More actor functions should be data scoped?

[Sir Robin]

In the actor class, some functions are clearscoped, such as isFrozen, SpawnHealth, GetMaxHealth, etc, but lots of functions like CanTouchItem, CanCollideWith, CanResurrect, GetBloodType, GetGibHealth, etc are left in play scope. I would think that any get* or can* or is* functions that just read data and return a value should be data scoped. Is there a reason they're left in play scope?

[Graf Zahl]

Some require a play-side parameter or access play-side data and others have little use in UI code. Of the ones you listed the only one that might make sense to change is GetGibHealth.

[Marisa the Magician]

I would definitely like GetGibHealth to be clearscoped, mostly to get rid of some hacks in LineTracer classes.

[Sir Robin]

I'm writing a feature on the UI to tell the player about the object in front of them. The alternate is to have a function that calls these from play scope and stores the results somewhere accessible from UI. I was just curious why they weren't already accessible there, if there was a reason or just an oversight.

The other ones I was thinking of were the GetUDMF* from line and sector structs

I would definitely like GetGibHealth to be clearscoped, mostly to get rid of some hacks in LineTracer classes.

If you know about the Line Tracer class can you take a look at this? A line trace will pass through a 3d floor if it touches a poly object first.

[AFADoomer]

The same could be said for most "Get*" Side/Line/Sector functions...

I would love to be able to use these to (for example) properly retrieve a Side texture Y offset from inside of a LineTracer callback in order to check if the tracer actually hit the texture of a non-wrapped midtex.

[Graf Zahl]

The line tracer should be play scope. Please don't tell me it isn't.

[Marisa the Magician]

it's entirely data scope.

[phantombeta]

The line tracer should be play scope. Please don't tell me it isn't. :?

Why should it be play scope? That'd severely limit its usability, and as far as I know, LineTracer (due to requiring you to implement the whole trace callback manually) entirely bypasses the stuff in the default line-tracing code that causes external changes.

[Marisa the Magician]

I don't think I've ever needed to use a LineTracer from ui scope, though.

[Graf Zahl]

The thing here is, the line tracer is fundamentally a play feature. With Play/UI we need to think in client/server terms. Play features run on the server and UI features run on the client. Running a line tracer would require a complete round trip from client to server to client to produce some results. Any such feature really should have no business whatsoever on the UI side if it was done properly.

Yes, I know, the engine is not C/S but it's things like this that make it so hard.

[Marisa the Magician]

I'd figure if it's made play scope, we can re-enable the flags for activating line cross specials with it, then (currently have to re-implement this in the callback itself by filling in an array of activatable lines for the user code to manually trigger).

[JPL]

The main argument I can think of for making Trace available from UI scope is if you're doing the equivalent of client side only checks that are explicitly assumed to be unreliable, eg Quake 3's "ground trace" that runs on both server and client to do things like its client side prediction. https://github.com/id-Software/Quake-II ... ch?q=trace
That's obviously getting ahead of things a bit in GZDoom because it's not fully C/S but separating the concepts in anticipation of it being seems prudent.
Edit: but it would probably need to be a special version of Trace that disallows side effects?

[Major Cooke]

The thing here is, the line tracer is fundamentally a play feature. With Play/UI we need to think in client/server terms. Play features run on the server and UI features run on the client. Running a line tracer would require a complete round trip from client to server to client to produce some results. Any such feature really should have no business whatsoever on the UI side if it was done properly.

Yes, I know, the engine is not C/S but it's things like this that make it so hard.

Mods like TargetSpy would not be doable if the ability to perform such functions outside of play scope was taken away. These rely on getting the player's target for example and displaying the names of the target, health bar, etc.

[Graf Zahl]

I know. But it''s these mods which make it virtually impossible to do a better multiplayer implementation. In a well designed environment they'd work by sending a request to the server and only print their information when the server sends the requested data back.

But since it's too late for that we'll be stuck with the current network system and never see Zandronum update.

[Nash]

Easy, just deprecate the old mods (they will never support the Zandronum update), modders who want to make their mods work with the Zandronum update will just have to update their works to the better-designed network API.

Can't have your cake and eat it too especially where major progress is concerned