4x4cheesecake

Maybe it's just me, but I wouldn't split a 4 min burn.Thats just not long enough. But if you really want to split that burn, don't bother about timing that much, because the timing is getting less relevant when setting up a long distance trajectory, it's more about precision regarding the burn direction and duration. So what I'm doing when splitting a burn is: setting up one maneuver that brings up an encounter and then perform the burn but pretending, it is only a 4 min burn (what a coincidence^^), so 2 min before and 2 min after the node, pointing to the maneuver marker on the naveball. I'm actually not sure if it is possible to add just +1 orbit to the node, I'm always getting wrong deltaV numbers when I've tried but I'm using the maneuver node evolved mod, maybe thats the problem. Due this problem, I just delete the node a place a new one direct at Pe (that is exactly where the old node was), and setting up the maneuver like before. Repeat until I have reached my desired orbit/encounter. Maybe not a perfect strategy but its working fine for me If you don't belive me when saying the timing is not a big deal, you can actually try it: While in LKO, set up an maneuver to encounter eve and write down the required deltaV. 100km LKO orbital period is ~30min, so add 2 more orbits to your node and change the vectors to get an encounter again. The difference between your new deltaV and your old deltaV should be some where around 0.5 or 1m/s. So you need 1m/s more deltaV if you are 1 hour late on your transferwindow. If you want, you can split your 4min burn into 4x 1min burn and starting the first burn at the perfect transferwindow, be ~8h late on your transferwindow when finishing the final burn which will cost you a tiny amount of deltaV to correct that, but you will safe a lot more fuel by using the oberth effect more efficent. I guess, you can even split the time for the transfer window like a maneuver node time (start 4h early and finish 4 hours late) but this will only save some fuel in your correction, which is already just a tiny amount.

Do you know about the debug menu? mod + F12 (can be strg+mod+F12 if you have a NVIDIA GPU and GeForce Experience installed) brings up the debug menu and there are also some cheat options available, for example: setting an orbit. So whenever you want to test something, you can place it on your launchepad and bring it to orbit with one click. There is also an option to rendevouz another vessel which will place your active vessel in ~100m distance to the choosen target. As long as you dont want to test your launchvehicle, this will help a lot. Be carefull when using the "Hack Gravity" option, that can mess up the orbits of EVERY vessel you have in space (gravity changes are applied to the whole universe, not just the planet/moon you are on).

Have you tried to clear your input lock when this happens (debug menu -> input locks -> clear input locks)? Maybe at least a workaround so you don't have to restart your game everytime.

Well, selfmade rescue missions are actually fun^^

This will help you: https://steamcommunity.com/sharedfiles/filedetails/?id=889624474 Follow the steps, keep in mind that ksp 1.3 release date was May 25, 2017 and you should be able to download ksp 1.3 through steam. Not as comfortable as the beta program, but it is possible.

You don't need to put a docking port on a hatch, your Kerbals can crawl through everything (even a fueltank), so place your port where ever you want. But If you really place a docking port on a hatch, this will be obstructed and kerbals cannot go out for EVA through this hatch. Refuelling CAN be different because there is a difficulty option for "parts obey crossfeed rules" (or similar, should be off by default on normal difficulty, dont know for other difficulty settings). If this is ENABELD, you can not refuel if there is a heatshield or some other parts between your dockingport and the tank. Sometimes you can place fuellines to cross the section which does not allow fuel crossfeed but don't forget that fuelline can only transfort fuel in one direction, so you MUST place two lines (one for each direction). Parts that don't allow fuel crossfeed are labeled in the editor. If this option is disabled in your difficulty settings, you can always refuel a docked vessel.

@MissMolly Well, I cannot replicate the exact error but everythings works fine when I launche from the KSC launchpad. Your log says you have used the Woomerang launchpad and like you, I cannot launch there. Can you please try to launch from the KSC launchpad too? edit: Ok, I was a little bit stupid. RemoteTech had no connection at Woomerang launchpad so I wasn't ablte to launch there but after removing RemoteTech (but keeping the parts) everything was fine again. Well, the rockets tips over even though there are launchclamps but I was still able to launch (and revert and launch again and revert and launch again...) So, I cannot replicate your problem here. Looks like it's none of the part mods, HangerExtender works fine too, I cannot find any parts in your .craft file with unwanted, duplicated parts (with no parents)...actually, i ran out of ideas

@MissMolly Can you tell me which of your mods contains the hydrogen scoop (maybe just search for "hydrogenscoop" in your gamedata folder)? Thats the only part i cannot find anywhere and I want to do some tests after deleting parts in the craft file.

