artwhaley

With the way the API is built, it's essentially impossible to make a mod that contains any plugins compatible with multiple versions of KSP. So, as a mod maker, I want to echo support for QA being thorough on the patch! Even if they don't touch anything your mod uses, you have to recompile, test, rebuild your distribution packages, update CKAN... it's a thing. One thing we can all do to keep development rolling... buy the DLC! The number ofpeople I see who bought a game on a STEAM sale for 15 bucks, have gotten hundreds or thousands of hours of fun spread over years of their lives from it, but declare self righteously they will not pay more than $4.99 for D LC and it better give them multi player is astounding. Development energy is not driven any more by excitement or interest. It's driven by sales and budgets. If the DLC is profitable, there will be more.. or a 2.0 game. If KSP appears to be a money pit full of constantly dissatisfied fans... TT will cut their losses. My dream that will never happen for 1.4 or 1.5 or whatever the final release will be - involve modders in a deep effort to expose any bits they still want access to, and thoroughly document the whole API. Then modders can continue to make the game fresh for years. In the same way that all of the specific concerns in this thread - balance, wheels, and visual enhancements - are already fixed by the community.

Many games get a 1.0 release... then a 1.01 patch a week later... then a 1.1 patch six months later.... and... maybe a 1.11 patch a year later If some security flaw is discovered... and that's the game, whether it's fixed by 1.11 or not. I think it's always worth remembering that the early access model and then the continued rollout of major improvements after the 'features complete' date is still VERY atypical. We've gotten a lot more out of Squad already than you get out of larger studios for games that cost twice as much. I DO suspect... just based on the devnotes really... and the purchase of the 'franchise,' that we're probably not going to see MUCH except bug fixes for the core game in the future - that the new features and major gameplay things may well be DLC... or saved for future installments in the kerbal franchise. But that's a gut feeling, not based on insider knowledge or anything! Though I always want to point out in conversations like this what i said in the first paragraph. While there are CERTAINLY things I wish they'd do still in the game, we have to accept that at some point management is going to say 'sales are no longer paying for development. You guys are going to start working on something new.' and that this has been delayed WAY longer than we have any right to expect already, so when it happens we need to all cheer for them and eagerly anticipate the next project, not panic!

You're totally right about error from that one. I don't see an obvious way to get that answer without computing it via haversine related math. In that landing script I linked above, the coords_down_bearing function does the right math, mostly, for you. It takes a current latitude and longitude, a bearing and a distance and gives you the new latitude and longitude. So... ONCE I get Djungelorm's guidance on adding the lat and longitude from position vector routines to KRPC... what you'll have to do sounds like... Get the Lat and Lon where you'd land if you were landing NOW... Get the time till impact multiply that time by the rotational speed of the planet to get the degrees rotated between now and then Find the circumference of the planet at the landing latitude use circumference and the rotation angle to get the overland distance between where you'd land now and where you'll actually be landing then.... and then the math from that coords_down_bearing function will get you the rest of the way - coords_down_bearing(current_lat, current_lon, 270, overland_distance, orbital_body_in_question)

@Benjamin Kerman - that was my first attempt as well when I was trying to limit dynamic pressure on an ascent script. I found it over corrected a lot! Switching even to a proportional control helps, if you're not ready to get into a full PID controller. A pseudocode example might be = kP = .2 # sorta arbitrary value for the proportional gain - tune this until you # get the balance you want between strong reaction/over correction target_speed = 0 #For a hover - could be not zero for a controlled climb or descent LOOP INDEFINITELY: error = target_speed - vertical_speed # calculate the error correction = error * kP # multiply error by the gain set throttle = throttle + correction # apply the correction to the throttle value. That way we instantly react to the value that we're measuring in a way that is proportional to the error. If we're a little high, a slight negative correction gets made. If we're way low, a large positive correction gets made. And when we cross the correct value, we don't have to wait a few cycles for the value to incrementally return to zero. To improve that to a PI controller, all we have to do is this - kP = .2 # sorta arbitrary value for the proportional gain - tune this until you # get the balance you want between strong reaction/over correction' I = 0 # The integral term. A sort of memory for how long we've had an error in the vertical velocity kI = .1 # gain for the integral. MaxI = 10 #Max and minimum I values to prevent 'windup.' MinI = -10 target_speed = 0 #For a hover - could be not zero for a controlled climb or descent LOOP INDEFINITELY: error = target_speed - vertical_speed # calculate the error I = I + error #Integrate the errors if I > MaxI then I = MaxI if I < MinI then I = MinI correction = (error * kP) + (I * kI) # multiply error and integral by gains set throttle = throttle + correction # apply the correction to the throttle value. That's 13 lines of code for a fairly adaptable controller routine. What we added with the I - we keep a sum of all the errors we've measured... and multiply that times the kI gain. What this does is pretty intuitive once you think about it... let's give an example. With the code above, say we're 1 m/s too high - as in we're drifting upward at 1 m/s. In the first cycle through the loop: error = -1, I = 0 + -1 So the correction applied to the throttle will be (-1 * .2) + (-1 * .1) or -.3 If that isnt' enough to fix it, and we're STILL climbing at 1 m/s in the next cycle, NOW I = -1 + -1. So this time through the correction is (-1 *.2) + (-2 * .1) or -.4. The longer we're wrong, the harder it will 'lean' on the throttle to bring us back into balance. This way we get small corrections for quick flutters, and stronger corrections when something goes way wonky and stays that way.

