-
Posts
2,129 -
Joined
-
Last visited
-
Days Won
48
Posts posted by Kyet
-
-
If someone asks me for something as HoP/Captain, my 5 possible answers are:
1) "Yes." - e.g: atmos tech alone in Eng wants engine access.
2) "No." - e.g: clown wants all-access.
3) If I ask person X over radio/PDA, and they agree, "Yes". Otherwise, "No". - E.g: a transfer request to Sec requires HoS authorization.
4) If I ask person X over radio/PDA, and they object, "No". Otherwise, "Yes". - E.g: if I'm suspicious of someone, I'll float every request they make over command radio just to be sure there is no reason it should be denied.
5) "Ask again in X minutes" - E.g: if I am busy at the time.
None of these options involve asking the person to get anything signed, stamped, or whatnot.
None of these options involve paperwork of any kind.
I prefer radio over forms. Reasons:
- Radio is faster, both for them, and for me.
- Radio is hard to forge, and easier to check.
If radio fails, I will use PDA. It has an attention-grabbing beep, and records the conversation automatically.
Overall, I avoid creating paperwork for other people.
If someone tries to get me to complete paperwork when I request something, my typical answer is "nevermind".
E.g: if I'm an Eng, and I want to put up cameras in maint, I might ask the QM for camera assemblies. If they say "please fill out this form", I reply "nevermind" and find something else to do with my shift.
E.g: if I want a job transfer, ask the HoP, and get "please complete this form", my typical response is "nevermind" and cryoing instead.
Actually, on second thought, the fact many HoPs ask for paperwork, rather than using the radio, is the reason I don't visit the HoP desk anymore.
About the only case where I will do paperwork is if I'm doing it to help someone else. E.g: I'm the Captain and IAA wants my comment on some investigation, or I'm RD and someone wants me to sign a permission form so they can get borged. I'll do that.
Although I won't usually do paperwork, I do have a large library of out-of-game text files I refer to every shift. They include pages-long checklists of roundstart actions for every job I play, copies of telecomms scripts, recipie lists for chem, etc. They also include a file for round-specific notes (e.g: writing down wires as eng, words as cult, all requests I get and decisions I make as HoP/Captain, etc).
These are freeform, and useful. They're "notes", not "paperwork".
Sometimes I will paste these notes onto paper, in-game, to help someone. E.g: AI wants to see my telecomms script, NT rep is doing a report and I can help by providing them my HoP/Captain request records, someone is mixing scichem and would benefit from a quick recipie guide, someone is doing R&D and would benefit from an item list, etc.
Still not paperwork, though.
I generally only use the word "paperwork" to refer to using paper in a way which doesn't help anyone, and/or actively wastes other peoples' time.
The classic example of paperwork is the QM above.
I ask for camera assemblies as an engineer. They have no nefarious use. I want to put up cameras in maint. That would help the station. The QM isn't short on resources. Nobody will ever care I have these assemblies.
QM still asks me to sign something or fill out a form. Nobody is ever going to read or care about this paper, even if I do complete it.
The QM is engaging in paperwork: an unnecessary time-wasting activity that comes off, to me, as deliberately obstructive.
I wonder if the QM is doing it deliberately because he enjoys wasting peoples' time.
Under this definition, some things that involve lots of paper (e.g: shift-start reports by NT reps, faxed to centcomm) aren't paperwork.
So long as they're useful, and don't waste time, they're not paperwork. No matter how much paper they use.
I reserve the word "paperwork" for activities which involve paper, achieve nothing useful, and aggressively waste your time.
I've found that the most paperwork of paperwork loving HoPs don't actually like the paperwork itself. They like the power that comes from forcing someone to go on a snipe hunt gathering signatures and filling out forms. It's a power trip, and it gets silly.The HoP who cared about paperwork integrity would, for example, NEVER hand a crewmember a transfer form and say "fill it out". We live in a world of counterfeit stamps and forgery, after all. No, a HoP who cared about such would fill out the form themselves, use a secure fax to the relevant department, verify with stamped return receipts.
Instead, it's "Here, waste time out of your round filling this form out I copypasta'ed in 10 seconds off the wiki, then go chase down another busy person and annoy them."
This.
-
IMHO, the "jobs" page should only list jobs that are actually, currently supported by our codebase.
Custom jobs, especially event jobs, don't belong on that page.
That said, we should have another page for event jobs/roles, and this should be listed there.
-
They're looking forward to meeting you.
-
News:
- Many updates have been made based on awaymission feedback and Ping's SS13 Video Team beta test. Changelog: http://nanotrasen.se/forum/viewtopic.ph ... 024#p63024
- Several of these are major updates, including the complete elimination of UO71 ID cards, adding much better lighting, fixing the power issues, etc.
- The pull request is up, at: https://github.com/ParadiseSS13/Paradise/pull/4229
-
Update 13: https://github.com/Kyep/Paradise/commit ... e19a0e7c89
- UO71: Added food vendors to the halls, and prepared food to the kitchen. No longer will explorers go hungry.
- UO71: Eliminated all the UO71 ID cards. You get basic door access by using a terminal in the second room. All other doors unlock automatically when you defeat certain spiders. No longer must you hunt around for, swap out, or otherwise fiddle with ID cards to do things.
- UO71: Deleted some filing cabinets that were causing pathing issues for spiders in Eng and Civil.
- UO71: Changed all SMES' starting charge (1.5e+006 to 5e+006) and output (7k to 25k). UO71 should no longer run out of power.
- UO71: Replaced queen chamber airlock with triple blast doors. This eliminates the chokepoint on the chamber and makes the fight much harder.
- UO71: Replaced the inner airlocks on the mother/prince chambers with rwindows. This ensures they will aggro as you walk by, IF you have opened their chambers.
- UO71: Added some more supplies to UO71 medbay.
- UO71: Added cyborg recharging station to UO71 science.
- UO71: Added purple (praetorian) spider to guard a loot item. Partly to prevent cheesing, partly to give awayteams more experience fighting them.
- UO71: Added robotic arms and legs to science divison. Only one of each, but should provide parts for replacement surgeries when awayteams are ripped limb from limb.
- Feature: Added "Toggle Debug" and "Toggle Instant" verbs for empresses. They toggle debug mode and instant growth, respectively, for all spiders. Debug tools.
- Cleanup: Made various cleanup changes aimed at preventing potential conflicts with Paradise master when I put up a PR for this.
- Balance: Changed white spider invasion event spawncount from 3 to 1. Big nerf.
- Mapping: Changed awaymissions to NOT constantly select UO71 anymore (another pre-PR change)
Update 14:
Merge pull from Paradise13/master, bringing the spiders codebase up-to-date with Paradise.
Necessary in order to identify and fix code conflicts between the two.
Update 15: https://github.com/ParadiseSS13/Paradis ... 0ef034b1c7
- UO71: Adjusted lighting throughout UO71 - should be MUCH more atmospheric now!
- Fixed bug where dead gray spiders would keep building webs.
- Fixed many bugs introduced in Update 14, where changed Paradise code caused many things to trigger compile errors:
-- Deleted all references to meat_type and meat_amount, verified spiders still don't have meat, even when butchered.
-- Deleted all references to min_oxy, max_oxy, ditto for tox, co2 and n2. Adjusted to new heat system based on atmos_requirements var.
-- Changed C.deactivate to C.toggle_cam. Verified those spiders can still break cams.
-- Updated "stance" code to "AIStatus" code. Verified queen still nests, etc.
-- Created local config/config_away_mission.txt. Allows SVT and I to change away mission config without code changes.
- Fixed issues pointed out by Tastyfish on Github
-- Absolute paths for New() in UO71 code
-- Deleted access cards
-- Changed [src.name] to [name]
-- Changed all use of: X << "..." to: to_chat(X,"...")
We now have a pull request, at: https://github.com/ParadiseSS13/Paradise/pull/4229
-
...I lost a part of my soul writing all of that. That took an hour and forty minutes. My sanity may of dropped while nitpicking all of that, so if you guys notice anything overly pretentious or annoying or just plain wrong that I said, I'm so sorry.
I agree with pretty much everything you said.
Like most semi-formal documents, SOP has a tendency to be longer than it needs to be, and/or vague in some cases.
Being clearer and more concise is a good thing.
I will never attempt to act like I'm TZO ever again. *screamI'm taking this as a compliment.
-
That's a legitimately good point. How's the following sound:
The Captain is to ensure that every Department is following Standard Operating Procedure, up to and including the respective Head of Staff. If a Head of Staff is not available for a Department, the Captain must ensure themselves that Standard Operating Procedure is followed, and must find and appoint an Acting Head for that Department, if there are available personnelI'd suggest something like this:
If a department lacks a head, the Captain should make reasonable efforts to appoint an acting one.
If there's a head, enforcing SOP in that department falls on them, not the Captain (though the Captain can demote them if they prove incapable).
If there's no head, the Captain should appoint one.
If there's no head and the Captain can't find anyone willing to take up the post... the department/station probably has serious problems beyond SOP enforcement. And/or the Captain should offer an incentive to anyone willing to take the job.
I don't think Captains should be enforcing department SOP themselves (what are their heads for?) - but they should be willing to demote heads who dangerously breach SOP and/or completely fail to enforce it.
The Captain may not fire any Head of Staff without reasonable justification (ie, incompetency, criminal activity, or otherwise any action that endangers/compromises the station and/or crew). The Captain may not fire any Central Command VIPs without permission from Central Command, unless they are blatantly acting against the well-being and safety of the crew and stationThat seems pretty reasonable. I would possibly add "(E.g: magistrate, blueshield, NT rep)" after "Central Command VIPs".
The Blueshield is most often around Command areas and is better armed (and trained). Heads of Personnel more often than not faff off to somewhere else but their office, not to mention that they are not nominally in charge of anything but Cargo and Command until there's no Captain.
I would agree HoS/BS are safer than HoP. HoS/BS are both loyalty implanted, supposed to be carrying weapons, and tend to be in secure areas. The HoP isn't loyalty implanted, isn't meant to be providing physical security (e.g: disk-guarding services), and is often in insecure areas. It would be safer kept on the HoS or BS, if Captain doesn't want to carry it.
Personally, when I play Captain, I keep the disk on me at all times, and give the pinpointer to the HoS/BS so they can always locate me/it.
The Head of Personnel may not leave their office unattended for longer than fifteen (15) minutes at a time. If there are personnel waiting in line, the Head of Personnel is to head to their office post haste;This is absolutely ridiculous, for three reasons:
1) It forces the HoP to keep returning to his office even when, 90% of the time, nobody will be there.
2) It discourages people from simply radioing or PDAing the HoP to ask him to attend to their request - despite the fact this would be faster. "Oh well he will turn up at his office eventually..."
3) The part about 'if there are people waiting in line' - how exactly would the HoP know unless he's paying attention to radio (rendering this rule somewhat pointless) or already at his desk (also rendering it pointless)?
A better alternative would be something like this:
The Head of Personnel cannot ignore ID alteration requests. They should spend a few minutes at the start of each shift processing any requests made by people who come to their office. After the initial rush is over, they should still respond to any person requesting them over PDA/radio within a reasonable period of time. Disappearing off somewhere and ignoring all requests, to the point that Captain/command consider them MIA, is considered incompetence. -
abductions
Just to clarify: Terror Spiders' reproduction is quite different to Xenomorphs'.
Xenos have to facehug people, abduct them, drag them back to a nest, and wait for them to burst.
On the other hand, Terror Spiders have three breeding methods, none of which involves abduction:
- Greens kill/incap you, then web you up and drink your blood. Once you are webbed, you cannot be moved (though you can be freed if someone destroys the cocoon - something spiders cannot do). They also have no incentive to wait on webbing you, since once they web/drink you, they can then lay eggs at any future point. Their main method of movement is vents, and they can't take bodies through vents, so the mechanics heavily discourage them from abducting people. Their incentive is to kill you and drink your blood, not abduct you.
- Whites want to infect you with spider eggs. They infect, then they run. That's what they are designed for. At most they might tranq you, but combat is a big risk for them so they want to avoid attracting attention. They're hit-and-run spiders.
In general, terror spiders are not intended to, and don't have the mechanics to support, crew abductions.
The egglaying types cannot generally open powered doors, for example, and you can't take a body with you through a vent.
-
This has been a really annoying trend as of late. You know those cliques that always RP together and ignore the rest of the station? They really like joining Security.
Boy is it ever lovely when I'm being attacked and I have to yell over the comms for five minutes before someone actually arrives, they linger for a few moments while the guy runs off, then the guy comes back and it takes another five minutes to bring them back.
If sec is not very effective:
- Ask the HoS to straighten out their officers, and/or hire more if they're slow because they're overstretched.
- If that fails, tell the Captain that security is failing to do their jobs. He/she can investigate and correct the problem.
But in my experience, sometimes it is hard to really secure things when your HoS pretty much goes "Just gear up and patrol" rather than hold a meeting and get a plan in place. Sure, it might make things easier to just get up and go, but I'm the kinda guy who would rather the crew of a certain branch get together and discuss the plan better. As QM, I always have a meeting with my Cargo techs first to assign jobs before getting to work, which I believe makes things easier and also gets people immersed.
When I play security, I assume that any HoS who calls a "meeting" at the start of the shift is a bad HoS.
I find that such meetings generally occupy the entire sec team for 20 minutes, during which time there is absolutely nobody providing security for the station. Good security officers have probably heard everything the HoS will say already, while bad ones won't turn up and/or listen regardless of what the HoS says.
The entire sec team has radios. Using them is better than having an in-person meeting, because:
- It is much faster, because you don't have to wait for people to arrive.
- Officers can do other things (like patrol) while they listen.
-
Updated (Apr/13) list of sprites I'm looking for:
1st priority (spiders still stuck with codersprites)
- Green spider (an egglaying, webspinning spider)
2nd priority (spiders currently stuck sharing sprites with other spiders)
-
Mother spider (a spider with other spiders on its back)
-
Prince spider (a fast, aggressive, tank-like spider hardened for battle)
Queen spider (a huge egglaying and nestbuilding spider)
Empress spider (an enormous, battle-hardened queen that ideally needs both 32x32 and 64x64 sprites)3rd priority (new items I am looking to add)
-
Spider carapace (a drop from spiders that can be crafted into things, can look like goliath plates)
-
Spider body armor (a body armor that I'd like to make craftable with bits of carapace, can look like sec body armor)
4th priority (spiders with viable sprites I'd still like to replace/change)
-
White (vicious-looking, fluffy)
- Gray (smaller-looking, stealthy)
-
Ping did a second (and far more successful) run through with some Paradise admins watching:
This is the video that went up on r/ss13.
Thoughts/suggestions/ideas/comments/etc on the awaymission, and the spiders in general, are still welcome.
Although I am on a break right now, I will be returning to work on them soon (ie: less than a week) and will be looking to get all this wrapped up for a PR.
-
I once got a law zero stating that I was the Captain.
That was a fun round.
-
Alternatively: "the captain must make reasonable efforts to find and appoint a head for that department".
Why not both? Changed it to:
If a Head of Staff is not available for a Department, the Captain must ensure themselves that Standard Operating Procedure is followed, or must at least make reasonable efforts to find and appoint an Acting Head for that DepartmentThat does not qualify as 'both'.
Requote, with emphasis added:
If a Head of Staff is not available for a Department, the Captain must ensure themselves that Standard Operating Procedure is followed, or must at least make reasonable efforts to find and appoint an Acting Head for that DepartmentThat "or" there could be interpreted as: "So long as a Captain has made a reasonable effort to appoint an acting head for a department, they've done all they need to do under this rule." A skeptic might interpret that as: "So long as a Captain makes reasonable efforts to appoint a head for all departments, they are not violating this SOP rule, regardless of how many SOP violations their departments commit".
Alternatively: "The Captain may not fire anyone from command without good reason."Requiring a vote is silly.
I have to say I disagree. Letting the Captain fire someone "with good reason" allows for a tad bit too much wriggle room. Whose good reason? What's a good reason?
A good reason is one of the set list of valid causes for demotion stated on the Wiki.
Adding this weird voting requirement means either:
(A) It provides an additional valid reason for a Captain to demote a head when none of the other valid reasons for demotion apply, in which case Captains can demote anyone they can get the heads to vote against for any/no reason. This encourages demotions to be a popularity contest rather than a comparison with a set of objective standards - it basically lets the Captain initiate a "vote them out" against any head for no reason.
Or:
(B) It doesn't provide an additional valid reason, in which case it is completely redundant because voting can't make an invalid reason valid or a valid reason invalid, and thus has no actual impact on whether a demotion is legit or not.
If (A) is the case, you're effectively giving Captains an additional criteria they can optionally use to justify a demotion, which is an expansion of power rather than a restriction, and if (B) is the case you're wasting words as votes are still not a valid justification.
Neither seems like what you want to be doing.
Keep in mind, the vote is only for situations where the Head isn't being openly incompetent, ie, situations where conflicts may arise. Having the whole of Command on board what may very well be a controversial decision saves a lot of hassle.
Suppose the CMO gets on medical comms, and starts asking basic questions like "how do I treat a wound?". It is obvious they do not have the knowledge to be CMO. They're incompetent, but they're not openly so, because only other people with medical radio access see it. The Captain sees it, and moves to demote after it becomes clear the CMO has no medical experience, but the other heads vote against him, because they (not having medical radio access) never saw the comments, and the CMO is claiming they're having a "slow day" or whatever. What was previously an obvious demotion is now a contentious topic - and for no good reason. "Openly incompetent" is a lot easier to detect when you can see all radio chatter.
-
Thanks to Travelling Merchant, the black type is now sprited:
Green/etc still need sprites.
-
If a Head of Staff is not available for a Department, the Captain must ensure themselves that Standard Operating Procedure is followed;
Alternatively: "the captain must make reasonable efforts to find and appoint a head for that department".
The Captain may not fire anyone from Command without majority approval from Command, unless said someone is blatantly acting against the best interests of NanoTrasen, the station and crew. In the case of a voting deadlock, the Captain is to be considered the tiebreaker vote;
Alternatively: "The Captain may not fire anyone from command without good reason."
Requiring a vote is silly.
No Law Changes are to be performed without full approval from the Captain, Research Director and at least one other member of Command (Blueshield excluded).
Alternatively: "No law changes are to be performed without the approval of the Captain AND Research Director. In the event there is no Research Director, any other head of staff may fill in to confirm the law change."
Captain + RD should be enough to authorize a law change.
Also, the word "full" is redundant. In the spirit of Yoda, there is only approval, and lack of approval. There is no "approval but not full approval".
Freeform Laws are only to be added if absolutely necessary due to external circumstances (such as major station emergencies). Adding Freeform Laws without proper approval is to be considered Sabotage;
Freeform laws are a major source of fun, and this removes that entirely.
In the absence of a Captain, the Head of Personnel is to be considered the Acting Captain.
What happens if the HoP decides they don't want to be acting captain? I've seen this happen a few times.
-
Update 12: https://github.com/Kyep/Paradise/commit ... 7a006c7c94
Mini-update for the sake of Ping's awaymission testing team:
- Bugfixes for away mission doors appearing in walls. All three cases (chem lab 1 & 2, medbay maint) are fixed.
- Major rebalance for awaymissions to reward smarts (hardsuit available near start), increase self-sufficiency (UO71 medbay now has cryopod & synthflesh patches), and punish clueless zerging (giant black widows are incredibly lethal to greytide now).
- New atmospheric lighting for awaymission. Yes, its controllable.
- New story, with accompanying loot that you can take with you out of the mission.
- All spiders can now open public-access doors.
- Eliminated over-complicated "war" system, and refactored diplomatic options for queens.
- Enabled static placement of grays, without ventcrawl. This enables other people to use them in designing away missions.
- Prevented spiders from cocooning paper. Partly for awaymission balance, partly for RP reasons.
- Ensured loot that drops from spiders appears on top of, not below, their corpses. In the case of keycards, this is very important.
- Prevented ghosts from being offered control of dead spiders when they clicked on them.
- Rewrote Show Guide verb, now includes a summary of all other verbs, including rare/type-restricted verbs.
- Erased the silly AOEWeb ability of Grays. Instead, gave them better nesting AI that automatically sets up webs near their lairs - and keeps them there once they find a good nesting spot (ie: they won't nest in tiny rooms, or in places with no trap spots, or next to the queen). Player-controlled spiders also go through the nesting setup. This ensures player spiders can more conveniently build nests, but also prevents them from abusing their invisibility to cloak up near-instantly on a new vent.
- Fixed bug where ghosts were offered control of queen in awaymission, even though she's never controllable.
- Made queen poison spit respect THICKMATERIAL on chest (empress still ignores). This is a big deal as even 1-2 hits from her can have a large impact on the fight if you are not properly protected and/or carrying the right healing meds.
- Made walking into a terror web have a good chance to decloak and aggress any gray spider hiding in the vicinity. Running into the the webs *will* get you ambushed and killed.
- Removed the ability for destroying terror webs to do the same. Shooting all webs from maximum range to flush out the spiders and engage them at a safe distance no longer works. They are too smart for that now.
- Fully switched over from codersprites to Travelling Merchant's sprites for the black spider, aka: giant black widow spider. Amazing sprites. Previously, black spiders would change sprite sets as they died or faced north. Now they will look badass all the time.
-
Excellent. Just copy paste it to the terror spider wiki page when you're done and everything is implemented.
That's the plan.
Fair warning: I'm unlikely to keep anything currently on the WiP version of http://nanotrasen.se/wiki/index.php/Terror_Spider when I do the copy-over. At least in its current state, it is very inaccurate.
Examples:
- Access is wrong - brute force does not open everything. Their access is more correctly summed up as "anywhere with an unwelded vent", though there are some exceptions to this as well.
- Duties are misleading - "feeding" plays a minor role. Their duties could be more accurately described as "obey the queen" (if there is one), or "build a nest and kill anyone who tries to stop you" (if there isn't one).
-
Update 10: https://github.com/Kyep/Paradise/commit ... d300646521
- Updated some black spider sprites
- Prevented white spider victims in gateway from bringing infection to main station, using new, better method
- Refactored lots of code
- Bugfix for spiders getting other spiders as enemies
- Bugfix for failed faction inheritance
- Bugfix for spiders getting stuck in vents.
- Expanded guide/orders help system
- Merged all attack code, fixing various attack code bugs
- Made away mission queen continue spawning spiders after maximum IF spiders are dying
- Refactored HiveCommand/etc code to share between queen and Empress, eliminating mostly-duplicate code
- Fixed bug with breaking cameras/firelocks
- Fixed awaymission teleproofing
- Fixed lots of minor issues with awaymission, found during "try to cheese this!" testing
Update 11: https://github.com/Kyep/Paradise/commit ... 36f6c00c35
- Reverted to update 9 map file, then re-did all the map changes in update 10. This was the only way to get around the permanent map corruption that sometimes happens in BYOND.
- Eliminated spider chittering.
- Fixed bug where deadly white/black types could almost never inject venom. Also added notification of which body part they are targeting.
- Added feature where grays stay on vents (cloaked) if possible.
- Added verb for grays to quickly set up lots of webs.
- Simplified Gray cloaking
- Increased # of spiders queens will spawn by default, to 25.
- Made destroying a web that a gray has built with AOE web, have a chance to decloak the gray.
- Made grays move a lot slower while cloaked.
-
I mean more of stuff along the lines of:
Player opens door to cryodorms>Spider is sitting in there waiting to ambush someone because they see the room as a valid ambushpoint>Player who wants to cryo gets mauled.
Thoughts:
1) If a player-controlled spider is willing to do that, blocking attacks in cryodorms won't solve it. They could just ambush people on their way to cryodorms.
2) An AI spider can already be stopped from doing that by simply welding the vent in cryo, same as with any other area. If the vent in an area is welded, they can't ventcrawl to that area.
3) People who are going to cryodorms probably don't care if they die, as they're leaving the round anyway.
4) Putting in a code check for this one specific room would create weird situations, e.g: spider chasing someone through the halls, player leads them to cryodorms, suddenly spider cannot attack them for no obvious reason.
5) As far as I know, there are no other monsters, player-controlled or not, which have a hard-coded check preventing them from attacking in that one specific room.
I have, however, put in a check that prevents spiders (AI or player) from targeting or attacking SSD players.
This only applies to characters controlled by players who are logged out. IE: who generate the "Probably suffering from SSD." message if you try to shake them.
Simply AFKing in the round will not earn you any mercy, because you are still logged in.
This check exists to prevent someone whose internet drops out from dying to spiders while they are disconnected.
-
I recommend that you blacklist certain rooms so the AI spiders don't enter/hide in them. Namely Cryodorms.
There's a partial blacklist already - queens, for example, won't nest in hallways, or in any room where a hostile is visible.
I'm not going to arbitrarily ban spiders from ever entering the cryodorms room, though, because:
A) If the person is actually SSD, they should be in the cryo pod, which spiders can't open
B) If they're not actually SSD, they're just AFK, they're a valid target.
I might code in something that makes spiders consider SSD players to not be valid targets, however, and prevents player-controlled spiders attacking anyone who is SSD.
-
What? Are we making it a thing? Could the spiders breath in space (they shouldn't)? Should I start a wiki page?
So many questions so little time...
EDIT: making the wiki page...
Yes, the plan is to do a PR and get it merged in once I'm satisfied with it.
It is taking some time because it is complicated.
For comparison, Xenomorphs reproduce in one way (facehuggers), have 7 types (facehugger, larva, drone, hunter, sentinel, queen, empress), and one event.
Terror Spiders reproduce in 3 ways, have 10 types (red/green/gray/white/black/purple/mother/queen/prince/empress), 3 events, a gateway mission that revolves around them, and are designed to have AI smart enough to be a genuine threat to crew even without player control (though equally, they're also playable).
Terror Spiders will not be as polished as Xenos upon release. But they should be at least as deep as Xenos are, mechanically, and just as interesting, both to fight and to play. That's what I'm aiming for, anyway.
Yes, the spiders can hold their breath in space. RL spiders can survive being underwater for literally hours. These are space spiders. To have space kill them seems silly (and bad gameplay, it encourages people do do things like bomb areas / depressurize rooms to try to kill them).
As for the wiki, check out: http://nanotrasen.se/wiki/index.php/User:Tzo
Not final, but it is where I've been working on the documentation I will add as a proper wiki page when they're merged.
Looking forward to this man, can't wait.
They're looking forward to it too.
-
The first version of my terror spider away mission has been added to Github:
http://nanotrasen.se/forum/viewtopic.ph ... 706#p61706
If you want to download and playtest it, you can.
It isn't finished yet, of course, but it is playable in its current state.
-
Update 9
https://github.com/Kyep/Paradise/commit ... 2d59ad39c9
Major changes:
- New awaymission featuring the spiders
- Major balance changes designed to enable crew to use defensive items
- Major AI rewrite/improvements
- New loot items
The awaymission may yet see substantial change. It is intended to be a tutorial for fighting the spiders, but also a challenge which is much harder than any existing away mission.
For further info on the away mission added in this update, see here: http://nanotrasen.se/forum/viewtopic.php?f=2&t=7449
If you'd like to download the map and test it, you're more than welcome to - I value all feedback!
Detailed changelog (copied from the update on Github):
- Added UO71, an away mission with terror spiders. See forum thread: http://nanotrasen.se/forum/viewtopic.php?f=2&t=7449
- This away mission has its own items, ID cards, etc. Its is hidden from default camera networks, and has code changes to support new mob behaviors. It also has 3 bosses (higher tier spiders), balanced loot, etc. Still a work in progress, but its playable in its current state should you want to playtest it.
- Moved sprites from animal.dmi to new terrorspider.dmi
- Blacklisted ALL types of terror spider so they are no longer spawnable via random reactions in scichem or xenobio.
- Added new chem - green spider pheromone. Reduces spiders' aggro radius for you when it is in you. Obtainable from green spiders.
- Changed spider_ckey_blacklist from a mob-specific var set on every mob to a global var.
- Made all spiders anchored, to prevent people dragging them.
- Fixed bug where spiders could get stuck pathing towards an object forever.
- Fixed bug where green spiders could try to path to a cocoon object and a vent at the same time, resulting in silly movements.
- Added ai_ventcrawls variable which can be turned off on a spider to prevent it ventcrawling at all, ever. Used for away mission mobs and purples.
- Merged all the handle_automated_action AI code (except for Queen) into one big routine. Eliminates duplicate code, prevents conflicts/bugs, and is generally neater by far.
- Added role summaries for all spider classes. You will be given these if you try to inhabit one as a ghost. So you know what you are getting into.
- Added drops-on-death medals as loot for boss spiders.
- Added enforcement check to prevent passive spiders being able to attack anyone, and defensive spiders being able to attack non-enemies, even when player-controlled. This is designed to prevent one bad apple playing a spider from ruining the RP of the round by going ham on sec during a peaceful TS colony.
- Added gun (awaymission_spidergun) which wrecks low-tier spiders in awaymissions.
- Expanded examine system to provide a lot more info about spiders on examine.
- Fixed bugs with notify_ghost system that was advertising spiders as controllable when they weren't, and notifying people too soon.
- Added ClearObstacle routine to break objects while spider is chasing something and AI-controlled.
- Renovated loot system to introduce new loot types for three spiders (green/black/white venom glands).
- Added notice when a hidden spider emerges from a vent (except for grays)
- Added guide & RP suicide option for empresses.
- Made gray spiders player-controllable for the first time. Their cloaking / vent hiding now works for players, too.
- Major balance change: spider bites no longer penetrate THICKMATERIAL, meaning that eng hardsuits offer 100% immunity to spider venom injection and will save your life!
- Major upgrade to AI of white spider - now uses less force against non-resistant targets, but will use lethal force against things it can't seem to poison.
- Dramatically reduced chances of a queen nesting in an area with enemies, a hallway, etc.
- Added wireless AEGs, a new type of AEG that has only a kill setting, only works in awaymission, and is designed for away mission adventures. It does not work on the station or any non-awaymission zlevel.
-
Current list of sprites needed:
1st priority (I'm currently using placeholder codersprites I dislike, because I have no usable sprites):
-
Green (egglayer)
- Black (giant black widow with red hourglass)
2nd priority (I'm using sprites shared between classes, or that don't really fit what the class now does):
-
Mother (spider with other spiders on its back)
-
Prince (big boss hardened for battle)
Queen (big boss, if possible carrying large egg sac)
Empress (older, more experienced battle-hardened queen, needs both 32x32 and 64x64 sprites)3rd priority (I'd prefer to see them closer to the references I posted, but it isn't a big deal)
-
White (vicious-looking, fluffy)
- Gray (smaller-looking, stealthy)
Obligatory example image for the Prince class:
The Prince graphic doesn't have to look like that, or be black, it just needs to look fearsome.
-
Command Job SOP --- Complete!
in Wiki Development
Posted
The Captain is in charge of checking that EVERYONE is doing their jobs correctly?
Also, is this really how we define the responsibility of the Captain, as the first-line item?
Perhaps:
"The Captain's main responsibilities are: protecting the nuclear disk, managing the heads of staff, leading the crew, and ___. Captains don't do other crew's jobs for them, they merely ensure jobs are done correctly, typically by managing the heads, who then manage the rest of the crew."
Perhaps add "The Captain should not generally place themselves in harm's way."
Perhaps replace "requisition" with "take".
The ID computer can't open job slots for heads. This is redundant.
Does this overrule the long-established rule that certain things (e.g: capital crimes) automatically authorize termination/demotion?
"The Head of Personnel may not ignore ID change requests"... etc.
Don't chain them to the desk.
"HoP to desk!"
"What do you need?"
"I want access to X!"
"Head Y, do you approve their access to X?"
"No"
"Sorry, can't do that"
*unnecessary return to HoP office avoided*
Maybe change this to "substantial equipment"? Or "important equipment"?
Technically if they pick up a medkit from the floor of medbay, and fail to ask, they're guilty of violating this.
Sub-department?
Agreed. It should remain in the Captain's office.
More seriously: "The NT Rep is not a head of staff, and ranks after them in the Chain of Command."
"detain" => "have"
"... the NT Rep must remind the Captain to appoint a head for that department."
RIP Magistrate.
"Nor may they threaten to fire, or have CC fire, anyone."
"In such a situation, the NT Rep should also evaluate whether a shuttle call is necessary."