Iron Hill Project Thread

[TMac3000]

Wow, man, you want to be on Chronus 8 that bad? :lol: How far would you go to get on the third flight to Mercury?

But seriously, we can wait until the weekend if necessary

 

[sorindafabico]

I wasn't in flight 7, just want to fly again

 

[TMac3000]

Cool
But I do want to try and get you on that third flight to Mercury

 

[TMac3000]

Okay. After some hacking with the SCN file, I have corrected all the quantum weirdness that resulted from our previous exploits. ISS, Mir, Luna 01-B and MESSENGER now have their correct orbits and positions. Discovery and Odyssey are also where they should be.

In addition, I have placed a Shuttle-A called WideawakeMCC at Wideawake. In accordance with Sorindafabico's request, with which I wholeheartedly agree, everyone should Always hit F3 and switch control to this vessel before exiting orbiter and posting a new state. This way we won't end up with Odyssey on the Sun and MESSENGER in a three-trillion-and-something kilometer orbit around Neptune

EDIT: Oops, Chronus wasn't fueled in this state. No worries, I'll fix it tomorrow

EDIT: Corrected. New state will be posted tomorrow:goodnight:

 

[sorindafabico]

I intend to launch Chronus this weekend. In worst case, A-crew will be back to the ground until next weekend (23/24).

 

[TMac3000]

Hang on, we're getting some quantum weirdness again.

I went to check on the scenario this morning, and Chronus is being flung out into space every time I start the SCN:facepalm:

The problem doesn't seen to be affecting other vessels. Any ideas?

 

[sorindafabico]

Decommissioning Chronus and using Hermes?

 

[TMac3000]

I don't know about that--now it looks like Hermes and the other ships are being affected as well.
EDIT: Okay, I've fixed it, and I'll be posting a new correct state sometime tomorrow morning. For some reason, Orbiter was moving some of our ships to the sun, which was causing the well-known "blown into space at 15c" effect.

I still don't know exactly what caused it, so I'm putting a 24-hour hold on Chronus 8, so we can know for sure if the changes I made will survive RTU.

If any of the coding experts here on OF have any idea why this is happening, I'd be overjoyed to hear them.

---------- Post added 03-17-13 at 12:45 PM ---------- Previous post was 03-16-13 at 04:35 PM ----------

The problem is still there. I am truly running out of ideas here:facepalm:

 

[dgatsoulis]

I did not run the scenario because I don't have all the addons required but I did have a look at it (the scenario on post #1204) and the scenarios before that.

The only thing that stands out is the Hermes XR5 and its payloadbay. (Actually, it's just the Hermes because correcting it will automatically correct the payloadbay as well).

The Hermes is flying away from the sun at 2.93 AU/s (!?) and it's at a distance of about 113.9 AU, so I am guessing that's not what you want.
What was its state in the scenario before that?

I looked at sorindafabico's scenario on post #1183 but there are even more ships in a weird state (Mir, SH-03 and Hermes+Payloadbay).

Tracking it even farther back, the problem persists on SolarLiner's scenario on post #1174 (Mir, SH-03 Chronus and Hermes+Payloadbays) and exactly the same ships have the same problem on Tmac's post #1160 and SolarLiner's scenario on post #1148

All the weird states on these ships (Mir, SH-03, Chronus and Hermes) seem to have first appeared after Felipi1205's scenario on post #1144 where all the ships that are affected from there on are landed on Earth.(except Mir)

The problems seem to have begun to occur when you first used

BEGIN_RealTime
TIME=xxxxx.xxxxxx
END

in the scenarios, between post #1144 and #1148.

If the ships in question have not been used since Felipi1205's scenario on post #1144, you can get their state from there and copy it on the latest scenario. Then deactivate the realtime addon and try one flight to see if that was the problem.

Hope this helps

 

[sorindafabico]

Well, after dgatsoulis post, we have three options:

1) Test RTU saving ONLY in the glass cockpit of a ship in solar orbit (it seems the less CPU intensive option for RTU).

