IRF

I think @Richard Hallas uses a Mac, so he may have some experience in this regard?

I concur - Top hats (or mining helmets) off to Andy!

But only if the spare lives are on the first frame of animation. I like how the colour cycling of the screen is still taking place (part of the 'extra life awarded' effect) after the bonus life has already expired!

By comparing Willy's sprite data with the attribute byte values assigned to the various block types in the cavern data, I've discovered a few effects that I think will arise within the Manic Miner game engine. If you have more than 34 remaining lives and if the spare lives on the status bar are set to their rightmost frame of animation. Willy's back foot in that frame has a byte value of #03, which matches a couple of magenta INK on black PAPER blocks in the game: - In 'Abandoned Uranium Workings', some of the errant blocks (in 'even' columns) across the middle of the cavern will act as conveyor cells (no animation, but they will drag Willy rightwards). This effect could be quite erratic if the in-game music is left on, meaning that the spare lives pass through that animation frame and the conveyor effect periodically stops and starts. This should affect the new platform directly underneath the cavern's sole crumbly platform - that is in fact the very same new platform which led @DigitalDuck to improve his score here, which gave rise to this discussion! N.B. No POKE is needed to observe this effect - just set the remaining lives to the appropriate frame; - In 'Return of the Alien Kong Beast', the mid-height Water cell platform patrolled by the right-most 'rolling rock' guardian will, in theory, become crumbly. Unfortunately, Willy can't access that part of the cavern to stand on that platform and cause its pixels to crumble away, because of the aforementioned blockage on the left-hand side of the cavern (as pointed out by DigitalDuck). There is a single-cell platform occupying the same character row towards the left of the cavern (just below/to the right of the leftmost banana item), which is reachable during game play, but unfortunately that block sits in an 'odd' column, so the overwritten attribute (corresponding to a different part of Willy's sprite) doesn't match the crumbly cell attribute, and so no crumbling of pixels will occur if Willy stands on it even if it has been corrupted by a rogue attribute. However, if that platform were extended by one more block (either left or right will do the trick), then the new extension to that platform would crumble when stood upon: POKE #DD02,#43 or POKE #DD04,#43 (in decimal: POKE 56578,67 or POKE 56580,67) - apply before entering the cavern. Meanwhile, if you have 36 or more remaining lives and if the spare lives on the status bar are set to either their second or third frame of animation, then I believe the attribute value #06 (corresponding to the next pixel-row up in Willy's sprite) will be written across alternate cells of the top character row of the caverns. This could also have gameplay consequences: - The value #06 is assigned in 'The Menagerie' to an (unused) Fire cell type (the yellow bush that is encountered in other caverns), so as the number of extra lives continue to tally up, the top three items will be either embedded in or sandwiched between Fire cells, making them uncollectable without being killed (unless you move the animation of the remaining lives on to the first or last frame); - Similarly, 'Processing Plant' would be incompletable once the errant Fire blocks reach across to the portal (and probably before that - I don't think it's safe to drop down from the starting point in the cavern without first making a jump that means Willy's head passes through the top character row); - And the route options in 'The Warehouse' would be more restricted (for instance, you couldn't jump over the first Fire cell to Willy's right upon entering the cavern, without hitting one of the newly-created overhead Fire cells). P.S. Whilst researching this post, I discovered for the first time that Matthew's original design for 'The Sixteenth Cavern' may have incorporated a switch!? (The switch graphic from the Kong caverns is present, unused, in the 16th cavern data.)

Ah yes, because the right-hand half of that pair of sprite graphic bytes is pixel-less, so the attribute value #00 is written there (which happens to mean it remains an air cell).

I just tried the above experiment. (The idea behind it being to match the crumbly attribute in Eugene's Lair to one of the bit maps for a part of Willy's sprite.) When Willy stands on the corrupted conveyor, the conveyor's pixels start to crumble downwards whilst they're also animating rightwards! It's more interesting if you proceed along the conveyor from right to left, rather than vice versa. (So the pixels keep on coming from the left, otherwise they all disappear quite quickly.) Also, try leaving the music on with the spare lives dancing - the errant blocks change colour in time with the music, and if Willy is standing on the right hand end of the conveyor, then the downwards crumbly-conveyor animation keeps stopping and starting depending on the animation frame of the spare lives! (A couple of other observations: the conveyor no longer drags Willy along, even though it is still animated to look like it should. And the ever head stalactite is no longer lethal to Willy.)

The POKES for that experiment: POKE #C232, #03 POKE #8457, #30 In decimal, that's: POKE 49714, 20 POKE 33879, 48 Then start up the game, wait until the extra lives are showing in the their rightmost animation frame before pressing ENTER to stop their dancing, type 6032769 and then the cavern teleport code: 36. EDIT: Ooh, it's just occurred to me that the Cheat Mode Boot will also be printed somewhere rogue if you have too many lives and Cheat Mode is activated...

