The way SDL handles window coordinates passes through the native platform API's behavior instead of trying to make a consistent API, so the way sizes are handled on macOS is different.
The analyzer was built to go off syntax nodes. This (AFAICT) meant that the SemanticModel had to be recalculated for every single invocation.
If you don't know what the above means: it basically means the compiler has to re-analyze the entire file.
Fix this by moving it to an operation analyzer so the compiler can properly cache the semantic model.
* Add ProfManager.Value guard, write first command argument as a ProfManager value in ExecuteInShell
* Make EntitySystemManager use the new Value method
This was an undocumented breaking change introduced by https://github.com/space-wizards/RobustToolbox/pull/5915. The behavior does not make much sense: you're specifying coordinates relative to the map, so the rotation should be relative to the map too.
Apparently cheat clients have figured out that none of SS14's code does validation against NaN inputs. Uh oh.
IRobustSerializer can now be configured to remove NaN values when reading. This is intended to be set on the server to completely block the issue.
Added "Unsafe" float types that can be used to bypass the new configurable behavior, in case somebody *really* needs NaNs.
An alternative option was to make a "SafeFloat" type, and only apply the sanitization to that. The problem is that would require updating hundreds if not thousands of messages in SS14, and probably significantly confuse contributors on "when use what." Blocking NaNs by default is likely to cause little issues while ensuring the entire exploit is guaranteed impossible.
* WebSocket-based data transfer system
* Move resource downloads/uploads to the new transfer system
Should drastically increase the permitted practical size
* Transfer impl for Lidgren
* Async impl for receive stream
* Use unbounded channel for Lidgren
* Add metrics
* More comments
* Add serverside stream limit to avoid being a DoS vector
* Fix tests
* Oops forgot to actually implement sequence channels in NetMessage
* Doc comment for NetMessage.SequenceChannel
* Release notes
Yeah so this adds libogg, libvorbis, and libopus to the Rust library on the client. This is intended for use by the client soon-ish to replace .NET ogg vorbis implementations and add opus support.
This turns out to be a huge pain thanks to https://github.com/rust-lang/rfcs/issues/2771 . To solve this I ended up compiling the projects as staticlib and creating a build.py script to invoke the linker. This sucks a *lot* and I have yet to write the linker invocations for Linux/Windows, but it's probably the best option we have.
