lastlegacy.us

I bet there'd be many new possibilities if there were a "sleep" function that pauses a thread and only resumes it by using variables.

Ideas using this:

• Block-made elevators with multiple stops.
• Collected Tri-coins losing their value under a certain condition, but ONLY when they are collected.
• Earthquakes that are only able to stop under a certain condition, but then resume under the same condition being removed. This might be useful.
• Platforms that only play when standing on them, pausing every time you get off (might require a secondary thread to work with it, since using "sleep until on ground" resumes it anywhere).
• ...And other things I'm too lazy to think up.

Maybe these ideas are already doable somehow, but I doubt having this function would bring nothing new to the table.

the sleep function is now deprecated. What you described is quite similar to callbacks, which will be the preferred way of doing things. We're going to have a script compiler at some point that translates old scripts into new scripts.

instead of:

Code: Select all

doSomething
sleep(10)
doSomethingElse


it will probably be

Code: Select all

doSomething
execute(10, doSomethingElse) // calls 'doSomethingElse' in 10ms


We're using Java's built-in script interpreters as our scripting engine. So its literally javascript. As for threads, the scripts will most likely run in a thread pool, so you can think of each script running in its own thread, however they're really just sharing 4 or so threads. Because of this, pausing a thread is not at all recommended since if all threads are sleeping, the entire scripting engine would halt.

And before anyone asks "Why not just give each script its own thread?" The overhead for creating a thread is really high and there are also way more opportunities for scripts than before.

In the current version, you can do:

Code: Select all

1 do stuff
2 sleep 1
3 if g_var==0 goto 2
4 do other stuff

Which will just keep repeating the sleep function until "g_var" is set to something other than 0, then continue the thread.

KABOOM wrote:In the current version, you can do:

Code: Select all

1 do stuff
2 sleep 1
3 if g_var==0 goto 2
4 do other stuff

Which will just keep repeating the sleep function until "g_var" is set to something other than 0, then continue the thread.

I've been aware of that already, but thank you for the input. What I was trying to suggest, though, was slightly different (but I guess this is too similar then), but now it appears it doesn't matter anymore, since there'll no longer be sleep functions anyway.

"goto" is also going to be deprecated. We have not yet decided on what to replace it with yet.

lulzaraptor wrote:"goto" is also going to be deprecated. We have not yet decided on what to replace it with yet.

Any news on this?

If it still hasn't been decided (and sorry in advance if none of this makes any sense or is impossible because I don't really know javascript or how it works), I feel like the numbered lines system as a whole along with the 'goto' function should probably be removed if possible, and replaced with something else. It's annoying to use, and outdated anyway. Some sort of branch labelling system might work better for triggers (since it'd probably be a little too much to try to implement methods and stuff into those).

And also adding some way to swap between the graphical trigger code editor and a text-based version using the trigger language would be beneficial, because while the graphical drag/drop version is really nice especially for people who don't have a ton of experience with programming, it gets a little bit annoying and clunky to use when you're using a lot of triggers at once. Increasing the maximum number of lines (not really sure if there is one, but I remember having problems last time I played with triggers on a large-scale) would probably be necessary to go along with this.

End of this post also has a bit more on my thoughts in the context of a different suggestion.

Some sort of branch labelling system

Short programming history lesson time!
You used to write programs like this:

Code: Select all

gosub sayHello
exit
sayHello:
     print "hello world"
     return;


The compiler would translate that into

Code: Select all

10 return_address = 30
20 goto 40
30 exit
40 print "hello world"
50 goto $return_address


People realized that it was redundant to always have to save the return address. This was resolved in newer languages and eventually we get something like this:

Code: Select all

function sayHello() {
    print("hello world");
}

sayHello();


And also adding some way to swap between the graphical trigger code editor and a text-based version using the trigger language

We're currently working on something that evolved from the trigger system. It allows swapping of engine code with scripts. It might remain a developer tool only due to its unsafe nature.