LUA : get / set scene value

  • #10, by afrlmeWednesday, 18. February 2015, 11:27 10 years ago
    Some of the stuff is still not accessible with shorthand. It's early days, but it's working a lot better now than the first time Simon tried implementing it.

    It would be impossible & unrealistic for me to even attempt providing documentation for all the different getobject, direct path & shorthand methods of accessing the / writing to the data structure fields & tables.

    Imperator

    7285 Posts


  • #11, by LebosteinWednesday, 18. February 2015, 11:33 10 years ago
    I think the "shorthand" method should be the main method! That is clear, easy to learn and very logical. At the moment that lua thing acts and increases without clear concept in my eyes. For the user it is very, very confusing if there are more than one possibilities to set and get parameters. Wihich method is the best? Why some things don't work with one method and not with the other method? The confusion increases even more if some users use the one and other users use the other method in forum example codes....

    Key Killer

    621 Posts

  • #12, by afrlmeWednesday, 18. February 2015, 11:59 10 years ago
    Quite a few people are still using 3.7.1 (for some reason), so the getObject method can't really be dropped. I added some shorthand methods to the scripting page last month when I rewrote it. I've just a few sections at the end of that page to finish updating, but they aren't particularly important, so they can stay as they are for now.

    The getObject method is the safest method, especially in combination with direct linking to the specified data structure field or table.

    I think everything can be accessed globally with shorthand, it's just that currently some of the fields can't be directly accessed, or maybe that is just on your current build.

    quick note: object, character, animation, value, condition names (etc) are case sensitive.

    Imperator

    7285 Posts

  • #13, by afrlmeWednesday, 18. February 2015, 12:14 10 years ago
    Ok so I've tested multiple shorthand methods & they all work in the current build of the engine I'm running; please note that I am using a team build & not the current public build, so I have additional bug fixes & features that should be included in the next release.

    I've added a value to my main character "jacob" & I've called said value "v_test" & set the initial value to 10. I tested accessing & writing to the values via the console (tab) with the exec command.

    print( Characters["jacob"].CharacterValues["v_test"].Int ) -- returned 10
print( game.CurrentCharacter.CharacterValues["v_test"].Int ) -- returned 10

Characters["jacob"].CharacterValues["v_test"].Int = 20 -- updated value to 20
game.CurrentCharacter.CharacterValues["v_test"].Int = 20 -- same as above

    ...I tried printing them afterwards & they both returned 20 as they should have done. So my conclusion is that it could be that you've either written the names out wrong or that something has changed between the public build & the team build I am using.

    Imperator

    7285 Posts

  • #14, by LebosteinWednesday, 18. February 2015, 23:44 10 years ago
    Sorry, it don't work here! Could it be a Mac OS bug?

    Works:
    getObject("Characters[char_hans].CharacterValues[money]"):setValue(VValueInt, 20)

    Don't work:
    Characters["char_hans"].CharacterValues["money"].Int = 20

    Key Killer

    621 Posts

  • #15, by LebosteinWednesday, 18. February 2015, 23:57 10 years ago
    If it works (someday or next release) how I change the string value? With .String? And why this syntax don't follow the data structure: .ValueInt .ValueString ?

    Key Killer

    621 Posts

  • #16, by afrlmeThursday, 19. February 2015, 00:10 10 years ago
    Because it is shorthand. The idea is to reduce the amount you need to type. To be honest the naming convention of data structure fields & tables is not that good. Most names could have been much shorter. Why bother writing VValueString? it might as well have just been "string" or "str" even. For me some of the names are ridiculously long.

    Let's see...

    game:getLink(VGameCurrentCharacter) -- could have simply been CurrentCharacter, as we already know it's part of the game table, so why bother declaring the table name at the beginning of each word?

    Then we have doubled words like...
    getObject("ActiveActions[test]"):getInt(VActionActionPartIndex) -- I understand that it can't simply be PartIndex as that would not mean anything to anyone, but ActionAction? grin

    This is only a couple of examples. The data structure is plagued by stuff like this though.

    Imperator

    7285 Posts

  • #17, by AlexThursday, 19. February 2015, 01:19 10 years ago
    “
    The idea is to reduce the amount you need to type. To be honest the naming convention of data structure fields & tables is not that good. Most names could have been much shorter.
    „


    once you start with abbreviations you'll get hard to read names, e.g. CurHorScrollDist. And maybe some names get abbreviations and others don't which results in inconsistent names.

    “

    Then we have doubled words like...
    getObject("ActiveActions[test]"):getInt(VActionActionPartIndex) -- I understand that it can't simply be PartIndex as that would not mean anything to anyone, but ActionAction? grin
    „

    the first part is always the table name, kind of a prefix. it makes code less error prone since you immediately see to which table a field belongs.

    “
    This is only a couple of examples. The data structure is plagued by stuff like this though.
    „

    Actually it is a very consistent naming scheme and was done that way on purpose.

    Great Poster

    378 Posts

  • #18, by LebosteinThursday, 19. February 2015, 11:06 10 years ago
    “
    The idea is to reduce the amount you need to type.
    „

    No. The idea is a clear, logic and readable code I think. At the moment the mix of functions, long strings and attached methods to set a simple value for example is very hard to read and not in the sense of an object-oriented language:
    getObject("Characters[jacob].CharacterValues[money]"):setValue(VValueInt, 20)

    The "shorthand" method is clean, logic and easy to read, like any other object-oriented language. This follows a simple and logic tree structure:
    Characters["jacob"].CharacterValues["money"].Int = 20

    This is optimal! But the developers should use a consistent name convention! See the .Int in the last example. A "Character" has the following parameters:

    Character: (see here)
    * CharacterActions
    * CharacterConditions
    * CharacterDialogs
    * CharacterFont
    * CharacterValues
    * CharacterOutfits
    * ... and so on

    The data type of "CharacterValues" is a link to a "Value". And a "Value" has the following parameters:

    Value: (see here)
    * ValueInt
    * ValueRandom
    * ValueRandomMax
    * ValueRandomMin
    * ValueString

    Therefore, the correct syntax should be:
    Characters["jacob"].CharacterValues["money"].ValueInt = 20
Characters["jacob"].CharacterValues["money"].ValueString = "Euro"

    If you shorten your name convention, then you should short it consistently by removing the redundant prefixes, like that:

    Characters["jacob"].CharacterValues["money"].ValueInt = 20
    Characters["jacob"].CharacterValues["money"].ValueString = "Euro"
    Characters["jacob"].Values["money"].Int = 20
Characters["jacob"].Values["money"].String = "Euro"

    The last one is the optimal thing but I can live with the long version above. But a consistent and documented naming convention (without arbitrariness and without compromises) is extremely important in my eyes!

    Key Killer

    621 Posts

  • #19, by AlexThursday, 19. February 2015, 13:01 10 years ago
    I wasn't aware of the shortened field access (Int instead of ValueInt). As you said this is not consistent and I think this should be removed because it confuses people when there are multiple options to do the same thing.

    btw, you can already write
    Characters["jacob"].CharacterValues["money"].ValueInt = 20

    actually also the fully shortened version works:
    Characters["jacob"].Values["money"].Int = 20

    although it gives a log error.

    Great Poster

    378 Posts

  • #20, by LebosteinThursday, 19. February 2015, 13:14 10 years ago
    I think I have to wait for the official build to test this. In 4.1 this "shorthand" method seems not finished. I would also work as a beta tester, if it is possible.

    Key Killer

    621 Posts