New Release Interplanetary Modular Spacecraft RC9

[goaowonk]

Usually I need to restart Orbiter when I exit to the launchpad, `cause current state or quicksaves make it crash if not. It solves itself in that way, but I`not 100% sure wether IMS is the reason.

Also I cannot make IMS`s BD101 open its doors (k key when focused), but original one does work.

And I`ve noticed that making a vessel being landed via scenario editor removes its docking capability. Tonight I`ll post it.

Sent from my Deltaglider using Potatolk.

 

[jedidia]

I done messaged jedidia about it that the download link doesn't work and was wondering if anyone had a spare .rar of IMS_RC2.3 laying around?

My bad. I didn't realise PeterRoss included only the dll in the download. So you have to download RC2 first and then install RC 2.3 over it. Link on first page updated, sorry for the inconvienience.

Also I cannot make IMS`s BD101 open its doors (k key when focused), but original one does work.

Yes you can, but of course not with the same command it used to have. IMS doesn't link any keyboard commands at all, that could get really, really messy. Select the module in the schematic, you can open the doors in the module window (same place where you would deploy solar panels) and I think you can also open it through the Crew MFC, but I'm not quite sure about that anymore...

And I`ve noticed that making a vessel being landed via scenario editor removes its docking capability.

Orbiter limitation. Landed vessels cannot dock, period.

 

[VSI]

That solved it thanks :tiphat:

 

[goaowonk]

Orbiter limitation. Landed vessels cannot dock, period.

Even when I magically (scenario editor) bring it again into orbit?

Sent from my Deltaglider using Potatolk.

 

[jedidia]

Even when I magically (scenario editor) bring it again into orbit?

As soon as its state changes to landed, all docking relations are terminated. They don't get renewed when the vessel lifts off again.

 

[goaowonk]

They don't get renewed when the vessel lifts off again.

Ok. Thanks a lot for your explanation.

Sent from my Deltaglider using Potatolk.

 

[Dantassii]

Short update

I ran into a 'crash with too many of a given module' error with the BT100 truss objects that was overcome by changing the naming convention radically (using letters instead of numbers). So that's 2 modules now that have given me problems. BT101 and BT100. All other modules that I've used have either not given me troubles with 30+ of them on my station, or I haven't put enough to set off the limit. BT100's were numbered BT100-01, BT100-02, BT100-101, and BT100-102 and that crashed it. Named -101 and -102 to -Z1 and -Z2 and no crash.

On a positive note, just did mission 16 this evening and I have mission 17 loaded up and ready to launch tomorrow night. I also have my sandbox scenario up to what my station will look like after Mission 18 is complete. I'm averaging 1 complete mission per evening.

 

[jedidia]

I ran into a 'crash with too many of a given module' error

There is no such thing. No really, there isn't. What can happen is that you have too many modules docked together and Orbiter overflows the dockinfo line, but that usually doesn't lead to a crash, only to missing modules.

Integrating a module always bears a slight chance of a crash, due to an orbiter bug with deleting docking ports. Changing the integration order usually helps with that.

Or you might have sneaked in a space somewhere in a module name without noticing, but that usually doesn't result in a crash either.

 

[Dantassii]

Well, the only thing that seems to stop the crashing is using a different name for the module that causes the crash. And I make sure I don't have ANY spaces in my module names. But if start up Orbiter, add a module, save it, stop orbiter, and restart it and the simulation crashes when I try to load the saved module.. something is fishy... Then I use a totally different naming convention and it works fine on the first try.

Wish there was something in the orbiter.log or one of the 4-5 log files that get generated.. but there isn't.

---------- Post added at 23:27 ---------- Previous post was at 18:01 ----------

Just got my first 'crash' while integrating and I think I've found a possible cause. When you start integrating, the first few 'layers' of modules away from your command module fire off either the 'successful docking' or 'successful undocking' sound effect. However, once you start integrating modules that started more than say 2 or 3 layers away from your command module, you no longer hear any sound effects. However, it appears that they are still firing off. The messages can take up to 10 seconds to play and although Orbiter allows more than 1 to be playing at the same time (even more than 1 copy of the same sound effect) if you get too many of them going at once, BOOM!

The way I tested this is I setup a station with as many modules as I could attached within 2 layers of the command module, and then I started integrating them as fast as I could push the buttons. When I got more than 4 sounds running at the same time (three 10 second long docking and two+ 8 second long undocking) BOOM! it crashed... every time.

Now, if I patiently integrate each module and count to 10 before integrating the next module, I am able to integrate my station as it will look after Mission 22 w/out a single crash. I haven't counted the number of modules, but it looks like somewhere around 130. I also saw many more than 10 'integration snapshot' files in my IMS directory for this station, but some of them may be left over from earlier integrations that I threw away the end result.

I don't know the details of why or what. I'm just reporting the symptoms as I find them in hopes that it will ring a bell and you'll have a Eurika! moment. If I stumble across any other details, I'll post them.

 

[jedidia]

Just got my first 'crash' while integrating and I think I've found a possible cause.

The major cause is perfectly known to me

However, it sounds from your description that an additional problem might be orbiter sound overflowing because of queing sound effects, which sounds perfectly possible, especially since I never tested with orbiter sound. Alas, there's nothing I can do about that either. I think you can disable the docking messages somewhere in the orbiter sound configuration, could you see if that alieviates the problem? If yes, that's valuable information to pass on to users...

 

[Dantassii]

Next time I do a mass integration of my station (to see if it works) I'll turn off Orbiter sound and see if that helps with the 'sound crash'.

I realize that some of these things I'm reporting are outside of your control, and that some of them may have already been reported. I'm relatively new to Orbiter (less than a year) and I'm just trying to help out in any way I can.

 

[NukeET]

Just out of curiosity, does anyone know what the largest ship (in terms of # of modules before integration) ever built with IMS is?

I just finished integrating 83 modules without CTD.


@Jedidia:

What happened to the animated radiator panels for GregBurch's BNG01 Nuclear Generator? The original had deployable/rotatable panels.

The IMS version is limited to offline/online for power.

 

[BruceJohnJennerLawso]

The major cause is perfectly known to me

However, it sounds from your description that an additional problem might be orbiter sound overflowing because of queing sound effects, which sounds perfectly possible, especially since I never tested with orbiter sound. Alas, there's nothing I can do about that either. I think you can disable the docking messages somewhere in the orbiter sound configuration, could you see if that alieviates the problem? If yes, that's valuable information to pass on to users...

So the issue is related to docking port deletion, Orbitersound, or both?

page 105/144 by the way. I think I should be able to understand most of the IMS source code now, with a bit of help.

I just finished integrating 83 modules without CTD.

Yes, IMS 2.3 improved immensely at integration over RC 2.0, thanks to PeterRosses good work. If we can just weed out those bugs with the RCS & huge vessels, IMS will be very stable IMO.

@Jedidia:

What happened to the animated radiator panels for GregBurch's BNG01 Nuclear Generator? The original had deployable/rotatable panels.

The IMS version is limited to offline/online for power.

Check the schematic near the generator for a separate radiator. The radiators do work as far as I know.

 

[NukeET]

Check the schematic near the generator for a separate radiator. The radiators do work as far as I know.

Thanks! I was able to deploy them.


Is this mentioned anywhere in the "documentation"?

 

[BruceJohnJennerLawso]

Thanks! I was able to deploy them.


Is this mentioned anywhere in the "documentation"?

:lol:, not exactly. The documentation has been a monster project, so it will definitely take some time. I will try to remember to put in a note about it though.

 

[Dantassii]

I'm having problems with integrating a habitat ring. I'm going to try ordering the ring into 1 or 2 parts instead of 4 parts. Part 2 of 4 seems to rotate parts when I start linking part 1 of 4 in rather unusual ways. If I can figure out a way of linking the parts that doesn't rotate, I'll post it here, if I can't, I'll post a scenario that can be used to demonstrate this problem.

I'm up to 200 modules in my station after 22 XR5 missions... and I'm not even half way yet....

 

[jedidia]

Part 2 of 4 seems to rotate parts when I start linking part 1 of 4 in rather unusual ways.

That might be because you rotated stacked modules... that is another orbiter limitation I only found an insufficient workaround. In effect, if you rotate a module before integration, the modules docked to it and those docked to them don't update their positions. This can lead to rather funny stuff on integration, especially if there's both modules docked before and docked after the rotation...

If you rotate one module before integration and there's other stuff docked to it, this could very well be the cause. Otherwise I need lots of additional information and screenshots.

 

[Dantassii]

The only problem I had was when I docked the Part 2 modules to the BN200 that I put on the end of arm. Parts 1, 3 and 4 when I docked the first ring I docked port 1 of the ring to port 3 of the BN200. On Part 2 however, that resulted in the part going the opposite direction, so I had to dock port 2 of the ring to Port 3 of the BN200.

I'm going to undock the entire ring after Mission 22 (that's when all the parts will be in place) and redock it 1 piece at a time all in 1 ring starting at the first BN200. Then I'll integrate and see if that resolves the problem. If not, I'll try a few other ideas. I figure it's something to do with the order that the parts are docked to the space station or the order that they are integrated, or both.

 

[Dantassii]

New Question

If my hab ring starts rotating un-integrated components around as I integrate it due to undocking/redocking during the integration process (a known Orbiter bug), what is the suggested means to 'fix' the modules so I can continue integrating?

1) Delete all the rotated parts, and re-add them
2) Try to use the 'rotate' command to rotate them back into the correct position
3) Some other idea?

1) is hard because I'd be re-adding them to the integrated ship and finding the correct docking node out of the 200+ that are on my integrated ship will be a mess. Also if I wait until the last minute to integrate the hab ring, I may end up deleting 90 percent of it (and each ring is over 100 modules a piece).

2) is hard because I'm not 100% sure which way to rotate a module that is out of alignment. Also, when 1 module rotates, everything still attached to it rotates as well.. so I'd have to undock each module and rotate each one individually. Might be easier to do 1).

Some of the rotations are really bizzare, as in BN200 nodes getting rotated 45 degrees out of alignment with anything they are still connected too. There also seems to be confusion when a module is docked to 1 module but is aligned so that it can dock with another module. When the module it is actually attached to is integrated, it undocks the unintegrated module, whcih then proceeds to automatically try to dock with anything around it that it can.. of course this causes problems when the 'integration' process attempts to redock with the unintegrated component and finds it isn't undocked any more...

For example:

Module 1 is attached to module 2 and one of the unused docking nodes on Module 1 is lined up with an unused docking node on module 3. Module 3 is aready connected to module 1 through its connection to module 2, so Orbiter won't let you dock Module 1 to Module 3 directly. Now if I undock module 2 from module 1, module 1 appears to automatically dock itself with module 3. Of course when this happens because module 2 was 'integrated', I suspect it the whole thing gets totally confused when it tries to redock with module 1 and runs into no circular docking allowed since module 1 is now connected to module 3 and module 3 is connected to module 2.

I don't know if this is a bug with Orbiter, or a bug with the 'integration' process of IMS, or a bug in both, or even something totally unrelated. It may even be a known bug that can't be fixed.

I figure it can't hurt to document the apparent cause-n-effect that I'm seeing just in case it isn't something someone has figured out before.

 

[NukeET]

I may have found a new bug (perhaps a feature?) concerning IDS frequencies assigned to docking ports on a integrated and unsealed vessel.

As long as I boot a scenario with the IDS definition following the DOCKPORT section, the IDS frequencies work as intended. See code snippet:

...
...
...
  DOCKPORT 2.4247,20.3042,-7.3131 1,0,0 0,1,0
  DOCKPORT -2.4248,20.3042,-7.3131 -1,0,0 0,1,0
  DOCKPORT 0,20.3042,-9.7378 0,0,-1 0,1,0
  DOCKPORT 0,20.3042,-4.8883 0,0,1 0,1,0
  DOCKPORT 2.4247,40.6084,-7.3131 1,0,0 0,-1,0
  DOCKPORT -2.4248,40.6084,-7.3131 -1,0,0 0,-1,0
  DOCKPORT 0,40.6084,-4.8883 0,0,1 0,-1,0
  DOCKPORT 0,40.6084,-9.7378 0,0,-1 0,-1,0
  DOCKPORT 54.0492,30.4563,-2.3131 0,0,1 0,1,0
  DOCKPORT 54.0492,30.4563,-12.3131 0,0,-1 0,1,0
  DOCKPORT 52.6653,30.4563,-7.3131 1,0,0 0,0,1
  DOCKPORT -54.0492,30.4563,-12.3131 0,0,-1 0,1,0
  DOCKPORT -54.0492,30.4563,-2.313 0,0,1 0,1,0
  DOCKPORT -52.6653,30.4563,-7.313 -1,0,0 0,0,-1
...
...
...
[B]IDS 0:20 100 1:40 100 2:60 100 3:80 100 4:100 100 5:120 100 6:140 100 7:160 100 8:180 100 9:200 100 10:220 100 11:240 100 12:260 100 13:280 100
[/B]END

Yet, if I save it, then boot the newly created scenario, I get this:

 STATUS Orbiting Moon
  RPOS 1348988.12 66104.11 -2382781.49
  RVEL -1165.336 26.366 -658.188
  AROT 79.64 -13.20 15.53
  AFCMODE 7
  PRPLEVEL 4:0.856052
[B]IDS 0:20 100 1:40 100 2:60 100 3:80 100 4:100 100 5:120 100 6:140 100 7:160 100 8:180 100 9:200 100 10:220 100 11:240 100 12:260 100 13:280 100
[/B]  NAVFREQ 0 0
  XPDR 1
...
...
...
  DOCKPORT 2.4247,20.3042,-7.3131 1,0,0 0,1,0
  DOCKPORT -2.4248,20.3042,-7.3131 -1,0,0 0,1,0
  DOCKPORT 0,20.3042,-9.7378 0,0,-1 0,1,0
  DOCKPORT 0,20.3042,-4.8883 0,0,1 0,1,0
  DOCKPORT 2.4247,40.6084,-7.3131 1,0,0 0,-1,0
  DOCKPORT -2.4248,40.6084,-7.3131 -1,0,0 0,-1,0
  DOCKPORT 0,40.6084,-4.8883 0,0,1 0,-1,0
  DOCKPORT 0,40.6084,-9.7378 0,0,-1 0,-1,0
  DOCKPORT 54.0492,30.4563,-2.3131 0,0,1 0,1,0
  DOCKPORT 54.0492,30.4563,-12.3131 0,0,-1 0,1,0
  DOCKPORT 52.6653,30.4563,-7.3131 1,0,0 0,0,1
  DOCKPORT -54.0492,30.4563,-12.3131 0,0,-1 0,1,0
  DOCKPORT -54.0492,30.4563,-2.313 0,0,1 0,1,0
  DOCKPORT -52.6653,30.4563,-7.313 -1,0,0 0,0,-1
...
...
...
END

The end result is 14 docking ports with no assigned IDS frequencies.

This is a work around for now...yet would like to see this resolved.