Jump to content

Kartoffelkuchen

Members
  • Posts

    1,651
  • Joined

  • Last visited

Everything posted by Kartoffelkuchen

  1. Set the two booster engines' throttle mode to independent via right click part menu and set throttle to 100% (you might need to turn on Advanced Tweakables in the game settings). Then you can just throttle only the core engine as usual.
  2. Yo guys, I am looking for a wind mod which can be used with the stock atmosphere. The only mod I know of is Kerbal Wind, but that one's for FAR only (though it still works in KSP 1.7 last time I checked) and I dislike the idea of using FAR due to nowadays pretty well-modelled atmosphere. Kerbal Weather Systems is still listed for 0.90 so that one won't work. Maybe someone more competent in programming than me can have a look at this? I think it'd be a great addition to the game, one that has not been done yet (at least for the more current game versions), making the game generally more challenging, be it when flying rockets or of course aircrafts and more realistic. Cheers - KK
  3. If all you need is a Centaur, that one should work. RCS plumes micht be inverted though. Rest of the pack probably won't work so nice.
  4. Well, noone forces you to use all the build-in accessible flight variables like altitude, airspeed etc. You are free to code your very own IMU and so on by using the data you can get from the stock in game sensor parts, would actually be quite interesting to try that.
  5. 1.8.1 shouldn't have changed anything to render launchers pack non usable. I'll check it out myself again too, but you probably messed up when installing it somehow.
  6. Sorry, I'm a little out of the loop currently with my mods. I think that tipping over has to do with inaccurate drag cubes being generated, I guess it also happens with the other Atlas 5xx rockets? I'm not sure if I want to update the Atlas rockets, they are really old and, in my opinion, quality is not that great. So an update for the Atlas pack probably won't happen anytime soon, though maybe I decide one day to pick it up and polish these rockets again, but no promises.
  7. Nope, you'd break the mod. Why would you want to do that?
  8. 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.
  9. 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
  10. Yeah what @scimas said, it's get only and the DLC seems to be able to only read pilotcontrol.
  11. 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!
  12. 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.:)
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. That's interesting, I'll have a look into it. Apart from that, Starhopper WIP pictures!
  18. 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.
  19. 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.
  20. 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!
×
×
  • Create New...