IRF

It's here: http://jswmm.co.uk/topic/518-file-jsw128vm/ Once you're on the title screen, if you press 'O' then you get an options screen which allows you to change a LOT of things about the game - the ability for Willy to shoot a gun or a bow&arrow is just one of many new features...

I've just discovered the excellent set of accompanying notes (in PDF format) which Norman Sword added to the first post in this thread, via a subsequent edit a few days after the original post.

One of Norman Sword's working files, posted here on this forum, gives Willy a Licence to Kill...

Hint: they are based on real-world phenomena. Maybe it's too difficult... Look at them closely; what are they? Hope you feel better soon Fabian. But on a related note, and in response to the above quote, I haven't seen the guardians in question yet but I'm going to take a wild guess that the "real-world phenomenon" they are based on is the Coronavirus?

Congratulations, Danny! And Fabian, it's a great game!

There is a potential flaw in the JSW128 game engine (or at least in John Elliott's explanatory notes for the engine). Whilst the original guardian class table (#A000-#A3FF) provides a #FF Terminator byte at the address #A3F8, if you create further guardian class tables then another #FF Terminator byte needs to be inserted at the start of the final 8-byte entry of the additional tables. e.g. - If you create an additional guardian class table across pages #D8-DB of memory, then an #FF value needs to be inserted at address #DBF8. If you don't do that, and if the first entry of the additional table has a defined guardian (i.e. of Class #00), then there is a risk that the code which populates the guardian buffer (#8922-#8949) will cause errant Class #00 guardians to appear in any room* that uses the additional guardian class table, with potentially disastrous consequences! (*Unless said room has a full complement of eight guardians, or unless the structure 'FF 00 FF 00 FF 00 etc' is used to terminate a less-populated room's guardian list, instead of 'FF 00 00 00 00 00 etc'.) The explanatory notes for the JSW128 game engine should alert the game designer of the need to include a #FF Terminator byte at the start of the last slot in every guardian table (unless the editor could be made to automatically insert the Terminator byte whenever a new guardian table is created). ** EDIT: A similar bug afflicts the Softricks Edition of JSW - for the same reason, there should be an #FF byte at address #A7F8 (corresponding to the start of the last entry in the double-length guardian class table in the Softricks engine), but it seems that there isn't. ** FURTHER EDIT: There is also a glitch in JSWED, whereby if a room has a full complement of eight guardians, and if you delete one of them in JSWED's GUI [other than the last one in the list] and then navigate away from that room in the GUI before replacing the guardian that you've just deleted, then a guardian of class #00 (if guardian class #00 has been defined) appears at the left-hand side of the room when you play the game, due to the failure of JSWED to write a 'Terminator' byte into the guardian list for that room. I guess what happens is that, in general, when you delete a guardian from an early slot in the guardian instance list (guardians are listed as pairs of values in Offsets #F0-#FF in the room definition), then the later entries get shuffled up to fill the gap. If there were fewer than eight guardians then there will be an #FF Terminator byte at one of the even addresses in the range of Offsets #F0-#FF, and it will gets shuffled up as well. But if there were a full complement of eight guardians prior to the deletion of one of them, then seemingly Offsets #FE-FF for the room are just NOPped out, and this is interpreted as an instance of Guardian Class #00 in the room (with a horizontal coordinate of 00).

I can change the CC robot sprite now (in V6b).

On V6, for me for some reason, I can change the colour of the horizontal robot in Central Cavern, and I can toggle it between 4-frame and 8-frame versions when the background colour behind the +/- symbol is blue. But I can't select a different sprite for the Central Cavern robot. :unsure: :wacko:

Ah, I've just seen the notes, and discovered the use of the 'P' key for toggling between 4 and 8 frames for horizontals guardians. The flaw you've discussed probably explains why I can't seem to change the sprites for some of the guardians.

I just noticed that a V6 has been uploaded (attached to post 1 in this thread). I'm not sure what the difference is with it, but I tried to change a guardian's sprite, failed to do so, but ended up with it walking backwards! Oh, and a big red number '5' appears now when the editor is viewed in 'guardians moving' mode. (I'm not sure what the '5' signifies?)

I left a big clue in post 17 of this thread. ;)

I cracked the cheat code a while ago, as you know (but kept it under my hat). Daniel was halfway to cracking it when he started this thread. Then he got distracted by another project whose release is imminent - after which he should be able to resume work on this puzzle...

Welcome, Fabian! I was recently introduced to your JSW games - I've been helping Jetsetdanny out with his project to convert your 'Madam Blavskja's Carnival Macabre' to the 48K game engine. It's a nice, very atmospheric game. ?

I'll save my congratulations until it's released! ;-)

Nice touch in V5 to make the border colour match/indicate the selected guardian colour. :)

Fair enough. Presumably with horizontal guardians it would be more difficult to store the colour, because the 'speed' bit for HGs shares a byte. Vertical guardians just have a single byte dedicated to the attribute. (That's assuming that the guardian data storage may be as it is in original MM; yours may be compressed?)

I tried editing the guardian in V4. I managed to successfully change the sprites for a guardian (i.e. the pixel pattern which is drawn), and that change persisted once I left the editor. I could also change the colours of guardians within the editor, but when I went to exit the editor and play the game, the colours reverted. So for example, in Central Cavern you can have a yellow penguin replacing the yellow robot patrolling along the green conveyor. But you can't change that to a red penguin (well, you can in the editor but not in the game itself).

It's nice to be able to place Willy and the portal in the editor. :) Minor typo in the file name of the latest version: "Manic 49 Miner". ("Wine me, Mine me, 49 me"?! :P )

Out of curiosity, if there is currently a key which toggles between 'Face Willy left at the start' and 'Face Willy right', could it easily be extended so that the same key progresses Willy's initial frame of animation through all eight possible options (four left-facing, four right-facing)? Or would that require too much additional code?

It's definitely appropriate in Manic Miner, where as well as many of them (though not all) being key-shaped, they do actually 'unlock' the portals. In Jet Set Willy, bottle or rubbish or detritus may be more applicable, since he's 'tidying up'.

On a technical level, Bit 4 of the lower byte of Willy's attribute coordinates is tested on entry to the room, and the result applied to Bit 7 of the first byte of the rope definition.

Or you could use 'O' for Objects. That isn't used for another purpose is it? (Except as part of the ZHO key combination - out of interest, is there any deep meaning to that combo?)

Danny, further to the above, I would point out that correcting your error will mean that there are an odd number of data points in the above table. So bear that in mind - "when a convenient time presents itself" - as you contemplate

Slight confusion between references to keys for keypresses on the keyboard, and also for collectable items (not all of which are key-shaped. e.g. Snowshoes, bananas are also collectable)you in some caverns). But I can see that the INK parameter needs to take precedence for use of the letter 'I' on the keyboard. Anyway, the ability to edit the placement and form of the collectable keys/items in each cavern is a welcome addition to the editor. :) ** I previously misunderstood the purpose of the 'graphic trail' mode; I tried in vain to find a key combo which allowed me to edit the parameters of the guardians. But I can see the benefit of displaying the range of the guardians' paths, so that when placing room tiles you can avoid a collision between the two.