Approved Full information replays for Random Battles

Presently, when viewing a replay, you can only see information that both players would know at that point in time. For example, if you hover over a Pokemon on turn one, it doesn't tell you any of the moves that that Pokemon knows. In Random Battles, this is particularly noticeable as unrevealed Pokemon also stay hidden in replays.

My suggestion is to enable full-information replays such that after the battle has ended, a spectator can see all the Pokemon on each team as well as what moves, stats, abilities, and items they had.

There are a few motivations for this:

1. After I play a Random Battle, in order to reflect on the choices I made, I'd like to be able to see the other unrevealed Pokemon I had left if I don't remember what they were.
2. I'm interested in studying other people's battles and choices, but I can't put myself in their shoes if I can't see what information they had at that time since it's hidden to me.

I can think of two drawbacks to this suggestion:
- Implementing this would require that the server stores each entire team for every replay rather than just a log of moves.
- If someone was trying to keep parts of their team secret in a competitive setting.

If the first drawback is a deal-breaker, I can think of two alternatives:
- Allow full-information replays for only the players in the battle, this way the client would just have to store the team until that battle was closed and the server wouldn't have to store it post-game. This would still satisfy motivation #1 even though it wouldn't satisfy motivation #2.
- The server could store full team data only for replays that had been used recently and forget the team data for old replays to save space.

My response to the second drawback is that people who want part of their team to be secret, generally want their entire team to be secret. As a separate feature, implementing private battles such that no non-participating user can view the replay would satisfy that use-case without blocking this feature.

I think implementing this suggestion would be a great idea and I'm happy to explore alternatives if there's something wrong with it.
 

Hecate

Be the serpent under't
is a Battle Simulator Administratoris a Community Leaderis a Programmer
PS Admin
My response to the second drawback is that people who want part of their team to be secret, generally want their entire team to be secret. As a separate feature, implementing private battles such that no non-participating user can view the replay would satisfy that use-case without blocking this feature.
this exists. Hiding the battle (using any of the commands /ioo, /modjoin + <or %>, /hideroom, or /ionext) will also hide the replay unless the battle is unhidden before it’s saved.
The main problem with full team info that I see is that these have been bypassed before, unfortunately, through various means (not to mention one of the players just sharing the link) which means all info in a replay is then vulnerable.
 
It seems like a bug that people who have the link to a private battle can still view the battle. If you weren't a participant you shouldn't be able to view a private battle, no?
 

Hecate

Be the serpent under't
is a Battle Simulator Administratoris a Community Leaderis a Programmer
PS Admin
no, it's intended - so players can still link the battle to friends and others they may wish, while also making sure it isn't available to any random browser
 
What if, for private battles, you can only see full team data for the player(s) who have clicked "Upload and Share Replay" and for those who haven't you see only derived information? That would be giving away as much information as we give away today for people who don't want to give information away, but for people who don't care, we'd then support the full team data.
 
Why can't we require asking the opponent for permission in order to save a full information replay? This way you can only save a regular replay if either player doesn't want a full information replay.
 

pre

pkmn.cc
As you can see from the code, Random Battles already log full information replays once the battle is ended (including the input logs), as do custom games. In all other cases the replays are saved from a spectator's perspective (private vs. public replays do not make a difference with respect to what information is revealed.) - ie. no information about teams is leaked. I don't see us supporting full information replays for non random formats.
 
This is not true in practice. After a random battle, neither player can see unrevealed information in the replay. Look at this replay https://replay.pokemonshowdown.com/destiny-randombattle-572765

At the start, all Pokemon on both teams are hidden in Pokeballs. After the first Pokemon is revealed, it's moves are unknown. After the battle is over, there are still unrevealed Pokemon that you can't see as a spectator. Maybe we have a different understanding of what full-information replay means. To me it means that at the start of the battle, as well as throughout the battle, you can see all the Pokemon for each player as well as all they're moves, items, and abilities.
 
Presently, neither replay.pokemonshowdown.com nor play.pokemonshowdown.com show full information replays for random battles or for team battles. Are you saying that because the client already receives the full information, that this is just a UI issue? Even if it's just a UI issue preventing this from happening, it's still not happening, so "Done" seems like a misnomer here.
 

pre

pkmn.cc
You mean you want the UI to display omniscient replays for formats where the full state is reconstructible (I don't know what you mean by 'team' battles, but this isn't something we'd be supporting in a format where teams are not randomly determined)? That is not 'Done', you are correct. To get this to happen you would need to:

- use the seed present in the inputLog to regenerate the team, either in the replay server (which would be awkward because the team generators are in JS and most of the replay logic is in PHP) or on the client (which isn't really an option under the server codebase is modularized and the team generator is packaged separately so it can be used as part of the client bundle, pointing to doing it server side being a better approach).
- possible changing the replay viewer logic to understand omniscient replays. It may or may not already understand them, IDK

I'll mark this as 'Approved' then for Random Battles et al, but its not exactly trivial.
 

Zarel

Not a Yuyuko fan
is a Site Content Manageris a Battle Simulator Administratoris a Programmeris a Pokemon Researcheris an Administrator
Creator of PS
You mean you want the UI to display omniscient replays for formats where the full state is reconstructible (I don't know what you mean by 'team' battles, but this isn't something we'd be supporting in a format where teams are not randomly determined)? That is not 'Done', you are correct. To get this to happen you would need to:

- use the seed present in the inputLog to regenerate the team, either in the replay server (which would be awkward because the team generators are in JS and most of the replay logic is in PHP) or on the client (which isn't really an option under the server codebase is modularized and the team generator is packaged separately so it can be used as part of the client bundle, pointing to doing it server side being a better approach).
- possible changing the replay viewer logic to understand omniscient replays. It may or may not already understand them, IDK

I'll mark this as 'Approved' then for Random Battles et al, but its not exactly trivial.
It should be close to trivial. I think it was already implemented in the past; and if it's not currently being done, that's a regression that should be pretty easy to pinpoint.

Here's where it's implemented:
https://github.com/Zarel/Pokemon-Sh...0dd7d7c9b14a4aa/server/chat-commands.js#L4077

There's no need to regenerate the replay – PS already tracks omniscient logs, and the replay player can already handle them.
 

Users Who Are Viewing This Thread (Users: 1, Guests: 0)

Top