Results 1 to 4 of 4

Thread: Workaround for Player Based UI Elements

  1. #1

    Workaround for Player Based UI Elements

    I am making a D&D Framework for using TTS to play D&D.

    In this regard, I have a number of UI buttons which perform various rolls for each of the characters in the game. On their own these buttons work correctly.

    Since there are a larger number of these buttons, I don't want to attach them to the character tokens because they would make the display cluttered especially in combat situations where multiple character tokens are close together. As such I added the UI buttons as general UI buttons allowing them to be at the side of the screen and staying there no matter where the player's camera is looking. Again, this all works.

    However, since the game has multiple players, I generate the UI buttons for each player and added visibility so that that each set of buttons is only available to the corresponding player. So, for example, Red player sees only the buttons for the character associated with the Red player.

    When I tested this concept, I found that TTS has a bug which causes buttons that are not visible to capture button clicks and do nothing with them. This, in turn, prevents the player from using his/her set of buttons because the non-visible buttons (for that player) capture the click events and prevent the visible buttons from functioning.

    The issue has been identified in post: http://www.berserk-games.com/forums/...e-Click-Events

    As far as I can tell, this problem occurs when two or more buttons (regardless if they are visible or not) share the same screen space. As such the only solution that I can come up with is for each player's buttons to be in a different location. For example, one player's buttons would be at the right side of the screen, one on the left side, one near the top and one near the bottom. This poses a difficulty because the number of buttons I have per character exceeds one side of the screen. For example, one character has combat related buttons along the side and skills along the bottom. With 4 characters in the game, I don't think I can position the buttons so that none of them overlap.

    I was also toying with the idea of using buttons (not UI buttons) on objects to hold the menu. Since I don't want these to be attached to the player tokens, I was thinking of making a "menu object" for each player: basically a cube to which all character's buttons are attached. This would allow the player to have his set of buttons where he/she wants but it also means having to move the menu object when panning around the screen. I also need to confirm that the UI issue is not present with object based (non-UI) buttons.

    Attached is a sample screen shot of the UI buttons for Red player. As you can see they take up the right side and bottom side of the screen. However, the buttons for other players (which are only visible to those players) take up the same space as the ones for Red player. Normally this would not be a problem since only one set of buttons is visible at a time (depending on the player color) but due to the TTS bug, the buttons don't work because the non-visible buttons prevent the visible buttons from being used.

    Does anyone have an alternate work-around suggestion as to how I can get working player specific buttons visible to player? (i.e. 30 buttons visible only to Red player, another 30 buttons visible to Blue player, ...)
    Attached Images Attached Images

  2. #2
    Workaround:

    Create smaller menus for players so that none of them overlap and provide buttons for swapping menu pages. This is what I did in my RPG Framework @ https://steamcommunity.com/sharedfil...?id=1838539309

  3. #3
    You might just have to reuse one set of buttons for everyone and instead identify the player who pressed the button on the Lua side of things. The "Player" object will be the first argument passed to every onClick event.

  4. #4
    Quote Originally Posted by JTE_ View Post
    You might just have to reuse one set of buttons for everyone and instead identify the player who pressed the button on the Lua side of things. The "Player" object will be the first argument passed to every onClick event.
    While that is a possibility, I don't like it because the button labels cannot be unique. As such this would work for stats that are common to all players but it does not work for custom rolls. For example, a fighter has multiple weapon macros while a magic user has multiple spell macros. Since the button would only have a single label, it would be hard for the players to figure out what roll was attached.

    The page swapping solution seems to work well. The most common rolls (for each player) are on the first couple of pages for quick access but the rest of the rolls can be found on subsequent pages. Each player can have their own number of pages and thus the GM can make as few or as many macros for each player that the desire.

Similar Threads

  1. Clicking Through XML Elements
    By berserk3k in forum Scripting
    Replies: 3
    Last Post: 07-28-2018, 01:37 AM
  2. Error after 10 UI elements created
    By rjotanm in forum Scripting Bug Reports
    Replies: 0
    Last Post: 06-25-2018, 06:10 PM
  3. [SUPPORT] Host timeouts, looking for a workaround for a slow-paced game
    By plasticus in forum Technical Support
    Replies: 1
    Last Post: 06-10-2018, 05:53 AM
  4. Scripting chat commands/2D UI elements?
    By 343N in forum Scripting
    Replies: 3
    Last Post: 10-09-2017, 06:37 AM
  5. semi-lock physics workaround
    By Nedok1 in forum Scripting
    Replies: 4
    Last Post: 06-17-2017, 10:27 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •