PDA

View Full Version : ZC [2.future] Development Plans [To-Do]



ZoriaRPG
02-16-2016, 05:24 PM
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

ZoriaRPG
02-24-2016, 02:19 AM
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

ZoriaRPG
02-24-2016, 11:24 AM
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.

ZoriaRPG
02-27-2016, 09:05 AM
Quest Files

Quests:Quest Details

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

ZoriaRPG
03-02-2016, 09:21 AM
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.

ZoriaRPG
03-04-2016, 02:21 AM
04-March: Added External:Tools and Utilities category, above..

ZoriaRPG
03-16-2016, 05:36 PM
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.

ZoriaRPG
03-21-2016, 04:27 AM
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.

Saffith
06-22-2016, 05:18 PM
I suppose I need to go over all this at some point...


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.

ZoriaRPG
06-24-2016, 04:49 AM
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?



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.

Saffith
07-07-2016, 05:57 PM
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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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?

Tamamo
07-07-2016, 06:28 PM
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.

ZoriaRPG
07-12-2016, 06:53 PM
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.

Tamamo
07-12-2016, 08:06 PM
Leave quest rules out of ZASM... That is one thing you do not want to tinker with ZoriaRPG

ZoriaRPG
07-12-2016, 08:44 PM
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.

DarkDragon
11-28-2016, 12:58 PM
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:

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.

Saffith
11-28-2016, 01:59 PM
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.

ZoriaRPG
11-28-2016, 04:59 PM
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_27JAN2016_RPG_zh-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.

Saffith
11-28-2016, 05:48 PM
I know nothing about any of this, incidentally.

Dimentio
11-28-2016, 09:01 PM
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

Mitsukara
11-28-2016, 10:24 PM
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 : )

Saffith
11-28-2016, 11:05 PM
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).

DarkDragon
11-29-2016, 04:27 AM
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.


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.


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.


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.

DarkDragon
11-29-2016, 05:40 AM
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.

Gleeok
11-29-2016, 06:15 AM
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.

Mitsukara
11-29-2016, 10:12 AM
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.


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?

Saffith
11-29-2016, 11:48 AM
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.

DarkDragon
11-29-2016, 10:00 PM
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.

ZoriaRPG
11-29-2016, 11:53 PM
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.

Moosh
11-30-2016, 01:36 AM
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.

DarkDragon
11-30-2016, 02:05 AM
An important factor, is that ZC is no longer the only game in town. I'm unsure if @DarkDragon (http://armageddongames.net/member.php?u=1) 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 (http://armageddongames.net/member.php?u=61144) ' 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.

ZoriaRPG
11-30-2016, 02:45 AM
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.

ZoriaRPG
11-30-2016, 05:56 AM
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.

Saffith
11-30-2016, 02:35 PM
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.


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.


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.


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.


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.

DarkDragon
11-30-2016, 02:57 PM
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).

ZoriaRPG
11-30-2016, 07:10 PM
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.




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.



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.



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.

Saffith
11-30-2016, 08:21 PM
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.


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.


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.

Gleeok
12-01-2016, 03:43 AM
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.

DarkDragon
12-01-2016, 04:38 AM
Excellent!! Historically this wasn't always the case, and I'm sure the quest authors greatly appreciate it.

ZoriaRPG
12-01-2016, 06:02 AM
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.


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.



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.


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.

Gleeok
12-01-2016, 06:32 AM
[Thread Hijacking In Progress]


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.

Ooh boy, oh boy. A discussion about getters/setters and abstraction layers! Quick, post the offending code. We've got to figure this out immediately! :P


This edisode of 'Is it sarcasm' has been brought to you by Gleeok. Click here to see the answer:
-=SPOILER=-

[/Thread Hijacking In Progress]

Mitsukara
12-01-2016, 08:51 AM
(I apologize that this following post got rambly.)


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.
In support of Zoria, I myself was saying "Wait, if quests that use ZScript stop working in new versions, you're going to lose a ton of your userbase" and "Oh, well, at least people can develop in 2.5.2 instead of the new version, solely for the benefit of continuing to use ZScript". At the same time, I like the potential of what you're describing for new versions, so I think that's a decent sounding compromise, but it is a compromise, because ZScript is the lifeblood of many of the most popular ZC Quests these days.

And you very likely will get some people who don't learn angelscript even though they were avid zscripters, even with that, so I think it's also worthwhile to keep that alive, and to allow people to still play older beloved quests (In The Lost Kingdom of the Banana Blood God, Isle of Rebirth, and so on) in newer versions.

So to reiterate: I'm on board with trying a 'keep supporting quests made with zscript, but don't allow newer versions to compile it because there's this other similar thing you can use instead that's better' approach. It's just that it's a tricky balance to strike.


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.
I definitely see how you'd want a small, devoted team- otherwise things do get confusing and messy. I think that can be a pretty good idea here. But regarding your example... I can definitely believe it's a mess to work on behind the scenes, but 2.50 came out much more stable than 2.10 from all my experiences as a user, and...


In fact, I've been sorta semi-retired from general bug-fixing for some time due to the fact that it has remained stable. :)
Yes, this exact thing. 2.50/2.50.1/2.50.2 are the most stable versions of ZC I remember since 1.00 back in 2000.

