More actor functions should be data scoped?

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

User avatar
Sir Robin
Posts: 537
Joined: Wed Dec 22, 2021 7:02 pm
Graphics Processor: Intel (Modern GZDoom)
Location: Medellin, Colombia

More actor functions should be data scoped?

Post by 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?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49182
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: More actor functions should be data scoped?

Post by 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.
User avatar
Marisa the Magician
Posts: 3886
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Operating System Version (Optional): (btw I use) Arch
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

Re: More actor functions should be data scoped?

Post by Marisa the Magician »

I would definitely like GetGibHealth to be clearscoped, mostly to get rid of some hacks in LineTracer classes.
User avatar
Sir Robin
Posts: 537
Joined: Wed Dec 22, 2021 7:02 pm
Graphics Processor: Intel (Modern GZDoom)
Location: Medellin, Colombia

Re: More actor functions should be data scoped?

Post by 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
Marisa Kirisame wrote: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.
User avatar
AFADoomer
Posts: 1337
Joined: Tue Jul 15, 2003 4:18 pm

Re: More actor functions should be data scoped?

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49182
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: More actor functions should be data scoped?

Post by Graf Zahl »

The line tracer should be play scope. Please don't tell me it isn't. :?
User avatar
Marisa the Magician
Posts: 3886
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Operating System Version (Optional): (btw I use) Arch
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

Re: More actor functions should be data scoped?

Post by Marisa the Magician »

it's entirely data scope.
User avatar
phantombeta
Posts: 2119
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: More actor functions should be data scoped?

Post by phantombeta »

Graf Zahl wrote: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.
User avatar
Marisa the Magician
Posts: 3886
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Operating System Version (Optional): (btw I use) Arch
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

Re: More actor functions should be data scoped?

Post by Marisa the Magician »

I don't think I've ever needed to use a LineTracer from ui scope, though.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49182
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: More actor functions should be data scoped?

Post by 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.
User avatar
Marisa the Magician
Posts: 3886
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Operating System Version (Optional): (btw I use) Arch
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

Re: More actor functions should be data scoped?

Post by 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).
User avatar
JPL
 
 
Posts: 523
Joined: Mon Apr 09, 2012 12:27 pm

Re: More actor functions should be data scoped?

Post by 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?
User avatar
Major Cooke
Posts: 8196
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: More actor functions should be data scoped?

Post by Major Cooke »

Graf Zahl wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49182
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: More actor functions should be data scoped?

Post by 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.
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: More actor functions should be data scoped?

Post by 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. :mrgreen:

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

Return to “Feature Suggestions [GZDoom]”