This PR is a revisit to the previously derelict PR #20159 that has been
unfinished for sometime now. More details about it in general can be
found here:
https://github.com/orgs/Aurorastation/projects/2?pane=issue&itemId=53167153
For awhile I've been talking about "Things I've been doing but it would
be really nice to do them with a skills system", or "And here's how I
would put this into the skills system when it's done". The main thing
that was stopping me from building it myself was having poor real life
skills in UI code and in DB code. However, I've gotten permission to
resume this PR, which has already completed the steps I would not have
been able to do myself. The rest of the PR fits well into my skillset as
a dev.
I'm opening this PR as a draft so as to enable my dev environment to
locally track all the previously modified files. I'll take this PR out
of draft and give this a full writeup when I have more work to show for
the PR this weekend.
### TODO
- [x] Rework a decent chunk of the currently existing skills to no
longer require hardcoded inserts into other systems. EG, converting from
classical ss13 methods, to modern /tg/-style ECS coding methods that
work off of component-signal patterns.
- [x] Make sure all of the existing skills have actual game
functionality (I won't PR a 2016 Baystation12 situation where 90% of the
skills are fluff only)
- [x] Add the various skills not yet made but are necessary for
completion sake, EG: Pilot (Spacecraft), Gunnery, Pilot (Walkers).
- [x] Examine each existing job in the game and assess whether it should
have a skill made with it in mind, or if it's covered by an existing
skill.
- [x] TO DISCUSS, BUT NOT ESSENTIAL: Additional skill proposals not
currently in the pre-existing TODO list, proposing subcategories.
- [x] Ensure that the previous TODO list is completed.
### Current Skills
The current list of skills, checkmarked for if I've completed them/they
have actual game mechanics. Or if we're just relegating them to separate
PRs. Originally this list was going to be forced to visit for a bare
minimum "does at least one thing" requirement, but now that is being
forgone due to this PR ballooning out of control and in complexity, as
well as development time overruns.
- [x] Bartending
- [x] Cooking
- [x] Gardening
- [x] Entertaining
- [x] Electrical Engineering
- [x] Mechanical Engineering
- [x] Atmospherics Systems
- [x] Reactor Systems
- [x] Medicine
- [x] Surgery
- [x] Pharmacology
- [x] Anatomy
- [x] Forensics
- [x] Robotics
- [x] Pilot: Spacecraft
- [x] Pilot: Exosuits
- [x] Research
- [x] Xenobotany
- [x] Xenoarchaeology
- [x] Xenobiology
- [x] Unarmed Combat
- [x] Armed Combat
- [x] Firearms
- [x] Leadership
---------
Signed-off-by: VMSolidus <evilexecutive@gmail.com>
Co-authored-by: Matt Atlas <liermattia@gmail.com>
Co-authored-by: FabianK3 <21039694+FabianK3@users.noreply.github.com>
Co-authored-by: Matt Atlas <mattiathebest2000@hotmail.it>
# Summary
This PR refactores code and structure of the current persistence
subsystem, in preparation for Persistency: Circles, Squares and
Triangles.
This should not contain any user facing changes.
~~This PR is based of branch #21925 and **needs** to be merged in order.
The files changed display will be meaningless until then.~~ *Done.*
## Changes
- Split subsystem in partial files.
- Refactored proc names, added "persistentObject" format for current
code.
- Renamed SQL table.
- Refactored logging and call hiearachy.
- Fix CI labeler adding DB label on non-SQL files.
This is a bug that affects characters with multiple long language names:
`language":"Elyran+Standard=&Sol+Common=&Encoded+Audio+Language="`
This exceeds the limit of 50 characters for the language column, thus
bricking the saving.
The limit has been changed to 75 characters.
---------
Co-authored-by: Matt Atlas <liermattia@gmail.com>
# Summary
This PR has the goal of adding a base framework for tracking, saving and
otherwise managing persistent data between rounds, written from scratch.
Persistent data can be anything - Most expectedly noticeboards, dirt,
papers, etc.
_Technical details about the PR below are subject to change._
## Estimated scope
The first iteration of the persistence framework should include the
functioning subsystem and the first implementation of a persistent type
using said subsystem.
- [x] Prepare database for persistent data
- [x] Add new features to `/obj/`
- [x] Logic to get and load persistent data into objects for the
subsystem
- [x] Internal logic for tracking and other
- [x] Implement subsystem
- [x] Basics, files, integration of subsystem
- [x] Database queries for different operations
- [x] Methods for registering and de-registering object tracking for
`/obj`
- [x] Round start logic
- [x] Round end logic
- [x] Implement first persistent type: Papers on notice boards
- [ ] Code review
- [x] Scope validation
- [x] Testing
- [x] Full changelog
- Merge
- [ ] Setup logging config for new subsystem
- [x] Documentation for developers ([How to add new persistent
types](https://github.com/Aurorastation/Aurora.3/wiki/Persistence))
## Inner workings
The new persistence subsystem has the following concept:
At round start the subsystem reads existing data from the database and
creates objects for them.
During the round objects can be added to the tracking using a register
function (or removed by a de-register function).
At round end the subsystem goes over all it's actively tracked objects:
Create new objects (that don't have a persistent ID from the database),
update objects that changed during the round and expire objects that are
no longer tracked.
The objects in questions can register themselves, de-register themselves
and decide themselves what content should be stored and handle how to
set themselves up during the subsystems init phase.
## Information on the new table
`id` - database generated ID for tracking persistent objects over
multiple rounds, objects without an ID are considered new and created
during the round.
`author_ckey` - With the first implementation unused, but expected to be
required in the future to allow any staff/moderation on persistent data.
Nullable as persistent data also can be things like decals without an
actual owner.
`type` - Type of persistent data used for creating objects at round
start.
`created_at` - Statistical values.
`expire_at` - Used for cleaning the database and setting limits for
persistent data types. It's optional and allows permanent persistent
data (command notice boards?).
`content` - JSON formatted data containing the actual properties of an
individual tracked object (e.g. what's written on a paper, what's its
title).
`x`, `y`, `z` - Coordinates taken and given from/to the object during
save/load. Those can be null for future purposes.
## The goal on how to add new persistent data types
`/obj` received two new methods which need to be overriden in the to-be
added new persistent type:
`persistence_get_content()` and `persistence_apply_content(content, x,
y, z)`.
The first method has the responsibility to provide all custom content of
a new type to the subsystem in the form of an associated list (`["title"
= "Hello, World!", "value" = 1337].
What does that mean?
In the example of a piece of paper, the method needs to put the papers
title and text content into a an associated list, that list will be
saved by the persistence subsystem.
The second method has the responsibility to apply the previously saved
content when persistent data is initialized at the start of the round:
The associated list needs to be read back and applied to the paper,
additionally coordinates are provided for the object that have been
taken during saving. Note that the coordinates might be null and could
be ignored during setup.
During the round, when a new object is created, like a paper, you need
to call the subsystem and register a track:
`SSpersistence.register_track(your_object_to_track, ckey (optional)`.
The subsystem will be using the methods above when the round ends and
saves the object - and loads it at the start of the round using the
second method. The ckey needs to be given for all persistent that
contains user generated content, e.g. papers.
In case a persistent object gets removed, you need to call
`SSpersistence.deregister_track(your_tracked_object)`. At the end of the
round the object will be removed from the storage.
`/obj` contains the variable (along some other technical vars)
`persistance_initial_expiration_time_days`, which has a default value of
30 days, but can be safely overriden on a per-type basis. This value (in
days) will be used for the persistent data entry expiration date when a
new object of said type is stored in the database.
## PR description changelog
- Added *The goal on how to add new persistent data types*.
- Updates *Estimated scope* format.
- Updates *Inner workings*.
- Final iteration.
*(Grammer and formatting not tracked manually)*
Adds five new songs for Aurora lobby music - no more baseline SS13
stuff!
Also backports the original Title3 for that OG SS13 goodness.
Taken mostly from CCMixter.
Information in licensing_information.txt.
Also, updates the lobby music toggle to be a volume input. Set to 0 to
mute.
---------
Signed-off-by: Wowzewow (Wezzy) <42310821+alsoandanswer@users.noreply.github.com>
Requires https://github.com/Aurorastation/Web-Interface/pull/136 be
merged.
Allows users to authenticate themselves using only the forum. It will
generate a custom ckey for these users in the form of
`GuestF-[ckey(forum-nickname)]`. This will be saved into the database
and will act as a normal ckey from thereon out. These ckeys will be
marked in the player table, to allow for later filtering.
This will also modify the config parameter external_auth to be an enum
of 3 values.
Open questions: can we do automatic linking from purely the game side?
Since upon creation of the custom ckey, it should also be linked back to
the forums.
---------
Co-authored-by: Erki <erki@skullnet.me>
!!! Please merge AFTER #20723 for migrate version (this PR is set up to
seamlessly be merged after that PR) !!!
Adds a new option to character preferences determining whether a shell
is a hidden shell or not. Right now this is a Yes/No toggle that solely
makes records display as "Human" instead of "Shell Frame".
The previous iteration of this was icky.
I hope this is better.
My rationale for this is twofold:
Right now, you can only play a hidden shell "correctly" if you're
untagged. Firstly, this isn't explained anywhere, so people might miss
this by playing a tagged shell that's playing human. Someone might do
this because a tag can be a potent story tool, especially for specific
brands or lines of shells. Imagine tag scanning a runaway you've found
and getting presented with `HLTD-S07U24`, suddenly you get a huge amount
of storytelling there that wouldn't be present without the tag. <sub>any
similarities to persons living or dead is purely coincidental.</sub>
Secondly, it also means you can't play a shell who doesn't try and hide
it, but also has no tag, because that'll automatically show as human,
which is problematic in many ways.
Also, I moved the "species" field in records to the top with the rest of
the public info, and took it out of employement records, because
security and medical would definitely also get that info, logically
speaking.
In the future (with lore team approval) i would like to enable certain
human citizenships for shells with this preference enabled (likely just
Sol, but i mean if lore team wants we can get wacky with Dominia too),
but that's out of scope for this PR.
**NOTE TO SYSADMINS: See "SQL Details" section below for information on
SQL modifications.**
Moves the data containing cargo items (i.e. the ones you order from ops
and get in the cargo shuttle) from the online database to the codebase.
Everything from suppliers to categories to individual items is now
code-side and editable by developers/contributors.
Refactors cargo items to use `singletons` instead of `datums` for
`cargo_supplier`, `cargo_category`, and `cargo_item`. Multiple-instnace
things like cargo_orders, etc. still use `datums`.
Fixed a bunch of strange discrepancies in categories, suppliers, and
pricing for various cargo items. I did a little bit, but it's exhausting
to go through all of it right now.
Clicking the 'Details' button on the Cargo Order app now actually gives
you details instead of bluescreening. Also added some UI elements to the
Cargo Order app - Cargo Control and Delivery remain untouched.
Overhauled the Cargo Order console TGUI window. It now has tabs on the
left, displays restricted access, supplier information, and boasts
search functionality.
### SQL Details
<details>
<summary>SQL Details [Click to Expand]</summary>
The following SQL tables should be deleted or deprecated from the server
database, as they are no longer in use:
- `ss13_cargo_items`
- `ss13_cargo_categories`
- `ss13_cargo_suppliers`
The included migration file, `V011__codeside_cargo`, creates a new table
`ss13_cargo_item_orderlog` to the DB. This **replaces**
`ss13_cargo_orderlog_items`. Because of this,
`ss13_cargo_orderlog_items` is deprecated and should either be deleted
or locked & preserved for logging purposes.
</details>
## Screenshots
---------
Signed-off-by: naut <55491249+nauticall@users.noreply.github.com>
Co-authored-by: Fluffy <65877598+FluffyGhoster@users.noreply.github.com>
* Fixes SQL Death Tracking again
Removes the foreign key constraint from the ckeys.
-> Ckeys can have different values i.e. when someone dies while aghosted the ckey becomes @ckey
Ensurs that the char_id is set to null and not 0 -> To make sure the foreign key constraint there actually works
* Simpler changelog
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
* Connection Logging Overhaul
Changes how/where the connections are logged to the database
* Add logging of admin bypass connections
* Rebase to latest master
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
* Death Stats Fix
Changes how the coordinates for the death stats are stored.
-> One column for x,y,z instead of all mashed into one column
* Add missing GLOB
* convert indentation
* Rebase to latest master
* Adds the attackers char id aswell.
* Slight reformatting and add constraint
* Fix indentation
* Adds another check
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
* Updates Loadout Backend
Updates the loadout backend to store gear data in a separate table.
This might enable us to increase the number of loadout points available
* Bump MariaDB Version to 10.11
* Update editorconfig for SQL
* Fix update_character_gear
* tgui_alert and TOPIC_NOACTION
* Fix missing sur
* Actually, its user
* Adds a CHECK_TICK, just in case
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
The suit sensors pr used INT as datatype to store text -> That didnt work for obvious reasons.
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
* i alone am the honoured one
* THROUGHOUT HEAVEN AND EARTH I ALONE AM THE HONOURED ONE
* hollow point
* nanana
* ssss
* tgsay final touches
* stuff
* tgui inputs
* help
* carpal tunnel syndrome
* ffff
* again and again and again and again
* hehehehe
* dsada
* readd sanitize
* whoops
* dsad
* nah fuck that
* sd
* fix
* ow
* remove prefs for testmerging
* oops
* oops 2
* fix that
* f
---------
Co-authored-by: Matt Atlas <liermattia@gmail.com>
* Condense Database Migrations
Condenses the Database Migrations into a new initial schema.
Also adds some instructions to the Database Readme for existing setups.
* Update readme/delete changed migrations since pr creation
* Reworks a bit how the previous migrations are handled and updates the instructions accordingly
* Expand the readme with baseline/migrate
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
VMSolidus