New Release Interplanetary Modular Spacecraft RC9

[Hlynkacg]

Note:

If you want a set of meshes that can be included in the IMS download (no calls to Burchismo) required drop me a line. You're already using my engines, I've got more where they came from.

 

[BruceJohnJennerLawso]

No, unfortunately it can't be right. Reason being, heat transfers only work from higher temperature to lower. You can't dump the coolant of your mainframe into a radiator that runs at 900K. Unless you build a mainframe that can run at above 900K, of course...

Well, exactly, if I had "the mother of all MCS systems", could it do that in theory?

My point with all that was that if we're bothering with a cooling system, it probably should be able to preferentially relocate heat for us. The typical (& much more sane method) for dealing with cooling problems is to add more radiator area, since insufficient area will leave too much heat still in the modules we need nice & cool, so adding more area acts as a sort of heat sink (which of course does dispose of some heat for us anyways). But, if my hypothesis is true, maybe the alternate method to cooling could be to have a souped up MCS system which dumps a ton of heat into one radiator. I just can think of any way that it could be done in practice :shrug:

I totally agree there, but I don't have the time currently.

Just a thought. I figure our next part priorities can be command modules, then engines, then fuel tanks. I guess Im the only active mesher right now though...

That would be PeterRoss's revised configs. Due to a research glitch, NTRs had way too much waste heat originally. In real life they have practically none, because they use the exhaust for cooling. This brings some efficiency losses, but those are already accounted for in the specs you find about them.

:lol:, in the propellant! Im sure every engineer would love to discover that his engine is dealing with waste heat by doing its job better!

Not if you don't have them in store...

Yes, but I have regenerative lifesupport & food for everyone on board. i wouldnt care, except those alerts keep stopping timewarp in the middle of my journey to Mars.

I felt pretty intimidated too when inheriting the code from vchamp. It's rather large, and a bit messy, but when you work a bit with it you'll start to find your way around.

Well, I'll start in the shallow end of the pool first. I'll double check that I have that IMS.rc file, then I should hopefully have the new touchdown point feature implemented by Friday. Im also going to create an offline copy of your bug-hunting list that came with the source too. I just hope I know what to fix when I get there.

Note:
If you want a set of meshes that can be included in the IMS download (no calls to Burchismo) required drop me a line. You're already using my engines, I've got more where they came from.

:jj: awesome!

Shall I contact you, or would you rather transfer them through Jedidia?

---------- Post added 03-14-13 at 01:29 AM ---------- Previous post was 03-13-13 at 11:15 PM ----------

First Command module on my list is done. Now to find the others...

 

[Hlynkacg]

I haven't really been paying attention to who is working on what, but if you give me a list of the modules you need for a "Base Package", along with a quick physical description, I'll get on it.

I have a whole bunch of stuff that I've assembled for my alternate history Apollo and Shuttle projects as well as some a bunch of drawings and models I created for a non-Orbiter science fiction project.

 

[BruceJohnJennerLawso]

I haven't really been paying attention to who is working on what, but if you give me a list of the modules you need for a "Base Package", along with a quick physical description, I'll get on it.

I have a whole bunch of stuff that I've assembled for my alternate history Apollo and Shuttle projects as well as some a bunch of drawings and models I created for a non-Orbiter science fiction project.

Hmmm, its kinda hard to explain all of what we need, but Ill describe the categories.

Command Modules - not exactly an Apollo CM, although it can be one. IMS ships start with a command module & build from there, so its really the "bridge" of the ship. If youve ever seen the Bullet Command module, thats it (in fact Im going to try to create something similar myself.)

Solar panels & radiators - pretty self explanatory, although they may need to have their mesh groups defined in specific ways so that sun tracking is possible (only solar panels do that actually)

More engines - Maybe we could use some of the work in your Nuclear transit shuttle?

General modules - Basically just space station modules, with appropriate skins for whatever they do

Cargo containers - also very useful

Communications arrays - also may need specific mesh group structure, as the high gain dishes track user set targets

Engines and fuel tanks - all types, all fuels (most fuels), any sizes.

 

[MaverickSawyer]

Hmmm, its kinda hard to explain all of what we need, but Ill describe the categories.