What I'm trying to say here is that you've already done a fantastic job debugging ZC from what it used to be. There's things I could imagine being improved, but a lot of those are weirdness rooted deeper in the engine- the odd color limitation system and bad translucent colors, the Zelda 1 scrolling/screen size limits, the Zelda 1 subscreen, and so on. Or stuff that can be worked around easily, like how NPCT_WALKER enemies behave poorly in sideview. 2.50 (and the subsequent, even more stable versions) are so great they brought me back to quest development after many years of disinterest, so don't disregard the quality of your own teamwork/accomplishments, here. : )


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.
*raises hand* Dimentio, I, and Moosh all came when Zoria told us we should weigh in. But that's only a small portion of that chat, and leaves out people like Evan who made Isle of Rebirth, Grayswandir, ywkls, and several other major scripters. To say nothing of the sheer scope of the PureZC forums proper...

I don't post very much in either forum. By posting as many times as I have in this thread this week, I think I'm actually exceeding the numer of posts I've made on PureZC in the past month, outside of my own private bugtesting thread for my own quest project. I have nothing against either community in their present forms (though I will say AGN was poorly managed when I was a teenager and a younger adult, many years ago; but I didn't go to PureZC very much then, either, and I spent most of 2007-2015 not posting on either forum at all).

I don't see the communities as bickering or rivaling at all anymore... I see AGN as being a quiet place with a few oldbies who like to hang out, and the staff talking about dev topics amongst themselves.

But PureZC, while slightly slow at times, is a much more active ZC community than AGN. Look at their front page updates (http://www.purezc.net/) for stuff that's been added to the database and updates on quest projects; contrast ZeldaClassic.com's cobweb-filled database. Look at youtube let's plays (MeleeWizard, TeamUDF, Pixcalibur123, SCKnuckles, and the list goes on)... which community is more likely to get mentioned, and where more LPers are announcing their videos/streams (http://www.purezc.net/forums/index.php?showforum=258). Look at the fact that mere unfinished projects can get a lot of comments and followers. Just a couple of months ago they had a successful expo (http://www.purezc.net/forums/index.php?showforum=301), and I heard the previous year had a bigger one.

This stuff just doesn't happen at AGN; comparatively there's very little for ZC users to do here besides trying to talk to the staff. There's some posts, but look how many of them are either the same very few people, or extremely old threads... the Quest Developers Excahnge subforum, with the mission statement "Trade tiles, midis, maps, palettes, anything related to quest building in ZC"- it hasn't had a post in over a year, almost a year and a half. PureZC's database has had tile submissions and stuff like that in the past few days, and they keep coming.

It's not about 'the communities fighting'; from what I can see those fights are old, dusty, and, I suspect, mostly over. The aftermath is that AGN retains the actual staff and ownership, but PureZC retains the actual majority of the userbase, and that's just how it works these days. If you want to get the userbase's opinion, you have to seek them out where they actually go, not discard the majority userbase as "secondhand" for going to the more active community instead of the ghost town. That's just... marketing.

You also have to realize that a lot of users might not even realize AGN is where the devs go; you have to realize that people aren't sure who the developers are (...heck, when I posted here asking about a list of everybody known to have been part of ZC's staff, I barely got any replies, with very little info on the subject). And even then, between inactivity, social awkwardness, and not thinking of it, a lot of users are extremely unlikely to look you up over here.

I'm glad that you're all here again and that you're trying to rekindle things, and I'm glad War Lord is updating ZeldaClassic.com- without you guys 2.50 wouldn't have even happened, and without War Lord 1.00 might not've saw the light of day. We also owe a lot to Phantom Menace and DarkNation (may he rest in peace). However, for making these big strategic decisions about the future, I really think you should also post some kind of thread at PureZC about it (that is, discuss it at both forums), or get more of their own staff involved and let them set up a forum for that, or something- I'm certain you would get more feedback from actual users that way, instead of just staff members and less than a handful of people that Zoria personally succeeded at dragging over here. : (

To try to wrap up my ramblings on a more positive note, though, I am very excited for the possibility of new developments in ZC. I always like having more options; I got into ZC again because I could finally make a quest with a ton of items, thanks to the 2.50 updates. : )

Saffith
12-01-2016, 11:28 AM
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.
That was regarding quest rules specifically. A lot of the other stuff is just exposing internal state for no reason.
https://github.com/ArmageddonGames/ZeldaClassic/pull/29/commits/eff465097589d28aba7df8e8dbf100e0a95b2d49

+ case GAMEPAUSED:
+ ret=Paused?10000:0;
+ break;
+
+ case GAMESHOWFPS:
+ ret=ShowFPS?10000:0;
+ break;
+
+ case GAMESHOWPAL:
+ ret=Showpal?10000:0;
+ break;
+
+ //case GAMENOCLICKFREEZE:
+ // ret=disableClickToFreeze?10000:0;
+ // break;
+
+ case GAMECLICKFREEZE2:
+ ret=ClickToFreeze?10000:0;
+ break;
+
+ case GAMEPLAYING:
+ ret=Playing?10000:0;
+ break;
+
+ case GAMEDEBUG:
+ ret=__debug?10000:0;
+ break;
+
+ case GAMEDEBUGON:
+ ret=debug_enabled?10000:0;
+ break;
+
+ case GAMEDEBUGON:
+ ret=debug_enabled?10000:0;
+ break;
+
+ case PRESSF12:
+ ret=debug_enabled?10000:0;
+ break;
+
+ case PRESSF11:
+ ret=F11?10000:0;
+ break;
+
+ case PRESSF5:
+ ret=F5?10000:0;
+ break;
+
+ case PRESSFI:
+ ret=keyI?10000:0;
+ break;
+
+ case PRESSFQ:
+ ret=keyQ?10000:0;
+ break;
I defy you to explain how any of that is useful. Or why access to a variable created just for scripts was removed in favor of the one it overrides.



