Jump to content


IRF

Member Since 23 Aug 2015
Online Last Active Jul 16 2020 05:19 PM
-----

Posts I've Made

In Topic: Playing around.

15 July 2020 - 01:31 PM

Question: in Eugene's Lair, why when I first enter the cavern is the vertical Amoebatron colour-cycling (as if it is an 'Angry Eugene', although it doesn't settle down directly above the portal in the way Angry Eugene does), but then if I lose a life and the cavern is refreshed, the Amoebatron stops colour-cycling and remains cyan (until such time that all the items have been collected, at which point the colour cycling kicks in again and it descends to guard the portal as you would expect)?

 

Regarding the above oddity, I've been back and checked and that was the case in the earlier Manic Panic files as well, I just didn't notice it at the time.

 

****

 

Back on the subject of rotating the torch beam, if Willy finds himself on a conveyor belt standing still (e.g. if you fall onto a conveyor whilst keeping the 'upstream' sideways movement key depressed, so the keypress and the conveyor cancel each other out), are the rotate keys active whilst Willy remains stationary on the conveyor?

 

I presume the answer is yes, because the sideways movement flag isn't set in that situation, even though a Left-Right movement key is being pressed by the player.


In Topic: Playing around.

15 July 2020 - 09:45 AM

Question: in Eugene's Lair, why when I first enter the cavern is the vertical Amoebatron colour-cycling (as if it is an 'Angry Eugene', although it doesn't settle down directly above the portal in the way Angry Eugene does), but then if I lose a life and the cavern is refreshed, the Amoebatron stops colour-cycling and remains cyan (until such time that all the items have been collected, at which point the colour cycling kicks in again and it descends to guard the portal as you would expect)?


In Topic: Playing around.

15 July 2020 - 09:36 AM

My replies in red:

 

Removing most of the checks and leaving just two checks. On the same condition.

 

1) if a change in movement status. Then direct beam. this detects change of face direction. when static.

 

2) If moving left or right then direct beam.

 

Don't both of those relate to the same variable? i.e. different bits of the same byte?  If so, could it be done via a single check, rather that two?

 

-------------------------------------------------------

 

In the spiral room. Beam can be rotated downwards as willy falls. Beam can be rotated upwards as willy climbs

 

In the Eyeball room beam can be rotated as the floors collapse, or as you climb vertically

 

Those are better examples of where the ability to direct the beam up or down would be useful!  The example I gave of dropping into the flashing portal in Return of Kong is a bit of a 'fall of faith', because I believe the torch beam doesn't extend far enough to be useful for avoiding hitting the 'rolling rock' guardian which traverses past the portal - you can't tell where the rock is until you have already fallen down a few rows, by which time it's too late to do anything if you are on course to hit it!

 

------------------------------------------------------

 

 

Airborne status is set to 6 when starting a fall. This is the point at which which forward movement is stopped and willy falls vertically.
 

Incidentally, the reason for the value 6, I think, is so that the pitch of the falling noise transitions smoothly from the jumping arc to the falling sequence.

EDIT: Also, so that the fatal fall distance is the same regardless of whether you descend from the apex of a jump, or whether you just walk off a ledge.


In Topic: Playing around.

14 July 2020 - 11:45 PM

To be clear, I wasn't suggesting that Willy should automatically look downwards when he falls down a shaft.  I just wondered whether the player retains the ability to rotate the torch beam whilst he is falling.

 

I would have expected that this would not be possible in your earlier test file (described in post #164 of this thread), where you had forced the beam to face forwards based on Willy's facing direction AND based on his jump/fall counter*.

 

But I would have expected that it would be possible to look down whilst falling in the later test file (described in post #166), where you only tested Willy's facing direction and not the jump/fall counter to decide whether to force a sideways beam.  It sounds like you have proved me wrong on that point?

 

 

(*Actually, there are two separate variables involved in jumping.  There is a joint variable for Airborne Status, which is reset to 00 by default, holds 01 when jumping, values from 02 upwards when falling - acting as a Fall Counter - and is set to -01 [#FF] as a 'Willy is dead' indicator.  And a separate Jump Counter variable which keeps track of Willy's progress through a jump.  I presume the former is the one that we're talking about in terms of what you were testing at one stage, to determine whether to make the torch beam face forwards?) 


In Topic: Playing around.

14 July 2020 - 08:39 PM

It is also not possible to look all around whilst Willy is being moved along by a conveyor, where you might expect* him to be able to do so.  That would probably require a fundamental change in logic, with the check for Left-Right keypresses temporarily disabling the check for Clockwise-Anticlockwise keypresses. i.e. the basis for being unable to rotate the lamp wouldn't be "Is Willy moving sideways?", but "Is the player actively moving Willy sideways?"

 

(*Then again, logic would dictate that his legs shouldn't animate in that scenario either, as you pointed out elsewhere a while ago.)