JohannesMP

My Previous 0.1.5.1 Tests Rover Docking test 1 Orbit Test 1 - Setup Orbit Test 1 - Further Testing Docking Test - Attempt 1 Orbit Test 2 Rover test 2 After a good bit of work with godarklight we were able to compile a working 32bit sqlite3 mac library, and I wanted to test if it fixed some of the issues that sqlite3 had for mac in the past. It should be noted that while I am using devbuild 7d95942, in addition to the extra libsqlite3.0.dylib file I was also using Mono.Data.Sqlite.dll and a modified KMPServer.exe and KerbalMultiPlayer.dll (as modified by godarklight on his test server). As such some of the issues below may not be directly reproducible with the immediate dev build, but probably will be in future builds, once these changes are merged. Setup Server was configured Similar to previous attempts (default except 1750m bubble) although this time we're using sqlite3 and so useMySQL is set to False. Everything is running on the same machine, two clients, the top-left is called 'client_1', bottom-right 'client_2'. Video (please watch in full 1080p) Note: Unfortunately I did not have time to edit this video, but a detailed analysis with timestamps can be found below Key Issue Summary [New] When launching at the same time, both clients will suddenly not be able to see the other one on their respective user lists while inside the bubble. Despite this however the users can still receive chat messages from each other. When either of the clients exits the bubble they will immediately appear on the other client's user list. It seems the change of state causes the update to sync, while the client did not receive the original 'change in user's state' message while they were in the process of loading the world/vehicle before launch. Similarly at other times a client will not see a connected user, but then changing their state, such as switching from the space center to the tracking station, will fix it. [Known] As in my previous tests, two clients leaving the bubble in atmosphere next to each other will not be able to see each other's vessels until they completely disconnect and reconnect. [Known] When another user is connected, one user will repeatedly fail to connect, instantly being listed as "Player #<num> <name> has disconnected: Connection lost". This seems random and randomly fixes itself, but as you can see in the video below, sometimes it takes over a minute of consecutive tries for it to work. [New] When disconnecting and reconnecting soon after the initial sync out of the bubble (to fix issue 2 above), weird stuff happens with the vehicles: I. The original movement that the vehicle made seems to not have saved and the vehicle is reset to the edge of the bubble where it was first synced to the server - in the example below both rovers drove 200-300 meters away from the bubble and locked their breaks. upon logging in again both vehicles were on the edge of the bubble with their breaks unlocked II. One vehicle is changed to the other vehicle's model and name, but retains its original position (so it's not a case of ship duplication where you just have two copies of the same vessel in one spot). - I've been able to reliably reproduce both I and II, following the same order of operations as described by the video. [Known] 45 second vehicle updates still do not happen, for several minutes after opening the parachutes on both vehicles, the other client would still see the parachutes as closed [New] Although early in my test the movement seemed much smoother than in my previous tests, at a very slow speeds movement is not correctly synced and the other client, instead of seeing a slow steady movement, will see the vehicle jumping forward in little hops every few seconds. It seems as if either movement data is capped to only be sent if the velocity exceeds a certain speed, or if a vehicle has moved more than a predetermined distance. While this might save bandwidth, it looks really bad. [New] After running for a few minutes the server begins to struggle and messages are delayed, only a few seconds at first, but ultimately one vessel's movement can take up to 80 seconds to even begin to appear on the other client. This also affects chat messages, which don't even show up in the server's own log until much later after they are sent, which seems to indicate an underlying congestion issue in the server itself. Video Analysis (bold timestamps indicate a possible issue) 0:06 - As a baseline, showing that both clients can send and receive chat messages from one another 0:40 - Note: client_1 has loaded Rover1, client_2 has loaded Rover 2. Rover1 has orange parachutes, Rover2 has blue. This is important later on. 1:05 - Both client_1 and client_2 launch as close together as possible. This might be relevant for the issue that follows at 1:18 below. 1:12 - For the first ~5 seconds both clients can see the other in the user list 1:18 - Suddenly both clients disappear from the other's user list. However neither have been disconnected, and indeed both can still receive chat messages from the other one (1:25). 1:45 - The moment client_1 leaves the bubble client_2 suddenly sees them again, listed as 'Prelaunch at Kerbin'. However client_1 still cannot see client_2 on their user list. When client_2 then leaves the bubble (2:08) they also appear on client_1's userlist. 2:12 - As has been the case in all my previous tests, once both clients have left the bubble and synced their vehicles to the server, neither can see the other. 2:20 - Note: Rover1 and Rover2 are both about 200-300 meters away from the edge of the runway, and both have their breaks on, so cannot move anywhere. Keep this in mind for later. 2:28 - Both clients disconnect, as is necessary for them to be able to see the other vessel. 2:43 - I first click connect on client-1, then a splitsecond later click connect on client_2. While client_2 reconnects instantly, client_1 is stuck on the map screen. Almost instantly after attempting to connect the server log states: "Player #1 client_1 has disconnected: Connection lost". This continues to happen several times: 2:58 - client_1 Connection attempt 2 - failed 3:14 - client_1 Connection attempt 3 - failed 3:24 - client_1 Connection attempt 4 - failed 3:37 - client_1 Connection attempt 5 - failed 3:44 - client_1 Connection attempt 6 - failed 3:53 - client_1 Connection attempt 7 - success! notice how you can immediately tell from the atmospheric reentry sound effect that plays during the loading screen. 4:05 - Despite having now connected, client_2 still is not seeing client_1 on their player list. Only once both players switch locations, to the tracking station, does client_2 see client_1 again. 4:15 - Remember how I made absolutely sure that the two rovers had different names, Rover1 and Rover2? Well the tracking station now only shows two 'Rover2' entries 4:32 - client_1 resumes the flight of the top rover and client 2 resumes the bottom one. 4:37 - Now, if Rover2 was just duplicated you would expect the two duplicates to be in the same spot, but they're not. In fact they're both on the same path that the previous two rovers took when they left the bubble, not on the same path as you would expect if it was somehow a duplicate of Rover2. What seems to have happened here is that, somehow, Rover1 was simply replaced by Rover2. What the heck? 4:42 - Remember where the rovers stopped at 2:20, each rover was 200-300 meters away from the runway with their breaks on. However when client_1 and client_2 logged on just now, the rovers were just barely on the edge of the runway, basically exactly where the edge of the bubble is. It's almost as if their position was not saved on the server after the clients disconnected, and reverted back to the place where Rover1 and Rover2 first spawned into the server when leaving the bubble. 4:53 - Time to test how good the syncing is now. If you'll recall in my previous tests, this was always really jittery, with a strange 1-2, 1-2, 1-2 kind of movement. 5:12 - Just to verify that they are indeed the same vehicle, both have the blue parachutes that Rover2 used, not the orange ones that Rover1 had attached. 5:37 - At this point, comparing the movement on client_1 and client_2 it actually looks -really- good. The movement is smooth and almost 1-1. Much better than in previous tests! 7:14 - To test if periodic updates work now, I deployed the two parachutes on client_1. The ship should re-sync completely every 45 seconds, so at the very least in 45 seconds client_2 should see the open parachutes. 7:37 - Switching to client_2, I decide to also deploy its parachutes. However when I do so notice that the parachute model does not open up and change to show the 'parachute deployed' model. when I did so with the two client_1 parachutes this happened instantly. 8:00 - On client_1's rover is rolling at a constant, very slow speed. It seems that unlike the previous smooth movement, client_2 is not interpolating the movement correctly and so is seeing client_1's rover do little 'hops' every few seconds. It's almost as if movement is not synced unless the position changes more than a given value, at which point the position is synced again. 8:16 - On client_2's chat, I enter a chat message "bounce, bounce, bounce". However this chat message does not appear instantly on client_2's screen, nor does it appear on the server's log. In fact there seems to currently be a MASSIVE delay in server packets, and the initial 'bounce, bounce, bounce' does not appear until 8:37, so 11 seconds later. subsequent chat messages sent by either client seem to take longer and longer each time. 8:51 - Thinking back to 7:37 when I opened client_2's parachutes and the model did not update. Right at this moment the model suddenly updates, a whopping 74 seconds after the initial command. This further confirms that something is -really- clogging up the server right now. 9:00 - I begin to drive around on client_2's screen to see how long it would take for client_1 to see the movement. 9:28 It takes about 30 seconds for the movement from client_2 to be visible to client_1. And the resulting movement is not very pretty anymore. It's very jittery, as if the client keeps receiving old data that resets the rover back and trying to re-interpret the path according to that. Something is clearly very wrong with the data being sent from the server to the client. It seems almost like the server is insisting on sending all the built up data that it has instead of just sending the client the most recent data, and as a result there's a huge amount of congestion. - Remember this is all running on the same machine, latency or packet bandwidth should not be an issue whatsoever. 10:00 Now client_1 drives around a bit and then waits until client_2 receives this data. It ends up taking until 11:23, or over 80 seconds for client_2 to see client_1's rover even begin to move. Downloads Rover Craft Files: link Log Files: link (I'm unsure which order I launched the clients in, so don't know which client Player.log corresponds to. I also forgot to run KSP with the KMPdebug flag)

Yep, as another Mac user I can confirm that this is a know Issue on the bug tracker and unfortunately MySQL is the only currently proposed workaround, which comes with its own set of issues.

I'm assuming you don't mean simply 'remove time warp' since that would mean flying to Eve would require you to wait over a year for your ship to arrive (and anyways to do that all you need to do is just agree with your friends to never to use the warp button, by for example just unbinding the keys), and I'm assuming instead you mean remove the need I to sync when someone warps. As in, if they warp on their trajectory to the moon, then you would just see them on the moon in your time. The problem is that in KSP, planets and moons are not stationary. Even if the mod made the player appear to be in their relative place around a celestial body, it still would have the potential to cause massive issues. Let's say you are orbiting Kermin and on their screen they just landed on minmus. And let's assume on your map you would see the moon and minus on opposite sides of kerbin, and on their screen, since they warped time, the moon and minmus are close together. If the mod was designed to just always show them where they are in their universe but 'projected' onto your universe, what would happen if they suddenly launch from minmus and do a quick transfer to the moon. Since on your screen the moon is on the opposite side of kerbin, would you see their ship suddenly fly through kerbin to reach the moon on the other side? It would just cause a huge amount of confusion and issues. For example what if you now wanted to rendezvous with them as they (on your screen) pass thorough kerbin. They wouldn't actually be there. It may be a roundabout way of saying it, but the current syncing/time warp system is absolutely necessary. The only way you could otherwise avoid the problem is by locking the universe, forcing all planets to be stationary. That way regardless of how you warped, your position would still make sense for everyone, but that would take all the fun out of transferring between orbits.

