toadicus

@lodestar @rasta013, thanks for following up on the editor info. It looks like Squad has removed the functionality that I previously used to update the module info that's displayed in the editor (confusingly, without removing the API ball that used to facilitate it). So, I'm pretty sure I'm going to need to take the long way 'round and make my own system to do so. @rasta013, thanks for fielding @Tandoori's question. You're correct in observing that "command centers" are not supported at this point, and that the intended way to control probes outside of direct contact with Kerbin is to disable "connection required for probe control". In general I feel like without ahead-of-time programming and signal lag, requiring connections for control is more punitive than realistic. In real life nobody is flying the Mars landers as they descend in real time; it's all programmed and executed by the computer. Here, since we don't have computers to execute programs for it, I figure we're basically roleplaying the robots executing commands when we're playing probes.

Well, "recently" as in "nearly a year ago". simpleRange has been a part of the config since 1.10 when proper geometrically-additive ranges were added. The README has a bit more info on what you need and tries to talk about why. EDIT: Also, thanks! I'm glad you're enjoying the mod. Yes, EVAManager is a dependency. Technically it's optional -- most of the mod will work without it -- but it's required for getting radios into Kerbals' EVA suits. I know a number of people have written some -- and it sounds like @rasta013 and @Tantalus are writing more now -- but I don't maintain any myself. I'm trying to encourage people to put links to their patches here: https://github.com/toadicus/AntennaRange/wiki/Compatibility-Patches. All you need is a registered github account; no working knowledge of fancy version control schemes required.

@eddiew, last I checked OPM distributes a patch that increases the range of all the stock parts for use with AntennaRange. @lodestar, thanks for the report! I'll look in to it.

@Tantalus, MaxPowerFactor affects the maximum range of antennas (along with nominalRange) via the relationship MaximumRange = sqrt(MaxPowerFactor) * nominalRange. Note that in the default mode "maximum range" is a misleading name; that's actually the maximum range between two antennas of the same type. Different targets (various antenna types, Kerbin at different levels, etc.) affect the actual effective maximum range of a given link via the relationship MaxLinkDistance = sqrt(relay1.maximumRange * relay2.maximumRange). EDIT: MaxDataFactor provides a "speed up" bonus to transmission rates when your effective link is inside the nominal link range (which is NominalLinkDistance = sqrt(relay1.nominalRange * relay2.nominalRange)). There's more info in the README, here: https://github.com/toadicus/AntennaRange/blob/master/README.md Hope that helps! When you get something that you like, feel free to contribute it to the community via the compatibility patches page: https://github.com/toadicus/AntennaRange/wiki/Compatibility-Patches. @eddiew, the answer to your question is probably a lot the same as the answer to Tantalus' question: range requirements depend on both ends of the link. A Comm. 16 has a maximum link distance to a level 2 Tracking Station that's just outside Minmus' orbit, so assuming that describes your situation, the behaviour you describe is expected. Here's a table that shows the maximum link ranges of each antenna relative to the others, and to each of the Kerbin upgrade levels: To↓ From→ Comm. 16 Comms DTS HG-55 Comm. 88-88 EVA Comm. 16 <Kerbin Orbit Kerbisynchronous Orbit Kerbin->Mun Kerbin->Mun <Kerbin Orbit Comms DTS Kerbisynchronous Orbit Jool's Moons Jool's Moons Jool's Moons Kerbisynchronous Orbit HG-55 Kerbin->Mun Jool's Moons Jool's Moons Kerbin->Duna @ Transfer Kerbisynchronous Orbit Comm. 88-88 Kerbin->Mun Jool's Moons Kerbin->Duna @ Transfer Kerbin->Duna Kerbisynchronous Orbit KSC1 Low Kerbin Orbit Kerbin->Minmus Kerbin SOI Kerbin SOI <Kerbin Orbit KSC2 Kerbin->Minmus Kerbin->Duna Kerbin->Duna Kerbin->Jool Kerbin->Mun KSC3 Kerbin SOI Kerbin->Jool Kerbin->Eeloo Kerbin->Eeloo Kerbin->Minmus

Cheers. For those interested, the bug was actually due to the positions being set in FixedUpdate, which happens when physics calculations are done, instead of Update, which happens when GUI frames are rendered. In most configurations there are more of the latter, so it appeared to lag behind (even though it was technically keeping up).

QuantumStruts has been updated to version 1.6! This update brings KSP 1.1 compatibility and squashes the "lagging strut" bug.

I've found what looks like the right way to use the new UI hide/show events, and have it implemented internally. New version will go up soon.

Thanks @Renegrade, I'll look in to that. I have never done anything with F2 handling at all before, so it's pretty certainly a change on Squad's end that I'll have to adapt to.

