I still need help, how to use this script the right way.
I loaded ffc and global script (combined with my former version, which enables DayNight switch, Auto Slashable Animation/Sfx and flowing water) but it still does nothing.
Very sure that there's something I make wrong with the constants/configurations.
It's very difficult for me, especially because my first language is german.
Can someone tell me (in "for dummies" version), how to use it?
- Current Location:
- PureZC
- » PureZC Forums
- » Scripts
- » Moosh's Pit Script
Moosh's Pit Script
Overview
Creator:
Moosh
Updated: 24 Apr 2018
Tags:
FFC,
Global
Downloads: 161
|
View Script
Download Example (1.49 MB) |
Information
Yup, it's another pit script. Place your bets on how many it takes until we get one that doesn't suck. 
Description Setup Reviews Comments
After watching Mero's pit script bug out spectacularly for the umpteenth time, I finally decided to get off my butt and make my own. Pit scripts seem to have a history of being buggy and terrible, and I can't really promise this one will turn out any differently, but at least I should be able to address the problems as they come. Better to be patching up my own broken code than somebody else's.
Immediate "Mistakes were made" update: Almost forgot to make pits interact with FFCs. Whoops!
Update 4/13/17: Fixed a bug where DMap offsets would make the pits dump Link at the last safe spot instead of the entrance. Also made pits interact properly when dropping Link into a sideview screen.
Update 5/26/17: Fixed a bug where I forgot to make the pits interact with the hookshot. Yes, seriously. It took this long for me to find out.
Update 10/11/17: Added a function, MooshPit_ResetEntry(), that lets other scripts update the return point.
Update 10/25/17: Fixed a bug where Link would collect items south of a pit while falling. Added a setting to prevent falling sprite snapping to the grid.
Update 4/24/18: Fixed the pit hitboxes. Yeah, those were broken this whole time somehow and nobody even noticed. Also added some basic (optional) slidey pit behavior.
Update 2/21/19: You fellas ever forget the raft exists? Me too. Plenty of people who used this script too. How did it take me this long to add a check for rafting?
Update 6/7/19: Added a fix for respawning on top of stairs and an experimental feature to stun enemies while falling
Immediate "Mistakes were made" update: Almost forgot to make pits interact with FFCs. Whoops!
Update 4/13/17: Fixed a bug where DMap offsets would make the pits dump Link at the last safe spot instead of the entrance. Also made pits interact properly when dropping Link into a sideview screen.
Update 5/26/17: Fixed a bug where I forgot to make the pits interact with the hookshot. Yes, seriously. It took this long for me to find out.
Update 10/11/17: Added a function, MooshPit_ResetEntry(), that lets other scripts update the return point.
Update 10/25/17: Fixed a bug where Link would collect items south of a pit while falling. Added a setting to prevent falling sprite snapping to the grid.
Update 4/24/18: Fixed the pit hitboxes. Yeah, those were broken this whole time somehow and nobody even noticed. Also added some basic (optional) slidey pit behavior.
Update 2/21/19: You fellas ever forget the raft exists? Me too. Plenty of people who used this script too. How did it take me this long to add a check for rafting?
Update 6/7/19: Added a fix for respawning on top of stairs and an experimental feature to stun enemies while falling
Constants:
First, you'll want to set up all the constants in the script for your quest as follows:
If this is your only global script, you can just use the included MooshPitGlobal script and be on your way. Otherwise, you'll have to combine it with your other scripts. Put MooshPit_Init(); somewhere between void run(){ and while(true){. Put MooshPit_Update(); somewhere between while(true){ and Waitdraw();. If there's no Waitdraw(); put it before Waitframe();.
Warps:
Screens where you want pits to warp Link down to a lower floor are marked with a screen flag in the Misc section. By default this is General Use 1 (Scripts). When this flag is set, pits will warp Link instead of dealing damage. The warp destination is set with Side Warp A. You cannot have more than one warp destination on one screen or damaging pits and warp pits on the same screen. Not that either of those situations would make sense anyways.
MooshPit_StairsFix:
This script is mostly just called by the global script to fix a bug with respawning on top of stairs, but ZC itself isn't always consistent about this behavior. If you find a spot where Link is kicked down stairs because of F6 or some other thing you can also just place the script manually.
This script requires std.zh and ffcscript.zh.
First, you'll want to set up all the constants in the script for your quest as follows:
- CT_HOLELAVA: This is the combo type the pit script uses. By default it's No Ground Enemies. You probably don't need to change it, but if you have plans to use No Ground Enemies for something else, it's an option.
- CF_LAVA: This is the flag that makes the pit behave as lava. Uses General Purpose 1 (Scripts) by default.
- SPR_FALLHOLE: Sprite in weapons/misc for Link falling in a pit
- SPR_FALLLAVA: Sprite in weapons/misc for Link falling in lava
- DAMAGE_FALLHOLE: Damage from falling in a hole (16ths of a heart)
- DAMAGE_FALLLAVA: Damage from falling in lava (16ths of a heart)
- FFC_MOOSHPIT_AUTOWARPA: Set this to the number of an FFC that's not being used on any screen. Chances are you can leave it at 32.
- CMB_MOOSHPIT_AUTOWARPA: Set this to the number of an invisible combo with the type set to Auto Side Warp [A].
- SF_MISC_MOOSHPITWARP: This is the screen flag under the Misc section that makes pits warp you. If none of your other scripts use screen flags, you can leave it be. Otherwise, count from the top of the Misc section starting at 0.
- MOOSHPIT_LINKHITBOXWIDTH, MOOSHPIT_LINKHITBOXHEIGHT: Width and height of Link's hitbox, which is centered on the bottom half of his tile. The whole hitbox needs to overlap the pit for him to fall in. Increase to make pits less sensitive.
- MOOSHPIT_SIDEVIEW_LINKHITBOXWIDTH, MOOSHPIT_SIDEVIEW_LINKHITBOXHEIGHT: Same as above but for sideview. Here, the hitbox is centered on Link.
- MOOSHPIT_MIN_FALL_TIME: Minimum delay after falling in a pit in frames (60ths of a second). This is a safety value to prevent Link repeatedly falling into pits and respawning. You can lower it if you really want fast pit falling.
- MOOSHPIT_EXTRA_FALL_TIME: Extra frames (60ths of a second) after Link falls into a pit before he respawns.
- MOOSHPIT_NO_GRID_SNAP: Set to 1 if you don't want Link's falling sprite to snap to the combo grid. This might look weird for most sprites with the default hitbox settings.
- MOOSHPIT_ENABLE_SLIDEYPITS: Set to 1 if you want Link to slide into pits. This will only work with a lenient pit hitbox (I used 12x12 in testing)
- MOOSHPIT_NO_MOVE_WHILE_FALLING: Set to 1 if you don't want Link to move while dropping from a higher floor.
- MOOSHPIT_NO_REENTER_STAIRS: Set to 1 to prevent Link reentering stairs if he respawns on them. This uses an FFC script.
- MOOSHPIT_STUN_ENEMIES_WHILE_FALLING: Set to 1 to stun enemies while the falling animations plays. This makes long fall animations more fair but may produce bugs and won't work with all enemies.
If this is your only global script, you can just use the included MooshPitGlobal script and be on your way. Otherwise, you'll have to combine it with your other scripts. Put MooshPit_Init(); somewhere between void run(){ and while(true){. Put MooshPit_Update(); somewhere between while(true){ and Waitdraw();. If there's no Waitdraw(); put it before Waitframe();.
Warps:
Screens where you want pits to warp Link down to a lower floor are marked with a screen flag in the Misc section. By default this is General Use 1 (Scripts). When this flag is set, pits will warp Link instead of dealing damage. The warp destination is set with Side Warp A. You cannot have more than one warp destination on one screen or damaging pits and warp pits on the same screen. Not that either of those situations would make sense anyways.
MooshPit_StairsFix:
This script is mostly just called by the global script to fix a bug with respawning on top of stairs, but ZC itself isn't always consistent about this behavior. If you find a spot where Link is kicked down stairs because of F6 or some other thing you can also just place the script manually.
This script requires std.zh and ffcscript.zh.
TheRock
Posted 30 September 2023 - 12:16 PM
For some odd reason the warp trees like to override the falling to a new screen. Once the player finds one warp tree and uses it, then falls in the pit that goes to a new screen it will then always play the animation of when you warp to a new location with the seeds.
Here's a video to show the pit working right and then it breaking: https://www.youtube....h?v=pmXd6El6FAM
Here's a video to show the pit working right and then it breaking: https://www.youtube....h?v=pmXd6El6FAM
Lüt
Edited 24 April 2018 - 05:54 AM
Much to my surprise, I was able to get this set up and working exactly how I wanted with essentially no hangups.
And you know your instructions are good when that happens.
However, two points I thought were worth bringing up:
First, the Link-touches-the-pit detection. Your default hitbox size of 2x2 works fine, as does 3x3. However, larger or smaller sizes can cause Link to fall down the wrong side of the pit depending which direction he approaches it from - example. With the sizes of 4x4 or 5x5, Link will fall into the wrong side when he walks rightward into the pit, but walking leftward, downward or upward into the pit works fine. With the size of 6x6 or above, walking rightward as well as downward into the pit will cause him to fall into the wrong side, but walking leftward or upward into the pit works fine. I tested it up to 12x12. Alternatively, with the size of 1x1, Link will fall into the wrong side when he walks leftward into the pit, but walking rightward, downward or upward into the pit works fine. I also tested with 4-way and 8-way movement, and "large Link hit box" enabled and disabled - same results. I did not test rectangular hitbox sizes, nor sideview.
I mean, I realize we're dealing with a character who's only 16x16 at his largest, so there's obviously going to be a limit. But if 2x2 or 3x3 are the final limits - which is plenty fine with me - it would be helpful to note that in the comments, rather than simply "increase to make pits less sensitive" and leaving the impression that, say, 8x8 only means really low sensitivity. Unless that's the intent, in which case you may have a problem here.
Second, the move-while-falling feature. Generally I like the ability move while jumping/falling. I don't think I ever would have played Mario past the first level or two if it didn't have that. But the issue here arises with room-per-room screen scrolling and the relative position of the pits toward the scroll points. If we assume the standard rectangular-room dungeon format that most designers use, any pit that's not tucked away into a mostly-blocked-off corner will allow the player to reach the doors before they're finished falling, resulting in some very odd visuals - example. That's the room directly below the one in the example above - note the blue shadow on the bottom side of the door to see Link's actual position during this screen transition.
It's also feasible that a designer may want to create an LttP-style multi-floor fall, like say Tower of Hera in which falling into the wrong pit on one floor would land you in yet another pit and down yet another floor, and the ability to maneuver out of the fall could undermine the danger of the trap (not that I personally mind being able to cheat my consequences as a player, but you know...).
So if there's an option to disable movement on fall, I didn't see it noted anywhere in the setup, and if there isn't an option, I'd recommend adding one, since I for one would use it.
[Posted: Jun 21 2017 / Edited: Apr 24, 2018 - updated image links]
And you know your instructions are good when that happens.
However, two points I thought were worth bringing up:
First, the Link-touches-the-pit detection. Your default hitbox size of 2x2 works fine, as does 3x3. However, larger or smaller sizes can cause Link to fall down the wrong side of the pit depending which direction he approaches it from - example. With the sizes of 4x4 or 5x5, Link will fall into the wrong side when he walks rightward into the pit, but walking leftward, downward or upward into the pit works fine. With the size of 6x6 or above, walking rightward as well as downward into the pit will cause him to fall into the wrong side, but walking leftward or upward into the pit works fine. I tested it up to 12x12. Alternatively, with the size of 1x1, Link will fall into the wrong side when he walks leftward into the pit, but walking rightward, downward or upward into the pit works fine. I also tested with 4-way and 8-way movement, and "large Link hit box" enabled and disabled - same results. I did not test rectangular hitbox sizes, nor sideview.
I mean, I realize we're dealing with a character who's only 16x16 at his largest, so there's obviously going to be a limit. But if 2x2 or 3x3 are the final limits - which is plenty fine with me - it would be helpful to note that in the comments, rather than simply "increase to make pits less sensitive" and leaving the impression that, say, 8x8 only means really low sensitivity. Unless that's the intent, in which case you may have a problem here.
Second, the move-while-falling feature. Generally I like the ability move while jumping/falling. I don't think I ever would have played Mario past the first level or two if it didn't have that. But the issue here arises with room-per-room screen scrolling and the relative position of the pits toward the scroll points. If we assume the standard rectangular-room dungeon format that most designers use, any pit that's not tucked away into a mostly-blocked-off corner will allow the player to reach the doors before they're finished falling, resulting in some very odd visuals - example. That's the room directly below the one in the example above - note the blue shadow on the bottom side of the door to see Link's actual position during this screen transition.
It's also feasible that a designer may want to create an LttP-style multi-floor fall, like say Tower of Hera in which falling into the wrong pit on one floor would land you in yet another pit and down yet another floor, and the ability to maneuver out of the fall could undermine the danger of the trap (not that I personally mind being able to cheat my consequences as a player, but you know...).
So if there's an option to disable movement on fall, I didn't see it noted anywhere in the setup, and if there isn't an option, I'd recommend adding one, since I for one would use it.
[Posted: Jun 21 2017 / Edited: Apr 24, 2018 - updated image links]
Sans
Edited 12 April 2017 - 07:06 PM
That works pretty good for me 
Now i could put the pitlava everywhere i want on my quest. but one question. When i falls on the lava why that take me a damage when i go on lava and when Link respawn on the screen closer at the lava ?
also i notice an important bug on this script: On my quest when you jump above the pit or the lava when you're accidently fall on thoses then the bug is Link is respawned on the hole or on the lava and he fall/drowns again until i die. Also i made the same thing you made for the warps hole but the bug is i fall on the same room without any explications
Now i could put the pitlava everywhere i want on my quest. but one question. When i falls on the lava why that take me a damage when i go on lava and when Link respawn on the screen closer at the lava ?also i notice an important bug on this script: On my quest when you jump above the pit or the lava when you're accidently fall on thoses then the bug is Link is respawned on the hole or on the lava and he fall/drowns again until i die. Also i made the same thing you made for the warps hole but the bug is i fall on the same room without any explications
