Creating slippery "Ice" platforms

[IRF]

On 1/31/2023 at 10:00 PM, IRF said:

sticky_patch:
    sub    3        ;2
    cp    -4        ;4
    ld    e,a        ;5
    ret    nz        ;6
    ld    hl,willy_dir)     ;9      L85D0
    RES    1,(hl)        ;11
    ret               ;12

The above (note the RESET in capitals, replacing Norman's SET command) would turn the conveyor into a proper 'flypaper' platform, stopping Willy's horizontal motion even if he is moving sideways when he steps (or jumps sideways) onto the conveyor. 

EDIT: Although for the full flypaper effect, it should also turn off the functionality of the jump keys!

Edited February 2, 2023 by IRF

[IRF]

13 hours ago, IRF said:

Norman, in respect of your more advanced code, having studied it but not tried it out yet, my guess is that it has the effect that whenever Willy jumps or falls vertically onto such a conveyor, it turns him round and then conveys him in the opposite direction to the way he was facing before he landed on the conveyor. Am I right?

On second thoughts, does it set the jump flag (turning the conveyor into a trampoline)? 

[IRF]

4 hours ago, IRF said:

On second thoughts, does it set the jump flag (turning the conveyor into a trampoline)? 

No, that's not it. Hopefully third time lucky - does it cause the conveyor to pull Willy along without him having to move his legs? (Which is a more logical way that the conveyors should work!) 

If I'm right, it would also mean that his skids across the ice at twice his normal walking speed. 

Edited February 1, 2023 by IRF

[Sendy The Endless]

Someone's gonna have to try the patch(es) and experiment : ) I will give it a go soon.

Ideally an ice platform would, in the case of no horizontal momentum, move him in his last moved direction. From a designer's point of view, that would be best for puzzles and wotnot.

As for the truely sticky conveyor, I've only found one use for it that isn't just a cruel trap. You get stuck to it and have to survive enemies until an invalid arrow eventually erases it from under your feet. I used this in Strangel, and thought it was pretty nifty at the time.

Edited February 1, 2023 by Sendy The Endless
Grammar is importantly to I

[IRF]

I'm now convinced that it (the Ice Patch) will do what I suggested in my third guess (although I still haven't tried it out yet).  Kind of like the toilet run, but it will work in both directions (going left or right) on a conveyor that has the appropriate setting.

Incidentally, I'm convinced that Matthew made a boo-boo in implementing the toilet run.  I think he intended to use the 'legs together' and 'legs fully apart' frames of animation during that sequence*, so that it really does look like he's running for the toilet to throw up (the hangover having fully kicked in at that point!)  Rather than using the two intermediate 'legs slightly' apart animation frames, which makes it look like he isn't moving his legs at all but is somehow being pulled by an invisible force towards the bog...

(*I once figured out a way to change the code so that this happens instead, and it really does look like he's sprinting.)

[Norman Sword]

Deleted 
 

 

Edited February 8, 2023 by Norman Sword

[IRF]

I guess the 'mission' in each Bathroom variant of Norman's test file is to collect the tap and then exit top-left without dying?

(Might not be possible for every conveyor type?)

Edited February 2, 2023 by IRF

[IRF]

Here are my observations after investigating Norman's 'Conveyor logic' test file:

Firstly, I agree that the escalator in First Landing is cool!

The Bathroom (aka 'Plumbing Mess'): It is possible to complete the room with all conveyor types.  With Type 3, it can ONLY be completed (without losing a life) by exiting the room via the top-left exit.

Analysis of conveyor types (based on the number that appears in blue INK at the bottom-right of the status bar):

Type 0 - I can't see any difference between this and Type 2 (see below), they appear to have identical behaviour.

Type 1 - Willy is conveyed forwards (i.e. in the same direction as he was facing beforehand), slowly (i.e. at the regular walking speed), it is not possible to 'drop and stop' (i.e. drop vertically down onto the conveyor from above and then arrest forward motion by pressing the opposite sideways key to the way he is facing).  This is a two-way conveyor with Norman's original patch to eliminate the 'sticky' behaviour.

Type 2 - Willy is conveyed forwards, at a fast pace (using only two of the four available frames of animation), no drop & stop.  This one uses Norman's Ice Patch, eliminating 'sticky' behaviour with fast motion (and no apparent motion by Willy because the two frames of Willy used are identical apart from their horizontal positioning). (Presumably Types 1 and 2 are differentiated via a CP command to check the Conveyor direction byte?)

Type 3 - Willy is conveyed forwards, slowly, if he jumps (or walks) sideways onto the conveyor, but gets stuck if he drops or jumps vertically onto it.  This is therefore the same as what has commonly been used/known as a 'sticky conveyor'.

Type 4 - Willy is conveyed rightwards, quickly (using two animation frames), unless he is facing leftwards with the left movement key pressed when he lands on the conveyor.  It is not possible to drop & stop (i.e. drop vertically down on to the conveyor whilst facing 'upstream' - in this case leftwards - with the Left key pressed), or to turn & stop (i.e. walk 'upstream' - in this case leftwards - then stop pressing the Left key for a single time-frame and then resume pressing Left), in order to remain at a fixed position on the conveyor.

Type 5 - Willy is conveyed rightwards, slowly (standard speed), unless the left key is pressed and he has leftwards momentum when he lands on the conveyor.  The 'drop & stop' / 'turn & stop' manoeuvres are possible on this one.  I think this is basically a standard Right Conveyor as per original JSW (Conveyor direction byte = 01).

Type 6 - Same as Type 4 but with slow movement (using all four animation frames).  The change between Type 4 and Type 6 is analogous to (and presumably done in a similar manner to) the change between Type 1 and Type 2 (i.e. to toggle the slow/fast conveyor action). Both Type 4 and Type 6 are variations on Right conveyors - has some other patch been applied to the Move Willy code to implement these?  (Perhaps another CP command in the called subroutine, to check for another fixed value for the conveyor direction byte?)

Type 7 - An Off Conveyor, with no conveyor qualities at all (except perhaps animation of the first and third pixel-rows, if that were possible to see, which it isn't in this room).  Conveyor direction byte is set to 02 (so that after subtracting 3, both bits 0 and 1 are set - one of those bits being reset is what drives Willy's sideways movement).

Edited February 3, 2023 by IRF

[IRF]

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.) 

Edited February 8, 2023 by IRF

[IRF]

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)

Edited February 8, 2023 by IRF
To get the correct values that will make this new type of conveyor work as predicted