Crater

Here, it looks like this Which almost includes your final line, but.... not quite.

Well, any part that doesn't exist will simply mean that the match rules never find a match. No error, no failure, just no effect. So the only possible downside would be an increase in loading time, which is tiny, For example, I have over 230 MM rules spread across fiftysomething files, most of them are wildcard matches that scan through the over 1500 parts I have (B9, KW, Novapunch, KSO, many many others), and the sum total MM processsing time (from reading the logs for when it starts and when it finishes) is about 11 seconds, so if you added an extra 10% on that (which would be a LOT of rules, parts and changes), then you would be looking at one more second on my several minutes load time. I'd say you'd be fine, but if you really want to, then break out rules into one file per mod instead of one monolithic file, and people can delete the ones they don't need.

The secret of being able to name a port would be to create a new partmodule that only had one parameter, and that was the port name, so the config would look something like MODULE { name = ModuleDockingPortName portName = Cargo Berth #1 } Kethane stores data in the savegame by using a SCENARIO {} node, but that's save-global, not craft specific, so for the ports on a single craft, I think you'd have to go the partModule route, then use ModuleManager (or other witchcraft) to add your new partmodule to anything that had a docking port on it. It might crumble when faced with single parts with multiple docking ports (such as PortWorks hab), but other than that, it should be pretty robust I think... but since I've never written anything of any significance in C#, and never anything at all for KSP, I could be completely wrong, ofc.

You could model that by having BreatableOxygen and LiquidOxygen as two separate resources, (probably renaming one of them to Oxygen for inter-mod compatability), with parts that convert LOX into Breathable as necessary, most Oxy Generators generating the uncompressed one, and a biiiiig heavy power-hungry part that can liquify the BreathableOxygen for use on bases or resupply stations if necessary. But basically, the recyling system would generally cope with keeping up with demand, and the stock tanks of LOX would only be dipped into when there was a shortfall. Or maybe have GeneratedOxygen and Oxygen, and the LS mod use GeneratedOxygen if it is available, and only dip into the Oxygen if needed, but don't provide storage of GeneratedOxygen beyond the size of the pod. I agree that in the real world, compression only takes place planetside. I know exactly where you're coming from on the in-game electrical system. If you call the units Ah, or Joules, then it is just a matter of scaling, but so many people tried to call them watts or volts or.... some other incorrect unitary expression. But even so, the balance is.... well lets just say it's a game, and enjoy playing it Anyway.... I gotta run - we have visiting friends over for the weekend.

For reference, STP is "standard temperature and pressure", which is defined as 273.15K (0°C, -32°F). RTP or NTP are "Room" or "normal" temp and pressure, which is usually considered to be 293.15K (20°C, 68°F), but has the problem of "but my room is 22°C" or "is that normal for summer or winter" and so on, so STP is safer, but less useful in this case, since the gas when actually breathed will (hopefully) be at room temperature. At that density, it'll be liquid. To get the gas down to that level of compression, you're looking at about 800bar at room temperature, uhhhh, about 11,000 PSI, which is crazy-pressure. but for Liquid Oxygen, 148kg would take up just shy of 130liters, which fits well with allowing for the tank walls in the above. Agreed. The one thing that is constant is that the amount of oxygen a person (and presumably a kerbal) needs to metabolise in order to keep breathing (pun intended) is a constant mass per time, regardless of the atmospheric pressure, O2 concentration, temperature, etc. etc. etc. So it definitely makes sense to consider the resource usage by the addon in terms of kg, BUT.... liters are a measure of volume. kilograms are a measure of weight. You can't interchange them unless you use density as a conversion factor (which has units of mass per volume). Fortuitously, the game already requires density to be specified in the resource definition file. It multiplies the stored volumes by the resource density to calculate the mass of the vessel. Which means that if you are using kg as your unit, then you absolutely must set the density to 1.0 or the vessel mass will be off, and that that point you are actually using liters as your unit, and lying about the real density, which will come back to haunt you when you start storing more than one type of gas in a matching set of vessels. as an extreme example, liquid hydrogen is over 16 times less dense than liquid oxygen. This also impacts on crossovers with other mods. For example, anyone using the KethaneConverter module in a part to work with these resources will find that you can already specify mass-ratios for input and output resources, and the converter uses the densities to calculate the conversion rates based on these, ensuring that conservation of mass continues to happen. Similarly, the Exoplanetary Launchpads uses the density of its rocket parts to caclulate how many you need for a given mass of vessel. So please, please, by all means work in kg for the consumption rates, but then use the resource file defined density that you are working with to convert into storage units that are in a volumentric measure (liters, 5liter units, whatever is decided). I love ModuleManager, and yeah, however it ends up being, I'm happy to tweak my own personal KUniverse to my own designs... I'm just arguing the case for minimizing the tweakage I have to do... and hopefully maximizing the ease of interacting with other mods, other parts, and other people's stuff

Thanks for being so understanding. I completely see where you are coming from with wanting to use 1u=1l for units, and my only reason for preferring 1u-5l is for interoperability with stock, and with the many many other mods that are balanced against it. It means that if you want to repurpose a tank model, you just change the resource name. That said, it isn't exactly a hardship for me to multiply by 5 (I went through a save game file the other night converting from 1u=1day to your modified values to save Jeb from asphyxiation on his way to minmus!) if I'm editing a file. So I'll happily accept whatever standard is decided upon for the mod. I just wanted to raise the discussion point. However..... for my next two discussion points. You keep referring to STP and gasses taking up 22.4 litres per mole. Spot on... Except that nothing else is using STP. Breathing air (the 304.whatever liters per day thing) is at RTP (or NTp depending on where you live), which is 24 liters per mole, a little over 7% more volume per mass, and a heck of a big error if you run out 93% of your way home! And.... I think that since tanks only matter for storage it would make more sense if you worked with the stored forms for the required volumes. I don't really care that it takes 304 litres of air at normal pressure to keep me alive for a day, compared to knowing that the 1.5 liter tank of O2 I have at 200 bar can happily do the job without cryogenic storage, or that I'd need less than a quarter of that volume if I was storing LOX, though that does come with additional complications. But it doesn't seem right that a tank volume that can hold 10 units of water can also hold 3000 units of oxygen. It would seem a lot more sensible to me if it went something like * you need 304.27 liters of O2 per kerbal per 24 hours * stored at 200bar, that is 1.52135 liters of tank volume. Therfore this 50 liter tank can keep one kerbal alive for 32.86 (24-hour) days. Use the storage units as liters, the stored medium as being (compressed) oxygen, and adjust the required units per day down to 1.512 to compensate for that. It would keep the units in a tank a lot more consistent regardless of what resource you were referring to.

Sorry to be a nuisance, but all the stock resources actually use one unit equals five liters, not one liter. For example, if we take the big orange Jumbo-64 tank, at 2.5m diameter, that gives a cross sectional area of about 4.9m2, so if we assume the 6,400 units are liters, that would require 6.4 m3 of volume, which gives the tank a height of 1.3m.... If we assume 5 liters per unit, that makes the tank more like 6.5m high, which is clearly closer to the case. Using the stock volumetrics would ease the path for people using modular fuels, or converting other tanks across to store TACLS resources. Best of luck with the move! Hope everything goes smoothly for you.

Loving the progress that you're making on this mod. The models and art are awesome, as is the general functionality. However, from what I've read, it looks like you are using liters as your unit of capacity when working out the amounts of resources that fit into a tank. In general, all the stock tanks are based around one unit of resource being 5 liters of volume. For example, if we take the big orange Jumbo-64 tank, at 2.5m diameter, that gives a cross sectional area of about 4.9m2, so if we assume the 6,400 units are liters, that would require 6.4 m3 of volume, which gives the tank a height of 1.3m.... If we assume 5 liters per unit, that makes the tank more like 6.5m high. It would be really nice, to ease conversions between mods, especially such as modular fuels / RF, if you could aim for units of 5l rather than 1l per unit. I'm off to make the same plea in the TAC thread now.

I hit a weird bug last night. Apparently if you don't actually remember to place the parachute onto your rocket, then it doesn't deploy during reentry, and Jeb gets very upset with you (briefly).

Alternatively, if you use KAS, you can send up a load of Storage Bags that you can just carry across and attach to your station. But otherwise, then yes - they are standard resources, so you can transfer them in all the ways you can transfer fuel etc.

Without knowing what version of KSP and what version of MechJeb you are using, there is very little that we can do to offer advice on either of these issues. (also, please note that "latest" is not a version... latest when I downloaded it, latest when I ran it, latest when I logged the bug, latest when someone reads the post... can all be different versions)

Go to GameData\Kerazmit\ProceduralFairings\ and open each of the adapter, baseNNN, and baseRingNNN configs (for each size, eleven files in total) in a text editor, look for the lines that start with node_stack_top or node_stack_bottom, and make sure that the seventh number on the line is the correct digit for the size (some only have 6, some already have 7, once you finish, all should have 7) 0.625m - size 0 1.25m - size 1 2.5m - size 2 3.75m - size 3 5m - size 3 (there is no size 4 in game.... yet, so these are 3 as well) Save the files, reload KSP, and you should be good. Alternatively, the following should be a ModuleManager config that will do it for you, if you use ModuleManager.dll (can't test it at the moment, I'm at work) @PART[KzInterstageAdapter] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_top = 0.0, 0.23, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_top1 = 0.0, 1.0, 0.0, 0.0, 1.0, 0.0, 2 } @PART[KzProcFairingBase1_25] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1 @node_stack_top = 0.0, 0.575, 0.0, 0.0, 1.0, 0.0, 1 } @PART[KzProcFairingBase2_5] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_top = 0.0, 1.15, 0.0, 0.0, 1.0, 0.0, 2 } @PART[KzProcFairingBase3_75] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 3 @node_stack_top = 0.0, 1.725, 0.0, 0.0, 1.0, 0.0, 3 } @PART[KzProcFairingBase5] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 3 @node_stack_top = 0.0, 2.4, 0.0, 0.0, 1.0, 0.0, 3 } @PART[KzProcFairingBaseRing1_25] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1 @node_stack_top = 0.0, 0.23, 0.0, 0.0, 1.0, 0.0, 1 } @PART[KzProcFairingBaseRing2_5] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_top = 0.0, 0.46, 0.0, 0.0, 1.0, 0.0, 2 } @PART[KzProcFairingBaseRing3_75] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 3 @node_stack_top = 0.0, 0.69, 0.0, 0.0, 1.0, 0.0, 3 } @PART[KzProcFairingBaseRing5] { @node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 3 @node_stack_top = 0.0, 0.96, 0.0, 0.0, 1.0, 0.0, 3 } If you do use MM, just stick that with your other MM configs.

