DSO's are'nt being made

#1 DSOs are basically not required anymore, as they will be generated on the device at runtime (since the real 1.3 release)
by not having them at all you save space and ram on the device and you can ensure that its always the up to date scripts.

Unsure if the non-generation is by intend though, but I would guess: yes

#2 I wonder if it's expected that you include the .cs files into the final release now instead of .dsos? Seems bad to send out the source with it. I certainly can appreciate the not having to deal with DSO during development but need a way to not send the source out at least.

#3 Marc, I'd recommend that you still generate DSOs first at 1) they should lod faster than .CS files and 2) should be smaller in your .app as they are binary instead of text. Then you should delete you .CS files and only ship with your .DSOs. Besides, you don't want people seeing all of your funky script code anyways :)

#4 Luke is correct, build your game - AT THE END, make sure theres a clean folder of resources, generate DSO's, and remove cs files. There was a script for that included in 1.3 im sure

You may also want to look in the code for TORQUE_ALLOW_DSO_GENERATION

#5 OK, I peek a look there but I don´t understand C++.

What should I do to allow the DSO generation? Allow this is mandatory for my project, otherwise it dont works.

Thanks

#6 I have uncommented the TORQUE_ALLOW_DSO_GENERATION and I still can't get DSO's to be generated when i run the app.

Are DSO's generated by a Mac/Windows executable or can they be done directly by running the app?

I compiled and copied over the Mac executable but after I generated the DSO, the following is logged as error messages in the console:

exec: Found an old DSO (/Users/terenctb/Library/Application Support/iPhone Simulator/3.1.2/Applications/683DAEFD-B521-46A0-A1FB-1DD42338FA47/Last Call.app/common/main.cs.dso, ver 41 < 42), ignoring.

Not sure how to fix this. Our app is pretty much done and I just need to figure out how package it and submit it (hopefully not to get rejected because of the OS 4.0 debacle).

#7 I'm in the same boat as you Terence :(

I'm having the same issue here. Using T2d for iPhone 1.3. Compiling against 3.1.3 device OS device. In my final steps before submitting. Are we supposed to be including the .cs and forgetting about the .dso now? Runs fine on the device. I guess this has been going on the whole time I have been developing this app and I didn't notice. I have very few scripts and only two behaviors.

I don't have an issue with just leaving the .cs even though I prefer the .dso. I just want to know what is expected. What is the official stance of Garagegames? Would it be a reason for rejection from Apple?

#8 Are you looking inside the actual bundle, ALONGSIDE the cs files? Mine compiles DSO's - If it says :

ver 41 < 42

This usually means the DSO's are being compiled without PUAP_SCRIPT_CHANGE, if the mac project is not using these flags the DSO files are the wrong version. Make sure thats defined (im seeing it on the ones in the zip i have).

@ Michael

You should use DSO files. Not cs files. Build them using the mac app, and deploy using only the dso files. There should be a script that i included in the tools folder for "stripping" the cs files, leaving only DSO files (if a dso exists).

#9 I build and deploy to the iPhone without DSO files and it works fine - I'm assuming they are being made on the iPhone by the runtime interpreter (JIT?). Using 1.3.1

#10 I know about your tools Sven (much appreciated) I'm off to work and probably won't get to look til tomorrow or Friday. I definitely would like to use the .dso's

They definitely are not being made so I will investigate when I can. Thanks for giving me a heads up of where to look.

#11 The key thing here is that IF DSOs are required then surely the program should compile them at publish time (e.g when you select build to distribute)... it seems strange that if thats they way it should be done, that we have to go scratching around deleting CS files in the app file and ensuring DSO's are built..

It might be me misunderstanding things, but surely the tool should make these things easier, not make more steps for the developer.... (thats if i am not misunderstanding the conversation).

#12 I agree with Jason that the final packaging is problematic. My current process is:

1) Clone the current xcode project to include only the .dso resources.
2) Do an svn export to export scripts over to the a 'build' directory containing my resources
3) Make sure a Mac App is there compiled with PUAP_SCRIPT_CHANGE
4) Run the mac app to "compile" the scripts to DSO's
5) execute the clean up script(which I actually couldn't find), so i'm doing a 'find game -type f -name "*.cs" -exec rm -rf {} ;'...doing the same on the common directory(I may have an older script file layout)
6) Hop over to Xcode. Make sure all the resource are added. Build and compile a package
7) For some reason even when my main.cs has been added as a resource, it's not copied over..so manually open the package and drop the main.cs in.

Issues
1) I can't find the 'scripts' used to clean up the cs files....according to the docs it's called "clean_cs_script.sh". I have done "find" and can't locate it.
2) Having to manually copy the main.cs is a pain.
3) I think running a Mac app to compile is flawed because for those that have created new engine code that is iPhone only, we would have to make sure it works on the mac too. I worry about scripts not all getting compiled.
4) Had to modify line 200 of levelManagement.cs to check for 'dso' files as well:

//Before the level is loaded, load this levels datablocks - Sven
   	
   if(!isFile(%dbFileName) && (!isFile(%dbFileName @ ".dso")))
   {
      echo("--------::: No datablocks for this level? Level will still be loaded! Watch for errors.");
   }

5) Had to modify line 97 of projectManagement.cs to check/run dso files:

addResPath( %userDatablockFile );   
   if( isFile( %userDatablockFile ) || isFile( %userDatablockFile @ ".dso"))
      exec( %userDatablockFile );

This is my suggested way to do packaging, if we could make it happen this way.
1) Have another buld option in xcode that enables script generation
2) Run the build in xcode iphone simulator to compile the scripts
3) Run scripts to remove the dso files
4) Run the build again for the device this time to package it

#13 Okay, I need some clarification here ...

All I do is:

- in finder - find all .dso files and delete them for the app
- in xcode, clean and build
- deploy to iPhone

I don't do any of the other stuff and now I'm a little worried.

I could do with someone explaining how the DSO files are built on the device - I'm assuming you NEED the .cs files on the device otherwise all bets are of. I'm guessing because I build the DSO files on the device I don't need to play the game in TGBGame on the Mac to generate the DSO files - otherwise I'd have to play 60 levels every time which seems crazy - I load the new level at the end of the previous level as an "exec "....datablocks.cs" script command.

#14 They need to be built FOR the device, not ON the device. The device does not have write access to the .dso paths. You just happen to be able to run plain script files in the most recent version of the engine. If you're using any earlier version than 1.3.1, you might run into issues like the scripts not being compatible with both the desktop and device versions of the engine. See flags mentioned above.

#15 I think you're a bit confused here. The *.dso file are compiled script files that are ONLY needed (or strongly recommended) for final submission to AppStore. You can get away with using only cs files straight from xcode (editing there as well) which is what I have been doing (i.e. not using an external editor such as eclipse or editing on Windows)

You don't need the cs (script) files as they are compiled to dso files which Torque uses (being pre-compiled, loads faster and makes it so you script don't appear in the final package)

Bleh Ronny beat me to it...

#16 Thanks Ronny and Terence - can you confirm then that I DO have to play the game end to end prior to uploading if I want to have DSOs?

I am using 1.3.1 so is there any performance difference between running the script on the device and compiling a DSO using the TGBGame engine on the Mac?

#17 or you can compile one time on 1.2 and copy the dso files into 1.3.1

works for me

#18 1.3.1 should be compiling it all for you. Better check the doc PDFs!