Ok this is weird
For some reason whenever I call an unveiled predicate it only reports it’s value when the block was started, not it’s current value
It made this exact block before and it worked fine but now it doesn’t
I figured it out, it’s a bug with the true/false switch block
Yup, the evaluated (regular) boolean input gets ran only once, when it gets the value to use. Unevaluated doesn't call the input before it runs the block, which allows the input to be called multiple times, with the ability for the input to change over time.
Yea but I made my own system for it, but I do like the other ones too
The problem with that is, if you reset the timer while it's waiting, it would wait even longer.
Timer can always be replaced by the current time timestamp in things like this if timer isn't suitable
Plus, the timer is only accurate down to the tenth decimal place, while millisecond calculation is accurate to the thousandth.
Here's a version using milliseconds:
The variable x, in this case, is a boolean (unevaluated).
I actually didn't think about that.
((1000) * (Secs)) is a conversion to ms, but (timer) reports secs.
EDIT: I think you meant to use current [time in milliseconds]) instead of (timer).
Yes, that's what I meant. I never said I could program. :~/
This implementation apparently consumes slightly less processing time than @pajamaclaws21's (excellent!) function - I used [Boolean (unevaluated)], too.
I compared both implementations through the following script:
On my system, running in Turbo mode, @pajamaclaws21's implementation permitted the parallel counter to reach between 200,000 and 250.000, whereas my implementation consistently facilitated 300,000+. It's not a huge difference of course but significant nonetheless.
On the other hand, with my implementation one needs to be careful when specifying the interval, because the waiting thread will keep running until the end of the interval.
All things considered, this is a really useful block for making games
… and this version consumes even less processing time:
(800,000+ parallel counts on my system; in the test set-up as described in post 13, that is)
Huh. That's quicker than WAIT UNTIL? Because you could replace any WAIT UNTIL with that, right?
I suppose so. Perhaps not under all circumstances - I could run some more tests. The downside is the script-itself’s response to events maybe somewhat slower. In this case (@cookieclickerer33 apparently wants to use it to wait for a player’s feedback) that shouldn’t be a problem.
Wait untill does the test 60 times a second and yours does the test 20.
So youre faster.
The more checks it does, the more responsive it is. Less checks does not always mean better.
True. Which is better depends on the application, and whether you want the software to do other tasks in parallel.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
