Game Development Community

Questions about protocols for code/script sharing.

by Chris Calef · in Torque 3D Professional · 09/23/2014 (6:28 pm) · 4 replies

Hey, I feel like I should know this, but I haven't been around for a while... when you have mods you want to share with people, I have a couple of questions as to where exactly you need to set things up. (Or directions to a tutorial/forum thread would be great.)

First, if I have new engine code files, how do I add those to the project manager so they will be incorporated into the new solution/project files? Second, with script file changes, do people generally alter the Empty/Full Template files directly, or do they make a new project and make all of their VC project changes and script changes there?
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Azaezel
#1
09/23/2014 (8:00 pm)
Speaking strictly for myself, I've found that since the main repository is stored on github nowadays, far simpler to create a branch and make any source/script alterations to share with the class there. Particularly since you can link straight to the line(s) under dsicusison or a given step for instance. Though That does mean you might end up with more than a few stray branches lurking around if you don't intend to suggest incorporating em straight into the engine proper.

Daniel Buckmaster's got a pretty good writeup on using that toolset here. (Personally, I've taken to using sourcetree, since I follow several folks forks.)

The project manager (or cmake soon) is fairly automatic when it comes to copying files from full or empty into a working directory.

On adding additional libraries whole-cloth: The last convo I can recall on the topic would be here.

Associate Chris Calef
BrokeAss Games
#2
09/23/2014 (9:04 pm)
Thanks Az! Those were very helpful links!

Torque Owner Daniel Buckmaster
T3D Steering Committee
#3
09/23/2014 (9:58 pm)
We always recommend not working in the Templates, since that'll have it hard for you to pull updates down. In the same way that we recommend not adding any commits to the development and master branches - it makes it hard to update, and to pull-request if that's your thing.

If you're sharing a substantial source addon, a good way to do it is to create your own project generator/cmake module. This means people can include it on a per-project basis.

Associate Chris Calef
BrokeAss Games
#4
09/24/2014 (9:41 am)
Hm, right, that makes sense.

(And btw, thanks very much for that awesome git slideshow Daniel! I had already acquired most of the knowledge from the first one the hard way but would have _loved_ to have seen that a while ago - looking forward to more of them!!)

One thing thing that just occurred to me is that I probably just screwed up massively by merging changes from T3D into my branch, instead of rebasing. I'm trying to update my fbx branch, which hasn't seen any updates since it went online, and the merge went pretty well. However, now that I've pushed them to my github fork I'm wondering, would anyone who wanted to pull from my fork now end up with a huge pile of commits clobbering those same commits that they have already applied, and creating a huge nightmare for them? Or would git be smart enough to recognize that it was all the same stuff and ignore it?

If the former, I may end up just starting this branch over, the code for it is more or less self contained... but maybe a revert and rebase would fix it...?