Yes, Yes, and no - you only don't get warning at the Space Center or the Tracking Station. If you are controlling a differnet vessel you will get warnings about any / all vessels.

As a general rule, decompression timings are almost unrelated to compression levels, it is at compression time that you get exponential time increases as you push harder. I haven't done any benchmarking on PNG compression specifically, but this is the case almost across the board for the majority of compression algorithms.

You need to be using the dev version of MechJeb, you can find links in the MJ thread, in Sarbian's sig, or at http://jenkins.mumech.com/job/MechJeb2/ - it was updated less than an hour after 0.23.5 came out, but don't hold your breath for a "stable" release, dev is very stable itself in general.

Since these are just resizes (very useful and needed ones), is there any chance that you could reference the Squad models and textures rather than copying and duplicating them? It would cut the memory footprint down to almost zero if you did.

First off, I understand your position, and I too miss the awesomeness that was the DEMV rovers in my game. That said.... the reason Bobcat (and others like him) object to other people distributing "fixed" versions of their products is that far too many (idiot) users download the "fixed" version, then complain at the original author for support on it, moan, whine, demand proper fixes, request changes to this, that, the other, on work that has now been changed from what was originally released, sometimes in game-damaging ways, and often without even mentioning that it is a tweaked version that they downloaded. Also, bear in mind that, specifically in the case of the DEMV rovers, they aren't fixed, as such (I'm guessing here, but I'd put money on it), since an actual fix would involve splitting the chassis up into a base and separate wheels, and recoding it to use the stock rover wheel system. If you want to know why it makes a difference, try driving a stock rover, and then a MK4 on Gilly and watch the difference. When that happened to me is when I removed them from my 0.23.0 folder and moved on. They feel too much like cheat parts now to me. Getting the parts to load in-game is as simple as putting PART {} around the config files and downloading the updated cleverbobcat.dll. Making the work the way they should, the way Bobcat has stated he would want, the way his unfinished updated rover will, well that's a whole different job. If people make the changes themselves (really guys, it is a couple of minutes in a text editor, total, less with practice), then then understand the issues, the lack of support, the things that will still not be "right". If they click on a link (especially one in the official thread), and unpack as normal, then they will all too often complain that the parts simply don't meet their quality expectations for Bobcat releases.... and the thread fills up with complaints about something that the OP didn't even do. I hope that gives you a better understanding of why some mod-authors are resistant to derivative works.

