Assign Quest Journal ID at runtime

[DeidreReay]

Trying to find some examples but its escaping me a bit. Here some thought on what I am trying to do and reasoning(Hopefully makes sense).

1.) Multiplayer game. Everything for the most part is working except quests from clients. They somewhat work but think I know why.
2.) All of their Quest Journal ID names are the same PLAYER... So hoping if i can assign those at runtime they then would be different and allow the rest of the systems to work correctly. (Let me know if anything else is also maybe missing)

So in short is there an example or could you shed some light on getting these IDS assigned at runtime. Also if anything else is blaring going to need to be done to have multiple players doing quests, saving, reloading etc. Thank you as always.

[Tony Li]

Hi,

To assign an ID at runtime, unregister the QuestJournal, set the id property, then re-register it. Example:

Code: Select all

var journal = GetComponent<QuestJournal>();
QuestMachine.UnregisterQuestListContainer(journal);
journal.id = new StringField("Player 2");
QuestMachine.RegisterQuestListContainer(journal);

[DeidreReay]

That worked perfectly with a little fumbling around to get our Player chosen names. One last question hopefully.

We are using dialogue system and quest machine integrated together. How can we use the newly set Journal.id String name or the Journal.display name as our Actor name in conversation? Is this possible ? Figured if so may be the simplest solution as we already now have those set up correctly with Player Created names. Also if there is an easier way we are missing to get correct names shown instead of Player for all dialogue would be much appreciated.

[Tony Li]

Hi,

Add a DialogueActor component to the player GameObject, and set its actor property to the same name. Example:

Code: Select all

GetComponent<DialogueActor>().actor = journal.id.value;

[DeidreReay]

That worked and can see the field there gets filled in. Still during dialogues with NPCS it is showing PLAYER when the player is speaking (compared to I had hoped it would change to their chosen name). Can you think of any settings to check to make that possible?

[Tony Li]

Make sure the conversations use the correct player GameObject. This way it will get the player name from the GameObject's DialogueActor component. If you use C# to start the conversation, pass the correct player GameObject to it. Example:

Code: Select all

DialogueManager.StartConversation("Title", specificPlayerGameObject.transform, npc.transform);

If you use a Dialogue System Trigger, leave the Actions > Start Conversation > Conversation Actor field unassigned. If it's triggered by OnUse or OnTrigger/Collision, it will use the GameObject that triggered it (i.e., the player).

[DeidreReay]

That seemed to work in single player. Initial test for multiplayer did not work. The client that joineed in "Player 2" name was then working, but it named the initial player "Player 1" also "Player 2". Can you think of anything to check that might be causing that to happen or perhaps had others with similar issues?

[Tony Li]

Are you using a server-side RPC that you intend to target just to player 2 but is perhaps being handled by all players?

If you inspect player 1's and player 2's Quest Journal components, are their IDs correct?

The AI Questers Tutorial isn't multiplayer per se, but it does demonstrate how to have multiple characters with their own Quest Journals. It might be helpful.

[DeidreReay]

Yeah. Been testing around and thinking I might need to clarify a few things and look at what can be done. So lets try to reestablish current scenario.
~ Using Mirror Networking newest version.
~ Quest Machine, Dialogue System, Invector integrations
~ Server authority using mirror etc

So looking at a few things and thinking on it.
1.) Should there only be 1 Global Dialogue and Quest Machine Manager on the server (Host)?(Right now we have them placed in scene which in theory would have clients all having their own managers. Which seems like would cause issues?)

2.) If so are there examples for a scenario that has that sort of a setup.

3.) Per you last response. I believe that there are multiple managers would be causing the issues compared to one global setup and RPCS or commands to send or update that manager with and when clients are added etc.

4.) Let me know if I am way off here just seems we are close and certainly want to use these assets as they are amazing, but really cant seem to think through how this should work.

[Tony Li]

I recommend running the Quest Machine and Dialogue Manager GameObjects locally on each client. Even MMOs keep their dialogue content local instead of sending every line down from the server.

Technically only the client's local player needs a Quest Journal component. You can either add it when the player connects or, if the player prefab has a Quest Journal component, use an RPC call to set the new player's GameObject to the same ID (e.g., "Player 2") on all clients.

For any operations that need server authority, write network-enabled custom quest actions and quest conditions. To do this, duplicate QuestActionTemplate.cs and/or QuestConditionTemplate.cs and fill in the code where the comments indicate.

Each client will have their own Dialogue System environment, too, including Lua variables. So if you use a DS variable to record that the player has talked to a specific NPC, that variable will be in the player's Lua environment. To save the Lua variables to the server, call PersistentDataManager.GetSaveData() to store the variable data in a string.

If you want to keep some Dialogue System Lua variables synced across players, use the Lua Network Commands. The script is written for UNET, so you can just replace "Unity.Networking" with "Mirror".