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

[Razorfang]

It made the problem not happen as often, but it still occurs on several parts. It seems that the heavier the part, the easier it is to cause.

Is perhaps part of the problem that the mass gets doubly subtracted since Tweakscale changes the area supported as well as change the mass?

Edited May 3, 2016 by Razorfang

[Svm420]

@ferram4

Quick repeat of my posted test scenario and everything works as intended. So it appears your fix was successful. I will continue to monitor for any other abnormalities. Thank you for your time.  Well razorfang was correct it worked until I changed the wing str/mass ratio from 1 to .4. Testing it seem .4 and below triggers it for the wing I tested.

 

Darn long edit

Edited May 3, 2016 by Svm420

[Razorfang]

@Svm420 Try scaling it to 50% or less and see if it reoccurs. It did for me.

[Svm420]

@Razorfang

You were right I was too quick to reply. It seem FAR runs into the issue with allowing scaling of mass after tweakscaling a part. The interaction as you said leads to negative part mass. I am no programmer, but I think it maybe a tweakscale issue to fix at this point, but again I dont know. No matter what other parts is scaled as small as they would go I didn't get negative mass. I hope Pellinor will see this tomorrow and help sort this out. 

Edited May 3, 2016 by Svm420

[MisterFister]

 

1 hour ago, nobodyhasthis2 said:

It is there but does not directly reference your last CKAN contributions. Although the connection is fairly obvious. In short it is the same story but from the point of view of an end user. Looking at a passed FAR problem and how it applies to the whole community. Honestly I thought it was best to not use FAR as a direct example in the larger issue as there plenty evidence about it already. I don't even want to give you the link as you have been through enough.

I, as a user, would be curious to know where this link might be.  You indicated hesitation in posting it here out of respect for @ferram4, perhaps you can PM it to me?  I'm no modder or programmer, but I have worked in logistics and customer flow management, and I can say that "read the first post please" is very little to ask.  I've screwed it up sometimes by "reading" but nevertheless skimming over a detail that I later learned to have been relevant, of course, but that's a less-unacceptable error than simply deciding not to read it.

Another possible solution would be to forcibly put the special-case info right there in the metadata descriptor.  Right now it reads:

FAR replaces KSP's stock part-centered aerodynamics model with one based on real-life physics.

Instead, might it not read:

FAR replaces KSP's stock part-centered aerodynamics model with one based on real-life physics.  ATTENTION!!!  There are KNOWN issues of this mod's installation not being managed correctly!  Please read the OP of the link thread below before posting support issues, and please also know up front that your issue will not be addressed unless you can provide logfiles from both a CKAN install and a manual install with the same symptom.  This has been a particular issue with this one mod.

This is in addition, of course, to changing the embedded metadata link to the actual FAR-for-CKAN support thread (with a link in that thread's OP pointing to this one, of course.)  And, not to be confrontational, but I'm gonna stick up for @ferram4 on this one when I say: no one can convince me that "nobody" at CKAN knows what's involved in getting this accomplished.  I, for one, do not appreciate it when two of my favorite KSP utilities (CKAN and FAR) have creators that are somehow holding a grudge with one another because you know what?  To heck with the nitwit user who doesn't know to read an OP, I get unfairly smooshed in the middle during that fight, and I don't like it.  Let the man some peace in sorting some of the chaff from his tech requests for cryin out loud.  :-\

It's not just this mod, to be entirely clear on this matter.  Every time I visit CKAN, I'm told (either directly or because I see forum posts already discussing my issue) to bring something to a mod author's attention, and at least 65% of the times I've done that I end up going back to the CKAN thread to get either the answer or some other lead to a resolution that wasn't with the mod author.  I say that based on my modding history since 2013 when I started with v0.18 when I was sucked into this wonderfully addictive game by happening across Scott Manley's Reusable Space Program, so I've been modding since before CKAN was a thing and I'm not exactly a slouch, since I was running v1.0.5 on a dual-boot Linux64 system with well over 230 mods installed and active, with a KSC idle screen RAM footprint easily in excess of 7.5GB.

So.

[ferram4]

@Svm420, @Razorfang: The problem is that FAR previously was able to simply set the mass based on the surface area and whatnot.  The problem is that the requirement to switch to ModuleMass (because KSP changes) forces everything to work through mass changes only, rather than setting it directly.  So I need to know the base mass.  Which Tweakscale changes.  Apparently my attempt to work it back by calculating Tweakscale as multiplying mass by scaleFactor^3 didn't work, so I'm not sure what the actual solution is here anymore.

@MisterFister: I think you're being too generous towards him.  There isn't much point in not linking the issue if it's just stuff that has been rehashed before, the only reason to not link it is because it's probably leaning more towards, "blame ferram4 for all the issues" sort of stuff.  A bunch of people involved in CKAN seem to think they're going out of their way to accommodate me when they're really finding ways to avoid fixing the fundamental issues I have with CKAN.  At least that's the gist I got from the few issues I found searching through the github for anything that might fit the bill.

Oh, one of those issues was basically what you are asking for as a change.  It was closed as being outside the scope of what CKAN is supposed to do / to avoid acknowledging CKAN's issues rather than merging it.  The most likely case of it happening is if they decide to go for it after I say this to prove me wrong; which would be nice, but that would require them to be motivated by spite, and I don't think that's the case, I think they just don't care about the problems they cause and have.  But basically, that's probably not gonna happen, because CKAN acknowledging that they have a history of screwing up undermines their argument for why they're useful.

The main reason you're being sent on a wild goose chase is that, 1) CKAN devs and contributors would prefer modders to handle the metadata and present things as if that's the case to convince users that modders support CKAN a lot more than they do, 2) But modders don't tend to handle the metadata, because it's not what we've taken on, leading to, 3) Back and forth before CKAN contributors finally accept that it's their job to handle it. 

