Lock Tokens

[thelinuxfan]

How do I lock tokens so that players have to have their moves accepted? It is especially useful for measuring movement distance or not having players move their tokens (or someone elses!) out of order.

[LordEntrails]

You can't. Yet. Please see stickies at the top of the forum for items like this that have not yet been implemented.

[thelinuxfan]

Thanks!

I did look but missed that point. I am not sure if I can try this out without that aspect as I have too many players to track and would easily miss moves especially when it would reveal sections of the map if an accidental move occurred.

[LordEntrails]

I get it. (And no problem missing the sticky!)

Something to think about, how many accidental things can a player do that you don't worry about? Do you worry they might accidentally alter their character sheet? Do you check that they don't incorrectly add a modifier to a die roll?

To me, it's just not worth the time and stress. I trust my players to do what's right. Not because I implicitly trust them to never make a mistake, but because the way I run my games (you don't have to run it the way I do!) It doesn't matter if someone makes a mistake. If we catch it we correct it and move on. But no single mistake ruins the story or our fun, and worrying about folks making mistakes isn't worth my time or stress. (FOR ME!)

Happy gaming :)

[thelinuxfan]

You are right, and I thought of it like that as well. I do trust my players, but I do have to go check their spell slots, ki points, sorc points, etc. to have them update them after using abilities; not all the time, but it happens and is never a malicious/cheating mistake.

We are so used to dragging a token 30 ft for a move. Now, with FGU, you have to draw line and move the token, or try to count moves while tapping the arrow keys. What if a player is moving, especially in combat, and moves past a trap and I miss it because I didn't approve, or a player runs around a corner, and I have an NPC with a readied action to attack, but I miss it because of the non approval; the player can move freely and attack before I catch it. I can't really retroactively fix something like that.

Trying to track both movement and all of the other things is what is making my shy away from it right now. Also, locking the tokens makes the game feel much more tactical and turn based for me rather than "video game" style.

I do remember locking tokens the first time we ever used FG because of the chaos it can cause, especially with players accidentally moving someone else's character and then not remembering where they started at. We have been using FG for over 4 years and I have logged thousands of hours into the platform. I want to use FGU, but this is still a blocker for me.

[Xorn]

I made a list of the pros and cons of using FGU vs FGC and the critical reasons that I would use one or the other for my new campaign. The short list of reasons to pick one or the other for me, prioritized by importance:

FGC: Locking Tokens > Player Map Toolbar > Player Map Toolbar

FGU: Better Grids > Map Effects > LOS Effects

Honestly the first reason is the main driver by far for me. If FGU had locking tokens I would be using it without hesitation. I trust my players just fine--the locked tokens is so nice for reactions during the move.

The moment I can lock tokens in FGU, I'll be switching because I love the grid system allowing me to set a decimal in the grid size--so many maps I've downloaded take a grid perfectly when I can put a ".5" on the grid size, that I can never get to line up in FGC, settling for adjusting the grid after they traverse a certain amount of the map.

[Blackwolfe]

Yes please add lock tokens function. :)

[Milke]

I have one player, that ever since we started using FGU, when we enter a new map he starts slinging his token everywhere to open up the line of sight so he can see everything. Locking tokens would be great.

[Marquis_de_Taigeis]

I have one player, that ever since we started using FGU, when we enter a new map he starts slinging his token everywhere to open up the line of sight so he can see everything. Locking tokens would be great.

very simple solution to stop this, lots of traps without a save that kills does enough damage to bring the player to 1 hp, if they repeat the character dies in an area to far from anyone else to administer healing, time for a new character. my favourite trap is a 200ft pit without a save to avoid

[lostsanityreturned]

I have one player, that ever since we started using FGU, when we enter a new map he starts slinging his token everywhere to open up the line of sight so he can see everything. Locking tokens would be great.

Even after you have told them to stop?

You are a more patient person than me, that sort of behaviour would get a "don't come back" and no third chance. There are plenty of players, and people like that don't deserve a slot imo.

[Imagix]

I'm with lostsanityreturned. If the player cannot control themselves, then they are simply not welcome at the table (virtual or otherwise).

[Kanbie]

I know its in the sticky, but I cannot bring my players to transition into unity without some kind of managed and enforceable movement system. It isn't that I don't trust them, its that we love having out turn plotted out before pulling the trigger.

[LordEntrails]

I know its in the sticky, but I cannot bring my players to transition into unity without some kind of managed and enforceable movement system. It isn't that I don't trust them, its that we love having out turn plotted out before pulling the trigger.
Then you will have to wait until some indeterminable time after full release.

I suspect the devs will catch up on this thread before then so they will know that there is one more person urging this feature to be implemented.

[DwightLee]

I know its in the sticky, but I cannot bring my players to transition into unity without some kind of managed and enforceable movement system. It isn't that I don't trust them, its that we love having out turn plotted out before pulling the trigger.

I am in the same boat, there were 2 things keeping me from moving to FGU, I just found out one of them is resolved. I had not tested it in a while but FGU now works well with the Syrincape sound system and chat triggers found at DM's Guild, an essential element for my games. The last piece that is a game breaker for me is locking tokens. My players actually prefer it as well, so they dont accidentally move. Not only does it stop people from being able to randomly cheat, but it also assists the DM, sometimes movement tigers another event, often before the movement is complete as with traps. Say a player was going to move 35 feet, but falls into a pit trap after 10 feet. FGU shows the player the room that he player never actually saw.

My players will propose a move, token locked to show me what they intend, it works wonderfully in FGC, waiting for this in FGU

I am quite excited and pleased with what I have seen with Unity, I do hope this last thing ( to my group anyway ) is addressed at some point. My play group is looking forward to when we can move over.

I know there are complicated, and contrived ways to work around this ( putting traps in every single square and then turning the off only on the legal moves people can make ) was probably meant in humor, but imagine actually needing to do that as a work around for a missing essential game element. No this is a missing element that is important to people. There is not something wrong with the DM or the players, there is something missing from the implementation.

[bmos]

Although it's not kept me from having a great time playing in Unity (the admittedly-basic LOS system and 64 bit support make up for it in my games), this is the #1 thing I miss about Classic.

A pretty good workaround is using masking in Unity along with LOS.

[Blackwolfe]

A pretty good workaround is using masking in Unity along with LOS.

Yep. that's what I'm doing.
I find any "punish your players for bad behavior" posts unhelpful (in other threads as well).
"Punishing" characters in game for bad player behavior never makes a better game in My experience.
I do agree if a player cannot follow the rules long term it's okay to remove them from your game.

[DwightLee]

Yep. that's what I'm doing.
I find any "punish your players for bad behavior" posts unhelpful (in other threads as well).
"Punishing" players in game for bad behavior never makes a better game in My experience.
I do agree if a player cannot follow the rules long term it's okay to remove them from your game.

I agree, once I started using Token Lock in FGC, I was surprised that my players actually preferred it that way.

[qdwag]

I'm just wondering, does anyone know why the Token Lock feature isn't taking a higher priority in the FGU development queue?
It's quite an important feature IMHO.

[Zacchaeus]

