What would you like to see addressed in Torque 3D?

#181 here the perfect solution for t3d lighting and volumtric clouds
http://www.windwardmark.net/products.php?page=nimble&sub=technology
http://www.windwardmark.net/products.php?page=windlight&sub=technology

add the lightning from simulweather sdk
http://www.simul.co.uk/

It would make torque the best hands down! It would have pretty much the same features as cryengine 2 but hopefully a lower price tag. Garagegames would be the Walmart of the gaming industry!!!

#182 i hope you know that cryengine sucks for a engine its far from being the best. the only thing its good at is physics nothing more. also if you had all of cryengines stuff your not going to sell many copy's as people will have to have very very high end computers.

in mater of fact all engines have there ups and downs. i like HeroEngine the best its got super super cool stuff to make building your game much easier.

#183 Brandon, that is just your opinion. It's not even related to the topic either.

I would really like to see this new lighting system that was talked about in the SSAO blog.

#184 @ Adam Beer

Your comment made my laugh! But your right this threads about
what people want to see in T3D

@ Brandon

Just write what you would like to see in T3D a Feature a Bug a Wish!

#185 Not really sure where the humor was but glad to hear that. :)

#186 sorry its a habit Surge i like to speak my mind on anything.

if you want me to list some stuff well i can list allot they are all from heroengine. i also want them exactly like heroengine as its easier to use the way they have it.

Region Nodes,Emitter Mesh, really want Path Editing,Vortex Nodes, really want Morphing Technology,Smart Objects.

then Artificial Intelligence for AI its called Pathfinding its where npc's get to pick where they want when they want. :P

i love there engine these are just some of the main cool things i like to see.

#187 I apologize if I offened you Brandon. If you want Hero Engines functionality, thats fair.

#188 - An editor that meets 2009 standards
The current one was nice 1997, but its far from any acceptable grade for a current / next gen technology with an indie / commercial engine at which position GG is now targetting with T3D.
Need an idea what such an editor is: Look at visual studio, look at grome, look at the Unity 2.5 screenshots

- A standard editor "plugin" interface
Even thought many things have been reworked, the editor is still as awfull as it always has been. There needs to be a common API, a base class from which all editor components derive and which the developer can derive from as well to add more capabilities to the editor. As the code base is meant to be "ground up new" if it is no longer TGEA 1.x, I assume / hope thats possible

- Even a hobbiest class art pipeline
Nothing against the DTS format, but the trouble to get anything into this damned format has already caused a pretty well going project to be put on ice as all have been ugly annoyed by the problems getting their art from X -> Torque without having to setup half the crap again.
As such I would also like to see the "asset update notification" that was already mentioned a few pages before to happen.

- Less datablock bindings, more flexibility for the designer through editors
The days are gone where variety in the objects caused serious slowdowns, where RAM was limited etc
Databaseblocks are nice for template placing but I definitely would like to see that at least lights get excluded from that crap.
Can't be the idea that you must create 300 light datablocks if you want some variety in your creation, that totally defeats the point. Especially as the work happens more or less basing 20 "template lights" with slight variations so we could save 280 datablocks

- PFX, abstract physics layer or equivalent capabilities
Mentioned already but wanted to add it here anyway.
Writting complex physics is a hard task and GGs strengths definitely aren't physics or collision.
As there are top class libraries that are available for free, I would like to see that the path to integrate industrial standard solutions (Newton 2, PhysX, Havoc) becomes considerably simpler.


- asyncronous media loading
right now, unless this has changed with 1.8, the only thing that is really able to load on request seems to be Atlas terrains.
With current gen games tending to use more and more assets its thought important to ensure that only those waste RAM that are required now or in a potential feature (defined by the designer).


I think that are more or less my hardpoints that will make the "make it or break it" difference for any investion larger than $200
nice to haves have been listed already before by others

that the list is that short thought shows that TGEA has become much better since its release ... I Know that I saved and dropped a posting back then on what has to change because I thought that 3 A4 pages are a bit much for a board and now its down to 4 hardpoints.
So great work so far :)

