ZDoom

[quote="HotWax"]
[edit] One more question: I'd assume we [i]don't[/i] want this property to apply to friendly monsters? :)[/quote]

I wouldn't. That said, I would also like an opportunity to fiddle with friendly monsters health as well as hostile ones.

So I'm working on implementing the MonsterHealth property, and I have a question.

I could easily make it so as each monster is spawned, its health is adjusted by the MonsterHealth value, leaving the normal class' MaxHealth alone. However, this would mean that, for example, any ACS script using GetActorProperty(APROP_MaxHealth) would return the [i]original[/i] max health, not the adjusted.

I can also easily alter the implementation of GetActorProperty to return the adjusted amount, but before I do...

1) Is this a good idea? Should I assume that all scripts will want to know the adjusted value as opposed to the original, and...
2) Can anyone think of other features that I would need to likewise adjust to be aware of the possibility that the actor's class' default health may no longer be their actual starting health?

[edit] One more question: I'd assume we [i]don't[/i] want this property to apply to friendly monsters? :)

See [url=http://forum.zdoom.org/viewtopic.php?f=34&t=22567]here[/url] for a new implementation. It's a new thread because it doesn't address the other suggested properties (monsterhealth, playerhealth, etc.) from this thread.

Skill someskill
blah
ReplaceActor(ZombieMan, ShotgunGuy)
ReplaceActor(ShotgunGuy, ChaingunGuy)

Actor Poss2 : ZombieMan replaces ZombieMan { blah }
Actor SPos2 : ShotgunGuy replaces ShotgunGuy { blah }
Actor CPos2 : ChaingunGuy replaces ChaingunGuy { blah }

[quote="Graf Zahl"]I'll be honest here: I like the feature but the implementation is giving me headaches. There's just too much replacement going on with replaced actors being replaced again. Unless this is clearly defined and properly handled I'll leave it out. 'Properly handled' to me means that there's only one function in the entire source that handles all of this.[/quote]

Now that I look back on it, changing just the way FActorInfo::GetReplacement() works would be the best approach as it would be that single function that handles all of it. (Well, we also need the other way around for A_BossDeath, so GetReplacee() too.)

Now for clearly defined: what should happen if I have this:
[code]Skill someskill
blah
ReplaceActor(ZombieMan, ShotgunGuy)
ReplaceActor(ShotgunGuy, ChaingunGuy)[/code]

With the existing Replaces system, logically we'd get ZombieMan replaced by ChaingunGuy, which is in my opinion not a desirable effect here. We probably want sergeants to be still spawnable, as replacements of the former humans.

Now what if the above code is combined with that in DECORATE:
[code]Actor Poss2 : ZombieMan replaces ZombieMan { blah }
Actor SPos2 : ShotgunGuy replaces ShotgunGuy { blah }
Actor CPos2 : ChaingunGuy replaces ChaingunGuy { blah }[/code]

In my opinion again, we should have ZombieMan replaced by SPos2 and ShotgunGuy replaced by CPos2.

In other words: first apply the skill replacements, and then apply the DECORATE replacements to it. That's what I think would be the most useful behavior.

[quote="Graf Zahl"]And why is it necessary to hack FDoomEdMap::FindType?[/quote]
Well, it was that or P_SpawnMapThing because P_SMT calls Spawn with NO_REPLACE. I agree that the latter would have been better, I overlooked the part of it which contains the DECORATE replacement code. Either way, the patch as it is now was intended to get feedback, not for submission (I would have requested a move to Code Submission otherwise).

I'll be honest here: I like the feature but the implementation is giving me headaches. There's just too much replacement going on with replaced actors being replaced again.

Unless this is clearly defined and properly handled I'll leave it out. 'Properly handled' to me means that there's only one function in the entire source that handles all of this. And why is it necessary to hack FDoomEdMap::FindType?

[quote="Gez"]TMapified. Also hacked the bossdeath code to work with actors replaced by skills. (Dead Simple is harsh when the fatsos are replaced by barons.)[/quote]

nice >=) now i can finally continue on my skill wad without massive hackery.

itl be fun to replace stimpacks with those kamikaze stimpacks err... [i]kinsie[/i] made

TMapified. Also hacked the bossdeath code to work with actors replaced by skills. (Dead Simple is harsh when the fatsos are replaced by barons.)

+FName * FSkillActorReplacement::Get(FName sReplacee)
{
	if (sReplacee == replacee) return &replacer;
	else if (Next != NULL) return Next->Get(sReplacee);
	return NULL;
}

WTF?!?

[code]
+FName * FSkillActorReplacement::Get(FName sReplacee)
{
if (sReplacee == replacee) return &replacer;
else if (Next != NULL) return Next->Get(sReplacee);
return NULL;
}
[/code]

I'm a bit tired but this looks like you store these in a linked list and then iterate through it recursively. Yuck!
Please have a look at the TMap class which provides a simple and efficient means to define such tables.

I've cobbled together an implementation of ReplaceActor. It works, but I'm sure there'd be more elegant ways of doing that. The problem is that you can't use the existing replacement mechanism because said mechanism isn't skill-dependent. The plus side is that it allows to replace things by steps without skipping: for example, you can make a skill that replaces zombiemen by sergeants and sergeants by chaingunners, and it won't replace zombiemen by chaingunners.

[quote="HotWax"]This would be no more harmful than using Decorate to replace an actor with a new class of different dimensions. The author should be well aware that this could cause problems.[/quote]

Or would compensate for this.

This would be no more harmful than using Decorate to replace an actor with a new class of different dimensions. The author should be well aware that this could cause problems.

It should be used carefully, though (warning on the wiki would suit just fine), if the replacing actor has a larger radius or height, it could get stuck. This isn't that bad for items, but would definately be for monsters.

[quote=".+:icytux:+."]or replace medkits and weapons with attacking medkits and weapons xD[/quote]
Or to replace invulnerability spheres with invisi-spheres, or a powerup that gives the player full bright and radsuit capability with one that only gives radsuit and also drains life slowly. Or, or, or....

Yeah, this idea sounds pretty cool.

This would be useful to replace existing actors with other existing ones, without having to recreate them in DECORATE. Because the way to do it if you want, say, lost souls to replace former humans is to do something like this:
actor lostsoul2 : lostsoul replace zombieman
actor lostsoul2 : lostsoul 3004

It'll work, but if you had, say, dynamic lights attached to lost souls (because you use GZDoom with lights.pk3) then they're lost as they won't be attached to lostsoul2. And, short of directly editing ZDoom.pk3, there's no way of redefining directly a property of a base actor such as what they replace.

So the possibility to have the engine update the replacement information after skill selection is interesting.

or replace medkits and weapons with attacking medkits and weapons xD