Character Sheet Locking in Savage Worlds

[Mike Serfass]

Today's release of Savage Worlds updates include character sheet locking from CoreRPG.
On player character sheets is a new lock icon. It's in the top menu bar in the right hand grouping.
Here's how it works.

Character sheets can be locked and unlocked by players and the GM.
The lock is shared, so if a player locks a character, it's locked for the GM and vice versa.
The GM cannot lock a character sheet in a way that prevents players from unlocking it, and vice-versa.

This does not lock everything. You can still drop bennies on dice, double click dice, and drag dice from the character sheet.
Commonly used fields are not locked. That includes

current power points
ammo
inventory counts
equip/unequip/carry buttons
currency
conviction
Wounds
Fatigue



Things that are locked include

dropping new records (items/edges/powers/attacks/etc) on lists
changing Trait dice
radial buttons that add or delete records



The purpose of this feature is to prevent accidentally updating max fields instead of current fields, changing dice and counts, and changing text when you type thinking you're in chat or a different window.
Locking will help prevent accidentally dragging the wrong thing, or grabbing the wrong item on the character sheet.
It also makes it easier to move and resize the character sheet.

Some things to note.
When the session starts, all character sheets are (re)locked. If you left the character sheet unlocked before ending the game, it will be locked next session.
This is done by CoreRPG, and isn't optional.

This is meant to be a convenience feature.
If there are fields that are changed frequently that require unlocking, please let me know. I can change what's locked.
(The notes tab is one I wasn't sure about locking. I included it because it's a large text field and is often accidentally typed in.)
Try it out for a bit then post what you think about this feature. Does it help? Does it get in the way? Do you want the GM to have the ability to override the player's lock?

[HywelPhillips]

I can pretty much guarantee that locking sheets that were left unlocked last session is going to be a pain in the posterior. It goes against the new paradigm of allowing open windows to re-open next time by ignoring a player's preferred state for their main interface with the game, their character sheet. I think that one should be punted back up to SW for reconsideration at the CoreRPG level.

I'm not running sessions this week as I am away, but I'll see how much it throws my players and report back.

It sounds like Mike has at least made sensible choices of what things should be locked i.e. not very many of them.

Cheers, Hywel

[Lonewolf]

I can pretty much guarantee that locking sheets that were left unlocked last session is going to be a pain in the posterior. It goes against the new paradigm of allowing open windows to re-open next time by ignoring a player's preferred state for their main interface with the game, their character sheet.

You are confusing two different things here. Record locking the data in the character sheet has got nothing to do with the window state of that character sheet.

[HywelPhillips]

I don't believe I am confusing two different things. It's a minor point admittedly, but it has to do with the "model" underlying these minor choices.

Fantasy Grounds traditionally has had a non-persistent state for UI between sessions. Game state is (almost entirely) persistent between sessions - it remembers the combat tracker, the map, where all the tokens are, who has what cards, effects, etc..

Where something goes against this underlying model (I believe the lack of persistency of fog of war explored areas on maps is an example), it confounds people's expectations and they get confused - and indeed ask for extensions to make the behaviour consistent with the underlying model.

Saving window positions between sessions (and making that the default now) changes the underlying model from "UI state does not persist between sessions" to "UI state does persist between sessions" - because most of the user's UI choices like which windows are open and where they are on the screen are now preserved between sessions.

User confusion occurs if specific bits of the program don't follow the suggested underlying model.

In this case, if there is a major toggle to do with how you interact with the main player UI window - their character sheet - it messes with the "UI is persistent" model and will mean it's something people repeatedly will forget when they rejoin a game.

At least the lock icon glows a nice red in the default style, so they can hopefully spot it for themselves, but I am willing to bet that I am going to have to keep reminding people why it is that they can't drag-and-drop a new edge or an increase in trait dice, because the behaviour of this particular bit of UI is non-persistent and has defaulted to a new and unexpected behaviour.

