Last updated: 06/04/2023 - Changelog
Maintainer: Abu
Contributors:
- (WTH) Abu
- [HLL Fr] Dr.WeeD / Maresh
- NoodleArms[BEER] / emathey
- [1.Fjg] FlorianSW
- [1CDO] Delphium
- 106.| Moooooritz
The purpose of this document is to summarize what items are currently wished for by the people developing tools for their own and/or wider community. As such, the primary focus is RCON changes or additions. These are topics too complicated for the average player to understand the meaning or implication of, and as a result you won't see these requested often if at all. But do note that these requests are not just intended to make our lives as developers of these tools easier, but directly impact the experience for players and server admins in a positive way that may not always be obvious to all. To assist with that, all items have been assigned a priority, based upon how impactful the requested changes would be.
We hope this document can be used internally by Team17 to better understand our needs and prioritize their tasks accordingly. Included are examples of what we hope the request and response can look like, and where applicable also the motivation behind a suggestion. If proposed behavior has to be deviated from, or a suggestion likely will not be implemented for any reason whatsoever, we would appreciate if we could be notified and where possible find a compromise.
Legend:
🔴 - Incredibly helpful
🟠 - Great to have
🟢 - Nice to have but not very important
Some topics are intertwined. By implementing the requested changes from one topic, another topic's importance may lower.
The current protocol has one major drawback, which is that requests and responses should not and thus do not contain any headers. These headers would be used to provide metadata about the response, which can be used to validate a packet's completeness, and pair responses to requests.
This means a couple of things:
- You can much more reliably receive data from the protocol, knowing whether a response is complete or not.
- Requests can be parallelized. Previously the server would often combine multiple commands sent into one unknown command and yield a FAIL.
An easier alternative would be to simply end every request and response with EOF or similar.
While it would be ideal for the protocol itself to be adjusted, if for whatever reason that's not feasible, a minimum viable solution would be to add something at the end of the ShowLog command to determine its completeness.
Related:
🟠 (BUG) When a player's name is longer than 20 characters and the 20th character is a space, the server is unable to identify that player via their name.
🟢 (BUG) Themessagecommand will fail if the passed name contains a space
Most commands exclusively accept a player's name as input, however Steam IDs are much more reliable. Due to a bug, when the 20th character in a player's name is a space, this causes most commands to fail and this player to go almost entirely unnoticed and be invincible. There is another case that is even more severe, which I will intentionally not cover here as it would be catastrophic were it to surface.
There are currently three commands which support both name and steam ID, which are the PermaBan, TempBan, and Message commands. However, there is a bug with the Message command (see related topics).
Related:
🟠 The ability to predetermine the point layout of the next match
A long-standing wish for server owners and event organisers has been the ability to apply basic modifiers to the "vanilla" game in order to create unique gameplay experiences. Some examples of what could be included:
- Damage multiplier
- Movement speed multiplier
- Disabled roles and weapons
- Disabled squad comms
- Initial resources
- Ability costs
- Respawn times
- Pre-defined point layout
There's various ways how this could be implemented. They could each be their own command, or they could be special parameters passed when adding the map to the rotation.
This suggestion was denied a while ago, because players should get a consistent experience that is the same for everyone. However we want to kindly ask this stance to be reconsidered. Other than the benefits mentioned earlier, a new filter could be added to the server browser to hide any servers using any of these gameplay modifiers.
Related:
🔴 Include the distance someone was killed from in the kill logs
🔴 A log line sent every minute that shows the current TPS. This is useful for determining how well a server is performing.
🟢 Swap prettified map names inMATCH START/MATCH ENDEDlogs with the actual map name
- Suicides and redeploys
SUICIDE: Player(Allies/012345678901234567) with MK2 GRENADE
- Objectives captured
OBJ CAPTURED: Axis captured 'Hospice' (2 - 3)
- Players downed
DOWNED: Player1(Allies/012345678901234567) downed Player2(Axis/012345678901234567) with M1 GARAND
- Players revived
REVIVED: Player1(Allies/012345678901234567) revived Player2(Allies/012345678901234567)
- Vehicles destroyed
VEHICLE DESTROYED: Player(Allies/012345678901234567) destroyed Tiger with Satchel
VEHICLE DESTROYED: INACTIVITY destroyed Tiger
- Structures built (spawnpoints, fortifications, supplies/ammo)
STRUCT BUILT: Player(Allies/012345678901234567) built Bunker
STRUCT BUILT: Player(Allies/012345678901234567) built TruckSupplies
- Structures destroyed
STRUCT DESTROYED: Player(Allies/012345678901234567) destroyed Garrison with Bazooka
- Unit created
UNIT CREATED: Player(Allies/012345678901234567) created ABLE
- Unit changed
UNIT CHANGED: Player(Allies/012345678901234567) switched from None to ABLE
- Role changed
ROLE CHANGED: Player(Allies/012345678901234567) switched from 'Rifleman' to 'Officer'
- Warmup phase ended
WARMUP ENDED
Right now the PlayerInfo command only works on individual players, yet its information is incredibly useful to have for all players. Unfortunately calling a command 100 times is very time and resource intensive and thus not feasible in most situations.
The proposed solution is a new command, Get AllPlayerInfo, which returns an array with each of its entries being the same as running PlayerInfo on a player.
While at first thought this may seem like a statistic purely for fun, it may prove very helpful when detecting cheaters. Plus, it sounds like an easy thing to implement.
KILL: Player1(Allies/012345678901234567) -> Player2(Allies/012345678901234567) with M1 GARAND from 123m
Being able to tell if something was a headshot would be nice as well, or if we're really digging deep, the specific limb.
KILL: Player1(Allies/012345678901234567) -> Player2(Allies/012345678901234567) with M1 GARAND from 123m (Body)KILL: Player1(Allies/012345678901234567) -> Player2(Allies/012345678901234567) with M1 GARAND from 123m (Head)
🔴 A log line sent every minute that shows the current TPS. This is useful for determining how well a server is performing.
Related: GSP and server issues, self-hosted servers
When dealing with server performance issues we have no metrics to go by. With us being able to monitor the ticks per second on a server we should be able to determine whether a server is underperforming a not and set a baseline expectation with server providers.
TPS: 18.36
Pretty self-explanatory. Being able to set, change, or remove a server password without needing to restart would be a huge QoL change for server admins.
ServerPassword [new-password]
Such a server would be incredibly helpful when testing out any changes that have to be made to our tools to ensure everything is operational at the day of release, without us needing to scramble together without being able to properly test it.
As per U13, the map rotation works with an incrementing value, or cursor, pointing to an index in the map rotation. This now allows multiple instances of the same map to be added to the rotation, however the commands are unnecessarily complicated. Plus, it is near impossible to determine with 100% accuracy where in rotation the server currently is, which in return makes it impossible to accurately set the next map without messing with the rotation in several places.
In U14, these commands received additional unexpected changes making the issues significantly worse, as the old behavior no longer works and you are forced to provide a whole bunch of unnecessary parameters. So, the following changes are proposed:
-
Add a command to see at what index the rotation currently is.
Get MapIndex-> Any number 0 or above -
Change the
RotAddcommand to give it an optionalindexparameter to determine its placement in the rotation:RotAdd <map-name> <after-map> <after-map-ordinal>->RotAdd <map-name> [index] -
Change the
RotDelcommand to allow the use of indexes:RotDel <map-name> [map-ordinal]->RotDel (<map-name>|<index>) -
Add a command to change where the cursor is pointing, allowing you to continue the rotation in a different position:
NextMap (<map-name>|<index>)
Some other unrelated but convenient changes:
- Force server admins to use full paths in their MapRotation.ini config file, to prevent them unknowingly breaking all rotation-related commands.
- Or even better, just have RCON accept map names without their path. As long as all map names are unique, identifying their location in the game files should be super simple.
- Add a command to replace an entire rotation:
SetRotation <comma-seperated-maps> - Allow changing the map without it having to be in rotation
- Drastically reduce the 60-second-timer when changing maps, and/or allow it to be canceled
KickFromUnit <player>
For convenience, a command to disband an entire unit would be quite useful too. This would be the same as running a kickfromunit command on each of the players in said unit.
DisbandUnit <team> <unit>
🟠 More elaborate error messages. Currently when a command fails it returns FAIL, however it would be more intuitive if it also included why it failed, for instance FAIL : No player found.
As a side note, the RotAdd and RotDel are (the only) commands that already do this. Yet they don't include the FAIL at the beginning. Having those there is highly important however, otherwise it becomes very difficult and in some cases even impossible to tell whether the command actually failed or not.
Related:
⚠️ Add packet headers to protocol requests and responses / add EOF to responses
MessageAll <message...>
Bonus points for a command to message an entire squad or team.
Related:
⚠️ (GAMEPLAY) Game modifiers
Either of the following:
NextMapLayout <randomization-seed>
NextMapLayout <5-number-sequence>
Related:
🟢 Include a player's clan tag in thePlayerInfocommand
The player's current position on the map, respresented by a Vec3, should be included in the response of the PlayerInfo command. Being able to tell where a player is would be an interesting metric and could help with automated seeding enforcement or detecting cheaters.
🟠 (BUG) When a player's name is longer than 20 characters and the 20th character is a space, the server is unable to identify that player via their name.
The game truncates names longer than 20 characters. If the 20th character in someone's name happens to be a space, that means their truncated name will end with a space. Using this truncated name will always yield a FAIL. This isn't as big of a deal if steam IDs could be used instead of names.
There is another case somewhat similar to this which I won't publicly cover here as it is even more severe than the issue above. It has been reported as a bug years ago and the fact that nothing has been done about it is genuinely worrysome.
🟢 The ability to customize how the automatic teamkill kick behaves (modify the threshold and punishment)
Doesn't have to be a RCON command, something in an .ini file would suffice.
Related:
🟠 Include a player's current position in thePlayerInfocommand
Could be used to schedule a restart (the GSP's service manager will automatically restart it) via RCON, either because the GSP doesn't allow configuring scheduled restarts or because you want to automatically send messages to players prior to the server restarting.
StopServer
Get Msg
This probably would be part of the PlayerInfo command.
Unit: 3 - DOG
Would become
Unit: 3 - DOG - Unlocked
If a kick or ban reason contains newlines, the corresponding log line when that player gets booted off of the server will occupy several lines in the response of the ShowLog command, making it difficult to be parsed accurately. Make it so when sending that log all newlines get escaped (\n -> \\n).
The "pretty" map names are not as descriptive. It does not tell you which team attacked on Offensive, or whether a map was a night map or not. There's a few inconsistencies as well, with some maps being formatted differently.
MATCH START SAINTE-MÈRE-ÉGLISE OFFENSIVE->MATCH START stmereeglise_offensive_ger
Not all maps follow the format guidelines set by the vast majority of other available maps. Proposed are the following changes:
hurtgenforest_warfare_V2->hurtgenforest_warfarehurtgenforest_warfare_V2_night->hurtgenforest_warfare_nighthurtgenforest_offensive_US->hurtgenforest_offensive_ushill400_offensive_US->hill400_offensive_usstmariedumont_off_us->stmariedumont_offensive_usstmariedumont_off_ger->stmariedumont_offensive_gerdriel_offensive_us->driel_offensive_gbelalamein_offensive_CW->elalamein_offensive_gb
If you want to set map shuffle on or off, at the moment, you have to first query what the current value is, and then toggle it. This is super inconvenient and inconsistent with how other commands behave. The following behavior is proposed:
GetMapShuffleEnabled->(1|0)
SetMapShuffleEnabled (1|0)->SUCCESS
The Get GameState command shows the amount of players online on each team. However, when there are 0 players online on any team, for one of the two teams it will show that 1 is still online.
This can happen when no players are online, but also when players are in the team select screen, who will also experience this issue.
The message command is one of the few commands that accepts both a player name and steam ID. However, if the name contains a space, the command will always fail. This happens despite having wrapped the name in quotes.
message "A Player" test message->FAIL
Whenever a ban is removed, it still seems to linger around in the response of the Get TempBans command as an empty entry in the array. So for instance, you may get an array of 10, but only 6 of them are ban details, whereas the other 4 are an empty string.
Whenever VIP or any Admin role is granted, the Steam ID that you pass along that this new status will be associated with is not validated. This means that anything can be sent and the game server won't stop you. Not filling in anything as SteamID, like VipAdd "A name" works too, which adds a VIP that cannot be removed!
- Updated legend
- Added 🟢 Being able to see whether a unit is locked
- Updated preface
- Added mention of an even worse case of invalid name
- Added the logging of headshots to 🔴 Include the distance someone was killed from in the kill logs
- Updated 🟠 Map rotation enhancements to include new issues and required changes
- Added additional map names to 🟢 Unify map identifiers
- Added 🟢 Redesign map shuffle commands
- Slightly expanded or reworded a few items here and there