2.future merge thread

[ZoriaRPG]

That sounds like good progress on the feature, but the litmus test for inclusion into the main ZC source is simple: 100% working, with no workarounds needed, and thoroughly tested.

Once setting equipment has been fixed to fully work (including on subscreens, and through warps, and with checks to prevent setting the items into an illegal state due to A-assignment quest rules) we will merge it in.

You know, I think it's because my subscreen script places a 'freeze all except ffcs' screen combo until it finishes animating its closure. Doing Link->SetA or Link->SetB works normally. The 'graphical bug' is because the passive subscreen doesn't update while that combo is on the screen.

The warping reset isn't really a bug. It's because if the items are not n the subscreen, and you warp, that ZC disables them. I intentionally set items that were not in inventory, to ensure that allowing this worked; hence, they were removed on warping. I added code to force them back, again, intentionally. The most popular reason to set itemA/B is to create scripted subscreens, if you weren't aware; in which case the default subscreen behavior is undesirable.

The reason I had SetItemSlot as a separate function from ItemA, and ItemB, was to permit the scripter to override if an item is in inventory, or legal in QR definitions. I think that the way we hadle QRs needs t\o die a horrible death. They should all be an array, and the user should be able to set, or unset them by script as quest variables.

Adding a check to prevent an illegal assignment is easy. I intentionally left that out, to permit the scripter to choose if they want to do it. This is precisely why I wanted to add the SetItemSlot(int, int, int) as an option for the user, as it could validate what to do with an assignment internally, whereas the setters default to forced.

if ( I->family != ic_swords ) //Don't assign it
if ( !Link->Item[I->ID] ) //do't assign it

I prefer to allow the scripter to decide if they can assign it to a slot, than decide for them. If you intentionally force it to obey inventory or rules, then you prevent it from doing some things for which it is intended. i.e., overriding quest defaults, and user inventory. Requiring it to obey Link->Item demeans how it can be used, and requiring it to obey the active subscreen utterly defeats the purpose of adding it.

I'm still not sure what that means. Writing to ItemData->Tile will reset all tiles of all items using that itemdata? How does this interact with Item->Tile?

It should overwrite the tile of any instance of an item, be they on the screen, or yet to be spawned. I may have this usage in that demo.

Have you looked at the link movement code? Are you sure that suddenly changing his major movement settings will never cause problems? What if he's on a ladder? In the middle of a walk animation? Halfway onto a tile? I am extremely nervous about touching the movement code, and so while I am not categorically opposed to changing his movement settings though scripts, it is going to be difficult to convince me that the changes have been done properly (this does not require a simple test quest where "I didn't notice any problems," but rather, a pull request containing just this fix, where it is evident that the changes to the movement code will not cause any glitches or bugs.)

I've looked at it. There are already unresolved bugs in the movement code. I'm not saying that it doesn't need testing--everything does. I' sayin that it shouldn't be rejected out of hand.

Sorry, this simply will not happen, on my watch. Both Saffith and I have explained why it is a bad idea. If you insist that the FPS is part of the game state, and not part of the rendering engine, answer this: can a NES ROM hack detect at what FPS it is running on your emulator?

I won't debate this one further. I can be a feature of the fork that you don't adopt.

The stability and maintainability of the source is more important than the wishes of the scripting community. Eventually, weapons will be fully scriptable. This becomes impossible if we are too greedy too soon and add features in before they are fully-baked. Exposing ZC internals is not a decision that affects just the current developers or just the current ZC version: the features we add ripple for all eternity into the future of ZC development. We have to be extremely careful and judicious with what we change.

Did you look at the implementation? All this does, is add case values specifically for each script type, instead of defaulting them into one category, and allow the user to set them in the enemy editor. How si supporting that any different to supporting the types that we now do? The script LW types can't go away: Users already use them. This is just a means for the user to apply elemental damage, or other special qualities to them without massively convoluted functions that are also very prone to bugs. It is far cleaner than what the users do now, that we may already need to support, and is far less likely to cause support headaches than this baffling 'swap this item class for another, read this god-awful array with settings, pass through filters, do three weapon and npc check loops' and so forth, that is now required to do precisely the same bloody thing.
@Mitsukara did that in PoC. I had to do something similar in a few quests, as did Lejes, @Dimentio , and Binx. Probably @Grayswandir , and @ywlks too. It's the most annoying aspect of the lweapons class, not being able to use the enemy editor to set up unique defence categories for them, because we already do give them special qualities, such as ice, water, air, wind, wood, earth, electric, dark. Tying this into the enemy editor, particularly now that I have double-damage, triple-damage, and quadruple damage in it, makes creating elemental, and other affinity based damage reduction, and damage enhancement, stupidly easy, without shifting the paradigm from how every other weapon works.