The 'development queue' hasn't started yet. At the outset of Unity Alpha no new features were going to be added until Unity was to be released. A number of items such as return to the start screen and token locking were found to be problematic to do in Unity so they were dropped from the list of initial features. The way movement will work hasn't even been decided yet (well it wasn't a few months back anyway) and so that's somewhere in the development queue after release.

[lostsanityreturned]

Yep. that's what I'm doing.
I find any "punish your players for bad behavior" posts unhelpful (in other threads as well).
"Punishing" characters in game for bad player behavior never makes a better game in My experience.
I do agree if a player cannot follow the rules long term it's okay to remove them from your game.

The "As well" in your post suggests you think people were advocating for punishing a player in this thread. Were there any such posts here?

I would say it is "I read the adventure in advance", "I have the monster manual open" or "I look at the GM's notes when they are in the toilet" style meta cheating. Anyone who continues to do something like this after being caught out and asked not to, will just keep doing it. And if the GM doesn't like it, it will cause resentment over time and that is what is important (especially when it comes to burnout).

It isn't about punishing someone for doing wrong, it is about caring for yourself, the campaign, and the other players.
It can even open up a dialogue, if they come back with a "sorry for doing it, I really do like the group and was being a bit of a fool because I could. I promise I won't do it again" I would let it be a group decision. However if they showed hostility they would be gone for good, same if they ever repeated the actions again. No arguments, threats or debates.

I am speaking from my own mistakes in the past of trying to be more accomodating and putting myself last. It was especially hard when I was running lots of public games for folks I didn't know at my FLGS, I was feeling like I was being mean to them whenever I would have to have the talk.

- Had one girl who would openly direct the party through dungeons because they knew what was where, telling other players stuff like "no, that way has xxxxx, this way has xxxxx" or telling people what items to bring, spells to prep and such.

- Another who whenever he would get bored because the tone had shifted to RP would turn it to a fight or torpedo the scene so he could have the spotlight again. Regardless of how frequently he had had it that session already.

For the record neither of these people were malicious or nasty in intent, but they both valued themselves more and continued their behaviour over 6 months (the latter for nearly a year) and were constantly testing where the boundaries were.

[LordEntrails]

I'm just wondering, does anyone know why the Token Lock feature isn't taking a higher priority in the FGU development queue?
It's quite an important feature IMHO.
The developers also have access to how often options are used in FGC (don't know about FGU). So I'm sure they have hard data to help them prioritize token locking. I'm confident that they have considered how often the option is used along with the technical challenges of implementing it in their decision to delay implementing the feature until after full release.

[thelinuxfan]

I am excited this is getting more activity!

There are many reasons it is important, but for me, it is chiefly the tactical game play. With many groups, being able to plan moves is a critical component. By drawing the segmented movement line, complex movements can be formed without moving your character token. Yes, it is possible to do it manually, but it is difficult and easy to lose track of where the token started.

I am calling it token locking, because that is how the specific feature was enabled. If there was a way to do the segmented lines without locking a token, I think that would be good enough for me to start using FGU.

[Blackwolfe]

The "As well" in your post suggests you think people were advocating for punishing a player in this thread. Were there any such posts here?

I have no intention of "calling anyone out"
I apologize to you for not being a bit more clear with that paragraph.
I agree it's the DM's job to police players in the interest of the health of the game, I didn't mean to suggest it wasn't, though "punishment" is not how I go about it, I don't think saying, "Follow the rules or find a different group" is a "punishment", it's giving the player a clear choice.
Focus on the second and third line of My post, Do not punish CHARACTERS IN GAME for bad player behavior. That's My belief. I have never seen a game improve from a DM doing something harmful to a PC in game to "get back at" the player.
If a person cannot play your game by your rules then it's perfectly acceptable to ask them to stop coming to your game.

[Larsenex]

Thanks for the update on 'locking' tokens.
My players also like to map out movement. I was going to migrate the campaign over from Classic to unity in about a month.
The post above indicating that adding the locking mechanism proved to be more trouble in unity sounds ominous. I do hope we get that feature and if not at least an explanation on why it cannot be implemented.
I am building out a mega dungeon exclusively in unity and having the players locked down and mapping out their movement will assist in me knowing if traps are indeed triggered.
Do we have a rough timeline on the state Unity is supposed to be at for 'official' release?

[LordEntrails]

Do we have a rough timeline on the state Unity is supposed to be at for 'official' release?
No. Every timeline given in the past has been missed. I don't expect SmiteWorks to give any new ones.

[ChumSlinger]

Up-vote. Locking tokens is super important to me.

[DwightLee]

The "As well" in your post suggests you think people were advocating for punishing a player in this thread. Were there any such posts here?

I would say it is "I read the adventure in advance", "I have the monster manual open" or "I look at the GM's notes when they are in the toilet" style meta cheating. Anyone who continues to do something like this after being caught out and asked not to, will just keep doing it. And if the GM doesn't like it, it will cause resentment over time and that is what is important (especially when it comes to burnout).

It isn't about punishing someone for doing wrong, it is about caring for yourself, the campaign, and the other players.
It can even open up a dialogue, if they come back with a "sorry for doing it, I really do like the group and was being a bit of a fool because I could. I promise I won't do it again" I would let it be a group decision. However if they showed hostility they would be gone for good, same if they ever repeated the actions again. No arguments, threats or debates.

I am speaking from my own mistakes in the past of trying to be more accomodating and putting myself last. It was especially hard when I was running lots of public games for folks I didn't know at my FLGS, I was feeling like I was being mean to them whenever I would have to have the talk.

- Had one girl who would openly direct the party through dungeons because they knew what was where, telling other players stuff like "no, that way has xxxxx, this way has xxxxx" or telling people what items to bring, spells to prep and such.

- Another who whenever he would get bored because the tone had shifted to RP would turn it to a fight or torpedo the scene so he could have the spotlight again. Regardless of how frequently he had had it that session already.

For the record neither of these people were malicious or nasty in intent, but they both valued themselves more and continued their behaviour over 6 months (the latter for nearly a year) and were constantly testing where the boundaries were.

There is nothing wrong with you as a DM and there is nothing wrong with your players.... there is something important missing in the implementation of FGU that we hope is resolved soon.

Dont let people bait you into thinking it is your fault, or your players fault, that isn't the case at all.

[Gaddiel]

Up-vote. Locking tokens is super important to me.

Yes, me too. I really liked the feature to let the players map out their move with a segmented line. Super useful.

I also need to block the unlimited range on LOS from revealing map areas prematurely. By the way, I've seen it mentioned that you can use a mask along with LOS, but so far, I've been unable to get that to work. What am I doing wrong?

[LordEntrails]

I also need to block the unlimited range on LOS from revealing map areas prematurely. By the way, I've seen it mentioned that you can use a mask along with LOS, but so far, I've been unable to get that to work. What am I doing wrong?
Are you using the instructions detailed here; https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/950633/Working+with+Images+as+the+GM#Global-LOS

If not, I suggest you start a new thread with details of what you are trying and the steps to reproduce. Also screen shots are useful.

[fabiocm]

I think that token lock was not that important in FG:C as it will be in Unity because of LOS. With manual masking there's nothing to really hide from players besides what is already masked. But with automatic reveals the movement importance reach another level.

[Indus101]

I think that token lock was not that important in FG:C as it will be in Unity because of LOS. With manual masking there's nothing to really hide from players besides what is already masked. But with automatic reveals the movement importance reach another level.

Agreed.

[spoonhead]

Lock token at the moment really is stopping me from switching to FGU. It sounds silly, as I know it appears to be just a small issue, but the turn based nature of combat really benefits from this feature.

[thelinuxfan]

Lock token at the moment really is stopping me from switching to FGU. It sounds silly, as I know it appears to be just a small issue, but the turn based nature of combat really benefits from this feature.

I do not think it is silly. It makes the tactical aspect of the game ... tactical.

[daggertx]

Yes I need this is well. Thank you!

[Zacchaeus]

It's interesting because I thought that the lack of token lock would be an issue but actually it isn't at all. It has forced my players to move more slowly in a group with the stronger party members in front, and for them to stay in a group rather than get scattered. Thus it is much easier to sort out the situation where a trap or ambush is sprung because the party is where it is rather than strung out waiting for moves to be approved. During combat the LoS makes for much more tactical situations where the players might not be able to see not only enemy positions but where their allies are as well. They use the keyboard to move a square at a time and just count the squares.

[Kelrugem]

I never used lock tokens because it sadly also locks facing, but I understand that one likes the measurement tool for measuring the distance moved :) (for the movement itself I just tell my players they should not simply move everywhere)

I think it is difficult to implement though. Imagine your token does not see some enemy around a corner and your movement does not take this into account. When I would suddenly see an enemy where I didn't expect any, then I would change my movement at that point. hence, the LoS needs to be updated along the way while planning the move, but I often see these complaints because DMs do not want that players use their movement to unhide hidden areas, and that approach would not help in that regard. (But without updating the LoS already in the planning, it is like you drive a car, then you see a tree but the DM doesn't allow you to use your brakes because you already said your movement without using brakes :D Not very realistic then, besides that people have a reaction time in reality, but you hopefully get what I want to say :D) Therefore, even when lock tokens will be implemented somewhen, it may still be a requirement that people do not misuse the LoS system :) (if that is some problem concerning you; as said, I understand completely the point to get that tool for tactical stuff :) )

[Indus101]

I never used lock tokens because it sadly also locks facing, but I understand that one likes the measurement tool for measuring the distance moved :) (for the movement itself I just tell my players they should not simply move everywhere)

I think it is difficult to implement though. Imagine your token does not see some enemy around a corner and your movement does not take this into account. When I would suddenly see an enemy where I didn't expect any, then I would change my movement at that point. hence, the LoS needs to be updated along the way while planning the move, but I often see these complaints because DMs do not want that players use their movement to unhide hidden areas, and that approach would not help in that regard. (But without updating the LoS already in the planning, it is like you drive a car, then you see a tree but the DM doesn't allow you to use your brakes because you already said your movement without using brakes :D Not very realistic then, besides that people have a reaction time in reality, but you hopefully get what I want to say :D) Therefore, even when lock tokens will be implemented somewhen, it may still be a requirement that people do not misuse the LoS system :) (if that is some problem concerning you; as said, I understand completely the point to get that tool for tactical stuff :) )

I see your point, but in this case, (as a DM) I would simply allow the player to change alter movement to react to what is being revealed (in your example, the car and the tree).

I didn't know it also locked facing. Does that mean you can't ever adjust your facing, even when you're plotting your movement?

[Kelrugem]

I see your point, but in this case (as a DM) I would simply allow the player to change alter movement to react to what is being revealed (in your example, the car and the tree).

I didn't know it also locked facing. Does that mean you can't ever adjust your facing, even when you're plotting your movement?

yeah, of course one can then simply allow to change movement, that is true :) Just wanted to point out that I can understand that one wants to think about the concept first :)

Hehe, yes, facing is always locked then in FGC :D we play with facing rules and at the very beginning we tried out lock tokens. The result was that I as the DM always needed to adjust the facing of my players because they couldn't adjust it on their own, so, they always needed to tell me where they want to look at :D We got quickly annoyed by that and therefore I stopped using lock tokens :D I hope FGU will not do the same when this will be implemented :)

[Indus101]

Never having owned FGC, I didn't realize this was the case. Yeah, I can see where that would quickly become tiring as a DM. Hopefully when token locking is implemented, this will change and players will have the ability to adjust facing as part of their plotted movement.

[thelinuxfan]

It's interesting because I thought that the lack of token lock would be an issue but actually it isn't at all. It has forced my players to move more slowly in a group with the stronger party members in front, and for them to stay in a group rather than get scattered. Thus it is much easier to sort out the situation where a trap or ambush is sprung because the party is where it is rather than strung out waiting for moves to be approved. During combat the LoS makes for much more tactical situations where the players might not be able to see not only enemy positions but where their allies are as well. They use the keyboard to move a square at a time and just count the squares.

Out of combat, I have no problem with FGU. It is in combat, it is where the movement is critical. I think both the token pathing (not locking!) and the LoS would be amazing. I don't necessary need locking; I need the segmented paths.

We tried FGU out for probably 5-6 sessions, but it wasn't doing it for us, so we have been back on FGC until this is resolved.

[kevininrussia]

Keeping the token movement as it is in Unity, I would like the token to know the speed of the PC/NPC and let the token only move that many squares. Maybe have a count down number on the token, as the token is moved show how many squares of movement are left. Effects like Slowed or Immobilized could adjust that number.

[Indus101]

That would be really cool, but I imagine it would take a lot of work and time for the Devs, as movement would go from being a descriptive number to an actual coded mechanic, like AC or Attack Bonus, that could be modified by Effects, or even interact with map features, such as difficult terrain.

[kevininrussia]

That would be really cool, but I imagine it would take a lot of work and time for the Devs, as movement would go from being a descriptive number to an actual coded mechanic, like AC or Attack Bonus, that could be modified by Effects, or even interact with map features, such as difficult terrain.

Movement is a coded mechanic now. I use the Aura extension that knows the Aura size in squares based on an effect on the token. It also knows the distance between tokens so the aura can be activated.

[Indus101]

Movement is a coded mechanic now. I use the Aura extension that knows the Aura size in squares based on an effect on the token. It also knows the distance between tokens so the aura can be activated.

Very cool! I didn't realize that.

[LordEntrails]

One of the problems with limiting token movement is how to handle exceptions. Many games (like D&D) have where character can move different distances based upon the actions they chose. Such as, double movement, dash, running or charging, feats/abilities used, spells, etc. So now you have to code in all these actions so that you know on this given turn a token can move more than it's listed speed. And then what happens with forced movement?

Yes, all these things can be accounted for, but the return on developer time may not be the best use of such time, plus the trade-offs on user interface and experience may or may not be desirable by any given user.

As for Token Locking, the devs have stated it is a high priority that they will evaluate how best to do it following full release. That tells me that they have some ideas on how they might improve it over how it works in FGC. That if they just wanted it to be the same as now, it probably would have already been done (unless somehow their is some strange technical reason, but I doubt it). So, in the end I suspect the feature will have much more capability than it does in FGC.

[ThingsCouldGetDicey]

One of the problems with limiting token movement is how to handle exceptions. Many games (like D&D) have where character can move different distances based upon the actions they chose. Such as, double movement, dash, running or charging, feats/abilities used, spells, etc. So now you have to code in all these actions so that you know on this given turn a token can move more than it's listed speed. And then what happens with forced movement?

Yes, all these things can be accounted for, but the return on developer time may not be the best use of such time, plus the trade-offs on user interface and experience may or may not be desirable by any given user.

As for Token Locking, the devs have stated it is a high priority that they will evaluate how best to do it following full release. That tells me that they have some ideas on how they might improve it over how it works in FGC. That if they just wanted it to be the same as now, it probably would have already been done (unless somehow their is some strange technical reason, but I doubt it). So, in the end I suspect the feature will have much more capability than it does in FGC.

afaik there isnt any value to attribute speed to within FG. so currently effects as they stand cant alter the allowance. so that would have to change too.

[JimSocks]

Upvote for locking!

We have now transitioned our 6 year campaign from Classic to Unity, and really the main annoyances I still have are font readability (the extensions that attempt to address this still haven't hit the mark for me), and the lack of token locking. I rejoiced when minimizing windows was brought into Unity- that was HUGE.

Honestly, my players miss the token locking even more than I do- they keep bringing it up as their chief complaint.

[Kelrugem]

Upvote for locking!

We have now transitioned our 6 year campaign from Classic to Unity, and really the main annoyances I still have are font readability (the extensions that attempt to address this still haven't hit the mark for me), and the lack of token locking. I rejoiced when minimizing windows was brought into Unity- that was HUGE.

Honestly, my players miss the token locking even more than I do- they keep bringing it up as their chief complaint.

About readability: You tried scaleui? :) Or do you just want to increase the font but everything else should stay as it is?

[Blackwolfe]

Upvote for locking!.

Devs. You did it before and you can do it again. All this conversation around the how or cannot isn't really necessary is it. People had the function on the older version, they want it on the new. :)

[Zacchaeus]

Devs. You did it before and you can do it again. All this conversation around the how or cannot isn't really necessary is it. People had the function on the older version, they want it on the new. :)

No one is disputing this. However it would be a new feature and until FG is released there won't be any new features. If this were a simple thing to do it would have been done - given the number of people who deem this necessary. The fact that it hasn't been done suggests that token locking is not something that is going to be trivial to code.

[JimSocks]

Or do you just want to increase the font but everything else should stay as it is?

This exactly. And the size of the font is only one part of it. The font itself is a bit harder to read IMO too. The extensions available to change the font make strides toward improving the font, but none hit the nail on the head to me.

A native solution to the readability issue (and not scaleui) would be amazing.

[Zygmunt Molotch]

missing basic functionality like this is one of the major reasons what's preventing it from going prime time, there is no point in occlusion mechanics if the movement can't be restricted...

it undermines the basic premise of why you'd include Occlusion mechanics to begin with... no project manager would have signed this off...

not only that, movement and thus locking tokens, should not be 'after' release, it's a fundamental requirement for DnD (really I mean RPGs) of all forms which is not 'theatre of the mind', that should have been clear from the very start of planning, the very first scrum

without the functionality of measuring distance and movement, Unity sorely misses the point of both RPGs (where movement is an intrinsic mechanic) and a VTTs (where it's possible to use machines to measure it for you to prevent errors/misunderstandings/for streamlining actions)



While I'm a big fan of FG, in all forms, the ignorance of some posters saying this isn't a requirement is shocking, we're all here to make suggestions, comment and improve the thing we love

saying 'it's not on the list' or 'not necessary' is wilfully 'missing the point' of a VTT

[LordEntrails]

missing basic functionality like this is one of the major reasons what's preventing it from going prime time, there is no point in occlusion mechanics if the movement can't be restricted...
<snip>
saying 'it's not on the list' or 'not necessary' is wilfully 'missing the point' of a VTT
Interesting thoughts. You certainly feel that what is important to you must be valued the same by everyone else. Hopefully you'll take a moment to reflect that many folks who have been playing RPGs, using VTTs and using FG for at least as long as you, and perhaps for decades longer, don't agree with you. Hopefully you will also realize that those folks might just be as intelligent and experienced as you.

Hopefully you will realize that different intelligent, thoughtful and insightful people may have different valid views. Please make sure to keep that in mind as you participate on the FG forums. Thanks.

[Zygmunt Molotch]

Alright, let's assume you're not trolling here,

the criticism that FGU is missing a major part of what makes the RPG game, the game, is valid no matter how you feel

there are whole chapters in all rulebooks to explain movement mechanics, it's a core feature of all rulebooks of all RPGs

currently with FGU you can't measure movement or lock tokens.

thanks for participating in a polite manner, I hope you understand that poster history isn't a measure of how long someone has been playing RPGs or VTTs

we don't need to argue, but you cannot dismiss this out of hand, every VTT provides a movement measure, and there is no reason for occlusion if movement is free

if you don't see how missing an intrinsic part of RPGs is,... odd I'm not sure what to say :D

[Imagix]

I would suggest that Fantasy Grounds already is prime time. Also, please point out where Smiteworks has said that they aren't going to do token locking. They have not "dismiss this out of hand". They've acknowledged over and over that people want token locking, and some version of it will be implemented. Only that it will not be done for the first release.

Also, I find the occlusion mechanics quite useful in the current incarnation. (Light sources will improve this so one does not have to juggle with masking and LoS. Also a post-release feature.) Without any sort of token locking.

[LordEntrails]

Alright, let's assume you're not trolling here,
With nearly 12,000 posts and Immortal status, I can assure you I'm not trolling. I'm asking you to consider that your opinions are opinions, and not indisputable facts.


the criticism that FGU is missing a major part of what makes the RPG game, the game, is valid no matter how you feel
I never said it was invalid. I said it that your statement was an opinion that is not universally shared. That is a valid statement, no matter how strongly you feel. And I will disagree with you below that FGU is missing a critical part of the game.


there are whole chapters in all rulebooks to explain movement mechanics, it's a core feature of all rulebooks of all RPGs

currently with FGU you can't measure movement or lock tokens.
You group these two capabilities as if they were one. They are not. Movement, and your disagreement about measuring movement, are distinctly different capabilities than token locking.

I can think of two ways to measure movement in FGU. The first is the same way I do it when playing with minis on a battlemap. Count squares. The second way is to use the Quick Pointers to draw arrows to measure movement before you actually move.

Locking tokens I feel is not a required feature. And I can justify to myself this opinion because when playing with minis on a battlemap, there is no Mini Locking. Players can pic up and move any mini at any time. We are all just mature enough to not move a figure if we should not be moving it.


thanks for participating in a polite manner, I hope you understand that poster history isn't a measure of how long someone has been playing RPGs or VTTs
Absolutely. The community here tries very hard to be civil and respectful to each other. It's one of the things that imo makes FG so awesome. If it matters, I've been playing RPGs since 1978 and using FG since 2015.


we don't need to argue, but you cannot dismiss this out of hand, every VTT provides a movement measure, and there is no reason for occlusion if movement is free
Hopefully we are not arguing, just discussing. I don't think I dismissed your view at all. In fact I was trying to not engage in discussing it at all. But rather was trying to ask you to tone down what I felt was an aggressive and absolutist set of statement that came across as akin to "FG is missing X and you can't play an RPG without X and no other view point is acceptable."


if you don't see how missing an intrinsic part of RPGs is,... odd I'm not sure what to say :D
As I said, I was trying to avoid this discussion. But since we are now having it consider this;
1) Measuring movement is not missing from FGU. I've already given you two ways to accomplish this.
2) Token locking is not something present in any RPG rules I can remember reading.
3) Extrapolating from known data; There have been millions (at least) of hours of RPGs played on FGC. Many or most of those hours have been played without the Lock Tokens option turned on. There are Tens of thousands of hours of RPGs played on FGU without Token Locking. If token locking was required to play RPGs, none of that would have happened. VTT's like Tableplop, Schmeppy and numerous others would not exist. If FGU had no way to calculate or account for movement and it was required for RPGs, then none of those FGU hours would accumulate.

