lewc

Yeah, agreed. I think fo the morph through the lens of being a prop hunt antag, and I think the skitter and encouraging people to interact with them seem like a plus

Morphs used to be able to eat items, but that was done away with on purpose during the rework that brought morph to its current form. "Morph ate the whole damn armory" is what I think we're trying to avoid. I do kinda like this, personally. Being able to jump like three or four tiles quickly might make a good difference. Kinda skittering like a spiderling.

iirc that's only the case for private (hidden) repositories. You can have as many contributors as you want for public repositories, so realistically anyone you want can help pitch in. If runners were to get added, it'd make sense in my eyes for them to be the evo of choice once vents get welded and that clumping up happens. Something that can get around the station quickly without the need of vents. As for spriting/licensing, I'm no expert so take this with a grain of salt, but the licenses on sprites on TGMC seem to generally be CC-BY-NC/CC-BY-NC-SA, while sprites on CM are CC-BY-SA. If we want to port sprites, I believe CM's license would be much more compatible with our existing license.

Yeah, I feel like I very rarely (if ever) see players run out of department headsets. Even for sec, it's much easier to get your hand on a new headset than a new baton. The only time I can really see a shortage of headsets emerging is if a) a vamp has a penchant for removing people's headsets in maint and keeping them, or b) HoP goes on a hiring spree and fills a new department with more people than they have lockers. If a necessity really arises, it'd probably be worth just asking CentCom for a shipment of new headsets or working with intercoms. That being said... Some sort of tool or encryption key rewriter that could change one key into another (that isn't sec/command) might be neat QoL for the HoP. A 1 to 1 tool that requires you to exchange an encryption key for another or convert one type of headset (with its original encryption key) into another would make it harder to really meme with every comms channel, since the HoP will probably be a little suspicious if you come back with three different headsets.

Yeah! I've seen hackmd.io used a fair bit recently for design docs and such (especially on /tg/) and it seems like a pretty solid tool. As for finding coders, I'd be more than willing to throw my hat into the ring. I'm still relatively new to writing DM, but I feel like I'm getting to the point where I feel comfortable writing things in the language, and I'd be willing to see how I can help. I can't say I've really seen any big teams working on changes like this (most of the past big antag refactors have been solo work I think) but I think it'd be worth a shot if you can get a few people together. Maybe see about reaching out in #coding-chat to see if you might be able to drum up some support there?

I'm so happy to see this coming back again! I've been playing a lot of TGMC lately so I'd be really excited to see beno gameplay get the attention it deserves on paradise. If I may, you might want to try putting your design doc up on hackmd.io. It respects GitHub markdown (even summary tabs and stuff) and can be commented on with threads and stuff, so it might make it easier to review/go through especially for people who don't want to doxx themselves on google docs I might as well spitball some things here, I'd put them on the doc but I don't have a good anonymous google account. I can definitely move them over if this goes onto hackmd or something. For a counter to mechs/robots, I feel like we're looking at some creatures that what they lack in damage output make up for in CC. Perhaps it could make sense to adopt the concept of xenos firing non-destructive sticky resin to gum up mechs, slowing them down or slowing down their weapon fire-rate? Crew could possibly burn it off with a welder, lasgun, or flamethrower, a mech won't be able to really solo a hive without literal fire support from (possibly vulnerable) humans. Something like sticky resin traps, too, or perhaps door-like structures that xenos and humanoids can crawl through, would provide some interesting environmental gameplay in the tight confines of the station. I really like the idea of giving xenos a speed buff on weeds but making non-hunter xenos as slow as humans off of them, if not a bit slower. Xenos are supposed to be agile, but this gives them a mobility reason to weed everywhere they can. On the topic of speed, hunters could perhaps get a speed boost out of combat, but lose that boost after interacting with something (like dealing damage or trying to drag someone off). I agree that one of the biggest gripes people have with benos is getting stunned and superspeed dragged through the halls back to the nest, and it might be nice to see something addressing that. Regarding acid, I personally think it makes sense to keep wall-melting acid expensive. Xenos have all of these great movement tools at their disposal and so maybe it would make sense to force them to use them rather than busting down any obstacle in their way. Maybe keep it slow to finally destroy walls, but consistent (only needs one application)? Lastly, I think there should be some sort of passive, weed-free plasma regen, though it should be very weak to encourage weeding. The regen speed would need to be slow, and perhaps its amount could be capped per xeno to only allow for a base ability. If it's under consideration at all, I feel like it's a necessity that drones be able to at least regen enough plasma to plant weeds. I really like what you've got cooked up so far otherwise! Can't wait to see what comes out of it, and I'll definitely be keeping an eye on it

Right, so there's Move() as well in our codebase (I think doMove() on /tg/) which handles key-input type movement where diagonals need to be accounted for as well. I would have to look into the usage of that a bit more. But to answer your question, no; forceMove sets .loc as one of the first things it does. There may be a little more overhead on using forceMove() over .loc setting, since it calls Moved() and fires other enter/exit signals.

I've been tossing this around as something I'd like to do, but I guess this is the best place to formalize it. The resulting change would probably hit everywhere in the codebase, so I also wanted to make sure it could be run by maints as needed. In my work on refactoring the orbiter, I reworked orbiting to follow COMSIG_MOVABLE_MOVED signals, where if objects are moved, the signals indicate that. There's a bit more detail with separate MOVED signals of moving things between containers, but I won't get into the nitty-gritty there. After the refactor went live, I've seen at least three or four different cases where orbiting has broken where it previously used to work: disposals, vent crawling, table climbing, etc. The root cause is pretty much the same across each issue, where an atom is moved by directly setting its .loc. This is easy and convenient to write, but circumvents any general movement handling from being applied on it. In particular, we never get Moved(), which does a few things like sending the MOVED signal and updating parallax/client views. This isn't good for orbiters, proximity monitors, or anything else that relies on signals to know when something's moved. As for the fix, I've been doing some research into how /tg/ handles their movement. It seems to me that they've settled on two basic move methods: - abstract_move() for anything that should have no side effects from movement and shouldn't be affected by anything when moving. This includes things like the AI eye and observers, and the /tg/ function docs note that it could be good for moving something onto a tile with a bear trap or something (possibly skipping crossed() signals). - forceMove() for literally everything else. Seriously, I'm pretty sure there was an effort to replace all .loc calls with forceMove. ForceMove already exists in our code, but abstractmove would be a new addition. It shouldn't need to go into too many places, so it should probably be an easier first addition. After that, though, it might come down to switching every manual setting of .loc to a forceMove (save for the rare cases where abstractmove would be better). I think it'd be best to do in pieces if possible, since I already ran into some bugs while trying to get vent crawling working with it (it resets the client's perspective and can fire off some other behavior). If we could document and understand exactly what is going on deep below this proc (particularly in the depths of Moved(), including its overrides), we could probably work out most of the issues before plugging it into everything. I know I'm still a fairly new contributor to the codebase, so it's possible I could be off the mark on something significant, but I feel pretty confident in the fact that this would not only make my life easier w/r/t managing each little orbiting bug as they appear, but also pave the way for more things to be able to consistently rely on movement signals, like steel's proximity monitor component. I'd be happy to try and take the lead on this, as a result.