SitReps

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

#16 Post by tzlaine »

Almkaz wrote: Finally, you are correct - one should never send strings down the network unless absolutely necessary. However, what we talk about here is sending down string IDs - they are only IDs that reference a string table on the client - thus they are much smaller...
That's quite right, and we're also zip-compressing all traffic using libz. And since all the traffic is text, and most of it is pattern-heavy XML, the compressed traffic is rather small.

Ablaze
Creative Contributor
Posts: 314
Joined: Tue Aug 26, 2003 6:10 pm
Location: Amidst the Inferno.

#17 Post by Ablaze »

I still think sprintf is more flexible, as the insertion point is coded into the string itself rather then the code. Either way the order of the variables is hardcoded.. which brings up another question: What if one language needs to put the planet name before the galaxy name and another needs to reverse the two? It seems impossible under the current system.
Time flies like the wind, fruit flies like bananas.

jbarcz1
Creative Contributor
Posts: 226
Joined: Thu Jun 26, 2003 4:33 pm
Location: Baltimore, MD

#18 Post by jbarcz1 »

I always assumed our string table would like like this:

English:

The Planet %object-1% has been colonized.
The Planet %object-1% has been conquered by %empire-1%
The %empire-1% has declared war on the %empire-2%

If we need to insert an object name we just look for the tag in the string, lookup the object, and substitute its name. To transmit a sitrep entry then, all we need to do is send N different object IDs. The client will take care of looking up their names, getting the string from the string table, etc.

All the sitrep creator has to do is specify which string is being pulled from the string table, and what the IDs are of the objects whose names get inserted. We should be able to support pretty much any language this way.

JB
Empire Team Lead

Almkaz
Space Floater
Posts: 31
Joined: Thu Sep 18, 2003 12:25 pm
Location: Ottawa, Canada

#19 Post by Almkaz »

Good point - my assumption earlier that the order of text and placeholders was sequential is flawed ( sorry, I should have remembered from JA2 ).

Example:
"PLANET_MAX_POP_MSGX"
" Foo "
"PLANET_MAX_POP_MSGY"
" Bar "
"PLANET_MAX_POP_MSGZ"

creates the string: "Planet Foo in the Bar system has reached its maximum population."

But we cannot assume the placement of Foo and Bar to be consistent for all languages. For example, some languages would require the sentence to be reordered to make grammatical sense:

( don't remember by high-school French, so let's assume this is another language )
"PLANET_MAX_POP_MSGX"
" Bar"
"PLANET_MAX_POP_MSGY"
" System"
"PLANET_MAX_POP_MSGZ"

creates the string: "In the system Bar, the planet Foo has reached its maximum population."
We need the flexibility to have the order and placement of the variables to be done through content. In the current system, the code would have to be re-written on the server end to encode the strings in a different order.
We can't even use the sprintf() style:
"The planet %s in the system %s has reached its maximum population".
In this case, the person translating the string would not have control over which position to place each variable.
I think jbarcz1 had the right idea, where the variables need to be named so that they can be substituted correctly:
"The Planet %planet-1% in the system %system-1% has reached its maximum population"
We can combine this with the XML idea earlier so that the client can easily parse the SitRep data into a string.
For example:
The string with ID PLANET_MAX_POP reads:
"The Planet %planet1% in the system %system1% has reached its maximum population"
The XML message for the SitRep is:
<sit_rep type="max_pop_reached">
<string_id value="PLANET_MAX_POP">
<planet1 value="10">
<system1 value="5">
</sit_rep>
In this way, the client parses the string and when it finds a %token% it uses that token as the tag name for the XML element to retrieve and place at the location.
So, we can re-arrange the placement of the variables for any language and only need to change the content.
Andrew

Yoghurt
Programmer
Posts: 376
Joined: Sat Jun 28, 2003 8:17 pm
Location: Heidelberg, Germany

#20 Post by Yoghurt »

Gnu Gettext would solve these problems. Furthermore it is more or less the "standart" for open source software, for those of you hwo don't know it, it might be worth a look
http://www.gnu.org/software/gettext/gettext.html

BTW: I'm still alive, but learning for my final exams. I'll hope to be back in November

Daveybaby
Small Juggernaut
Posts: 724
Joined: Mon Sep 01, 2003 11:07 am
Location: Hastings, UK

#21 Post by Daveybaby »

...But we cannot assume the placement of Foo and Bar to be consistent for all languages...
Hmmmm.... this is exactly the kind of thing i was talking about. Never mind french, what about if someone wants to build a kanji client? Or a braille one? Or a WAP one?

I can see why its not practical for the client to make all of the decisions regarding sitreps, but i maintain that the server shouldnt really even have to know what a string *is*.

