| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0004779 | Spring engine | Lua | public | 2015-05-12 13:34 | 2016-02-02 21:11 | ||||
| Reporter | aeonios | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | normal | Severity | feature | Reproducibility | always | ||||
| Status | resolved | Resolution | no change required | ||||||
| Product Version | 98.0.1+git | ||||||||
| Target Version | Fixed in Version | 100.0+git | |||||||
| Summary | 0004779: addon:GameFrame is called before other 'status' callins | ||||||||
| Description | I noticed this when tracking various bugs in a widget that I wrote, but GameFrame is called before things such as UnitFinished, UnitCreated, UnitDestroyed, etc. This prevents those callins from 'filtering' out things like units that are dead, forcing additional validity checks to be added to GameFrame logic. Also, such checks/cleanup in GameFrame can clobber the logic in the other callins, forcing even more redundant checks to be required for those functions. Having GameFrame called dead last for every frame update would make writing complex widgets a bit easier and more consistent. | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
abma (administrator) 2015-05-12 17:54 |
maybe add a GameFramePost callin? changing order of GameFrame/Unit callins imo would break a lot of widgets and gadgets. |
|
FLOZi (reporter) 2015-05-12 22:12 |
I'm not expert enough to be sure but I don't think changing order of execution would be sufficient to resolve all checks anyway (some things require a frame (or even slowupdate) to be properly 'cleaned up'). |
|
aeonios (reporter) 2015-05-13 04:35 |
>>changing order of GameFrame/Unit callins imo would break a lot of widgets and gadgets. Proof? Unless GameFrame was being used in a horrible-hack sort of way in the first place this should not occur. I haven't seen any widgets that would be negatively affected by this, nor am I aware of any case where a gadget should break due to such a small change. The way things currently work require checks on both ends regardless, so if anything all code should already be protected against such a change. This would merely allow some of the extra code to be removed. >>I'm not expert enough to be sure but I don't think changing order of execution would be sufficient to resolve all checks anyway (some things require a frame (or even slowupdate) to be properly 'cleaned up'). Technically the way I'm using GameFrame is to have it run every x game frames, where x is adjusted for latency. Given how easy it is to do that SlowUpdate is pretty much useless/redundant anyway. It's true that GameFrame still has to perform some checks since callins cannot indicate every possible thing about game state (such as whether a build site is blocked). On the other hand, it's extremely dumb that GameFrame should be seeing units that are mysteriously invalid once-in-a-great-while just because, if UnitDestroyed and GameFrame happen to be run during the same game frame then GameFrame will be called first. I suspect that SlowUpdate behaves the same, which is equally stupid. It's stupid because at least for the local player (for which all info is available to unsynced) UnitCreated, UnitFinished, UnitDestroyed and UnitTaken already allow for comprehensive and consistent tracking of the state of any given allied unit. Enemy units can't be tracked quite as well, but UnitEnteredLOS, UnitLeftLOS, UnitTaken and UnitDestroyed can still at least track them consistently enough that nil errors could be avoided. Features currently don't have any such callins, but if they did the situation would be the same for those as well. |
|
msafwan (reporter) 2015-05-14 18:24 Last edited: 2015-05-14 18:27 |
Won't stuff like GameFramePost() will have inconsistent rate? think about it... if there were dead units then it have to wait for them to process. But if you meant GameFrame() + 1, then just wait for next frame. If you have 100fps and wanted 0 delay calculation then use DrawScreen() (or Update()), it follow how fast your computer update. |
|
Kloot (developer) 2016-02-02 21:11 |
obsolete report now that UnitDestroyed is (will be) called twice; cleanup should happen there |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-05-12 13:34 | aeonios | New Issue | |
| 2015-05-12 17:54 | abma | Note Added: 0014458 | |
| 2015-05-12 17:55 | abma | Severity | tweak => feature |
| 2015-05-12 22:12 | FLOZi | Note Added: 0014459 | |
| 2015-05-13 04:35 | aeonios | Note Added: 0014461 | |
| 2015-05-14 18:24 | msafwan | Note Added: 0014467 | |
| 2015-05-14 18:25 | msafwan | Note Edited: 0014467 | View Revisions |
| 2015-05-14 18:26 | msafwan | Note Edited: 0014467 | View Revisions |
| 2015-05-14 18:27 | msafwan | Note Edited: 0014467 | View Revisions |
| 2016-02-02 21:11 | Kloot | Note Added: 0015610 | |
| 2016-02-02 21:11 | Kloot | Status | new => resolved |
| 2016-02-02 21:11 | Kloot | Fixed in Version | => 100.0+git |
| 2016-02-02 21:11 | Kloot | Resolution | open => no change required |
| 2016-02-02 21:11 | Kloot | Assigned To | => Kloot |
| Issue History |