Yoha

/u/Perlscrypt did not receive any confirmation email for the registration to the bug tracker. I was able to reproduce the issue.

I know it's cleaner and simpler to do it upstream. It's more of a quickfix in the mean time. Here is a cleaner Python version though: import re import glob import shutil regex = r'^quicksave_Y([0-9]*)D([0-9]*)H([0-9]*)M([0-9]*)S([0-9]*)\.sfs$' regex = re.compile(regex) for save in glob.glob('quicksave_Y*'): m = regex.match(save) if not m: continue date = map(int, m.group(1, 2, 3, 4, 5)) name = 'quicksave_%.2i-%.3i_%.2i:%.2i:%.2i.sfs' % tuple(date) shutil.move(save, name)

Hi. I have an intermittent problem where some direct lines of communications seems to be missing in the UI:

I figured I could share some code: $ rename 's/Y([0-9])D/Y0$1D/;s/Y//;s/D([0-9])H/D0$1H/;s/D([0-9][0-9])H/D0$1H/;s/D/-/;s/H([0-9])M/H0$1M/;s/H/_/g;s/M([0-9])S/M0$1S/;s/M/:/;s/S([0-9])\./S0$1./;s/S/:/' quicksave_Y* This bash command (there is probably simpler…) will rename dated quicksaves to an ISO8601 variant. Using the `-n` flag (`rename -n 's/…`) will output how files will be renamed. Here is an example from my savegame: rename(quicksave_Y1D10H2M14S51.sfs, quicksave_01-010_02:14:51.sfs) rename(quicksave_Y1D10H2M3S33.sfs, quicksave_01-010_02:03:33.sfs) rename(quicksave_Y1D15H5M13S3.sfs, quicksave_01-015_05:13:03.sfs) rename(quicksave_Y1D16H0M57S32.sfs, quicksave_01-016_00:57:32.sfs) rename(quicksave_Y1D1H0M37S43.sfs, quicksave_01-001_00:37:43.sfs) rename(quicksave_Y1D1H0M42S45.sfs, quicksave_01-001_00:42:45.sfs) rename(quicksave_Y1D1H0M47S14.sfs, quicksave_01-001_00:47:14.sfs) rename(quicksave_Y1D1H0M50S35.sfs, quicksave_01-001_00:50:35.sfs) rename(quicksave_Y1D1H0M51S18.sfs, quicksave_01-001_00:51:18.sfs) rename(quicksave_Y1D1H0M53S2.sfs, quicksave_01-001_00:53:02.sfs) rename(quicksave_Y1D25H0M45S52.sfs, quicksave_01-025_00:45:52.sfs) rename(quicksave_Y1D25H0M46S20.sfs, quicksave_01-025_00:46:20.sfs) rename(quicksave_Y1D25H0M46S29.sfs, quicksave_01-025_00:46:29.sfs) rename(quicksave_Y1D2H4M7S20.sfs, quicksave_01-002_04:07:20.sfs) rename(quicksave_Y1D2H4M9S13.sfs, quicksave_01-002_04:09:13.sfs) rename(quicksave_Y1D30H5M16S57.sfs, quicksave_01-030_05:16:57.sfs) rename(quicksave_Y1D30H5M21S24.sfs, quicksave_01-030_05:21:24.sfs) rename(quicksave_Y1D30H5M23S32.sfs, quicksave_01-030_05:23:32.sfs) rename(quicksave_Y1D30H5M58S35.sfs, quicksave_01-030_05:58:35.sfs) These are time formats for ISO8601 (same as in PHP and stuff): $ date +%Y-%m-%dT%H:%M:%S 2015-08-03T22:36:01 $ date +%Y-%jT%H:%M:%S 2015-215T22:36:01 Here with printf-style formatting (code excerpt in Python): >>> "%.4i-%.2i-%.2iT%.2i:%.2i:%.2i" % (2015, 8, 3, 22, 35, 21) '2015-08-03T22:35:21' >>> "%.4i-%.3iT%.2i:%.2i:%.2i" % (2015, 215, 22, 35, 21) '2015-215T22:35:21'

I have a suggestion for Dated QuickSaves: always pad numbers with zeros on the left, like "%.2i" for hours, minutes and seconds. For instance: Y0010D009H03M04S34 Y0010D023H03M04S07 Y0010D023H03M31S57 Y0010D023H03M35S39 This ensures saves are sorted in the right order, and makes it easier to find one back. Compare with the current system for the same dates: Y10D23H3M31S57 Y10D23H3M35S39 Y10D23H3M4S7 Y10D9H3M4S34 Even better, use the widespread ISO 8601: 0010-009T03:04:34 0010-023T03:04:07 0010-023T03:31:57 0010-023T03:35:39 For even better readability, it is common to substitute another character for "T" (space, underscore). Note: also, please prefer readable date formats for mod last updates

