Using values strings to control object visibility

  • #1, by i-c-gSaturday, 02. January, 18:20 2 weeks ago
    Hi everybody.

    I'm struggling with what seems to me a silly problem.
    I have two objects placed on my scene (the main menu actually), and I want to show them depending on the selected language.

    I know the "Conditions" section of the object properties allows me to show the object depending on Values, and I know Values can contain strings as well as ints.

    My proplem now is, it seems that Visionarie allows me to only test Ints in a value in the Properties section of the object. It seems I can't test the string in the Value to turn the object on or off.

    I'm pretty sure I'm missing something... what should I do to make use of Value string in that context?

    Thanks everybody


    13 Posts

  • #2, by afrlmeSaturday, 02. January, 19:55 2 weeks ago
    Because that's only possible with Lua. What you could do is assign a number instead & at begin of scene you could use the if lua result action part or execute a script action part, to check the language & update the values as needed.

    I would probably do something like this...

    execute a script:

    Values["example"].Int = game.StandardLanguage:getId().id

    What you are essentially doing there is telling it to set the integer value to whatever the ID value of the language is. The first language you create will be 0, then 1, & 2, & so on. It just keeps on incrementing. If you aren't sure what ID belongs to which language, you can right click on a language in the list & select copy id. Paste them into a notepad or something so you can keep track of them.

    Alternatively, if you want you could create a table manually & use that instead.

    execute a script:

    local t = {

    English = 1, German = 2, French = 3


    Values["example"].Int = t[ game.StandardLanguage:getName() ]

    That's 2 methods out of multiple other solutions that are probably available.


    6896 Posts

  • #3, by i-c-gSaturday, 02. January, 21:08 2 weeks ago
    Thanks AFRLme, using the language id is a nice trick.

    Sadly, any int-based solution makes things almost unreadable... having the ability to use the value String as a first-class citizen in the game editor would be great. Strange it's not possible, from a user perspective seems a no-brainer to me...

    Maybe in a future version of VS they'll add this feature.
    In the meantime, thanks for your help! Very appreciated


    13 Posts

  • #4, by afrlmeSunday, 03. January, 12:26 A week ago
    I think it's not included because by default you can't update the string table of values without using script. Maybe he will see this & add it? Maybe he'll even add an action part for updating the string table belonging to values? Maybe...

    Actually I like the int based value approach because it let's me get creative with state based approaches, such as:

    • object locked
    • object unlocked
    • object open (item inside)
    • object open (empty)

    From a single value I can control the states of multiple objects. Also don't forget with values that you have multiple different query operators, such as:

    • equal to
    • does not equal
    • less than
    • less than or equal to
    • greater than
    • greater than or equal to
    • etc.

    The second solution I gave you (in my last post) is all you need. Actually, if the objects in question you want to change aren't going to be affected by the player, then you could technically use the same VS value for all of them & just call the second script example I shared with you to update the value. There shouldn't be any need to create a value for every single thing unless it's something the player can interact with & change in some way.


    6896 Posts

  • #5, by i-c-gSunday, 03. January, 16:32 A week ago
    I second your thoughts but I still think that adding actions and interfaces to manage string values would be a great addition.

    If I can dare, I would also ask for a callback to be registered as condition, so you can implement your Lua logic and leave the "interactive code" alone (but I understand a part of VS audience prefer not to code).

    That said, having strings for Lua only and Ints as sole option for the rest seems to me a half-baked solution. I think it's common since things evolve incrementally in a product like this. Hope strings will be supported soon for readability sake.

    As for the associative table, it makes sense but it's still unreadable from an interface perspective. Still ATM it's the best way to solve such situation.



    13 Posts

Write post