Rule #42: Keep your variables to yourself

[I-am-Erk]

Is your feature request related to a problem? Please describe.

Implementation of character switching is going to aggravate a previously known issue with NPCs "knowing" you when you return as a new character. We now actually have most of the infrastructure to deal with this, and can solve it with what I hope is a slight modification of the dialogue variable system, followed by a less-slight-but-not-impossible review of use of variables throughout the dialogue code.

We currently track "npc_has_var" and "u_has_var". We use "u" as a form of global variable under the increasingly incorrect assumption that the user won't change, while "npc" is local and applies only in this conversation.

Solution you would like.

Rule 42: Keep your hands variables to yourself

We need a couple more versions of our existing variable functions:

fac_has_var: fac related variable functions would apply the variable to the player faction. Different new characters in the same world should have a different player faction, and so would not share these variables. However, NPCs within your faction would, so if you take over an NPC, they maintain this variable.

global_has_var: This replaces the common ill-advised use of u as a global variable. If you need multiple NPCs to react to a change, and that reaction should be persistent across playthroughs, use global.

party_has_var: This option would attach a u scale variable to only your current followers. This might be useful for something somewhat secret or minor that your character may not tell the whole faction about, but that anyone currently travelling with you would know. This is the least important of the three, but if we want to do it right we should still include it so that it can get integrated with the whole setup.

All these sets of functions should have the full set of variable operations including variable timers and mathematics. At least for now, we probably don't need a faction or global version of any other dialogue conditionals.

The new faction trust mechanic should be checked out, and we should make sure it applies to the player faction, not the individual character, and not to new characters in the same world. Overall, the major change involved in this whole thing is likely going to be having a distinct player faction that resets on death or on savegame switch. That said, I don't think that it's as important to make sure your newly created characters get a new faction as it is to make sure your followers know what they should, and don't know what they shouldn't.

Usage example.

• Party stored variable: Rubik mentions that they love watching different versions of Star Wars from different universes. Anyone with you at the time might remember this and bring it up, but it's not important enough that you would tell your whole faction about it.
• User stored variable: You brought Rubik a copy of Star Wars, and they love it and occasionally mention how grateful they are.
• NPC stored variable: You brought Rubik a copy of Star Wars, and they now occasionally quote from it. They have the movie, they'll quote from it no matter who visits the store.
• Faction stored variable: You've learned that Rubik will offer cybernetics to you, and so everyone in your faction should be able to go ask to become a cyborg from the Exodii or ask for installations, even if they weren't with you when you found that out for the first time.
• Global stored variable: You've helped the exodii scout out the local area, so multiple Exodii quest givers now have more local knowledge that increases the quests they can offer, regardless of if it's your original character, someone from the same faction, or a totally unrelated new person coming to visit.

Mission handling.

By default I think we should assume missions persist across the faction, but there are some missions (eg foodperson missions) that probably don't make sense that way.

Missions are a lot harder to code so I think we have to do this a different way. I would suggest one of:

1. "end_on_death" boolean in mission definition, default false. If the player character dies, this mission ends as failed. If false, this mission will remain active when the character switches. Of note, this mission will remain active if you switch characters.
2. "personal_mission" boolean, default false. I suspect this would be harder to code but I am not sure. If you switch characters, this mission is hidden both from the Mission display and from any checks such as u_has_mission. It only reactivates if your active character is again the person who took the mission. You cannot turn it in, get no dialogue related to it, etc. Just like end_on_death the mission cancels as failed if the original taker dies.

If personal mission is achievable, we may not need end_on_death.

Describe alternatives you have considered.

We could probably do something with flags on the variables themselves to indicate if they should persist after character death or not, but I think that makes an already very verbose system into a nightmare with no real usability help.

Additional context

At some point we may want to look into things like party_has_skill and things to assess if anyone in your faction has a particular skill or attribute, facilitating party-based play by letting your followers pipe up if they know something, but I think that can wait a lot longer. Likewise, party_add_effect to apply a specific effect to all your current followers and a few similar things would be neat.

[Ramza13]

So global vars totally exist at the moment and can do timers and math and anything u vars can. Right now Portal Storms are the only thing using them I think but at some point migrating over older code is doable.

The other two could basically be copies of global vars with an extra map to store multiple versions worth. Half tempted to use this as an excuse to shrink dialog var names from needing 3 parts at the same time.

[I-am-Erk]

Half tempted to use this as an excuse to shrink dialog var names from needing 3 parts at the same time.

Please do. The current fields should be optional. It drives me mad. We could just have them default to "default" if not filled for example.

[PatrikLundell]

Many "personal" missions ought to be possible to be given to multiple characters, with whoever finishes the mission first clearing the mission for all of them. It doesn't make sense that I'd refuse to give the mission to kill the jabberwock to anyone but a single person, as I'm probably mostly interested in killing that critter dead. There might be some cases where there's some "honor" involved (e.g. vs a betrothed, should that become a possible relation) that might allow someone to keep trying until giving up or dying and only then hand it over to someone else, but that's probably an exception.
If the same mission can be given to multiple people, there's probably a need to separate mission states into a quest giver part and a quester part to allow the questers to progress to different degrees in parallel.

[I-am-Erk]

That's mainly a separate issue. I'm trying to avoid delving too far into missions here because that code is a mess and a half