IRF

Final suggestion for tonight: are you editing the game in John Elliott's JSWED? If so, I strongly recommend that you implement the Adjacent Ropes (New) patch (just tick the box on the Menu screen when you first open the file in JSWED, and save). It fixes this bug: http://skoolkid.github.io/jetsetwilly/reference/facts.html#theEncroachingRope

Oh, and have you implemented the POKES that fix this? http://skoolkid.github.io/jetsetwilly/reference/facts.html#asYouWere It's quite simple, just reset the values of #85D0 and #85D2 to zero during the course of the 'Display the title screen' routine, along with all the other variables that are initialised at the start of that routine. Then Willy will always be sitting at the back of the bath facing the tap at the start of every game, no matter what his stance was when the previous game ended! In fact, it can be done without calling up code from elsewhere, if you slot the commands in in place of the ones that reset the unused Screen Flash Counter and the Inactivity Timer (assuming that you've deactivated the Auto Pause function and the Screen Flash routine remains unused). I.e. insert 'D0' at #87D2 and 'D2' at #87DB.

One other thing which I've picked up, looking at that list of bugs. SkoolKid's fix for the conveyor and the ramp in The Nightmare Room rotates all eight graphic bytes for the conveyor downwards by one byte, and replaces the conveyor attribute byte with the final graphic byte of the ramp cells. Then rotates the byte that falls off the end of the conveyor graphic definition to fill in the gap at the bottom of the ramp cells. However, I came up with a slightly alternative version, where only the first four conveyor graphic bytes are moved along, the bottom four pixel-rows of the conveyor are unchanged, and the fourth pixel-row's byte (as set out in the original game code) is used to fill in the base of the ramp. The conveyor cell is almost identical in both variants (the only difference being in the fifth pixel-row), but I think that the ramp looks better in the version that I came up with. Have a look at the attached screenshot which I created (based on The Nightmare Edition, but it allows a useful comparison), and the images from the disassembly (as copied and pasted below), and see what you think? Very corrupted conveyor You might be thinking that the fix given above for the corrupted conveyors bug does not do much for the appearance of the conveyor in The Nightmare Room. Perhaps that's because the real problem with this conveyor is that its attribute byte and graphic data - which should occupy addresses DDCD-DDD5 - appear to have been shifted by one byte back to DDCC-DDD4 (overwriting the eighth graphic byte of the ramp tile). If they are shifted along to the right spot, the conveyor takes on a much more reasonable appearance: http://skoolkid.github.io/jetsetwilly/images/scr/conveyor29_before.gif http://skoolkid.github.io/jetsetwilly/images/scr/conveyor29_after2.gif Before After In addition, if the byte at DDD5 (0x55) is shifted back round to DDCC it seems to fix the appearance of the ramp tile (by filling the gap at the bottom): http://skoolkid.github.io/jetsetwilly/images/scr/ramp29_before.png http://skoolkid.github.io/jetsetwilly/images/scr/ramp29_after.png Before After

I think that Matt Smith got the operand of a COMPARE operation out by one byte, and if a certain value is picked up then the routine is sent slightly out of range. The codes are stored at #9E00 to #9EB2, but a SUBTRACT command overshoots and points the routine at the address #9EFF (i.e. it points one byte below #9E00, but the low byte wraps around whilst the high byte still holds the value #9E.)

The same POKE fixes both bugs. i.e. instead of picking up an invalid address, the same value of the system variable that generates a random grid location will point to R9. At least, that's my understanding. (Although I haven't yet got my head around exactly how the routine generates a random number?)

Oh go on, you might as well fix it for completeness, using POKE 34556,180. Especially since the same POKE also prevents the invalid grid location from being called, as I referred to above!

You may as well insert the POKE that fixes the 'invalid grid location', even if you've hacked the code entry routine so that any code will do. It's only one POKE: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#invalidGridLocation

Have you ticked off all the entries on this list:? http://skoolkid.github.io/jetsetwilly/reference/bugs.html

I'm happy to report that I've cracked this particular nut! And I'm especially pleased with the method that I came up with to switch between am and pm, and back again (rather cunning, if I do say so myself!). Please see the attached file. For demonstration purposes, I've NOPped out the byte at #8A51 (previous value was #59), so that the clock is updated every time-frame (every 'tick' of the game's internal clock), rather than every 256 'ticks'. If you load up the file, you'll see the clock racing through the numbers! Obviously, that address should retain its proper value in a normal game file. The substantial changes are at #8A81-#8A96, and at #9700-#9708 and #9710-#971E. Mickey, you may have to find alternative locations for the stuff in the #97XX range if you've already used them for other purposes. By the way, my initial attempt didn't include the extra code at #9710-#971E (which replicates #8A31-#8A3C). When I ran the program to test it, everything worked fine at noon, and the game terminated at the right time (progressing to 'Game Over' as it should, not the Title Screen). However, the clock display didn't update to '12:00am' (midnight) when the 'Game Over' screen kicked in. I managed to fix that as well though. I realised that, even though the value of the digital clock is updated internally before the jump to #8C4A, the Main Loop prints the digital clock display onto the screen before the digital clock is updated. Thus I had to replicate the 'Print the current time' commands just before the jump to Game Over. (There may be a more efficient way of doing this by inserting the 'Print the current time' code into a sub-routine, but it's probably more trouble than it's worth unless you've got a critical shortage of spare addresses.) am to pm fixed.z80

