Pivot points for rotations...

#1 I noticed in the documentation for Mount:

NOTE:- Using an offset of (0,0); both objects will be aligned using their pivot-points. For
instance, if one object has the pivot-point at top/left and the other center/center then the fully
mounted objects will overlap with the top/left and center/center of the objects at the same
position....

So clearly you guys have been thinking about relocating the pivot point, right?

#2 @Jason: Yes. At this point, you can mount any object onto any point on another object but you cannot specify which part of the source object will form the pivot.

Technically, this isn't anything to do with mounting at all, it's related simply to allowing an arbitrary pivot-point. It's really easy to change T2D to then allow an arbitrary pivot-point but the problem here is that the rotation code and all the physics is based upon rotation around the center of the object and for good reason as it makes the inertial responses/torque much easier to calculate.

We'll be looking carefully at problems caused by not being able to configure arbitrary pivot-points but at this point, you'll just have to trust us that allowing such configuration does impact alot of internal systems in T2D and isn't as trivial as it at first sounds.

It's something that's come up before during the beta trials and I'm sure it'll come up again.

Sorry if this causes you any problems though.

The way to get around this is to make sure that graphical-pivot-point is in the center of your image-frame so in your case, your gun-pivot needs to be in the center of the image. At worst, this can cause your image to be slightly larger which isn't really an issue unless you've got huge volumes of different existing images to convert.

- Melv.

#3 I think you need to chnage the pivot location with setPivotAlignment('Left', 'center'); on the barrel No?

could it be faked with

addLinkPoint() ?

#4 @Melv: OK. That's how I worked around it yesterday. It just makes my sprite image a little bigger (ans wastes a little memory, but so be it). I can't really think of a case right now where I will ever need the pivot point to change dynamically, but that's what will hose people without an API, since you'd have to make a lot of variations of the sprite image for the sole purpose of changing the pivot point. I'm not sure that's a scenario of anyone, though.

@Anthony: I can't find this API in the reference docs. Do you know something I don't know? :-)

Thanks both of you for the help!

#5 Mine is referance from beta docs, only thing I have at work, sorry if I am out of date on my side =p

#6 @Jason/Anthony: Yes, "setPivotAlignment" was in the old beta stuff but was removed for several reason, most notably because it caused both confusion to people using it and it cause the internals to become uncessarily complex. It died a horrible death and I personally won't miss it. ;)

Yes, unfortunately, you are "limited" to rotation around the center of the object, mounted or not. You can be sure that serious consideration of allowing an arbitrary pivot-point will be given in the future.

- Melv.

#7 Couldn't this be worked around with a little math ?
rotate it and moving its location at the same time , or moving the link position ? with some formulas...

or am I just too tired and confused lol ?

#8 @Matthew: Sure, you can position stuff manually but the mounting has to be done by T2D. As I say, it's really related to the aspect of the angular momentum physics code that assumes the centroid to be in the center of the frame. Way too complex to go into without me having some food first. :)

- Melv.

#9 Hmm... ok now I'm understanding you... what if we were to create dynamic link positions based on the new needed rotation ? or would that be too much of a workaround for something that might not be needed lol ?

#10 There's nothing you can do about it at all unless you want to manage your own mounts really. The problem simply centers around the fact that the rotation is always the center of the object. Again, we'll definately be looking at this issue more closely.

- Melv.

#11 This was one we wrestled with a lot when we were designing the physics system. We decided that this would be the best approach for now, and that we'd come back to revisit it in the future. :)

#12 I was trying to figure out how to adjust the pivot point of some of my sprites and I ran across this thread from near 2 years ago. Was this ability ever implemented and if so how do I go about it?

Otherwise I'll just use the attach to dummy object trick.

#13 Taggage

#14 Objects still rotate about their centers.

#15 Found this thread via the search so I echo the above question.

1.5 years after the last employee post and night on 4 years after the original post: is this ever going to happen?

I am assuming after this long GG's official position is "This is too much hassle to change, forget about it" but it would be nice to know for sure.

#16 Have a look at this thread:

www.garagegames.com/mg/forums/result.thread.php?qt=71517

The problem with this idea is that it will probably have unexpected results with physics and collisions.

#17 Yea, I know about the various workarounds. Rezising the image is the one I will go for but it would still be nice to get an " official party line" on this so that we aren't waiting for that possible glorious day.

#18 Hey, wanted to at least give you an honest response. This probably isn't going to happen anytime soon. I won't guarantee it won't, but I can say that compared to other things to work on in TGB this is not at the top of the priority list.

I also wanted to say that it's not that things like this isn't important to us. In fact we think of things we want in our engines all of the time, but when it comes down to putting it into the product we need to predict the time it would take, the QA time it would take to test it, potential time it would take to fix anything QA runs into. This includes a risk analysis of what we are changing, something like this is very risk since it would effect multiple other important systems. We then have to evaluate how important this is to all of our users and compare it's cost in time to fix and value to everything else we could possibly do. It's painful to look at something like that and honestly say there are higher priority things, but it doesn't we aren't listening and don't care, very much the opposite :)

#19 Many thanks for the honest reply.

I am assuming the vast majority of people here are programmers and can appreciate the problems associated with this change so I am not going to throw any toys out the pram.

Thanks for the update.