Suggestion as posted on the Issue Tracker: Single Kerbal Mode (and other Co-op Ideas) Overview I was discussing with a few friends about how KMP might play further along in development, once the mission-critical bugs have been fixed, and how we would potentially like to play the game. We came up with this idea as a means to allowing players to collaborate more, and to allow them to have a more intimate relationship with their vessel/Kerbals. I'm aware that the proposed features would require a ton of work (tentatively touched on at the bottom of this post), and even in the best-case scenario would be many, many months away from even being considered for KMP, but I think it's worth discussing for potentially figuring out what sort of features we might want to see later in development. Single Kerbal Mode Specification When logging into a server you can choose if you want to have standard control of Kerbals, or play in Single Kerbal mode (alternatively this could be set and required by the server). In Single Kerbal Mode a Kerbal is effectively your avatar, and is bound to you. When first logging on with this mode, You'll have the option of customizing your kerbal, with a name as well as choosing their stupidity/courage levels. Ideally their name would be your username - Remember, for all intents and purposes, while playing in this mode you are that kerbal. For clarity's sake, in this discussion I will refer to the two modes as Single Kerbal mode and Standard mode. Players in these mdoes will be referred to simply as Kerbal Players, and Standard Players respectively. Once a character is created you can join a Mission, which effectively is a party system restricted to other Single-Kerbal players. Ideally it would have a mission interface and mission chat (accessible as in most multiplayer games by a simple /m or /p command in the chat window which would toggle it to party chat, /g or /w toggling back to general/world chat). As the original creator of the Mission, you would become the Mission Leader. When Choosing to launch a rocket, you are restricted to only having your assigned Kerbal in a command pod, the other seats being empty. However you can use the Mission interface to assign other Player Kerbals to the available seats, assuming that they are not already in another vessel Once on the launchpad/runway, the other crew members (Players) will be able to see the ship (so foregoing any bubble syncing restrictions), and will have full control of the components that you've assigned them to Anyone can spectate your vessel, but it is considered private to your current Mission, so a Vessel that's in control a Single-Kerbal player can never be controlled by the Standard players. While in this mode you are unable to switch vessels. If you want to take control of another ship, you need to EVA and get in that ship (Probe controlled-ships, that are currently without a direct pilot would be an exception) If your Kerbal is killed in action, Depending on the mission settings you would either be out for the count, or be allowed to create another Kerbal. The idea behind all of this is that your actions will have much more serious consequences. If you manage to get stranded in space or on a celestial body, you are stuck there, and other members of your mission need to mount a rescue. You cannot just magically jump to the tracking station or launch another vessel, although the Mission Leader could terminate your flight (which means they carry a lot of responsibility). This would allow for a much more intimate co-op experience with your Mission teammates than is currently possible. Adding what is effectively a Perma-death element to your character would also force you to be much more careful during vehicle construction and mission planning, such as including extra failsafes and backup plans, which I think would create a more realistic space experience. Potential Changes Required Obviously before this can even be considered, all current game-breaking KMP bugs would need to be fixed. Syncing would need to be seamless enough to allow multiple players to control the same ship without anything exploding. Permadeath is not very fair if while approaching the vessel of another member of your mission, it suddenly explodes randomly. Otherwise changes that would be required would include: Custom UI elements, both for Kerbal Creation on Login, as well as Mission Management. Ideally it would extend/replace the Editor's Crew selection screen to allow for selection of members of your current mission The entire Mission backend, how it's stored in the database, Handling mission roles and permissions, etc. Major changes to the current Bubble system, since for this to work players that man your ship with you would probably like to be able to see everything from the moment you spawn and start your count-down Major changes to the ship controls to allow for permissions, such as giving a specific mission player the ability to decouple a docked ship. Also you would need to be restricted from being able to EVA/control other Kerbals, as well as limitations to what vessels you can switch to, and preventing you from launching another ship when your character Kerbal is already on another active vessel. Figuring out exactly how standard players and Single Kerbal players would interact. it might be easier for it to just be a server-side setting that can only be one or the other. Lots of backend changes I haven't even begun to consider. Summary Really this is only touching on some ideas that could easily be expanded further. I think the fact that you would be a character in the world, not some Omnipotent Deity able to traverse the boundaries of time and space without restrictions, opens up all kinds of gameplay possibilities. Just as a further example, since each member of your crew would be a unique character, you could even assign roles (either just among your team, or enforced by your backend), for things such as one player being trained in unmanned rover piloting, while someone else might be the docking expert. Once again, this post is mostly a brainstorm, just trying to imagine what, under the best conditions, might be possible in a KSP with real multiplayer Co-op. Please feel free to add your own thoughts and discussion