At 34 to 38 lives for Eugene, it looks like you would have to take a different route to access the bottom left of the cavern, because you can jump over the black toilet without ending up back on top of the new platform? So you would have to drop down to walk along underneath the black toilet? I have another interesting experiment for you - try resetting the crumbly attribute in Eugene's Lair to non-bright magenta ink on black paper, set the dancing lives to the right-most frame of animation (by starting and stopping the in-game music), POKE the number of remaining lives to 48 and then try playing that cavern to see what happens when Willy stands on those newly created blocks? (Both the pixel-less ones on the left, and the ones on the right which should have pixels because they coincide with where the conveyor is!) Return of Kong - it looks to me like 36 lives will also create a platform on the left which Willy can't descend past? Because that tricky leftwards jump through the corner of a short floor platform, which you normally have to do from the longish platform just left of centre halfway down the cavern, won't work (you'll pass through the corner of the short platform but then land on the new platform just beneath it?) Mutant Telephones - you could escape it you could stand on the spider threads without being killed. It always struck me as odd that you can do that in The Menagerie, but not in here (or The Bank).

Or is there some way to activate a Superjump?

I suppose there is an ecological analogy to be drawn - overpopulation of some species (not generally turtles though!) can be damaging to the ecosystem once natural predators of those species are eliminated from a habitat.

It sounds like Invalid Arrows are exactly what you're looking for.

No extra lives are awarded in JSW, so you would have to POKE a big number to the Remaining Lives variable to see what happens.

Just for fun, have you tried POKING a value of #FF (255) for the remaining lives - the maximum amount that can be stored in a single byte, to see what happens? 😆 EDIT: After scrutinising the code, I predict that the temporary flickering (not affecting gameplay) may reach the second character-row of the playing area, but the blocks which Willy can interact with won't have reached that far yet. And the spare lives wouldn't reach the bottom of the stack (even if it WAS held on page #5B on memory) until they were greatly in excess of 256 (too many to be held in one byte).

Actually, you're right. In Jet Set Willy, the stack starts at the bottom of page #5B of memory (that page was originally designated as a printer buffer for use if your ZX Spectrum is hooked up to a ZX Printer, if I recall correctly? - which is obviously not a consideration when playing games like JSW/MM, so it's a good place to put the stack.) I had assumed that this was also the case in Manic Miner - that the base of the stack would be placed at #5BFE-5BFF. And hence at theoretical risk of eventually being overwritten by the bonus lives (if enough of them built up? The errant blocks would have to be reaching the bottom right of the playing area for that to occur, so other things are likely to have gone catastrophically wrong long before that occurs!) But apparently it's not even a theoretical consideration, because according to SkoolKid's MM disassembly, the base of the stack is near the end of the remnant source code which starts at #934C. So the stack builds up from addresses #9CFE-9CFF. (Incidentally, anyone working on a MM mod and finding a purpose for that available part of memory - #934C-9CFF - would be advised to steer clear of the last few bytes, lest the program overwrite the addresses stored on the stack during flow of execution, or vice versa!)

Sorry, I just checked the data for the rest of Willy's frames of animation. That foot stays in the same place for the next two frames, so would still be manifested as white INK when printed onto the attribute buffer. It's only if you move the spare lives on to the last animation frame ('legs apart'), before entering the Kong cavern, that the item won't be auto-collected, but should instead be uncollectable.

By the way, is there some temporary flickering of these blocks? I have a feeling that there would also be some overwriting of the actual screen attributes, as well as the attribute buffer, causing flickering (which is just a visual glitch not affecting gameplay). The stack may also be overwritten, which could in theory have more serious consequences (like the program crashing!)

Ah, that item you're referring to is in an 'odd' column number, so nothing is printed there for a Willy sprite in its leftmost frame of animation. (Well, technically the value #00 is written there, but that's what was already there anyway as it's an air cell in a room with a black background, so nothing changes in that cell and the item remains collectable. Try setting the dancing lives to a different animation frame and I think you'll find that it's uncollectable.) Conversely, the auto-collected item in Kong Beast is in an 'even' column, and it's actually one of the spare Willy's front foot which 'collects' it - the byte value for his feet in that position is #77, the first 7 represents his back foot, the second digit is his front foot, and that 7 is interpreted as white INK in the attribute buffer!

When Willy falls off the bottom of a cavern (or jumps up past the top), the corruption happens to the data of certain caverns, so you would have to reload the game file to reset it. (Same with the Attic Bug in JSW.) The spare lives overspill is happening in the buffers, so it's not permanent. If you lose some lives, then it will start to become undone (the errant blocks will retreat from right to left across the screen.)