In support of Zoria, I myself was saying "Wait, if quests that use ZScript stop working in new versions, you're going to lose a ton of your userbase" and "Oh, well, at least people can develop in 2.5.2 instead of the new version, solely for the benefit of continuing to use ZScript".
See, that's the thing. I feel like a lot of opposition to stuff in general is from people who don't fully understand things, and we can't sort it out without talking directly.

Honestly, the whole reason I said anything publicly about AngelScript in the first place was that I anticipated the concerns and wanted to deal with them as soon as possible. But the reaction seemed largely positive, and I thought the misunderstandings were cleared up pretty easily, so now I wonder if everyone forgot or if it was never really settled in the first place.

ZoriaRPG
12-01-2016, 11:32 AM
[Thread Hijacking In Progress]



Ooh boy, oh boy. A discussion about getters/setters and abstraction layers! Quick, post the offending code. We've got to figure this out immediately! :P


This edisode of 'Is it sarcasm' has been brought to you by Gleeok. Click here to see the answer:
-=SPOILER=-

[/Thread Hijacking In Progress]


I did them the same way that the other interface getters work:

-=SPOILER=-

I had to cut out some to get that to fit, such as GetPressF4.

Most of those that I cut are probably useless, but I just shoved all the interface vars in there when I did a few of them, so that I would never have to do them again. If for some reason anyone wants to add an intermediate register, that's fine, but in these cases, I think it's pretty pointless.

I may have lost the file with Set/GetDMapScreenDoor, Set/GetScreenDoor, Set/getScreenState, Set/etDMapScreenState, and a lot of other general purpose getters and setters for that sort of thing, that otherwise work exactly as GetScreenD, SetScreenD, GetDMapScreenD, SetDMapScreenD, and so forth; that would take all of an hour to write up again. I should have it archived, but I don't know where... It was on the drive that fried, and it'd be faster to rewrite it, than to find it on the servers.

ywkls
12-01-2016, 12:44 PM
(I apologize that this following post got rambly.)

*raises hand* Dimentio, I, and Moosh all came when Zoria told us we should weigh in. But that's only a small portion of that chat, and leaves out people like Evan who made Isle of Rebirth, Grayswandir, ywkls, and several other major scripters. To say nothing of the sheer scope of the PureZC forums proper...



Thanks for the vote of confidence on my scripting skills, Mitsukara. As for why I don't post here, I think you explained it rather succinctly with the following quote.




