toadicus

See! This is the whole problem; I never integrated the data logger module into my brain-code, so I have no idea what it does. Expect an overhaul soon.

When I do the rewrite, I'll add the ability for you to set a frequency so you can output just every 15 seconds. I'm also going to do asynchronous writes so you shouldn't lose several seconds if the game closes unexpectedly.

That extra character is a Microsoft-fail; Excel is importing the CSV as ASCII instead of UTF-8. To clean it up, instead of opening the csv directly in excel you can open a blank workbook and use the "Text Import Wizard" (under the Paste flyout). At the first dialog set the "File Origin" to "65001 : Unicode (UTF-8)", then click Next and at the second dialog change the Delimiter to Semicolon. I think I've sorted out why it's not printing the header every time. I'll fix it. EDIT: I decided to make the CSV files play more nicely with Excel, now using commas and properly quoting strings, also added the UTF-8 BOM, so Excel detects the character set automagically. I may wind up completely rewriting this module before I release next, because it's the only one that really never got any love and it's making me angry.

Hmm, does it not write a header? It's supposed to write a header. That header should be: "Mission Elapsed Time (s);" + "Altitude ASL (m);" + "Altitude above terrain (m);" + "Surface Latitude (°);" + "Surface Longitude (°);" + "Orbital Velocity (m/s);" + "Surface Velocity (m/s);" + "Vertical Speed (m/s);" + "Horizontal Speed (m/s);" + "Gee Force (gees);" + "Temperature (°C);" + "Gravity (m/s²);" + "Atmosphere Density (g/m³);" + "Downrange Distance (m);" + "\n" HTH! EDIT: By the way, I've (finally) made the next significant step forward towards scriptable panels, which should also result in scriptable logger columns. Don't have anything to share yet, but I'm about one syntax element away from moving from external testing to beginning an integration with VOID code.

I've taken a look at the deploy/retraction actions after transmission, and the new behavior of locking out control after the first transmission appears to be a stock behavior. As I mentioned a page or two ago, I'm going to add some manipulation to the antenna animations that will give users more freedom without allowing transmission from closed dishes, which will "fix" this issue in that it will supplant it entirely. I was going to roll that in to my slow progress on AR2, but I may move that up based on these findings.

VOID has been updated to version 0.15! As was mentioned previously, I finally talked with cybutek about adding a stage information window similar to KER's, and with his permission I have done so. This update adds the new Stage Information module, click-through protection, and miscellaneous background changes. CHANGELOG: v.0.15 [2014-11-15] * NEW MODULE! VOID_StageInfo is the long-awaited per-stage, per-body engineering data breakdown, available in the editor and in flight. * All windows should now be click-through resistant. Editor windows will now eschew the parts panel. * VOID_HUDAdvanced: Burn time calculations revised to be actually correct. * Completely rejiggered the way GUI styles are loaded. * VOID_Core: Changed the way "Kerbin" is fetched for the purposes of many reference calculations. This should be more tolerant of mods that change Kerbin's name.

Thanks for the report! I'm actually in the process of changing the way VOID loads styles completely, and this is a case that will be fixed by those changes.

I'll took in to the extension/retraction as soon as I get a chance (might be the weekend). In the meantime MeCripp's patch will probably give you all the freedom you could ask for as regards antenna deployment. Regarding the handbrake button, I'm locking out ALL_SHIP_CONTROLS, which is a huge blanket that shuts off everything and includes GROUPS_BRAKE, which should prevent the "brakes" action group from toggling. I'll tinker with this a bit this weekend as well, but if the brakes aren't actually locked out that is probably a Squad issue.

cantab, are you using any of the patches in the last few posts that stop the antenna from retracting after a transmission, especially any that include "isOneShot = true"? I play exclusively on Linux 64-bit and haven't seen any funniness with the retraction unless I'm using of those patches.

Wow, that's astonishingly thorough. Thanks for the info, Padishar! Learned a few new things today.

