Hydromancerx
C2C Modder
Updates
- Added 5 new Crimes.
- Applied Disease property to various Science mod buildings.
- Added 5 new Crimes.
- Applied Disease property to various Science mod buildings.
C2C SVN Changelog
- Thread starter Dancing Hoskuld
- Start date
Dancing Hoskuld
Deity
Update
- Preview of Sevo's Faces of God mod (inactive).
This needs the python converted before it becomes active and that will have to wait until I have the Extra Diplomacy python working.
- Preview of Sevo's Faces of God mod (inactive).
This needs the python converted before it becomes active and that will have to wait until I have the Extra Diplomacy python working.
Updates
- Added TAG_PEAK, TAG_HILL, TAG_FLATLAND, TAG_OWNED and TAG_CITY to Is tag for boolean expressions.
- Added TargetCondition to property propagators, a boolean expression that filters the propagator targets.
- Crime property diffusion is now only active in owned plots (so crime can only diffuse to plots right outside the border).
- Disease property diffusion is now only active in owned plots and can only diffuse to owned plots.
- Air pollution property does not diffuse to peaks now (so peaks serve as a diffusion barrier).
- Water pollution property can now only diffuse to river, water, farm or city plots.
- Fixed two display bugs in civics.
Just pushed some fairly major AI changes to SVN (rev 3144). This is a significant change so I expect it will need tweaking. Let me know if you see strange effects:
1) Changed the basis for how defended a city is, from number of defending units, to total strength (accounting for promotions) of the defending units
2) Changed the required floating defender strength (which used to be just a unit count) to a strength, and added a once per turn city AI routine to check if the city is not fully defended by this measure, and if not contract for units to join it with a priority proportional to the city threat level
3) Changed the unit contracting system to allow a strength to be contracted for, which allows potentially multiple units to respond to a single contract (partially fulfilled contracts have their required strength reduced by the amount fulfilled, and their priority reduced by the proportion fulfilled, which should mean if many cities are competing the available units divide between them in somewhat the correct proportions
4) Enhanced the city threat measure to better detect border distances, presence of enemy troops (or non-ally troops to a lesser extent), and border tensions. This should increase the distinction between interior and border cities relative to the previous system
What you **SHOULD** see is less concentration of AI defensive units around their interior cities, and more in their border cities, especially high-tension or war borders.
It currently only applies to defenders, so loitering attack stacks that are not really doing much are not (yet) addressed by this change, but the same mechanisms can (and I intend to do this too) be employed to make the distribtuion of attack troops more appropriate.
@Thunderbrd - the routine that evaluates unit strength in a batlle-context-free manner (CvUnitAI::AI_genericUnitValue()), when assessing the 'strength' for defensive or aggressive purposes is new, and takes account of promotions - it's inner loop (which evaluates a particular promotion) should probably be a common subroutine shared with promotion evaluation code, which I know you are working on. It should also ideally be common with AI_promotionValue() - it's just separated currently because:
i) I didn't want to mess with the promotion evaluation code when I knew you were modifying it
ii) I specifically need the promotion value as a multiplier on base strength, not an arbitrary interger value that can only be used to compare against other promotions. AI_promotionValue() is just this arbitrary integer currently. Ideally it would use (a more fleshed out version of) my new routine to generate its valuation, so that we don't have two independent sets of promotion valuing code longer term.
Note that it WOULD need fleshing out because it doesn't take account of all factors of all promotions yet - just the ones that mattered most for what I was doing.
1) Changed the basis for how defended a city is, from number of defending units, to total strength (accounting for promotions) of the defending units
2) Changed the required floating defender strength (which used to be just a unit count) to a strength, and added a once per turn city AI routine to check if the city is not fully defended by this measure, and if not contract for units to join it with a priority proportional to the city threat level
3) Changed the unit contracting system to allow a strength to be contracted for, which allows potentially multiple units to respond to a single contract (partially fulfilled contracts have their required strength reduced by the amount fulfilled, and their priority reduced by the proportion fulfilled, which should mean if many cities are competing the available units divide between them in somewhat the correct proportions
4) Enhanced the city threat measure to better detect border distances, presence of enemy troops (or non-ally troops to a lesser extent), and border tensions. This should increase the distinction between interior and border cities relative to the previous system
What you **SHOULD** see is less concentration of AI defensive units around their interior cities, and more in their border cities, especially high-tension or war borders.
It currently only applies to defenders, so loitering attack stacks that are not really doing much are not (yet) addressed by this change, but the same mechanisms can (and I intend to do this too) be employed to make the distribtuion of attack troops more appropriate.
@Thunderbrd - the routine that evaluates unit strength in a batlle-context-free manner (CvUnitAI::AI_genericUnitValue()), when assessing the 'strength' for defensive or aggressive purposes is new, and takes account of promotions - it's inner loop (which evaluates a particular promotion) should probably be a common subroutine shared with promotion evaluation code, which I know you are working on. It should also ideally be common with AI_promotionValue() - it's just separated currently because:
i) I didn't want to mess with the promotion evaluation code when I knew you were modifying it
ii) I specifically need the promotion value as a multiplier on base strength, not an arbitrary interger value that can only be used to compare against other promotions. AI_promotionValue() is just this arbitrary integer currently. Ideally it would use (a more fleshed out version of) my new routine to generate its valuation, so that we don't have two independent sets of promotion valuing code longer term.
Note that it WOULD need fleshing out because it doesn't take account of all factors of all promotions yet - just the ones that mattered most for what I was doing.
Thunderbrd
C2C War Dog
I believe I may have added a modification or two to CvUnitAI::AI_genericUnitValue() as well so that part should make the merge interesting. I had a few values that were generically nearly as important as strength that I felt needed that kind of base consideration. But I don't think it should be too tough to merge in if I'm following you correctly. It was a fairly simple adjustment.
What you're talking about is interesting. Does this mean, then that you're having units evaluated somewhat on their potential promotions, even if they aren't promoted yet? I know you were saying something about that in regards to the dog units earlier. I may need to omit any changes there in the merge and just quickly report to you what I was trying to do.
But if I had you do it NOW it would fault out as the tags aren't in place in the svn yet. Kinda a catch 22 situation. I'm sure we'll work it out ok when I get to merging, which will probably be either next weekend or the weekend after for the dll side of things. Still have a few more bits to wrap up here but they are all quite simple... just time consuming.
I also have some ai issues that need a bit stronger coding than I could provide it because it would also have created too great a changes in light of some of your plans. So we're bleeding over each others territories a bit here and we should have a chat soon about how to keep from incidentally stepping on each others toes. I'm not unhappy in any way, of course, with what you've changed. As I said, its a minor overlap anyhow. I'm sorry my delays are holding you up in any way as well.
Dancing Hoskuld
Deity
Updates
- Some animal buildings can now be captured.
- Space and deep space terrain added.
- Some animal buildings can now be captured.
- Space and deep space terrain added.
That would be a good trick, since it's a brand new method I just added!
No, just their current ones. When BUILDING new units I (think) the evaluation takes account of the avaliable promotions, but when moving units aroun to respond to defense requests it just looks at the units's current capabilities.
It's not holding me up, so np.
@DH - Python for civics was done last September: http://forums.civfanatics.com/showpost.php?p=10909992&postcount=594
Dancing Hoskuld
Deity
Sorry I must have missed it. Does it work if more than one civic is changed at a time? You example suggests not. (Edit2: unless you are raising an event for each change)
Edit since Civic is not an object defined in the python elsewhere what are its methods?
Edit3: Looks like I am having a BUG problem with this event, but everything has gone "pear shaped" in my working version, so it is time to step back and go back to the SVN for a new working version.
Civic is not an object as you say, so it has no methods. The event fires for every category of civic that is changed in the overall change that gets made. It's nearly a year since I did it, so I don't really remember any more than that. I'll have a play with it tomorrow and add a test handler that adds a message or something as an exampe, for usage.
Edit - Er - actually the old post I linked above has example usage from my original tests. That example shows it retrieving the civic info to display a messag about what changed. Is there more you need to know?
Dancing Hoskuld
Deity
By how much and will you be increasing the research times to compensate? As I mentioned elsewhere I thought the build times on both were fine. I managed to build the infrastructure for and build a small army (8 attach, 4 siege and a healer unit + baggage train of (story teller + defender + missionaries + animals).
Construct times were only bumped 25%, and unit train times were doubled. Now the iconstruct and iTrain are equal for each supported gamespeed. Both numbers are well below the iResearchModifier for their respective gamespeeds, so I don't think compensation will be necessary. If I find otherwise, I'll do some more tweaking when I get back from vacation.
strategyonly
C2C Supreme Commander
Changed Rome GG to look at a PRAETORIAN
and deleted duplicate Egyptian GG
and deleted duplicate Egyptian GG
Hydromancerx
C2C Modder
Updates
- Updated my FPK.
- Added 5 new Seafood buildings.
- Updated my FPK.
- Added 5 new Seafood buildings.
GiuseppeIII
The Third Giuseppe
Duplicate Egyptian GG?
