Torque 3D Community Edition Discussion Thread

#41 All those are good suggestions, the gameplay features would be a nice feature to add to the scene event editor. It can have a list of pre-set gameplay related function. For example, ladder climbing, or walking in a room and a trigger opening a door, etc. All the function can be resources port to 1.2 that would make for great gameplay features.

#42 As Steve said, fix and streamline. The engine is really needing some optimization.

Also, Mac and Linux compatibility would be a godsend. We are running our KS campaign, and we get asked about them 100 times per day, and it would really help us to confirm support for those platforms.

#43 streamline and fix.. i vote for that one. and hopefully in the fix part we can come to some conclusion on the collision issues. Maybe figure out why T3D is using Mesh collision even when using simple geometry shapes as collision meshes.

#44 @Kory, I can probably implement some kind of ladder climbing/ledge grabbing in due time when I'm not so busy with studies and whatnot (I still think that the engine needs a lot of bug fixes, updating stuff and optimisation before anyone should really be implementing any new gameplay mechanics, such as that).

---

@Donald, From what I've looked into the code concerning collision (which isn't much, so I could be quite wrong with saying this), but from what I have looked at, it doesn't do any kind of checking to see if it should use a visible/collision mesh for collision depending on the shapes geometry. Could probably throw some kind of check in there, but that promotes lazy artists for even simple, convex shapes ;)

#45 I agree with the fix and streamline argument. The codebase is old and has had numerous programmers working on it. Some of the coding in the engine is plain horrendous and is full of coding errors and lack of basic object cleanup. The engine needs to be cleaned and optimized before any other additions are made to the engine. The entire engine has been patched and mangled until the codebase as a whole has no cohesion.

#46 Fixes and optimizations are definitely key areas that we are interested in. Just in the past few days:

• Improved some iterator operations
• Removed unnecessary multiple assignments of values
• Fixed some logical errors
• Removed some checks unnecessarily repeated several times
• Replaced unnecessary calls with assignments
• Declared as virtual some destructors, so as to free the memory if inherited objects are deleted.
• Replace some memory and string functions with the corresponding asm sse2/sse3/sse4 optimized version: dMemcpy / dMemmove / dMemset / dStrcat / dStrcmp / dStricmp / dStrcpy / dStrspn / dStrcspn

Keep in mind that this is not an all-inconclusive list, and some fixes may not actually be valid for all situations or machines. This optimization work by Alfio (arranged into layers for iterative testing) doesn't include the several supporting libraries that have been updated already and will continue to be updated.

It's all well and good to say that things could be improved, that some code is just awful, or is full of errors, yet no one is logging these problems on the ticket system, most of what we're seeing are feature requests or Resource additions. Which does provide a task list, so don't be discouraged if you don't see immediate attention given to including a favored Resource or desired feature, for nothing has been denied -- yet we do need more participation. The whole point of the Community Edition is for everyone to benefit from a pool of knowledge and skill that is larger than what one or two individuals may know of in order to solve some of these problems. There are 46 members of the CE as of right now, and if all of us contributes just one fix or enhancement, or submits a ticket for something which could be improved, that would definitely give us all a better Torque environment to work with in time.

These discussions are certainly laying a groundwork for future goals as well as providing feedback for ongoing efforts, just remember that only the first few steps have been taken as of yet. We're all of us responsible for those goals, short and long range, which can only be accomplished with participation.

#47 @Michael,
How do you propose we go about testing the changes that could be introducing new bugs because the bad code fixed bad code? Should we work at creating some kind of test suite?

As to features versus bugs:
I am not always working with the engine itself. I probably do not know enough when I am working with the engine to know what is good code or bad code. Unless I am really trying to figure out a piece of code. So, I am not really sure how much input I can put in for bug fixes. I can work on optimizations for pieces of the code perhaps. It will just depend on how much I am working with the engine at the moment. I can however start looking at problems people point out and work to correct those problems.

Do you see looking at streamlining the compiledEval loop as a optimization or a feature? Is that the kind of things you want to see in the Tickets? I do see your point in that we can have a whole lot of "ideas" for features, but never really address what this whole exercise was about.

#48 I agree with fixing and streamlining but I'm just opening up ideas. Things I think would help making games in T3D easier from both artists and programmers, small teams to a single individual. I think everyone would agree in saying yes the codebase is buggy, and pretty much if you find an area that you feel needs to be fixed, open up a ticket and note the issue. It wouldn't get fixed if no-one else isn't aware of the issue.
The reason I put up the features to start conversation on it. That way when new features are implemented there is a clear direction. Something everyone would be happy with!

#49 Ideas, features, and suggestions are all certainly welcome. Don't get me wrong, many of the feature requests that I've seen so far are attainable goals and I'm not going to say that we shouldn't include them but we do hope to see more people interested in acting or improving upon those requests. Everyone is welcome to make changes, offer insight, etc., so keep the discussions going!

I think a test suite would be useful, but probably outside my skill level, any takers?

Alfio has designed his optimizations so that the depth of them can be tested in stages or all at once through a series of project defines in the project.conf file of the Full Template. This means you would have to recompile for each test, by default they are all enabled. It also looks like he has a system in place for comparing profiling benchmarks... but I must admit to not having made use of it yet.

#50 @Michael,

As someone who is not a programmer, I struggle with the opening tickets for things as I am not sure what is worth the effort. Do I submit tickets even when I know due to my lack of skill I will not be able to contribute to the code base?

