Dunbaratu

This is very broken logic because unlike the other parts that use this resource distribution algorithm, jet engines can run partially effectively on partial air. This algorithm only makes sense when a part's resource requirements follow an all or nothing boolean logic, not when they scale across a gradient. When they scale across a gradient this algorithm guarantees uneven distribution any time the resource supply is between 100% and 0% of what is needed. I've found that adding air intakes LOWERS the effective altitude at which I can use jets because of this algorithm. I have to shut them down the moment the air intakes drops to 95% of the needed amount, instead of leaving them on up to about 5-10%. I hope the devs don't classify this behavior as "correct". I hope they understand it's a problem.

That does it. Thanks. I'm not very familiar with many of the new 0.23 tweakables.

Of course, That Mitchell and Webb look addressed this:

Is there any way to force a jet engine to change the normal fuel depletion rules such that it tries to take from the backmost fuel tank first? I think my flipping over problem is happening because the front fuel tanks drain first and this moves the center of mass back as the fuel is used. I tried a yellow fuel hose going from the back tank to the front tank to try to replenish from the back to the font but that makes no difference. It always removes fuel from the front first. With a single engine design I can use the mouse to counter this and transfer fuel during flight with the engine on, but with two engines I cause asymmetry by trying to do that since I can only move one side at a time.

Working around the symmetry bug seems to have made this a lot easier. It's working now and I got it into orbit. I still have no idea how to make intakes go to the correct engines so I can't make high altitude multi-intake setups work, but at least I can get both engines to shut off at once now. I still have the annoying problem that planes flip over on their backs in utterly unrealistic ways but that's a later problem and a seperate topic. (Yes, I know I'm supposed to put the lift a bit behind the center of mass. I build balsa gliders as a hobby. That doesn't seem to be the cause of the flipping.)

That sounds like the problem I'm having. I've just never encountered it before. The strange thing is that even when I tried re-assigning the action group after symmetrizing it still has the problem. I have to delete the jet engines entirely and re-attach new ones (thus clearing off the previous action groups for it) before I can get proper symmetry from its action group. If I just go into action group 1, remove the action, and then re-assign it, with the engines still there, they still lack symmetry in the action groups. Only removing the engine any putting a new one one in its place seems to make it "forget" the buggy data and allow the action groups to have symmetry. Once the game has gotten it in its head that the part's action groups should not be symmetrical, that mistaken notion stays true for that part from then on, even if you try to reassign its action groups after finishing the build. You have to throw that part away and go get a new part from the parts bin to break free from the problem.

Hmm. I just did an experiment and it turns out I only get the "one engine toggle" problem when I build the craft in this order: 1 - Turn off bi-symmetry. 2 - Attach fuel tank to left side of plane (getting only a tank on the left side because symmetry is off) 3 - Attach air intake to fuel tank (getting only a tank on the left side because symmetry is off) 4 - Attach jet engine to fuel tank (getting only a tank on the left side because symmetry is off) 5 - click action group tab. 6 - click jet engine. 7 - assign "toggle engine" to action group 1. 8 - Turn on bi-symmetry. 9 - Detach original fuel tank from left side and reattach it now that symmetry is turned on - causing it to clone the entire tree of parts from there on down and make a copy of it on the right side. That may seem like a weird way to do it but it's sometimes necessary because it won't let you attach parts, thinking there's phantom collisions with other parts, unless you build the entire structure one-sided and then clone it later. If on the other hand I build it in THIS order, it works: 1 - Turn on bi-symmetry. 2 - Attach fuel tank to left side of plane (getting a matching one on the right side too because of symmetry) 3 - Attach air intake to fuel tank (getting a matching one on the right side too because of symmetry) 4 - Attach jet engine to fuel tank (getting a matching one on the right side too because of symmetry) 5 - click action group tab. 6 - click jet engine. 7 - assign "toggle engine" to action group 1. But unfortunately it's not always possible to build it that way because of the "refuse to let you attach parts symmetrically that you CAN attach one at a time" bug.

How on earth do you get them to have air above about 20km? I've tried additional intakes but that is bugged because they don't spread to the engines correctly and only one of the engines gets all the additional air when you do that. Where do you fit the rocket that is needed? At some point you do need one, to lift periapsis after you get to your apopasis. I was trying to put the rocket in as the middle center piece. But the action groups aren't toggling both the two engines in a symmetry group like they should. They're only toggling one of them. This is the solution I was trying but that problem made it not work as a solution.

