Allow DECORATE actor names to duplicate existing names

Moderator: GZDoom Developers

User avatar
Enjay
 
 
Posts: 26441
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Allow DECORATE actor names to duplicate existing names

Post by Enjay »

Reasons why are stated here.

http://forum.zdoom.org/viewtopic.php?p=114504

24
User avatar
David Ferstat
Posts: 1113
Joined: Wed Jul 16, 2003 8:53 am
Location: Perth, Western Australia

Post by David Ferstat »

When you think about, this is simply a logical extension of the traditional Doom/Zdoom method of changing resources.

We're all accustomed to loading a wad (and in Zdoom, a Dehacked/Bex file) that would simply replace any previously loaded data. Being able to do the same with DECORATE would at least be consistent.
User avatar
Tormentor667
Posts: 13470
Joined: Wed Jul 16, 2003 3:52 am

Post by Tormentor667 »

Seconded, might be useful for KDiZD
User avatar
Cutmanmike
Posts: 11286
Joined: Mon Oct 06, 2003 3:41 pm
Operating System Version (Optional): Windows 10
Location: United Kingdom

Post by Cutmanmike »

:idea:
User avatar
Your Name Is
Posts: 802
Joined: Sun Oct 31, 2004 5:06 pm
Location: Raleigh, NC

Post by Your Name Is »

Thirded, might be useful to replace originals when DEHACKEd has messed them up for the moment...
User avatar
randi
Site Admin
Posts: 7731
Joined: Wed Jul 09, 2003 10:30 pm

Post by randi »

Counterpoint: Inheritance. If you replace an existing actor's definition, then you also need to reprocess all the actors that inherit from it. A simpler and less error-prone alternative that would serve your purposes just as well would be to specify a list of replacement actors. e.g.

Code: Select all

replace DoomImp with DoomImp2
would cause any attempts to spawn DoomImp to spawn DoomImp2 instead.
User avatar
Enjay
 
 
Posts: 26441
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Post by Enjay »

Inheritance was something I thought might cause a problem, but seeing as how Graf didn't flag it up, I assumed it wasn't going to be one. eg, maybe, I thought, the inheriting would be done before the substitution of the DECORATE version and so allow inheritance before applying changes - kind of like how if you inherit from a monster that has been dehacked, it's the original monster behaviour the gets inherited, not the dehacked version (apparently).

But yes, your suggestion would overcome my biggest problem - not being able to easily replace an actor that doesn't get into the map via the editor. It wouldn't solve my other (more minor) point of Zdoom not allowing me to load a second decorate with the names of actors from another decorate lump from the command line for testing purposes. However, if it can't be done, then it can't be done. Although that is a more minor point, it's also the one I come up against most often. :(

23
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48519
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

randy wrote:Counterpoint: Inheritance. If you replace an existing actor's definition, then you also need to reprocess all the actors that inherit from it.
Just don't do it. If a duplicate name appears you could just forget that the original (and all its derivates) ever existed. Everything that came before inherits from the old version and everything that comes after uses the new version. I already had my fights with that limitation, too.
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Post by Zippy »

Graf Zahl wrote:Just don't do it. If a duplicate name appears you could just forget that the original (and all its derivates) ever existed. Everything that came before inherits from the old version and everything that comes after uses the new version. I already had my fights with that limitation, too.
Let me see if I can just put this in a general perspective, to make sure I'm understanding it...

ZDoom starts loading up, and bases all inherited DECORATE actors off the the original monsters they inherit from. Then ZDoom hits a new DECORATE lump or just a new Actor in the lump designed to replace one of the original monsters, let's say, the imp. In DECORATE it would look like so.

Code: Select all

Actor DoomImp
{
...
So now, ZDoom forgets about the old original imp and uses this new DECORATE actor as the imp. All the actors which inherited from the old imp that were created previously are still based off the old imp.

Now, DECORATE continues to be loaded into ZDoom. You are saying that when ZDoom encounters this...

Code: Select all

Actor SuperDeathImp : DoomImp
{
...
... it will now inherit from the newly defined DoomImp, right? When you said "forget that the original (and all its derivates) ever existed" you were just refering to when ZDoom loads?

This seems good, and it would serve its purpose. Would this still leave room to support the multiple DECORATE lumps though? Things could change around if DECORATE lumps aren't loaded in a certain order.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48519
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Zippy wrote:
Graf Zahl wrote: This seems good, and it would serve its purpose. Would this still leave room to support the multiple DECORATE lumps though? Things could change around if DECORATE lumps aren't loaded in a certain order.
THat's the whole point of it. The current issue is that you can't just extract something from a lump, change it and load it with '-file'. Or to load 2 different resource WADs which happen to define the same names.
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Post by Zippy »

Graf Zahl wrote:
Zippy wrote:
Graf Zahl wrote: This seems good, and it would serve its purpose. Would this still leave room to support the multiple DECORATE lumps though? Things could change around if DECORATE lumps aren't loaded in a certain order.
THat's the whole point of it. The current issue is that you can't just extract something from a lump, change it and load it with '-file'. Or to load 2 different resource WADs which happen to define the same names.
Ah, ok, I see it now. Must've messed up understanding something my first time through. Probably from making some subliminal assumptions about the matter of inheritance that I shouldn't have. I guess this works.
User avatar
Cutmanmike
Posts: 11286
Joined: Mon Oct 06, 2003 3:41 pm
Operating System Version (Optional): Windows 10
Location: United Kingdom

Post by Cutmanmike »

Someone needs to remember how to use quotes properly :P
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48519
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Yes, phpBB should. It is far too easy to mess up nested quotes.
User avatar
Chris
Posts: 2897
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Post by Chris »

I've never had a problem. Just be careful when you delete quotes that you delete the right bracket set. PIBCAK
User avatar
Sir_Alien
Posts: 863
Joined: Sun Aug 29, 2004 6:15 am
Location: Sydney, Australia

Post by Sir_Alien »

And preview your posts before you post them.
Chris wrote:PIBCAK
:?:

Return to “Closed Feature Suggestions [GZDoom]”