Jump to content

Arcane FX


vbillet

Recommended Posts

Hi All,

 

Will Jeff join this forum?

Apparently.

 

Any plan about Arcane FX?

Lukas is right, I'm mostly working with Unity these days, however, an MIT Licensed version of AFX is about 95% done. I'll admit that work on this had been excruciatingly slow, but it's almost ready.


Status:

  • currently works with T3D 3.6.2
  • includes almost everything from the commercial version
  • primary AFXDemo heavily adapted to current scripting practices
  • secondary project added featuring minimal AFX variant of Full (adds spellcasting turret and flying damage text)

Link to comment
Share on other sites

No way, the real Jeff Faust was taken hostage by a Unity cult and forced to do the most horrible things like use Unity engine.


All kidding aside, welcome to the new forums and glade to hear you're close to getting AFX MIT'd. Now on to the real topic of this discussion, it is true you're really Stanley Tucci in disguise? It would explain your frequent inactivity being busy doing acting work and all. ;-)

Link to comment
Share on other sites

Arcane FX: It's like adding chocolate to AN ELECTRICAL STORM!


Joking aside, this sounds like great news. I'll be looking for this when I get around to making elemental weapons and spellcards for my game. I'm coming up with the concept for a FPS-RPG type game. (maybe 4-player co-op, but probably single-player)

Link to comment
Share on other sites

  • 1 month later...

A new version of AFX is complete and ready to be released under an MIT license, just like Torque 3D.


Status:

  • currently works with T3D 3.6.3
  • includes almost everything from the commercial version
  • primary AFXDemo heavily adapted to current scripting practices
  • secondary project added featuring minimal AFX variant of Full (adds spellcasting turret and flying damage text)

 

Additionally, GarageGames is delisting the commercial AFX product and has given me permission to release a number of assets, including Orc and Space Orc models as part of an MIT licensed version of AFX.


The only real subtraction in functionality from the commercial version is that I removed the scripted pieces of UAISK+AFX. This was done because I didn't know the status of UAISK in regards to MIT licensing, and it also simplified the task of refactoring the scripts. I don't think it will be difficult to add back in if users are interested.


Moving forward, I'd like to know from the community:

What is the best way to integrate ArcaneFX into GitHub so that it works well with the Torque 3D release?

My experience with GitHub is limited and I'm not sure what the best practices are in this situation.


Keep in mind that AFX, in its entirety, consists of:

  • modifications and additions to T3D source code in ~/Engine/source
  • two custom project templates in ~/Templates
  • modifications to T3D.inc in ~/Tools/projectGenerator/modules
  • some PDF docs in ~/AFX_Docs

 

Left to do:

  • finalize release notes
  • create proper MIT licensing documents
  • integrate into GitHub

 

- Jeff Faust

Link to comment
Share on other sites

:shock: good news Jeff, thanks for all of you work! I'm very new to torque3D but since I came, always heard good thing about arcane fx ;) . About the best practices in github @buckmaster can help you with this, you can upload to github, from there SC and the community can help to work well with the latest version.

Link to comment
Share on other sites

Been using SourceTree myself, so these'll be shots from that, but I've come to think of git like a chunk-based* svn.

So setup structure:

http://i.imgur.com/KjDWCgk.jpg

main fork:

http://i.imgur.com/hjqjm5N.jpg

Working branch:

http://i.imgur.com/b1XI5oK.jpg

Add/Subtract Files and chunks.

http://i.imgur.com/hPRnw1J.jpg

and push

http://i.imgur.com/OwEMjDS.jpg


If there's anything in particular you want to throw into the main repo, that would likely be best doen with a sub-branch based off of the development fork and thrown over by way of PR (you'll find that on your github html page)


*chunk based because for versionary purposes, conflicts arise from line collisions, not file-collisions.


also: squeeee :D

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@buckmaster - I've considered doing AFX as a module. It's a great idea in the abstract, but in reality, it's not practical. @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.

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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.

Edited by Azaezel
Link to comment
Share on other sites

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'...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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/commit/8737a7929ebaf0c7ae88087833e46998b33ce801 for instance could be taken out of the one chain and PRd by its-self with impunity.

Link to comment
Share on other sites

  • 2 weeks later...

https://github.com/Azaezel/Torque3D/tree/afx_full starts in on converting it over to 3.7 specs. Time of writing, it's in a compilable state.*


Notes on commits where I flipped a coin:

https://github.com/Azaezel/Torque3D/commit/f767dce9f457e6743bf6b2e6a6c53cc5319948f5 contains the conflict resolutions, all but one of which were simply a case of things being commited to the same spots. Since that's too large to list the resolutions, left a line-note for you https://github.com/faustlogic/Torque3D-plus-AFX/commit/4bc14bdbf620341aed6c43727580e7e7c9af5480


https://github.com/Azaezel/Torque3D/commit/d5f69a150e3f220ed94d5225e6b23d24fd1f537e contains a cmake module with afx being included on by default.


*Where (will you?) be wanting that type of thing pushed?

Link to comment
Share on other sites

*Where (will you?) be wanting that type of thing pushed?

Actually, I'm not really sure... feel free to make suggestions.


On a related note, I'm trying to figure out the best strategy for branches. Currently the AFX-fork's master branch just modifies the T3D master which seems straight-forward and obvious. I'm not really sure what to do with the AFX-fork's development branch in its current form, but would like to have a branch which effectively starts with the AFX-fork's master and folds in changes from T3D development and then continues to track the T3D development branch at some reasonable frequency.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...