New Release Interplanetary Modular Spacecraft RC9

[PeterRoss]

The strange thing is that it does show 144 downloads, so the problem doesn't seem constant.

Alas, failed downloads counted. I am responsible for acouple of dozens of "downloads" personally. I guess it was broken all the time.

I searched the thread but did not find a formula for how IMS calculates the power output of solar panels although the topic has been discussed a couple of times.

How can I calculate the power output of a solar panel at a certain distance from the sun assuming optimal alignment (perpendicular to the sun I suppose)?

Any deployed solar panel considered to be perpendicular to the sun, because they're supplied with sun-tracking animation. As for dependance of power output from the distance to sun, all I can help with is to note that solars' output at LEO is depicted at module's preview pic in SBB41Brev2 config pack.

---------- Post added at 21:03 ---------- Previous post was at 20:46 ----------

Wait, isn't the power output is a square root of distance (sorry for my math English)?

Like, if PO = 1 at distance of 1AU, then PO at 2 AU is square root of 2?

---------- Post added at 22:02 ---------- Previous post was at 21:03 ----------

all I can help with is to note that solars' output at LEO is depicted at module's preview pic in SBB41Brev2 config pack.

Seems like these new pics are missed from the IMS RC4.

 

[jedidia]

How can I calculate the power output of a solar panel at a certain distance from the sun assuming optimal alignment

If I'm remembering correctly, it's solar constant / distance(AU)^2 * surface area * efficiency.

the [ame="http://en.wikipedia.org/wiki/Solar_constant"]solar constant[/ame] is the average solar output at 1 AU, which is 1.36 kW/m^2

Seems like these new pics are missed from the IMS RC4.

oops... were they not included in SSBB4.1Rev2?

 

[PeterRoss]

Confirming RC4 stability against the gremlin bugs reported by me. The thing seems stable as rock for the first glance, have to test it furthermore to be sure. Thanks, Jedidia :thumbup:

---------- Post added at 22:56 ---------- Previous post was at 22:54 ----------

oops... were they not included in SSBB4.1Rev2?

They were, but with "_r2" added to a file name, to keep backwards compatibility.

---------- Post added at 23:02 ---------- Previous post was at 22:56 ----------

ADDED: And solar panels previews were just overwritten by new ones with the same name because there was no changes in the config files, only more useful information on the preview.

 

[wingnut]

If I'm remembering correctly, it's solar constant / distance(AU)^2 * surface area * efficiency.

the solar constant is the average solar output at 1 AU, which is 1.36 kW/m^2

Thanks, that looks about right. The result (divided by 10) is a bit less than what's displayed in IMS.

 

[BruceJohnJennerLawso]

Tried the dl again, and it worked. The D3D9 issue I was experiencing before is gone! Thank you Jedidia!

Unfortunately something odd is up with the solar panels...

which appears to be unique to the D3D9 Client while retracted

Otherwise everything is great. The meshes look great, the panels react much faster... IMS is simply excellent under D3D9 :thumbup:

I cant wait for the SSBB4.1 normal maps pack.

Edit: Okay Jedidia, heres the issue that I was talking about with lifesupport generating consmables even while offline. These two snapshots were taken 15 seconds apart, notice how the values for water & oxygen are growing, even though the lifesupport module is offline:

before:

and after:

Im also confused as to how you exactly kill unfed crew. Do they die instantly upon entering a vessel with 0 of some consumable, or is that checked on a cyclical basis (ie check every ~6 hours, since the crew only requires food at meal times...)

 

[jedidia]

Unfortunately something odd is up with the solar panels...

Screenshot's too dark, I can't make out anything...

Okay Jedidia, heres the issue that I was talking about with lifesupport generating consmables even while offline.

Ok, there's definitely something fishy. I assume it's the same scenario you posted before?

Im also confused as to how you exactly kill unfed crew. Do they die instantly upon entering a vessel with 0 of some consumable, or is that checked on a cyclical basis (ie check every ~6 hours, since the crew only requires food at meal times...)

Had to look that one up in the code. They have 3 minutes without oxygen, 3 days without water and 30 days without food before dying.

The D3D9 issue I was experiencing before is gone! Thank you Jedidia!

