Wildkins

hi the evac didn't work because of my shitcode that is all

I think you're all sort of underestimating what an actual engineering or maintenance technician IRL would be capable of and in charge of. They aren't janitors who've read a blueprint and know which side of a wrench is which, they're trained, often-times specialized workers that would do the vast majority of the actual grunt work on any given job, often overseen by a (chief) engineer. Making this the default title would also have some nice symmetry with Atmospheric Technician, who would more directly be the other side of the coin so to speak. They'd still also be your "jack of all trades, master of none" in that sense. That being said, I'm neutral on the whole idea. I've never really liked "Station Engineer" as a term, maybe even stealing "Engineering Technician" might be a better term or something else, I don't know. "Station Engineer" just feels really...I dunno. Odd. But I can also see why some people might want it to stay in some form or another.

while we're at it can we make them not explode into flames while considering the concept of a light jog

hmm...

As above, I moved so quickly purely to both bring myself up to speed in a language I'd not touched before and establish myself in the community, given that I was a complete unknown to everyone. It was a perfect storm of good timing and ample opportunity, and I've already slowed myself down considerably to pace myself because what I was doing is just not sustainable. Burnout is certainly a real thing and I'll do my best to stave it off for as long as possible, but that's always tied to interest. So far I'm feeling fine, though! I didn't link them primarily because I'm not sure how much relevance they'd have and it'd mean decoupling them from real-life information. I wouldn't mind sending those along privately with most of the revealing information cut out if you'd like to see them, but personally I'd rather be judged on the merits of my BYOND coding to-date.

These two are essentially related - for me, coding is as much a hobby as a career, and I've been looking for a project I could contribute to that I simultaneously enjoyed playing myself. Unrelated to that was a seemingly stable kick of SS13 that I picked up, which led to be shopping around to various servers I hadn't tried in a while - and I didn't stick to most, as @Omicega can attest. "HRP" servers were something I hadn't tried for a long time (I think the last time I joined Bay was around the time LLA was still kicking) but I found the transition somewhat easy and the server much more in line with what I was expecting from SS13. That all being said, I've played probably two rounds since last week, tops. I have maybe one regular character that people might recognize on a "oh I've seen them in a hallway once" - atmos tech James Sprey - and that's about it. But that just comes down to time. The only reason I wasn't playing on the server, especially this last week, is that I'd thrown myself in at the deep end doing nothing with my days but reading and writing code. It all started because I was annoyed I couldn't late-join as a medical intern, and then I realized I could fix up all the nagging little issues that I encountered while playing, and hey, maybe I could fix some other people's issues too - oh, and gee, wasn't the microwave annoying to use? Et cetera, et cetera. The other factor that, I think, led to me sticking around was the support of the developer and contributor team, especially people like @Datamatt, @geeves, and even @Skull132. It was unusually easy to ask questions, submit changes, and get things done even when I was (and still mostly am) a complete nobody, and that made it a lot easier for me to fit in and feel at home quickly. There's no way I'll match the number of PRs I put out in my first week, for a couple good reasons - for one, there aren't that many low hanging fruit bugs. Most of the remaining issues on github are far more esoteric, either in reproduction or in cause, so they're not fixes I can bang out in an afternoon. I also happened to write all those PRs while on my fall break, which meant that I was putting all 12-16 hours into coding, sometimes more. That's obviously not sustainable in the slightest, even for someone like me that enjoys it! But I expect to constantly be working on both one larger content overhaul (e.g., microwaves) and then fielding bugfixes and smaller updates as often as I feel good doing, as I'm much more careful about pacing now that I have a better feel for how and why to do things.

Ckey/BYOND Username: JohnWildkins Discord Name: Wildkins#8123 Position Being Applied For: (coder, mapper, spriter): Coder Past Experiences/Knowledge: BYOND: ~2-3 weeks of basic research into the codebase, and then shoving myself into every open issue I can get my hands on. Other: Graduating senior, attaining my B.S. in Computer Science w/ focus on Cybersecurity and Web Development Experience in Python (incl. Django/Flask), Java, JS, and SQL-based DBMS Examples of Past Work: Closed ~35 issues via direct bugfix. Worked alongside @Geeves and @skull132 to close ~250 total via identification and testing. Cooking Fixes Microwave Overhaul Yield Declarations Trap Refactor A large number of QOL and non-issued bugfixes, tl;dr: Merged PRs Additional Comments: Obviously I’m still pretty new to both the community and BYOND, but I’ve thrown myself in at the deep end to try and make up for lost time. For me, seeking a developer position is mostly a convenience factor to better amplify my efforts - addressing issues promptly, fixing up quality of life where possible, and attending to user suggestions where appropriate. Things as simple as a vaguely shiny name and ability to throw icons on an issue tracker are honestly very valuable to this end. Furthermore, as I grow in knowledge and ability, I want to try my hand at tackling some of the larger, more pervasive issues in mechanics - but doing so without close partnership with the developers and heads will surely be an exercise in frustration.

