OFSS II - Project Info & Discussion Thread

[Grover]

cool about the antares!

whilst working on the beta, i think ive found a way to house a SMALL payload inside the orbit insertion stage (HES5), not quite the size of a whole module, but if you add anything small i should be able to get it up there in an Antares (ill try it first before i go for anything)

thanks
-=Grover=-

 

[Kyle]

General question. Is it possible for Orbiter Multiplayer to do stuff like OFSS2 EVA's (Me and another player preform the same mission for example, two Astronauts on EVA) for more realistic assembly?

 

[Grover]

well, technically yes, although i believe there are problems that arise when two people control the same craft.

the main problem though is lack of time acceleration, each orbit is 1 1/2 hours, so you could take 6 hours for a mission, which you would need to leave running constantly, and its possible for you to CTD, losing your progress entirely (although if one person CTDs, the other might preserve the craft)

good luck anyway though
-=Grover=-

 

[Nazban]

It wont be the same craft would it? we can have 3 people, 1 controlling the shutlle and RMS(for shuttle missions, or the station could have an RMS of its own) and 2 different astronauts doing an EVA(like kyle said).
Anyways the main problem i only see is time issues, i live in Dubai, and thats almost 12 hours away from america(west coast side), but for something like this, ill stay up all night if i have to!!

 

[Carmen A]

I got in a few dozen solid hours of orbital practise in multiplayer and should get myself mission-qualified in good time before my launch.

We should update to the new Shuttle Fleet v4.7, yes?

And I guess no harm if I steal a few of the older, already flown scenarios, so I can get some time with intercepting the 'real' target and deploying station parts.

 

[C3PO]

We should update to the new Shuttle Fleet v4.7, yes?

Version 4.7 is still a 1'st release, and all the wrincles aren't ironed out. But when it's proven to be stable I think we should go with v4.7

 

[Carmen A]

well, technically yes, although i believe there are problems that arise when two people control the same craft.

the main problem though is lack of time acceleration, each orbit is 1 1/2 hours, so you could take 6 hours for a mission, which you would need to leave running constantly, and its possible for you to CTD, losing your progress entirely (although if one person CTDs, the other might preserve the craft)

good luck anyway though
-=Grover=-

We have worked on some stability issues related to real time scenario editing but so far orbital ops appear to be rather stable especially if all the 'mission objects' are already positioned in the scenario. Some docking bugs I believe were fixed a couple weeks back and people have been doing rendezvous quite successfully in orbit.

Low velocity ops like EVAs is as good as lagless.

To run a proper OFSS scenario may need special server side support as presently we're just using Ascension Island as a free for all sandbox. Might want to consult Face and deltawing777 on this regard and see if they can't make you a OFSS "special stage" to beta test on.

I have had requested some special features for OMP and they were put in VERY fast.

 

[deltawing777]

Face maybe able to elaborate on this a little more as far as why this didnt work. But I was able to add shuttle fleet 4.7 to the server as a vehicle. I ran into some issues with it. It did appear to run flawlessly untill I %jump to xx to a buddy that had spawned the iss. It would crash to desktop my buddy's orbiter.I was able to repeat without fail 4 more times with same result. Not sure why.When I installed Shuttle Fleet 4.7 I did so overwritting orbiter2010 files. IT worked but I could not see anybody in game.I think this is due to shuttle fleet overwritting base and earth .cfg files.So after re-installing orbiter2010 with all needed addons for our omp server I again installed shuttle fleet 4.7 this time NOT overwritting orbiter2010 files and it worked I could see people in game and it looked absolutly beautiful.Untill I decided to %jump to xx in-game. As far as a "take off from ksc scenerio" Yes this can absolutly be done.The problem with using scenerio editor to "spawn" ships while in game is this. You can add atlantis to the scenerio but not the stack itself. I think this is due to most ships listed in scenerio editor have config files as well as atlantis. But not the stack as a whole.If there is a way to make a config file to spawn the whole shuttle stack using scenerio editor im all ears. I just need to do more testing on this as I to really would like to have the shuttle back in the server

 

[Kyle]

I'm going to give Shuttle Fleet 4.7 a spin to see how this works, then I'll get back to you guys.

---------- Post added at 01:58 PM ---------- Previous post was at 01:55 PM ----------

Okay I just ran a scenario with 4.7, works perfectly. I'll be updating to that now.

 

[Face]

Hy there,

as there were several questions and statements regarding OMP for OFSSII, I am so bold to throw in my thoughts here...

Let's see if I understood the modus operandi first. AFAIK, OFSS-like projects work by means of sharing Orbiter scenarios, managed by one (or a team of) project leader:

1. Participants receive a scenario and a mission description,
2. do the mission, make screenshots and maybe a report to document the success (or failure), and
3. send back the resulting scenario.

Is this correct?

I assume I got it about right, so based on this, here is what I can imagine to work with current OMP:

• Instead of doing 1. , the project leader can setup a server with appropriate "locations". The later are scenario snippets the connecting user can choose to start with.
• Normally the server hoster would also host an Orbiter instance that occupates the static element "location", e.g. the station. All other participants would take an active role with one of the other "locations", e.g. MMUs or shuttle.
• After all clients connected, the server hoster could lock down the server, so nobody can disturb the mission.
• During the session, the server hoster can control the MJD to allow coordinated time-acceleration. In addition, a recording can be done to document the session.
• Once finished, all clients disconnect and the server hoster uses the static element's scenario file to redefine the server's location snippets in order to get ready for the next stage.

If you really want to try it out, I'd suggest the following:

