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

[Starman4308]

Hey, I'm wondering if there is anyway I can stop the mod from disabling itself (and therefore, all lift and control surfaces) on 64bit KSP. I've been using it with only minor problems so far, and I used it with FAR in .24, so I doubt you are going to cause me any problems. It would be nice to be able to load all my mods without having to use the lowest quality textures now.

See this thread (Senshi enabled a few mods for x64), or manually delete the x64 check from the source code and recompile (a general solution for any mod you want to run on x64). For some mods, you could just PM the author and ask politely as well.

Just do us all a favor, and don't complain to Ferram about bugs unless you've replicated it in 32-bit.

EDIT: Ferram, would you prefer I not specifically mention Senshi?

Edited November 18, 2014 by Starman4308

[ferram4]

@Din182: No. This is non-negotiable; either remove the lock yourself or find someone else to provide you with it, and then never come here for support. Win64 has gotten a lot more unstable with 0.25, and it's simply not worth dealing with in any form.

@nli2work: Those connection points go past the body, don't they? Okay, I think I see the problem: FAR looks for points within a set distance from the furthest point, that distance partly based on the overall fineness ratio of the object when trying to set up its mesh, this way it can account for numerical errors. For the smaller object, it's including the main fuselage in that "furthest point volume," but for the larger it's being limited to that cylindrical connection on one side.

FAR heuristically calculates the orientation based on how stack nodes are attached to find the "up" vector, then preferring part.up if that can't be resolved effectively.

[Din182]

See this thread (Senshi enabled a few mods for x64), or manually delete the x64 check from the source code and recompile (a general solution for any mod you want to run on x64). For some mods, you could just PM the author and ask politely as well.

Just do us all a favor, and don't complain to Ferram about bugs unless you've replicated it in 32-bit.

Thanks for the heads-up about that. And this is the only mod that I use that goes out of its way to make itself a pain for 64bit users.

Also, do me a favour, and don't be so condescending in your replies. I know that 64bit isn't supported, the ferram doesn't want to bother trying to fix 64bit bugs, yadda yadda. This ain't my first time at the rodeo.

[Din182]

@Din182: No. This is non-negotiable; either remove the lock yourself or find someone else to provide you with it, and then never come here for support. Win64 has gotten a lot more unstable with 0.25, and it's simply not worth dealing with in any form.

@nli2work: Those connection points go past the body, don't they? Okay, I think I see the problem: FAR looks for points within a set distance from the furthest point, that distance partly based on the overall fineness ratio of the object when trying to set up its mesh, this way it can account for numerical errors. For the smaller object, it's including the main fuselage in that "furthest point volume," but for the larger it's being limited to that cylindrical connection on one side.

FAR heuristically calculates the orientation based on how stack nodes are attached to find the "up" vector, then preferring part.up if that can't be resolved effectively.

Wow, rude. Honestly, I don't think I even want to bother with this mod anymore. Have a fine day, gentleman...

[nli2work]

@nli2work: Those connection points go past the body, don't they? Okay, I think I see the problem: FAR looks for points within a set distance from the furthest point, that distance partly based on the overall fineness ratio of the object when trying to set up its mesh, this way it can account for numerical errors. For the smaller object, it's including the main fuselage in that "furthest point volume," but for the larger it's being limited to that cylindrical connection on one side.

yes the stack nodes are slightly inside the volume of the tanks on the Y. so if I understand what yous said correctly... This is something related to the location of the stack nodes? the stack nodes should be where the front/rear most vertices are? or just outside? the smaller tank is not being calculated as a part by itself, but as a part of another piece? the larger tank has the correct drag value?

also re basicDragModel

S = 20              //Surface Area 
...
localUpVector = 0,1,0       //a unit vector defining "up" for this part; 0,1,0 is standard for most stock-compliant parts  
localForwardVector = 1,0,0  //a unti vector defining "forward" for this part; 1,0,0 is standard for most stock-compliant parts

For a non-wing part, a cylinder fuel tank for instance, S is surface area of the entire object? or just the area that deflects airflow (like the large flat area of wings)?

Up and Forward Vectors are in X,Y,Z yes? so a part with the above values, it's localUpVector is Up in VAB; or Foward in SPH? and localForwardVector is toward the launchpad in VAB; Right in SPH? or is this only after Launch, where +X is East, +Y is radial out?

Edited November 18, 2014 by nli2work

[ferram4]

