Quote:
I can guess what he deemed to be 'serious issues', which are all graphical, and careful script planning prevents all of them. I specifically created a demo to test, and prove this. The main two issues, are that the values are reset on warp, and that the passive subscreen graphics can be made to fall out of sync, but both of these issues have a easy in-script solution.
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.
Quote:
Writing to itemdata affects the item globally, until the game is reloaded, just as it always has. I could run an entire quest with two 'inventory' items, and change the itemdata values for each whenever I please, instead of a full inventory. The same could be done to a lesser extent, with drop items, but that would make messy ZScript. I might pop out a demo purely of the itemdata stuff, next.
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?
Quote:
As to the stuff with Link, many of those things were requests, and some are damned well worthwhile. Enabling or disabling diagonal movement is pretty useful, and being able to define Link's hitbox, and sprites, is something that most scritpers have wanted for ages. Would it be nice to be able to directly write to his tile? Sure, but until a rewrite exists that allows it, this is the only viable option. Too many quests depend on how sprites work to ever fully deprecate them, so if in the future, the sprites are phased out--something I would favour--then we could easily redirect what the functions that set these values do. I did use an intermediate call for this.
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.)
Quote:
bool Uncapped: This is a hot request, to prevent timing problems with scripted events, and quite frankly to detect cheating. Recharge items, in particular, are subject to hellish abuse because the player can just unthrottle, and one way or another, the system will always have an uncap feature. All you need to do is redirect how it returns the check for it, if you change it out. It's detecting it by state and/or keypress. This is a user setting invoked at any time, and not quite the same as screen res, colour depth, or any of that stuff. I would frankly love to offer a state prevention for this one, as it is extremely abused.
But throttled is already an internal variable, too. That is mostly what this checks, except whomever added holding down the tilde key didn't flipping tie it to that var, so this also checks that. I would rather check and return the variable, which in this case, I can't define as anything other than a game state, as that is how it was coded, and link the keypress to setting it. I suppose the bottom line on this one, is that unless you think that it will be impossible to remove the 60fps cap in the future, I can't agree with the support issues. It's also the type of thing, that I'm pretty adamant about keeping in the fork, but if it isn't pulled into main, that's fine. I suppose what isn't pulled, can help define what users want, if they decide to use a fork rather than the mainstream release to create quests.
I also don't see any reason that if you did remove the feature, that you couldn't just have it return false at all times.
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?
Quote:
Being able to use the ten script types individually is the most popular request of the lot. If you want to roll it into Defense[], that's fine, but if you want to reject it out of hand because you want to rewrite weapons and think you may eventually have a better solution, then I think I'm just done. That pretty much tosses out the wishes of the scripting community, and it's a harmless feature. You are going to need to support the present defence system in the future no-matter what you do. Additional defence categories, and outcomes, should not pose any more of a problem iin that regard than what now exists.
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.
Quote:
I can list several scripters who beg for this kind of expansion, as they flat out exhausted all of these indices.
.
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.
Quote:
Actually, that is a very bad idea. In fact, hardcoding effects to slots is something I would rather move away from, not towards. If you did et it to a slot, then you'd need a new at to bind all sound effects by script. I would certainly approve of that, but the sound of a warp should not be any more static than using an item, or weapon. |The way that warps are using in games, you need them to be silent, or use a specific sound, base don their implementation; and the questmaker may want several sounds for the same warp type, based on how it is invoked. I did in fact, put quite a lot of thought into this set, and my eventual goal was with an array WarpEffects[12], or separate arrays or values based on these conditions
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.
Quote:
These have been in the ZScript syntax for years, and done nothing. People have also wanted to be able to do this, for years. Being unable to modify Link's hitbox for engine collisions is a dramatic flaw in the entire system, and changing these to match a different implementation alter shouldn't pose a problem. Hell, every other sprited object has these properties. It is physically impossible to make a sidescrolling quest, or a quest with larger than 16x16 Link sprites, and have the full sprite in the collision area.
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.
Quote:
One important thing: I fundamentally oppose either deprecating existing syntax, or changing the number of parameters for any functions; unless you want to write a stack-exchange to support them being overloaded. There is simply no compelling reason to break existing scripts, in order to implement new instructions. There was enough fun with that sort of thing in the 2.5 betas, when an existing script, or quest, would break because the number of function params were changed, or the function/variable was renamed. Now with such a gigantic ZScript library out there, it is imperative not to break scripts, especially as that can simultaneously can break quest compatibility.
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.
