Benji

Major Update:, new thread:

BenjisHardwiredLogic Version: 2.0.1 Dependencies: ModuleManager.4.2.2.dll Download: Github - Spacedock - Sourcecode Installation: Simply drag the folder BenjisHardwiredLogic into your GameData folder. Description: Benjis Hardwired Logic… ...is a set of four tools to predefine staging actions in your rocket. Fairings can automatically be jettisoned at a given altitude. RCS and Decoupler can be activated at a set time after launch or prior to reaching Apside. Engines can ignite at a set time after launch or prior to reaching Apside. An engine can also be cut when a set Apside is reached. An Apoogee Kick Motor can either Burn-Out, Circularize or Cut-Off at a set Apside. On-Screen appearing messages for all events can be turned on / off (in VAB and Flight). A picture says more than a hundred words, so check out the awesome flowchart in the pdf provided.

haha quackquack

Thanks. I now use these simple automations for all my "launch-vehicles" (as far as this is can be called a concept in ksp). Guidance: I was thinking about using kOS just as guidance computer. Or I'll make a new "hardwire"-automation for avionics and capsules. All my launches would be automated then. For now I steer myself. I used (last time is more then a year ago) kOS for landers on mars and moon's far side. For launches I always found it too tedious to write programs. Never got around writing a flexible enough program that can be used for various vehicles.

Hmm, interesting. Never tried that. But should work. Are you playing RO / RP1? What ksp-version are you playing, any problems? Main purpose for me (reason why I started this project) was to not miss those sometimes relatively short hot staging moments in RO / RP1. ->gave me a reliable way of pushing the early sounding rockets to their limits by hot staging and decoupling at the best possible moment.

BenjisHardwiredLogic Version: v1.2.2 Dependencies: ModuleManager.4.2.2.dll Download: Github - Spacedock - Sourcecode Installation: Simply drag the folder BenjisHardwiredLogic into your GameData folder. Description: A ksp mod to "hardwire"-logic into rocket designs. (At this point: decoupler-staging, fairing-separation and engine/rcs-ignition). Every engine, decoupler or fairing is now disabled by default and can be enabled/disabled by the push of a button in the editor's PAW. Decouplers and also Fairingbases can have a delay assigned (up to 30min 59.9sec). The same for Engines (solid and "liquid") and RCS thrusters. Procedural Fairings (only RO, not the squad basegame thingies) can have a height between 0 and 140 km assigned. Every other value will start counting down once the launchclamps are released. When reaching 0min 0.0s the decoupler will automatically decouple, the engine light up and the RCS become active. Fairings automatically separate at the set height (above sealevel). If the messaging system is activated, 3 pre messages at -10s, -5s and -2s will be shown on screen. Also a on screen message at the actual decoupling, ignition or fairing separation are shown. This will save a lot of space in the StagingList because the whole launcher can be put into 3 stages (or 2, if the 1st stage Engine is immidiatly at 100%, for example if you're using a SolidMotor). But maybe you should just leave your StagingList the way it always was. Else you mess up all the dV and burntime readouts (KER and MJ). The other upside is, you can always stage, decouple and separate fairings ahead of countdown (in case of engine failures). This mod does not prevent that. Example (of your standard launcher): Stages 0-4 un-automated payload-stuff, whatever you wanna put into space... Stage 5 2x radialDecouplers connected to the solidMotors (delayed for 30.5sec) 2ndStageEngine (2min burntime) (delayed for 1min 3.8sec) 2ndStageDecoupler between 1st and 2nd stage (delayed for 1min 4.8sec) payloadDecoupler between 2nd stage and payload (delayed for 2min 4.0sec) procFairing (set for 90km) Stage 6 launchClamps 2x solidMotors (30s burntime) Stage 7 1st stage engine (65s burntime) So, let's look at what will happen, shall we? First spacebar fires the main engine. Once that is spooled up, spacebar fires the solidMotors and releases the launchClamps. Now the countdowns will start. At 30.5s the solidMotors will decouple At 1min 3.8s the 2nd stage will fire. At 1min 4.8s the 1st stage will be decoupled, hopefully the 2nd stage is spooled up by now. At 90km the fairings will separate. 2 minutes 4 seconds after lift off: The payload will be decoupled from the 2nd stage. Changelog: v.1.2.2 - The "Correct me, if I'm wording things wrongly and please spin stabilize" release -Aded a rare 4th Stage and Spin-Motor Option for Igniting and Decoupling -Grammar update: - Editor: Igniting -> Ignite - Editor: Decoupling-> Decouple - Messaging: Jettison-> Jettisoning - RCS with its own correct grammar v.1.2.1 - The "SHUT-UP! I told you not to message me" release -CHANGELOG & README: - Added to the release zip -OnScreen messaging system: - All messages are now schown in the upper center - Messages can be turned off now, forgot to implement that earlier v.1.2.1 - The "SHUT-UP! I told you not to message me" release -CHANGELOG & README: - Added to the release zip -OnScreen messaging system: - All messages are now schown in the upper center - Messages can be turned off now, forgot to implement that earlier v1.2 - The "warn me before doing stuff automagically" release -OnScreen messaging system: - Can be turned off - Shows 3 pre messages before decoupling and igniting at -10s, -5s and -2s - Shows a message at decoupling, igniting and fairing separation v1.1.1 -The "humans want something nice to read" release -inflight PAW change: Circuits are: connected/disconnected instead of active?: true/false v1.1 - The "ON-OFF-Button" release -enable/disable button to disable funcionality instead of 0.0s/0km v1.0 - The "never available, 'cause I forgot to generate a zip file" release -initial release

