More actor functions should be data scoped?
Moderator: GZDoom Developers
-
- 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?
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?
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: More actor functions should be data scoped?
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.
-
- 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?
I would definitely like GetGibHealth to be clearscoped, mostly to get rid of some hacks in LineTracer classes.
-
- 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?
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
The other ones I was thinking of were the GetUDMF* from line and sector structs
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.Marisa Kirisame wrote:I would definitely like GetGibHealth to be clearscoped, mostly to get rid of some hacks in LineTracer classes.
-
- Posts: 1337
- Joined: Tue Jul 15, 2003 4:18 pm
Re: More actor functions should be data scoped?
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: More actor functions should be data scoped?
The line tracer should be play scope. Please don't tell me it isn't.
-
- 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?
it's entirely data scope.
-
- 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?
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.Graf Zahl wrote:The line tracer should be play scope. Please don't tell me it isn't. :?
-
- 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?
I don't think I've ever needed to use a LineTracer from ui scope, though.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: More actor functions should be data scoped?
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.
Yes, I know, the engine is not C/S but it's things like this that make it so hard.
-
- 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?
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).
-
-
- Posts: 523
- Joined: Mon Apr 09, 2012 12:27 pm
Re: More actor functions should be data scoped?
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?
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?
-
- 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?
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 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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: More actor functions should be data scoped?
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.
But since it's too late for that we'll be stuck with the current network system and never see Zandronum update.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: More actor functions should be data scoped?
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
Can't have your cake and eat it too especially where major progress is concerned