ZDoom

PR link
Exports P_CheckFor3DFloorHit and P_CheckFor3DCeilingHit to ZScript, and adds a function for triggering monster use/push specials to circumvent not being able to access the spechit array when writing custom monster AI.

What are you doing here? This is all extracting code from the innermost logic of the engine.

Graf Zahl wrote:What are you doing here? This is all extracting code from the innermost logic of the engine.

I need P_CheckFor3DFloorHit in my AI to handle drop-offs, and thought I might as well export P_CheckFor3DCeilingHit.
As for CheckMonsterUseSpecials, I need such a function in my monsters' custom AI and movement code so they can reliably open doors and trigger lifts. Otherwise, all this code I wrote is literally useless.

Basically, I'm using custom AI to make monsters smarter, and so I can have a much better invisibility powerup, along with using custom movement code so monsters navigate better instead of getting stuck bouncing between walls all the time. This involves making monsters move in way more directions than 8, which means I can't use TryWalk or MonsterMove - and without those or CheckMonsterUseSpecials, monsters are quite useless, as they can't activate doors and lifts.
(Basically, CheckMonsterUseSpecials exists for the same reason I wanted to export the spechit array.)

phantombeta wrote:movement code so they can reliably open doors and trigger lifts

A_wander with no random turns flag no longer work for this? I remember I use this in decorate for LCA addon.

It'll mess with my own movement code, so no, it wouldn't work.

Edit: As a note, it doesn't make much sense not to merge the exports for P_CheckFor3DFloorHit and P_CheckFor3DCeilingHit IMO - P_CheckFakeFloorTriggers was exported to ZScript, and that's pretty much the same thing, just for fake floors.

I could definitely use this myself.

Ok then. Looking through this PR I'd still like to request one change: To keep the code clean and the exports out of the way I rewrote larger parts so that the exports do not contain any real work code and are relocated to vmthunks.cpp/vmthunks_actor.cpp.

This should follow the same rules and also define the called functions as direct native variants. Just be careful with bool returns, they get rejected by the macro and need to be changed to int.

Alright, gonna do that right now.
By the way, since that isn't really obvious, could you put that somewhere so other people can see it? I don't mind doing a bit more work just to make sure my PRs get in, but I imagine other people would like to know this.

Sure, but only after the release. Now it makes no real sense.

Okay, PR updated. I force-pushed the changes so there's still only two commits.

Perhaps this could be moved to Code Submissions since it has a PR now?