Sevio
-
Posts
30 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Sevio
-
-
Squad mentioned earlier they reworked things so they could know the exact time at which a ship changed SoI, so that warping across a boundary at high speed no longer resulted in your orbit predictions being way off. Being able to do the same for water impacts was probably a nice secondary result of this change.
-
Not sure if it's a bug or I'm dumb, but the SABREs, specifically the SABRE Ms, are burning oxidizer in air-breathing mode. I've got plenty of intake air, and I'm using stacked precoolers. Is this supposed to happen? I know it's pre-release and all, but I figure I'd treat it like a beta tester.
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?
-
@Sevio: The simplest version possible should already be there to play around with; I uploaded it maybe an hour or so ago. If that doesn't work, more extreme measures might be necessary.
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.
-
@Sevio: That's probably something to do with the difference between the transform of the new vessel root part (the docking port) and the part you're controlling from (the cockpit). I'll look into finding a fix. I'll probably just have to run the control orientation code again, no big deal.
The exceptions are due to a bug that I've already fixed for the dev build; that should be out whenever I fix this one.
@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.
-
Sevio, did you try putting another command pod or probe on the ship and selecting "control from here" on it?
Or tried docking and going for reentry without selecting "control from here" on the docking port?
The control change seems to be the issue.
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?
-
Sevio are you running KSP .24.2?
And did you choose control from here on another command module or docking ring? And not choose to control back at the cockpit of the craft?
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.
-
It's not in RO, it's in RftS
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.
-
There is a .cfg file for Realism Overhaul that gives you a "light weight" version of the PWings. There is the normal Pwing then the light versions.
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
} -
OpenResourceSystem\PlanetResourceData\oceanicresourcedefinitions.cfg
OCEANIC_RESOURCE_DEFINITION
{
name = LaytheLithium
guiName = Lithium
celestialBodyName = Laythe
abundance = 0.000000237
}
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.
-
Yes, you're right, the problem is related to how ChargedParticles are converted into ThermalPower when a supply of ChargedParticles isn't needed. I have managed to fix the problem of thrust assymetry by changing the way that conversion happens, the fix basically stops ChargedParticles from being converted into ThermalPower and instead allows generators and thermal rockets to consume ChargedParticles directly if they have need of more power.
The downside of this approach is that there is no preferential treatment of charged particles meaning that the generators can likewise run out of power to maintain the fusion reactions when in charged particle mode.
At least this second problem is much easier to solve, I'm going to add a warning that will alert the user when fusion plasma heating power is getting dangerously low so they can take some action to prevent it (e.g. throttling engines down to 90%).
I have some ideas for better solutions though, so I'm going to test those alongside this approach and see what works best.
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: 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.
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.
-
Just to confirm so I know the conditions fully, the generators are in direct conversion mode, right?
Sorry I forgot to mention that, yes the generators are all direct conversion.
Devnote Tuesday: Experimental Improvements
in KSP1 The Daily Kerbal
Posted
I don't agree that the Round8 was redundant with the Oscar-b. With that logic you might as well remove all FL-T* tanks except the FL-T100, since they're all multiples of it. As well as all Rockomax tanks except the X8. (forgot the exact name, 800 units of LFO)
My small probes with an ant engine get at least a Round8 and an Oscar-b to get a decent amount of delta-v. A small probe with a single Oscar-b is on the low side in delta-v, but an FL-T100 is overkill and looks bad. There definitely needs to be more than one tank option for the 0.675m parts. If you're going to repurpose the Round8 for Xenon because its looks aren't consistent with other LFO tanks, new LFO tanks for the 0.675m diameter are needed.
From a gameplay perspective, if ion drives are to power larger craft than probes, please also consider a larger version of the ion engine along with the needed power generation options to prevent the need to cluster the small ones excessively.