## About The Pull Request
Resprites:
Tesla Cannon
Tesla Cannon crafting kit
### New SFX / VFX
The tesla cannon now uses a new type of beam effect that randomly picks
sprite variants for each segment instead of a tracer.
This makes the arc look more dynamic and less distorted.
Autofire guns can now choose to use a looping sound datum when firing.
#### Balance changes
The tesla cannon must now have its stock unfolded before firing, this
takes 1.5 seconds and makes the gun bulky.
It is still normal sized when folded, and folding it is instant.
### Bug fixes
Fixed a bug where looping_sound.stop() would fail to stop sounds.
The tesla cannon is an incredibly powerfu
## Why It's Good For The Game
### My reasons for respriting
The old sprite was not bad, by all means but I had a few gripes with it.
* The old sprite does not incorporate the flux anomaly yellow colour.
* The old sprite looks a bit much like a real, professionally produced
sci-fi weapon,
* The old sprite looks pretty small for such a ultra high dps full auto
weapon.
* The old inhand is quite indistinct for something that can game end you
in like one second.
### My design
I think that anomaly items should be very mad science coded and, since
anomaly science is by definition a poorly studied field, they should
look more like prototypes created by a scientist rather than something
professionally made in a factory.
## Changelog
🆑
image: The tesla cannon has new sprites.
image: The tesla parts kit has new sprites.
image: The tesla cannon has a new shocking beam effect when firing.
sound: The tesla cannon has new sounds.
balance: The tesla cannon must now be unfolded to fire.
fix: looping sounds now stop playing sounds when commaned to do so.
/🆑
## About The Pull Request
adds the Cain & Abel to the lootpool of the colossus!
these are a set of angelic twinblades bound together by some chains. The
long chains allow u to attack mobs from a distance (2 tiles max) and at
very FAST speed, and come with a few new mechanics:
-Attacking a mob with the cain and abel grants you a special whisp that
follows your character. these whisps empower ur next melee attacks u can
collect a maximum of up to 6 whisps, (their bonuses stack), after which
they reset. If u get hit by a mob once, you'll lose ur whisps (and ur
melee bonus), so ull have to regain them by rebuilding up ur combo. u
can also choose to sacrifice ur whisps by firing them at mobs (by right
clicking them) for some hefty damage (this again means u'll lose them)
https://github.com/user-attachments/assets/0a1738db-9fa4-4226-ac80-334f5e97cfa5
-u can also choose to hurl one of ur daggers at enemies, there's 2 throw
modes u can toggle between by pressing Z while holding ur weapon.
1- On launch mode, u can throw one of ur daggers at a tile, afterwhich
the chains will rapidly pull u towards it, making for some cool getaways
in tense situations. this puts throw mode on a 7 second cooldown
2- On crystal mode, u can hurl a dagger at an enemy or at a tile. Spiked
crystals will errupt on nearby floors, dealing some damage to nearby
mobs and stunning them for 2 seconds (bosses dont get stunned tho). puts
throw mode on a 15 second cooldown
https://github.com/user-attachments/assets/665b9cf4-c5a1-4263-a36b-86e3f35d0ae5
-Lastly is the swing ability. This will swing ur daggers around u,
dealing AOE damage to nearby mobs, and makes u block all melee attacks,
tentacle attacks, and deflect incoming projectile attacks (could for
example be used to deflect the colossus' shotgun blast back to it). ull
only block attacks while the animation is active, which lasts a good
1.75 seconds, and is at a 20 second cooldown.
https://github.com/user-attachments/assets/073e5324-af5b-45ab-912e-5bcaa13fc728
Here's a short clip of me using them to fight a colossus and a bubblegum
https://www.youtube.com/watch?v=kp5Hu16dHPQ&ab_channel=Kobsa
## Why It's Good For The Game
adds a new fun weapon with a few deep mechanics to the game. also makes
taking down colossi alot more rewarding.
## Changelog
🆑
add: adds the cain and abel to the colossus lootpool!
/🆑
# Conflicts:
# icons/mob/inhands/equipment/kitchen_lefthand.dmi
## About The Pull Request
Previous attempt - https://github.com/tgstation/tgstation/pull/87227
`/atom/proc/singularity_pull(obj/singularity/singularity, current_size)`
has first arg typed, but other procs were just referencing it as a
un-typed variable.
Since args are not standartized AND
`atom/proc/singularity_pull(obj/singularity/singularity, current_size)`
is out-dated, since it can be called by things that has
`/datum/component/singularity` - not just by
`obj/singularity/singularity` - This PR just adds args to every
`proc/singularity_pull()` as follows:
`proc/singularity_pull(atom/singularity, current_size)`
## Why It's Good For The Game
Standartization
## Changelog
No changelog needed
## About The Pull Request
This PR significantly enhances how zero-g movement works. Its no longer
locked to one of 8 directions, everything now has inertia and is
affected by weight. This means that throwing a piece of wire will no
longer completely reverse your movement direction, and that being thrown
out of mass driver no longer will slow you down to a halt at some point.
This leads to following gameplay changes:
* Guns now accelerate you. Ballistics have higher acceleration than
lasers, and higher calibers have higher acceleration than smaller ones.
This means that firing full-auto weapons in zero-g will make you drift
and accelerate significantly. While this can be a hilarious way to
travel in space, it makes using them trickier.
* Impacting a wall or an object while moving at high speeds will cause
you to violently crash into it as if you were thrown. Careful when
exploring!
* Jetpacks now have inertia. Changes introduced in #84712 have been
mostly reverted, although speed buff has been reduced to 0.3 instead of
0.5 (although this is compensated by new movement mechanics, so overall
speed should be roughly equal). All MODsuit jetpacks now possess the
speed boost. Advanced MODsuit jets (which has also been added back) and
captain's jetpack instead have higher acceleration and stabilization
power, providing much more precise control over your movement.
* Firing guns while moving on a jetpack will partially negate your
pack's acceleration, slowing you down. Non-advanced jetpacks'
stabilization is not enough to compensate for heavy caliber weaponry as
sniper rifles, shotguns or rocket launchers.
* You no longer instantly decelerate upon sliding along a wall. Instead,
it may take a few tiles if you are moving at extreme speeds. Passing
over lattices still allows you to grab onto them!
As space movement is angle-based instead of dir-based now, its much more
smooth than before due to using new movement logic.
Example of jetpack stabilization in action:
https://github.com/tgstation/tgstation/assets/44720187/6761a4fd-b7de-4523-97ea-38144b8aab41
And, of course, you can do this now.
**This pull request requires extensive gameplay testing before
merging**, as a large amount of numbers have been picked arbitrarily in
an attempt to keep consistency with previous behavior (guns and
normal-sized items applying 1 drift force, which is equal to what
everything applied before this PR). Jetpacks and impacts may also
require adjustments as to not be frustrating to use.
Closes#85165
## Why It's Good For The Game
Zero-G refactor - currently our zero-g movement is rather ugly and can
be uncomfortable to work with. A piece of cable being able to accelerate
you the same as a duffelbag full of items when thrown makes no sense,
and so does instantly changing directions. Inertia-based version is
smoother and more intuitive. This also makes being thrown into space
more of a hazard (possibly opening the door for explosive
decompressions?)
Jetpack inertia and gun changes - this is mostly a consequence of
inertia-based movement. However, zero-g combat being preferred during
modes like warops was an issue due to it negatively affecting everyone
without jetpacks which are in limited supply onboard. This reverts the
mobility changes which severely impacted space exploration, while making
zero-g combat more dangerous and having it require more skill to be a
viable option.
## What's left
- [x] Refactor moth wings to use jetpack code
- [x] Refactor functional wings to use jetpack code
- [x] Locate and fix a recursion runtime that sometimes occurs upon
splattering against a wall
- [x] Add craftable tethers and modify engineering MOD tethers to use
the same system
## Changelog
🆑
add: You can now craft tether anchors, which can be secured with a
wrench and attached to with right click. They won't let you drift into
space and you can adjust tether length/cut it via lmb/rmb/ctrl click on
the wire.
add: MOD tethers now remotely place and connect to tether anchors
instead of throwing you at where they landed.
balance: MOD tethers can now be used in gravity
balance: Jetpacks are now inertia-based.
balance: Guns can accelerate you significantly in zero-g.
balance: All jetpacks now give you equal speed buff, however advanced
MOD ion jets and captain's jetpack have higher acceleration/deceleration
values.
refactor: Refactored zero-g movement to be inertia-based and utilize
angles instead of directions.
/🆑
## About The Pull Request
See the title. This is an issue I've noticed when the wallening arrived,
however it isn't strictly related to it. The wallening just pretty much
brought it up thanks to the vast usage of pixel w and z
## Why It's Good For The Game
Beams should be aligned with the pixel offsets of the two ends.
## Changelog
🆑
fix: beams now take into account the pixel offsets of both origin and
target more accurately..
/🆑
## About The Pull Request
adds a new weapon to mining, the grapple gun. this weapon is a new fun
way to traverse lavaland, it lets u grapple onto things and ziplines u
towards them.
https://github.com/tgstation/tgstation/assets/138636438/5e935776-1482-4994-bcc7-e1ca7fcf33dc
while its less practical than things like the spinning mining modsuit
module, or xenobio wings, its still very fun to use.
u can also use this as a weapon against mobs! (like batman)
the zipline will launch u towards the mob, doing some damage to them and
launching them back
https://github.com/tgstation/tgstation/assets/138636438/3bf77fe5-4ed1-4153-8673-a0786ecee98f
## Why It's Good For The Game
adds a new fun harmless way to travel through mining biomes
## Changelog
🆑
add: miners can now purchase grapple guns
/🆑
## About The Pull Request
FOV as it is currently implemented is incompatible* with wallening.
I'm doin wallening, so we gotta redo things here.
The issue is the masking of mobs. Wallening relies on sidemap (layering
based off physical position), which only works on things on the same
plane (because planes are basically sheets we render down onto)
So rather then masking mobs, let's reuse the masking idea from old fov,
and use it to cut out a bit of the game render plane, and
blur/over-saturate the bit that's masked out.
My hope is this makes things visible in light, but not as much in
darkness, alongside making more vivid shit more easily seen (just like
real life)
Here's some videos, what follows after is the commits I care about
(since I had to rip a bunch of planes to nothing, so the files changed
tab might be a bit of a mess)
Oh also I had to remove the darkness pref since the darkness is doing a
lot of the heavy lifting now. I'm sorry.
Edit:
NEW FOV SPRITES! Thanks dongle your aviator glasses will guide us to a
better future.
https://github.com/tgstation/tgstation/assets/58055496/afa9eeb8-8b7b-4364-b0c0-7ac8070b5609https://github.com/tgstation/tgstation/assets/58055496/0eff040c-8bf1-47e4-a4f3-dac56fb2ccc8
## Commits I Care About
[Implements something like fov, but without the planes as layers
hell](https://github.com/tgstation/tgstation/commit/a604c7b1c8d74cd27af4d806d85892c1f7e35ba8)
Rather then masking out mobs standing behind us, we use a combo color
matrix and blur filter to make the stuff covered by fov harder to see.
We achive this by splitting the game plane into two, masking both by fov
(one normally and one inversely), and then applying effects to one of
the two.
I want to make the fov fullscreens more gradient, but as an effect this
is a good start
[Removes WALL_PLANE_UPPER by adding a WALL_PLANE overlay to material
walls (init cost comes
here)](https://github.com/tgstation/tgstation/commit/25489337392f708cb337fbf05a2329eacdfc5346)
@Mothblocks see this. comment in commit explains further but uh, we need
to draw material walls to the light mask plane so things actually can be
seen on them, but we can't do that and also have them be big, so they
get an overlay. Sorry, slight init time bump, about 0.5 seconds. I can
kill it with wallening.
[Moves SEETHROUGH_PLANE above
ABOVE_GAME_PLANE](https://github.com/tgstation/tgstation/commit/beec4c00e01d34a04fba7c2bb98a9b70d27ead82)
I don't think it actually wants to draw here
@Time-Green I think this was you so pinging for opinion
[Resprites FOV masks to be clean (and more
consistent)](https://github.com/tgstation/tgstation/pull/80062/commits/f02ad13696b3b17658af612c62848b48609d785d)
[f02ad13](https://github.com/tgstation/tgstation/pull/80062/commits/f02ad13696b3b17658af612c62848b48609d785d)
This is 100% donglesplonge's work, he's spent a week or so going back
and forth with me sharpening these to a mirror shine, real chill
## Why It's Good For The Game
Walls are closing in
## Changelog
🆑 LemonInTheDark, Donglesplonge
image: Redoes fov "mask" sprites. They're clean, have a very pleasant
dithering effect, and look real fuckin good!
del: Changed FOV, it no longer hides mobs, instead it blurs the hidden
area, and makes it a bit darker/oversaturated
/🆑
###### * It's technically possible if we start using render targets to
create 2 sets of sources but that's insane and we aren't doing it
## About The Pull Request
That of beams being layered below mobs has been a minor issue ever since
that mess that is FoV was implemented (with the exception of chain
lighting of the 'lighting' holoparasite type). I'm changing the plane of
beams to GAME_PLANE_UPPER_FOV_HIDDEN along a couple other things.
## Why It's Good For The Game
Re-read the above section, also fishing lines shouldn't generally glow
in the dark like very thin lightsabers, and them being layered below
mobs has always been a peeve to me.
## Changelog
🆑
fix: Fixed beams rendering below mobs by default.
fix: The fishing line beam is no longer emissive (it doesn't glow in the
dark).
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
kinesis now waits for its first inputs to be given before firing, it
should no longer pull the item to the center of the screen
the kinesis overlay now is emissive
beam emissivity now works (emissive appearances no longer reset
transform)
beams now have a variable whether or not they should be emissive,
because of stuff like vines or chains from the meat hook
fixes https://github.com/tgstation/tgstation/issues/71640
## Why It's Good For The Game
neat visual stuff
## Changelog
🆑
fix: fixes beam glow in the dark effects
fix: kinesis now doesnt pull the item to the centre of the screen when
first used
fix: physical beams (like vines or meat hook chain) no longer glow in
the dark
/🆑
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>
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
Adds fishing and fishing minigame.
You use fishing rod to fish.
Equipping specific bait/hook/reels will affect your success chances.
You can fish out fish,items and other things.
Fishing Equipment
Fishing rods have three slots: Bait, Reel and Hook.
Any food can be used as bait but dedicated bait makes fishing easier.
You can buy hook and line sets
New bait types:
Worms : Buy can of them at cargo (alternative acquirement method pending)
Doughballs : Use knife on flat piece of dough to get five of them.
Fishing rod types:
Basic : Print these at the lathe, nothing fancy here.
Tech: Experimental tech. Provides infinite bait
Fishing rods can also hook and reel normal items.
Equipment screen and reeling video
Fishing spots
Keep in mind this PR is meant to add the basic systems and i intend to fill these with more fish in future PR's so wait with suggestions until then.
Lavaland lava (no fish here right now, just other stuff), requires reinforced line to fish in.
Maintenance moisture traps.
Beach away mission water.
Fishing portal available for purchase from cargo - This is stopgap until we fill more spots.
Difficulty depends on fishing spot, fish type, and the fish traits and rod setup combinations.
All fish types can have specific traits, most common ones being favourite and disliked bait types/categories.
Other
Fishing catalog now lists fishing related info
New admin debug verb, fishing calculator that show probabilities with different setups so it's easier to balance this.
Fish now have average weight and size. Make sure to boast if you catch a big one.
Adds tgui mouse passthrough
Screens
Sprites:
Fishing portal sprite by @ArcaneMusic
Other sprites by @Mey-Ha-Zah
Bad ones by me. (Could still use better fishing minigame backgrounds)
Sounds:
https://freesound.org/people/soundscalpel.com/sounds/110393/https://freesound.org/people/soundslikewillem/sounds/343748/
bring code up to latest standards, move many procs to named files inside _HELPERS
no idea where to put some of these procs, help is appreciated
made more files to contain some unique code, deleted unsorted.dm, we can rest now
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
Huge removal of dead vars, bad timers, and other sloppy jitteriness from beams. They go from checking movement to waiting for a signal.
VARIABLE KILL LIST:
sleep_time: signals baby
finished: signals BAYBEEE
target_oldloc: not only not typecasted as a turf or named as a turf, it was unused. when are we going to use this? the beam starts from the origin!
origin_oldloc: bad name, not typecasted. renamed to originturf
static_beam: how are you an unused variable and still get replaced by signals like really
timing_id: signallllss bbbaaaabbyy
recalculating: you get the drill by now signals baby
base_icon: unused, seemingly replaced by visuals I think
* relic file
* Revert "Merge branch 'master' of https://github.com/tralezab/tgstation"
This reverts commit 826916d87b421dbb0ebcfce7fad96e456b6d3674, reversing
changes made to a0f476d874.
* a couple runtimes to kill, otherwise ready
* beam animation
* removes bad idea lol
* more panache
* fixes spelling
* nobomb mode
* nobomb granter
* sanity for levelling, plasma cap is now a var
* DO YOU LIKE... MY CAR...
* reviews handled, again
* more reviews! 🔪
* Revert "all this wrapping and it's not even christmas (#33035)"
This reverts commit faaf151580.
* Revert "fuck me for forgetting to graph this one"
This reverts commit 45d7acea2f.
* Revert "defines math"
This reverts commit 2817a1737b.
* Makes qdeleted and qdestroying macros
* Makes QDELETED and QDESTROYING uppercase
* Swap qdel checks istype's for != null's
* Fix it
* How was this missed?
* Fixes some bad addtimers
* Adds INVOKE
* Warning for addtimer
* Working syntax
* Another bad call
* Fixes the addtimer warning
* Add suppress_zero_warning to addtimer
Useful for addtimer that uses vars
* Add INVOKE_AGAIN for when the var is already defined
* Replace addtimer(...,0) with INVOKE((...))
* Much more sensible syntax
* Less overhead, less copypaste
* Rename INVOKE_ASYNC
* Use a macro
* Allman style
* Wait, why make it a datum in the first place?
* Revert the rename
* Rename again, keep line endings
* typo
* More typos
* Untouches Addtimer
* Update callbacks.dm
* Update timer.dm
* Revert allman style
* Revert "Revert allman style"
This reverts commit 47361da15bd04eca138be5f13acdc9dd5ba89331.
* Trying to match that whitespace diff
* Why is this missing?
* I'm not fucking dealing with this!
Alexis