Page 1 of 1

Player death logic

Posted: Tue Sep 13, 2016 11:21 pm
by Subject9x
Hello all, first time posting here but have been reading for a while now and have studied the tutorials from the old site in the past.

I tried searching for this problem but haven't found an answer close to my problem.

Scope:
1) making a mech-style mod built using Darkplaces extensions.
2) players have entities attached to them as parts (using MOVETYPE_FOLLOW).
3) certain entities when killed, will kill the player ent (namely the mech's 'center torso').
4) player ent does not have a model, rather a pair of 'legs' are bolted onto the player at an offset.


Issue:
How do I handle player death? vanilla QC has the player state tightly coupled to the animation frames, but for my mod this is not the case.
I've been tearing my hair out trying to get respawning to work because the .deadflag logic is not being handled correctly.

Code: Select all

void() PlayerDie={
/*
normal code cribbed from player.qc
*/
  if(self.p_class == P_MECH){
    mech_player_die();
  }
  PlayerDead(); //this functions exactly as the original in player.qc
};

Code: Select all

void() mech_player_die={

  local entity oself, w_chain, next;
  oself = self;
  mech_player_cameradie();
  
  mech_player_compdie(self.e_tor_c);
  mech_player_compdie(self.e_tor_l);
  mech_player_compdie(self.e_tor_r);
  mech_player_compdie(self.e_arm_l);
  mech_player_compdie(self.e_arm_r);
  mech_player_compdie(self.e_legs);
  
  w_chain = self.w_slot;
  while(w_chain){
    mech_player_compdie(w_chain);
    w_chain = w_chain.w_slot;
  }
  self = oself;
};

void(entity comp) mech_player_compdie={
  if(comp.model){
    if(comp != world && comp.owner == self){
      local entity old;
      old = self;
      self = comp;
        self.th_die();
      self = old;
    }
  }
};

any help would be greatly appreciated, I plan on putting the work-in-progess QC up on github if I can solve the respawn issue (theoretically its the last major problem holding me from building more of the actual mod...)

Image

Re: Player death logic

Posted: Wed Sep 14, 2016 11:14 am
by 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.

Re: Player death logic

Posted: Wed Sep 14, 2016 10:11 pm
by 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?

Re: Player death logic

Posted: Thu Sep 15, 2016 11:53 am
by 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.

Re: Player death logic

Posted: Fri Sep 16, 2016 12:06 am
by 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?

Re: Player death logic

Posted: Fri Sep 16, 2016 1:05 am
by frag.machine
At least for a start I'd try to do as you described.

Re: Player death logic

Posted: Mon Sep 26, 2016 12:03 pm
by 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 :)