• Use a simple scenario first: one station, one launching rocket, thus 2 clients. It should only be the hoster and the mission pilot.
• Before flying the mission, everyone should be sure how the multiplayer framework works and what are the DOs and DONTs. At least a working connection should be established. Try it with simple DGs first...
• Introduce every interested mission pilot to the work-mode, but only one after one. This way you can concentrate on one person and better organize meetings time-wise (world-wide time-zones!).
• Experiment with the system, but be sure your experiment is not harming someone's carefully set-out mission.

Of course, most of my points above are worth an ORLY, but it can't hurt to repeat it anyways.

regards,
Face

 

[Scruce]

Hy there,

as there were several questions and statements regarding OMP for OFSSII, I am so bold to throw in my thoughts here...

Let's see if I understood the modus operandi first. AFAIK, OFSS-like projects work by means of sharing Orbiter scenarios, managed by one (or a team of) project leader:

1. Participants receive a scenario and a mission description,
2. do the mission, make screenshots and maybe a report to document the success (or failure), and
3. send back the resulting scenario.

Is this correct?

I assume I got it about right, so based on this, here is what I can imagine to work with current OMP:

• Instead of doing 1. , the project leader can setup a server with appropriate "locations". The later are scenario snippets the connecting user can choose to start with.
• Normally the server hoster would also host an Orbiter instance that occupates the static element "location", e.g. the station. All other participants would take an active role with one of the other "locations", e.g. MMUs or shuttle.
• After all clients connected, the server hoster could lock down the server, so nobody can disturb the mission.
• During the session, the server hoster can control the MJD to allow coordinated time-acceleration. In addition, a recording can be done to document the session.
• Once finished, all clients disconnect and the server hoster uses the static element's scenario file to redefine the server's location snippets in order to get ready for the next stage.

If you really want to try it out, I'd suggest the following:

• Use a simple scenario first: one station, one launching rocket, thus 2 clients. It should only be the hoster and the mission pilot.
• Before flying the mission, everyone should be sure how the multiplayer framework works and what are the DOs and DONTs. At least a working connection should be established. Try it with simple DGs first...
• Introduce every interested mission pilot to the work-mode, but only one after one. This way you can concentrate on one person and better organize meetings time-wise (world-wide time-zones!).
• Experiment with the system, but be sure your experiment is not harming someone's carefully set-out mission.

Of course, most of my points above are worth an ORLY, but it can't hurt to repeat it anyways.

regards,
Face

Some people like me (noobs), have trouble setting up OMP. So it would be unfair to exclude me because i can not use OMP. What are the advantages anyway?

 

[Grover]

its not too hard to set up, theres a really good tutorial here, and the advantages are working together to fly a mission, so you can have two EVAs going on, where each orbinaut can perform a complimentary role to the others

 

[Carmen A]

As a stress test for OMP, some of us today embarked on a 4 hour suborbital flight campaign. No crashes, no lag, nothing. It's definitely stable enough.

A formation launch into orbit is definitely a sight to behold and a unique challenge of planning and communication.

Support wise, we are improving by creating a dedicated support website
http://omp.dyndns-server.com/

 

[C3PO]

If you really want to try it out, I'd suggest the following:

• Use a simple scenario first: one station, one launching rocket, thus 2 clients. It should only be the hoster and the mission pilot.
• Before flying the mission, everyone should be sure how the multiplayer framework works and what are the DOs and DONTs. At least a working connection should be established. Try it with simple DGs first...
• Introduce every interested mission pilot to the work-mode, but only one after one. This way you can concentrate on one person and better organize meetings time-wise (world-wide time-zones!).
• Experiment with the system, but be sure your experiment is not harming someone's carefully set-out mission.

Take a look at the required addons list. Not a simple setup, and IMHO multiplayer would put this project on the outer limit of a "regular" orbiteer's ability. Multiple spacecraft.dll and multistage.dll craft + EVA + RMS Ops in OMP is not for the fainthearted. :lol:

I'd start with something simpler for OMP. My 0.02$

 

[Kyle]

Eh, OMP for OFSS2 sounds to complicated for me to figure out. I think I'll stick to the way OFSS1 went.

 

[diogom]

On my opinion, the OFSS2 should be built Mk1 style, and later, when it's completed (or almost), the construction could be done again on OMP.

 

[Face]

Take a look at the required addons list. Not a simple setup, and IMHO multiplayer would put this project on the outer limit of a "regular" orbiteer's ability. Multiple spacecraft.dll and multistage.dll craft + EVA + RMS Ops in OMP is not for the fainthearted. :lol:

The required addons list is why I suggested to use a simple setup first, to test out if it is even feasable.

I've got some PMs mentioning the questions and suggestions regarding OMP in this group, so I thought I'll let you know how I see it.
If you rule out multiplayer anyway, there is no need to discuss it further. I didn't want to advertise it or urge you to use it .

Good luck with your project, folks!

 

[Grover]

sorry to change the subject a little here, but do we have a plan/schematic of the OFSS? id like to know exactly how big it will be (i know you've already said "it will dwarf the shuttle")

 

[deltawing777]

Eh, OMP for OFSS2 sounds to complicated for me to figure out. I think I'll stick to the way OFSS1 went.

as a wise man once said:

"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too."

JFK
lol just messing around

 

[C3PO]

The required addons list is why I suggested to use a simple setup first, to test out if it is even feasable.

I've got some PMs mentioning the questions and suggestions regarding OMP in this group, so I thought I'll let you know how I see it.
If you rule out multiplayer anyway, there is no need to discuss it further. I didn't want to advertise it or urge you to use it .

Good luck with your project, folks!

I was thinking that this was so far along that adding OMP at this stage could be problematic.
If my VSA was building stations using OMP, I would start with standard craft > simple cfg vessels > addon dll vessels > spacecraft.dll vessels.

BTW good job on OMP!!! Excellent work.:tiphat: