Wolf Baginski

As the other bear said, some Mods explicitly include the Gamedata folder, some don't. And sometimes a user will end up wth: ./Gamedata/Gamedata/Modname It's easy to make a mistake like that, and also easy to check for that install error. At least, it looks easy for this bear, but he is old enough to have used MS-DOS, before Windows came on the scene.

Miller's Dale for TideswellKirby MuxloeMow Cop and Scholar Green

That's OK. No effect is better than something that contradicts the visual model. I don't know how solar panels set the zero, but it wouldn't surprise me if it has to be a particular axis in the model. I shall have a look at doing something with Module Manager to make is Snacks compatible. That system is a simple life-support mechanism, and not bothering with sun-angle fits with that simplicity. Looking at the Snacks greenhouse, it's its own solar panel which converts a trickle of EC into snacks. In the logic of the software, opening the covers over the greenhouse is no different from deploying a solar panel

A question about the sun angle: I use the Snacks system, and greenhouses came with that. Their output depends on the sun angle, the same as a solar panel, but the zero direction, where the sun generates maximum input, is aligned with the long axis. And they're a similar layout to your model. That all makes it a bit tricky to combine with solar panels. So do your greenhouses depend on the sun angle, and does it point in a plausible direction?

o,64x looks good as an ideal scaling, but that slightly larger scaling for a Redstone to get to 1.25m is a very defensible choice. That x1.1 linear difference cubes out at x1.33 volume, and that could be applied as a correction for mass/fuel numbers, if you wanted to be picky.

The Kerbin Rover mod is a good option for this sort of thing, essentially a Land Rover Defender, and it does work with 1.1.x I have loaded up the roof rack with science and gone prowling the Space Centre. There were FFR ("Fitted For Radio") versions used by the British Army and a version with an extra battery and a Communotron 16 is a good start for that. It's what I use, and the classic Land Rover is a very Kerbalish vehicle, very modular.

VAB and Hangar crashes seem to be a general problem for KSP at the moment. It would be as well to make a game save before ever entering the VAB or hangar. On what I've seen, it doesn't seem to be any particular mod. All that blowfish says about getting support is good, but with Squad taking a much-needed holiday there's not much chance of any fixes for a couple of weeks.

I can't rule out that something else was messing me up, but I do wonder why Squad so consistently does not use the NODE-module method, I have earlier downloads, but the oldest version I have easily accessible is v1.04 and the only place where I find the "FIXED_JOINT" string is the part-configs in the KipEng folder. It all worked then. It's the same for "JOINT". The string "NODE" is in a few more places, but not in part-configs. So I reckon the new-style node specification, which came in around v0.20, has been abandoned. It may have been deprecated earlier than v1.0, when it became necessary to get the direction vector correct. Ah, I found my v0.90 install. Only one item uses the NODE-module, a rover body from Kerbal Foundries Unity 5 may have been the final straw. It may not have been that it couldn't support both methods, but why do the work to transfer and test both? It's not going to be trivial to sort this out. There must be something in the .mu files which marks the node locations, there's nowhere else for the data. I know there are ways to load them back into Blender, but after that I'm screaming "Run away! Run away!". Guessing wildly, there are mesh components that are tagged as markers, with specific names. It's likely the top and bottom nodes are (x,y)=(0,0) and only the z-coordinate matters, at least for the docking ports and other KipEng 2-node parts. But that's reverse-engineering the parts, not the best way of doing things.

So Squad are still using the original method for everything, and everybody else copies them. I suppose that the key details for the position and orientation are defined elsewhere. But note that the details of the old-style node specification changed with v1.0 and that bottom node needed the minus sign adding. Here's the nodes for the current Rockomax Hub, the stock equivalent, which conveniently shows the six directions. node_stack_right = 0.9121535, 0, 0, 1, 0, 0, 1 node_stack_left = -0.9121535, 0, 0, -1, 0, 0, 1 node_stack_back = 0, 0, 0.9121535, 0, 0, 1, 1 node_stack_front = 0, 0,-0.9121535, 0, 0, -1, 1 node_stack_top = 0, 0.9121535, 0, 0, 1, 0, 1 node_stack_bottom = 0,-0.9121535, 0, 0, -1, 0, 1 The first three numbers in the set are the coordinates of the attachment point, the next three are the direction-vector, the last digit is the size. The two systems might still be there, in parallel, but I feel a bit doubtful about relying on a "New Nodes System" which seems so completely not used.