I'm working on a similar problem... starting with vacuum landings and going to play with atmospheres at SOME point. At the moment I've got a decently functioning vacuum lander script - that doesn't do any targeting - but controls descent with reasonable efficiency. It's the lander script in my example directory -https://github.com/krpc/krpc-library/blob/master/Art_Whaleys_KRPC_Demos/landing.py The fun bits are mostly a KRPC/Python port of the mechjeb suicide burn calculation equations, which seems like it might be useful to you. I don't begin to understand the maths, but I get the same numbers mechjeb does, so it's working. ((actually, my routine is maybe slightly BETTER at avoiding terrain than mechjeb - because mechjeb only looks at the altitude of the projected landing site... and my routine samples terrain heights along the landing path and tries to kill horizontal velocity by the altitude of the highest obstacle along the course. The closest I can get off the top of my head to what you want to do is this bit- v = conn.space_center.active_vessel radius = v.orbit.body.equatorial_radius + v.flight().surface_altitude TA = v.orbit.true_anomaly_at_radius(radius) TA = -1 * TA #look on the negative (descending) side of the orbit impact_time = v.orbit.ut_at_true_anomaly(TA) impact_place = v.orbit.position_at(impact_time, v.orbit.body.reference_frame) And IMPORTANT - that position_at(ut, reference frame) bit is actually in the development builds of KRPC but not the .39 release yet - I just added it to the code last month. It should be in the next release. The missing piece THEN becomes... turning a vector position into a latitude and longitude? Which I don't think exists yet... so maybe I'll see if I can figure that out and get it into the development release too, because it seems a useful bit to have? Off the top of my head... you could maybe cludge it using what already exists in KRPC by getting the vector position at the vessel's latitude and longitude, at the same altitude as 'radius,' then calculating the distance between the two points... then using some haversine derived math to get the lat and lon of the second point based on distance and heading? PART of that math is in that same landing.py file - the coords_down_bearing(lat, lon, bearing, distance, body): function. You just need to calculate the bearing. Update - a quick peek in the KSP API confirms that getting the latitude, longitude and altitude of a point in world space is easy - I've opened an issue on the KRPC github to see how djungelorm prefers me to do it, but as soon as he gets back to me on that, I'll add those methods to KRPC and then you'll have them in the development build... which.. will.. MOSTLY get you where you want to be for vacuum planets. Atmospheres... that's a different animal. I'd look at how the trajectories mod does it and try to port that over if the license allows. And in fact... I WILL be doing that at some point soon for my own curiosity as well!

I've tried this and been frustrated with the poor construction of any keyboard cheap enough to be okay taking apart! I got frustrated trying to physically attach to the circuit board... but that was ages ago and I don't remember what EXACTLY was annoying me. Though, yes, you'll have to tag on to the X and Y lines and trigger both of those to send the keystroke. You REALLY won't regret getting into something like Arduino - there's a simple library to enable arduinos with the right usb chip to emulate a keyboard very simply - https://www.arduino.cc/en/Reference/MouseKeyboard . There's a huge community around arduino, lots of tutorials, and a couple of KSP implementations already that are doing basically what you want to do that might be worth looking into, and would definitely be places to ask for help. I'm ALSO playing myself with a raspberry pi idea... that utilizes the KRPC plugin to move data over network. The idea would be to roll a raspberry pi image that anyone could just burn to an SD card and run with - so when you booted up you got a bunch of telemetry data on the HDMI screen..and that is almost done... and when finished I was going to experiment with a simple way to allow people to attach buttons to the GPIO pins? Maybe add a .cfg file people could edit to route the button pins to whatever functions they wanted control of? But that's more advanced than you want to get into right now! Let us know what you end up trying and how it works out!