I'm not dismissing your view. I'm not even saying that for you and your game you find something required missing from FGU. I'm asking you to recognize that your requirements are not everyone's requirements. And more importantly, to try (as best one can in a written medium) take a tone that allows for opinions different than yours.

[Indus101]

Out of curiosity, what was the change, or rather new feature, in FGU that made token locking not currently possible? Something FGU can do that FGC can't? (I think I've seen this answered somewhere before, but I can't find it now)

[Zacchaeus]

The whole way that movement will work has not been officially decided in FGU as yet (or if it has it hasn't been publicly discussed). I believe that the token locking was interfering with the LoS functionality and since it was going to take a fair bit of coding to sort that out it was disabled and will be part of the movement system that will be worked on after release.

[LordEntrails]

Out of curiosity, what was the change, or rather new feature, in FGU that made token locking not currently possible? Something FGU can do that FGC can't? (I think I've seen this answered somewhere before, but I can't find it now)
I think as Mr Z says, I think it has to do with LOS.

One example I can think of is moving around corners. Say you are 10 ft from a hallway corner. Can you move to that corner and wait until the GM approves that movement? And then you have to finish your movement with another proposed move? Or do you propose moving there, and LOS updates so you can continue moving? I'm sure there are other possibilities as well.

Also, I wonder if the devs have some other ideas in mind for things like height and incorporating speed or other things. And instead of doing just the bare minimum, they have decided to wait until they can take a wholistic look at movement and implement a comprehensive solution, rather than just re-implementing what FGC has.

The other thing is the devs have data on what options are actually used in games. I suspect that if Lock Tokens was used by a huge majority of folks, then it would not have been postponed.

[Indus101]

Got it. Thanks for the quick replies Z and Lord

[DwightLee]

I will do my best to be patient, but the advantages of FGU would be wonderful if it had this one important feature. How I hope it will work is that LOS is based upon where someones token actually is, ( not where it is proposed ) so that the GM can overide a proposed movement by placing the players token how far they would actually get in a situation, not necessarily where they proposed to go. My only complaint is that we have waited a long time for FGU, but without this feature, we will continue our game in FGC. It is just too important to do without for us anyway.

[Zacchaeus]

I will do my best to be patient, but the advantages of FGU would be wonderful if it had this one important feature. How I hope it will work is that LOS is based upon where someones token actually is, ( not where it is proposed ) so that the GM can overide a proposed movement by placing the players token how far they would actually get in a situation, not necessarily where they proposed to go. My only complaint is that we have waited a long time for FGU, but without this feature, we will continue our game in FGC. It is just too important to do without for us anyway.

I suspect that this is the reason why it hasn't been implemented as yet. Whenever a token is moved it reveals the LoS - so a way has to be found which would allow the token to move without revealing LoS until the movement has been approved. Of course if that is the way it is implemented then that won't really be all that brilliant either since the player may not want to move all the way to where they put their token if at some point along the route it revealed a bunch of enemies. So, actually the way it is working now is really great because the players can move a square at a time and stop their movement at any point if enemies are revealed and the DM can activate any traps or anything else they want as the player moves. So, in essence, a simple movement system like in Classic isn't going to work in Unity - at least not all that well.

As I noted in a previous post above the way movement works hasn't been decided yet and whether token locking will even be a part of that is unknown. There are a lot of variables that need to work together so that the wishes of both the player and the DM are satisfactorily met. I, too, thought that token locking would be a major issue but in fact it turns out not to be a problem at all. But as also noted YMMV.

[JimSocks]

I think if locked tokens are allowed to be moved up to the current vision extents for that token, but no further until after approved and the FOV changes, that would work.

Player can’t yet see around the corner, but can propose a move to look around it. The GM approves, token moves, and the player now sees more area. They can then decide to move into the now visible area or not, if they have more movement remaining.

Just an idea?

[JonnyG]

I think if locked tokens are allowed to be moved up to the current vision extents for that token, but no further until after approved and the FOV changes, that would work.

Player can’t yet see around the corner, but can propose a move to look around it. The GM approves, token moves, and the player now sees more area. They can then decide to move into the now visible area or not, if they have more movement remaining.

Just an idea?

I agree with Zacchaeus above, the problem is what happens if halfway along that movement it reveals a monstrous pit that the movement would fall in. Or as was suggested above, halfway along a dragon is revealed, that the rest of the movement would then put them in range of. YOu wouldn't want to reveal all the area for the path and end of the path. Maybe you could put it in where you wanted to go, but when the movement and reveal actually happens, it was one step at a time, and the player could cancel the rest of the movement at any time.

[JimSocks]

Right, but what if you could only move to the extent of your current vision? Then there wouldnt be a possibility of falling into a pit you didn’t see before?

So the player proposes a movement up to the edge of their vision, the GM approves, the token moves, the vision extent grows, and the player can then propose more movement.

[spoonhead]

How about just having the choice of locking tokens or not? Then fans of both systems would be happy. Of course, LoS needs to eventually take into account light, dark vision et al to be really effective.

[Zacchaeus]

You can imagine all sorts of scenarios and you can't really devise a movement system that would cover everything; nor one that's going to make everyone happy. If the players are approaching a junction that's 20 feet away I don't imagine that a character with a speed of 30 is going to create a move that takes it the the end of the junction and then goes 10 feet left or right. Anyone is going to go to a point where they can see left and right before deciding whether to continue their move or not. If we have token locking then the DM has to approve that first movement then has to approve another move. Without token locking the player can hit the arrow key four times to move the 20 feet and then hit it twice more in the direction the want to go if it's all clear. I'm not seeing any advantage in this kind of situation where locking tokens trumps not locking them.

We'll have to wait and see what the devs come up with but as I said above the main problem will be allowing a player to move a token to where they want to be without revealing LoS if we want token locking and DM approval the same as it is in Classic. I really think that what we'll get is a much better method than that and it may very well not involve locking tokens at all.

[LordEntrails]

So the player proposes a movement up to the edge of their vision, the GM approves, the token moves, the vision extent grows, and the player can then propose more movement.
The challenge is the "What If..."
For example, what if moving into a large chamber with niches along the wall (like an old church). Sure you can move your full movement up to the altar or such, but doing so reveals enemies in the niches.

Not to say their isn't a reasonable solution for that What If. Or any other one. But it just shows that their is always another edge case. And in the end, the GM and players have to work together with the tools available to tell the right story. This is just like when we have played at the table with tokens/minis or even theatre of the mind.

[Finsteel]

I'm mostly lurking around forums but let me toss some ideas that just occured to me. What if token movement was not 'undoable' and strictly limited to number of squares, allowed by creature's movement rate. If the player (or DM in case of NPCs) moves the token around, it would also draw the trail of the movement for that round. The trail could be automatically deleted when the creature finishes it's turn. Using Dash action (or some other effects) would then of course increase the movement available. So if your character really moves all the way up to that altar (like in LordEntrails' example above), you could reveal those enemies in the niches but end up in possibly dangerous position and no way to move back. Or you could just end your movement or even move back the instant you reveal the first enemy.

Now what about movement outside combat rounds? The movement restriction could be turned off if the Combat Tracker round is set to 0. If there are some players who tend to whirlwind their tokens around the map, the DM could just politely ask if they really want to do the whole Undermountain round by round or be more careful with their movements outside the combat rounds.