I have an extra dropdown menu there, under advanced, with the name "Mipmap filter", with a similar range of options to the standard image resizing. I don't recall whether the .dds export is an add-on or built-in, but I'd check you have the latest version. I'm on GIMP 2.8.10 and the website says it's up to 2.8.16. I ought to update, I think. It does look like it is a plug-in, and there are still links to a really old version of the plug-in on the net.

And so our intrepid Kerbals set out to Do Science! (This is an FFR version assigned to R&D, hence the extra battery for the wireless set.) This vaguely resembles a real Land Rover I drove for many years. The FFR versions were set up for two aerials on the front wings and had a dual 24v electrical system, with separate batteries and control systems for the vehicle and for the radio system, while the ignition system was specially screened, plugs, cables, and distributor. This was designed before the transistor took over from the vacuum tube. And, as British motorists of a certain era may recall, there were regular sacrifices to Lucas, Prince of Darkness.

Sorry to say that I've not had any success with v1.1.2 but it may not be an issue with these parts specifically. I noticed that the equivalent stock parts specify nodes in a totally different manner. This is the style all the KipEng parts use. NODE { name = top transform = n_top size = 1 method = FIXED_JOINT } NODE { name = bottom transform = n_bottom size = 1 method = FIXED_JOINT } And this is the stock docking port. node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1 node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0 It's two completely different methods of specifying the node location and the string "FIXED_JOINT" doesn't seem to come up anywhere else but in the KipEng folder.

I am not seeing the huge problems some are reporting. Some areas, I've maybe not used yet, and I think I was rather casual about taking game saves, but I don't have a super-hot machine, and things are working better. But I am using Linux. Some people are using Mac hardware, and I know, in other contexts, people are having problems specific to that. So maybe I am lucky. But if you want to make a fuss about the quality of the current version, I figure it might be the OS you are using, not KSP, that is the root of the problem.

Good to hear this. I shall give them a run with 1.1.2 though, since I am running under Linux, anything could happen. (it is annoying when people are wailing about problems I have never seen, and are not bothering to say which of the three versions they are using.)

You do need to make regular game saves now, but I haven't come across anything insurmountable. Every game these days seems to depend on an underlying engine that is produced somewhere else. There's stuff I use that gets almost weekly new releases, and which depends on some 3rd-party code that is still 32-bit only. 64-bit software has been around for a long time; it's rather sad that games in general have failed to keep up. We do have better perfomance, but maybe things have slipped back. I haven't been around long enough to really compare. I am not sure if things are better or worse than v0.90 for the bugs. I can't compare to v0.25 I think the pace of change, and that matters for the mods which many of us use, has been too fast. v1.1.1 might as well not have existed. We need a few weeks of stability for the mod authors to get out something that works. There are things that are likely to work without problems, and things which need tweaking, and things that should be taken out behind the barn and shot.

It's the gaps around the doors where it looks wrong. Just the line in the texture works. One of the things that could go well with this would be something resembling a theodolite. It would be a KIS/KAS thing, and a Kerbal doing EVA could set it up, take some measurements, and pick up a few science points, maybe a few more if it was near an anomaly. Nothing big, but it used to be how these things were done, rather than pushing a button on a GPS, and a surveyor running around in a Kerbin Rover sort of feels right. And it's the sort of data that could easily be sent back to base by radio.

A couple of Mystery Goo cylinders, load up with Kerbals, and chase Werhner around the KSC, and the science builds up fast, maybe a little too fast. On the other hand, the early stages with stock vehicles can be a bit tedious. Sine the real Land Rover is such an old vehicle design they're quite plausible as something that would be seen around, maybe even doing some applied boffinry. It'd be an interesting challenge to see how far you could travel around Kerbin It wouldn't be so easy to get Science Points in career mode since there are limits on EVA. Those surface samples add up.

Thanks for the texture-file. The headlamp range doesn't look badly wrong, though a bit more would be plausible. I went exploring with a couple of Mystery Goo cylinders on the roof and an extending aerial on the top of one front wing. Worked fine. And I see there is another update... I see you can now stick a flag on, but maybe the front door, driver and passenger, would suit better than the roof. Also, I'm not sure the normal map is working right.

The latest version on KerbalStuff is looking very good. If v1.1.2 hadn't appeared I would have added some KIS-storage and sent a bunch of Kerbals on an expedition. It wouldn't be hard, I think, to trade off a couple of passenger seats, and there are ways of having the valiant Kerbals sans pressure helmets. If somebody wants to get some good photos, KIS/KAS would also allow some proper camping equipment to be set up. At the moment, with the transition between versions, I shall just wait a while I wonder if I can mount some roof-racks with oxygen tanks for an expedition to the Mun. The real Land Rover is just over 1.5m wide, and I think that makes parts for a roof-rack and ladder available in some mod or another. I am also going to see if I can come up with a variation on the colour scheme. There's the very commonplace white roof with green or blue for most of the rest (The colours changed slightly over the years, and the names) and one scheme you sometimes see on old TV, typically in an African setting, is a white-and-black zebra-stripe (The TV series Daktari also used some ordinary factory paint schemes).

