IRF

Maybe if you ever feel the need to release a Special Edition of JSW: Mind Control or something, you could incorporate it into that?

Give him a jetpac!

Whilst I'm on the subject of the Party Willy boxset (Special Edition), the laterally-inverted MM game 'reniM cinaM' lacks a proper fix for the new switch positions in the Kong rooms. If you want to laterally invert the location of a Kong room switch, (or have a switch located at an odd x-coordinate in general), then you have to replace the two instructions at #921E-#9220: INC A AND #FE with these two instructions: NOP OR #01 I had previously included the above fix in a thread in the Contributor Forum, but thought it might be useful to make it more publicly available here.

Random observation from Andrew Broad's Party Willy boxset (Special Edition): the title screen of the laterally-inverted JSW game 'ylliW teS teJ' isn't quite a mirror-imaged version of the original JSW title screen - the entire Impossible Triangle has been vertically shifted* by a single pixel (as well as being laterally inverted). *It's been a while since I noticed this, so I can't recall whether it has been moved upwards or downwards by one pixel? So consider that to be. New Year's trivia question; answers on a postcard please... (P.S. Check out the title screen of the same file from the Original Edition of Party Willy - Andrew evidently had difficulties laterally inverting the triangle at the first attempt!)

I notice that you've also fixed the errant colour attribute in the sloping inner corner of the impossible triangle which Matthew had in the original JSW (it was partly obscured by the original block lettering, but you could see it if you looked carefully).

If you play in the mode whereby the caverns appear in the original MM order then it won't be a problem, as Willy should have accumulated a healthy bank balance by the time he reaches Solar Power Generator.

Actually, that's not a theoretical risk and there's no need to hang around for ages to bring it about - I just set the game to random mode, entered the portal in the Bathroom, I ended up in Solar Power Generator, an encounter with the solar beam sapped most of my money away, and then I got hit by a guardian and lost all my lives in quick succession!! This new system really does provide added peril to the game!

Ah, so it's a feature not a bug (to be fair, I did include that possibility in my initial post after spotting the "bug/glitch/(feature?)"). I wasn't aware of the new game parameters - I've just had a skim through the readme (Word document) in the Zip file, so I think I've got my head around the 'new regime' now. I suppose if you played very poorly - hung around for long enough without collecting items - then you could end up losing more than two lives simultaneously...

I've discovered a very peculiar feature of this game (and V1.05), which I've discussed in detail in the following post on the earlier Manic Jet Set Willy thread: The thing I noticed was that when you lose your penultimate life, you effectively lose two lives simultaneously and the game ends. (But there seems to be at least one exception to that rule - it doesn't happen that way in the Central Cavern, but only if you've collected all the items in that cavern prior to losing your penultimate life!) Answers on a postcard please...

I've just carried out further investigations into the above quirky feature (whilst exploring V3.01 of MJSW). It seems that in the Central Cavern (accessed via the Bathroom portal), there is even more unusual behaviour: - If you lose your penultimate life whilst there are still some items flashing in the Central Cavern, then both of your final lives are lost consecutively; - But if you lose your penultimate life after having collected all of the items in the Central Cavern (but before reaching the portal), then the cavern is reset and you have your final life remaining to try and complete it! I tried to replicate this in another cavern (Cold Room) to see if there was a difference between JSW rooms and MM caverns, but the above pattern wasn't replicated there. Very peculiar!!

To answer my own question, after having checked out the V3 game file, the bouncing horizontal guardian behaviour does seem to have been fixed. However, in the process of investigation I have noticed another bug/glitch/(feature?) which is present in both V3 and (although nobody seems to have noticed it before) in V1.05. Namely that when you lose your penultimate life: - the current room is reset as it was at the point of Willy's previous death (instead of him being at his earlier point of entry to the room, and also guardian positions don't reset themselves to their initial starting positions for the room); - the flashing death effect repeats; - and Willy immediately loses his last life and the game ends. i.e. two lives are lost consecutively. The effective consequence of this bug is that you have one fewer life to play with than you think you have. I would surmise that @jetsetdanny never noticed this, despite his extensive playtesting of V1 of the game last year, because he tends to try to avoid losing any lives (using a Rollback feature to assist in this endeavour), and so wouldn't normally proceed to the point of only having one life remaining.

Danny, hopefully one day you will create a new game using the JSW128 or JSW64 game engine, in which case I hope you implement the modest code changes I suggested that will give you a personalised cheat mode password. (And perhaps by then you will also have cracked the code so that you know what your personalised password actually is!)

Happy New Year everybody!

Norman, is the problem you refer to above the quirky behaviour of horizontal guardians when they turn around at the rightmost extent of their range (skipping two frames of animation in the process)? Something that made, for example, Cuckoo's Nest slightly more difficult to complete. (And also had an effect on the timing/positioning of the solar beam in Solar Power Generator, because of the complex interactions between the solar beam and the relative positions of the slow and fast horizontal guardians in that cavern.) Am I safe to assume that that quirk has now been fixed in V2/3 of the game?

"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. 😉

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'!

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.

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!)

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? 🤨

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!?

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.

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

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)