Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000898Zandronum[All Projects] Suggestionpublic2012-06-25 04:092018-09-30 19:51
ReporterWatermelon 
Assigned ToTorr Samaho 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version1.0 
Summary0000898: GetPlayerInput cannot work on CLIENTSIDE scripts
DescriptionGetPlayerInput would be great to call on spectators who join the game as it allows some interesting customization to be done in the wad with respect to showing stuff based on player input and mouse movements.

There are a TON of features that the GVH community wants in that literally are halted by this (or rather made extremely inconvenient), so far we are unable to add it properly since GetPlayerInput always returns 0 on the clientside.

As a developer for this mod, and on behalf of the GVH community: May I request that CLIENTSIDE functions for GetPlayerInput return the values on the current machine? It would mean a lot to us. This in turn would also allow a new release of GVH and give reasons to further drive players from the old Skulltag over to Zandronum.

Ideally it should work when players are spectating (as the script in the example is an OPEN CLIENTSIDE script), assuming this feature can be implemented.

This feature will also pave the way for customization in ACS heavy games like All Out War... etc, possibly benefiting the modding scene tremendously.
Steps To Reproduce1. Open game (-host -file ACSExample.wad), online net play is desired in this case, but you can test it offline

2. Load MAP01 (Just go to New Game)

3. Watch
Additional InformationThe function does work on the server end if the player is actively in game and not in spectator mode.

The function does not work clientside for neither spectator nor in-game modes.
Attached Files? file icon ACSExample.wad [^] (713 bytes) 2012-06-25 04:09
? file icon ACSClientToServer.wad [^] (945 bytes) 2012-06-27 16:40

- Relationships
related to 0001656resolved CLIENTSIDE GetPlayerInput to work the same on- and offline 

-  Notes
User avatar (0003850)
Dusk (developer)
2012-06-25 11:25

 User error.

From ZDoom wiki regarding GetPlayerInput:
player
 The number of the player you want to get information on. Player 1 is 0, player 2 is 1, etc. Use -1 to specify the script activator instead.

In OPEN scripts, the activator is the world, not the player. Using ENTER instead of OPEN makes the script work properly.
User avatar (0003851)
Dusk (developer)
2012-06-25 15:30
edited on: 2012-06-25 15:31

 Alright, after discussing this with Watermelon, it turned out that GetPlayerInput cannot return input information on client-side scripts if the consoleplayer is a spectator.

Moreover, DLevelScript::GetPlayerInput has absolutely zero spectator handling. I was thinking about returning consoleplayer input if GetPlayerInput is called on a client-side script, no matter what is passed as the first parameter.

if (NETWORK_InClientMode()) p = consoleplayer;
or something like that.

I think it's safe to assume that the client doesn't know of other players' input, right? In such case, using GetPlayerInput on a non-consoleplayer in clientside scripts would always return 0 (and thus be of no use). Therefore, there would be no backwards-compatibility issues.

How feasible would this be?
User avatar (0003856)
Torr Samaho (administrator)
2012-06-26 20:40

 Spectators are considered not to be part of the game and so far they are not supposed to interact with scripts in any way. That's for instance why spectators don't trigger ENTER scripts. We may decide to dilute this design here, but this has to be well thought out.
User avatar (0003858)
Dusk (developer)
2012-06-26 21:48

 I guess server-side this makes sense, but I think that spectators should be able to be scripted on at least client-side. If you use ConsoleCommand to puke client-side scripts you can script on the consoleplayer while he spectates. Furthermore, the spectating consoleplayer can also become activator if he pukes a NET CLIENTSIDE script.

Why? Modders may use this to have users interact with the mod in some way or form or start up special effects or put up a menu with mod-specific options or something like that before they join. I think this sort of behavior allows for great possibilities and should be preserved. Scripting on the (spectating) consoleplayer lets you interact with the user, even right after the game starts.

I myself have even gone so far as made the newly connecting player send a request to the server with a NET script for information on map-scoped variables, implementing a "full update system" done in ACS. This kind of stuff is useful for custom menus and HUDs.

