Jump to content

Doc

Members
  • Content Count

    198
  • Joined

  • Last visited

7 Followers

About Doc

Linked Accounts

  • Byond CKey
    thedococt

Recent Profile Visitors

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

  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.
  2. 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.
  3. Where'd the original drone sprite go? Bring it back in addition to the new ones, please.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. Same. The old ones are much preferable. These sprites received 90% negative feedback in their thread.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
×
×
  • Create New...