FabianK3

Some jokes even continue themselves: (Credit goes to @hellfirejag )

Besides the changes to the PDAs capacity / round start value - Where would outlets be fitting within the brig? I'd assume the community area of the brig, cells sounds a bit much, no? Would outlets pose any threat within a brig to security or the prisoners? Otherwise outlets are easily added.

Personally am not a fan of extending emergency kits, as @Jasorn suggested, this can lead to involuntary/accidental powergaming - Why would a doctor, gardener, librarian have a crowbar at all? Doesn't seem right RP wise either. I think the emergency kits should be replaced with more publicly available equipment like medkits, O2 lockers and so on- But this is a whole other topic. I believe safety mechanisms that don't require additional tools sounds very reasonable for a ships design and operation. You would expect a ship / area to have the basic functionality to assist in emergencies, in this particular case door overrides on power failures. Generally, personal safety equipment is something to me for specific roles, jobs or tasks.

How about 2x capacity? Would result in 180min of charge if I'm not mistaken. Would give you a fair chance to get through a basic round without your PDA dying, which I think would be neat if you charged your PDA before the shift (high roll on the initial charge).

Perhaps we can give everyone a different battery level at round start (70-100% for example?) to fix the unified death of PDAs and buff it's capacity? The small capacity and synced battery death is annoying, but I do like the battery mechanic, it's nice RP fluff.

Currently airlocks that are considered secure don't open on power loss, reactor doors or external airlocks for example. If the behavior is switched around, all doors could get that manual override on power loss feature, except those who are currently considered secure. Those would keep closed and won't be able to be opened without power to keep them secure. Unless concerns about that idea are voiced, I can look into that.

"Emergency hydraulic release. Pull lever five times to release hydraulic pressure to override locking mechanism. Mechanism only functional during loss of power." Sounds great.

After another dead-pop round* without power I once again noticed that airlocks open when they loose power. Thinking about it, it seems kind of odd to me: Does it imply that airlocks are actively held close? Seems counter intuitive to me. Would it be better if it were the other way around? Things I considered: - Open areas allow any kind of hostile creature to roam around uncontrolled. - Venting will result in pressure loss as shutters are not always instant to close. - Depowered areas are immediately free to enter for anyone without regard. Considering a spaceship requires area segmentation for multiple reasons, I think the other way around would be more reasonable. Are there gameplay reason opposing a closed-by-default behavior? - Crowsbars and emergency axes are around, so depending on the circumstance, crew can free other crew if the default would be closed without power. What do you think? Would it be worth it or possible to change this behavior? *Most commonly seen on dead-pop rounds, but also a concern in any other setting.

The state in which the Horizon is leaving the expanse right now...

