View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001395 | FSSCP | gameplay | public | 2007-05-12 19:25 | 2007-08-15 10:58 |
| Reporter | CP5670 | Assigned To | Goober5000 | ||
| Priority | normal | Severity | major | Reproducibility | random |
| Status | resolved | Resolution | no change required | ||
| Product Version | 3.6.9 | ||||
| Summary | 0001395: every-time-argument does not work consistently | ||||
| Description | The every-time-argument operator doesn't work reliably. This is something system-specific and is hard to reproduce, but enough people have complained about it now that I think it may be a game bug of some sort. This specifically concerns mission 13 of The Procyon Insurgency, where two every-time-argument events are used to automatically add and remove fighters from the escort list according to their proximity from the player. I've played this mission many times on two different computers and have never had these events fail to work, but a number of people on the forums are reporting that they only work some of the time, which would make the mission almost impossible. I believe the frequency of every-time/every-time-argument is dependent on the framerate, which varies between computers, so it may have something to do with that. | ||||
| Tags | No tags attached. | ||||
|
|
Yep. You should never do anything frame rate dependent with either every-time or every-time argument (Or with when and a repeat delay of 0 for that matter). |
|
|
The operators need to be changed to work at some fixed rate in that case, since they are pretty useless if they do in fact work differently on every computer. That being said, I can't see any obvious connection between their framerate dependancy and the particular events I'm using them in. In this situation, the events would still fire hundreds of times even if the framerate is low, so something must be wrong if they still won't always work for some people. |
|
|
The engine is single-threaded, so it's ALL framerate dependant. Most everything is executed once per frame, which means that anything happens, at most, 120 times per second. But if you are only getting 20 FPS, then things can only execute 20 times per second. Outside of just making every-time execute on a timer 10-20 times per second (the timer is also going to be linked to some extent to the framerate), so that you have a more predictable execution time, there is nothing to do here. Making the engine multi-threaded, though the only real fix, is a massive undertaking and that isn't going to happen any time soon. |
|
|
I'd go for the timer method. Ten times a second sounds good to me. |
|
|
That's what I had in mind too. I may have been able to find a workaround in the particular case I mentioned earlier (still not really sure if it works for others), but in general, debugging missions becomes very complicated if there is any possibility of the mission behavior being different depending on the machine. A smaller interval should make things work more consistently across a variety of computers. |
|
|
Ok, I'll go with a 10 FPS timer, as soon as I figure out how. ;) |
|
|
Unless you make all the other SEXPs dependant on the same timer, please don't. Suppose I have a situation like this Event 1 -every-time --Case A -Modify variable to YES Event 2 -when --And ---Case B ---Variable = YES -Do something Event 3 -every-time --Variable = YES -Modify variable to NO That little situation works perfectly well under current conditions but if you change every-time to working on a timer independent of when the When SEXP triggers you open up all kinds of race conditions. Firstly is Event 3 going to trigger every time that Event 1 does? Or is there the possibility of it falling out of phase and giving event 2 several chances to trigger erroneously? Even if all every-time SEXPs are synced to the same clock then you still have issues with the when SEXP not going off at the right time. The Every-time might correct something that when missed causes a 4th event to go off incorrectly. If you're going to have a timer driven SEXP either all of them have to work that way or it has to be a new SEXP. I can see all kinds of problems if you change the way it works now. |
|
|
I don't know if your event 2 will work consistently even with the existing setup. In fact, that is just the sort of thing that seems to be machine-dependent. The event 2 stuff should be merged into event 1 to ensure that it works every time. I see your point though, and I think the best way to maintain backward compatibility is to add an extension to every-time/every-time-argument (similar to what was done with is-event-true-delay) that specifies how often it should be checked. That would essentially leave it in the hands of the mission designer. |
|
|
I had never intended for every-time to be used as much as it is now. It's quite computation-intensive, and it's verging on a hack anyway. That said, I just remembered something that might make the timer thing completely irrelevant: When and every-time use exactly the same code. The difference is that when stops being evaluated as soon as it comes true, while every-time immediately forgets that it was ever evaluated (causing it to be checked again on each subsequent frame). In summary, when and every-time have the exact same framerate dependency. So why are we seeing bugs with every-time that we don't see with when? |
|
|
I don't think we are. If this is a frame rate problem it would appear with use of repeated when with a 0 delay too. In fact that's probably what he should be using. |
|
|
Closing as a choice-of-sexp problem, not a code problem. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-05-12 19:25 | CP5670 | New Issue | |
| 2007-05-13 23:42 | karajorma | Note Added: 0008077 | |
| 2007-05-13 23:58 | CP5670 | Note Added: 0008081 | |
| 2007-05-13 23:59 | CP5670 | Note Edited: 0008081 | |
| 2007-05-14 07:10 | taylor | Note Added: 0008082 | |
| 2007-05-25 04:46 | Goober5000 | Note Added: 0008133 | |
| 2007-05-25 04:46 | Goober5000 | Assigned To | => Goober5000 |
| 2007-05-25 04:46 | Goober5000 | Status | new => assigned |
| 2007-05-25 09:42 | CP5670 | Note Added: 0008136 | |
| 2007-05-25 09:47 | taylor | Note Added: 0008137 | |
| 2007-05-25 12:10 | karajorma | Note Added: 0008138 | |
| 2007-05-25 12:53 | CP5670 | Note Added: 0008139 | |
| 2007-05-25 12:54 | CP5670 | Note Edited: 0008139 | |
| 2007-05-25 22:49 | Goober5000 | Note Added: 0008140 | |
| 2007-05-26 11:07 | karajorma | Note Added: 0008143 | |
| 2007-08-15 10:58 | Goober5000 | Note Added: 0008377 | |
| 2007-08-15 10:58 | Goober5000 | Status | assigned => resolved |
| 2007-08-15 10:58 | Goober5000 | Resolution | open => no change required |
