User Tag List

Page 6 of 7 FirstFirst ... 4 5 6 7 LastLast
Results 51 to 60 of 67

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

  1. #51
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    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:
    Code:
    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.

    Code:
    { "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.

  2. #52
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.

  3. #53
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Tamamo View Post
    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?

  4. #54
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Quote Originally Posted by ZoriaRPG View Post
    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.

  5. #55
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    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.

  6. #56
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    I 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.

  7. #57
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    17th January, 2017: Updated features, and plans, to indicate recent progress, current to Beta 52r5.

  8. #58
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    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.

  9. #59
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    78.95%
    Quote Originally Posted by ZoriaRPG
    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.


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

  10. #60
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Grayswandir View Post
    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.
    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/ff..._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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social