ZC [2.future] Development Plans [To-Do]

This is a separate topic, detailing things that we plan to do, or that we would like to do/add into 2.xx in the future. users are welcome to respond to this, but we'd like to keep feature requests, and bug reports in their own threads.

Italic listings are partially done.
Bold listings are implemented, but untested.
Green Italic are partially implemented to the point of being test-able.
Green Bold are done, and working.
Red Italic are likely impractical.
Red Bold are ruled as impossible, or abandoned.
Blue are ruled as extremely difficult, but potentially possible, or at least plausible.

Note that while this is a list of what we would like to accomplish, there is absolutely no guarantee that we will do all of what you see here!


ZScript

ZScript::Lexer, Parser, Stack

• Expand the number of gf registers to a large amount.
• Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.
• Add some mathematical things, and logical operators.( !<, !>, ^^, NAND, NOR).
• Read/set any ZC Interface options (e.g. FPS, Uncapped, MenuOpen) by script.
• Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.
• Add some directives.
• Increase the script buffer from ~18MB to MAX_LONG in bytes.
• Add additional routines for handling of strings. : Some implementation of string literals is done.
• Add 2D and 3D arrays.
• Add special datatypes, and declarations.
  
• Allow global datatype pointers/declarations. This involves preallocating some for this use, similar to arrays.
• Increase array operational pointers from 4096 to *.
• Increase other operational pointers for datatype objects from 255 to *.
• Add extra preprocessing support.
• Add some lexer symbols, such as ? (question-mark) to be used in function names, such as ?InAir()
  
• Add function pointers.
• Add custom defined datastructs.
• Add a few additional types for variables. : I was originally thinking of adding byte, char, long.
• Fix error messages to be more useful.
• Detect some common errors, such as reading an invalid pointer ( e.g. LoadNPC(0) ) during compilation.
• Include support for linked lists and hash tables internally.
• Add new typedefs that would be useful. : Grayswandir added typedef.
• Add new tokens, such as switch, case, and the like. : Added switch-case; still need define and enum.
• Add new directives, such as #DEFINE
• Add octal NUMBERS
• Expand IDENTIFIER to cover more (useful) symbols.
• Add user-defined pointers.
• Add user-defined objects.
• Add new types, especially those used by AngelScript.
• Add compile-time option to 'Export ZScript Code as AngelScript.
  --> This would work as 'Export ZScript code to ZASM' does now, and would create a file with the code as AngelScript. This is a 2.60 or 2.65 goal.
• Add 'Cross-Compile to AngelScript' output option.
• Add token defs for standard var declarations in both cases.
• Add AngelScript style and token, and or token.
• Add Until() and Unless() expressions.
• Add Repeat(int iterations) loop type.
• Add 'load' directive to load a quest with a specified file name into the present save slot, and change the assigned quest when loading that slot.
  
  • This is for serialised quests spanning multiple quest files.

ZScript::Global

• Add returns to detect if a screen is a dungeon, or other type, based on its DMap.
  
• Read any DMap value.
• Pretty much make any value read/write.
• Add Subscreen namespace,and allow easy subscreen construction.
  
• Allow datatype typecasting for objects.
  
• Fix problem reading the pointer of a boolean array.
  
• Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.
  
• Add functions to directly modify the palette, or tiles on a pixel-basis, or colour basis, including reading tiles for a colour value.
• Add internal global array series as easy to use defaults.
• Internalised Remove() : This should not be too terrible.
• Add internal Collision() ZScript function. : Partially done.
• Add additional weapon generation functions. : Added CreateLWeaponDx(int type, int origItem)
  
• Set/change quest rules by script.
  
• Allow setting an array size with numeric literal equations (e.g. 14+16) or constants.
  
• Allow loading any LSet or ESP, or CSet pal, into a normal CSet pal, or changing CSet values by script.
• Allow reading most internal variables, including enemy timers, and whatnot.
• Return engine properties as boolean flags; or make returns for uncapped(), and MenuOpen(), and CheatMenu(). : This will not be permitted in ZC Canonical.
  
• Return ZQuest version in which a quest was created as a global int. : I added a way to get the current ZC Version.
• Add method of reading system time, and date.
  
  • This would allow setting time, or events in a quest, based on real-time events.
• Add PrintToLog(char str) to ZScript.
  
  • This would print the contents of 'str' directly to the log, without needing to declare a ZScript string. : The new string literals handle this with TraceS().

ZScript::itemdata
Nearly Done

• 
  
• Add all editor values, including Attributes[10], and ensure that all item data resources, and itemdata resources cross over, including Sound, Cost, Level, and so forth. 99% done.
  
