Modifying Player States

[Metal96]

Hello all,

So to begin, I have a simple question: can the player mobj states be changed to have different actions? I have concluded that the actions of each state are entirely hardcoded, meaning anything put into the "action" spot will just be ignored--no matter what. However, I can change the length/next attributes of the states which seems to be contradictory to my conclusion...

Anyway, the point is I want a script to execute when the player dies. So I stuck A_LinedefExecute into the second frame of the dying sequence, as the first already had A_Fall. It didn't work. I also tried redirecting the player mobj to a freeslot with the action, which didn't do anything at all. However, I can change the "next" states internally with the states in the player mobj, but I cannot get actions to work. Is there some way to do this without a source mod?

 

[Ricardo]

Yes, you can do that with SOCs only. However, I don't know exactly why you need to execute a script via linedef executor, since you're already taking the SOC path in the first place. In other words, why not start your script using SOC actions directly, or is that not a viable option for you?

Anyway, it is indeed possible to execute arbitrary SOC actions triggered by the player's death. You almost made it with your strategy, but instead of altering the second or third "death frame", you simply need to change the first frame to a custom one via freeslots and setting its "nextstate" to the former default.

More specifically:

1. Create a custom state using freeslot F and set the deathstate field of the MT_PLAYER mobj to F
2. Set the duration of F to 0 tics
3. Set the nextstate of F to the default deathstate of the player (a quick look at the source/wiki tells me it's state 34)
4. Give F your desired action

 

[Metal96]

However, I don't know exactly why you need to execute a script via linedef executor, since you're already taking the SOC path in the first place. In other words, why not start your script using SOC actions directly, or is that not a viable option for you?

It is a console script. Unless I can execute console commands directly with SOC, but I've never heard of such a thing...

More specifically:

1. Create a custom state using freeslot F and set the deathstate field of the MT_PLAYER mobj to F
2. Set the duration of F to 0 tics
3. Set the nextstate of F to the default deathstate of the player (a quick look at the source/wiki tells me it's state 34)
4. Give F your desired action

Absolutely fantastic. I will try this. Thank you.

EDIT: It does not work. However, the console does spit out "A_LindefExecute blahblahblah" with the right variables which leads me to believe the SOC is working (thanks again), which means my executor has been botched somehow. I tested the execution with a regular push-button executor in-map, and it runs the script fine, however it does not from the action. I have the script named "SCR01201", the floor height of the trigger sector to 201, the linedef with the action of 415 having the tag of 2001, and the SOC VAR1 set to 2001. Please tell me what is wrong.

EDIT2: Even better, have a functionally identical test wad. It will provide you with a cecho message if it works right. It does not provide the message for me.

 

[Ricardo]

A_LinedefExecute executes the linedef executor whose tag is equal to the value of the state's var1. This means the tag of the trigger linedef, not the action one.

You just need to add a trigger linedef of your choice to the control sector, which in this case can either be Once or Continuous (do not use Each Time since it doesn't work here), and give it the tag you have on your state's var1, which is 2001 in this case.

Your action linedef with type 415 doesn't need any tag.

To be honest, the wiki article of A_LinedefExecute was not entirely explanatory regarding which linedef the tag is supposed to reference. I made a slight change to the article to make it more explicit.

 

[Metal96]

Oh, thank you! Yes, the article mentioned the "tag of the linedef to be executed." Thank you for explaining this. I actually tried the trigger executor method but set it to Each Time :-P

EDIT: I re-edited the Wiki page to streamline the sentence and include the note about not using Each Time triggers.