Replacing MENUDEF class with ZScript class fails

[AFADoomer]

For menus that are defined in MENUDEF with a 'Class' value set (e.g., PlayerMenu), re-defining the Class value to use a ZScript class always fails.

Sample can be downloaded here.

MENUDEF entry:

Code: Select all

ListMenu "PlayerMenu"
{
  <<snip copy/paste of the standard PlayerMenu info>>

	Class "NewPlayerMenu"
}

This throws an error:

Code: Select all

Script error, "PlayerMenu.pk7:menudef.txt" line 28:
Tried to replace menu 'Playermenu' with a menu of different type

The class that I am trying to replace "PlayerMenu" with in MENUDEF is "NewPlayerMenu", which is a direct inherited copy of "PlayerMenu":

Code: Select all

class NewPlayerMenu : PlayerMenu {}

Creating a new, identical menu using the new class but a different menu name works fine ("openmenu test" in console will open a copy of the player menu that is fully functional).

[Major Cooke]

Last I checked, it's fully intentional. You have to rename it to something else in order to get it to work. Not just the class, you have to rename the menudef definition too.

[AFADoomer]

Just because there's a workaround doesn't mean it's right...

The MENUDEF parsing code specifically has handling to check if the replacing class is compatible with the old class - The problem is that it does a direct comparison of class types instead of a IsDescendantOf-type check, so the class has to have the same name... Which makes the whole class replacing code pointless.

[Major Cooke]

I meant, you cannot just replace the playermenu for certain technical reasons. It's a matter of protecting certain internal things to prevent exploits. Graf will not expose those things, thus being forced to rely upon having a class invoked and nailing the PlayerMenu to the reserved list.

So you don't exactly have any choice in that matter from the looks of things.

[AFADoomer]

Nothing is protected. There are no technical reasons.

I can make an identical and fully functional player menu by copy/pasting the ZScript definition and renaming it and copy/pasting the MENUDEF entry and replacing it. ('openmenu test' in the console with the file I linked).

[Major Cooke]

Nothing is protected. There are no technical reasons.

Code: Select all

	// All write function for the player config are native to prevent abuse.
	protected native void AutoaimChanged(float val);
	protected native void TeamChanged(int val);
	protected native void AlwaysRunChanged(int val);
	protected native void GenderChanged(int val);
	protected native void SwitchOnPickupChanged(int val);
	protected native void ColorChanged(int red, int green, int blue);
	protected native void ColorSetChanged(int red);
	protected native void PlayerNameChanged(String name);
	protected native void SkinChanged (int val);
	protected native void ClassChanged(int sel, PlayerClass cls);

I beg to differ.

[AFADoomer]

So I have to inherit from PlayerMenu to use those. Yay.

[Major Cooke]

And I believe that's also part of the reason why he put a class under it and thus nailed it to the menus already defined first. I don't remember how many other menus had a Class definition added to them in menudef.txt but because of it, it cannot be replaced at all.

But it wouldn't be the first time Graf corrected me for my theory being completely off.

[AFADoomer]

Maybe 'protected' items aren't intended to be executable outside of the gzdoom.pk3 block of ZScript, and something's not fully implemented? But there's certainly nothing keeping my copied and inherited player config menu from working.

The whole Class thing in MENUDEF was original to the first MENUDEF implementation, when the classes were defined in compiled code (so, at least 7 years ago, based on GitHub. I'm old.)... I think the non-replaceable bit only is supposed to apply to the engine-generated content of the menus - episodes, skills, etc. But, yeah, we both could be wrong. Or just me.

[Graf Zahl]

Just because there's a workaround doesn't mean it's right...

Correct. such a replacement should work,

[_mental_]

Is CheckCompatible() correct? It compares menu classes which will be different for sure in case of replacement.

[Graf Zahl]

This should have used 'IsDescendantOf' instead of checking for equality.

[_mental_]

Fixed in 7a29128.

[Major Cooke]

I'm glad I was wrong.