forked from Impostor/Impostor
-
Notifications
You must be signed in to change notification settings - Fork 0
Up stream #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Up stream #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
I've checked Impostor for issues that are similar to Impostor#664, and found this one: if mods add a custom rpc on PlayerPhysics, Impostor will check ownership of it, which isn't intentional.
* 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>
Creating a game is now possible
This is used in the new "Enter Code" flow 3 extra fields are added to GameListing, including a Base 64 serialization method for game options
Innersloth also forbids it, and it's likely not possible due to the new GameOption version
At this point it doesn't seem necessary to drop support for old Amoguses, so just bump the minor version for support purposes
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>
Co-Authored-By: Niko233 <139348239+NikoCat233@users.noreply.github.com>
The game ignores unknown fields when deserializing, and as only fields were added it's acceptable to merge the structs together
Can't be generated from game files at the moment unfortunately
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
Add support for 16.0.0
Crossplay with the previous version is not supported, so it gets its own compatibility group. Further analysis on the changes is still needed
Add 16.0.5 support
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.
Because it's only restored in standard SA networking, the stored value will be ignored in HA. This is preferred to logging when in HA mode
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
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
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
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
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
…tory Update docs to add that HTTPS is now mandatory
Fixes compile warning
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Closes issues