This PR makes it so that player characters who are active in the
ghostrole list will show up on the Crew Manifest, but only if you the
player are not currently in-round. Any type of Observer, including
ghosts, aghosts, and actually being in the lobby, all allow the user to
view Off-ship characters in the manifest. If you are not any kind of
observer, the Crew Manifest will only show Horizon characters.
I have tested this PR. Behold.
https://github.com/user-attachments/assets/76ffb40a-bb67-4719-a2e7-df04f38b929e
Changes the Auth System to use the new login server to fetch the
users/groups instead of the deprecated forumuserapi.
Removes the ForumUserAPI and moves the admin authorization processes to
a auth subsystem
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
This PR updates the repo fully to Byond 516.1673. We now have access to
Associative Lists, Vectors, Matrices, and a huge number of math
improvements tha will allow us to catapult the repo into a new era of
simulationism.
I have tested this PR to verify that it works.
<img width="1076" height="1079" alt="image"
src="https://github.com/user-attachments/assets/c69a7276-7611-4a59-8630-46d8dd8a12a6"
/>
# 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)*
**Goals:**
1. Delete area definitions no longer used in any map or file.
2. Update area definitions such that everything used in mapping the
Horizon exists in 'maps\sccv_horizon\areas' with the parent
'area\horizon\'.
3. Reorganize/rename/restructure those Horizon area definitions to make
future mapping easier and code that hooks into area properties easier.
4. Present area names and blurbs in the status panel.
This PR only handles Horizon and Runtime areas, for digestibility/ease
of reviewing. Offsite areas for another PR.
Naming convention reference:
The /area/ 'name' variable no longer contains either 'Horizon' or the
Deck# of the area or its approx location on the ship. All Horizon areas
now have several new variables as metadata-- area names now need only be
strictly descriptive, and the appropriate constants used in the area
definition, and a new function generates the display name with
consistent formatting for us.
Detailed documentation to follow after any adjustments are made to
mappers' preferences.
This also adds area blurbs to most areas- if not bespoke, then general
department-wide blurbs to parents. I know feature creep always sucks,
but while some areas having pre-existing blurbs, the overwhelming
majority of areas don't, and while testing it was very distracting to
see them randomly appearing and disappearing. Most blurbs are pretty
basic but I feel are entirely presentable- more clever individual ones
can follow in a separate PR.
Ports the DBCore subsystem from tg.
A few things had to be dumbed down to make them work here.
Separate PRs will be created for different systems as they are moved
over to the new DBCore.
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
What it says on the can; now we can better compensate for processing
spikes by queueing and accounting for verb times (assuming we actually
use this framework to invoke the bulk of them). I have added its use to
some of them, more can be ported as time goes on, eventually everything
but the most trivial ones should go through this.
No player facing changes. Hopefully.
Praise be the omnissiah.
https://forums.aurorastation.org/topic/20198-mission-briefing-auroras-gamemode-revolution
To-do:
- [x] Finish storyteller verbs.
- [x] Storyteller landmarks.
- [x] Proper storyteller spawning. Right now the gamemode system is
happy with just picking one storyteller and no actors.
- [x] Antagonist whitelists code.
- [x] Adding the Storyteller whitelist.
- [x] Mission map loading code.
- [x] Map in a bunch of missions.
- [ ] Storyteller adminhelps.
---------
Co-authored-by: Matt Atlas <liermattia@gmail.com>
Co-authored-by: DreamySkrell <>
Refactored Life() to receive seconds per tick and times fired as
parameters.
Life() now cannot be slept in, turned various sleepings into async calls
procs.
Optimized mob AI subsystems, gave them new priorities levels and flags.
Grab upgrades are now elaborated asynchronously, tweaked them to avoid
stacking multiple upgrades.
Fixed plains tyrants keeping sending messages about stomping even if
dead.
Ported SSThrowing from TG, to handle throwings.
Updated movement system to the latest iteration, made it a datum as per
latest iteration.
Updated pass/hit handling of atoms, introduced pass_flag_self to
determine what atoms allow to pass.
Moved procs and defines around to make them more organized.
Our SSOverlays system is outdated, and is likely the cause of many of
the issues seen in #18895. It has also been linked to a massive server
performance decrease.
This brings an updated system from Baystation, hopefully with speed
increases.
Should be testmerged, ideally with #18895.
---------
Co-authored-by: Cody Brittain <cbrittain10@live.com>
Refactored the use of the isprocessing var into the datum flag
DF_ISPROCESSING.
Updated SSprocessing and SSmachinery to have a constant fire rate.
Updated gas cooler to be time-constant thanks to the above.
* sdaf
* sdaf
* sdfa
* sadf
* sfda
* gfd
* reduce thrusters volume
* sdafsadsdaf
* sdfa
* Reduced some sound ranges and made some/more not ignore walls for loops
* health analyzers too
* ivdrip adjustment
* most tools now use play_tool_sound to have the sound played, reduced range for it
* first reordering, committed in case i fuck up badly next
* from the moment i understood the weakness of my flesh
* sdafa
* you asked for this
* we can't have nice things
* sdafasdf
* sdafasd
* sdfa
* fsa
* worth a shot
* more pain
* sdfasdf
* SSatlas.current_map
* hardsuit spell tab appears to clear correctly
* sdfsa
* from the moment i understood the weakness of my flesh, it disgusted me
* sdf
* pain
* sadfas
* sdfa
* sdfasf
* sfa
* sdf
* might the lord have mercy on our soul
* i cri everidai
* adeste fideles
* sdf
* where will this lead, what's coming next, from your inventions
* dear lord
* gjvhk
* i cri everidai
* fsgf
* sdfa
* sdaf
* hiuhi
VMSolidus