New Release Interplanetary Modular Spacecraft RC9

[Dantassii]

Duplicates only appeared in DX9 under R2

I was able to make them go away by saving manually or using the [Current state]. I never tried the IMS quick saves under R2.3 on DX9, so the duplicates may have gone away under R2.3. So far the only issues I have with my station building activities is the URMS grapple on modules seems to slip quite a bit as I manipulate them around. I never saw that under DX9. I guess URMS is only 100% compatible with DX9 or higher. If the slippage gets out of hand, I just dock the module using the Scenario Editor. Graphics are also rather clunky under DX7... Guess I just was spoiled by the DX9 stuff.

I wonder.. after I push the 'finish' button on my station.. will I be able to load/play/run it under DX9?

Most of my C++ work was done in ASCII C++ with a little in non-ASCII HPUX C++. I did some programing in Borland C++ for Windows 3.1 back in the 80's but I haven't programed in C++ for Windows since then, mainly due to the DirectX issues previously stated.

 

[jedidia]

I wonder.. after I push the 'finish' button on my station.. will I be able to load/play/run it under DX9?

Unfortunately no, since the mesehs of the modules have to be rotated on loading, which of course uses the same function. As long as I don't write something that rotates the vertices, there's no client compatibility.

My biggest problem is I don't have any sort of software development tool on my home computer

That is simple to solve. Since none of us actually do software development for a living, we're all using the free visual studio express. Practically everyone developing for orbiter is using that.

I suspect my biggest problem (and it's not really a problem) is we live in widely spaced time zones. So if you post something and would like me to look at it, it may be 12+ hours before I even see it.

Also not really a problem... Development isn't fast enough anyways, to make that an issue. But I really have to set things up again on my computer... somehow I'm starting to itch to get started again. PeterRoss, what's the status on the finalisation bugs? If I remember right you fixed some of them for RC 2.3?

 

[PeterRoss]

But I really have to set things up again on my computer... somehow I'm starting to itch to get started again. PeterRoss, what's the status on the finalisation bugs? If I remember right you fixed some of them for RC 2.3?

FIXED:
Issue with consumables in finalised vessels not saving correctly;
Issue with propellant in finalised vessels not loading correctly
Issue with Docking Ports in wrong position when loading finalised vessels;
Issue with animated modules on finalised vessels duplicated;
Issue with module duplication when autosaving after integration.

ADDED:
Three more propellants (N2H4, HTP, NO2_C2H5OH);
Touchdown points support without user interface.

CHANGED:
SetCenterOfGravity();
All the saving and loading functions;
Propellant N2O2_N2H4 - into N2O4_N2H4.

NOT FIXED:
Symmetry check bug;
Composite module bug;
MCS overload when orbiting on LEO during time acceleration bug.

Link to 2.3 sources is in IMS development group. I tried to comment all the changes I made, but if you have some questions I'll try to answer. I'm not sure I'll remember everything I did there though.

I have a question. Don't you think it's better to start working on IMS 2 already instead of trying to fix what can't be fixed? Don't get me wrong, I'm absolutely loyal to IMS 1, but remembering all the fixes I've made I'm afraid I broke the modular structure of the code. I mean, my fixes were just simple patches aimed on making it work here and now and not on keeping the program architecture: for example, I inserted parts of SetCenterOfGravity() into loading and saving functions instead of making a call to the function because it would have taken too much changes in it, and all the other stuff. I'm afraid you will not be happy with my pieces of code and you'll have to invent another fixes to make the code better. And there are many other pieces of code which are not what they should to be, as you know. I'm afraid any further work on IMS 1 will be making patches over patches over patches. So, shouldn't we start from the beginning? But if you think it's better to continue working on IMS 1, I'll try my best to help you with it anyway.

 

[jedidia]

Don't you think it's better to start working on IMS 2 already instead of trying to fix what can't be fixed?

I'm not sure what can and cannot be fixed, really. But you seem to have taken care of the most glaring issues. I would absolutely love to immediately start ripping the whole thing appart and putting it back together again, so yes, I completely agree with you. I just wanted to make sure that we reach R1 first.

As I see it, I could probably leave the code as is and give client compatibility a shot, that shouldn't be too complicated and I'll need that function for 2.0 anyways. After that we can add in the docummentation and call it 1.0. I would like that approach best, I think.

but remembering all the fixes I've made I'm afraid I broke the modular structure of the code.

The code never had a modular structure to begin with (which is kind of ironic for an add-on for building modular spaceships). vchamp was pretty good at math, a lot better than I am really, but his structure was pure C-style, without classes, left alone inheritances. Every new module type that did something the others did not needed code added to the core, which is exactly what I'm going to change. As such, there's not much you could have broken... :shifty:
Considering the difficulty with touchdown points and center of gravity, they might need a special case any way you turn it. But other than that I hope to keep the code of every module type in its separate class, including the panel interface. I.E. every module type will be able to handle its own customized interface, allowing more convienient handling than the general interface we have currently.

 

[PeterRoss]

Considering the difficulty with touchdown points and center of gravity, they might need a special case any way you turn it. But other than that I hope to keep the code of every module type in its separate class, including the panel interface. I.E. every module type will be able to handle its own customized interface, allowing more convienient handling than the general interface we have currently.

I'm not sure I understand how it will be looking like, but I like the idea anyway :lol:

 

[Dantassii]

Some new issues and a new idea...

1) Is there a limit on the number of copies of a particular module I can have on a ship at once time? I have put 10 BT101's in my design, but the moment I try to add #11 and #12, save it, then try to reload it, I get a Orbiter crash and it refuses to run.