2) Disable RTU and use manual warp time (keys R/T) to advance time to "Now". If this works, it means RTU doesn't handle the start of the simulation very well.

3) Return to the old ScnEditor method (with no O2 consumption and no orbital perturbations)

 

[TMac3000]

I hate to give up on RTU just yet...it's a fabulous add-on, although it may need some more tweaking. I'll pull that state from 1144 and see what happens...

 

[dgatsoulis]

I haven't followed this thread from the beginning, so I am not sure exactly how you select the dates for the scenarios and fly the missions.
From what I understand, you fly the missions in realtime (now?) and update the scenario.

You want all the ships in the scenario to propagate their state with each date change and also consume any consumables, correct?

Could someone please walk me through the procedure from say... TMac3000 posting the scenario and then the commander of the mission flying it and posting the next scenario. If I understand exactly what's going on, I could look for a solution too.

 

[sorindafabico]

I hate to give up on RTU just yet...it's a fabulous add-on, although it may need some more tweaking. I'll pull that state from 1144 and see what happens...

But state #1144 is very old, before Discovery EOI, it isn't?



I've done some tests. RTU works fine warping small amounts of time (<1 day), and this probably happens because our scenario has a lot of vessels.

It's too much work ask somebody to update the state every day, so we'll have to find a better solution. We can try to warp time manually (it's better than using Scenario Editor, IMO). We'll not achieve ultra-precise time-sync with real time, but one minute or two of difference are not bad.

Also, we can reorganize the vessels in specific groups in the .SCN file. A first group of permanent freefalling vessels (ISS, MESSENGER). A second group of manned vessels (Arrows, XR5) and a third group of permanent landed vessels.

The orbits of ISS and Messenger can be periodically updated using real data editing the SCN file. Also, we may check grounded vessels to see if they are where they must be. This is easier with the SCN file reorganized.

Here's a state with vessels reorganized and RTU disabled. I deleted some we never used (Mir, Luna, etc) to improve CPU work.

 

[TMac3000]

I haven't followed this thread from the beginning, so I am not sure exactly how you select the dates for the scenarios and fly the missions.
From what I understand, you fly the missions in realtime (now?) and update the scenario.

You want all the ships in the scenario to propagate their state with each date change and also consume any consumables, correct?

Could someone please walk me through the procedure from say... TMac3000 posting the scenario and then the commander of the mission flying it and posting the next scenario. If I understand exactly what's going on, I could look for a solution too.

It's all the same scenario, although some people change the filename every now and then.
Here's what we've been doing:
1) Open "The Iron Hill Project.scn" in Orbiter.
2) Make whatever changes are necessary.
3) Exit Orbiter and copy "(Current State).scn" over "The Iron Hill Project.scn" (some people will change the file name to reflect new events, like "Iron Hill Project-Chronus Landed", etc)
4) Post "The Iron Hill Project.scn" to the forum.
5) The next person downloads the latest posted state and continues the scenario, and the process starts again.

So it's really only one file we're working with here--a persistent real-time scenario using either RTU or Scenario Editor to recalculate all the trajectories and stuff.

 

[sorindafabico]

I haven't followed this thread from the beginning, so I am not sure exactly how you select the dates for the scenarios and fly the missions.
From what I understand, you fly the missions in realtime (now?) and update the scenario.

You want all the ships in the scenario to propagate their state with each date change and also consume any consumables, correct?

Could someone please walk me through the procedure from say... TMac3000 posting the scenario and then the commander of the mission flying it and posting the next scenario. If I understand exactly what's going on, I could look for a solution too.

Yes, we fly the missions in realtime and we want to propagate state with each date change and also consume any consumables.

The last person that changed anything posts the last scenario update here.

---------- Post added at 08:58 PM ---------- Previous post was at 08:58 PM ----------

:ninja:'ed by TMac.

 

