C2C SVN Changelog

@TB (mainly):

I was getting an assertion failure about out of range unitCombat indexes. It turns out to be this piece of code you modified in rev 5600:

Code:
		for (int iI = 0; iI < GC.getNumUnitCombatInfos(); iI++);
		{
			iMultiplier += getUnitCombatProductionModifier((UnitCombatTypes)iI) / 4;
		}

The compiler REALLY should warn about this sort of thing (but it's technically valid C++ and the compiler isn't picky enough to warn). Anyway, I'll edit this post with exactly what was wrong in 24 hours - until then it's left as an exercise for the reader (though I'll fix it in my SVN push later today).

Edit - PS - I suspect this explains the hang and also why some people get it and some don't (think uninitialized memory)
Now this is interesting because I did note this and struggled against it trying to figure out what the heck could possibly be causing this. As I look at it it's still fine from what I can see and I brought it up elsewhere here (can't recall where atm) to see if I could get some assistance on the issue. You said 'think uninitialized memory' but how could this possibly have been hitting something uninitialized? By uninitialized, I presume we're talking about the GC.getNumUnitCombatInfos() value but once loaded, how could that be in any way uninitialized?

Just pushed to SVN (5658):
  • Fixed CTD associated with river crossing defense changes
  • Fixed concurrency issue that could lead to CTD
  • Optimized assessment of buildable improvements

...and additionally in second update (rev 5659):
  • Fixed potential CTD
  • Fixed specialists in captured cities disappearing on recalc
Can you let me know what I did wrong with the river defense changes? And I'm curious to know what was causing the specialist disappearances.

All in all, great work Koshling! We've missed you! :goodjob:
 
Update

- Fix the city hover over pink icons. I forgot that if you have white space anywhere in the name or folder of an icon that it will show up as a pink square in hover over mode! As would currently be happening if you had slave specialists. SO this means you will need to remove the old icons form your FPK version. I would not update the FPK yet as I may get to do a few more before the freeze. ;)

- Can now settle slaves as the new slave specialists but you wont get rid of them yet as I am still testing that bit of code.
 
SO this means you will need to remove the old icons form your FPK version. I would not update the FPK yet as I may get to do a few more before the freeze. ;)

- Can now settle slaves as the new slave specialists but you wont get rid of them yet as I am still testing that bit of code.

:lol: yeah i found that out after doing 2 of them, and then you added even more, so "You Betcha" i will wait :p
 
Update

- New slave specialists now fully mostly working. (Rats, forgot about what happens when you capture a city with slaves when you aren't running slavery and what happens when you raze/abandon a city with slaves :blush::sad:)
 
Now this is interesting because I did note this and struggled against it trying to figure out what the heck could possibly be causing this. As I look at it it's still fine from what I can see and I brought it up elsewhere here (can't recall where atm) to see if I could get some assistance on the issue. You said 'think uninitialized memory' but how could this possibly have been hitting something uninitialized? By uninitialized, I presume we're talking about the GC.getNumUnitCombatInfos() value but once loaded, how could that be in any way uninitialized?

