IRF

"A Rope in the Sky? Impossible!!!" (00) - I like the fact that there's a clue in the room name. It should lead the inquisitive player to discover the secret route. 😉

One of my games does this, courtesy of a joke at the expense of my brother's then seemingly limitless appetite and a misremembered sketch from "The Young Ones". It's only three rooms though.

I seem to think there's a couple of games if not more that actually set this on/off per room. I'd have to have a look or think about it. Not 'Dynamite Dan' trampoline style, but more "you can land on this from a great height"

I think there are various such safe drops through more than one room in various games, but, off the top of my head, I wouldn't dare say which one is the longest one of them all.
In Sendy's and mine "JSW: Mind Control" there are two such drops.
One, which I'm particularly proud of (for various reasons), is when you jump into a void between the clouds on the left in "A Rope in the Sky? Impossible!!!" (004), find yourself in free fall in "A Glimpse of 'JSWL 2005' Megamix' (060) and land safely on a tiny rope at the top of "The Most Secret of All Places". This drop is also a secret route, as it would be hard to expect from a reasonable (and uninquisitive) player to jump off the rope in  "A Rope in the Sky? Impossible!!!".
The other one starts in "Promoter of Foolishness" (019), my remake of "advocate of stupidity" (019) from Sendy's game "where's woody?". Willy falls down through "Foolish, wasn't it?" (014), "But Willy'll be lucky, will he?" (012) and ends up safely on the rope in "Yes! Willy's a lucky bastard!!!" (098).
There may be some safe long drops also in the games that use the fall-without-dying POKE as a constant feature. I can't think of any specific ones right now, but I'm sure you could find some in these games.

Danny, does this ring a bell with you? I seem to recall a game with an improbably long drop, where a rope saves the day several rooms down from the start of the fall. Can't recall which game though. One of Richard Hallas's maybe? 

Ah yes, it's all coming back to me now. And if Willy jumps into 'Pool Party' from the top right (out of the 'East Wing'), he is saved from a fatal drop by the springy 'diving board'! 

I did recently read up on the changes between Mini and Mini SE although they were mostly confined to small tweaks and bug fixes iirc. 🙂

Ah yes, it's all coming back to me now. And if Willy jumps into 'Pool Party' from the top right (out of the 'East Wing'), he is saved from a fatal drop by the springy 'diving board'! 

@IRFIt was indeed Jet Set Mini , you can safely fall from most of the Orangery to the Swimming Pool (apart from extreme edges) and the rope will catch him.
Spoiler contains animated .gifs of a left and right hand fall. Screenflash in effect in Swimming Pool.

Danny, does this ring a bell with you? I seem to recall a game with an improbably long drop, where a rope saves the day several rooms down from the start of the fall. Can't recall which game though. One of Richard Hallas's maybe? 

If I recall correctly, the Swimming Pool in Jet Set Mini has a Room Setup Patch which changes the initial swing direction of the rope, depending on which side of the room Willy enters. The net result is that the rope will always catch Willy whenever he drops from above, whether he is left or right of the top segment of rope. 

If I recall correctly, the Swimming Pool in Jet Set Mini has a Room Setup Patch which changes the initial swing direction of the rope, depending on which side of the room Willy enters. The net result is that the rope will always catch Willy whenever he drops from above, whether he is left or right of the top segment of rope. 

FALL_TEST.TAP
Note this file only has a few basic rooms and the cell colours are not always set properly. There's not meant to be any exit left/right its only a 5 minute 'build' demonstration. 🙂 Willy can pass through earth cells but I did not really pay a lot of attention to the ropes, other than trying an invisible (black/black) one! Exits may or may not be valid, I recall I forgot to set 'same room' for one of them. Basic premise simply catch him either way in a different part of a game...
EDIT... The game 'core' was altered a bit as I used a starting base project to do this, so there's no clock / central display of lives etc. Not the best 'base file' to use but it serves the purpose here well enough.

Now that is something useful! Provided Willy falls near enough to be caught. Indeed this gives me a new thought @IRF
Lets say he falls 3 or 4 rooms down and on room 5 the rope is swinging left and he catches is provided he fell near enough it allowing him a passage safely to the left of that screen (think like Back stairway layout for half the screen)
... but ...
if he misses is then he falls a couple more screens and is caught by a rope swinging rightwards this time. Although he is now in a different area. Possibly only accessible via this method unless a tortuous route is followed.
Your wish is my command 😉 (I did make the guardians a bit harmless to save time!) To match the others I've again used the Amstrad version. It plays just as nicely in obviously a different palette:
 
I've seen that happen a few times yes! 😄

What about the record for the longest fall which seems like it's going to be fatal, but in the room at the bottom Willy encounters a rope which saves the day!? 

If that's the case, then shouldn't you have included a screenshot of Down t'Pit (the start of that fall) to show that it is in fact a bigger drop (in terms of number of rooms) than the drop from On Top of the House? 🤨