IMO what you should be doing is creating a solid and flexible event reporting system. This would be used for 'Event' events, such as supernovae, wandering performers etc, and for regular gameplay events, such as 'system X has been colonised' and 'race Y has declared war on race Z'. What it shouldnt include is ANY bias towards how the client decides to inform the user of these events.

You really need to establish roles here, i.e. define boundaries between the servers job (receiving, processing and outputting raw game data) and the clients job (presenting that data in a nice/helpful way, parsing the players commands). It should make no difference to the server whether the client informs the player of a 'supernova' event via a text string or a full blown 3 minute mpg. Or via the magic of dancing sheep.

Each event needs, at minimum, an identifier (i.e. an integer denoting what the event is, e.g. 5 = supernova, 18 = war declared etc), an importance/priority level (e.g. red/green/yellow in moo3) and event specific data (e.g. a planet ID#, a quantity, an empire ID etc). I'm sure theres other stuff that could be useful but thats the basics.

Each turn server would send the player both the static gamestate at the end of the turn processing (i.e. what the current state of the universe is) *and* all of the events that occurred that turn. This way the client has all of the information it needs to do its job properly, which is to present the information to the player in the most useful way, in whatever form the player has chosen.

Almkaz
Space Floater
Posts: 31
Joined: Thu Sep 18, 2003 12:25 pm
Location: Ottawa, Canada

#22 Post by Almkaz »

What you are describing makes perfect sense and is what, as far as I can see, are the current roles/boundaries for the client/server.

What we are in the process of doing here is flushing out ideas for a system that has not yet been coded - so it's good to test them against the roles of the client/server.

And you have caught one with the last XML example - the server probably does not need to send the text string ID, since it is redundant information because the type of message is sent over as well. The client only should know about which strings to display ( or mpg as you mention ).

So the xml becomes:
<sit_rep type="max_pop_reached">
<planet1 value="10">
<system1 value="5">
</sit_rep>

Andrew

Ablaze
Creative Contributor
Posts: 314
Joined: Tue Aug 26, 2003 6:10 pm
Location: Amidst the Inferno.

#23 Post by Ablaze »

Just a minor point here, but I don't think the server should decide the importance of an event. That should, at the very least, be modable by the client.
Time flies like the wind, fruit flies like bananas.

jbarcz1
Creative Contributor
Posts: 226
Joined: Thu Jun 26, 2003 4:33 pm
Location: Baltimore, MD

#24 Post by jbarcz1 »

Daveybaby wrote:
IMO what you should be doing is creating a solid and flexible event reporting system. This would be used for 'Event' events, such as supernovae, wandering performers etc, and for regular gameplay events, such as 'system X has been colonised' and 'race Y has declared war on race Z'. What it shouldnt include is ANY bias towards how the client decides to inform the user of these events.

You really need to establish roles here, i.e. define boundaries between the servers job (receiving, processing and outputting raw game data) and the clients job (presenting that data in a nice/helpful way, parsing the players commands). It should make no difference to the server whether the client informs the player of a 'supernova' event via a text string or a full blown 3 minute mpg. Or via the magic of dancing sheep.

Each event needs, at minimum, an identifier (i.e. an integer denoting what the event is, e.g. 5 = supernova, 18 = war declared etc), an importance/priority level (e.g. red/green/yellow in moo3) and event specific data (e.g. a planet ID#, a quantity, an empire ID etc). I'm sure theres other stuff that could be useful but thats the basics.
This is exactly what the Sitrep objects are supposed to do. Every time an event occurs (planet builds something, planet colonized, etc), we'd create a sitrep object with the pertinent data and pass it back to the client. There are strings stored in there currently, but my impression is that this is only temporary and they will go away once SitReps strings are put into the string table.
Empire Team Lead

Daveybaby
Small Juggernaut
Posts: 724
Joined: Mon Sep 01, 2003 11:07 am
Location: Hastings, UK

#25 Post by Daveybaby »

Ablaze wrote:Just a minor point here, but I don't think the server should decide the importance of an event. That should, at the very least, be modable by the client.
You are, of course, totally correct. Having that in there completely contradicts my argument about keeping client and server behaviour well separated. Dont know what i was thinking.

DOH!
jbarcz1 wrote:This is exactly what the Sitrep objects are supposed to do. Every time an event occurs (planet builds something, planet colonized, etc), we'd create a sitrep object with the pertinent data and pass it back to the client. There are strings stored in there currently, but my impression is that this is only temporary and they will go away once SitReps strings are put into the string table.
Ah - that all sounds lovely.
Heh, looks like i got all excited for nothing.

Anytime you want me to reinvent the wheel for you again just call.

Post Reply