Yeah ECWolf's implementation of DECORATE is from scratch and doesn't have the renaming code. IIRC ZDoom didn't have it at the time I started either. (Zandronum did and of course many people there used it as a feature instead of a compatibility crutch. Yay no need to think up a unique name! ) If it will ever get depends, but since the 1.x series of ECWolf doesn't promise backwards compatibility it's not exactly needed.

Yeah ECWolf's implementation of DECORATE is from scratch and doesn't have the renaming code. IIRC ZDoom didn't have it at the time I started either. (Zandronum did and of course many people there used it as a feature instead of a compatibility crutch. Yay no need to think up a unique name! :P) If it will ever get depends, but since the 1.x series of ECWolf doesn't promise backwards compatibility it's not exactly needed.

That gets generated when a mod defines an actor called "Zombieman" in DECORATE and it clashes with the existing actor. So, what I was asking about was what would happen if a mod had DECORATE like this:

But that is GZDoom and this is ECWolf, but it was the post here that retriggered a question that I'd had bubbling away in the back of my head for some time but had basically forgotten about.

Anyway, sorry for the distraction, back to actual ECWolf stuff and CeeJay's hi-res/enhancement patch...

Apologies for the huge image but, in this case, that's kind of the point. [Thank goodness that Rachael installed that cool mod for shrinking pictures]

Further to the above, I think that I was trying to establish was actually prompted by messages that I'd seen in GZDoom with some mods. e.g.

[code]Script warning, "decorate.txt:DECORATE" line 1:Tried to define class 'Zombieman' more than once. Renaming class to 'Zombieman@decorate.txt@DECORATE'[/code]

That gets generated when a mod defines an actor called "Zombieman" in DECORATE and it clashes with the existing actor. So, what I was asking about was what would happen if a mod had DECORATE like this:

[code]ACTOR Zombieman : Shotgunguy{}

ACTOR Zombieman@decorate.txt@DECORATE : Chaingunguy{}[/code]

unlikely I know but the answer is:

[code]Script warning, "decorate.txt:DECORATE" line 1:Tried to define class 'Zombieman' more than once. Renaming class to 'Zombieman@decorate.txt@DECORATE'Script warning, "decorate.txt:DECORATE" line 4:Tried to define class 'Zombieman@decorate.txt@DECORATE' more than once. Renaming class to 'Zombieman@decorate.txt@DECORATE@decorate.txt@DECORATE'[/code]

But that is GZDoom and this is ECWolf, but it was the post here that retriggered a question that I'd had bubbling away in the back of my head for some time but had basically forgotten about.

Anyway, sorry for the distraction, back to actual ECWolf stuff and CeeJay's hi-res/enhancement patch... :bfg:

Apologies for the huge image but, in this case, that's kind of the point. [Thank goodness that Rachael installed that cool mod for shrinking pictures]

So I think I need to answer that question the wrong way first to actually have the answer make sense since I think your curiosity is rooted in something that isn't happening:

There's no renaming going on here, it's just replaces as you know it from ZDoom. The only thing that's changing is ECWolf 1.4 is getting rid of editor numbers so all internal tables reference actors by names. (Editor numbers were just a Doomism I copied for no real reason.) So before there was a mapping that said spawn actor 60 where tile <X> was used. ECWolf 1.3 would on map load lookup what 60 was and spawn it. Since the mod overwrite what was at table entry 60 it would spawn the right thing even though you're not supposed to replace things like that. With 1.4 it's now spawn MachineGun where tile <X> was used. So at map load it would spawn the original MachineGun. Even though the editor number table was updated to point to NewMachineGun it's just no longer using that table to load a map. Thus for the 1.3 -> 1.4 transition I've added compatibility which turns editor number replacement into a proper replaces clause. If the actor uses both an editor number and replaces then it does nothing and the mod breaks.

But your question was hypothetical, so the answer is ECWolf doesn't rename anything. It would just throw an error when it sees the second NewMachineGun definition and tell the user to resolve the conflict. Like with ZDoom stacking mods is not really a supported thing.

If that doesn't clear it up I really don't follow your question.

So I think I need to answer that question the wrong way first to actually have the answer make sense since I think your curiosity is rooted in something that isn't happening:

