New Release Interplanetary Modular Spacecraft RC9

[Dantassii]

Another question of a general nature

What is a 'good' acceleration for a ship that will never land on a planet but needs to get in/out of orbit of a planet in 1 burn?

1 G? 0.5 G? 0.25 G? 0.1G?

I'm trying to decide if I want to spend the time trying to improve the acceleration of my SSTV or concentrate on figuring out just where I'm going to put all the heat generated by the engines I've got already? I got rid of all but 1 of the Hyper Engines (kept one as an 'experimental' unit) and replaced the rest with the more realistic engines that :

1. Produce so much heat that I can only run them for about 15-20 seconds before the engines and my high temperature radiators start melting
2. Only give me 3.8 km/s delta V (instead of 40 Mm/s) with my current fuel load
3. Require 12 engines to produce the acceleration of 1 Hyper Engine (and I originally had 5 Hyper Engines, so 60 engines would be required to get the same acceleration as the original design).

Dantassii
HUMONGOUS IMS spacecraft builder

 

[BruceJohnJennerLawso]

What is a 'good' acceleration for a ship that will never land on a planet but needs to get in/out of orbit of a planet in 1 burn?

1 G? 0.5 G? 0.25 G? 0.1G?

I'm trying to decide if I want to spend the time trying to improve the acceleration of my SSTV or concentrate on figuring out just where I'm going to put all the heat generated by the engines I've got already? I got rid of all but 1 of the Hyper Engines (kept one as an 'experimental' unit) and replaced the rest with the more realistic engines that :

1. Produce so much heat that I can only run them for about 15-20 seconds before the engines and my high temperature radiators start melting
2. Only give me 3.8 km/s delta V (instead of 40 Mm/s) with my current fuel load
3. Require 12 engines to produce the acceleration of 1 Hyper Engine (and I originally had 5 Hyper Engines, so 60 engines would be required to get the same acceleration as the original design).

Dantassii
HUMONGOUS IMS spacecraft builder

I like 0.2-0.4 G, but that may require a double kick for ejection when in low fast orbits. 0.7 might be a good target, but I think you can handle low accelerations if you're ejecting from lunar orbit. :tiphat:

 

[PeterRoss]

Incidentally, PeterRoss, is this bit of memory-voodoo in clbkSaveState from you?

   memset (&stat, 0, sizeof(stat));

It's rather unnecessary after declaring the VESSELSTATUS on the stack, I think.

Well, I wasn't sure what's this was about, I just copied the piece of code from some other source (either Deltaglider code or something else) which was doing what I needed to do, and it seemed like working. No coder I am...:embarrassed:

What is a 'good' acceleration for a ship that will never land on a planet but needs to get in/out of orbit of a planet in 1 burn?

1 G? 0.5 G? 0.25 G? 0.1G?

0.5 G should be sufficient, although I managed to perform single translunar burns with 0.1 G many times.

I'm trying to decide if I want to spend the time trying to improve the acceleration of my SSTV or concentrate on figuring out just where I'm going to put all the heat generated by the engines I've got already? I got rid of all but 1 of the Hyper Engines (kept one as an 'experimental' unit) and replaced the rest with the more realistic engines that :

1. Produce so much heat that I can only run them for about 15-20 seconds before the engines and my high temperature radiators start melting.

Do you use the latest configs revision? Because the latest version of NTRs almost don't produce any waste heat and dont require radiators anymore.

 

[Dantassii]

Thanks for the suggestions

I like 0.2-0.4 G, but that may require a double kick for ejection when in low fast orbits. 0.7 might be a good target, but I think you can handle low accelerations if you're ejecting from lunar orbit. :tiphat:

0.5 G should be sufficient, although I managed to perform single translunar burns with 0.1 G many times.

Do you use the latest configs revision? Because the latest version of NTRs almost don't produce any waste heat and dont require radiators anymore.

Thanks for the suggestions!

