The 1 cycle gravity switch (9.5 sec time save) - by Parhelion
5 years ago

Part 1: the 1 cycle gravity swtich strat (using a RMJ box boost) Part 2: the comparison between 1 and 2 cycles strats Part 3: the risk of getting a dangle grab -,-

it's worth going for the skip, because there's just enough time to go for 2 cycles if you don't get the huge box boost to the right ...

itsme_baruch likes this

FYI, just getting the box boost is not enough to get the 1 cycle (obviously :P ) ... but it's really important you tighten up the entire movement ... especially in such a small section (between switch and saw) ... so here are a few things to consider when attempting this skip:

  • the first jump is a tiny jump (tap the jump button), and it's exactly from the ledge, as late as possible (unlike the normal strat)
  • you have to stop in midair, so you fall next to the switch on the left side
  • "hit" the switch as early as possible (at the top-left of the panel), so you spend less time in the air
  • when you land on the ceiling, turn to the box instantly, already holding the grab button
  • grabbing and dragging the box is difficult ... this is a crucial point in the strat, needs practice so you can manage most outcomes (for ex, if the box flips, or if the boy lets go of the box, you have to react fast without losing time)
  • do not drag the box too far right (this part is when you're the slowest, so the less time you spend dragging the box = the better)
  • it's important to know that if you fail the box boost, you can still do a 2 cycle strat (when practicing the skip, don't give up immediately, try to go for the 2 cycles as a backup)
  • if you get the right ledge grab, it's important not to insta jump out of that climb (because you have to do a very precise jump just before the automatic gravity switch)
  • after the climb up, there's very little time to waste ... so, simply run right and try to time 1 jump just before the automatic gravity switch, so you stall in midair as the the gravity switches down, so you clear the saw using the momentum foward, flying over it) ... (in the video you can see I messed up the timing for the last jump, and I touched the ceiling again, without stalling in midair ... good thing I got a belly landing on the ledge, so I was already far enough to clear the saw reagardless)

...

Edited by the author 5 years ago

here's a 16min training session ... getting 10 successful skips ... from 28 box boost commitments that cannot be saved with a 2 cycle backup ... in 49 attempts (actual chapter loadings) :

as I was working on this 1 cycle gravity, I had a bit of a revelation about how it works (I mean, getting the good box boost) ... and I think it has something to do with what Zet and Raining were saying back in the day ... they each had a theory on different parts of the box boost, so both theories can work together

Zet had a strat which involved moving the stick slightly up when doing the box boost, not just going from left to right in one instant motion ... this gave me an idea, I incorporated this sort of sequence into my keyboard strat : as I'm running left on the box, I release the left button before pressing jump, then the right button is the last one to be pressed ... so on keyboard it's a sort of simulation of Zet's motion ... release left, press jump (and hold), then press right (and hold) ... hope you know what I mean ... so this is what I do at gravbox, trying to mimic that motion in a perfect succession (the interval between those inputs as equal as poss, so since it's a sequence of inputs, so I started calling it a "sequential" box boost)

but anyway, now Raining: he always made sure to emphasize the moment WHEN you do the RMJ ... not gonna go through his explanation, just know that the actual moment/timing of the RMJ as you run over that corner of the box is important ... and I think it's because the game wants to save limboy from falling over any ledge if you stop just a bit after that ledge, so the game kinda readjusts your position back safely onto the ledge ... (that's just a speculation) but I think this is where that pause after releasing left input comes into play ... at least this is my latest theory, and it works with much greater success than other techniques I've tried

I asked Lightdrew to test this theory on controller, timing the jump in the middle of the transition of the stick from left to right, without going instantly from left to right (leaving a bit of room for that pause before jumping) and he said it's looking promising ... it takes a bit of time to readjust your muscle memory for this new movement, but we're early in the experiments, so let's see how it works out later on

About the tree skip box boost, I tried it with this new technique, but for some reason I didn't get good results ... not on the left side drag (the normal first approach) ... but it works surprisingly well if you drag the box from the right ... as you can see in this video :

Edited by the author 5 years ago
v_input_output likes this

I don't know if anyone cares about this sort of stuff or not but here are some odd experiment results I've made: I used AutoHotkey to record a successful tree skip into a replayable macro script, but replaying the script didn't produce consistent results. The character only performed a successful skip 6 out of 20 times. Suspecting that AutoHotkey may be a little too slow for the high percision execution, I've written a logger that logged the timestamps of when input is being sent.

By default Limbo outputs 60 fps hard-locked by the vsync. If the rendering and the internal game logic are in sync, you have a window of 16.(6) milliseconds to send your input. The measured deviation of AutoHotkey on my machine was a range of 0.002 to 0.00009 milliseconds so in the worst possible case input was delayed by two microseconds. That figure is way too small to possibly cause such drastic inconsistency so something else must be wrong.

I'm not sure what is up with Limbo but it seems that anything that involves physics adds arbitrary randomness. Very very small bits of randomness that aren't immediately apparent. Like pushing and pulling objects doesn't result in them being in the exact spots every time. Often this isn't a problem for humans because we adjust out actions based on what we see and if the adjustment is as small as a fraction of a second we may not recognize that we even did it but input scripts fail if 100% determinism is not guaranteed.

I'm not very experienced with these sorts of things but I'd like to throw it out there that there may be an undefined behaviour somwhere in the physics code of Limbo that introduces these inconsistencies. In that case there can be no guarantee that the same input results in performing a tree skip from one attempt to another.