ZDoom

[quote="Xtyfe"][quote="Ghastly_dragon"]Would it be too much to ask[/quote]

Seems to be the feeling here these days[/quote]That's not helping. Please knock it off.

[quote="Ghastly_dragon"]Would it be too much to ask[/quote]

Seems to be the feeling here these days

Would it be too much to ask to apply some kind of HealType (like damagetype for resurrecting), so we can have Raise.Archvile and etc. states? I'm thinking of something like the Gremlins from Quake - Scourge of Armagon, which consume corpses to create new Gremlins.

Fair enough, I only hope it gets added one day :p

There's a lot of things that are still under consideration, Xtyfe. FDARI will have to update some of his submissions because they are potentially quite outdated and no longer apply properly.

I see it's possible to specify the heal state with this, but what about the raise state? Something can't be resurrected already unless it has the standard raise state, so why not prevent resurrection based on whether it has the specified state that defaults to "raise". I can use this to prevent an opposing side of monsters from resurrecting the other.

On that note, whats the hold up with this not being added yet?

The healer doesn't heal itself, but the "ReActionMan" class has the ability to raise (new) and the ability to be raised (inherited from ZombieMan). A single ReActionMan will always be raising another actor, not itself.

The custom inventory is not used to force another actor to do something, but to put a lot of statements in a single line of code. I called the item "ReanimationRitualBatch" because it contains several instructions for the healer.


By the way: This submission is fading from memory, I'm afraid, but I think that RESF_REUSECORPSE will not allow raising a corpse that's out of range. RESF_REUSECORPSE will try only for the remembered actor, but in the same way it would otherwise try for all actors. So if the corpse slips out of reach before the final A_Chase, it will not be raised.

Hmm... I think I got most of that, thanks for explaining it.

But I don't understand the example zombieman - he seems to both resurrect things and be resurrected.

And what about giving the resurectee a custom inventory item that makes it behave in a particular way? As far as I can see, the zombieman is giving it to himself, rather than the resurrectee. What have I got wrong here?

I also am not sure how to just search for corpses without chasing any other actors. Again, it's been a long time since I delved into the code, but IIRC, specifying "" for a melee and missile state would cause the actor to enter their default melee and missile state, rather than ignoring potential targets :?

(I would try using the example zombieman, but without more explanation I fear I would misinterpret what I see him do!)

EDIT: Would it be possible for us to see the full version of the code modification, instead of a "simplified" one?

[b]EDIT:[/b]

I have thought of a clean way to do some of what I wanted (or even all of it, with a bit of work). Being resurrected makes the resurrectee an "unofficial" minion of the ArchVile (or whoever called the codepointer). So why not have an extra flag that says to make the resurrectee an [i]official[/i] minion of the resurrecter? In other words, the resurrectee gets their MASTER pointer set to the resurrecter.

In my original idea, using the TARGET pointer was logical because I was thinking of the resurrection as a form of attack, but making him a minion would also suffice - there are "give to children" and "give to master" codepointers, which allows remote manipulation between children and master. Actually, there should really be two such flags - one to make the resurrectee a minion when they are raised, and another one to make them a minion before the raise takes place, so that some processing can be done before the resurrectee enters their Raise state.

EDIT EDIT:

OK, this idea works up to a point - for example I made a customised hellhound (from the beastiary) and configured it this way (I called it the RESF_EARLYMINION flag in my code) and put in the Heal.complete state A_RemoveChildren(1). The monster makes corpses disappear completely! It's as if he is eating them :) I did [url=http://forum.zdoom.org/viewtopic.php?f=3&t=17038]make something like this years ago[/url] but have lost the blasted source code!!!

