HELP WANTED: ZScript

[Major Cooke]

D4D.pk3 has been updated. Eruanna, hope your build supports the new ResolveState functions needed.

This update in particular clears out all those truncation warnings and deprecated usage crap.

[Major Cooke]

New D4D.pk3 out for testing thinkers and virtual functions. While morphed via runes, keys can be picked up. That is, if they're of D4D's. Any addons that modify the keys and do not inherit from them (D4<Red/Green/Blue><Key/Skull>) or do not inherit from D4KeyBase cannot be picked up while morphed.

Also utilizes constant arrays.

The bulk of the changes are under ZD4D/Runes/MonsterBase.txt, while the rest of the rune files were cleaned and shortened quite a bit.

[Crudux Cruo]

So i'll simply say that, i like decorate. Not everything, but most things. i don't want to be forced to change a lot of code simply because. Don't fix it if it ain't broke, and don't break it if it doesn't need fixing. You guys wanna make a extra layer of scripting ON TOP of decorate? Sure. But don't force people to change thousands of lines for little tweaks and changes that could just as easily be interchangeable.

Perhaps i don't understand everything, but it seems like there's a significant number of things that probably don't need to change; things that perhaps could be interchangeable.

For instance:

---

"Actors are now known as classes which must inherit from Actor (or anything inheriting from Actor itself)."

"Actor names must be valid identifiers (i.e. be composed of only letters, numbers, and underscores; and must start with a letter or underscore). Most notably, this means that actor names may no longer begin with a number."

"Some warnings such as missing actors are treated as errors. All actors must be defined."

"All class names, colors, and strings now require enclosure by quotes (" ").

Species must be set to "None".
Empty Sounds and colors must use "".
Empty class actors, names and strings must use null."

"Damagetype definitions belong in MAPINFO."

This is all to say that i see some things that can change. I don't mind changing a few things, if there is a reason, but i don't want to have to do more work than i should. I sincerely hope the direction of this project is heading towards a greater mind for compatibility.

I'm going to keep my eye on this despite all that being said. I might even try to use it. Just thought i would throw in my 2 cents before its too late. I would only be interested if decorate and z-script could be used side-by-side. It's worth noting, i have downloaded D4D, and looked into the updated zscript definitions, and it looks radically different in places that probably don't need to change.

[Rachael]

This is all to say that i see some things that can change. I don't mind changing a few things, if there is a reason, but i don't want to have to do more work than i should. I sincerely hope the direction of this project is heading towards a greater mind for compatibility.

I'm going to keep my eye on this despite all that being said. I might even try to use it. Just thought i would throw in my 2 cents before its too late. I would only be interested if decorate and z-script could be used side-by-side. It's worth noting, i have downloaded D4D, and looked into the updated zscript definitions, and it looks radically different in places that probably don't need to change.

I don't know where you got the idea that ZScript and DECORATE were not going to be compatible.

If you know Graf even slightly, you know he at least tries to maintain a level of compatibility with the latest release versions of ZDoom / GZDoom.

Suffice to say, breaking compatibility with hundreds of released mods from over 17 years, not to mention a few very prominent ones ... is insane. And has been repeatedly stated as such before.

[Nash]

You are not forced to use ZScript. DECORATE still works. They are 2 completely different lumps.

DECORATE will continue to work, it just won't be expanded/have new features added anymore. Kinda like old DECORATE (the ooold one Randi made whose purpose was to define custom decorative actors, who remember??? XD) vs new DECORATE (96x for those who were here long enough).

Old DECORATE continues to work in ZDoom... just that no one's using it anymore and of course, no new features were added. The new features that you have been using in 96x DECORATE are so complicated that it will never work with the syntax of the old DECORATE. So instead of trying to shoehorn the ability to make more complicated actors into old DECORATE, Graf simply made DECORATE 96x.

Same analogy here. There's no point in expanding DECORATE any farther because of years of questionable/poor design decisions. So make a new lump: ZScript.

Why ZScript is made the way it is? Simple. Because it's more powerful. Here's an example of a DECORATE vs ZScript:

Code: Select all