@Din182: I'm sorry if you consider that rude, I was simply telling you how things are. You have your options, take them. But I will not provide support for any issues if you do so, because if you remove the lock, it's now your code, and if you use someone else's download, it's now their code. I'd rather work on code that I can fix rather than magical win64 crashes that make no sense.

@nli2work: No, not the stack nodes. The cylindrical parts of the mesh that stick out slightly from the center of the endpoints of the non-cylidnrical fuselages. The parts of the mesh just outside those 4 red triangle/arrows; that sticks out beyond the rest of the fuselage, right? If so, that is the problem.

The vectors are overrides for the coordinate space used by the drag model; if it takes it straight from the part, then "up" is the y axis and then "forward" is X axis, where "up" is what we consider up in the VAB / out the door in the SPH and forward is to the left in the VAB / down in the SPH. It's purely part-space.

[blowfish]

Wow, rude. Honestly, I don't think I even want to bother with this mod anymore. Have a fine day, gentleman...

No need for such hostility. You can find x64 enabled versions around, but ferram's dropping of x64 support is justified. The Win64 version of KSP will basically crash if you glance at it the wrong way, and that's with no mods. Many modders (including ferram) were getting flooded with support requests for which they had no solution because problem was with KSP itself and not with the mods. And the instability got worse in 0.25. So for now either use x86 (recommended) or get one of the unofficial x64 versions with the understanding that you won't be able to get any support for crashes.

[nli2work]

@nli2work: No, not the stack nodes. The cylindrical parts of the mesh that stick out slightly from the center of the endpoints of the non-cylidnrical fuselages. The parts of the mesh just outside those 4 red triangle/arrows; that sticks out beyond the rest of the fuselage, right? If so, that is the problem.

The vectors are overrides for the coordinate space used by the drag model; if it takes it straight from the part, then "up" is the y axis and then "forward" is X axis, where "up" is what we consider up in the VAB / out the door in the SPH and forward is to the left in the VAB / down in the SPH. It's purely part-space.

Ah okay, I think I'm starting to understand it now. the mesh that stick out are seen as flat discs against the forward direction and so generate extra drag. Adjusted the mesh, problem solved.

one last thing regarding basic drag model... Surface Area is the area of entire part? or just the portion that faces airflow?

Thanks very much!

Edited November 18, 2014 by nli2work

[ferram4]

Surface area is, by default, the total surface area - any area that can be accounted for by the stack nodes. So that would be (for your parts) the outer, intended-to-be-exposed part of the mesh, while the ends where stuff is attached shouldn't count; that will be addressed by the attach nodes.

[nli2work]

Surface area is, by default, the total surface area - any area that can be accounted for by the stack nodes. So that would be (for your parts) the outer, intended-to-be-exposed part of the mesh, while the ends where stuff is attached shouldn't count; that will be addressed by the attach nodes.

Okay I see. thanks! I got a little optimization work to do.

[buljcron]

As I stated when you brought it up a few pages ago, you need to provide a full output_log.txt and reproduction steps.

adding "LC_ALL=C %command%_64"to steam launch option some how fixed to me...thanks for helping

[Mouhand]

edited

Edited September 25, 2022 by Mouhand
edited

[praise the suuun]

since structural failure has been added to FAR, what will be my maximum speed? ive noticed if i have too much acceleration at a transonic speed itll shear but if i reduce acceleration (throttle) i can make it to mach 3.5, at 18km, with the lowered throttle same. maybe if i reduce throttle again can i increase speed without failure?

[praise the suuun]

.

well done. you got another subscriber. i hope to see more custom designs!

Edited November 19, 2014 by praise the suuun

[Master Tao]

It's not a maximum speed – it's how much aerodynamic pressure you put where. Pressure increases with velocity and density, and location varies with how you're flying the plane.

Short version: maneuver gently while traveling at high speeds in thick atmospheres.

Long version: use the spiffy new Aero Viz button: Cl and Cd show lift and drag, respectively. Both of those correspond to pressure, so they can give you a better idea of how aerodynamic forces move as you maneuver.

Remember: you can now reinforce or weaken the wings by tweaking them in the SPH.

Edited November 19, 2014 by Master Tao
forces/pressure

[Wanderfound]

since structural failure has been added to FAR, what will be my maximum speed? ive noticed if i have too much acceleration at a transonic speed itll shear but if i reduce acceleration (throttle) i can make it to mach 3.5, at 18km, with the lowered throttle same. maybe if i reduce throttle again can i increase speed without failure?

It depends on both your piloting and your aircraft design. Something built specifically for low altitude speed can tolerate fairly extreme forces:

And at high altitude, even a comparatively fragile craft can manage much higher speeds:

As a general guideline, try to stay below hypersonic speeds (i.e., < Mach 5) until you're above 25,000m, and be gentle with your control inputs if you're low and fast enough to be generating atmospheric effects.

[westamastaflash]

I have a question. I built a rocket similar to Falcon 9 on Kerbal 6.4x Kerbin. When I launch with a light payload, when I reach about 400m/s at about 5000 feet, radial parts break off from my lander (which is *inside* a procedural fairing). Is this expected behavior? Is there anything I can do to stop it? I can provide a craft file but I've got so many mods it might not be useful (realfuels, kw, procedural parts, proc fairings, etc)...

[ferram4]

Expected, but due to a bug. Get the dev version from the github repo, I'm finishing up a fix for that.

[westamastaflash]

Expected, but due to a bug. Get the dev version from the github repo, I'm finishing up a fix for that.

Great, thanks!

[Zidane]

I have a suggestion.

When building a plane one has to calculate the stability variables for the various circumstances the place is expected to be in. One manually varies the air density, temperature and mach parameters to get an idea of how stable the plane is, plus the spoilers and the flaps. My suggestion is making a tab with the various circumstances the place is expected to be in so you can select the ones you want and it will auto set the parameters.

For instance you select planet Kerbin and you get a list of options:

- Takeoff - Mach .35, flaps level 2, 20º and ASL air density.

- Low altitude flight - (...)

- High altitude flight - (...)

- Reentry - (...)

- On final approach - (...)

- Takeoff in the poles (?)

Idk you get the gist. Hope you find this useful.

[ferram4]

The next version will have the parameters set using a dropdown for planet, along with altitude as inputs. Setting the flight configuration and deciding the flight conditions is still up to you. After all, I can't actually expect what circumstances your plane will be in; you're the designer, you'll have to make those calls. So it'll be easier to select conditions that make sense, but it's still going to leave you to decide whether it's sane to reach 15 km at 300 m/s.

[Oddible]

Need some help with FAR, just trying it for the first time. Are there good resources to help get a sense of what to look at and how to build to minimize issues? I got over my penchant for building rockets with giant bulbs on top rather quickly. Currently however I'm struggling with re-entry. Pods are coming in just fine but when I try to get anything more complex to the surface I'm running into a lot of stability issues. For instance, trying to land a pod with a science jr attached to it. It always flips over and goes pod first, tossing a chute from the top of the pod or even sides of the science jr rips my craft apart. How can I make my re-entry more stable with FAR?

[tetryds]

Need some help with FAR, just trying it for the first time. Are there good resources to help get a sense of what to look at and how to build to minimize issues? I got over my penchant for building rockets with giant bulbs on top rather quickly. Currently however I'm struggling with re-entry. Pods are coming in just fine but when I try to get anything more complex to the surface I'm running into a lot of stability issues. For instance, trying to land a pod with a science jr attached to it. It always flips over and goes pod first, tossing a chute from the top of the pod or even sides of the science jr rips my craft apart. How can I make my re-entry more stable with FAR?

Well, that is a very common issue, what I recommend you do to is make sure your COL marker is always under/behind your COM.

You can easily fix this by adding small wings to the bottom of the stage.

You may also want to check what happens to your COM as you consume fuel so it doesn't become unstable midflight, mainly for airplanes.

For reentry it's the opposite, since you comme bottom first you will want your COL to be above your COM for that stage.

Just try to have more weight on the bottom of your craft and it should work better.

Also, wait for longer until you deploy your parachutes, break for longer using the atmosphere.

If there is not enough time to break more with the atmosphere then try to reentry on a less steep angle.

These are the very basics, with this you will be able to figure out a lot of stuff by yourself.

[Dr. Death]

Is there any chance that we get 64 bits compatibility again? i use several parts mod and i just cant use 32 bits, with the loading times of KSP and the crashes that the 32 bits version gives me i am always forced to use 64 bits.

[blowfish]

Is there any chance that we get 64 bits compatibility again? i use several parts mod and i just cant use 32 bits, with the loading times of KSP and the crashes that the 32 bits version gives me i am always forced to use 64 bits.

I can tell you right now the answer is no, but you can find 64-bit enabled builds here. Of course, don't expect any support if when you get 64-bit related crashes.

But a more reliable solution to the memory limits of 32 bit would either to use Active Texture Management or DDS Loader and convert all your textures to DDS. The DDSLoader approach has the added bonus of significantly cutting down loading times.