#189 @Marc:

Quote:- An editor that meets 2009 standards
The current one was nice 1997, but its far from any acceptable grade for a current / next gen technology with an indie / commercial engine at which position GG is now targetting with T3D.
Need an idea what such an editor is: Look at visual studio, look at grome, look at the Unity 2.5 screenshots

Totally agree with you here Mark. More than anything, TGEA's editor's just need a facelift so you don't feel like you're back in Windows 98. On top of that, adding some better UI features, and simplifying those that already exist is a major focus. You'll probably get a look at this during February.

Quote:- Even a hobbiest class art pipeline
Nothing against the DTS format, but the trouble to get anything into this damned format has already caused a pretty well going project to be put on ice as all have been ugly annoyed by the problems getting their art from X -> Torque without having to setup half the crap again.
As such I would also like to see the "asset update notification" that was already mentioned a few pages before to happen.

Torque is going to go from having one of the most difficult art pipelines for artists / hobbyists to work with, to one of the easiest. Native Collada file loading has already been mentioned and yes, live asset updating will make workflow for artists 10x easier than it is today with TGEA.

Quote:- Less datablock bindings, more flexibility for the designer through editors
The days are gone where variety in the objects caused serious slowdowns, where RAM was limited etc
Databaseblocks are nice for template placing but I definitely would like to see that at least lights get excluded from that crap.
Can't be the idea that you must create 300 light datablocks if you want some variety in your creation, that totally defeats the point. Especially as the work happens more or less basing 20 "template lights" with slight variations so we could save 280 datablocks

This one is tricky to do correctly, but we're thinking along the same lines.

Quote:- PFX, abstract physics layer or equivalent capabilities
Mentioned already but wanted to add it here anyway.
Writting complex physics is a hard task and GGs strengths definitely aren't physics or collision.
As there are top class libraries that are available for free, I would like to see that the path to integrate industrial standard solutions (Newton 2, PhysX, Havoc) becomes considerably simpler.

We're aiming for a proper abstraction on the level of GFX or SFX, but we may not get all the way there. We will however have a much more robust set of physics features to call upon.

Quote:So great work so far :)

Thanks! We're putting in the work, so hopefully you guys are seeing the results :)

#190 i echo Marc's criticism of datablocks.
often they're just not needed, and they take up a huge amount of time during mission load. StaticShapeData is especially egregious IMO - vSide has about 400 StaticShapeData datablocks, at least 90% of which are totally empty except for "shapefile =". hugely wasteful. we're looking at moving the shapefile param into the object itself. ditto AudioProfile, sgUniversalStaticLightData, etc.

Quote:More than anything, TGEA's editor's just need a facelift so you don't feel like you're back in Windows 98. On top of that, adding some better UI features, and simplifying those that already exist is a major focus. You'll probably get a look at this during February.

i have to admit i find this statement troubling. more than anything the editor needs updated functionality, not a facelift.

#191

Quote:
more than anything the editor needs updated functionality, not a facelift.

I have to keep going back to the question of "what functionality?". Currently we have a list of about 100 things we'd like to see addressed in the World Editor (42 culled straight from this thread). Not all of these will get addressed in Torque 3D (some require a ground up rewrite of the engine which isn't happening this time around) but we are going to try to tackle as much as is reasonable.

However, we need to know what functionality you think is missing if it is to ever stand a chance to make it onto the list of things to change. Telling us that it needs "updated functionality" isn't helpful unless it is combined with an actual list of the functionality.

This isn't aimed specifically at you Orion. It is just something that has been frustrating me personally lately. People repeatedly carried on about TGEA 1.8.0 being "so buggy" compared to TGEA 1.7.1, yet when we look at the list of bugs that TGEA 1.8.0 actually introduced it was very short (less than 10). The rest of the bugs reported (after we begged for bug reports repeatedly) were stuff that existed in TGEA 1.7.1 or even have always existed in Torque. Another example is Marc's "Need an idea what such an editor is: Look at visual studio, look at grome, look at the Unity 2.5 screenshots". What specifically are those editors doing that is better than the current Mission Editor? Is it just that they look more polished or is there actual functionality differences?

