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

[nothke]

lol, I've seen the beginning of the discussion a week ago, and the end now, and it's all about timewarp xD

The only thing I'd like multiplayer for, and for what I think it is only useful, is the same thing as seen in the first video. Being able to build a base/station together, formation fly, drive around/roleplay in Kerbin City perhaps, all in a physical range.. If you want to have one player around Jool and one around Kerbin communicate is what you already have now through Kerbal Livefeed.

[shand]

Faark - its much easier to just make a throw away statement that you could do it than to do it

Nothke - actually the OP has referenced some interesting ideas about how to make timewarp not a problem, especially on small scale servers (me and my mate, rather than the whole world). And various enhancements could make those ideas better still once he gets to the stage of testing them.

My first post in this thread was of the nature of "hmm you'll still have to deal with timewarp so this could all be in vane", but i reckon the OP will be able to deal with timewarp well enough when he gets there

But as he's said before, its irrelivent if you cant even do live play. once live play is sorted to a satisfactory level then timewarp can be dealt with.

[IndieDev3D]

I deleted my comment because it was replying to your comment which you deleted and was therefore out of context and wouldn't make sense.

In reply to your last comment:

Fine, but nobody was saying he deserved more praise then the praise for the entire game - that could only be implied from the original comment you quoted if you completely ignored the context. IE: the fact this is a topic about a multiplayer mod, where someone is trying to make MP work despite everybody says its impossible.

And you are still saying that making MP in unity is really easy, which is a tad rude, and very unhelpful.

PS: your website doesn't work - i was hoping to look you up and admire your handwork (out of genuine curiousity - i like clicking links in sigs) but... i can't

Yeah I noticed that it stopped working today, weird, and yes I was only reffering to the original comment, which is how this war started, anyway...

[FEichinger]

Hello there

Just a reminder: Please refrain from talking about removed posts. They were removed for a reason - no matter who removed them - and pushing them into the discussion yet again is not constructive at all. I'm not gonna go through the posts and purge it, but I'm closely watching and I will take action if this warning ends up insufficient.

FEichinger

[shand]

Aye FEichinger

As a rule i tend not to delete posts unless they were responses to a post that was itself deleted, or unless nobody has seen it. otherwise it just disjoints the discussion. I'm more inclined to throw an edit and put a "this is all rubbish" or something at the end when i'm wrong.

Anyway: finally back on topic!

