Read text from arbitrary lumps from ZScript

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Read text from arbitrary lumps from ZScript

Re: Read text from arbitrary lumps from ZScript

by _mental_ » Wed Nov 01, 2017 7:43 am

You can do String.Split() on lump's content several times: with "\n" as delimiter first to get individual lines and then with own separator on each string to get tokens.

Execution of arbitrary lump as a script is technically doable. Although I'm not aware of all side effects it might have. So I would leave to Graf to decide.
To clarify, I'm talking about rudimentary dynamic loading: your code loaded from ZSCRIPT lump will decide what additional script(s) will be processed.
Of course, each script can be loaded only once (and cannot be unloaded). Class replacement will be partially functional. Most likely there are some more subtle issues with this feature.

Re: Read text from arbitrary lumps from ZScript

by Major Cooke » Mon Oct 30, 2017 4:12 pm

Right, that's what I was intending on doing -- using a dynamic array and gathering up a large list of actors, but that means I would need some form of tokenizer system according to Gutawer and TZK, though that's also reading outside of the mod itself.

Re: Read text from arbitrary lumps from ZScript

by Graf Zahl » Mon Oct 30, 2017 3:21 pm

Major Cooke wrote:So am I understanding this correctly, we can NOT create an externalized system template?
At the moment: no. The replacing monsters are stored in static data.
However nothing prevents you from inheriting from RandomSpawner and instead use a dynamic array to store the data for the actors to spawn. Of couse you'll have to initialize those lists in code, not with predefined properties.

Re: Read text from arbitrary lumps from ZScript

by Graf Zahl » Mon Oct 30, 2017 3:18 pm

The Zombie Killer wrote:The ACS VM is not limited. ACC and the version of the ACS language that it uses are limited.
Lots and lots of mods that use ACS for stuff it was never meant for speak a different language.
I never said that I was against using ZScript for gameplay scripting, nor is that the case. What I am against is completely removing ACS from that equation. When you make use of features like [wiki]ScriptCall[/wiki], you can expose pretty much any important feature of ZScript to ACS (and therefore C). It's a powerful combination that most people seem to quietly ignore.
ScriptCall's purpose is to trigger complex actions from map events like pressing a switch - not for cobbling together some Frankensteinian mess that abuses ACS for stuff it was never meant for.


The bottom line is: Use the tool that is meant to solve your problems. ACS is for handling map logic - and ultimately that's the only thing it should have been designed for.
It's not meant for programming HUDs, for example. It has been abused to hell and back for that for sure but I have lost count about how many mods I had to hack to make them work sanely again.

Re: Read text from arbitrary lumps from ZScript

by Major Cooke » Mon Oct 30, 2017 3:01 pm

So am I understanding this correctly, we can NOT create an externalized system template?

I.e. For AEons of Death, I would love nothing more than to not have to replace the replacers just to add more monsters to the spawn list if other mods are detected...

Code: Select all

MonsterList
{
// 	Monster Name - Command - Monster Spawner - Category Name
	HL2Dog,	AddTo,	CyberdemonReplacer, HalfLife2
}
I'm getting the impression we can't just do that, right?

If that's a bit too confusing, basically I want to avoid doing this:

Code: Select all

Class CyberdemonReplacerReplacer : CyberdemonReplacer replaces CyberdemonReplacer
Just to add a few extra monsters to it as this will make addons unfriendly.

Re: Read text from arbitrary lumps from ZScript

by The Zombie Killer » Mon Oct 30, 2017 2:48 pm

Nash wrote:I'm curious, why are you so adamant on defending ACS for core-gameplay-scripting still? Your programming skill and understanding is obviously not a limiting factor here, so I really don't understand why you're still insistent on hanging on to the ACS VM, which is ULTRA LIMITED for core-gameplay-scripting (so limited that you have to rely on a third-party/separately-maintained compiler that internally works around said limitations).
The ACS VM is not limited. ACC and the version of the ACS language that it uses are limited.
Nash wrote:ZScript allows you to directly access whatever you need, the things you can alter and modify just "glues" better with the base engine (since you are basically using the same tools that the entire engine itself is using for its core gameplay and mechanics), has better/more integrated API... heck, the direct screen drawing, uncapped frame rate and direct access to keyboard and mouse inputs for UIs alone is one reason I will never go back to ACS anymore for core-gameplay-scripting.

Personally, I have ditched every cringey gameplay-related ACS work I've done over the past years and am fully ZScript now. I only use acc.exe for its original purpose - level scripting. Moving floors, opening doors, things like that.

