3.7 is out in the wild! We've run a bit into overtime, but the additional work squeaked in at the end was worth it. You can grab a package with the Project Manager and Windows binaries from here, or simply 'git pull' the master branch to get the latest version of the source.

We've seen a lot of work go into 3.7 and it's been a pretty hefty batch of polishing, improvement and fixes, with a dash of new stuff in for flavor. Over 200 issues and pull requests were closed for 3.7, plus another 40 or so which were categorised under the OpenGL milestone. Of all those, around 100 were bug/fixes, 40 were new features, and the rest were general improvements to performance or code quality.

As always, you can see the full list of changes in the release notes, but here are some highlights:

New stuff

Linux

Torque 3D running on top of my XMonad desktop, for extra street cred

As if you haven't heard this enough already, T3D now supports a Linux client with OpenGL rendering. This has been a herculean effort by some dedicated and talented programmers, so everyone give them a huge pat on the back! Particular thanks goes to Luis, who has spearheaded the effort, Lopuska, who has helped hugely, Azaezel, who has been diligent as usual, and BeamNG, who have supported Luis's efforts and the engine in general.

Note that not everything is working quite right in Linux just yet - there's still work to be done, especially around the platform layer, and some graphical bugs that no doubt lurk in different GFX/driver combinations. But this is a huge step towards full cross-platform support for the engine, and we're really happy to have Linux back.

Accumulation volumes

After Konrad Kiss kindly released Sahara under an open-source license, Quinton Delpeche and Andrew Mac set about getting it ready to use with the current version of the engine. Andrew even made some improvements, so you can use multiple different accumulation types in the same level, defined by volumes you can place like triggers. We reckon this is a pretty cool feature, letting you reuse assets while tying your envionments together in a more cohesive style.

Ribbons

Ribbon projectile being tested in Airship Dragoon

Another fun litle graphical upgrade is the new Ribbon class, which can be attached to projectiles as in the image above, or even vehicles. You can make all sorts of crazy things (shudder).

Navmeshes

A large navmesh in the new navmesh editor, formerly known as Walkabout

A little while ago, I open-sourced Walkabout, a formerly-commercial addon providing Recast/Detour integration. Thanks to popular demand I've cleaned it up a little and PRed it into the main engine, so everyone can enjoy the power of those fantastic libraries with Torque.

Bits and pieces

A subtle vignette and a tweaked atmospheric ray effect

One of my personal favourites is that you can now write anonymous functions in TorqueScript. Though they don't capture any surrounding variables, they're still useful for scheduling and callbacks! There's also a new vignette PostFX shader courtesy of J0linar, and an in-depth tweaking interface for the god-ray shader, thanks to Chelaru's first PR. Lukas also managed to get particles rendering to the glow buffer, which means fancy glowing particles!

Behind-the-scenes

As always, you can find the full changelog the wiki. But here I want to mention a couple of significant changes that may have implications for your project.

Most uses of ConsoleMethod have been changed to use DefineEngineMethod. The old macros haven't been removed, and are in fact still used for variadic script functions, which aren't currently possible with the DefineEngineMethod macros. But be warned that there are a lot of changes in this area, which may cause conflicts if you've modified any of the console methods.

James Urquhart's major console function call refactor has finally found its way in, which has meant significant refactoring to the way TorqueScript works under the hood, including new wrappers for console types. This has introduced some subtle bugs we've managed to find, but if you're relying on custom console methods and behaviour, we urge you to double-check those and make sure they still behave exactly as expected.

A bug in quaternion math has been fixed, but you might find that code relying on the broken behaviour needs to be changed.

There's a new version of the SimDictionary based on the C++11 STL hashmap. You'll find a commented-out #define in torqueConfig.h which you can enable if you like. According to the contributors, it's worth doing if you have a lot of SimObjects about at the same time.

The projects.xml file is now part of the main repo, instead of being part of the Project Manager repo. Just so you know, and don't go looking for it there.

isObject is now stricter about what's actually an object. Where before, the string &quot;3.14&quot; would be cast to the integer &quot;3&quot; and resolved to object ID 3, the whole string is now validated first, and if it's not a valid integer, it won't count as an object ID. (Note that the method still also accepts object names as usual.) This logic expands to other types of object resolution as well - so &quot;3.14&quot;.getClassName() now won't work.

Extra goodies

The folks at GarageGames were kind enough to let the SC get access to some of the older Torque 3D demos - so we're really happy that we will soon be presenting them to you, reworked to use the latest engine version and totally open-source! This means that the Pacific, Sector T3D, and Deathball Desert demos will be coming to you soon. Jeff Raab has been taking the responsibility of getting them ported, and we're really excited to be able to give them to you soon.

