Results 1 to 6 of 6

Thread: Contextual menu options through Scripting

  1. #1

    Exclamation Contextual menu options through Scripting

    It would be REALLY powerful to be able to add scripted options to the right-click menu with scripting.

    Imagine a scripted object where you could flip certain booleans, choose from an enum-like table, choose a color from a color wheel and more, all in order to change certain aspects of that object. One very useful element you could add to that is linking to other objects (which would work the same as getObjectFromGUID()). This would be really powerful for both creating scripted objects AND allowing them to be used in other mods.

    Here's an example of how it could be used: I have a little flat square that counts the number of chips above it and displays the count on a texttool text box. I could right-click, go to the "scripting" sub-menu, and I could click the "target object that counts" option to select another object. That object would now be the one that this counts chips from (i.e. the Physics.cast() would happen from THAT object). Another option in the "scripting" sub-menu could be "show cast" which would turn on the debug of the Physics.cast to true so you could see the shape of the cast on the new object. And you could have even more.

    On the scripting side, you'd assign variables to be "shown" in the context menu, probably with a function called something like addVariableToContextMenu(var variable, int index, string name, string description). The index is for ordering the variable, name is the name shown for that variable in the context menu, description is the text that shows up when mousing over the option. Would also be nice to have a function called addSeparatorToContextMenu(int index) that inserts a separator between the options in the sub-menu.

    Here's a list of the types of things that we could see in a scripted context menu:
    • Variable: changing values of a variable
    • . . Numbers, strings: simply changing a number or a string for either of those types
    • . . Colors: Clicking that opens the color wheel to select a color
    • . . Players: Click this then click a player name in the top right (or maybe a hand zone) to select a player
    • . . Objects: Click this then an object to change a targeted object (this would be one of the most powerful ones imo)
    • . . Zones: Click this to reveal each zone on the table, and then click a zone to select.
    • Functions: clicking one of these calls a function in the script, allowing for potentially more discreet adjustments to tools.
    • Separators: separates what's in the context menu, to keep it looking clean

    The goal is to make scripted components be more flexible, versatile, and MUCH more useable for people that don't know how to script. You can write instructions on how to change stuff for porting a tool, but the vast majority of people won't ever go to the trouble of trying to change anything with code, even something as simple as a variable. I really think something like this could make a huge difference for the entire TTS community.
    Last edited by Unreal_Ed; 05-14-2019 at 10:29 AM.

  2. #2
    If this gets added, it would also be really nice to see a new permission called "scripting context menu" that would allow players to access the scripting context menu, EVEN IF the "context menu" permission is disabled (since you might want to allow acess to scripting options WITHOUT allowing access to locking, toggles, etc)

  3. #3
    A simpler but also very powerful addition would simply be custom buttons in the context menu. Basically, just like there's a button for "delete" or "copy", we could add our own buttons to do specific things inside the code.

    For example, clicking the "deal to evil players" button I'd add would simply call the dealToEvilPlayers() function on that object

  4. #4
    I think making this an extension of the existing UI api would be great - no need to complicate things with two individual UI systems. There can just be a section of the context menu that will render the object's ContextMenu UI so long as it is there. Maybe <Object>.ContextMenu could be another instance of the UI api?

  5. #5
    Seems like you could get this effect (and lots more) by letting the script pass a click it has intercepted to the next layer of the UI. That is, whatever would have received the click it your button wasn't there.
    Then you put a transparent button on whatever, catch clicks you want, and pass the rest on. I would much like this so I can add features to existing elements.

    It would also resolve another of my complaints, buttons on objects intercept clicks on TTS UI elements that cover them up. When I have the file selector up, I cannot click on any item that has a button UNDER it.

  6. #6
    Quote Originally Posted by MoreThanTom View Post
    I think making this an extension of the existing UI api would be great - no need to complicate things with two individual UI systems. There can just be a section of the context menu that will render the object's ContextMenu UI so long as it is there. Maybe <Object>.ContextMenu could be another instance of the UI api?
    There are advantages to having a new system: It would be much faster to implement than having to create a whole working UI, ESPECIALLY for simple functionality (in my idea, it's as simple as calling a function); it would match the current look of the context menu perfectly;

    But of course there are disadvantages to a new system too: You couldn't create a really complex set and beautifully laid out set of options as you could with the XML UI.

    Also, it COULD be easier to implement the XML UI into the current context menu, or it might not. They are different systems and so they might not mesh well. That's for the devs to know though.

    - - - Updated - - -

    Quote Originally Posted by cche View Post
    When I have the file selector up, I cannot click on any item that has a button UNDER it.
    This seems highly desirable though. If, for example, I tried to click on the Components menu and it instead activated the button on the object BEHIND the Components menu, I'd be pretty pissed!

Similar Threads

  1. Dont hide contextual menu
    By 13eforeu in forum Suggestions
    Replies: 0
    Last Post: 12-18-2018, 11:06 PM
  2. Custom contextual menu items
    By danbopes in forum Scripting Bug Reports
    Replies: 1
    Last Post: 09-29-2017, 07:09 PM
  3. [SOLVED] Menu missing options: Can't get GUID from a scripting zone?
    By qvazzler in forum Scripting
    Replies: 5
    Last Post: 01-23-2017, 08:07 PM
  4. Disable Contextual menu
    By Concerned Party host in forum General Discussion
    Replies: 2
    Last Post: 04-02-2016, 03:56 AM
  5. Replies: 6
    Last Post: 09-28-2015, 12:38 PM

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
  •