I'll take a look at it, may take a while.

I'll try it: 1) Download and install Microsoft Visual Studio (Community Version is free to use). During the installation, be sure you will install the packages ".NET Framework 3.5-Development tools", "C# and Visual Basic Roslyn-Compiler" and "C# and Visual Basic". You can find these in the "single component" category. If you have already installed Visual Studio, you can check for these components by starting Visual Studio -> Tools -> Get Tools and Features. This will start the installer environment, click on "modify" and you will find the component list there (had to translate the install environment for my self so the names my be slightly different) 2) Download and unzip the FAR source code AND the actual mod FAR v.0.15.9.1 3)Open "FerramAerospaceResearch.sln" (located in the FAR source code folder) in Visual Studio 4)On the right site, you will see the "Solution Explorer" containing the FAR files. 5) There are TWO projects: "FerramAerospaceResearch" and "ferramGraph" and both of them got a "References" list. Expand the list and you will see all requiered references. 6) Some of these references are marked with a yellow triangle, you need to fix this. Right click "References" -> "Add Reference" and click "Browse" in the new window. Browse to "your_installfolder_of_KSP 1.4\KSP_64_Data\Managed" (be sure it is your 1.4 install) and search for every .dll file which is marked with an yellow triangle (should be Assembly-CSharp.dll, KSPAssets.dll, UnityEngine.dll, UnityEngin.UI.dll and ModularFlightIntegrator.dll (THIS ONE IS LOCATED IN YOUR FAR v.0.15.9.1 FOLDER[not hte source code folder, but the mod folder]) After all .dll files are added, click "OK" and all yellow triangles should be gone. THIS NEED TO BE DONE WITH BOTH PROJECTS 7) Open "CompatibilityChecker.cs" (listed in the Solution Explorer, inside of the FerramAerospaceReasearch project) 8) Search for "return Versioning.version_major == 1 && Versioning.version_minor == 3;" in line 61 (you may have to expand the source code by clicking the small + und the left side) 9) Change "version_minor == 3" to "version_minor == 4" 10) Save 11) Open "Properties" (also found in the Solution Explorer and inside the project). "Application" Tab should be open, check if the Target Framefork is set to ".NET Framework 3.5". Switch to "Build" tab and change the Configuration from "Active (Debug)" to "Release". Check your "Output path" (should be bin\Release but you may want to change this) 12) Your Visual Studio toolbar contains two drop-down menus, one of the shows "Debug" the other "Any CPU". Change "Debug" to "Release". 13) Compile (Click on "Build" -> "Build Solution") 14) Browse to your Release folder (you may have set in step 11). If you haven't changed the output path, it is located in "your_source_code_folder\Ferram-Aerospace-Research-0.15.9.1_Liepmann\FerramAerospaceResearch\bin\Release" 15) Pick your new "FerramAerospaceResearch.dll" and "ferramGraph.dll" and replace these with the .dll files in your mod folder of FAR. (I'm not sure if you have to replace the "Scale_redist.dll" as well) 16) Done I guess there is a reason for ferram4 to use this compatibility check so no guarantee everything will work properly. (You can recompile any mods for a new KSP version by loading the source code and setting the references to the latest .dll files in KSP, obviously on your own risk) edit: If FAR is still not running, try to recompile the ModularFlightIntegrator.

Forgot there is a mod list inside of the output_log, so thats already done A craft file would be still nice, I'm quiet curious if you ran into the very same issue I had before or if it is 'just' a mod problem (infernal robotics is marked as WIP, UbioWeldingInc has some limitations and is incompatible with infernal robotics hopefully you had this in mind and didn't try to weld some robotic parts together!)

As long you are not using a mod like Craft History or you have made several different saves while you build the ship, there is no way to go back. Is that the correct link? Cannot find a output_log there. The other ship you have tested, does it contain mod parts? If not, try to reproduce this bug in a pure stock game, that would be great if you can reproduce the bug (which is the first step to a bug report and hopefully a fix). If you can provide me a .craft file, I can try to fix it like I did it before with my ship, but no guarantee. (And if mod parts are involved, a mod list would be nice too)

I guess thats covered:

I'm sorry, missed that entry while checking ingame.

Even on the screenshot, it looks fine for me. If removing the mods does not help and if you haven't done already, you may want to check the antenna state via right click. Same for the batteries and the probe core, just to be sure everything is actually operational. Honestly running out of ideas (must be something so obvious, nobody thinks about xD) edit: Maybe try to launch the very same probe again and check if this one is working?