// DECORATE version.
// 3 states, 2 of which are really duplicates
// This is commonly known as "Spaghetti DECORATE"
Actor NashGore_FlyingBlood : NashGore_BloodBase
{
    States
    {
        Spawn:
        FlyingNormal:
            TNT1 A 2 A_SpawnItem("NashGore_FlyingBloodTrail", 0, 0, 0, 1)
            TNT1 A 0 A_Jump(12, "RandomlyDestroy")
            TNT1 A 0 A_Jump(27, "FlyingDecel")
            Loop
        FlyingDecel:
            TNT1 A 2 A_SpawnItem("NashGore_FlyingBloodTrail", 0, 0, 0, 1)
            TNT1 A 0 A_ChangeVelocity(velx * 0.8, vely * 0.8, velz, CVF_REPLACE)
            Loop
        RandomlyDestroy:
            TNT1 A 0
            Stop

// ZScript version.
// 1 state, all of the logic needed covered in 1 go!
// Drastically clear and logical programming is seen here
class NashGore_FlyingBlood : NashGore_BloodBase
{
    bool isDecelerating;

    States
    {
    Spawn:
        TNTT A 2 NoDelay
        {
            A_SpawnItem("NashGore_FlyingBloodTrail", transfer_translation: true);

            if (random() < 27) isDecelerating = true;

            if (isDecelerating)
            {
                A_ChangeVelocity(vel.x * 0.8, vel.y * 0.8, vel.z, CVF_REPLACE);
            }

            // no chance to randomly destroy if it's decelerating
            if (random() < 12 && !isDecelerating)
            {
                return ResolveState("Null");
            }

            return ResolveState(null);
        }
        Loop;
 

Conclusion:

You are not forced to use ZScript. DECORATE will continue to work. If you find that one day you'll need to make complicated monsters or weapons however... you will find DECORATE frustrating. Unless you enjoy Spaghetti DECORATE'ing.

[arookas]

Building upon Nash's points:

"Actors are now known as classes which must inherit from Actor (or anything inheriting from Actor itself)."

This is because not all classes need to inherit from actor. All actors are classes, but not all classes are actors. You can (or will be able to) define other types of classes lower than actor, such as thinkers.

"Actor names must be valid identifiers (i.e. be composed of only letters, numbers, and underscores; and must start with a letter or underscore). Most notably, this means that actor names may no longer begin with a number."

This is pretty standard everywhere else. Since zscript uses an actual grammar rather than an ad hoc parser, tokens need to be validated so as to not create parsing conflicts. A name needs to begin with a letter so as to not be able to be confused with a number (for instance, you couldn't name your class "0xFADEBABE", since that is a valid hexadecimal literal).

"Some warnings such as missing actors are treated as errors. All actors must be defined."

If an actor is attempted to be spawned or inherited from, of course that actor needs to be defined. This also helps find typos because the game halts, letting you see the missing class instead of silently passing it by and starting the game anyway.

"All class names, colors, and strings now require enclosure by quotes (" ").

Species must be set to "None".
Empty Sounds and colors must use "".
Empty class actors, names and strings must use null."

Again, because zscript uses an actual grammar, literals of different types have to be differentiated from each other. Names use single quotes so as to differentiate from strings, which use double quotes. The rest of the points simply show that zscript is enforcing certain values to represent "none" or "nothing" for each type, which is great.

"Damagetype definitions belong in MAPINFO."

It has been stated that damage types definitions are too minor for their own lump, but don't fit in an actor/class definition lump either. MAPINFO seemed like the next best fit.

[Kinsie]

Conclusion:

You are not forced to use ZScript. DECORATE will continue to work. If you find that one day you'll need to make complicated monsters or weapons however... you will find DECORATE frustrating. Unless you enjoy Spaghetti DECORATE'ing.

Translation:

If you are new to modding, trying to learn DECORATE, and ask for help... you will no longer receive it. Unless you find condescending "WHY AREN'T YOU USING THE NEW THING ONLY WE KNOW HOW TO USE" replies useful and encouraging.

[Major Cooke]

Graf's going to make documentation after it's ready, Kinsie. Also I see what you did there with your avatar.

[Graf Zahl]

I can't do the documentation alone, it's way too much. I think a better plan is that a few people volunteer with me guiding the whole thing. Fortunately all the existing DECORATE docs are still relevant.
What I can say is, if you feel comfortable writing the docs, the exported functions in class Actor are good to go. I don't expect anything to change there, but if it does it should be minor and not render existing docs worthless.

@Kinsie: Stop acting like an idiot. Aside from a few syntactic differences ZScript is a functional superset of DECORATE, with a few questionable design decisions removed. None of those are showstoppers, but the ultimate outcome will be the same as with MAPINFO or UDMF. The old formats will continue to be used, some people refusing to go along and eventually being left behind in the dust because everybody has moved on and not being to help them with their outdated format that cannot express the things they want to do. It makes very little sense actively maintaining two features that are functionally identical with one suffering from structural problems preventing it from moving forward. As people gradually learn how to use the power of actual scripting, DECORATE will inevitably fade into legacy support, just like Hexen-style MAPINFO and Hexen-format maps did.

[Major Cooke]

I'll volunteer. Perhaps there's a way to mass create all the pages and set them up with a special formatting automatically, with the following:

• Page Name
• Function
• Description
• Parameters
• Example(s)

But I kinda need to know what all was added, as some of the functions were sorta just chucked in there and I'm not certain which is ZScript and which isn't. I can get started on mass creating all those pages once I'm certain of which is zscript and what's not. Then, perhaps a brief description on what some of the more obscure stuff does in a gneeral sense, and I can work on taking care of the rest.

(I.e. CheckClass is actually a Decorate compatible function by the way, I think you meant to label GetClass instead?)

One other thing, I don't know if I can tag them all like {{git|}} and such. That will probably have to wait until you merge ZScript into master.

Gez, if you come around this thread at all, we should also probably start thinking about how we're going to organize it. I suppose I can just make a big list on a single page, sorted alphabetically for now until someone comes up with something, containing links to each.

[Xaser]

Git tagging on the wiki ought to work just fine; a commit is a commit no matter which branch it's in.

[I'd try it myself but I'm presently unable to log in or reset my password on the wiki for some reason. ]

[SanyaWaffles]

I would be willing to document what functions do and the like. One thing I am good at is coming up with examples too.

I will be diving into converting my in-progress standalone TC as a guinea pig, but more so I can aid in documentation (and looking at my code, it could reap from the benefits of ZScript, mainly with the goddamn jump statements. They are so confusing, even with DECORATE's anonymous functions.

[Gez]

passive-aggressive whining

Kins, please. You're smarter than that.

[Graf Zahl]

(I.e. CheckClass is actually a Decorate compatible function by the way, I think you meant to label GetClass instead?)

To be precise, ANY function that doesn't use an object or other pointer is DECORATE compatible.

[Crudux Cruo]

as long as nothing done will break, i'm happy. It'll be yet another thing i have to learn. I loved how simple yet effective DDF code is/was, and some of the coolest mods came out for edge, perhaps this new zscript will be a renaissance for gzdoom. for the record, i've used gzdoom for 8 years straight, so i can see the need to jazz things up a bit. I'll keep my eyes on this, who knows, maybe lethaldoom will get a conversion one day.