combined ("and"-)conditions are counting always as "false" in LUA

  • #1, z sebastianMonday, 29. August 2016, 00:05 hodinky 8 years ago
    Hey there,

    while doing some LUA stuff this day I recognized that conditions which are "combined" are always "false". Even if the two condition parts of it are true.
    Is this right? How do i check if a combined condition is true?

    Do i really have to check both separate condition parts for itself or am I doing something wrong?

    kind regards
    Sebastian

    Kapitán

    2346 Posts


  • #2, z afrlmeMonday, 29. August 2016, 00:40 hodinky 8 years ago
    You are talking about combined conditions created inside of the Visionaire Studio editor? Actually, I've never tried querying a combined and/or condition with Lua script before. It's simple enough to query multiple instances of conditions with Lua script though, so just query the two conditions or as many conditions / values as you like with Lua script directly...
    if Conditions["x"].ConditionValue and not Condition["y"].ConditionValue then
 -- do something
end


    if game.CurrentScene.SceneConditions["x"].ConditionValue then
 -- do something
end


    if game.CurrentScene.SceneObjects["example"].ObjectConditions["x"].ConditionValue then
 -- do something
end

    ... I guess you get the idea! You can create some fairly complex if queries with Lua script compromising of various different query types from boolean, to integer, to float, to "string", etc.

    Imperátor

    7285 Posts

  • #3, z sebastianMonday, 29. August 2016, 00:55 hodinky 8 years ago
    just looked up in the wiki. As guessed when the condition is a "combined" version, TRUE and FALSE are not valid here. It just links to the two sub parts.

    Kapitán

    2346 Posts

  • #4, z afrlmeMonday, 29. August 2016, 01:02 hodinky 8 years ago
    Aye it seems you have to query both of them...
    local var = Conditions["combined_example"]

if var.Condition1.ConditionValue and var.Condition2.ConditionValue then
 print("true")
else
 print("false")
end

    Not really much point to doing that with Lua script. Same amount of work more or less as querying individual conditions.

    Imperátor

    7285 Posts

  • #5, z sebastianTuesday, 30. August 2016, 08:15 hodinky 8 years ago
    thanks, mate. I think this is a great addition to the workflow functions in the wiki. something like

    condition(conditionname)
    condition(objectname.conditionname)
    condition(scenename.objectname.conditionname)

    function should split up the string at each "." and build the VS correct string, then checks if the condition is combined or not.
    if not, return its state (true/false)
    if combined then get its childs and return their and/or combined value

    only problem i see here is what the syntac should look like when requesting something from interfaces, characters, etc...

    Kapitán

    2346 Posts

  • #6, z sebastianTuesday, 30. August 2016, 08:18 hodinky 8 years ago
    i guess it is suffivient to just use condition(conditionname)...

    Kapitán

    2346 Posts

  • #7, z afrlmeTuesday, 30. August 2016, 11:37 hodinky 8 years ago
    It's possible to use .name for pathing as both...
    game.CurrentScene.SceneObjects.object_name.ObjectConditions.condition_name.ConditionValue

    or...
    game.CurrentScene.SceneObjects["object_name"].ObjectConditions["condition_name"].ConditionValue

    are valid.

    Conditions on it's own can be used globally, but only be used if you are using unique names for each of your conditions, otherwise direct path linking is desired as it's the safest method.

    Anyway... I believe I already added some workflow stuff for conditions, no?

    Imperátor

    7285 Posts

  • #8, z sebastianTuesday, 30. August 2016, 11:55 hodinky 8 years ago
    i only found setcondition in the wiki

    yeah i know that the conditionnames should be globally unique for this to work.
    setcondition in the wiki does the same^^

    Kapitán

    2346 Posts

  • #9, z afrlmeTuesday, 30. August 2016, 12:05 hodinky 8 years ago
    I think I wrote that workflow function back before we had shorthand, as it was supposed to just get rid of having to type out the full getObject() method...
    getObject("Conditions[condition_name]"):getBool(VConditionValue) -- I think it was... been so long since I used getObject method, I can't really remember.

    The only thing your workflow functions would save on is having to type .ConditionValue at the end, so not much point really.

    Imperátor

    7285 Posts

  • #10, z sebastianTuesday, 30. August 2016, 18:02 hodinky 8 years ago
    ah ok. wasnt sure about the short hand method. =)

    Kapitán

    2346 Posts