Playing around.

[Norman Sword]

Played a few screens, with the particular interest in what the conveyors do in candle mode

I encountered the static conveyor problem, which is not the same as mentioned elsewhere. (but similar to)

 

In cavern/room 3 there are two low conveyors. The first one that can be jumped on is the conveyor on the lower right. If I press and hold the right movement key and jump onto the conveyor. The wall on the far right will stop my progress. The conveyor is trying to move me left. Here we have a static condition. But the oxygen will still deplete and we can not rotate the beam.

I changed the basic code and changed what was being examined for static conditions to be met. Simple enough change, which also needed the drawing of Willy to also be very slightly changed.  Just a re-order of the code which calculates  the sprite definition to be drawn. The changes in code seemed to do the trick.

The next problem was how the static condition was handled by the oxygen/timer. The new problem was caused by the sequence of updates in the code. The timer needed to be updated after Willy had moved, instead of before as was originally coded. Again a simple enough change.

 

With the above changes. The actions of Willy on a conveyor are handled differently.

 

 

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

 

 

Jumping in cavern/room 3 onto the right lower conveyor and keeping the right keys pressed. When willy hits the wall and his animation stops.

With the above change. --- The clock stops and Willy can rotate the beam.

 

Does this merit another update ? - 

A version mp_V13.tap is added to mp_V12.tap

 

 

accessible via This Link

 

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

 

 

I probably need to start some other code - and not play this game more or even read the source code.

 

Most of the update I have done recently, stem from just editing the code layout to make it look neater. This entails doing global name changes, making all tabs and all comments line up exactly in the same column. etc Something that does not happen when the code is being written. However this does often alert me to things I can do with already written code. I might be re-reading a piece of code written a few week ago. looking at it afresh will sometimes trigger a response in me, of  how I could re-write a sequence to be faster or smaller. This  re-reading code, can end up as large re-writes of code. 

 

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

 

Addendum to the comment above... The lining up of comments, tabs code etc, is actually done by another program I wrote. Its purpose being just to standardise the look of the code. It takes my source code and re-formats into the look I want.

Edited July 20, 2020 by Norman Sword

[Spider]

Thank you again for the updates! :thumbsup:

 

For anyone generally who cannot find an attachment in a topic, there is an easy way to do this:

 

View the forum not the topic and click on the paperclip icon to bring up a small popup (with scrollbar) containing all that topic's attachments as well as a link to the post in question if required on the right hand side of it:

 

 

Its not brilliantly styled however it "does the job" :)

 

For your own attachments, a few months ago I added a "My Attachments" link to the usermenu (top right) to save having to go through the user control panel to get to that page.

[IRF]

Played a few screens, with the particular interest in what the conveyors do in candle mode

 

I encountered the static conveyor problem, which is not the same as mentioned elsewhere. (but similar to)

 

In cavern/room 3 there are two low conveyors. The first one that can be jumped on is the conveyor on the lower right. If I press and hold the right movement key and jump onto the conveyor. The wall on the far right will stop my progress. The conveyor is trying to move me left. Here we have a static condition. But the oxygen will still deplete and we can not rotate the beam.

 

I changed the basic code and changed what was being examined for static conditions to be met. Simple enough change, which also needed the drawing of Willy to also be very slightly changed.  Just a re-order of the code which calculates  the sprite definition to be drawn. The changes in code seemed to do the trick.

 

The next problem was how the static condition was handled by the oxygen/timer. The new problem was caused by the sequence of updates in the code. The timer needed to be updated after Willy had moved, instead of before as was originally coded. Again a simple enough change.

 

With the above changes. The actions of Willy on a conveyor are handled differently.

 

 

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

 

 

Jumping in cavern/room 3 onto the right lower conveyor and keeping the right keys pressed. When willy hits the wall and his animation stops.

 

With the above change. --- The clock stops and Willy can rotate the beam.

 

Does this merit another update ? - 

 

A version mp_V13.tap is added to mp_V12.tap

 

 

accessible via This Link

 

 

If Willy is trying to walk up a conveyor but is stopped by a wall, he is technically still moving sideways (the Movement Flag is set).  As distinct from when he jumps or falls vertically onto a conveyor with the 'upstream' key kept pressed, or when he does a 'turn around on the spot' manoeuvre on a conveyor.

 

The attached recording was done whilst playing MP12 in Candle Mode.  The first time Willy is on the conveyor, with the Right key depressed but up against a wall, I tried to rotate the torch beam using H-J but failed.  Then I let go of the Right key and immediately pressed it again (then kept it depressed).  Willy turns round on the spot and stays put.  This time I could rotate the beam using H-J keys.  I then made Willy fall onto the conveyor with the Right key depressed, and again I could rotate the beam.  A bit later in the recording I jumped vertically up onto another conveyor, with the Right [upstream] key depressed, and once again I could rotate the beam.

 

It's good that you have resolved the discrepancy between the different scenarios, in MP13.  :)

MP12 Conveyor Torch Rotation.rzx

Edited July 20, 2020 by IRF

[IRF]

One more short recording, to demonstrate a (harmless) visual quirk I noticed in Torch Mode. See the conveyor above Willy's head when the torch beam is rotated to certain angles. Some portions of the conveyor seem to be colour-inverted compared with the rest of the conveyor. I think this is because the normal colour setting for the conveyor in question is black INK on blue PAPER, but in Torch Mode everything that isn't lit up by the torch beam is rendered in blue INK on black PAPER.

