User Tag List

Page 2 of 7 FirstFirst 1 2 3 4 ... LastLast
Results 11 to 20 of 67

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

  1. #11
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    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?

  2. #12
    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%
    @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.

  3. #13
    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,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    Quote Originally Posted by Saffith View Post
    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.

  4. #14
    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%
    Leave quest rules out of ZASM... That is one thing you do not want to tinker with @ZoriaRPG

  5. #15
    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,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    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.

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

  7. #17
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    Quote Originally Posted by DarkDragon View Post
    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.

  8. #18
    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,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    Quote Originally Posted by DarkDragon View Post
    One piece of advice: for each of the suggestions, include a paragraph justifying why there is a need for that feature (and even better, links to forum topics by quest authors demonstrating that need). For example I see many items in the list that could be implemented, and be somewhat useful in some situation, but don't seem worth the time or added code complexity to implement unless there is a demonstrated need by quest authors, like octal support, function pointers, global arrays of object pointers, etc.

    I also cannot endorse Saffith's comment above enough:

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

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

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

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

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

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

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

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

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

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

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

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

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

    ..and see...

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

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

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

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

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

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

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

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

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

  9. #19
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    I know nothing about any of this, incidentally.

  10. #20
    Banned
    Join Date
    May 2015
    Posts
    141
    Mentioned
    34 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    667
    Level
    9
    vBActivity - Bars
    Lv. Percent
    14.48%
    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.

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