The issue was the ';' at the end of the line with the 'for' statement:
Code:
for (int iI = 0; iI < GC.getNumUnitCombatInfos(); iI++);
This terminates the stamen, making the loop JUST what is specified in the 'for', and the subsequent (intended) 'loop body' is just a sequentially following statement that happens to be enclosed in curly braces (so it has it's own scope, which doesn't have any impact here). The net effect is that the loop executes and leaves iI set to on past the end of the valid range for combat infos. It is then used in the following statement (the one that was INTENDED as a loop body), which causes the assertion failure. If you tell it to continue (or anyway in anything but the DEBUG version) it will attempt to use the 'modifier value' that happens to be in the memory past the end of the array - this is (for all intents and purposes) uninitialized and will either crash (if it's not valid memory) or (much more likely) return a random modifier (so could explain reports of crazy modifier values).

The fix was just to move the spurious ';' (so a one character fix)

Can you let me know what I did wrong with the river defense changes? And I'm curious to know what was causing the specialist disappearances.

You checked whether something was a city or not using a function that returns true for a true city OR a fort (actsAsCity), and then used the pointer returned by plotCity() without checking for NULL (which it will be in the case of a fort), resulting in a CTD.
 
Just pushed to SVN (5664):
  • Fixed end of turn hang reported by StrategyOnly
  • Significant optimization to calculation of stranded units (situational bottleneck shown by SO's save)
 
The issue was the ';' at the end of the line with the 'for' statement:
Code:
for (int iI = 0; iI < GC.getNumUnitCombatInfos(); iI++);
This terminates the stamen, making the loop JUST what is specified in the 'for', and the subsequent (intended) 'loop body' is just a sequentially following statement that happens to be enclosed in curly braces (so it has it's own scope, which doesn't have any impact here). The net effect is that the loop executes and leaves iI set to on past the end of the valid range for combat infos. It is then used in the following statement (the one that was INTENDED as a loop body), which causes the assertion failure. If you tell it to continue (or anyway in anything but the DEBUG version) it will attempt to use the 'modifier value' that happens to be in the memory past the end of the array - this is (for all intents and purposes) uninitialized and will either crash (if it's not valid memory) or (much more likely) return a random modifier (so could explain reports of crazy modifier values).

The fix was just to move the spurious ';' (so a one character fix)
Ugh... it's the little typos that get me. At least this one comes with a particular behavioral indicator that now that I know that was the problem I will more quickly see the error if I ever run into it again.



You checked whether something was a city or not using a function that returns true for a true city OR a fort (actsAsCity), and then used the pointer returned by plotCity() without checking for NULL (which it will be in the case of a fort), resulting in a CTD.
Ah... crud. oops. I'll watch out for that then when using plotCity(). Thanks for the expo!
 
Just pushed to SVN - emergency fix (rev 5667)
  • Fixed broken unit counting which results in the ability to create multiple national units.
  • Fixed an issue with AI building evaluation that caused it to tend not to build things with bad properties when the property concerned is currently negative!! (e.g. - wouldn't build smokehouse when air pollution was negative)

The unit counting bug was due to a typo (oops) I made yesterday. IT WILL HAVE BROKEN ANY GAME PLAYED WITH YESTERDAY'S BUILD - YOU MUST REVERT TO AN OLDER SAVE once you get the fixed version.
 
With the latest update to the source forge code I have to enter my password 4 times to read (ie update my work copy) but only once to write (ie commit). Does this mean I have something wrong in my set up? If so can anyone suggest what it is that is wrong?
 
Just pushed to SVN (5672):
  • Fixed end of turn hang reported by Talin
  • Reinstated default threading of 4 (needs testing more now the common bugs are fixed)
  • Fixed an AI bug that caused it to build research while there were still worthwhile buildings
  • Improved city AI slightly to better evaluate commerce bonuses (will now build river port in city with a lot of river tiles much faster for example)
 
With the latest update to the source forge code I have to enter my password 4 times to read (ie update my work copy) but only once to write (ie commit). Does this mean I have something wrong in my set up? If so can anyone suggest what it is that is wrong?

Nope its correct, infact i have a ticket to them saying just that, but they told me to read and do this, but i cant, its too much for me (ADHD)

https://sourceforge.net/p/forge/site-support/4523/

someone else need to make heads or tails of it, sorry.
 
Nope its correct, infact i have a ticket to them saying just that, but they told me to read and do this, but i cant, its too much for me (ADHD)

https://sourceforge.net/p/forge/site-support/4523/

someone else need to make heads or tails of it, sorry.

If you followed the instructions in the first post for modders then you will already be using svn+ssh as am I. So that part we are doing correctly.

The rest just says that their software does not provide a solution to the need for entering the password many times. In fact it causes the problem. The fix is to install yet another bit of software. That software remembers your password for you for the time of the connection to the SVN. At least I hope it is only for the period of the session. that is as far as I got.
 
The rest just says that their software does not provide a solution to the need for entering the password many times. In fact it causes the problem. The fix is to install yet another bit of software. That software remembers your password for you for the time of the connection to the SVN. At least I hope it is only for the period of the session. that is as far as I got.

Thats what i thought, but i can only do 2-3 lines then my mind wonders, thx.

EDIT: Fixed pink event for ori's tarpit

EDIT EDIT:
changed unit art for Maya holkan to jav type

changed Lightning Warrior to Obsidian type club

changed cuirassier to currassier folder (different looking unit) then
changed the carabineer to the cuirassier type

Duplicate Cannon entry deleted
 
Back
Top Bottom