• itemdata values at present don't include about 80% of item attributes.
  e.g. The values for a Peril Ring, only allow modifying its Power, but not its min_hearts. We can solve this by ensuring that all attributes are available (read/write, while we're at it). : Done.
• Allow custom itemclass definitions, and arguments via Attributes[10]
  
• Make all values read/write. : Should be done for itemdata.

ZScript:Objects

• Get UIDS of all objects.
• Use UIDs as references.
• Store the script id that spawns a weapon, ffc or npc with it. : The new messaging system should permit this.
• Add a NoRemove boolean to all objects, so that if they are off-screen, they are not removed when this is set.
• All object types should have 'bool ObeysGravity'.

ZScript::*weapon

• Allow easy crossing of all itemdata values. This is to allow making a weapon by reading the itemdata values of any existing item, or npcdata (see below).
  
• Correct bomb and flag interaction with wLitBomb and wBOOM for scripted explosions, possibly adding LW_EXPLOSION as its own weapon type. : THis is much harder than it seemed at first. I did add CreateLWeaponDx() which properly reads the sprite from a bomb item when making an explosion. (It reads Sprites[0] from any item.
  (!) Added CreateLWeaponDx(), which forwards datum from a specified item to use its sprites, and sounds for LW types that do not have such properties, such as LW_PBOMBBLAST.
• Add bool ObeysGravity to all weapons.

ZScript::npc

• Add Defences[] for all ten script types. (added as npc->ScriptDefense[10])
• Ensure that all values are r/w.
• Allow creation of custom npc classes (with attributes defined by script).
• Add npc weapon attributes to match all values available to *weapon, so that the user may set them.
  This includes, for example., npc->WeaponSound, npc->WeaponPower, npc->WeaponSprite, and the like.
• Give components of a segmented enemy unique flags, and allow access to them individually.
• Add user-defined movement styles.
• Replace(npc n) to change one npc for another, without needing to silently kill one, and spawn another.
• Add ->Invincible attribute. Read to see if an npc is invincible, or set true to make it invincible. (i.e. guy::superman)
  
• Allow reading, and writing to npc lists anywhere in the game environment.
• Modify CanWalk() so that it checks if the npc's Step has changed since the last frame. In fact, it needs to do the following:
  
  • Do a CanWalk(), store Stepin LastStep. If LastStep differs, recheck.
  • We need some re-check before committing the walk movement, in the event that a user writes to Step.
  • At present, Step is not rechecked, and if a user writes to it, during the phase at which an npc begins moving, the npc can walk into solid tiles.

ZScript::npcdata

• We plan to add this, to operate as itemdata for nocs, so that you can read npc values without creating them, and waiting for them to spawn.
• Dynamically modify main npc attributes, such as walk type.

ZScript::Link

• Add Walkspeed attribute as a variable.
• Diagonal movement, Big Hitbox, and Extend by ZScript.
• Make all values r/w
  
• Add Link->Extend, so that all the Link hitbox, and drawoffset, and similar things work.
  
• Allow setting Link->Tile
  
• Finish defining some of the missing Link->Action types.
• Allow pre-waitdraw adjustments to Link variables that do not work at present.
• Make all values r/w.
• Add shield block flags to cover all script types.
• Add some ->Action types
• Add Z3 sword class.
• Add a flagset to indicate button presses, and inputs.
  
• Add ->Invincible attribute. Read to see if Link is invincible, or set true to make him invincible. (e.g. superman, not CollDetection; or as a special circumstance that ignores some collision?)
  (!) Added Link->Invincible, which uses his invincibility frames.
  
• Allow setting Link's equipment.

ZScript::Screen

• Increase Screen->D[] regs to 256. (not happening, because of memory usage).
• Add function to SetScreenBoundary() s that scrolling occurs when the player passes its event horizon, instead of the default screen edge. This would allow for different screen sizes.
• Display passive subscreen, set by flag, or script.
  
• Read/set any screen flag by script.
  
• Read npc lists from any screen in the game.
• Add TriggerSecret(int specific_secret) -- This will require making secrets into a flagset on the ZScript side.
• Detect screen changes and add a timer to determine how long it has been since the screen changed.

ZScript::Script Drawing

• Add additional routines for bitmap handling, including translucent rendering to screen.
  
• Increase bitmap area to a very large size (possibly for advanced panning, or scrolling)
• Add missing drawing functions, such as Polygon() and Polygon3d()
  
• Allow setting a bitmap as a texture to a drawn object.
• Allow creating user-defined bitmaps with user-defined IDs at specific sizes.
  
• Allow saving user bitmaps directly in the quest file.

ZScript::ffc

• Complete solidity flag, and allow it to be used with multiple types.
• Add solidity bounds as variables.

ZQuest Editor

Editor::Enemies

• Add editor flags for various npc options, including invisibility (by type) and reveal invis (by item).
• Add block flags by specific script type.
• Add death sprite, and other death effects.
• Move hardcoded enemy effects to user-defined attributes.
• Add 'Invisible', 'Cloaked', Item Class Reveals Insivible [ field ], Item Reveals Invisible [ field ], Itemclass Reveals Cloaked [ field ], Item reveals cloaked [ field ] to the ditor.
  --> This would allow the user to specify if an enemy is cloaked, or invisible, and set up a specific item, or itemclass to reveal them.
• Add 'Lens Reveals Invisible', 'Lens Reveals Cloaked', 'Amulet Reveals Invisible', and 'Amulet Reveals Cloaked' to each enemy as checkboxes. These work in addition to the specified classes, and items (above).
• Add 'Splits into enemy (ID, number of enemies) on hit', Splits into (enemy ID, number of enemies) fields to every enemy.
• [B]Add all ten script defence types as individual settings.
  ->Generic 'Script' would continue to work for any type. (THe old 'Script' value is forwarded to the new ten at present.)
• Add 'Split' as a defence outcome. This means that the enemy will split into its defined split variety when hurt by the specified weapon type.
• Add 'Whistle' defence type. Make Digdogger's Whislte Defence 'Split'
  
• Add 'Double Damage' as a defence outcome.
• Add combo type 'Sideview Ladder'
  
• Add combo type 'Pit (Damage)' with different heart damage values and falling LTMs. This should make a sound, set LA_FALLING, and send Link back to the spot at which he entered the screen.
  
• Add combo type 'Lava/Fire' with damage values. This should make a sound and send Link back to the spot at which he entered the screen.
• Add Link->Action LA_ONFIRE
• Add Link->Action LA_FALLING
• Add Link Variable FireDamage
• Fix LA_SPINNING so that it does the spin animation on demand.
• Fix LA_CHARGING so that it always displays a charging animation.
  
• Fix LA_CASTING so that it always displays a casting animation.
• Add Link var ChargingItem so that we can set what item Link is holding out.
• Maybe ChargingSprite?
• Add Link->Useitem(int itm). This will use an item even of it isn't in an A/B slot.
  
• Add Link->SetItemA/B internally, instead of the std.zh pressDirand subscreen madness. This will set an item to A/B directly. It should have a param 'bool force' that sets it even if Link doesn't have it.
  
• Add way of detecting what item Link is using.
• Add Link->EquippedItems. When gaining an item, this is set true by default, but can be disabled/enabled without needing to set owning the item to false to temp orarily disable it, or allow equip menus/subscreens.
• Add Link variable FireDuration. This should be reduced by 1 per frame, internally.
• Add Link->Input and Link->Press flagsets.
  

Editor::Items

• Add 'Can Pick up Items [ field: list item numbers, separated by commas ]' to allow the item to pick up anything listed that it touches.
• Add 'Deliver items picked up on contact' and 'deliver items picked up when weapon returns to Link' as options for delivery.
• Allow setting the Misc Attributes for generic class items as [ text fields ] instead of greyed out pulldowns.

Editor::Rules & Quest Settings

• Add duplicate point to set Link movement and related attributes rules in QRs panel, in addition to the Link->Graphics panel.
• Expand the amount of the text field for quest details in header.
• Add 'Quest credits' to quest header.
• Enable visibility of 'Quest Number', rather than needing to press a special key to view, and set it.

Editor::Other

• Add flag editor.
• Add font editor.
• Enhance subscreen editor to support multiple pages, and other action types (equip/unequip)
• Add option to use specific script object (weapon, or otherwise) in editor options that use them.
• Allow setting any pulldown value to a custom value (with field for entry). For example, npc and item values.
  
• Add additional user-defined flags, for use with flag editor.
  
• Add SCCs for more robust options, and to complete some partially-implemented things.
• Allow more than 8 script args for editor panes.
• Display passive subscreen as a separate option from show subscreen in editor pane.
• Allow setting subscreen display by DMap, instead of by specific screen.
• Allow any screen flag to be set for all screens on a given DMap from one editor pane.
• Add quest templates, with pre-loaded tiles, scripts (enemy, bods, engine, items), for 'Z3-esque', Gameboy-esque', and 'RPG'.
  --> These could probably use a *.cgf file to set that, and whatnot, that is read into a buffer. We could then present it in its own GUI window, where a user may toggle settings, and when a user changes (and commits) anything, ZQ would automatically (and silently) recompile using the .cgf file through an import directive in the main buffer.
  --> pretty much, when the user saves changes, the save is written to the *.cfg file, and then the main buffer (with a call to import "questtemplate*.cfg" is recompiled, and all slots automatically reassigned, without displaying any of the manual parts of compiling.
  --> This is so that the user never needs to look at the scripts directly.
  --> Essentially a new 'Classic/Z1' quest would be what we use now, but the other options would load a quest template with all of the things needed to make that style of quest, pre-configured.

17-Jan-2017 : Updated

Zelda Classic (Viewer)

Zelda Classic:General

• Integrate the agfont library, adding TTF support to ZC.
• Allow editing ag.cfg via GUI/menus, using ZC.'
• Allow reading from allegro.log, or some kind of external file.
  
  • If another external file, then ZScript will need to be able to write to it.
  • We could probably build this into a TCP/IP communications stack, for strategy games.

General

General::Quest, Save

• Save datum carryover between numbered quests.
• Fix combos that only work on layer 0, to work on higher layers, adding any ZScript components that we may need.
• Improved sideview mode.

General::Flags

• Add Flag (Explosion Trigger ( combos that are triggered by contact with LW_EXPLOSION).
• Add: EWeapon trigger flags.

General::Misc

• Add 2-player, support, and multiple input device support.
• Potentially find a way to solve the need to make fresh saves when changing vars, or arrays.
  
• Add internal version detection, and reporting (when loading/playing a quest).
• Change ffc loading from absolute (all screens, all DMaps at the start of the game), to a pre-emptive loading; else allow reading, and running ffcs on other screens.
• Other ffc changes/improvements.
• Allow 8-bit icons, and improvements to save slot/name entry/display.
• Allow changing some system hardcoded colours, such as shoppe rupee prices, and death animation red flash.
• Push all game save data to another quest file, for sequel support.
  
• Fix large Link hitbox in sideview.
• Global (not screen-based) script-executing objects, like FFCs, but without ffc properties.
• Fix scaling 8-bit tiles/sprites, and such. At present, their colours are ruined when downsized.
• Might need to fix up-sizing 8-bit, too?
  
• Possibly allow higher resolution sprites, via scaling? Can we do this if we double the screen size, and pixel ratio?
• Find out why counter values, that are supposed unsigned ints, behave as signed ints; and fix rollover.
• Possibly convert counters to be signed longs.
• Make x/y/z coordinates floating point values, so that it is possible to increment/decrement them in fractional units of pixels. Note that they would still be floored when drawn, but it will be possible to store a coordinate value of 10.023, for example, which would be drawn as 10.
• Sideview slope (diagonal movement) combos.
• Add 'Sideview' DMap flag, for sideview quests, so that it is not mandatory to set this on a per-screen basis.
• Add subscreen object 'Equip/Unequip'

External

Quest-template::Gameboy

• Include a Gameboy quest template that includes most, or all of the content belonging to Link's Awakening, and the Oracle games, so that users may build similar quests without the hassle of piecing together all the scripts, graphics, and such.

Quest-template::Z3-Esque

• Something based on Pure, or similar. Possibly a Z3 tileset, with Z3 enemies, items, and bosses?
• This does not mean Z3-Screolling. Don't ask.

Quest-template::RPG

• Could be based on the RPG.zh engine, with a 'Dragon Quest' tileset, items, spells, menus, and the like.

Headers::std.zh

• Expanded std.zh for 2.53 and above.
  
• Includes a config file.
• Includes new functions, and constants.
  
• Includes expanded string,zh, that is now considered part of std.zh proper, and imported with it.
  -->This will not conflict with scripts that import string.zh.
• mem.zh for advanced array handling.
• Possibly linked lists and mock function pointers, until we add those internally.

Docs::ZScript

• Usage docs for ZScript, with examples.
• Usage docs for std.zh and all related files.

Docs::ZScript Parser

• Explains how the parser works.

Docs::Script Tutorials

• Self-explanatory, but we will list what we complete.

Docs::ZQuest Manual

• A big, long, horrific nightmare.
  
• Any volunteers to assist with writing this bastard?

Docs::ZQuest Tutorials

• PDF format.
• Video format, if we have a volunteer to record them.

Tools and Utilities::Editors and Viewers

• String Table Editor
• Palette Editor/Viewer
• Subscreen Designer -> We also need to be able to import subscreens as code.

Tools and Utilities::ZScript

• ZScript IDE -> Bobby Light's Java IDE might be usable as a base?
• ZASM Extractor -> Extracts ZASM from .qst file word table, back into ZASM instructions.

Tools and Utilities::ZLaunch

• Replace ZLaunch with LTMs launcher. or something similar that handles multiple save files.

Tools and Utilities::ROMView

• Fix ROMView, or replace with something new.

Tools and utilities::Misc

• Personal Quest Database, with quest rations, and such, that can be shared.

External::TCP/IP Communications

• Some method of transmitting text over TPC/IP via two Ip addresses on a given port, would allow turn-based strategy quests, and sharing seeds for randomised games, or time-based synchronisation.

22-Feb, 23-Feb,24-Feb : Some additions to the above llist, and other notations.
25-Feb: Expansions, plus 'External' category.
17-Jan-2017 : Updated

We're going to need to start tagging these things as goals for [2.53], [2.54], [2.55], and ['2.60'], along with who is working on each aspect. Note that '2.60' (above) implies that it won't be in 2.53->2/55, but in a later version. It might make it into an earlier release, but we can only plan on it for the future, and not for the immediate future.

Quest Files

Quests:Quest Details

• Allow setting a quest number for serialised quests, that does not require the quest to have a

27-Feb : Added some global values, and object values. By popular request 9and concern), bool ObeysGravity is now on the list for weapons, and other object types. This one might be a priority for 2.54/2.55

02-March:

Add: TriggerSecret(int secret)
Add: Flag (Explosion Trigger ( combos that are triggered by contact with LW_EXPLOSION).
Add: EWeapon trigger flags.

04-March: Added External:Tools and Utilities category, above..

16-March :

Added list entries for the following to the main categories, above:

• Add Until() and Unless() expressions. -ZoriaRPG/grayswandir
• Allow creating user-defined bitmaps with user-defined IDs at specific sizes.
• Allow saving user bitmaps directly in the quest file.
• Allow editing ag.cfg via GUI/menus, using ZC.
• Fix ROMView, or replace with something new.
• Replace ZLaunch with LTMs launcher. or something similar that handles multiple save files.
• Add Repeat(int iterations) loop type. -grayswandir

17-March:

• Add method of reading system time, and date.
  
  • This would allow setting time, or events in a quest, based on real-time events.
• Allow reading from allegro.log, or some kind of external file.
  
  • If another external file, then ZScript will need to be able to write to it.
  • We could probably build this into a TCP/IP communications stack, for strategy games.

Added: External::TCP/IP Communications

• Some method of transmitting text over TPC/IP via two Ip addresses on a given port, would allow turn-based strategy quests, and sharing seeds for randomised games, or time-based synchronisation.

Happy Spring!

21-March:

• Add PrintToLog(char str) to ZScript.
  
  • This would print the contents of 'str' directly to the log, without needing to declare a ZScript string.

22-March:

• Add 'load' directive to load a quest with a specified file name into the present save slot, and change the assigned quest when loading that slot.
  
  • This is for serialised quests spanning multiple quest files.

Quest Files

Quests:Quest Details

• Allow setting a quest number for serialised quests, that does not require the quest to have a

Editor::Rules & Quest Settings

• Add duplicate point to set Link movement and related attributes rules in QRs panel, in addition to the Link->Graphics panel.
• Expand the amount of the text field for quest details in header.
• Add 'Quest credits' to quest header.
• Enable visibility of 'Quest Number', rather than needing to press a special key to view, and set it.

I suppose I need to go over all this at some point...

Quote:

---

Increase the script buffer from ~18MB to MAX_LONG in bytes.

---

The buffer is just a std::string. Any limit on it is from that class, and it may vary by platform. Not that it's all that hard to replace, probably.

Quote:

---

Increase other operational pointers for datatype objects from 255 to *.

---

When is 255 not enough? That's a significant design consideration for an extremely rare case.

Quote:

---

Add some lexer symbols, such as ? (question-mark) to be used in function names, such as ?InAir()

---

Why? There's no way to fit that into existing naming standards, it would make it impossible to implement the ternary operator (not that I expect that to happen anyway), and there isn't any obvious benefit.

Quote:

---

Add AngelScript style and token, and or token.
Add Until() and Unless() expressions.
Add Repeat(int iterations) loop type.

---

Okay, I guess? Again, I don't see much benefit. It'll create more reserved words, and "repeat" in particular is likely to be used in existing scripts.

Quote:

---

Add function pointers.

---

That's going to be seriously limited without fundamentally changing how scripts work. Functions aren't shared among compiled scripts, so a pointer passed from one script to another would become invalid.

Quote:

---

Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.

---

UID behavior has already changed in a way that would break compatibility.

Quote:

---

Allow reading most internal variables, including enemy timers, and whatnot.

---

This is right at the top of the list of things we absolutely should not do. One of the big problems with ZScript is all the internal behavior it already exposes. Anything that's visible to ZScript has to remain in the game, or at least be emulated, indefinitely.

This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.

Quote:

---

Set/change quest rules by script.

---

Similar deal, plus there are several issues with it already. Lots of rules wouldn't take effect if set while the game was already running. We'd either have to rewrite a lot of stuff to address that, or just accept that it would be inconsistent and unpredictable.

Quote:

---

Add PrintToLog(char str) to ZScript.

• This would print the contents of 'str' directly to the log, without needing to declare a ZScript string.

---

That would require changing the way strings are compiled. And if you did that, TraceS would handle it, anyway.

Quote:

---

Increase Screen->D[] regs to 256.

---

That would increase memory usage by 134,912 bytes per map. And every byte of that is save data, which means load and save times for even small quests would be drastically increased. To take one example, the save data for Isle of Rebirth is currently about 2.24 MB; with this change, it would become 20.18 MB. And that vast majority of that would be totally unused.
If you come up with a way to do this that allows the memory to be allocated on demand and not saved unless it's used, it might be okay. Simply increasing the number wihtout changing its behavior would be unacceptable.

Quote:

---

Allow saving user bitmaps directly in the quest file.

---

Again, as long as you can do it on demand rather than saving all bitmaps for every quest.

Quote:

---

Add Link->SetItemA/B internally, instead of the std.zh pressDirand subscreen madness. This will set an item to A/B directly. It should have a param 'bool force' that sets it even if Link doesn't have it.

---

This sounds like the same thing as making Link->Equipment writable. That was the case in 2.50 until build 1187 or so, but it was disabled because it was too buggy and basically unfixable. I don't know the details of that, though.

Quote:

---

Allow 8-bit icons, and improvements to save slot/name entry/display.

---

Supporting 8-bit icons is impossible with 8-bit color. It would require having four palettes loaded at once.

Quote:

---

Find out why counter values, that are supposed unsigned ints, behave as signed ints; and fix rollover.

---

They're unsigned short ints, 0-65535. Drain counters are signed, however, and the counter mod functions take signed arguments.




I don't even want to think about most of this stuff. Suffice it to say, virtually nothing will be easy, and doing it without breaking existing quests nearly impossible.
It took eight years to finish 2.50 because more and more poorly written features were glommed onto a codebase that was already an unsustainable shambles. This is not a practice I am interested in continuing. Don't expect approval of anything that would make maintenance more of a nightmare than it already is.

Quote:

---

Originally Posted by Saffith

I suppose I need to go over all this at some point...

---

Well, we started making a plan out of this in January, but better late than never; eh?

Quote:

---

The buffer is just a std::string. Any limit on it is from that class, and it may vary by platform. Not that it's all that hard to replace, probably.

---

I suppose we'll find out when we try to do it.

Before I get too deep into this, I feel it important to note that I'm not quite on most of these topics yet. Of the list, there are only two things that I wanted to get into 2.55, which per our versioning plan, would be six months to a year following 2.53/2.54; and that is intended to be the first truly new ZC 2.x release out of our plans.

Dimentio did some npc stuff, and might have done some ZQ string control code madness that I personally want no part of, as Ikd rather not support YAL in ZC with SCCs to do ZScript stuff, which is what he was attempting to do.

Quote:

---

When is 255 not enough? That's a significant design consideration for an extremely rare case.

---

Actually, it's usually weapons that can easily exceed this, but there are some abstract applications for these objects, too. I think we tagged this as 2.6.

/quote]
Why? There's no way to fit that into existing naming standards, it would make it impossible to implement the ternary operator (not that I expect that to happen anyway), and there isn't any obvious benefit.
[/quote]

The termary operator ?: should be able to coexist. The way I was setting this up, the identifiers required that the ? was a leading, or trailing character, and I can put in an exception for STATEMENT ? EXPRESSION : EXPRESSION, or IDENTIFIER ASSIGN STATEMENT ? EXPRESSION;, or I believe that I can. This, and some of the other things to do with tokens, will come down to experimentation. If what I do works, I'll keep it. If not, I'll cut it, and cut my losses.

I know those aren't quite right, but ai'm flat out of steam at present.

In any event, ? by itself can be distinguished from ?[aA-zZ] or whatever identifier tokens you fancy. The key component is that the ? must be the first, or last char in the token. I could probably add a ternary token too, just to test if they are compatible.

Quote:

---

Okay, I guess? Again, I don't see much benefit. It'll create more reserved words, and "repeat" in particular is likely to be used in existing scripts.

---

Some of us just like these expressions. That comes from a language diversity, I expect, but they are useful in some readability aspects. Grayswandir requested a basic repeat statement, I think, and I'd like a do-until expression simply for clarity.

In these cases, I look at is a more of a kwhy notk situation. Repeat is just a shorthand for loop, and thus a shorter way of doing that. I've never seen it used in a script, though that doesn't make it impossible. In any case, our decision on this is that there may be small ZScript changes that require updating a minority of scripts, so unless we did something with sweeping impact--which is in the alloeed scope of 2.65 under our definition--it can stand.

It's not the first time this has happened, and even @Gleeok suggested replacing existing functions with new functions that use the same name, but with more params. I wasn't in favour of that, as that has a high risk factor in breaking existing scripts.

Quote:

---

That's going to be seriously limited without fundamentally changing how scripts work. Functions aren't shared among compiled scripts, so a pointer passed from one script to another would become invalid.

---

This one isn't my idea at all, and I wouldn't want to be the one to implemt it.

Quote:

---

UID behavior has already changed in a way that would break compatibility.

---

Please explain, and give further details on what this is supposed to mean.

Quote:

---

This is right at the top of the list of things we absolutely should not do. One of the big problems with ZScript is all the internal behavior it already exposes. Anything that's visible to ZScript has to remain in the game, or at least be emulated, indefinitely.

---

Which in turn, is one of the problems with making ZScript functions, and vars that can actually affect the game, without being hellishly buggy.

Quote:

---

This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.

---

That was sort of the implied direction for making these vars part of the npc class itself.

Quote:

---

Similar deal, plus there are several issues with it already. Lots of rules wouldn't take effect if set while the game was already running. We'd either have to rewrite a lot of stuff to address that, or just accept that it would be inconsistent and unpredictable.

---

Probably both, with incremental shifts towards full compatibility. Not as if there isn't already an arms' length list of inconsistent behaviour in ZScript, such as NULL values.

Quote:

---

That would require changing the way strings are compiled. And if you did that, TraceS would handle it, anyway.

---

The point of this one, is to make it possible to do TraceS() without using a pointer to an existing string: TraceStr("This is what we're doing" ). Of course, how to store that string is another matter, but doing anything with char isn't happening soon.

Quote:

---

That would increase memory usage by 134,912 bytes per map. And every byte of that is save data, which means load and save times for even small quests would be drastically increased. To take one example, the save data for Isle of Rebirth is currently about 2.24 MB; with this change, it would become 20.18 MB. And that vast majority of that would be totally unused.
If you come up with a way to do this that allows the memory to be allocated on demand and not saved unless it's used, it might be okay. Simply increasing the number wihtout changing its behavior would be unacceptable.

---

What is the specific memory footprint for a single index? When I do the math here, I'm coming up with a different value? (131072 Bytes).

I had not considered that this was another area where zc memory management was so broken. So, sure, if we made huge array sizes for screen datum, we'd need to compress out unused stuff and load it more dynamically.

It would still be nice to pop these up a bit, perhaps make it a size of 20, and make all the class->Misc[] arrays a size of 32. How bad is memory (RAM) handling for those? Probably the same issue, only it is based on object count.

Quote:

---

Again, as long as you can do it on demand rather than saving all bitmaps for every quest.

---

Naturally, it would need to be something that is added to a save file only after the bitmaps are first generated in a playthrough. The new functions to create bitmap space might help there.

Quote:

---

This sounds like the same thing as making Link->Equipment writable. That was the case in 2.50 until build 1187 or so, but it was disabled because it was too buggy and basically unfixable. I don't know the details of that, though.

---

Are the old (non-public) ZC dev boards from 2.11/2.5 still archived? It would be extremely useful to be able to read them, to find out what has been tried, and know the pitfalls. I only know that the intent was to be able to set/get any value.

Quote:

---

Supporting 8-bit icons is impossible with 8-bit color. It would require having four palettes loaded at once.

---

I'll need to look at how icons are drawn, but if you only allow a single 8-bit icon, or four 4-bit, it could work.

Quote:

---

They're unsigned short ints, 0-65535. Drain counters are signed, however, and the counter mod functions take signed arguments.

---

Why do the unsigned values roll at 32768? Is there any valid reason not to change them to the fixed type? Hell, I'd like to make signed fixed counters available.

Quote:

---

I don't even want to think about most of this stuff. Suffice it to say, virtually nothing will be easy, and doing it without breaking existing quests nearly impossible.
It took eight years to finish 2.50 because more and more poorly written features were glommed onto a codebase that was already an unsustainable shambles. This is not a practice I am interested in continuing. Don't expect approval of anything that would make maintenance more of a nightmare than it already is.

---

None of claimed it would be easy, and pretty much, the understanding is that if we make 2.5x stuff, we're stuck supporting it. Either way, it's all stuff we'd like to do, but not something we swear we'll be able to pull off, and it's part of a four-year overall plan, with one release a year, as the general model.

It's hard to say what on the list will prove possible on a per-version basis, or if itks even possible, until we write it, and test it. We aren't trying to strongarm you into doing any of this, at all. Really, we aren't looking to burden you with this; but we do appreciate being able to consult with you from time to time, as needed, to ask technical questions, as long as you don't mind doing that, while you do the things that you want to accomplish.

Now...I've worked a 22-hour shift, and been awake for 30+ hours, so I'm siging off, to pass out.

Quote:

---

The termary operator ?: should be able to coexist. The way I was setting this up, the identifiers required that the ? was a leading, or trailing character, and I can put in an exception for STATEMENT ? EXPRESSION : EXPRESSION, or IDENTIFIER ASSIGN STATEMENT ? EXPRESSION;, or I believe that I can. This, and some of the other things to do with tokens, will come down to experimentation. If what I do works, I'll keep it. If not, I'll cut it, and cut my losses.

---

You'd also have to do extra work to exclude ? itself as an identifier and require spaces around it, which would be more arbitrary differences from everything else. Otherwise, you run into unparseable cases like
int x=foo??bar:baz;
Again, I don't expect it will ever be implemented anyway. DarkDragon considered it more trouble than it was worth, and I'm inclined to agree. Still, I'd rather keep the option than give it up for a cosmetic feature.

Quote:

---

In these cases, I look at is a more of a kwhy notk situation. Repeat is just a shorthand for loop, and thus a shorter way of doing that. I've never seen it used in a script, though that doesn't make it impossible. In any case, our decision on this is that there may be small ZScript changes that require updating a minority of scripts, so unless we did something with sweeping impact--which is in the alloeed scope of 2.65 under our definition--it can stand.

---

I generally don't like the idea of throwing in every random thing one or two people want. Not a good work-to-benefit ratio, though it's probably not a big issue in this case. Beyond that, my only real objection is that we have a mostly amateur scripting community, and many users struggle with basic aspects of scripting as it is. Adding new ways of doing things creates more stuff to learn and remember, and it will make for a more difficult transition to AngelScript when the time comes.

Quote:

---

Please explain, and give further details on what this is supposed to mean.

---

The sprite_list class has been rewritten and now assigns UIDs a bit differently. Manhandla heads and Patra orbiters will be numbered differently (they haven't been updated yet, so I don't know exactly how). Weapons created by a breath firing type are numbered differently. There may be more differences I'm not aware of.

Quote:

---

Which in turn, is one of the problems with making ZScript functions, and vars that can actually affect the game, without being hellishly buggy.

---

Doesn't matter. The more stuff that's directly exposed to ZScript, the more we can never fix or improve. Making more problems permanently unfixable is the last thing I want to do.

Quote:

---

Probably both, with incremental shifts towards full compatibility. Not as if there isn't already an arms' length list of inconsistent behaviour in ZScript, such as NULL values.

---

It's just too problematic. Quest rules were't made to be changed mid-game. I can't imagine how many bugs would result from it, beyond some of them simply not doing anything at all. Also, it'd make it harder to replace quest rules with superior options later on.
Quest rules don't make for a good scripting interface, anyway. If you put some rules one might reasonably want to change behind meaningful interfaces (e.g. Link->DiagonalMovement, Game->ContinueHealth), that should be okay. Even if the ZASM it compiles to is just SETQUESTRULE, that's less of an issue.

Quote:

---

The point of this one, is to make it possible to do TraceS() without using a pointer to an existing string: TraceStr("This is what we're doing" ). Of course, how to store that string is another matter, but doing anything with char isn't happening soon.

---

Do you mean that you want to store the string as text in the quest separately from scripts and the actual function argument would just be an index? And this would be denoted only by the function used? That's a thing you could do, I guess, but it seems a lot harder than just loading the string into a temporary variable in a way that would work with any function.

Quote:

---

What is the specific memory footprint for a single index? When I do the math here, I'm coming up with a different value? (131072 Bytes).

---

136 screens per map, 248 additional elements per screen.

Quote:

---

It would still be nice to pop these up a bit, perhaps make it a size of 20, and make all the class->Misc[] arrays a size of 32. How bad is memory (RAM) handling for those? Probably the same issue, only it is based on object count.

---

They're fixed for each instance, yes. But those are dynamically allocated and not saved, so it's less of an issue

Quote:

---

Are the old (non-public) ZC dev boards from 2.11/2.5 still archived? It would be extremely useful to be able to read them, to find out what has been tried, and know the pitfalls. I only know that the intent was to be able to set/get any value.

---

There doesn't appear to have been any discussion about it. Joe123 dealt with it on his own, as far as I can see.

Quote:

---

I'll need to look at how icons are drawn, but if you only allow a single 8-bit icon, or four 4-bit, it could work.

---

Not in the quest, on the loading screen. You'd potentially need three full palettes along with the colors for the screen itself.

Quote:

---

Why do the unsigned values roll at 32768? Is there any valid reason not to change them to the fixed type? Hell, I'd like to make signed fixed counters available.

---

They don't, as far as I'm aware. Can you give me a specific example?

@Saffith
He's talking about the counters, if you trace values to allegro they are signed and rolled for some reason.
In otherwords the internal does not match allegro log.

Quote:

---

Originally Posted by Saffith

It's just too problematic. Quest rules were't made to be changed mid-game. I can't imagine how many bugs would result from it, beyond some of them simply not doing anything at all. Also, it'd make it harder to replace quest rules with superior options later on.
Quest rules don't make for a good scripting interface, anyway. If you put some rules one might reasonably want to change behind meaningful interfaces (e.g. Link->DiagonalMovement, Game->ContinueHealth), that should be okay. Even if the ZASM it compiles to is just SETQUESTRULE, that's less of an issue.

---

Well, right. I was indeed going to add two levels of an interface to it. One that stores the QR values in an array, to modify, and another that uses ZScript hooks. i wasn't planning to make it fully direct. In fact, what i wanted to do was change the way they work, so tat we don;t run out of space, by storing each rule value in an index. Might be wasteful, but unless you want a second flagset...

I was not going to try to do raw Setter/Getter stuff for those. Sorry if that wasn't clear.

I did write some Setter/Getter stuff for things like bool Throttle. Not sure if you would want more abstraction for that stuff. (It's mostly Getter functions anyway.)

That other stuff for the most part, isn't a priority. I think expanding the misc indices for game objects (*weapon, nnc, and so forth) would be prudent, as using two or three headers now makes it easy to have issues with overlaps.

Insofar as stuff like ? as an icentifier, I did indeed add a list of exceptions that check for it. THe way I wrote it, the ? needed to be at the head of an identifier, with no spaces. also have qualms about mandatory spacing styles though, which came up when i wanted to add * to identifiers. WHile that would be nice, it's not necessary. I agree. I did write most of the support code to make it work, but I don't want to cause conflicts. '?' was less of an issue as we don;t use it anywhere else. You're probably right in any event, and maybe I'll add ternary to the parser when I feel like having me brains turn to pudding.

Comment blocks may be done now though, and case-switch is partially done. Not sure how long it'll be before I get back to that one, which I feel would be extremely useful, and compatible with whatever later interface you want. I should note that adding Repeat and Do-Until to AS should be easy, but neither of those have the same priority as case-switch and COMMENTBLOCK.

I also want to make illegal SINGLECHARs such as ` halt the compiler though. I did other things with the parser, but now I'm starting to forget what they were. I might eventually break down and make 2D arrays, but it's low on my agenda, and has a high sanity cost. I'll note here that I don;t really have huge issues comprehending flex, and there are many useful docs and tutorials, many of which I've read specifically for this reason.

I sort of want to make either a BAISC or COBOL language interface for ZASM, just for fun. I seem to recall someone trying to do that in the past, back in 2005-6, before I dropped off the map.

Last, I do have to disagree about who is using ZScript at an advanced enough level to make use of some of these things. We have a decent little (private) side community on Skype who all do some pretty advanced things on a regular basis, and I try not to underestimate the needs/desires of users, present, or new. We've had people sign up, and jump right in with no qualms, only to b*tch about things not existing. I tend to field a lot of stuff for/from users on ZScript support, so I pretty much see a lot more than most when it comes to both desires, and capability of users.

Our side community is meant for people who do advanced stuff though, but we have something like seventeen active participants who are in the chat nearly every day, and more are joining at sporadic intervals. We'd be happy to have you in chat too, but I know that you don't use IM.

Leave quest rules out of ZASM... That is one thing you do not want to tinker with @ZoriaRPG

I should just make things like 4/8-way movement a game variable in general. Not even a quest rule in the first place, but it's the most common request for a rule that can be changed.

One piece of advice: for each of the suggestions, include a paragraph justifying why there is a need for that feature (and even better, links to forum topics by quest authors demonstrating that need). For example I see many items in the list that could be implemented, and be somewhat useful in some situation, but don't seem worth the time or added code complexity to implement unless there is a demonstrated need by quest authors, like octal support, function pointers, global arrays of object pointers, etc.

I also cannot endorse Saffith's comment above enough:

Quote:

---

This is right at the top of the list of things we absolutely should not do. One of the big problems with ZScript is all the internal behavior it already exposes. Anything that's visible to ZScript has to remain in the game, or at least be emulated, indefinitely.
This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.

---

One of the big mistakes we made in the time between 2.10 and 2.50 is adding many new features without fully thinking through what the consequences would be for future backwards compatibility and for future ports and rewrites.

I see several mentions of AngelScript. Is somebody working on replacing ZScript with AngelScript (I think LUA was also discussed in the past as an alternative)? This is an excellent idea. It may even be worth considering Python.

Quote:

---

Originally Posted by DarkDragon

I see several mentions of AngelScript. Is somebody working on replacing ZScript with AngelScript (I think LUA was also discussed in the past as an alternative)? This is an excellent idea. It may even be worth considering Python.

---

Yes, that's the plan, though the details are still pretty uncertain. I like AngelScript specifically for of its C++-like syntax. It's similar to ZScript, which should make for an easier transition for the mostly amateur scripting community, and it's easy to adapt the existing code for anything we want to move out of the engine.

Quote:

---

Originally Posted by DarkDragon

One piece of advice: for each of the suggestions, include a paragraph justifying why there is a need for that feature (and even better, links to forum topics by quest authors demonstrating that need). For example I see many items in the list that could be implemented, and be somewhat useful in some situation, but don't seem worth the time or added code complexity to implement unless there is a demonstrated need by quest authors, like octal support, function pointers, global arrays of object pointers, etc.

I also cannot endorse Saffith's comment above enough:

One of the big mistakes we made in the time between 2.10 and 2.50 is adding many new features without fully thinking through what the consequences would be for future backwards compatibility and for future ports and rewrites.

I see several mentions of AngelScript. Is somebody working on replacing ZScript with AngelScript (I think LUA was also discussed in the past as an alternative)? This is an excellent idea. It may even be worth considering Python.

---

So, a bit of backstory. When ZC was first released as source, a trio of us pretty much wanted to work on 2.xx, keeping ZScript, as the userbase that we represent has a huge investment in it. We had some chats with Gleeok, and the original plan was that ZC3 would go with AngelScript, and that we'd be in charge of making new 2.xx releases, hence the 2.future tag.

The to-do list was pretty much something that all of us constructed, each with our own priorities, but who knows what would end up in there.

A lot of things on the list should probably make it in, and the most common requests are support for all the weapon types, npc scripts that run like ffcs, support for comment blocks in the parser, global pointers--when you see some of the things we're doing with the language, you'll understand--more control over Link (hitbox, sprites, tiles), and such.

Some of the things were more esoteric. Grayswandir is the one who wants function pointers, for example. We all pretty much want some things like switch-case, and more functions to handle internal ZC things, that should have been in there in 2.5, like GetDMapScreenDoor(), and expanded drawing.

There's always a realism limitation of course, but we do some pretty advanced stuff that is often hindered by limitations. ... and the group that we represent is pretty much the core of the ZScripting community. Typical users don't honestly even comprehend basic scripts, much less complex engines that run on top of ZC.

After a lot of back and forth bicker, the AngelScript plan was put on hold, and we all pretty much agreed to work on 2.54, 2.55, and 2.60 retaining ZScript. By 2.60, we could potentially introduce AngelScript, but I felt that would end up being a 2.65 thing, still supporting ZScript fully, and initially introducing AS so that users could start learning it, with AS being dominant in ZC3. I was hoping to do one major release per year, until ZC3 is ready, too. One main issue that I see, is that the userbase is dwindling, from stagnation.

The best way to attract new users, and keep existing ones, is to keep the programme fresh, so that they can explore new avenues of design. There hasn't been muc of a change since the 2.5 betas, so for the past six years or more, ZC has remained about the same, with few new capabilities. This has caused people to migrate to other tools that are more regularly updated, and if we wait until everything is done, instead of doing incremental new versions, there won't be anyone left to use what we create.

This happened in the 2.5 release era as well. People left the community because it took so long to produce 2.5, and some of them are only now returning, but these are few. The majority of new members want to do 'out of the box' things, and they rely on the scripting community to provide them.

For the most part, nearly none of these scripters had any interest in AS, in moving to something different, or in losing compatibility. Some of these engines are in excess of 100,000 lines of ZScript code, and porting them just isn't a realistic option.

If you want to see just how much can be done with your language, you should try this:

http://timelord.insomnia247.nl/zc/ZeldYs.qst - Moosh is working on this.

..and see...

https://github.com/ZoriaRPG/Backup_2...h-Main-Project
and
http://pastebin.com/0QrXNm3M - Grayswandir's LISP.zh implementation; he wants function pointers for things like this.

My focus has primarily been adding more script drawing, and adding more getter/setter functions, to do things that are either literally, or practically impossible. The GetDMapScreenDoor() example above is a good one, as there is no realistic way to read Screen->Door remotely. Most of the base functions could use a way to get/set them remotely, which is pretty straightforward, from what I can tell after ploughing through the ffscript code for untold hours.

As things stand, I'm working on a plan to submit, and discuss with the other devs, so that we aren't going in cross directions, and I'm hoping to compile and complete that in January. My time of late has been drained away by petty legal concerns, and my work, which at present has be very far away from home, and my office. (I'm out in the remote wilderness, typing this.)

Another major issue that I see as crucial, is that most users are on Pure, and all of these discussions occur on AGN. While it would be fantastic if they all joined here, realistically that just won't happen. I've tried to motivate people to sign up and participate here, and the common response is 'Why not just make a Dev forum on Pure for us?'.

I'll reiterate that, as it's important: We can't really get user input when we discuss this here, and the userbase is elsewhere. We need a Dev board on Pure.

From what I understand, the Pure staff are reluctant to add one, because AGN staff didn't want it in the past, but now that it's open sourced, we need to remove those objections, and allow a Dev board, with a bug reports board, there. Most of the bugs that we miss are ignored because users don't report them, and they don't report them because they can't do it on PZC.

Other than all of that, I have been (slowly) working on an improved docs set, that in the end, will become a comprehensive PDF. I would like to do the same for ZQuest, and I would also like to work on the Wiki, but there have been some roadblocks.

I would like to ask, while you are here, if it would be possible to move, or mirror the Wiki from Shardstorm to AGN, or to a server with a faster data path. I've had many user complaints that it takes forever to load, and this also makes editing it quite a tedious task. I'd also like to update the Wiki software at some point, to add in modern Wiki markup, as it's running a version that doesn't even properly support referencing. ...but all that is best discussed on its own.

In essence, while all of these other languages are fantastic on the surface, they don't have much appeal to the people actually using the programme. It is far better to plan out a slow migration, and allow users to gradually adapt to the changes. That's my tuppence worth.

I know nothing about any of this, incidentally.

I'm one of the ones who agrees that the change to AngelScript shouldn't be instantaneous. Immediately introducing a new language and then forcing people to ditch ZScript if they want the new changes isn't really a good plan, considering scripters are pretty much keeping ZC alive at this point. Hell, if 2.50 didn't have ZScript, I think ZC would be dead by now. I do think a new, better language would be great at some point, so long as we let people get used to it, allow them the time to learn it, and the like.

Truth be told, I think ZC needs a major rewrite. Looking through the code is almost like taking a tour through an archeological site, and frankly, all these variables whose purpose is not clear can go to hell. :P

If it's possible to add Angelsript at whatever pace you want, without dropping support for ZScript, I think that would be fine. But if you drop support for zscript, even if you replace it with a similar language, you are still disenfranchising some of the most active creators. (I wouldn't count myself as such a person, as I'm in the 'disappeared in the 2.10 days and only recently resurfaced' category, but, for my own position in the matter: I've pretty much completed my first full quest, by heavily relying on ZScript. I would not be eager to learn a different language right away; if I'm going to do that kind of thing, I would go off and learn something I can make programs in myself. But I am already working on ideas for a sequel... that rely on my knowledge of zscript to actually function.) Part of what might also happen if ZScript is dropped too hastily, is that many people will simply use 2.5.2 instead of the new version, which undermines the points of your hard work.

So basically, I'd totally be in favor of adding a new language, and even okay with you developing that language while not really expanding ZScript- as long as compatability for ZScript isn't dropped. I think that would be a terrible mistake. Just look at how many of the most popular quests rely on ZScript, you know?

As far as ideas for new features... I'm pretty sure it's already been discussed here, but I still think that splitting up the NPC Script weapon defenses into 10 parts (a separate defense setting for each of the ten LW_SCRIPTs) would be an excellent addition to the enemy editor, because it would make the separate script weapon types more useful, and much more likely to be used. Needing to script a workaround to constantly change NPCD_SCRIPT is silly, and many users don't even bother, or, as I did, encounter bugs in the course of trying to set it up properly. I also think that added the ten EW_SCRIPT weapon types to the default weapons you can set an enemy to have would be a good idea, because this enables users to easily put together enemies in the editor- without ghost- that use new weapon types that they can script global effects for. Lastly, I think one other enhancement the enemy editor could use, that would improve casual usage, is better built-in adjustments for enemy sizes- basically just a means to type in their tile width, tile height, hit width, hit height, draw X offset, and draw Y offset; those are admittedly pretty easy to set with scripts, but I think you'd get non-scripter users potentially making more interesting bosses this way. I don't know if any of these suggestions are really necessary, but they'd be extremely convenient, and reduce the barriers of confusion for those learning the program.

Regarding setting up a dev forum on PureZC... I'm not a terribly active forumgoer myself at either place, but I do think that would greatly expand your user feedback, since this place is definitely sort of a ghost town by comparison (I must admit I only saw this thread because someone else pointed me at it). Another very big problem is Zeldaclassic.com not keeping up with new version releases- this really undermines the point of having that site, doesn't it? I think updating Zeldaclassic.com would be a very good idea for getting more users to notice new versions.... I was using 2.5.1 until August because I had no idea 2.5.2 existed, because it was only posted on the PureZC forums, in a place I missed. Especially since PureZC's own download link also leads to Zeldaclassic.com, instead of the up to date forum posting. So there's sort of some executive/presentation confusion about the whole project....

In any case, I also want to say that 2.50 was an excellent improvement over 2.10. The ability to script new items and enemies is singlehandedly what made me interested again- finally I can have my Cane of Somaria and so many other neat things I wished for as a teenager. Thank you very much for making ZScript in the first place. Also... 2.50 in general, especially 2.5.2, are far, far less buggy and vastly more stable than the old 2.10 or various 1.92 versions. I've experienced almost no crashes myself, on Windows 7, except for when I did silly things like misusing a while loop when I was learning to script.

I look forward to seeing new developments for ZC, and thank you all for your hard work : )

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work. If backward compatibility weren't a priority, this would all be much easier.

There really isn't a good way to support both languages at once without undermining each of them. Enemies, weapons, and especially Link are all a complete mess, but we can't make any major changes to them without potentially breaking quests that depend on their weird behavior. Replacing them with scripted versions would fix that; their behavior would be part of the quests and unaffected by future updates. Continuing to support ZScript, whether or not the objects themselves were written in ZScript, would mean either keeping a lot of the weirdness we want to get away from or completely overhauling the language (which would be about as big a change as switching).

The ZScript discussion reminds of Houdini, a Blender-like 3D modeling tool that is commonly used in the special effects industry. For many years Houdini was highly scriptable using a DSL called "hscript" with its own syntax and parser, etc. This worked well for a while, but was a barrier to entry for new users and also somewhat of a pain to use since hscript lacked many of the advanced features and conveniences of mainstream scripting languages. At some point SideFX, the company behind Houdini, decided to switch from Hscript to Python. Houdini still supports hscript, but outside of legacy files and assets nobody really uses it anymore.

I imagine the most painless way to move away from ZScript to something like AngelScript would be to use a similar strategy. For a while, both ZScript and AngelScript are fully supported. Fully-scripted items and enemies are slowly introduced that coexist side-by-side with the old hard-coded ones, but new quests created in ZQ use the new enemies by default, and these new features only work with AngelScript. Old quests still play, but authors using ZQuest are increasingly incentivized to switch to the new system.

Quote:

---

Another major issue that I see as crucial, is that most users are on Pure, and all of these discussions occur on AGN. While it would be fantastic if they all joined here, realistically that just won't happen. I've tried to motivate people to sign up and participate here, and the common response is 'Why not just make a Dev forum on Pure for us?'.

I'll reiterate that, as it's important: We can't really get user input when we discuss this here, and the userbase is elsewhere. We need a Dev board on Pure.

From what I understand, the Pure staff are reluctant to add one, because AGN staff didn't want it in the past, but now that it's open sourced, we need to remove those objections, and allow a Dev board, with a bug reports board, there. Most of the bugs that we miss are ignored because users don't report them, and they don't report them because they can't do it on PZC.

---

I guess that's something to discuss with the folks at Pure. I don't know anything about this and don't particularly care to wade in, though I have to say I'm surprised to see that the drama and bickering between the sites continues in 2016 when it seems both sites struggle to get more than a dozen posts per day.

Presumably y'all have set up a core group of developers charged with curating the official repository and binaries. Hopefully you're on the same page about both the short and long-term development goals of the project, and have some centralized place to discuss this. But communication with the community can happen anywhere and in multiple places simultaneously. How to best handle users submitting feature request, pull requests, bug reports etc. is for you (the ZC developers) to decide. Both sites should be making facilitation of ZC development their unequivocal top priority. On the AGN side I can try to help relay any requests or concerns to War Lord (though I know I'm not necessarily much easier to get a hold of than War Lord himself... :() and my understanding is that Gleeok and Saffith have pull at PureZC.

Quote:

---

I would like to ask, while you are here, if it would be possible to move, or mirror the Wiki from Shardstorm to AGN, or to a server with a faster data path. I've had many user complaints that it takes forever to load, and this also makes editing it quite a tedious task. I'd also like to update the Wiki software at some point, to add in modern Wiki markup, as it's running a version that doesn't even properly support referencing. ...but all that is best discussed on its own.

---

Agreed; War Lord and I are already coordinating on doing this.

Quote:

---

In essence, while all of these other languages are fantastic on the surface, they don't have much appeal to the people actually using the programme. It is far better to plan out a slow migration, and allow users to gradually adapt to the changes. That's my tuppence worth.

---

From what I'm seeing in this thread, it seems everybody is on board with gradual change.

Quote:

---

Another very big problem is Zeldaclassic.com not keeping up with new version releases- this really undermines the point of having that site, doesn't it? I think updating Zeldaclassic.com would be a very good idea for getting more users to notice new versions.... I was using 2.5.1 until August because I had no idea 2.5.2 existed, because it was only posted on the PureZC forums, in a place I missed. Especially since PureZC's own download link also leads to Zeldaclassic.com, instead of the up to date forum posting. So there's sort of some executive/presentation confusion about the whole project....

---

Yes, this is a perennial problem. The current ZC lead developer should have access to zeldaclassic.com, but should not be expected to have the time or skills to keep the site maintained. The site needs a webmaster who is competent and active, which is a lot to ask. War Lord is currently working on fixing the site in the short term, so if you know somebody who might fit the bill in the long term, please do encourage them to contact War Lord.

There were no plans to remove ZScript immediately from ZC. This is also a practical approach; there's simply too much work to be done first. If the day comes when we have the luxury to either deprecate or rip out ZScript entirely, then it's not going to be a breaking news story by any stretch. The amount of work it would take to get ZScript to the level of angelscript feature-wise is simply ginormous (It [angelscript] has been in development for 10+ years after all). This includes both the end-user scripts and the ease-of-use of working with scripting from within the codebase itself. That said, I personally don't have problem with leaving ZScript intact until the last, if for no other reason than removing it would be at the bottom of my list of fun things to do to spend my time.

Quote:

---

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work.

---

Ooh- in that case, it occurs to me that even if you had people who wanted to continue developing in ZScript after new versions dropped compiling support for it, then you could simply build your quest in an old version and then port it into the new one for release. If that'd even be something people would want to do given the timescales it sounds like you're thinking of for this change. So that does kind of keep options open; rather than making ZScript unusable/obsolete, it would merely gradually reduce the convenience and practicality of using ZScript, so that sounds okay.

(More comedically, I'm picturing someone trying to make some sort of 2.5.2 virtual machine in Angelscript, though... XD )

How to run Zeldaclassic.com is pretty much your guys' call, but.... what might be more reliable, is instead of having a single webmaster that can edit the site, if you instead had a handful of key staff members all have access- such as Saffith, who posted 2.5.2- so that once a new version is done, then they don't have to get in touch with somebody less active to update it. A very small group of the most trusted developers all having Zeldaclassic.com update privileges, sort of like a shared dropbox kinda deal, basically.

Quote:

---

the amount of work it would take to get ZScript to the level of angelscript feature-wise is simply ginormous (It [angelscript] has been in development for 10+ years after all).

---

Oh? That sounds really cool. ZScript is already pretty amazing (for a few examples, I know someone was having some progress making an adaptation of Ys with free-range scrolling and a custom hitbox system; and there's been a lot of amazing items and custom bosses, and special puzzles, and all that good stuff. Being able to move X and Y, do drawing commands- including scaling, rotating, and some limited 3D textured shapes - and turn collision detection for just about anything on/off, goes a very long way), so if Angelscript can do all that kinda stuff and more, that should definitely be intriguing.

I don't suppose Angelscript can mess with screen scrolling behavior and built in Active Subscreens, can it?

Theoretically, it can do pretty much anything; it's just a matter of making the functions available to it. For scrolling and subscreen stuff, it's more a question of putting those features into the engine. I expect both will happen, but nothing's definite right now.

I'm not really sure what a gradual change would mean. We need to replace the whole sprite class, and continuing to support ZScript after that means making a separate version of the script engine to work with the new classes. Changing the combo system would mean all the scripts using Screen->Combo* or Game->Get/SetCombo* break. Same deal for flags. The whole itemdata type depends on the current weapon implementation. There are all sorts of weird little things; weapon->DeadState, screen flags, the behavior of directions outside the range of 0-7... How far do we go to keep existing scripts working? And if we're okay with breaking scripts, why go to any trouble at all when only the most trivial will keep working?

Maybe it will become clear in time. It's not like this is something that's going to happen overnight.

Quote:

---

Originally Posted by Saffith

Theoretically, it can do pretty much anything; it's just a matter of making the functions available to it. For scrolling and subscreen stuff, it's more a question of putting those features into the engine. I expect both will happen, but nothing's definite right now.

I'm not really sure what a gradual change would mean. We need to replace the whole sprite class, and continuing to support ZScript after that means making a separate version of the script engine to work with the new classes. Changing the combo system would mean all the scripts using Screen->Combo* or Game->Get/SetCombo* break. Same deal for flags. The whole itemdata type depends on the current weapon implementation. There are all sorts of weird little things; weapon->DeadState, screen flags, the behavior of directions outside the range of 0-7... How far do we go to keep existing scripts working? And if we're okay with breaking scripts, why go to any trouble at all when only the most trivial will keep working?

Maybe it will become clear in time. It's not like this is something that's going to happen overnight.

---

Well, those are good questions, but let's look at the case of combos specifically. In my mind the "right" way to implement combos would be to have them all be scripted, with users selecting from a palette of pre-written combo scripts, rather than a palette of hard-coded combos (which is what we have now). How might this be implemented? The first step would be to introduce a "scripted combo" combo that uses AngelScript scripts that do not interact in any way with ZScript. New users who pick up ZQuest make their quests entirely out of these "scripted combos" and are none the wiser that anything else ever existed before, but the hard-coded combos are still supported (for backwards compatibility with old quests). ZScript can try to use Screen->Combo* but these function do not do anything interesting for the new "scripted combos" (I suppose ComboD returns a generic ID indicating that the combo is a scripted combo).

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

Quote:

---

Originally Posted by DarkDragon

Well, those are good questions, but let's look at the case of combos specifically. In my mind the "right" way to implement combos would be to have them all be scripted, with users selecting from a palette of pre-written combo scripts, rather than a palette of hard-coded combos (which is what we have now). How might this be implemented? The first step would be to introduce a "scripted combo" combo that uses AngelScript scripts that do not interact in any way with ZScript. New users who pick up ZQuest make their quests entirely out of these "scripted combos" and are none the wiser that anything else ever existed before, but the hard-coded combos are still supported (for backwards compatibility with old quests). ZScript can try to use Screen->Combo* but these function do not do anything interesting for the new "scripted combos" (I suppose ComboD returns a generic ID indicating that the combo is a scripted combo).

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

---

Honestly, if people want to do a rewrite as ZC v3.x, backward compatibility is going to take a hit one way or another. I was originally in favour of continuing 2.xx development, and allowing a rewrite (3.0) to be clean, possibly working on platform stability in future 2.x updates, and working out some way to make a 2.x quest 'player' in the 3.0 engine, that handles all these quirks directly through new, clean code.

The alternative is a big case statement that reads the quest header, and does A if it's 3.x, or B if it's 2.x, for just about everything.

There's no reason that 2.x has to die for this to work, and there's no reason to abandon the community using 2.x to allow a rewrite. I don't really think tha tthe userbase has ever really been consulted on any of this, and insofar as deprecating ZScript, the community opinion has been unfavourable to this outcome.

An important factor, is that ZC is no longer the only game in town. I'm unsure if @DarkDragon has looked at the Solarus engine. IMO, that is the right direction for ZC3. Every object in Solarus is scripted... If you went that route, and you had easy to use attribute editors so that scripting is not a mandatory requirement to use the flipping thing (note that Solarus does not yet do that, but it's on @Christopho ' s plan), you would have something that can hold up to the test of time.

You could even allow stock Z1 style questmaking, by setting the bitmap scrolling areas to one-screen regions, and adding a scripted subscreen bar. ...but the reality is, that ZC3 should be something that keeps up with the other gamemaking engines, instead of the arcane and antiquated methodologies that it employs at present, and in so doing that, you pretty much relegate old quest compatibility to a side-programme. Other utilities do this. Hell, Apple did it when they came out with OSX, running older programmes in a VM that sort of invisibly ran in the background.

That might be the thing to do, for 2.5 compatibility in the future: Some kind of invisible background process that runs the quest on top of the new engine.

All this not withstanding, in my ehttp://armageddongames.net/showthread.php?97486-ZC-2-future-Development-Plans-To-Do&p=912319#post912319w3stimate, we're five to six years away from such a thing being viable. In the interim, I choose to work with 2.50, adding things that people want, fixing what can be fixed, and trying to smooth out some ruffles. I have yet to see any kind of plan for a rewrite, or ZC3, that I feel is viable; nor have I seen the kind of staffing or dedication it would take to accomplish it. We realistically would need ten or more core developers, and a suite of contributors, or it'll take 12 years, like Solarus, or pretty much 2.5.

We do however, have people willing to work on 2.55, and 2.60. It's possible to keep this thing alive using these resources, while we develop a plan for the future. If you actually need a list of references on why not routinely updating something kills it, I can provide that: History is a good teacher here. Without working on 2.55 and 2.6 as continuations of 2.50--even if that means biting it, and continuing to work on a dinosaur API with a zany assembler that has its own C-type interpreter,--ZC is pretty much a dead duck, as the present userbase will die out, and no new userbase will exist to supplant it.

You also have to take the contributors, and new developers that you can gain, and avoid thwarting ever ambition that they may have, isolating them, and turning them away in the process. I know that @Tamamo pretty much abandoned ZC Dev because everything she wanted to do was rejected; and while I was not in favour of some of it, the same thing is happening with the three of us that are willing to work on this beastie.

Quote:

---

Originally Posted by Saffith

To be clear here, the goal is to drop support for compiling ZScript; existing quests would continue to work. If backward compatibility weren't a priority, this would all be much easier.

There really isn't a good way to support both languages at once without undermining each of them. Enemies, weapons, and especially Link are all a complete mess, but we can't make any major changes to them without potentially breaking quests that depend on their weird behavior. Replacing them with scripted versions would fix that; their behavior would be part of the quests and unaffected by future updates. Continuing to support ZScript, whether or not the objects themselves were written in ZScript, would mean either keeping a lot of the weirdness we want to get away from or completely overhauling the language (which would be about as big a change as switching).

---

So when updating a quest from 2.5 to whatever version adds AngelScript, would there be a way to remove certain ZScript scripts that are broken? Or are they so incompatible that all scripts would be removed from the file? I'm fine with ZScript support being dropped, but I'm wondering how hard it will be (if it's even possible) to update a 2.5 quest over to the next version.

Quote:

---

An important factor, is that ZC is no longer the only game in town. I'm unsure if @DarkDragon has looked at the Solarus engine. IMO, that is the right direction for ZC3. Every object in Solarus is scripted... If you went that route, and you had easy to use attribute editors so that scripting is not a mandatory requirement to use the flipping thing (note that Solarus does not yet do that, but it's on @Christopho ' s plan), you would have something that can hold up to the test of time.

---

I'm not aware of Solarus, though I played Megazeux back in the day, which also was a fully-scripted engine on top of which all of the game elements were built. It's a very tempting model, especially to us computer scientists who will abstract anything given the slightest temptation.

However! I will warn you that I traveled quite a distance down this path 5-6 years ago when we were first pondering the idea of a full remake, and an "everything-scripted" Zelda remake would require a **lot** of thought and pre-planning to have any hope of success. Just think of what a Link script would have to look like, so that he correctly transitions between all of his possible states in LoZ -- walking, attacking, hurt, dying, rafting, on a ladder, warping, etc etc etc) -- and responds correctly to user input and world interaction in all states. I don't know how Solarus is built to manage the complexity, but I'd imagine a sophisticated message-passage system (perhaps along the lines of, but far more elaborate than, MZX's system) of some sort would be needed.

Quote:

---

Originally Posted by DarkDragon

I'm not aware of Solarus, though I played Megazeux back in the day, which also was a fully-scripted engine on top of which all of the game elements were built. It's a very tempting model, especially to us computer scientists who will abstract anything given the slightest temptation.

However! I will warn you that I traveled quite a distance down this path 5-6 years ago when we were first pondering the idea of a full remake, and an "everything-scripted" Zelda remake would require a **lot** of thought and pre-planning to have any hope of success. Just think of what a Link script would have to look like, so that he correctly transitions between all of his possible states in LoZ -- walking, attacking, hurt, dying, rafting, on a ladder, warping, etc etc etc) -- and responds correctly to user input and world interaction in all states. I don't know how Solarus is built to manage the complexity, but I'd imagine a sophisticated message-passage system (perhaps along the lines of, but far more elaborate than, MZX's system) of some sort would be needed.

---

You should certainly have a look: http://www.solarus-games.org -- The default quest is rather impressive, and the quests made to date are shaping up nicely. it uses Lua, and TBH, my main complaint is that you need to manually configure absolutely everything with Lua scripts, at present. The map design tools are outstanding though, and it runs in the Z3 style.

It's also open source, and @Christopho has no qualms discussing it in depth, should you want to inquire.

Quote:

---

Originally Posted by Moosh

So when updating a quest from 2.5 to whatever version adds AngelScript, would there be a way to remove certain ZScript scripts that are broken? Or are they so incompatible that all scripts would be removed from the file? I'm fine with ZScript support being dropped, but I'm wondering how hard it will be (if it's even possible) to update a 2.5 quest over to the next version.

---

Unfortunately, only time will tell. AFAIK, the present plan doesn't call for ZScript deprecation for a jolly long time. I'm mostly uncertain if it's even plausible to do such a major rewrite, and not break the universe in the process. We have so many compatibility rules as things stand, that implementing all of them in a rewrite is simply...madness.

The hope is that when ZC3 is a thing, and a new language is implemented, quests with ZASM tables will still work, most of the time.

It won't be the 'next version' though. Somewhere down the line, certainly, but not next. That, and I may be mad enough to continue supporting 2.xx stuff after it is officially deprecated. We'll see in a few years how much steam I've left.

Quote:

---

Originally Posted by DarkDragon

Similarly hard-coded enemies can be replaced with scripted enemies, same thing with items, etc.

---

I'm just not sure that's feasible for everything. For sprite types, for instance, if we want to replace the fixed-point coordinates with floating-point, the current script engine won't work with that at all.
I don't know. It probably doesn't make sense to worry about it too much at this point, anyway.

Quote:

---

Originally Posted by ZoriaRPG

There's no reason that 2.x has to die for this to work, and there's no reason to abandon the community using 2.x to allow a rewrite.

---

I don't disagree with any of that. I would like there to be a 2.60 (or 2.55, or whatever), and I'd like to start the branch as soon as 2.50.3 is complete. I'm already leaning toward abandoning the current rewriting effort and doing it more gradually, starting there. But the current codebase is so messy and so fragile that we're greatly limited in what we can actually do in the way of incremental upgrades without breaking a lot of existing quests, and what I absolutely do not want to do is make it worse by adding unmaintainable features and exposing more internal behavior.

Quote:

---

and insofar as deprecating ZScript, the community opinion has been unfavourable to this outcome.

---

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

Quote:

---

We do however, have people willing to work on 2.55, and 2.60.

---

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

Quote:

---

Originally Posted by Moosh

So when updating a quest from 2.5 to whatever version adds AngelScript, would there be a way to remove certain ZScript scripts that are broken? Or are they so incompatible that all scripts would be removed from the file? I'm fine with ZScript support being dropped, but I'm wondering how hard it will be (if it's even possible) to update a 2.5 quest over to the next version.

---

We just can't say at this point. I think updating a quest would mean removing all ZScripts and updating enemies, items, etc. to the new versions, but maybe not.

Quote:

---

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

---

In particular, are there developers that are willing to focus on fixing bugs, and refactoring code, rather than cram in more new features?

Debugging and maintenance is extremely unglamorous work, but is what ZC needs right now (and has needed since 2.12, to be honest).

Quote:

---

Originally Posted by Saffith

I'm just not sure that's feasible for everything. For sprite types, for instance, if we want to replace the fixed-point coordinates with floating-point, the current script engine won't work with that at all.
I don't know. It probably doesn't make sense to worry about it too much at this point, anyway.

---

I certainly wouldn't. I'm not even sure what benefot thee would be to that conversion, to be frank. Changing from the present fixed format would sure break everything though, which is why I haven't been in favour of suggestions to do anything of the sort. I had an idea for allowing fixeds in the script lanuage, but I pretty much abandoned that after i determined just how obscene it would be to implement, versus its usefulness.

I did have ideas for how to convert the hardcoded enemies, to scripted enemies, with reasonable transparency, but no-one seemed keen to hear them out in full.

Quote:

---

I don't disagree with any of that. I would like there to be a 2.60 (or 2.55, or whatever), and I'd like to start the branch as soon as 2.50.3 is complete. I'm already leaning toward abandoning the current rewriting effort and doing it more gradually, starting there. But the current codebase is so messy and so fragile that we're greatly limited in what we can actually do in the way of incremental upgrades without breaking a lot of existing quests, and what I absolutely do not want to do is make it worse by adding unmaintainable features and exposing more internal behavior.

---

Which of my routines haven't included at least some layer of abstraction, in your eyes? The return functions? That's the sort of thin that can be updated at a function level, at any time, and they work in precisely the same manner as every other return function.

Quote:

---

Who? Where? You keep saying that, but I haven't seen any evidence of it. There've been some questions and some uncertainty, but I haven't seen any real opposition to it from anyone except you.

---

Well, of course not. It hasn't been discussed on a public forum, where we have most of the userbase... :p

It comes up in chat, every single time this topic is broached.

Quote:

---

That's great, but we need more than willingness. Several people were willing to work on 2.50, and now it's an unmaintainable mess of spaghetti code.

---

That's valid, certainly. I fret that any attempt to clean it up is likely to (initially) do more harm, than good, as well...but there are really three options, as I see things:

1. People work together on the individual, incremental updates; you take what you can get.
2. You end up with a core version, several forks, and community splintering that the present minimal userbase cannot maintain.
3. You have a stalled project, that goes nowhere for years.

We seem mostly to be in mode 3, from that list.

Quote:

---

Originally Posted by ZoriaRPG

I did have ideas for how to convert the hardcoded enemies, to scripted enemies, with reasonable transparency, but no-one seemed keen to hear them out in full.

---

First I've heard of it. I was doing that, and it seemed to be working fine, but then we stopped doing that. Maybe for a reason, but I don't even know anymore.

Quote:

---

Which of my routines haven't included at least some layer of abstraction, in your eyes? The return functions? That's the sort of thin that can be updated at a function level, at any time, and they work in precisely the same manner as every other return function.

---

I don't know what any part of that means.

Quote:

---

Well, of course not. It hasn't been discussed on a public forum, where we have most of the userbase... :p

---

Well, tell them to come to the forums. I'm not accepting secondhand complaints. I really don't like you being the representative of some horde of anonymous users.

Quote:

---

Originally Posted by DarkDragon

In particular, are there developers that are willing to focus on fixing bugs, and refactoring code, rather than cram in more new features?

Debugging and maintenance is extremely unglamorous work, but is what ZC needs right now (and has needed since 2.12, to be honest).

---

I just wanted to point out that this is exactly what has happened since you left. The simple fact that you don't see any users saying things like "Works only with XXX version of ZC" anymore I think proves this. :) In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. :)

The worst bugs currently (I believe) are from Windows 10 DirectX layer, Windows 10 drivers, and/or general Windows shenanigans. For example; someone said that ZC mega-lags unless they are playing a youtube video in the background. Stuff like this.

Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.

Quote:

---

Originally Posted by Gleeok

I just wanted to point out that this is exactly what has happened since you left. The simple fact that you don't see any users saying things like "Works only with XXX version of ZC" anymore I think proves this. :) In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. :)

The worst bugs currently (I believe) are from Windows 10 DirectX layer, Windows 10 drivers, and/or general Windows shenanigans. For example; someone said that ZC mega-lags unless they are playing a youtube video in the background. Stuff like this.

---

(Emphasis, mine.)

Bah? I have win10 installed, and I've tested ZC and ZQuest, encountering no such issues. It must be either a video driver conflict, or some kind of malware in that case?!.

Neither ZC, nor ZQuest seem to run differently on Win10, than they did on Win7, on this hardware.

Quote:

---

Originally Posted by Saffith

First I've heard of it. I was doing that, and it seemed to be working fine, but then we stopped doing that. Maybe for a reason, but I don't even know anymore.


I don't know what any part of that means.

---

I think you had implied in the past that something I had done didn't have proper abstraction? I just want to make certain that setter/getter functions that return something like bool throttleFPS aren't a problem.

Quote:

---

Well, tell them to come to the forums. I'm not accepting secondhand complaints. I really don't like you being the representative of some horde of anonymous users.

---

Oh, I have. I can't even get people to sign in here, that have accounts to make flipping bug reports. They send them to me, over Skype, and ask me to file them. :(

This is precisely why I've been pushing for bug and dev forums on Pure, as pretty much everyone who could be discussing these things, getting involved, and reporting issues is over there. ---->

I don't actually enjoy relaying everyone else's concerns, you know; nor being left to defend their interests solely. They should just stop being lazy, and sign up, or sign in here, but you know, that isn't going to happen. I'm sort of tired of being the gopher for every complaint, problem, and general issue, too. For my own purposes, I an always crank out a version of ZC that does what I need it to do, and not worry about it.

Frankly, assuring people that everything they made isn't going to abruptly break in the very next ZC version shouldn't be my full-time job.

Quote:

---

Originally Posted by DarkDragon

Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.

---

2.50 stability is assuredly, highly praised, and regarded. I remember the fun of 2.10 crashing randomly, if I wanted to view the space-bar-map, or 2.5 betas eating save files. things like that are why I abandoned ZC for a few years, particularly when it seemed as if future dev (then) was going no-where.

Incidentally, this is why I fear things being stagnant, now; as I know people tend to leave when they feel as if nothing new is forthcoming. I certainly did, in 2006/7.