|
Notes |
|
|
|
|
Spectators are intentionally treated as not being part of the game, so they shouldn't interact with scripts in any way. |
|
|
|
|
|
But IIRC if you don't clear TID of spectators you can do some stuff on them. I for example could spawn projectiles on them. |
|
|
|
|
|
If you can do something with spectators it's simply a bug. |
|
|
|
|
but then why they can call scripts? :s
eh, it looks like I'll not win my function '-'... so there's another way to get it? by decorate? |
|
|
|
|
|
Torr please don't decline what not everything you can do w/ spectators is a bug. For example, in my mod I have a music manager what controls what each player hears and I want dead spectators to hear the same music as their team. In general I see no issue with non gameplay altering stuff being applicable to spectators. Maybe I even will use the fact I can spawn a projectile on them to show them as "ghosts", IMHO it would be a cool feature of my mod. |
|
|
|
|
|
I could be wrong about this, but it seems to me that if you're looping a clientsided script (an ENTER script for example), and then the player dies, it will still be able to get your coordinates. |
|
|
|
|
But then, if I f12 someone, would I get the position of the "Spectator position" or the position where I'm looking?
because that's the good part about a command at zandronum that shows the position that you're looking on the spectator position itself, the bad problem, there's no way to acess that data :( |
|
|
|
|
|
Can they not get your position when dead? |
|
|
|
(0010880)
|
|
Dusk
|
|
2014-11-13 16:34
|
|
|
I'm beginning to think that we should more strictly define what spectators can and cannot do. IMO, they should not interact with the playloop but should be able to execute ACS scripts (provided that they do not mess with the playloop) for instance. So a HUD script could pass for instance. |
|
|
|
|
well I tried with the enter script, but when I die, I only get actor pos x/y/z = zero, but the script continued to run, even if I was spectated or dead...
So, what I wish is an acs script that could get idmypos information.
Here's my situation:
I made a rainfall script, where it use the player tid to make it only rain near from him, it works fine, but, it just stop working when he f12 someone, spectate or die.
So on picture one'http://i.imgur.com/97xQlde.jpg [^]' , I have a bot and I playing the test map, on the middle of the screen is the print to show my position got from getactorx/y/z and my tid, and on the top right, it's the idmypos command, you can see that it works fine on this specific situation, but here thing get "wrong".
On the second screen'http://i.imgur.com/CUVhpUM.png [^]' I'm f12ing the bot,idk why it's zero the information on the middle, but, the important is the green information, it shows the position that I'm looking and not where am I...
And when I die/spectate, I will get a result just like picture 2, pos x/y/z = 0 but, I still can have the right position of my camera on the right.
So here am I asking again, I was wondering if you'd mind implementing a getmyposx() getmyposy() getmyposz() functions? OR, if there's already a way to make it , please tell me, because the only way I know to get position is by getactorx/y/z D: |
|
|
|
|
|
|
|
(0014003)
|
|
Dusk
|
|
2015-12-20 21:23
|
|
No.
Also good job screwing up p_acs.cpp's formatting entirely while doing so. |
|
|
|
|
|
Why do you need a special function for this? Can't you achieve this with GetActorX/Y/Z (CheckPlayerCamera( ConsolePlayerNumber() )? Assuming the camera has a TID? |
|
|
|
(0014005)
|
|
ibm5155
|
2015-12-20 22:05
(edited on: 2015-12-20 22:23) |
|
to get the player position while he's spectating, get the position of the followed player (by f12).
Also, as showed on the demo, getactorx/y/z is limited to get the player position, not the player câmera position.
Here are some examples:
'http://i.imgur.com/bgvSaei.png [^]' this Picture shows that I'm spectating, the getactorx/y/z only shows the last position that I was when I was playing, and the new function shows the position of my screen view position (so it can get my position even if I'm spectating), on the right, there's a message showing the x,y,z, resulted from the idmypos console comand.
'http://i.imgur.com/bgvSaei.png [^]' The second Picture shows my view, on that case, The result from the new function and getactorx/y/z are the same.
'http://i.imgur.com/b0y1EwT.png [^]' Third case: getactor x/y/z shows my actor position, while the new function shows the followed player position.
The problem is that the player's câmera isn't a fixed object, sometimes it's the player itself, sometimes it's another player and sometimes, it doesn't exist...
Indeed, Visual Studio screwed that file, I'll fix that file.
EDIT:
File fixed, removed everything I didn't changed in the code...
Also, it's now a fork ( I think that's the right way to do the things here)
'https://bitbucket.org/ibm5155/ibm5155zandronum/commits/0a9f1fcf392cf8bd0771e893b22158901c021c40 [^]'
|
|
|
|
|
Archvile time D:
video example of those functions in action:https://www.youtube.com/watch?v=L5zBpHQlbVM
what's happening in this video?
-there's fire in the position that each player is looking at.
-it's raining near your camera.
>>What's the difference betwheen GetactorXYZ and GetCameraXYZ.
-As the name says, Getactor return the position where the given actor tid is.
-GetCamera by the other side, return the position where your point of view position is.
-GetActor can work with multiple tids so it works in clientside/serverside.
-GetCamera only works with the client POV data so this is why it's a clientside only feature.
>>Why do you need this?
mostly in my case, to make my rainfall to rain around your point of view pos and not around the player's actors.
I also did other use cases test to see what could be done with that function:
-Send every spectator's coord to server by requestscriptpuke so you could show the spectators position to other spectators or even the players.
-You could do the same above to show who's spectating you.
================================================================================
Since most of the use cases are mostly visual only, there was no need to get the point of view coordinates when you're looking at the map, so the function could be way less complex and less evasive because there wouldn't need to have some extra cvar code outside the giant acs parser.
I'm going to try again to rework that code later (I dont have my main computer here to code)
And an extra: why don't I try to implement this in zdoom before? well I tried, but the network model doesn't like a function returning a different value for more than one player (and each player has no data about each player's camera pos so it's a no go there)
And lastly, I feel that function's name is bad, it should be something that doesn't make people confused with getactorx (hm GetConsolePlayerCameraXYZ ?) |
|
|
|
|
It should provide access to camera's direction too. And it should take ChangeCamera into account.
And a shorter name would be GetClientCameraXYZ. Also it would be easier to use as three separate functions, as it matches GetActorX GetActorY GetActorZ and doesn't require typing long extra constants.
Also, the rain will still be broken when viewed through camera textures. |
|
|
|
|
it's not in that commit neither in that vídeo, but for receiving the consoleplayercamera's pitch and angle was as easy as taking the xyz coord.
Yes, it's going to be 3 separated functions like:
ConsolePlayerCameraX();
ConsolePlayerCameraY();
ConsolePlayerCameraZ();
and if also done
ConsolePlayerCameraPitch();
ConsolePlayerCameraAngle();
It's quite a big name, but it fits the other name style of ConsolePlayerNumber().
Yes the rain is not gonna work in that way, but it's rare to see mods that uses that, and if used the modder could simply take the output from ConsolePlayerCameraXYZ to see if it's needed to Spawn rain in the texture câmera sector or not. |
|
|
|
|
|
|
|
(0017547)
|
|
ibm5155
|
2017-05-04 14:33
(edited on: 2017-05-04 15:03) |
|
GetActorX/Y/Z (CheckPlayerCamera(ConsolePlayerNumber()) partially works in zandornum 2.1.x while it doesnt in 3.0
the output from CheckPlayerCamera(ConsolePlayerNumber()) where you only have yourself ingame:
-3.0: -1 always
-2.1.2: returns the playertid
the output from CheckPlayerCamera(ConsolePlayerNumber()) where you are watching a camera is:
-3.0: returns the camera tid
-2.1.2: returns the camera tid
the output from CheckPlayerCamera(ConsolePlayerNumber()) when I try to coop spy a bot (he should have a uniquetid) is :
-3.0: returns -1
-2.1.2: returns the bot tid
Should I create a new ticket only about CheckPlayerCamera(ConsolePlayerNumber())?
EDIT: Acording to zdoom this is the result that should be returned for now, we cannot get anymore the players coord by coop spying because of this new guy ( || players[playernum].camera->player != NULL) EVEN if you set another player as a camera ;--;
'https://zdoom.org/wiki/CheckPlayerCamera [^]'
|
|
|
|
|
I had a look at the logs and found the reason why ZDoom added this check:
Quote from ZDoom Repo Log
Fixed: CheckPlayerCamera not sync safe
- If a player is spying through another player, CheckPlayerCamera will
return the TID of the player you are "spying", but as coopspy isn't a
net command, this wont be reflected by all nodes. So to fix this,
CheckPlayerCamera now returns -1 if a player's camera is that of any
player at all. (thanks edward850)
Since the server keeps everything in sync, we can definitely loosen this check. For instance, a client knows its own camera, so there is no need to return -1, when CheckPlayerCamera(ConsolePlayerNumber()) is called in a CLIENTSIDE script. |
|
|
|
(0017557)
|
|
ibm5155
|
2017-05-06 18:36
(edited on: 2017-05-06 18:48) |
|
"new => feedback "
Do you want me to edit the CheckPlayerCamera code?
@Torr, can I merge that existing function with mine? because when you're spectating you can get the coord from who you're coop spying, the only case it doesn't work is if you're just spectating but not coop spying someone else.
|
|
|
|
|
Sorry for not being clear enough. I'd like feedback on 0001679:0017548, i.e. is it sufficient for your purposes if we make CheckPlayerCamera(ConsolePlayerNumber()) work in CLIENTSIDE script again like it did in 2.1.2?
Quote from ibm5155
@Torr, can I merge that existing function with mine? because when you're spectating you can get the coord from who you're coop spying, the only case it doesn't work is if you're just spectating but not coop spying someone else.
What is the problem if you are just spectating? That the camera is the spectator body which has no tid? |
|
|
|
|
It fixes almost all the cases that I wanted, like:
-get your coord when your actor is in game.
-get your camera coord when you coop spy or when you're viewing an activator camera (Works when your actor is in the game or when spectating).
The only case that it doesn't work for me is the following one:
-get your coord when your actor isnt in the game (spectating)
Yes, the problem happens by the fact that the spectator body has no tid, and I
think it's fine the way it's.
What about a change in Getactor X|Y|Z where if called from a clientside script
where the actor is null, return the coord from the spectator?
here's an example code that I did:'https://pastebin.com/m5WWDn3u [^]' |
|
|
|
|
Quote from ibm5155
What about a change in Getactor X|Y|Z where if called from a clientside script
where the actor is null, return the coord from the spectator?
No, I don't see any reason why this should be a reasonable fallback.
What you should be able to do is the following: In case CheckPlayerCamera returns -1, you can check whether the player is a true spectator with PlayerIsSpectator. If that is the case, you know that you have a true spectator that is not coop spying. Make that player the activator (if he is not already) and you can get the position with GetActorX/Y/Z. |
|
|
|
|
Ok now, just a final question.
do you want me to apply PlayerIsSpectator on my new acs function (GetConsolePlayerCameraX/Y/Z) or into getactorX/Y/Z ? |
|
|
|
(0017580)
|
|
Torr Samaho
|
2017-05-07 13:56
(edited on: 2017-05-07 13:59) |
|
Neither. I'm trying to say what you want to achieve is already possible with ACS in 2.1.2, if you handle the true spectator case explicitly like I outlined in 0001679:0017573.
|
|
|
|
|
CheckPlayerCamera(ConsolePlayerNumber()) return 0 when spectating in zan 2.1.2 and -1 in 3.0
While PlayerIsSpectator return 1 when I specate in both 2.1.2 and 3.0..
And I cannot use GetActor in that case because the activator will Always be null (even if I try to set him a new tid)? why, because it looks like the spectators doesn't store tids, so it'll return null in the SingleActorFromTID code because the activator tid will Always be zero.
Being able to set tids for spectators may fix that |
|
|
|
|
Above you said:
Quote from ibm5155
It fixes almost all the cases that I wanted, like:
-get your coord when your actor is in game.
-get your camera coord when you coop spy or when you're viewing an activator camera (Works when your actor is in the game or when spectating).
So when and how does the last thing work? Based on this
Quote from ibm5155
CheckPlayerCamera(ConsolePlayerNumber()) return 0 when spectating in zan 2.1.2 and -1 in 3.0
I can't be working either in 2.1.2 or 3.0 at the moment. |
|
|
|
(0017587)
|
|
ibm5155
|
2017-05-07 15:59
(edited on: 2017-05-07 16:05) |
|
|
|
|
(0017588)
|
|
Torr Samaho
|
2017-05-07 16:08
(edited on: 2017-05-07 16:18) |
|
Ok, then what I described in 0001679:0017573 should work in 2.1.2. If CheckPlayerCamera(ConsolePlayerNumber()) returns 0, you check PlayerIsSpectator(ConsolePlayerNumber()). If that returns 1, you know that the local player is a true spectator.
If the local player is the activator of the current script, GetActorX(0) should work. If the local player is not activator, you have to make him the activator.
EDIT: I had a look at your example wad:
SetActivator(ConsolePlayerNumber(), ConsolePlayerNumber());
can't work. Currently, with SetActivator you only use the first eight players as activator. You should be able to do it along the lines of
if ( ConsolePlayerNumber() == 0 )
SetActivator(0, AAPTR_PLAYER1);
else if ( ConsolePlayerNumber() == 1 )
SetActivator(0, AAPTR_PLAYER2);
...
|
|
|
|
(0017589)
|
|
ibm5155
|
2017-05-07 16:46
(edited on: 2017-05-07 16:52) |
|
This should work right?
===============================================================
EDIT: Saw your edit, and it Works indeed :D ...
Just a question, this script Works with more than 8 players?
|
|
|
|
|
No,
SetActivator(ConsolePlayerNumber());
cannot work. Why do you think this should do anything? The first argument of SetActivator is a tid. Why do you think a player number could work to replace a tid? I sketched how to use SetActivator to set the activator to the console player in 0001679:0017588. |
|
|
|
(0017591)
|
|
ibm5155
|
2017-05-07 17:03
(edited on: 2017-05-07 17:11) |
|
Sorry :S, Idk how well all those playernumber thing Works well :B
It looks like this method is limited to 8 players, ehm, what about a SetActivatorToPlayer function? (sugested by Korshun)
EDIT: Or ConsolePlayerPointer()
|
|
|
|
|
|
Something that works like SetActivatorToPlayer would be great, we just have to find a future proof way to implement this. Let's discuss this aspect in 0002649. |
|
|
|
|
|
|
|
(0017600)
|
|
ibm5155
|
2017-05-07 23:36
(edited on: 2017-05-08 00:53) |
|
I tried to coop spy using CheckPlayerCamera(ConsolePlayerNumber()) but it doesn't work, but since I removed the bloatware 2017 and replaced it by VS2015, here are some data for you inside the PCD_CHECKPLAYERCAMERA:
playernum = 0
playeringame[playernum] = true
players[playernum].câmera != NULL
players[playernum].camera->player != NULL
NETWORK_InClientMode = 0
so we have this if:
if(FALSE || FALSE || !TRUE || FALSE || (TRUE && !FALSE))
=>
if(FALSE || FALSE || FALSE || FALSE || (TRUE && TRUE))
=>
if(FALSE || TRUE)
=>
return -1
EDIT: Hmm it seems to be working online but not off-line:
off-line: being ingame or spectating, coop spying or not Always gives u the coord 0 using GetActorX(CheckPlayerCamera( ConsolePlayerNumber()))
online:
ENTER CLIENTSIDE Works fine in all the cases
OPEN CLIENTSIDE: the only case that doesn't work is coop spying in spectator mode.
|
|
|
|
(0017601)
|
|
ibm5155
|
2017-05-08 01:18
(edited on: 2017-05-08 01:35) |
|
Ok here is a bigger test: 'https://1drv.ms/u/s!AurELTq1jbljkbQ_j67mb1ErQUXj4Q [^]'
I took my old testing my for this function, and reimplemented the acs calls to script call (so there's no need to reimplement the wheel on c++)
open clientside scripts seems to be working in that case (maybe because a clientside script is calling another clientside script)
It's not a perfect wad, but it implemente some stuff that I need and even others that I got the idea about the usage of those functions
EDIT: the open clientside script doesn't work online if no one is playing the game (everyone on the server is spectating)
|
|
|
|
|
LAST NOTE:
in PCD_CHECKPLAYERCAMERA
if (playernum < 0 || playernum >= MAXPLAYERS || !playeringame[playernum] || players[playernum].camera == NULL || ( players[playernum].camera->player != NULL && !NETWORK_InClientMode() ) )
needs to be
if (playernum < 0 || playernum >= MAXPLAYERS || !playeringame[playernum] || players[playernum].camera == NULL || ( players[playernum].camera->player != NULL && NETWORK_GetState() == NETSTATE_SERVER) )
so it can work in single player with clientside scripts (tested) |
|
|
|
|
FYI, the CLIENTSIDE flag is ignored in single player, so technically there are no CLIENTSIDE scripts in single player. That's why I didn't change the single player behavior so far.
Can you elaborate what you need this for? In single player, you are usually not spectating or coop spying. |
|
|
|
(0017665)
|
|
ibm5155
|
2017-05-14 13:09
(edited on: 2017-05-14 13:10) |
|
Indeed, the change was mostly to make CheckPlayerCamera() compatible with single player.
I could do an workaround to make this code to work in single player, BUT, in that case, if I add a new bot, the code doesn't work
Example code:
script "GetConsolePlayerCameraX" (void) clientside{
int _return;
if(GameType() == GAME_SINGLE_PLAYER && ConsolePlayerNumber() == 0){
SetActivator(0,AAPTR_PLAYER1);
if(getactorx(CheckPlayerCamera(0) == 0)){
_return =getactorx(0);
}
else{
_return =(GetActorX(CheckPlayerCamera(0)));
}
}
else{
if(CheckPlayerCamera(ConsolePlayerNumber()) <= 0 && PlayerIsSpectator(ConsolePlayerNumber())){
if(SetActivatorToPlayer(ConsolePlayerNumber()) == 0){
print(s:"Error in SetActivatorToPlayer, return 0");
}
}
_return =(GetActorX(CheckPlayerCamera( ConsolePlayerNumber())));
}
SetResultValue(_return);
}
|
|
|
|
|
Quote from Torr Samaho
Can you elaborate what you need this for?
|
|
|
|
|
I just need that so my mod or others that may use that function are not going to break off-line (single player).
I can do a workaround so the script Works in single player WITHOUT bots, but when I add a bot into the single player gameplay, things just doesnt work anymore (because the game is not SINGLE_PLAYER but yes GAME_NET_COOPERATIVE).
I'd be glad if you gave me a solution for the single player with multiplayer case.
else: I could give you a virtual cookie if you add that commit :p |
|
|
|
|
|
Let me rephrase my question. You are worried about the performance of your rainfall script, right? How do you fix the performance problems in ZDoom in single player? |
|
|
|
(0017677)
|
|
ibm5155
|
2017-05-14 15:53
(edited on: 2017-05-14 15:59) |
|
Oh, got it...
I'm not worried with the performance with the rainfall script, my MAIN problem is that CheckPlayerCamera Always return -1 in single player or multiplayer emulation.
SO, if I do: GetActorY(CheckPlayerCamera( ConsolePlayerNumber() )) it'll Always return 0 in singleplayer/multiplayer emulation.
EDIT: If I replace the "!NETWORK_InClientMode() " by "NETWORK_GetState() == NETSTATE_SERVER" in check player câmera, then the return from CheckPlayerCamera( ConsolePlayerNumber() is the correct player tid (or the câmera tid that the player is looking at) and not -1
|
|
|
|
|
Quote from ibm5155
my MAIN problem is that CheckPlayerCamera Always return -1 in single player or multiplayer emulation.
This is what ZDoom is doing and it's doing so intentionally. If you want me to change this, you need a good use case that allows to justify breaking with the ZDoom behavior. This ticket was originally about the performance of your rainfall script, but now you say that this is not what you are worried about. What problem are you trying to solve then by making use of GetActorY(CheckPlayerCamera( ConsolePlayerNumber() ))? |
|
|
|
|
This is quite a old ticket, what I was trying to do was to rain around the player's point of view coord, in the old days I only knew about the use of GetActorX/Y/Z, so with that I could only rain around the player actor, but if the player spectate or coop spy, it would rain at the wrong place (where player actor was and not where your camera coord was).
With the changes you did I can now make this happen ONLINE, I can get the player's câmera coord, doing coop spy or spectating.
Now my only limitation is single player with bots, in that case my raifall is raining at the coord {0,0,0} because CheckPlayerCamera is Always returning -1 in that specific case.
IF there's a way to know if the game is being played in that emulated multiplayer mode, I can actually fix this problem without changing the zandronum code. (so my function will finally work in all the cases that someone can play it) |
|
|
|
|
|
But doesn't that mean you are worried about the performance of the rainfall script, since you want to limit the rain to where the player is looking? |
|
|
|
(0017686)
|
|
ibm5155
|
2017-05-14 18:02
(edited on: 2017-05-14 18:06) |
|
ehm, yes, because there's no need to rain where the player isn't looking at.
Well, in case there's no way to get CheckPlayerCamera to work in single player with bots without changing the c++ code, so I'm fine with what you have done.
EDIT: in the end, I'll use this function for my rainfall script, + some new stuff like showing who's spectating you or showing where the spectators are ingame...
|
|
|
|
(0017687)
|
|
Torr Samaho
|
2017-05-14 18:13
(edited on: 2017-05-14 18:17) |
|
Don't get me wrong, I'm not saying we can't further change what CheckPlayerCamera is returning under which circumstances. But before considering further changes (in particular changes that possibly break compatibility with ZDoom in single player), I just wanted to know what exactly you are trying to achieve. Not wanting to spawn rain everywhere sounds very reasonable to me. I'll discuss this with the other devs. I could imagine having CheckPlayerCamera work the same when multiplayer emulation is enabled as it does on the clients now.
EDIT:
Quote from ibm5155
who's spectating you or showing where the spectators are ingame...
Spectator positions are not synced. So there is no way to show clients where other spectators are. Furthermore, IIRC the server does not inform the clients who is spying whom, so you can't show who is spying you.
|
|
|
|
|
Ok, I was just feeling that this wouldn't change because it's the way zdoom did.
If you make CheckPlayerCamera to work with the multipalyer emulation I'd be glad :D
About your edit, yes, you can't directly, but with my function, you can make every spectator to run a clientside script, get his position and send it to the server with RequestScriptPuke, later I did an object that represent a spectator, this object will have his position updated acording to RequestScriptPuke input.
what I did to know who's spectating you, send this coord from spectators that the server stored and send it for each player, to know who's spectating you, you just compare the position of each spectator with your position, if they are too near, then a spectator is coop spying you (not a perfect solution, be in this case I don't need a perfect solution that doesn't affect the gameplay in any matter)
Here's an example of receiving the spectator's coord and send it to the server
'https://pastebin.com/3Pv67jms [^]' |
|
|
|
|
|
After discussing this with the other devs, we decided to restore the behavior from Zandronum 2.1.2. This preserves backwards compatibility with 2.1.2 and should solve your last problem. |
|
|
|
|
|
wow, thanks alot Torr Samaho :D |
|
|
|
|
Tested and it's working great :D
This one can be in resolved state ;--; |
|
|
|
|
|
I'm glad to hear that! Marking this as resolved then. |
|