(I'd argue that for consistency the character sheet should re-open on whatever tab the player already had open at the end of the last session, but at least players are used to clicking between tabs freely).

Suddenly not being able to enter notes until you've unlocked the sheet, and having the sheet reset every time to locked is just confounding the underlying "UI window states are persistent" model. Individual players will have their own preference for whether the sheet should be locked or unlocked, and IMO the UI should preserve their choice in line with the "state of windows is persistent between sessions" model that is now the default behaviour for FGU.

Recent changes have all being going in the direction of making "UI is persistent" the model under which FGU works - for example automatic reconnection of owned characters. This change is notable in going the opposite way, which is why I think it is a mistake. I think sheet state should be persistent between sessions to as great an extent as possible for consistency with the underlying UI model, and that the lock state of the sheet should be remembered per-character-sheet between sessions.

Doubly so because it is overloading behaviour already present for NPCs which can be locked or unlocked - using the same icons and UI to do so - and their state does persist between sessions. So the behaviour of the character sheet lock is doubly inconsistent.

Cheers, Hywel Phillips

[Moon Wizard]

This is by design at the CoreRPG level, not specific to SW.
By returning records to a locked state by default; this prevents accidental changes in a new session, as inexperienced players often leave things half-cooked.
I've actually been thinking about making this a standard for all record types.

Regards,
JPG

[zarlor]

I'm with Hywell on this, honestly. Just because some new players have issues doesn't mean everyone else should deal with something that doesn't follow the rest of the persistence standards we are used to. By leaving it persistent you leave it in the hands of the players and GM to either lock or unlock the sheets. The risk of leaving them unlocked seems to me to be outweighed by having the environment be consistent with the state you last left it in. Perhaps a setting for re-locking (on by default if that seems appropriate) the sheets would be a good compromise, or some way for a GM to decide on the locking and unlocking of all character sheets at once?

[Jiminimonka]

I tried this (in SWADE) last night and it seemed fine.

Having the lock default to locked might become annoying, I agree, but it is too soon to know. Maps snap to grid turning itself on IS annoying..

[Mike Serfass]

Would it help if I made (un)locking the charsheet a benny drop for the GM? Each time the GM locks or unlocks the charsheet, that player gets a benny.
Let the bennies flow!

[Jiminimonka]

Would it help if I made (un)locking the charsheet a benny drop for the GM? Each time the GM locks or unlocks the charsheet, that player gets a benny.
Let the bennies flow!

Have it as an option except for Doswelk. Everyone gets Bennies except him when he GMs... 😅

[Doswelk]

I tried this (in SWADE) last night and it seemed fine.

Having the lock default to locked might become annoying, I agree, but it is too soon to know. Maps snap to grid turning itself on IS annoying..

Yep wish we had an option to disable Snap to grid on maps as default :|

[HywelPhillips]

By returning records to a locked state by default; this prevents accidental changes in a new session, as inexperienced players often leave things half-cooked.
I've actually been thinking about making this a standard for all record types.


Oh god please don't make that a default for the GM as well. Having to re-unlock every record every time I wanted to change anything would be absolutely infuriating to me as a GM.

I know inexperienced users need hand-holding, but experienced users who know what they are doing need the software to get out the way. This would insert dozens of extra mouse clicks for me every prep session and many game sessions too. Generally speaking I don't make very many UI mistakes, because I know the software well. If I have changed something to be editable I'm capable of not editing it by accident. If I wanted it locked, I'm capable of re-locking it myself.

Experienced users come to have their own UI preferences, and resetting them every time is an annoyance the system simply shouldn't do. Just look at the people in this thread complaining about maps defaulting to snap to grid on.

I vote for making the inexperienced-user friendly thing the initial default, but if Window state is being remembered, as many things as possible should honour that next session. If a record has been set to unlocked, it should stay unlocked until someone locks it again, and that includes character sheets.

Cheers, Hywel

[Griffy]

Yep wish we had an option to disable Snap to grid on maps as default :|

+1 for that