## About The Pull Request
It's kinda hacky, but it is nearly the same as just rendering one z
layer.
We allow people to ENTIRELY REMOVE most plane masters from their screen.
This has the side effect of disabling most visual effects (AO is a big
one) which saves a LOT of gpu.
We rely on planes being essentially layers to ensure things render in
the proper order. (outside of some hackyness required to make parallax
work)
I've kept parallax and lighting enabled, so visuals will still look
better then multiz pre plane cube.
It does also mean that things like FOV don't work, but honestly they
didn't work PRE plane cube, and FOV's implementation makes me mad so I
have a hard time caring.
Reduces gpu usage on my machine on tram from 47% to 32%, just above the
27% I get on meta.
I'm happy with this.
Oh also turns out the parallaxing had almost no cost. Need to remove it
as a side effect of what I'm doing but if I could keep it I would.
There's still room for in between performance options, like disabling
things like AO on lower z layers, but I didn't expect it to make a huge
impact, so I left things as is
Also fixes a bug with paper bins not respecting z layer. It came up in
testing and annoyed me
## Why It's Good For The Game
Ensures we can make multiz maps without running into client performance
issues, allows users to customize performance and visual quality.
## Changelog
🆑
add: Adds a new rendering option to the gameplay preferences. You can
now limit the rendering intensity of multiz levels. This will make
things look a bit worse, but run a LOT better. Try it out if your
machine chokes on icebox or somethin.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
I wanted to try and implement an easier way for people to fish out
corpses from chasms, as I heard many tales of people trying to fish
others out of chasms and it taking over one IRL hour, with some cases
where it would take over two hours. Obviously, that's not really
interesting gameplay, and it doesn't really give people an incentive to
fish, it just turns it into an annoyance that people won't want to do
for fun. Now, we don't want that, do we?
As such, I've created the rescue hook, a special fishing hook that can
only be used in chasms (as that's currently the only place you can find
people into), which will only be able to fish out duds, skeleton
corpses, any mob that's fallen into a chasm and hasn't been rescued yet,
or rarely, a hostile monster lurking below. It has, at the time of
writing this, a weight of 5 (50 without bait, lower with bait) for duds
and a weight of 30 for chasm detritus, which themselves have a 50%
chance to be a random skeleton corpse, or a lobstrosity, and the
remaining 50% chance of fishing out a mob that's fallen into a chasm.
I'm open to tweaking these values if we think it's too easy or too hard,
but it's still a rather expensive item, so I'd consider it quite fine
the way it is myself, as it's still not risk-free.
It's currently only obtainable through buying it from cargo in the
goodies section, at a default price of 600 credits (making it
SIGNIFICANTLY more expensive than the rest of the fishing content, and
making it something that assistants will have to put some elbow grease
into if they want to be able to afford it).
As it stands currently, it can't be used to recover the fallen's
belongings that weren't on their person (i.e., their crusher if they
were holding it in hands), ~*but* I'm down to make that easier to fish
out using, for instance, the magnet hook, while also making it
incompatible with fishing out bodies, which would make it a nice way to
recover those lost items without spending over an hour fishing for them,
if that's something that maintainers would want.~ Maintainers did want
it, and as such...
The Magnetic hook is now the go-to hook to retrieve objects from chasms!
Not only does it inherently do a much better job at fishing out
non-fishes, it also has a lesser chance of retrieving random junk from
chasms, and an even lower chance of fishing out lobstrosities!
I also improved the code for the fishing weights calculation so that the
hooks and the rods can have an effect on the odds of certain types of
rewards more easily, with the option of offloading a more of what's
currently being calculated on `fishing_challenge` over on the rods or
even the hooks themselves.
I finished by fixing a handful of capitalization and punctuation issues
in various fishing items, as that bugged me when I was testing my
changes.
## Why It's Good For The Game
Corpses being recoverable from chasms was a great idea, however making
it so people would have to sink a major portion of their shift for a
chance at recovering a corpse doesn't create a particularly interesting
gameplay loop. However, being able to spend your hard-earned funds in
order to streamline that process without really being able to use that
to cheese other mechanics sounds like a great deal to me.
## Changelog
🆑 GoldenAlpharex
add: Added a Rescue Hook, that will allow the fishing rod it's attached
onto to become a lot more proficient at recovering corpses from chasms,
at the expense of making it unusable for more traditional fishing. It
isn't entirely lobstrosity-proof, however...
balance: The magnetic hook can no longer fish out corpses from chasms,
but will fish out items much more efficiently than any other hooks,
while also being much less attractive to lobstrosities. Some still fall
for it regardless, however.
spellcheck: Fixed the capitalization and punctuation in the description
of multiple fishing accessories.
code: Improved the code for fishing weights, to allow for different
hooks to have some more noticeable results on the weights without having
to add to an already massive proc.
/🆑
## About The Pull Request
The first and biggest thing that is in this pull request is changing the
old pizza crate code from something that is hard to parse and full of
blahblach = C stuff into things that I believe are more in line with
modern standards, which adds the potential for expansion or additions to
pizza crates with more ease if, for example, someone wanted to make a
flatbread crate or something.
I've also changed all of the lizard flatbreads from just /food/pizza/
into being /food/pizza/flatbread so that I could fax them, along with
sliced bread.
Then I went in on pizzabox code adding various screentips and balloon
alerts so that holding stacks of pizza and manipulating them doesnt fill
your chat with stuff and finally to pizza code to add screentips.
EDIT: I've changed the code so that instead of using the tool context
screentips add element, it adds screentips via the processable add
element which means all processable food now has a default screentip of
"process" as a result of this PR
## Why It's Good For The Game
Old pizza crate code was unclear and now is clear so it should be easier
to know what to mess with if someone wants to change them further or add
or expand them.
We all like screentips!
Old pizzaboxes had way too many unnecessary messages getting printed to
chat.
You can fax root flatbread but not flatbread with toppings on them and
while that can make a kind of sense you can fax pizza slices with
toppings on them! Bread slices just also makes sense to add while I'm at
it.
## Changelog
🆑
add: you can fax flatbreads and slices of bread now, changed all
flatbreads into children of pizza/flatbread to allow for this
qol: adds screentips to various pizzabox action (stacking, when you can
take pizzas out, pizza box bomb stuff)
qol: adds a way to add screentips directly into processable food via the
add element processable proc
refactor: pizza crates work the same but more clearly and more variable
/🆑
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Fixes#41123
This gives mop buckets the same behavior as janicarts. This means it
inherits the same hotkeys, context screentips, etc.
Other niche changes:
- Fix reagent containers playing attack animation when transferring
reagents to mob bucket
- Fix syringes and droppers not updating the appearance of target when
used
- Regular mop bucket has the same RMB hotkey as janicart for wetting mop
## Why It's Good For The Game
One less bug off tracker. Better consistency with code.
## Changelog
🆑
fix: Fix reagent containers playing attack animation when transferring
reagents to mob bucket
fix: Fix syringes and droppers not updating the appearance of target
when used
qol: Regular mop bucket has the same RMB hotkey as janicart for wetting
mop
refactor: Refactor janicart to be subtype of mop bucket
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
this is a re-attempt at PR #70725 that was practically ready but was
ruined in the course of my hardships with git. Mistakes were made.
In this re-edition I also addressed a few suggestions from the comments
of the original pr. There is a shaker added in the meta station cafe and
the pill bottle is moved out of sight to the fridge (I still left it
cause it contained antidepressants for the especially overworked NT
employees). Additionally, the naming of `/cup/glass/coffee` has been
handled differently this time to minimize the need of changing the code
in multiple places.
Please refer to the original PR for all details concerning the content,
below I add just a rough line-out for the sake of coherency.
The content of the pr extends to:
- a new coffee bean driven coffeemaker
- syrup bottles
- a coffee condiment display box
- almost complete make-over of the meta station cafe
- adding the new coffeemaker in a few break rooms on delta and tram (2
machines per station)
## Why It's Good For The Game
Please refer to #70725
## Changelog
🆑
add: After a massive success of the Modello 3 series, Piccionaia Home
Appliances rolls out a completely new coffeemaker model and renovates
the meta station cafe for free in a promotional campaign!
add: Syrup bottles, condiment displays, and more, to make the spess
coffee experience even better
/🆑
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Tastyfish <crazychris32@gmail.com>
## About The Pull Request
Removes the last computer part in the game: ID parts
Because this is removed, I also removed all computer hardware in the
game, and removed mentions of it in the game.
There is still 'hardware', as in Computer, Tablet, or Laptop.
Computers now all hold one ID slot by default, the only time a second ID
was needed was to use the access of both at once, and for the ID
modification application. This was now replaced with a new UI that only
has one tab, one ID slot:
https://user-images.githubusercontent.com/53777086/202801939-151b783f-75c8-46bf-a6c5-1b57b0d0da8e.mp4
## Why It's Good For The Game
Computer hardware is finally dead 🦀
## Changelog
🆑
balance: All modular computers now only have one ID slot, and cannot be
upgraded.
qol: The HoP's access application now only has one app, logging in will
directly modify the ID that's in it, making it less confusing to swap
back and forth.
/🆑
## About The Pull Request
Removes cell parts and cell part cells, now tablets directly stole a
power cell in them, and uses regular stock cells like every other
machine in the game. This also makes it less confusing because people
are more used to stock cells over computer cells. Because cells
generally hold more power than computer ones, I bumped up the active
power usage from 50 to 75.
## Why It's Good For The Game
We are nearly finished removing all parts, holy cr*p
## Changelog
🆑
balance: Tablets now use regular cells instead of computer cells.
balance: Tablets no longer need a power cell component to hold power
cells.
/🆑
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>
## About The Pull Request
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This PR fixes a minor icon_state name discrepancy when switching to the
sales tagger mode (I forgot to add a space to the icon_state, which
carried over to the radial).
I then read #70909 which brings up several issues with the item, and
after actually testing it, everything works as intended. The issue it
appears is that it's not clear enough that the functionality is the same
as it was previously on the prior items, so we've added contextual
screentips to all 3 modes of the scanner.
## Why It's Good For The Game
Fixes#70909. Improves player feedback on the three modes of the
universal scanner through context.
## Changelog
🆑
fix: The universal scanner now properly show all three options in the
radial with sprites, due to a missing space.
qol: The universal scanner now has contextual screentips within all
three of its modes.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
This PR adds in 6 new flatbread recipes that are a mixture of more
"traditional style" recipes that would have already existed and some new
ones that reflect the space station living lifestyle.
Pictured from left to right is a bee larva and jellyfish flatbread
(stinging), raw meat flatbread (meatlovers), cucumber and egg with liver
flatbread (zmorgast, named after Smörgåstårta), fish and bbq sauce
flatbread (BBQ fish), tomato, mushroom, and oil flatbread (mushroom and
tomato), and korta nut flour and milk flatbread (nuffy).
It also features one additional pizza that can only be eaten by
Ethereals, because I think it is funny when Ethereals eat.
It is made out of two batteries and flatdough.
## Why It's Good For The Game
Generally, this is to add more support as a cook who only makes pizzas
and flatbreads for the crew. As there are only three flatbreads. the
options for such a pizza focused chef who wants to feed any lizards is
pretty low, and then some of those require out of the way ingredients or
additional cooking. This offers a bit more variety to flatbreads
including some with overlapping ingredients to things that you might
already have your hands on if you want to go all in on Pizzacraft. The
ethereal pizza is just a bonus and so that all of the roundstart species
can have a slice now.
## Changelog
🆑
add: Added 6 new flatbreads and their associated recipes
add: Added 1 new pizza for ethereals
/🆑
About The Pull Request
Adds a skillchip to the chef's vendor. This vendor allows the chef to kiss their food to deliver a chef's kiss.
Chef's kissing your food will add the "love" reagent to the food, which makes people much happier when they eat it. Be careful, overdosing on love can cause heart attacks.
Refactors microwaving.
Separates microwaving out of the edible component and makes it its own element, like grillable and bakeable.
Also removes some magic numbers from microwave code.
Code improvements all around baking and grilling code.
Refactors edible component inheritance.
Inheriting the edible component is now a viable way to cleanly add food types, flags, and callbacks. This makes it much much easier to change the values of an edible item without adding hacky signals / procs / getcomponent.
Why It's Good For The Game
Emergent chef gameplay.
Being able to further enhance your food with mood buffs.
Better code.
Changelog
cl Melbert
add: Chefs can now make food with love. They can purchase a skillchip from their vendor which enhances their kiss emote. Using your kiss on food you create will add a special reagent to it which makes it nicer.
refactor: Separated Microwavable from the Edible component, refactored microwave act to accompany this
refactor: Refactored how grilled items are generated
refactor: Refactored how silver slime food items are generated
refactor: Refactored how edible items inherit new edible statuses
code: Removed some magic numbers from microwaves
code: General code improvements for grillable / bakeable / etc
/cl
This PR adds a new item to the black market uplink, the V8 Engine. The V8 engine is a classic, vintage engine, kept perserved for hundreds of years by black market smugglers, and they'll only ship it to you for an exceptional cost.
About The Pull Request
The Export Scanner, Sales Tagger, and Price Tagger are all niche, cargo adjacent items that each perform a different minor task and if using one, requires usually one of the three extremely rarely. Each one requires printing a new item at the lathe, all for maybe one or two uses before it needs to be replaced.
This PR merges the three into a singular, modular item. Existing export scanners have been reflavored the "universal scanner". When used in-hand, it produces a radial to swap between the three modes, Each mode has identical function to their previous scanner, with the only functional difference being that the sales tagger now prints new tags on secondary attack as opposed to primary.
The other two items lathe recipes have been removed, as their functionality has been fully moved to the universal scanner.
Also flips the export scanner icon state to match the other 2 scanner items that have been lumped together.
Why It's Good For The Game
Cargo now only needs to swap between 1 of three nearly identical barcode scanner looking items at a time, as opposed to having to print an item that sees functional use once every thousand rounds. By increasing the ease of use, it will also make it easier to use custom vendors, as well as print sales tags on regular rounds, as the universal scanner can still be found in shipping boxes located around the station and in tool storages.
Arguably not a balance change, as the three tools are extremely cheap to print, and don't have a formal impact on cargo balance except for tedium.
* Removes HDD's entirely
HDDs have been removed, though the code for it is still currently lingering as it's required for portable disks. I'll have to find a solution to this one day, but as I am going to sleep, this is a problem for future me.
* starts on removing SSD
* updatepaths and kills off SSD
* update path :D
* Fixes to programs and icons
* Ready for review now
I read over everything I did and tried to fix anything I saw wasn't done right. Hopefully better comments now.
* merge conflict fix
* can't win them all
* takes viruses into account in paths, fixes it in snowcabin
* Renames the updatepaths
* removes the qdel loop
* accidentally new'ed programs twice
* Fix program's computer var
* destroy pen and disk, dont run kill program on something killed
* more fixes for pens and idle threads
* Fixes PDAs installing apps twice.
* simplifies inserted disk & PDA disk
* fuck's sake
* Use istype instead
* revert
* Revert "revert"
This reverts commit 9ede628c6fef9c7c86417234f6d8ada1ff9e2fef.
* why did that happen
* Update code/modules/modular_computers/computers/item/tablet.dm
* MC_SSD added to master lol
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
About The Pull Request
So, it turns out the crafting recipe for the black market was using obj/item/market_uplink to make black market uplinks. Now, as it stands, we only have one market, the black market. As a result, the parent pulls that as well.
However, that doesn't change the fact that the description for the parent is quite literally one of those "You shouldn't have one of these!" sorts of descriptions that we've usually try to report.
Why It's Good For The Game
Cleans up the item paths for future usage of the market system for potentially civilian markets and also makes it seem like the black market uplink actually works. (It does).
Splits head dmi into separate files for both mob and obj icons. Kept similar to suit split categorization + some more. New files include beanie, bio, chaplain, costume, cowboy, default, hats(softcaps, fedoras, head caps, generic hats), helmet(helmets and other armored headgear/hoods), spacehelm, utility(hardhats, mostly work related hats), wizard.
Moves animal/pet head sitting icons to 1 folder, pets_head.dmi
Renames PAI head sitting icon file to pai_head.dmi
* Makes engines machines instead of structures
* Updates the maps
* Fixes boards and anchoring
* Removes 2 unused engine types
Router was actually used a total of once, so I just replaced it with propulsion.
I think cutting down on these useless engine types that make no difference in-game would be a nice first step to adding more functionalities to them.
* Don't use power (since shuttles dont have)
Shuttles don't have APCs, instead they just have infinite power, so I'm removing their power usage for now. I'm hoping this can be removed when unique mechanics are added to engines, because I would like them to make use of power like other machines.
* re-organizes vars
* deletes deleted dm file
* Slightly improves cargo selling code
* Renames the updatepaths
* Removes in_wall engines
I hate this stupid engine it sucks it's useless it's used solely for the tram it provides nothing of benefit to the server
replaces them with regular engines
* Adds a new 'Knucklebone' crate to the Cargo console under Service's "Costume & Toys" section, which comes with a crayon, 19 dices, and a paper explaining how Knucklebone works.
* base
* reasons
* GetToken proc, with a many remarks
* Add a way to change reason in transfer_money proc. Add a reasons.
* Reason to use the app. Commission. Standard application.
* Apply suggestions from code review - Tralezab
Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
* Tralezab & jlsnow301 advices. New format(everywhere)
* Nanotrasen
* Refactor TGUI(not me:( ). Fix useless capitalize
* Update code/modules/economy/account.dm
* Trans transforms in transaction
* coMmission. little autodoc mistalke. Translation != Transaction
* oops
* Merge Conflict
* ...
* back feats
* mistakes bye!
* ну да
Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE
The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name.
It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity.
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 recharger tablet parts
Removes 'advanced' tablet subtypes that we used before PDAs were added, in some jobs.
Replaces Roboticist's advanced tablet mail with a laptop
Moves the notepad's note var from the tablet, to the note app
Moves modular computer's defines into their own file
Machine computers now directly use power from the machine they're in, while the rest uses power cells.
Silicon tablets don't use power at all.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Refactors hallucinations slightly, organizes them
* Refactors hallucination into a status effect
* Further hallucination proper refactoring
* Refactors battle hallucinations
* Refactors "fake item other" hallucination
* Gets it a bit closer to working state
* Refactors screwydoll and fake alerts
* Refactors fake inhand items
* Refactors a few more.
- Fake death
- Fake messages
- Fake sounds
- Projectiles
* Refactoring delusions, hallucination effects
* Furthering the hallucination status effect
- removes copypaste of hallucination pulses
* Almost finalizes the changeover to status effect
* Last staus effect stuff
* Delusion business
* Airlocks, fire, and more delusion stuff
* Finishes screwyhud. It compiles now!
* Swaps screwyhud over to a grouped status effect
* Removes hal_screwyhud
* Comment
* Bugfixing
* image cleaning
* Get rid of this it came back
* What if I finished this branch?
* Oops
* Messing with the randomness
* Mass hallucination tweaks
* +
* Some more mass tweaks
* Review
* Updates
* Unit tests hallucination icons
* More tweaks
* Move folder
* Another re-name
* Minor tweaks
* Anomaly unity
* Mass hallucination buffs
* t
* Sig
* Merge
* Lints
* Unit test already coming in clutch
* Another failure
* Use named args for cause_hallucination via some define trickery
* Some cleanup
* This is better
* adds some hallucinations
* Oops
* More sounds
* Tweaks
* Some additional documentation
* Flash
* Fixes mass hallucination
* Json changes
* Updates documentation
* Json conflicts
* Makes it work
* Missed that one too
* Helpers
* More signalization (WIP)
* Fixes bump
* Missed a helper use
* Dumb
Fax machines being present on the supply shuttle creates a risk that there may be ways to send other blacklisted items to CentCom in order to gain access. The neatest and safest solution to this broad realm of potential exploits is to keep the fax machine from being able to get there in the first place.
* A lot of shuttle code improvements
* Makes use of ``as anything`` in many places
* Adds mapload to connect_to_shuttle()
* Renames many vars, including shuttle 'id' var to 'shuttle_id' and engine 'state' to 'engine_state'.
* Engines now weakref their attached ship, and disconnect when unwrenched from it.
* Removes check for force when deleting a mobile docking port, being deleted should still clear your stuff, regardless of being forced.
Because of all the above, I was able to remove a few pointless checks scattered around, like engine's alter_engine_power()
* better comment for port_id
* Fixes Cargo, Arrivals, and Pirate ships.
* Merge branch 'master' into shuttlecode-oh-no
* last few
* fixes the CI
* fixes
* Fixes infinite engines
* Revert "Merge branch 'master' into shuttlecode-oh-no"
This reverts commit 94eba37de9fe3f4a01dc40bb064771b764f379e3.
* trammies
* whiteship tram
* Makes use of ?. instead
apparently this is what weakrefs use, so 🤷
* i hate supernovaa41
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* removes lateinit that I never implemented
* adds _ref to weakref var name
* small change to weld time define
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
About The Pull Request
Not without the help of my friend spriter, I added cucumbers, their seeds, the cultivation itself, so that they could be pickled and washed with a brine jar. I also added a Danish hot dog because it required cucumbers (perhaps that was the end goal), changed a couple of recipes to include cucumbers or pickles. Cucumbers have been added to both cargo orders and bounty cubes, as well as for the food order console
I think the Cucumber Update deserves its plush toy.
gg18b4b2cab0
Why It's Good For The Game
I think more food and drink... would add quite a nice role playing experience, and additional gameplay for hydroponics.
Changelog
cl Vishenka0704 and Ying-The-Pando
add: Cucumbers and pickles
add: Danish hot dog
balance: add cucumbers in dishes where they need
qol: add to bounty cubes, orders - new vegetables
/cl
About The Pull Request
Everyone has been asking: "When will there be an anomaly like the bioscrambler, but for the space station? Please, we need more things which replace objects with different objects from the same typepath."
Well I made it and it looked like ass because non-tiling floor and walls look terrible, so then I made this instead.
Dimensional.mp4
The "dimensional anomaly" shifts matter into a parallel dimension where objects are made out of something else.
Like the Bioscrambler anomaly, it does not expire on its own and only leaves when someone signals it or uses an anomaly remover.
When it spawns it picks a "theme" and converts terrain around it until it covers a 7x7 square, then it teleports somewhere else and picks a new theme.
A lot of these themes are relatively benign like "meat", "fancy carpet", or "gold". Some of them are kind of annoying like "icebox" because it creates floor which slows you down, or "clown" because bananium is intentionally annoying. Some of them are actively dangerous, mostly "uranium" and "plasma".
The main problem this will usually cause for crewmembers is decreasing area security. When it replaces doors it replaces them with ones which don't have any access control, and it will also replace RWalls with normal and much more vulnerable walls which will make breaking and entering significantly easier until someone has taken the time to fix the damage. But also sometimes it will irradiate them, you never know.
The fact that sometimes the changes are benign (or provide uncommon materials) and might be happening in places you don't care about access to might encourage people to push their luck and leave it alone until it starts turning the captain's office into a bamboo room or repainting medbay a fetching shade of flammable purple, which I would consider a success.
Armour.mp4
If you successfully harvest the anomaly core you can place it into the reactive armour to get Reactive Barricade Armour, which shifts your dimension when you take damage and attempts to place some randomised (not terribly durable) objects between you and hopefully your attacker (it really just picks up to four random unoccupied tiles next to you). If you're EMPed then the changes it make to the environment will often be as unpleasant for you as they are for a pursuer, and significantly more likely to harm both of you rather than just provide obstacles.
Other changes:
I split anomalies out into their own dmi file, seems to be all the rage lately.
I moved the anomaly placing code into a datum instead of the event because I wanted to reuse it but if you have a better idea about where I could have put it let me know.
This also fixes a bug where the material spreader component wasn't working when I applied plasma materials to something, the extra whitespace was parsing as another argument for some reason and meant it would runtime.
Supermatter delamination was still pointing to Delimber anomalies instead of Bioscrambler.
* Allows Brig Subtypes To Be Usable for Departmental Orders
Hey there,
I saw an odd thing on IceBox the other day, where they couldn't deliver the departmental order crate because they were trying to open it in `/area/station/security/brig/upper` and not `/area/station/security/brig`. When they went down a z-level and opened it in the correct area, it worked perfectly fine. However, I think it's a bit obtuse, and this sort of thing might only get worse as multi-z maps become more dominant. So, let's apply a code solution by making the areas list read off typesof for the department_delivery_areas for security crates.
* typesof didn't actually work, we go explicit now
LemonInTheDark
