Era of Miracles fantasy mod - developer diary

[Ahriman]

Why are you so negative about adding the retreat promotion to some units?

Because I don't think the mechanic as designed is fun.
Effects that have a large impact but fire randomly just aren't very fun.

Hard hitting units that are weak on defense should be weak on defense. You should be punished for leaving a lancer unit vulnerable out in the open, it shouldn't have a get-out-of-jail free card. A withdraw chance just rewards bad play.

Its very frustrating to attack units and just have them instantly teleport away without consequences.

Why not both?

Because that would make them very very frustrating to try to chase down.

 

[PawelS]

Sorry for lack of post in the last days, for a few days I was ill and lying in bed most of the time instead of using the computer, and after that I got busy with my non-civ related projects and RL issues. So my daily posts in this thread are suspended for now, but I'll still answer other people's posts, and someday (sooner rather than later), I'll resume working on the mod and posting here regularly.

@Spatz: If I understand it correctly, to scan one hex, the game loads an entire database containing data about all hexes. If it's true, that's a real waste of computer's resources.

@Ahriman: The argument about the randomness is a good point, I don't like too much randomness. But I still think it's a fun feature, and it makes sense - fast moving units should have a chance to avoid being attacked in melee. Of course when testing shows that it isn't fun, it will be removed.

 

[Spatzimaus]

@Spatz: If I understand it correctly, to scan one hex, the game loads an entire database containing data about all hexes. If it's true, that's a real waste of computer's resources.

It's just the behavior of a typical non-indexed database. There are a few indexing functions (if you have a hex, you can quickly find which city is working it or which city is closest), but there are quite a few linkages that are conspicuously absent. Most relevant here, while there IS a function within the Players structure that can tell you how many improvements of type X are within a certain player's territory, there's no "where" command to allow you to easily get a sublist containing only the plots with that improvement. That is, most languages have something like:
index = where(Plot:ImprovementType == "IMPROVEMENT_FARM", count)
where "index" becomes an array of indices for all plots that meet that condition, and "count" is how many matches there were. ("count" will be the same as the number of elements in "index", which most languages can easily extract, but if there were no matches many languages will return a 1-element null-valued array anyway.) Lua has the equivalent of the "count" part, but not the where.

So without that sort of thing, you end up doing a lot of brute-force searching through arrays. It's very wasteful on time, but it's pretty clear the devs only added the specific Lua functions that they needed for their own work, ignoring the things we the modders would need to expand on their design. With the DLL it wouldn't be hard to implement whatever functions we needed, but who knows when that'll happen.

 

[PawelS]

I'll need a list of hexes with a specific improvement for my Prospecting Facilities searching for new resources - is there any reasonable way to do it?

(I program in C++ so I know that index/count thing, too bad it's not implemented in this case).

 

[Spatzimaus]

I'll need a list of hexes with a specific improvement for my Prospecting Facilities searching for new resources - is there any reasonable way to do it?

Not that I've ever found. My mod's had Terraforming code for almost a year now, a mechanism that functions by placing a temporary Improvement on the map, searching for that Improvement, and then wherever I find that improvement I do whatever terrain/resource/feature changes need to be done, and remove the improvement. Given that, I've obviously had an interest in increasing the efficiency of these sorts of searches. But so far, I haven't seen anything better than a loop over the entire map.

There are a few ways to gate the search so that it doesn't waste too much time; I check to see if any players have any improvements in that class (and since they're removed in the process, it'll then only search the whole map if it knows there's at least one hex to change on that particular turn), you can limit it by techs/eras, and when searching the actual hex the first thing to check is whether it's water (since I have no sea-based terraforming). But in the late game, when there's nearly always at least one hex terraformed on each turn, it's a noticeable slowdown, especially on larger maps.

