New Release Interplanetary Modular Spacecraft RC9

[jedidia]

Interplanetary modular spacecraft lets you construct your own spacecraft (or space stations) from modules.

Get RC9 here

Now with D3D9 compatibility!
fixes a few minor things and a pretty ugly bug.

IMS officially recommends to use the Orbiter StackEditor as a convienient means to layout and spawn your required modules.


Features:

-Merges meshes, animations and properties of modules with appropriate config files into one vessel
-rotating centrifuges, suntracking solar panels, target tracking antennae, etc.
-Life support, Power and Thermodynamics simulation
-Resources and propellant transfers between IMS vessels, cargo modules and even unrelated vessels if they have an appropriate config line
-dynamic panels you can set up to display the information you need
-Save completed vessel to a config file from where it can be loaded by scenario editor or shared with other IMS users.
-Create your own modules by config files


Dependencies:
UMMU 2.0
[ame="[URL]http://www.orbithangar.com/searchid.php?ID=3177[/URL]"]SSBB 4.1B[/ame]


Important Notes:

-Do NOT use spaces in vessel's names, neither in the names of individual modules nor in the name of the vessel you are building. Vessels with spaces in their names cause premature termination when reading scenario entries and will therefore lead to trouble with loading IMS, UCGO and even the orbiter-native DOCKINFO entries. Additionally, UMMU is incapable of transfering crew to a vessel that has a space in the name!

-It is strongly recommended to deactivate OrbiterSound during integrations (there are no problems otherwise). The number of docking messages spawned by IMS during integration can easily cause a crash!

- IMS listens to the orbiter damage and failure simulation flag. If you want failure modes, dying crew and power consumption, damage and failure simulation has to be activated in the orbiter launchpad. If you just want to build something fun and not bother with cooling, heating, power and lifesupport concerns, deactivate damage simulation. While everything will still be processed, modules will work even if outside temperature range, insufficient power or lack of consumables. There will be no messages in the systems MFC.


Documentation:

There is no documentation in the download yet, we are still working on that. However, there is almost complete documentation in the development group (although you might stumble over a few things that are not quite accurate anymore, if so, please do tell):
See here for a quickstart tutorial and a description of the IMS panel elements

Since just knowing how to screw stuff together is only the secondary part of spacecraft design, there is the Spacecraft design for dummies guide to introduce the physical aspects and how IMS exactly handles them. This is very much recommended reading. It is absolutely required reading before you post a bug about thermodynamics issues, because most probably it won't be one.If you absolutely totally can't wait to make your own modules, there's a good part of the modders guide located here. It's just currently trimmed on adapting already existing Orbiter configs and spacecraft 3 inis, but it's all there is in that department currently.


Known Issues:

-Can massively wreck your framerate if you build too wild for your machine.
-Crashes on startup if launchpad wasn't closed between sessions. This was traced to an actual orbiter bug that demonstrates this behavior if shiftCG is called during vessel initialisation. Unfortunately, IMS has to call it then to work properly, so this is unfixable from my end.

Credits:

This was a group effort, not a one-man show!

original proof of concept: vchamp
coding: vchamp, Jedidia, PeterRoss
models&textures: PeterRoss, xx_mortekai_xx, MaverickSawyer, Hlynkacg, vchamp, Jedidia
config files: Jarod, PeterRoss, IceDown
testing: PeterRoss, Nexiss
additional release testing: IceDown, CaptainComic, Dores, Dantassii

Special thanks to Greg Burch, who gave us a great selection of modules to fall back on when we realised that we won't get enough models done of our own. I have been unable to contact him, but since we do not actually include parts of his add-on but make it a mandatory download, there shouldn't be any problems. Indeed, if he ever learns of this, I hope he will be glad to see that his add-ons are still in use and their purpose even expanded.
Also much thanks to Countdown84, who let us copy his XR5 configurations for SSBB 4.1, saving us a lot of hassle.

Future Plans:

Since the current architecture is limited and provides severe difficulties when trying to add new features, IMS will NOT add any new features in the future. Instead, a complete rewrite to a new architecture has been started under the name IMS2. This has started out very promising, but is currently on ice until further notice, because kids. Seriously, try getting twins and see what that does to your sanity...

Thanks again to everyone involved here, you guys have been teriffic!

Changelog:

fixed bug that prevented heat dissipation until the engineering panel was accessed the first time in a session (RC9)
fixed wrongly displayed animation names for custom named animations (RC9)
fixed a ctd in connection with general purpose module animations (RC9)
fixed some more startup animation problems with finalised vessels (RC9)
current animation states not saved to cfg anymore (RC8)
fixed "hyperspace jump" after booster ignition (RC8)
fixed regeneration multiplication in finalised vessels (RC7)
fixed consumables loading from scenario (RC7, hopefully for real this time)
fixed faulty consumables loading (RC6)
fixed miraculous lifesupport multiplication (RC5)
fixed sharing of consumables with non-IMS vessels (RC5)
new folder structure for config files (RC4)
autoattach only after integration (RC4)
fixed several memory leaks (RC4)
fixed PMI calculation (not retroactive!) (RC4)
introduced auto-attach and list-integration (RC3)
fixed random wrong rotations and vanishing meshes on integration (RC3)
removed crashes in connection with integrations (RC3)
fixed displaced thrusters when spawning finalised vessels from Scenario Editor (RC3)
added D3D9Client compatibility (RC3)
fixed module duplication after loading autosave (RC2.3)
fixed several problems with finalised vessels (RC2.3)
fixed disappearing radiators on export to config file (RC2)
fixed engines restoring state on CoG shift (RC2)
fixed animations of composite modules with non-centric animation reference (RC2)
fixed deletion of docking ports on integration (RC2)
added missing GCNTR mesh (RC2)
added missing reactor texture (RC2)
added missing Trussnode (RC2)

 

