Sable compat

[gjorgdy]

Contributor License Agreement

Full CLA
Contributors: Please "X" in the following box to acknowledge our CLA

• I have read and agree to the CLA for Iron's Spells and Spellbooks which allows me to retain my ownership in the code submitted while granting the repository owner legal rights to use my contribution.

I added compatibility/fixes for Sable sublevels, specifically for Portal Frames and the Touch Dig spell.

For fixing the crash on sublevel teleport I've created a PR on Sable's repo.

[PMW9905]

Literally just came here to open a bug for the same issue only to find this PR. Thanks for your work! LMK if you need any assistance w/ the fix.

[iron431]

I am not keen on implementing the sable companion dependency. sable fundamentally rewrites vanilla assumptions (world structure, entity behavior, coordinate space) and does so in a way that is openly acknowledged to be intrusive and compatibility-breaking. I have no desire to maintain an additional dependency because of this, and rewrite every spell that uses raycast features.

Unfortunately, I have yet to see a sable maintainer acknowledge any of the open issues regarding raycasting or teleporting.

[Modog500000]

Hello, I am a sable maintainer! I wanted to explain for @iron431 what is actually happening. Sable Companion is a mod made to be JIJ that has a VERY small file size, and includes none of the features of sable itself.
Sable does not require you to rewrite your raycasts, it just requires you to transform your positions in and out of the sublevel when needed.
Furthermore, it appears that this PR simply uses sable companion to transform these positions. I can't speak on if it works or not, as I havn't tested it, but when its done it should hopefully be relatively uninvasive.
If you have any questions, just let me know!

[iron431]

Thanks for the update @Modog500000

Sable does not require you to rewrite your raycasts, it just requires you to transform your positions in and out of the sublevel when needed.

to me, this precisely is rewriting my raycasts. every single one must be prefixed by a new, alien operation -- wired through the sable companion. even if it is "relatively uninvasive", i prefer not to have the burden of maintaining a third party api in my core logic flow, especially not one that has no intrinsic value to my mod.

it seems the raycasting issues largely stem from abnormally large AABB's being computed, thus hanging the game. i do question if sable can intercept these (it seems to already be able to detect log their presence) and simply inject a return of the union of two AABB lookups: one with the corrected world coordinates, and one with the corrected sublevel coordinates. I imagine sable being able to do this automatically would provide compatibility with every mod that uses vanilla-style entity raycasting.

[Modog500000]

@iron431
I feel that there is some confusion here, as the behavior you are explaining is intentional. It is a very simple operation to find and transform a position that is in a sublevel, but it is much more complex to find one that isnt.
Additionally this usually maximizes compat in most cases, however there are some, like yours, where this doesnt work as well.
Sable companion is specifically made to be an api, and we will never remove or otherwise change methods tgat are used, so you don't need to worry about "maintaining" compat with sable.

[iron431]

@Modog500000
I understand how the sable companion works, and I understand that it is intentional.

My point is the burden of cleaning up the fallout of your mod should not fall on me.

This is especially true when it seems sable should be able to intercept these AABB checks. If an AABB has one extent in the plotyard and one outside, it already logs it as such. Sable itself should intercept these lookups, and return the union of a duplicated lookup: one wholly in the plotyard, and one wholly in world space.

While i am not familiar with the internals of sable, to my rudimentary understanding, this would alleviate all entity raycasting issues for all mods. Maybe I am wrong, but this feels like a much better solution than "all mod authors must now implement my helper"

[iron431]

After more thinking, this would not single-handedly work; you would also likely need to adapt AABB#clip to also duplicate and transform the start and end vectors if exactly one extent is in a plotyard.