So when a function ends, i want another one to start. However, i want the new function to be separate from the function which ended.
One way of doing this would be by firing a remote event, and have a event listener which connects the new function when the event is fired from the function that ended.
Either execute the new function in a coroutine whenever you need too, or just connect an event listener thatâs all - since you want them separate, which I assume means you want them in different threads.
Iâm trying the methods you have listed right now, but just for clarification hereâs what i mean:
So my code is something similar to this (the layout):
local function example1()
examplecode
end
local function example2()
examplecode
end
I want example 2 to be connected when example1 ends. However, i donât want this:
local function example1()
examplecode
wait(exampletime)
example2()
end
because then when example2 ends, it goes back to example1 to run any remaining code. Thatâs what i mean by separate. If i were to use the remote event function example, it would be separate, because when example2 ends, thatâs it.
Iâm just wandering if there is a simpler way to do this instead of the remote event example. Please keep in mind i wanât this to be all running off one thread. (Iâm making a Intermission/Round system)
I have a chain of functions. I wanât each of them to run one by one, by being connected by the function that ran before them.
I do not want that code to run.
I donât want for example2() to be connected inside example1() because when example2() ends, it connects another function which in the end causes a whole chain of functions, all leading back to example1()
By one thread i mean one continuous chain of functions, which fire the next function in the chain when the function has finished.
Basically i want a continuous chain of functions, starting from function 1. When function1 finishes, i want function2 to start, however i want function2 to be separate from function1 because of answer 3
If you have any other questions, please feel free to ask.
Okay, but is it dynamic? What I mean by that is does it always go eg:
fn1() â fn2() â fn3() â fn4() â fn1()?
Or could it also possibly for instance be eg:
fn1() â fn3() â fn4() â fn2() â fn1()?
example1() gets disconnected and reconnected by another system in the script. If i were to disconnect example1(), it would go straight onto example2(), even though example1() wasnât fully finished. Thatâs why i need a chain of functions that go onto the next one after one has finished.
For clarification, that âother systemâ goes through all the players in the game, and checks for a value to be true. If less than 2 people have that value to true, interrupt the Intermission function, and make it restart. If 2 or more people have the value to true, then donât interrupt the intermission, and if the intermission manages to finish without being interrupted, that system is deactivated, and the round begins (function 2). Thereâs more to it, and what iâve said so far doesnât really make sense, but you get the idea.
Sounds like you just need one more level of indirection such as:
function example0()
local ok = true
repeat
Intermission() -- example1()
TeleportPlayers() -- example2()
ok = RoundSystem() -- example3()
until not ok
end
If by âinterrupt the Intermission function, and make it restartâ you mean call Intermission again,
you can simply have Intermission() return a value that represents that it was interrupted, and
just put another loop within the loop that calls Intermission(), and break out of it if it can move on
to the next function.
I think its better if i just keep it as it is. Tbh i canât even remember why i wanted to separate those two functions. I think i was just haunted by the fact that my gameâs core game mechanics scripts would pretty much rely on one function.
I did find out a method, which is to use :GetPropertyChangedSignal on a value to trigger function2, but itâs probably better to not separate the functions.
It sounds like iâm absolutely crazy and donât know what iâm talking about, but itâs hard to explain.