While working on #326 , I was trying to figure out why Sengoku wasn't importing as expected. For some reason it was trying to import the Ronin twice... but it was only in the unit list once.
Then I noticed that Rider said there were 46 PRTOs, but counting them manually, there were fewer than that. Then I remembered... strategy maps!
Civ3 has a really weird file structure when you give multiple possible strategies to a unit. Instead of storing these in, say, a bitfield, it creates an entire new copy of the unit. One has one strategy, the other has the other. If you add a third strategy, there is a third unit of the same type.
The Ronin has both the Offense and Explore strategies ticked, and thus is stored twice using StrategyMaps.
We should not store multiple copies of units for strategy maps! Thankfully, unlike in my editor, we won't have to write them out in that manner either, just have the sense to know they aren't really two units.
You might think that the way to check for strategy maps is the units having the same name, but it's actually to check if the "otherStrategy" flag is not -1. If it's not -1, the unit is a StrategyMap of another unit. Excerpt from my editor's PRTO import code that shows this:
if (newPRTO.getOtherStrategy() != -1) //strategy map
{ //combine the strategies
unit.get(newPRTO.getOtherStrategy()).AIStrategy = (unit.get(newPRTO.getOtherStrategy()).AIStrategy) | newPRTO.AIStrategy;
//Recalculate the constituent parts
unit.get(newPRTO.getOtherStrategy()).extractAIStrategy();
}
So it isn't too bad once you know what's going on (and don't have to re-export it!). Still doesn't make sense as a data structure, but we can handle it.
While working on #326 , I was trying to figure out why Sengoku wasn't importing as expected. For some reason it was trying to import the Ronin twice... but it was only in the unit list once.
Then I noticed that Rider said there were 46 PRTOs, but counting them manually, there were fewer than that. Then I remembered... strategy maps!
Civ3 has a really weird file structure when you give multiple possible strategies to a unit. Instead of storing these in, say, a bitfield, it creates an entire new copy of the unit. One has one strategy, the other has the other. If you add a third strategy, there is a third unit of the same type.
The Ronin has both the Offense and Explore strategies ticked, and thus is stored twice using StrategyMaps.
We should not store multiple copies of units for strategy maps! Thankfully, unlike in my editor, we won't have to write them out in that manner either, just have the sense to know they aren't really two units.
You might think that the way to check for strategy maps is the units having the same name, but it's actually to check if the "otherStrategy" flag is not -1. If it's not -1, the unit is a StrategyMap of another unit. Excerpt from my editor's PRTO import code that shows this:
So it isn't too bad once you know what's going on (and don't have to re-export it!). Still doesn't make sense as a data structure, but we can handle it.