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.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...
SitReps
Moderator: Committer
-
- Creative Contributor
- Posts: 314
- Joined: Tue Aug 26, 2003 6:10 pm
- Location: Amidst the Inferno.
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.
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
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
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
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
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
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
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?...But we cannot assume the placement of Foo and Bar to be consistent for all languages...
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.
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
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
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.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.
Empire Team Lead
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.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.
DOH!
Ah - that all sounds lovely.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.
Heh, looks like i got all excited for nothing.
Anytime you want me to reinvent the wheel for you again just call.