Refine mission target search profiles by specifying Z level.

[PatrikLundell]

Is your feature request related to a problem? Please describe.

I'm currently struggling with the Rubik warehouse mission, where I've got a situation where it consistently fails after two hours or so. Looking at the code, I see that it searches through all Z levels unless those are specified, and I've modified this particular mission's JSON to specify the Z level as 0 (which is the only level where a match can be found). This cuts down the time to reach the failure report by at least 15 minutes.

Solution you would like.

Update all mission target location search criteria to specify the only Z level the target can be found at to cut away searches for it on levels where it cannot exist.

Describe alternatives you have considered.

No response

Additional context

This doesn't do anything to solve my problem, but it should help speed up searches (in particular ones ultimately failing), which is the aim of this request.

Even if your mission is in a mod where you do have stuff on multiple Z levels (ravines and whatnot), you should still be able to constrain the Z levels to the ones where your target can be found (e.g. not in the sky, or not deep underground).

As an aside, I'm trying to deal with the missing warehouse mission and have a situation where I can reliably ask a particular logger for the location of the target and have it fail (after 105 minutes or less (I've been doing other things in the foreground, and so haven't kept exact tab on when they finally fail), rather than about 120). Unless my trace output is bugged, the target is marked as having been placed as a unique location prior to the search, but isn't within a 540 OMT radius (and I think the generation of the location is still attempted, even though it will fail, because there is no check for if globally uniques have been placed). Unfortunately, the globally unique "list" only contains the identities of placed uniques, but not their locations.

It can also be noted that the search code to get the nearest instance of a location when searching for existing locations only goes through a call chain for each location within the search radius in range order, only to hit a "this OM hasn't been generated" negative result for each position within range in such OMs (and each Z level, to boot). I wonder if it wouldn't be faster to find the non generated OMs within range and remove their locations from the list of search locations before performing the tests for each location?

[RenechCDDA]

Since almost everything is on z=0 perhaps it should default to that, and exceptions must be specified instead?

Otherwise it sounds like a fine idea.

[PatrikLundell]

Changing the default is definitely a possibility. The downside to that is that it means all mission target definitions will have to be reviewed to verify they're still going to work (in particular mods), whereas updating the missions themselves can be done one at a time.

Beside the OP issue: Adding a check whether a special is included into the globally unique list before trying to create it cuts down time to failure to about 55 minutes when it's present (as only the search phase is performed, and the doomed to failure creation phase is skipped). Edit: And this problem resulted in #81219.

[John-Candlebury]

Seems reasonable to change the default to 0

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.