New Release Interplanetary Modular Spacecraft RC9

[BruceJohnJennerLawso]

Finalised vessels use other loading schemes than vessels in construction. They're loaded from two separate files, after all...

Aha, so were we swatting some bugs in there? Finalization was giving me some really weird bugs on occasion, like docking ports offset 50m from where they were supposed to be.

 

[jedidia]

Yes, most of the currently existing bugs seem to have to do with finalisation. Pretty much all for which I suggested a fix had to do with it. I wasn't aware of the module duplication thing, looks like that would be the last big fly in the soup when the other stuff is fixed.

 

[PeterRoss]

Only Issue 1 and Issue 3 was solved this easily. Issue 2 is fixed too. Its cause was not missing brackets but the propellant mass vector push-up being called twice: first in LoadFromConfig and second in LoadLightState. It resulted in saving full tank value first and loaded tank value second, and it was the first one used in PostCreation to set propellant level. Commenting out the string from LoadFromConfig seems like fixed the problem.

Issue 4 and module duplication issue is on schedule.

Here are two Lunar Landers: one is assembled from modules and second is respawned from config file. You can see docking ports aren't shifted:

 

[BruceJohnJennerLawso]

Only Issue 1 and Issue 3 was solved this easily. Issue 2 is fixed too. Its cause was not missing brackets but the propellant mass vector push-up being called twice: first in LoadFromConfig and second in LoadLightState. It resulted in saving full tank value first and loaded tank value second, and it was the first one used in PostCreation to set propellant level. Commenting out the string from LoadFromConfig seems like fixed the problem.

Issue 4 and module duplication issue is on schedule.

Here are two Lunar Landers: one is assembled from modules and second is respawned from config file. You can see docking ports aren't shifted:

Excellent, once those bugs are cleared out IMS should be much more stable across the board. I eagerly await that source code.

Hmmm, update: page 33/144 now, wrote my first useful program, as youve probably seen already. Not exactly heart stopping, but its nice to actually do something with all that work.

Anyways, I may also have a bit of a mea culpa to do. I was working on a project last night with a lot of glitches & frustration, when it dawned on me that IMS stability seemed to have gone downhill right about when I created my new config structure. During construction I end up needing to save almost constantly to avoid misplaced parts & crashes around integration time. My guess is that sometimes long config location names are running over what IMS can realistically handle. For example when IMS RC2 configs are being used, the name written to scenario file would be:

IMS/partname.cfg

but the new structure expanded it to

IMS/CompanyName/PartType/partname.cfg

A lot longer! So anyways, over the next few days Im going to reconfigure everything to PeterRosses original idea of just grouping part types under separate folders in the IMS configs, which should shorten that CFG line & reduce errors. If that does seem to be the case, Ill make sure to reorganize the config pack I created into the simpler system, which we can incorporate into RC3. I still think some company distinctiveness would be nice, but we can probably just include different logos in the preview pictures for that.

Speaking of RC3, seeing that we now have several bugs picked out, and the documentation underway, how would you feel about finally putting out an Orbithangar release for RC3? I think the project is good enough for it, and OHM would allow us to distribute much more easily to a wider audience than we can in an OF thread

 

[jedidia]

My guess is that sometimes long config location names are running over what IMS can realistically handle.
So anyways, over the next few days Im going to reconfigure everything to PeterRosses original idea of just grouping part types under separate folders in the IMS configs

Hold that! I just punched up the code and saw that the config file name for modules is currently allocated at 100 characters, which might indeed be the problem, but is easy to fix.

PeterRoss, while you're at it, please extend this to something more forgiving, like 500 or so. Once past loadstate, the name is noted in an std::string, which has dynamic allocation, so no problem there.

The line is (was, anyways) in clbkloadstate under "MODULE", IMSstate.cpp, line 398, and again in LoadVesselFromConfig, same file, line 864:

		else if (s.compare(0, 6, "MODULE") == 0) 
		{
			[COLOR="Red"]char configFileName[100];[/COLOR]
			VECTOR3 pos, dir, rot;
			int mactive = 0;
			sscanf(s.substr(7).data(), "%s %lf,%lf,%lf %lf,%lf,%lf %lf,%lf,%lf %d", 
				configFileName, 
				&(pos.x), &(pos.y), &(pos.z), 
				&(dir.x), &(dir.y), &(dir.z),
				&(rot.x), &(rot.y), &(rot.z), &(mactive));
			AddModule(GetModuleConfig(configFileName), pos, dir, rot, pos, mactive);
			RestoreModule(modules.size()-1, false, true);
		}

(the lines probably won't be accurate anymore, but should get you in the close vicinity)

One thing to check though, Bruce: Make sure your directories don't have any spaces in their names (nor your filenames). I don't know how many times we stumbled over those spaces already, so it might be a good Idea to double check.

Speaking of RC3, seeing that we now have several bugs picked out, and the documentation underway, how would you feel about finally putting out an Orbithangar release for RC3?

I would throw it on the Hangar when it reaches R1 (was the original intent, anyways). As for when that is reached, I'll leave that to you guys. I'd say documentation finished and currently known bugs fixed, and you're good to go. I's suggest to make an RC3, test it, and if there's nothing comming up, release it as soon as the documentation is in (before finalising the documentation, give me a call... I have to put in the proper credits for the used meshes, and the rest of the work. Actually, I'll just write it up one of these days and you can add it).

Its cause was not missing brackets but the propellant mass vector push-up being called twice: first in LoadFromConfig and second in LoadLightState. It resulted in saving full tank value first and loaded tank value second, and it was the first one used in PostCreation to set propellant level. Commenting out the string from LoadFromConfig seems like fixed the problem.

