191 Commits

Author	SHA1	Message	Date
Zephyr	7f8752be14	Admin Verb Datums MkIII | Now with functional command bar (#82511)	2024-04-12 12:27:09 -07:00
ArcaneMusic	ed31397cc4	Fixes ore vents spawning without ores on icebox, sets up map specific ore configurations (#81103) ... ## About The Pull Request In short, we used a static list previously within the ore_generation subsystem that held the amount of each ore that we expected a single map to uniformly need. We held this number constant, since we were spawning 15 vents per map. **Pros:** This worked flawlessly for Lavaland since 15 vents on a single Z level makes it pretty densely packed map with a good amount of map-based ore spawns, and it worked consistently. **Cons:** 15 vents did not work well on Icebox however, even when split so that the majority of the ores were spawning on the lower levels, players did not feel like icebox spawned nearly enough ores and reported the map spawning empty. **Result:** As a result, we adjusted the ratio, so that we spawned vastly more ores on the lower levels, now up to 4 vents on the upper level, and 21 vents on the lower level. However, as we were still using the ore distribution list based on lavaland, icebox vents were quickly running out of ores to distribute between them, resulting in empty vents -> which produced empty boulders -> which not only don't really let you process them properly, but also just result in a metric ton of runtimes. Icebox now has it's own list of ore distributions. These distributions are now moved to a set of global lists as opposed to being saved on the subsystem as a static list, which will make going and setting up new ore distribution lists very very easy. Additionally, we've moved the setting and getting of those ore_distributions over to the seedRuins proc, so that we're actually setting the list of ores right before we actually place them to make sure that the order that it's set is roughly as it's needed, while still setting the list at the same time the map-appropriate ruin placements are dropped in. **Plus some misc cleanup fixes:** `var/list/ore_vent_sizes` in SSore_generation wasn't being treated as a similar budget list as `ore_vent_minerals`, since it `pick()`s off it's own static size list. Which is honestly fine for this five seconds, I can handle that later while we make sure the rest of the code code is stable. In the meantime, I've just tweak it so that it's easy to see at a glance how many of each random vent has spawned into the map. Tweaked the description to not include anything about chemical processing, as I'm planning on hitting on that in a part 2 PR that I'll be picking back up after the freeze. ## Why It's Good For The Game Cleans up the code a bit, but primarily fixes ores not spawning on icebox as they should. Should fix #81058. Improves description to not mention mechanics that aren't in game. Also, cleans up a piece of code that currently isn't serving much of a purpose. ## Changelog 🆑 fix: Icebox should have it's ore distribution and it's ore vents fixed, so that vents should now produce ore. spellcheck: Boulder processing machines now don't mention things they don't do. /🆑	2024-02-07 05:20:25 +01:00
ArcaneMusic	002051a3d5	ArcMining Pr Beta: Version 1.2 (#78524) ... This one's not like the last one, so much so that I'm not even going to outsource the PR description to a robot this time! Basically, **You should read the PR body before assuming that everything is the same as last time. It's not.** ## Video Summary Click the link below to see a video summary of the main features of this pull request. https://youtu.be/Aho2omR0mjY?feature=shared ## About The Pull Request This pull request serves as a large rework of minerals produced by mining, and by extension mining itself. I'll try and list each change and it's associated nuance here. ### Ore Vents The biggest addition to the game with ArcMining is **Ore Vents**. Ore vents spawn as a ruin on the map, placing a randomized ore vent onto map generation. Ore vents spawn in 3 different sizes, **Small, Medium, and Large**. These vents will pick from a pool of materials they can generate, and will hang out across the map. A player can use a mining scanner to discover an ore vent, granting a small quantity of **mining points** to begin with. Once scanned, ore vents will show what minerals that ore vent will generate after they're fully tapped. Scanning the vent again will trigger the extraction process. A small drone will fly down, called the NODE drone, and buckle onto the vent. Your job during wave defense is to protect the drone and to defeat waves of randomly spawning mobs (dependent on if you're on lavaland or on icebox). The quantity, duration, and time between waves is scaled to the size of the vent you're protecting. Starting by scanning and protecting lower tier vents earlier in the shift is a safer bet than doing a large vent in the first few minutes. The drone has 500 health, and can take a good few hits, but leaving it alone will cause it to meet an unfortunate end quite quickly. Cooperation can be your best asset, as mining with allies can greatly help with wave defense, and mineral points are granted to anyone who helps with defending the ore vent equally (So 500 * size tier, regardless of how much help you receive). Once complete, the ore vent will have a mining machine constructed on top of it, and will start to dredge up **Boulders** from the earth automatically. More on boulders later. Ore vents can be located based on your mining scanner, and will provide an appropriate audio cue based on if the ore vent has been discovered or not, and once processed will no longer alert you to it's presence. **Each station comes with a free vent that produces exclusively iron and glass, free of charge.** This is to help with shifts where the station may not have shaft miners to produce minerals, and to provide the station with a baseline amount of minerals where none may exist otherwise. ### Mineral Generation Mineral generation has been completely reworked. Previously, Mineral Generation had a flat 13% spawn rate in-game. Once minerals spawned, they would also have a chance to propagate their minerals to nearby tiles, resulting in a rather massive pool of minerals that could spawn throughout lavaland on the whole. This tweaks that, by making minerals in walls spawn based on their proximity to ore vents on maps that use cave generation. Both the probability, and quantity of ores spawning in walls is scaled based on distance, with ore vents looking like large caches of ores found in walls. This makes following ores found in walls and checking their quantity of minerals spawned a good indicator of how close you are to a nearby vent in-round. This means you can collect some points form both discovering ore vents first, as well as collecting their surrounding ores, turn those in for mining points, and then trading them in for gear upgrades to more effectively take on ore vents. As a result of tweaking the balance of this, the total amount of ores spawned in walls overall has been decreased. However, by making more of the process time based, we still result in a mostly balanced finished product. ### Boulder Processing On station, there are now three new machines. These are the BRM, the Refinery, and the Smelter. - The BRM acts as a teleporter. Instead of needing to carry boulders back to the station, you can activate the BRM, and it will automatically pick boulders to teleport back to itself. You can use this to teleport boulders dredged up from lavaland onto the station for processing. **The BRM will only lock on to boulders that are resting on an ore vent.** Moving boulders back by hand will mean you'll have to haul it back by hand. - The refinery processes the non-metallic materials out of boulders. This process sends the materials straight to the ORM, and collects mining points from the ores smelted in the machine. Swiping with an ID card lets you withdraw those points for your own personal account, but remember that these points are for your whole team to share from. The **Mining points obtained from this process is only 75% of the amount an equivalent amount of ores would provide.** - The smelter works nearly identically, however the smelter produces metallic materials out of boulders instead. - Once a boulder has had all of it's materials extracted, it's broken down and deleted from the line. Otherwise, the boulder is spat out for the next machine to process it (either the refinery or smelter). - Once there's no minerals left in a boulder of any type, the refinery or smelter will break the boulder down. - Boulders **do not stack onto tiles with each other**, so they'll block each other when pulled or when moving on a conveyor belt. Boulders can also be processed by hand. Using a mining tool on a boulder with right click will allow you to break down a boulder into it's composite ores, but limits you to a maximum of 10 ore per boulder, where the full amount can be extracted using the proper processing machines. Also, processing by hand does deal small amounts of stamina damage over time, do breaking a full large boulder can be particularly taxing. Additional Boulder Processing Machines can be built, with the BRM board being obtained from the Protolathe, while the Smelter and Refinery boards being obtainable from the Autolathe instead. A _boulder processing beacon_ can also be obtained from the mining points vendor as a reward to assist with boulder processing. Boulder processing beacons can be used to spawn in a new BRM, refinery, and smelter on the tile the user is standing on, however **you'll still need to link them to the ORM**! All three machines can be upgraded with Stock Parts, allowing for **more boulders to be processed at a time**. It does not, however, increase the amount of minerals received from boulders, or points earned. ### Mining Borg Tweaks Mining borgs have been given some minor adjustments to compensate for the changes to mining. Their mineral scanner, which now has an active component to gameplay, is now a module as opposed to built into the mob. This module allows for the same ability to discover and start waves of monsters to fight. Mining modules will find that their PKA now has a total of 90% mod capacity as compared to the 80% they had before, to allow for more robust defense of ore vents. In addition, all borgs and AIs can interact with the BRM for boulder collection. ### Mining Mech Tweaks Mining Mechs have had their utility tweaked as a result of these changes as well. Mineral scanners to be used on mining mechs now have a larger radius by comparison to their handheld cousins. Similarly, it now has an active scanning button, which will actively discovery nearby ore vents. To begin wave defense, you will need to hop out and scan a second time however, so that you can properly accept the risks of drawing a horde of bloodthirsty wildlife towards you and your companions. Mechs can also manually process boulders, similar to mining tools using their drill. ### Golem Tweaks Golems, being more gentle and less aggressive than humans, while being made out of LITERAL ROCKS, have a greater need to secure access to ores and minerals to eat. As such, they have adapted to be able to do two new things: - Golems may now right click ore vents to be able to manually haul a boulder out of the vent. This costs a hefty amount of stamina, but it allows for golems to avoid combat during regular gameplay. - Golems may now left click a boulder with an open hand in order to manually process a boulder like a pickaxe. While not faster, it is consistent and prevents golems from starving if they have access to a vent, but no ores, somehow. ### Gulag Tweaks The labor camp, being a camp for rehabilitation and ~~excessive manual labor~~ has been tweaked. Boulders now replace the random minerals located on their island, and to acquire their prizes inside, much be excavated and then broken out of the rock. Now YOU TOO can excavate minerals and become a true mineral hero by working your way to freedom. ### Mining Point Changes As a result of fewer mining points being available across the map due to the new ore spawning mechanics, and the shift in how and when ores will be coming in, almost every progress based mining point cost has been reduced by around 10-20%. Many numbers are still subject to change at present, but the idea is that core progress unlocks should be made a bit more available earlier in the round before players can start to solo or duo larger or more difficult ore vents, after which they'll be rolling in ores. ### Rarities Every once in awhile, an unusual boulder will get hauled up from the mineral rich depths of lavaland. These **Artifact boulders** can occasionally produce rare items, but for now they've mostly just been pulling up **Strange objects** for science. Nanotrasen Natural Sciences department will reward you extra points to be collected by boulder processing machines for successfully extracting one. In the future, this opens up a passive reward space that mining can reward to the station, like providing cytology DNA samples, ancient seeds, or other artifacts. ### Misc notes - Boulders can be stored in all varieties of ore boxes (ground, mech) should you choose, however as mentioned it's best to leave them where they spawn and teleport them to the station for convenience. - Maps that are not subject to cave generation will find that they are largely untouched in terms of mineral balance. - Future or existing ruins can now be tweaked to have a mineral balance cost, as the ore vent ruin does. This will allow us to spawn in more interesting ruins for pre-made combat challenges. - There are unique ore vents that spawn across the map, that will summon a boss mob relevant to that map. If the boss mob is defeated, that vent will spawn large boulders pulling from every possible ore type that can spawn. Not for the faint of heart! - Similarly, the number of ore vents and mineral budget is now adjustable in the cave generation procs, so maps may spawn with more or less ore vents as desired for balance. - Artifact boulders opens up a LOT of room for possible future content like archaeology, xenoarch, artisci, and other design spaces! - Megafauna STILL SPAWN ON THE MAP. They just happen to spawn in addition to boss ore vents. - **I'll add more to this as I get asked questions and remember things, this is a huge PR and I'm confident I've missed at least something** ## Why It's Good For The Game I outlined a lot of this in #78040, so I'll try and keep this relatively snappy this time, while noting that I've made some concessions to make the whole system a lot more playable while not trying to break out design decisions that are at the end of the day, better for the game and the overall resource balance in round. Minerals are a very poorly balanced system, and have been since their inception many years ago. We heavily rely on mineral balance in round, and yet we've really only balanced it by introducing so much supply that there's no equivalent exchange for materials that doesn't just heavily flood the exchanged material. For example, items printed from materials that are otherwise considered "rare" on master exist in such quantities and they'll never practically run out in our allotted 90 minute time slot design. This PR adjusts how ores spawn to a point where we can minimize the amount of ores that need to exist on the map for mining to be able to progress, while still providing enough resources for the station that it covers the needs of the station adequately. Miners will need to be more strategic about what resources they've collected, and be able to make decisions about which vents are worth the risk of attempting to fight, how to prepare for a wave defense, and when to head back up for upgrades, while finally giving them at least some kind of incentive to work together and use different equipment. Resonators make cleaning up the caves around vent easy, sandbags set up easy defenses for your vent, mechs can serve as a wider range radar while mining, all while still providing a new gameplay loop to mining. By limiting the amount of ores that can enter the round from the massive, massive amounts that were coming into the round beforehand (see #78346 ), we can make ore processing more meaningful by adding more gameplay to the processing of minerals. I have some plans for that, however this PR already got bloated really REALLY badly due to scope creep and the number of intersecting systems that rammed into each other to make this PR possible. So that'll be next. Plus, as I've mentioned, we open up places for ore processing to find fossils, relics, and other things that can implemented down the line. Overall, I don't expect this PR to save or kill ore balance, but we gain a LOT more control over it through the use of our mining defines attached to this PR, and at the end of the day, that's a great place to start off of. ## Changelog 🆑 add: Added ore vents. Scanning them with mining scanners shows what minerals they contain. Scan again to fight off a horde of beasts as your drone assistant excavates the vent, so the ore vent will produce mineral boulders! bal: Ores that spawn in walls now spawn based on their proximity to ore vents, with their chance to spawn and their minerals contained scaling from low to high. add: Added the BRM, Refinery, and Smelter. These pieces of equipment are used to process ore boulders into minerals for the station. Stock Part upgrades allow more boulders to be processed at one time. They collect mining points as well, to be redeemed with an ID card swipe. add: Boulders are teleported to the station via the BRM if left untouched. Boulders can also be cracked open for a reduced amount of ore using pickaxes or golems hands. add: All stations come equipt with a pre-excavated ore vent, which produces a basic supply of iron and glass only. Scan other vents for your critical resources! add: Look there's a shit ton of changes on mining, for more detail check out the Pull Request: https://github.com/tgstation/tgstation/pull/78524. sound: New sounds and noises for your high octane factorio-like gameplay! image: All new boulder sprites for the new minerals and rocks added to the mining gameplay loop, as well as mining machines! image: Overlays appear over vents when scanned to let you know their contents at a glance when actively scanned with any mining scanners. /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>	2024-01-21 11:32:05 -05:00
Kyle Spier-Swenson	8703eac50d	split area.contained_turfs up by zlevel, make init 10 seconds faster (#80941) ... ## About The Pull Request Situation: areas have a list of all turfs in their area. Problem: `/area/space` is an area and has a 6 to 7 digit count of turfs that has to be traversed for every turf we need to remove from it. This can take multiple byond ticks just to preform this action for a single space rune Solution: split the list by zlevel, and only search the right zlevel list when removing turfs from areas. replaces `area.get_contained_turfs()` with a few new procs: * `get_highest_zlevel()` - returns the highest zlevel the area contains turfs in. useful for use with `get_turfs_by_zlevel` * `get_turfs_by_zlevel(zlevel)` - returns a list of turfs in the area in a given zlevel. Useful for code that only cares about a specific zlevel or changes behavior based on zlevel like lighting init. * `get_turfs_from_all_zlevels()` - the replacement for `get_contained_turfs()`, renamed as such so anybody copying/cargo culting code gets a hint that a zlevel specific version might exist. Still used in for loops that type checked so byond would do that all at once * `get_zlevel_turf_lists()` - returns the area's zlevel lists of lists but only for non-empty zlevels. very useful for for loops. The area contents unit test has been rewritten to ensure any improper data triggers failures or runtimes by not having it use the helpers above (some of which ensure a list is always returned) and access the lists directly.	2024-01-18 12:16:12 -05:00
LemonInTheDark	b77fa8c2a2	Starlight Control (Aurora works now, space gas doesn't touch starlight, narsie ending effects) (#78877) ... ## About The Pull Request [Implements a setter for starlight variables](af34f06b41) I want to start to modify starlight more, and that means I need a way to hook into everything that uses it and update it, so we can modify it on the fly. This does that, alongside removing space overlays from nearspace (too many false positives) and making the aurora modify all turfs projecting starlight, rather then all turfs in an area. Do still need to figure out handling for the starlight color usage in turf underlays tho (I gave up, we just keep it static. I'll fix it someday but the render_relay strategy just doesn't work with its masking setup) [Reworks how starlight overlays work](9da4bc38e2) Instead of setting color on the overlays directly, we instead store an object with our current settings in every mob's screen, and render_target it down onto our overlays. This lets us update overlay colors VERY trivially. Just need to set color on the overlay var. Makes modifying starlight a lot cheaper. It doesn't work on area overlays, because suffering, and it MIGHT induce extra cost on clients. if it does we can do something about that, we'll play it by ear [Removes parallax starlight coloring.](5f701a1b13) I'm sorta iffy on the color, the effect can be real oppressive in some cases, and I'd like to use starlight color for more events in world, and having it vary can make that looking nice hard. [Adds some visual effects to narsie being summoned](a423cfcb2b) As the rune drawing progresses space (starlight and parallax) go from normal to greyscale. Then, right about when narsie shows up, starlight becomes vibrant red. It's a nice effect. I wanna do more shit like this, I think it'll improve vibes significantly. ## Why It's Good For The Game Can't embed it because of github's upload limit, can show a [link](https://cdn.discordapp.com/attachments/458452245256601615/1160821856358645860/2023-10-08_22-31-22.mp4?ex=65360e99&is=65239999&hm=680e33e4e0026b89e132afc50c04a648a24f869eb662f274a381a5de5c5a36f2&) for the narsie stuff Here's [one](https://cdn.discordapp.com/attachments/326831214667235328/1160813747196141568/2023-10-08_22-34-10.mp4?ex=6536070c&is=6523920c&hm=f8d571d1013da89887f49f3fec99f632251eeeac83085aa7dde97009aee3922f&) for the aurora too. This gives us more pretty starlight shit, and the ABILITY to do more pretty starlight shit. I'm pretty jazzed, and I hope people use this proc more (keeping in mind that it's pretty hard on the lighting system, and needs significant delay between changes) ## Changelog 🆑 add: Narsie summoning has had some effects added to space and starlight del: Removes the link between spacegas color and starlight. It was a slight bit too vibrant and I think impacted the vibe too wildly to be incidental. fix: The aurora event actually... works now. Space lights up and all that /🆑	2023-10-17 13:19:12 -06:00
Zephyr	1b96345e44	Multi-Z Support for Lazy Templates | Cleans up some turf flag misuse (#77786) ... ## About The Pull Request Adds multi-z support for lazy templates Also fixes some improper use and placement for turf flags ## Why It's Good For The Game Shadow needs/wants this for bit runner maps. Turf flags are also why lava has been generating in places it shouldnt. (inside of ruins) ## Changelog 🆑 fix: Lava can no longer occasionally generate inside of previously loaded templates and breach and/or destroy shit /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>	2023-09-19 01:06:08 +00:00
Whoneedspacee	3692ad837b	Demonic Frost Miner can spawn again (#78067) ... ## About The Pull Request Fixes #72943 Fixes #62901 This fixes specifically icebox multi-z ruins not spawning with their counterpart below ruins because the area for the underground portion of icebox was not whitelisted so there were no valid spawn positions. ## Why It's Good For The Game Multi-z icebox ruins working is good. ## Changelog 🆑 fix: Multi-z Icebox ruins including the Demonic Frost Miner can now be placed again /🆑 --------- Co-authored-by: Changelogs <action@github.com>	2023-09-03 06:45:56 +02:00
Time-Green	61abab479b	Planetary station traits: Forever Storm and Forested (#76957) ... Adds two new station traits for Icebox: **Forever Storm** The storm on icebox never stops and is more intense. You can wear a coat and drink coffee and be fine **Forested** Icebox top exterior has a different terrain generator, including way more grass and trees. AND DEER. Natural chasms are replaced with plasma rivers <details> <summary>Outside</summary>    (the emissives on the trees have been fixed) </details> ## Why It's Good For The Game There are no icebox specific station traits, so I added them! The exterior is very static, samey and could honestly be a lot more interesting. Having the outside area be varied is something that freshens up icebox a little! (3x3 icebox is inevitable...) Forever Storm: I think storms are pretty spooky and cool, and having a permanent storm can change the ambience a bit and make everyone feel more isolated. Exploration is not recommended, but you can totally still go outside at increased risk. Pretty rare and can only happen on icebox Forested: Forests are dope. It's pretty common for a station trait, but factoring in that this only happens on icebox, I think it's fair I've also had to split apart turf and object generation so stuff doesn't spawn above rivers/chasms anymore. I tested it and I didn't seem to have broken anything, so that's pretty cool closes #75154 🆑 add: Adds a Forested planetary station trait! Icebox exterior is now a forest! add: Adds a Forever Storm planetary station trait! Sometimes, the storm never stops. Stay inside or get some coffee and warm clothes fix: fixes stuff spawning in rivers and above chasms fix: emissive blockers on random flora not updating code: Splits terrain generation and terrain population in SSmapping /🆑	2023-07-29 07:59:34 +00:00
san7890	755fa4db6d	Loads Away Missions for Unit Testing (#76245) ... ## About The Pull Request Hey there, A pretty bad bug (#76226) got through, but it was fixed pretty quickly in #76241 (cf92862daf). I realized that if we were testing all the away missions, that this could theoretically get caught and not happen again. Regardless, unit testing gateway missions has been on my to-do list for a while now, and I finally got it nailed down. Basically, we just have a really small "station" map with the bare bones (_teeny_ bit of fluff, maploading is going to take 30 seconds tops anyways let me have my kicks) with a JSON map datum flag that causes it to load all away missions in the codebase (which are all in one folder). Just in case some admins were planning on invoking the proc on `SSmapping`, I also decided to gate a `tgui_alert()` behind it because you never can be too sure of what people think is funny these days (it really does lock up your game for a second or so at a time). I also alphabetized the maps.txt config because that was annoying me. ## Why It's Good For The Game Things that break on production could(?) be caught in unit testing? I don't know if the linked issue I mentioned above would have been caught in retrospect, but it's likely to catch more than a few upcoming bugs (like the UO45 atmospherics thing at the very top) and ensure that these gateway missions, which tend to be the most neglected part of mapping, stay bug-free. This is also helpful in case someone makes a new away mission and wants to see if stuff's broken. Helps out maptainers a bit because very, very technically broken mapping will throw up runtimes. Neato. ## Changelog Nothing that players should be concerned about. Let me know if there's a better way to approach this, but I really think that having a super-duper light map with the bare basics to load up gateway missions and then all nine-ish gateway missions can sequentially load during init. I can't think of a better way to do it aside from some really ugly `#ifdef` shit. Also also, it has the added benefit of being a map that will always load your away mission without touching a single shred of config (and it's not likely to break if you follow sane practices such as making your own areas)	2023-07-05 19:40:24 -07:00
LemonInTheDark	4d1e34322f	Macros multi-z code, removes the false premise of manual offsets (#76248) ... ## About The Pull Request [Removes the pretense of relative multiz levels](0293fdc2bd) Our multiz system does not support having a z level that is only connected one way, or which goes down backwards or anything like that. That's a fiction of the trait system, the actual backend has never really supported this. This pr removes the assumptions we were making backend around this, and uses that to save cpu time. I am also converting multiz_levels from an assoc list to a pure one, which saves significantly on access times and cleans up the code somewhat. Also I'm making the get_below/get_above procs into macros, for the sake of cpu time. [Converts the starlight disease to use BYOND's directional defines instead of our own](7d698f02d9) To some extent spurred on by https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known before ## Why It's Good For The Game Faster multiz code, faster init, etc etc etc	2023-07-05 18:31:27 -06:00
LemonInTheDark	63c365909e	Removes per z level station relays, allows tcomms to reach across interconnected zs (#76360) ... ## About The Pull Request The second layer of tram does not need its own relay, it is like 10 feet max above the first. Feels wrong in game, mappers tend to just sneak these off in corners, it sucks. Shouldn't need to do it. Instead, tcomms z levels will be filled based off the z stack, rather then just the layer itself. Adds a list/helper to make this more efficient/more easily duplicable ## Why It's Good For The Game Matches what people expect better, removes redundant map bits, better vibes. ## Changelog 🆑 balance: Tcomms now works across connected (vertically) zlevels. No more hunting in maint for the relay. /🆑	2023-06-27 22:14:32 -06:00
lessthanthree	8a8dd8f4b6	Fix further/MetaStation (#76158) ... ## About The Pull Request Typo fixes. Further and fixes MetaStation's default name to match the JSON. ## Changelog 🆑 LT3 spellcheck: Fixed a few typos /🆑	2023-06-19 23:04:45 -07:00
BlueMemesauce	20602ce519	Makes ruin budget proportional to amount of space ruin z-levels (#74841) ... ## About The Pull Request Adds global define for DEFAULT_SPACE_RUIN_LEVELS and DEFAULT_SPACE_EMPTY_LEVELS ### Proportional budget Adds proportional budget to setup_ruins The budget is multiplied by the current amount of ruin levels over the default amount Smaller amounts will have less ruins, while bigger maps will have more ruins Should maintain the same amount of ruins per z-level ### Z-levels spawning fix Z-levels didn't seem to spawn their intended amount of ruins This was because the for loop added the count variable before doing the spawning. So for example if there was only 1 level, it would count to 1 and end the loop without spawning the level. Also removed a loop that seemed to just make the process more complex for no reason. It even had a note to remove it. However, if it has a use then you should tell me. ## Why It's Good For The Game Maps with a smaller amount of ruin levels won't be completely filled The amount of ruins will be consistent per z-level The creator of North Star won't allow space exploration unless there's a way to proportionally reduce the space budget see #74719 ## Changelog 🆑 fix: Maps now spawn the correct amount of space levels. The bug caused them to spawn 1 less in each category code: The space ruins budget is now proportional to the amount of ruin levels. This has no effect on the current default maps, but added maps with less than the default amount of ruin levels will see less ruins. /🆑	2023-04-23 17:20:52 -06:00
LemonInTheDark	1e58c1875d	Fixes lava river genertation (It was broken for 2 YEARS) (#74359) ... ## About The Pull Request Post 9ee4703133, river generation was broken It broke things by moving ruin loading to BEFORE world gen (river gen happens w ruin loading for convienience), which, since rivers retain their old area (and world gen is area based), meant that rivers just got overriden. I've fixed things by moving river generation to AFTER world gen, since rivers rely on things like mineral walls existing ## Why It's Good For The Game If we're gonna spend cpu time on these they should like, exist. Closes #61371 ## Changelog 🆑 fix: Lava and plasma rivers (openspace on icebox too) will generate now. This was broken for 2 years wtf man /🆑	2023-03-30 21:21:44 -06:00
LemonInTheDark	5aab9dd88a	Saves roughly 20% off living/Life(), makes gravity event based (#74084) ... ## About The Pull Request Right now, each time life processes we need to run has_gravity, and check its output against a bunch of thresholds. We could save off that second bit by caching the previous value, but we'd still be only updating this every 2 seconds. This potentially delayed updating leads to really janky feeling behavior around transition points too (like when moving on/off the sand on tram station) So instead of doing this updating off life(), let's make it event based. We'll decompose has_gravity, and take all the values it relies on, and check for them changing ourselves. That way we get instant response, and can save all the wasted has_gravity calls. This constant checking on movement adds a few signal registrations, a connect_loc, and some logic on living/Moved The Moved logic increases Moved's self by 50%, roughly 1 second a round at worst. Don't have concrete numbers for the connect_loc (new self / old self)  In constrast, handle_gravity is currently on average maybe 15 seconds.  I could JUST save maybe 13 seconds and not spend the 1 by storing the previous gravity value, but I think this is worth the ux changes. It does add some extra resistance to change, but s much nice. Moved some functions around too, and removed now redundant update_gravity calls ## Why It's Good For The Game Snappier gravity, faster Life() ## Changelog 🆑 qol: Human gravity will react to changes instantly, instead of waiting for the next process tick. Hopefully this feels better and not worse /🆑	2023-03-25 22:44:27 -06:00
lessthanthree	331bc183b5	Fix pre-round lobby map vote filter (#73820) ... ## About The Pull Request Fixes https://github.com/tgstation/tgstation/issues/73816 ## Changelog 🆑 LT3 fix: Map filter works properly in the pre-round lobby fix: Map vote doesn't log 'not enough players' if the vote starts in the pre-round lobby /🆑 --------- Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>	2023-03-10 12:49:24 +00:00
MrMelbert	d8077e6b11	Documents the_station_areas global list, fixes some things which read from it incorrectly (#73279) ... ## About The Pull Request At a glance this list may confuse people, so it should have documentation. It contains area typepaths, not area instances. Some things got this wrong, fixed those. Perhaps this list can be changed to be associated `[type] to [area instance]` - though that brings in some redundancies when it comes to `areas_by_type`. Fixes #73298 ## Changelog 🆑 Melbert fix: False alarm radiation leaks should be less obvious fix: Fixes some traitor objectives from dropping in blacklisted areas, like security. /🆑	2023-02-07 16:40:18 -07:00
LemonInTheDark	f88edef0fb	Space/Changeturf fixes and optimizations (#73261) ... ## About The Pull Request We've got a few space related things that are busted, and shuttle movement is slow. I'd like to try to improve these things, if just a bit. Long list of only tenuously related topics. Sorry for the shotgun blast #### [Fixes lazyloaded stuff having bad space](d4de176a63) We need to handle area transferring in maploading code under niche cases, and we also need to actually init reservation spaces we create. It's also redundant and potentially dupe creating to do area lighting handling in changeturf, because it gets touched in turf init anyway. Old me is stupid. #### [Adds some doc comments, yeets ssmappping/transit](269717145d) We had a reserved space for just shuttles to use, except it wasn't for just shuttles. So in theory if the space got clogged with other shit, the shuttles could have nowhere to actually use. It's better to just have the two groups share real estate. More sane ### The "Starlight is Slow" Block #### [Starlight optimization part one (don't check config for each individual turf you check for activity)](7312a314be) #### [Starlight optimization part two (infer context)](be94c422ed) Starlight was causing each space turf to cause itself and its neighbor to constantly recheck if they had starlight off changeturf. The exact same effect can be had by taking advantage of some pre-existing information, namely if the space turf is gaining or losing a source of starlight. Essentially, instead of telling a turf to check all adjacent turfs to see if it's got starlight, we tell the turf if WE are a source of starlight, or if we might be taking something away from it. There's a bit of wasted cpu here but not much, if it's worth doing a register signal pattern for clearing depends on the case we're working with. Being intelligent about this makes things much faster, something in the neighborhood of 4 to 3 fold. I've also made openspace's starlight work better, cause the old pattern was a bit silly. ### Changeturf is Annoying (Microops) #### [Micro ops changeturf and turf deletion a bit](386b3ab7fc) Don't do work if the thing you're working on doesn't exist, don't check every adjacent turf for firelocks on turf change (just have thefirelocks manage that), don't check all atoms on the turf for decals on turf change, similar. Also moves visibility changes from camera code into changeturf, to avoid unneeded work. Needs some extra work to optimize the guts for this path but I can do that! #### [Micros camera vis changes](ebab69e9ea) We should only update vis when our opacity changes. In addition, we don't need all the camera handling fluff if we only want to update our turf's static groups. Also micros a camera net helper to be less crap for non multiz maps #### [Micros some open space atmos cases, alongside avoiding a for(null) in opacity handling](72ae07ba1d) #### [Ensures space_lit tiles never accidentially inherit lighting objects](a99ff2265a) S dumb, and leads to space turfs having two sources of lighting, which looks wrong. This was invisible when their lighting was fullbright, but it sucks now. ### Misc Stuff #### [Cleans up stat tracking a bit to avoid collisions](40fb8f21e2) #### [Cleans up a turf helper to not be stupid](bf4ee67100) WHY ARE YOU USING THE RANGED TURF HELPER IF YOU GO ONE TILE #### [Moves transit turf signal cleanup to destroy, I named this proc wrong](c85c2cfc86) I'm sorry @Time-Green #### [Adds better transit caching to shuttles](35e85334c4) Adds a max reserved transit size to the shuttle subsystem, to keep things in bounds. In addition, adds a soft cap under which existing transit space will get hold onto, to make repeated non escape/arrive shuttle movements faster Hopefully this makes common shuttle moves less bad. ## Why It's Good For The Game Speed	2023-02-06 23:04:50 -05:00
Jacquerel	cfb2d9feb9	Meteor events won't try and run on icebox (#73241) ... ## About The Pull Request While I was trying to improve changeling meteor spawning on Icebox I noticed that several other meteor-like events don't seem to be blocked on Icebox either even though they don't do anything. I added a new capability to events which can prevent them being loaded under certain map conditions (specifically: whether the map is in space or not). Currently there's no events which _only_ run on a planet but, now someone could add one I guess? Now all of the events which spawn meteors are filtered out on icebox and you can't absent-mindedly try to trigger them.  Also a couple of dynamic options had this applied too, chiefly ones which expect you to be able to fly a space ship to the space station. ## Why It's Good For The Game These events shouldn't run on Icebox (or soon, Chilled) because they don't do anything there. AFAICT Meteors were getting as far as trying to spawn, then would retry trying to find space tiles which didn't exist until they failed 10 times, then give up. Once per every meteor it tried to spawn. Gross. ## Changelog 🆑 fix: Meteors can't be triggered automatically or manually on Icebox, where they do nothing. fix: Hacking a comms console as a traitor won't try to summon meteors or pirates to Icebox, where they do nothing. /🆑	2023-02-05 19:19:28 -07:00
Mothblocks	d67555a0b5	the inevitable Revert "Refactors admin verbs from giant ass lists into datums" in case stuff breaks (#73206) ... Reverts tgstation/tgstation#72407	2023-02-05 11:44:38 +13:00
Zephyr	fca90f5c78	Redoes the admin verb define to require passing in an Admin Visible Name, and restores the usage of '-' for the verb bar when you want to call verbs from the command bar. Also cleans up and organizes the backend for drawing verbs to make it easier in the future for me to make it look better (#73214) ... ## About The Pull Request Damn that's a long title. Admin Verbs can be used in the verb bar with hyphens instead of spaces again. ## Why It's Good For The Game Admin muscle memory ## Changelog	2023-02-04 01:20:18 -08:00
Zephyr	7f25d7f17b	Refactors admin verbs from giant ass lists into datums (#72407) ... ## About The Pull Request See title. ## Why It's Good For The Game Makes it easier for people to add new admin buttons, and also removes the giant ass ugly lists that are an affront to my eyes. Yes you are still able to call them manually via the verb bar   ## Changelog 🆑 refactor: Admin verbs are now datums with a dedicated panel handler admin: Admin verbs now come with a handy description when you hover over them! /🆑 --------- Signed-off-by: GitHub <noreply@github.com>	2023-02-03 16:32:37 -08:00
LemonInTheDark	e9c87c0acb	Starlight Polish (Space is blue!) (#72886) ... <!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request Adds support to underlays to realize_overlays Ensures decals properly handle plane offsets Fixes space lighting double applying if it's changeturf'd into. this will be important later Makes solar vis_contents block emissives as expected Moves transit tube overlays to update_overlays, adds emissive blockers to them #### Adds render steps An expansion on render_target based emissive blockers. They allow us to hijack an object's appearance and draw it somewhere else, or even modify it, THEN draw it somewhere else. They chain quite nicely Fixes shuttles deleting z holder objects #### Makes space emissive, makes walls and floors block emissives The core idea here goes like this: We make space glow, and give its overlays some color This way, the tile and space parallax remain fullbright, along with anything that doesn't block emissives, but anything that does block emissives will instead get shaded the color of starlight This requires a bit of extra work, see later This is done automatically with render relays, which now support specifiying layer and color (Need to make an editor for these one of these days) The emissive blocking floor stuff requires making a second render plate to prevent double scaling Also adds some new layering defines for lighting, and ensures all turf lights have a layer. We'll get to this soon #### Makes things in space blue We color them the same as starlight, by taking advantage of space being emissive This means that things in space that block emissive will block it correctly and be colored blue by the light overlay, but space itself will remain fullbright This does require redefining what always_lit means, but nothing but cordons use that so it's fineee #### Makes glass above space glow, and some other stuff Glass tiles that sit above space will now shine light with matching color to the glasses color. This includes mat tiles. Glass tiles (not mat because they have no alpha) also only partially block emissives. Adds a new proc that uses render steps to acomplish this, essentially we're cutting out bits below X alpha and drawing what remains as an emissive. #### Modifies partial space showing to support glow Essentially, alongside displaying space as an underlay, we also display a light overlay colored like starlight. That starlight overlay gets masked to only be visible in bits that do not contain any alpha. We also mask the turf lighting to not go into bits that have no alpha, to ensure we get the effect we want. This is done with that lighting layer thing I mentioned earlier. #### Makes appearance realization's list output ordered I want it output in order of overlay, sub overlay suboverlay, next overlay Need to use insert for that ## Why It's Good For The Game Pretty! Also having space be emissive is a very very good way to test for fucked emissive blockers (If it's broken why are we even drawing the overlay) I know for a fact mob blockers on lizards and socks are kinda yorked, I think there's more <details> <summary> Old </summary>    </details> <details> <summary> New </summary>    </details> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 add: Space now makes things in it starlight faintly blue fix: Glass floors that display space now properly let space shine through them, rather then hiding it in the dark add: Glass floors above space now glow faintly depending on their glass type /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> --------- Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>	2023-01-31 09:52:27 +00:00
AnturK	49418819db	Fixes lazy loading antag maps locking world start (#72800) ... So the core issue here is antag datums are also created during preference spritesheet generation and when first opening admin panels. This could happen before mapping subsystem initialized and is ready for lazy loading. If this didn't actually lock the whole ss initialization it would also mean they are always loaded. I'll leave finding proper early load points for someone else if they're are necessary but New isn't it.	2023-01-22 18:49:08 -06:00
Jeremiah	872e64fb05	Adds spaces around logical operators (#72603) ... ## About The Pull Request Part of a prior PR that was closed (#72562). This version does not add the check in CI. ## Why It's Good For The Game The work is already done, so I figured why not. ## Changelog N/A Nothing player facing Co-authored-by: Jeremiah Snow <jlsnow301@pm.me> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>	2023-01-16 16:56:35 -08:00
Zephyr	8a8b4a37c4	Adds support for Rulesets having intrinsic template requirements (#72339) ... Title ## About The Pull Request Ensures that we load templates for a ruleset before we attempt to place or cache characters for that ruleset Also makes wizard and abductor async load their template to improve (apparent) loading times for them ## Why It's Good For The Game This is the only thing left that I can think of that would cause antags like nukies and abductors to spawn in wrong ## Changelog This should not be player facing Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>	2022-12-29 22:02:29 -08:00
Andrew	99d119758a	Maps load in the center of Z-level instead of bottom-left corner (#71818) ... ## About The Pull Request Reopen of https://github.com/tgstation/tgstation/pull/67857 as it became stale and autoclosed. Z levels are 255 by 255 tiles, but only 235 by 235 area is accessible because the 10-tile margins are reserved for smooth transition between space levels (essentially no-go area) The levels were loaded with x and y offsets set as 1, regardless of the level bounds. So when you load a custom DMM or just a map that is smaller than 255x255 and doesn't take into account these smooth transition margins, its western and southern part was cut. This PR makes it so that stations and custom maps are always placed in the center of the z-level. This has no effect of the 255 by 255 maps, but smaller maps, like runtime station or custom ruins loaded as stations, will not require to have the smooth transition margin tiles reserved in DMM. And they will not end up having parts in the inaccessible area. This inaccessible area is highlighted on the screenshots below. ### Before: <img width="816" alt="before" src="https://user-images.githubusercontent.com/3625094/206308672-9f97fe50-74bc-440f-b29a-605d3777103a.PNG"> ### After: <img width="816" alt="after" src="https://user-images.githubusercontent.com/3625094/206308725-4b1fb3db-b72e-4187-833b-4dfda777d1e4.PNG"> ## Why It's Good For The Game You can now properly load any space ruin as a custom map without it being fucked up by map cropping. ## Changelog 🆑 fix: The maps are now placed in the center of Z level to avoid having parts getting into the inaccessible area /🆑	2022-12-25 21:26:58 +00:00
Zephyr	b182d6f320	Lazy Template Loading - Nukie/Wiz (#71785) ... ## About The Pull Request Removes the nukie base and wizard den from the base centcom map. They are instead now lazy loaded as required. To make a new lazy load template is fairly simple, make a map, allocate an area for it, and place a marker at the bottom left corner of that area. I have it check an area to ensure that if someone makes the map larger than expected but doesn't account for the template allocation it doesn't overwrite stuff without warning [Replaces some improper CHECK_TICKs with MAPLOADING_CHECK_TICKs](c7fbca9148) Atom init has already been tripped by the time we get to this portion of the loading, so if we don't use the right check tick, we will potentially block unrelated init attempts. This is bad. (Lemon edit, I want this in the commit desc) ## Why It's Good For The Game Cuts down on init times. Closes https://github.com/tgstation/dev-cycles-initiative/issues/17 ## Changelog 🆑 admin: New mapping verb to load lazy templates as needed. In your admin tab under the Mapping category. /🆑 this isnt technically player visible, so not sure it needs a changelog Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>	2022-12-21 00:33:30 -08:00
LemonInTheDark	29d766e25f	Fixes attempting to offset floating planes (#71490) ... ## About The Pull Request This is a dumb idea, and leads to fucked rendering on occasion ## Why It's Good For The Game Fixes another portion of #70258, a player will no longer have a hidden antag hud if they move down a z level after getting an antag. We were trying to offset the floating plane of their image, and it went to shit. Also fixes a bug with observers not having antag huds for the combo hud to see. We were only giving them one on mind.on_transfer, rather then on mind assignment. I hate mindcode	2022-11-25 00:31:05 -08:00
LemonInTheDark	24d795b354	Adds a preference that disables intensive rendering on different multiz layers (#71218) ... ## 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>	2022-11-24 20:31:36 -08:00
John Willard	562a99c467	Fixes Golems not spawning on Lavaland (#71017) ... ## About The Pull Request Golems is apparently disabled on Icebox, but isn't disabled on Lavaland. However, blacklisting ruins doesn't care for maps, and will blacklist all, as if it were using all maps at once. This isn't a problem because Lavaland and Icebox do not share common ruins, except for one: Golem ship. ## Why It's Good For The Game Config now works as it's supposed to, Golems should spawn on Lavaland again (assuming it's enabled in config, I dont keep up to date with that) ## Changelog 🆑 fix: Ruins blacklisted from icebox shouldn't also blacklist it from lavaland, and vice versa. /🆑	2022-11-17 12:14:46 -08:00
AnturK	4d6a8bc537	515 Compatibility (#71161) ... 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>	2022-11-15 03:50:11 +00:00
LemonInTheDark	5b4ba051a0	Builds logic that manages turfs contained inside an area (#70966) ... ## 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>	2022-11-04 20:13:54 -07:00
LemonInTheDark	068482fb3c	Fixes a runtime in ssmapping caused by me forgetting what iteration pattern I was using (#70965) ... Fixes #70932	2022-11-04 01:08:26 -07:00
Mothblocks	085e2bb2b3	Save 0.1s in generate_station_area_list (#70933) ... `area.contents` loops over everything in the world to collect its list, every time. We need to avoid it where possible. Lemon already working on a PR to cache it. In the distant future we will lint this. This was a useless consumer of it. It cost 0.1s to index contents twice like this.	2022-10-31 20:40:52 -04:00
LemonInTheDark	85b2d5043d	Optimizes qdel related things (slight init time savings) (#70729) ... * Moves spawners and decals to a different init/delete scheme Rather then fully creating and then immediately deleting these things, we instead do the bare minimum. This is faster, if in theory more fragile. We should be safe since any errors should be caught in compile since this is very close to a "static" action. It does mean these atoms cannot use signals, etc. * Potentially saves init time, mostly cleans up a silly pattern We use sleeps and INVOKE_ASYNC to ensure that handing back turfs doesn't block a space reservation, but this by nature consumes up to the threshold and a bit more of whatever working block we were in. This is silly. Should just be a subsystem, so I made it one, with support for awaiting its finish if you want to * Optimizes garbage/proc/Queue slightly Queue takes about 1.6 seconds to process 26k items right now. The MASSIVE majority of this time is spent on using \ref This is because \ref returns a string, and that string requires being inserted into the global cache of strings we store What I'm doing is caching the result of ANY \ref on the datum it's applied to. This ensures previous uses will never decay from the string tree. This saves about 0.2 seconds of init	2022-10-30 00:09:15 -07:00
LemonInTheDark	a625fc8038	Cleans up the fallout from plane cube (#70235) ... * Cleans up the fallout from plane cube Alright. Makes cleaning bubbles respect planes Adds support for updating overlays on move, fixing an issue with pointing at items Adds better error messages for failing to provide args for mutable_appearance() Fixes a bug where string overlays were not respecting insertion order * Adds documentation for offset spokesman and offset_const * Better stack trace * Removes some redundant uses of cached MAs At this scale, attempting to cache MAs like this has 0 impact on anything And just makes things more messy then they need to be * ensures fullscreen objects START offset, so things are always proper * ensures chatmessages always have the right offset * fixes compile * whoops, the above lighting plane should actually be ABOVE the lighting plane * fixes compile, also cleans up the fire overlay a tad * Adds a unit test for plane masters that are shrunk by multiz being double shrunk This is slightly hacky because of how I'm handing the plane master group, but it's not THAT bad, and gives me some real good coverage * Properly targets the seethrough plane at the game world plate. This fixes unit tests, and also just makes more sense * whoops * oh * adds datum support for allocate(), cleans up a harddel from testing * Makes camera chunks index at 1, and also makes them support non powers of two sizes, since that was unneeded * fixes runtime in allocate	2022-10-20 09:00:02 +13:00
John Willard	364cd38285	[MDB IGNORE] Makes only station areas, station areas. (#70182) ... * Makes only station areas part of Statioj * Makes only subtypes of /area/station be part of the station * Removes Icemoon and Shuttles as a check for Anomaly placers as they aren't needed anymore, not being part of shuttles. * Removes a ton of uses of NO_ALERTS where it is no longer needed.	2022-10-19 00:54:29 -07:00
VexingRaven	5cd548d579	Fixes multi-Z ruins (Ice Moon Mining Site) not spawning (#70097) ... * Fixes multi-z ruins not spawning	2022-09-30 16:22:40 +02:00
John Willard	be450e12c8	Unit tests powernets to make sure the whole station is connected. (#70090)	2022-09-27 22:33:56 -07:00
LemonInTheDark	23bfdec8f4	Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115) ... 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 #65800 Fixes #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	2022-09-27 20:11:04 +13:00
LemonInTheDark	d34fa4c642	Macro optimizes SSmapping saving 50% (#69632) ... * 'optimizes' space transitions by like 0.06 seconds, makes them easier to read tho, so that's an upside * ''''optimizes'''' parsed map loading I'm honestly not sure how big a difference this makes, looked like small percentage points if anything It's a bit more internally concistent at least, which is nice. Also I understand the system now. I'd like to think it helped but I think this is kinda a "do you think it's easier to read" sort of situation. if it did help it was by the skin of its teeth * Saves 0.6 seconds off loading meta and lavaland's map files This is just a lot of micro stuff. 1: Bound checks don't need to be inside for loops, we can instead bound the iteration counts 2: TGM and DMM are parsed differently. in dmm a grid_set is one z level, in tgm it's one collumn. Realizing this allows you to skip copytexts and other such silly in the tgm implemenentation, saving a good bit of time 3: Min/max bounds do not need to be checked inside for loops, and can instead be handled outside of them, because we know the order of x and y iteration. This saves 0.2 seconds I may or may not have made the code harder to read, if so let me know and I'll check it over. * Micro ops key caching significantly. Fixes macros bug inserting \ into a dmm with no valid target would just less then loop the string. Dumb Anyway, optimizations. I save a LOT of time by not needing to call find_next_delimiter_position for every entry and var set. (like maybe 0.5 seconds, not totally sure) I save this by using splittext, which is significantly faster. this would cause parsing issues if you could embed \n into dmms, but you can't, so I'm safe. Lemme see uh, lots of little things, stuff that's suboptimal or could be done cheaper. Some "hey you and I both know a \" is 2 chars long sort of stuff I removed trim_text because the quote trimming was never actually used, and the space trimming was slower then using the code in trim. I also micro'd trim to save a bit of time. this saves another maybe 0.5. Few other things, I think that's the main of it. Gives me the fuzzy feelings * Saves 50% of build_coordinate's time Micro optimizing go brrrrr I made turf_blacklist an assoc list rather then just a normal one, so lookups are O(log n) instead of O(n). Also it's faster for the base case of loading mostly space. Instead of toggling the map loader right before and right after New() calls, we toggle at the start of mapload, and disable then reenable if we check tick. This saves like 0.3 seconds Rather then tracking an area cache ourselves, and needing to pass it around, we use a locally static list to reference the global list of area -> type. This is much faster, if slightly fragile. Rather then checking for a null turf at every line, we do it at the start of the proc and not after. Faster this way, tho it can in theory drop area vvs. Avoids calling world.preloader_setup unless we actually have a unique set of attributes. We use another static list to make this comparison cheap. This saves another 0.3 Rather then checking for area paths in the turf logic, or vis versa, we assume we are creating the type implied by the index we're reading off. So only the last type entry will be loaded like a turf, etc. This is slightly unsafe but saves a good bit of time, and will properly error on fucked maps. Also, rather then using a datum to hold preloader vars, we use 2 global variables. This is faster. This marks the end of my optimizations for direct maploading. I've reduced the cost of loading a map by more then 50% now. Get owned. * Adds a define for maploading tick check * makes shuttles load again, removes some of the hard limits I had on the reader for profiling * Macro ops cave generation Cave generation was insanely more expensive then it had any right to be. Maybe 0.5 seconds was saved off not doing a range(12) for EVERY SPAWNED MOB. 0.14 was saved off using expanded weighted lists (A new idea of mine) This is useful because I can take a weighted list, and condense it into weight * path count. This is more memory heavy, and costs more to create, but is so much faster then the proc. I also added a naive implementation of gcd to make this a bit less bad. It's not great, but it'll do for this usecase. Oh and I changed some ChangeTurfs into New()s. I'm still not entirely sure what the core difference between the two is, but it seems to work fine. I believe it's safe because the turf below us hasn't init'd yet, there's nothing to take from them. It's like 3 seconds faster too so I'll be sad when it turns out I'm being dumb * Micros river spawning This uses the same sort of concepts as the last change, mostly New being preferable to ChangeTurf at this level of code. This bit isn't nearly as detailed as the last few, I honestly got a bit tired. It's still like 0.4 seconds saved tho * Micros ruin loading Turns out it saves time if you don't check area type for every tile on a ruin. Not a whole ton faster, like 0.03, but faster. Saves even more time (0.1) to not iterate all your ruin's turfs 3 times to clear away lavaland mobs, when you're IN SPACE who wrote this. Oh it also saves time to only pull your turf list once, rather then 3 times	2022-09-22 15:34:10 -07:00
Tastyfish	4733643f39	Clean up subsystem Initialize(), require an explicit result returned, give a formal way to fail (for SSlua) (#69775) ... * cleanup SS API, give SSlua a proper way to error out * New SS_INIT_ system	2022-09-14 23:52:10 -04:00
san7890	3b2cf65d59	Rocking The Boat, er, Map Vote (#69561) ... * Rocking The Boat, er, Map Vote Hey there, A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan. So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls. Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen. * makes the grammar grammar it would be "Rock the Vote vote" otherwise	2022-09-06 11:06:01 +12:00
Mothblocks	73d471637b	Closets now initialize their contents on demand (more than 1.6 seconds of init time saved) (#69587) ... About The Pull Request Closets now initialize their contents once in dump_contents(). This saves more than 1.6 seconds of init time (all /obj/structure/closet now initialize in 84ms). Not sure what assumptions this will break, there's a lot of closets, so separate PR. cl del: You can no longer see maint spawners before the round starts (but your rounds start faster now :) ) /cl	2022-09-04 09:34:56 +12:00
Seth Scherer	c6a48b1f82	Refactors z level trait checking to be less shit (#69334) ... * Puts level traits and their associated z into a list and then uses it to make the z level trait procs less shit. They no longer need to loop through every z level to do what they aim to do. * Also removes get_level from level_trait because it just does the same checks as already done above in the proc.	2022-08-22 16:45:06 -04:00
Kylerace	fe7513d282	addresses reviews on the tram pr made after merge, fixes diagonal movement bugs (#68033)	2022-07-16 21:44:41 -07:00
Kylerace	8f0df7816b	(code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE (#66657) ... ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4 About The Pull Request fixes #66887 done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels. the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them. the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement. way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object. all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent. many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do). also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum. also https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4 multiz tram (this just adds the capability to map it like this, no tram does this) Actual Performance Differences to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch. also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement. the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds. ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved here are the master and optimized benchmark text files: master master base tram.txt https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4 also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch optimized optimization base tram.txt https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4 the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement. on master, this test takes over 100 milliseconds per movement master 2000 obj's.txt https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4 when optimized, about 10 milliseconds per movement https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4 optimization 2000 obj's.txt the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard. on master, this test takes 200 milliseconds master 300 catgirls.txt when optimized, this takes about 13-14 milliseconds. optimization 300 catgirls on ram ranch.txt Why It's Good For The Game the tram is literally 10x cheaper to move. and the code is better organized. currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential. also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen. also, you no longer make footstep sounds when the tram moves you over a floor TODO mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways. add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit. automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy remove the area based forced_gravity optimization its not worth figuring out why it doesnt work fix the inevitable merge conflict with master lol create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example. Changelog cl balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps) performance: the tram is now about 10 times cheaper to move for the server add: mappers can now create trams with multiple z levels code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift. /cl	2022-06-24 13:42:09 +12:00
GoldenAlpharex	0a4a5d2afd	Fixes map votes not happening when the ALLOW_MAP_VOTING config flag was disabled (#67394) ... Fixes map votes not happening when allow map voting was disabled by config	2022-05-30 15:05:59 -04:00
Jolly	cfc2330528	[MDB IGNORE] More /area/ typepath organization and cleanup (#67107) ... This further continues what I did in b4fb8f3ed1 (but instead of just stations, its now every (most) applicable area in the game	2022-05-23 13:01:19 -06:00