IRF

Here are my observations after investigating Norman's 'Conveyor logic' test file: Firstly, I agree that the escalator in First Landing is cool! The Bathroom (aka 'Plumbing Mess'): It is possible to complete the room with all conveyor types. With Type 3, it can ONLY be completed (without losing a life) by exiting the room via the top-left exit. Analysis of conveyor types (based on the number that appears in blue INK at the bottom-right of the status bar): Type 0 - I can't see any difference between this and Type 2 (see below), they appear to have identical behaviour. Type 1 - Willy is conveyed forwards (i.e. in the same direction as he was facing beforehand), slowly (i.e. at the regular walking speed), it is not possible to 'drop and stop' (i.e. drop vertically down onto the conveyor from above and then arrest forward motion by pressing the opposite sideways key to the way he is facing). This is a two-way conveyor with Norman's original patch to eliminate the 'sticky' behaviour. Type 2 - Willy is conveyed forwards, at a fast pace (using only two of the four available frames of animation), no drop & stop. This one uses Norman's Ice Patch, eliminating 'sticky' behaviour with fast motion (and no apparent motion by Willy because the two frames of Willy used are identical apart from their horizontal positioning). (Presumably Types 1 and 2 are differentiated via a CP command to check the Conveyor direction byte?) Type 3 - Willy is conveyed forwards, slowly, if he jumps (or walks) sideways onto the conveyor, but gets stuck if he drops or jumps vertically onto it. This is therefore the same as what has commonly been used/known as a 'sticky conveyor'. Type 4 - Willy is conveyed rightwards, quickly (using two animation frames), unless he is facing leftwards with the left movement key pressed when he lands on the conveyor. It is not possible to drop & stop (i.e. drop vertically down on to the conveyor whilst facing 'upstream' - in this case leftwards - with the Left key pressed), or to turn & stop (i.e. walk 'upstream' - in this case leftwards - then stop pressing the Left key for a single time-frame and then resume pressing Left), in order to remain at a fixed position on the conveyor. Type 5 - Willy is conveyed rightwards, slowly (standard speed), unless the left key is pressed and he has leftwards momentum when he lands on the conveyor. The 'drop & stop' / 'turn & stop' manoeuvres are possible on this one. I think this is basically a standard Right Conveyor as per original JSW (Conveyor direction byte = 01). Type 6 - Same as Type 4 but with slow movement (using all four animation frames). The change between Type 4 and Type 6 is analogous to (and presumably done in a similar manner to) the change between Type 1 and Type 2 (i.e. to toggle the slow/fast conveyor action). Both Type 4 and Type 6 are variations on Right conveyors - has some other patch been applied to the Move Willy code to implement these? (Perhaps another CP command in the called subroutine, to check for another fixed value for the conveyor direction byte?) Type 7 - An Off Conveyor, with no conveyor qualities at all (except perhaps animation of the first and third pixel-rows, if that were possible to see, which it isn't in this room). Conveyor direction byte is set to 02 (so that after subtracting 3, both bits 0 and 1 are set - one of those bits being reset is what drives Willy's sideways movement).

I guess the 'mission' in each Bathroom variant of Norman's test file is to collect the tap and then exit top-left without dying? (Might not be possible for every conveyor type?)

I'm now convinced that it (the Ice Patch) will do what I suggested in my third guess (although I still haven't tried it out yet). Kind of like the toilet run, but it will work in both directions (going left or right) on a conveyor that has the appropriate setting. Incidentally, I'm convinced that Matthew made a boo-boo in implementing the toilet run. I think he intended to use the 'legs together' and 'legs fully apart' frames of animation during that sequence*, so that it really does look like he's running for the toilet to throw up (the hangover having fully kicked in at that point!) Rather than using the two intermediate 'legs slightly' apart animation frames, which makes it look like he isn't moving his legs at all but is somehow being pulled by an invisible force towards the bog... (*I once figured out a way to change the code so that this happens instead, and it really does look like he's sprinting.)

No, that's not it. Hopefully third time lucky - does it cause the conveyor to pull Willy along without him having to move his legs? (Which is a more logical way that the conveyors should work!) If I'm right, it would also mean that his skids across the ice at twice his normal walking speed.

On second thoughts, does it set the jump flag (turning the conveyor into a trampoline)?

The above (note the RESET in capitals, replacing Norman's SET command) would turn the conveyor into a proper 'flypaper' platform, stopping Willy's horizontal motion even if he is moving sideways when he steps (or jumps sideways) onto the conveyor. EDIT: Although for the full flypaper effect, it should also turn off the functionality of the jump keys!

I wonder if you use a value of 03 for the conveyor definition byte, will it achieve the same thing as 255 (since only bits 0-1 are inspected by the conveyor routine), but then you can replace your CP -4 command with an OR A (which does the same thing as CP 0 but only requires one byte instead of two)? You could then use a value of 131 instead of 127 in your more advanced code to switch the stickiness back on again. EDIT: Actually you could use any value that is [a non-zero multiple of 4 plus 3] to create a sticky conveyor. (I once experimented with different conveyor values beyond 0-3, and found that they had different properties during the toilet run, in terms of the ability of the P key to stop Willy in his tracks.) **** Norman, in respect of your more advanced code, having studied it but not tried it out yet, my guess is that it has the effect that whenever Willy jumps or falls vertically onto such a conveyor, it turns him round and then conveys him in the opposite direction to the way he was facing before he landed on the conveyor. Am I right?

Also, whoever is taking Willy's hard-earned cash off him is a rip-off merchant! 😜 If he loses a life when he has, say, £99000 in the bank, then he gets all the money taken off him but is then told "Sorry, that's not enough cash to pay for a regeneration, but I'm keeping it anyway!" 😂

I made a poor observation of a suboptimal warning system. 😋 If the FLASHING £ value is to serve as a warning then it should start to FLASH during gameplay, whenever the total drops below £100,000. i.e. To signify that more cash needs to be accrued quickly or else the next life lost will mean Game Over! (It should then stop FLASHING if, during subsequent play Willy, manages to get the total back up to £100,000 or more - enough to pay for a 're-spawn'.) The way that things are setup at the moment, the £ doesn't start to FLASH until the onset of the Game Over sequence, so the player has no opportunity to do anything about it... EDIT: I suppose the FLASHING £ count on the Game Over screen serves as a learning tool for the next time you play the game, indicating one of the factors that led to your failure.

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