Working Multiplayer Proof of Concept with video proof [No Longer In Production]

[SolarLiner]

The biggest problem is the floating point/kraken, which I don't even fully understand, but at least I know timewarp isn't an issue.

Unity uses floats for the the transform values handling. A floating point precision number allows less and less precision on the decimal side to let bigger number stored. So the farthest you go from the center, the less precise the number will get. And then arrives the point where you don't have enough precision to precisely hold pieces together; they "detaches" from the ship. Deep Space Kraken has waken up for ya.

To put this into perspective, let say you have a random position vector with X=150.052713635694. Really precise number, right? Now let's go and leave the solar system. Your X position will grow to big numbers, and arrives as X=2984135412384.25; which is only a 2-digits decimal number, compared to the first one.

Now, to return to the multiplayer discussion here, let me quote an other post I wrote on it (and sorry to bring timewarp problems here):

The first thing to do is add a tag on the server to control the mods needed. You will need all the mods requied to enter. And you will not be able to use other mods to play in multiplayer. Then you will be able to show all aircrafts in the visual range (with physics disabled it will save a lot of FPS for other's big object) and without mod compatibility because everyone will have the same configuration.

But how to actually see each other, internet-wise? Update cycles will come every 1/2 or 1 second. Sent data will contain reference body, orbital parameters, thrust percent, attitude and angular velocity. Thrust and angular velocity will come for the "continuous movement", ie when there is no data, the craft will follow these current parameters to predict next position on the render frame.

Now comes the problems: first collisions. Collision will be handled by the game itself. That's right, then we "resync" the debris. That can cause problems with trollers who will kamikaze into other's stations. The owner can choose to force the object to go on-rails. Danny2462's researches proved that collision is disabled when on rails. Docking too, so be sure to disable the on-rails "hack" before contact.

BTW, docking is the second problem. The way KSP works is by merging ships into one. I may have to find a "hack" for that but that's an other option on the object: let docks or not, and to what users. That way you will blame only yourself if something bad happens to the station

But the most known problem to multiplayer is time warp. The ship will disappear from other players when time wrapped. When returned to x1, its position will be changed to fit the result of the time-warp. If it has an encounter, the orbit will be moved for everyone to see the encounter properly.

Now, there is still some things to implement. Event triggers will be sent immediately: stage activation, action triggers, deployment of landing gear, EVAs, etc...

Now, I only speak in theorical, as I don't have looked completely in the KSP API yet, and I may not have the right skills for all that. But I think it is a great, structured idea I have for KSP MultiPlayer. I'll be proud if I can help anyone in the process of making such an addon, and if this mod com to everyone's life, it'll be a complete game changer.

[swiftgates24]

Ah, thank you for explaining. And the reason I don't like ideas on timewarp, is because it is already solved.

Quote from that thread:

- You will be able to timewarp like usual! You will start at a server time (Which counts in realtime, like the usual singleplayer KSP time does when timewarp isn't activated) launching your vessel,

when you timewarp you will go faster than the server time, when going back to the Space Center your time will be set to the server time again.

- Your timewarped flights are "recorded" on a log (The name of this project comes from this).

- The server now shows everyone your vessel doing everything like you did with timewarp, but without. For example, if you do a mission to Laythe, and it needs 30 mins. in realtime, but it takes 400 days in timewarped time, other players will see your ship cruise for 400 days in realtime!

- Of course, because noone wants to wait for 400 days, the server time will be updated to the highest vessel-time when noone is controlling a vessel. (Spacecenter, VAB, SPH, Telescope or just offline)

- When you timewarped and another player does something in realtime (or maybe in timewarp-time, too, but lower than yours) you will see his future position at your point of time updated for every burn he does. You will see a sign above his vessel when he does a burn so you know that the course he has on your map will not stay the same.

Edited August 30, 2013 by swiftgates24

[oggylt]

Interesting mod you have going here. I'm wondering how you're going to fix the deep space kraken and other errors associated with being far from the center of the in game universe.

I would say why bother having 1 shared universe, instead each client is center of his own universe and problem solved

[Pwolf]

That's sort of how it is already and why there is a problem to begin with... How do you determine where client A is in client B's universe without having a universal reference point?

[gl0ryh0und]

Forgive me for keeping this alive, but how is the disposition of heavenly bodies handled? Ships aren't the only things moving and frames of reference to planetary bodies from your point of origin will vary from person to person. This solution in my humble opinion is flawed and unworkable.. so it either ignores other player's frames of reference and planetary disposition or is only a visual representation of other player's apparent movements. You would get something similar to what you see in the KLF mod, not at all 'multiplayer' but a nice social addition. In addition cranking the server time back or forth to adjust the position of planets to syncronize client times would have dire affects on ships in deep space. I think the problem of full space program immersion from multiple players is still not solved.

[Tw1]

Ah, thank you for explaining. And the reason I don't like ideas on timewarp, is because it is already solved.

One problem with the update time theory, is it would mess up any transfer windows that other players had planed.

Solar liner's idea, where it updates the orbit of other players, relative to the body they have an encounter with, sounds like a better solution.

One thing I was wondering, would it be possible to just not load a missing mod part, and have a gap where it would be? Only the other parts, arranged as they are on that player's computer would be shown. Or would that not be feasible?

[SolarLiner]

One thing I was wondering, would it be possible to just not load a missing mod part, and have a gap where it would be? Only the other parts, arranged as they are on that player's computer would be shown. Or would that not be feasible?

Well, if other parts are attached to it, it might cause problems. Or maybe if there's something to get global part position ... but then we will quickly arrive at a few hundreds of kb/s for large ships.

[Faark]

One thing I was wondering, would it be possible to just not load a missing mod part, and have a gap where it would be? Only the other parts, arranged as they are on that player's computer would be shown. Or would that not be feasible?

"Primitive" mod parts are not really a big issues, since you can already check on connecting that the client has all necessary mods. Yes, you could also try to generate a part at runtime. But that isn't easy, especially when there are multiple parts missing. And, well... for some part packages you might not have any parts left all

We should start with a "you miss mods [...]", preferable with a spaceport link. Maybe even some kind of automatic download & if possible Mp-Only-Install/-Loading.

[swiftgates24]

One thing I was wondering, would it be possible to just not load a missing mod part, and have a gap where it would be? Only the other parts, arranged as they are on that player's computer would be shown. Or would that not be feasible?

But what if someone was to make a whole mod ship...that would be...kinda invisible?

[Tw1]

But what if someone was to make a whole mod ship...that would be...kinda invisible?

Kerbal space program, stealth mode!

What inspired my suggestion, was one time when I had too much delta-V in a booster, I turned around to eliminate it with the lasers, as some parts blew up, other parts kept floating in position.

The same thing happened on Kerbin too, when I was clearing up debris at KSC.

I recon such a system would work best along with having several of the most common mod parts loaded, to reduce the chance of invisible ships. If such a system is even possible, that is.

Edited August 31, 2013 by Tw1

[frizzank]

Why not keep the position transform client side?

The other players accuracy doesn't matter until they get close to you anyways. If they are on another planet you cant see them except for the map view so being off by as much as a meter wouldn't even matter.

Kerbal Live feed is an interesting way to solve miss matches between players and time warps. It looks a little odd on the map screen when someone else time warps but who cares.

http://forum.kerbalspaceprogram.com/showthread.php/24926-0-21-Kerbal-LiveFeed-Passive-Multiplayer-Plugin-Client-Server-v0-7-1

Actually if you could just take the same thing they did and make the other players ships are visible when I get within 2.5km them that would work just fine for me.

Don't worry about collision, docking, mods or time-warps for now. Just focus on the larger picture, and ignore everything everyone else says. Including me. Your doing a great job.

Edited August 31, 2013 by frizzank

[Talisar]

Just focus on the larger picture, and ignore everything everyone else says. Including me. Your doing a great job.

This may be the best piece of encouragement I've ever seen given to someone!

[Blaylock1988]

I agree 100% with frizzank.

[Pwolf]

I'm pushing my mathematical skills here but if anyone else can back me up on this, that would be awesome:

So, I've been thinking about the position issue for the past few days. Basically the origin shift ensures that there's no way to, for sure, know exactly where any one vessel, other than your own, will be placed in space. This creates a big problem for multiplayer. For larger distances, this doesn't matter so much as the local client doesn't need an accurate position of a vessel if it can't see it anyway. This can be solved using existing techniques that have already been used in other mods (KSP Live Feed for example). For shorter distances within the visual zone, this doesn't work... However:

If you have a starting point/vector, a distance, and an angle, you can find an end point/vector. My thought is, if I use the nearest celestial body, or orbiting body, (within a threshold so that the kraken doesn't cause an issue) as a reference point I can use the distance between the body and the vessel as well as an angle to the vessel to find it's position on another client. I'd send the distance and angle (Euler angle?) to the server along with other vessel information. When another client within visual distance renders the position of the vessel it will use the position of it's local body and the distance/angle of the vessel to find out what that vessels position is in relation to the current offset. Does any of that make sense?

Does anyone know how to actually calculate this? lol. I know you can do this in 2D with relative ease (iirc):

x2 = x1 + cos(angle)*distance

y2 = y1 + sin(angle)*distance

(i think that's right)

How does this work in 3d space?

[Faark]

Sry, i don't really get it... what is the exact problem? I wouldn't really care about having vessels in 2 different SOI's for now. Not sure if the stock game does handle this case at all^^

And as long as you are in the same SOI, you can use the vessels position. You current screen always have one as a reference, as well. For example here you have some of my research code. It teleports the active vessel 5km next to the targeted vessel:

var trgPos = FlightGlobals.fetch.VesselTarget.GetOrbitDriver().orbit.getPositionAtUT(Planetarium.GetUniversalTime());
var curPos = FlightGlobals.ActiveVessel.orbitDriver.orbit.getPositionAtUT(Planetarium.GetUniversalTime());
var safeDist = ((curPos - trgPos).normalized * 5000);
var jmpTrg = trgPos + safeDist;
var jmpDist = jmpTrg - curPos;
FlightGlobals.ActiveVessel.SetPosition(jmpDist - FlightGlobals.ActiveVessel.transform.position);

So you are definitively somewhat aware of other nearby vessels. The code isn't perfectly accurate, it for example would be a good idea to make sure those positions are not outdated, already. But using relative positions might even make it worse^^

[Captain Sierra]

OKay, might as well add my two cents worth for Time warp. Say f*** time warp. Allow users to time warp but have it only effect them. Yes, it would result in unrealistic 'warp jumps' but still, you have working MP. The video seemed to show transmission of positional, rotational, and trajectory data. This incoming data would not be effected if time warp data was not sent.

The only way I can see MP working with time warp is a two mode approach.

Mode 1, semi-sync:

allows time warp. Craft position, rotation, and trajectory data is sent. Physics is only calculated by the owner of craft and is only present in his save. Ships cannot interact or collide but can be viewed in map and flight view.

Mode 2, full sync:

time warp dissallowed, can be switched to in flight but all players must agree. Physics calculated by all players and ships can interact and collide and dock. Great for co-op space station assembly.

The idea HERE is that you get the best of both, you don't overload computers, and you get a massive new level of depth.

[Pwolf]

Faark:

Is the origin always the same within a SOI?

[OrbitusII]

The origin is an (sometimes not so) arbitrary point, (0,0,0), that is used as the main reference frame for the entire scene. The parent body can be used as the reference frame by using some easy vector math, and by extension a vessel can be used as a reference frame for others.

So, to answer your question, yes and no. It simplifies calculations a lot to keep the reference frame as the same object, e.g. the parent body (yes), but you could very well have a random number generator coming up with a new reference frame every frame (no).

------------------------------------------------------------------------------------

This is a very promising project, I can't wait to see it in action with my own eyes!

[Faark]

Yes, all orbital calculations within the same SOI use the same origin (center of SOI? haven't checked it). The problem are loaded vessels. Their positions aren't calculated but tracked from Unitys game & physics engine. The engine apparently can't handle large values very well (origin offsets as well as speeds), thats why they use a different reference frame, with a center close to the current vessel. Orbit.Pos / Orbit.Vel should be the latest tracked values and therefor be a good start to work with...

[Itsdavyjones]

Keep up the work. Would love to see this up and running.

[Metapher]

I dont mod, and iam a bad programmer, but heres my opinion about the synchro problem (and excuse my english-german-mixed-grammar):

Whats in my head about positions:

What your mod needs to force, is a 0-State.

A time where the game starts in an initial state, where every position, rotation/angle, blah blah, from every object is set from a startvariable.

Also every ship on the launchpad has always a same startposition, ALWAYS. Because you defined this position by placing it in the VAB

So even when the game started a while ago, we could recalculate the startposition of the ship, like it would be placed on the launchpad right at the moment of game-initialisation.

With these informations (6-axis + 3 angles) of the "0-State" of every vessel, we are able to calculate the same position for every other user from the actual position.

(Where is the launchpad now -> where would have it been at 0-State -> calculated difference)

All the clients needs to know are the 0-States as fixed variables and the real-time "Now-State". The rest should be highschool mathematics, since KSP doenst use n-body-problematics.

[Smoovious]

the main problem still is "what happens when you timewarp"

that has been and always will be the sticking point both technically and design wise.

Well, if you're able to override timewarping, you could end up implementing it as a lesser of everyone's setting...

So if you have 3 people, one is set to 100x, another to 20x, and a 3rd to 10x, then all three would go 10x... then as the slowest one, speeds up after his maneuver, setting his to 50x, then all three would go 20x, as the 2nd player's warp setting is now the lowest.

-- Smoov

(ps: I'm new. o/ )

edit: Ok, I posted that early on in the thread.

From what I've observed, the problem with multiplayer in KSP isn't very different to some behavior I see in another sim I play. (Run8, a multiplayer railroad simulator)

In Run8, each client handles the physics for their own train only, and everyone else's trains just share positional data. The plus side is that it lowers the computational load on each client's computer. The down side, is that we always have sync issues. One person's train that I see on my screen, may not be precisely accurate, as it may be shown a few feet ahead or behind, on another person's screen.

When we're doing some yard switching cooperatively (one engineer, one conductor), we have from time to time, thrown a switch when we saw the last car clear the switch, but on someone else's computer, the last car hasn't cleared it yet, and the thrown switch, makes the car split the switch and go down 2 tracks at the same time.

This also becomes an issue, when one engineer, is picking up cars left from another engineer's train, and they're backing up to couple, and it may look to me like their couplers are perfectly lined up, while on their screen they still have another 10 feet of space to go, so even tho I tell him he's there, his physics (since he's in control of the train) disagree.

I see this as a problem caused by the way they implemented multiplayer from the ground up, and I don't see anything they can do, to get rid of it completely, unless they change the way multiplayer is implemented from the ground up. Since they aren't truly sync'd up, we often don't see the same thing as each other. Different vehicle traffic on the grade crossings being the most obvious.

Another game I've played, is OpenTTD... and while it isn't a sim in any sense of the word, the way it implements multiplayer, locks everyone up to seeing the exact same thing at all times. It uses nonces and seeded random number generators, and instead of exchanging positional data of our vehicles, it just exchanges the commands between the server, which in turn, passes them onto the rest of the clients, so all of the clients know to apply that command at the specified nonce. All random numbers are generated with the same seed based on the nonce, so we all end up seeing the same exact thing.

Again, there is an upside and a downside. Upside is, everything stays in sync, and everything is in the same exact position on everyone's screen. Downside is, that everyone has to compute everything for themselves, increasing the processor load. There would also be some lag-time between when you moved a control, and when you see the effects, but that could also be realistic too. Also, this isn't a sim, but a transportation-related game, so there is no real freedom of movement to begin with, but the principle still applies.

In Run8, if they switched to the nonce/seed method, then the clients would pass along the commands to the server instead of positional data. Throttle position changes, brake handle/pressure changes, etc. Then, assuming everything else stayed properly sync'd, every piece of rolling stock would be in the same exact place on the track, no matter which player's screen it is being viewed from. This would also allow us to kick cars (something that we really want, but just isn't possible with the current networking method. When we pick up and drop off cars, they are added/removed from our single train object, which sounds like it is similar to how KSP treats the joined pieces all as one object)

So... since KSP wasn't designed with multi-player in mind, I don't think having that kind of precise interaction is very possible. We may have to accept being able to work near each other, without being able to couple up our pieces together. Even if that's all we can do, that would be HUGE, and I think it should still be tried.

Last thought... is it even possible in KSP, to position objects, and keep updating their position, while ignoring physics on the non-host computer? (host being the one that is actually controlling the craft)

-- Smoov

Edited September 3, 2013 by Smoovious
finished reading the whole thread :P

[Faark]

The rest should be highschool mathematics, since KSP doenst use n-body-problematics.

Actually, your "highschool mathematics" is exactly the problem. There are ambitious documents out there on how games like Counter Strike make sure your bullet actually hit the moving opponents head. I don't want to end up rewriting large parts of KSPs game engine.

You want an example? Fine! Here are some 8 second old data about an vessel entering kerbins atmosphere: position_vector (about 40km above ground), rotation, velocity_vector (about 4km/s). And once you calculated that, you have to manage a smooth transition from the current pos/rot/vel to match your calculation result. Ofc you have to do sth like this for every kind of game situation...

Last thought... is it even possible in KSP, to position objects, and keep updating their position, while ignoring physics on the non-host computer? (host being the one that is actually controlling the craft)

Yes, i think it is. But you want some kind of physics, to calculate changes to the vessel without transmitting & updating its data every frame.

Getting out of sync isn't a that big problem in KSP i hope, since you basically only push changes to your own vessel to the server while "playing" records from all others.

[Drognoid]

Couldn't you just leave the multiplayer aspect to focus only on kerbin? My only real plans with multiplayer would utilize the spaceplane hanger, and timewarp? couldn't a jump to SOI feature or a jump to rendezvous...

Also multiple players on the server could cause the need for some hefty hardware for the server, KSP throws a CPU hogging fit when the part count exceeds 250. Having 4-5 players near each-other (close enough that physics is loaded for everyone) could render the sever into a molten pool of expensive metals

[Smoovious]

Yes, i think it is. But you want some kind of physics, to calculate changes to the vessel without transmitting & updating its data every frame.

Getting out of sync isn't a that big problem in KSP i hope, since you basically only push changes to your own vessel to the server while "playing" records from all others./QUOTE]Well, only one computer (the host) should be working out the physics. If you insist on the client computers working out the physics too, then you may get into situations where the client computer and the host computer are trying to apply physics to both vehicles, from different positions.

With the host computer already working out the physics, and sending position data, the client computer can just smooth out the old/new positions in between updates.

Yeah, it would take bandwidth, but you're going to have to do it anyways. Shouldn't be that much bandwidth tho, and it all depends on how many updates per second you're sending too.

-- Smoov