Force(.*)Async will perform the same function as \1Async but without
throwing exceptions. The old API is maintained for backwards
compatibility reasons.
Murder checks are now shared with the main function that handles
CheckMurder, as ProtectPlayerAsync and ExileAsync aren't used in the
code I didn't make a similar change there. Checks were also synced
between both methods
This prevents situations where a player that requested red has a
different color when rejoining because red is the default color of a
PlayerInfo object. This is most noticeable if the host is late with
rejoining, and a lot of players are alreading in WaitingForHost limbo.
When the host finally rejoins, they will not assign Red immediately to
players that requested Red as it is "in use", and instead assign the
next color.
By recording and restoring this is avoided, and players tend to get
their own colors back in most cases.
This is not something that officials do at the moment, but I don't think
this has an impact on mods, as a normal checkcolor/setcolor cycle will
take place as usual.
These are no longer used, so warn people who do want to edit them.
I don't foresee these getting removed soon though, as we do want to kick
players on old versions for having an old game version
To prevent needing to pull in Impostor.Hazel, use an extension method
instead.
Thanks Niko for researching this part
Co-Authored-By: Niko233 <139348239+NikoCat233@users.noreply.github.com>
* Add diagnostic message to test HTTP server
This makes it possible to diagnose if the reverse proxy setup is working
correctly or if the game configuration is wrong
* Print console log as well
Only print it once to prevent console spam
* Update src/Impostor.Server/Http/HelloController.cs
Co-authored-by: js6pak <me@6pak.dev>
---------
Co-authored-by: js6pak <me@6pak.dev>
I've checked Impostor for issues that are similar to #664, and found
this one: if mods add a custom rpc on PlayerPhysics, Impostor will check
ownership of it, which isn't intentional.
Mods may send RPC's on a ShipStatus that aren't broadcasts. Previously
Impostor would forbid that, which doesn't make sense to me. By moving
down the check it'll allow mods to broadcast RPC's on ShipStatus.
Reported-By: xtracube
When a client disconnects without ever having joined a game, it leaves
behind an empty game on the server. Remove these when a player
disconnects.
Co-Authored-By: js6pak <me@6pak.dev>
* implemented the sequence ID
* implemented the sequence ID for the player outfits
the sequence ID in the set call must be greater than that stored on the client otherwise the client disregards the set call.
* make sequence IDs internal
* added space after closing brace
* make the sequence ID addition +5
Base game doesn't have a specific message for it so it results in a generic "left the game due to error" but it's still better than the default "left the game".
This also allows client side mods to fix the message.
DisconnectReason.Hacking has been broken in base game for a long time so replace it with a custom message.
Also add a random support code for easier debugging in case of false positives.
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.
This commit does what official servers do:
- despawn the PlayerInfo if someone disconnects while in the lobby
- despawn all PlayerInfos at the end of a game when the EndGame screen
is shown. At this point a lot of other netobjects are destroyed as well,
with the PlayerInfos generally done first.
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. Committing for posterity.
Co-Authored-By: js6pak <me@6pak.dev>
In 2024.6.18 Innersloth changed the storage location of the PlayerName
from PlayerInfo to PlayerOutfit. If we don't set the PlayerName, we'll
send an incomplete PlayerInfo to new players, so new players are unable
to stay connected as they will not receive complete PlayerInfo objects
before a timeout in the client activates.
Because we publish PlayerName in the API, we can't completely remove
the PlayerName field from PlayerInfo. We also use it internally in a few
places, so I don't this is worth removing.
As tasks used to be part of the GameData, 2024.6.18 has moved them to
the PlayerInfo. Because they are now called on the PlayerInfo of the
correct player, the playerId field in the RPC is no longer necessary.
2024.6.18 adds a NetId field *in front* of the existing fields to help link back to the PlayerInfo. We don't actually need this NetId and assume it's called on the correct PlayerControl, so we ignore it.
In 2024.6.18 Innersloth promoted PlayerInfo to its own network object, and gave it to the server. InnerGameData is now a container that holds these players. This commit implements the changes necessary to handle these separate PlayerInfo network objects.
miniduikboot