Results 1 to 10 of 10

Thread: Help with conceptual understanding of x, y, z and [1], [2], [3] in pos tables

  1. #1

    Help with conceptual understanding of x, y, z and [1], [2], [3] in pos tables

    So i've rather fluently used getPosition() and setPosition() for a bit now, but I ran into a strange issue that had me puzzled for a bit.

    Simplified version of case:

    I use a custom function to run through the process of spawning in objects from a bag, using takeObject() and placing them on placeholders.

    You feed the function the variable. It gets the position of the placeholder using getPosition() and takes out the relevant object using takeObject() with params.position being one of the params.

    Here's the issue.

    In order to place the object slightly above the placeholder, I would use
    params.position = placeholder.getPosition()
    params.position[2] = params.position[2] + 2

    If I printed the results, it would show the x, y, z coordinates of the placeholder with the additional +2 to the y coord.

    But then it feeds the param into the takeObject() command.

    The result:

    Custom models spawned with the +2 height modification. Decks/cards did not.

    I tried getting ridiculous with the position mods, trying params.position[1] = params.position[1] + 50 and the like.

    The result was the cards/decks ALWAYS spawned directly in the exact coordinates of the placeholder that it got with the getPosition() command, while models used the ridiculous modifications to the coords.

    After tinkering, I fixed it. And the fix also confused me as to why it worked.

    I changed it to:

    params.position = placeholder.getPosition()
    params.position.y = params.position[2] + 2

    This change now makes cards/decks spawn with the proper height mod.

    ... What am I not understanding here?

  2. #2
    params.position = placeholder.getPosition()
    params.position.y = params.position.y + 2
    I think that should do it. When you use getPosition() you get in return {x=#, y=#, z=#}. In other words, it has letters for keys, not numbers. so params.position[2] in your example would return nil if you tried to print it there.

    Now when you user setPosition, it has the ability to take an numerically indexed or non-numerically indexed table. So {x=#, y=#, z=#} or {#, #, #}. Your table might have ended up as some combination of those and maybe sometimes it would be read or behave differently, depending on the code?

    Regardless of what it was doing, that is why you had the issue. So doing params.position.y instead of params.positions[2] should sort it out for ya.

  3. #3
    Join Date
    Jan 2014
    When we return a position or rotation we actually return a table keyed as both x, y, z and 1, 2, 3. When you give us a table back we check first for x, y, z if that doesn't exist then we check for 1, 2, 3.

  4. #4
    Ah, good to know

  5. #5
    If i'm not mistaken, that's a newer feature, to increase parity with use of x,y,z and 1,2,3. This is why I began to use 1,2,3 in lieu of x, y, z often, since it seemed to create less problems overall when I'm dealing with multiple dynamic situations.

    I guess the only question for me left is why setting params.position[2] = is different than setting params.position.y -- I understand they are different keys specifically, but [2] is able to point to the right entry (as in the 2nd value in the table, which is the y key), and it does the right math, and prints the right result. It just didn't do the right thing with setPosition(), meaning [2] almost became a different value that was overriden by the previous .y.

    And then the mixed equation params.position.y = params.position[2] + 2 works completely as intended -- no need to change the [2] to a .y.

    Taking this into account and weighing against Knil's response, it seems that in a x, y, z table... using [2] to set the 2nd entry (y) doesn't set it -- it instead almost seems to create a different entry from the .y. Then using the setPosition(), it first looks for a x, y, z value -- finding the y, it disregards this strange shadow 2nd entry, and goes with the .y at the original value, different from the [2] reference.

    Meanwhile if you call the [2] any other way, it functions the same as .y... I still feel like there's something I'm missing here.

  6. #6
    Non-numeric indexes, which is what x/y/z are, are non-sequential. They do not have a numeric index (2 for example) attached to them. So if you wrote this, it would print nil

    function onload()
        a={x=1, y=2, z=3}
    This is because entries that use a letter as an index ("x" for example) do not have any numeric value assigned to them, regarding their position in the table. But when you use getPosition(), here is that same example of what the table it returns looks like. (except I used 4/5/6 instead of 1/2/3 just so the print makes it clear what is being printed)

    function onload()
        a={x=1, y=2, z=3, 4, 5, 6}
        print(a[2]) --Prints 5
    And since, as Knil was nice enough to point out, it is reading the x/y/z keys if they exist, which they do, it is ignoring the change you made to numeric key 2. A solution is, when you manually create vectors like this, always make them {x=#, y=#, z=#} and avoid the numeric keys entirely. Then when you work with vectors in the future, always use x/y/z, never numeric keys. It is good practice, as I think it makes code easier to interpret as well as removing possible issues like this.

  7. #7
    The things you say make sense.

    I see now. To rehash: the fix they did to make 1,2,3 work as well as x, y, z was make getPosition() return 6 values.... the x, y, z keys and the same values but in the numbered index. This means that I was merely modifying a different value in the table, which is lower priority when using the setPosition().

    Now all that fiddly behavior with tables makes sense -- I always operated on the idea that whether things had a key or a default index in a table, they were still considered numbered in the order they were entered into the table. meaning a [2] would return the 2nd ordered value regardless of key -- but if I'm understanding this right, a [2] only works for values that do not have a key declared.

  8. #8
    I can agree that this all pretty much matches my current understanding.

    Especially about indexes. They come in numeric and non-numeric flavors. You can't get a numeric entry with a non-numeric call to the table and vice versa.

    Glad this all helped straighten it out

  9. #9
    Join Date
    Jan 2014
    You guy got it all right I also do it this way so you can declare a vector as just pos = { 2.5, 5, 3 }

  10. #10
    Which I often do, too, when I'm making my own tables. Because I'm too lazy to write XYZ apparently lol

Posting Permissions

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