Why WAS Torque3D documentation so poor?

#381 I know this might be a bit of a strange request in this day and age but would it be possible to create print-ready versions of the various documents?

I'm asking since I know I feel more comfortable having something I can hold in my hands and flip through and rather than trying to print each page individually it'd be much handier if it came in a readily printable format ( I'm referring here to T3D documentation such as at http://docs.torquepowered.com/torque-3d/official/ )

#382 I don't have anything set up to make contiguous page prints. A little clever batching and access to my order.txt files (used in the Doc System), would make it easier though. Someone in the forums may have already solved this, because it has been requested before. However, I only have time to generate content right now.

#383
Best option is probably to use Doxygen's Latex or RTF output, convert that to PDF, and print that.

#384

Quote:@Glen - AI players have move-to. Player objects use $mvForward. As for static objects, you would most likely need to use setPosition or implement an interpolated movement like the player classes. You can see an example of that in the RTS Prototype tutorial in the online docs.

Thanks Mich. I assume that the mvForward is just a setting of speed? If so that's good. Does it also use physics to keep from sticking into other bounding boxes?

As for the mood of the topic, it's nice to see that the posts have changed. I guess it just takes a little proof. Good work Eric, Mich, and your team. ;)

#385 $mvForward is a direct input to move forward (eg: a keystroke) on the client (notice the $ global). Speed settings are always maximum available to the pose - (art)player.cs for pose speeds, (scripts/client)default.bind.cs for setMoveSpeed() function.

Collision of players - and thus inhereted by Ai - is based on clashing bounding boxes (and possibly mass and runforce though I haven't tested this). Players/Ai can get stuck together if the angle and speed of collision is from opposite directions. (easiest solution, a little impulse in onCollision to force them slightly apart on contact will make them slide off one another).

#386 Thanks Steve. It's nice to know that the move speeds and all are customizable, and since it's a direct keystroke command It's easily resettable.

As for the collision, that's ok. I had to do more than that with our game PreVa. The collision was bad so I had to make a script that forces out the opposite way of being stuck.

#387 ActionMap
Anyone know the differences between bind, bindCmd, and bindObj?

Know how to switch between ActionMaps?

How to unbind an action without deleting an ActionMap?

How to find out what function is bound to a keyboard space?

Ever seen documentation on the flags used when binding?

Well, you will from here on. Check out the new CHM section under Modules->Input Management. Clicking on the ActionMap class takes you to the updated API docs. Also have a nifty Input Event Listing table reference.

Updated TorqueScript Manual (don't forget to unblock it)

Progress, and not just quick "once overs". Quality progress. Please remember that this is still WIP.

Btw, if you find any error in logic or have a better explanation of a function...please please please e-mail me: michaelp@torquepowered.com.

#388 Thanks for the update, Michael.

#389 Among other classes being documented, we just put a MAJOR dent in the File I/O docs. Once the site cache is flushed (give it about 45 min), you will have access to the new docs for:

- FileObject
- FileDialog
- OpenFileDialog
- SaveFileDialog
- ConsoleLogger
- BanList

It should be noted Dave has been working hard too, some of the recent things he's been committing:

- Explosion
- ExplosionData
- Splash
- SplashData
- Precipitation
- PrecipitationData
- Lightning
- LightningData
- LightningStrikeEvent
- GroundCover
- fxShapeReplicatedStatic
- fxShapeReplicator
- fxFoliageReplicator

Yeah, we have our game faces on. Doing our best to rectify nine years of doc neglect.

#390 Perhaps a little bit of UML chart love at this point might be useful as well. I see lots of people asking how to think about game creation.

#391 Great work guys

#392 Just being proactive here.... Michael will be working on a blog to update everyone in the next week or so.

#393 Sweet. Thanks Eric, I'm looking forward to it.

#394 Hi folks,
I haven't found a reference to this issue. I can't get any data in the CHM.
I've turned off the firewall in case this was the issue but still get 'Navigation to the web page was canceled'

Have I missed something on one of the earlier posts?

#395 @David - Right click the .CHM, go to properties, and choose to Unlock the file. I'm not sure why CHM files have this issue - but that will likely fix it.

#396 @Bryan cheers mate your blood's worth bottling!

All fixed.

#397 @All - Back from Seattle, very heads down on work. Here is what's going on with the docs:

(listed by priority)

1. Working on the TS API for the CHM
We are tearing through classes left and right. Making a lot of good progress, but finding some very odd issues in the engine. A good example is that the FlightCeiling and FlightCeilingRange variables for MissionArea are used strictly by the FlyingVehicle class. However, these variables are only used if the MissionArea is called "GlobalMissionArea". Some of these have caused us to stumble, but we are good about not getting caught up. So far, so good. Just a lot of work in a very small time frame.

2. Converting and committing new guides for River, Decal, Particle, DecalRoad, and MeshRoad editors
These were created by our other writer, and are along the same lines as the other guides for Forest Editor, Terrain Editor, Terrain Painter, etc. Very nicely done, and I'm thinking about changing the guides I wrote to fit the format. These will be pushed online after the CHM is done, or in between compile times.

3. Fix the broken links and images for the online docs
On my local machine, the docs look good. When pushed online, some links are broken and images missing. This has a lot to do with the capitalization (thanks orb), and some html tags. Hope to have this fixed when I push the new editor guides.

4. Write documentation blog
As Eric mentioned, I'm going to post a blog about documentation. This will not be all about T3D docs. Instead, it covers the range of Torque documentation, how it has progressed in 9 years, and what documentation means for all parties involved. Should be a great read.

#398 Kind of off-topic but noticed Michael's comment about flight ceiling & mission area -- there's quite a few things left from the Tribes days that are only partially implemented (or referenced) in Torque's code. Had wondered how such things would affect documentation... glad it's not me having to address such, hehe ;)

#399 @Michael - Definitely some WTF moments when documenting this engine. Legacy code can be a PITA.

#400 Michael,
I hope you take the opportunity to take note of unintuitive stuff like that, so it can be changed, and made better for the next versions.