Orbiter 2016 only!
We are proud to show off what we've been working on for the past two years: Interplanetary Modular Spacecraft, version 2.
The very first Alpha, that is.
Download it here. The page contains installation instructions and a link to what currently passes for a manual. Also, there's two scenarios included in the distribution to show off a tiny bit.
IMS2, like its predecessor IMS, allows you to build spacecraft from Modules in Orbiter.
In its current state, IMS2 isn't quite up there yet with the old IMS in terms of features. The reason for this is that IMS2 is a complete rewrite of the old IMS from scratch, and not developed on its code. This was neccessary because the architecture of IMS was very ill-suited for what it was actually supposed to do. Maintaining it would be difficult, and adding new features an outright nightmare. IMS2 on the other hand sports an architecture that is flexible and easily extendable, meaning that one fine day it will surpass the original in each and every way.
Right now, IMS2 implements the basic required features to get a working spacecraft in orbiter, which are:
Current Features:
further development.
Known Issues:
As a piece of software in the very early alpha stages, there will be bugs, and loose ends. I'll just let you know the ones we already know about:
Future plans:
We don't really have an all too clear vision for the project, but at least we have a decent plan.
You can take a look at the roadmap here. It's not definite, but it should give you a coarse overview over what can be expected at which point in the project.
Credits:
Core team:
Dantassii: Testing
PeterRoss: Testing and some meshes
Jedidia: Overall Architecture, Code
Additional contributors:
HlynkaCG: J2-mesh and Killrot-AP logic
Meson800: Prototype implementation of intelligent RCS
Orb: Some functions for vector rotations
VChamp: IMS legacy code
xx_mortekai_xx: VASIMR meshes
---------- Post added at 08:39 PM ---------- Previous post was at 08:38 PM ----------
We're looking for contributors!
IMS2 is a pretty large project, and development could profit greatly from additional hands. Here's a short job-list in case you're interested.
One general rule for contributors to consider:
I'm posting this rule right here, right now, because I have long experience working with volunteer teams, software related and otherwise: The rule is that you commit, and then follow through. The commitment doesn't need to be large. It can be for a simple, small thing. In fact, I'll much more appreciate it if you commit to a very small thing and deliver than if you're committing to large stretches of the project and leave with a ton of half-finished stuff in the wake. Even a commitment of "I'm not sure how much I'll be able to contribute, I'll just take it bit by bit, starting with this particular thing" is ok, as long as you finish one bit after another, and clearly communicate when you're out.
I'm making this rule to not waste your effort as much as to not waste mine: Halfway finished and badly documented stuff is almost impossible to integrate into a project like this, and it will possibly be done by somebody else from scratch. And running after people to ask them how far along they are with something and if they're ever going to finish it because it would be kind of important to have at this point is a hassle I don't need. If somebody says he's going to do something, I want to be able to rely on it getting done.
So, if you're all enthusiastic about this project and want to help us out (which is great), take a short timeout and think about what you can realistically do with the time and skill available to you, then come tell us, either here, or by PM. If you want to do something and are unsure how much time is involved, ask. I'm usually very responsive to questions.
Texturers/Modellers:
We would really like to get rid of the dependency on SSBB4, mostly because they look really dated by now. I hope that when this thing is finished, we'll have a complete replacement with modules that support D3D9-features like normal maps. Unfortunately, we don't yet have anybody capable of doing it, much less any kind of artistic vision of what stuff should actually look like.
Take note however that this is calling for texturers and mappers a lot more than for modellers: The geometries involved are fairly simple most of the time, and we'd like to keep it that way. We don't want to hit polly-overkill on a vessel with 30 to 50 modules already. So most of the detail should come from textures and maps.
We don't have a lot to offer interested modellers right now, except for a good team atmosphere, a quick way to get models functional in orbiter, and creative freedom. In fact, if somebody could take a bit of a lead on the artistic side, that would be great.
For this reason I'm afraid We'll have to turn down beginners, though.
Coders:
This is a coding project of some complexity, so coders are of course always welcome. There's multiple interesting areas to work in right now, and there's always the possibility that you might want to create a niche of your own that nobody of us has thought about yet. This is an open source project under the MIT licence though, so you have to be aware that whatever code you contribute will be shared with the rest of the world.
Right now, generic work can be done on basic implementations of further module functionalities (similar to the current comms module), but also relatively detailed and focused work on implementing more complex models for different engine types, like behavior of chemical, nuclear, electric or whatever rockets. Also, this list will be expanding pretty rapidly with further development, as each new core feature implemented into IMS2 will offer a wealth of new possibilities in the periphery.
For interested coders, we offer pretty solid documentation and even a detailed guide for implementing new module functions and using some of the tools that the core framework provides.
As for required level, I can offer individual help and can also do some handholding for beginners, but you should definitely be the kind of person that looks for solutions on his own before asking questions. If in doubt, read the modulefunction guide above. If you're reaction is "Uhu, I'm getting the general gist of it, but it feels a bit above my head", that's perfectly fine. If you have no idea whatsoever what I'm talking about in that guide, you should maybe do a few tutorials on Object-Oriented programming and encapsulation first.
Researchers:
Not a very glamorous job, but a very important one. See, I'm dealing with code, and architecture, and how this is all supposed to work inside the simulation. My work is concerned with correct results for any input. I hardly find the time to check whether any of my inputs actually make sense. How heavy is a habitat module with such-and-such volume expected to be? I don't know. How heavy is a pump that can handle this much massflow, and how much power does it eat? I don't know. How much volume does a zero-G toilet take up? I don't know. I think you get the picture by now. In the end, IMS2 can have great systems simulation, it will still feel unrealistic if I was just rolling dice when deciding on the values that define its outcome. We could really use one or two people that can dig through tech-manuals, charts and whatnot to come up with sensible values in an IMS2 specific context. There's no coding involved. There's config-file writing involved (aka "Modding") if you want to, but not neccessarily. In essence, you're a cross between a detective and an engineer, but then I sometimes wonder where exactly the difference between those two is anyways.
Testers:
We have two dedicated testers right now, which is a blessing I cannot overstate during a pre-alpha phase. Without them, this thing might be a little further along the road feature-wise, but with half those features broken. Right now, those two testers are doing a good job at keeping up with the one coder, so we don't have any immediate need for more, which does not mean that one or two more wouldn't be helpful.
In general, Testing means methodically breaking stuff, and rigorously documenting how you broke it. Sounds simple enough, but usually isn't.
A UI-designer (also known as interaction designer nowadays):
By which I don't mean visual design. Sure, somebody with a good sense for color scheems could do a bit of something, but the whole UI will be reskinable via config files once "The Great GUI-Refactoring" happens, a mystic future event foretold by the Prophets of neccessity. In other words, trying to fix the visuals of the UI at this point in time would be a waste of effort. No, what I'm talking about is somebody that is willing to get familiar with what IMS2 is trying to do, and spend some serious thought about how to best structure the UI so the user can do what needs to be done in an intuitive way without a hundred mouseclicks, so IMS2 doesn't end up with a convoluted and difficult to navigate menu structure like MS-Word in the mid 2000s.
Coding skills are not neccessary for this job. It's about defining how the UI should work, not making it work that way, although it would of course be considered a perk if you are able/willing to help with that. Somebody interested in the job should have done similar things before, even if only on paper.
We are proud to show off what we've been working on for the past two years: Interplanetary Modular Spacecraft, version 2.
The very first Alpha, that is.
Download it here. The page contains installation instructions and a link to what currently passes for a manual. Also, there's two scenarios included in the distribution to show off a tiny bit.
IMS2, like its predecessor IMS, allows you to build spacecraft from Modules in Orbiter.
In its current state, IMS2 isn't quite up there yet with the old IMS in terms of features. The reason for this is that IMS2 is a complete rewrite of the old IMS from scratch, and not developed on its code. This was neccessary because the architecture of IMS was very ill-suited for what it was actually supposed to do. Maintaining it would be difficult, and adding new features an outright nightmare. IMS2 on the other hand sports an architecture that is flexible and easily extendable, meaning that one fine day it will surpass the original in each and every way.
Right now, IMS2 implements the basic required features to get a working spacecraft in orbiter, which are:
Current Features:
- Constructable from modules: Merge IMS2 modules into a single spacecraft
- Constructable from preassembled parts: Merge entire, already assembled IMS2 vessels into a singe spacecraft.
- Constructable in one click: Merge entire docked stacks of modules and vessels with one single mouseclick.
- Deconstructable: Split merged IMS2 vessels into multiple spacecraft
- Complex propellant management: Components of propellant mixtures (like for example LOX/LH2) are drawn from individual propellant tanks.
- Multi-mode thrusters: Thrusters can have multiple modes defined with different thrust/ISP values and even different propellants, which can be switched at wll during the simulation.
- Complex CoG: Center of Gravity is the result of how you build your spacecraft, and moves with propellant consumption.
- Intelligent RCS: IMS2 vessels consider position relative to CoG, alignement and power of individual RCS thrusters, and aims to eliminate translation when rotating and rotation when translating.
- Fully landable: IMS2 vessels can be outfitted with landing gear, giving you the ability to build landers. Even without landing gear, IMS2 vessels define a hullshape for full Orbiter 2016 terrain collision. If you're wondering, yes, that means you can also build bases out of modules.
- Animated: IMS2 has quite a powerful and flexible animation framework built in. Unfortunately, there's not yet many modules that actually make use of it, but take a look at the Comms module for a glimpse of things to come.
further development.
Known Issues:
As a piece of software in the very early alpha stages, there will be bugs, and loose ends. I'll just let you know the ones we already know about:
- On entering the cockpit, you'll see a blue, empty panel. This is the future construction site of the flight panel. Right now, you'll have to use the standard glass cockpit (F8) to fly your vessel, and there's a basic menu for IMS2-related operations available by pressing ctrl-down.
- The UI sucks: IMS2 has a rudimentary GUI-toolkit propped on top of the Orbiter panel structure that will allow us to develop a decent user interface. The current interface arrangement, however, is highly impractical and shows the early development stage. You can do all you need to do, but you'll be clicking your way through a few menus.
- XYZ-MFD doesn't work: Due to IMS2's intelligent RCS, MFD autopilots usually have a hard time controlling IMS2 vessels. There's a switch in the general configurations menu to turn intelligent RCS off, which should fix that problem.
- Stock autopilots are somewhat erratic: See above. There's an IMS2-specific implementation for Killrot though, so that one you can always rely on.
- When I place my constructed vessel with landing gear on a planetary surface using scenario editor, it ends up at the center of the planet: Turn on "scened placement assist" in the general configuration menu.
- There's no controls for landing gear: You're supposed to press 'G'.
- Thrusters aren't working: At least not as long as you don't assign them to a thruster group and make sure they got propellant.
Future plans:
We don't really have an all too clear vision for the project, but at least we have a decent plan.
You can take a look at the roadmap here. It's not definite, but it should give you a coarse overview over what can be expected at which point in the project.
Credits:
Core team:
Dantassii: Testing
PeterRoss: Testing and some meshes
Jedidia: Overall Architecture, Code
Additional contributors:
HlynkaCG: J2-mesh and Killrot-AP logic
Meson800: Prototype implementation of intelligent RCS
Orb: Some functions for vector rotations
VChamp: IMS legacy code
xx_mortekai_xx: VASIMR meshes
---------- Post added at 08:39 PM ---------- Previous post was at 08:38 PM ----------
We're looking for contributors!
IMS2 is a pretty large project, and development could profit greatly from additional hands. Here's a short job-list in case you're interested.
One general rule for contributors to consider:
I'm posting this rule right here, right now, because I have long experience working with volunteer teams, software related and otherwise: The rule is that you commit, and then follow through. The commitment doesn't need to be large. It can be for a simple, small thing. In fact, I'll much more appreciate it if you commit to a very small thing and deliver than if you're committing to large stretches of the project and leave with a ton of half-finished stuff in the wake. Even a commitment of "I'm not sure how much I'll be able to contribute, I'll just take it bit by bit, starting with this particular thing" is ok, as long as you finish one bit after another, and clearly communicate when you're out.
I'm making this rule to not waste your effort as much as to not waste mine: Halfway finished and badly documented stuff is almost impossible to integrate into a project like this, and it will possibly be done by somebody else from scratch. And running after people to ask them how far along they are with something and if they're ever going to finish it because it would be kind of important to have at this point is a hassle I don't need. If somebody says he's going to do something, I want to be able to rely on it getting done.
So, if you're all enthusiastic about this project and want to help us out (which is great), take a short timeout and think about what you can realistically do with the time and skill available to you, then come tell us, either here, or by PM. If you want to do something and are unsure how much time is involved, ask. I'm usually very responsive to questions.
Texturers/Modellers:
We would really like to get rid of the dependency on SSBB4, mostly because they look really dated by now. I hope that when this thing is finished, we'll have a complete replacement with modules that support D3D9-features like normal maps. Unfortunately, we don't yet have anybody capable of doing it, much less any kind of artistic vision of what stuff should actually look like.
Take note however that this is calling for texturers and mappers a lot more than for modellers: The geometries involved are fairly simple most of the time, and we'd like to keep it that way. We don't want to hit polly-overkill on a vessel with 30 to 50 modules already. So most of the detail should come from textures and maps.
We don't have a lot to offer interested modellers right now, except for a good team atmosphere, a quick way to get models functional in orbiter, and creative freedom. In fact, if somebody could take a bit of a lead on the artistic side, that would be great.
For this reason I'm afraid We'll have to turn down beginners, though.
Coders:
This is a coding project of some complexity, so coders are of course always welcome. There's multiple interesting areas to work in right now, and there's always the possibility that you might want to create a niche of your own that nobody of us has thought about yet. This is an open source project under the MIT licence though, so you have to be aware that whatever code you contribute will be shared with the rest of the world.
Right now, generic work can be done on basic implementations of further module functionalities (similar to the current comms module), but also relatively detailed and focused work on implementing more complex models for different engine types, like behavior of chemical, nuclear, electric or whatever rockets. Also, this list will be expanding pretty rapidly with further development, as each new core feature implemented into IMS2 will offer a wealth of new possibilities in the periphery.
For interested coders, we offer pretty solid documentation and even a detailed guide for implementing new module functions and using some of the tools that the core framework provides.
As for required level, I can offer individual help and can also do some handholding for beginners, but you should definitely be the kind of person that looks for solutions on his own before asking questions. If in doubt, read the modulefunction guide above. If you're reaction is "Uhu, I'm getting the general gist of it, but it feels a bit above my head", that's perfectly fine. If you have no idea whatsoever what I'm talking about in that guide, you should maybe do a few tutorials on Object-Oriented programming and encapsulation first.
Researchers:
Not a very glamorous job, but a very important one. See, I'm dealing with code, and architecture, and how this is all supposed to work inside the simulation. My work is concerned with correct results for any input. I hardly find the time to check whether any of my inputs actually make sense. How heavy is a habitat module with such-and-such volume expected to be? I don't know. How heavy is a pump that can handle this much massflow, and how much power does it eat? I don't know. How much volume does a zero-G toilet take up? I don't know. I think you get the picture by now. In the end, IMS2 can have great systems simulation, it will still feel unrealistic if I was just rolling dice when deciding on the values that define its outcome. We could really use one or two people that can dig through tech-manuals, charts and whatnot to come up with sensible values in an IMS2 specific context. There's no coding involved. There's config-file writing involved (aka "Modding") if you want to, but not neccessarily. In essence, you're a cross between a detective and an engineer, but then I sometimes wonder where exactly the difference between those two is anyways.
Testers:
We have two dedicated testers right now, which is a blessing I cannot overstate during a pre-alpha phase. Without them, this thing might be a little further along the road feature-wise, but with half those features broken. Right now, those two testers are doing a good job at keeping up with the one coder, so we don't have any immediate need for more, which does not mean that one or two more wouldn't be helpful.
In general, Testing means methodically breaking stuff, and rigorously documenting how you broke it. Sounds simple enough, but usually isn't.
A UI-designer (also known as interaction designer nowadays):
By which I don't mean visual design. Sure, somebody with a good sense for color scheems could do a bit of something, but the whole UI will be reskinable via config files once "The Great GUI-Refactoring" happens, a mystic future event foretold by the Prophets of neccessity. In other words, trying to fix the visuals of the UI at this point in time would be a waste of effort. No, what I'm talking about is somebody that is willing to get familiar with what IMS2 is trying to do, and spend some serious thought about how to best structure the UI so the user can do what needs to be done in an intuitive way without a hundred mouseclicks, so IMS2 doesn't end up with a convoluted and difficult to navigate menu structure like MS-Word in the mid 2000s.
Coding skills are not neccessary for this job. It's about defining how the UI should work, not making it work that way, although it would of course be considered a perk if you are able/willing to help with that. Somebody interested in the job should have done similar things before, even if only on paper.
Last edited: