Crashes on Windows 10

[stevengreens10]

Might need an updated signature?

No error message displays, it just crashes the server instantly upon a player/bot taking damage.

[nosoop]

Just checked; it's the same unique signature.

It's possible it might be a detour-related snafu (dynooks historically had issues with returning floats in general and not restoring argument pointers in post-hooks on Windows, so it's not impossible).

I'm almost sure Karma Charger demo'd this functionality for some of his plugins and he runs on Windows; I'd lean towards a dependent plugin causing this.

[Umbrozium]

i have the exact same problem. upon taking damage from any source, the server crashes immediately. im not sure what you mean by a "dependent plugin" since any plugin that is dependent on tf_ontakedamage that i used is all the attribute plugins you provided with the custom attribute framework you developed.

[Umbrozium]

fyi im using the custom attribute framework and all the custom attributes on my own dedicated server and i have pretty much everything i need for it to work, but it does what's said above instead. when checking the crashlogs i pretty much see a lot of errors regarding lots of dhookenabledetour and dhookentity. i think some of the new tf2 updates might've broken something, or im doing something wrong? if so, how do i fix this?

[nosoop]

It'd be one of the attribute plugins in that case, as those are the ones that would be hooking on this library. As a sanity checking measure, can you disable all attribute plugins (preferably just the ones that have use tf_ontakedamage per the sources) and verify that the server doesn't crash? If it doesn't, doing a bisect (loading / unloading plugins until it does) should narrow down which plugin is causing the issue.

The DHook-related errors would be under the attribute project. Windows in general is poorly supported due to fragile signatures (and needing bytesigs in general, see nosoop/SM-TFCustomAttributeStarterPack#10).

[Umbrozium]

so, would these attribute plugins work better on a Linux server?

[nosoop]

That is the state of things, yes.

This appears to be a bug in 1.1.0 (in the CTFGameRules::ApplyOnDamageModifyRules() detour), as the previous pre-release build doesn't have the same issue.

[Umbrozium]

okay so I tested all the stuff on a Linux server. firstly I tried to damage myself of course but no crash so that's good. I wondered what could be the problem with wearables not working, I think I had the latest wearables and randomizer gamedata, but first equipping the Air Lock made the secondary slot completely remove itself, and then I tried to get other gamedata versions and now equipping the shield just forces "suicide" while the camera stays in the point of view I was standing before equipping the shield. while looking from third person, it looks like my ragdoll just falls down while my cosmetics fly as if I'm still there. Oh yes and I can't move at all.

[nosoop]

@Umbrozium Things that don't involve the damage hook are outside the scope of this issue / project; that's either within the starter pack, the Custom Weapons plugin set, or your particular configuration (please ensure the gamedata is up to date and correct).

@stevengreens10 I've pushed out a pre-release build for Windows which should patch up the DHooks quirk which doesn't preserve the stack arguments for use in the post-hook (ref: peace-maker/DHooks2#2). I always forget that's a thing. Please test the pre-release and let me know if that resolves the crashing issues on Windows (and if you have any plugins that depend on the TF2_OnTakeDamageModifyRules hook, to verify that it's working).

[nosoop]

Released a second pre-release build. I thought they just needed a pre-hook, but no, on startup the hooks are getting different values (the eighth highest bit is set to 1 for whatever reason).

[Umbrozium]

sorry i just wasnt sure where i should move that comment/issue.

[nosoop]

Going to go ahead and close this since there hasn't been any activity and I haven't heard of any other complaints on it.