artwhaley

Members
  • Content count

    540
  • Joined

  • Last visited

Community Reputation

401 Excellent

1 Follower

About artwhaley

  • Rank
    Sr. Spacecraft Engineer
  1. Hey, I saw some of SpaceX's look rougher than that! You didn't have a fireball that obliterated the camera filming it like they did one time I was watching! I don't know if it helps with your approach at all, but in the library at https://github.com/krpc/krpc-library/tree/master/Art_Whaleys_KRPC_Demos my landing script has a python port of the mechjeb suicide burn algorithm (with a couple of changes. I think I do a better job of clearing terrain obstacles because I test them along the descent path, not just at the projected landing site... and I make my calculations and fly my landings assuming 95% of max thrust, but with the loop testing if we're ever over speed and boosting to full power when necessary, for an extra safety factor.) It works pretty reliably for automated landings on the mun, but that's the only test case I'd done with it. It doesn't consider atmospheres at all, but still could be useful to you in that final landing burn phase. It looks like you're chasing the retrograde bug there at the end, and an over correction takes you too far from vertical? Perhaps a final phase is in order where if the horizontal speed is less than some threshhold, it simply locks vertical instead of trying to chase down those last few meters per second and landing on it's side? Good idea on passing spacecenter.ut to the pid instead of just time.now() which IS totally what I've been using in my PID loops! I'll look at rewriting it this way so it adjusts for lag!
  2. Hey! That's looking like GREAT progress! If I had to wager a guess without seeing the code or testing anything here... I'd actually guess it's a matter of scales that can be fixed with a simple bit of arithmetic. Pitch and roll return values between -180 and 180 and heading returns values between 0 and 360. If your unity model can have it's pitch, yaw, and roll set as 0 to 360 values, or you can convert pitch, yaw and roll to the format you need, make sure you've done something like - if(pitch<0) pitch += 360; if(roll<0) roll += 360; I may be missing something, but that's my first guess!
  3. You should pass the reference frame as you request the direction. There may be a default that gets assumed if you don't specify, but the documentation doesn't tell us what it is. Something like : var vesselDirection = vessel.Direction (vessel.SurfaceReferenceFrame); The example here shows some ways to work with that. https://krpc.github.io/krpc/tutorials/pitch-heading-roll.html Without TOTALLY thinking through the 3D space implications.... it sure SEEMS to me that the roll, pitch and heading values ((again, from a flight(vessel.SurfaceReferenceFrame) object)) COULD be used to rotate your ball? I hate 3D rotation math... so hopefully someone smarter than me volunteers how to actually relate one to the other!
  4. The Navball seems like it ought to be relatively simple in Unity, since you're really just rotating a 3D model in front of a camera? As to a map view... if you're doing it the hard way... I've got this - It's ancient C# code from when I was playing with Telemachus years ago and it's terribly documented - and was just a test - all the orbital parameters are hard coded in. It's only giving a 2D display, thus only really works for two vessels when their planes are matched, and I'm SURE there are a BUNCH of cases under which it doesn't work right at all, but it might get you STARTED on thinking through the steps to draw an orbit. I make NO guarantee that it's RIGHT at all... and don't claim to really remember how it worked if it did! It draws the planet, the atmosphere line, the ellipse of the 'active vessel's orbit and a dashed line to show it's current position along that ellipse, then the target vessel's orbital ellipse and current position line. float planetr = 600; //radius float planetatmo = 70; //atmosphere thickness in km float biggest = 0; //determines what the biggest ellipse that needs drawn is float scalefactor = 1f; // multiplier, used later float windowsize = 390; //myship variables float shipsma=751; float shipsmi = 713; float shipapa = 151; float shippea = 75; float shipmea = 3.1415f; float shiplan = 15; float shiparg = 15; //arg of periapsis PointF shipcenter; float shipscaledx; float shipscaledy; //targetship variables float targetsma = 751; float targetsmi = 713; float targetapa = 151; float targetpea = 75; float targetmea = 3.010101f; float targetlan = 180; float targetarg = 15; PointF targetcenter; float targetscaledx; float targetscaledy; //myship next orbit variables float nxtsma = 751; float nxtsmi = 713; float nxtapa = 151; float nxtpea = 75; float nxtmea = 3.010101f; float nxtlan = 45; float nxtarg = 15; PointF nxtcenter; float nxtscaledx; float nxtscaledy; //graphics crap - including pen colors Graphics g = panel1.CreateGraphics(); System.Drawing.Pen planetBrush = new System.Drawing.Pen(Color.Goldenrod, 3); System.Drawing.Pen atmoBrush = new System.Drawing.Pen(Color.Goldenrod, 2); atmoBrush.DashStyle = DashStyle.Dash; atmoBrush.DashPattern = new float[] { 10f, 10f, 5f, 10f }; System.Drawing.Pen myBrush = new System.Drawing.Pen(Color.Cyan, 1); System.Drawing.Pen targetBrush = new System.Drawing.Pen(Color.Green, 1); System.Drawing.Pen nxtBrush = new System.Drawing.Pen(Color.Blue, 1); //Figure out what the biggest thing we have to draw is and scale that to the window's resolution. biggest = Math.Max(planetr, shipsma); biggest = Math.Max(biggest, targetsma); biggest = Math.Max(biggest, nxtsma); scalefactor = windowsize / biggest; scalefactor = (scalefactor * .4f); //rescale everything planetr = planetr * scalefactor; planetatmo = planetatmo * scalefactor; shipsma = shipsma * scalefactor; shipsmi = shipsmi * scalefactor; shipapa = shipapa * scalefactor; shippea = shippea * scalefactor; targetsma = targetsma * scalefactor; targetsmi = targetsmi * scalefactor; targetapa = targetapa * scalefactor; targetpea = targetpea * scalefactor; //draw planet Point planetcenter = new Point((int)windowsize / 2, (int)windowsize / 2); Point planetcorner = new Point((int)(planetcenter.X - planetr), (int)(planetcenter.Y - planetr)); g.DrawEllipse(planetBrush, new Rectangle(planetcorner.X, planetcorner.Y, (int)(2*planetr), (int)(2*planetr))); g.DrawEllipse(atmoBrush, new Rectangle(planetcorner.X-(int)planetatmo, planetcorner.Y-(int)planetatmo, (int)(2 * (planetr+planetatmo)), (int)(2 * (planetr+planetatmo)))); //draw ship float angle = shiplan + shiparg; // rotation of orbit's SMA relative to Origin of Longitude float centeradjust = 0.5f*(shippea - shipapa); shipcenter =new PointF((float)planetcenter.X-centeradjust,(float)planetcenter.Y); Point shipcorner = new Point((int)(shipcenter.X - (int)shipsma), (int)(shipcenter.Y - (int)shipsmi)); using (Matrix rotate = new Matrix()){ GraphicsContainer container = g.BeginContainer(); rotate.RotateAt(angle, planetcenter); g.Transform = rotate; g.DrawEllipse(myBrush, new Rectangle(shipcorner.X,shipcorner.Y,(int)(2*shipsma),(int)(2*shipsmi))); g.EndContainer(container); } float progressangle = (shipmea * 360) / 6.28319f; progressangle = progressangle + shiplan + shiparg; Point shippoint = new Point(); shippoint.X = (int)((windowsize) * Math.Cos((Math.PI / 180) * progressangle) + planetcenter.X); shippoint.Y = (int)((windowsize) * Math.Sin((Math.PI / 180) * progressangle) + planetcenter.Y); //textBox1.Text = shippoint.X.ToString(); //textBox2.Text = shippoint.Y.ToString(); //textBox3.Text = progressangle.ToString(); g.DrawLine(myBrush,planetcenter, shippoint); //draw target angle = targetlan + targetarg; centeradjust = 0.5f * (targetpea - targetapa); targetcenter = new PointF((float)planetcenter.X - centeradjust, (float)planetcenter.Y); Point targetcorner = new Point((int)(targetcenter.X - (int)targetsma), (int)(targetcenter.Y - (int)targetsmi)); using (Matrix rotate = new Matrix()) { GraphicsContainer container = g.BeginContainer(); rotate.RotateAt(angle, planetcenter); g.Transform = rotate; g.DrawEllipse(targetBrush, new Rectangle(targetcorner.X, targetcorner.Y, (int)(2 * targetsma), (int)(2 * targetsmi))); g.EndContainer(container); } progressangle = (targetmea * 360) / 6.28319f; progressangle = progressangle + targetlan + targetarg; Point targetpoint = new Point(); targetpoint.X = (int)((windowsize) * Math.Cos((Math.PI / 180) * progressangle) + planetcenter.X); targetpoint.Y = (int)((windowsize) * Math.Sin((Math.PI / 180) * progressangle) + planetcenter.Y); //textBox1.Text = shippoint.X.ToString(); //textBox2.Text = shippoint.Y.ToString(); //textBox3.Text = progressangle.ToString(); g.DrawLine(targetBrush, planetcenter, targetpoint); g.Dispose(); myBrush.Dispose();
  5. Cantab Learns Python with KSP and kRPC.

    The code tags! On the markup/formatting bar click the <> button and that will pop up a window to type your code into, and you can even tell it what language to get it to color it correctly if it actually is code! And a fully automated mun mission wouldn't be trivial, but it's certainly doable. I think almost everything you need to accomplish it is in my version of the library repository - https://github.com/artwhaley/krpc-library/tree/master/Art_Whaleys_KRPC_Demos There's a launch script that's self explanatory, Then in the rendezvous.py file you'll find methods for a hohmann transfer - they'll have to be recoded because I think they intercept a vessel only, but swapping the target_vessel for target_body ought to be just about the extent of it. This would work fine for giving you a rough Transmunar Injection Burn. Then you'd enter munar SOI and have to write a bit of code to burn radial + or - to adjust periapsis. Then you'd circularize at periapsis (similar to how it's done in the launch script at apoapsis) Then there's an automated landing script in the folder that handles reasonably efficient landings on vacuum bodies! If I ever finish the code for the KRPC mechjeb service, it's WAY easier. When I had that hacked together without reflection, it was about 20 lines of code to launch and transfer and land on the mun... because you were just feeding parameters to mechjeb an then activating the autopilots.
  6. I don't think he's trying to modify the plugin, I think he's trying to make a client... if I understand right! I'm a novice too at c# - mostly learning as I hack at KRPC's server code for various reasons, and I haven't done a c# client yet, but I THINK what you're looking for are the classes in the client. Now, spaceCenter() is accessed as a method, so you probably would need to use reflection to grab it... and I hate reflection. BUTTTTT I think I can get you going without that. I haven't TESTED this code but it didn't throw errors in visual studio and SEEMS like it would work. You can explicitly define the type of a KRPC.Client.Connection object, and hold THAT in your user defined class... then access it's spaceCenter method when you need to. A quick example would be - KRPC.Client.Connection conn = connection; KRPC.Client.Services.SpaceCenter.Vessel vessel = conn.SpaceCenter().ActiveVessel; And I also explicitly defined the type for a vessel. There... may WELL be a way to explicitly define the type for a spaceCenter object as well... but my five minutes of poking through the autocomplete suggestions didn't show it to me, and this SHOULD get you going until smarter people chime in and make it easier for you.
  7. KSP Weekly: A Voyage in a Lifetime

    I need a new phone every 18 months, but Voyager is still working fine after nearly 40 years - using "8-track" magnetic tape for storage between transmissions? Something's up. I wonder if I can change the tape in my phone and get another year out of it?
  8. 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 - https://archive.org/details/ignition_201612
  9. @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.
  10. A new type of mouse

    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!
  11. [Mod Help] Docking Ports Not Working

    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!
  12. 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.
  13. 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?
  14. Calculate landing coordinates on Kerbin

    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.
  15. Calculate landing coordinates on Kerbin

    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. https://drive.google.com/file/d/0B3q8VwW68f8AdXhEQVR3UlpPWUk/view?usp=sharing 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.