But PureZC, while slightly slow at times, is a much more active ZC community than AGN. Look at their front page updates (http://www.purezc.net/) for stuff that's been added to the database and updates on quest projects; contrast ZeldaClassic.com's cobweb-filled database. Look at youtube let's plays (MeleeWizard, TeamUDF, Pixcalibur123, SCKnuckles, and the list goes on)... which community is more likely to get mentioned, and where more LPers are announcing their videos/streams (http://www.purezc.net/forums/index.php?showforum=258). Look at the fact that mere unfinished projects can get a lot of comments and followers. Just a couple of months ago they had a successful expo (http://www.purezc.net/forums/index.php?showforum=301), and I heard the previous year had a bigger one.

This stuff just doesn't happen at AGN; comparatively there's very little for ZC users to do here besides trying to talk to the staff. There's some posts, but look how many of them are either the same very few people, or extremely old threads... the Quest Developers Excahnge subforum, with the mission statement "Trade tiles, midis, maps, palettes, anything related to quest building in ZC"- it hasn't had a post in over a year, almost a year and a half. PureZC's database has had tile submissions and stuff like that in the past few days, and they keep coming.

It's not about 'the communities fighting'; from what I can see those fights are old, dusty, and, I suspect, mostly over. The aftermath is that AGN retains the actual staff and ownership, but PureZC retains the actual majority of the userbase, and that's just how it works these days. If you want to get the userbase's opinion, you have to seek them out where they actually go, not discard the majority userbase as "secondhand" for going to the more active community instead of the ghost town. That's just... marketing.



I don't post for most of these reasons. There's very little activity here. I do post bugs, occasionally; when I find them. But, otherwise; I rely on PureZC.

So, let me see if I can summarize my opinion on the future development of ZC...


A slow transition between the current scripting language and anything else (such as ZScript) seems to be the best solution to that particular quandary.

Having looked over Solarus (which ZoriaRPG) mentioned, I can honestly say that even to someone who has a relatively robust knowledge of how scripting works; setting things up where everything must be scripted before it can be use would daunt most people and keep them from even trying. So some sort of middle ground (which is what we have now, mostly) would be advised.

Regarding the objectives outlines towards the beginning of this thread...
I'll make a separate post for that.

ywkls
12-01-2016, 12:54 PM
-=SPOILER=-

From this post, these are the things I most understand and have seen the need for their creation. (Or have been forced to create odd scripted workaround to do.)
If anyone needs an explanation why on something, I can provide one.

ywkls
12-01-2016, 01:13 PM
-=SPOILER=-

I can't think of any reason why most scripters wouldn't want most of the things on this list. As for whether we'll actually get them... that's an entirely different kettle of fish.

ZoriaRPG admits to that and I think that this topic has gotten away from "how can we improve ZC realistically in a time frame that isn't so long where a lot of people lose interest."

My own specific most wanted would be the improvements for Scripted weapons types both in enemy and Link defense, easy adjustment to Link's appearance via script, read and writing flags like Dmap, Screen and other things which aren't currently accessible and improvements to gd registers and script buffer size.

I've lost track of the weird workarounds I've had to do in order to accomplish many of the things on this list (and the other one) and having the ability to control them via script would have definitely made it easier.

Saffith
12-01-2016, 03:24 PM
Having looked over Solarus (which ZoriaRPG) mentioned, I can honestly say that even to someone who has a relatively robust knowledge of how scripting works; setting things up where everything must be scripted before it can be use would daunt most people and keep them from even trying. So some sort of middle ground (which is what we have now, mostly) would be advised.
Nothing like that. Everything may be converted to scripts, but they'll all be loaded up by default and placed much like they are now. Anyone who doesn't want to mess with script stuff won't have to. That's not going to change.


ZoriaRPG admits to that and I think that this topic has gotten away from "how can we improve ZC realistically in a time frame that isn't so long where a lot of people lose interest."
Realistically is the problematic bit. We can come up with all sorts of ideas, but making even small changes is often difficult, and doing so without breaking existing quests or making future support harder isn't always possible.

ZoriaRPG
12-01-2016, 04:13 PM
Thanks for the vote of confidence on my scripting skills, Mitsukara. As for why I don't post here, I think you explained it rather succinctly with the following quote.
A slow transition between the current scripting language and anything else (such as ZScript) seems to be the best solution to that particular quandary.

Having looked over Solarus (which ZoriaRPG) mentioned, I can honestly say that even to someone who has a relatively robust knowledge of how scripting works; setting things up where everything must be scripted before it can be use would daunt most people and keep them from even trying. So some sort of middle ground (which is what we have now, mostly) would be advised.

Regarding the objectives outlines towards the beginning of this thread...
I'll make a separate post for that.

Pretty much, even Solarus will eventually have some way of interfacing with the object scripts via GUI. Christopho has stated that's part of his goal with the editors.

The basic idea, is that instead of an npc, or an item, hardcoded in the engine, it has a 'built-in' script, that controls it. The user may modify that, or use it as-is; and instead of the editor changing values that affect how its internal coding works, an editor pane will set script attributes.

As I mentioned, I had an idea on how to do this (using ZScript), for npc scripts; disabling the hard-coded behaviour, and using something similar to how an ffc script works, save that they are only loaded when an npc is in use, per npc. The idea what that the 'NPC Type' selector in the enemy editor would have up to N script slots, and selecting one of those would disable any internal behaviour, and run that script to control the npc. I can't say how practical that would have been, or if anyone else would even have approved it, but it could be workable.

Effectively, it would be similar to how item scripts are selected from the item editor, and run when the item is used, save that it would persist until the npc is removed, and its pointer invalidated.

Gleeok
12-01-2016, 09:49 PM
I did them the same way that the other interface getters work:

-=SPOILER=-

I had to cut out some to get that to fit, such as GetPressF4.

Most of those that I cut are probably useless, but I just shoved all the interface vars in there when I did a few of them, so that I would never have to do them again. If for some reason anyone wants to add an intermediate register, that's fine, but in these cases, I think it's pretty pointless.

I may have lost the file with Set/GetDMapScreenDoor, Set/GetScreenDoor, Set/getScreenState, Set/etDMapScreenState, and a lot of other general purpose getters and setters for that sort of thing, that otherwise work exactly as GetScreenD, SetScreenD, GetDMapScreenD, SetDMapScreenD, and so forth; that would take all of an hour to write up again. I should have it archived, but I don't know where... It was on the drive that fried, and it'd be faster to rewrite it, than to find it on the servers.


Ah yes, The programmers version of TMI. ;) Many an API has been over-engineered since the dawn of interface design, and it's always hard to get right (I still mess it up). I agree with Saffith here. That is just much /too much.

Especially this one:


case GAMEPAUSED: // INVALID CODE PATH
ret=Paused?10000:0; // This will never actually run because the scripts are paused...
break;


I mentioned this before but a simple int Game->EngineProperty[] and int Game->QuestRule[] would take care of all of these things. I hadn't put them in because 2.5 was supposed version compatible (Although soon it probably won't matter anyway).

ZoriaRPG
12-01-2016, 10:16 PM
Ah yes, The programmers version of TMI. ;) Many an API has been over-engineered since the dawn of interface design, and it's always hard to get right (I still mess it up). I agree with Saffith here. That is just much /too much.

Especially this one:


case GAMEPAUSED: // INVALID CODE PATH
ret=Paused?10000:0; // This will never actually run because the scripts are paused...
break;


I mentioned this before but a simple int Game->EngineProperty[] and int Game->QuestRule[] would take care of all of these things. I hadn't put them in because 2.5 was supposed version compatible (Although soon it probably won't matter anyway).


As I said, I just dumped the entire list of vars into a file, and built a getter on them, as it was a painless thing to do. There are probably four that should be in there.

