mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-18 21:15:21 +00:00
403274ff62d14466c0057d4bfeeec1fa1bb19f27
207 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
YesterdaysPromise
|
fb10121022 |
Icons folder cleaning wave two (#76788)
## About The Pull Request Further continous organizing and cleaning the Icons folder. There are still some minior nitpicks left to do, but I reached my daily sanity expenses limit again, and the faster these get in the less issues for both me and others later. Also cleans some mess I caused by my blindness last PR. ## Why It's Good For The Game Saner spriters = better sprites |
||
SyncIt21
|
dcd20ab4a0 |
Jetpack component & Modsuit module signal clean-up & fixes (#76133)
## About The Pull Request 1. Removed the `get_mover` callback, the mover can be retrieved during activation itself 2. Fixes #76116 the user is passed correctly during activation & deactivation same for modsuit modules and this also fixes the same bug for `/obj/item/organ/internal/cyberimp/chest/thrusters` as it's signal was also not registered correctly with the user 3. Timestop module on `on_module_triggered()` accepts user as 2nd param ## Changelog 🆑 fix: jetpack modules work on mod suits again fix: jetpack cyber implants also work refactor: removed `get_mover` callback, user is retrieved during activation refactor: timestop module on `on_module_triggered()` accepts user as 2nd param /🆑 |
||
Stonetear
|
07ac92015c |
Fixes stowing suit storage jetpacks when retracting modsuit chestplates (#75844)
## About The Pull Request This is a bizare bug I discovered while trying to develop another feature, so let's just get into the reproduction steps: - Wear a modsuit and extend it's parts - Put a jetpack in the suit storage slot and turn it on. Currently, the only jetpack that fits in the storage slot on TG is the captain's jetpack. - While the jetpack is activated, deactivate your modsuit using the UI, which stows the jetpack into your storage module automatically. - This fails to unregister some signal thing because it can't find the user. My fix *could* be shitcode, so any feedback would be appreciated. Jetpack activation and deactivation signals now pass a user. `/datum/component/jetpack/proc/activate(datum/source, mob/user)` `/datum/component/jetpack/proc/deactivate(datum/source, mob/user)` Some jetpack `pre_move_react` thing now has a check to see if it's argument is null. ``` if(!trail) return FALSE ``` ## Why It's Good For The Game Stops a crash/runtime. ## Changelog 🆑 stonetear fix: jetpack signals now pass a user argument. This fixes an error when automatically stowing a captain jetpack into your modsuit. /🆑 |
||
LemonInTheDark
|
ae5a4f955d |
Pulls apart the vestiges of components still hanging onto signals (#75914)
## About The Pull Request Signals were initially only usable with component listeners, which while no longer the case has lead to outdated documentation, names, and a similar location in code. This pr pulls the two apart. Partially because mso thinks we should, but also because they really aren't directly linked anymore, and having them in this midstate just confuses people. [Renames comp_lookup to listen_lookup, since that's what it does]( |
||
ShizCalev
|
d927f28951 |
Makes update_icon_updates_onmob more robust (#75324)
Safeguards against #74965 happening in the future. Noticed a bunch of these were using ITEM_SLOT_HANDS. This is incorrect, as the element already automatically updates held items. grep'd it to catch future instances. Likewise, a number of objects weren't passing slot_flags to the element, meaning it wasn't actually updating those things properly when they were being worn. I've simplified this so now the element will automatically update all slot_flags, and passing an additional slot to the element when being added is only needed for additional slots that might need to be updated. This also means if slot_flags change, the element will now update correctly as well. 🆑 ShizCalev code: The update_icon_updates_onmob element will now automatically update all slots in an item's slot_flags var. This does fix multiple things that weren't updating properly. Passing a slot to the element is now only necessary if you want to add additional slots to be updated. /🆑 |
||
ArcaneMusic
|
f2fd69a49a |
Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. (#75052)
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you all here (through the automatic reviewer request system). So, mineral balance! Mineral balance is less a balance and more of a nervous white dude juggling spinning plates on a high-wire on his first day. The fact it hasn't failed after going on this long is a miracle in and of itself. This PR does not change mineral balance. What this does is moves over every individual cost, both in crafting recipes attached to an object over to a define based system. We have 3 defines: `sheet_material_amount=2000` . Stock standard mineral sheet. This being our central mineral unit, this is used for all costs 2000+. `half_sheet_material_amount=1000` . Same as above, but using iron rods as our inbetween for costs of 1000-1999. `small_material_amount=100` . This hits 1-999. This covers... a startlingly large amount of the codebase. It's feast or famine out here in terms of mineral costs as a result, items are either sheets upon sheets, or some fraction of small mats. Shout out to riot darts for being the worst material cost in the game. I will not elaborate. Regardless, this has no functional change, but it sets the groundwork for making future changes to material costs much, MUCH easier, and moves over to a single, standardized set of units to help enforce coding standards on new items, and will bring up lots of uncomfortable balance questions down the line. For now though, this serves as some rough boundaries on how items costs are related, and will make adjusting these values easier going forward. Except for foam darts. I did round up foam darts. Adjusting mineral balance on the macro scale will be as simple as changing the aforementioned mineral defines, where the alternative is a rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~ Items individual numbers have not been adjusted yet, but we can standardize how the conversation can be held and actually GET SOMEWHERE on material balance as opposed to throwing our hands up or ignoring it for another 10 years. |
||
oranges
|
4c48966ff8 |
Renames delta time to be a more obvious name (#74654)
This tracks the seconds per tick of a subsystem, however note that it is not completely accurate, as subsystems can be delayed, however it's useful to have this number as a multiplier or ratio, so that if in future someone changes the subsystem wait time code correctly adjusts how fast it applies effects regexes used git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i 's/DT_PROB/SPT_PROB/g' git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i 's/delta_time/seconds_per_tick/g' |
||
Tim
|
a1ada2c9ef |
Refactor, improve, and rename canUseTopic to be can_perform_action (#73434)
This builds on what #69790 did and improved the code even further. Notable things: - `Topic()` is a deprecated proc in our codebase (replaced with Javascript tgui) so it makes sense to rename `canUseTopic` to `can_perform_action` which is more straightforward in what it does. - Positional and named arguments have been converted into a easier to use `action_bitflag` - The bitflags adds some new checks you can use like: `NEED_GRAVITY | NEED_LITERACY | NEED_LIGHT` when you want to perform an action. - Redundant, duplicate, or dead code has been removed. - Fixes several runtimes where `canUseTopic` was being called without a proper target (IV drips, gibber, food processor) - Better documentation for the proc and bitflags with examples |
||
|
oranges
|
3869634972 |
Made assembly bombs unable to multignite (#73446)
Added stack traces for multignition events Also moves the tank procs into the tanks file from bomb because I can and I hate the previous organisation |
||
CapybaraExtravagante
|
bd81d32080 |
Makes some improvements to how AI can use JPS with movement loops (#72685)
## About The Pull Request This PR makes some changes to how JPS is used in movement loops, as it was causing a variety of issues: - Fixed some code where JPS would fail because the path is still being made. Instead, the movement loop will now wait. - Reduced the subsystem wait for the pathfinder subsystem from 2 seconds to 0.1 seconds. @LemonInTheDark told me that this is better, I'll update this with a better explanation once I squeeze it out of him :D - Allows you to provide an initial path to the movement loop, in case you pre-calculated one while making a plan. ## Why It's Good For The Game Makes working with JPS a bit easier when making AI. --------- Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com> Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
Tastyfish
|
c51b43f838 |
Fix some reference leaks (#72669)
## About The Pull Request For some reason, this repo doesn't have a problem with these references, but the downstream I work on catches these on the new 515 alternative GC test 100% of the time, despite us having not modifying these types. Go figure. Removed the tank var from the mister as it's basically unused except to leak a reference. ## Why It's Good For The Game Garbage collector happy ## Changelog Not player-facing Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> |
||
Jeremiah
|
872e64fb05 |
Adds spaces around logical operators (#72603)
## About The Pull Request Part of a prior PR that was closed (#72562). This version does not add the check in CI. ## Why It's Good For The Game The work is already done, so I figured why not. ## Changelog N/A Nothing player facing Co-authored-by: Jeremiah Snow <jlsnow301@pm.me> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
Mothblocks
|
f54dcda1c0 |
afterattack now returns a flag if it's reasonable to suspect the user intends to act on an item (#72320)
Necessary for #72292 to work effectively, and probably not very useful out of that context. Split out of its own PR because this is long and boring. I want to make sure that we're catching actual mistakes there, and not just experiencing side effects of how shitty the attack chain is. |
||
Zephyr
|
6a0c884410 |
[no gbp] removes all duplicate armor datums (#72354)
## About The Pull Request closes #72348 Title ## Why It's Good For The Game My bad ## Changelog Heres the script I used this time if you want to ```cs var baseDir = Environment.CurrentDirectory; var allFiles = Directory.EnumerateFiles($@"{baseDir}\code", "*.dm", SearchOption.AllDirectories).ToList(); var known = new Dictionary<string, List<KeyValuePair<string, int>>>(); foreach (var file in allFiles) { var fileLines = File.ReadAllLines(file); for (var i = 0; i < fileLines.Length; i++) { var line = fileLines[i]; if (line.StartsWith("/datum/armor/")) { var armorName = line.Replace("/datum/armor/", "").Trim(); if (!known.ContainsKey(armorName)) known[armorName] = new List<KeyValuePair<string, int>>(); var knownList = known[armorName]; knownList.Add(new KeyValuePair<string, int>(file, i)); } } } Console.WriteLine($"There are {known.Sum(d => d.Value.Count)} duplicate armor datums."); var duplicates = new Dictionary<string, List<int>>(); foreach (var (_, entries) in known) { var actuals = entries.Skip(1).ToList(); foreach (var actual in actuals) { if (!duplicates.ContainsKey(actual.Key)) duplicates[actual.Key] = new List<int>(); duplicates[actual.Key].Add(actual.Value); } } Console.WriteLine($"There are {duplicates.Count} files to update."); foreach (var (file, idxes) in duplicates) { var fileContents = File.ReadAllLines(file).ToList(); foreach (var idx in idxes.OrderByDescending(i => i)) { string line; do { line = fileContents[idx]; fileContents.RemoveAt(idx); } while (!String.IsNullOrWhiteSpace(line)); } File.WriteAllLines(file, fileContents); } ``` |
||
|
Zephyr
|
72add64520 |
Refactors armor into dedicated subtypes (#71986)
## About The Pull Request See title. ## Why It's Good For The Game Code is cleaner, and more readable/intuitive Technically closes https://github.com/tgstation/dev-cycles-initiative/issues/8 ## Changelog 🆑 refactor: armor, from the ground up basically /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
Fikou
|
febdb61e01 |
makes status tab use signals, thirds the delay between updates (#72002)
## About The Pull Request status panel for carbons and humans instead of hardcoding stuff, uses signals (borg material storage too) removes combat mode indicator in status tab from xenomorphs which have a button for it, but adds it to simplemobs, since they dont have a visual indicator adds status tab stuff to basic mobs, i think they were missing everything by accident offsets unique status tab stuff for all mobs by a single line the delay between updates is a third of what it was before, mainly to make shuttle timers more accurate (approved by kyler) ## Why It's Good For The Game much cleaner code, makes future implementations easy ## Changelog 🆑 qol: you can see your combat mode status as a simple or basic mob, and you can see your health as a basic mob qol: status panel updates three times as fast /🆑 |
||
Andrew
|
90120455ab |
Void suit and jetpack resprite (#71705)
imageadd: Void suit and jetpack resprited |
||
MrMelbert
|
329921639a |
Rewrites how action buttons icons are generated, makes them layer nicer. Allows observers to see a mob's action buttons. (#71339)
## About The Pull Request
- Rewrites how action button icons are generated.
- Prior, generated an action button icon was fairly simplistic and
didn't allow for many changes. Someone recently added the option for
overlays to be generated over action buttons, but the framework was very
weak.
- Now, action button icon generation is split across multiple procs,
like atom icon updates.
- The background of action buttons are underlays
- The actual icon of the action button is the icon and icon state of the
action button movable
- The rim / border of the button is an overlay, layered overtop the
button.
- Allows observers to see what action buttons a mob has. They even
update in real time! And no, the observers cannot click on them.
## Why It's Good For The Game
- Runechat text of action buttons are no longer hidden behind the actual
icon. This was very ugly with cooldown actions, as the cooldown text was
hidden behind a lot of spell icons.
- Cuts down on a lot of icon duplication.
- Gives much finer control over action button icons
- Saves a bit of processing from generating full action button icons
when not necessary. Not implemented in many places, but is in some.
## Changelog
🆑 Melbert
add: Observers can now see what action buttons an observed mob has. No,
you can't click them. And no it doesn't show EVERY action.
refactor: Refactored how action button icons are generated. Some actions
will now use a colored border when active instead of just turning green.
Cooldown text will also appear on the top layer of actions too. If you
see any funky lookin' icons (namely their borders), let me know.
refactor: Bluespace Golem's teleport action is now a cooldown action.
fix: Construct actions go to the middle of the screen like expected.
/🆑
|
||
AnturK
|
4d6a8bc537 |
515 Compatibility (#71161)
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
|
||
tattle
|
ad5debaaa1 |
Add investigate_deaths (#71112)
## About The Pull Request Adds INVESTIGATE_DEATHS, an investigate category intended to better show causes of death.   Also makes suicide_act take a `mob/living` as an argument instead of a `mob`, and some minor style improvements since apparently I hate atomicity. ## Why It's Good For The Game Inspired by a mysterious death and dusting. More logging and leads for admins investigating deaths. Also fixes #59028 ## Changelog 🆑 Tattle admin: added investigate deaths to shed some more light on unusual demises, dustings, and gibbings /🆑 Co-authored-by: tattle <article.disaster@gmail.com> |
||
Dani Glore
|
0a81ea5bf9 |
Internals Bugfixes & Internals-Compatible Helmets (#70750)
* Core internals refactor. Add open/close_internals procs to /obj/item/tank. Add open/close_internals, can_breathe_internals, and invalid_internals procs to /mob/living/carbon. Fixed bug in human_stripping.dm preventing changing internals for breathing tube users. Fixed bug in /obj/item/tank/toggle_internals that was auto-adjusting non-internals masks. Fixed bug in slements/strippable that caused two mobs to breathe from the same internals. |
||
|
ShizCalev
|
7048110298 | Inhands var hardsetting (#70364) | ||
|
ShizCalev
|
1a32f60cf4 |
[ready] adds unit test for missing inhand icons. fixes a bunch of missing inhand icons (#70037)
fix: Fixed a bunch of missing inhand icons. fix: Fixed cables in electrical toolboxes not randomizing their colors. fix: Fixed the wrong colored icon showing when trying to make cable cuffs out of cables. fix: The collectable SWAT helmet is now using the proper icon again! refactor: Pipecleaners and power cables now share a unified color system, so they're once again available in ALL the same colors. imageadd: Updated the screwdriver belt overlay to represent the newer sprite. imageadd: Added a bunch of new inhand icons. Special thanks to Twaticus for doing the helmets! <3 fix: Wirecutters now have an icon when inside a belt again! admin: Added a new omnitool subtype that allows you to spawn all items in a typepath! fix: Explorer gaskmasks now properly reflect their adjusted state when held. fix: Fixed balaclavas having the wrong icon when pulled up. fix: Fixed the base energy sword (admin spawn only) being invisible. fix: The rainbow energy sword is now a little bit more rainbowy! fix: Fixed an tk exploit with orange handcuffed shoes. fix: The traitor outfit in the select equipment panel is now actually functional! |
||
John Willard
|
243231eb48 |
Properly checks flags with & instead of == (#70130)
* Makes flags properly check themselves Byond ref: https://www.byond.com/docs/ref/#/operator/& Basically, flags should use & instead of == We can have more than 1 slot on any item, so it's preferred that we do this instead. Even if it doesn't immediately fix any problems, it's something that should be the standard anyways to prevent it from ever being a problem. Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
Xander3359
|
63d8a2cb49 |
Captain Jetpack now fits on suit storage slot. (#70107)
* Adds a base modsuit chestplate allow list, cutting down on copy paste * Allows Jetpacks to work while equipped to a de-hardcoded slot_flags list * Allows the Captain's jetpack to fit on space suits and MODsuits by default * Makes the Captain's jetpack fit on the Suit storage slot. |
||
|
tattle
|
d91390a447 |
[IDB IGNORE] The Great Sweep: Moving dmis into subfolders (part 1) (#69416)
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine Moves Halloween, Christmas, and misc holiday items to obj/holiday Moves lollipops to obj/food Moves crates, closets, and storage to obj/storage Moves assemblies to obj/assemblies Renames decals.dmi to signs.dmi ...because they're signs and not decals Moves statues, cutouts, instruments, art supplies, and crayons to obj/art Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys Moves guns, swords, shields to obj/weapons |
||
Seth Scherer
|
f1a363c825 |
Converts a shitload of istypes to their more concise macros (#69260)
* Converts a lot of istypes() to use their istype macro helpers. |
||
Kapu1178
|
2eccf3cea0 |
Cleans up update_icons, makes the update_icon_updates_onmob element bespoke, updates CODEOWNERS (#69179)
* I just realised this is all one commit. * hail marry * fix. * FIXES IT FOR REAL * Update code/datums/elements/update_icon_updates_onmob.dm |
||
|
John Willard
|
952c3ee0d3 |
Removes ComponentInitialize() (#69118)
* Removes ComponentInitialize() Completely removes ComponentInitialize() as a proc, which was called on every single atom in the game, twice in some instances (like new players), over something that can already be done with Initialize(). This is the second attempt at doing this, after the first attempt fell apart for some reason. This time it was way easier though, since storages are no longer a Component. * update icon blocker added before calling parent * Update code/game/machinery/porta_turret/portable_turret.dm Co-authored-by: san7890 <the@san7890.com> * adds a mapload while I'm here * moves human mood * Does some UNRELATED thing to the PR Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
Mooshimi
|
a3121f15c4 |
[GBP No Update] Perish, individual logging runtime (#69024)
missed 2 or 3(lol it was more when I look back at the files), LOG_GAME tags on the log_message line, and did some cleaning up since i was looking through every log_message again Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> |
||
|
Mooshimi
|
b09f3868f8 |
individual LOG_GAME (#68683)
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
|
||
13spacemen
|
8e4327b290 | Removes Internals HUD element (#68523) | ||
|
MrMelbert
|
f8f3dbed98 |
Completely removes proc_holders from existence. Refactors all wizard, xeno, spider, and genetics powers to be actions. Also refactors and sorts ton of accompanying code. (#67083)
* destroy proc holder pt1 - change proc_holder/spell to action/cooldown/spell - docs all the spell vars, renames some of them - removes some useless vars - start with pointed spells, as they're easy * kill proc_holder pt2 - kill a buncha vars and replace it with flags - convert a ton over - general code improvements * kill proc_holders pt3 - convert a good few more spells - rename some signals - handle statpanel - better docs * kiill proc_holder pt4: - restructure the file system of action.dm, separating a good amount of item actions and miscellaneous garbage into files where they belong slightly better. Also splits off item actions, cooldown actions, innate actions, etc. into their own files, overlal making it much better to work with - converts touch attacks to actions - converts blood crawl, jaunt subtype * kills proc_holder pt5 - clears up some icon issues so all the currently converted pages don't have errors - shapeshift - some more action cleanup * kills proc_holder pt5.5: - some documentation - reworks feedback to prevent oversight with teleports and stuff * kills proc_holder pt6: - converted cult spells - converted magic missile - converted mime spells - chipped away at the errors - removed some vars which were too general, replaced them with more locally applicable vars. for example "range" which could mean "projectile range" or "aoe radius" or whatever - instead of having a broad net which everyone applies to in a confusing matter, instead lets each spell delegate on their own. - merged magic/spell and magic/aoe, as the comment intended - more unified behavior for spell levelling * kill proc_holders pt 6.5: - replacing a buncha old proc_holders that have been updated to reduce some errors. sub 900 baby * kills proc_holder pt 6.75: - minor fixes * kills proc_holder pt7: - cuts down on some errors - refactors some wiz events * kills proc_holder pt 7.5: - malf ranged modules - some minor errors * kills proc_holder pt 7.75: - mor eminor error handling, cleaning up changes * kill proc_holder pt8: - refactors spell book - refactors spell implant - some more minor error fixing * kill proc_holder pt 8.5: - scan ability * Adds some robust documentation * kill proc_holder pt9: - converts some / most mutations over * kill proc_holder pt10: - sort out all the granters - refactor them slightly - fix some compile errors * Some set-unset sanity - going to need to test removing Share() * Removes transfer actions. It doesn't seem to do anything. - Transfer_actions was called when current = new_character so locially speaking the early return in Grant() should cause it to NOOP. Test this in the future though * Removes sharing from actions, docs actions better * Some better documentation for spell and spell components * Kills proc_holder pt11: - Finally finishes ALL THE SPELLS IN THE SPELL FOLDER - Fixes some more errors * kills proc_holder pt11.5: - minor error fixing and sanity * Method of sharing actions. Can be improved in the future, needs testing * Implements a way to update the stat panel entry for a spell. Also gets rid of VV stuff, as you can update the bigflags directly in VV now. * Curse of madness bug I put in. * kills proc_holder pt12: - sub 500 errors! - converts cytology mobs - converts and refactors spiders slightly - some minor fixing around the place as usual * kill proc_holder pt13 - Finishes heretic spells - Sub 300 errors! - some touch refactoring to account for mansus grasp * kills proc_holder pt14: - revenant - minor bugfixing for heretic stuff * kills proc_holder pt14.5: - some missed stuff for revenant + heretic * kills proc_holder pt15: - alien abilities - more minor fixing - sub 100 errors. The end is nigh * kill proc_holder pt16? 17: - Finishes cult spells - sub 50 errors! - refactors the way charge works - renames / moves some signals * kills proc_holder pt final: - sdql spells - no more errors! * Bugfixes round 1 * Various bugfixing - documentation done - give spell works - can cast spell gives feedback conditionally - is available takes into account casting ability * Some accidental reversions + fixes * Unit tests * Completely refactors jaunting - All bloodcrawling is now handled on the action itself instead of across various living procs - slaughter demons have their own blood crawls - jaunting dummies don't have side effects on destroy() anymore * Wizard spell logging and even more refactoring |
||
TemporalOroboros
|
2683ec04b0 |
Improves logging for smoke clouds. (#67206)
About The Pull Request Makes smoke propagate the fingerprints of the last person to touch the source of the smoke. This makes gunpowder smoke actually log the person responsible for the explosions. Why It's Good For The Game As of right now gunpowder smoke (and similar) doesn't actually have very good logging as as far as the smoke is concerned it's never been touched and so the resulting explosions are blameless. Obviously, scrolling up for a good minute looking for who has just obliterated the escape shuttle is slightly annoying for the admins. Ergo, making the explosions log who actually is responsible for making the smoke they originate from should reduce admin annoyance. Changelog cl admin: Smoke now logs the last person to touch the source of the smoke as the last person to touch the smoke itself. Gunpowder smoke should be less annoying to log dive as a result as every explosion will log that person. /cl |
||
itseasytosee
|
878e3b8d37 |
Implements a Demolition Modifier variable to items, affects damage vs structures and robots. (#66967)
Adds a modifier variable which can be used to increase or decrease a given items damage to structures, machinery, vehicles, and robots (including cyborgs, simple-bots, and anything else with the MOB_ROBOTIC biotype) |
||
|
LemonInTheDark
|
7e9ff85f2a |
[NO GBP] Jetpack and spacedrift: Fixes and niceties (#66628)
* Jetpack and spacedrift: Fixes and niceties Ok so when I ported spacemovement onto movement loop, I neglected to port this behavior that existed to support jetpacks. Basically, if something that lets you move while spacedrifing completes a move while you're spacedrifting, the drift should "disable" to let it complete, and then later restart. I neglected to add support for that, so that's what this does. There's some other stuff going on here, mostly things to let jetpacks ignore some of drift's extra behavior, since when a jetpack is not on stablized, we want both to coexist. It's a bit of a mess, I'm sorry about that. Oh and at temporal's suggestion I've moved the visual_delay set from newtonian move to an istype on the drift component, that was a good idea, thanks quiet * Makes dropping a pull while drifting carry the momentum into the pulled thing\ * Adds some extra context to Process_Spacemove, fixes a bunch of stupid space bugs It used to be, if you called Process_Spacemove with a direction, it assumed you were an "action", so a client or mob trying to move in a direction. Unfortuantely for it, I needed to be able to use direction to make mob pull drifting work. So we now actually pass in a second variable called continuous_move, which tracks if this Process_Spacemove is on behalf of a continuous move or not In addition to this, I've added logic to bumping "off" someone to prevent backbumping if that makes sense, since the bump is in the form of a newtonian move that's run before the thing that's bumping actually moves, we need some way to exclude it from holding the other object in place. * Adds a jetpack component, uses it to unify all three versions of jetpacking I hate you fikou There were three copies of the same behavior, which made it hard to fix stuff. Let's just componentize it * Fixes jetpacks stabalizing even without fuel This is mildly hacky. The real fix is to do this with events, but I really don't wanna bend my brain like that. This'll do * Ensures turn_off always has a user) * Shut pu * Bulky drags no longer effect your movespeed in space, fixing a consistency issue between them and all other forms of drags * Removes some redundant code, cleans up some messy stuff * Removes redundant safety checking from jetpack code * see above * Removes redundant signals |
||
|
TemporalOroboros
|
068a3be859 |
Makes smoke and foam attempt to fill the available space. (#65281)
Have you ever noticed that the chemical smoke and chemical foam reactions are a lot less effective in confined spaces? This is because they currently attempt to spread to all tiles within n steps of their origin. If they can't expand onto a tile they get blocked and the expanding cloud/flood misses out on all the tiles that would be in range, but that can't be reached. Obviously smoke and foam getting blocked by walls and the like makes intuitive sense, but it seemed a bit nonsensical that walls would basically delete a significant chunk of an expanding, amoebic mass. The solution I came up with is making smoke and foam expand until they cover a certain area, with a shared tracker for the target size and total size of the flood. The flood will simply expand as normal until it covers the desired target area. Blocked expansions just don't count and will be made up for with expansion elsewhere. Attendant to these changes are a whole bunch of minor code improvement to smoke, foam, and one for wizard spells because I was already in the area and :pain:. There have been some minor balance changes to the chemical smoke and foam reactions: I converted them over to passing the desired area of the resulting smoke cloud/foam flood. The old equation for the resulting area was along the lines of 2sqrt(x)(sqrt(x) + 1) + 1 given reaction volume x and given unobstructed expansion. I've made them just pass around 2x instead. This is actually less than they used to try for, but now they're guaranteed to reach that unless the flood is fully contained. Not entirely certain if buff or nerf. Probably buff on the station. Also, foam dilution is now based on covered area instead of target expansion range. Since this scales faster than it used to foam has been effectively nerfed at high volumes. To compensate for this I removed the jank 6/7 effect multiplier and increased the base reagent scaling a bit. Again, not certain if buff or nerf. |
||
|
ArcaneMusic
|
5f4d5a42d4 |
Arconomy: The bigger balance PR (REVISED EDITION) (#65795)
This PR covers 4 Key features:
Price Rebalancing
Passive Income
Gas Exports
Lathe Tax
Relevant Design Doc (Slightly out of date as a result of the discourse on the subject).
https://hackmd.io/WlWgyRafTaiAqz6ouOqC-Q
-- START DOCUMENT --
# Arconomy Version Two
This is mostly me organizing a long list of thoughts that I'm not sure if I can properly describe and get across, but lets just work with what we got and go from there.
## There should probably be a relationship to time and profit
So, part one of a series called "Arcane was completely wrong about game design", I made a rather large misstep in regards to designing arconomy, and nobody told me this until far, FAR after I had gone way too in on my own ideas:
"There needs to be a relationship between time and money". Because Space Station 13 is a game that is built around rounds, either long, LONG rounds on MRP or 30 min - 1 hour long rounds in LRP, your whole orientation of the game is built around time. The longer you spend in a single round, the more you can do and mold the station and the game in a specific direction, whether it's from an admin event, doing your job, or going off on a wierd character based tangent.
The issue here lies in a question I tried to answer in my previous design doc:
> "Command players start with lots of money, and make mountains of money, and as a result, have so much money by the end of the shift that they're practically immune to the effects of the economy.
> Assistant players start out with practically no money, find that the station is covered in costs that they'll never be able to practically afford, and decide that the economy is stupid and not worth utilizing altogether."
Two fundimentally different outlooks on the same problem, caused by the pay discrepency as it existed originally. Since we have so many different jobs all at different paygrades, the option that made the most sense at the time was to completely remove paychecks alltogether because they would multiplicitively exacerbate the previous issue.
While it would flood the in-game economy over time at high levels, it did add a sense of timescale to the existing in-game relationships. You **KNEW** that after x many minutes you would get that fancy hat, or that you would need to find cash in other ways to get it. Having that time-scale is helpful as we've moved to our 90 minute round average/goal. It also, similarly, means that we know exactly how many credits each job SHOULD have had access to before a major disaster calls for a shuttle call. But, in hindsight, that is a value that should be consistant for all players. If a single, unaided player looks at a 200 credit bill, that should have the same impact player to player, and not limit their access to jobs.
## Bounties just ain't that fun, but they stand to see improvement from where they are now
So, guilty as charged, bounty running doesn't quite have the same charm as it used to have. For our friends just joining us, cargo used to have a single, per round laundry list of items that would payout to the cargo budget each shift. Each list would start with 10 items, one of which would randomly be assigned higher priority with a higher payout, and it would be cargo's job to ~~Break into each department and steal that thing~~ cooperate with jobs around the station to aquire funds for station crisis or when you just want to dick around and make stacks of cash. This had a distinct charm to it, but one element of it that majorly reduced the replayability of bounties was that they were severely limited in scope. Once you did your ONE drink bounty or your ONE chemical bounty, you no longer needed to interact with that department.
My original goal was this: Make an unlimited bounty system, where crewmates were able to get a cut of their work as profit. To a degree, it's fairly successful! Crew do have a way to actively work with cargo to get paid for their labor, and they help cargo as a result by giving them free valuables. The issue lies in the fact that this has kinda flipped the relationship on it's head: Bounties stopped being cargo's job to outsource to the crew, and instead the crew's job that becomes dependent on cargo.
In general, many bounties simply weren't meant to be repeatable content in the first place. And certainly not meant to be used for every job. Offloading it as a kind of fetchquest minigame so that all jobs can offset the loss of passive income? It's not the best choice. For jobs like botanists or scientists it's tolerable at best, frustrating at worst. Just look at the state of things like experisci-slime experiments or scanning furniture.
It gets far worse when it's from the perspective of jobs that have *explicitly* limited supplies like security. No, a security player is not going to be allowed to haul away all the good metal handcuffs from the brig for a bounty, and no, you cannot take all the riot shotguns from the brig.
Now, a few of these things were fixed over time, with mixed successes. Bounties started to be cleaned up in order to prevent limited quantity items from being an option for repeat bounties. Jobs that lack exports started to get some content for still allowing them to have repeatable exports (Like the Scanners for Security Officers to go on patrols).
The BIG EXCEPTION to this is Restaurant Bots, but we'll hit that in a second.
## Getting everything on the same price scale has been a major improvement.
Unironically one of the best changes made has been the idea that even if we lack that good time-credit scale from before, we didn't really have a "standard" to work off of when something new is added to the game and the dev needs to determine how much to make that thing cost. That's why the current costs of objects and values on-station are scaled off of a single define, the value of a crate sold on the cargo shuttle.
> Yes, I'd like an APPLE. It's worth 3124151 CREDITS. NO, I don't know why the apple juice in the vendor is worth 415 CREDITS, nor do I CARE, GOOD MAN.
From the back end, everything is scaled off the same define now. Paygrades are defined off of a different scale still, but that's fine. You know, from the cargo end of things, that a cargo player needs to ship off X number of empty metal crates to purchase a laser crate, or a pizza crate. Definate relationships help in solidifying the singular value of a product.
If we decide that we want to rescale the in-game economy and provide space credits with more granularity, at least we know we can do it with a single line of code, and not looking at every single instance of something that charges the player money.
### Arconomy Tangent: We gotta nuke gas selling.
This has been a long time coming and I know people are going to be upset at me, but look man.
I have no idea how selling moles of gas works these days. It seems like with minimal resources, true atmos wizards are able to make singular cans of gasses with infinite moles of some kind of gas, and if it's exotic enough, they can make upwards of a million credits a can. I've seen multiple occasions where selling gas cans to cargo has allowed for players to buy a bike.
For our Gen-Z zoomers reading this, players were never meant to BUY the bike. The bike is just a reskinned scooter meant as a cute little pokemon joke. If a player can actually buy a bike in a round, that's a sign that someone, somewhere, fucked up.
We fucked up the whole system with atmos gas selling.
We've now gone through metas of extracting miasma from lavaland for credits, we've gone through a meta where cargo starts building their own hydrogen burn chambers for simply produced gasses, we've seen time and time again that processed gasses in the funny space simulator just tends to be abused to death and back. I've had talks with TheFinalPotato on this in the past, and it just feels like a system that would need to be rewritten from the ground up, or looked at in terms of the whole cargo department. If I don't get to it first, the next cargo design doc someone writes **SHOULD**.
## Giving jobs content that integrates into the economy can be really fun.
Tourism bots and the baked in ingredient shopping is fun! It's enabled for a fluff job that doesn't have too terribly much by way of serious responsibilites to integrate active income minigames into the gameplay of chefs and bartenders. It's fully optional, it's quick, and it's not even a full shift investment.
These secondary tasks, which utilize jobs core gameplay loops in a new way, while rewarding them within the in-game economy are a decent way to keep players engaged with their jobs, and allow for them to use credits as a player resource as well as a primary job resource.
**I AM NOT SAYING** that all jobs need to find tasks to arbitrarily reward players with credits for. The reason it works so well for jobs like the chef or bartender is because their job is already to make food and drinks, but they have so many options that they're not encouraged to make too wide of a variety of food, especially when botanists won't always make everything you need. The food market gives them an outlet to buy outlier ingredients and the tourists pay handsomely enough that you can offset your costs most or the time.
I'll break this down as well into the three different methods of money-making in game as well, to guide someone on how to make good, secondary income content.
| Primary | Secondary | Tertiary |
| -------- | -------- | -------- |
| This is something like passive paycheck income. You get this just purely for playing the game, and staying alive. | This is an active trade off between your job's specific content, where you are trading your time for something it is directly your responsibility to do. Eg. Tourist Bots. | An active task you are performing for income, but lacks the specialization of a job. EG. Bounties. |
Jobs that excell at more service based tasks and less production based tasks should aim to aquire more seconary style economy integration, like medical, science, or security.
## The options for moving money around the station are actually pretty decent, but could be streamlined
Bounty boards are pretty decent at being a way to pay crew members for single service jobs. However, bounty boards are pretty much dead content, in a sense. There's not much incentive to hunt down your department's bounty board.
Similarly, most crew would just prefer to hand credits out by hand to prevent most kinds of abuse of their own credit supply.
Long term and certainly a major personal outcome I'd like to see: Bounty boards and Newscasters should be merged together. Newscasters have some truely awful spaghetti and their being held together by shoe-strings and duct tape (This is slang for HTML). Bounty boards are... well they're functional, but they have the benefit of being built in TGUI. Merging the two's functions should cut down on wall-space, as well as improve the quality of a vast deal of code, and make money transfer on station slightly easier.
Honestly, pretty happy with vend-a-trays. They're pretty decent store-machines on station and do their job pretty well when they get used. All in all I'm happy with how they work.
Custom Vendors are clunky to a fairly major degree and I don't think most players get how to make them work on account of need a price tagger (not a sales tagger, that's the cargo item) to mark an object for it's sale value, then load it into a custom vendor sales unit, then load it into a custom vending machine, and that's only IF custom vending machines decide to work this year. Streamlining the tools, or perhaps just vending machines would certainly improve this as a service.
## Just ain't enough cool stuff to buy with credits.
An ever-present problem, that we're just kinda stuck with. There's a decent number of issues involved with making content that can safely be gated with just credits.
* If it's usable as a weapon, is it too dangerous to hand out to the crew at large?
* Does security get potential oversight?
* If it's illegal, does it go through cargo?
* Does it HAVE to go through cargo?
* If it's beneficial, is it going to invalidate the existance of a job? (Think old medkits!)
* Is there anything that players WANT that's not a weapon, benefical to the station but not too strong, or quite literally traitor equipment?
It's a tough question.
Some items make complete sense to implement on a per job basis as either uncommon or premium equipment, while other items could potentially be moved to station-wide unique purchasables.
# Takeaways:
Look, these are just some possible solutions that I'm considering. I think that working alongside a maintainer who could actually give a damn on getting this system orderly and possibly alligned with our current design philosophy (Who also understands that a not-insignificant amount of current economy was abitrarly written by goofball an actual decade ago) could help iron this out into a clear and consise set of goals and milestones to make the in-game economy workable. Not balanced, but workable.
* **Design a simple simulation for per round intake and outtake, to determine benchmark values for a 90 minute round.**
It would need to look something like this, as a kind of fucked up, Multi-Input Multi-Output Control Problem. Possibly could be done in simulink, but I'm not quite sure how to do that at this moment, so a less complex version might be fine.
* **Look back at implementing crewmember incomes, but at a flat, more consistant rate over all jobs**
My leading idea: 50 credit, uniform paygrade. No wild, unscaled pay rates based on what job is "important" or not.
That line of thinking means that certain jobs should have more expensive equipment over other jobs, but then we're right back to the captain thinking that a cup of coffee is practically free where an assistant thinks that a screwdriver from the vendor is going to put them out of house and home.
Improves time-relationship values with credits.
This could lead way to heads of staff having some degree of control to giving raises or paycuts to crew-members, but perhaps at a very, VERY gradual rate.
* **Perform another big-picture look at bounty cubes.**
Potentially try to put bounties back in the hands of cargo, while still providing payouts to crewmates who assist in completing jobs. This may require some minor refactoring of the pricetag component, perhaps to even allow for multiple crewmembers to recieve profit from a payout.
This means once again, look at making bounties workable for all jobs on the station, not making the objects requested literal lathe-fodder, and finding ways to benefit the station in some way with the task of bounty cubes, even if it's just for credits.
Deceptively hard task.
* **Add secondary tasks that integrate the economy into non-bounty-able jobs/departments**
Like it says on the tin, look into ways to add content that improves economy integration into existing jobs, without necessarily changing what those jobs DO. The bounties for those jobs can still exist as a tertiary thing, but should be made clear that they're... tertiary.
Chefs still make food and bartenders still serve drinks, but they have a way to hand them out for fun and profit.
Some thoughts and ways to handle this potentially:
*Science:* Perform intricate testing on anomalous materials using science equipment. Should NOT REWARD RESEARCH POINTS. Mr. OJ Headcoder will CHEMICALLY CASTRATE me, or you, if you do.
*Medical:* Complete tricky or non-standard surgeries on dummies for medical data. Think like that meme from the TV show, House.
"He needs Mouse bites to live. MORE MOUSE BITES."
*Engineering:* Repair wacky machines that use both station-standard parts as well as solving quick puzzles.
* **Look into more effective money sinks that are dynamic sensitive**
Think, for example, about the station ransom event that spawns space pirates.
What if instead of the captain just dumping credits from the cargo budget into the aether to prevent pirate spawns (They're bugged anyway to my knowledge to spawn anyway), crewmates had to cough up that dough before a time-limit, or risk a pirate spawn. For those of you who were scratching their heads at (Operational Costs!?) in the above controls diagram, this is the sort of thing I mean.
Little, smaller things that might need to be purchased, invested in, or otherwise drain credits from the station over the course of the round.
# Arconomy 2.0: Smarter, Better, Flashier.
## Roundstart
Players begin each shift with a set amount of money, with the value being mostly uniform over the course of a shift assuming no interaction with economy. Jobs are split up into only 3 paygrades, Minimal, Crew, and Command. Minimal is reserved for jobs that are meant to fill population counts but lack a specialization, like prisoner and assistant. When starting the shift, a player will start with 5 paychecks worth of savings. This system is not designed for persistance, so you will always be able to tell how much money a player starts out with. Every 5 minutes, aka every economy tick, the player will recieve one paycheck, which is capped out at the standard crew member paycheck. This means that even if you start the shift as the captain, and begin the shift with 500 credits, you will recieve the same 50 credits as regular crew members.
| Minimal Paycheck | Crew Paycheck | Command Paycheck | Frequency |
| -------- | -------- | -------- |--------|
| 125 Cr | 250 Cr | 500 Cr | Roundstart |
| 25 Cr | 50 Cr | 50 Cr | Passive Income |
## Product Prices
Products found in vending machines are defined by the amount of a player's paycheck they're meant to cost. Regular items use the PAYCHECK_CREW value, while more expensive or otherwise prohibitive items are defined by PAYCHECK_COMMAND. Items are defined in this uniform, horizontal fashion in order to maintain the equal value of credits over all jobs. A 100 credit medkit in medical should have the same value to a doctor as it does to a botanist.
Jobs apply a discount to vending within their own department, so an engineering would have a discount on tools, and a doctor would have a discount on sutures. Items that are important to gameplay progression in a role are less expensive to their intended users.
> **AUTHORS NOTE:** I am considering removing in-department discounts. In the benefit of making the value of purchasables more universal, deciding that credits shouldn't be spent within their own department just seems... rather fucking stupid.
> Possibly move the discount to only the first few minutes of the shift, or perhaps as some kind of gameplay benefit to slowly increase in-department discount through gameplay milestones? Who knows 👻
>
Some jobs have premium, high value items stocked in their vending machines that are not meant to be purchased at roundstart. These are meant to encourage players to save or combine resources to gain access. An example of this is insulated gloves. Other high value items can also be found in contraband through hacking vending machines. This remains unchanged.
## Markets
The cargo department has been changed in order to improve player involvement with the economy, as well as to give cargo more variety in their merchandise while preventing a singular stale meta of products to purchase from.
Yes, I'm looking at you, russian surplus crate.
Lets start with what's remaining the same:
* Cargo is a department that manages imports and exports of products, fulfilling departmental orders, and aquiring supplies dependent on the station's state.
* Cargo encompasses the station's mail, mining, and flow of orders, as well as drone exploration.
* A skilled cargo member is able to find high value items to sell back to centcom in exchange for more funds, to purchase those supplies.
* Centcom may request bounties which crew can fulfill in exchange for credits, if they wish for additional work.
**Now for the new design flow:**
Cargo starts out with a new mechanic called a market. Markets hold existing export datums as well as purchasable products. The values of items will fluxuate up and down based on the market status, with in-game events or player actions raising or lowering the values of specific markets.
At roundstart, cargo has a single market to sell to, which is Nanotransen. This will not incapsulate all the existing export datums in the game, just the *primary* exports that are used by players. Items that are exclusive to nanotrasen and required to play certain game modes, like mindshield implants or being able to sell crates, are included and will always be available to purchase.
Additional markets can be unlocked through gameplay sources, such as:
| Market Name | Source | Imports/Exports |
| -------- | -------- |- |
| The Syndicate | Emagging/Hacking the Console | Illegal Goods/Contraband |
| The Clown Planet Commerse | Discovering the clown planet ruin | Pies, Horns, Pranking Equipment |
|Terragov Sector Security Surplus | Killing any megafauna. | Weapons, Ammunition, Advanced Riot Gear. |
| Mekki Materials Co. | Recovered loot from Exodrones | Materials and industrial equipment. |
|Donk Co.| As a tip from tourist robots. | Foods and Drinks, Toys and Games.|
|Waffle Co.| As above. | Bootleg products and wacky merchandise. |
|The Research Consortium| Reward for completing any experiment tree. | Slime Cores, RnD Artifacts, Robotics Equipment |
...And more, if I can think of more.
The purpose being, of course, to split up cargo's purchasable goods to be more instanced and unique, while also create unique situations where due to profitable markets, very specific exports are needed to help the department make money.
End of document for now :@ArcaneMusic
-- END DOCUMENT
Price Shifting
So, in-game items that have prices have a major issue on their hands, being that they were decided by how much money that job should make. This means that many of the jobs in-game have been given prices scaled to their job's income. That income I adjusted by removing passive income in #54161. While this was helpful to moving towards an active in-game economy, it resulted in items falling into distinct price brackets. A high paying job like security's items could never be purchased by someone like a botanist, but a job like a security officer had more capital and buying power than most other jobs in-game combined when moving down those brackets. We've done a simple normalization of scale to help in bring things closer to a semblance of equality.
There are now 3 price brackets, PAYCHECK_LOW, PAYCHECK_CREW, and PAYCHECK_COMMAND. Command staff will still have a higher base level of money on-hand than other crew, and low paying wages that we on-station don't respect as being real jobs (assistant, prisoner) will have their items be intentionally cheaper to encourage active participation in the economy, but the difference in scale is now noticeably far closer to each other. This means that assistants can still interact with the economy as spenders, but if they want to be doing a lot of work with money, they'll need to put in work. Additionally, this means we arbitrarily enforce a system that allows for items to have uniformity in what they cost to other players. 50 credits for a wrench feels better when you know that other job critical items in-game are also around the same price, and it's equivalent to one paycheck.
Paychecks are reintroduced
Economy lost it's relationship to time. In a game where a single round takes 90+ minutes (Backed up not only by the head-coder's design direction as well as plenty of aggregate round data), having a relationship to time and how long it takes to afford something is a major consideration when you look at buying something. Also, we get to say that I was certifiably wrong in regards to the active economy thing, since we have very, VERY few active sources of content in-game that are very... fun? Bounties are literal fetch quests but something like tourists is at least more engaging and interactive with the round, and should be the direction we want economy-job integration to head in.
Between having inflation as a price manipulation mechanic already in the code, as well as prices being roughly equalized in terms of their costs between jobs and their impact on the round, this allows for the reintroduction of paychecks to an extent.
As an additional note, doing this meant tweaking down the syndicate briefcase of cash, so that instead of giving you 5000 credits for 1 TC, it now costs 5 TC to accompany the fact that this is now a rather significant amount of money, even on decently high population. Fun fact: the Syndicate Briefcase of Cash actually PREDATES the economy, and was NEVER ADJUSTED beyond the original implementation of the economy as a result!
Gas Exports.
ALRIGHT ARE YOU READY FOR SOME GRAPHS? I THOUGHT SO, YOU LOVE GRAPHS.
So, gas exports are fucked, have always been fucked, and consistently have proven to be capable of breaking the in-game economy for a long time. This is no secret, I've been pinged with players getting billions, actual billions of credits using it multiple times in as many years. See, any round where a player manages to buy the bicycle is a round where I've fucked up, or someone fucked and I let it get past me.
So here's how gas exports work right now.
So, all of this hinges on the value of a single mole of gas, and some gasses enable you to make extremely, EXTREMELY profitable gasses through atmospheric gas wizardry However, even those less profitable gasses are still in an extremely high magnitude of value.
Most gasses if you have a full can of it will net you OVER 10k credits. For scale, one crate being sold in cargo is 200 credits.
That's a minimum of crates for pumping gas into a hollow metal box and praying it doesn't explode.
So we adjusted the values accordingly.
The baseline value of a single gas has been tweaked downward significantly. Even these values are still arguably very high, but I can play with it at the discretion of LemonintheDark. The green line at the top represents gasses that previously sold for 100 credits per mole, antinobilium I believe, and working downwards. I am going to try and enforce 10 credits per mole as the absolute maximum hard cap on gas exports, regardless of how many gasses we try to add in the future. Because the alternative is getting a gunjillion credits by huffing miasma into a tank of steel. And we ain't having that shit.
Lathe Tax
Part of the testing for this PR involved me modeling the SS13 economy in a given round as a kind of controls problem, with each source of income introduced in the round as a kind of input (Passive Income, Bounties, Tourists) in order to get a handle on roughly how much income a single round of SS13 will see per player on the given designed round-length, in order to estimate how much things are going to cost. Modeling how much players spend on a given round is variable enough that it'd be too difficult to accurately test without just throwing this up on a server and getting live data.
However, from the appearance of my dataset, players would be making a LOT more money nowadays with all of the above changes implemented. In an attempt to curve that intake, I attempted to implement a small, low scale tax of printing items that would take a small amount of players income every time they print, as a way to add a basic economic side-effect to this mechanic.
This has made a lot of people very angry and been widely regarded as a mixed decision. So, maintainers came up with an intended direction they want to see it, as they wanted to make sure that economy would remain a secondary system, that could still have an impact on round direction and the changes they want to see in the game.
So, here's the intent:
Lathe tax should exist in the form of printing things from protolathes outside of your department, not on autolathes or your own protolathe.
We want to promote people talking and collaborating to access things if it's outside the scope of their department and they still want it, with theft still being a viable avenue of gameplay.
Players will be charged 10 credits for printing a set of items not from their own protolathe, each. Printing an item can be paid for from your own ID card's bank account automatically, but the payment component has been buffed to handle physical money alternatives, as well as pulled money, similar to the luxury shuttle scanner gate's behavior.
Borgs are still enabled to print from lathes, however instead of it costing them credits, they now take a self-significant power cost in order to do so, preventing them from being used as a roving bank account for printing. I'll look into this further as we don't want to invalidate mechanics like borgs being able to do organ based surgery or building machinery, but we don't want them to become credit cards, so place that under advisement.
Tweaks and Updates:
(Suggested by Ziiro) If the revolutionaries win, centcom will no longer enforce the Lathe Tax.
(Suggested by about ~1000 people independently between my DMs, Reddit threads, the Feedback Thread, and elsewhere)
Printing items only taxes you once per print. EG: If you print 10 Kitchen Knifes as an assistant from the service lathe, you will only be charged once instead of 10 times.
For many of the reasons that I outlined above, this is a good change in a positive direction.
Players get more ability to interact with the economy without having to do content that's becoming increasingly depreciated in my absence.
Players also have a baseline consensus on what values of credits are high and low because jobs have been given an equalized standard in regards to the cost of certain items.
Price fluctuations through inflation will now be more meaningful in situations where the economy becomes more relevant.
The system will still encourage you to play a job that's productive to the status of the station through lower paycheck jobs existing as well.
Gas exports are now reduced to the point that their value is appropriate for the first time... actually ever. Nice.
The values of nearly every item purchasable by players has been rebalanced.
Players will now start with less starting money, but will receive a paycheck once every 5 minutes.
The value of gasses exported through the cargo department have been skewed way, WAY down in terms of price.
The Syndicate briefcase of cash now contains now costs 5 TC, up from 1 TC, for 5000 credits.
Printing items from lathes on station now costs a fee of 10 credits per item printed if it's from a lathe not under your department.
The payment component has received additional handling for physical credits, as well as pulled credits/ID cards for those without hands.
|
||
vincentiusvin
|
eeb5465931 |
Ordnance Content Update: Scientific Papers (#62284)
How do I play/test/operate this? Download NT Frontier on any modular computers. It should debrief you on what experiments are available and how to publish. If you want to do a bomb experiment, make sure it's captured by the doppler array (as usual) and then print the experiments into a disk and publish it. If you want to do a gas experiment, make the gas and either pump it into a tank and 1) overpressurize it with a "clear" gas like N2 or 2) overpressurize tanks with the gas itself. Make sure you do the overpressurizing in the compressor machine. When tanks are destroyed/ejected leaked gas will get recorded. Print it into a disk and publish it. For publication, the file needs to be directly present inside the computer's HDD. This means you need to copy it first with the file manager. Fill the data (if desired, it will autofill with boiler plate if you dont) and send away! Doing experiments unlock nodes, while doing them well unlocks boosts (which are discounts but slightly more restrictive) which are purchaseable with NT Frontier. If you are testing this and have access to admin tools, there are various premade bombs under obj/effect/spawner/newbomb A doc I wrote detailing the why and what part of this PR. https://hackmd.io/JOakSYVMSh2zU2YL5ju_-Q --- # Intro ## The Problem(s) Ordnance, (previously toxins) seems to lack a lot of content and things to do. The gameplay loop consists of making a bomb and then sending it off for credits or using it to refine cores. Ordnance at it's inception originally relies on players experimenting and finding the perfect mix over multiple rounds, but once the recipe for a "do-everything" mix got out, the original charm of individual discoveries becomes meaningless. Another issue with ordnance is the odd difficulty curve. As a new player, ordnance is almost impossible to decipher, but once you watch a tutorial or read a wiki and can mail a 50k into space, there pretty much isn't anything else to do. Most players will be satisfied at this point without the gameplay loop encouraging them to understand or play more. The only thing you can do afterwards is to sink your teeth in and understand why that particular mix explodes the way it does. This again has a significant difficulty curve, but if you do that, the department doesn't acknowledge or reward that in any way. There are pretty much two huge spikes, with the latter one not really existing inside the department. TLDR: * The content being same-y over rounds. * Odd difficulty curve: 1. A new player is oblivious to everything. 2. Those in the middle can repeat the final goal consistently without needing to understanding why 3. There is nothing to justify spending more time in the department after reaching the midgame. ## Abstract Scientific Papers aim to add a framework to run multiple experiments in ordnance. Adding more experiments scattered across various atmospheric aspects might allow players of various knowledge levels to still have something engaging to do. A new player should have an easier challange than to mail a 50K. While those that already can make bombs should have an easier time understanding why their bombs explode the way it does. Once they fully understand why, they can set their sights on taking advantage of another reaction to set their bomb off or hone one particular reaction down. ## Goals * Have some intro-level challanges for new players. * Have some semblance of late-game challanges for more experienced players. * Explain the mechanics better for those in the middle of the road. * Incentivize trying new things out in the department. * Better integrate Ordnance with Experisci ## Boundaries / Dont's * Do not incentivize people to learn ordnance by using PvP loots. * Do not shake or change the reaction system by a huge amount. * Disincentivize having a single god-mix that does everything. **** # Main design pillars ## A. Framework surrounding the experiments ### A.1. New experiments Add new experiments to the ExperiSci module. These will come in two flavours: New explosions to do, and various gas synthesis experiments. Both of these are actually supported by the map layout of ordnance right now, but there is no reason to do anything outside of making a 50k as fast as possible. ### A.2. Rewards for experiments: Cash and Techweb Boosts. Scientific papers will add a separate experiment handling system. A single experiment will be graded into various tiers, each tier corresponding to the explosion size or amount of gas made. Doing any tier of a specific experiment will unlock the discount for that specific reactions. A single explosion **WILL NOT** do multiple experiments (or even tiers) at once. On publication, a partner can be selected. A single partner only has a specific criteria of experiments they want. The experiments will then be graded on "how good they are done", with the criteria being more punishing as tier increases. Publication will then reward scientific cooperation with the partnered partner. Players can spend this cooperation on techweb boosts. Techweb boosts are meant to be subservient to discount from experiments and will not shave a node's price to be lower than 500 points. **Experiments will only unlock nodes, discounts are handled through this boost system.** This is more for maintainability than anything. ### A.3. On Tedium *This is a note on implementation more than anything, but I think this helps explains why several things are done.* Due to the nature of atmospheric reactions in the game (they're all linear), tedium is a very important thing to consider. An experiment should have a sweet spot to aim for, but there should not be a point where further mastery is stopped dead on it's track with a reward cap. Scientific Papers attempts to discourage this behaviour by having the "maximum score" scale off to infinity but with the rewards being smaller and smaller. The sweet spot is always there to aim for and should be well communicated with players, but on their last submission of an experiment topic players should be encouraged to do their best. There should always be a reward for pushing the system to it's limit as long as it doesn't completely nullify the other subdepartments. This is the reason why there is a hard limit on the number of publications and why the score calculation is a bit more complex than it needed to be. ## B. Gas Synthesis (Early-Mid Game) Scientific papers will add one new machine that requests a tank to release x amounts of y gas. This will be accomplished by adding a tank pumping machine which will either burst or explode a tank, releasing the gas inside. The gas currently requested are BZ, Nitryl, Halon and Nob. The overarching goal of this compressor machine is to present a gas synthesis challange for the players and to get them more accustomed to how a tank explodes. The gas synthesis part can always be changed in order to reflect the current state of atmospheric reactions. ## C. Explosion Changes (Mid-Late Game) ### C.1 Cause and effect. The main theme of the explosion changes is establishing cause and effect of explosions. Reactions that happens inside a tank that's going to explode will be recorded and forwarded to a doppler array. Some experiments will require only a single cause to be present (think of it as isolating a variable). This is currently implemented for nobliumformation and pressure based bombs. Having other reactions occuring besides noblium formation will fail the first one, while having any reactions at all will fail the second one. Adding more explosions here will be a slight challange because as of now the game has only two reactions that can reliably make an explosion. ### C.2 Tools upgrade. Doppler array has now been retrofitted to state the probable cause of an explosion, be it reactions or just overpressurization on gas merging. These should help intermediate players figure out what is causing an explosion. Added a new functionality to the implosion compressor: Basically performs the gas merging and reaction that TTV does in a machine and reports the results back as if someone uses an analyzer on them. Here to give players feedback so they can try and understand what is actually going on in a bomb. ## D. Player Interaction There should be more room for more than 1 player to play ordnance simultaneously. Previously players are also able to split tasks, but this rarely happens because tritium synthesis needs only the gas chamber to be reconfigured. Now, different players can pick different experiments and work on them. Players can also do joint tasks on one single experiment. Gases like noblium will need tritium production and also a cooling module online. Ordnance can also coordinate with their parent department on what they really need, be it money or research bonuses. # Potential Changes The best-case changes that can be implemented if the current roster of content isn't enough is more reactions that can be used in bombs. Eliminating bombs entirely goes against the spirit of the subdepartment, while adding new ones will need a lot of care and consideration. Another possible change is to implement a "gas payload" bomb. Bombs that has a set number of unreacting gas inside that will increase the heat capacity, reduce the payload, and neccesitates more bespoke mixes. Adding more gas synthesis experiments is discouraged. The main focus of ordnance should be bombs, with gas synthesis being a side project for ordnance. These are present to ease the introduction to bombs and provide some side content. There should be a somewhat well-justified goal in adding new synthesis experiments: e.g. BZ is there as a "tutorial" gas, Nitryl to introduce players to cooling/heating mixes, Halon to a more efficient tritium production, and Nob as a nudge to nobformation bombs and mastery over other aspects. # Conclusion / Summary Add more experiments to ordnance that players can take, accomplish this by: 1. Making the players perform gas synthesis or make bombs. 2. Have them collect the data, see if it fits the criteria. Explain why if it fits and why if it doesn't. 3. Have the player publish a paper. Reward them based on how well did they do, give players agency both on the experiment phase and also publication phase. --- TLDR: Added new experiment to toxins, added the framework for those experiments existing. Experiments comes in gas synthesis and also bombs but with more parameters. Experiments needs to be published through papers, various choices to be made there. Implementation notes: Because of how paper works, ordnance experiments are handled outside of experiment_handler components. My reasoning for this is twofold: The experiments will be completed manually on publication and if the experiment isn't unlocked yet it will still be completed. Experiment handler datums have several procs which require an atom-level parent, and I figured this is the most sensible and cleanest way to implement this without changing the experiment handler datum too much. Small change to /obj/machinery/proc/power_change() signal ordering to adjust the state first and then send the signal. Didn't found any other usage of this signal except mine but barge down my door if it broke something. Rewrote the ttv merge_gases() code to be slightly more readable. A small code improvement for thermomachine to use tofixed (my fault). Ordnance have been updated to enable the publication of papers Several new explosive and gas synthesis experiments have been added to ordnance Anomaly compressor has been TGUIzed and now supports simulating the reaction of the gases inside the ttv. New tank compressor machine for toxins. You can overpressurize tanks with exotic gases and complete experiments. Several techweb nodes are locked and require toxin experiments to complete. Toxins can purchase boosts for various techweb nodes. You no longer need to anchor doppler arrays for it to work. Doppler array and implosion compressor now supports deconstruction, implosion compressor construction added. Doppler now emits a red light to denote it's direction and it being on. Doppler not malf. Implosion compressor renamed to anomaly refinery. Created a new program tab "Science" for the downloader app. Removed Robotics. Reworked the code for bombspawner (used in the cuban pete arcade game) |
||
|
LemonInTheDark
|
4051ad647e |
Space drifting fixes and cleanup (#64915)
* Fixes infi pushing off something in space Right now you can just push "into" a dense object forever, and depending on your move rate, just kinda glide We can fix that by checking if we're trying to push "off" something we're moving towards * Makes pushing off something shift it instantly Currently if you kick off something in space it waits the delay of the move to start drifting. Looks dumb, let's not * Updates backup movement to properly account for directional windows. GOD I HATE DIRECTIONAL DENSITY SHOOOOOT MEEEEEEEEEEEEEEEEEEE * Uses range instead of orange so standing on the same tile as a directional counts properly, rather then suddenly entering a drift state. I hate it here * Ensures all args are named, updates implementations of the proc with the new arg |
||
Cursed
|
79963a08f5 |
Pepper spray module for sec modsuits, Atmos resin module and nukie pyro bundle flamethrower made into module (#64934)
Pyro bundle was broken as when you brought it you would get modsuit and pyro backpack forcing you to either use armor or use backpack without fire protection(which modsuit has). Thanks to Fikou work it became a module Anti-Tider on the other hand is rarely used(i have never seen it used when i was playing sec or observing) and needed a little buff so now it will also became a module while i will make normal Anti-Tider stream wider(still working on it). |
||
Aerden
|
b5ae68778b | Firefighter tank can now be equipped in the suit storage slot of atmos modsuits. (#64709) | ||
|
LemonInTheDark
|
5ee5efbcd8 |
Hopefully fixes another source of long timer singlecaps (#64316)
* Hopefully fixes another source of long timer singlecaps
Very similar to
|
||
|
LemonInTheDark
|
815bb8ae40 |
Adds a movement looping system, replaces inbuild procs and spacedrift with it (#62567)
* Adds a subsystem to handle automated directional movement, replaces all instances of walk_towards with it. Makes meteors and immovable rods not drift in space, and makes immovable rods more destructive. Note, I've opted not to use byond's method of moving towards something, which is effectively Move(src, get_step(src, get_dir(src, target))) as it's cringe and doesn't make a smooth line. I've replaced it with a autoupdating rise over run setup, read the code for more details * woop forgot the subsystem * Documentation, contributing.md entry, and some cleanup * Makes the moveloop datum more oop friendly, sets us up for a lot of conversions * Converts the curseblob and walk_away() to the subsystem * Changes the default for override from FALSE to TRUE * converts walk() over, still need to add a replacement proc for it, but we didn't actually have anything that used the raw proc * converts the rest of walk_to() over, nearing the end now * cleans up some errors * Fully documents everything, fills in some missing movement types, uses the power of oop to make things cleaner, and typepaths longer * Finishes the contributing.md stuff * Done * Fefaults -> Defaults, can you tell I wrote this at 1AM? * resolves bubblegum issues * Roh's suggestions Co-authored-by: Rohesie <rohesie@gmail.com> * Cleanup * Hey lemon, did you know that Destroy() lives on datums? ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh * Converts over the discrepencies created in my absense * HAHA FUCK YOU I PAY MY DUES * Whoops lost some stuff in the merge * Converts the system from seconds to deciseconds to make dealing with the api more sane * Some stuff I missed * Makes movement an inheritable subsystem type, splits the moveloop file into two, one for the subsystem, and one for the datums * Makes a subsystem that handles directing movers out to other subsystems. It's a bit bad right now, but it's a good first step. I think I'll move the move loop datum to a lazy var on mobs instead of an assoc list, don't like lists. Also makes the movement procs global, I'll move em to the /movement subsystem at some point or something like that * Converts the existing uses of the procs over to the new format * Adds support for subsystem precedence, so a type of A can override type B. General cleanup, still kinda in debug mode but it's getting better * I'll admit I'm not too familiar with this, but I think it will work * Adds starting logic so movement types "pausing" makes any sense Redoes how waiting is handled to make it based on world.time directly. I don't remember why. I think it's better this way. Adds a drifting movement type, moves space drift over to it. Needs severe work before it's ready, too much info stored and modified on the moving object, see comment Starts work on making drifting smooth * Moves almost all space drifting vars over to signals on the movement datum Properly implements glide size stuff for both the subsystem and the loops. Space drift will be smoother now. It's not perfect, but it'll work just fine for now Adds a way to override a client'd mob's glide size mid move, uses it to make entering a spacedrift look right Adds a way to delay a client move outside of just move_delay, meant to be used for long periods, and setup such that it doesn't make inputs persist Adds flags to movement loops, alongside MOVELOOP_OVERRIDE_CLIENT_CONTROL, which blocks client movements while the loop is firing, and for it's visual delay after This means you can't exit a space drift until you hit the actual wall. This feels a lot better Some general logic stuff, move() will return true/false if it succeeded or failed Adds a stop_loop() proc that's called when a move loop is no longer active Suck my nuts * Moves precedence to the loop instead of the subsystem * Moves drifting into a component, this lets me explictly block input after the move loop ends, so people can't move the moment they functionally move onto a new tile This is a bit underdeveloped currently, but that's a problem for another day Cleans up some uses of move procs, fixes runtimes in metoer and curseblob code Adds signals for stopping/starting a move loop, sending one for destroy is redundant. Moves existing event signals from the movable being acted on to the loop itself, makes more sense this way Makes the move handler return the created loop up the chain so we can register to it Fixes a logic error in loop contesting code that lead to loops never actually being removed from subsystems because they didn't know they should be. Properly changes lifetime from a time to stop, to functionally an amount of moves to complete before stopping Adds some new signals for pre/post loop process. This is to better tie into components. I decided I didn't like the idea of tying all functionality to the loops themselves The loop decides functionally how to move, components or just tied in signals can decide when/when not to move and can modify properties of the loop Making a new loop for things like atmos drift, something I'm interested in tackling in the future, seemed silly * Moves movement procs directly to the subsystem for better namespacing or whatever * Moves movement packets onto /atom/movable, no longer need the debugging I've decided to not just put their contents fully onto atom movable, since it makes debugging on live much harder, can't sdql for them anymore. Fixes a runtime in meteor code, properly this time Fixes a logic error in stop_looping Makes move manager NO_INIT, because well, it doesn't init * Commits human sin, makes Recover() work properly for movement subsystems * Fixes immovable rod orbits not always working, they were returning too early in moved and fucking up the var we use to track move count, and thus not sending a signal properly * Reworks the curseblob to use signals more, and to not use override * Missed this in the movement ss commit * Removes override, makes having a higher or equal precedence take its place * Updates documentation * Cleans up some unused defines * Nukes the unused flags option * Whoops forgot to qdel check * Removes an unused var I had for client move prevention before I started using a component * Let's do this properly * Modernizes meteor code to better match how explosions actually work currently * Some more cleanup * Cleans up effect code a little bit Nukes the effect system's sleep loop, we use movement loops instead As a part of that, instead of 1 timer per effect spawned, we react to loop failure and make it 1 timer per effect system This should reduce the amoumt of slowdown we see after mass lighting break It's not everything, we're still making a timer per spark effect, but it cuts things down significantly * Updates explosions to not sleep * Adds support for modifying a loops delay post process, makes extinguisher code suck less then it does currently, nukes some more sleeps and timer loops * Converts water tank resin over to move loops rather then sleeps, minor behavior change mind, the cooldown starts on fire rather then on land, but I think that makes more sense anyway * compile and runtime fix * Fixes some runtimes, cleans up some code, ensures feature parity when it comes to logging * Prevents resin foam from space drifting * Adds support for flags back into the system, I need it for reasons * Updates move_towards to fix some bugs and resolve some inconsistent behavior, implements a flag that makes a loop's first move start instantly * Fixes extinguishers not actually transfering any reagents * Converts sprays to the new system. This does actually minorly change behavior, in that I've changed the order of spray actions from step -> sleep -> wash to step -> wash -> sleep, but I'm not terribly torn up about it because frankly I think it feels better * Converts grav catapults over to the new system * Converts trays over to moveloops * Converts robot streaking to move loops, the other two coming soon * Compile you won't. Also fixes a behavior issue with oil streaks * Does directional step_to properly, cleans up the other two streaking types * Converts step_trigger over, not that it's actually used anywhere. Changes how stoping a move works, you need to explicitly qdel, other the step is just considered to be ignored. This will make life easier later * Adds a jps movement loop. It's a bit bloaty, id is stupid, but it'll work just fine * Makes the system support passing in a datum that's just used as extra context for the move. The hope is this makes signalizing things less of an absolute headache * Begins the conversion of ai movement datums to movement loops * These two are reasonably simple, only weird thing I'm doing is A: Not allowing target hotswapping, which I hope none is doing, and B: passing the controller into the move loop as extra context so things work properly * JPS is a bit more complex, partially because the old implementation was a bit weird. 2 major things. 1: I'm dropping what I think was a redundant behavior minimum distance check from the premove bit of logic, since I'm pretty sure it didn't do anything. 2, instead of just stoping the step in an error state like being pulled, we count it against our max move total * Audit * Moves most forced movement to the framework, adds some components to make things nicer * Implements a flag that makes the loop always operate, regardless of precedence and without impacting any other loops * Moves movement subsystems into the right folder * Hey potato what if you had two procs that did the same thing and one called the other? Wow it's useless * Merges slipping and force movement * Converys conveyors over to the system. It's a bit fragile, but I think it's totally worth it to save the sleep loop * Precedence -> Priority, cleans up some logic errors, makes priority highest to lowest instead of lowest to highest, straight cleans some code up * Makes poly and bubbles ignore spacedrift, now that precedence actually functions properly. I'm likely missing cases of this, will deal with it later * Depression, thy name is linter * Fixes linter, and hopefully fixes the runtimes in ci too * Wew * Sets sprays and extinguishers back to legacy, since people do actually seem to have noticed * Spelling errors my beloved Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> * More detail, moves return descriptions * Converts transit tubes to the system? * Adds the glide size modifier. Not honestly sure that this should be default, considering how crummy it makes things look for normal walking, but it's useful as hell here * Adds a force move in dir template, actual support for fast initial steps (wtf old me) and a helper proc for setting delay * Cleans up displosal code a bit, I thought about adding it to the system but it would functionally be just 'disposal loops'. Maybe I'll make a template subtype? not sure how I want to handle stuff like this * Cleans up mob movement a bit * Let's use the controller's visual delay * Makes the resin thrower nicer, cries * Cleans up some comments, replaces an implicit world.icon_size with an explicit one, fixes up a typecheck * typecache instead of double istype. Can't do much about the !atom/movable, list would be too big I feel * hhh * bro wtf * Documents the why of SS_TICKER * Puts SSmovement on SS_TICKER. Lets us support tick steps * Cleans up the charge action. Makes it use moveloops * Fixes CI? kinda worried that this just got dropped * Converts disposal pipes to move loops. They stutter a bit more then usual as of now, hoping that's a me thing, if it's not I'ma look at uping the priority of the base subsystem * Moves the move subsystems off background, puts some on ssticker * Prevents some things that shouldn't move in space from moving in space * Documents the general form and usage of the system * Virgin one vs chad once Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> * Removes unneeded check * Moves appropriate movement subsystems into SS_BACKGROUND. Removes redundant SS_KEEP_TIMINGs I do want the behavior of SS_TICKER, which at this point is tick based waits, and ignoring overtime when calculating next fire. Since honestly, these subsystems should ignore overtime in regards to next fire, the cost of moving A may be nothing compared to the cost of moving B. * Makes the MODULUS macro use floor. I knew our coders would never let me down, glad this exists, thanks ninja Fixes teleporting caused by shitty round() behavior, adds a "you hit your target" case to homing loops * Converts blood splatters to move loops, that'll do it Co-authored-by: Rohesie <rohesie@gmail.com> Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> |
||
|
Fikou
|
7b38dd4ff7 | MODsuits (#59109) | ||
Ghom
|
b79dd74fd0 |
Replaces a portion of C-style for loops with the more commonplace for loops, which are faster. (#62624)
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> |
||
|
John Willard
|
6c0aba5da4 |
removes double spaces AFTER symbols (#62515)
* removes double spaces AFTER symbols * found more |
||
GuillaumePrata
|
1663f3efcb |
Changes Plasmamen belt tanks volume and the rate that their lungs consume plasma to 1/4 of the previous value. (#62081)
Plasmamen belt tank volume is 24, the extended engineering one is 6 and the emergency internals are 3. The issue balance wise is that all of those have the same pocket size and can be printed at the same Research tier, this results on smart atmos/engineers printing a plasmamen belt tank and filling it with O2 so their internals can last for almost 2 hours instead of the 24 minutes of the extended O2. Now they have the same volume but plasmamen lungs were rebalanced to consume plasma at a lower rate. To be clear, it will have no effect on how long the internal last for a plasmamen. Removes a no skill trick that gives you internals that will last for all shift, you can still make those but it will take a tiny bit of effort now. Also a small step to make internals balanced. |
||
|
Mothblocks
|
0f3c4e51f7 |
Modernizing Radiation -- TL;DR: Radiation is now a status effect healed by tox healing, and contamination is removed (#62265)
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else. Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter. Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away! |
||
tralezab
|
6c01cc2c01 |
every case of initialize that should have mapload, does (#61623)
## About The Pull Request stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload  ## Regex used: procs without args, not even regex `/Initialize()` procs with args `\/Initialize\((?!mapload)((.)*\w)?` cleanup of things i didn't want to mapload: `\/datum\/(.)*\/Initialize\(mapload` |
