C2C SVN Changelog

[Il Principe]

removed by me

 

[Dancing Hoskuld]

Yay! I fixed it!
It somehow got set wrong on the zoom out map. The globe one.

Also, I will add my thoughts on things as I find them in this thread. Also, who's the voice actor for the techs? What accent does he have?

Discussions belong on one of the other threads, here or here, bugs belong in the BUG forum. That allows this thread to be kept clear so people can keep up with what is changing in the beta (SVN). Thanks.

 

[strategyonly]

Made the Valley of the Kings Wonder not to be built by the Barbarians anymore, also added Bandit FoodPad to be built by the Barbarians.

 

[ls612]

Updates:

-New Button for the Medevac Dropship.
-Tweaked the Light Tank
-Renamed the Heavy Tank M26
-Renamed a LOT of the Air units.
-Removed some useless code for Terrain damage.

 

[DavidB1111]

Sorry, Dancing, didn't know about an entire forum for bug reports.

 

[Dancing Hoskuld]

Updates

- Caves should now appear on new maps.

Edit

- Moved all concepts into two entries in the pedia. One for Civ IV-BtS and the other for C2C. However I have not managed to remove the two old new index lines for DCM(RoM) and AND. There is some interaction with the dll I am not sure of.

 

[strategyonly]

Updates

- Caves should now appear on new maps.

Edit

- Moved all concepts into two entries in the pedia. One for Civ IV-BtS and the other for C2C. However I have not managed to remove the two old new index lines for DCM(RoM) and AND. There is some interaction with the dll I am not sure of.

Correct, Koshling will need to deal with that stuff, i am pretty sure AIAndy might even know, but at the moment he is really really busy as Koshling are in RL, so please be patient everyone. . .thx

 

[Koshling]

Just pushed to SVN (4329):

• Fixed performance issue with modifier recalculations

Turns out this was down to the new code for orbital buildings. CvPlayer::hasOrbitalInfrastructure() was being called several million times, which chewed up the time.

Using the game SO posted as my test case, the timings are as follows:

Previous SVN version: 3995 seconds

After adding a cache to the orbital building count: 227 seconds (which is basically where it was a few versions ago before the orbital stuff went in, I think)

After also addressing another issue that the analysis revealed: 85 seconds

Enjoy!

If anyone finds any problems with recalculation not producing the right result (or the same result if run twice) let me know (it seems ok in my tests, but there could be special cases I guess).

I'm a bit too full of Thanksgiving cheer (aka Champaign) to do any more now, so the CTD will have to wait for another day.

 

[Stormwind]

I'm a bit too full of Thanksgiving cheer (aka Champaign) to do any more now, so the CTD will have to wait for another day.

Thank you!! Have fun!

 

[ls612]

Just pushed to SVN (4329):

• Fixed performance issue with modifier recalculations

Turns out this was down to the new code for orbital buildings. CvPlayer::hasOrbitalInfrastructure() was being called several million times, which chewed up the time.

Using the game SO posted as my test case, the timings are as follows:

Previous SVN version: 3995 seconds

After adding a cache to the orbital building count: 227 seconds (which is basically where it was a few versions ago before the orbital stuff went in, I think)

After also addressing another issue that the analysis revealed: 85 seconds

Enjoy!

If anyone finds any problems with recalculation not producing the right result (or the same result if run twice) let me know (it seems ok in my tests, but there could be special cases I guess).

I'm a bit too full of Thanksgiving cheer (aka Champaign) to do any more now, so the CTD will have to wait for another day.

I was afraid of that. What did I do wrong?

 

[strategyonly]

Using the game SO posted as my test case, the timings are as follows:

Previous SVN version: 3995 seconds

After adding a cache to the orbital building count: 227 seconds (which is basically where it was a few versions ago before the orbital stuff went in, I think)

After also addressing another issue that the analysis revealed: 85 seconds


I'm a bit too full of Thanksgiving cheer (aka Champagne) to do any more now, so the CTD will have to wait for another day.

Thank you!! Have fun!

I agree most heartily!! gobble gobble oops

Thx, and like i said dont worry too much about that CTD in viewports, i can wait, no biggy.

 

[DavidB1111]

Hey, I have a question, do the SVN updates break saves often, or is it rare?
I just want to know if I can update the SVN.

 

[Dancing Hoskuld]

Hey, I have a question, do the SVN updates break saves often, or is it rare?
I just want to know if I can update the SVN.

Almost never, and when they do we give plenty of notice. However changes may affect your game play.

 

[dusckr87]

Hey, I have a question, do the SVN updates break saves often, or is it rare?
I just want to know if I can update the SVN.

