Skull132

Journalists cannot contact CCIA. Journalists cannot file IRs about command abuse of D-Notice powers if the news being reported was related to antags, which is 90% of D-Noticed content. That's nice. Though considering the recent addition of the journalists as a role, that assertion is not something which has to hold. Considering they have a press pass, meaning they needed to get through PR, and also need to deal with internal security to get their clearance, rules, etcetera. They might as well have access to CCIA. Even if via some proxy which we can politely set up for "lore" purposes.

Surgery room being put in the pathway in and out is a pretty bad idea. Specially with how it as executed at the moment. Also, what Trazz said. There's no actual way to vent/cleanse the pens of dangerous gas.

I didn't even know the Project forum was a new project, I've literally just come back after being away for a month and didn't know the rules there were more serious than in other locations. This is just unfair. I'd be extremely curious to hear how the subforum in question being a recent one had any effect on this punishment. I outlined my thought process in an overly detailed fashion in this post, including all factors which were considered. All of which were either established rules and convention, or clearly visible. Hint: the subforum has had, since its creation, a little blurb above it detailing its purpose. Failure to notice and or to accommodate this as a consideration while posting is not our concern, since the mechanic in question is the standard mechanic we have used since ages past to inform people of forum rules and the rest.

If a journalist is assisting terrorists as a non-antag, can't they be bwoinked? Once red alert hits, paperwork-based policies go flying out the window. I strongly suggest it be a mechanical prevention but I am also of the mind that as long as there is proactive protection of the freelance journalists by staff against zealous command, that it could be fine. I am worried about "it's an IC issue" ruining the freelance journalists' freedom due to zealous D-noticing from command. Journalists are helpless in the face of a d-notice and have no ic recourse in antag rounds. we will see. One time offences of specific journalists overstepping their bounds should handled IC, IMO. Lest we continue this shit of keeping the CCIA as uninvolved in but the most trivial of IC infractions, and elevating the rest onto OOC issues. Outside of a journalist being an outright meme, I do not see a reason to deem their misconduct an OOC issue, when you consider that we have the CCIA for exactly cases like this.

Wrong. Dick Captains cannot get canned by the CCIA if the news is in regards to antags - which is most of the news that would ever get D-Noticed. Wrong. CCIA almost always side with Captains, even if they are minorly in the wrong. Please make it mechanical. I'd rather have myself proven wrong first, before I start adding really fiddly mechanics to code. Regardless, it needs policy anyways.

The issue of not having D-notices mechanically available can potentially end in retardations like journalists publicly assisting terrorists. Ideally those would be the only cases where D-notices for journalists would fly under whatever policy is implemented. So it should buff out. And no, IMO, this is perfectly fine as being left as an IC thing initially. Dick journalists get canned by the CCIA, dick Captains get canned by the CCIA. Everyone wins.

Imma be an ass and ping everyone involved in this. [mention]Senpai Jackboot[/mention][mention]Garnascus[/mention][mention]Sharp[/mention] the mechanical end of this has been implemented: Corp Reporters have wider access. D-notice restrictions are not mechanically enforced at the moment, as it's really ugly code and I'd rather see policy enforce it anyways. (Note that the policy needs to exist anyways.) So uh. Ball's in your court. And probably in the court of the CCIAA.

Application entered into trial. Due to the applicant taking a leave for a week during the trial, we'll keep this one going until the 31st of August. So a little more than a month.

Ye, that Sytic said. A threat alone is worthless if it's never going to be realized.

