Real Time Inc Test Mission

[TMac3000]

For RTI's maiden flight, I'd like us to try a one week stay at ISS. This would allow me to test a new persistent-mission system for future RTI projects. Here's how the new system would work:

1) When a new project is started, the project coordinator (Sorindafabico on the Collins Project, for example-- or myself for Deep Six) will post the first state on their OH account.

2) Each team member will download a copy and post it on theirOH account. Whenever someone makes a change to a project, they announce the change in the appropriate thread, and update their copy on OH.

3) When the update is announced, everyone will download it from the account of the person who did it.

This way, each person has one file to keep up with, and we don't have to clutter up the forum with all those states like we did in IHP. And speaking of IHP, we'll continue using the current system until Discovery returns to Earth in September

I'd love to get some feedback on this idea, especially the shakedown flight to ISS.

 

[sorindafabico]

Vessel: XR1? XR2? A capsule?

ISS: Default? UCGO ISS? AtoZ?

 

[TMac3000]

Let's start with default ISS for now We can use a DG-IV for the mission. That will enable us to "transfer crew" without the need for UCGO compatibility. If it works, we can move up to the UCGO compatible version.

 

[sorindafabico]

But the default ISS isn't UMMU-capable. I suggested UCGO ISS because this.

 

[garyw]

It is UMMU compatible with [ame="http://www.orbithangar.com/searchid.php?ID=3509"]UMMUFA v.2.0[/ame]

I use that for my own ISS missions and it works very well.

 

[TMac3000]

But the default ISS isn't UMMU-capable. I suggested UCGO ISS because this.

I know, but if you dock a DGIV to the default ISS and put the ship in "safe mode" (there's a checklist in the system for this), it will "transfer" the crew to ISS (although you won't be able to do anything with them). They will be automatically "transferred" back when you reactivate the ship.

You have a good point though. An ISS mission would be no fun without some EVAs. UCGO it is

 

[BruceJohnJennerLawso]

I know, but if you dock a DGIV to the default ISS and put the ship in "safe mode" (there's a checklist in the system for this), it will "transfer" the crew to ISS (although you won't be able to do anything with them). They will be automatically "transferred" back when you reactivate the ship.

You have a good point though. An ISS mission would be no fun without some EVAs. UCGO it is

Ooh, Ooh, Ooh

Why not use this too?

[ame="http://www.orbithangar.com/searchid.php?ID=6032"]http://www.orbithangar.com/searchid.php?ID=6032[/ame]

Completely shameless plug there :lol:

It should be able to fit into a DGIV cargo bay, although I havent tried yet.

 

[TMac3000]

We could use it, but for what exactly? Maybe add a couple of new modules to ISS?

 

[garyw]

What is the mission to the ISS for? If you are planning or running a type of VSA then it needs to have some sort of reason be it 'fly to ISS, spend three days and then undock'.

It sounds like you need to get some mission background down to work out what the mission is actually going to deliver?

 

[TMac3000]

The purpose of this mission would be to try out a new system for swapping state files, in a persistent real-time mission such as the Iron Hill Project was. In IHP, we just posted the latest state on the forum, and the next person downloaded it, did whatever they needed to do, and posted the state that they ended up with. This worked, but it was not very efficient, and resulted in the thread being cluttered with a zillion files.

The new system will involve OrbitHangar, and is expected to be much more efficient, since there will only be one file for each team member, and they can update it whenever they do something. Just one question--can we supress the automatic creation of an OF thread when someone posts their file for the first time?

 

[BruceJohnJennerLawso]

We could use it, but for what exactly? Maybe add a couple of new modules to ISS?

Well its really just a survey pod, but if you attached a URMS to it it would make a neat little platform to do a flyaround with.

Just a thought.

 

[garyw]

The purpose of this mission would be to try out a new system for swapping state files, in a persistent real-time mission such as the Iron Hill Project was.

then that is your mission, that is all you should be trying to achieve. No point in over complicating things from day one. Start small, work out the kinks then build up to the more complex missions.

 

[kamaz]

I'd love to get some feedback on this idea, especially the shakedown flight to ISS.

Why not use subversion (SVN)?

Step 1: Set up a SVN repo(sitory) using any of the providers listed here: http://www.svnhostingcomparison.com/ .