[TMac3000]

But state #1144 is very old, before Discovery EOI, it isn't?



I've done some tests. RTU works fine warping small amounts of time (<1 day), and this probably happens because our scenario has a lot of vessels.

It's too much work ask somebody to update the state every day, so we'll have to find a better solution. We can try to warp time manually (it's better than using Scenario Editor, IMO). We'll not achieve ultra-precise time-sync with real time, but one minute or two of difference are not bad.

Also, we can reorganize the vessels in specific groups in the .SCN file. A first group of permanent freefalling vessels (ISS, MESSENGER). A second group of manned vessels (Arrows, XR5) and a third group of permanent landed vessels.

The orbits of ISS and Messenger can be periodically updated using real data editing the SCN file. Also, we may check grounded vessels to see if they are where they must be. This is easier with the SCN file reorganized.

Here's a state with vessels reorganized and RTU disabled. I deleted some we never used (Mir, Luna, etc) to improve CPU work.

A few minutes makes a big difference at interplanetary velocity We need to keep this as precise as possible. I suppose we could go back to using the Scenario Editor, but I'd really like to find out why all this weird stuff is happening.

Manual time warping would be a pain in the butt, but it is doable, and we all have a few minutes' time difference between our computers anyway, which may be contributing to the problem.

Obviously, keeping RTU is off the table, at least until we figure out what the heck is wrong with it. That leaves 1) Scenario Editor, 2) manual time warp. I'd prefer option 2, but Sorindafabico, you are in command on the ground, so I'll leave it up to you. You should also confer with Astrosammy and Indy91 on this.

 

[dgatsoulis]

So for example, when a mission from the Earth to the Moon is up, whoever is the commander gets the ship to orbit, performs the TLI burn and then exits the scenario. Then he takes the (Current state) scenario, renames it and posts it here.

Then sometime later, you update the scenario to the current date (via RealTime) and continue with the next phase of the mission (MCC, LOI, or whatever is up next). Correct?

I don't understand how you use the RealTime addon. It seems to me that you need the MJD of the last scenario (at whatever time it was saved) in the BEGIN_ENVIRONMENT section and the "now" date in the BEGIN_RealTime section. But in the scenarios I looked, I saw the same date on both. Or did I miss something?

 

[TMac3000]

I'm planning to experiment with a more efficient persistence system for the Deep Six Project, in which everyone will post their own copy of the file on Orbit Hangar, to be downloaded by the next person who needs to do something. This would not only keep us from cluttering up the forum with all these states, but it might solve some of the propagation problems

 

[sorindafabico]

A few minutes makes a big difference at interplanetary velocity

Yes, but, since there's no difference inside the simulation, I think there's no problem to launch a rocket at 11:25 sim time with 11:26 system time. As you said, our computer clocks may have some difference anyway - and this doesn't affect the simulation itself, it only affects the synchronization between real world time and simulation time, which would be important only if we were playing in simultaneous multiplayer

Obviously, keeping RTU is off the table, at least until we figure out what the heck is wrong with it. That leaves 1) Scenario Editor, 2) manual time warp. I'd prefer option 2, but Sorindafabico, you are in command on the ground, so I'll leave it up to you. You should also confer with Astrosammy and Indy91 on this.

I'd prefer option 2, too. It's not the best but, the most frequently we update, the less time we'll spend updating.

I don't understand how you use the RealTime addon. It seems to me that you need the MJD of the last scenario (at whatever time it was saved) in the BEGIN_ENVIRONMENT section and the "now" date in the BEGIN_RealTime section. But in the scenarios I looked, I saw the same date on both. Or did I miss something?

When we were using RTU, both dates (environment and RTU) must be the same, since we were doing it in "real real time".

 

[TMac3000]

Option 2 it is then Here we go...

And we still need to look into this RTU bug. If it's a problem with the addon itself, then there's nothing we can do, but everybody needs to make a backup file and start playing around with it.