The display_name property from shipdata.plist and shipdata-overrides.plist does not work

[Simba]

https://wiki.alioth.net/index.php/Shipd ... splay_name

When I try to write my own value in the display_name property, the names of the ships on F3 and in the save description remain the same as in the name property. I checked both on 1.90 and on the latest version 1.91.

[another_commander]

display_name works for me on 1.91

[Simba]

display_name works for me on 1.91

It doesn't work for me, it doesn't work for Krager either. Can you start a new game and see how it works there? And can you also show me what your shipdata-overrides.plist looks like?

[another_commander]

Starting a new game works fine and the shipdata-overrides can be something as simple as

Code: Select all

{
	"cobra3-player" =
	{
		display_name = "Yarrrrrr!!";
	};
}

Throw this shipdata-overrides.plist inside a Config folder in AddOns and that should do it.

[Simba]

cobra3-player

Wait, the bug is that the display_name property is not inherited when using like_ship. I've been trying to change it in oolite_template_adder and oolite_template_cobra3 all this time, expecting all template inheritors to get the new value the same way.

[another_commander]

I am not sure it is a bug. OOShipRegistry.m in the source code contains the following inside the - (NSMutableDictionary *) mergeShip:(NSDictionary *)child withParent:(NSDictionary *)parent method:

Code: Select all

// Certain properties cannot be inherited.
if ([child oo_stringForKey:@"display_name"] == nil)  [result removeObjectForKey:@"display_name"];
if ([child oo_stringForKey:@"is_template"] == nil)  [result removeObjectForKey:@"is_template"];x

The above two keys are forcibly removed from ship dictionaries when resolving like_shiip.

This code was inserted by Jens, one of our principal maintainers, more than 16 years ago. I cannot tell or even remember why display_name should not be inherited (unlike is_template, which obviously shouldn't be), but I do know that if Jens excluded it, there is probably a good reason for it.

There is still a chance that this restriction could be lifted without harmful results, but it should be done only after very careful consideration and testing. Oolite's code is mature after all these years in development, very much so in fact. When it comes to gameplay and general internal structure, there is very little that's left to chance or without extensive playtest. However, if anyone can recall exactly why display_name should not be inherited please give us a shout here.

My recommendation would be to compile the game without the above display_name restriction and test it a lot. If tests don't uncover any breakage, consideration could be given in making the change officially, but remember, it's Jens who put this in, so be very, very sure if you decide to go ahead and change it.

[Wildeblood]

I am not sure it is a bug. OOShipRegistry.m in the source code contains the following inside the - (NSMutableDictionary *) mergeShip:(NSDictionary *)child withParent:(NSDictionary *)parent method:

Code: Select all

// Certain properties cannot be inherited.
if ([child oo_stringForKey:@"display_name"] == nil)  [result removeObjectForKey:@"display_name"];
if ([child oo_stringForKey:@"is_template"] == nil)  [result removeObjectForKey:@"is_template"];x

The above two keys are forcibly removed from ship dictionaries when resolving like_shiip.

This code was inserted by Jens, one of our principal maintainers, more than 16 years ago. I cannot tell or even remember why display_name should not be inherited (unlike is_template, which obviously shouldn't be), but I do know that if Jens excluded it, there is probably a good reason for it.

I thought display_name in shipdata was... I can't find the exact word, redundant, maybe.
I thought displayName on a ship object was created from shipClassName + shipUniqueName (possibly via some rule in descriptions.plist).

[another_commander]

I thought display_name in shipdata was... I can't find the exact word, redundant, maybe.
I thought displayName on a ship object was created from shipClassName + shipUniqueName (possibly via some rule in descriptions.plist).

I honestly cannot remember if, how and when this happened, but display_name in shipdata is definitely still a thing.

-

For those who want to test the change, I have uploaded a test executable here.

[Simba]

I thought display_name in shipdata was... I can't find the exact word, redundant, maybe.
I thought displayName on a ship object was created from shipClassName + shipUniqueName (possibly via some rule in descriptions.plist).

https://wiki.alioth.net/index.php/Shipd ... splay_name
According to the wiki, this field exists for localization and by default contains a value from name.

This code was inserted by Jens, one of our principal maintainers, more than 16 years ago. I cannot tell or even remember why display_name should not be inherited (unlike is_template, which obviously shouldn't be), but I do know that if Jens excluded it, there is probably a good reason for it.

I think I understand the reason. Suppose there is a template A in shipdata and a template B inheriting it. Template A has a name field (so display_name contains the same value), and template B also has a name field. In this case it is necessary that the display_name field of the ship created on the basis of template B should be overridden as well. And this should happen even if the display_name field was explicitly specified in template A. But the scenario was not envisioned in which the name field is not specified in template B (and display_name too), i.e. it does not imply a change of the ship's name relative to template A.