Please change - Gibs != RealGibs
Moderator: GZDoom Developers
Please change - Gibs != RealGibs
I have a really high-ress gib replacement sprite.
It looks fine when placed as a map decoration (scaled through DeHacked), but when a monster is crushed under a door, the engine spawns a different sprite called RealGibs which is unscaled and unmodifiable in any way - thus breaking any modifications I made through DeHacked.
These two objects should be the same...
It looks fine when placed as a map decoration (scaled through DeHacked), but when a monster is crushed under a door, the engine spawns a different sprite called RealGibs which is unscaled and unmodifiable in any way - thus breaking any modifications I made through DeHacked.
These two objects should be the same...
- Cutmanmike
- Posts: 11335
- Joined: Mon Oct 06, 2003 3:41 pm
- Operating System Version (Optional): Windows 10
- Location: United Kingdom
- Contact:
-
- Posts: 380
- Joined: Thu Oct 21, 2004 5:27 pm
Purely for the record, when this behaviour was changed to the current Zdoom one, it did minorly mess up the dehacked patch I was working on at the time. Irrelevant now, but I remember it did catch me "on the hop" at the time.randy wrote:The problem is that Doom did not spawn a gib actor when something was crushed. Instead, the crushed actor was set to the gib state. There may not be any Dehacked patches that took advantage of this behavior, but I prefer to play it safe and stay compatible.
-
- Posts: 598
- Joined: Fri Jun 24, 2005 3:19 am
- Location: Makin tracks with jetboots
- MartinHowe
- Posts: 2027
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
- Contact:
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?cutmanmike wrote:I agree, but I think graf had a reason why this cannot be done.
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."
}
Code: Select all
MODIFY ZombieMan IMPLICIT
{
obituary "%o was killed by a modified Zombie."
}
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
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact: