Base Moon Village, partially buried base + Pads

[Urwumpe]

Maybe another alternative interpretation: The tug transports the lander into lunar orbit and in another mission brings the hab to the lander in lunar orbit. This would be the more conservative approach to LOR.

 

[gattispilot]

I get this. I need redo the mesh at the top just a bit
I need to figure what values x,z the 2 sides move.
They are 120 degrees off center.
static UINT SGrp1[10] = { 3,4,10,14,15,22,23,28,34,40 }; static MGROUP_TRANSLATE side1(0, SGrp1, 10, _V(0, 0, .5)); static UINT SGrp2[10] = { 5,6,11,17,18,24,25,30,33,39 }; static MGROUP_TRANSLATE side2(0, SGrp2, 10, _V(-.25, 0, .25)); static UINT SGrp3[10] = { 7,8,12,20,19,26,27,31,32,38 }; static MGROUP_TRANSLATE side3(0, SGrp3, 10, _V(.25, 0, -.25));

These are are UCAS yet

 

[Urwumpe]

simply use

static const VECTOR3 direction = _V(sin(120 * RAD), 0, cos(120 * RAD))

 

[gattispilot]

It's impossible to add astronauts to a vessel that doesn't support it. Currently, there are 2 ways to add an astronaut: inside a vessel by the vessel, or directly in the scenario by scenario editor.

Both vessels must be docked to transfer astronauts between them. Otherwise, you have to egress the astronaut, get it in, and ingress into another vessel.

For bases, it's not possible to get the astronaut inside them like vessels. Astronauts stay inside as normal Orbiter vessels, and if breathable, can remove their suit inside. So there is a physical astronaut inside the base, not just information like vessels.

static const VECTOR3 direction = _V(sin(120 * RAD), 0, cos(120 * RAD))

Thanks. But for translate don't we need a distance also?

 

[Urwumpe]

Thanks. But for translate don't we need a distance also?

Oh yes. Then make it a:

static const VECTOR3 displacement = _V(sin(120 * RAD), 0, cos(120 * RAD)) * LENGTH;

 

[gattispilot]

Thanks. Trying to get side 3 to move correctly. side 1 and 2 work good

I am going to have to scale these sides in. They need to move 1.05 to fit inside the Fairings. The image show they moved in. See how they are in the center part near the dock


anim_sides = CreateAnimation(1.0); static const VECTOR3 displacement = _V(sin(120 * RAD), 0, cos(120 * RAD)) * .5; // static const VECTOR3 displacement1 = _V(sin(120 * RAD), 0, cos(120 * RAD)) * -.5; static UINT SGrp1[10] = { 3,4,10,15,16,22,23,29,34,40 }; static MGROUP_TRANSLATE side1(0, SGrp1, 10, _V(0, 0, .5)); static UINT SGrp2[10] = { 5,6,11,17,18,24,25,30,33,39 }; static MGROUP_TRANSLATE side2(0, SGrp2, 10, displacement); static UINT SGrp3[10] = { 7,8,12,20,19,26,27,31,32,38 }; // static MGROUP_TRANSLATE side3(0, SGrp3, 10, displacement1); AddAnimationComponent(anim_sides, 0, 1, &side1); AddAnimationComponent(anim_sides, 0, 1, &side2); // AddAnimationComponent(anim_sides, 0, 1, &side3);

 

[Urwumpe]

Remember the circle, for the 240° case, you of course have to use 240 as angle. Or invert the x axis. displacement is also just my suggestion how to name the variable, but you can pick what ever you like. displ120 or displ240 is also an option. If you are using a serious code style, any global constant names should be all upper case letter.

 

[gattispilot]

Thanks. I will recode her for scaling. Basically I have touchdown points, docking info and animation of the sides.
Since there is really no airlock, yet. This shouldn't be UACS.

 

[Urwumpe]

Thanks. I will recode her for scaling. Basically I have touchdown points, docking info and animation of the sides.
Since there is really no airlock, yet. This shouldn't be UACS.