Fun fact: if Willy drops down onto a rope from the room above (eg. Orangery to Swimming Pool), and then you use WRITETYPER to teleport him to another room, then sometimes* in the teleport destination room, he can end up dropping a 'safe' distance onto a platform only a couple of rows below but still be killed (because the falling counter variable isn't actually reset to zero by the process of being caught by a rope).
(*At other times, Willy ends up 'out of alignment' with the character rows, causing further odd things to happen!) 

Fun fact: if Willy drops down onto a rope from the room above (eg. Orangery to Swimming Pool), and then you use WRITETYPER to teleport him to another room, then sometimes* in the teleport destination room, he can end up dropping a 'safe' distance onto a platform only a couple of rows below but still be killed (because the falling counter variable isn't actually reset to zero by the process of being caught by a rope).
(*At other times, Willy ends up 'out of alignment' with the character rows, causing further odd things to happen!) 

Norman's latest code makes it easy to switch between the two 'rope modes' (key function switch when rope turn round versus when rope passes through the vertical) - to revert the code as listed above back to the original setup (retaining the 6 byte saving), you only need to edit two bytes: change the offset byte of the XOR from 01 to 00, and then swap the JR Z, skip_0 to a JR NZ, skip_0
****
Random fact: when Willy jumps off or falls off the end of a rope, a counter is set that means he cannot get back onto the rope for 16 time-frames of the game. (Presumably intended to prevent him from getting unintentionally tangled back onto the rope immediately after dismounting.) But in a room in a modified game that has two ropes (even with the Adjacent Ropes patch implemented), this 'cooling off period' only lasts for 8 game 'ticks'; with four ropes in the same room it will only be four 'ticks' after dismounting before he can get back onto a rope; etc. 

Norman's CPL is essentially doing the same thing as my XOR #80, in this context (CPL toggles all the bits of A, but that has no effect here since there's an AND gate shortly afterwards which isolates the bit under consideration). The other difference is that I applied the XOR #80 after XORing with the appropriate rope definition byte, whereas Norman did the CPL first. (Doesn't make a difference which order they're done in.)
And of course the CPL only requires a single byte, whereas XOR #80 takes two bytes.

Nice one, Norman! 
Note to self: The code changes you identified would provide a saving of six bytes if you weren't simultaneously implementing the alternative key action whilst Willy is on a rope.
i.e. If not inserting the CPL command, whilst leaving the XOR as a xor (ix+rope00)

Potential six-byte saving here (see my comment in the post after the linked one):
 

Norman's latest code makes it easy to switch between the two 'rope modes' (key function switch when rope turn round versus when rope passes through the vertical) - to revert the code as listed above back to the original setup (retaining the 6 byte saving), you only need to edit two bytes: change the offset byte of the XOR from 01 to 00, and then swap the JR Z, skip_0 to a JR NZ, skip_0
****
Random fact: when Willy jumps off or falls off the end of a rope, a counter is set that means he cannot get back onto the rope for 16 time-frames of the game. (Presumably intended to prevent him from getting unintentionally tangled back onto the rope immediately after dismounting.) But in a room in a modified game that has two ropes (even with the Adjacent Ropes patch implemented), this 'cooling off period' only lasts for 8 game 'ticks'; with four ropes in the same room it will only be four 'ticks' after dismounting before he can get back onto a rope; etc. 

Further to my previous post, I've implemented my suggested alternative rope motion in the attached file.
**
Code changes: this involved firstly changing the command at #937D from a XOR (IX+$00) to a XOR (IX+$01), to pick up the 'Is the rope left- or right-of-centre?' flag, instead of the 'Is the rope swinging left- or right-wards?' flag.
But that had exactly the opposite effect of what I intended (the left key made Willy move rightwards on the rope, and vice versa), so I inserted an additional XOR #80 command to toggle the movement back to the correct way round.  (I needed to insert two additional bytes for that, so I deleted the redundant two-byte instruction at #93B1, and shuffled all the code in between.)
[There may be a simpler way of doing the above without using two consecutive XOR's, but I couldn't think of one.]
**
Now that I've dealt with the technical stuff, please have a go with the rope in the Swimming Pool in the attached file.  I think this makes most sense of all - pressing left moves Willy leftwards on the rope, regardless of its swing direction, and pressing right moves him rightwards on the rope - simples!
In the original game, if you keep a single movement key pressed as Willy swings on the rope, then he switches from climbing up to climbing down the rope (or vice versa) at the moment when the rope reaches the furthest extremity of its swing and turns round to start swinging the other way - that doesn't seem to follow simple logic (hence SymbolShift was prompted to initiate this debate in the first place!)
But in the attached, if you keep a single movement key pressed as Willy swings on the rope, then he switches from climbing up to climbing down the rope (or vice versa) at the moment when the rope passes through its vertical position, from one side of the screen to the other. i.e. as the rope changes between having a 'sloping down to the right' versus a 'sloping down to the left' gradient.  This seems to me to be a more logical distinction to make, because if you consider the horizontal component of Willy's motion, he is always moving in the direction (left or right) which corresponds with the key that you are pressing.
Thoughts?
Logical Rope Movement.z80

SymbolShift wrote:
"Anyone I know who jumps on a rope for the first time is totally baffled on how to control Willy, as the climbing direction reverses when the swing direction changes. That said, after a while, you do eventually get used to it. I have coded the above method in my game (since it's true to JSW), but I did try a simplified version (left = up, right = down, no matter what swinging direction) and it seemed way more logical."
Your suggestion doesn't seem more logical to me, because when the rope is left-of-centre, pushing the left button (to move up, in your system) would cause Willy's horizontal position on the screen to move rightwards. It would only be a more logical method, it seems to me, at times when the rope is to the right of its central position (i.e. to the right of where it would hang if it wasn't swinging). 
Perhaps the most logical set-up would be to have the up-down functions of the left-right keys toggle to having the opposite effect every time the rope passed from the left-hand side to the right-hand side of the screen, and vice versa (as opposed to toggling every time the direction of swing flipped). 
That would involve the key functionality being determined by the value of the Rope Animation Frame variable (whether it is a positive or negative number, treating the byte as a signed number so that values > than 128 are negative), instead of using the Rope Direction Flag (the highest bit of the guardian type byte in the guardian definition buffer) to determine which keys send Willy up/down the rope.