Éa III, Sword & Sorcery: Developer's Thread

[Pazyryk]

It's a hard-coded solution to the problem that there is nothing in the database that links a feature to the build that removes it. So when you build a plantation on a resource that's in forest, you actually kick off two builds - BUILD_REMOVE_FOREST and BUILD_PLANTATION. BUILD_PLANTATION "knows" (from the BuildFeatures table) that it has to remove the forest but there is nothing to tell it what "build" does that.

The generic solution is to add a "RemovedBy References Builds(Type)" column to the Features table and then use that to work out what build is needed to remove feature X

Edit: Except that isn't going to work for Ea, as you have multiple ways to remove feature X (slash-and-burn or chop) depending on adopted tech. Going to need a FeatureRemove table with FeatureType, BuildType and TechType columns.

Too much speed posting -- can't keep up...

I can do the table. Is that easier than coding a "smarter dll AI" that can look for allowed remove builds and select one that works? Note that the mod only allows 1 for a player at a give time (it takes away the tech that allows slash-burn at the same time that it gives tech allowing the chop).

Edit: A GameEvents.CanBuild might simplify the situation here, so I wouldn't have hidden techs allowing/disallowing certain builds. Not sure if that helps with the AI discussion or not. But I thought I'd throw everything on the table for discussion.

Edit2: Strike above suggestion. A "BuildDisallow" tag in both Policies and Technologies tables would serve all my needs for Builds control.

Edit3: Strike above. Need new columns in Builds table: "PrereqPolicy", "DisallowTech" and "DisallowPolicy".

The other (possible) complication is that some civs (based on policy) can improve a given resource without removing a feature, others have to remove the feature. This all works fine for human. It would work also for AI if it was done generically by testing what builds could be done on a given plot. But now I suspect that is not the case.

 

[whoward69]

Too much speed posting -- can't keep up...

Sorry ... must stop "doing a Thal" (ie editing posts)

Is that easier than coding a "smarter dll AI" that can look for allowed remove builds and select one that works?

No, but it's more generic, so something that I'd be interested into coding into my DLL as a fix to Firaxis' hard-coding, which you can then lift into Ea

 

[whoward69]

Edit: A GameEvents.CanBuild might simplify the situation here, so I wouldn't have hidden techs allowing/disallowing certain builds. Not sure if that helps with the AI discussion or not. But I thought I'd throw everything on the table for discussion.

I already have one - GAMEEVENT_PlayerCanBuild in CvUnit.cpp

It wouldn't help the AI though as it only knows about the 4 standard "removes" so it wouldn't know how to "slash and burn" or "remove blight"

 

[Pazyryk]

Edit: Except that isn't going to work for Ea, as you have multiple ways to remove feature X (slash-and-burn or chop) depending on adopted tech. Going to need a FeatureRemove table with FeatureType and BuildType columns and then use the PrereqType column in Builds to sort out multiples.

All of this info is already in BuildFeatures. That table has: BuildType, FeatureType, PrereqTech and Remove. Well... except the problem there is that you have both the "pure remove builds" and the "remove improvement with remove builds" in that table. But that could be sorted out by adding one extra column: "RemoveOnly".

 

[whoward69]

I have a generic fix for the "what build removes this feature" problem (using the RemoveOnly column suggested and enhanced with an ObsoleteTech column) implement and it's working in my current game so I'll include it in tonights push of v45.

 

[Pazyryk]

@ls612,

I'm reworking the yield modifiers a bit. There were some problems with modifiers being applied in a non-additive way with base game modifiers (which should be avoided in general) and production and gold being screwy beyond that (these went through the roof in my test game). But there is a somewhat more complicated issue that the getBaseYieldRateModifier method does not just modify yield, but also generates UI text for the first 4 city yields.

I'll post a fix commit as soon as I test my changes.

 

[ls612]

@ls612,

I'm reworking the yield modifiers a bit. There were some problems with modifiers being applied in a non-additive way with base game modifiers (which should be avoided in general) and production and gold being screwy beyond that (these went through the roof in my test game). But there is a somewhat more complicated issue that the getBaseYieldRateModifier method does not just modify yield, but also generates UI text for the first 4 city yields.

I'll post a fix commit as soon as I test my changes.

Hm, I simply applied the modifiers to the methods Whoward gave me.

As for the non-additive modifiers, that is totally my bad, in C2C we had multiplicative modifiers for many things so I got used to doing things that way. Sorry for the mixup.

In other news, my college responsibilities will be a bit greater this week than normal, but I should still be able to look at some of the SQL and content work as well as merge Whoward's Generic Feature Removal stuff.

 

[Pazyryk]

Production is messy with overflow and other issues. I moved modification for Production, Food, Gold and Science to CvCity::getBaseYieldRateModifier. It's hard to track but all 4 get modifier from there (via methods that whoward69 listed). That method is also used in a rather weird way by CvLuaCity::lGetYieldModifierTooltip to get help text for these 4 yields. I moved a few other things around just to make UI implementation easier. It did help a lot to have the persistent parts already coded.

Just added commits for dll and non-dll mod.

 

[Pazyryk]