No you wouldn't. The button would delete debris only when the user is done with the mission and goes in to the tracking center and uses the button. If the user needs that debris around for a while and not delete it until the mission is over, that's an option the user has. Setting zero debris deletes debris instantaneously the moment it gets more than 2.5 km away from the camera, or as soon as the user escapes out to a menu screen. The button would allow the user the time to, say, use the "recover" option on several pieces of the craft first before then going and deleting debris, or leaving that tank in orbit, waiting for the re-ascent and rendezvous first. I set debris to zero for performance concerns once (to see if that was the cause, it wasn't) and then immediately set it up to 25 just to avoid these problems I encountered at zero debris.

With any sort of spaceplane design, you come to a point during the flight where the air thins out to the point where you need to turn off the air-breathing engines and switch to a rocket engine. I have never been able to do this without either spinning uncontrollably at the moment of transition, or leaving the engines off long enough that a large amount of the vessel's momentum is lost to drag during the transition period. If I wait for the engines to flameout on their own in a twin engine plane, they generally don't flameout at exactly the same time as each other, leading to uncontrollable spin from the few seconds of uneven thrust when one engine was on and the other was not. If I hit 'x' to kill the engines first, they take too long to spool down to zero and I lose too much momentum waiting for that. If I try to kill the engines just before the flameout, by watching the air intake's rightclick menu and as it starts getting dangerously close to zero using a pre-assigned action group that I assigned to the "toggle" action on the engines when hitting ALT-1, then only one of the two engines turns off when I do it! Even though the two engines are built with symmetry and are the "same" engine as far as the action group tab is concerned, only the left engine actually toggles off when I use ALT-1. Thus, uncontrolled spin results. It's one of the infuriating things about spaceplanes and it's the reason I never use them despite having over 1000 hours in the game. I think if this was solvable they'd be usable. And clearly it has to be solvable because other people use them. I just don't understand how they're making the two jet engines cutoff at the same time to avoid the spin.

The point is that with no air there's no pressure shockwave. The first damage that spreads out from the explosion and breaks walls and windows is a wave of pressure passing through the medium of air. As the explosion expands and takes up volume, it violently pushes the air away that had previously occupied that volume, and that effect propagates through the air as a sound wave. The biggest, most violent sound wave ever. In a vacuum there's no material to make that wave propagate through so that effect doesn't happen. Instead the explosion expands into the empty volume around it and doesn't have anything it needs to push out of the way to do so. That's why it's a bit less violent in a vacuum. It's still pretty powerful, but not AS powerful as in atmosphere.

Exploding rocket parts does not reduce the debris problem. That's why they don't do it in real life. A thousand little parts is far worse of a problem than one big part. But that has other effects that make it a bad idea. You usually want to allow at least a little debris, otherwise bits of your craft you didn't meant to delete end up being deleted as "debris". I.e. leave a fuel tank in orbit expecting to re-dock with it later. Except that since it was 'debris' it's gone. Or a bit of your craft breaks off landing back on Kerbin, and first you recover science from the main part of the craft, and can't recover the science on the broken off part because it was debris and it's gone the moment you recover the main part (and thus leave focus from the area).

The player-visible feature in that case is called "better looking terrain". Procedural generation is a means to that end, and this thread is about the ends, not the means. But we're requesting the end effects here, not the means to achieve them. You request lower memory footprint as the actual game feature you want. If the devs think procedural generation is a good way to get that that's their decision. The argument about how to achieve the end goal is secondary. When people ask for "64 bit", for example, what they're *really* asking for is "allow more memory so I can run more mods. Also make it have less space-kraken style errors that blow up my stations." and so on.

I didn't forget. I just recognize that the title of the thread is "what do YOU want to see in 0.24" and the "you" in that refers to the players not the developers. Developer tools don't belong in that topic. And as long as players are only allowed to ever see one and only one universe, the means by which that terrain is created is purely a developer-side issue. It belongs in the same category as what revision control system they're using, or their decision to use Unity, or their decision to use C#. These are not game features. They're implementation details.

But my point is that this is a thread about features the user sees in the game, not features the developers see. It make little sense for a player to request a feature that's not relevant to the player experience. The only way the difference between procedural or manual terrain generation is relevant to the player is if the procedural terrain is NOT determinisitcally giving the same answer every time. As long as there is one and only one universe that ever exists in KSP anywhere and it's the same for every player, then the difference between procedural versus manual terrain is relevant only to the game developers, not to the players. In other words, procedural terrain generation isn't really a user-visible game feature unless the devs drop their insistence that everyone must play in an identical universe.

One very important thing is to check this thread back a few pages (I can't remember now how far back and I'm typing on my phone where it's hard to deal with the tiny screen for stuff like that). kOS does NOT WORK with KSP 0.23 if you use the default download link mentioned on the front page of this thread. It's a long story but what matters is that the original author went out of communication entirely and stopped updating and this happened before the KSP 0.23 update so the version mentioned on the front page is for version 0.22 and doesn't work with 0.23. But there is a version for 0.23 that is being updated by another user. Go back a few pages in the thread to try to find the link to it.

The history of the craft (which things it landed on) is stored in its command cores. If you land a lander with, say, 3 command cores on it, on the mun, all 3 of them get the "this was on the mun" flag recorded into them. As long as any of them make it home, it triggers the achievement. So to do an Apollo-style experiment and get proper credit for it, what you have to do is put the smallest command core you have on the experiment pod part of the lander, just as a record keeper that stores the fact that the pod was on the mun. Then when you ascend the lander and re-dock it with the command module to go home, make sure it was designed such that the bit with the command core and experiment pod detaches and stays on the command module while the rest of it can be discarded. Bring home just the experiment pod and the dummy command core that's on it. Ideally, any science instrument in the persistence file should remember that it has been on the Mun. The property 'this has been landed on ......" should attach to the science instrument parts just like it does to the command cores. Story-wise what *should* be giving the extra science points is bringing the experiment back home, not bringing the computer that flew the mission back home. I would like to see that change as a small tweak to future versions of KSP.

That is a false claim. It tracks it based on the command core, not the ship itself. You can leave the majority of the ship behind as long as you take a command core that landed back with you. So the achievement isn't really an accurate measure of what it claims to be anyway.

I'd find it far more useful to be able to say "don't toggle to debris with [ and ]". At the scene of a crash it can be really annoying to try to work out which of the 30 or so things you're toggling between is the right one.

Read my earlier post. I already covered that exact point. I went into quite a bit of detail about the difference between the "in progress" and "is flying" parts of the phrase "flights in progress" and how in some cases (rovers) it's only the "flying" part that's wrong, not the "in progress" part. For flags, both happen to be wrong. For rovers, only one of them is wrong. A proper solution to both *MUST* separate the two into two separate properties, and then only mention the "in progress" property in the summary you see for campaign saves.

In a Venn Diagram, "random terrain" is contained entirely inside "procedural terrain". There is no such thing as non-procedural random terrain. And when you fix the seed in a random procedural algorithm and never allow it to change like I was describing, it stops really being correct to call it random either. It becomes a deterministic procedural algorithm. I'm aware of all that. It's also irrelevant to my comment. You chose to reply as if I was comparing random procedural generation to deterministic procedural generation, which I wasn't. I was pointing out that as long as the outcome is deterministic, regardless of how it got that way, the difference doesn't matter to the player. The only way procedural generation would matter at all to the player is if it IS random or at least allows there to exist alternates or tweaks to cause changes. If you can't, as is the case with the dev's belief that its more fun for there to only ever exist one solar system configuration ever (1), then it's a pointless thing to ask for as a game feature. It's an underlying implementation detail, not an end-user game feature. (1) Which I don't agree with. I think there is an easy compromise between "no shared experience possible because everyone's got their own different universe" and "no variation allowed ever so everyone has the same universe." and that is a moddable solar system generator. That gives more than one possible universe, but still only a few countable ones, as other solar systems would be mods.) If the devs allowed that, THEN the fact that the terrain follows a deterministic procedural algorithm would start to matter to the user community.

Add the "weathervane effect" to areodynamics already. It doesn't need to be the full blown accurate areodynamics model - just that one thing would help get rid of the biggest annoyance - unrealistic flipovers and spinouts. The main reason I don't do much spaceplane stuff in KSP is that I get frustrated with the fact that the chief challenge I face when doing so is a challenge based entirely on a buggy artifact of the simulation. What I mean by the "weathervane effect" is the way that by virtue of the flat panel on its tail, a weather vane always tends to point into the wind. It happens because the wind pushes on the tail when the tail shows its side to the wind, and it has the least resistance when it's aligned with the wind. The reason it's not happening is that drag is being applied to the craft as a summary global whole, rather than being applied to each part and calculating how those forces pull on the craft. If it was applied to each part, the fact that facing the tail into the wind drags the tail more would cause the tail to try to decelerate relative to the rest of the craft's parts, and thus tend to rotate the craft back into a position where the tail is in back. The groundwork for this is all already there, since when the craft is in space the rotations the craft experiences because of applying a force to individual parts is being calculated.

While true, it's not in a way that's meaningful to the player since it generates the same exact terrain every time. A bit like a world in which everyone playing Minecraft had to use the exact same world seed and could never change it. The fact that the terrain is procedurally generated doesn't matter if it's identical each time.

Two problems with this: 1 - An if/else is not a looping mechanism. As a mechanism that can only branch forward (not backward), discussions of algorithm timings sort of don't apply. You need some concept of looping and therefore a count of "how many iterations" of it for that sort of question to be meaningful (to me). 2 - This is the wrong thread anyway. Questions about the language itself rather than about this challenge *using* the language should go in the mod showcase thread for kOS.

True, but my point is that there will inevitably be incompatibilities with exisitng kosscript because of how quirky and weird kOS behaves and some of that quirky behavior you probably won't *want* to emulate as it's actually buggy design. That means people will have to go over their existing code anyway and find out why things changed, and that might make a clean break better. It's a bit like the problem people have who implement WINE. Re-implementing the Windows API to work correctly actually isn't enough to make it compatibile. They also have to make it have the same BUGs and really stupid behaviors as exist in the original, even in places where the original behavior is clearly wrong, to make it really compatible.