TGB 1.7.3 beta 1 Bug? - sticky walls

#1 Hi,

Could you provide some useful information about this "very sticky" issue as I'm not able to do anything from the description above. Could you for instance tell me what the code is doing (collision modes, that kind of stuff) or preferably provide me with the code so that I can see if I can duplicate the problem? As simple an example as possible is best.

I saw many examples of things "working" in v1.7.2 and not working in v1.7.3 and I expect to see lots more. This is simply because (and for good reason) lots of code does naughty things to counter-act the problematic physics prior to v1.7.3.

Maybe this is the problem, maybe not but if I can get something in front of me I can fix it.

Melv.

#2 Melv and Jydog,

When you press and hold down the Left/Right key it will process this in the onUpdate function of the Actor behavior. The process checks to see which direction the actor should move in and then updates it's velocity accordingly. This process is iterated every frame to handle acceleration and deceleration.

Note: While in the air, a y-axis linear velocity (not constant force) is applied to the actor to force it towards the ground.

In 1.7.2 when you jumped up and ran into a wall it would just allow you to fall down towards the ground, but in 1.7.3 you are now getting stuck.

When you collide with a wall, it will clear the move speed of the actor. Despite this, the onUpdate function is called again and it will attempt to move the actor in the specified direction. From the tests that I have done, if you let go of the key telling the actor to move left/right, then you will fall to the ground as normal.

From what I can gather from this case is that the clamp response is ignoring the fact that there is a y-axis velocity applied to the actor.

#3 Please forgive my ignorance but is this some kind of example in the PSK? Unfortunately I don't have access to that right now so again could one of you guys please supply me with the code that demonstrates this? Again, could someone supply me with some useful details such as collision-mode, collision send/receive for the objects involved, the object types etc.

During development I tested 4 different platformers with all collision responses, some using tile-maps and some built from static scene objects.

I'm absolutely amazed that you're getting something as basic as a clamp-response problem, really amazed. I tested all the responses quite extensively and I never got a single case of interpenetration on any machine. I'll kick myself if I let something silly slip through!

Anyway, could someone please get something in front of me so I can see what's causing it?

In the meantime I'll setup another test with the presumed settings.

Thanks for the feedback!

Melv.

#4 Can I just check that this interaction doesn't involve the "t2dTrigger" object does it?

You will find that in the v1.7.3 b1 that t2dtriggers don't have an "onCollision" callback. There were two changes made to this object.

The first was to change its use of straight lists of objects into object dictionaries which made the determination of objects that stay and leave really quick.

The second was that the object used its own "castCollisionList" internal call to quickly determine occupancy. This was much faster than just setting the objects collision active and allowing objects to collide with it. Also, it meant that objects didn't see collisions with it which has proven to be problematic in some cases. Unfortunately, the other day an example came up where the "onCollision" was being used on this object rather than the "OnEnter". In this case the normal was seemingly important so it meant that the new t2dtrigger was "broken" in face of that code.

So what I did was revert the use of "castCollisionList" back to the standard internal collision so that its behaviour is now identical to before but with the problem associated with having the object receive collisions. It is still much, much faster than it was, particular when lots of objects are involved.

Coincidentally, this example I mentioned above was using the PSK although I'd highlight that the problem is with this change in the t2dTrigger and not the PSK in any way.

That change is now in the repo.

Melv.

#5 Melv, if you thow me an email I will hook you up with the PSK to get a better understanding of what is happening.

Regarding t2dTriggers, I have only used them in a few areas, one of them being the AreaDamageBehavior. I don't think that the trigger changes have affected the PSK in any form.

In the meantime here is a brief rundown of how it is set up.

function ActorBehavior::onAddToScene(%this)
{
	...
 
	// Set up some of the basics we need down the track
	%this.Owner.setCollisionActive(1,1);
	%this.Owner.setCollisionPhysics(1,0);
	%this.Owner.setCollisionCallback(1);
	%this.Owner.enableUpdateCallback();
 
	...
}
 
function ActorBehavior::onUpdate(%this)
{
	...
 
	%this.updatePhysics();
 
	...
}
 
function ActorBehavior::updatePhysics(%this)
{
	...
 
	// Check to see if we should move or not
	if (%this.Owner.Controller.Direction.X != 0)
	{
		// Increase our speed in the direction we are trying to go
		%this.MoveSpeed.X += %this.Owner.Controller.Direction.X * %MoveAccel;
	}
	else
	{
		// Since we're not trying to go anywhere, slow our speed down
		%dir = -1 + 2 * (%this.MoveSpeed.X > 0);
 
		if (mAbs(%this.MoveSpeed.X) > mAbs(%MoveDecel))
			%this.MoveSpeed.X -= %dir * %MoveDecel;
		else
			%this.MoveSpeed.X = 0;
	}

	// Ensure we dont move too quickly
	%this.MoveSpeed.X = mClamp(%this.MoveSpeed.X, -%this.MaxMoveSpeed, %this.MaxMoveSpeed);
 
	%this.Owner.setLinearVelocity(%this.MoveSpeed);
 
	...
}
 
