pellinor

It's probably not what you would like to hear. I'm suggesting to first do the challenge, with separate leaderboards as usual. The results of the challenge will give you a quantitative comparison of certain mods. If you do it the other way round, first scoring mods by opinion and then do one challenge for all, you'll likely end up with either stock or one mod combination dominating the leaderboard. It's like balancing a new game, very hard to do in advance. Most games are balanced by playtesting, you watch which strategies are successful, and apply tweak after tweak to the rules. In the end, if many different strategies are able to win, the game is balanced.

Such a difficulty scale depends largely on the challenge. Otherwise you end up with a car race around KSC that gives extra points of you have deadly reentry, remote tech and life support installed. Actually the best way to measure the effect of mods to a given challenge is to set up a robust measure of success and then compare the best results of certain mod combinations.

I agree. When large acceleration happens, a large force is at work. And if the new direction seems dubious from a developer's perspective, it smells like external pressure that people are not allowed to talk about.

Now that we have gizmos with fancy direction arrows, red/green/blue snap might be the most convenient UI.

All these functions just need some coordinate system to work. And ideally they all get it from the same location (like a pointer currentVessel.coordinateSystem). We already know that this pointer can be changed, since this is what 'control from here' does. So functionally this is quite a small change. Of course this does not mean that it is easy or safe to do in the current KSP code. This is something you can't tell from the outside.

I don't see any lift arrow. If the lift is zero, it has no well-defined point of attack, so the CoL marker has no meaning. Also note that the CoL is different from the center of drag, which unfortunately is not accessible at all.

Sounds like a good idea. I often use mechjeb cases for this. The suggestion to squad would be to extract this function into a new "control from here" part module that carries its own coordinate system. Give it a nameable button (so you can distinguish multiple orientations) that can be assigned to action groups.

I don't think unique vessel IDs are a safe thing to use. You can easily glue vessels together and chop the result into arbitrary pieces, so there is no well-defined way of assigning the previous vessel IDs to the new assemblies. I've seen enough strange behaviour with vessel names when separating docked vessels. The 'atoms' in KSP are parts, so contract flags should stick to parts in some obvious way. Maybe the heaviest component, or the control part. Surely not the root part since this is invisible to the player, and may change in strange ways. The experiment module could be used as a 'fulfill contract' module that offers a button when the conditions are met. When activated, the button changes to a field that gives some indication that this part is already part of a contracted station or sattelite. The button on a research lab could be something like 'dedicate to minmus orbital station'.

Arbitrary limitations are a vital part of most games. The (highly subjective) question for me is if a certain limitation is * a vital game mechanic * a flaw of the implementation (like bugs, missing content) * or even a workaround to simplify things for the average player If for example I look at a real car engine, it looks pretty much like the result of heavy part clipping. Everything is crammed where there is room, stuff is built around other stuff and some of the tanks have strange forms in order to use the available space. There is no such thing as a slice of the car dedicated exclusively to the battery. So for me part clipping falls into the third category, and I do lots of clipping, provided that I like the looks of the result. In the second category I would put things like TWR and deltaV Numbers. It would also be a perfectly valid viewpoint that guessing those is meant as vital part of the difficulty. Or that they would confuse new players too much.

There was also a bug in the drag equation for air intakes. Something about a number which is multiplied twice, which results in drag amounts that don't make sense. Does that sound familiar to anyone? Is this still an open bug? I can't find the reference at the moment but it probably should be mentioned here because it has a big influence on the usefulness of different intakes. The resource gathering part should be unaffected.

As I understand, the fuel consummation is determined by thrust (depends on speed, so-called thrust curve of the engine) and Isp (depends on air density). Then these propellant ratios determine how the fuel consummation is divided into liquid fuel and intake air.

Yes, by shifting center of thrust I was referring to the regime when there is not enough air for all engines. So in the beginning every engine will run at maximum thrust, so the CoT is an average weighted by engine thrust. When air is scarce (suppose no flameout yet), every engine is limited by its intake(s), hence the CoT is an average weighted by assigned intake area. The path between those border cases might be straight, or include more asymmetric situations (like one engine at full thrust and another near flameout). And the CoT will jump whenever an engine flames out. I'd love a manual option, as you can set different priorities. You seem to optimize to have the first flameout as late as possible, while I would optiomize to make it symmetric even if it occurs earlier (supposing a typical spaceplane with symmetric pairs of engines). The player also just has more information he might use in some way, like engine thrust, Isp, placement and symmetry of engines, or stable/unstable axes of the craft. Or use plain trial and error. Edit: as a consequence of the above CoT discussion, I'd suggest that you try to give each engine intakes according to its air consummation instead of distributing them uniformly. This might be tricky for engines with different trust curves and Isp ranges...

A completely different idea: what about offering an interface so the player can enter the distribution? Including some intelligent visualization of the results. Maybe even visualize how the center of thrust shifts as the air gets thinner...

In a curved space(-time), the whole concept of relative velocity only makes sense for objects which are at the same place. Say there are two houses 1km apart from each other, on a flat plane. Then, a mountain grows between them, so the shortest walkable path between them now is 2km long. Then the distance between the houses changed, but none of them did move. There is also no upper limit on how fast the distance can change with time. In general relativity, the 'line of sight'-distance behaves like such a mountain path, following the shortest way across a curvature landscape (that also changes with time). The belief that there are regions of space whose light will never reach us is based on the assumption that space is homogenious. So we extrapolate that the 'relative velocity' of distant galaxies converges to the speed of light, but their distance does not converge to infinity. If space os homogenious, then behind that limit there must be more space similar to the observable universe.