Command Modules - not exactly an Apollo CM, although it can be one. IMS ships start with a command module & build from there, so its really the "bridge" of the ship. If youve ever seen the Bullet Command module, thats it (in fact Im going to try to create something similar myself.)

Solar panels & radiators - pretty self explanatory, although they may need to have their mesh groups defined in specific ways so that sun tracking is possible (only solar panels do that actually)

More engines - Maybe we could use some of the work in your Nuclear transit shuttle?

General modules - Basically just space station modules, with appropriate skins for whatever they do

Cargo containers - also very useful

Communications arrays - also may need specific mesh group structure, as the high gain dishes track user set targets

Engines and fuel tanks - all types, all fuels (most fuels), any sizes.

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.

 

[jedidia]

Well, exactly, if I had "the mother of all MCS systems", could it do that in theory?

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.

for dealing with cooling problems is to add more radiator area, since insufficient area will leave too much heat still in the modules we need nice & cool, so adding more area acts as a sort of heat sink (which of course does dispose of some heat for us anyways).

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.

---------- Post added at 12:10 PM ---------- Previous post was at 09:35 AM ----------

Just got around to uploading the resource file. Let's see what other build errors there'll come up :lol:

 

[PeterRoss]

Or you turned them into the sun. Bad Idea, that, at least for low temperature radiators.

An inability of radiators to sun-tracking and/or vessel to keep its attitude towards sun forced me to use as absurd low-temp radiator configuration as this, for exapmle:

The vessel (unfinished yet) has four radiators which is used to cool just a single CM module! I need two perpendicularly-aligned radiators for at least one of them not to be directly hit by the sunlight, and two other - for visual symmetry :lol:
The vessel's name is Aquarius, by the way

 

[jedidia]

and/or vessel to keep its attitude towards sun

That's strange... killrot should keep the attitude to the sun quite nicely, I never had problems with it.

The vessel (unfinished yet) has four radiators which is used to cool just a single CM module!

There's a few things more at work here... The lack of support of one-sided radiators and no shadowing for radiators means that if the sun hits one, it will always hit the one in its shadow as well.

 

[PeterRoss]

That's strange... killrot should keep the attitude to the sun quite nicely, I never had problems with it.

It does, but not if the vessel is spinning on LEO for a week or two while I'm busy with another stuff.

There's a few things more at work here... The lack of support of one-sided radiators and no shadowing for radiators means that if the sun hits one, it will always hit the one in its shadow as well.

Yes, I know it. But I still have two radiators which aren't under direct sunlight then! :lol:


I managed to build an IMS.dll without fatal errors, but there were quite many other - about syntax and some other stuff. As a result, my .dll isn't working at all. I can create an IMS CM, but it has no any IMS abilities at all and is being saved as any dummy vessel.
Do you think it will help if I'll try to compile the build under VS 2008? You've used this version, if I recall correctly.

 

[jedidia]

I managed to build an IMS.dll without fatal errors, but there were quite many other - about syntax and some other stuff. As a result, my .dll isn't working at all.

Not quite possible, really. there'll be a ton of warnings, that's ok. If there are any synthax errors, the code doesn't build at all. Make sure the dll is in the right place for Orbiter to find, and if you are, take a look at the orbiter log. If the dll failed to load it'll be there. I'll need to see the build log to give any more advice.

 

[PeterRoss]

1>------ Построение начато: проект: IMS_RES, Конфигурация: Release Win32 ------
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(C:\Games\Orbiter_2010\Orbitersdk\IMS\/../../Modules/IMS\IMS_RES.dll) не соответствует значению свойства выходного файла (C:\Games\Orbiter_2010\Modules\IMS\IMS.dll) для Linker. Это может привести к неправильному построению проекта. Чтобы исправить это, убедитесь, что значения свойств $(OutDir), $(TargetName) и $(TargetExt) соответствуют значению, указанному в %(Link.OutputFile).
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5): warning MSB8012: TargetName(IMS_RES) не соответствует значению свойства выходного файла (IMS) для Linker. Это может привести к неправильному построению проекта. Чтобы исправить это, убедитесь, что значения свойств $(OutDir), $(TargetName) и $(TargetExt) соответствуют значению, указанному в %(Link.OutputFile).
1>     Создается библиотека C:\Games\Orbiter_2010\Orbitersdk\IMS\/../../Modules/IMS\IMS_RES.lib и объект C:\Games\Orbiter_2010\Orbitersdk\IMS\/../../Modules/IMS\IMS_RES.exp
1>  IMS_RES.vcxproj -> C:\Games\Orbiter_2010\Orbitersdk\IMS\/../../Modules/IMS\IMS_RES.dll
========== Построение: успешно: 1, с ошибками: 0, без изменений: 0, пропущено: 0 ==========