The problem is that there appears to be no action function for giving inventory items to master or children; must be an ACS function only :( Have to have another look later.

The original submission worked a little like that, but Graf made it clear that he would not allow a feature like this to depend on custom use of standard pointers. When A_Chase does the resurrection thing and finds a corpse, that corpse is stored in a hidden pointer. If you have specified RESF_REUSECORPSE, the corpse from the previous operation is reused. If you have specified RESF_NORAISE, the located corpse will not be raised.

A_Chase("","",CHF_VILECHASE, RESF_NORAISE) works like A_SearchForCorpses, although you cannot access information about the corpse in scripts (Graf would not have a pointer selector for this corpse).
A_Chase("","",CHF_VILECHASE, RESF_REUSECORPSE) works like A_Resurrect, although you can only raise the corpse that was found by the previous search.

With reusecorpse: Reuse the corpse from the last search.
Without reusecorpse: Search for a corpse.
The rules for finding a corpse on search are the same as for A_Chase("","",CHF_VILECHASE).

Interesting. I was having similar thoughts, but along different lines. Much of it here seems OK, but I cannot see a way to get at the actor resurrected.

What I was originally thinking was to have a new codepointer [b]A_SearchForCorpses(int flags)[/b] with flags to tell the function which pointer (target or tracer) to put the result in and then an [b]A_Resurrect(int flags)[/b] codepointer using the same flags to tell it which pointer holds the resurrectee.

The idea would be so that the modder can split the process up and put the actor in the target pointer so that other more generic functions can then be used on it.

Could any of that be incorporated? Or have I just misunderstood what is going on in the example?

Updated in accordance with restrictions and guidelines, to the best of my understanding and ability.

This could come in handy. I'll have to try this out later. The RESF_NOSOUND I'm definitely looking forward to.

[b]A_Chase(state melee = "*", state missile = "none", int flags = 0, int healflags = 0, state heal = "")[/b]

New parameters:

STATE heal: If specified, jump to this state instead of the automatic healing state.

INT healflags:

RESF_NORAISE: Do not resurrect the corpse.
RESF_REUSECORPSE: Use the corpse from the previous resurrection instead of a search. If the previous call did not find a suitable corpse, this is NULL.
RESF_NOSOUND: Do not play the default sound.
RESF_NODEFAULTJUMP: Do not perform the default jump. Implicit if a custom jump for healing is specified.
RESF_DONTSTOPCORPSE: Do not set the corpse's xy-momentum to 0.

The demo uses NORAISE, NOSOUND and DONTSTOPCORPSE to locate a corpse and start healing it. Because momentum is not killed, a sliding corpse can slip out of reach during this process. When the final call is made, REUSECORPSE causes the function to try resurrecting the same corpse that was first selected, instead of searching for a new corpse.
[spoiler=For good and for bad this had to go]RESF_NORAISE: Do not actually raise the corpse.
RESF_CHECKPOINTER: Try an actor from one of your pointers before searching the area for corpses (default TRACER).
RESF_SETPOINTER: Assign the corpse (if one is found) to a pointer (default TRACER).
RESF_CLEARPOINTER: Clear the selected pointer if no corpse is found (default TRACER).
RESF_USEMASTER: Use master for all pointer operations
RESF_USETARGET: Use target for all pointer operations
RESF_USETRACER: Use tracer for all pointer operations (default, value = 0)
RESF_DONTSEARCH: Do not search for actors. (Should be used in conjunction with RESF_CHECKPOINTER)
RESF_NOSOUND: Don't play the default resurrection sound.
RESF_NODEFAULTJUMP: Don't perform the default resurrection jump. (If the non-default STATE heal is specified, this flag has no effect.)
RESF_DONTSTOPCORPSE: Don't set the corpse's xy-velocity to 0.[/spoiler]
Some details in decorate-file in demo.

Possible uses: Delay the resurrection effect (demonstrated). Make the resurrection interruptable by painstate (demonstrated). Customise the appearance of resurrections. (I'd say that's demonstrated too)

[spoiler=Compatibility notes]There has been one change of no obvious significance, to the order of events in P_CheckForResurrection. The default statejump is now processed only after the complete processing of the resurrection. This would affect any function that required the resurrection to be incomplete at the beginning of the heal-state. Seeing as the advanced decorate processing of resurrection has not previously been available, I believe this change is without significance.

The change is not necessary, but it is preferable: It avoids code duplication, and causes consistent behaviour between the custom state (4. parameter) and the default state. It also seems more intuitive and useful that all operations, especially pointer assignments, should be complete before the state jump is performed, since the ensuing state might depend on the results.

Compatibility seems unlikely to break. Modders are easily allowed to process the results instantly instead of with a 1 tick delay (although they'd achieve the same by sending a custom state parameter).[/spoiler][b]Important note to developer:[/b] I have now modified the save format by adding the new pointer. In the patch you might note a big comment where the revision number needs to be updated. The line reads "[u]if (SaveVersion >= 3242) // THIS NUMBER CANNOT BE 3242, that's only for my revision 3242M (feature added) [FDARI][/u]". I couldn't see a good way for me to ensure that the revision number would end up being correct, so I left it to you.