Maxsimal

KSP Team
  • Content Count

    231
  • Joined

  • Last visited

Everything posted by Maxsimal

  1. Glad you found some of this helpful, and that's a great tip! Helicopters are complicated, and I'm impressed with how much of the community has figured out how to work with them. In many ways I'd say they're more complicated, at least physics-wise- than rockets - more force interactions and coupling.
  2. I understand it changes with changing airspeed - one reason I think most players will prefer to use SAS - but not sure about why you think it takes a while to set up? You don't have to use trim tabs or something like that, just use the keyboard-based trim adjustment.
  3. I think you're thinking that we should have linked some not-necessarily symmetrical blades to have them somehow manage themselves, across different parts to balance your lift, through feed-forward control system? That's just not something that works well with the lego-style functionality of kerbal parts - any unaccounted for configuration is going to cause more problems, and require further dev effort, and possibly interfere in something else the player is trying to do. We avoid that when possible. Instead, and much more simply, players can either trim their roll with mod-Q/E, or use SAS to balance the forces through a feedback control mechanism. Another advantage is neither of those required new work
  4. We actually did investigate having precession something the control system would account for, and messed with some stuff to deal with it- until we realized that PhysX does not actually simulate precession at all. So no, the blades don't deal with it because it's not a thing in our physics engine.
  5. This isn't really an apples to apples comparison. What's happening here is not just that you have the Oberth effect in play, when you're comparing to a vessel that's in Kerbin's orbit but not circling Kerbin - you also have the vessel's velocity around Kerbin itself. Think about it this way - if you suddenly deleted Kerbin when you're making your prograde maneuver from LKO, assuming you're in a 0degree inclination orbit, you would not be at 9285m/s around the Sun. You'd be at 9285m/s + your Kerbin orbit velocity - so ~ 2300m/s = 11585m/s - enough by itself to do the Jool transfer. When you make that comparison, you can see that it is still more expensive to depart for Jool from Kerbin, when you're in its gravity well - you just have a lot of kinetic energy in your orbit around Kerbin that you're leveraging.
  6. One big change we’ve made this version is the addition of some advanced control code to the blades, to help you build helicopters and quad copters that work like the real thing. This blog will help you understand what the new functionality does and how you can use it. Advanced Blade Controls When you enable Pitch/Yaw/Roll control on a rotating blade now, the blades themselves will make a decision on whether the blade needs to be in cyclic or collective mode - on a per axis basis. Image 1: Blade COM alignment For this craft above, the blades are aligned with the center of mass in the forward direction - so they’ll use cyclic mode for pitch. They’re far apart horizontally, so they’ll use collective mode for roll. And because their axis of rotation is flat, they won’t attempt to provide any control input in yaw. Cyclic mode: Cyclic mode is what a normal helicopter’s main rotor does to control the pitch and roll of the helicopter. They will change their pitch - by the limits you set in the authority limiter control of the blade - as they spin around. This creates more or less lift to one side or the other of the blade’s disc of rotation. Image 2: Cyclic Mode Pitch Collective mode: Collective mode is what a normal helicopter does when it wants to change how much overall lift is created. But as you can see in the picture below, adjusting the relative lift on the two different sets of rotors will cause the craft to roll. Image 3: Collective Mode Roll Summary and Videos: So that’s what our blades now do in a nutshell. However, understanding these topics can be pretty complicated. I really recommend checking out some of these excellent Youtube videos for further study. Smarter Everyday’s series on Helicopters - Dustin’s videos are fantastic, and these are no different: Craft Building Tips: Here are a few tips to help you build your helicopters/quad-copters/etc. Make sure to set your authority limiter pretty low. One of the potential trouble spots you can have is if the blade pitches too much trying to generate control - if it goes OVER the stall limit and starts generating less lift, you’ll get the opposite of what you wanted. 2 or 3 degrees will often be enough. Helicopters can be finicky to control. Even if you’ve got everything right, any change in a helicopters forward or vertical motion affects the lift on the blades, which generate input coupling. If flying a plane is like driving a car, then flying a helicopter is like riding a unicycle - don’t be surprised if you have to constantly adjust inputs. Chinook-style craft will generate interesting and unpredictable effects due to axis coupling effects. If you want to build a really stable Chinook style craft, consider looking into how those are actually built - they adjust their whole rotor assembly plane of rotation, rather than just using cyclic/collective. http://www.chinook-helicopter.com/standards/Army_D_Model_AQC_Classes/Flight_Controls.pdf The blade controls will work well for using a tail rotor, blades rotating in any axis will respond appropriately. That said - it’s still easier to manage a helicopter with two counter rotating blades. Finally - if you decide none of this is for you and you just want a helicopter without worrying about the physics so much, feel free to just turn off the Pitch/Yaw/Roll blade controls, and use a reaction wheel to generate the torque you want - no one on the dev team will accuse you of cheating, we promise!
  7. No, I'm a cat wrangler. Community manager's job is harder. Amoeba wrangler maybe?
  8. That is clearly the first thing we'd do with such a technology...
  9. Warping isn't completely unrestricted. If your PE is too low - below the edge of the atmosphere or the highest altitude + some margin, previous warp restrictions apply, to help players avoid over-warping into a planet.
  10. Phase angle between two perfectly circular 0 inclination orbits w/Keplerian orbital motion shouldn't be a range, there's an exact value that you can get to analytically for a simple Hohmann transfer. Kerbin's is perfectly circular, and Duna's is nearly so. I believe that calculator is narrowing the problem down by assuming Duna's is as well. However, even if you did use Duna's real orbit rather than assuming it's circular, I don't think the range would be that wide - transfers to other bodies with more eccentric/inclined orbits though, you're right, it would be a wider range, and dependent on which orbit you're looking at. If you notice, neither of those places mentions which Kerbal date you should depart from/asks you for which Kerbal date to search from.
  11. Every rocket I destroyed was an accident. And you can't prove otherwise.
  12. I helped make sure Kerbals suffocate to death if you try to take them to space riding in a command chair without a helmet on.
  13. I think that's known as 'hot mess' staging.
  14. That's correct. ISPs are slightly higher than the kickback for these two, but still lower than LF engines.
  15. You know Jeb's a pro - he's gonna go back home on EVA pack fuel alone. Was always the plan.
  16. 1700kn and 3300kn in vacuum. They'll rattle some windows.
  17. Don't have a long time to get into the details today, but the answer you're looking for is no, there's no effect the front propellers pass to the rear propellers. Something else is different about the two propellers, but without looking at the craft file, I can't say what that might be - it'd have to be a difference of blade angle or a difference of rotor RPM.
  18. Hahah sorry all, fixed the issue. You knew what I meant
  19. We’ve raced to fix bugs and add a whole bunch of new parts and functionality in this update – it’s almost a new version unto itself. I just want to take this time to highlight some of the additions and changes. Propellers: Our new propellers take a different route than jet engines in the game. Jet engines, while historically more difficult to construct, are simpler for a pilot to manage. Propellers are not meant to compete with them. However, propellers do offer one unique benefit – you can build rotor craft to fly on planets without oxygen in its atmosphere with the electric rotors. I'll cover the basics here - but if you want a more in depth look behind the physics of propellers, this video goes into a lot of the actual real world mechanics - many of which are simulated by KSP. Managing Propellers: So, what makes propellers so difficult to manage for a pilot? It’s because you have to manage the angle of attack of the propeller – which is basically just a spinning wing. First, consider the case with a normal fixed wing aircraft, illustrated below: The above is easy to manage. When you want to increase angle of attack, and get lift - at the cost of more drag – you point the nose – and your wings - above prograde. In level flight, that just means pointing them above the horizon. Now, consider a spinning propeller on plane that is not flying – just sitting still with its brakes on and the propeller spinning. In this case, all the airspeed is coming from the fact that the propeller is moving through otherwise still air – pictured below for what one section of the propeller would see. The angle of attack is still large and the propeller can generate a lot of lift, though it also causes a lot of both drag and the lift in a direction not fully parallel with forward – both of which the torque of the rotor has to counteract. Now, picture what happens when the plane starts moving. Now the airspeed across the propeller comes from both the rotation of the propeller and the movement of the aircraft. Consequently, the angle of attack has gone down dramatically, and you get less lift. This is why propeller planes either have to change the angle of propeller blades – called their pitch – or remain limited to a low airspeed. You could increase RPM, but RPM is limited in both KSP and the real world because propellers lose effectiveness if the propeller tips go faster than mach 1. In KSP, you can adjust the angle of our propellers by setting their ‘Deploy’ field to ‘Extended’ in the PAW, and adjusting the authority limiter, as pictured below. KAL-1000 can assist you with coordinating the settings on multiple sets of propellers if you build a multi-engine plane. Using aero-debugging visualization – F12 by default – can assist you by letting you visualize the lift off of the propeller – your aim should be to adjust the pitch so that the yellow arrows are as long and as far forward as possible. Rotor Changes Rotors have seen a significant set of changes and improvements, as well as the addition of the liquid-fuel consuming rotors, which model a turboshaft engine for a propeller plane and for a helicopter. Now all rotors are set to max out at 460 RPM – near the limit that our physics engine allows. Further, now you can reach that RPM limit regardless of how little torque is applied. Before the rotor RPM and torque were unrealistically interrelated. However, just as a rocket can reach any velocity in space regardless of how much thrust you use - lower thrust just means it takes more time - now a rotor can do the same, barring things like atmospheric drag that would oppose it. Finally, rotor RPM is more stable, you won’t see the RPM numbers vibrating as much. This all required retuning. Further, our initial pass for rotor power gave too much torque. Rather than reducing the available torque, we’ve increased the resource usage and weight/cost requirements for a given motor power. Be aware that you absolutely don’t need to always keep the motor size at 100% - for many applications, a lot less torque will be more than enough. Robotics Resource Usage Changes While we endeavor to simulate physical systems in as realistic way as possible, that has to be balanced against fun and development feasibility. With 1.7.3, we’ve now improved our resource usage simulation for robotics parts, though it is still by not 100% accurate to the real world. What this means is that in 1.7.3 the traversal or rotation rate you request from a part will now impact how much EC/LF is used by the part, where before it was not a factor in the resource usage calculations.
  20. Some improvements may be made in how the LF rotors work, calculate their consumption and communicate it to the player in the future. However, the overall fuel usage is unlikely to change. This craft that I threw together can just about circumnavigate Kerbin - fewer passenger compartments and more fuel would easily allow it to do so. That's more than enough efficiency for Kerbal - we understand that a real long-haul turbo prop would be able to go Keep in mind that propellers are harder to use the jet engines - that's just part of how we implemented, and also mirrors reality.
  21. This actually goes beyond just the numbers. We changed how the PhysX joint is configured, the rotor behavior is more stable now - if you watch the RPM figures they will hold a lot steadier than before.
  22. Btw, this is what a helicopter blade looks like without the perspective issue.