If you do this, understand the following: - Security will not care at all if you take further hostages - The above means Security will literally fuck you up regardless of how many people you have hostage, because you are liable to kill them already risking their death to get you is generally seen as collateral - Everyone will operate under the belief you are a hostage-killer, and EVERYONE you try to take hostage will fight back violently, because they risk death just by being caught by you On the flip, if you never kill you're hostages, you're neglecting the reasons why you took them in the first place. Hostages are literally an insurance policy. If you just keep saying, "Don't come any closer, we're gonna kill'em!" but never actually carry out your threats, then they're pretty worthless. Generally, you'd want to clearly outline some reasonable circumstances under which you'll start killing hostages and make them publicly known. And once someone violates those circumstances, start picking them off until the violation is resolved. This makes it clear that your threats are valid and that you're willing to carry them out. And in general, Security should then avoid violating those circumstances until such a time when they have a full plan for dealing with you. Instead of just swarming in after, "Welp, they started killing'em."

General rules of thumb for taking hostages: A minimum of two people per one hostage is required. Absolutely be prepared to kill your hostages. Hostages are ultimately there to be killed if people start doing stupid shit. Kill them and run if security does anything you do not like. Always have a way out. A thing a lot of people do with hostages is they take them in a bad place. Ideally you'd either take your hostage somewhere, where sec can never get to you (syndicate ship) or you'd keep mobile with your hostage to avoid being gunned down. Since those two are hard to attain at times, always have a quick exit route in mind if you're creating a barricade situation. Like a stick of C4 and a suit you can blast your way out with. Or something of the like. Having good situational awareness to spot sec doing goofy shit is also helpful.

Since a few weeks ago, some changes have been made to the development process of the server. They're listed below, in no particular order: Updates are now scheduled for every first weekend of the month. This is a convenience thing, which allows for easier tracking of when an update's scheduled and more consistency. It does cut, on average, a week from the current cycle length. But this should be a non-issue. This is in effective starting with the August update. Which means that the time between the July update (today, 22JUL) and the August update (05AUG) is only 2 weeks long. But we decided that this is better than skipping the August update and having a thus bigger September update. Contributors can now review pull requests. As it says on the tin. Contributor reviews can now count towards the review limit. Though this is with the caveat that we don't necessarily trust them. So a new contributor's review, or a review from a contributor who's obviously not as skilled as required for the task, may still merit two developers look over a PR. But in general, we hope that this results in more eyes on code changes, resulting in less bugs and errors. Two reviews per pull request now required. In line with the above, we would like to increase the number of eyes on code that's being merged. As such, all PRs targeting development must optimally pass 2 peer reviews. With contributor reviews counting as described above. Clear exceptions made for high priority PRs, obviously, and for PRs bypassing development. For the latter case, 2 reviews are required for a merge before 24 hours, and 1 for merge after 24 hours. The Projects subforum. This subforum has been created to better facilitate developers and contributors gathering feedback on active projects. The main difference between this subforum and the suggestions subforum is that the projects subforum describe actually in-development (and hopefully soon-to-release) projects. And as such, the feedback should be oriented towards the final idea which was chosen for implementation, which at times may differ from the original idea pitched in the suggestions subforum. Hopefully yhis will garner feedback that's more on topic once an idea has been selected for implementation. As opposed to suggestion topics, which may still discuss various different implementation methods long past a dev has picked the subject up. Regular community votes! This isn't exactly new anymore, but I figured I'd mention this anyways. We've started running community feedback votes on certain development issues over the past month or two. You hopefully have seen and voted on a few of them. The idea is to break out of simply having largely the same group of people offer feedback on the forums and on Discord, and to see what the greater playerbase thinks on certain topics. Though it should be noted that this feedback is not ever binding, it will be taken into consideration when addressing issues around votes. So. That should be it for now. If anyone has any questions about any of this, or wishes for elaboration, feel free to post down below.

Making it an ability can be useful, I suppose. But making them permanently have no pulse is a no-go. It's an extremely obvious tip which can be and will be metagame-d easily.

Okay so here's going to be the deal on this one. A poll was ran on this with the question of, "Should the stun from the pepperspray and telebaton be removed?" Which is not really the intent behind the PR. Ergo there's a decent chance of confusion to be had. Otherwise, feedback for the proposal has been pretty okay, and the amount of stun damage done is on the very high side. Like, enough to down you in one if not two hits. This simply makes the tools actually cooperate with the agony systems used, instead of bypassing them in lieu of adding straight up, "You're ded," timers. A similar thing applies to the taser: they do high amounts of AGONY/HALLOSS damage, but are still beholden to the system. With that said, and due to that, the PR has now been merged. If it ends up being poo, we'll revert I suppose.

