Patch 674: Change to Events.SerialEventUnitSetDamage

[whoward69]

This used to work

function OnUnitSetDamage(iPlayer, iUnit, iDamage, iPreviousDamage)
  local pUnit = Players[iPlayer]:GetUnitByID(iUnit)
  if (pUnit:IsDead()) then
  -- Unit died at pUnit:GetPlot()
  end
end
Events.SerialEventUnitSetDamage.Add(OnUnitSetDamage)

But due to the changes to the animation sequences no longer does (so there is now no way to work out where a unit died, short of storing all unit positions at the start of a players turn and updating them as they move )

 

[Spatzimaus]

so there is now no way to work out where a unit died

In EndCombatSim, you can compare the unit's initial HP to the amount of damage it took during that combat. If the latter is greater than the former, then the unit will die as a result of the combat. EndCombatSim has all of the information necessary to find the unit's location, or anything else, since the unit isn't technically dead yet. (It's only MOSTLY dead, which means it's slightly alive...)

It's not great, since you can't use Quick Combat or Strategic View with that event, but it's what I use in my own mods for on-death effects. While I could have used the Serial functions instead, I don't trust them as they're generally UI-related, and I needed to be using EndCombatSim for other things anyway.

 

[whoward69]

So I can replace one OK event (in so far as it's used by the UnitIconManager code so was pretty much guarenteed to do what I needed) for one mediocre, known flawed (I play a lot of SV / quick combat games on trains), event - thanks Firaxis/2k Games!

Oh well, it will be enough to get Part 6 of my UI Tutorial working on build 674, so thanks for the info

 

[Spatzimaus]

So I can replace one OK event (in so far as it's used by the UnitIconManager code so was pretty much guarenteed to do what I needed) for one mediocre, known flawed (I play a lot of SV / quick combat games on trains), event - thanks Firaxis/2k Games!

Pretty much. The thing is, RunCombatSim and EndCombatSim are useful for so many other reasons that I've basically given up on ever using SV or QC ever again. Once you make that commitment, there's really no further downside; they're actually really good functions, in that they pass a lot more useful info through the argument lists than most other events do. So, in my mods, I use those two events for Psi units, nuke interception, orbital defenses, Damage Reduction abilities, spontaneous healing, critical hits, phoenix respawning, battle-related Favor generation, and so on. It's no longer about trading the strategic view/quick combat benefits for one bit of code, I'm trading those two options for a ton of new functions. The only remaining downside I've run into is that the RunCombatSim for combat #2 might start just before the EndCombatSim for combat #1 ends; depending on what you're doing within these functions, that might cause issues.

All they really need to do is give us start-of-combat and end-of-combat GameEvents with similar argument lists to those two Events, but that don't conflict with strategic view or quick combat. Then, everyone would be happy. Until then, I just have to keep telling my players to not use either of those two options (which is a problem now that they've moved Quick Combat from being a GameOption to being something you can toggle on and off in your Options menu).

EDIT: Also forgot to mention, two other headaches of using these two Events?

1> The argument lists aren't quite the same. That is, RunCombatSim tells you the attacker's maximum HP, starting HP, and damage taken during the combat, and then the same three things again for the defender. EndCombatSim, on the other hand, flips the damage taken arguments for the two units involved, making it a "damage dealt" instead of "damage taken". So if you're using RunCombatSim and EndCombatSim events in a mod, just be careful with the argument lists.

2> When a city is attacked, the defending player is still set as normal, but the defending unit remains at -1. The HP arguments will still give good info, but you have to extract mission data for the attacking unit if you want to figure out exactly which city is defending.
2a> And if the attacker is a city and the defender is a unit, then you can't even do that.
2b> And if the attacker is a nuke, then there's no defender at all. Nukes target a hex, not a unit or city, so no information about the defending player is passed through. Again, you can extract the mission data for the attacking nuke to figure out where it was targeted.

So, if they DO get around to making GameEvents for combat, I hope they fix both of the above.

 

[Gedemon]

have you checked your point 1/ with last patch ?

I had the feeling they corrected that (and had to do a quick hack in my mod to un-correct the correction before having time to look at it more closely)

And I can't get 2/ to work anymore, what are you using now ?

 

[whoward69]

Fortunately my needs are pretty simple - I just need to know where one of active humans units died in the "off-season" so I can automatically stick a pin in the map

 

[Spatzimaus]

have you checked your point 1/ with last patch ?

No. I was busy with work over the weekend, so I haven't had any time to update my mods to compatibility with the latest patch. I'm planning on starting that process tonight. If they HAVE flipped the arguments, then in one sense I'd be happy with it, but in another, I wish they'd document their patch changes better, because this sort of thing matters to us.

For instance, once upon a time I'd noted that the arguments to Game:SetWinner() were backwards; instead of (player ID, victory type), they'd flipped it to put the type first, and the wiki was just wrong. Well, in the last patch before this one, it looks like they fixed that without telling anyone, but no one testing my mods noticed right away since, obviously, it ONLY applied to games won through my special Transcendence process, and a while back I made other changes to no longer need that Lua trigger. I didn't find out about that change until I sat down to debug some other issue I was having with that custom victory.

And I can't get 2/ to work anymore, what are you using now ?

See previous answer; if the patch broke it, I haven't had time to check. If the Mission stack functions no longer work, then I don't know of any easy way to consistently find the city involved; you can't just use the nearest city. Yet again, they really need to just make a real GameEvent instead of forcing us to jump through all these hoops.

 

[Pazyryk]

I had some weird new issues with my mod. Not sure exactly what but my guess was that it might have something to do with event sequencing. I set EnableGameCoreThreading = 0 in the config, and these problems disappeared. (Note: I was not experience slowdowns or other problems with the patch in vanilla, although I only played a couple turns.)

Edit: I did this as a sort of "what the hell" kind of experiment. But really, it makes sense that new multi-threading capability (added in patch) would be used for graphics and could play hell with Events.

 

[whoward69]

For both RunCombatSim and EndCombatSim the unit that died is nil (ie Players[ownerOfDeadUnit]:GetUnitByID(idOfDeadUnit) == nil) - not sure if that's a change between 511 and 674 as I've not used this before.

The solution for my simple needs is to use the plot of the non-dead unit, and just accept defeat if that unit happens to have died as well.

 

[Spatzimaus]

For both RunCombatSim and EndCombatSim the unit that died is nil

I haven't had time to check this for myself, but if it's true that these events now fail for any unit that dies during the combat, then I think I'm done with Civ5, and I won't be buying the expansion. (At least until they release the DLL so that someone can make GOOD hooks into the combat events and all the other things we've asked for over the past two years.) There is just absolutely no way I can do my mods without two working combat events, and the CombatSim events were just close enough that I could do most of the things I needed. And without my own mods, I have no real interest in continuing to play, because the core game is just such a mess.

It's just incredible how often Firaxis breaks old functionalities in their rush to add new ones. It just makes things so much harder for us modders, which is amazing considering how mod-dependent games like this are.

 

[Spatzimaus]

Okay, I've semi-confirmed that, and it's definitely in the 674 patch and not the expansion. Sometimes RunCombatSim does work, and sometimes it doesn't. Basically, the Unit structure for a unit is now being cleared out more or less concurrently with RunCombatSim, so you can no longer use that event for anything useful. In a half-dozen test combats, I had three times where the structure persisted long enough for me to pull info out of it, and three when it didn't.

To make it worse, EndCombatSim no longer even STARTS if one of the units involved is going to die, so that one's even more useless.

So yeah. Until they fix this, give us a real combat event, or unlock the DLL so we can do it ourself, it looks like I'm done with modding. This breaks pretty much every feature I've added in any of my mods, so I'm just not in the mood to work around it.

 

[Spatzimaus]

Slight correction to previous statement: it now fails in both events if one of the units involved dies. It also skips EndCombatSim entirely if you're using a unit that has no animations, and when the AI takes its turn it performs all of its RunCombatSim events and THEN, once they're all complete, it does all of its EndCombatSim events.

In other words, still completely unusable.

 

[bc1]

it's weird there are so many peripheral functions but how basic fundamental stuff is missing (could kinda say the same thing about the AI )