IRF

I have some other suggestions for John Elliott if he ever carries out a further update of JSWED. I intend to post in detail on this matter when I get the time.

Meanwhile, if you NOP out 38115 to 38119 inclusive, then Willy can no longer fall a greater distance than usual if the descent spans two vertically-adjacent rooms.

I think what happened there is that the rope must have caught Willy (just prior to the start of your recording) at a point in his jump when he wasn't cell-row aligned. EDIT: I think it is more likely to occur if Willy is in the descending phase of his jump (i.e. past the apex). Then when he emerges at the top of the rope, he carries on with his jump (because of the POKES we came up with above), and so he ends up 'out-of-step' with the platforms! You can also have another effect if Willy falls a dangerously long distance, which he survives because he is caught by a rope. (e.g. drop out of The Orangery). If Willy then climbs up to the top of the rope into the room above, without having dismounted and remounted the rope in the intervening period, then as soon as he appears in the room above he is immediately caught in an Infinite Death Scenario (EDIT: again, this only applies in the context of the POKES discussed above being in place)! This occurs because the Airborne Status Indicator isn't reset to zero when Willy catches onto a rope, but rather it is reset when he later jumps off, or falls off the end of, the rope. (You can see a similar effect by getting Willy to fall a long distance onto a rope, and then teleport off the rope using WRITETYPER. Willy then resumes his fall without the Airborne counter being reset, and so he can be killed when he lands on a platform, even if it is only a short distance beneath him in the room that he has teleported into! Likewise, if Willy is caught by a rope mid-jump and then WRITETYPER's back off it, he resumes his jump and he often ends up falling through solid platforms, because he jump is out of sync with his surroundings!)

On reflection, I think I'll take back my comments above. Whilst a study of the code would suggest that a note of value #00 should only be slightly lower in pitch than one of value #FF, having listened carefully to the two notes played one after the other in sequence, there does indeed seem to be an octave difference between them. Why this transpires to be the case is a bit of a mystery; perhaps the carry flag is being set as the register rolls over, and this is extending the delay between excitations of the speaker diaphragm in some way?

Mickey, one little thing that you should perhaps fix in the next build is the erroneous colour attribute in the Impossible Triangle on the Title Screen. It's the Green/Black square inside the 'S' of 'SET'; it should be Green and Blue. You can fix it in the 'Title' Menu in JSWED, or directly in the hex editor (address #98D2 should hold '0C' instead of '04'). Also, I wonder whether you should animate the Skull guardian in Out on a Limb? In the original game it only uses one frame of animation, which seems a shame.

I've just noticed that the item shape which you've added to The Hall is the one from Above the West Bedroom, rather than the one from West Wing Roof as per Andy's suggestion. (Mind you, both items are 'floating' in their original settings.)

Cheers Mickey! I think we've nailed Conservatory Roof, and its relationship with The Orangery (perhaps you might want to add the article i.e. the word 'The', as we did in TNE?) That 'One Flew Over the Cuckoo's Nest' is really psychedelic now! I suppose that kind of references the theme of the movie of the same name, set in a psychiatric institute? One late thought which I had - if you raised the rightmost Water cell in 'Tree Top' up by one cell-row, it would prevent the player from accidentally jumping into an IDS fall from the far left of 'One Flew...' (I kind of raised the issue before, suggesting the platform in 'Tree Top' could be extended leftwards [so that it's two blocks long] to catch Willy, although I suggested that particular IDS was a bit less unfair than others we've discussed. However, raising the platform instead of lengthening it would be less visually intrusive, so it might be worth doing? Just a suggestion, that's all.) Otherwise, I have no further suggestions. (Except that you might want to replicate the final layout of Conservatory Roof/Orangery in your other project - the one where you filled in the gaps in the mansion layout with new rooms?) P.S. I agree that WRITETYPER codes for Rooms 61-63 would be a worthy addition to Richard's disassembly.

Are you sure you included the right file? Rev3b looks exactly the same as Rev3a..

I think that both cases of 'FE 01' in the above can be replaced with a '3D' (DEC A) command, with the same effect on the Zero Flag but saving one byte in each case (i.e. two bytes saved in total). Come to think of it, Matt Smith could have pulled off that trick at the start of 'Move Willy (1)', saving another byte at #8DDF. There may well be other cases in the original code where a CP 01 could be replaced with a DEC A, or conversely a CP FF with a INC A. (There's even a CP 00 in the 'Move Willy (3)' routine, at #8FE2, where an OR A would do the trick in one byte! That's a check if Willy is jumping when he's moving leftwards; the equivalent command when he's moving rightwards does use an OR A!) P.S. The INC A or DEC A optimisations are only possible if you're only checking whether a variable matches with values of FF or 01; not if the same part of the code subsequently goes on to use the value of the variable for some other purpose. (Otherwise you'd have to decrement or increment the A register back to its original value, thus negating the byte-saving!)

I think that might be quite similar to Richard (SkoolKid)'s fix: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#corruptedConveyors

The IDS occurs because the A register is retaining its previous value, which happens to be Willy's y-coordinate (loaded up in the previous instructions at 38085-89). So the program thinks that Willy has just fallen a height of 104 room-cells! Try also NOPping out the next three bytes as well (i.e. 38090-93 inclusive), and it should work fine, with the jump carrying on where it left off?

I've playtested the new rooms now, all's good - I particularly like the nice new Rope challenge!

Will do. :) I think IDS's are acceptable if the player is aware that there is a risk if they make a mistake. e.g. when crossing a room from one side to the other, above a precipitous drop but with jumpable gaps between the platforms. :excl: However, if the player is lured into a drop/leap 'into the unknown', then they can be unfair. :o It is quite possible that someone trying to drop down from 'Conservatory Roof' might not have visited 'The Orangery' before, so it feels right to eliminate IDS's from that manoeuvre. Another example which I previously encountered was the sideways leap from your previous layout of 'One Flew Over the Cuckoo's Nest', which got me into an infinite death :blush: but which you've now fixed. There is now a similar risk if you make the jump in the opposite direction i.e. from the very edge of the leftmost platform in 'One Flew...' - you could fix it by extending the rightmost platform in 'Tree Top'. However, it seems a bit more fair on the return journey, because the player will know what to expect when jumping leftwards out of 'One Flew...', having arrived there earlier in the game from 'Tree Top' [unless they cheated and got there via WRITETYPER! ;) ] Anyway, we're being far more cautious that Matt Smith ever was - I recall reading an interview where he said that he was aware of the potential for infinite deaths, but he couldn't be bothered fixing them (or words to that effect)!! :P

I've attached another .rzx here, to demonstrate the spectacular IDS fall into the Swimming Pool! Note that I recorded this before I added the extra Water platform that you saw in the other recording (which catches Willy and prevents the IDS). Taking a Dive!.rzx

In the latest build, you have indeed prevented the IDS if you walk left off the leftmost Water block in Conservatory Roof. However, if you stand on the far left edge of the Water cell at the bottom of Conservatory Roof and jump left, you somehow miss both the left-hand block in that room and all the blocks in The Orangery - Willy ends up falling all the way to an infinite death in the Swimming Pool!! SPLASH!! How about both your new block and the one which I suggested near the top? I think that would ensure a safe passage down to The Orangery in virtually all circumstances. EDIT: Alternatively, you could put an additional Orangery Water block directly under the position that I highlighted with the cursor? That would mean the player could get frustratingly close to achieving a short-cut to the items in Conservatory Roof, but still not be able to quite reach them! (See the attached .rzx recording - the new block is the one that Willy ends up standing on at the very end of the recording - So near and yet so far; back to the Banyan Tree you go, Willy!! :lol: ) Orangery Frustration.rzx

I've had a look at the latest build, but I find that I can now once again take the shortcut of jumping into the underside of Conservatory Roof, from the outside of that room's Ramp! (Thus avoiding the climb up A Bit of Tree etc.) However, I've had another idea for a final tweak - please see the attached screenshot of The Orangery. Basically, if you shift the Water block that is diagonally adjacent to the cursor square, into the cell highlighted by the square, then you could in turn safely remove the bottom-left Water block in Conservatory Roof. That will remove the possibility of a shortcut to the Conservatory Roof items, yet the relocated Orangery platform will catch Willy (without an IDS) if he overshoots when jumping to access the left-most item in Conservatory Roof. The extended CR Conveyor looks good, and adds an extra bit of spice! Still on my to-do list: playtest the amended layouts of the four new rooms. P.S. If you adopt the suggested final tweak, could you label the next build No. 3, to avoid confusion please?

Oh, one other possible tweak to Conservatory Roof that I've just thought of - perhaps you could extend the length of the Conveyor by one cell to the left? Still with a rightwards conveying action though. (With an additional Water block under the exended part of the Conveyor, for 'support'/aesthetic purposes.) That would preserve the original challenge of having to make a vertical-jump-on-a-conveyor in order to collect the second-from-left item without losing a life. And being forced to walk without stopping to sneak under the red guardian (and then jump back up) in order to reach the leftmost item. (As things stand, the player can jump over the guardian and collect the second item, by standing on the two Water blocks to the left of the conveyor.) P.S. The extra (aesthetic) Water block in Banyan Tree looks good - was that in your first release, and I missed it, or have you just added it?

I think you're almost there with Conservatory Roof. All items are collectable without loss of life, the tight timing for sneaking under the red guardian is maintained, there's no shortcut through the ramp (i.e. from outside to inside the roof structure). However, I've noticed that there is an unfair Infinite Death Scenario in the Orangery, if Willy walks leftwards off the bottom-most Water block (the one above the first 'o' of 'Roof'). I suggest you move that block rightwards by one cell, so that it sits above the second 'o' of 'Roof'. That, in turn, then opens up the possibility that the player might miss the left-most Water block when trying to access the left-most item, and fall into a different Infinite Death Scenario. So you could add an extra Water block at the top of The Orangery to catch Willy in that circumstance - at the same height as the existing highest Water block in that room, but a few cells to the left. (Above the letter 'r' should do it?) I suggest you playtest jumping left off the lowest platform in Conservatory Roof from each of Willy's frames of animation, to make sure that you've eliminated the IDS's. I'll playtest the rest of the new rooms later, although I did notice an interesting use of a new Rope in the MegaTree... One other observation - have you removed the Code Entry screen altogether? It would seem a bit of a shame, what with you having fixed the bug in it (especially since it let you through on the second attempt anyway!)

A more detailed explanation for this fix is now available here: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/7050

So you would favour Q-W for Left-Right over O-P, as I deduced? Elementary! I'll explain at a later date how I came to that conclusion. For now, I'll just point out that I think I have opened up a whole new field of study: Forensic Willy-ology!

One other thing Mickey, for a bit of fun... If I may be so bold, I am going to try and predict something personal, based upon my reading of your game code. It seems to me that you tend to play JSW using your left hand to press 'Q' and 'W' for Left and Right respectively, rather than 'O' and 'P' using your right hand (as I do). Am I correct? ;) (If not, then I would hazard a guess that it is true of whoever created the snapshot, upon which I presume you based your gamefile?)

