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.