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?
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.
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?
@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.
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.
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.
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.
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.
) 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.
