Allow shadowing: If not set, the game issues a warning if this variable has the same name, but different flags or type, as another variable in the same campaign.
Allow shadowing: If not set, the game issues a warning if this variable has the same name, but different flags or type, as another variable in the same campaign.
This makes little sense to me. Allowing variables to be shadowed leads to complications that are best avoided entirely.
"No idea what to call player-specific variables saved on accepting mission outcome; please suggest something."
"Campaign-persistent variables" would become "Progression variables" (tied to the campaign, saved when accepting the mission outcome).
That's why I (wrongly) assumed those would be kills and ranks since they're player specific, saved on mission outcome, and are not campaign specific.But they're not SEXP variables, so irrelevant to this conversation.
I'm also confused by MageKing's terminology, what's player-specific supposed to mean compared to player-persistent? How are those 2 even different? I know what a specific variable is in math terminology but I don't understand how it would apply here since you aren't solving any equations."Player-persistent" is the current name for what is actually still supposed to be a campaign variable. "Player-specific" is meant to be taken literally: a variable that is specific to the player (as opposed to being tied to the campaign).
... how far a long is this now?No work done, and we're still in a feature freeze so I have no real desire to start working on something this complicated right now.
I'm thinking of starting work on persistence for SEXP Containers. That means I need a decision to have been made on this. Personally I still like the idea of two names and a flag for whether it is eternal or not. We could also add a flag for techroom use if required.
In terms of backwards compatibility, I'd suggest that anything currently in the player file becomes an eternal variable. As soon as the next mission is played, the code should notice that the eternal flag is missing and remove the variable from the player file (writing it into the campaign file instead). This does mean that any campaign which is counting on the bug being present would break but given that this can easily be fixed (simply re-release the campaign file with the eternal flag ticked) and given that knossos makes it easy to distribute the fix, I think that's the best solution.
The campaign file is not intended to be updated if the player quits the mission without actually making progress in the campaign. Variables managed by the player are updated without regard to which campaign is being played or whether progress is being made, but variables managed by the campaign are only updated when the campaign advances.
Is this use case (variable is managed by the campaign but updated regardless of whether the campaign makes progress) actually necessary? Because none of the other campaign-managed data (events, goals, score, kills, etc.) works that way.
What if they were name-spaced by campaign within the player file?
I guess I don't understand how anything previously discussed would not have the same problem. Any change to how the vars are stored, such as where they're stored, would break old saves wouldn't it?