ZDoom

Dear members, dear developers,

in the past weeks I am following the development of ZSCript and I am utterly impressed by the possibilites it has. Nash has already done a few crazy things for example to mention one of them. Though, Nash is also one of the few people around here who are very used to programming, who understand the language and who are able to create soemthing with ZSript.

This is the point where I get nervous.

DECORATE is a very intuitive and easy format to work with, I am used to it and I can come up with things even though I am not a programmer. Though when I take a look at some of the ZScript actors in the ZScript thread, I simply don't understand anything.

So, is DECORATE now slowly disappearing from the developers' radar and is replaced entirely by ZScript or will both be developed parallely in the future so people with little programming skills can continue using new functions and other people can go crazy with ZScript?

ZScript is based from Unreal Script which is a powerfull language for programming in Unreal Engines 1 to 3 in UE4 it was replaced by Blueprint scripting which is still Unreal Script but in a sort of node linking visual to be more intuitive for non-programmers.

Anyway, in ZDoom the thing is, many people are accostumated alot with DECORATE, but ZScript don't simply dumps everything that DECORATE has established, converting decorate actors to zscript is pretty easy because the syntax of decorate is the base syntax of zscript with only the change of actors now becoming classes so the engine can treat that as source code.

Personally all this fear many modders are having with ZScript now is the same thing that happened to UDMF years ago, people though it would be a total changer of how map would be made, but in the end, it is just Hexen format with even more powerfull abilities, so, the same happens to ZScript, you can make an actor exactly as in decorate PLUS giving the option to access many internal features of the engine which decorate was not able to do.

That parts where you say you don't understand is exactly the part where ZScript is accessing the internal code of the engine to make a better control of how that actor will behave in such mod.

Think of ZScript as "DECORATE on steroids" - only, instead of strictly defining actors, it defines a lot of parts of the engine, itself.

I wouldn't stop using DECORATE, personally, despite its announced deprecation. There's a lot of really neat things you can do with ZScript, sure, but with libraries like HOERS those will start to become easier over time, not to mention more accessible.

I didn't really do much, mostly just silly test actor classes as means to learn the language. But that's flattering, thanks. XD

But yeah, don't worry... DECORATE will still work, and although the devs won't extend DECORATE anymore, hopefully HOERS will allow DECORATErs to import custom ZScript-written functions and enjoy some expanded functionality.

Of course if you want to do really, really complicated, engine-tier stuff (mostly relevant for TC makers who want to stray as far from stock Doom mechanics as possible, or people who want to make ultra-complicated mods), then there's no avoiding working directly in ZScript. With so much power, the learning curve will obviously be very high, just like anything in the real world I'm afraid...

Tormentor667 wrote:So, is DECORATE now slowly disappearing from the developers' radar and is replaced entirely by ZScript or will both be developed parallely in the future so people with little programming skills can continue using new functions and other people can go crazy with ZScript?

I don't think DECORATE will receive any new major features, but it's not just going to be thrown away. Too many mods rely on it. DECORATE is parsed after ZScript, so you can create DECORATE actors that inherit from ZScript ones and get the best of both worlds.

Zanieon wrote:Personally all this fear many modders are having with ZScript now is the same thing that happened to UDMF years ago, people though it would be a total changer of how map would be made, but in the end, it is just Hexen format with even more powerfull abilities, so, the same happens to ZScript, you can make an actor exactly as in decorate PLUS giving the option to access many internal features of the engine which decorate was not able to do.

To be fair, ZScript is a lot closer to real, big-boy programming than anything else in the engine, and a lot of the code examples in the ZScript thread focus on complicated stuff, so I can understand how people can be scared off as a result.

Nothing's been lost, and some fun new toys are being gained. It's worth having a twiddle with, if nothing else.

Why should DECORATE go away? Aside from the parser frontend it uses all the same code than ZScript - the property handlers are the exact same code, the state builder is the exact same code and the compiler backend is the exact same code. And new features are not done by extending the parser but by extending the backends, so DECORATE will inherit a lot of what ZScript will get. Of course, for defining new content, it still makes sense to use ZScript because then, if you have to add some code, you just can. But nobody is forcing you to do so.

See the introduction to the [wiki]Converting DECORATE code to ZScript[/wiki] article. You can get away with keeping DECORATE if you're worried of having to learn too much, and only use ZScript for when you need to do something that is impossible or tedious to do in DECORATE.

My single fear of ZScript is that we will never get the thingdeltas I've been hoping would one day allow me to remove bullet point 5 from [wiki=Template:Actor]this[/wiki].

Gez wrote: My single fear of ZScript is that we will never get the thingdeltas I've been hoping would one day allow me to remove bullet point 5 from [wiki=Template:Actor]this[/wiki].

The sheer horror of that idea is enough to nix it from the go. Once a class is defined, it is defined. End of story.

That's really disappointing. I've posted a good example of use case before, were the ability to update two classes is the alternative to having to replace 24 classes and the status bar; and again internally the engine can handle it since it can handle dehacked patches. But there's no dehacked entries for Heretic, Hexen, and Strife.

What you forget to mention is the risk of hard to track errors that may occur when the assumption that actor defaults are immutable after creation is removed. Dehacked only modifies a very small subset of data. The only info that truly may warrant post-compile modification is ammo settings, and those are better dealt with in another place where it can be better controlled than allowing blanket redefinition of actor properties.

From my experience with the thing, there's not much difference between a basic monster written in DECORATE and the same monster rewritten in ZScript, aside from a few more semicolons and curly braces. Not until you get into the weird science things that are all up in the ZScript threads, at least.

I just want to echo Torms feelings on this too, I feel the same way myself.

I plan to update my project to ZScript, I just have to learn how now

I think instead of thingdeltas we can use Add/Give/Take/Check inventory along with this funny pattern to attach both custom fields and methods to any actor.
From what I remember, inventory items do receive Tick(), so it's possible to do background processing in such a module as well.
Finally directly subclassing Inventory is useful.

ALSO: maybe it can be possible to not use inventory, but have a separate list for "component" objects with slightly different behavior (e.g. so you can forward DamageMobj to them and allow every component to process it before actually feeding it to the actual actor). But that's something definitely not for right now so just use inventory

I want something to update default properties of standard actors.

If I have to create a script that will spawn an item that will iterate through every mobj and color their blood blue if they are cacodemons, then so be it. I'm not sure how it's better than a thingdelta, but whatever works.

That can be done with EventHandlers using ThingSpawned method.
Note: EventHandlers are still broken by now.