I suspect that this all may be tied to the Events system, since it is purely a graphic issue. For example, Events.SerialEventImprovementCreated and similar events probably fire as the improvement changes state (with state=0 for unseen).
Correct. If you observe an improvement being created, the SerialEventImprovementCreated event will trigger twice; once from the transition to the under-construction state (0 -> 1), and then again when it transitions to the fully constructed state (1 -> 2). However, if the improvement is being created in an area where you don't have visibility, then when you move your unit to a point where it can see the completed improvement, it'll trigger that event once (0 -> 2), even if the improvement was actually built a hundred turns earlier.
You see, when I first started adding Terraforming code to my own logic, I'd used that event to control it. You'd build a "BUILD_FOREST" improvement, and when its construction completed the improvement would be replaced with a forest through a Lua event. But unfortunately, this Event is limited in the ways I described; an AI player would have to wait until the human looked at his area to get the actual benefits of the Forest, and the event's double-firing for the player's lands would cause headaches. And then, the fact that large numbers of improvements would need graphical updating would cause crashes when a high-mobility, high-visibility unit (like a Caravel) would pass nearby, which leads to...
Before someone comments by saying this will crash your game, let me just say that there is no clear evidence either way on that.
Yeah, it most certainly DID crash your game. Maybe you've never run into this personally in your own mods, and maybe they've improved it since the olden days, but there was no question that this flag was responsible for a ridiculous number of crashes in my own mod, or any other mod that spent most of its time in a fully developed world. It was especially common in mods that had units with really high movement rates or large visibilities, to where a single movement command might require a few dozen hexes to update their graphics at once; part of this is that the game does not cleanly separate the execution of events, and won't wait for one update to finish before beginning the next. (You can see a similar effect in the RunCombatSim event, where the next combat's animation can begin before the previous one finishes.)
It got to the point where the chance of the game crashing approached certainty on any given turn, and since this crash could happen during the AI's turn as well, there was no way to alter your playstyle to prevent it from occurring. Disabling that reload flag fixed all of that, and at the time it did nothing beneficial.
Now, since then they've made a lot of improvements, and that flag now actually does something, so the crash issues might no longer be a major problem. But there's no question that it WAS causing crashes.
Hopefully the DLL will shed some light on this mystery...