I suggested turning the QRs into a r/w array, but that was rejected by Saffith. Even if it could only cover some of them, the rules that can be modified on the fly, it would be useful IMO. Also, moving things like 'Big Link Sprite' into a Link class property, pretty much as TileHeight/TileWidth, were on my list, but that's another matter.



{ "getHeartbeep", ScriptParser::TYPE_BOOL, GETTER, GAMEHEARTBEEP, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },
{ "getCapFPS", ScriptParser::TYPE_BOOL, GETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },
{ "setCapFPS", ScriptParser::TYPE_VOID, SETTER, GAMETHROTTLE, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },

{ "setHasPlayed", ScriptParser::TYPE_VOID, SETTER, GAMEHASPLAYED, 1, { ScriptParser::TYPE_GAME, ScriptParser::TYPE_BOOL, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 } },



Those were what I planned to retain, above all else. I left out SetHeartBeep, which while it may seem an oversight, is because I wanted to do Link->HeartbeepSfx and Link->HeartBeepContinuous as separate commands, given that you can't set the sound by script at all at present. I also wanted to do Link->HurtSound and Link->HurtEffect (none, flicker, flash).

one of that was stuff that I wanted to d for the very next release. I would frankly do more frequent, smaller updates that are easier to debug, than roll everything into one massive update and play 'now let's see what breaks'. That is exactly why I wanted to do an incremental 2.53, 2.5, and 2.55, each with a small subset of new features, and more bugfixes.

The new drawing stuff, some additional setters, getters, and a few new commands were all of what I wanted to do for '2.53'. Something that isn't likely to cause problems, that gives users something new to try.

Tamamo
12-08-2016, 08:56 AM
That's not true at all ZoriaRPG
I abandoned it because making sure you dicks get along and keep getting along is more important at this time. And that is quite tiring. I haven't gotten an complaint from anyone in while dev or nondev alike (i get both, and I keep them annonymous) it's clear we can't get along. Especially with the lack of communication going on.
Gleeok simple just doesn't give a damn. Saffith has Autism so that leaves? oh wait... that's all the major devs... Oh well. Looks like a volunteer is gonna have to do it.

Moosh
we're not adding angelscript ever, and I'm adamant about that... It's a terrible languange anyways and I would be much more in favor of rewriting Zelda Classic from scratch to be moddable with pluggins just makes more sense.

ZoriaRPG
12-08-2016, 09:19 AM
That's not true at all ZoriaRPG
I abandoned it because making sure you dicks get along and keep getting along is more important at this time. And that is quite tiring. I haven't gotten an complaint from anyone in while dev or nondev alike (i get both, and I keep them annonymous) it's clear we can't get along. Especially with the lack of communication going on.
Gleeok simple just doesn't give a damn. Saffith has Autism so that leaves? oh wait... that's all the major devs... Oh well. Looks like a volunteer is gonna have to do it.

Moosh
we're not adding angelscript ever, and I'm adamant about that... It's a terrible languange anyways and I would be much more in favor of rewriting Zelda Classic from scratch to be moddable with pluggins just makes more sense.

Frack, I don't actually remember what you are quoting at this point... I know you're tired of the bantering though; as am I, which is why I'll work on this, make some usable builds, and see what happens.

At least we seem to be making some sort of progress, now that we're discussing these things on the forum, instead of behind closed doors, with everyone having different concepts on what's happening. I might try adding keypress detection for the whole keyboard (available to ZScript) next. That way we can forget about adding any new graphical stuff, and we can all make early-80s style TBAs. :p

