No, it's not horribly messy, you just don't understand TorqueScript namespaces or script callbacks.

It's messy compared to scripting engines in UE3 games or Second Life. It's also inefficient for purposes of a game centered around blocks. If you're not willing to do it just tell me, but saying I'm dead wrong and it's a stupid idea isn't getting anywhere.

I'm not changing the engine to add capabilities that are already present. You're not getting my point that it is already ENTIRELY possible to attach scripts to blocks.

Yes, I get that you can. The point is that it's a multi-step process to do so. The suggestion was to make small scripting like this much simpler, far enough one could even include a GUI for it.

I get it, you don't want to do something you see as redundant. That's fine.

I'm not including a "script editing GUI", because, essentially, it opens the door for huge exploitability issues, when any client can write and run scripts on someone else's server.

True, however this is true with any client-side modification system. Torque already has the ability to interface with the server with client sided scripts. If someone wants to hijack or kill the server, the possibilities are already open.

I understand the concern though, with open scripting systems it's very hard to enforce security. Even Linden Labs has problems with it.

With Torque, the client side scripts can only interface via exposed (and rank-authenticated) server commands.

Trust me, given enough time, a dedicated hacker could find countless ways to exploit it. The only way to even remotely reduce that possibility is to lock down all the scripts in dso format, like Blockland did, which pissed me off to no end.

Right now, (assuming all the server commands are locked down, which I know some aren't), the only way to exploit the server would be crashing it with a hacked binary that abuses the net protocol, and I've fixed a couple bugs that already that didn't handle invalid data correctly.

I think the whole point here is that absolutely anyone could do bad things to a server unless this was very very secure, and even if it was very secure people would still find obvious exploits within a day or two.

I actually had an idea for a debugging backdoor vaguely similar to this, and I figured that if scripts had to be approved by the host before they could run, as opposed to being allowed to run immediately without any permission and without any warning, that would make it pretty safe. Even if the host has no idea what the script is supposed to do, it could be pretty easy to figure out if it seems dangerous.

Perhaps, but that seems like it would get quite tedious after a while...

I should also point out that there's absolutely nothing preventing an enterprising modder from making it easy to transmit code from client -> server for any client/server pair that both have the feature enabled. It's trivial to send text to the server, and trivial for the server to write text to files and execute. That being said, our official FreeBuild distribution will not have this feature, as it's not a can of worms that we feel like opening at this point.