thelink2012
commented
4 years ago My observations in this regard:
- That could possibility leave the game in an invalid or unspecified state. If we halt a script mid-execution it could leave a task incomplete, dangling handles, corrupted memory, and other things that could make the game state unreliable, but since the game didn't crash, one wouldn't notice until things start to break (possibly some of this invalid state could infect save games).
- I have no data to support this claim, but SEH could make these commands slower, and these are commands that are expected to be fast as they compose a high percentage of the lines in complex scripts.
- Scripts can incorrectly manipulate memory in other manners. Be that with DMA, or by passing weird parameters to non-memory commands. That is, the unsandboxed problem goes way over these two commands, and is inherent to the original scripting environment.
Generalizing this a bit, since almost every command can produce problematic memory manipulation, the SEH could encapsulate the script execution tick itself, instead of only these two commands. But the first problem would become even stronger in this method.
In my opinion this is a lost cause. Manipulating memory either goes well, or it doesn't. If it doesn't, you might want to provide a recovery mechanism, but that recovery mechanism varies from case to case. As such, instead, there could be a similar command that returns a boolean indicating failure [PS: CLEO would need to handle the memset case, or even not support it]. But again, would that be useful? Would it be cost-effective for scripters to stop and think about failure recovery?
I think what I mean is, corrupting user data is worse than crashing, and this feature would go in that direction.
GoKuDead
x87
Reading and writing memory should happen in isolated and controlled manner and never cause the game to crash. Instead the error should be logged and the script shut down, while letting other scripts continue working.