## About The Pull Request
When a camera update is triggered, it is instead added to a queue on a
background subsystem
An AI entering a camera chunk which is queued to update will force the
update immediately (bypassing the queue)
While the root problem of this is, ultimately, not addressed...
<img width="554" height="58"
alt="467828777-eff3f0e5-49d6-4997-b4d7-05eff6432155"
src="https://github.com/user-attachments/assets/c2d6a5f5-d958-463e-959f-116bd0dab475"
/>
...the change will ultimately prevent update spam from consuming all of
the server's resources - instead allocating updates to the backburner in
times of high server stress (or on multi-z maps)
## Changelog
🆑 Melbert
refactor: Refactored the way camera updates are handled to hopefully
reduce some lag. Report any oddities
/🆑
## About The Pull Request
[cleans up poor namespacing on light debugging
tools](https://github.com/tgstation/tgstation/commit/93cc9070d56ee4dbeb600ebd4616b047adf9d648)
[Implements a pathfinding visualization
tool](https://github.com/tgstation/tgstation/commit/ed91f69ac42a92329c10ccdbba308d213fc8c759)
It holds a set of inputs from the client, and uses them to generate and
display paths from source/target. Left click sets the source, right
click sets the target.
Pathmap support too, if no target is set we display the paths from every
turf in the map to the source, if one is set we build a path TO it from
the source.
I had to add COMSIG_MOB_CLICKON to observers to make this work (tho idk
why it didn't exist already), I also removed the everpresent colorblind
datum from admin datums, only needs to exist if they're using it.
[Adds a mutable_appearance helper that dirlocks them, wallening port
which I thought might be useful here, and will likely be useful
elsewhere in
future](https://github.com/tgstation/tgstation/commit/87f752e7c361ff47d62452f2f1ea805458f71b66)
[Fixes an infinite loop in pathmaps if we tried to pull a cached path to
an unreachable target, && not ||
4head](https://github.com/tgstation/tgstation/commit/10086a655df817c9f4494f9aac879c85a6059719)
[Fixes JPS not dealing with border objects properly. They violate some
of the assumptions JPS makes, so we need to backfill them with checks.
These basically read as (if the thing that should normally take this
path can't reach this turf, can
we?)](https://github.com/tgstation/tgstation/commit/f56cc4dd434cecee89879aea500bd1c9d2f38ce6)
## Why It's Good For The Game
Maybe deals with #80619?
Adds more robust testing tools for pathfinding, should allow people to
better understand/debug these systems. I added this with the idea of
adding multiz support but I don't have the time for that rn.
JPS will work around thindows better, that's nice.
https://file.house/IrBiR0bGxoKw1jJJoxgMRQ==.mp4
## Changelog
🆑
fix: Fixed our pathfinding logic getting deeply confused by border
objects
admin: Added clientside displayed pathfinding debug tools, give em a go
/🆑
Ports the helpers from
https://github.com/BeeStation/BeeStation-Hornet/pull/12240
This should fix some more of the 516 issues that I've seen while giving
a quick check through the code
The remaining browse should work now.
Also fixing another sass warning while being on it.
## About The Pull Request
## Why It's Good For The Game
## Changelog
🆑
fix: tgui say 516 will no longer change channels when the button is used
to drag it
fix: tgui say 516 will no longer leak radio messages into the wrong
channel
fix: runechat flickering when faded up messages fade out
/🆑
Ports the helpers from
https://github.com/BeeStation/BeeStation-Hornet/pull/12240
This should fix some more of the 516 issues that I've seen while giving
a quick check through the code
The remaining browse should work now.
Also fixing another sass warning while being on it.
## About The Pull Request
## Why It's Good For The Game
## Changelog
🆑
fix: tgui say 516 will no longer change channels when the button is used
to drag it
fix: tgui say 516 will no longer leak radio messages into the wrong
channel
fix: runechat flickering when faded up messages fade out
/🆑
## About The Pull Request
Was just scrolling through the Paradise github since they seem to have
more work done for 516 to see if there's anything I can port over, found
this and thought why not.
Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105
Specifically, updaing all hrefs to use the internal ``byond://``, and
adding it to grep.
## Why It's Good For The Game
More work towards 516.
## Changelog
Nothing player-facing.
3591 individual conflicts
Update build.js
Update install_node.sh
Update byond.js
oh my fucking god
hat
slow
huh
holy shit
we all fall down
2 more I missed
2900 individual conflicts
2700 Individual conflicts
replaces yarn file with tg version, bumping us down to 2200-ish
Down to 2000 individual conflicts
140 down
mmm
aaaaaaaaaaaaaaaaaaa
not yt
575
soon
900 individual conflicts
600 individual conflicts, 121 file conflicts
im not okay
160 across 19 files
29 in 4 files
0 conflicts, compiletime fix time
some minor incap stuff
missed ticks
weird dupe definition stuff
missed ticks 2
incap fixes
undefs and pie fix
Radio update and some extra minor stuff
returns a single override
no more dupe definitions, 175 compiletime errors
Unticked file fix
sound and emote stuff
honk and more radio stuff
## About The Pull Request
Fixes several errors to spelling, grammar, and punctuation.
## Why It's Good For The Game
## Changelog
🆑
spellcheck: fixed a few typos
/🆑
## About The Pull Request
Basically, adds a version of `randomize_human` that's a tad more
curated, IE, primarily picks results to create a more "coherent" result
than full randomization.
Shown here: Humans, Lizards, Felinids. Looks a bit boring, but that's
the point.
Non-humans I left almost entirely untouched, as they generally form a
more "coherent" mob from pure randomization already.
## Why It's Good For The Game
Basically just aiming to perform a more "consistent" style for humonkeys
and corpses.
For monkeys, it doesn't make the most sense when they pop up with a
giant red afro.
For corpses, it's a bit hard to feel immersed in the ruins when they've
all got pink and green mustaches.
## Changelog
🆑 Melbert
add: Humonkeys and random corpse spawns now look more... human.
/🆑
* Adds Character Loadout Tab to preferences (with just a small handful of items to start)
* step one rip out all the old nasties
* fixes, current bugs: donator lock, ckey lock, one item in case
* opps
* sanity checks, fixed, donator implementation, ckey locking. fixes.
* wew
* final fixes
* Update loadout_categories.dm
* Update loadout_items.dm
* Update loadout_items.dm
* Update declarations.dm
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
Co-authored-by: SpaceLoveSs13 <68121607+SpaceLoveSs13@users.noreply.github.com>
* Admin Verb Datums MkIII | Now with functional command bar (#82511)
* Modular stuffs
* Put some admin jump verbs back into the context menu | sorts area jump list again (#82647)
## About The Pull Request
See title.
## Why It's Good For The Game
Some admins wanted all the jump verbs back, aswell as making them not
AGhost you.
Also make the Jump To Area verb use a sorted list again
* Hey what if admins were allowed to use the player panel (#82682)
Re-adds the player panel verb to the verb panel.
* Controller Overview UI (#82739)
* Fixes a minor spelling mistake on the admin panel/verb list (#82747)
## About The Pull Request
Corrects `inisimin` to `invisimin`. This addresses #82728, but only
fixes one of the two issues mentioned
## Why It's Good For The Game
-1 spelling mistake
## Changelog
🆑
spellcheck: 'inisimin' verb corrected to 'invisimin'
/🆑
* Player Panel-age (#82757)
* Admin Forced Mob Rename and Preference Update (#82715)
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com>
Co-authored-by: chel <64568243+iliyaxox@users.noreply.github.com>
* Removes some code soul (`IF YOU ARE COPY PASTING THIS...`), replaces it with a macro (#79935)
## About The Pull Request
Replaces all instances of `SSblackbox.record_feedback\("tally",
"admin_verb", 1, (.+)\)` with `BLACKBOX_LOG_ADMIN_VERB($1)`
This makes so the funny comment isn't necessary.
It also reveals one location which someone did not heed the comment, the
`debug_controller` proc copy+pasted the line but did not change the
fourth argument. PEOPLE DON'T READ!
* Removes some code soul (`IF YOU ARE COPY PASTING THIS...`), replaces it with a macro
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Replaces all instances of `SSblackbox.record_feedback\("tally",
"admin_verb", 1, (.+)\)` with `BLACKBOX_LOG_ADMIN_VERB($1)`
This makes so the funny comment isn't necessary.
It also reveals one location which someone did not heed the comment, the
`debug_controller` proc copy+pasted the line but did not change the
fourth argument. PEOPLE DON'T READ!
* count station food verb counts station food (#78864)
## About The Pull Request
it checked for food not on the station
## Why It's Good For The Game
bug bad
## Changelog
🆑
fix: count station food verb now counts food only onstation
/🆑
* count station food verb counts station food
---------
Co-authored-by: jimmyl <70376633+mc-oofert@users.noreply.github.com>
## About The Pull Request
it checked for food not on the station
## Why It's Good For The Game
bug bad
## Changelog
🆑
fix: count station food verb now counts food only onstation
/🆑
* Loads Away Missions for Unit Testing (#76245)
Hey there,
A pretty bad bug (#76226) got through, but it was fixed pretty quickly
in #76241 (cf92862daf). I realized that if
we were testing all the away missions, that this could theoretically get
caught and not happen again. Regardless, unit testing gateway missions
has been on my to-do list for a while now, and I finally got it nailed
down.
Basically, we just have a really small "station" map with the bare bones
(_teeny_ bit of fluff, maploading is going to take 30 seconds tops
anyways let me have my kicks) with a JSON map datum flag that causes it
to load all away missions in the codebase (which are all in one folder).
Just in case some admins were planning on invoking the proc on
`SSmapping`, I also decided to gate a `tgui_alert()` behind it because
you never can be too sure of what people think is funny these days (it
really does lock up your game for a second or so at a time).
I also alphabetized the maps.txt config because that was annoying me.
Things that break on production could(?) be caught in unit testing? I
don't know if the linked issue I mentioned above would have been caught
in retrospect, but it's likely to catch more than a few upcoming bugs
(like the UO45 atmospherics thing at the very top) and ensure that these
gateway missions, which tend to be the most neglected part of mapping,
stay bug-free.
This is also helpful in case someone makes a new away mission and wants
to see if stuff's broken. Helps out maptainers a bit because very, very
technically broken mapping will throw up runtimes. Neato.
Nothing that players should be concerned about.
Let me know if there's a better way to approach this, but I really think
that having a super-duper light map with the bare basics to load up
gateway missions and then all nine-ish gateway missions can sequentially
load during init. I can't think of a better way to do it aside from some
really ugly `#ifdef` shit. Also also, it has the added benefit of being
a map that will always load your away mission without touching a single
shred of config (and it's not likely to break if you follow sane
practices such as making your own areas)
* Update gateway_test.json
* Map Reset
* Gets rid of an area that was in a space turf
* Attempting to fix some runtimes
* Map Reset
* Lets remains spawn in xen water
* and acid, too
* Update remains.dm
* Removes extra airlock helper
* Delete research2.dmm
Surely this was a mistake?
* Merge branch 'master' into pr/22534
* Map Reset
* Update snowdin.dmm
* Revert "Update snowdin.dmm"
This reverts commit c860c6f4fbb463954d5b8da1b494305a2f45b44b.
* Update snowdin.dmm
* Update snowdin.dmm
* Revert "Update snowdin.dmm"
This reverts commit 47e7916056a47e12adfcb8b94b9748b7e56f378d.
* Update snowdin.dmm
* Revert "Update snowdin.dmm"
This reverts commit c82576bee69e09eda649d3cbf63d96dddaeeb380.
* Update immerse.dm
* Revert "Update immerse.dm"
This reverts commit 2ad622f3029a3ed17a05f8269299d0f25e747d11.
* Update immerse.dm
* Update maps.txt
* Fix hard dels in area spawn
* Update gateway_test.json
* Actually we can just get away with keeping a list of types here, no refs needed.
* Update area_spawn_subsystem.dm
* Update automapper.dm
* Let's just test to see if getting rid of black mesa stops the segfaults...
* Let's try deleting astrum too
* Revert "Let's just test to see if getting rid of black mesa stops the segfaults..."
This reverts commit de9a05708d451abbb78a635a3e03b2f460004496.
* Revert "Let's try deleting astrum too"
This reverts commit 2121a6357a54faf5719a42a762ba8b4698c008fb.
* Update waypointstation.dmm
* Update blackmesa.dmm
* Update decaySS.dm
* Update gateway_test.json
* Revert "Update gateway_test.json"
This reverts commit 93adc08819f05aecc8599980385e3fb10d02a1d2.
* Testing
* Revert "Testing"
This reverts commit 1d476d236953daac6adf59b93e56f2fab218085b.
* Testing
* Revert "Testing"
This reverts commit de05a74636c1f43e50fb7ec9f24978d270db4b88.
* Now try and actually fix the stupid thing
* Update clockwork_research.dm
---------
Co-authored-by: san7890 <the@san7890.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>
## 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
* [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>
## 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>
## About The Pull Request
Hey there,
A pretty bad bug (#76226) got through, but it was fixed pretty quickly
in #76241 (cf92862daf). I realized that if
we were testing all the away missions, that this could theoretically get
caught and not happen again. Regardless, unit testing gateway missions
has been on my to-do list for a while now, and I finally got it nailed
down.
Basically, we just have a really small "station" map with the bare bones
(_teeny_ bit of fluff, maploading is going to take 30 seconds tops
anyways let me have my kicks) with a JSON map datum flag that causes it
to load all away missions in the codebase (which are all in one folder).
Just in case some admins were planning on invoking the proc on
`SSmapping`, I also decided to gate a `tgui_alert()` behind it because
you never can be too sure of what people think is funny these days (it
really does lock up your game for a second or so at a time).
I also alphabetized the maps.txt config because that was annoying me.
## Why It's Good For The Game
Things that break on production could(?) be caught in unit testing? I
don't know if the linked issue I mentioned above would have been caught
in retrospect, but it's likely to catch more than a few upcoming bugs
(like the UO45 atmospherics thing at the very top) and ensure that these
gateway missions, which tend to be the most neglected part of mapping,
stay bug-free.
This is also helpful in case someone makes a new away mission and wants
to see if stuff's broken. Helps out maptainers a bit because very, very
technically broken mapping will throw up runtimes. Neato.
## Changelog
Nothing that players should be concerned about.
Let me know if there's a better way to approach this, but I really think
that having a super-duper light map with the bare basics to load up
gateway missions and then all nine-ish gateway missions can sequentially
load during init. I can't think of a better way to do it aside from some
really ugly `#ifdef` shit. Also also, it has the added benefit of being
a map that will always load your away mission without touching a single
shred of config (and it's not likely to break if you follow sane
practices such as making your own areas)
* Corrects record_feedback()'s copy/paste comment (#74962)
## About The Pull Request
Corrects `record_feedback()`'s copy/paste comment.
## Pointless history
Originally being added in e2a8a5e, it kept its name and args for quite a
few years, that was until #32188 which had it renamed to
`record_feedback` and its args pretty much doubled. In between these
times the known copy/paste comment was already around, but that wasn't
updated, until now apparently.
* Corrects record_feedback()'s copy/paste comment
---------
Co-authored-by: Zandario <zandarioh@gmail.com>
## About The Pull Request
Corrects `record_feedback()`'s copy/paste comment.
## Pointless history
Originally being added in e2a8a5e, it kept its name and args for quite a
few years, that was until #32188 which had it renamed to
`record_feedback` and its args pretty much doubled. In between these
times the known copy/paste comment was already around, but that wasn't
updated, until now apparently.
## About The Pull Request
Damn that's a long title.
Admin Verbs can be used in the verb bar with hyphens instead of spaces
again.
## Why It's Good For The Game
Admin muscle memory
## Changelog
* Atmospheric machineries now interact with each other directly, rather than going through a radio layer -- saves about 0.4s of init time
* updatescript maps
* Merge conflicts
* Tarkon atmos
* tick file
* that file was supposed to be removed
* tarkon cringe
* tarkon tweaks after testing
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
More than a decade ago, these were all coded to use a weird dynamic list
radio broadcasting system to communicate with each other. If there was
any depth that they were planning on creating with this, it didn't come
to fruition, and it instead just wasted a lot of init time.
Removing `post_signal` saves 198.41ms, fired 588 times from lots of
different machinery. Its self cost was 81.44ms.
`broadcast_status`, also removed, was taking 218ms.
I'm pretty sure I'm done with this, but it's hard to tell given the
nature of old radio signal code.
A small self cost of 34.9ms was added in the form of /obj/Initialize
checking id_tag to set in a global list. This could be optimized away by
tagging everything that does use id_tag, but it's a loooot and I think
this is just a useful mechanism to have. Not worth it IMO.
The "Check Atmos Chamber Devices" verb has been removed. Everything it
did *should* be replicated by runtimes on Initialize, which is both more
obvious to mappers and shows up in unit tests since we spawn every ruin.
* Strays away from GLOB.machines when possible (#71100)
## About The Pull Request
This replaces needless GLOB.machines with more precise lists whenever
one existed, plus adding a new one for CTF machines.
## Why It's Good For The Game
GLOB.machines holds every single /obj/machinery in the game, so checking
the whole list for stuff is pretty big. This aims to cut that down by
using smaller lists whenever possible. I also gave CTF a new list
because it checked machines very often.
## Changelog
Nothing player facing.
* Strays away from GLOB.machines when possible
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
## About The Pull Request
This replaces needless GLOB.machines with more precise lists whenever
one existed, plus adding a new one for CTF machines.
## Why It's Good For The Game
GLOB.machines holds every single /obj/machinery in the game, so checking
the whole list for stuff is pretty big. This aims to cut that down by
using smaller lists whenever possible. I also gave CTF a new list
because it checked machines very often.
## Changelog
Nothing player facing.
* Removes overlay queuing, saves 6/7 seconds of initialize. Lightly modifies stat tracking macros
So we have this overlay queuing system right? It's build with the assumption
that the "add to overlay list" operation is real expensive, and is
thus useful to queue removals or additions.
It turns out that it just isn't, at least during init. In my testing the
operation of queuing took LONGER then the actual overlay add/remove did.
That's ignoring the cost of the subsystem's work.
I've also modified part of the stat tracking macro, since it took a good
bit of cpu time, and didn't seem to well, do anything. So far as I can
tell it always evaluates to 1
* Examine Blocks Out The Debug Z-Levels Verb (#69845)
Hey there,
It's mostly on the tin. It really looked kinda ugly spitting out the information + the drawing right into chat, so let's wrap it in a nice examine_block to keep it looking good. I added some line breaks because I thought it also aided the formatting.
* Examine Blocks Out The Debug Z-Levels Verb
Co-authored-by: san7890 <the@san7890.com>
Hey there,
It's mostly on the tin. It really looked kinda ugly spitting out the information + the drawing right into chat, so let's wrap it in a nice examine_block to keep it looking good. I added some line breaks because I thought it also aided the formatting.
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
* Obstructed Vents and Scrubbers? - Debug Them Out! (#68890)
* Obstructed Vents and Scrubbers? - Debug Them Out!
Hello there,
In _May of 2014_, Ikarrus wrote the following (here)[https://tgstation13.org/phpBB/viewtopic.php?f=11&t=327]:
"Avoid placing scrubbers and air vents under objects. It's better to leave them in the open and visible so people can use them."
How far we have fallen. However, during a review I did in the last week, I accidentally let one of these (in multiple occurrences!) slip past me:
I don't want that to happen again. It's especially hard when they're under tables, or big bulky lockers, and under computers sometimes! They're not obvious to the human eye, so we must rely on technology. This creates a new Debug Mapping Verb that will flag out any vent, scrubber, or canister port that is being obstructed by an invalid object (directionals and undertiles are excluded). It will be a gargantuan effort unlike anything you've seen to get rid of all of them, but at least this is the first stone in a grand arch.
* Updates some variable names, adds some more logging
* Update code/modules/admin/verbs/mapping.dm
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Update code/modules/admin/verbs/mapping.dm
* no more single letter var
* early continue
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Obstructed Vents and Scrubbers? - Debug Them Out!
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Obstructed Vents and Scrubbers? - Debug Them Out!
Hello there,
In _May of 2014_, Ikarrus wrote the following (here)[https://tgstation13.org/phpBB/viewtopic.php?f=11&t=327]:
"Avoid placing scrubbers and air vents under objects. It's better to leave them in the open and visible so people can use them."
How far we have fallen. However, during a review I did in the last week, I accidentally let one of these (in multiple occurrences!) slip past me:
I don't want that to happen again. It's especially hard when they're under tables, or big bulky lockers, and under computers sometimes! They're not obvious to the human eye, so we must rely on technology. This creates a new Debug Mapping Verb that will flag out any vent, scrubber, or canister port that is being obstructed by an invalid object (directionals and undertiles are excluded). It will be a gargantuan effort unlike anything you've seen to get rid of all of them, but at least this is the first stone in a grand arch.
* Updates some variable names, adds some more logging
* Update code/modules/admin/verbs/mapping.dm
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Update code/modules/admin/verbs/mapping.dm
* no more single letter var
* early continue
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Adds addition test areas verb that filters maintenance areas out (#68484)
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Adds addition test areas verb that filters maintenance areas out
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Adds Puzzgrid smite to trap enemy gamers in a fiendishly hard puzzle (#66855)
* Puzzgrids
* Adds Puzzgrid smite to trap enemy gamers in a fiendishly hard puzzle
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
nevimer