[PeterRoss]

There's currently not a single chemical engine

In fact there is one LOX_LH2 chemical engine in SBB41B configs.

 

[Scattykat]

And the release has come in on a Monday!
Thank you!

 

[PeterRoss]

And the release has come in on a Monday!
Thank you!

Hey, it's Tuesday on my side of the planet alright!:lol:

 

[BruceJohnJennerLawso]

Out of curiosity, has this project seemed to support the Mars Direct way of designing Interplanetary Missions (small & simple as possible), or does bigger tend to mean better with IMS?

 

[PeterRoss]

It's up to designer. Although modules included in the RC1 are all big and clumsy, I made some small-sized modules for testing reasons and it was working quite well. There may be problems though if attachment points will be very close.

 

[jedidia]

Out of curiosity, has this project seemed to support the Mars Direct way of designing Interplanetary Missions (small & simple as possible), or does bigger tend to mean better with IMS?

This is more a question of how the configs are designed. We tried to provide configs that offer a lot of flexibility as a standard package, which means that they won't fulfill highly specialised purposes. If you make your own config files you can make them as specialised as you want to, reducing their flexibility to increase usefulness in a specific configuration. Indeed it is even possible to force the user to put your modules together a certain way if you do your own configs, so there's nothing preventing you from designing modules intended to be used in an exact ship configuration. This will certainly result in the best use of mass, though not necessarily in the most fun for end-users.

 

[Tacolev]

Here's a question: I'm assuming I'm doing something wrong but for the life of me I can't seem to keep my crew alive no matter how favorable I keep the conditions and no matter how much in the way of equipment and consumables I integrate. The life support mfc stay at div/0, no messages come up in the status display, and the crew dies in short order.

 

[jedidia]

The life support mfc stay at div/0, no messages come up in the status display, and the crew dies in short order.

That is disturbing. Can you post the scenario?

 

[PeterRoss]

Could you please post your scenario here before the crew is dead? I assume it's something simple like no power applied to lifesupport or there's no storage to keep consumables. Or pretty much anything else. What is Systems MFC saying?

Ninja'd

 

[Hlynkacg]

Good ol gas guzzlers

Hey Jedia,

see attached.

 

[jedidia]

:woohoo:

Thanks a lot!

 

[Tacolev]

Aha!

Sorry to throw you guys in a panic it was two things I hadn't noticed: storage modules come empty and the production by regenerating modules is tiny relative to storage, so I plain out didn't notice when it shifted to 0.00 from the nullity case since there was still no indicator bar.

This led to me to over-react and try a "simpler" case with only the storage modules--which I didn't know had come empty--and hence all the dead crew members. Again, sorry for going off half-cocked. You guys have lived and breathed this thing for months so it must seem second nature.

 

[PeterRoss]

Aha!

Sorry to throw you guys in a panic it was two things I hadn't noticed: storage modules come empty and the production by regenerating modules is tiny relative to storage, so I plain out didn't notice when it shifted to 0.00 from the nullity case since there was still no indicator bar.

This led to me to over-react and try a "simpler" case with only the storage modules--which I didn't know had come empty--and hence all the dead crew members. Again, sorry for going off half-cocked. You guys have lived and breathed this thing for months so it must seem second nature.

Tell you what, noone ever built an IMS without finding a bug which appeared to be a feature after some research :lol: It's OK, and it's good you found out what was the problem.

About storage modules - it's my fault as config writer that it's not clear if module is spawned empty or full. Here's an explaination: cargo containers are being spawned full, cargo storages are being spawned empty. There's is some logic behind this decision: modules are intended to be integrated parts of a vessel while cargo containers are meant to be a supply tool (although it is possible to integrate cargo containers into a vessel as well).

 

[Tacolev]

Ai, the reasoning became quite apparent once I noticed I hadn't been looking at the cargoes at all.

And since I'm not in the dev group, here's a legitimate bug that I've been getting: With the exception of quicksaves and the "(current scenario)" of a work-in-progress, if I save a scenario, the radiators will be completely wiped from the engineering console, as though they don't exist.

A workaround I've been using to allow a craft to be added from the scenario editor is to go and copy the states of the radiators from the scenario file manually into a "finalized" config file but then I get another curious problem of the radiators being doubled if I load up the scenario again from a quicksave or the (current scenario). Any idea what's going on?

 

[jedidia]

I'm not quite sure I follow. Define "wiped", and define whether it happens after saving or after reloading.

In your second paragraph, you seem to talk about finalisation, which would be a different animal entirely to simple saving and loading of a scenario. It is possible that finalisation does not retain radiator configurations, although it should. If that is the only problem, there is indeed something wrong in the parser.

Note however that fialisation is not intended to save the vessel state, but rather to provide a file from where vessels of this type can be spawned without much hassle. I.E. they spawn completely powered down, with full tanks and stores, but theyshould retain the crew and the radiator configuration, as these things are usually pretty tedious to do for larger vessels. So again, if by "wiped" you mean that no modules are connected to the radiators, and if this happens on finalisation, it's a bug, but a pretty simple one.

If it happens on simple sql, or even on saving alone, then that would be a pretty darn serious bug that noone has noticed yet (probably undefined behavior). The same applies if by wiped you mean that the radiators don't show up on the engineering panel at all anymore.

 

[Tacolev]

By "wiped" I mean they don't show up in the engineering panel.
Vessel:

Panel:

 

[PeterRoss]

Try unzoom the panel.

EDIT. Oh. The last image is an interesting one indeed.

 

[Tacolev]

Certainly:

 

[PeterRoss]

I see the problem. Unzooming was about the picture you posted wrongly before you edited your post.