Cs vs .dso files

#1 .dso files are the 'compiled' version of the .cs file. If you were releasing a game you would want to remove the .cs files and leave the compiled .dso files.

Hope that helps.

B--

#2 The .cs files are your script files, these are the ones you edit.

The .cs.dso files are the compiled versions, these are the ones that engine uses. (I'm pretty sure that that is correct).

#3 Kinda. When I change the .cs file, am I changing the .dso file automatically? I ask because changes I make in the .cs file are appearing in the starter.fps when I run the program. If that is the case, what happens when I do delete the .cs files? Does the engine run both automatically, or must I call for .dso files in all my arguments before switching over to .dso files?

I get the sneaky suspicion these are very remedial questions...

#4 Oh, and thanks to everyone and the community. Can't forget my eternal thanks.

#5 The game needs to run the dso version.
dso is like the .exe version of your game.
cs is like the source code (.cc/.h) of you game.

You make the .cs file, the game 'compiles' the .cs file turning it into the .dso.

So, you want to distribute the 'compiled' scripts only.

#6 A few other other items that I think are note worthy.
1 - if the .cs fails to compile the game will use the old .dso file for execution. So if you ever make a change and run the game and nothing new happens, it just might be that the .cs failed to compile and its using the old .dso
2 - Sometime when you make engine changes you need to have all the .dso files re-created or re-compiled. As a result its a good idea to delete all your .dso files by doing something such as(Windows):
dir \s *.dso
from the same location as your torquedemo.exe (or whatever your .exe is named)
3 - The main.cs which is located in the same directory as your .exe is handles slightly special and you can delete it and expect your game to run. There are resources such as Eliminating root main.cs if you don't wish to have the main.cs around.

Hope that helps you avoid some trouble in the future and good luck!

#7 Sorry for hijacking the thread, but on a related topic:

Is there any reason why .dso is appended to the filename instead of replacing .cs with .dso? It's not another one of those Unix things, is it?

#8 On Windows, the compiled files are .cs.dso and the script files are plain vanilla .cs files.

So you would have
player.cs and
player.cs.dso

So no, it's not a Unix thing.

#9 You need the .dso extension to distinguish foo.cs from foo.gui; replacing would make it ambiguous.

"Another one of those Unix things"...? :)

#10 Thanks for the help, almost understanding now. Last question: when does the engine compile? During game startup?

Also, hypothetical situation. I have a directory full of .cs files, then the engine compiles. Now I have a directory of .cs files and .dso files?

Yeah, yeah, I'm dense.

#11 As files are needed (usually loaded via exec() calls) they are loaded and compiled and executed. Some files like .mis files are compiled but the results are not stored to disk.

#12 @Nmuta,

I understand that .dso are the object files. The "Unix thing" was from when I asked a while ago why the .cc extension was used.

@Ben,

I also understand that appending the .dso extension to foo.cs and foo.gui distinguishes files in the same directory. But there are also many places where .cs and .gui files are stored in different directories. So who, or perhaps, what cares if foo.dso is ambiguous? Was it purely as a visual aid to the developers or some deep dark juju in the engine? Would I be foolish to change the engine to replace the extensions (aside from the obvious 'if it ain't broke, don't fix it' perspective)?

Also see above about the Unix thing. You were probably the one who answered me way back when.

#13 James,

They're often stored in the same directory, which is madly convenient, thus it is a desirable feature.

If you want to change it, go ahead - you've got the source! :)

#14 Just to follow up on Ben's comment about changing where the .dso's are stored...there is at least one project I know of that did this with just a small amount of effort, and are very happy with that implementation.

#15 Ben,

Just to make sure we're talking about the same thing, I was referring to SomeGui.cs being in a Scripts directory while SomeGui.gui is in a UI directory as opposed to having the .dso's in some form out output folder.

My point being that if SomeGui.cs compiled to SomeGui.dso and SomeGui.gui compiled to SomeGui.dso, they wouldn't conflict if they were in seperate directories. I'd probably take it further and compile .cso's and .gso's or something to maintain the source file connection.

I just wanted to make sure there was no resource-level naming convention issue that would arise. My problem being that I have a (bad) utility that sorts files and I can't exclude .cs or .gui files without losing .cs.dso and .gui.dso.

#16 Actually, a number of the .cs and .gui files *are* currently in the same folder (especially in the editors) so if you are going to make this change to the engine then you had better account for these.

The way the official engine handles this is *not* going to change but feel free to modify your version.

#17 Yup, Matt is exactly correct.

#18 @Matt,

I realize that the editor folders are handled differently (i.e. inconsistently) which is why I was referring to the cases where they were split into two folders. I never suggested that the current layout choices where wrong or that they should be changed. However, when I run across something that seems to me to be a little odd, I like to try and find out if there was a good reason for it being what it is, or if it just is what it is. I was merely fishing for some technical or moral reason not to attempt changing my version at some point.

This mod is intendend for personal use only. Please don't attempt it at home.

#19 >Ben Garney
>Associate
>Posted: Aug 10, 2005 11:31
>As files are needed (usually loaded via exec() calls) they are loaded and compiled and executed. Some files like .mis files are compiled but the results are not stored to disk.

I seem to have .mis.dso being written to disk and would like to package them instead of mis files. The ConsoleFunction exec seems to follow a separate code path for mis files (LoadShapeFile). Could you please give some more details on that? Are particular script statements not supposed to be compiled? Or are mis files supposed to have only a certain subset of statements (Everyone would like to keep a minimum number of plain-text statements in the game package, and I assume not having to compile them might save some load times)?
(In the mean time I'm trying to make my mis.dso files exec instead of .mis to see what all that affects)
Pranav Tekchand
--
(This is 1.0.3 with some (shadow, collision) changes merged in from 1.7)
I have a "main" Mission.mis which execs other mis files (we had split the mis file into more grouped/manageable chunks).
(Mission.mis -> groupA.mis, groupB.mis, groupC.mis, ... )

Looking in to LoadShapeFile shows that it looks for a .mis.shapes file - I don't seem to have any of these, didn't find them in an example either.
Once its done with LoadShapeFile, it goes ahead and compiles and execs as usual.
Since I didn't have any .mis.shapes files, I renamed the (other) .mis files which my "main" mis file was exec[ing] to be .cs and my level loaded up except for certain textures which had transparency in them were no longer transparent - this seems odd - any ideas?
Also buildLoadInfo which is called from missionLoad.cs searches for the plain-text MissionInfo object in the "main" mis file (which should get exec[ed] from a dso too?).
--
The transparency issue turned out to be matrials.cs not being exec[ed], loadMaterials() in client/init.cs was changed to search for materials.cs.dso if the cs files weren't found to fix this. Similarly ParticleEditorStartup.cs was also searching for cs files.