
jackfractal
Members-
Posts
598 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Everything posted by jackfractal
-
Hi Scopes! Me again! I've just opened four new pull requests today, and there hasn't really been any movement since I opened this thread. I'm worried that a 35 day delay for feedback on pull requests, while understandable given your workload, could make it uninviting for third party contributors to help with Aurora. I was wondering, is there was some way we could help you or make things easier on you?
-
Give Emagged Cyborgs Access to the Syndicate Radio Channel
jackfractal replied to jackfractal's topic in Archive
Pull request up. -
It's not bullshit, it's a neat idea, though I'm not sure what kind of tools such a cyborg might require. Remote access to newsfeeds maybe? That might be fun.
-
It's actually a realism thing. Heat dissipation is the key problem in vacuum, not cold. It could be absolute zero out there, but if there's no matter to steal the heat, it's a lot like being in a greenhouse. The heat you generate has no way to escape save through radiation, which is an inefficient way to transmit heat at relatively low temperatures. IPC's hover at around 80C even in atmosphere, get enough of them in a small space and you can register the changes on an atmos scanner. They require the artificial coolers to take care of the heat they build up in vacuum.
-
Magnetic Manipulator for Engineering Cyborgs
jackfractal replied to jackfractal's topic in Completed Projects
Pull request up. -
Allow Cyborgs to Use Medical Machinery
jackfractal replied to jackfractal's topic in Completed Projects
Pull request up. -
I_speak_money's IPC Application
jackfractal replied to I_speak_money's topic in Whitelist Applications Archives
Hi I_speak_money! I saw a few of your rounds as Pomeroy and Talbot, I thought that was an interesting idea. This form is filled out fine, so unless someone brings up a major issue in the next few hours, I'll mark this as accepted. Have a great day! -
I'm still within the belief that captain+ head of security must still be immune from antagonist roles, implant or no. That's interesting. Can you unpack that?
-
I am doing some design work on cyborgs this week. It's mostly gameplay and code, but it should fit with the lore a little better when I'm finished.
-
Hmm.... upon further reflection, I realize that I've gone about this entirely the wrong way. I'll leave this thread here but I'm not going to argue any more. I have a better idea. I'll see about writing it up tomorrow.
-
Hey! This is one of those screwball idiosyncrasies of SS13. All jumpsuit items (like kilts) take up the jumpsuit slot and you have to click on them and drag them into your hand to remove them. This will make everything attached to your jumpsuit fall off as well. I have no idea why it works like that, but that's how it works...
-
Hi Gurodel! Welcome to Aurora. If you have any questions, don't hesitate to ask.
-
OK, I admit I laughed at this.
-
I think we should maybe talk real-time about this, because again, I feel like I'm not communicating clearly. I like your design idea for the Standard module, but you haven't provided a design goal for cyborg modules as a whole that can properly encompass what you're describing in a way that remains coherent with the designs for other modules. And... all of the other modules can already do all of the things your describing as primary tasks for the Standard module. Often better. What you're describing is something that has no functionality beyond that of a cyborg without a module. The only thing that it would have would be a lack of formal responsibilities, and if you don't want formal responsibilities, why not play Service? I think most of the things that people play Standard for, especially the role-playing opportunities, are better served by the Service module. That's why I want to expand the Service module so it can be a bit more functional. What if we smooshed the two together? We could merge Service and Standard into... "Helper" or something?
-
@Critsy It's not a matter of 'what does it do' it's a matter of 'what is it's job'. They're not the same thing. Thank you for your analysis, but I'm not sure I can find a way to make it useful given the design goals I outlined in my other posts. I mean, 'provide a more rp-centric role' isn't a job like "fix atmospheric breaches", "clean the station" or "detain lawbreakers" are. Neither is 'work easily in any department'. I think I may be failing to communicate here. The 'job' in my design goals refers to a specific task within the station. It does not refer to another design goal, which is what 'provide a more rp-centric role' would be. The job has to be specific, in order to work. Trying to slot 'versatility' into the 'job' part of my design goals, doesn't work, when what you're trying to balance against is a reduction of versatility. That's axiomatic. That's why I asked for someone to describe an alternative set of design goals for cyborgs without a specific task, because the design goals that I'm working off of make such a goal invalid. It literally does not compute. If you're saying that the point of the Standard cyborg is to '[serve] any purpose it is assigned to', I have to remind you that all cyborgs, regardless of starting module, can work in any department. They simply need to go to robotics and get their module swapped to that of their assigned task. If they later need to work in another department, they can get their module switched to that new department as well. Module reset boards are cheap, fast to build, available from round-start, and take about ten seconds to install. As that is the case, and your primary argument seems to be 'they are designed to work anywhere', then I propose that any cyborg can already do everything that you're saying that the Standard module is designed to do, with the added bonus of actually being good at the job they've been asked to do, once they've switched to the right module. So, the design space that you're saying the Standard module is supposed to exist in, is entirely overlapped by that of the existing capabilities of all cyborgs. That seems to me to be a further argument for their removal. @Alberyk. You are right. The energy sword is extremely badass. @Scopes: It is not something I am trying to impose. It is a formalization of how the design goals for cyborgs have been described to me in the past, including on this very server. Why can't cyborgs have hands? That would make them too versatile. They're already really strong 'cause they can go in space, have all access, and don't need to breathe. Gotta balance that. Why do engineering cyborgs have RCD's and why do security cyborgs have recharging tasers? Because they don't have hands! They need to be good at their job because they lack the ability to do anything else. I have had a lot of discussions about cyborg design over the years and there are very clear arguments for things that I have encountered repeatedly. My design statement 'Cyborgs trade versatility and freedom of action for the ability to do one job very well.' is a distillation of dozens of conversations about how cyborgs should be designed. If you disagree with that statement, and you have a different but clear set of guidelines for doing module design, please tell me, and I'll use those instead.
-
Why remove it? Because the reasons I've outlined. It's very bad at almost everything. It is an awful place for a new player to start, as they are unable to do nearly all tasks and it doesn't 'work fine', as it's design cannot be assessed because it doesn't even fit within the design framework for other cyborg modules. The only point I'll give you is that people may like to play it, but like I said, I think the amount it's played is very rare. We have no hard data on this, just anecdotes. I'd like to put a module selection logger into the code so that in future discussions like this, we can talk about what is really going on in terms of play population. The real issue with the Standard module is that it doesn't fit the design pattern for other cyborg modules. This makes it very hard to assess whether it's 'working' or not. The design goal for cyborg modules appears to be 'cyborgs trade versatility and freedom of action for the ability to do one job very well'. If we use that design goal as a lens through which we look at the existing modules, we can assess whether a module is working correctly. Lets try this out. Can the janitor module be considered 'good' under this pattern? Yes, it can. We can look at it and say 'It is very good at cleaning, but lacks the ability to do anything else'. If it had, for example, a laser gun, we could say 'Hmm. This laser gun doesn't help with cleaning, which is it's assigned task, therefore, the laser gun should be removed.' We can also look at, say, the medical modules. Are they 'good' when looked at through this lens? After looking at them, we can determine that, no, they are not. They lack the ability to do the job they're supposed to do, due to their inability to use medical machinery, and their weirdly distributed tools (no ability to handle toxin damage). So, you can see, by comparing a module's current abilities to our design goals, we can determine if a specific module is doing what it's supposed to do, and whether it requires modification. What happens if we try to assess the Standard module? Well we fail on first principles. "What is the Standard cyborg's job?" It doesn't have one. It sorta goes around helping people, but not very well because it's not actually very good at anything. That means we can't assess it. We can't determine if it should or should not have a laser gun because we don't know what the perimeters of it's task is. We can't even begin to assess this module because it doesn't fit within our design goals. Its like trying to assess a fork, when you're trying to design a pair of scissors. When this happens, it means one of two things, either the thing you're trying to assess is inapplicable in some fundamental way, or your design goals are not setup properly. I think our design goals, as I outlined them, are fine, but I'm willing to admit that I might be wrong. Does anyone have a set of design goals for cyborg modules that lets us assess cyborg modules without a specific task, in a way that is also useful for cyborg modules with specific tasks?
-
Allow Cyborgs to Use Medical Machinery
jackfractal replied to jackfractal's topic in Completed Projects
That's not a really good argument Vanagandr. No other role on the station requires another player to do most of their job for them. That's what having an assistant follow you around and use the machine's for you would be. Most of the job of a doctor in Aurora medical code requires these machines. That would be like if anyone who picked 'Engineer' as a role weren't allowed to use any tools and they had to get a 'tool assistant' to follow them around and follow their instructions whenever tools were needed. It wouldn't be fun. -
While the Standard module does technically function, in that it doesn't prevent compilation and it doesn't throw run-time errors it is still broken. It's code is fine, it's the design which is where the problem is, both in it's own right (it is very bad at doing things) but also in how it relates to the broader topic of cyborg design as a whole. The axiom I have been told for cyborg design, and the one that appears to be partially born out by the other modules, is that cyborgs are designed for a particular purpose, and from a game-play perspective, the player of a cyborg trades the autonomy and versatility that they would get as a regular crew-member for mastery of a particular task. "Assisting" is not a specific task, it requires versatility, which is the thing that cyborgs are not supposed to have. Assuming that the axiom that I mentioned above is true, there should be no 'general purpose' cyborgs, because cyborgs are supposed to be built for a particular task. Assume the situation were reversed. If the Standard module didn't exist, what would be the argument for including it?
-
Give Emagged Cyborgs Access to the Syndicate Radio Channel
jackfractal replied to jackfractal's topic in Archive
Yeah, that's doable. I've been meaning to update the borg radio stuff for a while (give them the option to broadcast or not). I like the broadcasting thing by default, but it should be possible to disable it (and the syndicate channel should be disabled by default). -
I suspect that, were we to log module selection results, the standard cyborg would be... less then half a percent? Less then a tenth of a percent? People play two modules: Engineering and Security. You sometimes (very rarely) see Janitorial, Mining, or one of the two Medical models. That's it. Either the Standard Cyborg should be given a task that they are actually good at, or they should be removed. I tried to come up with a task that could be considered 'Standard', but any task I came up with that wasn't covered by the other modules would have required a name change. Even if that weren't the case, it is a newbie trap and I think we should prioritize assisting newbies over supporting a rare play-style.
-
Allow Cyborgs to Use Medical Machinery
jackfractal replied to jackfractal's topic in Completed Projects
Precisely. That's the point. Even if you combined the trauma and surgical cyborgs, without the ability to use these machines they're still not going to be able to do their job properly. If you're a cyborg and you're playing medical, you should be able to do the job at least as well as a regular crew member, as you are prevented mechanically from doing anything else. That's always been the balancing factor for cyborgs. You trade versatility and freedom of action for the ability to do one job very well. Right now our medical cyborgs are unable to do their jobs properly as most of medical's job requires the use of these machines. -
I keep coming up with more of these... When emagged, cyborgs during Nuke Ops rounds should have access to the syndicate radio channel. If the emag is magical enough to spontaneously generate military grade laser weapons or poison, it should be able to create an encryption key. Getting subverted happens so rarely, that when it does happen, the cyborg should at least be useful.
-
It does nothing very well. When I see it played, it's almost always by new players who have never played cyborg before and they end up confused as to why it can't actually do anything. For those wondering what tools the standard cyborg ends up with, here's the list: - flashlight - flash - stun baton - fire extinguisher - wrench - crowbar - health analyzer It's a newbie trap more than anything and it serves no purpose. It also goes against the design ethos for cyborgs, which is to trade the versatility of a crew-member, for efficiency at a specific task. Without a specific task, the 'standard' cyborg does nothing.
-
The Service Cyborg is hardly ever used because it has almost no ability to actually do anything. I recommend that we give it the ability to properly fill the chef and bartender rolls. It needs a gripper that can manipulate food items, a knife, and some larger mixing glasses for alcohol. I also think it might be cool if the service cyborg could help out in Botany, as botany is usually pretty quiet, and we have no cyborg module that helps out in there. Botany isn't a particularly complex department, and giving cyborg versions of their various tools wouldn't be that difficult.
-
Right now, cyborgs are unable to drag people into medical machinery. This means that they cannot use sleepers, scanners, cloners, dna-manipulators, cryo tubes, cryogenic freezers, or surgical tables. This makes them flipping useless in medbay. My suggestion would be to make this work as it does on Paradise and TG, where a borg can click-drag a crew-member onto one of the devices, there is a delay where a message is displayed saying 'ROBOCOP is trying to place Urist McCrewmember in the Sleeper' during which time they can be interrupted by moving either player. This is easy to do, and would make medical cyborgs substantially more viable.