Allow DECORATE actor names to duplicate existing names
Moderator: GZDoom Developers
-
-
- Posts: 26690
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
-
- Posts: 1113
- Joined: Wed Jul 16, 2003 8:53 am
- Location: Perth, Western Australia
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.
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.
-
- Posts: 13549
- Joined: Wed Jul 16, 2003 3:52 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Germany
-
- Posts: 11349
- Joined: Mon Oct 06, 2003 3:41 pm
- Operating System Version (Optional): Windows 10
- Location: United Kingdom
-
- Posts: 802
- Joined: Sun Oct 31, 2004 5:06 pm
- Location: Raleigh, NC
-
- Site Admin
- Posts: 7749
- Joined: Wed Jul 09, 2003 10:30 pm
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. would cause any attempts to spawn DoomImp to spawn DoomImp2 instead.
Code: Select all
replace DoomImp with DoomImp2
-
-
- Posts: 26690
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
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
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
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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.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.
-
- Posts: 3302
- Joined: Wed Mar 23, 2005 5:31 pm
- Location: New Jersey
Let me see if I can just put this in a general perspective, to make sure I'm understanding it...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.
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
{
...
Now, DECORATE continues to be loaded into ZDoom. You are saying that when ZDoom encounters this...
Code: Select all
Actor SuperDeathImp : DoomImp
{
...
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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.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.
-
- Posts: 3302
- Joined: Wed Mar 23, 2005 5:31 pm
- Location: New Jersey
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.Graf Zahl wrote:Zippy wrote: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.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.
-
- Posts: 11349
- Joined: Mon Oct 06, 2003 3:41 pm
- Operating System Version (Optional): Windows 10
- Location: United Kingdom
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
-
- Posts: 2958
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
-
- Posts: 863
- Joined: Sun Aug 29, 2004 6:15 am
- Location: Sydney, Australia