I'm inclined to agree with this. We do not have an interlocking system of buffs and debuffs to slot this into. And like has been proven with attempting to appropriate organ damage for things like this, doing it in bits does not work out. Updating all of the status indicator systems (hunger, fatigue, comfort, mental stability(?)) to run off of a centralized system would make things more concise. It would also allow for things like character perks and deperks later down the road, which should address the issue of people wanting to customize their characters and their like or dislike of certain things.

Ye I'm going to have to disagree with the actual nerf portion of this. (Sorry for taking so long, but mulling over it took some time.) To be completely frank: it is lazy. As Pacman pointed out. It is not a meaningful difference in gameplay, it simply adds onto an edge case which already exists as an edge case. The edge case being assault with a flash. If we're interested in "X being on par with security," just make an actual modular glasses system. Expand upon what I started with glasses + HUDs literally years ago now, and make all glass combinations possible.

Well, I don't have anything to add here. Already explained why the warning is essentially the minimum punishment on the forums and why you earned yourself one. Up to Garn to decide if it's valid, then.

Okay so. Let me put the scene for you. It's 3 AM after a work week. We just finished a full system reboot about an hour ago due to a failed drive. Some old code issues creeping up against causing the server to be unplayable right after the full system restart. And I was now finally chilling, looking at code I wanted to write. Then Fowl sees your post, reports it, is about to delete it (as he would on the suggestions forum), but realizes that he doesn't have the permissions due to an error on my part when setting up the projects forum. So he pings me. My first act is to be confused, because I could have sworn I copied permissions over properly. Shortly after this, I trot over to the link, I glance at the post, I click the report and from there the "Issue warning" button, and I soft-delete your post. I do this because the post is clearly unhelpful, does not convey any meaningful information, and is made in a clearly silly manner. Now, usually, those factors combine to make what's called a shitpost. I report back to the dev discord that I've handled the report and ye. As I do so, Arrow suggests to Fowl that he report the post for Mods and Admins to deal with. As some more background. Recently, the Admins have encouraged devs to, instead of simply soft-deleting posts like yours, to report the individuals so they could b e warned and, if they keep up, eventually banned. So you can say that there's effectively new internal policy to actually start enforcing forum rules with consequences on those boards. Now. If you think that at any point there, the fact that you were Xander played a role in what I did, then I physically do not know how to explain to you that it did not. Now to further elaborate on two keys points. First, why was the post deemed off-topic and removed. Because it conveyed no meaningful information and did nothing to assist the developer in the continued development of his feature. Now, let me unpack that a little. First, consider the clearly outlined purpose of the board. "This forum is for project authors (coders, spriters, etcetera) to create feedback topics on their contributions. [...]" So basically, the purpose of the board is to gather community feedback on specific implementations of a given idea. I won't go into the specifics of how this differs from the suggestions board here, but the general point is: the feedback must actually be constructive. Now, we do understand and recognize that not everyone is savvy enough to post full fledged bug reports with steps to reproduce, a full technical write-out of what is the intended outcome and what is the current outcome, etcetera. So saying something like, "Hey, this bit or bob here doesn't work!" would be fine. As long as there was an actual visible effort to be genuinely helpful in there. Going, "lel it broke" contains no meaningful information outside of the fact that something or all of it is broken. Doesn't even attempt to describe in which fashion it's broken. Or why you think that. Ergo: contains absolutely no useful information for the developer to with, outside of the fact that, "Hey, there is an issue with this large and complex system." And the post was written in a fashion where it clearly did not intend to contain such information. As for, "Hey, it's a community, we joke about stuff!" No. Or more correctly, yes, we do, but we have specific areas for that. Like the off-topic board. Everything else is considered to be on-topic. With the limits for it depending on the concreteness of the board. So you can get away with funny shit in General, as it covers a whole breadth of potential topics and discussions, but on boards with a clearly outlined objective, the limits are stricter. In general. These limits are not things to be made exceptions to. Because it would convey a sense of unfair enforcement or worse, encourage infraction on the basis of, "He dun it too!" So no, while we do acknowledge that there's a time and place for jokes, that place is never a board that's meant for an explicit purpose. And finally, the matter of a warning vs a message. All administrative action against an individual should be logged. If we talk to you ingame, we will either put a note about it on your account, or issue a warning or a ban. Strikes are used on Discord, along with a specific hidden logs channel. For the forums, we don't have a decent notes section, so we just use warnings for tracking infractions. This practice is necessary for us to actually keep track of people who've done shit. If you were to, hypothetically, continue shitposting on the projects forums after my warning, and I had only sent you a PM instead of logging the warning, then the next admin or mod would most likely think that you're a first time offender. At which point, he'd potentially do the same as I, and you'd still continue. And this series of wrist slaps would continue up until one of the people who's already wrist slapped you spots you violating his verbal warning and goes, "Guys. I already gave him a chance on this." A warning, which creates a log and increments a counter, is a clear indication for other staff that you've already fouled up against something. They can then investigate and decide whether this something should affect their current decision. This is why warnings, notes, and the like are used instead of verbal notes that other staff cannot track. Also, "[...] but the board automatically bans after someone gets a certain amount of warnings afaik and something like this should NOT contribute to that." I don't know where you got this misinformation from, but I would like you to point it out. Because this is not the case. And no. You do not have a right to decide how we log your infractions. You can only contest the severity of the punishment applied. Now, I think I've offered a very exhaustive explanation of my actions. And I really don't have much else to add.

