[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[lordcirth]

2 hours ago, GBry said:

Is it possible to add limits to a control surface, for example to make spoilerons so that it can go between 0 and +45, so that it doesn't go under the wing? Sorta infernal robotic's controls...

Just Shift-rotate it upwards, then set the limits so that max downwards is level.

[Darael]

9 minutes ago, lordcirth said:

Just Shift-rotate it upwards, then set the limits so that max downwards is level.

That works so long as one always wants the no-control-input position to be at the midpoint of the surface's travel.  I can't immediately see a way to produce a surface that's level without any control inputs, and only moves one way - it would probably be necessary to clone-and-patch the part and use the result.

[GBry]

35 minutes ago, Darael said:

That works so long as one always wants the no-control-input position to be at the midpoint of the surface's travel.  I can't immediately see a way to produce a surface that's level without any control inputs, and only moves one way - it would probably be necessary to clone-and-patch the part and use the result.

it would require ferram to put two sliders or toggle "limit from negative" or something

[tetryds]

@Darael have you tried enabling flaps on it so that the flap deflection makes it exactly level?

Edited November 20, 2016 by tetryds

[Darael]

1 minute ago, tetryds said:

@Darael have you tried enabling flaps on it so that the flap deflection makes it exactly level?

That... might actually work, yeah.

[GBry]

5 minutes ago, tetryds said:

@Darael have you tried enabling flaps on it so that the flap deflection makes it exactly level?

right. suppose that works too. but flaps' speed is too slow

[Darael]

Just now, GBry said:

right. suppose that works too. but flaps' speed is too slow

I think the idea is to place the part at an angle, then abuse the flap feature using a negative flap-deflection so that when the specific control surface is in the correct flap-state its rest position is level with the wing.  The maximum total deflection won't let it go below there, but it should still respond to control inputs that would move it upward.

[GBry]

21 minutes ago, Darael said:

I think the idea is to place the part at an angle, then abuse the flap feature using a negative flap-deflection so that when the specific control surface is in the correct flap-state its rest position is level with the wing.  The maximum total deflection won't let it go below there, but it should still respond to control inputs that would move it upward.

I'll try the next time I open KSP.

[kcs123]

I usualy set control surfaces for flaps to be "flaps only" - give it properties that actualy is flap, choose flap deflection, but also pitch/yaw/roll to zero, so it does not move from pilot direct input. Level of flap deflection in flight is set trough action groups.

For pitch control it is better to use surfaces on tail than same one as flaps. I used stock bug fixes from Claw in past, so I no longer recall what flap feature comes from FAR and what was addition from stock bug fixes.

[GBry]

8 hours ago, kcs123 said:

I usualy set control surfaces for flaps to be "flaps only" - give it properties that actualy is flap, choose flap deflection, but also pitch/yaw/roll to zero, so it does not move from pilot direct input. Level of flap deflection in flight is set trough action groups.

For pitch control it is better to use surfaces on tail than same one as flaps. I used stock bug fixes from Claw in past, so I no longer recall what flap feature comes from FAR and what was addition from stock bug fixes.

No, no. Guys. I want the control surfaces to be SPOILERONS. Like the spoilers on commercial aircraft, which doubles as a positive aileron. It can't go negative, because there's the flap subsystem and a bit of the wing spar underneath. For flaps I use IR.

[Darael]

13 hours ago, GBry said:

No, no. Guys. I want the control surfaces to be SPOILERONS. Like the spoilers on commercial aircraft, which doubles as a positive aileron. It can't go negative, because there's the flap subsystem and a bit of the wing spar underneath. For flaps I use IR.

Right, which is why I interpreted the first suggestion to mean what would essentially be abusing the flap settings.  The idea is that while the parts to be used as spoilerons would have their flap settings enabled and their flap-level set such that they stay at maximum negative deflection, they'd be excluded from any flap-control action groups so that they stay there, and don't change with the flap-settings.  They're not used as flaps, they just exploit that group of settings.

The problem is that, under FAR, a single control surface can be set as a flap or as a spoiler, but not both - so to avoid choosing between using them as positive-only ailerons and as spoilers (or doubling up, clipping dupes into each other and using one set as each?  That might work but feels wrong) it'll be necessary to add mod-parts.  Or work with spoilers that aren't automatically in the brake action-group, &c &c &c.

Edited November 21, 2016 by Darael
clarificatiomajigs

[kcs123]

This picture is from KSP 1.0.5. I deleted recently KSP 1.1.x installs, so I no longer can check, but I belive it is this what you have asked for:

Control surface defined as spoiler and positive deflection - it deflect up. On this crafti it is also used as elevator along with ones from tail, therefore it have pitch control to 100%, but it is not always recommanded such combo. I opened stability derivates with spoilers deployed so it can show behaviour in flight.
Spoiler is also tied with brakes, it is always 100% or nothing, while for flaps you can choose 3 different steps of deflection in flight.

Spoiler

Please, note separate values for deflection when used for picth control and different values for spoiler / flap. It is also possible to have negative deflection on spoiler as you can see on another picture, although as I said, I no longer recall is that feature from FAR or stock bug fixes mod from Claw.

Spoiler

[GBry]

4 hours ago, Darael said:

Right, which is why I interpreted the first suggestion to mean what would essentially be abusing the flap settings.  The idea is that while the parts to be used as spoilerons would have their flap settings enabled and their flap-level set such that they stay at maximum negative deflection, they'd be excluded from any flap-control action groups so that they stay there, and don't change with the flap-settings.  They're not used as flaps, they just exploit that group of settings.

The problem is that, under FAR, a single control surface can be set as a flap or as a spoiler, but not both - so to avoid choosing between using them as positive-only ailerons and as spoilers (or doubling up, clipping dupes into each other and using one set as each?  That might work but feels wrong) it'll be necessary to add mod-parts.  Or work with spoilers that aren't automatically in the brake action-group, &c &c &c.

Feels wrong, lol

1 hour ago, kcs123 said:

This picture is from KSP 1.0.5. I deleted recently KSP 1.1.x installs, so I no longer can check, but I belive it is this what you have asked for:

Control surface defined as spoiler and positive deflection - it deflect up. On this crafti it is also used as elevator along with ones from tail, therefore it have pitch control to 100%, but it is not always recommanded such combo. I opened stability derivates with spoilers deployed so it can show behaviour in flight.
Spoiler is also tied with brakes, it is always 100% or nothing, while for flaps you can choose 3 different steps of deflection in flight.

  Hide contents

Please, note separate values for deflection when used for picth control and different values for spoiler / flap. It is also possible to have negative deflection on spoiler as you can see on another picture, although as I said, I no longer recall is that feature from FAR or stock bug fixes mod from Claw.

  Hide contents

No it's not about getting the spoilers to a negative deflection, it's about PREVENTING the things from going to negative deflection. I believe what Darael has told me is the one most achievable in this case.

[kcs123]

7 minutes ago, GBry said:

it's about PREVENTING the things from going to negative deflection. I believe what Darael has told me is the one most achievable in this case.

Then it is just about not using control surface for pitch pilot input. With shown settings on picture above, all you need to do is to set pitch slider to "0" for pilot control, put spoiler to active and flap to inactive. Give it desired deflection and that's it.

For elevation control, you should use other control surfaces, not same one that is used for spoiler.
All other things is, like Darael said is just abusing FAR. It is either, some nasty part cliping or other mods involved.

[Darael]

8 minutes ago, kcs123 said:

Then it is just about not using control surface for pitch pilot input. With shown settings on picture above, all you need to do is to set pitch slider to "0" for pilot control, put spoiler to active and flap to inactive. Give it desired deflection and that's it.

For elevation control, you should use other control surfaces, not same one that is used for spoiler.
All other things is, like Darael said is just abusing FAR. It is either, some nasty part cliping or other mods involved.

It's not that, either.

It's about being able to mount a control surface in the middle of the wing rather than on the edge.  Such a surface (assuming it's atop the wing, rather than beneath) should be able to deflect up, either for use symmetrically as a spoiler or differentially as an aileron, but it should not be able to deflect down because that would involve clipping through the wing.

