Skull132

I generally approve of ideas like this. But I do have one major question. Specifically concerning group antags. If we enable the selection of specific themes. How do we make the selection of a uniform theme for that group work out? Like, it's fine and cool that we get to pick their style, but if we allow this at an individual level, then, IMO, group antags will suffer immensely. Even without this ability, Raiders and Mercs have a long history of the antagonists just not being able to agree on a theme or an approach from time to time, and this has caused issues. So giving even more ways to cause discord between the team members is bound to exacerbate the issue.

Any admin is able to change your account's name, IIRC. So PM-ing any one of them through the forums would have been sufficient. And consider your name changed now.

Giving the captain a sword does not well suit our setting. Swords are generally associated with the Unathi and ninja in our setting, and definitely not with a common Biesel human.

This makes the use of internals to protect against unsavory atmospheres pointless. And exceptions for gas masks or the like end us up in exception city. Which is not a good place to be. Exception city aaaaaa. Teal deer: I think that adding an n-amount of exceptions to this system would: make it dumb to maintain code wise; make it difficult to handle and perceive the mechanics. Specifically in the sense of you gaining an appreciation for when you are running on internals, and when you are not. Specific conveniance as the cost of general uniformity tends to be bad game design.

Thread name and proposal do not seem to match upon initial inspection. Is this meant to represent bullet grooving, at which point you'd get a "fingerprint" of a gun; or is it meant to identify the gun type, which can perhaps already be done by shift-clicking the bullet?

The reason why your lungs pop is because it is possible to drain a tank to near vacuum just by breathing through it. If it were an air mix, you'd probably die of suffocation first, as the oxygen level depletes in the tank. But with a pure O2 tank, you just exhaust the entire tank and boom, done. No reverse pressure, just powerful enough lungs to consume all of the pressure within the tank. RE co2 poisoning. Humans do not produce enough co2 for it to matter before you die from a lack of O2, even if there was no vacuum. It's also questionable whether a true gas exchange actually takes place with internals. It probably doesn't. I would also caution against explicit conditions like "when wearing a space suit" and "when in a breathable atmosphere". It tends to lead to hard coding. It should either be all manual, as it is now, or all automatic, meaning you drop the mask if it is not sufficient. But the latter quickly becomes a bad idea if the issue of the vacuum is fixed. Namely, how do we determine a bad gas mixture. So, IMO, the only thing that should be modified is the fact that you can casually create a vacuum by breathing out all of the O2 from a tank, and also implementing meaningful gas exchange. Where you breathe from should still be a manual decision.

But you're not. My question stems from the fact that we literally have nothing useful to add with the contract, that is not already covered by another source.

What does this help to establish that corporate regulations, station directives, and job descriptions already have not?