You could consider symmetric pairs of engines. Let's say we have two pairs of engines and 6 intakes. Then it should be a fine solution to give the first pair of engines two intakes each. The engines of the second pair will flameout first. By that time each engine of the first pair will use all the air from its two intakes, so no air will 'overflow' to the next engine in the list. If there is a single engine without symmetry, assign any single or leftover intakes to this. Symmetric pairs of engines and intakes (with at most one single engine) should cover most cases of planes. When engines flameout in pairs, you keep yaw-stability which is the most important. There might still be moments in the pitch-axis but you can't generally avoid those with an arbitrary plane and some odd number of engines and intakes.

As far as I know tweakScale still messes up the TWR of engines. As a default, part mass has a scaleExponent of 3 and thrust has 2. The consequence is that scaling to half size will double the TWR of an engine. This bug makes shrinked engines extremely powerful and enlarged ones pretty much unusable. So your 1.25m poodle is probably more powerful than the boost Steambirds asks for.

I've seen the same with other animated USI parts, namely the Karborundum drive and the AES pod. They seemed to check collisions with other parts of the same vessel. (Might be outdated as I haven't played for a few weeks)

My experience is that gimbal on a pushing engine helps, but reaction wheels attached to the engine will work against you (by flexing the engine part instead of turning the whole vessel, acting like a gimbal in the wrong direction). If the wheels/RCS are attached to the asteroid separately, they should work fine. As long as the engine is running, all you need is a gimbal angle larger than your alignment error. To stop the engine from wobbling, it helps to have it close to the claw, with no torque acting on the engine assembly.

Hi m4v, i have a feature request for you: Just like the small blue thrust arrows on RCS thrusters, could you draw a small lift arrow on each lifting surface? It would work like the CoL indicator, and show the contribution (point of attack, direction and magnitude) of each wing/control surface to the total lift. You could also add the torque that the total lift force applies to the craft, just like you already do for engine thrust. This would be highly useful to recognize hidden things like * wings giving no lift because they are placed sideways * wing pieces applying their lift force at unexpected positions (e.g. at the root of a wing instead of the center) * differences between wings and control surfaces * parts giving an unexpected amount of lift (much more or less than their visible mesh would suggest) Any chance of such a 'lift mode' in RCS build aid?

Do you know these small thrust arrows on engine or RCS nozzles? They are probably done by the RCS build aid mod. It would be useful to show lift arrows in the same fashion on every lifting surface. So a wing piece put sideways would show up as a small blue ball without an arrow. If the arrow contains a magnitude, you would also notice if the actual lift rating of a surface is different from what its mesh model would suggest.

Shouldn't it be 9.81N and 1kg? Coming from this 'g' in the formula that was introduced so that working with imperial or metric units did not produce different numbers. As I understand, ISP is the time that an arbitrary amount of fuel would provide 1g of acceleration on its own weight.

Generally opening/documenting interfaces, so that the content can be done by the community. New Planets for example. Integrating stuff that already exists as a well-tested mod.

I'm not sure if l have fully understood what this CoL indicator actually shows. Can someone confirm or disprove my theories? Here is my understanding of how this CoL stuff works: 1) Imagine a plane in stable flight with constant velocity. Let us say thrust and drag are centered so they do not cause any momentum. If the forces of weight and lift would not be in line, the plane would turn around the pitch axis. Simple physics. So in straight flight something must happen to bring them in line. 2) The CoL arrow in the SPH doesn't point straight up, it has a light forward tilt. It always points up, even if you turn a wing upside down. So my theory is that the SPH actually calculates the lift force for an airstream that does not go horizontally but a few degrees upwards. So you see your plane at a fixed angle of attack (around 5°). This is even necessary for stock aero because at zero angle of attack there would be no lift. 3) If you turn the plane around the pitch axis (in the SPH), you see the CoL for different angles of attack. If a plane is hands-off stable in the pitch axis, the CoL must be behind the CoM at high angles of attack, and in front for low/negative angle of attack. The stable equilibrium is the angle where the CoL and CoM are in line (note that trim will move this equilibrium point, see #5). A stable plane will seek this angle of attack, resulting in a speed and climb/sink rate that depends on the thrust. 4) This shound work the same for other axes. So turning the plane around the yaw axis should simulate sideslip. If the plane is stable, the CoL indicator should create a momentum to turn the plane back. 5) If you attach control surfaces at an angle, the CoL indicator moves. This shows how the plane will react to control input.

For balancing vessels, I also miss a way of telling all those small editor helpers when they should consider the tanks full (like the CoM indicator, rcs build aid, Mechjeb). The best would be to have everything tweakable in the editor and only force empty tanks at launch.

The are supposed to attract new buyers. But do they succeed? My first contact with KSP was that someone told me the name, and that this is a game I might like. I went to the KSP site, clicked through a few videos which clearly did not show a second of actual gameplay. Disppointed, I went to Youtube, which provided a much better impression of what this game is like. So the first trailers even left a negative impression.