[Svm420]

@ferram4

In that case maybe because the tweakscale modules applied to wings uses 2 as the exponent for mass scaling. I think it is assumed since wings are thin the mass would be based on surface area not volume. Would changing the exponent to 2 "fix" this? Maybe your method was over estimating the reduction in mass?

[Razorfang]

@Svm420I think you hit the nail on the head. The control surfaces use free_square scale type, which sets the mass exponent to 2.  I wonder if there's a way to query the mass exponent from TweakScale at runtime?

The MassScale is a public variable, can you just check the value of massScale directly?

Edited May 3, 2016 by Razorfang

[Svm420]

11 minutes ago, Razorfang said:

@Svm420I think you hit the nail on the head. The control surfaces use free_square scale type, which sets the mass exponent to 2.  I wonder if there's a way to query the mass exponent from TweakScale at runtime?

Just needs to switch from factor.absolute.cubic to factor.absolute.quadratic if the rest of the code is right. Well I tried recompiling with that change no difference in triggering it. Better than nothing though.  

Edited May 3, 2016 by Svm420

[nobodyhasthis2]

1 minute ago, ferram4 said:

@MisterFister: I think you're being too generous towards him.  There isn't much point in not linking the issue if it's just stuff that has been rehashed before, the only reason to not link it is because it's probably leaning more towards, "blame ferram4 for all the issues" sort of stuff. 

Nope totally wrong there. I supported you. However that response means I was right to leave you out of it. Good enough reason not to link it right here. Seriously this not worth your time.

16 minutes ago, MisterFister said:

I, as a user, would be curious to know where this link might be.  You indicated hesitation in posting it here out of respect for @ferram4, perhaps you can PM it to me?  I'm no modder or programmer, but I have worked in logistics and customer flow management, and I can say that "read the first post please" is very little to ask.  I've screwed it up sometimes by "reading" but nevertheless skimming over a detail that I later learned to have been relevant, of course, but that's a less-unacceptable error than simply deciding not to read it.

Yes the point is elegantly made but not here. The wound is too deep. The list of problems go way back to 2014. Seriously he has being getting shafted for years. To cut a long story short. This is the wrong thread to talk about CKAN. There is another thread for that. I am saying that out of respect for @ferram4

Ironically we have already discussed this. You have told me your workflow which avoids half the problem. Then offered up a good solution to reinforce it. I am more that happy to send you a PM later on today ok. Although I do realise you have got other stuff going on in RL. So no harm done if you can't respond for now.

[ferram4]

@Svm420: That would raise the question of how it knows which one to use.  The main problem is that I can't access the massScale field easily simply because the ScaleRedist doesn't expose it through the rescale functions.  I could assume that mass only goes with scale^2, but then if that ever changes everything goes to hell.

@nobodyhasthis2: The only issue that I know of on the CKAN github that I'd consider fitting the bill of "supporting" my position is anything related to #1607 or #1610, the former of which is very relevant and that I am aware of already, and #1610 the same but really isn't relevant considering that most CKAN errors with FAR (where I can even figure out what went wrong) seem to be related to distributing the wrong version of dependencies; I doubt that the leaving files behind issue would actually matter because FAR hasn't updated its config files in awhile due to no need to do that, and any issues that will occur won't affect FAR installs, only installs that had FAR and don't anymore.  So that then leads me to the question again of what issue you're actually talking about, since it can't be either of those, because why would you try to hide the issues that I'm already aware of?  Hell, why would you try to keep someone who has a serious problem with CKAN's handling of metadata in the dark about their discussions of that in the first place?

