Player death logic

[Subject9x]

[frag.machine]

I'd suggest to treat the mech torso as the player model/main entity to keep compatibility with the original death functions. You haven't mentioned but losing parts during combat suggests some sort of locational damage. Remember that MOVETYPE_FOLLOW assumes all attached entities use SOLID_NOT. With my experiments in multipart players I had the best results this way.

[Subject9x]

Thanks! I'll give that a try tomorrow
I was thinking over it today, if the player is the center torso, I myself am not sure how to keep the player on the ground to move normally except for:
Making the player hitbox encompass most of the mech's volume, filtering out the player when a project hits and finding the closest available body part? Maybe set the player to fly a certain number of units above the ground?

[frag.machine]

In this case there's no elegant way to deal with locational damage unfortunately; you will have to make some calculations to find the approximated impact area and react according. You may simplify a bit things working only in relation to the z axis and thus defining 3 zones: head, body or legs. The idea of a "hovering" entity sounds complicated and prone to many problems like getting stuck in stairs or jumping.

[Subject9x]

so should the player bbox encompass 'most' of the expected mech's volume? and the player model; the 'center torso' would be drawn at an offset?

[frag.machine]

At least for a start I'd try to do as you described.

[Subject9x]

quick update: I haven't had a chance to try coding the location damage yet, but I did fix the player respawning issue by following your suggestions, thanks