Another feature of the patch that I've just thought of - it allows Willy to jump rightwards and land on a platform that is up to four cell-rows below his starting position, if (but only if) he bangs his head on an Earth cell on the way down! (A feat which he could already achieve jumping leftwards.)

As I said before, SkoolKid's patch is better than the one I came up with, but he only provides POKES in decimal. I tend to think it's easier to understand how they operate in hexadecimal (although emulators such as SPIN don't allow you to enter POKES in hex, which is a pain). To give you a hand, I've converted SkoolKid's POKES for this into hexadecimal, and I've also made the address for the 'remote' part of the patch more generic, so that you can slot it in wherever you know there's a space (only 6 contiguous bytes in this case) in the code. #9634 Yy #9635 Xy That the operand of the conditional Jump command at #9633 (written in the usual 'Little-endian' format). Then at the jump address #XxYy write: CB 4C CA B6 90 C9 (Assuming you decide you want to fix the bug after all!)

Out of interest, I just playtested 'Dr No', with the check for Earth cells to the right of James' head disabled. (It was a 'quick and dirty' test; I didn't implement the full patch, I just NOPped out #90A8; so in theory James could also walk through head-height Earth cells on both sides, although the opportunity to do so doesn't present itself in Dr No.) I was correct in my suspicion that attempting to jump rightwards over Honey Ryder whilst halfway along the conveyor, taking advantage of the intermittent pairs of non-Earth cells in the overhead platform, does now cause James to fall to a standstill on the conveyor, even if you keep the Right key depressed. However, it is possible to reach the lift at the bottom-right, if you run up the conveyor very closely behind Honey Ryder, and jump just before she turns round at the right-hand end. That way, James has cleared past all of the overhead Earth cells before he attempts the jump. But you have to wait till Honey has traversed the conveyor three times (first left, then right and left again) before you set off. If you go too early (on the first occasion that Honey starts to go right), then you hit the side of the lift (fatally) just after you've jumped over her. I then went on to complete the screen, but because of the extra delay involved in waiting for an extra 'Honey cycle', the time constraint is tighter, and it would be easier to run out of air supply before reaching the portal. It's not too critical though. ****** So in summary, the patch doesn't affect the completability of the screen in this particular example, but it does serve as a reminder of the danger of 'unexpected consequences' when you're making any changes to the game mechanics (or to the game engine in general)!

Although the SkoolKid fix jumps to the location of Room 61-63. So you'd have to amend it to jump elsewhere. Also, the location SkoolKid chose was immediately followed by a Return command (he did that to minimise the number of POKES). So if you are inserting the fix but putting it elsewhere, make sure to add a C9 at the end of the 'remote' part of the code!

SkoolKid has a more efficient patch for that one (see the Bugs section of the SkoolKit disassembly).

Another bug that may be best left unfixed is the one where a Fire cell at the top of the room can kill Willy if he falls off the bottom of the screen directly below it. That can be quite usefully applied to prevent falls into 'Infinite Death Scenarios'!

By the way, I came up with a 'proper' fix for the 'Sticky Bed Bug', involving swapping around some of the chunks of code in the 'Move Willy (2)' routine. (Off the top of my head: place #8F05-#8F0C before #8EFA-#8F04.) However, turning the Conveyor action of the bed to 'Off' does the trick more simply, and since Willy can't really access the bed anyway, it's probably not worth the hassle of shifting code around. In any case, it's a matter of debate whether it's a 'bug' or a 'quirky feature'! (I can perhaps imagine a teenage Matt Smith thinking: "If you play with Willy for too long, you end up with a sticky bed!!" )

Here you go, Danny - better late than never!: Moving Left #9032 C3 00 97 #9700 B7 ED 52 3A D1 85 FE 01 20 06 3A D5 85 B7 20 05 3A B2 80 BE C8 C3 35 90 Moving Right #90A1 B7 ED 52 #90A4 C3 18 97 #9718 3A D1 85 FE 01 20 07 3A D5 85 B7 C2 A9 90 3A B2 80 C3 A7 90

I thought I should consolidate all of my proposed changes that fix this bug into one post, for easier reference: #91EE to #91FA edited as follows: C3 Yy Xx 00 DD 7E 01 E6 07 4F 7E E6 78 where #XxYy is a suitable address where there are 19 spare contiguous bytes. Then at #XxYy: 7E E6 38 C2 F2 91 4F DD 7E 01 E6 0F C6 38 E6 47 C3 FB 91

Did you have any luck with this one in the end? I can provide a few pointers if necessary. :) (I've just realised that the area of code which I previously suggested for this fix, overlaps with the addresses that I put forward last night for the head-height Earth cell patch! :blush: ) EDIT: This might help: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/?do=findComment&comment=5587

Please see the attached file, in which I've applied my patches that: - Allow the program to detect an Earth cell to the left of Willy's head when he is walking (but not when he is jumping); - Suppress the detection of an Earth cell to the right of Willy's head when he is jumping (but it is still picked up when he's walking). Some credit goes to Dr Andrew Broad for helping to devise the concept for this hybrid solution, which provides the 'best of both worlds' because it: - Fixes the asymmetry in Willy's walking behaviour; - Prevents Willy from getting stuck forever in clusters of Earth cells (e.g. inside the elephant's head in Dr Jones), or in other situations (such as if he exits Forgotten Abbey in a certain way: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#stuckInTheWall ); - Retains the quirky behaviour when Willy jumps leftwards (which is necessary to allow him to navigate around The Wine Cellar, and to return along the top platform of Ballroom East); - Introduces the same quirky jumping behaviour when Willy leaps rightwards (for example, he can now exit from Emergency Generator to the Priest's Hole by jumping from the right-hand stack - although he can't progress any further than that, so it doesn't facilitate a sneaky shortcut down the East Wall!) I've tried to optimise the patches a bit (although more efficiencies could probably be found!) The code changes are as follows. I've suggested that the new code could occupy the spare addresses at #9700 to #972B, but you may need to change that [and therefore the bytes highlighted in bold] if you've already used those locations for other patches: Moving Left #9032 C3 00 97 #9700 B7 ED 52 3A D1 85 FE 01 20 06 3A D5 85 B7 20 05 3A B2 80 BE C8 C3 35 90 Moving Right #90A1 B7 ED 52 #90A4 C3 18 97 #9718 3A D1 85 FE 01 20 07 3A D5 85 B7 C2 A9 90 3A B2 80 C3 A7 90 The new patch ends at #972B. ****** On a separate matter Mickey, did you fix the conveyor (and ramp) in The Nightmare Room in your project?: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#veryCorruptedConveyor The fix described in the above link goes further than the Cell-Graphics Bug patch. Stuart Brady and I share the credit for spotting this glitch. (Actually, if you apply the fix - which involves shifting a few bytes back in the code by one byte - then the Cell-Graphics Bug in this particular room is fixed even if the CGB fix isn't in place!) Earth cell symmetry restored.TAP

If you're not careful you can get stuck in the elephant's head in Dr Jones because of the 'Don't mind your head' bug!

I've not seen a fix for the am/pm bug. It's something which I thought I might have a go at some day, but I haven't got round to yet. :blush: Andrew Broad fixed it in a sense, by introducing a 24-hour clock. However, I'm not sure that fits in thematically with Willy's creaky old mansion! :ph34r: ****** I have a couple of other suggestions, if they're not too late... :mellow: In terms of 'As Manufacturer Intended', have you fixed the bug which causes the asymmetry in Willy's horizontal movement? I recall reading an interview with Matthew Smith, in which he said that Willy's movement in JSW was meant to be symmetrical (as it is in Manic Miner). So fixing that would seem to fit the bill of 'as manufacturer intended'. :huh: You'd have to be careful not to end up making some of the jumps in the likes of The Wine Cellar impossible though. :excl: I came up with a 'hybrid' fix that provides the best of both words, although I haven't got round to disassembling it yet (yet another thing on my 'to do' list!) EDIT: Here's a link, if you're interested: :) http://jswmm.co.uk/topic/196-dont-mind-your-head-while-walking-left-bug-fix-for-jsw/?p=3999 ****** Final query: what did you do to fix the Conservatory Roof bug (i.e. the uncollectable item)? The 'official' fix* simply removed a Fire cell, but it still left another item requiring a 'kamikaze' manoeuvre to collect it. :o Andy (Spider) devised a good fix which resolved that from a 'gameplay' perspective, but it involved separating the Fire cells and items from each other. :unsure: I take the view that, from a visual point of view, the Fire cells and items in Conservatory Roof should all be paired up (as per my profile pic!) To my eye, each little 'gremlin' is clutching a beer bottle (with a black label on it) - their left arm is wrapped around the bottle as part of the item graphic (whilst they're swinging from the roof structure with their right arm) - and they appear to have drunken grins on their faces! :P I eventually came up with a layout that gives all four items an accompanying nasty, yet which allows them all to be collected without losing a life! There's a screenshot of my suggested layout in the pertinent topic. ;) ****** * In relation to the 'official' fixes, they were only 'official' in the sense that Software Projects took the POKES that the first people to complete the game came up with (to enable them to do so), and then released them retrospectively to the wider public. So I don't give them that much credence really - particularly the one that relocates the invisible, unreachable item from First Landing to The Hall, without even bothering to make it visible! :blink:

Yes, the new caverns are most intriguing! Do you have a copy of a playable file you could share with us please?

Oh, and an explanation (of both the bug and the fix) will still follow - in fact, it was when I went to type up the explanation that I got distracted by noticing the potential for further 'overspill' of Willy's graphics. (Fortunately, there are three contiguous unused bytes available for the POKES, whose addresses are of the correct format, and which lie just beyond the furthest potential reach of the corruption!)