Huh, when did radial decouplers start crossfeeding? Well yeah, that's not OK. I've actually had a crossfeed tweak written for a long time; let me dust it off and make sure everything still works OK. EDIT: Playing with it some more, the crossfeed on radial decouplers seems like a bug. It works differently than normal crossfeed, e.g. if an engine is on a fuel tank on a radial decoupler on another fuel tank, you'd expect it to drain the host tank first, but it doesn't. In fact, it'll only feed across the decoupler if there is no fuel available on the "out" side of the decoupler; not just "enough fuel to run", but no fuel that applies to the engine. I had a couple units of liquid fuel, but no oxidizer, left in the outboard tank, and the engine wouldn't drain from the central tank unless I disabled the LiquidFuel flow control on the outboard tank. Weird stuff. Fortunately, my tweak appears to work just fine. I'll get it in the next release, but for now here's the standalone DLL: http://ksp.hawkbats.com/TweakableEverything/TweakableCrossFeed.dll To add the module to radial decouplers, open up TweakableDecouplers.cfg, and change the ModuleAnchoredDecoupler patch to look like this: @PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:FOR[TweakableEverything]:NEEDS[TweakableStaging] { MODULE { name = ModuleTweakableDecouple decouplerModuleName = ModuleAnchoredDecoupler } [b]MODULE { name = ModuleTweakableCrossFeed fuelCrossFeed = false }[/b] } Bolded region is new.

There's not currently a way for you to do that. As a part of what I'm trying to do for katateochi, I'm working on figuring out a more consistent way of rebuilding the underlying systems in use here that would also make it easier for me to add such options for you, but right now there's nothing you can do.

Spheniscine: Thanks for checking! I got my formula from deriving on the back of an envelope a while back. I wish I still had that envelope so I could see where I went wrong... but alas. Fix is committed; will be in the next release. Padishar: Thanks for the explanation!

Gaiiden, VOID is already using that equation (in a slightly different form) for its burn time calculation, see line 669 here. return initialMass / massFlow * (Math.Exp(deltaV * massFlow / thrust) - 1d); That will be wrong if VesselSimulator isn't figuring the current stage correctly, which is likely what is happening to Spheniscine. I haven't had a chance to tinker with it yet; I'll let you know what I find when I find it.

I never installed your files directly, but I did the same thing as your "cfg 1" in a separate MM patch and it worked fine for me. The antennas didn't retract, but that's to be expected when isOneShot = true.

MeCripp: I've never looked at AdvancedAnimator, so I'm not sure. I'll try to take a look when I get a chance. I'm guessing it completely replaces the ModuleAnimateGeneric with a more robust implementation of the same interfaces. Noio: Currently the icon turns yellow once you pass the "halfway point", or so. If I added something at that 95% range, would it actually be useful? It seems to me that by the time you're there you probably have seconds of game time to do what you need to do, but I confess that since I don't use the probe-disabling option myself, I don't have any direct experience. Just want to make sure that if I put something like this in, it gives people enough time to actually do something useful (like... point your solar panels at the sun so you don't run out of juice before you get your comms back?). Would a red exclamation point or something be good enough? If this really is a last-minute thing it seems like some kind of animated warning would be helpful, like flashing the icon or something. I'm not sure how well toolbar and applauncher support that kind of thing, but I'll look in to it.