PWolf, have you managed to sync during burns? i imagine thats the next step? are you thinking of the client updating during the burn (presumably thers a limit to the frequency of updates which will effect how smooth the transitions are? and will another client see the engines burning?

(^^All said knowing this is only a hobby so there really is no hurry, just curious as to how you are planning on dealing with this )

[Pwolf]

PWolf, have you managed to sync during burns? i imagine thats the next step? are you thinking of the client updating during the burn (presumably thers a limit to the frequency of updates which will effect how smooth the transitions are? and will another client see the engines burning?

My current way of "syncing" is to run a game clock on the server, which is basically a stopwatch that counts up with millisecond precision. When a client connects, it syncs it's game clock (Planetarium.SetUniversalTime()) based on the artificial game clock from the server. This does a decent job but it's not great. It at least lets me test positioning a bit more accurately.

That said, I still haven't found a way to actually programmatically position a vessel (without relying on forces). Simply setting the position using Vessel.SetPosition() doesn't seem to work (nor does any other position related attribute or method I've tested). It just wants to sit there at the same distance away from the active vessel. RCSing towards it doesn't do anything. However, if I burn towards the other client, I'll eventually move towards it but very slowly. It's a very interesting behavior and I'm not sure why it's happening.

I haven't had a whole lot of time to troubleshoot it. Everything looks like it's in working order: the position is being sent to the server and the client is getting it as well as it looks like it's being set on the other vessel correctly. I haven't had a whole lot of time/motivation to really tackle it the past week (sort of burned myself out working on everything that got me to the video I posted... also did a lot of the coding for the server/client while at work during breaks since it didn't require me to actually open KSP >.>).

[meve12]

Have you tried and looked at the map view while a burn is underway? Are both vehicles moving when the burn occurs?

[triffid_hunter]

I can't for the life of me remember where I saw this idea and so can't credit its original author, but it's the most sensible one I've seen yet:

(not quoted verbatim, just my own wording of the idea itself)

Each player can warp to their heart's content and their game keeps track of time since joining the server.

If two (or more) players wish to interact, they must first synchronise their times. This involves the player who's behind catching up, probably using a 'sync with this player' button which will apply an appropriate amount of warp.

This solves the issue of players warping hard on interplanetary missions, and also solves time stopping while mucking around in the VAB. It also solves the issue of having all the planets and moons in the right place while doing transfers.

You might also like to consider forcing Stations to stay on rails, so players can dock with them. You would of course need to synchronise times to see other players' ships at the station, and batten down the hatches for total CPU meltdown if they've docked a behemoth

Map icons would be managed ala KSP live I suppose, I haven't used it myself but presume they have something relatively sensible?

[Pwolf]

Have you tried and looked at the map view while a burn is underway? Are both vehicles moving when the burn occurs?

I have not looked at it closely under the map view. The orbit information is changing as expected and syncing correctly though.

[SolarLiner]

Speaking of stations, how dock will be handled? It presume ownership transfer, as you can control all the parts (and the previously docked ships) of the station.

[Pwolf]

Not even going to think about that right now

[kmarht]

I dont think warp would be to hard to solve at least as a concept, in a game like this with no points or competition you could have the clients exhibit a strong trust of each other, so say player 2 hits warp and "desyncs" from player 1 sort of disappearing from their view of the world, they come back out of warp, the clients resync and the players reappear to each other, at least it sounds good to me from a non programmer standpoint.

edit: planet positions might be a big issue though

[inaBizzel]

The first thing I thought of regarding warping was making it client only. Players can warp freely and to other players around them, they look like they are just travelling extremely fast. You could disable warping when players get within 1000 metres of each other. Seems like a pretty obvious solution to me. Maybe there are engine limitations I don't know.

[Tangle]

I'm pretty sure eventually you could have a server directory and you choose the type of mission you want and if there's a server close to starting, you could do one mission with each of your own vessels and when the last vessel is up you all wait for your transfer(time warping would be allowed as each vehicle would wait approximately the same time), then transfer, then timewarp with a fine-tuning opportunity, then you arrive for aerobraking/retrograde burn and then burn retro to land(unless you've decided for a direct descent after aerobraking/retro burn), and at this point you can phys warp x4, and when you reach the slowdown burn altitude you have to go down to 2 or 3, then you continue to the surface at x2 or just normal speed.

[Stuntaneous]

Given what you now know, how would you go about attempting the separate problem of keeping remote areas simulating? I imagine you may've stepped into that realm with this task.

[eschybach]

First of all to everyone in this thread - I am sick of hearing about timewarp. STOP.

Second of all, I am no computer programmer, so forgive me (and by all means, correct me!) if any or all of this is way off basis.

Would it be possible to use telemetry data (such as data from Telemachus) to send positioning data back and forth between the two clients? It would be a scenario where each ship had to have a part active on the ship to send the data (as such these would be the only ships represented and seen by clients), the server ran the world clock, and each client ran an identical save. The saves would be updated according to the telemetry data (and at startup and close) and sent back and forth. Would this work or am I missing something in regards to the positional data being focused on a single ship?

For ships further away or in a different SOI, I know there's another MP plugin out there that shows ships in map view regardless of SOI and does a pretty good job updating. Maybe implementing whatever they used as well? As well, ships that are further away don't need constant updating which would free up processing. And with the Telemachus style of calculating, anything that isn't actively being controlled just returns to rails again to save on calculations.

Of course there are many other synchrosity/ownership issues such as docking, targeting, collisions, and part rendering/representation which I'm sure all come later.

How off am I? Any of that good?

[Silicon014]

Maybe you could implement a consent system for timewarp. Whenever someone needs to go to timewarp, it sends out a consent message to all multiplayer users, asking them if it is okay to go to a certain timewarp factor

[nubeees]

Any chance of us getting another progress video? :3

Good job so far by the way, keep up the good work! I really do hope this doesn't die out like all the rest of the threads on this topic!

[Exsmelliarmus]

How about we agree to STOP talking about timewarp on this thread AT LEAST until we we have a definitive understanding on how non-timewarp multiplayer will work. It would make figuring out what IS an update, or a new development, as opposed to more timewarp talk, much easier. Or, alternatively, have a look through at least one timewarp thread, or even this thread, and if it has already been posted, don't post the idea again, even if you came up with it yourself, then discovered others had already talked about it. Sorry to come across harsh, but the OP is making actual progress, while we are merely rehashing the same ideas over and over and over and over again.

OP, keep doing what you're doing. One question, are the two computers talking directly to one another, or going through a server to access world time, position etc?

Edited September 8, 2013 by Exsmelliarmus

[SolarLiner]

I am sick of hearing about timewarp. STOP.

How about we agree to STOP talking about timewarp on this thread AT LEAST until we we have a definitive understanding on how non-timewarp multiplayer will work. It would make figuring out what IS an update, or a new development, as opposed to more timewarp talk, much easier. Or, alternatively, have a look through at least one timewarp thread, or even this thread, and if it has already been posted, don't post it. Sorry to come across harsh, but the OP is making actual progress, while we are merely rehashing the same ideas over and over and over and over again.

True. Timewarp is NOT the main issue here, so let's progress step by step. Timewarp will come WHEN and only when we will have a powerful, lightweight and reliable system to sync everyone in a multiplayer server.

Second of all, I am no computer programmer, so forgive me (and by all means, correct me!) if any or all of this is way off basis.

Would it be possible to use telemetry data (such as data from Telemachus) to send positioning data back and forth between the two clients? It would be a scenario where each ship had to have a part active on the ship to send the data (as such these would be the only ships represented and seen by clients), the server ran the world clock, and each client ran an identical save. The saves would be updated according to the telemetry data (and at startup and close) and sent back and forth. Would this work or am I missing something in regards to the positional data being focused on a single ship?

That's basically the method. You run a shared universe where your client only calculates for your ships, the rest being downloaded realtime by the MP plugin. The only thing is that we can't constantly update the save file and load in in KSP; it takes too much time (try to quicksave and reload that quicksave 8 times a second) for KSP to reload everything (because that's how it works). But you can directly "teleport" objects and crafts to new locations, and update orientation according to what the server tells us.

For ships further away or in a different SOI, I know there's another MP plugin out there that shows ships in map view regardless of SOI and does a pretty good job updating. Maybe implementing whatever they used as well? As well, ships that are further away don't need constant updating which would free up processing. And with the Telemachus style of calculating, anything that isn't actively being controlled just returns to rails again to save on calculations.

Of course there are many other synchronicity/ownership issues such as docking, targeting, collisions, and part rendering/representation which I'm sure all come later.

What we can do for Other SOI ships is just show their rough positions and path on the map. You only need the craft itself and more accurate positioning when you get closer to it, or you focus on it.

[Pwolf]

Any chance of us getting another progress video? :3

As mentioned earlier, I haven't had a lot of time/motivation to work on this. I've burned myself out a bit. The last few weeks have been pretty busy in general for me as well. That said, there hasn't been very much progress at all. I tried to tackle the positioning but it hasn't worked out very well. Going on a bit of a vacation next weekend so hopefully I'll come back with some motivation to work on this a bit more. If anything, I'll upload some videos of the behavior I'm experiencing with the positioning.

[krenshala]

You mentioned that it tracks/transfers orbital information just fine. I would think it would be (relatively) easy to define the movement of other vessels by transferring their orbital info and when they started that orbit, so the data transfered would be the ephemerus, a timestamp, and an angle on the ellipse defined by the ephemerus. This would give you both a time and position on the orbit, and the game should calculate the vessel's current position on the orbit using its normal routines. You should only have to update the data on other clients when the controlling player performs a maneuver (an RCS or engine burn). This, of course, only covers those situations where the other players are not close enough to actually render the vessel (or kerbal) being controlled.

If the ship is close enough to render you would also need the rotational data (initial rotational position, plus changes), which it looks like you have done a good job of setting up already.

On the timewarp issue, I agree with the calls to stop beating the horse. Once this mod gets to the point where it will matter, however, my preference is for something like the mod that lets you warp at will and logs your maneuvers, playing them them back for the other players at whatever speed their clients are running at. This keeps celestial positions sane (which appears to be what some folks overlook when discussion warping) while still allowing official time to catch up when nobody is controlling a vessel at a lower speed. In my mind this does have the oddness that a player could launch a ship into a long orbit, time warp forward on it, do some things, then return to the Space Port (and "server" time) to launch another ship and see himself performing actions on the first vessel from a different perspective. I like this unintended feature, but thought it should be pointed out for those that overlooked it.

Pwolf, keep up the good work. I'm curious to see what you come up with.

[Grimskull44]

Hey all. not a good rocket scientist, or programmer but was very impressed by the quick vid! and I've got a Half-theory on the moving in close proximity side...

As you can't (sorry)Timewarp, or save while under acceleration in normal KSP, would it be logical to assume the physics of thrust/in-atmo gravity/etc are all processed in real-time, and only the resulting position, course/orbit and drift speed/fuel left stored? if so, would that explain the issue Pwolf had where firing the engines toward the other ship barely did anything? thinking maybe short bursts of engine thrust might show up more on the second clients view than sustained power...

whether that's accurate or even helpful though, no clue x) just thought as it wasn't mentioned before in this thread, and there were a few repeated ones on timewarp, i'd mention and see if it aids the grand science. Either way, hoping for some success i'm quite interested how this goes, and who knows, maybe all the logs from people trying to mod in the function help squad down the line when they're working on Kerbal Space Race, The Competitive Career Spectacular.

[Smoovious]

hmm... ok, you don't even need to update the position all the time, either... only when you've used some kind of thrust to change your trajectory, or a gimbal or thruster to change your orientation... the rest of the time, you could just keep each other updated using orbital elements...

back in the day I used to use a program called STS Plus, which I would use for tracking satellites (and the shuttle when it was up).

I would get the orbital element sets through a NASA feed, and the sets get updated when a trajectory changes. Like, when one of the STS missions, would push the ISS up to a higher orbit, then we'd get updates for the STS and ISS missions after the maneuver and they have got a fix on the new orbits.

When they had to have another satellite do a small burn because their computers are warning of a possible collision with another one soon, they'd send an update out for that too.

So... probably don't have to send the info on position/orientation constantly...

-- Smoov

[Aghanim]

Alright I'm not a programmer but it seems that I notice several multiplayer system:

1. Player A sends a thruster on command -> Player A computes the movement, and the ship moves -> Player A sends a command to ship in Player B computer, it computes its command, and the ships move (OpenTTD)

2. Player A sends a thruster on command -> Player A computes the movement, and the ship moves -> Player A sends a positional data to ship in Player B computer (author KSP multiplayer)

And here is my suggestion:

3. Player A sends a thruster on command -> It go to a server, computes, and it moves Player A ship -> It send a video/positional data to Player B

And vice versa is true. No one computes the ship, instead the server computes all the stuff and the client acts only like a "dumb terminal" for inputting commands and showing each other ship position. Wait, isn't this is method number 2 but this is using dedicated server instead of listen server?

Unfortunately because KSP source code is not available with its documentation, I could only guess what happen step by step what happens when a ship receives a thrust on command. But a brute force way is to map KSP space into coordinates and send the coord to other ship......... Honestly if I learn Java and reverse engineer Minecraft multiplayer mode, trying to find out how do flying player hit other player probably I have an idea...

But this mod is a Chicago Pile moment, when we create our first nuclear reactor, and several decades later we make 100+ MW reactors