JohannesMP

Thanks @4x4cheesecake and @OHara, that does clarify some things. As far as I understand it now, you will only see a difference with the Parent and Vessel options if your parent part is not inline AND not attached with symmetry. What the Vessel/Parent Symmetry Setting Actually does Given this vessel: Attaching a part to the non-inline part in 3x symmetry with Vessel symmetry results in this: The parts are mirrored as if around the root of the vessel axis, but positioned over the parent part. And attaching a part to the non-inline part in 3x symmetry with Part symmetry results in this: The parts are mirrored around the parent part's axis. Note that this no longer works if the parent part you are attaching to is itself symmetrically attached. Then all attachments to it will behave the same way they do with the Parent option selected on a non-mirrored parent part. Here is a video showing the above details: As shown in the video posted by @4x4cheesecake, if you are attaching a part to another 2x symmetry part, hitting the symmetry hotkey (X) will perform the behavior I was originally expecting. Sort of... What hitting X in 2x symmetry does You have to use the hotkey while mousing over the part, because the behavior disappears once you mouse off the parent, so clicking the symmetry UI button is not an option. However even more interesting, if you hit X to enable this local symmetry, now hitting F will actually do something again. This results in 3 possible ways to attach a child to a 2x parent symmetry: Default: radially around vessel axis, one on each parent part After hitting F: In Parent mode: The part is mirrored around the parent part axis, on one side only In Vessel mode: The part is mirrored around the vessel axis, but translated onto the parent part: Once again it should be noted that 2 and 3 above only work if you hit X while the parent part is in 1x or 2x symmetry. Whew, ok, I think that covers it?

Overview When in the editor (VAB or SPH), and placing a part with radial symmetry enbled you have access to the Radial Symmetry Space Option, which is supposed to let you switch between having the symmetry mode be relative to the vessel, or relative to the parent part. It appears that while this option has a hotkey, as well as an on-screen button, its toggle state does not actually currently affect object placement; The part placement always defaults to using the vessel as the axis of symmetry and not the parent part. Details Given this simple vessel which has two tanks (FL-T400 Fuel Tank) on radial decouplers attached to a larger central tank (FL-T800 Fuel Tank) using 2x symmetry: The default behavior for attaching a small spherical tank is to do so relative to the vessel. In other words, The spherical tank is placed with the axis of rotation being through the center of the vessel: In the tools section there is an Option that toggles between "Vessel" (Default) and "Parent" Which when pressed displays the corresponding notification: This option can also be toggled by hitting the F hotkey, described on the Key bindings wiki page as "In place mode: Toggle Symmetry between vessel or parent part". With it set to "Parent Part", I would expect the spherical tank to now be mirrored relative to is parent part (the FL-T400 Fuel Tank), which would look like this: However this is not currently the case. The above image was mocked up using single symmetry, and was not achieved using the "Parent Part" setting. Here is a gif screen capture showing the issue: https://imgur.com/p0jLF0y Note how despite being in 'Parent' mode and the on-screen notification saying "Radial Symmetry around Parent Part", the spherical tank is not mirrored around its parent part, the FL-T400 Fuel Tank, and is instead always mirrored around the vessel's center part, the FLT-800 Fuel tank. Summary Am I correct in my assumption that when the Radial Symmetry Space Option is set to "Parent Part" that objects should be placed in relation to their parent part, and not the vessel? If not, I would really like to know what this option is intended to do otherwise. Tested using KSP 1.4.5.2243 (WindowsPlayer x64) en-us Note: If an admin could move this topic to the Technical Support (PC, unmodded installs) forum, it would be much appreciated.

This information is available on github: https://github.com/TehGimp/KerbalMultiPlayer/issues I would suggest filtering the current issues by milestone for 0.1.6.0, and sorting them by 'Recently Updated', as you can find here: https://github.com/TehGimp/KerbalMultiPlayer/issues?direction=desc&milestone=5&page=1&sort=updated&state=open For a list of fixed issues just click the closed' button instead of 'open'. Most of the work currently is still being done with resolving various positioning issues, specifically regarding issues #436, #509, #659, #731 and #734. Some good work has been done there, mostly via Godarklight's 'orbit' branch, and we have had some good success with small-scale testing with people in the IRC (see Godarklight's signature). I would say that these issues are probably the core of what still needs to be done for 0.1.6.0. Just as an example of why it's not quite ready yet, just recently I did some testing and had this problem: https://www.youtube.com/watch?v=lvHXFPaf6wc Although that has probably been resolved by now.

darklight: did you fix the camera-resetting-while-spectating issue? In the it happens a few times, but I didn't notice it in the at all.Asking since I've been meaning to make an issue report regarding that. Is that fixed now? Do these changes also benefit viewing vessels out of spectator mode? Like say, if you had client1 sit on the runway and client2 was flying overhead.

Hmm, yeah exactly what you described there is what should happen normally. Switching to a controlled vessel -should- just have you spectate it. Is his server (and your client) running the latest development build?

One thing I would also just advise to check is that everything is installed in the correct locations: (click for full size) Just make sure that nothing is out of place. What version of mac OS is he running? What version of KMP is he running? have you tried the developer build? (see godarklight's signature) Lastly just for future reference:

We would probably need some more info from your friend there before we can help him. For the record, I personally run KMP on mac and experience no such crashes. What version of KMP is he running? What kind of a mac is he using? We would probably need to see his Player.log file to see what is causing the crash. He can find it in Macintosh HD/Users/<his username>/Library/Logs/Unity If he is running Mac OS Lion or Mountain Lion (10.7) or later, his Library folder will probably be hidden, so he may need to follow a guide like this: http://osxdaily.com/2011/07/04/show-library-directory-in-mac-os-x-lion/ - in Mac OS Mavericks (10.9) you can set it as a preference when you have the User folder open, then open the view options (Command+J), and check 'Show Library Folder'. Once you have the log file, you or your friend can upload its content on www.pastebin.com or www.dropbox.com, and then post the link here so the devs can look at what might be causing the crash.

At the time of this writing 0.1.6 is 87% complete (72 issues closed, 11 remaining) and has a listed due date of Monday, 24 March 2014. (see list of remaining issues on github). However to be clear, the due dates for this and previous Milestones have been moved back on several occasions and are not something you should become too attached to. Simply put, even tentative 'guestimation' is very difficult with an iterative project like this. All issues are not created equal; Some can be fixed quickly if someone sits down and dedicates their time to it, while some others would require considerable more work to complete and need to be tested after each iteration, which makes it effectively impossible to reliably predict how long they will take. As godarklight said above, on a few of these issues it's getting to the point where it's not just an easy fix, and will require a considerable amount of massaging KSP to do stuff that it is not currently designed for. I would suggest instead of looking for a date, just keep an eye on the issues that are left on github and how they are progressing. Then you can decide for yourself how much longer you think it might take. In any case, when 0.1.6 is released officially is I think irrelevant. If you really feel passionately enough about it then you can poke over to godarklight's build server and grab the latest test build whenever a new one pops up. They're generally already far more stable and usable than the current 0.1.5.1 builds, and is also quite easy to set up. You can hop onto the IRC as well if you need any help.

I'm not completely certain, but I think science is currently handled client-side, and is not stored on the server. Someone confirm or correct me here just in case.

That should be listed on your Dev server page, like in its own section titled "KMP Testing Servers"! They're specific to testing and so are relevant to show there, even if they already appear on the general server list. In any case, in a day or two that post will be buried and no-one will want to search the forums for it. I'd almost be tempted to say 'add them in your signature', but that might be going a bit far

Port forwarding is only necessary if: you are behind a NAT (a router) you need someone outside that NAT to access your server. For a more detailed explanation of why and when you need port-forwarding, please see this post Since for testing you only need to connect to yourself, you don't need to port forward. Heck you don't even need an internet connection at all, just use 127.0.0.1 (local host) as the IP in the server browser when connecting.

Your best bet there is to come on the IRC and ask people there. Godarklight has a development test server he uses occasionally, and he lists a server in the 'Development Clients' section of his build server page, but I'm not sure it's using that version. You can also always run the server yourself locally. It's pretty easy to set up.

As of right now, you can find the latest version on godarklight's build server - if you ever need to find the link, look at his signature here on the forums. Installing it is a little more difficult than the version that's on Spaceport, since it does not include the readme. Here is what you have to do if you want to run the absolute latest version: In the "Development build" section in the top-left corner on the build server, download the latest 'CLIENT PACKAGE'. - If you want to host a server, you'll need to also download the latest 'SERVER PACKAGE' right below that. To install those you can for the most part refer to the readme that is included in the build from space port. After unzipping the client package you will need to move the contained KMP GameData folder into your Kerbal Space Program's GameData folder, and move the KMP save folder into your Kerbal Space Program's save folder. - For Hosting a server you will need to look at the readme from the build on the spaceport; it describes which dll files you need to copy into the server folder and I don't remember them off-hand. At this point you will have the latest 'official' development build installed, but because TehGimp666 is gone for a while, godarklight has been working on his own 'unofficial' branch which includes the newest changes and bugfixes. The next steps tell you how to apply the unofficial changes. They will eventually be included in the official version, but we need to wait for TehGimp666 to come back for him to add them. You can then follow the instructions further down on the build server in the "Update while gimp is away" section. The link there will show you the latest version of the two files that update most frequently: "KMPServer.exe" and "KerbalMultiPlayer.dll". For the client, you will have to download this new KerbalMultiPlayer.dll file and replace the old one that you installed back in step 1. (in other words, you will want to replace Kerbal Space Program/GameData/KMP/Plugins/KerbalMultiplayer.dll with the new dll). - If you want to run the Server then you will replace both the dll and the exe that came in the download in step 1 with the new ones.

Just as a general disclaimer, not to discourage anyone from trying out KMP, but please be aware that it is indeed still very much a 'pre-alpha'. That means the following: In many aspects, not just lack of manuals, the Mod is still not as user friendly as it could be. I personally would discourage anyone from trying to use it if they are not reasonably comfortable with things like Port Forwarding, using a Terminal/Command-line to run scripts, compiling source-code or managing a database. That is not to say you won't be able to figure it out if you don't have that kind of experience but your mileage may vary. Regarding the 'Manual' being out of date: The Mod is still early enough in development that its functionality will changes very frequently, and time is often better spent working on fixing bugs than re-writing the manual. Also there are only effectively two core developers (TehGimp666 and godarklight) working on the mod, in their spare time, and so even something as simple as updating a manual can sometimes take a while to get around to. While of course the community could help out there, it also requires an in-depth knowledge of the features of the mod to be able to do well, and it's long and tedious work. I personally wouldn't want to attempt it until at least 0.1.6.0 has been released and some more of the functionality has been nailed down. Also, if you are having difficulty getting the mod to work, please consider jumping on the IRC chat (which you can access via your browser by clicking here), so we can try and help you in person. If you are getting errors where it says that a directory was not found, please double check that you have everything in the right place. Here is a visual reference: (click for full size) Note: While the screenshot was taken on mac, the file structure should be identical.

I don't think anyone here would ask you to give 'full access' to your computer... "one of those people" would cover basically everyone here. The whole point of taking a screenshot is that you choose what is shown. If you ever need to show someone something but don't want to show everything on your screen, just use the windows snipping tool: http://windows.microsoft.com/en-us/windows7/products/features/snipping-tool With it you can select a section of your screen, save it as an image and then upload that image on an image hosting service such as imgur. The screenshot at the bottom of this post is an example of where using screenshots helps, because it can convey information easier than trying to describe it in words. In windows you can add command-line parameters through shortcuts: http://vgstrategies.about.com/od/faq/a/CommandLineP.htm What godarklight said is for you to modify a shortcut to the game. The exe itself remains completely and totally unchanged. Another way to do this that might be easier for you would be by adding it as a launch option in steam: https://support.steampowered.com/kb_article.php?ref=1040-JWMT-2947 You can follow the above tutorial, and the launch option you would type in the text field is -kmpdebug. In short, this is what you should see in steam: Though the windows will of course look slightly different, since I'm using mac OS here. This ultimately does exactly the same thing as adding the parameter on a shortcut, and it will only work if you launch the game inside steam (the same way that parameters on a shortcut only work if you actually run the game by using that shortcut). Once that launch option is added, just click 'play' on kerbal space program in steam, and the log file that is created will now include some extra debug information.

While I agree that it might be helpful, there's only so much info that you can put in a readme/opening post/server output before it becomes too bloated and people will ignore it all-together. It's not even fundamental to Unity; Basically every modern computer language is case sensitive, from Java to Python, XML, C and of course C# which Unity and KSP are built on. It's a simple mistake to make, but also one that is easy to figure out when you look at how the server output capitalizes the commands when it lists them on startup. Not to mention In both mine and godarklight's example code it was capitalized as well, so chances are if someone (not picking on Tux-box1 here specifically) missed it there, after we even provided correct code that could have just been copy/pasted, then adding it to a readme probably wouldn't help much either, regardless of how big we make the letters. Also just to be clear I'm not trying to put Tux-box1 on the spot here, goodness knows I've made many far more embarrassing mistakes before My point is that you can't catch every silly mistake people might make and sometimes it's better to only include the most critically important information, and then help potential issues on a case-by-case basis. That's what these forums are for after all

Edit: godarklight beat me to it @Tux-box1 ah yeah, I gave you the line as it is stored in the config file. if you want to set it via the commandline you need to use the correct format for the command: /set mySQLConnString Server=127.0.0.1;Port=3306;Database=KSP;Uid=KSP;Pwd=KSP;Pooling=true; should do it

The standard MySQL connection string syntax should work: https://www.connectionstrings.com/mysql/ As an example, here is the string that I use to connect the KMP server to mysql running locally on the same machine: mySQLConnString=Server=127.0.0.1;Port=8889;Database=KMP;Uid=kmp_admin;Pwd=kmp123;Pooling=true; The only thing I did was add a new KMP Database, and create a new mysql user account - kmp_admin - which for extra security has local access privileges to that Database alone. In general I would strongly advise against setting this up with your root user.

My Previous KMP Tests: Rover Docking test 1 Orbit Test 1 - Setup Orbit Test 1 - Further Testing Docking Test - Attempt 1 Orbit Test 2 Rover test 2 0.1.6.0: Rover test 2 Godarklight has been hard at work fixing various issues and while gimp is away is maintaining his own Dev branch (which can be found as always on his build server). This Test was run using the latest Dev Build, and godarklight's dark-feb-21 branch. Setup Server was configured Similar to previous attempts (default except 1750m bubble). Everything is running on the same machine, two clients, the top-left is called 'Johannes_1', bottom-right 'Johannes_2'. I will be refering to them as client_1 and 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 Quick Summary [FIXED] Issue 692, which caused clients to not be able to see one another when coming out of the bubble seems to be fixed! vessels now appear instantly. [NEW] However when a vehicle is first synced to a client, for the first 3 seconds or so the client will only see the vessel at its original spawn point, and every few frames will see the vessel flicker to where it should actually be, like the server's updates are only applied for a single frame and then reverted. This tends to fix itself after 3-4 seconds. [FIXED] Issue 646, where structural changes on a ship would not sync every 45 seconds as they are supposed to. This seems to be fixed, as changes such as the parachutes activating and solar panels opening seemed to take at most 45 seconds to sync to the other client. This long wait is still far from ideal, but it's a good first step. [NEW-ish] Kerbals seem to take very long to sync, or at least take upwards of 15 seconds to appear on the ladder after EVA-ing. Kerbals appear as new vessels on the server list a second or so after they EVA, so it seems to be a problem with the other clients receiving/displaying them. [Known] While vehicles movement appears much smoother thanks to their velocity being applied between the 1/3 second ticks, Kerbals still only have their position/rotation synced, and so will appear much more jittery than their vehicles. [New(?)] This may have been a one-off, but in one case, where kerbal sync delay was also involved, It took way more than 45 seconds for something to sync: when client_2 saw Jeb_1 appear he flipped Rover_1, which remained flipped for over a minute, and only synced when client_1 made Jeb_1 enter Rover_1 again. [New] On seemingly random occasions the client's camera will reset. When this happens it seems that every aspect of the client's vessel is overwritten with what the server has saved. so for example, a moving rover with its breaks off will have its velocity set to 0 and breaks re-enabled when this camera reset happens. [New] Both times I tried testing this build, one of my clients ended up hard-crashing right around when I was getting in/out of EVA. Maybe just coincidence, but the log in the download below is for the client that crashed which had -kmpdebug enabled, so there might be some info there. Video Analysis (bold timestamps indicate a possible issue) 00:43 - both clients spawn in their rovers 01:01 - Rover_1 leaves the bubble and instantly appears on client_2's screen. nice! 01:02 - For the next ~4 seconds, client_1's sees Rover_1 stationary at the point where it originally synced in (at the edge of the bubble), and Rover_1 appears to flicker to its true location for one frame at a time (probably whenever client_1 receives an update from the server) 01:06 - the flickering stops and client_2 correctly sees Rover_1's position. 01:25 - client_2 proceeds to drive Rover_2 to the bubble's edge. 01:37 - the exact moment Rover_2 is synced two things happen: client_1's camera is reset. Notice how before this happened, Rover_1's breaks were on. After the camera change they turned off, almost as if the update reset everything. client_2 sees Rover_2 rocket off at high velocity, resetting several times until coming to rest at it's actual location (with some broken wheels) 01:42 - client_2 suddenly also has their camera reset. Some things to note: The split second before the camera reset, client_2 sees another copy of itself intersect it Right when the camera resets, client_2 sees its position switch from "Rover_2 Prelaunch at Kerbin" to "Preparing/launching from KSC" and then to "Rover_2 Landed at Kerbin". Before the reset Rover_2 was moving at ~10m/s. During the split second after the camera switch its speed says 174m/s and then 0m/s, so the velocity got reset to 0. 01:44 - after its reset, client_2 now no longer sees Rover_1, and client_1 no longer sees Rover 2. 01:54 - both clients see the other's Rover again, but for a split second client_1 sees Rover 2 on the ramp, on the edge of the bubble where it first initially appeared. 01:58 - client_2's camera is reset yet again, and a fraction of a second later client_1 sees Rover_2 flicker several times 02:18 - client_2 raises Rover_2's solar panel to test if the 45 second sync is working now. 02:22 - client_1 sees Rover_2 flicker from it's stationary position to its 'true' position several times before it syncs correctly 02:36 - Testing if client_2 can see when client_1 turns Rover_1's wheels. It can, and the sync is basically instant! 02:50 - client_1 opens Rover_1's solar panel and parachute (I forget that after activating parachutes appear closed until you move a little to trigger them, my bad) 03:06 - client_1 sees Rover_2's solar panel sync, so the 45 second resync seems to be working. 03:17 - client_2 sees Rover_1's solar panel sync 03:28 - And I finally remember that to appear open a parachute needs to trigger, so I start moving Rover_2 and behold, the parachutes weren't stuck. 04:08 - I decide to EVA client_2's Jebediah (we'll call him Jeb_2). 04:12 - we see a new vessel was added to the universe, so Jeb_2 should sync and appear to client_1. however it takes another 13 seconds (04:25) for him to sync 04:25 - having now appeared for client_1, Jeb_2 seems to go through the same 'syncing' process as Rover_1 did at 01:02 - he remains stationary and flickers to his actual location several times before starting to sync correctly a few seconds later. 04:29 - as Jeb_2 walks it becomes clear that the kerbal's velocity is not being synced, and he only jumps to his current position every 1/3 of a second when the server sends an update. This looks pretty bad compared to how nice and relatively smooth the Rover movement looks now. 04:44 - Jeb_2 tries to grab Rover_1's ladder (with the hopes of testing if he can enter) right as we experience a huge lag spike, which seems to be because the server backed up the Universe Database right at that second 04:53 - After Jeb_2 gets stuck under Rover_1, client_1's camera resets yet again. 05:35 - Jeb_2 tries to climb the ladder again, and fails. He blames bad Rover design for forcing him to have to use his jetpack to jump. 05:40 - Success! Jeb_2 manages to hold onto Rover_1's ladder. Attempting to board shows us that the module is full, which is as it should be since Jeb_1 is still inside it. 05:51 - Satisfied, we attempt to EVA Jeb_1 5:53 - Similar to Jeb_2 at 04:25, Jeb_1 stands on the ladder and does not appear on client_2's screen for several seconds 06:07 - When Jeb_1 appears on client_2 he is lying under the rover, causing the physics solver to throw Rover_1 into the air and onto its side 06:32 - Jeb_1 and Jeb_2 stand in awe for a few seconds, surprised that actually nothing broke, but client_1 is still seeing an upright Rover_1, while client_2 sees Rover_1 on its side. 06:38 - Jeb_2 decides to investigate the capsized Rover. client_2 sees Jeb_1 colliding with the still-standing Rover, causing it to jump once and break a wheel 06:57 - Jeb_1 goes to fix his Rover's Wheel. He then jumps on the ladder and boards it. 07:11 - over a minute after the rover flipped at 06:07, Rover_1 suddenly appears upright again on client_2's screen. 07:20 - we EVA Jeb_1 again, and a moment later client_2 shows a completely black screen, and hard-crashes a few seconds later. Downloads Rover Craft Files: link Log Files: link (Player.log as well as crash.txt correspond to the left client that crashes at the end of the video)

It sounds like you may need to use port forwarding. This would be necessary if your machine running the server executable is connecting to the internet via a router. In that case port forwarding needs to be set up on said router for anyone on the outside to connect to your server. I explain it a bit more in the first three bullet points here. For help with setting up port forwarding please visit http://portforward.com/

This is a combination of potentially two things: A feature: You need to be outside of the bubble, which is a safety mechanism designed to ensure that you don't collide with someone else on the launchpad/runway. Use the !bubble chat command to check how far you are from the bubble's edge. You'll also be able to tell from the status of the player in the player list: "Preparing/Launching at KSC" is inside bubble, "Prelaunch at Kerbin" is outside of bubble. A bug: While in atmosphere, vessels don't sync until you both log out and in again. You can see this in action in my rover tests, where I list it as issue 2 in the Key Issue Summary section (note: in that test I'm using the latest dev build so it also has some other features/issues). It's been a known issue for a while (bug tracker) and is being worked on. TL;DR: Use !bubble to check that you are out of the bubble, then both log out and in again.

I think this has mostly been fixed in the upcoming 0.1.6.0 update, but luckily you don't have to wait to try it, just look at godarklight's signature for a link to his build server where you can find the latest client and server builds. If you do try it, you'll notice that the KMP window is missing from the KSP startup screen. In the dev build it's now integrated into the main menu:

As far as I know, ships and science are stored on the server, not the save file, and are just sent to your client when you are running KMP; Nothing is written to that file. I would strongly discourage trying to load KMP's save, since it's specifically crafted to be used by KMP and is not used to store universe data. However coming back to your revert problem: while revert is not currently implemented as it works in the normal game, you can easily remove an in-progress flight by switching to the tracking station and terminate the flight from there, or while piloting a ship by clicking the green 'recover vessel' button when you mouse over the elevation indicator at the top of your screen.

You're welcome to add these as individual suggestions in the bug tracker: https://github.com/TehGimp/KerbalMultiPlayer/issues. Try seperating them as multiple issue posts, to make tracking them easier in the future, although you can probably group the features pertaining to teams as one issue for the time being. However most of these are probably still multiple versions away, simply because the core fundamentals are still not done yet. There's still plenty of desyncing and simple issues that need to be addressed and ironed out before most of the features you suggested are even ready to be considered. You've got some good ideas, but I'd be surprised if any of them will make it in before 0.1.8

While this was a known "won't fix" issue for the past few months just yesterday godarklight and I managed to compile a proper 32bit mac dylib. The one comes included in /usr/lib is the one causing the issues. Once #679 is merged this should work. From my tests so far it does not crash anymore (as you can see in the rover test I posted above) If you want you can already manually download the dylib here, then unzip and drop it in a clean instal of the current server devbuild.