As I already told PoZe, my previous concerns from his application at the start of the year have been eroded. Specifically you've been getting more used to the idea of explaining why certain things work, instead of taking them from granted, and so forth. So this has my +1. Posted to developers as well. Will wait for their feedback until the weekend and will then decide whether to trial or not.

Well. To offer my feedback on the matter. I am not entirely too concerned about the original incident. But the ignoring of feedback on the why's and how's right afterwards, offered by myself and Fowl, was more worrisome. That is to say, a single slip can happen and get corrected. But ignoring feedback from the rest of the team on the matter is not necessarily smart. And would have most likely played a role in the final evaluation. But that's that, then. Application denied, per the request of the applicant. Trial thus cancelled. Closing and archiving.

tbh I'd love mechanics for being a persistent traitor character. And allowing yourself to get new identities and shit. Of course with metagame economy mechanics attached. Definitely better instead of just being able to click, "Ayy rando".

There's a format for unban requests, to be found here. Please update your original post to match the format required.

One more crazy idea would be to turn the wiki into a static site generator based website and host the main code on Github. But since nuking slowly accruing work sounds like a horrible idea, I'll just throw this into my bin of missed opportunities. Spambots aren't an issue. We don't have wiki registration alone anymore. Users are based off of forum accounts, which are more secure. But we can and will still install the moderation extension. IMO it's a better way to pre-emptively deal with potential edit wars and whatever else. It also means that a contributor can get feedback that they have to look at. Instead of doing their thing and then disregarding wiki maintainer feedback. Etcetera. In general, I should be able to get this rolling some time this weekend. [mention]Senpai Jackboot[/mention] what's your onion on this?

https://github.com/Aurorastation/Aurora.3/pull/4999 Le PR is up.

To prevent all of these fun things, do you know if Mediawiki has a proposed changes system, similar to how PR-ing on Git works? Or is recent edits all you get on that count? Because, if I had to choose, reviewing changes before approving them is infinitely better than reviewing them after they've been pushed live. Also, I've linked this to the wiki plebs to see if they'd be interested in adding the role of Wiki Administratum to their job list.