## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
## About The Pull Request
Somewhat of a port of
https://github.com/ParadiseSS13/Paradise/pull/26401, albeit re-done from
scratch (with the power of find and replace)
Caller is a protected/reserved var in 516. We use it a lot. It's used in
more places than this, but I'm a perfectionist and can't think of better
names for most of the other uses (mostly mob AI, holocall, and
`InterceptClickOn` related), so I'm just doing pathfinding for now.
## Why It's Good For The Game
Prep for compiling on 516
## Changelog
No user-facing changes - this is merely renaming vars.
## About The Pull Request
Fixes issues with var typing and proc arguments, discovered using
OpenDream's WIP TypeMaker feature (using improvements I haven't PR'd
upstream yet).
## Why It's Good For The Game
Codebase maintenance.
## About The Pull Request
Fixes several errors to spelling, grammar, and punctuation.
## Why It's Good For The Game
## Changelog
🆑
spellcheck: fixed a few typos
/🆑
## About The Pull Request
Implements /datum/pathfind/sssp, which generates /datum/path_map
/datum/path_maps allow us to very efficently generate paths to any turf
they contain from their central point.
We're effectively running the single source shortest paths algorithm.
We expand from the center turf, adding turfs as they're found, and then
processing them in order of addition.
As we go, we remember what turf "found" us first. Reversing this chain
gives us the shortest possible path from the center turf to any turf in
its range (or the inverse).
This isn't all that useful on its own, outside of a few niche cases
(Like if we wanted to get the farthest reachable turf from the center)
but if we could reuse the map more then once, we'd be able to swarm
to/from a point very easily.
Reuse is a bit troublesome, reqiures a timeout system and a way to
compare different movables trying to get paths.
I've implemented it tho. I've refactored CanAStarPass to take a datum,
/datum/can_pass_info. This is built from a movable and a list of access,
and copies all the properties that would impact pathfinding over onto
itself.
There is one case where we don't do this, pathing over openspace
requires checking if we'd fall through the openspace, and the proc for
that takes an atom.
So instead we use the weakref to the owner that we hold onto, and hold
copies of all the values that would impact the check on the datum.
When someone requests a swarmed path their pass info is compared with
the pass info of all other path_maps centered on their target turf. If
it matches and their requested timeout isn't too short, we just reuse
the map.
Timeout is a tricky thing because the longer a map exists the more out
of date it gets.
I've added a few age defines that let you modulate your level of risk
here. We default to only allowing maps that are currently
being generated, or finished generating in our tick.
Hopefully this prevents falling into trouble, but consumers will need to
allow "failed" movements.
As a part of this datumized pass info, I've refactored pathfinding to
use access lists, rather then id cards directly. This also avoids some
dumbass harddel oppertunities, and prevents an idcard from changing mid
path.
Did a few things to the zPass procs, they took args that they did NOT
need, and I thought it'd be better to yeet em.
If you'd all like I could undo the caching/can_pass_info stuff if you'd
all like. I think it's useful generally because it avoids stuff changing
mid pathfind attempt, but if it's too clunky I could nuke it.
Oh also I added optional args to jps that constricts how it handles
diagonals. I've used this to fix bot paths.
## Why It's Good For The Game
Much of this is redundant currently. I'm adding it because it could have
saved hugglebippers, and because I get the feeling it'll be useful for
"grouping" mobs like bees and such.
We're doing more basic mob work currently and I want to provide extra
tools for that work.
https://github.com/tgstation/tgstation/assets/58055496/66aca1f9-c6e7-4173-9c38-c40516d6d853
## Changelog
🆑
add: Adds swarmed pathfinding, trading accuracy for potential
optimization of used correctly
fix: Bots will no longer take diagonal paths, preventing weirdo looking
path visuals
refactor: Refactored bits of pathfinding code, hopefully easier to add
new pathfinding strategies now
/🆑
## About The Pull Request
This PR makes some changes to how JPS is used in movement loops, as it
was causing a variety of issues:
- Fixed some code where JPS would fail because the path is still being
made. Instead, the movement loop will now wait.
- Reduced the subsystem wait for the pathfinder subsystem from 2 seconds
to 0.1 seconds. @LemonInTheDark told me that this is better, I'll update
this with a better explanation once I squeeze it out of him :D
- Allows you to provide an initial path to the movement loop, in case
you pre-calculated one while making a plan.
## Why It's Good For The Game
Makes working with JPS a bit easier when making AI.
---------
Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
Alright. So.
Right now, JPS works like this:
```
code requests path
we enter the actual pathfinding
pathfinding sleeps when it overruns a tick
if it sleeps, it'll then wake up before the mc starts
continue
```
This has annoying side effects. Primarily that we have no real control
over JPS, we just sorta have to eat its cost.
So if there's like 10 different things pathfinding at once, the mc will
have no time to do anything. Hell we might even end up eating into
maptick's time if the jps work is expensive enough (note the cost of
sleeping is not accounted for, and that has overhead)
This has happen before, usually when someone makes a lot of bots, and
it's really annoying.
So then, lets put JPS on a subsystem. That way the MC has control over
it.
But wait, existing code expects to yield and get back a path list, and
that's a sane request.
This is solvable, but requires abusing pass by reference lists, and the
ability to make callbacks into partials (preinsert arguments into them
before they're called, and accept other args later)
Because of this, we can now pass callbacks into pathfinders, allowing
for async use, rather then JUST yielding.
Of note: I've removed the 10 pathfinding datums limit, since
ratelimiting like that is handled nicely by the MC.
I've also removed the 15 second timeout, since mc yielding would trigger
it too often. I'm unsure if this means we don't have exit conditions for
pathfinding, need to talk to ryll. (@Ryll-Ryll what happens if jps just
like, fails to find a path?)
Also of note: I think bots will fire off more then one pathfinding
attempt at a time if their first takes too long to complete. This is
dumb, why do we do this?
Optimizes JPS by more then 40% by removing redundant for(thing in turf)
loops, and avoiding making proc calls if objects are non dense.
This makes things slightly more fragile, but saves a LOT of time. I
think it's worth it, tho talking to mso it might be possible to do
better. Maybe I should do a LINDA system style thing. (I did a linda
system style thing I fixed it)
Optimizes botscanning, fixes bots not seeing things adjacent to them
The list of types could be a cached typecache
We could inline both checkscan and check_bot
check_bot SHOULD NOT BE CALLED ON EVERY OBJECT IN VIEW HOLY SHIT WHY
We don't need to process adjacent and the shuffled view separately, it's
in fact easier to process them in one block
Renames a var
Moves bot's pathing images to above most floor objects, so they're
visible in maint
## Why It's Good For The Game
Speed. Also manuel will stop killing their server by placing 20000
medibots (fucking icebox man every time)
## Changelog
🆑
fix: Bots will now "notice" you if you're standing right next to them
fix: Bot paths will now draw above things like pipes, rather then below
them
refactor: Changed how pathfinding paths get generated
refactor: Made pathfinding and bot searching significantly faster
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
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>
So a month or so ago I wanted to make it so dogs in my dog AI PR could path through doors if they had access, and was told I'd need to improve our pathfinding efficiency if I wanted to use full pathfinding for them. Thus, enter JPS, a pathfinding algorithm that allows for massive timesavings in systems with uniform cost grids like ours. This code is still fairly rough and needs polishing, but it's fully functional and already shows massive savings over traditional A*! I plan for this to replace A* as our default pathing method, but I'll leave the A* code in place in case someone ever needs it for whatever reason, like if a specific case needs variable cost pathing.
Note that this allows for diagonal pathing instead of the cardinal pathing our A* uses right now, and the current version of the code costs the same to move diagonally as it does to move laterally, which may change later. There's also a lot of dummy/test code in right now in general, but you should still be able to test it out for yourself by spawning a bot like a medibot and using your PDA to summon it.
Preliminary Profile Results
A preliminary profile is available here. Using one medibot by itself on Metastation, I generated a list of 500 random blob spawn points around the station, gave the medibot all access, then let each algorithm tackle the list. The old A* algorithm took a total of 86 seconds to complete the list and processed 978065 nodes, while JPS took a total of 46 seconds and processed only 100062 nodes, for a 47% decrease in total time and an almost 90% decrease in nodes processed!
Why It's Good For The Game
Significantly cheaper pathing, which will very much come in handy for the AI datums I'm looking to dig into, what's not to like?
* Photography Update
* Pictures logged in their own /data/picture_logs folder rather than normal logs
* Pictures logged in their own /data/picture_logs folder rather than normal logs
* Photos broke, retrying
* Persistence stuff
* I'm almost done I promise!
* Persistence mostly working, compile, etc etc
* Persistence mostly working, compile, etc etc
* Remove something really not needed from the PR
* Prevents duplication
* default to off
* removes check tick
* increase slots in albums to 21
* Allows for singular loading
* Update camera_image_capturing.dm
* Addresses review
* Anturk
* Update camera.dm
* Update misc.dm
* Update datum.dm
* Update camera.dm
Watermelon914