MIT resources will be merged with the Torque 3D engine?

#1 It's one of those things where it may be tossed up onto GIT, but there's a good chance that there need to be updates to them, get them aligned with the dev branch and so on.

I believe the GMK stuff is mostly there, which if that's the case, all that needs to be done is have a PR made to target the dev branch so we can review it/test it, etc.

In short, if the MIT resources are up to date and someone makes PR for them, it's considerably easier for us to roll it into the fold. Otherwise, we'll have to do the updating/vouching and PR creation ourselves, which puts it at a bit lower priority than trying to work through the existing PRs.

I think in general though, they offer features that would be pretty useful to have in there, so hopefully we can move in that direction.

#2 I just want to note that these are not 'resources', but 'products'.

But yeah, they'll most like be added if someone cares enough to go to the effort of preparing them.

#3 The GMK physics side i think really needs to be looked at before implementing into the T3D. There is nothing wrong with it, it works but it's very obvious it was designed as a "add-on" and i think it needs to be completely redesigned to fit in nicely with the current T3D physics API (yes the T3D physics API itself would require extending).

I do totally agree some of this stuff should find it's way back into T3D, it's that time thing, so few people and so much to-do :/

#4 Thanks to a fix that Dan pushed. And a very small function argument ambiguity fix. Verve seems to work. Although I must add that I haven't used it before and I don't know it very well. But it compiles and runs just fine. In its current state it feels fairly separate and would require some assimilation to be pushed into the main branch.

#5 so, in others words, if someone take the time to adapt the code and do the push request, it will be considered to merge? :)

If was useful to peoples in the past, surely right now too.

I think these products should be considered, adds more competitive to the engine. Right now some useful feature that need torque3d is a module to AI to make it more "complete".

#6 @johxz
I also planned to add resources to the engine, but around my game, so they will be added when I need them. Most changes will be on the script side, you can follow my project if you want, but my focus is to create a game, not a game engine.

#7 Where could I find the fix Dan did to fix verve?

I purchased GMK and guidebot and in my opinion they are great add on's but GMK and I believe was mentioned would need for the physics stuff to be cleaned up before it would be a good fit into the core engine codebase. Plus I think it would conflict with verve if that was added. Guidebot in it's current state isn't a standalone. It' needs GMK to operate, if someone could make it a standalone not relying on GMK and work with Dan's walkabout then we may have a solid AI solution for the engine. I have ideas how it could be done if anyone is interested in it just send me an email jstanleynwo(AT)yahoo. Nonetheless I think some of the MIT add on would make great additions to the engine to make it a bit more complete..

#8 Oh yeah, of course we should obviously note that every submission will be reviewed on equal footing for suitability for merge, code quality, etc. For example, we might only want parts of something like GMK to exist in the engine itself. The rest could, maybe should, be kept as a separate addon. Et cetera. It won't be a free-for-all ;P. But it requires someone who cares enough to make the thing compatible in the first place.

#9 Kory -

Author: Daniel Buckmaster <dan.buckmaster@gmail.com>
Date: 4 weeks ago (1/2/2015 1:38:05 AM)
Commit hash: f1da30f2853114807754eed51d0d3fa9aa58119e

Those are ints, not floats.

There is a small change on the Verve side to resolve a function argument ambiguity. As I recall casting to const char* takes care of that.

This was made in the Development branch.

#10 antony
Thanks, I'll bookmark it...

#11 I have managed to shoehorn most of those products in my current build, The problem after doing that is bloat. As a matter of fact, I am STILL working on optimizing a bit... Good tools but, messy to get working together. For example, why do I need GMK cut scene editing when I already stuffed Verve in? I don't but, GMK has that particular part of the tool set integrated across a lot of the GMK features.... The list goes on and on.

Ron

#12 @Ron bloat? I don't think is a problem. A lot of engines are huge in size.

The point is not abandon good products... and do maybe a "complete" engine, others engine out there have more stuff to offers to people, but you need to paid. Torque3D has the advantage that is MIT and good people are doing good products in it. Let's take the good stuff and at least add to the roadmap haha

#13 Bloat is a problem. Think of it this way, you have so many 'cycles' in which to calculate, AI, Pathfinding (yeah that is two things), Collision, rendering, sound, key presses, etc, etc,etc.

If the engine is busy 'calculating' something that is NOT being used at the moment, it takes away from the overall performance. In my example, why calculate for two systems that essentially do the same thing? It's a bad idea from the start. Additionally, Bloat is already a problem in T3D. I do not like nor do I use the ground cover tool. (I use the forest editor for all of that). So why reserve the memory and allocate the registers? Those are valuable resources and trust me.... players will notice if frame rate or performance 'hic ups' happen.

Just some info FYI. A FAT engine with a ton of bloat, is NOT what you want.

Ron

#14 Ron, trust me, GroundCover isn't taking up any registers unless you have a GroundCover object in the mission - but that's not to say I don't agree with you that there's a lot of bloat that won't be used in any particular game.

I think the important thing to focus on is disentangling different parts of the engine from each other so that it's easy for users (developers) to remove parts they don't want. For example, the forest - it's in its own directory, but you can't just nuke it.

On the other hand, it's also very important to make sure we don't make it difficult for people to make addons and so on. If we go changing the engine source significantly every release, it means addons are likely to become incompatible.

It's a fine line to walk.

#15 I think the work should be done the other way round, the products should be maintained in compatible branches to the engine so they become 'simple' merges. If you know you never need updates to the products you can take them and merge them, but this to some extent makes the engine even bigger and more complex. While this is fine for the end user the actual number of people working to actively maintain the engine is a far far too fragile few, and in my opinion increasing the complexity will eventually take its toll on the few that are working hard since garage games abandoned the engine.

With regards to rons comments about bloat, from what I can gather from my cursory looks at most of these products is that some, are designed to be integrate to the engine and are fairly well optimised afx and walkabout for example, GMK is poorly optimised within its own system and it kind of bolts onto torque, and verve is very similar, in that its almost an external tool.
NB there are other products that i own(ed) but havent really toyed with for long

Some things need rebuilding from the ground up, some like walkabout has had some of its features creep into the engine.

tldr; somebody needs to maintain the plugins separately from the engine else the engine will suffer overall.

PS yes, i'm an ass putting the tldr at the bottom
PSS if tldr's are the main source of your info, then the topic isnt for you.

#16 Ok, I understand, is true. so then, the best move is have a clean core and the products like addons/plugins I guess.

This post was not to merge all the products/resource you know hahah but the good ones xD although is better to have a clean core for better maintenance.

what it says here http://torque3d.org/engine/#roadmap guess it will help a lot for plugins

Middle-term
- New modular script templates and content distribution.

Long-term
- Modularise scripting engine, paving the way for other scripting languages


Remember sahara was included in omniengine
http://www.garagegames.com/community/resources/view/22781

#17 What i would possibly like to see is a new github organisation set up for the engines, so that you have independent Torque3D and Torque2D organisations.

Also under these organisations should be forks of all of the appropriate add-ons (GMK, Verve, etc) so that they can be maintained by the 'community'.

I believe that many of these add-ons are unknown to most of the newer community members, and if they were included as part of an organisation on github then they would be on show and would get more contributors as a result.

#18 Omni engine is doing the right thing. Like other game engines it implements third parts middle-ware when possible.

#19 Please can we leave GMK and Verve out of T3D? Unworking/Undocumented/not-cared-about-by-author code doesn't help...

#20 I second gibby. Putting in 3rd party code/integration that's actively maintained is one thing, but dead, undocumented code doesn't help.