cyberKerb

I tried to go through object while reviewing your video, but I'm seriously lacking in knowledge for this. Having said that, I'm going to give it a shot and make a recommendation anyway. @alexustas - Can you remove the "Bounds" BoxCollider that is currently in the PRC Wheel model? This was one of @SpannerMonkey(smce) recommendations. As you can see in the screenshot, it's that specific collider that has contact with the ground and is causing the wheel model (also the wheel collider as well) to float and have no traction. Without that, I think we'll be back in business. Breaking down each of the new modules used in the "modern" wheel config.... ModuleWheelBase - Uses wheelCollider & wheel, may need to tweak the radius number. For reference, I've used the Making history Rover Wheel cfg as a starting point. ModuleWheelSuspension - not sure on this as the "Bounds" BoxCollider is in the way and can't test suspension movement that well. Can't see movement with either option of suspensionTraverse & suspensionNeutralPoint ModuleWheelSteering - might be good, it uses same transform as old file, but within new cfg structure. Steering responds correctly. ModuleWheelMotor - No model reference, should be fine ModuleWheelBrakes - No model reference, should be fine ModuleWheelDamage - using bustedwheel & wheel. Can't seem to break the wheel yet. FXModuleLookAtConstraint - uses K-WheelSuspension - guessing this might be still good as the module hasn't changed from old KSP cfg FXModuleConstrainPosition - removed from cfg as it isn't on other "modern" wheel cfg files FSanimateGeneric (Requires Firespitter) - This seems to animate as expected and allows specifying EVA range to animate/deplay as the previous animation module did. However, I'm not sure on @alexustas view on adding Firespitter as a dependancy Full CFG file for ASET Rover Wheel - also fixed the KIS reference

Module Manager

@alexustas I saw a recent post that mentioned this to help with the hierarchy of wheel. https://imgur.com/a/ohZticD Does this help with re-doing the PRC wheels?

24.FebProgress update after a day in the shed. If the cardboard version were "Alpha" version, I'll call the a "Beta" version and in my head I'm thinking "It'll do for the first mock up in wood". During my attempt to make the housing I found that I'm having difficulties getting a straight cut while on an angle at the bandsaw. Next time I might try doing these on the table saw instead. I've taped the previous cardboard handle as the one I tried to do in wood ended up too thin in two dimensions as well as being quite rough. I need to rethink my order of operations to get the handle looking like I want. For this weekends version, I just used a small roundover bit to soften the edge. I'll probably redo the whole housing again so I can add that 45degree edge that's on the in-game model. I'll also move the screws inwards away from the edges using some blocks onside the housing . So... more of a think about order of operations during the week and then next weekend I'll redo the housing and try the handle again.

