Kerbal Space Program 1.7.3 is live!

[XLjedi]

On 7/11/2019 at 9:56 PM, MechBFP said:

Anyone know how to correct for the roll problem for a single prop aircraft without resorting to setting the trim every time?

Yes, I know how to fix this... PM me if you'd like to discuss or open another thread.

[Snark]

Some content has been split off into a separate technical support thread:

...and, furthermore, more content has been removed due to argumentative bickering, finger-pointing, name-calling, etc.  Folks, let's please remember to keep it friendly.  We're all pals here, we all like KSP, and we would all like to be able to play the game we bought that we love so much.  So we're all on the same side.  Try to remember that, please?

Thank you for your understanding.

[Shadowmage]

On 7/13/2019 at 7:48 AM, Foxster said:

I'm sure that's all very accurate to RL but it doesn't feel Kerbal. 

Honestly, its NOT accurate to real life (at least RC modeling).  On my aircraft, I slap on a prop, hit the throttle stick, and watch it leap into the air.  None of this dickering with deployments, inversions, etc.

For my RC craft, it goes about like this:

Put one of these:

Onto one of these:

And... IDK... profit?  Have thrust?  It really is that simple.  Zero playing with orientation, zero messing about with deployment toggles, zero setup. 

Put motor on airplane.  Put propeller on motor.  Apply electricity/generate torque.  Get thrust.

Granted, these are fixed pitch props....  But...that seems exactly like a 'stock' KSP thing to me -- a selection of pre-configured fixed-pitch propellers fits exactly in the stock design paradigm.

Even the collective pitch RC propellers aren't that much of a PITA to work with.  One extra axis to map to a servo, and one additional servo to configure, and the rest is exactly the same (mount propeller on motor, profit!).  Even full cyclic-collective propellers (yes, they are a thing...when you want extreme thrust-vectoring on an airplane) are only slightly more complicated to setup, requiring only adding additional servos for two more axes'.

 

After playing around with the propellers and helicopter blades, I will certainly agree that these have been made far-too-needlessly-complicated for a stock KSP mechanic.  And I love complexity and configuration, so for me to say something is 'too complex', generally means something is wrong with it at the basic design level.  (essentially, there needs to be configuration, but things should 'just work as expected' when used in their simplest configuration; these do not work as expected, in any configuration)  (I'm not saying that don't work... because they do in very specific configurations... but the configuration needed to make them work is has zero logic in it).

I guess I'm just curious why it is such a PITA to configure the props for a plane?  It could be that I am trying to configure it wrong... but that again goes to my last point -- it should be intuitive enough that it should be extremely difficult to 'configure it wrong'.

 

[shdwlrd]

16 minutes ago, Shadowmage said:

After playing around with the propellers and helicopter blades, I will certainly agree that these have been made far-too-needlessly-complicated for a stock KSP mechanic.  And I love complexity and configuration, so for me to say something is 'too complex', generally means something is wrong with it at the basic design level.

I have to agree with this, I was expecting just to slap on the props and blades and to have them just work. Even if they didn't work well. It would give you a base to start tinkering to increase the efficiency of the prop. (And I have to say, once you do get them trimmed right, they are as efficient as the Weezer or Juno but with more capability.)

IDK what the best solution would be, but either having the props and blades attach deployed, or adding a few degrees to the angle of the blades when they snap on, or already have them setup to a basic usable configuration could help guide the user get started with the blades quicker. But something needs to be done to help the user figure out how to use them.

[Snark]

41 minutes ago, shdwlrd said:

IDK what the best solution would be, but either having the props and blades attach deployed, or adding a few degrees to the angle of the blades when they snap on, or already have them setup to a basic usable configuration could help guide the user get started with the blades quicker. But something needs to be done to help the user figure out how to use them.

Agreed that "gosh, this sure feels complicated" is an impression I get when I use them.

On the other hand... I'm not inclined to kvetch (at least not until I've had a lot more time to get used to them), mainly because it's not obvious to me what would be "better".