Good Job! But then you've always been very persistent at hunting down bugs, it can only be an advantage for you to have the code and actually see what's going on. :lol:

---------- Post added at 06:38 PM ---------- Previous post was at 06:21 PM ----------

Acctually, for fixing the config line problem once and for all, Just change the offending line to

char configFileName[s.length()];

This way the filename will always be guaranteed to fit, no matter how long. It's a bit more memory than necessary, but the variable won't exist for more than a few lines anyways.

 

[BruceJohnJennerLawso]

Hold that! I just punched up the code and saw that the config file name for modules is currently allocated at 100 characters, which might indeed be the problem, but is easy to fix.

PeterRoss, while you're at it, please extend this to something more forgiving, like 500 or so. Once past loadstate, the name is noted in an std::string, which has dynamic allocation, so no problem there.

The line is (was, anyways) in clbkloadstate under "MODULE", IMSstate.cpp, line 398, and again in LoadVesselFromConfig, same file, line 864:

		else if (s.compare(0, 6, "MODULE") == 0) 
		{
			[COLOR="Red"]char configFileName[100];[/COLOR]
			VECTOR3 pos, dir, rot;
			int mactive = 0;
			sscanf(s.substr(7).data(), "%s %lf,%lf,%lf %lf,%lf,%lf %lf,%lf,%lf %d", 
				configFileName, 
				&(pos.x), &(pos.y), &(pos.z), 
				&(dir.x), &(dir.y), &(dir.z),
				&(rot.x), &(rot.y), &(rot.z), &(mactive));
			AddModule(GetModuleConfig(configFileName), pos, dir, rot, pos, mactive);
			RestoreModule(modules.size()-1, false, true);
		}

(the lines probably won't be accurate anymore, but should get you in the close vicinity)



---------- Post added at 06:38 PM ---------- Previous post was at 06:21 PM ----------

Acctually, for fixing the config line problem once and for all, Just change the offending line to

char configFileName[s.length()];

This way the filename will always be guaranteed to fit, no matter how long. It's a bit more memory than necessary, but the variable won't exist for more than a few lines anyways.

Hmmm, thats good news & bad. We should implement that change just for the sake of redundancy, but the problem might lie elsewhere. If you check the config structure that I posted, you'll probably notice that the configs are all pretty much under 50 characters. If the limit had been set at 30, that probably could have been the problem, but I dont think any were past 100. Is it possible that a long config string can somehow "push" other module values out at integration, like when a modules mesh moves after being integrated?

In any case, I think PeterRosses original complaints about company structuring may have been well founded. I vote we simply subdivide the parts into part type folders & leave it at that. If you're okay with that Jedidia, we can just make that the standard from now on.

One thing to check though, Bruce: Make sure your directories don't have any spaces in their names (nor your filenames). I don't know how many times we stumbled over those spaces already, so it might be a good Idea to double check.

Yep, I made sure to do that from the start just to be safe. I didnt know I had to do it, but it seemed likely enough that I did it anyways.

I would throw it on the Hangar when it reaches R1 (was the original intent, anyways). As for when that is reached, I'll leave that to you guys. I'd say documentation finished and currently known bugs fixed, and you're good to go. I's suggest to make an RC3, test it, and if there's nothing comming up, release it as soon as the documentation is in (before finalising the documentation, give me a call... I have to put in the proper credits for the used meshes, and the rest of the work. Actually, I'll just write it up one of these days and you can add it).

Good, I have a document that should be perfect for that already written up. I also may have finally hit upon the right idea for the logo, more on that later.

Im glad you agree on that, Ive felt that IMS would benefit greatly from an Orbithangar release, but the time spent on the OF thread was well worth it. If we released this in its RC1 state on Orbithangar, the reaction might have been a bit negative, so easing IMS out into the world really paid off.

The one thing I would request though, would be that either you or Peterross do the honors of uploading the add-on. It wouldnt be right for me to put it up with mine, you guys have really been the heart & sould of the project from day one. :thumbup:

 

[jedidia]

Is it possible that a long config string can somehow "push" other module values out at integration

Orbiter supports scenario lines of arbitrary length, so no, that isn't possible. The only thing that is possible is that a path over hundred characters long overflowed the array.

like when a modules mesh moves after being integrated?

Wait, what? You absolutely, totally can't move config files after integration, the old vessel will not find them anymore (the path gets noted in the scenario file, after all).

You can move meshes, as the path of the mesh is part of the config file, so if you change it there, Orbiter will find it if IMS finds the config file. Move a config file, and you break all backward compatibility for vessels using that module. Move a mesh without noting the change of path in the config file, and you pretty much broke the module for good.

 

[PeterRoss]

In any case, I think PeterRosses original complaints about company structuring may have been well founded. I vote we simply subdivide the parts into part type folders & leave it at that. If you're okay with that Jedidia, we can just make that the standard from now on.

Is it because you're afraid of too long filenames or you actually think it's easier to use this way? Because I've just got used to Set\Function\Part.cfg structure and I don't think it's that inconvenient anymore.

The one thing I would request though, would be that either you or Peterross do the honors of uploading the add-on. It wouldnt be right for me to put it up with mine, you guys have really been the heart & sould of the project from day one. :thumbup:

It's up to Jedidia entirely. And the thing isn't release-ready anyway.

Wait, what? You absolutely, totally can't move config files after integration, the old vessel will not find them anymore (the path gets noted in the scenario file, after all).

No, I believe he meant moving of data blocks by IMS core and not moving of config files.

---------- Post added at 23:58 ---------- Previous post was at 22:59 ----------

