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

[Pazyryk]

1. Why do you want the getter for the city and civ-wide yield percent modifiers to be sent to lua? I am already processing the effects of that method in the DLL.

UI

Edit: OK, yes I should know value since I set it from Lua. But the issue there is persisting data in Lua. We do it but it's easier and safer to get the persisted value from dll rather than persist parallel values in dll and Lua.

2. Do you have sample Lua code I could use to test my addition of these methods?

Get yer Fire Tunner up and running...

Players[0]:SetLeaderYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)
Plaerys[0]:GetCapitalCity():SetCityResidentYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)

The itemized yields won't be right in UI (unitl I mod it with the Get methods) but the bottom line totals should be responding to your changes.


Edit2: I posted our release date on the mod thread (April 13). No pressure there. I have some time over spring break so I'm feeling optimistic. And things have been moving very fast the last couple weeks.

 

[ls612]

UI

Edit: OK, yes I should know value since I set it from Lua. But the issue there is persisting data in Lua. We do it but it's easier and safer to get the persisted value from dll rather than persist parallel values in dll and Lua.

Get yer Fire Tunner up and running...

Players[0]:SetLeaderYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)
Plaerys[0]:GetCapitalCity():SetCityResidentYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)

The itemized yields won't be right in UI (unitl I mod it with the Get methods) but the bottom line totals should be responding to your changes.


Edit2: I posted our release date on the mod thread (April 13). No pressure there. I have some time over spring break so I'm feeling optimistic. And things have been moving very fast the last couple weeks.

Sounds good to me.

Re release date, that seems slightly optimistic to me. April 13 is 24 days away, and we still have a lot of actual content which is needed, on top of the code changes. I'm specifically concerned about the new spells, enabled policies, and civ traits which need to be designed. How about waiting until the 27th or so?

 

[Pazyryk]

I'm inspired by some autoplays running out to turn 400 or more. I'll get enough spells in, and I can get through the "content finishing" section if I can resist adding new mechanisms.

 

[whoward69]

Minor quest Lua support: GameEvents.AllowMinorQuest(iMajor, iMinor, questID) CallTestAll.

At the end of CvMinorCivAI::IsValidQuestForPlayer()

You might also want to add one to the end of CvMinorCivAI::IsValidQuestCopyForPlayer() (just stick a bCopy param on the end of the previous event) and, for completeness, events to the end of CvMinorCivQuest::IsComplete(), CvMinorCivQuest::IsExpired() and CvMinorCivQuest::IsRevoked()

 

[whoward69]

A Lua method to add a specific quest will be needed too (just port whatever dll method does this).

Just need to expose CvMinorCivAI::AddQuestForPlayer() to the Lua API, but if you want a player to be able to join an existing global quest (eg culture race) when the player encounters the CS you'll also need to expose CvMinorCivAI::AddQuestCopyForPlayer()

 

[whoward69]

[*]Rivers make internal city connections with Fishing tech (or with building enabled by tech). whoward69 is working on this so wait and copy his solution.

Planning to upload this over the weekend (probably late Sunday UK time). Check v45 of the code base for MOD_EVENTS_CITY_CONNECTIONS along with the "Trait - River Connection" mod.

If the map can change (ie rivers shift or lakes come/go), you'll (possibly) also want the MOD_EVENTS_TERRAFORMING code

 

[Pazyryk]

Thanks whoward69 for all the help!

Some new items on the OP under Additional DLL and AI. Actually, all 3 items are related to problems from hard-coding in dll for Builds, specifically "remove feature" type builds. There's BUILD_SCRUB_FALLOUT. That at least makes sense to me as kind of a special situation. But there are other places where the other "remove feature" builds are hard-coded. One method involving human popup has the features hard-coded by type string and the corresponding remove builds hard-coded by table ID integer. The former is OK for us (the base 6 features are hard-coded in the graphics engine, so we can't code around that anyway), but the Builds table IDs are fatal for the mod.

 

[ls612]

Get yer Fire Tunner up and running...

Players[0]:SetLeaderYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)
Plaerys[0]:GetCapitalCity():SetCityResidentYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)

The itemized yields won't be right in UI (unitl I mod it with the Get methods) but the bottom line totals should be responding to your changes.

I must be doing something wrong with FireTuner, becuse I'm getting this error:

Runtime Error: _cmdr = {Players[0]:GetCapitalCity():SetCityResidentYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)}:1: attempt to index global 'players' (a nil value)