We don't want to work in a vacuum where we only focus on the stuff that we know about. It is hugely beneficial to us and you for us to be able to be responsive to your specific concerns and issues but we can't do that if all we get is vague concepts like "your stuff sucks" or "make it better" thrown our way. For this to be a true two way street you gotta give us some meat.

Again, this isn't meant to jump on Orion specifically or even anyone else specifically. This is just a plea for you guys to really help us define how our products can better serve you.

#192

Quote:
- Less datablock bindings, more flexibility for the designer through editors

Quote:
vSide has about 400 StaticShapeData datablocks, at least 90% of which are totally empty except for "shapefile =". hugely wasteful.

I totally agree. I think that datablocks are useful for templating and for optimization but they shouldn't be forced onto the end user who doesn't want to use them. I am perfectly fine letting people shoot themselves in the foot with their network traffic as long as there is a solution like datablocks that they can use to solve their problem once they really understand the issue.

That said, the current generation of the Torque codebase is so dependent on datablocks it would be a massive undertaking to completely break them out. For Torque 3D I would like to address some of the more obvious/problematic datablock fields (like shapeFile and maxForwardSpeed) but it is a lower priority item on my list. It may have to wait until a later version of Torque but trust me, I hear your concerns in this area =)

#193 Help me to help you!

#194 @Matt, your video embed is broken :)

#195 Thank you for a clear and actionable issue report Ross! =P

#196 As per the editor thing, I kind of like it as it is. A facelift is simple enough with skinnable controls -- but a 'prettier' more modern looking editor doesn't make it better or easier to use.

I wouldn't mind seeing some sort of datablock editor that would allow you to not only edit but also to create new datablocks (sort of like the existing Particle & Light editor but more encompassing (ie: vehicles, players, explosions, etc). All datablocks would then be stored in a common location and exec'd with a load(dir) command. Maybe even allow client-side caching of certain types of datablocks.

To replace all of those 'empty' StaticShape datablocks how about a new or modified TSStatic class that allowed script callbacks without the need of datablocks.

#197

Quote:
in a common location and exec'd with a load(dir) command

We actually started down the route of an "autoexec" for datablocks but ran into a major problem: dependencies

For example, the player datablocks have some dependencies on the crossbow datablock already existing and both of them have dependencies on some of the sound profile datablocks.

With an "autoexec" there is no way to specify what order things will get executed in (not without a ton of rework). This is actually something that is being addressed in Torque R&D but in a totally new "data" management system.

For Torque 3D, we've split the datablocks out from the gameplay scripting and added a datablockExec.cs which manages the order/dependencies for us. It isn't automatic but it is a lot simpler to figure out how to add a datablock (instead of digging into scriptsAndAssets/server/games.cs -> onServerCreated()). It also makes it easier for use to "manage" the datablocks in editors (like the particle editor or light editor or a datablock editor) since we have to worry a little less about overwriting your gameplay code with datablock values.

#198

Quote:We actually started down the route of an "autoexec" for datablocks but ran into a major problem: dependencies

Ahh yeah, dependencies.... sounds before explosions before projectiles before weapons... I didn't actually think that far ahead. The "datablockExec.cs" does sound good to me though -- in fact that's sort of what I've been doing.

#199 Hey Matt - i certainly understand your frustrations.
As you say, unless it's actionable, a complaint or suggestion is almost worthless. i assumed there was a known list of improvements to the world editor.

here's a query on our internal jira database for world editor improvement projects. some we've implemented, some haven't. one which isn't in there but should be is four-view mode and automatic adjustment of the neart clip plane for isometric views. google doc: world editor improvements.

#200 Awesome Orion! I immediately forwarded this to Matt Langley who is heading up the tools side of Torque 3D.

Thank you very much!