Most likely this idea has some drawbacks I didn't think of yet and/or it may be technically difficult to apply but I just wanted to add some brainstorming to this issue. At least this way there is no need to build some approval mechanism to proposed movement, instead of just giving the responsibility to players about how they use their 'movement points'.

I have not used much FGC but have been running a campaign on FGU since April. So I don't have strong opinion or 'legacy' about token locking but I do have some issues about free movement with my group too, so some kind of solution for it would be welcome for me too. Either locking and approving the movement or just inherently limit the movement range by round or something completely different.

Cheers!

[DwightLee]

I suspect that this is the reason why it hasn't been implemented as yet. Whenever a token is moved it reveals the LoS - so a way has to be found which would allow the token to move without revealing LoS until the movement has been approved. Of course if that is the way it is implemented then that won't really be all that brilliant either since the player may not want to move all the way to where they put their token if at some point along the route it revealed a bunch of enemies. So, actually the way it is working now is really great because the players can move a square at a time and stop their movement at any point if enemies are revealed and the DM can activate any traps or anything else they want as the player moves. So, in essence, a simple movement system like in Classic isn't going to work in Unity - at least not all that well.

As I noted in a previous post above the way movement works hasn't been decided yet and whether token locking will even be a part of that is unknown. There are a lot of variables that need to work together so that the wishes of both the player and the DM are satisfactorily met. I, too, thought that token locking would be a major issue but in fact it turns out not to be a problem at all. But as also noted YMMV.


I dont see the problem still, the players dont move, they propose a move, the GM either allows it, or moves for them to show them how far they got. That is what we ask for

[Zacchaeus]

I dont see the problem still, the players dont move, they propose a move, the GM either allows it, or moves for them to show them how far they got. That is what we ask for
How are they going to propose a move without moving their token?

[YggBjorn]

I think what DwightLee is saying, is that with a locked token the token doesn't move. The player moves the 'movement node' (for lack of a better term) to a desired location. I wonder if with Unity that 'node' also carried the light source with it thereby revealing the map before the token was given allowance to move from the DM? I could see that as being a reason to rethink movement, however that is just speculation.

[Zacchaeus]

I think what DwightLee is saying, is that with a locked token the token doesn't move. The player moves the 'movement node' (for lack of a better term) to a desired location. I wonder if with Unity that 'node' also carried the light source with it thereby revealing the map before the token was given allowance to move from the DM? I could see that as being a reason to rethink movement, however that is just speculation.
That is exactly what I have been saying. The node as you put it would reveal the LOS as soon as you started moving it. Thus there is no point in having the tokens locked since that is exactly the same as just moving the token. In Unity movement is better than in Classic since we have keyboard movement, so tokens can move a square at a time. So by embracing that and using that as part of the gameplay you have a more visceral experience. Things happen in real time. I appreciate that some people see locking tokens as essential but I and my group have not found it to be a problem at all, and in fact find it better than classic where we always played with tokens locked.

[spoonhead]

What if tokens were locked when it wasn’t your turn on the combat tracker? Would that not work? Or is that a problem with Unity? Free movement outside of combat generally isn’t an issue. I don’t think any of us are arguing for locked tokens being mandatory, just that it can be a choice as it is now. It would solve both sides of the debate. I find this debate about realism a little odd, seeing as at the moment LoS is not limited by distance. Just look at another VTT to see how it can be done.

Also, if we were all around a table moving minis, that in itself wouldn’t be a problem, seeing as there is no way for the minis to interact with the environment. You’d move them, and that would be it. Nothing revealed, nothing triggered, so it’s not quite the same.

BTW, can tokens move diagonally using the keyboard?

[JimSocks]

Generally it’s actually my players that miss the token locking the most. I mean I miss it too, but they mention it far more than I do. My group spent time between turns plotting out different routes sometimes, which now they do with pointers and it’s just... more of a pain (and not the greatest for calculating distances) Add to that forgetting where they started which happens I swear to God every session.

Everyone is well-intentioned, but accidents happen.

What if for those that wanted token locking, we ditch LOS? Flip a setting within our FGU client to turn LOS off, and token locking works? That would suck a bit, because LOS is great, but I’d ditch it for token lock I think. Sure, we could migrate back to FGC for that experience, but I’m not sure how smooth Campaign reverse-migration is, and Unity is the future of FG anyway, right?

As a side note, if there is a way to move diagonally with movement keys I would welcome that knowledge too!

[kevininrussia]

As a side note, if there is a way to move diagonally with movement keys I would welcome that knowledge too!

Numeric key pad with number lock turned off

[DwightLee]

I suppose I dont really care, you can make it a mark, you can make it a dot, you can use whatever you want to, just dont move the token and let them indicate where they intend to move.

[YggBjorn]

The shape of the 'node' doesn't matter, the 'node' itself has the LoS lighting attached to it, so when the token is locked and the player is setting up their move, the little square showing their intended movement is where the players LoS lighting bit is attached thereby revealing the area of the map where the intended move is sitting, not where the token is sitting. That is apparently the reason they disabled locking tokens, they can't force the LoS lighting to stick to the token. The developers have decided to disable the ability to lock tokens. We must be patient and wait for them to fix it. They understand our concerns and will take them under advisement. I plan on running my Savage World sessions in FGU as they aren't quite as tactical as say DnD5e which I will run in FGC until this is resolved.

[DwightLee]

The shape of the 'node' doesn't matter, the 'node' itself has the LoS lighting attached to it, so when the token is locked and the player is setting up their move, the little square showing their intended movement is where the players LoS lighting bit is attached thereby revealing the area of the map where the intended move is sitting, not where the token is sitting. That is apparently the reason they disabled locking tokens, they can't force the LoS lighting to stick to the token. The developers have decided to disable the ability to lock tokens. We must be patient and wait for them to fix it. They understand our concerns and will take them under advisement. I plan on running my Savage World sessions in FGU as they aren't quite as tactical as say DnD5e which I will run in FGC until this is resolved.

your talking programming ( nodes ) and Im talking playing of course so we are speaking different languages. There should be a way to indicate something without triggering line of sight. I will be patient ( or try to, it was never my long suit ) on the positive side I just tested FGU whit one of my players, and now we are talking to the other players about the positives vs that one big minus. Keyboard movement will change the game in a lot of ways, which makes lack of token locking easier to take. The loss of diagonal movement is not that big a deal as long as we limit the NPC's in the exact same way, we can all buy that.

[YggBjorn]

If they turn numlock off and scroll lock on they can use the number key pad to move diagonally.

[LordEntrails]

your talking programming ( nodes ) and Im talking playing of course so we are speaking different languages. There should be a way to indicate something without triggering line of sight. I will be patient ( or try to, it was never my long suit ) on the positive side I just tested FGU whit one of my players, and now we are talking to the other players about the positives vs that one big minus.
Yes there should be, but there isn't (yet). So no token locking (yet).

[Patou]

Yes there should be, but there isn't (yet). So no token locking (yet).

Token distance measurement upon movement will likely happen at the same time?

[LordEntrails]

Token distance measurement upon movement will likely happen at the same time?
Sorry, I have no idea.

[GrumpyOldAndy]

I'll admit, I find it confusing that LoS and token locking are an issue, considering it was done in Laser Squad, released 32 years ago in 1988, and a host of games since including the more famous sequel Ufo:Enemy Unknown, and would have assumed the algorithms needed were published in any decent book on games programming, and in freely downloadable libraries for every programming language.
HOWEVER, there is obviously some problem I am unaware of and to keep moaning about it achieves nothing. The developers are aware of the issue, you can upvote the feature request in the wishlist to make sure they realise how many people want it, and they have stated it will be a priority after launch.
Before people say I have no idea what I'm talking about, although not a games programmer, I was an embedded C programmer in the oil industry, and my code is in refineries that have millions of dollars per day of oil going through them.

[bmos]

There should be a way to indicate something without triggering line of sightThere is. Just create a pointer of a 5ft circle on the map and use it to indicate.
You could even use arrow pointers to show complex movement.
These are obviously just workarounds until locked token movement is implemented, but it's not that fussy after session or two and actually has the benefit of color-coding based on the player's dice color.

[Blackwolfe]

to keep moaning about it achieves nothing. The developers are aware of the issue, you can upvote the feature request in the wishlist to make sure they realise how many people want it, and they have stated it will be a priority after launch.

Where is this wish list? (link?) I completely agree with You good Sir.

[thelinuxfan]

Where is this wish list? (link?) I completely agree with You good Sir.

https://fg2app.idea.informer.com/

[LordEntrails]

Where is this wish list? (link?) I completely agree with You good Sir.
https://fg2app.idea.informer.com/

[DwightLee]

There is. Just create a pointer of a 5ft circle on the map and use it to indicate.
You could even use arrow pointers to show complex movement.
These are obviously just workarounds until locked token movement is implemented, but it's not that fussy after session or two and actually has the benefit of color-coding based on the player's dice color.

My point was in unity there should be a way to indicate where a player wants to move, and then the GM approve the indicated move. After doing some testing in Fantasy grounds however, we have decided to take the plunge after all

[Kelrugem]

