Orbiter Online - Milestone 0 Goals Thread

[Urwumpe]

Clockwise or counter-clockwise? ( )

Inside to outside of course! It's your choice if you implement something or just make a concept for it. :rofl:

 

[BHawthorne]

Looks a lot like the classic Shewhart PDCA Cycle design. Interesting to see how other industries adapt problem solving tools. The guys who come up with these cyclical solutions must like donuts.

 

[DarkWanderer]

Well, are we finised with donuts discussion?..

I've created a repository for the project: http://bitbucket.org/darkwanderer/mmorbiter/
Please sign in for access.

As for the main topic:
My vision of "realistic" sci-fi (Orbiter is already sci-fi) is a resource-based economy with additional government and player-to-player missions.
"Resources" include a common set of material and goods, similar to any elite-like game. Government missions include satellites launch/retrieving, probe delivery, courier and scientific missions. Player to player - just like EVE contracts, ability to ask someone do something for money. Though the latter is of low priority.
So, the main sources of gaining wealth will be:
- Mining
- Government missions
- P2P interaction (credits, corporation leadership)
We were asked to reduce the amount of grinding, so mining itself may be automated. But the player would be required to drive back and forth to deliver the product. And here we get an organic advantage of a corporation: building a refinement station near the "mine" will make the flights quite more viable (as the product will reduce in size and gain in price), and one pilot would have difficulties maintatining the station (he would have to make flights there regularly). And of cource, he could set such a price for consumables on his station that other players will happily bring him it
Your thoughts?..

 

[BHawthorne]

Join us in irc. face and I have been actively debating all kinds of things in the #orbiter-online channel.

 

[goop]

Out of curiousity here is the major problem I see with an MMORPG, I was wondering how you would plan to solve it.

Not everyone has everysingle addon so if one person does not have the addon wouldn't their session fail to load?

Perhaps you could make any mesh or tex that fails to load as a Deltaglider inorder to avoid this problem.

 

[DarkWanderer]

Not everyone has everysingle addon so if one person does not have the addon wouldn't their session fail to load?

It's gonna be either a distributed addon set requiring separate install, either addon control system, assuring that client has every addon enabled on server. The exact variant will be chosen when other design parts are complete.

 

[Face]

Out of curiousity here is the major problem I see with an MMORPG, I was wondering how you would plan to solve it.

Not everyone has everysingle addon so if one person does not have the addon wouldn't their session fail to load?

Perhaps you could make any mesh or tex that fails to load as a Deltaglider inorder to avoid this problem.

Distribution is certainly a important aspect, but not at the current state. As I see it, a dynamic distribution system in the ranks of addon-managers will soon enough bring up all kinds of quirks regarding intellectual property. I don't think it is wise to go this route. A fixed software compilation will better suite the needs of an anyway fixed scenario setup IMHO.

regards,
Face

 

[Arrowstar]

Distribution is certainly a important aspect, but not at the current state. As I see it, a dynamic distribution system in the ranks of addon-managers will soon enough bring up all kinds of quirks regarding intellectual property. I don't think it is wise to go this route. A fixed software compilation will better suite the needs of an anyway fixed scenario setup IMHO.

regards,
Face

What if the addon manager simply pulled the addon ZIP file from the dev's web hosting and unpacked it into the Orbiter directory? It'd be just like downloading it and installing it yourself.

On the other hand, you could simply have the app check to see if all the required addons are installed and ask the player to get them before running.

 

[Face]

What if the addon manager simply pulled the addon ZIP file from the dev's web hosting and unpacked it into the Orbiter directory? It'd be just like downloading it and installing it yourself.