That puzzled me at first - why not completable with 40 to 46 lives? - but I see what you mean now. Willy can't progress upstream all the way along the conveyor, because he has to drop down onto it from above due to the short wall/Fire cell* combo that sit on the conveyor. But at 47 lives, the conveyor itself is corrupted along its whole length into being comprised of floor cells. (Incidentally, if that Fire cell wasn't there, you could make it back to the right-hand end of the conveyor with a well-timed jump whilst walking upstream along the conveyor, but you have to make the jump pixel-perfect in order to pass through the corner of, and thus into, the first wall block.) Of course, doing that in itself causes corruption of some of the caverns, when the game engine tries to draw the playable Willy sprite extending beyond the bottom of the screen! ** Top-notch research, DigitalDuck!

So you could envisage a scenario where progress relies on turning the music back on to make a block change from a lethal Fire cell to a 'standonable' floor block! The on/off status of the in-game music being an inherent part of the gameplay would be another novelty!

True! It occurred to me just after I posed the question that, whilst perhaps slightly novel, it wouldn't present any additional difficulty to the cavern, because the player would (for a 'standard' Kong-style cavern) have to pass through there anyway. However, musing on it a bit further, I think I have thought of a possible cunning use for it... I feel another quirky one-cavern puzzle might be in the works...

That comment has just inspired me to wonder - has there ever been a MM game with a Kong cavern where an item is embedded within the collapsing wall, and therefore only collectable after the first switch has been tripped? 🤔

Even curiouser - if the item in AUW is collectable (ie. by Willy when he passes through it, not auto-collected as soon as Willy enters, like the glass in JSW's The Swimming Pool), that suggests the glitch is just a visual effect, not affecting the gameplay. (An item embedded in a genuine non-Air block is either uncollectable, or auto-collected if the block happens to have white INK. EDIT: or collectable if it's within a crumbly block but only once that block has been completely crumbled away by Willy standing on it.) Yet in terms of Willy's ability to stand on the errant blocks, it's seemingly more than just a visual artefact and it does affect the gameplay! ** A couple of additional thoughts that I had: (1) These rogue blocks created by the spare lives overspilling are analogous with some Invalid Arrow effects in Jet Set Willy. (Is there a separate topic discussing Invalid Arrows somewhere here on JSWMM?); (2) You said that the errant blocks manifested themselves as fire cells in Skylab Landing Bay, making that cavern impassable. But did you try teleporting beyond there (using 6031769), to see what might happen beyond that? If the bonus lives continue to accrue, then new gameplay possibilities might open up (even quicker routes/shortcuts), as the extra blocks continue to build rightwards... Although if they stretch across the whole screen, they might make it impossible to descend a cavern from top to bottom? (Unless of course they manifest as crumbly blocks!?) They might also block progress if they appear as solid wall/earth blocks...or may spice things up if they turn out as (non-animated) conveyor cells! (The exact behaviour depends on the assigned attributes for each block type in each cavern, and whether or not there is a match - floor/water tiles being the default if there's no match.) The errant blocks shouldn't collide with any guardians (since such collisions are pixel-based), but they might conceivably trigger rapid air loss in the Solar cavern when the solar beam passes through them? Finally, what happens when the blocks created by the bonus lives go past the right-hand side of the cavern? Do they start to fill the next character row down, or do they then start to corrupt the pixel buffer? (Now that COULD cause a guardian collision!) ** Sorry, that turned out to be a lot more than "a couple of additional thoughts"!!! 🤣

Okay, I've just seen the caveat at the start of your video. (EDIT: This post crossed over with DD's latest reply.) On that basis, whilst it's a very interesting and quirky experiment, I don't think it should form the basis of an update to the ranking table? As you suggest, it isn't something that can be achieved in the High Score Challenge, because it relies on the player having completed all 20 caverns several times through beforehand! Which isn't something you can do in the HSC; you just pick a cavern and play it (slowing your score for that cavern easily to be seen, since you start off with 000000) Also, the high scores in the table at the start of this thread should serve as a target for the average (good) player to aspire to. I don't think activating this bug is within the bounds of normal/sane gameplay! Plus the precise outworkings of the bug may be somewhat predictable. In one cavern during your experiment, an errant extra life auto-collected an item (presumably because the INK in the host character space was rendered in white). But in other circumstances, a non-white INK attribute might get printed over an item, making it uncollectable!? Those are just my personal musings; ultimately it's Andy (Spider)'s call as to whether to update the high score table, since it's his project.

Wow! Did you actually play far enough without losing lives to gain enough extra lives to spill over onto the playing area, or did you POKE the remaining lives to a high number and start from there? Anyway, I'm confident now that I won't need to update my forthcoming project again like I did have to do for The Endorian Forest.