IRF

One more thought for now, regarding the new conveyor types that Norman came up with which always enforce sideways movement ("no lockout on falling" in Norman's terminology; "no drop & stop" in mine): If placed in a setting with earth blocks above a narrow channel that is just high enough to fit Willy (such as in the room Tree Root, or the Final Barrier in MM), these conveyors would prevent the player from using the trick of pressing the jump key to bump Willy's head on the ceiling (which on a regular conveyor can slow down or halt Willy's movement down the conveyor, making the timing of avoiding certain guardians much easier). When combined with Norman's 'fast slide' conveyor setting, this could make such scenarios much more challenging!

Incidentally, in the absence of changes to the 'Animate the conveyor' routine, all the types of conveyor discussed in this thread - except for standard left conveyors that have a direction byte value of zero - will have rightwards animation in their top pixel-layer (assuming the pixel pattern allows for visible animation).

Okay, possibly two more types (slow and fast versions respectively): POKE 32982, 130 POKE 32982, 66 My prediction(?): These ones might even have worked using Norman's original code (before I intervened). Edit: These two additional platform types would take the total number of conveyor variants up to 16 14 (FURTHER EDIT: MY LATEST EXPERIMENT DIDN'T WORK, I JUST TRIED OUT THE ABOVE TWO POKES IN TURN - THEY CREATED ANOTHER 'SLOW OFF' & 'FAST OFF' CONVEYOR, IDENTICAL IN BEHAVIOUR TO THE PREVIOUS SLOW & FAST OFF CONVEYORS), which is the maximum number of possible variants using 4 bits of the conveyor byte. Changing the other 4 bits will only create identical behaviour to those 16 14 types of platform. (Caveat: that might not be true if Willy runs over a conveyor during the toilet run, when the ability of the right 'P' key - and that right key alone - to stop the toilet run introduces an additional variable.) FINAL EDIT: The reason why the above didn't work as I had anticipated is this: Norman's code will have briefly set the movement flag, but in the absence of any bits corresponding to left-right movement being reset by a conveyor of this type (and assuming the player isn't pressing a movement key), then the movement flag will be reset shortly afterwards after the left-right movement table (#8421-#8430) is consulted.

There might be one more permutation possible - try POKE 32982, 191.

Thanks! Yes, that works exactly how I anticipated that it would. 🙂 It's an Off Conveyor, but Willy walks along it at double-speed if you press a left-right movement key (thanks to Norman Sword's code which responds to a reset bit 6 of the conveyor direction byte). And he stops moving if you stop pressing the key, even if you're still on the (non-)conveyor. One further quirk is that if you drop onto it from above without a sideways movement key pressed, Willy lands in animation frame 1, not animation frame 0 as usually happens when you drop off a platform onto the next platform below. N.B. As with my previous snapshot file, the effect only lasts until you lose a life/leave & re-enter the room/abandon & restart the game. (If you do one of those whilst playing around with the effect, you have to reload the game file.)

I think I've just come up with another new conveyor type (which also needs the minor tweak that I implemented yesterday to Norman's code to make it work - I replaced the first RET NZ with a JR NZ). A conveyor direction byte value of 11000010. (After the conveyor routine subtracts 3, this becomes 10111111.) I'm not in a position to try this out right now, but if someone wants to load up the 'Conveyor Logic test of new logic' snapshot file that I attached to my previous post, and apply the following POKE whilst Willy is in the Bathroom, they should be able to see it in action: POKE 32982, 194 (If you could then save another snapshot and re-upload, I'd be much obliged.)

Armed with my new understanding of how the conveyor direction bits affect Willy's movement, I've managed to come up with a new pair of conveyor types. Using a conveyor direction byte value of 11000001, and with a minor tweak to Norman's conveyor subroutine, I created a fast-sliding conveyor which otherwise retains the logic of the original JSW conveyors. e.g. you cannot drop down onto a conveyor from above and proceed upstream, but you can 'drop and stop' using the upstream button, and you can turn and stop by walking upstream and releasing the upstream movement key for a single time-frame then pressing it again. Implemented in the attached test file. (NB If you lose a life, or leave the Bathroom and re-enter, or restart the game, then the conveyor will stop working in the above way and you'll have to reload the snapshot file). Conveyor Logic test of new logic.sna

