Adds the navigate verb, it makes a holographic path to any navigation beacon on station
Video here: https://streamable.com/2uy76l
removes wayfiding pinpointers and the associated quirk, as theyre kinda redundant with it
needs #65665 before merge
partially inspired by goon
About The Pull Request
https://imgur.com/a/pMMEi4ihttps://imgur.com/a/xCrIcz4
Title, really.
Adds an ingame guide to atmos. Currently hooked to the atmos monitors, analyzer, and the tablet app.
Lots of reaction data not implemented yet, banking on the cleanup to get merged first, so drafting.
Done, all reactions in. Haven't double checked them though.
Code is pretty much finished, feel free to take a look. Ill probably retidy them while adding stuffs so no rush.
Might add a reaction handbook obj later Implemented in analyzer.
Dotted tooltip idea shamelessly stolen from preferences.
Lots of the diffs are from breaking the sensor file up, dont worry about it.
Why It's Good For The Game
Less need to open the wiki in another page I guess.
Changelog
cl
add: Added an ic atmos reaction guide. Available in your atmos control consoles/monitors, ntosatmos app, and analyzer.
code: Some changes to how gas canister descriptions are generated.
/cl
About The Pull Request
I noticed a lot of strange and un-intuitive behavior in action buttons, and got stung by the bloat bug. Damn it hug #58027
I'll do my best to explain what I've changed and why, might get a bit long.
If you want a better idea, read the commits. Most of em are pretty solid, if long.
Whelp. Here we go.
How do action buttons currently work
All action buttons are draggable, to any place on the screen. They're held in an actions list on the player's mob.
Their location in this list determines their position on the top of the screen. If one is dragged away from the top, its position in the list is "saved". This looks really bad.
If two buttons are dragged over each other, their positions swap. (inside the actions list too)
If a button is shift clicked, it is brought back to the position it started at.
If the action collapse button that you likely just mentally edit out is alt clicked, it resets the position of all action buttons on the screen.
If an action is ctrl clicked, it is "locked". This prevents any future position changes, and also enables a saving feature. With this saving feature, locked button positions persist between rounds. So your first o2 canister will always start where you saved it, etc.
Actions and buttons are a one to one link. While there is functionality to share action buttons between two players, this means showing the same object to both. So one player can move a button on another's screen. Horrendous.
This also makes code that modifies properties of the screen object itself very clunky.
Why is this bad
A: None knew pretty much any of this information. It is actually documented, just in a horribly formatted screen tip on the collapse button, you know the one we all mentally delete from the hud.
B: None of this is intuitive. Dragging buttons makes the hud look much worse, and you get no feedback that you even can drag them. Depressing
C: We use actions to make new options clear to the player. This means players can have a lot of action buttons on the hud. This gets cluttery
D: The collapse button is useless. It lets you clear your screen if someone like me fucks up and gives you 2000 actions, but outside of that it just hides all information from you. You never want to see none of your action buttons, just a filtered list of them.
E: On a technical level, they're quite messy, and not fully functionally complete. This is depressing.
What I've done
Assuming the above to be true, how do we fix them?
Well first I'm going to go over everything I changed, including links to major commits. I'll then describe the finished product, and why I made the decisions I did.
Oh and I've moved some of the more niche or technical discussion to dropdowns. Hopefully this makes finding the major functional changes easier
Adds helper procs for turning screen_loc strings into more manageable arrays. This doesn't fully support all of the screen_loc spec, but it's enough for what I'm doing. (f54865f)
Uses these helper procs to improve existing code (6273b93)
Fixes an issue with tooltip code itself. If you tried to hold down a mouse button while dragging onto a tooltip enabled object, it would silently fail. The js made assumptions about the order args came in, which broke when buttons were held down (e0e42f6)
Adds a signal linked to /client/Click(). Surprised we didn't have this before honestly (c491a4a)
Makes /client/MouseDrag() return parent. If we don't do this, any overrides of MouseDrag will never actually be called (2190b2a)
Refactors how action buttons work under the hood (53ccce2)
Basically, rather then generating one button per action, we generate one button per viewer
Starts to change button behavior, more cleanup
Changes the mouse cursor when an action button is dragged. Hopefully
this makes moving things feel less like an accident, and makes you doing
it more clear
Removes the moved and locked vars. This will be more relevant later, but
for now:
Moved exists as a sort of budget "We've been dragged" variable. We can
handle this more cleanly, and the movable type doesn't care about it
Locked is a very old variable that is also not something that the
movable type "owns". It's more an action button thing that's been moved
down.
It exists so an action can be locked in place, and in that locking, be
treated as a "saved location"
(21e20fc)
Because I've nuked move, we don't need to directly set our button's
position. We can use the default_button_position var instead. This is
quite handy.
Please ignore position_action, I will explain that later
(83e265e)
Removes the buttons locked pref
It was another obscure part of action buttons, basically do buttons
start "locked" or not. See previous discussion of locked
(b58b1bd)
Major rework starts here
Alright. Sorry for this, this is where me not commiting regularly starts
to suck. I'll do my best though.
Rather then figuring out an action button's position via a combination
of the moved and ordered vars, we use a separate location var to store
one of a few defines. This makes life later much easier.
Adds tooltip support for dragging action buttons. The way the tooltip
just froze in place when dragging really bugged me, and lead to some
nasty visual artifacts.
This is a bit messy because the drag procs are horrible, but it's
workable
Dropping a button on another button will no longer swap their positions
Behavior instead depends on the target button.
If it's a part of a group (A concept I will explain later) the dragged
button is simply inserted before it in the group's list.
If it's floating on the general hud, we instead position the dragged
button to its right. There's extra logic here to ensure buttons will
never overflow the screen, but I'll get into that later.
Alright. That's most of the refactoring. Time for the larger behavior
changes.
Adds a button palette. This is a separate dropdown that renders
underneath buttons.
image
The idea is to allow for a conceptual separation between "important"
buttons and the ones that end up cluttering the screen.
You can click on the dropdown to open it, then any later clicks that
don't involve actions in some way will autoclose it.
My goal is to come up with an alternative for the action button that
just acted as a way to hide all buttons on screen. Not convinced it saw
much use.
As a side effect of removing that, I've moved its tooltip stuff to the
palette. I've properly formatted it, so hopefully it's easier to read
then the jumble that we used to have.
(You can alt click the palette button to reset all button positions)
Oh and the palette can scroll, since as you'll see later it has a
limited size.
image
Moving on from that, I've added what amounts to action landing buttons.
These allow buttons to rejoin groups, or be positioned at the end of a
line of buttons.
image
They've got a 32x32 hitbox, and only show up when dragging. Hopefully
this makes the system more clear just by dragging an action.
Oh and I've changed how button position updating works. The old system
of calling update_action_buttons on mob every time an action button
changes position is gone, mostly because I've setup more robust
grouping. Will discuss when I get to huds
(0d1e93f)
Adds the backbone behind action button position changes (94133bd)
Moves hud defines to the global folder, safer this way (7260117)
Adds color changing to the palette button, giving some heads up for buttons being inserted into the palette automatically
image
image
Ensures a landing button is always shown, even if it needs to break the
max row rule
Makes palettes auto contract if they have no buttons inside them
Prevents palettes from being opened if they have no buttons inside them
(f9417f3)
How it looks
2022-02-26.02-30-10.mp4
Why It's Good For The Game
Players have more control over the clutter on their screen.
Buttons are available, but not in the way,
Since any player move of a button saves it, any lack of clarity in the way buttons work will be forced out by buttons not just resetting when a new game starts.
We don't overlap any existing screen elements, unless the upper button list gets really long.
The code is much less crummy (I think, may have made it worse it's hard for me to judge my own work)
If it ends up not being as usable as I'd like, I'll rip out the existing changes and just implement the qol and backend stuff. I think it's worth doing though.
Changelog
cl
add: Expanded heavily on action buttons
add: Adds an action button dropdown that sits just under the normal list in the top left. You can drag new buttons onto it to insert them. Click on it to show its contents, do what you want to do, then click again anywhere to contract it. Alt click it to reset all button positions
add: Action buttons will now remember their position between rounds. So if you really like your flashlight right next to your player for some reason, we support that now
add: When you start to drag an action button, docking ports will appear in places that it can be inserted into. (Outside of just floating somewhere on your screen of course)
del: Removed action button locking, and the associated preference. I'm reasonably sure literally none uses this, but if you do hit me up
qol: Dragging an action button will now give you an outline of its size around your cursor
fix: You can no longer cause the screen to expand by putting an action button on the edge of widescreen, and then resizing to standard.
refactor: Refactors action and button code significantly. lots of little things.
/cl
* Prevents potentially infinite length books from being written and stored. I'm not sure if this is an actual issue, but I have a funny feeling it may become one someday
* Moves the paper defines to their own file
* It's become clear to me that I am stupid
* git add --all
* Makes book info into a datum to allow for easy passing around
* Converts the library scanner to tgui, lays the groundwork for tgui visitor consoles
* Makes the db request for book info sort
Adds the frontend for the visitor's console
Adds a hash to prevent duplicate db requests
Adds a prams changed var to help facilitate a better search button
Makes the page number code accept text as input
* Makes the ui index at 1 even tho we index at 0 internally
* Begins the conversion process for the library console.
Changes the library console to override the visitor, to utalize for the archive access portion of the ui
Makes scanner into a weakref, I'm coming for you handheld scanner
Renames some vars to make things clearer
* Converts the remaining refs of the old console typepath over, adds a circuit board for consoles because pain
* Changes how bookshelves load in books
Instead of loading them in lazyally, we load them during init
This lets us track what books are stored in which areas
Somewhat jutting off of this, adds map config for designating something as "part of the library"
This will be useful later
* Renames the random poster, adds a spritesheet for bibles. Both will be useful in a moment
* Ok. This is a bit of a mess.
Converts the library console to tgui.
This comes with a few minor behavior changes:
You can now select what type of poster you want to print, instead of just printing a random one
It's now possible to heed the console's emag warning
The console's inventory page will fill at roundstart with the books in your area/if you're in a library, any
areas designated as "library like" in the map config
You can see what type of bible the chaplin has selected?
"Fixes":
You can no longer just dump books into the scanner forever
Implementation details:
Any input that makes a db request will now A: freeze up any other db inputs until it's finished, and B: Start a
1 second timer before any new db requests can be made
Of note, I'm handling html encoding in a very targeted way.
All book_data datums need to have html encoded values. get_title/author/content exist so a defaulting and tgui
appropriate version can be loaded in. This somewhat matches with the trusted var on set_title, it exists to
prevent double html encoding.
While we're here
Input/DB (Book data should be html encoded)
Inside book datum (Book data should be html encoded)
Sending to tgui (Book data should be decoded during extraction with the get_() procs)
Sending anywhere else (Book data should be html encoded, otherwise it's an xss vuln)
Uhhhh tgui stuff?
I'm using a custom theme for emag visuals, I'll get into that more later
The visitor and book management console share the same data/act pipeline, which is why they're parented/subtyped
They also share a page selection component, which is why the visitor's console imports it.
Uhhhhh
Oh right, fuck.
Ok so the page selection component is kinda cursed, the left and right controls are fine
But I'm trying to get a << < [page/max] > >> setup going, and that means resetting the center input past change
so the default value can be used
This ends up being slightly hacky. I'm sorry.
Oh also, I implemented a custom tab setup for this ui. I have no idea why it was literally like 5 months ago.
I think it looks pretty nice, but if you want me to nuke it I can. Sorry for any headache around this.
More tgui stuff next
* Scanner/visitor cleanup, some other odds and ends
* Adds in a dark red and black theme for library computers to be triggered by an emag.
Things of note: I'm overriding some lists that get passed into buttons and one other thing using set, since the
list is alreadt generated by that step in the process? I think?
I've added dimness control to the dimmer component, since well, it was dimming already dark uis.
I also made and added a rather large background svg. I've got no experience with this sort of thing, and all the
compression methods I found for this ended up being busts. I know this isn't acceptable as an end product, but I
don't know how to get it there.
Somewhat on that note, this ui might not be worth the size for the amount of use it gets. I'm fine with nuking
it if that's the case, I bring this up because I have a very poor understanding of the logistics of something
like this, so I have a feeling I've fucked up somewhere
* Forgot these, just a scss file for library computers, barely used but I think it's worthwhile
* Missed this eariler. As a part of the uploading tab, I'm displaying the contents of books. I'm loading in that
context as raw html so paper -> book books look close to right. Means I need more html tags then our current
sanitize provides. I don't think any of these will cause issues, and there's also a good chance I'm missing
some. Will come up with a list later
* Updates the rest of the maps to use the new management typepath
* Fixes the default bible name being Default Bible Name, I am sorry
* Turns out I had the scaling wrong for bible names, lead to weird stacking because the bible icon doesn't scale, so I lowered its sizing
* Yeets unneeded exports (Thank you jlsnow)
Haha wouldn't it be funny if I didn't know how components worked
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
* Resets the maps to master
* Fixes oversights from merge commit, changes maps
* Removes needless Flex's from the scanner
* Gives the library console the ability to parse markdown. Expands the list of acceptable html elements a bit
* Adds audio cues for printing and inserting/removing from the scanner, makes the scanner nicer to use in general
* Uses a compressed version of the background. It's still huge, but smaller at least
* Adds the printing audio to the book binder
* Cleans up tram
* curse you tram
* AHHHHHHHH
* MY LIFE IS TRUE PAIN
* Adds a path conversion statement to make people's lives easier
* Apply's style's suggestions
thx style
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Compresses the background svg
* Further js cleanup
* We no longer render markdown in the ui, since any source of markdown is converted to html anyway
* More ui changes
Makes the tab/main screen logic use Flex rather then manuel offsets
Makes modals better fit the size of their contents
Readjusts the width of some inputs
Properly uses the header prop for a table
Makes the buttons in the upload panel look nicer
Restructures the print tab a bit
* Increase a modal's size
* Fixes computers with no keyboard overlay showing their screen even when the power is out
* Moves some data and logic onto the library subsystem. Kyler's review
Fixes harddels held by the library scanner. Makes the scanner's buffer
actually do something
* Makes book icon randomization a proc rather then just copypasta'd code
* Removes the kilo library edit, the soul was removed
* Damn you san (Fixes mapconflicts)
* Pain
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Although these vars are unlikely to ever change, if the vars were ever renamed it would result in these strings not erroring properly if they weren't updated as well.
Alsonce scrubbers only wake up if something they can filter is on the tile an existing bug where scrubbers dont filter very small but non garbage collectable amounts of a gas becomes a big issue, as in without changing scrubbing rates you can breathe once on a tile with a scrubber set to scrub co2 and that co2 wont go away barring any other factors and the scrubber wont go to sleep. so now with the idea of rohesie and permission of lemon i changed how scrubbers removed small molar amounts of gas from their turf. now scrubbers will look through 100% of the turfs air mix for filtering, but will only remove up to
gas moles * (scrubber volume / turf volume) * (gas moles / total filterable moles) moles from each filterable gas in the turfs mix unless that amount is less than either MOLAR_ACCURACY * 100 or the number of moles of that filterable gas, in which case all of the moles of that gas are subtracted from the mix. this is to make it easier for the scrubber to remove very small amounts of gas with filters without changing how fast they scrub large amounts of gas, thus making scrubbers able to go to sleep faster only after a gas has been reduced to near zero
scrubbers are the biggest proportion of SSair's machine processing cost which is a non trivial amount of SSair's total cost. now they will only do most of their work if they can actually scrub anything on the tile which is a minority of the time.
Renames ACCESS_SEC_DOORS to ACCESS_BRIG_ENTRANCE
Renames ACCESS_FORENSICS_LOCKERS to ACCESS_FORENSICS
Adds a helper for detective access (because I forgot it in my first PR, oops)
Changes gulag item reclaimer access from ACCESS_SECURITY to ACCESS_BRIG
This PR moves the in-game Newscaster over to TGUI, which is one the most bothersome html to tgui projects on the codebase being that it's gone untouched for like... over 4 years now after the introduction of tgui. Newscasters are widely used in-game by players wanting to be deranged whistleblowers, noir detectives, and journalists. They're flavorful, fun, and we still use an html window to make them run so it looks like it's from 2003.
* Refactors tcg code a bit. Adds support for "keywords"
Idea is to allow card makers to embed tooltips in their card
descriptions.
These tooltips are defined in the keywords.json file
They can be referenced using {$keyword_name}
I've also done some refactoring to move more logic and state onto the
subsystem, and implemented a few keywords from the wiki
* New keywords, applies the old ones to the second card set
* Adds support for embedding react components in tgui chat
This is done by adding the data-component attribute to an html element
The value of that attibute is the component you want to use.
New components can be added by modifying the TGUI_CHAT_COMPONENTS list
in tgui-panel/chat/renderer.js.
Props can also be passed in in a limited capacity.
Any props you wish to pass must be added to
TGUI_CHAT_ATTRIBUTES_TO_PROPS.
This is due to a style restriction of html attributes, they cannot
contain an upper case char.
Use this list to convert between attibute compatible text and the prop's
name.
Props support 3 datatypes.
true and false can be passed by wrapping them in ""s. (Note to self add
a special char here to prevent colison with people just passing the
string true.
Numbers are supported in a limited capacity. Whitespace is not allowed,
but floats and ints are fair game.
And of course, strings are fully supported.
I've currently added support for Tooltip, since that's what I'm using
this for. Also added some tooltip html styles to the chat css.
* Implements the embedded component system to make tcg cards have nice pretty tooltips so people don't need to have the wiki open on one screen
* Adds documentation for embedding tgui components in chat, adds some protection against accidentially sending true as a bool
* Adds italitcs to the tooltips, moves the span stuff to a macro
* tGUI -> tgui, thank fikou
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Style suggestions
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Removes unneeded key from the components list
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Removes needless span
* Actually adds the tooltip, oops
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Restores the Persistant Scars preference
I also had to remove some raw READ_FILE()s because that was now useless. I was thus able to remove the persistent_scars variable from the prefs, as it is now a standalone preference.
* I forgor...
About The Pull Request
Simply converts all instances of soundkeys that use get_sfx from strings into defines.
E.g. "sparks" is now SFX_SPARKS
Why It's Good For The Game
It makes life a lot easier when you're looking for a sound effect. You just type SFX_ and you get suggestions in VSC. Plus, it looks better.
image
Changelog
Not player facing.
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)
Essentially SSmapping had a list for each theme of ruin (space, lava,
ice, ice underground). These were all filled with an if statement
checking the ruin templates type. Now, i've given ruins a ruin_type var, which is then used to dynamically add to a single list of ruins, which separates lists of ruins by ruin type.
Good for downstreams who may have more ruin types
Changelog
cl
refactor: Dehardcoded SSmapping ruin types.
/cl
Should help when paintings lists gets zeroed unintentionally during the round for some reason.
Now it only deletes the painting file right before it writes the new file to prevent loss of data if anything runtimes or breaks.
Makes SSTimer actually recover properly when it needs to. This is a follow-up for #60846 (3da51f515d) with code I added in my port of that PR to bee.
There were 3 main problems, and each was uncovered after fixing the previous:
/datum/controller/master/New() was using faulty logic to find existing subsystems. It was adding Sound Loops twice and not adding Timer at all (Sound Loops being a subtype of Timer).
/datum/timedevent stores a ref to the timer subsystem in var/datum/controller/subsystem/timer/timer_subsystem for performance. It wasn't being updated to the new Timer subsystem, ultimately resulting in it runtiming as an invalid timer.
The buckets need to be reset during recovery. The TTR and other bucket-related handling is out of whack because SSTimer wasn't firing for however long recovery took. Luckily reset_buckets() can already handle all of this.
Missing continue in the random job assignment code meant an if statement was ineffective, code fell through and assigned roles to jobs that were already full.
Fixes a runtime error that can occur during DivideOccupations() in the event that one of the players has their clients disappear during setup due to classic byond client volatility.
If a new player's client vanishes during job setup, it will read as null instead of runtiming, which throws a JobDebug and moves onto the next player.
* Removes hardcoded job from SSjkobs. "station_jobs", "head_of_staff_jobs", "additional_jobs_with_icons", "centcom_jobs" have been removed and replaced with flags and vars on the trims.
We should just straight up not be processing turfs if the adjacent turf
isn't correctly setup
It used to be on a seperate subsystem with a second wait with the idea
of reducing the cost of explosions, but since they're instant now
there's no reason to not just have it on SSair. Gets rid of my excuse
for process_cell runtimes too
Adds a basic bucketing system to move loops.
This should hopefully save a lot of cpu time, and allow for more load while gaining better smoothness.
The idea is very similar to SStimer, but my implementation is much more simple, since I have to worry less about long delays and redundant buckets.
Insertion needs to be cheaper too, since I'm making a system that by design holds a lot of looping things
It comes with some minor tradeoffs, we can't have constant rechecking of loops if a move "fails", not that we really want that anyway
We also lose direct control over the timer var, but I think that's better, don't want people manipulating that directly
Not that it even really worked very well back when we did have it
Removes the sleep from singularity code
Rather then using sleep to store the state of our iteration, we instead queue the iteration in a list.
We then use a custom singulo processing subsystem to call our "digest" proc several times per full eat, with the hope of staying on top of
our queue
This rarely happens because the queue is too large, god why is a sm powered singulo 24x24 tiles.
I've also A: cached our dist checks, and B: Added dist checks to prevent attempting to pull things out of range
This might look a bit worse, but it saves a lot of work
Oh right and I made the singulo unable to eat while it still has tiles to digest. The hope is to prevent
overwork and list explosion.
Hopefully this will prevent singulo server stoppage, though I've seen some other worrying things in testing.
This PR updates and refreshes the whole of black market code for improved usability as well as to better sell the backbone of the content behind the blackmarket in-game.
For starters, the datums for the black market were designed around not being specific to the black market. Reading the code, it was intended to allow for multiple blackmarket_markets to be added after it's original inclusion, which was passed up as a result of what I'd guess is a branding issue, as every datum associated with the blackmarket was labeled... as for the black market, nothing else.
So to begin I've renamed most of the backend of the blackmarket code to just market instead, datum/market, datum/market_order, datum/market_item, datum/market_uplink(/blackmarket). The works.
Next, QOL change to how blackmarket uplinks were implemented: Now, instead of having to manually load credits into a black market uplink by hand, then choose to buy things using the uplink, they instead just draw from the user's ID card, checks for a bank account, and purchases through that, with quick inputs added when purchases are successful and warnings when a purchase cannot be made.
Lastly, code change. In an old economy PR of mine I standardized purchased cargo items to use the CARGO_CRATE_VALUE define, and for vendible items to use paycheck defines instead. In that PR I rebalanced quite a bit of prices as a result, but this got passed up when that happened. I'll leave the balancing for another time then, but this updates the code of market_item datums to use CARGO_CRATE_VALUE for their upper and lower cost ranges to maintain that standard.
I made this because I was just messing with jobs and remembered about jobs' tgui prefs being de-hardcoded so thought about doing it for the in-game jobs as well.
Why It's Good For The Game
Not good for the game, but is just a QoL for downstreams who have custom jobs.
Changelog
Not necessary.
* Atoms (mostly new players caused by logout) can get deleted before spatial grid initializes.
* Fixes images when viewing your notes before SSassets initializes.
* Fixes abandoned crate runtime.
* Fixes armor runtimes on eating clothes (this really needs alternative solution)
* Revert " Properly speeds up a lot of things, mostly mobs (#64270)"
This reverts commit a836574388.
THE BYOND REF WAS A LIE, THE PLAYERS ARE FOOLS, HELP, HELPPPPPPP
It turns out that despite what the byond ref says, the walk proc's delays were not in fact in ticks, but in deciseconds.
This means when I "fixed" mob movement by doubling all walk delays, what I actually did was double the speed of anything that used walk()
I have a feeling that the actual issue players were seeing was just move_to having fucked up distance logic, and the movement of slow mobs being smoothed out. I've changed that, so hopefully this puts a seal on the whole problem
I've had a request put in to make beepsky faster, but I think that's best done in a seperate pr
* Adds a flag to disable smooth moveloop movement
Applies it to hostile mob's Goto()
Backports the fixes to move_to and move_away from the previous pr
Adds a /datum/autowiki template which can be derived in order to create wiki pages and queue file uploads. This is then kickstarted by the new tgs target autowiki (using the AUTOWIKI define) in order to upload these pages.
The pages generated are, in a best case scenario, raw data. This means that wiki editors can decide what the actual theme is without ever having to touch the repository. In the future, MSO will hopefully sandbox the wiki and install Scribunto to let us separate data and style even more.
These will, when done, upload to templates, such as Template:Autowiki/VendingMachines. The actual pages (in this case "Vending Machines") will include this, and thus can write down their own prose and whatnot without ever having to touch repo.
This will also be run on a daily GitHub action, with some secrets setup to link to the account. Currently this is on a bot password (my forum account will not be leaked in the event of a collapse), but at some point I would like to create a dedicated bot account.
This PR adds a Techweb and Vending Machine autowiki. You can look at the Vending Machines one here and the Techweb one here.
I have absolutely no idea what to label this PR (other than note the unit tests I've added). Feel free to add whatever gives GBP 😉
This removes code/__DEFINES/misc.dm and moves all the defines to either:
another existing define file
new define file
local .dm file if the define was only used in one file
I also deleted defines that were not being used and added documentation to all of the ones that were moved out of misc.dm
Why was this needed? People were basically using the misc.dm file as a dumpster to toss all their defines into that was creating one giant mess. The defines have been organized into their proper groups and files now.
Ports fix from SStimer #64242
Why It's Good For The Game
Changelog
cl Semoro
fix: Avoid runechat scheduling too far events into short queue (port from SStimer)
/cl
makes most updating stat panel tabs update once every 4 seconds instead of 4 deciseconds, but switching tabs instantly updates statpanel data for you. also makes examining a turf make flat icons for a maximum of 10 contents instead of 30 because its ridiculous to call getFuckingFlatIcon() wrappers that many times. also makes SSfluids not have SS_TICKER and updates its wait accordingly because theres no reason for it to be a ticker subsystem
the mc tab updates every 2 seconds unless someone has the pref enabled to refresh it quickly because SOME UNILLUMINATED LEMONS absolutely must watch overtime spikes in real time
statpanels can take between 1-3% of masters total processing time at very high pop, which is silly considering theres no need for someone to know any of the data updated accurate to less than half of a second. The only reason it needed to update so fast was because it looked awful when switching tabs, which will only be updated on the next fire. now switching tabs updates data instantly so theres no need to update the rest of the data quickly.
also makes each stat tab update into its own proc so we can tell how much each tab update costs
Fixes#56292
Why It's Good For The Game
Increases chances of smooth experience
Changelog
cl Semoro
fix: timers not removing from second queue on init
/cl
Previously it was possible for events to enter the short queue when the timer is offset by more than BUCKET_LEN
Now it is forced to schedule events into the second queue if the timer is processing slower then world time goes allowing the timer to keep up
This PR provides a better definition of TIMER_MAX to avoid scheduling timed events that are more than one window of buckets away in terms of timeToRun into buckets queue and properly passing them into the second queue.
Ports ss220-space/Paradise#578
Should be merged with/after #64138
Detailed explanation
The timer subsystem mainly uses two concepts, buckets, and second queue
Buckets is a fixed-length list of linked lists, where each "bucket" contains timers scheduled to run on the same tick
The second queue is a simple list containing sorted timers that scheduled too far in future
To process buckets, the timer uses two variables named head_offset and practical_offset
head_offset determines the offset of the first bucket in time
while practical_offset determines offset from bucket list beginning
There are two equations responsible for determining where timed event would end up scheduled
TIMER_MAX and BUCKET_POS
TIMER_MAX determines the maximum value of timeToRun for timed event to schedule into buckets and not the second queue
While BUCKET_POS determines where to put timed event relative to current head_offset
Let's look at BUCKET_POS first
BUCKET_POS(timer) = (((round((timer.timeToRun - SStimer.head_offset) / world.tick_lag)+1) % BUCKET_LEN)||BUCKET_LEN)
Let's imagine we have our tick_lag set to 0.5, due to that we will have BUCKET_LEN = (10 / 0.5) * 60 = 1200
And head_offset of 100, that would make any timed event with timeToRun = 100 + 600N to get bucket_pos of 1
Now let's look at the current implementation of TIMER_MAX
TIMER_MAX = (world.time + TICKS2DS(min(BUCKET_LEN-(SStimer.practical_offset-DS2TICKS(world.time - SStimer.head_offset))-1, BUCKET_LEN-1)))
Let's say our world.time = 100 and practical_offset = 1 for now
So TIMER_MAX = 100 + min(1200 - (1 - (100 - 100)/0.5) - 1, 1200 - 1) * 0.5 = 100 + 1198 * 0.5 = 699
As you might see, in that example we're fine and no events can be scheduled in buckets past boundary
But let's now imagine a situation: some high priority subsystem lagged and caused the timer not to fire for a bit
Now our world.time = 200 and practical_offset = 1 still
So now our TIMER_MAX would be calculated as follow
TIMER_MAX = 200 + min(Q, 1199) * 0.5
Where Q = 1200 - 1 - (1 - (200 - 100) / 0.5) = 1200 - 1 - 1 + (200 - 100) / 0.5 = 1398
Which is bigger then 1199, so we will choose 1199 instead
TIMER_MAX = 200 + 599.5 = 799.5
Let's now schedule repetitive timed event with timeToRun = world.time + 500
It will be scheduled into buckets since, 700 < TIMER_MAX
BUCKET_POS will be ((700 - 100) / 0.5 + 1) % 1200 = 1
Let's run the timer subsystem
During the execution of that timer, we will try to reschedule it for the next fire at timeToRun = world.time + 500
Which would end up adding it in the same bucket we are currently processing, locking subsystem in a loop till suspending
On next tick we will try to continue and will reschedule at timeToRun = world.time + 0.5 + 500
Which would end up in bucket 2, constantly blocking the timer from processing normally
Why It's Good For The Game
Increases chances of smooth experience
Changelog
cl Semoro
fix: Avoid timer scheduling too far events into short queue
/cl
When I made my move loop changes (815bb8a) 62567, I converted a few walk() procs to
the new system
What I didn't know when I did that conversion is that walk() operates on ticks, when move loops operate on
deciseconds
So when I converted say, mob movement over, I accidentially halved the attack movespeed of all of our mobs
This resolves that, alongside a few other misteps
Of note: There are old comments implying that walk()'s delay is not actually linear, or simply as the reference says "in ticks"
I don't have a good idea of how fast things actually should be though, which makes this tricky
In light of this, I've decreased the move speed of legion slightly, in hopes that it will feel more "normal"
I've also fixed a bug with move_to and move_away, they were treating their distance parameters as move to this and one more, rather then move to this. This lead to mobs attempting to overlap with your sprite. s cringe, and also fixed
Fixes misc moveloop runtimes souced by mid move deletes and disposal loop traps, this was caused by a misunderstood bit of logic. current_pipe needs to be set to the actual return value of transfer() rather then our current location
Space drifting "listened" for moves outside of its expected range, and if it saw them it would self delete
The problem is it registered for this behavior in drifting_start(), which was intended to be called by the MOVELOOP_START signal
But because that signal was fired as a consequence of move() being called, we never registered the signal
So if you took an item out of your pack, when it hit the ground it would get the drifting component
Next tick it would be drift moved to its intended location, the move would "fail", and then it would stop
This lead to items being visually in your inventory, but not functionally
Which leads to a lot of really weird behavior
Oh and I added a var to moveloops that's just "are we running" to make solving this class of issue easier
As it is right now, we never actually clear the temporary list processing_queries
So if the subsystem is for some reason unable to complete a run, we will just whip right back around to it again
If it's been long enough, this could even cause horrific log spam. There was just now a manuel round with roughly 30k undeleted query errors. not good.
But what was actually not deleting you may ask?
Well
When you create a db request, a 5 minute timer starts. after those 5 minutes are up, the request is qdeleted by the db subsystem
This is to prevent the creation of unused requests, and to handle requests that are never cleaned up
Telemetry code was creating all of its db requests inside a for loop that could check tick, and then later
attempting to call them in series
Since requests by default sleep, this almost always lead to undeleted queries, which harddel'd given long enough periods
I've fixed this by moving the data gathering away from the query creation
Why is it good for the game
I was working on atmos code, happy, safe in my delusion, when suddenly I got a ping from tattle freaking out over 200 undeleted queries a second
This resolves that issue, so I can once again live in peace
Changelog
cl
admin: Telemetry code will spam you with undeleted query logs much less often now!
server: Improved how the db subsystem handles undeleted queries, should never have an incident like that again
/cl
