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

[ZoriaRPG]

I suppose I need to go over all this at some point...

Well, we started making a plan out of this in January, but better late than never; eh?

The buffer is just a std::string. Any limit on it is from that class, and it may vary by platform. Not that it's all that hard to replace, probably.

I suppose we'll find out when we try to do it.

Before I get too deep into this, I feel it important to note that I'm not quite on most of these topics yet. Of the list, there are only two things that I wanted to get into 2.55, which per our versioning plan, would be six months to a year following 2.53/2.54; and that is intended to be the first truly new ZC 2.x release out of our plans.

Dimentio did some npc stuff, and might have done some ZQ string control code madness that I personally want no part of, as Ikd rather not support YAL in ZC with SCCs to do ZScript stuff, which is what he was attempting to do.

When is 255 not enough? That's a significant design consideration for an extremely rare case.

Actually, it's usually weapons that can easily exceed this, but there are some abstract applications for these objects, too. I think we tagged this as 2.6.

/quote]
Why? There's no way to fit that into existing naming standards, it would make it impossible to implement the ternary operator (not that I expect that to happen anyway), and there isn't any obvious benefit.
[/quote]

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.

I know those aren't quite right, but ai'm flat out of steam at present.

In any event, ? by itself can be distinguished from ?[aA-zZ] or whatever identifier tokens you fancy. The key component is that the ? must be the first, or last char in the token. I could probably add a ternary token too, just to test if they are compatible.

Okay, I guess? Again, I don't see much benefit. It'll create more reserved words, and "repeat" in particular is likely to be used in existing scripts.

Some of us just like these expressions. That comes from a language diversity, I expect, but they are useful in some readability aspects. Grayswandir requested a basic repeat statement, I think, and I'd like a do-until expression simply for clarity.

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.

It's not the first time this has happened, and even @Gleeok suggested replacing existing functions with new functions that use the same name, but with more params. I wasn't in favour of that, as that has a high risk factor in breaking existing scripts.

That's going to be seriously limited without fundamentally changing how scripts work. Functions aren't shared among compiled scripts, so a pointer passed from one script to another would become invalid.

This one isn't my idea at all, and I wouldn't want to be the one to implemt it.

UID behavior has already changed in a way that would break compatibility.

Please explain, and give further details on what this is supposed to mean.

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.

Which in turn, is one of the problems with making ZScript functions, and vars that can actually affect the game, without being hellishly buggy.

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.

That was sort of the implied direction for making these vars part of the npc class itself.

Similar deal, plus there are several issues with it already. Lots of rules wouldn't take effect if set while the game was already running. We'd either have to rewrite a lot of stuff to address that, or just accept that it would be inconsistent and unpredictable.

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.

That would require changing the way strings are compiled. And if you did that, TraceS would handle it, anyway.

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.

That would increase memory usage by 134,912 bytes per map. And every byte of that is save data, which means load and save times for even small quests would be drastically increased. To take one example, the save data for Isle of Rebirth is currently about 2.24 MB; with this change, it would become 20.18 MB. And that vast majority of that would be totally unused.
If you come up with a way to do this that allows the memory to be allocated on demand and not saved unless it's used, it might be okay. Simply increasing the number wihtout changing its behavior would be unacceptable.

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

I had not considered that this was another area where zc memory management was so broken. So, sure, if we made huge array sizes for screen datum, we'd need to compress out unused stuff and load it more dynamically.

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.

Again, as long as you can do it on demand rather than saving all bitmaps for every quest.

Naturally, it would need to be something that is added to a save file only after the bitmaps are first generated in a playthrough. The new functions to create bitmap space might help there.

This sounds like the same thing as making Link->Equipment writable. That was the case in 2.50 until build 1187 or so, but it was disabled because it was too buggy and basically unfixable. I don't know the details of that, though.

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.

Supporting 8-bit icons is impossible with 8-bit color. It would require having four palettes loaded at once.

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.

They're unsigned short ints, 0-65535. Drain counters are signed, however, and the counter mod functions take signed arguments.

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.

I don't even want to think about most of this stuff. Suffice it to say, virtually nothing will be easy, and doing it without breaking existing quests nearly impossible.
It took eight years to finish 2.50 because more and more poorly written features were glommed onto a codebase that was already an unsustainable shambles. This is not a practice I am interested in continuing. Don't expect approval of anything that would make maintenance more of a nightmare than it already is.

None of claimed it would be easy, and pretty much, the understanding is that if we make 2.5x stuff, we're stuck supporting it. Either way, it's all stuff we'd like to do, but not something we swear we'll be able to pull off, and it's part of a four-year overall plan, with one release a year, as the general model.

It's hard to say what on the list will prove possible on a per-version basis, or if itks even possible, until we write it, and test it. We aren't trying to strongarm you into doing any of this, at all. Really, we aren't looking to burden you with this; but we do appreciate being able to consult with you from time to time, as needed, to ask technical questions, as long as you don't mind doing that, while you do the things that you want to accomplish.

Now...I've worked a 22-hour shift, and been awake for 30+ hours, so I'm siging off, to pass out.