Tweakscale can be the reason but every mod can mess around sometimes but since the error seems to be in your .craft file, any editor mod like tweakscale is more likely to cause this issue. Actually, I think it is the re-root function of the editor (or re-root in generell because this happend to me after docking which also causes a re-rooting of parts). Would be convenient if you have used this option too?

Well, I'm out of ideas then. I've recreated your situation as good as I can, following your description but my probe is getting an connection. Hopefully someone else can help you.

Well, I guess its a girder (or a launchclamp? Not sure about the hierachy path): WRN 10:45:57.214] BoxColliders does not support negative scale or size. The effective box size has been forced positive and is likely to give unexpected collision geometry. If you absolutely need to use negative scaling you can use the convex MeshCollider. Scene hierarchy path "KzInterstageAdapter2/RSBtankSaturnSII/RSBdecouplerSaturnSII/RSBtankSaturnSIC/launchClamp1/launchClamp1/model/launchclamp/obj_girdercap/obj_girder/obj_girder_mesh" Had a similar error some time ago but with a cubic strut. You may have to delete and replace any girder(try to replace your launchclamps too) you have used. If it is the very same error like mine, you can also check your craft file in an texteditor, scroll down to the very end of the part list and check if there are two identical girders. If so, delete the last one and try to start your vessel again. This can break your craft or fix it, so you may want to make a backup copy If the craft is not very complex, a rebuild may be the best solution.

Correct but you have to be in the main menu to find the "advanced tweakables" in the "Generel" tab

Ok, sounds like you had only one relay in Kerbin orbit Read my edit for another idea ^^

Are you sure that you have a stable connection between KSC and the mun relays? Sounds pretty unstable to me with just one relay in Kerbin orbit. edit: Just another thought: Have you increased the "Occlusion Modifier Atm" in your difficulty settings? A value above 1 allows the atmosphere to block your signal (a least if the line of sight got a very long way through the atmosphere). Lower the value just to check if you can get a connection.

Actually, you can 'cheat' on these contracts because it is not necessary to deliver the fresh ore...any ore will do the job. So you can send a small drill probe down to Eves surface to get the contract update on "acquire 900 units of fresh ore" and then land another vessel on gilly, having already 900 units of ore on board (brought vom Kerbin) or drill on Gilly for 900 units of ore. I guess that is "semi-intendet" so you cannot stuck on these contracts by having a surface refuel station which may get the update for acquiring the ore but will never be able to deliver it anywhere (or it is not intendet at all since you can dump ore but this will not revert the contract update). Having this feature/bug in mind, a SSTO carrying a drill probe and an ore tank can do this job easily because you don't need to land on Eve but Gilly. But since this is considered as a challenge I'll try it as intended

Well, I would consider most of the issues as minor, except for the QuickHide settings window. I'll definitly take a look at the release version (I actually want to use some of these mods). I guess I'm not going to do a full blown test for all of them again but a check up for the known bugs is totally doable

These are some pretty nice suggestions I would also like to get a possibility to influence the contracts showing up in mission control. Strategies to get more contracts of a kind are nice but it would be even better, if we can also exclude some vessels from contracts. I know, it is possible to decline as contract but why should i spend my hard earned reputation to decline an illogical contract like "adjust the orbit of 'ComSat Relay Alpha1'" or "Extent station 'Duna Base Delivery'". ComNet Relays are usually well placed by the player and as soon as a ship got space for 5 or more kerbals, the game suggest this is spacestation (even though it is a base which needs to be delivered or even a big tourists ship). Would be nice to get "Extent station xyz" contracts only if there is a vessel marked as "Station" and probes marked as "Relay" shouldn't be considered when new contracts are created. It would be also more logical if an agency ask you to launch a probe and after some time, the same agency ask you to adjust the orbit of the probe you have launched ealier. There is absolutly no reason for an agency to adjust the orbit of an probe or relay, which is placed by the players choice.

Well, I've played around with unity engine 5.5.0p4 and it is really nice to have a realtime preview, but after loading the settings into the KS3P mod, the effects looks a bit different. For example: In the unity engine, I reduced the vignette effect to be very subtile but visible but after loading the very same settings in KS3P, the vignette is not visible at all. Also, I wasn't able to set up ambient occlusion in unity engine 5.5.0. While ambient occlusion was active, the whole "game" scene turned into a grey screen (I spawned a blank terrain and a simple sphere with some textures) So, I guess the unity engine version is important, but wich one should I use instead?