I haven't gotten into KOS yet, but have done this with KRPC and might be able to help with the concept. I used a PID loop (and I believe that KOS has a generic 'hardware' PID available for you to use?). To hover, I used a setpoint of 0 and input vertical velocity as my measurement variable, and the output was fed into the throttle. You could also probably use the altitude you want to hover at as the setpoint and then measure the actual altitude, if you were more worried about that than about vertical velocity.

Glad I could help! I've been using the python client library, but I'm pretty familiar with KRPC so if you get stuck, just shout at me!

I am certain the folks in the arduino thread can be more help - you might want to just post there? If you can't just use the arduino mod as a basis for what you're trying to do? Just guessing from the name of your mod -dashboard driver - I'm assuming you're building a hardware interface? The other projects that do that might be informative. If not... you could also use KRPC to get the KSP data you need IN and OUT of the game and then write your own standalone application that processes data and handles the IO? But beyond that, I'd ask the arduino guys. They can probably just paste you 5 lines that does it.

All of the graphics for DPAI are in the folder and it's easy to modify them. If you look at this video, and ignore what I'm actually trying to SHOW you in the video (which is the IVA prop) you can see that I'd replaced the background and frame images on DPAI with something totally transparent, so I just get the needles floating in empty space. Depending on your skill level you could make the DPAI aesthetic anything you want! - Also.... hmmm. Those were kind of cool IVA props. I really ought to clean them up and make them available without the ship I'm not maintaining any more.

Sorry to see you go, but I know the feeling! I've taken long breaks myself... maybe you'll find your way back eventually. I'm happy to do a bit of babysitting on Pilot Assistant - at least recompiling against game updates... until someone else comes along with more time to do more with it.

You are all so pessimistic. I have absolutely no doubt that NASA could put a man on Mars by 2024, if not 2020. And if the stock prices hold out and enough people buy Teslas... Elon can almost certainly bring back their desiccated remains by 2050 or 2060. It's called faith people. Have a little.

You can ask anything! And that's even the sort of thing that will get an answer! I'm going to assume you're working in Python? Classes are handled like any class in python - you define them and then create an instance of them. To my (rather new to python) mind, they're great for a couple of things - 1, when you have a set of related functions and variables that it makes sense to roll together, and 2 - when you're going to want multiple copies of the same code/variables at the same time. As far as more advanced scripts go - Launches are a good place to start. I know of three fully developed ones - The one on the documentation wiki you've probably already found - https://krpc.github.io/krpc/tutorials/launch-into-orbit.html @Kerbart's which is a GREAT example of how python lets you organize a script into classes and make them all work together (though it's still a bit over my head!) https://github.com/bart-r-willems/krpc-launch/blob/master/launch.py and mine - which is more linear and less pythonic, but handles most cases to get you to orbit. https://github.com/artwhaley/krpc-library/blob/master/Art_Whaleys_KRPC_Demos/Simple_Launch_Script.py

Ahhh. I don't believe that is built into the server. With everything you're trying to accomplish, and your obvious experience in programming... have you thought about building your own KRPC service for the ingame C# side? KRPC makes it very easy to tie your own plugin into KRPC - this way you could offload what calculations and controls you wanted to your external script, but also create your own methods server side for items like this that would unduly tax the RPC link? https://krpc.github.io/krpc/extending.html has the details on that.

https://krpc.github.io/krpc/tutorials/reference-frames.html#converting-between-reference-frames That link may do what you need? the space_center service has facilities for converting directions, forces, rotations, and positions from one reference frame to another?

