EmbersArc

Did you install Kerbal Joint Reinforcement? The behavior you're describing could come from that. I'm pretty sure it doesn't have anything to do with KRE. Also nice ship, I like seeing the parts being used in creative ways.

Sure, go to the GameData/KerbalReusabilityExpansion folder and delete anything you don't need. Hard to tell what the problem is without more information. First try reinstalling just KRE, if that doesn't work try it without any other mods. As a last resort a clean installation of KSP should fix it. The original purpose of autostrut was to strut the landing legs to the heaviest part. That's what they still do by default if I'm not mistaken. Not sure why you had no issues before. You mean the last update of KRE right?

You're right. Forgot to tell it to check for TweakScale first. I've uploaded a new version. As you see I haven't done much in terms of testing. So keep letting me know if things don't work.

Update 2.3.1 2 Reformatted textures (memory demand reduced by 40%) as suggested by @RGBPeter Tweakscale support: Each part is scaleable in a limited range when Tweakscale is installed (so that you can't scale up the small legs to be as big as the large ones) Added crossfeed toggle to heatshield decoupler Download from Spacedock Unfortunately it doesn't seem to be possible to fix the heatshield deltaV bug as it is not necessarily a bug. The issue might be on the KER side as @swoosh pointed out:

Okay I've been using this mod for a few weeks now and love it. It was an important part of this reddit post: https://www.reddit.com/r/KerbalSpaceProgram/comments/5td0q9/express_rocket_delivery_krpc/ Now I've run into problems while trying to tweak the code a bit. Maybe someone with C++ experience can help me out. Here's the code: https://github.com/EmbersArc/kRPC_cpp/tree/master/src So far the approach has been to store most variables as global variables (see Drone_AerialGrasping.cpp for example). To make it easier to fly more than one vehicle simultaneously, I've now tried to create a class (the "VesselControl" class) that has all the variables in it and can be constructed by giving it the name of the vehicle. In the current state it compiles fine but throws a segmentation fault when't it's executed. The problem could be the two lines to connect to the space center: Any idea how to implement this so that all functions in the class can access the sc. thingy? EDIT: What does krpc::services::SpaceCenter sc(&conn); return/create? Is it something I can pass to the classes when they are called? EDIT: I now put the class and main function in the same file to make it less complicated. Still the same error though. https://github.com/EmbersArc/kRPC_cpp/blob/master/src/Allinone.cpp EDIT: Found the problem. Made the simple mistake of calling the altitude stream before assigning it. Oops.

Great observation! It looks like this has to do with the decoupling module. KER seems to think that after decoupling, the mass is jettisoned even though it's still there. The cause is most likely the direction of the node. Note that in the VAB it always says "decoupler attached wrong". I'll try to fix it next week while working on version 2.3.1 of the mod.

Someone a while back reported that they would break the leg deploy action group on existing craft. Can anyone confirm that? If that's true then I could try to leave the ModuleWheelDeployment unchanged which might be causing the problem. Download link

Tried -l:libprotobuf.so.11 but the result was the same. Good news though: After reinstalling Ubuntu (at least something I have a lot of experience with) I did everything exactly like it is in the docker file and it works perfectly. Was also able to get it to work with eclipse. Maybe it would be helpful to have exactly those steps in the tutorial for the beginners like me. Just an idea, maybe not. Thanks again.

@djungelorm Thanks for helping. I didn't get the notification that you answered so I kept beating my head against a wall for a bit longer . I just noticed that I was making the stupid mistake of using protobuf version 2. I didn't realize that while compiling it from the first github link in the installation instructions. I've now used the file from the second link (version 3.1.0) and that worked perfectly. Another problem has come up though after running the program: g++ main.cpp -std=c++11 -lkrpc -lprotobuf //usr/local/lib/libkrpc.so: undefined reference to `google::protobuf::io::CodedOutputStream::WriteVarint64ToArray(unsigned long, unsigned char*)' //usr/local/lib/libkrpc.so: undefined reference to `google::protobuf::internal::GeneratedMessageReflection::NewGeneratedMessageReflection(google::protobuf::Descriptor const*, google::protobuf::Message const*, int const*, int, int, int, int, int, int)' //usr/local/lib/libkrpc.so: undefined reference to `google::protobuf::internal::MergeFromFail(char const*, int)' collect2: error: ld returned 1 exit status Did I confuse it by first installing version 2 and then 3?

I thought I had ruled that out but just tested it again. Yes you're right. It somehow didn't happen when it grabbed a vessel with a tilted probe core on it. Luckily kOS has a way to set the control point. Thanks!

Okay I've got a (hopefully less confusing) bug report. The whole thing is quite complicated but I'll do my best to explain it. I've noticed that command seats on a vessel can significantly impact the way it flies. If they are empty it's fine, unless you grab vessels with them with a claw. Here's a little gif of what I mean: http://i.imgur.com/E1MeiRe.gifv (First grabs a vessel without then with command seat) If they have a Kerbal in them, the behavior is very similar. Then it doesn't matter if you grab it first or not. As soon as a Kerbal boards the seat the whole thing loses control. This is independent from when the script is launched. http://i.imgur.com/JSTlTcY.gifv The behavior is similar to what you would expect if the script runs very slowly and variables are not updated often enough. Here's a log for all four situations and some more info (The last one is the random steering bug). https://gist.github.com/EmbersArc/b17cf12ab8ce4401a7d8c86f92b38197

Okay I tried it on Ubuntu 16.04 instead. Here's what I did: Install ASIO: sudo apt-get install libasio-dev Install Protobuf: (downloaded source from github) $ sudo apt-get install autoconf automake libtool curl make g++ unzip $ ./autogen.sh $ ./configure $ make $ make check $ sudo make install $ sudo ldconfig # refresh shared library cache. That all worked fine. Install kRPC: (downloaded krpc-cpp-3.7.0) ./configure make at "make" I got an error: ../include/krpc/krpc.pb.hpp:3821:90: error: no matching function for call to ‘google::protobuf::internal::ArenaStringPtr::GetNoArena(const string*) const’ sion_.GetNoArena(&::google::protobuf::internal::GetEmptyStringAlreadyInited()); ^ In file included from ../include/krpc/krpc.pb.hpp:23:0, from ../include/krpc/client.hpp:8, from client.cpp:1: /usr/local/include/google/protobuf/arenastring.h:225:31: note: candidate: const string& google::protobuf::internal::ArenaStringPtr::GetNoArena() const inline const ::std::string& GetNoArena() const { return *ptr_; } ^ Is it missing some part of protobuf? Sorry if I'm being annoying but maybe someone can help.

Yes that's what I mean. It happens every time the vessels dock and I can confirm that both throttle and steering get unlocked. The "ADDON BINDER: Cannot resolve assembly: AGExt, Culture=neutral, PublicKeyToken=null" message seems to disappear when I re-lock throttle and steering. This however is not that big of a problem. More annoying is the first error I described: I'm not sure if it's related. That's the one that pops up about in about 40% of the cases when I launch the script. The log also regularly prints this error: "kOS: SteeringManager.Update: Value is <null>"

Yes it happens every time when the vessels dock. I'm not exactly sure what I'm referring to either. That's just the area where docking happens and thighs most likely went wrong. Maybe it's because of some sort of cyclic docking because there are two ports? If you want I can send you the save and the script to reproduce it. EDIT: Turns out all it does is just unlock STEERING and THROTTLE. I have to reassign those after docking but then it continues fine.

Two more things I noticed: DockingPort:STATE doesn't return "PreAttached" when it's close to another port. Instead it returns "acquire". LIST Command: LIST ListKeyword FROM SomeVessel IN YourVariable. It always freaks out about the "from" when I write "LIST DockingPorts FROM Vessel("somevesselname") IN somelist".

I'm trying to get into kRPC but I ran into trouble installing the libraries. I'm not very experienced with Visual Studio and couldn't find much on how to install those libraries. It looks like that's just something I'm expected to know. I've downloaded Asio 1.10.6 and Protobuf 3.1.0 for C++. Can someone maybe quickly walk me through how to install those libraries and configure VS to run scripts? Or is there a more detailed tutorial somewhere that I haven't seen?

Okay here's the log: https://gist.github.com/anonymous/ac4a61dd54b9715519a3f1753b423d2e The first error (nullref on lauch) is from lines 4461-4696 and the second error (docking) from lines 4236-4458. 0-4235 is KSP launch to vessel load.

I'm having some problems with my script, maybe someone can help. Maybe those are bugs in kOS but I might be doing something wrong: Here's the script: https://gist.github.com/anonymous/332e30e38f09be0d63ad16d43135fb06 The quadcopter (quadrocket?) picks up an element and places it on the base in the background to build a tower. Each element has docking ports so the whole thing doesn't fall apart. The first problem occurs right when launching the script at line 197 where the steering vector gets locked: The strange thing is that it only happens in every third attempt. In the other cases it launches fine. If I try to launch it again after this error it gives me the following error: Which probably makes some sense because assigning the steering vector failed. --- The other problem happens after the part is docked with the base right after this: After docking, the ship unlocks throttle and sets it to 0. It just sits there while the program is still executing. It looks like the problem occurs after line 244 since that's the last thing it prints. Could it have to do with the automatic camera adjustment or switch to a different vessel right after docking? Or is it because there are two docking ports? Let me know if you need some more information, any kind of help is appreciated.

Thanks for pointing that out, I'll convert them to DTX1 in the next update. Can you elaborate on those issues? I'm not aware of any problems with the collision mesh.

I've implemented cascading control for the Dragon's orientation which means that it can recover when it's spinning. Here it is starting a rotation on purpose and then recovering from it: https://gfycat.com/somenaiveconey Honestly I don't think it's necessary. If there's a specific part that just doesn't make sense then don't hesitate to ask. Here's the new code, it's a bit more elegant: http://pasteall.org/168444

Sure here you go: http://pasteall.org/163505 Tweaked it and added cascading attitude control: http://pasteall.org/164260 At the moment you can enter any position (lon, lat, alt) and it will try to fly there. I had another approach for landing where it controls the speed vector to always point at the target. It's more efficient but less reliable.

The script for controlling a Dragon with differential throttling in action. The reaction wheels and SAS are turned off and all steering happens with thrust adjustments on the four SuperDraco engines.It can be commanded to fly to a predefined place and will do that without any further input.This is the first step and I will improve the script to do some more crazy things. Using the error from the steering manager turned out to work perfectly for that.

@kcs123, @hvacengi thanks! I'm trying to make a script to use differential throttling to control a Dragon v2 capsule for a point landing. I thought there might be a way to just tune the steering manager and use its output to adjust the thrust limit on the individual engines. Access to the output might or might not be helpful for that, just thought I'd try that first. It even somewhat works with the output from the rotational velocity PID but it's not very elegant. It looks like the best way is to make it from scratch after all.

Hey everyone, while writing a script I noticed that it's not possible to take the output of the steering manager's Torque PID (does not change ship:control:pitch and directly controls the steering). So I attempted to write one myself based on the output of the Rotational Velocity PID. According to this the output should be the desired rotational velocity. However this only gives me an extremely low number (~10^-17). Am I misinterpreting it or is that just what it does and it has to be multiplied by 10^17 before it can be used?

If I remember correctly then this was a bug in 1.1.3 happening with all docking ports. Haven't tried it myself but this seems to add a workaround: I did some tests and it worked with both docking ports. The colliders don't extend past the visible mesh. However I noticed that some of them were duplicated which will be fixed in the next version but that probably wasn't the problem. Can you provide some screenshots?