FreeOrion

Hello!

With some turn processing in, I am working on flushing out the P&G and movement methods of universe objects. Part of this is producing SitReps for conditions like research done, max industry, etc.

Currently, SitReps contain members for: the type of sitrep, turn produced and a string. There may be a need to augment this class in order to better suit the server.

For one, we probably do not want to send over strings. In that case, the string needs to be constructed on the client as it receives SitReps. For this, we need parameters for the SitReps - planet ID for industry maxed out, Tech ID for new research, etc.

The obvious thing is to make sub-classes of SitRep for each type ( with the corresponding XML support and factory )..

Does this make sense? If it does I can do this but it will probably be after I flush out the turn processing. Are there other candidates who would want to take it on??

Andrew

We had a discussion about this before your arrival to the project, so you'd have no way of knowing this, but that's actually the way we had originally planned it.

However, I felt then as now that we'd be faced with an explosion of SitRep classes if we went that route. Instead, I favor an approach that relies on the inherent power of the LinkText class. I feel that SitRep entries should simply inform the player that something has happened, and allow her to follow a hyperlink to the relevant screen. For this, I believe we only need to use the proper text and not a class hierarchy.

However, generating the link text server-side could be problematic. Since we are trying to support multiple languages from the outset, perhaps we should send the SitRep entries in some sort of meta-language that can be converted client-side to the proper string (including LinkText tags) using the local language preferences.

This meta-language doesn't need to be complicated, it could just be something like a vector of strings:

"PLANET_MAX_POP_MSGX"
" Foo "
"PLANET_MAX_POP_MSGY"
" Bar "
"PLANET_MAX_POP_MSGZ"

where the X, Y and Z strings represent the three strings needed to compose the message string in various languages, and can be looked up in the string table.

In English:

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

This may be getting too complicated, but I think it's fairly easy to maintain, considering its flexibility and its relative adjustability via text files. In other words, it will be up to the various translators to get the X, Y, Z, etc., right for each message.

I'm not laying down the law here, but proposing this. Ideas?

I like the meta data route - no need to create an explosion of classes.

I also like sending down the string IDs to the client to compose the text.

The only gray area for me is how to send down the relevant link data. It we send an array of strings, would the client then lookup that name for planet "Foo" to determine it's ID so that it can build the link tag? Or should we send down the plant ID value instead of the planet name?

Using your example, we would write:
"PLANET_MAX_POP_MSGX"
"1"
"PLANET_MAX_POP_MSGY"
"34"
"PLANET_MAX_POP_MSGZ"

Where 1 is the planet ID and 34 is the system ID. The client decoding the message would look for the above sequence of strings and know that the 2nd represents a planet ID and the 4th represents a system ID for this particular SitRep type. It could then compose the string as well as the link information from the IDs.

One thought - What about using XML for this language? Is there any advantage, besides maybe readability for debugging? I'll put it out there for any discussion...

The XML language could contain all the possible variables that SitRep reports need as elements.

For example:
XML Elements: <sit_rep>, <string_id>, <system_id>, < planet_id >,<tech_id>,<empire_id>, etc

The XML for the Foo Bar example could look like:

<sit_rep type="max_pop_reached">
<string_id value="PLANET_MAX_POPX">
<planet_id value="1">
<string_id value="PLANET_MAX_POPY">
<system_id value="5">
<string_id value="PLANET_MAX_POPX">
</sit_rep>

The client knows that for a sitrep of type "max_pop_reached" has it's XML document in a given order: string_id element, planet_id, string_id, system_id and a final string_id element. It would walk the tree looking for this sequence. Other events would expect the document in other ways.

Since it's using hte IDs it can fomulate the link tags.

I guess, basically it's the same idea but using XML as the meta data instead of an array of strings...

Andrew

I see a potential problem with this idea: Not all languages have the same grammatical syntax. For instance, some languages may have to read like "Maximum population reached on planet foo in the bar system." Scripts could be used to reorder the strings, but that sounds like needless effort to me.

I purpose that the magic of printf is used. The stings can be stored client side with wildcards for the planet and system names. If you want to use indexes instead of actual names that can be accomplished with 2 nested printfs. (One to replace the index with a string and another to insert the string into the complete message.)

