[0.11.0] Travel Map: Location names don't take WorldData overrides into account

Curated user bug reports with enough information to reproduce problem. Moderators will move topics here from Help & Support once a bug has been confirmed and enough information has been provided.
User avatar
XJDHDR
Posts: 158
Joined: Thu Jan 10, 2019 5:15 pm
Location: New Zealand
Contact:

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by XJDHDR »

Interkarma wrote: Sun Jan 31, 2021 10:27 pm All discovery is handled through PlayerGPS methods. The world data from MAPS.BSA, such as MapTable, have no bearing on player discovery.
I'm talking about the part of DFU that decides what to reveal on the map on starting the game, before the player has discovered anything. How does the game decide to show the player a location that their DiscoveryData has no entries for? Does it do so by looking at the location's Discovered boolean in the location's MapTable or though some other mechanism?
Interkarma wrote: Sun Jan 31, 2021 10:27 pm Most small crypts and graveyards are always visible from start of game, they don't need player to discover them.
And how does the game decide to show the player these places, as well as all the settlements, from the start? It doesn't do so by adding an entry for all of them to the DiscoveryData.

User avatar
Interkarma
Posts: 6133
Joined: Sun Mar 22, 2015 1:51 am

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Interkarma »

I see, I've misunderstood your question.

After quick review: a location will be revealed on map if present in DiscoveryData through normal play (e.g. exploration, maps, quests) or if the MapTable.Discovered flag is true in MAPS.BSA. The latter flag is cached by ContentReader.EnumerateMaps() at startup and doesn't use world data replacements.

To fix this for your needs, DaggerfallTravelMapWindow.checkLocationDiscovered() will need to query the world data override for that map pixel instead of checking summary.Discovered of cached maptable data. Or cached data will need to take overrides into account at startup. The second path is going to be harder as this caching happens before the mod system is active and assumes MAPS.BSA is read-only and immutable.

From the looks of it, the travel map UI doesn't use world data replacement helpers at all. Everything comes straight from MAPS.BSA. The travel map would need some refactoring to support this being changed by mods.

I'll move this one to bug reports for followup.

User avatar
Interkarma
Posts: 6133
Joined: Sun Mar 22, 2015 1:51 am

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Interkarma »

Getting the new name from world data replacement didn't seem hard, so I've added that feature now just to get ball rolling.

https://github.com/Interkarma/daggerfal ... 2c2463e80d

Testing with your sample data (thank you so much) now shows the modded name in travel map.

override1.jpg
override1.jpg (138.9 KiB) Viewed 186 times
override2.jpg
override2.jpg (158.5 KiB) Viewed 186 times

This has minimal overhead and only kicks in when a replacement location is available. I will of course bow to Hazelnut if he doesn't like how I did this and would prefer to handle another way. :)

It should be just as easy to add a check for MapTable.Disovered from world data replacement, but I'm a bit worried about the number of total checks while populating travel map. It's getting late here, so I'll look at this tomorrow.

User avatar
Interkarma
Posts: 6133
Joined: Sun Mar 22, 2015 1:51 am

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Interkarma »

I've posted a second fix for initial location visibility via MapTable.Discovered flag in world replacement data.

https://github.com/Interkarma/daggerfal ... d59515b481

This looks for available replacement data then falls back to cached MAPS.BSA data if none found. I was concerned about the number of times this check runs when populating "dots" on travel map, but it seems to have minimal overhead.

Welcome any feedback from the other devs on this one.

User avatar
Hazelnut
Posts: 2664
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Hazelnut »

As I said on the commit, it's all cached as long as not running in unity editor so it should be fine. Possibility of a small delay the first time opening a big region in travel map after starting DFU, but only on slow systems using a very slow disk or something, even then I'd not expect it to be much but I guess we will see if anyone notices.
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Interkarma
Posts: 6133
Joined: Sun Mar 22, 2015 1:51 am

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Interkarma »

Thank you for all your help Hazelnut (and for the excellent work on world data replacement). :D

I'd say this one can be marked resolved now for 0.11.1, unless XJDHDR spots any other gaps in travel map with world data replacement.

User avatar
XJDHDR
Posts: 158
Joined: Thu Jan 10, 2019 5:15 pm
Location: New Zealand
Contact:

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by XJDHDR »

Thanks for fixing these issues. My only remaining concern is whether there are other items in the MapTable that are hardcoded to be read from MAPS.BSA. Are RegionName, Latitude, Longitude and LocationType read from WorldData overrides or also hardcoded?

I haven't tested these or found a problem; just suggesting before someone potentially finds a problem.

User avatar
Interkarma
Posts: 6133
Joined: Sun Mar 22, 2015 1:51 am

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Interkarma »

