Duplication in template content

[crabmusket]

As it stands, the Torque3D download is pretty big. A certain amount of that is unavoidable, but one thing really gets me: there are four templates, two of them near-exact duplicates (Full and Full PhysX), and the other two subsets of the first two (Empty and Empty PhysX). The Full PhysX template is almost 250MB. Surely we can devise a way to share assets between templates?

Aside from download size, this would also have advantages in maintenance. For example, if we want to make template script changes, we wouldn't have to modify the same script four times, or leave three templates unmaintained. The game/core and game/tools directories would particularly benefit from this.

[brenttaylor]

Having not looked at it, I take it the difference between them is simply what files are included in the visual studio C++ project for compilation? And probably a couple of macro's specified. If my assumptions are correct...

Once the code has been updated and released for Toolbox, I think it'd be best to simply add PhysX support as a flag at project creation time. Multiple templates wouldn't be needed at that point.

[crabmusket]

Yes, the scripts are identical except for a few name changes from 'Full' to 'Full PhysX'. The project config files are different, of course.

Lukas made a sort of improved project generator (forum thread) which was kind of what I had in mind. Even for scripts - for example, you could select which assets to include, maybe large portions of the default scripts, etc. I guess that's a little more advanced than simply removing that redundant 250MB, but I can dream, right?

[thecelloman]

Can git handle a directory as an 'external' like svn can? If so, we should suggest that the core and the tools directory be set as an external that would propagate through all Templates. That way if anytlhing is modified in say the Full Template's core or tools scripts then those changes wouldn't have to ported or maintained across all Templates, those other Templates would simply pull from the ones marked as external.

That said, I'm of the opinion that the Templates should officially be refactored, trimmed, and reduced by at least one script package level. I had done that for the Community Edition project, and once I get the CE ported to the MIT version we will only be sharing/supporting the CE Starter Template (with optional physics flags for either Bullet or Physx) in the CE fork.

[brenttaylor]

@icelloman
Not that I'm aware of, nor is google giving me anything that fits quite what you're asking for. Good idea though.

On that note, I'm partial to having templates be nothing more than a script that builds a project rather than it just being a full project copied over. It requires a little more setup but would drastically reduce disk requirements.

[crabmusket]

@icelloman See this SO question for some Git versions of externals. I think both of them require separate repositories. That's an option, though IMO it's a bit messy to create separate repos for templates.

@brenttaylor I agree. A toolbox rewrite would help this along ;P.

[brenttaylor]

@eightyeight If you think a rewrite is a good idea (or otherwise for that matter), mind piping up in the Issue #17 discussion?

[DavidWyand-GG]

@thecelloman:
From my research, Git does have a form external. However, it is more complicated for a user to keep the main repo and any external repos up to date when both "checking out" and "checking in". I believe it is impossible to handle from GitHub for Windows or Mac alone. We decided to go for easier access and a larger repo size.

@ALL:
Between the templates with a similar name (Full and Full PhysX) there are similar scripts and nearly identical assets. Between Empty and Full there are differences. We could see about moving to a more modular pick-and-choose situation to cut down on the repo size. That would be especially helpful with the "core" scripts and assets as a start.

[losinggeneration]

Having used git submodules before, they're really not too much more complicated if you tell people to clone with --recursive. If they forget to add --recursive, the can still get there with this:

git submodule init
git submodule sync

With that said, I've seen people get submodules wrong quite frequently (at the repo level.) For instance, some people try to edit .gitmodules directly and think that's enough. In all, it's probably easier for most people to not have to worry about it (as it's not quite as automatic as svn externals.)

[thecelloman]

Closing this issue since two whole Template projects (Physics) were removed due to the new features of the Project Generator introduced with the 3.0 release.

Considering this resolved despite some duplicate content remaining within the supported Template which will go away when the modular template system is finished.