Downloading v1.1.2 for Linux from the Squad Store is misbehaving. I hope it's just a sign of the load on the Squad server-system. I don't feel any need to rush, but when I do try again I shall also try Firefox rather than Opera, On what I have seen so far, with v1.1.1, the 64-bit version is a remarkable achievement. It's not hitting RAM so hard and generally running faster. But I would be unsurprised by a further version appearing in the next couple of months.

Copyright and licensing issues matter, but it is certainly possible to read and write .dds texture files with graphics editors such as The GIMP, and do something such as changing a colour or adding a logo without having to access "sources". I tend to create and edit textures oversized, 2x or 4x the size I use at the end, and I also use the lossless-compression (if any) multi-layer native editor format, and that all makes a huge difference to the final quality which ends up in the .dds I also know some people get grumpy about even editing for your own use. So don't get silly. Own use

Thinking about the different vehicles, there has always been something very Kerbalish about the Land Rover Defender. It's a set of parts you can just bolt together. Well, it was. Production has ended. Those windows in the roof side are called "Alpine lights" or sometimes "Alpine Windows". You could, if you were so inclined, make a set of parts for KSP and get a whole mix of Land Rovers. hard top, canvas top, pick-up cab and body different chassis lengths, the options go on and on. The Series III LWB DPV got very well-known because of the Tamiya "pink panther" kit, but the basic style goes back to the early days, and the colour was even used by the Royal Navy to paint ships because it was thought less conspicious at sunset and sunrise.

It's a good start, but the windscreen, side windows, and roof don't look right. There are plenty of good photos, so I shall just summarise There is a vented air-intake panel between the bottom edge of the windscreen and the top of the hood/bonnet. This has always been there. and without it the bottom edge of the windscreen is too low. The top of the side windows looks too low, but this may be down to roof shape. They should be lower than the top of the windscreen, but that looks too high. Essentially, the sides are vertical until the top of the door is reached. At the front, with the single-piece windscreen, the top edge was raised, with a small-radius rounded corner. The transition from vertical side to flat roof was always a smooth curve, with a quarter-cone taper ever the front door. It's easy to see this with the colours you've chosen. The curve at the edge of the roof, the black area, should have a horizontal bottom edge, front to back. The radius is a bit too big at the very front, and there is a bit too much metal at the top and sides of the windscreen. The roof panel, curves and all, unbolts as one piece, and only the top of the rear door was higher than the side panels until the single-panel front windscreen came in. A usual colour for the metal roof, regardless of the main body colour is white/cream

There's a Taurus HCV capsules that carries 7 Kerbals, and I have had good results from using a 2.5m-3.74m adaptor that is outfitted with space for 4 kerbals, but I can't recall which mod that's in. I think it uses the PXL/PXD labelling system. That gives you the crew capacity potential for re-entry. I've been doing some tests and comparisons. and a not-fancy command pod might not need any fixes. The 1.05 part.cfg may well work. I tend to use the sort of modules that come in Space Station packs to provide space for long missions, rather than just rely on the re-entry crew spaces in a heat-shielded command pod.

I have now made a check on Whyren's Snackhouse models, the greenhouses in his pack, and they do work, but I am seeing some odd behaviour. Full sun exposure, and maximum snack production, happens when the sun is aligned with the vertical axis of the part (vertical in VAB). The greenhouse doors open OK, revealing the windows on the side. and the solar panels I fitted to my test craft correctly track the sun (and gave me a visual check on sun direction). I've shied away from using the ToolsByWhyren.dll which could be what fixes it, but these .dll files are just the thing which I'd expect not to work in v1.1 I shall have to give it a try. Edited to add: There was no change at all with the .dll included, no failure and no change to behaviour. It's a while yet before it would make any difference, I tend not to transfer games between KSP versions, but this does seem to need attention. Did it happen with 1.05? I never noticed. You sort of assume that things that obvious get checked before a mod gets out in the wild. Further Edit Report: I am not 100% sure on this, but I suspect the oddly-aligned sun angle happens in v1.05 If there is a way this can be re-done it needs it. As the solar panel angles changed and the sun got closer to the axis, ther Snackhouse seemed to be working faster. Then I overcooked the manouever and the station broke up. But, at the moment, there's a workaround, awkward though it is to align the station differently. And if there is a way to work the sun angle properly...