The latitude/longitude are integral to world indexing, this would lean more into adding new locations or moving locations than just replacing existing data. I don't feel this is something I'd want to support without serious review, if ever.

Region names are hardcoded and immutable. There are methods that search for locations by name using strings for both region and location, so we need to be careful with this. While researching feasibility during initial localization rollout, I decided best not to touch region names for now. Region names are proper (fantasy) nouns in any case, and shouldn't require translation. There's a strong chance they will not enter localization.

However, locations might require translated names, or even just corrections like fixing "THe Crypts of Rhajom". I'm still considering how location names will be supported in localization framework, and how this will interact with world data replacements.

I'm more open to changing location type however. I think this will work well enough for purposes of travel map filtering and could be used to "convert" a location into something similar but different - e.g. convert a temple to a custom coven.

User avatar
XJDHDR
Posts: 158
Joined: Thu Jan 10, 2019 5:15 pm
Location: New Zealand
Contact:

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by XJDHDR »

Interkarma wrote: Tue Feb 02, 2021 2:00 am Region names are hardcoded and immutable. There are methods that search for locations by name using strings for both region and location, so we need to be careful with this. While researching feasibility during initial localization rollout, I decided best not to touch region names for now. Region names are proper (fantasy) nouns in any case, and shouldn't require translation. There's a strong chance they will not enter localization.
I'm not talking about renaming regions. I'm talking about the RegionName parameter on the 4th line of a location override. That said, now that I think about it, I'm not sure what the game would use this piece of data for in the first place. The region a location is found in is determined by the 3 character extension attached to the 4 MAPS.BSA records of each region. And according to the UESP, this parameter doesn't appear to be present in the original data. So is this just added by DFU for identification purposes?
Interkarma wrote: Tue Feb 02, 2021 2:00 am The latitude/longitude are integral to world indexing, this would lean more into adding new locations or moving locations than just replacing existing data. I don't feel this is something I'd want to support without serious review, if ever.
Okay, if it's not possible to move locations around then indeed, it makes no sense to support this on the travel map.
Interkarma wrote: Tue Feb 02, 2021 2:00 am However, locations might require translated names, or even just corrections like fixing "THe Crypts of Rhajom". I'm still considering how location names will be supported in localization framework, and how this will interact with world data replacements.
Bethesda's approach for Skyrim (and presumably Fallout 4) was to configure any user-facing strings in the game such that the data was not stored in the ESM/P but in STRINGS files that are different for each language. Similar to what you appear to be doing here. However, when a modder creates a mod that touches any of these strings, the link from the plugin data to those STRINGS is broken and the mod will set those strings to whatever they are for that modder's language. The modder can counteract this by creating their own STRINGS files for their mod's strings and provide their own translations.

Perhaps you could take a similar approach: Have WorldData overrides overwrite any localised strings DFU sets and make it the modder's responsibility to provide translations of their mods. You might then be able to provide a way of, say, letting players provide an INI, JSON or something with their mod that contains translated strings and then provide a way to define links to those translated entries in their WorldData overrides, scripts and whatever else.

User avatar
Interkarma
Posts: 6133
Joined: Sun Mar 22, 2015 1:51 am

Re: [0.11.0] Travel Map: Location names don't take WorldData overrides into account

Post by Interkarma »

XJDHDR wrote: Tue Feb 02, 2021 2:34 am So is this just added by DFU for identification purposes?
I believe region name is serialized only for easy identification in JSON file. Region name in world data replacement doesn't map back to anything in game that I'm aware of.

XJDHDR wrote: Tue Feb 02, 2021 2:34 am Perhaps you could take a similar approach: Have WorldData overrides overwrite any localised strings DFU sets and make it the modder's responsibility to provide translations of their mods. You might then be able to provide a way of, say, letting players provide an INI, JSON or something with their mod that contains translated strings and then provide a way to define links to those translated entries in their WorldData overrides, scripts and whatever else.
Thank you for feedback. We're thinking along the same lines and I want an order of precedence much like you describe. So MAPS.BSA location names are overridden by core localization string tables, which in turn are overridden by world replacement data from mods. Then it's the modder's responsibility to provide translated names for custom locations.

Considering world data replacement is already in JSON format, this could be extended to support location names by locale code. Here's a quick example of what I mean using Google translate and a totally made-up name for an imaginary location mod.

Code: Select all

"Name": "The Blight of Yhams",
"LocalizedNames": {
    "fr": "Le fléau de Yhams",
    "de": "Die Seuche von Yhams"
},
Then world data replacement reads in whichever name matches the active locale in localization system, or just uses the "Name" value if no localized name exists in JSON.

Of course, this is only required if a modder replaces some location and wants to support localized versions of that name.

Post Reply