[Dwarf King]

that I should be able to put a working turret and tracks on a vehicle without having to change the engine code.

You don't really know how game development works, do you? Are you sure you're not looking for something like GameGuru or Axis Game Factory? Seems to be more well suited for your expectations and skill set.

T3D is not a nightmare, by a longshot. It was, however, completely abandoned for a long time. With the source release, it's slowly getting traction and being improved by the community. If you want to make a game with a few clicks, this is not the place. Never was, not even when it was a product.

I must say that this comment should not be the standard around here. We want helpful comments, even when users are frustrated about something. So a link to a helpful post/thread that can inspire to solutions or your own suggestions for how to solve this would be to prefer.

Any negative comments about asking people to move on to other tools due to their skills and expectations etc. is far by helpful. We should all wish to keep a helpful and understanding community where no questions are too stupid to ask and hence increase our base of T3D users.

Disclaimer: I am not the moderator but as our community is very small here we should take care of the users we have rather than scare them away. Just saying.

[rlranft]

Plugins are better way of dealing with these things.

This has crossed my mind a few times. Most of T3D is already a dll, no real reason we couldn't make the executable portion look in a specific directory for other dlls and load them. Need to expose a ton of stuff so the plugins can use the Console and TorqueScript, but though it's a lot of work it's not impossible by a long shot. I've just been too busy ("lazy") to do it myself.

[flysouth]

I used to program credit card terminals. They had an interesting way of working. The central core program was pre-compiled and installed. You could then compile your own code which you would register with the core as a callback. The core would then hand full control to your program on every system 'tick' or any events such as keypad, wifi, network etc. It would also pass 'handles' to the event drivers. Your program would at that stage have full control of the system. If you did not want to react to the event you would simply hand control back. The core would then pass control to the next possible program until it had gone through the callback list. When compiling your code a header file was used to allow you to call the various functions built into the core. Using this method it was possible for terminals to download additional code or update existing without changing the core program. The core was like a mini operating system in a way.

Just thought I would mention this - perhaps give some ideas

[rlranft]

Yeah - I'm guessing you had a well-defined set of events to handle and your plugin was required to have at least a stub for each event. I'm also guessing that your number of required stubs was fairly small, numbering in the few dozens at worst? Torque's console is well-defined but very broad - the sheer number of export/import definitions is the issue, not the method. It's not really a matter of "this is difficult" but more "this is time consuming." I've looked at it (spent about 6 hours one Saturday about two years ago) and admittedly didn't dive terribly deep, but it looks like a lot of busy-work.

But of course you don't have to take my word for it - give it a go and see what you think. In all seriousness I might have gravely overestimated the amount of work necessary because, as I say, I only spent a few hours doing some preliminary research.

[flysouth]

Actually the plug-in had no stubs at all.
The core program passed a pointer to a struct which the plugin examined and decided if it was something that it could handle.
If the struct contained an unknown record type then you would return with a status that it was not processed. The core then sent the record pointer to the next plugin and this went on until it came across a plugin that knew what to do with the event / data / whatever.
Being an embedded system with limited memory and CPU it was a very effecient system. It was using C not C++. So it might be even easier using C++

No its not something I would try - My C++ skills are very basic, and after many years of microcontroller programing you tend to think very differently about software - especialy when on smaller devices you only have 8K of flash to put the program in and 2K of ram for the variables Everything you do is about speed and using the least amount of resources, so no dynamic stuff here.

[flysouth]

Actually it seems like what @

flysouth is discussing, is exactly what @

andrewmac implemented in Torque6! Since the code-bases are sort-of-similar, it might be possible to use some of the same code for plugins in Torque3D.

[Duion]

When will 3.9 come out?

[saindd]

Seems to have some bugs left: https://github.com/GarageGames/Torque3D/milestones/3.9

[rlranft]

Actually it seems like what @ flysouth is discussing, is exactly what @ andrewmac implemented in Torque6! Since the code-bases are sort-of-similar, it might be possible to use some of the same code for plugins in Torque3D.

Yeah, was thinking that myself - but wasn't entirely sure. Maybe he'll chime in on it.

[Chelaru]

For some reason the milestones is no longer accessible. The same is for 3.9 and 4.0.
"https://github.com/GarageGames/Torque3D/milestones"