First, I don't actually know that there's a simple one-size-fits-all-craft solution for how the props could be designed / attached.  For example, optimum blade pitch appears to me (at least anecdotally based on the limited playing I've done thus far) to depend on both air density and airspeed... not sure how to make that work.  I'd rather have software make no assumptions at all, than to make some default assumptions that turn out to be wrong in a lot of cases.  Because the no-assumptions-at-all mode at least forces me to figure things out early and come to an understanding of the fundamental dynamics involved, which in the long run I think is better for me.

Second, any "solution" would have to be not only one-size-fits-all-craft, but also one-size-fits-all-players, and I don't know if that's even vaguely possible.  People use the game very differently, and a "solution" that makes things better for one group of players would make them worse for others.

For example, I don't use the blades at all like you describe.  For me, that's not what "deployment" is for.  I use "deployment" simply as a form of "gear shift".  I'll set all my prop blades to control authority 20 (much lower than the default 100), and I attach them to the craft in the editor not deployed, and I manually adjust the rotation of the blades to something "reasonable" for that craft (e.g. 15 degrees or whatever, it varies with craft).  And I assign "toggle deploy" to some action group.  That way, the craft "just works" straight off the runway when launched, and I can shift between "high gear" and "low gear" by pressing a button.

That seems simple and logical to me, and I enjoy playing that way, and it's easy and quick for me to build craft.  But I do it differently from how you do.  Your suggestions to "improve" the way they work would actually make life more difficult and confusing for me.  And my suggested "improvements" (i.e. to make my own playstyle simpler) would probably make things more confusing and less convenient for you-- i.e. my own list would be "reduce default deployment amount to 20, make the default attach position of the blades be parallel to the plane of rotation rather than parallel to the axis".

So if I try to put myself into the shoes of the game designer... it's not clear to me that there exists a "sweet spot" of design to default to, nor is it clear to me how to address different players' design habits and styles.

So I think it's a hard problem and I'm not inclined to point fingers until and unless I can think of a solution that makes more sense to me (for all craft, and all players) than the current one.  Which I haven't, yet.  Doesn't mean there isn't one, just that I don't have one myself. 

 

1 hour ago, Shadowmage said:

After playing around with the propellers and helicopter blades, I will certainly agree that these have been made far-too-needlessly-complicated for a stock KSP mechanic.  And I love complexity and configuration, so for me to say something is 'too complex', generally means something is wrong with it at the basic design level.  (essentially, there needs to be configuration, but things should 'just work as expected' when used in their simplest configuration; these do not work as expected, in any configuration)  (I'm not saying that don't work... because they do in very specific configurations... but the configuration needed to make them work is has zero logic in it).

I guess I'm just curious why it is such a PITA to configure the props for a plane?  It could be that I am trying to configure it wrong... but that again goes to my last point -- it should be intuitive enough that it should be extremely difficult to 'configure it wrong'.

I agree that it seems complicated, and I wish it were less so.  I just don't know that significant simplification is possible.  Maybe it is-- but it's not obvious to me what that would be.  It may simply be that this is a hard problem, and that they settled on this because they couldn't find a simpler way that worked well enough to be shippable.

[Foxster]

17 minutes ago, Snark said:

So if I try to put myself into the shoes of the game designer... it's not clear to me that there exists a "sweet spot" of design to default to, nor is it clear to me how to address different players' design habits and styles.

If I was to put myself in the shoes of the game designer I'd say this has been rather half-baked. 

The look and even the functioning of the parts are great. What is missing is some polish. I'm really hoping that's the case and that a mopping-up build will sort things out.

I think some other's ideas around there being too many parts are probably right. It has added to physics issues (see the mess under time warp). Small, medium and large prop engines (electric and LF) with props attached that just worked as the rocket and jet engines do would have been well received by a lot of players. 

 

[Snark]

7 minutes ago, Foxster said:

What is missing is some polish.

Such as?  (Not doubting you or questioning your position, just wondering what you specifically have in mind.)

8 minutes ago, Foxster said:

I think some other's ideas around there being too many parts are probably right. It has added to physics issues (see the mess under time warp). Small, medium and large prop engines (electric and LF) with props attached that just worked as the rocket and jet engines do would have been well received by a lot of players. 

Not gonna disagree with you there, I think that would have been relatively low-effort and more re-use of existing code, and a lot of people would have liked it.

But then, a lot of people also want to build things-that-move-with-physics.  It's not obvious to me where the "right" answer would be, from a business perspective.  Personally?  A simple electric motor that looks like a propeller but in physics terms is just an electric-thrust engine that works in any atmosphere, would suit my own needs just fine.  But I don't know what percentage of the KSP demographic I represent, in that regard.

In other words...  I think "which way is best" is a harder question to answer than "what's good".  It's unclear to me, here.  Need more time to play with it and "settle in" before I form strong opinions.

[Foxster]

1 hour ago, Snark said:

Such as?  (Not doubting you or questioning your position, just wondering what you specifically have in mind.)

I posted some stuff above but basically: Make props auto-pitch for best thrust, hide some of the other settings by wrapping them into a throttle setting and making them stageable. Maybe also with options for the existing settings available as non-defaults to fine tune performance for those interested in such things. 

This doesn't need to mean reskinned jet engines as someone implied. I'd like to see them balanced with the jet engines. Maybe as low thrust but low/zero fuel consumption engines available early in the tech tree. 

Edited July 15, 2019 by Foxster

[shdwlrd]

@Snark I don't disagree with any points you've said. And I understand that Squad did what they felt was best for the props and blades. I'm just saying throw the player a bone and have a setup that works out of the gate. Even if it works like utter crap. Show the players that it works, and if you tinker with it, you can make them work better. 

I'm just throwing out possible solutions. I'm just as guilty as everyone else in KSP for trying things before understanding how they should really work. I'm just use to Squad releasing parts that work out of the gate. In this case, there is little guidance to help the player out. That's my major gripe is about the props and blades.

Edited July 15, 2019 by shdwlrd

[Waxing_Kibbous]

I'm in the camp of more standardized propeller+motor units (boring I know). Just as a specific rocket engine has specific stats- thrust, efficiency, etc., I'd like to see propeller units act the same. Personally I like the idea of problem solving with constraints, but I understand that some people like to really delve into the engineering side of things and customize something to be perfect for it's purpose. I imagine there are long meetings amongst the devs dedicated to this balance. Having multiple means of applying force- RCS, SAS, rocket engines, jet engines, propellors, AND giving players free reign to use any combination, AND keeping it friendly to use has got to be an intense mental exercise.

Anyhow, cool update, always fun to see more ways to play and things to do.

[XLjedi]

I love the way the propellers have been implemented.  I don't think they are too terribly difficult to figure out.  I made this video...  it's a bit long, but I hope it helps someone. 

@SQUAD did a remarkable job in my opinion.  If they had asked me (they didn't, LOL) how to implement props and rotors, they did exactly what I would've asked for.  They even included some stuff (the KAL-1000) to link em all up that I would not have asked for...  but I love it!

Actually, this is more of an hour long advanced tutorial and discussion around how to use the new 1.7.3 propellers, rotors, and KAL-1000.  ...along with a few other observations, tips and tricks.

Edited July 15, 2019 by XLjedi

[Angelo Kerman]

At the least, if they don’t already have one, the KSPedia would benefit players with a tutorial on how to use the new propellers and rotors. Otherwise they seem a bit too complicated to use out of the box.

[XLjedi]

42 minutes ago, Angel-125 said:

At the least, if they don’t already have one, the KSPedia would benefit players with a tutorial on how to use the new propellers and rotors. Otherwise they seem a bit too complicated to use out of the box.

LOL... posted right under my hour long tutorial video.  If folks like it, I can post it to the KSPedia.

[XLjedi]

14 hours ago, Boris-Barboris said:

IMO part per blade was a mistake. Both the PhysX engine and old part module code are not up for the task. Lifting surface module was written on the different assumptions. Part joint system is unfit for blade placement (look at the effect of time warp on this 10-second segment: https://youtu.be/2EiyoE2Z1qA?t=668) , integration time step is too large to precisely perform cyclic control on high rpm...

It should have just been a new module with the ability to shape blades and change their count. Most bits of detail and simulation can be done better in the module, with the exception of per-blade damage I guess.

 

It's just a time warp visual glitch that appears to do no damage... maybe just note it as a low priority bug in the bug tracker?

[Boris-Barboris]

1 hour ago, XLjedi said:

visual glitch

That's not "visual", the part's collider is where part's model is in KSP/Unity.

4 hours ago, shdwlrd said:

In this case, there is little guidance to help the player out. That's my major gripe is about the props and blades.

That's not the guidance that is missing but the core game subsystem.

Imagine if KSP was a game where there was no centralized throttle, and you had to modify each engine's thrust by hand. Or solar panels that must be manually oriented towards the sun.

That sounds terrible, but I think this is exactly the level of propeller feature maturity: core without a shell. At this stage you transfer the system to UI/UX guys, not players. Unless, of course, Squad thinks that it's the modders that must step in now, wich is doubtful. They will probably just observe our struggles for a couple of months and come up with some simplifications in the next patch.

[XLjedi]

44 minutes ago, Boris-Barboris said:

That's not "visual", the part's collider is where part's model is in KSP/Unity.

Doesn't effect gameplay... Doesn't blow up the ship...  Doesn't really concern me...  

I noticed it yesterday, and it wasn't worth my time to post it as a bug tracker item.  It'll get sorted.

5 hours ago, shdwlrd said:

In this case, there is little guidance to help the player out. That's my major gripe is about the props and blades.

Look up a few posts in this thread; I took an hour to explain it with a video tutorial.  I would agree it's not as painfully obvious as snap-on engine part... but once you make a few lateral connections, the system they gave us makes a lot of sense, and we can do amazing things with it.  Rather than play toy thrust generators, they gave us real kerbal aerofoil physics to negotiate.

 

 

 

Edited July 16, 2019 by XLjedi

[Bartybum]

8 hours ago, Shadowmage said:

Honestly, its NOT accurate to real life (at least RC modeling).  On my aircraft, I slap on a prop, hit the throttle stick, and watch it leap into the air.  None of this dickering with deployments, inversions, etc.

Even the collective pitch RC propellers aren't that much of a PITA to work with.  One extra axis to map to a servo, and one additional servo to configure, and the rest is exactly the same (mount propeller on motor, profit!).  Even full cyclic-collective propellers (yes, they are a thing...when you want extreme thrust-vectoring on an airplane) are only slightly more complicated to setup, requiring only adding additional servos for two more axes'.

After playing around with the propellers and helicopter blades, I will certainly agree that these have been made far-too-needlessly-complicated for a stock KSP mechanic.  And I love complexity and configuration, so for me to say something is 'too complex', generally means something is wrong with it at the basic design level.  (essentially, there needs to be configuration, but things should 'just work as expected' when used in their simplest configuration; these do not work as expected, in any configuration)  (I'm not saying that don't work... because they do in very specific configurations... but the configuration needed to make them work is has zero logic in it).

 

I can agree with your first point, but only to the point that the devs should've added fixed pitch blades too, for those who aren't interested in variable pitch. Saying that variable pitch blades aren't accurate to real life because they're not fixed blades is not a valid argument, because they're not trying to be fixed blades. Other than that, variable pitch is awesome, and (save for the few problems outlined below) I don't see how else it could be set up. To me it's no more complicated than configuring flaps with an incremental authority limiter.

Cyclic-collective pitch propellers are notoriously difficult to build efficiently and stably out of props, and (as far as I'm aware) aren't possible with just the blade and rotor pieces, so I'm not sure what point you're trying to make there.

So far I've encountered three main issues:

1. I don't think the symmetry and inversion issues are the fault of the blades, but the way KSP handles multiple symmetry groups for the same part. I've found that if hubs are part of the same symmetry group, then you can't attach X blades to one, and X blades to the other, because the editor will automatically set symmetry to mirror instead of radial, and add a single blade to each hub. As a result you can't have both rotor hubs be part of the same symmetry group, and consequently the hub "invert direction" tweakable becomes redundant when using blades.

2. However (and I WILL fault the blades for this), the deployment of blades is reversed (for me anyway), meaning that positive pitch requires a negative input, which logically doesn't make sense. When you choose the counterclockwise blade variant, the required deployment direction suddenly reverses. This is strongly tied to the fact that different variants are symmetrical around the wrong plane (the opposite blade variant is 180deg backwards, rather than just counterclockwise but still facing forward), so you have to also rotate the blade.

3. There's no hologram indicator to say which orientation is forward facing.

These problems are purely editor based, and I'd imagine 2 & 3 are simple fixes (number 1 will be a bit harder). However, once you acknowledge these problems they're super easy to work around.

[XLjedi]

12 minutes ago, Bartybum said:

These problems are purely editor based, and I'd imagine 2 & 3 are simple fixes (number 1 will be a bit harder). However, once you acknowledge these problems they're super easy to work around.

I really don't see any problems or a need for any workarounds...  

Edit: additionally, the deployment of blades is not reversed. (possible your understanding of lift vectors is though) ...and there are two variants for each blade, one for CW engines and one for CCW, make sure you're using the right ones for the direction your engines are turning.  Why do you think you need a hologram to determine the facing of a blade?  Watch my video.

 

Edited July 16, 2019 by XLjedi

[OHara]

On 7/11/2019 at 2:03 PM, Wallygator said:

why do the turboshaft engines show up under "robotics"?

I wonder if this was a very prescient rhetorical question, subtly making the point that became clear in the following pages: The new engines are not at all the plug-and-play parts in KSPs "engines" category.

KSP does not yet have propeller engines or helicopter engines, in the usual sense of KSP engines.
Rather, KSP's Breaking Ground DLC includes parts with which one can learn to build a propeller or helicopter engine.

I think that propeller engines, both electric and air-breathing, with the simple control-interface like that of the Goliath, etc.,  with appropriate prop models and animations and specifications, would still be a welcome addition to the base game.  I think they would co-exist nicely with the robotic parts for those that also have the DLC, because of their different niches of use (and at least hope they could spur enough sales of KSP to make it wise for Squad to spend the effort).

Edited July 17, 2019 by OHara
spling

[Bartybum]

1 hour ago, XLjedi said:

I really don't see any problems or a need for any workarounds...  

Edit: additionally, the deployment of blades is not reversed. (possible your understanding of lift vectors is though) ...and there are two variants for each blade, one for CW engines and one for CCW, make sure you're using the right ones for the direction your engines are turning.  Why do you think you need a hologram to determine the facing of a blade?  Watch my video.

 

I understand how lift vectors work - I study aerospace engineering

I position mine such that 0 deployment corresponds to 0 pitch:

And then forward and reverse pitch, respectively:

 

Dunno what to tell you, but that's how I do it. I base it off this:

I have no idea what other way people would position the blades.

Edited July 16, 2019 by Bartybum

[bcqJC]

1 hour ago, XLjedi said:

 ...and there are two variants for each blade, one for CW engines and one for CCW, make sure you're using the right ones for the direction your engines are turning.

 

Just noticed this now. I've been using the rotate tool to set the direction of the blades :)

I just built my first "plain" helo - no contra-rotating blades just like most helos IRL.

I assigned the authority limiter of the heli blade to the Translate U/D axis to make the helo go up/down. For the tail rotor, I used the smallest rotor motor and smallest prop blade. Then mapped them to the Yaw axis so that I can swing the tail using the Yaw controls. Torque limit for main and tail motor are both mapped to Main Throttle. The rest of the axis groups are default.

It is flyable  without any SAS, albeit a bit difficult. With SAS on, I don't have to baby sit it all the time. I can actually take my hands off the keyboard for a few seconds and let the helo fly a bit.

Lesson#1 for me was the wrapping my head around the distinction between the "Motor Size and Output" in the SPH, and the "Torque Limit" in flight.

Lesson#2 was "less is more" when it comes to torque. Before, I thought that I would need lots of torque to make things spin around. My plain helo only has 10% Max Torque on all motors. I think set that to 5% because I can fly the helo at just 1/3 throttle. The less torque you use, the less of it you need to counteract.

Those are just some lessons I learned. I think some craft examples and/or KSPedia articles stepping people through how to build their 1st working helo without going through the "principles of flight", will go a long way towards lessening the frustration of trying to enjoy the new parts on the first try.

[XLjedi]

31 minutes ago, Bartybum said:

I understand how lift vectors work - I study aerospace engineering

I position mine such that 0 deployment corresponds to 0 pitch:

And then forward and reverse pitch, respectively:

 

Dunno what to tell you, but that's how I do it. I base it off this:

I have no idea what other way people would position the blades.

I see... you're installing them a bit different than I did.  I thought the range of motion was a bit wide on the props, so I just left mine pointing forward, but I like your positioning better I think.  I may have to tinker with that, I was trying to go for easiest possible installation to get people to a workable fixed blade prop.  But the way you point the leading edge is probably more correct, and it's consistent with how I mount the rotor blades.  ...and your forward/reverse thrust has the correct leading edge.  So agreed.  But why do you think that works in reverse?

Edited July 16, 2019 by XLjedi

[Bartybum]

17 minutes ago, XLjedi said:

I see... you're installing them wrong.  For these kerbalized versions of propellers.  You should install them so the leading edge faces directly forward.  If you watch my video, you'll see how the full range of motion works.  I'm not an aerospace engineer, but I've done my share of studying as well and held a pilots license for nearly 30 years.

Well then, I'm confident in saying the devs got it wrong. Under their system, reverse thrust is done by driving an airfoil backwards into the flow (see below), which is absolutely not how reverse thrust works in real life. Real reverse thrust is done by driving the airfoil forwards but at a negative angle of attack to the flow.
 

Thoughts, devs?

Edited July 16, 2019 by Bartybum

[shdwlrd]

2 hours ago, XLjedi said:

Look up a few posts in this thread; I took an hour to explain it with a video tutorial.  I would agree it's not as painfully obvious as snap-on engine part... but once you make a few lateral connections, the system they gave us makes a lot of sense, and we can do amazing things with it.  Rather than play toy thrust generators, they gave us real kerbal aerofoil physics to negotiate.

Yes, that is very true. And I'm loving every minute of messing around with it. From playing with the stock (Kraken) propeller craft of old, and keeping tabs on the announcement thread for the props and blades I was able to quickly figure out what was going on and how to get them working. (I'm still annoyed that there is no obvious way to tell what the direction of thrust should be between the props and rotors.) I was thinking about players that never made or played with the stock (Kraken) propeller craft or didn't bother reading through the announcement thread for the props and blades. There is no clues in the editor to how to set things up. There's nothing I noticed in the game that says you have to adjust the control authority to adjust the blade pitch. There's no hint you should fly with the aerodynamics overlay on to see when your blades are stalling out. And you can only test your setups in the flight scene. That can lead to a bunch of jumping back and forth to make sure everything is correct because there is nothing to clue you in if your setup is correct or not. That's where my problems lie.

XLjedi, thank you for making a video on this, I do plan on watching it later. But it was something Squad should have done. (Is the craft you made on KerbalX? I would love to see how your are doing the counter rotating blades. The ones I've made so far have been lack luster so far.)

@Boris-BarborisCreating an automatic control mechanism for the props and blades would be difficult to do without knowing were the stall points for the blades would be. It would need input either from the player or by following the aerodynamic forces. That can be muddied quite a bit depending on the craft you made, or what you are doing at the moment. There were times I was purposefully stalling the blades to slow my craft down with out touching the throttle. How do you teach the program to look for something like that?

[XLjedi]

2 minutes ago, Bartybum said:

Well then, I'm confident in saying the devs got it wrong. Under their system, reverse thrust is done by driving an airfoil backwards into the flow (see below), which is absolutely not how reverse thrust works in real life. Real reverse thrust is done by driving the airfoil forwards but at a negative angle of attack to the flow.
 

Thoughts, devs?

No, I edited my post...  I think your logic is sound. 

I just tested it with leading edge as you have it and I see what you mean by the negative value.  On the one hand, if you install it with leading edge facing forward (as I did in my video) what you find is the values are not inverted.  Although, if I feather the prop for reverse thrust the way I have it, the trailing and leading edge of the blades are reversed.  ...and I like your orientation better for the technical and R/L reasons.  

I wouldn't worry too much about it, just invert your values when you assign the pitch to your preferred hotkey.