Aha! Cracked it! I was puzzled about this - how a conveyor with direction byte 01111110 would cause Willy to move rightwards if he falls down vertically onto it whilst facing leftwards, without any movement keys being pressed. Surely the fact he was facing left (bit 0 of #85D0 was set before he landed) would mean that leftwards movement would take precedence once the movement flag (bit 1 of #85D0) was set by Norman's code? Why, then does the conveyor turn Willy around to face to the right before moving him rightwards? (Conveyor type 6 in Norman's test file.) But then I realised that, after the conveyor subroutine has subtracted 3 from the direction value, giving 01111011 - BIT 2 IS NOW RESET. And it turns out that the higher bits of the conveyor direction byte (2-5) do actually help to determine Willy's sideways movement, not just bits 0-1. N.B. For a normal right conveyor, value 00000001, subtracting 3 gives 11111110. Only bit 0 reset so Willy moves right. For an Off conveyor, direction value 00000010, subtracting 3 gives 11111111. No bits reset so no movement (unless you press a left-right key). A direction byte of 01111101 would also act as a right conveyor (subtract 3 and you get 01111010 - both bits 0 and 2 reset).

P.S. I subsequently edited my post last night because I thought that I might have identified a typo? I couldn't see how a conveyor direction byte value of db %01111110 could create a right conveyor? The lowest two bits of a right conveyor are usually 01 (so that after subtracting 3, you get 10 in the lowest two bits - Bit 1 set, Bit 0 reset). A conveyor with lowest two bits of 10 is usually an Off Conveyor (because the routine subtracts 3 leaving 11 in the lowest two bits, and no reset bits = no movement)? However, I've just tried POKEing your file in the way that I suggested last night, and it didn't work in the way that I thought it would, so I bow to your knowledge of the way that your code operates. 🙂 P.P.S. I probably came across as pedantic when I suggested certain changes for "neatness and consistency", but that was more about me trying to get my head fully around the subject matter. The point I was trying to make was that the status of bits 2-5 is less critical. EDIT: I was wrong on that point - see my subsequent post.

Norman, I didn't mean to 'troll' or exasperate you. My intention in posting that "I've just noticed that Norman added a code listing to his last post here" was to draw the attention of others to the fact that you had latterly edited your earlier post to add some detail of your conveyor code. If a member goes back and edit an earlier post then there is no notification on this forum that they have done so. Indeed, it was only several days after you had edited the post that I noticed you had done so - I thought it might have escaped the notice of other members as well, so I tried to flag it up. The code you provided in that post (which you have now apparently deleted) was very useful and informative, and I hope that you reinstate it. 🙂

Danny, I seem to recall that you did donate a couple of patches (implemented via the patch vector system) for Jet Set Mini. And if memory serves correctly, you were duly credited in the readme file. 😊

There is one more conveyor logic permutation I can think of. (ie. Two more conveyor types, one L and one R.) Namely fast sliders but for which it IS possible to lock Willy in a stationary position (after falling vertically down onto it with the 'upstream movement' key depressed, or by walking upstream & releasing the 'upstream' key for a single time frame before pressing it again). I think this additional conveyor type could be facilitated (though I haven't tried this yet) by replacing the first RET NZ in Norman's code with a JR NZ that just skips forward past the SET 1, (HL) command. And then the conveyor direction bytes to implement that type of conveyor would be: db %11000000 ;L SLIDE CONVEYOR - LOCKOUT ON FALLING Subtract 3 and you get 10111101 (bit 1 reset so it's a left conveyor; bit 6 reset causes fast sliding; bit 7 set means horizontal movement isn't automatically switched on if he falls onto it vertically) db %11000001 ;R SLIDE CONVEYOR - LOCKOUT ON FALLING Subtract 3 and you get 10111110 (bit 0 reset so it's a right conveyor; bit 6 reset causes fast sliding; bit 7 set means horizontal movement isn't automatically switched on if he falls onto it vertically)

I've just noticed that Norman added a code listing to his last post here. Conveyor types are differentiated by testing various bits of the conveyor direction byte. FURTHER EDIT: Everything below this point was incorrect, based on a fundamental misunderstanding on my part. Apologies to Norman for doubting him! Edit: Although I believe there may be an error in this entry: db %01111110 ;R STANDARD CONVEYOR - BUT NO LOCKOUT ON FALLING To make a right moving conveyor, that should read(?): db %01111101 ;R STANDARD CONVEYOR - BUT NO LOCKOUT ON FALLING Also, I suppose that for neatness and consistency between L and R conveyors of the same category, these ones: db %00111000 ;L SLIDE CONVEYOR db %01111000 ;L STANDARD CONVEYOR - BUT NO LOCKOUT ON FALLING Would be better as: db %00111100 ;L SLIDE CONVEYOR db %01111100 ;L STANDARD CONVEYOR - BUT NO LOCKOUT ON FALLING (Though those changes wouldn't make any difference in practice.)

That's a good idea Danny! I would make it my first priority (time permitting) to provide an explanation of how I managed to create the trampoline in Jet Set Mini (and not just any old trampoline - one which allows you to fall from a ridiculous height and land on it safely!)

You obviously haven't explored the full mansion of Jet Set Mini yet... 😉😎

Now I'm really confused! East Wall is the 'classic' name for it, and I renamed it the West Wall here! The bird flying along at the bottom of the Priest's Hole (top room of the West Wal) slightly 'wraps around' beyond the bottom of the room. This causes it to imprint a few of its pixels permanently (well, until the room is refreshed when Willy dies or re-enters) onto one of the screen buffers - they appear along the very top of the room as the bird tracks along, but they are dark blue INK against the black PAPER background, so they're not easy to spot. When the bird returns back to the same place after one complete traverse of its horizontal range, it collides with that 'shadow' of itself, which has the effect of killing Willy. That effectively imposes a limit on how much time you can spend in that room in one go. In order to safely navigate the room, you have to leave and re-enter a few times (which resets the bird to its starting position and clears the buffer of those errant pixels). That's why I created that exit to the Emergency Generator halfway up so you can pop out and back in again (otherwise the game would be impossible to complete!)

Since Sendy is relatively new here, I thought I should point out something that sometimes happens on this forum: last night I posted twice in succession in this thread, both in response to Sendy, but the two posts ended up on different pages. You may (based on your likes) have only seen the most recent one and missed the post at the bottom of page 2 of the thread? (Not that I said anything particularly crucial in that post; I just thought I'd point out this potential pitfall of posting here. 😊)

I also credited Geoff for some of his patches in the readme for Jet Set Mini (and for coming up with Patch Vector system, along with John Elliott who expanded the concept by creating different categories: Room Setup PV, Main Loop PV and (in Manic Miner games) Portal Patch Vectors).

Ah, I think you're talking about the floor conveyor in the Dr Jones ('elephant') room when you talk about Willy changing direction on a conveyor. That's not a sticky conveyor, just a standard one but the direction is toggled on a timer. The ice platform is in the Cold Store, between the Kitchen and the Back Stairway.

Cold Store conveyor isn't the floor but the platform just below the bottom of the rope. At one point in Danny's walk through he catches the end of the rope and immediately drops off again, which interrupts his sideways motion - is that what you mean? Camel room = Elephant room?? East Wall is now the West Wall in this laterally-inverted game. 😉 I don't think that's why you're dying at the top of the West Wall - there is a time limit imposed though, via a quirky feature of the game engine. So you have to pop in and out to reset the room in order to progress up to the top exit.

A 'medium friction' platform as you describe would indeed be a novelty (well, it's kind of like the JSW: Perpetual Motion mod, but only applied to a specific type of platform not the whole game). However, that isn't how that ice platform in Jet Set Mini behaves! It is essentially a non-sticky Sticky Conveyor, as discussed earlier. I think you might have mistaken all the platforms in that room for conveyors, whereas in fact there is only one in the room (the long one across the centre). (If so, it highlights the perils of trying to figure out what is going on by watching a pre-recorded run-through, rather than playing the game yourself!)

Geoff's recent(ish) game Willy does the Great Pyramid has an interesting (and apt) logic for connecting rooms vertically.

If you like that, then you'll probably like the Room Setup Patch I implemented in the Swimming Pool in Jet Set Mini (where that room is known as 'Pool Party'). Upon Willy's entry to the room, his x-coordinate is inspected, and the initial swing direction of the rope is set accordingly. This means that if he falls down from The Orangery into the left half of the Swimming Pool, the rope starts off swinging leftwards; if he falls down from the right half of The Orangery then the rope starts swinging rightwards. Either way it catches Willy, and there is no Infinite Death Scenario (such as occurs if you drop down on the wrong side of the rope in original JSW). In fact, in an attempt to showcase this neat little fix, I designed the layout in such as way that you have to drop down on both sides of the rope in order to be able to collect all the Orangery items safely. 😉

There could be a way round* those design considerations - by using the WRITETYPER keys to teleport into the room at a position that is a (safe) drop above one of the conveyors, Willy might end up stuck on one of them even it isn't possible to manoeuvre into such a situation within the room. (*Done at the player's own risk - and of course they could always teleport back out again!)

Hello Sendy, sorry for not welcoming you here sooner - before doing so I wanted to dig out, by way of a welcome, the following quote from the readme file for a game called 'Jet Set Mini' that Andy (Spider the site moderator) and I created a few years back. In amongst the credits for the game, it says this: "- Alex Cornhill ('Sendy'), for unwittingly inspiring ideas for new block types, in messages posted on the Manic Miner & Jet Set Willy Yahoo! Group more than a decade ago!" Due to the passage of time (and the unavailability of the Yahoo! Group, other than as a compressed backup file that I don't have to hand right now), I can't remember the full details of what I was referring to there. However, the 'Kitchen's Cold Store' room has - appropriately enough - an ice platform similar to the one that you initiated a discussion on elsewhere in this forum recently. (Albeit executed differently - a Main Loop Patch, implemented via the Patch Vector system, constantly updates the Conveyor Direction Byte in that room so that the conveyor flow direction always matches Willy's current facing direction. This means that he never gets stuck on the spot, as he's always facing either left or right.) And there's also a crumbly ramp somewhere in the game. Those might be two of the examples of "new block types" that you might have "unwittingly inspired" me to create for 'Jet Set Mini'. (That game is also packed with lots of other special effects thanks to the Patch Vector system, so I humbly suggest you check it out - it's available to download from the 'jswmm releases' section of the Downloads tab at the top of this forum. 😀 ) **** By the way, I was a member of the Yahoo! club towards the end of its existence (about 90% of the last hundred or so messages on there were from me), but that was probably after you had (temporarily) diverted your interests elsewhere. (But you might have noticed auto-generated emails from me appearing in your email inbox as a result of those posts!)