[Added] Read text from arbitrary lumps from ZScript

[Gutawer]

Ah, my apologies, didn't see that.

[The Zombie Killer]

@The Zombie Killer
If you so inclined to work with binary data you can access character codes via String.CharCodeAt() function.
The engine doesn't do any interpretation of lump's data, so working with raw bytes is already doable.

This poses an issue when using ScriptCall to access this API via ACS though, due to the string being truncated at the null byte.

[_mental_]

I would like to keep API as simple as possible. Please do all processing in ZScript and use ACS only when something cannot be done without it.
Do not forget that ultimate goal is to replace ACS with ZScript everywhere.

[Rachael]

Do not forget that ultimate goal is to replace ACS with ZScript everywhere.

I thought Graf specifically said something against this because it was "reinventing the wheel." - or at least that's what someone told me, on Discord.

At any rate, if it's really true I'd probably like to introduce a few ACS-specific functions to ZScript, myself.

[_mental_]

Well, I could get it wrong too.

But in any case providing reach API for handling lumps data is out of scope. Reading of packed structures, serialization, etc...
Sorry, it’s embedded scripting language, not generic purpose one like Python or Ruby.

[Major Cooke]

Mostly everywhere. Naturally, map controls should be left to ACS such as level manipulation (scripts to raise/lower walls and all that good stuff).

...ninja'd.

[Graf Zahl]

At any rate, if it's really true I'd probably like to introduce a few ACS-specific functions to ZScript, myself.

Long term I think the entire ACS function set needs to be reviewed for ZScript inclusion and then refactored out of the ACS VM. Maybe the same for FraggleScript so that all 3 languages can access the same code and have an orthogonal feature set when it comes to high level map manipulation.

[Rachael]

I think having a single VM for all of the languages could be beneficial in the long term, at least as far as code maintenance goes.

If it were up to me, I'd probably want to deprecate ACS and let it be nothing more than a means by which to run legacy projects - going forward, updating a singular interface with a singular language will be a huge boon for project authors, as well as the developers.

[Graf Zahl]

I think having a single VM for all of the languages could be beneficial in the long term, at least as far as code maintenance goes.

Too much work. It'd mean translating ACS bytecode to ZScript bytecode which requires just as much code as interpreting it directly and touching the Fragglescript interpreter with all its fickleness is a no-go.

If it were up to me, I'd probably want to deprecate ACS and let it be nothing more than a means by which to run legacy projects - going forward, updating a singular interface with a singular language will be a huge boon for project authors, as well as the developers.

ZScript does not have latent functions which is a core concept of ACS, and unless that changes there's no chance. Writing a thinker to handle this is infinitely more complex.

[Edward-san]

Regarding the lump reading interfering with the lump protection mechanism, I talked with the other devs at Zandronum (yeah, that's what I was referring) and yeah, we can move our mechanism to whitelist-based approach.

Though, in my personal opinion, making mandatory for such lumps to have a name like "ZLUMP_*" could be good?

[gwHero]

Now I do like ZScript and I definitely see the benefits of it, but I really don't understand why ACS is getting less appreciation these days.

For me the two can perfectly exist together; for main map and level control ACS is such a pleasant technique to work with, straightforward and powerful. I don't see how I could replace all my ACS with ZScript, not without much pain, if possible at all. I would not like to see it getting deprecated too soon.

[Rachael]

but I really don't understand why ACS is getting less appreciation these days.

ACS allows an author to distribute closed-source. ZScript forces the source to be open.

ACS requires an external compiler to work with - whereas ZScript lumps can be edited directly with immediate effect.

ACS also requires everything to either in advance have a tag or on-the-fly reference in order to work with it - you cannot simply iterate all of a certain object in a level like you can with ZScript.

Those are my main gripes with it, really.

[The Zombie Killer]

Now I do like ZScript and I definitely see the benefits of it, but I really don't understand why ACS is getting less appreciation these days.

Agreed. Especially when we have tools like GDCC that allow us to straight-up use C in our mods.

ACS allows an author to distribute closed-source. ZScript forces the source to be open.

While it's nice to have everything open like that, I don't think it's necessarily a reason to discredit ACS. If someone doesn't want their source code public, they'll find a way to obfuscate it regardless.
I always thought encouraging an open source attitude is better than forcing it, anyway. Plus, the ACS bytecode format has allowed for various cool things like GDCC, and the stuff Kaiser did in the CIF series.

ACS requires an external compiler to work with - whereas ZScript lumps can be edited directly with immediate effect.

I never saw that as a real problem, plus a compiler can always be embedded, just like ZScript. Even then, I just have batch/shell scripts that automatically compile my scripts and run the game.

ACS also requires everything to either in advance have a tag or on-the-fly reference in order to work with it - you cannot simply iterate all of a certain object in a level like you can with ZScript.

That's caused by a lack of APIs to do so, if anything.

[Rachael]

I am not trying to argue whether ACS is good or not. I am merely responding to the apparent concern about what makes me react the way I do about it.

[The Zombie Killer]

Oh I'm aware, I was merely sharing my own stance on those things.