Additions to skill definiton

[TheDarkArchon]

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.

Or would compensate for this.

[Gez]

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.

[Graf Zahl]

WTF?!?

Code: Select all

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

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.

[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.)

[.+:icytux:+.]

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

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

itl be fun to replace stimpacks with those kamikaze stimpacks err... kinsie made

[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. And why is it necessary to hack FDoomEdMap::FindType?

[Gez]

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.

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: Select all

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

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: Select all

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

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.

And why is it necessary to hack FDoomEdMap::FindType?

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).

[Gez]

See here for a new implementation. It's a new thread because it doesn't address the other suggested properties (monsterhealth, playerhealth, etc.) from this thread.

[HotWax]

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 original 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 don't want this property to apply to friendly monsters?

[TheDarkArchon]

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

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