11 replies to this topic

[Lüt]

OK this is probably the easiest request ever.

 

The Stone of Agony has been ZC's longest standing non-functional item, and thus the most easily re-purposed.

 

Therefore, when I decided to change it to the Stone of Gravity, ZoriaRPG gave me this global code to disable Link knockback while having the item in inventory:

global script noMoveOnHit
{
  void run()
  {
    while(true)
    {
     if(Link->Item[I_STONEAGONY] && ( Link->Action == LA_GOTHURTLAND || Link->Action == LA_GOTHURTWATER ) )
     {
     Link->HitDir = -1; //Force HitDir only if Link is hit.
     }
     Waitdraw();
     Waitframe();
    }
  }
}

However, now that the item has been made functional again in 2.50.3 (THANKS SHANE), Link now starts bouncing near secrets, even though I have the item sensitivity set to 0.

 

So if anybody could add this functionality to a standalone item script which I could then use with an entirely new item, that would be wonderful.

 

(And also, when I create this new item, do I have to use the pre-labeled "Custom Item 01" from the item list, or can I just start with "zz154"?)

[Avaro]

It'll have to stay a global script. What you can do here is replace I_STONEAGONY with any item ID number you want and it'll function for that item. Can be a custom item or one of the zz items.

[Timelord]

OK this is probably the easiest request ever.

 

The Stone of Agony has been ZC's longest standing non-functional item, and thus the most easily re-purposed.

 

Therefore, when I decided to change it to the Stone of Gravity, ZoriaRPG gave me this global code to disable Link knockback while having the item in inventory:

global script noMoveOnHit
{
  void run()
  {
    while(true)
    {
     if(Link->Item[I_STONEAGONY] && ( Link->Action == LA_GOTHURTLAND || Link->Action == LA_GOTHURTWATER ) )
     {
     Link->HitDir = -1; //Force HitDir only if Link is hit.
     }
     Waitdraw();
     Waitframe();
    }
  }
}

However, now that the item has been made functional again in 2.50.3 (THANKS SHANE), Link now starts bouncing near secrets, even though I have the item sensitivity set to 0.

 

So if anybody could add this functionality to a standalone item script which I could then use with an entirely new item, that would be wonderful.

 

(And also, when I create this new item, do I have to use the pre-labeled "Custom Item 01" from the item list, or can I just start with "zz154"?)

 

Start with the custom item 01-20. The listings under zzNNN are reserved, and may be actual items in a future version. I might add in a new buffer of forty custom item classes before adding new items, to ensure that quests that used these are relatively safe, but you cannot rename them in ZQuest if that helps you in any way.

 

Item scripts do not run on their own in 2.50.x for any reason, and only the global active script can set conditions based on if an item is in Link's inventory.

 

Why are you thanking Shane for fixing the Stone of Agony? What did I miss here?

[Lüt]

It'll have to stay a global script. What you can do here is replace I_STONEAGONY with any item ID number you want and it'll function for that item. Can be a custom item or one of the zz items.

D'oh. Really?

But I've seen so many items cause so many crazy things

Is there any particular reason a thing like this can't go in an item script?

I mean, not that it's relevant to the issue, I suppose. Just a curiosity.

Regardless, the question now is, how exactly do I link the script to the item? There's nowhere in the item editor that the Stone of Agony is named "I_STONEAGONY," so how do I know what (or where) to label this new thing? Is it auto-generated based on what I name the item in the item editor, or can I just call it by number? I decided to use Custom Item 01 (Item 123), because I'll probably need to use Class "Custom Itemclass 01" to get it to show up in the subscreen on pickup, so could I just use "I_123"?

[edit] Zoria the ninja strikes again!

Start with the custom item 01-20. The listings under zzNNN are reserved, and may be actual items in a future version. I might add in a new buffer of forty custom item classes before adding new items, to ensure that quests that used these are relatively safe, but you cannot rename them in ZQuest if that helps you in any way.

Item scripts do not run on their own in 2.50.x for any reason, and only the global active script can set conditions based on if an item is in Link's inventory.

Why are you thanking Shane for fixing the Stone of Agony? What did I miss here?

OK, looks like I was right to choose Custom Item 01 then.

 

I might have to move a few other items to Custom Item ##'s then, as I believe I may have used 2 or 3 of the zz###'s in the process of creating L2 upgrades.

 

And that answers the question of item/global functionality.

 

As for Shane... well, he was the one who reported that the Stone of Agony needed its functionality reworked, which Saffith then did, so I blame Shane for needing to do this

Edited by Lüt, 11 June 2017 - 09:26 AM.

[Saffith]

You don't need a new item. You don't even need to change the script. Just change the stone's type to a custom item and update its subscreen slot.

[Shoshon the Elegant]

Lut.

I_STONEOFAGONY refers to the item's name in std.zh. It is a constant.

I believe I_STONEOFAGONY in particular is in std constants.

Script makers use constants to simplify script making.

If you look through the std constants, you should be able to see that I_STONEOFAGONY is equal to the item id of the Stone of Agony in the item editor.