FAR does not provide a way to do this "properly"; I've checked the code and there's no way to set maximum deflection distinctly from minimum deflection, which I'm pretty sure is what would be needed to achieve this even with a ModuleManager patch.  At least using ModuleControlSurface and FARControllableSurface - there might be something doable by working off the airbrake part instead of a control-surface one?  Failing that, the only options I can see are abusing the features FAR does provide, as discussed, or finding or creating a secondary mod.

Edited November 21, 2016 by Darael

[GBry]

6 minutes ago, Darael said:

It's not that, either.

It's about being able to mount a control surface in the middle of the wing rather than on the edge.  Such a surface (assuming it's atop the wing, rather than beneath) should be able to deflect up, either for use symmetrically as a spoiler or differentially as an aileron, but it should not be able to deflect down because that would involve clipping through the wing.

FAR does not provide a way to do this "properly"; I've checked the code and there's no way to set maximum deflection distinctly from minimum deflection, which I'm pretty sure is what would be needed to achieve this even with a ModuleManager patch.  At least using ModuleControlSurface and FARControllableSurface - there might be something doable by working off the airbrake part instead of a control-surface one?  Failing that, the only options I can see are abusing the features FAR does provide, as discussed, or finding or creating a secondary mod.

Yes, this makes sense. Stock airbrakes can be used as control surfaces too. I think b9 procedural wings' author should make one part exactly to do this also. Also, with mounting in the middle of the wing, I used a workaround : mounted on the edge, then add another thin "wing" behind it so that it looks like it's in the middle.

[Lan_Morehell]

Hi!

 

Could please anybody tell how to install the test version of FAR on 1.2.1? I have tried to download the "KSP_update" branch as ZIP and then copy "Game data" to "Game data" No signs of FAR in the game....

[Darael]

32 minutes ago, Lan_Morehell said:

Hi!

 

Could please anybody tell how to install the test version of FAR on 1.2.1? I have tried to download the "KSP_update" branch as ZIP and then copy "Game data" to "Game data" No signs of FAR in the game....