BASED ON MY POTENTIALLY FLAWED UNDERSTANDING - Packed vessels don't have their part tree loaded- they're treated as a single entity. Thus, mechjeb - and solar panels, for that matter, are neither one going to work as expected -since they're both part modules. So... something with a vessel module - of which, without looking at code, I would suspect TAC is a candidate... would need to handle this. I don't THINK it makes any sense to try to 'orient' a packed vessel, but I think it WOULD make sense to calculate a 'maximum solar panel generation' number and apply that over time. I'm... sort of surprised that isn't the behavior you're seeing from the stock game actually? My packed vessels with solar on board don't get dead batteries, generally speaking? If TAC is draining the batteries itself... it would be a question to post in THAT thread to figure out how they handle solar panels replenishing EC versus LS draining it and see if perhaps you can suggest a new way to think about that.

Technically you're correct in that last question. The time number IS the amount of time you would have to burn at full throttle to achieve the indicated delta-v... because it's showing the amount of time the stage can burn at full throttle and the delta-v of the stage. But as people pointed out above - that time number isn't particularly useful to you. The actual delta-v and the TWR of your rocket are all that really matter to you from that window.

Blender can import a lot of types of files so it's just a matter of figuring out what wings can export - it looks like collada (.dae) and wavefront (.obj) are both on the list, and those are formats blender handles very well. So I'd export as a .dae, then import it into blender!

Since nobody mentioned it again after you asked, I'll add - The game comes with more than a dozen stock craft already built. I believe there's now a menu setting that controls if they're available to you in a career game, and you'd still be limited by what parts are unlocked, but you can always just start a sandbox save and play with the examples that are magically in the space plane hanger's 'saved craft' folder then! Doing so will let you learn to fly on known good hardware - because it IS difficult when you're starting out to know 'did I crash because of the build, or because of my flying.' The answer is usually both - and that if you'd been better at EITHER building or flying you might have not crashed. But - that's all the more reason to learn to fly so that when you are test piloting your own creations you'll know what it SHOULD have handled like and be able to have a starting place on fixing it.

If you move to blender, there are a lot more of us who can walk you through things you get stuck on. I HATED my move to blender - having worked in Lightwave ages ago - but now that I'm used to it, it's all second nature.

This is a fantastic thread! I've been thinking about doing something like this with videos - showing the basics of using KRPC and python. I'm so glad you're posting these reports! Keep it up! I'll point other KRPC beginners to this as a resource.

@cantab - I hadn't done anything in Python until I started with KRPC - it's been a GREAT excuse to learn something that's been on my list for ages. I admit I've still got a lot to learn about the philosophy of it - it turns out Python is half programming language and half religion, apparently? We've started putting together this resource of examples - https://github.com/krpc/krpc-library It's got a lot of room to grow, but in my folder I've got fairly simple approaches to some fairly complicated tasks - you can see how to use a PID controller to manage throttle, then see how that gets applied in a complete ascent script... or how the exact same PID controller gets used to steer the vessel's RCS thrusters for a totally automated docking, as an example. If you have questions about anything... I've found this thread is frequented by smart and helpful people so don't hesitate to ask!

Well, I hold alt to make a named save occasionally. It's only happened twice. But still. It could have been anywhere else. Or... they could have NOT used alt as the modifier for named saves! And yes it's totally rebindable. I'd done so after the first time it happened, but when it happened again the other day I had to make a snarky forum post to work out my minute bit of rage. It did NOT save to persistent.sfs in that instance though... so the cool thing I was sure I could only pull off once was lost and sure enough... I could only pull it off once. Whatever it was.

And found it, I think - I'm going to link in the code here for those that come after. I converted them to radians and shifted the AN and DN properties to +-pi so they'd be in the same number space as the anomaly properties. Thank you so much for the help everyone! //AN var degrees = FinePrint.Utilities.OrbitUtilities.AngleOfAscendingNode(InternalOrbit, target.Orbit.InternalOrbit); if (degrees > 180) degrees -= 360; return Math.PI * degrees / 180; //DN var degrees = FinePrint.Utilities.OrbitUtilities.AngleOfDescendingNode(InternalOrbit, target.Orbit.InternalOrbit); if (degrees > 180) degrees -= 360; return Math.PI * degrees / 180; //Inclination var degrees = FinePrint.Utilities.OrbitUtilities.GetRelativeInclination(InternalOrbit, target.Orbit.InternalOrbit); return Math.PI * degrees / 180;

The second one DOES look promising for finding the angle between the planes! Thank you! I'll try it out, though I'm still looking for how to find the longitude or mean anomaly or time of the intersection.