Lua Scripting Possibilities

Counting units is how I would implement that functionality.

I counted settlers and engineers for SorFox earlier

<a href="https://forums.civfanatics.com/threads/lua-scripting-possibilities.627220/page-6#post-15188320">Lua Scripting Possibilities</a>

Try writing the code from scratch. Look at the code to understand how it works (I offer fairly detailed explanation on a slightly incorrect version of the code a few posts up), but don't just try to replace the "key bits." Practice thinking about the instructions you must give the computer to get it to do what you want. In fact, start first by writing a function that counts the number of 7s in a table.

 

First off, I do want to thank both of you again for all of your help here. I know I am being very needy. I do offer what I feel is a reasonable excuse: I'm trying like mad to finalize this scenario and get it to a point to alpha test asap because my wife and I are expecting our second child any day now (she has a doctor's appointment today and it might be the day). I suspect I will occasionally have time to alpha test and do things that I can do quickly but this stuff is very challenging for me and I have a hard time doing it with distractions, hence why I'm asking rapid fire questions like a machine gun! Also, if I drop off the face of the planet suddenly for a few days, you know what happened

With that said, I do think your approach to this will help me learn, Prof. Garfield (I might have to forgo the 7's experiment for now though for the sake of expediency). I'll try this a little bit later but looking at the code and trying to understand how it works, I am skeptical it is going to work for my needs because it seems you're basing it off of civ.getActiveUnit() and civ.getCurrentTile(), neither of which I suspect will work for a situation with units that have 0 movement points (they'll never be "active"). I do think I might be able to modify it by using for unit in civ.iterateUnits() do because my understanding is that this assigns an integer to every single unit in the game at the moment, which would work well here. For now though, here's my interpretation of your code:

