User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 17

Thread: 2.future merge thread

  1. #1
    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%

    2.future merge thread

    I'll give ZoriaRPG's changelog the same treatment as the official repos:

    Blue: worthwhile assuming the feature is thoroughly tested
    Orange: I don't object but would like some rationale as to why the feature is needed before being 100% happy introducing the feature into ZC
    Red: dubious/requires discussion

    // Beta 44

    /////////////////
    /// ZScript ///
    /////////////////

    The ZScript language now supports function pointers, using the AT_SIGN token (@) as a delimiter.
    (Seems extremely risky, from a language-change perspective, with very marginal benefit. Is there really a need for function pointers? Need thorough testing if implemented.)

    The ZScript language now supports C-Style comment blocks using the traditional syntax of:

    /*
    COMMENT BLOCK

    */


    Arrays now support being declared with a formula:

    int arr[10*4];

    This is now the same as int arr[40];

    Nesting array calls should now work properly. (e.g. arrA[ arrB[ arrC[ arrd[4] ] ] ] )

    //////////////
    // Global //
    //////////////

    void OverlayTile(int firsttile, int secondtile);
    Overlay one tile onto another.

    /************************************************** ************************************************** ********/

    ////////////
    // Game //
    ////////////

    bool CappedFPS
    * Check if the game is uncapped.
    (Unnecessary and extremely dangerous. FPS capping is a front-end implementation detail that should have no effect on the quest that's running.)

    int Version;
    * Returns the version of ZC being used.

    int Build;
    * Returns the Build ID of the version of ZC being used.
    (Quest authors should only release quests for ZC versions that are stable releases (can be differentiated with Version). Letting authors see the build number just encourages negative behavior.)

    int Beta;
    * Returns the Beta ID of the version of ZC being used. If the build is not a beta, this returns 0.
    (See above.)

    bool DisableActiveSubscreen;
    * If set true, the active subscreen will not fall into view ehen the player presses Start.


    /************************************************** ************************************************** ********/

    /////////////////
    /// LWeapon ///
    /////////////////

    int Range;
    * The range of the weapon in pixels. At present, this only affects boomerange class lweapons.
    (Seems dangerous. Weapons are due for an overhaul, and any details we expose today severely constraints what we can revamp in the future.)

    /////////////////
    /// *weapon ///
    /////////////////

    float Misc[32];
    * Epanded fro a size of [16] to [32]. An array of 32 miscellaneous variables for you to use as you please.
    (I'm convinced now that these are a good idea.)


    /************************************************** ************************************************** ********/

    /////////////
    /// NPC ///
    /////////////


    int ScriptDefense[10];
    * The npc's Script Weapon Defense values. This corresponds to the 'Defenses 3' tab in the Enemy Editor.
    (See above.)

    /************************************************** ************************************************** ********/

    //////////////
    /// Link ///
    //////////////

    int Animation;
    * Link;s Animation style, as set in Quest->Graphics->Sprites->Link
    (I don't see a use for these, and moreover they bind us to implementation details about a very crufty part of the code (Link's animation))

    int WalkASpeed;
    * Link's Walking Animation speed as set in Quest->Graphics->Sprites->Link

    int SwimASpeed;
    * Link's Swiming Animation speed as set in Quest->Graphics->Sprites->Link

    int InvFrames;
    * This returns how long Link will remain invincible, 0 if not invincible. Can be set.

    bool InvFlicker;
    * If set false, Link will neither flash, nor flicker when invincible.
    (There does need to be a way for scripts to disable Link's damage code. I don't think this pair of functions is the right approach.)

    int HurtSound;
    * The sound that plays when Link is injured. By default this is '16', but you may change it at any time.
    (The SFX system needs to be revamped.

    int HitHeight;
    * link's Hitbox height in pixels starting from his 0x,0y (upper-left) corner, going down.

    int HitWidth;
    * Link's Hitbox width in pixels starting from his x0,y0 (upper-left) corner, going right.

    int HitXOffset;
    * The X offset of Link's hitbox, or collision rectangle.

    int HitYOffset;
    * The Y offset of Link's hitbox, or collision rectangle.

    int Eaten;
    * It returns 0 if Link is not eaten, otherwise it returns the duration of him being eaten.
    (Assuming this is a GETTER only.)

    int Equipment;
    * Link->Equipment is now read-write, and needs testing.
    (Much prefer the more fine-grained functions below. In fact we should deprecate Link->Equipment and encourage script writers to switch to ItemA, etc.)

    int ItemA;
    * Contains the item IDs of what is currently equiped to Link's A button.

    int ItemB;
    * Contains the item IDs of what is currently equiped to Link's B button.

    int SetItemSlot(int itm_id, bool a_button, bool force);
    * This allows you to set Link's button items without binary operation. Needs testing. , and to decide whether to
    (Joe123 tried implementing this function and ran into "quite large issues." Needs thorough investigation before implementing.)

    int Extend;
    * Sets the extend value for all of Link's various actions.

    int GetLinkExtend(int sprite, int dir);
    * Gets the extend value for one of Link's various actions based on a direction.

    void SetLinkExtend(int sprite, int dir, int extend);
    * Sets the extend value for one of Link's various actions.

    void SetLinkTile(int sprite, int tile, int dir)
    * Sets the tile for Link's various actions. This is intended to work as OTile for Link. Unverified.

    int GetLinkTile(int sprite, int dir)
    * Returns the OTile for one of Link's various actions. Unverified.

    int WalkTile, SwimTile, DiveTile, SlashTile, JumpTile, ChargeTile, StabTile, CastingTile, PoundTile, FloatTile
    Hold1LandTile, Hold2LandTile, Hold1WaterTile, Hold2WaterTile;

    * A series of fourteen individual setter/getter ints to set or return the tile for all of Link's various actions.
    (All of the above expose dangerously low-level details about Link's animation code.)

    int WarpEffect;
    * Sets a warp effect type prior to doing Screen->Warp
    (Adding extra state to the script engine that modifies future warps dangerously increases complexity. This functionality should be exposed only through a new function call e.g. Screen->WarpExtended())

    int WarpSound;
    * Setting this to a value other than '0' will play that sound when Link warps.
    (Via any means, or only when warping using Screen->Warp? Some control over game sound effects is reasonable but this series of variables does not seem fully thought-out. Maybe replace with an SFX slot per warp type? )

    bool SideWarpSounds;
    * If you enable this setting, the warp sound will play in side warps.
    (See above)

    bool PitWarpSounds;
    * If you enable this setting, the warp sound will play in a pit warp, one time.
    (Adding this kind of state to the engine (sets up a delayed effect that only happens once, next time Link warps) is unnecessary and dangerous.)

    int UseWarpReturn;
    * Setting this to a value between 0 and 3 will change the target return square for Link->Warp
    (Should be added as a new function e.g. Link->WarpToWarpReturn)

    int UsingItem;
    * Returns the ID of an item used when Link uses an item. Returns -1 if Link is not using an item this frame.

    int UsingItemA;
    * Returns the ID of an item used when Link uses an item on button A. Returns -1 if Link is not using an item this frame.

    int UsingItemB;
    * Returns the ID of an item used when Link uses an item on button B. Returns -1 if Link is not using an item this frame.

    bool Diagonal;
    * This corresponds to whether 'Diagonal Movement' is enabled, or not.

    bool BigHitbox;
    * This corresponds to whether 'Big Hitbox' is enabled, or not.

    float Misc[32];
    * Expanded from [16] to [32]. An array of 32 miscellaneous variables for you to use as you please.

    /************************************************** ************************************************** ********/

    //////////////////
    /// itemdata ///
    //////////////////


    int ID;
    * Returns the item number of the item in question.

    int Modifier;
    * The Link Tile Modifier
    (There are some general concerns that need to be sorted out regarding items vs itemdata. Will setting itemdata automatically update the corresponding variables for all items using that itemdata? Or only affect new copies of that item?)

    int Tile;
    * The tile used by the item.

    int CSet;
    * The CSet of the tile used by the item.

    int Flash;
    * The Flash value for the CSet

    int AFrames;
    * The number of animation frames in the item's tile animation.

    int ASpeed;
    * The speed of the item's animation.

    int Delay;
    * The Delay value, before the animation begins.

    int Script;
    * The Action Script for the item.

    int PScript;
    * The Pickup Script for the item.

    int MagicCost;
    * The item's maic (or rupees, if this is set) cost.

    int MinHearts;
    * The minimum number of hearts required to pick up the item.

    int Misc1, Misc2, Misc3, Misc4, Misc5, Misc6, Misc7, Misc8, Misc9, Misc10;
    * These correspond to the pull-down options in the item editor 'Data' tab.
    (Should be an array)

    int Attribute1, Attribute2, Attribute3, Attribute4, Attribute5, Attribute6,
    Attribute7, Attribute8, Attribute9, Attribute10;

    * These correspond to the pull-down options in the item editor 'Action' tab.

    bool Combine;
    * Corresponds to 'Upgrade when collected twice'.

    bool Downgrade;
    * Corresponds to the 'Remove When Used' option on the Action tab of the item editor.

    bool KeepOld;
    * Corresponds to 'Keep lower level items on the Pickup tab of the item editor.

    bool RupeeCost;
    * Corresponds to the 'Use Rupees Instead of Magic' option on the item editor 'Action' tab.
    (Should probably be renamed)

    bool Edible;
    * Corresponds to the 'Can be Eaten by Enemies' box on the Pickup tab of the item editor.

    bool GainLower;
    * Corresponds to the 'Gain All Lower Level Items' box on the Pickup tab of the item editor.

    bool Flag1;
    * This corresponds to the box directly below 'Equiment Item'. For swords, this is 'B.H. is Percent'.

    bool Flag2;
    * This corresponds to the box directly below 'Flag 1, or two boxes down from 'Equiment Item'.
    * For swords, this is 'B.D. is Percent'.

    bool Flag3;
    * This corresponds to the box directly right of 'Equiment Item'. For swords, this is 'B. Penetrates Enemies'.

    bool Flag4;
    * This corresponds to the box directly right of 'Flag 2'. For swords, this is 'Can Slash'.

    bool Flag5;
    * This corresponds to the box directly below 'Flag 4'. For swords, this is '<Unused>', and greyed out.

    bool Unused;
    * ? - An extra script-only flag. It's a mystery to everyone.

    /************************************************** ************************************************** ********/

    ////////////
    /// npc ///
    ////////////

    float Misc[32];
    * Epanded fron a size of [16] to [32]. An array of 32 miscellaneous variables for you to use as you please.

    /************************************************** ************************************************** ********/

    ////////////////
    /// Screen ///
    ////////////////

    void WavyIn();
    * Replicates the warping screen wave effect (inbound) from a tile warp.

    void WavyOut();
    * Replicates the warping screen wave effect (outbound) from a tile warp.

    void ZapIn();
    * Replicates the warping screen zap effect (inbound) from a tile warp.

    void ZapOut();
    * Replicates the warping screen zap effect (outbound) from a tile warp.

    void OpeningWipe();
    * Replicates the opening wipe screen effect (using the quest rule for its type) from a tile warp.


    void DrawBitmapEx ( int layer,
    int bitmap_id,
    int source_x, int source_y, int source_w, int source_h,
    int dest_x, int dest_y, int dest_w, int dest_h,
    float rotation, int cx, int cy, int mode, int lit, bool mask);


    * As DrawBitmap(), except that it can do more things.

    /************************************************** ************************************************** ********/

  2. #2
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    The ZScript language now supports function pointers, using the AT_SIGN token (@) as a delimiter.
    This seems very problematic. Functions aren't shared across scripts, so a function pointer created in one script would point to some random, meaningless data if used in another script. And functions that aren't used in the script aren't compiled at all. Can the compiler reasonably detect which functions need to be compiled so that they might be pointed to?
    It just seems to me like the engine would need completely overhauled to make this work reasonably.

    The ZScript language now supports C-Style comment blocks using the traditional syntax of:

    /*
    COMMENT BLOCK

    */
    Fine, but there are a lot of mistakes that could be made in the implementation. Will all of these cases work correctly, or is it okay if they don't?
    Code:
    int str[]="asdf/*";
    
    /*
    // */
    
    // /*
    Nesting array calls should now work properly. (e.g. arrA[ arrB[ arrC[ arrd[4] ] ] ] )
    I believe those are working in 2.50.3.

    int ScriptDefense[10];
    * The npc's Script Weapon Defense values. This corresponds to the 'Defenses 3' tab in the Enemy Editor.
    Extended defenses would be nice, but I'd rather make them generic and add a weapon->Defense to control which is used rather than hard-code them to LW_SCRIPT*. Making them separate from the existing defenses I don't like at all.

    int Equipment;
    * Link->Equipment is now read-write, and needs testing.
    It was originally writable, but Joe123 disabled that, saying there were problems with it. I don't know any details, but I'd be pretty wary about adding it back in.

  3. #3
    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%
    This seems very problematic. Functions aren't shared across scripts, so a function pointer created in one script would point to some random, meaningless data if used in another script. And functions that aren't used in the script aren't compiled at all. Can the compiler reasonably detect which functions need to be compiled so that they might be pointed to?
    It just seems to me like the engine would need completely overhauled to make this work reasonably.
    The addressable functions are known at compile time so these could be labeled and included in the ZASM output of all scripts. A table can then be included in a reliable fixed place (i.e., at the beginning) of every script that contains the address to jump to for each function pointer in the addressable functions table.

    Setting aside the complexity and bloat of the above there are of course additional problems. Function pointers of member functions need to either be disallowed, or some compile-time semantic checking needs to ensure that only scripts of class X can call pointer to member functions of class X, otherwise the "this" pointer will be garbage. Moreover script variables addressed within the function in question obviously won't be accessible if the function is invoked from within a different script (worse, this problem will not be detected at the time ZASM is assembled, but rather will result in silent corruption whenever the function pointer is invoked.)

    But it could be done, if there were extremely compelling rationale for the need.

    Fine, but there are a lot of mistakes that could be made in the implementation. Will all of these cases work correctly, or is it okay if they don't?
    It's a standard enough language feature that presumably good solutions exist already online for the magic incantation to make the comment blocks work with Flex.

    It was originally writable, but Joe123 disabled that, saying there were problems with it. I don't know any details, but I'd be pretty wary about adding it back in.
    Hm, was this a forum post or private correspondence? I can see potential issues with both buttons being assigned the same item, or the A button being remapped in quests that do not allow assigning non-Swords to the A button, but I don't see any major issues with it otherwise...

  4. #4
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    Quote Originally Posted by DarkDragon View Post
    Hm, was this a forum post or private correspondence?
    On the SVN log and Shardstorm.
    * Link->Equipment can no longer be set - I overlooked some (quite large) issues when adding this functionality. My sincerest apologies to those who were using this in their scripts.
    That's all we've got, unfortunately.

  5. #5
    Banned
    Join Date
    May 2015
    Posts
    141
    Mentioned
    34 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    667
    Level
    9
    vBActivity - Bars
    Lv. Percent
    14.48%
    Quote Originally Posted by DarkDragon View Post
    /************************************************** ************************************************** ********/

    ////////////
    // Game //
    ////////////

    bool CappedFPS
    * Check if the game is uncapped.
    (Unnecessary and extremely dangerous. FPS capping is a front-end implementation detail that should have no effect on the quest that's running.)

    int Version;
    * Returns the version of ZC being used.

    int Build;
    * Returns the Build ID of the version of ZC being used.
    (Quest authors should only release quests for ZC versions that are stable releases (can be differentiated with Version). Letting authors see the build number just encourages negative behavior.)

    int Beta;
    * Returns the Beta ID of the version of ZC being used. If the build is not a beta, this returns 0.
    (See above.)
    I have to disagree with the red on these. Personally, I'd like a way to check if somebody is uncapping to speed up the game, to see if they're cheating. Perhaps it would be better as an int: int FrameRate. I believe ZC can already check the framerate with the use of f2, so why not let scripts read it? I'm not too sure about setting FPS/MaxFPS, though, as that seems like problems waiting to happen.

    Frankly, if we're trying to discourage building quests in betas, why release betas at all? I thought the point was to find as many problems as possible, and you kinda have to make a quest to do so. Not to mention, checking to see if somebody is playing in a beta is useful, as the quest could lock them out or alter features to improve the player's enjoyment.

  6. #6
    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%
    FPS: like I said, FPS rate is part of the GUI front end, not part of the game state, and game state has no business being coupled to it. It's the same reason there will never be a ZScript commands like "getScreenResolution" or "gameIsPaused" or "getKeyboardMappings" or "peekFileOnHostComputer." Just because the ZC code can access some client state does not mean it's a good idea to expose that state to the game engine.

    As a thought experiment, consider the possibility that in 1, 5, or 10 years:
    - ZC runs on a backend with no ability to query the frame rate;
    - ZC implements a "headless playback" mode that runs through prerecorded commands (as a way for authors to test late parts of their quest);
    - we decouple the screen refresh rate from the game clock rate;
    - etc etc.
    We want to be able to do this without worrying about old quests relying on implementation details of the graphics front end.

    Moreover, I don't see "cheat prevention" as a very compelling reason to need the FPS rate. If users want to speed up or slow down (or pause) gameplay that is their prerogative. One reason I do see as legitimate is testing for performance and turning off cosmetic effects on slow machines. But I don't find this reason compelling *enough* to take the extremely high-consequence plunge of tying the ZC game state to the ZC player GUI.

    Re: Betas. I do want people to use the betas, but I don't want them releasing final versions of their quests with instructions like "plays only on the ZC 2.50.4 RC5 Linux beta build because the script I use checks for this for some reason." (Yes, the Lost Isle build was a thing, but it should remain the only exception.) Neither of the QDBs allow posting of quests that do not work on stable builds and I fully support this policy.

    The only legitimate use of these variables is for scripts to try to patch compatibility bugs themselves, and this is a misassignment of roles. Compatibility bugs need to be fixed at the source level.

  7. #7
    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 Saffith View Post
    On the SVN log and Shardstorm.

    That's all we've got, unfortunately.
    Ok. I assume he had good reasons, and will mark the concern in the list above.

  8. #8
    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%
    Request: please change the topic title to [2.future] Merge Thread. I am only one of three people working on this fork.

    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.

    Subscreen Demo using this new variable pair, and itemdata stuff. I have some repetition in the global active script, so that I can work on deducing some timing-related things, but most of that could probably be trimmed to one pair of calls. This requires Beta 46 or later.

    @DarkDragon : 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 can move those itemdata attributes into arrays though. I was already planning to do it, once I was sure that they were all tested. MiscN will become Attributes[15], and AttributesN will become Sprites[10].

    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.

    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.

    One reason I do see as legitimate is testing for performance and turning off cosmetic effects on slow machines.
    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.

    I have no objection to weapon->SetDefenseType, or something like that, but defining weapon defences on the weapon, solely, rather than on the npc, is downright silly.

    int Modifier;
    * The Link Tile Modifier
    (There are some general concerns that need to be sorted out regarding items vs itemdata. Will setting itemdata automatically update the corresponding variables for all items using that itemdata? Or only affect new copies of that item?)
    It affects every item using that itemdata index. That's how it has always worked.

    Really, one thing I need to ask, is who is going to overhaul weapons, sprites/objects, and Link? I mean, truly do the work? One person doing that, is insufficient, and we all know it. Is that stuff due for an overhaul? Certainly. is it likely to happen in the next two or three releases? Probably not.
    I had considered returning the refresh rate as float, purely for that reason, but I also didn't see it as practical.

    Expanded -?>Misc[] shouldn't bloat. It's adding 32b*16 to each object, but they are all temporary objects. NPCs and *weapon in particular, I can list several scripters who beg for this kind of expansion, as they flat out exhausted all of these indices. Hell, my own lweapon/itemdata header would eat up a significant number of the normal 16. This isn't like Screen->D, where the values are in perpetual use, and even if they were, it's 255 maximum objects of each type, compared to N-screens*N-dmaps of FFCs that re always active. I would say that adding memory management to a future version should be a higher priority than worrying if a few pointers use 512 extra bits of space each.

    Hell, even if you flood the screen with them, that's 16KB per object class. Thus, at max items, npcs, lweapons, and eweapons, that is 64KB of memory space. How exactly is this bloat?

    Game->Beta, sure I could remove it. I put that in place as a minversion check. The same for ->Build. We had a number of issues last year with compatibility bugs, and no way to reach the build ID. This kind of variable would be useful to scripters to ensure that things can be coded to work differently, if necessary, for different builds.

    int WalkTile, SwimTile, DiveTile, SlashTile, JumpTile, ChargeTile, StabTile, CastingTile, PoundTile, FloatTile
    Hold1LandTile, Hold2LandTile, Hold1WaterTile, Hold2WaterTile;
    * A series of fourteen individual setter/getter ints to set or return the tile for all of Link's various actions.
    (All of the above expose dangerously low-level details about Link's animation code.)
    That may be true, but the way that Link's animation works is bound together with sprites, anim styles, and sizes, that are quite frankly impossible to work around. If you replaced the present system, it would still need to respect these for compatibility. What would your approach me here? OTIle certainly works for NPC sprites. They simply have fewer.

    int WarpEffect;
    * Sets a warp effect type prior to doing Screen->Warp
    (Adding extra state to the script engine that modifies future warps dangerously increases complexity. This functionality should be exposed only through a new function call e.g. Screen->WarpExtended())
    int WarpSound;
    * Setting this to a value other than '0' will play that sound when Link warps.
    (Via any means, or only when warping using Screen->Warp? Some control over game sound effects is reasonable but this series of variables does not seem fully thought-out. Maybe replace with an SFX slot per warp type? )
    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:

    Warp Type, tile, side, pit, invoked_from_string
    Warp Sound for each type
    Warp return for each type
    Warp visual effect for each type

    bool SideWarpSounds;
    * If you enable this setting, the warp sound will play in side warps.
    (See above)
    I planned to replace this with a unique sound ID to play, with 0 being none.

    bool PitWarpSounds;
    * If you enable this setting, the warp sound will play in a pit warp, one time.
    (Adding this kind of state to the engine (sets up a delayed effect that only happens once, next time Link warps) is unnecessary and dangerous.)
    It was actually harder to make it occur one time, than all of the time, and I'm scrapping this anyway, in favour of a unique int PitWarpSound, to store an ID. Pit warps are used for a umber of effects, many of which in older quests should be silent, That's the only reason that I added this as a one-instance change, as I needed to test it out, and see if this could break old quests. Then again, I could just read the ZScript version or something to prevent that.

    int UseWarpReturn;
    * Setting this to a value between 0 and 3 will change the target return square for Link->Warp
    (Should be added as a new function e.g. Link->WarpToWarpReturn)
    I can see adding a replacement function to do many of these things, but some, such as WarpSOund, affect non-scripted warps as well. This is by design. UseWarpReturn should, in factm override the warp return for tile warps, which can be useful.

    I have no problem adding new ZScript functions to do some of these things, but to be quite honest, in programming anything from tiny ffcs, to huge engines that run in ZScript, I have often found that I would have preferred a separate variable to set, rather than using a function parameter. For one thing, let's say Warp, I would prefer to be able to change the sound at any time, for any reason. Adding a scripted Warp(...) function that includes a sound parameter, would not do that, without actually warping.

    Using variables that an be changed at any time, greatly increase the flexibility of the language. In fact, I would love to tie all sounds to a ZScript array with a size of MAXSOUNDs, so that the user can assign any in-built sound event to a sound ID, and be done.

    int HitHeight;
    * link's Hitbox height in pixels starting from his 0x,0y (upper-left) corner, going down.

    int HitWidth;
    * Link's Hitbox width in pixels starting from his x0,y0 (upper-left) corner, going right.

    int HitXOffset;
    * The X offset of Link's hitbox, or collision rectangle.

    int HitYOffset;
    * The Y offset of Link's hitbox, or collision rectangle.
    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.

    This is in fact, why there are nearly no quests that use the feature, as, for example, with 16x32 Link., inly his lower half is subject to collision. Likewise, quests that would have him duck, would break, if the reverse was the only option. At present, the ZScript workaround is extremely ugly, few people want to try doing it, and it is subject to horrible bugs. The only viable solution at present for scripters: Bind an ffc, or weapon to be drawn over Link at all times, and constantly do manual, forced collision checks on it. Ugly, buggy, and bogs down the system.

    All these do is add an existing check tot he collision code anyway. The variables have been there for years, and I added them to depend on an Extend attribute, as described in zscript.txt, also for years. |If you object to them on those grounds, that part is easy to change.

    -----------


    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.

    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.

  9. #9
    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 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.

    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?

    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.)

    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?

    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.

    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.

    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.

    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.

    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.

  10. #10
    Keese ywkls's Avatar
    Join Date
    Feb 2016
    Posts
    62
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    476
    Level
    7
    vBActivity - Bars
    Lv. Percent
    86.27%
    Quote Originally Posted by DarkDragon View Post
    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.
    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.

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