ZScript Discussion

[Graf Zahl]

The slope setter should set a new plane equation for a sector, how this is derived should be up to the script programmer, as there's a vast possibility of how this can be done. You already have full access to the vertex and linedef data, so a lot should be doable, aside from making a controlled update to the sector. That part will require a native function. And for gradually altering slopes it will also require a slope interpolation object so that it gets smoothed for high FPS.

[Major Cooke]

Ah, is that the opengl renderer update function that needs the native function?

Because I have no idea what else I'm supposed to do to make those two functions...

[Nash]

So we can now detect savegame loading by transient variable suddenly becoming null :twisted:

I just used this feature - actually I don't even consider this hacky, I happened to run into a situation where I wanted an actor to run some functions every single time the level is re-entered and checking against a transient bool at the very start of their Tick() is perfect for my needs. Thanks for this feature, Graf!

[NeuralStunner]

You'll have to set that up in PostBeginPlay. Currently you cannot change the spawn health.

IOW I'd have to use a workaround. Personally, if I'm going to do that, I'd rather set default SpawnHealth absurdly high and manage the cap manually. (Probably via a local property and a quick check inside its think routine.) That way I can at least use HealThing et al.

A "fire and forget" method to modify its SpawnHealth would still be preferable.

[Nash]

Graf: I know you already explained why extending Actor is impossible at the moment but is there any plan to make this possible eventually... even if it's of low priority?

I'm already running into situations where the only sane way is to extend Actor. For example, to add functionality to every monster with minimal workarounds.

[Major Cooke]

@Neural: I have yet to hear from Graf himself if that even will become a thing, but I doubt it will happen since that could cause issues.

@Nash: "For the moment" being the key word. He never said it was out the door.

[ZzZombo]

You can use subclasses of PlayerPawn for monsters with dynamic health pool. Just never let players spawn as one such class.

[Agentbromsnor]

Tick() only gets called 35 times a second (it's one Tick per Tic ); from a quick look through Major Cooke's fixed version of TZK's camera stuff,my guess is that you can achieve smoothness by updating the spawned object's 'vel' (velocity) property to get it to move between tics. MC would be the best confirminator here; can't really play with it myself at present.

I have the same issue with my player class in ZScript; it looks jittery ever since I added a Y restriction using "override void Tick(void)".

Will this perhaps get changed later on in ZScript's development?

[Major Cooke]

However, I suggest you drag TheZombieKiller in here to post his even more recently revised one as that one takes care of some further issues which mine had.

Already available here

Right here, Agent.

[Nash]

To elaborate and with minimal example:

You have to apply the velocity of the positioner's (player) to the positionee (thing to attach to the player), PLUS some buffer velocity (offset) to compensate for the player's velocity; without the latter, the positionee will appear to "lag" or "move forward" in the positioner's direction (even though it will be smooth and won't jitter anymore).

I'll see if I can put together a minimal demo later when I have time.

[ZZYZX]

https://github.com/coelckers/gzdoom/pull/223 this regarding the discussion few pages ago on GL structures and actors not updating properly after a slope change. Posting here so I don't have to check github for Graf's comments
(edit: had to check anyway. zzz)

[Major Cooke]

Speaking of these changes... Perhaps it might be a good time to look into allowing overlays on actors other than player pawns? Nothing to deal with weapons per se -- if you look at Zombie's mod, that crosshair is an overlay with the player being the actual camera, a rather severe hack at that...

He can't open doors for example.

[Graf Zahl]

Bad timing for that.

[Graf Zahl]

Here's a number some may find interesting. After scriptifying much of the Inventory class, I added a scripted method of Inventory.tick, to see how much the VM would cost if called frequently.
I chose ZDCMP2 as a test map because it has roughly 1000 placed inventory items. The scripted Tick function didn't do anything except calling the super method.

This increased per-frame execution time by 0.15 milliseconds on my 3.4 GHz Core i7, adding 750 VM calls. What's also interesting is that running the VM isn't much of a problem, but function calls cost a lot of time. Well, at the moment this needs huge maps to cause an issue, for ZDCMP the increase was less than 3% of the entire time spent in the playsim, so it wasn't particularly troubling.
And if all else fails using aJIT compiler may always remain an option.

[Xaser]

Well, that doesn't suck at all.


A second stress test may be putting together a wad which Replaces all Doom monsters with ones which override Tick() and then load up a slaughtermap. I bring this up because I'm planning on doing exactly that for a thing. Welp.