Jump to content

Photo

Continue Point Shenanigans


  • Please log in to reply
5 replies to this topic

#1 C-Dawg

C-Dawg

    Magus

  • Members

Posted 23 June 2015 - 09:37 AM

I'm posting over here in the hopes I can get a few more pairs of eyes to help out figure out what's going on with some continue point weirdness in Zodiac.  I can't seem to figure it out.  Let me explain what I'm trying to accomplish, how it's set up, and the problem.  Once you understand that, I'd love to have a volunteer or two open up the latest version of Zodiac.qst from the project page, open it in Zquest, and see if they can figure out what's wrong.

 

WHAT SHOULD HAPPEN

 

In Zodiac, you move around mostly in a 2-d platforming maze.  You find doors that lead into small room scattered all over the place.  The concept is that dying or resetting inside one of these doors should not set a continue point; that is, you should never continue INSIDE a door.  However, each door you EXIT should set a continue point for death->continue purposes.

 

For save->restart purposes, however, the player should only ever continue at the room they first entered the current Zone.  The 2-d platforming maze is divided into 12 different "Zones" named after the Zodiac.  So, when you move between Zones, then a save->restart continue point should be set only there.

 

Make sense?  If you die, you go back to the last door you left.  If you save and quit, you go back to the entrance of the current Zone.

 

HOW IT IS SET UP

 

Doors are scripted, so it might be difficult to see what's going on at first.  The script looks to see if the player is pushing "UP" in front of a door combo.  If so, it loads the warp data from the screen (the same stuff you see when you push F10) and applies it to an autowarp combo.  So, the warp should function however it is set up in Zquest.

 

Passages between Zones (large blue doors with arrows) are normal Zquest stair combos.  They warp according to Zquest rules.

 

THE PROBLEM

 

Some of the doors work, but not all.  In very general terms -- I havn't tested every single door -- they start functioning perfectly around the Pisces Zone and thereafter.  For some reason, they do not work in earlier zones. 

 

Also, I have had some reports that saving->continuing in SOME places, most particularly the passage between Aquarius and Aries, seems to lead to bizarre behavior.

 

YOU CAN HELP

 

I'd love for more people to pop open the hood and let me know what they think about this.  I can't very well be done with the project until I get all the continue bugs ironed out!  Thanks! 



#2 Saffith

Saffith

    IPv7 user

  • Members

Posted 23 June 2015 - 03:33 PM

You could handle it in the script rather than using the built-in handling. Probably easier than getting ZC to do what you want. You'd use Game->ContinueDMap, Game->ContinueScreen, Game->LastEntranceDMap, andGame->LastEntranceScreen for that.

#3 C-Dawg

C-Dawg

    Magus

  • Members

Posted 23 June 2015 - 03:52 PM

Interesting. Are these functions well described in zscript.txt?

#4 Saffith

Saffith

    IPv7 user

  • Members

Posted 23 June 2015 - 03:57 PM

Yeah. They're pretty straightforward, except they use the map screen instead of the DMap screen for whatever reason.

#5 C-Dawg

C-Dawg

    Magus

  • Members

Posted 23 June 2015 - 04:29 PM

I'll take a look and see if these solve the problem, thanks.



#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 25 June 2015 - 02:19 AM

If I may suggest an alternative approach: Save the destination coordinates for the FFC door in a temp array, and slave that to OnExit and OnContinue scripts. The OnContinue script can direct warp the player to ( map, screen, x, y ) of the destination door FFC saved in the array, which is far simpler than messing with any traditional continue points.

 

I can just send you my code for that, if you want it; or I can patch your door FFC to support my code for it, and send it to you as a drop-in package.

 

It's also easy to re-spawn the player at that point, or any arbitrary checkpoint with the same methods, if their health bar is zero, and they have remaining lives.

 

It's not that Saffith's way is at all problematic, it's simply that reading the values with a for loop is more streamlined. You can store them at any arbitrary position in any of your game variable arrays, and just set a constant for the number of values, and the starting index position; and you're essentially done. A simple Screen->Rectangle while loading also makes it clean, but you can do something fancy, too, by drawing a string over the rectangle, such as remaining lives, with a graphic tile, and play a jingle for the transition.

 

This is essentially how my 'Quick Save' in LoE (from RPG.zh) works, but it stores far more datum.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users