## 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
Removes all of the duplicate global lists for specific machine types
where the only thing they do is store all machines of that type.
Adds machine tracking to SSmachines in the form of a list for all
machines, and then an associative list for machines by their type.
Previously we have machines in multiple global lists, such as airlocks
being in GLOB.doors, GLOB.airlocks, GLOB.machines.
This makes that not a thing, and also means that iterating through
GLOB.machines looking for a specific type is no longer as expensive.
## About The Pull Request
https://github.com/tgstation/tgstation/assets/7501474/a2d83ce8-eba1-42d9-a1f8-9d73f7c40b21
Adds shuttle events! Stuff can now start to happen outside the shuttle,
either benign or spicy (but usually just fun to watch)!
## Why It's Good For The Game
The shuttle escape sequence is an important part of the game, uniting
about every player surviving player. Recently, #71906 has made the
escape sequence more forgiving as well as more interesting by
conditionally doubling the playing field. The area outside the shuttle
is still mostly empty though, except for the few people being spaced,
daredevils and the occasional epic space fight.
This PR adds adds some space events to spice up the outside of the
shuttle! This both gives people something too look at, making the escape
sequence feel less static and more lively, as well as give people a
reason to go outside and get the full experience of ~being decapitated
by a meteor~ swimming with the fishes!
<details>
<summary>Shuttle Events</summary>
**Friendly carp swarm**
Spawns a group of carp that flies past the shuttle, completely friendly
unless provoked.
**Friendly meteors**
Spawns a lot of strong meteors, but they all miss the shuttle.
Completely safe as long as you don't go EVA
**Maintenance debris**
Picks random stuff from the maintenance spawn pool and throws it at the
shuttle. Completely benign, unless you get hit in the head by a toolbox.
Could get you some cool stuff though!
**Dust storm**
Spawns a bunch of dust meteors. Has a rare chance to hit the shuttle,
doing minimal damage but can damage windows and might need inflight
maintenance
**Alien queen**
One in every 250 escapes. Spawns a player controlled alien queen and a
ripley mech. RIP AND TEAR!! Really not that dangerous when you realize
the entire crew is on the shuttle and the queen is fat as fuck, but can
still be fun to throw people around a bit before being torn to shreds.
**ANGRY CARP**
Once in every 500 escapes. Spawns 12 normal carp and 3 big carps, who
may just decide to go through the shuttle or try and bust through the
window if you look at them wrong. Somewhat dangerous, you could stay
away from the windows and try to hide, or more likely shoot at them and
weld the windows
**Fake TTV**
Lol
**Italian Storm**
Once in every 2000 rounds. Throws pasta, pizza and meatballs at the
shuttle. Definitely not me going off the rails with a testing event
**Player controlled carp trio**
Once in every 100 escapes. Spawns three player controlled carp to harass
the shuttle. May rarely be a magicarp, megacarp or chaos carp. I can't
honestly see them do anything other than be annoying for 3 seconds and
die
There are some other admin only ones: a group of passive carps going
directly through the shuttle and just being little shits, and a magic
carp swarm
</details>
Events are selected seperately, there isn't a crazy weighting system,
each just has a chance to run, and multiple could run at once. They also
don't immediately trigger, so people can get settled a bit, and to make
sure just waiting out the more dangerous ones is still a valid strategy.
## Changelog
🆑
add: Adds shuttle events! If shuttle escapes weren't exciting before
(doubtful), they definitely are now! I'm joking it's mostly an
atmosphere thing.
admin: Adds an admin panel to interact with shuttle events, under the
Events tab: Change Shuttle Events
fix: Objects spawned in hyperspace will properly catch hyperspace drift
/🆑
There's a few things I'd like to do later (another PR) (honestly anyone
can do them because I suck at follow-ups), because this is too big as
is:
- Hijack triggered shuttle events
- More events (got a lot of cool suggestions, but I'm putting most of
them on hold)
- Maybe stration announcements if some more dangerous ones get added
- Structures appearing next to the escape shuttle???
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
We've got a few space related things that are busted, and shuttle
movement is slow.
I'd like to try to improve these things, if just a bit.
Long list of only tenuously related topics. Sorry for the shotgun blast
#### [Fixes lazyloaded stuff having bad
space](d4de176a63)
We need to handle area transferring in maploading code under niche
cases, and we also need to actually init reservation spaces we create.
It's also redundant and potentially dupe creating to do area lighting
handling in changeturf, because it gets touched in turf init anyway. Old
me is stupid.
#### [Adds some doc comments, yeets
ssmappping/transit](269717145d)
We had a reserved space for just shuttles to use, except it wasn't for
just shuttles.
So in theory if the space got clogged with other shit, the shuttles
could have nowhere to actually use.
It's better to just have the two groups share real estate. More sane
### The "Starlight is Slow" Block
#### [Starlight optimization part one (don't check config for each
individual turf you check for
activity)](7312a314be)
#### [Starlight optimization part two (infer
context)](be94c422ed)
Starlight was causing each space turf to cause itself and its neighbor
to constantly recheck if they had starlight off changeturf.
The exact same effect can be had by taking advantage of some
pre-existing information, namely if the space turf is gaining or losing
a source of starlight.
Essentially, instead of telling a turf to check all adjacent turfs to
see if it's got starlight, we tell the turf if WE are a source of
starlight, or if we might be taking something away from it.
There's a bit of wasted cpu here but not much, if it's worth doing a
register signal pattern for clearing depends on the case we're working
with.
Being intelligent about this makes things much faster, something in the
neighborhood of 4 to 3 fold.
I've also made openspace's starlight work better, cause the old pattern
was a bit silly.
### Changeturf is Annoying (Microops)
#### [Micro ops changeturf and turf deletion a
bit](386b3ab7fc)
Don't do work if the thing you're working on doesn't exist, don't check
every adjacent turf for firelocks on turf change (just have thefirelocks
manage that), don't check all atoms on the turf for decals on turf
change, similar.
Also moves visibility changes from camera code into changeturf, to avoid
unneeded work.
Needs some extra work to optimize the guts for this path but I can do
that!
#### [Micros camera vis
changes](ebab69e9ea)
We should only update vis when our opacity changes.
In addition, we don't need all the camera handling fluff if we only want
to update our turf's static groups.
Also micros a camera net helper to be less crap for non multiz maps
#### [Micros some open space atmos cases, alongside avoiding a for(null)
in opacity
handling](72ae07ba1d)
#### [Ensures space_lit tiles never accidentially inherit lighting
objects](a99ff2265a)
S dumb, and leads to space turfs having two sources of lighting, which
looks wrong.
This was invisible when their lighting was fullbright, but it sucks now.
### Misc Stuff
#### [Cleans up stat tracking a bit to avoid
collisions](40fb8f21e2)
#### [Cleans up a turf helper to not be
stupid](bf4ee67100)
WHY ARE YOU USING THE RANGED TURF HELPER IF YOU GO ONE TILE
#### [Moves transit turf signal cleanup to destroy, I named this proc
wrong](c85c2cfc86)
I'm sorry @Time-Green
#### [Adds better transit caching to
shuttles](35e85334c4)
Adds a max reserved transit size to the shuttle subsystem, to keep
things in bounds.
In addition, adds a soft cap under which existing transit space will get
hold onto, to make repeated non escape/arrive shuttle movements faster
Hopefully this makes common shuttle moves less bad.
## Why It's Good For The Game
Speed
## About The Pull Request
1. automatically adds access requirement to description of every supply
crate
2. also adds access_view to the automatic system, which previously was
not visible
## Why It's Good For The Game
1. better code
2. now you can see what access you need to privately purchase a crate
from the supply console.
## Changelog
🆑
code: The access requirements at the end of supply crate descriptions
are now automatically generated
fix: Supply console now tells you what access each crate needs to be
privately purchased
/🆑
## About The Pull Request
Checking the initial pack's contains did not work for canisters because
they were manually given a contains by ``generate_supply_packs()``, so
they were skipped over when creating supply packs.
## Why It's Good For The Game
Canisters can now be ordered again.
Closes https://github.com/tgstation/tgstation/issues/71679
## Changelog
🆑
fix: You can now order canisters again.
/🆑
## About The Pull Request
Now comes with a Hackmd: https://hackmd.io/ImTe5FLeTgmI7spTWKBaFQ?view
In-game screenshots:
Removes the old Mining vendor console and all its bad code. Instead, the
chef produce console was generalized and a NEW mining vendor is a
subtype of it. If they try to Express this console, it will be 1.5x the
mining points (compared to 2x for the Chef produce console atm), so it
is technically possible, but it is still better to order it through
Cargo.
Different to the Kitchen crate, this one is a private order by the Shaft
Miner, using mining points instead of Credits. Cargo CAN emitter it
open, but I think that's an acceptable risk with all crates. As shown in
the screenshot, Cargo will immediately know who ordered the items so
knows who to call to pick it up when needed.
This also means Shaft Miner's vendor is now categorized somewhat. I
tried my best to make sense out of it but some items really don't make
sense (laser pointer, soap...)
I split the different sections of orderable items into different files
for better management, and de-hardcoded it and its TGUI to make it
easier for anyone who wants to add more to it.
I also made the produce console use paths and added ways 'categories' to
produce consoles, which indicates which sections you should and
shouldn't be allowed to see.
https://github.com/tgstation/tgstation/pull/71007 already did part of
this but it isn't merged yet so :/
Free golems are mostly unaffected by this. Their console only works in
express mode and doesn't increase the prices for it. The only downside
is the cooldown.
I still have some things to finish on this PR so it'll be left as draft
until at least tomorrow.
## Why It's Good For The Game
https://hackmd.io/ImTe5FLeTgmI7spTWKBaFQ?view
1. A large problem currently with Miners is that they don't interact
with the station, this will at least help integrate them more into their
own department, by making the cost of their equipment cheaper if they
bother to actually go through Cargo for their gear.
2. It also means that a non functional Cargo would affect Shaft Miners
too, and as they have access to the shuttle, maybe we can expect some
Miners to pick up the slack if needed.
3. The old mining vendor was the ONLY vendor in the game that had
infinite stock. It doesn't need a refill or anything like any other
vendor, and every other vendor uses credits, mining points is just shaft
miner credits. Why are they an exception? At least being ordered through
the shuttle makes sense.
4. It opens the QM being able to see easier what Miners are doing, and
prevents miners from hiding on Lavaland to do nothing but hunt fauna if
they were meant to be demoted or something by the QM. Basically, gives
the QM more control over the people working in their department.
## Changelog
🆑
add: Shaft Miner's equipment vendor now orders their equipment through
the Cargo shuttle, though you can spend 1.5x the points to express it,
making it a Mining version of the Chef's produce console, with a
weakened express tax.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
About The Pull Request
Currently there are a bunch of snowflake checks on the mining shuttle console's attack_hand proc, including a check for TRAIT_ILLITERATE which is hardcoded to specific destinations and is causing issues with the public lavaland shuttle in #69641. When I started looking at that issue I realized that this should all probably be done in ui_interact() instead, and also that checking specifically for TRAIT_ILLITERATE when there's a proc for this (can_read) makes little sense. So I moved it all to ui_interact and cleaned up the TRAIT_ILLITERATE check. I also moved some code related to getting the list of destinations of shuttle consoles into a proc which is shared between the ui_data proc and the can_read check.
Now any illiterate mob which isn't otherwise blocked from interacting (such as monkies, ash lizards, and humans with a quirk) which interact with the shuttle console will spend 10 seconds "randomly mashing buttons" before sending it to a random valid destination. This is (essentially) the current behavior for humans with illiteracy and was (per @timothymtorres ) the intended behavior for ash lizards when he added the illiteracy quirk to begin with in #66648. I'm just making it less snowflakey and I guess technically adding it to monkies too since they could also use the shuttle before that PR and it doesn't make sense to exclude them arbitrarily.
Why It's Good For The Game
Fixes#69641
Generally makes the code more standardized, attack_hand checks are legacy from before ui interact was unified into can_interact and ui_interact. Making the code apply to all shuttle consoles and randomly pick a valid destination makes the more maintainable and less prone to random issues than a hardcoded list.
Also makes the other existing checks more consistent, for example the labor shuttle will now also warn rev heads, block free golems, and let illiterates move them just like the mining and public lavaland shuttles do.
Changelog
cl VexingRaven
fix: The illiteracy quirk will no longer break the mining shuttle
refactor: Refactored some checks on the shuttle console to apply to all consoles
/cl
* A lot of shuttle code improvements
* Makes use of ``as anything`` in many places
* Adds mapload to connect_to_shuttle()
* Renames many vars, including shuttle 'id' var to 'shuttle_id' and engine 'state' to 'engine_state'.
* Engines now weakref their attached ship, and disconnect when unwrenched from it.
* Removes check for force when deleting a mobile docking port, being deleted should still clear your stuff, regardless of being forced.
Because of all the above, I was able to remove a few pointless checks scattered around, like engine's alter_engine_power()
* better comment for port_id
* Fixes Cargo, Arrivals, and Pirate ships.
* Merge branch 'master' into shuttlecode-oh-no
* last few
* fixes the CI
* fixes
* Fixes infinite engines
* Revert "Merge branch 'master' into shuttlecode-oh-no"
This reverts commit 94eba37de9fe3f4a01dc40bb064771b764f379e3.
* trammies
* whiteship tram
* Makes use of ?. instead
apparently this is what weakrefs use, so 🤷
* i hate supernovaa41
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* removes lateinit that I never implemented
* adds _ref to weakref var name
* small change to weld time define
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
When 65% or more of the station is revs, the shuttle will automatically call. This shuttle can be recalled.
Approved with majority vote from me and @ninjanomnom
Should probably be test merged first, I touched some core shuttle code.
Roughly 60% of rev victories I checked called the shuttle shortly after. That's a lot, but there's still a high amount that aren't, either because the population genuinely wants to stay, or the revolutionary victory was a surprise. The latter of which I had happen to me like, recently! Remember that was the core problem revs victories continuing the round was trying to fix.
With that in mind, this plays nicely with both some player grievances with post-revs while keeping in line with the core of the feature. Players are still, in part, controlling the end of the round, but with affordance given to the most likely scenario.
This reverts commit f021767645.
This reverts commit f021767 from:
Add stamped requisition forms now give bonus credits #66230
This bug was encountered when we were testing this PR but I thought it got fixed.
Why It's Good For The Game
Cargo crates will now reappear.
Requisition forms now grant bonus credits when they are stamped by the appropriate stamp listed under "Authorization Required:" on the form. Initially I was just going to have the req forms give the same amount of credits as the manifest but I was convinced to lower both of them so it doesn't unbalance crate returns too much.
This PR adds the resonance cascade to the SM (idea ported from vg but with total rewrite)
The resonance cascade will turn reality into crystals that devours and destroy everything.
It can be triggered by delaminating the SM when is in contact with hypernoblium and antinoblium, both at over 40% and with as many moles to trigger a singulo delamination. The cascade can't be triggered if the SM is already under 80% integrity and if at any point any of the gases gets under 40% or the total gets lower than the amount for singulo, it will stop the cascade and can't be retriggered unless you reset the SM to over 80% integrity.
Bring _HELPERS/_lists.dm to latest standards by:
-Adding proper documentation and fixing existing one
-Giving vars proper names
-Procs now use snake case as per standard (many files that use those procs will be affected)
* The Failsafe can now recover from an deleted MC
Its also more reliable and can handle a situation where its main Loop runtimes and the MC is stuck
* Reset defcon level correctly
Oops left that in from debugging the levels
* Correctly recover SSasset
* Only decrease defcon if MC creation failed
Also add some sort sleep between emergency loops
* Makes the last two emergency actions manual procs
Since they are kinda unstantable its probalby best
if only admins call these manually
Its also more reliable and can handle a situation where its main Loop runtimes and the MC is stuck
You can also now debug Master/New()
While there will most likely never be any situation where the MC is just gone its still good to know that the game can recover from such a situation
For example maybe someone messed up a SDQL query or maybe someone wanted to delete the MC to create a new one hoping the Failsafe would do so for him
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
* Beep beep gamemode removal coming through
* More cleaning
* More cleaning
* Clean up station_was_nuked
* Station nuke source
* Remove name
* More unused functions
* Remove antag rep, which was unused in dynamic
* Remove more antag rep stuff, which was UNUSED IN DYNAMIC
* Station goals outside of mode
* Remove setup_done
* Remove player lists
* Move some older procs
* Fix simulations
* Attempt to fix this stupid case sensitive bullshit
* Revert "Attempt to fix this stupid case sensitive bullshit"
This reverts commit 8693c02d67602543d7d4b92130a7a32cd973e5bf.
* ???
* Delete icons/Testing directory
* Move station_goals global definition
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
This PR adds station traits which are essentially small changes to a normal round that can be used to create small variations in how a round might play out, sometimes there might be only one, very simple trait, but you might have a round where they have a somewhat bigger impact, to make rounds feel slightly more different from each other.
The following traits have been added:
Positive:
Lucky winner - Free pizza and beer every 6-12 minutes
Galactic Grant - Larger starting funds for cargo
Premium internals boxes - emergency box has flare + radio as bonus
Bountiful bounties - Bounties pay 20% more
Strong supply lines - Imports 20% cheaper
Filled maint - More loot in maint
Fast shuttle - Cargo shuttle is faster
Free scarves - Free scarfs if a slot is free
Neutral:
Bananium shipment - Clown starts with 5 sheets of bananium (Neutral because this helps noone but the clown)
Unnatural atmosphere - Lava planet can get more restricted gasses
Unique AI - Random lawset at roundstart for AI
Ian adventure - Ian teleports to a random spot on the station
Glitched PDAs - PDA's have a different beep
Announcer intern - Changes the announcement messages to sound like they're from an intern at Centcom
Negative:
Carp infestation - Carp event is more common and can start earlier
Weak supply lines - Imports 20% more expensive
Blackout - Station lights are partially broken around the station
Empty maint - Less loot in maint
Overflow bureacracy mistake - Random overflow job (From a vetted list)
Late Arrivals - Everyone starts in arrivals
Random spawns - Random spawn location (by drop pod)
Slow shuttle - Cargo shuttle is slower
Co-authored-by: Mothblocks <35135081+Jared-Fogle@users.noreply.github.com>
Co-authored-by: coiax <yellowbounder@gmail.com>
It's a story as old as time itself. Admin loads a new shuttle, decorates it, and then shuttle catastrophe triggers and the admin gets deeply, deeply owned. With this, you can set what emergency shuttle they picked and prevent any more changes to the shuttle!
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
* Start of work
* More work
* Finish visuals for main page for AIs, start work on behavior
* More functionality--authenticating and calling shuttle
* Set security level
* Message list
* Purchasing shuttles
* Emagging, messaing associates, nuke codes, permission fixes
* Sending message to allied sectors (done?)
* CentComm -> CentCom
* Resolve part of feedback
* Remove now unused pageComponent variable
* Change children to not use array
* Split lines
* Flex box allied stations
* Don't use ternary
* Fix lints
* Rebuild tgui
* Change icon to biohazard
* Clean up color property
* Rebuild tgui
Set mode = SHUTTLE_PREARRIVAL to shuttle that initially placed to transit docking port.
No more SSshuttles delete transit for half loaded shuttle
Fix#54232
* add replace button to shuttle panel
load button now only load new shuttle
* shuttle teplate loads as shuttle
* new shuttle console connects to shuttle
* new navigation computer connect to shurrle
* docking_port id now unique
add count to id if id already in work
* many docks from one base tenplate
* up
* fix unregister
* up
* up
* up
* block multiple shuttle loading
* return preview button
* up id generation
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
Admins now have the option to enable or disable the shuttle(located in the admin tab).
Disabling the shuttle will basically pause it where it is, regardless(unless game is over). Until the admins enable it again. It will resume exactly back to where it was and continue from there. This is great for events. You can't recall or call the shuttle while it's disabled.
Admins also now get the option when calling the shuttle to disable the recall of said shuttle unless they cancel it or select enable shuttle.
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