I don't know, I would see some UACS use cases. First of all, cargo could be transfered into the base for unpacking, have it as consumer. Also but there I don't know UACS well enough yet, a habitat could of course host astronauts.

 

[gattispilot]

I don't know, I would see some UACS use cases. First of all, cargo could be transfered into the base for unpacking, have it as consumer. Also but there I don't know UACS well enough yet, a habitat could of course host astronauts.

Yes. I can make it UACS. BUt the challenege is the the airlock exit point. Sure I can make it be the 3 docks near the ground. But if an airlock module is attached then the guy might appear in the tube connecting. UACS requires a vessel to be docked to transfer. I think for Orbiter just have an airlock vessel that holds the people. I guess if the airlock vessel is docked then you could transfer people.

 

[Urwumpe]

And what if it without airlock and the airlock is a vessel of its own?

 

[gattispilot]

And what if it without airlock and the airlock is a vessel of its own?

Yes. You would have a HAbitat vessel UACS for transfer and a airlock vessel with 3 tunnesls to conne ct 3 Habitats docked. THen the guy enters the airlock and transfer to a Habitat. The only issue might be the height of the vessels. If the airlock is on the ground and then docked to 2 habitats. one might be above the surface. due to the dock being straight line and the surface not.

 

[Urwumpe]

Yes. You would have a HAbitat vessel UACS for transfer and a airlock vessel with 3 tunnesls to conne ct 3 Habitats docked. THen the guy enters the airlock and transfer to a Habitat. The only issue might be the height of the vessels. If the airlock is on the ground and then docked to 2 habitats. one might be above the surface. due to the dock being straight line and the surface not.

Sounds like designed. So you fear that ground is not level and requires some way to compensate?

 

[gattispilot]

Sounds like designed. So you fear that ground is not level and requires some way to compensate?

Yes. We might could try flatten the area. I might take a quest airlock and add 3 tunnels to her and some support. I might redo the hatch from round to rectangle also.

 

[gattispilot]

I need to figure the 120 and 240 angles scaling.
Side 1 works, But side 2 and 3 are not even
static UINT SGrp1[10] = { 3,4,10,15,16,22,23,29,34,40 }; static MGROUP_SCALE side1(0, SGrp1, 10, _V(0, 0, 2.096), _V(1, 1, 2)); static UINT SGrp2[10] = { 5,6,11,17,18,24,25,30,33,39 };//120degrees static MGROUP_SCALE side2(0, SGrp2, 10, _V(1.750371, 7.82493, - .9486793), _V(1.5, 1, 2)); static UINT SGrp3[10] = { 7,8,12,20,19,26,27,31,32,38 };//240 static MGROUP_SCALE side3(0, SGrp3, 10, _V(-1.750371, 7.82493, -.9486793), _V(2, 1, 1.5));

 

[gattispilot]

Ugh. I can't get the 2 120 degrees side to scale good. I might cheat and make them the same as the straight z. And then rotate 120

 

[Urwumpe]

Ugh. I can't get the 2 120 degrees side to scale good. I might cheat and make them the same as the straight z. And then rotate 120

Scaling and then rotating the groups can have weird effects, normally scaling has to a be a leaf in the animation tree.

 

[gattispilot]

Yes. I think I will just make a side extended and a side retracted. Press a key and they are either extended or retracted

 

[Urwumpe]

Yes, I think that is the easiest and least error prone way to implement this.

I could imagine another way, but since Orbiter is open-source now, maybe there is even an better way to implement this by adding a new set of animation functions to the API. But this then requires more thinking and planning than I can do right now. If we could do native skeleton animations in Orbiter, we could actually cover a whole lot of new use cases, from better human figures to parachutes, tethers, inflatable structures and sails.

 

[gattispilot]

MAybe this for an airlock module. It would have scaleable tunnels but the dock would remain out. It is just to get on the SLS or Falcon. # docks and one front hatch?