diomedea

@HebaruSan: thanks for linking that article, is pretty interesting. Believe we'll have to see how it works when that new filter is released.

Merging all selected threads in one? Believe was attempted while we got acquainted with IPS on a testing site, never (that I know of) on the real KSP forum.

It's rather simple, we have to be viewing the thread into which other posts will be merged, then hit the "merge" button in the "Moderation Actions" menu, a dialog shows asking for the URL of the thread about to be merged (which I'm never smart enough to have copied in advance ). There are a couple technical things to be careful about, as IPS can get confused if we don't pay attention to something in the status of merging posts (we learned those the hard way).

Unfortunately the basic filter we have in IPS doesn't recognize word separators, but will filter any occurrence of the "A++" sequence. There are a number of perfectly legit words that would be changed in something different, "mass" e.g. could automatically become "mdonkey" with the proposed change. Therefore why that word isn't catched by the filter, better if we catch it by eye (with the help of forum users, of course). Hopefully we will find and install a better filter in future.

@ZQSDsvp: got your reason about using a separate set of keys. Certainly a matter of personal preference, I never found the need to make something like that in KSP. About the missing settings, a number of bindings currently are not shown in the settings interface, but are changeable via manual editing the settings.cfg just like you proposed. However these ones are not exposed, not saved with settings. It would take making a few more lines in the stock KSP code to implement the read, write, assign by default functions for those keys just like done for all others (and remove the hardcoded bindings). Nothing complex, I did something similar with add-on code; however it remains with KSP devs to agree this is a worthwhile change and find that little time it takes to implement.

Certainly the Space Center move keys aren't mapped in settings. Probably something overlooked since now (but then, there were a few more unmapped keys in the past, some a lot more annoying). One question: I have the arrow keys doing exactly the same as WASD in the space Center, believe those should work with an AZERTY keyboard just as well. Unless the OP is using a laptop without arrows as alternate key meanings. Would like if this missing settings issue was already reported on the public bugtracker, but seems it never was. Let's see if can summon some magic to have it cared...

Uh, my turn? @Frybert?

Me too. @DuoDex?

"Modding" is a very wide subject. You could be interested in programming, so, creating plugins, then best to start reading the very many help threads in here. Or, you may be about modelling, creating parts, then best to start looking at tutorials here. But you may even start modding by just editing config files, or else. Anyway, moved to Add-on Development being most proper section until you show a specific subsection could be more adequate.

Contrary to common expectations, best reentry profile with Spaceplanes (as with Space Shuttle IRL) is to keep a very high Angle of Attack. 40° generally works fine, but in KSP even 90° AoA can be attempted. Presenting the largest surface to the airflow actually causes more drag, but while air density is still thin that is bearable, while airspeed gets greatly reduced; therefore when the spaceplane finally descends at altitudes where air density is high enough to be a factor, its speed is much lower. Drag is directly proportional to air density and to the square of airspeed, so reducing the latter while still high is very beneficial to reducing drag later, and with drag both the thermal and physics effects on parts.

Thanks for the explanation. But then, if the capacity now scales to always cover 5/3 * crew capacity of each part, it shows to be broken. The vessel in my game showing more of this issue has one PPD-12 cupola (1 crew), 2 x PPD-10 hitchhiker pods (2x4 = 8 crew) and a Mk2 landing can (2 crew). Total 11 crew capacity (so the capacity of processors should be 11x 5/3 = 18.33), and 11 crew aboard. Another vessel has one cupola and one PPD-10, total 5 (so, capacity should be = 5 *5/3 = 8.33) and its 5 occupants are getting poisoned as well, though not as fast as with the first vessel. Restarting game didn't help in my case. Really it seems like I'm having a fixed capacity for each module, not proportional to the crew capacity (so, PPD-10 can hold 4 kerbals but still only provide for one, or maybe 5/3, falling way short than the requirement). Vessels with just one kerbal per module keep working as usual. EDIT: so, checked how this capacity of processes scale works. New vessels indeed have it with amounts = 5/3 x crew capacity for each crewable part. Old vessels already in game don't have it updated, it was and still is = 1 for each module. With the new system those quantities are way shorter than what needed. This requires saves with old vessels have all vessels edited, or to wait until them all are recovered before updating to 1.1.9 (in case no permanent or long missions are ongoing). Going to edit all crewable parts with all my vessels ().