, but I should still be able to look at some of the SQL and content work as well as merge Whoward's Generic Feature Removal stuff.

I think it's better if you leave the feature removal stuff for me. The problem is that the mod's needs are not generic. Well some are (like removing feature to build improvment) but others are very mod-specific, such as how to properly fight the Living Terrain system. Only I really know how that needs to work.

I'd say keep working through the first list on the OP. I added one new item:

• New Builds tags: DisallowTech, PrereqPolicy, DisallowPolicy. Look for where PrereqTech is implemented and add extra checks there.

Also, I'd like to merge in whoward69's river connection system.

 

[ls612]

I think it's better if you leave the feature removal stuff for me. The problem is that the mod's needs are not generic. Well some are (like removing feature to build improvment) but others are very mod-specific, such as how to properly fight the Living Terrain system. Only I really know how that needs to work.

I'd say keep working through the first list on the OP. I added one new item:

• New Builds tags: DisallowTech, PrereqPolicy, DisallowPolicy. Look for where PrereqTech is implemented and add extra checks there.

Also, I'd like to merge in whoward69's river connection system.

OK. I would like to take a crack as some SQL stuff though once most of the DLL stuff is done.

 

[ls612]

I think it's better if you leave the feature removal stuff for me. The problem is that the mod's needs are not generic. Well some are (like removing feature to build improvment) but others are very mod-specific, such as how to properly fight the Living Terrain system. Only I really know how that needs to work.

I'd say keep working through the first list on the OP. I added one new item:

• New Builds tags: DisallowTech, PrereqPolicy, DisallowPolicy. Look for where PrereqTech is implemented and add extra checks there.

Also, I'd like to merge in whoward69's river connection system.

One issue I have found with the prereq tech stuff is that it's effects are strongly hinted to the AI in the DLL source code. I know that the Ea AI is handled in lua, but do you want me to point the AI in the right direction for at least the obsolete tech tag? Policy enabling would be another matter entirely, but I could hook the AI up to that as well if you wanted.

 

[Pazyryk]

One issue I have found with the prereq tech stuff is that it's effects are strongly hinted to the AI in the DLL source code. I know that the Ea AI is handled in lua, but do you want me to point the AI in the right direction for at least the obsolete tech tag? Policy enabling would be another matter entirely, but I could hook the AI up to that as well if you wanted.

Do you mean for Builds, or something else? My Lua handles policy and tech choices for civ, and movement and actions (including builds) for GPs only. For those, it's 100% determined by Lua so there is no point in helping on the dll side. But everything else is on the dll side, and obviously that needs help...

OK. I would like to take a crack as some SQL stuff though once most of the DLL stuff is done.

What part are you thinking about?

 

[whoward69]

Also, I'd like to merge in whoward69's river connection system.

Just when you think everything is tested and ready for the final build

[3249.157] TraitRiverConnection: OnCityConnected: 0 indirect Tobol'sk to Matsuyama
[3249.204] Runtime Error: MODS\Trait - River Connection (v 1)\LUA\RiverConnections.lua:508: attempt to index local 'segment' (a nil value)

 

[ls612]

Do you mean for Builds, or something else? My Lua handles policy and tech choices for civ, and movement and actions (including builds) for GPs only. For those, it's 100% determined by Lua so there is no point in helping on the dll side. But everything else is on the dll side, and obviously that needs help...

Tech prereqs for builds are specifically noted inside the DLL for tech decisions and AI strategies. At the very least the strategy code needs help for obsolete techs. If you are handling policy choices in lua and completely overriding the C++ AI for that then I don't need to touch that.

What part are you thinking about?

Favored policies and techs would be a good starting point. I'd also like (not now, but maybe during phase 4) to help design actual mechanics for the mod if that would be OK.

 

[Pazyryk]

AI strategies absolutely needs help. On the table side, look in CoreTables/AI.sql for the little bit of work that I've done. I have some Lua code that hooks up to the 3 GameEvents: City/Economic/MilitaryStrategyCanActivate. Right now it does nothing except provide feedback to Fire Tuner. We will probably need some dll modding here also.


Enabled Policies is probably the best area still for creative work. There is a long list in the Manual that need to be added to the Policies table (look for --Civ-Enabled). These all need effects, and only a few have been designed even (see Manual). Keep it simple.

After that, they need to be added to the table EaCiv_EnabledPolicies in EaTables/EaCivilizations.sql. These are added for The Graeae civ as an example. GridX, GridY in this table determine where each policy is displayed in the Civ-Enabled branch (overrides values from Policies table). Note that position of a policy can differ for each civ, which is needed because each civ has a different selection of these.

Here's what it looks like in-game for The Graeae (the only civ that hase its set so far). Note that they have to be arranged for each civ so that prereqs can be drawn correctly:

Spoiler :

