[karajorma]

Bit of an odd request today as I'm after an event that doesn't work

Basically I'm trying to explain the difference between every-time and when in the FAQ. The best way to do that of course it to come up with an event that doesn't work using when but which magically starts to work the second I replace when with every-time.

Only problem is that I must be having the best FREDding day ever. No matter what event I try it works perfectly with when. I've even tried events that I remember other people reporting failures with and they still work.

In fact the only event that I have been able to get this behaviour with involved using key-reset and quite frankly I think is down to a bug in Key-reset itself rather than when vs every-time.

So has anyone got a non-working event?

[Nuclear1]

-when
--has-time-elapsed
---180
--give-free-college-education
---nuclear1

Doesn't work.

-when
--bank-account
---<
---2
--refill-bank
---100000000000000

Doesn't work either.

Seriously though, I don't think I've seen an event not work besides human error in my years of FRED.

[Goober5000]

The only difference in the two sexps is that "every-time" is always evaluated, whereas "when" is only evaluated until its condition becomes known (either true or false).  (Although this has the side effect of making "every-time" act like an infinite repeat with a time delay of 0, so you need some sort of latch.)

Trouble is, I forget the original problem that led me to create "every-time".

[Singh]

[gimmeh beamz!!!! Event]
-when
---1>0
----fire-beam
-----Turret01
------DS

will not work. It will spawn only one beam.

[Gimm3h m0r3 b34mz!!]
-every-time
--1>0
---fire-beam
----turret01
-----DS

will work and spawn more than one beam, to quote Goober's point.

[Goober5000]

That's not significantly different from this, though...

[yay beamz!!!!]
-when
---1>0
----fire-beam
-----Turret01
------DS
+Repeat Count: 999999

The only two differences are that this delays for a second between every beam and eventually stops firing beams.


There are two potential examples that would illustrate this sexp well.  One is something that needs to be updated instantly... say, assigning a distance to a variable.  Another is something that could potentially become false even after being definitively decided as true (a weird and uncommon situation).

[Singh]

hmm

got one!

If you want to have a variable that activates only when Alpha 1 is a certain distance from an object, but ONLY when hes there for a few seconds, then every-time would be more in use, since it updates faster than the repeat count, as it refreshes at 0 seconds as opposed to 1.

Don't know how the even would look lile though

[karajorma]

You can set the repeat delay to 0 you know If you do that When updates about as often as every-time.

I'm going to have to search for the original post where Goober made the every-time SEXP. Only problem is that I think it was invented to deal with key-reset problems.

[Goober5000]

It wasn't, that much I know for sure.

EDIT: Here it is.  It was created to deal with "repeat" problems:
http://www.hard-light.net/forums/index.php/topic,22675.0.html

[Goober5000]

Aha!  I think I know what it is!

FS2 short-circuits evaluation of sexps once they become true.  For example, with the "is-destroyed-delay" sexp, FS2 replaces that sexp internally with "true" once the ship is destroyed.  Since the ship isn't coming back from the dead (we hope), the sexp no longer wastes time on evaluation.

Key-pressed seems to be one of those sexps that is short-circuited.  As soon as the key is pressed, the sexp is overwritten with "true".  This means that as soon as the sexp repeats, it thinks the key is still being pressed and so it re-executes as soon as the repeat delay is up.

That's why every-time works... because it resets the entire sexp tree to "unknown" after it's evaluated.  Aside from flushing the tree it's exactly the same as when.

The solution is to add key-pressed to the list of sexps that aren't short-circuited, but that might screw up something else.  And that doesn't explain (1-4) acting differently from other keys.

[karajorma]

Yeah. The mission I made for that did involve key-reset and for that matter so does yours I'd imagine since it involves pressing keys. (I'll download it to make sure though)

I'm sure there must be some SEXP I can make an error with by short circuiting it in this way but I've tried using the = SEXP (Which I had prevously had problems with) and it worked.
 I also tried Random but it misbehaved with both Every-Time and When (which I half expected).

[Black Wolf]

If you just want an example of when every-time is superior to when, using it to do that fake gravity I came up with awhile back (or to simulate tractor beams or whatever) results in much smoother motion than when.

[Sesquipedalian]

Here's one:

Code: [Select]

when
     >
          distance
               Alpha 1
               TestShip
          500
     send-message
          Too far from TestShip! With a repeat count, this event will keep sending the message even if Alpha 1 moves back to less than 500 meters from TestShip.  

Using every-time will ensure the message is sent only while the distance is greater than 500, and not whenever it is less.

[karajorma]

Really? I've used distance events several times and not seen that! I'll test it out though

[karajorma]

Tried it Sesq and it worked fine with when.

Gonna look at Goober's original every-time mission now.

EDIT : As I suspected the every-time SEXP is being used with Key-pressed and Key-reset.


I suspect I'm going to have trouble explaining what every-time is for seeing is four of the FREDders (including myself) who use it the most have now looked in and none of us have been able to give an example apart from key-reset where it should be used instead of when

[karajorma]

Originally posted by Black Wolf
If you just want an example of when every-time is superior to when, using it to do that fake gravity I came up with awhile back (or to simulate tractor beams or whatever) results in much smoother motion than when.

Did you try using when with a repeat delay of zero? Until recently I thought that you could have a delay of zero in a repeating event but TopAce pointed it out to me and when I tested it I found that when was at least as fast as every-time.

Try the mission I'm attaching. Pressing F will show you how many times every-time repeats in a second and pressing T will do the same for When.

Try changing the when's in "Begin Every-time" and "End Every-time" to every-time for some rather interesting behaviour (It loops forever!)


In fact I think that actually gives me an example of something you can use every-time for!

EDIT : Nope. Worked with when. I wish I had this much luck getting events to work when I was FREDding missions rather than tests

[Black Wolf]

You know, if you're having this much trouble documenting it, it might be an idea to leave it undocumented (or just put basic "Fires constntly" or whatever) until someone comes up with a problem for which the solution requires every-time rather than when. Then you get your example, and a new FREDder realizes what a helpful, friendly place HLP can be.

[karajorma]

Problem is that means something of a re-write and it makes it harder to explain every-time argument too.

Still I think you're right. But I was actually having fun testing in FRED again. Been a while since I last did that

[Sesquipedalian]

Originally posted by karajorma
Tried it Sesq and it worked fine with when.

Someone might have fixed something then, because IIRC that same scenario gave me trouble one time, and was what prompted me to finally bother with every-time.

[Goober5000]

Here's one documentation tidbit that should probably be added: you can't use is-event-[true|false]-delay with every-time.  Since the sexp is flushed after each execution, it's never flagged as "complete" (and thus is always "incomplete").

[karajorma]

Yeah. I noticed that one. I will have to remember to incluide it.