Moosh's NPC Script
Overview
Creator:
Moosh
Updated: 02 Dec 2021
Tags:
FFC
Downloads: 408
|
View Script
Download Example (1.55 MB) |
Information
I made this script as an alternative to an older script by Lemmy Koopa. The script lets you have NPCs that you can talk to as well as NPCs that block your path and appear and disappear depending on what items you have. It also did away with a pretty serious bug that allowed sequence breaking.
Update: Added simplified version of the script and an example add-on script for trade sequences.
Update: Added simplified version of the script and an example add-on script for trade sequences.
Description Setup Reviews Comments
Demonlink
Edited 02 June 2021 - 09:57 PM
So... having an issue with this on 2.55 alpha 92, (don't recall having trouble with it on 2.53). It works okay, except for the fact that once the message displays, you can still walk around. Link doesn't freeze:
I have checked that the rule "Messages freeze screen" is checked, and it is. Or, I may have overlooked something else... However, as mentioned, before upgrading to 2.55, I didn't have this problem.
I have checked that the rule "Messages freeze screen" is checked, and it is. Or, I may have overlooked something else... However, as mentioned, before upgrading to 2.55, I didn't have this problem.
Timelord
Edited 07 August 2020 - 05:53 AM
There is a danger here:
If your settings for solidity use layers that are not set up on screens where the ffc script is placed, you will be erroneously writing combos on map 1, screen 0.
The use of (e.g.) SetLayerComboD(2, ...) here, resolves to Game->SetComboSolid(-1, -1, pos, id), because the return for LayerMap()is -1, and the return for LayerScreen() is -1, as the layers were not configured in ZQE; see: zscript.txt.
This is due to how commands such as SetComboData work internally. If values passed to them would resolve to a map < 1, then the value is clamped to 1; and if values passed to them would result in a screen < 0, again, then the value is clamped to 0. This prevents crashes (i.e., writing to OoB struct for TheMaps), but it also means that invalid values (here: -1, -1) always clamp to a legal value, which mathematically is Min, of map 1, screen 0.
I have fixed the <std> functions for Get/SetLayerCombo as of 2.53.1 Beta 52, (<std v1.5013>), and 2.55 Alpha 79 (<std v1.7106>) to prevent this, and to issue an error on access to these functions for layers that are not configured, but you do need to be careful. Every screen where you use the npc, needs the layer assigned to LAYER_NPC to be configured.
Te other option is to wrap all calls to Set/GetLayerCombo with Screen->LayerMap(LAYER_NPC) != -1 && Screen->LayerScreen(LAYER_NPC) != -1, which is what I did to help Joel, but then, the npc will not be solid, so, be sure to set up the layers for all screens that use this script, so that they exist for the script to place down solid combos.
The effect of failing to guard here, with the screen layer data set up improperly, is that the combos for all screens drawn using map 1, screen 0 at the position of the ffc, will be converted to the combo ID assigned as CMB_NPC_SOLID (or CMB_NPC_HIDDEN). This causes graphical corruption that the end user will assume is either random, or a ZC bug, when in fact, the script is telling the software to do it, although this is admittedly an inadvertent outcome of how those commands work.
Future versions will now log errors such as The layer (2) used by SetLayerComboD for the current screen are not properly configured., when those functions are recompiled with the current versions of <std>, but users should be aware that prior to this internal sanity check, that this effect can occur by failing to give the screens using the script the layer that the script expects the screen to provide.
If your settings for solidity use layers that are not set up on screens where the ffc script is placed, you will be erroneously writing combos on map 1, screen 0.
The use of (e.g.) SetLayerComboD(2, ...) here, resolves to Game->SetComboSolid(-1, -1, pos, id), because the return for LayerMap()is -1, and the return for LayerScreen() is -1, as the layers were not configured in ZQE; see: zscript.txt.
This is due to how commands such as SetComboData work internally. If values passed to them would resolve to a map < 1, then the value is clamped to 1; and if values passed to them would result in a screen < 0, again, then the value is clamped to 0. This prevents crashes (i.e., writing to OoB struct for TheMaps), but it also means that invalid values (here: -1, -1) always clamp to a legal value, which mathematically is Min, of map 1, screen 0.
I have fixed the <std> functions for Get/SetLayerCombo as of 2.53.1 Beta 52, (<std v1.5013>), and 2.55 Alpha 79 (<std v1.7106>) to prevent this, and to issue an error on access to these functions for layers that are not configured, but you do need to be careful. Every screen where you use the npc, needs the layer assigned to LAYER_NPC to be configured.
Te other option is to wrap all calls to Set/GetLayerCombo with Screen->LayerMap(LAYER_NPC) != -1 && Screen->LayerScreen(LAYER_NPC) != -1, which is what I did to help Joel, but then, the npc will not be solid, so, be sure to set up the layers for all screens that use this script, so that they exist for the script to place down solid combos.
The effect of failing to guard here, with the screen layer data set up improperly, is that the combos for all screens drawn using map 1, screen 0 at the position of the ffc, will be converted to the combo ID assigned as CMB_NPC_SOLID (or CMB_NPC_HIDDEN). This causes graphical corruption that the end user will assume is either random, or a ZC bug, when in fact, the script is telling the software to do it, although this is admittedly an inadvertent outcome of how those commands work.
Future versions will now log errors such as The layer (2) used by SetLayerComboD for the current screen are not properly configured., when those functions are recompiled with the current versions of <std>, but users should be aware that prior to this internal sanity check, that this effect can occur by failing to give the screens using the script the layer that the script expects the screen to provide.
Jared
Posted 28 April 2016 - 05:13 PM
Hey Moosh, I have a question.
Can you use this script to warp to another screen once you meet certain requirements? I don't know if you still remember this thread, but I'm still having trouble with it.
Can you use this script to warp to another screen once you meet certain requirements? I don't know if you still remember this thread, but I'm still having trouble with it.
fireyf
Posted 27 April 2016 - 10:11 PM
This is my first time using scripts so maybe I'm doing something wrong, but when I try to import the script I get an error "invalid instruction the command was "std.zh"
I put import "std.zh" at the top of the file. I can't figure out why it's giving me an error.
I put import "std.zh" at the top of the file. I can't figure out why it's giving me an error.
