New Release Interplanetary Modular Spacecraft RC9

[PeterRoss]

I got it working. As I thought, it's something about VS versions. I've installed VS 2008 Express and everything went fine (well, except of all these warnings). Resulting file is just the same size as original IMS.dll and is working fine. Sorry for the panic

 

[jedidia]

Well, I never doubted that it had to do with VS2010, I just wonder why... from what I've heard, you can use it to build for Orbiter 2010 P1. Maybe it needs some compatibility options set or somesuch.

 

[BruceJohnJennerLawso]

I've got a Bullet-style command module in Sketchup. You can tinker with it at will, especially to remove the interior, which is useless in IMS right now.

That would be great, but we'll need to get it into a useable format. Are you familiar with Babel3d?

No. It's simply against the laws of physics to transfer heat from the lower temperature to the higher. Might as well ask a river to flow uphills. And before you say "I can pump it", you can of course heat up your low temperature heat to higher temperatures, but you'll generate lots more heat in the process. It just doesn't work the convienient way.

No and no. The radiator area has to be sufficient. Additional area doesn't help, unless you're expecting the environment to get hotter.
Heatsinks might be helpful for short peak-loads, but they help nothing at allfor getting rid of constantly produced heat. The only purpose your radiators have to fulfill is being able to radiate the constantly produced heat while staying at a temperature lower than the coolant, because otherwise you can't pass any more heat to it. It's still a lot more helpfull than a heat sink, as it will slow down the heat buildup significantly, but in this case you're simply dealing with insufficient radiator area. Or you turned them into the sun. Bad Idea, that, at least for low temperature radiators.

Well, I wont pursue this much further, but I guess my point was that having an MCS to move heat seems pointless when everything eventually averages out.

If I remember correctly though, adding more radiator area will help up to a point, since it adds more mass. Temperature is really just Energy/Mass, so adding more mass will work to a point. That point would be reached when:

A-the radiators start bringing in more heat than they realistically can store for you

B-If the overall temperature of the rads is too low, they cant effectively radiate heat

Out of curiosity, whats the lowest temp that anyone has managed to get an IMS module down to? I think I managed something like 30K on a module in the shadow of audacity during construction.

The vessel's name is Aquarius, by the way

"Gasp" Ive been :ninja:!

I have a bad news for you. While I managed to load Aquarius_After.scn by changing it this way:

  CMODULE 4 34 [COLOR="Red"] -1,[/COLOR]  6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,24,25,26,27,28,29,30,31,32,33,34,35,36,37,39

this change is getting lost when saving. I.e. if you save you scenario (or just quit and launch (current state).scn) you will get CTD. I can't fix it manually, it's something about centrifuge once again. :dry:

Yeah, that Centrifuge module is just not wanting to cooperate. Im going to try and create an arm module that should allow us to directly attach ring segments onto the end. My suspicion is that attaching nodes onto centrifuges isnt a good idea.

I already said it futilly in SSU, I can only repeat it here and hope somebody reads it:

Warnings are bad. They are not ok. Warnings are symptoms of possible undetected bugs or bugs that will later manifest themselves.

You should ALWAYS treat warnings like errors during development. They are no showstopper and you get your binary, but they need your attention before release.

Yes, but its not 100% necessary to stamp them out of existence if you are sure they're benign. Data loss errors aren't going to grind an Orbiter module to a halt as much as a badly written piece of code that a compiler wouldn't even notice (something contradictory like a docking port with the same directional & rotational vectors maybe? :facepalm

That being said, in a module like IMS, any message out of the ordinary needs to be taken seriously at compile time because the code is so interlinked. I dont see major cause for concern yet though, since the only errors that were present in the IMS source were data loss & signed/unsigned mismatches, important but not critical

Alas, the result is pretty much the same. When loading an existing IMS scenario, CM module is being created as a dummy, and that's all.

Ill have to give it a try on my end.

Meanwhile, here's my first parts pack for IMS. I also included a pair of audio files to overwrite the docking radio sounds in a zip file in the sound directory. After the hundredth docking & integration on a vessel, Im just about ready to murder flight control for congratulating me :chainsaw:

View attachment Dauntless_Industries.zip

