New Release IMS2 Alpha-1

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
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:
  • 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.
Unfortunately, All kinds of actual onboard systems or crew simulation that made the original cool are not yet here. They will gradually be added during the Alpha-phase of the development. Somebody familiar with the original IMS will however notice that there are already quite a few features in that list that are not offered by ye olde, and this is pretty much the entire paradigm of IMS2 while it is developed: Offer the features of the old IMS, but without its limitations. You will see this trend continuing with
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:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Will stack editor still work with this or will it be updated?

The current version will work with some caveats, which are actually noted in the download page.
There is a dedicated version planned for IMS2, but it will still be quite some time until that point is reached. This is early alpha stage, after all.

Speaking of which, has the texture issue been worked out from last year?

Oh dear, completely forgot about that, and apparently so did Meson800. The issue has been worked out alright, but no patch has ever been released. I guess I should upload one. :shifty:
 

Raven

New member
Joined
Jul 4, 2011
Messages
46
Reaction score
0
Points
0
I'd like to contribute models and textures to the project. Since you're wanting lower-poly stuff I should be able to run those off relatively quickly. I can do normal, specular, and emissive maps too. If you can give me the basic concept for whichever modules you want, I can build from there.
 

Dantassii

HUMONGOUS IMS shipbuilder
Joined
Jul 14, 2012
Messages
508
Reaction score
20
Points
33
I took a few minutes this weekend to build up my first successful ship using IMS 2.0. :) I've built quite a few unsuccessful ships already, but this is the first time what I built actually did what I wanted it to do from the start. I can't wait to rebuild my Lunar Station (with its 2,775 individual modules) using IMS 2.0.

Here are some pictures:

Ship in LEO assembly orbit just after integration:
picture.php


Ship docked with Mir space station:
picture.php


Ship docked with ISS space station:
picture.php


I hope that someone gets around to porting the centrifuge modules from IMS to IMS2 sometime in the near future. Having several gravity wheels on my space stations and Solar System Transport Vehicles is a must.

Dantassii
HUMONGOUS IMS shipbuilder
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
I hope that someone gets around to porting the centrifuge modules from IMS to IMS2 sometime in the near future.

Well, just the modules would be trivial, but it will be some time until the functionality for centrifuges gets added. The composite system will be... interesting to code, to say the least.
 

Dantassii

HUMONGOUS IMS shipbuilder
Joined
Jul 14, 2012
Messages
508
Reaction score
20
Points
33
..The composite system will be... interesting to code, to say the least.

That's the spirit Jedidia. :) The biggest problem with the old multi-segment, build your own centrifuges was the off angle connections. They weren't at 90 degrees and that somehow confused the integrator into rotating them around each other as you try to integrate them.

I assume the IMS2 integration system won't have that problem...

Dantassii
HUMONGOUS IMS shipbuilder
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
They weren't at 90 degrees and that somehow confused the integrator into rotating them around each other as you try to integrate them.

There were several problems, some of them being general instability of the integration code, the other having to do with incremental inacuracies, especially where odd angles were involved. It tended to lead to unresolved connections, which made the centrifuge non-functional. I can't say for sure how this will work out for large contructions in IMS2, but the fact that you you can build partial segments is basically a safety net against all those issues. Most of the problems are avoided by default if you can assemble the moving parts by themselves.
 

crisbeta

Member
Joined
May 27, 2013
Messages
140
Reaction score
4
Points
18
Fonts problem

Hello,

Have you any idea why the font looks like these?

I tried different resolutions, but I have same problem.

Thank you :)
 

Attachments

  • IMS2_v20170205-1233.jpg
    IMS2_v20170205-1233.jpg
    43.8 KB · Views: 54

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Huh... it does indeed look like a scaling problem. What resolutions did you try?
 

crisbeta

Member
Joined
May 27, 2013
Messages
140
Reaction score
4
Points
18
I used dx9 client:
1280x720x32b
1600x900x32b

I checked now on default Orbiter client and it's ok. Looks like it's a problem with this font in dx9.
 
Last edited:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
I checked now on default Orbiter client an its ok. Looks like it's a problem with this font in dx9.

It's got nothing to do with the font. The font is just run-of-the-mill Arial at this point. It's a scaling issue. The panel is rendered at 1680x1050 natively (a 16:10 resolution). What orbiter then does is, it scales the panel to the window resolution. It looks like D3D9client has some issues with downscaling. While a certain loss has to be expected, the inline client seems to handle the operation much better than D3D9client.

I can reproduce the artifacts if I run IMS2 in a window with a resolution smaller than the native panel resolution in D3D9client. They vanish as soon as the resoultion equals, or goes above, 1680x1050.
They also vanish if I run them in a full-screen window at resolutions lower than that, though I'm not sure why. It certainly has something to do with the fact that the window then gets blown up to 1920x1080 again, but if there really was that much loss in the scale-down, it shouldn't look any better if the system blows it up again, suggesting that there are other factors in play too.