function doThisOnKeyPress(keyCode)
if keyCode == 214 then -- Condition is that BackSpace is pressed here you are saying that this is going to fire if and only if backspace is pressed
local activeTile = nil I think you're starting the count at nil so that the first assumption is that there is nothing and it gives the computer a way to recognize that "1" is "1"?
if civ.getActiveUnit() then --Check that there is an active unit you want to make sure that the key press will only do something if there is an actual unit that is active on the tile (so you can't press it over empty land and have something happen)
activeTile = civ.getActiveUnit().location -- Gets the acive unit and selects the tile
else --Code for case where there is no active unit
activeTile = civ.getCurrentTile()
end
local settlerType = civ.getUnitType(0) on this and the next line you define which unit is what so that you can use the phrase "settlerType" or "engineerType" rather than an integer (the unit)
local engineerType = civ.getUnitType(1)
local numberOfSettlers = 0 I'm pretty sure here you are doing this so that the count starts at 0?
local numberOfEngineers = 0 same?
local firstSettler = nil
for currentUnit in activeTile.units do this and the next few lines is you telling the computer if the current active unit is in the current active tile, you want it to first see if it is a Settler and if so you want number of settlers count to increase by 1
if currentUnit.type == settlerType then
numberOfSettlers = numberOfSettlers+1 this is how you are achieving the count sequence
if numberOfSettlers == 1 then
firstSettler = currentUnit
end
end
if currentUnit.type == engineerType then --I think I cna I don't think I need this stuff
numberOfEngineers = numberOfEngineers+1
end
end

I think instead, I could probably use something like this:

if numberOfSettlers >=1 and numberOfEngineers>=1 then
civ.ui.text("Allies get $100")
tribe = civ.getTribe(1)
tribe.money = tribe.money + 100

I am wondering, however, if I have to keep doing this 29 more times:

if numberOfSettlers >=2 then
civ.ui.text("Allies get $200")
tribe = civ.getTribe(1)
tribe.money = tribe.money + 200

if numberOfSettlers >=3 then
civ.ui.text("Allies get $300")
tribe = civ.getTribe(1)
tribe.money = tribe.money + 300

or if there is simply a way to say:

if numberOfSettlers >=0 then
Multiply that number by 100 This is the line I have NO idea how to achieve
local=theResultOfThatLineAbove --even though I might need to put this outside of this "if"
tribe = civ.getTribe(1)
tribe.money = tribe.money + theResultOfThatLineAbove

I'll look at this all in more detail later assuming I still only have one kid!

 

If your goal is getting this done before your next child arrives (a very understandable goal), upload your scenario and I'll write the events. That will probably be easier for both of us.

 

I'd be interested in your feedback regarding the scenario as well as you're an active player in multiplayer so I will send you a PM with the files when I get home from work.

This is really the only event I'm still needing as I was able to piece a few together, and you and Knighttime wrote many, so with the time crunch I'm under I will cheerfully accept your help so I can spend this last weekend getting the rest of the design files in order. Thanks!

 

Using Maps For Seasons (instead of batch conversion)

At the moment, we're still lacking the ToTPP functionality to change some parts of the game rules, particularly the terrain characteristics. @tootall_2012 has mentioned, for example, that his Napoleonic Wars scenario will still use a batch file to change seasons, at least in part for this reason.

For scenarios that need only one map, there may be a way to avoid the use of batch files, even without the ability to change terrain characteristics. The rules.txt allows for the terrain characteristics of each map to be defined separately, so we can use up to four maps as four different seasons. (or if the game needs 2 maps, 2 seasons per map) This could allow much more frequent season changes, since it wouldn't break gameplay.

The procedure for changing seasons wouldn't actually be all that difficult. Have a loop go over all the tiles on the current season. For each tile, copy any terrain improvements on the tile to the same tile in the new season. If the tile has a city, use the relocate city functionality to move it to the new tile. Then, cycle through all the units on the tile, and teleport them to the new 'season.' If the unit being teleported has a goto command, change the destination to match the new season.

There might be something I've forgotten to move or property I've forgotten to update for the new season, but this looks doable.

The 'hard' part would seem to be keeping track of where events should happen, since the tile would depend on the current season. It would probably be necessary to have some sort of getSeason() function which would return the current season (i.e. map). I'm not sure how much work it would be to convert an in progress scenario events to this format, but it might be worth considering for any future scenario

 

The Caesar scenario has changing summer/winter terrain with lua functions, starting with:

----------------------------------------------------------------------------------------------------------------------------------------

--g Helper functions


--g set the terrain graphics - is called each turn and onLoad - if state.winterSeason==1 then the winter terrain is loaded, otherwise the summerTerrain

--g also: modify the movement points of all land units to half the summer value - hard coded, has to be updated if rules are changed!

local function setTerrainGraphicsAndRules(winterSeason)


if winterSeason==1 then

--g it is so cold!!!

civ.ui.loadTerrain(0, 'wTerrain1.bmp', 'wTerrain2.bmp')


if totpp.movementMultipliers then

totpp.movementMultipliers.road=2

totpp.movementMultipliers.railroad=4

else

civ.cosmic.roadMultiplier=2

end

local multiplier = civ.cosmic.roadMultiplier


A lot more is following in the programming, but with these texts the code can be found.

 

Yes, I knew Caesar's Gallic Wars has a winter/summer system. You can do a lot with the TOTPP lua functionality that currently exists. However, changing terrain move cost (to have individual terrain type variation), production and defensive bonuses is not possible with current functionality. I offered this as a way to achieve that kind of change without resorting to a batch file. This sort of map swap could also be used to represent good or bad harvests by choosing a different one each turn, and probably many more things I haven't thought of yet.

 

So, if I wanted to replace a map with a different map from a .mp map file in the console, how would I do that?

 

As far as I know, there is no easy way of doing that at the moment. And any 'hard' way would not be able to copy rivers, because the current TOTPP lua functions don't allow placing rivers on terrain (and eliminate rivers when changing terrain). What you'd want to do is start a game with the new map (which should have the same dimensions of the existing map), run a script that puts the terrain type of each square in a table, and prints that table to a file. Then, you run a script in the game where you want to replace the map that goes over each square and references the table you created to change that square to what it 'should' be.

If you have a specific use case, I might be able to provide more details and some code.

 

Considering my maps in mind have no rivers to begin with, that may be helpful

Edit: Also, how do I fix the fertility on a map if something like this happens again?

 

I'm trying to think of a way to implement encirclement and supply lines in a WW2 Europe scenario The Hinge of Fate (which remains a paper scenario at this point). @Knighttime , I am curious about your work with leader bonuses in Napoleon.

1. Was it a design decision to limit the bonus to units that start (or passed through and activated) on the leader's tile, or is this how it must be done?
2. Would it be possible to have a leader unit press 'k' and then grant an attack bonus to all units on its square AND adjacent squares for the turn, or does the attack bonus have to be activated by the unit that wishes to use it?

I'm basically wondering if it would be possible to use your leader bonus idea but tweak it a bit - rename leaders "supplies," have the supply unit boost the stats of nearby units when it presses "k," and delete the supply unit in the process.

This would require a player to protect supply lines, and if another player was able to encircle a portion of an army, and supplies could not get through, the trapped army would fight at a disadvantage.

This also would make for a bit of micromanagement, but logistics were very important in the war and I think if one unit could supply units in a 9-square grid then it wouldn't be overwhelming. It also might be fun as, for example, the Germans might overextend themselves in Russia, outrunning their supplies and being unable to move forward and attack effectively.

This seems like one of those things I should confirm would work in the game as it does in my head before I start building the scenario

 

Hi @JPetroski, good questions! The important thing to remember is that unit stats like attack and defense strength are stored at the unit type level only, not for individual units. So in order to confer an attack bonus on a unit, an event has to change the attack strength for all units of that type in the entire game. Obviously, then, a separate event also needs to set the attack strength of that unit type back to the default at some point after the first unit has completed its turn, so that the next unit of that type to be activated doesn't inherit a bonus that isn't warranted.

The way this is implemented in the current release of Napoleon (v 1.0) is that an event runs each time a unit is activated, and first sets all unit type attack strengths back to the default. Then it checks to see if the active unit is on the same tile as a leader, and if so, confers the appropriate attack bonus on that unit type. This is the simplest implementation that I could find. Note that this doesn't require pressing a key to apply the bonus, but it does require that the unit be activated while on the same tile as the leader -- simply passing through that tile isn't sufficient, since no event trigger fires on every unit movement, only on unit activation.

It would be possible, and not too difficult, to make a minor enhancement to benefit units that start elsewhere and pass through a leader tile, so that instead of having to de-select and re-select them, the player would simply have to press a key while on the leader's tile to receive the bonus and could then keep moving. But it's not a huge improvement; units that start on a leader tile still have their bonus applied automatically, and those that start on a different tile still require some deliberate action on the part of the player in order to receive it.

It was part of @tootall_2012 's specifications that in order to receive the bonus, a unit had to be present on the same tile as the leader at some point during that turn, not simply adjacent or nearby. The fact that simply passing through a leader's tile doesn't automatically confer the bonus is a game limitation.

Actually... you asked that as an "either/or" question, but I'd say "yes" to both. First "yes": it would be possible to re-implement this concept so that it could only be initiated by a key press while the leader unit is active. We didn't pursue this for Napoleon, for several reasons: first, the implementation would be considerably more extensive and complex (see below); second, it would require manually finding and activating each leader first, instead of allowing the game to apply bonuses to each unit automatically as it gets activated; and third, making it the leader's responsibility to confer the bonus doesn't align well with the requirement that a unit is eligible to receive the bonus any time it crosses paths with that leader.

The implementation would need to work something like this: when the leader unit was active and the player chose to apply its bonus, the event would have to identify all units which should be affected. Identifying units on the same tile is easy, but identifying units on nearby tiles requires additional code to determine which tiles are in fact adjacent, and then look for units on them. Secondly, once the units are identified, the event would need to create entries within the state table for them to document that they should receive a bonus. But since the stats must be changed at the unit type level, you couldn't actually apply any bonuses at that time, since the next unit of a given type to be activated might be elsewhere on the map. Instead you would still have to wait until a (non-leader) unit was activated, and then potentially change the stats of its unit type at that time (that's the second "yes"). The difference is that instead of checking for the current presence of a leader (as in Napoleon) the event would look for an entry in the state table.

