## About The Pull Request
This PR refactors mind language holders into non-existence
As a result, `update_atom_languages` is no longer necessary
Mind-bound languages are transferred via `/mind/proc/transfer_to`
Species changing no longer deletes and re-creates the mob's language
holder, allowing them to keep any languages they have.
Species languages are sourced from `LANGUAGE_SPECIES` now, meaning they
are removed when they change species. If the mob is not a human with a
species datum, these are effectively just atom level languages.
Makes a bunch of unit tests to ensure language transfer over certain
events works as intended
## Why It's Good For The Game
Mobs with minds having two independent language holders results in a
good few bugs, and simply doesn't make sense when we have sources
(`LANGUAGE_MIND`).
Instead of tracking two language holders, we can simply use sources
better and only track one.
This means that the language holder you start with is your language
holder, period. It doesn't get deleted or re-instantiated or whatever.
## Changelog
🆑 Melbert
refactor: Refactored language holders, making species changes not delete
all of your known languages
/🆑
holoparasite types have improved code
admins can now give someone a holoparasite through a new menu in vv
dropdown
alt click holopara abilities were moved to right click (support's beacon
wasn't, but support's heal mode was)
holoparas have less hardcoded stuff so admins can edit them easier
holoparasites now get their light color from their guardian color
holoparasites no longer have the hostile faction, things will attack
them
holoparasites now have a damage overlay, so you can see how much your
summoner is damaged
holoparasite health updating is now event based rather than running on
life, so you'll see health changes everytime they happen, rather than
every 2 seconds
holoparasites fly properly again (they cant spacewalk, but count as
flying for stuff like chasms)
holoparasite creation now uses a radial menu with tooltips for each
subtype. it also shows ghosts which type you picked
holoparasites can no longer be fugu'd
adds support for ownerless holoparasites
fixes mildly related bugs along the way
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Hello everyone! Today I bring to you all a fancy new HUD for you lot to enjoy: The Trasen-Knox HUD! Lovingly based off of the Common Core lore maintained by EOBGames!
Well, what is it?
Its a HUD with a special theming based on the old 1970's CRT screens that were commonplace at the time, including the iconic neon green and the beige plastic casing!
This PR also includes a new behavior so that its possible for each active hand icon to be unique, instead of it being a sole highlighted icon as it was before.
image
And for those wondering, it does indeed account for multiple limbs!
image
Finally, as seen in the first screenshot, this PR adds the behavior to hide the HUD icon when you insert a piece of equipment into the slot. Thank you for adding the behavior, Fikou!
This is all as a step for upgrading and changing how the HUDs we interact with on a daily basis can be upgraded in the future to be more appealing visually! That, and it is simply gorgeous :)
PositiveEntropy, Fikou
add: Adds a new HUD: The Trasen-Knox HUD! With a theming based on classic 1970s CRT screen computers!
code: Added behavior for unique icons for active hands.
code: Added behavior that makes it so when you equip an item, the icon behind it defaults to the blank template type.
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
* Removes persistence of species-restricted items through changing
Makes use of item's mob_can_equip instead of mob's can_equip, making it take the item's restrictions into account.
Also, fixes the inventory's color, so it's properly red when you can't equip such an item, by making it also use mob_can_equip.
Finally, expands the species clothing unit test to take that into account, to prevent it breaking in the future.
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
* - Fixes storage mass transfer
- Brings some sanity to storage procs
- Implements a griddle feature that never was
* Uncomment this
* Right-click attack fix
* Scoop fix
* Smartfridges use silent
* Restores some lost checks
* Fixes storage implants
Currently, storage works as a subtype of /datum/component, utilizing GetComponent() and signals to operate. While this is a pretty good idea in theory, the execution was pretty trash, and we end up with alot of GetComponent() snowflake code (something that shouldn't even need to be used frankly), and a heaping load of scattered procs that lead into one another, and procs that don't get utilized properly.
Instead, this PR adds atom_storage and proc/create_storage(. . .) to every atom, allowing for the possibility of storage on quite frankly anything. Not only does this entirely remove the need for signals, but it heavily squashes down the number of needed procs in total (removing snowflake signal procs that just lead to one another), reducing overall proc overhead and improving performance.
Adds the navigate verb, it makes a holographic path to any navigation beacon on station
Video here: https://streamable.com/2uy76l
removes wayfiding pinpointers and the associated quirk, as theyre kinda redundant with it
needs #65665 before merge
partially inspired by goon
* Move element to component, start UI, move assets into their own directory
* Complete UI
* Stop when another surgery is started
* Set your real zone since I forgot you actually need to start the surgery too
* Bring this back since I was just removing it as part of a cleanup for asset cache, but I can't prove it's not used anymore
* Remove unnecessary constructor I was using for something else
* Fix signal override
About The Pull Request
Same vein (although a lot larger than) #64118
On the tin. This moves them into their own folders and the paths were updated in the code.
Why It's Good For The Game
It's not exactly good visuals for stuff that can be placed elsewhere to just be sitting in the root. Organization is nice.
Changelog
cl
fix: For those of you into code, some stuff with the icon pathing has been shuffled around so it's no longer in the roots of the icon/ folder. If you aren't into code, that's fine too.
/cl
## About The Pull Request
stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it
for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload
## Regex used:
procs without args, not even regex
`/Initialize()`
procs with args
`\/Initialize\((?!mapload)((.)*\w)?`
cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
Mousing over an inventory slot with an item in-hand can trigger a call to equip_delay_self_check.
If the item has an equip_delay_self and bypass_equip_delay_self is FALSE, then it acts like it's going to equip the item and starts a do_after.
I think the only two items that do this are /obj/item/clothing/gloves/cargo_gauntlet and /obj/item/clothing/suit/straight_jacket
I make sure the call to can_equip back in the /atom/movable/screen/inventory/add_overlays section of the call stack calls with bypass_equip_delay_self = TRUE to prevent this.
## About The Pull Request
Changes up some layer and plane defines for no particular reason lol
## Why It's Good For The Game
Planes actually override layers, and layers control ordering within planes. A lot of the usage of plane and layer was wholly unnecessary. This refactor helps future maintainability while also being needed staging for _future features._
This PR makes sure all MouseEntered() procs call their parent, which handles the status bar. This fixes instances where the status bar was missing, for example when you hovered over the ghost buttons, you would not be shown a name of the button, but completely different object, like "space", which was very misleading. This also means that the new status bar should have better parity the with the old status bar, which also showed these things.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
The mood /atom/movable/screen, instead of having a Click() override, instead has its COMSIG_ATOM_CLICK registered in the mood component. This has the side effect of normal attack chain protocol being ran on it, meaning that if you click it with TK you will get a message saying "Your mind won't reach that far". This fixes that by overriding attack_tk into a noop.
This is a pretty big change all around. The gist of it is that it moves the mobility_flags into traits or variables that can track the sources, and to which we can append code to react to the events, be it via signals or via on_event-like procs.
For example, MOBILITY_STAND could mean, depending on context, that the mob is either already standing or that it may be able to stand, and thus is lying down.
There was a lot of snowflakery and redefinitions on top of redefinitions, so this is bound to create bugs I'm willing to fix as I learn them.
The end-goal is for every living mob to use the same mobility system, for the traits to mean the same among them, and for no place to just mass-change settings without a way to trace it, such as with mobility_flags = NONE and mobility_flags = ALL
Fixes AIs being able to strip nearby people. They've lost their hands usage.
Currently, when you drag your mouse off an inventory button while holding it down, it'll leave a permanent ghost image (#53950). This is because MouseExited is not being called properly. However, I couldn't reproduce this in a non-SS13 BYOND project, which makes it difficult for me to fix that.
This is a band-aid fix. It'll leave a ghost image, but then the next time you hover over and exit, it'll remove it, making it much less annoying.
About The Pull Request
It annoyed me that we have a perfectly good frag grenade item, and a perfectly good shrapnel component, but no crossover episode between the two. This remedies that, and does a lot, lot more.
dreamseeker_2020-03-30_05-01-13.png
dreamseeker_2020-03-30_05-01-26.png
Big points:
Adds new component: pellet_cloud, which can be used by ammo casings, guns, and landmines to spray shrapnel and display aggregate hit messages ("You're hit by 6 buckshot pellets!" vs "You're hit by the buckshot pellet in the X" x6). All gun ammo that shoot multiple pellets now use this component on firing.
Adds stingbangs, premium less-lethal grenades that shoot off lots of stinger pellets, to cargo. Frag grenades are also reworked to have smaller booms, but shoot off lots of shrapnel shards. You can jump on top of these grenades to absorb a portion of the shrapnel to save those around you! There's an achievement for dying this way, called "Look Out, Sir!"
Projectiles can now embed items/shrapnel. Adds .38 DumDum ammo to cargo that does less damage and has negative armor pen, but can embed in people. This is the only ammo that currently embeds.
Bullets can now ricochet off walls, structures, and machinery (harder surfaces are more likely to ricochet). Only standard .38 and Match Grade .38/.357/L6 ammo can ricochet, with Match Grade being much better at ricocheting. You can buy Match Grade .38 from cargo and Match Grade L6 ammo from the nuke uplink, while Match .357 is admin only.
Armor now protects you from harmful embeds, taking the better of the bullet/bomb armor on the affected limb. Armor penetration can modify this of course, and many blunt embeds like stingbangs and DumDum bullets are significantly worse if you have even 1 armor.
Other misc fixes/changes
Refactored the embed element a bunch and fixed it creating new elements for every instance rather than expected bespoke behavior. There are new /obj/item helpers for modifying and adding embedding.
Fixes#49989: Spears can no longer embed in turfs cause their sprite is annoying to me, it's generally harder for most things to embed in turfs
Fixes#49741: New carbon helpers for removing embedded objects
Fixes#46416: Handles embedded objects getting qdel'd or moved while embedded
Renamed the old shrapnel component for RPG loot to MIRV to avoid confusion
Repathed frag grenades from under minibombs to under base grenades, and added explosion vars to base grenades
Why It's Good For The Game
Fixes a bunch of janky design with embeds, adds lots of new avenues for projectile and grenade variety, ricochets and collateral damage are fun!
Changelog
🆑 Ryll/Shaps
add: Adds stingbangs to cargo (and one in the sec vendor premium), premium less-lethal grenades that shoot off a giant swarm of stingball pellets to help incapacitate swarms of people in tight quarters. You can jump on top of a live one to be a hero and absorb a bunch of shrapnel, same with frag grenades. There's even an achievement for dying to a grenade you jumped on!
add: Projectiles can now embed in people! Or at least grenade shrapnel and the new .38 DumDum ammo, now available in cargo, can. DumDum rounds excel against unarmored targets, but are pricey and do poorly against armored targets.
add: Bullets can now ricochet! Or at least, standard .38 and the new .38/L6 Match Grade ammo can. Match Grade ammo is finely tuned to ricochet easier and seek targets off bounces better, and can be purchased from cargo (for the .38) or nuke ops uplink (for the L6), but standard .38 ammo has a chance to ricochet as well.
tweak: Frag grenades now have smaller explosions but shoot off a bunch of devastating shrapnel, excellent for soft targets!
tweak: Shotguns and other multi-pellet guns now print aggregate messages, so you'll get one "You've been hit by 6 buckshot pellets!" rather than 6 "You've been hit by the buckshot pellet in the X!" messages. Bye bye lag!
balance: Armor can now protect against embedding weapons, taking the best of either the bullet or bomb armor for the limb in question away from the embed chance. Some weapons are better at piercing armor than others!
/🆑
About The Pull Request
This makes space suits use a cell and warm the wearer, This was handled by the handle_environment proc in the past with an override to make the suits work. This corrects this issue, and removes the override.
All space suits will have a cell installed at round start, this cell will last 15 min on average usage.
The cell cover can be toggled by alt+clicking (press the button), or using a crowbar (just pry it open) on the suit.
With the cover open you can remove the cell by using the suit in hand, or ctrl+clicking the suit.
As well with the cover open you can use a screwdriver to set the thermal regulator's temperature. The normal range is 20 c to 45 c, do not use an emag on the suit to increase the temperature range.
Examining the suit will report the temperature setting and the cells charge, if the cover is open you will also be able to see the type of cell that is in the suit.
Suit storage units will now charge the cells in suits, they will also require power to operate properly now.
Why It's Good For The Game
Space suits should be managing the wearers temp in space not using some override.
Lizards now have a portable heater in the form of any space suit.
Now that suits need a cell it is not as easy to spend all session in a space suit.
New interactions with hardsuits and emp's give nice combat buff to an underused item.
Nuke ops can raid xeno for some nice yellow cells, or science for a big old bluespace cell.
MrMelbert
