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

[Pazyryk]

Yep, that fixed it (for one civ so I'll assume the rest). New dll is in hotfix b already posted.

 

[timurbek]

I'm assuming, because this Sword & Sorcery mods DLL, that this mod won't run on Macs? Can anybody shed some light on this?

 

[ls612]

I'm assuming, because this Sword & Sorcery mods DLL, that this mod won't run on Macs? Can anybody shed some light on this?

That is correct. DLL mods will only run on Windows.

 

[Pazyryk]

@ls612 (or anyone else following the Github build),

The last 3 commits (everything since "v3 working") require Ea Media Pack v5, which isn't uploaded yet. So you can't make a functional build right now. I'll be that way until late tomorrow or the next day when I release v3.

 

[Pazyryk]

@ls612, I quickly synced with dll change right before uploading v3. Couple things,

1. It violates the mod norm by deleting lines and not using #ifdef's
2. The "player has lost capital" notification still happens (interestingly, it no longer has mouse-over text)
3. Something really weird happened in my first autoplay game. Starting exactly on turn 96 and thereafter, on each Barb turn GameEvents.PlayerPreAIUnitUpdate fires exactly 13 or 14 times consecutively for Barb player only. I don't know much more or whether barb was actually getting to play 13 turns. It's hard to imagine this isn't a dll bug (although we are constantly surprised). Game CTD'd after turn 145 - not sure if that is helpful though since it was messed up already on turn 96.

I'm running a new autoplay session to see if #3 happens again. I may hotfix back to previous dll (since we will need a dll hotfix anyway when 2nd notification removed).

Edit: Same exact issue (#3) on 2nd autorun, only it started on turn 98 this time. I'm going to revert back to last dll and start a new autorun.

Attached Minidump for the 1st overnight autorun crash.

 

[ls612]

@ls612, I quickly synced with dll change right before uploading v3. Couple things,

1. It violates the mod norm by deleting lines and not using #ifdef's
2. The "player has lost capital" notification still happens (interestingly, it no longer has mouse-over text)
3. Something really weird happened in my first autoplay game. Starting exactly on turn 96 and thereafter, on each Barb turn GameEvents.PlayerPreAIUnitUpdate fires exactly 13 or 14 times consecutively for Barb player only. I don't know much more or whether barb was actually getting to play 13 turns. It's hard to imagine this isn't a dll bug (although we are constantly surprised). Game CTD'd after turn 145 - not sure if that is helpful though since it was messed up already on turn 96.

I'm running a new autoplay session to see if #3 happens again. I may hotfix back to previous dll (since we will need a dll hotfix anyway when 2nd notification removed).

Edit: Same exact issue (#3) on 2nd autorun, only it started on turn 98 this time. I'm going to revert back to last dll and start a new autorun.

Attached Minidump for the 1st overnight autorun crash.

It isn't crashing in the DLL, it is crashing in the exe. This doesn't mean that it couldn't originate in the DLL, but it does mean that I can't glean any info from the minidump. I didn't touch the PlayerPreAIUnitUpdate in the last DLL update.

Re Notifications, I screwed up the capital one (sorry, I didn't have lots of time yesterday), I'll submit a change which fixes it. The reason I didn't #ifdef it is because it is more of a bugfix thing, but I've changed that now.

 

[Pazyryk]

No problem. I often look at diff file between Ea and Master for the "big picture" - and it's a little of a compulsion for me to have no deleted lines in there. (Actually, the practical reason is based on whoward69's description of merging a base dll update. It's still possible there will be one with BE I guess.)

I'm conducting a controlled experiment to see if new dll was to blame for #3 issue above. I reverted to last dll with hotfix and I'm now running autoplay. If no issue #3, then I'll blame it on dll change. I can imagine the crazy repetitive barb turns (if somehow from last dll change) causing exe crash ~50 turns later.


Edit: I've also seen cases in the past of new unit art causing CTD when unit appears in game (which I guess would be an exe crash). I thought I plopped all units in to look at, but I might have forgotten one or two in the new set.

 

[Pazyryk]

hotfix a just autoplayed to turn 436 for me. That's with dll from "Tech cost mod fix" commit. I'm going to build with the last pull request "Code convention fixes" and run another autoplay.

Edit: Notifications gone... that's good. If it holds up in autoplay I'll put this in next hotfix.

 

[Pazyryk]

@ls612, Are you interested in doing this?:

Player suggestion that I agree with: there should not be a warmonger penalty for DoW on (or taking cities from) a civ that is destroying the world. A similar situation comes up with Heldeofol. No one should mind you capturing/razing Heldeofol cities.

I have not looked at dll code for this yet, so I don't know best approach. But what comes to mind are two CallAccumulator GameEvents:

GameEvents.PlayerWarmongerForDOW(iOffensePlayer, iDefensePlayer, iDLLWarmonger)
GameEvents.PlayerWarmongerForCity(iOffensePlayer, iDefensePlayer, iDLLWarmonger, iCity [, numCitiesRemaining??])

On the Lua side we can either pass back the iDLLWarmonger or modify it or set it to 0.

I think that base only gives warmonger penalty for those two things. DOW is relatively minor but capturing a city is very severe, especially taking last city of a player (which is why conquering a CS is very bad).

The other thing that bothers me about base is that there is no penalty for razing cities. In my mind, this should be worse than conquering a city. There should be a penalty for each turn a population point is razed. Then we could modify that with a 3rd GameEvents similar to the above.

This way I can check for Fallen status or racial effects.

I think that there is only one "Warmonger value" for each player. So unfortunately we can't differentiate a case where Race A thinks player x is warmonger (because player x keeps attacking Race A) but Race B doesn't see player x as warmonger. That would be nice but I'm not sure it is needed. My idea now is that there will be no penalty for attacking Heldeofol. But Heldeofol will have total tolerance for warmongers, so it doesn't matter who you attack in their eyes (they hate you anyway from base race effect). But a Sidhe or Man civilization may become concerned if you are attacking either Sidhe or Man.


Edit: I suggested this in initial post as a sort of "patch" for warmonger not differentiating races. But I like this idea now as a mechanic separate from warmonger. The mod already has a Racial Dislike diplo effect: "We don't like your kind". But my idea now is that this value can raise over the course of a game. It raises based on any civ's (of Race A) actions against any other civ (of Race B). So all players will naturally have a growing animosity for other races, although it depends on a game's particular history. But dislike of Heldeofol will grow naturally depending on how many H civs and how successful they are in their conquests.

 

[ls612]

@ls612, Are you interested in doing this?:

Sure. I'm thinking a better way would be to just expose some diplo variables to Lua and then handle the warmonger changes in CityCaptured or something.

 

[Pazyryk]

Sure. I'm thinking a better way would be to just expose some diplo variables to Lua and then handle the warmonger changes in CityCaptured or something.

Maybe. But dll doesn't know about race or Fallen status or mana burned. And I don't want to have to tell you in advance (or recompile new dll) for any tweaks I want to make in those effect. Also, none of these events are happening many times a turn, so GameEvents overhead is inconsequential.

But this is speaking without looking at code yet. So let me know what you think after looking at how warmonger is implemented.

 

[ls612]

Maybe. But dll doesn't know about race or Fallen status or mana burned. And I don't want to have to tell you in advance (or recompile new dll) for any tweaks I want to make in those effect. Also, none of these events are happening many times a turn, so GameEvents overhead is inconsequential.

But this is speaking without looking at code yet. So let me know what you think after looking at how warmonger is implemented.

No, I could simply expose the DLL variables for warmonger penalties to Lua and have lua tell it new values. Most internal diplo variables aren't exposed, but there's no reason they can't be exposed if we want. Warmonger specifically works in a very odd fashion. It uses an enum internally, not a numeric value or penalty.

How about this, I'll create a flag on the player which indicates whether or not actions against that player create warmonger issues for the attacker, and expose that flag to lua. Then you can set it there and I can process things in the DLL based on whatever the value of the flag is.

 

[Pazyryk]

It uses an enum internally, not a numeric value or penalty.

That's weird. But the enums must have numerical values, right? NO_WARMONGER = 0, ..., CRAZY_WARMONGER = 4 ??? So then this is calculated based on a history of DoWs and city captures?

How about this, I'll create a flag on the player which indicates whether or not actions against that player create warmonger issues for the attacker, and expose that flag to lua. Then you can set it there and I can process things in the DLL based on whatever the value of the flag is.

How about an integer value from 0-100 representing percent effect? That way I can scale it for fallen based on mana consumed.

 

[ls612]

How about an integer value from 0-100 representing percent effect? That way I can scale it for fallen based on mana consumed.

Sure, that's fine. I'll make it this weekend.

 

[Pazyryk]

Sure, that's fine. I'll make it this weekend.

Sounds good. What about a city razing effect? Can you add that too? (To compensate for throwing on another warmonger effect, maybe reduce city capture effect by 50%...?)

 

[ls612]

An update on Warmonger stuff. The way warmonger is handled in diplomacy is more complicated than what is observed ingame. Each player has a separate warmonger assessment of each other player's warmonger threat (essentially how much of a threat that a player going berserk would create for you). This means that to get the effect for all players some spaghetti code is required, and above all this change WILL be breaking for saves. I'll have it done today or tomorrow, and then some testing will be in order, as this is a major change.

 

[Pazyryk]

An update on Warmonger stuff. The way warmonger is handled in diplomacy is more complicated than what is observed ingame. Each player has a separate warmonger assessment of each other player's warmonger threat (essentially how much of a threat that a player going berserk would create for you). This means that to get the effect for all players some spaghetti code is required, and above all this change WILL be breaking for saves. I'll have it done today or tomorrow, and then some testing will be in order, as this is a major change.

v5 will break saves anyway.

I had assumed one warmonger value per player, but one for each pair of players gives us lots of flexibility. I'm not trying to push you back in this direction, but doesn't that argue for the GameEvents approach?

Edit: I just made my last dll commit for v5. I finally killed unit maintenance messiness (it's straight 1 gpt per unit regardless of turn and unit number) and finally got visibility working for Seeing-Eye Glyph. It's well-tested in long autoplay.

 

[ls612]

v5 will break saves anyway.

I had assumed one warmonger value per player, but one for each pair of players gives us lots of flexibility. I'm not trying to push you back in this direction, but doesn't that argue for the GameEvents approach?

No, it would support making it an array of values instead of a single value. But using existing game events fired by the DLL should still be a better plan (so you would set the lua methods to run on the DOW event or city capture event or whatever).

 

[Pazyryk]

I released v5 because new spells were ready, and I won't be able to mod much this week (I can still do hotfixes). Both repositories are up to date on Github.

I figured I'll need to do some Lua work to support new dll diplo functionality, and that will take a while. So that can be v6 probably.

 

[ls612]

I released v5 because new spells were ready, and I won't be able to mod much this week (I can still do hotfixes). Both repositories are up to date on Github.

I figured I'll need to do some Lua work to support new dll diplo functionality, and that will take a while. So that can be v6 probably.

OK, sounds good to me. I've just finished cleaning up the new code and will be testing it shortly, I ended up being able to avoid some of the more convoluted solutions and limit the impact of the change to only affecting DOW and city capture contributions to warmonger scores.