I though think that there should be a non-hack way to run a console-player activated script when the game starts...
User avatar (0003862)
Watermelon (developer)
2012-06-27 04:02
edited on: 2012-06-27 04:11

 > Spectators are considered not to be part of the game and so far they are not supposed to interact with scripts in any way. That's for instance why spectators don't trigger ENTER scripts. We may decide to dilute this design here, but this has to be well thought out.

I'll try and be as succinct as possible (my previous response was 2000+ words)
- Spectators can already puke scripts through NET scripts

- Theres a DMFlag or CompatFlag to make all NET scripts clientside to prevent this possible 'abuse' -- if it's such a concern, enable it by default and then let people who host mods (who know what they are doing) disable it?

- These puked scripts *cannot* affect the game at the moment (so please don't change it), as you will see in an example wad I posted, if you call a script that has PrintBold and ThingDamage in it, the Thing_Damage command is actually not run if you're a spectator, so there is already a failsafe (but PrintBold will display for everyone)

- Mods thus far all have some kind of implementation of OPEN CLIENTSIDE scripts. AoW may have some, GVH definitely has it, Zombie Horde probably does due to its achievement system and data storing, JumpMaze not only has it, but takes it to a *whole new level* with an exe embedded in the .pk3 itself(!), and CTFCaptains (a wad which I made) relies on the spectator being able to send data to the server as a spectator. If you disable this feature you will kill mod abilities in our mods, and kill off a prized addon wad for CTF players.
Based on the above list, that encompasses almost all of the CTF community, and 85-90% of the mod scene. That's massive! Maybe even more because I'm not including games like Shotgun Frenzy or such which are very ACS heavy and advanced, which may push 85-90% even higher. By adding this option you will benefit all those players.

- This will allow clientside to see its own data, there should be no harm in such a thing and further allows clientside modability

- This will not change how the spectator acts in games, the design of the spectator in game need not be touched

- Clients can do things from the spectator mode, instead of having to join a game, pop up the menu (since you can only grab data while in game), and this makes you a sitting suck for team last man standing games/stacks the teams/blocks other players...etc

- If you're worried about abuse, we already have a CompatFlag that completely disables spectators communicating with the server in any shape or form (since the only way for spectators thus far to interact is puke scripts with CompatFlag2 'Compat_NetScriptsAreClientSide'); there's not a single worry about this being 'abused'
I just went through the list, the only server that had Compat_NetScriptsAreClientside set to true is this abandoned bot server that no one plays it. Furthermore, it seems that this is a default option-- therefore people will be unable to shoot themselves in the foot unless they willingly change the CompatFlags2.

Torr: I don't know if you secretly load up an alias and play mods, or play CTF... but if you don't: Please let me tell you how important something like this will be. Every single active person who plays in the GVH community wants to see this. I can't speak on behalf of other mods but you're opening a "good" pandora's box for modders by allowing this. We want to move forward as the leading game of allowing mods, not restricting this port and going the route of ZDaemon.

GVH intends to release its ultimate version ever as a pull for players to bridge from Skulltag to Zandronum. It utilizes all the what-were-98e-features, and by adding this single update you will make all of this possible (or at least much more convenient). Implementation of the client reading its own button/mouse data will overcome an impossible roadblock that the wad I work on faces. In addition, it will also bring up hopefully a new front of mod features that we can showcase as "look, Zandronum is the place to be."


EDIT: Torr if you want me to PM you on something very interesting I've done so far so you can see the true magnitude of what this tweak has to offer, I will message you on the Zandronum forums.
User avatar (0003863)
Watermelon (developer)
2012-06-27 16:40

 Oops, forgot to upload the test wad.... attached
User avatar (0003864)
Torr Samaho (administrator)
2012-06-27 21:01

 First and foremost, let me clarify that I have absolutely no intention to shut down existing mods. To the contrary, I always strife for staying compatible with existing modes while paving the way for exciting new features and modding capabilities.

OPEN CLIENTSIDE scripts are perfectly fine, I introduced them on purpose. Note that these scripts are not activated by a spectator, they are activated by the world, so this nicely fits with the "spectators are not part of the game" approach. Following this line, we could let GetPlayerInput return the input from the consoleplayer if it's called from a CLIENTSIDE script with the world as activator. Would this solve what you try to achieve?
User avatar (0003865)
Watermelon (developer)
2012-06-27 22:19
edited on: 2012-06-28 00:15

 Cool, I appreciate that a lot :)

