## About The Pull Request
This shit has confused people too many times, let's give them an easy
pathway to use reftracking
Also split the separate logging bit into its own thing
## About The Pull Request
Adds `MAP_TEST` compile flag.
This compile flag blocks common things which make it difficult to test a
map.
Things this applies to:
- Rats no longer spawn.
- Rat spawning will (obviously) break up the powernet, which is
INCREDIBLY annoying when trying to test if all the rooms of the station
are wired correctly (or testing which rooms lose power first, etc)
- Light tubes no longer break on initialize.
- Random light breakages can easily cause mappers to accidentally over
light a room.
- Roundstart command report is not printed.
- Might be a personal preference, but it's kinda annoying to hear the
alert over and over again.
- Random events do not trigger.
- Some events such as gravity generator outage can trigger with 0
population.
- Random camera breakage event can cause over-placement of cameras.
- Other stuff tends to just get in the way.
- Station traits do not trigger.
- Probably the biggest annoyance. Many traits modify the map in some way
which disrupts testing.
- Roundstart landmarks don't self deletes.
- Allows mappers to use sdql to find them.
- Mapping verbs start enabled.
Obviously more things can be added if they come up.
This being 2 is causing all connected clients to get all generated or
runtime created assets (like tts), but it is not set to 2 on prod
because the rsc cdn requires setting this to 0 via
`server_side_modifications.dm`
also causes spritesheet to send resources out to all connected clients
every insert mid generation, massively slowing it down as it will
FUCKING BLOCK during this.
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
[Reduces timer insertion cost by
80%](c9e5b285ed)
Timer name generation involved a LOT of string shit, some in ways where
the string only existed for a moment.
This costs a good bit of time, and can be reduced with only minimal
impacts on the end product, so let's do that. Includes a compile flag to
flip it back if we ever have trouble in future.
This is about 0.1s off init, since we do a lot of timer stuff then too
[Removes STOPPABLE flag from QDEL_IN, moves it to a bespoke
macro](e7a5d7f2a7)
Its a waste most of the time, tho I would LOVE to analyze at compile
time to work out if we care
## Why It's Good For The Game
I like it when we don't spend all of our cpu time just setting the name
var on timers. that's good and not bad.
This saves time fucking everywhere. 15% off explosions, 0.1 seconds off
init, bunch of time off foam. it's just good.
Cherry picked out of #76104 since that was too cluttered (sannnnnn)
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
Avoids calling `cut_overlay` if we know that we manage every overlay
we're about to remove, and short-circuits to `overlays = null`. This
saves the cost of building the appearance list and performing `-=` of
the list.
More minor change, splits validation part of `POST_OVERLAY_CHANGE` into
`VALIDATE_OVERLAY_LIMIT`. This is because there is no point checking if
we hit the overlay limit after removing overlays, since we would've
checked in `add_overlay` in reasonable cases.
## About The Pull Request
[Saves 0.2 seconds of init time. 50% of emissive
blockers](8318b648f6)
Emissive blockers are a decent expense during init, even these, which
are the ones that update outside of initialize.
I've inlined them, removed some redundant vars and checks, reduced the
arg count, and shifted some things around. This ends up saving 200ms, or
50% of its total cost.
I also shifted mutable_appearance about a bit. it's not a massive
saving, but it is technically faster
[Prevents a few redundant appearance_updates, saves 0.8 seconds of
init](5475cd778b)
Prequisit info: update_appearance is decently expensive
It's good then to only do it if we have a reason to, right?
Me and moth were shooting the shit about just general init time, and we
came up with the idea of tracking which update_appearances actually
"worked" and which didn't.
That bit comes later, let's enjoy the fruits of that work first
First, holograms were calling update_appearance on process, for almost
no reason.
I patched the one event they don't already "react" to, and then locked
it behind a change decection if.
good for live, doesn't impact init.
Next, decals. If you add a decal to something before it inits, it'll
react to the after successful init signal.
The trouble is the same atom could have its appearance updated from this
MORE then once, since decals can be stacked on tiles, and signal
unregisters don't work once the signal is sent.
So we add a flag to track if we've had this happen to us or not, so it
only happens once.
saves 80 ms
Power! lots of things call power_change on init, often more then once.
We'll update appearance for each of those calls, even if only one is an
actual change.
That's silly, better to track what sort of power we're using for our
appearance and go off that changing
This was taking about 300ms. Really stupid
Icon smoothing. After emissive blockers were added, any change to
something's icon smoothing would lead to an update_appearance call.
Nasty shit, specially cause of walls, which don't even use emissive
blockers.
Ok then, so we'll always update appearance for movables, and will allow
turfs that are interested to hook it manually.
Not many of those anyhow
This is slightly a dev ux thing, but it saves 600ms so I think it's
worth it. Rare case anyway
Telecomms:
telecomm machines were updating appearance on process. This is to cover
for them turning on/off on process.
Better then to just check if on actually changed.
This cost adds up midgame, doesn't impact init tho
Materials:
There's this update_appearance call in material on_apply. it doesn't do
anything.
The logs will lie to you and say it does, but it's just like reapplying
emissives. It doesn't need to exist
Saves like 50ms
Canisters:
Live thing, lots of time wasted updating appearance for no reason, lets
see if we change anything first yes?
[Uses defines to wrap update_appearance for
tracking](4fa82e1c9d)
[Undoes _update_appearance changes, instead reccomends 2 regexes to
use](a8c8fec57a)
I need file and line number for my tracking, so I need to override
update_appearance calls, and also preferably not require every override
of update_appearance to handle dummy file + line args.
So instead, I created a wrapper proc that checks to see if appearanaces
match (they're unique remember, the two of the same visual appearance
will be equivalent)
The trouble is I can't intercept JUST proc calls, or JUST function
definitions with defines. it needs to be both.
So I renamed the /update_appearance proc to /_update_appearance
this way I can capture old uses, and don't need to worry about merge/dev
brain skew
~~It does mean that all update_appearance proc definitions now look
weird tho.
My profiling is leaking into dev ux. I wish I had better templating.~~
**The above is no longer being pr'd**, it's instead just recommended via
a few regexes adjacent to the define.
Smelled wrong anyhow
[Adds a setter for panel_open, so I can update_appearance on
it](cf1df8a69f)
## Why It's Good For The Game
Speed
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>
Adds `USE_BYOND_TRACY`, which automatically loads a given
prof.dll/libprof.so using https://github.com/mafemergency/byond-tracy/.
Not intended for use in production, and we do not ship a copy of
byond-tracy. It is extremely easy to compile yourself, but if you're
someone interesting enough to play around with this then let me know and
I can just give you a build.
I'm going to be using this for init profiling.
It occured to me, we didn't have a good way to "see" what turfs were actually being updated
Figured I'd fix that
I've also added some debug vars on SSlighting to make testing with/without some checks easier
Speaking of which, I've added a second check to lighting corner updating
Basically, if our past and current cached rgb values are the same, there's no point updating
This is possible because static lighting is relative. If you've got a
TON of blue, it'll outweight the red and green you have in smaller amounts
We also do some rounding to ensure values look right
Similarly, if you've got roughly the same lighting, and a bit of something you already have a lot of is added, you're not likely to actually enter a new "bracket" of color
Anyway uh, it's hard to profile this, but I've seen it help quite a bit, mostly with things like emergency lighting that updates lighting in small amounts often, and in constricted spaces.
To some extent just comes down to map design
Adds a macro that consumes cpu up to some tick limit
Adds a define that uses said macro to leave verb processing just its
reserve of the tick
Adds a second subdefine that forces verb processing into total overtime
Mimicing the worst case scenario around maptick spikes
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 😉
About The Pull Request
This is a fix for map not load anymore because of security changes
Why It's Good For The Game
Maps are good as they encourage gameplay and differentiate ss13 from a classic MUD game
Changelog
cl
add: unit test for map load
add: directory param to map load + whitelist for data and _maps
add: advertising for mojave sun in tg commit logs
/cl
This PR fixes a bunch of the code for load_map_config(), documenting it better and removing a deprecated (I hope) parameter that was also a security concern along the way, while also making another proc for just loading the default map config, which is supposed to always be functional.
Basically, saves developer's time by yelling that the compiler can't write to dmb/rsc, because they are locked by Dream Daemon.
Added myself as a code owner for /tools/build.
Sourced from #59118 and a cursed project I'll pr later, This pr contains a lot of harddel fixes for stuff that pops up after a player interacts with something. I'm not gonna list them all here because there's something like 60 130, check the commit log if you're curious
Oh and I moved ref tracking screaming to a separate define, and made some optimizations to the thing in general. I think that's it, this pr is a bit of a frankenstine
* Adds in support for basic send maps profiling, I'd still like to get something that tracks with the round a bit
better, but we can worry about that later
* Adds a debug verb that displays the sendmaps profiling page, as basic as it is
* Define respect
* Patches over an error where profiles would persist through rounds, somehow. Adds the maptick stuff to performance logging, so we can look at how things change over a short period of time
* Ref Tracking: Revengance
Fixes reference tracking ignoring self references due to a poorly thought out tick checking system.
Fixes reference tracking ignoring the contents of assoc lists
Makes the reference tracking printouts actually describe what list the ref is in, rather then just saying "list"
Adds REFERENCE_TRACKING_DEBUG, a define which toggles tracking info for the ref tracking procs, which allows for
oversight on how the proc is working
Allows for direct calls of qdel_and_find_ref_if_fail(), makes it use ref rather then REF(), fixing it breaking
for mobs. (Ditto for the qdel hint which does the same thing)
Moves REAGENTS_TESTING out of the reftracking define block
Makes unit tests define REFERENCE_TRACKING, REFERENCE_TRACKING_DEBUG, and FIND_REF_NO_CHECK_TICK
Adds a unit test that sanity checks the reference finder proc
Adds a new CBT define which is automatically created when building. If this define is absent, the build will fail.
This is what Cyberboss tried to do with USE_BUILD_BAT_INSTEAD_OF_DREAM_MAKER.dm, but couldn't.
The reasoning behind this is CBT is already a requirement to build a fresh project, otherwise the tgui bundle files won't exist. This gives a readable error to go along with that. However, you can currently build once then just use Dream Maker. This is a footgun - not only are we already adding new things to CBT like tgfont which will fail later on, but also it will create weird scenarios when we add tasks to CBT that don't immediately fail if not ran, or otherwise create out of sync builds.
Also replaces rmSync with unlinkSync, which works on older Node versions.
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Brings a heavily improved, rewritten, and optimised fermichem to tg. I saw that tg seemed receptive to it, so I thought I’d do it myself. If you know of fermichem – there’s a lot changed and improved, so looking at other documents regarding it will not be accurate.
Revamps the main chemistry reaction handler to allow for over time reactions instead of instant reactions. This revamp allows for simultaneous reactions, exo/endothermic reactions and pH consuming/producing behaviours. Most of the reactions in game will now inherit an easy one size fits all reaction.
Temperature mechanics
Temperature affects reaction rate
The higher it is, the faster it is, but be careful, as chem reactions will perform special functions when overheated (presently it DOESN’T explode)
Temperature will increase or decrease depending on the exo/endothermic nature of the reaction
pH mechanics
Each reaction requires the pH of a beaker to be within a certain range.
If you are outside of the optimal, you'll incur impurity, which has a negative effect on the resultant chem
pH of a beaker will change during a reaction
Reacting Impure chem effects can vary from chem to chem, but for default will reduce the purity of other reagents in the beaker
Consuming an impure chem will either cause liver or tox damage dependant on how impure it is as well as reducing consumed volume
Purity can (presently) only be seen with a chemical analyser
Impure chems can purposely be made by making the reagent with a low, but not explosive, purity.
A chem made under the PurityMin will convert into the reagent’s failed chem in the beaker.
Optional catalysts
Reactions can use an optional catalyst to influence the reaction - at the more framework exists from tmeprature, reaction rate and pH changes as a result of a catalyst. Catalysts can be set to only work on a specific reagent subtype. It is preferable to those building upon this code that optional catalysts only affect a subsection of reagents.
Presently the only catalyst that uses this is Palladium synthate catalyst - a catalyst that increases the reaction speed of medicines.
Reaction agents
These are reagents that will consume themselves when added to a beaker - even a full one, and apply effects to the total solution. One example being Tempomyocin which will speed up a reaction, or the buffer reagents which change the pH.
Competitive reactions
These reactions will go towards a certain product depending on the conditions of the holder. The example one given is a little tricky and requires a lot of temperature to push it towards one end.
New and charged reactions
(see the wiki for details)
Acidic /basic buffer - These reagents will adjust the pH of a beaker/solution when added to one. If the beaker is empty it will fill it instead.
Tempomyocin - This will instantly speed up any reaction added it is added to, giving it a short burst of speed. Adding this reagent to a reaction will give it a suddent speed boost up to 3x times - with the output purity of the boost modified by the Tempomyocin's purity.5u per 100u will give you 2x, 10 u per 100u will give you 3x. IIt caps at 3x for a single addition, but there is nothing preventing you from adding multiple doses for multiple boosts.
Purit tester - this will fizzle if the solution it is added to has an inverse purity reagent present.
A few other reactions have been tweaked to make sure they work too. An example being meth - see the wikipage linked above.
A note on all reactions
The one size fits all reaction for all chems generally won’t create impure chems – it is very forgiving. The only thing to remember is to avoid heating reactions over 900 or you’ll reduce your yield, and try to keep your pH between 5 -9.
This PR doesn’t have specific example chems included (except for the buffers) – they will be atomised out and they use the mechanics in more depth
A note on plumbing
I reached out to Time Green and we worked together to make sure plumbing was fine. Time Green did some of his own tests too, and surprisingly it doesn't look like much needs to be changed.
* Uses 514's map_cpu var when it's available
* Uses auxtools for the debugger, to supply cross verison compatibility
* Nukes extools reference tracking, reinstates the old ref tracking system
* Adds an atmos debugging tool and excited group visualizer
* rebuild moment
* yarn install -> yarn run build
* Sigh
* Fixed UI, did not test, needs a rebuild.
* Proper flexing
* Adds varied colors, improved ui courtusy of stylemistake:
* Fixes a runtime, updates tgui
* added superconductors, cleaned up some shitcode, removed a clashing color
* Woop
* Speed
* rebuild
* Adds a tick count
* begone auto-update
* color defines
* rebuild moment
* color improvements, fixes updating
* adds another preprocesser define to handle showing max shares in the ui
* test of application system?
* patches up some display issues, allows for smooth flowing from one group to another
* overlay-ified
* client testing
* dmi moment
* plane master
* it fucking works
* size change
* passthrough
* rebuild moment
* adresses review concerns, toggles active turf vis on when testing
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
About The Pull Request
Adds extools-powered reference tracking. Includes a couple procs that retrieve the back and forward references of a datum - Back references let you see what is referencing your object and potentially preventing it from garbage collecting, and forward ones show you what your object in turn references. Also made a cool GUI to inspect and follow these references.
The tracking adds some overhead to all variable sets and list operations. Init time is increased by ~15%. I haven't actually benched it so it might impact the actual game less.
Why It's Good For The Game
no lagging caused by hard dels scanning the entire planet (once coders fix them)
About The Pull Request
The num_to_hex pr #51005 updated the required version without updating the error message sweep sweep sweep
Why It's Good For The Game
This looks like a bug at first glance, let's fix that.
Changelog
🆑
fix: Dear out of date coders, you will now be yelled at to update to the correct version of byond, rather then an unsupported one.
/🆑
* Unicode support Part 1
Makes all calls to ascii2text() and text2ascii() unicode aware as well as all calls in code/__HELPERS/text.dm.
Adds defines for the footext_char() procs to maintain 512 support.
I did some cleanup on the text helpers since a lot of them were really, really bad.
reject_bad_text() and reject_bad_name() have an arg to reject non-ascii chars which defaults to TRUE.
* Give travis a more recent beta
* Ultimate compat
Added the _char procs I was missing
Test the build instead of the version because Lummox is a goddamn moron
* Suggested fixes, removes the last of the dd_ helpers
* Reading the reference is very important!
* Minor code improvements and a comment
* Typo
This was supposed to be 1 or 2 (2 preloads uploaded resources) in the repo and set to 0 in [`server_side_modifications.dm`](https://tgstation13.org/parsed-logs/basil/server_side_modifications.dm) but i messed that up when i switched it from a test merging pr to something mergable.