Wouldn't it be better to support a nice, clean way of handling it, than worry about bugs creeping in from all this type changing that people are forced to do now? That notwithstanding, please explain to be how expanding the cases for do_enemy_hit's switch statements will ultimately befuddle supporting anything?

Sure, that's the kind of evidence I want to see. Link me to some scripts where the variable count is becoming a severe limiting factor and I'm all for the proposed increase.

I hear from ywkls that he wants to post about this, so I'll let him do it.

That's a good point, and you've convinced me that warp sounds need the flexibility of being assigned on a per-instance basis. So let's do that first, and only after warps have been done "the right way" in the source, only then, add ZScript support for it.

Clarify, 'done "the right way"' for me.
I frankly have been wanting to rewrite warping, so that we separate pit warps from the rest, as a special case; and flag each if it was script, scc, or combo/screen generated.

They have done nothing because making them work correctly is very difficult. I'm not opposed to eventually being able to script Link's hitbox, but the attitude needs to be extremely careful study of the source code, followed by a 100% working solution.

Sure, certainly; but the only way to test them, is to try to use them. Clearly, it needs testing with any particular scenario, and we quite frankly need some questmakers who are willing to experiment with this sort of thing, and try to find issues, as the more people use this kind of proposed feature, the more sources you have for finding issues. I have neither proven, nor disproven tat what I did works perfectly, however I've been testin it while viewin the hitbox via the Cheat->Show Hitbox option, and this does help to validate it.

I noticed that you didn't mention the ZQuest, and ZC additions, though?

//Beta 45

///////////////////////
///  Zelda Classic  ///
///////////////////////

You may not enable, or disable the Debug Console from the Misc menu. 

//b45

////////////////
///  ZQuest  ///
////////////////

The Enemy Editor now had an additional tab, 'Defenses 3'. In this tab, you will find settings for configuring
enemy defences for each of the ten LW_SCRIPT* types. These otherwise work as normal weapon defences, and
correspond to npc->ScriptDefense[] in ZScript. 

Quests made in versions prior to 2.54 have no knowledge of these types, and will fall back on the generic 'Script'
defence type. This type should no longer be used to configure enemies, as it will be ignored in quests saved in
2.54. 

Further, the following new defence outcomes exist:

Trigger Secrets: Hitting the enemy with this weapon type will trigger all the secrets on the screen.
Double Damage : Weapon inflicts 2x damage.
Triple Damage : Weapon inflicts 3x damage.
Quadruple Damage : Weapon inflicts 4x damage.
Block if Damage < 10 : Blocks the weapon if its power is < 10. 
Enemy Gains HP = Damage : The enemy gains HP equal to the damage of the weapon. Note that this is not capped!

The other 'Block if < n' defence outcomes have been renamed to 'Block if Damage < n', for clarity. 

Other new defence outcomes have been added to the enemy editor, but they do nothing.

Oh I completely agree (one side note though: the beta releases are NOT officially supported. We reserve the right to break quests created in beta builds at any time for any reason, though obviously we try to avoid it whenever possible.) Once quests are compiled into ZASM on a stable release of ZC, those scripts need to work for all eternity (and this, once again, is why I err way, way on the side of caution when it comes to adding ZScript features.) That doesn't stop us from printing a huge warning message if the user tries to use deprecated ZScript syntax, and removing the deprecated functions from the documentation.

Good, good. @Grayswandir was pondering doin a stack exchange for GetPointerAsInt(...), to get an array pointer for a non-float array type as int, but I advised doing a separate function for each, to simplify matters. That, or allow typecasting array pointers from the parser.

One of the most popular scripting tools available is Ghost.zh (by Saffith) and it uses Misc Slots to do a lot of fancy things with EWeapons and Npcs. I'm not sure exactly how many the Npc's use, but the Eweapons use quite a bit.

Additionally, there have been several independenly created scripting libraries that also rely heavily of Misc slots. One of these is StdWeapons.zh (by Alucard648 on PureZC). It can be found here.

StdWeapons.zh

I've also been working on my own header, to do similar things albeit from a global level which I call Lweapons.zh. It uses 15 of the available Misc Slots to do fancy things and currently runs to well over 3,000 lines of code. Here's a link to it. (There are some things which are non-functional and have been commented out.)

LWeapons.zh code

There is also a test quest, if you want to see any of these in action. The scripted boomerang I have uses up all of the 15 slots that the script access to work, for instance.

One thing I'll note, I that itemdata's new vars ease this tension a bit, but not fully. Again, if the concern is bloat, and I didn't muck up the maths, it's 64KB of extra usage. That's negligible, versus the benefit of the additional slots. Ten times that, is still neglidgible, against their benefit.