Issue 4 is solved by a brute force. There was no animation initialisation in LoadLightState() too except of AddRadiator(), AddSolarPanel() and AddComArray() duplication. Maybe there's sense to optimise LoadVesselFromConfig() and LoadLightState() - maybe even merge them together to be one function since we now have spawned/loaded check anyway.

 

[BruceJohnJennerLawso]

Orbiter supports scenario lines of arbitrary length, so no, that isn't possible. The only thing that is possible is that a path over hundred characters long overflowed the array.

Yes, but if you look at the configs that I posted, none of the total string lengths seem to even come close to that. Thats why Im not convinced that that was the root of the problem, although I still suspect the issues that Ive experienced are related to this.

Wait, what? You absolutely, totally can't move config files after integration, the old vessel will not find them anymore (the path gets noted in the scenario file, after all).

You can move meshes, as the path of the mesh is part of the config file, so if you change it there, Orbiter will find it if IMS finds the config file. Move a config file, and you break all backward compatibility for vessels using that module. Move a mesh without noting the change of path in the config file, and you pretty much broke the module for good.

Umm, I never moved configs after integration, so Im not really sure what youre talking about. Small miscommunication

Is it because you're afraid of too long filenames or you actually think it's easier to use this way? Because I've just got used to Set\Function\Part.cfg structure and I don't think it's that inconvenient anymore.

:lol:, you want me to say it don't you? Well heres what I know;

The longer configs require more memory, and thus decrease performance. The config structure with company names is good for the most part, but your previous comments about an extra branch proved somewhat true. SSBB 4.1 and the stock IMS parts a generally quite similar, so separating them really was somewhat pointless. Having NASA or ESA parts in company folders seemed strange as well. The other issue I found was that part sets with only one config (like the MIPTS CM) look out of place in the list, especially when compared to a full set like SSBB 4.1.

So anyways, it seems to me that it would be easier for us all to be in agreement on this. My suggestion is:

-organize part types under IMS/part type, and have each config preview picture contain a logo for the company name. This will work especially nice for NASA, Roscosmos, ESA, JAXA stuff, etc.
-For specific ships that use IMS as their base like a IMS Enterprise or a Space Shuttle, or whatever, require authors to place all parts under IMS/custom_vessels/EnterpriseParts. Since most of these will be using specific parts with specific attachment ids, it will be best to keep them away from the "build as you like" parts.

I hate to upend our little IMS world again, but I think this would be a good strategy to stick to from here on out. Company folders was a neat idea, but not really all that useful.

It's up to Jedidia entirely. And the thing isn't release-ready anyway.

What do you feel we need to accomplish in order to be release ready? I should be able to get most of the documentation done fairly soon, so is it a content issue or a stability one?

---------- Post added at 14:58 ---------- Previous post was at 14:13 ----------

Okay, I think I finally got it, heres IMS logo v3



Simple, clean, & easy to fit in anywhere you like (especially on top of an IMS screenshot). I made it using part of the IMS page headers in the documentation now in progress.

Also dug up a few nuggets for the docs, including the Blues Brothers joke. This one should be fun to use as well

 

[jedidia]

Maybe there's sense to optimise LoadVesselFromConfig() and LoadLightState() - maybe even merge them together to be one function since we now have spawned/loaded check anyway.

It's usually better to have two separate functions if you read from two separate files, just for clarity, but some optimisation never hurts...

Okay, I think I finally got it, heres IMS logo v3

Yeah, that works. The aspect ratio will look somewhat weird in scenario editor, though...

 

[MaverickSawyer]

Stack the module beneath the text.

OK, now that I know what the size of the XR3's payload bay is, I'm starting to make some rough concepts for what kinds of IMS modules would fit into the central slot for modules: 3.6m diameter, 10m long.
Sadly, since I have only the free version of Sketchup, I can't kick them out in a format that I can convert to mesh format. However, I'll gladly let you guys take a stab at converting them if you want. Keep in mind, they're still just wireframes right now to help me figure out the maximum dimensions.

 

[Athena]

Question...what does red radiators mean in the cooling screen? and the ones with a blue square around them?

 

[MaverickSawyer]

Red radiators means that they're overloaded, if I'm remembering things correctly. Blue squares means that the module you've selected in the scroll menu to the right of the graphic display is connected to that radiator.

 

[BruceJohnJennerLawso]

Yeah, that works. The aspect ratio will look somewhat weird in scenario editor, though...

Great! Where would it need to be used in the scenario editor?

Stack the module beneath the text.

I can, but I feel that part of the logos appeal is in the left to right linearity, having a very clean, direct look. Ill have to experiment with other sizes of it then.

OK, now that I know what the size of the XR3's payload bay is, I'm starting to make some rough concepts for what kinds of IMS modules would fit into the central slot for modules: 3.6m diameter, 10m long.
Sadly, since I have only the free version of Sketchup, I can't kick them out in a format that I can convert to mesh format. However, I'll gladly let you guys take a stab at converting them if you want. Keep in mind, they're still just wireframes right now to help me figure out the maximum dimensions.

You know, the Babel3d account will run out eventually, wouldnt it just be better to switch to real modelling software? If youre willing to try, I can guide you through the transition to Anim8or. Its actually not that hard to use, and it does have references so that you can build properly to scale. PM me if youre interested

Red radiators means that they're overloaded, if I'm remembering things correctly. Blue squares means that the module you've selected in the scroll menu to the right of the graphic display is connected to that radiator.

Yep, and once thats happening, the only thing to do is either, reconfigure your cooling systems to be more efficient, or add more radiator area. Make sure you have the right radiator type too




A quibble with the IMS design guide:

In the thermodynamics section, it seems to state that all power used by a module eventually becomes heat. This is generally true, but I dont think its universally true, since some of the power used by a module will actually go to the task that it was doing. If an electric motor is used to "spin up" a momentum wheel, some energy is lost as heat, but some also ends up in the rotational kinetic energy of the wheel. Its a small point, but I would like to correct this just to be accurate. My assumption would be that IMS treats it like this, because its an accurate approximation in this case.

 

[jedidia]

You know, the Babel3d account will run out eventually, wouldnt it just be better to switch to real modelling software? If youre willing to try, I can guide you through the transition to Anim8or.

Guys, please, if you don't want to pay any money, there's always Blender or Gmax. Since we're already talking about "real" modelling software...

Question...what does red radiators mean in the cooling screen?

"overloaded" is a bit of an unacurate description. You can't exactly overload a radiator unless you melt it to slack (which is not possible in IMS, it just shuts down the heat exchangers before that happens...).
Red simply means that there is one or more modules who's optimal temparature is lower than the radiators current working temparature. I.E. as long as the radiator shows up in red on the display, it is physically impossible for these modules to keep their nominal temparature. Usually solved by shutting down some connected modules, optimizing your connection scheme, turning the vessel out of the sun or screwing on more radiators.

In the thermodynamics section, it seems to state that all power used by a module eventually becomes heat. This is generally true, but I dont think its universally true, since some of the power used by a module will actually go to the task that it was doing.

And where does it go from there? You're exactly missing the point. ANY AND ALL Energy will EVENTUALLY turn to heat. Period.

In a spaceship, this "eventually" does not tend to be an overly long cycle. To take your example: It might take a bit longer, because it'll only be released when you break that momentum wheel down again, or it will happen very gradually over time as the wheel slows down from unavoidable friction.
Anyways, this is mechanic stuff we're talking about... If you take electronics, you have the transformation practically instantaneous, because they don't do any mechanical work. If you think about it, converting electricity to heat is what drives a computer.

Where would it need to be used in the scenario editor?

Uhm, good question actually. Not sure what I was thinking.

 

[Furet]

Sorry to be a pain, but I just can't figure out what happens with the scenarios hereafter (sorry if it's an already documented issue). I've made some prototypes in order to test various tanks arrangement for my vessel.

The first one is working all right and when thrust is applied it goes straight ahead.

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56331.8421978598
END_ENVIRONMENT

BEGIN_FOCUS
  Ship CDLS-1
END_FOCUS

BEGIN_CAMERA
  TARGET CDLS-1
  MODE Cockpit
  FOV 40.19
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
CDLS-1:IMS\SBB41B\BG203_CONTROL_AI_SContainer
  STATUS Orbiting Earth
  RPOS 863893.70 -165.64 6954311.05
  RVEL -7484.405 -0.036 929.334
  AROT 0.00 -0.00 90.00
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000 2:1.000000 3:1.000000
  NAVFREQ 0 0
  COMMAND 1 0
  MODULE SBB41B\BT201_Truss_to_Module_Adapter 0,-2.3884,-1.0599 1,0,0 0,0,1 0
  MODULE SBB41B\BG201_Battery_SContainer 0,-4.7768,0 0,0,1 0,-1,0 0
  MODULE SBB41B\BNTR_GasCore_ClosedCycle_Nuclear_Engine 0,-2.3884,-10.1833 0,0,1 -1,0,0 0
  MODULE SBB41B\BT101_Truss 0,-2.3884,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,0.9409,6.166 0,0,-1 0,-1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,-5.7177,6.166 0,0,-1 0,1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 3.3293,-2.3884,6.166 0,0,-1 -1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -3.3293,-2.3884,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BT101_Truss 0,-2.3884,16.3181 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,0.9409,16.3181 0,0,-1 0,-1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,-5.7177,16.3181 0,0,-1 0,1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 3.3293,-2.3884,16.3181 0,0,-1 -1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -3.3293,-2.3884,16.3181 0,0,-1 1,0,0 0
  TDPOINT 0,0,0 0,0,0 0,0,0
  DELETEPOINT 2
  ATTPOINT IM 5,-2.3884,0 1,0,0 0,0,1
  ATTPOINT IM -5,-2.3884,0 -1,0,0 0,0,1
  ATTPOINT IM 0,-6.0452,0 0,-1,0 0,0,1
  ATTPOINT IM 2.2405,0.9409,6.166 1,0,0 0,0,-1
  ATTPOINT IM -2.2405,0.9409,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 0,3.1814,6.166 0,1,0 0,0,-1
  ATTPOINT IM -2.2405,-5.7177,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 2.2405,-5.7177,6.166 1,0,0 0,0,-1
  ATTPOINT IM 0,-7.9582,6.166 0,-1,0 0,0,-1
  ATTPOINT IM 3.3293,-4.6289,6.166 0,-1,0 0,0,-1
  ATTPOINT IM 3.3293,-0.1479,6.166 0,1,0 0,0,-1
  ATTPOINT IM 5.5698,-2.3884,6.166 1,0,0 0,0,-1
  ATTPOINT IM -3.3293,-0.1479,6.166 0,1,0 0,0,-1
  ATTPOINT IM -3.3293,-4.6289,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -5.5698,-2.3884,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 0,-2.3884,21.3942 0,0,1 0,1,0
  ATTPOINT IM 2.2405,0.9409,16.3181 1,0,0 0,0,-1
  ATTPOINT IM -2.2405,0.9409,16.3181 -1,0,0 0,0,-1
  ATTPOINT IM 0,3.1814,16.3181 0,1,0 0,0,-1
  ATTPOINT IM -2.2405,-5.7177,16.3181 -1,0,0 0,0,-1
  ATTPOINT IM 2.2405,-5.7177,16.3181 1,0,0 0,0,-1
  ATTPOINT IM 0,-7.9582,16.3181 0,-1,0 0,0,-1
  ATTPOINT IM 3.3293,-4.6289,16.3181 0,-1,0 0,0,-1
  ATTPOINT IM 3.3293,-0.1479,16.3181 0,1,0 0,0,-1
  ATTPOINT IM 5.5698,-2.3884,16.3181 1,0,0 0,0,-1
  ATTPOINT IM -3.3293,-0.1479,16.3181 0,1,0 0,0,-1
  ATTPOINT IM -3.3293,-4.6289,16.3181 0,-1,0 0,0,-1
  ATTPOINT IM -5.5698,-2.3884,16.3181 -1,0,0 0,0,-1
  DELETEPORT 1
  CONSTRUCTIONPORT 5,-2.3884,0 1,0,0 0,0,1
  CONSTRUCTIONPORT -5,-2.3884,0 -1,0,0 0,0,1
  CONSTRUCTIONPORT 0,-6.0452,0 0,-1,0 0,0,1
  CONSTRUCTIONPORT 2.2405,0.9409,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -2.2405,0.9409,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,3.1814,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT -2.2405,-5.7177,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 2.2405,-5.7177,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,-7.9582,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 3.3293,-4.6289,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 3.3293,-0.1479,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 5.5698,-2.3884,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -3.3293,-0.1479,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT -3.3293,-4.6289,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -5.5698,-2.3884,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,-2.3884,21.3942 0,0,1 0,1,0
  CONSTRUCTIONPORT 2.2405,0.9409,16.3181 1,0,0 0,0,-1
  CONSTRUCTIONPORT -2.2405,0.9409,16.3181 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,3.1814,16.3181 0,1,0 0,0,-1
  CONSTRUCTIONPORT -2.2405,-5.7177,16.3181 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 2.2405,-5.7177,16.3181 1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,-7.9582,16.3181 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 3.3293,-4.6289,16.3181 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 3.3293,-0.1479,16.3181 0,1,0 0,0,-1
  CONSTRUCTIONPORT 5.5698,-2.3884,16.3181 1,0,0 0,0,-1
  CONSTRUCTIONPORT -3.3293,-0.1479,16.3181 0,1,0 0,0,-1
  CONSTRUCTIONPORT -3.3293,-4.6289,16.3181 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -5.5698,-2.3884,16.3181 -1,0,0 0,0,-1
  EMPTYMASS 71000.000000
  MASSCENTER 0.000000 -2.388400 2.581339
  PMI 101.000000 105.200000 27.320000
  PROP LH2 75936 75936
  ENGINE 2 0 0
  CONSUMABLES 0.0001 0.0001 0 0.0001 0.0001 0 0.0001 0.0001 0
  TEMPERATURES -1:298.07:243.09 1:298.00:266.55 2:1298.76:403.54
  HEATING no
  THGROUPLEVELS 0 0 0 0 
  CREW 0 0
  ENERGY 395854196.507321
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 1 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 1 0 1 0 0 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 1 0 1 0 0 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
END
END_SHIPS