It looks like that it comes sooner than later :) (at least a test version, see here: https://www.fantasygrounds.com/forums/showthread.php?62021-Full-Release-Date&p=543079&viewfull=1#post543079 ) So, some hope for you Lock-Tokens-users :D

[ddavison]

Yes, the test looked really good. We will do some additional testing next week and then figure out what our release schedule looks like for all you fine folks.

[Ludd_G]

Thank you!

[Indus101]

Yes, the test looked really good. We will do some additional testing next week and then figure out what our release schedule looks like for all you fine folks.

Very cool. Thanks for the update!

[Larsenex]

I am excited for this update. So much so i just randomly bought Pathfinder 2E products from the store~ (insert image of Fry screaming 'take my money')

Any idea if this will arrive in October sometime?

[fabiocm]

There are some weeks since the last FG update, and then they come with this info. I m hoping to have lock token at the next update!

[Moon Wizard]

There is a new FGU release build with the first implementation of token locking in FGU. You can enable via the right-click menu or via the image data control play mode toolbar (accessible after unlocking image record).

Regards,
JPG

[Patou]

There is a new FGU release build with the first implementation of token locking in FGU. You can enable via the right-click menu or via the image data control play mode toolbar (accessible after unlocking image record).

Regards,
JPG

:) !!!!

[Indus101]

There is a new FGU release build with the first implementation of token locking in FGU. You can enable via the right-click menu or via the image data control play mode toolbar (accessible after unlocking image record).

Regards,
JPG

Thank you!

[kevininrussia]

There is a new FGU release build with the first implementation of token locking in FGU. You can enable via the right-click menu or via the image data control play mode toolbar (accessible after unlocking image record).

Regards,
JPG

Messing around with the new token lock. I like it. :-)

Only comment is maybe have the movement after DM clicks the check mark a little faster.

Is it possible to make movement by squares instead of the smooth movement? That might be less LOS calculations and speed up the movement.

[Zygmunt Molotch]

There is a new FGU release build with the first implementation of token locking in FGU. You can enable via the right-click menu or via the image data control play mode toolbar (accessible after unlocking image record).

Regards,
JPG

Well let's give this a bash!

yay for moaning!

[DwightLee]

Thank you Smite Works.... this is exactly what we wanted :)

[qdwag]

This is awesome. About time! Looks great.

But now it makes the targeting arrow look a little outdated :o

[arkanis]

A very important milestone for FGU

Thank you!

[ddavison]

This is awesome. About time! Looks great.

But now it makes the targeting arrow look a little outdated :o

Yes, those are being updated as well. We didn’t want to make you wait for those to be implemented.

[qdwag]

Much thanks. I’m sure everyone is rejoicing now after the much awaited wait.

[humby]

Found a something a little interesting when testing this earlier - if a player attempts to move their token through a wall and then back again, if the GM accepts the move then on their side the move stops at the wall but on the player's side the token will end up at the final location (so the tokens are not in the same place on the GM's side vs the player's side).

In the pictures below, GM view is on the left, player view is on the right:
Token starts near to a wall: 39664
Player moves tokens 3 spaces to the left, through the wall: 39665
Player moves the token 2 places to the right (again, through the wall): 39666
GM accepts the move: 39667

[Ludd_G]

Loving it so far! Thank you!

But, just because I'm greedy ( :o ), I was wondering if will there be the ability for the player to delete movement nodes/points, using backspace or delete, like in various graphics programs?

Also is the token movement speed tied to computer power at all? I noticed someone saying their tokens were very slow but mine are literally zooming around in a most impetuous way! :)

Cheers, and thanks again!

Simon

p.s. I also noticed the behaviour spotted by Humby above.

[Jiminimonka]

Ooh Shiny!!

[ddavison]

Here is the start of the wiki page for how to use it, for those that haven't already discovered these features:
https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/758841345/Token+Locking+-+GM+Approved+Player+Movement

[Moon Wizard]

@Ludd_G,
If you drag a waypoint onto another waypoint (assuming grid snap is on), then the waypoints should combine.

Regards,
JPG

[Moon Wizard]

I also want to thank Carl and Joshua for their design work on this project; and Carl again for his quick implementation!

Regards,
JPG

[Ludd_G]

Hi, yeah, I'm starting to get it, thanks for the link to the wiki.

The thing that is a bit fiddly is that if the GM wants to use dragging rather than keystrokes the first movement node dropped will not be snapped to grid as ctrl is being held down, is that right? After this first one is dropped I can then continue to drag the origin node without holding down ctrl which means all subsequent nodes are now nicely snapping to grid? I can then go back and a quick jiggle of the first node snaps it back to grid as long as ctrl is not being held?

What was happening is I was ending up with several nodes not snapped to grid, which means that if they are placed on each other they don't combine as they are not perfectly aligned. What would be an instant fix to this is to use 2 different modifier keys for 'no snap to grid' and 'GM uses movement locking', at the moment they both use ctrl I think? Could one use Alt?

I could also be doing it totally wrong?

It would also be great to be able to drag the origin node and move it rather than have it drop another node. Would this be possible with another modifier key? I've worked out I can do this by moving the movement trail back on itself and then move the newly created node back under the origin node, but this seems a little clunky?

Cheers,

Simon

Oh, and as always, thank you all for your hard work!

[pindercarl]

Hi, yeah, I'm starting to get it, thanks for the link to the wiki.

The thing that is a bit fiddly is that if the GM wants to use dragging rather than keystrokes the first movement node dropped will not be snapped to grid as ctrl is being held down, is that right? After this first one is dropped I can then continue to drag the origin node without holding down ctrl which means all subsequent nodes are now nicely snapping to grid? I can then go back and a quick jiggle of the first node snaps it back to grid as long as ctrl is not being held?

What was happening is I was ending up with several nodes not snapped to grid, which means that if they are placed on each other they don't combine as they are not perfectly aligned. What would be an instant fix to this is to use 2 different modifier keys for 'no snap to grid' and 'GM uses movement locking', at the moment they both use ctrl I think? Could one use Alt?

I could also be doing it totally wrong?

It would also be great to be able to drag the origin node and move it rather than have it drop another node. Would this be possible with another modifier key? I've worked out I can do this by moving the movement trail back on itself and then move the newly created node back under the origin node, but this seems a little clunky?

Cheers,

Simon

Oh, and as always, thank you all for your hard work!

The CTRL key used as the snap-toggle for all movement modes. For the GM, use CTRL to initiate the locked token movement, then let go of the CTRL key and the token will snap.

[Verdigris]

Looks good, but I am having issues. Testing on my local machine. When I click the green checkmark to approve the movement, the arrows vanish and no movement is actually carried out. I have disabled all extensions, cross no LOS boundaries. Not certain what I'm doing wrong here.

[Ludd_G]

Hi Carl.

Yeah, I can definitely do that, but it just seems a bit... fiddly to me?

Cheers,

Simon

[Moon Wizard]

@Ludd_G,
We noticed that in our testing as well; and we're thinking about the best way to deal with that. We might just remove Control key snap override; since the snap on/off option is in image data control now.

@Verdigris,
Can you recreate in a new map? Do you know the exact steps you followed?

Regards,
JPG

[Ludd_G]

Hi Moon,

that'd be a lot more straight forward I think.

Cheers,

Simon

[ddavison]

Looks good, but I am having issues. Testing on my local machine. When I click the green checkmark to approve the movement, the arrows vanish and no movement is actually carried out. I have disabled all extensions, cross no LOS boundaries. Not certain what I'm doing wrong here.

There is a bug we just identified with new maps that will occur until you toggle the grid visibility.

[Verdigris]

@Moon Wizard - New map seems to have fixed it. Thank you very much sir! Seems that using a pre-existing combat setup on a map prevented it from working properly.

[Blackwolfe]

Just gave it a test run, Worked PERFECTLY! Thank You FGU Team!

[DwightLee]

Just gave it a test run, Worked PERFECTLY! Thank You FGU Team!

Yeah, this is exactly what I was asking for. Not worried about moves through walls because I wont accept that move, I would just manually move them to the desired location instead.

Its perfect, I love how movement looks so different than targeting... there is no mistaking the two like it was in Classic, this token locking is better than it was in Classic :)

[Kelrugem]

Yeah, this is exactly what I was asking for. Not worried about moves through walls because I wont accept that move, I would just manually move them to the desired location instead.

Its perfect, I love how movement looks so different than targeting... there is no mistaking the two like it was in Classic, this token locking is better than it was in Classic :)

They stop at walls automatically :) (just in case you did not know about that feature, though there is some reported bug about that on the players' side it might look differently)

[Moon Wizard]

Carl has some plans to update the targeting and pointers eventually as well; but token locking was the big item to get out.

Regards,
JPG

[fabiocm]

Really good! I tested as GM only. Waiting for the session next week to see this in action.

One request: Each node could have a confirm/cancel button, so the GM can authorize partial movement.

[darrenan]

The buttons don't seem to work for me. I click the green check mark, the move line goes away and the token stays put.

EDIT: tried on a different map and it worked fine.

EDIT 2: This was the issue Doug called out above where it doesn't work until you turn on the grid.

[Moon Wizard]

@darrenan,
Thanks for the confirmation. We'll have a fix for that one next week.

Regards,
JPG

[Moon Wizard]

So, I just reviewed Photoshop, and it uses Control key for inverting snap behaviors when moving objects, just like we are doing for tokens now.
However, the token locking for GMs was on Control key in FGC, which was brought over; but FGC doesn't have the invert snap option either.

So, my two options to avoid the modifier key overloading (which I plan to do either way) are either to:
A) Move GM token planned movement when token locked to use the Alt key instead; OR
B) Remove invert snap from Control key, and only use for GM planned movement

