timmers_uk

New release posted - adds tooltips to T + R buttons, and hopefully sorts out @Blacks 's NPE.

It means I forgot to update the version in the assembly properties file. Ill have a look tomorrow with fresh eyes.

Done. New release uploaded (and wasn't that a pain in the ambients uploading whilst on the train!). Changed default position when using stock toolbar. Save slider position to settings.dat I haven't seen a repeat of the NPE, but I did find one place where maybe it could have come from, so I'd be interested to know if you are still getting the NPE ... though puzzled on the cause - I can't wait for someone to get the debug patches updated to allow debugging the thing.

Yep already seen the issue(s). New release going up (already) ... Added the toggle setting A/B button (the one with letter 'T') and reset current setting )the one with letter 'R') to the panel. Fixed proliferation of toolbar buttons after scene change, and NPEs from autohide coroutine.

Ok I'm not waiting on Blizzy's toolbar for 1.1 ... New release on first page - build for 1.1 Prerelease, supports Stock Applauncher (toolbar), but *in theory* will switch to using Blizzy's toolbar when that is available for 1.1 assuming the interface stays the same (untested). Default slider position is top left because I can't see a nice way to get the applauncher position (unlike Blizzy's toolbar, which handles this nicely), but I've added support for dragging the slider elsewhere on the screen. Edit to add : Note - right now the stock mode doesn't support middle/right click on Applauncher to reset/switch to setting2 - I'd be interested to know if people would be ok with buttons next to the slider for doing these things (reset to default + setting1/2 toggle) - I'm kindof inclined that way as it makes operation a bit more obvious. .... I'm also not ignoring requests for per-scene settings, but want to get this working for 1.1 first.

I'm currently waiting on Blizzy's toolbar for 1.1 - I'll have a look tonight at the much delayed 'looking at a stock toolbar option/version', but don't hold your breath, ALA is written in a quite toolbar centric way.

Correct - not enough time to make UI on KeepFit less painful, and a keen awareness of the dangers of featurecreep. On the EVA suits, I'll try and leave a Kerbal in EVA suit for a few days - I suspect the way the code works, it'll count as if he's CRAMPED for KeepFit purposes when he's on EVA, but I'm not sure. CRAMPED is probably most reasonable if on EVA and not on a planetary surface with reasonable Gee (I can't remember what I set for 'reasonable' here). (Side note : we don't, as humans, really know what a reasonable Gee level for long term health is, we can't test for it - its either vomit comet for <1min reduced G, ISS for 0ish G, or Planet Earth for ~1G - and I don't see anyone volunteering to spend long periods in a centrifuge to do long term testing of >1G either!)

Unfortunately I'm at the other end of the day, so I'd recommend steering clear of my profile on spacedock - I added a dupe of KeepFit on their not thinking about the fact that its already up, and when I removed it, 'things' have gone pear shaped. I've been avoiding getting into other things like radiation with this mod - feel free to fork the source if you like and make a version substituting the Gee stuff for radiation though - my concern would be opening a can of radiation worms with things like Nerva exhausts, but feel free.

NEUTRAL should be the one to zero out fitness loss. EXERCISING should increase fitness. I think Cryo would be NEUTRAL?

@Deimos Rast Sorry I haven't got to looking at your changes yet - I definitely will, but I wanted to get a 1.1 build out for the pre-release quickly. 0.10.4.3 release up on Spacedock + github - rebuilt and fixed up for the 1.1 prerelease, and vaguely tested with 1.1. Shout if you see new bugs - I don't have CLS support yet tested due to not seeing a 1.1 build yet, and haven't pushed the bounds of the possible with it by any means, but I did get rid of the most glaring showstoppers needing fixed to use it with 1.1 If you aren't on 1.1 prerelease, steer clear of this new build, stick with 0.9.4.3

0.16.5.2 released, rebuilt with minor fixups only needed for 1.1.0 prerelease. No blizzy toolbar support for now, as AFAIK no blizzy toolbar for 1.1.0 prerelease If you are using 1.0.5 still, stick with 0.15.5.2.

Well, GDC is now completed, with a bonus of Achievement Unlocked x2 KSP PS4 edition *and* Scott Manley! KeepFit you say? Yeah haven't got any further with that - waiting for 1.1 UI framework changes.

We do, as long as you have an environment for your crew which could support some decent fitness equipment, rather than placing them in a space smaller than a phone booth for weeks at a time - think Skylab rather than Voshkod. Right now the only parts which allow state Exercising are various spinny habs.

0.9.4.3 Posted, and added to spacedock - I haven't tested it much myself on this rev, so it may as always, be filled with bees. And on the CLS front ... I'm in two minds on the cause of this one - probably 1.1 will be my next chance to mojo it up so I look into it. For now I guess, disabling CLS integration is the way to go. Tim

Yep np, this is all witchcraft anyway, so possibly a little unpredictability is expected

Growwllll rargghhhh Now you've done it, awoken the beast and everything - no idea why I've stopped getting notifications coming through reliably from this thread, but I'm a) tied up in other work things right now (GDC looming), and don't have much inclination to touch code when I escape. b) just realised I left my laptop power supply at the office so can't do poo about poo this weekend as a result. I know I've got outstanding work to push out, from other helpful users, and I'll push out a spacedock release on the next release, but only then - I pushed ambient light adjustment out to spacedock sooner because I know more people use it. Perhaps Monday if I can dodge the eyes of my boss.at lunchtime (mmm .... another al-desko lunch). T p.s. Not sure on the cutting out/undetecting of the ships - when I push the new release I'll try to have a look at what could be going pop, but generally KeepFit has worked through being dumb as a brick. p.p.s. @bananashavings - nevermind and thanks for being good about pulling from spacedock, ironically if someone had PM'ed me a few nights ago I would have had the time (maybe not much inclination but enough if I'd known someone was jonesing for KeepFit) p.p.p.s. @NathanKell thanks for handling this in my lazy absence

Yeah I've re-created the entry for ALA on spacedock. If that goes pop though, I'm just going to go github only in future, so CKAN will just have to find it on there, and it'll be for CKAN side to re-link it or whatever, as I don't use CKAN so can't comment on whether the setup matches.

@SirCmpwn coming to this a little late, as usual, but sorry to hear things have ended up the way they did, and thank you for providing KerbalStuff for as long as you did.

TBH I'm not sure what to do on this - I have something which is working for me, that I've pushed into my own fork of the source code, but it looks like the OP hasn't been around for some time. If anyone wants to look at my forked code, I'm fine with that, but to release a forked version I'd need to a) Get into contact with Mactee to get the ok to redistribute stuff based on his code, b) take on the responsibility for it ... and I'm behind on updates for my own mods let alone someone else's app. Timm

Yep I'm on build 1028, and since commenting out that line and rebuilding (the patcher), my debugging seems to be happy enough.

Has anyone else been having issues with using github based releases with the most recent KSP Mod admin AnyOS? I had a look at it in the debugger, and it looks as if possibly the HTML scraping is broken (changes to the HTML layout of github's release page?) I've looked into redoing the github plugin using the github REST API, but it has some pretty horrific rate limiting on API requests/hour for non-authenticated requests

FYI I was unable to run the patcher successfully on the current 1.0.5 win32 KSP, as the patcher couldn't find the ModuleAblator initializer. I recompiled having commented out the offending line, it patched the rest ok, and KSP seems to have come up successfully //MoveInitializerIntoAwake(asm, "ModuleAblator", "\b\b", 8, "Start");

Oh absoutely, I don't like the interface myself, but coding for a living I've found it very hard to get motivation to re implement the UI code for KeepFit - ideally I'd find someone who likes doing UI code, and split the KeepFit code apart so it provides the guts + backend, and have someone else expose the nice UI to front it up. Maybe the new UI requirements in 1.1 will take me over that hump, as the current Unity GUILayout based code gives me the angers, because its ... odd ... to say the least. On your specific issue, you could go temporarily wimp-mode (and suffer nothing but the eternal shame of knowing you've played a sandbox game how you like it, rather than according to some arbitrary requirement of happenstance co-incidence between 6.4k kerbol, stock aerodynamics (? or is it FAR?), and KeepFit) for this slightly iffy sounding re-entry, then switch it back on afterwards. edit : missed the 'or' ... or you can edit the gee-tolerances which I just checked and realised are stored in the scenario node in the savedata, not globally in the plugin dir - look in https://github.com/timmersuk/Timmers_KSP/blob/master/Timmers/KeepFit/GameConfig.cs to help find where to look. I'm pretty sure I didn't expose those settings via the settings UI.

Hmm.... could be interesting. I'd be tempted to use something like Graphotron on an unmanned (unkerballed?) test flight/simulation of the re-entry. 24g seems like its on the harsh end of what's even sustainable in the short term. In theory more is definitely possible, and you could always play around with the KeepFit config settings, but sustained over any length of time (re-entry to 6.4k Eve is not going to be over in a few seconds, unlike the kinds of things John Stapp did to himself) ... tricky - breathing might be a real factor. If (BIG IF - I've not even got around to refactoring the poke my eyes out its so ugly GUI for KeepFit!) I were doing additions to KeepFit, it would be tempting to add a module that can be added into the configuration for capsules to account for things like acceleration couches, G-suits, or at the KSPI level of future tech, things like liquid suspension/immersion Gee mitigation compartments, which may apply a multiplier/fixed limiter to experience Gee effects in short, medium, or long term Gee effects. Right now though, tbh, its less of a priority as I'm not playing anything of an RSS or larger than average scale Kerbin system nature, so the Gee effects aren't really much of a limiting factor unless I send a crew out to Jool in a tuna can and then expect them to survive their deorbit/re-entry decel. Of course if anyone else fancies taking that one on ... feel free to send a github pull request and I'll be happy to look at incorporating it! oh ... you could also consider for Eve, going the spaceplane landing route - should be a gentler re-entry than dropping like an anvil from low orbit.

Thanks for that, and the appreciation. Ill look at dropping those extra configs in tomorrow. Timmers