C2C SVN Changelog

[Thunderbrd]

Update

Removed the AutoPrereqHierarchy tag in reference to a method of assumed programming that represents an improvement in the Promotion Line concept without having to utilize the tag.

Note: was unable to compile the dll and will remain unable to until some odd problems in the code involving text displays for properties are repaired.

For reference, I'm having trouble with these lines in CvGameTextManager (I did not touch this file in my revision)

Spoiler :

	//Properties
	kBuilding.getProperties()->buildChangesString(szBuffer);
	kBuilding.getPropertiesAllCities()->buildChangesAllCitiesString(szBuffer);
	
	kBuilding.getPrereqMinProperties()->buildRequiresMinString(szBuffer, pCity ? pCity->getPropertiesConst() : NULL);
	kBuilding.getPrereqMaxProperties()->buildRequiresMaxString(szBuffer, pCity ? pCity->getPropertiesConst() : NULL);
	
	kBuilding.getPrereqPlayerMinProperties()->buildRequiresMinString(szBuffer, ePlayer != NO_PLAYER ? GET_PLAYER(ePlayer).getPropertiesConst() : NULL);
	kBuilding.getPrereqPlayerMaxProperties()->buildRequiresMaxString(szBuffer, ePlayer != NO_PLAYER ? GET_PLAYER(ePlayer).getPropertiesConst() : NULL);

	kBuilding.getPropertyManipulators()->buildDisplayString(szBuffer);

Approx line 17997.

Errors listed:

Spoiler :

1>CvGameTextMgr.cpp
1>CvGameTextMgr.cpp(18001) : error C2664: 'CvProperties::buildRequiresMinString' : cannot convert parameter 2 from 'const CvProperties *' to 'const CvProperties &'
1>        Reason: cannot convert from 'const CvProperties *' to 'const CvProperties'
1>        No constructor could take the source type, or constructor overload resolution was ambiguous
1>CvGameTextMgr.cpp(18002) : error C2664: 'CvProperties::buildRequiresMaxString' : cannot convert parameter 2 from 'const CvProperties *' to 'const CvProperties &'
1>        Reason: cannot convert from 'const CvProperties *' to 'const CvProperties'
1>        No constructor could take the source type, or constructor overload resolution was ambiguous
1>CvGameTextMgr.cpp(18004) : error C2664: 'CvProperties::buildRequiresMinString' : cannot convert parameter 2 from 'const CvProperties *' to 'const CvProperties &'
1>        Reason: cannot convert from 'const CvProperties *' to 'const CvProperties'
1>        No constructor could take the source type, or constructor overload resolution was ambiguous
1>CvGameTextMgr.cpp(18005) : error C2664: 'CvProperties::buildRequiresMaxString' : cannot convert parameter 2 from 'const CvProperties *' to 'const CvProperties &'
1>        Reason: cannot convert from 'const CvProperties *' to 'const CvProperties'
1>        No constructor could take the source type, or constructor overload resolution was ambiguous
1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"' : return code '0x2'

Whoever is working on this please resolve so I can compile! I've pushed my source changes so on the next compile they'll work appropriately.


