Jump to content

Kyet

Retired Admins
  • Posts

    2,129
  • Joined

  • Last visited

  • Days Won

    48

Posts posted by Kyet

  1. Lately, lots of things have been competing for my time. I need to focus on the most important stuff, the stuff that will make the biggest difference to my life in the long term. Things like my career, relationships, etc. I have a lot of big goals, and I need serious focus to achieve them.

    So, I'm stepping down as a head on Paradise. To free up some time, and mental energy, for working towards my goals.

    I might stick around for a bit as a regular game admin. We'll see.

    In the meantime, I wish you all the best, and remember: never let videogames stand between you and your dreams.

    • Like 18
    • Thanks 11
    • fastparrot 1
  2. I don't think this is a good idea.

    For one, it seems like it is just gonna get used to harass borg players.

    For another, the best use for it (giving a borg player a medal) is weird, because... borgs are technically property, not crew, so it would be weird to give them a medal.

    I'm quite sympathetic to the idea that borgs *should be* crew, but right now I don't think they are, which would make giving them medals weird.

  3. On 7/30/2021 at 11:16 AM, AllStickySocks said:

    Very quick and simple. Is anyone against having snow machines year round instead of them being a Christmas only thing? I really want to make my drask paradise room and have snowball fights.

    Yes, I'm against it.
    Snow really makes zero sense indoors, especially indoors on a space station.
    While in theory you can create it with a machine, why would you? In practice it'd just make getting around onerous, not to mention issues with temperature, visibility, etc.
    Also, having it year round would make the xmas period less special.

  4. 12 hours ago, Charliminator said:

    What do admins think of people constructing cameras in maints? when/when are they not okay. can maint drones make them? is it powergaming? a couple different admins have given me different answers and I always feel weird ahelping about it because there is no general consensus on it. 

    I would love to hear the communities/admins/heads thoughts on this.

    In my opinion I believe they shouldn't be built on blue/green under the powergaming rule.

    On green, its considered powergaming, and not okay.

    On red (ie: with a known threat) its permissible.

    Drones should probably not do it regardless of code level. They should focus on repairs. Drones installing new cameras comes across as ghosts just trying to make the antags fail.

    • Like 5
  5. On 7/9/2021 at 1:03 PM, AllStickySocks said:

    Would you be opposed to some type of labeling system that allows heads to remain anonymous while still giving a sense of feedback about what is happening to a PR? Or is anonymity a deal breaker? @Kyet

    I don't object to the addition of a labeling system, but I am also very skeptical it would help.
    How exactly would it make life easier for the maints/heads, bearing in mind that heads cannot label PRs? You'd need a convincing answer for that.

     

    On 7/9/2021 at 2:14 PM, SabreML said:

    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.

    Intuitively, I agree with you.

    In practice though, you're not taking into account (and historically, I have failed to take into account) that:

    • maints can get an enormous amount of harassment over even normal PRs, and this is even worse for PRs they object to. AA just did an announcement within the last few days complaining that he got 14 DMs in the space of a few *hours*. Imagine dealing with dozens of DMs per day, every day, about PRs. In practice, you would quickly get super tired of this and it would make you re-think your willingness to publicly state objections to things if you thought it might lead to yet another hour of being deluged in DMs.
    • maints are volunteers, and there's a limit to the amount of free time they can afford to spend doing free work for paradise without it hurting their real lives. While it may sometimes be frustrating for PR authors, ultimately the more time they spend arguing with authors over why their PR does not deserve to be merged, the less time they have for actually merging other things, and the worse the PR backlog gets. Sure, in theory simply stating their objection won't become a long argument, but in practice it often does.
    • there are some extremely toxic people on github who will raise UNHOLY HELL about even trivial, terrible quality PRs being rejected. Such people are incredibly energy-draining to deal with. The maints having to spend time on those people is demoralizing.

    I've been told this week that the reason I get away with having a "always explain my objection reasons on the PR" policy, and don't get harassed as a result, is that people fear me.

    Unsurprisingly, I mostly disagree. For one I don't think most PR authors fear me. For another, I think that by stating my objection reasons publicly, I have demonstrated I am quite willing to defend my position, and that makes people less willing to challenge me over it. There are also other factors, such as the fact I think maints get a lot more harassment over PRs in general than heads do. Another possible factor is personality differences. Essentially most of the maints and some of the heads dislike coming into conflict with other people, and really don't enjoy having to argue. Deep down, they want agreement. In comparison, not only am I totally comfortable with disagreement, I even enjoy arguing at times (I spent a fair amount of time in college debate clubs, arguing for fun). I'm also used to operating in environments where consensus is impossible, yet decisions have to be made, so you have to accept some pretty sharp argument (and the fact some will leave unhappy) as the price of admission.

    All combined, this means that most of the maints/heads are a lot less willing to explain their objection reasons than I am. And to a large degree this is understandable. While I'd certainly *prefer* they explained all their objection reasons in public like I do (it hasn't always been easy, but I do believe it gets easier the more you do it).... in practice that just may not be doable for them, and certainly not without asking them to go against their instincts, natural way of doing things, etc. And while it might obviously be fairer for PR authors if all objections were accompanied by a reason... in practice if I had to choose between the other heads/maints always giving an explanation for their actions... and y'know... actually getting the work done... obviously I'd prefer they actually get the work done.

    So I guess what I'm trying to say is... we can't force the other heads/maints to always explain their objections. And even if we could, the time that would require might be counter-productive. What we can do is reduce the cost they perceive for doing so, largely by making sure that people aren't allowed to harass maints over their objections. Which we are doing. Via the new guidelines on github.

    So yeah, I sympathize with your point of view. Still, instead of looking at it from an "is this fair to me as a PR author?" angle, I would encourage you to instead look at it from an "given the limited time/energy/morale/etc of the maints/heads, when is it worth, or not worth, explaining an objection?" angle. Because while sometimes it clearly is in the best interests of the project for it to happen... other times... its just sapping maintainer/head morale for no benefit.

    • Like 4
    • Thanks 1
  6. S34N:

    • ~59% of all PRs have a head approval. There's ~21% another of PRs that are either pure fixes or refactors that either way already don't require head approval. Thus, the chances of head approval being the thing holding up any given PR is less than 20%. Approximately 63% of head-issued approvals for PRs are issued by me.
    • Removing the requirement for heads to approve feature PRs is not an option. That would just put even more of the work onto the maints. As is, we serve as a sort of filter that stops maints wasting time with things that obviously won't work for design reasons. The requirement for our approval lets us reject those so we prevent them wasting maints' time. We also buffer some of the toxicity from players, so they don't have to deal with it.
    • Ideally we would appoint new maints, but its almost impossible to find candidates for the position of maintainer that are acceptable enough to all the existing heads/maints that they can actually be added. I went on somewhat of a crusade during my two years as head+host trying to get more maints appointed, and even then I was only able to get one extra maint (AA) in the end. Politically, getting a maint appointed requires an extreme level of agreement among not just the heads but also all the existing maintainers. It is an incredibly difficult process. I've always been keen on the idea of junior maints but frankly with all that has been going on in my real life lately I quite simply don't have the energy for such a difficult task right now.
       

    Stokes52

    • In general, getting a feature PR merged usually requires (A) one head approval (B) one maint approval and (C) no heads or maints objecting.
    • When I post a review of a PR that has a green check mark / marked as approved, I am saying that I am voting for that PR in my capacity as a head. Now it requires only (B) and (C) to be merged. I use my reviews to make my votes public. I have tried to encourage other heads/maints to adopt this system too, but most of them don't want to, partly as they dislike dealing with backlash on github. They don't like having to explain why they object to PRs, because they don't want to deal with PR authors messaging them "what do you mean, my code is terrible" or "what do you mean, you don't need another X in the game".
    • When I post a non-approving review with the word "objection" in it, I indicate that I am voting against the PR. A head or maint voting against a PR doesn't automatically kill it, but it does make it MUCH harder for it to pass. Generally it can only pass at that point if another head votes for it regardless, a maint votes for it too, and a discussion is held among the heads/maints which ends with the resolution that it will still be merged despite the objection of at least one head or maint.
    • As for progress indicators, you should probably assume that if it has a head's review/comment explaining that they like the PR, then its waiting for maint approval. If it doesn't, it is still waiting for head approval.
    • Like 7
  7. April 10:

    • Vargh has retired from Game Admin

     

    April 22

    • Drakeven has gone on leave as a Game Admin

     

    May 5

    • SpacemanSpark has retired from Game Admin


    May 7

    • Pineapple Salad has passed their Trial Admin period and been promoted to full Game Admin


    May 9

    • eler00 has retired from Game Admin
    • fastparrot 1
  8. The code that handles our forum/Discord integration has been updated.

    The main change is that the code now uses the latest Discord API.

    This is important, because Discord is going to turn off the old API, so had we not updated, our Discord integration would have abruptly stopped working sooner or later when Discord did that.

    Other then that, the update is mostly just bug fixes. Don't expect any obvious difference.

    If you do notice anything odd, though, let me know.

    • Thanks 1
  9. My real life has become so busy, that I can no longer afford the time to host Paradise.

    So, over the next month, I will be stepping down, and our resident Java expert@AffectedArc07will become the new host.

     

    This means:

    1. All-new servers (with higher specs!) will be built. My hope is that the new AA-rated servers will have better performance.
    2. Our backend will be replaced. I expect the new backend to be better, and provide better tools.
    3. The number of coffee-related jokes in our Discord will increase at least 20%.


    For the next few weeks, my focus will be on ensuring a smooth transition.

    That means providing all the necessary documentation, training, etc.


    Before you know it, though, AA will be running the entire backend of Paradise. Probably with a Barista supporting him.
    Hosting is a fair chunk of work, so please be nice to him, and patient with him if he says he is busy.

    To answer the inevitable questions:

    1. Exactly when is the switchover happening? => When AA is ready. Don't rush him. He's rebuilding every server we have, using brand new technology. It is important to take our time and get it right. The road towards switching may be long, taking a few weeks, but it arcs towards progress.
    2. Will my ping to the server be affected? => No. The new server will be in the same datacenter, with the same great connection, as the old server.
    3. Is AA staying as a maint, as well as being host? => Yes. He's doing both now. He might even do the billing paperwork for the servers himself. You could say 07 has earned his license to bill.
    4. Is Kyet staying as a head? => Yes. You can't goat rid of me that easily. I'll be around, at least until the transition is complete. After that, it depends on how busy my RL gets.
    • Like 8
    • Thanks 4
    • stunbaton 1
    • explodyparrot 5
  10. 7 hours ago, TheYeetster said:

    Tagging @Kyet because he made the Syndicate Research Outpost, and was wondering what his vision for the Syndicate Research Outpost is.

    What:

    Maybe its just because the SRO is new, but currently the SRO seems to have little interaction with other people in the SRO. Often ghosts spawn in,  either practice making death chems, help traitors on the console or get into a massive Donk Soft guns battle (which is all well and good), but it would be interesting if there was some more low impact RP. That is why I think it would be a cool addition to move the syndicate jail into the Syndicate Research Outpost. 

    Why?

    When Syndicate contractors abduct people, the abductees just sit in a cell. It would be more enjoyable/interesting if there was some interaction that abductees could have rather than solitary confinement, and this would also be interesting for the researchers. The syndicate research base is the perfect opportunity for some low impact RP. 

    I think it would be cool if the researchers had some way to torture abductees for information, using chemicals, botany plants or viruses. I'm slightly worried about people being killed or irreparably mutilated. Maybe the Syndicate Researches could be given some incentive not break prisoners too badly. (need ideas here)

    How?

    RP wise it would look like this:

    Syndicate researches are, along with their other research, researching new interrogation tactics / torture techniques. S.R.O. Scientists have torture implants / tracker implants, that at the request of request of syndicate contractors could be implanted. Syndicate Researchers would also get to interrogate and torture abducted crew for information, take blood samples, experiment on the abductees for a few minutes. Then return them when CC pays the ransom.

    Ahhh too much!

    If this is too much for the SRO, It could be toned down to just an interrogation cell with no torture, but it might loose that research aspect. If this is case it might be interesting to add a syndicate warden, who would watch and interrogate prisoners. The warden would also oversee the syndicate armory.

     

    The vision I outlined on the PR.
    Basically it lets newbies practice mechanics in peace, without having any significant impact on the round.
    Also, the official name for it is Syndicate Space Base (SSB).  While I did make that up... its also what I called it in the code, so if you invent another name for it it'll get confusing.

    There are many issues with moving syndi jail there:

    1. Someone with a tracking implant could be abducted, allowing a whole army of sec to use the teleporter to teleport to their location and invade the base.
    2. Prisoners could be killed, maimed, etc, which was not intended by @Mochito happen when syndi contractors were added.
    3. If the base was destroyed, there'd be nothing stopping 'captured' prisoners from escaping instantly. Even worse if the base is spaced.... captured prisoners would be returned dead.

    If we went this road (and I'm skeptical of it, frankly) then we'd have to only allow researchers to TALK to the prisoners.... and relay whatever info they give to other traitors over comms in exchange for a reduced 'abduction' timer.

    • Like 2
  11. On 3/24/2021 at 11:26 PM, TotoMC01 said:

    Hi, I accidentally linked my byond account (TotoMC) to my secondary discord account TotoMC-2#4112 (I use it for testing discord bots) and I would like to unlink it and link it to my discord account TotoMC#1624 

    Hi. @TotoMC01@TotoMC

    Your current setup is this:

    • Unlinked(ingame) -> TotoMC01(forum) -> TotoMC#1624(discord)
    • totomc(ingame) -> TotoMC(forum) -> TotoMC-2#4112

    Your forum/discord accounts cannot be delinked from each other, because your forum accounts were created based on your discord login... which means if that is de-linked they become unusable.

    However, you do have a few options for fixing this:

    1. You can go to https://www.paradisestation.org/forum/settings/ and simply change the display names on your two forum accounts so they match the discord accounts they're linked to. Or you can ask me to simply swap over the displaynames for you.
    2. You can ask me to de-link your totomc byond account from your totomc forum account so you can re-link it instead to your totomc01 forum account. (which, with the above displayname change, would become your primary forum account)
    3. You can ask me to delete both forum accounts and then you can re-register them using normal non-discord registration, that will let you then associate whatever discord account you like with them, and it will also mean you can delink/relink them with discord at will once they're re-created.

    Let me know what you want to do.

  12. 22 hours ago, SabreML said:

    Personally I'd like to see the exact opposite of this, maybe even to the level of drinking everything in the bar and barely even getting a buzz.

    Take our current vox population.

    Now give them an excuse to drink everything in the bar.

    Improvement?

  13. Here is what I propose granting:

    Mentor:

    - autopatrol, patrol (we should not need to double-check the edits of mentors, and they can check others' edits, giving both of these out more widely would make the unpatrolled edits list special page much more useful)
    - rollback (any editor can already revert someone else's changes, this permission makes it a bit easier)
    - suppressredirect (players can already move pages, this just lets them do so without a redirect - useful in a few cases but not something most editors need)

    Admin:
    - delete, delete-redirect, deleterevision, deletedhistory, deletedtext, browsearchive (all these permissions are about removing stuff or seeing removed stuff, so maybe admin-only, but since deleted stuff can be viewed with the "undelete" permission its less "delete" and more "hide for most people". Even then we basically never use these - the best argument for "delete" is "lets us delete old/outdated files" like old images of which there are over 200 on the slated for removal list)
    - block, hideuser (this is basically banning, but only for the wiki, and given how the wiki requires forum auth, we should probably keep this admin-only, I don't see us ever needing it, its really just an emergency-use-only button)
    - mergehistory, suppressionlog, viewsuppressed (this covers "private logs", so perhaps admin only)


    Nobody:

    - unwatched pages (useless, its a list of basically every page/file, its not helpful)

  14. 1 hour ago, Rurik said:

    Just trying to understand the reasoning of such a precedent going forward. 

    Personally, I would prefer it if it was simply never allowed to unwrench pipes to counter ventcrawling antags. For exactly this reason - from the antag's perspective its often uncounterable gameplay. Their options become "stay in the room and eventually get swarmed and killed" or "attempt to run through the pipe anyway and pop out right next to someone who is prepared to shoot/axe you".
    That said, I made this change anyway because the other two heads wanted it. Its one of the cases where I implemented something I don't personally like because of its popularity with the rest of the staff.

  15. I am fine with having a dedicated staff member whose job it is to oversee the wiki.
    I am also fine with giving expanded permissions to:

    - Mentors (e.g: patrol, autopatrol, maybe rollback?)

    - Wiki Contributors (unsure what I'd give them)

    - Some sort of new not-an-admin-but-has-curator-permissions-on-the-wiki role (maybe delete pages, probably not bigdelete/blockuser)

     

    • Like 1
  16. For what it is worth, I am rarely in the Bridge as Captain, and yet I rarely get killed.

    I do, however:

    1. Max my suit sensors at roundstart, and then re-max them after any kidnap attempt
    2. Drag the blueshield around with me if I am going anywhere except brig and he's available. If he's not available... wait for him to be available, or get a sec officer as an escort, or go alone but be more cautious.
    3. Give the blueshield the pinpointer too so they can locate me via the disk I always carry
    4. Avoid acting like security, this includes chasing threats who attack you too far - instead just set them to arrest and let sec pick them up
    5. Avoid entering maint unless its a shortcut to a non-maint room you're running to (e.g. hop office maint tunnel shortcut to mechanic)
    6. Call for backup earlier than you think you need it
    7. If attacked, scream for help + location on radio
    8. Avoid standing in any dangerous area
    9. Avoid letting anyone chase or follow you - if they seem to keep following you, mark them
    10. Move very fast, such that if someone loses sight of you for 3 seconds, they will never catch up
    11. Get pre-scanned
    12. Use the door remote.
    • Thanks 1
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use