implementation of talk window

Discuss coding questions, pull requests, and implementation details.
Post Reply
User avatar
Nystul
Posts: 1501
Joined: Mon Mar 23, 2015 8:31 am

Re: started implementation of talk window

Post by Nystul »

great! I owe you a lot. I am sure this will do the trick. ;)

User avatar
Nystul
Posts: 1501
Joined: Mon Mar 23, 2015 8:31 am

Re: started implementation of talk window

Post by Nystul »

Interkarma 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
}
the mechanism works now once quest npc has been placed
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?

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

Re: started implementation of talk window

Post by Interkarma »

Nystul wrote: Tue May 01, 2018 1:52 pm 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?
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. :)

User avatar
Nystul
Posts: 1501
Joined: Mon Mar 23, 2015 8:31 am

Re: started implementation of talk window

Post by Nystul »

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?
  • 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
I further managed to make a quest person disappear from the list after it was there already, could not reproduce this again though

Al-Khwarizmi
Posts: 177
Joined: Sun Mar 22, 2015 9:52 am

Re: started implementation of talk window

Post by Al-Khwarizmi »

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.

User avatar
Nystul
Posts: 1501
Joined: Mon Mar 23, 2015 8:31 am

Re: started implementation of talk window

Post by Nystul »

@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 :)

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

Re: started implementation of talk window

Post by Interkarma »

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.

User avatar
Nystul
Posts: 1501
Joined: Mon Mar 23, 2015 8:31 am

Re: started implementation of talk window

Post by Nystul »

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

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

Re: started implementation of talk window

Post by Interkarma »

Nystul wrote: Sat May 05, 2018 9:24 pm (trusting that the name "Residence" will be used as internal mechanism to hide)
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;
I'd prefer it if the residence was filtered in the following way:

Code: Select all

if (!IsResidence(discoveredBuilding.buildingType))
	newBuildingNameplate.name = discoveredBuilding.displayName;
In the above, the new method IsResidence() would check discoveredBuilding.buildingType and return true if building is one of the known residence types. This is much more data-stable than just checking for text string "Residence".

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;
That way it should not be necessary to do any resetting of name plates. It will inherit name directly from quest only when a quest is operating on that residence, and otherwise not show anything for simple residences not involved in any quest work currently. I can help create an efficient means of retrieving quest name from buildingKey if needed.

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.

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

Re: started implementation of talk window

Post by Interkarma »

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)
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.

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. :)

Post Reply