Step 2: Create initial scenario, put it in the repo. You can also create directories for screenshots etc.

Step 3: All project members install TortoiseSVN, configure it and download (checkout) initial version

Flight operation:

Step 1: Download changes from repo (update in SVN lingo)

Step 2: Execute flight. Save changed scenario. Optionally, add pictures from the trip.

Step 3: Save (SVN: commit) changes to repo.

Not only this allows you to keep team members in sync (commit/update), SVN keeps log of file changes, so you can easily extract old game states.

 

[TMac3000]

I'll check that out this evening when I get home

 

[Face]

I'd rather discourage the use of OHM for this purpose, after all it will not be an add-on per se and could be seen as spam. OHM is not a gaming platform IMHO.

On the SVN idea: that sounds much better. You can see the history of your project there, even if it is only the one scenario file. But I think you will find the central nature of SVN as single point of failure, especially with many people involved, "collision on commit" comes to mind. As always with version control, I'd suggest using Mercurial instead, as you don't need a server (although Bitbucket is a good free hosting platform), you have full local history to tinker with and you can commit as many intermediate steps as you want without worrying about other people. Especially the later one fits nicely to your initial one-file-per-member idea. Just make it one-branch-per-member.

As for the concept as such, I've written an article about what could work in contrast to the many failed VSA attempts out there: challenges. Your proposal doesn't sound too different.

regards,
Face

 

[BruceJohnJennerLawso]

As for the concept as such, I've written an article about what could work in contrast to the many failed VSA attempts out there: challenges. Your proposal doesn't sound too different.

regards,
Face

The Iron Hill Project and RTI probably have been the first succesful open VSAs. I think thats a pretty significant achievement.

I was wondering if you could take a look at my proposal for venture station? It does share some common elements with a VSA, but modified in order to work effectively. I would be interested to hear what you think about the idea.


Before I forget Tmac, you should change this threads name to Real Time Incorporated trip to ISS. The current thread title sounds like some sort of obscure orbital ops maneuver, probably causing most people to ignore it

 

[dgatsoulis]

Since this is going to be just for scenario updates, you can checkout dropbox as an alternative.
Easy to setup and work with. You can use common folder for just the members of your VSA and even upload any customizations you may have made, such as textures, custom meshes, dlls etc, without cluttering up O-H or O-F.

Although, since you will be using O-F for discussion and project design, I don't see what's the problem in adding the scenarios too.
Things can be simplified if the project leaders have a link with the calendar and mission roster in their signature and also a link with the latest scenario state.
This way members won't have to go through multiple pages of posts to find an update; they simply click on one of the project leaders' latest posts (regardless of forum topic) and are immediately up to speed with upcoming events and latest scenario state.

The links themselves could be anywhere, either a file sharing site, or a specific post here on O-F.

Just my :2cents:

 

[TMac3000]

DropBox sounds like the best solution to me, and linking to the latest state in my sig is a very good idea This is something we need to decide as a team tho. I'm curious to know what my fellow Iron Hill-ers think of this?

---------- Post added at 04:55 PM ---------- Previous post was at 04:53 PM ----------

The Iron Hill Project and RTI probably have been the first succesful open VSAs. I think thats a pretty significant achievement.

Wow, that would be quite an honor if it turns out to be true:thumbup: At very least, it's a huge compliment. Thanks, man

 

[kamaz]

On the SVN idea: that sounds much better. You can see the history of your project there, even if it is only the one scenario file. But I think you will find the central nature of SVN as single point of failure, especially with many people involved, "collision on commit" comes to mind.

"Collision on commit" would not take place here by definition, because TMac3000 has several pilots who take turns playing in pre-agreed order -- in other words, pilot B will start playing only after pilot A finishes his turn and executes SVN commit. This is trivial to achieve just by using SVN logs (not to mention forum or e-mail). There's no need to go into the extra complexity of distributed version control, quite the contrary in fact -- a centralized repo forces the timeline consistency, so to speak.

As already suggested, even dropbox is enough for this, except that SVN also gives you change log and history.

 

[sorindafabico]

I think dropbox is enough, but SVN is good too.

===

About the mission: if we use the UCGO ISS, we could fly a crew there (real Iron Hill participants or just "dummy" astronauts) who would be using the consumables, justifying periodical routine missions.