This would be nothing more than a complicated web-installer.
What about collisions? How to delete an addon again? What if the download location is temporarly down? What about different installation formats? How to deal with different packaging structure (some folks use extra directories, some don't use directories at all)?
I think such a distribution strategy is not going to work in an automated way.

On the other hand, you could simply have the app check to see if all the required addons are installed and ask the player to get them before running.

How would you want to do that? Checking file presence? This is not enough, file content can be different. Checking time stamps or MD5 hashing? This is surely not going to be "simply".

In the end, it all boils down to a common Orbiter installation, i.e. exactely the same state of the Orbiter installation on all participating machines. This can be achieved by single package distribution much faster and more stable than with incremental or even on-demand distribution.

Anyway... maybe the multiplayer solution the project results in will not be too demanding on Orbiter installation state at all. In this case, no distribution strategy - besides the addon itself - is needed. Therefore: let's wait and see.

regards,
Face

 

[Fizyk]

All of this would be doable, but unfortunately would require dr Martin to change the way Orbiter handles addons. You could have a separate directory for addons, where each addon would have its own directory. This is the way addons are handled by for example Garry's Mod and it's pretty awesome - you can easily delete unneeded addons, quickly check which ones are installed, etc, etc.

 

[Face]

All of this would be doable, but unfortunately would require dr Martin to change the way Orbiter handles addons. You could have a separate directory for addons, where each addon would have its own directory. This is the way addons are handled by ie. Garry's Mod and it's pretty awesome - you can easily delete unneeded addons, quickly check which ones are installed, etc, etc.

It has been done. Without the need for core support or change.

Orbiter's structure allows not only additive addons, but modifying addons, too. I.e. there can be an addon requiring change to core files such as base textures and the like. Thus just switching to separate directories for addons will not work. There will always be a problem with collisions. Deferring this fundamental issue to the good doctor is a bit much IMHO.

I think something like Garry's Mod is a fine thing for simple addon-management, but if it comes to concurrent file manipulation and interdependency of addons, it fails. If it even comes to version management, it is right out of the game. And version management is something you will encounter real soon if you're doing addon development...

I know I may hold a strong opinion here, but in my book meta-data based package-managers - requiring package-maintainers to grasp the inerts of a whole new description language just to enable addon-distribution - suffer from a design-flaw. I've all to often ran into problems with things like aptitude, zipper, rpm.

All you want is to have all the necessary files in your directory, so why complicating the matter with meta-data? Just snapshot that directory and give it a name.

regards,
Face

 

[Fizyk]

I don't know how much it is required to modify core files, as I haven't made any addons for Orbiter yet, but I guess if you say it's necessary, then it is, and the system I suggested would fail in this case. COI indeed looks like a great solution to this (I saw this project being started, but I haven't been here for a while, so I didn't see you finished it - really great work!).

 

[Face]

I don't know how much it is required to modify core files, as I haven't made any addons for Orbiter yet, but I guess if you say it's necessary, then it is, and the system I suggested would fail in this case. COI indeed looks like a great solution to this (I saw this project being started, but I haven't been here for a while, so I didn't see you finished it - really great work!).

Thanks. It is not finished, though.

Many popular addons modify core files. One of the more frequently modified core files is /Config/Base.cfg .

About the necessarity for modifying core files: this is the point here. We don't know how open the system could or should be made. Without this design descision being done, it is a bit academical to discuss distribution methods.

While COI is able to handle most distribution problems, I still think it would be better to first aim for a all-in-one package-distribution route, but time will tell...

regards,
Face

 

[Kaito]

Note: I may not support all these Idea’s these are just some that I came up with in order to possibly spark some discussion.

My idea for an Online version of Orbiter would include: New Time Management, an Economic System, and a hierarchy of “power”, or administrators.




Economy
Market
My idea for an economy would be a sort of free-market, player run system, with little to no NPC interaction on the market place. There would be a currency that you could use to buy certain things such as fuel for ships, repairs, or possibly buy new ships. The way to earn money could come in several ways:

1)Start off with a certain amount of money, and do “quests” for either NPC’s or other players to earn money. So, in a sort, you need to work to earn money. I am in favor of the ability to transfer money from player to player, but the idea of involving NPC’s might be a bit risky and lead to exploiting.
2)Each person has a “job” that they attend. This job is part of a company, and you regularly earn money, online or not. This would virtually eliminate the need for market NPC’s, but it would reward you for not playing the game. I am in favor of having a “job”, so to speak, however this would need to be refined. Maybe have a player run company, like SpaceTech, and it have “employees” that get paid. However, this would have to incorporate a technology system, which I will cover later.
I think the best approach would be a combination of the two, with the ability to transfer money from one person to another (pay someone), and have a job in which you earn money.

