I denoted the individual, key response points,in bold text, so that you can examine them at your leisure.
Gleeok wrote:[MENTION=42228]ZoriaRPG[/MENTION]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:
int a[] = {1, 2, 3};
//or
int a[3];
Here is an AS array:
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:
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.
Gleeok wrote: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 [B]please clarify if after adding this AS parser, people will be able to flipping compile a ZScript script, without changing it? [/B]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
DarkDragon wrote: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. 😛
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 [MENTION=61126]Dimentio[/MENTION] 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.