SQUAD staff
  • Content Count

  • Joined

  • Last visited

Everything posted by Maxsimal

  1. 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.
  2. Hahah sorry all, fixed the issue. You knew what I meant
  3. 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.
  4. 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.
  5. 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.
  6. Btw, this is what a helicopter blade looks like without the perspective issue.
  7. No. The only core difference between the LF rotors and the electric ones are which resource is consumed. There are of course other tuning differences. In fact, the propeller blades should also work if you attach them to anything that spins fast enough - one reason we selected this approach is its a little more Kerbal (for better or worse!) than what you see in many mods. You'll have to learn about propeller dynamics to build a craft that works well. One of our testers suggests this video as a great resource, many of the dynamics of real world propellers apply to the these.
  8. So to address a couple of issues that have come up in this thread. 1. The helicopter blades in those images were tilted back in a fashion to get them to fit within the image frame. Like someone took a picture from near the root-end, which is making them look leaf-shaped. The in-game ones are much closer to what you'd see in a real helicopter. 2. The propellers, and to a lesser extent the helicopter blades, calculate their velocity/AOA from an artificially offset position. This allows them to act like they're at a higher RPM than they actually are, to get around the PhysX RPM limit, with the consequent effect on AOA, drag, and lift. They also use their own aerodynamic values with a lift peak closer to a realistic AOA value than standard KSP aerodynamics. Pitching your blades is still 100% necessary, but the pitch amounts are more reasonable and realistic. 3. The blades have been set up so you can deploy and use the authority limiter to adjust the pitch of the blade - which you can easily do with KAL. So you don't have to set up a servo system to do variable pitch, and therefore you can set up a propeller with just a rotor, two blades, and a nosecone and have a workable system. These were on the drawing board for a while, but our time frame from BG meant we had lots of ideas that didn't get in. We saw how many people were really interested in rotor craft though so the team pushed hard to get these into the 1.7.3 patch. There are definitely a few things that we'd still like to do with them, but I think this will give a better & more aesthetic result than the elevon-based craft that the locale Kraken-mechanics have been rigging up up to this point.
  9. They were considered for both uses, as you'll see when you get to read the part descriptions.
  10. Seriously though, there'll be more details in the future.
  11. Not for the whole deployed science system, that's DLC, just for the cargo system.
  12. That portion of the feature will actually be included in the free portion of the DLC release. But it will be hidden because only the DLC functionality uses it. Modders can use it though, and it will be visible in the base game once modders add their own parts that use it. However, for a wide variety of reasons, legal, logistical, etc (IANAL but this is pretty obvious) nothing Squad does can depend on the existence of a player-built mod. We can release stuff that you guys can then make compatible with your own mods, but not vice versa.
  13. To answer a few questions that have been popping up here: 1. Yes, you'll be able to make mods to add more robotics parts with the core functionality that's being released with the DLC - but anyone who wants to use those parts will need the DLC of course. 2. There are different sizes & shapes of the robotics parts. 3. Mods will be able to add experiments for the surface experiments. 4. To deploy experiments, you'll have a Kerbal grab them from a storage container, carry them in their own inventory, and put them on the ground - the type & experience level of the Kerbal will affect the performance of some of these parts. Read into that what you will. 5. I hope you'll be pleased with what we're going to deliver for the robotics control mechanisms. We've got several features, that are still not revealed and I'm not sure how much I can say about them, that will help you control regular & robotic craft in ways that make the feature even more than it already sounds like.
  14. Actually, I meant adding it to the tracker when i was thanking the community, sorry not to be clear. However, please do also understand that there's a lead time on all fixes, and while something may be near the top of the list right this moment, it may not have been when we triage the issues we're planning to address for a particular version. And even if it's in the top 10 of the public tracker, we have a lot more plates to spin than just addressing the tracker. That said, I I know it can be hard to wait for the issue you perceive as your top priority to be fixed. I hope you'll be patient - and take comfort in the fact that the last couple of versions, at least imho, have proved to be pretty stable and addressed some of the bigger performance and stability issues we had, and I believe our team has been doing a really great job in balancing developing new features and addressing existing issues.
  15. I think you're reading too much into this! First, that this is a solo effort by me - it's hasn't been and won't be, the whole team is on board with making fixes and improving the situation for players. And second, we do consider people's existing craft and games, there's no 'damn the torpedoes' attitude here. That said, I'm happy that people are responding positively to the fixes we are making, incremental as they may seem to some of you. It can be a scary thing coming onto a game with KSP's long history and devoted fan base and then tinkering with the bits of it. Feedback about what changes you want done, and how you perceive the changes that have been made, is useful. Thank you.
  16. I'm not opposed to looking at any part fixes. There are a quite a few already on my list, but we've also got a lot of plates spinning. So no promises, but thanks for making us aware of the issue.
  17. Maneuver Engine Re-Balance Among the other features in 1.7 are a few art revamps for various maneuver engines. And amongst the feedback for those engines, some of the community pointed out that a couple of these engines aren’t as useful as others, due to their stats. The team decided to take a look and yes, we did see some tuning issues – so we decided to update select numbers of the engines we’re revamping. As with the last blog on the tuning of the MH engines, the goal here is balance and making sure each of our engines has a niche and a use, while making the smallest number of changes possible. So first, here are the raw numbers of the engines we’re changing, as well as some reference numbers of similar engines that aren’t changing. Engine Comparison Thrust (Vac) ISP Vac ISP ASL Mass Vac TWR ASL TWR Cost Cost/kN Thrust Tech Level Gimbal Range EC/s Crash Tolerance Entry Cost Ant (for comparison) 2 315 80 0.02 10.19 2.59 110 55.00 Propulsion Systems (5) 0 0 7 1500 Spider (for comparison) 2 290 260 0.02 10.19 9.14 120 60.00 Precision Propulsion (6) 10 0 7 1750 Twitch 16 290 250 0.09 18.12 15.62 400 25.00 Precision Propulsion (6) 8 0 7 1600 New Twitch 16 290 275 0.08 20.39 19.33 230 14.38 Precision Propulsion (6) 8 0 7 920 Puff (for comparison) 20 250 120 0.09 22.65 10.87 150 7.50 Precision Propulsion (6) 6 0 7 2500 Spark 20 320 270 0.1 20.39 17.20 240 12.00 Propulsion Systems (5) 3 0 7 2800 New Spark 20 320 265 0.13 15.68 12.99 240 12.00 Propulsion Systems (5) 3 0 7 2800 Place-Anywhere 7 2 240 100 0.03 6.80 2.83 280 140.00 Advanced Flight Control(5) 0 0 50 4200 New Place-Anywhere 7 2 240 100 0.02 10.19 4.25 25 12.50 Advanced Flight Control(5) 0 0 15 800 RV-105 RCS 4 240 100 0.05 8.15 3.40 620 155.00 Advanced Flight Control(5) 0 0 15 3400 New RV-105 RCS 4 240 100 0.04 10.19 4.25 45 11.25 Advanced Flight Control(5) 0 0 15 1200 Vernor 12 260 140 0.08 15.29 8.23 1400 116.67 Specialized Control(6) 0 0 50 4200 New Vernor 12 260 140 0.08 15.29 8.23 150 12.50 Specialized Control(6) 0 0 15 1800 And here’s the thinking behind these changes. Twitch & Spark: The twitch and spark are both relatively similar in size, use the same propellant, and the twitch unlocks later than the spark. The twitch is a surface attached engine with a good gimbal range, but otherwise the Spark is just better in every way – TWR, cost/KN, and efficiency. In fact, the Spark is so efficient that it outpaces many larger significantly larger engines, making clusters of them a better choice than using one of them, something we generally want to avoid as we think that both game balance and realism are better satisfied by having larger engines generally be slightly better than smaller ones, at the expense of not being as flexible in exactly how many of them you use. Therefore, the Twitch was made about half as costly, and its ASL ISP was increased to make it a better descent engine for probes on planets with an atmosphere, or as a Vernier. The Spark’s ASL ISP was lowered slightly, and its mass increased, to tilt it more toward being a Vac engine rather than just a perfect all-around engine that it was. We’re aware that the community has been using this engine for a while and kept the changes as small as possible, but this engine stood out too much from its peers when you look at the numbers to not need to adjust it. RCS Engines: The Place Anywhere 7, RV-105 RCS, and Vernor are all engines designed to steer your ship in space, making fine adjustments to orientation and course rather than providing raw power. Also, RCS is a much more realistic way to adjust a large craft’s orientation rather than piling on more reaction wheels. But the cost of these engines, we felt was just too exorbitant, especially given their low efficiency & the fact that they are typically placed in symmetry, so their costs were reduced dramatically. The mass of the Place Anywhere 7 and RV-105 also made them a poor choice compared to the more powerful Vernor and were thus lowered. However, these are still engines, sensitive pieces of equipment, so the crash tolerances were set more in line with other engines.
  18. There'll be a dev blog posted up about it soon (TM) and I'd rather have all our thinking posted there rather than address it in a quick comment here.
  19. Hey I'm not the designer primarily in charge of UI/UX, that's @Bea_Pin, but I'll share some of what goes into it. Even a fairly minor task takes a chunk of time when you have to consider the feature as a whole. We actually have done almost a dozen different mockups with ideas & variations of the AGL/ASL design. Without diving too deeply into how the sausage is made, all of the following get considered: 1. What sort of affordance the UI requires. An affordance is something that lets the user know the action of the UI element. The more advanced a feature is, the less affordance we tend to give it, because they take space and we have dozens upon dozens of functional UI elements on screen at once. Not to toot KSP's horn too much, but compare it to many flight simulators - that still don't have to support as many situations or as much information as KSP - and how much screen space those games tend to cover with their on-screen UI, and you'll see KSP packs a lot of punch into a relatively low % of the screen. 2. Current UI style Not only do we not want to rework things too much for the sake of dev time, but we have a lot of very conservative players who don't like too much change. And we don't want to shuffle around UI elements that the player is already familiar with - that's one reason we didn't decide to swap the climb rate indicator out for a radar altimeter. 3. Localization One of the reasons this initial variant was selected was to give enough space for localization - we sent off text early for localization to see if we could get 'ASL' and 'AGL' to fit on buttons initially, and found that the Japanese and Chinese variants text was overlarge for what one of our ideas would handle. 4. Player capabilities This includes: how small a screen resolution we need to support, to color blindness, to vision issues that mean we try to keep all functional text at 12pts or more. ---------------------------------------------- To give a concrete example: we hide away the advanced delta V information behind clicking on the stage icons - that's not a great affordance at all, but that information is more for a power user, and lets us keep the screen space usage down and the stage UI style the same as people are used to. The stage information flyouts also mean we have a bit more space for text on those. Even with all that, we don't think we get it right all the time - so we give out previews to both our pioneers group and to the audience to get feedback. When we see feedback we do evaluate it - and compare the cost of additional changes vs work on other features in the pipeline.
  20. You can also click the actual readout, we did not miss the comparison to the orbital/surface speed display. As for form factor of the display, that's still a bit of a WIP.