View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000082 | FSSCP | gameplay | public | 2004-01-25 10:25 | 2012-07-01 04:32 |
| Reporter | CP5670 | Assigned To | Goober5000 | ||
| Priority | low | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.6.14 | Fixed in Version | 3.7.2 | ||
| Summary | 0000082: Repeat count sexp does not work reliably | ||||
| Description | The repeat count feature sometimes fails to work; the events only fire once even with the repeat count and interval are set to something else. I haven't been able to find out exactly what combinations of events cause it but it seems to be related either to chained events or coincident repeat intervals for multiple repeating events. The severity of this bug depends entirely on the mission; it may do nothing at all or it may stop a mission from working properly. I got the latter result in two missions (that worked fine in 1.2) that had capital ship battles controlled directly, with fire-beam events repeating at regular intervals; the ships stopped firing after the first salvos and since they weren't getting destroyed, the gameplay and events got completely messed up. This occurs with the 01_20_2004 version, although I have seen it with many earlier versions as well. By the way, can one of you admins add in a sexps category for the bug reporting here? This sort of bug would probably fit into that. | ||||
| Tags | No tags attached. | ||||
| related to | 0002667 | resolved | Goober5000 | Repeating chained events always repeat |
|
|
Meh, I'd rather leave the SEXP category out. Gameplay vs. FRED is clearer, methinks. Can you post the earliest build that this showed up in? Look in the "Afterburner Bug" thread for a list. |
|
2004-01-28 08:16
|
|
|
|
Okay, now I am really confused. I spent the last hour trying various things with this and it looks like the problems are occurring in all of the versions, including 1.2. However, I distinctly remember that one of my PI missions that worked fine in the original version started having problems with the SCP versions at some point, so I have no idea what could be happening here. To make matters even worse, there seems to be another problem in the events; for some strange reason, the game thinks the chain delays are all zero, again in all of the versions. I uploaded the generic test mission I was using here; it was made with the original FRED2 and both problems (repeat count and chain delay) seem to occur reliably in all versions. Look over the events to see what is supposed to happen and then play the mission to see what actually happens. Any ideas? edited on: 01-28-04 03:24 |
|
|
Goober, since I sent you that email on this issue it seems that the random element in the whole thing is gone and the "case 2" I described there is what is always occurring. I was using this mission to test my changes to the media vp beamglow effects and I tried it ten or so times with the 5/03 version, always getting case 2. This is somewhat good news aside from the fact that the randomness is gone, since case 2 was marginally better than case 1, but the main problem is still there. For the rest of you, here is a copy of the relevant bits in that email. Anyone else have any clue what is going on here? It's really starting to get on my nerves as it turns out that a lot more of my missions are affected by this than I had thought earlier. -------------------- Here is what the chains of events in that sexptest mission are supposed to do, where x is an integer between 0 and 10: 1: At the beginning of the mission (0 seconds), both ships' turrets are set to be locked. 2: Every 10 + 25x seconds into the mission, the Lilith fires its beam. (so this happens at the 10 sec, 35 sec, 60 sec, etc. marks) 3: Every 15 + 25x seconds into the mission, the Aeolus fires one of its beams. 4: Every 18 + 25x seconds into the mission, the Aeolus fires its other beam. And this is what actually happens in the game: 1: At the beginning of the mission, both ships' turrets are locked as desired. 2: 10 seconds into the mission, all three of the beam events fire, i.e. the Lilith shoots its beam and the Aeolus fires both of its beams, all simultaneously. 3: Every 10 + 25x seconds into the mission, the Aeolus fires one of its beams (the turret12 one dealt with in event4). The Aeolus's other beam and the Lilith's beam are never fired again. So there is something wrong with the repeat counts; only the last event in the chain list is repeating. Since you are familiar with mission design, you will see how this could cause serious problems in some missions. I am not sure if any of the FS2 campaign missions are affected but some of my PI ones are doing funny things because of this. There might also be a problem with the chain delays, but I am no longer really sure about this. -------------------- |
|
|
I have no idea how to fix this, and I haven't been able to come up with any new ideas. So let's play tag for a bit. Taylor, you're it. ;) |
|
|
Another bug for Taylor. Gee, thanks ;) Never even looked at this one so I'll have to play a little bit. I'll have a go at it after work tomorrow. May end up being a hot potato. |
|
|
Finally had some time this morning to look at this... Ok, it's working, but in reverse of what you specify CP5670. At 0000007:0000003 seconds in the Aeolus fires turret12 (event4), at 0000008:0000005 seconds Aeolus fires turret11 (event3), at 0000022:0000010 seconds Lilith fires (event2). It continues this in 0000008:0000025 second intervals. I'm not sure that it properly evals the last repeat yet or not but that's just my mistake if it doesn't. So I guess the only issue now is the order. I'll try and swap it around (not really sure why it backwards though) and then put out a test build. I would prefer not putting this in CVS until it's been properly tested with a mod or two and the OC. |
|
|
Now I know why Goober passed this thing off!! :P Bit of a pain, especially when trying not to break anything. I've got a basic handle on what to do though, just need to figure how to do it. That two line fix was just too good to be true. :) |
|
|
I do have this basically working at the moment. Still needs a few more modifications to work reliably, since :V: never coded it to work properly in the first place, but it will work. It's going to be at least another month before I have time to get it all done and cleaned up enough to hit CVS though. |
|
|
Has there be any progress on getting this in CVS? |
|
|
It's still not working 100%. I know this bug is annoying but I consider it minor for 3.6.7. The fact is that every mission that uses repeat counts will behave a bit differently after this hits CVS and I don't want to change something like that just before 3.6.7. I'll make the push to get it in after so that it can be properly tested without any rush to get builds out. |
|
|
Any updates on this? Now that 3.6.7 is out, maybe your fix could be added into the next beta build. I would like to try it out on several missions I have that are currently messed up due to this. |
|
|
Maybe late next week. I'm still working on the Linux and OS X versions of 3.6.7 (being released today) and I'm going to update the OpenAL sound code in CVS before moving on to these other things. I spent so much time bug fixing for 3.6.7 that I never finished with this particular bug. The new code still needs to be brought out of my experimental tree, completed (it's 98% done already), and tested in a stable tree before I can get it in CVS. |
|
|
*knock knock* ;) I'm on a bug closing spree and would like to resolve this. :D |
|
|
Probably not much work left to do on it for cleanup but it's in an experimental tree that I haven't used since I started getting ready for the OS X and Linux releases. I'll make it a point to dig up the code, test it, fix anything that's left, and get it in CVS by this weekend. There wasn't a whole lot to it, just getting the timestamps on the chained events to behave properly. The code just wasn't written in a way that it ever would have worked. I'll go ahead and resolve this though since it really is fixed, just not in CVS yet, and Goober can rest easy with one more bug out of the way. :) |
|
|
Fixered... but not in CVS yet. |
|
|
Considering Murphy's Law, I think we should always keep bugs open until the code is actually committed to CVS. ;) |
|
|
Agreed. :) I haven't had time to debug a couple of things, one major event problem may not be related to the changed code but since I don't know that for sure I'm not going to commit until I'm done testing. Something in my code tree is broken though so I'm trying to be careful about not making that a problem for the public. |
|
|
has this been committed then? |
|
|
It's not committed yet. The problem is that it seemed to cause most/all events to happen more rapidly than before. As soon as I relized that during final testing I decided not to commit the changes until that issue was resolved. I've got two different versions of the fix, but both are in different code trees which are out-of-sync with CVS and don't even compile anymore (due to the ammount of new, incomplete code). This is too low priority for me to care about right now though so unless someone else wants to fix it everyone will just have to wait until I get the time to clean up my code base and get the last issue resolved. |
|
|
I was able to work around it in my own missions quite some time ago, so it's not really a high priority thing anymore at least for me. (although it would still be nice to have it fixed) |
|
|
Not going to work on this. |
|
|
*bump* Anybody? This is old. Very old. |
|
|
Karajorma might be interested in this. |
|
|
Oh, very well. I might as well take a stab at it myself. :p |
|
2010-11-12 13:05
|
|
|
|
Issue still exists. Although events are evaluated in proper order now, only the last event in the chain actually gets to repeat. (Note: This also happens for trigger count repetition). |
|
|
CP5670 would have to answer that, I guess. |
|
|
If you use the second mission attached here (repeat bug.fs2), you'll see it for yourself. |
|
|
Fix committed to trunk@8603. |
|
|
Fix committed to fs2_open_3_6_14@8722. |
|
|
Reopened as a placeholder for adding a mod.tbl flag. |
|
|
Added a mod.tbl flag which will be present in the next SCP release after 3.6.14. (Mod.tbl isn't in 3.6.14.) |
|
fs2open: trunk r8603 2012-03-08 10:19 Ported: N/A Details Diff |
Well I find it hard to believe that in over eight years three senior SCP coders couldn't find THAT! Fix Mantis 0082 (Repeat count sexp does not work reliably) |
Affected Issues 0000082 |
|
| mod - /trunk/fs2_open/code/mission/missiongoals.cpp | Diff File | ||
|
fs2open: fs2_open_3_6_14 r8722 2012-05-02 07:37 Ported: N/A Details Diff |
Backport: Trunk r8603; Well I find it hard to believe that in over eight years three senior SCP coders couldn't find THAT! Fix Mantis 0082 (Repeat count sexp does not work reliably) |
Affected Issues 0000082 |
|
| mod - /branches/fs2_open_3_6_14/code/mission/missiongoals.cpp | Diff File | ||
|
fs2open: trunk r8920 2012-07-01 00:32 Ported: N/A Details Diff |
add mod.tbl flag for Mantis 0000082 |
Affected Issues 0000082 |
|
| mod - /trunk/fs2_open/code/globalincs/def_files.cpp | Diff File | ||
| mod - /trunk/fs2_open/code/mission/missiongoals.cpp | Diff File | ||
| mod - /trunk/fs2_open/code/mod_table/mod_table.cpp | Diff File | ||
| mod - /trunk/fs2_open/code/mod_table/mod_table.h | Diff File | ||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-01-25 10:25 | CP5670 | New Issue | |
| 2004-01-26 04:42 | Goober5000 | Note Added: 0000103 | |
| 2004-01-26 04:42 | Goober5000 | Assigned To | => Goober5000 |
| 2004-01-26 04:42 | Goober5000 | Status | new => assigned |
| 2004-01-28 08:16 | CP5670 | File Added: sexptest.fs2 | |
| 2004-01-28 08:17 | CP5670 | Note Added: 0000125 | |
| 2004-01-28 08:24 | CP5670 | Note Edited: 0000125 | |
| 2004-03-09 08:52 | Rga_Noris | Summary | Repeat count does not work reliably => Repeat count sexp does not work reliably |
| 2004-03-21 20:48 | Goober5000 | Priority | normal => low |
| 2004-05-25 05:47 | CP5670 | Note Added: 0000954 | |
| 2005-03-15 00:59 | Goober5000 | Note Added: 0001934 | |
| 2005-03-15 00:59 | Goober5000 | Assigned To | Goober5000 => taylor |
| 2005-03-15 01:40 | taylor | Note Added: 0001951 | |
| 2005-04-19 14:29 | taylor | Note Added: 0002182 | |
| 2005-04-24 14:35 | taylor | Note Added: 0002242 | |
| 2005-07-22 07:17 | taylor | Note Added: 0002856 | |
| 2005-08-24 11:37 | kasperl | Note Added: 0003136 | |
| 2005-08-24 14:40 | taylor | Note Added: 0003143 | |
| 2005-09-22 16:24 | CP5670 | Note Added: 0003448 | |
| 2005-09-22 16:43 | taylor | Note Added: 0003449 | |
| 2005-11-01 03:07 | Goober5000 | Note Added: 0003696 | |
| 2005-11-01 03:38 | taylor | Note Added: 0003697 | |
| 2005-11-01 03:38 | taylor | Status | assigned => resolved |
| 2005-11-01 03:38 | taylor | Resolution | open => fixed |
| 2005-11-01 03:38 | taylor | Note Added: 0003698 | |
| 2005-11-27 00:59 | Goober5000 | Status | resolved => feedback |
| 2005-11-27 00:59 | Goober5000 | Resolution | fixed => reopened |
| 2005-11-27 00:59 | Goober5000 | Note Added: 0003942 | |
| 2005-11-27 00:59 | Goober5000 | Status | feedback => acknowledged |
| 2005-11-27 02:14 | taylor | Note Added: 0003943 | |
| 2006-04-13 17:03 | phreak | Note Added: 0005324 | |
| 2006-04-13 17:37 | taylor | Note Added: 0005329 | |
| 2006-04-13 20:20 | CP5670 | Note Added: 0005331 | |
| 2008-07-17 16:23 | taylor | Note Added: 0009445 | |
| 2008-07-17 16:23 | taylor | Assigned To | taylor => |
| 2008-07-17 16:23 | taylor | Resolution | reopened => open |
| 2009-06-07 15:47 | portej05 | Note Added: 0010961 | |
| 2009-06-07 15:47 | portej05 | Status | acknowledged => confirmed |
| 2009-06-18 16:32 | chief1983 | Note Added: 0010980 | |
| 2009-06-25 20:21 | karajorma | Status | confirmed => assigned |
| 2009-06-25 20:21 | karajorma | Assigned To | => karajorma |
| 2009-06-25 20:22 | karajorma | Note Added: 0010994 | |
| 2010-11-12 13:01 | The_E | File Added: repeat bug.fs2 | |
| 2010-11-12 13:02 | The_E | File Deleted: repeat bug.fs2 | |
| 2010-11-12 13:05 | The_E | File Added: repeat bug.fs2 | |
| 2010-11-12 13:08 | The_E | Note Added: 0012454 | |
| 2010-11-13 02:31 | Goober5000 | Note Added: 0012456 | |
| 2010-11-13 07:29 | The_E | Note Added: 0012458 | |
| 2012-03-08 15:19 | karajorma | Changeset attached | => fs2open trunk r8603 |
| 2012-03-08 15:19 | karajorma | Note Added: 0013410 | |
| 2012-03-08 15:19 | karajorma | Status | assigned => resolved |
| 2012-03-08 15:19 | karajorma | Resolution | open => fixed |
| 2012-05-02 11:35 | niffiwan | Changeset attached | => fs2open fs2_open_3_6_14 r8722 |
| 2012-05-02 11:35 | niffiwan | Note Added: 0013504 | |
| 2012-06-18 05:24 | Goober5000 | Relationship added | related to 0002667 |
| 2012-06-23 10:18 | Goober5000 | Note Added: 0013708 | |
| 2012-06-23 10:18 | Goober5000 | Assigned To | karajorma => Goober5000 |
| 2012-06-23 10:18 | Goober5000 | Status | resolved => assigned |
| 2012-06-23 10:20 | Goober5000 | Target Version | => 3.6.14 |
| 2012-07-01 04:31 | Goober5000 | Changeset attached | => fs2open trunk r8920 |
| 2012-07-01 04:32 | Goober5000 | Note Added: 0013741 | |
| 2012-07-01 04:32 | Goober5000 | Status | assigned => resolved |
| 2012-07-01 04:32 | Goober5000 | Fixed in Version | => 3.7.2 |