Resources
This is assuming we have a “company” system; one way to earn money would be to search for resources, sort of like today. People are mining for Coal and Oil for which they are paid to do. We have some resources, example of which could be:
Lunar Rock (big chunks)
Lunar Regolith (the dust)
Titanium
Metal (a kill-all term for ship material)
H2
O2
LOX

These are just examples, and could be expanded on. However, all the resources would have to be defined internally, which is a bit obvious. Obviously, there can be updates, but this aspect would need to be thoroughly thought out.

One reason I suggested the “Solar Power MFD” is because this would be a critical part in a realistic version of Orbiter Online. Power/Energy would be a critical part resource, and could even produce an “energy monopoly”. How, I have no idea, but with enough resources and time, someone could

Pros to a Market
Gives some sort of purpose
Cons to a Market
Could be overly complex



Hierarchy of Power
“Power” in this section referrers to an administrative, or admin, ability.

Power is a crucial element in EVERY online game. Whether it is that only a special few have power, or no one has power, it has an effect. In a game I used to play, there was a server with multiple people on it, but there were several levels of admin ability. A few people had the power to kick, kill, and abuse the other players. While the abuse was kept to a minimum, it still happened. This, in my opinion, is a form of “client side” power, where a player has the ability to affect others directly. The other form would be “server side”, rcon, or remote console. This is affecting the server settings directly, which may or may not affect the other players. Another example of this is right here, on the forums: there are admins (Tex/Vash) who can directly affect the servers, then there are mods who can use their power on us almost at will (not saying they would, but it is possible). I feel that a form of both of these could/should be implemented in any form of Multiplayer version of Orbiter.

RCON
Rcon stands for Remote Console; it is basically direct access to the server and its settings. Because of this, only the server host and anyone he deems trustworthy should have this. This is the Tex/Vash on our forum. The server settings could include elements such as: date, time, number of vessels, banned IP list, Master time acceleration, etc. Basically all the main environment elements in the scenario would be accessible through rcon.

Server Admins
This might be going a bit far for Orbiter Online, but I might as well bring it up for discussion. The server host would give certain “abilities” to individuals. These are the “mods” on our forum. They could use certain commands to do things to people, whether it be punish or reward. Some “abilities” they could receive are:
Control over a players fuel level
Control over a players thruster settings
Control over a players position
Ban
Kick
Etc.
Like I said earlier, this might be going overboard, but it could cause good discussion.

Community Voting
This I feel should be implemented. The players on the server each get to vote on a certain category such as time acceleration. This is how I picture it working:
One person calls a vote to time accelerate 10x for 3 seconds. Everyone can now see the vote, and they have the ability to A) accept or B) decline. Depending on the server, the number of votes will determine if it is passed or not. The number of votes needed to pass could be majority, 2/3ds, or unanimous.

Pros to a Hierarchy
Allows for power control/server limits
Cons to a Hierarchy
Easily abused



Time
This is probably one of the most pressing issues for a multiplayer version of Orbiter: How to handle time acceleration.

No Time Acceleration
This would be the most drastic choice. This is saying that Orbiters time acceleration ability would be cut, just leaving time to run at its normal pace. This poses an obvious problem: How would I get to Jupiter? The answer is to wait 10 years, or get a very powerful ship. Neither of those are fun, so this option would restrict us to an Earth-Moon system. The benefit however: The players could be off-line for a significant amount of time without worrying about random time accelerations.

Shared Time
This is face’s idea. This whole concept belongs to him.
This idea is confusing at first, but I feel it offers the most viable solution: When a player joins for the first time, he is synchronized with the Server Time. If the player wishes to time accelerate, he/she would receive a message saying “you are going to go out of sync with the server time. Are you sure you wish to do this,” or something to that effect. If the user wishes to do so, then he will be “split” from the server time and enter his own universe with separate planets, separate ISS, separate bases, etc. Other player’s information would not be sent to his computer.

Other players can choose to synchronize with another users time, so in effect, sharing time. While they’re may be 100 people on the server, 3 could be in one time, 5 could be in another, 77 could be in the master. The idea is that this way, groups of people who are docked to the Deepstar, or some interplanetary ship, could all get together and go to Jupiter and be back in time for dinner, while some others could be doing a demonstration on how to properly dock with the station. The “creator” of the new time would be the “administrator” of it, allowing him to speed up/slow down time at his will. The “admin” could abuse it, or he/she could be responsible and ask others. If there is abuse, the solution is simple: separate from the bubble.

