elfprince13

Now that Visual Studio supports alternate compilers (i.e. Clang), I think it would be in everyone's best interest to drop the VC++ compiler (I don't care for the VS IDE either, but that's personal preference - the VC++ compiler is objectively bad).

MathJax is awesome, though I don't think I've actually ever seen anyone use it here before.

I just use a Windows VM, but there are tutorials out there for cross compilation and I'm sure CMake makes it easier now. I'm curious if anyone has verified if the Windows build of Torque is MinGW / Cygwin compatible, because if you are going to cross compile you might as well get the benefit of a modern compiler like GCC or Clang. You might also look into compiling and linking with MSVC running under Wine which is something that's been done before.

Ditto on this, though at least last time I looked there was no push-button solution to get skyboxes out, and it required a little fiddling.

Just wanted to bump this and say I'm a fan of Komodo Edit, and have a plugin for TorqueScript support - https://github.com/elfprince13/KomodoTS

Hi Jeff, that's super helpful, thanks :)

Is there any documentation on the TAML module system? The wiki is suspiciously empty (or at least the search function isn't turning anything up), and it's been a few years since I did any TorqueScripting so I haven't been keeping up with the modern way of doing things.

Just wanted to chime in and say thanks for all the hard work. OS X support is a huge moment, and I might finally come back into the Torque fold after GG screwed the pooch on the T3D 1.1 release way back when.

Out of curiosity, has anybody tried to directly compile the Linux client under OS X with MacPorts?

Sure. Here's the PR - https://github.com/JeffProgrammer/Torque3D/pull/4 And here's my fork, which also has some of the newer patches from the official repo: https://github.com/elfprince13/Torque3D It builds and "runs", but doesn't seem to be quite working correctly graphically.

We really ought to kill the carbon dependencies. CountMenuItems seems to be completely deprecated at this point. [edit] Alternatively, just make TORQUE_SDL default to ON. I'm assuming this is how you guys have been working, and I just found it. There's still some weird bits that I had to comment out between the SDL and Mac layers to get everyone on the same page about where Platform:: implementations were coming from. [edit 2] There are some really severe buffer overruns in macCarbFileIO.mm. I opened a PR for Jeff's repo to include these fixes.

This isn't really true. The LGPL requires that you provide a way to relink your binaries. So if you want to (a) static link, and (b) be closed source (GPL vs non-GPL isn't an issue here, if the source is open), you have to provide an unlinked-object file with your release so that others can choose to relink. See section 4: https://www.gnu.org/copyleft/lesser.html#section4 The point wouldn't be to "replace networking", it would be to have a unified code base for the socket-level stuff. @LuisAntonRebollo: We also really ought to clean up file-system access. Torque has a history of writing to badly behaved locations (assuming a program can write to the directory the executable is stored in as a really bad model.....), and Qt provides a nice abstraction for finding platform specific user-data locations, and the like. If you want to stick with something light-weight though, I have a project for the same purpose that has better directory-purpose coverage than SDL: https://github.com/elfprince13/libcrane

I'm apparently behind the times on SDL, but QT has: Immense cross-platform support GPL, LGPL, and commercial licensing options Support for networking, file system abstractions, threading, native UI development (including OpenGL components, and D3D, afaik), a string class with good support for different encodings. Also has support for multimedia using native codec libraries, and WebKit. The libraries are well modularized, so you don't have to link the whole thing to use some of them - e.g. you can use all of the low-level goodies for your dedicated server without needing to take the GUI stuff along for the ride

Wait, really? When did it get all the goodies? Last time I looked at using SDL it was still only input/sound/graphics context. This is a fair point, though those of us who are planning on developing open source stuff don't care, and those of us who aren't can probably afford to pay for a commercial license for Qt (which is available).

The ridiculous amount of metaprogramming in boost makes compiling take way too long. So far I haven't had to add any additional compile steps for Qt - just download it and link. It even seems to play nicely with CMake. Right now I'm basically just scrolling through the linking errors to find what platform functions are missing, and adding Qt based implementations one at a time. Anyone else who thinks this is interesting is welcome to join in. Right now it looks like there's about 150ish functions to go. I expect most of this stuff will have straightforward mappings into Qt, so if we knock them off a few at a time we should be in good shape.