Ckey/BYOND Username: k3fabian (Initially fabiank3, updated after account was lost, current linked to forum) Discord Name: FabianK3 Position Being Applied For: Coder Past Experiences/Knowledge: Professional software development for nearly a decade as a full stack developer with partial experience as team lead. Previous experiences include but are not limited to: - Full stack development (Primarily C#, expected web standards) - Database development (MSSQL/T-SQL, Sqlite, MariaDB) - Development operations (GitLab, Ansible) - Service development (Linux, Windows) - Containerization (Docker, Kubernetes) - Windows/Linux administration (along game server hosting) - Generic game modding, as presumably expected Examples of Past Work: Highlights: - Persistent data framework - Persistent trash - Persistent dirt (WIP) - Issue and pull request stale triage workflow Other; Different PRs all over the codebase: Code fixes, map fixes, minor sprite conversions: Full GitHub PR list - Engineering lobby revision - Rework of wall damage visuals - Hangar air station Additional Comments: I've been told this application was overdue. I'm happy to bring my ideas into action, but I'm not entirely certain with what capabilities regarding available time on my end. I'm hesitant to commit to timeframes, but like to contribute as much as I can. Further contact options, say Hi! https://fabiank3.cloud/

IC statement MSG-CRC: 25059e4d350b0466df3c0648da6b9cec5daa07bb AUTH-ID: Bradley Knight AUTH-STATE: VERIFIED TIMESTAMP: 15707785235 FROM: Bradley Knight, Atmospheric technician (Heph) TO: Marianne Frauke Minamoto di Trevisani, Chief engineer (SCC) TITLE: RE: Ice processing update TYPE: Hephaestus standard lossless audio codec (HLAC) ----- [You can hear heavy humming in the background, sounds similar to chemical processing plants or even a refinery. Occasional clanks in the background and the use of impact drills. The voiceline is mixed in but still okay-ish to understand. With progressing time the humming fades out, as if the noise source is gaining distance to the speaker.] Knight here, sorry for the voice message but we're still busy in atmos. We now got all of the canisters we filled up from down there, good amount— Oxygen and hydrogen primarily of course but we also found a good amount of trace elements in the ice. Turns out the trace amounts are primarily helium-3 and luck's on our side— It's enough to make good use in our drive, I think we can squeeze out a good jump from it. Nonetheless, things are taking a bit longer then anticipated. While we are making good constant progress, we noticed that we got some contaminants in the gas cans we have to filter out coming from the ice before we can inject the contents into our storage tanks. We're going to stow away the helium in standard canisters, as usual. Following our earlier discussion the additional jump capability is great to have as I said before, even though it seems like it's not much use for our current location. General thrust is still looking a bit dire at the moment as I have mentioned in the shift already— Phoron supplies are dwindling and we really need to keep an eye on it. We are mixing in carbondioxid into the fuel line but this isn't the efficiency we are used to, might affect thrust quality. I think it would be great if you could put some attention on the matter on the bridge, perhaps we can save more propellant by limiting the amount of course changes. Save every delta-V we have left. [The speakers volume turns down for a moment, you hear an exclaiming tone.] Err— Yeah! Those two cans are done— Okay, put them over there for now. [The voice returns to a normal level once again. Humming still underlines the voice even with distance to it.] —Sorry. About your question; While the additional jump is good to have, it's not much use. I think our best bet right now would be to turn to Vela. CES One-four-six looks like a death trap... On the other hand, with the jumps available we might be able to just jump over those bastar- pirates. —That might actually work... We also have the interdiction we got from the cartographer. I feel like I might not have all details to make a decision right now. —Hell, then there was the idea of a shuttle bomb? What a situation we find ourselves in... Anyways, we should hope for more supplies of any kind. Obviously. Let me know if you need any other details, I'll let you know if anything rapidly changes down here of course. That's all, Knight out. OOC plan No decision. Awaiting further feedback. Vela could be an exit. CES-146 could be an exit. Vela: We might run out of supplies when we are going in a circle with the Malebranche if we take the Vela route and a bluespace jump might be impossible due to the corners of the routes (if that is a thing?). CES-146: Dead end but Bluespace jump over them / interdiction / shuttle bomb(?) could provide the fallback option in that case?

BUDDY is a menace.

Small update: Persistent trash is waiting for review and persistent dirt is next on my list.

A great idea and already been mentioned to me a lot. But for any kind of persistent resources, there are some issues to be resolved/discussed/test-merged: What happens if the resource runs out? What if it overflows? Should there be a limit on how much can be added or lost per round? Is there a way or does it need a way to "reset" the resource? - All very highly dependent on the use case. When it comes to the implementation: Not that difficult! Be it a single locker/vendor or items laying all around the ship. The "How" and "When" is more difficult when it comes to persistence imho.

Scream if you love the Nralakk federation

A little update! Notice boards have been put in more places and their new functionality should be now more accessible to each department. (Thanks to @MattAtlas, https://github.com/Aurorastation/Aurora.3/pull/21263). Notice boards also received new sprites: Regular notice boards now can handle a lot more papers. Go fill it to the brim and get scolded for it by your local department head. Additionally, we now have a command board type featuring a command-lock and glass pane for public announcements by command. (This one still has not yet been mapped in, I'll come around to that!) (Thanks to @KingOfThePing, https://github.com/Aurorastation/Aurora.3/pull/21211). Last but not least, persistent trash is nearing completion and persistent dirt is still WIP on my end.

IC statement MSG-CRC: 9e126da28250bdb37077145c0c2b4ac13fb233a4 AUTH-ID: Bradley Knight AUTH-STATE: VERIFIED TIMESTAMP: 15704690275 FROM: Bradley Knight, Atmospheric technician (Heph) TO: Visolela Kuvanga, Chief engineer (SCC) TITLE: RE: Status of propulsion and C-Goliath Drive ----- As per your request, we had another look on the status quo of our current means of propulsion. We used up a pretty big charge with the manual bluespace jump tonight, we are currently capable of three further jumps before we lack the moderator composition to execute any other meaningful jump. Propulsion on the other hand looks good: Phoron supplies are good enough to give us a continuous burn for the next weeks. Ilina, Roebuck and myself went through non-scheduluded maintenance after this mess to keep the thrusters operating at a higher efficiency while we set off away from the hostile cruiser. From the speed we have observed of the cruiser, we should be able to keep it at arms length as long as we don't take any larger breaks anywhere. We are faster, but only marginally in this regard. Concerning your question about next jump availability: We prepared a second charge for the drive that we didn't use up yet this night, meaning we can execute another jump in less then an hour of notice. I would suggest we do. If we set course to CES 146 utilizing a jump, we might get lucky enough for the cruiser to lose partial track - Maybe they are incompetent enough to take a wrong turn, giving us more time. When we made some distance, we also have the time to checkout CES 146, CES 142 and Vela in that direction. Let's look if there is a way out of this infested region in the galactic north. Frustrating thought to be running away from pirates, years ago they would've been the ones running. Where is the SAF when you need them. Let me or the team know if you require any other details from Atmos, Bradley Knight OOC plan Bluespace jump to CES 146, investigate system → burn to CES 142, investigate system → burn to Vela, investigate system → Re-evaluate situation, hope for region exit in the galactic north / utilize remaining resources to evade and move. Edit: Grammer

The moment we face some special conditions for "for this area" / "in this instance" persistence shouldn't be applied, we need to find a generic solution. The issue is for example with filing cabinets, how can a player see that "this" specific filing cabinet is not included in persistence and why is it not included? The moment we come up with arbitrary rules for excluding persistence on some things, things might become obfuscated/confusing quickly. (This is a general problem and not directly derived from the filing cabinet idea.)

and his trusted A last visit in engineering before the shift ends... Oh no! (Oh yeah)

I don't even have context to this myself.

Not quite! But I noticed as well. The PRs should be stay as small as possible to prevent scope creep. Somebody just needs to map in more of them but i think the last discourse in mapping was: Let's wait for the notice board refactoring.

Might be small, but when you also add refillable paper trays, wrapping paper and so on, it suddenly becomes whole new task

Persistent trash - Work in progress https://github.com/Aurorastation/Aurora.3/pull/21217 Refactoring of notice boards and implementation of command notice boards - Work in progress - Thanks to @KingOfThePing https://github.com/Aurorastation/Aurora.3/pull/21211