First time user impressions, include dts versions of dae files in repo?

#1 You're right in that it's probably better to make them wait during checkout/download than the first time they run a game. It's just that most of us have this mindset that you shouldn't store anything that can be generated. Part of that is that you don't want to store it if there's a possibility that it could need to be regenerated because of an update and this somehow doesn't happen - you'd be using the old .dts (for example) when the new .dae is available.

I'm up in the air on this one - either provide the .cached.dts files or make it very clear that the first time you run a game it must generate these files and so takes a long time to start. And that documentation might run on into explaining how to remove the .dae files for distribution/deployment of your game when you're getting ready to ship - we don't have a good guide for that, either.

You're probably right - for many, first impressions are everything.

#2 Yeah, and dts is really a pretty concise format. For that matter, why even include the dae files in the release at all? They could easily be available as a resource for people to test loading them, without having to slow everybody else down.

Are people still working on those art assets anyway? If they are it would also be a minor step for them to go ahead and compile to dts when they're done working, instead of every starting user having to wait for it.

#3 Cached DTS files should definitely be not included in the repo. The release packages need to be revamped for new users. If you're a newbie to Torque, or just evaluating it, you shouldn't be encouraged to clone the repo - we should provide packages with binaries, art, etc. The engine repo should have completely minimal script templates. The current templates should be separate projects entirely, to be honest.

The 3.6 release will be our first time testing and discovering what release packages we need to provide. This will probably be packages of just binaries, just binaries with Empty template or Full template, and then if you want the whole shebang you can clone the repo.

#4 Right, Daniel, I forgot everybody doesn't got straight for the repo. :-P

So in the binary releases at least are we currently shipping cached dts files instead of daes?

I like where you're going with removing the templates into separate projects as well! Leaner and meaner...

#5 Ah, sorry - I think the problem is that everybody does go for the repo, as it's their only sensible option. We do have downloads, but they're actually just the repo contents, so really no difference. Every release so far has not included the cached DTS files.

The 3.6 release will break this pattern by providing different download options, and some of those options (the ones which include art) will include cached shape files for exactly the reason you describe.

#6 Nice! Well, glad to see the great minds on the steering committee are already on top of this problem! :-)

#7 Why not another option of a prefs flag of "firstTime"? If it is first time running, show an extra dialogue window warning the user that the first time will be extra long thanks to cached shape generation. Then set it to 0 and never show that dialogue again.

Doesn't need any extra direction or download types and still solves the potential problem of people getting a bad first impression, and instead fully understanding that is it just how the template is designed to first run.

#8 That still leaves open the question of why we want to take up their time doing something that could have very easily been done once by a developer instead of a thousand times by every new user, as well as why we need to ship these models in a large and inefficient plain text format instead of a very efficient binary format. For the binary release builds, that is.

It seems like it's just there so we can say "look how cool we are, we're importing collada!" :-) Which is cool and all, but why make every new user wait for it?

#9 Would probably advise stripping the .daes for binary, and .cached.dts (and remember, there's still a couple normal.dts files layin around) for source, since with both in a repo, if it finds a newer dae than dts it'll just regen it anyway.

#10 'Binary' release refers to the executables. We'll consider providing 'production' demos without source art, but honestly I don't see the benefit of removing it. I think the majority of the download size comes from textures, not DAE shapes, though I haven't actually analysed that in detail. I have checked, however, compression, and the DAE shapes compress much better than the DDS textures.

I agree with Chris that the real fix is to pregenerate those files, rather than to just apologise for not doing it.

#11 Actually, they could be pre-generated during the automated release build, I think. Isn't there a "generate dso's" command line flag? Could we add a "generate dts'" flag? Then TeamCity (or whatever you use) could just call it after the compile step to generate them. Then no one has to do it - it just happens.

You guys are using an automated build system for binary releases, right?

#12 Richard - I'm just setting that up right now :P. Also, we use Jenkins.

#13 Ah. The reason I brought up TC is that it's what GG was using internally to build, well, just about everything. There should already be projects pretty much set up in there.