It will be, and I have a version that compiles, but I need to test it a bit and want to try and hunt down the "high speed activation" bug that's been reported. Stay tuned; hopefully something this weekend.

I have to update my upload scripts for SpaceDock to make CKAN easy. That's going to lag behind a couple of days.

TweakableEverything has been updated to version 1.15! This brings compatibility with KSP 1.1 and very little else. Squad is continuing their persistent integration of many of our tweaks, so pretty much all the changes the time are removals! Let me know if there's something missing that you want to see. CHANGELOG * KSP 1.1 Compatibility * Retired TweakableControlSurfaces: it's stock now. * Retired TweakableDecouplers: it's stock now. * Retired TweakableRCS: it's stock now.

VOID has been updated to version 0.19! This version brings compatibility with KSP 1.1 and very little else. I hope to get back to work on the scripted panels soon! CHANGELOG: v.0.19 [2016-04-20] * KSP 1.1 Compatibility * Minor optimizations in thrust offset and intake air calcs.

AntennaRange has been updated to version 1.11! This version includes compatibility KSP 1.1 and improved network resolution based on the total chain cost. CHANGELOG: v.1.11 [2016-04-20] * KSP 1.1 Compatibility * Network resolution now picks relay targets based on cheapest total cost (in EC/MiT) to Kerbin. * New icons by HalcyonHush! * Communotron 16 moved to starting tech * Relays will now recalculate their maximum range periodically to account for changes to the Additive Ranges setting. * Added toggle to disable the use of the Toolbar mod even when it is detected. * Removed some extraneous debugging messages.

@Padishar I have two things that check through most of the ship (both looking at engines for stuff), one does intake air status and one does thrust offset (basically measures by how much your thrust vector "misses" the COM). They're separate loops, and one is old and uses a Linq query first so it can definitely be optimized a bit, but neither of these are doing anything new.

Is this FPS hit only observed when VOID is installed and active? If so, can you make it go away by disabling any of the VOID modules (perhaps especially the HUD or advanced HUD)?

It's not in the screenshots because the screenshots predate the "advanced hud". I should probably update those...

The short answer to "why not just use the 88-88 all the time?" is "no reason, go for it." Because Squad only gave us three antennas (originally) and I didn't want to include additional parts, I was pretty limited in my options for trying to balance them. If you're doing short range stuff (in Kerbin's SOI) and have a well-upgraded tracking station, the Comm. 16 will be a hair lighter and cheaper. If you're doing ultra-light landers on your multi-moon Jool mission, the Comm. 16 will be lighter. But, because of the really, really disparate ranges in the game and the way transmission costs scale, it's pretty hard to avoid the 88-88 being an "I win" button. It has to let you finish out the game without adding a burdensome taxation mechanic (like requiring a relay constellation outside Duna's orbit or something), and that means it'll always be better forever. I wouldn't mind if the 88-88 were a bit heavier, to make its use on small probes a tougher decision. But, I don't really want to rebalance the mass on these parts because then spacecraft might operate very differently with and without AntennaRange, which I don't really want (a part of my design is that AntennaRange feel "optional" and removable, so that if you install it in the middle of a game you can expect things to work well, and so for uninstalling it). So, it is what it is. I guess I could put a config option in there to increase the 88-88 mass by a factor of 10?

Just uploaded a new version that doesn't check for AsteroidDay before applying the HighGainAntenna patch, which should resolve the issue.

Are you using custom antennas, maybe? Can you try something really simple, just a capsule with a stock antenna (not the High Gain)? I can't duplicate these issues in my clean install.

The log shows that AntennaRange's patches are correctly applied, and I see later that a module is being loaded an an "Archer Bodkin Mk 2". Can you try to get me some more information about what's going on? What kind of save are you using? What sort of use cases are you testing?

If you still have the issue go ahead and remove it entirely. PlanetShine is definitely causing some consternation during ModuleManager's startups, so if you have the problem with 0.2.5 you should probably take this over to Valerian.

Try removing PlanetShine; ModuleManager is crashing during its startup because PlanetShine can't be loaded properly. It looks like Valerian has a version that says it works (0.2.5); if you try it again make sure you're using that version.

I just re-uploaded a fresh binary of a build and patch that are definitely working for me (same link). Please make sure you only have one version of ModuleManager (2.6.21 or newer) and that you do not have RemoteTech or any libraries or folders named "RemoteTech" in GameData. If all those are true and you're still having issues, please get me a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log).

@NoShotz, I noticed I've accidentally got two copies of ModuleManager in the archives. Can you remove version 2.6.13 and let me know if the same thing happens again?

I've got a build that's compatible with KSP 1.1 available here: [zip] [tar.gz] [tar.xz] I haven't done a lot of functional testing, so please get bug reports with logs to me if you encounter any issues! Do try to be sure you're not reporting a KSP bug, though.