Jump to content

Kartoffelkuchen

Members
  • Posts

    1,641
  • Joined

  • Last visited

Everything posted by Kartoffelkuchen

  1. What you have there is just a "static" approach angle, the plane will always follow this 3° glideslope, even if this glideslope won't lead the plane to the runway and make it under- or overshoot. What you instead want is a more "dynamic" way of calculating the angle, you really want to hit that runway, so what you'll need to do is make the angle based on the runway distance and your current altitude. Here's mine: SET descentangle to -arctan((altitude-height-runwaypos:terrainheight) / max((grounddistance - 1000),0.0001)). So what we've got here is calculating the angle by using the current altitude of the airplane - the height of the plane (probably unnecessary here but I'm still doing it) - the height of the terrain at our target landing position and dividing that by the distance to the runway on the ground. I guess you could also use cos and then just use the runwaypos:distance instead of having to make some wonky calculations to get the actual distance on the ground but that's what I decided to settle on. Using the -1000 btw so that we're actually targeting a spot 1000m ahead of the runway so we don't overshoot too much since we won't follow that angle anymore once we're flaring. As for the flare, this is the line that triggers the switch from the descent to flare mode: SET flareInit_alt to abs(descentangle) * 50 + 50. Basically just trial and error to see what works best lol. Condition for the switch from descent to flare is then: IF altitude-height - runwaypos:terrainheight < flareInit_alt { SET autoland_mode to "flare". SET lastdescentangle to descentangle. } ELSE IF autoland_mode = "flare" AND landingabort = 0 { SET descentangle2 to -arctan((altitude-height-runwaypos:terrainheight) / max(grounddistance,0.0001)). SET flare_agg to max( min( 0.01 / descentangle * (-1000),-0.15), -0.3). SET holdpitch_param to max(min((altitude-height-targetrunway[1]:terrainheight)*(flare_agg),-1),min(descentangle2,-1)). } Notice I'm now using the actual runway position, not -1000. I've got that one factor flare_agg in there, since the plane won't be able to immediately change it's pitch angle and that factor basically just controls how quickly the pitch angle will be reduced in order to prevent us crashing into the ground because we didn't flare soon enough. Last line then just controls the actual pitch angle we'll follow, also using the descentangle2 so that we will not descent with a higher angle than we prreviously had before we switched to flare mode. It's really just some really basic triangly maths and then figuring out which limitations and factors you'll need to introduce to have a safe approach which the plane can follow nicely. I also have a second option to use which lets you specify an angle you'll want to follow, like 3deg. Then based on that the plane will adapt it's pitch angle constantly to try to follow that 3deg glideslope, so if you had a 8deg angle with the method I mentioned above, the plane will pitch down more to like 12deg so that the angle reduces and then eventually pitch up at the right time to follow that 3deg glideslope again but I guess what I wrote above is enough for a start.
  2. Well, is everything correctly displayed in the game? If yes, no worriee, if no, I'll have a look at it. Thanks for directly providing a log file though
  3. Yeah what @scimas said, it's get only and the DLC seems to be able to only read pilotcontrol.
  4. Not sure if I should even post here, but is there a way I can control the robotics from the Breaking Ground Expansion via kOS? The situation is as follows: Built a large airplane, so large that standard control surfaces aren't enough, so I made custom large elevators, which are moved via a hinge which is bound to the Pitch control input from the pilot. This works fine for manual flying, however problems already occur when using trim, since apparently these parts don't react to trim input, only to "actual" input from the pilot as in 'W' or 'S' being pushed. However when I try to let kOS steer the plane, which works just fine with normal elevators, things don't work out. Neither raw control seems to work (set ship:control:pitch to 1) nor does "direct" control (lock steering to up). Maybe both issues are somehow related? It's also possible that this is a problem with the game itself, but thought I'd post it here anyways since I'd be really cool if this actually worked!
  5. Fill up? You mean explode? Try rebuilding and reattaching the cores, maybe that helps. Hm, no that's not planned I'm afraid, however I'd be more than happy if someone went ahead and does that.:)
  6. Looks really nice! Just one thing, decrease the "thickness" of the engine bell at the bottom, those things are really thin actually. Should be at least 50% thinner, probably even more. Apart from that, great work! And maybe consider having a variant without that boattail just like the stock engines now offer.
  7. Ouhh what a nice job you've done! Was about time someone made a New Shepard for Kerbal. You might need to add a license though in order to share the download link, which has apparently been removed for now.
  8. Slowly getting good enough for a release I think. So much new stuff has been added and remade since the last video, a much better & smoother pitch control logic, a glideslope control logic which makes sure the plane stays roughly in the desired glideslope, a new landing "flare mode" trigger, which contributes to overall much more accurate and smoother landings. Also some more safety features have been added, for example bank angle & pitch limits, a ground-proximity-warning-system (you can see the warnings in the video, however system was not activated because the plane was in a lanidng configuration), flight prediction and terrain scanning and of course also a rule to disable some of these systems in case of a detected emergency, kind of like an alternate flight law in an Airbus. Really like how this is coming along, crazy that it's been over a year since I started this project.
  9. Alright, great to hear you got it to work! Good idea, will do! I'll also redo the payload adapter when I'm at it, the one I have doesn't look like the F9 Adapter at all which has been bothering me for quite a while.
  10. That's interesting, I'll have a look into it. Apart from that, Starhopper WIP pictures!
  11. Since acceleration is the rate at which the speed is changing, you could measure airspeed / speed at two points of time with a known seperation between the measurement, then divide the difference by the time and you got the acceleration. Of course you'd need to do that inside a main loop which runs all the time, otherwise you'd only get one measurement, it would look something like this: set p to 1. until p = 0 { set v1 to airspeed. wait 0.01. set v2 to airspeed. set acc to (v2-v1) / 0.01. print "acc: " + round(acc,2) + "m/s^2 " at (0,2). on ag10 set p to 0. } You might need to multiply or divide acc by a factor of 2 or 4, don't know why it sometimes doesn't work out directly.
  12. Yeah, for now the turntable has no "real" functionality apart from spinning the whole ship up. The decoupler is integrated into the Star 48B since with an engine and a decoupler in that part it wouldn''t work. I did not fully understand how the expansion things work, had some interesting behaviour when I tried to make the turntable work with the Expansion, once I've sorted that out I will provide an update to add support for that, maybe also for Infernal Robotics for everyone who does not own the expansion.
  13. Concerning performance issues of the rocket, I'll make sure to include an Old School Fairings MM-config in the next patch, this should give more stable ascents and more consistent performance from the rockets. Also, we have a nice review from KottabosGames!
  14. Delta Pack Adds the Delta II, III and IV rockets into the game, featuring highly detailed models & textures. (No, this is NOT the official ULA mod pack! I do not have any affiliation with them, I've released my work on my own since otherwise you would never get your hands on this.) Overview of the parts included: RS-27A, RS-68A, RL10-B2, AJ-10-118K, LR-101 GEM-40, GEM-46, GEM-60,GEM-63, GEM-63XL, Star 48B SRM's 4m DCSS (2 colour shemes), 5m DCSS, Common Booster Core, Thor Tank, Delta K, Extra Extended Long Thor Tank various Payload Fairings A wide range of different payload adapters based Note: These launch vehicles are scaled down to fit the Kerbal universe, Delta II has a diameter of 1.5m, Delta III of 2.5m and Delta IV of 3m. A seperate manual is also included in the .zip file. Real Solar System / Realism Overhaul configs are made by @raidernick and are included in the upcoming RO patch. More pictures: https://imgur.com/a/MHVdhPr DOWNLOAD v.1.0 FROM SPACEDOCK All rights reserved - Kartoffelkuchen Logos used are owned by United Launch Alliance Important note: I do not want to make any profit off of my work, so I always appreciate some nice comments if you like it! Enjoy! @Coolinee Kerman Well, not my fault lol but I've decided its time to release this now, otherwise people would never get their hands on this.
  15. ...2, 3 and 4... Got a little something coming up for ya
  16. Version 4.0 released! KSP 1.7.2 (and also 1.6.1 for RO) support New GEM-40 model & textures (Air- & Ground-lit) Added GEM-60, GEM-63, GEM-63 XL New model for the Star 48B and Star 48BV General rebalancing of the parts DOWNLOAD
  17. Does KSP only allow the use of squared textures (512x512, 1024x1024 etc)? I have a part which uses a 2048 x 1024 texture, which will not load at all. If I remove the texture from the material in unity, the part loads up fine. Not sure if this is wanted by the devs or a bug, is there a way around this? Using a squared texture for this model would really be a big waste of memory, but I don't think I have any other options..
  18. KK's K-1011 "Tristar" Development Thread I've recently been working on a model of the famous infamous Lockheed L-1011 "Tristar", mainly out of personal interest because I wanted to challenge myself with something new (everyone can make easy 3D rocket parts right?) and thought I'd share some of my progress here, maybe some of you like it. Note that this is not supposed to be a replica, I am trying to keep things simple, though this won't be stockalike either and will not really be suitable to use with other stock parts in your own designs, due to the high amount of work needed to split things up into many smaller parts. Things like the engines can of course be reused in your own crafts. Current progress: - engines are done (model & textures completed, still need to go through Unity) - most parts are finished modelling, the gear is still missing though I will make sure to create a nice, realistic IVA for this as well. And some pictures: Hope you like it so far.
  19. Since you‘re saying that you want to replicate ISS modules, you will need to learn 3D modelling and texturing. I‘d recommend you to look into the part.cfg files, start changing some values around and see what happens in KSP (make a copy before of course), then slowly get into a modelling software of your choice (I‘d recommend Blender) and texturing, for exporting the model into the game you‘ll finally need Unity. There are a ton of useful modding resouces available too.
  20. Works totally fine for me on 1.7. Always worth it to just try it out.
×
×
  • Create New...