## About The Pull Request
Logs the coordinates of the turf causing the test failure
## Why It's Good For The Game
Knowing where the turf is can be a clue to the root cause of the failure
## Changelog
N/A
## About The Pull Request
One of the development hell cycles with mapping is how long it takes to
fix quality or run issues with maps.
By adding a prefix called "maptest_" to some of the unit tests it allows
mappers to only target some tests instead of the usual 350+ tests to run
each time or trying to trigger them individually and faffing.
This does not rename the unit test files themselves to preserve history
but just the "/datum/unit_test/" in each file.
This does not break the current CI or obstruct other tests - A few other
map files that call these tests specifically have been edited to point
at the new datum name.
This assumes you are using the TG testing extension to do this.
| All Tests | maptest_ |
|--------|--------|
| <img width="426" height="106" alt="image"
src="https://github.com/user-attachments/assets/d1d6f81e-16bd-473a-88da-e8b56f8bd3d0"
/> | <img width="434" height="96" alt="image"
src="https://github.com/user-attachments/assets/ea1c47fe-a6ce-40c6-b2cb-65b9c8e94a29"
/> |
| <img width="360" height="886" alt="image"
src="https://github.com/user-attachments/assets/65bcd774-79ad-432e-8211-c67fb9d3e443"
/> | <img width="370" height="833" alt="Screenshot 2025-10-01 204609"
src="https://github.com/user-attachments/assets/ad360796-5698-42fd-bd2e-51de1a02ab87"
/> |
## Why It's Good For The Game
- Should make it easier for mappers to test locally, saving CI/Github
resource for TG
- Mappers can now test their work 56% faster
## Changelog
🆑
code: Mappers can now run just mapping unit tests - Should be 56% faster
- Should have no player impact
/🆑
Co-authored-by: loganuk <falseemail@aol.com>
## About The Pull Request
Situation: areas have a list of all turfs in their area.
Problem: `/area/space` is an area and has a 6 to 7 digit count of turfs
that has to be traversed for every turf we need to remove from it. This
can take multiple byond ticks just to preform this action for a single
space rune
Solution: split the list by zlevel, and only search the right zlevel
list when removing turfs from areas.
replaces `area.get_contained_turfs()` with a few new procs:
* `get_highest_zlevel()` - returns the highest zlevel the area contains
turfs in. useful for use with `get_turfs_by_zlevel`
* `get_turfs_by_zlevel(zlevel)` - returns a list of turfs in the area in
a given zlevel. Useful for code that only cares about a specific zlevel
or changes behavior based on zlevel like lighting init.
* `get_turfs_from_all_zlevels()` - the replacement for
`get_contained_turfs()`, renamed as such so anybody copying/cargo
culting code gets a hint that a zlevel specific version might exist.
Still used in for loops that type checked so byond would do that all at
once
* `get_zlevel_turf_lists()` - returns the area's zlevel lists of lists
but only for non-empty zlevels. very useful for for loops.
The area contents unit test has been rewritten to ensure any improper
data triggers failures or runtimes by not having it use the helpers
above (some of which ensure a list is always returned) and access the
lists directly.
## About The Pull Request
Ok so like, I was using an assoc list in the unit test to map turfs to
their tracked area parent.
This was foolish because unless the test fails we will be doing this for
EVERY TURF IN THE GAME.
Assoc lists are red black tress, so insert time, more then just the list
expansion cost, also just scales with the amount of keys, since we need
to binary search them all to ensure we don't already exist.
This is really slow, and was costing us like actually 300 seconds or
something.
I've switched to storing this information in just the turf. It should
bring this down to like 6 seconds instead of 6 minutes.
Remember, assoc lists are dumb for high scales kids
## About The Pull Request
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
