[ZC 2.54 ] setting Link->Action to LA_DROWNING makes link turn invisable

[DarkDragon]

Right, but what I am also saying, is that the engine shouldn't be directly mucking with them either. I would rather that the engine point to the script engine, and let the script engine have priority when deciding how to handle them. This way, the script engine and the game engine do not diverge. Where the values are stored becomes immaterial, as you can always relocate them.

Yes, this is one way to go. It's not a bad way. Although I'm not aware of the full history, I well imagine that the push to rewrite game internals in AngelScript was one foray in this direction.

If we were starting from scratch, I'd be in favor of the approach you suggest. But if you want a fully-scripted engine, those options exist, and I don't see much point in reinventing the wheel with a Zelda sticker slapped on top (especially since removing copyrighted assets from the core engine is one of our near-term goals!) The unique strength of ZC is its large database of quests that can be played and quest assets that can be reused in the future. Preserving this advantage, while also slowly improving the quality of the ZC code and the power of its features, is a very delicate operation. I don't think ripping out the guts and trying to replace them with something purely scripted is likely to work out.

One thing I can say, is that if you slave the script engine to the game engine, you preclude being able to do things later down the road, that you might want to do. Making the game engine call tot he script engine, gives you far more options. It also maintains uniformity between the two. The notion that a scripted behaviour does A, but the internal behaviour does B, is a huge fault in the engine, as it stands.

Again, I disagree.

The responsibility of the game engine is to maintain a consistent game state. This (heavy!) responsibility shouldn't get foisted onto the scripters or quest authors. They should be able to write code that tells Link to attack, say, without the fear that if they send the command at just the wrong frame, when Link is already doing just the wrong existing action, he gets stuck with infinite invincibility, or starts moving around wildly, or crashes ZC, etc.

That means there must necessarily exist some separation between the interface exposed to scripts, and the internals of how the game actually operates. A blood-brain barrier, if you will. I don't know if you played Megazeux back in the day, but that to me is an example of scripting done right, and an ideal for ZC to try to aspire to. MZX games were extremely scriptable using a versatile language, but the set of commands was restricted and the game environment sandboxed.

[ZoriaRPG]

Yes, this is one way to go. It's not a bad way. Although I'm not aware of the full history, I well imagine that the push to rewrite game internals in AngelScript was one foray in this direction.

If we were starting from scratch, I'd be in favor of the approach you suggest. But if you want a fully-scripted engine, those options exist, and I don't see much point in reinventing the wheel with a Zelda sticker slapped on top (especially since removing copyrighted assets from the core engine is one of our near-term goals!) The unique strength of ZC is its large database of quests that can be played and quest assets that can be reused in the future. Preserving this advantage, while also slowly improving the quality of the ZC code and the power of its features, is a very delicate operation. I don't think ripping out the guts and trying to replace them with something purely scripted is likely to work out.



Again, I disagree.

The responsibility of the game engine is to maintain a consistent game state. This (heavy!) responsibility shouldn't get foisted onto the scripters or quest authors. They should be able to write code that tells Link to attack, say, without the fear that if they send the command at just the wrong frame, when Link is already doing just the wrong existing action, he gets stuck with infinite invincibility, or starts moving around wildly, or crashes ZC, etc.

That means there must necessarily exist some separation between the interface exposed to scripts, and the internals of how the game actually operates. A blood-brain barrier, if you will. I don't know if you played Megazeux back in the day, but that to me is an example of scripting done right, and an ideal for ZC to try to aspire to. MZX games were extremely scriptable using a versatile language, but the set of commands was restricted and the game environment sandboxed.

I suppose it depends on if Gleeok, and Saffith still plan to implement AngelScript in the future. Hell, Grayswandir is doing things with the parser, specifically to support easier ZScript to AS conversion later down the road, and this is why I advised running the game engine off the script engine, as if you are going to eventually replace the script engine with AS, and run almost all the stuff off of scripts, which is how most modern game engines work, them you may as well start working on making the engine calls portable.

I'm just not all that interested in writing either side of that at present.

I also wonder just how much of the extant ZC library is in vogue, at all. Pretty much everything that gets attention at all these days, is a script-heavy quest. That means that there si a significant demand place don the script engine, and that if it was at the forefront, you might have a more popular product. I honestly do not know. What is the reason that RPG Maker, and Game Maker are such popular choices?

