fox-flux:

incredibly stupid physics problems

ALT

(crossposting from cohost)

i posted this in the secret fox flux $4 discord channel last night and it reveals A Problem

i mean, a problem besides the barrel’s layering being kind of dubious

the pistons stop trying to extend as soon as they’re blocked. and here, you may notice, the one extending left pushes the slime a little bit before giving up. this turns out to be caused by a combination of:

• the piston is “moving”, but it’s not using the normal motion machinery (obviously), so it doesn’t actually have any velocity.
• when object A tries to push object B, if it determines that object B is moving away from it faster than A is moving, it doesn’t bother. i don’t remember what specific problem this was meant to solve, but it does make intuitive sense — if i’m pushing a boulder down a hill then it’s just going to roll away from me and i am going to accomplish nothing. if i let the push happen, i’d make B move even faster (however briefly) which is silly.

as long as the slime is walking towards the piston, everything is fine. but the slime immediately notices it’s blocked on one side, turns around, and starts walking the other way. now the slime has a leftwards velocity, but the piston has zero velocity, so the piston thinks the slime is speeding away from it. but that isn’t happening, and the slime is still there, so the piston thinks it’s now blocked and stops extending.

love it. chef kiss. pushing objects is the hardest thing in the world. anyway i guess i can think of two potential solutions here

① delete the special case for a pushee moving away. checking velocity in the middle of the (hairy) push code is already kind of weird, and it’s only done for this specific case. it also shouldn’t matter; even if we push something slightly this frame, if it really is moving away from us, then it should be beyond our reach next frame anyway.

i suspect this is a leftover from an older and vastly more complicated iteration of the push code that tried to conserve momentum and whatnot — in which case, doing this even for a single frame would have made A and B look like a single unit, combined their momentum, and given both the same velocity, which means B slows down. so that’s bad. but that was an endless nightmare of increasingly obscure interactions so i eventually gave up and scrapped it all. the current implementation won’t let you simulate newton’s cradle, i guess, but that’s not the kind of game this is so whatever?

on the other hand, if i’m wrong and this is still important in some exceptionally obscure case, it would be bad to remove it! exciting.

(if you’re curious: what i do now is give lexy — or other push-capable actors — a maximum push mass, and then when she tries to push something, i scale her movement down proportional to how much she’s pushing. for example, rubber lexy’s push capacity is 8, and a wooden crate weighs 4, so she moves at half speed when pushing one crate and at zero speed when pushing two. i think if a sliding crate hits another one now, they’ll both just move at the first one’s original speed, but friction skids everything to a halt fast enough that it mostly doesn’t come up.)

② give the piston a fake velocity to fool the check. i might want to do this anyway for stuff like climbing, where the player is moving but is considered to have zero velocity because it’s being done manually. but lying like this feels like it’ll come back to bite me somewhere down the line.

anyway this is just the sort of thing i bumble into occasionally. hope it’s interesting. i should probably go try to fix it now