-
Posts
259 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Everything posted by Doc
-
I have trouble understanding what exactly it is about the mesons that help you cope with this. Could you elaborate some more? To clarify, mesons weren't removed because they don't comply with vision cones- I don't think that was an aspect that was even considered, honestly. They were removed because engineers and to a lesser extent other roles were using them to look for changes in the station's structure- walls being deconstructed, girder bridges being built, windows being broken- in order to spot antags, or to hunt down and cheese through derelicts and dungeons to gain all of the loot with none of the risk. It's very difficult to change mesons in any way that keeps them 'useful' while not allowing that kind of abuse to happen, as seeing those changes is literally exactly what mesons are intended to do, just not for validhunting or powergaming purposes.
-
I'm under the impression that this is a hard no, according to past rulings; portable ammo is a ballistics feature. Not an energy weapon feature. Energy weapons are balanced around having a limited ammo pool that you are required to fall back and replenish at a stationary charger, generally back in security.
-
Can confirm that the default hotkeys for facedir and lockdir aren't particularly ergonomic, especially in high tension situations like combat. Rebinding them somewhere easily used would be wonderful. Additionally, having played with footstep indicators, they work great and fix a good amount of issues with the lack of reasonable information in your blocked field of vision. However, I've noticed that the theoretical typing indicator that you're supposed to see even when it's behind you hasn't been working. Is that going to be fixed soon? Walking away from people talking to you because you can't see it remains one of the major problems stopping me from just saying "merge this now".
-
Having just completed a crossfire round as security during a test-merge, which ended in a rough draw, I'm frankly really enjoying having to deal with the vision cones. The fact that they inhibit your situational awareness is-.. kind of the point. They create a unique, heightened tension atmosphere that isn't quite the same as when you can always know you can see behind you, making you consider- and be nervous of- flanking and blindsiding maneuvers. That's a good thing in my opinion- I find it fun to have to consider your situation more cautiously and tactically to achieve the same sense of security as you would with magic 360 degree vision. I don't have much of a problem with the lack of the so-called 'sixth sense' that should theoretically allow you to know someone is behind you; I wouldn't be opposed to some kind of ghostly image in the three tiles directly behind you if someone's there, but I don't consider that a necessary change to make the mechanic as a whole worth implementing permanently. Footstep and item use indicator cues, however, I definitely do think are necessary before full implementation- though I'm of the personal opinion that they should only be appearing out to 4-5 tiles, not your entire blocked cone. I didn't find combat particularly problematic during the crossfire-visioncones round. I was even flanked at one point, leaving me injured- but that's not a flaw with the mechanic, that's one of it's intended features, imo, and frankly I was kind of giddy when it happened just from the realization that that's something that can happen now. Again- it's cool, even when I 'lose' because of it! Tactical awareness is a thing, and to be honest I don't even think that vision cones will change traditional antagonist stealth that much- but the affects on typical combat, as just mentioned? I think that's one of the best parts. To those who do have trouble, I do throw out the PSA that if you use hotkeys, as any sane individual should, ctrl+arrow-keys makes you face in a direction without moving that way, and alt+arrow-keys toggles a lock in facing that direction so that you can strafe. These are functions that I've used for years for convenience, but I understand now may be nearly mandatory for effective management of your vision cone- but the fact that some people might not know of them or know how to use them to their fullest extent is not, imo, a reason to knock this PR. I don't feel that Aurora's current mechanical setup is in any way 'not fit' for vision cones; in fact, I went into the round with that prior feedback in mind, and I didn't really have any experiences that even helped me understand the opposing argument. I'm not really sure what it means, and I would encourage anyone who has only said "it doesnt work with our server/mechanics/SS13" to return to the thread and elaborate, if only to help me understand what they mean, as DrPockets did (to which my above explanation of enjoying how it adds to gameplay imo is my reply).
-
Of the three jumpsuits, I prefer the green or white. As for the storage options, I unfortunately have to say that I don't think they mesh too well with existing bags and satchels, though it's a good effort. There is, however, an existing-and-unused sprite currently buried in our codebase that, with a brief color adjustment (that neon yellow to white, the forest-green to med's pale-green) could be reused very readily.
-
To note, to those unaware: Originally, some short time in the realm of a month or two after contractors were originally implemented, Necropolis' security contractor lore was on the wiki under the late "Contractors" page, along with all of the other lore specific to contractors from our megacorps. This was lore. Canon. IC. It linked to all of the corporation's pages and in most cases vice versa. This page was removed from the wiki and replaced with the on-server blurbs, and this information was purposefully not relocated anywhere else on the wiki because having it on the character creation blurbs was considered 'sufficient' documentation of said information. As can potentially be interpreted through my tone, I disagreed and still disagree with this assessment, and this is exactly why I was so against it, because it is now essentially being erased as non-existent (Wezzy) or dismissed as insufficient (Alberyk), despite the information originally being intended to be canon lore explaining the existence of and reasoning behind these contractors. TLDR; necropolis has been intended to have security services for as long as we've had contractors (as well as anything else in the on-server blurbs) but the information was purposefully removed from the wiki for raisins, and should not be ignored despite this (whether necropolis should keep security contractors ANYWAY is still up for debate, but this should not be considered in any way one of the reasons for removing them)
-
Geeves Improves Necropolis by 900% (Not Clickbait) (Gone Wrong)
Doc replied to geeves's topic in Off Topic Discussion
This is in the wrong forum; it should be in the legitimate suggestions forum. Unironic +1 -
I don't think it looks especially better in-game, personally. The original drone is objectively not designed in the same way because.. it's, not an old sprite reused for a purpose it wasn't designed for? I'm not sure what you're trying to argue there. Anyway, the coloration in the drone does exactly what I suggested- highlighting and varied color design besides just a full, plain coat of orange (or X color, but, per the example picture). Is it shaded? Sure, but it shaded in a very smooth manner- this isn't inherently bad, but it contributes to the feeling of a flat, uninteresting design- you can look two or three spaces above the Icarus drone to see more interesting shading that contributes to a more visually appealing sprite- or, the top of the drone. This makes it more interesting to look at and better designed compared to the Icarus drone, imo- despite it's sprite size, which should make it harder to do such thanks to simply less room for detail. I'll specify again that this is specifically with the repo Icarus sprite- I think you've successfully applied the tenants you're talking about to your other sprites, but.. just, not the Icarus one.
-
I honestly dislike the 'repo Icarus' sprite. The coloration looks weird and ill-fitting; it really does look like it was just a completely different sprite which was color-shifted to be forced into the same theme as the rest. I would recommend taking the original Icarus sprite and instead of completely recoloring it, giving it stripes of coloration on its wings and chassis. It's also a little weird that its gun barrels were just turned into lights, imo. It definitely should not replace the original drone sprite entirely.
-
Where'd the original drone sprite go? Bring it back in addition to the new ones, please.
-
[+2 DISMISSAL;Bin 16.02] Sidearms for all (of command)
Doc replied to Cnaym's topic in Discontinued Projects
Basically, echoing all of this. The HoP gets it for the same reason the Captain gets it; they have direct and full access to all of the most sensitive aspects of the station at a complete whim. They are given this equipment to protect those interests in a last ditch scenario. They are, presumably, given only the most basic training required to defend themselves with it and utilize it safely- because that may be the absolute last line of defense of the entire station (mostly in the interests of preventing frontlining- which we already have issues with from captains, and, at points in the past, 'hopcurity'- and thus this is already an imperfect situation with weapons given only to those two roles). These reasons are not applicable to any other command staff, and so they have no reason to have these weapons. -1. -
There is currently a brainmed rebalance PR that will improve the liver's resilience and in general drastically lower the lethality of toxin damage. As stated above, the problem is not inherent with the event itself, but brainmed's failure to account for it and its current general inbalance. Brainmed is being and will be balanced and adjusted for these kinds of things. -1, since I didn't say it earlier.
-
It's not relevant if the individual is willing to overhaul all of our other sprites or, more generally, if we have the current spriting capability to match them. We don't need the entire staircase built before we start taking steps in the right directions. That's not how long-term collaborative projects like this work. Breaking drastically with our current design is only automatically a problem when doing so has no tangible benefit; i.e. the sprites are worse or, at best, roughly the same quality with a drastically different design (a 'side-grade'); but this is not the case with these sprites. There is a tangible benefit because the sprites are really friggen good. This neglects to acknowledge that "maintaining cohesion" with inferior quality by refusing to accept improvement is... stagnation. This really just seems like you have a drastic misunderstanding of how open-source projects evolve over time. You've literally described exactly how this process works. People contribute higher quality replacements of lower quality aspects and, with time, the quality and/or content of the project grows.
-
Wonderful spritework. +1. I don't really see concerns about the sprite 'fitting' as relevant; the sprite is good. It's an improvement. It should be accepted. Our spritebase evolves over time with individual contributions from individual contributors; that's how open-source projects as a whole work, and it's absolutely how our and many other SS13 server codebases work. We should be encouraging that evolution to trend towards the positive, and this is undeniably a step in that direction. The idea that it doesn't 'fit' with the other sprites only means that we should be looking to bring those other sprites up to par with this level of quality; that's never going to happen overnight, or even in the near future, but accepting higher quality sprites is how we progress toward that level of quality. I don't understand the desire to stagnate by refusing to improve without magically transforming the entire spritebase at once.
-
EOUGH
-
Dragging, particularly while sprinting, is an exceedingly fast way of moving someone out of harm's way at risk of causing severe damage to them in the process; compared to grabbing, where you are considerably slowed by the process but can move them completely safely. It's a trade-off for speed over health. This would completely remove that option. I absolutely do not support this unless both methods of moving people remain implemented, and readily accessible within a few button presses, somehow.
-
Same. The old ones are much preferable. These sprites received 90% negative feedback in their thread.
-
This seems to be a knee-jerk reaction to someone dying at some point due to a scrubber blast, which alone inclines me to disagree with the suggestion, because "I don't want things to happen to me" is not a particular valid reason to remove aspects of the game; that said, this also seems to largely be an unintended result of brainmed changes. I would highly prefer that no reagents be removed and that instead, our currently more lethal poisons and acids be adjusted to apply lower amounts of reagents, to avoid the near-gauranteed-death they present. Before brainmed, all but the most lethal reagents really only ever resulted in a five minute trip to medical for some dylovene. The intent behind this mechanic is the same of many other random events currently; to encourage players from different areas to interact with other players in different areas they might not usually do so; fifteen toxin damage results in you talking to a paramedic or doctor for a few minutes when you never would have interacted with them; a broken camera in mining results in an engineer talking to cargo personnel they never would have met on their own; a cave dweller in the science sublevel does the same for security and some xenoarcheologists. Sometimes, these interactions are barebones and uninteresting; but when they are, they're incredibly brief. The scrubbers event should be adjusted to meet that same standard, not just completely gimped.
-
[Rescinded] Bear's Moderator Application
Doc replied to Bear's topic in Moderator Applications Archives
It has been a standing rule that a member of the modmin team cannot be a member of the CCIA team and vice versa; the only "exception" being the admin position of CCIA liaison. Ignoring that, I'm not particularly sure what to make of this application. The reasoning boils down to "because I want to", with little further elaboration, and your responsibility responses are rather short. which combined, make it hard to meaningfully gauge your commitment as anything other than low. Your membership of the CCIA team is a plus, but the workloads and expectations of the two teams are wildly different, and I can, from personal experience, tell you that adjusting to the difference will be a good amount of effort. You will have higher expectations of on-server time, on a more consistent basis, while potentially actually playing less to handle your administrative responsibilities. I'm not familiar with your current frequency of playing the server; but the fact that you, in this application, seem so nonchalant about """upgrading""" your responsibilities concerns me in terms of you actually being ready to commit to them. -
Red is exactly what we should stay away from; it's unnecessary attachment to their former Syndicate roots that we should be purposefully avoiding. "We're here to commit terrorism because you're a NanoTrasen station and NanoTrasen is bad" offers very little opportunity for engaging RP; having independent mercs that can develop their own motivations and their own goals is a much more worthy goal, and for that reason their 'standard' uniform should be very generalist. I think these sprites fulfill that purpose nicely. Edit: I only just realized- don't they start with tactical turtlenecks already? Why do we not stick with those? I personally prefer those over these jumpsuits. I had my mind stuck on their blood-red voidsuits and moving away from the Syndicate themes. If anything these can be added to their armory as an alternative uniform, in addition to the turtlenecks.
-
Is this some kind of bizarre attempt at trolling? Has this entire conversation been an elaborate ruse to waste as many people's time as possible while accomplishing no actual meaningful discussion? Guess what this suggestion thread is for. Getting them to do that.
-
The purpose of this suggestion is to revert this nonsensical ruling by the lore team- you can't then use the existence of the ruling as reasoning against the suggestion. As has been explained by multiple people in multiple ways, it is not logical for NT to have only just begun employing offworlders in the last year, and were it not for this ruling, there would be no actual reason offworlders could not fulfill these roles (besides the caveat of the security team). Lived in, no. Genetically 'adapted'/degenerated over multiple generations, yes. To call them a sub-species is indeed correct. No, it's not. Some offworlders have adapted over dozens of generations with significant genetic impact; some have only been mildly affected in their individual youth to have lighter/weaker bone structure, lankier builds, and weaker circulatory systems, with completely standard human genetics. Calling them a distinct sub-species implies a consistency between all of them that doesn't exist. The lore term of 'offworlder' encompasses the entire spectrum of individuals who have been permanently influenced by non-standard gravity environments; this is why there was rather protracted debate over even naming them offworlders as opposed to 'spacers' or other suggestions. The mechanical race encompasses the more heavily physically affected end of spectrum of offworlders, but it's entirely possible for a person closer to what our mechanical standard humans represents (i.e., less physically inhibited) to be considered an offworlder in lore by the way their environment affected their development or by their lineage. Yes, they were overly tall, suffered from poor bone structure causing aching in standard gravity environments, were significantly clumsy and pained by unsupported heavy equipment such as voidsuits, and often tried to avail their pain through alcohol when given the chance by lax command staff or other circumstances. There was no retconning; they were always, originally, intended to have been heavily affected from birth by a lack of full or stable gravity, and I even stopped playing them months before mechanical offworlders were originally being designed, much less implemented. If I had made them now, I likely wouldn't have changed very much about them; they do not suffer from the worst of an offworlder's possible physical problems, but enough to desperately want a stable supply of RMT to suppress their daily pain. Of course, if I decided to play them now, lore would have decided for me that they haven't actually been working at NT for the past four years I've been playing them, despite the fact that they have because I did. That's dumb. That's why this suggestion exists.
-
The entire point of the conversation is that offworlders should and really have been employed by NanoTrasen for longer than that year. That's... why this doesn't make sense. I personally had an offworlder character for about three years before mechanical offworlders were implemented that would be a CE now if she returned, but now lore is turning around and saying she's only existed for a year because... well I don't know, it really makes no sense, that's the point.
-
Please give it an accurate name or at least some kind of more detailed description in your announcements next time. I purposefully avoided the first half of the arc believing it was some kind of Skrell avant garde theatre series being put on aboard the Aurora, because all it was described as as "a skrell musical". That was, clearly, very much not what it was.