Bugreport on delta-V calculator. It looks like the calculator for remaining delta-v can not work out the available resources for engines that use MonoProp or Xenon, the two resources that changed flow type in this update. These two are no longer ALL_VESSEL flow type, but are now STAGE_PRIORITY_FLOW instead. I'm guessing that this is likely the cause. Using build 194 on 0.23.5. Interestingly, the RCS delta-V figure is still okay, it is just in the engines/stages calculation that it fails.

Would it be possible to just separate that portion of the UV out onto a separate texture canvas, say a 128x128 one that had just the name on a white background? That way, people who wanted multiple names in game at a time wouldn't need to duplicate the entire huge texture.

First, please please please DO change to using standard volumetric units for supplies. It makes things way simpler for people who want to integrate with other mods (several now have water, for example), or use stretchy tanks, or modular fuels, or build service modules, or.... the list goes on. Second, 0.23.5 is semi-save breaking anyway, in the sense that only new saves will have asteroids, so most people will be throwing out their old saves at that point anyhow. Third, don't forget that units are storage units in the game, so if a Kerbal breathes 304 liters of oxygen in 24 hours, totalling 0.405kg, then that was at room temperature and pressure. Once you compress a gas and stick it in a tank, it doesn't take anywhere near that much space. For example, the density for Liquid Oxygen is 1,140kg/m3 which means that the 0.405kg mentioned above comes out at 0.356 liters, rather than just over 300, which is a HUGE difference.

