[Zscript] Mod/File checking

[Major Cooke]

Nice!

Now, maybe I'm missing something here but... State parameters? What in particular is that? I can't tell if that's something to deal with goto labels and return state() functions or not.

[Graf Zahl]

That'd be the duration, the offsets and the light names.

[Major Cooke]

Code: Select all • Expand view

 // although it could be done, let's not convert colors back to strings.
    else
    {
        ScriptPosition.Message(MSG_ERROR, "Cannot convert to string");
        delete this;
        return NULL;
    }

This doesn't affect turning strings into colors, does it?

(Is it planned for strings to be in user variables someday?)

[Graf Zahl]

The concept of a user variable no longer exists in ZScript. It's an open extension of the internal classes which includes variable definition.
Of course there will be some means to handle redefinition of a base class's variable in a child class. This issue was the prime reason for requiring the 'user' prefix. Right now the parser aborts when it encounters a duplicate but this will have to be relaxed. when new variables get added to internal classes.

[Major Cooke]

Alright. I'm writing down all this information so I can host it up on the wiki ahead of time and keep it up to date. This way no one has to scour the forums for clues on how to convert DECORATE to Zscript once its merged.

What is the Default { } that I see going on in the converted actor properties like the PorkFX actor? I'm curious what it's use will be...

[Graf Zahl]

That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.

[Major Cooke]

Okay, here's all the information I've wrote down so far.
Since I'm still learning more about this, some information is probably incorrect; your edits would be appreciated.

That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.

Huh. I wonder if there's going to be anything else aside this and States.

Anyway, so strings don't have an identifier, but what about non/constant ints/floats, or would those just be the same thing?

Code: Select all • Expand view

const n1 = 1;
const n2 = 2.5;

The concept of a user variable no longer exists in ZScript. It's an open extension of the internal classes which includes variable definition.
Of course there will be some means to handle redefinition of a base class's variable in a child class. This issue was the prime reason for requiring the 'user' prefix. Right now the parser aborts when it encounters a duplicate but this will have to be relaxed. when new variables get added to internal classes.

How do you plan on having the user define the variables?

[Graf Zahl]

So far I haven't put much thought into this stuff, but I think it'd be a good idea to have a real versioning system, i.e. every new exported symbol gets tagged with a version number and the modder has to declare in their mod which version they intend to target. With ZDoom's tendency to add new features this may otherwise get out of hand fast if there's clashes with no safeguards.

[Major Cooke]

To supply your idea, perhaps a definable warning message modders can use to print in consoles on what could happen if using a version above/below, and possible what may happen when mixing mod X/Y/Z together with another that's not very compatible. That could couple nicely with my original suggestion.

[Gez]

That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.

Why is the block named "Default" instead of "Properties"? It doesn't really matter much obviously but "Properties" seems more appropriate.

[FishyClockwork]

So after having a quick look at this I have to ask: In the 'Default' block, is there a reason why apparently to only thing not requiring a semicolon is +FLAGNAME/-FLAGNAME ? Just curious.

[Graf Zahl]

Because many users tend to put multiple flags on one line and then the semicolons become a distraction. I can add that one is allowed after a flag name for consistency but I won't force it.

@Gez: Because that's what it had been named in ZDoom since forever. Randi just used the same name here. But since we are still in the initial stage, if there's consensus that it should be changed it can still be done.

[Major Cooke]

Because many users tend to put multiple flags on one line and then the semicolons become a distraction. I can add that one is allowed after a flag name for consistency but I won't force it.

Allowing it to ignore the semicolon basically? That works!

So then, I know you probably haven't thought about it as you stated earlier, but what plans do you have for loading conditions in control lumps? Because all I see right now in zscript.txt is just loading of the filenames (though obviously that's because there's no need for anything in them yet.)

[Ryan Cordell]

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

Why make defining the type optional though? Wouldn't it be better to actually avoid any ambiguity on that front?

[Major Cooke]

Correct me if I'm wrong, Graf: they probably resolve based on detection of "" or not. If no "" is detected, it can detect if it's an int or float based on a period being present or not.