Jump to content

Devnote Tuesday: An Overdue Break


SQUAD

Recommended Posts

On 3/8/2016 at 0:54 AM, SQUAD said:

While the experimental testers are carefully documenting the first batch of bugs development

Why are they documenting the development of bugs...? :P

 

On 3/9/2016 at 3:56 AM, Claw said:

And because of that, flight controls can now radially deploy when attached in radial symmetry, and will mirror deploy when attached mirrored.

Is there any possibility to make this a per-part tweakable instead? While I can see it resolving some frequent use cases, it then creates the exact same problem for others that now work as is.

I've had to give up disgusted several times of using a certain design because no matter how I use symmetry or 'deploy reversion', in-flight the game would stubbornly use exactly the wrong direction of deflection no matter what for one or more of the control surfaces, ruining the flight model. I really want to be able to force this myself, per control surface if need be, so I am not left at the mercy of algorithmic assumptions that one way or another seem to pick exactly wrong in 3+ symmetry situations.

 

Link to comment
Share on other sites

1 hour ago, swjr-swis said:

Is there any possibility to make this a per-part tweakable instead? While I can see it resolving some frequent use cases, it then creates the exact same problem for others that now work as is.

I've had to give up disgusted several times of using a certain design because no matter how I use symmetry or 'deploy reversion', in-flight the game would stubbornly use exactly the wrong direction of deflection no matter what for one or more of the control surfaces, ruining the flight model. I really want to be able to force this myself, per control surface if need be, so I am not left at the mercy of algorithmic assumptions that one way or another seem to pick exactly wrong in 3+ symmetry situations.

 

Sure, just manually place the parts instead of using radial symmetry.

This only applies when placing parts with symmetry, so place them one by one and you can set them however you want.

Link to comment
Share on other sites

52 minutes ago, Terwin said:

Sure, just manually place the parts instead of using radial symmetry.

This only applies when placing parts with symmetry, so place them one by one and you can set them however you want.

Or in mirror symmetry, which is how almost all players place their wings and tails anyway so your control surfaces will deflect as you'd expect when using them as flaps or spoilers.

Remember this has no effect on rudders, ailerons or elevators for normal control, the only thing it changes is the behaviour when deploying the part as a flap.

This change makes a (crude) stock helicopter collective possible, it enables spin stability for missiles that isn't active all the time and messing up your planes flight path, and I'm sure there are other things inventive players can do with it.

Link to comment
Share on other sites

22 hours ago, Ruedii said:

It seriously breaks my early career stage craft designs that rely on pitching up heavily on reentry using flaps.

I hear what you are saying, and what I'm trying to say is that this ability isn't taken away. The only difference is in how you tell KSP which way the control surfaces should deploy.

For example, in 1.0.5, I believe this is what you desire to happen (I'm using the SPH for pictures because it's easier to see, but the same applies to the VAB):

8l8cxz2.png

In this case, deploying the flight controls causes them all to give a pitch up command. What's not apparent in this setup is that the behavior isn't always consistent. What I want to point out is that this design is still 100% possible with the new setup...the difference is in how the controls need to be attached. Instead of 4x radial symmetry, you place 2 sets of 2x mirror symmetry (annotated by a set of green and a set of blue winglets). Both sets will mirror deploy and give pure pitch only input.

 

But the underlying thing that's now fixed is the scenario below (another picture from 1.0.5).

UhijV0m.png

In this case of 4x symmetry, the fins on top/bottom are causing yaw input and no pitch input. To get only pitch in 1.0.5, the top and bottom fin would still need to be attached separately already, so that the "deploy" actions can be independently assigned. Even worse is that, in some situations, the top and bottom fin flip their deploy direction based on CoM "wiggle" during flight. They might not deploy in the same direction indicated by the editor, and they may even constantly flip back and forth regardless of if that pair was attached and deployed separately. This behavior should be resolved with the new system.

 

Another scenario is the 3x fin setup, where one fin is deploying in yaw and the other two in pitch (which was alluded to in another post). Again, the top fin's deployment isn't always consistent.

ohlJzZP.png

 

Also, because of the current "pitch only" behavior, anything attached off axis from the rocket body will behave inconsistently. This can be seen below where half the controls are trailing edge down (marked green), and the other half are trailing edge up (marked red). This might seem like an extreme example, but illustrates the issue of inconsistency with KSP's current assumptions.

hedSofM.jpg

 

Another pitfall is that using the same logic as the flight controls (as someone suggested) doesn't work very well for deploying flight controls. Why? Because unlike pressing a key corresponding to yaw, pitch or roll...if the user selects "deploy," KSP doesn't know if that means deploy in yaw, deploy in pitch, or deploy in roll. So it tries to deploy in pitch, but doesn't always give pitch only input (and sometimes gives a backward pitch input from what's indicated in the editor). Even if it did give pitch only input, that creates some limitations in the deploy option's flexibility. Even attaching single controls in this situation doesn't always guarantee they will deploy the direction you intended.
 

So the real intent of the change was to make deployment more consistent and predictable for the general case (i.e. remove the inconsistent behavior). However, I do recognize that the change forces the user to build differently for the 4x symmetric example above (placing 2 - 2x mirror symmetry instead of 1 - 4x radial symmetry)...but the end result is hopefully a more complex (but consistent) set of tools and behavior.

 

Link to comment
Share on other sites

  • 2 weeks later...
36 minutes ago, Yakuzi said:

Devnote Tuesday hype anyone? :P

Lol, I saw the new post in devnotes and did not even realize that I was reading an old post till I was halfway through and it dawned on me I had read it before.

Link to comment
Share on other sites

2 minutes ago, Jarin said:

I swear, some people. So rude.

You have commited crimes against Kerbin and her people. What say you in your defense?

Link to comment
Share on other sites

8 minutes ago, Flapp said:

You have commited crimes against Kerbin and her people. What say you in your defense?

Your honor, I plead mental instability.

Seriously, I hang out around here, I figure that went without saying. :P

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...