cutmanmike wrote:I agree, but I think graf had a reason why this cannot be done.
Why not? Inheritance is handled by class names, not DoomEdNums. What one wants, more often than not, is a new actor to replace the original but with the same DoomEdNumber. This is not a strong as actually modifying the original actor, but is close enough that it surely deserves to be implementd?
Define a new actor inheriting from an old one and have a new decorate keyword something like this:
Code: Select all
ACTOR MyZombie : ZombieMan SAMEID
{
obituary "%o was killed by a modified Zombie."
}
All this would do is suppress the warning about two things having the same DoomEdNum, surely that's a trivial matter to change? After all, the original ZombieMan can still be referenced by class name. As to changing the originals, what problems would this cause:
Code: Select all
MODIFY ZombieMan IMPLICIT
{
obituary "%o was killed by a modified Zombie."
}
The IMPLICIT keyword would mean that changes were inherited whenever the game implicitly uses a ZombieMan for something. EXPLICIT would mean that the changes would only affect ZombieMen created or referenced
explicitly by the mapper, for example by placing one by DoomEdNum in the editor or SpawnSpot() in a script.
In effect, ZDoom would need to store a copy of the original definition; however, that could be standard anyway. Each predefined THING could be defined as Default<ClassName> inside the system, with <ClassName> being defined by the game automatically as a no-change inheritance of the default version if nothing tries to change the default version of the THING. In this case, the "real" ZombieMan would be DefaultZombieMan and ZombieMan would automatically be created by the game if nobody attempted to modify Zombies.
The MODIFY, EXPLICIT and IMPLICIT keywords would only work on predefined THINGS. Note that the default version should NOT have a DoomEdNum as it would only be needed internally for use by the game. Indeed, although it would be possible to refer to the default item explicitly by class name (for example, in a script), should it even be allowed?
Discuss
[quote="cutmanmike"]I agree, but I think graf had a reason why this cannot be done.[/quote]Why not? Inheritance is handled by class names, not DoomEdNums. What one wants, more often than not, is a new actor to replace the original but with the same DoomEdNumber. This is not a strong as actually modifying the original actor, but is close enough that it surely deserves to be implementd?
Define a new actor inheriting from an old one and have a new decorate keyword something like this:
[code]ACTOR MyZombie : ZombieMan SAMEID
{
obituary "%o was killed by a modified Zombie."
}
[/code]
All this would do is suppress the warning about two things having the same DoomEdNum, surely that's a trivial matter to change? After all, the original ZombieMan can still be referenced by class name. As to changing the originals, what problems would this cause:
[code]MODIFY ZombieMan IMPLICIT
{
obituary "%o was killed by a modified Zombie."
}
[/code]
The IMPLICIT keyword would mean that changes were inherited whenever the game implicitly uses a ZombieMan for something. EXPLICIT would mean that the changes would only affect ZombieMen created or referenced [b]explicitly [/b] by the mapper, for example by placing one by DoomEdNum in the editor or SpawnSpot() in a script.
In effect, ZDoom would need to store a copy of the original definition; however, that could be standard anyway. Each predefined THING could be defined as Default<ClassName> inside the system, with <ClassName> being defined by the game automatically as a no-change inheritance of the default version if nothing tries to change the default version of the THING. In this case, the "real" ZombieMan would be DefaultZombieMan and ZombieMan would automatically be created by the game if nobody attempted to modify Zombies.
The MODIFY, EXPLICIT and IMPLICIT keywords would only work on predefined THINGS. Note that the default version should NOT have a DoomEdNum as it would only be needed internally for use by the game. Indeed, although it would be possible to refer to the default item explicitly by class name (for example, in a script), should it even be allowed?
Discuss :)