ZScript Discussion

[Rachael]

That's the weird thing here. Right now I am still collecting features, there is absolutely no guarantee that something I don't like won't get refactored eventually. It may easily happen that some functions will go away ultimately, should I decide that their presence will hurt the thing overall.

Which is part of why I put disclaimer notices to that effect very prominently in the announcements as well as the actual download page for GZZScript.

I've noticed the effect of that has made some people afraid to even try it out, even stating that they are afraid converting their mod would be a waste of time because the language would change anyway (even though I did suggest resulting progressive changes would be smaller in comparison to the conversion, itself).

At this point, I think the best thing for ZScript is if you guided the testing. Like made announcements to the effect of "this group of functions" or "this type of syntax" needs tested. Or it may be too early for that right now, but I think something like that does help, if you are able to.

[Graf Zahl]

I cannot guide the testing and do the programming at the same time. Ideally, Randi should be up here, guiding development, but I think that's a futile hope.
One thing I learned on my job is that it will never work if the programmer of some complex thing also needs to act as producer. A producer needs to have an unbiased outside view on actual development or they'll never catch if something goes wrong.
I have done both - programming and producing, but the projects where I had to do both at the same time were always the ones where something went bad, for the sole reason that nobody was able to give proper technical feedback.

To be honest, what worries me most about the compiler is that nobody with a good grasp on how to stress test such a thing and deliberately look for logical errors is present here.

[Edward-san]

I think a testing framework could help here...


[edit] I tested square1.pk3 again after the latest changes and got these warnings:

Code: Select all

Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 27:
Truncation of floating point constant -0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 27:
Truncation of floating point constant 0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 27:
Truncation of floating point constant -0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 27:
Truncation of floating point constant 0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 58:
Truncation of floating point constant -0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 58:
Truncation of floating point constant 0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 58:
Truncation of floating point constant -0.500000
Script warning, "square1.pk3:actors/square/base/enemies/anglefish.txt" line 58:
Truncation of floating point constant 0.500000
Script warning, "square1.pk3:actors/square/base/scenery/weather.txt" line 175:
Truncation of floating point constant -0.500000
Script warning, "square1.pk3:actors/square/base/scenery/weather.txt" line 175:
Truncation of floating point constant 0.500000
Script warning, "square1.pk3:actors/square/base/scenery/weather.txt" line 175:
Truncation of floating point constant -0.500000
Script warning, "square1.pk3:actors/square/base/scenery/weather.txt" line 175:
Truncation of floating point constant 0.500000

Are these warnings valid?

[Graf Zahl]

This means that at some point it tries to cast a float constant to an integer which always loses some significant part of the value.

Code: Select all

random[SquareEffectRandom](-0.5, 0.5)

And that definitely does not work. Yes, it's an error in the mod that until now wasn't reported.
These need to use frandom, not random.

[Major Cooke]

Which is part of why I put disclaimer notices to that effect very prominently in the announcements as well as the actual download page for GZZScript.

I've noticed the effect of that has made some people afraid to even try it out, even stating that they are afraid converting their mod would be a waste of time because the language would change anyway (even though I did suggest resulting progressive changes would be smaller in comparison to the conversion, itself).

At this point, I think the best thing for ZScript is if you guided the testing. Like made announcements to the effect of "this group of functions" or "this type of syntax" needs tested. Or it may be too early for that right now, but I think something like that does help, if you are able to.

It sucks that people are afraid to try, really. It'd be for the sake of forwarding progress.

But I can think of a few legitimate reasons why:

• If something is broken after a straight up convert, it begs the question: Modder's fault, or zdoom's?
• Mod size is definitely a factor, such as AEons of Death. I sure as hell won't convert that until ZScript is merged, save for a few things that could desperately use the overhaul as-is.
• Internals are ever changing and chaotic at the moment, and syntax is changing.
• Lack of proper documentation makes it painful to even start from scratch, it seems.
• Some features aren't yet available..
• Probably some others that I haven't thought of yet.

Though on that note, yes, converting D4D was a pain in the ass. Took about 3-5 days? I think? That was strictly porting it over, not starting the use of the new functionality. Now I am using whatever I can to eliminate many a bad hack, and now I can't get enough of ZScript. I never want to go back to DECORATE again if I can avoid it.

Some of the planned ideas have to wait until local arrays are available though.

I cannot guide the testing and do the programming at the same time. Ideally, Randi should be up here, guiding development, but I think that's a futile hope.
One thing I learned on my job is that it will never work if the programmer of some complex thing also needs to act as producer. A producer needs to have an unbiased outside view on actual development or they'll never catch if something goes wrong.
I have done both - programming and producing, but the projects where I had to do both at the same time were always the ones where something went bad, for the sole reason that nobody was able to give proper technical feedback.

To be honest, what worries me most about the compiler is that nobody with a good grasp on how to stress test such a thing and deliberately look for logical errors is present here.

Sounds like randi just gave you the reigns and said 'have fun'.

Also this brings up an old curiosity -- What is the point of the VM? I know it plays a big part in all this, and that it is likely to be the only thing which allows zscript to exist, but still...

[XxMiltenXx]

Hey, I have a question about SetStateLabel. If I use it inside an actor that inherits from "Weapon", it crashes immediately when he tries it. Is this a bug or does it simply not work for weapons or is there anything special I have to write?

EDIT: I tried it as a seperate function and as an Anonymous function and simply like "TNT1 A 0 SetStateLabel("Example");. All the same result

[Graf Zahl]

Also this brings up an old curiosity -- What is the point of the VM? I know it plays a big part in all this, and that it is likely to be the only thing which allows zscript to exist, but still...

The VM is the part that runs the actual compiled bytecode generated from the scripts, so yes, it's the most essential part of all.

[Rachael]

Sounds like randi just gave you the reigns and said 'have fun'.

More like "Oh hey Graf here's something cool I made" and then Graf ends up spending months fixing it.

Look - I love Randi to death for what she's done but that kind of absenteeism is frustrating, to say the very least.

[Major Cooke]

More like "Oh hey Graf here's something cool I made" and then Graf ends up spending months fixing it.

He was just given some sample code if I recall correctly. I don't think it was much, probably what the ZScript code/syntax would look like? Dunno.

Randi did comment on a few things here and there, but the attention to this hasn't been persistent -- or so it would seem. Meh, life gets in the way perhaps?

----------

Also I'm a little surprised at all the feature creep that's been going on. Not that I'm complaining!

[Graf Zahl]

Precisely that. Just a small sample of extremely contrived test code which I needed to get an understanding on how the parser and the frontend work. What's really sad is, had I had that piece of code 5 years ago, we wouldn't be here right now, the thing would be done.

Interestingly, it looks like the grammar was never fed with actual production code before I started implementing the compiler backend - which is why I had to made quite a bit of changes to the grammar and the VM instruction set as well because they were simply missing some parts.

[Major Cooke]

...randi had it for that long?

[Rachael]

I think what Graf might be saying is if he had that sample (even with no parser or backend) he would've done the work himself. From what I've read in Graf's previous posts, most of the framework was already there, just limited by the parser.

[Major Cooke]

Actually I was asking about the sample code. Graf seemed to be implying that was the case.

[D2JK]

Is it currently possible to make some of the custom function arguments optional? If yes, how do I do that?

[AFADoomer]

It sucks that people are afraid to try, really. It'd be for the sake of forwarding progress.

But I can think of a few legitimate reasons why:

• If something is broken after a straight up convert, it begs the question: Modder's fault, or zdoom's?
• Mod size is definitely a factor, such as AEons of Death. I sure as hell won't convert that until ZScript is merged, save for a few things that could desperately use the overhaul as-is.
• Internals are ever changing and chaotic at the moment, and syntax is changing.
• Lack of proper documentation makes it painful to even start from scratch, it seems.
• Some features aren't yet available..
• Probably some others that I haven't thought of yet.

My main issue is that while I'm converting my current work (Star Trek mod) to ZScript, I can't do further mapping (without loading up Decorate shims for GZDoomBuilder's sake). I've converted most of my actors over (a relatively straightforward process), but now have to revert to an older version while mapping. I could convert something with stable maps, like the Wolfenstein 3D TC, but I'd rather leave that as 'complete' (considering that I started work on it nearly 14 years ago!).

The lack of documentation just means that I don't know what all I *can* do directly - most of what I'm doing is direct conversion from Decorate, so probably has some Decorate-ism crutches that aren't necessary anymore.