Im still using the "space company" format for the configs. If you want me to change that, please say so soon.

 

[MaverickSawyer]

That would be great, but we'll need to get it into a useable format. Are you familiar with Babel3d?

Yep, I have an account with at least one free run left. What format do you want it in? (I'll kick you the textures for the docking ports, too, but feel free to change those.)

 

[BruceJohnJennerLawso]

Yep, I have an account with at least one free run left. What format do you want it in? (I'll kick you the textures for the docking ports, too, but feel free to change those.)

I really dont have a preference, 3ds, obj, maybe anim8or (if it lets you). Cant wait to see wait you came up with :thumbup:.

 

[MaverickSawyer]

Cool. I'll go do that right now.

 

[jedidia]

Well, I wont pursue this much further, but I guess my point was that having an MCS to move heat seems pointless when everything eventually averages out.

It won't average out if you don't move the heat to the radiators... :shifty:

If I remember correctly though, adding more radiator area will help up to a point, since it adds more mass.

More mass is bad in rocket design

A-the radiators start bringing in more heat than they realistically can store for you

You don't want them to store it. You want them to radiate it. They can of course store some heat, but generally, the lighter you can make it, the better. How much energy it can store is a completely negligible factor for a radiator.

B-If the overall temperature of the rads is too low, they cant effectively radiate heat

And if they can't radiate it, they'll heat up until they can. The only thing you're interested in is that this temperature is lower than what you are trying to cool. If it's much lower, it means you have much more radiator area than you need. Worth thinking about taking some of, not adding some more.

 

[BruceJohnJennerLawso]

More mass is bad in rocket design

More Clowns is better

By the way, I have started work on the IMS docs. Im working my way through it on a paper copy, making notes & stuff. Im not going to change anything you wrote, except to restructure a few things grammatically, & Im hoping to add a few pointers & tips of my own. It wont be ready for a while yet though.

Do you like the parts? They obviously weren't too hard to make.

 

[Hlynkacg]

In regards to meshes. I have a bunch of generic 4.6m diameter space station modules that I created for an alternate history, Space Station Freedom/Columbia addon that I never got around to coding. I've also got a bunch of engine meshes both historical, and fictional that I've already provided to Jedia, as well as a whole crap-ton of random sketches/doodles for various projects that I never got around to.

Core module of 1968 Lunar space station proposal.

It sounds to me like you've got a lot of fat to trim so figure out a list of 20 or so bulding blocks that you want in the final release and I'll see what I can whip up.

based on your replies so far I'm imagining...

3 Command Modules:

• Small lunar lander/worker pod style cockpit.
• Larger "Bridge-style" cockpit for IPVs
• Space station "core" module

2-3 sizes of Radiators and Solar panel

• Small
• Medium?
• Large

Engines/Thrusters:

• Chemical, high thrust.
• Chemical, high impulse
• Solid Core NTR
• Gas/Liquid Core NTR
• Electrical/Exotic
• RCS Quad

Fuel Tanks:

• Spheres and Cylinders of assorted sizes

Truss/Structural Elements:

• Straight truss sections, long and short
• Thrust structure for mounting engines/clusters there of
• Assorted joints/connectors, "elbow", "T", "cross", etc...

Other Modules

• Generic cylindrical modules (assorted sizes)
• Airlock module
• Node/connector module
• Science/Sensor pallet module
• Antenna module
• Reactor/Power generation module

Does that sound about right?

If so I've got about 2/3rds of the required meshes sitting on my hard drive.

 

[BruceJohnJennerLawso]

In regards to meshes. I have a bunch of generic 4.6m diameter space station modules that I created for an alternate history, Space Station Freedom/Columbia addon that I never got around to coding. I've also got a bunch of engine meshes both historical, and fictional that I've already provided to Jedia, as well as a whole crap-ton of random sketches/doodles for various projects that I never got around to.

Core module of 1968 Lunar space station proposal.

It sounds to me like you've got a lot of fat to trim so figure out a list of 20 or so bulding blocks that you want in the final release and I'll see what I can whip up.

based on your replies so far I'm imagining...

3 Command Modules:

• Small lunar lander/worker pod style cockpit.
• Larger "Bridge-style" cockpit for IPVs
• Space station "core" module

2-3 sizes of Radiators and Solar panel

• Small
• Medium?
• Large

Engines/Thrusters:

• Chemical, high thrust.
• Chemical, high impulse
• Solid Core NTR
• Gas/Liquid Core NTR
• Electrical/Exotic
• RCS Quad

Fuel Tanks:

• Spheres and Cylinders of assorted sizes

Truss/Structural Elements:

• Straight truss sections, long and short
• Thrust structure for mounting engines/clusters there of
• Assorted joints/connectors, "elbow", "T", "cross", etc...

Other Modules

• Generic cylindrical modules (assorted sizes)
• Airlock module
• Node/connector module
• Science/Sensor pallet module
• Antenna module
• Reactor/Power generation module

Does that sound about right?

If so I've got about 2/3rds of the required meshes sitting on my hard drive.

Wow, that would make a huge difference in getting this project to an OHM release. Everything you mentioned sounds perfect, would you mind posting some more screenshots?

The station modules would really help as well. If we could request one other thing, could you make some inflatable ones? Something along the lines of the ISRU would be perfect.

 

[Hlynkacg]

Wow, that would make a huge difference in getting this project to an OHM release. Everything you mentioned sounds perfect, would you mind posting some more screenshots?

The station modules would really help as well. If we could request one other thing, could you make some inflatable ones? Something along the lines of the ISRU would be perfect.

A lot of 'em exist only as blender renders and need to be ported over to mesh format.

As for making inflatable modules,[ame="http://www.orbithangar.com/searchid.php?ID=5247"] brother please[/ame].

 

[PeterRoss]

Thank you for these amazing modules, Hlynkacg!

I have to remind you guys that we have strict limitations for animated modules though. Solars must have only two rotation axes per module for suntracking, while the one shown at Hlynkacg's picture has three of them - each solar wing has its own longitudal rotation axis.

Radiator should be an individual module and can't be part of anything else.

Animated part of an antenna module have to be able to freely rotate around two axes as well since we have no arresting mechanism which would prevent it from rotate through its own mesh. Jedidia found the way to make SSBB41 antenna rotate this way, I've made my own antenna some time ago, but I can't find it right now to show what I mean.

 

[Hlynkacg]

Any other specifics I should be aware of?

 

[PeterRoss]

Can't think of anything specific right now.
Well, there can't be such thing as RCS quad in IMS. It can be either single thruster or five-directional assembly. Thrust applying point is 0,0,0 only, as a result all the thrusters' working axes should pass through it. Axes of 5-dir assembly thrusters have to be perpendicular to each other. Engine modules aren't this strict.
Each module center of mass should lie at 0,0,0 point.

 

[BruceJohnJennerLawso]

Continuing building in IMS



Odyssey station, named after the venerable flagship of the Iron Hill Project, located at the EML4 point. The screenshot you see is of it in final development. I actually found a way to overload a 2.1 Megawatt MCS system :facepalm:

 

[PeterRoss]

Continuing building in IMS



Odyssey station, named after the venerable flagship of the Iron Hill Project, located at the EML4 point. The screenshot you see is of it in final development. I actually found a way to overload a 2.1 Megawatt MCS system :facepalm:

You like gravity wheels of non-standard configuration, don't you?:lol: I think I'll make some functional ring segments for you - or rather some adapters to fit standard modules into the wheel.

How did you managed to get a 2.1 MW MCS? I can see only two 350kW cooling modules.

---------- Post added at 16:49 ---------- Previous post was at 14:40 ----------

I made touchdown points to work. I've added these code blocks into IMSState:

Scenario read block:

else if (s.compare(0, 7, "TDPOINT") == 0) {
			VECTOR3 fwd, lft, rgt;	
			sscanf(s.substr(8).data(), "%lf,%lf,%lf %lf,%lf,%lf %lf,%lf,%lf", 
				&(fwd.x), &(fwd.y), &(fwd.z), 
				&(lft.x), &(lft.y), &(lft.z),
				&(rgt.x), &(rgt.y), &(rgt.z));
			SetTouchdownPoints(fwd, lft, rgt);
		}

Scenario write block:

		//Touchdown Points
		VECTOR3 fwd, lft, rgt;
		GetTouchdownPoints(fwd, lft, rgt); 
		
		ss.str("");
		RoundVector(fwd);
		ss << fwd.x << "," << fwd.y << "," << fwd.z << " ";
		RoundVector(lft);
		ss << lft.x << "," << lft.y << "," << lft.z << " ";
		RoundVector(rgt);
		ss << rgt.x << "," << rgt.y << "," << rgt.z;
		sprintf(buf, ss.str().data());

		sprintf(buf, ss.str().data());
		oapiWriteScenario_string(scn, "TDPOINT", buf);

Everything seems to work, you don't even have to create the string manually since it's being created with default numbers when you save a scenario.

Two things bothers me:
1) Where did these red and blue arrows poniting at APs and docking ports came from? I think it's something Jedidia added into code for debugging convenience and left it there. How do I get rid of them?
2) While Touchdown points are working, some large numbers (more than 7, for what I've seen) set for vertical axis produce weird results like vessel jumping into orbit. Why is it happens?

 

[jedidia]

It can be either single thruster or five-directional assembly.

As far as I remember, the number of thrusters is flexible, but anything appart from 90 degree angles is strongly discouraged.

1) Where did these red and blue arrows poniting at APs and docking ports came from? I think it's something Jedidia added into code for debugging convenience and left it there. How do I get rid of them?

