Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account
This post has been closed. You can still view previous posts, but you can't post any new replies.

Flight Height and distance

First there needs to be a section on the tokens that is able to be set by either player or GM based on the control settings to label Flight indicators. How high someone has flown up into the air. Second, there needs to be like a mouse over option if you prefer. How it's done isn't really a concern to me as long as it is able to be viewed.  Third, ( optional) if two tokens have their flight height filled out. We could use a tool or method to determine the distance between the two. This would help give people a way to judge how far they have to move with out taking game time to figure it out.   Tags: Fly Speed, Flight Speed, Flying Speed, Flight Distance, Fly, Flight, Flying
1521697090
Chris D.
Pro
Sheet Author
API Scripter
Compendium Curator
This is easily accomplished using existing tools. At our table we simply have the player or GM assign the token the "anglewings" status marker, with a numeric badge indicating flight height. For example a 4 means the character is 4 hexes above the ground. 
Chris D. said: This is easily accomplished using existing tools. At our table we simply have the player or GM assign the token the "anglewings" status marker, with a numeric badge indicating flight height. For example a 4 means the character is 4 hexes above the ground.  That is nearly the same way I do it in my campaigns, but I use two of the color indicators, so you can use even higher numbers (you can   read about it in detail here ).
1521717164

Edited 1521717213
That is not a fix Chris. That is a work around. That is what I have right now. With the use of the "bars" it's a cobbled band aid. I see a lot f replies like this. Replies that indicate that a suggestion is not good enough for votes or implementation unless it cannot be replicated in anyway in game  so sorry. As a paying customer, that's not satisfactory.  It would be like Facebook telling it's users, I know an instant messaging feature would be really great, but did you know you can just talk to each other on their wall directly?  I appreciate your response and that is a great idea until a real solution is introduced. 
Well, this is exactly what the status indicators are for. Alternatively, you can use one of the three bubbles to enter a flight height value (I use the center bubble for health, the second for the AC value and the third as "helper field" for all kind of values, like the flight height.
1521730794

Edited 1521730887
Ada L.
Marketplace Creator
Sheet Author
API Scripter
Game Master said: That is not a fix Chris. That is a work around. That is what I have right now. With the use of the "bars" it's a cobbled band aid. I see a lot f replies like this. Replies that indicate that a suggestion is not good enough for votes or implementation unless it cannot be replicated in anyway in game  so sorry. As a paying customer, that's not satisfactory.  It would be like Facebook telling it's users, I know an instant messaging feature would be really great, but did you know you can just talk to each other on their wall directly?  I appreciate your response and that is a great idea until a real solution is introduced.  In their defense, Roll20's development team is a lot smaller than Facebook's. There are a lot of features that would be great to implement, but they have to prioritize which ones they're going to work on. These features all take some time to plan, design, implement, and test. If a feature like this were done, it would also make more sense that not just tokens have height counters, but terrain gets height as well. Perhaps a better way to design this would be to have a topological map feature that allows users to draw topological contours defining the elevation of areas on the map. Perhaps these contours would be drawn on a new layer, perhaps called the "topology" layer. By default, tokens would have a elevation set to whatever the elevation is in the topological area of the map they're standing in. Then, sure, for flying/burrowing creatures, there could be a widget to adjust this elevation. It would be more difficult though to decide then how Euclidean distance is going to work for the measurement tool. Should the distance use start and end points located on the ground? Should we assume that the start and end points have the same elevation? If either of the endpoints overlap a creature, should we use their elevation instead? This is a more difficult design decision, since on the VTT we are working with a top-down 2D projection instead of a 3D perspective projection.
Arthur B said: Well, this is exactly what the status indicators are for. Alternatively, you can use one of the three bubbles to enter a flight height value (I use the center bubble for health, the second for the AC value and the third as "helper field" for all kind of values, like the flight height. No, that's what they have been made to do by the users. They are "catch-all" text fields. Nothing more. They aren't dynamic or special in any real way. And that's ok for things that don't merit specific attention. But in Table Top RPG, there are numerous variables that easily clutter up a game board. The solution should point to working with the existing token or in said above topography instead of forcing a user to work out side of a design. I tend to disagree Stephen L. said: Game Master said: That is not a fix Chris. That is a work around. That is what I have right now. With the use of the "bars" it's a cobbled band aid. I see a lot f replies like this. Replies that indicate that a suggestion is not good enough for votes or implementation unless it cannot be replicated in anyway in game  so sorry. As a paying customer, that's not satisfactory.  It would be like Facebook telling it's users, I know an instant messaging feature would be really great, but did you know you can just talk to each other on their wall directly?  I appreciate your response and that is a great idea until a real solution is introduced.  In their defense, Roll20's development team is a lot smaller than Facebook's. There are a lot of features that would be great to implement, but they have to prioritize which ones they're going to work on. These features all take some time to plan, design, implement, and test. If a feature like this were done, it would also make more sense that not just tokens have height counters, but terrain gets height as well. Perhaps a better way to design this would be to have a topological map feature that allows users to draw topological contours defining the elevation of areas on the map. Perhaps these contours would be drawn on a new layer, perhaps called the "topology" layer. By default, tokens would have a elevation set to whatever the elevation is in the topological area of the map they're standing in. Then, sure, for flying/burrowing creatures, there could be a widget to adjust this elevation. It would be more difficult though to decide then how Euclidean distance is going to work for the measurement tool. Should the distance use start and end points located on the ground? Should we assume that the start and end points have the same elevation? If either of the endpoints overlap a creature, should we use their elevation instead? This is a more difficult design decision, since on the VTT we are working with a top-down 2D projection instead of a 3D perspective projection. In the software development world I'm used to (scrum/agile) you would not stop or never start a project simply because it is too complex. You would decide what would bring the most value to the stakeholder/user whatever, get your requirements and start there. If your sprint won't allow you to finish then you splice the work you can do and deliver as often and as early as you can.   Now, I understand that Facebook is larger than Roll20. My comparison was for easy understanding of the root problem with these forums not the difference in dev teams themselves. A better comparison would be to say to Ford before power windows started: We would like a switch to control a motor to roll down our window for us in our sedans. To which they reply: "That isn't really needed, they have a hand crank to raise and lower the window."  To your other point however, in development you do not say, User x wants flight and distance calculated into tokens and then go we will also work on topography. That is separate feature. Separate development.  You risk not getting anything done. Which I fear is why we still have 2 years + waiting on knock-out-of-the-park requests like macro folders. Because the user base is too busy defending Roll20's dev team and not demanding timely requested features. They aren't raking in facebook or ford money, but I promise you, they are making money.  I sympathize with the work that goes into this great platform, but that doesn't free them from the repsonibiity of creating quality content on a timely basis either :)
Game Master - sounds like you know a little bit about how to do this, have you thought about trying to get involved?
Thanks for the suggestion! After 30 days, Suggestions and Ideas with fewer than 10 votes are closed and the votes are refunded to promote freshness. Your suggestion didn't build the right momentum this time, but feel free to submit it again! We find that the best suggestions describe the problem you are having, and the solution you want. You can learn more about the process of making suggestions on the Roll20 Wiki! More details can be found here .