What you want in Documentation?
by Matthew Langley · in Torque Game Builder · 09/07/2007 (11:04 am) · 62 replies
I figured I'd post a thread about this to see if I can get some good feedback from people. The question is pretty simple:
What you want in Documentation?
I'm curious as to what different people want. This can include what is partially there but not completely, what isn't there and you think should be, or even what is there and you want more of?
One thing I will note is for the future we are shifting away from developing docs that step you through creating an entire game. We've found that these can be long and boring (since making an entire game has a lot of repetition and isn't exactly fun to learn with). It also means if the existing ones don't cover a game or content that interests you then you may avoid it completely, ex. If you don't want to make a fish game you'll avoid the fish tutorials.
We are going to focus more on concepts tied to application. Doing this will help reduce the size of the tutorial (make them more digestible) as well as hopefully teach you concepts you can piece together to make whatever you want.
Figured I would include at least that blurb before getting feedback.
Be honest, be brutal, but please be constructive if you choose to give feedback :)
Also please don't be too harsh about the past efforts as much as being constructive about what you would want. We've had limited resources to dedicate to TGB docs (lol me, and not even completely full-time on docs) so keep that in mind. I think we've done extremely well with limited resources. I feel launch and 1.1.3 was a great launch, engine wise as well as the quality and amount of docs. Especially considering before the current docs were released we really only had a single tutorial. I do think though our future efforts need to both step up the quality and quantity of the docs. The existing docs looked great compared to what we had before, but not much has been added (though maintaining alone is a huge task) during the past year (except some reference generation changes and framework updates, which have been extensive and time consuming, and allows us to more efficiently develop and maintain docs) so I think the current docs have become less appealing since they haven't grown.
This thread delivers no promises, though your feedback, input, and suggestions will be invaluable for future considerations.
What you want in Documentation?
I'm curious as to what different people want. This can include what is partially there but not completely, what isn't there and you think should be, or even what is there and you want more of?
One thing I will note is for the future we are shifting away from developing docs that step you through creating an entire game. We've found that these can be long and boring (since making an entire game has a lot of repetition and isn't exactly fun to learn with). It also means if the existing ones don't cover a game or content that interests you then you may avoid it completely, ex. If you don't want to make a fish game you'll avoid the fish tutorials.
We are going to focus more on concepts tied to application. Doing this will help reduce the size of the tutorial (make them more digestible) as well as hopefully teach you concepts you can piece together to make whatever you want.
Figured I would include at least that blurb before getting feedback.
Be honest, be brutal, but please be constructive if you choose to give feedback :)
Also please don't be too harsh about the past efforts as much as being constructive about what you would want. We've had limited resources to dedicate to TGB docs (lol me, and not even completely full-time on docs) so keep that in mind. I think we've done extremely well with limited resources. I feel launch and 1.1.3 was a great launch, engine wise as well as the quality and amount of docs. Especially considering before the current docs were released we really only had a single tutorial. I do think though our future efforts need to both step up the quality and quantity of the docs. The existing docs looked great compared to what we had before, but not much has been added (though maintaining alone is a huge task) during the past year (except some reference generation changes and framework updates, which have been extensive and time consuming, and allows us to more efficiently develop and maintain docs) so I think the current docs have become less appealing since they haven't grown.
This thread delivers no promises, though your feedback, input, and suggestions will be invaluable for future considerations.
About the author
I Manage Tool Development for Torque at InstantAction
#2
Also, I think it's really great that users wish to add to the document base, but it feels like there is no quality control. Their intent and efforts are admirable, but half-finished documents can be very confusing and sometimes a little less than helpful.
09/07/2007 (12:08 pm)
Each article should be laser focused, a tutorial on using a joystick for input should involve moving an object with a joystick. Practical application is nice, but it often means that the example project becomes unwieldy.Also, I think it's really great that users wish to add to the document base, but it feels like there is no quality control. Their intent and efforts are admirable, but half-finished documents can be very confusing and sometimes a little less than helpful.
#3
For myself : nothing, thanks. I'm happy with 1.1.3 and 1.5 docs together, as the only thing I use regularly is the 1.1.3 TGB Reference. By the way I think you should put it again (as it is) in the forthcoming doc.
09/07/2007 (2:23 pm)
For newcomers, the most common practices with TGB (like this one, or the use of "$timescale", or an explanation of what does "return" (I discovered only recently that it interrupt the whole function it is in)).For myself : nothing, thanks. I'm happy with 1.1.3 and 1.5 docs together, as the only thing I use regularly is the 1.1.3 TGB Reference. By the way I think you should put it again (as it is) in the forthcoming doc.
#4
On the otherhand, short tutorials aimed at fixing common issues are an excellent idea. I think a good small GUI tutorial would be awesome too. Just something like a window with text and a button, where the button changes the GUI or something to that effect. Many people stear clear of the GUI builder because of the apparent complexity.
One final thing, hands up if you dislike the highlighting in the documentation? I *always* forget to uncheck it, then end up waiting ages for it to load the page. If people need to find specific words, no doubt they will be able to use the find feature in their browser (my 2c).
Overall, I really like the documentation. I started TGB at 1.1.3 and never had trouble finding what I needed to learn (no, I didn't do the fish tutorial). You're doing a great job, keep it up.
09/07/2007 (3:28 pm)
Mattew, I somewhat agree with your idea of abolishing larger tutorials that may not promote people to run through them, wasting your time. If a long tutorial is made, it should be a base for other games, not something weird (fish game). I know it's difficult to think of things to do, but sometimes longer tutorials are needed.On the otherhand, short tutorials aimed at fixing common issues are an excellent idea. I think a good small GUI tutorial would be awesome too. Just something like a window with text and a button, where the button changes the GUI or something to that effect. Many people stear clear of the GUI builder because of the apparent complexity.
One final thing, hands up if you dislike the highlighting in the documentation? I *always* forget to uncheck it, then end up waiting ages for it to load the page. If people need to find specific words, no doubt they will be able to use the find feature in their browser (my 2c).
Overall, I really like the documentation. I started TGB at 1.1.3 and never had trouble finding what I needed to learn (no, I didn't do the fish tutorial). You're doing a great job, keep it up.
#5
"$timescale" and pausing is always coming up in the forums and I didn't know about it
for a while, It is the coolest thing ever.....
I think new users (including me) need tutorials that teach how to structure a real game from beginning to end. Users need to know how to begin by creating a Game menu screen with a few selectable options(GUI builder perhaps). Once Player selects let's say "Play" from the menu, users need tutorials on how to load a new level properly, then Tutorials on Pausing the game, setting up conditions to complete the level and load a new level. How to handle Player Lives and Ending the game.
I tend to always create a game but it takes me the longest to impement the seemingly easy things like the beginning and ending...
I hit Play in the LevelBuilder and the Player just pops into the gameplay...
One other request would be to take a simple game and show the user all the options they have for Debugging their game. I have learned alot by taking notes off the forums and am still learning new ways to debug TGB games using only the console and script... (Not meant to cover editors like Torsion)..
Maybe go into a short tutorial about how to interpret the errors that a new user might see in the console... Some of simple scripting errors and ways to track down typos easier..
I agree about the highlighting in the 1.5 docs, slow/doesn't work sometimes...
Thanks...
09/07/2007 (8:37 pm)
I agree with Benjamin on the common things needed for a game..."$timescale" and pausing is always coming up in the forums and I didn't know about it
for a while, It is the coolest thing ever.....
I think new users (including me) need tutorials that teach how to structure a real game from beginning to end. Users need to know how to begin by creating a Game menu screen with a few selectable options(GUI builder perhaps). Once Player selects let's say "Play" from the menu, users need tutorials on how to load a new level properly, then Tutorials on Pausing the game, setting up conditions to complete the level and load a new level. How to handle Player Lives and Ending the game.
I tend to always create a game but it takes me the longest to impement the seemingly easy things like the beginning and ending...
I hit Play in the LevelBuilder and the Player just pops into the gameplay...
One other request would be to take a simple game and show the user all the options they have for Debugging their game. I have learned alot by taking notes off the forums and am still learning new ways to debug TGB games using only the console and script... (Not meant to cover editors like Torsion)..
Maybe go into a short tutorial about how to interpret the errors that a new user might see in the console... Some of simple scripting errors and ways to track down typos easier..
I agree about the highlighting in the 1.5 docs, slow/doesn't work sometimes...
Thanks...
#6
A few suggestions:
1) Clearly mark the version that the tutorial was written for. When someone refreshes the tutorial make sure that gets recorded.
2) Provide complete versions of the example files to download. In a lot of cases the tutorials have snippets which are great but I would like to have access to the authors compete files.
3) The reference material could really use community annotation. A few months ago I was doing some work with php and was amazed at the quality of the annotations. The user contributions were by far more informative than the base documentation. I do not know what process they use but they must be somehow moderated as there aren't any goofy questions etc. Of course, a lot has to do with the size of that user group but still perhaps we can learn from them.
http://www.php.net/manual/en/language.variables.php
4) Make sure you really go into depth when you do cover a topic. I found this very well done: http://tdn.garagegames.com/wiki/Torque_2D/T2D_3DShapes
(discusses all the things you want to do, some of the issues we are likely to run into, why you want to this etc)
5) Search. Any way we can get the TDN search to be somehow restricted by product? I get so much noise its not funny. (same goes with the forum search; I know you guys got google in a box but isn't there a way to only include 'TGB Private Forums'). I know its not authoring documentation, but I am so much more likely to search for a method name for a discussion or tutorial.
I believe the level of documentation for TGB to be good. The new version did effect a lot of the existing content and its unfortunate.
And as an aside, I looked at TGE today going through the Getting Started tutorial and I have to say it was excellent.
09/07/2007 (9:12 pm)
I still think that you need one or two 'Lets make a simple game from scratch' tutorials as they help teach people how everything fits in. But I understand the level of effort involved which could be used in other areas. Btw, I DID read though the 'Full Game' tutorials that were provided, I found them fun and useful.A few suggestions:
1) Clearly mark the version that the tutorial was written for. When someone refreshes the tutorial make sure that gets recorded.
2) Provide complete versions of the example files to download. In a lot of cases the tutorials have snippets which are great but I would like to have access to the authors compete files.
3) The reference material could really use community annotation. A few months ago I was doing some work with php and was amazed at the quality of the annotations. The user contributions were by far more informative than the base documentation. I do not know what process they use but they must be somehow moderated as there aren't any goofy questions etc. Of course, a lot has to do with the size of that user group but still perhaps we can learn from them.
http://www.php.net/manual/en/language.variables.php
4) Make sure you really go into depth when you do cover a topic. I found this very well done: http://tdn.garagegames.com/wiki/Torque_2D/T2D_3DShapes
(discusses all the things you want to do, some of the issues we are likely to run into, why you want to this etc)
5) Search. Any way we can get the TDN search to be somehow restricted by product? I get so much noise its not funny. (same goes with the forum search; I know you guys got google in a box but isn't there a way to only include 'TGB Private Forums'). I know its not authoring documentation, but I am so much more likely to search for a method name for a discussion or tutorial.
I believe the level of documentation for TGB to be good. The new version did effect a lot of the existing content and its unfortunate.
And as an aside, I looked at TGE today going through the Getting Started tutorial and I have to say it was excellent.
#7
What is a scenegraph, scenewindow, simset?
How do I build my game for non-PC platforms? Do I need to be running TGB on a Mac or Linux to build for those platforms?
09/08/2007 (6:46 am)
I'm a beginner to TGB and to programming. I'm about half way through making a shoot-em-up game and have only learned the things I really need to know to get my game done. Here are some things I'm not sure about and haven't been able to find documentation to explain:What is a scenegraph, scenewindow, simset?
How do I build my game for non-PC platforms? Do I need to be running TGB on a Mac or Linux to build for those platforms?
#8
Granted, I found out later that the specific tutorial I was most interested in was user-submitted, so I shouldn't complain to GG about *that*.
I agree for the most part with the views expressed already, however I want to put up one vote for comprehensive tutorials in one instance... Genres.
I'm fairly sure there are a list of clearly recognizable game types or genres that GG users are likely to want to make. With this knowledge, maybe we could see genre-based walkthrough tutorials.
Yes, they're usuallly larger and take more effort, but if say a new user wants to make a scolling shooter, the old shooter tutorial was a good way to learn all the common elements that go into most shooters.
Personally I'm interested in an RTS tutorial/walkthrough, but I realize I'm just one man.
Keep up the good work!
09/08/2007 (12:46 pm)
Now this is a thread I can get interested in. I was one of those slightly dissappointed by the TDN docs, though in my case it was due to outdated and unfinished tutorials.Granted, I found out later that the specific tutorial I was most interested in was user-submitted, so I shouldn't complain to GG about *that*.
I agree for the most part with the views expressed already, however I want to put up one vote for comprehensive tutorials in one instance... Genres.
I'm fairly sure there are a list of clearly recognizable game types or genres that GG users are likely to want to make. With this knowledge, maybe we could see genre-based walkthrough tutorials.
Yes, they're usuallly larger and take more effort, but if say a new user wants to make a scolling shooter, the old shooter tutorial was a good way to learn all the common elements that go into most shooters.
Personally I'm interested in an RTS tutorial/walkthrough, but I realize I'm just one man.
Keep up the good work!
#9
http://www.modwiki.net/wiki/RotateTo_%28script_event%29
it says how to use it, what the vars mean & then an example with an explanation & why it's different from other, similar, functions.
I've found that documentation like that is more useful then a full blown tut on a specific ting to do (IE shooter game) because you have the info on how to do the parts of something then a specific way of doing it. I've done a heck of a lot in Doom 3 with virtually no documentation except that but in TGB I have examples like "how to make a side scroller shooter" & "how to make a whack-a-mole" but when I want to do something different (ie rotate my ship) there's no short example on how rotate works & I spend more time then I'd like figuring it out (case & point: I found out in Doom 3 that the "rotate" functions all rotate the opposite direction on the Z plane then the editor shows. So if I figured I wanted to rotate something 90degrees clockwise in the editor I needed to do it -90 in a script. Frustrating!)
09/08/2007 (3:59 pm)
More examples with script functions. I've found that with an example of how something works (not just what each function/var means) it's easier to figure out as you can plug it in to a script & see it work. Take a look at this:http://www.modwiki.net/wiki/RotateTo_%28script_event%29
it says how to use it, what the vars mean & then an example with an explanation & why it's different from other, similar, functions.
I've found that documentation like that is more useful then a full blown tut on a specific ting to do (IE shooter game) because you have the info on how to do the parts of something then a specific way of doing it. I've done a heck of a lot in Doom 3 with virtually no documentation except that but in TGB I have examples like "how to make a side scroller shooter" & "how to make a whack-a-mole" but when I want to do something different (ie rotate my ship) there's no short example on how rotate works & I spend more time then I'd like figuring it out (case & point: I found out in Doom 3 that the "rotate" functions all rotate the opposite direction on the Z plane then the editor shows. So if I figured I wanted to rotate something 90degrees clockwise in the editor I needed to do it -90 in a script. Frustrating!)
#10
09/08/2007 (5:32 pm)
As I think about it, all of the little lacks of the documentation would be resolved by a REAL search function on the GG website. Right now it's worthless, google or not (and it should be far less time consuming to fix than rewriting a docs that match the forum in term of informations...).
#11
but the search in the included doc's is pretty good.
09/08/2007 (7:17 pm)
All google searches on all websites i find 100% worthless. They turn up so much junk. but the search in the included doc's is pretty good.
#12
There is tons of documentation available for TGB, but finding it can be time comsuming.. I find that most of the time I am searching for something instead of writing code. The answer is there, but I can't find it. I use the forum most of the time, asking for help. If you check the forum you will see my name a lot.
I am not complaining, (although it may seem like it). I am just suggesting (or seconding) a revamp of the forum search.
I did go thru the Fish game and a couple of others. This did give me some experience using Torque.
Smaller byte size expamples would be great also.
In the documentation that exists, an example of the syntax use would be helpful. Tell me how it works then show me, if only a one liner.
Also, as stated before, get rid of the highlighting. A lot of the time, it just tells me that there are too many instances and to use ctrl F. I use that anyway. The highlighting is more of a distraction. Also a comment of the the search in the docs. I searched for "for(" and go no results. I am sure there are lots of instances of "for(" but it found none of them. Then I searched for "for" and found every page.
Thanks for taking the time to ask for input. I hope I have helped and not complained. That was not my intent.
09/09/2007 (1:13 pm)
I agree with the comments about the site search engine. If you look at MOM's forum search engine, you would see a how it could work. Their forum search engine is great!There is tons of documentation available for TGB, but finding it can be time comsuming.. I find that most of the time I am searching for something instead of writing code. The answer is there, but I can't find it. I use the forum most of the time, asking for help. If you check the forum you will see my name a lot.
I am not complaining, (although it may seem like it). I am just suggesting (or seconding) a revamp of the forum search.
I did go thru the Fish game and a couple of others. This did give me some experience using Torque.
Smaller byte size expamples would be great also.
In the documentation that exists, an example of the syntax use would be helpful. Tell me how it works then show me, if only a one liner.
Also, as stated before, get rid of the highlighting. A lot of the time, it just tells me that there are too many instances and to use ctrl F. I use that anyway. The highlighting is more of a distraction. Also a comment of the the search in the docs. I searched for "for(" and go no results. I am sure there are lots of instances of "for(" but it found none of them. Then I searched for "for" and found every page.
Thanks for taking the time to ask for input. I hope I have helped and not complained. That was not my intent.
#13
09/10/2007 (10:35 am)
Great feedback, thanks everyone, it's all been very helpful and constructive. 
#14
I see your point about making game specific tutorials being not useful to everyone while references are, so, improved reference documentation and general topic tutorials might be a good thing to focus on first.
For documentation that ships with TGB this should probably be the focus, BUT I still think additional, genre-specific starter kits should be available for those that need them. These can be sold separately and would not just help a lot of people, but actually make money. I personally see the presense of starter kits as part of the documentation, even if they are bought separately. These starterkits could be made by anyone, but seeing as TGB has been out a while, maybe GG should start working on a few of their own?
09/10/2007 (11:51 am)
Improved reference documentation would be great, like having complete descriptions of all methods, including intended usage. Half of them now seem to be missing that. The idea of mini-tutorials introducing specific TGB concepts, like animated sprites, behaviors, tilemaps, etc, seems like a great idea, but they just don't go into enough detail. Specifically, tutorials should cover the script side of a topic not just the editor side (tilemapes / tilelayers).I see your point about making game specific tutorials being not useful to everyone while references are, so, improved reference documentation and general topic tutorials might be a good thing to focus on first.
For documentation that ships with TGB this should probably be the focus, BUT I still think additional, genre-specific starter kits should be available for those that need them. These can be sold separately and would not just help a lot of people, but actually make money. I personally see the presense of starter kits as part of the documentation, even if they are bought separately. These starterkits could be made by anyone, but seeing as TGB has been out a while, maybe GG should start working on a few of their own?
#15
Seeing everything in action is really important - and if it has nice comments, I think most people could figure it out pretty fast.
(Side note to Matt - did you guys get a new spam filter or are you massively busy and my emails aren't getting to you? No problem either way, I've been enjoying my quality time with TGEA ;)
09/10/2007 (12:08 pm)
On top of all the stuff mentioned so far, I think simple, but polished games are extremely useful. Once you've got the basics down from the smaller tutorials, I think it's very instructive to go through a bigger game and try to understand how everything is done. (For instance, have the little games I did been released? I guess they need to be ported, but I think a lot of people could learn from Battleship or Reactor)Seeing everything in action is really important - and if it has nice comments, I think most people could figure it out pretty fast.
(Side note to Matt - did you guys get a new spam filter or are you massively busy and my emails aren't getting to you? No problem either way, I've been enjoying my quality time with TGEA ;)
#16
I completely agree and I think what you're doing is great. Those make a lot more sense as separate sellable products (like you are planning) which justify continued updates (since maintaining is one of the largest issues) as well as extensive documentation and design. Doing this as a separate product justifies the added resources it takes to do so, vs. doing this in the official product we would have to justify the resources to do it right.
09/10/2007 (1:47 pm)
Quote:For documentation that ships with TGB this should probably be the focus, BUT I still think additional, genre-specific starter kits should be available for those that need them.
I completely agree and I think what you're doing is great. Those make a lot more sense as separate sellable products (like you are planning) which justify continued updates (since maintaining is one of the largest issues) as well as extensive documentation and design. Doing this as a separate product justifies the added resources it takes to do so, vs. doing this in the official product we would have to justify the resources to do it right.
#17
09/10/2007 (1:48 pm)
Thanks for the reminder Tom. The last couple weeks have been long days and late nights so it slipped my mind. If I don't e-mail you by tomorrow let me know, you are a valuable resource to utilize :)
#18
I'm not sure that we need "more tutorials" necessarily -- I feel like there are *tons* of TGB tutorials. The problem is that so many of them suffer from documentation rot -- they work with 1.1.1, or 1.1.3, or 1.5.1, etc. TDN is a perfect example of this -- it's a great idea, but it's just not very well maintained, and it just hasn't gotten its feet underneath itself to really push off of the ground.
I really liked the old Shooter tutorial -- that one was fantastic. That and the Mini Platformer tutorial are what first really got me going with Torque Game Builder and got me cranking away with things. They are a great mix of "Look ma, no code!" simplicity and showcasing some of the power of TGB that could be used in a "real" game.
"Best Practice" is something that was really puzzling me for a long time. How exactly does someone do a platformer game in TGB? Is there a way to make a solid platformer? If there is, I haven't yet seen one. For a while, I felt like I was always reinventing the wheel any time I wanted to integrate the TGB splash screen into my games. Why isn't there a game template with that sort of thing? That's the sort of example/documentation that I feel could help new users get off the ground.
I do recognize the hard balance that tutorials are in though -- if a tutorial is too large, then it becomes unweildy to maintain and it doesn't get updated from version-to-version (Checkers, Fire & Healing, Tank Buster). However, if it's too small, then it's not very good for showing Torque's usefulness in the context of larger projects.
So yeah, I think I lean towards desiring smaller "mini" tutorials that are updated from version-to-version to show "best practice" (or at least show how the Torque devs imagined their engine being used), as well as a single larger project (such as Tank Buster) that gives an overall "this is what a full-size project looks like" sort of picture.
Thanks, Matt! You do a great job with documenting TGB -- I'm always salivating over the next release, and I can't wait to see the tool get even better and more solid than it already is.
--clint
09/10/2007 (1:55 pm)
I really appreciate the documentation that exists currently. When I'm coding in Torque, my browser almost always has the TGB Reference page open to t2dSceneObject or Console Functions or something. Those docs are great. There are many descriptions that are obvious copy/paste typos, but other than that, I'm very happy with what's there.I'm not sure that we need "more tutorials" necessarily -- I feel like there are *tons* of TGB tutorials. The problem is that so many of them suffer from documentation rot -- they work with 1.1.1, or 1.1.3, or 1.5.1, etc. TDN is a perfect example of this -- it's a great idea, but it's just not very well maintained, and it just hasn't gotten its feet underneath itself to really push off of the ground.
I really liked the old Shooter tutorial -- that one was fantastic. That and the Mini Platformer tutorial are what first really got me going with Torque Game Builder and got me cranking away with things. They are a great mix of "Look ma, no code!" simplicity and showcasing some of the power of TGB that could be used in a "real" game.
"Best Practice" is something that was really puzzling me for a long time. How exactly does someone do a platformer game in TGB? Is there a way to make a solid platformer? If there is, I haven't yet seen one. For a while, I felt like I was always reinventing the wheel any time I wanted to integrate the TGB splash screen into my games. Why isn't there a game template with that sort of thing? That's the sort of example/documentation that I feel could help new users get off the ground.
I do recognize the hard balance that tutorials are in though -- if a tutorial is too large, then it becomes unweildy to maintain and it doesn't get updated from version-to-version (Checkers, Fire & Healing, Tank Buster). However, if it's too small, then it's not very good for showing Torque's usefulness in the context of larger projects.
So yeah, I think I lean towards desiring smaller "mini" tutorials that are updated from version-to-version to show "best practice" (or at least show how the Torque devs imagined their engine being used), as well as a single larger project (such as Tank Buster) that gives an overall "this is what a full-size project looks like" sort of picture.
Thanks, Matt! You do a great job with documenting TGB -- I'm always salivating over the next release, and I can't wait to see the tool get even better and more solid than it already is.
--clint
#19
Example:
09/10/2007 (2:13 pm)
It's not all bad, I just wish the documentation would explain more about the functions and their parameters and what the function actually does. Maybe listing any quirks or notes on the function. Maybe with links that show more detail about what the terms being used mean. Example:
t2dSceneObject::getAtRest() Description: Gets whether the Object is at Rest."At rest." What does that really mean? What are the implications involved with setting an object "at rest" in the physics simulation? It may be obvious to most people, but to someone with no physics knowledge it might not be. I just think the current description of this function is somewhat useless, it just restates what the function name already says.
#20
While 1.5 has a longer list of commands, the comments simply aren't done.
09/10/2007 (3:19 pm)
From the 1.1.3 TGB Reference :getAtRest() Purpose Gets whether or not the object is completely at rest. Return Value - Bool True if the object's linear and angular velocities are 0. False otherwise.
setAtRest()
Purpose
Completely stops the objectData Types: Object
.
Notes
*
Both linear velocities and angular velocities are set to 0 so the object will be at rest right after the function is called. However, if any forces are applied to the object after it is set at rest, it will move again.While 1.5 has a longer list of commands, the comments simply aren't done.
Torque 3D Owner Marc 'Dreamora' Schaerer
Gayasoft
1. A tutorial that dives into datablocks, class and superclass and the usage of the inheritance and datablock clone functionality ( bla : blubb)
2. A behavior tutorial that takes inter behavior coding into account and for what they could be missused potentially (when I remember correctly, behaviors themself could hold behaviors as well, correct?)
Thats up what I can think of as general tutorials beside one for the level editor perhaps. (oh and when we are on the level editor: could you please readd the datablock dropdown menu? did that manually in my build as I found it quite frustrating to assign the datablock after placing the object which is quite annoying)
Generally I like the docs, although there are some shortcommings: 1.1.3 was generally better structured out of the scripter perspective (never really looked at the tutorials I've to say).
The 1.5.1 docs still lacks the behavior documentation completely. Its still needed to check the TDN for the callbacks and the like.
No real complaint to make on the docs.