All good. But if that time comes around do let us know.
Last time I tried DMP was at least a year ago, maybe 18 months. It was quite jerky, particularly in atmospheric flight. Has the netcode or user experience improved at all?
I’ve not followed DMP closely but it’s probably still just as jerky in atmosphere (only when watching someone else, your own plane should be totally smooth).
I just had a quick look at the code and it looks like there is no client side prediction at all. So yeah that’s going to be super laggy 
Navy that is your mod??? I never made the connection. Duh.
It’s always one of the first I download. Can’t play without it so thank you for putting in the work to make something so useful!
1 Like
Shouldn’t you post this on the ksp forum, not the Inovaestudios forum?
It is indeed. You’re welcome! I’m surprised squad hasn’t made something similar stock yet, to be honest. [quote=“PlasmaStruck, post:57, topic:3516, full:true”]
Shouldn’t you post this on the ksp forum, not the Inovaestudios forum?
[/quote]
Why do you say that? This is a thread about ksp, tagged as general. I have been a member of the inovae forums since 2006 (back when the domain was fl-tw), have formed many relationships with folks here, and would like to play a game of MP KSP with them. It seems like exactly the right place to post this.
1 Like
Thanks for the link @martindevans
So it looks like each client sends their full state to the server, which assumedly just forwards it naively to all other relevant clients. Makes sense since this server isn’t a ksp instance and therefore doesn’t have much insight into the spatial relationship between players.
That eliminates a lot of possible interpolation solutions, but it seems that a client side receive buffer could fit into their current code. I’ll have to dig deeper to see if they frame stamp or timestamp packets, but at the expense of latency, jitter caused by changing network conditions could be drastically reduced.
Interestingly, due to the trusted client architecture, two buffers would actually be required. One on the server to smooth out received client state updates, and then one on the client to smooth out received server forwarding updates.
Fork time…
Not playing KSP at the moment, but when I go back to it, your mod is always on my to-install priority list. I can’t imagine how many hours of frustration it has saved worldwide, but it probably passed the “make the world a better place” level 
That could probably work, it’s not how I’d fix the problem though.
Instead I’d hold two different states for every vehicle - displayed and invisible. When a packet arrives integrate forward it’s contents by the latency time and update the invisible to be the new state, then update the displayed by the delta from the previous invisible to the new invisible. Then simulate both displayed and invisible locally and interpolate displayed towards invisible over several frames.
That way latency doesn’t really matter (because we integrate it away) and there’s never any laggy movement because all movement is done via a smooth interpolation.
Oh I’d also drop out of order packets, because fuck em.
I’ve never used it! But since it’s apparently a candidate for solving world peace maybe I should…
[quote=“martindevans, post:61, topic:3516”]
When a packet arrives integrate forward it’s contents by the latency time[/quote]
Problem is, the latency is not constant. Sure, it can be averaged over several updates — but it’s the per-update latency variance (sometimes referred to as Jitter) which is visibly disruptive.
Granted, we’re actually describing two different parts of a solution. I am suggesting buffering multiple network frames (typically 3 is enough to cover most networks’ expected jitter), so that you do not need to perform any extrapolation – which would be required if the expected update did not arrive in time due to a momentary increase in latency.
Essentially: You assume that each client is sending at a constant rate, i.e 20 updates per second, and then append these updates into a queue (production side of the queue), Simultaneously, you dispatch them out of queue to the client at the expected update rate (consumption side of the same queue). It’s just a delay line to ensure that the ‘next’ update is (almost) always available. If you were to buffer 3 updates worth, then the max jitter you can handle is 3x the update interval – in this example, 150ms latency variance.
The end result is that the buffer ‘releases’ updates to the local client at the exact rate of 20 updates per second.
Interpolation is definitely required, and is the next step. But you actually don’t need to simulate each sub-step (the deltas) as you described. Assuming these are all linear transformations, which I believe they are, you can simply take the expected time difference between two updates (50 ms), and back-solve for the initial velocity and acceleration that would be needed in frame A to get from there to frame B (so that you end up at the correct position and velocity in frame B).
Every time the aforementioned buffer releases an update (‘frame B’), you calculate those ‘how to get from frame A to frame B’ values (‘frame A’ being the previous update released from the buffer), then set the visible vessel’s current position to the position from update A, and its velocity and acceleration to the calculated ‘from a to b’ values, and then simply allow the physics engine to do all of the interpolation for you. Math dictates that 50 milliseconds from now, the vessel will be at the position and velocity specified in update B. (all of this applies to rotation and angular velocity / acceleration as well).
I hope that makes sense…
hahahah… moving us closer towards world peace, one docking approach at a time!
1 Like
I would measure the latency per packet. Which you can obviously do pretty easily if you know the other end is sending once periodically (say once every 50ms) and you assume your clocks run at the same speed (technically not a solid assumption I know, but generally good enough for games). Then of course you can do the extrapolation with this per-packet-latency value and don’t need any buffering.
That said, I’m more experienced with building shooters where any extra delay to the packets is totally unthinkable, in a slower paced game like KSP a jitter buffer might work.
You’re right that you don’t need to do substep simulation if the simulation is purely linear, but it’s necessarily linear!
Orbital motion isn’t technically linear although in a 50ms window it’s probably not curved enough for anyone to notice and I think your suggestion would work just fine. The real problem is atmospheric flight which is incredibly complex (especially if you add FAR into the mix) and the only way that’s going to work is by fully simulating both versions and moving one towards the other.
Perfectly
Damnit, now I really want to give this a go. That may have to wait a month (moving to Seattle!), but if I take a whack at it I will let you know!
By the way, if you haven’t seen this video, you’ll probably enjoy it. As far as I can tell, they’re describing a very similar technique as the one Valve developed for the Source engine, although they seem to have special allowances like “favor the shooter” which I don’t think Valve explicitly coded for.
Just curious, you mentioned building shooters. Personal projects? Work for a team? Anything we may have heard of?
Let us know if you put the server back up. As I mentioned, I’m moving this month, so it’s not a good time for me to host. But once I’m settled, if there’s enough interest, I’d be willing to host a server if it still isn’t an option for you. I have a 5-year old desktop sitting around collecting dust that could be put to good use.
1 Like
I’d love to contribute to DMP. It’s so hard to find the time though
If you do this I promise that at the very least I can do some code reviews and make helpful suggestions for you 
Independent game development. I was working on a procedurally generated co-op multiplayer stealth game about pulling off bank heists.
I’ve just recently changed my focus to building middleware for unity. Right now I’m building a VoIP chat asset for unity (many discussions about jitter buffering involved), and soon I shall be porting over a load of the procedural city generation technology which I developed for my game to unity.
Edit: Watching the video now
2 Likes
Oh, cool. Regarding the voip middleware, have you considered WebRTC for the back end? It’s built specifically for streaming audio/video. I’ve only worked with the data channel piece of it, for a web based multi-player asteroids style game, but the api is dead simple.
Your input would of course be greatly appreciated. I’ll keep in touch.
2 Likes
Any chance of bringing this back to life?
17 Likes
I’d like to play some more DMP, but I’m not sure if I’ll be able to find time to setup the server. It was pretty high maintenance last time (keeping up with the same modpack for everyone).
How many other people are interested in playing?
1 Like
The server is back up!
To join you just need to install mods with CKAN using this mod list and then connect to mute.moe (default port) using the DMP window on the main menu.
The server is setup so that all the parts in the mod list are required - you must install them to be able to join. You can also install any other mods you like. If you create a craft with parts the server does not know you’ll be unable to launch, so make sure you only install non-part mods (e.g. ferram aerospace, texture packs, kOS etc).
2 Likes
I won’t be able to join soon because I’m going on vacation.
But I did a short testrun with the modpack…
My KSP has already updated to version 1.7 - many of the mods on the list have not been updated in CKAN to work with that.
That can be bypased but I think the saver version is that we stick to an older version of KSP for now.
I have set steam to stick to Version 1.6.1 now. Will test in the evening if everything works out after that.
3 Likes
I swear every time I put up a server KSP immediately undergoes a change that breaks half the mods! 
Let’s stick with 1.6.1 for now.
1 Like
Tested. Worked without problems.
Got a bit confused by your naming convention. I don’t know why but when I think of outposts I assume a land base.
Got me wondering how that thing is supposed to land 
11 Likes
Haha that’s definitely an orbital outpost, maybe I should rename it to station instead of outpost 