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

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.

Honestly I think that having hard(ish)coded flavors makes the game more interesting. If you are playing against Alexander you should be at war all of the time for instance. Maybe in Ea it should be an issue of saying 'leader X wants to become a horse-lord, therefore he/she aggressively pursues horse resources on the map'.
 
'leader X wants to become a horse-lord, therefore he/she aggressively pursues horse resources on the map'.
That's the flavor system in a nutshell. The problem I have is that the window of opportunity is too short to be wanting what you don't have (and can't get very quickly). You end up with a civ that has metals but wants horses, and a civ that has horses but wants metals. And neither really excels at anything.

So just flip your statement: 'leader X has horse resources on the map [not necessarily in borders, but near enough to obtain in early game], therefore he/she aggressively wants to become a horse-lord,'. Now you have a civ that excels in horse-related development. And the other civ with metals excels in infantry.
 
@Pazyryk: Are you intending to make route build which have an obsolete tech/policy? If so that will be a whole lot of extra code which I don't want to write unless you plan on using it.
 
@Pazyryk: Are you intending to make route build which have an obsolete tech/policy? If so that will be a whole lot of extra code which I don't want to write unless you plan on using it.
No plans for route Builds obsoleting. Only improvement Builds.

Some examples:
-Bronze Working enables Forest Chop but disallows Forest Slash-Burn (chop is better because it gives production).
-Iron Working enables Jungle Chop but disallows Jungle Slash-Burn
-Pantheism (policy) disallows all chops and slash burns

Also, many individual improvements have two Builds: One for Pantheistic civs (allows the build in a feature without removal) and one for non-Pantheistic (build with removal).

Right now this is all controlled by a bunch of hidden techs that are turned on/off by Lua: TECH_AGRICULTURE_NO_PAN, TECH_AGRICULTURE_PAN, etc. So it's another massive Lua/Table kludge that I want to clean up.
 
No plans for route Builds obsoleting. Only improvement Builds.

Some examples:
-Bronze Working enables Forest Chop but disallows Forest Slash-Burn (chop is better because it gives production).
-Iron Working enables Jungle Chop but disallows Jungle Slash-Burn
-Pantheism (policy) disallows all chops and slash burns

Also, many individual improvements have two Builds: One for Pantheistic civs (allows the build in a feature without removal) and one for non-Pantheistic (build with removal).

Right now this is all controlled by a bunch of hidden techs that are turned on/off by Lua: TECH_AGRICULTURE_NO_PAN, TECH_AGRICULTURE_PAN, etc. So it's another massive Lua/Table kludge that I want to clean up.

Sounds good then. I'll have the new tags ready for a pull either tonight or tomorrow morning.
 
@ls612,

My apologies for spying on your work before a pull request. You're still missing the logic of CvUnit::canBuildRoute() as of commit "More small fixes for build restrictions". It is supposed to return true if the unit can build any route. So you need "continue" statements in your rejection tests, and a return true in that block if nothing rejects (only one route type has to pass).

I was checking in because improvement builds weren't working after the initial pull request (I hadn't even tested routes yet). I couldn't find the logic flaw in improvement builds, but I spotted the problem with the route builds. (It's possible that I created the improvement build problem on the Lua/table side.)
 
@ls612,

My apologies for spying on your work before a pull request. You're still missing the logic of CvUnit::canBuildRoute() as of commit "More small fixes for build restrictions". It is supposed to return true if the unit can build any route. So you need "continue" statements in your rejection tests, and a return true in that block if nothing rejects (only one route type has to pass).

I was checking in because improvement builds weren't working after the initial pull request (I hadn't even tested routes yet). I couldn't find the logic flaw in improvement builds, but I spotted the problem with the route builds. (It's possible that I created the improvement build problem on the Lua/table side.)

Hm, Improvements were working for me in my test game. I'll look again and see, there might be something simple I missed.
 
