Sevio

I had this problem too, the sabres were running both airbreathing and closed cycle modes at the same time, (and producing crazy thrust in the process). I tracked it down to Hotrockets, removing its B9 config file in MP_Nazari solved the problem for me.

Hi Ferram, I noticed your development update to the FAR github and decided to test it out, both with my test plane and the plane that originally had the issue with. Both planes now work entirely as expected (I was able to do the reentry and landing successfully with the spaceplane), so thank you for the fix You probably already know but I figured I'd report it anyway: During a test flight with my spaceplane, I did spot an issue where the FAR in-flight window disappears during flight, couldn't see anything in the log indicating what went wrong though. In any case, happy with the fixed control surfaces, keep up the good work!

Is NEAR support planned for a future update?

I've just downloaded FAR from github master and tested the above plane once more, unfortunately control surfaces are still inverted Curiously, in both versions they're also wrong when you control the plane from the docking port.

Hi Ferram, is there any chance of testing a dev build for a fix with the control surface orientation? In case it may help, I've simplified the steps to produce the bug down to an 11 part plane as shown here: The docking port is the root part facing towards the outside, the rest of the plane is built in reverse, cockpit facing towards the back of the hangar. When it is launched, control starts with the cockpit and the control surfaces start inverted from what they should be.

Ok it's actually fairly simple to reproduce: Start in the SPH with an orange tank, attach a docking port to the back, then build from that docking port a simple plane with canards / elevons and a tailplane, the cockpit should be facing away from the hangar door as should the winglets. Launch, decouple the docking port and you'll get inverted control surfaces.

@ferram4: Thanks for looking into it, if it would help I can try producing a test assembly to try to reproduce the problem on the runway.

The control change may have played a factor but the navball is showing the right orientation. It never showed the wrong one either, I just did "control from here" on the cockpit to make sure. I'm more and more convinced this is a bug related to FAR's handling of the control surfaces, as without FAR they work fine under the same docking & reentry procedure. I've quickloaded and redone the reentry half a dozen times over by now trying different ways of getting the control surfaces to work right. (setting control, going to space center and coming back after undocking, quitting the game and reloading after undocking, etc) From what I could see in the FAR flight data on the previously linked screenshots, it's almost like FAR has the up/down direction of the plane flipped. It's showing negative L/D and Cl. Also there is the glitch where the UI rapidly toggles on and off while the error log is being spammed, which also doesn't happen without FAR. Some additional info about the plane: The fuel tank that I left behind at the station was attached to a surface mounted docking port on the cargo bay, facing backwards and upside down. After undocking that port probably became the root part, maybe this is why FAR interprets control surface input the wrong way? Original description of the problem

I am running .24.2, the spaceplane had a fuel tank in its cargo bay with an upward-facing docking port. I used control from there to dock with the station, then detached the tank from the cargo hold when I wanted to leave. So the docking port I once controlled it from is no longer on the ship on reentry. I've made sure to rightclick the cockpit and choose "control from here" before reentry but it still happens.

Hi ferram, After a long time of sticking with stock's aerodynamics, I've started using FAR in the last few days, after a lot of engineering I've managed to produce a spaceplane that stays stable all the way to orbit, however after docking with a space station and trying to reenter, it will flip out of control below about 40 km no matter what I do. At first I thought it might be because of poor stability with the tanks emptied, then I noticed something odd: all control surface input seems to be inverted when I try to reenter this plane: http://puu.sh/aBDbY/e6292f3371.png http://puu.sh/aBDhJ/454eeb9694.png What's also odd to me is that it's showing a negative L/D and Cl, even though the plane is clearly pitched up in the second picture. I have tried exiting the game and reloading after undocking to see if it would be fixed, but nothing seems to help. Also every time I quickload and undock from the station to deorbit, the UI will start rapidly toggling on and off, which forces me to exit to the space center and come back. When I spawn a new version of the plane, the control surfaces behave as expected, but two different versions of the plane that I sent up both have the same problem when reentering. I have tried to do the deorbit without FAR installed and the control surfaces work fine without it, and there is no ui toggling glitch during the deorbit timewarp. Edit: When the ui glitching happens, the log is spammed with these errors: [Exception]: ArgumentException: Value does not fall within the expected range. Mods in use: Enhanced Navball 1.3.2 FAR 0.14.1.1 Kerbal Alarm Clock 2.7.8.0 Mechjeb 2.3.1.270 Procedural Wings 0.8 Procedural Fairings 3.08 RCS Build Aid 0.4.6 Spaceplane Plus 1.3