I have the latest configs revision but I haven't used them yet because except for the Hydroponics modules weighing more, none of the modules that I use seem to be any different. But if the NTRs are that much improved, I'll definitely swap them out and try the newer ones. Being unable to fire the main engines for more than 15-20 seconds at a time seemed pretty bad.

Dantassii
HUMONGOUS IMS shipbuilder

 

[jedidia]

It could be because of some IMS function being called recursively, or because of very large variables allocated by IMS on stack.

Must be somewhere in the stack tracing, then (the vessel stack, not the memory stack). IMS analises the currently docked stack in order to give the user some information already prior to integration. That's about the only recursive thing that's happening, I think. But it doesn't do name comparisons while doing that... I'll have to take a closer look. Dantassii, do you have a scenario that cleanly reproduces the crash?

 

[PeterRoss]

Thanks for the suggestions!

I have the latest configs revision but I haven't used them yet because except for the Hydroponics modules weighing more, none of the modules that I use seem to be any different. But if the NTRs are that much improved, I'll definitely swap them out and try the newer ones. Being unable to fire the main engines for more than 15-20 seconds at a time seemed pretty bad.

Dantassii
HUMONGOUS IMS shipbuilder

Almost forgot: in the case if you're using GasCoreNTR_ClosedCycle engines from IMS folder, it isn't affected by the latest configs revision which applies to SBB41B pack only.
You'll have to manually change its efficiency to 99.9999 or something. It must be able to work for half an hour at the full thrust without overheating ideally, you could try to find the correct efficiency value by trial and error if you want it to be like in real life.

 

[Dantassii]

Scenario that produces the crash

Must be somewhere in the stack tracing, then (the vessel stack, not the memory stack). IMS analises the currently docked stack in order to give the user some information already prior to integration. That's about the only recursive thing that's happening, I think. But it doesn't do name comparisons while doing that... I'll have to take a closer look. Dantassii, do you have a scenario that cleanly reproduces the crash?

I've attached a ZIP file that has 3 scenarios in it

• 10 BT101's that don't CTD
• 12 BT101's that have similar names and CTD
• 12 BT101'a where the last 2 have an extra 'A' put in the module name that do not CTD

It's the same scenarios that I sent to orb. orb was able to duplicate the error I saw with the second scenario.

Dantassii
HUMONGOUS IMS shipbuilder

 

[orb]

orb was able to duplicate the error I saw with the second scenario.

No, I wasn't able to duplicate it with the 2nd scenario, because I haven't used IMS so far. I substituted IMS vessels with stock vessels (Module2) to test if the scenario itself (vessel / class / file names as the bug report stated) can cause an error.

 

[jedidia]

Right. The recursive function GetStack gets called 87065 times before the stack finally overflows. So much for the cause of the crash. Not yet sure what the reason for this behavior is, though.

 

[Dantassii]

No, I wasn't able to duplicate it with the 2nd scenario, because I haven't used IMS so far. I substituted IMS vessels with stock vessels (Module2) to test if the scenario itself (vessel / class / file names as the bug report stated) can cause an error.

Opps, my bad. I thought you had duplicated it.

This is the smallest scenario that I could create that definitely causes the CDT. I actually was kinda surprised that this caused it as the first time I ran into it was with a MUCH larger scenario (about 200 modules). Took me a while to figure out what the problem was in my scenario because I had so many things moving at the time. Just goes to show that the saying 'save your work often' is applicable to IMS as it is in software development.

---------- Post added at 09:39 ---------- Previous post was at 09:36 ----------

Right. The recursive function GetStack gets called 87065 times before the stack finally overflows. So much for the cause of the crash. Not yet sure what the reason for this behavior is, though.