BEGIN_ExtMFD
END

The two other ones, although looking perfectly symmetrical, are pitching down as soon as thrust is engaged. It behaves like if the CoG is off the centerline.

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56331.8827168695
END_ENVIRONMENT

BEGIN_FOCUS
  Ship CDLS-I
END_FOCUS

BEGIN_CAMERA
  TARGET CDLS-I
  MODE Cockpit
  FOV 40.19
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
CDLS-I:IMS\SBB41B\BG203_CONTROL_AI_SContainer
  STATUS Orbiting Earth
  RPOS 3376150.71 133.88 -6141250.18
  RVEL 6608.900 0.067 3632.843
  AROT -0.08 0.01 90.00
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000 2:1.000000 3:1.000000
  NAVFREQ 0 0
  COMMAND 1 0
  MODULE SBB41B\BT201_Truss_to_Module_Adapter 0,-2.3884,-1.0599 1,0,0 0,0,1 0
  MODULE SBB41B\BG201_Battery_SContainer 0,-4.7768,0 0,0,1 0,-1,0 0
  MODULE SBB41B\BNTR_GasCore_ClosedCycle_Nuclear_Engine 0,-2.3884,-10.1833 0,0,1 -1,0,0 0
  MODULE SBB41B\BT101_Truss 0,-2.3884,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 3.3293,-2.3884,6.166 0,0,-1 -1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -3.3293,-2.3884,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 3.3293,-6.8694,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 3.3293,2.0927,6.166 0,0,-1 -1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 7.8103,-2.3884,6.166 0,0,-1 -1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -3.3293,2.0926,6.166 0,0,-1 -1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -3.3293,-6.8695,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -7.8103,-2.3884,6.166 0,0,-1 1,0,0 0
  TDPOINT 0,0,0 0,0,0 0,0,0
  DELETEPOINT 2
  ATTPOINT IM 5,-2.3884,0 1,0,0 0,0,1
  ATTPOINT IM -5,-2.3884,0 -1,0,0 0,0,1
  ATTPOINT IM 0,-6.0452,0 0,-1,0 0,0,1
  ATTPOINT IM 0,-1.2997,6.166 0,1,0 0,0,-1
  ATTPOINT IM 0,-3.4771,6.166 0,-1,0 0,0,-1
  ATTPOINT IM 0,-2.3884,11.2421 0,0,1 0,1,0
  ATTPOINT IM 3.3293,-9.11,6.166 0,-1,0 0,0,-1
  ATTPOINT IM 5.5698,-6.8694,6.166 1,0,0 0,0,-1
  ATTPOINT IM 1.0887,-6.8694,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 3.3293,4.3332,6.166 0,1,0 0,0,-1
  ATTPOINT IM 1.0887,2.0927,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 5.5698,2.0927,6.166 1,0,0 0,0,-1
  ATTPOINT IM 7.8103,-4.6289,6.166 0,-1,0 0,0,-1
  ATTPOINT IM 7.8103,-0.1479,6.166 0,1,0 0,0,-1
  ATTPOINT IM 10.0508,-2.3884,6.166 1,0,0 0,0,-1
  ATTPOINT IM -3.3293,4.3332,6.166 0,1,0 0,0,-1
  ATTPOINT IM -5.5698,2.0926,6.166 -1,0,0 0,0,-1
  ATTPOINT IM -1.0887,2.0926,6.166 1,0,0 0,0,-1
  ATTPOINT IM -3.3293,-9.11,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -1.0887,-6.8695,6.166 1,0,0 0,0,-1
  ATTPOINT IM -5.5698,-6.8695,6.166 -1,0,0 0,0,-1
  ATTPOINT IM -7.8103,-0.1479,6.166 0,1,0 0,0,-1
  ATTPOINT IM -7.8103,-4.6289,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -10.0508,-2.3884,6.166 -1,0,0 0,0,-1
  DELETEPORT 1
  CONSTRUCTIONPORT 5,-2.3884,0 1,0,0 0,0,1
  CONSTRUCTIONPORT -5,-2.3884,0 -1,0,0 0,0,1
  CONSTRUCTIONPORT 0,-6.0452,0 0,-1,0 0,0,1
  CONSTRUCTIONPORT 0,-1.2997,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 0,-3.4771,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 0,-2.3884,11.2421 0,0,1 0,1,0
  CONSTRUCTIONPORT 3.3293,-9.11,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 5.5698,-6.8694,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT 1.0887,-6.8694,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 3.3293,4.3332,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 1.0887,2.0927,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 5.5698,2.0927,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT 7.8103,-4.6289,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 7.8103,-0.1479,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 10.0508,-2.3884,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -3.3293,4.3332,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT -5.5698,2.0926,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT -1.0887,2.0926,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -3.3293,-9.11,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -1.0887,-6.8695,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -5.5698,-6.8695,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT -7.8103,-0.1479,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT -7.8103,-4.6289,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -10.0508,-2.3884,6.166 -1,0,0 0,0,-1
  EMPTYMASS 70000.000000
  MASSCENTER 0.097009 -3.082356 -0.362746
  PMI 93.300000 97.500000 27.020000
  PROP LH2 75936 75936
  ENGINE 2 0 0
  CONSUMABLES 0.0001 0.0001 0 0.0001 0.0001 0 0.0001 0.0001 0
  TEMPERATURES -1:298.02:349.91 1:298.00:336.87 2:1298.32:420.57
  HEATING no
  THGROUPLEVELS 0 0 0 0 
  CREW 0 0
  ENERGY 395959211.786974
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 1 0 1 -1 0 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
END
END_SHIPS

