Global & Per-Actor (inheritable) Death Scripts

[NeuralStunner]

Would it be better to have the base functionality on its own, and work out the action function as a separate submission later? I hate to see a good feature getting stalled for an extension that's entirely useless without it.

[Graf Zahl]

Let's be clear: I have no problems with A_SetDeathScript or an ACS variant, as long as it sets all the args as well.
Yes, the rest can be sorted out later, nothing will happen there without another dev's input.

[Ghastly]

I have no idea what you are saying.

tell me how to make decorate expressions, or at least the file that they're defined in

So he can expose these death script arguments as decorate expressions. That way we can keep existing arguments in an action function that can modify all death script arguments.

[StrikerMan780]

I have no idea what you are saying. What do you mean by "having some DECORATE expressions"?

How don't you know this?

http://zdoom.org/wiki/DECORATE_expressions

Scroll down to "Variables".

I want to have DSArg[x] as a decorate expression so one can retrieve those values if they need to. So, one can use something like A_SetDeathScriptArg("Script", DSArg[0], 333, DSArg[2], DSArg[3]) if they want to edit one arg while leaving the others alone. Similar to args[x], which is something that exists for specials. This way I can use the syntax you want, while keeping the functionality/flexibility I want.

I am asking which file these expressions are supposed to be defined in, in the source code. I am having difficulty locating them.

EDIT:

I have no idea what you are saying.

tell me how to make decorate expressions, or at least the file that they're defined in

So he can expose these death script arguments as decorate expressions. That way we can keep existing arguments in an action function that can modify all death script arguments.

Yeah, you got it.

[Graf Zahl]

Two words: Total overkill.

[StrikerMan780]

Two words: Fuck yourself.

User was warned about this post. - Mod

[Leonard2]

This just very problematic anyways.
Imagine you have an actor that has no deathscript defined but there is already a default one in the mapinfo lump.
If you call A_SetDeathScriptArg with the decorate expression identifier you want as arguments to this call you will get the wrong arguments as you will be reading the actor's data rather than the gameinfo's data which is what you would want in such a case.
Having the identifier return either the gameinfo or the actor's data depending on the current definition is unfortunately beyond decorate's capabilities.
Let's not even take in account the use of "+BOTHDEATHSCRIPTS'". What would the decorate expression even return in such a case?
I think this is just broken by design.
Unless you have the default deathscript defined by gameinfo stored in the actor's data rather than gameinfo. This would mean loosing "+BOTHDEATHSCRIPTS" but it would make everything much more sane and you would be able to use decorate expressions as a solution.

I couldn't figure out how to have it take either a string or integer interchangeably without making a mess.

This should definitely be possible for both an actor and a gameinfo's definition.

Reading your submission, apparently deathscripts don't trigger if they come from a player.
Why such a limitation?

On a side note, you really should use the ACS_WANTRESULT flag rather than ACS_ALWAYS when calling P_StartScript.
Having the script execute immediatly will avoid some headaches for a ton of people and will make the whole thing consistent with typed scripts.

[StrikerMan780]

User was warned about this post. - Mod

Like I give a shit. He had it coming.

Just scrap this. I stopped caring. Doesn't matter, nothing does. Nothing ever will.

Not like it'll matter if this gets in or not, I'll be dead in a few weeks anyway. Like everything else I do, this fell to shit. A failure, like myself.

[Graf Zahl]

Note to everybody here:

If you act like you are entitled to get the features you want in exactly the way you want, think again. This is not your engine. You are not the ones who will have to live with all the baggage your features create. As such, if the developers say that a feature has to be restricted/altered/denied for a given reason, insulting the devs, bitching and complaining won't get you anywhere.

It'd just take two clicks for me to close this thread, never to be heard from again.

[Graf Zahl]

I might just close this. As it stands this submission does not work like I would imagine, it still needs work - but with what happened last night it looks like we can forget about this getting addressed. If someone feels like cleaning this up, be my guest but don't expect me to put any work in here.

[wildweasel]

Since the thread's closed and the OP no longer has access to the forums, I've been asked to notify the devs that the pull request is redone from scratch and ready for approval.

https://github.com/rheit/zdoom/pull/745

[Graf Zahl]

Added the new submission.