Download link for latest snapshot:
http://orbiter.world/orbiter.online.zip
Extract in root Orbiter directory, then activate the 3 included modules: clientpersister, serverpersister, mjdcontroller and you should be set.
What's currently supported :
I have added a combat MFD and missiles to help find bugs. Persistence is working well, with the caveat that currently there is no persistent "docking list" so discrepancies can occur. When leaving the sim, undock/redock your vessels.. This is a pain in the ass limitation that'll soon hopefully go away.
Hey guys. I have been working on a multiplayer-like collaborative mission add-on. The goal isn't real-time multiplayer, but rather to provide a persistent world and ways for players to collaborate with one another.
1. Oxygen, propellant and ships are the three primary resources players are concerned about. All players start off in a Deltaglider. They can purchase additional ships with credits, the price of which are computed using a totally arbitrary scheme that relies on the mass, thrust, size, etc to compute the price. The amount of oxygen and propellant a player's ship(s) has is controlled by the server. I would have liked to use Ummu and UCGO for Oxygen modeling but I think that decision will bite me in the ass later on. There is no easy way to integrate with those add-ons, they weren't designed with this in mind.
2. Payload management is done via Kulch's wonderful universal cargo deck add-on, because it handles all the physics for you. Sacrificing realism for playability, the idea here is that you are only constrained by your ship's thrust.
3. I know people have in the past collaboratively built space stations by doing missions and sharing scenarios. A persistent world streamlines this process greatly.
4. Get from point A to B quicker than other person type races.
5. Missions. People will inevitably strand themselves in deep space hopelessly lost. They'd be able to issue SOS calls that can be received and handled by players for credits. Refueling missions, transportation missions, etc. Because the world is persistent, the interface largely facilitates the transaction between players, but it is agnostic of the actual dealings. So for example, orbinauts would be able to negotiate deals like launching a module for either a flat fee or percent stake in all the profits from the station. If a party fails to comply, the other party can open a ticket much like it's done on PayPal/amazon/ebay and the final outcome would be decided by the world's admins/council/etc.
6. Achievements. Tracking the total distance traveled by each ship, the number of missions and complexity of each mission, crossing the 100 km mark for the first time, being supersonic for the first time, etc, with a rank going from newbie to master orbinaut. I plan on having a little link that people can post in their signature in the orbiter-forum that'd display their stats.
7. Mission planning. Even doing LEO/local space stuff requires planning and careful execution. I think in Orbiter things appear to be so easy because we can time accelerate whenever we want and compensate for lack of planning by hitting T and doing another burn with massive engines and endless supply of fuel. Because players can only fly ships they own (unless on a mission) and because they lose the ships they destroy, players will be motivated to use mission planners to plan their missions lest they find themselves in the middle of nowhere. I am guilty of this. If I could, I would bring up my mission planner MFD, plan my mission and have my plan sent over to be looked at/annotated/approved by an expert, and that's precisely what'll happen here.
I am looking for ideas specifically about collaborative station management. Collaboratively building the station is easy. Each person involved launches the module and the persistent world syncs the vessels and their positions across all clients, so no need to share scenarios.
What I need help with is, what to do once the station is built? You can have one person in charge of the oxygen on board and the food (which is consumed according to the number of crew on board, also a server side variable). Since most stations will likely be built as orbital fueling stations, another person could be responsible for making sure that the fuel reservoirs are full. I believe there are regulations about when and how spacecraft can rendezvous and dock with one another, so one person could perhaps be responsible for approving or rejecting docking requests. Since this is all real-time, the request to dock could be transmitted to the "Docking Officer" onboard the station via his/her cell phone via an email notification (opt-in and optional). The docking officer would fire up orbiter and will be presented with the scenario containing the approaching ship. The officer could then based on the situation approve or reject the docking request in game, which will be transmitted to the approaching player.
I am looking for other ideas along this line. I don't know what real astronauts on the ISS do.. I think doing a full blown systems emulation would be totally out of scope. But given the persistent world described here, what could some duties be of the crew of stations? At the time the station is "registered" with the world, the player can do an EVA and indicate specific parts/regions and label them. Given that, we could do some generic damage modeling and maintenance of sub-systems. Implementing it is easy, but the devil (and fun) is in the details.
http://orbiter.world/orbiter.online.zip
Extract in root Orbiter directory, then activate the 3 included modules: clientpersister, serverpersister, mjdcontroller and you should be set.
What's currently supported :
- Docking
- Atmospheric flight
- Persistence
- Missiles (Combat MFD)
I have added a combat MFD and missiles to help find bugs. Persistence is working well, with the caveat that currently there is no persistent "docking list" so discrepancies can occur. When leaving the sim, undock/redock your vessels.. This is a pain in the ass limitation that'll soon hopefully go away.
Hey guys. I have been working on a multiplayer-like collaborative mission add-on. The goal isn't real-time multiplayer, but rather to provide a persistent world and ways for players to collaborate with one another.
1. Oxygen, propellant and ships are the three primary resources players are concerned about. All players start off in a Deltaglider. They can purchase additional ships with credits, the price of which are computed using a totally arbitrary scheme that relies on the mass, thrust, size, etc to compute the price. The amount of oxygen and propellant a player's ship(s) has is controlled by the server. I would have liked to use Ummu and UCGO for Oxygen modeling but I think that decision will bite me in the ass later on. There is no easy way to integrate with those add-ons, they weren't designed with this in mind.
2. Payload management is done via Kulch's wonderful universal cargo deck add-on, because it handles all the physics for you. Sacrificing realism for playability, the idea here is that you are only constrained by your ship's thrust.
3. I know people have in the past collaboratively built space stations by doing missions and sharing scenarios. A persistent world streamlines this process greatly.
4. Get from point A to B quicker than other person type races.
5. Missions. People will inevitably strand themselves in deep space hopelessly lost. They'd be able to issue SOS calls that can be received and handled by players for credits. Refueling missions, transportation missions, etc. Because the world is persistent, the interface largely facilitates the transaction between players, but it is agnostic of the actual dealings. So for example, orbinauts would be able to negotiate deals like launching a module for either a flat fee or percent stake in all the profits from the station. If a party fails to comply, the other party can open a ticket much like it's done on PayPal/amazon/ebay and the final outcome would be decided by the world's admins/council/etc.
6. Achievements. Tracking the total distance traveled by each ship, the number of missions and complexity of each mission, crossing the 100 km mark for the first time, being supersonic for the first time, etc, with a rank going from newbie to master orbinaut. I plan on having a little link that people can post in their signature in the orbiter-forum that'd display their stats.
7. Mission planning. Even doing LEO/local space stuff requires planning and careful execution. I think in Orbiter things appear to be so easy because we can time accelerate whenever we want and compensate for lack of planning by hitting T and doing another burn with massive engines and endless supply of fuel. Because players can only fly ships they own (unless on a mission) and because they lose the ships they destroy, players will be motivated to use mission planners to plan their missions lest they find themselves in the middle of nowhere. I am guilty of this. If I could, I would bring up my mission planner MFD, plan my mission and have my plan sent over to be looked at/annotated/approved by an expert, and that's precisely what'll happen here.
I am looking for ideas specifically about collaborative station management. Collaboratively building the station is easy. Each person involved launches the module and the persistent world syncs the vessels and their positions across all clients, so no need to share scenarios.
What I need help with is, what to do once the station is built? You can have one person in charge of the oxygen on board and the food (which is consumed according to the number of crew on board, also a server side variable). Since most stations will likely be built as orbital fueling stations, another person could be responsible for making sure that the fuel reservoirs are full. I believe there are regulations about when and how spacecraft can rendezvous and dock with one another, so one person could perhaps be responsible for approving or rejecting docking requests. Since this is all real-time, the request to dock could be transmitted to the "Docking Officer" onboard the station via his/her cell phone via an email notification (opt-in and optional). The docking officer would fire up orbiter and will be presented with the scenario containing the approaching ship. The officer could then based on the situation approve or reject the docking request in game, which will be transmitted to the approaching player.
I am looking for other ideas along this line. I don't know what real astronauts on the ISS do.. I think doing a full blown systems emulation would be totally out of scope. But given the persistent world described here, what could some duties be of the crew of stations? At the time the station is "registered" with the world, the player can do an EVA and indicate specific parts/regions and label them. Given that, we could do some generic damage modeling and maintenance of sub-systems. Implementing it is easy, but the devil (and fun) is in the details.
Last edited: