Script help with takeobject, rotations and snap point

[Randoom]

Hello !

I'm looking for some more advance help on scripting ... I'm a programmer myself during my day job, and to relax at night ... I script and code stuff for others :P

I'm currently scripting an Aeon's end table to automate nemesis turn, player's draft and discard phase, flip over decks on end of turn, etc.

Long story short, it *almost* works, but I have 2 issues ... I could work around the issues with more hard coding, but being a programmer, I like neat and precises stuff :P


#1 - Defaut rotation from TakeObject isn't what I want and differs from taking an item manually.

when taking out an item from the loot back manually, the item keep the same rotation as when you put it in. which is neat, because it allows to customize the 4 'gate' directions for each different mages. But, when I do a 'takeObject' from the loot bag, it will default to the loot bag rotation, which is not good.

Now, I *COULD* hard code each 4 gate for each of the 30'ish mages into their playmat, and dynamically go look at the orientation needed ... but ... meh ... thats a lot of work. is there a simple way to just tell TTS to not mess with the rotation of an item when you take it out of a loot bag ... since before being taken out, it doesnt exists yet, I cant find the previous rotation with .getRotation in a call back method, yet if I take it out of the back manually and it have the right rotation, I'm guessing the information must be written up somewhere ?



#2- Objects taken out by with TakeObject dont snap to snap points.

this one I'm actually curious as to why, since the object exists in the world at this point, and it start to fall ( get attracted by gravity ). yet if I want an object to 'snap', I have to manually lift and drop it again. It's not crucial, and I can live with 'almost perfectly placed card' ... but I'd like it to be "neater".

----

Thanks in advance if you can advice me on how to correct these 2 little problems !

[Tragic]

1# Objects should retain their rotation they had when put in the bag... so if you drop a token in it in face up, it will be face up when you pull it out. If the object is changing rotation, I would assume it could be in your code. When I take from a bag witch scripting I personally like to use setPostion and setRotation or the smooth vertsion instead of the "parameters" for takeObject.

something like this...

local object = bag.takeObject({})
pos = bag.getPosition()
pos.y = pos.y + bag.getBounds().size.y + 0.5
obj.setPosition(pos)
obj.setPositionSmooth(????)

This code (not tested just off the top of my head) should take a object, move it instantly above the bag, and then smoothly move it to whereever you tell it. As we never used any parameters at all, there is no place in this code to change the rotation. Basically I only use takerObject(prams) to define GUID or a Index or a callback function.

2# Not sure why this is happening either. I did have a issue like this once... but only with dice. The tags should be saved and be the same when you come out of the bag. The quickest work around would be to add a onLeaveContainer or w/e it is called and just set the obj.use_snap = true to force it to always be on.

Also, snaps do not work on setPosition and stuff. If you code a setPosition it will go to that exact place, regardless of it a snap is close to it. It "sounds" like maybe the snap is working. When you pick up the card and drop it again, it is moving to the snap.. if your setPosition went to the correct spot, it would place it at that same place.. so the user would nevr know the snap is not being used, and if they manually move it, then snaps are working then. You can check this by printing out if the use_snap == true on the frame function *the one that triggers every frame).. to tracj exact when, if it is at all, the snap is turning off. Or just right click and see if the snap option is ticked.

[Randoom]

Hey ! thanks for answering, more particulary on the 2nd question.

but sadly I'll have to disagree strongly with your 1st answer ... and unless poeple see this answer and try it to use it I prefer to voice my disagreement right away. I'm not new to programming or scripting, I have 10+ years of experience coding, and what you say makes no sense on this subject. the documentations directly says the contrary to what you do ...


Taken from the documentation :
parameters.smooth: If the taken Object moves smoothly or instantly.
Optional, defaults to true.

parameters.rotation: A Vector of the rotation of the Object.
Optional, defaults to the container's rotation.



