MantisBT - Zandronum
View Issue Details
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.
Steps To Reproduce
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.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2017-05-28 07:50throwawayNew Issue
2017-05-28 08:06FusedNote Added: 0017770
2017-05-28 08:12throwawayNote Added: 0017771
2017-05-28 08:12throwawayNote Edited: 0017771bug_revision_view_page.php?bugnote_id=17771#r10662
2017-05-28 10:50DuskNote Added: 0017772
2017-05-28 10:50DuskStatusnew => feedback
2017-05-28 15:28KorshunNote Added: 0017776
2017-05-28 19:13Torr SamahoNote Added: 0017780
2017-05-29 20:58throwawayNote Added: 0017789
2017-05-29 20:58throwawayStatusfeedback => new
2017-05-29 21:31throwawayNote Edited: 0017789bug_revision_view_page.php?bugnote_id=17789#r10670

Notes
(0017770)
Fused   
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.
(0017771)
throwaway   
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.
(0017772)
Dusk   
2017-05-28 10:50   
This can very easily be implemented with a few scripts. Why does this have to be an engine feature?
(0017776)
Korshun   
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.
(0017780)
Torr Samaho   
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.
(0017789)
throwaway   
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?