New Release Interplanetary Modular Spacecraft RC9

[Dantassii]

Okay, Stack Editor has made IMS WAY more practical. I have a design that I could contribute.

Should I start a new IMS design discussion and finished spacecraft repository thread, or keep it all here?

I uploaded my Lunar Station somewhere on this site a few months back. A few people looked at the thread, only 1 downloaded the scenario file. Never did hear back from them although I suspect that their computer may have fallen into the black hole that appeared where there CPU used to be when they fired it up.

I think there are something like 2,750 individual IMS modules in the station.. and it's only 70% complete with the initial operational capability and about 35% of final design complete.

Dantassii
HUMONGOUS IMS shipbuilder, just ask Jedidia

 

[jedidia]

I tried it again without the extra IMS_RES line just to be sure, no luck.

There's a few misconceptions here, as far as I can see. First, note that for resource transfer to work, BOTH vessels must have storage capacity for that resource. In your test scenario, the command module has no propellant storage whatsoever, so it can't transfer any propellant, no matter with what vessel.

Second, I see that you have designated the resource on the gilgamesh as hydrogen-fluoride... while supported by the core, I don't think there's actually any thrusters or for that matter propellant tanks that support that particular propellant, so if you want to go with that you'd have to make some first... :shifty:

As for the UMMU transfer: I think For that to work, the active airlock on the target vessel has be on the same position as the dockport it's docked with, but I'm not sure. Currently the airlock position on the GIlgamesh is at 0,0,0, which certainly isn't where the dockport is. The problem is expounded however by the fact that the Gilgamesh extends its dockport... which means the airlock would have to be at the positionof the extended dockport.
I'm not entirely sure if my recollection of the mechanics here are correct. But in any case it's either that, or UMMU in generic vessel doesn't work quite as intended (how do you add a crew and EVA it on a generic vessel? I couldn't locate it in the documentation...).

 

[pattersoncr]

There's a few misconceptions here, as far as I can see. First, note that for resource transfer to work, BOTH vessels must have storage capacity for that resource. In your test scenario, the command module has no propellant storage whatsoever, so it can't transfer any propellant, no matter with what vessel.

I threw together the files above as an example rather than the actual station I'm trying to build since I made several custom configs (see below).

Second, I see that you have designated the resource on the gilgamesh as hydrogen-fluoride... while supported by the core, I don't think there's actually any thrusters or for that matter propellant tanks that support that particular propellant, so if you want to go with that you'd have to make some first... :shifty:

Since I was using the XR craft to launch components, I was postulating a similar level of technology for my station. I picked LHF for a fuel type that didn't seem like it was being used by any of the default modules. I made a couple some configs for LHF fuel tanks as well as LHF RCS thrusters. I gave the thrusters the same ISP as the XR5 (~26000m/s).

As for the UMMU transfer: I think For that to work, the active airlock on the target vessel has be on the same position as the dockport it's docked with, but I'm not sure. Currently the airlock position on the GIlgamesh is at 0,0,0, which certainly isn't where the dockport is. The problem is expounded however by the fact that the Gilgamesh extends its dockport... which means the airlock would have to be at the positionof the extended dockport.
I'm not entirely sure if my recollection of the mechanics here are correct. But in any case it's either that, or UMMU in generic vessel doesn't work quite as intended (how do you add a crew and EVA it on a generic vessel? I couldn't locate it in the documentation...).

I'll try to mess around with the UMMU airlock location to see whether that's the issue. Regarding the extending docking port, my understanding is that the docking port is always at the extended location, it is only an animated portion of the mesh that extends out to the (invisible) docking port location. As confirmation, you can have the Gilgamesh docked and retract the docking port. The docking port tube will retract but the hull of the Gilgamesh will stay where it is, a gap will open between the two vessels. Pg 9 of the pdf included in the genericvessel download shows the format for the UMMU entry bt I'm pretty fuzzy on exactly how genericvessel is supposed to work.

I guess I could try making a bare bones genericvessel craft and trying to get UMMU to work with that first.

Anyway thanks for your help so far and thanks for your work on this wonderful addition to Orbiter!
Is IMS2 still under development?


Sent from my iPhone using Tapatalk

 

[Face]

I'm trying to use Greg Burch's LSTS Gilgamesh Transport. and GenericVessel version 140205

I added this config file:

; === Configuration file for vessel Gilgamesh class ===

ClassName = LSTS2011
Module = GenericVessel
IMS_RES = LHF:0
; TODO: ImageBmp = Images\Vessels\???.bmp

; ======================================
; IMS specific parameters
; ======================================
IMS_RES = LHF:0

[UMMU]
MAXSEATS=3
AIRLOCK_POSITION=(0,0,0)
AIRLOCK_SIZE=(10,10,10)
EVA_POS=(0,0,0)
EVA_ROT=(0,0,3.14)

genericvessel version 140205 is Artlav's latest release. AFAIK, he removed the reading of INI-elements inside the configuration file. Instead, you have to author an INI file at the legacy location with the same name as the class name. His documentation describes this properly IMHO.

Looks like you don't have that setup, so the UMMU settings inside your config file will not have an effect.

 

[pattersoncr]