Compression will almost certainly still save you space. For example, a 4kx4k texture (pretty much the biggest you'll generally see in game) uncompressed is 64MB. is you half the resolution for a lowrez version, that will quarter the size down to 16MB. However, if you simply compress the original, it will typically in the the region of 6MB - 10MB. Compressing the low-res will be smaller again, but I'd actually recommend that you try switching to the highres packs for everything, since one of the features of aggressive is that it will resize larger textures down (selectively, the individual mod config files can control this), so starting with the high res stuff and seeing what happens should go okay, and minimize the drop in (or even potentially improve) graphics quality. Edit: It is completely safe to just install aggressive over the top of basic - it is only going the other way that you would need to delete the texture cache to re-allow the loading of the original textures.

Even worse - when you add wings to both sides of a craft, with or without symmetry mode, they're rotated not mirrored. So if you textured a wing with differences between top and bottom, one of them would always be upside down. The only solution I've seen to that is to have duplicated parts for left and right wings, which is major part bloat, can be major texture bloat if done wrong, and means you cannot use symmetry, but have to resort to tricks like attachment nodes for placing the wings onto the craft, which means you're essentially building a model kit, not your own design.

Or just rename the mod to Four-real Chutes *hides*

There are the same number of hexes on every body, regardless of its radius. The hexes just change size depending on what body you're looking at. As for how many there are, Majiir has definitely mentioned it a few times in the thread, but short of counting them manually, I couldn't tell you off-hand.

they're not folder names, they're (regular expression) patterns that need to match the filenames, so in your case, try something like config_enabled = true OVERRIDES { BigDummysMod/C/.* { compress = false mipmaps = false scale = 1 max_size = 0 make_not_readable = false } BigDummysMod/D/.* { compress = false mipmaps = false scale = 1 max_size = 0 make_not_readable = false } } (notice the "slash dot star" on the ends of them).