2) If there is a limit (say 10?), can I get around the limit by integrating a few of the earlier ones before I add more?

3) If there's not a limit, then does anyone have any clues why I can't add 12 BT101's to my design?

It will let me add and add and add w/out an error.. until I save it and try to reload it.. then BOOM no go... Luckily I make intermediate saves as I go, so I was able to figure out just where it saved and started crashing.
------------- Issue update ------------------------------
I integrated some of my BT101's into my ship and then successfully added #11 and #12 and was able to load the scenario after saving. So there does appear to be a limit on the number of copies of a module you can have un-integrated in your ship at one time. Something for the User's Manual?

------------ End Issues, Start Idea ----------------------
Idea #1) Is there any way that you could use a comm frequency assigned to a docking port as a flag that the port should not be removed? I know you folks were talking about how you could get rid of extra docking ports w/out getting rid of ones you want to keep. If a comm frequency is assigned to 1, even temporary, that could be a flag.

 

[jedidia]

The DOCKLIST scenario entry... we had problems with overly long docking list entries, but I can't remember which ones exactly. PeterRoss, do you perchance recall the problem? was it just spaces in the names, or did orbiter actually not parse the whole thing after a certain length?

Is there any way that you could use a comm frequency assigned to a docking port as a flag that the port should not be removed?

It's possible I guess, but I don't know if it's that much more convenient. The permanent docking ports are kept any way you turn it, and assigning a nav-frequency to all the construction ports you want to keep might be just as tedious...

 

[Dantassii]

Permanent docking ports

I guess I'm a little confused still. How do I designate a docking port as permanent? Is there a particular module I must add at a given port to note that it is permanent or do I need to 'do something' to the port to make it permanent?

 

[jedidia]

I guess I'm a little confused still. How do I designate a docking port as permanent?

You don't designate them, they are either separate modules, or part of a module.

In terms of realism, these are actual docking ports you can transfer personel and cargo through, while the others are just some flanges with a radio beacon that help you put stuff together.

In terms of IMS, "construction ports" are just there to give you a convienient way to put things together, they wouldn't actually be necessary for the program to work (indeed programing within the docking port/attachment point dualism turned out to be a frickin' nightmare...). They get deleted when a module is integrated, and they all get deleted on finalisation, to prevent the finished vessel from having 173 unusable docking ports clogging up the list.

Permanent ports, on the other hand, are final, they don't get deleted, and you cannot integrate modules over them (at least not if the config writer didn't screw up royally). They are the only prts through which you can transfer crew, consumables, power and heat. The others are just dumb position placeholders so you can dock stuff together with the scenario editor.

I expect this system to see some major change for 2.0, although I'm not sure yet how I'm going to solve the problem. But the instabilities that arise from docking and attaching vessels simultaniously is just too much of a liability to keep in place.

 

[Dantassii]

