ZScript Discussion

[DenisBelmondo]

EDIT: moving to other topic.

[Matt]

The how-to thread is over here

[DenisBelmondo]

Oh my bad, I'll move the question over there. Thanks!

[ZZYZX]

Just curious, is there going to be any line drawing under Screen? If so, when approximately?

[Graf Zahl]

The functions exist, they just have the small problem that the software versions do not clip the output so they are not suitable for user code.

[Nash]

The line drawer IMO, should eventually be extended to allow a line thickness parameter... lines are almost invisible to me at 4k resolution.

/////////


Question about: https://mantis.zdoom.org/view.php?id=456

The Defaults make sense for actors which have to be spawned with a generic function, but for other classes the proper way should be a constructor.

Constructors sound like exactly what I was looking for. How do I do those or are they possible yet?

[Graf Zahl]

Constructors are not in yet.

And to be honest I need to take a break from more complex ZScript for now.

[Nash]

No problem! The amount of work you did in 2017 alone is more than, like, oh I don't know, the past 2 years of progress combined or something.

I will remind you about the constructor idea some other time. It's not urgent for me, and I have lots of other features to play with currently (not to mention learning how to actually script properly and generally improving my ZScript-fu)

[Caligari87]

So before I go crying wolf on a bug report, need to have someone else test this. It seems that overriding PostBeginPlay in Doomplayer disables look up/down.

File should be downloadable from this link. All it is, is a MAPINFO and ZScript that ZZYZX gave me to test new player classes.
https://cdn.discordapp.com/attachments/ ... sclass.pk3

MAPINFO:

Code: Select all • Expand view

gameinfo
{
   PlayerClasses = "TestZSClass"
}

ZSCRIPT

Code: Select all • Expand view

class TestZSClass : DoomPlayer
{
   override void PostBeginPlay()
   {
      Console.Printf("HI");
   }
}

[Graf Zahl]

You *MUST* call the super method!
PlayerPawn.PostBeginPlay performs some necessary setup without which you end up with an incompletely set up player.

[Caligari87]

Yeah, just found that out. Wasn't aware it did other stuff. Whoops.

[Major Cooke]

Was this possibly related to the overhead cost of calling subfunctions?

[Graf Zahl]

More like overhead cost of pointers in general. This stuff was meant to be used to check pointer types but practical constraints basically limited it to checking if a pointer was supposed to be an object, and even that wasn't safe.

The problem with function calls is that the code is extremely generic and has to account for a lot of things. I don't really think that this can be streamlined much more without sacrificing functionality.

There's one thing in the VM which I also may scrap - and that is scripted exceptions. It's a typical pie-in-the-sky proposition but will probably totally go over the head of most scripters and offer very limited functionality, but also comes with quite a bit of overhead. On the language side this hasn't even been implemented yet and I have no plans to do so.

You have to consider that the only things ZDoom is using execptions for is to abort on errors and for FraggleScript to terminate scripts (but only because this was so badly implemented that it couldn't have been done in a saner fashion.)

[Major Cooke]

Fair enough. I figured it wouldn't do much of a benefit towards subfunctions, just thought I'd check.

It does seem like this provided a minor speed boost in more 'sticky' situations with lots of ZScript heavy actors performing their stuff, so that's nice!

[Major Cooke]

Out of curiosity, on the topic of subfunctions...

Does that just apply to whenever calling it from within a function like Tick(), or does that also include in anonymous functions?

I.e.

Code: Select all • Expand view

TNT1 A 0 MyFunction();
TNT1 A 0 { MyFunction(); }

Does this also weigh upon the system more heavily than just executing the regular code?