|
|
Huh? Screenshot or something please. |
|
2009-11-13 07:41
|
2021a.jpg (138,785 bytes) |
|
|
Repeat count and interval are useless for every-time so they should be set and/or locked. |
|
|
For the umpteenth time, the every-time sexp is NOT equivalent to an infinite repeat. It's a very specialized sexp that should be used extremely rarely. It's also a completely different concept to the repeat count -- if you're using every-time when you should be using repeat instead, then "ur doing it wrong", to coin a phrase. Furthermore, repeat count affects the whole sexp, whereas every-time only affects a node tree. Suppose you have something like this: when --some temporary condition --do some stuff --do some other stuff --every-time ----do some specialized stuff Repeat might be necessary to continually check that temporary condition. Now granted this is an extremely unlikely edge case, but it illustrates the fact that the two concepts are not the same. |
|
|
I realize that and the only reason I am using ever-time is that a repeating when either with a trigger or repeat count is not reevaluating the conditions for this particular event. Every-time does that. Believe me I don't want to use every-time but am forced to in this particular instance. The thin is that when ever-time is the root of the event the other options are meaningless and just letting them be changed is misleading. |
|
|
If it's misleading, the FREDder shouldn't be using that sexp. As I said, repeat count and every-time are two totally different concepts. We've been saying for a while now that FREDders shouldn't be using every-time unless they have a very good reason. Furthermore, in the most recent mission I FREDded (for SA) I *did* use every-time in a repeating event. It wasn't in the root node, but it was part of the sexp and it served a very important function. So if we change the behavior here, it will confuse the issue for people who *actually know what they're doing*. I'm closing this as "no change required". |
- Anonymous