aaaaand done https://github.com/Aurorastation/Aurora.3/pull/7192

went with the ore processor over the stacker because the ore processor already has an ID mechanic and it made tracking inputs easier too, to print there needs to have been ore processed and an ID inserted added a 'waste detected' area to the form for hilarious IC consideration, going to do some touch-ups and hopefully get it so you can fill in miner names instead of it being auto-assigned, PR soon(tm)

printing from one of the machines is probably the best bet

having literally never looked at the code before my guess is that wouldn't be very hard if nobody else is chomping at the bit i can take a look once i stop committing war crimes in the kitchen code

Those are some good points. I like the idea of more recipes adding a small amount to the microwave dirtiness, and then making it easier for the chef to keep up on maintenance. As for burned messes and failed dishes, I think you're also spot on, although I'm not sure how I'd go about implementing burning a dish. Without doing a goon-style cook time system or some sort of power setting, everything's going to have a fixed cook time...unless I go the oven route and have it require manual input to stop cooking. But that isn't really how microwaves work, anyway. Still, the abort button at present does what you describe (more or less, there isn't a door-open sprite as far as I'm aware) I'll probably just have the smoking as a status effect that's displayed as a visible_message (like how the microwave getting dirty is), and then have a series of status effects show up on the cooking progress window to make it look a little more interesting. Something like "It's cooking nicely!" if the recipe matches or "It looks like a mess in there" if it failed somehow, probably showing up after the half-way mark of cooking. ...also, if we're having the microwave break only when you shove metal utensils or other stuff in there, then there should totally be a joke dish or two about like, microwaving a lunchbox or something.

Eh, the problem is that failure is basically a binary state. The recipe system really doesn't like you missing single ingredients, and honestly I'm still not sure if I'm a fan of failed recipes just thanos-snapping the ingredients out of existence for a toxic mess. That's not really how real cooking works, you just make worse food, or it doesn't turn out right. That's why I kinda like my "lump-of-gross-food" idea slightly better, since it wouldn't completely waste the ingredients, but I don't know if that's necessarily a great idea either.

honestly the fact that heads were whitelisted but AI wasn't shocked me as a newcomer and from what I've seen, AI is very hit or miss depending on who gets it; honestly, it seems like most of the problems raised here would be easily fixed with a whitelist which also wouldn't remove content or roles from the server, and is a win-win in keeping the AI role for the people who want it and can play it well, or like experiencing what it has to offer in rounds, while simultaneously limiting the cheese and admin workload in re: bad AIs and the like as for cyborgs i'm not a massive fan especially if they all go engineer/construction because post-engine setup they can basically do their job but better; but i am also biased in this regard and honestly i don't really care either way

Well, right now failing one recipe doesn't do anything to the microwave. You'd need to fail a second one to actually dirty the microwave to non-usefulness, and even that's only at a 10% chance. I like the idea of having some kind of indicator that the recipe is failing, though. I'm still not sure if making burned messes is still the right way to go, but at the very least I'll implement that.

https://github.com/Aurorastation/Aurora.3/pull/7180 As some of my earlier PRs may have made clear, I have a soft spot for the service area and the Kitchen in particular, and it's an honest shame that so much of its code hasn't been touched in so long. Since I'm pretty sure most of the egregious bugs in the kitchen area have been squashed, it's now time to look at making things a little less 1990s around here. This PR implements a Vue UI for the microwave, and overhauls a lot of its functionality. For the average user, the microwave is almost identical to how it used to be, save having a new interface. Putting in the right ingredients will still get you your food, but there's now a few new key features: You can now abort in-progress cooking. If the recipe is valid, this is always a safe action. If not, you can abort safely for the first half of the cook time (about 20 seconds) before it's "locked in" as burned mess. You can now eject individual ingredients. Ejecting solid contents (meat, etc.) will simply place them on the microwave as normal; ejecting reagents requires a held container with enough space. Cook time is now shown via a progress bar on the UI. I'm mainly looking for feedback on the UI/UX of the display, since I'm no front-end developer by any stretch of the imagination, and what you think about the microwave and "messing things up". Right now I'm looking at these questions myself, and if you have any strong microwave opinions, I'd like to hear them: Microwaves can't? be broken right now. (Might be wrong.) Regardless, what should warrant breaking a microwave vs just dirtying it? Should burned mess still be a thing? I was considering making a "messy ball of food" item that just catch-all'd the ingredients into one not-very-nutritious ball, as something slightly more realistic and slightly less painful than just outright burning everything. Should abort be a thing? You'd only really use it when you messed up, and honestly the entire dirtyness mechanic somewhat strikes me of a noobtrap or a pitfall for people following out of date recipes. If failures causing damage are fine, then should they be instant? Right now you have to wait half the normal cook time just to find out the microwave's now dirtied, and egads, your roast is ruined. Should I care this much about microwaves? (The answer is yes.)