I mean, I know that the collision system on Torque 3D has issues, and I know based on responses from GG that they are not pursuing the collision issues any further.

So Do I put in a ticket saying object collisions causes lockups when objects move at high speed? Even if the chances of it being worked on are slim? Or how about the collision system using mesh collision even when set to geometry shape collision.

#51 @Donald just submit a ticket if you believe the engine needs to be improved in anyway.
E.g. the collision system, submit a ticket for it if it is not urgent set it's priority to trivial or low. If someone looks at it and think they can fix it, they will 'take ownership' of the ticket indicating they are working on it, if not it will just hang around untill someone thinks it is either unnecessary or if he wants to work on it.
IMO rather a ticket too much. As long as you don't set something low priority as a high priority it never hurts to have tickets hanging there so someone knows that someone thinks it's an issue.

#52 Just a note when it comes to adding resources. Seeing the Advanced Camera resource mentioned threw up a red flag since it is not network friendly and can significantly impact the engine for people in the CE project that have network requirements. It could, of course, be re-written to be network friendly, but whenever it comes to looking at adding a resource, make sure you understand the impacts of that resource on everyone using the CE edition.

I love the discussions this is generating!

@Donald
I'm not sure where you heard that we were not working on the collision system. I'm not familiar with the 1.3 project schedule, but I know that there wasn't anything that we were like "we're never working on that again". Except for DIF's and IFL's, though they were a 1.0/1.1 decision, so they aren't on our radar as deprecated systems.

#53 @Donald: doing so would at least give a point of reference for something that you feel needs to be evaluated -- that is participation. Maybe someone could offer some insight towards a resolution once they see the ticket.

#54 David raises an excellent point about Resource inclusion requests in general. That actual example has already received comment within it's ticket discussion and a possible goal thereof -- which is why I keep wanting to encourage them.

Thanks David.

#55 Maybe I should request access so that I don't put my foot in my mouth too often! :)

#56 Well David it's good to see that our internal discussions about impact seem to be on the right track. Management of goals and expectation is still kind of fast and loose, but I see us getting there one step at a time :)

I noticed in IRC recently that there was a bit of concern and desire to see the 3rd party external libraries updated... so kind of an update for those who haven't noticed that this is an area of focus as well:
Of course, if any issues arise due to these updates, that's something we should be made aware of.

#57 (I probably should try to get access too, admittedly) In regards to streamlining/bugfixing, etc. I would have to stand by my suggestion for having built-in hooks for stuff like processTick or updateMove to script.
Having that sort of thing in there would push a LOT of game-specific stuff, or the need for tons of new code for additional/simple features out of the engine and back into script where it belongs.
Heck, if you include Dan's script-defined action animations source and have a similar 'datablock' type for stance info, you could move all the stance specific junk(which is game-dependant) out of the engine and into script(which is what I've done for my project).
I think a logical, and honestly it could be pretty short-term, goal would be focus on finding game-specific elements like that, and moving it out of the engine, and into script/expanding what script can do for game-specific elements.
This keeps the engine codebase streamlined and easier to keep clean/bug free.

After the inital code push I did for my build of the engine, I've hardly had to edit the engine code at all, because I'm doing all the gameplay stuff, and I've made it where 99% of that can be done by script. Given how practical that makes T2D, I think it's a logical direction for T3D as well.

#58 One thing i really miss on the torque, at this time for my tests, is a non-interactive benchmark scene and more details on the measurements at runtime. I lose, very long time to create complex scenes to evaluate the speed of the engine.

NOTE: THE COMMUNITY IS NOT RELEASING ANY FINAL VERSION, BUT IT IS ONLY FOR TESTS AND IMPROVEMENTS, THEN... WILL REMAIN UNDER DEVELOPMENT.

As for the gameplay. We're not developing a game, so i do not think that some requests are within in the planned goals. Certainly no one forbids you to add items pertaining to the gameplay ;)

Any help to improve the engine is welcome.

[I personally speaking]
When i do a commit a change on the server, i guarantee that all changes are tested. Some are also analyzed with a static analyzer, and measured with a profiler.

Though of course... i can not stay days to check that each new single line of code is perfect. Therefore, it is possible that in the new injected code, there is some bug, but certainly... if it is signaled with a ticket, can be fixed. The idea of having a shared version of the project is also based on these reasons.

PS: Sorry if not much comment the posts of this discussion, but with the words am not very good. :P

#59 @Jeff I must say I like that idea. I would like to see a Game Engine where you could actually make the whole game from script and use that game engine as the machine that you give input rather than use scripting for small tasks and use the engine for running the game. Not sure if I make myself clear, but I like where you are heading Jeff keep it going.

#60 @Alfio,
The tests could be a simple alternate set of startup scripts that check object inputs and outputs, game function inputs and outputs, and any other simple tests we add over time. The idea would be to catch something that might change more than we anticipated: house of cards effect. I could see a situation where the engine needs a bug or some bad code to fix another area that was hard to identify and was hacked to get it working. So, if we had a way to say: "This change does need to be made, but it causes the engine to fail test # 12. This change will be in a branch until the cause of this secondary failure is determined." Rather than it being an all inclusive test suite, it could be a quick litmus test that through experience we update.

Maybe the tests themselves can be submitted into the code as a test suite. There to be used if people want them. I am guessing they will evolve as we evolve the engine.