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

#61

Quote:
1. Integrated PhysX, with Ragdolls.

One of the lower priority things we are looking at with Torque 3D is providing an abstract interface for physics libraries like PhysX and ODE to plug into Torque a lot more cleanly. There has been some work already done in this area but it is still unclear exactly how far it will progress. We are hoping to have a demo that shows off some of this which would give people a *much* better starting point than they currently have but it is a feature that is behind a couple of other ones in priority.

Quote:
2. Fully integrated AFX, not a separate purchase.

We would also like to see this but it isn't our call.

Quote:
3. Voxel based terrain system with overhangs, etc.

We are doing some pretty hefty improvements to the Terrain system but this isn't going to be one of them.

Quote:
4. Built in swimming, crawling, crouching, climbing, hanging from ledges, etc.

Already on swimming, crawling, and crouching. We'll see about climbing and hanging from ledges. Our artists are pretty solidly booked with tasks for Torque 3D.

Quote:
5. Built in inventory system.
6. Built in conversation system.
7. Built in Melee system.

I agree with Steve Acaster that these are far more game specific than the rest of your list. I doubt any of these will make an appearance in Torque 3D but we would like to see them addressed when we do an RPG Genre Kit.

Quote:
8. Built in SSAO
9. Built in full screen shaders (blur out, etc)

One of the things I would *like* to see in Torque 3D is a better post-processing effects system however this is also a bit lower priority than some of the other things on our list. We *are* making some changes to rendering that will make this kind of stuff a lot easier.

Quote:
10. Built in Radar

This *might* happen as part of one of our demos for Torque 3D. If it doesn't, you'll be glad to know that one of my favorite game ideas actually revolves around radar and I'll be pushing on that some this year =)

Quote:
11. Square replicators
12. Replicator blockers
13. Built in terrain material references www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=1507...

There are some serious changes coming for the foliage system. I am not sure if we will be addressing *all* of these directly but we will be keeping them in mind. I am extremely confident you'll like what we are doing =)

Quote:
14. Better default player artwork that doesn't use the wierdest starting pose ever

This is something I tried really hard to make happen for TGEA 1.7.0 and TGEA 1.7.1 but we've had a really hard time laying hands on the right artist for the task. We'll see for Torque 3D...

Quote:
15. Ability to retarget dsq animations to different skeletons at load time (by providing a reference skeleton).

With TGEA 1.7.0 I did remove the requirement for DSQ's that the DSQ and the DTS have to have *exactly* the same skeleton. You can get yourself in trouble with that if you are careful but in general it seems to work pretty well. We are also majorly beefing up TSShapeConstructor with things like renaming nodes, renaming meshes, adding new nodes, offsetting existing nodes, and much more which I think will allow you to do what you want with this. In other words...I think we've got you covered on this one!

Quote:
16. Fix the water bugs - Water doesnt' work right at mission load. You have to force it to resend the network packets after load.
17. Fix more water bugs - If you turn off reflections, the cube map is wrong.
18. Fix even more water bugs - You get incorrect reflections / blobs on the water seemingly from nowhere.

Good stuff! This is some of the most "actionable" items on your list. The clearer reproduction cases and example missions you can send us the better (16 and 17 seem reasonably reproducible on our end but 18 sounds tricky).

#62 Matt Fairfax said: "blah blah ... RPG Genre Kit."

I'm happy.

#63 @ Kevin -

Quote:
A call back for on animation playthread finished? to eliminate the scheduling and manual stop of a one time animation?

this has been in for a long time:

function myPlayerDataBlock::animationDone(%this, %playerObject)

#64

Quote:
A fix for all basic Vehicle classes (wheeled and flying) and related physics.

Can you be more specific about what you want fixed? Give me examples of clear reproduction cases which are causing this behavior.

Quote:
You named one of the items with the flying vehicles crashing when moving to fast. Thats something thats been a bane ithink since the engines been around. With the game crashing with vehicles moving over a certain speed.

