IRF

Doesn't 'Eugene - Lord of the Bathroom' use 'Erix Mode' as well (albeit an Erix1 rewrite of the Manic Miner game engine, rather than of JSW)? That's not to detract from your decision not to waste time categorising your list of games by game engine modifications - a decision which I can very much sympathise with! I seem to recall that Igor Makovsky's 'Ultimate Manic Miner'* would merit its own similar reference in the list - I think that Igor modified the JSW64 engine in that game, though I can't recall the details? Not to mention Norman Sword's numerous major game engine rewrites! So for consistency, you either had to make major changes to a lot of the entries in the 'Complete list of MM and JSW games', or else trim out the extraneous detail such as which Geoff Mode applied to the various games by Geoff. (*Incidentally, did you ever discover the personal tribute to yourself and many of the other 'Willy old-timers' in Room 54 of 'Ultimate Manic Miner'?)

It's a reference to the fact that one of the room names ('An Ecumenical Matter') is based on a quote from the Channel 4 show 'Father Ted'. Probably the kind of cryptic comment that you needn't concern yourself with. 😉

Is it just me, or do some older posts get truncated when you view them? e.g. this one, which ends just as it is getting going, with "Daniel Gromann raised the question of the game": EDIT... Posts split from original "Temporary Issues" topic.

I don't think that's the right tune. 😮

Now that one (tune.tap attached to the post quoted above) is familiar...

Whilst I was at compiling the previous images, I also came up with this one, which highlights more clearly the 'protective shadow' provided by the vertical guardians. N.B. No air-sapping took place in this frame - which might be counter-intuitive, since the front part of his head is within the beam and is drawn with white INK! But that's because the solar beam itself is drawn with white INK (on yellow PAPER) attributes, overlaying the front of Willy's head (which had previously been discoloured by the guardian's blue INK, earlier on during the processing of this pass through the Main Loop.) Presumably, Norman's modified solar beam wouldn't turn red at all here (which is good, both in terms of gameplay and analysis of the beam mechanics!)

There are also occasions when the solar beam only saps 4 air units, so it would be useful to only have a single character of the beam highlighted with red in such circumstances. In the two attached images, the solar beam is sapping 4 units and 12 units of air in those respective time frames. In the first image, the right of Willy's sprite falls under the shadow of the adjacent guardian, which protects him from the air-sapping effect of that character of the beam. Then the beam is deflected by the guardian, so it passes horizontally through the left of his sprite. A single red character of the beam would help to highlight what is happening. In the second image, the solar beam is passing vertically through Willy whilst he is jumping/falling and not cell-aligned. So three red characters of the beam would be visually useful here. Norman, I presume the beam is highlighted in red PAPER but with white INK in your images? (So that any infilled pixels of Willy's sprite would be visible within the red beam? I can't tell from the images you supplied so far, because Willy just happens to be in right-facing animation frame 0 is all cases, meaning that the right half of his sprite is comprised entirely of unfilled pixels.)

I think it's a useful tool (the beam turning red where Willy enters it), but the usefulness would be enhanced if it were to revert back to yellow 'downstream' of Willy. Because that would allow you to more clearly distinguish between times when the beam is sapping 8 units of air (as per your images), and when it is sapping 12 units - if Willy were to jump in the air in the scenario shown by your images (and assuming the beam stays in the same place), then in the next time frame, his sprite would be spanning three character-rows, and so three characters of the beam would be highlighted red in the upper image.

Thanks, Norman. It's interesting to see that the deflection of the beam (by the vertical guardian extending its reach) is favourable to Willy in that instance. (N.B. It can work the other way too, in some circumstances. e.g. if Willy had been standing a bit further to the left in the screenshot I uploaded a few posts back, then he would have been zapped by the beam, but only because the beam had been deflected downwards by the blue vertical guardian's 'shadow'.) Question: Is the red part of the solar beam in your top picture intended to show where the beam is in contact with Willy? If so, then shouldn't the final character of the beam revert back to yellow? Since Willy is only occupying two character-rows at that moment in time (as evidenced by the fact that the difference in score = 8 points. i.e. only 2 cells of Willy's white INK are in contact with the beam). I mentioned it as a bug because SkoolKid lists it as such in his disassembly (instead of it being in the 'Trivia' section). There is also a similar entry in the 'Bugs' part of the disassembly concerning the attributes bleeding out of Skylabs whilst they are on their landing pads just after crashing - the rationale for that not being a bug, I tell myself, is that the dust emanating from the disintegration of the Skylabs is what is temporarily colouring the platforms.

Another excerpt from the 'Jet Set Mini' Readme provides a couple of POKES, either of which allows you to play around with another novel, quirky feature of the game - namely the invalid rope in the room 'Overgrown MegaTree / Front Door' - happy swinging!:

I've already asked him (by email), and he also thought it was 'influenced by Bach' (but not actually 'by Bach').

Or POKE 37495, 201 (in Bug-Byte) turns off the second Fire cells for each cavern, but not the first.