I'm leaning towards option A for consistency with drawing program shortcut keys. Thoughts?

Regards,
JPG

[Zacchaeus]

I like consistency so I’m with A.

[mattekure]

I like A as well

[Aridhro]

Nice feature!
One question: Can the final waypoint be dragged?
For instance if your player went 5' to far and you don't want to cancel the full movement. Only the last 5'.

[Aridhro]

Carl has some plans to update the targeting and pointers eventually as well; but token locking was the big item to get out.

Regards,
JPG

I'm imagening pointers who look like actual fire balls and cones of ice, targetting every token in its path ... dreaming out loud ;-)

[Ludd_G]

Hi,

I'd vote for B, but I'd be happy with A. The reason I'd vote for B is 'cause I'm struggling to remember not wanting snap to grid to be on in play. I'm sure there are loads of good reasons and I'm more than happy to learn but for now my vote is with B as Ctrl just seems 'right'.

Cheers,

Simon

[Ludd_G]

Oh, and do you think there's any chance of being able to include an option to display GM movement on the player's iteration? This would be great for face-to-face play where I use a players instance to display the maps on a horizontal tv, and this would aid my players in moving all my NPC minis, and save me the hassle of jumping up to do it all the time, if that makes sense?

Cheers,

Simon

[Moon Wizard]

Drag the end point to new position, then drag the new waypoint onto existing waypoint or in the middle.

Regards,
JPG

[Ludd_G]

Nice feature!
One question: Can the final waypoint be dragged?
For instance if your player went 5' to far and you don't want to cancel the full movement. Only the last 5'.

I'd like this as well, it just seems more tidy. As it is though if you move the final way point back to where you'd like it, you can then move the node it's dropped back to that point as well, and it'll be joined with the final waypoint thus removing the unwanted extension of the movement trail, if that make sense?

Cheers,

Simon

[mattekure]

Does the intended movement for NPCs display for players? I used this in classic a lot so players could visually see where the npcs were moving and know if that movement triggered any special reactions or abilities.

[Ludd_G]

Let me check again, but I wasn't getting it to display when I was poking around yesterday....


*Just checked and it can't get the player instance to display NPC movement trails.

[Jiminimonka]

I hope that the themeing for the movement arrows can be modified by the theme being used if it's not already.

[ShaunB]

Any chance we could get a toggle option that lets the players have the same checkmark/cancel confirmation interface that the GM gets? I trust my players not to confirm movement farther than their speed, and I feel that waiting on my confirmation for each move would slow down combat. I'd still really like this feature as a measurement tool to make it easier for my players to see how far they've moved though.

I also agree with the previous comment that some way to move the last node instead of adding new nodes would be nice.

[ddavison]

I hope that the themeing for the movement arrows can be modified by the theme being used if it's not already.

These are not likely to be themeable.

[SilentRuin]

Does the intended movement for NPCs display for players? I used this in classic a lot so players could visually see where the npcs were moving and know if that movement triggered any special reactions or abilities.

As long as the map is shared when you do the CTRL move token on a host - you'll see the token lock movement for PC's and NPC's. IF you do the CTRL move on host then share - you will not be seeing on player side what was done before the map was shared. And of course if the player owns the NPC you'll see it when they just move a locked token.

[Jiminimonka]

these are not likely to be themeable.

ok.

[Ludd_G]

As long as the map is shared when you do the CTRL move token on a host - you'll see the token lock movement for PC's and NPC's. IF you do the CTRL move on host then share - you will not be seeing on player side what was done before the map was shared. And of course if the player owns the NPC you'll see it when they just move a locked token.

Hmmmm, don't know what I'm doing wrong then. I'm not seeing any NPC movement indicators on the players map, and I have the map displayed so it's definitely shared? I think I'm misunderstanding something?

[Moon Wizard]

Token movement is only shown for tokens that are owned or publicly editable by the player. (i.e. owned PCs, and friendly units if Party movement option enabled).

JPG

[Ludd_G]

Hi Moon,

is there any way viewing all movement could be an option? For me it'd just be a massive help for face-to-face sessions (if we ever get to enjoy those again!) and it seems like some others see a benefit for this option in other situations as well.

Cheers,

Simon

[Moon Wizard]

Why would you want players to know where NPCs are moving? Isn't that a bit like player ESP?

Regards,
JPG

[mattekure]

Why would you want players to know where NPCs are moving? Isn't that a bit like player ESP?

Regards,
JPG

I would want for players to be able to see NPC movement because many characters have reactions or powers that may come into play based on the NPCs movement. As a DM I may or may not know all the powers the players have, but being able to see the NPCs movement helps the players announce things like "When he enters into my range, my XXX power will activate as it goes by".

[rob2e]

The fact that players cannot see other players movements seems WHOLLY unacceptable. It changes the game in such a dynamic way. I am putting in my vote for "please change that to the way it used to be" in classic. Also it would be nice if the players could also see the DMs path if the DM decides to show the path (by holding CTRL). Also AS the DM I want to be able to see that path. The new Unity changes for token locking and token movement are so different, it's the first time (so far) I decided to actually post about Unity in a negative fasion on the forums. I REALLLY don't like it. If I'm the only one, well then... but I think this won't be a welcome change amongst most.

[Moon Wizard]

I've asked Carl to investigate what it would take to display token movement path planning on all clients (GM and player).

Thanks,
JPG

[mikegraf]

Hi, thanks for adding the locking feature. Something definitely useful and with some configurable options, would be even better.

I am, however, noticing that the distance calculation seems to work fine if I use a square grid, but seems to be wrong if I use a hex grid, in that it thinks 1 hex away is 5', and 3 hexes away is also 5'.
Is this something to do with the new locking calculation or my grids?

Have also noticed that now tokens can move half way between grid locations when previously they could only move into full open grid spaces. Again, is this a feature (bug) from the new locking or something to do with grids that I (as a relative newbie to FGU) need to correct?

Thanks for any help, guidance or pointers

[rob2e]

I've asked Carl to investigate what it would take to display token movement path planning on all clients (GM and player).

Thanks,
JPG

You're all over it John. Yay Carl!

[bwatford]

Can't the players see the movement if "Group sight" is turned on?

@rob2e?

The only thing we are having an issue with is the movement arrows show up while the player is "planning" when it is someone else's turn and since I as the DM see them all it gets confusing and I have told them to stop planning with the arrows until you turn.

[mattekure]

As a DM I do not allow players to draw movement unless its their turn. If they do I cancel it.

[Ludd_G]

The fact that players cannot see other players movements seems WHOLLY unacceptable. It changes the game in such a dynamic way. I am putting in my vote for "please change that to the way it used to be" in classic. Also it would be nice if the players could also see the DMs path if the DM decides to show the path (by holding CTRL). Also AS the DM I want to be able to see that path. The new Unity changes for token locking and token movement are so different, it's the first time (so far) I decided to actually post about Unity in a negative fasion on the forums. I REALLLY don't like it. If I'm the only one, well then... but I think this won't be a welcome change amongst most.

Hi Rob,

I'm guessing that toggling 'Party Vision and Movement' on in options would allow for players to see each others movement plans?

Cheers,

Simon

[Ludd_G]

Why would you want players to know where NPCs are moving? Isn't that a bit like player ESP?

Regards,
JPG

Hi Moon,

for me it's for face-to-face gaming at the table (or horizontal tv in our case!). Basically, to stop me having to get up move around the table all the time, I ask my players to move all the NPC minis for me, allowing me to stay at the pc which would definitely speed up play. They absolutely can do this with just reference to where I move the token, but seeing the movement trail would be a much more immediate indicator of where they are to move which mini.

I know this is an edge case but I thought it worth asking.