This should really be looked into (and probably added as it's own bug report) - I'd imagine that given the option, many sys admins would like being able to run it on their existing MySQL setup if they have the choice, not just Mac users. For example I do have a dedicated Linux server that I plan to run KMP on when It's closer to beta. I already run a handful of other games on there, many of which use MySQL. And as you said previously it doesn't seem to be an issue in the MySQL database itself.

I'll give it another shot when I have some time (probably in the next day or so). Oddly enough I haven't even tried testing going out of Kerbin's sphere of influence with multiple clients yet, much less land on another body, but I've been meaning to try it. Something tells me that if you and another vessel are in visual range of one another on a trajectory to the moon, that you'll have much Fun when you cross into the other sphere of influence I have a hunch that this issue might originate deep within KSP itself, but is made exponentially worse by some KMP weirdness. Also in my experience, periodic lockups like this are often telltale signs of memory issues, since garbage collection and similar things tend to happen at a similar frequency. At least I've had many odd periodic FPS issues in various games that ended up being memory related, either in the game, or even with my graphics card. (To be honest this is purely speculation here, I know basically nothing of how KMP/KSP/Unity/C# actually function) Well, right now the database is periodically backed up every few minutes as defined in your settings, but It overrides the backup file every time it does it, so you'll probably want to back it up manually before attempting any risky maneuvers. If you do happen to make a big mess, you'll have until the next periodic backup to grab the current backup before it gets overridden, so if you're quick and lucky you can save the last backup and revert from that. I like using the MySQL database option, since that way I have full control over the DB and can use my own automated MySQL backup method of choice. It would be neat if the server could be forced to make a backup via a console command, which could then be loaded when the server is stopped.

Yeah, you're exactly right. When you first try to log in with KMP it will create a local 'token' that is used to authenticate you as that username. It's located in: GameData/Squad/Plugins/PluginData/KerbalMultiPlayer/KMPPlayerToken.txt. So what happened in your case was, the token was created and the server associated it with your initial username. When you then replaced the KMP files it removed the token, and on your next login attempt generated a different one that no longer matched what the server had in its database. To avoid this problem in the future just make sure to back up the token file and replace it after any upgrades you make. Also another quick fix would be to just delete the server's Universe file and start over. Given the current state of the mod It's not unlikely that you'll have to reset the universe every once in a while anyways. Alternatively, I'm not sure if the sqlite universe file can be easily edited, but when using the MySQL option it's super easy to just manually delete the entry in the Users table.

Hmm, assuming the IP he tries to connect to is what you get when you google "what is my IP", and assuming your port is indeed correctly forwarded it should work. the IP binding is only necessary if you have multiple IP's on your machine, so leave that at 0.0.0.0. Hamachi may work too, but really shouldn't be necessary.

Expected, but still a bug - that vestigial 'feature' has been removed in all other cases, and is just confusing since what the client sees is not actually what is on the server.

My Previous 0.1.5.1 Tests: Rover Docking test 1 Orbit Test 1 - Setup Orbit Test 1 - Further Testing Docking Test - Attempt 1 Orbit Test 2 Yet another attempt at a local orbit rendezvous, this time with two identical craft launched at the exact same time on two local clients Setup: Basically the same as Orbit Test 1 Video Issues listed in the video Ships are not synced correctly in atmo (issue report) A client will sometimes see multiple copies of a ship that aren't actually there (issue report) Reverting to Space Center from space will make the craft appear to be on the launchpad "Player #1 client_1 has disconnected: Connection lost" (issue report) When coming out of warp with another ship in close proximity, your client will sometimes cause the other ship to explode and sync debris back to the server (issue report) Using the tracking station (while in close proximity to a ship on the same orbit as you) can shift your orbit by 40km (issue report) No video analysis this time, since I actually bothered to add subtitles and edit it down to a manageable time.

Excellent, really hope that fixes it since that made accurate docking a huge pain

It's absolutely not the case without KMP. I've done plenty of docking with -much- bigger stations than this little test platform and at most my framerate drops, but it remains consistent. For example I never see RCS thruster particles explode to the size of my ship as happens several times in my video above, which is a clear sign of the game just completely locking up for a second. Low but consistent framerate I can deal with; Complete lookups every few seconds are much more difficult.

Actually no, port forwarding is only ever necessary on a server. The reason is fairly simple: Assume Client A and Server B. Both are behind their own routers without port forwarding. Client A knows The IP address to Server B's Router, but it does not know the IP address that Server B has in its router's internal network. When Client A tries to send a message to Server B, the router of Server B that receives the message does not know where to send the message to in its internal network, so the connection fails. After setting up port forwarding on Server B's router though, the router knows 'Aha, I got a message, for port X, and I know that any messages to port X are sent to this internal IP address' - the one corresponding to Server B. The key to understand here is that, when a message is sent out through a router from a machine in its local network, the router and connection protocol keep track of what internal IP/Port that communication came from. So when Server B goes to reply to Client A, the router of Client A knows that this message is a reply to the one sent out earlier, and so it can route the message directly back to Client A without needing a port to be forwarded. It should be noted that I'm very much simplifying, but that is the basic reason why you don't generally need to forward ports if you are just a client, and are not trying to act as a server. Though it is not directly relevant to KMP, there are ways of handling this that make it so Server B would not need to port forward, such as NAT Through-punching, which many services such as Skype use. It basically means that you have another sever - Server C - that both Client A and Server B (which in this case would really be Client B) connect to first, and through there A and B can connect to each other directly since their respective routers have already started routing messages and know where internally they should send incoming messages to. (Again, I'm very much simplifying) The problem here is that as the service provider, you need to maintain a single login server that handles all initial connections, so if it goes down (via hardware failure, too much load or a DDOS attack) no-one will be able to connect.

Ah crap, yeah I meant seconds; further down in my post I correctly said seconds. Thanks for catching that.

My Previous 0.1.5.1 Tests Rover Docking test 1 Orbit Test 1 - Setup Orbit Test 1 - Further Testing Docking Test - Attempt 1 My first real attempt at real-world testing, conducted with a good friend of mine that lives in Alaska (I live in Finland). Setup: Server is running locally on Mac via Mono, using MySQL Database (local install via MAMP). Server is port-forwarded through router. We have two ships in a 100km orbit, and are just close enough to start seeing each other's model, and are trying to dock. I'm connecting Locally (Jo), friend (Ryxos) is connecting via IP, Ping is 100-200ms. Video Notable reoccurring issues On multiple occasions my friend's ship would shoot off and then slowly drift back to where it was before. Jumping to the tracking station or disconnecting/reconnecting would cause our flight paths to vary wildy, forcing us to spent much time trying to rendevouz again Even changes to the ship such as detaching a stage would sometimes not sync, appearing as detached on the pilot's screen, but still appearing attached on the other screen. My client experienced massive lag spikes every 15-20 seconds, during which any held input keys were considered held, often causing my ship to rotate out of control and having to waste time slowing down again. Video Analysis - bold timestamps indicate a possible issue: 0:12 - Trying to click on my friend's ship in world to set it as target is not working 0:50 - On the map screen, the player indicator arrow for ryxos is not matching the location of his ship, and seems to be ahead of him on his orbit. 0:56 - Managed to set friend's ship as target via map screen 1:00 - Annoyingly though, despite having it set as a target (as indicated by the speed on the navball) I still cannot see the HUD indicator for his ship. 1:08 - Ryxos' ship suddenly shoots off screen (notably in the direction of where his player indicator arrow was located on the map screen), only to slowly slide back into place a few seconds later (1:15) 1:55 - I start trying to cancel our relative velocity and maneuver towards Ryxos' Ship 2:00 - Massive lag spike that causes my RCS to fire continuously (and the particles become huge for a moment), causing me to spin out of control for a moment. This lag (issue #632) Makes fine adjustments incredibly difficult, since if the thruster is engaged as the lag spike hits, the key up event will not be registered until the lag spike is over, causing the thruster input to last for several seconds, completely messing up any semblance of fine control. This continues to happen every 15-20 seconds or so. 5:32 - Ryxos' ship once again disappears. The menu has no connection to this. Notice how my framerate goes up dramatically while it's gone. 5:38 - Ryxos' ship comes racing back. on his screen he said it looked like I suddenly crashed into him 7:55 - At this point we realize that our ships are out of sync. During the last minute Ryxos had jettisoned his large fuel tanks and engines on his ship. On my screen however the fuel tanks were still attached, blocking the large docking adapter that I was intending on docking with. 8:20 - In hopes of resyncing, I went to the tracking station and tried re-selecting my ship 8:40 - Ryxos' ship is nowhere to be seen. Our orbits are now quite desynced, and he's about 16km away. The next minutes are spent trying to sync up again. 14:25 - I timewarp, with the hope that once I've warped to a position where our ships are close together, Ryxos will be able to just click the 'sync' button. 14:40 - Ryxos has clicked sync and suddenly the target velocity of his ship (see navball) is going up super fast. It should be noted that my friend is not accelerating or even touching his controls at this point. 15:00 - We basically give up trying to dock at this point.

Keep in mind, the 'bubble' is a cylinder. The 2000 is just the radius, not the height. type !bubble in the chat in-game and you'll see how far you are from the top. I think in this case I specifically didn't use arrow keys (since I've noticed the issue you describe in the past) however I'm beginning to suspect that modifier keys are also being recorded, since I used cmd+c, cmd+v to copy/paste the ship ID. It would be nice if you could just type the first 5 letters of the ID and it would just figure out the ship you mean from that, assuming only one ship matches that code. in the unlikely event that multiple ships have that code, it could just tell you and you could type out a few more characters.

I'm trying to manually delete a piece of debris with /deleteship, but when I do so it says the Vessel is not found, eventhough I'm copy/pasting the vessel ID directly. /listships [19:08:57] [Info] : Command Input: /listships [19:08:57] [Info] : Name: ****-Spear Personnel Deployer-Sh ID: 4cfb2610-dfa8-4de5-be7e-cc1d33fd0f52 [19:08:57] [Info] : Name: Jebediah Kerman ID: b14d0ae3-f688-408e-89e3-26c5e1f89472 [19:08:57] [Info] : Name: ****-Spear Personnel Deployer-Sh ID: dcdd9a00-a503-49b1-9efd-88dfe656d4f5 [19:08:57] [Info] : Name: ****-Spear Personnel Deployer-Sh ID: fa54e31e-aec1-4eca-a208-667812be50d8 [19:08:57] [Info] : Name: Test Platform ID: 174662c8-dfc6-4e63-832a-cceb7c962401 [19:08:57] [Info] : Name: Test Platform Debris ID: a2095391-93bc-499a-a9d3-cd8cdd96efda /deleteship a2095391-93bc-499a-a9d3-cd8cdd96efda [19:09:08] [Info] : Command Input: /deleteship a2095391-93bc-499a-a9d3-cd8cdd96efda [19:09:08] [Info] : Vessel a2095391-93bc-499a-a9d3-cd8cdd96efda not found. As you can see I'm trying to delete 'Test Platform Debris'. could there maybe be some invisible character involved that's being copied from the /listships output?

Correct. The best you can currently do is fly a ship, and someone else spectates you. They can take over the ship for you if you EVA/undock, assuming you left the ship public. No way yet to delegate people to control certain parts of your ship.

When you download the client files you'll have a folder called 'saves' that contains a 'KMP' folder. This folder needs to be placed in the saves folder in your KSP installation. So basically make sure that you have the correct stuff in Steam/SteamApps/common/Kerbal Space Program/saves/KMP. If you already did this try deleting the previous KMP safe folder, re-download the client files and try doing it again. Never try to load this save in the game normally. Also, saying 'quick reply would be nice' is in no way going to make replies faster people reply when they see a post and have time.

Negative. Spectator mode, where one player switches into an already controlled ship was added in KMP v0.1.4. The documented behavior is that the spectator is unable to change anything on the ship (which is working correctly). In addition to that, if the ship is public, and the controlling client switches out, control is yielded to the spectator. Testing of this functionality was the primary focus of the last test.

A continuation of the in-orbit Tests, covering spectating, EVA and some docking. Setup: Two KSP clients, running on the same machine, connected to a server over LAN (<1 ms latency). The server is running the universe set up in this post, default settings except safetyBubbleRadius is set to 1750. there is one ship in a 150km orbit, and client 1 and 2 will be switching off taking control of the ship, EVAing from it, etc. Video Notable reoccuring issues Vessels sometimes show up without the appended <client_1>/<client_2> tag, or sometimes the wrong vessel will have the appended name. Resource usage, solar panels, lights and docking shields are not synced between clients. Even after disconnecting each client will only see the changes that it made to its version of the ship, way past the 45 sync duragion (the even by the end of the 27min video the changes one client made to the ship still haven't synced to the other client, even after multiple disconnects/reconnects) Each client has their own set of kerbals for a given ship, so if a ship has 3 cremen, then each client that takes control of the ship can EVA 3 kerbals, instead of the number of kerbals remaining bound to the ship. this is probably related to the above desyncing issue. When viewing a controlled ship as spectator, the RCS thrusters will fire and SAS button blink when the ship is being rotated, if the spectator's client left those buttons enabled on the previous flight. Also when this occurs, electricity/RCS fuel is used up, causing the client's instance of the ship to have less fuel (also related to syncing problem above) On a few occasions switching to spectator mode causes a huge amount of lag for the spectator, making the game very unresponsive. It could be a coincidence, but one time when this happened, checking the tracking station revealed 6 extra EVA'd Kerbals that shouldn't have been there. disconnecting and reconnecting removed the extra kerbals and fixed the latency. Consistently, when a pilot controls a ship while another client is spectating and detaches from the ship (either by EVA or decoupling a docked ship and switching to it), the spectator will gain control of the ship (as is intended), but the ship will also warp 30m-30km away from the newly EVA'd/undocked vessel. Other single-instance issues, see below Video Analysis - bold timestamps indicate a possible issue: 0:20 - client_2 can see 'Test Platform' in the tracking station list, however shouldn't its name be "Test Platform <client_1>"? 0:45 - changes made by client_1 to the docking shields, as well as lights and solar panels are not synced to client_2, even long after the 45 second refresh time. 01:52 - when client_1 rotates the vessel using only SAS, client_2 sees the ship rotating with RCS thrusters, since the RCS button was enabled during client_2's last flight. really RCS and SAS should always be disabled for a spectator 03:00 - similar to 0:45, since the spectator sees the ship using RCS, the RCS amount in the tanks is becoming unsynced 03:20 - even once constant speed (no acceleration) is reached on the rotation of the pilot's ship, the spectator only sees very jerky movement, so it's not just the lack of syncing acceleration that's the problem. it seems that velocity (rotational in this case) is not being correctly synced, since between the 1-2, 1-2 jitters the ship is not rotating at all. 03:55 - client_1 EVA's a kerbal. Since the ship is public this should transfer the spectator to being the pilot of the ship. In this case however client_2 begins experiencing extreme lag, causing the game to become largely unresponsive. Only by client_1 returnin g from EVA does client_2 return to normal. 04:41 - client_1 EVA's again, this time correctly giving client_2 control of the ship (as indicated by the Kerbal portraits. When this happens the ship is suddenly 13km away from the kerbal. 05:05 - exiting the flight and going to the tracking station, client_2 now sees three instances of Bill Kerman. When client_1 switches to the tracking station only one Bill appears, same with /listships on the server 05:55 - NOTE: it's pretty neat that like this I can actually view the map while still flyign a kerbal manually. 07:35 - after a disconnecting and reconnecting, client_2 sees the correct number of flights in the tracking station, but it says that Test Platform is being controlled by client_2, when client_2 is actually EVA-ing Bill 08:01 - While attempting to return Bill to the ship, client_1 timewarped (at 06:55), putting client_2 behind.However while at the Space center, client_2's Sync button is completely disabled, both in the standard version of the KerbalMP window, as well as the Options section. This is a minor issue since taking control of the vehicle re-enables the sync button, but it's annoying nonetheless. 12:08 - The moment client_2 tries to grab the ladder, the ship jumps ~30 meters away. 13:06 - With client_1 spectating again, client_2 EVA's Bill, which (like at 04:41) causes the ship to warp 1km away. 13:44 - client_1 suddenly sees two Bills on his HUD. One is listed as being under client_2's control, but looking at the distance seen on client_2's HUD while maneuvering back tot he ship, it seems that the one under client_2's control is the one -without- "<client_2>" in the name. This persists into the tracking station. A quick disconnect/reconnect fixes it. 17:05 - with client_2's Bill now hugging the ship, client_1 EVA's their Bill. A few moments later on client_1's screen, client_2's Bill suddenly boosts away from the rocket at about 20m/s 17:50 - client_2 sees its bill slowly pass through the body of the ship 19:00 - NOTE: client_2 is leaving a Bill Kerman in space. Since each client seems to be in charge of its own set of Kerbals, for the rest of the video an extra 'Bill' will be visible in the tracking station/map. 19:00 - client_2 switches to the tracking station and spectates the ship again, causing the FPS to plummet and become very unresponsive, just like at 03:55 19:08 - client_1 EVA's Bill, which a few seconds later causes client_2 to suddenly see three Bills on the ladder, And which, like in previous EVA's, causes the ship to suddenly warp away at a rapid speed, being 20km away by 19:32 20:07 - client_2 is now so unresponsive that it took several seconds for the menu to pop up after pressing escape (notice how at the time when it pops up, the other window has been in focus for a few seconds), and clicking 'Space Center' takes another ~5 seconds to respond 20:26 - possibly related to the high degree of lag, client_2 suddenly sees 7 Bill Kermans in the tracking station. Disconnecting and reconnecting fixes it to the point of there being two Bill Kermans (which is correct, since client_2 did abandon a Bill earlier) 22:30 - client_2 (which is currently in control of the ship) detaches a small docked ship (which has no Kerbals but a drone) and switches to controlling it, once again warping the other ship (which client_1 now has control of) 26km away. 22:50 - The rest of the video is me trying to redock the small ship, and failing miserably, mainly because I attached the drone the wrong way which completely throws me off and causes me to waste all my RCS. Downloads See previous test post

Yeah, the screenshot thing wasn't really a test per say, as opposed to just me not having anything else to do during a fairly boring launch And TehGimp666 summarized it well in his reply on reddit - not every aspect is constantly tested, and many of the things I'm showing here are well known as being problems and are already listed in the bug tracker. The point of my tests is not to poke the developers and say "look at all these obvious problems that you've missed" (again, they -know- about most of these already) but rather to give a third opinion and offer my input on what I think might be worth focusing on.

Will be working on doing some more in-depth testing, starting with spectator mode in orbit. This first post/video is mostly just setup, and I didn't quite get around to the actual bulk of the testing I wanted due to an odd UI crash that probably was not related to KMP. More tests coming later. Setup: Two KSP clients, running on the same machine, connected to a server over LAN (<1 ms latency). The server is running a clean universe, default settings except safetyBubbleRadius is set to 1750. client_1 is flying a ship (see downloads section) into into a 150km orbit, client 2 will attempt to spectate. the resulting universe (see downloads section) will be used in following tests. Video (click to skip past launch to when the issues begin) Notable issues Spectator was unable to select the ship from tracking station even when it was out of the bubble, and even after disconnecting and reconnecting. Spectator's client crashed when trying to spectate the ship Video Analysis - bold timestamps indicate a possible issue: 0:35 - Showing off the screenshot sharing feature 1:13 - Launch! 1:40 - Testing the maximum rate that you can send screenshots by mashing the F8 key; It's about one every 3 seconds. 2:05 - Still inside the bubble, so client_2 wouldn't be able to see it anyways 2:12 - Throttling down a little to remain under 200m/s while below 10km 2:40 - Starting gravity turn a little late 3:07 - We're out of the bubble. No we can start trying to spectate with client_2 3:25 - Client_1's vessel is out of the bubble, but client_2 cannot see it in the 'Flights in Progress' list -BUT- it can see the flight's trajectory and view it by mousing over on the map. 3:58 - It should be noted that the syncing of position data on client_2's tracking station is surprisingly smooth. tick rate here must be much higher than for the actual models. 4:50 - Even after disconnecting, client_2 is unable to see the vessel in the tracking station's list, so cannot select it to attempt to take control. 6:06 - After disconnecting again client_2 finally sees the vessel in the tracking station's list. 6:20 - Attempting to spectate the vessel, client_2 suddenly experiences a really strange UI bug, becomes unresponsive to the menu items and ultimately the client has to be forced to shut down. Downloads Testing platform craft file KMP Server Universe (will use this in further tests)

Unfortunately, as far as ground vehicles are concerned, KMP v0.1.5.1 is still effectively unusable for even the most basic multiplayer gameplay. As with my previous tests, the guidelines are simple: Setup Two KSP clients, running on the same machine, connected to a server over LAN (<1 ms latency). The server is running a clean universe, default settings except safetyBubbleRadius is set to 1750. (in this case the server was running on a windows machine to avoid mac-specific sqlite3.dll server issues. Clients were still on mac, but that should be irrelevant to these issues) Each client loads a simple 21 part rover - See craft files in the 'Downloads' section below. Goals: The rovers must correctly appear for the other client once they are outside of the bubble. The rovers must not randomly explode. The vehicle count on the server may not exceed 2 (not counting Kerbals or debris created from legitimate collisions). The movement of the other client's rover must appear reasonably smooth/synchronized. The rovers must be able to dock successfully with reasonable ease. Video of Test: ( ) (note: client "Jo_1" (top-left) and "Jo_2" (bottom-right) are referred to below as "client 1" and "client 2" respectively) This video demonstrates that v0.1.5.1 (Dev build 0ff9147) still fails each of the goals stated above: Each client had to disconnect from the server completely for the other client's vehicle to appear, even when outside of the bubble. There are plenty of random explosions. The debris resulting from these explosion on one client would frequently synchronize to the server, thus also appearing on the other client. By the end of the video below /listships returned 29 vehicles (not counting Kerbals) - See log file in the 'Downloads' section below. Movement is very jittery - It seems that velocity data is not taken into consideration to smooth out the movement of the other received vehicle data. The opening of the docking covers does not seem to be synchronized for a long time if at all, making docking impossible since each client saw the other client's rover as having its docking cover still closed. Downloads For the sake of debugging, here are downloads relevant to the above video: Rover Craft Files KMP Server Log File KMP Server Universe Request I would like to encourage the devs to attempt to recreate my test as demonstrated in the video above, and to prioritize fixing the fundamental issues shown (vehicle explosions, movement jerkyness, part states such as docking shields not syncing at all, etc) over new features like mod support, which I personally feel are much less critical for the mod to even be at all usable. Lastly, here is a summary of all the obvious issues that I could see in the above video (some of which are probably already in the bug tracker): 1:47 - With both rovers outside the bubble, neither client can see the other's rover 2:10 - After switching to the tracking station, client 1 cannot see the rover of client 2 (I'm aware that this is a known issue on the bug tracker and not something that can be easily fixed) 2:38 - After disconnecting, client 1 attempts to reconnect, but gets a sync timeout (this really shouldn't happen on a LAN) 3:05 - After connecting successfully and switching to the tracking station, client 1 sees two instances of 'Rover_2', one controlled by client 2, the other not 3:32 - Upon resuming control of Rover_1, client 1 sees Rover 2 'poof' as it is syncronized 3:40 - Client 1 can now see client 2's rover (having disconnected and reconneted) but client 2 still cannot see Rover_1. 4:00 - On client 1, Rover 2's seems to teleport to its new position every fraction of a second, in a weird 1-2, 1-2, 1-2 jitter, about every 300ms. 4:42 - Client 2 disconnects and reconnects, and sees 3 instances of Rover_1 in the tracking station, one of which is controlled by client 1. 5:16 - Client 1 disconnects and reconnects, and sees 1 instance each of Rover_1 and Rover_2 - It seems that multiple instances only show up in the tracking station when one is being controlled. 5:34 - Upon resuming control of their respective rovers, client 2 sees Rover_1 explode a few seconds after resuming control of Rover_2. 5:52 - Debris created from the explosion that was visible only to client 2 now begins to appear on client 1 6:02 - On client 1, Rover 2 flickers between two positions for a few seconds before settling 7:03 - Both clients having disconnected and reconnected, Client 2 once again sees Rover 1 Exploding - it seems that the second client to connect sees the explosions. 7:27 - Client 2 opens the docking shields on Rover 2. This is not visible on Client 1. 8:26 - Client 1 opens the docking shields on Rover 1. This is not visible on Client 2. 8:35 - With their respective docking shields open for both clients, Client 2 attempts to dock to Rover 1. This fails since both clients still do not acknowledge that the other client's rover has their docking shield open. 9:14 - Client 1 attempts to EVA. The kerbals movement as seen by client 2 is very jerky, and small movements are often not even registered, showing the kerbal spinning in on the same spot (see 9:38). Also many pieces of debris that are touched by the Kerbal *poof* out of existence. 10:10 - Client 2 attempts to EVA. While still attached to Rover 2, client 1 does not even see the Kerbal, but instead repeatedly sees poofs of smoke. 10:22 - As Client 2's Kerbal lets go of the ladder of Rover 2, client 1 sees Rover_2 break apart 10:30 - The breaking of Rover_2 that occured on client 1 is now synchronized to client 2. 10:38 - Client 1 finally sees Rover_2's docking shields as being open, about 3 minutes and 11 seconds after they were originally opened on Client 2. 11:05 - Client 2 attempts to board Rover 1. However the message "Cannot board a full module" appears, despite the fact that Client 1 has EVA'd the kerbal from Rover 1, and the module should be empty. 11:25 - Client 1 attempts to board Rover 2, but is unable to even see the text to grab the ladder. The same is true when Client 1 tries to grab the ladder on Rover 1. 12:25 - It should be noted that at the end, Client 2 still could not see the docking shield of Rover 1 as being open.

Server-side mod control is in the works: https://github.com/TehGimp/KerbalMultiPlayer/pull/454