## About The Pull Request
Adds 'Bloody Spreader' component that bloodies everything it touches!
For example inserting an item into it if it is a storage item. Or
entering it if it's a turf, or bumping onto it, or... you get the point,
hopefully.
Added this component to the MEAT backpack, meat slabs, bouncy castles,
meateor fluff, meateor heart, and the heretic sanguine blade.
Gave most of these the blood walk component as well, which spreads blood
if it's dragged around.
Meat slabs contain a limited amount of both components, eventually they
will 'dry out'.
## Why It's Good For The Game
Meat isn't meaty and squelchy enough, this will make it meatier. It also
makes the janitor suffer.
## Changelog
🆑
code: Adds 'Bloody Spreader' component that bloodies everything it
touches!
code: For example inserting an item into it if it is a storage item. Or
entering it if it's a turf, or bumping onto it, or... you get the point,
hopefully.
add: Added this component to the MEAT backpack, meat slabs, bouncy
castles, meateor fluff, meateor heart, and the heretic sanguine blade.
add: Gave most of these the blood walk component as well, which spreads
blood if it's dragged around.
add: Meat slabs contain a limited amount of both components, eventually
they will 'dry out'.
code: Added a signal for when an item is entered into storage.
/🆑
## About The Pull Request
This takes all the gib related procs:
- `gib()`
- `spawn_gibs()`
- `spill_organs()`
- `spread_bodyparts()`
And adds heavy documentation that communicates what the procs are used
for and how the different bitflags affect them. The difference is
noticeable:
`gib(TRUE, FALSE, FALSE, null)` vs `gib(DROP_ORGANS|DROP_BODYPARTS)`
The code is now much more legible which is important considering it's
used in a lot of places!
Another robust change, is that we had several places in the code where
there were double negatives like so:
```
/mob/living/carbon/spill_organs(no_brain, no_organs, no_bodyparts)
if(!no_bodyparts) // DOUBLE NEGATIVES ARE BAD M'KAY?!?
// do stuff here
```
This is a mindfuck to untangle. I inverted a lot of these parts so we
don't lose our sanity.
Last thing that was changed was a big `if()` loop in the `spill_organ()`
proc. This was refactored to just be a simple `for` loop with `continue`
statements where we needed to skip enabled bitflags. It's now shorter
and cleaner than before.
The only slight gameplay change this affects is that gibbing a mob now
guarantees to drop all items unless the `DROP_ITEMS` bitflag is
deliberately omitted. Some places like admin gib self, we don't want
this to happen.
## Why It's Good For The Game
Gib code is very old. (~15 years) People kept adding more arguments to
the procs when it should have been a bitflag initially. By doing it this
way, there is more flexibility and readability when it comes to adding
new code in the future.
## Changelog
🆑
refactor: Refactor gib code to be more robust.
qol: Gibbing a mob will result in all items being dropped instead of
getting deleted. There are a few exceptions (like admin gib self) where
this will not take place.
/🆑
## About The Pull Request
Adds multi-z support for lazy templates
Also fixes some improper use and placement for turf flags
## Why It's Good For The Game
Shadow needs/wants this for bit runner maps.
Turf flags are also why lava has been generating in places it shouldnt.
(inside of ruins)
## Changelog
🆑
fix: Lava can no longer occasionally generate inside of previously
loaded templates and breach and/or destroy shit
/🆑
---------
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
Heavily refactors wounds AGAIN.
The primary thing this PR does is completely change how wounds are
generated and added - while the normal "hit a guy til they bleed" stuff
works about the same, asking for a specific type of wound, say, like how
vending machines try to apply a compound fracture sometimes, isnt going
to work if we ever get any non-organic wounds, which the previous
refactor allowed.
With this PR, however...
* You can now ask for a specific type of wound via
get_corresponding_wound_type(), which takes wound types, a limb, wound
series, etc. and will try to give you a wound fitting those
specifications - but also, a wound that can be applied to a limb.
* This will allow for a vending machine to apply a compound fracture to
a human, but a collapsed superstructure (assuming my synth wounds go in)
to a robot
There are now new "series types" and "wound specific types" that allow
us to designate what series are "mainline" and randomly generatable, and
what are "alternate types" and must be generated manually - you can see
the documentation in wounds.dm.
The behavior of limping and interaction delays has been abstracted to
datum/wound from bone wounds to allow just, general ease of development
Pregen data now allows for series-specific wound penalties. Example: You
could set a burn wound's series wound penalty to 40, which would make
wound progression in the burn category easier - but it would not make it
any easier to get a slashing wound. As it stands wound penalties are for
wounds globally
Scar files are now picked in a "priority" list, where the wound checks
to see if the limb has a biostate before moving down in said list.
Example: Wounds will check for flesh first, if it finds it - it will use
the flesh scar list. Failing that, they then check bone - if it uses
that, it will use the bone scar list. This allows for significantly more
modular scars that dont even need much proc editing when a new wound
type is added
Misc changes: most initial() usage has been replaced by singleton
datums, wound_type is now wound_types and thus wounds can accept
multiple wound types, wounds can now accept multiple tool behaviors for
treatment, wounds now have a picking weight so we can make certain
wounds rarer flatly,
This PR also allows for wounds to override lower severity wounds on
generation, allowing eswords to jump to avulsions - but in spirit of
refactoring, this has been disabled by default (see pregen data's
competition_mode var).
## Why It's Good For The Game
Code quality is good!
Also, all the changes above allow wounds to be a MUCH more modular
system, which is one of its biggest problems right now - everything is
kinda hardcoded and static, making creative work within wounds harder to
do.
## Changelog
🆑
refactor: Refactored wounds yet again
fix: Wounds are now picked from the most severe down again, meaning
eswords can jump to avulsions
fix: Scar descs are now properly applied
/🆑
## About The Pull Request
This PR does many things and I expect to be asked to atomize some stuff.
### Oldstation Additions
Oldstation now has their own research server, generating their own
points. To help alleviate major concerns, they have a few stuff to help
with this:
- They now have a pre-built operating computer
- They now have an Autopsy scanner
- They now have access to Experimental Dissection
Experimental Dissection is the old dissection, giving research points in
the form of paper notes on completion. They must be turned in to the RND
server (only works on the Oldstation one, so you can't abuse this) for
points. This was an idea I've had for some time, as Oldstation is used
somewhat as a representation of how ss13 used to be (through its use of
directional windows (before they got removed, but I'd like to bring them
back), old IDs, RTGs, and old engines before they got removed from the
game fully)
Considering there are 11 alien mobs in Oldstation, there is 27.5k
research points to get from alien corpses, enough to bring them up to
speed with whatever they wish to do. This is their 'alternative' for
experiments (which they can still do if they want, but it is very hard
to do, outside of dissection which is needed for the node).
This surgery isn't repeatable, isn't upgradable, and isn't removed by
being healed. It is not mutually exclusive with autopsy (so you can't
ruin yourself doing the wrong surgery).
### Other stuff
- Ninjas now drain RND points from the server they drain from, rather
than always hitting science
- Syncing machines to research roundstart is now a macro, and now
immediately syncs to a server on your Z-level. Machines will
automatically connect to the Science servers if none else are available.
### non-player facing
- Science, Admin, and Oldstation techwebs are now no longer vars on
research, but stored in research's list of techwebs.
- ``get_available_servers`` and ``find_valid_servers`` are now procs on
the research subsystem, rather than the experisci component.
- Oldstation code has been split into separate files.
## Why It's Good For The Game
Oldstation is one of my favorite ruins, but it is also one of the
largest complaints for RND (along with Golems) because they use the
station's Science nodes & points (I recently tried de-hardcoding Science
stuff to help prepare for this, but I didn't get everything in advance).
The complaint stems from these ghost roles, who are meant to be a fun
activity to do while waiting for the next round, using the station's
research points for their own stuff, completely untrackable unless
someone goes out of their way to grief a ghost spawn just for using
points to get things they need. These roles make their own servers to
drain the station, and I find that unfun and quite boring for everyone-
it's also not very flavorful, why would Charliestation know of the
station's RND to take advantage of it?
This hopes to fix those issues, make Charliestation more worthwhile, and
more flavorful.
## Changelog
🆑
fix: Getting a node researched now properly makes it no longer hidden.
fix: Ninjas draining RD servers now drains it from the connected
techweb, rather than sniping Science.
balance: Machines will first try to connect to a techweb with servers on
their z-level, with the Science techweb remaining as fallback.
add: Oldstation RND, comes with their own Techweb and special surgery to
gain research points through dissecting Xenomorphs.
/🆑
## About The Pull Request
Hey there,
There were more than a few times (like in cinematic code) where we might
need to accurately know the source of what's adding this trait (or have
multiple sources for the whole 'we don't want this mob to do shit while
we transform this mob'), so in order to rectify this potential issue,
let's refactor it into a trait.
## Why It's Good For The Game
Some code already declared that there might be issues with this being a
boolean var (with no way of knowing _why_ we don't want this mob to not
transform (or not do anything idk). Let's remove those comments and any
future doubt in those instances with the trait macros. Also, stuff like
`TRAIT_IMMOBILIZED` which does a similar thing in many contexts was
already a trait that was regularly added in conjunction with flipping
the variable, so we're able to flatten all that stuff into
`add_traits()` and `remove_traits()` now. nice
I also cleaned up quite a bit of code as I saw it, let me know if it
should be split out but I guarantee that if I didn't do it- no one will
for the next two years.
## Changelog
🆑
refactor: If you transform into another mob and notice bugs with
interacting with the game world, please create a bug report as this
framework was recently refactored.
/🆑
Probably fucked up somewhere, lmk
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Corrects the specific_tram_id helper for the Hilbert's Research to use
the hilbert tram ID. I've also dropped the `.../hilbert/research`
(tram-specific) paths in favor of simply `.../hilbert`
## Why It's Good For The Game
Fixes the Hilbert Hotel Research ruin's tram, and also stops the
malfunctioning tram event from being able to use that tram to start. (No
more trams going haywire on maps without trams!)
Closes#78018
## Changelog
🆑
fix: Hilbert's Hotel Research ruin now has a functioning tram. As a side
effect, the malfunctioning tram event should now only fire on maps with
a tram!
/🆑
## About The Pull Request
**_THIS PR UPDATES THE SCAR VERSION - ALL EXISTING SCARS WILL BE
WIPED_**
Expands the wound system functionality to support any type of limb at
all.
To do this, wounds have been significantly refactored. For starters,
wounds now use limb biotype instead of wound type for determining what
they can be applied to. They also use singleton instances for most "can
we apply this" checks instead if copy pasted initial().
Wounds now use a "wound series" instead of wound_type for determining
the, well, series. Previously, all WOUND_BLUNT wounds were considered
bone wounds, making it impossible to have multiple WOUND_BLUNT wounds at
once. Now, its based on wound series - bone wounds are of the blunt bone
wound series, and use the typical logic.
One change that results from this is the ability for everything with a
jointed limb to get a dislocation. Yes, this includes things like
prosthetics.
On the note of external and internal biotypes: Exterior are bones,
Interior is flesh. Interior protects exterior from slash until its
mangled, at which point it either exposes exterior to slash or allows
dismemberment if theres no exterior.
Basically - it acts the exact same way, except its not hardcoded, and
its more modular.
A lot, lot more changes were made - I cant name them all, but if youre
interested, you can read up. Wounds have more procs, more
modularization, and less hardcoding.
Sadly, scars have been updated in such a way so that the wound version
must be updated. Scars will be deleted.
## Why It's Good For The Game
As it stands, half the limbs in the game can't be dismembered. This
changes that, allowing every single limb to be dismembered.
The two dismemberment critera are now:
1. If able to get mangled flesh or bone, it can be dismembered once it
gets mangled flesh and bone (or JUST flesh if it only has a internal
biostate, vice vers afor bone if external only)
2. If it cant be dismembered by the above, it will have a chance to
dismember when at or above 80% of its total max damage
Finally, code being better is usually a good thing.
## Changelog
🆑
balance: Prosthetics and slimepeople can now have limbs dismembered
balance: Slimepeople can now receive slash wounds, but cannot bleed
balance: Most limbs can now be dislocated
refactor: Scar backend reworked, scars will be wiped as they update to
the new format
/🆑
## About The Pull Request
Adds interaction between immovable rod and the tram for the rare
occasions the rod hits it at the front or back while flying at a
parallel angle.
The rod will push/pull the tram in the direction it's flying until a
short distance past the tram's usual landmark, eventually winning and
carrying on.
- Only applies to random rods, if the rod has a target it will ignore
the tram as usual.
- Looping rod only pushes the tram once.
- As long as the tram has power, can be returned to the rails as usual
by calling it.
## Why It's Good For The Game
When the HoP is having a really unlucky day.
https://github.com/tgstation/tgstation/assets/83487515/2f0393cd-f796-4b00-8674-d97e57358543https://github.com/tgstation/tgstation/assets/83487515/f74c8497-8d62-4fcf-80a0-da7259160b7f
## Changelog
🆑 LT3
add: Immovable rod will now battle the unstoppable tram should they
cross paths
fix: Birdshot's maint tram doors now work properly
fix: Tramstation's exterior light fixtures no longer get destroyed as
soon as the tram moves
code: Tram landmarks are now all subtyped instead of map varedits
/🆑
## About The Pull Request
Massively overhauls and standardizes the nuclear operative uplink.
### Weapon Kits
Essentially, all the main weapons of the uplink have been changed to
instead come as 'weapon kits', which are essentially cases containing a
weapon loadout to enable operatives to easily start operating on only
just one item purchase, without the fuss of worrying whether or not
operatives are getting spare ammo, or getting relevant equipment for
success. Consider this a pseudo-loadout, though without necessarily
restricting the purchasing of more weapon kits.
All kits come in three categories: Low Cost (8 TC), Medium Cost (14 TC)
and High Cost (18 TC). This is also matched by categorized ammo costs;
Basic Ammo (2 TC), Hollow Point and Armour Penetrating (4 TC),
Incendiary (3 TC) and Special (or anything that does not easily fit
these categories and does something real extra) (5 TC). Weapons that
lacked these ammos have gained these ammo types to fill the gaps.
<details>
There is may one exception to this in disruptor ammo, which is priced as
basic ammo if only because it isn't _quite_ good enough to justify
pricing at 5 tc and I can see an op wanting to use it as a basic ammo
type instead of normal .50 BMG against, say, a silicon/mech heavy
opposition. Since it cannot kill organics on its own, I'll consider this
mostly basic-adjacent
</details>
The kits have also been labelled based on potential difficulty. This
reflects possible difficulties in using the item, how conducive it is to
success for how much game knowledge needed to actually use it, and how
likely an op is to succeed using it. I don't expect ops to win using
nothing but a rocket launcher, but I think ops should get a fair shake
at trying, yeah?
The kits are as below:
#### **Low-Cost**
_Bulldog (Moderate):_ Shotgun and three magazines of standard ammo.
_Ansem (Easy/Spare):_ Pistol and three spare magazines of standard ammo.
#### **Medium Cost**
_C-20r (Easy):_ SMG and three spare magazines of standard ammo.
_Energy Sword and Shield (Very Hard):_ Energy sword and shield. (Also a
special hat)
_Revolver (Moderate):_ Revolver and three speedloaders of standard ammo.
_Rocket Launcher (Hard):_ Rocket launcher with three spare rockets.
#### **High Cost**
_L6 SAW (Moderate):_ LMG, and that's it. No spare ammo.
_M-90gl (Hard):_ Rifle, two spare magazines of standard ammo and a box
of rubber grenades.
_Sniper (Hard):_ Sniper rifle, two spare magazine of standard ammo, and
one magazine of disruptor ammo. Also suit and tie.
_CQC (Very Hard):_ Comes with a stealth implant and a bandana.
_Double-Energy Sword (Very Hard):_ Double-energy sword, syndicate soap,
antislip module, meth injector and a prisoner jumpsuit.
_**NEW** Grenadier's Kit (Hard):_ Grenadier's belt and grenade launcher
(the one that launchers chem grenades). (I replaced the shit acid
grenade with another flashbang in the belt)
Surplus SMG (Flukie difficulty) has been unchanged. It just now comes
with two rations.
Includes two new revolver ammo types: Phasic, which goes through walls
and armor, but has significantly less damage as a result (I've equalized
the revolver damage and the rifle version's damage to 30 for both). And
Heartseeker, which has homing bullets. Both are Special ammo, and are
priced at 5 TC a speedloader.
### Other Gear
The other items in the uplink have also been consolidated and
standardized in various ways.
#### Grenades
Most now cost 15 TC for three grenades of any given type (including the
full fungal tuberculous). This is pretty much identical to the previous
price, just more consistent overall and front-loaded in cost.
#### Reinforcements
All the various reinforcements now cost 35 TC and all refundable,
equalizing cost to the average across the reinforcements. This is
primarily because I feel like all these options should be weighed
equally, and not one of these options are necessarily worse or better
than the other in their current balance. They're largely inaccessible
for normal ops regardless, and typically come out when there is a
discount or war ops. I took the average value and went with it. Not much
more to say.
#### Mechs
They're just cheaper. These things still suck and they need help.
They've always needed help. A slightly less excessive value for the
mechs may help see people willing to spend the TC on them. I doubt it. I
seriously suggest not buying these still. I keep them in primarily
because they are big stompy mechs and are kind of iconic 'war ops' gear.
#### Bundles
Since I've implemented weapon kits, gun bundles are rather redundant. So
the bulldog weapon and ammo bundle, the c20-r weapon and ammo bundle and
technically the sniper bundle were removed. The sniper bundle is now the
weapon kit, obviously.
Nothing else here really. Except for one....
#### Implants
Not much changed here. I standardized the implant prices to 8 TC a pop.
This is in accordance with traitor implants, which ops also get. So
everything in this category bar a few exceptions (like macro/microbombs)
are around 8 TC. Makes sense to me, really.
Importantly, I made the Implant bundle 25 TC, and I unrandomized the
contents. Who in the right fucking mind would spend 40 TC just to get
five reviver implants is beyond me. But instead, you get one of each of
the cybernetic implants except thermal eyes (you can just buy thermals
and get the benefit of both vision types; x-ray and thermal vision, if
you want to use smokescreens a lot).
#### Base Keys
They're all now 15 TC, except the fridge which is 5 TC. It's weird
they're valued differently when they are taken mostly to do gimmicks
like xenobio and toxins in a hurry before hitting the station. So we've
standardized it.
## Hat Crate
**YES, GOOD SIR, YOU TOO CAN ORDER A HAT CRATE FROM THE SYNDICATE STORE
FOR ONLY 5 TC!**
**NO NEED FOR A KEY, JUST BUY IT AND PULL IT OPEN WITH YOUR STANDARD
ISSUE CROWBAR!**
**ENJOY YOUR NEW CRATE! ENJOY YOUR NEW HAT!**
**PUT IT ON USING THE FREE HAT STABILIZERS WE INCLUDED WITH THE HATS!**
~~**NO REFUNDS IF YOU GET BLOOD ON YOUR HAT!**~~
<details>
There is a 1% chance to instagib people with direct hits from a rocket.
This does the crit effect.
</details>
## Why It's Good For The Game
The uplink needed more spring cleaning and standardization.
With this, I've partially implemented my older idea for ammo consistency
and initial allowance for nukies. Ammo is kind of over-priced and often
where a good chunk of TC goes towards without really pushing nukies
towards meaningful success. And it is often what is tripping up new
players who didn't think to get any. Now, when they get a gun, they get
ammo in their case. On top of this, the weapon kit category is both at
the top of the uplink AND has a little label to say 'Recommend', so that
these new players will hopefully know they should be looking there
first.
In addition, it is the gateway towards a concept that is currently being
worked on. Nuclear operatives having some degree of predefined loadouts
for players to select if they aren't sure what they want, or don't know
what to get. Nukies is very confusing for many players. So giving them a
fighting chance with some premade setups can help ease them into the
role without needing too much player knowledge in how to apply the
items. This is only one step towards that, so that players can identify
what gear they need to help succeed based on their skill.
I wanted to implement a difficulty warning so that players can choose
gear loadouts that are actually conducive to their skill and knowledge.
I based it on how much players would need to know to engage in combat
with it, and how much fiddling is required to get something to work
properly (overly involved reloading is a consideration, for example, as
well as precise button presses). In addition, how much of a force
multiplier some weapons can be for their ease of use.
Most people recognize the c20-r as the most new player friendly weapon,
as an example. So it would be good to steer players towards taking that
gun because of how easy it is to use, understand and succeed with it.
And most importantly of all; Having standards within the uplink is
important. Most of the values in the uplink are just completely random.
Nobody has a good grasp of what is too much or too little. Even just a
hint of consistency, and people will stick to it (see implants for what
I mean). And there is still some work to be done even there. A good
start is weapons. Price for power can be meaningful when decided whether
we want some weapons to come out more often than others. Players do
enjoy making informed decisions and choices, and having affordability be
a draw to some otherwise less powerful weapons (looking at you, Bulldog)
can actually be a worthwhile and meaningful difference.
~~I thought it would tick off the gun nerds to change the calibers on
the guns.~~
~~I also thought adding hats would be funny given the release of TF2's
most recent update.~~
## Changelog
🆑
balance: Standardizes some of the nuclear operative entries to have more
consistent pricing within their respective categories.
add: Adds some new categories so that players have an easier time
navigating the nuclear operative uplink.
balance: Many items have had prices reduced or adjusted to make them
more desirable or more consistent within their category.
add: Weapon kits have replaced almost all the individual weapons in the
uplink. You now buy these instead of the individual weapon. These often
come with spare ammo or relevant gear for success.
add: Most ammo types have been standardized in price.
refactor; Removes a lot of redundant item entry code and tidies up the
actual code part of the nuclear uplink so that it is much easier to find
things within it.
add: Added 40 new cosmetic items to the Syndicate Store. Buy them now
from the Hat Crate, only 5 TC!
code: Updated the nuclear operative uplink files.
/🆑
## 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
Due to a mental breakdown caused by unfathomable abomination that is
icons folder, I swore to myself to one day clean it. Today is kind of
that day. Been at it for around 6, you gotta understand I need a rest. I
tracked most changes in descriptions of commits if you are looking for
details.
## Why It's Good For The Game
Saner spriters make better sprites. And also, just helps keep track of
things.
## Changelog
🆑
image: added sprites for different variants of scrolls.
image: modified couple posters with ghost pixels.
/🆑
---------
Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>
## About The Pull Request
Removed `ambigen2.ogg` and renamed all the generic ambience sounds after
`ambigen1.ogg` to account the fact we have one less generic ambience
sound file now.
## Why It's Good For The Game
This will close#75010
## Changelog
N/A, it wasn't even used in the code.
## About The Pull Request
Adds defines for gasses and replaces uses I've found to instead use the
defines.
Can you believe I made this PR while trying to work with Xenos? This
sucks!
## Why It's Good For The Game
There's a lot of different uses of things like "o2" and "plasma", and
they are pretty inconsistent. In some places, it's "hydrogen", in others
it's "h2". In some it's "plasma", others "plasm". This unifies it all
under defines so it has a less chance of breaking in the future.
## Changelog
Nothing player-facing.
## About The Pull Request
Removes a bunch of sound files that we don't use and moves some sound
files into better locations. I'm hoping to get an archive repo for
sounds going, much like the
[map_depot](https://github.com/tgstation/map_depot) and
[SS13-sprites](https://github.com/tgstation/SS13-sprites).
EDIT: The old sound files are being moved here:
https://github.com/tgstation/SS13-sounds
Also increased the volume of the clownana rustle sound and clipped off
some dead air from shockwave_explosion
## Why It's Good For The Game
Removes a total of 1.95MB worth of unused sound files from the codebase.
## Changelog
🆑 Tattle
soundadd: increased the volume of the clownana rustle
/🆑
---------
Co-authored-by: tattle <article.disaster@gmail.com>
## About The Pull Request
0426f7ddba/code/game/objects/items/stacks/stack.dm (L449)
Ok, but can we not?
This PR refactors sheet crafting to generalize all the cases that were
previously locked behind grille/window type checks and such. In their
stead there are bitflags that can be set to achieve certain behaviors.
All the behavior from before should be preserved, but now it can be
extended to other items. E.g. if you want a railing that can be crafted
underneath directional windows, or an item that behaves like a grille
does--it's just a matter of setting the right obj_flags for it now.
This makes it very simple and painless to add new recipes that use
directional crafting! It's all modular now.
<details><summary>Details</summary>
---
### What I've done:
-Eliminated all the type checks, instead it will now be handled by
object flags and recipe vars, making for a much more configurable
system.
-Added two new obj_flags: `BLOCKS_CONSTRUCTION_DIR` and
`IGNORE_DENSITY`.
-Additionally, I renamed the existing flag `NO_BUILD` to
`BLOCKS_CONSTRUCTION`.
-Changes the proc `valid_window_location` to `valid_build_direction`,
and makes it work for things other than windows.
-Removed a deprecated `window_checks` var from the stack_recipe datum.
-Added three more vars to the stack_recipe datum: `check_direction` and
`check_density`, `is_fulltile`
-Decoupled `on_solid_ground` from the object density check. Now you can
set those separately, allowing you to make recipes that forbid/allow
building things over other things while in space.
---
### What the new flags do:
`BLOCKS_CONSTRUCTION` works as before---prevents objects from being
built on the object. I felt that the previous name was not descriptive
enough, you should know exactly what it does just from looking at the
name.
_example: dna scanner_
`BLOCKS_CONSTRUCTION_DIR` -- setting this on an object will prevent
objects from being built on it when their directions are the same.
_example: directional windows, windoors, railings_
`IGNORE_DENSITY` -- setting this on an object will cause its density to
be ignored when performing the construction density check. This could
have other potential uses as well in the future.
_example: grilles, directional windows, tables_
These three flags cover all the bases for the types of items that are
currently craftable, so there is no more need for any type checking or
weird snowflake window checks. Simply set the appropriate flag and it'll
work as you would expect.
---
### What the recipe vars do:
`check_direction` tells the recipe to check if there's something in that
direction with the `BLOCKS_CONSTRUCTION_DIR` flag set.
`check_density` tells the recipe to run the density check when set. This
is true by default. There are very few items in the game that currently
have this set to false--namely grilles. Setting this to false will make
it so that the object can be constructed regardless of what is in that
tile (unless `one_per_turf` is also set, which will make it so that you
can't craft the same thing twice in the same turf).
`is_fulltile` is used for fulltile windows, but it doesn't necessarily
have to be--you can give this to any recipe and it will adopt the same
properties as that of the fulltile window. Basically they have a special
case where they shouldn't be able to be built over directional
constructions, where normally things would be able to be. Setting this
makes check_direction true as well.
---
### In summary:
Sheet crafting still works just as it did before. But the backend of it
has gotten a glow up and will be able to more easily support new
behaviors.
</details>
## Why It's Good For The Game
This makes the crafting system much more flexible to add recipes to, and
will prevent bad code practices of stacking more conditionals down the
line whenever someone wants to add an item that behaves like grilles or
directional windows in how they are constructed.
It had to be done. Those window checks were a mess.
## Changelog
🆑
qol: added fifty stack versions of remaining glass sheet stacks for ease
of debugging
refactor: refactored sheet crafting to better support directional
constructions that aren't windows
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
gives shoes to waystation cargo technician corpses
## Why It's Good For The Game
fixes#74512
## Changelog
🆑
fix: waystation cargo techs get shoes now
/🆑
## About The Pull Request
This sprite file had been a dumping ground for miscellaneous sprites for
the past decade. It's bloated and full of random kinds of icons and even
has a few unused ones. It's time to reorganize them into their own
separate dmi's based on theme.
## Why It's Good For The Game
Better organization and easier access when looking for stuff.
## Changelog
🆑
imageadd: Split all icons in weapons_and_items.dmi to their own
categories
imagedel: Removed some unused icons
/🆑
## About The Pull Request
Did you know that there's 2 types of disks Science can print?
One of them creates a whole new techweb and is used to transfer data to
and from techwebs (which used to be for Theft objective, but nowadays
all it's used for is Admin techweb).
The other one is these disks you can find from Lavaland & for the
Limbgrower which holds nodes on them directly, they don't need anything
else.
These are both printable and have very similar names which could easily
confuse people, especially since they are both printed and used at the
same place, being the R&D room and R&D console.
This will hopefully simplify it, by removing the base Tech disks from
being printable. The only one that can be printed now is for
Limbgrowers, which can't be easily mixed with the other type of Disk.
Outside of that, Lavaland disks are staying the same, but I've moved
Bepis disks to use this, which allows us to remove Bepis techwebs being
made every single time a new bepis disk is created.
Examples of it in-game
## Why It's Good For The Game
There's no reason why every single Bepis node should be making a whole
new techweb set with experiments to complete, roundstart nodes
researched, being constantly checked if it should gain research points,
have a list of papers to publish, and everything else that techwebs do.
Can you guess which disk does what in this screenshot?
## Changelog
🆑
balance: You can no longer print Technology data disks. You can still
print Tech disks, which hold techweb information on it, just not the one
that holds up to 5 nodes.
balance: ^ Because of this, there's no way to download nodes from an RD
console and upload them to an Autolathe to bypass departmental
restrictions, you have to go through a Techfab/Circuit imprinter for
your needs.
balance: Ones that are found cannot have anything uploaded/deleted off
of them either, you can only upload them to the Web.
code: Every individual Bepis disk no longer create an entire techweb
/🆑
## About The Pull Request
Broken by #74163
Various child procs of `/obj/machinery/proc/open_machine(drop = TRUE,
density_to_set = FALSE)` didn't have the same params as the parent proc.
This leads to the wrong arg being passed to the parent's `drop = TRUE`
param during the parent proc call.
In this case, 0 (FALSE). Leading to machines that never dropped their
contents when opened. This is a problem when a lot of the machines I've
fixed contain players, necessitating admin intervention to free them.
## Why It's Good For The Game
Feex.
## Changelog
🆑
fix: DNA Scanners, Sleepers, Abductor Experimentors, Skill Stations and
Mod Installers now appropriately release their contents when opened,
fixing an issue where they could permanently absorb players and items
until admins intervened.
/🆑
## About The Pull Request
These changes fix how machines are pried open with crowbars. Currently,
most machines can be pried open, but many of them have no method for
being closed again. This means they can be pried once, and then never
again (as their internal logic has them stuck in an "open" state).
Additionally, the densities of these machines is also inconsistent, as
density is tied to the procs for opening/closing machines (open =
non-dense, closed = dense). Thus, these new changes allow desired
densities to be passed to `open_machine()` and `close_machine()`, as
well as `default_pry_open()`, meaning that atypical machine densities
can be maintained (e.g. machines that should remain dense when open, or
non-dense when closed).
I've also added a `close_after_pry` boolean parameter to the
`default_pry_open()` proc, which determines whether to immediately close
a machine after opening it. This is useful for machines that don't
really have a use case for remaining open, often lacking a sprite to
represent this state as well.
* Note: Opening and immediately closing machines with this boolean will
still drop their contents onto the floor, but will now immediately
"close" in their logic, allowing for further prying attempts in the
future.
It's worth noting that this implements default density values for these
procs, which match the existing behavior for machines, so as to
(hopefully) not disrupt existing or expected machine behavior.
Two caveats to these changes currently exist:
1. On machines that immediately close after prying, the prying action
can now be spammed to the chat with repeated clicking. I'm uncertain if
this needs some sort of spam protection or if it's fine as is.
2. I've only been able to manually test this code. I'd love to write
unit tests for it, as it affects a lot of different machines, but don't
know where to begin with DM Unit Testing (or which files would be good
examples to reference in the code base).
* Note: I did manually test each and every machine that calls
`default_pry_open()` and they all seem to be working correctly. (Except
for `obj/machinery/plumbing/sender`, but that doesn't seem to need
prying, as it has no contents to drop, only reagents.)
As always, let me know if any improvements/changes should be made.
This closes#26833.
## Why It's Good For The Game
These changes allow crowbar prying to correctly occur multiple times on
any machine, which is intended behavior. It prevents player confusion
that could occur when a machine couldn't be pried open a second time
during a shift, even though it had previously been pried before, forcing
players to question themselves. (Are they missing something? Did they
perform the action a different way last time? Is the machine actually
still powered on instead of off? Etc.)
These changes also maintain the correct density for machines after
prying, preventing scenarios where a machine might behave differently
once it had been pried open. (An example of this was being able to walk
through a smartfridge after prying it open.) Additionally, players are
no longer required to know/use workarounds (such as machine disassembly)
to retrieve a powered-off machine's contents.
Overall, these changes improve consistency around machines, creating
more scenarios where they behave as players would expect.
## Changelog
🆑
fix: machines can now be pried open more than once.
fix: machines now have the correct density when pried open.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
- Tram crossing signals now call process() much less often
- Tram crossing signals don't turn amber/red needlessly
- Tram destination landmarks are more generic to accommodate future
maps, like Birdshot
- Renames to_where and from_where, because those vars didn't always
match tram position to/from
## Why It's Good For The Game
Tram works better, uses less processing
## Changelog
🆑 LT3
code: Tram crossing signal/platform logic improvements
/🆑
## About The Pull Request
Quite a lot of mobs had faction defines as a string, which always has a
chance for error. For example, the clown mob spawner had their faction
written as "clown", when the official faction name was "clowns", and a
define existed for it anyways! This PR moves every single string based
factions over here. No references or special role factions. Hopefully I
didn't miss anything.
I also moved a global define used for picking your uplink provider's
flavour to the only file that used it, datum_traitor.dm, and renamed
them a bit to avoid confusion.
I have also noticed that the mimic faction was assigned to the petrified
player with += instead of |=. |= would ensure no duplicate factions, so
I have changed it.
Future improvement:
I have noticed that there is a lot of bloat with factions that contain
only one or two entries (examples: gnomes, floating eyeballs, penguins,
the pet lizards), and some always appear in pairs (vines and plants, the
rare exceptions being killer tomatoes and strange reagent spawned pine
trees), but trimming consolidating them is a matter for a different
time.
## Why It's Good For The Game
Makes assigning factions a bit less error prone.
I can finally remove the ```/// Later all mob factions will be moved
here and their current factions replaced with faction defines.```
comment. Later is NOW.
## Changelog
Nothing player facing
## About The Pull Request
Over the years I've heard quite a few lizard players scratch their heads
in confusion due to the lack of gibs filling you up. I gave it a fairly
low value of 2 so people don't end up trying to power game it.
## Why It's Good For The Game
Adding an alternative use to gibs is always nice, at the moment it's
mostly just used for soap and cytology (Which barely anyone does.)
## Changelog
🆑
balance: Gibs now provide a small amount of nutriment.
/🆑
## About The Pull Request
revive of #68760
this time a proc, not an element
this time supports cardboard cutouts
this time supports mob corpses
## Why It's Good For The Game
prevents these icons ever being outdated, they'll always look what they
are supposed to, saves spriting work
## Changelog
🆑 Fikou, a hood by Viro
refactor: humanoid mobs and cardboard cutouts automatically generate
their sprites, they no longer will be outdated
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## About The Pull Request
We do two major things here.
First, instead of having every turf need to ask all the turfs in "front"
of it for its blast resistance, we have blast resistance carry back in a
cache, so they only need to ask the one directly in front of them.
Much faster, such wow
The other thing we do is totally remove the idea of "building" a turf's
explosion resistance. Instead, a turf's full resistance is stored on it
at all times.
We use an element to manage objects that want to block explosives, and
that's it simple as.
As an optimization, turfs handle block differently, using a system where
we imply that a turf's own block is just the initial of their
explosive_resistance, unless proven otherwise
This also saves a significant amount of time
To be honest with you, I did this mostly cause I wanted to well make
explosions faster
This doesn't really fufil that. They are faster, but not by much
The bulk of explosion cost comes from actually exploding things, rather
then figuring out what/how to delete.
This code is much faster for larger blastwave sizes, because calculating
protection is constant.
We save maybe 60% of propogate_blastwave, but unfortunately
propogate_blastwave for one maxcap on the top left of icebox's chapel is
only 28ms, so while 11ms is good, it's not everything I could want when
the cost of explosion/fire is 555ms.
I'm happy about it still tho, because doing things like this means I can
expand on how explosive blocking works without needing to make things
seriously expensive in here.
Also it's faster for meme admin explosions and mega burgers
## Why It's Good For The Game
Speeds up explosives slightly, opens the door to better blast resistance
projection
Necessary for #72292 to work effectively, and probably not very useful
out of that context. Split out of its own PR because this is long and
boring.
I want to make sure that we're catching actual mistakes there, and not
just experiencing side effects of how shitty the attack chain is.
## 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!
/🆑
This one is fun.
On every /turf/Initialize and /atom/Initialize, we try to set
`smoothing_groups` and `canSmoothWith` to a cached list of bitfields. At
the type level, these are specified as lists of IDs, which are then
`Join`ed in Initialize, and retrieved from the cache (or built from
there).
The problem is that the cache only misses about 60 times, but the cache
hits more than a hundred thousand times. This means we eat the cost of
`Join` (which is very very slow, because strings + BYOND), as well as
the preliminary `length` checks, for every single atom.
Furthermore, as you might remember, if you have any list variable set on
a type, it'll create a hidden `(init)` proc to create the list. On
turfs, that costs us about 60ms.
This PR does a cool trick where we can completely eliminate the `Join`
*and* the lists at the cost of a little more work when building the
cache.
The trick is that we replace the current type definitions with this:
```patch
- smoothing_groups = list(SMOOTH_GROUP_TURF_OPEN, SMOOTH_GROUP_FLOOR_ASH)
- canSmoothWith = list(SMOOTH_GROUP_FLOOR_ASH, SMOOTH_GROUP_CLOSED_TURFS)
+ smoothing_groups = SMOOTH_GROUP_TURF_OPEN + SMOOTH_GROUP_FLOOR_ASH
+ canSmoothWith = SMOOTH_GROUP_FLOOR_ASH + SMOOTH_GROUP_CLOSED_TURFS
```
These defines, instead of being numbers, are now segments of a string,
delimited by commas.
For instance, if ASH used to be 13, and CLOSED_TURFS used to be 37, this
used to equal `list(13, 37)`. Now, it equals `"13,37,"`.
Then, when the cache misses, we take that string, and treat it as part
of a JSON list, and decode it from there. Meaning:
```java
// Starting value
"13,37,"
// We have a trailing comma, so add a dummy value
"13,37,0"
// Make it an array
"[13,37,0]"
// Decode
list(13, 37, 0)
// Chop off the dummy value
list(13, 37) // Done!
```
This on its own eliminates 265ms *without space ruins*, with the
combined savings of turf/Initialize, atom/Initialize, and the hidden
(init) procs that no longer exist.
Furthermore, there's some other fun stuff we gain from this approach
emergently.
We previously had a difference between `S_TURF` and `S_OBJ`. The idea is
that if you have any smoothing groups with `S_OBJ`, then you will gain
the `SMOOTH_OBJ` bitflag (though note to self, I need to check that the
cost of adding this is actually worth it). This is achieved by the fact
that `S_OBJ` simply takes the last turf, and adds onto that, meaning
that if the biggest value in the sorting groups is greater than that,
then we know we're going to be smoothing to objects.
This new method provides a limitation here. BYOND has no way of
converting a number to a string at compile time, meaning that we can't
evaluate `MAX_S_TURF + offset` into a string. Instead, in order to
preserve the nice UX, `S_OBJ` now instead opts to make the numbers
negative. This means that what used to be something like:
```dm
smoothing_groups = list(SMOOTH_GROUP_ALIEN_RESIN, SMOOTH_GROUP_ALIEN_WEEDS)
```
...which may have been represented as
```dm
smoothing_groups = list(15, MAX_S_TURF + 3)
```
...will now become, at compile time:
```dm
smoothing_groups = "15,-3,"
```
Except! Because we guarantee smoothing groups are sorted through unit
testing, this is actually going to look like:
```dm
smoothing_groups = "-3,15,"
```
Meaning that we can now check if we're smoothing with objects just by
checking if `smoothing_groups[1] == "-"`, as that's the only way that is
possible. Neat!
Furthermore, though much simpler, what used to be `if
(length(smoothing_groups))` (and canSmoothWith) on every single
atom/Initialize and turf/Initialize can now be `if (smoothing_groups)`,
since empty strings are falsy. `length` is about 15% slower than doing
nothing, so in procs as hot as this, this gives some nice gains just on
its own.
For developers, very little changes. Instead of using `list`, you now
use `+`. The order might change, as `S_OBJ` now needs to come first, but
unit tests will catch you if you mess up. Also, you will notice that all
`S_OBJ` have been increased by one. This is because we used to have
`S_TURF(0)` and `S_OBJ(0)`, but with this new trick, -0 == 0, and so
they conflicted and needed to be changed.
## About The Pull Request
Fixes a spelling error in some fluff text
## Why It's Good For The Game
Spelling errors are bad
## Changelog
🆑
spellcheck: Fixed a spelling error in some fluff
/🆑
## About The Pull Request
Hilbert Research Facility tram buttons work now.
Hilbert Research Facility's tram no longer has engines.
Redoes the overlay effect on the broken tv in hilbert lore room by
making it its own type.
Makes the tele porta turrets their own type.
Adds support for html in lore terminals, and makes Roman's emails use
them.
fixes https://github.com/tgstation/tgstation/issues/68072
## Why It's Good For The Game
some neat stuff that hilbert needed
## Changelog
🆑
fix: Hilbert Research Facility tram buttons work now.
qol: Adds support for html in lore terminals, and makes Hilbert Research
Facility emails use them.
/🆑
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>