BEGIN_ExtMFD
END

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56331.8833262666
END_ENVIRONMENT

BEGIN_FOCUS
  Ship CDLS-I
END_FOCUS

BEGIN_CAMERA
  TARGET CDLS-I
  MODE Cockpit
  FOV 40.19
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
CDLS-I:IMS\SBB41B\BG203_CONTROL_AI_SContainer
  STATUS Orbiting Earth
  RPOS 3718518.03 137.31 -5940221.19
  RVEL 6392.542 0.059 4001.270
  AROT -0.08 0.01 90.00
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000 2:1.000000 3:1.000000
  NAVFREQ 0 0
  COMMAND 1 0
  MODULE SBB41B\BT201_Truss_to_Module_Adapter 0,-2.3884,-1.0599 1,0,0 0,0,1 0
  MODULE SBB41B\BG201_Battery_SContainer 0,-4.7768,0 0,0,1 0,-1,0 0
  MODULE SBB41B\BNTR_GasCore_ClosedCycle_Nuclear_Engine 0,-2.3884,-10.1833 0,0,1 -1,0,0 0
  MODULE SBB41B\BT101_Truss 0,-2.3884,6.166 0,0,-1 1,0,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,0.9409,6.166 0,0,-1 0,-1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,-5.7177,6.166 0,0,-1 0,1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 4.481,0.9409,6.166 0,0,-1 0,1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -4.481,0.9409,6.166 0,0,-1 0,-1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,5.4219,6.166 0,0,-1 0,-1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank -4.481,-5.7177,6.166 0,0,-1 0,-1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 4.481,-5.7177,6.166 0,0,-1 0,1,0 0
  MODULE SBB41B\BTank102_LH2_LFuelTank 0,-10.1987,6.166 0,0,-1 0,1,0 0
  TDPOINT 0,0,0 0,0,0 0,0,0
  DELETEPOINT 2
  ATTPOINT IM 5,-2.3884,0 1,0,0 0,0,1
  ATTPOINT IM -5,-2.3884,0 -1,0,0 0,0,1
  ATTPOINT IM 0,-6.0452,0 0,-1,0 0,0,1
  ATTPOINT IM 1.0887,-2.3884,6.166 1,0,0 0,0,-1
  ATTPOINT IM -1.0887,-2.3884,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 0,-2.3884,11.2421 0,0,1 0,1,0
  ATTPOINT IM 6.7216,0.9409,6.166 1,0,0 0,0,-1
  ATTPOINT IM 4.481,3.1814,6.166 0,1,0 0,0,-1
  ATTPOINT IM 4.481,-1.2997,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -6.7216,0.9409,6.166 -1,0,0 0,0,-1
  ATTPOINT IM -4.481,-1.2997,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -4.481,3.1814,6.166 0,1,0 0,0,-1
  ATTPOINT IM 2.2405,5.4219,6.166 1,0,0 0,0,-1
  ATTPOINT IM -2.2405,5.4219,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 0,7.6624,6.166 0,1,0 0,0,-1
  ATTPOINT IM -6.7216,-5.7177,6.166 -1,0,0 0,0,-1
  ATTPOINT IM -4.481,-7.9582,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -4.481,-3.4771,6.166 0,1,0 0,0,-1
  ATTPOINT IM 6.7216,-5.7177,6.166 1,0,0 0,0,-1
  ATTPOINT IM 4.481,-3.4772,6.166 0,1,0 0,0,-1
  ATTPOINT IM 4.481,-7.9582,6.166 0,-1,0 0,0,-1
  ATTPOINT IM -2.2405,-10.1987,6.166 -1,0,0 0,0,-1
  ATTPOINT IM 2.2405,-10.1987,6.166 1,0,0 0,0,-1
  ATTPOINT IM 0,-12.4392,6.166 0,-1,0 0,0,-1
  DELETEPORT 1
  CONSTRUCTIONPORT 5,-2.3884,0 1,0,0 0,0,1
  CONSTRUCTIONPORT -5,-2.3884,0 -1,0,0 0,0,1
  CONSTRUCTIONPORT 0,-6.0452,0 0,-1,0 0,0,1
  CONSTRUCTIONPORT 1.0887,-2.3884,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -1.0887,-2.3884,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,-2.3884,11.2421 0,0,1 0,1,0
  CONSTRUCTIONPORT 6.7216,0.9409,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT 4.481,3.1814,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 4.481,-1.2997,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -6.7216,0.9409,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT -4.481,-1.2997,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -4.481,3.1814,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 2.2405,5.4219,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT -2.2405,5.4219,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,7.6624,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT -6.7216,-5.7177,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT -4.481,-7.9582,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -4.481,-3.4771,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 6.7216,-5.7177,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT 4.481,-3.4772,6.166 0,1,0 0,0,-1
  CONSTRUCTIONPORT 4.481,-7.9582,6.166 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -2.2405,-10.1987,6.166 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 2.2405,-10.1987,6.166 1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,-12.4392,6.166 0,-1,0 0,0,-1
  EMPTYMASS 70000.000000
  MASSCENTER 0.000000 -2.599109 -0.362746
  PMI 93.300000 97.500000 27.020000
  PROP LH2 75936 75936
  ENGINE 2 0 0
  CONSUMABLES 0.0001 0.0001 0 0.0001 0.0001 0 0.0001 0.0001 0
  TEMPERATURES -1:298.01:316.69 1:298.00:315.06 2:1299.62:558.94
  HEATING no
  THGROUPLEVELS 0 0 0 0 
  CREW 0 0
  ENERGY 395971626.907889
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 1 0 1 0 0 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
END
END_SHIPS

