IRF

I wasn't sure where to put this, but this seemed like as good a place as any... I encountered a headless Willy just now - see attached screenshot. No POKES or code changes were involved! Willy managed to walk away safely though - and his head came back!

NOTES TO SELF, for future reference: I've just investigated the above, and my reading of the code was slightly wrong - it is possible to reduce the initial air supply in such a way that a pixel-perfect, quickest-possible cavern completion leaves Willy with precisely ZERO units of air left, but he can enter the portal before being killed in the last time-frame (i.e. just after the last gasp of air has expired), with ZERO points being accrued for remaining air left. DONE EDIT: However, four caverns would need 'special treatment' (i.e. a Cavern Setup Patch to insert a CPL instruction after #8D1F in the 'Move the HGs' routine; then that would need to be NOPped out for all other caverns) to deal with a combination of Slow guardians and the original initial air supply value being reduced in the modified file by an odd number of increments), namely: Telephones, Return of Kong, Warehouse and Solar Power. (N.B. That's for the BB version; for the SP version only Telephones, Return of Kong and Solar Power would need the CPL instruction to be patched in, because The Warehouse would have one less unit of air in a 'perfect performance required' version of MM-SP.) [One example of the impact of those two factors is that the pattern of the solar beam changes because the slow HG isn't in sync with the other guardians in the same way. Another example is that Willy has to wait one extra time-frame for the slow 'rolling rock' in the second Kong cavern to move out of the way.] DONE ---- EDIT: The Endorian Forest has a new high score thanks to DigitalDuck, and this means that the above patch needs to be applied for that cavern too (since it has a slow guardian) - ALSO DONE The 'Nine Lives in the Light' bug would also need to be fixed, to stop Willy's air supply from being replenished by the solar beam when the air has dropped down to the last character on the status bar. DONE Slow down screen colour-cycling after entry to portal - to give the player a chance to 'breathe' before embarking on the next cavern! DONE (Changed #90A3 from '04' to '10') Also consider having zero spare lives (to prevent possibility of inflated score by repeatedly collecting the same item via different lives, and making Kong out-of-bounds (i.e. not enough time to flip the switch and escape to the portal). DONE Finally, might have to fix the visual glitch which occurs when a value of #00 for Offset #2BD in the cavern definition (especially if it turns out that that is a value that occurs, once the initial air supply levels for each cavern has been adjusted). DONE P.S. Could skip the 'Game Over' sequence, if it proves to be too annoyingly repetitive. (You can't abandon it once it starts going!) DONE P.P.S. New name for the modified game - DONE - and an associated change to the title screen/scrolly? - TO DO

Well, if you listen to the link above from 10 seconds onwards, and listen to the .tap from 27 seconds onwards, they are identical. It could be that the .tap is an amalgam of another tune as well, I am just trying to work that part out. Yes, you're right about that part. However, I wonder if it's a medley of different tunes? The first bit is very familiar, but doesn't seem to be part of the Washington Post March. Andy, just posted an embedded video in the previous post to this, which starts off with the same familiar tune as the tune-tap he previously uploaded. Hopefully someone else might recognise the start of the tune? @Richard Hallas perhaps?

Danny, here are a few suggested tweaks in bold: ("Item" could lead to confusion with the game's collectable items!) (I'm not bothered about not getting a credit here; most of the work has been done by crem, his algorithm, and Norman Sword.)

Not really, no. 🤨

Furthermore, I've noticed another five or six missing or truncated posts in that thread alone (other than the ones I mentioned above, and the ones that Andy listed.) Probably too many to mention them all, but this one in particular might be worth rescuing if possible, as it seems to be the one in which Fabian might give a detailed explanation about his new game? (i.e. the background to the game, etc): I dread to think how many more posts might have been affected across the whole website...

And this one is severely truncated - I suspect that Danny made lengthy comments about all the rooms in Fabian's game, but all you can see is the beginning of a section titled 'General Comments': http://jswmm.co.uk/topic/532-jet-set-jason-in-rodd/?do=findComment&comment=11773

This post appears to have a missing part too - it looks like Danny was responding to a quote by himself three days earlier, but all that is left is the original quote:

I wonder whether - for the sake of completeness, and if it doesn't require much effort (and if the data would fit into the game file) - it might be worth inserting the alternate sprites into 'Amoebatrons' Revenge' [and I suppose the different Fire cell/item bitmaps in 'Processing Plant'] for the Software Projects version of the automatic MM? Even though, as far as crem's algorithm can tell, those aspects have no bearing on the maximum achievable score.

Thanks, Andy! However, as you point out, Danny's post dated 15th March 2020 contains a quote from an earlier post in the thread. But that quote doesn't appear in any of the earlier posts in the thread! Which suggests that something is still missing! 😮

Just to be pedantic, I tried the same jump in the BB version of The Warehouse, and that route/jump is possible, but only if you wait for one time-frame (to allow the bulkier 'thresher' guardian) before jumping. And that one frame's delay means that you can only match the best score achievable in BB via the other route.

I've just skimmed through the thread concerning 'Jet Set Jason in Roddenwald' (in the 'Remakes' section). Judging by the number of missing/broken posts in that short(ish) thread, this may be a bigger problem than previously thought! (If that thread is typical of the whole website - hopefully not!?) However, any public (non-Contributor) post/thread prior to January 2020 should be available via the Wayback Machine? So that provides a kind of solution for much of the site's content.

Did we ever get the answer to this puzzle? Was it just the fact that 'embedded Willies' was what you were drawing our attention to? Or was there some other significance/meaning to them? Incidentally, I noticed that a lot of the posts in this thread have fallen foul of the 'missing text' problem that the site has experienced since being moved over to the new format.

Thanks, Andy!

If the info can't be retrieved from archive then it might be available from JSWCentral?

Fair enough, I just thought the tweak I suggested would assist with the clinical analysis to further the aim of improving the maximum MM score, which is the primary purpose of this thread. 🙂 (Actually, crem's primary purpose when he started this thread was to find the fastest MM completion time, which isn't quite the same thing - e.g. avoid killing Kong speeds up the completion but doesn't maximise the score - but in the context of the solar cavern it seems to amount to the same thing, and time spent processing 'air saps' slows down the game at an infinitesimal level!) But in any case, your version (red beam from first contact with Willy under termination) inspired me to create an adjusted version which does what I want it to do (beam red only when in contact with Willy), so everyone's happy! 🙂

I think it'll be a case of us reporting as and when we come across a post that looks truncated in the time ahead. Starting with the following one, which is quite important as it's the head of a topic so a lot of essential information about the file in question appears to be missing (and is also missing from the associated Download page accessed by clicking the 'View File' button): Although if a post is truncated at the end of a sentence or paragraph, it might not always be obvious that anything is missing!

Furthermore, I would humbly point out that the subtlety of where exactly the light beam is causing Willy harm is lost if it is rendered in red from the first point of contact with Willy and then stays red all the way until the beam terminates.

On reflection, the above aspect is potentially confusing, because of the coincidence of the solar beam detecting white INK - causing the air to sap - and the fact that the solar beam is drawn with white INK. (Even though the former - Willy's sprite - is non-BRIGHT white, whereas the beam's INK attribute is BRIGHT white.) A further modification (screenshot attached) helps to provide clarity. This time, the solar beam's INK setting is cyan - the rationale being that Willy is 'blue in the face, gasping for air'! - which applies whether the beam is sapping (red PAPER) or not (yellow PAPER - so it temporarily and harmlessly colours the guardians' INK cyan as well). Note that Willy's INK was still coloured non-BRIGHT yellow 'behind the scenes' by the adjacent guardian (before the solar beam's INK overwrote it in the same frame, this time with BRIGHT cyan) - this went unseen, but you can tell by the fact that his front foot (which falls beyond the reach of the beam as it is deflected away) also falls under the guardian's shadow, and so his front foot is visibly rendered with yellow INK in the screenshot.

The attached screenshot - based on a modified file in which only those characters of the solar beam that are currently sapping Willy's air supply get highlighted in red PAPER - demonstrates that in some circumstances, there can be separate, discrete elements of the beam sapping Willy's air. The intermediate character does not affect the air supply because it falls under the shadow of the adjacent guardian, which changed the INK attribute in the cell holding part of Willy's sprite to non-white (before the Main Loop drew the beam in this frame), therefore that character of the beam is drawn with the regular yellow PAPER/white INK attribute. N.B. It's all a bit academic, as Willy pixel-collided with the guardian and died shortly after the screenshot was taken! 😮😆

And then Norman Sword took the basic concept, refined it, and implemented it in some of the modes of play in Manic Panic.

Yes.

I've noticed it quite a few times actually, but forgot to mention it at the time. Every single post by Zub, for example! (I was searching back through his previous posts for something, and noticed it. But he doesn't seem to visit the site any more, so I didn't prioritise reporting it then.)

Ah, the reason why it's done the way it is, is because if the program were to RETurn to the exit point from the Main Loop, it would then try to draw vertical guardians on top of the Skylabs! So the Skylab code jumps back to a later entry point in the Main Loop, bypassing the CALL to draw regular vertical guardians (as well as the CALLs to draw Kong/the solar beam).

In Manic Miner, the code which deals with Skylabs seems to be arrived at via a JUMP from the Main Loop - unlike all the other guardian routines, which are CALLed. There doesn't seem to be any rational reason for this discrepancy, so a few bytes could perhaps be saved - with a bit of care to ensure the stack pointer is preserved, etc - by changing the status of the Skylab-handling code to a subroutine, with the jump back into the Main Loop replaced with a RET.