This is more specific but I need more details. How fast do you have to be going to get a crash? Does it vary depending on if you run into something or not? Is it a limitation of the tick-based nature Torque's physics or is it symptomatic of something else? Is a crash to desktop or is it an infinite/really long loop?

The vehicle system is a good example of something that works great if you use it in certain ways and can go horribly wrong if you push it beyond its intended limits. Since we have been working so long with it internally we tend to just not push it in the wrong directions because we have years of experience not doing so. So we need new/fresh eyes to help us push it in ways we wouldn't and to give us nice clear feedback on what those ways are.

The good news here is that, as Brett already announced, we are going to be integrating any of the engine changes/fixes that LUMA had to make when they were working on Mini37 and BLUR which will hopefully address a lot of the concerns here.

Quote:
How about some more Ai choices and options. ie Aiflying Vehicles and such.
AI player is nice, but how about adding in Ai Gaurd for the new folks as working examples, yes it can be added to but it seems that aiplayer and aigaurd/patrol would cover a few of the basic requests.

AI is a lot harder to do in the context of the general SDK. We'll probably address this later as we get more into Genre Kit development. I have been hoping to pull the AI Guard resource in for a *long* time so I may make time for it while we work on the FPS Genre Kit.

Quote:
Can we get a working movie player for in game movies.. we had Theora but its not compatible.

We'll see...there is some interesting things that have to happen to SFX to make streaming audio work but I do think we will be able to get that done for Torque 3D.

Quote:
And can we fix the demo recording and playback functions?

Didn't realize it was broken =) Please post a bug in the TGEA Bug Forums.

#65 @Orion Elenzil
Thanks, I've never seen that before.

#66 >>Can we get a working movie player for in game movies.. we had Theora but its not compatible.
> We'll see...there is some interesting things that have to happen to SFX
> to make streaming audio work but I do think we will be able to get that done for Torque 3D.

you might look into FFMPEG instead of theora.
i think it's a bit more advanced, and handles flash video.

#67 I thought FFMPEG was a video encoding application and not a codec?

It has been about 4-5 years since I spent much time in that space however so maybe I am misremembering or something changed?

#68 After looking a bit closer, it's specifically the libAVCodec component of ffmpeg which i had in mind.
edit:we use it in vSide to play youtube vids in-world.

#69 Some bits and pieces of FFMPEG is under the GPL while other pieces are under the LGPL (like libAVCodec).

#70

Quote:* replace torquescript with javascript.

PLEASE tell me you're joking... Right?

#71 EMCAScript can be pretty damn sweet (Tamarin is a lot of fun); and has a large following and documentation base. It would allow a much quicker and easier transition of ActionScript and web programmers into our technology. Personally, I like the idea of a pluggable scripting system that would integrate quickly with various languages. The core to this is to provide well-documented hooks into the scripting API to alow Python, Ruby, C#, JavaScript, LUA, etc to be used.

#72 I have a bias here because we sell Torsion... but JavaScript/ECMAScript is not a bad solution.

#73

Quote:
I'd request an example implementation with one of each type of asset the engine is supposed to support both for internal and external use.

I am going to be working with our QA team to try our best to build a proper test suite. This will include a *lot* of small missions with isolated examples of nearly everything in our engine as well as a couple of larger test levels to try to verify the interactions of a complex scene.

There is *so* many features in Torque that I don't know exactly what we will be able to get to but we will cover a lot of ground. Please feel free to let us know if there is anything *specific* you want to make it into the test suite.

#74

Quote:
Linux Support.

We have absolutely no plans to include client-side Linux support. We have no internal Linux developers and Linux support does not pay enough to make it worth hiring one.

There is linux dedicated server support for some of the InstantAction games which shares a lot in common with TGEA and Torque 3D so we may look at bringing that over if we have the time (it is a lower priority over all).

#75

Quote:
* replace torquescript with javascript.

PLEASE tell me you're joking... Right?

@Tyler:

I think Orion's idea is a great one! Javascript is actually one of the most powerful scripting languages in existence. Unfortunately, bad browser implementations did not help much in making it popular for applications outside the web.