Is there any reason you prefer not to use the default way to do it, but overlap 3 movement position to move an object (which can be repeated up to 15x for up to 4 player in the exact same moment, giving up to 120 unnessary move command to the game ? Unless you are telling me that using TakeOjbects with no param somehow changes the behavior or the other params of an object, your code makes no sense in pretty much every possible situation.

# Objects should retain their rotation they had when put in the bag... so if you drop a token in it in face up, it will be face up when you pull it out. If the object is changing rotation, I would assume it could be in your code. This code (not tested just off the top of my head) should take a object, move it instantly above the bag, and then smoothly move it to whereever you tell it. As we never used any parameters at all, there is no place in this code to change the rotation. Basically I only use takerObject(prams) to define GUID or a Index or a callback function.

That is my problem. I can't define my rotations, because the object doesnt exist yet, and because I don't know the rotation of the item being taken out, yet I don't want it to rotate around and get the bag's rotation. Right now, as soon as I take cards out of the bag, I have to manually set the rotation of my item in a callback function so that it set in front of the player's instead of being ackwardly backward because of the bag's rotation.

Also, snaps do not work on setPosition and stuff. If you code a setPosition it will go to that exact place, regardless of it a snap is close to it. It "sounds" like maybe the snap is working. When you pick up the card and drop it again, it is moving to the snap.. if your setPosition went to the correct spot, it would place it at that same place.. so the user would nevr know the snap is not being used, and if they manually move it, then snaps are working then.

[/QUOTE]

Ok, that I like, seems plausible enough. I know the snap are activated when I pick the object up, I'll try to check it while it moves in position and while it's created, but I think you are right on. I'll try to manually give the snap point locations instead of an arbitrary position near where the spot I want them.

[Tragic]

#1 - Well that is how I do it, you can take it or leave it! : ) When you get into more advanced takeobject functions you may find that having it automatically start moving the instant spawns not be useful, and it is super handy to have the object reference ready to go as well. The method I use allows me to have complete control of the object, and I like this. Also, when you use takeObject(prams) it spawns at the x,y,z of the bag, so at the bag base. I like the visual look of it being above the bag when it starts moving.... like I said this is how I do it, there is no "correct" way. Whatever works for you.

Also, the obj rotation shouldn't change in anyway when you remove it form a bag, unless you are telling it to, This is why I said to try that code as it will remove any shenanigans that maybe be rotating it without you knowing.. I say shouldn't.. as TTS is a complex app and dose have some strange stuff happen now and then. So in theory you shouldn't ever need to know the object rotation as it enters the bag, as this should be saved.

When you takeObject() it spawns and on that frame it spawns all the getRotation() and other things work fine. So you can get the rotaion of the object after it comes out of the bag. Just use obj = bag.takeObject(???)... as takeObject returns the object taken.. so you can do all sorts of things to the taken object after it spawns.

If you are really having issues you can just store the rotation data as it enters the bag, this will work, but it is not needed because as far as I know all this rotation info is saved anyway... but if you are having a problem of the rotations not being the same as they were when dropped in try this.... build a objectenterscontainer event (or w/e it is called) that simple gets the entering objects.getRotation() and saves that into a table saveRotations[obj_entering.getGUID()][obj_entering.getRotation()].. now when you take it out of the bag, you can either put the rotation into your takeObject prams, or use setRotation(). I would start the variable saving the rotations on the bag itself, and just get the table form it. obj.getTable... . .

example

local obj = bag.takeObject(prams)
obj.setRotation(saveRotations[obj.getGUID()])

[Randoom]

2# Not sure why this is happening either. I did have a issue like this once... but only with dice. The tags should be saved and be the same when you come out of the bag. The quickest work around would be to add a onLeaveContainer or w/e it is called

Well, this part did gave me the idea to find the work around, so thanks alot for it.

... it's a bit fishy, but it woks.

after a couple of test, I've seen that the rotation of an object in TakeObject == rotation of it's bag, but, the rotation of an obect in OnLeaveContainer will be the rotation it have exactly at that frame, which means it's currently pivoting to get toward the containers rotation ( so instead of 180, it'll be 179.0034 ... )

so I've set a flag who registered if Im currently in "deploying mode", and if I am, I save in a table every guid / rotation combination that trigger OnLeaveContainer, and in the callback function of my TakeObject, I grab that rotation and I round it to the closest integer to have the correct rotation , and I erase it from the table afterward.

