Wolf Baginski

I've done a check, and Whyren's snack containers work OK in v1.1 They're essentially dumb boxes. The Snackhouse greenhouses I have not tried yet, but since they have animation features I left them out for now. I shall have to see if they will work, they're an answer for long-duration flights.

Agreed, this is so useful. I mostly use it as essentially a simulator, trying out such things as Duna landers before I commit to an actual mission, otherwise my surface scans would be showing remarkably high concentrations of aluminium in the soil.

Snacks seem very Kerbalish to me as a way of modelling life support, and I am happy to know they will still be around. The various add-on snack containers and greenhouses are also good. I've been doing some checking of changes to part.cfg files, and a lot of v1.05 things should work without problems. I'm cautious about items that use animations. The key item is the actual plug-in. It will be a while before I launch a mission lasting long enough for extra snack storage to matter. I may knock up something for one of the cylindrical batteries which has reduced battery capacity. Something such as a Z-200 with only 150 battery capacity and 50 snacks. Does that sound a plausible balance? Maybe a bit less battery, but something that could combine with the Mk1 Capsule.

I shall give this a try, but I don't expect any deal-breaking problems. I've been doing a few comparisons of part.cfg files and they haven't changed in any obvious ways. Command Pod, Engines, and Fuel Tanks look pretty good bets. I know there have been decouplers which depend on animation plug-ins, and there was a lot of work that was needed on landing legs and wheels. There's likely other stuff. So I would say that if anyone wants to use this mod in v1.1, just try it. On the other hand, I wouldn't risk taking a career-save from v1.05 to v1.1 That sort of jump could be awkward.

I have just been comparing a v1.1 rocket engine with a v1.05 one, two different versions of the same component There is no obvious difference in the part.cfg That doesn't hugely surprise me. I probably should do a proper diff-style comparison, but it suggests that if I really want to use an engine from an older mod, I can just go for it. Though I shouldn't really complain if something goes wrong. If a Mod doesn't need a plugin to work. what traps are there besides wheels and landing legs? And some of the standard plugins, such as KER and Interstellar Fuel Switch, have got their v1.1 upgrade. So I did some checking on command pods. The K2 pod, one of those Gemini-style two-seaters, doesn't have any significant changes from the stock Mk1 in the modules it uses and the relevant variables. It's different, because there are differences between the two mods, and I am not sure if the K2 got a full v1.05 update, but it looks as though it would work. There are some things I am waiting for. If you're using extended life support mods. there are plugins involved, even for something as simple as Snacks, and that maybe explains some of what has and hasn't appeared yet. I am going to give one or two things a try, because, for one thing, I like the look they have. but I don't quite expect the full Monty from them. But the comparisons I have made are reassuring. I've never compiled a plug-in, and I don't want to diminish the problems in that, but I am feels a lot less worried about when some stuff might appear for v1.1

I am a bit tight for RAM, and had regretfully decided not to use this with 1.05, but so far 1.1 seems to be using less. I am not going to rush, there is so much other new stuff to explore, and any v1.1 career will take time to advance to the point of using this. I recently saw a pic that compared the various cargo/crew craft that had visited the ISS. The Shuttle could carry a huge volume. This is one way of filling that gap.

32-bit can address 4 gigabytes of memory. 64-bit isn't infinity. but 16 million million million bytes is near enough for most things. Current hardware, memory modules and board space, gets to 64 gigabytes without much trouble. My current PC can handle 32 gigabytes, but I am not sure it can handle bigger memory modules. That's partly a limit of the connector. The program with stock parts runs to around 2 gigabytes, plus some memory for the OS. Just going to 8 gigabytes would more than triple the RAM for storing mods. It took a long time for software to really take advantage of the hardware. There are game-code components that are still only available in 32-bit form, even though there was a 64-bit version of WinXP. We all have a huge amount to thank the Unity developers for.

I am a little wary of download v1.1-compatible mods now the official release has happened I am not sure if they are fully compatible with the actual release version. I expect it will all get sorted out over time, but at some point it might be worth just changing the version tag for the remaining pre-release v1.1 mods to something like v1.1beta. There shouldn't be many. The people who have been uploading v1.1 mods are the one who I expect will fairly quickly do a test against the release version, but any of us could have an accident. (I did once, and was off-net for 7 weeks.)

It's a change to the part file. Different filename and different name-entry in the file means that it sits there in parallel with the original. Two distinct Pods available in the editor.

That's a pretty trivial change. Make a copy of the .cfg file, change the "name" so you can have both versions, remove the "INTERNAL" section, and change the "CrewCapacity". That's all you need to change carry 6 Kerbals. You won't have an internal view, and that's where it would get complicated. Also, there are the "cost" and "mass" numbers that ought to be higher, It's the internal view where the real work would be, and the cost and mass would matter for balance. Without changing those it's a bit of a cheat. I reckon. The existing parts are close to other components of similar size and capacity: you could certainly use the existing 3-Kerbal original without any balance issues. The main fuel tank is a good match for one of the stock 2.5m tanks in weight and capacity. and that's where a heavier pod would have effects. You would need something a bit heavier and carrying more fuel. If you're after the looks, does that really matter? Maybe all that's needed is to do a similar mod to the fuel tanks, and using the same model, so it's all a bit heavier and carrying some more fuel. It's what you want to do with a higher-capacity pod that sets whether you bother.

