DMagic

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.

I'm not sure why people think KSP has a "cartoon" look. Cartoon, or "toon" is a fairly specific visual style, there is a wide range here (think Borderlands on the more realistic side, or flat-shaded, low poly games on the other side), but KSP doesn't fit anywhere in that range. The Kerbals themselves look a bit cartoonish, and I could see the argument for them, though not so much when you only see them from behind with their helmets on. But the actual game just has a very bad realistic visual style. The terrain of basically all planets has realistic, but very bland textures. The parts range from smudgy, oil-drum style visuals, to fairly decent realistic styles. I think the game looks the way it does because its visual aspects have remained basically unchanged since the early versions, which were made for an ancient version of Unity, by people who either weren't very experienced with art assets or were more focused on the programming side. A huge amount of visual improvement could be had by just taking advantage of some of the more modern lighting and shader aspects of Unity. There is no reason to change game engines simply to get better visuals. And for people that have old computers, that is why the graphics options menu exists. If something like clouds, atmospheric light scattering, better lighting, or improved water effects is too much for your computer to handle then you could just turn off such features. Maybe KSP's player-base differs a little from the overall Steam population, but I doubt if there is a more representative source of hardware information available. https://store.steampowered.com/hwsurvey/videocard/ According to Steam about 50% of users have at least a GTX 1050 or higher level of graphics card (maybe more like 60% if you add up all of the individual GPUs above that level). Which is more than enough to handle anything KSP can throw at it, even with a lot of visual mods. A range of visual improvement options doesn't seem like something that would be ignored by the majority of players.

@Crio Kerbalism changes a lot about science works, so any questions about that will have to be directed to the Kerbalism people. @Tacombel There are a few experiments that won't be detected by any science monitoring mods, as they don't work in the standard way. You'll just have to handle them yourself.

@Jumberlack SCANsat uses a 32 bit integer array to store all of its scanning data. This allows it to specify which type of scan has been performed on each spot of a planet's surface. It also means that there are only 32 different scan types available (those values are 2^0 up to 2^31). This could be switched to a 64 bit integer, but that would double the already significant amount of space in the save file required for saving all scanning data. It would also require a tricky one-time conversion of all old data to the new system. And it would probably affect overall performance of the mod, as this data storage array is constantly being accessed and updated. The values are specified in the config file to allow users to set their own resource types if they are using something other than Community Resource Pack resources, or if they want some different combination of resources.

I believe the mesh transform is used by the fairings to toggle on the girder mesh along with its extra attachment nodes. I don't know if it does anything for engine plates. As for using config defined attach nodes, I'm not sure. Universal Storage uses this module to switch attach nodes, but it uses model defined attach nodes. I'm on mobile now, but will check into how US is using it more when I get a chance.

I don't think the issue is so much the time it takes (did anyone say the parts included here could be made in 5 minutes? That would obviously be an exaggeration anyway), it's that a group of modders working for free, in their free time, have demonstrated the ability to make a more consistently high quality set of parts than what Squad has managed working with paid professionals, presumably working full-, or at least part-time. The Making History parts in particular are riddled with bugs, odd design choices (engine plates really mess with staging and dV), and poor balancing. That may be, but what they've provided is really poor quality. It's just a single, very large pdf with no organization at all, no contents, or internal links at all. You just have to scroll through to find what you need. That is really not very helpful. That's also true, but PC players generally play with a mouse, a precision pointing tool which is well suited to clicking on relatively small, moving targets. Fumbling around with console controller thumb sticks is an entirely different world of control precision.

Unity 2017 supports .NET 4.6 as an "experimental setting" in its Player Settings menu, but I don't think KSP uses this (I'm fairly sure that Unity 2017.1 was when this option was added, so it's doubtful that such a complex game like KSP would jump on an experimental feature like that at such an early stage). I continue to always set the target as .NET 3.5 for KSP mods. As for how it works on MacOS, I have no idea.

@UomoCapra : "For the time being, the KSPedia will remain in the PC version of the game, but you’ll be able to access it from our website as well." Some clarification on what this means could really be helpful. A downloadable pdf is next to useless compared to the in-game help tool as it exists today. And there is no comparable way for mods to offer their own in-game help without the considerable work and effort required to make a custom UI for it. So what does "for the time being" mean? Will it be removed at some point? Why would that happen?

@cicatrix You are missing the ContractParser dependency from your GameData/DMagicUtilities folder. I'm not sure how that could have happened when installing through CKAN, as it is set as a dependency there. You could try deleting Contracts Window + and reinstalling, or just manually install Contract Parser, or manually install Contracts Window + from Space Dock, which includes all of its dependencies.