0003114: A_JumpIfConsolePlayerCloser

(0017450)
Fused (reporter)
2017-04-30 16:57

For clarification, this should check if the consoleplayer is closer than said distance.

(0017477)
ibm5155 (reporter)
2017-05-01 14:56

It could get his data from here:
x = players[consoleplayer].camera->x;
y = players[consoleplayer].camera->y;
z = players[consoleplayer].camera->z;

so it Works if the player is spectating and even coop spying (F12).
It would be a similar function to the one that I'm gonna try to implemente in acs.
And also, it should work in clientside or in single player mode, BUT, in multiplayer serverside script, it should only return 0;

(0017479)
Korshun (reporter)
2017-05-01 16:23

Yeah, there is a difference between consoleplayer's position and consoleplayer's CAMERA position. The camera position can be overriden using ChangeCamera.

(0017502)
StrikerMan780 (reporter)
2017-05-01 19:45

Strong support for this, I could optimize a lot of effects this way.

(0017517)
Fused (reporter)
2017-05-02 12:27

Yeah I suppose this should also respect cameras and player spectating.

(0017518)
Korshun (reporter)
2017-05-02 12:29

But then it's not actually ConsolePlayerIsCloser, but ConsolePlayerCameraIsCloser.

(0017652)
Torr Samaho (administrator)
2017-05-13 14:51

Quote from Fused
A_JumpIfCloser for clientsided decoration basically. This would help a lot with performance, due to being able to determine whenever the consoleplayer should render something or not.

How would you optimize this in single player? If you have speed problems on the clients, I guess you should have the same problems in single player.

(0017666)
ibm5155 (reporter)
2017-05-14 13:19

@Torr I only see some cases where this is valid, like the example of my rainfall:
-the rainfall is a heavy effect that may Spawn more than 100,000 particles, and to save some performance you just Spawn those particles around the player's câmera coord and not all over the map.

When my acs functions are ready, that new decorate function could just call those functions that I did to do the same thing.

(0017669)
Torr Samaho (administrator)
2017-05-14 14:35

Quote from ibm5155

-the rainfall is a heavy effect that may Spawn more than 100,000 particles, and to save some performance you just Spawn those particles around the player's câmera coord and not all over the map.

This sounds like something that would also be too slow in ZDoom.

(0017689)
Fused (reporter)
2017-05-14 18:36

Quote

How would you optimize this in single player? If you have speed problems on the clients, I guess you should have the same problems in single player.

If you mean how the function should behave in singleplayer, then it should be the same as A_JumpIfCloser. If you use that in singleplayer currently, there's a massive increase in frames when done right.

(0017690)
Torr Samaho (administrator)
2017-05-14 19:05

Can you post a corresponding small single player example for A_JumpIfCloser? For CLIENTSIDEONLY actors, the clients should already do the jumps in A_JumpIfCloser on their own, but perhaps there is a problem with how the target of CLIENTSIDEONLY is set.

(0017691)
Dusk (developer)
2017-05-14 19:05
edited on: 2017-05-14 19:06

What do you generally do when the player is too far away? Make the actor invisible and freeze whatever it's doing? Perhaps some built-in behavior would work better and be more convenient. I'm not too much of a fan of adding more of these kinds of codepointers.

(0017692)
Fused (reporter)
2017-05-14 19:49
edited on: 2017-05-14 20:28

I uploaded an example. It's hard to keep a decent filesize while showcasing the change in framerate, so I chose to spawn everything using a script. I believe I noticed how for some reason frames dropped way quicker when spawned through ACS, so I had to find a spot where it would still be smooth, yet drop frames when near the pillars.

When you walk to the other side of the room, pillars will start rendering. The more stacked pillars, the lower your frames. I'm unable to do this online as A_Jumpifcloser doesn't seem to work. I assumed this would need a seperate function, much like A_FaceConsolePlayer has done (even though the serversided variant is for targets only)

Quote

What do you generally do when the player is too far away? Make the actor invisible and freeze whatever it's doing? Perhaps some built-in behavior would work better and be more convenient. I'm not too much of a fan of adding more of these kinds of codepointers.