Forgive my bluntness, please, but since this is not an officially-announced FAR release or beta, if thou dostn't know what th'art doing thou probably shouldstn't be using it.  It's not ready - which is to say, it was known not to be release-ready more recently than the last commit on that branch.  If Ferram wants more testers, we'll hear about it.

That being said, copying the contents of the repository's GameData folder (specifically, the FerramAerospaceResearch folder therein) to the game's GameData folder is the usual procedure.  Probably best, if working with this dev-branch, to delete any such folder that already exists.  Do watch out for the possibility of accidentally ending up with a "GameData/GameData/FerramAerospaceResearch" folder.

[whale_2]

1 hour ago, Lan_Morehell said:

Hi!

 

Could please anybody tell how to install the test version of FAR on 1.2.1? I have tried to download the "KSP_update" branch as ZIP and then copy "Game data" to "Game data" No signs of FAR in the game....

Do you have Modular Flight Integrator for 1.2? 

[Akira_R]

1 hour ago, Lan_Morehell said:

Hi!

 

Could please anybody tell how to install the test version of FAR on 1.2.1? I have tried to download the "KSP_update" branch as ZIP and then copy "Game data" to "Game data" No signs of FAR in the game....

I have to agree with @Darael on this one, I mean no offense or anything but as this is an underdevelopment dev branch not intended for use by the general public if you are having problems figuring out how to install it then you probably shouldn't be messing with it.... But make sure you have the FAR folder and a copy of Modular Flight Integrator in your Game Data folder.

[DoctorDavinci]

1 hour ago, Lan_Morehell said:

Hi!

 

Could please anybody tell how to install the test version of FAR on 1.2.1? I have tried to download the "KSP_update" branch as ZIP and then copy "Game data" to "Game data" No signs of FAR in the game....

 

On Wednesday, November 16, 2016 at 6:57 PM, ferram4 said:

@MaxRebo and @ss8913, you are both absolutely terrible at reading. I appreciate the effort, but take it to github where I can track things, not here where you end up burying @tetryds' relevant post.

Also, since it seems necessary, I fully endorse all of tetryds' post, as well as @DoctorDavinci's.  Follow their example, let's not have a repeat of the leadup to FAR for 1.0.

 

On Tuesday, November 15, 2016 at 2:29 PM, tetryds said:

If nothing has been announced in the thread it makes sense that it should only be used by people with deeper knowledge about the KSP code and coding itself, who can report nasty bugs and help improving it.

As always, the best practice is that you should not be using it if you don't already know how to do so.

IMO it's also a disservice for the mod development to help other people do that.

It's important to mention that since a development version was not even mentioned you should expect absolutely no support from it, only report issues that you have tested and confirmed and report them on github, never here.

Otherwise people will think there is a version they can use to play and everything turns into chaos

 

On Wednesday, November 16, 2016 at 2:35 PM, DoctorDavinci said:

You do realize that there is no new version of FAR yet ... What you are reporting on is a development build that has not been finished

Referring to it as the 'new' version is misleading and could incite people to flood this thread with requests for a download link for the new version when there is no new version

 

[Jiraiyah]

18 minutes ago, DoctorDavinci said:

 

 

 

 

I agree with all the statements, people need to learn that, when there is a branch on github, it does not mean the code is finished and ready to test, chances are that the developer started coding something and for some reason (maybe busy life) he had to stop mid way throw the coding and that branch is not functional at all. there can be cases that the code would not even throw a warning or error for you to know that this is not a ready product, it could simply stop functioning and you would never know.

the reason for developers to have branches other than main on source control repositories is exactly the same thing. they can work on the code, change stuff around as much as they want and if something terrible happened they can easily switch the project to main branch and it would look like nothing ever happened and they could work from day one again and again until the day comes that the branch code proves itself ready for test, that is when the developer would ask few people or sometimes public to give that branch a go and report bugs. when the result show that the code is ready for final release, that is when the developer would merge this branch with the main branch and effectively it would become the new main branch.

long story short, when you are looking at a branch in repository other than the main branch, you never know if the code is working, if there is a nasty bug there, or what. Yah you can go through all the commit messages and try to figure things out, but, that works if the developer put time and effort in explaining the whole commit to the detail, 99% of the times, when developers push the commit to the repositories, they give only single line of comment so that they know what was going on themselves.

So if you ask me or any other experienced coder around the net, they would tell you to avoid branches unless you are experienced coder and are looking into branch "just to follow the process of coding and learn from it!"

Edited November 23, 2016 by Jiraiyah

[Yaar Podshipnik]

All true, unless you develop in main/master and do releases from branches

[tetryds]

1 hour ago, Yaar Podshipnik said:

All true, unless you develop in main/master and do releases from branches

In which case you wouldn't download them from the branches but from the releases themselves, which FAR always issues.

I don't think there is much gain in discussing this further, it has been proven so many times that it's a bad idea to get into stuff like this hoping for everything to work, let alone ask for support.

I would myself delay a release if this happened to one of my mods simply because I would get away from it as this kind of thing would stress me out a lot.

[FunnelVortex]

I am starting to think someone should just lock this thread until @ferram4 posts an update.