Edit:
One other note on AI Strategies. There is probably a lot of processing time wasted on the "gods". The gods are just minor civs with MINOR_TRAIT_RELIGIOUS. They don't have any cities or units, so probably shouldn't be thinking about much at all. They are only there to give mana/resources to friends/allies and for quests. ("The Fay" are a hidden major civ with no cities or units, but we want to leave this player's AI mostly intact because they might get some hidden units later...)


Edit2:
You should be aware that I hate the "flavor system" for AI from the depths of my heart. I'm fine with AI's having leader-specific preferences when alternatives are similarly valuable. But the AI should just do what it needs to do when it needs to do it -- screw flavor. That's how I designed civ tech/policy choices. And guess what, there is more civ-differentiation without it. Initial choices, driven largely by local geography, set up small differences. At each stage these differences propagate into larger differences.

 

[Pazyryk]

@ls612, don't do the "New Promotions tag: Slaver" item. I'm going to implement this a little differently. (You need Slavery policy to capture civilians, so I'm just coding it that way.)

 

[ls612]

AI strategies absolutely needs help. On the table side, look in CoreTables/AI.sql for the little bit of work that I've done. I have some Lua code that hooks up to the 3 GameEvents: City/Economic/MilitaryStrategyCanActivate. Right now it does nothing except provide feedback to Fire Tuner. We will probably need some dll modding here also.


Enabled Policies is probably the best area still for creative work. There is a long list in the Manual that need to be added to the Policies table (look for --Civ-Enabled). These all need effects, and only a few have been designed even (see Manual). Keep it simple.

After that, they need to be added to the table EaCiv_EnabledPolicies in EaTables/EaCivilizations.sql. These are added for The Graeae civ as an example. GridX, GridY in this table determine where each policy is displayed in the Civ-Enabled branch (overrides values from Policies table). Note that position of a policy can differ for each civ, which is needed because each civ has a different selection of these.

Here's what it looks like in-game for The Graeae (the only civ that hase its set so far). Note that they have to be arranged for each civ so that prereqs can be drawn correctly:
<image removed>

Edit:
One other note on AI Strategies. There is probably a lot of processing time wasted on the "gods". The gods are just minor civs with MINOR_TRAIT_RELIGIOUS. They don't have any cities or units, so probably shouldn't be thinking about much at all. They are only there to give mana/resources to friends/allies and for quests. ("The Fay" are a hidden major civ with no cities or units, but we want to leave this player's AI mostly intact because they might get some hidden units later...)


Edit2:
You should be aware that I hate the "flavor system" for AI from the depths of my heart. I'm fine with AI's having leader-specific preferences when alternatives are similarly valuable. But the AI should just do what it needs to do when it needs to do it -- screw flavor. That's how I designed civ tech/policy choices. And guess what, there is more civ-differentiation without it. Initial choices, driven largely by local geography, set up small differences. At each stage these differences propagate into larger differences.

Thanks for the tips. I don't intend to go deep into the AI (I'll admit, I don't really understand most of it), but I will make the obvious adjustment for the tech obsolete builds.

@ls612, don't do the "New Promotions tag: Slaver" item. I'm going to implement this a little differently. (You need Slavery policy to capture civilians, so I'm just coding it that way.)

OK, I was assuming at any rate that the slaver mechanic would be something for after V3 release.

 

[Pazyryk]

OK, I was assuming at any rate that the slaver mechanic would be something for after V3 release.

No. Slave mechanics are already there and working in phase II. But the logic for unit capture was hanging on Events.SerialEventUnitCreated, which was both dangerous and very messy. I'm testing new capture system now and will have dll and non-dll commits soon if it works.

Let me know when/where you are making changes in the non-dll mod. I tend to make many changes and sometimes wholesale reorganization, so merge conflicts are a danger. This isn't a problem in dll since I tend to do very small incremental changes.

 

[S3rgeus]

Edit2:
You should be aware that I hate the "flavor system" for AI from the depths of my heart. I'm fine with AI's having leader-specific preferences when alternatives are similarly valuable. But the AI should just do what it needs to do when it needs to do it -- screw flavor. That's how I designed civ tech/policy choices. And guess what, there is more civ-differentiation without it. Initial choices, driven largely by local geography, set up small differences. At each stage these differences propagate into larger differences.

This is very interesting. You've found abandoning the flavor system adds variety to your opponents? Is that just wholesale off of the base game with new decision making processes or have you added any new weighting per leader/civ/location in some other ways?

 

[Pazyryk]

It's true in the Éa mod because the AI continues to look at cost/benefits based on what it already has. So,

1. Lot's of fish -> AI targets Fishing tech for the sake of food
2. AI has Fishing -> AI more likely to target Sailing because that would give it a name (a mod-specific goal) and it already has the prereq tech (making the cost for Sailing less that it would be otherwise)
3. AI achieves Sailing first and becomes the Fomhóire civ, allowing it to cross ocean (civ-specific trait).
4. AI can cross ocean so goes all Naval Expansion.

In truth, #4 isn't there yet. But #1-3 are in and working. There are also "scripted" tech/policy strategies that the AI can pick from, but again these are picked based on conditions (both initial and contingent), so allow differentiation based on how the game develops. Another thing that helps differentiation in the mod is a very "wide" tech tree.

If above concepts were applied to base, you would have emergent naval powers, horse-raiding civilizations, etc., that fit the natural geography. This is the way I've always wanted Civilization to work ever since they first introduced Civ-specific traits (was that II or III?). Hence the mod.