mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-15 03:27:46 +00:00
25d4afc869
## About The Pull Request You can no longer craft explosive lances. ## Why It's Good For The Game Explosive lances are unhealthy for the game in it's current iteration. Many years ago when the game was more loose and we weren't dealing with players who treat the game like competitive TTT or Town of Salem, They are a one shot kill weapon, which is the most powerful kind of weapon in every gamemode. @JohnFulpWillard likened it to 1f1, a concept from Town of Salem players where the town trades 1 person for 1 bad guy. Modern ss13 design includes a significantly heavier load of antagonists that aren't fixed roundstart compared to when the e-lance went in. When we added the e-lance, if nuke ops spawned, that was it, there was nuke ops, if you e-lanced the nuke ops and died you were dead until the next round. Nowadays you're rolling for lone operative, blob, wizard, disease, revenant, and every other fun enjoyable antagonist role under the sun. I can e-lance a nuke op/cultist/traitor/revolutionary/any bad guy in the game as a non-antag assistant, die, and have a good chance to roll another, way more fun antag in deadchat. My change to make the e-lance a proper "we both die" tool didn't actually help because I didn't quite realize that to the modern SS13 player because of how we designed Dynamic and antagonists in the modern era, death is, frankly, not a punishment anymore. It's time we admit the facts, items designed in 2015 SS13 in #12389 simply don't hold up in a healthy manner in 2022 SS13. Dying in SS13 in 2015 was a significantly different experience with different consequences than it has now, and right now "kills you when you use it" is not the same massive downside it was 7-8 years ago. ## Changelog 🆑 del: You can no longer craft explosive lances. /🆑
Datum Component System (DCS)
Concept
Loosely adapted from /vg/. This is an entity component system for adding behaviours to datums when inheritance doesn't quite cut it. By using signals and events instead of direct inheritance, you can inject behaviours without hacky overloads. It requires a different method of thinking, but is not hard to use correctly. If a behaviour can have application across more than one thing. Make it generic, make it a component. Atom/mob/obj event? Give it a signal, and forward it's arguments with a SendSignal() call. Now every component that want's to can also know about this happening.