This problem still exists i can fix a few to give you examples but i can't do all of them.
Ok, easiest way for me to go about this would be if you choose one data load method, like say, arrays, and post what those need to be displayed as and then I can go through all of them in the Unit, building and general infos cpp files. Not thinking this will take too long for each type but one type at a time. Even ints/bools... do we have any of those that are needing correcting?
ahhh you got to it before i was going to edit, but NO to that answer, infact its very seldom, and i didnt really pay any attention to the units, only when i was going to attack did i notice some of these.
i got the same thing when i changed game options to c2c size matters. its changes everything to 0.05 . but when i merge 3 they go back to normal.
ggm
Aaaahhhh... yes well it's a GAME OPTION for a reason. The math isn't designed to be adjusted mid-game. What I'd highly suspect about your game SO, and correct me if it's even possible this could be wrong, is that when Alberts made his adjustments to the game option xml file that caused saved games to load with different options set true/false it caused your game to run for a bit without Size Matters being on... those units you see at .05 str may have been built during this time then going back to SM they become errored at the .05 str level.
ggm(thank you GOD for your post! I have a feeling this one would've had me pulling my hair out for HOURS without your observation!) makes a very good point that Size Matters introduces a mechanism by which we can often recalculate our units selectively by splitting then merging or the reverse if that's possible. This would then reset everything and correct the unit. (Too bad the AI won't know to do this to theirs!)
A whole game unit recalculation mechanism has been on my task list for a very long time and here's another game that could really use it!
But if you've seen the .05 str units in play long before Alberts' update and my subsequent 'fix' that should've righted things the other day then we could have a different issue still afoot so let me know if you saw it happening before then.
Also BEFORE you mentioned that you did something to the PreQ's that made the turns times shorter but it WASN'T a very good system of doing stuff, and you only did it because i mentioned something, can you PLEASE fix that and replace it BACK with the OLD system where everything works the way it is supposed to thx.
EDIT: Was just thinking also, this MIGHT have been done with "earlier" version also, whereas the adjustments were not working correctly???

[/QUOTE]
Now we have the old system back, thunderbrd tried to fix problems with missing building prereqs inside the dll and that made things alot slower. Also those missing building prereqs should get fixed inside the xml files.
It MIGHT be something that could be worked out in the code in a fairly smooth manner but it was an amazing slowdown for the amount of added processing that was actually taking place in that location which means that the AI scours that portion of the code so often that even a small adjustment there can have a really huge impact on turn times. So I'm with Alberts that the best way to address the problem is to clean up the xml and add the buildings that represent upgrades to any building prereqs that exist in any building's building prereq OR list.
Thus, if a building requires a stable, that building should ALSO require, as an optional 'OR' prerequisite, the Knight's Stable, the Modern Stable and any other building the stable might be upgraded to become. Any failure to do this with our buildings when building their prerequisites is going to be a major headache.
has anyone found the solution or the mangrove bug? i would like a fix that i can put into the base v34 version so i can continue mapping work without having to deal with it if anyone has found one.
It's probably IN the art file, most likely in the mesh file itself - outgrowing it's tile invisibly. I don't work with those programs for CivIV yet so I can't do it. But you MIGHT be able to get the features around a mangrove to show up if they are placed AFTER the mangrove (if you're building a map anyhow.)
@ the team
Did we ever have a 'ATTACHABLE_CHIMNEYSMOKE' in C2C?
I remember that i saw a missing 'ATTACHABLE_CHIMNEYSMOKE' error a while back but i can't remember what caused it.
I noted the missing chimneysmoke bug before we
had an SVN... it's been around THAT long. I THINK that the effect art can be found in RoM if we're looking for it. There's probably some arts we use here that could be copied and pasted into a new filename that Attachable Chimneysmoke refers to as well.