d3ac3d06bb
How can ONE DATABASE COLUMN have so many cursed issues I don't know, but it certainly pissed off the devil in its previous life. The start_date column on round entities in the database was added by https://github.com/space-wizards/space-station-14/pull/21153. For some reason, this PR gave the column a nonsensical default value instead of making it nullable. This default value causes the code from #25280 to break. It actually trips an assert though that's not what the original issue report ran into. This didn't get noticed on wizden servers because we at some point backfilled the start_date column based on the stored admin logs. So I change the database model to make this column nullable, updated the C# code to match, and made the existing migration set the invalid values to be NULL instead. Cool. Wait how's SQLite handle in this scenario anyways? Well actually turns out the column was *completely broken* in the first place! The code for inserting into the round table was copy pasted between SQLite and PostgreSQL, with the only difference being that the SQLite key manually assigned the primary key instead of letting SQLite AUTOINCREMENT it. And then the code to give a start_date value was only added to the PostgreSQL version (which is actually in the base class already). So for SQLite that column's been filled up with the same invalid default the whole time. Why was the code manually assigning a PK? I checked the SQLite docs for AUTOINCREMENT[1], and the behavior seems appropriate. I removed the SQLite-specific code path and it just seems to work regardless. The migration just sets the old values to NULL too. BUT WAIT, THERE'S MORE! Turns out just doing the migration on SQLite is a pain in the ass! EF Core has to create a new table to apply the nullability change, because SQLite doesn't support proper ALTER COLUMN. This causes the generated SQL commands to be weird and the UPDATE for the migration goes BEFORE the nullability change... I ended up having to make TWO migrations for SQLite. Yay. Fixes #26800 [1]: https://www.sqlite.org/autoinc.html
Space Station 14 is a remake of SS13 that runs on Robust Toolbox, our homegrown engine written in C#.
This is the primary repo for Space Station 14. To prevent people forking RobustToolbox, a "content" pack is loaded by the client and server. This content pack contains everything needed to play the game on one specific server.
If you want to host or create content for SS14, this is the repo you need. It contains both RobustToolbox and the content pack for development of new content packs.
Links
Website | Discord | Forum | Steam | Standalone Download
Documentation/Wiki
Our docs site has documentation on SS14s content, engine, game design and more. We also have lots of resources for new contributors to the project.
Contributing
We are happy to accept contributions from anybody. Get in Discord if you want to help. We've got a list of issues that need to be done and anybody can pick them up. Don't be afraid to ask for help either!
Just make sure your changes and pull requests are in accordance with the contribution guidelines.
We are not currently accepting translations of the game on our main repository. If you would like to translate the game into another language consider creating a fork or contributing to a fork.
Building
- Clone this repo.
- Run
RUN_THIS.pyto init submodules and download the engine. - Compile the solution.
More detailed instructions on building the project.
License
All code for the content repository is licensed under MIT.
Most assets are licensed under CC-BY-SA 3.0 unless stated otherwise. Assets have their license and the copyright in the metadata file. Example.
Note that some assets are licensed under the non-commercial CC-BY-NC-SA 3.0 or similar non-commercial licenses and will need to be removed if you wish to use this project commercially.