## About The Pull Request
This makes `/datum/player_details` properly track BYOND version and
build separately, as opposed to just the full version string.
Whenever a client logs in, and their BYOND version is 516, while their
previous version was 515, or vice versa, it'll set a newly added client
var, `rebuild_plane_masters`, to TRUE.
During the `COMSIG_MOB_LOGIN` signal handler of a mob's HUD
(`/datum/hud/proc/client_refresh`), it will check to see if
`rebuild_plane_masters` is TRUE - if so, it will set the appropriate
`relay_loc` of (based on client BYOND version) of its plane master
groups, and rebuild their plane masters.
## Why It's Good For The Game
Makes testing stuff across 515 and 516 easier, as your screen won't
break when switching between the two.
## Changelog
516 is _still_ in private alpha, so no user-facing changes.
## About The Pull Request
existance doesnt exist so i changed it to existence
## Why It's Good For The Game
existance dosent exist
## Changelog
🆑
spellcheck: spellecheck: existence not existance
/🆑
## About The Pull Request
1. Deletes `INFINTIE`, it is misleading and not at all a big number and
causes bugs
2. Adds `STATUS_EFFECT_PERMANENT` and `STATUS_EFFECT_NO_TICK` to make it
clearer what infinite status effects are
## About The Pull Request
autotator, malf and blob's candidates would all get wiped out by this,
as `can_roll_midround()` returns TRUE if they can roll midround
## Why It's Good For The Game
seems like we want candidates in these roles, given the game is trying
to get some
## Changelog
🆑
fix: dynamic rulesets can get candidates for their roles
/🆑fixes#87535
## Why It's Good For The Game
Clarity and consistency regarding DM's systems.
Internally, `eye` is used for anything that controls the client's view.
How `eye` is used in DM is consistent with how we use the term, so I
figured this would add clarity.
Being named mob/camera also makes it unclear exactly what it's doing.
The name implies that it would function similar to how mob/camera/ai_eye
does, but most of the time it's only used as... an eye.
My ulterior reason for this PR is that I want to clean up
mob/camera/ai_eye and it's subtypes after this.
## Changelog
🆑
server: mob/camera has been renamed to mob/eye, which may break
downstreams
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Adds a new boolean that lets you opt out of automatically linking
zlevels in `LoadGroup()` (as implemented in
https://github.com/tgstation/tgstation/pull/87029); and forwards that
support to map jsons. Does ***not*** change any /tg/ map jsons in the
process; as they all still work as intended.
A modified Icebox JSON loading correctly:
### How do I disable automatic z-level linking?
Add the following to your json; under planetary:
``` "height_autosetup": 0, ```
For each z-level's trait; you can then add either `"Up": true` or `"Down": true` to link them manually, as you would've prior to #87029 .
## Why It's Good For The Game
tl;dr, map experimentation. It was prior possible to have station segments separated by z-level that weren't vertically linked; which was put to practice most prominently on Nova Sector, of all places, - but #87029 made it automatically assume that they should be linked in that manner.
This middleground keeps the new assumption while preserving the old manual process for any mapping projects that need it.
## Changelog
🆑
code: Mappers can now opt out of automatically linking their up/down station traits.
/🆑
## About The Pull Request
I'm adding a score that tracks which types of fish you've caught across
multiple rounds. To do so, I had to add a new score subtype that manages
the score value not being a number. Thankfully the achievement code is
fairly flexible so not a whole lot had to be done, although I've to add
a new column to the achievements table in the DB, because the 'value' is
for integers, while we need one for text strings ~~(the contents of the
list are converted to text with a delimiter before being saved cuz I'm
not sure if and how our DM slash SQL integration handles using lists
directly and I don't want to waste time finding it out)~~.
EDIT: It's mostly done beside the reviews that are going to point out
things that need to be changed. The UI changes are done. It's time for
reviews.
Here are screenshots of the UI with all fish still uncatched beside one
(I've since then the typo on its name and removed an extra zero from the
index number, as well as a nit with the spacing between cells):
## Why It's Good For The Game
We have about dozens over dozens of different fish in the game now, many
of which are just fluff anyway. It's getting to the point it's perhaps
doable to add a score or something to be a braggard about.
## Changelog
🆑
add: Added a new score that keeps track of all different fish that
you've caught between shifts.
server: Added a new schema table to store the aforementioned entries and
the ckeys associated to them, with an additional timestamp column.
/🆑
## About The Pull Request
## Why It's Good For The Game
gives players more control over how loud they want certain sounds to be
## Changelog
🆑 grungussuss
sound: the volume that ship ambience, ambience, radio noise and
announcements play at can now be tweaked in preferences, check your
preferences!
/🆑
## About The Pull Request
Rewrite `/datum/generecipe` to have two variables, `input_one` and
`input_two` that hold the type path of the ingredients for the recipe,
instead of it being a semicolon-separated string.
## Why It's Good For The Game
Better code, will catch invalid type paths in recipes at compile-time.
## Changelog
No player-facing changes
Fixes#86331Fixes#87060
## Why It's Good For The Game
Admins keep trying to spawn stuff postgame and it doesnt work
## Changelog
🆑
fix: alert polls work past roundend
/🆑
## About The Pull Request
Fixes an issue mentioned in
https://github.com/tgstation/tgstation/issues/72526, where pressing
"Now!" in the game panel for injecting a latejoin, caused midround one
to occur as well. This was because the same boolean was used for forcing
both, which caused both to happen.
* Closes https://github.com/tgstation/tgstation/issues/72526
## Why It's Good For The Game
Improves admin tools by fixing a bug.
## Changelog
🆑
admin: doing a latejoin injection no longer causes a midround one as
well
/🆑
## About The Pull Request
This PR kills the abstract internal and external typepaths for organs,
now replaced by an EXTERNAL_ORGAN flag to distinguish the two kinds.
This PR also fixes fox ears (from #87162, no tail is added) and
mushpeople's caps (they should be red, the screenshot is a tad
outdated).
And yes, you can now use a hair dye spray to recolor body parts like
most tails, podpeople hair, mushpeople caps and cat ears. The process
can be reversed by using the spray again.
## Why It's Good For The Game
Time-Green put some effort during the last few months to untie functions
and mechanics from external/internal organ pathing. Now, all that this
pathing is good for are a few typechecks, easily replaceable with
bitflags.
Also podpeople and mushpeople need a way to recolor their "hair". This
kind of applies to fish tails from the fish infusion, which colors can't
be selected right now. The rest is just there if you ever want to
recolor your lizard tail for some reason.
Proof of testing btw (screenshot taken before mushpeople cap fix, right
side has dyed body parts, moth can't be dyed, they're already fabolous):
## Changelog
🆑
code: Removed internal/external pathing from organs in favor of a bit
flag. Hopefully this shouldn't break anything about organs.
fix: Fixed invisible fox ears.
fix: Fixed mushpeople caps not being colored red by default.
add: You can now dye most tails, podpeople hair, mushpeople caps etc.
with a hair dye spray.
/🆑
## About The Pull Request
Upon getting stabbed in your eyes or having a bullet fly through your
head there's a chance (minor for stabbing, extremely low for headshots)
you'll receive a new "Eye Puncture" wound which causes profuse bleeding
out of your now-empty eye hole. Once healed you'll have to deal with a
scar on your eye which cannot be cured and requires surgical
replacement. Eye scarring will reduce your eyes' max health by 15, give
you a minor screen tint and a fancy visual on your character sprite.
Getting scarring on both eyes will turn you completely blind.
This PR also introduces a new quirk which gives you eye scarring on the
eye of your choice and an eyepatch to go alongside it, just make sure
that it sits on the right eye.
Also added medical(white) subtype of eyepatches to loadout for those who
want that version instead. Credits to AnturK on discord for the idea.
## Why It's Good For The Game
Its a neat lil' feature that makes the game more immersive, and unlocks
more roleplay opportunities for players. New quirk gives access to this
feature for players who want to make it a part of their character's
backstory (or maybe as a part of permanent scar roleplaying).
## Changelog
🆑
add: Getting stabbed or shot in the eyes has a chance of giving you a
new wound and a semi-permanent scar, blinding you on one side
add: Added new "Scarred Eye" quirk which blinds you on one eye but gives
you a fancy eyepatch
add: Medical eyepatches have been added to loadout
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
## About The Pull Request
movement subsystem now has the SS_BACKGROUND flag removed
excuse me if this isnt any correct like i know daedalus did this for
some reason at best
## Why It's Good For The Game
(stuff controlled by) movement ss is not actually THAT costly (compared
to Throwing)
(when i nuked metastation on local)
and i think being able to move when you slip on oil or whatever eg
jetpacks during lotsa lag is pretty important
this does not actually make it immune to lag it just seems to mitigate
the issue by a slight margin
## Changelog
🆑
code: Movement Subsystem no longer is a background subsystem. This means
that you should no longer get stuck after slipping on oil during
instances of high usage.
/🆑
## About The Pull Request
Turns out that if you don't test if you fix works, it probably won't!
I've actually managed to test this one, and even though it gave me a
handshake error when joining the other server, at least the fade in
worked! The fadeout is set up in the same way, so it should be fine
## Why It's Good For The Game
ACTUALLY fixes#29496
## Changelog
🆑
fix: ACTUALLY fixes server hop fade in
/🆑
## About The Pull Request
I'm adding a new infusion ~~(actually four, but two of them are just
holders for specific organs tied to a couple fish traits)~~ to the game.
As the title says, it's about fish.
The infusion is composed of three primary organs, plus another few that
can be gotten from fish with specific traits.
The primary organs are:
- Gills (lungs): Instead of breathing oxygen, you now need to stay wet
or breathe water vapor.
- fish-DNA infused stomach: Can safely eat raw fish.
- fish tail: On its own, it only speeds you up on water turfs, but it
has another effect once past the organ set threshold. It also makes you
waddle and flop like a fish while crawling (I still gotta finish sprites
on this one)
Other organs are:
- semi-aquatic lungs: A subtype of gills from fish with the 'amphibious'
trait, falls back on oxygen if there's no water. Can also be gotten from
frogs, axolotl and crabs.
- fish-DNA infused liver: From fish with the 'toxic' trait. Uses
tetrodotoxin as a healing chem instead of a toxin. Also better tolerance
to alcohol if you want to drink like a fish (ba dum tsh).
- inky tongue: From fish with the 'ink production' trait. Gives mobs the
ability to spit ink on a cooldown, blinding and confusion foes
temporarily.
The main gimmick of this infusion revolves around being drenched in
water to benefit from it, In the case you get the gills organ, this also
becomes a necessity, to not suffocate to death (alternatively, you can
breathe water vapor, without any benefit). To enable the bonus of the
organs set, three organs need to be infused. They can be gills, stomach,
tail and/or liver, while the inky tongue doesn't count towards it.
Once the threshold is reached, the following bonus are enabled:
- Wetness decays a lot slower and resists fire a bit more.
- Ink spit becomes stronger, allowing it to very briefly knock down
foes.
- Fishing bonuses and experience
- Resistance to high pressures
- Slightly expanded FOV
- drinking water and showers mildly heal you over time.
- for felinids: You won't hate getting sprayed by water or taking a
shower.
- While wet:
- - If the fish tail is implanted, crawling speed is boosted.
- - You no longer slip on wet tiles.
- - You also become slippery when lying on the floor.
- - You get a very mild damage resistance and passive stamina
regeneration, and cool down faster.
- - You resist grabs better.
- - get a very weak positive moodlet.
- However, being dry will make you quite squisher, especially against
fire damage, slower and give you a modest negative moodlet.
While working on it, I've also noticed a few things that explained why
tetrodotoxin (TTX) did jackshit at low doses, because livers have a set
toxin tolerance value, below which, any amount of toxin does nothing.
Also I've felt like reagents like multiver & co were a bit too strong
against a reagent that's supposed to work at very low doses, with slow
metabolization, so I've added a couple variables to buff TTX a bit,
making it harder to purge and resistant to liver toxin tolerance (also
added a bit of lungs damage).
## Why It's Good For The Game
I wanted to take a shot at coding a DNA infusion and see how chock-full
I could make it. DNA infusions are like a middle point between "aha,
small visual trinket" and organs with generally ok effects. I seek to
make something a bit more complex ~~(also tied to fishing ofc because
that's more or less the recurrent gag of my recent features)~~ primaly
focused around the unique theme of being strong when wet and weaker when
dry.
EDIT: The PR is now ready, have a set of screenshots of the (fairly mid)
fish tails (and gills, barely visible) on randomly generated spessman
and one consistent joe:
## Changelog
🆑
add: Added a new infusion to the game: Fish. Its main gimmick revolves
around being stronger and slippery when wet while weaker when dry.
balance: Buffed tetrodotoxin a little against liver tolerance and
purging reagents.
/🆑
## About The Pull Request
AI controllers do not respect their tick limits, behaving as if they
need to process all controllers in one tick.
This means every time the idle subsystem runs we process 500 controllers
at once. This is bad, and induces overtime for free, which sucks.
I can't think of a reason we would need to do all this work at once.
## About The Pull Request
Adds the Fundamentally Evil quirk. The quirk does nothing in of itself.
If an Empath examines you, they will be shaken up by the fact that you
are totally evil.
Mindreaders can literally see that you're evil. If they're ALSO evil, it
gives a gives a unique message.
Honorbound chaplains can freely attack you without first declaring you
evil. You are already evil. There is no outward tells for this fact, but
if the chaplain pays attention to the medical records, you might have a
problem on your hands.
You are significantly harmed by holy water and holy explosions. So don't
drink holy water if you can help it.
## Why It's Good For The Game
I just think it'd be funny to have some crew, for whatever reason, be
fully committed to being evil for no reason other than it is funny to
bother empaths.
I want a chaplain to come to the realization that I'm evil and see what
happens.
## Changelog
🆑
add: Fundamentally Evil quirk. You might act normal, but you know deep
down that you totally don't give a shit about anyone but yourself.
Empaths better watch out.
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
Co-authored-by: ATH1909 <42606352+ATH1909@users.noreply.github.com>
## About The Pull Request
I'm "cooking" the materials system a bit, specifically the code
responsible for applying and removing effects. My goal is to move most
of the code to the objects-side, split it in smaller procs that can be
more easily overriden or called for object-specific modifiers and
effects, while also revamping things all around to better support items
made from multiple materials (the cleric mace will most likely be one in
this PR, with the handle and tip made of different materials).
PR NO LONGER WIP, TESTED AND ALL, CLERIC MACES CAN NOW BE MADE OF TWO
MATERIALS.
## Why It's Good For The Game
One of the nastiest flaws with the materials system is that it's just
unfeasable to have items made of multiple mats (with effects enabled)
right now, as they easily tend to override each other, where some of the
modifiers and effects should only be applied the main material.
Beside, the system's starting to show signs of its time, from the
several type checks used to apply different effects, the one letter
variables to the the material flags that are still being passed down as
arguments when you can access them from the atom/source arg anyway. It
would be disonhest of me if I went ahead and coded material fishing rods
or whatever fish fuckery with materials without ensuring it won't
further the technical debt the feature currently has.
## Changelog
🆑
refactor: Refactored materials code. report any issue.
add: Cleric maces (The autolathe-printable weapon design from outer
space) can now be made of two different materials.
balance: Buffed cleric maces a little.
fix: toolboxes' stats are now affected by materials again.
/🆑
---------
Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com>
## About The Pull Request
Before there were two settings for human authority:
`ENFORCE_HUMAN_AUTHORITY` and `ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE`
The first, if enabled, would not let non-humans be heads of staff unless
they had a specific var on their job set to TRUE.
The second, if enabled, would simply ignore that var and reject the
non-human anyways.
This PR replaces both of those settings with a single one,
`HUMAN_AUTHORITY`. You can set it to one of four settings:
* "OFF": human authority will be turned OFF. Non-Humans will be able to
be heads of staff.
* "HUMAN WHITELIST": human authority will be turned OFF, HOWEVER; if a
job has its new `human_authority` variable set to
`JOB_AUTHORITY_HUMANS_ONLY`, then whoever picks that job will be forced
to be human.
* "NON-HUMAN WHITELIST": human authority will be turned ON. However, if
a job has its `human_authority` variable set to
`JOB_AUTHORITY_NON_HUMANS_ALLOWED`, a non-human can become that job.
This is what we have now, it works the same as if
`ENFORCE_HUMAN_AUTHORITY` were turned on. This is also what I've set as
the default value.
* "ENFORCED" human authority will be turned ON. Non-Humans will never be
able to be heads of staff. This is what
`ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE` used to do.
You can also now set the `human_authority` variable through
`jobconfig.toml`!
## Why It's Good For The Game
Allows more configuration options for downstreams, and lets keyholders
and headmins have more options over how to set up human authority.
## Changelog
🆑
config: Both human authority settings were combined into a singular one,
allowing for more flexibility
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
`SSpolling.poll_ghosts_for_target` returns a 0 length list when no
candidates are chosen so it will spawn an AI core without a client, so
instead of `if(isnull(ghost)` we do `if(!ismob(ghost))`.
closes https://github.com/tgstation/tgstation/issues/86976
## Changelog
🆑 grungussuss
fix: fixed a clientless AI spawning when a ghost poll for syndicate
modsuit AI had no volunteers
admin: AI rolebanned players can no longer role for Syndicate modsuit AI
/🆑
## About The Pull Request
ai controllers that have exhausted all their current behaviors now stop
processing until the next cycle, so we no longer need to do these checks
on every process fire. idle behaviors are now instead handled by a new
low priority subsystem. these are the costs before/after roughly 25
minutes into the round
## Why It's Good For The Game
improves ai performance
## Changelog
🆑
/🆑
## About The Pull Request
Fixes#86899
Assigning head positions doesn't use the `available_occupations` list
and instead just iterates through all command roles direct from some
department job helper, jumping over any that are at capacity.
This means the `available_occupations` list doesn't get updated when
head positions are assigned and can lead to an edge case where two
players can both get a single-slot job. The first player gets it via
`fill_all_head_positions_at_priority()`. The second player gets it via
being given a random role when any now-full head job doesn't get removed
from the `available_occupations` list.
There are many ways to fix this. The solution I've opted for is removing
command roles from the `available_occupations` list entirely, letting
`fill_all_head_positions_at_priority()` handle the logic for this
exclusively.
## Why It's Good For The Game
I feex.
## Changelog
🆑
fix: Fixes a bug where the game would assign multiple players to
single-slot command roles.
/🆑
## About The Pull Request
This autoloads the up/down traits for every map instead of having to
manually add those traits to the JSON.
## Why It's Good For The Game
More automation good. Also let's people experiment with larger maps like
a multi-z lavaland.
## Changelog
🆑
code: Automatically link maps multi-z up/down traits
/🆑
## About The Pull Request
Adds the following new general shuttle events:_
**Hitchhiker**
- 1% chance
- A single assistant in an EVA suit and some PBJs in a suitcase
**Assistant Wave**
- 0.1% chance
- Spawns 10 assistants with internals
- For clarity, they don't get sent to the shuttle, but get launched at
it from space. It's a scuffle of 10 assistants trying to get in without
being spaced or succumbing to the cold/pressure
**Intern Wave**
- Admin only
- Unarmed and armed version
- Spawns centcom interns, with a little announcement to warn they're
coming
I've also fixed projectiles bugging out and admin forced shuttle events
not activating if they were added after the shuttle launched
<details>
<summary>Admin only events added</summary>
**Nukie**
Spawns a single nukie, armed with a shotgun, pistol and edagger.
Basically the deathmatch nukie loadout, you dont want to fight this
**Meaty ores**
Meaty-ores meteors. Have a 4% chance to hit the shuttle, posing a
potential hazard
**3 player controlled fire-sharks**
3 fire sharks controlled by players. Not much to talk about here
**Fireball Wave**
Shoots a wave of fireballs at the shuttle. I think it's cool but
apparently shuttle walls and windows deflect fireballs so it's kind of
moot unless you're outside :/
</details>
## Why It's Good For The Game
The assistant and hitchhiker events are some flavoring that I thought up
a while ago. The Hitchhiker is just intentionally a flavor addition, but
the assistant wave and intern wave can be used by admins to repopulate
or retake the emergency shuttle as well.
## Changelog
🆑
add: Adds an assistant and hitchiker shuttle event, replenishing the
crew mid flight!
admin: Adds two intern wave shuttle events
code: You can now supply shuttle events with outfits!
code: You can now shoot projectiles with the shuttle events!
fix: Fixes projectiles bugging out when fired in shuttle transit space
fix: Fixes admin forced shuttle events not activating when added mid
transit
/🆑
## About The Pull Request
Changes map votes to be based on a persistent tally count.
Tallies for maps are cached between rounds and are added to by map
votes.
When a map is chosen, and it wasn't the only valid one, the tallies for
said chosen map will be reset.
Refactors map vote handling and moves it from SSmapping to SSmap_vote.
Rock the Vote has been removed as a result of this refactor.
## Why It's Good For The Game
Makes it more likely that all maps will be played over the course of a
server instead of always being truly random.
Removes some clutter off of SSmapping.
🆑
refactor: Map Votes are now carried over between rounds. When a map vote
is actually a contest, the winning map will have its votes reset.
/🆑
## About The Pull Request
So this was caused by the change in
https://github.com/tgstation/tgstation/pull/86012 .
They tried to fix a case for polls with `amount_to_pick` set to _greater
than 1_ having null entries in the returned lists, and succeeded at
that.
However, in doing so they messed up the control flow of the proc such
that now it's returning early with an empty `list()` whenever the amount
is _equal to 1_.
The assumption was, when `amount_to_pick` was equal to 1 specifically
then the return value would be either a `null` value or the valid mob.
However, now what was being returned was either a `list()` or the valid
mob because that code was no longer ever being reached.
For example
Fixes https://github.com/NovaSector/NovaSector/issues/4427
Fixes both bugs in a way that should not cause any problems, and adjusts
documentation to make it clearer what the return value of this proc is
expected to be.
## Why It's Good For The Game
Fixes a bug that pretty much effects the majority of ghost polls as most
of them are only asking for 1 player.
## Changelog
🆑
fix: fixes pulsing tumor failing to spawn the elite if no ghosts respond
to the poll and leaving you in a bugged state, and possibly other
related issues
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
123 changed files and multiple crashes after writing broken regex, I
replaced most remains of direct spans with macros. This cleans up the
code and makes it easier to work with in general, see justification for
the original PR. I also fixed a bunch of broken and/or unclosed spans
here too.
I intentionally avoided replacing spans with multiple classes (in most
cases) and spans in the middle of strings as it would impact readability
(in my opinion at least) and could be done later if required.
## Why It's Good For The Game
Cleaner code, actually using our macros, fixes borked HTML in some
places. See original PR.
## Changelog
Nothing player-facing
## About The Pull Request
This PR significantly enhances how zero-g movement works. Its no longer
locked to one of 8 directions, everything now has inertia and is
affected by weight. This means that throwing a piece of wire will no
longer completely reverse your movement direction, and that being thrown
out of mass driver no longer will slow you down to a halt at some point.
This leads to following gameplay changes:
* Guns now accelerate you. Ballistics have higher acceleration than
lasers, and higher calibers have higher acceleration than smaller ones.
This means that firing full-auto weapons in zero-g will make you drift
and accelerate significantly. While this can be a hilarious way to
travel in space, it makes using them trickier.
* Impacting a wall or an object while moving at high speeds will cause
you to violently crash into it as if you were thrown. Careful when
exploring!
* Jetpacks now have inertia. Changes introduced in #84712 have been
mostly reverted, although speed buff has been reduced to 0.3 instead of
0.5 (although this is compensated by new movement mechanics, so overall
speed should be roughly equal). All MODsuit jetpacks now possess the
speed boost. Advanced MODsuit jets (which has also been added back) and
captain's jetpack instead have higher acceleration and stabilization
power, providing much more precise control over your movement.
* Firing guns while moving on a jetpack will partially negate your
pack's acceleration, slowing you down. Non-advanced jetpacks'
stabilization is not enough to compensate for heavy caliber weaponry as
sniper rifles, shotguns or rocket launchers.
* You no longer instantly decelerate upon sliding along a wall. Instead,
it may take a few tiles if you are moving at extreme speeds. Passing
over lattices still allows you to grab onto them!
As space movement is angle-based instead of dir-based now, its much more
smooth than before due to using new movement logic.
Example of jetpack stabilization in action:
https://github.com/tgstation/tgstation/assets/44720187/6761a4fd-b7de-4523-97ea-38144b8aab41
And, of course, you can do this now.
**This pull request requires extensive gameplay testing before
merging**, as a large amount of numbers have been picked arbitrarily in
an attempt to keep consistency with previous behavior (guns and
normal-sized items applying 1 drift force, which is equal to what
everything applied before this PR). Jetpacks and impacts may also
require adjustments as to not be frustrating to use.
Closes#85165
## Why It's Good For The Game
Zero-G refactor - currently our zero-g movement is rather ugly and can
be uncomfortable to work with. A piece of cable being able to accelerate
you the same as a duffelbag full of items when thrown makes no sense,
and so does instantly changing directions. Inertia-based version is
smoother and more intuitive. This also makes being thrown into space
more of a hazard (possibly opening the door for explosive
decompressions?)
Jetpack inertia and gun changes - this is mostly a consequence of
inertia-based movement. However, zero-g combat being preferred during
modes like warops was an issue due to it negatively affecting everyone
without jetpacks which are in limited supply onboard. This reverts the
mobility changes which severely impacted space exploration, while making
zero-g combat more dangerous and having it require more skill to be a
viable option.
## What's left
- [x] Refactor moth wings to use jetpack code
- [x] Refactor functional wings to use jetpack code
- [x] Locate and fix a recursion runtime that sometimes occurs upon
splattering against a wall
- [x] Add craftable tethers and modify engineering MOD tethers to use
the same system
## Changelog
🆑
add: You can now craft tether anchors, which can be secured with a
wrench and attached to with right click. They won't let you drift into
space and you can adjust tether length/cut it via lmb/rmb/ctrl click on
the wire.
add: MOD tethers now remotely place and connect to tether anchors
instead of throwing you at where they landed.
balance: MOD tethers can now be used in gravity
balance: Jetpacks are now inertia-based.
balance: Guns can accelerate you significantly in zero-g.
balance: All jetpacks now give you equal speed buff, however advanced
MOD ion jets and captain's jetpack have higher acceleration/deceleration
values.
refactor: Refactored zero-g movement to be inertia-based and utilize
angles instead of directions.
/🆑
## About The Pull Request
<details>
- renamed ai folder to announcer
-- announcer --
- moved vox_fem to announcer
- moved approachingTG to announcer
- separated the ambience folder into ambience and instrumental
-- ambience --
- created holy folder moved all related sounds there
- created engineering folder and moved all related sounds there
- created security folder and moved ambidet there
- created general folder and moved ambigen there
- created icemoon folder and moved all icebox-related ambience there
- created medical folder and moved all medbay-related ambi there
- created ruin folder and moves all ruins ambi there
- created beach folder and moved seag and shore there
- created lavaland folder and moved related ambi there
- created aurora_caelus folder and placed its ambi there
- created misc folder and moved the rest of the files that don't have a
specific category into it
-- instrumental --
- moved traitor folder here
- created lobby_music folder and placed our songs there (title0 not used
anywhere? - server-side modification?)
-- items --
- moved secdeath to hailer
- moved surgery to handling
-- effects --
- moved chemistry into effects
- moved hallucinations into effects
- moved health into effects
- moved magic into effects
-- vehicles --
- moved mecha into vehicles
created mobs folder
-- mobs --
- moved creatures folder into mobs
- moved voice into mobs
renamed creatures to non-humanoids
renamed voice to humanoids
-- non-humanoids--
created cyborg folder
created hiss folder
moved harmalarm.ogg to cyborg
-- humanoids --
-- misc --
moved ghostwhisper to misc
moved insane_low_laugh to misc
I give up trying to document this.
</details>
- [X] ambience
- [x] announcer
- [x] effects
- [X] instrumental
- [x] items
- [x] machines
- [x] misc
- [X] mobs
- [X] runtime
- [X] vehicles
- [ ] attributions
## Why It's Good For The Game
This folder is so disorganized that it's vomit inducing, will make it
easier to find and add new sounds, providng a minor structure to the
sound folder.
## Changelog
🆑 grungussuss
refactor: the sound folder in the source code has been reorganized,
please report any oddities with sounds playing or not playing
server: lobby music has been repathed to sound/music/lobby_music
/🆑
## About The Pull Request
Rewrites a good chunk of express console code, removing one letter
variables, duplicate code and straightening all the staircases with
early returns. RIP cooldowns in ui_data()
Mapped-in consoles now actually work, as currently they initialize
before SSshuttles which results in them having a completely empty packs
menu. This is fixed by making them report themselves to SSshuttles which
will call package init on them once it itself initializes.
Emagging the console will update the prices in the UI, and emagged
consoles will try to send at least 1 package instead of requiring the
budget to have enough funds to send all 5 pods. Because when you press a
button with a price tag on it, you'd expect at least something to
happen.
Beacons now reset their offsets when anchored because thats been
triggering my OCD. Upgrade disks aren't deleted and instead drop when
the console is deconstructed.
## Why It's Good For The Game
Code is crunchy, stuff is broken, prices aren't displayed correctly when
the console is emagged and you'd expect at least something to arrive
when you press a button with a price that you can afford.
## Changelog
🆑
fix: Mapped in express supply consoles now work instead of displaying an
empty UI.
fix: Emagged express supply consoles now display updated prices.
refactor: Rewrote a large chunk of express supply console code
balance: Express supply consoles now drop their upgrade disk upon being
deconstructed, and emagged consoles now will try to send at least one
package to the station if cargo budget doesn't have enough funds for all
5.
/🆑
## About The Pull Request
This swaps out the pirate spawner on the Meta Central VDOM with the
subtype specifically meant for virtual domains. That thing wasn't
actually a virtual domain spawner, it was just a regular one.
This applies the necessary restrictions/roles being applied to pirates
who spawn on that map. It will also make #86794 work on the Metastation
Central map, rather than only affect the Corsair Cove map (which used
the correct spawner type).
This also adds the Announce to Ghosts flag to Meta Central, as is
uniform for maps with ghost roles. Doing so also enables the VDOM
selector UI indicator that ghost roles can spawn on the map.
This whole thing started as an attempt to fix#86785 but I was too slow
and someone beat me too it. Darn.
## Why It's Good For The Game
Ensures #86785 will be closed properly.
## Changelog
🆑 Rhials
fix: The Meta Central Virtual Domain now uses the proper ghost role
spawner, meaning you can't eavesdrop on syndie comms using their
headset.
/🆑
## About The Pull Request
ai controllers that fail planning no longer process until theyre able to
plan again. this makes it so /process is called less thus you'll have
less AI competing against one another for cpu. also converts idle
behaviors into singletons
## Why It's Good For The Game
AIs that dont have a plan dont do anything during processing so its
better to just make them sit out the cycle instead of draining cpu
## Changelog
🆑
/🆑
## About The Pull Request
In #86711 we made it so adjusting the trim of an id card also updated
the job on the associated bank account to match, but we forgot to update
`bank_accounts_by_job` to match this.
This made it so Curator painting patronage cuts wouldn't get updated to
match the trim, and would risk issues with removing it from
`bank_accounts_by_job` if the bank account were to get deleted.
In this pr we add a `update_account_job_lists(...)` proc that updated
`bank_accounts_by_job` to match.
This fixes our issues.
Additionally, we update `vv_edit_var(...)` to also run this when
changing related values, such that it actually removes and adds the
values when needed.
## Why It's Good For The Game
Fixes a bug, helps with VVediting bank account jobs.
## Changelog
🆑
fix: Changing a bank account's job to or from Curator actually changes
whether they get a cut from painting patronage.
admin: VVediting a bank account's account_job actually updates what job
the account is associated with. Currently only matters for Curators.
admin: VVediting a bank account's add_to_accounts actually removes it
from or adds it to the job to account associations. Currently only
matters for Curators.
/🆑
## About The Pull Request
So, I've been looking into manually loading job traits today, and it
seems the buttons don't appear until you reconnect. Upon further
investigations, it turns out that the code doesn't support showing lobby
buttons outside of SSstation init. To add injury only up to three
buttons can be displayed for some stupid reason (the lack of code for x
offsets), plus the buttons aren't relocated when one is removed, thus
possibly leaving behind an empty gap.
This PR fixes all of that, while removing some crumbs of shitcode from
new players' HUDs and making sure to remove datum traits and references
are removed when the trait is deleted (usually never the case outside
VV).
## Why It's Good For The Game
Lobby buttons should ALWAYS be shown to the player if the relative trait
is loaded, the only exception being the conditions set by the trait
itself (for job traits is the job age and whether the game has started
or not), while the offsets of the lobby buttons should stay synced with
how many are being displayed to the new player at any given time, so if
a button is deleted, the others are relocated to avoid having leaving an
empty gap behind.
Beside, this is necessary for the lobby button for the playable pun pun
to show up during Monkey Day.
## Changelog
N/A, all backend.
## About The Pull Request
Closes#61216Closes#57516
Arcane gave greenlight on this PR as its unlikely that this'll be
cheesed or affect balance in any way, and in worst case scenario mass
account changes will just summon space IRS on the offending HoP
## Changelog
🆑
fix: Changing ID card's trim now properly adjusts linked bank account's
job, allowing you to receive bounties for your new job
/🆑
## About The Previous Pull Request
#85308 reverted by #85929
~~Causes the round to not start when a player isn't eligible for any
jobs at a specific priority level due to runtimes trying to `pick()`
from an empty list aborting the entire job assignment stack.~~
(Fixed???? by
e0e9f2f430)
Maybe we should test merge this for a mo just to make sure no more
cheeky runtimes pop up before merging.
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
## About The Pull Request
[Ties new active turfs to SSair's "frame
window"](cf46d8b1fc)
Currently, if you add a new active turf midway through processing, it
will be handled as a PART of that fire's processing.
This combined with some bullshit with archive means that placing one
source of diffs down can lead to a 1 tick spread instantly, ONLY if no
turfs are actually active.
(The following is one tick of atmos processing)
This runs counter to the existing archiving system, and violates the
principles of active/inactive turfs of being an optimization over
processing every cell individually.
The fix is to uh, not do that.
It also solves the highly edge case of a turf that's activated by
something reacting to its temp change, alone in a 1x1 with no neighbors
possibly causing an infinte stall in ssair.
I'm also cleaning up add to active a bit, zypher's idea should have 0
cost.
[Makes turf to turf activation fully diamond
shaped](2528fb2764)
Turf sharing operates off the archived gas list, but the check to see if
we SHOULD share was working off the normal gas/temp values.
This meant diff evening out was DIRECTIONAL (due to the directional
ordering of atmos adjacent turfs)
This is fixable by just using archive for these things.
This does require an additional arg to compare() which DOES matter at
this scale but I don't want to split compare into two procs I don't
think and it should be relatively minimal.
This means cleaner debug outputs, hopefully less pointlessly activated
turfs, and a more consistent activation/sharing order (we aren't
dropping turfs randomly now!)
https://github.com/user-attachments/assets/347d3cd6-542f-48e6-aa83-40e7e9b11635
(spreading w/o this change as an example of the former issues)
https://github.com/user-attachments/assets/da1ecbce-28b6-4241-8ac6-517b690c9ba6
---------
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
## About The Pull Request
This is a remake of https://github.com/tgstation/tgstation/pull/84501
with a few small changes to avoid mapping issues. This time it's
restricted to a once-in-a-year event, mainly because neither Jacq and
Lemon were ok with the possibility of Pun Pun being posibly playable all
year, however Jacq said he's fine with it being available on the
holiday, while Lemon isn't around on Discord atm so I don't know what
he's to say.
The trait makes pun pun playable and gives them the job of being a
busser (waiter) in the cafeteria. They're clever and can use tools most
other monkeys can't, but cannot be humanized, while also being unable to
speak Galactic Common. Should they roll traitor, they'll be able to buy
syndicate monkey reinforcements and equipment, which it can also use,
being a monkey itself.
## Why It's Good For The Game
This is a fairly unique job, like the Cargo Gorilla, due to the fact
it's not a conventional humanoid crew member nor the AI or a cyborg. I
thought this was a fun idea, though I met some obstacles and the
original PR was DNM'ed and then closed. However, the trait perfectly
fits the theme of the holiday, making a good compromise since Pun Pun
will stay AI-controlled the rest of the year, as Jacquarel and Lemon
want it to be. It can also be added by an admin through VV, whether
they're planning some shenanigean or just want to add something more to
the round.
## Changelog
🆑
add: Pun Pun is a playable crewmember during Monkey Day (14 December).
/🆑
## About The Pull Request
I've come to realize manually updating all fishing stuff on the very
much outdated wiki would be a colossal pain in the rear, so I've decided
to automate a few bits to generate autowiki lists containing information
about fish, fish traits, bait, hooks, reels, fishng rods, fish sources
and fish experiments.
Now tested.
## Why It's Good For The Game
Making a huge autowiki for a feature that's being constantly updated (by
me) but still has a particularly lame and outdated page on the wiki.
## Changelog
N/A
## About The Pull Request
reduces the cost of the planning subsystem. instead of calculating
able_to_plan on every fire for every mob, we only calculate it when a
mob queues/dequeues a behavior. also converts behavior lists into lists
rather than lazylists to reduce the amount of checks we do on process.
these are the differences after ran on tracy.
## Why It's Good For The Game
reduces the cost of ai planning subsystem
## Changelog
🆑
/🆑
## About The Pull Request
Over half of the line changes are merely from splitting the
fish_types.dm into several files since it was over 1k lines already.
One of the small issues with fishing right now is RNG. You want to get
some specific fish, and you go through all the micromanaging with hooks,
reels and baits only for the random number god to say "nope", and that's
only going to get worse the more fish are in the game.
However, I've a solution: (unconsumable/reusable) fishing lures, each of
which attracts different fish based on different conditions. The only
caveat is that they require to be spun at set intervals (usually 1 to 3
seconds, depending on the lure, with a second-long window). Worry not,
there're visual cues in the form of a green/red light hovering the
fishing float, so you won't get screwed up by the server slowing down or
whatever.
The whole box of lures (12 so far) can be from cargo for the fair price
of 450 credits.
I've also added 5 new fish: monkfish, plaice, pike, another punnier
variant of the pike, perch and squid. The latter is quite special
because of the ink production trait, which lets players use it to blind
others at a close range and when butchered, it yields an ink sac, which
can be processed into a can of squid ink (one less item exclusive to the
produce console), or thrown at people in a sort-of-similar fashion of
banana cream pies (except it's ink).
<details>
<summary>Images</summary>
Fishing lures (forgot to take my cursor off the veggie one before the
screenshot):
The five new fish:
</details>
<details>
<summary>A table of fish catchable wth each lure (excluding
holodeck)</summary>
</details>
A few more things in the CL, baitfish are a thing now.
## Why It's Good For The Game
There should be ways to contrast some of the RNG fishing has. After all,
it's only going to get more random the more fish are in the game.
Furthermore, I find it disappointing that a lot of food stuff is
exclusive to the ingredients console and there're no other ways to get
it.
## Changelog
🆑
add: Added fishing lures to the game. They don't get used up like baits
and let you catch specific kinds of fish, though they need to be spun
every few seconds. The whole set can be ordered from cargo for 450
credits.
balance: The magnet hook now removes dud chances.
add: Added five new fish types: perch, two types of pike, monkfish,
plaice and squid. Squids have a fairly special ink production trait,
which lets you use them (unless dead) to ink people face at close range,
and can be butchered for an ink sac, which can either be processed into
canned squid ink, or thrown at someone.
fix: Refactored throwing a little. Some items (specifically
components/elements) won't be triggered when caught. no more plates
shattering despite being caught for example.
add: Goldfish, lavaloops, needlefish and armorfish can now be used as
baits.
/🆑