@ShotgunNinja: did anything change from Kerbalism 1.1.8 to the new 1.1.9 version, about how scrubbers work? Since updating to 1.1.9 (heavily modded game, but that's the only change I did), CO2 levels keep increasing regardless of scrubbers, of course end killing all crew. Reverted to 1.1.8 and CO2 is kept under control as expected.

Not easy to diagnose when the only output device from a PC goes black. PC may not be locked up at all, but you can't see any way to regain control. It may easily be an application in background taking focus and waiting for user input, but you can't see it while the screen is black (e.g., the firewall I use has this annoying behaviour, it stops the foreground application when it tries to connect to the web and isn't already whitelisted, and asks how it should deal with it. All correct, but doesn't help when its dialog goes hidden below the stuck foreground app window). Perhaps you use KSP fullscreen? If so, I'd make it in a window, that would allow to keep seeing other events on your PC while KSP loads. You don't need to start KSP to change its video mode, best way would be to delete the settings.cfg (it would be rebuilt from scratch with default values, and those are for windowed display). Best if that settings.cfg is saved somewhere else so you can restore it later (I use to zip such files, is a fast way to keep them safe while the original is binned). In case even with a windowed KSP you get a black screen, that could be indicative of a video mode mismatch (e.g., KSP is instructing the GPU to use a unsupported resolution). Again, that shouldn't happen with default settings values, as those are supported by all known configurations; moreover, if the same settings were working few days ago, there's no reason why they shouldn't now. Another cause may be tied to the GFX hardware, but I doubt it, you would notice with other applications too. Anyway do test with something graphically intensive, that requires the GPU to work at its maximum. KSP isn't graphically intensive as other games, but requires the GPU to do a lot of computing (GPU can often be the bottleneck with performance in KSP). But lack of performance would normally result in lag, not a black screen, unless the GPU overheats and then shuts down. If you have an overheat (that other apps should also be causing), you would better check GPU temperatures (there are a number of tools for that, generally also from the GPU producer; this is one I find pretty useful). In case of overheats, check the GPU fan(s) are free and there's no dust around. EDIT: oh, btw, I believe this below should actually result in a shutdown, not a black screen, unless your PSU has multiple independent power lines and the one used for your GPU isn't the same that goes to the mainboard. In case, the PSU may be unable to supply all the power the GPU requires; therefore the latter shuts down (protection from undervoltage). Should result in a lack of signal to the display, most displays provide info when that happens therefore you should notice. If none of the above helps, could be best to watch for events registered by the OS. Windows has a console to visualize system events (part of the MSC, Admin Tools) and that allows to read what unusual the OS logged before or during the previous session. Something causing a shutdown, but even a system lock, should get logged. However that's a technique I'm not fluent enough to give advice on how to use and would take too long to describe here; maybe for another post if really required.

Importing orbital params with vessels and roid in KSP works fine. SMA, ECC, INC, LPE, LAN, REF are all as expected. EPH makes me wonder, KSP savegame holds value much higher than UT in game; Orbital Ops in KSPTOTConnect shows a value about 5500 seconds higher than current UT in KSP. It could be all right, but that makes my comparison of MNA pointless, values are in reference to different times. MNA values are clearly very different and that's all I can say just now. Maybe with some elliptical geometry I could compute MNA for different EPH, but I wouldn't trust to make that right, better to let you know that's a value I couldn't test. EDIT: solved the issue about the EPH difference. Need to read Current UT in KSPTOT MCC Real Time System from the status line at the bottom; the value with a vessel parameters seems to be updated with some delay (so, taking snapshots after timewarping can bring to such differences). Checking values in KSP against the status line shows a match; and MNA also matches. There are a couple issues worth a note with the Real Time System. 1) I can select one vessel (or asteroid) finely the first time I do the connection to KSP. But when I then try to switch to another vessel (or roid), either restarting from the MCC Real Time System on the main KSPTOT window, or selecting "Connect to New Vessel" from the MCC Real Time System Connection Menu, I am presented again with the "Select Vessel" dialog, there is no list of vessels to select so have to redo "Test Connect to Remote Host" to see again the list of vessels. But then, for any other vessel I may choose, after connecting, I open again Orbital Ops and again find the values relative to the first vessel I chose, instead of the vessel I selected from the list. 2) If I choose to "Terminate TM Stream" from the MCC Real Time System Connection menu, then want to restart the connection, can see the stream going on within KSP (the Console Window shows all messages about the ongoing stream) but the MCC Real Time System remains stuck at "Disconnected" in its status line (of course no window with values can then be opened from the MCC Real Time System main dialog).

Had a suspect asteroids wouldn't be easy to tame. They are all generated so to cross the SoI of another body within a rather short time, so there's not much of their Sun orbit before that, while a Hohmann transfer requires a large arc (180° along the transfer orbit). Almost all roid encounters are actually conducted within the minor body SoI, therefore while the roid is on a hyperbolic orbit (my procedure is to maneuver the vessel so to get an early encounter, as close as possible to the SoI limit, but that requires the vessel to be already past its AP and descending while the roid arrives from above; certainly not Hohmann). It is slightly less efficient than the early encounter to go meeting the roid before it even enters the minor SoI (though, the farthest from the minor, the less DV required to redirect the roid); but definitely such a maneuver requires a different approach. So, I'm really glad to see there is interest in the idea. Delighted about the possibility to plan encounters with other vessels in the same SoI. Fantastic if this tool could also compute hyperbolic encounters, I get it's a very different task than with closed orbits. The ability to plan the kind of encounters I described above is probably something for a far, far future.

