Move out of world promoted, packed and upgraded entity as they are not destroyed immediately. So they don't interact with the 'physical' world. Refs #4595.
Differential Revision: https://code.wildfiregames.com/D590
Reviewed By: wraitii
Description
Description
Details
Details
- Committed
fatherbushido Nov 1 2017, 3:55 PM - Reviewer
- wraitii
- Differential Revision
- D590: Move out world promoted, packed or upgraded before destroying.
- Parents
- rP20392: [i18n] Updated POT and PO files.
- Branches
- Unknown
- Tags
- Build Status
Buildable 3576 Build 6205: Post-Commit Build Jenkins
Event Timeline
Comment Actions
This is broken: build a garrison-able upgradable wall and garrison it, then upgrade the wall to a gate: the units won't eject since the garrisonholder is out of world.
There is also a bug when the new ent has a garrisonholder but not enough space, the ents will eject, but stay unmoveable at the garrisonholders foot (probably unrelated since that is fixed by removing the autogarrison call in TransferGarrisonedUnits)
Comment Actions
This is broken: build a garrison-able upgradable wall and garrison it, then upgrade the wall to a gate: the units won't eject since the garrisonholder is out of world.
You mean a garrison able upgradable unit, garrison that unit, upgrade it while garrisoned? I'm pretty sure that never worked.
Comment Actions
y, thats the bug.
Well I tracked the code, and it gets stuck on the IsInWorld check, so my suspicion is this commit (didn't actually test if it worked before)
/ps/trunk/binaries/data/mods/public/simulation/helpers/Transform.js | ||
---|---|---|
224 | Also this comment seems like it was tested (bit ambiguous though comment) | |
231 | (this is the call I talked about, don't know where it is good for) |
/ps/trunk/binaries/data/mods/public/simulation/helpers/Transform.js | ||
---|---|---|
231 | I agree, that's what I recall too. |
Comment Actions
(I wonder if the concern shouldn't be removed, as the pointed bug was not really related to that patch)
Comment Actions
Causing another bug revealed by rP22313: a unit that tries to flee from a promoted unit, doesn't know anymore where to flee (since the attacker has no position anymore). This is fixable, by first passing on the fleeing call with the old entID and the promoting it. If required we can always listen to OnEntityRename, but when the attack occurs we don't know the new ent ID (we don't even now if it promotes), see the Damage.js CauseDamge.
Probably needs a test too.
Comment Actions
For the record, not only fleeing is affected, every movement update which bails on msg.likelyFailure.
(rP22526#38783)