If it's possible to have GetPlayerInput(-1, INPUT_BUTTONS/INPUT_PITCH/INPUT_YAW...etc) return the value to the client itself only, then that's completely fine by me. I don't need the spectator to be anything else, as long as it can use the function to read its own input only (regardless of who activates it) it's all good.


// If this returns something greater than zero while holding down +forward or +fire/+attack...etc, that's all that we need
Script 10 OPEN CLIENTSIDE
{
    delay(35*5);
    PrintBold(d: GetPlayerInput(-1, INPUT_BUTTONS));
}

Hopefully that clarifies my situation. If the -1 returns the world, will that point to the player? Or to an imaginary server that will always return zero? I will store the player number on the machine so I could always substitute the PlayerNumber() the player is supposed to be into the first argument for GetPlayerInput.

As long as the function returns what is going on for the client itself in a clientside function, doesn't matter if the world activates it or not. My only question is would -1 be using the activator as the world, and thus return nothing? Or would it re-direct itself to the client's input (which is what we want)
User avatar (0003873)
Torr Samaho (administrator)
2012-07-01 09:21

 Alright, since this is only a minimal change that shouldn't affect anything else, I went ahead and implemented this, i.e. if GetPlayerInput is called from a world activated CLIENTSIDE script with a negative player number, the input of the local consoleplayer is returned.
Quote from Dusk

I though think that there should be a non-hack way to run a console-player activated script when the game starts..

Probably we should introduce a new script type for this. The currently used approach of using a CLIENTSIDE NET script puked by ConsoleCommand in a CLIENTSIDE OPEN script is awful and just works by chance, it was never intentionally designed to be used like this.
User avatar (0003874)
Dusk (developer)
2012-07-01 09:27
edited on: 2012-07-01 11:17

 I know, that's why I posted my remarks about it.

Maybe there could be a SetActivatorToConsolePlayer(); which would only function in client-side scripts? Would seem like a better approach to me..

I could go and put that in if you want.
EDIT: Well, after I return on tuesday, that is..
User avatar (0003876)
Torr Samaho (administrator)
2012-07-01 13:15

 A SetActivatorToConsolePlayer() function that only works in CLIENTSIDE scripts could work. I think it won't hurt though if we brainstorm a bit more before deciding how to handle this. Can you post a small example wad where you would want to use SetActivatorToConsolePlayer()? At least I get a better feeling for this if I see a specific example.
User avatar (0003878)
Watermelon (developer)
2012-07-01 16:21
edited on: 2012-07-01 16:22

 Successfully works (on the server I hosted)! Thanks so much
User avatar (0003903)
Dusk (developer)
2012-07-05 12:37

 > Can you post a small example wad where you would want to use SetActivatorToConsolePlayer()?
I don't have a WAD at hand but I got a few examples.

Well for instance you could write stuff like this:
script 901 (void) {
SetActivatorToConsolePlayer();
SetResultValue (PlayerNumber());
}

function int ConsolePlayerNumber() {
return ACS_ExecuteWithResult (901);
}

And that value you could use to make the console player do certain things or exempt him from them. One thing I'm using this number in AOW for instance is in HUDs - with !PlayerInGame (ConsolePlayerNumber()); I can determine if the user is spectating and display different information. In menus, I have the server call clientside ACS to activate a menu on a player - knowing console player's number is needed so that the menu isn't displayed when someone else activates the menu.

