Jump to content

Contextual

Members
  • Posts

    211
  • Joined

  • Last visited

Linked Accounts

  • Byond CKey
    contextual

Recent Profile Visitors

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

Contextual's Achievements

Chief Engineer

Chief Engineer (23/37)

  1. These, specifically, are all really good points for adjustment. All of them can be tweaked, removed, or reworked in order to make stationbound more consistent with existing lore and mechanics for other races, as well as bringing their "power level" in line with the rest of the crew, without losing their inherent character. Make stationbound more susceptible to stuns, be they screeches or flashbangs or the like, or even stun baton strikes. Perhaps even give them some kind of fluffy electrical shock threshold, where they can dampen so many disruptor shots before being overwhelmed and suffering a temporary shutdown/stun to prevent systems damage? Vacuum is a big one. They shouldn't be super-immune to it, as this runs directly counter to IPC lore/mechanics. Perhaps have the EVA modules have some built-in cooler item with limited charge that they have to work around, with the others suffering gradual heat buildup/damage a la IPCs? Movement speed is ever-tweakable with every individual module, and I have suggested that several of the modules have varying degrees of it. Especially ones which present combat utility in the form of surgical saws, etc. The flashlight can be removed outright and locked behind the floodlight upgrade, if this is a particular pain point of balance. It would give much more impact to the upgrade, too, making it feel much better in the machinist-stationbound interaction loop. The computer was added out of nowhere, and really only serves to give stationbound the ability to use the chat client when AI IM was deprecated. If this functionality can be re-added to their baked-in mechanics, the computer can be removed entirely at no great loss. System interfacing can be policed on a system-by-system basis. See ATMs for an example. Not in round, no. Not without a substantial rework along the lines of what Chada has proposed; however, this toolkit, which in certain cases is far too strong and all-encompassing, can be adjusted with balance passes, as I have detailed in my previous posts in this thread. In fact, it's really important for the health of the role that these passes take place, even if the access changes are permanent.
  2. As best as I can tell, the all access of stationbounds has now been removed entirely. The only way for stationbound to get this access back, the role and function which makes dead/lowpop mechanically functional for those players who choose to participate in it, is for a Research Director to be present and willing to grant them the ability. An incredibly uncommon member of command, on an already low-population round. I don't think I can really express my disappointment with this change in mere words. The actual problems of the role have not been addressed in any way, all of which are rooted in the abilities of specific modules. The actual "flavor", the point of stationbound being stationbound has been lost, in favor of... restricting movement? Of restricting access? Of making stationbound effectively the same as crew, but worse? And then, another merge has already been proposed for an entire module to be summarily removed instead of the (admittedly more involved) solution of restricting module availability based on available slots. I don't think I can wrap my head around the mentality that has gone into these implemented and upcoming changes. It seems to me to be intentionally, maliciously obtuse, spurred on by blind bias and intentionally oblivious to more reasonable, agreeable suggestions. There is so much room for improvement to stationbound, so many things which can be adjusted, and should have been long ago. Instead, in the face of the removal vote not going through, the intention seems to be to "rework" the class in the same way that an autocrat "reworks" political opposition, rendering it utterly toothless and obsolete.
  3. My lawyers have advised me to explicitly lay out my proposed changes in this thread. In short, the changes I propose consist of three distinct and separate methods, which taken individually or as a whole will improve the quality of stationbound play and players. Change 1: Modules Change 2: Module Slot Restrictions This one can be implemented in a few ways, but the intention is to prevent more than one stationbound from taking a single module at any given time. This could be expanded to have a stationbound module consume one of the corresponding crew slots, if applicable. I.e., a surgical module requires and occupies an empty surgeon slot, a machinist module requires and occupies an empty machinist slot, both construction and maintenance modules requiring and occupying an empty engineer slot. This would prevent a situation where all of the patient work has to be split between two FRs and a rescue module. This, if implemented, would neatly help solve the allocation and overlap concern with crew--now a stationbound isn't competing with you and your coworker, as far as the roster is concerned, it is your coworker. Change 3: Create a Stationbound Whitelist This one may be a bit unpopular, but the simple fact is that stationbound play is currently as unrestricted as playing a generic human. Players are able to play stationbound any way they so please, and frequently do not do so in a manner that is conducive to good interaction or representation of the stationbound as a "species", shattering immersion and generally making fools of themselves. Creating a distinct stationbound whitelist would allow for the synthetic lore team to exert more lore and quality control over the role as a whole. This would, additionally, potentially lead to more relaxed law-sets in the future as the whitelisted playerbase would be both more trustworthy and easily policed for bad actors. --------------------------------------------------------------- Again, each of these changes can be implemented separately, or all together, and each would dramatically help to address the existing issues with stationbound as they are currently implemented.
  4. While I'm aware it's not the topic of this particular thread, I feel the need to express my utter befuddlement at the notion of stationbound characters being rule- or law-restricted from having personalities. As well as the general opinion that such characters fundamentally cannot be "characters", cannot have backgrounds, traits, aspirations, etc... It seems, to me, a very limited and warped perspective from players who are fundamentally unfamiliar with actually playing or interacting with (well-depicted) stationbounds. That out of the way, I also do not agree with the proposed changes in this thread. Stationbounds, and their servile all-access nature, are incredibly valuable to the flow and quality of life in low-pop or unevenly-staffed rounds. Taking away or restricting their access, even just locking it behind a code elevation, would render them functionally indistinct from organic crew; they're meant to be, at some level, an extension of the ship itself. The core problems which seem to be generating frustration with players in regards to stationbound appear to be threefold. 1) Certain modules are far too all-encompassing, capable of replacing entire departments in their scope and capability. This is something which must be addressed mechanically, and is incredibly simple to do so in a way that creates more options for character expression and variance. 2) Certain stationbound players have, apparently, been either permitted through inaction or expected through convention to power-game departments. This is something which must be addressed on a case-by-case basis via in-round reporting and moderation. 3) Certain crewmember players appear unwilling or unable to confront and interact with stationbounds whose modules overlap with the job of their own character. This one is just baffling, as in nearly all cases the roles in question are inherently multi-slot, and such characters are expected to have the exact same discussions with other crew members of the same profession. Notwithstanding the effete nature of the latter two issues, there is room for improvement in the implementation of stationbound as they currently stand. Module-wise, restricting access to any one of the modules is a deeply flawed approach to a very legitimate problem. Historically, stationbound modules have seen continuous buffs, both power-creeping organic crew and also module-creeping other stationbound. --This is exemplified in the Medical module, which possesses every tool and chemical the medbay could ever realistically need, while also possessing the tools and means to go and retrieve (or even treat) crew members out and about the ship, almost completely negating the purpose of the far weaker Rescue module in all ways but sheer (default) mobility. --Similarly, the Engineering module can not only do every single task Engineering could possibly be called upon to do, it does so while also containing practically the exact same power tools present in the Construction module. The only true "advantage" the Construction module maintains in its specialty is the mining drill, which is functionally useless with the server's transition to an astronautical vessel. --Lastly, the Research module is remarkably overpowered in the hands of any competent antagonist player. Even when played normally, though, it's capable of far too many functions, from the engine to surgery to repairing and upgrading other machines. It's even capable of being selected, setting the engine, upgrading itself with all available materials, and then resetting itself into a different module of its choice! No single thing that any of these modules can do is the problem. The problem comes from the confluence of all of these capabilities replacing entire departments. Simply locking these modules, or the capabilities they possess, behind a "progression" or "permission" system would ultimately restrict the variety of player choice and expression to an unacceptable degree. Instead of being able to play a specialized surgical robot, or a smart-cracking hull-patching maintenance crawler, or even a hyper-specialized automated engine-setup apparatus, all stationbound characters would have to be multirole generalists. All stationbound characters would have to be service/clerical/janitorial by default. All stationbound characters would be expected to be able to be changed into whatever specialty module is unlocked and expected. Instead, the existing modules should be broken down, split apart, and nerfed. The engineering module should not be able to match/outperform the construction module in its own niche. The research module should not be able to upgrade or repair itself, let alone do most of the work of four separate departments alone. The medical module should not be the medical module. I'd elaborate further with specific propositions on how to do this, but I feel it would be straying too far from the original suggestions being discussed in this thread, and this post is already getting long.
  5. I support this entirely, for reasons of both balance and realism
  6. TO: Mrrrrhazmanq Naldratajrmro, Assistant, NSS Aurora FROM: CCIAAMS, NTCC Odin SUBJECT: RE: Incident Report -------------------- BODY: This is an automated message to inform you that an investigation has now been opened regarding your incident report, and assigned to Nadine Branagan (Contextual). You may be contacted by the CCIAA for an interview, or you may contact them directly if you have any questions. -------------------- DTG: 04-09:25-TAU CETI STANDARD-11-2462 SIGN: CCIAAMS
  7. TO: Spirit, Chief Medical Officer, NSS Aurora FROM: CCIAAMS, NTCC Odin SUBJECT: RE: Incident Report -------------------- BODY: This is an automated message to inform you that an investigation has now been opened regarding your incident report, and assigned to Nadine Branagan (Contextual). You may be contacted by the CCIAA for an interview, or you may contact them directly if you have any questions. -------------------- DTG: 04-09:25-TAU CETI STANDARD-11-2462 SIGN: CCIAAMS
×
×
  • Create New...