This is a pretty straight forward bug in the Science Archives. All science reports done in the Lesser Flats, Great Flats or Greater Flats (Minmus) are listed in the Flats section as well.

Quels mods as-tu installé ?

For anyone wondering, xZise (and BobBot) have removed the use of */Data so that data templates are now unified for all data templates of celestial bodies. See Kerbal_Space_Program_Wiki:Templates. The previous approach still exist for parts, but at least it is now consistent for celestial bodies.

Hi. I have been having a look the source for the data displayed on the wiki. Apparently, language-independent data is externalized to a specific page. For instance, Rockomax 48-7S and Rockomax_48-7S/ja both use data from Rockomax 48-7S/Box by simply including "{{:Rockomax 48-7S/Box}}". Similarly, Kerbin/fr and Kerbin/de both use data from Kerbin/Data by including "{{:Kerbin/Data}}". So far, so good. However, it appears that Kerbin directly includes "{{Infobox/Body}}" instead and that Template:Infobox/Body will look for Kerbin/Param and include its data. Note that Template:Infobox/Body is also the template for Kerbin/Data. This looks awfully inconsistent and I am trying to get my head around this. Hidden inclusion of */Param is more recent and */Param seeem to hold more information so this may be the new way to go. However, nothing have been changed for parts. Should we use plain direct inclusion with "{{*/Data}}" which looks the most readable, should we switch to obfuscated indirect "{{*/Param}}" for some reason, or should I give up on the wiki altogether?

Again, this is not worth the trouble. If you wanted to actually send a spacecraft through the Solar System, you would indeed have to refine the patched conic approximation with a n-body simulation. On the other hand, KSP only needs a simple but seemingly realistic model and patched conics are good enough and relatively simple to use. The problem of n-body physics is not algorithmic complexity but of analytic solving. Limiting the simulation to three bodies instead of eighteen does not help: even simulating only the attraction of only two bodies on the vessel makes things incredibly more complicated than with only one.

I know that I can select parts whose some attribute matches some value with HAS, e.g.: :HAS[#awesomeMLPvalue[42]] I would like to know if there is some way to match for a range or a comparison operator, like: :HAS[#awesomeMLPvalue[>42]] :HAS[#awesomeMLPvalue[<42]] :HAS[#awesomeMLPvalue[24:42]]

I compiled a short list of mods from the previous posts which fulfill the following conditions: improves gameplay does not change the game mechanics (so I put Kethane, FAR, TAC and such aside) Simpler maneuvering: Kerbal Engineer Redux Kerbal Alarm Clock Precisenode Enhanced Navball Docking Port Alignment Indicator Other interface improvements: Editor Extensions SelectRoot Haystack Immersion: Environment Visual Enhancement Chatterer Miscellaneous: KSP AVC Final Frontier Module Manager

Editor Extensions

Hi. I noticed that RemoteTech2 did not take into account probes from other mods. The probes are patched in RemoteTech_Squad_Probes.cfg which contains the same patch copy-pasted for each of the squad probes. I have written a short patch to add RemoteTech2 capability for any new probe (initially intended for CactEye's Smobodobodyne SLIM probe): @PART [*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],!MODULE[ModuleSPU]]:Final { MODULE { name = ModuleSPU } MODULE { name = ModuleRTAntennaPassive TechRequired = unmannedTech OmniRange = 3000 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } } If RemoteTech2 was to use the previous snippet, the selector would actually only need: @PART [*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]]] Basically, it simply selects parts whose command module does not require any crew, hence probes. Anyone is free to use, modify and redistribute the previous code as they see fit (just in case). Note: there is one difference for the large stock probe (probeStackLarge) that has "IsRTCommandStation = true"; I guess you need this probe in particular to set up a command control with your six crews; so that should still be added somewhere Note: there is a file for Mechjeb (RemoteTech_MechJeb.cfg) with the following code: @PART[mumech_MJ2_AR202] { title = MechJeb 2 (AR202 case) (ModuleSPU) MODULE { name = ModuleSPU } } This means that this part does not have an included antenna. If this is intended, there should be a special case for this part. Otherwise, this is covered by the previous code.

One good example of this is aspargus, where you don't want to add six liquid fuel booster by hand, but need to put asymmetric (w.r.t. to the ×6 symmetry) fuel lines.

You aroused my curiosity. Have you a particular title in mind?

I just felt it would be more helpful to also give a solution for the current situation since there is one.

I get the point, but I feel this is unnecessarily complicating things. Is that adding something to the gameplay?

Well, they do, check the .craft file ;-) . It's actually the editor which does not update the symmetry on selection. That would be a handy change indeed. Check out Editor Extensions. Although: Yeah, there is usually a glitch that makes it so that the first added part is alone while the mirrored parts are soundly grouped. Anyway, the whole staging editing could use a rework (when connecting a launcher to a vessel, add the stages below, don't just merge them!).

