Allow setting static telephone name

[WheteThunger]

Currently, users can place static telephone entities at monuments, but they cannot control the names. We should add a command which allows them to update the name. Care should be given to what happens if there are multiple instances of the monument, since names might need to be unique (not sure). Also consider whether the names can be auto generated in some workable fashion like the vanilla phone names which use the grid coordinates.

[m-hynek]

Currently im working on some telephone plugin and it seems that only phone number has to be unique. PhoneController have helper method for generating grid coords from its location, so it should be easy to implement some naming automation. I'll take a look into it

[WheteThunger]

Cool, that's one less thing to worry about. I also confirmed in-game that I can give a player phone the same name as a monument phone, and both show up in the directory.

One thing we should at least think about is, when a player saves one of these phone numbers into their contacts, then the plugin reloads and respawns the entity, the phone number will probably have changed, meaning the existing contact entry will be stale. I think it's not a serious enough issue for now, but there are several ways we could address it in the future if anybody reports it as an issue.

• Disallow saving MA static phones in contacts
• Suggest that server owners enable the PersistEntitiesAfterUnload config option
• Store state in data files to remember the name chosen (probably complex)

[m-hynek]

var telephone = Entity as Telephone;
if (telephone != null && telephone.prefabID == 1009655496)
{
    var info = Monument.Object as MonumentInfo;
    if (info != null)
    {
        // add translated marker phrase to BaseMonument?
        var name = info.displayPhrase.translated;
        telephone.Controller.PhoneName = name;
        //if multiple monuments of same type present on map, add grid coord
        telephone.Controller.PhoneName = telephone.Controller.PhoneName + " " + PhoneController.PositionToGridCoord(telephone.Controller.baseEntity.transform.position);
        //if another static telephone is already present on monument (even vanilla one), add current count as another identifier
        telephone.Controller.PhoneName = telephone.Controller.PhoneName + "-2"; //number of statuc phones on monument

        TelephoneManager.RegisterTelephone(telephone.Controller);
    }
}

I hacked together this idea to automate telephone naming (PostEntitySpawn), but im not sure what methods are best to solve these comment conditions. Can you advice, if this approach makes sense to you? Ingame it works, public phone directory is updated after reaload so no stale contacts there. I wouldnt worry much about players adding public phones to contactlist, but preventing them to do so would (IMO) require new hook in TelephoneManager.Server_AddSavedNumber. PersistEntitiesAfterUnload seems like right way to solve this.

Edit: It doesnt work with underwaterlabs and freight transit line (I assume Monument.Object is not MonumentInfo for those)

[WheteThunger]

Great questions! There's certainly a lot to think about here.

add translated marker phrase to BaseMonument?

Yes, this is a reasonable start. Technically, I think the "translated" display phrase is always English (unless there is a server-side language setting). I don't know if the client does any sort of automatic translation of static phone names, but I'm guessing not, since if it did, that could create a problem where a client sees a Russian name, then types that in but the server can't find it.

If server owners want to customize the name, that can be achieved by implementing a command to set it. I don't see server owners realistically wanting to define multiple translations for a telephone's name, since that would produce the aforementioned problem.

if multiple monuments of same type present on map, add grid coord

This sounds reasonable. I vote we do this. Also, just something to think about is that some "monuments" may be dynamic, such as cargo ship (people could have multiple at once if they wanted to), also #17. We can probably start with the assumption that people won't be placing phones on dynamic monuments that will be duplicated, so we can ignore this concern for now.

if another static telephone is already present on monument (even vanilla one), add current count as another identifier

This one is tricky to make deterministic. Multiple profiles could add telephones to a monument. The profile load order would also influence the exact number of a given telephone. Telephones could also be despawned, so ideally you would want something to keep track of this state and adjust names retroactively. I vote that we don't bother with adding the number for now. We can always add it in the future if people are running into this case.

One thing we could think about for this longer term would be to implement a suffix based on a more precise location. For example, divide each grid square into a grid of its own, which would produce coordinates like N31-R2 and N31-D2.

It doesnt work with underwaterlabs and freight transit line (I assume Monument.Object is not MonumentInfo for those)

Good catch! I appreciate you testing thoroughly. Underground tunnels will be an instance of DungeonGridCell. While there are MonumentInfo objects that corresponds to each underwater lab, Monument Addons cares only about the DungeonBaseLink volume since those have deterministic layout (underwater labs as a whole do not). The DungeonBaseLink instance will have a reference to a DungeonBaseInfo. You could call GetComponent<MonumentInfo>() or GetComponentInParent<MonumentInfo>() on the DungeonBaseInfo object to see if you can find the MonumentInfo. If running GetComponentInParent, please benchmark with a stopwatch to make sure it's below 1ms cost.

As we're talking about underwater labs, I realize placing phones at them could significantly increase the likelihood of having multiple at one monument, since the module layouts can't really be predicted, so maybe we should think about the suffix some more.