Implement GetHashCode()
Fix Equals doing reference equality on the attributes.
Small code cleanup.
Actually mark it as IEquatable<MarkupNode> because we already implement Equals() so there's no reason not to.
* Don't rely on client for grid fixture rebuilds
Server is already networking fixture data and this has a chance to go bad.
Easier to just stop this entirely and remove the fixture references to just network the relevant ones for each chunk. Performance impact should pretty much be non-existent and it should be less buggy.
* a
* weh notes
* fix aabb update
* Fix AABB gen
* weh
* More networking
* V1 commit
* V2 Commit, ObjectSerializer
* Make sure write for objects have the !type:<T> set
* Added AppearanceDataInit
* Change to AppearanceDataInit setting to AppearanceData the moment it itself gets set; ComponentInit is too late. Forgive me sloth.
* RELEASE-NOTES.md
* Fix release notes
* Fix release-notes for realsies
In profiles of RMC-14, encrypting network messages accounted for ~8% of main thread time. That's a lot.
Each NetChannel has an "encryption channel" which gets processed on the thread pool.
It is our suggestion for a long while to keep the TPS at 30 for servers. However the default was always 60.
I believe its better to have it as a default.
* Make PhysicsHull a ref struct
First time I've used it but seemed like a good candidate considering it's temporary.
* weh
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
* Clamp audio tickrate
I am reasonably sure I saw a recommended 30TPS figure somewhere but I cannot find it again. At any rate I can't notice this but imagine it provides significant benefits for people on 144hz+ monitors.
* rn
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
* Strongly order network prototypes and resources.
When a new client connects, both the uploaded prototypes and resources get sent at once. There was no ordering here, which means that prototypes could easily load before resources. This would then obviously give load errors at runtime. In practice though this seemed fine because the RSI or something would just load fine after when spawned or something.
This was then broken by ae1051e813, which made ResourceCache start caching "that RSI doesn't exist" so it never really tried again.
I originally tried to fix this by adding an API to IResourceManager that allows content to invalidate the aforementioned cache (commit 316a7e4ac10100593202ff7f53dc2992611bbd1e, for however GitHub will track that) but then realized resource uploading isn't part of content like I first thought. Lol whoops. That API might still be useful for other dynamic content use cases, but I'm not committing it for now. That fix still caused errors to be spammed if the prototype was loaded before the resources were ready.
The new fix is to just load resources before prototypes. This is done by making them both ordered relative to each other, and running resources first.
Fixes#5291
* Release notes
* Entity console commands system.
This adds a new base type, LocalizedEntityCommands, which is able to import entity systems as dependencies. This is done by only registering these while the entity system is active.
Handling registration separately like this required a bit of changes around ConsoleHost to make it more suitable for this purpose:
You can now directly register command instances, and also have a system to suppress `UpdateAvailableCommands` on the client so there's no bad O(N*M) behavior.
* Convert TeleportCommands.cs to new entity commands.
Removes some obsoletion warnings without pain from having to manually import transform system.
* Fix RobustServerSimulation dependency issue.
---------
Co-authored-by: metalgearsloth <31366439+metalgearsloth@users.noreply.github.com>
Content has multiple cases where AnimationCompletedEvent is used to loop an animation. #5238 broke some of these by making this event raised even when manually removed.
Luckily most cases in content tie the animation looping to the presence of a component, so the component getting removed means there's nothing to refresh the loop. LightBehavior is not as fortunate however, causing bugs like https://github.com/space-wizards/space-station-14/issues/29144
This boolean allows looping code to properly distinguish the event, so it won't try to restart an animation after removing it directly.
Pieter-Jan Briers