ZDoom

I don't see how even in a proper client-server arch. line trace must be only a server-side feature. As long as the client has already the relevant knowledge of the intercepted objects it should be possible for it to return the results w/o consulting the server.

To be fair (and clear, so that I don't get misinterpreted), I'm not knocking on mods - I mean at the end of the day, given [i]current[/i] features as of today, there's not really any other way to do certain things. As an example, Major Cooke linked to TargetSpy in the other post - which is a very well-coded mod and m8f certainly knows what he's doing. It's certainly not his fault that all he has at his disposal when his mod was made, is the current Actor.LineTrace or the LineTracer class.

But that also means that if GZDoom gets C/S, I think it's a realistic expectation that some mods won't "just work" out the box.

[quote="Nash"]Can't have your cake and eat it too especially where major progress is concerned[/quote]

This so much. It's incredibly frustrating to constantly be held back because one mod out of a thousand did something wrong in terms of engine progress.

As long as it's made clear on deprecation and how we can transition this stuff, I'd be fine with that.

(But to be fair, since the [url=https://forum.zdoom.org/viewtopic.php?f=15&t=73071#p1197644]spread rune is an absolute no-go[/url], we'll never get there 100% of the way anyway.)

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

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.

[quote="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.[/quote]

Mods like [url=https://forum.zdoom.org/viewtopic.php?t=60784]TargetSpy[/url] 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.

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-III-Arena/search?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?

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).

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.

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

[quote="Graf Zahl"]The line tracer should be play scope. Please don't tell me it isn't. :?[/quote]
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.

it's entirely data scope.

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

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.