I don't intent to use this on any active actors, but I guess I will do that, should I make stuff move. Like with the example wad, I mostly just use pure decoration. I am fine with it being build in, but only if there's a way to modify how far it renders each actortype, incase something should be rendered from further away. Although I would like to be able to just have full controll over it regarding what it shows when out of range etc too.

(0017693)
Torr Samaho (administrator)
2017-05-14 19:56

After looking at the code of your example, I think what may be sufficient is to adapt A_Look when called on the clients by CLIENTSIDEONLY actors. Currently, A_Look will essentially do nothing on the client, but except the server handle everything. For CLIENTSIDEONLY actors this is wrong though.

(0017698)
Fused (reporter)
2017-05-15 08:07

Having A_Look face consoleplayers in a clientsided actor is definitely a solution too. It would mean A_FaceConsolePlayer is probably not needed either.

(0017755)
ibm5155 (reporter)
2017-05-24 16:37

with the changes that Torr did before with the câmera stuff (id 1679), you can now do the same thing that you wanted in with A_JumpIfConsolePlayerCloser in acs.
So use this:'https://pastebin.com/WemJViiS [^]' and on decorare just do a:
A_jumpif(acs_namedexecutewithresult("ConsolePlayerCloser",2000) == false, "Sleep")

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	ibm5155 StrikerMan780 Korshun Kaminsky Dynamix
Opponents:	No one explicitly opposes this issue yet.

Notes
(0017450) Fused (reporter) 2017-04-30 16:57	For clarification, this should check if the consoleplayer is closer than said distance.

(0017477) ibm5155 (reporter) 2017-05-01 14:56	It could get his data from here: x = players[consoleplayer].camera->x; y = players[consoleplayer].camera->y; z = players[consoleplayer].camera->z; so it Works if the player is spectating and even coop spying (F12). It would be a similar function to the one that I'm gonna try to implemente in acs. And also, it should work in clientside or in single player mode, BUT, in multiplayer serverside script, it should only return 0;

(0017479) Korshun (reporter) 2017-05-01 16:23	Yeah, there is a difference between consoleplayer's position and consoleplayer's CAMERA position. The camera position can be overriden using ChangeCamera.

(0017502) StrikerMan780 (reporter) 2017-05-01 19:45	Strong support for this, I could optimize a lot of effects this way.

(0017517) Fused (reporter) 2017-05-02 12:27	Yeah I suppose this should also respect cameras and player spectating.

(0017518) Korshun (reporter) 2017-05-02 12:29	But then it's not actually ConsolePlayerIsCloser, but ConsolePlayerCameraIsCloser.

(0017652) Torr Samaho (administrator) 2017-05-13 14:51	Quote from Fused A_JumpIfCloser for clientsided decoration basically. This would help a lot with performance, due to being able to determine whenever the consoleplayer should render something or not. How would you optimize this in single player? If you have speed problems on the clients, I guess you should have the same problems in single player.

(0017666) ibm5155 (reporter) 2017-05-14 13:19	@Torr I only see some cases where this is valid, like the example of my rainfall: -the rainfall is a heavy effect that may Spawn more than 100,000 particles, and to save some performance you just Spawn those particles around the player's câmera coord and not all over the map. When my acs functions are ready, that new decorate function could just call those functions that I did to do the same thing.

(0017669) Torr Samaho (administrator) 2017-05-14 14:35	Quote from ibm5155 -the rainfall is a heavy effect that may Spawn more than 100,000 particles, and to save some performance you just Spawn those particles around the player's câmera coord and not all over the map. This sounds like something that would also be too slow in ZDoom.

(0017689) Fused (reporter) 2017-05-14 18:36	Quote How would you optimize this in single player? If you have speed problems on the clients, I guess you should have the same problems in single player. If you mean how the function should behave in singleplayer, then it should be the same as A_JumpIfCloser. If you use that in singleplayer currently, there's a massive increase in frames when done right.

(0017690) Torr Samaho (administrator) 2017-05-14 19:05	Can you post a corresponding small single player example for A_JumpIfCloser? For CLIENTSIDEONLY actors, the clients should already do the jumps in A_JumpIfCloser on their own, but perhaps there is a problem with how the target of CLIENTSIDEONLY is set.