The answer was given, but I want to emphasize that you should not use the SVN to play, but a copy (export) of the SVN. That way, you can still update the SVN but will have a backup just in case the most recent SVN has problems. Note that if you do this you must delete the old "working copy" C2C folder when you do a new export (well, possibly not depending on the type of export (full vs versioned) but I always do to be safe as a full copy). Have your "main" SVN that you update in a separate folder (I use G:\temp\temp) and your working copy in the BTS\mods folder.

(I do overkill and not only export the SVN, but archive it as well as a 7z. I then delete minor versions later once I get a "stable" version, and then copy the stable versions to DVD. DVD is faster than download.)

 

[ls612]

Updates:

-More Airplane tweaks.

 

[Thunderbrd]

The answer was given, but I want to emphasize that you should not use the SVN to play, but a copy (export) of the SVN. That way, you can still update the SVN but will have a backup just in case the most recent SVN has problems. Note that if you do this you must delete the old "working copy" C2C folder when you do a new export (well, possibly not depending on the type of export (full vs versioned) but I always do to be safe as a full copy). Have your "main" SVN that you update in a separate folder (I use G:\temp\temp) and your working copy in the BTS\mods folder.

(I do overkill and not only export the SVN, but archive it as well as a 7z. I then delete minor versions later once I get a "stable" version, and then copy the stable versions to DVD. DVD is faster than download.)

You DO know you can use the SVN to revert to a previous version if the most recent update(s) are unstable right?

 

[Koshling]

I was afraid of that. What did I do wrong?

Nothing obvious really that you could have been expected to see without performance testing. Basically during modifier recalc it essentially rebuilds every building in every city *(about 65 thousand in SO's game). Each such build (and indeed several other things like tech acquisition, which is also replayed by recalc) calls updateBuildingCommerce() on each city. That in turn calls getOrbitalBuildingCommerceByBuilding() for every orbital building type defined (whether the city has it or not), and THAT unconditionally calls CvPlayer::countNumCitiesWithOrbitalInfrastructure() before checking if the requested building is present.

The net result is several million calls to CvPlayer::countNumCitiesWithOrbitalInfrastructure(), which itself loops through all cities, counting orbital infrastructure present (which is ANOTHER loop through every building type for every city).

I cached the result of CvPlayer::countNumCitiesWithOrbitalInfrastructure(), with a makeDirty method whenever an orbital infrastructure building is added/removed, which was the fix that essentially put things back to where they were before. I then also inhibited all commerce recalcation as a triggered result of other individual changes during the execution of the game-wide modifier recalc, and did an explicit call to do it one-time at the end, for the remainder.

 

[Dancing Hoskuld]

Update

- Move Balloon units and buildings into core.

 

[Koshling]

Just pushed to SVN (4332):

• Fixed the Great Wall display issues across save & load with viewports
• Fixed the city opened by next/prev or insert key when no city selected to be the one closest to the current view center

Note that the GW fix will not help existing saves that have displaced Great Walls within them (I cannot do anything about those), but they should prevent it happening for new games (or existing games in which the GW is not yet built).

For anyone interested in the gory details here's why it happened, and why I can't fix it for existing saves. First a little background:

• The graphics and tiles that comprise the GW are not handled by the DLL. They are handled directly by the game engine
• The API the game engine provides lets you add or remove a GW belonging to a specified city
• The game engine keeps its own data on the plots the GW runs through, and it adds that to saved game info outside of the control of the DLL
• During a viewport switch, which will change the coordinates (as far as the game engine is concerned) of everything , including the GW, we remove the GW (before the coordinate switch) and re-add it (after the switch) to get it correctly positioned

The problem lies in the fact that the game engine, outside of the control of the DLL, saves the GW positioning information in the save file. That means, that when it reloads the game, if the viewport is positioned differently to when it was saved (and it often will be), the positioning information it has for the GW is incorrect, so it paints it in the wrong place. At that point it is impossible to remove it, since the API forces you to specify a generating city to the game engine (to add or remove), and that generating city (even if it I within the load-time viewport, which it might not be) will generate a different set of coordinates and thus not (cleanly at least) remove the GW that was in the game engine's save data.

At first sight, this can be solved by saving the viewport information in the save and ensuring that the viewport is set on load to what it was on save. However, this is impossible too, since the viewport size (or even enablement) might be different when the game is loaded to when it was saved.

The fix I've adopted is to remove the GW at the start of the save process (so it's not present at all in the save game data), and re-add it after the save completes (and on load, which I already did anyway). This seems to work ok in my testing (though as mentioned it cannot rescue old saves), with the minor downside that the GW disappears and reappears (the animation plays so it's not instant, which again I cannot control) when the game is saved (including auto saves).

 

[Hydromancerx]

Updates
- Fixed Orchestron Theater. It had the old dye tags by mistake.