In Impostor 1.9.x games only started when all players had a role set.
Currently games will start when the first role is assigned, with all
other players defaulting to Crewmate, ignoring the other SetRole
commands that Impostor has not yet processed.
This commit reverts to the previous correct behaviour where SetRole
needs to be called for all players. Also ignore RoleType when
deserializing, as Vanilla roles are not nullable
Some people were confused by config-full.json, thinking that this file
should be edited too. This is not the case and the values in this file
don't apply as it was only meant as an example, so rename the file to
make that more clear.
There are various bugs in the current implementation of host-authoritive
multiplayer such that I can't recommend players to use it. Fixing these
issues on the server side is impossible, and I can't smell remotely if
clients have applied the necessary fixes. The currently known bugs
include at least:
- Unable to join more than 8 players in a room
- Unable for new players to join if host switched from host authoritive
to server authoritive
- Host is unable to kill if it is in a host authoritive game while it
thinks it is in server authoritive mode
If Innersloth fixes this mode in future game patches, this option may be
reconsidered.
Turns out they were broken when I disabled them as I wasn't tracking
playerinfo's properly, but this is now fixed, so the checks can be
re-enabled.
One issue with the ColorLimits checks is that it didn't account for mods
that add extra colors, this is fixed by checking if the route followed
is plausible instead of mimicking client logic and only accepting a
single answer that it expected. A false negative is possible where the
host decides to wrap back to the front but there are still custom colors
available at the end of the list. This is acceptable because Impostor
doesn't currently know the amount of colors available and this issue
isn't major enough to ask all mod authors to declare their custom color
amount to the server.
As extra colors should now be handled by this code, it makes sense to
change the category of the unknown colors check to ProtocolExtensions.
For these mods an exemption of the ColorLimits category is no longer
necessary.
Note that mods that allow duplicate colors that do not use a custom rpc
to set colors can only be supported by disabling the ColorLimits
category, this was already the case and I don't think it can be unified
with the existing check.
Previously Impostor liked to kill exiled players server side to raise an
event, however as PlayerInfo is now networked, it also killed players
client side. This caused meetings to immediately conclude if the final
impostor was voted out, ruining the cutscene.
So wait for hosts to actually kill the player
Looks like Innersloth added this but hasn't actually used this. Weird..
When sent it makes the new host perform a full rejoin, which gums up
Impostor's spawning logic. Fixing that causes the client to gum itself
up. Sigh.
After some testing it seems like host migration still works fine, so
this investigation wasn't needed. Comitting for posterity.
I've been carrying these in a stash for a while. They only show up when
the Debug verbosity is shown, which is intended to prevent spamming
production logs
Currently, Impostor will show an "Client is in an invalid state."
message if a player tries to join a match where the host or the joining
player is using a version unknown to Impostor.
This message confused a *lot* of people, so this PR changes the API such
that if the version is not registered, the version itself is put in a
compatibility group and compared, assuming no other game versions are
compatible with it. This works fine in most cases, as Among Us network
versions generally increase over time.
Failure on 2222.2.2 (which is ancient at this point, so likely no longer
used) and future cases where Innersloth messes up (which is unlikely) is
an acceptable consequence to me.
When a player is kicked or banned from a game, the client is expected to
disconnect in response. When they decide not to *or* the disconnect
packet is lost, Impostor just silently disposes of the connection.
This does not remove them from ClientManager, which is how I tracked
this bug down.
By sending them a proper disconnect message, clients should have
received *a* disconnection message before dropping their connection.
Future work should split this entire method in removing players from a
game and processing kick/bans because the latter feature is not relevant
for other callers of this method.
Multiple guard clauses make the file harder to navigate, so put them in
a single guard clause with one validation rule per line. Some statements
in the file were already set up like this, so this commit makes it consistent
When a game has just been created, it does not yet have any players in
them, and as a result you can't get the host or its connection id when
this event is called. This makes it annoying to link between this event
and the IGameCreationEvent that came just before it.
Having this link is useful for the usecase of a game code allocation
plugin that allocates codes from a pool, and needs to return codes to
a pool if these codes weren't picked.
* Add extra configuration options for the anticheat
* Implement option to exempt hosts from AC checks
* Add AntiCheatConfig to InnerNetObject and friends
* Categorize calls in InnerNetObject.Anticheat
* Categorize other calls to ReportCheatAsync
* Update cosmetics AC handling
When Innersloth changed SetHat etc to SetHatStr as part of the cosmicube
update we accidentally created a few dead methods. Restore and update
the code.
* Push up cheat category to ReportCheatAsync
This makes it possible to log failed checks for diagnosis. Also much
cleaner now that we don't have to push AntiCheatConfig everywhere.
Should've done this immediately q.q
* Add back old version of ReportCheatAsync
some plugins used this method. affected plugins should rebuild after the
next impostor release
* Add documentation for modular anticheat
* Address comments
* Sort AntiCheatConfig keys
* Rework the option to allow cheating hosts
This option should actually be tristate: to not break host-only mods we
should disable the anticheat for hosts running host-only mods.
* Document CheatingHostMode
* Split Limits category in Color and Name Limits
- Update versions to the latest one
- Get rid of .gitmodules as we dumped that years ago
- Change ::set-output to output files as the former is slated for removal
We see that a lot of support tickets are caused by this default setting,
as it is one of the things that blocks connections to the server with no
obvious indication that this is happening. To make it easier for first
time users to set up Impostor, it is important that this setting is
changed.
Previously we also recommended against direct exposing due to security
reasons, but I believe this fear to be unfounded: Microsoft claims that
the Kestrel server is hardened against web server vulnerabilities and
supports its use both with and without a reverse proxy.[1]
We still recommend using reverse proxies if HTTPS support is needed, so
that section of documentation still remains. Setting the ListenIp to
127.0.0.1 is still recommended when using a reverse proxy to remove the
ability for people to connect directly, so we add it there as a recommendation.
[1]: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-8.0
This RPC is still sent by clients, but no longer used by clients. As the
server can get the info it wants from LogicOptions instead, remove this
RPC to prevent people from using it accidentally
This can be triggered by both RPC 02 and a(nother) plugin calling
SyncSettings to force certain settings on the host. Users of this API
could cause this event to recurse by calling SyncSettingsAsync inside an
event handler, so we prevent such reasonable foreseeable misuse.
In games where players have a high ping, they can get disconnected if
they try and murder a player twice. If a player tries to kill a player
again while they are still under a cooldown from their previous kill,
cancel their request if the game is server authoritive and don't process
it anymore if the game is host authoritive