Any time that someone mentions them, they praise Lua (I do not care for Lua), and how flexible everything is; how the engine is linked to the script engine, and so forth. Solarus is near entirely tied to the script engine. Even graphics are effectively set by script. Most of these things today run in real time, without compiling. It;s actually rather fascinating, and also, requires far more processing power, and RAM, than i happen to like. That;s the problem with abstraction layers, and JIT compilers.

I also wonder how many ZC users have anything approaching modern hardware, given that most of the questmakers are using systems that are seven to ten years old.

Anyway, I think it;s pretty much your show at this point for core ZC, and you will do what you want. We're still going to produce the 2.future fork, and we'll see what plan evolves. If you create some abstraction layer that works, and does most of what we do in 2.future, we can make a port-over utility. I certainly have no problem contributing to the core, but I effectively know that you are going to take a very small number of additions, and you will not like doing it. Look at itemdata. All of those are tied to class variables. If you don't want to include anhything tied to class variables, that is new, then I hinestly have no idea what you would include from the 2.future basecode.

That's why for the core, I'd rather work on the libs and such, because it just sounds as if you do not want any of our stuff, and neither Gleeok, nor Saffith are particularly active in what you are doing, and despite the stuff you made to date being forks, no-one is going to deny you the lead position in this; I certainly won't. That said, dissuading us from making our own thing here isn't happening either.

If there is anything specific that you have seen in the 2.future base that you think would be welcome, I think it'd be better to work with it in that regard. Clearly, you won't be happy with the majority of our work product, plans, or motivations.

It's not a matter of variables vs functions; that's surface-level syntax and not very important in the grand scheme of things.

The issue here is internal implementation vs. externally-visible interface. If you look at LinkClass::setAction(), you can see there is already a bunch of code there that tries to prevent scripts from issuing actions that break the consistency of the game state. That's the way that actions (and anything else scriptable) should be handled, not by tweaking the internal state and damn the consequences.

I don't know if you're a computer science student, but a key concept in computer science is that of invariants: relations that you can prove must be true about an algorithm as it's running, and that you can use to reason that an algorithm is correct. For example, in a for loop, you know that the index variable must be between the start and end of the for loop range, because if it weren't, the loop would have terminated on the previous iteration. This lets you write code like

for(int i=0; i<size; i++)
  array[i] = 0;

without worrying that you might segfault due to writing past the end of the array.

If some external agent is allowed to muck with the internals of your code at any time (for example, by setting a breakpoint, and writing new values to memory) it is extremely easy to break your code, because you can no longer trust your invariants. I can set i to be size+1 at some point in the middle of executing the loop, and bam, your program crashes. To prevent this, any changes that you make to the program's internal state need to be aware of, and go out of their way to preserve, the invariants. Instead of letting the user write random integer values directly into the memory address of i, you provide a callback which reads the user's new requested value, and sanitizes it, before continuing with the loop.

It is the same with the ZC engine, except much more complicated, because the invariants are unclear and undocumented, and require great effort to tease out in a lot of cases.

At what point did I advise directly writing to the class variables with absolutely no handling? There's a clear difference between sane handling and interpretation, and writing emulation, and onion layers of obfustication.

Computer science student... I've been a student of all arts, and sciences, throughout the nearly sixty years of my life.

I should note that when I went in to try and define LA_CASTING, I specifically used the setAction() function as an entry point. I have slowly been plotting out moving all the direct variable manipulation out of ZScript, so that handlers on the class side interface with it. (I prefer to keep them with the class, when that is rational, but there are things that I would like to move into the script engine.)

My present project involves finding all the engine points that read Link.x, LinkX(), and Link.getX(), and so forth, and setting up Link.AbstractedX() so that hitbox modification isn't as bloody wretched. That is simple separation-based abstraction, and if that is what you want, that's agreeable. If you want ten layers of separation, I'm just not interested in doing it. I can't even place odds on being alive by the time that is done, at the present rate of progress.

There are also some facets where abstraction other than by passing values through a function, seems either superfluous, or for which I see no method.

How you you set invincibility frames, that are normally handled by a class variable? Note that I vbounded it between the legal values, but beyond that, there aren;t any system definitions where it would be illegal, or unsafe. The engine is extremely open-ended about most of those things, from my experience.