Jump to content

Recommended Posts

@saindd

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.

Dont make assumptions about people who you do not know

T3D is not a nightmare, by a longshot
That was not said by me


@Duion

but most do not even bother to look into the code or try things out
more assumptions. I have looked at the code and I have tried a lot of stuff out.

My only point here is I accept that with a game engine that if you try to do stuff that it was not designed to do then you might have to change the code. I however am trying to do something that the documentation says it can do. I came onto the forum to see if someone could assist and so far I have not received any working suggestions that do not involve changing the code. So my original post in this topic was just saying that new features are great but are non working features that have been around for 3 or 4 years being resolved?

Link to post
Share on other sites

The truth is that I like the way that T3D works. It is mostly intuitive and fairly easy to use.

Like all game engines there is a learning curve.

For someone new to T3D it is just a bit confusing because a lot of the examples floating around are for older versions and

parts of the documentation are either very thin on details or just does not work as stated.


Clear with ver 4 coming out with major changes it does not make much sense to spend hours changing the current source.

I will obviously have to figure out work arounds to my problems.

Thank you to those who have made positive suggestions.

Link to post
Share on other sites

I agree that the documentation is out of date. I agree that all features should be working as described.


There are parts of this beast that bother everyone and there are parts that bother only some of us, but there are some things that need to be added even before some of the old bugs are fixed just to draw more users. I think that the SC is trying to focus on some modernization to help bring more developers in so that there are more people with the time and inclination to jump in.


I feel that the engine belongs to everyone. If you see a problem and it really bothers you, log the bug in Github (https://github.com/GarageGames/Torque3D/issues) or fix it and make a pull request - or both. It belongs to you as much as it belongs to me.


Many features are actually genre-specific, or at least specific enough that they can't be said to apply to "most" genres - are we sure that those features need to actually be added to the engine instead of shared as a resource? Do vehicle-mounted turrets or character facial morphing really apply to my 3D chess game? Card game? Medieval RTS? Before adding something we need to ask ourselves "is this really useful in a broad sense?" Sharing these resources is probably the better option in my opinion - it lets people do more without adding bloat to the engine for people who don't need the added features. This was a guiding principal in T2D during the preparation for moving toward 3SS/MIT.


For example, I've recently updated the old RTS Prototype walkthrough/tutorial for 3.8/3.9 and I'm currently working on extending that - I keep it in a copy of the full T3D online documentation that I host on my site (http://www.roostertailgames.com/TorqueRef/index.html). While this doesn't make it easy for anyone but me to edit it does leave it accessible, and since it is an extension of the current documentation available at https://github.com/dottools/Torque3D-Documentation (MIT from the original public release) anyone is free to copy/paste if they wish. I focused on this mainly because at this time it's all I have the available time for. There are a few (very simple) engine-side changes that I want to make for it, but I'm going to document those separately. I want to keep the tutorials script-side only, but I want to make the engine-side changes available for those with the inclination to try them. Additionally, ballistic calculations and a RTS-style decal move/placement cursor don't belong in the engine in my opinion - they're things that I want for this RTS but they're not "generally applicable."

Link to post
Share on other sites

I agree that certain things don't belong in the engine. I feel that the engine should be a generic as possible and then use a system of plugins such as dll's for Windows and whatever the equivalents are for other operating systems.

Plugins are better way of dealing with these things. The problem with compiling things in if you need them is that your version of the engine is unique and then when big changes are made to the engine it can be difficult / time consuming to adapt your special bits of code. Using plugins can make these changes easier to handle if done correctly. Obviously even with plugins you would always be free to change the core code if you wanted to. It also means you could supply end users with add-ons in the form of plugins to give new functionality without having to give an entirely new executable.

But hey my programming skills are for microcontrollers so I might be the wrong person to make these kinds of suggestions lol.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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 :shock:

Link to post
Share on other sites

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.

Link to post
Share on other sites

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 :D Everything you do is about speed and using the least amount of resources, so no dynamic stuff here.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

 

The theory could be reused but the actual code can't. The plugin system is obviously very specific to Torque 6, but yes, it functions pretty much exactly as its being described here.

Link to post
Share on other sites
×
×
  • Create New...