Major issues here. First, an actual contract would be so immensely long that no sane human bean would bother to read it. Second, those that do read it are likely to find (or worse, think they've found) a loophole or some such within it, and are going to use it in an attempt to strong arm people. The latter will require regular staff intervention to shut down and curb the people in question; to amend the monolithic document; to otherwise maintain said document. Literally. No benefits gained besides the ability for some people to do stupid shit, and for a bit of a neat fluff flavour.

But like. This is the main concern raised in the post. And there is no way to counter it beyond forcing people (or incentivizing) to fix bugs if they wish to do grander things. This happens to even professional coders. The butterfly effect is a metric ass and the most concrete way to counter it is to install a battery of tests. We don't really have that. Instead, we have peer review, which brings us to the following point. How would it change the status quo? If the person cannot intuitively understand that his code is about to invoke the butterfly effect on scale already, then he will simply skip over these questions unless someone else verifies the answers to these questions. Even requiring that all features be "tested" doesn't work, because testing is actually a relatively complex skill: it is typical that only a positive result is looked for (eg. my feature works), but it is common for people to neglect negative results and surrounding results. This is a methodology which can only be learned through trial and error, IMO; and will, at the end of the day, still require a code reviewer to pose the exact same questions and to walk through the exact same process.

I need to be horribly nitpick-y here. I've echoed similar complaints over any related proposals about IPCs and such as well. Why would NT provide any external party access to its internal and secure networks in this capacity? A principle of information security is control over access points, and in common application, this means that corporate internal networks can only be accessed via devices which are under direct corporate supervision (work computers, enslaved synths). And there is a flip side to this as well. Why would the Akutha, or IPCs, put themselves at risk by exposing themselves to NT networks? The moment you start communicating with another network is the moment you need to put in extra effort to control exactly what they can do on your network. If NT was to provide a weakness in the Akutha or IPC security, it could very well just enslave all of them, for example. Or, in a more believable capacity, would use it to fuck with either of them.

There's at least widely different points conflated within this post. Feature completeness. Ala, "Don't remove something unless you have something to replace it." Depending on the PR in question, this is a valid point: a PR should be feature complete and usually this is enforced. However, note that this is a subjective metric so we may well have different views on what requires a replacement. Somethings don't, and removal alone is sufficient. Follow-up. Or, well, bug fixes. This is probably the largest issue presented here. As we slowly accrue fresh contributors (and I do mean fresh), the amount of bugs generated by them is also going to accrue. Specially from small silly shit, wherein the bugs aren't actually bad or game breaking, and thus aren't grovelled over by the playerbase at large. A proposal, one which might be well worth considering if this trend continues, is the addition of "gud coder points". Wherein your ability to submit "Feature" PRs gets automatically limited, until you submit "Bugfix" PRs. Another point of follow-up is indeed balance. I see largely two approaches to this: either maintainers begin more actively supervising balance oriented PRs, at which point they will become more sparse and more difficult to get through; or we uh. Don't do anything and pray for the best. There's no really good way to handle this that is not a mix of these two (larger balance changes get more oversight, and are thus slower), which is what we have now, anyways. Review and testing. Your list, effectively. Point one, mistakes happen, and perhaps the relief from point 2 would be able to assist with that. We do test-merge large PRs now, but obviously we can't apply this to every single PR forever. So ye, I do not have many proposals for this point.

When is the last time you have gone over them? I need to say again they are distinct from their original set up which i acknowledged was confusing. Theyre now a semi popular species and people more or less get it in its current iteration. Did you actually read my point? And it took a decent amount of loud noises to make this not be the case. Re: Atlas. As said, I've not investigated too far, simply forwarding what I've heard. And since I am not the only one to hold this opinion, perhaps it is a matter worth providing introspective on. Skull132 is the decider as the head developer. He is my boss. For the sake of clarity and future reference. You could have indeed transitioned Nursie to another task, something which was actually even discussed once during the initial discussion I think? How the mandate of 2 deputies per team was achieved was largely irrelevant, though suppose I did not explicitly mention that you had alternatives. Mostly because my patience on the issue was done.

Can you describe how? The politics deal is what I've heard consistently for the past 4 months, from both within and without the lore team. Example one is the Akutha, which at first attempted to implement a niche sociological experiment in a manner which was devoid of logic. All the while trying to paint it off as "good" or in a general positive light. Specifically in this case: the idea that the central AI of the akutha wasn't a slave-master, despite the lore literally saying that it was able to influence the akutha's subconcious decision making processes (and please do not proceed with pedantry as a defence: this issue was discussed to death and if half of your own writers find the matter in question badly presented or illogical, then it's a bit more difficult than, "You're using the wrong terms!"). Another example that I've heard consistent noise about is the treatment of Atlas for the past 4 - 5 months, and how they've been made into a caricature. Something which, according to your detractors, they were not previously. The speculation goes that since Atlas' politics are relatively well opposed to your own views, they are not being a fair treatment. Though, since I have not had reason to fully look into this matter, I cannot comment on the specifics. Simply know that this criticism has existed for a relatively long time, and this is how it looks.

Some limitation would probably be necessary yes. Something along the lines of your syndicate cell leader authorizing you to traitor for that round. Basically you join, try some action on your PDA, and that determines if you're given a green light to mantag or not. Alternatively, we mark syndicate characters and forbid joining as one if there's already too many antags in the round.

Oh hey. I figured out what's broken on the engineering jumpsuits. There's no contrast. At all. It's a blob, specially when you zoom out. The atmos jumpsuit does a way better job at introducing contrast.

Mining is very bland. And something about the engineering and janitor uniforms gets me. A lack of deeper shades, perhaps? It just, looks off, and I can't quite put my finger on it.

The issue is not with providing feedback. But with the fact that a staff complaint is used for it. Staff complaints are meant for actual errors or mistakes, and are usually treated as such by the attending staff. There's also nothing to be done with a staff complaint like this beyond going, "Okay," and moving on. Which is detrimental because: the specific issue of event feedback will probably get ignored (because, again, from the perspective of a staff complaint, there isn't much to do with a complaint like this one); the signal to noise ratio of complaints is increased, thus lowering their worth and severity. If the staff member is looking for feedback, he will utilize a way of gathering it. Regardless, complaint closed and now filed.

One cannot help but wonder what the point of such a mock threat would be.

Hoookay. Hi. I will be frank, I don't have time to properly read this thread at present, but from what I am reading this is turning into a what's basically an unmoderated player complaint. So here is what I'm going to do: Lock the thread. Flag a moderator or an admin to sort this shit out (issue warnings where necessary, purge the thread where needed, and reopen this if there is any meaningful discussion to be salvaged here). And here's a reminder. If you have specific complaints about the conduct of a player or a member of staff, we have specific sections of the forums to deal with this shit. Use it. Otherwise, your complaints will be removed and not listened to.

On the one hand, this begs the question of why do we keep writing such things into our species (specially the new ones, like the akutha). On the other hand. This is not necessarily an excuse to permit subversion of the lore. People are free to simply not play the species which are clearly written as being on the bottom of something. And let the free market sort it out.

Well. Lore enforcement is a tricky subject. With a lot of components. First, we have a lot of whitelisted people. While whitelisting serves as a basic litmus test, the system is gimped by the fact that there is minimal follow-up enforcement. Largely because there's no real reports coming through on the matter of lore breaking characters. But there might well be an underlying issue to that. Specifically, how many people actually know what to report in terms of a character breaking lore? How do you get that information to the players in a manner where they can quickly place all of this in their heads, and keep track of it? Lore itself is in a place where it's relatively complex, with political and economic issues taking the forefront. Perhaps we have slightly forgotten the basics on that count. There has also been push back towards certain ideas to making lore more easily accessible: people objecting to something as simple as putting up a concise list of characteristics (cultural largely) for a species, because it might somehow harm the player's attitude towards lore. These are largely things that the staff can do to better. But there's also playerbase-sided issues. As written here, it is hard to be an asshole, and it is far more easier to play a character that is liked by all. And this is from both ends: it is draining to play a character that's hateful, and it is easier to hate (from the perspective of a third party) the one actively antagonizing, versus the character who you should actually be antagonizing. We have to find some way of making playing all characters reasonable and desirable. Somehow. No clue how, though.

If memory serves, PoZe has ran quite a few, upwards of 3 - 4, PRs regarding Diona over the past 4 months actually. Which is not a bad number. Though the matter of, "Who notices these if no one plays the race" remains, one would suppose.

I would argue that's not what a complaint is for. Complaints should generally concern misconduct or rule violations. Running an event in a manner you disagree with is not any of that, unless you wish to argue that this was adminbus or not at all an RP event. But sure, footnote made. Proposing to close this unless annyone has anything else to say on the matter.

oh, I was still writing here apparently. Welp. Unfortunately, all of us like different things and so forth. Every event will be hit-or-miss, and If you paid attention to the round end OOC, then there were definitely people who also enjoyed the round! And possibly those people also voted for extended. In my opinion, the event was small enough to be in line with what was promised. And wasn't somehow detrimental to the HRP that was to be had. Sure, it could have gone better, but no rules nor guidelines were broken that I can identify, and beyond feedback on how to potentially handle things better, I don't really see anything else in this thread that's actionable. And as already pointed out, attacking it was not your only way of dealing with the matter. It was simply the station's decision to.