Oh, did I mention usable builds (http://timelord.insomnia247.nl/zc/zc_dev/ZC_2.54_Beta_7.zip)?

Tamamo
12-08-2016, 09:31 AM
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.

ZoriaRPG
12-08-2016, 12:52 PM
Oh, right. I was being somewhat polite, there: 'everything she wanted to do was rejected'.

i.e., You wanted to do things, and we all went into bicker mode, every time.

DarkDragon
12-09-2016, 05:56 AM
I don't really know what's going on, but if the complaint is that the devs are being too stringent about accepting patches for new features into the repository, I confess I'm very much on the side of the developers.

Patches should absolutely be rejected unless accompanied by a detailed, compelling rationale assessing the impact the patch will have on constraining future development and maintenance. The price for new features is not paid today, but over the next 10-20 years as all future versions of Zelda Classic must be warped to fit around them. Open up any of the source files and you'll quickly find an example of an obscure feature on which we're still paying interest today: all of the different Link movement quest rules; Link tile modifiers; Big Link; the fact that even the emptiest quest has a huge memory footprint due to the reckless allocation of global and screen scripting variables, etc.

ZoriaRPG
01-17-2017, 06:39 AM
17th January, 2017: Updated features, and plans, to indicate recent progress, current to Beta 52r5.

ZoriaRPG
02-19-2017, 08:51 AM
This is primarily a list of ideas that we would like to implement, and it exists so that we can track them, discuss them, and remember them over time...

None of these are promised, or guaranteed.

Additional 2.future and ZC Canonical Planned Features and Improvements

Allow setting shop price text colour, font.
Add Z3 style shop option. This should be a menu selection for the shop, or a flag int he shop editor, not a QR.

Correct Patra movement, and add an enemy editor flag for them. Patras on the NES wrap around the screen edges.
Correct Ganon NES movement pattern, and add an enemy editor flag to enable it.

Add Z3 bosses.

Fix sprite editor. Add in contextual copy/paste menu, and display the sprite number in the lister.

Make screen-based flags global, or by dmap. Sideview gravity, as an example, should be available by screen, dmap, or as a global quest setting.

Add 'Goto DMap' hotkey and menu option.
Add 'Goto Screen' hotkey and menu option.

Add assets locator (find command) that outputs a lister showing locations of any given asset, with buttons to jump to the map and screen with that asset.

Add TileWidth, TileHeight, HitWidth, HitHeight, HitZHeight, HitXOffset, HitYOffset, DrawXOffset, and DrawYOffset to npc, and item editors.

Add special reflect flags to all weapons, to allow any other weapon to reflect them. This would make it easy to make an Aghanim style enemy, or similar effects.

Add animations, and other visual effects, including lightning, fog, mist, flames, wind, water. Allow setting these to item usage, weapon usage, npc actions, and screen or dmap flags. These should also be able to be called by script.

Make all extant animations able to be called by script, and generated by items, npcs, and so forth.

Add flags or rules for counters (signed, unsigned, 16b, 32b, rolls over).

More to follow.


Improved Tile Editor: Edit entire tile pages in pixel view, and pan around, with levels of zoom.
Export tile pages in a raw format, and import them in a raw format. This would improve colour conversion issues.

Add enhanced music flags to npcs and items. When an npc with an enhanced music flag (and filename) is on-screen, that music is loaded. The lowest numbered npc on the list with enhanced music, will play; so multiple npcs with enhanced music will be enqueued. The music will be loaded one time, and when that npc dies, the list is rechecked. If a different filename is found, that one will begin playing. If other npcs have the same music file. the music will continue. If no npcs remain with music files, the normal dmap music will resume.

This could in theory, also be done for items, and for screens. Each screen could have unique special-case music.

Load any colour into a palette index by script. CHange palettes by script. Load ESPs by script. Edit ESPs and LPals by script.

Add global boolean to disable keyboard input from registering as button presses (set by script). Note: Main system buttons (e.g. F6, F10) will be excluded from being disabled.
Add global boolean to prevent keyboard presses from triggering cheat menus. THis should be an array, with an index per key used, each set by script.

These are to streamline keyboard input by script, so that keypresses can be protected, and prevented from doing anything other than generating a character.

Expand itemclass count from 256 to 512. Classes 163 to 255 (z###) should be user classes. It would be nice to allow the user to rename them. Classes 256 to 511 should not be visible to the user, until we add items for them.

Add any new item classes, after this. Because users already use the z### classes, we can;t just use them as originally planned.,

Add Allegro LoadBitmap() and SaveBitmap() to ZScript.

Revise item editor 'rupee cost' flag. Change Magic Cost to ''Counter Cost' and add a JWIN_SELECT_PROC menu to select the counter ref, with magic as the default.

Copy screen layer, and paste as layer zquest hotkeys. Paste as layer pastes a copied screen, or a copied layer to the selected layer.

Grayswandir
02-20-2017, 11:14 PM
Please look over the ZScript Parser things on this list, and let me know which of them are on your to-do list, and which you will likely never do, or want to do:

So, here are my thoughts:

ZScript::Lexer, Parser, Stack


Expand the number of gd registers to a large amount.

Definitely want to do this, but I'll need to learn the ZC save code first, so it's not a priority.


Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.

I'll probably stick this in as soon as I learn how to add gui elements for whatever other reason.


Add some mathematical things, and logical operators.( !<, !>, ^^, NAND, NOR).

Unsure how useful these are. A low priority, and I'd want to check if anybody has objections beforehand.


Read/set any ZC Interface options (e.g. FPS, Uncapped, MenuOpen) by script.

Sure? Not really a parser thing, though. No plans for when at the moment.


Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.

This is done, I think? It's green.


Add some directives.

Wonderfully vague. :P



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

Again, I'd need to learn the save format, so wanted but not really going to happen soon.


Add additional routines for handling of strings. : Some implementation of string literals is done.

Anonymous Strings are already done. I want to add TraceS(array, offset) and similar eventually, but not a priority.


Add 2D and 3D arrays.

Working on some prep work for this currently, kinda.


Add special datatypes, and declarations.

Again, kinda working on this at the moment.


Allow global datatype pointers/declarations. This involves preallocating some for this use, similar to arrays.

Not sure what you mean by preallocating here. Otherwise it's fairly simple to switch on now, as I mentioned the other day.



Increase array operational pointers from 4096 to *.

Again, sounds good, but need to learn how first.


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

Again, sounds good, but need to learn how first.



Add extra preprocessing support.

Meh.


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

Not sure if we want ? specifically - might want to add in ternary operators or something.



Add function pointers.

I'm getting closer to adding these in, but some other stuff is taking priority. They'll go in a soon as I'm done, though.



Add custom defined datastructs.

Pretty soon.


Add a few additional types for variables. : I was originally thinking of adding byte, char, long.

Not sure how these'd be useful? Would long take 2 registers?


Fix error messages to be more useful.

Again, nice, but kinda vague.


Detect some common errors, such as reading an invalid pointer ( e.g. LoadNPC(0) ) during compilation.

Sounds neat, but not really a high priority.


Include support for linked lists and hash tables internally.

Not really a high priority, kinda surprisingly. I'll probably add these in when it becomes convenient, but I won't specifically work towards them.


Add new typedefs that would be useful. : Grayswandir added typedef.

I didn't particularly want this feature, but I needed some way to test that type scoping was working properly. :)


Add new tokens, such as switch, case, and the like. : Added switch-case; still need define and enum.

enum sounds good. I'm still wary of define.


Add new directives, such as #DEFINE

ditto



Add octal NUMBERS

These are in already?


Expand IDENTIFIER to cover more (useful) symbols.

Not sure what else is wanted.



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.

All these are pretty far in the future. They'll depend on how AS turns out.


Add AngelScript style and token, and or token.

Trivial to implement.



Add Until() and Unless() expressions.

Unsure if these are warranted.


Add Repeat(int iterations) loop type.

Low priority.


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.


No idea how to go about doing so. Low priority.

ZoriaRPG
02-21-2017, 02:47 PM
So, here are my thoughts:

ZScript::Lexer, Parser, Stack


Expand the number of gd registers to a large amount.

Definitely want to do this, but I'll need to learn the ZC save code first, so it's not a priority.


Inform me if you need help with that.





Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.

I'll probably stick this in as soon as I learn how to add gui elements for whatever other reason.


I need to know if DarkDragon is still thinking of doing buffers per script, or something like that, first. That, or multiple buffers. If you need JWin help, let me know.




Add some mathematical things, and logical operators.( !<, !>, ^^, NAND, NOR).

Unsure how useful these are. A low priority, and I'd want to check if anybody has objections beforehand.


It would be good to discuss if any of these should not be implemented first, aye. IMO, NAND, NOR, and similar boolean logic should. Logical Xor, possibly. !< and !> might be useful syntactically.




Read/set any ZC Interface options (e.g. FPS, Uncapped, MenuOpen) by script.

Sure? Not really a parser thing, though. No plans for when at the moment.


This one should have been marked 'not allowed for canonical'...?




Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.

This is done, I think? It's green.


'It is....it is..... It is green.'




Add some directives.

Wonderfully vague. :P


I was originally thinking of adding #include and #if, along with #define.




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

Again, I'd need to learn the save format, so wanted but not really going to happen soon.

DarkDragon wanted to give each script its own buffer and store them with the quest. Is that still happening?




Add additional routines for handling of strings. : Some implementation of string literals is done.

Anonymous Strings are already done. I want to add TraceS(array, offset) and similar eventually, but not a priority.


Sure. Real strings, or 2D arrays would have a much higher priority.




Add 2D and 3D arrays.

Working on some prep work for this currently, kinda.


Oh? This ended up on my quasi-abandoned list, as I wasn't certain how to begin to implement them globally; and had other concerns. If you have a way, by all means.




Add special datatypes, and declarations.

Again, kinda working on this at the moment.


Allow global datatype pointers/declarations. This involves preallocating some for this use, similar to arrays.

Not sure what you mean by preallocating here. Otherwise it's fairly simple to switch on now, as I mentioned the other day.


Global pointers /are/ preAllocated with the quest at compile time, but it would be nice to get away from that, if there is any way to do it--hint--there isn't as the preallocation is stored in the quest save file. I was going to give them their own array pointers pool, so that global int/float/bool arrays and special case types had separation, though. Mostly as a safety thing.




Increase array operational pointers from 4096 to *.

Again, sounds good, but need to learn how first.


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

Again, sounds good, but need to learn how first.


When I finish the other stuff, amd we merge it all, I'll work on this with you. This part should not be hard for me at all.




Add extra preprocessing support.

Meh.


What happened to that template that you showed to me last month? It looked viable.




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

Not sure if we want ? specifically - might want to add in ternary operators or something.


If it can be ensured not to get in the way of ternary. This was one of /your/ suggestions a year ago, and I wrote up some IDENTIFIER defs for it. Ternary is a higher priority.




Add function pointers.

I'm getting closer to adding these in, but some other stuff is taking priority. They'll go in a soon as I'm done, though.


Know the feeling.



Add custom defined datastructs.

Pretty soon.


Ace.




Add a few additional types for variables. : I was originally thinking of adding byte, char, long.

Not sure how these'd be useful? Would long take 2 registers?


Long is probably out. I did want to add int18 (igr), which would be auto-truncated, or any int that is auto-truncated. Many of these were just ideas, or a way to handle special values for AS conversion, latter. There is a list of them: http://timelord.insomnia247.nl/zc/ffscript_Update_16.lpp




Fix error messages to be more useful.

Again, nice, but kinda vague.


File that under 'note to self'. I'm going to add more verbose and informative errors, but we may need a directive to enable/suppress them.




Detect some common errors, such as reading an invalid pointer ( e.g. LoadNPC(0) ) during compilation.

Sounds neat, but not really a high priority.


Would belong with an IDE or preprocessor.




Include support for linked lists and hash tables internally.

Not really a high priority, kinda surprisingly. I'll probably add these in when it becomes convenient, but I won't specifically work towards them.


This also, was your suggestion a year ago.




Add new typedefs that would be useful. : Grayswandir added typedef.

I didn't particularly want this feature, but I needed some way to test that type scoping was working properly. :)


No, no, that was awesome. Ace.




Add new tokens, such as switch, case, and the like. : Added switch-case; still need define and enum.

enum sounds good. I'm still wary of define.


Add new directives, such as #DEFINE

ditto


What exactly is your issue with define? With typedef it isn't needed, unless constants are ever revised to be a special datatype, or something; but still...what is it harming? It is literally a few extra lines of AST.




Add octal NUMBERS

These are in already?


They were a year ago, then I pulled them pending some answer on what base we would use. I don't know if I ever did the correct AST for returning them. I see this as 'potentially useful'.




Expand IDENTIFIER to cover more (useful) symbols.

Not sure what else is wanted.


People wanted *, which is dumb. That should be reserved for pointers, but in theory, flex could support some chars that we don't use. I let this one die on the vine.




Add user-defined pointers.

???


For real arrays, and to reference arrays or objects; and for function params.




Add user-defined objects.



Why did you lump this with AS stuff?



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.
[/LIST]
All these are pretty far in the future. They'll depend on how AS turns out.


May as well be prepared for the need.




Add AngelScript style and token, and or token.

Trivial to implement.



Tried? I would add a parser mode to disable this, btw, for the weird case of someone declaring int and.




Add Until() and Unless() expressions.

Unsure if these are warranted.


Add Repeat(int iterations) loop type.

Low priority.


I happen to like Until and Unless, syntactically. I will entertain arguments against any of these three. Repeat() was one of yours, and I like it, too.




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.


No idea how to go about doing so. Low priority.
[/quote]

Actually, this would potentially be viable. Load the new maps, map datum, items,tiles, combos, npcs, and alll scripts, without clearing the system RAM. All of these things are loaded in a modular manner, so it's mostly a matter of giving the parser a directive to execute a special load function in qst.cpp. If you make a bison/ast side function for this, that calls 'ScriptLoadQst("filename"), I could probably tack in a preliminary load routine in a month or so.--the delay, because of the other things on my agenda that must come first.

This would need to occur post-merge, because some load routines have changed, particularly script loading, and it would be critical not to clear the GD regs, and Link's equipment/stats/counters. That seems not too terrible.

DarkDragon
02-21-2017, 05:36 PM
I need to know if @DarkDragon (http://www.armageddongames.net/member.php?u=1) is still thinking of doing buffers per script, or something like that, first. That, or multiple buffers. If you need JWin help, let me know.

I'd like to work out how script contexts work in AngelScript first; it then makes sense to modify ZScript to line up with how the AS runtime works.

Gleeok
02-21-2017, 09:05 PM
I'd like to work out how script contexts work in AngelScript first; it then makes sense to modify ZScript to line up with how the AS runtime works.

I was just sorta copying/emulating how ZScript does it. If you're talking about storing scripts inside of quest files I hadn't planned that until ver.2 since run-time compiling is higher priority.

ZoriaRPG
02-22-2017, 06:00 AM
I was just sorta copying/emulating how ZScript does it. If you're talking about storing scripts inside of quest files I hadn't planned that until ver.2 since run-time compiling is higher priority.


I'd like to work out how script contexts work in AngelScript first; it then makes sense to modify ZScript to line up with how the AS runtime works.



Fair enough mates. For the present, I may write a routine to parse the output of the fuill buffer with all imports in-line to a separate buffer, and save it with the quest, with an option to extract it to a file, and an option to output it to a file at compile time. That should not disrupt anything and can be expanded in the future. It would be a pretty useful utility in any case. I think I will make it the default, and compulsory behaviour. If people absolutely want to hide code, they will need to work to do it. The entire argument of [i]needing'[/i[ to hide it, is asinine, IMO.

I also still plan to add an 'Export ZASM' option at some point, to get scripts as assembly to reuse, should the master files ever be lost. (Note, that I mean raw ZASM as a file, not some kind of disassembly--pretty much the opposite of the 'Import ZASM' options.

ZoriaRPG
03-11-2017, 09:32 AM
I forgot to add this during me last overhaul:

Zelda Classic (Viewer)

Zelda Classic:General

Integrate the agfont library, adding TTF support to ZC.


It seems viable, and falls into the 'would be nice' for 2.55, 'almost certainly' for 2.60, and 'mandatory' for 2.65.

THis has many upsides, including the following:


ZC GUI fonts will be scaled smoothly. No more jagged edges or distortions from scaling the window to any arbitrary size.
Higher legibility on large (high-resolution_ displays.
Easier to allow the user to set an interface font.
Better internal code editor, and listers.
In-quest ZStrings, and ZScript/AScript strings could use any font, and any size, cleanly.
The user can add fonts to a quest.


The proof is in the pudding, though.

Avataro
04-04-2017, 10:36 AM
I just want to say good luck to the devs. I hope ZC will stay great and become even greater. Just having read the OP so far, that's one heck of a list. Most of the stuff would be too good to be true. I have no idea what the state of the future of ZC is in right now though.

Downloader
04-05-2020, 05:21 PM
Has there been any progress on the 2-player input and 2-player support in any recent builds?

ZoriaRPG
04-18-2020, 05:35 PM
Has there been any progress on the 2-player input and 2-player support in any recent builds?


It is now possible to write a scripted system where different keyboard keys can be mapped to two or more player inputs, but as yet there is no P2 controller built-in. It is still part of the plan for canonical ZC.

[2.future] itself is dead, though. We have integrated most of the plan here into 2.55 and beyond.

Please see: To-Do List, on OpenZC.org (https://openzc.org/forum/viewtopic.php?f=64&t=362&p=399#p399)