mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-09 23:27:56 +01:00
observer_fix_tm
322 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 nevimer
|
baf3837ae8 |
Merge remote-tracking branch 'tgstation/master' into upstream-2025-11-29
# Conflicts: # _maps/RandomRuins/SpaceRuins/derelict_sulaco.dmm # _maps/RandomRuins/SpaceRuins/garbagetruck2.dmm # _maps/map_files/CatwalkStation/CatwalkStation_2023.dmm # _maps/map_files/tramstation/tramstation.dmm # code/_onclick/hud/new_player.dm # code/datums/components/squashable.dm # code/datums/diseases/advance/symptoms/heal.dm # code/datums/diseases/chronic_illness.dm # code/datums/status_effects/buffs.dm # code/datums/status_effects/debuffs/drunk.dm # code/datums/status_effects/debuffs/stamcrit.dm # code/game/machinery/computer/crew.dm # code/game/objects/items/devices/scanners/health_analyzer.dm # code/game/objects/items/wall_mounted.dm # code/game/turfs/closed/indestructible.dm # code/modules/admin/view_variables/filterrific.dm # code/modules/antagonists/heretic/influences.dm # code/modules/cargo/orderconsole.dm # code/modules/client/preferences.dm # code/modules/events/space_vines/vine_mutations.dm # code/modules/mob/dead/new_player/new_player.dm # code/modules/mob/living/carbon/human/death.dm # code/modules/mob/living/carbon/human/species_types/jellypeople.dm # code/modules/mob/living/damage_procs.dm # code/modules/mob/living/living.dm # code/modules/mob_spawn/ghost_roles/mining_roles.dm # code/modules/mob_spawn/mob_spawn.dm # code/modules/projectiles/ammunition/energy/laser.dm # code/modules/projectiles/guns/ballistic/launchers.dm # code/modules/projectiles/guns/energy/laser.dm # code/modules/reagents/chemistry/machinery/chem_dispenser.dm # code/modules/reagents/chemistry/reagents/cat2_medicine_reagents.dm # code/modules/reagents/chemistry/reagents/drinks/alcohol_reagents.dm # code/modules/reagents/chemistry/reagents/medicine_reagents.dm # code/modules/surgery/healing.dm # code/modules/unit_tests/designs.dm # icons/mob/inhands/items_lefthand.dmi # icons/mob/inhands/items_righthand.dmi # tgui/packages/tgui/interfaces/ChemDispenser.tsx |
||
|
Bloop
|
183c5af2e4 |
Adds flag for virtual areas, fixes being able to send funds from virtualspace to real accounts (#94071)
## About The Pull Request Fixes https://github.com/tgstation/tgstation/issues/90641 Fixes https://github.com/tgstation/tgstation/issues/88366 Eliminates worries over virtualspace currency being sent to real accounts. When I was looking into why there were no flags for bitrunning areas. Then I saw this mess: <img width="929" height="889" alt="Code_2we2QjDyFp" src="https://github.com/user-attachments/assets/8a807bfe-b566-4057-a8ea-2b306325687d" /> Not having enough space / being too lazy to refactor this is a silly reason to not include flags for something like these virtual areas where it can be quite helpful. Fortunately I am not too lazy ~~in this moment~~ so here we go: It was fairly logical to move over some of these to a separate flag, which I've called `area_flags_mapping` since they pertain to maploading things and terrain generation mostly. `area_flags` stays reserved for general properties and now has more room than it did before for you people to fill it with. In doing this it's also neatened up the code quit a bit, as UNIQUE_AREA was kind of everywhere and now that it's implied by default less areas need to have it defined (or explicitly un-defined). <details> <summary> Working as intended </summary> <img width="787" height="448" alt="dreamseeker_p0Qts36tG1" src="https://github.com/user-attachments/assets/25056f34-8d43-4be2-a293-e53df7a7d1db" /> <img width="383" height="59" alt="dreamseeker_Ek7TXCcpbA" src="https://github.com/user-attachments/assets/89622974-9467-4cdb-8345-d684f7c9004b" /> </details> ## Why It's Good For The Game Fixes an exploit, improves the area flags situation slightly. ## Changelog 🆑 fix: you can no longer send money from virtualspace to a real account code: adds a flag for virtual areas so they can easily be checked, as well as an easy helper proc, 'is_area_virtual(your_area)' /🆑 |
||
|
Time-Green
|
a66a60e711 |
1X3 ICEBOX | Wilderness Expansion (Now not extremely slow!) (#91920)
## About The Pull Request Turns the surface z-level of icebox into a 1x3 area, effectively adding 2 wilderness new z-levels surrounding the station Because it's not always clear to other people what I'm talking about, this is what I mean with making the surface level a 3x3 z-level The wilderness z-levels are gridlinked, instead of crosslinked, which just means the connections are consistent and not randomized. If you keep going right, you will always end up where you started again, eventually. This also removes the black border around the surface icebox z-level (cause you can just go there now) **Wilderness levels** I've added some Z-level templates that can be generated. They're incredibly basic, but all can spawn runes on them as well. - Snow planes (5x) - Ice planes (1x) - Forest planes (1x) - Mountain planes (1x) I've also tweaked surface generation quite a bit. It being completely covered in bones always felt weird, and the intersparsed rocks and chasms never sat right with me. The default overworldgen is now more like the Forested trait, but with more sparse trees. All of this is modular btw. You can increase the amount of z-levels, make any space z-level be unrandomized gridlinked or add your own wilderness z-levels (either to your own map or icebox) ## Why It's Good For The Game Icebox exploration is kind of depressing. We have this unique setting, but we can't really go anywhere? You can go down and find that one pool, which is about the peak of exploration of icebox. Now you can literally explore the entire round and get incredibly lost! It's also a great opportunity for mappers! (Especially since the templates I made were made rather quickly as I wasn't sure if this had merit). 2 extra z-levels isn't a lot, but it'll let us further develop planetary wilderness z-levels further without impacting load times that much. Maybe 3x3 icebox can be real in the future, but for now 1x3 icebox will have to do |
||
|
Time-Green
|
a47835a04f |
1X3 ICEBOX | Wilderness Expansion (Now not extremely slow!) (#91920)
## About The Pull Request Turns the surface z-level of icebox into a 1x3 area, effectively adding 2 wilderness new z-levels surrounding the station Because it's not always clear to other people what I'm talking about, this is what I mean with making the surface level a 3x3 z-level The wilderness z-levels are gridlinked, instead of crosslinked, which just means the connections are consistent and not randomized. If you keep going right, you will always end up where you started again, eventually. This also removes the black border around the surface icebox z-level (cause you can just go there now) **Wilderness levels** I've added some Z-level templates that can be generated. They're incredibly basic, but all can spawn runes on them as well. - Snow planes (5x) - Ice planes (1x) - Forest planes (1x) - Mountain planes (1x) I've also tweaked surface generation quite a bit. It being completely covered in bones always felt weird, and the intersparsed rocks and chasms never sat right with me. The default overworldgen is now more like the Forested trait, but with more sparse trees. All of this is modular btw. You can increase the amount of z-levels, make any space z-level be unrandomized gridlinked or add your own wilderness z-levels (either to your own map or icebox) ## Why It's Good For The Game Icebox exploration is kind of depressing. We have this unique setting, but we can't really go anywhere? You can go down and find that one pool, which is about the peak of exploration of icebox. Now you can literally explore the entire round and get incredibly lost! It's also a great opportunity for mappers! (Especially since the templates I made were made rather quickly as I wasn't sure if this had merit). 2 extra z-levels isn't a lot, but it'll let us further develop planetary wilderness z-levels further without impacting load times that much. Maybe 3x3 icebox can be real in the future, but for now 1x3 icebox will have to do |
||
|
SmArtKar
|
f740a1e9bb |
Corrects mining export names on icebox (#91145)
## About The Pull Request Closes #90666, converts minetypes to defines, gives icebox a minetype define which could also be used later to give mining suits some fur or something. ## Changelog 🆑 fix: Icebox artifact exports no longer claim they're from a lava planet /🆑 |
||
|
SmArtKar
|
29d9626d3d |
Corrects mining export names on icebox (#91145)
## About The Pull Request Closes #90666, converts minetypes to defines, gives icebox a minetype define which could also be used later to give mining suits some fur or something. ## Changelog 🆑 fix: Icebox artifact exports no longer claim they're from a lava planet /🆑 |
||
|
John Willard
|
df10c57593 |
webmap is now in maps.txt instead of a config entry (#90821)
## About The Pull Request Currently the button to open a map in webmap is tied to a config entry, which would then take the name of the map being played and get the link to that, however for cases like new/tested/admin uploaded maps where there is no webmap available, this would still have a link to a url that doesn't exist. Instead, we'll make the webmap link be in ``maps.txt``, same as feedbacklink. ## Why It's Good For The Game Explained in the about section, this prevents webmaps appearing for maps that aren't supposed to have a webmap link available. ## Changelog Nothing player-facing, webmaps aren't currently used (afaik) currently cause they're broken for tg codebases. |
||
|
John Willard
|
400e6c15e4 |
webmap is now in maps.txt instead of a config entry (#90821)
## About The Pull Request Currently the button to open a map in webmap is tied to a config entry, which would then take the name of the map being played and get the link to that, however for cases like new/tested/admin uploaded maps where there is no webmap available, this would still have a link to a url that doesn't exist. Instead, we'll make the webmap link be in ``maps.txt``, same as feedbacklink. ## Why It's Good For The Game Explained in the about section, this prevents webmaps appearing for maps that aren't supposed to have a webmap link available. ## Changelog Nothing player-facing, webmaps aren't currently used (afaik) currently cause they're broken for tg codebases. |
||
|
John Willard
|
ea28a87ca8 |
Adds map feedback thread support (AI stat panel buff) (#90506)
This PR started with the idea of adding support for map feedback threads, which I added to the roundend report, escape menu, and stat panel. To do this though I had to make pretty annoying changes to the stat panel and had to touch every single time something to the stat panel was added, so since we now have a way to have links in the stat panel I thought of taking full advantage of it and add some QOL. AIs can now track their borgs by clicking their status on the stat panel https://github.com/user-attachments/assets/1789dc46-5d12-48e9-bb8d-d3278aa19639 With Melbert's comment, I added another stat panel entry that directs you to the Webmap page, which currently seems to be a little messed up (https://github.com/AffectedArc07/SS13WebMap/issues/41 & https://github.com/AffectedArc07/SS13WebMap/issues/42) but if they get fixed this would be a swag asf feature Feedback threads was a suggestion from a player and is fully in control of admins as an optional thing, and while we still have stat panel I think it's nice to be able to take advantage of its features. 🆑 admin: Admins can now link a URL for maps, used to give feedback on said maps. Accessible through the roundend report, escape menu, and stat panel. qol: AIs can track their borgs by clicking on them in the stat panel. qol: You can now directly go to the webmap of maps from the stat panel (assuming it's set in config). /🆑 |
||
|
Bloop
|
29e2f867b8 |
Adds some trailing commas to lists (#90501)
## About The Pull Request I heard you liked commas. ## Why It's Good For The Game Trailing commas make everyone happy! ## Changelog Nothing anyone will notice besides downstreams adding to these lists |
||
|
Watermelon914
|
79b00baad2 |
Refactors subsystems to use dependency-ordering to determine init order. Subsystems can now declare their own dependencies. (#90268)
## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
|
||
|
John Willard
|
380c143431 |
Adds map feedback thread support (AI stat panel buff) (#90506)
## About The Pull Request This PR started with the idea of adding support for map feedback threads, which I added to the roundend report, escape menu, and stat panel. To do this though I had to make pretty annoying changes to the stat panel and had to touch every single time something to the stat panel was added, so since we now have a way to have links in the stat panel I thought of taking full advantage of it and add some QOL. AIs can now track their borgs by clicking their status on the stat panel https://github.com/user-attachments/assets/1789dc46-5d12-48e9-bb8d-d3278aa19639 With Melbert's comment, I added another stat panel entry that directs you to the Webmap page, which currently seems to be a little messed up (https://github.com/AffectedArc07/SS13WebMap/issues/41 & https://github.com/AffectedArc07/SS13WebMap/issues/42) but if they get fixed this would be a swag asf feature ##### Code bounty for Ezel/Improvedname ## Why It's Good For The Game Feedback threads was a suggestion from a player and is fully in control of admins as an optional thing, and while we still have stat panel I think it's nice to be able to take advantage of its features. ## Changelog 🆑 admin: Admins can now link a URL for maps, used to give feedback on said maps. Accessible through the roundend report, escape menu, and stat panel. qol: AIs can track their borgs by clicking on them in the stat panel. qol: You can now directly go to the webmap of maps from the stat panel (assuming it's set in config). /🆑 |
||
|
Bloop
|
d71375eafd |
Adds some trailing commas to lists (#90501)
## About The Pull Request I heard you liked commas. ## Why It's Good For The Game Trailing commas make everyone happy! ## Changelog Nothing anyone will notice besides downstreams adding to these lists |
||
|
Watermelon914
|
6c017cf1e1 |
Refactors subsystems to use dependency-ordering to determine init order. Subsystems can now declare their own dependencies. (#90268)
## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
|
||
|
Majkl-J
|
b6b8306fda | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-02a | ||
|
Lucy
|
2ee02682f7 |
Converts most other usages of block() to x/y/z format (#89290)
## About The Pull Request The sequel to https://github.com/tgstation/tgstation/pull/89234 > someone should do the rest at some point guess what, I'm that someone :3 ## Why It's Good For The Game Same reasoning as the previous PR: > less cluttered code is nice, and it should in theory be more optimized as we avoid the need to run min, max, and locate. ## Changelog No user-facing changes |
||
|
Aylong
|
2d549e2945 |
Allow to hide Initialized mesages (#88681)
## About The Pull Request Adds `Debug` group to initialization messages ## Why It's Good For The Game You can finally hide those annoying messages, and leave it on special Logs/Debug tabs <details><summary>Video</summary> https://github.com/user-attachments/assets/0b0d5219-d420-4d49-aa90-069961dcdaeb </details> ## Changelog 🆑 qol: Now you can hide `Initialized some shit within 0s` messages, by unchecking `Debug Log` checkbox into the chat tabs settings /🆑 |
||
|
Tim
|
189616ae2c |
Add better logging for ruins (#88403)
## About The Pull Request ~~This adds a new test for the CI/CD so that we can load all space ruins instead of it being RNG.~~ Adds more robust logging for ruins so we can see when they fail/succeed and how many are placed on a map. This also removes a deprecated CI config setting. It prevented ALL ruins from spawning during CI tests which is bad. The config setting was made redundant in: - #87910 ## Why It's Good For The Game More robust CI/CD. ## Changelog 🆑 code: Add better logging for ruins /🆑 |
||
|
Tim
|
7a32a4a8ee |
Automatically link maps multi-z up/down traits (#87029)
This autoloads the up/down traits for every map instead of having to manually add those traits to the JSON. More automation good. Also let's people experiment with larger maps like a multi-z lavaland. 🆑 code: Automatically link maps multi-z up/down traits /🆑 |
||
|
BluBerry016
|
437145131e |
Makes #87029 Opt-Out (#87714)
## About The Pull Request Adds a new boolean that lets you opt out of automatically linking zlevels in `LoadGroup()` (as implemented in https://github.com/tgstation/tgstation/pull/87029); and forwards that support to map jsons. Does ***not*** change any /tg/ map jsons in the process; as they all still work as intended. A modified Icebox JSON loading correctly:  ### How do I disable automatic z-level linking? Add the following to your json; under planetary: ``` "height_autosetup": 0, ``` For each z-level's trait; you can then add either `"Up": true` or `"Down": true` to link them manually, as you would've prior to #87029 . ## Why It's Good For The Game tl;dr, map experimentation. It was prior possible to have station segments separated by z-level that weren't vertically linked; which was put to practice most prominently on Nova Sector, of all places, - but #87029 made it automatically assume that they should be linked in that manner. This middleground keeps the new assumption while preserving the old manual process for any mapping projects that need it. ## Changelog 🆑 code: Mappers can now opt out of automatically linking their up/down station traits. /🆑 |
||
|
Majkl-J
|
e59d8ba64b | Merge commit '179a607a90ad7ec62bdaff4e6fe72af60ee56442' of https://github.com/tgstation/tgstation into upstream-24-10b | ||
|
Waterpig
|
bb70889f6e |
TG Upstream Part 1
3591 individual conflicts Update build.js Update install_node.sh Update byond.js oh my fucking god hat slow huh holy shit we all fall down 2 more I missed 2900 individual conflicts 2700 Individual conflicts replaces yarn file with tg version, bumping us down to 2200-ish Down to 2000 individual conflicts 140 down mmm aaaaaaaaaaaaaaaaaaa not yt 575 soon 900 individual conflicts 600 individual conflicts, 121 file conflicts im not okay 160 across 19 files 29 in 4 files 0 conflicts, compiletime fix time some minor incap stuff missed ticks weird dupe definition stuff missed ticks 2 incap fixes undefs and pie fix Radio update and some extra minor stuff returns a single override no more dupe definitions, 175 compiletime errors Unticked file fix sound and emote stuff honk and more radio stuff |
||
|
Tim
|
ff7fb30783 |
Automatically link maps multi-z up/down traits (#87029)
## About The Pull Request This autoloads the up/down traits for every map instead of having to manually add those traits to the JSON. ## Why It's Good For The Game More automation good. Also let's people experiment with larger maps like a multi-z lavaland. ## Changelog 🆑 code: Automatically link maps multi-z up/down traits /🆑 |
||
|
Zephyr
|
0ef5c3d049 |
Persistent Map Vote Tallies (#86788)
## About The Pull Request Changes map votes to be based on a persistent tally count. Tallies for maps are cached between rounds and are added to by map votes. When a map is chosen, and it wasn't the only valid one, the tallies for said chosen map will be reset. Refactors map vote handling and moves it from SSmapping to SSmap_vote. Rock the Vote has been removed as a result of this refactor. ## Why It's Good For The Game Makes it more likely that all maps will be played over the course of a server instead of always being truly random. Removes some clutter off of SSmapping. 🆑 refactor: Map Votes are now carried over between rounds. When a map vote is actually a contest, the winning map will have its votes reset. /🆑 |
||
|
Waterpig
|
4c4930c71d | Merge branch 'master' of https://github.com/tgstation/tgstation into pulls-tg-to-fix-shit | ||
|
SkyratBot
|
e93c6c3199 |
[MIRROR] Block atmos processing on ReservedTurfs\™️ (#29368)
* Block atmos processing on ReservedTurfs\™️ (#84873) ## About The Pull Request See title. ## Why It's Good For The Game We get constant runtimes and issues from atmos processing on turfs we are actively loading and/or reserving. I promised I would do something about this months ago --------- Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com> * Block atmos processing on ReservedTurfs\™️ --------- Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com> |
||
|
Zephyr
|
52f7f44215 |
Block atmos processing on ReservedTurfs\™️ (#84873)
## About The Pull Request See title. ## Why It's Good For The Game We get constant runtimes and issues from atmos processing on turfs we are actively loading and/or reserving. I promised I would do something about this months ago --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
SpaceLoveSs13
|
fa2ab65f07 |
Missed mirrors (#28919)
Handful of missed mirrors (#3739) * fix duplicate traits * Adds a Contraband trait, and implements contraband as a mechanic to security bounties. (#84003) This PR does a few things but centrally it's all centered around mechanically enforcing what items are and are-not considered contraband in-game. Contraband items are visually indistinguishable from non-contraband. If an item is Contraband, it can only be detected in two ways: * After being scanned by an N-Spect scanner, which is a standard item security item, assuming it still has a charge to do so. * Via a scanner gate, which can now be upgraded with an N-spect scanner to allow for it to scan a person and all their contents for contraband. Contraband items are intended to be determined both logically and through other relevant examine text. However, here's the short list of items that are considered contraband, reserving the right to expand the list. <details> <summary>In hindsight it's kind of a long list.</summary> * Items that have "contraband" or "illegal" in the name or description. * Items that allow for the player to obtain other illegal items, that are NOT particularly stealthy. * This means that a syndicate uplink is NOT considered contraband, as they're typically hidden on your person as something else. * Stealth items under the syndicate uplink, the revolutionary flash, and some mapped in dangerous items that can come from both syndicate and company-aligned resources are not considered dangerous. * Items that are purchased from cargo after emagging or switching to extended cargo range. * Items purchased FROM syndicate uplinks, the wizard knowledge scroll, or other antagonist shops. * Cursed artifacts/tools magically produced by cultists or heretics. * Items purchased from the blackmarket. * Items purchased from the contraband section of vending machines. * Some drugs and overtly dangerous or criminal byproducts. </details> Well, primarily, this is an aid for in-game enforcement of space law. Based on the length of the above list, we have a LONG, LONG list of items in-game that are technically considered, in one way or another, illegal to have on the station, and yet without either metaknowledge of what those items are, or how they're used, security officers lack some of the certainty of how to deal with these kinds of encounters. Additionally to the knowledge aspect of this trait, security officers may now receive a new civilian bounty to collect items that are considered contraband, also giving them an incentive to look for and confiscate contraband that's been found across the station while upholding space law. Security has a bounty for 3 different rechargers, and considering access limitations, most security players aren't going to make this exchange, so I've lowered the required amount down to 1. Adjusted the N-spect scanner's description to match it's new functionality. The Civilian bounty TGUI now has an additional 1 point of padding to make it feel less cramped. https://github.com/tgstation/tgstation/assets/41715314/c3cd4752-b03a-4e0b-959e-1252fcc2369d **Updated as of 6/19/2024:** Additionally, some storage items will block the presence of contraband when going through a contraband aligned scanning gate. These items include the infiltrator modsuit core, storage implant, void cloak, the aptly named smuggler's satchel, and the chameleon kit's backpack. **Updated as of 6/23/2024:** N-spect scanner now has contextual screentips. **Updated as of 6/29/2024:** Scanner gates are now available in all lathes that have a feature specific to how scanner gates function. So, includes cargo (contraband), security (weapons), and medbay (diseases). Originally, this started out as a way to be able to provide more in-character and in-flavor bounties for security officers, because they suck! Most security bounties as they exist right now do the worst possible things from all respective bounties: * They detract away from a job's actual responsibilities as opposed to working with them. * They're best completed while sitting next to your lathe and running items back to the bounty pad. * They exist with such esoteric rarity of high quantity of items that it's miserable to fulfil. As a result, I started work on this as a framework to allow security officers to be further incentivized to collect contraband across the station, either as a result of the gamemode or just through routine patrols across the station. Implementing it as a learning tool for security as well just happened to work out as an additional bonus, and having a function in-game allowing newer or less experienced players to know if an item is considered dangerous or conspicuous also works as a particularly good way to provide information where a player may not know what they're up against. If nothing else, this might be interesting to try, and if not, I'll just snip out the QOL changes from it and we'll see how it goes. Going forward, I am a bit hesitant about the contraband scanner gate mode, and as such, will try working with the admin team to determine if that's a good feature to keep around for game health, while hoping to give it a chance in the fullness of time. 🆑 add: Items spawned via traitor uplinks or are known illegal contraband on the station can now be scanned and identified as such by the N-spect scanners in security. These only applies to overt traitor or antagonist items, and "stealth" items will not be seen as such. add: Scanner gates can now be upgraded by using an N-spect scanner on it to unlock "contraband scanning" mode. add: Security officers can now be offered a bounty to turn in pieces of contraband. add: Some stealthy storage items like storage implants, smuggler's satchels, void cloaks, the infiltrator modsuit, and the chameleon backpack will block the presence of contraband on your person when placed inside. qol: N-spect scanner contextual screentips. balance: Recharger security bounties ask for a quantity of 1, down from 3. qol: security, cargo, and medbay have access to scanner gate boards. /🆑 --------- * Adds six new strange object powers! (#84775) DESIGN CONCEPT: Strange Devices are at their best when they're odd tools which can help a department out, with some strange drawbacks that make them interesting and unique. Foam for the Janitor, Flashbang for Security, Teleporter for tiders, Corgimaker for the chef. They're also ambiguous enough that they can really be used by anyone for silly hijinks. Drink Dispenser: Creates a glass, then fills it up with a random drink. Bioscrambler: After a noticeable warning, bioscrambles people nearby. 33% chance to be used up on use. Recharger: Shocks you, but recharges one random item to max battery. Hugger: Hugs everyone in range as if you had the friendly trait. DImensional: Converts the surroundings to a random material-theme. Each use increases cooldown by two seconds. Disguiser: Drops your clothing to the ground and replaces it with a delete-on-drop costume and a randomly assigned cardboard ID. Removed an unused and unusable shock flag. Removed an unused dumb ghost item. Added a proc that returns a hex color with the # attached. > DESIGN CONCEPT: Strange Devices are at their best when they're odd tools which can help a department out, with some strange drawbacks that make them interesting and unique. Foam for the Janitor, Flashbang for Security, Teleporter for tiders, Corgimaker for the chef. They're also ambiguous enough that they can really be used by anyone for silly hijinks. Request by ArcaneMusic! He wanted new abilities to go along with the new sprites, and approved these. > Removed an unused dumb ghost item. please stop using costume subtypes for OP items. whats the damn point of the subtype if youre just going to screw with it > Added a proc that returns a hex color with the # attached. idk why it didnt have this tbh 🆑 add: Adds six new strange object powers! Drink dispenser, bioscrambler, recharger, hugger, dimensional, disguiser. code: Removed some unused code and items, and added a proc that returns a random #colorstring. /🆑 * [NO GBP] the random spawner loot weight config is not an integer (#84814) Sets `integer` to false. Also a tidbit about the `skew_loot_weight` proc, though loot lists with uneven weights all tend to add a value to all entries so it isn't an issue. The config isn't an integer. N/A * The techweb no longer erroneously refers to MODsuits as exosuits (#84800) At some point, some of the techweb node descriptions were changed, so that it referred to certain modsuits as exosuits. This just changes it back. The term "exosuit" is generally used for mechs, not modsuits. The techweb descriptions should refer to modsuits as modsuits. 🆑 spellcheck: The techweb no longer erroneously refers to MODsuits as exosuits. /🆑 * Adds new hairstyle - Short Bangs 2 (#84804) Adds a new hairstyle called Short Bangs 2. The hairstyle is basically an edit of the existing double buns, except the hair buns themselves are removed. https://github.com/tgstation/tgstation/assets/66234359/38fe3b09-c42b-43e6-9e30-949428aab506 More customization, variety and character flavor is great. Double buns itself is a good hairstyle but some may not like the hair buns out of personal preference or that it can look weird on non-human species like felinids. 🆑 Hardly3D add: Added new hairstyle: Short Bangs 2 /🆑 * Offset render relays for non-offsetting planes to match highest matching render plane (#84184) **Alternate title: "Fix blind people getting so blind they become deaf when going down a flight of stairs"** So 'bout half a week to a week ago I overheard a friend complaining about blind people not seeing runechat on lower multi-z levels. Asked a bit, apparently they'd reported this about half a year ago, and it's still an issue. So in my never-ending hubris I decided to just go and fix it! Now, admittedly? I really _really_ do not get the rendering system we use. The simple options were right out: we can't allow the fullscreens plane to be offset, as this causes issues with looking up/down, or disallow runechat from being offset, which causes issues with runechat from other levels. After poking our very cool and smart rendering guy several times over the course of the last week, this is what we got to: We simply make the rendering relays for non-offsetting plane masters point to the highest rendering plane that matches the target. We do this by offsetting the rendering relays in place, by adjusting their plane and layer values to match the new offset, with a new `offset_relays_in_place(new_offset)` proc called in `/datum/plane_master_group/proc/transform_lower_turfs(...)`. Importantly, we compare the current layer values to what they should've been, so we don't accidentally override relays with custom-set layers. This fixes our issue (as tested on wawastation): <details> <summary>Images</summary>    </details> Fixes #80376. 🆑 fix: You can see runechat above fullscreen overlays on lower multi-z levels again. Rejoice, blind players. Please report any weird rendering layering issues. /🆑 * illegal tech flag got changed * Automatic changelog for PR #84003 [ci skip] * Automatic changelog for PR #84775 [ci skip] * Automatic changelog for PR #84800 [ci skip] * Automatic changelog for PR #84804 [ci skip] * Automatic changelog for PR #84184 [ci skip] * Makes the smoking pipe sprite not give you a phantom stache. (#84898) The smoking pipe currently gives you a phantom stache. Observe, note the black background and know this character has no facial hair.  I basically adjusted the pixels so it'd look better from different directions. This is the new look - approximately.  Smoking pipe is cool for RP but the sprite's fucked. 🆑 image: the smoking pipe's directional looks have been altered to make it less ugly /🆑 (cherry picked from commit |
||
|
_0Steven
|
5e753b6788 |
Offset render relays for non-offsetting planes to match highest matching render plane (#84184)
## About The Pull Request **Alternate title: "Fix blind people getting so blind they become deaf when going down a flight of stairs"** So 'bout half a week to a week ago I overheard a friend complaining about blind people not seeing runechat on lower multi-z levels. Asked a bit, apparently they'd reported this about half a year ago, and it's still an issue. So in my never-ending hubris I decided to just go and fix it! Now, admittedly? I really _really_ do not get the rendering system we use. The simple options were right out: we can't allow the fullscreens plane to be offset, as this causes issues with looking up/down, or disallow runechat from being offset, which causes issues with runechat from other levels. After poking our very cool and smart rendering guy several times over the course of the last week, this is what we got to: ### The technical bits We simply make the rendering relays for non-offsetting plane masters point to the highest rendering plane that matches the target. We do this by offsetting the rendering relays in place, by adjusting their plane and layer values to match the new offset, with a new `offset_relays_in_place(new_offset)` proc called in `/datum/plane_master_group/proc/transform_lower_turfs(...)`. Importantly, we compare the current layer values to what they should've been, so we don't accidentally override relays with custom-set layers. This fixes our issue (as tested on wawastation): <details> <summary>Images</summary>    </details> ## Why It's Good For The Game Fixes #80376. ## Changelog 🆑 fix: You can see runechat above fullscreen overlays on lower multi-z levels again. Rejoice, blind players. Please report any weird rendering layering issues. /🆑 |
||
|
SpaceLoveSs13
|
a9ff046352 |
Administrator Cherrypick (#27405)
* Admin Verb Datums MkIII | Now with functional command bar (#82511) * Modular stuffs * Put some admin jump verbs back into the context menu | sorts area jump list again (#82647) ## About The Pull Request See title. ## Why It's Good For The Game Some admins wanted all the jump verbs back, aswell as making them not AGhost you. Also make the Jump To Area verb use a sorted list again * Hey what if admins were allowed to use the player panel (#82682) Re-adds the player panel verb to the verb panel. * Controller Overview UI (#82739) * Fixes a minor spelling mistake on the admin panel/verb list (#82747) ## About The Pull Request Corrects `inisimin` to `invisimin`. This addresses #82728, but only fixes one of the two issues mentioned ## Why It's Good For The Game -1 spelling mistake ## Changelog 🆑 spellcheck: 'inisimin' verb corrected to 'invisimin' /🆑 * Player Panel-age (#82757) * Admin Forced Mob Rename and Preference Update (#82715) --------- Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> Co-authored-by: chel <64568243+iliyaxox@users.noreply.github.com> |
||
|
Zephyr
|
7f8752be14 | Admin Verb Datums MkIII | Now with functional command bar (#82511) | ||
|
SkyratBot
|
602ac52e9d |
[MIRROR] Fixes ore vents spawning without ores on icebox, sets up map specific ore configurations (#26375)
* 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. /🆑 * Fixes ore vents spawning without ores on icebox, sets up map specific ore configurations --------- Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> |
||
|
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. /🆑 |
||
|
SkyratBot
|
5543a44882 |
[MIRROR] ArcMining Pr Beta: Version 1.2 (#26205)
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.** Click the link below to see a video summary of the main features of this pull request. https://youtu.be/Aho2omR0mjY?feature=shared 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. 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 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. 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 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 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. 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. 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. 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. 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. - 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** 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 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. 🆑 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: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> 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> |
||
|
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> |
||
|
SkyratBot
|
ab5a4d0f99 |
[MIRROR] split area.contained_turfs up by zlevel, make init 10 seconds faster (#26161)
* 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. * split area.contained_turfs up by zlevel, make init 10 seconds faster * eeyes * Update area_spawn_subsystem.dm * Unshits turf contain code slightly (#81023) Literally just implements my reviews from #80941 I am frankly a smidge pissed that the pr was merged without them being handled. No code is worth merging past known issues, and if the author is just gonna dip then that's life. I don't like privileging mso on stuff like this, especially because frankly I'm kinda mad at him rn but also because when a pr is made the onus on finishing it falls to the person who made it. Should not need to clean up after someone as a maintainer, and shouldn't normalize doing it. I'm not like mad at zypher directly mind he offered to do this too, just the idea he was espousing here. --------- Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
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. |
||
|
SkyratBot
|
17a7b8f2fb |
[MIRROR] Starlight Control (Aurora works now, space gas doesn't touch starlight, narsie ending effects) [MDB IGNORE] (#24406)
* 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](https://github.com/tgstation/tgstation/commit/af34f06b418b039b2ead90b29112b30adea4bc68) 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](https://github.com/tgstation/tgstation/commit/9da4bc38e223e0ce2d91b0c8beddf1ebba968b9c) 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.](https://github.com/tgstation/tgstation/commit/5f701a1b137c7d4c333929e4cbfdd9d4aa8656d6) 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](https://github.com/tgstation/tgstation/pull/78877/commits/a423cfcb2ba9c0d729b06c36dd7d38ff68c967c2) 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 /🆑 * Starlight Control (Aurora works now, space gas doesn't touch starlight, narsie ending effects) * Update space.dm * Update shuttles.dm --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
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](https://github.com/tgstation/tgstation/commit/af34f06b418b039b2ead90b29112b30adea4bc68) 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](https://github.com/tgstation/tgstation/commit/9da4bc38e223e0ce2d91b0c8beddf1ebba968b9c) 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.](https://github.com/tgstation/tgstation/commit/5f701a1b137c7d4c333929e4cbfdd9d4aa8656d6) 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](https://github.com/tgstation/tgstation/pull/78877/commits/a423cfcb2ba9c0d729b06c36dd7d38ff68c967c2) 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 /🆑 |
||
|
SkyratBot
|
d9624bdf97 |
[MIRROR] Multi-Z Support for Lazy Templates | Cleans up some turf flag misuse [MDB IGNORE] (#23794)
* Multi-Z Support for Lazy Templates | Cleans up some turf flag misuse * Update hilbertshotel.dm * Modular proc ref --------- Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
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> |
||
|
SkyratBot
|
e884af7b5b |
[MIRROR] Demonic Frost Miner can spawn again [MDB IGNORE] (#23484)
* 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> * Demonic Frost Miner can spawn again --------- Co-authored-by: Whoneedspacee <yougotreallyowned@gmail.com> Co-authored-by: Changelogs <action@ github.com> |
||
|
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> |
||
|
Bloop
|
3569f9fd94 |
[MISSED MIRROR] Loads Away Missions for Unit Testing (#76245) (#22534)
* Loads Away Missions for Unit Testing (#76245)
Hey there,
A pretty bad bug (#76226) got through, but it was fixed pretty quickly
in #76241 (
|
||
|
SkyratBot
|
4f48be9809 |
[MIRROR] Planetary station traits: Forever Storm and Forested [MDB IGNORE] (#22763)
* Planetary station traits: Forever Storm and Forested * Update CaveGenerator.dm * Update CaveGenerator.dm --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
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 /🆑 |
||
|
Bloop
|
b674e72ef1 |
[MISSED MIRROR] Macros multi-z code, removes the false premise of manual offsets (#76248) (#22531)
* Macros multi-z code, removes the false premise of manual offsets (#76248) ## About The Pull Request [Removes the pretense of relative multiz levels](https://github.com/tgstation/tgstation/pull/76248/commits/0293fdc2bd8c8af7a0d18da33265e060789c71f7) 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](https://github.com/tgstation/tgstation/commit/7d698f02d991eb4e1bde56314c657cf6e48ceb5d) 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 * modular files how very dare you --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
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 (
|
||
|
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](https://github.com/tgstation/tgstation/pull/76248/commits/0293fdc2bd8c8af7a0d18da33265e060789c71f7) 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](https://github.com/tgstation/tgstation/commit/7d698f02d991eb4e1bde56314c657cf6e48ceb5d) 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 |
||
|
SkyratBot
|
4c6567976b |
[MIRROR] Removes per z level station relays, allows tcomms to reach across interconnected zs [MDB IGNORE] (#22111)
* 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. /🆑 * Removes per z level station relays, allows tcomms to reach across interconnected zs --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com> |