What is the are the *.dso files for?

#1 The .DSO files are compiled versions of the .cs scripts.
They get compiled weverytime you run the .exe file and start the game.

Once the .DSO files are created you dont really need the .cs files anymore. Unless you want to make changes to them.

Btw. don't delete your .cs files :)

Everytime you make a change to the .cs files you have to delete the corresponding .DSO file or else the engine will execute the .DSO instead.

// Clocks out

#2 actually the engine checks if the timestamp on the cs file, so if it can tell if its been modified and recompiles. But if theres an error compiling then it will use the old dso.

#3 Just started learning here and im trying to figure out how to not allow people to get in and edit my game so they can just play it....

Can I use the dso files for that purpose? Do you still need the .cs files when giving the game to someone.

#4 wow, this is old, ( a week after i got the engine)

after your game is complete and ready to ship, you can remove all the .cs files then noone will be able to edit your game.

[added]

basicly the .cs files are the SDK for your scripting engine

#5 I hate to be a bother, but isnt there a .dso decompiler? I've heard it when I coded for t2, cause I didnt want other people changing my mod, and my friend told me that there is a .dso compiler.

Please tell me this is impossible ;)

#6 Just do what Ace suggested.

There is a certain amount of risk being taken by doing this. You increase the odds of your game crashing.

Why hide it anyway? Just think of where you would be scripting-wise had Tribes2 done the same.

That was a rhetorical question, btw. ;-)

Eric

#7 I had a guy on my server once talking about decompiling some .cs.dso files so I started asking questions. It turns out (the way he was doing it, at least) that you need some version of the .cs (can be older) to start with to really get anything figured out. It's necessary because the compling is similar to zipping a file. Goto the top of a .dso file and you will see every STRING in the whole .cs there, but no code. So I assume if you have some background information on what the file kinda has in it, you can pick through the rest and end up with a basic idea of the code. I don't think there this guy was using any program other than maybe a hex editor.

There's a chance someone made a .dso decompiler, since there is a .dso compiler. Perhaps someone with Torque source figured it out?

#8 Could be; really, it should be kept in mind that binary executable files can be decompiled too (ie, C/C++ code). This problem is hardly unique to DSO files ;)

Much like piracy, any determined person will be able to get in and examine your (compiled) code. They won't get your beautifully written, witty comments, and often times won't get variable names, but they will be able to reconstruct the code given time.

So... Don't worry about it. GG owns the Torque source, and you own your script files. If anyone steals it, and puts it to any real use, either you or GG can (and should!) sue them.

And, of course, users _love_ games they can poke around with. How many developers here got their start testing the limits of other's games? ;)

If you're really lucky, you might get the equivalent of counter strike for your game. It would've been awful hard for them to write CS if Valve hadn't been nice enough to distribute their game code. (which is equivalent to scripts in Torque; I'm not advocating distributing the Torque source illegally, just the scripts.)

#9 Im not worried about people "stealing" my game. Im worried about people hacking it. As far as I can tell MOST things that have to do with how a vehicle handles is done in these .cs files. I wouldnt want someone jacking up the values so that his vehicle can go light speed or something. Is there other protection methods in place to prevent this?

#10 Yes... it's called client/server architecture...

-J

#11 I think he means people hosting a server with edited scripts being a problem, not people sending fabricated stuff back to the server to make them move faster, etc. You could of course write all the variables for the datablocks down in compiled engine code if you were psychotic and that would prevent modification of anything you hard coded in.

#12 Unless somebody modified the server EXE...

If you can't trust the administrator, you're screwed! This applies to any kind of server. Even halflife is susceptible to having the server hacked.

Even if you're writing a MMORPG or something, you STILL need to be able to trust the server admins... Or at least be able to identify trustworthy servers with a master list or something.

If you can't trust the client or the server, you've left yourself nowhere to stand.

#13 Unless you use some sort of bizzare encryption system and they can only play on a special console you made, and you administer all the world in the game, hehe.

#14 Is it possible to disable dso compiling?

#15 From and including: Tuesday, 1 October 2002
To and including: Tuesday, 29 March 2011

It is 3102 days from the start date to the end date, end date included

Or 8 years, 5 months, 29 days including the end date
Alternative time units
3102 days can be converted to one of these units:

* 268,012,800 seconds
* 4,466,880 minutes
* 74,448 hours
* 443 weeks (rounded down)

#16

Quote:
From and including: Tuesday, 1 October 2002
To and including: Tuesday, 29 March 2011

It is 3102 days from the start date to the end date, end date included

Or 8 years, 5 months, 29 days including the end date
Alternative time units
3102 days can be converted to one of these units:

* 268,012,800 seconds
* 4,466,880 minutes
* 74,448 hours
* 443 weeks (rounded down)

That was a good laugh. :)

@Nikitin: The source version of the engine allows you to do so.

#17 Err, K.

@Nikitin: Anyway, the use of

$Scripts::ignoreDSOs = true;

will disable DSO compiling. I've also used this with the TGE demo, so it should work for you.