Question ShiftCG or ShiftCentreofMass in Lua?

[Thunder Chicken]

Is there a ShiftCG or ShiftCentreofMass capability in Lua? I saw a link to Shift_CentreofMass in the Help files but it doesn't link to anything.

EDIT: Below is an image that shows where these are found in the Orbiter Help dialogue, under Orbiter Scripting / Class Methods / Vessel Methods. The hypertext links don't connect to anything and so I don't know if these are actually implemented, and there is nothing saying how to use them. I tried:

vi:shift_centreofmass({1,2,3})

and

vi:shift_cg({1,2,3})

but in either case the script crashes Orbiter, and I can't think of how else these would be implemented.

 

[johnnymanly]

try this:
vi:shiftCG({x=1,y=2,z=3})

You'll need this DLL: https://www.orbiter-forum.com/threads/orbiter-beta-lua-development.35459/

 

[Thunder Chicken]

try this:
vi:shiftCG({x=1,y=2,z=3})

You'll need this DLL: https://www.orbiter-forum.com/threads/orbiter-beta-lua-development.35459/

I see, I've been struggling with the limited 2016 version of that DLL that came with the Orbiter 2016 download. This is a great help! Thanks!

Now I have to figure out how to get an aircraft to roll about its longitudinal axis. The origin of the mesh isn't on that axis, so it rolls rather strangely with an offset. I am updating an old add-on from another developer and really don't want to edit the original mesh, and would like all the shifts to be done in my Lua code. It seems that I can move the CG, but the pitch and roll axes are still through the origin of the mesh.

 

[jedidia]

ShiftCG or ShiftCentreofMass

Make sure you understand the difference between ShiftCG and ShiftCentreOfMass. I don't remember from the top of my head what it was, but I remember it being significant. One only moves the mesh, while the other one also moves thrusters and camera positions and stuff. Though I wouldn't expect that to result in the roll axes still going through the origin of the mesh, that's kind of what the center of gravity is all about. But it might not hurt checking in on that.

 

[n72.75]

Make sure you understand the difference between ShiftCG and ShiftCentreOfMass. I don't remember from the top of my head what it was, but I remember it being significant. One only moves the mesh, while the other one also moves thrusters and camera positions and stuff. Though I wouldn't expect that to result in the roll axes still going through the origin of the mesh, that's kind of what the center of gravity is all about. But it might not hurt checking in on that.

ShiftCG is the one that moves thrusters, clickspots etc. The API reference has good details on this.

 

[Thunder Chicken]

ShiftCG is the one that moves thrusters, clickspots etc. The API reference has good details on this.

That was my understanding as well.

What I am trying to do is set the origin of the local coordinate system to the location of the CG on the mesh so it can roll about its axis. Right now the origin is too high and so it rolls very strangely. I want it to roll about the centerline of the fuselage in line with the nose.

 

[jedidia]

You might have to shift the mesh, then, if you don't want to edit it... I think there's a function for that, but I'm not sure if it's exposed to LUA. You'll also have to adjust thruster positions, animation reference points etc.

 

[N_Molson]

It should work :

https://www.orbiter-forum.com/threads/orbiter-beta-lua-development.35459/

[+] ShiftMesh shift_mesh
[+] ShiftMeshes shift_meshes

 

[Thunder Chicken]

So what I have done is to run shipedit to get the location of the center of mass in the vessel local coordinates and put that into Lua in the following table:

cm = {x=0, y=-0.65, z=-1.71} --center of mass determined from shipedit

In clbk_setclasscaps I have the following code to load the mesh and to shift it

vi:add_mesh('K33/K-Mirage2000')
vi:shift_mesh(0,{-cm.x, -cm.y, -cm.z})

The script runs and the mesh loads, but the location of the origin (indicated by the visual helpers) doesn't seem to be changing. There is only the one mesh so it should be index 0.

 

[Thunder Chicken]

