Zandronum Chat on our Discord Server Get the latest version: 3.1
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
0003147Zandronum[All Projects] Suggestionpublic2017-05-28 07:502017-05-29 21:31
Reporterthrowaway 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version3.0-beta 
Target VersionFixed in Version 
Summary0003147: New ACS function for a monotonic player number
DescriptionRight now, I'm struggling with the problem of player numbers potentially referring to a different player than existed at the time the player number was read. For example, if player 0's player number was stored in an ACS array, he disconnected, and a new player filled the spot, that ACS array would now refer to a completely different player.

Similarly, a player spectating and rejoining could now be an entirely different player under entirely different circumstances, but the array still points to them.

This is easy enough to handle on your own when the issue only pops up in a couple ACS arrays, but it's much harder to handle when the player numbers get scattered everywhere, including in multiple ACS modules and in the inventories of actors (using counter items) with unknown TIDs.

This is why I was thinking of a monotonic player number, which would be the amount of times the game had been entered before a given player. For example:

- Player 1 joins an empty game that no one has entered yet. His PLN and monotonic PLN are both 0.
- Player 2 joins the game. His PLN and monotonic PLN are both 1.
- Player 1 disconnects.
- Player 3 joins the game. His PLN is 0 since no one's occupying it, but his monotonic PLN is 2, since the game had been entered 2 times before.
- Player 2 spectates and rejoins, possibly because he's stuck and the kill command is disabled. His PLN remains 1, but his monotonic PLN is now 3 since the game had been entered 3 times before.

This way, a monotonic player number would always refer to a specific player session, or no one. There'd be no chance of carrying over data to a different player session on accident. ZDoom already has this guarantee, as you can't join the game mid-session there, and as such this request makes no sense there.

This wouldn't solve every issue, but those issues are mostly related to storing data for each player in ACS, and can be handled with DISCONNECT scripts (or using inventory items) as is. For issues where you merely need to store a player number and want to be sure it won't refer to a different player later on, this would be perfect.
Additional InformationThe implementation I was thinking was simply this:

- UniquePlayerNumber() - returns the monotonic player number of the activator.
- MapUniquePlayerNumber(int upln) - returns the player number associated with a monotonic player number.

I would have the monotonic PLN counter reset with ACS global variables. Player numbers are already a massive pain in the ass (if not outright impossible) to keep track of between maps in a hub without mixing up players - monotonic player numbers should be free from that.

ZDoom would just make UniquePlayerNumber() an alias for PlayerNumber(), and MapUniquePlayerNumber() an identity function.
Attached Files

- Relationships

-  Notes
User avatar (0017770)
Fused (reporter)
2017-05-28 08:06

 So basically a playernumber that only increments and doesn't take any free spots before it? Sounds very useful actually.
User avatar (0017771)
throwaway (reporter)
2017-05-28 08:12
edited on: 2017-05-28 08:12

 In retrospect, it should be based on the amount of times the game has been joined.

The difference would be that exiting a map and going to the next one wouldn't change your monotonic player number, since you didn't rejoin. If it's based off entering, it would change - and would change the first time you enter any map in a hub, completely defeating the purpose.
User avatar (0017772)
Dusk (developer)
2017-05-28 10:50

 This can very easily be implemented with a few scripts. Why does this have to be an engine feature?
User avatar (0017776)
Korshun (reporter)
2017-05-28 15:28

 Apparently, the reporter wants this feature to keep track of player numbers between maps in a hub and says it can't be done because moving between maps in a hub wrecks player numbers. I was not aware of this behavior and haven't verified it.
User avatar (0017780)
Torr Samaho (administrator)
2017-05-28 19:13
Quote from throwaway

Player numbers are already a massive pain in the ass (if not outright impossible) to keep track of between maps in a hub without mixing up players - monotonic player numbers should be free from that.

Can you elaborate? IIRC "changemap" map changes shouldn't change player numbers.
User avatar (0017789)
throwaway (reporter)
2017-05-29 20:58
edited on: 2017-05-29 21:31

 >This can very easily be implemented with a few scripts. Why does this have to be an engine feature?

How would you make sure a player keeps the same monotonic player number through map changes? Enter scripts can't differentiate between someone joining the game and someone who was already in the game when the map started. Disconnect scripts don't run if you disconnect or spectate while the server is on the scoreboard. Inventory items don't carry over to, say, the next map in deathmatch. All of those would break an ACS implementation.

Keeping track of this would also require an ACS library in LOADACS, which is needlessly cumbersome for people who just want to be sure they won't reference the wrong person when calling SetActivatorToPlayer (when that gets into a stable build) in their maps.

Also, I've found out that spectating and rejoining in the same tic will have your ENTER script run *before* your DISCONNECT script, complicating efforts further, but that's another issue.


>Can you elaborate? IIRC "changemap" map changes shouldn't change player numbers.

The problem is that there it's impossible to guarantee that player 2 when leaving the map is the same player 2 when returning to the map, and there's no real way to handle that within a map script. ZDoom doesn't need to worry about this since players can't join mid-game - player 4 will always either be player 4, or not exist anymore. Having a player number for Zandronum with the same guarantee would make it much easier to not accidentally carry things over to the wrong player.

edit: To clarify that further; it's not that player numbers get shuffled, but that someone can disconnect and someone else can take that slot while on a different map in the hub, and the map has no foolproof way of knowing.

Actually, come to think of it, do RETURN scripts fire for everyone upon returning to a map, or do players who actually haven't been in the map yet fire off ENTER scripts?

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: Fused Dynamix
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2017-05-28 07:50 throwaway New Issue
2017-05-28 08:06 Fused Note Added: 0017770
2017-05-28 08:12 throwaway Note Added: 0017771
2017-05-28 08:12 throwaway Note Edited: 0017771 View Revisions
2017-05-28 10:50 Dusk Note Added: 0017772
2017-05-28 10:50 Dusk Status new => feedback
2017-05-28 15:28 Korshun Note Added: 0017776
2017-05-28 19:13 Torr Samaho Note Added: 0017780
2017-05-29 20:58 throwaway Note Added: 0017789
2017-05-29 20:58 throwaway Status feedback => new
2017-05-29 21:31 throwaway Note Edited: 0017789 View Revisions




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker