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
* Makes condiments their own subtype, fixes geese, prepares for merging
* Fixes geese checking drink type instead of edible foodtype to eat gross food.
* Renames foodtype var on drinks to drink_types to prevent above from happening again because it KEEPS HAPPENING. DRINKS AREN'T FOOD!
* Makes Condiments their own subtype of reagent_containers because they don't make any use of being a subtype of food, at all.
* Starts moving things from food to /food/drink subtype in preparation for merging /food/drink with /drink
* fully removes Food subtype
* /reagent_containers/drinks are now /reagent_containers/cup - This is so it's no longer confused with eachother.
* /food/drinks is now /reagent_containers/cup/drinks, so we can keep their special abilities.
* Fixes a LOT of errors with food, which are STILL checking the reagent_containers, despite ACTUAL food being refactored away from it a long time ago.
This doesn't compile yet, but I do want to make sure my progress is well tracked.
* remove copypaste code, changes soda cans
* Removes most copy paste code between the two drinks, moving most stuff to parent whenever needed.
* Made soda cans their own subtype since they didn't share anything with glass bottles anyways.
* Fixes more problems with food/drinks, especially with geese. Geese really were just broken this whole time and no one said a word...
* Removes a snowflake signal, now that both drink types share a common one.
* Adds everything to the .dme
Currently my goal is to get this all compiling, then remove isGlass var by making glass be all glass ones only.
* Moves all icons into a single drinks dmi
I'm not that great at icon stuff, hopefully I didn't forget/break anything.
* Turns juices into their own subtype
This allows us to let them check for type in molotov, to both get rid of a use of isGlass, and so non-glass non-cartons don't show up as 'carton'.
* fixes compile issues, adds updatepaths
* a better updatepaths
* updates the damn maps now
* properly names the updatepath
* how did that get there
* i suck at handling merge conflicts
* how am i this bad
* code improvement and soda fix
* more fixes
* Don't be a timer
Ports from old food bottles to trans the reagents, rather than add a timer to.
* Merge conflicts and fixes bottle smashing
* Bottle smashing is now consistently functional regardless of how much liquid they have in them, when before it would spill first, then smash on the second hit.
* runs updatepaths again
About The Pull Request
Yup. That's pretty much it. This PR adds the Mothroach to the game, described as "An ancient ancestor of the moth that surprisingly looks like the crossbreed of a moth and a cockroach."
Do you love the Mothroach? Then you can cuddle with it and pat it, as well as place it on your head for extra cuteness.
What if you hate it, though? You can always kill and butcher Mothroaches in order to mass produce moth plushes for your own profit... How fun!
Either way, you win!
The Mothroach can be picked up and has a special on-head sprite (which looks really cute). It is able to vent-crawl and you may get one by randomly summoning a friendly mob through the gold slime extracts, or by ordering one through the Cargo Requests. After butchered, you may use its hide, a heart, and some cloth to craft a moth plushie, the most devilish of Devil's designs.
Full Preview of all the Sprites (NEW): https://www.youtube.com/watch?v=pdg8FTNEYjI
Preview of some of the Sprites (OLD): https://www.youtube.com/watch?v=9A-8hGCiW0s
In-hand, on-head, and grounded Mothroach sprite credits go to ValuedEmployee.
I did the Mothroach hide sprite though!
Why It's Good For The Game
The Mothroach is incredibly cute and a neat, fresh, new piece of content. Although it could use some future repurposing, right now it's simply a cute exotic pet with a few interactions.
These cute sprites are just too good to go to waste...
I keep seeing people complain about the lack of new content. Well, here's something niche that won't break the whole balance of the game and that will be cute. I seriously cannot see a motive not to add this to the game. Just because it isn't a powergaming tool or something that is seen every shift, that doesn't mean that it won't have a positive influence on the game. As I have stated, right now the Mothroaches are underperforming in terms of interactions and ways of getting them, but adding them is the first step to later improve them.
Changelog
cl
add: The Mothroach, your new local exotic pet
add: Mothroach Hide and Mothroach Meat
add: New crafting recipe for the Moth Plush: 1 Mothroach Hide; 1 heart; 3 cloth
fix: Fixes dead mobs on-head not having sprites
/cl
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
Feedback on the layout is very much appreciated!
This PR entirely remaps the lower half of Deltastation.
I'd go into detailed closeups of everything that's changed like I do normally, but so much was tweaked that's not very feasible. Here's a high resolution image instead.
Deltastation's medbay is currently, very ... meh.
Big hallways, very small treatment center. Lots of wasted space.
So, I wanted to enact my long time plan to create a theme for Deltastation - A non-centralized departures hallway, to match the now non-centralized arrivals hallway.
One thing led to another and here we are.
The Departures hallway now branches off the starboard primary hallway, going down to the departures lounge, which has been redesigned. It now faces south. Meta-clone!!
The library is now between the central primary hallway and dormitories, featuring a lot more open design.
The chapel has a grand window looking out onto the shuttle dock.
The maintenance between the dorms, the library, and the chapel has been reworked as well. Aux electric was shrunk a bit and slapped here.
Medical and Science are now adjacent, both below the corporate lounge area, which was changed to serve as a more "command event area".
Medical lies along the departures hallway.
Psychology now has an access door to a main hallway.
Science now wraps around the corner of the hallway. Genetics gets a hallway desk, by the pharmacy, and robotics is now across from the HoP line, slightly disconnected from the main science connection.
The experimentor gets its own room again, Xenobiology touches space. Science maintenance recieved some major adjustments to accommodate.
Some other very minor changes were done around the map in general for consistency purposes.
About The Pull Request
Resprites various clothing items from the clothesmate with GAGs.
Organizes the clothesmate. Recolorable items on top, in the order of head, mask, neck, glasses, gloves, acc, belt, under, suit, shoes.
Adds a pair of jean shorts.
Tweaks some already GAG'd sprite colors.
Top: OG
Mid: Resprite in the style of the OG
Bottom: Random colors to showcase colorable channels
yoopp
sundress, tango, plaid, slacks(khakis), shorts, jeans, turtleneck skirt. scarf, large scarf, beanie. new jean shorts.
(excuse the inconsistent pantyhoes, hair, and ears i was already done screenshotting before i realized)
Why It's Good For The Game
Expands the amount of in-game customization while also cutting down on current and future sprites at the same time its like magic.
Changelog
cl
imageadd: Various clothing items have been converted using GAGs, making them recolorable. Check it out at your local clothesmate!
/cl
* Fixes internal/external organ for checks
Fixes many single-letter vars for organ for loops
Makes use of `as anything` more often
Fixes the comment for external_organs to explain what it actually is for
Fixes for loops checking internal_organs for external ones, as they aren't stored there (in dummy's harvest_organs, on_species_loss, and purrbation removal)
* Adds coffins to crates' exclude_types.
Adds coffins to crates' exclude_types.
* Updates comment
Updates a years old comment with the current economy prices.
Adds fishing and fishing minigame.
You use fishing rod to fish.
Equipping specific bait/hook/reels will affect your success chances.
You can fish out fish,items and other things.
Fishing Equipment
Fishing rods have three slots: Bait, Reel and Hook.
Any food can be used as bait but dedicated bait makes fishing easier.
You can buy hook and line sets
New bait types:
Worms : Buy can of them at cargo (alternative acquirement method pending)
Doughballs : Use knife on flat piece of dough to get five of them.
Fishing rod types:
Basic : Print these at the lathe, nothing fancy here.
Tech: Experimental tech. Provides infinite bait
Fishing rods can also hook and reel normal items.
Equipment screen and reeling video
Fishing spots
Keep in mind this PR is meant to add the basic systems and i intend to fill these with more fish in future PR's so wait with suggestions until then.
Lavaland lava (no fish here right now, just other stuff), requires reinforced line to fish in.
Maintenance moisture traps.
Beach away mission water.
Fishing portal available for purchase from cargo - This is stopgap until we fill more spots.
Difficulty depends on fishing spot, fish type, and the fish traits and rod setup combinations.
All fish types can have specific traits, most common ones being favourite and disliked bait types/categories.
Other
Fishing catalog now lists fishing related info
New admin debug verb, fishing calculator that show probabilities with different setups so it's easier to balance this.
Fish now have average weight and size. Make sure to boast if you catch a big one.
Adds tgui mouse passthrough
Screens
Sprites:
Fishing portal sprite by @ArcaneMusic
Other sprites by @Mey-Ha-Zah
Bad ones by me. (Could still use better fishing minigame backgrounds)
Sounds:
https://freesound.org/people/soundscalpel.com/sounds/110393/https://freesound.org/people/soundslikewillem/sounds/343748/
