Game Development Community

Couple tutorial things (nothing major, a typo etc)

by Matthew Langley · in Torque Game Builder · 02/25/2005 (10:00 pm) · 16 replies

function playerUp()
{
// Set the player moving up.
$player.setLinearVelocityY( - );
}

the -$10 should be -10


Also when you talk about collision you use this

// Set player's collision info:
$player.setGroup( 1 );
$player.setLayer( 1 );
$player.setCollisionActive( true, true );
$player.setCollisionMaterial( standardMaterial );
$player.setCollisionPolyCustom( 4, "-1 0 -0.1 -0.6 0.98 0.15 -0.1 0.7" );
$player.setCollisionMasks( BIT(2), BIT(2) );
$player.setCollisionCallback( true );


however, the order of the explanations go like this

group
layer
.setCollisionActive()
setCollisionScale()
setCollisionMasks()
etc etc etc....

just a little mix up :) LOVE the tutorial though... T2D is awesome

About the author

Was a GG Associate and then joined GG in 2005. Lead tool dev for T2D and T3D. In 2011 joined mobile company ngmoco/DeNA and spent about 4 years working game and server tech. 2014 joined startup Merigo Games developing server technology.


#1
02/26/2005 (6:12 am)
Thanks Matt! Good catches, and sorry for the typos.
#2
02/26/2005 (1:04 pm)
This isn't a bug, really, but is possibly a terminology flaw that could cause confusion. It's admitted in the Informal Technical Overview that "world limits" is a bad name for the functionality they provide.

I'd just like to support the idea of actually changing this officially to something more intuitive. Naming can be a huge barrier in comprehension (of algorithms in code as well as concepts in documentation), so this change would be beneficial to all.

"Movement bounds" or "movement regions" would indeed be better and would help reduce the learning curve. Now is a good time to clean up these sorts of issues since the engine is new and hasn't gotten entrenched just yet. :)

$.02.
#3
02/26/2005 (1:37 pm)
Thanks Jason, we'll definitely consider doing so. :)
#4
02/27/2005 (12:02 am)
Also, on Page 17, the example code:
$player.setWorldLimit(clamp, "-49 -37 40 37");
should really be

$player.setWorldLimit(clamp, "-49 -37 49 37");
#5
02/27/2005 (2:22 am)
@Drew: I see where you're going there as that's just shy of the right-hand side of the screen but it felt better to not allow the player to go that far so technically, this is correct but I can see how in a demo this could be confusing.

Thanks for the heads-up. Any other suggestions are most welcome.

- Melv.
#6
02/27/2005 (11:10 pm)
Hmmm I had a problem with the $10 thing but even when I replaced it and deleted the dso file I still got errors. Also I was checking it without the stop function created but it still should work.

I am correct in thinking that the keybinding belonged in the setscenegraph function correct? And not on it's own?

I'll try it again when I get home and if it still doesnt work i'll post the error.
#7
02/28/2005 (3:32 am)
Charlie, not quite sure what you mean, but if you mean that you were defining the playerUp() function inside of the SetupT2DScene() function... you can't do that. playerUp() should be defined out on its own.

If you just meant that you create the action map inside SetupT2DScene, then yes, that is the correct way to do it (at the beginning of the tutorial, then we show you a better organization later on).

The scripts definitely work (except for the $10 typo!), so you might've mis-typed / mis-copied something?
#8
02/28/2005 (6:51 am)
Yeah I guess I did. It was the $10 thing. Even though I swear I fixed it.

I know better then to try to declare functions within functions and all that. I really think it came down to the engine skipping to the .dso file though.

Either way it works now!
#9
02/28/2005 (7:44 am)
I have another naming niggle since I'm pedantic about this sort of thing. In fxAnimationDataBlock2D how about renaming "animationCycle" to "animationRepeat"? The word cycle is kind of ambiguous IMHO.

I don't mean to pick nits, but this kind of thing has a large impact on the overall comprehension of how things work. Plus it saves time if the fields are self-describing rather than needing to clarify by digging through the reference docs.

Don't worry, I'll mention other things I find along the way. :)
#10
02/28/2005 (8:04 am)
Hmmm. I always think of a cycle as being a scheduled repetition, whereas I see repeat and I think of immediacy rather than scheduling. I'm not sure if that's waht you're talking about with ambiguity, but I thought I'd add how I see the two terms at first glance.
#11
02/28/2005 (9:08 am)
I had to read the description to determine if animationCycle meant that it repeats or if it meant which "cycle" (sequence of frames) to play. Dunno, maybe it's not that ambiguous to other people. :)
#12
02/28/2005 (9:34 am)
I'm happy with either one. We'd have to have a good reason to break peoples code or have duplicate fields at this point though. ;)

- Melv.
#13
02/28/2005 (9:32 pm)
I know a lot of 3d modeling programs used the world "cyle" and "cyclic" animations.... though I can understand the misunderstanding... then again thats what the tutorials are for :)
#14
03/09/2005 (2:42 am)
@Malcolm: This isn't a new thing for computers really. I can write code even in a type-safe language like C++ and get no errors/warnings whatsoever. This is not a failing of TorqueScript, there will always be syntax that is valid but isn't what you actually intended.

Quite often, this is related to the accidental use of string comparisons which equate to zero.

I do agree though, that TorqueScript could do with certain improvements and I know that this work is taking place as Ben Garney has recently started a major move towards tightening the syntax and making it more useful. Things such as not using the "+" operator like this, "+100", should be allowed.

Like most script languages though, it's most painful when you're just starting-out, especially with the typeless nature of the beast. As you start using it in anger, you start to become more careful how you write code. For very complex applications though, you can actually debug the scripts and quite often, it's fairly easy to narrow-down any problem, at least that's my experience.

- Melv.
#15
03/26/2005 (9:36 pm)
Hmm ok I know the bit on the collision was stated up top, but I wanted to go over it again because its really messed up and doesn't give me the information at all really.

The document has you making calls that you don't explain, and explaining calls that you don't make. Its more than the order being messed up, its whole functions replaced/not explained.

setCollisionMaterial and setCollisionPolyCustom are both called but neither one is explained. On the reverse side, setCollisionScale is explained but never actually called.

So no matter how I look at it i'm kind of lost hehe. Would be nice to have explanation for the setCollisionMaterial and setCollisionPolyCustom calls. Now i'm a big boy and could probably figure it out, but while i'm here sludging my way through the tutorial its a rather unwanted jolt. TBH the collision step is a rather major couple of notches on the totem pole to absorb at once. Having the docs messed up on it makes it an even harder climb :)
#16
07/05/2005 (10:33 am)
I had a "problem" with setCollisionMaterial. When you go into console mode it shows errors on the calls to this function, don't ask me the exact error, I'm at work and all this happened at home.

When I looked at the source I can see the function defined but no where is there a list of the constants: missileMaterial, standardMaterial.

Doesn't break the script, it just keeps on running but those constants should be defined someplace.

BTW: what the heck is CollisionMaterial and whats it used for?