## About The Pull Request
I've refactored the FISH_SAFE_STORAGE trait into an element, mainly
because there were a few problems with how it worked: It wasn't stopping
hunger from raising, ditto with the breeding wait, and it offered no
healing whatsoever, which I find kind of a bummer. The new element will
keep the fish from getting any hungrier or ready to reproduce and will
heal them up to 65% of their base health.
Also, I've added a new bluespace fish case as a techweb design, found
along with other stuff in the advanced fishing node, though if you want
I can move it to a bluespace node. This should make it possible to
reasonably store and carry around larger fish.
Examining a fish will no longer give out readings on weight and size if
you haven't at least attempted fishing once (you can get to novice level
in less than a minute). While examining a fish with apprentice level or
higher will also give readings on the general conditions of the fish (is
it starving? drowning? has it lost a considerable chunk of health?). The
fishing skillchip also gives you these traits.
I've also converted two fish variables into traits, because fish have
waaaay too many variables. and gave some topdown shading to the
pre-existing fishbox sprite.
## Why It's Good For The Game
## Changelog
🆑
add: Added a bluespace fish case to the advanced fishing node.
balance: Fish cases will keep a fish from getting hungrier or ready to
reproduce, while also healing it up to 65% health.
balance: Examining a fish with zero fishing skill whatsoever won't give
a reading on its size and weight. Conversely, examining one with the
skill leveled two times will give general information on if it's
starving, sick, hungry, or dead.
/🆑
## About The Pull Request
Turns
`ON_WALL_LAYER`
into
`FLAT_ON_WALL_LAYER`
`ON_WALL_LAYER`
`HIGH_ON_WALL_LAYER`
Where `FLAT_ON_WALL_LAYER` is meant for lower-priority wall mounts like
signs and posters
`ON_WALL_LAYER` is default
and `HIGH_ON_WALL_LAYER` is for stuff that "hang over" the wall
Also makes the incident display actually wall mounted
## Why It's Good For The Game
I noticed this while doing mapping and I thought it was a really cool
effect
Unfortunately this effect was a coinflip because all wall mounts were on
the same layer. Sometimes it'd look like this
So this allows us to do this kinda stuff consistently.
Also has the added effect of letting us "de-prioritize" stuff like
posters, so we can hang stuff *over* posters and signs, which could be
useful.
## Changelog
🆑 Melbert
qol: Some wall mounts will now consistently layer over others (light
switches and cameras, notably, should always layer above other mounts
like signs and status displays)
/🆑
## 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.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
Hello everybuddy, your number three rated coder-failure here to clean up
some mess. This PR accomplishes some of the more major structural clean
up changes I wanted to do with /obj/ folder, but decided to wait on
until wallening gets merged, and so, time has come. Several things to
still be done, although I know these cleaning PR's are quite a load, so
will wait for this one to get done with first.
## Why It's Good For The Game
Saner spriters, better sprites, less annoyance. Also deleted a whole
load of redundancy this time around, a lot of sprites which existed
simultaniously in two places now got exit their quantum superposition.
## About The Pull Request
Sooooooo this one's a mess.
First off, layering issues. Pipes, cables, and disposals currently
render over catwalks!
That's not great.
Looking into it, it seems we've moved the `CATWALK_LAYER` below the
`ABOVE_OPEN_TURF_LAYER`, where the catwalk layer is used for closed
catwalks.
33e983ced1/code/__DEFINES/layers.dm (L148-L150)
Which, well, we've *also* made it so all `undertile` stuff gets rendered
at `ABOVE_OPEN_TURF_LAYER` when below a tile.
So! Naively! We swap those around! Easy peasy lemon squeezy.
```dm
#define ABOVE_OPEN_TURF_LAYER (12 + TOPDOWN_LAYER)
#define CATWALK_LAYER (13 + TOPDOWN_LAYER)
```
And hey! Well!
It's progress!
But as we can see in the bottom right catwalk tile, something's not
rendering right when they're below the tile...
Well, time to take a closer look at our `undertile` element... aaaaaand
would you look at that:
74f9a43141/code/datums/elements/undertile.dm (L45-L48)
We're setting EVERYTHING to the `FLOOR_PLANE` at
`ABOVE_OPEN_TURF_LAYER`, even the stuff that was already on
`FLOOR_PLANE` with its own layer like disposals or cables.
Meaning, layering fuckery ensues, we can't see shit.
So? We just make it only do that when we're not already on the floor
plane.
```dm
if(PLANE_TO_TRUE(source.plane) != FLOOR_PLANE)
SET_PLANE_IMPLICIT(source, FLOOR_PLANE)
source.layer = ABOVE_OPEN_TURF_LAYER
```
This solves it!
Progress!
...Kind of.
The _layering_ is solved, but unscrewing and rescrewing them seems to
cause pipe caps to manifest out of nowhere!
This _sucks_ for debugging, y'know?
Anyhow, this is based on two different things: an order of operations
issue and catwalks just not being accounted for.
First off! Order of operations.
On `Initialize(...)`, the base `/obj/machinery/atmospherics` registers a
proc that updates pipe caps on `COMSIG_OBJ_HIDE`:
33e983ced1/code/modules/atmospherics/machinery/atmosmachinery.dm (L114-L115)
Meanwhile, `/obj/machinery/atmospherics/pipe`, adds the `undertile`
element on its `Initialize(...)`... AFTER calling the parent.
33e983ced1/code/modules/atmospherics/machinery/pipes/pipes.dm (L31-L35)
...Which then registers its own proc on `COMSIG_OBJ_HIDE`...
74f9a43141/code/datums/elements/undertile.dm (L26)
This meant that, well, the proc that generates the caps was being called
*before* undertile had a chance to chance to remove the
`TRAIT_UNDERFLOOR` trait... which pipe caps use to work out when to
generate.
33e983ced1/code/modules/atmospherics/machinery/atmosmachinery.dm (L650-L652)
So, we swap this around by moving both to a `setup_hiding()` proc which
allows the pipe to register its behaviours before calling the parent and
it register its, without needing to register it before calling the
parent `Initialize(...)`. Cause that's ugly.
Now we're generating pipe caps on catwalks!
But! That brings us perfectly to the next bit. Cause those pipe caps,
even if shown when the tile is open, look *ugly*.
Why, when we open a catwalk, are we having our pipes suddenly extend
onto the neighbouring tiles and catwalks and going down into them from
the top? Arguably, these should behave like they're below tiles, because
they logically are even if not technically so.
Well, actually, we already have a similar situation with bare plating.
It's not applying `TRAIT_UNDERFLOOR`, but also the pipe caps shouldn't
be behaving like they're above a tile, because that'd be ugly- and
that's what it does!
33e983ced1/code/modules/atmospherics/machinery/atmosmachinery.dm (L654-L655)
So, we just apply a second check there, `iscatwalkturf(...)`
```dm
var/turf/node_turf = get_turf(node)
if(isplatingturf(node_turf) || iscatwalkturf(node_turf))
continue
```
And? Well!
There we go! There's no weird layering, there's no pipe caps where there
shouldn't be, pipes behave like those on catwalks are actually under a
tile.
It looks _clean_.
...
Well, for however clean we can get it to be without making sprites for
the opened catwalks but without the integrated plating so we can make an
overlay and have the pipes/cables/disposals not spontaneously go over
the edges of the catwalk when opened. Or making the under sprites only
have the attachment points in the corners, so it looks like the
pipes/cables/disposals are going over plating instead of what looks like
a raised edge.
## Why It's Good For The Game
Fixes#84789.
Fixes#82622.
Screwing open a catwalk suddenly generating pipecaps on neighbouring
closed catwalks and tiles with pipes under them looks weird.
## Changelog
🆑
fix: Fixed pipes/cables/disposals rendering above closed catwalks.
fix: Fixed catwalks covering pipes generating illogical pipe caps when
screwed.
fix: Opened catwalks are no longer assumed to be above-floor for the
sake of generating pipe caps.
/🆑
## What's going on here
Kept you waitin huh!
This pr resprites most all walls, windows and other "wall adjacent"
things to a 3/4th perspective, technical term is "tall" walls (we are
very smart).
If you're trying to understand the technical details here, much of the
"rendering tech" is built off the idea of split-vis. Basically, split a
sprite up and render it on adjacent turfs, to prevent seeing "through"
walls/doors, and to support seeing "edges" without actually seeing the
atom itself.
Most of the rest of it is pipelining done to accommodate how icons are
cut.
## Path To Merge
Almost* all sprites and code is done at this point.
There are some things missing both on and off the bounty list, but that
will be the case forever unless we force upstream (you guys) to stop
adding new shit that doesn't fit the style.
I plan on accepting and integrating prs to the current working repo
<https://github.com/wall-nerds/wallening> up until a merge, to make
contribution simpler and allow things like bounties to close out more
easily
This pr is quite bulky, even stripping away map changes it's maybe 7000
LOC (We have a few maps that were modified with UpdatePaths, I am also
tentatively pring our test map, for future use.)
This may inhibit proper review, although that is part of why I am
willing to make it despite my perfectionism. Apologies in advance.
Due to the perspective shift, a lot of mapping work is going to need to
be done at some point. This comes in varying levels of priority. Many
wallmounts are offset by hand, some are stuck in the wall/basically
cannot be placed on the east/west/north edges of walls (posters), some
just don't look great good in their current position.
Tests are currently a minor bit yorked, I thought it was more important
to get this up then to clean them fully.
## What does it look like?
## Credits
<details>
<summary>Historical Mumbojumbo</summary>
I am gonna do my best to document how this project came to be. I am
operating off third party info and half remembered details, so if I'm
wrong please yell at me.
This project started sometime in late 2020, as a product of Rohesie
trying to integrate and make easier work from Mojave Sun (A recently
defunct fallout server) with /tg/.
Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man
is insane) was working with tall walls, IE walls that are 48px tall
instead of the normal 32. This was I THINK done based off a technical
prototype from aao7 proving A it was possible and B it didn't look like
dogwater.
This alongside oranges begging the art team for 3/4th walls (he meant
TGMC style) lead to Rohesie bringing on contributors from general /tg/,
including actionninja who would eventually take over as technical lead
and Kryson, who would define /tg/'s version of the artstyle. Much of the
formative aspects of this project are their work.
The project was coming along pretty well for a few months, but ran into
serious technical issues with `SIDE_MAP`, a byond map_format that allows
for simpler 3/4th rendering.
Due to BULLSHIT I will not detail here, the map format caused issues
both at random with flickering and heavily with multiz.
Concurrent with this, action stepped down after hacking out the
rendering tech and starting work on an icon cutter that would allow for
simpler icon generation, leaving ninjanomnom to manage the project.
Some time passed, and the project stalled out due to the technical
issues. Eventually I built a test case for the issues we had with
`SIDE_MAP` and convinced lummox jr (byond's developer) to explain how
the fuckin thing actually worked. This understanding made the project
theoretically possible, but did not resolve the problems with multi-z.
Resolving those required a full rework of how rendering like, worked. I
(alongside tattle) took over project development from ninjanomnom at
this time, and started work on Plane Cube (#69115), which when finished
would finally make the project technically feasible.
The time between then and now has been slow, progressive work. Many many
artists and technical folks have dumped their time into this (as you can
see from the credits). I will get into this more below but I would like
to explicitly thank (in no particular order) tattle, draco, arcanemusic,
actionninja, imaginos, viro and kylerace for keeping the project alive
in this time period. I would have curled up into a ball and died if I
had to do this all myself, your help has been indispensable.
</details>
<details>
<summary>Detailed Credits</summary>
Deep apologies if I have forgotten someone (I am sure I have, if someone
is you please contact me). I've done my best to collate from the git
log/my memory.
Thanks to (In no particular order):
Raccoff: Being funny to bully, creating threshold decals for airlocks
aa07: (I think) inspiring the project
ActionNinja: Laying the technical rock we build off, supporting me
despite byond trying to kill him, building the icon cutter that makes
this possible
ArcaneMusic: Artistic and technical work spanning from the project's
start to literally today, being a constant of motivation and positivity.
I can't list all the stuff he's done
Armhulen: Key rendering work (he's the reason thindows render right), an
upbeat personality and a kick in the ass. Love you arm
Azlan: Damn cool sprites, consistently
Ben10Omintrix: You know ben showed up just to make basic mobs work, he's
just fuckin like that man
BigBimmer: A large amount of bounty work, alongside just like, throwing
shit around. An absolute joy to work with
Capsandi: Plaques, blastdoors, artistic work early on
CapybaraExtravagante: Rendering work on wall frames
Draco: SO MUCH STUFF. Much of the spritework done over the past two
years is his, constantly engaged and will take on anything. I would have
given up if not for you
Floyd: Early rendering work, so early I don't even know the details.
Enjoy freedom brother
Imaginos16: A guiding hand through the middle years, handled much of the
sprite review and contribution for a good bit there
Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of
effort dissecting feedback with a focus on making things as good as they
can be at the jump
Infrared: Part of the impetus for the project, made all the xenomorph
stuff in the MS style
Jacquerel: A bunch of little upkeep/technical things, has done so much
sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES)
Justice12354: Solved a bunch of error sprites (and worked out how to
actually make prs to the project) Thanks bro!
Kryson: Built the artstyle of the project, carrying on for years even
when it was technically dying, only stopping to casually beat cancer. So
much of our style and art is Kryson
KylerAce: Handled annoying technical stuff for me, built window frame
logic and fully got rid of grilles.
LemonInTheDark: Rendering dirtywork, project management and just so much
fucking time in dreammaker editing sprites
Meyhazah: Table buttons, brass windows and alll the old style doors
Mothblocks: Has provided constant support, gave me a deadline and
motivation, erased worries about "it not being done", gave just SO much
money to fill in the critical holes in sprites. Thanks moth
MTandi: Contributed art despite his own blackjack and hookers club
opening right down the road, I'm sorry I rolled over some of your
sprites man I wish we had finished earlier
Ninjanomnomnom: Consulted on gags issues, kept things alive through some
truly shit times
oranges: This is his fault
Rohesie: Organized the effort, did much of the initial like, proof of
concept stuff. I hope you're doin well whatever you're up to.
san7890: Consulting on mapper UX/design problems, being my pet mapper
Senefi: Offsetting items with a focus on detail/the more unused
canidates
SimplyLogan: Detailed map work and mapper feedback, personally very kind
even if we end up talking past each other sometimes. Thank you!
SpaceSmithers: Just like, random mapping support out of nowhere, and
bein a straight up cool dude
Tattle: A bunch of misc project management stuff, organizing the
discord, managing the test server, dealing with all the mapping bullshit
for me, being my backup in case of bus. I know you think you didn't do
much but your presence and work have been a great help
Thunder12345: Came out of nowhere and just so much of the random
bounties, I'm kind of upset about how much we paid him
Time-Green: I hooked him in by fucking with stuff he made and now he's
just doin shit, thanks for helping out man!
Twaticus: Provided artistic feedback and authority for my poor feeble
coder brain, believed in the project for YEARS, was a constant source of
❤️ and affirmation
unit0016: I have no god damn idea who she is, popped out of nowhere on
the github one day and dealt with a bunch of annoying
rendering/refactoring. Godspeed random furry thank you for all your
effort and issue reports
Viro: A bunch of detailed spriting moving towards 3/4ths, both on and
off the wallening fork. If anyone believed this project would be done,
it was viro
Wallem: Artistic review and consultation, was my go-to guy for a long
time when the other two spritetainers were inactive
Waltermeldon: Cracked out a bunch of rendering work, he's the reason
windows look like not dogwater. Alongside floyd and action spent a TON
of time speaking to lummox/unearthing how byond rendering worked trying
to make this thing happen
ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin
bugaboo that was living in my brain like it was nothing. Love you
brother
And finally:
The Mojave Sun development team. They provided a testbed for the idea,
committed hundreds and hundreds of hours to the artstyle, and were a
large reason we caught issues early enough to meaningfully deal with
them. Your work is a testament to what longterm effort and deep detailed
care produce. I hope you're doing well whatever you're up to. Go out
with a bang!
</details>
## Changelog
🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan,
Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd,
Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson,
KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom,
oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner,
SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016,
Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team!
add: Resprites or offsets almost all "tall" objects in the game to match
a 3/4ths perspective
add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: = <stewartareid@outlook.com>
Co-authored-by: Capsandi <dansullycc@gmail.com>
Co-authored-by: ArcaneMusic <hero12290@aol.com>
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com>
Co-authored-by: KylerAce <kylerlumpkin1@gmail.com>
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com>
Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com>
Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com>
Co-authored-by: tattle <article.disaster@gmail.com>
Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com>
Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com>
Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com>
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com>
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
Co-authored-by: Rob Bailey <github@criticalaction.net>
Co-authored-by: MMMiracles <lolaccount1@hotmail.com>
## About The Pull Request
refactors pet behaviors, such as collars and pet cultists into elements.
also this is a first step to completely removing the pet subtype
## Why It's Good For The Game
this means itll be alot easier for coders to make their tameable mobs
able to wear pet collars without having to make them of the pet subtype,
which i also plan to do
## Changelog
🆑
refactor: refactors pet collars and cultist pets into elements
/🆑
## About The Pull Request
on_hit_effect is now an element, which uses signals instead of
callbacks.
## Why It's Good For The Game
Easy peasy almost lemon squeezy. It's a good thing that I had made the
AddElementTrait proc so we can manage multiple sources of a common
element. It's much better to use signals than callbacks for components
and datums with several possible sources, kinda like how it's been donw
with the relay_attackers element.
## Changelog
N/A
## About The Pull Request
Lobstrosities can now be raised from aquarium icemoon/lavaland chrabs.
First of all, you've to get a live chrab, an aquarium, and some fish
feed. Second, you place the chrab inside the aquarium and turn the
'allow breeding' settting on (should probably rename it to a more apt
name now). Keep the chrab well fed, and possibly with some friends and
props in the same aquarium until it develops into a hopefully calm
juveline lobstrosity and plops out of the aquarium (it can take some
time). From there you can tame it by feeding it its favorite food: arms
and lavaloop fish, and wait another dozen minutes for it to mature into
a fully grown lobstrosity.
Juveline lobstrosities are basically smaller and weaker lobstrosities,
if not slightly faster in some ways. Unlike their taller counterparts,
they can be tamed. Once done so, they'll retain their tamedness once
grown up. Regardless, tamed lobstrosities can be given the pet command
to fish for things by pointing at them. Thanks BenMatrix for the
profound fisher component, woo.
The chrab's weigth and size influence the growth speed of the first
stage faster, meaning bigger chrabs (may require crossbreeding) will
turn into juveline lobstrosities quickly. Amongst other things
influencing the resulting mob are fish traits:
Several traits have been given effects that apply to the mob, such as
nocturnal regeneration, being venomous or being able to fly akin space
carps. Also a new one that prevents the resulting lobstrosity from fully
developing
Now tested.
## Why It's Good For The Game
I'm building upon fishing and aquarium stuff, which has been an interest
of mine in a good while, though most of it doesn't have that many
practical uses, I'm slowly trying to make it cooler, and chasm chrabs
growing into lobstrosities is pretty much in line with the fluff texts
for the fish.
Eventually I'll have to add tips inside fishing toolboxes, otherwise
people won't know even half of it.
## Changelog
🆑
add: You can raise lobstrosities from chasm chrabs inside an aquarium
with the 'allow breeding' setting on. Keep the fish well fed, healthy
and not lonely if you don't want an hostile one.
add: Juveline lobstrosities (from chasms, plasma rivers, or aquariums,
xenobio too) can be tamed with arms and lavaloop fishes.
add: For lobstrosities grown from aquariums, they can have additional
effects based on the fish traits they had in the aquarium, like being
venomous or even flying.
/🆑
## About The Pull Request
Iansdoor suggested this to me earlier (but I already knew it was a thing
on Goon), and I said ok. Basically, this PR adds an interaction between
explosions and fishing.
At the cost of potential collateral damage, you can too now use a TTV to
catch a lot of fishes (and other stuff). Fish spawned this way will be
pretty much dead however.
This PR also adds the examine tips already presents in the fishing spot
component to the lazy fishing spot element.
## Why It's Good For The Game
This PR adds an interaction between fishing and other mechanics of the
game.
## Changelog
🆑
add: You can now fish with explosives.
fix: Fixed an inconsistency with examining fishing spots with
sufficiently high fishing skill (or skillchip).
/🆑
## About The Pull Request
Added dehydrator, a machine version of drying rack.
Replaced the second fryer with this rack on some maps to be available
roundstart.
Also changed the colors of Smart Fridge to be more in line with other
kitchen appliances.
## Why It's Good For The Game
We have plenty of recipes requiring dried items, and it's silly that the
chef has to break down a cafeteria table to build a rack for regular
recipes.
## Changelog
🆑
add: Dehydrator, a machine version of drying rack, with a circuit board
and available on some kitchens roundstart.
image: Updated the color palette of Smart Fridge
/🆑
## About The Pull Request
it's - conjunction of "it" and "is"
its - possessive form of "it"
grammar is hard, and there were a lot of places where "it's" was used
where it shouldn't have been. i went and painstakingly searched the
entire repository for these instances, spending a few hours on it. i
completely ignored the changelog archive, and i may have missed some
outliers. most player-facing ones should be corrected, though
## Why It's Good For The Game
proper grammar is good
## Changelog
🆑
spellcheck: Numerous instances of "it's" have been properly replaced
with "its"
/🆑
## About The Pull Request
Balances
- Stops voidwalkers from breaking glass at all, and throwing items
Voidwalkers started using spears to break electrified windows to space
area's. Throwing bypasses too many safety checks, and shouldn't be their
main means of combat either way
- No hitting anyone in crit
Voidwalkers were using weapons to try and kill as many people as
possible without kidnapping
- Only able to pull people
Voidwalkers were dragging bags around with a personal armory. It also
just looks goofy as hell
- Increases space dive enter to 3 seconds (from 2) and decreases space
dive exit (from 2 seconds to 1)
The original value was pretty fast, and is being used to slip out of
combat if anyone ever comes after them. This is intended to a certain
degree, but it was a bit too strong
- Void Eater becomes blunt during use, needs kidnappings to refresh
Yeah... For some it's being used as a murderbone antag, forgoing
kidnappings completely. This change makes murderboning significantly
more difficult without bothering good faith players. It goes from 25
damage to 15 in 0.5 damage increments.
This slightly decreases take-down potentially against people with
low-mood, but clicks that go SCRUNGE release dopamine so it balances
- Gives voidwalkers chunkyfingers, preventing stun baton and gun use
Voidwalker originally had this, but I figured I'd keep it out to give
people to freedom to be more opportunistic in combat, but a significant
portion defaulted to getting a stunbaton as quick as possible so they
could avoid engaging in actual combat
- Removes eye slots
They're already flash immune. People don't know this so they're all
rushing sunglasses. It just looks weird when the space monster is
wearing glasses :/. They can still wear scarves if they decide to be
fashionable
- Void eater applies 10s of NODEATH
Yeah fuck it why not? It also prevents succumbing and takes out a lot of
cheese
- Removed Voidwalker armor
They had 10% brute and 20% burn armor. I didn't really think much about
the original change, figured they'd be too weak otherwise, but turns out
they're sufficiently strong and this kinda deviates from the intended
"ambush antag" by making them stronger in sustained combat
- Voided go to a safe turf instead of a random one
Actually just a mistake on my part. Dumping mute people in the turbine
plasma burn chamber is cruel, even for a coder
Fixes
- The Unsettle ability line of sight didn't check for line of sight :/
Addition:
- Gives Voidwalker telepathy. I originally kept it out because whatever
but honestly I think it's fine and gives them the chance to communicate
if they ever need to. I've also given the abilities it's own sprite and
background cause good vibes
## Why It's Good For The Game
The original testmerges I spectated went very well! I had it testmerged
on Terry and the rounds where I observed were played in very good faith
and played a spooky antag incredibly well. I've also seen others play
incredibly fun rounds!
It seems to have gone downhill a bit though (or Terry is high-RP?). I've
observed a few rounds on other servers and the way it's played is not
great. I originally kept as little handrails as I could as to give
people the most freedom possible in playing the spooky antag, but some
people dissappoint me so, so incredibly deeply.
It's just been merged but I'm already seeing players ignoring kidnap
mechanics in favor of roundremoving as many people as possible, giving
up any semblance of stealth in favor of carrying around mini armories.
Another spent it's time breaking windows to vent as much of the station
as possible. I also knew it would happen, but not this much. I probably
should've had this PR up a bit sooner but I've gotten really into
Hardrock TerraFirmaCraft (seriously it's _sooo_ good).
I can keep going "Argh, players!!" but honestly I've been incredibly
naive. These set of balance changes set out to cripple gameplay
optimizers while leaving good faithed players unaffected for the most
part, bringing it closer to the original design doc I wrote and away
from just being another murderbone machine
## Changelog
🆑
add: Gives voidwalker telepathy
fix: Fixes the Unsettle ability ignoring line of sight (which was it's
sole gimmick, im just dumb)
balance: Voidwalkers cannot break windows anymore or throw objects
balance: Voidwalkers can no longer harm people in crit
balance: Voidwalkers can only pull mobs
balance: Voidwalkers' space dive enter has been increased by 1 seconds,
but dive exit decreased by 1 second
balance: Void eater becomes blunt during use. Kidnap people to refresh
it
balance: Removes voidwalker glasses slot
balance: Gives voidwalkers chunky fingers
balance: Voidwalker applies NODEATH on hit
balance: Voided victims get dumped in safer places
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
Fixes that one alien feature that uses mouse drag
Honestly I really hate this fix, I think strippable should be
non-blocking, or alternatively, strippable should have some proc
`should_strip` to prevent people from opening the ui in some contexts.
But whatever
## Changelog
🆑 Melbert
fix: Fixes xenos being able to do that one mechanic that involves
mouse-dragging people to you
/🆑
## About The Pull Request
Currently if you want to apply a HUD you usually add both its trait and
the HUD itself. Only exceptions are things like simplemobs where you
should avoid adding the hud trait since it adds security/med DB access
and such, but there is no cases where you'd want to apply the trait and
not apply the hud.
Requested by Melbert about a week ago.
## Why It's Good For The Game
This makes working with HUDs significantly easier, as you no longer have
to bother with manually adding/removing them. Also potentially removes
an edge case where if your hud could get removed while keeping the
trait.
## Changelog
🆑
refactor: HUD traits now apply their corresponding hud automatically
/🆑
## About The Pull Request
Tin, should fix the following hard del and prevent similar instances:
There was nothing stopping something that was qdeleted from potentially
being 'immersed' which is definitely not something that we ever want to
be happening.
## Why It's Good For The Game
Spurious CI failures are annoying
## Changelog
Nothing player facing
## About The Pull Request
I was investigating a bug with hulk in which using it while damaged
doesn't put you back on full speed
I noticed `TRAIT_IGNOREDAMAGESLOWDOWN` on its own was subtly broken, in
that it did nothing if the user did not call `updatehealth` afterwards
And guess what, most (if not all) uses of the trait did not do this, so
it never applied correctly
So I nuked the trait entirely, made all uses of it use the same thing
morphine uses (`/datum/movespeed_modifier/damage_slowdown`)
And since I was auditing this I saw the ball module was broke, it
removed the immunity but never added it. Quick fix
I also cleaned up some Hulk stuff while I was in the area because I was
in the area. I removed all instances of `check_mutation` and replaced it
with trait checking because it made more sense.
I also also fixed a bug with the simple flying element never removing on
detach because I touched something that uses it for the above change.
## Changelog
🆑 Melbert
fix: Using hulk (and a myriad of similar effects) now properly updates
your movespeed to ignore the damage movespeed penalty
fix: Some things which temporarily make you fly don't make you fly
forever
fix: MODsuit ball module now properly makes you immune to damage
movespeed penalty when in ball form
fix: Adding Hulk via VV dropdown doesn't default to adding the strongest
hulk available (that which is used by the medieval pirates)
/🆑
## About The Pull Request
I may have forgotten a return which was overlooked in reviews, and
get_embed could fail if an object without an embed_type (shrapnel) got
assigned embed. Also optimized generate_with_values to not recreate the
datum if its not the "default" one.
## Changelog
🆑
fix: Embedding now properly changes its values.
/🆑
## About The Pull Request
This refactors embedding elements to make them use singleton datums
(similarly to armor) instead being bespoke and creating a new element
every time armor values are supposed to be adjusted.
Default values have been removed from defines due to now being declared
in base class itself.
Additionally fixes vending machines and tackling gloves setting
generated shards (which they instantly embed into their victim) embed
properties to null after running the embedding code, despite said shards
having non-null embedding values by default, making them not be able to
embed into anyone else, also potentially breaking the pain/jostling code
if they somehow get updated.
## Why It's Good For The Game
Current embedding system is an unnecessarily complicated mess as bespoke
elements are hard to work with, and creating a new element every time
you change values is hacky at best. This change should make it easier to
read and work with.
## Changelog
🆑
fix: Fixed glass shards generated from falling vending machines or
tackling windows not being able to embed into anyone.
refactor: Refactored embedding code to use datums instead of bespoke
elements and ugly associated lists.
/🆑
## About The Pull Request
Apparently I've left out that `isopenspaceturf(A)` returns false on
normal (not multi-z) space turfs because they're of a different path.
This should fix the fact you can use hoverboards as a substitute
jetpacks, which wasn't intended. You can still use them in space if
there's lattice/catwalk underneath, or another kind of turf on the
z-level below however.
## Why It's Good For The Game
Unintended bit from the skateboard buff PR I had made months ago.
## Changelog
🆑
fix: Hoverboards properly dysfunction in space without any kind of
support underneath them.
/🆑
## About The Pull Request
Converts slapcrafting into a bespoke element, used to be ac omponent
## Why It's Good For The Game
Noticed this was a big C and realized there was no real reason for that.
It's the same recipe shared across different items.
## Changelog
N/A
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Ok so like, side map right? It makes things higher up in the world
render above things lower down in the world.
Most of the time this is what we want, but it is NOT what we want for
floors.
Floors are allowed to be larger then 32x32, and if they are we want them
to render based off JUST their layer.
If we don't allow this grass turfs and others get cut off on their
bottom edge, which looks WEIRD.
In order to make this happen, we can add TOPDOWN_LAYER to every layer on
the floor plane and disable sidemap.
I've added documentation for this to VISUALS.md, and have also
implemented unit test errors to prevent mixing TOPDOWN layers with non
topdown planes (or vis versa).
This new test adds ~1 second to tests, which is I think a perfectly
scrumpulent number.
EDIT:
I nerd sniped myself and implemented sidemap layering and lighting for
cameras (also larger then 32x32 icon support for getflat)
The lighting isn't perfect, we don't handle things displaying in the
void all that well (I am convinced getflat blending is broken but I have
no debugger so I can't fix it properly), but it'll do.
This came up cause I had to fix another layering issue in cameras and
thought I might as well go all in.
## Why It's Good For The Game
Old:
New:
## Changelog
🆑
fix: Grass turfs will render properly now. Reworked how floors render,
please report any bugs!
fix: Cameras now properly capture lighting
fix: The layering seen in photos should better match the actual game
/🆑
## About The Pull Request
The title barely does justice to the content.
This PR turns a snowflake, neigh-unused, broken feature for glasses into
a rock-hard, functional, badass feature which can be applied to any
item, and also brings back the halloween screen tint, inside the pumpkin
hardhat, and also a polaroid tint for the helmet of the flash suit,
because the define was just there, unused.
for reference, the normal brightness/saturation is somewhere in the
middle. Also the pumpkin hardhat's effect is only there when it's lit
## Why It's Good For The Game
Less hardcoded implementation of the client colours for items, which
also doubles as a fix because the old code was checking for the trait on
the mob but was adding it to the item.
## Changelog
🆑
fix: Fixed toggleable screen colors for glasses.
code: De-hardcoded, refactored the above, now-fixed feature.
add: Pumpkin hardhats and the hood of the flash suit now affect the
color of your screen.
add: Prism glasses, obtainable through xenobiology crossbreeding, now
also affect the color of your screen.
/🆑
## About The Pull Request
Facehuggers dont make people fall asleep, instead making them unable if
on (already was in), and muffling speech
Xenomorphs still have decent tools to stun people in melee thats stuff
for another pr
muzzle is now an element and also just makes you talk like
word word word -> mmmmf mmmf mf
COMPLETELY evaporates BLOCKS_SPEECH flag
## Why It's Good For The Game
Being instantly sent to sleep by a facehugger thrown the hunter that
materialized from a vent then getting dragged to their goon cave where
you spend 2 minutes to get gibbed so someone else but you can play antag
is just extremely unfun
This should allow you to survive if youre quick enough after getting
hugged instead of being forced to get gibbed, allowing cooler xenomorph
combat (you could try fistfighting the dude or something idk)
## About The Pull Request
Mecha guns actually utilize random spread while firing if ``randomspread
= TRUE``. Currently every weapon that isn't the shotguns are always
pinpoint even if they would have variance.
Makes bumpsmash and melee attacks in a mech use the same cooldown. The
actual speed between bumpsmash melees are the same as before (once every
0.3 seconds) and click melee is the same as well (once every second).
However, if you do one or the other, it will put you on cooldown for
both. The reason for this is that they're literally just calling the
same proc but not respecting each others cooldowns. So we've
consolidated this into one cooldown with varying cooldown timers. I
don't even think this is the most elegant solution, but I'm not going to
make any radical changes of the structure of the code. Fuck that.
**Edit** I forgot to mention this but you have to be in combat mode to
bumpsmash as a consequence of the above changes. You're fucking welcome.
Separates out mecha_melee_attack proc on the ``/obj/`` level to instead
only ``/obj/structure`` and ``/obj/machinery``, which is the only things
we should be attacking in the /obj/ list. I don't even want to know what
mechs have been able to punch while this wasn't the case. Probably
nothing they should have.
## Why It's Good For The Game
Mechs are a fucking diabolical nightmare of procs and some truly ancient
code. Over time, things have gotten worse, as we have no one really
actively maintaining some of this consistently. One of these bugs is
literally day of mech implementation. I shit you not.
## Changelog
🆑
fix: Mecha weaponry is capable, for the first time ever, of experiencing
recoil. This was an intended mechanic, I promise. The code just
literally never worked.
fix: Mecha bump melee attacks and click melee attacks are now on the
same cooldown, but have varying cooldown timers. You will always bump
attack faster than you will click.
fix: You must be in combat mode to punch objects and to bumpsmash into
objects.
fix: Stops mecha being able to punch literally any object and damage
them.
code: Tidies up some of the autodoc comments for mech weapons.
/🆑
## About The Pull Request
This PR was originally meant as a replacement for the Bloody Bastard
blade, but then I stopped existing for 7 months. Now that I'm here
again, I'm finishing the job once and for all.
### **HERETICS VERSUS CULTISTS**
### Heretics
Heretics can now sacrifice cultists, which will give them one of three
gifts: The Cursed Blade, the Crimson Focus, and the Rusted Harvester.
The gifts given are weighted to be spread out equally with each type.
They will also gain one knowledge point.
- The Cursed Blade is a free heretic blade that is more powerful than
the normal heretic blade, including a small block chance. It can also be
used to draw heretic runes off combat mode.
- The Crimson Focus is a necklace that grants focusing and a minor
regeneration effect which also affects nearby heretics, at the cost of
gaining the BLOODY_MESS trait while wearing it. Additionally, it can be
squeezed to heal 50 points of brute/burn damage, injecting yourself with
three to six (separately) units of Eldritch ~~Water~~ Essence and Unholy
Water. Yes, this isn't good.
- The Rusted Harvester is a heretic 'monster' summon. It's a normal
Harvester, but instead of Area Conversion and Forcewall, it has
Aggressive Spread and Rust Construction (Raise Wall). It can delimb, but
only cultists, with a delay. It has an aura of decay, corroding the
environment and withering enemies near it, but it's VERY fragile.
Rusting cultist item dispensers will now cause them to turn into a
Heretic object. Altars turn into small heretic runes, Archives turn into
Codex Cicatrixi, Forges turn into Mawed Crucibles.
Ideally, Heretics would be able to gain an amount of these new powers
and use them to turn the tide against the cultists, amassing their power
and almost forming a sect of their own in turn which sweeps over and
converts the cult.
### Cultists
When a Cultist sacrifices a heretic, two things will happen:
- A new item will be available for creation at one of the dispensers.
- The Heretic will be trapped inside a powerful Haunted Blade.
`/obj/item/melee/cultblade/haunted`
` name = "haunted longsword"`
` desc = "An eerie sword with a blade that is less 'black' than it is
'absolute nothingness'. It glows with furious, restrained green
energy."`
This blade will be stronger across-the-board than a normal cult sword,
and will even allow those who wield it to cast one heretic spell from
their previous path. The only downside? The heretic can also cast one
spell. It's up to the trapped spirit if it wants to help you, or be a
nuisance.
The unlocked items are:
- The Cursed Blade, again. For cultists, it can be used to draw runes
twice as fast as usual, and they can even right-click it to teleport to
safety, just like a heretic!
- The Crimson Focus, again. Cultists are twice as fast at carving spells
into their body, and they gain a 5th spellslot as long as they wear the
amulet. It still causes hemophilia and grants weak regeneration.
- The Proteon Orb. This orb will create a gateway to Nar'sie's own
realm, spawning one Proteon every 15 seconds, which ghosts can possess.
The gateways cannot be placed close to one another.
Originally, they were going to be able to create a Harvester Shell, but
there were some concerns of it being too OP.
The true Bastard sword has been fully deleted. The null rod conversion
has been changed to a Bloody Halberd instead.
I'm considering re-enabling Stun Hand on Heretics, with Mansus Grasp
stats.
### Other
All the items above can be used by both Heretics and Cultists, no matter
how they were first created. Hell, even normal crew can use them! This
is probably not the best idea a lot of the time, though.
There are a lot of other changes in this PR. A loooooot. I will likely
miss some in the changelog, but I'll try to be as thorough as possible.
There's probably also some leftover garbo that I didn't find and clear
out yet.
## Why It's Good For The Game
Cult and Heretics, despite being mortally opposed, have very few
interactions with eachother, especially now that the Blade's gone. The
only thing of note is just the Heretic's unfair complete resistance to
stun hand, which is only marginally better than the alternative. This PR
will reintroduce their animosity, and give both sides a very, very good
reason to fight eachother.
The Cult will gain a sick sword that keeps the heretic in the game, and
unlike with the original implementation, will recieve a cult-wide bonus
in the form of a powerful, well deserved, and fun new item to summon.
The Heretic will gain powerful trinkets and knowledge from the
sacrifices, incentivizing them to become a terrifying cult-hunter. And
if they do succeed in wiping out the cult, they will have quite the
rewards to help with their ascension.
The crew, while mostly unaffected, will have a damn good reason to not
just Side with the heretic, out of fear of what they may become after
the cult is stomped down. They can also use a few of the items here in
an attempt to get one up on either side, as long as they manage to stay
clear of the side-effects.
Let the heretics eradicate the apostates.
Let the cultists root out the heathens.
The haunted longsword creates an aura of darkness (disabled for the
cultist for the image)
Sprites... are not great. Hopefully someone comes by and improves them.
code: Added get_inactive_hand() as an easy shortcut for carbons
code: Wall walker element can now accept a trait for wall-checking
fix: Fixed soulsword component being unable to invoke the post summon
callback
refactor: Turned Heretic rust turf healing into an element, given to
Rust Walkers and Rusted Harvesters
refactor: Converted Limb Amputation from an element to a component
Blade and Sword sprites by meyhaza!!! I did the inhands though. Cuz im
cool
## About The Pull Request
Fixes some interactions with attempting to patch multi-z holes.
1. openspace clicks happen on different z levels, so it's inherently a
*ranged* interaction- it was being ignored due to using the non ranged
signal
2. RCD was lacking the open space click handler,
3. #77540 still exists to a degree, I've refactored the click handler to
use parse_caught_click_modifiers to always grab the tile you're aiming
at rather than going off of whatever item you happened to click on
4. handle_openspace_click was treating the modifiers list as the old
parameters list
## Why It's Good For The Game
fix bugs, being able to repair holes is a very important and time
sensitive task that needs to flow well, and not require pixel hunting
## Changelog
🆑
fix: multi-z hole repair works better, especially when the turf below is
blocked by items
/🆑
## About The Pull Request
The light eater was working off of afterattack instead of interaction
for a lot of its light eating; now it works off interaction.
Incidentally, there was a 3 year old proc not being called when it broke
fixtures that gets called now; it turns out it's supposed to turn the
bulbs in light fixtures to ash.
## Why It's Good For The Game
Light eater was hungry, it gets to eat lights again
Fixes#84065
## About The Pull Request
- Fixes#84267
- Fixes#84264
- Fixes#84218
Adds `ALLOW_RESTING` to these actions. This should also fix some other
cases of mouse drop w are not aware of since it's at the `mob/living`
level. Also improved feedback messages for when an action cannot be
performed to help in debugging
## About The Pull Request
Previously, you couldn't pick up Ian because the clothing interface
would always open instead. Now, when you grab Ian (or any other corgi or
mob with the `can_be_held` trait) in an aggressive grip and pull him
towards you, you will take him into your hands!
## Why It's Good For The Game
...
You can hug Ian... That's enough
## Changelog
🆑
fix: you can hold Ian in your arms
/🆑
closes https://github.com/tgstation/tgstation/issues/84023
## About The Pull Request
So my previous PR was to give ashwalker the settler trait so they'd get
some of the benefits of settler (better riding, fishing, and taming) but
it was suggested that Settler be atomized into different traits instead.
I've done that here.
Ashwalkers now get
TRAIT_ROUGHRIDER
TRAIT_BEAST_EMPATHY
TRAIT_EXPERT_FISHER
which will, respectively, make them better riders, better tamers, and
better at fishing. I also made a small change to the riding code that
references riding speed boosts for people with the ROUGHRIDER trait
(would, at the moment, only be ashwalkers and settlers) that gives
ashwalkers the maximum bonus, to represent their primal connection with
the beasts in the area.
## Why It's Good For The Game
Ashwalkers are described in the lore as being denizens of lavaland, the
same as all the other messed up shit down there. This change brings them
in line with that. The improvements to the handling of the settler trait
will also open up avenues for expanding or improving on related systems
## Changelog
🆑 Bisar
add: Ashwalkers are now better at riding, taming animals, and fishing.
code: Behavior for the settler trait has been partially atomized into
several traits instead.
/🆑
---------
Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
there is a very small chance vendrobes will have mothroaches inside.
this will become apparent as the clothes you buy will come out slightly
damaged and eaten. hitting the vendrobe with a weapon (or throwing the
weapon at it) will cause the mothroaches to come out and scatter
everywhere. mothroaches will now also seek out clothes to eat them
## Why It's Good For The Game
gives more character and depth to mothroach AI
## Changelog
🆑
add: vendrobes may have mothroaches inside them
add: mothroaches will now seek out clothes to eat them
/🆑
## About The Pull Request
First of all, updates `COMPONENT_CANCEL_MOUSEDROPPED_ONTO` in the same
way Melbert did for `COMPONENT_CANCEL_MOUSEDROP_ONTO`, so it will only
block other interactions if it succeeds. Second of all, makes the
climbable element compatible with buckling again, since the two
behaviors have a lot of overlap.
## Why It's Good For The Game
Fixes a bug (Fixes#83998) where the chaplain altar can't be buckled to.
There might be other, similar cases that I'm not aware of.
## Changelog
🆑
fix: The chaplain altar can once again be buckled to.
/🆑
## About The Pull Request
Recently we allowed items held in your hands to catch fire if you catch
fire.
This makes sense but the code had a few oversights, then we reverted it.
This PR reintroduces the feature, but with a few refinements.
The basic feature is simple: If you are on fire then items you are
holding will also catch fire, in the same vein as items you are wearing
on your head or hands.
There are also a few caveats we forgot about the first time we added
this:
- If your gloves cannot catch fire, your held items will not catch fire
(because your hands aren't on fire).
- If you are extinguished, your held items will also be extinguished.
- Stopping, Dropping, and Rolling on top of any items will also
extinguish those items.
As part of this change, after an argument about whether or not this is
an oversight in coding-general, I've made the proc `get_equipped_items`
take a bitflag instead of a series of booleans as an argument and added
a new one for "include held items", so that we need no longer argue
about whether holding something counts as "equipping" it (in all other
parts of the game than this proc, it does). This is what gives the PR
most of its code footprint, don't be scared.
## Why It's Good For The Game
Items you are holding in your hands _should_ catch fire if everything
else on your person is on fire, and taking an item off of your body to
put it in your hands shouldn't protect it from fire, because those
things don't make intuitive sense.
If we want an item to be able to catch fire when worn, then it should do
so.
This might expose some issues where we were improperly setting the
flammability flags on items, but any weapon which will burn in your
hands now would also have burned if you were wearing it on your belt or
back, so making those issues more visible should be a bonus (we'll also
stop them from burning on your back or belt).
If you see someone holding a piece of paper that you really don't want
them to read you can now set them on fire to stop them from reading it,
whereas previously they would deftly hold the very flammable object out
of reach of their flaming body.
## Changelog
🆑
balance: Items held in your hands can catch fire.
balance: Items you are holding won't catch fire if your hands cannot
catch fire.
balance: When you stop being on fire so will items you are holding.
balance: If you roll around on your burning items they will stop being
on fire.
/🆑
## About The Pull Request
Fixes#83972
Clicking on stuff in your bag with stuff that has
`openspace_item_click_handler` makes it think you're on a different z
level (which is technically true) so it overrides the click and does its
own thing.
So we check that z is not 0. Also move the return to be safe.
## Changelog
🆑 Melbert
fix: Fix inability to make r-glass by hand inside your backpack
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
As I turned this into a trait the other day I thought I might as well go
all the way.
This PR allows basic mobs to perform wound handling steps if not in
combat mode.
This chiefly means that:
- cats and dogs can lick your wounds clean (they have the "wound licker"
trait)
- gorillas can set a dislocated limb (they have hands)
- dextrous holoparasites can pluck the eyeballs out of someone's crushed
head (they also have hands)
Wolves have the wound licker trait but can't lick your wounds because
for some reason they can't drag humans and I couldn't be bothered to
figure out why that was set up that way. Also it would look stupid
because it would still do the attack forecast animation.
In order to facilitate being able to set bones, gorillas need to be able
to aggressively grab you.
While I was there I set it to allow them to strangle people to death
because... well they're gorillas. It's probably slower than they could
punch you to death, so I don't see the harm.
## Why It's Good For The Game
If felinids can lick your wounds to heal them why can't an ordinary cat?
An ordinary cat won't _often_ do this and I have not placed any such
behaviour into their AI tree, but a sapient Ian or Runtime might provide
extremely minor assistance in medbay.
Also Cargorilla setting your dislocated limbs seems very funny and like
something it should be allowed to do.
## Changelog
🆑
add: Cats and Dogs can lick slashing wounds clean.
add: Basic Mobs with hands can relocate dislocated bones, and pluck
eyeballs out of pulped skulls.
balance: Gorillas can strangle people.
/🆑
## About The Pull Request
One should really err on the side of caution when preventing all humans
from being mousedroppable entirely
## Changelog
🆑 Melbert
fix: Human mousedropping
/🆑
## About The Pull Request
Mouse drag & drop has been refactored into its own attack chain. The
flowchart below summarizes it
Brief summary of each proc is as follows
**1. `atom/MouseDrop()`**
- It is now non overridable. No subtype should ever touch this proc
because it performs 2 basic checks
a) Measures the time between mouse down & mouse release. If its less
than `LENIENCY_TIME`(0.1 seconds) then the operation is not considered a
drag but a simple click
b) Measures the distance squared between the drag start & end point. If
its less than `LENIENCY_DISTANCE`(16 pixels screen space) then the drag
is considered too small and is discarded
- These 2 sanity checks for drag & drop are applied across all
operations without fail
**2. `atom/base_mouse_drop_handler()`**
- This is where atoms handle mouse drag & drop inside the world. Ideally
it is non overridable in most cases because it also performs 2 checks
- Is the dragged object & the drop target adjacent to the player?.
Screen elements always return true for this case
- Additional checks can be enforced by `can_perform_action()` done only
on the dragged object. It uses the combined flags of
`interaction_flags_mouse_drop` for both the dragged object & drop target
to determine if the operation is feasible.
We do this only on the dragged object because if both the dragged object
& drop target are adjacent to the player then `can_perform_action()`
will return the same results when done on either object so it makes no
difference.
Checks can be bypassed via the `IGNORE_MOUSE_DROP_CHECKS` which is used
by huds & screen elements or in case you want to implement your own
unique checks
**3. `atom/mouse_drop_dragged()`**
- Called on the object that is being dragged, drop target passed here as
well, subtypes do their stuff here
- `COMSIG_MOUSEDROP_ONTO` is sent afterwards. It does not require
subtypes to call their parent proc
**4. `atom/mouse_drop_receive()`**
- Called on the drop target that is receiving the dragged object,
subtypes do their stuff here
- `COMSIG_MOUSEDROPPED_ONTO` is sent afterwards. It does not require
subtypes to call their parent proc
## Why It's Good For The Game
Implements basic sanity checks across all drag & drop operations. Allows
us to reduce code like this
8c8311e624/code/game/machinery/dna_scanner.dm (L144-L145)
Into this
```
if(!iscarbon(target))
return
```
I'm tired of seeing this code pattern `!Adjacent(user) ||
!user.Adjacent(target)` copy pasted all over the place. Let's just write
that at the atom level & be done with it
## Changelog
🆑
refactor: Mouse drag & drop attack chain has been refactored. Report any
bugs on GitHub
fix: You cannot close the cryo tube on yourself with Alt click like
before
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
## About The Pull Request
- Afterattack is a very simple proc now: All it does is this, and all
it's used for is for having a convenient place to put effects an item
does after a successful attack (IE, the attack was not blocked)
- An overwhelming majority of afterattack implementations have been
moved to `interact_with_atom` or the new `ranged_interact_with_atom`
I have manually tested many of the refactored procs but there was 200+
so it's kinda hard
## Why It's Good For The Game
Afterattack is one of the worst parts of the attack chain, as it
simultaneously serves as a way of doing random interactions NOT AT ALL
related to attacks (despite the name) while ALSO serving as the defacto
way to do a ranged interaction with an item
This means careless coders (most of them) may throw stuff in afterattack
without realizing how wide reaching it is, which causes bugs. By making
two well defined, separate procs for handing adjacent vs ranged
interactions, it becomes WAY WAY WAY more easy to develop for.
If you want to do something when you click on something else and you're
adjacent, use `interact_with_atom`
If you want to do something when you click on something else and you're
not adjacent, use 'ranged_interact_with_atom`
This does result in some instances of boilerplate as shown here:
But I think it's acceptable, feel free to oppose if you don't I'm sure
we can think of another solution
~~Additionally it makes it easier to implement swing combat. That's a
bonus I guess~~
## Changelog
🆑 Melbert
refactor: Over 200 item interactions have been refactored to use a
newer, easier-to-use system. Report any oddities with using items on
other objects you may see (such as surgery, reagent containers like cups
and spray bottles, or construction devices), especially using something
at range (such as guns or chisels)
refactor: Item-On-Modsuit interactions have changed slightly. While on
combat mode, you will attempt to "use" the item on the suit instead of
inserting it into the suit's storage. This means being on combat mode
while the suit's panel is open will block you from inserting items
entirely via click (but other methods such as hotkey, clicking on the
storage boxes, and mousedrop will still work).
refactor: The detective's scanner will now be inserted into storage
items if clicked normally, and will scan the storage item if on combat
mode
/🆑
fixes the mood event not being applied, found in #83741🆑 ShizCalev
fix: The spooky element will now apply the spooked mood event when
someone is spooked.
fix: Fixed spookers getting a popup message when spooking mobs not
actively controlled by a player.
/🆑
also a minor grammar fix for the name of spooky skeletons.
## About The Pull Request
Fixes antimagic, not preventing the disgust builtup from standing on
rusted tiles, makes rust walkers more expensive to summon.
## Why It's Good For The Game
I'm very happy with the end result of my Rust heretic rework; but they
came up a tad stronger than i wanted them to be.
Carlac already changed the Vomit stun to knockdown, but i wanted to add
a couple of things myself.
Having anti magic now makes you fully immune to the effects of rusted
tiles, not just the spells.
Rust walkers summoning ritual now requires titanium instead of iron
sheets.
As of right now, they are way too easy to spam, Titanium is a bit harder
to come by than iron so that'll do for now.
I was planning to set a limit to how many you can summon at the time,
but i'd rather wait a few months to see how rust behaves before i add
more nerfs.
## Changelog
🆑
balance: Rust walkers' summoning ritual now requires 5 sheets of
Titanium instead of Iron.
fix: Magic resistance grants complete immunity from the passive disgust
buildup from standing on Rusted turfs.
/🆑
## About The Pull Request
A long-old bug due to the use of `min(flash_strength, 1)`. The intention
was clearly to have the flash be *at least* level 1, because
flash_strength defaults to nothing but can be set to 2. However,
`min(x,y)` uses the lowest value, making it always return 1. So we
change it to `max()`.
## Why It's Good For The Game
Bugfix. Sunglasses users cope.
## Changelog
🆑
fix: Tool-based flashes (read: from welders) are no longer incorrectly
locked at flash level 1. Wear proper PPE!
/🆑
## About The Pull Request
**PR body copied from last PR (#83149). I fucked something up (I think
by leaving dream maker open while trying to fix the merge conflicts?)
and rather than try and walk backwards I'm just making a new branch.**
This implements the digging of graves on most soil/dirt/planetary type
turfs, and gives the coroner their own private burial ground.
**Change 1 - Gravedigging:**
You can right-click planetary/dirt/grass tiles using a shovel or shovel
subtype (or entrenching tool). Speed varies on the type of shovel you
are using. This creates a Makeshift Grave, an unmarked burial mound
(different from the ones at the elephant graveyard).
This is handled through the new gravedigger component, which is mostly
unremarkable but worth mentioning in case anyone wants to add this
behavior elsewhere.
**Change 2 - Icebox Morgue Graveyard:**
The icebox morgue now has private burial ground, sealed off by a fence.
Mourners are expected to keep out and perform their grieving at the
appropriate distance. This does not affect the chaplain's burial ground,
which is publicly accessible from the outside. This gives a more secure
place to bury bodies (I'm sure someone will have a reason for this some
day) and may lead to fighting over corpses, which I think is funny.
Also, there might be some goodies left in those graves, but you wouldn't
go graverobbing just for some useless loot, would you??
This also adds a new area type, graveyard, which is mostly just the
icemoon outdoors with the spooky ambiance of the morgue.
## Why It's Good For The Game
Now you can bury your friends in an unmarked grave! Bury people alive!
Bury your treasure, or reminders of the sins you've committed! Bury
anything, anywhere you want!
The morgue graveyard is a nice bit of flavor. I know the Chaplain
already gets one (I forgot this when I started this PR though) but the
Coroner is an equal-if-not-more-important corpsekeeper than them.
## Changelog
🆑 Rhials
add: Shovels and entrenching tools can be used to dig graves on
asteroid/dirt/etc. surfaces. Neat!
add: The Icebox Morgue has been given a fenced-off graveyard in the
back.
code: burn_tile() is no longer double-defined on asteroid turfs.
/🆑
## About The Pull Request
Was looking into #83493 and I have no idea how that happens but I _did_
notice this unrelated runtime and logic error.
Due to the args being incorrect, we were checking the status of the
surgeon performing the operation rather than the person the organ was
being removed from.
## Changelog
🆑
fix: When removing a corrupted organ from a patient, the patient will
now be checked for Holy Water or magic resistance, rather than the
person performing the surgery.
/🆑
## About The Pull Request
If an elevated object is initialized inside of a non-turf atom, it'll
still make the turf it is on elevated. Permanently. Which is weird.
## Why It's Good For The Game
Randomly elevated turfs are bad. Bugs bad.
## Changelog
🆑
fix: Fix a rare issue where a turf would remain permanently "elevated"
if an elevated object was initialized inside of a non-turf object.
/🆑