Ooops. There's a line in there somewhere named SetAttachmentPointsVisible(true) or something along those lines. I think it's in the part of clbkPreStep that gets executed only before the first frame, but I'm not sure and can't check right now. It's only one line to comment out, that's for sure.

2) While Touchdown points are working, some large numbers (more than 7, for what I've seen) set for vertical axis produce weird results like vessel jumping into orbit. Why is it happens?

Certainly nothing to do with IMS. Orbiter does have the tendency to launch things out of the solar system because of numerical inputs that noone saw comming... :shifty:

How are the touchdown points working with the CoG shifting? any problems?

Now all you have to do is making a module parameter, and converting its position on integration.

 

[PeterRoss]

As far as I remember, the number of thrusters is flexible, but anything appart from 90 degree angles is strongly discouraged.

Oh, well then.

Ooops. There's a line in there somewhere named SetAttachmentPointsVisible(true) or something along those lines. I think it's in the part of clbkPreStep that gets executed only before the first frame, but I'm not sure and can't check right now. It's only one line to comment out, that's for sure.

oapiSetShowGrapplePoints

Gotcha!

Here's the resulting .dll, everybody feel free to test the new feature - touchdown points, which allows IMS vessels to land without sinking into ground:

View attachment IMS.zip

Just save your scenario and try to tweak the vessel's TDPOINT string parameters.

Certainly nothing to do with IMS. Orbiter does have the tendency to launch things out of the solar system because of numerical inputs that noone saw comming... :shifty:

Well, I'm not sure it's not connected with IMS because I've never seen such things before. See, when I save a scenario and change vertical axis numbers of TPs into anything less than 8 it starts landed when launching the scenario. If I make it 8 or more it appears as if it's landed on these TPs, but it starts to fall to the ground until the moment it touches the ground somewhere around the default TPs altitude (2 meters). At this point the vessel gets kicked up with a decent acceleration (not as big as the one that sends you into interstellar flight) and makes the vessel to jump around abit. It needs further testing since it was tried with a simple IMS vessel consisting of two modules only. I'll try to assemble a functional lunar lander and perform landing with it.

How are the touchdown points working with the CoG shifting? any problems?

Haven't checked it yet.

Now all you have to do is making a module parameter, and converting its position on integration.

It will require much more work, including all kinds of safeguards. For example, what will happen if user integrate four modules with assigned touchdown points? Or forty four? I'll eventually make it, but it will take time, oh it will take time.

 

[jedidia]

If I make it 8 or more it appears as if it's landed on these TPs, but it starts to fall to the ground until the moment it touches the ground somewhere around the default TPs altitude (2 meters).

Hmmm... might be that Orbiter gets confused because the vessel starts with the touchdown points below ground.

 

[PeterRoss]

How are the touchdown points working with the CoG shifting? any problems?

Now I see.:hmm:

You say, I can use the code fixing AP coordinates in respect of shifting COG?