Gods and Kings API Documentation Changes

I mean, the reason my own mods are dead (and at this point, likely to remain that way) is that they decided to alter how RunCombatSim works, to the point where most of the things I'd used it for in the past will no longer function. If they'd wanted an event with the functionality of the new-and-improved RunCombatSim, they should have just created another event with different characteristics, and used that instead. But instead, they broke any mod relying on the old system. It's just bad programming.
To be fair, I think they "just" didn't anticipated the implication of the change to the unit animation system.

That doesn't change the lethal effect it has for some mods like your's, WWII is on hold waiting for answers/solution/DLL and my planned combat mod is dead in the egg.

edit: or what's new and improved in RunCombatSim ?
 
I suspect the whole "event" sub-system saw a major change in the 674 patch to a more classical queue based system than a mechanism to enable cross-context calling of methods.

Pre-674, if you built an improvement within code being executed from the SerialEventImprovementCreated (or whatever it's called) event that built a new improvement on top of the just created improvement, you got the sequence Create-A, Create-B, End-Create-B, End-Create-A, Destroy-A, End-Destroy-A (ie method calling sequence), you now get the sequence Create-A, End-Create-A, Destroy-A, End-Destroy-A, Create-B, End-Create-B (ie classical queue sequence) - looking at the changes to RunCombatSim/EndCombatSim and the lack of an EndCombatSim if a unit dies (which means you don't need to update the unit in the vacated hex) it fits a classical queue based model
 
Placing a resource (either via Lua or LiveTuner) within the bounds of a city no longer enables buildings requiring that resource to be built - so if you drop 4 Horses on any tile already worked by a city and then improve them (either via FireTuner or a worker) you won't be able to build either the Circus or the Stables in that city.
 
Placing a resource (either via Lua or LiveTuner) within the bounds of a city no longer enables buildings requiring that resource to be built - so if you drop 4 Horses on any tile already worked by a city and then improve them (either via FireTuner or a worker) you won't be able to build either the Circus or the Stables in that city.
This is not new actually, the first versions of IGE encountered that problem almost one year ago.

What you must do is to remove the tile ownership, then set it again. BUT, if the tile is worked by the city, it will cause a permanent yield bug on the city. So you must first take care to remove the "worked" flag, then remove ownerhsip, then add ownership, then restore worked tiles. Since the API to deal with worked flags is not convenient at all and since you may have (as I did) misconceptions about that system because of how previous civ titles worked, I suggest you save you time and look at IGE's code: it's in IGE_API_Terrain.lua, at the beginning of the file. You need to look at the UpdateOwnership function, feel free to just copy/paste it.
 
Is it only worked tiles? Because I've been happily dropping resources into city limits from FireTuner for testing since almost day 1 and unless I've never bothered to look (possible but unlikely) I don't ever remember hitting this before.
 
Is it only worked tiles? Because I've been happily dropping resources into city limits from FireTuner for testing since almost day 1 and unless I've never bothered to look (possible but unlikely) I don't ever remember hitting this before.
* The "yield" bug always occurred if you canceled ownership of a worked tile. And only under those circumstances.
* The "resource incompletely taken into account" bug always occurred on all tiles, whether they were worked or not, at least to a certain extent: the marble's construction speed bonus for wonders, for example, was never granted (unless you reset ownership). But I could not say about horses and circus and other buildings' requirements. Happiness and the amounts of strategic resources, however, were always correctly updated afaik.
 
edit: or what's new and improved in RunCombatSim ?

Nothing that I could see. It does just appear to be caused by the new animation systems, with no actual added functionality. The thing is, they fundamentally changed the timing, especially on EndCombatSim; when an AI player takes his turn, it'll resolve the RunCombatSim events for ALL combats he initiates, and then once all combats are done, it'll resolve all of the EndCombatSim events at the same time. Even if they changed the animation system, that new timing is just really strange.

Basically, we just need someone to give us GameEvent hooks. One that triggers before combat damage is finalized, and one that triggers afterwards. With those, we can do all of the things we need, but without them, we're stuck. Hopefully, once the DLL is available someone will find a way to create those hooks for us.
 
Has anyone done any more experimenting with "GetScenarioDiploModifier1(ePlayer1, ePlayer2)"?

I would like certain civilizations, both minor and playable, to have an extra negative or positive diplomatic modifier that would be ongoing. For example, I want my viking civilizations in my scenario to never be too friendly with certain city states or major civs (such as anglo-saxons).

If someone has worked out some sort of template for doing this, I'd like to see how they did it.
 
Did you see Gedemon's post about it (#14 in this thread)? I do not think there is much more to tell, aside of figuring out what are the arguments (something you can do through print). Also you could look at the scenarios provided with G&K, I think one of them use those functions.
 
It did. He added 50 and removed 2x50 points of influence. The only problem on his picture is that he didn't bother defining the text keys (you create a XML file, add those two keys - look at IGE's en_us.xml if you want an example, set VFS to true for that file and, in the project settings, actions, update the game database with it on mod activation).
 
Files that update the game database (either XML or SQL) do not need VFS=true (it won't cause problems but is not needed)

Edit: "it won't cause problems" - actually I lie. If you have picked the same name as an existing xml file (eg CityView.xml) it will cause huge problems!
 
Has anyone run into problems ordering units to move? With the new patch (vanilla, not G&K) all of my unit move commands stopped working. These were just unit:PushMission( ... ) statements.

I probably should troubleshoot in the Tuner before posting. But I was hoping someone else (Gedemon?) may have seen this and solved it already...
 
I've got no report this was broken in the WWII mod, but I haven't tested it more than a few turns yet. it's for AI or human player ? both ?
 
AI. I really haven't troubleshot this at all yet. But I got a clear indication that AI units weren't moving after I got back from vacation (after patch) when they were moving before. It's possible that it's an indirect effect of something else that has gone wrong. I just need to try a PushMission via the tuner to see if it still works (perhaps this weekend).


Edit: Never mind. Works fine from tuner. I must have some upstream error that is causing this.
 
I've been experimenting with:

"GetScenarioDiploModifier1(ePlayer1, ePlayer2)"

A few issues:

- The text does not show up on the diplomatic screen. The UI may have to be altered.

- The text does show up when talking to the individual leaders. However, general leader attitude does not change. This may be a matter of the UI not adjusting. I've tried as high as +100, but the leader attitude remained neutral even though the text I associated with "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" appeared in green.

- Using the same "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" works for multiple situations... I think the only difference between "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" and "GetScenarioDiploModifier2(ePlayer1, ePlayer2)" is only in the text. I used "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" twice for the same leader but with different values and different ePlayer 2, and both instances worked at the same time. The command is not as limiting as we may have suspected. Mods would likely only clash in the event of differing text strings... I don't know what would happen in that event.
 
- Using the same "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" works for multiple situations... I think the only difference between "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" and "GetScenarioDiploModifier2(ePlayer1, ePlayer2)" is only in the text. I used "GetScenarioDiploModifier1(ePlayer1, ePlayer2)" twice for the same leader but with different values and different ePlayer 2, and both instances worked at the same time. The command is not as limiting as we may have suspected. Mods would likely only clash in the event of differing text strings... I don't know what would happen in that event.

This is the way these events work. What you are doing is writing a function (or any number of functions) for the dll to call whenever it needs to calculate diplo relationships. It's just like GameEvents.PlayerCanConstruct can be used to put any condition on any building (except that wants a true/false return). The dll calls this whenever it needs to know if a building can be built, for human and AI.
 
Here's a weird error. I'm converting my total conversion mod over to G&K (I finally have it "running", at least). The top panel is showing me the Maya calendar, and Players[0]:IsUsingMayaCalendar() returns true. I checked the DB and there is certainly no trait in my game that has MayaCalendarBonuses, nor are there any traits that could possibly have the same ID as the Long Count in base (if by any chance the devs encoded this in dll by ID).
 
Here's a weird error. I'm converting my total conversion mod over to G&K (I finally have it "running", at least). The top panel is showing me the Maya calendar, and Players[0]:IsUsingMayaCalendar() returns true. I checked the DB and there is certainly no trait in my game that has MayaCalendarBonuses, nor are there any traits that could possibly have the same ID as the Long Count in base (if by any chance the devs encoded this in dll by ID).

I encountered this problem when making my mod too. I solved it by keeping TRAIT_LONG_COUNT in the game (it's not used by any civs; to avoid invalid reference errors I also removed its tech prerequisite, because TECH_THEOLOGY doesn't currently exist in my mod). Here is the SQL code that I used:

Code:
DELETE FROM Traits WHERE Type <> "TRAIT_LONG_COUNT"; -- need to keep it to prevent using the Maya calendar for all civs
UPDATE Traits SET PrereqTech = NULL; -- remove Theology as PrereqTech for the Long Count
 
Back
Top Bottom