## About The Pull Request
Whenever you equip or unequip a piece of clothing (or change the
appearance of a chameleon item while wearing it), the game checks to see
if your sprite needs to update the parts of your body that are obscured
by that clothing. However, it only actually updates your sprite if the
item covers a part of your body that is relevant to your sprite. If you
equip an item that hides a part of your body (such as a chameleon helmet
set to something that hides your hair), then transform that item into a
form that no longer covers anything, it will see that the item covers
nothing important and skip trying to update your appearance.
Removing this check will cause update_body() calls to occur slightly
more often, but in the cases where it actually shouldn't update, the
sprite update code will detect that the rendering key for each limb has
not changed and exit without making any sprite changes, so the
performance hit will be minimal.
Similar situation with face-covering chameleon items and sec huds: You
could equip a face-covering chameleon item to make your sec hud arrest
status disappear, change the item to something that does not cover your
face, and then remove it, and your sec hud arrest status would not
update.
## Why It's Good For The Game
## Changelog
🆑
fix: Fixed chameleon clothing sometimes making you bald or hiding other
parts of your sprite.
/🆑Fixes#83570
# Conflicts:
# code/modules/mob/living/carbon/human/human_update_icons.dm
## About The Pull Request
Closes#54039
Rather than only dimming inventory slots your species are unable to use,
unusable inventory slots in general are dimmed.
For example, not wearing a jumpsuit shows this:
## Why It's Good For The Game
Makes it a bit more transparent what you can and can't wear given your
current equipment or status.
## Changelog
🆑 Melbert
qol: Unusable inventory slots (as according to your bodyparts or
equipment) will now be dimmed (similarly to how unusable inventory slots
are dimmed for certain species like Golems).
/🆑
# Conflicts:
# code/modules/mob/living/carbon/human/_species.dm
# code/modules/surgery/organs/organ_movement.dm
## About The Pull Request
The screen alert for being wounded is deleted
Instead, your health doll will now glow red on any (and all) wounded
limbs
https://github.com/user-attachments/assets/83565684-3e19-4753-8034-d8de6574e2b8
To accomplish this, the doll was refactored a bit. No longer operates
off of overlays, now uses vis contents across every limb, and just
updates the icon state of all those vis contents
## Why It's Good For The Game
Wounds really spam the hell out of you with screen alerts and it often
blocks you from seeing more relevant alerts that you care about
The mere presence of a minor dislocation on your leg prevents you from
noticing that you are no longer breathing. This is a bit troublesome
This can be resolved in other ways, of course - adding a priority value
to alerts? - but instead, I think we can just make better use of our
existing hud elements
I find this decently intuitive, at a glance.
- The old screen alert gave you a tooltip saying you could click the
alert to examine yourself.
- Clicking on the health doll examines yourself the exact same way.
- So, players may see their doll glowing red, and click on it to self
examine, to see the report of them having a wound on their leg or chest
or whatever.
## Changelog
🆑 Melbert
del: Having any wounds no longer gives you an alert in the top right
qol: Having any wounds now make the corresponding bodypart on your
health doll (the lil dude on the right side of the screen) glow red.
refactor: Refactored how the hud's health doll shows up for humans.
Report any oddities
/🆑
3591 individual conflicts
Update build.js
Update install_node.sh
Update byond.js
oh my fucking god
hat
slow
huh
holy shit
we all fall down
2 more I missed
2900 individual conflicts
2700 Individual conflicts
replaces yarn file with tg version, bumping us down to 2200-ish
Down to 2000 individual conflicts
140 down
mmm
aaaaaaaaaaaaaaaaaaa
not yt
575
soon
900 individual conflicts
600 individual conflicts, 121 file conflicts
im not okay
160 across 19 files
29 in 4 files
0 conflicts, compiletime fix time
some minor incap stuff
missed ticks
weird dupe definition stuff
missed ticks 2
incap fixes
undefs and pie fix
Radio update and some extra minor stuff
returns a single override
no more dupe definitions, 175 compiletime errors
Unticked file fix
sound and emote stuff
honk and more radio stuff
## About The Pull Request
All usages of world.icon_size in code have been replaced with new
`ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on
context
Replaces some "32" magic numbers with the defines
A few bits of code have been modified to split up x/y math as well
## Why It's Good For The Game
Magic number bad, code more readable, code more flexible and I'm told
there's an access cost to doing world.icon_size so minor performance
gains
## Changelog
🆑 tonty
code: made some code relating to the world's icon size more readable
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## 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
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
Second crack at my z-level changing HUD button. I felt that my last
attempt left a lot to be desired, so here I am with it again!
<details>
<summary> Images </summary>
Widescreen:
Non-widescreen:
Basic/Simple mobs:
</details>
TODOs:
- [x] Apply to cyborgs
- [x] Apply to xenomorphs
- [x] Sprites: Glass UI Style
- [x] Sprites: Detective UI Style
- [x] Sprites: Clockwork UI Style
- [x] Sprites: Operative UI STyle
I still wanted to get the PR up to both get feedback on this method and
to see if I could garner a little bit of help with the spriting bit
(PLEEEEASE)
## Why It's Good For The Game
The current button leaves a lot to be desired, mainly:
- It isn't applied to every possess-able mob
- It has weird positioning and sizing that doesn't match anything else
in the game
- It's confusing and inconsistent to use (it straight up would not work
for observers, and I had to add the option to do alt click to go down)
This PR aims to fix all this, and more!
- One, big, long button that matches other similar ones that already
exist!
- Click the up arrow to go up, click the down arrow to go down. Always.
No fuzz!
- Two types: Horizontal and Vertical! Choose whichever fits your needs!
## Changelog
🆑
qol: The z-level button got a refresh! It's now applied to more places
and it should be simpler to use.
/🆑
## About The Pull Request
This reverts commit 39e58f8b20 (#86020),
also reverts the "fix" from 8578180f8c7ef8c8745efbea3faa264c4bfc3984
(#86517 but keeping the unit test because sure).
get_steps_to() pathfinds, it cannot be used in a raycasting algorithm in
place of get_step_towards() (which is essentially get_step(us,
get_dir(us,them))). the original pr was making every usage of can_see()
and assorted procs pathfind to the target across the station instead of
checking visibility in a straight line to the target, leading to lemon
reporting can_see() taking up significantly more time than usual.
the fix inserting CanReach() doesnt work at all, CanReach() is for
checking if you can interact with an item in a possibly nested container
in the same or adjacent turf, it has nothing to do with visibility on
turfs.
## Why It's Good For The Game
optimizes the optimization, fixes the fix
## About The Pull Request
BYOND 515 added a new proc called `get_steps_to` - which is basically
`get_step_towards`, but instead it returns a list of directions! Ain't
that nifty and useful? So we can just calculate the path once.
Several helper procs - `can_see`, `CheckToolReach`, and
`get_hearers_in_LOS`, use `get_step_towards` in a loop, so I've
refactored them to just calculate the path once using `get_steps_to`,
and then loop through the returned path of directions.
## Why It's Good For The Game
In theory, should micro-optimize performance, by only calculating the
pathfinding once.
## Changelog
🆑
refactor: Refactored some functions related to line-of-sight and reach
to improve performance.
/🆑
## About The Pull Request
this is a revival of #82635 . i got permission from potato to reopen
this, he did almost all the work. i only just solved the conflicts and
fixed all the bugs that were preventing the original from being merged
(but it should be TMed first)
## Why It's Good For The Game
slightly improves the performance of basic mob AI
## Changelog
🆑
LemonInTheDark
refactor: able_to_run and incapacitated have been refactored to be event
based
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: ZephyrTFA <matthew@tfaluc.com>
## About The Pull Request
Fixes several errors to spelling, grammar, and punctuation.
## Why It's Good For The Game
## Changelog
🆑
spellcheck: fixed a few typos
/🆑
## About The Pull Request
Fixes several errors to spelling, grammar, and punctuation.
## Why It's Good For The Game
## Changelog
🆑
spellcheck: fixed a few typos
/🆑
* Makes map view hiding a bit more robust against unusual circumstances (#85900)
While in the middle of a destroy chain the mob can no longer be
associated with the client you need to clear huds from. This allows you
to just pass a client into a different proc and has some more error
checking to hopefully avoid visible issues for players if something goes
wrong.
This fixes a runtime I cam across while working on something else.
* Makes map view hiding a bit more robust against unusual circumstances
---------
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
## About The Pull Request
This solution sucks, but byond is after our mortal souls and I wasn't
able to find anything better. Something is very wrong with mouse_opacity
and the only working solution was making the plane master invisible
while its inactive.
Closes#85968
## Why It's Good For The Game
They no longer eat your clicks while invisible
## Changelog
🆑
fix: Fixed examine balloons not being click transparent even while
inactive
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
While in the middle of a destroy chain the mob can no longer be
associated with the client you need to clear huds from. This allows you
to just pass a client into a different proc and has some more error
checking to hopefully avoid visible issues for players if something goes
wrong.
This fixes a runtime I cam across while working on something else.
## About The Pull Request
You can now click wallmount balloons to click the parent object. Doing
so removes the shift key modifier, allowing you to interact with them
instead of examining
https://github.com/user-attachments/assets/d5b5ba95-4401-484a-a1a1-e738fa3ea99c
## Why It's Good For The Game
Sideways wallmounts are hard to click, and this is an easy and intuitive
way to solve that issue.
Also oranges paid me to do this.
## Changelog
🆑
qol: Wallmount balloons are now clickable
/🆑
* Adds attack_dir to multiple common damage sources, fixes mechs' directional armor (#85726)
## About The Pull Request
Closes#81260Closes#74022
Currently mechs are the only atoms utilizing attack_dir but I added it
in multiple other places that were missing it to ensure that if
something else uses it it won't break in those scenarios
## Changelog
🆑
fix: Mechs' directional armor now actually works
/🆑
* Adds attack_dir to multiple common damage sources, fixes mechs' directional armor
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Closes#81260Closes#74022
Currently mechs are the only atoms utilizing attack_dir but I added it
in multiple other places that were missing it to ensure that if
something else uses it it won't break in those scenarios
## Changelog
🆑
fix: Mechs' directional armor now actually works
/🆑
* Fix inventory item interactions sometimes being blocked due to not counting as adjacent when not on a turf (#85478)
## About The Pull Request
So it seems that currently `can_perform_action(target, ...)` being
called for an inventory item while you're inside of another object, say
a closet or a pAI card, blocks with the message "You are too far away!".
Looking into this, it seemed to be due to `CanReach(target)` failing,
which seemed to be due to `Adjacent(target)` not actually recognizing
these as being adjacent when not on a turf.
This seemed to be because it only really passes when either on a turf or
if the object we're checking adjacency with is the loc of the object
we're checking adjacency from.
After talking about it in the code channel, we decided to go for adding
a simple inverse check to make it symmetric.
Being, we add a second `neighbor?.loc == src` check parallel to our
existing `neighbor == loc` check.
This seems to fix the issue.
## Why It's Good For The Game
Kinda weird if being in a closet means somehow your inventory is no
longer adjacent to you for interactions, saying you're too far away.
Especially for pAIs, whom are always in this situation when not in
holoform (pAI in card, PDA in pAI).
## Changelog
🆑
fix: Fixes getting a "You are too far away!" interaction block on
inventory items when inside of another object. This includes accessing
storage or using your PDA from a closet, or as pAI using your digital
messenger while inside of your card.
/🆑
* Fix inventory item interactions sometimes being blocked due to not counting as adjacent when not on a turf
---------
Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com>
* Optimizes hunger appearance work (#85299)
## About The Pull Request
If our appearance is fully dependant on hunger state, there's no reason
to do ANY work if the state hasn't changed, also don't churn underlays
for no reason.
## Why It's Good For The Game
This has relatively high cost and it's an easy win
* Optimizes hunger appearance work
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Add our_view to screen_loc_to_offset in view_audit_buttons (#85300)
## About The Pull Request
Relative positions are calculated incorrectly in widescreen mode without
this. To demonstrate, call
```
screen_loc_to_offset("EAST-4,SOUTH", null) = [-128,32]
```
When passed to offset_to_screen_loc, this will be clamped to (32,32)
```
offset_to_screen_loc(-128, 32, view = our_view) = "1,1"
```
And returned as 1,1 - moving the action button incorrectly.
By including our_view in the call to `screen_loc_to_offset`, this entire
problem is avoided.
## Why It's Good For The Game
If someone sets a floating action button to be relative to EAST, SOUTH,
or CENTER, they run into this bug. As far as I can tell, nothing
currently does this and therefore it isn't meaningful, but I've run into
this twice now downstream.
## Changelog
🆑
fix: Fixed action buttons relative to EAST,SOUTH, or CENTER being
improperly moved during view_audit_buttons()
/🆑
* Add our_view to screen_loc_to_offset in view_audit_buttons
---------
Co-authored-by: ShadowLarkens <shadowlarkens@gmail.com>
## About The Pull Request
So it seems that currently `can_perform_action(target, ...)` being
called for an inventory item while you're inside of another object, say
a closet or a pAI card, blocks with the message "You are too far away!".
Looking into this, it seemed to be due to `CanReach(target)` failing,
which seemed to be due to `Adjacent(target)` not actually recognizing
these as being adjacent when not on a turf.
This seemed to be because it only really passes when either on a turf or
if the object we're checking adjacency with is the loc of the object
we're checking adjacency from.
After talking about it in the code channel, we decided to go for adding
a simple inverse check to make it symmetric.
Being, we add a second `neighbor?.loc == src` check parallel to our
existing `neighbor == loc` check.
This seems to fix the issue.
## Why It's Good For The Game
Kinda weird if being in a closet means somehow your inventory is no
longer adjacent to you for interactions, saying you're too far away.
Especially for pAIs, whom are always in this situation when not in
holoform (pAI in card, PDA in pAI).
## Changelog
🆑
fix: Fixes getting a "You are too far away!" interaction block on
inventory items when inside of another object. This includes accessing
storage or using your PDA from a closet, or as pAI using your digital
messenger while inside of your card.
/🆑
## About The Pull Request
If our appearance is fully dependant on hunger state, there's no reason
to do ANY work if the state hasn't changed, also don't churn underlays
for no reason.
## Why It's Good For The Game
This has relatively high cost and it's an easy win
## About The Pull Request
Relative positions are calculated incorrectly in widescreen mode without
this. To demonstrate, call
```
screen_loc_to_offset("EAST-4,SOUTH", null) = [-128,32]
```
When passed to offset_to_screen_loc, this will be clamped to (32,32)
```
offset_to_screen_loc(-128, 32, view = our_view) = "1,1"
```
And returned as 1,1 - moving the action button incorrectly.
By including our_view in the call to `screen_loc_to_offset`, this entire
problem is avoided.
## Why It's Good For The Game
If someone sets a floating action button to be relative to EAST, SOUTH,
or CENTER, they run into this bug. As far as I can tell, nothing
currently does this and therefore it isn't meaningful, but I've run into
this twice now downstream.
## Changelog
🆑
fix: Fixed action buttons relative to EAST,SOUTH, or CENTER being
improperly moved during view_audit_buttons()
/🆑
## 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>
* Callouts and MODsuit quick module pickers now track user (#85418)
## About The Pull Request
Callout and MODsuit quick picker (Ctrl + MMB) radials are now
user-bound, meaning that they won't change their screen position if you
move.
## Why It's Good For The Game
Those aren't radials bound to specific objects and rather appear at your
cursor purely for convenience. In case of callouts this is especially
important as you're most likely running while casting them which will
make your mouse move over and trigger a random option as you don't have
to click to use them.
## Changelog
🆑
qol: Callouts and MODsuit quick module pickers now track user
/🆑
* Callouts and MODsuit quick module pickers now track user
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Callout and MODsuit quick picker (Ctrl + MMB) radials are now
user-bound, meaning that they won't change their screen position if you
move.
## Why It's Good For The Game
Those aren't radials bound to specific objects and rather appear at your
cursor purely for convenience. In case of callouts this is especially
important as you're most likely running while casting them which will
make your mouse move over and trigger a random option as you don't have
to click to use them.
## Changelog
🆑
qol: Callouts and MODsuit quick module pickers now track user
/🆑
## About The Pull Request
https://github.com/user-attachments/assets/8949965f-a78a-4f3d-b528-afcdfe5c4e72
Drag'n'dropping items inside of an open storage that you can access will
reorder them. I had to register dropping onto items themselves instead
of cells as they ignore icon transparency when in storage for QOL
reasons, so bear with that.
## Why It's Good For The Game
Reordering your storage currently requires taking out all items in front
of position that you want a certain item to be and putting them back in
which could be rather annoying with large storages.
## Changelog
🆑
qol: You can now reorder items inside storages by dragging them
/🆑
## About The Pull Request
https://github.com/user-attachments/assets/8949965f-a78a-4f3d-b528-afcdfe5c4e72
Drag'n'dropping items inside of an open storage that you can access will
reorder them. I had to register dropping onto items themselves instead
of cells as they ignore icon transparency when in storage for QOL
reasons, so bear with that.
## Why It's Good For The Game
Reordering your storage currently requires taking out all items in front
of position that you want a certain item to be and putting them back in
which could be rather annoying with large storages.
## Changelog
🆑
qol: You can now reorder items inside storages by dragging them
/🆑
* Mining headset upgrade - Callouts and volume boosters (#85008)
## About The Pull Request
Shift + middle clicking while wearing a mining headset will open a
callout radial, after moving your mouse over one of the options a
callout emote will appear where you pointed (No need to click on the
radial button). Callouts have a 3 second cooldown to prevent spam and
glow in the dark due to how dark lavaland is (normal point emotes do
not)
There are 6 options: pointing, danger, attack, mine, defend and
reposition. Your callouts are colored in your runechat color. This is
done via a component so later if needed it could be added to other
headsets/mobs/items. Callouts also can initiate basic mob orders, being
a better way to command your minebots in combat.
Additionally, they also boost your speech back to normal levels in
low-pressure environments, ensuring that your runechat is still nice and
readable.
## Why It's Good For The Game
This would make coop mining much more enjoyable, as stopping to type
mid-fight is more often than not a death sentence on lavaland. With
arcmining's vents cooperating is actually beneficial, and I feel like we
should incentivize miners to do it more often by providing them with
tools for it.
## Changelog
🆑
add: Mining headsets now allow you to make callouts via pointing. You
can use them to communicate with fellow miners or order your army of
bots and raptors!
add: Mining headsets keep your voice loud and clear in low-pressure
environments (not vacuum!)
/🆑
* Mining headset upgrade - Callouts and volume boosters
* add N
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: SpaceLoveSs13 <68121607+SpaceLoveSs13@users.noreply.github.com>
## About The Pull Request
Shift + middle clicking while wearing a mining headset will open a
callout radial, after moving your mouse over one of the options a
callout emote will appear where you pointed (No need to click on the
radial button). Callouts have a 3 second cooldown to prevent spam and
glow in the dark due to how dark lavaland is (normal point emotes do
not)
There are 6 options: pointing, danger, attack, mine, defend and
reposition. Your callouts are colored in your runechat color. This is
done via a component so later if needed it could be added to other
headsets/mobs/items. Callouts also can initiate basic mob orders, being
a better way to command your minebots in combat.
Additionally, they also boost your speech back to normal levels in
low-pressure environments, ensuring that your runechat is still nice and
readable.
## Why It's Good For The Game
This would make coop mining much more enjoyable, as stopping to type
mid-fight is more often than not a death sentence on lavaland. With
arcmining's vents cooperating is actually beneficial, and I feel like we
should incentivize miners to do it more often by providing them with
tools for it.
## Changelog
🆑
add: Mining headsets now allow you to make callouts via pointing. You
can use them to communicate with fellow miners or order your army of
bots and raptors!
add: Mining headsets keep your voice loud and clear in low-pressure
environments (not vacuum!)
/🆑
* Monkeymancers can interact with runes (#85289)
## About The Pull Request
Hey hey party people. I watched a monkeymancer round last night. It was
hilarious, but the guy couldn't activate his ritual rune. Sucks!
Turns out, monkies don't call `attack_hand()`, they call `attack_paw()`.
This means that monkey dexterity was never the problem stopping the rune
from activating, but the fact that the attack chain was never even
trying to interact with the rune effect in the first place.
I've added a new atom interaction flag that routes through attack_paw,
so now monkies can be given their own specific interaction behaviors for
cases like this.
## Why It's Good For The Game
Closes#85267.
Also makes it a bit easier to make interact behaviors scalable to
monkies in the future.
## Changelog
🆑 Rhials
fix: Monkey wizards can now interact with grand ritual runes.
/🆑
* Monkeymancers can interact with runes
---------
Co-authored-by: Rhials <28870487+Rhials@users.noreply.github.com>
## About The Pull Request
Hey hey party people. I watched a monkeymancer round last night. It was
hilarious, but the guy couldn't activate his ritual rune. Sucks!
Turns out, monkies don't call `attack_hand()`, they call `attack_paw()`.
This means that monkey dexterity was never the problem stopping the rune
from activating, but the fact that the attack chain was never even
trying to interact with the rune effect in the first place.
I've added a new atom interaction flag that routes through attack_paw,
so now monkies can be given their own specific interaction behaviors for
cases like this.
## Why It's Good For The Game
Closes#85267.
Also makes it a bit easier to make interact behaviors scalable to
monkies in the future.
## Changelog
🆑 Rhials
fix: Monkey wizards can now interact with grand ritual runes.
/🆑
