Jump to content


Head Admins / Devs
  • Content Count

  • Joined

  • Last visited

About Skull132

  • Rank
    Head Developer
  • Birthday 14/12/1995

Personal Information

Linked Accounts

  • Byond CKey

Recent Profile Visitors

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

  1. So, there is a relatively long list of items to unpack here. And I may not get around to all of them in this first post. But we shall try to get the ball rolling at least. First and foremost, regarding the recruitment of a new deputy. We are of two minds on this. VT, you were told that an existent deputy coming under review would be a possibility and said, "We can discuss that later". Well, it was discussed, and a decision made. Claiming ignorance or holding faith in a previous instance, effectively discarding this note as, "unlikely to happen", was a decision you made and it bit you. You could have at least asked and drilled deeper about it, instead of binning it immediately in your mind. However, this is not to say that the situation could not have been handled better by Jackboot either. He should have been more firm (1) in handling the issue, by either slowing you down and making sure you are clear on the matter, or by just resolving the issue immediately, before permitting you to open up the apps. Arguably the latter would most likely have been the optimal solution. As an immediate fix, the hard limits on deputies have been codified, and we are considering applying heavier oversight to the recruitment of the lore team down the line. Moving on, regarding oversight and general management. This is a bit of a harder nut to evaluate, and I will be gathering a bit more feedback on the subject from other lore devs. In general, though, there does seem to be consensus that Jackboot focuses on specific elements of lore while neglecting others. I have also heard mentions of him having bias towards the creative decisions of specific individuals over others, but, as noted, this is due for a bit more discussion, to be carried out this week. One general solution that has been proposed for this has been the separation of the role of lore master from that of a species maintainer. Specifically, to ensure that the lore master is able to focus solely on actually managing lore, instead of actively writing it as well. Granted, this does have issues, specifically regarding motivation (someone who wants to be purely a manager is harder to find than someone who's willing to do managing as a side job). But we shall see. Related to management are also the two following notices. Firstly, regarding the complaints raised by Neinbox. Much like Abo has said, we find these bordering on excessively nit picky, to use a set of phrasing. If the established modus operandi for the lore team has been the review of works in progress via Google Docs, then you are obligated to enable this as a member of this team. If you do not wish to do so, then understand that failure to partake in the modus operandi of the team is grounds for removal. An analogy would be: the developers use Github to submit code for review. It is possible to use other means, like email, to submit diffs, but I assure you, your contributions will not be reviewed nor admitted if you did not go through the established channels. Overall, I feel like Jackboot should have been more active in resolving this, at least finding you an active replacement (2) while you were on leave for a good few months. He gave you a lot of space, and there has been regular pressure from myself, since January, to get Diona development actually active again. (And no, promises of hidden projects are not a good thing to try and fly with me.) The second note is related to what Moon said: While I disagree with the interpretation of these as "threats", I do see a bit of a trend. Jackboot is lenient (3). Very lenient. In my opinion, had he just put you up to the fact that your activity needs to improve, then that conversation would have perhaps carried less animosity with it. And perhaps this would have applied to others as well. One thing to take into consideration, due to the fact that most staff slots are limited, is that inactive people should be getting actively rotated out. And this does include basically letting people know that their activity is at an unacceptable level and it is time to go. This applies more so where the billet count is more limited (e.g. species maintainer positions). The numbers indicate a minimum amount of places I saw wherein Jackboot could have and should have acted in a manner more firm and to the point. This would be my bet at one of the core underlying issues here. I am curious to know what @Senpai Jackboot himself thinks of this interpretation. Addendum: "We" refers to all of the Head Admins and Head Devs, as per our internal discussions. "I" refers to my personal views and interpretations.
  2. Doesn't fully address the issue, simply shifts it. The core issue is that there is no mechanic nor sure fire way to get an agreement. So saying that there is one that'll be made is a non-answer. IMO some sure fire way of ensuring a theme is picked for the team must exist. Possibilities include: Mechanical voting amongst team members. Designating a team leader who has the final say. Randomly picking from a pool.
  3. 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.
  4. Skull132

    Ask a mod/admin!

    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.
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. What does this help to establish that corporate regulations, station directives, and job descriptions already have not?
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...