Also you could use this to teleport the spectating consoleplayer to - say - midfield, which could be useful in CTF wads and stuff like that. And since in client-side scripts you're interacting with the user, knowing stats of the user (health, position, whatever) could be real useful to who knows what utility scripts.

I'd think that ConsolePlayerNumber() by itself would be enough to address most of my points but setting the activator to that lets you define ConsolePlayerNumber() in ACS and allows for more possibilities and results around equal lines of code anyway. I believe such a function could have great possibilities.
User avatar (0003925)
Torr Samaho (administrator)
2012-07-08 18:49

 I wouldn't mind having ConsolePlayerNumber(), but I think SetActivatorToConsolePlayer() is too much of a hack and could easily be used wrongly (just imagine what could happen if somebody puts SetActivatorToConsolePlayer() in an ENTER script...).

If you need more than ConsolePlayerNumber() offers we could consider introducing CLIENTSIDE CONNECT scripts.
User avatar (0004253)
Torr Samaho (administrator)
2012-08-05 08:25

 The original issue has been resolved and also ConsolePlayerNumber() has been added. In case somebody wants to have CLIENTSIDE CONNECT script (or anything else), please request them in a new ticket and we can discuss this there.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: ZzZombo Watermelon Ivan Tux Boxmanbr Dsparil Tor-Bjorn
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2012-06-25 04:09 Watermelon New Issue
2012-06-25 04:09 Watermelon File Added: ACSExample.wad
2012-06-25 11:25 Dusk Note Added: 0003850
2012-06-25 11:25 Dusk Status new => closed
2012-06-25 11:25 Dusk Resolution open => no change required
2012-06-25 15:30 Dusk Assigned To => Dusk
2012-06-25 15:30 Dusk Note Added: 0003851
2012-06-25 15:30 Dusk Status closed => feedback
2012-06-25 15:30 Dusk Resolution no change required => reopened
2012-06-25 15:31 Dusk Note Edited: 0003851 View Revisions
2012-06-26 20:40 Torr Samaho Note Added: 0003856
2012-06-26 21:48 Dusk Note Added: 0003858
2012-06-27 04:02 Watermelon Note Added: 0003862
2012-06-27 04:02 Watermelon Status feedback => assigned
2012-06-27 04:03 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 04:04 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 04:04 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 04:06 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 04:07 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 04:08 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 04:11 Watermelon Note Edited: 0003862 View Revisions
2012-06-27 11:02 Dusk Status assigned => feedback
2012-06-27 16:40 Watermelon Note Added: 0003863
2012-06-27 16:40 Watermelon Status feedback => assigned
2012-06-27 16:40 Watermelon File Added: ACSClientToServer.wad
2012-06-27 21:01 Torr Samaho Note Added: 0003864
2012-06-27 22:19 Watermelon Note Added: 0003865
2012-06-28 00:15 Watermelon Note Edited: 0003865 View Revisions
2012-07-01 09:21 Torr Samaho Note Added: 0003873
2012-07-01 09:27 Dusk Note Added: 0003874
2012-07-01 09:28 Dusk Note Edited: 0003874 View Revisions
2012-07-01 11:17 Dusk Note Edited: 0003874 View Revisions
2012-07-01 11:17 Dusk Assigned To Dusk => Torr Samaho
2012-07-01 13:15 Torr Samaho Note Added: 0003876
2012-07-01 16:21 Watermelon Note Added: 0003878
2012-07-01 16:22 Watermelon Note Edited: 0003878 View Revisions
2012-07-05 12:37 Dusk Note Added: 0003903
2012-07-08 18:49 Torr Samaho Note Added: 0003925
2012-08-05 08:25 Torr Samaho Note Added: 0004253
2012-08-05 08:25 Torr Samaho Status assigned => resolved
2012-08-05 08:25 Torr Samaho Fixed in Version => 1.0
2012-08-05 08:25 Torr Samaho Resolution reopened => fixed
2014-01-11 18:26 Qent Relationship added related to 0001656
2018-09-30 19:51 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker