2022-12-01 13:17 EST

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0000082FSSCPgameplaypublic2012-07-01 00:32
Assigned ToGoober5000 
Product Version 
Target Version3.6.14Fixed in Version3.7.2 
Summary0000082: Repeat count sexp does not work reliably
DescriptionThe 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.
TagsNo tags attached.
Attached Files

related to 0002667resolvedGoober5000 Repeating chained events always repeat 



Goober5000 (administrator)

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.


CP5670 (reporter)

Last edited: 2004-01-28 03:24

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


CP5670 (reporter)

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.


Goober5000 (administrator)

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. ;)


taylor (administrator)

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.


taylor (administrator)

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.


taylor (administrator)

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. :)


taylor (administrator)

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.


kasperl (developer)

Has there be any progress on getting this in CVS?


taylor (administrator)

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.


CP5670 (reporter)

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.


taylor (administrator)

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.


Goober5000 (administrator)

*knock knock* ;)

I'm on a bug closing spree and would like to resolve this. :D


taylor (administrator)

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. :)


taylor (administrator)

Fixered... but not in CVS yet.


Goober5000 (administrator)

Considering Murphy's Law, I think we should always keep bugs open until the code is actually committed to CVS. ;)


taylor (administrator)

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.


phreak (developer)

has this been committed then?


taylor (administrator)

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.


CP5670 (reporter)

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)


taylor (administrator)

Not going to work on this.


portej05 (reporter)

This is old. Very old.


chief1983 (administrator)

Karajorma might be interested in this.


karajorma (administrator)

Oh, very well. I might as well take a stab at it myself. :p


The_E (administrator)

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).


Goober5000 (administrator)

CP5670 would have to answer that, I guess.


The_E (administrator)

If you use the second mission attached here (repeat bug.fs2), you'll see it for yourself.


karajorma (administrator)

Fix committed to trunk@8603.


niffiwan (developer)

Fix committed to fs2_open_3_6_14@8722.


Goober5000 (administrator)

Reopened as a placeholder for adding a mod.tbl flag.


Goober5000 (administrator)

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.)

+Related Changesets

-Issue History
Date Modified Username Field Change
2004-01-25 05:25 CP5670 New Issue
2004-01-25 23:42 Goober5000 Note Added: 0000103
2004-01-25 23:42 Goober5000 Assigned To => Goober5000
2004-01-25 23:42 Goober5000 Status new => assigned
2004-01-28 03:16 CP5670 File Added: sexptest.fs2
2004-01-28 03:17 CP5670 Note Added: 0000125
2004-01-28 03:24 CP5670 Note Edited: 0000125
2004-03-09 03:52 Rga_Noris Summary Repeat count does not work reliably => Repeat count sexp does not work reliably
2004-03-21 15:48 Goober5000 Priority normal => low
2004-05-25 01:47 CP5670 Note Added: 0000954
2005-03-14 19:59 Goober5000 Note Added: 0001934
2005-03-14 19:59 Goober5000 Assigned To Goober5000 => taylor
2005-03-14 20:40 taylor Note Added: 0001951
2005-04-19 10:29 taylor Note Added: 0002182
2005-04-24 10:35 taylor Note Added: 0002242
2005-07-22 03:17 taylor Note Added: 0002856
2005-08-24 07:37 kasperl Note Added: 0003136
2005-08-24 10:40 taylor Note Added: 0003143
2005-09-22 12:24 CP5670 Note Added: 0003448
2005-09-22 12:43 taylor Note Added: 0003449
2005-10-31 22:07 Goober5000 Note Added: 0003696
2005-10-31 22:38 taylor Note Added: 0003697
2005-10-31 22:38 taylor Status assigned => resolved
2005-10-31 22:38 taylor Resolution open => fixed
2005-10-31 22:38 taylor Note Added: 0003698
2005-11-26 19:59 Goober5000 Status resolved => feedback
2005-11-26 19:59 Goober5000 Resolution fixed => reopened
2005-11-26 19:59 Goober5000 Note Added: 0003942
2005-11-26 19:59 Goober5000 Status feedback => acknowledged
2005-11-26 21:14 taylor Note Added: 0003943
2006-04-13 13:03 phreak Note Added: 0005324
2006-04-13 13:37 taylor Note Added: 0005329
2006-04-13 16:20 CP5670 Note Added: 0005331
2008-07-17 12:23 taylor Note Added: 0009445
2008-07-17 12:23 taylor Assigned To taylor =>
2008-07-17 12:23 taylor Resolution reopened => open
2009-06-07 11:47 portej05 Note Added: 0010961
2009-06-07 11:47 portej05 Status acknowledged => confirmed
2009-06-18 12:32 chief1983 Note Added: 0010980
2009-06-25 16:21 karajorma Status confirmed => assigned
2009-06-25 16:21 karajorma Assigned To => karajorma
2009-06-25 16:22 karajorma Note Added: 0010994
2010-11-12 08:01 The_E File Added: repeat bug.fs2
2010-11-12 08:02 The_E File Deleted: repeat bug.fs2
2010-11-12 08:05 The_E File Added: repeat bug.fs2
2010-11-12 08:08 The_E Note Added: 0012454
2010-11-12 21:31 Goober5000 Note Added: 0012456
2010-11-13 02:29 The_E Note Added: 0012458
2012-03-08 10:19 karajorma Changeset attached => fs2open trunk r8603
2012-03-08 10:19 karajorma Note Added: 0013410
2012-03-08 10:19 karajorma Status assigned => resolved
2012-03-08 10:19 karajorma Resolution open => fixed
2012-05-02 07:35 niffiwan Changeset attached => fs2open fs2_open_3_6_14 r8722
2012-05-02 07:35 niffiwan Note Added: 0013504
2012-06-18 01:24 Goober5000 Relationship added related to 0002667
2012-06-23 06:18 Goober5000 Note Added: 0013708
2012-06-23 06:18 Goober5000 Assigned To karajorma => Goober5000
2012-06-23 06:18 Goober5000 Status resolved => assigned
2012-06-23 06:20 Goober5000 Target Version => 3.6.14
2012-07-01 00:31 Goober5000 Changeset attached => fs2open trunk r8920
2012-07-01 00:32 Goober5000 Note Added: 0013741
2012-07-01 00:32 Goober5000 Status assigned => resolved
2012-07-01 00:32 Goober5000 Fixed in Version => 3.7.2
+Issue History