Do pistons with TCP and waits still work synchronously?

#1

1) Give a description of the problem
Hi all. I’ve read a lot about Wait and TCP, but still couldn’t figure out the answer so asking. I have a piston where a virtual switch flips, runs through the piston, one device in the middle has a wait time of 3 seconds, a few more things happen and then the virtual switch flips off. All set to never cancel and running synchronously. I am finding that the virtual switch doesn’t take into account the 3 second wait of the previous device.

2) What is the expected behaviour?
the piston would run synchronously and even though never cancel is set, would still wait the 3 seconds of the previous device change.

3) What is happening/not happening?
(PUT YOUR INFO HERE)

4) Post a Green Snapshot of the pistonimage

image
image.jpg1518×1282 172 KB

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

#2

3 secs might be too short of a wait in this scenario. Test it out with a longer wait, start at 15 secs.

#3

Agree. I have to use at least 6 seconds with one of my locks.

#4

I am not quite clear what the problem is that you have, but I can tell you that none of your ‘Never Cancel’ settings will actually do anything.

The Task Cancellation Policy is all about ‘scheduled tasks’ and you don’t have any in your piston.

When you run a wait task it can be implemented in two different ways:

  • If the wait is five seconds or over, or there will be less than ten seconds of execution time available to the piston when the wait finishes, the piston will schedule a wake up for the end of the wait period and it will then exit. The piston will wake up at that time and, provided this ‘scheduled task’ hasn’t been marked as cancelled, it will fast forward to the end of the wait and continue with the piston.
  • Any other wait will be implemented by a timed loop in the code. So more often than not that includes any wait of under five seconds.

If the piston gets fired while another instance of it is executing it will, by default, ‘wait at a semaphore’ for up to ten seconds to give the executing instance a chance to finish (that is usually plenty of time). However, if a previous instance of the piston is in the middle of a long wait it will have exited and set up a scheduled task. So nothing stops the new instance running immediately. As it executes it may encounter conditions that have changed since it last ran. That raises the issue of what to do with any ‘scheduled tasks’ that were set up previously. Are they still needed if the conditions that led to them being created are no longer the same? The default TCP says that they aren’t and cancels them. You have the option to change that behaviour so the scheduled tasks still run.

So as you can see, there is no benefit to setting the TCP to ‘Never Cancel’ on an action that doesn’t include a wait task (or a similar task that involves long waits, like certain fades). There is also no benefit to setting the TCP on an action that includes wait of less than five seconds (except for bigger pistons that might have already been running for several seconds).

#5

Thank you for responding. I guess I misunderstood the “never cancel” and thought it prevented a piston from canceling out steps if the trigger changed. The problem I had was that the piston was canceling out intermittently. I unfortunately deleted the last log where this happened but it seemed the piston was running through and the virtual switch turning off at the end was cancelling out the piston, since the trigger was the virtual switch turning on originally. That’s the way it seemed from the log. said condition 2 turned false so it canceled or something along those lines. So, this is what led me to my initial question on if the piston ran in order. My assumption was that the piston should run through, wait for 3 seconds and then run the rest.