User Tag List

Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 30

Thread: I have a dream!

  1. #11
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    I like the rollback plan. Everyone involved only has to make a few minor concessions. Seems reasonable. (This of course is only if the bicker plan falls through, which, if you aren't paying attention, was 'plan A' )

    @ZoriaRPG : You may just change your mind about working on ZScript when you see the angelscript module do the same things, plus more, with only about 10% or less of the work ZScript would take. I'm also planning on plugging in a JIT compiler at some point in the future, which would allow scripts to be compiled to machine code and run closer to c/c++ speed.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  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%
    I can't make up my mind @Gleeok do I want to toss AS or Keep it. Hmm....

  3. #13
    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%
    @Zoria RPG
    Didn't see your post. You might want to be careful with some of the variables that are not yet usable. the clk, clk2,and clk3 variables in the enemy class for example. Don't touch those. Their type sensitive.
    Last edited by Tamamo; 03-27-2016 at 10:27 AM.

  4. #14
    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,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Gleeok View Post
    I like the rollback plan. Everyone involved only has to make a few minor concessions. Seems reasonable. (This of course is only if the bicker plan falls through, which, if you aren't paying attention, was 'plan A' )
    No, just...no. This is entirely different to what you told us. We agreed to the rollback, based on your statements, which were never hypothetical. It's been 18 days since the deadline for any nay-saying, and we have been working under the premise that this was green-lit, as no-one has said anything to denote otherwise, until now.

    Everything that I stated in the message from 5th/6th March still stands:

    Spoiler: show

    Well, the plan is still to deprecate ZScript for 3.x, so, as we pretty much plan to evolve ZScript, and flesh out some of the things that were never done, and implement a helluva lot of things, I doubt that what we're doing would be compatible, in terms of scope or code, with the plans for 3.0.

    The enemy code is only a tiny portion of it. Take a look at how few enemy-based materials are on the list. The biggest thing is an npcdata class for ZScript.

    The biggest difference between these forks, or branches, is that we aren't planning to implement AS at all. At best we'd add a facility to export ZS as AS code, which may, or may not ever happen. We plan to improve ZS and ZASM, toward an end-goal, which is mutually exclusive to conversion to AngelScript.

    That's exactly why we wanted the 2.x source, and why none of us even wanted to review the 3.0 stuff.

    As much as we appreciate what you two are doing, when the source was first released, we pretty much said, 'the hell with that, it's not what we wanted', and never looked through any of it.

    So, unless either of you have some plans to continue working on anything that falls into our group's agenda, I doubt that merging these back into one thing would be feasible, or even desirable. It would probably end up as a battle between implementation, and a real mess, given that we're pretty much going with the direction of a natural evolution of 2.5, and not a rewrite of any kind.

    To demonstrate this even further, our discussion on the possibility of shifting to Allegro 5 was about one paragraph of text over the last few months, in which out verdict was 'forget that'. We've actually considered fixing issues in Allegro 4 itself, instead.

    The goals of what we want to do, fall greatly in line with the fact that each of us has a ZScript engine that is in excess of 100k lines long, that we will never want to rewrite, that would greatly benefit from making enhancements to ZScript. Dimentio is obsessed with improving SCCs, which I would personally be in favour of deprecating, but other than that, most of what we want to do is laid out on the To-Do list, and I simply doubt that any of it falls in line with the 3.0 goals, at all, at all.

    Have a quick scan over it, keeping in mind that we do not want to deprecate ZScript, judge for yourself, than tell me if I'm wrong.

    I simply do not believe that most of what we want to do, is anything that either you, or Saffith want to do.

    If you two want to work on a system where both ZScript+ZASM and AngelScript are fully supported through both 2.x and 3.x, and in which ZScript (and ZASM) will not be deprecated in 3.x, we could probably do that; but the present model that you laid out for 3.x makes this clearly impossible.

    Another point, is that if we can get this to compile, we could have an improvement version out in 1 to 2 weeks. If we keep our goals organised, we could probably have a decent release every six months or so. ZC3 doesn't even have any specific goals laid out, other than 'rewrite and use a new script engine'; neither of which interest us at all.

    For reference, take a look at the size of these engines:

    https://github.com/ZoriaRPG/RPG_zh/t...ha-Development
    https://github.com/gwx/champions-challenge-scripts/

    Then bear in mind that both of these are Alphas, and roughly 40% complete. We may even merge the two. What we want to do, is make ZScript more robust, without breaking any compatibility,to be able to do more with is, using less hackish methods.

    Dimentip, and I, both want to improve ZScript drawing,and we can probably get a 2.53 beta out that does that, which is 100% compatible with all existing scripts, then continue to improve it.

    The only reason that we don't already have a 2.53 beta ready, is that we need to muck with outdated makefiles and project files, until it works. If we had your latest project files, I could patch in the changes, and actually, you know, test them in the real world.

    In contrast, ZC3 is years off, and even 3.x doesn't have a simple way to build it. Thus far, no-one has been able to get it to compile, either.

    So, pretty much if you wanted us as team players for 3.x, there'd need to be some heavy discussion on goals, full ZScript support as an imperative, including the enhancements that we want to add; and better filesharing and source management; far improved communication, a real plan, and other things that I just don't see happening.

    Hell, if either you or Saffith just sent me a ZIP with every file. of exactly how 2.50.2 is laid out, with both all the src files (with includes, and support files), and project files, makefiiles, and such that he used to build it, and a note on what version of VS/VC I need to use, we'd have had a new version ready to roll out, now.

    That aside, I think that the original plan to implement all enemies, and other class objects as AS code for 3.0 was a good plan, as it would allow complete control over the system by the user, which is precisely what Christopho did with Solarus. The difference, is that ZC3, would have GUI interfaces for modifying those operational variables, whereas Solarus does not (yet) have those.

    I have no idea why this changed, and given how much of a state of flux the general plan is for 3.x, I don't think it's anywhere near ready for showtime; meaning for anyone who might be interested to do any sort of useful contribution.

    Anyhow, I think I summed this up best by stating that 2.future, and 3.x are mutually exclusive goals, and would be incompatible by premise. You pretty much have three, maybe four people who want to work on 2.x, of which only one might be interested in working on 3.x, and he's not even committed to 2.x.

    If it comes down to it, we'll just release unofficial stuff, and if people want to use our stuff, they can. if they want to use quests that rely on it, they'll need it to play them. The difference, is that if what we make has official standing, more people would adopt it, but I get the sense that you want to avoid people adopting a more advanced ZScript engine, as that would make AS integration and backward compatibility harder for 3.x.

    I'm also going to note one more thing: Saffith hasn't said one word, or responded at all to any of our 2.future stuff; and that includes PMs. I pretty much am getting the vibe that he disapproves of it, of us, or whatever. I know he's a stickler for his own personal plan, and what we want to do clashes with that. He's also against any large changes to 2.x, which is precisely what we want to do here.

    I had many discussions with him over the last two years on ways to improve ZScript in 2.x, and he pretty much naysay'd all of them, because it would break from his versioning & compatibility model. We're nipping that in the bud here, and our new model would make quests of any version require that version, or higher to run; which is the diametric developmental style to Saffith's.

    I just don't see anything working out here, for full collab--if that is what you had in mind--with the present level of communication, and our divisive goals.

    In conclusion, if it comes to me making a choice of being an official developer, stuck abandoning ZScript, or an unofficial developer improving it, I'd go with the latter, as would Dimentio, and we're the only two willing to be stuck doing this as a full proposition. It's what I want to do, and I'm not personally concerned with any form of status; only our shared project goals.

    The absolute only reason that we wanted official blessing for this, is so that people wouldn't look at it as some deformed, bastard stepchild. If we make it, it means we plan to support it, but we aren't asking you two to support it. That's precisely why we petitioned for the 2.x source, and made our intentions clear from the onset.

    I welcome your thoughts on all of this, but again, I get the impression that you don't have a problem with what we intend to do, but Saffith does.


    Reiterating this now, and here, because it's only even clearer now that out goals clash. @Saffith 's responses in this thread only further my belief that what we want to do clashes with what he wants to do, which pretty much means we need to do our own thing.


    @ZoriaRPG : You may just change your mind about working on ZScript when you see the angelscript module do the same things, plus more, with only about 10% or less of the work ZScript would take. I'm also planning on plugging in a JIT compiler at some point in the future, which would allow scripts to be compiled to machine code and run closer to c/c++ speed.
    Never going to happen, I'm afraid. I have far too much time committed to my work to even consider converting it, and I have no interest in doing it anyway. I'd rather just erase all of my work to date, than waste even more time converting it. I wouldn't touch it, even in the future, if it wasn't 100% capable of compiling the existing script library. Plus, I've already devoted enough time and effort into learning, and tinkering with the Flex parser.

    I'll end up doing the ZScript changes, as will at least Dimentio, one way or another, just as we've said, repeatedly: If the rollback doesn't happen, please just jump to v3 and be done, so that we can get on with what we want to do without having version number conflicts.

    Really, I'm getting tired of the back and forth on deciding what to do with this, to the point that if we can't resolve this very soon, either I'm just going to do my own thing and not care if there are conflicts, or toss the whole thing, along with all of what I've been doing for the last 3.5 years in a rubbish bin and move on with my life. I absolutely do not want to muck with JIT compilers. Been there, done that, never going to do it again.

    We've been planning on how we want to expand ZC 2.5x for a long while now, and when the source release that we've been anticipating for so long was a wholly different beast to what we wanted to work on, it came as more of a slap in the face than some huge reward. it's been another two months, and it's still the same circular argument. We want to expand what we have, not convert it. That's all.

    Short of that, you pretty much lose all the volunteers that you have at present.

    I'll also note that we could already have a 2.53 release done, if everything in the repo wasn't so mangled. The Git repo for a 2.5 trunk should be no more than your last working path of 2.50.2/3 with all the support files, laid out exactly as they are on your system, so that all one need do is download the ZIP, unarchive it, open VS, and Build. Instead, we have to manually meddle with everything, grab external stuff, and then we still run into problems.

    Now we're going back and forth between two completely different models, because of LOC?!

    Please either work on ZC3, or 2.6. One or the other, pretty please. If you want to force AngelScript, then please just slap a ZC3 label on, it, send us a ZIP file of your 2.5x layout, and we'll make our own 2.5 repo as we planned from the onset. If we have to keep waiting just for a decision on this, then it's not open-source: It's shared closed source.

    2.50.2 works, and is proven. It should have been the initial commit. We want to use that as a base, not something wholly new.

    @Dimentio @Grayswandir @Samer

  5. #15
    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%
    And this is what happens when you open source too early. People bicker back and forth. Sigh...
    @ZoriaRPG
    I also agree that 2.5.2 should of been the initial commit. >_>
    Last edited by Tamamo; 03-27-2016 at 05:42 PM.

  6. #16
    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'd prefer to keep the 2.X line, and slowly move into 3.X. If we are truly adding Angelscript, I feel it should be a side thing, and not a forced upgrade. Remember back when people kept on using 2.10 and 1.90 because they found later versions buggy? I feel that forcing an upgrade could result in that, but more because of the removal of ZScript. People are attached to it, despite it's flaws.

    A JIT compiler? Depends. If it means less lag and no overcomplications, then I'm for it.

    Also, I vote that if we do decide to upgrade to Angelscript, that we call it ZScript, because Zelda Classic, ZQuest, ZLaunch, etc. Also, the amusing side effect of the confusion it'll cause. "Wait, so you mean the old timey ZScript, or that darn, new-fangled ZScript these kids be talking about these days?"
    Last edited by Dimentio; 03-27-2016 at 05:36 PM.

  7. #17
    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%
    @Dimentio
    Making Angelscript optional would be a pain in the ass.
    Let me put it this way. The enemies currently are Angelscript Classes and so is Link. Weapons and Items haven't been converted yet.
    In otherwords we would need two classes for each entity and that's just trouble waiting to happen

  8. #18
    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%
    Alright, if that's not possible, then ZScript. I haven't seen enough of Angelscript to eve n know it's going to be better than ZScript, so I'm going with what I know works, and just improve that.

  9. #19
    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%
    The best way to handle it is to create two branches of 3.x one for zscript and one for angelscript.

  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%
    That could be a solution... But then we have 2 separate groups working on 2 separate projects,which could either speed up or slow down development.

    I'm all for whatever plan is the most efficient.

Thread Information

Users Browsing this Thread

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

Tags for this Thread

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