thunder175

I noticed that the plugin generates files for each uniquely named launcher. However, if I have sequence numbers for my launches then each individual launch gets an individual named file with a single success or fail entry. Does that matter to the mod when it comes to refining launch setting estimates? If it does, would it be possible to add the ability to log an entire class of launchers instead? For example Sarnus *, instead of individual entries for Sarnus 1,2,3,4...

@akronOpened up my career save on 1.2.2 tonight after upgrading to 0.15RC from Github, and my probe core on its way to Mun all the sudden has what looks like a phantom decoupler following it around! I'm guessing its a model glitch since it acts like its attached when I spin the craft around. First time I've ever seen this after using your mods for a long time.

Just a very minor request. For the Dark Side calc altitude input box, could you expand the width to make it easier to read five digit numbers? I'm running Sigma Dimensions at 6.4x rescaling so my altitudes are much higher.

@nightingale Following up on my previous post since it may be a non-issue for you. I uninstalled CC 1.11.1 and was still getting the UnityGUI exceptions although they were labeled 'unknown' now. Apparently they are being generated by the dev version of KCT: http://forum.kerbalspaceprogram.com/index.php?/topic/83342-105-kerbal-construction-time-132-mar-7-2016-unrapid-planned-assembly/&do=findComment&comment=2550508

@nightingale Just installed 1.1.2 with the updated version of MM (2.6.24) and Exception Detector generating massive amounts of faults, claiming it to be ContractConfigurator. KSP.log file is showing me this: [EXC 10:11:24.646] MissingMethodException: Method not found: 'PopupDialog.SpawnPopupDialog'. UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)

I'm confused as to your network setup. You have a WiFi access point or router currently servicing the Android devices? Your main machine is on the same LAN as the Android devices or is it not on the LAN at all? What are the IP addresses of everything? If your main computer and Android devices are on a LAN right now with a 192.168.x.x range, that means they are getting addresses from a DHCP server on your network (presumably your router). So which device isn't? Or is your intent for a completely isolated network? You also mention Bluetooth. Simply connected via Bluetooth does nothing unless you are also setting it up to run as PAN (Personal Area Network).

No you don't need another copy of KSP installed on the remote computer/device. Telemachus starts a basic web server to host its pages on the local machine running KSP. And by "Ethernet cable" are you wired into a switch/hub or connecting directly between two computers? Either way you'll need to find the IP address. If between two devices directly and/or with no DHCP server on the LAN, your local IP address will be an APIPA address between 169.254.0.1 and 169.254.255.254, with a /16 subnet mask.

@Sigma88 Following up from my post a little bit ago, I rebooted into Linux, changed my SD settings, and fired up 1.0.5. SD created new cache files for the updated settings. Then rebooted back into Windows, copied the new cached content to my 1.1 folder. I'm currently in the tracking station and all looks just fine. So if I was a betting man I'd say maybe something wrong with the generation of the cache files?

I can confirm @davidy12 report. However, I did have success when I copied my entire Sigma Dimensions folder from my Linux 1.0.5 installation and ran it as is, no changes from 3.2x/6.4x. The catch is that I did copy the cache folder along with it. When I changed the settings to run 6.4x pure and the game generated new SD cache files, I got the black screen as described. EDIT: Took a screen shot of 1.1 running SD at 3.2x/6.4, with EVE and SVE installed.

Based on your description, your planned method will be applicable to resacling the entire solar system via Sigma Dimensions, 64K, RO/RSS.Is that a correct statement?

Did the formal release of 1.1 take anyone else by surprise? I stay away from the forums for a few hours and almost spit my drink out when check back and I saw the release notice. Immediately came here looking for a Kopernicus and SD update. I mean you had a few hours right? So I played stock scaling with stock parts... and that lasted all of 30 minutes. I'm serious, the game is unplayable for me now without rescaling with SD. Yet another round of public kudos to @Sigma88 for his efforts.