Right. I was kinda hoping for that. The whole affair smelt of a corrupted build. It's a rare occurance, but it can happen, and there's no way to reproduce it once I did a new build apart from dumping the DLL from the download in the folder again. But, to be entirely honest, I could reproduce the behavior... one single time. Then I rebuilt the project, because the current build was release and I needed a debug build to track it down, and it didn't happen. Then I built in release again and it still didn't happen, so I pretty much assumed that this was the problem.

Thanks, that looks about right. The result (divided by 10) is a bit less than what's displayed in IMS.

Divided by 10? why divided by 10? Do I have a decimal error in there somewhere? :blink:

 

[BruceJohnJennerLawso]

Screenshot's too dark, I can't make out anything...

Better shot here:

It seems quite similar to the issue that PeterRoss had with one of his custom parts earlier (Orbiters coordinate system), but it only happens in D3D9 when the solar panels retract.

Ok, there's definitely something fishy. I assume it's the same scenario you posted before?

See! Im not crazy after all :lol:

Yes, the same scenario as posted before. (albeit with the XRs & UCGO cargoes back in, but that isn't relevant)

Had to look that one up in the code. They have 3 minutes without oxygen, 3 days without water and 30 days without food before dying.

Would you mind posting that snippet here for me to see?

Right. I was kinda hoping for that. The whole affair smelt of a corrupted build. It's a rare occurance, but it can happen, and there's no way to reproduce it once I did a new build apart from dumping the DLL from the download in the folder again. But, to be entirely honest, I could reproduce the behavior... one single time. Then I rebuilt the project, because the current build was release and I needed a debug build to track it down, and it didn't happen. Then I built in release again and it still didn't happen, so I pretty much assumed that this was the problem.

Odd. So the glitches would have been due to the compiler making an error in the build?

 

[wingnut]

Divided by 10? why divided by 10? Do I have a decimal error in there somewhere? :blink:

No, I don't think so, it was my mistake, e. g.

SolarArrayRect at 1 AU:
SolarArrayArea = 600
Efficiency = 6

1.361 / 1^2 * 600 * 6 = 4899.6 (Watts I suppose?) so it would actually be divided by 100 of course to get kW - I got confused with the decimal sign in my spreadsheet.
There still is a small discrepancy. The IMS display in Orbiter says the SolarArrayRect has some 51 kW output in LEO, that's negligible for my purposes.

 

[jedidia]

1.361 / 1^2 * 600 * 6 (Watts I suppose?) so it would actually be divided by 100 of course to get kW - I got confused with the decimal sign in my spreadsheet.

Erm... no. Not quite.

1.361 is already in kW/m^2, but efficiency is in percent. That means the equation would go 1.36 kW/m^2 * 600 m^2 * 0.06, giving you the result in kW. So that's where your division by 100 comes from. to convert Watts to Kilowatts you'd actually have to divide by a thousand

 

[wingnut]

Oh man, I should really learn to think more carefully before posting something let alone use a calculator :blush:

Okay then my division by 100 is not owed to the conversion of W to kW but to the fact that I calculated with efficiency 6 instead of 0.06

 

[jedidia]

Odd. So the glitches would have been due to the compiler making an error in the build?

I assume so. It happens rarely, but it does. A computer is one huge Rube Goldberg machine, and sometimes things don't work out quite the way they should. Especially in Bosnia, where we have random light powersurges in the distribution that can can cause my PC to boot up from standby all by itself in the middle of the night if I don't unplug it (though since that build was done on the laptop, that cause is probably out). I had a similar problem once before, where I was searching for a bug, and in the end it simply vanished after rebuilding a project...

It seems quite similar to the issue that PeterRoss had with one of his custom parts earlier (Orbiters coordinate system), but it only happens in D3D9 when the solar panels retract.

Does it always happen under those conditions? Can anyone else confirm? I tested the animations after I did the cleaning up, I expierienced no such behavior (incidentaly I tested it with exactly your scenario). I'll see if I can reproduce it somewhen today, but a bit more detailed description wouldn't hurt. For example, does it happen because they don't retract correctly? or do they retract and then go haywire?

Would you mind posting that snippet here for me to see?

			if (GetPropellantMass(storageCaps.oxygen) == 0)
				TimeWithoutOxygen += simdt;
			else TimeWithoutOxygen = 0;
			if (GetPropellantMass(storageCaps.food) == 0)
				TimeWithoutFood += simdt;
			else TimeWithoutFood = 0;
			if (GetPropellantMass(storageCaps.water) == 0)
				TimeWithoutWater += simdt;
			else TimeWithoutWater = 0;

			if (TimeWithoutOxygen > 180 ||
				TimeWithoutWater > 259200 ||
				TimeWithoutFood > 2592000)
			{
				for (int i = 0; i < crewNumber; ++i)
					KillCrewMember(i);
			}

---------- Post added at 07:12 AM ---------- Previous post was at 06:39 AM ----------

It seems quite similar to the issue that PeterRoss had with one of his custom parts earlier (Orbiters coordinate system), but it only happens in D3D9 when the solar panels retract.

As expected, no repro. Please tell me exactly under what circumstances the issue appears.

 

[Dantassii]

Build errors

Odd. So the glitches would have been due to the compiler making an error in the build?

Do you folks know why the Space Shuttle main computers were built using Pentium I sized chips when they were upgraded back in the late 90's even though that technology was long obsolete in PCs?

Circuit size.

Computer circuitry has gotten so small these days that bit flips caused by cosmic radiation are a constant concern. The orbiters around Mars for instance suffer a 'soft reboot' about once a week due to radiation caused bit flips corrupting the contents of RAM and causing a crash.

To solve this problem, you either have to shield your computers with LOTS AND LOTS of lead shielding, or you have to use larger (and hence older) circuit sizes. As LOTS AND LOTS of lead isn't possible due to mass constraints, you see lots of older tech computer circuitry in spacecraft, or you see them doing lots and lots of reboots.

How does this affect computers on Earth?

Well, I've seen perfectly good software suddenly stop working. Upon doing a binary compare of the source code files between the current and backup, I find strange, unprintable, characters hiding in the source code. The source of these unprintable characters is random bit flips on the hard drive caused by radiation that makes it all the way to the hard drive.

So it doesn't surprise me that a binary got corrupted sometime after it's last compile. It's one of those 'when not if' situations. You leave a program on a hard drive long enough, and it will get a bit flipped somewhere.

Oh, and debugging these sort of errors is REALLY hard. Trust me, it took me nearly 2 weeks to figure out what had happened the first time it happened to me back in 1995. Since then it happens about once every 2-3 years, at least that I notice it happening.

Dantassii
HUMONGOUS IMS shipbuilder

 

[BruceJohnJennerLawso]

Does it always happen under those conditions? Can anyone else confirm? I tested the animations after I did the cleaning up, I experienced no such behavior (incidentaly I tested it with exactly your scenario). I'll see if I can reproduce it somewhen today, but a bit more detailed description wouldn't hurt. For example, does it happen because they don't retract correctly? or do they retract and then go haywire?

As expected, no repro. Please tell me exactly under what circumstances the issue appears.

I get the issue when loading the scenario under D3D9, but it works fine in D3D7. Theres nothing wrong with the panels while opened, but when I go to retract them, the retraction animations all happen in wacky orders & directions as if the file was written wrong. Im deleting & recopying my configs copy under modules/server just to be sure.

			if (GetPropellantMass(storageCaps.oxygen) == 0)
				TimeWithoutOxygen += simdt;
			else TimeWithoutOxygen = 0;
			if (GetPropellantMass(storageCaps.food) == 0)
				TimeWithoutFood += simdt;
			else TimeWithoutFood = 0;
			if (GetPropellantMass(storageCaps.water) == 0)
				TimeWithoutWater += simdt;
			else TimeWithoutWater = 0;

			if (TimeWithoutOxygen > 180 ||
				TimeWithoutWater > 259200 ||
				TimeWithoutFood > 2592000)
			{
				for (int i = 0; i < crewNumber; ++i)
					KillCrewMember(i);
			}

Thanks. I may do some small rewrites on that section for you if you like. I think a better approach would have each crew object doing some data storage for hunger, thirst, blood oxygen levels & so on. I'll take a look at what Ive got on that in my copy of the 2.3 source code later.

 

[jedidia]

Thanks. I may do some small rewrites on that section for you if you like. I think a better approach would have each crew object doing some data storage for hunger, thirst, blood oxygen levels & so on. I'll take a look at what Ive got on that in my copy of the 2.3 source code later.

That is possible of course, but I decided against it because then I'd also kind of have to add medical facilities and stuff, and in the current architecture it's just really unweildy.

That said, putting in a decent crew class would be one of the more simple additions, as it wouldn't cross too much with the rest of the code. But I'll rather start earnestly with IMS2 once I'm done getting out the bugs here. If someone wants to take the code and develop it further, be my guest, but I won't make any inclusions of foreign code before official release, and then I won't touch it ever again. I'm too close to this thing actually working decently to throw in new stuff.

---------- Post added at 08:10 PM ---------- Previous post was at 01:01 PM ----------

I just killed the crew of the horizon station... obviously the bug of the miraculous water and oxygen multiplication is fixed :shifty:

The problem was that the regen values still got saved and loaded to the scenario file, while actually they got calculated at sim start... but incrementally, as the modules come online. Which means that if you saved with lifesupport running, you suddenly got it double after reloading, and those doubles didn't care about power either.

Now, I have two possibilities to fix this. One breaks backward compatibility (can be undone by minor scenario editing), the other will save three useless values to the scenario for all eternity.
Kind of a sucker choice...

 

[BruceJohnJennerLawso]

That is possible of course, but I decided against it because then I'd also kind of have to add medical facilities and stuff, and in the current architecture it's just really unweildy.

That said, putting in a decent crew class would be one of the more simple additions, as it wouldn't cross too much with the rest of the code. But I'll rather start earnestly with IMS2 once I'm done getting out the bugs here. If someone wants to take the code and develop it further, be my guest, but I won't make any inclusions of foreign code before official release, and then I won't touch it ever again. I'm too close to this thing actually working decently to throw in new stuff.

Cant promise anything, but I might be able to provide a crew class, probably for use in IMS2. I would likely need some guidance on how to interface with other parts of IMS beforehand though.

I just killed the crew of the horizon station... obviously the bug of the miraculous water and oxygen multiplication is fixed :shifty:

You Bastard!!! :lol:

Thats err, good to hear. I remember that odd feeling of pseudo-excitement when I first disposed of an unlucky UMMU in a Shuttle-D.

The problem was that the regen values still got saved and loaded to the scenario file, while actually they got calculated at sim start... but incrementally, as the modules come online. Which means that if you saved with lifesupport running, you suddenly got it double after reloading, and those doubles didn't care about power either.

Now, I have two possibilities to fix this. One breaks backward compatibility (can be undone by minor scenario editing), the other will save three useless values to the scenario for all eternity.
Kind of a sucker choice...

So I can fix that issue by editing the scenario file? I wouldn't go to any great lengths to fix it in this version, just remember so that we don't make the mistake in IMS2.

On that topic, what is the status with IMS2? I think RC4 is as far as we realistically should go with IMS. If you want a keeper for the code, I would be happy to maintain RC4 until it becomes obsolete.

 

[Inksoull]

I am still getting CTD when the module loads from RC4... It wouldn't matter that I'm using UMMU 2.5 would it? (I'll go test that now) Otherwise all I can think of is that neither of my computers can handle it...

 

[PeterRoss]

I am still getting CTD when the module loads from RC4... It wouldn't matter that I'm using UMMU 2.5 would it? (I'll go test that now) Otherwise all I can think of is that neither of my computers can handle it...

Are you talking about loading some Upsilon Andromeda scenario yet, or you can't start IMS at all?

 

[Inksoull]

Are you talking about loading some Upsilon Andromeda scenario yet, or you can't start IMS at all?

I have never used the Upsilon Andromeda System, so not that.

I can create a perfectly working ship within a scenario, but when if i save it and try to reload the scenario then CTD...

 

[PeterRoss]

I have never used the Upsilon Andromeda System, so not that.

I can create a perfectly working ship within a scenario, but when if i save it and try to reload the scenario then CTD...

There's a known issue of IMS causing Orbiter CTD after quiting to Launchpad and starting again. The only workaround is to completely restart Orbiter after exiting (it can be made automatically by setting "Respawn Orbiter" mode at debugging submenu). Is the Orbiter crashing after complete Orbiter restart? If it is so, please post your scenario here.

 

[Inksoull]

There's a known issue of IMS causing Orbiter CTD after quiting to Launchpad and starting again. The only workaround is to completely restart Orbiter after exiting (it can be made automatically by setting "Respawn Orbiter" mode at debugging submenu). Is the Orbiter crashing after complete Orbiter restart? If it is so, please post your scenario here.

That fixes it brilliant, thank you! Why couldn't I find this anywhere before?