What's your native system resolution? If it's 1920x1080, you should see the issue disappear if you run in a full-screen window with a lower resolution.

If not, there's not much I can do about it at this point, I'm afraid. The GUI-refactoring is planned, and I might as well switch the whole thing to completely relative coordinates, allowing it to be drawn at the current orbiter resolution no matter what it might be. Since we're drawing the whole GUI dynamically and are not creating it from stored bitmaps anyways, that would probably be the best way to go. But I'm not quite there yet.
 
Last edited:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Crazy question: is there some way to render the UI using HTML+CSS.

There would be a way, but yes, it's crazy. Basically it would require an implementation of HTML/css on top of sketchpad, which comes with several caveats where sketchpad just isn't able to do all the thigs it would need to, and it would be much more complicated than we need it to be (not to mention really, really slow). The thought did cross my mind at some point, which is why I can immediately list off the problems. :lol:

Also, css is one of the worst GUI-toolkits I've ever worked with. As somebody once pointed out, "the problem with css is the cascading, and the sheets!" :p

Game UIs in general don't do dynamic responsiveness. They do at loadup to various degrees, and as mentioned, this is possible to implement in our GUI toolkit with some modifications that have to be made anyways. But the big difference here is that games (and IMS2 as well) pre-render their UI, because redrawing it is way too resource hungry when you need every bit you can get to run the realtime 3d stuff. If IMS2 would be using sketchpad to draw the UI dynamically instead of just to render bitmaps once and then blitting them, the loss in framerate would be in the double digits when there's lots of redraws going on.
 

crisbeta

Member
Joined
May 27, 2013
Messages
140
Reaction score
4
Points
18
For now only a small bug: I lost all the fuel when splitting a vessel (disassemble).

I tested launches from Earth for small subobital stages and 2 stage suborbital (2 IMS2 vessels docked). I had some problems setting docked vessel on the launch pad without flipping out on one side, but this shouldn't be a concern for now because Orbiter 2016 patch will contain some modifications for landed vessels.

Also a vessels with landing gear deployed seems to be more unstable than with landing gear retracted (not a concern for now; see above).

IMS2-alpha is very stable (more stable that IMS-RC9). I like the way you implemented IMS2; this is a more general approach than IMS1 (module, properties, functions), wich opens the code to almost everything.

Very nice job:thumbup: I hope you will find time to continue with this wonderful add-on. :tiphat:
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
For now only a small bug: I lost all the fuel when splitting a vessel (disassemble).

Whoops, will have a look at that.

I tested launches from Earth for small subobital stages and 2 stage suborbital (2 IMS2 vessels docked).

Interesting experiment. Not exactly what IMS2 is built for. We have zero aerodynamics, and not really any planed.

Orbiter 2016 patch will contain some modifications for landed vessels.

It will? You seem to know more than I do :lol:

Also a vessels with landing gear deployed seems to be more unstable than with landing gear retracted (not a concern for now; see above).

Define unstable, please. Unstable as in "doesn't stand right on the pad", or "crashes more often"?

IMS2-alpha is very stable (more stable that IMS-RC9). I like the way you implemented IMS2; this is a more general approach than IMS1 (module, properties, functions), wich opens the code to almost everything.

Yeah, that was pretty much the plan. Just wait until you'll be able to build subsystems into modules during runtime :p
Thanks for the nice words!

I hope you will find time to continue with this wonderful add-on.

Finding time right now, as a matter of fact. :)
 

Dantassii

HUMONGOUS IMS shipbuilder
Joined
Jul 14, 2012
Messages
508
Reaction score
20
Points
33
Update on Tester Dantassii

Last summer (2018) my Windows 7 computer suffered a video card crash due to a game (Space Engineers) overloading the video card when the video card drivers got updated. It appears that some of the periferal chips got MELTED due to an incompatibility between the video drivers and the game.

Anyway, I purchased a brand new Windows 10 computer, and have just this summer (2019) finally got around to installing the Release version of Orbiter 2016 w/Dx9.

New computer:
AMD Threadripper, 32 core CPU w/liquid H2O cooling
32 Gb RAM
GForce 1080Ti video card with 11Gb of vRAM
2 monitors (22" and 23" wide screens)
SSD primary drive
7200 RPM secondary drive

In other words, this is a BEAST!

Running Orbiter 2016 w/Dx7 took my video card to 75-90% usage according to Taskmanager. When I ran Dx9, the video usage went to 25% or less. CPU usage looks like it maxes out at 3 cores (out of 32). And memory usage is not even registering.

In the near future I plan on downloading IMS2-Alpha-1 (plus it dependencies) and see if I can get it to work.

Any other news in the 2 years since there was a post on this thread?

Dantassii
HUMONGOUS IMS shipbuilder (who is just itching to see how BIG an IMS ship he can build on this new computer)
 
Top