The new Unity version used by Among Us 16.0.5 disables the
"InsecureHttpOption", which blocks UnityWebRequests via HTTP. Therefore
all Impostor servers should now switch to HTTPS.
https://docs.unity3d.com/2022.3/Documentation/ScriptReference/InsecureHttpOption.html
Thanks to TianMengLucky for reporting this and NikoCat233 for
identifying the cause
Among Us always adds a constant amount of roles to this dict, so it
doesn't make sense to clear this dictionary every time.
Furthermore, previously it was possible to trigger a
ConcurrentModificationException when running Deserialize in parallel
with Serialize. This should no longer happen, as new keys are no longer added
It is possible to spawn invalid network objects without an attached
PlayerInfo, and Impostor will throw exceptions everywhere if you happen
to spawn one. Officials do allow spawning objects like this, so allow it
in Impostor for compatibility reasons
For some network objects, like PlayerControl, we expect that there is an
PlayerInfo object associated to them. If there isn't, throw an exception
in this AC category
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.
miniduikboot