function ActorBehavior::onCollision(%ourObject, %theirObject, %ourRef, %theirRef, %time, %normal, %contacts, %points)
{
	// Was it a ground surface?
	%groundSurface = (%normal.Y < %ourObject.MaxGroundNormalY);
	
	// If it isn't, then it must be a wall!
	if (!%groundSurface && mAbs(%normal.X) > 0)
		%ourObject.MoveSpeed.X = 0;
}

#6 ... also, make sure that if you're changing the default for collision iterations that you don't use "1".

The default changed to "3" and for good reason. Given a very simple setup you can get away with one but in most real examples that have multiple component X/Y velocities that can involve corners you'll need a few iterations.

For simple responses such as "clamp", the default should suffice but there's little harm bumping it up by one. It costs to do an iteration but for a single object you wouldn't probably notice if you bumped it up to 30 although it'd probably be a waste.

For rigid-body I'd recommend at least 10.

Because forces act in different directions simultaneously you need to ensure that the object has the chance to utilise its time as each iteration involves checking for the move, possibly finding a collision, moving to the collision point, doing the collision response and doing another iteration. This continues until the tick-time allocated to it has been spent (in terms of move-time) or the iteration limit has been reached.

It may not be this but until I can get my hot hands on the code I'm kinda guessing. :)

Cheers,

Melv.

#7 Philip,

I've got to pop out shortly but I'll be back in an hour. I'll send you an email soon.

In the meantime though, are you doing your own collision-response then? So this problem isn't anything to do with the stock collision response? I presume the object has its response off for send/receive?

Got to dash, be back very soon.

Melv.

#8 Email sent to the one in your profile!

Melv.

#9 Melv,

I don't want to give out too many trade secrets on the open forum, but I am using TGB's collision response. Provided nothing has changed in the default response from .2 to .3, it should be using CLAMP.

It is probably more of an issue to do with the implementation of the PSK and not of the new physics.

We can talk more via email.

Phil

#10 @jydog:

Just to let you know that I'm working on this issue right now and I'll get back as soon as it's resolved.

Melv.

#11 Got a copy of the PSK from Philip today and checked-out the problem. As I suspected it seems that the collisions iteration setting is "1" rather than the default "3" so I looked in the PSK and found that it wasn't changing it from the default which confused me until I realised that although I changed the default to "3", I didn't change the default datablock to "3" and it was still "1".

I've changed this in the repo but to hopefully solve your issue, please set the object in question to use "3" collision iterations explicitly. As far as the player-class is involved I believe you can add the following code in "playerMethods.cs":

function PlayerClass::onAddToScene(%this, %scenegraph)
{
...
   %this.setCollisionMaxIterations( 3 );
...
}

This immediately resolved the problem.

I have double-checked the internal physics and everything seems to be in order so it's a case of bad defaults in the "t2dSceneObjectDatablock". You won't be required to make this change in the PSK in the next release of the TGB beta.


In case you're interested, the detail of why this is happening is that with collision-max iterations of "1" being used and when an object collides with another object with the "clamp" response, the response is calculated and the velocity is clamped correctly. If only a single collision iteration is used, that's it for the object. If the scripts reassert the clamped velocity, come next collision check the object will collide at zero-time and the velocity is clamped again followed by the scripts reasserting the velocity ad-infinitum

An object left alone with collision iteration of "1" would work perfectly but if you're reasserting the velocity you need to understand that the object will find an immediately collision (it's against a wall and it's velocity is trying to move it into the wall). Because of the physics fixes you no longer get any interpenetration into the wall. If you had another iteration then the object would check up/down the wall and move appropriately. In this case you could use "2" iterations only but it's always safer to use "3" for corners etc. That's why it's the new default.

The bug-tracker for this problem is "TGB-78" and the repo-reference is "[16x\#8917]".

Thanks for the report.

Melv.

#12 Awesomeness, cheers Melv!

#13 Thanks for the work. Will be looking at it.

#14 Could you guys confirm that the change outlined above fixes your issue so I can close "TGB-78"?

Melv.

#15 I will have to rely on Phil to give it a clean bill of health.

#16 Could you not enter the single line of script above and see if it works? I am making an assumption that it's the same problem on your machine so I want to be safe.

Melv.

#17 ?????

Melv.

#18 Jydog, Melv is an authorative expert with this stuff, you don't need my okay to know that it is working.

#19 Of course he is : )

What I meant is; as my coding skills lack much and I figured you two have a good handle on it, you would check it out adequately.

I might try to load .3b1 back up and see if I see anything. I dumped it as it had some issues.

> ?????

Sorry Melv. That was one of those silly refresh double posts. Not a "YOU HEARD ME THE FIRST TIME!!!" : )

#20 So when you added "%this.setCollisionMaxIterations( 3 );" did it solve your problem so I can close the bug report down?

Melv.