when I use the Lua console.

Also, it would appear that while my lua plot rejection code is working, the UI is confused about it (see the attached picture).

 

[whoward69]

and the corresponding remove builds hard-coded by table ID integer.

I assume you're referring to this cr*p in CvUnitMission.cpp

/// Queue up a new mission
void CvUnitMission::PushMission(UnitHandle hUnit, MissionTypes eMission, int iData1, int iData2, int iFlags, bool bAppend, bool bManual, MissionAITypes eMissionAI, CvPlot* pMissionAIPlot, CvUnit* pMissionAIUnit)
{
  // Update Builder Resource info
  if(eMission == CvTypes::getMISSION_BUILD())
  {
    FeatureTypes eFeature = hUnit->plot()->getFeatureType();
    if(eFeature != NO_FEATURE && pkBuildInfo->isFeatureRemove(eFeature) && pkBuildInfo->getFeatureTime(eFeature) > 0)
    {
      CvFeatureInfo* feature = GC.getFeatureInfo(eFeature);
      MissionData removeMission;
      removeMission.eMissionType = eMission;
      if(iData1 != 15 && strcmp(feature->GetType(), "FEATURE_FOREST") == 0)
      {
        removeMission.iData1 = 15; // todo: future proof this
      }
      else if(iData1 != 14 && strcmp(feature->GetType(), "FEATURE_JUNGLE") == 0)
      {
        removeMission.iData1 = 14; // todo: future proof this
      }
      else if(iData1 != 16 && strcmp(feature->GetType(), "FEATURE_MARSH") == 0)
      {
        removeMission.iData1 = 16; // todo: future proof this
      }
      else if(iData1 != 17 && strcmp(feature->GetType(), "FEATURE_FALLOUT") == 0)
      {
        removeMission.iData1 = 17; // todo: future proof this
      }
    }
  }
}

Unfortunately, nothing Firaxis does in the code no longer surprises me

 

[whoward69]

I must be doing something wrong with FireTuner, becuse I'm getting this error:

Runtime Error: _cmdr = {Players[0]:GetCapitalCity():SetCityResidentYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)}:1: attempt to index global 'players' (a nil value)

when I use the Lua console.

