Closing in on 3.9

41 posts Page 3 of 5
flysouth
Posts: 105
Joined: Sun May 15, 2016 10:16 am
by flysouth » Wed Jun 01, 2016 2:28 pm
flysouth wrote:
If editors / script functions dont work 100% then perhaps they can have some sort of pop up comment in them that alerts users

Azaezel wrote:
elaborate?

It was really based on what Janders said about the sketch tool. I have not used it so cannot comment on it.
I was just suggesting that if a tool is released in a version but it has some known issues then perhaps when opening the tool a message could be shown indicating that it is not a 100% working tool and problems can be expected.

Clearly it looks as if some of the stuff will be addressed in release 4 which will be great. For me I would just like to be able to use an engine that does not require the user to change the c++ code. Yes if you are doing some 'non standard' stuf it might be required but for the more common stuff I would expect it to be done in scripts
LukasPJ
Site Admin
Posts: 312
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Wed Jun 01, 2016 2:39 pm
flysouth wrote:My skills are mostly in embedded systems using C and IS project management.
Due to the various versions of Torque it is very difficult when searching for help, to know what has been fixed in the current version, what tutorials will work
and what features exist and can be expected to work correctly.
As new user of T3D I would like to make the following comments that might be of some help going forward. Some of this might be 'common' knowledge to the
experienced Torque users, if so please just accept it, as mentioned already I am a T3D noob.

In no particular order...

    A line should be drawn at some version, for example 3.8. Then the wiki, resources and forum should have that as a separate starting point where only stuff that applies will be found.
    A list of known issues ie. things that dont work correctly should be made and put on a page where it can be checked. (maybe not every small bug). This will stop multiple bug reports and also help noobs to figure out if something should work or not.
    There should be some common base class that all objects / shapes use which has stuff like mounting in it. It should allow anything to mount to anything and all in the same way.
    Many FPS games have tanks / robots / vehicles with working gun turrets... Surely this should be one of the standard operations that a new user can achiever fairly simply?
    These are games not the real world. We want people mounted on rocks mounted on robots each with a gun turret.... lol ... anything to anything. (I can suggest how to do it but I am sure the C++ guys here already know)
    There should be a place where simple examples can be found. Templates are okay but they will always be very specific.
    If editors / script functions dont work 100% then perhaps they can have some sort of pop up comment in them that alerts users

Okay this is my 2 cents worth at the moment ... hey I am new .. only tried making a tank so far. Feel free to add to this list.

I am willing to assist with getting some of this stuff sorted out


In general, everything on the wiki should be up-to-date. If you find that this isn't the case, the everyone can update it or if you do not feel qualified to do so, feel free to tell me or somebody else that it needs updating :)

You should be able to find all issues using the GitHub issue-tracker (you can find it here: https://github.com/GarageGames/Torque3D/issues)

In general, examples has been written into the code-documentation in the past, you can find a bunch of them in there. Personally I think they should be on the Wiki, there has already been some work on adding examples to the Wiki (look at: http://wiki.torque3d.org/wiki:_scripter-start). I think that when the examples are on the wiki, it makes it more accessible for people to edit, what do you think?

In regards to the common base-classes, I think, and hope, that the component-system will help alleviate this, at it makes it easy to create and share component which could be a "mountedTower" component or "vehicle" component ;)
Dwarf King
Posts: 145
Joined: Thu Feb 05, 2015 7:20 pm
by Dwarf King » Fri Jun 03, 2016 7:02 pm
@
User avatar
JeffR


Just wanted to write that I think what you are doing here is pretty awesome.


On a sidenote.... This engine is NOT a nightmare.
saindd
Posts: 220
Joined: Wed Apr 15, 2015 3:20 am
by saindd » Sun Jun 05, 2016 1:10 am
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.
Duion
Posts: 654
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Sun Jun 05, 2016 2:15 pm
A lot of people like to keep complaining "This is bugged", "This does not work", "It is a nightmare" etc... but most do not even bother to look into the code or try things out, since then they would realize it is not that bad at all.
This phenomena is called "confirmation bias", people want to see it a certain way and so they only seek for things that confirm their world views.

Fact is still, that Torque3D is the best open source engine for 3D FPS games around, so you cannot really complain.
flysouth
Posts: 105
Joined: Sun May 15, 2016 10:16 am
by flysouth » Mon Jun 06, 2016 10:00 am
@
User avatar
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

@
User avatar
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?
Duion
Posts: 654
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jun 06, 2016 1:10 pm
@
User avatar
flysouth

That answer was mainly directed at people like Janders who just make claims without trying it out. Most of his claims are easily disproveable.
flysouth
Posts: 105
Joined: Sun May 15, 2016 10:16 am
by flysouth » Mon Jun 06, 2016 2:33 pm
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.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Mon Jun 06, 2016 3:20 pm
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."
flysouth
Posts: 105
Joined: Sun May 15, 2016 10:16 am
by flysouth » Mon Jun 06, 2016 3:55 pm
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.
41 posts Page 3 of 5

Who is online

Users browsing this forum: No registered users and 1 guest