(be carefull with OnLeaveContainer, as it's global and called on every single container )

[Randoom]

#1 - Well that is how I do it, you can take it or leave it! : ) When you get into more advanced takeobject functions you may find that having it automatically start moving the instant spawns not be useful, and it is super handy to have the object reference ready to go as well. The method I use allows me to have complete control of the object, and I like this. Also, when you use takeObject(prams) it spawns at the x,y,z of the bag, so at the bag base. I like the visual look of it being above the bag when it starts moving.... like I said this is how I do it, there is no "correct" way. Whatever works for you.

I know you CAN do it however you want, but everything you said is just false. it's not that I don't 'like it' it's just lies.
you have 2 different ways to have references of your object as soon as it spawns. TakeObject is a function, it returns the object you are currently taking out. callback fucntion aslo only starts once the object is loaded, which allow you to set other parameters which didn't exists previously, which is a lot safer.

also, if you call TakeObject() with no params ... It DO set the rotations to your bag's rotation. if you give it a position in the params, it DO move smoothly, from 2 y+2 over your back, to the position you want. if you set smooth = false, it will teleport the object on your position. that are DEFAULT value. you cannot ask the object to ignore the default value, unless you overwrites them . it's nothing special or weird, it's basic programming.

When you takeObject() it spawns and on that frame it spawns all the getRotation() and other things work fine. So you can get the rotaion of the object after it comes out of the bag.

that is totally wrong. take a tile, flip it and rotate it. put it in a bag. rotate the bag around. I just did, and it's how I got it to work . if you call getRotation your OnObjectLeaveContainer, and if you call it in your TakeObject() callback, or after the TakeObject() is called, you'll see it's different results.

[Randoom]

Sans titre.jpg

Here : I locked and made the tile immovable to tile to prevent them from moving after taking them out of the bag.

I called getRotation in the onObjectLeaveContainer, its the red frame, which is called 1st.

in yellow, its the call to getRotation done after TakeObject, which is called after.

you'll see the 4 tiles in TakeObjects have all the exact same rotations, despite being made immovable ( and not just locked) while they all had different ones when they were put in the bag, which we clearly see in the red frame.

[Tragic]

Based on your reply I seem to have failed to express my meaning. I'm not really a great teacher, sorry, as you have completely misunderstood me. The thing is though is that you are so incredibly rude and aggressive, I have no interest in conversing with you anymore. See ya, I hope it all works out for you.

[Randoom]

Based on your reply I seem to have failed to express my meaning. I'm not really a great teacher, sorry, as you have completely misunderstood me. The thing is though is that you are so incredibly rude and aggressive, I have no interest in conversing with you anymore. See ya, I hope it all works out for you.

sorry if it does sound rude, english isn't my main language, and I'm not in a programming carreer because of my high psychological skills, and I won't rock and sing you lullaby to explain that you are saying lies. I might come out a bit direct, but please don't tell people you will help if you come and says stuff that directly contradict the documentation and are just false.

default parameters ARE SET and WILL BE USED, even if you don't set them yourself. that's why they are default parameters. because YOU don't write them doesnt mean they dont exists. there is nothing weird or special, or hard to understand about it.

if it's hard to understand of behave erractly, it's because you don't understand how it work, nothing more.

I do thank you for trying to answer and trying to help, but geez, don't go around giving false answers to people who comes out with a detailed problem, when your answer contradict what the documentation says, are wrong, and are proven wrong once tested.



Me : " I did 'A' . it didn't do 'B'. I read the documentation :it says 'A' will never do 'B'. can someone help me ? "
You : " Do 'A'. It does do B. it works. "

me : " well, I'm here because I did "A" and it doesn't work. "
you :" it works, i always do "A" and it does 'B'. Here is a wrong example of a bad "A" that will do 'B' "

me : "look, I just tested you're exemple, it doesnt do 'B'. Heres a screenshot that shows you that your 'A' doesn't do 'B'."
you : you didnt understand. you are rude, get lost.