(I program in C++ so I know that index/count thing, too bad it's not implemented in this case).

This is why I have hope for the DLL. It really isn't a hard concept to manage, and the underlying languages generally have all of the tools we need to add in these functions. But with what we have now, it's just really hard to do certain things effectively.

 

[PawelS]

Hmm, the Prospecting Facilities should only give a chance to find new resources, so I think I can just check a random set of hexes every turn, and if they contain, or are adjacent to such improvement, and have no resources, then I can make a resource appear there. I guess it will take less time than checking all hexes every turn.

 

[Ahriman]

Sorry for lack of post in the last days, for a few days I was ill and lying in bed most of the time

Hope you're feeling better!

But I still think it's a fun feature, and it makes sense - fast moving units should have a chance to avoid being attacked in melee

I guess my perspective is: they do, its called move after attack. They can move out of range. I guess I prefer this kind of evasion to be a tactical issue that the player controls (by not over-extending and making sure they have enough movement to move out of range) rather than something that just triggers automatically/randomly.

On prospecting:
As a clueless non-programmer this might be stupid, but: is it worth specifically storing which tiles have a prospector improvement when those are created, and then checking only those tiles?
Another possibiliy would be: have the prospector as a rare, hard to get unit, and then have it automatically/instantly create a resource at random when you trigger, rather than Civ4 style chance per turn (which never really worked that well as a mechanic IMO).

 

[Spatzimaus]

That'd be very hit-or-miss in terms of balance. I mean, if you're playing on a decent-sized map there might be ~10,000 hexes on the map. Each of those improvements you described would only cover an area of 7 hexes, assuming no overlap, so to get a reasonable number of successes over the course of a game, you'd need to select several hundred random hexes each turn. You quickly reach a point where it's not worth it to use that sort of shortcut.

Now, there ARE several ways to avoid that.
1> In my terraforming code, one of the actions is the "Deep Mine". It's an improvement that, upon completion, is replaced with a random resource. I still search the whole map, but since it's removed as soon as it's built, I won't need to do this every turn.
2> Store the number of Prospecting Facilities each player has in a global array in Lua. If the number is the same as on the previous turn, there's no need to search the map. (But if this is something multiple players can build, that doesn't work well, since the answer will pretty much be "yes" on every turn.)
3> Loop over your cities, and check the area from (x-5:x+5,y-5:y+5) which means ~100*N hexes each turn instead of the whole map; changing the 5 to a 3 would greatly improve this, but there'd be a possibility of a hex within your borders but outside of your cities' workable area being ignored. You'd need some sort of mechanism to ensure you didn't check the same hex twice, also (probably using globals as in #2).
4> Back in the XML, in the Improvement_ResourceTypes table, there's a variable <DiscoveryRand>. I haven't checked to see if it actually works, but it sounds like the Civ4 mechanism that gave spontaneous minerals under a mine. While it wouldn't be able to do so in adjacent hexes, you COULD have your prospector just have a large chance for various resources. But even assuming that XML actually DOES work, you'd have an improvement that could now harvest every resource it might spawn (like a Great Improvement) in which case, why build anything else?

Bottom line, though: if this is the only mechanism you ever add to your mod that requires a map search, then it might be worth it to try a shortcut. But the more stuff you add, the greater the chance that you'll need to do a full-map scan, at which point it's just better to do the whole thing once and tie each function to the scan simultaneously.

 

[PawelS]

Hope you're feeling better!

I do, thanks

I guess my perspective is: they do, its called move after attack. They can move out of range. I guess I prefer this kind of evasion to be a tactical issue that the player controls (by not over-extending and making sure they have enough movement to move out of range) rather than something that just triggers automatically/randomly.

It happens during enemy turn when you can't control your units, so there is no other way than to trigger it automatically. There is a difference between moving out of enemy range in offensive and in defensive, and these 2 effects only partially serve the same purpose. As I wrote earlier, we'll see how it works, and I'm not fully convinced that I'll use this feature.

On prospecting:
As a clueless non-programmer this might be stupid, but: is it worth specifically storing which tiles have a prospector improvement when those are created, and then checking only those tiles?

That would require saving this information with a saved game (option #2 from Spatz' post). It should be possible, but I don't know how to do it.

Another possibiliy would be: have the prospector as a rare, hard to get unit, and then have it automatically/instantly create a resource at random when you trigger, rather than Civ4 style chance per turn (which never really worked that well as a mechanic IMO).

It will be a hard to get unit, because it will be a type of Great Person. Making it work instantly is a good option too, but is there an "improvement built" trigger that works for the AI players too? If not, I can use option #1 from Spatz' post - check if a player has one of them, scan the map only in this case and make it work instantly.

4> Back in the XML, in the Improvement_ResourceTypes table, there's a variable <DiscoveryRand>. I haven't checked to see if it actually works, but it sounds like the Civ4 mechanism that gave spontaneous minerals under a mine. While it wouldn't be able to do so in adjacent hexes, you COULD have your prospector just have a large chance for various resources. But even assuming that XML actually DOES work, you'd have an improvement that could now harvest every resource it might spawn (like a Great Improvement) in which case, why build anything else?

As I wrote earlier, it will be a GP Improvement indeed. I'm not sure if I can use the Civ4 mechanism, even if it works, because the discovered resources should depend on local terrain and features, and also the improvement should be removed after discovering a resource.

Bottom line, though: if this is the only mechanism you ever add to your mod that requires a map search, then it might be worth it to try a shortcut. But the more stuff you add, the greater the chance that you'll need to do a full-map scan, at which point it's just better to do the whole thing once and tie each function to the scan simultaneously.

Hmm, I also plan the features to grow for some civs (Forest for Elves, Jungle for Lemuria, Marsh for Vodniks, with a higher probability next to existing features of the same type, but also possible elsewhere), this will probably require scanning the map as well so perhaps I'll just use my original idea - a chance to discover resources, and a chance for the features to grow. I hope it doesn't take so much time to make playing at reasonable speed impossible.

 

[Spatzimaus]

As I wrote earlier, it will be a GP Improvement indeed. I'm not sure if I can use the Civ4 mechanism, even if it works, because the discovered resources should depend on local terrain and features, and also the improvement should be removed after discovering a resource.

In that case, just use the Deep Mine method from my own mod. It's in the Base mod, file "Terraform.lua", plus related bits in the Builds, Improvements, and Units XML files. If you're changing it from an every turn to a semi-random thing, then as long as the randomness is checked BEFORE the map is scanned, it shouldn't be a problem.

That is, let's say you want a 5% chance per turn per Improvement. So, what you do is check the Player:GetImprovementCount() function for each player, then add the total up. That'll tell you that you have N of them on the map. So do a random draw of 20 (which means 0-19); let's call the result M. If M >= N, don't scan the map. If M < N, then start the map loop. As soon as you reach the (M+1)th instance of the improvement, write down the location and break() the loop. That saved location will be the hex that gets an improvement; do whatever randomization of resources you need, place the deposit, and then remove the improvement.

There. You only need one map scan, you can abort it halfway through on average, and the only headaches are:
> Only one hex on the map can ever get a resource on a turn. It'll still average out to the same amount of time as randomizing individually, so this might be an improvement.
> The math breaks if you have more than 20 (that's 1/(5%)) of them on the map at the same time. That's easy enough to fix; just drop the break(), roll 0-19 for M instead of 0-(N-1), roll 0-(N-20) (let's call that one L), and upgrade the 20+Lth as well as the Mth. Repeat as necessary.

Hmm, I also plan the features to grow for some civs (Forest for Elves, Jungle for Lemuria, Marsh for Vodniks, with a higher probability next to existing features of the same type, but also possible elsewhere), this will probably require scanning the map as well so perhaps I'll just use my original idea

If you want the features to grow naturally, then yes, you'd probably need a full-map scan each turn, although you could get around that by populating a "candidate" array every 10 turns. Record the positions of all hexes that might be grown into, do random draws on that list, and on every 10th turn do a full-map scan to update the list. There'd really be no need to scan every single turn; sure, there might be a few quirks (like a forest growing adjacent to a hex where you just chopped a forest, or a recently-conquered Elven city might spawn forests even though it's now owned by Lemuria), but it shouldn't be too bad.

If you want forests and such to be planted by workers, see my terraforming code again. It makes things quite a bit easier.

--------

In fact, combine the two ideas. Make a new improvement; let's call it a "Tree Farm". All three of those races have a unique worker unit that can place them, using slightly different Build actions (to lock out different terrain types) and every 10 turns the game does a map scan and decides which hexes can also grow them naturally (unimproved hexes adjacent to existing Forests, Jungles, and Marshes); the game also records which type of adjacent foliage was the source for "natural" spread, and records the type favored by the planting unit's civ in the case of artificial spread. Use the graphics from Spices, or Incense or something for this improvement. The game randomly decides if a Tree Farm will upgrade itself this turn, using the kind of random draw I described earlier for your prospector; each might have a 10% chance of upgrading each turn.

Then, when it DOES decide to upgrade one, check the CURRENT owner of the hex. If it's the Elves, the Tree Farm is replaced with a Forest, even if the initial Tree Farm had been planted by a Lemurian unit or if the hex had naturally spread from a Marsh or Jungle. If it's the Lemurians, then it's replaced with a Jungle. If it's the Vodniks, then Marsh. Anyone else, or unclaimed land, and it goes with whichever type of vegetation the game recorded when it added element that to the candidate array.
Now yes, this means a Jungle can spawn because of an adjacent Forest or vice versa, within those races' territory but if these civs have regional start biases, that generally won't be an issue. You can also get around that by just going with the type when the hex was originally picked as a candidate for natural spread, regardless of who owns it, and just put the racial biases directly into the candidate logic (so only forest hexes in Elf-owned areas will be added to the list).

There. That's a mechanism that'd let you keep those racial biases, even adding the ability to plant those forests with workers, without requiring more than one map scan per 10 turns.

I hope it doesn't take so much time to make playing at reasonable speed impossible.

To someone on a reasonably up-to-date computer using anything other than the largest map sizes, it shouldn't be too much of a problem, although it'll depend a bit on how much you do in that loop. Now, there ARE those folks who love epic games on huge Earth maps... they'll have problems with this.

 

[PawelS]

In that case, just use the Deep Mine method from my own mod. It's in the Base mod, file "Terraform.lua", plus related bits in the Builds, Improvements, and Units XML files. If you're changing it from an every turn to a semi-random thing, then as long as the randomness is checked BEFORE the map is scanned, it shouldn't be a problem.

That is, let's say you want a 5% chance per turn per Improvement. So, what you do is check the Player:GetImprovementCount() function for each player, then add the total up. That'll tell you that you have N of them on the map. So do a random draw of 20 (which means 0-19); let's call the result M. If M >= N, don't scan the map. If M < N, then start the map loop. As soon as you reach the (M+1)th instance of the improvement, write down the location and break() the loop. That saved location will be the hex that gets an improvement; do whatever randomization of resources you need, place the deposit, and then remove the improvement.

There. You only need one map scan, you can abort it halfway through on average, and the only headaches are:
> Only one hex on the map can ever get a resource on a turn. It'll still average out to the same amount of time as randomizing individually, so this might be an improvement.
> The math breaks if you have more than 20 (that's 1/(5%)) of them on the map at the same time. That's easy enough to fix; just drop the break(), roll 0-19 for M instead of 0-(N-1), roll 0-(N-20) (let's call that one L), and upgrade the 20+Lth as well as the Mth. Repeat as necessary.

Thanks for advice, I'll use it when writing the LUA script.

If you want the features to grow naturally, then yes, you'd probably need a full-map scan each turn, although you could get around that by populating a "candidate" array every 10 turns. Record the positions of all hexes that might be grown into, do random draws on that list, and on every 10th turn do a full-map scan to update the list. There'd really be no need to scan every single turn; sure, there might be a few quirks (like a forest growing adjacent to a hex where you just chopped a forest, or a recently-conquered Elven city might spawn forests even though it's now owned by Lemuria), but it shouldn't be too bad.

Yes, I want them to grow naturally, making them planted by workers isn't a good idea because the hexes with such features will be better for these races than other hexes, so you will want to plant them everywhere. The growth rate should be slow (and depend on the game speed), because I don't want their entire territories covered by these features in late game. So perhaps I can just pick a few hexes at random every turn and drop the features there if eligible. Your method of keeping a "candidate array" requires saving this information with a saved game, and I don't know how to do it.

To someone on a reasonably up-to-date computer using anything other than the largest map sizes, it shouldn't be too much of a problem, although it'll depend a bit on how much you do in that loop. Now, there ARE those folks who love epic games on huge Earth maps... they'll have problems with this.

Playing a fantasy mod on an Earth map... I don't think it's a very good idea... But big maps are a problem indeed, I have problems playing the unmodded game on them myself, especially in hotseat. Too bad mods don't work with hotseat, I tested my non-fantasy mod made by editing the original files in hotseat, and it worked well (as far as hotseat works for normal game, it does cause some problems but none of them are game-breaking).

 

[Spatzimaus]

Your method of keeping a "candidate array" requires saving this information with a saved game, and I don't know how to do it.

Actually, it doesn't. What you'd do is, in your Lua file, declare the variable at the top of the file (OUTSIDE of the functions themselves). That makes it accessible to all functions within the file, regardless of when you call them, although the values are cleared when you exit the game. Let's say the variable is named b_Candidates[N][2], (where the 2 is the x,y values of the hex in question and N is the number of candidates). To be safe, also store the current number of candidates in a global variable, n_Candidates (and set its default to -1 so that you can easily tell if the array's been filled yet), since this array will grow and shrink regularly.

What you'd do is, create four functions:
1> A start-of-game event that populates the b_Candidates array as the game starts. If there's not supposed to be any natural spread outside of the territories of those particular civs, you can skip this one since they won't have any cities yet.

2> A start-of-active-turn Serial Event that populates the array:
if ( Game:GetGameTurn() % 10 == 0 ) then
(do the map scan and store the results into that array.)

3> A "execute upon loading the game" event, so that when you load a savegame it immediately re-fills the now-empty array. No need to save any mod data if you do this. These sorts of functions can be a bit flaky, so instead you could just do a start-of-turn event that checks to see if the candidate array is empty (or if n_Candidates < 0), and if so, fill it instead of waiting for the tenth turn.

4> A start-of-player-turn GameEvent that checks for the spread of the features by picking any random numbers necessary and pulling any values from the candidate array.

You can expand this a bit, like using SerialEventCityCreated to add candidates near a newly founded Elvish city, but you can start without that.

Again, there are a few ways to speed this up further, but what I've described above should allow you to still get a reasonably accurate growth without scanning the full map every turn.

 

[PawelS]

Thanks for the explanation.

You can expand this a bit, like using SerialEventCityCreated to add candidates near a newly founded Elvish city

I thought Serial Events work only for the human player... If not, I can use SerialEventImprovementCreated for discovering the resources.

 

[Pazyryk]

Your method of keeping a "candidate array" requires saving this information with a saved game, and I don't know how to do it.

May I suggest TableSaverLoader? It's pretty easy to use. Just put all of your tables in a global master table, say "gT", then call TableSave(gT,"MyMod") and TableLoad(gT,"MyMod") with game loads/saves as I show in some example script.

I developed this after my Civ4 modding experience. I had many situations where processing power was spent to re-learn things each turn rather than just keeping them in a variable (that's what variables are for, aren't they?). In Civ4, you couldn't even maintain variable data from one turn to the next. Civ5 fixed this, but it wasn't much use by itself because it's all lost on game exit/load. Hence, TableSaverLoader, which does this for you without any need to modify your variables/tables (except to reference them in one master table for save).

 

[Ahriman]

I have nothing useful to add on the technical front.
But I would say: do be careful about features that have significant runtime issues, a feature like the prospector seems fairly minor and probably is less important than ensuring a wide possible audience for the mod (at least from my perspective!).

Also, it seems like the kind of secondary feature that can get added to a dummy unit later; I'd still focus on the stable, playable, alpha version first.

 

[Spatzimaus]

I thought Serial Events work only for the human player... If not, I can use SerialEventImprovementCreated for discovering the resources.

Some do, some don't. SerialEventImprovementCreated, unfortunately, is one of the events that only works for the human; or, more specifically, it triggers when the human sees a new improvement (meaning either he created it, or he gains line-of-sight to a hex whose improvement he hadn't seen before). Actually, to be more correct, it triggers TWICE for improvements you make: once when the hex transitions from blank to the "under construction" graphic for an improvement, and then again when it's completed. So no, it's not suitable for this purpose. (The Forestation mod that I'd originally based my terraforming code on had used this event, because its creator hadn't known about the limitations of this particular serial event.)

But many of the others don't work that way. SerialEventUnitCreated triggers whenever a unit's created, even if the human didn't see it, but it ALSO triggers whenever a unit embarks or disembarks. SerialEventCityCreated triggers whenever a city is founded, period, regardless of who did it or where it happened. And so on. Basically, each serial event has its own behavior, and you often can't predict which way each one will work until someone tries it out; the deciding factor seems to boil down to "does the UI need to know about X?" Units and citiies always need to be registered, because the active player gets a demographic screen that shows how well he's doing compared to everyone else, but the same isn't true for an improvement being created. And that embarkation/disembarkation bit for units is because that obviously needs to change which unit graphic is being used at each moment.

But I would say: do be careful about features that have significant runtime issues, a feature like the prospector seems fairly minor and probably is less important than ensuring a wide possible audience for the mod (at least from my perspective!).

Generally, you're correct. The catch is that once you set up one all-map scan function, it doesn't really slow things down further to stack more functions into it, depending on what exactly you're doing with it. So it's an all-or-nothing sort of deal; in my mod, I have six or seven different terraforming functions, all tied to the same map scan; since they involve mutually exclusive improvements, the slow part (checking each hex to see if it has a certain improvement/resource/whatever) isn't substantially affected by the addition of more functions.

 

[PawelS]

May I suggest TableSaverLoader? It's pretty easy to use. Just put all of your tables in a global master table, say "gT", then call TableSave(gT,"MyMod") and TableLoad(gT,"MyMod") with game loads/saves as I show in some example script.

I developed this after my Civ4 modding experience. I had many situations where processing power was spent to re-learn things each turn rather than just keeping them in a variable (that's what variables are for, aren't they?). In Civ4, you couldn't even maintain variable data from one turn to the next. Civ5 fixed this, but it wasn't much use by itself because it's all lost on game exit/load. Hence, TableSaverLoader, which does this for you without any need to modify your variables/tables (except to reference them in one master table for save).

Thanks for advice, I'll use it if needed, but Spatz said it's not needed in this case (also I'm not sure if I'll use the method he suggested).

I have nothing useful to add on the technical front.
But I would say: do be careful about features that have significant runtime issues, a feature like the prospector seems fairly minor and probably is less important than ensuring a wide possible audience for the mod (at least from my perspective!).

Also, it seems like the kind of secondary feature that can get added to a dummy unit later; I'd still focus on the stable, playable, alpha version first.

Prospecting is one of the most important features in the mod, it's what one of the great people types is used for. So I want to implement it in the first version.

Some do, some don't. SerialEventImprovementCreated, unfortunately, is one of the events that only works for the human; or, more specifically, it triggers when the human sees a new improvement (meaning either he created it, or he gains line-of-sight to a hex whose improvement he hadn't seen before). Actually, to be more correct, it triggers TWICE for improvements you make: once when the hex transitions from blank to the "under construction" graphic for an improvement, and then again when it's completed. So no, it's not suitable for this purpose. (The Forestation mod that I'd originally based my terraforming code on had used this event, because its creator hadn't known about the limitations of this particular serial event.)

But many of the others don't work that way. SerialEventUnitCreated triggers whenever a unit's created, even if the human didn't see it, but it ALSO triggers whenever a unit embarks or disembarks. SerialEventCityCreated triggers whenever a city is founded, period, regardless of who did it or where it happened. And so on. Basically, each serial event has its own behavior, and you often can't predict which way each one will work until someone tries it out; the deciding factor seems to boil down to "does the UI need to know about X?" Units and citiies always need to be registered, because the active player gets a demographic screen that shows how well he's doing compared to everyone else, but the same isn't true for an improvement being created. And that embarkation/disembarkation bit for units is because that obviously needs to change which unit graphic is being used at each moment.

Hmm, so what's a "serial" event after all? What's the difference between serial and non-serial events?

Btw it's good that the "city created" event works for all cities, I'll need it for the minor civs - they should get a building in all cities for free that gives racial promotions to their units, allows their special units to be built and so on. I think I'll use the method from the City States UU Mod only for gifted units, it will be better if they can produce their special units normally because they may require different technologies than the standard units (or have no standard versions at all). So I'll make versions of these units only for use by the minor civs, that require that building to be produced (it shouldn't cause problems for the AI, because they will get that building for free in all cities). I can make a national wonder that gives this building in all cities for free, and give it to the minor civ when their first city is created, but it should be also re-created when their capital moves. But how to detect when their capital has moved? Alternatively, I can give them that building in all cities they found or capture. (Does SerialEventCityCaptured work for all cities?)

 

[Spatzimaus]

Hmm, so what's a "serial" event after all? What's the difference between serial and non-serial events?

Serial events are UI-oriented; if it's something the UI needs to know, it triggers. If not, then it doesn't. The start-of-turn and end-of-turn events only trigger at the start/end of the active player's turn (i.e., yours). The start-of-combat and end-of-combat events only trigger if you're NOT in Strategic View and have NOT turned on Quick Combat. And so on; each will have some limitations, generally based on UI necessity.

The dozen or so GameEvents, listed here, however, are designed to work every time without exception, so if one of those is appropriate for whatever you're doing, use those instead wherever possible. They also tend to have better argument lists. Unfortunately, there are no end-of-turn, start-of-combat, or end-of-combat game events, but there are ones for start-of-turn, city captured, unit moved, and so on.

Btw it's good that the "city created" event works for all cities, I'll need it for the minor civs - they should get a building in all cities for free that gives racial promotions to their units, allows their special units to be built and so on.

You don't need a building for that, that can be done almost purely in XML. Make a new project, PROJECT_ELF. Set its cost to -1, so no one can build it. Add a single start-of-game Lua event (serial is fine for this) that gives all elven city-states or players that project on the first turn.

Then, just make any elf-specific units or buildings require that project, in the same way that nukes require the Manhattan Project. Very easy to manage, and there's no need to worry about cities changing hands since projects don't link to a city but instead directly modify the player.

The only thing you'd have to do is set the UnitClassOverrides for the barbarians; if you don't, they'll be able to build these units, as they're not constrained by project/building requirements.

But how to detect when their capital has moved? Alternatively, I can give them that building in all cities they found or capture. (Does SerialEventCityCaptured work for all cities?)

No need to use the serial event for that, there's a GameEvent for city captures. Arguments are old player number, boolean for whether it was a capital, X position, Y position, and new player number. So it'd be really easy to see when a capital moves; whenever this event triggers, just check the capital boolean.

 

[PawelS]

Good idea with the projects, but I also need the minor civs to get racial promotions for their units - for example the Elven minor civ should get the Elven promotion for all "living" units it builds (not for machines or ships), which will give things like double movement in forest and a ranged attack bonus. I don't think a project can provide this effect.

Also, I can't find an XML tag that would make a building require a project.

 

[PawelS]

I just found this awesome mod. I always wanted more CS types in the game, I thought it requires DLL changes, but it seems it can be done in LUA. I will use elements of this mod in mine for sure! As I wrote earlier in this thread, the minor civs will have multiple cities, and more types will make them more unique...