Files
Bubberstation/code/datums/components
BurgerLUA e87045b377 Tweaks some instances of get_safe_turf so things like the nuclear disk doesn't accidentally teleport to the Icebox Syndicate Base (#83012)
Yes, I know preventing the nuke disk teleporting to the icebox syndicate
base (or possibly the wendigo arena) is removing soul. Please don't kill
me :(

## About The Pull Request

Adds some missing variables to instances of get_safe_turf() so they will
only teleport to the given z-level.
Replaces some instances of get_safe_turf() with
get_safe_random_station_turf().

## Why It's Good For The Game

First, the differences between get_safe_turf() and
get_safe_random_station_turf():

### get_safe_turf()
- gets a random safe turf on a z-level (usually any of the staiton
z-levels), not accounting for the /area/
- should be used if you don't care if it spawns on the station or not,
or if you need to specifically teleport to a z-level
- not very expensive performance wise

###  get_safe_random_station_turf()
- gets a random safe turf that will always be a station area, ignoring
z-level.
- should be used if you NEED the turf to be on a station's area
- slightly more expensive performance wise than get_safe_turf, but still
very cheap

Some code was using get_safe_turf() when it should've been using
get_safe_random_station_turf(), and some code that should be using
get_safe_turf() were incorrectly using the zlevels arg instead of zlevel
arg (Yes, there is a difference), or didn't include it at all.

All the changes were made to my best judgement. If you're curious about
a change, please ask and I will explain why I did it.

## Changelog

🆑 BurgerBB
fix: Tweaks some instances of get_safe_turf so things like the nuclear
disk doesn't accidentally teleport to the Icebox Syndicate Base
/🆑

---------

Co-authored-by: Jacquerel <hnevard@gmail.com>
2024-06-14 21:57:33 +01:00
..
2024-06-14 20:39:29 +00:00
2023-10-16 16:14:31 +02:00
2024-04-16 17:48:03 -06:00
2024-04-09 03:21:51 -05:00
2023-10-11 16:58:29 -06:00
2024-05-16 19:54:00 -07:00
2024-02-11 03:17:55 +01:00
2024-06-05 10:17:34 -04:00
2023-12-04 14:42:43 -08:00
2024-05-16 19:54:00 -07:00
2024-06-13 13:29:45 -07:00
2024-04-20 01:39:50 -06:00
2024-04-16 17:48:03 -06:00
2024-05-16 19:54:00 -07:00
2024-05-16 19:54:00 -07:00
2023-10-21 23:36:48 +00:00
2023-10-08 03:04:35 +01:00
2023-12-04 14:42:43 -08:00
2024-03-29 22:26:35 -06:00
2023-10-05 13:20:16 -06:00
2024-04-16 17:48:03 -06:00
2024-03-27 16:49:46 -06:00
2024-03-21 20:30:56 -06:00
2024-03-16 12:06:02 +00:00
2023-08-14 12:39:30 -06:00
2024-05-16 19:54:00 -07:00

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.

HackMD page for an introduction to the system as a whole.

See/Define signals and their arguments in __DEFINES\components.dm