DMagic

@scottadges Thanks for looking into that. I'm fairly certain the problem is XScience (I think Automated Science something something and For Science would also have the same problem). It's also telling that I've never heard any reports of issues with the other US science parts, the thermometer, barometer, etc... Those also use a custom science module, but not one that would have this particular problem when used in conjunction with science management mods. You'll notice those "Running DMScienceAnimate" lines in the log, referring to DMagic Orbital Science experiments, both XScience and Automated whatever have explicit support for running DMagic Orbital Science and DMScienceAnimateGeneric (which is used by a lot of other mods) experiments (For Science does not have this support, which is why it is marked as incompatible with DMOS). But they don't have that kind of support for any random experiment that changes the science behavior like these do (they mostly have custom behavior in managing multiple samples for the same part). I'm pretty sure that Science Alert would handle this correctly, as it does this the right way: https://github.com/linuxgurugamer/ScienceAlert/blob/master/Source/ScienceAlert.Experiments/ExperimentObserver.cs#L284-L288 So the simplest solution would be do these experiments manually and bug whoever is maintaining XScience to change its behavior when it deploys the experiment. It should, theoretically, be a simple thing to change, and I think it's something I've brought up before, but all of those science mods tend to pass through multiple different maintainers and developers.

@scottadges Are you, or anyone else with this problem, using any of the science helper mods, like XScience, For Science, etc...? Or Kerbalism? All of these functions work fine for me, so it's a little hard to figure out what's going on.

That's sort of how it has to work, at least without really changing how KSP's code base works. All of the code for Making History is in the base game, at least as far as I know (there are a whole bunch of Expansions.something namespaces that you can check out it VS's Object Browser, or whatever program you use, or the API docs). I guess they could lock out some functions by testing to see if the expansion is installed, but generally I would expect all API features to be the same.

This doesn't make too much sense to me. If someone really cares about more terrain scatters and things to do with them, then they will probably buy the DLC. If they really want such a feature to be in the stock game, but aren't planning on buying the DLC then it doesn't much matter, they weren't going to buy it anyway. I imagine there is a very small number of players that care so much about this aspect that they would not buy a DLC that they were already planning to buy, just because of that one feature. I'm guessing there will be a small number of players that quietly think that way, and 3 or 4 that loudly think that way, and not much more.

So... you mean read all sorts of wild implications regarding inventories, storage, "put them on the ground", etc...

If I had it to do over again I would eliminate the need for KAS in SEP (not KIS though). Either make all of the stations simply be placed within some proximity of the central station and power, or make some "faked" cosmetic connections between each station, rather than actually linking the vessels with KAS. I'm fairly certain that the linking of so many parts that are all anchored to the surface is what causes so many headaches for SEP. Removing that dependency would simplify the mod and get rid of a major source of errors. But that's all a lot of trouble to go back and fix, and now sort of irrelevant.

Anyone have more details on this problem? Is the problem collecting data from the part? Or resetting the part after collecting data? Or collecting data after resetting the part? All of the above? Do the options for collecting or resetting the part appear in the right click menu? Do any screen messages appear related to this? Does it work during normal use, from inside the vessel, but not on EVA?

The new maneuver node handles don't work as buttons (at least I'm pretty sure they don't, the scroll wheel does work, though), and they don't work based on how far you pull the handle (like the old maneuver gizmo does), instead they work based on how fast you pull the handle. Instead of dragging the mouse further away to increase the effect you have to quickly jerk the mouse, I guess part of the problem is that the UI is down in the corner, so you can only pull down or left so far before you run out of room. The problem I've found, is that it seems difficult to alter the change rate after you have started dragging the handle, if you start with a quick movement to make a larger change in dV, then you can't really slow down without starting over. And there seems to be fairly little difference overall, even a very fast mouse movement only makes the dV change a little bit faster. It makes it a little awkward to control when you have been trained by the regular maneuver node to do it a different way for so long. There you just modify how far you are pulling the handle to adjust the increment. I guess we are supposed to rely on the dV scale slider. Or maybe they should come up with a different UI for adjusting the maneuver node, instead of trying to replicate the existing system in a condition where it clearly isn't well suited. Also, the dV increments are a little silly, when has anyone ever needed 1000m/s per tick? That could be topped out at maybe 100m/s and add more increments at the low end for extremely precise maneuvers (or probably just make fewer increments).

This question goes in the Kerbalism topic, as it changes how all science systems work.

I'm not sure about RelativePositionAtUT, but SCANsat uses getPositionAtUT, along with a correction for rotation taking the current time vs the time being checked (the part about fixLon/Lat is just for clamping the values). https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANcontroller.cs#L2065-L2073

The high/low space/flying value probably isn't very helpful. But KSP does have some more useful data about this sort of thing. CelestialBody.minOrbitalDistance will give you the lowest safe orbit (which, if you subtract the body radius gives you the highest point on the surface), I'm not sure about bodies with an atmosphere (I think that value will just come back with the atmosphere height), but there is also the FinePrint utility method, CelestialUtilities.GetHighestPeak that will tell you the highest point. Basic Orbit uses this data to trigger the display of radar altitude when in orbit. Considerations could also be made about the threshold level based on being in orbit vs being sub-orbital, or in flight.

Yes, a fairing will block any drag effects on the parts inside of it. But that is not always a realistic solution. More flexible handling of engine drag from Squad is the only real way to get around these problems.

Certain combinations of variants and engine placement can cause drag problems. Like using the smallest variant of the Terrier in the middle of a stack. Even with the engine shroud present, the game's drag system "sees" the Terrier as a much smaller part in the middle of what looks like a perfectly smooth cylinder. So you get a kind of stair-step drag problem in the middle of the vessel where the part below the Terrier receives much more drag than it should. If you used the bigger variants of the Terrier you won't see this problem. This is because the drag system can't handle both engine variants, and engine shrouds at the same time. It either modifies the engine drag based on the variant size, or based on the presence or absence of the engine shroud, but it can't manage both. While it won't always make a vessel unstable, the basic effect of this problem is that you are penalized for using the smaller variants of engines in the middle of a stack, even though visually everything looks like it should work fine.

Do you mean the list of keyboard shortcuts available in the settings menu? I guess it would be a lot of trouble to stuff another option in there (definitely possible, it's just a standard UI, but tedious), but there is no real need to do so. The stock list of keyboard shortcuts is a just a reference that various stock scripts use when listening for input. You can just load a KeyCode value from a config file and listen for that key press, you don't even need to parse the value from a config file if you are using the standard KSP ConfigNode, it supports KeyCode values. And a simple solution to having too many existing keyboard shortcuts is to require that the modifier key be held down, also. private KeyCode shortcut = KeyCode.G; private void Update() { if (Input.GetKeyDown(shortcut) && GameSettings.MODIFIER_KEY.GetKey(false)) { //Do something } }

It might be true that balancing and part adjustments are generally considered "improvements" but I've never heard anyone complain about the crash tolerance of the RCS balls, and given those parts' importance to this kind of wacky designs I think it would be prudent to consider that when changing their properties. If making a few tiny parts a little bit less crash tolerance means they no longer work for this kind of hinge, or bearing type of design, then maybe they should just remain unchanged. A lot of the attention KSP gets outside of its own community comes from these kinds of designs, and that is worth considering. This is a perfect example of where more community input could really help. The game's designers aren't generally going to be the people most familiar with things like part balance and their nitch uses.

I'm still not seeing it. I know the button you are talking about, and it works that way when in map mode, but in the flight view it is always greyed out. In the screenshots you can see that the maneuver node exists, but the cycle button is greyed out in flight view, it works fine in map view (this is with a clean, stock installation of 1.7): So my question remains. Is it intended that you can't use the maneuver node panel in flight view? And if so, why? There is no technical limitation that I'm aware of that would prevent this, so it seems like a strange decision. In particular, I would imagine that lots of people would want to be able to use this function from the IVA view

Am I doing something wrong, can you not edit the maneuver node in flight view? As soon as I close the map the maneuver node panel goes away. That seems like an odd decision, with the orbital info right there you could easily edit the maneuver node in flight view, so I don't see why the UI would not allow this. Also, to whoever was asking about the orbital parameter UI not updating every frame, it doesn't. It seems to update about every 3 or 4 frames, though I'm not sure if this is based on the number of frames in between or the time passed. The only good way to verify this is to run the game in the Unity debugger, it's pretty obvious when the UI updates that information. Now if only the same thing could be done for the deltaV info panels (those UI updates generate a lot of garbage allocations).

@Fearless Son Kind of like these things:

The drag isn't caused by the empty attach node on the back of the engine. It is caused by that engine's drag cube, which reflects the very flat surface on the back of that engine. If you look at most of the other jet engines they are tapered more like a cone in the back, and their drag cube values reflect that. There is one other engine, the Whiplash, which has a relatively flat back and a relatively high drag coefficient on its back end, I would guess that one also generates excess drag, though not as much as the Rapier. If you want to test this you can just delete the attach node at the back of the Rapier (node_stack_bottom in the config), and compare its drag to the standard version with nothing attached. Putting a nose cone on the back of the Rapier just blocks the drag on the back of the Rapier and instead presents a nose cone, which is similarly shaped to other engines, to the airstream. More on drag in the spoiler: The only way to really fix this is for Squad to stop relying on automatically generated drag cubes for almost all of their parts. Engines could be massaged to reduced this tail-end drag (and to fix a number of issues caused by engine variants). And a number of parts are out-right bugged (structural tubes) because they don't have their drag cubes setup right.

At any time you can delete the scan data for any type of data. If you change the existing scan types and want to reset the data, just go to the settings menu, choose the data type, and reset it for all bodies.

@UgoXT Do you have log files? Where did you download SCANsat from? How did you install it? It sounds like the problem is that it isn't installed right, as nothing is showing up.

@vardicd Well, they generally should wait until a few of the Universal Storage cores and shrouds are unlocked. The RPWS is probably just an oversight, but a few parts in different categories really doesn't matter all that much in the end.

The UI will (generally) always be updated after physics calculations are run. But that has nothing to do with whether you want to update that UI every frame, or you to update with less frequency. The Unity object life-cycle dictates in what order code is run. But that has no bearing on what I'm talking about, which is whether or not the UI is being updated every frame, or not. This isn't like multithreading where you have to worry about two different threads accessing the same object in memory; whether the physics math is slow or not has no bearing on the relative frequency with which you update the UI.

I'm not talking about physics calculations. KSP is already calculating all of these orbital parameters and other related data all of the time, on every physics frame. That is not going to change in 1.7. I'm talking about taking those numerical orbital values, converting them to a string of text, which generates garbage allocation in two unavoidable ways (it's technically possible to avoid the garbage allocation inherent to converting a numerical value to a string, but the string itself will always generate garbage), then displaying that text on screen. That has nothing to do with when the physics calculations take place. That is just a matter of when you want to update the UI, which can be done whenever you choose.

We should all be hoping that the displays don't update every single frame. That would be a significant performance optimization (and if you think KER's constantly updating display isn't barfing out 10X as much garbage allocations as KSP's baseline you're fooling yourself), this kind of conversion of numerical data to a text display comes with unavoidable garbage creation. Updating the text every other frame, or 3rd, or 4th frame significantly cuts down on that effect while being barely noticeable for most players. If you have a large craft causing low frame rates then the display will always look a little laggy, but one solution might be updating based on real-world time, rather than frame rate; update 5 times per second instead of, say, every 4th frame, or something like that.