|
Notes |
|
|
(0017450)
|
|
Fused
|
|
2017-04-30 16:57
|
|
|
For clarification, this should check if the consoleplayer is closer than said distance. |
|
|
|
|
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; |
|
|
|
|
|
Yeah, there is a difference between consoleplayer's position and consoleplayer's CAMERA position. The camera position can be overriden using ChangeCamera. |
|
|
|
|
|
Strong support for this, I could optimize a lot of effects this way. |
|
|
|
(0017517)
|
|
Fused
|
|
2017-05-02 12:27
|
|
|
Yeah I suppose this should also respect cameras and player spectating. |
|
|
|
|
|
But then it's not actually ConsolePlayerIsCloser, but ConsolePlayerCameraIsCloser. |
|
|
|
|
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. |
|
|
|
|
@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. |
|
|
|
|
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
|
|
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. |
|
|
|
|
|
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
|
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
|
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.
|
|
|
|
|
|
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
|
|
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. |
|
|
|
|
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") |
|
closertest.wad (2,619) 2017-05-14 19:44