-
Notifications
You must be signed in to change notification settings - Fork 241
Description
print "Throttle should now start at 3/4ths.".
lock throttle to 0.75.
wait 0.
when true then {
print "Throttle should now move down to 1/4th but it won't yet.".
lock throttle to 0.25. // doesn't really happen yet.
wait 10. // doesn't happen yet during these seconds.
print "Now that the trigger body is finishing, NOW it will retroactively take effect and move to 0.25.".
}
wait 20. // plenty of time for the above trigger to run to completion.
print "program over - resetting throttle to 0 as part of ending program.".
This becomes a problem for people who end up putting most of the bulk of their program inside a trigger so the trigger body lasts a while - our docs never explain this fact that while you can lock throttle and lock steering in a trigger, those changes won't take effect until the trigger body ends. Even if you think people shouldn't design programs this way (putting a long wait in a trigger, or a big loop in a trigger), the fact is that the docs never explain the problem.
The docs do mention that one trigger cannot interrupt another trigger, but the hidden fact that lock steering and lock throttle are themselves implemented via triggers, and therefore they follow this rule too, is never explained to the user.
Either we fix this and make it possible for cooked control changes to take effect before the trigger body is done, or if we can't then at the least the docs would have to be changed to make things clear.