Works perfectly, many thanks .

Moving the drills up would work. My dirty solution to move them up would actually go by editing the drilling vessels in the savegame (find the drill parts, edit the line with "position = ", the coordinates are X,Y,Z with 0 being the position of the root part CoM, the 2nd coordinate or Y position is the distance along the longitudinal axis of the vessel (+ for distances forward, - for backwards) therefore what you should change if drills are aligned with that axis). I would still prefer to rebuild drilling ships (cleanest solution) but sometimes that's just too expensive.

From KSP v1.2.2 changelog (in the readme): "* Model fixes to the large drill part." Colliders were reworked, vessels built with the drill from previous versions will have interaction with terrain due to deployed drills. Rigidbody physics doesn't allow colliders go inside another rigidbody, which makes the vessel jump.

Would be possible to add tracked asteroids to the list of bodies for which a transfer is selectable? I plan maneuvers manually all the time, asteroids can get a bit tricky to do right (as do bodies with a small SoI), believe this tool could come handy with roids even more than it is with planets.

Any progress about getting asteroids with KSPTOTConnect in v.1.5.6? While I can copypaste their orbital parameters from a savegame in bodies.ini (with the needed conversions) and make them appear as bodies for computing encounters, I'd prefer if they could still be imported alike vessels, as was possible in previous KSPTOT versions. Fine if you need more time about this issue (but please don't let it unanswered) .

Current version (1.2.4) works fine with KSP 1.2.2 (build 1622). You get a message from AVC version control, because the PreciseNode.version file (in GameData/PreciseNode/plugins once installed) has all fields for KSP version stating 1.2.0.0 (therefore, 1.2.2. raises the warning). That version file can be easily edited, if you change the "PATCH" field from 0 to 99 within the "KSP_VERSION_MAX" section, it will not show any warning for any variant of KSP up to 1.2.99.

Thread closed. Original author confirmed to have given permission to @SpannerMonkey(smce), who already set up a new thread to keep the mod going.

Glad you already found your answer, closing this thread therefore.

That issue totally depends on the speed video RAM is updated and the video mode used. Normally, video RAM holds at least two buffers of memory for the screen, while one is being read to display the image, the other is being written with new values; then the two are switched. That way, each frame is a "whole" image. Each memory buffer has to be as large as screen height x screen width x color depth (e.g., at a 16million colors depth (RGBA) it takes 32 bits/pixel=4bytes/pixel; a 1024x768 RGBA image takes 1024x768x4 = 3MBytes). When RAM isn't enough, or not enabled to hold at least two buffers, read and write operations have to go on the same space at the same time. Now, please note how the the two halves (top-right against bottom-left) of the screen appear to be mismatched in the vid: when you scroll down, top-right shows lower; when you scroll up, top-right shows higher than bottom-left. That shows, for each line of pixels, the left part of the line being drawn before values are updated, the right part of the line being drawn after the value was updated, therefore showing a different scene belonging to a different frame. As you have a integrated GPU, bets are it is also using system RAM instead of dedicated VRAM. RAM is slower, and that also contributes to how the effect shows. Believe you have settings allowing to dedicate more memory to the exclusive use of the GPU, that would allow to use the two buffers. If possible, install some dedicated VRAM; better yet, don't use integrated GPU for applications (as KSP) so intensive in use of graphics but install a proper graphics card.

Actually the wiki, still reporting 9.81 m/s2 for Kerbin's gravity, is accurate. Computing gravity with exact values of mass and universal gravitational constant (or, gravitational parameter) and radius for Kerbin, gives exactly 9.81 at sea level. But the value of gravity changes in reality with latitude. That's why the conventional standard for gravity on Earth (9.80665) is an average of gravity measured at different locations. Earth's gravity of course depends also from the radius of the planet, that is larger at the equator and less at the poles; but even with a perfectly spherical body as Kerbin, true gravity depends on centrifugal acceleration due to its rotation, this depends on latitude (still from my sheet, centrifugal acceleration at the equator for Kerbin = 0.051008154 m/s2, use it with cos(latitude) to have the correct value at any latitude). Summing gravity from gravitational law (9.81) with the centrifugal acceleration gives makes 9.80665 a good average value. KSP uses the average value where appropriate, but that doesn't apply to vessels orbiting Kerbin.