User Tag List

Page 2 of 2 FirstFirst 1 2
Results 11 to 17 of 17

Thread: 2.future merge thread

  1. #11
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    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?

    Code:
    //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.

    Quote Originally Posted by ywkls View Post
    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.

  2. #12
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    Re; lots of exposed global state/zc internals:

    On multiple occasions in the past I was very close to putting in two new get/set arrays (I think I even mentioned this before):

    int Game->Property[int prop_id];
    int Game->QuestRules[int qr];

    The reasons I never put them in was basically for the reasons DD mentioned, plus the fact that I didn't want to complicate any refactoring Saffith was doing, or future refactoring efforts. For example:

    if(Game->Property[epFPS_UNCAPPED] == 1 || Game->Property[epFPS] > 72) { //stuff for cheaters here };

    Now suppose the framerate is actually 60 due to other factors like a full moon, or it's uncapped and ZC is running at 45 FPS, or the user is vsynced to a variable refresh rate monitor, or 2.6 doesn't support it, or whatever. Say Windows 11 is running mega-cleaner in the background and ZC performance becomes erratic; well now your 'script' to check for cheaters is buggy and so you post a bug report. etc. Now multiply that by the other states we expose. Gameplay logic must be decoupled from engine code, period. However there are things that may be useful or trivial to maintain, and we can talk about those. If pausing or uncapping is a serious concern then why didn't anyone bring it up in the beta forums/suggestions? A better solution might be to put in a quest rule for uncapping and a quest variable for pause_timeout.

    It was basically the same with quest rules, although those are simpler. The only solution I have for the above is something like a "Game->TryGetEngineState[param]" which will ALWAYS have to checked for NOT_SUPPORTED otherwise it's the users fault. This has a bad smell to me though.


    Quote Originally Posted by ZoriaRPG View Post
    Really, download Gleeok's 'Starshooter Extreme', and try loading it in any 2,50 released version: It will crash. This is because the number of parameters in one draw command was changed (I think it was adding yscale), between when he wrote the script on which it runs, and when 2.5 was released. That simply isn't acceptable IMO, for the future.
    That was me. I was the one who changed that. - ZScript drawing commands was one of the things that was nowhere near finished in the beta days, and the fact that that's the only example of things I had to tweak is pretty dang good I think. Also, without that change there might not have been a "mysteries of the deep" by blue_knight as an example. I stand behind it.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  3. #13
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Quote Originally Posted by ywkls View Post
    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.
    Thanks for the info; I'm convinced now that the benefits of this change outweight the cost. I do wonder, though, if there is an ultimately superior solution (allow each script to request at compile time the number of variables it needs?)

  4. #14
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    Quote Originally Posted by DarkDragon View Post
    Thanks for the info; I'm convinced now that the benefits of this change outweight the cost. I do wonder, though, if there is an ultimately superior solution (allow each script to request at compile time the number of variables it needs?)
    I would probably (as an end-user) prefer a variable value menu that you could set in ZQuest that determines these. For 2.10 quests this would be 0, for 2.50 it would be 16, and for 2.51 you could just set it to however many you need for each type of script object. A special config script sounds good also.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  5. #15
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    Re; lots of exposed global state/zc internals:

    On multiple occasions in the past I was very close to putting in two new get/set arrays (I think I even mentioned this before):

    int Game->Property[int prop_id];
    int Game->QuestRules[int qr];

    The reasons I never put them in was basically for the reasons DD mentioned, plus the fact that I didn't want to complicate any refactoring Saffith was doing, or future refactoring efforts. For example:

    if(Game->Property[epFPS_UNCAPPED] == 1 || Game->Property[epFPS] > 72) { //stuff for cheaters here };

    Now suppose the framerate is actually 60 due to other factors like a full moon, or it's uncapped and ZC is running at 45 FPS, or the user is vsynced to a variable refresh rate monitor, or 2.6 doesn't support it, or whatever. Say Windows 11 is running mega-cleaner in the background and ZC performance becomes erratic; well now your 'script' to check for cheaters is buggy and so you post a bug report. etc. Now multiply that by the other states we expose. Gameplay logic must be decoupled from engine code, period. However there are things that may be useful or trivial to maintain, and we can talk about those. If pausing or uncapping is a serious concern then why didn't anyone bring it up in the beta forums/suggestions? A better solution might be to put in a quest rule for uncapping and a quest variable for pause_timeout.

    It was basically the same with quest rules, although those are simpler. The only solution I have for the above is something like a "Game->TryGetEngineState[param]" which will ALWAYS have to checked for NOT_SUPPORTED otherwise it's the users fault. This has a bad smell to me though.




    That was me. I was the one who changed that. - ZScript drawing commands was one of the things that was nowhere near finished in the beta days, and the fact that that's the only example of things I had to tweak is pretty dang good I think. Also, without that change there might not have been a "mysteries of the deep" by blue_knight as an example. I stand behind it.
    Doing this in a beta phase is fine, but doing it to functions that were in a release, just isn't. That was my primary point, there.

    I would favour an uncapping quest rule, or something like that. I'm not sure how different that would be than a variable that prevents uncapping, instead of one that returns if it is happening.

    Would preventing using uncap be acceptable, via a state variable? I could change THROTTLEFPS to set a ZASM variable, and change the uncap code to require that variable set false in order to do the FPC uncap from the mens, or the keyboard. How would you feel there, because that is a perfectly acceptable compromise to me.
    @DarkDragon : Regarding script defence types, you may want to read some of the user replies, from one of the previous conversations on this subject:

    http://www.armageddongames.net/showt...l=1#post911886
    http://www.armageddongames.net/showt...l=1#post911893

    Quote Originally Posted by Gleeok View Post
    I would probably (as an end-user) prefer a variable value menu that you could set in ZQuest that determines these. For 2.10 quests this would be 0, for 2.50 it would be 16, and for 2.51 you could just set it to however many you need for each type of script object. A special config script sounds good also.
    I presume you mean of a range from 0 to N, where N is a reasonable cap, so that they don't use 14MB of RAM per object when the user decides to max it at 214747 indices? It would require rewriting MISCD, and at that point, you may be better off tacking an additional array onto the object class that can have a user-defined size.

    Changes: itemdata sprites, attributes, and flags are now arrays. Added ->ID to the ffc table, so that you can check for the screen index *1) without loops, and (2) with surety. At present, there is no absolutely positive method of proving the screen ref of ffcs under some conditions. This fixes that problem and I would hope doesn't create anything bad. I set it to return 1 to 32, and to convert inputs of 1 to 32 into 0 to 31 for ri->ffcref, because the user is used to these values, even when the true ref for FFC 1 is 0. Why? Because we didn't need a true FFC NULL?

    Code:
    //Beta 48
    Added ffc->ID, to check this->ID and get the screen ref of an ffc from an ffc script. -Z 1/JAN/17
    Added itemdata->Flags[5], itemdata->Atributes[10], and itemdata->Sprites[10]. 
    	These are mean to replace the individual vars for each of these groups. -Z 1/Jan/2017
    * Updated entries for these new values in zscript.txt. -Z 1/Jan/2017

  6. #16
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    I presume you mean of a range from 0 to N, where N is a reasonable cap, so that they don't use 14MB of RAM per object when the user decides to max it at 214747 indices? It would require rewriting MISCD, and at that point, you may be better off tacking an additional array onto the object class that can have a user-defined size.
    Yes, though if the user asks for 200,000 indices, in a sense they have only themselves to blame.

  7. #17
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    Yes, though if the user asks for 200,000 indices, in a sense they have only themselves to blame.
    Well, yes, and no. We regularly declare arrays of that size as GlobalRAM arrays, to use for all of our bonkers variables. (All because ZScript has fixed variable allocation, which is pretty much just how it's going to stay.)

    But that's one, or possibly two arrays, not 255 of them * number of object types. Could you imagine that footprint inflation?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social