Sorry, I can see where I made a mistake. I forgot to use an 'R' to turn Willy around after he drops down at the upper-left part of the cavern (after the first few jumps). This datastream is what I was aiming for (N.B. I've crossed out/underlined one 'R', and replaced it with an earlier one highlighted in bold) - the jump over the BRIGHT yellow Pac-man leaves Willy in exactly the right place to wait for the magenta Pac-man to turn around and start moving away: Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q . . . . . . . M . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . RM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . RM . . . . . . . . . . . . R R RM . . . . . . . . . . . . Q QM . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . . Don't worry if you've already updated your automated file and can't be bothered to make the tweak.

There don't seem to be any POKEs here to protect Willy from being killed by Fire cells in the Bug-Byte edition of Manic Miner (unless I've missed it?) There are two POKEs provided in the first post of this thread for the Software Projects version which apparently do the trick, so based on those, the following two POKEs should have the same effect for BB-MM (although I haven't tried them out yet): POKE 37492, 58 and POKE 37499, 58

No, I think it actually is the same number of frames as your previous best score-run (judging by the length of the video and the final positions of the guardians in each case). What I was trying to say is that, in your latest video, Willy avoids the (previously) first contact with the beam - which saves him from 24 saps - but now his first contact (which was previously his second contact with it) is more deadly by 20 saps compared with before. So the net reduction in total saps across the cavern is 4 - which equates to a total score that is 4 points higher (because both runs finished after precisely the same number of frames).

Thanks, Norman. If there's another update in future, perhaps you could take the opportunity to clean up the datastream in Processing Plant, as per this post (it's no biggie though):

Thanks, crem. I've just been scrutinising both the previous best score video and the current one. The previous one had an additional encounter with the light beam (at the point when Willy is on the conveyor), sapping 24 units of air. However, during the jump through the vertical beam to reach the top-right item, in the previous video Willy benefits from being in close proximity to the yellow horizontal guardian when he makes that jump, meaning that the beam doesn't recognise the presence of part of Willy's sprite (which is overshadowed by the guardian's attribute). Therefore only 64 units of air are sapped during that encounter with the beam, compared with 84 units in the latest performance (difference of 20). During the final jump back through the beam from the top-right corner, 72 units of air are sapped in both videos. Hence the net improvement in the latest walkthrough is only 4 points. *** This analysis has indirectly led me to discover something else about the solar cavern. In SkoolKid's Manic Miner disassembly, he reports the fact that, in the very first frame after Willy enters the Solar Power Generator, the blue vertical guardian's INK colour bleeds into the platform immediately below it (even though the guardian only occupies two character-rows at that point in time): https://skoolkid.github.io/manicminer/reference/bugs.html#blueShadow It's just occurred to me that this bug of the game engine means that a guardian (or rather, the 'shadow' of the guardian) can deflect the solar beam even when the beam isn't passing through it! You can see that occurring in the attached screenshot (beneath the blue vertical guardian, which at that moment in time is cell-aligned in the two character-rows above the approaching beam). In some circumstances, that might actually be beneficial to Willy. (Although at other times, the bug might send the solar beam in Willy's direction when logically it shouldn't!)

Would you be able to provide a similar column of data to what you did before, showing the number of 'air saps' by the solar beam in each frame of the game? It seems to me from watching the latest video that Willy only passes through the solar beam twice? (The bare minimum necessary in order to reach the top-right item.) Nifty work!

I've just updated the Highscore table to reflect crem's algorithm's improved score in 'Solar Power Generator'. In light of that, the maximum possible score across the twenty caverns is (at least) 39,530 points. 😮

To answer my own question, it doesn't seem to improve the final score if you set off one frame earlier in 'Processing Plant'. Either way, you have to wait around for a few frames for the magenta Pac-Man guardian to move out of the way. Here is a 'cleaned up' version of the datastream for cavern 6, with the first stationary frame omitted and no jerky movement while waiting for the magenta guardian (I hope it works!): Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q . . . . . . . R R R R RM . . . . . . . . . . . . . . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q . . . . . . . M . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . RM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . RM . . . . . . . . . . . . R R RM . . . . . . . . . . . . Q QM . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . .

P.S. In your earlier post containing the keypress datastreams, it states that the Kong run without flipping Kong had the 'First frame stationary' bug in place. I don't think that would make a difference to the completion time in this case, because Willy has to wait around at the end for the rolling rock above the portal to get out of the way. However, in the same post (see below), it also states that the Cavern 6 datastream also had the 'First frame stationary' bug. Did you check that that didn't have any effect on the possible final score either?

Thanks, no surprises there really. Final score 1692, for the record.

Doesn't the fact that the Airborne Status Indicator (#806B) = zero tell you that Willy is on a platform of some sort? You can also distinguish times when Willy is jumping sideways from when he is standing around by the Movement Flag in #806A.

Could the implication of the bug mentioned above possibly be that there is a better final score to be achieved for this cavern than the one you have reported so far?

Crem, unless I'm mistaken I don't think you ever posted your video of Willy completing the first Kong cavern without flipping Kong? (Although you did provide a datastream which your algorithm came up with for that scenario.)