giltirn

Hi all, While I have become relatively proficient at using the navball, some things still confuse me. 1) Why is the 'east' line 90 degrees anticlockwise of the north line?? 2) Is there any way, other than trial and error, to determine what the compass directions are relative to the orientation of the camera? I find docking and hovering about moons extremely difficult because I have no way of telling what direction my ship is going to turn when I press WSAD. I would appreciate any help!

The hardest part during the hover/apply thrust diagonally part is figuring out exactly what direction you need to turn your ship. AFAIK there is no way to see what compass direction the camera is facing, so the navball is pretty much useless. I have tried in the past using trial and error but always end up crashing. It would be wonderful if there was some way of projecting the compass directions into the camera view, it would make this, and docking, so much easier.

Hi All, Does anyone know if there is a way to rotate a part on your ship without to detach it? Sometimes I want to slightly adjust the rotation of a part, but clicking it rips the part and everything attached to it from the ship, and unless you clicked exactly over the attachment node, its position shifts to the cursor location and it must be laboriously moved back to its original position, which can be extremely difficult with some of the fiddlier pieces like angled beams.

If we wanted to change the class names in the fixed library to prevent the .dll from conflicting with another installation of mumechlib (which is used by other mods), we would have to modify the part.cfg files. Of course the required changes could just be written down to be applied by the end-user, but this may turn people off.

It appears that DR is a collaboration between r4mon and DYJ. r4mon wrote the mumechlib library, and it is available under the GPL license, meaning that we in the community can modify and redistribute it. The parts were created by DYJ, who has asked for permissions before redistributing. It seems that we can release a fixed .dll and source code, but not the parts.

If you strip back the code then other mods that use mumechlib.dll would probably break, depending on how smart the linker is; either you install only the stripped-back library, in which case most of the mumechlib methods will not be defined that are used by other mods, or else you install the old mumechlib.dll alongside the stripped-back version, in which case there will be multiple and differing definitions of some of the methods - this will either cause the linker to fail or it will load one and not the other with no idea a priori which one to use. Considering mumechlib seems to be no longer supported, it makes sense for the DR author to strip out all the extraneous stuff from the library and to rename the methods to prevent conflicts with mumech.dll. Then the mod becomes independent of mumechlib and changes can be made without the possibility of breaking other mods.

To compile the source you need a C# compiler to compile and link the source into a .dll. I just followed the instructions to set up Visual Studio and then played around with a simple module in the tutorial. In order to compile DamnedRobotics, just download the 4 source files I mentioned from the link in the OP, import them into a Visual Studio project, make the changes from my post, add the 2 .dll files as references that are discussed in the tutorial, then run build. You will also need to add PART { } around the contents of the .cfg files in order for them to be read in 0.20+.

I saw the undefined keys problem too, but I figured that it was probably an existing bug. Being very new to KSP modding I could not immediately see a way to tell the user that keys need to be bound before going to the launch pad - I would be interested in seeing your solution.

Looks like I got beaten to the punch. Did you reach the same conclusion regarding the source of the problem?

To anyone interested: I have fixed the issue with the plugin. Essentially the MuMechToggle class, in its onPartAwake() and onPartLoad() methods, calls a method colliderizeChilds(Transform obj). It then calls the method obj.GetComponent<MeshFilter>(), which returns the MeshFilter object if attached, or null if there is not an instance attached. The problem is that a some point (probably in onPartAwake(), where I understand the object may not actually be built when this method is called) the colliderizeChilds(Transform obj) tries to tell Unity to instantiate the 'mesh' variable contained within the attached MeshFilter, but there is no MeshFilter attached at that time (the reference is null). Modifying the code to check if the MeshFilter reference is null first fixes the problem: In Toggle.cs (http://svn.mumech.com/KSP/trunk/MuMechLib/): protected void colliderizeChilds(Transform obj) { if (obj.name.StartsWith("node_collider") || obj.name.StartsWith("fixed_node_collider") || obj.name.StartsWith("mobile_node_collider")) { print("Toggle: converting collider " + obj.name); if (!obj.GetComponent<MeshFilter>()) { print("Collider has no MeshFilter (yet?): skipping Colliderize"); } else { Mesh sharedMesh = UnityEngine.Object.Instantiate(obj.GetComponent<MeshFilter>().mesh) as Mesh; UnityEngine.Object.Destroy(obj.GetComponent<MeshFilter>()); UnityEngine.Object.Destroy(obj.GetComponent<MeshRenderer>()); MeshCollider meshCollider = obj.gameObject.AddComponent<MeshCollider>(); meshCollider.sharedMesh = sharedMesh; meshCollider.convex = true; obj.parent = transform; if (obj.name.StartsWith("mobile_node_collider")) { mobileColliders.Add(obj); } } } for (int i = 0; i < obj.childCount; i++) { colliderizeChilds(obj.GetChild(i)); } } I recompiled the plugin (note; you only need Toggle.cs, Part.cs, MuUtils.cs and Servo.cs for DamnedRobotics), and tested in KSP 0.20.2.186 (latest Steam build); everything seems to work fine. I will message the author with this fix and ask for permission to distribute a patched plugin.

I honestly think that the exact function of 'end flight' is far from obvious to a new player. It needs more explanation. Something like "Warning: End flight will remove every part *currently attached to your ship* from the game world." When I launched my first space station I was paranoid that it too would disappear when I ended the flight after landing.

This is not broken. SAS modules do not increase 'command torque' (aka rotation power), i.e. the torque applied when you press the WSAD keys. What they do is actually to apply a torque opposite to the direction of rotation of your ship in order to counteract that motion. You cannot control this, it is automatic, and you cannot direct it to make your ship spin faster. If you want to increase your rotation power you have to add more command modules. I find a stack of the small probe cores or an empty lander can usually adds enough for most purposes.

Any chance you can update the original post to include information about what exactly this tool does?

Were you using the subassembly loader mod? If so try removing the plugin - this fixed my performance issues, as well as those of some others I have talked to.

With the maneuver nodes it now seems much easier to do small adjustments. This, combined with the filter on the tracker (FYI you can now use the tracker to take control of debris; using end flight causes it to vanish - a nice way to clean up!) makes me a very happy man!

Gaius asked above, but its worth asking again: how do we deal with mods that come with their own PluginData folder containing misc config files?

Hi all, I have a question regarding probe cores. I tried launching a rocket with only a probe core in control, and while I was able to control the staging I was not able to turn it. However a ship/station in orbit controlled by a probe core can be turned. Is this supposed to happen? Thanks in advance!

Hmm, that's very interesting. Why would adding a small tank between the orange and the mainsail prevent the engine from overheating? Is this a bug?

Thanks for the answers everyone. I guess resource sharing means that I can dock modules to the station that don't have cores? Typically I fly up my module, dock it to the station, then undock the command pod and take it back to Kerbin leaving the station unmanned.

Hi All, I am attempting to build a space station comprising multiple parts connected by docking rings. I lifted the first module, consisting of a couple of fuel tanks, solar panels, batteries and a probe core. I then lifted a second module with a larger fuel tank, some RCS fuel and a second probe core. After I docked the two together, only one probe core appears on the orbital map and in the tracking station - the core belonging to the second module . I have a few questions that I cannot seem to find answers to elsewhere: 1) Is it standard behaviour that the most recently attached core assumes control of the station? 2) Will this second core receive electricity from the solar panels on the first module? If not the second probe core is going to run out of electricity and die as I do not have solar panels on the second module. 3) Do all modules of the station need individual probe cores? 4) Is there a way of choosing which core is active? Thanks for your help!