mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-29 02:51:41 +00:00
460ab7adf5
* JPS Optimization (Light Botcode) (#70623) ## 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> * JPS Optimization (Light Botcode) Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
6 lines
310 B
Plaintext
6 lines
310 B
Plaintext
// Define set that decides how an atom will be scanned for astar things
|
|
/// If set, we make the assumption that CanAStarPass() will NEVER return FALSE unless density is true
|
|
#define CANASTARPASS_DENSITY 0
|
|
/// If this is set, we bypass density checks and always call the proc
|
|
#define CANASTARPASS_ALWAYS_PROC 1
|