BEGIN_ExtMFD
END

:shrug:

Many thanks for the hard works.

 

[BruceJohnJennerLawso]

Guys, please, if you don't want to pay any money, there's always Blender or Gmax. Since we're already talking about "real" modelling software...

True, although in defense on anim8or, it has a very good pedigree with Orbiter developers. Almost all of the SSBB meshes appear to have been made in it, and I think Dansteph uses it himself. I am looking somewhat in the direction of Gmax as well though, since the calls to move on to something new have been frequent. Anim8or is generally great, but its really hard to figure out how to do certain shapes in it, and UV mapping is a clumsy process at best. Still, for a first try at meshing, Anim8or isn't the worst thing in the world...

"overloaded" is a bit of an unacurate description. You can't exactly overload a radiator unless you melt it to slack (which is not possible in IMS, it just shuts down the heat exchangers before that happens...).
Red simply means that there is one or more modules who's optimal temparature is lower than the radiators current working temparature. I.E. as long as the radiator shows up in red on the display, it is physically impossible for these modules to keep their nominal temparature. Usually solved by shutting down some connected modules, optimizing your connection scheme, turning the vessel out of the sun or screwing on more radiators.

Hmmm, good to know that, I was going to ask what happens when radiators go past their max temp, didnt think we actually simulated melting them.

And where does it go from there? You're exactly missing the point. ANY AND ALL Energy will EVENTUALLY turn to heat. Period.

In a spaceship, this "eventually" does not tend to be an overly long cycle. To take your example: It might take a bit longer, because it'll only be released when you break that momentum wheel down again, or it will happen very gradually over time as the wheel slows down from unavoidable friction.
Anyways, this is mechanic stuff we're talking about... If you take electronics, you have the transformation practically instantaneous, because they don't do any mechanical work. If you think about it, converting electricity to heat is what drives a computer.

Aughh, this thing bothers me so much. Every time I hear the "universe heat death thing" I always try to find ways to counter it, because it... it bothers me.

In the case of the momentum wheel, if its contained in the pressurized section of the vessel, yes it will eventually lose kinetic energy to friction, but what if you placed it in a vacuum chamber, or even just alongside the ship? Obviously this would be difficult to do in practice because of all the perturbations from all of the other objects in the solar system, but micro-pulses on RCS could probably work for station keeping. How does the transfer to heat happen there?

In the case of a computer, 99.9 % of the time, this does hold true, but heres an example of where it might not. If you have a computer monitor set up, probably like the one youre looking at right now, and it emits light, where is all of that energy going? Lots of it will be lost as heat in the interminable bouncing off the inside walls of the spacecraft (since its not a blackbody, but not reflective either, the light will be absorbed a little and reflected a little each pass. This basically translates into a dim glow inside that module that dissipates quickly after the lights are turned off.) The light captured by the human eye probably also turns to heat somehow, although I cant really confirm that or how. But, what about light escaping through a window? where does that turn to heat?

On the macroscopic scale, lets jump ahead the gazillion years to uniform temperature day, which we'll say happens on a Tuesday . Wouldnt gravity just start clumping all of that cold matter together again into stars & galaxies, & so on, basically starting the same process that produced the universe we see right now?

Uhm, good question actually. Not sure what I was thinking.

Hmmm, well I dont think there is any way to put a preview pic on a folder in the scenario editor, although that would be nice.

---------- Post added at 14:38 ---------- Previous post was at 14:34 ----------

The two other ones, although looking perfectly symmetrical, are pitching down as soon as thrust is engaged. It behaves like if the CoG is off the centerline.

Try checking the specs menu to see the actual reference location for your CG. If its still perfectly aligned, check that the engine placement is symmetrical (also can be found under the engines tab).

 

[BruceJohnJennerLawso]

Okay, just some small changes Ive made. I put the IMS logo through one more design cycle to get it just right.



When you see the documentation, you'll understand why

And here is the first piece of documentation, just a quick intro that directs users off to the documentation that they need. If this is where you want to put the credits for the meshes, let me know & Ill send you a word copy. How do you like the format?

Edit: whoops, small formatting error on the first copy, I fix that first, then upload again

fixed now


View attachment IMS Documentation v1.0.pdf

 

[jedidia]

but what if you placed it in a vacuum chamber, or even just alongside the ship?

If it has an axle, it has friction. If it's outside of the vessel, the situation for the vessel is of course different, as you are essentially moving energy outside.

The example with a flywheel is in so far a special case as a flywheel is in the core of its nature an energy storage device of mechanical sorts. You pump energy into it and convert it to kinetic energy, to release it at a later time. Friction in this case becomes the efficiency of the energy storage, that is, how long it can hold on to the energy stored before losing it to natural processes. But in pretty much every way, a flywheel is just a mechanical battery. Therefore, if you spin it up and then detach it from the ship you basically throw a battery out of the window. Not a very sensible thing to do, but yes, the flywheel will keep its energy for quite a long time in that case... namely, until it hits something, or until the minimal friction of the residual gases in space slows it down. Both might take a couple milion years...

But, what about light escaping through a window? where does that turn to heat?

Remember how a radiator works? right, by emitting light. Same thing if light goes out the window. That light will turn to heat whenever it hits something it can heat up.

The light captured by the human eye probably also turns to heat somehow

The part that isn't reflected warms up your receptors, pretty simple. Why did you think it is bad to look directly into the sun or a welding torch?

Wouldnt gravity just start clumping all of that cold matter together again into stars & galaxies, & so on, basically starting the same process that produced the universe we see right now?

It will do so for a loooong time to come. If the Universe stops expanding and falls in on itself again by its gravitational forces, this might lead to a second big bang. If not, well, that's that. I'm not currently occupied enough with the topic to know what the current answer on that question is.

Every time I hear the "universe heat death thing" I always try to find ways to counter it, because it... it bothers me.

Sorry... either you become religious, or you'll have to come to terms with it....

The two other ones, although looking perfectly symmetrical, are pitching down as soon as thrust is engaged.

From what I can see there's a minimal rounding error in the y-axis in the magnitude of 0.1 mm. Certainly not enough to account for your pitching, except maybe if you were talking really high time acceleration, but with this mass it really shouldn't matter. Otherwise, everything looks very much ok. The MassCenter line in the second scenario shows some really weird values, but I'm not even sure if that line still does anything. In the third scenario everything looks dandy. No Idea what's wrong there...

 

[BruceJohnJennerLawso]

If it has an axle, it has friction. If it's outside of the vessel, the situation for the vessel is of course different, as you are essentially moving energy outside.

The example with a flywheel is in so far a special case as a flywheel is in the core of its nature an energy storage device of mechanical sorts. You pump energy into it and convert it to kinetic energy, to release it at a later time. Friction in this case becomes the efficiency of the energy storage, that is, how long it can hold on to the energy stored before losing it to natural processes. But in pretty much every way, a flywheel is just a mechanical battery. Therefore, if you spin it up and then detach it from the ship you basically throw a battery out of the window. Not a very sensible thing to do, but yes, the flywheel will keep its energy for quite a long time in that case... namely, until it hits something, or until the minimal friction of the residual gases in space slows it down. Both might take a couple milion years...

Remember how a radiator works? right, by emitting light. Same thing if light goes out the window. That light will turn to heat whenever it hits something it can heat up.

Well, the idea I was suggesting was for a flywheel without an axle, but you get the idea. That being said, I dont see any real issue with storing it outside the ship, so long as you know that you can get it back when you need it. It might actually make more sense to do spin up with a momentum wheel than RCS thrusters, since the energy density of Nuclear or Solar is probably a lot better than that of RCS fuels.

But my point was, if the axle doesnt hit something, or if the light never hits anything for that matter, then the energy isnt converted to heat at all. It might be a google-to-one shot for that photon to cross the universe without impacting anything, but if it could happen, that changes the probability from 100% going to heat, to 99.999999999%. There is a difference.

It will do so for a loooong time to come. If the Universe stops expanding and falls in on itself again by its gravitational forces, this might lead to a second big bang. If not, well, that's that. I'm not currently occupied enough with the topic to know what the current answer on that question is.

Hmmm, yeah. It seems to me though, that no matter how fast or how far it expands, its never going to outrun gravity, so formation of macroscopic structures bound together by gravity will continue, its only really a question of whether the structures created will still be causing fusion...