It's maybe a Bug
by Firas · in Torque Game Builder · 10/06/2006 (12:49 am) · 24 replies
Hi guys
I was playing with the miniPlatformer tutorial alot in the last 3 days and I found somthing:
the movement of the player is very good and smooth until you define a custome collison polygon for your player, so if you define a collision polygon for the player you will have some problem with movement speacilly the jump key, you will press space bar many times to make your player jump and it will stuck alot on some corners.
I know this sound strange but please give it a try.
waiting for replay
thanks
I was playing with the miniPlatformer tutorial alot in the last 3 days and I found somthing:
the movement of the player is very good and smooth until you define a custome collison polygon for your player, so if you define a collision polygon for the player you will have some problem with movement speacilly the jump key, you will press space bar many times to make your player jump and it will stuck alot on some corners.
I know this sound strange but please give it a try.
waiting for replay
thanks
About the author
#2
thansk
10/08/2006 (10:50 pm)
Oliver colud you tell us more about your problem, coz I think the more we desripe the problem the better for the GG people to understand and solve the problem.thansk
#3
TGB: Torque Game Builder v1.1.2, OSX.
Code: MiniPlatformerTutorial
Symptoms:
Everything works fine when:
I follow the tutorial to the T and do not define my own collision polygon.
Things break when:
I define my own collision polygon. My polygon has five points with a flat line [read: as flat as it can be according to the levelEditor collision polygon editor] spanning the entire bottom of the t2dAnimatedSprite. When I do this I get the issues explained in this thread. Specifically:
Seems like there's still some issues to be worked out in the collision code? I hear that we're to be amazed at the next release... is this addressed?
10/09/2006 (5:33 pm)
I have the same problem. Here's my info:TGB: Torque Game Builder v1.1.2, OSX.
Code: MiniPlatformerTutorial
Symptoms:
Everything works fine when:
I follow the tutorial to the T and do not define my own collision polygon.
Things break when:
I define my own collision polygon. My polygon has five points with a flat line [read: as flat as it can be according to the levelEditor collision polygon editor] spanning the entire bottom of the t2dAnimatedSprite. When I do this I get the issues explained in this thread. Specifically:
Quote:My character only gets stuck (or cannot jump) when I've landed while actively moving left or right. I'm not sure what's going on but if I'm holding down left or right when the avatar lands then everything stops. If I move around in the air with the keys but let go right before contacting a platform then I'm safe and can move around freely.Even more fun is that I had my new pGuy jump on my old pGuy (landing on the top of old pGuy's polygon - which is a single point) and the new pGuy couldn't move. Left, right, jump... none of it worked. I could tell things were still working, though, because the animations would switch between left and right depending on what button I had last hit.
Seems like there's still some issues to be worked out in the collision code? I hear that we're to be amazed at the next release... is this addressed?
#4
My new code follows (this makes the bounding polygon a bit tighter on the bottom and incorporates the apex problem fix):
10/09/2006 (6:04 pm)
Upon further testing I have found that if you specify a perfectly straight line for the bottom of the player, the code in the MiniPlatformerTutorial works okay, even with custom collision polygons. My two bottom points had their y-components offset ever-so-slightly. I modified my collision polygon by going into the level1.t2d file and editing the polygon directly. I changed it to read:CollisionPolyList = "-0.945 -0.012 -0.082 -0.671 0.970 -0.326 1.000 1.000 -1.000 1.000";You can see that the last four numbers (1,1, -1, 1) the (x,y,x,y) values of the two bottom points. What's fun is that I now notice that the player can get stuck on the ceiling if his polygon hits it (the top of my polygon is a single point... like a rooftop). I just went in and added a point really close to it that lies on the same horizontal line (y=0). No more getting stuck in the ceiling.
My new code follows (this makes the bounding polygon a bit tighter on the bottom and incorporates the apex problem fix):
CollisionPolyList = "-0.945 -0.012 -0.082 -0.675 0.082 -0.675 0.970 -0.326 0.970 1.000 -0.940 1.000";The fun part is that this does not bode well for uneven surface contacts... perhaps this can all be sidestepped by using pickLine instead of castCollision to determine stuff. I'll try some stuff out and see how it goes.
#5
Getting stuck is related to the wall-climbing fix. In the code it comes through as:
Why is this important? Because of sloped platforms. If you have a 45 degree slope, for example, then you're going to be out of luck using this algorithm because you're going to have an x-component collision resulting in no movement up the slope (down works for obvious reasons).
In short, the above fix should work as a stop-gap for most people. It will only work for a final solution if you resolve to have zero slanted surfaces in your game.
-----
I believe that it affects the custom collision polygons as well because you're inverting the issue: your platform is level but your polygon (even if it's off by 0.001 units) is the slant. So, either the angle between the contacts is zero (parallel lines) or you don't use the above line to determine collision.
Unfortunately, removing the above also brings back the wall climbing issue... Maybe a more apt solution would be to check the normal between collisions in pGuy's "onCollision" callback.
-----
And I'm still not sure why a perfectly perpendicular collision did not result in the player getting stuck. Perhaps there's a rounding error associated with non-perpendicular collision that was just enough to cause stuff to go all wonky...
10/09/2006 (8:50 pm)
New Info:Getting stuck is related to the wall-climbing fix. In the code it comes through as:
function playerClass::updateMovement(%this)
{
...
%yVelocity = %this.getLinearVelocityY();
%this.setLinearVelocityY(0);
%collision = %this.castCollision(0.005);
// Stops horizontal motion in case of object to the side.
if(%collision !$= "")
{
[b]%this.setLinearVelocityX(0);[/b]
}
...
}The problem goes away if you remove the line in bold above, even without collision polygon sides parallel to the surface they're contacting. Points work just as well.Why is this important? Because of sloped platforms. If you have a 45 degree slope, for example, then you're going to be out of luck using this algorithm because you're going to have an x-component collision resulting in no movement up the slope (down works for obvious reasons).
In short, the above fix should work as a stop-gap for most people. It will only work for a final solution if you resolve to have zero slanted surfaces in your game.
-----
I believe that it affects the custom collision polygons as well because you're inverting the issue: your platform is level but your polygon (even if it's off by 0.001 units) is the slant. So, either the angle between the contacts is zero (parallel lines) or you don't use the above line to determine collision.
Unfortunately, removing the above also brings back the wall climbing issue... Maybe a more apt solution would be to check the normal between collisions in pGuy's "onCollision" callback.
-----
And I'm still not sure why a perfectly perpendicular collision did not result in the player getting stuck. Perhaps there's a rounding error associated with non-perpendicular collision that was just enough to cause stuff to go all wonky...
#6
I'm not sure whats going on with the custom collision poly's (Way out of my leauge) but i'm glad you found the cause of the problem.
10/09/2006 (11:31 pm)
Nice to see you got it figured out Eric, the miniplatformer tutoral was never intended to handle slopes and your right, it will never work in that situation. Hence the "mini" aspect of the tutorial.I'm not sure whats going on with the custom collision poly's (Way out of my leauge) but i'm glad you found the cause of the problem.
#7
I did edit the level file and make sure that my top and bottom are perfectly stright please check this:
CollisionPolyList = "0.896 0.281 0.486 0.996 -0.699 0.996 -0.912 0.024 0.185 -0.558 0.241 -0.558";
note: "0.486 0.996 -0.699 0.996 " this for the bottom poly. and "0.185 -0.558 0.241 -0.558" for the top poly.
and I comment the following line of code in player.cs script like this:
//$pGuy.setLinearVelocityX(0);
this help alot beleave me but it's still stuck with the jump sometimes (try to play with the player for 2 min. or more and press left the right keys a lot after little time the player will not jump even if you press the jump key until you collide with something then pGuy can jump agine).
I don't know If I explain the problem exactly but if you like I can zip my miniplatform folder and send it to your email so you can test it in your computer, do you accept?
thanks in advance.
Firas
10/10/2006 (2:32 am)
Eric thanks agine for your solution it's really help alot but It's still not perfect I I'm saying that coz I have faced the following problem:I did edit the level file and make sure that my top and bottom are perfectly stright please check this:
CollisionPolyList = "0.896 0.281 0.486 0.996 -0.699 0.996 -0.912 0.024 0.185 -0.558 0.241 -0.558";
note: "0.486 0.996 -0.699 0.996 " this for the bottom poly. and "0.185 -0.558 0.241 -0.558" for the top poly.
and I comment the following line of code in player.cs script like this:
//$pGuy.setLinearVelocityX(0);
this help alot beleave me but it's still stuck with the jump sometimes (try to play with the player for 2 min. or more and press left the right keys a lot after little time the player will not jump even if you press the jump key until you collide with something then pGuy can jump agine).
I don't know If I explain the problem exactly but if you like I can zip my miniplatform folder and send it to your email so you can test it in your computer, do you accept?
thanks in advance.
Firas
#8
use setImpulse instead of SetVelocity it seems to work alot better. Atleast that is what I used in my code.
10/10/2006 (12:00 pm)
This might help the devs in solving the Get/SetLinearVelocity bugs with collision.use setImpulse instead of SetVelocity it seems to work alot better. Atleast that is what I used in my code.
#9
10/10/2006 (12:09 pm)
Interesting idea, gonna try it out!
#10
As for why custom polygons broke, it's all a matter of how the angles work out on contact. If the edge of your custom polygon is perfectly parallel with the contact edge then you're safe using this method. If, however, there is any deviation then you have an angle to deal with and some combination of physics, collision, and [pixie dust?] results in a horizontal velocity change. It's really a bunch of simple geometry... when you get down to it.
It's probably due to the CLAMP physics being mixed with the collision: CLAMP will stop the object upon contact. However, according to the physics simulation, the object is not yet 'at rest'. If you land on a single point and are not completely balanced then you will rotate on that point until an edge lands and you can come to rest. Now, as we know, getLinearVelocityX does not return the objects current actual speed but what the current actual speed is set to. My guess would be that the physics engine starts doing calculations for bringing the object to rest. If there is no angle between the platform and the collision polygon (parallel lines) then the work is done. However, if an angle exists then the object will have to rotate to come to rest. This will undoubtedly result in some kind of horizontal movement (thanks to the rotation of the object). Thanks to CLAMP we will not move the character at all (my guess is that linearVelocity components are ignored when this physics response is set) but the simulation will still set the linear velocity value. We poll that value, see that it is "moving" and stop it.
At least that's now I see it working. I still don't feel 100% on the "why?" it doesn't ever break if you're not holding down left or right, but... Maybe it has something to do with shutting off the gravity in the nick-'o-time...
@Firas: A couple of things to watch out for:
1) Your collision polygon was a bit precise. With Y values of 0.996 and -0.558 you're very likely to hit some rounding errors and funky edge cases. I played around with your polygon by setting the above values to 1.000 and -0.550 respectively. I was no longer getting stuck in the ground. (I got stuck in the ground and couldn't move at all after a big jump [I have an event in my code that sky-rockets my player... came in useful for testing].) The ground issue seemed to be gone. But as I was testing I got stuck in the ceiling once (and was able to jump out of it). I set that value to the above and I was no longer getting stuck in the ceiling. Seems like these issues are totally related to rounding errors [???].
Your new collision line is as follows:
3) I don't know why yet (probably due to the order of function calls in the code) but you cannot jump while holding down both left and right at the same time. Be careful that this isn't what's happening when you cannot jump.
Hope that helps!
@Azmodeus: The setImpulse idea is interesting. It would certainly make for more believable physics (as you wouldn't have to stop movement everywhere - makes for a more Mario-esque jumping style... I would assume). I'm going to give that a shot after I work through a few more things.
10/10/2006 (5:32 pm)
@Dan: Heh. I really didn't want to believe it was that code that was causing the issue. The fix for the wall climbing seemed so elegant... Ahh well. I'm going to see if I can't figure something out using the pickLine method.As for why custom polygons broke, it's all a matter of how the angles work out on contact. If the edge of your custom polygon is perfectly parallel with the contact edge then you're safe using this method. If, however, there is any deviation then you have an angle to deal with and some combination of physics, collision, and [pixie dust?] results in a horizontal velocity change. It's really a bunch of simple geometry... when you get down to it.
It's probably due to the CLAMP physics being mixed with the collision: CLAMP will stop the object upon contact. However, according to the physics simulation, the object is not yet 'at rest'. If you land on a single point and are not completely balanced then you will rotate on that point until an edge lands and you can come to rest. Now, as we know, getLinearVelocityX does not return the objects current actual speed but what the current actual speed is set to. My guess would be that the physics engine starts doing calculations for bringing the object to rest. If there is no angle between the platform and the collision polygon (parallel lines) then the work is done. However, if an angle exists then the object will have to rotate to come to rest. This will undoubtedly result in some kind of horizontal movement (thanks to the rotation of the object). Thanks to CLAMP we will not move the character at all (my guess is that linearVelocity components are ignored when this physics response is set) but the simulation will still set the linear velocity value. We poll that value, see that it is "moving" and stop it.
At least that's now I see it working. I still don't feel 100% on the "why?" it doesn't ever break if you're not holding down left or right, but... Maybe it has something to do with shutting off the gravity in the nick-'o-time...
@Firas: A couple of things to watch out for:
1) Your collision polygon was a bit precise. With Y values of 0.996 and -0.558 you're very likely to hit some rounding errors and funky edge cases. I played around with your polygon by setting the above values to 1.000 and -0.550 respectively. I was no longer getting stuck in the ground. (I got stuck in the ground and couldn't move at all after a big jump [I have an event in my code that sky-rockets my player... came in useful for testing].) The ground issue seemed to be gone. But as I was testing I got stuck in the ceiling once (and was able to jump out of it). I set that value to the above and I was no longer getting stuck in the ceiling. Seems like these issues are totally related to rounding errors [???].
Your new collision line is as follows:
CollisionPolyList = "0.896 0.281 0.486 1.000 -0.699 1.000 -0.912 0.024 0.185 -0.550 0.241 -0.550";2) Your polygon is extremely prone to oddities with the wall-climbing fix in place (I haven't changed my test code to remove it for good yet). You get stuck on any edge with it when you jump into it.
3) I don't know why yet (probably due to the order of function calls in the code) but you cannot jump while holding down both left and right at the same time. Be careful that this isn't what's happening when you cannot jump.
Hope that helps!
@Azmodeus: The setImpulse idea is interesting. It would certainly make for more believable physics (as you wouldn't have to stop movement everywhere - makes for a more Mario-esque jumping style... I would assume). I'm going to give that a shot after I work through a few more things.
#11
1) There were several issues that have recently (within the past month) surfaced in-house that were caused by a 'fix' to clamp collision response circa 1.1.1 that caused sticking in surfaces. This is a *bug* and is being addressed accordingly. The short version of the story is that there were underlying issues with the code that was responsible for resolving overlaps and the modifications to clamp response brought those issues to light. If all goes well, fixes for these problems will be released with the next update.
2) There are certain things that can simply not be done without modifying the source. Stock TGB can only register one *collision send* per object per frame. For most types of games this is more than sufficient. Platformers happen to be one of those genres in which it is very easy to botch up your collision settings trying to get things to work right in stock TGB. Sonic-style physics are nearly impossible with stock TGB (possible, but not without lots and lots of dirty scripting). The physics in even the first sonic game were very specific. Player control is a 'by feel' type thing that no engine will ever come stock with. Those are the types of things that take the most tweaking and are the most fun to tweak (and consequently, the most rewarding to finally get just right). If you want to make a unique game, you will have to work at it. Generic platformer stuff works perfectly fine in TGB (physics response bugs aside) and achieving the more complex platformer functionality only requires mild source modifications for the most part. That's not to say that anyone was suggesting that TGB should come with gameplay mechanics built in - more so to say that TGB was not designed to target any specific genre and should not be seen as an 'all-purpose' 2D game engine but rather as a 'more-than-bare-bones' 2D game engine with some kickass tools that come with it. It is possible to make millions of cool games without modifying the source code, but it's important to note that the goal for TGB is not to make it work for every gameplay mechanic imaginable without requiring any modifications - that would be impossible.
3) Clamp response has no concept of 'at rest'. All clamp is supposed to care about is if an object is moving in the direction of the collision normal in the event of a collision. If it is, the proper response is to modify its velocity such that all movement into the surface is cancelled. That's why you'll see objects appear to slide down a slope when they have a downward constant force: the slope doesn't care whether the object is moving down, it only cares whether the object is moving directly into it's surface. The downward motion is not cancelled, only the motion that goes against the surface normal. Without modifying constant force when on slopes (meaning, setting the constant force to be directly into the slope), I don't know of a way to make slopes work in platformers with stock TGB. There may well be a way (and I've heard talk about there being a way), I just don't personally know it. The point was, angles in collision polygons should have nothing to do with clamp collision and the fact that they do is a bug (see #1).
4) I reccomend against using setImpulseForce for anything other than forces that would actually be considered impulses and thus calculated and applied as such. One general reason is that only one impulse force can be applied per scene update, but more importantly: jump should generally not be considered an impulse, as in most platformers the uniformity of the jump allows the player to learn how to navigate their environment (as in, learning how far or how high they can jump). An impulse force is not neccesarily always going to produce the same results given different starting velocities, which could potentially stunt the player's learning curve and make the gameplay experience unpredictable and ultimately frustrating.
5) TDN is a wiki. Everyone with access is allowed and encouraged to create and edit material. The Platformer MiniTutorial was not a GG submission - it was created and posted on TDN by a GG community member. As I understand it, the tutorial was not intended to be the end-all of correct platformer development using TGB, but rather just a quick-and-dirty way to get you a platformer environment that you can play with and later clean up and rewrite to fit your specific needs once you understand the underlying concepts of how a platformer functions. A lot of the issues that keep cropping up (wall-climbing, for example) are specific to this example and are not neccesarily 'platformer issues', but are still issues that are discussed fairly often and there are normally many ways to solve any design problem. What I'm getting at is that it would be nice to see some of these innovative sollutions to common problems go up on TDN so people in the community can benefit from each other's experiences. After all, it was put up for just that reason.
I hope this helped to shed some light on some of the issues you may have been having, and (maybe?) inspired some of you to take a more active role on TDN. ;)
Edit: I still can't spell. =(
10/11/2006 (12:36 am)
Just a few notes to clear some of the dust off this topic:1) There were several issues that have recently (within the past month) surfaced in-house that were caused by a 'fix' to clamp collision response circa 1.1.1 that caused sticking in surfaces. This is a *bug* and is being addressed accordingly. The short version of the story is that there were underlying issues with the code that was responsible for resolving overlaps and the modifications to clamp response brought those issues to light. If all goes well, fixes for these problems will be released with the next update.
2) There are certain things that can simply not be done without modifying the source. Stock TGB can only register one *collision send* per object per frame. For most types of games this is more than sufficient. Platformers happen to be one of those genres in which it is very easy to botch up your collision settings trying to get things to work right in stock TGB. Sonic-style physics are nearly impossible with stock TGB (possible, but not without lots and lots of dirty scripting). The physics in even the first sonic game were very specific. Player control is a 'by feel' type thing that no engine will ever come stock with. Those are the types of things that take the most tweaking and are the most fun to tweak (and consequently, the most rewarding to finally get just right). If you want to make a unique game, you will have to work at it. Generic platformer stuff works perfectly fine in TGB (physics response bugs aside) and achieving the more complex platformer functionality only requires mild source modifications for the most part. That's not to say that anyone was suggesting that TGB should come with gameplay mechanics built in - more so to say that TGB was not designed to target any specific genre and should not be seen as an 'all-purpose' 2D game engine but rather as a 'more-than-bare-bones' 2D game engine with some kickass tools that come with it. It is possible to make millions of cool games without modifying the source code, but it's important to note that the goal for TGB is not to make it work for every gameplay mechanic imaginable without requiring any modifications - that would be impossible.
3) Clamp response has no concept of 'at rest'. All clamp is supposed to care about is if an object is moving in the direction of the collision normal in the event of a collision. If it is, the proper response is to modify its velocity such that all movement into the surface is cancelled. That's why you'll see objects appear to slide down a slope when they have a downward constant force: the slope doesn't care whether the object is moving down, it only cares whether the object is moving directly into it's surface. The downward motion is not cancelled, only the motion that goes against the surface normal. Without modifying constant force when on slopes (meaning, setting the constant force to be directly into the slope), I don't know of a way to make slopes work in platformers with stock TGB. There may well be a way (and I've heard talk about there being a way), I just don't personally know it. The point was, angles in collision polygons should have nothing to do with clamp collision and the fact that they do is a bug (see #1).
4) I reccomend against using setImpulseForce for anything other than forces that would actually be considered impulses and thus calculated and applied as such. One general reason is that only one impulse force can be applied per scene update, but more importantly: jump should generally not be considered an impulse, as in most platformers the uniformity of the jump allows the player to learn how to navigate their environment (as in, learning how far or how high they can jump). An impulse force is not neccesarily always going to produce the same results given different starting velocities, which could potentially stunt the player's learning curve and make the gameplay experience unpredictable and ultimately frustrating.
5) TDN is a wiki. Everyone with access is allowed and encouraged to create and edit material. The Platformer MiniTutorial was not a GG submission - it was created and posted on TDN by a GG community member. As I understand it, the tutorial was not intended to be the end-all of correct platformer development using TGB, but rather just a quick-and-dirty way to get you a platformer environment that you can play with and later clean up and rewrite to fit your specific needs once you understand the underlying concepts of how a platformer functions. A lot of the issues that keep cropping up (wall-climbing, for example) are specific to this example and are not neccesarily 'platformer issues', but are still issues that are discussed fairly often and there are normally many ways to solve any design problem. What I'm getting at is that it would be nice to see some of these innovative sollutions to common problems go up on TDN so people in the community can benefit from each other's experiences. After all, it was put up for just that reason.
I hope this helped to shed some light on some of the issues you may have been having, and (maybe?) inspired some of you to take a more active role on TDN. ;)
Edit: I still can't spell. =(
#12
pGuy is still stuck from the top, I mean if he collide with a ciling pGuy will stuck.
I try to commet the line:
pGuy.setConstantForceY(0);
- so the force will stay 100 and it will bring him down, but thats did't work.
- I try to use the normal (%normal) in the onCollision function do define the top of pGuy and so if pGuy collide from the top the constant force should return to 100 and bring him back to ground, but also this didn't work.
any suggestion on how to bring a stcuked player back to the ground?
thanks in advance.
10/11/2006 (1:25 am)
Eric thanks your solution is greate everything is really greate but still there is one problem here:pGuy is still stuck from the top, I mean if he collide with a ciling pGuy will stuck.
I try to commet the line:
pGuy.setConstantForceY(0);
- so the force will stay 100 and it will bring him down, but thats did't work.
- I try to use the normal (%normal) in the onCollision function do define the top of pGuy and so if pGuy collide from the top the constant force should return to 100 and bring him back to ground, but also this didn't work.
any suggestion on how to bring a stcuked player back to the ground?
thanks in advance.
#13
10/11/2006 (1:28 am)
You might want to take another look at #1 in my post right above yours.
#14
will I'm asking here coz maybe someone (maybe you) may give me a (turn around) solution so that I don't stop my development till the next realse. do you agree with me?
10/11/2006 (1:36 am)
Thomas thanks for your quick replay, I think you are trying to tell me that I should wait tell the next release so this problem will be sloved right??will I'm asking here coz maybe someone (maybe you) may give me a (turn around) solution so that I don't stop my development till the next realse. do you agree with me?
#15
Re 3) That explains why holding left and right would result in a stuck player but direct collision would not. Cool. Knowing more about how CLAMP works really highlights the 'buginess' of the functionality. Knowing more about how CLAMP works also explains the wall-climbing issue...
Re 2) Particularly,
Re 4) Duly noted. Thanks for the advice (and info about only being able to call setImpulseForce() once per frame).
Re 1) Good to hear you guys are on-the-job! Can't wait for the fixes (whenever they come about!).
Re 5) I came up with a valid (in my opinion) fix for the wall climbing issue within the tutorial code. Incidentally I also made the code play nicely with ramps and pointy polygons. I posted [propose] the fixes here. I have edited the TDN article before, fixing spelling mistakes, etc. but figured that I should let the author himself make these more involved changes. Particularly since he's involved in the discussions.
A question for the employees: how receptive are you to pressing questions [even basic ones] regarding TGB functionality? I'd imagine you get kind of sick and tired of repeating yourselves...
I certainly don't feel like an authority on Collision just yet but I've noticed that several people have struggled with the same issues that I did. I've toyed with writing a WIki Entry about how to properly use "Collision Layers" but feel that I might get to a point where I muddle through some important piece and throw people off entirely. Is the idea that if I'm wrong someone will go in and edit it or...?
10/11/2006 (1:56 am)
@Thomas: Holy moly. Where to start? ;D Out of order!Re 3) That explains why holding left and right would result in a stuck player but direct collision would not. Cool. Knowing more about how CLAMP works really highlights the 'buginess' of the functionality. Knowing more about how CLAMP works also explains the wall-climbing issue...
Re 2) Particularly,
Quote:Stock TGB can only register one *collision send* per object per frame.Does that include calls using "%obj.castCollision(%time)" and the List version? Or is that some kind of special exception?
Re 4) Duly noted. Thanks for the advice (and info about only being able to call setImpulseForce() once per frame).
Re 1) Good to hear you guys are on-the-job! Can't wait for the fixes (whenever they come about!).
Re 5) I came up with a valid (in my opinion) fix for the wall climbing issue within the tutorial code. Incidentally I also made the code play nicely with ramps and pointy polygons. I posted [propose] the fixes here. I have edited the TDN article before, fixing spelling mistakes, etc. but figured that I should let the author himself make these more involved changes. Particularly since he's involved in the discussions.
A question for the employees: how receptive are you to pressing questions [even basic ones] regarding TGB functionality? I'd imagine you get kind of sick and tired of repeating yourselves...
I certainly don't feel like an authority on Collision just yet but I've noticed that several people have struggled with the same issues that I did. I've toyed with writing a WIki Entry about how to properly use "Collision Layers" but feel that I might get to a point where I muddle through some important piece and throw people off entirely. Is the idea that if I'm wrong someone will go in and edit it or...?
#16
@Thomas:
10/11/2006 (2:00 am)
THIS POST OFF TOPIC@Thomas:
Quote:Edit: I still can't spell. =(Heh, I know the feeling. I used to have Dictionary.app open all the time for spell checking while I wrote posts and what-not... now I just rely on the built in spell checker that comes with Firefox 2 (I'm on Firefox RC2 at the moment). It helps a ton.
#18
http://www.garagegames.com/mg/forums/result.thread.php?qt=50633
but stucking on the ciling when jump with left or right key pressed still there.
any other suggestion?
10/11/2006 (3:05 am)
Yes eric I test the code in this thread:http://www.garagegames.com/mg/forums/result.thread.php?qt=50633
but stucking on the ciling when jump with left or right key pressed still there.
any other suggestion?
#19
@Eric - CastCollision doesn't count as a 'collision' (note that it doesn't give you a callback or trigger a response), so you're good on that front. SetImpulseForce can be used more than once per frame, but only the last impulse force tha was set will be used.
As for TDN, I agree that the original author of an article should be kept in the loop if at all possible and I love to see people really getting into the discussions about this stuff. Generally you guys are going about it the right way, I really only mentioned TDN to kinda remind everyone that its up there and to not be afraid to use it. The idea is that if someone posts something that's confusing or incorrect, someone else will notice and fix it. If you're ever unsure if something is confusing, you could link to it here on the forums and ask people to proofread it for you.
I'm pretty receptive to questions about functionality. I generally answer questions unless i dont know the answer or it has been answered very recently and its obvious the person asking the question didn't look around first (or I just cant understand the question). I think it's especially important now that questions be answered because TGB is so new and there is nowhere else for people to find the answers to some of their questions. As for repeating myself, I tend to do that a lot and generally don't like to. Sometimes I find myself linking to other threads where someone has already answered the question, but I feel like that can seem a little impersonal so sometimes I just wait to see what sollutions people come up with and just try to steer them in the right direction. I do read the forums every day, though, and I try to help when I can.
10/11/2006 (2:11 pm)
@Firas - I'm not suggesting that you hold off on developing your game until next release. I was only suggesting that you focus on other areas of your game istead of not wasting time trying to work around an issue that will be resolved soon. I would hate to see anyone fall off their development schedule due to a bug in the engine. @Eric - CastCollision doesn't count as a 'collision' (note that it doesn't give you a callback or trigger a response), so you're good on that front. SetImpulseForce can be used more than once per frame, but only the last impulse force tha was set will be used.
As for TDN, I agree that the original author of an article should be kept in the loop if at all possible and I love to see people really getting into the discussions about this stuff. Generally you guys are going about it the right way, I really only mentioned TDN to kinda remind everyone that its up there and to not be afraid to use it. The idea is that if someone posts something that's confusing or incorrect, someone else will notice and fix it. If you're ever unsure if something is confusing, you could link to it here on the forums and ask people to proofread it for you.
I'm pretty receptive to questions about functionality. I generally answer questions unless i dont know the answer or it has been answered very recently and its obvious the person asking the question didn't look around first (or I just cant understand the question). I think it's especially important now that questions be answered because TGB is so new and there is nowhere else for people to find the answers to some of their questions. As for repeating myself, I tend to do that a lot and generally don't like to. Sometimes I find myself linking to other threads where someone has already answered the question, but I feel like that can seem a little impersonal so sometimes I just wait to see what sollutions people come up with and just try to steer them in the right direction. I do read the forums every day, though, and I try to help when I can.
#20
@Everyone - Hey guys, you are doing a great community here. Keep working!.
10/11/2006 (3:34 pm)
@Thomas - So this is a bug in the engine that will be fixed soon? is there a schedule date for a new TGB release? Don't want to spent my time as newbie trying to fix something that's beyond my capabilities :)@Everyone - Hey guys, you are doing a great community here. Keep working!.
Torque Owner Oliver Rendelmann - DerR