To access the Telemachus page, you enter the IP address and Telemachus port number of the KSP computer. I tested this the other day using an Android tablet running Chrome. In my case, I opened up Chrome and entered 192.168.25.58:8085 . Your individual computer IP address on your LAN will vary, however almost all consumer grade routers default to the 192.168.1.x subnet, so look for an address similar to that. You MUST also enter the port number following the address with a colon, as Telemachus does not use standard HTTP port 80. If you forget the port number following the IP address, it will timeout and give the impression its not working. You must tell your browser to use port 8085 to find the web server on your KSP computer by entering the additional info after the fourth octet of the IP address. If all goes well, you'll hit the landing page where you can go to the various displays.

This is blowing my mind as far as which way to go and makes me wish I paid more attention in math class long ago. But let me try to run the numbers for a 3.2x resize, 6.4x rescale based on the math you provided.This may help someone else in the future. For KSO: 3463.33*(4*3.2)^(2/3) = 18951.08 - (600km*3.2) = 17031.08km altitude for KSO at 3.2x resize. SOC is saying 17037.395, so its in the ballpark For RT multiplier: (6.4*4)^(2/3) = 8.686 for standard model, / 2 = 4.343 for root model Using RT multiplier at 4.343, a DP-10 will close links with a KR-7 at 31.3Mm since: DP-10 range = 0.5Mm * 4.343 = 2.172Mm KR-7 range = 90Mm * 4.343 = 390.87Mm. Link closure = MIN(2.172,390.87)+SQRT(2.172*390.87) = 31.305Mm. Stock root model per RT table for DP-10 <--> KR-7 = 3600km That look about right? EDIT: Been thinking about this the past little while and I think I may "promote" my system to full 6.4x. Just seems the 3.2/6.4 split a la the 365 mod is causing more headaches on the math than its worth.

Ok I think I'm not fully understanding the changes from previous dev versions, sorry. The older dev version RT patch file is no longer included? Talking about the file that changes all antenna configs individually (assuming)? So in all newer dev versions the only way to change antenna range is via the RT settings multiplier? In other words, I install new dev version and leave RT alone, I'll have a much bigger scaled system with stock scaled antenna ranges? I guess I'm just trying to figure out what is the appropriate range given a specific rescale without doing any antenna theory math. If for no other reason than for the record on the forums, here is a few scenarios with the AIES CL-1. CL-1 Range, Stock scale system = 9Mm (CL-1 Range (9Mm)) * RT multiplier (0.5)) = 4.5Mm (CL-1 Range (9Mm)) * RT multiplier (0.5)) * SD Rescale (3.2x) = 14.4Mm (CL-1 Range (9Mm)) * RT multiplier (0.5)) * SD Rescale (6.4x) = 28.8Mm <-- My current setup with older dev version of SD (CL-1 Range (9Mm)) * RT multiplier (1.6)) = 14.4Mm (CL-1 Range (9Mm)) * RT multiplier (3.2)) = 28.8Mm (CL-1 Range (9Mm)) * RT multiplier (6.4)) = 57.6Mm I hope I have that all correct since I'm doing this from memory while at work. Given the above, are you saying I am getting too much performance from my antenna right now when using the root model of RT? Again, my specific instance of KSP/SD is using a 3.2x/6.4x split. EDIT: I just did some math in Excel using the above and RT's root formula. In my scenario, between two CL-1's the root model math is 858.24!! Is that right?? Clearly I'm doing this all wrong. This is all making me want to switch back to standard mode to be honest. EDIT2: Fixed the problem with my math and am now getting reasonable link closure ranges in Excel.

@Sigma88 Thanks for the great work on this. So if you have abandoned changes for RT, is it safe to use the newer dev versions again for those using root mode? In all honesty I feel fine with the way it is. I think the antenna ranges are still scaling properly without changing the RT settings config IMHO. The only real problem I am seeing is that antennas that may be on the edge for KEO in stock scaling won't rescale correctly and may not reach a larger stable KEO. But that is easily correctable with another part specific patch or just use a bigger dish. For example, the AIES CL-1 is perfect for low power KEO work. It defaults to 9Mm range. With my previously mentioned root and multiplier settings, that range gets halved, then multiplied by SD's setting of 6.4 for a max range of 28.8Mm, well within KEO for a 3.2x Kerbin. The DTS-1 using the same math is getting me out to 288Mm, good enough to close a link to Minmus. Actually just had another thought. I may be feeling its fine since I am running 3.2x/6.4x. What is KEO for a straight up 6.4x system? 3.2x KEO is 17037km. I'm not doing anything really long range yet beyond Kerbin SOI, so again your mileage may vary. I also tweaked the RT settings config file by adding ground stations. The biggest change here of note to users in this thread is dramatically increasing the range of the KSC dish. When using root mode it will close a link even beyond the max range of a given antenna. This is both good and bad IMHO. I also added a bunch of tier 2 and tier 3 ground station sites to support launches and limited comm's. Some of these are crucial and allow a limited field of launch azimuths from KSC until the launch of larger communication relay birds. Sites were selected to coincide with the KerbinSide ground station locations that had their lat/lon listed in their config file (since I was lazy and unimaginative). I can post my config file if anyone is interested. Anyways, sorry to turn this into an RT discussion instead of the pure awesomeness that is SD. I can't even imagine ever going back to stock after SD...

Will all current AIES parts break with 1.1? Even just the probe cores? If this is the case, I implore @akron to make the spiritual successor. I can't live without the AIES busses and parts. I know its out of your current scope, if you made some basic parts share the size, shape, look, and dimensions of the current AIES cores (especially the Explon's and square tank addon) I as well as many on here would be grateful.

Just curious if it would be possible to implement radio bands on antennas to future versions RT? Where antennas can only communicate with in-band receivers and networks? It can be simplified for the sake of the community to do just UHF, EHF, and SHF bands instead of S, C, Ku, etc. Transceiver band would be selectable in the VAB/SPH or definable in a part file. Omni's should be more or less stuck in the UHF band, which would prevent them from closing links with long range dishes. Color coding in the settings config file could be added for the map display to show your different networks. Would help to segment communication networks and encourage antenna diversity and cross banding solutions on probes.

Yes your pic is what I'm talking about. Only things on my modded game that should be changing anything is RealHeat. So not sure if that is my problem or not, or if I even have a problem. I just noticed that RO/RSS changes some of the physics.cfg settings including aeroFX which is why I was asking. I can live with it since it doesn't seem that its actually causing any additional heating, and even FAR data is showing almost no atmosphere and drag. Ok great. Again, just wanted to make sure resetting the global RT multiplier wouldn't throw out the recommended setting when running root/additive modes. Because currently RT takes the multiplier (0.5 in my case) and applies that to the existing antenna range. So a 90Mm ranged antenna is listed at 45Mm in stock. And then the previous SD multiplier was applied, which in my case is 6.4x, raising the max antenna range listed to 288Mm with other math associated with the root model applied by RT to actually close the link.

Certainly! Glad I could help and hope someone can use it. CLS works great especially when coupled with Ship Manifest. I had to update the above post since I realized when I got in the game I forgot about the lander's. So please grab that instead. I wasn't sure about the shuttle fuselage though. I know you said you are pulling it from the next release due to U5 reasons. I'm not sure if MM will start throwing exceptions or anything trying to apply a patch to a missing part since I'm new to tweaking the configs, so I just left it out for right now.

Dunno if anyone else used Connected Living Space, but I saw SSTU didn't have a config file for it. I had to temporarily disable it to move my Kerbals around my SSTU craft. Anyways, I made a quick config file for it. I'm very new to any form of KSP MM editing so someone please verify my work. Hope this works and helps someone on here. As always, no warranty expressed or implied and your mileage may vary. @PART[SSTU_ShipCore_A_CM]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU_ShipCore_A_CMX]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU-SC-B-CM]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU-SC-B-CMX]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU-SC-C-OM]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU-SC-C-DM]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU_LanderCore_LC2-POD]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU_LanderCore_LC3-POD]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU_LanderCore_LC5-POD]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU-SC-GEN-DP-0P]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SSTU-SC-GEN-DP-1P]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } }

@Sigma88 Acknowledge all. Just a few things. First I looked at the RO physics.cfg file and he makes tweaks to the AeroFX section. Looks like he changes the variables for a 10x RSS system. Problem is when I applied the RO AeroFX changes on my 3.2x Kerbin, I was getting virtually no atmospheric visual effects at all even on reentry. So clearly something needs to be tweaked for larger than stock, but smaller than 10x systems in regards to the aeroFX settings. I defer to your discussions with the other developers. Second, on the math. Thanks! I think I did it right based on the equation you gave and I came out to 36163.584. When I used that in the web app it was giving me numbers very close to what I was seeing in game, so I guess I got that right. Third and most importantly on the RT multiplier. Great work but I don't think that is what we want if we are using the root model instead of standard described in the settings addendum (https://remotetechnologiesgroup.github.io/RemoteTech/guide/settings/). Reason is that a 0.5 mulitiplier is recommended by the developer if using the root model. He gives the math equation used, and I'd have to run the numbers but I think if you apply a patch changing the value of the global RT antenna multiplier it would give drastically increased ranges when using the root model. Those using standard modeling will probably be OK since it is defaulted to 1 and is basically an either can talk-can't talk scenario based on the max effective range of a given antenna. Can you double-check my thinking on this?

What's the significance of the change? Was there a problem with the last dev version that this is fixing? I haven't noticed much in the way of heating issues although I am using RealHeat. But maybe that is the problem? On a side note, can you give us some recommended settings that you use or maybe even a physics.cfg patch like RO for the AeroFX on a scaled up Kerbin? Tired of my rocket glowing red and eating FPS (although no heating, just the FX) at 40km-60km on a 1.2857 multiplied atmosphere (90km atmospheric boundary). I'm hesitant to eject my fairings when I'm getting the FX even though FAR data is saying there is virtual no density and almost no drag, so I'm probably holding on to dead weight longer than I need to. Or do I just need to throttle back on my gravity turn? On another side note, still loving 3.2x rescale and 6.4x resize. I even removed SMURFF since I didn't feel like fiddling with the multiplier value since 0.5 felt like overkill at 3.2x. At 3.2x, its taking just shy of 5700m/s to a 185km orbit. MJ is working perfectly with a 120km final turn altitude. I'm getting nice continuous orbital insertion burns without requiring engine restarts to get the Pe above the atmosphere. 6.4x resize is awesome with RT transmission delays. Lastly, does anyone know how to calculate μ(km3s-2) for rescaled planets? I'm trying to use the RemoteTech planner web app (https://ryohpops.github.io/kspRemoteTechPlanner/) and am inputting the newly sized planets as user add-ons, but without the standard gravity parameter it breaks most of the pages functionality. I am terrible at the math and am unsure of what to put in that space.

Hope I didn't suggest anything bad or out of place...

I too wouldn't mind seeing some new GPS block II and block III antenna since the Figaro GNSS system hasn't been updated in a while, especially if you can make it compatible with MCE to replace or augment their navigation core. I also would love to see a laser communication 'dish antenna' for use with RemoteTech for long range, high bandwidth applications (https://en.wikipedia.org/wiki/Laser_communication_in_space).

If someone has time, a quick FAR and RealChute MM config file for the chutes would be greatly appreciated for those who run those mods. I found out the hard way late last night when my pod burned in at 250m/s despite a fully deployed chute.