Also... this thread is about FAR.  Normally it sticks to FAR development and support, but discussions about how CKAN affects FAR is on-topic here.

[hoowuth]

I have no arrow on the blue lift ball as the stock version had and I have reinstalled the mod 2 times trying to get it back without progress. Should I bee worried or does that ball have an arrow at all. If it has how do I fix it.

[ThorBeorn]

@hoowuthIt's the other way around. With FAR there shouldn't be a lift vector as the blue ball repesents center of pressure instead of center of lift. If you have a lift vector it could be due to installation error or a part that is not configured for FAR.

[hoowuth]

Just now, ThorBeorn said:

@hoowuthIt's the other way around. With FAR there shouldn't be a lift vector as the blue ball repesents center of pressure instead of center of lift. If you have a lift vector it could be due to installation error or a part that is not configured for FAR.

Oh, ok. So it's kinda a different thing.

Thank you for the help!

[pellinor]

9 hours ago, ferram4 said:

@Svm420: That would raise the question of how it knows which one to use.  The main problem is that I can't access the massScale field easily simply because the ScaleRedist doesn't expose it through the rescale functions.  I could assume that mass only goes with scale^2, but then if that ever changes everything goes to hell.

So much discussion to catch up... Yes, assumptions about the mass exponent are not a good idea since that can be configured in quite complicated ways, and is not the same for all parts. Can't you access public kspFields in another partModule by name, or call its getModuleCost method? If this is not possible (or too slow) I'm fine with exposing that information in some other way.

[Razorfang]

@ferram4 Looking through all the stock wings, they all use quadratic scaling. Though I agree that default assuming this is a recipe for disaster.

@pellinor I think it'd be best for everyone to make a way to return the mass scale since it can be set independent of the scale factor. Any other mods that change the mass values are at risk of this behavior. 

[ferram4]

@pellinor: I have been able to access the MassScale value from the partmodule successfully.  However, when the OnRescale function runs MassScale reports 1.  I can't afford the overhead of constantly checking the MassScale value to see if and when it changes, so at this point the ball's in your court.

[pellinor]

51 minutes ago, ferram4 said:

@pellinor: I have been able to access the MassScale value from the partmodule successfully.  However, when the OnRescale function runs MassScale reports 1.  I can't afford the overhead of constantly checking the MassScale value to see if and when it changes, so at this point the ball's in your court.

I'll fix that. Thanks for your help!

[Gnoyze]

-null-

Edited May 4, 2016 by Gnoyze

[ferram4]

@pellinor: When you've got something worth testing say so and I'll try it out, then if it works we can deploy our fixes.

[uxlapogi]

My derivatives window is blank. what do? :c *sadface

EDIT: -removed screenshot-

disregard, working with latest patch

 

love your mod :3

 

Edited May 4, 2016 by uxlapogi

[SpaceEnthusiast]

I just added this to my more realistic build, and I've noticed when going sideways with a small rocket at 200m/s (horizontal speed), the rocket tears itself apart. I'm just wondering whether that's a bug or I'm just not used to this much realism

Edit: more specifically, my rocket is in vertical position, but I'm going almost entirely sideways. All parts are almost immediately torn from each other.

Edited May 4, 2016 by SpaceEnthusiast

[Kalas_konrad]

5 minutes ago, SpaceEnthusiast said:

I just added this to my more realistic build, and I've noticed when going sideways with a small rocket at 200m/s (horizontal speed), the rocket tears itself apart. I'm just wondering whether that's a bug or I'm just not used to this much realism

Edit: more specifically, my rocket is in vertical position, but I'm going almost entirely sideways. All parts are almost immediately torn from each other.

FAQ on first page

I don't like my rocket coming apart under heavy aerodynamic loads; how can I turn it off?

In the Space Center scene FAR has a debug menu that can be accessed to mess with a large number of the parameters. Under the "cheats" section of the first tab there is an option to disable aerodynamic failure.

[SpaceEnthusiast]

1 hour ago, Kalas_konrad said:

In the Space Center scene FAR has a debug menu that can be accessed to mess with a large number of the parameters. Under the "cheats" section of the first tab there is an option to disable aerodynamic failure.

But that would decrease the realism of my game As long as it happens in real life, I'll have it in my game. Thanks for answering.

[pellinor]

17 hours ago, ferram4 said:

@pellinor: When you've got something worth testing say so and I'll try it out, then if it works we can deploy our fixes.

Now all the configured exponents should be applied before any updaters from other mods are called:
https://github.com/pellinor0/TweakScale/archive/dev.zip