LANGUAGE alias for Player.DisplayName?

[Ed the Bat]

I know this is a rather esoteric request, but I would imagine it's very simple to implement... Could the Player.DisplayName properties of the player classes in zdoom.pk3 be externalized to LANGUAGE? With this, one could rename the classes without actually defining a new actor by simply changing one LANGUAGE string. For instance, a project that gives the player a new story role could have him appear as something other than "Marine" in the player setup menu without having to make a new actor to replace him; a simpler way to add just a touch of flavor.

[wildweasel]

Or, foreign language translations of Hexen could translate Fighter/Cleric/Mage into their language's equivalents without redefining all three.

[Ed the Bat]

Excellent point; I forgot to even consider that.

[Graf Zahl]

Sadly not. Despite the term 'Displayname' this property is used for other purposes as well which should have been using the class name in the first place.
I'd really like to change this design bug, but that'd break pretty much any player mod out there.

[Ed the Bat]

What kind of things would break? I've successfully made player classes that reference a LANGUAGE string in their DisplayName, and didn't notice problems. What should I be looking out for?

[Graf Zahl]

The entire player class selection is done via display name. If that gets replaced by a LANGUAGE lookup it'd all fall apart.
I have no idea why Grubber implemented it this way as it's completely stupid.

[Ed the Bat]

I'll have to take your word for it, then... So would you recommend I not use LANGUAGE for my classes' names?

[Graf Zahl]

What precisely do you do?

[Ed the Bat]

I do just what I was hoping to see done to DoomPlayer (and the other internal player classes)
In LANGUAGE:

Code: Select all

[enu default]
MYPLAYERNAME="My Player";

In DECORATE:

Code: Select all

ACTOR NewPlayer : PlayerPawn
{
	Player.DisplayName "$MYPLAYERNAME"
	...
}

I've seen no problems so far, but if you know of something I should be looking for...

[Graf Zahl]

That's basically fine. The language lookup is only used in the menu.
The problem I was talking about is that I cannot retroactively change current player names because it'd break all mods out there, for the simple reason that some parts of the code use the 'display'-name for identification purposes - and expose this to some definition lumps!

[Ed the Bat]

Ah, I see. How disappointing...

[Arctangent]

Perhaps this could be better resolved by the addition of Player.NiceName or making Tag functional on player classes, which will override the name on the menu if defined? It's definitely kind of silly that that's a direction this would be required to take, but the simpler option is clearly unavailable due to poor implementation.

[Graf Zahl]

I think you are correct. The best option would probably be to officially deprecate the 'displayname' property, wrap all accesses into some functions, add a new property solely for display and use the class name in other places and the old 'displayname' only in the places where it's necessary but fall back to the class name if none is specified. But that'd require some serious thinking.

[Xaser]

I'd be all for such a change. It'd remove a persistent thorn for sure.

[Ed the Bat]

That would be just fine with me. I'd even retract my feature suggestion from last year to make Tag default to DisplayName, if it would be considered the new 'proper' method for nice names.