Playing around.

[IRF]

I've noticed a glitch with the way that the torch beam works.

 

Say Willy is standing still, facing rightwards.  If you nudge the Left key once, to turn Willy around, his beam still points rightwards.  Only if you nudge Left again to make Willy walk one pace leftwards does his torch beam turn round to match his leftwards facing direction.

 

(And vice versa.)

[Norman Sword]

The beam follows movement. Not direction. I can see how that would be interpreted as a glitch. If static then the direction is whatever you want it to be.

[IRF]

The beam follows movement. Not direction. I can see how that would be interpreted as a glitch. If static then the direction is whatever you want it to be.

 

I noticed it when doing a certain manoeuvre to collect the item on the right, halfway up the Central Cavern-style room - jump right off the crumblies, then before landing hit left+jump to perform a 'turnaround and jump straight up' to collect the overhead item, before proceeding to jump left onto the conveyor (and then onwards to the spiky bushes/clockwork robot, etc).

 

I was expecting the beam to turn around at the moment Willy turned around, but because he does a vertical jump to get the item, during which he isn't actually moving leftwards yet, he was left facing into the blackness before I nudged him left.  If that doesn't make sense I could do a quick RZX recording to illustrate.

[Norman Sword]

Easy enough for me to change---- would not be an instant change, only because of the number of steps needed to create a working version. As opposed to an assembly download.

 

 

I will force the direction when jumping. Which is not done now.

 

 

Changed.

Still allows willy to turn on the spot without changing the direction of the beam. But the instance of jumping will change the beam direction immediately

 

Changed again.

 

Any change in willies status will change the beam to face, whichever direction he faces.

 

so on the spot static movement, but a change in direction will automatically rotate the beam to follow the new direction.

 

 

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

 

Final game version accessible via  This Link

Edited July 20, 2020 by Norman Sword

[IRF]

Will the latest change mean that if Willy points the beam straight upwards, then does a vertical jump, the beam will still point straight upwards?

 

Because in that circumstance - if you're trying to inspect what is located a few character rows above Willy - you wouldn't necessarily want the beam to automatically align left or right to match Willy's facing direction.

 

Sorry if I'm being picky!

[Norman Sword]

Therefore it is not the jumping that is causing the problem. (can remove that new check) but the static direction change. - 1 min and I can see what that does.

 

 

Removed the jumping check

 

By only checking for changes in Willies movement status. The instance of landing and turning around will switch the beam

 

static turn around will switch the beam.

 

Jumping directly upward will not switch the beam.

 

jumping sideways which has movement will switch the beam.

 

 

 

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

 

Final game version accessible via  This Link

Edited July 20, 2020 by Norman Sword

[IRF]

Perfect!

 

Hopefully also means that when falling from a great height into the portal in Return of Kong, you can turn the beam mid-fall to point it towards the portal. (Whereas in the previous version, with the additional check for the airborne status, the beam might have stubbornly reverted to point sideways?)

[Norman Sword]

Return of Kong

 

 

Tried the above  kong fall. The beam stays pointing sideways on the fall. - I will look at again later - after I have watched a film. 

 

 

Intermission on film:-

 

 

I suspect a similar reason to the fact that the mechanics do not permit Willy to change face direction on fall. no matter how far he falls. Think Jet Set willy and the leap from the top of the building.

Getting complicated to insert code to check if falling and at max fall value. Then permit beam rotate.....Airborne=6 when on a long descent 

 

I added a check for Airborne =6, (which happens on max fall) and permitted beam rotate. Need super fast reflexes to point the beam on fall. If I was to do these checks then it would make more sense to do a force of the beam to point downwards whenever willy is on maximum fall speed. i.e. when Airborne=6. the beam points downward.... I will set up a series of screen/border flags to indicate game wise when Airborne =6. To clarify to myself if this only happens on max fall. and if so. Force the beam to point downward. If too convoluted - I wont bother.

Without even adding any code - I can already see problems. 

 

 

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

 

 

Whilst it works checking for the fall value of 6, which forces willy  to look down works.. It negates the ability to look upward. Jumping on the spot will keep on re setting the beam to look downward on every landing.

 

To counter that you need to set automatic upward facing beams. And whilst at it, carry on and angle the beam depending on the arc of travel......

 

Whilst I probably could do all of the above...I wont. This was supposed to be a quick addendum, which supposedly stopped at version 4.

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

 

 

 

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

 

Final game version accessible via  This Link

Edited July 20, 2020 by Norman Sword

[IRF]

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

Edited July 14, 2020 by IRF

[Norman Sword]

Without looking at code. The conveyor problem could probably be implemented by looking at the keycode values. I.e. the routine for movement generates a composite value for keypresses.

A conveyor effectively presses a key. If the opposite key is pressed then we have a null situation. The movement action treats a null situation as a continuation of previous movement. If I read the keycode value and not the movement value of willy. Then it would be possible to treat a conveyor movement as a static movement. 

Something I will not do - I stopped at version 4. 



 

Edited July 14, 2020 by Norman Sword