I have just been trying something that uses this. I have just Tweakscale and Hangar that come with the DLL, and Hangar is old enough that it had to have its own version, not the more recent version with Tweakscale. If I read things correctly, that's expected behaviour, depends which version of plug-in the Mod is compiled against. Is it possible to have a plug-in that, in the transition, just translates between the plugin and the official KSP version? Or do I misunderstand how the linking works? Though one possible old Mod giving a problem is hardly a disaster. I am a little anxious about making the switch to v1.1 but KSP isn't a huge problem to have multiple independent copies of. It's more a feeling that there are going to be some 1.1test versions of Mods lurking in the shadows, all labelled as 1.1-compatible, and they might not be compatible with the release version. I probably worry too much, but this is about rocket science, after all. (Mods such as Hangar, there are all sorts of ways of getting a rover down onto another world, but there is room for black-boxing the detailed design, just as we don't worry about the fine details of turbopumps.)

I miss this Mod in 1.0.5, it was making it so much easier to deliver things such as rovers. There is some overlap with the large service modules in Lithobrake Exploration Technology., but larger service bays in general can't substitute for this. You srill have to have set up some sort of coupler/docking. The same with cargo bays. Getting something, anything, like this in v1.1, will be a good thing. It doesn't have to be this specific mod. But the overall idea is a kerbalisation of a real problem. We don't really do the detailed engineering. We assemble high-tech black boxes

My initial reaction is to wonder about scaling. The Kerbol-Kerbin system is smaller than Sol-Tellus. The scaling factor is about 10.9 to 1 It looks as though Bennu could be an E-class asteroid, but that makes things such as sample-return messy You have to grab an asteroid, a sort of docking, rather than land on it. A Gilly-based mod might be the better answer.

The problem with removing the Push Adaptor is in what it might do to saved games. It can be deprecated, but removal from the pack would be hasty. I would have a preference for some sort of choice for things like docking. There are different docking ports used in different station Mods, both how they look and what they will dock with. I am not sure it makes any visual sense to fit a different docking port, visually functioning as a sold disk, but having a unit with a node to accept a docking port, a grappler, or other similar device might be useful.

You could probably do all this in the part.cfg file. Suggestion: use the Squad R-10 SRB with a fuel tank on top. It's a standard fuel-switch option to make the tank all-oxidiser, but you could make an edited version with the liquidfuel RESOURCE section removed, and names and description changed. You also do an edited part.cfg for the SRB that adds a requirement for Oxidiser as a PROPELLANT. Check how the quantities and ratios work out. but then you start getting into the fine details of balance, Isp, and the atmosphere curve. The advantage is that you have a simpler mechanical system, only one set of pumps, but this would need a little more dead weight than an SRB. On the other hand, it's something you can stop and start.

While I can see the point of having a central list, there is a tool to convert between a Unity .mu and Blender which might be enough to make a start on somebody using the various cross-sections. Yes, you would need permission to distribute a Mod using somebody else's hull shape, and the conversion, as I recall, does include the collision mesh. Attachment nodes are specified in the part.cfg, and the zero point seems to be the centre of the Mesh, which might be a little tricky for some shapes. It can all get complicated, but it looks as though fitting to a particular existing cross-section is pretty simple, if you know how to make a model. The virtue of a list would be in documenting who currently controls a shape.

Check which version of B9 you are using. The details are in the file B9_Aerospace.version and there does seem to be something coming through the works. The version I am using is v6.0.0 and I did get a warning of v6.0.1 from the version manager I use. But then it tried to use a link to the defunct Kerbalstuff site. My own preference is to download and install manually. The B9 install puts several plug-ins into GameData, and I can see them in the zipfile and check I have them all. I reckon we're an an in-between stage, and I would try a v6.0.0 install. That works OK in my system. The B9 mod is pretty well-organised and you can delete sub-folders of Parts to remove things you don't want. The whole thing has also been split into three sections, with the HX-size hulls and Legacy parts. It's not the only well-organised mod out there, but it's a good example of how to do it all.

I'd start with the Module Manager syntax It is documented in the handbook on the Github page and in the Module Manager form thread I have done one or two things, but essentially it is a programming language for modifying the .cfg files and it can look a little frightening. I think there are ways to do what you ask. If I am reading the Github syntax page correctly, picking a sub-directory of GameData is a "needs" option, and then you would use a wildcard for the part-name, which would add something to all the parts in a set. I think. I have too much blood in my caffeine-stream...

I've been checking, and there have been updates to some of the content this year. I checked one of the config files, and it has had the usual changes to attachment nodes and temperature limits. So it's not quite a dead mod. It may just be shagged out after a long squawk. It's hardly useless, but I am not sure I would start using it this close to KSP v1.1