Ok, after some digging around and learning a little bit about how PartModules work, it turns out it's already possible to tweak the wing mass, even on a part-by-part basis. Since the mass calculation for the existing pWings is uniform, here's the modulemanager config I used to make them a little bit lighter. @PART[*]:HAS[@MODULE[WingManipulator]] { @MODULE[WingManipulator] { massFudgeNumber = 0.013 // Default: 0.015 } } This reduces the mass of all pWings to ~86.7% of their default mass, stock wing connector and delta wing are now equal in mass compared to a pWing of the same size. Still a bit heavier than the stock swept wing, but you do get a lot of flexibility and scalability for it so I guess that is fair. Another thing you could tweak in the same way is liftFudgeNumber (defaults to 0.0775), but this only affects the lift of the wing without FAR.

Took some decrypting to figure out what you meant by that (Reaching for the Stars), and then scanning to find the latest version of it. While it does have a modulemanager patch for pWings, it has nothing in it that changes the mass. It seems to mod the textures and add "objects" to it, whatever those are.

Do you happen to know which config it is? I scanned through the Realism overhaul configs but couldn't find anything relating to procedural dynamics. From the source file I read, the calculation is completely hardcoded, so maybe the realism overhaul plugin is the one that's doing the tweaking?

Hello DYJ, I've recently started using this mod and am quite liking it so far. After playing around with it a bit, I've unfortunately found an issue and also have a request: The issue is that the mod does not detect the presence of NEAR, causing it to not set the required aerodynamic parameters, so the wing scaling has no effect. I'm using FAR in the meantime for my testing. My request is if you could add some way for us to tweak the mass of the generated wings, the mass calculation seems to be entirely hard coded right now, but the wings seem a bit heavy for their surface area when I compare them with similarly sized stock wings, particularly the stock swept wings really overpower a pWing of similar mass.

For those of you who would like lithium mining to make a little more sense, here is the MM config I used to bring down the time to fill a single canister with a single refinery on Laythe from ~7 hours of real time max timewarp to a matter of a few in-game days. Relative balance of mining speed between Laythe, Kerbin and Eve is unchanged, I just multiplied the abundance by 10000. @OCEANIC_RESOURCE_DEFINITION[EveLithium] { @abundance = 0.00093 } @OCEANIC_RESOURCE_DEFINITION[KerbinLithium] { @abundance = 0.0017 } @OCEANIC_RESOURCE_DEFINITION[LaytheLithium] { @abundance = 0.00237 }

Thanks, I hadn't thought of looking in the OpenResourceSystem dir yet. Going to be tweaking this a bit to make lithium extraction a little more bearable.

@Fractal_UK So after arriving at Laythe and getting a small base established with Extraplanetary Launchpads, I decided it was time to do something about my slowly dwindling fuel supply. I have set up a uranium refinery at a hotspot that seems to be working out quite well, and I've got a science lab and 2 refineries churning away extracting lithium and deuterium from a nearby lake, intending to breed that lithium to tritium. Deuterium extraction seems to be acceptable at 0.94 kg/h but lithium is being extracted at only 753.034 mg/hour. I have to go up to 10000x timewarp to get it to move at all and even then it's being extracted at less than 0.01 units per second. At max timewarp it goes at 0.04 per second. To fill a single tank of lithium with 1 refinery would take 6.9 realtime hours of time warping at max speed. I happen to have the liquid spectrometer on a probe on all the planets with oceans on them, there is no place with a higher concentration of lithium in its oceans. The way things are now, it doesn't seem remotely viable at all to get Lithium from anywhere else than the VAB. Is there anyplace I can increase the concentration of lithium in the oceans or make the refinery extract lithium faster somehow? I couldn't find anything of the sort in the config files in the 0.10.3 release.

I think I may have read the number in the VAB wrong, plus some confusion about where the bred tritium was going. It was going into the deuterium/tritium cryostats so I saw the tritium level in my reactors going down at an alarming rate. Did a bit of testing with my antimatter complex that runs on 2 3.75m Tokamaks and 2 Thorium Aegletes 2's: Tritium inside each reactor: 4.93 Total tritium: 10.20 Total breeding rate (per day): 18.77 After time accelerating for one day: Tritium inside each reactor: 2.22 Total tritium: 15.24 Tritium consumed in one day: 13.73 (6.865 per fusion reactor) Net Tritium gain: 5.04 (Just slightly over 2x the tritium breeding rate of the fission reactors) It looks like the Tokamaks are just barely self-sufficient tritium wise afterall, sorry about the misunderstanding and thanks for the clarification on the neutron economy of tritium breeding

So I've been experimenting with the 3.75m tokamak nuclear reactor, I'm a little bit confused as to why they're tritium-negative when tritium breeding is on. A primary goal for ITER (fusion reactor under construction in France) is to develop a way for fusion reactors to breed more tritium than they consume. The extra tritium produced would also be useful as a margin (restarts, tritium decay) and to kickstart other, future fusion reactors. What's the reasoning behind them being tritium-negative in Interstellar? Some numbers from the mod as it is: The 3.75m tokamak consumes ~13.69 kg of tritium per day when at full power, yet it can breed only 6.88 kg/day. the Aegletes 2 running on thorium (12.4 GW) can breed 2.51 kg/day. This means you need ~3.17 Aegletes 2 reactors running thorium full bore in order to just break even tritium-wise.

@Fractal_UK: Just installed your new update and my fusion-powered shuttle flies straight once again, much thanks! I'm a little unsure how the thermal turbojets are actually consuming the charged power now (perhaps at a lower efficiency), their thrust in LFO mode is still higher than in 0.9.2 but lower than it was in 0.10.1. It looks like with sufficient storage of megajoules the use of a plasma thruster for the burn to orbit is still a valid technique to provide that push into the upper atmosphere. Going low on megajoules indeed triggered the warning message and I was able to throttle back just in time.

Allowing thermal generators and thermal rockets to consume charged particles directly sounds like a great solution, throttling back thermal rockets a little to allow enough room for electricity generation is something one can deal with Do fusion reactors get preferential treatment for consumption of the available power if there is also say, a plasma thruster demanding the maximum amount of available power?

Hi Fractal_UK: Some more testing that may or may not be useful to you: the thrust drop happening with one of the thermal rockets (problem occurs with turbojets too) seems to be due to the way the generators decide to balance the load of keeping the fusion reactors operational amongst themselves, along with the fusion reactors' new capability to scale the amount of chargedpower they produce. One of the generators decides to produce all the power for the 4 reactors while the other generators do nothing, allowing those reactors to scale to full thermal power. I also found another, possibly related problem with the Omega fusion reactors while testing in a slightly different setup. Same probe as in the quoted post, but instead of using 4 direct conversion generators, I decided to use 4 KTEC solid state generators: After running the engines for some time, because the thermal rockets take precedence over generators the stored Megajoules in the generators run out and the fusion reactors shut down. I'm ok with this happening with thermal generators because there is the option of using direct conversion to supply the fusion reactors, but it would be nice if direct conversion generators were able to balance the load between themselves somehow to avoid the asymmetric thrust situation.

Sorry I forgot to mention that, yes the generators are all direct conversion.

Hi Fractal_UK: Thanks for all your hard work with the new update, I can't wait to play with the new reactors and all the other things! Unfortunately I seem to have hit upon a rather severe bug. It's easy to reproduce, create a vessel with probe brain, FL-T800 fuel tank, 2 small deployable radiators and strap 4x symmetry generator/Omega fusion reactor/thermal rocket to the fuel tank. When on the launchpad, after running the engines for a bit and the thermalpower of the reactors has run out, one of the 4 engines drastically loses thrust, creating an uncontrollable spin effect due to the asymmetric thrust. Or it would, if the test ship had enough TWR to lift off. Which brings me to a question, I've noticed the Omega and GEKKO fusion reactors have had their mass significantly increased (from 1.5t to 2t for the Omega), why is that? I don't think that was needed, their TWR even with LFO fuel was nothing to write home about.

I have been hammering at the nuclear-powered SSTO challenge myself, as Fractal said it's been quite the engineering challenge to even design one that can get into orbit. However today I seem to have finally hit a sweet spot. I present to you the Seraph Surface-to-orbit Shuttle: The Seraph without cargo weighs 21.075 tons, can operate in any atmosphere due to being purely fusion-powered and for its test flight carried a cargo of 10.8375 tons into LKO, consisting of a large metal can plus 2.4 tons of useless oxidizer. Other mods used: B9, Modular Fuel Tanks, Extraplanetary Launchpads (heavy metal cargo can), Mechjeb (only for statistics) I used some part clipping to make the thing look somewhat aesthetic. Key elements are: Works in any atmosphere! 4 upgraded fusion reactors with 1.25m direct conversion generators. The middle ones are clipped into their generators to keep engine section from sticking out too far behind. Sabre M intake + 3 supersonic inlets on each side. Although the Sabre Ms are technically attached to the precoolers (the adapter behind it is just there for show), the supersonic inlets mounted radially on the precooler don't seem to benefit from its effect and thus the engines will still show some overheating. Take care not to activate your engines in airbreathing mode when reentering at high speed! Plasma Thruster in the middle to squeeze more thrust out of the fusion reactors after switching away from airbreathing mode mode for the burn to orbit. Both Xenon and Argon are suitable for this stage, go for Xenon if you are worried you won't have enough thrust to get out of the atmosphere quickly. Modular Fuel Tanks: Thanks to MFT, the twin engine mount at the back can contain some monopropellant for docking, plus the LFO needed for the burn to orbit and rendez-vous maneuvers. The middle LFO tank contains either 54 Argon or 4480 Xenon for the plasma thruster, and 480 units of (cargo) oxidizer but could also be used to transport kethane or other fuels. Small 2m cargo bay: It's not very useful for actually deploying space probes due to its small size and the wing above blocking part of the bay. However it has 2 internal attachment points that can be used to attach cargo containers in line with the Center of Mass such as metal cans. The 8t metal can clipping through the craft hasn't been a problem on my multiple test flights. This makes it useful for transporting various resources between surface and orbit. Secondary cockpit has room for 2 passengers Ascent strategy: Climb up to 10 km on the Thermal Turbojets, begin leveling out once engine thrust starts to rise more slowly. At around 12-13 km their thrust will be optimal, so try to squeeze as much speed as possible out of this stage while climbing very slowly to 950-1000 m/s at 20km. Once there thrust will start dropping sharply, so pitch up to about 30 degrees, switch 2 of your engines over to LFO mode and activate the plasma thruster, while the other 2 turbojets continue to squeeze more thrust out of their now doubled intakeatm. Once the remaining airbreathing turbojets' thrust drops below that of your LFO thrusters (you should be at 30 km now), switch them over as well, turn off your intakes and pitch up to 45 degrees for the burn to orbit. Once you break 50 km altitude you can lean down and simply point prograde until you reach your desired Ap. Depending on execution, there should be around 600 - 1200 delta-V left after circularizing at 80km. Some notes on construction: If you're not using Modular Fueltanks, you will probably have to get creative to avoid bringing too much dead weight with you. You'll have to use Xenon for the plasma thruster (the only argon container is far too big and heavy for a spaceplane), or alternatively you can leave out the plasma thruster entirely, replace the 1.25m generators with 62.5 cm ones and add some more LFO, but this will have slightly lower total thrust at the critical burn to orbit stage. If someone would like the .craft file to give it a try, let me know and I'll put it up somewhere for download. I hope this writeup helps some of you out with your interstellar spaceplane efforts! Happy flying!