NationStates Jolt Archive

1) It seems most of the pages rely on a white background by default. Well, my desktop theme has another color for window content background... maybe the css could be fixed to include a "background-color: white;" for the body?
2) I still don't understand why, when you upload custom flags bigger than 107x71, the full size flag shows when you see a foreign nation page but it is constrained when it's your own.

1. I haven't a clue, this is Sal's area of expertise. :wink:
2. Well, when you view your own nation it's smaller to allow the Jennifer Government and Syrup banner to fit on the screen.

2. Well, when you view your own nation it's smaller to allow the Jennifer Government and Syrup banner to fit on the screen.
I get the point. However, given most nations have a normal size flag, is it really that a biggy?

Well, since there's something like 80000 nations, I'm assuming that it might just be. :wink:

Besides, it draws more attention to the banner. :P

*sob*, so long for seeing my flag in its full glory :P

Oh, and about the css, I should also mention that not only is background-color on a default setting but so are table borders and vertical bars. I really think it would be a good idea to look further into this... Sal. ;)

Or have transparancies in the banner ... (I use a grey BG color, so I notice this all the time :P)

Hmm, good point with the default background. I think that it will be changed.

As far as the different sizes that you see flags. I can give you a technical answer as to "why", but not the motivation. Displaying your own nation is a different process from displaying other nations. This is why you don't have a TG field or the ability to change endorsements at the bottom, but do have access to issues and telegrams.

http://www.weirdozone.0catch.com/projects/nationstates/salusasecondus/salusasecondus2.jpg
SalusaSecondus
Tech Modling

Just a little curious. I know there are xml feeds, but they don't seem to be sent to the client (I mean, the nation pages and all that jazz). I have the feeling xml is processed on the server. Given most modern browsers support xml/xsl, wouldn't it help the server to send the xml to the client rather than a server-side pre-transformed html (less bandwidth used, less cpu power eaten)? Another good side effect could be themability too (even with xsl files hosted on other servers - custom skins).

The server doesn't process the data as XML. The XML is itself dynamically (or daily?) created in order for you to get the region/nation data feeds. No XSLT is performed server side, to the best of my knowledge, as the output is raw XML. If you wanted to create a formatting scheme, it's perfectly easy for you to generate your own local page that will format the XML feed using any number of XSLT stylesheets.

I think that the suggestion is that the server send XML directly to the browser/client which will then format the pages appropriately, thus, resulting both in lower bandwidth requirements and greater parsibility by custom clients. If so, that's a good idea, but is also a major change and will probably take a while to be done (if ever).

http://www.weirdozone.0catch.com/projects/nationstates/salusasecondus/salusasecondus2.jpg
SalusaSecondus
Tech Modling

Ah, I see. I thought we were talking in terms of the data feeds.

If we're talking main game things... well, it's something I'd personally love to see, but as you say, it's kind of a big task. How's the coding going along with NS2? If it's still at the level where something like this could be easily implemented, I can see it being a great advantage. Certainly with a bunch of the features I'm planning to implement, the ability to grab the data without having to parse through formatting information would be highly useful.

Sorry, I know nothing more about NS2 than you guys do.

1) It seems most of the pages rely on a white background by default. Well, my desktop theme has another color for window content background... maybe the css could be fixed to include a "background-color: white;" for the body?
Aha, thanks for the report. Fixed.

2) I still don't understand why, when you upload custom flags bigger than 107x71, the full size flag shows when you see a foreign nation page but it is constrained when it's your own.
Initially this was a bug. But it deliberately hasn't been fixed -- that is, flag sizes haven't been forcibly restrained to the required size when viewed by other players -- because it's rarely been abused, and some people do post good non-standard sized flags. I suppose we should make it consistent across both views. Okay, I'll do that. :)

]2) I still don't understand why, when you upload custom flags bigger than 107x71, the full size flag shows when you see a foreign nation page but it is constrained when it's your own.
Initially this was a bug. But it deliberately hasn't been fixed -- that is, flag sizes haven't been forcibly restrained to the required size when viewed by other players -- because it's rarely been abused, and some people do post good non-standard sized flags. I suppose we should make it consistent across both views. Okay, I'll do that. :)

Looks like that's been implemented. Thanks, [violet]!

Yeah! Great work! Thanks violet :)

I think that the suggestion is that the server send XML directly to the browser/client which will then format the pages appropriately, thus, resulting both in lower bandwidth requirements and greater parsibility by custom clients. If so, that's a good idea, but is also a major change and will probably take a while to be done (if ever).
Actually, I doubt it would be that long. The xml datafeed is already written and so are the HTML generation scripts so a merger/modification of those two could generate a xml file instead of a html file pretty easily. The big thing would be the XSL stylesheet(s), but I don't see that much work given the pretty simple layout of the pages. Browser sniffing could be used to detect if the client can process xml.

So, the steps would be:
1) make an extended version of the datafeed script or simpler version of the html generators => xml files
2) add the said scripts to the cron (or dynamic scripts given the situation)
3) add browser sniffing in the pages and stream the correct file (html or xml) given the browser type/version.

A more violent way would be to switch to xml totally, but I'd need users' browser stats to see if this wouldn't penalize a lot of players (I doubt it, my experience is most people use the latest IE or the latest netscape/mozilla).

Anyway, in term of cpu usage, I have the feeling the main issue on the server is the forums. I've been searching the web for countless hours but I couldn't find a xml-generating forum in php. That's sad, because given how phpBB has been shrinked (configured) to an extreme minimum (no avatar, no pm, no sign up, etc, etc), all what's needed is something clean and fast.