Actually, I've just noticed that the default status of the music is OFF when you first load up the game. It should be ON by default. This caused me great puzzlement for a while, but I've finally managed to figure out what's going on. The value stored at #85E2 in the game code is '02', rather than '00'. So Bit 1 is set at load-up by default, causing the music to be off when you first press ENTER to play. (In subsequent games, it retains the ON or OFF status which it was left with when the previous game came to an end.) I'm guessing that you must have built your game upon a snapshot, which was taken at a point when the music was set to off? In fact, for elegance, all of the game variables from #85CB to #85E4 inclusive, should really be given values of '00' in the release candidate's game code. Although in practice, most of those variables are correctly initialised by the routine at #87CA as soon as the game is loaded up. (Otherwise the game would commence, after loading, with Willy located in whichever room/coordinates/etc, he was at when you took the original snapshot!!)

... I strongly recommend that you play the room 'Eugene Lair' directly upon starting up the game. i.e. by setting Room 61 as the starting room - Willy should be positioned, via the Portal page in JSWED, at the bottom of the room above the 'EN' of the word 'EUGENE'. (Make sure he starts off buried up to his neck in the two Cyan cells, rather than standing on those cells, or else the room may be uncompletable.) This is how the author intended the room to be played, I believe - over on the Yahoo! group, Igor reported a bug: "I've found a bug, that I can't solve - but it doesn't harm the game. You will meet it in the EUGENE LAIR. > Skylabs turn into Droplets. When you will get to it you'll see it." It doesn't harm the game in the sense of rendering it uncompletable, but I do believe it takes a certain element away from that room. What is happening is that there are Droplet guardians (i.e. Skylabs that don't move sideways between 'incarnations') that are normally encountered in an earlier room of the game. The effect of the Droplets patch, which John Elliott describes as 'experimental'*, is to permanently overwrite the horizontal offset that is applied to Skylabs (at #FF61 in the Skylab movement code). Incidentally, I believe I have come up with a fix for that, which I shall report on later. [*'Experimental' probably for this very reason, as well as the fact that they can sometimes be drawn with an erroneous initial sprite-frame.] Anyway, if you load up the game with Willy placed directly into Eugene Lair, then you will bypass the corruption caused by the Droplets in the earlier room, and so you'll be able to play 'Eugene Lair' with the Skylabs (which look like explosions of lava) in full effect. It's an awesome challenge - nowhere is safe!! :o :excl: ;)

Suggested POKES to implement the above in the next build: At #87CF, insert 'DF'. At #87DD, insert 'CD 18 97'. At #9718, insert '3D 32 E1 85 C9'. It only makes a subtle difference but you can tell that the tune no longer starts 'abruptly' with the above patch in place. (Incidentally, I've PM'd SkoolKid about this and he intends to add an entry about this, the next time he updates his disassembly.) ****** Also, if you want to ensure that the default status of the in-game music is On at the start of each game (even if the player switched the music Off during the course of the previous game), then you can do this by simply inserting the following at #880E-#8812: '3E 01 32 E2 85'.

Not fair - poor Willy!! :lol: