[Can't] Please change - Gibs != RealGibs

Moderator: GZDoom Developers

Please change - Gibs != RealGibs

Postby Nash » Wed Jul 13, 2005 3:09 pm

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...
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Postby Graf Zahl » Wed Jul 13, 2005 3:47 pm

Can't be changed. It would really mess up DEHACKED patches that change the gib actor if it was.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Xaser » Wed Jul 13, 2005 3:53 pm

What we really need is the ability to modify existing objects with DECORATE. That would allow you to change the RealGibs actor itself.
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Postby BouncyTEM » Wed Jul 13, 2005 6:40 pm

Xaser wrote:What we really need is the ability to modify existing objects with DECORATE. That would allow you to change the RealGibs actor itself.

I agree. If we were able to do this, Dehacked would OFFICIALLY be useless for GOOD.
User avatar
BouncyTEM
All Caps Guy, Maker of Sir Belfin Dramatic Reading Series.
 
Joined: 24 Aug 2003
Location: 2280 Lol Street: The Calamitous Carnival (formerly Senators Prison)

Postby Cutmanmike » Thu Jul 14, 2005 4:54 am

I agree, but I think graf had a reason why this cannot be done.
User avatar
Cutmanmike
Is it hot in here or is it just ZScript
 
Joined: 06 Oct 2003
Location: United Kingdom

Postby randi » Fri Jul 15, 2005 2:57 pm

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.
User avatar
randi
Site Admin
 
Joined: 10 Jul 2003

Postby Cptschrodinger » Fri Jul 15, 2005 5:34 pm

Well, Then can we define the gib state with decorate?
Cptschrodinger
Our father, who art in hell
 
Joined: 21 Oct 2004

Postby Enjay » Fri Jul 15, 2005 5:45 pm

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.


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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby Nash » Sat Jul 16, 2005 12:30 am

Okay, I see that this thread has Randy's official NO labelled on it, but as someone said earlier; how about a gibbed/crushed state for the actor through DECORATE?
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Postby ant1991331 » Sat Jul 16, 2005 12:32 am

Xaser wrote:What we really need is the ability to modify existing objects with DECORATE. That would allow you to change the RealGibs actor itself.

although, i asked this before, and it would be great if you could....
ant1991331
Too quick.
 
Joined: 24 Jun 2005
Location: Makin tracks with jetboots

Postby MartinHowe » Sat Jul 16, 2005 2:51 am

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 allExpand view
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 allExpand view
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 :)
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Postby Nash » Sat Jul 16, 2005 2:48 pm

I fully agree with Martin's idea...
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Postby wildweasel » Sat Jul 16, 2005 8:56 pm

MartinHowe, you have just showcased the old saying "Great minds think alike" - this is exactly what I was thinking.
User avatar
wildweasel
change o' pace.
Moderator Team Lead
 
Joined: 16 Jul 2003

Postby Xaser » Tue Jul 19, 2005 12:10 am

The ability to modify existing things will fix more problems than anything else I can think of right now. MartinHowe, you have summed up the whole thing perfectly, and I can't think of any reason why not to add this.
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Postby Giest118 » Tue Jul 19, 2005 12:19 am

Bouncy wrote:Dehacked would OFFICIALLY be useless for GOOD.


Not quite.

It's still necessary if you want backwards compatibility, and it has the ability to change the player's max health.... (And yes, there are uses for that.)
User avatar
Giest118
I don't trust people who trust me. Because they're stoned.
 
Joined: 06 Dec 2003

Next

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests