Half-ticks and physics collisions

[pickleplayer]

I've been re-working the hitbox system for Smashup because the rest of the base game is basically done (and looking pretty good) but I've been running into some... weird problems.

 

Okay, so this game runs at 30 fps, right? So code runs at every tick(or frame), and nothing in between, right?

Well, after a LOT of experimenting, I've started to notice that some code is actually running in between ticks. I’m not crazy I swear! I have proof! I made a button that moves the game forward 1 tick, as well as the debug keys "[" and "]" which slow down and speed up time. Pressing the backspace key lets you see what tick the game is currently on.

So during testing, I would activate an attack and freeze the game time, going forward one tick at a time. On the tick that the hitbox comes out on, nothing happens at first. But if I QUICKLY tap "]" and then "[" (which quickly un-pauses and then re-pauses the game again), more print messages from the hitbox show up, EVEN THOUGH the "Sim Tick:" number in the corner has not changed. I've been testing for a while and I'm positive that code is being executed at intervals in-between 30 fps. But it's very inconsistent. Sometimes attacks will even register during these half-ticks. (which is actually what I'm trying to make happen, but it usually doesn't work)

I think it has something to do with the games physics, because most of the code involved in the half ticks are from PhysicsCollisionCallbacks. The reason this has been giving me so much trouble is because physics collisions with multiple objects at once can't return a table of all objects it's touching. It just runs it's collision script based on whatever object it "collides with first". and since most cases involve it being teleported onto multiple objects at once, the "first" object it registers seems to be totally random. The whole clanking system relies on a hitboxes ability to tell if it's touching another hitbox before running it's code on hurtboxes.

I wanted to have a timer that updates the hitboxes collision script after every tick, after a table of all colliding items had been neatly sorted out for it. But now I can't do that because collisions seem to register BETWEEN ticks, so there won't be anything in that table until after the timers already run.

My original idea of getting around this problem was to have the hitbox’s CollisionCallback scripts just add the touching objects to a table, and then have a separate “master hitbox updater” that registers the attack after all the hitbox objects touching it have been added to the table. But the real question is, how can I get the master hitbox updater to run AFTER all the connecting objects have been added to the table? How will it know when everything is done being added?

I would have liked to just set up a timer that runs the attack checker every tick, but I can’t, because collisions usually register on HALF ticks, so the attack won’t register anything until the next frame starts.

The process happens in the order: Hitbox spawns – wait for all touching objects to register themselves in the table via PhysicsCollisionCallbacks – run the master hitbox updater and determine of any of those objects in the table are other hitboxes and then apply the attack.

And I need everything to happen in that order before the next tick starts. Since the second step usually takes 0.5 frames to register, the third step needs to happen directly after it, or else the attack wont register until the next frame.

Oh god it sounds like I’m getting into Mario 64 half-A presses.

 

I’m not exactly sure what I’m expecting by asking for help here, but maybe there are some people that know more about tables or tick updates or PhysicsCollisonCallbacks than I do that can help.

If not, I’ll just have to make hitboxes have a 1 frame delay. Oh well.

[Mobbstar]

Isn't this what components do in their wall update functions? The number value "dt" gets tested in a few of them, because "too large intervals break the maths". This means "dt" is not a fixed tick time, suggesting the fundamental code runs at whatever pace it can (staying somewhat gentle to the CPU and RAM and stuff of course).

EDIT: I'm afraid I can't help you much more than that, or at least not without wasting lots of my time on catching up. Maybe you can summon some devs to help you out more?

Edited January 27, 2016 by Mobbstar

[Arkathorn]

16 minutes ago, Mobbstar said:

This means "dt" is not a fixed tick time, suggesting the fundamental code runs at whatever pace it can

I'm pretty sure 'dt' is a measure of seconds passed. It also may be that this is just a more convenient format than ticks for developers to use.

 

You could just make your own collision code, and bypass the physics engine entirely. AABBs aren't that complicated.

[Mobbstar]

4 minutes ago, Arkathorn said:

I'm pretty sure 'dt' is a measure of seconds passed. It also may be that this is just a more convenient format than ticks for developers to use.

 

You could just make your own collision code, and bypass the physics engine entirely. AABBs aren't that complicated.

It's not seconds, not always. Sometimes it's smaller than that, but I can't remember an example

[Arkathorn]

2 hours ago, Mobbstar said:

Sometimes it's smaller than that

'dt' is almost always a decimal, but I believe that it is a measure of a fraction of a second.

[pickleplayer]

6 hours ago, Mobbstar said:

Isn't this what components do in their wall update functions? The number value "dt" gets tested in a few of them, because "too large intervals break the maths". This means "dt" is not a fixed tick time, suggesting the fundamental code runs at whatever pace it can (staying somewhat gentle to the CPU and RAM and stuff of course).

EDIT: I'm afraid I can't help you much more than that, or at least not without wasting lots of my time on catching up. Maybe you can summon some devs to help you out more?

 

Hmm, wall updates? I remember seeing stuff about them before, but I didn't really look much into it. I always assumed it was like regular updates, except they would run even when the game is paused.

I'll take a look into it, although now that you mention it, I'm also having a hard time remembering where they were actually used in game. I looked around and all I found was a thing in "uianim", but I'm still testing it out.

[pickleplayer]

6 hours ago, Arkathorn said:

I'm pretty sure 'dt' is a measure of seconds passed. It also may be that this is just a more convenient format than ticks for developers to use.

 

You could just make your own collision code, and bypass the physics engine entirely. AABBs aren't that complicated.

 

That's pretty much what the old hitbox system was. But it was old and had so many tiny weird bugs. This new one fixes almost all of them, makes much more sense, can hit multiple enemies at once, and can use both spheres and CYLINDERS boxes to define them.

[pickleplayer]

Oh. Wow I think that fixed it.

There was some 3 line function underneath WallUpdater called PostUpdate. And that just sounded like exactly what I needed, so I threw the Master hitbox updater in there and now everything suddenly works. Wow, I can't believe how quick it was too.

I'll probably change it a bit later so it doesn't run every tick, but I guess everything's good for now.

Time to add some more characters

[Mobbstar]

11 hours ago, pickleplayer said:

can use both spheres and CYLINDERS boxes to define them

Oh, tricky!

9 hours ago, pickleplayer said:

Oh. Wow I think that fixed it.

I did a thing! Yeay!