#Cancel event async
sullen pilot
alright
the reason why I'm using async threads in the first place is to be able to halt the thread as opposed to just using runnables
because runnables are not reliable for example when waiting inside of a loop
like you can have a repeating task but
if you wanna have an additional wait inside it
then it'll only wait for the code inside the runnable, not the code after as well
elder wedge
Hm, why do you need to wait inside of a loop though?
sullen pilot
I'm translating code from a minecraft server into java code (so that you can take your minigames off the server and onto your own) there's a wait block pretty much identical to thread.sleep in said language and I need to implement it
elder wedge
Why not use runTaskTimer set to run every tick then?
sullen pilot
wdym
elder wedge
Things in Minecraft can only change every tick anyways, so it's effectively the same thing.
sullen pilot
ok so say I have
loop{
// something
wait(5s)
if(something) wait(5s)
// something 2
}
with a bukkit scheduler
to actually halt the code after the if statement only if the if statement is true
I mean you just can't even do that
which is why I'm using thread.sleep instead, but for that I need an async environment
as to not freeze the server thread
sullen pilot
No, I mean that in this example if the wait in the if statement ran, the code after the if statement would execute after a total of 10s since the start of the iteration
hope that makes sense
you could substitute Thread.sleep into wait in my pseudocode
elder wedge
You could, but that's where your problems are arising.
It might be harder to implement nested Bukkit schedulers, but all these issues would probably be easily solved if you used them.
sullen pilot
Yeah that was my initial approach but like how
elder wedge
Lemme see if I can write an example for what you sent using schedulers
sullen pilot
alright
elder wedge
//Start the loop, since it's executed every tick.
new BukkitRunnable() {
@Override
public void run() {
//Wait for 5 seconds.
Bukkit.getScheduler().runTaskLater(Experimental.getInstance(), () -> {
if(true) {
Bukkit.getScheduler().runTaskLater(Experimental.getInstance(), () -> {
//Do a thing after 10 seconds.
}, 100);
} else {
//Do another thing after 5 seconds.
}
}, 100);
}
}.runTaskTimer(Experimental.getInstance(), 0, 0);
Then you can call this.cancel() anywhere in there to stop the loop.
sullen pilot
so basically everything after the if statement needs to be written twice
elder wedge
Well, only because you have two different wait(5) calls
sullen pilot
yeah but that becomes a problem when you nest those types of if statements
it'd be unreadable
not that essentially matters but I'd like to keep it at least a little comprehensible
at this point it may not be possible though
elder wedge
Well but that's how you would do something like this in an actual plugin anyways
If you had to wait 5 seconds, check something, and then wait another 5 seconds to do something completely different, you'd nest schedulers.
I mean, waiting in Bukkit is straight up only achievable correctly with scheduling.
So if you have to wait twice, you need two schedulers.
sullen pilot
well I'm stubborn but hey this works, I tried with a few api calls as well
new Thread(() -> {
event.setCancelled(true);
Bukkit.broadcastMessage("Cancelled!");
}).start();
try{Thread.sleep(1);}catch(InterruptedException ignored){};
Bukkit.broadcastMessage(String.valueOf(event.isCancelled()));
@elder wedge
I've probably broken at least 3 coding conventions with this implementation but lmao
elder wedge
That cancelled?
sullen pilot
yep
elder wedge
Wild lol
sullen pilot
I just replaced the scheduler with a java thread
elder wedge
Me waiting for it to randomly break 