[Zscript] Mod/File checking

[Major Cooke]

It'd be of great use if we could check for other mods and/or files loaded somehow, preferrably with a function so I can change actors based on what's installed and what's not.

Or, better yet, what about an ability to include a file (Zscript and/or DECORATE) based on what files are loaded? I ask this because this would allow for better handling of replacement actors where appropriate (if we're still calling them actors which I assume so). Also maintaining a project with compatibility for 2+ mods quickly grows old when trying to keep them in sync.

Code: Select all

if "Addon1.pk3" || "Addon2.pk3"
{
#include "zscript/fasterguns.txt"
}
else
{
#include "zscript/biggerguns.txt"
}

Or something.

[Graf Zahl]

Since the loading is based on a control lump there's certainly options. But be aware that ZScript is parsed before DECORATE so you will never be able to create classes in ZScript that inherit from DECORATE.

[Major Cooke]

Anything is better at this point than dealing with multiple replacements that try to override one another. To be able to pick and choose what to load based on mods and/or cvars would be a blessing by itself.

I'm curious, what's the control lump like / what will it be like?

And, understood. I'm looking at Zscript as a means for me to drop both DECORATE and ACS over time, when it's available. I know DECORATE is probably receiving little to no more attention at this point, since Zscript is heavily in the works.

[Graf Zahl]

My current goal is to get ZScript to the point where it supports all the features of DECORATE and then merge it back to master.

At that point DECORATE will be officially deprecated. It may inherit some featurs by using mostly the same backend to process the data but for the most part it will cease to be developed further.

After that I plan to write a converter and then I'll do feature extensions - and maybe Randi is also going to work on it.

Keep in mind, that this is one huge task and I won't have the amount of time I put into this over the last week forever. I just had little to do at work because I finished my last project the week before and the next one has been delayed for a few days so when that starts I'll have to pull back a bit. So don't expect any miracles. Right now I can work at such a high pace because the features I need right now are already present in the backend, I just have to plug them into the compiler. But this will change once scripting features have to be made working that DECORATE does not yet have.

[Major Cooke]

I take it you're attempting to get that DECORATE stuff in zscript done and merged before the start of the project, or am I underestimating? And, strictly just compatibility or is there some new things we can start using like the control lump?

And when that does happen, where will functions be developed from now on for zscript?

(Also I can't help but wonder how the wiki's going to transition all that deprecation. )

[Gez]

(Also I can't help but wonder how the wiki's going to transition all that deprecation. )

DECORATE will be removed from the sidebar, and the main page will be updated.

I don't see what else it'd need. Deprecating DECORATE doesn't mean deprecating every DECORATE function, I'm sure [wiki]A_CustomMissile[/wiki] and friends will stay around and just be available from ZScript too. And eventually they might even end up being defined in ZScript itself.

The biggest task would be to update the actor pages to replace the "DECORATE definition" headers with "ZScript code" headers. Might get a bot to do that automatically.

[Graf Zahl]

I made sure that the transition will be relatively painless. The biggest difference is that for structuring reasons each property and each state line will have to be terminated with a ';'.
All function names remain the same, all parameters remain the same, all properties remain the same (with the exception of the damage function - which due to what the parser outputs can not be distinguished from a simple constant anymore - so it has to use a different name.)
The syntax will be a bit stricter, i.e. string arguments must be enclosed in quotes - the old parser did not enforce this everywhere.

About using it: The first merge will be to ensure that all the changes I made did not break any DECORATE code out there - I had to modify a few places where DECORATE was shortcutting proper resolving of the compiled data, because the input from ZScript is more generic and needs this to be done correctly. You are free to play around with it, of course, but I would not recommend using the unfinished ZScript to actually create production code right away.

[Major Cooke]

Ah I see. Understandable, it's more along the lines of me playing around with it similar to how I did with the merging of the scripting branch back at the beginning of the year. This time should be a lot less stressful though for certain.

What all does the strict parser enforce besides that? From what I can gather:

• Some warnings become errors (Which ones?)
• Quotes are required around strings (as you stated)
• Deprecated flags give warnings
• Proper 'missing/too many parameters' errors
• Inventory/Weapon key flags are required from now on (i.e. +ALWAYSPICKUP must be +INVENTORY.ALWAYSPICKUP)
• No longer possible to set conversation ID, doomednum and spawnid directly -- must be done through MAPINFO

And:

Code: Select all

TNT1 A 0 A_Something

Is now

Code: Select all

TNT1 A 0 A_Something; //With Semicolon

At long last?

Also does this change possibly mean string user vars in zscript in the future? I'm not holding high hopes at all considering what randi tried for DECORATE but... that was DECORATE.

[FireSeraphim]

Will the option to continue using the current version of decorate and acs still be allowed? I'm kinda used to it and I'm not really looking forward to relearning what I already learned about decorate and acs so far.

[Major Cooke]

Naturally. And you wouldn't be relearning anything. Just changing a small bit of syntax change. The goal of zscript at this moment is to support all decorate functionality that it can muster.

However, DECORATE will no longer be developed for.

[Graf Zahl]

[*]Some warnings become errors (Which ones?)

All that should have been. The two biggest ones: Passing a non-existent class name to a spawn function and using a string in an integer context.

One other: No more spaces as parameter separator in the propeties, it must be a comma now.

And let's not forget the biggest addition to these parts: You can now use constants in properties and state parameters.

[Tapwave]

But be aware that ZScript is parsed before DECORATE so you will never be able to create classes in ZScript that inherit from DECORATE.

Purely out of curiosity, why this order? Is it to give priority to older decorate-based mods?

[Major Cooke]

You can now use constants in properties and state parameters.

So we can define constant strings in zscript now? (Also, state parameters?)

Code: Select all

const string Name1 = "The name of this string is Name1.";

[Graf Zahl]

Yes, you can. But it's just 'const Name1 = "...";'

[Graf Zahl]

But be aware that ZScript is parsed before DECORATE so you will never be able to create classes in ZScript that inherit from DECORATE.

Purely out of curiosity, why this order? Is it to give priority to older decorate-based mods?

It's because DECORATE needs access to the internal items that are now being transitioned.