NOTE TO XML MODDERS:
This recent change means that ALL non-Equipment, non-Affliction, non-Critical designated promotion lines WILL AUTOMATICALLY have an established prerequisite chain. Thus it will no longer be necessary to list Combat I as a prereq for Combat II, Combat II as a prereq for Combat III etc... its assumed! In fact, those prereq definitions that currently exist should be safely removable at this point (for cleanup's sake) and I'll eventually scrub the current prereq definitions in promotioninfos to reflect this and the rest of the new methods of establishing prereq definitions along lines.

 

[strategyonly]

changed back to last buildinginfo Praetyre replaced it with a modular one instead, just replacing it is all. Thx Desolator

 

[AIAndy]

Whoever is working on this please resolve so I can compile! I've pushed my source changes so on the next compile they'll work appropriately.

Have you updated your SVN properly? From the error it looks like you still have the old CvProperties.h but the new CvGameTextMgr.cpp.

 

[Koshling]

Have you updated your SVN properly? From the error it looks like you still have the old CvProperties.h but the new CvGameTextMgr.cpp.

I can confirm that AIAndy's latest changes compile fine for m, so the problem is definitely at your end TB.

 

[Koshling]

Just pushed to SVN (3741):

• Fixed a bug that caused all free promotions to be lost on unit upgrade
• A few efficiency tweaks to the promotion code
• Flagged promotions owned on load from saves by revisions older than this one, that we're not explicably present (from the XML), as being free (prevents Python-given promotions all vanishing when you load an old save)
• Fixed an out-by-one error in the retrain code that could result in a spurious extra retrain
• Fixed several CTDs with viewports (from debugging Shenryyr's games)
• Fixed reporting of the SVN version that the last loaded save is from on the flag hover

@Shenryyr: The viewport CTD fixes should hopefully help stabilize that aspect significantly (one fix was to a whole category of problems). If you continue to get crashes with the new version please keep posting the saves/minidumps. Many thanks for the ones you have provided so far.

 

[Hydromancerx]

Updates
- Housing (Homeless) reduced +8 unhealthy to +4 unhealthy.

 

[SteelSterling]

Updates
- All houses now build themselves when their requirements are met. Also added "Homeless" pseudo building if you do not have any houses built.

Needs major testing to see if it works. Please give feedback.

So far it is working. I was wondering why I was seeing those messages pop up! "The citizens of xxxx have built bark huts",etc.

 

[ls612]

Updates:

-Major changes to the Dog units.
-Added ~15 new Dog unit promotions.

NOTE: Some of the promotions may have pink icons, that will be temporary until Hydro makes all of the buttons.

 

[Koshling]

Actually had time to PLAY, fro the first time in a few weeks this evening, but I seemed to be losing an awful lot of fights I felt I shouldn't be, so...

...I reloaded the DEBUG version and debugged through the combat resolutions, and lo and behold - there was a serious bug that GREATLY favors the attacker over the defender in anything but an overwhelming fight (@TB - the combat loop was recalculating defender hit chances and damage-on-hit every round but not attacker ones, for which it continued to use the initial (undamaged) values).

Fixed in rev 3745.

 

[strategyonly]

Actually had time to PLAY, fro the first time in a few weeks this evening, but I seemed to be losing an awful lot of fights I felt I shouldn't be, so...

See what EVEN a little playing does

 

[Sgtslick]

Actually had time to PLAY, fro the first time in a few weeks this evening, but I seemed to be losing an awful lot of fights I felt I shouldn't be, so...

...I reloaded the DEBUG version and debugged through the combat resolutions, and lo and behold - there was a serious bug that GREATLY favors the attacker over the defender in anything but an overwhelming fight (@TB - the combat loop was recalculating defender hit chances and damage-on-hit every round but not attacker ones, for which it continued to use the initial (undamaged) values).

Fixed in rev 3745.

Ah so thats why a congo stone axeman defeated my tribal guardian across the river

 

[Hydromancerx]

Updates
- Added 3 new Anti-Crime buildings; Lookout Post, Sentry Post and Town Patrol.

 

[Thunderbrd]

Actually had time to PLAY, fro the first time in a few weeks this evening, but I seemed to be losing an awful lot of fights I felt I shouldn't be, so...

...I reloaded the DEBUG version and debugged through the combat resolutions, and lo and behold - there was a serious bug that GREATLY favors the attacker over the defender in anything but an overwhelming fight (@TB - the combat loop was recalculating defender hit chances and damage-on-hit every round but not attacker ones, for which it continued to use the initial (undamaged) values).

Fixed in rev 3745.

Oh hell! I just had to take a look at what you did to fix that and... how simple! Very nice work Koshling... I had thought the check to getDefenderCombatValues was also going to recalc attacker values but apparently I'm wrong. Truthfully, since getDefenderCombatValues doesn't ever 'return' any given values I'm not sure HOW it manages to change anything being read in the resolveCombat while loop. I kinda narrowed it down to 'something I don't understand about the use of the & symbol'. I can see how I completely missed that Attacker values weren't being recalculated then. Thank you so much for finding and fixing that!

On a side note, do you feel its impacting combat calculation performance too much for slower systems to have the recalculations taking place between rounds? Do you think this recalculating should be made optional? There's a number of effects that will be relying on this that would need to be disabled if its made optional and the option is off but I don't want to make it impossible to play on slower systems either.

BTW: I don't have any clue how I was having trouble with that failure to compile issue... At the time, I tried a clean recompile (deleting the whole final release folder and compiling once again), and updated twice to see if I could get it to right itself but I couldn't get past it last night. Now, after another update and clean recompile, I've been able to get it to get past that portion I was hung up on so... I dunno. But its working now so that's good.

 

[Koshling]

Oh hell! I just had to take a look at what you did to fix that and... how simple! Very nice work Koshling... I had thought the check to getDefenderCombatValues was also going to recalc attacker values but apparently I'm wrong. Truthfully, since getDefenderCombatValues doesn't ever 'return' any given values I'm not sure HOW it manages to change anything being read in the resolveCombat while loop. I kinda narrowed it down to 'something I don't understand about the use of the & symbol'. I can see how I completely missed that Attacker values weren't being recalculated then. Thank you so much for finding and fixing that!

The '&' means 'pass by reference not by value'. The difference essentially is that a type passed by value is essentially just copy, so any modifications made to it only change the copy that is in scope in the called method. Something passed by reference is actually the original itself, so any changes to I will change the original wherever it was being called from.

On a side note, do you feel its impacting combat calculation performance too much for slower systems to have the recalculations taking place between rounds? Do you think this recalculating should be made optional? There's a number of effects that will be relying on this that would need to be disabled if its made optional and the option is off but I don't want to make it impossible to play on slower systems either.

Combat calculations are not significant in the overall scheme of things (small fraction of 1% of the total turn time), so it's fine.

BTW: I don't have any clue how I was having trouble with that failure to compile issue... At the time, I tried a clean recompile (deleting the whole final release folder and compiling once again), and updated twice to see if I could get it to right itself but I couldn't get past it last night. Now, after another update and clean recompile, I've been able to get it to get past that portion I was hung up on so... I dunno. But its working now so that's good.

 

[Thunderbrd]

The '&' means 'pass by reference not by value'. The difference essentially is that a type passed by value is essentially just copy, so any modifications made to it only change the copy that is in scope in the called method. Something passed by reference is actually the original itself, so any changes to I will change the original wherever it was being called from.

From inference, I figured that was what was taking place there so its nice to hear it confirmed and better clarified. I guess, then, that it should have been visibly apparent that the attacker values were NOT passed by reference from the getDefenderCombatValues function. Makes sense though. Thanks!

 

[ls612]

Updates:

-Added some more Canine promotions
-Fixed Dog unit subcombats.
-Fixed the pink promotion buttons.

 

[Koshling]

Just pushed to SVN (3752):

• Fixed AI odds miscalculation when attacking with large stacks
• Fixed bug in game object expression textualization that could result in crashes (happened to me entering world-builder)
• Fixed promotions handed out by buildings

The first of the above was behind the AI's tendency to make suicide (or at least bad) attacks from large stacks.

Note - I have also found that the combat mod has thrown off the AI's assessment of odds (the multi-round nature of combat with strengths being recalculated each round means that the AI assessment routine mis-predicts quite badly). This will need to be fixed, and I'll try to sort it out tomorrow.

Edit - also pushed merge of Damgo's fix for the main screen Python (rev 3753)

 

[Hydromancerx]

Updates
- Administration type buildings no longer give Crime.
- Added Jade Gatherer and Amber Gatherer.
- Tweaked Aluminum Factory, Biofuel Refinery, Crafts Guild Hall, Deep Space Research Institute, Department of Motor Vehicles, Dike, Foundling Hospital, Maximum Security Prison, Nanite Lab, National Library Service, National Science Foundation, National Sports League, Radio Telescope, Recording Studio, Replicator Plant, Research Institute, Servants Guild Hall, Travel Agency, Victuallers Guild Hall and Woodcutter's Guild.

 

[Thunderbrd]

Update

Added PromotionLines to modules.

 

[Praetyre]

Updates

Stripped Aluminum Factory, Biofuel Refinery, Chemical Plant, Fertilizer Plant, Rubber Factory and Rubber Plant of National Wonder status.