I have just discovered Celestia, a software that allows you to explore outer space, including moons, planets, asteroids, spacecrafts, stars… I wanted to share it with you and I found even more; those are mods for Celestia that add the Kerbol System to Celestia http://forum.kerbalspaceprogram.com/threads/9789-KSP-in-Celestia! (old version) http://forum.kerbalspaceprogram.com/threads/21030-KSP-in-Celestia-(Version-2) (you will probably prefer this one) http://forum.kerbalspaceprogram.com/threads/38606-System-designer-and-Kerbol-system-in-Celestia (textures are off) You can install those by simply putting Mocha2007 or extras/ksp in the extras directory of Celestia (i.e. /usr/share/celestia/extras). See https://en.wikibooks.org/wiki/Celestia/Add-Ons for more information. Once you have copied the files, simply start Celestia and hit Ctrl+F and search for Kerbin; once the planet is found and selected (upper left corner), hit G to focus and zoom to it.

Hi, I'm playing with 0.24 testing the contract mode with RemoteTech2 and encounter an array overrun bug. I sent a tiny probe to Duna, which is made of two parts: a lander and an orbiter. Since I guess it's a bad idea to land on Duna with an unfolded dish antenna which breaks in atmosphere, the orbiter will relay communications until the landing is done (at which point, the lander can use its own antenna). Both parts are equipped with a Communotron 88-88 (dish antenna aimed at Kerbin) and a Reflectron DP-10 (omnidirectionnal antenna to keep contact with the lander). I managed to get into Duna low orbit (first time, yay), so, considering the communication delay, I planed the landing: execute maneuver node to meet the ground activate chute, retract lander solar panels decouple lander execute maneuver node to get the orbiter back into orbit (the mass will be decreased but that's not really a problem) Decoupling goes fine (though, I should probably switch the controlling probe before in order to be able execute the second maneuver), but then, the lander cannot be controlled, even though: orbiter is still in communication with KSC both still have electricity left both probes are activated both DP-10 are activated When looking up in the debug console, I get the following errors repeated a varying amount of times, when switching back back to the orbiter: [Exception]: IndexOutOfRangeException: Array index is out of range. [Exception]: ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint Aborting Here are the SFS files (quicksave) before and after the decoupling (there is one more KSS-DUN probe orbiting the Sun that failed to enter Duna orbit and that I have not retrieved yet): http://sinon.org/ksp/dunaLow.sfs http://sinon.org/ksp/RTbugged.sfs And the craft file: http://sinon.org/ksp/KSS-DUN.craft Edit: The craft uses a part from the Engineer Redux mod and the error message appears after: [Log]: [FLIGHT GLOBALS]: Switching To Vessel KSS-DUN Probe ---------------------- [Log]: Camera Mode: AUTO [Log]: stage manager resuming... and before: [Log]: RemoteTech: ModuleRTAntenna: Find TRANSMITTER success. [Log]: RemoteTech: ModuleRTAntenna: Add TRANSMITTER success. [Log]: RemoteTech: ModuleRTAntennaPassive: Find TRANSMITTER success. [Log]: RemoteTech: ModuleRTAntennaPassive: Add TRANSMITTER success. [Log]: RemoteTech: ModuleRTAntenna: Find TRANSMITTER success. [Log]: RemoteTech: ModuleRTAntenna: Add TRANSMITTER success. Edit 2: After a few more tries, I identified that decoupling was sufficient to trigger the bug (no other order to either detached module) in dunaLow.sfs. Disabling all antennas does not make the error message disappears (new ones continue to appear when switching vessels). The Find/ADD TRANSMITTER messages are not displayed anymore and the errors still appear after: [Log]: stage manager resuming...

I'm just happy to have got an updated mod so quickly!

Same situation: cleaned RealChutes before replacing for the newer version, but the loader hangs at the legacy parts. It works fine when removing them all from the folder. I'm on Linux (64 bits). Edit: the last upload works fine \o/

Sorry, I don't get which point of my remark you are addressing. Could you develop?