Even if Kerbals are green to photosynthesise, I doubt they have enough skin area for the energy they use. Let's see if we can make a rough estimate (I used to have to do this when I was using a slide rule.) Human energy requirement: 10,500 kJ per day Solar energy input to surface: 240 W/m2 That works out at about half a square meter continuously exposed to the Sun and absorbing energy at 100% efficiency. Double the area to allow for night. Efficiency figures seem to vary a lot but I am just trying to get a rough idea. 5% efficiency is at the high end of the range, so we can make a rough guess that a human would need 20 m2 of skin exposed to the sun. That's a lot more than reality, and we would have to assume transparent space suits. Don't hit me, Valentina!

I may have missed something. What do I need to do to stop the tracking station classifying the assembly as "Debris"? It gets a little confusing.

I have mixed feelings about IVAa. I rarely use them in gameplay, and I have known them have a huge hit on RAM use. I suspect the worst case I came across used far too much detail in textures and mesh. I think I would wait and see what v1.1 works out like. But I would prefer having an option for a very simple IVA. It isn't so hard to delete the IVA from the cfg-file, but not having the option in the Mod can be a nuisance.

Jeb was hammering at his typewriter with what seems to be enough energy to orbit a Mun-probe. He was muttering things as well. Gene peered anxiously around the office door, nodded slightly, and quietly walked away. Wernher looked up from his desk. "He is annoyed", he suggested. "Well, I am not pleased, Gene. This should embarrass all of us." Then he smiled slightly. "But the verbal reports. It could have been a movie from the old days, something Buster Kerbal might have made." He held a palm-up before Gene could comment. "Not The General, but perhaps The Minmus Rover." Gene stifled an urge to giggle. "Perhaps so," he agreed. "I think Bill is correct about the proximate cause. But nobody is admitting anything. Are we so terrible?" Wernher shrugged. "We can afford to laugh. Nobody was hurt. And we learned a great deal from the mission. I expect you want it on your checklists." Gene nodded. "Rover parking brake set On." "I was watching on the camera." Wernher sighed. "The deployment light came on. The Kerbal Standard Initiators fired. We had weight on wheels. It all looked so good from Mission Control. And then the Rover appeared, visibly accelerating, followed by four kerbals, running as fast as a kerbal can in Minmus gravity." "I know", said Gene. "Somebody at the Kerbal Broadcasting Corporation has already sped up the tape and added a soundtrack." He sighed. "I have been earwormed." "Yackety Sax?" There was a long silence. "It wasn't quite the science we expected," said Gene, "but it was science." Wernher smiled. "And it was funny, but I shall not say that to Jeb."

I did find the hatch when I checked again. There's an old thread here that shows the space shuttle warning sign by one of the windows. It's rather more visible at a distance. You don't need the lettering to be clear. Though I expect it depends on the texture size you pick in Settings. You maybe didn't read the Wiki carefully enough on Node Definitions. The examples include node_stack_bottom names with numbers, and refer to stock parts with multiple bottom nodes. It maybe could be a little better-written, but I infer the "node_stack" and "node_attach" part of the names does matter. On the other hand, KSP used to rely on the "top" and "bottom" components before it switched to using the numeric vector, and all the bottom nodes had to use a "-1". What may be a problem for the MAV is that stepped profile, if you wanted nodes rather than surface attachment. .A capsule+interstage combination can survive re-entry from Kerbin orbit without a heatshield, but it can depend on the engines. I was able to do the same with my stock-parts version, similar weight and similar fuel quantities. I think Kerbals may be better rocket designers than the film's designers. The base is essentially a frame around four great big rocket motors that get left behind, with minimal fuel tankage, and that just feels wrong. There's the fuel generation to refill the main tank after landing, but why bother with the extra engines. If you have enough thrust to take off, you have enough to land in the first place. Art vs. engineering, it's the usual conflict.

To be honest, not having distinct names seems to be asking for trouble. I just flew a test and everything worked with the distinct names. The main thing I noticed was a bit more reliability with attaching engines in the VAB. I was using the SpaceY "Kiwi" engine on the MAV stage, instead of an LTV-45, and a boosted version of the "Spark" on the interstage. The "Kiwi" doubles the thrust with a lower iSP and my "Super-Spark" follows similar ratios. With a bit of extra fuel, a 2.5m pancake tank, and some 0.625m SRBs the capsule made Kerbin orbit. Six "Kiwi" engines are probably excessive but you have the TWR to carry extra fuel. I checked, and it's essentially a stock tank for mass and capacity, and that suggests I could build a craft of similar performance from stock parts. Maybe, for KSP, the capsule should have a crew hatch. It's all very well having an internal passage to a ground-level crew hatch, but it makes things a bit limited. OK, so it's a thing from a movie, but even if a crew hatch on the capsule is never uses on-screen, does that mean it isn't there? What do you do if the docking port fails? I am doing a bit more fiddling, and mounting engines in the base unit is being very awkward for v2. The base unit has an open bottom, with the nodes in the recess, and the engine is hovering in empty space, That didn't happen with v1.1, but I don't see any difference in the cfg file. I have seen similar things with surface-mount attachment, parts attached in mid-air, and I suspect it could be a different collision-box.