implementation of talk window
- Nystul
- Posts: 1501
- Joined: Mon Mar 23, 2015 8:31 am
Re: started implementation of talk window
great! I owe you a lot. I am sure this will do the trick.
- Nystul
- Posts: 1501
- Joined: Mon Mar 23, 2015 8:31 am
Re: started implementation of talk window
the mechanism works now once quest npc has been placedInterkarma wrote: ↑Mon Apr 30, 2018 9:38 pm To find the location Person is assigned to (this should be fixed by commit in my previous post).Code: Select all
// Get Place a Person was assigned to by "place npc" - will be null if "place npc" not called by quest Symbol assignedPlaceSymbol = person.GetAssignedPlaceSymbol(); if (assignedPlaceSymbol != null) { Place assignedPlace = quest.GetPlace(assignedPlaceSymbol); // Gets actual place resource // From here, use assignedPlace.SiteDetails to get all the juicy info about that place }
since this can happen at any point in the quest I will have have to build the list again after place npc command was performed.
is it ok for you if I add a call (to inform the TalkManager) inside the PlaceNPC.cs class after SetAssignedPlaceSymbol() and before SetComplete() call?
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: started implementation of talk window
That's fine, as long as process is just a signal (like an event or setting a rebuild=true flag or something along those lines) and PlaceNpc isn't kicking off any actual talk window back-end logic.
- Nystul
- Posts: 1501
- Joined: Mon Mar 23, 2015 8:31 am
Re: started implementation of talk window
just a post for those who might be interested:
I am doing lots of testing with quest resources in conjunction with dialog right now. With latest patch for daggerfall btw.
Vanilla df is quite bugged in regards to this.
Have you ever realized, that all quest resources that are in the same location with the player are available for dialog even if the player has not learned about them? Both persons and places...
edit: ok tested with unpatched vanilla daggerfall version - this behaves different here: it is revealed correctly only after you learned through dialog about quest person target, places are still always available - INTERESTING
I consider this a bug and daggerfall unity will correctly just reveal them after player has learned about them through dialog or if quest adds them with "add dialog" command or as "dialog linked" resource
Furthermore if you are in the same building as the quest target and you ask about it under the "where is" section you will get wrong directions. It looks as if you get directed to a reference point in the building (not sure if it is a door or the center or whatever) but it rarely matches the direction of the target person...
Should we fix this behavior, if yes what would be the way to go?
I am doing lots of testing with quest resources in conjunction with dialog right now. With latest patch for daggerfall btw.
Vanilla df is quite bugged in regards to this.
Have you ever realized, that all quest resources that are in the same location with the player are available for dialog even if the player has not learned about them? Both persons and places...
edit: ok tested with unpatched vanilla daggerfall version - this behaves different here: it is revealed correctly only after you learned through dialog about quest person target, places are still always available - INTERESTING
I consider this a bug and daggerfall unity will correctly just reveal them after player has learned about them through dialog or if quest adds them with "add dialog" command or as "dialog linked" resource
Furthermore if you are in the same building as the quest target and you ask about it under the "where is" section you will get wrong directions. It looks as if you get directed to a reference point in the building (not sure if it is a door or the center or whatever) but it rarely matches the direction of the target person...
Should we fix this behavior, if yes what would be the way to go?
- correct compass direction
- a message like something "xyz is right here in this building, very nearby"
- a message like something "xyz is right here in this building, very nearby" + compass direction
-
- Posts: 177
- Joined: Sun Mar 22, 2015 9:52 am
Re: started implementation of talk window
I think it makes sense to fix it (it can be considered a bug IMO) and I would use option 2 or 3... 2 is perhaps more immersive, as it's strange to refer to cardinal directions inside a building, 3 is more practical.
- Nystul
- Posts: 1501
- Joined: Mon Mar 23, 2015 8:31 am
Re: started implementation of talk window
@Interkarma:
I am currently trying to implement to clear named residences from map after quest finished, but I fail in this case:
I load a previously saved game where pc is in an interior environment just before turning in a quest after fulfilling the objective
player is inside - so no exterior or streamingworld stuff has loaded/computed
failure inside function DiscoverBuilding in PlayerGPS because:
in invoked GetBuildingDiscoveryData function GameManager.Instance.StreamingWorld.GetCurrentBuildingDirectory() fails because currentPlayerLocationObject inside it is null (because no externals has been loaded)
this is tricky - how will we solve this? I would like to be able to modify discovery data also when player loads savegame pc in interior environment
I am currently trying to implement to clear named residences from map after quest finished, but I fail in this case:
I load a previously saved game where pc is in an interior environment just before turning in a quest after fulfilling the objective
player is inside - so no exterior or streamingworld stuff has loaded/computed
failure inside function DiscoverBuilding in PlayerGPS because:
in invoked GetBuildingDiscoveryData function GameManager.Instance.StreamingWorld.GetCurrentBuildingDirectory() fails because currentPlayerLocationObject inside it is null (because no externals has been loaded)
this is tricky - how will we solve this? I would like to be able to modify discovery data also when player loads savegame pc in interior environment
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: started implementation of talk window
Let me see what I can do. It's possible to load world when loading interior saves, but I might be able to do something else and retain the quick initial load.
- Nystul
- Posts: 1501
- Joined: Mon Mar 23, 2015 8:31 am
Re: started implementation of talk window
that would be awesome - thanks!
one possible solution might be a "to-undiscover-list" that is worked through as soon as one loads exterior?
so that one can mark a building via buildingkey and optional parameters like overridename and resetFlag (or something similar) by adding it to the list. Would be enough I think.
One more question:
currently it is possible to override a building's name with a custom name. What would be the correct mechanism to reset this regarding named residences (e.g. Masterdon Residence would be the override name and one should be able to reset it to just "Residence") - what would be possible right now is to set the override name in function PlayerGPS.DiscoverBuilding again to "Residence" (and thus getting it automatically hidden) which seems perfectly legit at first look but I don't like it too much because the mechanism is using insider knowledge (trusting that the name "Residence" will be used as internal mechanism to hide) - should this mechanism ever change - BOOM - everything breaks. I would like to have something like an additional optional parameter like bool "resetName" that will make the function change the name back to its internal default name... much cleaner in my opinion
one possible solution might be a "to-undiscover-list" that is worked through as soon as one loads exterior?
so that one can mark a building via buildingkey and optional parameters like overridename and resetFlag (or something similar) by adding it to the list. Would be enough I think.
One more question:
currently it is possible to override a building's name with a custom name. What would be the correct mechanism to reset this regarding named residences (e.g. Masterdon Residence would be the override name and one should be able to reset it to just "Residence") - what would be possible right now is to set the override name in function PlayerGPS.DiscoverBuilding again to "Residence" (and thus getting it automatically hidden) which seems perfectly legit at first look but I don't like it too much because the mechanism is using insider knowledge (trusting that the name "Residence" will be used as internal mechanism to hide) - should this mechanism ever change - BOOM - everything breaks. I would like to have something like an additional optional parameter like bool "resetName" that will make the function change the name back to its internal default name... much cleaner in my opinion
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: started implementation of talk window
It occurs to me this probably isn't the best way for us to do this. When it becomes possible to translate some of these default labels, the following code will break.
Code: Select all
// only create nameplates for buildings different than "Residence"
if (discoveredBuilding.displayName != "Residence")
newBuildingNameplate.name = discoveredBuilding.displayName;
Code: Select all
if (!IsResidence(discoveredBuilding.buildingType))
newBuildingNameplate.name = discoveredBuilding.displayName;
To expand on the above for quests. I'd prefer it if name plates are only shown for residences when involved in an active quest. Once the quest ends, the nameplate would be filtered out again. Can probably rework above to something like the following.
Code: Select all
// Only show nameplate if residence is involved in a quest
string buildingQuestName = GetBuildingQuestName(discoveredBuilding.buildingKey); // Returns string.Empty if building not involved in quest
if (IsResidence(discoveredBuilding.buildingType) && !string.IsNullOrEmpty(buildingQuestName))
newBuildingNameplate.name = buildingQuestName;
From a design point of view, I prefer active state to come in from active systems. Meaning the automap should be a consumer of state rather a provider of state. It shouldn't be making decisions about what buildings are called and when to reset names. It should just show what they're called by combining intelligence from other systems.
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: started implementation of talk window
Just on this, why do you need to call DiscoverBuilding() again? The building should have been added permanently to discovery data at the moment player entered it from the exterior. And the discovery data is always available from PlayerGPS even when loading a fresh interior save. There should not be any need to "rediscover" the building. This is all automatic.Nystul wrote: ↑Sat May 05, 2018 5:00 pm failure inside function DiscoverBuilding in PlayerGPS because:
in invoked GetBuildingDiscoveryData function GameManager.Instance.StreamingWorld.GetCurrentBuildingDirectory() fails because currentPlayerLocationObject inside it is null (because no externals has been loaded)
I might need more detail here, as I'm not sure we're solving the right problem. If this is a workaround to change names in the discovery system, that would be the wrong approach for the design. You should never need to modify the discovery state. My previous post has some other suggestions.