To make matters worse, Civ recycles unit ID numbers when a unit is killed or disbanded, so simply tracking unit IDs in the state table might leave some loopholes. Additional events or cross-checking might be required to avoid problems. Bonuses would also have to be cleared out from the state table at the end of each turn if you didn't want them to carry over.

Yes, that definitely seems possible, and I tried to outline the way I'd approach this above. But unfortunately the implementation in Napoleon is only about a quarter of what you'd need, so it would be more than a "tweak".

 

Thank you, Knighttime. I often find that my small "tweaks" often grow well beyond the term!

I'm trying to figure out a way to make supplies work so that Malta matters, and encircling an enemy actually has some meaning. To do that without making it to burdensome for the player would be the real goal.

I might have to spend some more time at the drawing board about this one.

 

@Knighttime @JPetroski

I think it might be time to have a look at how the combat event works. A while ago, I tried it out and found that you couldn't change the a/d (and probably not hp/fp) and have it apply within that particular combat. However, I could make changes to the unit's hit points between 'rounds' of combat, and possibly do other things. We might be able to 'override' the combat system by saving the following method:
Each round:
1) revert both unit hp values to what was saved last round
2) Do a customized (or possibly several) combat calculation using whatever information we need from the 'game board' and modify both units' hp to reflect the result.
3) save these hp values in order to revert after the subsequent round of combat

If the reason this hasn't been looked into more is that a unit must always die in combat, I think we should reverse that decision, since a unit always dies in combat anyway, with current functionality. If we were hoping @TheNamelessOne would fix it relatively soon and so didn't want to build on a soon to be obsolete functionality, he's been gone for a while and we don't know when he'll be back, so we might as well use what we have. We can always put a note in the readme that a particular scenario might not work with future versions of TOTPP, and make sure that section of code is well documented, so it can be updated when necessary.

