FreeOrion

I noticed that the starting fleets in recent build no longer had names like "Colony Fleet", "Scout Fleet" etc., but "FN_COLONY_FLEET", "FN_SCOUT_FLEET" etc. Apparently these string identifiers don't get translated into the corresponding string entries in the stringtables.

Looking at the FleetPlan and FleetPlanManager classes code revealed that FleetPlan has a member flag which decides if the fleet name stored in m_name will be looked up in the stringtabels (via call to UserString()). This flags defaults to false in the ctor code, and nowhere in the rest of the code it gets set to true, resulting in never being translated in the corresponding entry in the stringtables.

I tried to find out where and how this flag has been set to true for the starting fleet plans in rev 4471 (where it worked, fleet names have been translated), but I have to admit I failed. I guess it happened somewhere in the old parser code, but I coudn't figure it out, I'm a bit out of my legue here

So I finally came up with the idea to check if the first three characters of m_name equal "FN_" in FleetPlan::Name(), and if that's the case to ignore the lookup flag, looking up the name regardless and returning the translated string (instead of the identifier string). Test build went fine, fleet names of the starting fleets were back to normal.

However, I doubt that this is the way things should work, but this was the best I could think of. I have no idea in what way the parser code would have to be modified to get the original behaviour. Nevertheless I attached a patch, it should work at least as a temporary solution. Don't know if you want to incorporate it into SVN...

EDIT: Don't use patch attached to this post, it's obsolete and has been replaced by a new one! See subsequent post below.

In 4471, the FleetPlan parsing looked like this:
The val(true) is the parameter to the FleetPlan constructor to tell it to look up the names in the stringtable. So, for FleetPlans created by parsing, this flag was always true.

I'm not sure if there's any case where fleet plans are made not by parsing, but it'd probably be OK to change the default value of that parameter for FleetPlan to true.

To replicate the old behaviour, you might be able to pass true to the FleetPlan constructor in the parser. I'm not sure if this needs wrapping in something like val(true) as was required for the old parser, but the relevant bit of FleetPlansParser.cpp is which is not specifying anything for the third parameter, so is using the default false, resulting in the names not being looked up in the stringtable, as that's what that parameter specifies.

Inspecting the name for FN_ is indeed not a good idea.

As far as I can tell fleet plans currently are only used to set up the starting fleets, and because of that my first try to solve the issue has been exactly that, changing the default value of that parameter to true. However, I wasn't comfortable with that solution because I thought this flag surely exists and defaults to false for a reason. Maybe there is no apparent use for it now, but whoever wrote that code might had some future use in mind. Not that my solution was any better, on the contrary...


Well, when in doubt go with the original plan (that already proved to be working), so I decided to replicate the old behaviour. Which I was able to do now, thanks to your hints


Definitely needs wrapping - not wrapping leads to crashes, as I just found out. However, I had to use "phoenix::val" instead of just "val". Made a build and ran a quick test game, starting fleet names are back, everything seems to work fine. New patch attached.


Yeah, that's not a fix, but a hack, and I didn't like it at all. Doing it this way was just asking for trouble. MUCH better now