There's no renaming going on here, it's just replaces as you know it from ZDoom. The only thing that's changing is ECWolf 1.4 is getting rid of editor numbers so all internal tables reference actors by names. (Editor numbers were just a Doomism I copied for no real reason.) So before there was a mapping that said spawn actor 60 where tile <X> was used. ECWolf 1.3 would on map load lookup what 60 was and spawn it. Since the mod overwrite what was at table entry 60 it would spawn the right thing even though you're not supposed to replace things like that. With 1.4 it's now spawn MachineGun where tile <X> was used. So at map load it would spawn the original MachineGun. Even though the editor number table was updated to point to NewMachineGun it's just no longer using that table to load a map. Thus for the 1.3 -> 1.4 transition I've added compatibility which turns editor number replacement into a proper replaces clause. If the actor uses both an editor number and replaces then it does nothing and the mod breaks.

But your question was hypothetical, so the answer is ECWolf doesn't rename anything. It would just throw an error when it sees the second NewMachineGun definition and tell the user to resolve the conflict. Like with ZDoom stacking mods is not really a supported thing.

What I meant was, if the mod contains an actor that ECWolf needs to auto-rename to something, but the name that ECWolf wants to rename that actor to already exists, what does ECWolf do?

e.g. in this case "MachineGun" is being renamed to "NewMachineGun" but it's easy to imagine a mod that contains a regular replacement for the machine gun and an additional new super-fantastic weapon called "NewMachineGun". So what happens if ECWolf tries to rename "MachineGun" to "NewMachineGun" but finds that the mod already contains another actor called "NewMachineGun"? i.e.the name slot is already taken by another weapon in the mod. What would ECWolf do then?

I assume that it just picks an alternative new name but the question just intrigued me.

What I meant was, if the mod contains an actor that ECWolf needs to auto-rename to something, but the name that ECWolf wants to rename that actor to already exists, what does ECWolf do?

e.g. in this case "MachineGun" is being renamed to "NewMachineGun" but it's easy to imagine a mod that contains a regular replacement for the machine gun and an additional new super-fantastic weapon called "NewMachineGun". So what happens if ECWolf tries to rename "MachineGun" to "NewMachineGun" but finds that the mod already contains another actor called "NewMachineGun"? i.e.the name slot is already taken by another weapon in the mod. What would ECWolf do then?

I assume that it just picks an alternative new name but the question just intrigued me.

Enjay wrote:Purely out if interest, if the mod also already contained a weapon called "NewMachineGun", what would ECWolf do then?

Not sure I follow the question, but if two actors have the same names ECWolf will throw an error.

[quote="Enjay"]Purely out if interest, if the mod also already contained a weapon called "NewMachineGun", what would ECWolf do then?[/quote]Not sure I follow the question, but if two actors have the same names ECWolf will throw an error.

Cleveland Rock wrote:Edit: It seems the bug only happens when you pick up a machine gun that was not dropped by an enemy. The easiest way to replicate the bug is with the hidden machine gun in the very first level.

decorate.txt:94:33:Warning: 'NewMachineGun' overwrites deprecated editor number 60 previously assigned to 'MachineGun'. This mod will soon break if not changed to 'replaces'!
decorate.txt:94:33:Warning: Deprecated use of editor number for class 'NewMachineGun'.

[quote="Cleveland Rock"]Edit: It seems the bug only happens when you pick up a machine gun that was [b]not[/b] dropped by an enemy. The easiest way to replicate the bug is with the hidden machine gun in the very first level.[/quote]Finally got to look at this issue and it's a bug in the mod:[code]decorate.txt:94:33:Warning: Overwriting editor number 60 previously assigned to 'MachineGun', use replaces instead.[/code]Added emulation for this error in ECWolf 1.4 and added more warnings.[code]decorate.txt:94:33:Warning: 'NewMachineGun' overwrites deprecated editor number 60 previously assigned to 'MachineGun'. This mod will soon break if not changed to 'replaces'!decorate.txt:94:33:Warning: Deprecated use of editor number for class 'NewMachineGun'.[/code]

I will say that the texture issue is not your problem. The weapon switching thing I haven't looked into yet, but I would assume it's my problem at this point. (In other words, even though I don't promise backwards compatibility until after 2.0 do assume compat issues are bugs unless I say otherwise.)

I will say that the texture issue is not your problem. The weapon switching thing I haven't looked into yet, but I would assume it's my problem at this point. (In other words, even though I don't promise backwards compatibility until after 2.0 do assume compat issues are bugs unless I say otherwise.)