| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0002620 | Spring engine | General | public | 2011-08-23 23:49 | 2011-09-08 22:10 | ||||
| Reporter | zerver | ||||||||
| Assigned To | zerver | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 0.82.7.1 | ||||||||
| Target Version | Fixed in Version | 0.82.7+git | |||||||
| Summary | 0002620: Repeat commands involving IDs remain after the object has been destroyed | ||||||||
| Description | For example, a repeat command to reclaim feature with ID X may cause the constructor to wander off into nowhere to reclaim another feature with same ID that was created after the original one was destroyed. This happens regardless of LOS status of the new feature. I'm suspecting the same bug exists with other objects also (units). | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
hoijui (reporter) 2011-08-26 09:27 |
This suggests we should use a death dependence on the feature/unit to reclaim/attack/repair/etc. . If i got it right, these commands may have a form (parameter count) that would require this: CMD_ATTACK CMD_GUARD CMD_REPAIR CMD_LOAD_UNITS CMD_LOAD_ONTO CMD_UNLOAD_UNITS CMD_UNLOAD_UNIT CMD_RECLAIM CMD_MANUALFIRE CMD_RESURRECT CMD_CAPTURE In order to use a death dependency, Command would have to inherit CObject, and remove itsself from the queue if the feature/unit it depends on dies. right? alternatively, the death dependency could be added to the unit itsself, but that could get messy. for example, we add a dependency on unitX because of a reclaim command on that unit, but we already depend on unitX for an other reason, and when the command gets canceled we remove the dependency on unitX -> bad. |
|
jK (developer) 2011-08-27 04:35 Last edited: 2011-08-27 04:37 |
why not block ids for min one slowupdate cycle (16 sim frames)? this way all commands linked to it would run before it gets reused -> delete themselves from the cmd queues (id is dead!). |
|
hoijui (reporter) 2011-08-27 10:11 |
that sounds like a better solution, yes. though, i don't understand why all commands are reused within 16 sim frames. there is some code part that re-checks all commands of all units each slow-update? |
|
zerver (reporter) 2011-08-28 02:52 |
I think one slowupdate cycle is only guaranteed to process the next command. If there is a queue, it won't be enough. |
|
zerver (reporter) 2011-09-08 22:10 |
https://github.com/spring/spring/commit/fab515de367648f4a8e2de6fd158175b1b1cabb2 |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-08-23 23:49 | zerver | New Issue | |
| 2011-08-26 09:27 | hoijui | Note Added: 0007302 | |
| 2011-08-27 04:35 | jK | Note Added: 0007303 | |
| 2011-08-27 04:36 | jK | Note Edited: 0007303 | |
| 2011-08-27 04:37 | jK | Note Edited: 0007303 | |
| 2011-08-27 10:11 | hoijui | Note Added: 0007305 | |
| 2011-08-28 02:52 | zerver | Note Added: 0007307 | |
| 2011-09-05 16:27 | zerver | Status | new => assigned |
| 2011-09-05 16:27 | zerver | Assigned To | => zerver |
| 2011-09-08 22:10 | zerver | Note Added: 0007345 | |
| 2011-09-08 22:10 | zerver | Status | assigned => resolved |
| 2011-09-08 22:10 | zerver | Fixed in Version | => 0.82.7+git |
| 2011-09-08 22:10 | zerver | Resolution | open => fixed |
| Issue History |