For whatever reason this didn't work:

vi:shift_mesh(0,{-cm.x, -cm.y, -cm.z})

but this did?

vi:shift_mesh(0,vec.mul(-1,cm))

Had to update the touchdown points, but otherwise everything worked out. All the animations still work and rotate around the appropriate axes.

Onward!

 

[jedidia]

For whatever reason this didn't work:

vi:shift_mesh(0,{-cm.x, -cm.y, -cm.z})

but this did?

vi:shift_mesh(0,vec.mul(-1,cm))

Now you made me curious enough to have a look into the API docs. The C++ implementation that lua is binding to expects a reference to a vector3. I imagine that this jives badly with the inline declaration in LUA for whatever reason...

 

[Thunder Chicken]

Now you made me curious enough to have a look into the API docs. The C++ implementation that lua is binding to expects a reference to a vector3. I imagine that this jives badly with the inline declaration in LUA for whatever reason...

But it's OK with vec.mul(-1,cm)? That doesn't produce a reference.

 

[jedidia]

But it's OK with vec.mul(-1,cm)? That doesn't produce a reference.

It really depends on how the LUA interpreter does stuff, which I know nothing about. It does seem odd, but not unimaginable. Could also be that I'm completely wrong.

 

[N_Molson]

For whatever reason this didn't work:

vi:shift_mesh(0,{-cm.x, -cm.y, -cm.z})

but this did?

vi:shift_mesh(0,vec.mul(-1,cm))

View attachment 35638
Had to update the touchdown points, but otherwise everything worked out. All the animations still work and rotate around the appropriate axes.

Onward!

Be sure to note that information in the LUA thread, good find !

 

[Thunder Chicken]

Be sure to note that information in the LUA thread, good find !

Which one? There are a couple of things that I ran across that should be documented somewhere. Lua does seem rather usable, but the documentation needs to be brought up to the level of the Orbiter API reference somehow. That may be challenging with the various Orbiter forks that are popping up. I'm still on Orbiter 2016 which may not be what the cool kids are using these days, or in the future.

 

[N_Molson]

Which one? There are a couple of things that I ran across that should be documented somewhere. Lua does seem rather usable, but the documentation needs to be brought up to the level of the Orbiter API reference somehow. That may be challenging with the various Orbiter forks that are popping up. I'm still on Orbiter 2016 which may not be what the cool kids are using these days, or in the future.

I'm still on 2016 too. What are the 'cool kids' using today, and what are the improvements done ? I must say I'm a bit lost.

 

[Thunder Chicken]

I'm still on 2016 too. What are the 'cool kids' using today, and what are the improvements done ? I must say I'm a bit lost.

I believe the good Dr. Schweiger made Orbiter open source, and there are a couple of forks that I am aware of, but I haven't done much investigating. I don't know what the "official" version is anymore.

 

[N_Molson]

I believe the good Dr. Schweiger made Orbiter open source, and there are a couple of forks that I am aware of, but I haven't done much investigating. I don't know what the "official" version is anymore.

Same here. And probably the same for 99% of users...

 

[Gondos]

Not sure if you're still banging your head on this one but your issue is with the vector definition :

vi:shift_mesh(0,{-cm.x, -cm.y, -cm.z})

A vector is a table with x,y and z attributes, but here you define an array of 3 elements
You should do this instead :

vi:shift_mesh(0,{x=-cm.x, y=-cm.y, z=-cm.z})

 

[Thunder Chicken]

Not sure if you're still banging your head on this one but your issue is with the vector definition :

vi:shift_mesh(0,{-cm.x, -cm.y, -cm.z})

A vector is a table with x,y and z attributes, but here you define an array of 3 elements
You should do this instead :

vi:shift_mesh(0,{x=-cm.x, y=-cm.y, z=-cm.z})

Thanks for checking back, but I did finally figure out the Orbiter vector definition as a keyed Lua table.