Today, the possibilities of the JavaScript implementation in Chrome rival MS' Silverlight or even Flash in certain cases considering speed.

I strongly believe that Orion's idea to take the Gui and Scripting towards the web is an innovative and excellent idea! Anyone who has been knee deep in JavaScript will say so.

I would not dispose of TorqueScript though, I've learnt to like this language.

As David said, a pluggable scripting system would be nice, but if everyone would be using different scripting languages, the resource system would shame Babel in no time. There's a huge advantage in having only one scripting language - we all speak a common language.

#76

Quote:
- Much more modular system for add-on game components and capabilities.
- Removal of old poorly object-oriented Tribes 2 game code in favour of a component-driven framework.
- Implementation of a single player version of that game that doesn't require having multiple server/client objects and partial networking to run.
- Proper usage of namespaces in the code. Put everything Torque-related under Torque:: for example.

A lot of this is already happening in our R&D codebase which GG Studios is using but it has a ways yet to go before it is mature enough for general release. GG Studios is finding new things and reworking a lot of stuff as they work on their first couple of games based on this codebase. Once they get further along and it stabilizes we will be looking at "productizing" that version. In the mean time we are pulling over some of the easier parts like GFX2, the new ResourceManager, and the Sting class (all in TGEA 1.8).

#77 When i think about actually leaving TS behind,
the main part which really gives me pause are the specialty construction syntaxes such as datablocks, the mission file, etc.
and of course porting existing code, and losing the benefit of existing documentation and books such as TGPGTT.

David,
while a generic script interface is definitely the most flexible and forward-compatible option, i'm not sure i agree that it would be a good thing overall.
i think there's value in having a consistent scripting language for an engine,
to maximize the reusability of code and ease of discussion. ie, keeping the community on the same page, language-wise. imagine the resources section if there were 6 different scripting languages in play..

#78

Quote:
1)x,y,z spinners , so I can edit a DIF/DTS position without having to type it in all the time.
Similar to 3dsmax.

Good suggestion. I'll make sure the developers on the World Editor (we are renaming Mission Editor) see it.

Quote:
2)A material system that can update itself and have a gui interface in real time without having to reload
and edit a text file save and reboot everytime, similar to the Plastic tweaker.

Already on it =)

Quote:
3)Elevators, moving lifts that affect players position similar to Ramen Sama's Platforms that Players can Ride on.

This is one of my higher priority items but it may have to wait for some of the sweeping physics/networking changes happening over in Torque R&D in order for it to not be a complete hack job.

Quote:
4)If you create a Shader in Render Monkey , you could use it as is without needing to know how to edit the Pixel or Vertex Shader File.

This is actually a pretty tall order. The vertex data and matrices that Render Monkey uses can be *dramatically* different from those Torque uses. Instead we are focusing on extending ShaderGen to cover more "features" and allowing you to edit those in real-time.

Quote:
5) World editor/Inspector/Terrain editor..etc windows become floating windows so that they can
exist outside of the Game window.

This gets tricky really quick with the current generation of the platform layer and WindowManager but it is definitely one of our long term goals (much easier with some of the changes over in Torque R&D).

#79 It very well could be a resource nightmare, but I also think that the top couple of languages would shake out pretty quickly. ECMAScript would most likely be one of the tops, I would think, simply because of its prevalence everywhere else in the development world. Ruby or PHP could make a leap up as well with the bump towards web development with PHP and Rails over the last several years. People like using languages that they are extremely familiar with.

But yes, it could make things extremely messy to have a generic interface.

#80

Quote:
Also I want to throw in a request for the ability for Torque to have its own "Export to Web" ability much like unity 3d or dxstudio's web players.

As Brett covered here we are hard at work on allowing you to publish your game to a web plugin. For various reasons I can't get into publicly we are going a slightly different direction than the "web players" like Unity but we are going to help automate the process as much as possible.

Quote:
And to be able to get the effect of mapping a seperate detail texture to each terrain texture layer so that dirt can look like dirt while grass can look like grass etc.

*skirt* *skirt* *skirt* *looks over his shoulder at the marketing people* *shifty eyes*