United StatesThank you to everyone who contributed in my previous forum post.
In my new record for the Old version category I incorporated the upwards ceiling phase through in level 3, through practice attempts I have found that it is incredibly consistent to phase upwards through the ceiling.
I did my best to explain how you can consistently recreate the ceiling phase (which I will be referring to as 'noid strat' from now on to less redundant) in my last forum post, I feel like I did a pretty good job as to why it happens and a theoretical way to reproduce it (finding the perfect time to hit noid strat as scratch 'yields' to the code that allows the bug) but I didn't share a noid strat time. Here are my current findings
As you can see I hit noid strat on level three (attempt starts at 4.8s), I used YouTube Frame Timer to find out the exact time the player sprite phases through the ceiling from the first frame that the start flag is clicked to the frame the sprite starts to phase through the ceiling. 8.267s (CORRECTION: 6.533s). Scratch takes 1/30th of a second to refresh the screen (and im assuming to yield), thats 33.33ms of leeway to get noid strat. 33.33ms is 1 frame. If I'm correct we have the first frame perfect trick in jetpack.
Well the answer to getting the collision right is simple
Do a set of actions that will get the exact time of the right scratch yield.
If the steps easy to do multiple times and save the most time its consistent.
My only thought on that is that changing directions right before touching the ceiling adds the tiniest of time for scratch to yield to the right bit of code, it's very much possible to create an external program to show the exact time it would take to get the right scratch yield, I'll see what I can do in making level 3 more consistent, maybe if we get the consistency down we can find more time saves in the other rooms (related to collision).
I just realized I didn't do a great job on explaining why i think yielding causes it to be inconsistent, its most likely controlled by the time you take to go through rooms 1-3 and then when you touch the line in room 3, im guessing because of the large size of the collision script in jetpack, scratch cycles through each <if ____ then> block, so theres certain times where you can phase upwards and when you cant phase upwards
I took a look at the code for the game, here's what I came up with
Basically a part of the collision code says if the players outline (black) touches a black line, move up by 2, then it says if the players outline touches a brown line, move down by 2. I think the black line code prevents the player from going through the ground (which in most of the levels are black). As for the brown lines I'm assuming that the color brown is used for ceilings.
In room 3 its quite noticeable that the first line is split into a thicker brown line and a thin black line on top, brown for the lower section of the area, and the black thin line for ground the player can land on when getting to the middle section.
I'm still not exactly sure what causes a non-black color of the sprite to touch the but it might have something to do with the sprites orientation and y speed (how fast the player sprite moves upwards).
I drew a crude diagram on what I think is going on
While typing this out I think I might have found out why its so inconsistent, heres a quote from the scratch forums by user nXIII, "...after each iteration of a control structure (like <forever> or <repeat ()>) Scratch stops executing the current script and goes on to the next one (this is called yielding)..."
Room 3 seems to have some buggy collision that isnt consistent with when it happens. Any thoughts on why and how it can become consistent?
You won't know when or what day, but i will randomly improve this record.
Bro spent 1.805% of his legally allowed gaming time per week on a baldis basics speedrun, i feel you
Will add some funny categories in a category extensions page if these are too hard for you :/
reach the book room after jumping on the pillars