Hm, Improvements were working for me in my test game. I'll look again and see, there might be something simple I missed.
It was after your first commit last night (when you had the ||'s instead of breaking into 4 tests).

I just fixed CvUnit::canBuildRoute logic in a commit. Try to sync up before you proceed. (At least I know how to do manual merges now ... so I'm not as scared as I was before.)

Edit: Don't do the table add. I've already done that and made use of new tags. Non-dll commit coming soon if it all works in test. (And the file is renamed to UnitBuilds.sql since that's what it is. Will show in repository as 1 new file and 1 deleted file.)

Edit 2: Tested and everything working now. New commits for both dll and non-dll mods.

Edit 3: Btw, I still don't see any feedback from EA_DEBUG or CvAssertMsg. It doesn't appear in my VS2010 output window (the window where the compiler feedback prints?). Is there something I can do to fix this?

Edit 4: First AI fix for feature removal Builds is committed. OMG there is some bad coding in CvUnitMission::PushMission: hard-coded table IDs and text string matching rather than using existing enums defined in the same method.

Edit 5: Weeeee!!!! AI is really thriving now in autoplay. Not sure if all problems are fixed, but the difference is very apparent by turn 60.
 
@ls612, do you want to do the dll-side fix for "UNIT_WORKER" hard-coding?

Mostly these can be fixed by a new Units tag "IsWorker" and then adding isWorker() method in dll. I'll go ahead and prep for a solution by adding IsWorker tag and setting it for the 6 worker units.

There are at least two methods where you need to know the proper worker type for a given Minor player. I'll code this information into the MinorCivilizations table with a new column: "WorkerUnitType". Note that some Minor civs are "gods" (not even on the map) and this tag will be NULL. I'm not sure whether the relevant methods ever get called for these. But it may be best to figure out a safe way to deal with this. (NULL in table becomes eUnitType == NO_UNIT on the dll side.)
 
@ls612, do you want to do the dll-side fix for "UNIT_WORKER" hard-coding?

Mostly these can be fixed by a new Units tag "IsWorker" and then adding isWorker() method in dll. I'll go ahead and prep for a solution by adding IsWorker tag and setting it for the 6 worker units.

There are at least two methods where you need to know the proper worker type for a given Minor player. I'll code this information into the MinorCivilizations table with a new column: "WorkerUnitType". Note that some Minor civs are "gods" (not even on the map) and this tag will be NULL. I'm not sure whether the relevant methods ever get called for these. But it may be best to figure out a safe way to deal with this. (NULL in table becomes eUnitType == NO_UNIT on the dll side.)

Sounds good to me. I can get that done over the weekend.

By the way, in a test game I had yesterday there were a LOT of TXT errors (mainly related to technologies). Is there a reason why when a free tech is chosen at game start there is a popup implying that tech shouldn't have been visible?
 
Sounds good to me. I can get that done over the weekend.
Great! I just committed new non-dll changes with 2 new table tags:
IsWorker in Units (boolean)
WorkerUnitType in MinorCivilizations (text, see note on NULL cases above)


By the way, in a test game I had yesterday there were a LOT of TXT errors (mainly related to technologies).
Most (all?) are missing Help text. And all are missing Quote. For Quotes, I'm thinking about removing them entirely. Alternatively, I could mod popup to not even try to show if Quote is NULL, and only show when non-NULL value is added to table. (Maybe someone someday will write ~100 tech quotes for us.) I don't particularly want to do help texts until all the specific effects are settled and the Game Manual correctly reflects actual game mechanic. Then they can all be added/updated at one go.

Is there a reason why when a free tech is chosen at game start there is a popup implying that tech shouldn't have been visible?
Hidden techs are given by various Lua code. Unfortunately these show up in tech research panel as the last tech researched. The "SHOULD NOT BE VISIBLE" text is to remind me to do something about this some day (it's a UI Lua coding issue that could be solved with some work).

"there is a popup" --Do you mean an actual popup? Or just the last tech researched information in tech selection? If the former, there is something wrong with your build.
 
The "plot effects" system (Glyphs, Runes and Wards) is in now. See details here. It has a pretty sweet UI system with toggle-able highlighting, colored by specific effect type: Protective Ward (blue); Seeing Eye Glyph (yellow); Explosive Rune (red); Death Rune (black).

The Explosive Rune spell is fully functional (except for AI) in last commit. I'll give it some rudimentary AI so they will cast it around their own big cities and move on to the other 3 plot effect spells. It should be pretty easy after that to code Reveal Glyphs, Runes and Wards and Dispel Glyphs, Runes and Wards.
 
"there is a popup" --Do you mean an actual popup? Or just the last tech researched information in tech selection? If the former, there is something wrong with your build.

The attached picture shows what happens. The first tech I click on is given for free (is that intended?) and shows that popup (I don't know if it is an actual BUTTONPOPUP).
 

Attachments

  • 8930_2014-03-29_00002.jpg
    8930_2014-03-29_00002.jpg
    110.3 KB · Views: 71
Race Man gets a free tech at game start.

The SHOULD NOT BE VISIBLE is the Quote, which as I said will be removed. And yes, the help text isn't added yet.

What's strange though is that you don't have a pasture showing up there, since that's a build for Domestication (and I just tested that is is present for me). Are you sure you have a current build for the non-dll mod? Pasture would have been missing before the "Incorporated new Builds tags" commit, which was ages ago (OK, only 2 days ago but 6 commits).


Edit:

I'm still not able to access feedback from dll. Asserts don't go to my VS2010 output window. It's particularly important now because I'm seeing a new CTD out past turn 200. Possibly related to a change I made to allow a particular negative yield (but I hate to troubleshoot with no feedback).
 
Race Man gets a free tech at game start.

The SHOULD NOT BE VISIBLE is the Quote, which as I said will be removed. And yes, the help text isn't added yet.

What's strange though is that you don't have a pasture showing up there, since that's a build for Domestication (and I just tested that is is present for me). Are you sure you have a current build for the non-dll mod? Pasture would have been missing before the "Incorporated new Builds tags" commit, which was ages ago (OK, only 2 days ago but 6 commits).


Edit:

I'm still not able to access feedback from dll. Asserts don't go to my VS2010 output window. It's particularly important now because I'm seeing a new CTD out past turn 200. Possibly related to a change I made to allow a particular negative yield (but I hate to troubleshoot with no feedback).

IIRC asserts go in the assert.log file. If you want to see output in the Debug window use the EA_DEBUG method (it uses C-style output formatting with a couple things I added on).

That was an old build, but it has been that way since I started working with Ea.
 
IIRC asserts go in the assert.log file.
I don't see any asserts.log in the Logs directory, or anywhere on my computer for that matter. I've looked through all the logs in the Logs folder and none look like they are coming from dll.

If you want to see output in the Debug window use the EA_DEBUG method (it uses C-style output formatting with a couple things I added on). .
So it works like a print statement in Lua? I guess I thought you'd have a "hello I'm loading statement" or something. I'll try using it and see if something prints to my output window.

it has been that way since I started working with Ea.
I'm still unclear about the problem you are referring to. The Quote text? The help text? The missing pasture? Or something else?
 
So it works like a print statement in Lua? I guess I thought you'd have a "hello I'm loading statement" or something. I'll try using it and see if something prints to my output window.

Oh, in that case just use the OutputDebugString() macro (or check the output window to see what DLLs are being loaded). EA_DEBUG is if you want to have integer values from various variables in your output, like saying for instance "This unit now has 3 Strength". It uses sprintf internally (so C-style output formatting), and then adds on stuff like the newline and which class the message is for.

Also, if you are getting random(ish) CTDs you can find the CvMinidump file in the base Civilization 5 folder. If you place that dump in the same folder as the PDB for the DLL you can then open the dump in Visual Studio and view the state of the program when it crashed.
 
I don't see any asserts.log in the Logs directory, or anywhere on my computer for that matter. I've looked through all the logs in the Logs folder and none look like they are coming from dll.

Well that is strange, I had the assert.log in the Logs folder last week and assumed that it was where assert messages go, but it isn't there now. :confused: I think others (whoward for one) have gotten it to work by following the instructions in CvAssert.h, maybe I did something wrong. I'll look into it.

Edit: Whoops, I found that file and it isn't Civ 5 related at all. :hammer2: I need to get more sleep before I look at this further.
 
Back
Top Bottom