• Content count

  • Joined

  • Last visited

Community Reputation

387 Excellent

1 Follower

About artwhaley

  • Rank
    Sr. Spacecraft Engineer
  1. I just started this - Ignition, by John Clark. The whole text is free online. He was a researcher with the U.S. Navy between the 40s and 60s when the major work was being done on liquid propellants. I'm enjoying it thoroughly, and thought you guys might too! Link -
  2. @sarbian Gets MORE people blaming him when they can't launch a rocket that has giant fins on the very top and a fairing closed around the SRBs than any 10 of the rest of us combined. He has saintly level patience when it comes to dealing with people asking for support. He said he's already tried to duplicate the problem even though nobody gave him logs, which he is VERY clear about as a basic requirement before he'll feel obligated to help out. Then he told you it was going to be a while before he got back to it. I didn't take his post as 'punishment - because you were naughty I'm going to refuse to support it for two weeks to teach you a lesson!' It was simply him saying he was going to be busy. And he doesn't OWE us support. Shrugging and saying "I dunno... I guess don't use this mod?" would be a perfectly reasonable answer but instead he said he'd work on it more, even without logs, but that it would be a while. What more do people want from him? If we looked at the number of hours I've played this game... vs the number of hours I'd have played this game WITHOUT mechjeb to take care of both the routine and boring (launches!) and the difficult and tedious (interplanetary transfers and maneuver planning), I'd say Squad probably owes Sarbian about 80% of what I paid for the game. And then include the fact that a lot of my KSP time has been since I got interested in modding... and... I don't know what plugin author HASN'T at some point had to dig through Mechjeb's code to figure out how to do or access something... I bet I'm not the only one who can say that well over half of my enjoyment of this game has hinged on work sarbian is involved with.
  3. If I could get it configured correctly, I'd use the HECK out of it in Blender and Unity when modding the game. THOSE are two applications where the ability to manipulate my view while manipulating objects separately would be fantastic. I find myself frustrated with getting the view I want in those applications very commonly. What you're doing looks great, though as others have said, in KSP the view doesn't actually NEED all that much manipulating, and almost never does it need to be manipulated quickly, so I'm not sure KSP gamers are the right target for your product. But a 3D mouse aimed at the graphics and 3D content creation markets would be something I think you could sell a lot of!
  4. What @SpannerMonkey(smce) said. This line in the .cfg file is telling KSP that the docking connection point is an empty game object in Unity, with the blue arrow pointing out (as in, towards the other ship that will dock with this port) named dockingNode. To make it work, all you have to do is create and position this empty game object correctly!
  5. Hey, you're making lots of progress! On your UV map - it looks like you've got something you can work with, which is a great start! For the best possible results, you want to arrange and size all of those 'UV islands' (the separated chunks of your model) so that they fill as much as possible of the square image. The reason for this is 'texture density.' If you scale everything up as large as you can on the image, you've got as many pixels as possible to hold visual information. If things are scaled down small on the UV map, they will look grainy and 'low resolution' when they get into the game. We really need to push the blender tutorials a bit more, I think. Lots of people find that (excellent!) wings 3D tutorial and jump into this with Wings... and then run into the problem that none of us who are active here to help actually use it. Most people are working in Blender (as far as free software goes.) So your Wings specific questions are just going to take more time to get answers, because there are fewer people who know how to help you. As to the question of export - I don't believe there's a way to go directly from Wings to .mu. You'll use unity to create your .mu, which is the recommended method even for people working in blender which DOES have a direct to .mu plugin available.
  6. Reading the devnotes and seeing bits about how some low level functions are being worked on to allow making history to deal with objectives and placing vessels onto surfaces and such... got me wondering - is Making History going to include changes to any of the API DLLs that mods typically compile against? If so - will there be a general stock update that rolls out a 'Making History capable' set of DLLs, and then you'll either get the DLC and USE the new features, or you won't? I ask because if it means there will be two sets of Assembly C# and Unity Engine DLLs in the wild at the same time - every plugin mod would then need a Stock and a Making History build... and that seems like it might well cause some major headaches? Has this been given thought yet?
  7. Well, then... that experimental version of the SpaceCenter dll ought to help, as it lets you grab density for any point in space. Let me know if there's anything else that would both help, and be broadly applicable to others. I think all 4 methods in that PR fit the bill. I always try to strike a balance between those two with contributing methods to KRPC, and Djungelorm has been pretty patient with me so far! lol.
  8. I gave this a try... and am getting results that agree exactly with the aeroGUI window... so I think it's working. I temporarily had a method to get the temperature out, and that agreed with the aero GUI as well, and was considerably warmer than the FlightGlobals.getExternalTemperature results, so I THINK it's getting the correct temperature adjusted for latitude. var adjustedPosition = referenceFrame.PositionToWorldSpace(Position.ToVector()); var altitude = InternalBody.GetAltitude(adjustedPosition); var latitude = InternalBody.GetLatitude(adjustedPosition); var pressure = FlightGlobals.getStaticPressure(adjustedPosition); var temperature = FlightGlobals.getExternalTemperature(altitude, InternalBody) + InternalBody.atmosphereTemperatureSunMultCurve.Evaluate((float)altitude) * (InternalBody.latitudeTemperatureBiasCurve.Evaluate((float)latitude) + InternalBody.latitudeTemperatureSunMultCurve.Evaluate((float)latitude) // fix that 0 into latitude + InternalBody.axialTemperatureSunMultCurve.Evaluate(1)); return FlightGlobals.getAtmDensity(pressure, temperature); Here's a VERY experimental version of the space center dll, that should replace the one in your gamedata/krpc/ folder... TEMPORARILY AND WITH CAUTION. It adds four methods to the celestial body class that have been spawned by this discussion - latitude, longitude, and altitude, and atmospheric density from position methods. Is there any need to be able to get temperature or pressure at a given position, if you already have the density? They're easy to implement, but if they're unnecessary I hate to clutter up the API. The code for the changes I've made is all visible in my fork, via the pull request.
  9. 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.
  10. 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!
  11. 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)
  12. @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.
  13. 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 - 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 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!
  14. 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 - . 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!
  15. 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.