Eating corpses

[MartinHowe]

While working on the morphing code, it became clear that some way is needed for a morphed animal to gain health. Although, I have made progress in experiments for a reasonably simple per-item pick up allow/deny for dumb animals, for the even simpler cases, being able to pick up health, but nothing else, is sufficient.

Clearing the PICKUP flag for morphed animals prevents them picking up anything, which is good, except you can't even pick up health in that state. Then I remembered that just after the DOOM source release, some enterprising soul with an even weirder imagination than mine ( ) made a source mod of DosDoom (as EDGE was called then) that used Bombay 72 for graphics and sounds and added the ability to "eat" corpses! Of course, this would meet the need for a "no-pickup except health" mode.

The attached is a diff against r921 of a very rough-and-ready corpse-eating codepointer called A_Consume(). It works, but needs fine tuning. Example use is as follows (the code should go in a player pawn that has the PICKUP flag clear):

Code: Select all

	See:
		BCAT C  2
		BCAT C  0 A_JumpIfHealthLower(350, "Hungry")
		BCAT 2
		Goto See
	Hungry:
		BCAT D  2 A_Consume(0, 350)
		Goto See

Comments and suggestions are welcome. You can send abuse too, but my cat will eat you if you do, so I wouldn't advise it

[MartinHowe]

Well, either nobody's noticed it, or else nobody wants to compile their own executable or whatever

OK, here's a small test WAD and a zdoom.exe file to go with it. Start any map and summon a KITTYLATOR artefact. Pick it up and use it. You will turn into a large cat; it's supposed to be a jaguar or panther but the graphics are crap because they're all I have. When you press the FIRE key, it's a close-quarter melee weapon like a beak or snout, though I haven't made the picture of a cat's nose to go with it yet, it does work. AlfFire makes you leap forwards at and bite the enemy over short distances. When your health gets below 350 you will "eat" corpses by walking over them. try it!

[Onslaught Six]

Actually, it didn't take much "imagination" for this idea--if I remember right, Wolfenstein 3D allowed you to slurp up certain puddles of blood, water or other goo for 1% health if you had less than 10. Kinda gruesome, when you think about it.

Anyway, I was wondering if this same code could be altered to work only on "certain" actors--e.g. if I decided to make similar "goo puddle" actors that you could use to get little amounts of health if you were really desperate.

[MartinHowe]

Heh Yes, the Wolf-3D blood puddles was certainly gruesome - though I didn't know about that until recently. Anyway I emailed the authors of VSB doom to let them know about this thread, for ol' time's sake, though after ten years who knows if they'll even care, given they've moved on to other games

Currently, and this could change before submitting it as a feature request since the whole idea of posting it on the editing forum is to iron out the logical problems first, the prototype for A_Consume is this:

Code: Select all

action native A_Consume(optional eval int flags, optional eval int hungryif, optional eval int minhealth, optional eval int maxhealth, optional eval int foodvalue, optional name consumerstate, optional name consumedstate);

A_Consume defines two actors, the scavenger and the beneficiary; this allows the programmer to make, for example, a wraithverge whose spirits seek corpses and feed their master by "telepathy" and allows the function to be called from almost any type of actor, especially by weapons and non-weapons. When an "edible"
corpse is found, the beneficiary receives a fraction of the start health (property of) the corpse and the corpse is removed.

• The search for health is carried out in the vicinity of the scavenger; this is usually the actor that called the function unless the caller is an inventory item, such as a weapon or powerup; in this case, the scavenger is the owner of the item.
• The health from a corpse is given to the beneficiary; this is usually the actor that called the function unless the caller is an inventory item, such as a weapon or powerup, or a missile; in the case of an inventory item, the beneficiary is the owner of the item; in the case of a missile, the scavenger rule is applied to the actor that actually fired the missile, in order to determine which player or monster really fired the missile.
• If there is no beneficiary that can be positively identified as being a player or monster, the function does nothing. This can happen because of a known bug in the engine's target/source handling which occasionally causes the engine to "forget" who ultimately fired the shot; see this thread for details.

The arguments are as follows:

• flags -
  • CSF_CONSUMEMONSTERS (value 1)
  • CSF_CONSUMEBOSSES (value 2)
  • CSF_CONSUMEPLAYERS (value 4)
  default is 5 - consume players and (non-boss) monsters, but not bosses.
• hungryif - don't try to eat if the beneficiary has this much health or more; negative amount -x means +x% of beneficiary's start health; default is -50.
• minhealth - ignore corpses whose start health is less than this; default is 0, which implicitly means "no limit".
• maxhealth - ignore corpses whose start health is more than this; default is 0, which is defined to mean "no limit".
• foodvalue - limit the received health to this amount; negative amount -x means +x% of corpses' start health; default is -100.
• consumerstate - if the function succeeds, put the beneficiary into this state; default is do nothing.
• consumedstate - if the function succeeds, put the corpse into this state; default is a generic "consumed" state that the patch adds to the engine, analogous to the generic ice death state.

IIRC, no regular monster has a start health lower than about 20 so using the minimum health of 20 (or whatever your preferred value is) would do it.

At the moment - I can think of a few things that should be considered; a flag to explicitly say "no consumer state" and one to explicitly say "no consumed state"; this is a limitation of DECORATE - the engine can't distinguish between "" to mean "nothing at all" and "" to mean "None". Perhaps the engine should define a NAME_Nothing value to explicitly mean "do nothing" as opposed to "NAME_None" which means "no name was given".