Looking at it again, this is probably for the best; when writing my comment above I had forgotten about the sign out box. The other alternative is to take the if logged in/not in statement out of the php layer and push it entirely into the javascript layer such that this becomes one large block of javascript. Then the button declaration could be within the same javascript, at the end in either case.
Browser Interface Development
- Thread starter Wedge009
- Start date
By no means bug free, I've now integrated the minimap into the main game. I left behind all mention or code for the click-and-scroll-on-grid variant. The minimap still doesn't support scroll-while-dragging, but it does now slide in and out.
Wedge, I'd appreciate it, when you have some time, if you could verify its compatibility with other browsers. I also noticed that IE9 apparently has finally done away with a lot of the filter: garbage, and we can use -ms-transforms in much the same notation as the other browsers.
Wedge, I'd appreciate it, when you have some time, if you could verify its compatibility with other browsers. I also noticed that IE9 apparently has finally done away with a lot of the filter: garbage, and we can use -ms-transforms in much the same notation as the other browsers.
Wedge009
Rogue Leader
I understand you're still fine-tuning things, but I thought a little mouse cursor feedback on the mini-map would be helpful. I committed two small changes in the CSS to the repository.
As I mentioned before, we'll have to recruit someone else for IE9 development and testing. I'm glad to hear of the move away from the filter nonsense, but it's the first I've heard of it since I haven't done any development with IE9 before. Incidentally, your removal of the .folder{} rotation filter in ie.css has returned the Details/Hide button text in the fighter pop-up window to the standard horizontal orientation in IE8.
Anyway, for the new mini-map feature, here's what I've tested and the results I had:
Edit: I also rounded the corners on the mini-map collapser for cross-browser consistency.
As I mentioned before, we'll have to recruit someone else for IE9 development and testing. I'm glad to hear of the move away from the filter nonsense, but it's the first I've heard of it since I haven't done any development with IE9 before. Incidentally, your removal of the .folder{} rotation filter in ie.css has returned the Details/Hide button text in the fighter pop-up window to the standard horizontal orientation in IE8.
Anyway, for the new mini-map feature, here's what I've tested and the results I had:
- Gecko (Firefox 7.0.1): Seems to work as intended.
- WebKit (Chromium 17.0.915.0, Rekonq 0.7.90): Scrolling the main window is reflected in the mini-map window, but the opposite does not seem to work.
- Presto (Opera 11.52): Seems to work as intended.
- KHTML (Konqueror 4.7.2): No mini-map at all.
- Trident (Internet Explorer 8.0.6001.18702): No mini-map at all.
Edit: I also rounded the corners on the mini-map collapser for cross-browser consistency.
By all means! Thanks!
Hmm, perhaps we should go and add back in the filter then. A lot of people haven't upgraded to IE9 yet.
Weird, I thought this had been working. I'll have to mess with it later today and see where/what isn't reacting properly.
edit: nope, it never worked in Chrome for me, just checked the phase51 testbed. Weird.
Wedge009
Rogue Leader
Does the new MS-specific properties conflict with the older filter code? I can make it such that only IEs older than version 9 use the filter garbage.
I honestly don't know; we'd need to do some 'net research. I only happened upon it because the w3schools site started mentioning pre IE9 and post IE9 behaviours for a number of CSS tags. Putting in a split might be a good idea, but then anything we hadn't upgraded to the IE9 style would also need to be changed. (Who knows, maybe it is the IE8 filters being interpreted on IE9 creating those horrible red bars).
edit:
On a side note, much of our button and dialog formatting is coming out of the jquery UI. Wedge, you'll likely have noticed that we have a 'custom-theme' subdirectory which contains some images and the jquery-ui-1.8.2.custom.css.
We can generate new such directories using the themeroller, and they even have some example code on how to have the site dynamically switch between such theme sets. They even have a bookmarklet that lets us try to edit it in-situ and then save the version we like.
I mention this because the buttons all have huge text right now, but the actual theme I came up with for our site that wasn't the case. Some other piece of CSS somewhere is what is causing that. While we're looking at the css again, it might be worth tracking it down so that buttons like the 'sign up' and 'register' are done with the jqueryUI stuff, but more of the size and proportion of the ones you had done in pure css.
Works okay for me. It still doesn't get me to where I'm clicking on the mini-map, but that's probably because Avacar hasn't implemented that feature yet. Everything else is good!
It should exactly work when you click. It does in Firefox. Click minimap, and it should jump the main map there. Drag minimap, and on release you should jump there.
Um, no, I'm saying it doesn't work in Chrome. 
I thought the clicking/dragging on the mini-map wouldn't work at all, but after you mentioned Firefox, I noticed it actually does. In Chrome, it just shows the position of all in-game objects and highlights the correct portion of the screen after scrolling.
I thought the clicking/dragging on the mini-map wouldn't work at all, but after you mentioned Firefox, I noticed it actually does. In Chrome, it just shows the position of all in-game objects and highlights the correct portion of the screen after scrolling.Just something I noticed when I tried issuing orders in Game 4: In Safari under iOS 5, I couldn't access the multi-object selector. I was able to tap on "Objects," but the drop-down menu wouldn't appear. Also, when tapping on a ship, the info screen pops up, but I haven't found out how to close it properly. (It once closed when I tapped on "Field Report," but this wasn't consistent.)
I know that touch screen support isn't a priority right now, but I thought I'd let you know anyway.
I know that touch screen support isn't a priority right now, but I thought I'd let you know anyway.
Yeah, you close by mouseing out of a popup... something you can't do on a touch interface. I can add a 'close' button to them at some point.Just something I noticed when I tried issuing orders in Game 4: In Safari under iOS 5, I couldn't access the multi-object selector. I was able to tap on "Objects," but the drop-down menu wouldn't appear. Also, when tapping on a ship, the info screen pops up, but I haven't found out how to close it properly. (It once closed when I tapped on "Field Report," but this wasn't consistent.)
I know that touch screen support isn't a priority right now, but I thought I'd let you know anyway.
Wedge009
Rogue Leader
From the other thread...
Consistent fonts across different platforms has long plagued web designers - I know that my plain rendition of the ICIS manual has issues with default fonts on a Linux desktop. I can't remember if it's HTML5 or CSS3, but one of those new draft standards intends to introduce web fonts which will download any required fonts for a consistent type-face presentation across all systems. If it's really that big an issue, it could be worth a try.
It's a system issue, not a browser issue. I've attached my Chromium window - the fonts are the same as they are in Firefox. I'm pretty sure if you try Firefox on your system, you could get a similar problem.
Consistent fonts across different platforms has long plagued web designers - I know that my plain rendition of the ICIS manual has issues with default fonts on a Linux desktop. I can't remember if it's HTML5 or CSS3, but one of those new draft standards intends to introduce web fonts which will download any required fonts for a consistent type-face presentation across all systems. If it's really that big an issue, it could be worth a try.
Attachments
I say we give these web font options a shot. We're already pushing the bleeding edge with a number of our other features, so might as well do so there too. Feel free to switch up the fonts however you wish; these were chosen mostly to make it look most like what Ironduke had done on the older, static WCTO.
Wedge, can you take a stab at it when you have some time? If not, I'll eventually get around to it.
Wedge009
Rogue Leader
I did a bit of research to refresh my memory. CSS3 introduces a @font-face rule which allows specification of a src attribute to tell the browser where to download the font file, if required. However, before I get in too deep (it's a bit late for me to be doing development work - give me another 17 hours or so, when my weekend starts): Ironduke, could you please confirm what operating system you're using and whether or not you have Verdana and/or Arial available? That's all we're really specifying in the CSS.
Edit: Uh, I just realised what the problem is. The CSS does not specify fonts for all text. I tested Firefox, Chromium and IE on my WinXP system and it seems they all use Times New Roman as the default font. However, if I choose a different default font, then the appearance of the text in the pop-up box changes. I can work on making sure all the selectors have fonts are specified when I get back from work tomorrow.
Another Edit: Couldn't help myself - had to work on it for a bit, but I'm giving up now. I set the global font-family at the <body> level to use the same 'Verdana, Arial, sans-serif' and tried to fiddle with the .partslist selector to shrink the font, but the sans-serif fonts turn out to be a lot wider than the previous default serif font that was showing before. Also, changing the font seems to make the text in div.ship_title a bit too big as well.
Avacar or Ironduke, would you be able to provide an example of the static WCTO styling so I have something to compare with? At this point in development, it might be a better idea to only change what's necessary instead of trying to specify a global font-family. I have a headache now, I'm going to bed.
Edit: Uh, I just realised what the problem is. The CSS does not specify fonts for all text. I tested Firefox, Chromium and IE on my WinXP system and it seems they all use Times New Roman as the default font. However, if I choose a different default font, then the appearance of the text in the pop-up box changes. I can work on making sure all the selectors have fonts are specified when I get back from work tomorrow.
Another Edit: Couldn't help myself - had to work on it for a bit, but I'm giving up now. I set the global font-family at the <body> level to use the same 'Verdana, Arial, sans-serif' and tried to fiddle with the .partslist selector to shrink the font, but the sans-serif fonts turn out to be a lot wider than the previous default serif font that was showing before. Also, changing the font seems to make the text in div.ship_title a bit too big as well.
Avacar or Ironduke, would you be able to provide an example of the static WCTO styling so I have something to compare with? At this point in development, it might be a better idea to only change what's necessary instead of trying to specify a global font-family. I have a headache now, I'm going to bed.
Just head to the original WCTO page and look at the various games there. It is all done in static flash though, so you can't extract anything. This has led to a lot of guesswork on my part, or asking Ironduke. Ultimately I wanted to make WCTOO as close to WCTO as I could since this whole thing is Ironduke's baby... but the further we get into development I think it is okay for us to deviate on small things (like fonts) when and where it adds clarity and/or fixes bugs.
Feel free to pick fonts/restyle as needed to make it consistent. I mentioned this before too, above, but I'll mention it again: feel free also to standardize some of the font-size commands. I know that, especially, the 'buttons' that are being declared in .button() commands to the jqueryUI seem to have really large text. I know that that isn't coming from the jqueryUI theme CSS, so something we have has overwritten that and increased the text size. If you go through and standardize fonts and text sizes, I suspect you may clean that up automatically. If not, if you happen to run across where we're "leaking" a font size increase, please clean it up!
Actually, while I really appreciate your staying true to the original WCTO, I'm all for any changes that will improve the game. I can only repeat myself, but you're doing a fantastic job here I couldn't have done myself. Thanks a lot!
Wedge009
Rogue Leader
Yeah, unfortunately, anything to do with the background scrolling to the top/left while interacting with windows seems to be an artefact of the jquery dialogues. Haven't found any obvious culprits yet.
I did do a bit of research today, though, and I have a few cross-browser improvements to try. I'll be working on those as I tidy the CSS code in general.