Jump to content

Skull132

Members
  • Posts

    3,166
  • Joined

  • Last visited

Everything posted by Skull132

  1. I'll put this on record. Instead of spamming schlorgos everywhere, let's think of MORE critters to replace common animals with.
  2. Lag wasn't the issue*. And we don't want to remove Zs. We were kinda just forced to. Ergo, there's no argument presently for removing another Z.
  3. (^ Aurora server's hardware.) Ye I don't think that's the issue here boss.
  4. Well I mean. The decision is already made. People are free to map solars onto the surface or interstitial level. Or onto the bottom space level, actually. ?
  5. As some of you may have noticed, over the past few weeks the server has been experiencing episodes where you can move around, but absolutely nothing functions. To include IC chat for the most part. This is typically what happens when the server gets close to or exceeds its memory capacity of 1.8 gigabytes. (This limit is INTERNAL to BYOND. We cannot modify this. We are stuck with it.) Why are we suddenly getting close to this limit? Who knows. Profiling the memory usage of the server is incredibly difficult and the tooling for it (up until recently) very poor. Though I suspect some of the newer features being memory intensive. And even if we did locate the culprit, we would have to weigh whether or not we actually can do anything about it, without outright removing the feature(s) responsible. So as a semi-permanent stop-gap. We nuked a Z-level for about 100 megabytes of more headroom. Which appears to have worked and calmed down the crashing. The Z-level that was removed was the roof, since it was the most superfluous one, in terms of mapping. Stuff from it can easily be slapped onto the surface or interstitial, if someone wants to have a go at it. so ye. no more roof.
  6. The only other mechanic cited here that does similar damage is headbutting. Minus very large weapons I guess, like fire axes, that can deal a maximum of 25 brute per attack. But those are slooow, and take up your other hand. See the problem is that this is power creep. "Look we have a 20 damage attack so we might as well get the 25 one!" No, we might as well not. If head butting becomes an issue, then we'll nerf that as well. But it has yet to be proven as such. If you say that bug bite is useless as it stands then maybe simply accept that the idea behind such an attack isn't what you want it to be (widely useful), and come up with another idea on how to make combat as a bug interesting. Again: a 25 damage no-penalties fast-attack is not it. There's technically a way but the mandibles are still too stronk according to other factors. ADDENDUM: Alb pointed out that we could make the mandibling drop the grab, to make it impossible to chain head buts and mandibles. Though this still leaves us in a situation where mandibling is a straight upgrade from 20 damage and 10 self-inflicted damage to 25 damage and 0 self-inflicted damage.
  7. A 25 damage insta-attack is not the way to go about buffing them. At all. High damage attacks should require some form of commit and come with a way to dodge or other penalties. Bugbite was removed due to it missing all of these characteristics and just being a really strong special attack with no downsides. Free real-estate, as it were. Other attacks being more convenient in fast moving environments is not necessarily a bad thing: as noted in the PR, the change made the bugbite into a finisher or into a very specific kill-move. So other attacks being more usable makes sense and is intended.
  8. What if we. Don't? Because I'm pretty sure we don't.
  9. Staff complaints which, for whatever reason, need to remain confidential, should go through the respective head of staff. This system already exists, per say. The only short-coming is what Arrow highlighted, namely the fact that these investigations aren't logged and marked down too well. But that is not necessarily tied to how the complaint is issued. The only cases where you would ever use this system is when a staff member has done something incredibly egregious or dubious. And historically, this has been the case. Player complaints of this nature would receive a, "Hell no" from me. The only time a player complaint would deserve this level of confidentiality is if personally identifiable information is involved. In which case, again, you go to the head admins on discord/forums.
  10. And if the answer is "Yes", then we should probably start another poll to determine in which way the AI can be nerfed, yes?
  11. Let us remind ourselves of what happened that other time when SS13 had a very clear tell-tale mark of an antagonist: the ling blood test. To those of you who weren't around in the 2010 era, the blood test entailed that if you apply a welder/zippo/whatever to a beaker of ling blood, it'll "jump". Any other type of blood would do absolutely nothing. This resulted in frantic testing of everyone's blood the moment a ling's presence was suggested. Thus removing the "murder mystery" part from the murder mystery antag. The generalized output from this should be that specific tells like this will likely be used to powergame/metagame to fuck. To that end, if we want to ask, "Why does ling have a specific tell!" I would propose we remove the ling's tell instead. Plus, there's already pretty decent tells (or were, maybe brainmed altered them a bit) for vamps. Typical result of a succ being inexplicable oxygen damage showing on the CMC if the sensors were left on. And as was discussed in discord, the probably best solution would be to just give autopsy staff the ability to measure blood quantity remaining in body along with general damage done. (Tho this already exists if you have access to a body scanner?) That way, common damage criteria could be used to identify vamp if you wanted to.
  12. Only two of the three names listed were actually developers. Both of those were removed following citations and otherwise punitive action against their conduct. Mistakes made were admitted to in respective threads and discussions. You could spend the next however many years trying to reopen old wounds, but that doesn't change the fact that they were (eventually) dealt with, and cases of this nature haven't popped up since. Further, to claim that I liked all 3 of the people listed, or that I even enjoyed having all 3 of them around, is an unimaginable stretch, if you've ever actually been in staff discord to discuss them. You are free to report any member of staff's conduct to members of the administrative staff via the relevant means (report button on the forums, ahelp ingame, ping on Discord). This has always been the case. Developers (and other staff for that matter) have received forum warnings for various posts. What you outline cannot work. Ever. When you host a server, someone's account has to be billed for it. This means that someone's billing information is going to be available and it is unreasonable to expect a member of staff make it public to other members of staff. (Specially if we're talking credit card information, which doesn't required 2FA to abuse.) The only way to achieve what you describe would be to set a full non-profit or other legal entity. But for obvious reasons, this is a way excessive ask. The current way gives every member of the server's leadership as much control as is possible, without compromising my personal information to a degree with which I feel uncomfortable with. As I have told you many times before: all 4 members of the leadership (head admins and head devs) have near-full access to our infrastructure. The only thing I can practically do, that others cannot, is pull the plug on it all. But this is due to what I outlined in the earlier paragraph: someone has to pay, and whoever pays has full control over the service. I do not get where this is coming from. Either you're implying that admins cannot police other admins (which is false, seeing as how we have admins and even mods deal with player complaints about admins), or that admins cannot properly handle complaints about developer conduct. There is no magical third place here for people like Matt or Alberyk. For complaints about developers, yes the Head Devs (and now also maintainers) tend to handle team, with the principle being that the leader of the respective staff team is responsible for handling conduct complaints about them (which is why you see the lore master handling complaints about the conduct of lore devs, and not the administrators directly, unless it's relevant to their domain). What everyone should know about this process is that every such complaint, if non-trivial, is typically discussed within what we call the Deputy Shadow Council. Which is really just a pretentious name for a Discord channel where all team leaders (deputy and primary) are present. This includes the Head Admins. This means that, contrary to your understanding, the administration is involved in resolving these complaints. This policy doesn't exist for players; why should it exist for staff (specially staff who aren't dealing with direct administration)? This has been discussed in similar threads before: Aurora's enforcement of "Don't be a dick" rule is incredibly long-winded. In this very thread, there are people who've skirted by under this rule for way longer than some members of this community think is reasonable. The rope eventually snaps and the person gets removed/banned. The same rope is extended to staff as well, and thus far, in all cases, it has eventually snapped. This is one of those, "What's truly correct here?" questions, where being too heavy handed with the rule does (and has, if you'll remember the era of FFrances as head admin) cause backlash in the opposing direction. Also. No such policy can be enforced without players reporting instances of these abuses. Neither can the current policies work without the same reporting. The idea of these "Unique little kingdoms" is the foundation behind Aurora's policy on how to handle staffing. (And there's a falsehood or two here as well.) Every team is trusted with an area of responsibility and no team shall undermine this. This is done to minimize conflict between teams. The exception is the Administrators, who actually have all-access to staff discord, minus leadership channels. And even this has already created minor issues and needless friction between staff members, as Administrators poke their noses into matters that they are not fully informed in or involve themselves in discussions in a manner that does not jive well with the MO of the staff team whose room they're interrupting in. (This is not to say that I'm calling admins out, the mistakes in question are human, this is just to highlight why such extensive freedom is given in the first place: it minimizes needless friction.) Further, the falsehood I mentioned in the beginning is that admins do not police the areas you suggested. ALL aspects of the forums are subject to oversight from the server mods and admins. Meaning that you can hit the "Report" button anywhere, and an admin or a mod will deal with it. Not a developer, not a lore writer: an admin. If a developer is the subject of the report, then for small infractions, a warning is given per MO. If it's something larger, then the admins typically ping the head admins and the respective team leaders for further disciplinary actions. Psure Fowl got forum banned by the autoban system as a result of this (per the same standards a player would have been). Github does not fall under this oversight because Github is considered a tool for the development team. It is not a place for community-wide discussion: it is a discussion place about code and gameplay considerations first and foremost. If you start treating it like the suggestion forums, then that discussion is just going to move somewhere else, less accessible to the community. Again. I maintain that we have treated members of the dev team with more-or-less the same rope that we've given to some players. And again, you're scratching up old wounds that have been dealt with: you have no new cases coming even close to the magnitude of Nanako or Fowl to reference. Clamoring for public executions and hard lines is not something we wish to deal with.
  13. What you posted right now, @Resilynn, is both missing context and smells like shit posting (specially considering that it was in a chat where Geeves doesn't have his rank colours). And there's a metric ass of this in this thread. Either posting content without context, lying through omission, or flat out lying. If y'all ever want to figure out why staff are hostile towards you, it's because they're apparently not permitted to relax and chat shit without someone somewhere using it to claim they're a despot.
  14. Accepted per Lancer and closed.
  15. No new corps are planned, the current ones will be used. Independent roles will likely remain as they are, they're outliers so w/e. I mean. Someone has to do the low-skilled work? Whether or not your character sees service on a spess-ship as a good career path is ultimately up to you to decide. We cannot make every concession and obviously certain characters that would fit Aurora will not fit the ship. This is inevitable for any major change in setting.
  16. The magic of open source. You're free to join in. Could start by pinging Taco.
  17. What I'd ultimately like is for all parties interested to contribute to the same project, whatever that may be.
  18. LLVM is a dumbass idea. I discussed this issue with Moondancer back in uh, December, a lot. And we did a bit of research. I do agree that any custom language will have the issue of documentation. But there are a great few butt's here. So lemme condense the analysis we did during that exchange. First, regarding documentation. I will thoroughly agree that any language needs good documentation, and that if we do not have it, we're fucked. This is actually something the original NTSL suffered from greatly: there wasn't any good documentation, just a tonne of example codes anyone could copy-paste. In my view, there's 3 things that need to be documented for any language that gets implemented as a replacement for NTSL(.*): language syntax, standard library, custom interfaces. Using an already existent language takes care of 1, since the syntax is expected to be documented in that case. 2 will also likely be largely taken care of, though we'd likely have to document what limitations we've applied. 3 is a "No" in both cases. So let's go look at the documentation for NTSL2, and see how many boxes we can tick off. 1 is there, 2 is there (actually surprisingly well done). What's missing is 3. There's absolutely nothing describing how the fuck this language interfaces with things like TComms or ICs. Replacing this language with something else does not inherently land us in a better place on this front. Next up, security! Security comes in two aspects: server security and clientside security. Both were a fuck in the case of the original NTSL. With the culmination of NTSL being bitcoin miners running on the server clients. However, this threat will remain with any of the languages implemented, since this is inherent to the implementation of the language's front-end(s), and not the language itself. The other, more pressing (to me) matter is server-side security. If someone gains access to run IO functions on our server, then we're all in for a treat. Secondary concerns are interpreter lock-up and OOM (though since we use docker for the interpreter currently, this isn't that large of a concern). This is also where the research by myself and Moondancer comes in. A lot of the languages listed above are not sandboxable. Embeddable Python interpreter README's literally say, "Do not use this to run untrusted scripts, it will not end well." Same for most JS engines that we looked at. The best we could find was a few Lua interpreters, but even they had warnings. Server-side security is one of the places where a custom language actually offers the best benefits: if it's implemented in a higher level language that handles garbage collection and the rest, then sandboxing it is a simple matter of simply never ever giving it access to IO functionality. And you'll be ahead of most other embedded interpreters on that front, since sandboxing those typically requires maintaining a blacklist or other similar solutions. Another consideration is developer bus-factor. Well, this is gonna remain high no matter what, probably. The project of creating an interpreter is one which requires a high degree of technical aptitude and while we do have a list of people who possess that aptitude, it is unlikely that more than 1 person invests themselves in this project unless needed. So going with anything else would really only replace "Look at and figure out Taco's shit-code" with "Look at and figure out X's shit-code". No real gain to be had here either way. So, to summarize. We have the issue of documentation to solve, the issue of server-side security, client-side security, and maintainability. Before we go down the path of implementing yet another interpreter, we should take stock of what the current one actually does well, and figure out what the new one would do better, without sacrificing what we've already done well. Also, the specific solution we're looking for is an embedded sandboxed interpreted language. Anything heavier than Python (Java, C#) is a fucking "No", anything that requires multistage compilation is a "No"; classes are not a requirement, etc.
  19. The short answer is: no, we cannot. The long answer is as follows: All of the languages you listed are impossible to sandbox safely. And they need to be sandboxed, because they'll be running potentially malicious code. The only language that I've found where sandboxing to the required extent looks reasonable is Lua.
  20. No map switching. Map rotation and rp are bad juju. So once we go ship, we're staying ship.
  21. Kyres (deputy leaderman of loremen) is actually one of the larger drivers for this enterprise.
  22. The illusion of threat works both ways. If the detective is given an effective weapon, he is more encouraged to use it. This is why this debate just does not fucking die, by the way. So by giving him a more useless weapon, we are forcing him to not get entangled in stupid situations more.
  23. If we use "Stick up arse" as a measure of elitism, then I want to shoot for "Just the tip up arse". Going any higher would get us towards a silly strict RP environment that probably isn't beneficial for RP. How exactly lore will achieve this is up to lads like @kyres1, tho.
  24. In an ideal world, this is how it'll work. But the world is not ideal. Expect the minimum viable product to be just a moving space station. A better result will yeah be antags or other actors from the away sites, like the kosmostrelski. But one does not replace the other.
  25. Loreman told me that there'll be an automated support fleet attached to the vessel. To include a cryosleep ship. So the people will live there. The ship will probably at some point have to dock regardless, yes. Maybe, who knows! This is planned as an enterprise undertaken by multiple large megacorporations. So explaining why some species or culture is around is easy enough, still.
×
×
  • Create New...