While the Sector and Deathball demos are still being worked on, the Pacific demo and package are good to go. So, here are a couple of high resolution screenshots, and the links!

To utilize the Pacific package, just create a new Full template project, and drag-and-drop the package files over top of it, replacing the files it asks. Once you do, you'll have the assets and the level in the project, ready to use.

How many months overdue?

Five, sadly, according to our GitHub milestone. I can't remember how long I've been assuring people that it's okay, the release candidate will be out next week! And, after that, that we're just waiting for more tests and to fix the remaining issues before releasing properly. We on the SC will be the first to admit that we've been pretty slow to wrap this one up. What with this and that, and BeamNG's recent release tying up some of our most productive reviewers, we've been a little slow to get through that last 10% of work for the release.

So, with that in mind, let's chat a bit about what you can expect in the next release.

What's next

I had to double-check using my calculator, but it tells me that 3.8 would be the next step in line. What's on the docket for 3.8, you ask? We on the Steering Committee have been mulling over stuff we feel is pretty critical to Torque's advancement. A lot of it is the finalization and integration of several projects people in the community have been working on for a while now, while other parts pertaining to cleaning up the weak aspects you guys have to deal with constantly. Specifically:

Jeff's entity/component system. This is a massive and important refactoring, which is going to hit like a tsunami.

Some sort of plugin or package system for C++/scripts/content. This will be supported by

Improving the Project Manager - specifically, we want to rewrite it as a Torque application, instead of it using Qt, and beef it up with new features.

Improve Linux and OpenGL work - in particular, stability, and making sure we have feature parity across platforms.

Refactor ugly/old code. This is a constant war.

Review the physics layer. Common consensus dictates that the builtin 'Torque physics' shouldn't be privileged, but should be a backend the same way Bullet and PhysX are, meaning no more duplicated RigidShape/PhysicsShape split.

Quite a few of these are already far along, such as the entity/component work, and only need to be pushed to the finish line so they can be rolled in properly. Others are things that need to happen to keep the engine as pleasant and easy to use as possible.

But now, before I get too far ahead of myself - obviously not all of these are going to make it into 3.8, due to sheer impracticality. One of our biggest issues right now is that we're not doing a great job of providing a stable codebase for you, the users. The mix of lack of testing, huge codebase, large PRs with sweeping changes, and just a general shortage of eyes on the code has meant some projects like DHMC haven't been able to upgrade past 3.5.

This is a big problem for us, and we plan on taking it seriously. Our recent internal discussions have focused on the possibility of making 3.8 a 'boring' release focused on stability and improving our processes. We've also been encouraged to focus on some of the community projects out there, like James's hardware skinning, which will bring large benefits to most users of the engine with minimal pain.

So, as usual, we want to hear from you! Some people in the community we hear from a lot, but others tend not to be involved in the same channels of communication as frequently, and though others do an admirable job passing the message along to us in the SC when they can, we want to hear your opinions! Share your thoughts in the comments or in the forums - what would you like to see us focus on, and what would you like to do with the engine?

Acknowledgments

In no particular order, here are the people who contributed to this release's GitHub issues - we thank and salute you! If anyone's been left off this list, I apologise in advance - I got lazy and used a script to run through the authors of all closed PRs and issues, but we might have let a few slip through the cracks in odd circumstances!

As far as suggestions for what I'd like to see in the engine, Hardware occlusion would be nice, I remember someone started work on it and didn't have a huge amount left to do, just a few things. For the engine plugin thing, perhaps have various interchangeable parts of the engine non-statically compiled and put in some sort of linked library, for example the physics engine could be in a "physics.dll" in the same directory as the engine and it could contain Bullet or PhysX and the abstraction layer for the engine. That way if I wanted to switch between Bullet or PhysX, I could just copy/paste a DLL instead of recompiling.

...Improving the Project Manager - specifically, we want to rewrite it as a Torque application, instead of it using Qt, and beef it up with new features.

We've always talked about switching script templates to use packages, so you can automatically copy over more modular bits than just getting the whole enormous Full template every time you want to start a project. That's my main one. That would ideally include the ability to browse and download packages from some online registry.

That said, given the way things are going this might not be on the table for 3.8.

Thank you for the Linux support! I must admit that I have no idea how to build this release on Linux. Could you guys please point me toward an updated tutorial/instructions on how to install this release. Am I missing something, as I cannot find a Linux binary.