The default context for the FireTuner console IIRC is "MainMenu" (drop down top left), which is part of the front end code, so knows nothing about the Players object/table. You need to change it to InGame or WorldView (I use the latter as it's the second one up from the bottom and a heck of a lot easier to find than InGame which is in the middle)

 

[Pazyryk]

I must be doing something wrong with FireTuner, becuse I'm getting this error:

Runtime Error: _cmdr = {Players[0]:GetCapitalCity():SetCityResidentYieldBoost(GameInfoTypes.YIELD_PRODUCTION, 50)}:1: attempt to index global 'players' (a nil value)

when I use the Lua console.

That error line appears to contradict itself (see "P" versus "p" for Players). "Players" is defined if you are in the proper Lua state. Make sure you select EaMain, then click lock state so you won't have to again.

[Edit: whoward69 beat me to post. That line would work from any "mod state", which is anything other than the default ("Main"?). But if you need to run a mod function (like the mod's built-in "Autoplay") these are almost all in state: "EaMain" (except for UI files which each have their own state).]

Also, it would appear that while my lua plot rejection code is working, the UI is confused about it (see the attached picture).

It's OK. Borders are allowed to spread over sea resources and features (other than Ice).

 

[whoward69]

Just a heads up, there is a missing call to the CanAcquirePlot event in the code that calculates the costs of plots, it's not a show-stopper, just makes plots slightly more expensive in cities that can't buy plots (eg water/mountains) in rings 1 or 2. Fix will be in v45.

 

[ls612]

It's OK. Borders are allowed to spread over sea resources and features (other than Ice).

No, the two UIs (the main graphical one and the minimap) are disagreeing, that is the problem.

 

[Pazyryk]

I assume you're referring to this cr*p in CvUnitMission.cpp

Spoiler :

/// Queue up a new mission
void CvUnitMission::PushMission(UnitHandle hUnit, MissionTypes eMission, int iData1, int iData2, int iFlags, bool bAppend, bool bManual, MissionAITypes eMissionAI, CvPlot* pMissionAIPlot, CvUnit* pMissionAIUnit)
{
  // Update Builder Resource info
  if(eMission == CvTypes::getMISSION_BUILD())
  {
    FeatureTypes eFeature = hUnit->plot()->getFeatureType();
    if(eFeature != NO_FEATURE && pkBuildInfo->isFeatureRemove(eFeature) && pkBuildInfo->getFeatureTime(eFeature) > 0)
    {
      CvFeatureInfo* feature = GC.getFeatureInfo(eFeature);
      MissionData removeMission;
      removeMission.eMissionType = eMission;
      if(iData1 != 15 && strcmp(feature->GetType(), "FEATURE_FOREST") == 0)
      {
        removeMission.iData1 = 15; // todo: future proof this
      }
      else if(iData1 != 14 && strcmp(feature->GetType(), "FEATURE_JUNGLE") == 0)
      {
        removeMission.iData1 = 14; // todo: future proof this
      }
      else if(iData1 != 16 && strcmp(feature->GetType(), "FEATURE_MARSH") == 0)
      {
        removeMission.iData1 = 16; // todo: future proof this
      }
      else if(iData1 != 17 && strcmp(feature->GetType(), "FEATURE_FALLOUT") == 0)
      {
        removeMission.iData1 = 17; // todo: future proof this
      }
    }
  }
}

Yep. That's the one I found in my initial search. I haven't looked carefully beyond that.

My posts about this in the To Do list may be a little confusing (due to my exasperation as I was finding this). Before doing anything, we should make sure we understand the existing code (which I don't yet) and the mod's specific needs. For the mod, we have these "feature removal" Builds:

BUILD_SCRUB_BLIGHT
BUILD_SLASH_BURN_FOREST
BUILD_SLASH_BURN_JUNGLE
BUILD_CHOP_FOREST
BUILD_CHOP_JUNGLE
BUILD_REMOVE_MARSH

All are coded properly on Lua/DB-side and work, but dll side AI doesn't know what to do with them due to hard-coding issues. Just some notes for clarification:

1. BUILD_SCRUB_BLIGHT should work pretty much like the base BUILD_SCRUB_FALLOUT but recognizing the new FEATURE_BLIGHT. In this case, replacing the existing hardcoding of "FALLOUT" for "BLIGHT" seems like the simplest (if not most elegant) way to go.
2. The "chops" versus "slash-burns" are a mod feature. Chops give production yield. Slash-burns are lower tech (for jungle) or no-tech (for forest) versions that clear the feature but don't give production. There's no AI needed for chop versus slash-burn since a player looses ability to do slash-burn when it gains ability to do chop. So that's not a problem. But I don't think AI can do some of these at all due to hard-coding on type strings, so can't remove features as needed to build improvements (that's from autoplay observation; again, I haven't looked closely at C++ code yet).

 

[whoward69]

No, the two UIs (the main graphical one and the minimap) are disagreeing, that is the problem.

When did you last actually play a game (as opposed to testing mods)? The minimap has never shown spread over water

 

[Pazyryk]

No, the two UIs (the main graphical one and the minimap) are disagreeing, that is the problem.

That's a puzzler. OnCityCanAcquirePlot returns true for that plot, but it does for all the land plots too, so I don't see how that could be the culprit.

Is this from a recent Ea_III_Sword_and_Sorcery build, after the "Incorporated CityCanAcquirePlot..." commit? The Lua kludge before that involved a lot of setting and unsetting of plot ownership.

When did you last actually play a game (as opposed to testing mods)? The minimap has never shown spread over water

Last summer. But I don't always see the gorilla in the room while I'm playing.

 

[ls612]

That's a puzzler. OnCityCanAcquirePlot returns true for that plot, but it does for all the land plots too, so I don't see how that could be the culprit.

Is this from a recent Ea_III_Sword_and_Sorcery build, after the "Incorporated CityCanAcquirePlot..." commit? The Lua kludge before that involved a lot of setting and unsetting of plot ownership.

Yes, it is from my testing build with that new method enabled.

Also, new pull request coming for the city and player-wide yield percentage modifiers.

 

[ls612]

When did you last actually play a game (as opposed to testing mods)? The minimap has never shown spread over water

July? That would certainly explain it.

 

[Pazyryk]

Also, new pull request coming for the city and player-wide yield percentage modifiers.

Excellent! This will allow me to remove a whole mess of hidden policies and buildings. I'll test this out and add any Lua needed for itemized yields in UIs (city and top panel).

 

[whoward69]

Before doing anything, we should make sure we understand the existing code

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 and BuildType columns and then use the PrereqType column in Builds to sort out multiples.