I might look into this after OTR is released, but perhaps Knighttime now has some free 'lua time' since his project is finished.

I forgot about your need to copy a map. My Civ II Lua time is currently being used to try to finish Over the Reich, but if I haven't given you a solution by December 21, feel free to remind me.

 

Hi @Prof. Garfield, I also researched the onResolveCombat() trigger at one point, and (just for reference, although I expect you already saw this) my post after doing so is here: https://forums.civfanatics.com/threads/totpp-lua-function-reference.557527/#post-15169775

That's too bad, since this would seem like a potential avenue to setting leader defense bonuses (contrasted with the leader attack bonuses implemented in Napoleon).

The steps you describe certainly sound possible, but I'm not quite sure what you have in mind by "Do a customized (or possibly several) combat calculation using whatever information we need from the 'game board'". Personally, other than the two ideas I raised in the linked post (which didn't work) plus the idea of defensive leader bonuses (which you said doesn't work), I haven't really found any concrete situations where this trigger seems likely to be useful. Did you have a specific project or goal in mind?

Napoleon is released as you said, although event revisions for version 1.1 are already underway. I also have a medieval scenario project of my own that I'm working on when I get a chance, which has some pretty cool events as well. (Maybe someday it will actually be ready for outside review! ) That being said, I probably could find a little bit of time for this, if it would help someone advance past a roadblock in their scenario design.

Are you envisioning this as a solution for the "supply" problem that @JPetroski is trying to solve? Maybe I'm just not seeing how this provides significant advantages over what we can do today with onActivateUnit(). Would it be the ability to affect the HP of the defending unit?

 

The way I was thinking about approaching supply lines with what we currently have is basically:

-have every unit in the game start with either 0 or a very low attack rating (probably low) - possibly a low movement rating too for fuel-based units
-have this attack rating be boosted significantly by the supply unit via the leader tech
-if you can't get a supply unit to the attacking army, the attacking army isn't going to accomplish much, or anything
-have the supply unit be a 'k' unit that is deleted when it supplies, so that you must continuously bring one in from elsewhere. Hence a supply chain that can be cut (intercept the supply units, knock the army out of supply).
-Have the supply unit work for adjacent units (basically a 9 tile grid where the supply unit is always '5' on the number pad). Hence if there is an enemy unit between the supply and the army then it is out of range.

As far as I can tell from your response to my initial inquiry, @Knighttime, this would work. It would certainly work if I was content to have the attacking army have to be on the same exact square as the supply unit, anyway. It would probably work if I wanted a 9 grid (or greater) layer next to it too, though the code would need to be significantly modified.

This only works, of course, for halting an attacking army's advance, rather than giving their opponent an attack advantage.

In Hinge of Fate I'd really like to find a way to show off the grand encirclements of the eastern front where hundreds of thousands of prisoners were taken. I suppose the approach could work, because the advancing army would be impotent and could be so for several turns (it might be all I need), but it also might be better (and less demanding on the player from a micromanagement perspective) if the attacking army got some sort of bonus on the offensive (to keep it simply, perhaps increased attack rating) for attacking a trapped force.

That's the piece that I think is missing here and that I don't know how to accomplish currently. How does an attacking enemy army somehow "know" that it has encircled an enemy army?

It's worth exploring if there might be any way to check if a city, unit, or designated grid of tiles can trace a link back to a central point via a road or squares without the presence of enemy units. Because if this can be done then the potentially clunky supply system above doesn't seem necessary.

 

Customized defensive terrain:
Standard game rules say that attacker attacks at 5, defender defends at 2 + 50% defence bonus for terrain, so defender defends at 3.
We want a terrain defence bonus of 100% for when this particular attacking unit attacks this terrain. So, step 2 becomes

get the attacker value we actually want, a* (5)
get the defender value we actually want, d* (now 4 instead of 3)
a~ = uniform random number between 0 and a*
b~=uniform random number between 0 and b*
if a~>b~, attacker does damage to defender, otherwise defender does damage to attacker

Perhaps we want veteran status to be +30% instead of +50%. Maybe we want other units on the square (or nearby squares) to take damage either instead of the defending unit or in addition to it.

As long as we can figure out how to choose whether to kill the attacker or defender, we can do almost anything we want in combat, as long as it results in a unit being killed at the end.



Maybe we can override that: at the end of combat, we choose a 'loser' and save its id number, home city, location, and desired hp in the state table. On unit activation, an event checks if a unit needs to be revived, and, if so, accesses the unit via its id number (since the game doesn't delete the unit data immediately), moves it to the proper location, restores its home city and sets it to the desired hp.

We could do Axis and Allies style combat, where the chance to hit doesn't depend on the opponent's chance to hit.

@JPetroski 's supply problem can be solved by setting a* and b* to be different depending on the availability of supplies.

We can't do custom defensive terrain with onActivateUnit, nor can we give a unit a defensive bonus for sharing a square with another type of unit. Also, onActivateUnit can currently be circumvented in the city window, if a particular unit type will be given a disadvantage in combat against another unit type.

An alternative that could work now is to use onUnitKilled. After combat, the winner attempts to 'expend' nearby supplies (either reduce HP, or use up the entire unit). If it can't then the winner dies too.

This is definitely possible, but comes with some problems. First problem is that a pathfinding algorithm must be build in lua, or an 'off the shelf' pathfinding algorithm already written in lua must be found and interfaced with Civ II. I remember looking for an off the shelf pathfinding algorithm at some point, but being unable to figure out how it was supposed to be interfaced with an arbitrary game or problem. I'll probably do this eventually in one way or the other, since having pathfinding functionality is useful, but there are a lot of other things that I would probably want to get done first.

The second problem is that running a pathfinding algorithm for every unit (or, worse, on activation) might get expensive, especially the farther away that a search must be made from the starting point. There's a reason the generic civ II pathfinding isn't very good, although with 20 years improvements in computation power and algorithm design, we can do better. It is possible that computational efficiency will have to be taken seriously and a customized solution might end up being necessary, which isn't the end of the world, but might get the project delayed until someone with the skills to do it has the time and desire to do so.

If the maximum search distance is very limited (within maybe 5 or 6 squares), then most of these problems go away. However, if there could be a supply depot somewhere in at 30 square radius that would qualify, there might end up being a problem. I'm not sure, since I haven't done much pathfinding, and I don't know how 'quick' lua is either.

 

Just to confirm, yes, you could define any radius you wanted as far as a "zone of effect" for the supplies unit. Anything greater than "on the same tile" would require more effort to write, but wouldn't make the overall approach more or less likely to be successful.

I see what you're saying... you're essentially proposing that we could completely ignore the Civ2 "defaultResolutionFunction" in favor of writing our own, entirely from scratch, in Lua. That's... intriguing, and I can imagine that some scenario designers might find that quite useful.

All good points.

I've actually written a working implementation of a similar concept using onUnitKilled(), which creates a new instance of the losing unit away from the battle, with only 1 HP. It's a way to reflect survivors fleeing from the battlefield rather than being 100% wiped out. Perhaps something like that would also be possible via onResolveCombat(), just clarifying that it doesn't necessarily have to happen there.

It seems to me that one of the things that commonly makes pathfinding algorithms complex is a need to identify the best path from point A to point B. In Civ, this has to account for things like terrain type movement rates, roads and railroads, oceans and impassable terrains, etc. However, depending on the supply line rules, we may be able to simplify considerably because we may not need to care if we identify the most efficient path, only verify that there is one.

To be honest, this approach intrigues me quite a bit more than exploration into rewriting the battle resolution function for use within onResolveCombat(). I've had some success with writing recursive functions in Lua and I feel like I have a basic idea of how to tackle this. Mind if I give it a shot? Of course I can't guarantee success, but it seems like a fun problem to tackle!

Agreed, performance is potentially going to become an issue at some point. My first goal is just to see if I can get the concept working over short distances, and then we can begin performance testing longer supply lines.

 

I think that a supply line pathfinding system, if possible, would be better than the 'k' unit supply idea for the simple reason that the AI could actually use it (even if they wouldn't realize that they were using it). If the AI breaches your defenses and cuts a supply line, it cuts a supply line.

I suppose the first step could be just to see if any path is available but I'm wondering if certain modifiers could be built in or if any of these are also possible:

A. A path that is unobstructed by enemy units
B. A path that is unobstructed by certain terrain (for example a mountain or desert)
C. A path that is ONLY along a certain type of terrain (for example, "path")
D. A path that is along any terrain that has the road improvement on it

 

Go ahead. I have tutorials and libraries to write, so I don't expect to run out of things to do with lua any time soon.

These are all possible with a general pathfinding algorithm. Pathfinding can be done by converting your specific problem to a graph and then solving the problem with a pathfinding algorithm (and then interpreting the results). All the things you want simply mean constructing a different graph in the first step. That said, constructing the graph and then solving the pathfinding problem could become computationally expensive over an entire Civ II giga map.