MP12 Conveyor Animation.rzx

Edited July 20, 2020 by IRF

[IRF]

If Willy is trying to walk up a conveyor but is stopped by a wall, he is technically still moving sideways (the Movement Flag is set).  As distinct from when he jumps or falls vertically onto a conveyor with the 'upstream' key kept pressed, or when he does a 'turn around on the spot' manoeuvre on a conveyor.

 

The attached recording was done whilst playing MP12 in Candle Mode.  The first time Willy is on the conveyor, with the Right key depressed but up against a wall, I tried to rotate the torch beam using H-J but failed.  Then I let go of the Right key and immediately pressed it again (then kept it depressed).  Willy turns round on the spot and stays put.  This time I could rotate the beam using H-J keys.  I then made Willy fall onto the conveyor with the Right key depressed, and again I could rotate the beam.  A bit later in the recording I jumped vertically up onto another conveyor, with the Right [upstream] key depressed, and once again I could rotate the beam.

 

 

I forgot to say that the question of whether or not the air supply depletion is paused (because Willy isn't moving), in the recording referred to above, follows the same pattern. i.e. Air continues to be depleted when Willy is only prevented from moving because he is blocked by a wall, but isn't depleted in all the other scenarios: when Willy turns on the spot, or jumps or drops vertically onto a conveyor whilst the 'upstream' key is pressed.

 

Again, the discrepancy has been resolved in MP13.

Edited July 20, 2020 by IRF

[Norman Sword]

Not something I will look into. Black on blue turned into blue on black. The alternative being - Black on black.  No matter what is checked there is no alternative where the paper is black. 

 

 

I set out to do a quick interpretation of the original code and extend it.. That code took around two days to do. The added code checking I have done since  was to increase its play ability. Something I regret doing, it was a path that I added onto the code, that I still have misgivings about. The quirks will come thick and fast. I already know of several others. Cast you mind back to JSW and MM in their original guise and count the dozens of quirks they exhibit. How many years have you personally spent trying to correct them?  

The code I have written will exhibit lots of strange traits. Most of which I will not even attempt to change.

[IRF]

I wasn't suggesting anything needed changing with the blue conveyor, just thought it was worthy of a mention.

 

As you say, it would be impossible to iron out every logical inconsistency. Another example: in the attached image, it could be argued that the red crumbly cells at the top right shouldn't be illuminated by the torch, considering that Willy is positioned behind a solid wall and floor at that moment in time.  But trying to make the logic of the torchbeam's illumination contingent on the room layout surrounding Willy's current position would be a nightmare to implement!

 

Anyway, you've done a great job expanding out Pyguri's concept of the torchlit caverns.  :)

[Norman Sword]

in jest- the walls in the cavern are made from translucent crystals. Such as diamonds, emeralds, jade, etc. the light would pass through the crystals and illuminate the scene behind. This is the reason for Willies riches.

Edited July 20, 2020 by Norman Sword

[Norman Sword]

Pgyuri

 

 

Pgyuri's Halo:- which is a halo of light surrounding Willy.

 

Normans Sword's Light beam :-  Is a light beam which is rotatable and directional
 

 

Rotation of beam          Pgyuri NO
Stopping of clock          Pgyuri NO 
Display of objects         Pgyuri NO ; No feedback to where the objects are. No feedback for object collection
Display of portal           Pgyuri NO ; No feedback when the objects have all been collected. No feedback where the portal is

Playable on

 unknown screen          Pgyuri NO : the halo will not project across gaps. Jumps to other platforms are just guess work.
Halo of light                  Pgyuri yes

Directional beam          Pgyuri directional bias on halo

Ability to see ahead     Pgyuri NO

Ability to see above     Pgyuri NO. Object just two blocks away can not be seen. Jumping to collect an unseen object is guess work. Hazards can also not be seen.

Ability to see below     Pgyuri NO  objects just two blocks below his feet can not be seen. Falling of a platform to a lower platform is Guess work

 

From this point onwards I will always refer to the original routine as Pgyuri's Halo. And mine as Norman Sword's Light beam.








 

Edited July 21, 2020 by Norman Sword

[IRF]

I think his username is Pgyuri, not Pyguri.  (A typo which I was guilty of myself last night!)

 

He did do a variant where you can set off a 'flare' - only five of which are available per cavern - if you press a certain key it sets the Screen Flash Counter variable to 7, so that all the visible screen elements cycle down from white to black (like what happens when you gain an extra life in the original Manic Miner).  That effect allows you to survey the whole cavern for precisely seven time-frames of the game, which does make it slightly more playable/less insane.  (Nowhere near as playable as it is with Normans Sword's Torch beam though.)

 

I wonder whether it would be worth 'borrowing' the flare idea to cover the few scenarios where the torch beam doesn't reach far enough. e.g. when dropping down into the open portal from the top of caverns such as the ones based on the Cold Room and Return of Kong.  In both of those scenarios there is a horizontal guardian which intermittently either goes through the portal [Cold Room penguin], or passes the portal just above it [rolling rock in Return of Kong].  In Candle Mode it's pure guesswork when dropping down as to whether you're going to hit the guardian or not before you manage to reach the portal!  Setting off a flare before you make the drop could help you to get the timing right.