I took the Staging demo and changed it a bit: #include "KerbalSimpit.h" // constants won't change. They're used here to // set pin numbers: const int potiThrottle = A0;// the number of the poti pin const int ledPin = 13; // the number of the LED pin // Variables will change: int ledState = HIGH; // the current state of the output pin // Declare a KerbalSimpit object that will // communicate using the "Serial" device. KerbalSimpit mySimpit(Serial); void setup() { // Open the serial connection. Serial.begin(115200); // Set initial pin states, and turn on the LED pinMode(potiThrottle, INPUT); pinMode(LED_BUILTIN, OUTPUT); digitalWrite(ledPin, HIGH); // This loop continually attempts to handshake with the plugin. // It will keep retrying until it gets a successful handshake. while (!mySimpit.init()) { delay(100); } // Turn off the built-in LED to indicate handshaking is complete. digitalWrite(LED_BUILTIN, LOW); //register the throttle channel mySimpit.registerChannel(THROTTLE_MESSAGE); } void loop() { // Read the state of the poti into a local variable. int reading = analogRead(potiThrottle); //map it to a range KSP likes reading = map(reading, 23, 1017, 0, 32767); //sending it to the plugin mySimpit.send(THROTTLE_MESSAGE, (unsigned char*) &reading, 2); }

KSP expects throttle values from 0 to 32767. With map(value, fromLow, fromHigh, toLow, toHigh) you can span or reduce ranges. If your readings at A0 give values between 23-1017 you can use the map like this: throttle = map(throttleRead, 23, 1017, 0, 32767); -> 23 gets mapped to 0 -> 1017 gets mapped to 32767 -> Values in between are mapped linearly. I would advice using it like this: This way you get a little deadband to be sure you can reach "zero throttle" and "full throttle" throttle = map(throttleRead, 40, 1000, 0, 32767) if (throttle > 32767) { throttle = 32767; } More elegant: throttle = constrain(throttle, 0, 32767); Sending throttle over 100% to KSP sets it to zero. (It's not KSP's fault, just the way integers work.) Ohh. Is this intentional? Reading your "pitchPin" to control throttle?

My deadband-applying-code looks like this: #define DEADBAND 1500 if(abs(pitchR) - DEADBAND < 0) pitchR = 0; Don't be alarmed by the "large" number. 1500 is about 5%. You can put right after mapping.

@stibbons@Codapop Solved it. SAS_MODE_MESSAGE has to be 28 . I found the commit that causes this (https://bitbucket.org/pjhardy/kerbalsimpit/commits/232b15304532b5e9676671f657d34521c2d4876b) I suppose that is for sane continuation of message-numbering but I suspect the KSP Simpit Plugin (1.3.0.64) still listens to "channel 28". This works: mySimpit.send(28, (unsigned char*) &mySASMode, 1); Edit: But doesn't work correctly. Entered a pull request to fix it. On my machine it fixes it but the helper function is still not working.

mySimpit.send(SAS_MODE_MESSAGE, AP_PROGRADE) does compile for me. But in Helpers.cpp it's send(SAS_MODE_MESSAGE, &mode, 1); -> no matching function for call to 'KerbalSimpit::send(InboundPackets, AutopilotMode&, int)' So, the 1 is the message size [byte], like in mySimpit.send(THROTTLE_MESSAGE, (unsigned char*) &throttle, 2); (Why is it detected as byte and not as int ?) Then I defined it as byte and did some bit manipulation, but it still doesn't compile. -> no matching function for call to 'KerbalSimpit::send(InboundPackets, AutopilotMode&, byte&)' I think today is a day to not think about arrays and/or pointers. Sometimes this is very confusing. And like always everything becomes clear after a minute not thinking about it. That's compileable: mySimpit.send(SAS_MODE_MESSAGE, (unsigned char*) &mySASMode, 1); Like with throttle of course. But KSP doesn't set SAS commands. Aaaaand Arduino library is at 1.1.5 using the IDE. But here (https://bitbucket.org/pjhardy/kerbalsimpit-arduino/commits/all) the latest version is 1.2.1 So I downloaded the library here (https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/) But the arduino IDE still thinks Simpit is at 1.1.5 and there's no possibility to upgrade to 1.2.1 @stibbons, do you have a clue what's happening there?

Regarding SAS Modes. I do this: mySimpit.registerChannel(SAS_MODE_MESSAGE); mySimpit.send(SAS_MODE_MESSAGE, AP_RADIALIN); mySimpit.setSASMode(AP_RADIALIN); ...both ways don't work for me. Obviously I'm missing something there. Anyone have an idea? Found this in Helpers.cpp: void KerbalSimpit::setSASMode(byte mode) { send(SAS_MODE_MESSAGE, &mode, 1); } Very odd, because me using it like this causes compiler errors.

Hey. I looked at the struct for rotation message and found what we forgot. You need to set the bitmask in the rotationmessage: myRotation.mask = 1; if you want to send pitch. = 2; if you want to send yaw. = 4; if you want to send roll. Or in my case = 7; That's all bits combined. Or you can use = 5; for pitch and roll. Similar with myTranslation.mask

Got throttling working. Judging from my tests I think zero throttle is 0 and full throttle is 32767. Maybe that's the reason why you ( @codapop ) need to read 1/3 minimum? Because if I remember correctly 1/3 on a logarithmic poti is half the resistance. Attitude is still not working. I think I also don't now how to write a correct rotationMessage.

Quick question: What range of values does KSP expect? Are the attitude and translation controls ranged from -1024 to 1023 , -512 to 511 or 0 to 1023 ?