komodo

*also staggers in from the land of the dead*... Wow!

Two early xmas presents just popped up on github: A draft, but fairly complete compatibility config for Snacks!, lightweight as it is. (If there are fellow Snack!-ites, please give it a test if you are so inclined.) More fun, a compatibility config for Vanguard Technologies: Adds proper ejection seats to Gemini/Leo. (Pull the lever, Kronk!) Also, I just realized I misspelled compatibility in both commits. **** Edit to add... Oh, and this little one, which I wasn't going to put in the repo, but in case anyone wanted it... It is a tweakscale adjustment for the small intelligence camera part in @DMagic Orbital Science, adding a 0.938 m size for all of your Agena spying needs. @PART[dmReconSmall]:AFTER[DMagic]:NEEDS[Scale] { @MODULE[TweakScale] { @scaleFactors = 0.625, 0.938, 1.25, 2.5 @scaleNames = 0.625m, 0.938m, 1.25m, 2.5m } }

I would advise caution with such an approach: Windows isn't all that smart. It may work on your machine to have a zip file with a non DEFLATE compression type due to 7z being installed. I'd check it against a machine without such installed to check that it works in that case. (Maybe Windows 10 has improved in this respect, I can hope so, but I honestly don't know.) a slightly larger file might be worth it if someone doesn't have to think they have a corrupted download On a technical aside, LZMA can make some rather impressive compression results, at the trade off of time/resources to compress. For small archives like these, it's not so noticeable (if at all), but scaling up to a few gigabytes for a dataset, let's say I'm glad 7z is multithreaded on Windows... The perk though is that decompressing is still quick, along with the high compression ratio.

I have no hard evidence, but I just saw this field/method being used in the Kerbalism pre-release. See the middle of this post for circumstantial evidence. In any case, if you haven't already @Pointblank66, remove everything but the 1.1.3 versions of BDB and DMagicScience and see if it can be reproduced. I also don't have a clue why the antennas would be affected

The generic one should be correct, as it is intended for situations such as these. (They do different things, I think, although one may be a subset of the other.) That the change worked for you is likely a result of having the full DMagic science package (correct me if I'm wrong though). As mentioned just above, the package in question was updated more recently and should be updated on your end as such. (Same for the firespitter dll as well, as mentioned.) I'm sure when the next proper release of coatl will have the latest versions. ps, support for ksp 1.3 when?

Can't guarantee that it works correctly in the addon, but it *should* point out the other side if you reverse the direction of the display. (That is, if pointing in one direction for "left", it should invert for "right".) As for why... the right hand "rule" was a couple posts up. I wouldn't be able to sit and derive it off the top of my head though, these days.

It is one of those subtle MM things you just get used to after looking at them for an age: after Service modules. Some need 90% fuel, 10% mp. the patch is modifying, well, what we just did in the first MM block, but only for the LEM part. @ for MM is a useful mnemonic, literally "At this part of the code, DO (Stuff)". So here, At the B9PartSwitch module that was just added, and at the first two SUBTYPE keys (0 and 1), do something to the tank types... Except without the form "@tankType", it doesn't do anything. With no operator, it tries to add the new value, but as there is an existing one, it fails. (Or more accurately, just ignores it.) The @ operator is needed to edit an existing value. (I also just fixed it on github, so you can see the differences easily.) @Jso, I haven't had a chance to try it yet, but there is now a dev preview of B9PartSwitch with some of the partial fill options that were talked of previously. I don't think it will precisely help this setup, although it might inform decisions in the future. Also, headache as that config is, it's also fairly elegant, nicely done.

The issue with USI that I always ran into was a design decision on their part such that 'short' missions, up to Mun shots and back were considered 'included with the capsule', the last time I played. The grace period/running on fumes after you run out of resources was designed such that short orbital/munar missions didn't require additional supplies. This makes sense when balancing for long duration, system spanning/colonization missions, but is a moderate headache when trying to balance smaller pods. i.e., how to make them meaningly different. My memory is fuzzy, and I don't have it in front of me, but I strongly suspect I said "***** it" to some of the balance and implemented something that made sense internally to BDB. Similarly to the issue of 'stock balance', it may not be possible to cleanly integrate with USI and our own framework is needed, but I strongly suspect something can be worked out. I don't claim to be clever enough to do so though

The USI-LS configs are in sore need of updating. The 'balance' that is in the existing one (See the comments in said MM config for details) were my musing to myself on what might make for good gameplay. Unfortunately, I never got the knack for USI-LS at least as far as balance goes. I never quite got in line with their (to my sense) rapid resource use, especially on 'long' days, that is, 12 or 24 hour clocks. With the USI-LS... version 5?... I understand the values have changed from prior versions. I have unfortunately not been able to arc out the time/brain needed to dive into USI land in 1.2. As mentioned above, the existing MM config has notes on "why these values". If the payload/duration is kept the same, it would be just a matter of adjusting the resource ratios to match the new version. More in depth, would be something more thoughtful than my late night musings, and thus, I throw it open for discussion. Ideally on the github issue for USI-LS, but here is also ok, within reason. On a similar note, I haven't uploaded or lent it out yet, but I have a mostly working config for Snacks! that mirrors the existing USILS config as far as approximate mission duration. If there is any interest in that, I can get it online somewhere, but ideally I would like to wait to see what happens with the configs for USI, and/or [TAC, Kerbalism] as far as design. The configs are easy, deciding what to put in them is hard On a more technical note: Github has whizzbang features out the wazoo, many of which are pretty helpful, yet entirely perplexing. Grappling/mastering such whizzbangs is not a pre-requisite for working on any of this. The humble code block in a spoiler in a forum post works quite nicely for MM configs like the ones in question, if simplicity is sought. We can figure out the whizzbang after

Cool, that's great. Learning is always appreciated, contributions even more so! if you're already on github and such, do check out the issues/discussions. There's a lot of nuts and bolts stuff over there that may be of interest. As for this issue... Hrm. The values in the WBITankSwitcher.cfg have been changed, yes, but the MM cache doesn't reflect this, nor the output.log. The output.log has a printout at the very end, just before the log goes into cleanup on KSP edit, line 69199, of the resource definition. Which is 594/726/150 LF/O/MP, which I imagine is what you see in game. Curiously, this is a value that was once tried, and is still commented out in the SM config, but it's not the one we have currently in the tank switcher config. The MM cache is effectively a window into how the game sees its files. It has the same definition loaded, at line 2326 of the cache. Soooo what's it mean? I don't know exactly. I would try moving/renaming the cache and forcing MM to rebuild it. It shouldn't have missed this, but it wouldn't be the first time the cache didn't get updated, either. I suspect that this is what is up, that a previous edit has gotten jammed up and it isn't seeing the new value. Incidentally, if you're running at 10x rescale, I highly encourage you to check out the meta issue for rescales on github, #270. I don't think we have anyone who has tried 10x at any length, and any feedback would be extremely helpful. (The BD_Extras folder has some hints/inspirations for rescaling parts as well, at least saturn and to a lesser extent, titan.) If the issue persists, please check back. This is a weird one, but it shouldn't be too hard to run down.

What version/download are you playing with currently? The development version is in a state of rapid flux still, so the answer may depend on which version you're using. This part has been particularly annoying, but I digress. WBITankSwitcher.cfg should be the place to change it, for the moment, so i'm not sure why it wouldn't be working. If you could upload a KSP.log and a ModuleManager.ConfigCache to dropbox/something similar, it would be much easier to figure out what is going on. Out of curiosity more than anything, why those numbers?

I haven't paid my screenshot tax in a while. Time to fix that. First off, we have this lovely little item. This was born out of a late night session wondering if that part would even work like that... It turns out, yes, yes, it works very nicely in fact. That is an eight part probe, with several hundred m/s dV available. Don't sneeze, it might blow away. Secondly, I have this number. I'll spoiler it, for space purposes and that it's a filthy, but fun, crossbreed. And just a wee bit "through the looking glass". I was going to try to peace it up with tantares parts, but my computer is saying "NYET"... so I may fill it out with MOL parts. TBD, in any case.

The core functionality is working fine for me. The rescaled buildings took me by surprise initially, as I thought I had mucked it up with KSC so close to the beach at 6.4x! Figured out that I should have that on '1' and not '0' pretty quick, though. I am not sure if it is designed/intended/able to deal with Kerbal Konstructs/Kerbin-Side, though, so I haven't brought that up before. Results have been mixed there, but I haven't had time for extensive testing. (Even at resize buildings = '0', things were a bit muddled as far as elements above/below terrain). But yeah, no issues with KSC currently, all orbital type things working as per usual (so, quite nicely!) Cheers

I think in my case, per tank type would be the choice here. In which case, either proportion 0-1 or percentage 0-100% would work well, although any of them could be made to work. The use case I was after was exactly that of the Apollo service module, where the default could/should be a partial fill, but that the option exists for a full fuel load for certain mission profiles. Staring at a part config, it would make sense to me to configure it in the SUBTYPE block, as an optional percentage in that case. I don't know how feasible that is though. Pinging @Jsoas well, as I can't conceptualize the "number of units per volume to be filled" option, and that might turn out to be just the ticket.

Neat! I had done a similar thing a while ago for my own entertainment, but I might as well post it if anyone else wants to have a go at it: It doesn't need CryoTanks proper to be installed, just CRP. The numbers are balanced against the BDB cryogenic parts, so they'll be about right for 3.2x rescale as written. Just a heads up They also apply to the tanks modified by Shuttle Payload Technologies, which are cosmetic rescales of some of these tanks, as best I can tell. It ought to work with or without that mod, I think. (But I haven't tried.) If i've totally borked it, I'd be curious to see; they should work as simple MM, but there are always gremlins around every corner!.. Cheers.

What I mean to say is that GitHub unifies the line endings upon push, to ... well I don't remember off hand what it goes to: I suspect to the windows standard of CR/LF, as Linux is often used to dealing with both, but many windows utilities ignore simple LF newlines. But such a line as that quoted above doesn't seem out of the ordinary. If we do get a MM cache, the non-part nodes (such as experiment definitions) tend to to be toward the bottom, but no guarantee. If the MM cache is empty, it indicates there was a parse error from MM, but those it reports on the loading screen under the "patches applied" count. I would expect to find a mangled definition, or else a mangled science part. Working back to figure out whodunnit is difficult though. Edit to add, after reading over at SEP, apparently such a character can bungle up KSP/Unity after all O_o although, on the other hand, some insane counterintuitive unity behavior? Perish the thought... Gah....

The other way to look at it is more complicated. Anything physics involving an orthogonal direction, you have a normal force at play. I hope this links correctly, Although it's not ideal, it was the best I could find on short notice. As mentioned, whenever a rotation is being imparted, the resulting torque is felt as a normal vector. This to me is one of those counterintuitive to normal life but normal in physics sorts of thing. (No pun intended on use of "normal", here! D'oh!) I've never been great at physics descriptions though

Backtics? The one on the tilde key on US keyboards? It shouldn't matter either way, this is weird... Could you paste a sample line? I don't have a copy handy at the moment. (Or do mean some Unicode snuck in at some point?) Github will fix line endings across Linux/OS X and Windows, which I'd be more suspicious of then a particular character. It's all just strings if the brackets are balanced. But fixing line endings should avoid problems, not cause them. (Nothing is perfect though...) e: if just coatl and squad work, but with others it breaks, it's a MM issue somewhere. We'd need the MM cache and a log file to figure out what, though.

*can never unsee/unhear* The USI life support was my doing/fault: I haven't had a chance to use it at all in 1.2, or even a career run as of yet. If you (read, USI using thread goers writ large) have ideas/suggestions, please shoot them over on github: there is an open issue for it already. It's not too hard to implement configs, but puzzling them out from scratch is tricky. (Plus, I had a fair bit of free time and a lot fewer parts when I wrote the existing ones, time that I don't have a lot of at the moment ) I understand the ratios have changed, but again, I'm not sure what the new details are. (Hint, by all means, tear open the current MM and start playing. I won't get offended ) On another note, Those tanks look pretty shiny, indeed!

Why do you keep trying to make more work for you, CW? (Which is the 'new' one of those? Or are they two 'new' alternatives?)

Question: I had a look through the source, but I couldn't find an answer... It doesn't mean it isn't there, though: Is there a way to specify for a part, "Total volume is V, but only fill to V-n"? This would mirror the stock config solution of amount = V - n maxAmount = V I don't think there is a way to do this currently, but I figured it wouldn't hurt to ask. Thanks much!

So I heard this new Vega upper stage was going to be used for Atlas launches. This is an Atlas launch... Right? So, the Vega upper stage... Yeahhhhhhhh, About that..... It actually works really really well. (Note for bonus points, the new linear Kane RCS for OMS ports beneath.) Props to @benjee10 for the spiffy parts. Now, I just have to figure out how to not have the fairings rip the wings off... good thing this was a prototype ><

Soul draining aside, viva science. Ullage is still a strange word to say. "Ullageeeee...."

I don't know about the contents of the drag cube (but it's nice to see a ticket that got answered and not left on the vine forever), but for drag cubes, all of the values are going to be comma separated, at least that was how they used to be. I don't think anything has changed in that system going to 1.2. I should have said "12 commas in", or something, my bad. A non-integer being, "0.1185349 0.06135106", which is not an integer, or even a float, but a string. MM doesn't do algebra, yet at least. (One can dream!) Looking forward to your release!

Sorry CW, you happened to have the right quote for this I'm always amused at how casual everything kerbal is, but the hypergolic fuels might take the (explosive) cake. ("Whatcha got there?" "Oh, unsymmetrical dimethyl hydrazine and some neat nitric acid." "Oh. I think I will go... that... way. Quickly. You stay here. Byenow!") In other words, If you've used "squirts hydrazine" in a sentence, you're going to be in for a fun time. *gives @akron brownie points for including warning labels for unsuspecting kerbalnauts* The new parts look spiffy for sure. My soul is ready, even if my graphics card is not!