I also tried putting the UMMU lines in the ini file but that didn't work either. Face, can you comment on airlock location? Do you think incorrect airlock location would prevent a transfer?
Also I'm really confused regarding genericvessel. Can you comment on where its development currently stands?


Sent from my iPhone using Tapatalk

 

[Face]

Face, can you comment on airlock location? Do you think incorrect airlock location would prevent a transfer?

These are the appropriate code lines: https://bitbucket.org/face/genericv...icVessel.cpp?at=default#GenericVessel.cpp-404

The UMMU support just takes the INI parameters and forwards it to Dan's API. As written in my development thread, I have tried a simple configuration on the example vessels and it worked fine. I don't know what might cause your observations...

Also I'm really confused regarding genericvessel. Can you comment on where its development currently stands?

Well, I can only speak for the project I've started. As you may know, Artlav forked it with his thread there. The version you mentioned is from there.

I always tried to incorporate his changes as much as possible, though. The latest release here should have all of his work plus multi-arm-support plus animation bug fixes in it.

As for the current project status, I can say that it is still not feature-complete. Some missing elements/tags are documented here. ATM I'm working with Donamy on support for inverse arm kinematics, of course in parallel to slowly adding all the missing base features. After that, the plan is to activate my proposed SxS loader-concept (it is already implemented, but inactive), as well as getting rid of the Pascal code parts in favor of C++.

 

[pattersoncr]

Thanks Face. I'll tinker around with the 150310 version and see if I can make it work.


Sent from my iPhone using Tapatalk

---------- Post added at 07:45 PM ---------- Previous post was at 10:13 AM ----------

I installed version 150310 of Generic vessel and added UMMU lines to the .ini file with the airlock location matching the docking port location. Personnel transfer now works just fine. Thanks so much, Face!

Still no luck with propellant transfer.
(I added a compatible fuel tank to my test IMS vessel.)

 

[boogabooga]

I'm finding realistic-ish thermal management to be the genius of IMS.

 

[Dantassii]

I'm finding realistic-ish thermal management to be the genius of IMS.

I like that and the Life support/food production and storage. Not to mention the pretty ships/stations you can build with it.



Currently relaxing my brain converting the SSTV-01 into the SSTV-02 model since I've had several requests now for pictures of the SSTV-02 model before I send it off on its maiden voyage, a 100 day transit from Earth to Pluto. After I finish that, then its off to digging around in the code for IMS2.0.

Dantassii
HUMONGOUS IMS shipbuilder

 

[jedidia]

Still no luck with propellant transfer.

I'll have another look. I assume it's just the hydrogen fluoride, because frankly, we never tested that. There's technically not much that can go wrong with a simple identifier, but code is tricky that way.

 

[pattersoncr]

Transferring LHF between an IMS ship and an XR5 (with IMS RES line in the config) does work. Haven't tried other fuel types.


Sent from my iPhone using Tapatalk

 

[jedidia]

Ok, then we can exclude that too. Trouble is, that doesn't leave many possibilities that could be wrong on the IMS side, and I have no idea how generic vessel could possibly muck it up. I'll investigate later.

---------- Post added at 07:34 PM ---------- Previous post was at 06:12 PM ----------

Ok, we're both blind :lol:

IMS_RES = LHF:0

The propellant resource index is one-based, not zero-based. From the documentation I linked to earlier:

i is the index of the propellant resource (>= 1, check out propellant tab in scenario editor to see how many propellant resources a vessel has)

I think that should get you finally going.

 

[pattersoncr]

[/COLOR]Ok, we're both blind :lol:

IMS_RES = LHF:0

That did it!

 

[NukeET]

Well, I can only speak for the project I've started. As you may know, Artlav forked it with his thread there. The version you mentioned is from there.

I missed that. I should read more threads.

 

[Lmoy]

Has IMS RC9 been taken down? It doesn't appear to be available for download.

 

[jedidia]

No, it's still there, but I can confirm the download not working. Seems like ge.tt has some problems currently. I'll wait until this evening to see if it fixes itself.

 

[Dantassii]

No, it's still there, but I can confirm the download not working. Seems like ge.tt has some problems currently. I'll wait until this evening to see if it fixes itself.

I tried the download link when I posted my Lunar Station mission scenario a few months ago (March?) and it was broken then, so it's been broke for a while now.

Also, do we still need to download the 'special' DX9 patch that you created or have the changes you came up with been incorporated into the official DX9 release?

Dantassii
HUMONGOUS IMS shipbuilder

 

[jedidia]

I tried the download link when I posted my Lunar Station mission scenario a few months ago (March?) and it was broken then, so it's been broke for a while now.

It hasn't been down all that time. I downloaded it just a few weeks ago. I'll keep tabs on it, if it doesn't come back by tomorrow I might finally put it on the hangar. I was rather reluctant to do that because of the lack of documentation, but it's better than it not being available at all.

Also, do we still need to download the 'special' DX9 patch that you created or have the changes you came up with been incorporated into the official DX9 release?

No, I removed that some time ago from the front page.

 

[pattersoncr]

I downloaded IMS RC9 several weeks ago. No problems with the download. IMS2 on the other hand is unavailable.


Sent from my iPhone using Tapatalk

 

[jedidia]

IMS2 on the other hand is unavailable.

Of course it is. It's about two years away from being finished, and I never published a link except in the development group