PDA

View Full Version : 2.future merge thread



DarkDragon
12-31-2016, 03:12 PM
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.

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

Saffith
12-31-2016, 04:12 PM
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?

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.

DarkDragon
12-31-2016, 05:07 PM
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...

Saffith
12-31-2016, 05:10 PM
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.

Dimentio
12-31-2016, 05:27 PM
/************************************************** ************************************************** ********/

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

DarkDragon
12-31-2016, 05:50 PM
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.https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif

DarkDragon
12-31-2016, 05:56 PM
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.

ZoriaRPG
12-31-2016, 11:06 PM
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 (http://timelord.insomnia247.nl/zc/zc_dev/Subscreen6.zip) 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 (http://timelord.insomnia247.nl/zc/zc_dev/ZC_2.54_Beta_46.zip) 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.

DarkDragon
12-31-2016, 11:39 PM
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.

ywkls
01-01-2017, 12:27 AM
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 (http://www.purezc.net/index.php?page=scripts&id=235)

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 (http://pastebin.com/i1MSysmj)

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.

ZoriaRPG
01-01-2017, 12:41 AM
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 ) //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 [I]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 (http://www.purezc.net/index.php?page=scripts&id=235)

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 (http://pastebin.com/i1MSysmj)

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.

Gleeok
01-01-2017, 05:22 AM
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 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.




Really, download Gleeok's '[I]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. :P - 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.

DarkDragon
01-01-2017, 05:33 AM
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 (http://www.purezc.net/index.php?page=scripts&id=235)

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 (http://pastebin.com/i1MSysmj)

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

Gleeok
01-01-2017, 06:44 AM
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.

ZoriaRPG
01-01-2017, 05:00 PM
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. :P - 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/showthread.php?97635-Enemy-Editor-Defences-(Script-1-to-10)-Major-User-Request&p=911886&viewfull=1#post911886
http://www.armageddongames.net/showthread.php?97635-Enemy-Editor-Defences-(Script-1-to-10)-Major-User-Request&p=911893&viewfull=1#post911893


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?



//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

DarkDragon
01-02-2017, 12:56 AM
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.

ZoriaRPG
01-02-2017, 01:27 AM
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?