User Tag List

Page 8 of 12 FirstFirst ... 6 7 8 9 10 ... LastLast
Results 71 to 80 of 115

Thread: AngelScript: The Revenge

  1. #71
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    38
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,582
    Level
    30
    vBActivity - Bars
    Lv. Percent
    54.36%
    I was wondering about why we would develop zscript into a message based language if we were implementing AS

    Let me collect some points

    Reasons for implementing AS:

    Its fast
    - it gives us the changes we want in a faction of the time it would take to do the same in zscript with a more robust end result

    AS is better
    - angelscript is a fully developed, tried and true which will outperform zscript. Zscript was hacked together from some DIY kit and ZC s main devs from the last few years were loathe to touch it.

    Reason against AS or doing AS/ZS parallel:

    Some users might have to deal with a change

    Masochism
    Last edited by SUCCESSOR; 02-01-2017 at 12:37 PM.

  2. #72
    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.31%
    @ZoriaRPG

    I get what you are saying, but I don't have time right now to go over all of that. I wish you would post smaller chunks of text when there is only a few key points relevant. :/

    1) You are making a huge deal about arrays for no good reason. Here is a ZScript array:
    Code:
     int a[] = {1, 2, 3};
    //or
    int a[3];
    Here is an AS array:
    Code:
     int[] a = {1, 2, 3};
    //or
    int[] a(3);
    //or
    int[] a; a.Resize(3); //etc..
    Array<int> = {1, 2, 3};
    Array<ffc> f;
    Array<MyClass@> ae;
    eweapon[] aew;
    //etc....
    Oh my god! They are so different I don't know what to do!?

    2) int a = 0.5; This will end everything and the sees will boil! ...No. This is caught at compile time. No debugging required, just change the stuff to other stuff when the compiler tells you you fucked it up. ...or... just don't convert it to AS and keep using ZScript. Old quests will still work. ZScript will still work. I've said this enough already.

    I know that your scripts are hacks built around the fact that ZScript is very limited in features. Surely you also must recognize that your scripts are by far the most 'out there' and are not a good sample of normal scripts. I'm sorry that migrating your stuff over to AS is by far the absolute worst case scenario, but for most people it's nowhere near as bad. So just keep using ZScript if you want.

    I've used angelscript for two side projects over the last 6 years. It works great. The only people not in favor of improved fully-featured script support for future versions seem to be you and Dimentio. If you can explain that without strictly /personal/ reasons or motives and why it is not good for future ZC users then I'm all ears. If you can't then, well, we're just going to have to bring back General Bitching.
    Last edited by Gleeok; 02-01-2017 at 02:21 PM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  3. #73
    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.31%
    Quote Originally Posted by ZoriaRPG View Post
    Clarify 'this' in the above statement, and I can give you a concise answer.
    this = everything that AS already does that would need to be implemented from scratch in ZScript.

    Quote Originally Posted by ZoriaRPG View Post
    Well, let's count who we have that is even remotely interested in this, and is working on the source. Then, what are our priorities, and what is our release schedule? I was going to do one release every six months. I wanted to have 2.54 out by now, and every time I feel that we are close, we end up in a month-long debate about something.

    Are you construing my input as an active developer, in that it is directly meaningful; or am I just throwing opinions to the wind, and waiting for your approval? I thought it was the latter.
    It's not me who's arguing with you about /your/ new features, it's the other way around. I try not to interfere with what you want to do at all, but you have to realize that when all the active ZC devs tell you some very small feature is a bad idea and we won't take it it's probably a valid point. I think some of the things you added are pretty cool and hopefully you can streamline the keeping up-to-date with the zc repo to make it easier. I'm the type that likes new stuff. It's unfortunate that I started on ZC when it was such a mess with getting 2.5 done and I couldn't do anything major with it.

    Quote Originally Posted by ZoriaRPG View Post
    What I would like to see is array conversion, array pointer handling, and a method of typecasting all ZScript values to any single type. If it can;t do that, then it is a second language, tacked onto ZC. That means that at some point, we will stop adding to ZScript, but still include its parser and ZASM; and all new content will be via AS, and its parser. I don;t like that option, over properly implementing a cross-compiler, or interpreter.

    If it was for a ZC version in which we were not concerned with full legacy support, then it wouldn't matter. In that, I want to do massive engine changes and improvements.

    What we could do, is simultaneously develop 2.xx and 3.xx. I don't mind that option,particularly if Successor wants to work on rewrites; but I'm not some teenager who can skim this material, pick up in it in a heartbeat, and do something with it. I'm an old codger who takes his time doing everything.
    It's for both. Existing quests won't use it but new quests will have people switching over to AS.

    Quote Originally Posted by ZoriaRPG View Post
    Let's face it... This project is severely understaffed, and no level of re-factoring will change that unless ZC somehow becomes massively more popular. It;s been open for over a year, and you still have precisely the number of new people on board that you did, before you released 2.50.x. I was about ready to just say 'the hell with it', and again resume my plans just to work on the fork, because I'm a bit sick of the arguments.
    This is why we don't need people working on incompatible things when we can work on the same thing and get it done faster.
    Again, I'm not the one arguing.

    Quote Originally Posted by ZoriaRPG View Post
    I can't routinely debate these things, and I need to get the merging done, and get a version in Gamma. I want to get the drawing stuff in it, and I want to get most of our new features in it as well. Link.cpp needs a lot of work for 2.55 that will need to wait, and clearly isn't going into 2.54, because I can;t get anyone else to work on it with me. That seems more important than changing the script engine, at least, to me.
    Link.cpp sucks, but the enemies are needing a rewrite right after the the next (maybe 2 or 3) 2.5+ release. Totally different discussion though.

    Quote Originally Posted by ZoriaRPG View Post
    Most of our stuff relies on how array pointers work. Perhaps if AS can't support them, then it is just the wrong choice for a replacement language. Perhaps we should contact Andreas and see if he is willing to discuss how to make our bizarre types work with a conversion of some kind.
    Arrays are not pointers. Again you refer to /our/ meaning this is a personal matter, not one that reflects the overall ZC community.

    Quote Originally Posted by ZoriaRPG View Post
    But above all else, I would ask: Who else, developing ZC right now is going to work on this? I know in advance that Dimentio is not. He objects to the whole idea. I can't speak for the others, but if it means taking time away from what we are already doing for ZScript, then I can't justify it. I'm not looking for a quick way out of ZScript. I was only interested in AS because of what it offered to enhance our present scripting capabilities, but if it means rewriting everything, then it's just not practical.

    How often have we had that debate; and have people said that it would be almost perfectly compatible; then find some way to justify that some grievous lack of compatibility is worthwhile? If it truly cannot be made to be compatible, then just forget it and work on something else.
    What /are/ you doing for ZScript? How am I supposed to know that? Where is the code that does it, or, the spec that defines it? Don't get mad at me for being in the dark here... O_o
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  4. #74
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.7%
    ZoriaRPG, the major premise in your post appears to be that if ZC does not support old ZScripts integrating flawlessly with new features, then everybody will refuse to adapt and the change is not worth doing.

    I think this position is more conservative than the historical evidence has borne out. Nobody cares nowadays, for instance, that ZAsm is completely incompatible with ZScript and that you cannot easily write ZAsm scripts that interoperate with ZScript. Similarly, if some new hotness like scriptable enemies and weapons works only with AS, I think scripters would learn AS a lot quicker and adapt a lot faster than you give them credit for.

    All that said, nobody here is ruling out a 100% working cross compiler, or fully functioning messaging system that supports ZScript and AS side by side. These are separate questions from the main topic here, which is brainstorming a messaging/callback system, a change that will help tremendously in making enemy and weapon scripting tractable, no matter what language the scripts use.

    You are right that working simultaneously on AS and ZScript messaging is a spreading-out of scarce resources, but if you and Dimentio care passionately about maintaining compatibility of ZScript, perhaps you can help out with this task. As far as I know nobody (including Gleeok) objects to ZScropt and AS working side by side for the time being.

  5. #75
    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.06%
    I denoted the individual, key response points,in bold text, so that you can examine them at your leisure.

    Quote Originally Posted by Gleeok View Post
    @ZoriaRPG

    I get what you are saying, but I don't have time right now to go over all of that. I wish you would post smaller chunks of text when there is only a few key points relevant. :/

    1) You are making a huge deal about arrays for no good reason. Here is a ZScript array:
    Code:
     int a[] = {1, 2, 3};
    //or
    int a[3];
    Here is an AS array:
    Code:
     int[] a = {1, 2, 3};
    //or
    int[] a(3);
    //or
    int[] a; a.Resize(3); //etc..
    Array<int> = {1, 2, 3};
    Array<ffc> f;
    Array<MyClass@> ae;
    eweapon[] aew;
    //etc....
    Oh my god! They are so different I don't know what to do!?
    I don't know if you are deliberately mocking me, or if you missed my point; but I will clarify, if the latter. This concerns array pointers, not array declarations:

    Code:
    int foo[32];
    int arr[16];
    arr[0] = foo; //pointer for foo is stored in arr[0];
    
    int ptr = arr[0];
    pr[20] = 5; //foor[20] = 5
    This is extremely commonplace array pointer usage. because AS doesn't have (traditional) pointers, I am concerned that this will break.

    Will it? Evan effectively begged me at one point to ensure that this would never change. He and Moosh both use arrays by reference in precisely this way in almost every one of their ghost scripts. Gray, ywkls, and I all do so in our engines. It's not trivial, if it changes.

    Quote Originally Posted by Gleeok View Post
    this = everything that AS already does that would need to be implemented from scratch in ZScript.
    Here is what we seem to have, as a general plan, with some aspect or another complete.

    Additional C Syntax : Switch-Case, Define, Enum, Structs (or something similar), potentially classes. -Grayswandir, minor contribs from me.
    Sophisticated Messaging : -DarkDragon
    Enhanced string and array usage : Array declaration improvements, usage of maths, and constants for array sizes. String literals (limited, but functional). -Grayswandir
    Function pointers, that work similarly to handles in AS. -Grayswandir

    I'm sure there are other things that these two are working on at present. I was going to add in enum and define, if Gray doesn't, and I sent him the rules that I wrote for define, and some stuff for constants and other materials. He wanted me to hold off on doing anything else, particularly adding npcdata, and other script types, until he finishes his present round of changes.

    I have not focused on the parser itself of late. I mainly worked on the ZScript language, which I shall cover below.

    It's not me who's arguing with you about /your/ new features, it's the other way around. I try not to interfere with what you want to do at all, but you have to realize that when all the active ZC devs tell you some very small feature is a bad idea and we won't take it it's probably a valid point. I think some of the things you added are pretty cool and hopefully you can streamline the keeping up-to-date with the zc repo to make it easier. I'm the type that likes new stuff. It's unfortunate that I started on ZC when it was such a mess with getting 2.5 done and I couldn't do anything major with it.
    I only wish. If I could submit the changes that you will ratify, and do it in a sane manner, then keeping it up to sate in a streamlined manner would be easy-peasy.

    The changes are scattered around in various ways; see the links listing the changes below. There is no way to do this that isn't gong to drive me mad, under the present accepted method. You both want to maintain a repo using pushes, instead of commits. That just isn't hot the software was designed to flipping work. I literally need to make twenty or so identical forks, apply some of the changes to each, and mind, some of these changes depend on one-another, so I need to either (submit incomplete/non-working changes), or (lump more together at one time and hear complaints about total push size)--and pray that some other change doesn't make an auto-merge impossible; and be asked to do it again???

    That is absolutely ludicrous. You wonder why I'm not working on AS, and why I frankly don't want to be bothered with it? Hell, I have to merge in Dimentio's changes, too; and when I wake, and think about doing it, I get such a bad taste in my mouth between the constant complaints, and the sheer volume of merging many, many, tiny changes, that I just decide to do something else.

    It's for both. Existing quests won't use it but new quests will have people switching over to AS.
    (Emphasis, mine.)

    Wait, what? Now we're going back again? Can we please clarify if after adding this AS parser, people will be able to flipping compile a ZScript script, without changing it? I don't care how it's compiled, just that it compiles. What you say here, implies that the change is forced on the user. Earlier you said they could use both or either. Before that, it was one or the other. Which is it, again?

    What bothers me, is that even between the last few posts, or in the same post, I see wholly-contradicting points. If your AS implementation is a module, and the ZScript parser will work alongside, in parallel or otherwise, I certain have no objections at all. It is the one-or-the-other philosophy, that brings in potential problems; and aye, I have objections to it, but not merely because of any personal issue. I can easily make a custom ZC build to suit any purpose that I desire, for my own personal needs, or just modify my scripts if I wish. That is not the point; not at all.

    This is why we don't need people working on incompatible things when we can work on the same thing and get it done faster.

    Again, I'm not the one arguing.
    This is what happens when you let four mice out into a cage with cheese at both ends. You want us to work on this thing, we want to work on our thing, and no-one is happy. At present, I think what we want to accomplish, is to get our planned changes in and done, and get out a new version that is both more sable, and offers more to the user, before even considering any other radical changes.

    For the most part, expanding the capabilities of ZScript, and adding non-scripting features so that scripting is not mandatory for various effects; and adding in other elements that are useful to scripter and non-scripter alike, have a higher priority to us than making structs, or other far more advanced concepts that AS may offer. What's the carrot here?

    I'm the only one adding in actual ZScript commands. I have no problem with the system of doing this at present, and no urgent need to change it. My complaints stem from how the ZC classes are designed, not the way to implement things in the scripting language.

    Dimentio wants to work on weapons, items, and strings. He hasn't shown the slightest interest in working on ZScript, AS, or the parser.

    Grayswandir seems to enjoy the challenge of adding things to Flex-Bison. I don't know if this is my false perception, but he appears to get a thrill out of making new things work, that he himself added.

    The only person so far that seems to care is Successor. Hell, even Tamamo is opposed to this, for no reason that i can clearly comprehend, other than to want something else that she has no specified. Should we just do a Ruby parser, and be done?

    -------------------

    I know that there is a long-term benefit involved, but when I say that it will be a while before I can get to it, and you flat-out threaten to quit, that just tells me that you don't give a damn. I know you are going through hell in your life. Some of the rest of us are in pretty bad spots, too. I can't just stop everything I'm doing to work on some new aspect that I don;t believe needs to be done immediately; particularly when it is too much trouble to read one of my replies, much less to read through any of the code changes, or other stuff that I've done, or other threads on matters that I feel are important.

    Your time is valuable; so is mine. I can't say which is more finite, and limited. I can say that I'm getting far too old to care at times. You probably feel likewise.

    -------------------

    Arrays are not pointers. Again you refer to /our/ meaning this is a personal matter, not one that reflects the overall ZC community.
    See above.

    My reference of 'we', 'our', and such, is as a collective, referencing the totality of developers and users; in this case, the types that ZScript, and everyone using it, uses: int float, bool, npc, *weapon, ffc, itrem, itemdata. How was that coded that it wasn't clear?

    What /are/ you doing for ZScript? How am I supposed to know that? Where is the code that does it, or, the spec that defines it? Don't get mad at me for being in the dark here... O_o
    [/quote]

    Everything that I've done is out in the open for scrutiny. I don't feel the need to post every little thing, so I keep a change log, and 'update' docs that anyone may elect to read.

    Source Pack
    Change Log
    ZScript Changes | (Abbreviated form.)
    ZScript Syntax Changes
    ZQuest Changes
    ZStrings Changes
    ZC Changes

    Quote Originally Posted by DarkDragon View Post
    ZoriaRPG, the major premise in your post appears to be that if ZC does not support old ZScripts integrating flawlessly with new features, then everybody will refuse to adapt and the change is not worth doing.

    I think this position is more conservative than the historical evidence has borne out. Nobody cares nowadays, for instance, that ZAsm is completely incompatible with ZScript and that you cannot easily write ZAsm scripts that interoperate with ZScript. Similarly, if some new hotness like scriptable enemies and weapons works only with AS, I think scripters would learn AS a lot quicker and adapt a lot faster than you give them credit for.
    Hmm... Who, in reality, ever used ZASM? I did, a little bit. I know of what..one other user who did? I published one whopping ZASM script in the last ten years, and it does in fact, interoperate. It is designed to do precisely that, to allow 2.5 users to use a feature that was never implemented in ZScript. :p

    I think you underestimate two things. One, is that the majority of ZScript users are not programmers. They manage to hack their way around, stumbling blindly at times, and they are more than happy to accept horrible, bugged results, if they work for their application. This tends to lend to laziness, and the desire not to move to anything new.

    The second, is that the number of scripters out in the wild is small, and compared to the library of extant scripts, any new material is likely to me marginal, at best. This limits the resources for the user, and my considerations have the userbase in mind as a whole on this basis, not merely if something is inconvenient to a scripter. It's hard enough to explain how to import and compile a basic script to the average user. They simply are not willing to learn; and stemming from that point, they are not going to edit scripts to bring them in line with a new spec.

    No, instead they will ask the scripters to do it for them, as they always do; and this time, no-one will ave any clue what to do, save for perhaps five of us. I can name only one scripter who is a programmer, can comprehend these changes, and is not in some way involved with ZC dev: MoscowModder.

    (What happened to that userbase poll? It wasn't by job to run it. In fact, I stayed 20 metres away from that, to avoid any possible impression of a conflict of interest.)

    All that said, nobody here is ruling out a 100% working cross compiler, or fully functioning messaging system that supports ZScript and AS side by side. These are separate questions from the main topic here, which is brainstorming a messaging/callback system, a change that will help tremendously in making enemy and weapon scripting tractable, no matter what language the scripts use.

    You are right that working simultaneously on AS and ZScript messaging is a spreading-out of scarce resources, but if you and Dimentio care passionately about maintaining compatibility of ZScript, perhaps you can help out with this task. As far as I know nobody (including Gleeok) objects to ZScropt and AS working side by side for the time being.[/QUOTE]

    The problem here, is that the idea of them working, side-by-side, seems to be like a pendulum. If they do, fantastic. I couldn't ask for more, as it gives the choice of which to use, to the user, and the choice of which to expand, to the potential developer. I' am however, a bit weary of repeating that I do not have the time at present to dedicate to learning how AS works internally, en lieu of working on my present goals. I suspect that @Dimentio feels likewise.

    We both have very specific, and compatible, end-results in mind. There is in fact, a reason that we three, decided to work together. It's because we do not bicker about what we see as our vision for the next ZC/ZQ version. I certainly can't help with a task when the goal is as clear as mud.

    The bottom line for me, is that any one of these outcomes should be true:

    1. AS is not 100% compatible, but future versions will still support compiling ZScript code. We may even continue to update ZScript, and support both in parallel for a while.

    2. AS is 99.9% compatible, with a very rare instance of something needing a change. Note, this does not mean changing types, or how some 'advanced' tricks' such as pointer handling are done. We still support ZScript, somehow, if it is needed, but we don;t spend much time on it.

    3. AS is perfectly compatible, every single thing works, we abandon ZScript, and march merrily along.

    4. AS doesn't work as planned, and we make ZScript 2.0 the next big bombshell.

    The result that I won't accept--meaning, I would be 'done'--is:

    D. AS isn't perfectly compatible and we kill the ability to compile ZScript code.

    Does that suitably clarify my position on the matter?

    If 'ya'all' want me to work on this stuff too, then please, make my job easier. Go over my proposed changes, select what you won't take from the list, let me wholly integrate the rest, and be flipping done with this hellish merging process, so that nay future revisions can be kept in sync with the main codebase. I simply cannot spend countless hours doing, and redoing this shyte.

  6. #76
    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.31%
    First thing is first.

    Code:
    int foo[32];
    int arr[16];
    arr[0] = foo; //pointer for foo is stored in arr[0];
    
    int ptr = arr[0];
    pr[20] = 5; //foor[20] = 5
    Are people actually doing this? There's so many things wrong with this I can't even fathom. AS will not and should not support this.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  7. #77
    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.06%
    Quote Originally Posted by Gleeok View Post
    First thing is first.

    Are people actually doing this? There's so many things wrong with this I can't even fathom. AS will not and should not support this.
    Absolutely. Here is the common way that is is used for ghost scripts:

    Code:
    ffc script ghostffc{
        void run(){
            int arr[32];
            ///
            function(this,ghost,arr);
        }
        void function(ffc this, npc ghost, int ptr){
            this->X = ptr[3]; //etc
        }
    }
    Literally 'every script' that Moosh and Evan have made, does this; in their own words. Evan's statement when I discussed it with him, over a year ago, was something like this:

    'Please tell me that this will never change. Everything I do relies on that.'

    This is also how many scripters commonly use arrays in scripts, for engines, and otherwise. It is why I brought up array pointers, multiple times. I don't even know of a way to pass arrays in Zscript, otherwise. You need to store pointers for local arrays, to allow other external scripts to access them. Hell, I do it in ffc scripts, by storing the pointer for the ffc's local array in a Misc[] index, then referencing it with external functions. This is because scripts are not handled like classes, and their local variables/arrays can't be accessed with scope resolution; and of course because array pointers aren't handled as in C.

    Quite a lot of that is due to the limited size of the Zscript stack, but that doesn't solve the issue of compatibility. No simple change of types, or preprocessor warning, is going to fix this.

    If AS supports scope resolution to do that, that's fine; but in order to preserve the extant scripts, if the AS parser can't handle this, then the ZScript parser will need to be maintained in parallel, somehow.

    Do you see my reason for concern? I can say with surety, that over 30% of the scripters still around do this stuff, and that half or more of the ZScript Skype members do it routinely. Every ghost script that I have seen from Moosh and Evan does something along these lines. They expect that a pointer can b e passed as an integer; plain and simple. 95% of what all of us do, would break, without this.

    I'll even go so far as to note that I recorded a stream explaining how this works for a user, last week. He needed to be able to reference an array local to an ffc with external function calls, so I showed him how to do it, along with a series of warnings. If you want to view that stream, I will upload it. The point is that is is common enough that scripters teach it to one-another, and to new scripters, as the 'standard method' of doing this.

    I'll add as an anecdote, that I'm stunned that you aren't aware that ZScript users have been doing this for years. I learnt this technique from Evan, Moosh, and Gray. It explains why you dinna' sense my level of dread when discussing this earlier, why you didn't know why I was mentioning pointers, and some other key factors that I have tried to bring up, only to be met with silence, or seem'd disregard.

  8. #78
    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.31%
    They only do it because you have to use hacks to get around the limitations in ZScript. ...But at least tell people that they should not do this with global arrays, or, at least no global array should be used to propagate this behavior from local arrays.

    In AS no hack is required; you can pass arrays from anything to anything else if you want so long as it is type-checked. You can even get member variables declared in one script by another script. Heck, you can even have 100 global scripts communicate with each other and destroy/create each other. These are all built-in, and very simple to use script-side and c++ side. That is why I say we'll be saving years of dev time.

    But AS compatibility just dropped to no higher than 98% now.

    In the future just post the thing that is relevant so there's no confusion. I've never seen anyone do this, and it technically should be a compiler error, although it's a little late for that.
    Last edited by Gleeok; 02-03-2017 at 08:27 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  9. #79
    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.06%
    Quote Originally Posted by Gleeok View Post
    They only do it because you have to use hacks to get around the limitations in ZScript. ...But at least tell people that they should not do this with global arrays, or, at least no global array should be used to propagate this behavior from local arrays.

    In AS no hack is required; you can pass arrays from anything to anything else if you want so long as it is type-checked. You can even get member variables declared in one script by another script. Heck, you can even have 100 global scripts communicate with each other and destroy/create each other. These are all built-in, and very simple to use script-side and c++ side. That is why I say we'll be saving years of dev time.

    But AS compatibility just dropped to no higher than 98% now.

    In the future just post the thing that is relevant so there's no confusion. I've never seen anyone do this, and it technically should be a compiler error, although it's a little late for that.
    (Emphasis, mine.)

    A little late for this now, too. I do warn that they need to refresh pointers, and that it can be dangerous (because you may be using the wrong data later), but even I need to do this, but I don;t need the data to persist between saves when I do. I do it because I store all of my global values in one array, and I use indices for pointers. I also use this a great deal for string pointers, to make them available between scripts, externally. That's another area where this is often applied.

    Sure, it won't matter for new scripts, but I'm still waiting for absolute clarity on if compiling old scripts via the ZScript parser will be maintained in your plan here. That alone will resolve most user issues, point blank. If they can still use all of their old stuff as-is, and they have the option to convert it to use new features, that would be ideal. I don't have a problem committing to support both languages, if you don;t have a problem allowing me to support both languages.

    Hell, I even added a way to get other-typed pointers to my fork. I need to be able to do that, to reference them externally. That's because there is no way to make a global typed array. Even DD admitted that with the stuff that we do, global special type arrays are pretty much needed for ZScript. Not to force pointers to persist, but to store them globally per-session, and to be able to store and reconstruct special-typed data. That is what type->GetPointer() does, as I had mentioned earlier.

    Now you know why that sort of thing is so useful to us. Some of my magic is simply impossible without it. That equally applies to everyone else. You should look at Moosh and Evan;s scripts at some point though, and see how common this is. Lejes also used it, as i recall, and I'm fairly certain that it is as common as dirt. Is it because it is a hack required to do something? Certainly. Is that actually bad? I think it;s arguable. You can pass arrays by reference in C/Cpp, which is the equivalent of this.

    I'm not sure precisely how AS does it, but clearly it has to allow passing arrays and strings by reference and using them in functions and elsewhere without worrying about scope issues like this.

    Take a look at when I documented this on the Wiki. You might want to read some of this stuff, at some point; you know? (That is my comment, at the end of the page, too.)

    I should further note that this is similarly used for psuedo-2D arrays, and for mass string handling, and en-queueing.

    Code:
    int string1[]="foo";
    int string2[]="bar";
    int string3[]="rats";
    int string4[]="meatballs";
    
    int strings={string1,string2,string3,string4};
    //Draw strings to the screen in a for loops using the 'strings' array, one at a time, adjusting their positions.
    That is how every quest that has scripted credits rolls, scrolling text, or otherwise handles this. make the strings, and store their pointers in an array, so that you can iterate them with drawstring using a for loop (using their pointers).

    Code:
    int subscreen[265];
    int positions[16];
    int items[16];
    
    //etc
    
    subscreen[0] = positions; 
    subscreen[1] = items;
    //etc
    
    //iterate subscreen[] and do all events from the iteration, because ZScript doesn't have real 2D or 3D arrays. Huzzah
    I am not joking when I say it is used EVERYWHERE, by EVERYONE. I know for a fact that Lejes and MoscowModder did both of the above things. This is how I was taught] to do it. Hell, does Tango.zh do it for scrolling strings? Probably not, but everyone else that does scrolling text, or wants to manipulate many strings does it.

    I was taught the '2D array' thing by MoscowModder, and people often (poorly) explain it as 'storing one array within another', which it does not do. I always clarify that you are merely storing the pointer. @Grayswandir also teaches it to everyone, as do I. It is a staple of ZScript. :p

  10. #80
    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%
    @ZoriaRPG please just stop, that is and has always been nothing but foolishness, it's why i stopped scripting in the first place. I just couldn't handle having to write bad code to do the shit I wanted to do.

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