Wow - that was some testing. Had good long two attempts at over the last few days and was rewarded with this. I've managed to get blinking LED13 on both an Arduino Uno and Teensy 3.6 using the helloworld test script. Couple of caveats I had to do to work around some ..issues. I still can't get either board to handshake with KSP. I commented out the below line just to see if it would still connect (it was a long shot, but reading the code it's seemed good odds to work for the test) This allowed the board to move to the loop and keep sending the high/low char string every 100ms. while (!mySimpit.init()) Not sure what's up with my setup that forced this (it might be to do with the Teensyduino I have installed...) Anyway, I had to recast the low/high message as (byte*) to get these lines not to error in the compiler. The compiler kept giving the error: no matching function for call to 'KerbalSimpit::send(CommonPackets, const char [4], int)'. Checking KerbalSimpit.h I see the send function declared as: void send(byte messageType, byte msg[], byte msgSize); Should the type conversion from char to byte happen automatically and it's just not for me? Below was my work around. if (state) { mySimpit.send(ECHO_REQ_MESSAGE, (byte*)"low", 4); } else { mySimpit.send(ECHO_REQ_MESSAGE, (byte*)"high", 5); } The other data type issue that was stopping the helloworld script from compiling was an if statement in the messageHandler function. The msg[] variable is set to type "byte msg[]" This wasn't being allowed as the strcmp function expects two (char*) variables to be passed. Within helloworld function messageHandler: void messageHandler(byte messageType, byte msg[], byte msgSize) { if (messageType == ECHO_RESP_MESSAGE) { if (strcmp(msg, "low")) { Within string.h that came with the Teensyduino software: int _EXFUN(strncmp,(const char *, const char *, size_t)); Below is my workaround to get that past the compiler. if (strcmp((char*)msg, "low")) { Compiler threw a warning regarding KerbalSimpit.cpp: In member function 'bool KerbalSimpit::init()': Comparison between signed and unsigned integer expressions [-Wsign-compare] for (i=0; i<sizeof(KERBALSIMPIT_VERSION); i++) { This one is more for my understanding of the code - so excuse me if it's a stupid question: Under the KerbalSimpit.cpp and then function void KerbalSimpit::send(byte messageType, byte msg[], byte msgSize) There is this for loop. for (int x=0; x<msgSize; x++) { _serial->write(*(msg+x)); } If the 'bytesize' variable is passed as a byte, does the 'x' counter var need to be an int? Wouldn't that also be a byte so the loop evaluation of "x<msgSize" is the same type? As mentioned in the above post, adding some code to handle the loss of a COM port (for whatever reason - but usually it seem to be the Microcontroller resetting itself) Maybe when seeing the loss of the object, stop using it in the queue to send messages and still it in a side queue to check for a pulse every 5secs or so. If starts responding again, it can go can be allow to send message in the normal queue. This would go a great way to keeping the game running regardless of what bit of code on the Arduino might cause a dropped connection. The mod already handles reconnect awesomely, but this is only when the COM port hasn't been dropped. To replicate: have a device connected (even with just the hellowworld script) and then pull the USB out. I've seen similar log files already posted on the thread so far, but here' my screenshot if it helps. All up, glad I got it somewhat working. I need to dig into why it's not getting through the init function. Has anyone done any functions or have a methodology to keep an eye on the board buffer being overwhelmed when the speed has been set too fast? I really want to know where my limits are for sending information, whether it be per device, or from KSP in general as I plan to push the code as far & as fast as I can.

I'm still in the process of working out who I want to implement my console and comparing the two options of SimPit and KSPSerialIO. I've tested and 'get' the KSPSerialIO process and think I understand it's pros and cons. I can see how I can take a fork, rewrite the protocol for what I want on my console and what I'd need to grab the data. It is a firehose solution though, in that you're sending the data all the time in that main packet to the microcontroller. I very much like the idea proposed by @stibbonsand was keen to test it out. I'm still in the process of reading through the details of this thread (page 5 at the moment) So far I'm liking what I'm reading. I'm going for an analog cockpit so having the ability to just the activate and deactivate actions is great. I recently tried the Simpit helloworld script and installed on a Teensy3.6 and I can't get it past the " while (!mySimpit.init());" handshake step.I had to dump everything in the loop due to various errors regarding type conversion with byte & char, but that's all fixable later. I just wanted to test the connection. I know the Wiki says it's not working for a Teensy 3.2 on MacOS, but is this likely a similar problem? For reference, I'm on Win10 Home, TeensyDuino 1.44, Arduino 1.87, - Teensy 3.6 Hardware. Separate related request. In setting up the Teensy, I had an issue where the COM port would disappear. Now this was the Teensyduino software 1.41 fault, not KSP,. So no need to troubleshoot. I updated to 1.44 and that problem went away, but it occurred to me to suggest adding error detection when Simpit looses the COM port. In the current version, when the COM port disappears, after about 10 seconds of log spam the Simpit mod dies hard and KSP crashes in sympathy. ie "KSP is not responding" windows dialog box. Note: I'm happy to debug / test options if there is any interest in another tester

Thanks! For the last few days, I've been staring at the cardboard mock-up thinking it's still a little too big. The thing is, if I knock off the 10mm width I think I can from the grip width - I think that'll shrink the housing size too far to get the LCD screen in. At the moment, I'm using my hand on the throttle grip as the determining scaling requirement. I might change that requirement to be the LCD width and do one more Cardboard version with the minimum clearance available for the 16x2 LCD screen I'm using and see how it feels.

@Mulbin Thanks for throwing the list onto the front page. Just a note on formatting, if you dbl-click on each image and set it's width to be 260, (leave "Keep original aspect ratio" ticked) you'll get it looking a lot neater.

Thanks @alexustas, probably won't be putting force feedback in the throttle controller. However, if you meant to ask 'will it be motorised?' then I'm leaning towards 'yes' for that question. Mainly just to set Full or Cut throttle as shown in the below screenshot from your ALCOR lander.

Haven't had a chance to install the QuickIVA mod, but had a question for @4x4cheesecake who seems to use it a fair bit. Does the mod keep the camera in IVA after a successful docking? Or does it switch to 3rd person like it does in stock?

Thanks for the suggestion on this, however, I've found this little circuit worked first try. I just placed the meter between the PWM signal and the voltage divider. It's similar to what you suggested. Testing this on the Arduino Uno was just a matter of hooking it up to one of it's 6xPWM pins and setting the value between 0-255. I added 3x FOR loops for a repeating pattern that starts at the center zero. (125 to 255, 255 down to 0, 0 to 125) This gave the result of the meter moving between from -0.5 to +0.5. I also mapped the expected percent from KSP (0-100) to the value of the meter in code (0-255) to see how it went and it looked fine, but I could make out the little "jumps" between values due to the PWM value only having a resolution of 8 bits. A bit of research told me that Arduino has two pins (9 & 10) that can be used with the Timer1 library to give a 10 bit resolution (0-1023). I moved the circuit to Pin 9 and a quick code change resulted in a much smoother movement. As the gauge is only 65mm tall, the difference isn't really that much, but as it is with project like this, "should I do it" only really gets considered after the "can I do it" get resolved. It might be useful to have a finer resolution for something like Mono or LF/OX in KSP where you really want to know when you have those last dregs left in the tank. Another solution could be to have a switch that I could code the display to alternate from 0-100%, to show just the 0-20% values as the full range of 0-255. Could even have a 5pos rotary selector switch to pick what section of the range I want to "zoom" into (100-80, 80,60, 60-40, 40-20, 20-0). And that's only useful if I don't want to have the actual value (not the percentage) of the resource displayed as numbers somewhere. Plenty of options. The suggestion of 3x rate meters are right on the money. Replicating those rate meters in the bottom left of the KSP UI is very much in the plan. There's even enough meters to display LF, OX, Mono EC, Abl, Ox in both the current stage and the total vessel at the same time. But if I do that, I know I'll run out of meters rather quickly. Note, I probably won't do that though as I personally would rather a reason to flip a switch when needed, rather than display it all at once. The whole point of the build s to flip switch's a turn dials, isn't it? Thanks for the other suggestions too! I'm still very much in planning mode and have to consider a lot of the things you've touched upon.

That's gorgeous! Any plans to do any of the ASET IVAs?

17.Feb I really like how this looks at the moment. Very psyched to start marking it in wood. Proportions look great now that I took the measurements of the in game model! The grip fits my hand width without any contact either side, so that's nice. Not shown is a pommel piece on the left side of the grip, I found it to be a bit too much time commitment to make in cardboard with all the angles it required. It'll just have to wait for the next version in wood to make it's debut. I've also set my approx angles for 100% Fwd & Bkwd to be 76 degrees either side of the 0% mark. 0% will be 22 degrees towards the user off vertical. These angles were chosen to make sure I has the same range for both Fwd & Bkwd. This may change after I get electronics in as I probably don't need that amount of resolution for the reverse direction. Using the reference image, (nearest full degree at the end of the arrows) "Full Thrtl" 100% Fwd = 67 degrees back from vertical. (107 degree full range) "Cut Off" 0% = 40 degrees forward of vertical. Here's the detail I mentioned about sliding a section out to the right to "shift" into reverse. Minus 0-100% would be pulling down, kinda-sorta like a boat throttle. This will probably be checked in code via micro switches to work out where the throttle is in regards to forward/ reverse. (Hence needing to test the internal mechanism first) I know it make the whole thing that extra bit complicated, but seeing that striped section confirmed to me that I NEED that there. --------------------------------------------------- Next step: cut out the pieces in wood. Not happening until next weekend though, busy week at home and won't be able to get out to the shed until then.

KSP Controller Build Log By CyberKerb Okie Dokie, I've been playing around with various bits of hardware with Arduino and Teensy for the last few years. I'm motivating myself to 'actually' start something - ANYTHING to do with the project. My office desk is currently about 80% junk pile of electronics. I'm also starting to lose track of why I've ordered stuff and what it was supposed to be used for. It's time to start putting the parts and the knowledge I've picked up into action. Big credit to @alexustas & @MOARdV for their ASET series of mods and the RPM/MAS mod that allow them to be displayed. Without the work they have put into their mods, I wouldn't be even trying this. Long Term Goal: Build a half-decent controller that will allow me to flip buttons and switches to my hearts content. Maybe I'll even learn how to do purely IVA missions? Who knows? Guide to update frequency:: I'm planning to write this build log as frequently as I can. I'll look to pretty it up later. This is just my first step into logging the progress to make sure I keep on track. I usually only get from 10 mins to 1 hour on any given day to work of this. So progress will be a bit slow. The odd 5 days gap due to busy days with work, should probably be expected. Step 1: (Start small) Build Throttle controller. And not 'any' throttle controller. I want this 'specific one' by @alexustas. Every time I play KSP with the ASET IVA in the Mk1 lander can, I can't help but stare distractedly at the controls... and the gauges... and the dials... Green LCD at the front, light up sections on the handle and the main housing, buttons to auto-set full and zero thrust. This should be fun. --------------------------------------------------- 7.Feb: I've stared at that darn model in KSP / the forum posts long enough! Where are my scissors, metal ruler and utility blade?! Check , Check & check. Hot Glue? Check! Cardboard? (Glances at cereal supplies.) The Cheerios are low enough, stuff the remaining bag into a Tupperware and gimme that cardboard box. OK - we're GO for project initiation. I have a little modification I want to add to the throttle. The idea is that you slide the handle right which will "shift" the engines into "reverse" mode. This idea makes the design a little mod complicated, so I needed to work out how the internals should work. *cut**cut**cut**rule**cut**glue**glue**glue**glue* - Done. Crap that handle is large. How big it this thing going to be when I finish anyway? Er... I need a reference.... --------------------------------------------------- 9-10.Feb: I spent parts of the last 2 days learning Sketchup. I managed to trace the ASET model as best I can from the 3 perspectives that were available. (not a great representation on my part, but good enough to get a sense of scale of the part. in relation to each of the bits that make of the throttle.) I also added a shipload of measurements to do some more mockups regarding size. --------------------------------------------------- 13.Feb: Referenced my hacked together 3Dmodel and went with a 110mm wide hand grip as measured inside the hexagonal end caps. I figure it would allow for a little space either side of my fist holding the throttle handle. How big the housing now? Welp, that's HUGE! It completely obscures the already large cardboard mechanism mock-up. Ok, time to reel the size back in. How about knocking a little bit off to start with... umm what about a 100mm handle width? What size in the housing now? Eh... It got smaller by 2cm in height. Not a big change, but for some reason that's enough for it not to seam overly huge. Lets go with that. --------------------------------------------------- 15.Feb: Next step: Roughly create the rest of the outer shell of the model in cardboard. Just to see if the proportions are OK for my hand size. (I'm not Kerbal-sized, so I guess I'm putting in a custom order to Wernher)

Yay! Got a package in the mail on Friday and thought I'd share. I've been hunting for some decent gauges for a good while. I managed to win this on ebay for $9.50. (I kinda half expect a fellow KSP person to be the one that selling these.) Here's the Box contents (awesomely wrapped): Some dials and gauges that I'm sure I'll find uses for around the cockpit. The 4 x 0-30V might be a bit harder as I'm still trying to work out how to replace the dial face. The top isn't coming off easy. The below weird gauge comes from... (quick google check) ... a dialysis machine. I think it's a 24v, 40uA ammeter in function (maybe) and I'm not sure how I'll use it. However, once I've debugged how it works, I'm sure I'll think of something. The two indicator needles are adjustable via the side dials (they don't cross) Based on the badly scribbled pin-out notes of the unit, I'm pretty sure the think it will output a signal when the black indicator is above/below each of the Red pointers. Might be good for custom 'bingo fuel' alerts for a specific sub-mission. The bit below is what made me REALLY have to buy this. There are a little small, but I think they'll do for what I'm after. I was avoiding getting too big as I'll end up with a command desk like @richfiles has planned and I don't have the space for that. (Still jealous though) All sixteen gauges are center-zero +/- 0.5V. They also have a manual zero adjustment on the side. All this makes it easy to utilize them with a micro controller using 1xPWM pin, a couple of resistors and 1 capacitor for each gauge. The mounting brackets and face plates were bonuses that I couldn't believe were included. I carefully pulled one apart and found that the entire indicator range is removable. Adding a custom sticker over the existing DC Volt range looks like it will be a cinch.

They look awesome! I love the detail you managed to fit into a 32x16 px area. I have to ask (but not asking for) did you think of doing similarly styled stock resource icons?

Awesome mod! Love the work that has been done for this and it's fun to play around with the parts. Thanks for making this available. Just a quick query, did you have plans for what the ARPicons would look like for the various resources in this mod? Graviolium GravityWaves StaticCharge

Anyone got any revised links to additional icons people have created? The two links to dropbox in the OP are dead. Edit: Ah - found one of 'em. https://spacedock.info/mod/15/Olympic1's ARP Icons

Oh wow - welcome back @alexustas to posting! I've seen you lurking for a while and still keeping an eye out for the MAS videos I know that @SpannerMonkey(smce) comments above point to a few specific things to address like removing the Bounds box. Are you able to post a list of the current hierarchy for the PRC wheels? Maybe SM can give specific advice on what to change when knowing what you've got now. Also, both @Deimos Rast and @Mecripp have made attempts of adjusting the PRC wheels to the latest version that KSP uses and ran into issue. Maybe their input could be useful here.

I've compiled a few of the changes from this thread and threw them into the 4 3 cfg files for the parts of this mod. ASET_PRC_Wheel I've separated the PRC wheels into this Dev query thread. Just note that @alexustas is looking for input there on what to change. If you know what might be needed to bring the wheels up to date, head over there. Node: The below are cfg replacements, not module manager edits. ASET_PRC_Platform: Added ModuleKISItem Tweaked where the item get carried on the Kerbal back for KIS Used the FSanimateGeneric module for the deploy action (Firespitter becomes a dependency with this) Corrected all wheel/ bumper nodes so they attach in correct orientation in VAB (KIS doesn't seem to get this right when attaching bumpers out in the field, wheels were fine) Upped max temp to a default value of 1200 Added 50Kg to the mass to reduce how much it flew about when deploying it while it clipped into the ground. Added Description (was blank in v0.1 file) Added bulkheadProfiles = srf ASET_PRC_Seat Changed where the Kerbal is ejected when leaving the seat. Now it's just forward of seat at same level, rather than on top of it. Added ModuleKISItem (didn't add backpack item cfg as I figured it was small enough for inventory) Used the FSanimateGeneric module for the deploy action (Firespitter becomes a dependency with this) Changed mass to match Stock command seat (0.05) from 0.35 Upped max temp to a default value of 1200 Added description (was blank in v0.1 file) Added bulkheadProfiles = srf ASET_PRC_Bumper Added ModuleKISItem Tweaked where the item get carried on the Kerbal back for KIS Adjusted Node so they are oriented correct in VAB. KIS still loads it backward in the field but can be flipped manually (I need to check with the KIS dev if that's something to do with KIS or something we can fix in the cfg.) Changed attachment rules to allow items to be attached to front of bumper. (As was shown in the Demo video that has an ASET light on the front) Used the FSanimateGeneric module for the deploy action (Firespitter becomes a dependency with this) Changed mass to be higher than command seat (0.65) old mass was 0.35 Upped crashTolerance = 7 Upped max temp to a default value of 1200 Added Description (was blank in v0.1 file) Added bulkheadProfiles = srf

Okies - let me have a crack at this range issue. Something to note: Antenna Power does not equal Antenna Range. Your issue isn't with the Commnet-Constellation Mod. I believe you're understanding of what you were trying to do was sound, I think you just misunderstood the bit about calculating ranges between antennas. What level DSN are you at? For this I'll assume new game at Level DSN1, anything else should be better than what I calculate (although you'll see it doesn't really matter for what you're asking...) @TaxiService Made a slight error in taking the calculation for max range just a 'smidge' too far (Only a 'few' powers of magnitude too many) He used 15G (HG-55) and not 5M (for the originally stated HG-5 relay antenna in question) I usually blame lack of sleep or not enough coffee for this, as is the usual symptoms of KSP modders that do this work of love on their personal time The combined 4 x HG-5 antenna power is correct @ 14.142M. and of course your Minmus Probe only has a single HG-5 @ 5.0M power Maximum range between two Antennas calc is: sqrt(totalpower point1 * totalpower point2), so... sqrt(14.142 * 5) = 8.4Mm The news gets worse unfortunately, you said you were initially only using two of the HG-5 antennas for this test... - 2 x HG-5 antenna power is 8.408M. - Minmus Probe still only 1x HG-5 @ 5.0M A quick calculation later: sqrt(8.4M *5M) = 6.4Mm or 6,484km For reference: Mun range: 11.4Mm (11,400km) Minmus range: 46.4Mm (46,400km) . . . You're going to need a bigger antenna. I checked out a full 16x HG-5 trying to communicate to craft a with a single HG-5 and it'll only reach 15Mm at best, so adding more doesn't help. This is due to the combination exponent being 0.75 The reason you are seeing a successful link back to Kerbin from the Minmus probe is due to the link employing direct LOS to the DSN at KSC. I'll assume DSN level 1 (which should be more than enough) which has a power range of 2,000M The max range with those two antennas: - KSC Lvl1 DSN 2,000M - Minmus Probe still only 1x HG-5 @ 5.0M Hey Presto: sqrt(2000 * 5) = 100Mm (100,000km) and that's more than enough to cover all of the Minmus orbit and then some Last tidbit: If you decommission you existing 4x HG-5 CommSats and launch new ones with the next level in Relay sat tech (i.e. a single RA-2 Relay Antenna) you'll get the same-ish range as the KSC DSN level 1 out to 100Mm. Image below shows that exact setup with the controlling craft being the Minmus probe. (Note the antenna signal strength is yellow.) If you want green (>75%), you'll need at least 3xRa-2 Relay antennas per commsat to cover Minmus with a 76% strength. (4x would be 81%) For calculating ranges, I'd recommend checking out the Range Signal Strength Calculator spreadsheet by @Poodmund. For calculating how far a single / combination of a type of Antenna will go when combined with a DSN back home, check the below thread by @Kergarin to get rough indications. Just note in your particular issue, you were looking at Sat to Sat comm range with no DSN. So the graphic may not be that useful for you as all calcs assume a DNS is there somewhere. (But that does give me an idea for another graphic)

Ah - thanks. I don't have the original model, so I was hoping to just map the current transforms to the appropriate sub-modules. So it looks like it's not possible at the moment unless @alexustas comes back.

I'm currently tinkering with trying to get an old wheel module working again by way of trying to update the cfg file to bring it up to date with the recent KSP cfg requirements. The previous cfg was using the old ModuleWheel module from way back. I'm current having troubles getting the change to work. One question, was the stock change back when they moved away from 'ModuleWheel' more then just updating the CFG file? Am I fighting a lost cause as the actual model need correcting? (I don't have access to the source files) I'm thinking was that I need to utilze the ModuleWheelDeployment instead of ModuleAnimateGeneric, but I thougth that would work as a temporary fix until I can get friction working on the wheels... old Wheel cfg PART { name = ASET_PRC_Wheel module = Part author = Alexustas MODEL { model = ASET/PRC/KRoverWheel } scale = 1 rescaleFactor = 1 node_stack_wheelmount = 0.3064924, 0.06158525, 0.0, 1.0, 0.0, 0.0, 1 node_stack_bottom = 0.3064924, 0.06158525, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 0.3941842, 0.06158525, 0.00, 1.0, 0.0, 0.0, 1 TechRequired = fieldScience entryCost = 5200 cost = 550 category = Utility subcategory = 0 title = ASET PRC Wheel manufacturer = ASET description = attachRules = 1,1,0,1,0 mass = 0.05 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 10 maxTemp = 600 crashTolerance = 50 breakingForce = 50 breakingTorque = 50 //----------------------- Wheel Stuff --------------------------- MODULE { name = ModuleWheel hasMotor = true resourceName = ElectricCharge resourceConsumptionRate = 1.0 canSteer = true controlAxisType = Forward steeringModeType = AutomaticSteer brakeTorque = 200 brakeSpeed = 0.6 impactTolerance = 200 overSpeedDamage = 60 WHEEL { wheelName = wheel wheelColliderName = wheelCollider suspensionTransformName = suspensionTraverse suspensionNeutralPointName = suspensionNeutralPoint damagedObjectName = bustedwheel rotateX = 1 rotateY = 0 rotateZ = 0 } steeringCurve { key = 0 16 key = 10 9 key = 30 2 } torqueCurve { key = 0 25 0 0 key = 20 10 0 key = 30 5 0 0 key = 34 0 0 0 } } //--------------------------Wheel Constraints--------------------------- MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = SuspArmMountAimLoc rotatorsName = K-WheelSuspension } CONSTRAINLOOKFX { targetName = K-WheelSuspension rotatorsName = SuspArmMountAimLoc } CONSTRAINLOOKFX { targetName = SuspMainCylinderLoc rotatorsName = SuspMainPistonLoc } CONSTRAINLOOKFX { targetName = SuspMainPistonLoc rotatorsName = SuspMainCylinderLoc } CONSTRAINLOOKFX { targetName = SuspDampeBottomLoc rotatorsName = SuspDamperUpLoc } CONSTRAINLOOKFX { targetName = SuspDamperUpLoc rotatorsName = SuspDampeBottomLoc } } MODULE { name = FXModuleConstrainPosition matchRotation = true matchPosition = false CONSTRAINFX { targetName = steering moversName = trackSteering } } //------------------- ANIMATION -------------------------------------------- MODULE { name = ModuleAnimator animationName = KRoverWheelRetractionAnim //Name of the animation from the model guiEnableName = Expand Wheel //Part tooltip name to display for deployment guiDisableName = Retract Wheel //Part tooltip name to display for retraction animationSpeed = 0.25 //Normalized speed of the animation (1 is usually good) oneShot = false //If the animation can only be played once activeEditor = true //If the part toolitp is visible in the editor activeFlight = true //If the part tooltip is visible in flight activeUnfocused = true //If the part tooltip is visible from EVA unfocusedRange = 5 //The range from which the part tooltip is visible from in EVA } //----------------- KAS ---------------------------------- MODULE { name = KASModuleGrab evaPartPos = (-0.0, 0.50, -0.25) evaPartDir = (0,1,0) attachNodeName = wheelmount customGroundPos = true dropPartPos = (0.0, 0.0, 1.00) dropPartRot = (0.0, 1.0, 0.0) bayType = RoverWheel bayNode = wheelmount bayRot = (-1.0, 0.0, 0.0) storable = true storedSize = 8 } } my cfg attempt so far with poking around using Sarbians Debugstuff mod to identify like transforms I need to specify. PART { name = ASET_PRC_Wheel module = Part author = Alexustas MODEL { model = ASET/PRC/KRoverWheel } scale = 1 rescaleFactor = 1 node_stack_wheelmount = 0.3064924, 0.06158525, 0.0, 1.0, 0.0, 0.0, 1 node_stack_bottom = 0.3064924, 0.06158525, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 0.3941842, 0.06158525, 0.00, 1.0, 0.0, 0.0, 1 TechRequired = fieldScience entryCost = 5200 cost = 550 category = Utility subcategory = 0 title = ASET PRC Wheel manufacturer = ASET description = attachRules = 1,1,0,1,0 mass = 0.05 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 10 maxTemp = 1200 crashTolerance = 50 breakingForce = 50 breakingTorque = 200 bulkheadProfiles = srf //----------------------- Wheel Stuff --------------------------- MODULE { name = ModuleWheelBase wheelColliderTransformName = wheelCollider wheelTransformName = wheel //KRoverWheel(Clone) // wheelType = MOTORIZED // setting this to true will override the radius and center parameters FitWheelColliderToMesh = False radius = 0.21 center = 0,0,0 mass = 0.040 groundHeightOffset = 0 TooltipTitle = #autoLOC_502081 //#autoLOC_502081 = Rover Wheel TooltipPrimaryField = #autoLOC_6004045 //#autoLOC_6004045 = Motorized } MODULE { name = ModuleWheelSuspension baseModuleIndex = 0 suspensionTransformName = suspensionNeutralPoint //suspensionTraverse suspensionDistance = 0.1 targetPosition = 0.0 springRatio = 12 damperRatio = 1.0 maximumLoad = 5.0 } MODULE { name = ModuleWheelSteering baseModuleIndex = 0 caliperTransformName = suspensionNeutralPoint steeringResponse = 2 steeringCurve { key = 0 16 key = 10 9 key = 30 2 } } MODULE { name = ModuleWheelMotor baseModuleIndex = 0 maxRpm = 42 driveResponse = 2 torqueCurve { key = 0 25 0 0 key = 20 10 0 key = 30 5 0 0 key = 34 0 0 0 } RESOURCE { name = ElectricCharge rate = 1.0 } idleDrain = 0.0 } MODULE { name = ModuleWheelBrakes baseModuleIndex = 0 maxBrakeTorque = 0.5 brakeResponse = 1 } MODULE { name = ModuleWheelDamage baseModuleIndex = 0 damagedTransformName = bustedwheel undamagedTransformName = wheel stressTolerance = 250 impactTolerance = 100 deflectionMagnitude = 1.0 deflectionSharpness = 2.0 slipMagnitude = 15 slipSharpness = 2.0 } //--------------------------Wheel Constraints--------------------------- MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = SuspArmMountAimLoc rotatorsName = K-WheelSuspension } CONSTRAINLOOKFX { targetName = K-WheelSuspension rotatorsName = SuspArmMountAimLoc } CONSTRAINLOOKFX { targetName = SuspMainCylinderLoc rotatorsName = SuspMainPistonLoc } CONSTRAINLOOKFX { targetName = SuspMainPistonLoc rotatorsName = SuspMainCylinderLoc } CONSTRAINLOOKFX { targetName = SuspDampeBottomLoc rotatorsName = SuspDamperUpLoc } CONSTRAINLOOKFX { targetName = SuspDamperUpLoc rotatorsName = SuspDampeBottomLoc } } MODULE { name = FXModuleConstrainPosition matchRotation = true matchPosition = false CONSTRAINFX { targetName = steering moversName = trackSteering } } //------------------- ANIMATION -------------------------------------------- MODULE { name = ModuleAnimateGeneric animationName = KRoverWheelRetractionAnim startEventGUIName = Expand Wheel endEventGUIName = Retract Wheel actionGUIName = Expand Wheel1 } //----------------- KAS ---------------------------------- MODULE { name = ModuleKISItem volumeOverride = 1000 stackable = false allowPartAttach = 2 allowStaticAttach = 0 } MODULE { name = ModuleTestSubject environments = 15 useStaging = False useEvent = True } }

couple of minor Localization corrections: In locatisation file: #autoLOC_OTAV_0005 = Deploy Fins #autoLOC_OTAV_0006 = Retract Fins #autoLOc_OTAV_0024 = Deploy Winglets part cfg file have: Part: rektOTAVairFins #autoLOC_OTAV_005 should be 0005 not 005 #autoLOC_OTAV_006 should be 0006 not 006 Parts: rektOTAVwingletPort & rektOTAVwingletStbd #autoLOC_OTAV_0024 Localization file has lower case 'c'