mirror of
https://github.com/Aurorastation/Aurora.3.git
synced 2026-07-21 21:10:30 +01:00
hazelrat
eef80013fa
This introduces logic to place starlight onto turfs under horizon/exterior, and extends that area across the entirety of the Horizon's EVA areas, to remove the anachronistic darkness that's been atop the wings up to now. Handling this at the area level was the cleanest way I could think to implement it. <details> <summary>How it looks!</summary> <img width="954" height="711" alt="image" src="https://github.com/user-attachments/assets/ef82f1fe-0720-4559-8dca-390bf1ddff4d" /> <img width="924" height="878" alt="image" src="https://github.com/user-attachments/assets/ffa37bd2-7814-42eb-99ae-ebfc1ed1b680" /> <img width="917" height="904" alt="image" src="https://github.com/user-attachments/assets/8b36f9c9-dbe1-4c5a-bb0c-f5080eb359f4" /> <img width="953" height="952" alt="image" src="https://github.com/user-attachments/assets/531724ba-2a19-4ddd-bd31-70a1ebfb4543" /> </details> **Potential problems:** <details> <summary>Shuttle logic problems</summary> To get this working, all of the Horizon's EVA areas have had to be covered in the horizon/exterior area - which means there's now an area clash on the south, west, and east shuttle port, which falls afoul of the current is_valid check for shuttle landmarks. Notably, how this is mapped also means that an rfloor silhouette of a shuttle is always left on the Horizon after a shuttle undocks from any of these landmarks. <img width="864" height="704" alt="image" src="https://github.com/user-attachments/assets/4fd27d84-8d7c-4ed7-8333-f934a2d77e03" /> The problem here is on the mapping, not the logic - it seems like these areas were formerly excluded from the horizon/exterior area exactly to dance around this problem. The solution I've taken tentatively is simply to remove the area check. This doesn't feel great, but I don't think there's many situations in which it could bite us - maybe on exoplanets? The only other solution here is to remap the Horizon's docking ports to not suffer from this issue, which I'm not eager to do. I honestly just attribute this to being another fundamental flaw of the Horizon's design that we have to just dance around until we move off the map. I've documented that it's purely a mapping issue on the commented code segment, and that once the mapping issue is resolved there's no issue with an area check. </details> - [x] Figure out how to have starlight carry over after a shuttle departs - [x] Resolve the Horizon's shuttles being unable to dock with its docking ports --------- Signed-off-by: hazelrat <83198434+hazelrat@users.noreply.github.com> Co-authored-by: Matt Atlas <mattiathebest2000@hotmail.it>
72 lines
2.7 KiB
Plaintext
72 lines
2.7 KiB
Plaintext
/turf/space/transit
|
|
plane = 0
|
|
use_space_appearance = TRUE
|
|
var/pushdirection
|
|
|
|
//Overwrite because we dont want people building rods in space.
|
|
/turf/space/transit/attackby(obj/item/attacking_item, mob/user)
|
|
return FALSE
|
|
|
|
//generates a list used to randomize transit animations so they aren't in lockstep
|
|
/turf/space/transit/proc/get_cross_shift_list(size)
|
|
var/list/result = list()
|
|
|
|
result += rand(0, 14)
|
|
for(var/i in 2 to size)
|
|
var/shifts = list(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14)
|
|
shifts -= result[i - 1] //consecutive shifts should not be equal
|
|
if(i == size)
|
|
shifts -= result[1] //because shift list is a ring buffer
|
|
result += pick(shifts)
|
|
|
|
return result
|
|
|
|
/turf/space/transit/north // moving to the north
|
|
pushdirection = SOUTH // south because the space tile is scrolling south
|
|
var/static/list/phase_shift_by_x
|
|
|
|
/turf/space/transit/north/Initialize()
|
|
. = ..()
|
|
if(!phase_shift_by_x)
|
|
phase_shift_by_x = get_cross_shift_list(15)
|
|
|
|
var/x_shift = phase_shift_by_x[src.x % (phase_shift_by_x.len - 1) + 1]
|
|
var/transit_state = (world.maxy - src.y + x_shift)%15 + 1
|
|
|
|
icon_state = "speedspace_ns_[transit_state]"
|
|
|
|
/turf/space/transit/east // moving to the east
|
|
pushdirection = WEST
|
|
var/static/list/phase_shift_by_y
|
|
|
|
/turf/space/transit/east/New()
|
|
..()
|
|
if(!phase_shift_by_y)
|
|
phase_shift_by_y = get_cross_shift_list(15)
|
|
|
|
var/y_shift = phase_shift_by_y[src.y % (phase_shift_by_y.len - 1) + 1]
|
|
var/transit_state = (world.maxx - src.x + y_shift)%15 + 1
|
|
|
|
icon_state = "speedspace_ew_[transit_state]"
|
|
|
|
/turf/space/transit/bluespace //this is typically going to be used by shuttles/ships that aren't present in the sector, to imply they've had to bluespace jump some distance away.
|
|
name = "bluespace"
|
|
desc = "The blue beyond, a breach into an unknown dimension. Don't lick it."
|
|
desc_extended = "Bluespace is a very strange form of pocket dimension, that is largely unpredictable and completely unexplored. While there is speculation about the possibility of celestial bodies existing in Bluespace, it is highly unlikely. Travelling in the Bluespace dimension without a proper gate or Bluespace drive has thus far been proven to be incredibly dangerous, with probes either appearing in unintended locations or never returning at all."
|
|
icon_state = "bluespace-n"
|
|
plane = 0
|
|
use_space_appearance = FALSE
|
|
use_starlight = FALSE
|
|
|
|
/turf/space/transit/bluespace/ChangeTurf(path, tell_universe = TRUE, force_lighting_update = FALSE, ignore_override = FALSE, mapload = FALSE)
|
|
return ..(path, tell_universe, 1, ignore_override, mapload)
|
|
|
|
/turf/space/transit/bluespace/east
|
|
icon_state = "bluespace-e"
|
|
|
|
/turf/space/transit/bluespace/south
|
|
icon_state = "bluespace-s"
|
|
|
|
/turf/space/transit/bluespace/west
|
|
icon_state = "bluespace-w"
|