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.