Project AIA Toehold Lunar Base

[Countdown84]

Not all that off topic, could the rover be modified with a small URMS arm and function as a "spotting dolly" for a DG sive vessel?

What exactly do you mean by "spotting dolly?"

As to the rover, here is a pre-alpha screen of a small UMMU rover I'm working on. I am using this project as a real first step in 3D modeling though, so the mesh is taking a long time to refine. I'm also a novice at programming, so I can't say that this is likely to be finished soon....

As to the jetbridge - what are we going to do about XR5? When landed, crew would need to exit this vessel via the crew elevator that drops them directly on the surface - not through a docking port.

I favor a spacesuit EVA to get from vessel to base (or rover or train). It seems to me that jetbridges would be too expensive and complex to justify construction on the moon.

 

[PhantomCruiser]

A spotting dolly (or spottin' dolly), was just a piece of support equipment that we used to grab the nosewheel hub and "spot" the aircraft where we wanted her to be.
I'll dig around and see if I can find a picture...
You know, your little rover there would probably a good size for moving around small craft on the moon. I was surprised at how small a tow tractor could moce a C-130 around... What we used for helo's was about golf cart sized (albeit deisel powered), both had lots of torque though.
Something that I might let slip also is a "tilly bar", this was basically a long pole that has some tongs at the end that would grab an aircraft at the same place (nosewheel hub), we'd use a tilly bar to manually move the aircraft around. Not always easy, some them suckers are heavy. An A-4 Skyhawk is surprisingly light though...

 

[pattersoncr]

The XR5 might need a specialized boarding ramp. I hesitate to suggest that but it's probably warrented in the case of a craft a popular as the XR5.
I see two options; A very tall boarding ramp that swings over the top docking port or one that slides up next to the EVA elevator when the elevator is extended. The boarding ramp would have to be disconnected when you move the elevator.
I think Tommy has a great idea for handling half of the problem (transfer from the ship to the base). Now the other half needs to be figured out.

 

[the.punk]

From the Aliens film, the.punk.

One of these:

Thinking about it tgep, this may be a little low-slung for regolith travel, but would be great on prepered track way.

Ok. Thanks.

 

[wehaveaproblem]

I can send you my current mesh files if you'd like

I would like, but no point yet, I'm not even close to having a use for it. Better for you to get that 50% ot 100%.

...I have a couple vague ideas that may be useful if you go with a custom module for the base....

To you and all the other suggestions regarding the 'docking' to avoid EVA. I'll run this idea past a clever coder and see what he thinks is doable. It would be cool to have some means of direct vessel->base UMMU.

Cheers again for all the general chatter and thoughts, much obliged. You have all given me much to think about. It will be a while before I get to starting this project proper as I want to finish the WIN update first. But all the feedback is great.

WHAP

 

[Face]

To you and all the other suggestions regarding the 'docking' to avoid EVA. I'll run this idea past a clever coder and see what he thinks is doable. It would be cool to have some means of direct vessel->base UMMU.

A direct vessel->base UMMU is no big deal. Dan's SDK is pretty clever already, so there is no need for a clever coder .

cheers,
Face

 

[wehaveaproblem]

Oh cool face, so it is easily implementable?

Would the code be included in the base's dll or would it require a module? If so would it be vessel/base specific or could this be used as a universal vessel->ground base docker?

 

[Face]

Oh cool face, so it is easily implementable?

Would the code be included in the base's dll or would it require a module? If so would it be vessel/base specific or could this be used as a universal vessel->ground base docker?

It is almost ready. I started the UMMUFB (UMmu For Bases) project yesterday.
It will be a module you'll have to activate in the launchpad. A base dll is NOT needed.
Basically, a dialog or MFD (it doesn't matter to me, please choose one) will display all bases in the scenario and their appropriate passenger list. You can choose to "checkin" a passenger to a landed vessel there. If you land a vessel on a pad, it will think it is docked to the base. Every UMMU eva will therefore result in a transfer to the base, where the UMMU will show up in the list.

The underlying idea is to fake Orbiter's GetDockStatus call that is used by Dan's UMMU implementation. It will most certainly work with 2K6P1 only ATM.

BTW: The same concept can be used to create virtual dockings, too. E.g. for docking tunnels...

If anyone is interested (Computerex?), the code is in the attached ZIP.

cheers,
Face

 

[wehaveaproblem]

You see, that's why I like this community. You say" wouldn't it be good if we could..." and the next day it's almost made!

That sounds like and awesome, and fiendishly clever, workaround, Face. Great stuff!
So, your module will use default Orbiter pads as the trigger mechanism to allow for ummu to the base? Also, you mentioned docking tunnels and the like. Would that work via area effect or mesh contact or?

TBH, your module sounds like it will do what is needed in a very clean way without any faffing with working docking tunnels etc. Out of curiosity, could you still EVA from a vehicle's dock when on pad? or does the module restrict UMMU from vessel to base only and vice versa when on the pad?

 

[Face]

So, your module will use default Orbiter pads as the trigger mechanism to allow for ummu to the base?

Yes, ATM it detects the landed status and determines the base and pad the vessel is landed in. OFC it can be extended to e.g. read areas of contact from configuration files.

Also, you mentioned docking tunnels and the like. Would that work via area effect or mesh contact or?

Since all it does is faking a docking object, you can use the mechanism to e.g. link two vessels' ports as transfer-tunnels without having them really docked. This might interfere with other addons using the GetDockStatus method, though.

Out of curiosity, could you still EVA from a vehicle's dock when on pad? or does the module restrict UMMU from vessel to base only and vice versa when on the pad?

It depends on the vessel's UMMU implementation. Developers can force EVA by selecting -1 as docking port. Of course we can add a flag, so the user can select if a landed vessel should transfer UMMUs directely or default to the standard EVA...

So what would you prefer? Dialog or MFD "universal checkin terminal"?

regards,
Face

 

[Donamy]

Will this detect SC3 vessels ?

 

[Countdown84]

Wow, this sounds GREAT, Face! Ever since PreludeII came out I've lamented that more bases haven't become UMMU - friendly, but I never dreamed there would be a way to make that happen without individual base .dlls

WHAP, I think you've found your "clever coder."

So what would you prefer? Dialog or MFD "universal checkin terminal"?

regards,
Face

I'll put in a vote for a Dialog Box. MFD interface would be a little "clunky" in my opinion. Perhaps the dialog could include the ability to generate new crew members and to specify the Mesh to be used for EVA?

Also, could you have a direct EVA option from the base? Presumably each landing pad will become like a virtual "docking port," so there will need to be a way to select the landing pad for transfer. Maybe you can just add a choice to EVA the crew member from the center of the base or something?

 

[Face]

Will this detect SC3 vessels ?

I'm not so familiar with SC3. Are they UMMU compatible? If so, it sure will work with them, too.

It is nothing complicated, just hooking of Orbiter's vessel function for returning docking state. Whatever tries to get the docking state (like Dan's UMMU) will get an object-handle in return, if the vessel is landed near a base's pad.
This object is a dummy UMMU vessel, so UMMU can detect the dummy attachment-point it installs on all vessels and attach an UMMU there. The UMMU-process method in the dummy vessel then detects the attached UMMU and ingresses it immediately. Since the UMMUFB module is in charge of the dummy vessel class, it detects this transfer, removes the UMMU from its internal crew and adds it to the base's rooster, displayed by the MFD/dialog.

regards,
Face

 

[wehaveaproblem]

Sounds great Face. Personally I think an MFD would work nicely, plus open it up easily for others to use. People are familiar with MFDs and I think it would make a very nice addition to the family. But the functionality is what I want, so go with the majority.

 

[Face]

Sounds great Face. Personally I think an MFD would work nicely, plus open it up easily for others to use. People are familiar with MFDs and I think it would make a very nice addition to the family. But the functionality is what I want, so go with the majority.

Hm... maybe both have their place. I can imagine the following:

• PAXMFD displaying "Welcome to pad X of Example Spaceport! Press PAX for passenger operations" whenever the vessel is landed on a pad. Pressing PAX will dock the vessel to the pad for UMMU transfer. In this situation, invoking EVA will really EVA the UMMU.
• PAXMFD display "Ready for PAX. Press PAX again if boarding completed." whenever the vessel is "docked" to the pad. In this situation, EVA with designated port will transfer the UMMU to base rooster.
• PAXMFD display "No service" if the vessel is not landed on a pad.

• Dialog "Spaceport Check-In" showing a base selector combo box on top, a passenger list on the left, a vessel list on the right (with pad number as prefix followed by vessel name) and a log text box on the bottom.
• Below the log are 4 buttons: Check-in, Check-out, Board and Close. The later is obvious, Check-in opens a new dialog for creating a new UMMU, Check-out deletes the UMMU and Board transfers the UMMU to the selected vessel.
• In the vessel list, empty or undocked pads are displayed, too. If a UMMU "boards" empty pads, it simply EVAs starting in the middle of the pad.
• The log will detect and display base UMMU-events. Entering a base from a vessel and pad, checking-out, checking-in, boarding a vessel on a pad etc...

Does this sound like a plan?

regards,
Face

 

[wehaveaproblem]

Sounds like a frickin' awesome plan mate. Both sound a fantastic addition to the orbiter family. I'm surprised this hasn't been done before, I can't be the first to ask surely.

So yeah, I can see the merits of both, although the dialog does sound sexy now I read it. Do whichever you want to. And thank you!

 

[Tommy]

Is there a way for an EVA'd UMMU to enter the base?

 

[Donamy]

I'm not so familiar with SC3. Are they UMMU compatible? If so, it sure will work with them, too.

It is nothing complicated, just hooking of Orbiter's vessel function for returning docking state. Whatever tries to get the docking state (like Dan's UMMU) will get an object-handle in return, if the vessel is landed near a base's pad.
This object is a dummy UMMU vessel, so UMMU can detect the dummy attachment-point it installs on all vessels and attach an UMMU there. The UMMU-process method in the dummy vessel then detects the attached UMMU and ingresses it immediately. Since the UMMUFB module is in charge of the dummy vessel class, it detects this transfer, removes the UMMU from its internal crew and adds it to the base's rooster, displayed by the MFD/dialog.

regards,
Face

SC3 vessels have a .ini file, instead of a .cfg

 

[Face]

SC3 vessels have a .ini file, instead of a .cfg

Well, that is something I know, I'm just not sure if SC3 is supporting UMMU. In order to do that, the SC3 vessel-class would have to have a crew instance and call the UMMU-processing function.

I guess this is not so... but UMMUFA should be compatible with UMMUFB, so SC3 vessels can be used, too.

regards,
Face

---------- Post added at 09:48 ---------- Previous post was at 09:46 ----------

Is there a way for an EVA'd UMMU to enter the base?

Thought about that, too. I have to test some strategies for that. Best would be to have it ingress if landed on pad, too.

regards,
Face

 

[Tommy]

Best would be to have it ingress if landed on pad, too.

I was thinking that myself, and it looks like it will be possible to add "invisible" L-Pads anywhere you'ld want a UMMU to be able to enter the base, or on runway ends, etc.