87,065 times???? Egads! Sounds worse than my Computational Fluid Dynamics programs back from when I was working on my Ph.D! (That's a Rocket Scientist term BTW )

Dantassii
HUMONGOUS IMS shipbuilder

 

[jedidia]

87,065 times???? Egads! Sounds worse than my Computational Fluid Dynamics programs back from when I was working on my Ph.D!

That's what happens when your code enters an endless loop, which is exactly what happens. The reason for this is rather weird... Namely, a circular docking conection when orbiter starts up, although that should not be possible (the recursive function that traces the stack finds BT201-01 docked to BT101-09, and then loops along that chain).

The reason for this is not clear at all to me... I cannot replicate it outside IMS. However, the GetStack function is simply called when the clbkDockEvent is fired on the IMS vessel on startup. I cannot yet see how the problem might be related to vessel names. I'll try to find a few more hints...

Currently I'm more thinking of uninitialised docking ports and therefore undefined behavior than an actual circular connection, although I'm not quite sure how that could happen either.

---------- Post added at 03:38 PM ---------- Previous post was at 03:20 PM ----------

Aaaand... fixed!

As I suspected, another case of me not thinking enough about the orbiter event cue. Just because the IMS vessel gets the dockEvent does not mean that all the other vessels in the scenario got it too. Which probably means that I was tracing the vessel stack at a time when not all docking ports on all vessels were properly initialised.

What bothers me is that this should be undefined behavior, however the phenomenon has demonstrated an incredible consistency. Somehow I think there's a lot more to the picture than I presume, I just can't see it.

Anyways, the problem's been fixed by not executing any code in the clbkDockEvent until the first frame, and do it there retroactively. It seems to work, but it might have other consequences I didn't think through properly...

For all intents and purposes, we're heading for an actual RC3, on which I already gave up hope. Give me some more time to build up IMS2 to the point where integrations in all positions work flawlessly, so I can adopt it retroactively into IMS. I'm still having the unsolved trouble of a docking port still pointing to a deleted vessel every now and then, if I'm lucky I'll get that too...

 

[Dantassii]

Was/Is this going to be a problem in IMS 2?

Aaaand... fixed!

As I suspected, another case of me not thinking enough about the orbiter event cue. Just because the IMS vessel gets the dockEvent does not mean that all the other vessels in the scenario got it too. Which probably means that I was tracing the vessel stack at a time when not all docking ports on all vessels were properly initialised.

What bothers me is that this should be undefined behavior, however the phenomenon has demonstrated an incredible consistency. Somehow I think there's a lot more to the picture than I presume, I just can't see it.

Anyways, the problem's been fixed by not executing any code in the clbkDockEvent until the first frame, and do it there retroactively. It seems to work, but it might have other consequences I didn't think through properly...

For all intents and purposes, we're heading for an actual RC3, on which I already gave up hope. Give me some more time to build up IMS2 to the point where integrations in all positions work flawlessly, so I can adopt it retroactively into IMS. I'm still having the unsolved trouble of a docking port still pointing to a deleted vessel every now and then, if I'm lucky I'll get that too...

But why would this behavior not show up if you simply change the name of the 11th and further copies of the module? What is really getting my cat-killing curiosity is why the module names would have any impact on this occurring.

I hope you're not 'wasting' a lot of time/effort fixing IMS 1.0 RC2.3 on account of this bug. I'm mainly interested in making sure this bug doesn't sneak into IMS 2.0 by some back door. Errors from earlier releases ALWAYS shows up in later releases when I start code over from scratch unless I understand why the error showed up and specifically code the new release to not do it.

Dantassii
HUMONGOUS IMS shipbuilder

P.S. My SSTV is getting up there on number of modules. Due to all the BCCHs I'm adding to it for cargo capacity, it may actually be BIGGER than the Lunar Station where it is being built at. Go figure.

 

[jedidia]

I hope you're not 'wasting' a lot of time/effort fixing IMS 1.0 RC2.3 on account of this bug.

Nah, it was very educative. It convinced me to adapt a new policy for IMS2: Don't do anything in clbkDockEvent except noting that the event occured, then execute the necessary code in clbkPreStep. This way I can always be sure that all vessels involved in the action will have processed their events, and I will also be sure that everything will only get executed once even if there's several dockevents in one frame (which, in IMS, is not exactly a rare occasion...).

But why would this behavior not show up if you simply change the name of the 11th and further copies of the module? What is really getting my cat-killing curiosity is why the module names would have any impact on this occurring.

That is indeed a very interesting question, and I'd like to know the answer for it, but I'll leave that up to the philosophers. My immediate concerns in the matter are satisfied.

P.S. My SSTV is getting up there on number of modules. Due to all the BCCHs I'm adding to it for cargo capacity, it may actually be BIGGER than the Lunar Station where it is being built at. Go figure.

:facepalm:
You know, I wasn't quite honest with you... Well, actually, I was honest, but I didn't think things through. The index in a vector is an unsigned integer, which means that the maximum value of an unsigned integer is indeed the maximum number of modules you can have in an IMS vessel. That number is... 65535.

 

[Dantassii]

:facepalm:
You know, I wasn't quite honest with you... Well, actually, I was honest, but I didn't think things through. The index in a vector is an unsigned integer, which means that the maximum value of an unsigned integer is indeed the maximum number of modules you can have in an IMS vessel. That number is... 65535.

Ok, I think my station won't exceed 10,000 modules, so I should be safe... you have convinced me that I don't want to build my interstellar spacecraft using IMS 1.0..

 

[jedidia]

you have convinced me that I don't want to build my interstellar spacecraft using IMS 1.0..

IMS2 is very unlikely to support a higher number :lol:

 

[Dantassii]

Well....

IMS2 is very unlikely to support a higher number :lol:

Well how in the world am I going to build my ship that can carry 10,000 people (self supportive) at relativistic speeds to Alpha Centuri? LOL.

Dantassii
HUMONGOUS IMS shipbuilder

 

[PeterRoss]

Well how in the world am I going to build my ship that can carry 10,000 people (self supportive) at relativistic speeds to Alpha Centuri? LOL.

Dantassii
HUMONGOUS IMS shipbuilder

Oh, that's easy. I can create a single module for you with 10k crew capacity

P.S. Are you going to name all the UMMUs manually or to write some script doing it automatically? :lol:

 

[Dantassii]

Are you going to name all the UMMUs manually or to write some script doing it automatically? :lol:

Script? I'd suppose I could probably write a Java program.. or a C++ program... or a FORTRAN program... or a Visual Basic program... or maybe I will write a Perl Script.... With 35 computer languages to choose from I could come up with something.

I just integrated my current SSTV design. It has over 710 modules and I still have 3 more racks of BCCHs to put on board. It's down to only 0.4G with the main NTE engines (all 52 of them!) and the single hyper engine only adds another 0.2G. I also only have 2.8km/s of delta V on the mains. Gonna have to get that back up to at least 20km/s of delta V. I still have about 38Mm/s on the hyper engine. Don't know how I'm going to get the acceleration up. I mean I'm already running into naming problems with my NTEs (remember, you have to come up with unique combination of letters for ever group of 10 of them).

I will say this much though, sure looks pretty when the NTEs fire up on the dark side of the Earth.

Little kid on Earth when the SSTV lights off: Look Mommy, the moon!
Mommy: That's no moon.....

Dantassii
HUMONGOUS IMS shipbuilder

 

[PeterRoss]

Care to share some pictures of the engine stack running?:blink:

 

[Dantassii]

Eventually, once I decide what the final Engine layout/combination will be. I've kept 1 of the Hyper engines as an 'experimental' engine, but the ship can perform the entire mission w/out it if it fails. I think I may add 4 more and then add more fuel until I have enough Delta V with just the NTEs to do the mission (a bit slower than with full power) but use the Hyper engines along with the NTEs in most cases. I really like the Hyper Engine exhaust effects.

I also have to figure out a way to cool the ship while it is in the sun with its' engines on. Right now the whole thing overheats when it's not facing exactly the right direction even for a few seconds.

Ah the joys of thermodynamics. I haven't worked with them since 1996.

Dantassii
HUMONGOUS IMS shipbuilder