[DONE] Help test new FOV calculation executable (playable long view distances)

[Meridian]

@stiansel:
Yankes cherry-picked your changes to OXCE branch: https://github.com/Yankes/OpenXcom/commits/OpenXcomExtended
He also changed/fixed a few things:
1. https://github.com/Yankes/OpenXcom/commit/ad01723a2ccd611c0ef2447a095defe9f2a3027c
2. https://github.com/Yankes/OpenXcom/commit/986e534286c42a957615fbb0f8a8d703045c96ff

Should I do the same changes too?

[Stian]

Yeah, those changes look good to me. Though there's one thing that needs to be checked first. The FOV calculation needs the supplied radius to be large enough to fully cover the event, so it may need a +1 to the radius.

Edit: I wouldn't add the 3D distance fix as it will produce different results depending on whether a position based update or a unit based update takes place. That addition fix in the same commit is very much recommended though.

[Stian]

I updated the repository for the item stacker. I changed it a bit to better facilitate filtering by category. Namely I've changed it to stack each item in advance in its stackable subtypes, rather than bunch all items of the same type, then later figure out the stackable subtypes. This makes filtering out a specific subtype easier later on. (actual filtering not included as it's probably better to add that to a different branch?)

Also noticed a getItem function which (worst case) scanned the entire item inventory for each tested location of the stacker. With the other changes I've done to the stacker it tries to find room for stacks rather than individual items. So with the stacker no longer needing to know which item is present, just that something is there, I changed it to a small occupancy lookup table instead. The new version is about 10 times faster on the previous test save you gave me (and scales better).

[Meridian]

Edit: I wouldn't add the 3D distance fix as it will produce different results depending on whether a position based update or a unit based update takes place. That addition fix in the same commit is very much recommended though.

OK, I'll take the addition fix and change the distance calculation back to 2D.

[Stian]

I updated the FOV repository with a new bug fix. While investigating why Yankes hadn't noticed a difference with 3D distance set for the position based FOV updates I found a few cases where I had been inconsistent in my use of 2D and 3D distance. After this fix visibility near max range should be consistent with the base game behaviour again.

[Meridian]

@Stian:
Could you have a look at this? Adding the quick filter messed it up a little bit... but can't reproduce reliably. Maybe you'll spot an issue right away...

https://openxcom.org/forum/index.php/topic,4520.msg65983.html#msg65983

[Stian]

Does the issue also occur if you change the search term function to use arrangeGround(false)? (I don't have access to a compiler right now and probably can't take a much closer look for a couple of days.)

Edit: The extra spaces may be caused by incorrect values in the start index cache. Try disabling the startCache stuff by simply setting x=0. With the other changes done the performance loss is fairly small. If this turns out to be the culprit I'll fix it when I get back to a more useful computer.

[Dioxine]

I certainly prefer this bug over performance loss. It happens very rarely and basically only if you click the page change button like crazy.

[Stian]

Found and corrected the inconsistent inventory spacing bug as reported by Arthanor and Meridian. It was caused by a read outside of the assigned cache, hence the random nature of the error. This could also cause a CTD on opening of the inventory, so if anyone was experiencing that, it should be fixed too.

https://github.com/stiansel/OpenXcom/commit/6c6b4f17acb121ca4869121858ff538c49851d50