Removing the console/scripts

#1 I once considered this as a good idea, but I don't know how deep everything is connected. The console and script go hand-in-hand, but then the console is a part of the GUI. If you wanted to keep the console, that would probably make it difficult+1.

If you know little about Torque and its perks/practices/features, then I recommened you hold off on this goal for the time being.

#2 Rather than removing the console...

You can just delete the *.cs files, and leave the dso files when you distribute your program. Been talked about in depth in another forum. Unbind the console command (which will supress the console), and don't include the cs files.

The reason you don't want to get rid of the scripting, and why every major title (without exception) the last several years has used some form of scripting is because it's a lot easier to change things, and try them out, with a scripting language than hard code.

It makes modifications easier. It makes it easy to write good modifications. It makes writing add ons better. It makes distributing updates easier, etc.

If you want to hide game logic, you're better off simply not shipping the cs files. If you want to be really anal, you can do a crc check on the dso files (or a md5 or shs), and be relatively positive they've not changed.

Scripting gets you a lot of "try this, see if it works" without having to even exit the game. If you use Tribal, for example, you can set breakpoints, step through the code, etc., you can change the code, and cause your changes to the script to immediately take effect without having to restart the game.

#3 How do you un-bind the f functions? I want to use it as a real game so that people won't be able to edit it

Thanks,

Gabe

#4 One way of doing it :
- distribute only .dso file
- disable script compilation during run-time (you will have to take care of the main.cs file needed at startup)

#5 You can edit defaults.bind.cs (I believe) to control what options are available for the user.

Really, don't be too concerned about locking down the user. If your game is designed properly, then the user won't be able to screw with anything even if they do have access to scripts (Multiplayer game rule #1: Assume the player has compromised the client).

To remove the map/gui editor from visibility/immediate accessibility is the work of a few minutes.... and as Tribes/Tribes 2 have shown us, people appreciate having access to the map/gui editors, even if it's not obvious.

#6 I know this is a old thread but what about some one that has tge and compiles there own code and then exec it from the console. I know that it can be done, just dont know how much damage it can really cause.

#7 Why would you leave the console in your shipping game? All you have to do is not bind ~ to open it, no need to remove anything else. But really, theres plenty of tricks someone who knows TGE could do if they really wanted to.

#8 Why wouldn't you leave the console in your shipping game? It's hella useful to a player even if they're not trying to cheat! Quake, Doom, Unreal, Farcry, Quake Wars, Crysis come to mind... being able to instantly tweak settings on the fly, even if it's just the color of your name... that's huge.

#9 One reason to not want the console is to reduce download size. I'm looking to ship a casual game hopefully within about 6 months. There really isn't a whole lot of reason for the player to need the console or the editors for my game in particular. I mean I hardly need them lol, so it will just make it easier to support the game especially considering the audience I am going for. No need to complicate things when 99.9% would probably not even wonder if there is an editor.

If I was making a FPS then hell yeah. I want to give the community everything in order to mod and customize but it would be with a big disclaimer that I would not be doing any support for the editors. Too much of a headache for a small operation.