Also, as Mattekure said, it would allow the players to plan and announce any interrupts to the NPC movement (which I hadn't actually thought I needed till he said it! :) )

Cheers,

Simon

[eriktedesco]

Hi all,

I would also like for NPCs movement to be seen by the clients, since quite a lot of stuff could be triggered by the NPCs movement.

Thanks a lot for your hard work!

Erik

[TheFabulousIronChef]

Hi, thanks for adding the locking feature. Something definitely useful and with some configurable options, would be even better.

I am, however, noticing that the distance calculation seems to work fine if I use a square grid, but seems to be wrong if I use a hex grid, in that it thinks 1 hex away is 5', and 3 hexes away is also 5'.
Is this something to do with the new locking calculation or my grids?

Have also noticed that now tokens can move half way between grid locations when previously they could only move into full open grid spaces. Again, is this a feature (bug) from the new locking or something to do with grids that I (as a relative newbie to FGU) need to correct?

Thanks for any help, guidance or pointers

Using the GURPS ruleset, I am also having an issue. See this thread (https://www.fantasygrounds.com/forums/showthread.php?62283-Ranges-on-Maps-Hexes) and these images:

39748
39749

[Seems]

I watched the FGC video on locking tokens, but I'm still a little fuzzy on the details. Does token locking forbid the player from entering a movement path beyond their listed movement? If so, how do you allow for an alternate movement method, such as a Fly spell or the like?

Thanks!

[Seems]

Sorry, double post!

[Zacchaeus]

FG doesn't place restrictions on movement distance at all. So it's up to the players and DM to decide how far they can move.

[Seems]

Got it, thanks!

[Smoltok]

Hello !

Trying to use token lock in FGU but it appears not to work. If I valid the player movement it doesn't move the token at all.
Try many maps..

Any idea ?

[ddavison]

Hello !

Trying to use token lock in FGU but it appears not to work. If I valid the player movement it doesn't move the token at all.
Try many maps..

Any idea ?

Toggle the grid visibility on or off or adjust the grid. There is a known bug that should be resolved in the next release for this.

[lostsanityreturned]

Arrow key wise it might be a good idea to allow for up left, up right, down left and down right to diagonals. I have a number of players who lack numberpads on their keyboards. Usually handled by automatically combining inputs hit within a 50-100ms timeperiod to accommodate keys being pressed together.

As for the theming of the arrows, sad to hear as is they are exceptionally bright and colourful and I frequently run games that are, less than cheery -laughs-.

Some other requests:

- Toggle key that turns it on regardless of whether token lock is on or not (like with the GM but for everyone).

- A key to press as a GM to approve movement and or an option menu toggle to allow players to approve their own movement. Spacebar when hovered is a nice option though. Middle mouse works for legacy reasons too.

[federicacauzer]

Hi all! Just my two cents on that...would it be possible to match the arrow of the token movement with the color of the dice, without gradient (or maybe the possibility to select between these options)?

As such, it would be possible to recognize between the different players movement planning.

Just my two cent. truly amazing work by the way!

Cheers

[hammer58]

I like this lock token feature. However we had a problem using it in our game. Some players could use the arrow keys to move their token waypoints, others had to use the mouse to set waypoints. I could not figure out why some could use the arrow keys and others could not. Please explain this.

[paul23212]

Good evening I just played a game using lock tokens and I found the movement once i approved the move very slow and laggy has anyone else had this issue and please let me know i this is in the wrong place.

[Zacchaeus]

I like this lock token feature. However we had a problem using it in our game. Some players could use the arrow keys to move their token waypoints, others had to use the mouse to set waypoints. I could not figure out why some could use the arrow keys and others could not. Please explain this.

If your players were trying to use the numpad then it only works if numlock is off. Otherwise there's no reason why if they were just using arrow keys for some to work and others not.

[Zacchaeus]

Good evening I just played a game using lock tokens and I found the movement once i approved the move very slow and laggy has anyone else had this issue and please let me know i this is in the wrong place.

Yes, it's a bit slow on bigger maps.

[Ludd_G]

I'd love to have some way to adjust token speed, as my tokens are really sprinting around even on quite large maps (Wave Echo Cave, LoS active and quite a few NPC present). I'm guessing the speed is linked to computer power at this point in development, and as I got a beefy new rig a few months ago it's feel wrongly speeded up, so some level of user adjustability would be great to account for different pc specs.

Cheers,

Simon

[pindercarl]

Yes, it's a bit slow on bigger maps.

The update rate for the tokens is 1/5th of the grid size. So, if the token moves 5 grid spaces, the token would have 25 position updates regardless of the overall map size. If LOS is on, the LOS is calculated at each of the positions.

There was a bug wherein, if the image was unlocked and the layers panel was visible, then this could cause lag if there were a lot of layers. This was only an issue for the GM. Player's should be unaffected. This should have been addressed in yesterday's update.

@paul23212, can you confirm if any of these conditions are present for you?

[Zacchaeus]

The update rate for the tokens is 1/5th of the grid size. So, if the token moves 5 grid spaces, the token would have 25 position updates regardless of the overall map size. If LOS is on, the LOS is calculated at each of the positions.

There was a bug wherein, if the image was unlocked and the layers panel was visible, then this could cause lag if there were a lot of layers. This was only an issue for the GM. Player's should be unaffected. This should have been addressed in yesterday's update.

Yes, I suspected that the tokens weren't just going from square to square in one go. We're playing Dungeon of the Mad Mage so there's a lot going on in the maps in that one as far as LoS is concerned - and they're quite big maps.

[pindercarl]

Yes, I suspected that the tokens weren't just going from square to square in one go. We're playing Dungeon of the Mad Mage so there's a lot going on in the maps in that one as far as LoS is concerned - and they're quite big maps.

I'll add that the update rate for LOS when dragging a token is also 1/5th of the grid size. Accepting a token move should execute at the same speed on the map as normal token drag movement. If they differ, this is an issue that needs to be addressed.

[Zacchaeus]

I'll add that the update rate for LOS when dragging a token is also 1/5th of the grid size. Accepting a token move should execute at the same speed on the map as normal token drag movement. If they differ, this is an issue that needs to be addressed.

I have no yardstick as to what you expect so here's a video :) https://youtu.be/QhNOHOwR3EI

[pindercarl]

I have no yardstick as to what you expect so here's a video :) https://youtu.be/QhNOHOwR3EI

Thanks, Zacchaeus. How does that compare to moving the token with token locked disabled?

[Zacchaeus]

Thanks, Zacchaeus. How does that compare to moving the token with token locked disabled?

Here you go https://youtu.be/LoNr9Z_5lI0

[rob2e]

So, I just reviewed Photoshop, and it uses Control key for inverting snap behaviors when moving objects, just like we are doing for tokens now.
However, the token locking for GMs was on Control key in FGC, which was brought over; but FGC doesn't have the invert snap option either.

So, my two options to avoid the modifier key overloading (which I plan to do either way) are either to:
A) Move GM token planned movement when token locked to use the Alt key instead; OR
B) Remove invert snap from Control key, and only use for GM planned movement

I'm leaning towards option A for consistency with drawing program shortcut keys. Thoughts?

Regards,
JPG

Why are we CHANGING things? Should things be left as they were in CLassic? Add new, not change old? I FEAR CHANGE. But seriously, this is a real pain the new way. Are people not complaining about this? Just me... ???

[Moon Wizard]

In this case, we are working to make the keys more consistent across various features; so we had to move off Control which is used for "inverting" behaviors.

Regards,
JPG

[Jiminimonka]

Why are we CHANGING things? Should things be left as they were in CLassic? Add new, not change old? I FEAR CHANGE. But seriously, this is a real pain the new way. Are people not complaining about this? Just me... ???

Change is good. Just move the finger a.bit to the other button. Bumbashoot guvna oh snap

P.S. Classic is old and clunky and that's why FGU is being made.

[Zacchaeus]

Why are we CHANGING things? Should things be left as they were in CLassic? Add new, not change old? I FEAR CHANGE. But seriously, this is a real pain the new way. Are people not complaining about this? Just me... ???

Yep. Just you :)

[muklin]

It seems the distance calc is always wrong on the first jump, and ok after that. Not sure if its because of my diamond grid or iso-ish skew?


39960

[kevininrussia]

The update rate for the tokens is 1/5th of the grid size. So, if the token moves 5 grid spaces, the token would have 25 position updates regardless of the overall map size. If LOS is on, the LOS is calculated at each of the positions.

There was a bug wherein, if the image was unlocked and the layers panel was visible, then this could cause lag if there were a lot of layers. This was only an issue for the GM. Player's should be unaffected. This should have been addressed in yesterday's update.

@paul23212, can you confirm if any of these conditions are present for you?

LOS ON: I am having very slow movement on player side after DM selects the check mark for movement. To move 13 squares the token on DM computer took 7 seconds. On the players computer it was 18 seconds.

LOS OFF: token movement is very fast on the DM computer (1 second), fast but not as fast as DM on Players computer (4 seconds).

[pindercarl]

I am having very slow movement on player side after DM selects the check mark for movement. To move 13 squares the token on DM computer took 7 seconds. On the players computer it was 18 seconds.

If this with or without LOS enabled?

[kevininrussia]

If this with or without LOS enabled?

I answered above. Sorry, must have been editing it while you were writing.

[LordEntrails]

Weren't their performance issues with LOS if the GM had the image control window open and maybe if they were not in Play mode but were editing at the time?

[kevininrussia]

Weren't their performance issues with LOS if the GM had the image control window open and maybe if they were not in Play mode but were editing at the time?

I thought that was fixed in last update.

I had LOS on, image control window open and was in Play mode.

[kevininrussia]

Token speed test player side video on Windows 10 Surface i5 2018 model. LOS and Mask is on and on DM's side the image side panel is open.


https://youtu.be/7mhi4waG_Pw

[muklin]

New version seems to have fixed my above issue, btw.

[jrowsey1]

I am having the same issues with slow token movement while LOS is enabled. This is from the GM's side.

https://youtu.be/y02moeVi_0A


MacBook Pro 16" 2019
2.6 GHz 6-Core Intel Core i7

10/08/2020 FGU update

[seycyrus]

I am having the same issues with slow token movement while LOS is enabled. This is from the GM's side.

https://youtu.be/y02moeVi_0A


MacBook Pro 16" 2019
2.6 GHz 6-Core Intel Core i7

10/08/2020 FGU update

Video is private.

[jrowsey1]

Oops! Public now.