Also. You could use I_123 as custom item 1. But you would have to set up the constant in a script to actually make ZC understand what you mean by I_123. You could also probably just add it to the std constants. I haven't done that, but I assume you can.

If you've ever downloaded a script and had it come back with "XXX is Undeclared", it generally means that you have a constant in the script, but ZC doesn't know what to do with the constant cause you haven't given the constant a value.


Or you could try Saffith's suggestion. This is more for future reference.

[ywkls]

Is there any particular reason a thing like this can't go in an item script?

 

There are only two types of item scripts at present.

 

1. Runs only when you pickup the item. So, good for messages and variable alteration.

2. Runs when you use the item. Only runs for a single frame, but can be used to launch an ffc.

 

Theoretically, an ffc could do the same thing as the global script; but the difference is probably negligible.

 

 

Regardless, the question now is, how exactly do I link the script to the item? There's nowhere in the item editor that the Stone of Agony is named "I_STONEAGONY," so how do I know what (or where) to label this new thing? Is it auto-generated based on what I name the item in the item editor, or can I just call it by number? I decided to use Custom Item 01 (Item 123), because I'll probably need to use Class "Custom Itemclass 01" to get it to show up in the subscreen on pickup, so could I just use "I_123"?

 

The global script automatically locates whatever item has the correct item number, so there's no need to "link" the script to the item. Any item practically could be used for this.

[Binx]

Just to (hopefully) make this more clear. You don't need to make any alterations to the script file, itself. I_STONEOFAGONY refers to the item number of the Stone of Agony item. This will not change, regardless of whether or not you change the item class, so all you have to do is change the Stone of Agony item to a custom itemclass. No need for a fully custom item, as Saffith suggested. Much easier to do it this way.

Edited by Binx, 11 June 2017 - 07:40 PM.

[ywkls]

Just to (hopefully) make this more clear. You don't need to make any alterations to the script file, itself. I_STONEOFAGONY refers to the item number of the Stone of Agony item. This will not change, regardless of whether or not you change the item class, so all you have to do is change the Stone of Agony item to a custom itemclass. No need for a fully custom item, as Saffith suggested. Much easier to do it this way.

 

Well... that's true if he doesn't want a Stone of Agony type item as a secondary option. In other words, one item for secret detection (which is apparently fixed in newer versions of ZC, still in beta) and one that does the "No Knockback" feature. If only one is wanted, then changing the class of the existing item would work.

[Timelord]

Well... that's true if he doesn't want a Stone of Agony type item as a secondary option. In other words, one item for secret detection (which is apparently fixed in newer versions of ZC, still in beta) and one that does the "No Knockback" feature. If only one is wanted, then changing the class of the existing item would work.

 

No, he can of course always make a new item, and set that item to the 'Stone of Agony' class. Changing the class on the base stone would not preclude adding agony items to the quest, later. It will require updating the subscreen if he is not using item overrides.

 

Using an ffc to stop knockback would make sense only if:

1. You want this effect to require using the item; probably at a cost.

2. You want the effect to end as soon as Link changes screens in any way.

 

This is why I added a Link variable into future ZC versions that determines if he uses engine knockback.

Edited by ZoriaRPG, 12 June 2017 - 11:49 AM.

[Lüt]

OK, wrapping this up:

 

Saffith's solution was indeed the easiest. I wasn't sure if the script's usage of I_STONEAGONY required it be attached to an item that used the "Stones of Agony" type, but I see that's not the case. Removed that type, removed that functionality. Yay.

 

Still, even though that's perfectly fine for these updates, I wanted to try adding new items without replacing old ones for the sake of future projects. Making a new item using Custom Itemclass 01, and changing the script from "Item[I_STONEAGONY]" to "Item[123]" (not I_123) also worked just fine.

 

So it appears std_constants is where you can link an item number to an item name, apparently for the sake of only having to update that file rather than every single script file that uses that item if you change the item number. Convenient I suppose.

 

It does make me wonder though, because while you can name the individual item in the item editor and it will show up as such under init/link data, the item class itself seems to be stuck as "Custom Itemclass 01" - is there any way to change the name of the item classes as well as the individual items?

 

(Again, not that it's relevant for these updates. I'm just curious.)

 

Anyway, it makes sense that item scripts only activate when an item is... well, activated. So I see why this one has to stay global.

 

Alright, that was a lot to take in, but I think I got it all. Thanks everybody.

[Saffith]

So it appears std_constants is where you can link an item number to an item name, apparently for the sake of only having to update that file rather than every single script file that uses that item if you change the item number. Convenient I suppose.

Basically, yeah. A constant is just meaningful name for a number; replacing I_STONEAGONY with 123 is exactly what the compiler does. If you wanted to change any of them, though, you'd probably want to use a new file instead so that std_constants.zh isn't wrong when you start another quest.
 

It does make me wonder though, because while you can name the individual item in the item editor and it will show up as such under init/link data, the item class itself seems to be stuck as "Custom Itemclass 01" - is there any way to change the name of the item classes as well as the individual items?

There is not, unfortunately. Perhaps in a future version.