Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addons
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addons A repository for Orbiter addons contributed by users. Developers & members may announce new releases here and discuss any Orbiter addon.

Reply
 
Thread Tools
  #1  
Old
jedidia's Avatar
jedidia jedidia is online now
shoemaker without legs
Default IMS2 Alpha-1
by jedidia 01-07-2017, 07:39 PM

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 by jedidia; 01-08-2017 at 10:43 AM.
Reply With Quote
Views 4349 Comments 18
Total Comments 18

Comments

Old 01-08-2017, 12:19 AM   #2
MaverickSawyer
Acolyte of the Probe
 
MaverickSawyer's Avatar
Default

Okay, this might finally push me to refresh my Orbiter skills.
MaverickSawyer is offline   Reply With Quote
Thanked by:
Old 01-08-2017, 07:30 PM   #3
4throck
Enthusiast !
 
4throck's Avatar
Default

Great news. Will test it and give some feedback.
For now keep the SSBB4 models, they work well for development purposes.
4throck is offline   Reply With Quote
Thanked by:
Old 01-16-2017, 08:04 AM   #4
boogabooga
Bug Crusher
 
boogabooga's Avatar
Default

Will stack editor still work with this or will it be updated?

To me, S.E.is a vital part of the IMS experience.

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

http://www.orbiter-forum.com/showthr...postcount=1342
boogabooga is offline   Reply With Quote
Old 01-16-2017, 08:20 AM   #5
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
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.

Quote:
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.
jedidia is online now   Reply With Quote
Old 01-17-2017, 10:15 PM   #6
Raven
Orbinaut
 
Raven's Avatar
Default

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.
Raven is offline   Reply With Quote
Thanked by:
Old 01-17-2017, 10:56 PM   #7
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Thanks, you got pm!
jedidia is online now   Reply With Quote
Old 01-28-2017, 08:02 PM   #8
Dantassii
HUMONGOUS IMS shipbuilder
Default

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:


Ship docked with Mir space station:


Ship docked with ISS space station:


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
Dantassii is offline   Reply With Quote
Thanked by:
Old 01-28-2017, 08:21 PM   #9
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
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.
jedidia is online now   Reply With Quote
Thanked by:
Old 01-28-2017, 10:14 PM   #10
Dantassii
HUMONGOUS IMS shipbuilder
Default

Quote:
Originally Posted by jedidia View Post
 ..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
Dantassii is offline   Reply With Quote
Old 01-28-2017, 11:20 PM   #11
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
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.
jedidia is online now   Reply With Quote
Thanked by:
Old 02-05-2017, 10:41 AM   #12
crisbeta
Orbinaut
Default Fonts problem

Hello,

Have you any idea why the font looks like these?

I tried different resolutions, but I have same problem.

Thank you
Attached Thumbnails
IMS2_v20170205-1233.jpg  
crisbeta is offline   Reply With Quote
Old 02-05-2017, 03:25 PM   #13
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Huh... it does indeed look like a scaling problem. What resolutions did you try?
jedidia is online now   Reply With Quote
Old 02-05-2017, 04:33 PM   #14
crisbeta
Orbinaut
Default

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 by crisbeta; 02-05-2017 at 09:06 PM.
crisbeta is offline   Reply With Quote
Thanked by:
Old 02-05-2017, 06:24 PM   #15
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
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 by jedidia; 02-05-2017 at 06:27 PM.
jedidia is online now   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Addons > Addons


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 07:23 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.