I can translate Russian parts if you need. It is mostly about TargetName path is defined relatively and Linker result file path is absolute, I think. I can fix it if needed.
Even with all these errors IMS.dll is being created where it should be. The resulting file is little bit smaller than the original one (I mean - the one compiled by you).

There is this error message in Orbiter.log:

---------------------------------------------------------------
>>> ERROR: Could not load vessel module: IMS\IMS
>>> [Vessel::LoadModule | .\Vessel.cpp | 5442]
---------------------------------------------------------------

EDIT:
There were many other non-fatal errors appearing in build log when I tried to compile it unsuccesfully. All of these appeared just once and never been shown again in latter build logs, although I did nothing to fix it.

 

[jedidia]

All of these appeared just once and never been shown again in latter build logs, although I did nothing to fix it.

They'll reappear if you choose "rebuild". Warnings are not errors, that's why it builds. They are indicators that something is not going to the compilers liking and might be a source of bugs under certain circumstances, but nothing more. The fact that orbiter can't load the dll is not connected to them, your build was succesful. The dll is quite simply incompatible.

This reminds me of something... riiiight. try installing this, then try again. It's very possible that the VC runtime redistributables that come with Orbiter 2010 are not compatible with what VS express 2010 builds against.

I remember having a similar problem, but I'm not sure whether the problem was that the module was built against the Orbiter Beta SDK or built with VS2010 or both, but installing the security update above might fix our little problem here.

 

[PeterRoss]

One more issue seems to have croppped up for me while building the Aquarius. I had quite a few issues in getting the centrifuge to run on it, but I was able to push through most of the forward section. Once I get to building the truss section though, IMS crashes any saves from that point on. Ive uploaded the Scenario files so that you can take a look.

View attachment 11468

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:

 

[Urwumpe]

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.

 

[orb]

You should ALWAYS treat warnings like errors during development.

And you can do it at the compiler side by using "/WX" switch.

 

[Urwumpe]

And you can do it by using "/WX" compiler switch.

Yes, but that isn't really necessary, if you have the discipline. You just need to get away from the beginners attitude, that warnings are ok and don't require attention.

It is like the shock, when you do a static code analysis on a program, that you felt was great, and suddenly have 300 problems reported. And all 300 are justified, no false positive or code that has no alternative. From stuff like having a password in plaintext in your source code to an error-attracting way to iterate through containers.

 

[jedidia]

And you can do it at the compiler side by using "/WX" switch.

That's ok if you do it from the beginning, but when you pick it up in the middle it's just a wee bit annoying to change hundreds of ints to unsigned just to avoid the warning when you need to compare one of them with a vector index in a for loop.

 

[PeterRoss]

They'll reappear if you choose "rebuild". Warnings are not errors, that's why it builds. They are indicators that something is not going to the compilers liking and might be a source of bugs under certain circumstances, but nothing more. The fact that orbiter can't load the dll is not connected to them, your build was succesful. The dll is quite simply incompatible.

This reminds me of something... riiiight. try installing this, then try again. It's very possible that the VC runtime redistributables that come with Orbiter 2010 are not compatible with what VS express 2010 builds against.

I remember having a similar problem, but I'm not sure whether the problem was that the module was built against the Orbiter Beta SDK or built with VS2010 or both, but installing the security update above might fix our little problem here.

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.

 

[Urwumpe]

That's ok if you do it from the beginning, but when you pick it up in the middle it's just a wee bit annoying to change hundreds of ints to unsigned just to avoid the warning when you need to compare one of them with a vector index in a for loop.

Still easier fixed than kept. It just is no fun at all. :tiphat:

 

[jedidia]

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.

wait... only when loading an existing scenario? It works if you create a new CM?

As far as I remember you're running Win7. VS2010 builds can be a problem on XP, as far as I know, but on 7 it really shouldn't matter. This might get tricky...