| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0005862 | Spring engine | Lua | public | 2018-01-04 18:28 | 2018-01-18 00:59 | ||||
| Reporter | PepeAmpere | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 104.0 +git | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0005862: Spring.DestroyUnit + Spring.CreateUnit does not support morphing with persistent unitID | ||||||||
| Description | unitID of destroyed unit (destroyed by Spring.DestroyUnit) is blocked (i guess for some event handling purposes) for few frames. This does not allow me to construct custom morph gadget which in zero time would morph one unit to another with same unitID. My workaround is to wait few frames, but it is far from optimal: 1) need to visually cover the morph situation until the spawn happens 2) need to construct delayed call logic 3) unit does not exist for few frames ---- Options I see: 1) Expand Spring.DestroyUnit by another parameter which allows me to set "fast" destroy (it may have some complicated implications on e.g. events - generally for "fast" destroy i would not expect call of any consequent event, because this destroy is exactly for morphing, for nothing else) OR 2) Extend API by Spring.ReplaceUnit(...) which will allow me to change unitDefID of some unit. There may be some issues with validation of some unit parameters. We can say the function is silly - if values makes sense for new unitDefID, they persist the change, if they does not make sense, they disappear. Or maybe you see some other option. | ||||||||
| Steps To Reproduce | local function(...) Spring.DestroyUnit(unitID) local newUnitID = Spring.CreateUnit(defName, x, y, z, facing, unitTeam, beingBuilt, false, unitID) return newUnitID end // this will return nil | ||||||||
| Tags | ai, morphing, unitID | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Kloot (developer) 2018-01-04 20:14 |
there are no good options, read https://springrts.com/phpbb/viewtopic.php?f=85&t=36351 |
|
PepeAmpere (reporter) 2018-01-04 20:42 |
btw, it always takes 3 frames to do the morph with my delayed workaround: #1 delete unit with given unitID #2 wait, i guess handlers reacting 0000003 now you can spawn unit with same unitID late note: now i see it in kloots linked forum discussion as well, thanks kloot |
|
Kloot (developer) 2018-01-18 00:59 |
Fix 0b018304c7d2da8e0f523dac6f9c8307b16ca12b committed to develop branch: fix 0005862 extend Spring.DestroyUnit with a boolean recycleID argument this was neither planned nor desired, but required to squash another bug ID's of destroyed units were erroneously allowed to be re-assigned again (within three frames) *before* pool recycling took place, and most morph gadgets since started relying on the broken behavior as such, emulating it via an extra arg (which now at least makes seamless insta-morph possible) was the only way to keep things working as expected, repo: spring changeset id: 9461 |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-01-04 18:28 | PepeAmpere | New Issue | |
| 2018-01-04 18:28 | PepeAmpere | Tag Attached: ai | |
| 2018-01-04 18:28 | PepeAmpere | Tag Attached: morphing | |
| 2018-01-04 18:28 | PepeAmpere | Tag Attached: unitID | |
| 2018-01-04 20:14 | Kloot | Note Added: 0018705 | |
| 2018-01-04 20:42 | PepeAmpere | Note Added: 0018706 | |
| 2018-01-18 00:59 | Kloot | Changeset attached | => spring develop 0b018304 |
| 2018-01-18 00:59 | Kloot | Note Added: 0018737 | |
| 2018-01-18 00:59 | Kloot | Assigned To | => Kloot |
| 2018-01-18 00:59 | Kloot | Status | new => resolved |
| 2018-01-18 00:59 | Kloot | Resolution | open => fixed |
| Issue History |