This method also cuts down on the total traffic:
<sit_rep type="max_pop_reached">
<string_id value="PLANET_MAX_POP">
<planet_id value="1">
<system_id value="5">
</sit_rep>

_________________
Time flies like the wind, fruit flies like bananas.

It is always possible to make n+1 strings fit around n names, and make a sensible sentence, as long as the n names can be left in the given order. This is because if necessary the first and/or last of the n + 1 strings can be empty. Note that your alternative string makes my point. Think about this for a while if you don't see it at first.

BTW, printf is evil.

No matter what, XML will be used to move this across the network, since that is used for everything. Since the order will be implicit for each SitRep type, I think we can get away with just providing the SitRep type and the strings that make up the message in order. You're right about making the lookups easier by passing the ID numbers instead of the actual names of the subject(s); we should do that.

I'll buy that. I suppose my only real point, then, is that it would be slightly more efficient to pass 1 variable for a string over the network then n + 1 variables.


Is not! I'm not listening!! Naaa naaa naa naa...

*..*

..I mean.. why would you think such a thing?

_________________
Time flies like the wind, fruit flies like bananas.

Great, this all sounds good.

Now, about constructing these SitReps on the server. We'd want a convienent way to create them. Similar to the desing pattern we have for Message.cpp/h - we could have functions for each type of SitRep. They would take any paramters required for creating that particular type. For example:

CreateMaxFactoriesSitRep( int planet_id, int system_id );

This would create a SitRep with the appropriate array of strings.

If this all sounds good, I can implement them as I implement the P&G and movement unviverse object methods on the server...

That's exactly what I had in mind. Have at it.

First off, i will admit to knowing nothing about your client/server traffic patterns, and you've obviously already discussed this, but....

It strikes me as kind of odd that you have the server generating sitreps in the first place. The server should *already* be sending the client all of the 'visible' information for that turns events, just so that the client can update its status as per normal.

So why not just let the client generate sitreps locally? It recieves the turn info from the server, and determines from that data what sitreps to display based on the player's current sitrep filters. You can recalculate the list on the fly when the filters are changed.

Sitreps are just another way of displaying the same information which is being sent to the client. You dont send the number of pixels to fill in for a 'turns to completion' bar - you just send a numeric value of the number of turns to completion for each of your shipyards and let the client figure out how to present that information. So why send a string saying "Construction of ship X has 5 turns to completion", or "Construction of ship Y has been completed" when you've already sent the number of turns to complete those ships anyway?

There is no need to send extra information from the server, let alone transmit strings (which going to eat bandwidth like crazy, and cause all sorts of extra work for the server, especially if you decide to start producing localised versions down the line).

What you describe would produce less traffic. However, it would probably make up for it in coding and thus complexity to maintain and a larger source of bugs ( isn't it always a tradeoff between data and code complexity? ).

For the example of a new colony SitRep, when receiving new data, the client could do a diff and determine that the empire owns a new planet ( there is one there that it did not own before ). However, why did this planet become part of the empire? You can't assume it's from a colonization - it could have been taken over from attack, etc. You would need some code and data to make the proper distinction.

Another example - max production - you could easily see if a planet was at it's max production - but only producing a SitRep for the first time it reaches that maximum would require some extra data for the client to hang on to like a flag indicating that it's the first time.

Producing SitReps like this would be fairly complex code, and also produce funny bugs like producing a SitRep for something that is not true ( and it WILL produce bugs like that - if it's coded by a human, it will have bugs ). For the most part it's much less code to detect the SitReps on the server ( and thus less bugs ).

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...

Take care!
Andrew

i was curious as to why it is evil? Other than the fact that its not the speediest function in the world...

_________________
FreeOrion Programmer

Its a blasphemous, pagan artifact of C.
We must all embrace the purity of C++
Have you not read The ten commandments!?!

see: http://rikkus.info/ten_commandments.html

_________________
Empire Team Lead

I never read those before....but I see. (though I meant sprintf())

anyway, doesn't the STL string class have a "format" function that operates like sprintf()?

_________________
FreeOrion Programmer

No. But prefer stringstream for that kind of thing. It acts just like any other stream, but writes to a std::string. So you can do neat stuff like:

std::stringstream stream;
int i = 0;
std::string j = "1";
stream << i << " " << j;

instead of worring about using %d and %s in some formatting call.