Not trying to attack you, just trying to understand why are you against jumping on board ZScript for gameplay scripting. :mrgreen:
I never said that I was against using ZScript for gameplay scripting, nor is that the case. What I am against is completely removing ACS from that equation. When you make use of features like [wiki]ScriptCall[/wiki], you can expose pretty much any important feature of ZScript to ACS (and therefore C). It's a powerful combination that most people seem to quietly ignore.
Graf Zahl wrote:I've yet to see any mod that used ACS for advanced scripting and didn't make a mess.
As for said 'external compiler', let me reiterate what I said before: This compiler and its output are entirely unsupported and if the code doesn't work I am not going to waste my time investigating.
In clear English: Do it at your own risk, it may just so happen that stuff stops working later down the line if some changes do not work that well with code from another compiler than ACC itself.
You can make things just as much of a mess with both DECORATE and ZScript. That comes down to the programming skill of the modder.
Anyway, you've made your stance on GDCC very clear in the past, and while I disagree with it, I don't forsee anything I say changing it in the future.

Re: Read text from arbitrary lumps from ZScript

by Graf Zahl » Mon Oct 30, 2017 7:29 am

Rachael wrote: Was any effort made to clarify this?
Not that I know of.
Rachael wrote: Raven will ultimately be the ones enforcing the license, so maybe we should contact them?
No idea if it may help, but if you want to you can certainly try.

Re: Read text from arbitrary lumps from ZScript

by gwHero » Mon Oct 30, 2017 7:14 am

The Zombie Killer wrote:
gwHero wrote: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.
I never took that step; I rather stick with the standard supported tools. It is true that standard ACS has it's limitations, but I've kind of accepted them and learned to live with it. Besides, since it is very easy to expose engine functionality to ZScript, I agree with most people that Zscript is the future way to go. ZScript and the engine are like a dancing couple.

Also, I have not much doubt that ZScript will be extended with map/level scripting too. But will ZScript be as easy to understand as ACS or do modders need to have more in depth knowledge about the engine to get the same things done? This is what I am sometimes more concerned about; it could be a pitfall. On the other hand: with new tools it's usually the case that the more hesitating people among us will gain more confidence when they have learned to use the new stuff, so maybe my concerns will evaporate eventually.

Re: Read text from arbitrary lumps from ZScript

by Rachael » Mon Oct 30, 2017 2:53 am

It seems like the licensing situation is in an ambiguous state. The intent was to release ACC under the GPL (as a blanket package with other Raven source code) but that didn't actually happen.

Was any effort made to clarify this? Raven will ultimately be the ones enforcing the license, so maybe we should contact them?

Re: Read text from arbitrary lumps from ZScript

by Graf Zahl » Mon Oct 30, 2017 2:15 am

Edward-san wrote:Could it be possible to add the ACS compiler in GZDoom, so that there would be no need to insert the compiled bytecode in the wad file?

For licensing reasons this isn't possible, otherwise I would have already done it.

Re: Read text from arbitrary lumps from ZScript

by _mental_ » Mon Oct 30, 2017 2:09 am

I thought about the same before ZScript invention but now it doesn't make much sense.
It's better to spend time on extending ZScript for map scripting than to improve ACS. It will be supported for sure although without any major additions.

Re: Read text from arbitrary lumps from ZScript

by Edward-san » Mon Oct 30, 2017 2:03 am

Could it be possible to add the ACS compiler in GZDoom, so that there would be no need to insert the compiled bytecode in the wad file?

Re: Read text from arbitrary lumps from ZScript

by Graf Zahl » Mon Oct 30, 2017 1:16 am

I've yet to see any mod that used ACS for advanced scripting and didn't make a mess.
As for said 'external compiler', let me reiterate what I said before: This compiler and its output are entirely unsupported and if the code doesn't work I am not going to waste my time investigating.
In clear English: Do it at your own risk, it may just so happen that stuff stops working later down the line if some changes do not work that well with code from another compiler than ACC itself.

Re: Read text from arbitrary lumps from ZScript

by Nash » Mon Oct 30, 2017 1:03 am

The Zombie Killer wrote:Oh I'm aware, I was merely sharing my own stance on those things.
I'm curious, why are you so adamant on defending ACS for core-gameplay-scripting still? Your programming skill and understanding is obviously not a limiting factor here, so I really don't understand why you're still insistent on hanging on to the ACS VM, which is ULTRA LIMITED for core-gameplay-scripting (so limited that you have to rely on a third-party/separately-maintained compiler that internally works around said limitations).

ZScript allows you to directly access whatever you need, the things you can alter and modify just "glues" better with the base engine (since you are basically using the same tools that the entire engine itself is using for its core gameplay and mechanics), has better/more integrated API... heck, the direct screen drawing, uncapped frame rate and direct access to keyboard and mouse inputs for UIs alone is one reason I will never go back to ACS anymore for core-gameplay-scripting.

Personally, I have ditched every cringey gameplay-related ACS work I've done over the past years and am fully ZScript now. I only use acc.exe for its original purpose - level scripting. Moving floors, opening doors, things like that.

Not trying to attack you, just trying to understand why are you against jumping on board ZScript for gameplay scripting. :mrgreen:

Re: Read text from arbitrary lumps from ZScript

by The Zombie Killer » Sun Oct 29, 2017 11:14 pm

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

Top