toadicus

Yes, that's just how the logger works now. Because, really, the logger isn't for people who want a bunch of pretty numbers: the HUD does that, and it's still got °E, etc. The logger is for people who want a bunch of raw data for a specific purpose -- like you -- and raw numbers are way better for that than prettily-formatted numbers. If people really want pretty numbers in their spreadsheet they can use a formula for it.

Like this? https://imgrush.com/gumMG9bhcAO7.png Here's a re-upload for you, no new version number: [zip] [tar.gz] [tar.xz]

VOID has been updated to version 0.18.3! This version has no new features of any kind, but has a bunch of general code improvements on the back end that should improve performance. It also supports the new ToadicusTools I just uploaded to CKAN... no idea if 0.18.2 will or not. CHANGELOG: v.0.18.3 [2015-05-18] * Behind-the-scenes fixes to improve performance.

New dev build up! [zip] [tar.gz] [tar.xz] This should fix the non-transmission bug, which was a weird interaction with one of Squad's new overloads. It also fixes line-drawing and connectivity for users without the Toolbar mod, especially in map view.

TweakableEverything has been updated to version 1.11! This version fixes FAR compatibility in the editor, improves TweakableStaging performance and behavior, and adds an in-flight torque limiter to TweakableReactionWheels. Known issues: engine fairings still don't reappear when re-enabled; still haven't looked at fairing adjustments yet. CHANGELOG: v.1.11 [2015-05-18] * Fixed all modules using animations (TweakableAnimateGeneric, TweakableLadders, TweakableSolarPanels, TweakableDockingNode) to avoid falsely appearing to have changed from frame to frame as observed by mods like FAR. * Behind-the-scenes code changes to improve performance. * Added new dependency on KSPAPIEL, a stripped-down version of KSPAPIExtensions, to work around a Squad bug involving tweakable slider. * TweakableStaging: Removed a bug discovered during testing wherein the staging list would not sort properly during startup when normally-staged parts had staging disabled. * TweakableStaging: Major revisions to improve performance. * TweakableReactionWheels: Added a torque limiter to help alleviate twitch in flight.

The Squad bug with FloatRange tweakables has actually been present since at least 0.25 and probably since tweakables were introduced. It's just become more of an issue lately as more mods have started using and doing expensive things with onEditorShipModified. I've reported it to Squad; hopefully it gets sorted in an upcoming version. If not, the new slim version of KSPAPIExtensions (KSPAPIEL) works around the issue nicely, offers some extra functionality, and can be made available for general adoption. My animation bug has probably also always been present, but it was just exposed recently by nuFAR. My animation code never didn't work, even in recent versions; it just did things in a funky way that led to confusion on the part of interactions with mods that know what animations are supposed to be be in given states.

There were actually two separate issues. The first was the UI_FloatRange issue where tweakables would spam the onEditorShipModified event every Update when they were open, leading to hundreds of requests for rebuilds per second. This was affecting interactions with a lot of mods, especially mods that didn't use rate limiting on the event requests (FAR did, but we still made it rebuild every half second or so). This is a Squad bug; the tweakables should not be triggering event calls when nothing has changed. I've worked around this issue by introducing a dependency on a stripped-down version of KSPAPIExtensions. The second issue was an animation issue that would have been affecting TweakableAnimateGeneric and TweakableLadders, where I was inadvertently putting animations into an inconsistent state. FAR monitors animations every Update, and when it detects a change it requests a voxel rebuild. Because the animations were inconsistent, FAR flagged them as changed every time it checked, leading to the same problem as above. I've resolved this issue by rewriting my animation handling code from the ground up. I should have a release tonight (UTC-7).

mythbusters844, thanks for the report! That pointed me in the right direction and with a bit of collaboration from ferram4 I found the problem. The good news is this means we should have a definitive fix soon. The bad news is this means I didn't release yesterday.

Well, that's what I get for not testing the "release" mode build; I had activated most of the debug code, but a few leftover bits where still around causing trouble. [zip] [tar.gz] [tar.xz]

New dev build: [zip] [tar.gz] [tar.xz] This fixes a circular relay chain issue that was probably the biggest performance issue, and has a whole mess of other general improvements. Let me know how it goes!

smjjames, I'm confused by your last post, then. You're welcome, Beowulf! I'm glad you're enjoying it! hbkmog, that's the result of a Squad bug (we've been discussing it for the last 4-5 pages). I'm working around it with a new dependency; should have a release out this weekend.

helaeon, I've found the issue and believe it to be fixed. Should have a release this weekend. smjjames, I dare not speculate. The long load times I was causing before with TweakableStagingToggle were a result of queuing too many Staging sorts and nothing to do with the event spam. TweakScale also uses KSPAPIExtensions, which as far as I can tell don't suffer from the event spam issues. If you're having slowdowns with TweakScale you should talk to pellinor. In order to get rid of bug reports about the event spam and avoid making life harder for other modders, I'm going to "temporarily" depend on KSPAPIExtensions -- or some subset thereof -- so I can control how often onEditorShipModified gets called. When/if Squad fixes their bug (I've reported it formally now), I'll switch back to their tools and remove the dependency. Expect to see some or all of KSPAPIExtensions in the next TE release.

TweakScale will prompt onEditorShipModified calls second-hand through its use of KSPAPIExtensions. I'm not familiar enough with how those work to know if they exhibit the same problem; a quick read of the code suggests it might. Edit: Some testing suggests this may not be the case. The problem with the stock FloatRange tweakables in my first post is definitely still the case.

ferram4; TweakableEverything doesn't actually rescale parts, or do anything intentionally to trigger any event calls. That said, TweakableEverything (and any other mod that uses Squad's FloatRange tweakables) exposes a Squad bug relating to tweakables and excessive calls to onEditorShipModified, which I've generally identified to behave thus: This means that any time a FloatRange tweakable (something I've added, or a Squad stock tweakable) is active and set to a value where the slider can't sit precisely on a stepIncrement, Squad's code spams onEditorShipModified. This is mostly present for tweakables that default to a value other than 100% or 0%, which in general Squad doesn't have very many of, so this is mostly exposed when mod parts or tweakables are used. Does that seem like a plausible explanation for what's going on in FaterW's report? I'll consider rewriting UI_FloatRange entirely if that's what it takes to keep TweakableEverything and FAR playing more-or-less nicely. Thoughts?

smunisto, thanks. Your machine is definitely more capable than my laptop, though I am running in DirectX mode here. I'll try it again in OpenGL mode, as well. EDIT 3: OpenGL mode had a very slight slowdown from my 60 fps cap, to about 57 fps. ManuxKerb, did that correct itself with zooming and camera adjustment, or did it stay super broken? If the latter, can you get me a debug 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) after a run of the game that exhibits the problem? Thanks! EDIT: I think I duplicated your issue ManuxKerb; did it happen specifically after decoupling or undocking a craft, or something similar? EDIT 2: Well... maybe. It did happen to me, but it wasn't quite as consistent as I thought it might be...

smjjames, that's probably the same issue we've been discussing lately. This mod doesn't produce, show, or use any information from the fuel tweakables. Again, Squad's bug is exacerbated by mods that use onEditorShipChanged without rate limiting it. helaeon, does the issue go away if you uninstall AGX? I'm going to guess "no", because SirDiazo is actually handling is error, he just prints the whole thing out for verbosity. I'm a little more worried about the argument out of range during Staging.sortIcons; it's somewhat possible that we're causing that. I'll look in to it. EDIT: For those interested, I've reached out to ferram4 on the forums here: http://forum.kerbalspaceprogram.com/threads/20451?p=1939223&viewfull=1#post1939223. I may also follow up in other channels.

New dev build up: [zip] [tar.gz] [tar.xz] Still using the same method for drawing lines, but I should be using fewer objects to do so now, which may have a performance increase. I also tweaked a bunch of other stuff around, and fixed the display issue for out-of-range probes that dudecon noticed. Let me know if it helps performance at all... on my laptop, there's no performance hit at all (for an admittedly-small set of relays); the game stays frame-limited at 60 fps per my choice in KSP settings. If you still have performance issues, could you tell share some of your hardware specs with me so I can guess at whether this is a graphics issue (I've read that the method I'm using for drawing lines has poor performance) or a CPU issue (in large networks there is a lot of work to do to resolve connectivity for every relay). Also, does it slow things down in the general sense (i.e. slow, but frame rate feels "even") or does it stutter (i.e. sometimes there are long waits between frames)? Thanks!

The only weirdness I see is that OwKSP's post got the thread title for its subtitle, instead of mine. No big deal, though. Thanks for the assistance!

KerbMav, that's a ModuleManager patch, which only applies to configs already in the database. KerbalEVA parts are not in the database as such, and certainly not in the way you're accessing them; that patch would change an EVA_MODULE config for use by EVAManager before EVAManager processes it, which would be useful if what you were trying to do is change an EVAManager config in response to the existence of other mods, etc. Since you're trying to change a module already on the EVA Kerbal parts, and not patch a patch, you need to use the (admittedly entirely undocumented) EVAManager syntax. This is intentionally separate from ModuleManager syntax to avoid conflicts. That said... I'm not actually sure we can do what you want, because I don't have HAS matching or indexing yet, and the EVA part has two ModuleScienceExperiment modules on it. I didn't need those things for what I was doing, so I just haven't written them yet! For the sake of interest, here's basically what you would do, and might get lucky: EDIT_EVA_MODULE[ModuleScienceExperiment] { xmitDataScalar = 0 } If you're not lucky, that would change xmitDataScalar for EVA reports instead. At this point, I don't have operators to distinguish between editing an existing field or adding a new one like MM does, so you don't need "@" or "%". I'm probably not ever going to do it in quite the same way, both because for what we're doing here, in general, it shouldn't be necessary, and because I want to try to keep EVA_MODULE nodes generally patchable by ModuleManager itself. I'll probably require indexing for things like that, and delimit indexing differently.

I have created a new thread to discuss my sub-mod EVAManager, here: http://forum.kerbalspaceprogram.com/threads/121146 I'd like to migrate some recent discussion on the topic from my AntennaRange thread (http://forum.kerbalspaceprogram.com/threads/56440) to the new EVAManager thread. Please move these posts to the EVAManager thread: http://forum.kerbalspaceprogram.com/threads/56440-1-0-AntennaRange-1-8-Enforce-and-Encourage-Antenna-Diversity?p=1934257&viewfull=1#post1934257 http://forum.kerbalspaceprogram.com/threads/56440-1-0-AntennaRange-1-8-Enforce-and-Encourage-Antenna-Diversity?p=1934270&viewfull=1#post1934270 http://forum.kerbalspaceprogram.com/threads/56440-1-0-AntennaRange-1-8-Enforce-and-Encourage-Antenna-Diversity?p=1934347&viewfull=1#post1934347 http://forum.kerbalspaceprogram.com/threads/56440-1-0-AntennaRange-1-8-Enforce-and-Encourage-Antenna-Diversity?p=1934469&viewfull=1#post1934469 http://forum.kerbalspaceprogram.com/threads/56440-1-0-AntennaRange-1-8-Enforce-and-Encourage-Antenna-Diversity?p=1936088&viewfull=1#post1936088 Thanks! Also, feel free to delete my errant thread posted on this same subject: http://forum.kerbalspaceprogram.com/threads/121148

I'll try and duplicate that tonight. In the meantime, can you post your debug 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) following a run that exhibits the problem? I like both those mods, too. I'll try to talk to ferram4 and see if he can narrow down what's happening. I'm not actually changing the scale of anything, so my guess is this is related to the tweakable issue we've been talking about lately. Hopefully we can find a way to work around it. Is there a reason you think that is an issue with this mod? Otherwise, RealChute's thread is over here.

I actually haven't tested out of range relays at all, only occluded ones. In theory out of range relays should show a red line to the least out-of-range target; a relay if there's one closer than Kerbin, Kerbin if not. Occluded relays do exhibit that behavior, and will e.g. show a red line to a nearby, but blocked, relay when LOS is obscured and nothing better is available. Thanks for all the reports! I am looking in to better options for drawing the lines; it looks like LineRenderers are pretty heavy performance-wise. I might also try to get network resolution done in another thread... that's a Big Deal, though. Stay tuned. EVAManager discussion relocated over here: http://forum.kerbalspaceprogram.com/threads/121146

I'm not sure what all transforms exist on EVA Kerbals, so writing that might be tough. If you find one, though, it should work.

EVAManager provides a config-based interface for adding, removing, and modifying PartModules and PartResources for EVA Kerbals. Also provided is a basic mechanism for "filling" resources from the origin pod, allowing for proper conservation across missions. Someday soon I'll improve this thread to be more like a release thread. In the meantime, it's just a conversation moved over from another thread. My first post on the subject: EVAManager is chiefly available within the TweakableEverything and AntennaRange archives, as those are the only official uses I am aware of. If you'd like it for your own use, you can also get it at the links below. SpaceDock: [zip] Not A SpaceDock: [zip] [tar.gz] [tar.xz]

KerbMav, my EVAManager plugin (currently only used here and by TweakableEverything) already lets you do that. For example, if you wanted to add a thermometer experiment to a Kerbal, put something like this in a .cfg file in GameData: EVA_MODULE { name = ModuleScienceExperiment experimentID = temperatureScan experimentActionName = Log Temperature resetActionName = Delete Data useStaging = False useActionGroups = True hideUIwhenUnavailable = False xmitDataScalar = 0.5 dataIsCollectable = False rerunnable = True usageReqMaskInternal = 1 usageReqMaskExternal = 8 } You can get it from the AntennaRange and TweakableEverything archives, or from KerbalStuff. Someday maybe I'll release that more officially. EVAManager discussion relocated over here: http://forum.kerbalspaceprogram.com/threads/121146 In unrelated news, I'm releasing a testing version of AntennaRange featuring pretty lines! If you're both brave and committed to providing useful bug reports in the event of a problem, you're welcome to check it out and see if anything horrible happens. Download: [zip] [tar.gz] [tar.xz] It also comes with a really rough first draft of a VOID panel for AntennaRange. It's mostly useless at this point, but if you want to check it out you will need this dev build of VOID, as well: [zip] [tar.gz] [tar.xz]