That stage info window is and is not from KER. That's VOID's window (yet to be released), powered by KER (as are all of VOID's engineering data). I have finally had that long-awaited chat with cybutek. So, if VOID has the problem then so does KER. I'll see what I can do to narrow it down and then report it to cybutek & padishar myself.

Do these numbers look more realistic? Also included here: SPOILER ALERT!

Hullo there Iannic-ann-od! All of the variable-precision values (marked by a superscript "i") can have their magnitude shifted by left- or right-clicking on the value. One left click should change those values to m/s instead of mm/s, which should result in more-normal behavior in general. Precision settings in Surface & Atmosphere got weirded a little bit when I added Downrange Distance. Once you get things back to your liking they should stay that way.

It should be able to, in theory, I think, but in AntennaRange it can't. The long range antenna needs to be on the transmitter's side because the rangefinding radius is based on the part trying to transmit.

At this point no, range checks are only modeled in the "transmitter->receiver" direction, so generally from the active craft inward to Kerbin along the shortest relay path. So if you have a constellation of whip antennae in KSO, and a Medium Dish out at Minmus, you'll use the shorter range to KSO instead of the full range to Kerbin. This is because signal strength is proportional to the product of the gains of both antenna, in both directions. The whip antenna isn't as good at talking, but the medium dish is just as much better at listening as it is at talking. Of course, this means you should also be able to do the opposite, i.e. use a whip antenna out at Eeloo and pick it up with a big dish near Kerbin... but at this point you can't.

The LOS requirement is specifically to Kerbin, not to KSC. Requiring LOS to KSC seems needlessly punitive and unrealistic to me. Even the earliest Real Life spaceflights tracked their ships around the world using surface-based communications networks with varying international participation, navy ships, etc., to get messages back. Just because Squad hasn't modeled cities all over Kerbin doesn't mean the Kerbals can't do the same.

OK, so I've messed around with the various properties in MeCripp's file, and here's what I think I know: ModuleAnimateGeneric::isOneShot is a property of the antenna animation that locks the antenna open once it has been deployed the first time. This previously made the antennas "stick" after their first transmission, but that behavior appears to have been fixed by Squad. ModuleDataTransmitter::DeployFxModules is a property of the antenna transmitter that picks which animation module on the part it will move up and down when it transmits. ModuleDataTransmitter::ProgressFxModules is a property of the antenna transmitter that picks which animation module on the part it will do shiny light things with during transmission. Based on this and some quick laboratory testing, using either of the following patches should allow you to keep your antennae extended after transmission: @PART[*]:HAS[@MODULE[ModuleLimitedDataTransmitter],@MODULE[ModuleAnimateGeneric]]:AFTER[AntennaRange] { @MODULE[ModuleAnimateGeneric] { %isOneShot = true } } The patch above will lock your antenna in the deployed position after it is extended the first time, whether by the manual "Extend" button or by transmitting. It will never close again ever. @PART[*]:HAS[@MODULE[ModuleLimitedDataTransmitter],@MODULE[ModuleAnimateGeneric]]:AFTER[AntennaRange] { @MODULE[ModuleAnimateGeneric] { %isOneShot = false } @MODULE[ModuleLimitedDataTransmitter] { !DeployFxModules = DELETE } } This second patch will allow your antennae to transmit regardless of whether or not they are deployed. This means that you could transmit through a dish antenna that's completely folded up. It gives you more control over the position of the antennae, but relies on you to open them before use. Based on the above, I will probably add a "one shot" tweak to TweakableAnimateGeneric over in TweakableEverything. I will probably also supplant DeployFxModules in AntennaRange, so antennas can be operated freely, may deploy themselves on a transmission, and may not retract themselves when done. In the meantime, the patches above should give you a quick fix. Thanks for testing and finding this out, MeCripp!

Cross-posting from Kip's development thread:

Kip, I'm happy to move this discussion into the development thread as you prefer. Context for everyone else: This all sounds great. I think acquireRange should be enough. I'll turn it way down. Precise roll would be great too. Are you able make the magnet force perfect rotation if the orientation is close, or would you just need to have a viable range? I'll look into the roll stuff. I'm pretty sure Squad has provisions for it (there are fields in ModuleDockingNode for "captureMinRollDot" and "acquireMinRollDot"), but when I tried messing with those values many months ago nothing happened. Even if that's still the case, now that I have a plugin that is detecting all these things I can see about implementing it myself.