Arcane FX

Friendly conversations, and everything that doesn't fit into the other forums.
38 posts Page 2 of 4
buckmaster
DEVGRU
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Sat Apr 04, 2015 3:11 am
Awesome news, Jeff, and thanks for your kindness in doing this. I think given the way T3D works currently - i.e. not incredibly friendly to plugins - it might be the simplest route to simply upload the entirety of T3D with AFX integrated As much as I dislike this approach, the alternative would be to also provide detailed install instructions and a partial repo.

Are the changes to T3D.inc necessary, or would they be accomplished by providing a new AFX module that could be enabled/disabled in the Project Manager? Similarly, are the engine changes specific to AFX, or could they be implemented in the core engine? We've already merged in some bugfixes you had for us.
Azaezel
DEVGRU
Posts: 495
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Sat Apr 04, 2015 3:22 am
AFX the sold extension is a mix of spiderwebed embedded augmentations, a custom directory for full-bore unique classes, and script samples. Module might work for the source\afx dir. Script as well to a degree (There's a few hook-in points). The rest, not so much from a pragmatic perspective.

Prime example would be datablock caching. That by necessity touches a lot of places in the engine.
LuisAntonRebollo
DEVGRU
Posts: 19
Joined: Tue Feb 10, 2015 6:20 pm
by LuisAntonRebollo » Sat Apr 04, 2015 9:57 am
@ Faustlogic, great gift for T3D community... thx a lot :)
Faustlogic
Posts: 9
Joined: Mon Feb 16, 2015 2:51 pm
 
by Faustlogic » Sat Apr 04, 2015 5:00 pm
@
User avatar
buckmaster
- I've considered doing AFX as a module. It's a great idea in the abstract, but in reality, it's not practical. @
User avatar
Azaezel
describes it well as "a mix of spiderwebed embedded augmentations". I just don't think the module mechanism can fully represent all the ways in which AFX modifies Torque 3D.
Faustlogic
Posts: 9
Joined: Mon Feb 16, 2015 2:51 pm
 
by Faustlogic » Sat Apr 04, 2015 5:16 pm
@
User avatar
Azaezel
- I'm not a total newcomer to GitHub and I use SourceTree, though I've worked more with BitBucket than GitHub (for the free private repos).

Mainly I'm looking for input on how best to setup linkages with the Torque3D repo. It looks to me like the easiest thing to do right off the bat would be to fork the T3D master branch and merge in AFX to create a T3D+AFX repo. That would be a fairly stable but static version. Then, would it make sense to also fork the T3D development branch for a more dynamic and evolving version of T3D+AFX?

EDIT: Ok, It looks like making an AFX fork of Torque3D repo, sets up linkage to all branches.
Faustlogic
Posts: 9
Joined: Mon Feb 16, 2015 2:51 pm
 
by Faustlogic » Sat Apr 04, 2015 6:44 pm
I think given the way T3D works currently - i.e. not incredibly friendly to plugins - it might be the simplest route to simply upload the entirety of T3D with AFX integrated As much as I dislike this approach, the alternative would be to also provide detailed install instructions and a partial repo. ... are the engine changes specific to AFX, or could they be implemented in the core engine? We've already merged in some bugfixes you had for us.
What makes most sense to me, so far, is to create a Fork of Torque3D (Torque3D-plus-AFX) on GitHub and merge all AFX changes into the fork. There are a number of separable pieces of AFX that might make sense to push up into core Torque3D, but I expect this would be a gradual process, and in the meantime, end users wanting to use an AFX-enhanced-T3D will develop off of the Torque3D-plus-AFX fork of Torque3D. The implication here is that somehow the Torque3D-plus-AFX needs to track Torque3D development fairly closely. Hopefully, the benefits of GitHub can keep this reasonable.
Azaezel
DEVGRU
Posts: 495
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Sat Apr 04, 2015 7:14 pm
@
User avatar
Faustlogic
: Yeah, git is pretty bright about versiontracking in that manner. At the risk of making the process annoying and drawn out, I'll note doing a commit-series allows one to use the cherry-pick command to draw just the commit from a given fork and slap it into another for anything along the chain barring conflicts or dependencies (pretty much how that bugfix chain was handled which allowed them to line item the one fix). I know I'll be wanting to set up a clone on my own repo once you've sorted through what you consider core tech vs anything you'd want to reserve as a content pack, so might go that route this end to help lighten the maintenance load.

edit: and sorry if that explanation came off as more basic than intended. topic has come up a couple times in the last week.
Last edited by Azaezel on Sat Apr 04, 2015 7:42 pm, edited 2 times in total.
Gibby
Posts: 72
Joined: Wed Feb 11, 2015 2:40 pm
by Gibby » Sat Apr 04, 2015 7:15 pm
What makes most sense to me, so far, is to create a Fork of Torque3D (Torque3D-plus-AFX) on GitHub and merge all AFX changes into the fork
That would be great!

IMHO AFX is so solid and plays so well with the rest of the code it should just become part of the engine, especially the effectron system. The demo that it came with makes it appear to be oriented toward WOW style games but it really helps with whatever genre/gametype/application you'd use it for. Need to animate propellors/ceiling fans? Need particle effects that follow paths and stay in sync? Need model animation and script functions to play well together? AFX helps with all of these things, even in projects that don't have 'magic' or 'spells'...
Faustlogic
Posts: 9
Joined: Mon Feb 16, 2015 2:51 pm
 
by Faustlogic » Sat Apr 04, 2015 10:56 pm
At the risk of making the process annoying and drawn out, I'll note doing a commit-series allows one to use the cherry-pick command to draw just the commit from a given fork and slap it into another for anything along the chain barring conflicts or dependencies
So what you're suggesting here is, rather than dumping all the AFX mods into the fork as one huge commit, I should do a series of small commits that will be friendlier for use with the cherry-pick command. Right? Sounds like a reasonable idea, although it might be difficult to avoid interdependencies when it comes to some of the more complex changes.
Azaezel
DEVGRU
Posts: 495
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Sun Apr 05, 2015 1:11 am
So what you're suggesting here is, rather than dumping all the AFX mods into the fork as one huge commit, I should do a series of small commits that will be friendlier for use with the cherry-pick command. Right? Sounds like a reasonable idea, although it might be difficult to avoid interdependencies when it comes to some of the more complex changes.
Pretty much. https://github.com/Azaezel/Torque3D/com ... 98b33ce801 for instance could be taken out of the one chain and PRd by its-self with impunity.
38 posts Page 2 of 4

Who is online

Users browsing this forum: No registered users and 6 guests