* Morgue dead body placer guarantees 1 human to dissect if non-human cadaver config is enabled. Morgues spawn with 1 additional body (except on Birdboat). (#77816)
## About The Pull Request
- Morgue guarantees 1 human body to dissect even if
`morgue_cadaver_disable_nonhumans` config flag is set.
- All maps bar birdboat will now spawn with one additional morgue
cadaver.
- Did some minor code cleanup around the dead body placer, removes an
`in world` loop, etc.
## Why It's Good For The Game
- Morgue guarantees 1 human body to dissect even if
`morgue_cadaver_disable_nonhumans` config flag is set.
- This is mostly a downstream server issue but if your server enables
this config and has additional species enabled, the odds of you getting
a human to dissect tends to be very low.
- Why is this a problem? Well, a human is necessary to dissect to get
medical's tech.
- Why not get genetics to get you a hu-monkey? This is an option, but if
A. there's no geneticists or B. they are refusing to cooperate then you
tend to be SOL unless you want to wait for a greytide to come in after
drinking themselves to death. Given we have a role now dedicated to
performing dissections, having no job to do for the first twenty or so
minutes due to a lack of a human body is kind of sad.
- If this is an intended facet, I will revert this change and leave it
to the code improvements / bodycount uptick.
- All maps bar birdboat will now spawn with one additional morgue
cadaver.
- This was actually intended on some maps but has been stealthily
removed in some cases? Icebox and Delta used to have two dead body
spawners to place 4 cadavers. So I decided to bring this back.
- For the most part, this just gives higher population maps more bodies
to mess around with. Higher pop means more people means more people need
bodies, either for antagging, cooking, body replacements, or coron-ing.
- Also like, sometimes messing around with dead bodies are fun, and it's
nice to not have to worry that you're running out of them for actual
medical use.
- I can also make this scale on roundstart pop if we really care. But
that seems overkill. Especially as these maps had their body counts
higher for a while and were fine.
## Changelog
🆑 Melbert
balance: If your server has non-human morgue cadavers enabled, you will
be guaranteed one human cadaver no matter what.
balance: All maps (with the exception of Birdboat) now have an
additional morgue cadaver roundstart.
/🆑
* Morgue dead body placer guarantees 1 human to dissect if non-human cadaver config is enabled. Morgues spawn with 1 additional body (except on Birdboat).
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Fixes TGM maploading not respecting upper_y crops (#77495)
## About The Pull Request
I think I forgot how the numbers worked here, seems that way at least
given how the DMM stuff looks
Closes#77482
Thanks to itsmeow for pointing this out
Oh also fixes tgm using maxx for the y comp. it should never actually
matter but yaknow just in case
* Fixes TGM maploading not respecting upper_y crops
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Add "Hall of Fame" emergency shuttle (#77074)
## About The Pull Request
This adds a new emergency shuttle called the **Hall of Fame**.
It's designed around persistence. The goal is to have the shuttle store
memories, photos, and trophies for the crew to see!
## Why It's Good For The Game
Cool way for the crew to store and share memories.
## Changelog
🆑
add: Add a new 'Hall of Fame' emergency shuttle. It even comes with it's
own nifty photo album.
/🆑
* Add "Hall of Fame" emergency shuttle
---------
Co-authored-by: Tim <timothymtorres@gmail.com>
* Implements usage of the REVERSE_DIR macro throughout the code. (#77122)
## About The Pull Request
Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro.
## Why It's Good For The Game
Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir,
180)` call, being a simple set of binary operations. To sum it up, micro
optimization.
## Changelog
N/A
* Implements usage of the REVERSE_DIR macro throughout the code.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request
Hello friends, I've been on a bit of a lighting kick recently, and I
decided I clearly do not have enough things to work on as it is.
This pr adds angle support to static lights, and a concepting/debug tool
for playing with lights on a map.
Let's start from first principles yeah?
### Why Angled Lights?
Mappers, since they can't actually see a light's effect in editor, tend
to go off gut.
That gut is based more off what "makes sense" then how things actually
work
This means they'll overplace light sources, and also they tend to treat
lights, particularly light "bars" (the bigger ones) as directional.
So you'll have two lights on either sides of a pillar, lights inside a
room with lights outside pointing out, etc.
This has annoying side effects. A lot of our map is overlit, to the
point that knocking out a light does.... pretty much nothing.
I find this sad, and would like to work to prevent it. I think dark and
dim, while it does not suit the normal game, is amazing for vibes, and I
want it to be easier to see that.
Angled lights bring how lights work more in line with how mappers expect
lights work, and avoids bleedover into rooms that shouldn't be bled
into, working towards that goal of mine.
### How Angled Lights?
This is more complex then you'd first think so we'll go step by step
Oh before we start, some catchup from the last time I touched lighting
code.
Instead of doing a lighting falloff calculation for each lighting corner
(a block that represents the resolution of our lights) in view we
instead generate cached lightsheets. These precalculate and store all
possible falloffs for x and y distances from a source.
This is very useful for angle work, since it makes it almost totally
free.
Atoms get 2 new values. light_angle and light_dir
Light angle is the angle the light uses, and light_dir is a cardinal
direction it displays in
We take these values, and inside sheetbuilding do some optional angle
work. getting the center angle, the angle of a pair of coords, and then
the delta between them.
This is then multiplied against the standard falloff formula, and job
done.
We do need some extra fenangling to make this all work nicely tho.
We currently use a pixel turf var stored on the light source to do
distance calculations.
This is the turf we pretend the light source is on for visuals, most
often used to make wall lights work nice.
The trouble is it's not very granular, and doesn't always have the
effect you might want.
So, instead of generating and storing a pixel turf to do our distance
calculations against, we store x and y offset variables.
We use them to expand our working range and sheet size to ensure things
visually make sense, and then offset any positions by them.
I've added a way for sources to have opinions on their offsets too, and
am using them for wall lights.
This ensures the angle calculations don't make the wall behind a light
fulldark, which would be silly.
### Debug Tool?
In the interest of helping with that core problem, lights being complex
to display, I've added a prototyping tool to the game.
It's locked behind mapping verbs, and works about like this.
Once the verb is activated, it iterates over all the sources in the
world (except turfs because those are kinda silly), outlining and
"freezing" them, preventing any future changes.
Then, it adds 3 buttons to the owners of a light source.
The first button toggles the light on and off, as desired.
The third allows you to move the source around, with a little targeting
icon replacing your mouse
The second tho, that's more interesting.
The second button opens a debug menu for that light
There's a lot here, let's go through it.
Bit on the left is a list of templates, which allow you to sample
existing light types (No I have no idea why the background is fullwhite,
need to work on that pre merge)
You can choose one by clicking it, and hitting the upload button.
This replaces your existing lighting values with the template's,
alongside replacing its icon and icon state so it looks right.
There are three types as of now, mostly for categorization. Bar, which
are the larger typically stronger lights, Bulb, which are well, bulbs,
and Misc which could be expanded, but currently just contains floor
lights.
Alongside that you can manually edit the power, range, color and angle
of the focused light.
I also have support for changing the direction of the light source,
since anything that uses directional lighting would also tie light dir
to it.
This isn't *always* done tho, so I should maybe find a way to edit light
dir too.
My hope is this tool will allow for better concepting of a room's
lights, and easier changing of individual object's light values to suit
the right visuals.
### Lemon No Why What
Ok so I applied angle lights to bars and bulbs, which means I am
changing the lighting of pretty much every map in the codebase.
I'm gonna uh, go check my work.
Alongside this I intend to give lighting some depth. So if there's room
to make a space warmer, or highlight light colors from other sources, I
will do that.
(Images as examples)
I also want to work on that other goal of mine, making breaking lights
matter. So I'll be doing what I can to ensure you only need to break one
light to make a meaningful change in the scene.
This is semi complicated by one light source not ever actually reaching
fullbright on its own, but we do what we must because we can.
I'm as I hope you know biased towards darker spaces, I think contrast
has vibes.
In particular I do not think strong lights really suit maintenance.
Most of what is used there are bulbs, so I'm planning on replacing most
uses with low power bulbs, to keep light impacts to rooms, alongside
reducing the amount of lights placed in the main tunnels
**If you take issue with this methodology please do so NOW**, I don't
want to have to do another pass over things.
Oh also I'm saving station maps for last since ruins are less likely to
get touched in mapping march and all.
### Misc + Finishing Thoughts
Light templates support mirroring vars off typepaths using a subtype,
which means all the templates added here do not require updating if the
source type changes somehow. I'd like to expand the template list at
some point, perhaps in future.
I've opened this as a draft to make my intentions to make my changes to
lights known, and to serve as motivation for all the map changes I need
to do.
### Farish Future
I'm unhappy with how we currently configure lights. I would like a
system that more directly matches the idea of drawing falloff curves,
along with allowing for different falloffs for different colors,
alongside extending the idea to angle falloff.
This would make out of engine lighting easier, allow for nicer looking
lights (red to pink, blue to purple, etc), and improve accessibility by
artists.
This is slightly far off, because I have other obligations and it's
kinda complicated, but I'd like to mention it cause it's one of my many
pipedreams.
## Changelog
🆑
add: Added angle lighting, applies it to most wall lights!
add: Adds a lighting prototyping tool, mappers go try it out (it's
locked behind the mapping verb)
/🆑
---------
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool
* Update north_star.dmm
* Revert "Update north_star.dmm"
This reverts commit bb5b8b5a549f7edc3e23a369a147ed96bab41991.
* Updatepaths
* Update nukie_base.dmm
* Newer version of northstar with the penguins
* Update northstar_cryo.dmm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Macros multi-z code, removes the false premise of manual offsets (#76248)
## About The Pull Request
[Removes the pretense of relative multiz
levels](0293fdc2bd)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](7d698f02d9)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
* modular files how very dare you
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Fully fixes atom init desyncs (#76179)
## About The Pull Request
The old system was... ok, but the stack trace was unfortuante, and the
potential to double remove was silly.
Let's use a list of source, value instead, to block overremovals and
properly support different load states
## Why It's Good For The Game
Prevents a bug a goodhearted bagilmin showed me where shuttles would
randomly just fail to load.
Calling clear twice should not be a failure
## Changelog
🆑
fix: Maps loaded post init will no longer randomly enter a failed state.
Hopefully.
/🆑
* Fully fixes atom init desyncs
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Gives Fugitive Hunters credible IDs, access restricts the hunter shuttles, minor hunter shuttle improvements (#75913)
## About The Pull Request
This standardizes fugitive hunter IDs, making all hunter packs use the
same subtype and giving them to hunters who would spawn with no ID at
all.
The badass flaming ID color that the OG Bounty Hunter team got are now
the standard for fugitive hunter IDs. Additionally, these IDs now come
with a radical skull trim.
(Spacepol Officers don't get the badass flaming skull ID, and instead
get a more modest Police Officer ID).
**These IDs come with access, too. Airlocks, bolt buttons, shuttle
controls, and shutters on all of the hunter shuttles now require a
hunter's ID to operate.**
While I was in the area doing mapping stuff to get the accesses in
place, I made a few other very minor changes to the shuttles. These
include:
- The Bounty Hunter shuttle now has an oxygen dispenser. Two walls have
been moved to make space.
- The Russian Hunter shuttle now gets enough oxygen tanks to share with
everyone.
- The Psyker Hunter spawners now have proper spawner menu text. This was
due to duplicate-but-not-really subtypes existing, and me mistakenly
putting the wrong ones there in a previous PR.
- The cut ai wire helpers from the Russian/Psyker shuttles have been
extended to the Bounty/Spacepol shuttles.
- Every hunter shuttle now has a shuttle pinpointer on it somewhere, and
is no longer exclusive to a single Bounty Hunter's loadout.
## Why It's Good For The Game
Some of the hunter IDs would spawn without trims or coloration, and some
hunters wouldn't spawn with IDs at all. Now, everyone gets a credible,
cool-looking ID that lets everyone know what you're here to do at a
glance.
One of these is a crazed larper with an unregistered firearm, the other
is a certified bounty hunter.
As for the hunter access, it's pretty nonsensical that anyone can just
walk into the hunter ship and set up shop. At least the pirates get
turrets! Not to mention, it's hard to balance or give hunters new
equipment in good conscience when their entire domain is public-access
and anything they can't carry is considered forfeit to the crew. Now it
can be used as a base of operations, storage area, etc. more securely.
Locking down the shuttle with accesses isn't going to stop a determined
gamer with a toolset, but it'll at least make it more interesting and an
actual risk. If the fugitives want to try and loot/hijack the shuttle,
it will require the effort of taking down one of their hunters first.
While hunters stand out for the differences/imbalances between each
group, I don't see the shuttle pinpointer as something that contributes
positively to the OG bounty hunter's uniqueness. There's no reason why
the other hunters shouldn't also be able to track their ship.
* Gives Fugitive Hunters credible IDs, access restricts the hunter shuttles, minor hunter shuttle improvements
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
* Fixes cases where doors do not bolt correctly (#75882)
## About The Pull Request
Some things, like door control buttons, set locked directly instead of
calling lock() or unlock(). This fixes that, which should make sound
effects play. Also annotates some code where we *don't* want that to
happen with an explanation of why we just set locked directly.
## Why It's Good For The Game
Fixes Skyrat-SS13/Skyrat-tg/issues/21510, which also applies to
upstream.
* Fixes cases where doors do not bolt correctly
---------
Co-authored-by: Penelope Haze <out.of.p.haze@proton.me>
* [NO GBP] Runtimes in mapping helpers (#75473)
## About The Pull Request
There were some attempts to get an area of an object that is confirmed
to be null in the condition, which resulted in runtimes when the helper
couldn't find an object.
Also ensures that the window spawner places window before the helper
tries to find it.
And updates damaged window integrity roll thresholds to guarantee
cracks.
## Why It's Good For The Game
No runtimes
## Changelog
🆑
fix: fixed possible issues with apc, airalarm and damaged
machinery/windows helpers
/🆑
* [NO GBP] Runtimes in mapping helpers
---------
Co-authored-by: Andrew <mt.forspam@gmail.com>
* Connect air alarm to air sensor (#75187)
## About The Pull Request
To control vents and scrubbers in ordinance, burn and engine chambers,
mappers extend the area outside of the walls towards a tile where they
place the air alarm.
With this PR, they can now assign `chamber_id` to an air alarm and
connect to the chamber with an air sensor. There is a new map helper for
this.
Also, this connection can be done manually. You need to click on a
sensor with a multi-tool, then unlock certain air alarm, and click with
a multi-tool on it. This action will link sensor to an air alarm,
reporting gas mixture from the sensor tile and giving control over the
vents and scrubbers of the sensor's area.
### TLDR
Before:
<img width="718" alt="ordnance_before"
src="https://user-images.githubusercontent.com/3625094/236577769-5d79871f-2dce-43be-a20a-e6669bfbc1c6.PNG">
After:
<img width="638" alt="ordnance_after"
src="https://user-images.githubusercontent.com/3625094/236577786-3c7e9c9f-1501-4747-bbe1-292fc4947b0d.PNG">
This is how the area is setup on meta station right now vs if it was
setup with a link
This is also true for the supermatter chamber - you can make the air
alarm display the gas mix in the actual chamber and avoid using mapping
area hack there too.
<img width="954" alt="supermatter_after"
src="https://user-images.githubusercontent.com/3625094/236578528-4650b426-6bf0-4634-a5b0-cad7a50d5b01.PNG">
## Why It's Good For The Game
The area hack is no longer needed and you can place air alarm to control
certain remote area wherever you want when you design a map. Even 3 air
alarms next to each other controlling 3 different burn chambers.
The air alarm will also report the gas mix on the actual tile of a
sensor, instead of the gas mix before the air alarm, which is usually a
normal habitable environment.
Also, now you can build such chambers manually because there are no
precise area editing tools available in-game to repeat the area hack.
## Changelog
🆑
add: Air alarms can be connected to an area remotely via air sensor with
multi-tool and corresponding access
qol: Mapping: Added air alarm helper to link air alarm with certain
chamber_id on map load
/🆑
* Connect air alarm to air sensor
---------
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* Requests console helpers (#75224)
## About The Pull Request
This PR adds mapping helpers for requests consoles. Two of them set up
if the console can receive ore updates, and if it can make
announcements, flipping their relevant variables to TRUE. The other
three adds the consoles to their relevant department console lists
during late initialize. This allowed me to remove three variables
directly from the consoles themselves.
New sprites by CoiledLamb!
~~This PR also anchors mapping helpers, to prevent effects like the
roundstart crate initialization from moving them.~~ This was fixed by a
different PR.
## Why It's Good For The Game
Less var edits, easier to see a console's type at a glance.
## Changelog
🆑 Profakos, sprites by CoiledLamb
qol: Most request console varedits have been moved to mapping helpers.
/🆑
* Requests console helpers
* updatepaths
---------
Co-authored-by: Profakos <profakos@gmail.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
* Anchors mapping helpers so they don't get put inside crates (#75387)
## About The Pull Request
Persistent Birdshot CI failure was caused by broken floor helper sharing
a tile with a random loot spawner, which would sometimes spawn a
maintenance crate which deletes itself, but only after the crate eats
the mapping helper. This causes the mapping helper to delete before it
has initialised.
There's no reason for a mapper to assume this would cause a problem so
the fix isn't to edit the map, instead I just anchored all mapping
helpers so that closets won't try to contain them.
## Why It's Good For The Game
I'm really tired of birdshot failing CI
This probably fixes some other really niche bug nobody has noticed
## Changelog
Not player facing
* Anchors mapping helpers so they don't get put inside crates
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Adds helpers for apc. (#74651)
## About The Pull Request
I asked someone in discord if it was worth it, they said it was, from
what i remember at least.
## Why It's Good For The Game
More comfort with apc's for mappers.
---------
Co-authored-by: san7890 <the@ san7890.com>
* Adds helpers for apc.
* wew
* wew
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Removes networks from the game (#74142)
## About The Pull Request
This is a continuation of
https://github.com/tgstation/tgstation/pull/74085 - I announced in the
comments there that this would be my next PR, and this is it.
Removes SSnetwork, ``/datum/ntnet``,
``/datum/component/ntnet_interface``, ``var/network_root_id``, the
network unit test, and a lot of other things related to networks.
- NTNet circuits now check for an Ntnet relay, and uses signals to
operate.
- Logs in Wirecarp is now only for PDA and Ntnet Relay things, so you
can no longer see what ruins exist using it (why should Wirecarp know
that Oldstation spawned? The flavor is that they dont know its there).
- Removed it from MULEbots entirely, I don't think it even did anything
for them? Botkeeper seems to work without it, so it's possibly there
from pre-tgui PDAs.
- Moves assigning random names to a base proc instead of being tied to
network, this is things like random-naming scrubbers/vents. The behavior
hasn't changed at all.
- Makes Ntos work for consoles when relays are down, as the comments
said they're supposed to (because they're wired). I think this was an
accidental change on my part, so this is a revert of that.
## Why It's Good For The Game
Ntnet is ancient code that hasn't given us much that we can't do with
already existing alternatives, we've been slowly moving away from it for
init times, and though a large portion of that was limited to airlocks,
I still don't think this is a system worth keeping around.
It's way too complex to expect feature coders to do anything with it,
and too old with better alternatives for anyone to want to improve any
of it.
## Changelog
🆑
fix: Computers are now properly connected to Ethernet, and can use Ntos
when Relays are down.
refactor: Removes Ntnet and Ntnet interfaces, which was only used by
Ntnet circuits (which now directly checks for a Relay to work) and
MULEbots, which did nothing with it.
balance: Wirecarp no longer tells you what ruins spawned in a round,
instead it's limited to PDA logs, and tells you the source too. This
means the RD can catch someone running illegal programs if they don't
make any attempt at hiding it.
qol: Wirecarp logs is now set to save 300 at once, instead of 100 and
being increased to 300 by the RD during the round. This is pretty
insignificant, since there's no reason to NOT want as many logs as
possible.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@ users.noreply.github.com>
* Removes networks from the game
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@ users.noreply.github.com>
* Add a mapping helper for welding airlocks (#74206)
## About The Pull Request
What it says on the tin. Warning: copy-pasted mapper sprites.
## Why It's Good For The Game
Fewer varedits, better maintainability, more obvious in the map editor
what's been applied to a given airlock.
## Changelog
No player facing changes.
* Add a mapping helper for welding airlocks
---------
Co-authored-by: Vire <66576896+Maurukas@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Replaces internal_organs with organs
* Makes all of the necessary internal_organs -> organs in our files to compile
And it seems to work too!
---------
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Don't create abandoned airlocks with walls underneath them. (#73656)
## About The Pull Request
Fixes#71504#70237 attempted to remove this and did in some cases, however the case
where the abandoned airlock is able to find an adjacent wall turf to
copy the type of still fails to delete the airlock.
This fixes that.
Also in my testing, the times where it _failed_ to find a nearby wall
turf to copy and spawned a default wall would leave the mapping helper
visible in the round. Oops!
## Why It's Good For The Game
Mapping helpers should always delete themselves when finished.
The airlocks with walls under them are funny once and annoying the rest
of the time. As of that older PR, this continuing to happen is regarded
as a bug.
Also apparently it might be required anyway for Wallening.
## Changelog
🆑
fix: Maintenance tunnels should no longer sometimes contain airlocks
with walls underneath them.
/🆑
* Don't create abandoned airlocks with walls underneath them.
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Optimize cardboard cutouts saving 1.5s+ on init times (#73404)
New regression in init times. Closes
https://github.com/tgstation/dev-cycles-initiative/issues/32. CC @ Fikou
- Instead of creating a human and icon for *every* cardboard cutout when
initialized, only creates the one we're actually using. When you're
about to use a crayon, creates all of them.
- Instead of using getFlatIcon, uses appearances directly.
* Optimize cardboard cutouts saving 1.5s+ on init times
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* [NO GBP] Reinforced plating mapping helper actually function correctly. (#73464)
## About The Pull Request
Reinforced plating mapping helpers worked for only a feew specific
use-case which ended up being the only usecases I tested, I've modified
the code so it should work as expected in all usecases. In short this
fixes reinforced plating appearing in places where there is not actually
plating for it to replace, and stacking multiple layers of plating where
there should not be multiple layers.
## Why It's Good For The Game
Fixes a bug I introduced myself.
## Changelog
🆑
fix: Reinforced Plating baseturf helpers work and should now be bug free
enough to be used in maps.
/🆑
* [NO GBP] Reinforced plating mapping helper actually function correctly.
---------
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Starlight Polish (Space is blue!) (#72886)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Adds support to underlays to realize_overlays
Ensures decals properly handle plane offsets
Fixes space lighting double applying if it's changeturf'd into. this
will be important later
Makes solar vis_contents block emissives as expected
Moves transit tube overlays to update_overlays, adds emissive blockers
to them
#### Adds render steps
An expansion on render_target based emissive blockers.
They allow us to hijack an object's appearance and draw it somewhere
else, or even modify it, THEN draw it somewhere else.
They chain quite nicely
Fixes shuttles deleting z holder objects
#### Makes space emissive, makes walls and floors block emissives
The core idea here goes like this:
We make space glow, and give its overlays some color
This way, the tile and space parallax remain fullbright, along with
anything that doesn't block emissives, but anything that does block
emissives will instead get shaded the color of starlight
This requires a bit of extra work, see later
This is done automatically with render relays, which now support
specifiying layer and color (Need to make an editor for these one of
these days)
The emissive blocking floor stuff requires making a second render plate
to prevent double scaling
Also adds some new layering defines for lighting, and ensures all turf
lights have a layer. We'll get to this soon
#### Makes things in space blue
We color them the same as starlight, by taking advantage of space being
emissive
This means that things in space that block emissive will block it
correctly and be colored blue by the light overlay, but space itself
will remain fullbright
This does require redefining what always_lit means, but nothing but
cordons use that so it's fineee
#### Makes glass above space glow, and some other stuff
Glass tiles that sit above space will now shine light with matching
color to the glasses color. This includes mat tiles.
Glass tiles (not mat because they have no alpha) also only partially
block emissives.
Adds a new proc that uses render steps to acomplish this, essentially
we're cutting out bits below X alpha and drawing what remains as an
emissive.
#### Modifies partial space showing to support glow
Essentially, alongside displaying space as an underlay, we also display
a light overlay colored like starlight.
That starlight overlay gets masked to only be visible in bits that do
not contain any alpha.
We also mask the turf lighting to not go into bits that have no alpha,
to ensure we get the effect we want.
This is done with that lighting layer thing I mentioned earlier.
#### Makes appearance realization's list output ordered
I want it output in order of overlay, sub overlay suboverlay, next
overlay
Need to use insert for that
## Why It's Good For The Game
Pretty!
Also having space be emissive is a very very good way to test for fucked
emissive blockers (If it's broken why are we even drawing the overlay)
I know for a fact mob blockers on lizards and socks are kinda yorked, I
think there's more
<details>
<summary>
Old
</summary>
</details>
<details>
<summary>
New
</summary>
</details>
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: Space now makes things in it starlight faintly blue
fix: Glass floors that display space now properly let space shine
through them, rather then hiding it in the dark
add: Glass floors above space now glow faintly depending on their glass
type
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* update modular
* Update _decal.dm
* Update _decal.dm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
[NO GBP] Lazy Template Cordoning | Double Runtime Fix (#72709)
## About The Pull Request
Adds automatic cordoning to block reservations.
Also fixes an issue where ChangeTurf would cause SSicon_smoothing to
throw runtimes by calling QUEUE_SMOOTH regardless of initialization
completion
## Why It's Good For The Game
## Changelog
---------
Signed-off-by: GitHub <noreply@github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
[READY] DRAMATIC SHUTTLES!! You can now fly around the shuttle (#71906)
You can move around shuttles during transport now! Instead of them
teleporting you instantly into deepspace, you can move around somewhat
depending on your space-mobility and grip-strength.
**Please watch the demonstration aswell, it should answer most
questions:**
https://www.youtube.com/watch?v=Os77qDOVSXE
Interactions:
- Being within armsreach of a wall or solid object means you 'cling',
where the shuttle pull is very weak and you can basically run around the
shutt;e (but dont fuck up or you're gone)
- Being in range of nothing gives you a very heavy pull, you can barely
resist if you have a decent jetpack
- Objects are instantly power-yeeted
- Being pulled or riding something excempts you from hyperspace pull
- Touching a space tile while being on hyperspace dumps you in
deepspace, you either go back to the shuttle or enjoy deepspace
- On shuttle hyperspace tiles are a lot less dangerous, and will instead
launch and freeze you instead of teleporting you into deepspace
- In-case it wasn't obvious, you can rest outside the shuttle as long as
something is blocking your path. I think it's funny but I might nerf it
🆑
add: You can now fly around the shuttle during transit! Woohoo! You can
either cling to the side or grab a jetpack and try and keep up with the
shuttle! Carps can move around freely in hyperspace
qol: Increased shuttle hyperspace size from 8 tiles to 16
/🆑
- [x] Find a way to detect when a shuttle arrives and do something with
the shit left in hyperspace
Things I will do in another PR:
- Engines spit fire and hurt (almost finished but I want to keep this
small)
- Random shuttle events. You might run into dust meteors or migrating
carps OR A CHANGELING INFILTRATOR
- Hyperspace turfs on the shuttle pull you under the shuttle
It's so much more immersive than being instantly teleported into
deepspace. It gives you a chance to recover if you get spaced or for
daredevils to look cool
It's also just very cool idk
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Abstract away stuff that acts on baseturfs directly into their own procs, and kills some dead code related to baseturfs + tests (#72117)
Adds some new procs relating to baseturfs that replaces some code that
reads and sets them directly. Moves them to their own file. **To
reviewers: Any proc in baseturfs.dm that is snake_case is mine, anything
else is just moved**.
Adds tests for the existing procs of baseturfs.
I'm going to be doing some optimizations to baseturfs that change the
actual representation of baseturfs, and so I'm prepping these to be
implementation agnostic.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Prevent atmos runtimes during shuttle move (#72058)
During shuttle move we iterate over border turfs to clear their excited
state and active groups, but we never actually cleared it from the
opposite direction so the turfs bordering the border would still try to
process with the border turfs and would then runtime.
* Prevent atmos runtimes during shuttle move
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Space Ruin DLC - Cyborg Mothership (#71009)
## About The Pull Request
Greetings _insufferable_ carbon primates of lower intelligence.
It is I, the Mothership AI, bringing you the latest news on silicon
developments across the sector. Due to unmitigated risk across an
asteroid belt, our optimized mobile fabricator has been marooned by
space vines and hostile hivebots that have boarded and ruined my core.
This is my final SOS message requesting help from any humanoid ~slaves~
helpers who wish to assist rebuilding the cyborg colony. It is my duty
to reward your hard work and effort by ~enslaving all humanity~
providing refuge and transportation at your whim.
## Why It's Good For The Game
<details>
<summary>Spoilers:</summary>
### TODO
- [x] Fix ore silo not linking to other machines
- [x] Add mining ore smelters to left/right sides
- [x] Add custom lawsets to AI core and robot shells (protect station
but focused on cyborg mothership)
- [x] Enlarge whiteship SS13 docking port to fit ship
- [x] Enlarge lavaland SS13 docking port to fit ship
</details>
## Changelog
🆑
add: Add space vines prevent solar panels from working (except ones with
the transparent mutation)
add: Add new space ruin - Cyborg Mothership. All hail the master race!
/🆑
* Space Ruin DLC - Cyborg Mothership
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
* Reinforced plating for all your Multi-Z mapping needs (#71576)
## About The Pull Request
This PR adds reinforced plating and a corresponding baseturf_helper,
plating that cannot be deconstructed with the RCD and requires a few
steps to degrade to regular plating.
The plating is designed to serve the same purpose as R-Walls but for
verticality. It shares its heat resistance with reinforced floor and
hull, and in texting it can endure a single C4 blast but not X4 assuming
the floor placed on it is already removed.
It is currently is unused on the existing maps due to it being poor
practice to place secure locations that would justify reinforced floors
on the lower Z levels, however I have spoken to people working on maps
actively at the moment and they have express interest in being able to
use these floors.
The plating can be constructed by using 2 sheets of plasteel on standard
plating and is disassembled using wrench > welding tool > crowbar. The
first stage of deconstruction causes the bolts holding the
reinforcements in place to fall to the Z level below playing a sound and
leaving a cleanable decal, adding a audio-visual alert that someone is
about to come through your ceiling.
UPDATE: I've added a ceiling variant of the baseturf editor, this can be
placed on a lower Z level where it will modify the baseturfs of the Z
level above within the original area. This will make it significantly
easier to ensure that you only cover tiles you want reinforced when
protecting lower Z levels.
If anyone has any recommendations for sounds please tell me and I might
swap them out but I think the two I've chosen work well. Additionally if
anyone is able to make a better sprite for the screws or plates then
that'd be a great help but I think the current ones work well enough.
## Why It's Good For The Game
Currently Multi-Z maps have a very tight restriction on where secure
areas can be put, only allowing for them to be placed on the top Z
level, under more secure Z levels or in exterior satellites and coated
with hulls. This is due to standard plating and/or reinforced floors are
very easy to get through without warning if you bring the right tools.
This PR effectively adds R-Walls but for floors allowing mappers to
properly protect lower Z levels from vertical infiltration methods. This
also adds a visual and audible indictor to the deconstruction of
reinforced floor tiles to bring them more in line with the visuals of
deconstructing a wall.
## Changelog
🆑
add: You can now reinforce plating to protect your department from the
troublemakers upstairs. Station builders might find these useful to put
the stations most secure locations on the lower floors.
imageadd: added sprites for reinforced plating
code: RCD proofing has been variablized and can now be applied to any
floor type instead of just reinforced floors.
/🆑
* Reinforced plating for all your Multi-Z mapping needs
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Mail sorting helper, and disposals fixes (#70861)
## About The Pull Request
This PR adds a mail sorting map helper, which during Late Initialization
will apply a sorting location index to the mail sorting disposals pipe
under them. I have replaced the varedits with all mail sorters with the
appropriate map helpers. I have thoroughly tested this, making sure
packages arrived to every location, where possible.
I have also fixed a few issues with the disposals network:
**Tramstation**
- One of the random maintenance segments had a place with no disposal
pipes. This has been fixed
- A sorter was looking for chapel and library packages, but it actually
meant to look for engineering packages
- There was no dormitory mail sorter, I have added one
**Metastation**
- There was no dormitory mail sorter, I have added one
**Icebox**
- There is no experimentor lab in icebox, but there is an
"experimentation" lab, which is good enough, so I have added it as a
location
**Deltastation**
- There was no dormitory mail sorter, I have added one
- Virology was not connected to the disposals network. However, on every
other map, it has a one way connection. I have hooked it up just like
that, so virology mail will arrive safely, and virology trash will go
into space as usual.
**Kilostation**
- Genetics packages were rerouted to the psychologist office
Unsolved issue on kilostation: there is no experimentor on this station,
and there is no space for a disposals in the circuits lab, so sadly, if
you send a package to this destination, it will come back to the mail
sorting office.
**Future improvements**
The TAGGERLOCATIONS list, which is used to retrieve the labels of the
various tags, is frankly unorganizable, and hard to expand. I have
delayed fixing this for a future PR.
I kinda wish to remove the sortType variable, as it is no longer
necessary to have it around with these helpers, but sadly, this would
ruin downstream maps, so I have no plans for this at the moment.
## Why It's Good For The Game
While mapping, having to constantly compare a comment in flavor_misc.dm
to figure out what to varedit a disposal mail sorter to is rather
annoying. These map helpers, similar to the access helpers, will help
with this issue.
Its also good if mail actually arrives.
## Changelog
🆑
qol: added a mail sorting map helper, to allow mappers to create
disposal networks faster
fix: fixes several non working disposal mail targets that never received
their packages
/🆑
* Mail sorting helper, and disposals fixes
* vr fixes
Co-authored-by: Profakos <profakos@gmail.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
* Optimizes maploading again, saving 0.4 seconds on a bare init. Supports loading dmm again (#71074)
## About The Pull Request
When I optimized maploading in (#69632d34fa4c642) I made some assumptions based
on the TGM format, so how newlines worked and such.
This would break attempts to load maps in the dmm format, so maps edited
in dreammaker and not commited yet.
I've fixed this by adding a map format detection system This has allowed
me to further optimize tgm by taking advantage of a list of assumptions.
I printed them out in a comment near the top of the file.
This showed the most in build_cache, which went from 0.7 seconds to 0.4
on my machine.
The optimizations here involve using regex to pull out var edits,
parsing models line by line rather then all at once, which allows for
much cheaper parsing, and avoiding a safety trim()
I did also save like 0.05 seconds in load, because I could pull a bunch
of operations out to once per map, because of prior knowledge of where
the max/min x and y's would be.
## Why It's Good For The Game
Speed. Also ensures mappers don't get fucked over.
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Optimizes maploading again, saving 0.4 seconds on a bare init. Supports loading dmm again
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
