SabreML

Details: Files changed: 6 Line insertions: 104 Line deletions: 155 Potential labels: Refactor, Map edit (Box, Meta, Delta) This is a very simple one, replacing /obj/machinery/computer/borgupload with /obj/machinery/computer/aiupload/cyborg, since currently the majority of the code is just copied over directly from the AI upload console. I've also moved the install() code for law modules to be on the upload console rather than the AI module board, as that reduces the proc size from 48 lines of code to around 9. I'm not sure if I actually need to ask for permission on the forums to post this since it's relatively small, but it is around 200-300 lines and it's editing every map simultaneously, so I'm not going to risk it.

Details: Files changed: 260 Line insertions: 811 Line deletions: 811 Potential labels: Grammar and Formatting, Tweak/Fix I've gone through every file I could find in the code with name = "Uppercase Name" and replaced every instance (where needed) with either a lowercase version, or added an \improper so that it displays correctly in-game. This regex was used to search, but each replacement was done manually to avoid false positives: \tname\s*=\s*"\s*[A-Z].*" Now obviously this is a lot of changes to go through at once, so my current plan (assuming there's no objections) is to slowly post all of this in multiple smaller 'themed' PRs rather than in one massive one. That way I can go through everything in the 'Weapons' or 'Machinery' categories for example, and double check that I didn't make a mistake somewhere. Most importantly, this would also have the benefit of making the PRs actually possible to review, because while each change is very easy to check individually, 811 of them at once is not. Alternatively I could just split this into 130-file chunks, but atomising it seems like the best way to go. Examples: (Before/After) ----- ----- ----- ----- ----- ----- PRs: https://github.com/ParadiseSS13/Paradise/pull/16897 https://github.com/ParadiseSS13/Paradise/pull/16906

Oh, before I forget to link this: https://github.com/ParadiseSS13/Paradise/pull/16637

PR Details: Files Changed: 91 Line insertions: 330 Line deletions: 333 Potential labels: Refactor, Tweak Type: Draft until fully self-reviewed. PR Contents: Converts the magic numbers used by show_message() into bitflag defines for readability. (MSG_VISIBLE and MSG_AUDIBLE) M.show_message("<span class='warning'>BANG</span>", 2) >>>>>> M.show_message("<span class='warning'>BANG</span>", MSG_AUDIBLE) Converts many instances of show_message() into visible_message(), audible_message(), or to_chat() where applicable. for(var/mob/O in viewers(src, null)) O.show_message(text("<span class='alertalien'>[src] has planted some alien weeds!</span>"), 1) >>>>>> visible_message("<span class='alertalien'>[src] has planted some alien weeds!</span>") Adds a vision_distance argument to visible_message(), to make the message range customisable. Adds an ignored_mobs argument to visible_message() and audible_message(), to exclude a mob from being able to see the message. Useful for situations where the user, target, and observers all need separate messages. Adds autodoc documentation to the show_message(), visible_message(), and audible_message() procs. Fixes some incorrectly called visible_message() procs. visible_message("<span class='warning'>[user] disassembles [src].</span>", \ "<span class='notice'>You start to disassemble [src]...</span>",\ "<span class='warning'>You hear welding.</span>") >>>>>> user.visible_message("<span class='warning'>[user] disassembles [src].</span>", \ "<span class='notice'>You start to disassemble [src]...</span>",\ "<span class='warning'>You hear welding.</span>") The code for this is already finished, working, and mostly tested (I'll do more if it's approved). The vast majority of the file changes are very small, mostly just similar to the examples above, but as it affects 91 files in total I'm making a forum post for this anyway.

Since the new github code of conduct was put into place, a few people (myself included) have had to be reminded of this part specifically, multiple times in some cases: This is a pretty clear instruction for large feature and balance PRs, but the line at which something stops being a “design” change seems to vary from person to person. The official stance is that refactors and backend code changes also count towards this if they’re above a certain size, so I propose that the guideline be amended slightly in order to prevent any more confusion from this: (Just a short suggestion since I’m dealing with vaccination side effects at the moment, I can go into more detail on this in a few days if needed.)

Personally I'm not really sure about this. On the one hand, I've never played on Metastation before so I can't say how bad the maintenance issue actually is gameplay-wise when compared to other maps. On the other hand though, I've never played on Metastation before. Saying that it might have issues ingame is one thing, and I agree that it does seem that way, but removing a very popular map entirely after only a couple of test rounds seems a bit hasty to me. Eclipse Station does look really cool and I'd definitely be interested in seeing it ingame, I'm just not sure that it should be as a full replacement. At least not without a bit more data backing it up first.

One idea that I thought was very interesting was something along the lines of what this thread suggested, but more expanded upon: Allow Changelings to be decapitated, gibbed, etc. But let them survive anything up to the complete destruction of their body, or at least anything which wouldn't kill a generic horror monster in a movie (Gibbed by an explosion, or dusting/cremating). I can't speak on the coding difficulty of this yet since I haven't actually looked into it, but both decapitated and gibbed changelings still have a fully intact head which their ghost possesses. Maybe that head could grow legs and skitter off, grow a full body back out of the remains of its neck, or just turn into a regular old headslug and escape. I believe that this would fix the majority of the issues plaguing Changelings at the moment, primarily because the only way to be sure that you've killed them would be cremation or dusting. Still not exactly hard to do, but it would solve the annoying "cheesy" methods of beating them and make clings a lot more of an interesting and scary threat to the station than the slight annoyance they currently are. (Not actually a finalised suggestion obviously, just a cool shower thought I had.)

One thing that should probably be noted (although admittedly I've never seen one do this) is that the AI can be an antagonist too, and a malfunctioning AI would benefit greatly from maintenance cameras. They actually have an IC reason to build them as well.

I'm double posting and you can't stop me.

Oh, apparently I forgot to post this one!

I think the problem at the moment is that it doesn't provide either of those to IPCs. More often than not the contents of the box are just dumped out at roundstart to free up some extra inventory space. I can't remember having any real issues with that myself when I used to play IPC, but this issue has been brought up a LOT of times by separate players (and those are just the ones I could find), so there's clearly something wrong with it in its current state.

This seems to me like the best solution for this. The chemical doesn't actually exist yet as Esenno mentioned, but it would pretty easy to add it. Having a little 'Emergency repair injector' which could heal a small amount of damage if they're below a certain health threshold like epinephrine does would give the emergency box an actual use, wouldn't involve giving IPCs tools at roundstart, and most importantly, wouldn't be able to be abused at all.

One thing I will point out is that I've seen quite a few admins and staff members bridgewatch/bridgehobo themselves, presumably because it's a relatively safe spot to admin-ghost from. I'm not able to say if that's a good thing or a bad thing because I honestly never payed much attention to the whole issue, but maybe a more unified response or standard would improve it. Ingame announcements can only apply for a few hours before the players who saw them are replaced by new ones who didn't, so for many of them it's possible that if they see an admin lying above the bridge talking to people, they could take it as permission or even encouragement for them to do the same.

This is already a feature, unless it’s stopped working recently. I added it in one of my first PRs last year: https://github.com/ParadiseSS13/Paradise/pull/13934/commits/95b363f4a7c2e8f7bdc4df0896c9a6301fb2666a

Ah thanks, I owe you one.

Wait... so are we on 1 or 2 now?

One confused trial admin

Two ban evading officers

Personally, I would be happy just knowing if one of my PRs has been objected to at all. 90% of the time it's communicated very well and the reasoning behind the objection is laid out clearly. On that other 10% though it can be incredibly frustrating to have a PR closed without even knowing that there was a single objection. In some cases like the 'Genderless' PR I made a while ago then it's obviously understandable that people would rather not put a big, publically visible "I dislike this" on something as sensitive as that. But on other non-controversial ones, sometimes the most feedback you'll get is a with no explanation, if even that. I'm not saying this to complain of course, it's pretty obvious that all of the Maintainers & Heads are very busy people in real life who simply don't have the time to write a 2000 word essay explaining why replacing Tajaran with Felinids is a bad idea. Even so, I would argue that the "If you can't justify it in words, it might not be worth adding." policy on pull requests should go both ways. If they are unable put into words their reasons for objecting (Which again to reiterate, is completely understandable), then I don't believe that it should be officially counted. That's just my thoughts on it anyway, at least in terms of objections.

Five cargo techs walk into a bar...

Huh, I was sure that there would have been more of those. Maybe some of my own requests were done via msay instead. Either way, I'd personally flip that around and say "Even if it's used infrequently, why not have it anyway for the times it would be useful?" It's only 22 lines of code to add it as a feature in its current state, so I can't see any real downsides myself other than the standard 'muscle memory' argument, and I can't imagine there would be much of that for the VV dropdown menu. As I said (I think) my original plan for this was to give it to PR Reviewers and Mentors under certain restrictions. PR Reviewers because they already see the MC, runtimes, and qdel logs. Mentors because it'll allow them to check the attack intent, movement intent, contents, etc. of a player directly, rather than needing to guess.

Probably a good portion of my adminhelps over the last year or so have been asking if an admin could let me know what x variable is set to, and I'm sure I'm not the only one who's been sending these. Having the ability to see (and set) variables is an incredibly useful tool as a coder, really only matched by proc calling. Unfortunately, unless you have admin permssions or you spam ahelps during a testmerge, the ability for non-admins (PRRs included) to debug objects and behaviours on the live server is severely limited. Add to that the number of issues which seemingly choose not to happen at all in test servers or are limited by population, and you've got a pretty high number of bugs and runtimes which aren't being fixed or even detected. Any admins experienced with DM code will be able to avoid this issue of course, and potentially even create a PR to fix the issue right on the spot. 'Codermins' like this though are very much the minority, and while many admins know how to edit variables and debug to some degree, tracking down the source of a runtime or a reference error can sometimes be a whole different process entirely. I propose that we stealborrow PR #30463 from /tg/station, which allows admins to grant a read-only version of a datum's VV panel to a player of their choice. There are likely still bugs in my quick test port, and I know there's bound to be some variables that need to stay admin only, but I've attached a video below to demonstrate the feature. The potential benefits of this really are countless. Assuming it can be made as airtight as possible so as to not allow a greytider to edit someone's ckey out of existence, this would allow PR authors to have much greater insight into how things interact with players during a testmerge. Along with the obvious debugging capabilities. The current version of this still requires an admin to show it to you, which is around the same level of effort as just reporting back with the value of a variable, but I'm hoping that if this idea gets any traction that the read-only version can be given to PR Reviewers and possibly Mentors under limited conditions. (Possibly with extended permissions to allow for navigating nested objects, but that can come later.) As I said, I already have the main part of the code ready to go, but I thought that since this is very much an admin-centric idea that I would wait for any feedback from staff before submitting it fully. Jv3Ka78C2A.mp4

I’ve been wanting to implement this idea for ages now, so I’m definitely in favour. The amount of times I’ve seen people get upset in OOC that their building project got cut off, or that they just lost the syndi duffelbag, two pairs of noslips and a voice changer that they found in maintenance because the wizard died (speaking from experience) is way too high.

Personally I think that it'd be much better to just include that information in an ingame 'information menu' somewhere, like some other servers do. That'd avoid the issue of having to update every item on the wiki with its correct stats, and it'd probably be better for players too since it means they wouldn't have to check the wiki every time.