Game Development Community

TGB 1.7 Released

by Dan Maruschak · in Torque Game Builder · 01/30/2008 (5:56 pm) · 53 replies

TGB 1.7 is out! More details in my blog post.
#21
02/02/2008 (12:29 pm)
@Phillip - If you have the box checked, you should be able to see any other objects in the scene.
#22
02/02/2008 (1:27 pm)
It doesn't work for me Dan, it just displays the white background.
#23
02/02/2008 (3:00 pm)
Can you send me some screenshots, and maybe pack up your project and send it to me, so I can try to figure out what's going on?
#24
02/02/2008 (5:08 pm)
Awesome work on TGB 1.7 guys! I finally made the jump from 1.1.3 and I'm loving it! I've already run into some strange bugs that I'll post later, but I found easy enough work arounds so I'm not worried at all about them.

PS

Never thought I'd see the day when there were concave collision polygons in TGB!
#25
02/02/2008 (5:11 pm)
@Kevin - Sorry, the collision polygons still need to be convex. If it's letting you save concave ones, that's probably a bug.
#26
02/03/2008 (5:55 am)
Oh. I guess the red nodes means that you have to move them. Hahaha!
#27
02/04/2008 (2:28 pm)
I sorted it Dan, it was loading an old script from my roaming folder, I just cleared that out and it is working fine.

Cheers mate.
#28
02/04/2008 (9:10 pm)
1.7.1 looks great, I like the collision and link point editors.
I noticed a bug - in D3D mode resizing the window corrupts the display, as does maximizing the window. Works fine in openGL though.

Also, when I create a polygon object, I can see it in the editor, but it's invisible when I run the game. Is there some script required to get them to draw?
#29
02/05/2008 (6:38 pm)
1.7.2 is now live. It has:

- Bug fix: cloneWithBehaviors method now copies linkpoints from original object to clone
- Bug fix: t2dShape3D objects now clone properly with cloneWithBehaviors method
- Bug fix: t2dShapeVectors now take the FlipX/FlipY properties into account when rendering
- Bug fix: small tweaks and fixes to the new editors introduced in 1.7
- Added support for a new type of behavior field: "localpointlist"
#30
02/05/2008 (6:49 pm)
Awesome hustle with this one, guys. Fantastic!
#31
02/05/2008 (7:40 pm)
Wow...this kind of turnaround time on bugs is respectable.
#32
02/06/2008 (3:53 pm)
Except these two minor bugs remain unfixed:
http://www.garagegames.com/mg/forums/result.thread.php?qt=71771
http://www.garagegames.com/mg/forums/result.thread.php?qt=67835

I've had contact with GG employees regarding these bugs, but because they are not part of the TGB team, it seems to not have an impact on getting the simple fixes into the last three releases which have occurred over the course of five days.

Greg
#33
02/08/2008 (2:29 pm)
Edit: Really stupid...Wow. Linkpoints do not correspond to mountIDs and are returned in world space.

Hey Dan, I think the LinkPoints stuff might have been messed up a bit in this fix:
Quote:- Bug fix: cloneWithBehaviors method now copies linkpoints from original object to clone

Specifically, getting a linkpoint's position with getLinkPoint does not seem to work logically at all.
First, if you pass in 0 as the mountID, you get "0 0" in all cases that I've tested. This definitely doesn't match the awesome new linkpoint editor, which calls the first linkpoint the 0th.

Second, the return value from getLinkPoint is not what it should be, as far as I can tell. I did some quick testing to confirm. If I make an object, add a link point, start the level, and then use getLinkPoint to get the position, it returns points that are definitely not what the editor said.
It looks like it might be getting mucked up with worldspace transforms, but I don't have time to check it out.

Here are some X values on the left that I put in using the editor, and the corresponding X values returned from getLinkPoint:
-1       -14.81
-0.6     -8.4
0.4      7.59
1        17.18

I'm correct in expecting the values to be the same, right? They're linear (16x+1.19ish), but not symmetrical or logical...
#34
02/08/2008 (2:42 pm)
@Tom - LinkpointIDs are funny, and don't necessarily conform to the numbers you see in the editor (and generally won't). LinkpointIDs are actually arbitrary "tag" numbers that are used as lookup keys into the linkpoint data structure, not an index into a linkpoint array. I considered changing the linkpoint system so that the "0th linkpoint" would be accessed by getLinkPoint(0), but that could potentially break backwards compatibility, so I didn't make that change.

To get the0th linkpoint of t2dSceneObject %obj, I usually do something like:
%lpid = getWord(%obj.getAllLinkpointIDs(), 0);
echo("world position of 0th linkpoint is" SPC %obj.getLinkpoint(%lpidN));
#35
02/08/2008 (2:51 pm)
@Dan - ok, that makes sense, but I've only got one linkpoint and the values are still wrong. If getLinkPoint gives you non zero values, shouldn't those values match at least one of the points in the link point editor?
#36
02/08/2008 (2:53 pm)
GetLinkPoint returns the world-position of the linkpoint.
#37
02/08/2008 (2:55 pm)
That seemed illogical to me (given my task), but should fix all my silly problems :)

Thanks Dan!
#38
02/08/2008 (6:30 pm)
Why on earth does getLinkPoint return the world position of the point? No other internal point function does that. It is easy to convert it, yet it seems very illogical.
#39
02/08/2008 (6:35 pm)
I thought it was a bit odd too, but then I realized that one common use for linkpoints is to set places where projectiles come from or other specific world events happen. I agree that it's odd, though. Was unexpected, to be sure :)
#40
02/10/2008 (4:03 am)
@Dan M
Another odd thing about linkpoints is that the mountToLinkpoint
input parameter trackRotation seems to have no affect. The mounted object does its own rotation regardless if this value is set to true or false.

%srcObject.mountToLinkpoint(%dstObject,getRandom(1,4),0, false,true, true, true);


trackRotation: Whether or not to track the rotation of the object this is being mounted to.