Lyberta {l Wrote}:What about the halting problem?
dulsi {l Wrote}:The complexity is the drawback. You have to know where you are in every script. You have to craft the script with the knowledge they may not complete at once.
It is also common to use an embedded language like lua or python or javascript. In most cases the engines probably don't support this mode so you would need to code it up yourself.
However if the game had cinematics that take control away from the player, this solution won't help if the cinematics script is stuck.
By which I mean running a couple of bytecode instructions each game update instead of running a whole script at once.
onpon4 {l Wrote}:By which I mean running a couple of bytecode instructions each game update instead of running a whole script at once.
That would be largely pointless. If you're running the scripts independently of the rest of the code, you would do that with multithreading. Then you also get the benefit of parallelization of computing. But it doesn't work well for every game. Sometimes the engine needs to wait for a script to finish, and if that happens often enough, what's the point of parallelization? In fact, trying to run scripts at an arbitrary rate in parallel with the engine can easily cause important synchronization to be lost; imagine, for example, you have a script which walks your character 20 meters to the right before shutting a door behind him. If the script is running 2 times faster than it should, or more likely the game is running only half as fast as it should, then the door shuts before the player makes it, breaking the game. This can not be a problem depending on the game, but otherwise, it's just not worth it.
the point is giving modders a safe way to create high level game logic without actually giving them control over the software.
that is obviously something nobody competent would solve by waiting a specific time
This doesn't make sense. Scripting is intertwined with the game engine somehow; otherwise it would be useless. You can't completely separate them.
:shrug: I guess I'm incompetent then.
But this is not the only sort of situation that can cause synchronization problems. It's just the easiest example I could think of.
If I understood your proposal correctly, and please tell me if I'm wrong, you're proposing for the script interpreter to stop interpreting, arbitrarily, outside the scripter's control, after a certain amount of instructions or time, and then continuing what the game engine wants to do (effectively, advancing a frame) before continuing with the next couple lines or whatever of the script.
when simple parallelization would be much more reliable, simple, and have all the same problems.
farrer {l Wrote}:On former DNT (which is a RPG), using an own script language, I've used the approach of 'n' executed lines per script at the main game loop. The biggest drawback of this approach was letting the main thread (DNT was almost single threaded, with the exception of A* search and sound play) depended of the scripts. If I do remember acordingly, I've defined a global max number of lines could be interpreted each cycle. When much scripts are running, each script could take 'forever' to be resumed again, otherwise it will affect for worse the game's frame rate, etc. And a script taking forever to resume, is for sure a not-very-responsive one, which, for the user, isn't a good thing to have.
On current DNT, using AngelScript, I use mostly a secondary thread for script execution, running on its own frequency, totally independent of the renderer thread, but implemented as a scheduler (one script per time, with a maximum of lines per script). The result is much better than the previous one. The main thread could still call a 'direct-result' script function (usually for retrieving a value), but it's not often (for consistency, they lock the script scheduler. And couldn't be suspended. if not returned in 'x' time, they are removed, but we'll miss the return value, which will probably result on a failure somewhere else).
Also, on both, there's a concept of 'pending actions'. Those are actions that need more than 'immediate time' to finish (for example, character walk to a position, or even a delay function). Those will suspend the script, that are put to 'sleep' (ie: our script scheduler will not call to resume this script) until they are finished.
On both. there's no problem of a infinite loops stalling the application. But, maybe the problem is just dislocated to 'zombie' scripts (but not 'zombie threads or a 'zombie main game'). But a zombie script is a mod-failure, not the application fault, I believe.
Not sure if I explained it well. Probably not.
Sauer2 {l Wrote}:I kind of have trouble to make sense of the first paragraph, to be honest.
In particular, what was the drawback of letting the main thread depend on the scripts if you had a limit for the interpreter?
farrer {l Wrote}:Sauer2 {l Wrote}:I kind of have trouble to make sense of the first paragraph, to be honest.
In particular, what was the drawback of letting the main thread depend on the scripts if you had a limit for the interpreter?
Let's see if I can explain without messing it up. The main loop itself has its own frequency, dependent of the fixed frame rate (usually 30 or 60FPS). The simplest approach could be, each frame, just call a single line for a single script (in fact it was up to n-lines of a script, and up to 'x' lines for all scripts, cycling between them until have x lines or all scripts ran at that cycle... example: 3 lines per script and up to 12 lines treated per rendering cycle).
If there isn't the global limit the frame rate could drop considerably when with lot of active scripts (even with non-fixed frame-rates... remember that with vsync set by driver option, the frequency could be fixed beyond application control).
But with this global limit, with lots of scripts active, one script should only be resumed after too much time passed since the last time it ran before, being with a considerable delay from the action it detects or expects or made happen. That also happens on complex scripts, with lots of lines.
That's the drawback of this old - naive - approach I had. Hope it's better understandable now.
c_xong {l Wrote}:So the easier solution would be to monitor the health of the script, and terminate if it is unresponsive. I believe a lot of games do this already. It's really up to the script writer to fix such problems, there is no good general solution.
Sauer2 {l Wrote}:c_xong {l Wrote}:So the easier solution would be to monitor the health of the script, and terminate if it is unresponsive. I believe a lot of games do this already. It's really up to the script writer to fix such problems, there is no good general solution.
... So, the answer for Lua and most other interpreters is to modify the interpreter to have a volatile cancelling flag in its interpreter main loop?
Lyberta {l Wrote}:Wait, is there an ability in Lua implementation to set the maximum time the function call may take?
// The line callback function is called by the VM for each statement that is executed
void LineCallback(asIScriptContext *ctx, DWORD *timeOut)
{
// If the time out is reached we suspend the script
if( *timeOut < timeGetTime() )
ctx->Suspend();
}
The hook mechanism of the debug library allows us to register a function that will be called at specific events as your program runs. There are four kinds of events that can trigger a hook: call events happen every time Lua calls a function; return events happen every time a function returns; line events happen when Lua starts executing a new line of code; and count events happen after a given number of instructions.
Lyberta {l Wrote}:Wait, is there an ability in Lua implementation to set the maximum time the function call may take?
Users browsing this forum: No registered users and 0 guests