(0017691) Dusk (developer) 2017-05-14 19:05 edited on: 2017-05-14 19:06	What do you generally do when the player is too far away? Make the actor invisible and freeze whatever it's doing? Perhaps some built-in behavior would work better and be more convenient. I'm not too much of a fan of adding more of these kinds of codepointers.

(0017692) Fused (reporter) 2017-05-14 19:49 edited on: 2017-05-14 20:28	I uploaded an example. It's hard to keep a decent filesize while showcasing the change in framerate, so I chose to spawn everything using a script. I believe I noticed how for some reason frames dropped way quicker when spawned through ACS, so I had to find a spot where it would still be smooth, yet drop frames when near the pillars. When you walk to the other side of the room, pillars will start rendering. The more stacked pillars, the lower your frames. I'm unable to do this online as A_Jumpifcloser doesn't seem to work. I assumed this would need a seperate function, much like A_FaceConsolePlayer has done (even though the serversided variant is for targets only) Quote What do you generally do when the player is too far away? Make the actor invisible and freeze whatever it's doing? Perhaps some built-in behavior would work better and be more convenient. I'm not too much of a fan of adding more of these kinds of codepointers. I don't intent to use this on any active actors, but I guess I will do that, should I make stuff move. Like with the example wad, I mostly just use pure decoration. I am fine with it being build in, but only if there's a way to modify how far it renders each actortype, incase something should be rendered from further away. Although I would like to be able to just have full controll over it regarding what it shows when out of range etc too.

(0017693) Torr Samaho (administrator) 2017-05-14 19:56	After looking at the code of your example, I think what may be sufficient is to adapt A_Look when called on the clients by CLIENTSIDEONLY actors. Currently, A_Look will essentially do nothing on the client, but except the server handle everything. For CLIENTSIDEONLY actors this is wrong though.

(0017698) Fused (reporter) 2017-05-15 08:07	Having A_Look face consoleplayers in a clientsided actor is definitely a solution too. It would mean A_FaceConsolePlayer is probably not needed either.

(0017755) ibm5155 (reporter) 2017-05-24 16:37	with the changes that Torr did before with the câmera stuff (id 1679), you can now do the same thing that you wanted in with A_JumpIfConsolePlayerCloser in acs. So use this:'https://pastebin.com/WemJViiS [^]' and on decorare just do a: A_jumpif(acs_namedexecutewithresult("ConsolePlayerCloser",2000) == false, "Sleep")

Issue History
Date Modified	Username	Field	Change
2017-04-30 16:01	Fused	New Issue
2017-04-30 16:57	Fused	Note Added: 0017450
2017-05-01 14:56	ibm5155	Note Added: 0017477
2017-05-01 16:23	Korshun	Note Added: 0017479
2017-05-01 19:45	StrikerMan780	Note Added: 0017502
2017-05-02 12:27	Fused	Note Added: 0017517
2017-05-02 12:29	Korshun	Note Added: 0017518
2017-05-13 14:51	Torr Samaho	Note Added: 0017652
2017-05-13 14:51	Torr Samaho	Status	new => feedback
2017-05-14 13:19	ibm5155	Note Added: 0017666
2017-05-14 14:35	Torr Samaho	Note Added: 0017669
2017-05-14 18:36	Fused	Note Added: 0017689
2017-05-14 18:36	Fused	Status	feedback => new
2017-05-14 19:05	Torr Samaho	Note Added: 0017690
2017-05-14 19:05	Dusk	Note Added: 0017691
2017-05-14 19:06	Torr Samaho	Status	new => feedback
2017-05-14 19:06	Dusk	Note Edited: 0017691	View Revisions
2017-05-14 19:44	Fused	File Added: closertest.wad
2017-05-14 19:49	Fused	Note Added: 0017692
2017-05-14 19:49	Fused	Status	feedback => new
2017-05-14 19:49	Fused	Note Edited: 0017692	View Revisions
2017-05-14 19:56	Torr Samaho	Note Added: 0017693
2017-05-14 20:28	Fused	Note Edited: 0017692	View Revisions
2017-05-15 08:07	Fused	Note Added: 0017698
2017-05-24 16:37	ibm5155	Note Added: 0017755

Relationships