Kasuha
-
Posts
4,512 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Kasuha
-
-
Yup, I think the braking thing is linked to the landing gear. Looks like they never considered rocket-powered takeoffs when they introduced them.
I ain't saying it's not buggy, I'm just saying there's a reason for it.
Not related to landing gear, it does the same on rover wheels.
Yes it was probably intentional. But at present it is more annoying than useful.
-
Now you're arguing that because jet engines are already broken in every conceivable way,
You just keep changing the topic. I assume it is because you're afraid to admit that I'm right.
I have already proposed a common point we can agree on: turbojets are unrealistic and powerful. I have no problem agreeing on that. Does that make you happier? But this is a game and turbojets work as designed. Turbojets are built to allow players reach space. Can you agree on that? We got over that topic several times already. I am not discussing them.
My argument is that intake spam is not an exploit since you don't get any substantial reward for it.
-
Well yeah I can understand it. It may be easy to refuel orange tank but they don't make airplanes pretty.
-
Minimizing fuel usage and minimizing costs go kind of against each other in this particular case. You either save fuel and lose parts, or save parts and lose fuel. Except if you use jet-powered SSTO because then you save parts and spend negligible fuel. One trip of my lifter with full payload (30 t) costs me about 5,000 funds.
Parts are only deleted in flight when they exceed certain atmospheric pressure. On airless bodies such as Mun, they get deleted when they hit the surface. But it doesn't matter much as you can't recover from any other place but Kerbin.
-
If you're using air-breathing engines, the game defaults to keeping the landing gear brakes on until the engines have finished spooling up. It's intended as a feature; it's to maximise effective runway length.
It might have been intended as such some time ago but it definitely does not depend on spooling jets. You can have the engine all spooled up and brakes will still take 5 seconds to release. Besides, it does the same for rovers which have no engines at all.
-
Both Goodspeed and TAC-FB are good mod solutions, but yeah: stock fuel transfer is horrible. Not just balance, but time. Filling or emptying a craft with a lot of small tanks takes forever.
Speed of transfer depends on size of the destination tank. So if you're emptying small tank to large tank, it's done almost instantly. Even with that, emptying my Liquid Fuel Lifter was a chore. But hey, that was for a challenge and I needed to be as efficient as possible there.
Good reason to use fewer large rather than a lot of small tanks when you're building anything you're planning to refuel.
-
For a totally recoverable lifter stage without using mods you need to bring the stage to the orbit, or at least to suborbital trajectory high enough that you'll be able to circularize the payload and switch back to the lifter before it falls below 23 km altitude.
If the payload is not too massive, it's best done using turbojet engines. Here is my lifter that can take 30 tons of payload to LKO, leave it there and return back to runway for maximum recovery. If the payload is smaller, it can give it a kick on its interplanetary ejection or perhaps transfer it to Mun on free return trajectory, still returning to runway afterwards.
-
To me it works this way:
Pressing B activates brakes temporarily, brakes are on as long as I hold the B key.
Clicking on the brakes symbol right to the altimeter toggles brakes ON and they then stay locked some 5 second after they're released, either clicking on the symbol again, or by pressing and releasing the B key.
I have no idea why is that. I guess it was added as a workaround to some undesired behavior of the toggle some time ago and just stayed there.
-
I believe the Stop button not overlaping with Out/In buttons was intended. My guess is, as soon as the Stop button appeared with the clicked mouse pointer on it, it registered the event as well and stopped the transfer immediately before it even started. Clickable-through UI FTW.
We were promised a new fuel transfer by devs, Maxmaps mentioned it in one of his updates, even exactly in context of distributing fuel from one tank evenly to two. So hopefully we'll get something better over time.
As a workaround, when I expect I'll be distributing fuel by partially filling multiple tanks, I usually put multiple tanks of different sizes to my design. One of each FL-T100, FL-T200, FL-T400 etc, depending on size of the design. That allows me to measure exact portions for the destination tank. Of course I can't distribute remaining fuel from a tank exactly half by half that way. But I can get close to it.
-
My experiment regarding "intake spam".
Here is a "plane" with single turbojet and single RAM intake.
Up to 30 km, its speed and performance was held back by drag
Between 30 and 33 km, it was limited by speed curve
At 33 km it still runs on full throttle it is still producing 18.7 kN of thrust
Above 33 km, intake air limits kicked in (so I had to reduce throttle) together with speed curve
At 54 km on reduced throttle it is still producing 0.1 kN of thrust
It did not definitely flameout below 56 km altitude
When it left atmosphere, it was on orbital trajectory with apoapsis at 150 km and periapsis at 30 km
All in all, it flies at least as well as Scott Manley's "airhogging" design. With single intake. Of course, if you add more intakes today, you can fly on full throttle a bit higher. But that's it. Air just goes away exponentially and more intakes just give you a few meters of altitude at which you still can fly at full throttle.
Adding more intakes is just making things slightly more convenient. You just can't get significantly more from it.
Javascript is disabled. View full album
And just to convince you it works even if it is complete plane (picture taken before return to atmosphere):
-
In my experience, copying the thing you want to save as a subassembly, then saving it causes the fuel lines/struts to get messed up. If you're copying the rocket, try saving it as a subassembly without copying it first. This solved the problem for me.
In other words: do not Alt+click on the part to turn it into a subassembly. Tear it off the ship using normal left click and if you need to put it back, load it from the subassembly you just created.
-
As to the your comments regarding using metal plates, they are not crossfeed capable, so I'm not sure what you are saying.
What I'm saying is that a fuel pipe attached directly to the engine has precedence over any fuel tank that is attached to that engine axially. Your plane would draw the fuel exactly the same way if you removed the plate.
I respectfully must correct your statement that my ship is not a balanced craft.Okay I take my comment partially back, you actually did put the CoM at the right place in SPH, I must have skipped it somehow when I was watching the video for the first time. The only thing is, at least as far as I know, the landing gear still has no mass in flight. So you need to set up your CoM before you place it. That applies to all other massless parts as well.
Of course the SAS module you used can compensate for a lot more inaccuracy.
I am also fairly certain that putting CoL behind CoM has deeper reasons than movement of CoM. My experience is that planes with CoL over CoM are rather unstable even with full fuel. Maybe you compensated for that by putting your wings higher? I'm not sure. What I know, though, is that my balanced plane has CoL great deal behind CoM and it flies great.
Edit: seems to me that planes with CoL over CoM might be unstable in gliding.
-
Center of mass of any part never moves - regardless how much fuel there is in single tank, its CoM will always be in the same point.
Center of mass of a ship with multiple fuel tanks does move according to in which order is fuel drawn from these tanks. This can get complicated when considering all fuel draining rules but for simple case of a stack of tanks, the tank furthest from the engine is usually drawn first so the CoM moves towards the engine.
-
Yes, KSP should allow you to stick 20 command pods on a ship if you want to. But that ship should be substantially outperformed by an equivalent build that ditches the 19 redundant pods.
Ship with 20 command pods can bring 20 copies of the same science measurement.
Ship with 20 engines has better TWR.
Ship with 20 reaction wheels has better torque.
Ship with 20 fuel tanks has greater dv.
Ship with 20 intakes can fly higher.
Each of them outperforms their equivalent with just one copy of the part.
At present, in stock aero, the 20 intake-per-engine plane is better than the 1 intake-per-engine plane.Not substantially. That's my point.
Airhogging is a part of the same general problem.Not really. There's plenty of spaceplane challenges with "no airhogging" in their rules, but none of them prevents usage of jet engines. You're just evading the question.
With basically every other system, having too many of it makes the craft perform worse. There is always a trade-off. If you have too many engines, your delta-v suffers. If you have too much fuel, the rocket wastes more fuel and may not even lift at all. If you have too many wings, the plane is harder to fly. Not so with intakes: if your plane has too many intakes, it just flies better.It still has more mass and drag and most importantly higher part count.
It's neither realistic nor fun.Realistic, it's not. But I disagree with not fun. I have plenty of fun flying planes with current jets.
-
Okay, you don't like how jet engines work in KSP, I get that. But that's a completely different topic. And you still did not explain to me why airhogging as intake spam is bad, or even when it is still fine and when it is already airhogging.
You won't get your plane much above 2200 m/s ground speed regardless how many intakes you use and it's almost irrelevant whether you can do it at 40 km with three intakes or at 45 km with twelve, you're efficiently in orbit in both cases and your total orbital energy is not vastly different.
Actually, intake air distribution among engines was improved by devs in a recent release (was it 0.22?) so now you can do with less intakes what needed much more intakes before. With that change, airhogging is a non-problem to me. You don't need to spam intakes. You don't get any substantial reward if you do.
-
Today I sent a permanent outpost to Duna. When it was well underway, I realized I forgot to put crew into it. So I had to send a chase misson with crew that met the outpost during the transfer.
-
I do not believe allowing the player to stick 10 - 100 air intakes per engine, all over the craft, is the intended outcome.
The game is in general designed to allow you to build your craft any way you please. Want 20 command pods in a ship? Or 20 fuel tanks? 20 engines? Or 20 intakes? You're free to do that. That's what is fun on KSP that the game lets you do all kinds of stupid things with its parts.
I don't understand the fuss around "airhogging". You can build a functional SSTO with one intake per engine. If you use more, the more you use the more comfortable it gets - but above three or four the gain is starting to vanish, you don't really get much more from your plane if you have 10 intakes per engine than if you have three. Honestly, I don't see the problem.
As far as I understand OP's post, I think his definition of airhogging is storing intake air in closed intakes. That IMO counts as exploit. But it's not like it gives you a whole lot of power.
-
I think it's irrelevant if it is ducted fan or propeller, real-life efficiency does not quite translate to the game efficiency, I'm certain it would get about the right thrust to be fun.
-
You can find the Isp value in part description in VAB/SPH. Note that it depends on atmospheric pressure so all engines have two values, one for Kerbin's atmosphere at sea level, the other for vacuum.
-
Electrical propellers would be incredibly cool even if they only provided small thrust (in real life even combustion-driven propellers can't compare to jets, the less propellers powered by solar energy). And sure enough they'd provide solution for all atmospheres.
-
Here's what I found:
http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html
Short answer: it's bezier curves.
-
I think it falls down to how Unity interpolates these settings (AFAIK it's Unity functionality) and I'm quite sure it does not use very high order polynomials. I did not find any info regarding exactly this, but this might be a start:
http://docs.unity3d.com/Manual/EditingCurves.html
I have also tested behavior of the curve behind the end of the graph and the turbojet softly zeroes on zero thrust as you pass 2400 m/s surface velocity so I don't see any bugs in there.
-
Okay, this triggered my curiosity.
What is your interpretation of how these coefficients are used? IMO this converts airspeed (0-2400) to some kind of coefficient in range 0 to 1, perhaps thrust multiplier. And as of my knowledge, it either works or does not have any ill effects.
Are you sure you're not substituting orbital speed for airspeed?
Edit: I made a little experiment and the thrust seems to be following that set of keys nicely.
-
You make it sound like you'd be incapable ...
I would really appreciate if you just accepted the fact that my opinion differs from yours instead of trying to talk me into changing it.
It's a difficult bug to trackIt is not a bug if it works as intended and using it the way it was intended to be used is not an exploit. Unrealistic, simplified implementation is not a bug.
A few examples:
Decouplers stopping in midair are a bug.
Principles on which ladder or Kraken drives are based are not bugs, these quirks were added intentionally to the game but were not meant to be used for propulsion, therefore using them as such counts as exploit.
Jet engines and intakes are not a bug and using them is not an exploit. They were designed and programmed to work this way. Airhogging is a self-imposed vague rule invented by players who consider the way it was implemented too unrealistic. And while I share some of these feelings I am nowhere near ferram's position.
Docking Port Angle Snap
in KSP1 Gameplay Questions and Tutorials
Posted
I don't think multidocks cause any problems but they are not very helpful to align docked parts, you just can't rely on magnetism to align them - the proces ends when first port docks, the rest only dock if they happen to be facing their counterpart after the "new ship" is resolved. You have to work on that alignment anyway.
You can align the two parts either by eye (it is quite possible) or rely on some helping tools such as docking alignment indicator or docking ports that can be turned around when already docked.