* Content.Packaging can now emit binlogs for the build
I was checking why packaging is so much slower and it *seems* to be entirely the actual build being twice as slow as before .NET 10. Strange.
Content.Packaging can now emit MSBuild binlogs that we can analyze to see why that's the case.
* Enable --log-build on Test Packaging workflow, produce artifact with binlogs
* Disable setup-dotnet in packaging workflow
I have a suspicion...
* Ban DB refactor seems to work at a basic level for PostgreSQL
* New ban creation API
Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban).
* Make the migration irreversible
* Re-implement ban notifications
The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server.
* Fix some split query warnings
* Implement migration on SQLite
* More comments
* Remove required from ban reason
SS14.Admin changes would like this
* More missing AsSplitQuery() calls
* Fix missing ban type filter
* Fix old CreateServerBan API with permanent time
* Fix department and role ban commands with permanent time
* Re-add banhits navigation property
Dropped this on accident, SS14.Admin needs it.
* More ban API fixes.
* Don't fetch ban exemption info for role bans
Not relevant, reduces query performance
* Regenerate migrations
* Fix adminnotes command for players that never connected
Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it.
* Great shame... I accidentally committed submodule update...
* Update GDPR scripts
* Fix sandbox violation
* Fix bans with duplicate info causing DB exceptions
Most notably happened with role bans, as multiple departments may include the same role.
* Make ServerPackaging automatically get extra server assemblies
* Make the switch
* Use Content.Server.deps.json instead
* Remove debug
* Rewrite
Now recursively fetches dependencies from Content.Server
Only copies dependencies not covered by Robust
This removes the need to manually specify most of the dependencies, even the content ones!
Also look at runtime key properly to figure out the proper dll name.
This actually removes some assemblies that were duplicated between the main directory and assemblies (various Microsoft.Extensions stuff)
* Fix test compile errors when updating dependencies
Ran across this while updating dependencies on the RT .NET 10 update. Should be fine to merge immediately.
* More .NET 10 prep
* Convert to SLNX
Hell yeah
* slnx now has size-2 indents
* Update SLNX with new RT system
* Remove reference to RT test in toolshed test
* Remove accidental usage of transitive RT dependencies
* Move Robust project references to RobustApi
* Update solution file
* Fix warnings in pow3r
* Fix nullable warnings in integration tests
idk where these came from
* gitignore binlog files
* Fix transitive dependency warnings in Content.Benchmarks
* Update slnx
* Okay, the Robust API thing didn't pan out. New plan.
It apparently broke clean builds, as the dependencies aren't in the project asset list or something anymore. I tried to fix this, but it seems impossible to do without relying on .NET SDK internals, as there's no point in the NuGet graph walk process that seems cleanly extensible.
Instead let's just do the much dumber thing: a bunch of .props files for content to import. Hooray!
This also means that I have to go through and *explicitly* disable transitive dependencies everywhere in RT. This thankfully isn't too hard.
* Update RT to 269.0.0
* One last solution update
* Fix more data definition issues
* Update RT to 269.0.1
* Fix it again
---------
Co-authored-by: DrSmugleaf <drsmugleaf@gmail.com>
All of this was doing sRGB -> OkLAB conversions without linearizing the sRGB first, so it was broken. I could have sworn I pointed this out in review but I guess that got lost.
Also, add a gamut clipping step since we have out-of-gamut colors and I don't want random negative values causing weird nightmare bugs somewhere. Shouldn't change anything in regular rendering.
* Reduce explosion airtight cache memory usage
This means you can happily add explosion prototypes again
New approach has the tolerance value data in a shared storage with reference counting.
* Oops fix index removal
* Remove debug code and fix merge conflicts
* Also address my other review
* Oh it's in two places lmao
---------
Co-authored-by: Princess Cheeseballs <66055347+Pronana@users.noreply.github.com>
* Prometheus exporter for github repo stats
I want more grafana charts
Already deployed on moon, this is just so other codebases can use it if they want.
* Add docs and issue/PR priorities
* Sure add merge conflicts too
Many newer overlays use IRenderTextures that are sized to the rendered viewport. This was completely broken, because a single viewport can be rendered on multiple viewports in a single frame.
The end result of this was that in the better case, constant render targets were allocated and freed, which is extremely inefficient. In the worse case, many of these overlays completely failed to Dispose() their render targets, leading to *extremely* swift VRAM OOMs.
This fixes all the overlays to properly cache resources per viewport. This uses new engine functionality, so it requires engine master.
This is still a pretty lousy way to do GPU resource management but, well, anything better needs a render graph, so...
* Fix usages of TryIndex()
Most usages of TryIndex() were using it incorrectly. Checking whether prototype IDs specified in prototypes actually existed before using them. This is not appropriate as it's just hiding bugs that should be getting caught by the YAML linter and other tools. (#39115)
This then resulted in TryIndex() getting modified to log errors (https://github.com/space-wizards/RobustToolbox/commit/94f98073b07bd3fa3133ae6799b34d90f46f467e), which is incorrect as it causes false-positive errors in proper uses of the API: external data validation. (#39098)
This commit goes through and checks every call site of TryIndex() to see whether they were correct. Most call sites were replaced with the new Resolve(), which is suitable for these "defensive programming" use cases.
Fixes#39115
Breaking change: while doing this I noticed IdCardComponent and related systems were erroneously using ProtoId<AccessLevelPrototype> for job prototypes. This has been corrected.
* fix tests
---------
Co-authored-by: slarticodefast <161409025+slarticodefast@users.noreply.github.com>
* Fix horizontal space men in replays
Visualizer should not bail if data unavailable.
* Update Content.Client/Rotation/RotationVisualizerSystem.cs
---------
Co-authored-by: slarticodefast <161409025+slarticodefast@users.noreply.github.com>
* Disable parallax texture preloading
Many parallax layers are specific to a single map and will likely never be loaded for the duration of the game. Save VRAM by not loading them always.
Requires engine master
* Put generated parallax identifier in texture name
Makes it show up properly in debugging tools
* Don't load generated parallaxes multiple times
Many parallax prototypes re-use the same generated parallax configs. These generated parallaxes were being loaded multiple times at once, which was a massive waste of VRAM.
We now move these into a separate cache for deduplication. I had to write a lot of logic to handle loading cancellation and ref counting. Yay.
Also fixes some spaghetti with the previous parallax loading system: cancellation didn't work properly, give proper names to generated texture names, etc.
This saves like 100+ MB of VRAM.
The tick updates were purely used to decrease the invoke counter once per tick. Now instead we just calculate the effective counter value with some trivial math on the tick number. This completely removes the need for an update function.
The relative tick is not stored to map files. If we really need this, we can add a TickOffsetSerializer (similar to TimeOffsetSerializer), but I doubt it matters.
1. Now clearly says "opened"/"closed" when changing the release valve.
2. Clearly says whether the valve was opened while a canister was inserted or not.
3. When a tank is ejected, logs if the valve is open and the ejection started spilling into the environment.
Fixes#34488
I noticed that enumerating gases is frequently done in an annoying way with Enum.GetValues. So I made it better. Now GasMixture is IEnumerable<(Gas gas, float moles)> and it just works.
* Give silicons proper lobby/character editor previews
No more naked dummies, properly show a borg/AI sprite now.
This means taking the JobEntity into account when spawning the dummy. For AIs I had to add a "JobPreviewEntity" field because they'd look like a posibrain otherwise. AI therefore uses a custom dummy entity I defined.
Also I had to add some margins to the UI, because otherwise the 32x32 sprite of the AI would look bad.
* Update Content.Shared/Roles/JobPrototype.cs
* Update Content.Client/Lobby/LobbyUIController.cs
* Update Resources/Prototypes/Entities/Mobs/Player/silicon.yml
---------
Co-authored-by: slarticodefast <161409025+slarticodefast@users.noreply.github.com>
Layout would break for machines with >6 lights because the column count was hardcoded. Uncap the UI width and fix the rows count instead.
Lights with less than 4 characters of text weren't aligned right, now they are.
Fixes formatting of owned entity type property names. These are normally named "FooBar_Baz" by EF Core, but the snake case thing was turning them into "foo_bar__baz". The double underscore is now fixed.
We don't *yet* have any EF Core owned entity in use, but I am planning to add one. I don't know if downstreams are using any so this should still be marked as a breaking change.
Also fixed it creating and dropping a Compiled Regex instance for every name, the regex is now cached (and pregenerated).
This should be the primary changes for the future-proof "Modern HWID" system implemented into Robust and the auth server.
HWIDs in the database have been given an additional column representing their version, legacy or modern. This is implemented via an EF Core owned entity. By manually setting the column name of the main value column, we can keep DB compatibility and the migration is just adding some type columns.
This new HWID type has to be plumbed through everywhere, resulting in some breaking changes for the DB layer and such.
New bans and player records are placed with the new modern HWID. Old bans are still checked against legacy HWIDs.
Modern HWIDs are presented with a "V2-" prefix to admins, to allow distinguishing them. This is also integrated into the parsing logic for placing new bans.
There's also some code cleanup to reduce copy pasting around the place from my changes.
Requires latest engine to support ImmutableArray<byte> in NetSerializer.
* Borg type switching.
This allows borgs (new spawn or constructed) to select their chassis type on creation, like in SS13. This removes the need for the many different chassis types, and means round-start borgs can actually play the game immediately instead of waiting for science to unlock everything.
New borgs have an additional action that allows them to select their type. This opens a nice window with basic information about the borgs and a select button. Once a type has been selected it is permanent for that borg chassis.
These borg types also immediately start the borg with specific modules, so they do not need to be printed. Additional modules can still be inserted for upgrades, though this is now less critical. The built-in modules cannot be removed, but are shown in the UI.
The modules that each borg type starts with:
* Generic: tools
* Engineering: advanced tools, construction, RCD, cable
* Salvage: Grappling gun, appraisal, mining
* Janitor: cleaning, light replacer
* Medical: treatment
* Service: music, service, clowning
Specialized borgs have 3 additional module slots available on top of the ones listed above, generic borgs have 5.
Borg types are specified in a new BorgTypePrototype. These prototypes specify all information about the borg type. It is assigned to the borg entity through a mix of client side, server, and shared code. Some of the involved components were made networked, others are just ensured they're set on both sides of the wire.
The most gnarly change is the inventory template prototype, which needs to change purely to modify the borg hat offset. I managed to bodge this in with an API that *probably* won't explode for specifically for this use case, but it's still not the most clean of API designs.
Parts for specific borg chassis have been removed (so much deleted YAML) and specialized borg modules that are in the base set of a type have been removed from the exosuit fab as there's no point to printing those.
The ability to "downgrade" a borg so it can select a new chassis, like in SS13, is something that would be nice, but was not high enough priority for me to block the feature on. I did keep it in mind with some of the code, so it may be possible in the future.
There is no fancy animation when selecting borg types like in SS13, because I didn't think it was high priority, and it would add a lot of complex code.
* Fix sandbox failure due to collection expression.
* Module tweak
Fix salvage borg modules still having research/lathe recipes
Engie borg has regular tool module, not advanced.
* Fix inventory system breakage
* Fix migrations
Some things were missing
* Guidebook rewordings & review
* MinWidth on confirm selection button
You were already able to strip more items at once from somebody than you could hold, and they would drop to the floor. This matched the behavior in SS13.
Annoyingly, however, you were not allowed to *start* a stripping action if you're holding something. This just feels like an annoying paper cut, so this is no longer a thing.
This code was a mess. Now it's less of a mess and user UserDbDataManager now.
Fixes the following bugs:
* If you connect to a server, restart your client, connect again in the same round, you role bans would not be visible in the client.
* If you role ban somebody who is not connected to the server, then they connect within the round, they will only have the recently-applied ban.
Likely fixes#24781, #27282
* Fix some rounds failing to end due to mind roles
Fixes#32791
This is caused by ShowRoundEndScoreboard running into a bug trying to display antags: some player is showing up as antag with MindIsAntagonist(), but has no antag roles listed in MindGetAllRoleInfo().
This was caused by one of the roles of the player having the Antag boolean set, but having no AntagPrototype set.
The responsible mind role appeared to be MindRoleSubvertedSilicon which is missing a set for the SubvertedSilicon antag prototype.
I also added resilience to the round-end code to make it so that an exception showing the scoreboard (and sending the Discord message) would not cause the round end logic to completely abort from an exception.
I am planning to add an integration test to cover this bug (no prototype in mind roles), but I'll leave that for not-the-immediate-hotfix.
* At least one maintainer approved this tiny PR without reading it, not naming names.
* Fix error log when recycling something with small material counts.
MaterialStorageSystem.SpawnMultipleFromMaterial now doesn't call StackSystem.SpawnMultiple if it tries to spawn zero. This happens because the recycler calls SpawnMultipleFromMaterial for everything recycled, even if the amount it has stored is < the amount for one sheet.
* Update Content.Server/Materials/MaterialStorageSystem.cs
Co-authored-by: slarticodefast <161409025+slarticodefast@users.noreply.github.com>
---------
Co-authored-by: slarticodefast <161409025+slarticodefast@users.noreply.github.com>
* Fix borg hands showing up in stripping menu
Borgs can't drop their items anyways, and the amount of hands borgs have causes the UI to just bug out.
* Add more checks
Lol .AsSingleQuery().
Some people's preferences wouldn't load on Lizard. Turns out the entire preferences set is loaded with a morbillion joins in a single query and one person had 240,000 (!!!) rows returned for their preferences query. Yeah.
The ChatSystem code for re-enabling OOC only ran during PostRound, which gets skipped over when doing restartroundnow. Now it does this on PreRoundLobby too.
This uses multiple API requests to directly send the publish to the CDN server, no more GitHub artifacts.
Faster, less moving parts.
Needs Robust.Cdn 2.2.0
If an error occurs while loading a replay, it's *supposed* to show a popup "hey do you wanna continue with error tolerance", and it does do this. But because of spaghetti in the replay state code, it also immediately tries to reload the replay without input, as a consequence of trying to reset to the game's default state.
Now the replay load system has a proper game state for "replay load failed", with nice presentation and explicit formatting and 10% less italian cuisine.
* Extend shuttle dock time if the shuttle doesn't dock at evac.
If the shuttle can't dock at evac for *some reason*, it will instead try to dock at another port on the station. And if that fails it goes somewhere random on the station.
Because of the chaos and confusion caused by this, many people will frequently not get to the shuttle in time under these circumstances. This sucks for everybody.
To alleviate this, the shuttle launch timer will now be extended if the station doesn't dock at its ideal spot. The default values (controlled via CVar) are 1.667x and 2x respectively for "wrong dock" and "no dock at all" scenarios.
The code around here was a mess, so I fixed that too. "CallEmergencyShuttle" has been renamed to "DockEmergencyShuttle", the overload that did the actual docking has been renamed to DockSingleEmergencyShuttle. Code has been split into separate dock -> announce methods so we can calculate shuttle delay in between the case of multiple stations.
Also made the "shuttle couldn't find a dock" text announce the time until it launches and fix the shuttle timers not triggering for it.
* Minor review
---------
All PACMANs used to use the same ramping parameters, this meant a SUPERPACMAN (50 kW) took literally a 100 seconds to get up to its full output level. Ouch.
PACMAN has been raised to 5000 W/s with 1500 W tolerance, SUPERPACMAN to 7500 W/s with 2500 W tolerance
This re-introduces the dummy entity naming code, originally introduced in #29178 and randomly removed by #30064 with no technical justification given.
Fixes#31373
Pieter-Jan Briers