Now, lets say I build a base on the moon, and Billy Bob Joe runs the server…what happens to my moon base? If I leave that time, does my base go away? I think the Billy Bob Joe should have the option to sync “my” time with his at any point, which would take all my objects, debris, everything I have done, and put it with the main server. However, this is the only time where bases and non-self ships could be “transferred” from one time to another. Also, I think I should have the ability to make a “bookmark” of my time, so that even if I jump to the Master time, I have the ability to come back to “my time” so all my work is still there.


These are the two major ones I could come up with; I’d love to hear other’s opinions on this.


Technology
This, combined with an economy, would turn Orbiter into an “MMORPG”, and not just an online server.

Concept
The basic concept is simple: Based on several variables, some being sheer time playing, resources, dedication, etc., “technology” could be available to certain individuals/companies. This technology could be used to build more advanced ships (almost like “leveling up”), FTL, moon bases, etc.

Types of Technology
I think that the type of Technology that should be available range from more efficient engines to different systems to full-blown FTL ships. Examples of this, I think, are:
Engine Types
F1 (least efficient)
F2
F3
F4
F5 (most efficient)
Fuel Types
Hydrazine (least efficient)
Kerosene/LOX
H2/LOX (Most efficient)
--We will need more, but these are all I can come up with at the moment
MFD’s
Basic/Tech 1 (Stock MFD’s)
Tech 2 (Aerobrake/Basesync MFD)
Tech 3 (IMFD/TransX)
Tech 4 (LaunchMFD)
--We will need more, but these are all I can come up with at the moment
Heat Shield
Basic/Tech 1 (Need a near perfect re-entry to survive)
Tech 2 (more of the ship is covered in high-heat tolerant materials)
Tech 3 (nearly all of the ship is covered in high-heat tolerant materials)
--There would be more, but this is just the basic layout

The list could go on and on. I’m interested to see what you all could add to this list

How to increase Technology
This may be the most complex part of this Technology system: How are you going to define/research new technology?

I honestly have no ideas on this, so this is open to discussion

Pros of having Technology
Adds to the realism of Orbiter
Can provoke interesting competitions
Cons of having Technology
Creates a rift between the strong and the weak.


Re-write or current
Obviously, some of these ideas aren't currently supported by Orbiter. I think that an Online version of Orbiter should have a separate exe, but use the core of orbiter. By having a separate exe, time sync with the master server and ship choosing could be much more easy and simple. Plus, There's the added benefit of not having to modify the Original launch pad


Feel free to shoot down/support/modify any of my ideas!
~Kaito

 

[Kveldulf]

--Stuff on Time Accel--

Just my two cents on these points, as this is the biggest hangup for me.

Removing Time Acceleration solves part of the problem, but then also creates another one. This being that everything takes a long time to do. Even docking with ISS would take several hours. Sure, I could always disconnect, and come back when I have more time, but this creates two problems:

1) If my ship is still rendered, then we have an unmanned projectile, possibly heading directly for a station, as well as the players who are docking, undocking, or doing other assorted activities in the area.

