Spatzimaus
Mad Scientist
Believe me, I thought of that. But I ran into a few problems:
> The overhead is huge. UnitSetXY not only runs every time a unit moves, it runs once for EACH HEX traveled through. So figuring out whether that particular movement was linked to a combat (for melee units) would add a lot of headaches. It can be done, and it might even be low enough in processor time to be acceptable for some people, but it's not really a good solution since it wouldn't help with ranged attacks.
> The easier way to tell it was a melee attack is that the attacker took damage in the progress; ranged attacks never damage the attacker. (And those damage values are arguments to RCS, not dependent on the Unit structure, so they're still working.) But even for melees, that movement command won't help me figure out what unit was involved in the combat very easily, and for ranged warfare it'd be useless.
The problem is that since the Unit structure is now cleared before RCS triggers, fixing this would require you to scan through the list of active units for the two participants and see which entry is now missing; that's a LOT of overhead, since it'd require you to update a persistent table of active units after every combat, every event that could kill a unit (like my Lua-based Poison and Disease logics, my Critical Strike ability, and so on), whenever someone disbands a unit, etc. just to make sure you're identifying the RIGHT unit as the victim.
Well, that won't work any more if one of the two units involved died. Or if one of the two participants was a city. Or if a nuke was involved. And your Great General workaround might work for your own mod, but it wouldn't for mine, since quite a few of my units (like all of my Heroes, and many Myth units) generate no Great General points, while others generate more GG points than normal.
-----------
I've spent the past month going through all of the possible methods I could think of to fix this issue. So far, the best solution has been to redesign the math to not hinge so much on the individual units' stats in any RCS events. A lot of this does work; the Favor generation equation, for instance, primarily depends on the amount of damage dealt and whether or not the opponent was killed in the process, and all of that can be determined without needing the Unit structure. But there are some other bits that can't be worked around smoothly; I currently have a multiplier in there, to where 50% more Favor will be given to both parties if the attacker is either a Hero or a Myth unit, and another 50% if the defender is Hero or Myth. (That is, Hero-on-Myth, Hero-on-Hero, or Myth-on-Myth fights give twice the normal Favor to BOTH sides. Hero-on-Normal gives 150% to both sides.) That's a lot harder to work with, since determining whether a participant was a Hero or Myth unit will depend on the Unit structure. So, I could get around this by increasing the bonus to both sides if one of the two participants was killed in the process; it might be a bit unfair, but it'd result in the same average Favor rates over time. (That is, if a Hero kills any unit, whether mundane or mythological, both sides would get 175% Favor, since I'd have no way to know whether the defender would have been mundane, giving 150%, or mythological, giving 200%.)
If it were possible to have different Max HP values for individual unit types then it'd be easy; give all Myth units 12 HP, all Heroes 15 HP, and so on, and it'd be easy to use RCS's arguments to see what the unit was before it was killed. I'm trying to see if it's practical to do this sort of thing as a solution, but so far no luck.
Similar workarounds exist for a lot of stuff. Take Psi units; instead of adjusting their base strength pre-combat by +/-25% to account for enemy strength, I could just make it a simple "deal +1 to +3 damage if the opponent is stronger than you and survives, deal -1 to -3 damage if the opponent is weaker than you and survives, or heal fully if you kill the opponent". It'd have roughly the same effect, and wouldn't suffer from any of RunCombatSim's current problems. Most of the problems can be "fixed" like this. The problem is that there are just still a few that can't, like nuke interception. I've found nothing that could be used to mimic the old nuke interception; at best, I could give hidden anti-nuke promotions/abilities to units and buildings, to help them survive nuke attacks, but those wouldn't protect improvements. And until I find some acceptable fix for this, the Ascension mod just won't be balanced at all, as nukes are just too important a part of that mod's balance and being unable to intercept them would just ruin everything. And then there's the promotion cap; many of my stopgap fixes require giving hidden promotions, but from what people have said, the expansion adds so many promotions that my mods wouldn't have worked even WITHOUT the RCS bug.
Like I said, I'm still looking into solutions for this, and I've found some things that might be useful. But it's unlikely that the solution will be anything elegant like a single Lua workaround that'll fix all of these; it's more likely I'll have to patch each broken bit individually.
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