Ok. Next question then is how to I find the permanent docking ports? I have certain locations that I want to remain as docking ports once I finalize the design. Do I have to designate them by adding some sort of docking adapter at that point and if so, which modules do that?

 

[jedidia]

Do I have to designate them by adding some sort of docking adapter at that point and if so, which modules do that?

Yes, that's what the docking adapters in the native IMS modules are for. Any module can have a permanent docking port forced upon it if the module designer deems it fit (for example Greg Burch's airdocks have a default permanent port in place, since they're obviously meant to dock containers for convienient cargotransfer without having to suit up), but most modules don't come with one to keep flexibility high. Most people put a docking adapter right in front of their CM, but that is by no means a requirement. However, if your vessel has no permanent ports whatsoever, it cannot transfer anything.

 

[Dantassii]

Next question

Ok, so I put a pair of the BRCS2 RCS quads on either end of my spacecraft and then put 2 huge LH_LOX tanks to fuel them... but although I saw my 2 thrusters on the RCS screen and I could highlight them, there was no 'turn on' button, and I couldn't get any reaction from my spacecraft when I told it to rotate. I know it wasn't doing anything because my fuel load never went down.

Q1) What did I do wrong to turn on my RCS thrusters?
Q2) Is there some other step I'll need to do to turn on other thrusters? Main and Retro for instance?

 

[jedidia]

Q1) What did I do wrong to turn on my RCS thrusters?

Not sure... you're only supposed to click on them, and they should be good to go.

Wait... there's another condition. The transport seal must be broken, and the CM must be under power. If the CM is powered down, no flight controls whatsoever are available.

If those conditions are fulfilled, we have ourselves another problem...

 

[Dantassii]

Transport seal was broken and CM and everything else was under power.

I'm using the BRCS2 RCS system because my ship is already quite huge, is there a more powerful RCS module that I could use? I'll double check my fuel quantity, if I tell it to rotate to some distant orientation, I should be able to tell if the RCS is firing by watching the fuel load correct?

Q3) Do the RCS jets in IMS have thruster graphics that I should be able to see?

 

[jedidia]

Do the RCS jets in IMS have thruster graphics that I should be able to see?

Yes, you should be able to see them... No idea why they aren't working, but I'm getting set up again here, so I can run a test in the next days. Can you post the offending scenario?

Have you ever had this problem before?

 

[Dantassii]

This is the first time I've ever tried to build a ship using IMS and have gotten to the point where I can add the RCS. If I don't see any thruster graphics and my double check of the propellant levels doesn't go down then I'll upload a copy of the scenario.

------------- Another new idea ------------------------
Balute. As in the thing they used in the Movie 2010 to slow down at Jupiter. I imagine something that inflates to a certain size and several can be added together to form something large enough for a IMS ship to hide behind. When aerocapture is complete, they can be jettisoned.

I don't have any idea how to code this, but it would be kinda neat to have.

 

[jedidia]

The problem with that is that there's no aerodynamic or atmosphere modelling whatsoever, so it would be kinda pointless. Making just a module that looks like one woul be pretty simple, of course, but it won't add any functionality.

 

[PeterRoss]

The DOCKLIST scenario entry... we had problems with overly long docking list entries, but I can't remember which ones exactly. PeterRoss, do you perchance recall the problem? was it just spaces in the names, or did orbiter actually not parse the whole thing after a certain length?

Can't remember. There was certainly spaces-in-names problem with DOCKINFO scenario string, there was also an overflow of TEMPERATURES string which was initially limited to 256 characters. Can't remember if there was a DOCKINFO overflow, and Social Groups forum search isn't working very well. I guess it's worth to try to cause this overflow intentionally to see if it's the case.

 

[Dantassii]

Still would be a neat idea in my book. Might allow some of those "YAMS" to make it to Jupiter. BTW, the station I'm building needs RCS to keep the radiators in shade. Is there a sun-pointing auto-pilot that can be used to keep the 'nose' of a ship pointing at the sun, or turning towards the sun?

 

[jedidia]

Is there a sun-pointing auto-pilot that can be used to keep the 'nose' of a ship pointing at the sun, or turning towards the sun?

There's several attitude hold autopilots out there, but IMS' inbuilt absolute killrot usually works quite well for that purpose. Until you turn on non-spherical gravity, at least :shifty: