swjr-swis

Not sure what uses it, definitely nothing stock, but as far as I know explodium is considered to be the substance Eve's oceans consist of.

I notice you mention quicksaves, in which case you need to keep one other thing in mind: reloading a quicksave from before you made changes to game settings will revert the changes - including a change to the resource transfer setting. Best thing to do is as @Rocket In My Pocket said, change it from the in-game difficulty options, then immediately save it as a named save, and only use that save (and any saves from that point on) to continue the game.

Main rule is: the subassembly needs to be 'attachable' according to the game rules. Iow, the root part of the subassembly needs to be either surface attachable, or has to have an open stack node. Contrary to what @Magzimum says, this can in fact include the root part too, the entire craft you build, as long as the above applies. Another interesting detail: due to the above rule, one can create a subassembly with a root part that would normally not be accepted as a root part (ie. that cannot be placed as the very first part, like most surface attachable parts). The game only cares about it being attachable somehow. Quick test to prove the above: place an octo probe core, attach any other part(s) to it - but leave either the top or bottom node of the core open. Now grab the probe core and you'll see that the entire craft can be dropped as a subassembly. However, if you use both the top and bottom stack nodes for other parts, and grab the probe core now... no dice, no subassembly allowed. If you have a set of parts that you wish to save as subassembly, and somehow it won't save, it can usually be solved by using the re-root gizmo, and picking as root any other part of the set that still has either an open stack node or is surface attachable. Of course this may not attach as logical/pretty as one would wish, which is why you should always build a subassembly with the main rule in mind.

Yes, missing a full stop and a 'we': "The TK-W1 boasts a wider wheelbase since we kept flipping the M1s. Just add wheels." Still the same amount of total work, but: By simply splitting it up, there is less chance of things interrupting an individual PR review and perhaps forcing one to start all over again. Less time one has to dedicate in one chunk, which means one can better fit it into the RL schedule. Remember, not everyone has the same stretches of free time to dedicate to modding, sometimes especially mod authors/maintainers. But more importantly, I also said: "Also, it would've helped the logical processing of the different types of changes if they had been separate PRs." By doing functional changes in separate PRs from the whitespace changes, for example, a reviewer can work much more efficiently - it is quite faster to scroll over large stretches of code when you can be sure that you only have to look for empty lines added/removed and opening and closing brackets to be in the expected places. On the other hand, if you have to be on the lookout for code changes that affect functionality as well, the process becomes a lot slower. Also, a mod author can prioritize the PRs and like in this case, could've quickly reviewed and merged the atmosphereCurve/Oscar-C changes, which are arguably more 'bang for the buck', and leave the whitespace cleanups until there is more time/help. (don't misunderstand me, I think most coders appreciate clean, consistent whitespace, but when one has limited time, function tends to override OCD. If it works, it works... we'll make it pretty when there's time).

I reviewed #37 on github. One of the descriptions you change in there needs a slight correction (see the review for the detail), other than that it looks good to go.

Ok, took me quite a bit longer than expected... github and my browser got me twice - github by 'faking' the latter half of diffs and my browser by crashing on me at one point and at reload resetting the page so I lost track of where I was, which made me have to go through all of it again to be sure. Nevertheless, here's my findings of the review: TL;DR - as far as I can tell you can merge the PR wholesale without detrimental effect. The atmosphereCurve changes could use in-game testing/confirmation, but on text at least they look ok - and if anyone finds they need further refinement, it's easy enough to enter a new issue/PR for that later. The vast majority of the changes have no effect on file functionality: Corrections to indentation - a big thank you for that, as it definitely helps in making the files more readable and to better visually group NODE{} content. Whitespace removal - A lot of blank lines removed; also very welcome, but as said before, a bit overdone to my personal taste - I prefer to see a line of whitespace between NODES{}. I think this was already corrected in a newer PR. Line/section order - some lines/sections moved up or down in the files in the interest of consistency, all good work. Cleanup/removal of superfluous/spurious comment text - Most of these seemed to be remnants from templates or copy/paste actions, good riddance. Spelling and grammar changes to part description texts - In most cases corrections of clear errors, and a few removals of spurious cut/paste remnants, which is all good. (#1) A few changes do affect functionality, for the better: A section of MM patch text was cut out of a part cfg file (MEMDescentMod) and put into a new independent patch file (SXT_KIS.cfg), as it should have been A number of atmosphereCurves were adjusted/extended into the higher pressure range. The changes look ok at first glance, but they'd require testing in-game to be sure. The Oscar-C tank fuel content was upped a bit, and cost/mass changed to match stock ratios. One correction to a faulty tags line (tags = tags = ). One correction to a misformed bulkheadProfiles line. A few remarks on the PR, mainly for @voicey99 to keep in mind in the future: In the future, try to split PRs to make the job of reviewing it manageable. For a mod creators/maintainer it is almost more time consuming to have to review someone else's code than to write their own, especially if it's done in huge chunks like this that don't allow for piece-meal processing. Also, it would've helped the logical processing of the different types of changes if they had been separate PRs. #1: A number of changes to description texts seem to be more based on personal preference than necessary corrections. In a few cases I think to have spotted a change based purely on a misinterpretation of the original intention of the description. Personally, where it is not a clear case of correcting a grammar/spelling mistake, I would opt to leave the original text of the mod author alone, but since none of it affects the functionality and it would expedite things for lgg, I'm not going to go into those details now. (If they bother me enough later, I may just enter a github issue with my suggestions) All that said: thank you for the time and effort in helping with PRs. Any help lgg gets in maintaining his ever-growing list of mods will help in keeping his effort viable, and the mods available.

Still a bit to go, unfortunately not sure how much because I hadn't noticed that github doesn't load the entire set of diffs at once... I thought I was nearing the end before I ran into 'Load diff' which I have to do one by one. So I took a break for a moment to gather a bit of energy to go through the rest. Results so far: no errors found that would be caused by the diffs, so that's good. I did encounter a few functional changes, in all cases atmosphere curves - most of them extended into the higher pressure range, one had some tweaking on the pre-existing points. I can't judge just from looking at the text how the adaptations would work, but they look ok and in line with the advertised purpose. Back to see if I can finish the rest of it.

Let's reason out the distasteful details, because I think it's the other way around: stuff is not added, it's removed, and the end product is compacted. LifeSupport consists basically out of three things: solid, fluid, gas. Solid input is (usually) higher than solid output, due to removal of nutrients and a high percentage of the water 'solids' tend to consist of, plus there isn't all that much waste addition. We also shed hair and skin - some ends up as waste, another part is caught in the air filters. Fluid input is higher than fluid output - a fair percentage is converted into gas through perspiration and exhalation. We do add some waste to the output of course. Gas input is likely the only resource of which the output is clearly higher - we are very efficient air humidifiers, we add a carbon atom to every molecule of oxygen we 'use', and we produce some other gases. I don't know exactly how the output of scrubbers compares to liquid oxygen volume-wise, but there's definitely more atoms going out than coming in. Also not clear on what is done with water condensation from the craft atmosphere system - if not recycled, this would add to the waste/output too. Considering that water recycling is likely a big part of making a space craft/station viable for any serious length of time, I think it's fair to take water out of the equation to simplify things. In which case, we are mostly transforming voluminous hydrated solids into compacted dehydrated solids, and a lot of extra gases. Gases are dealt with through the air filtering systems, so the only end product to be dealt with, here called Organic Slurry, has to be of less volume than the input. Is my thinking wrong?

I have a few hours to burn... scrolling through them right now. So far (about 20% in) I have seen only whitespace, line order, and spelling changes to description text, none of which affect the functionality of the files. A completely subjective and perfectly ignorable opinion if I may express one: personally, I prefer a line of whitespace between NODE{} sections, which I notice have been removed with prejudice in this PR. But like I said, it changes nothing (so far) to the functionality. I'll report back in again as soon as I've worked my way through.

For the same reason they made the least aerodynamic model for the one of the pair (16/16-S) that is meant to be used inside the atmosphere, and default it to attaching perpendicular to prevalent airflow. Just about everything about that antenna is wrong inconvenient challenging for being the only stock atmospheric one we get. But on the bright side: it allows us to boast a 100% balanced game, and we get the added realism and immersion of circumventing the issue by using one (or more!) of any of the other non-atmospheric antennae while shielded inside a bay or fairing. So it's all good.

abracadabra?

Ion engines use EC though. Conceivably, one could create multi-staged ion probes. Would that run into problems with this? Another example might be monoprop-only craft, that use the same flow mode as EC?

Well.... given the documentation you linked to, it would seem the devs can in fact do at least one bit more: actually add units to the two in-game sliders. That tiny bit more could possible have prevented this entire thread. After-thought: they could even add tooltips that give a short explanation of the slider effect, which would allow to explain the 'responsiveness' slider even if the actual effect of it cannot be given a fitting unit (eg. if they chose for that slider to affect both attack and release, but each of those in a different range). Tooltips are shown in the 'mini-settings', so the code for that is already in there.

In stock, the generic maxTemp for low tech parts is 1200, medium tech 2000, and advanced/high tech 2500/2700. Going by the looks alone, I'd classify the IFI parts in advanced/high tech, but they miss the specific reentry-minded details of Mk2/Mk3 parts, setting a high limit of say 2400. At the same time, they look better designed than the stock medium tech parts, which would set the lower limit to 2000. 2200 seem like a good compromise?

El sistema usa las mismas reglas para el flujo de combustible, solo que en reverso. Dicho de otra manera: si el 'ISRU' fuese un motor, todos los tanques desde los cuales podría usar combustible pueden ser reabastecidos también, sin necesidad de mods o transferencias manuales. Un consejo: hazte un rover minero y plántalo en la pista en el CEK, y practica el uso del taladro y el procesador ahí mismo. Es la manera más eficaz de aprender los mecanismos, y puedes recuperarlo sin perder fondos.

F toggles the mode of the rotate/offset gizmos between absolute/local. I would be in serious trouble if that one gets conflicted with other functions.

Please tell me you're making it so kerbals can climb that radio mast. We need a good basejumping spot to uhm... test jetpacks and erh parachutes and stuff. For science. That's probably the best course of action; then no one needs to feel guilty for more (awesome) pics of this work.

Yes

The PartMapper is not a mod... it's a standalone command-line executable that runs completely outside the game. As such, I'm not sure that it should be indexed by CKAN to begin with. That aside, the functionality of the PartMapper is now included in the KerbalX mod, in a more user-friendly way. PartMapper has also not been updated in over a year now. Safe to say at this point it should probably not be advertised to the general public - they should be pointed to the KerbalX mod. From the KerbalX mod page:

An 'Update Craft' button was added in the 1.2.0 update of the website; it's at the bottom of the edit craft page, under the craft options. See if that works for you until kat gets a chance to look at this. I tested going to my own hangars by different routes, it all works. I also tried going to your hangars and it seems to work as well. This is on Windows and Firefox. Whatever the fault is, it's not universal.

Literally a carbon copy, yes. I'd advise doing it with a clean, unmodded copy so you have a clear starting point (you can zip up your current install as a backup to return to). CKAN allows you to administer several different instances of KSP with each their own mod set (I know, because I used to do this myself), but it's been a while so for exact instructions on that you would need to ask in the CKAN thread. If you have other KSP questions that are not directly about the Toolbar mod, feel free to PM me or (better, helpful for others too) create a new thread in either the Gameplay Questions or Technical Support sections of this forum.

Remember that KSP allows us to use engines under water (or other liquids, outside Kerbin/Laythe/Earth). 90 bar (~900m) when deep-diving in a planet's ocean can be reached even before getting to the bottom of Kerbin's water masses. As a wise person said not too long ago:

This seems like a self-created problem: nothing forces us to constantly update a mod, especially if it is not viable for one to have to redo work to compensate for changes. If a mod version you install works as is, stick with it until you have your current career/project 'finished' to a point where possibly breaking changes can be accommodated.

Stock doesn't have a 'parachute' tab in the default/simple mode (in stock they are in the utility tab, and just checked - still there in 1.3.1), so you are likely using a mod that changes the tabs/filters. It so happens that 1.3.1 makes some changes that require such mods to be adapted/recompiled to work. This may explain. Btw, in stock as well: under Advanced mode, filter by module, there is a separate entry called 'Parachute' with a distinctive icon. Just checked, and it is there and contains the stock chutes. It is rather down the list (on a 1920x1200 screen it goes on beyond the bottom of the screen), so you may need to scroll it up - hover over the icons and use the mouse wheel.

The cause may not be CC - you might want to check the release thread of the planet/realism mod you use that adds a planet called 'Earth'. One of the changes made in 1.3.1 that affects such mods has to do with the body names, and they may not have updated/recompiled to deal with that change.