2) If my ship dissapears, then depending on where I am in the procedures for rendezvous, I could have wasted fuel performing all of the burns, based on my reaching the station at a given time. If my position is still calculated by the server (but my ship isn't actually displayed), the problem would be returning after my intercept, at which point I have to calculate another intercept time, and use more fuel to reach that one. If the position is not calculated... well, its the same as above, except I would most likely have to plot another intercept, regardless of when I come back.

The Time Bubble idea is interesting, but it then also raises the question of what happens when the server side time catches up to the various "bubbles"? Say for instance... there was an expedition to the Moon, and the ships have returned, and docked at ISS, in its own bubble. Say... 2 minutes before the master server catches up with the bubble time, I'm approaching a docking port that is occupied by a ship in the bubble. What would happen when the times sync up then? Unless the server starts to send warnings explaining that ships will start appearing, I'd be under the impression that the docking port is empty, until the ship appears that is.

Another option would be to not have the ships appear in their exact position, but instead, have them appear... say 10km away. But without the server being smart enough to check the vessel states, we could have ships being automatically undocked, and moved away, but they could have the airlocks open, killing the crew instantly. This would also be problematic for stations under construction, as the construction crew suddenly finds themselves far away from the station.

I suppose it would be possible for a server admin or a mod (should they be used) to have control about what is carried over, but you'd need enough info to be able to avoid situations like I listed above. But then what happens to the people that dont get carried over? Do they just "poof" somewhere else?

The final option would be to not allow the bubbles to sinc back with the master server, but at that point, doesn't a master server become pointless? You'd be better off just sticking with small servers, with a few players all heading the same direction.

 

[Brycesv1]

the technology could maybe not be "researched" but baught and equipted on the open amrket depending on pilot accomplishments (read EXP). so if a pilot flies a lot and has done amny things he could earn license to purchase (with ingame money) and use more advanced tech.

for time maybe a cryo stasis type tech could be implimented though i dont know how this fits into the "near future tech". a player buys the cryo equipment with a basic license (maybe a few simple earth to LEO missions for enough EXP) and then gets an MFD for cryostasis. the pilot enteres the time that he would be in cryostasis and engages it (because he would not be able to control it if he was frozen). this is basically a personalised time acceleration. at that point the game calculates how much of various resources would be needed for the duration and give a warning if anything would reach dangerously low levels though the pilot could ignore this warning if he would be unfrozen right before a reentry to resupply. it would also calculate the player position after the cryo state has ended. after the cryo state has begun you simply have a warp effect and fade to a blue icy texture around the edges of the screen.

im short on time so i havnt thought it through. a problem would be planet and other playe positions after the cryo stasis has ended since time would have only been accelerated for one person... il think more later. any thoughts?

 

[Kaito]

Server side time catches up to the various "bubbles"?

The personal time bubbles would continue to run, just in a different time. So if I jumped 6 days ahead of the Master Server, I'd continue to run in time, just 6 days ahead. And, lets say the stars aligned (heh, that'd be a funny mod...ANYWAY) and two bubbles had the same time. I dont think they would "sync" then, they would just happen to have the same time. Until you physically tell the server to sync with another time, you're on your own

the technology could maybe not be "researched" but baught and equipted on the open amrket depending on pilot accomplishments (read EXP). so if a pilot flies a lot and has done amny things he could earn license to purchase (with ingame money) and use more advanced tech.

for time maybe a cryo stasis type tech could be implimented though i dont know how this fits into the "near future tech". a player buys the cryo equipment with a basic license (maybe a few simple earth to LEO missions for enough EXP) and then gets an MFD for cryostasis. the pilot enteres the time that he would be in cryostasis and engages it (because he would not be able to control it if he was frozen). this is basically a personalised time acceleration. at that point the game calculates how much of various resources would be needed for the duration and give a warning if anything would reach dangerously low levels though the pilot could ignore this warning if he would be unfrozen right before a reentry to resupply. it would also calculate the player position after the cryo state has ended. after the cryo state has begun you simply have a warp effect.

im short on time so i havnt thought it through. a problem would be planet and other playe positions after the cryo stasis has ended since time would have only been accelerated for one person... il think more later. any thoughts?

Cryo Stasis: Good for human trips, but how does that solve the multiple person time acceleration problem?
My vision of this is to have minimal NPC interaction, so buying technology from NPC's seems odd. You could purchase, say, blueprints from other companies, which could be a form of "buying" technology...

 

[Brycesv1]

thats what i was thinking. sorry i didnt make that clear. the actual tech would come from whatever play run company made said tec. the license to be able to use such tech would come from the server when it thinks you have enough EXP. however much that may be.

 

[Kaito]

thats what i was thinking. sorry i didnt make that clear. the actual tech would come from whatever play run company made said tec. the license to be able to use such tech would come from the server when it thinks you have enough EXP. however much that may be.

Right. Now, how would you gain EXP?
I'll think about this some more, maybe add another long post with the idea of Ships, Company Types, how you would gain tech, etc

 

[Urwumpe]

I could maybe deliver something about the XP, Tech and other low level stuff, I have some basic design work done for a similar RPG, but instead of being based on Orbiter, I wanted to make it stand-alone. And with theoretically feasible tech.