Jump to content

Arrow768

Head Admins / Devs
  • Posts

    1,698
  • Joined

  • Last visited

2 Followers

Linked Accounts

  • Byond CKey
    arrow768

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Arrow768's Achievements

Cyborg

Cyborg (35/37)

1

Community Answers

  1. There is one thing that I do want to point out in that discussion. Our setting is at a point in time, where most disabilities are by choice. Characters have the option to get artificial replacements for pretty much any organ they have. There can be reasons why a character might not want to go that path, but I do question if the Megacorps have to respect that choice in all cases or just go "if you want to work for us you have to meet those requirements. We can offer you a very attractive* repayment plan for those implants"
  2. As far as I know discord stores messages sent to a person if they are not online. Once they come back online they can then see the message that was sent. Why did you wait with sending the correction until lain was back online?
  3. From the information available to me you have told Lain that the person making the asylum request is in a relationship that is not publicly known. From the chat logs I can see that Hazel S-H9.09 answered your question about being in a relationship with: “[…] No, but we’re… close enough that I think he’s worried for his life even so, ma’am” How do you explain the difference between what you have been told ICly and what you OOCly told the human lore staff?
  4. Voting for dismissal. The other posters have explained well enough why „votes for host/staff in general“ arnt going to happen here. Regarding the duration of maintainer discussions: We try to reach a unanimous decision for PRs that are tagged with maintainer discussion. The first issue is finding the time when all maintainers are available and for some PRs we need to gather more information/ postpone it. (I.e. the vaurca bridge crew PR has been on the list of discussed PRs quite a few times by now) Regarding the XO as that has been mentioned in passing. Guess what: It’s still not implemented despite me having a branch ready since quite a while. I also want to point out again that I have mentioned multiple times by now to contact me via DM if someone wants to discuss these changes. So far not a single person has.
  5. As you have named the entire whitelist team in the complaint and noone else has claimed it so far, I will handle it. (Please excuse any spelling mistakes as I am writing that on my mobile phone while on vacation) Given that, I will not look into the issues that occured and only the statements you made afterwards: Regarding: "Unrelated Errors leading to a command whitelist strip" The current whitelist rules can be seen here: Command Whitelist Rules - Format - Last Update 02/11/2023 - READ BEFORE POSTING - Whitelist Applications - Aurora Station This is the section on the removal of command whitelists: In Addition the whitelist application format also contains this: "Do you understand your whitelist is not permanent, and may be stripped following continuous administrative action? [answer here]" As you have had multiple administrative interactions for failing to uphold the standards put in place for command whitelist holders, the whitelist removal is warranted. The current whitelist rules do not require that these failures to uphold the whitelist must be incidents that are linked to each other somehow. Regarding: "Not being able to explain your intentions" When sufficient information has been gathered to act on that information, staff members do not need to open a conversation with someone to discuss the infractions before applying a appropriate corrective action. (i.e. consider someone welderbombing, they just get instantly banned as griefer; The rest can be sorted out via unban/staff complaint) Staff Members are required to inform you in some way about actions taken against you. From what has been mentioned here, I believe that this has happened?! Given that you do agree that you have made a mistake, I do not see a failure to investigate this issue properly on part of the command whitelist team. (Unless you do want me to look into that closer) Conclusion: I do not see an issue with how the command whitelist team acted in this case, as it was covered by the currently established rules regarding whitelists and our general operating procedure. You are of course free to make a policy suggestion to change either of those. The "informal" motto of the head of staff whitelist is "easy to gain, easy to loose". I have inquired with the head of staff whitelist team and been informed that this is still the case and that you have not been banned from re-applying ever again. Should you reapply after 1 month, I do not forsee any major issues with a reapplication provided that you meet the requirements for a successful application. If you have any remaining questions/concerns please let me know.
  6. You are free to PR it if you want. Our Codebase is opensource so people can contribute their ideas. Even then, common sense is still required, as you can easily use the name/description changer of a vaguely related item to customise it to your liking and thereby circumventing established restrictions. To reiterate what I wrote above: the loadout in its current state can’t be a mechanically restricted authoritative source on when you can use a specific item (at least as long as we permit name/description changes). And that is not a problem, as you will be informed that a specific item is inappropriate for a specific character by the mods/min when it is noticed. I would be very surprised if any interaction with the mod/min team about a character-inappropriate item results in anything more than a talking-to/note (unless someone is actively trying to circumvent restrictions) I do agree that the loadout should provide some indication that a specific item is not for use by everyone. If you would like that feature you are free to create a PR for it.
  7. The loadout is not a authoritative resource of what is/isn’t allowed in the game. Just because something is available in/ can be done with the loadout doesn’t mean it’s allowed. (I.e. we had a HoS who created a centcom security ID card for himself. Obviously that was shut down as soon as it was discovered) The same thing applies to the ready screen. Just because you can click “ready up” on a hos character and could do so for a while does not mean that character has been created in accordance with the rules. Our enforcement will in almost all cases be retroactive: if a mod/min notices or is informed of something they will act on it. To proactively enforce just the two things you have mentioned would require a manual approval process of every character and their loadout items (as well as any changes to that). And that is clearly not practical to do. In addition we do not allow issues to continue once they come to our attention, just because they have been going on for a while now. (Otherwise someone could write into their characters records that they are the owner of the SCC and it would become canon lore at some point if noone notices it) I am not handling this complaint (for now). I am just correcting some incorrect assumptions that are part of this complaint.
  8. I would like to point out that once a complaint is retracted its retracted. There isnt going to be a revive card for the complaint.
  9. This complaint has been discussed and dismissed by the headmins/devs. The implementation that I communicated was discussed by the headmins/devs before it was communicated. As such you would have to file a complaint against all of the headmins/devs which is not possible. However, I will post my point of view on the concerns raised. I am aware of this issue, and I consider it already rectified with the appointment of Matt as second headdev. Matt has pretty much the same powers that I have as a headdev, however I still reserve a right to veto/override decisions on a case-by-case basis (primarily to be used when it concerns hosting questions). Votes have always been non-binding and merely a way to gauge the general opinion of the playerbase on a larger scale. As such the timeframe when or if the results of a vote are announced is not important in relation to a implementation of a specific feature. As mentioned above. Votes are only a way to evaluate the opinion of the larger player base and not a promise to implement something in a specific way if a vote passes. I believe it is also important to point out (again) that the vote did not mention Xenos becoming the second in command of the ship. The thread was locked after certain people were unable to have a civil debate in a public setting. In the closing post (I encourage you to actually read it), i have made the following statements: as well as Not a single person has contacted me so far regarding the 2IC XO (to the best of my knowledge).
  10. I have locked this complaint for now because it is becoming another 2icxo feedback thread. I should note that this does not mean the complaint is closed.
  11. That has been added. You can order multiple meat slabs in one order and they are thrown together into the same freezer -> Just order as many as you want and you will get them. I have reduced the prices accordingly as they were priced quite prohibitively. You can order multiples, and they will be placed in the same crate. And that has also been added.
  12. As there have been no further replies I am closing this complaint and moving it to the archive.
  13. This is not a reason for a staff complaint. Every PR has to go through a review process and be merged by a maintainer. To advance the current gameplay loop new things have to be tried out from time to time. As such things that might be outside of the established gameplay loop will be merged from time to time. Such changes are expected, and it is also expected that the author continues to tweak problematic PRs in coordination with the maintainers (which is happening in case of the cult PR) until these PRs fit into the standard gameplay loop (or are removed). The maintainers monitor this process and do reserve the right to take actions themselves if a PR author is unwilling/unable to tweak a problematic PR (which does not seem to be the case here). As you have been part of the community for a while, I believe it to be likely that you do know about the "no revert for 1 month" on new/controversial PRs-Ruling (from quite a few years ago). With that in mind I can see how Dreamy came to the conclusion that this was a kneejerk reaction to a PR that was just merged in an attempt to bypass the "no revert for 1 month" ruling. (Especially when considering that the PR has been up for almost 2 months). It could have been worded better, but ultimately, they are calling it out the way it appears to them. The only thing I can fault dreamy for is the attempt to vote for dismissal on that policy suggestion (which developers are unable to do according to the established rules for that sub-forum) I have discussed that with dreamy and advised them that: They should be more considerate when choosing how to word their response They cannot vote for dismissal on policy suggestions. The vote for dismissal on the policy suggestion by dreamy will be removed.
  14. I’ll handle that complaint. At a first glance it seems relatively simple so I should have a update within a few days.
  15. Well, during lowpop time there aren't a lot of people online. So, there's a good chance no one is going to be there to set up power if they join as off-duty crew. And with that power will run out in ~~45min or so.
×
×
  • Create New...