TiktaalikDreaming

I would think the last convenient time before actual release. That is, convenient for you. Tuesday morning your time maybe? Just so it's there beforehand, but not too early. I suspect most mods currently functioning in the prerelease will be releasable with 1.2. Not because they couldn't make changes, but because I'm using Sarbian as a litmus test, and he's updated Module Manager to 1.2 already.

Because it hasn't been mentioned here, and I don't know which threads others are watching, I thought it'd be worth just mentioning 1.2 is due to be released on the 11th, in some timezone (probably Mexican). So, load (network, file, db, basically everything) will likely skyrocket. And probably stay high for a few weeks.

Ha! Amen. Kerbals wouldn't mess around with teeny little 12m rockets when there's some handy 50m boosters.

Yip. Mostly done. I was going to take the opportunity to add in support for realism overhaul, and that bit isn't done yet. But the basic 1.2 compatibility is done. Those legs finally work properly. I had to do some tweaking on colliders, and it seems I hadn't updated some at all for 1.1. But I'm running tests for the next few day. Without KJR it's hairy as all hell, but it's working.

Many of the modules won't do multiple copies within a part. For engines though, you can just name all the mesh/transforms the same and treat it as one engine, with three (or whatever) times the single thrust. Each engine would have identically named Gimbal transforms, and similarly for the thrust transforms. KSP will just split the thrust evenly among the transforms and swivel each gimbal. I've used this a lot with subnozzles for aerospikes etc. No worries. I saw the mock up and thought I'd get in before the hole was dug too deep. :-)

Before you get too far down the line, the landing legs should probably be separate parts. The leg modules really don't play well with multiples in the one part.

The main tank body is 12m. Outer diameter to contain all the poking out bits, (especially the Interplanetary craft section) is apparently 17m. There's some really nice charts floating around apparently made from the CAD data (but no CAD files, dammit!).

You should be able to fit 9. 6 circles in a hex pattern is 3 circles wide, so if those are 1.25m parts, then that hex is only 3.75m across. For anything larger than 1, the size of the outer edge of a circle bounding N circles of the same size is ((1/sine(pi/N)-1)+2, or Circles Ratio Bounding Circle 1 1 2 2 3 2.1547005384 4 2.4142135624 5 2.7013016167 6 3 7 3.304764871 8 3.6131259298 9 3.9238044002 10 4.2360679775 11 4.5494655329 12 4.8637033052 13 5.1785814689 14 5.4939592074 15 5.8097343447 16 6.1258308955 17 6.4421911518 18 6.7587704831 19 7.075533821 20 7.3924532215 21 7.7095061398 22 8.0266741833 23 8.3439421961 24 8.6612975755 25 8.9787297556 26 9.2962298106 27 9.6137901485 28 9.9314042704 29 10.2490665803 30 10.5667722335 31 10.8845170144 32 11.2022972374

A pattern of six leaves a gap in the middle. You can leave the stack node there for anyone who wants the volume to go to 43.

https://en.wikipedia.org/wiki/Circle_packing_in_a_circle

Absolutely. Besides, my brain is still reeling from getting my Mars lander working in RSS+RO. What i should have said was that I lokoed at the diagrams and thought "race to mod", but then over-rode that thought when I immediately thought "this should be part of a SpaceY thing".

I was just looking at the published diagrams and thinking there's going to be a race to make a mod for that beast. Then (of course) I thought of SpaceY.

Switching the interiors to the RPM version is Module Manager code, and MM isn't updated. Making the props function uses the RPM Modules so they won't until this is updated. The dials and so forth will exist for adding to IVAs, so long as those are the default for that IVA and not reliant on MM config. Virtually all modules (aka DLL files) will need recompiling and often a juggle in which references there are. And, the pre-release 1.2 is primarily for testing stock, and is rapidly changing. There aren't going to be many mod authors updating their stuff until the actual release version of 1.2 comes out. Even if they have already updated their code. Releasing for specific builds of 1.2 would be a version control nightmare, esp when you factor in users that might never update to the release KSP edition of that mod.

I've been doing various types of IT support for decades now. And, one thing I've learnt is, you shouldn't take it home with you (unless someone's paying you to do so, on a short term basis), and you really shouldn't take it on holiday. I know you're personally invested in this, but everyone needs time off. So, feel free to be slightly annoyed that there's stuff going on and that you can't fix it. That's understandable and human. But then turn that off and go have a relaxing time on vacation. And, as @katateochi said, KSP is currently in that limbo state of a large section of the community using a pre-release, which means very little mods anyway, and mostly modders won't want to mess with their release versions (even if they're madly updating RCS and checking what explodes, they won't necessarily update anything 'till the prerelease is done). So, for the occasional panicked person, it's probably "OMG the worst time for spacedock to have issues!!!!!", but for 99% of people it's probably the best time ever. And who likes that 1% anyway? :-)

Mixing a generic animation module and the ModuleAeroSurface doesn't work so well. With messing around, you can get things deployed at different combinations, but nothing works to start with without right click actions, and usually not until you've deployed, retracted, and deployed again. So I'm thinking of just making the airbrakes deploy much further, as their actually fairly easy to limit to a smaller angle after attached.

On airbrakes; I had a go at adding a generic animation where they would fold down as a kind of spread out ramp. And they told out nicely and my first guess at angle turned out pretty close to touching the ground. But once the animation is done the airbrake module tales over again and sets the angle back. I might be able to parent the airbrake to an animated empty and get it working that way. I'll have to try after work.

That was my first thought ages back, but an increase in force should improve that. I've also been staging mine to match the ballute deployment, so it *should* coincide with a chunk of Gs helping it along. But it still got stuck. I think I've found the issue. The base collider is a set of six (duplicated) mesh colliders arranged in a circle so they have a gap. But even though the whole purpose of that is to compensate for not being able to have concave shapes, I completely forgot about that when making the inside edge. The inside of the circle was matching the actual circle, and formed a hexagon smaller than the gap when forced into convex shapes. So, in blender it looked like; But in Unity with the colliders showing, it looks like; Fixin and testing now. And the engine cover cannon works nicely. I might tone that 10000 ejection Force down a bit. http://imgur.com/a/FNLXP The main change that will make the engine cover function is this file; https://www.dropbox.com/s/ws1de1nme5zl0a7/NewModel.mu?dl=0 It's the model for the descent base, it overwrites the one in NAR_MEM/Parts/MEM-DescentBase/ The various tweaks will eventually be rolled into a mod update, probably once 1.2 is a real thing. This is getting a bit piece meal though. :-)

I will get to the bottom of this forceless decouple. Here's my test rig, in stock, because this isn't an RO specific thing. And in 1.2pre, as it's an issue there as well. What it's not; too low ejectionForce, because cranking a 200kg piece with 10tonnes of force should make it move. Not that the stack nodes were both negativeY, I've adjusted the centre point to a point part way between the stack nodes. (this change will roll into the next update, as it's a *should have been fixed anyway* fix. Not the only .15m gap between the stack nodes, I tried with artificially increased nodes .6m apart. Not that the collider was too big, I shrunk it a bit to test. (I will double check the plainly confusing, overly complex descent base collider soon) Not interaction with ablator resource (removed), or in fact anything ablatorish (test removal of the modules all together). Testrig

That engine cover has been annoying me for ages. There's something odd about how the ModuleDecouple functions. There's plenty of ejection force, but it decouples like there isn't any. I've had the same issue with other jettisonable parts. But then others, that I'd expect issues with, like the half cone shell pieces, jettison really nicely. I'll poke around the forums and see if others have had similar issues.

The airbrakes seem OK for CoM and CoL in the VAB display, although I'm unsure if FAR changes the VAB display along with behaviour though, so I'm not sure if what shows relates to what behaviour to expect. BUT, the descent base definitely has issues. The centre of lift appears well below the bottom of the craft. I'm surprised all MEMs using that aren't facing forward. EG: I've done a couple of flights using the aero overlay. Again, I don't know if FAR changes this or if it's just showing stock forces. But, looks like the aero forces are applied at the hinge point of the airbrakes. But, the big difference looks to be they provide next to zero forces when not deployed, but also seem to prevent the main body providing any drag. So the craft is experiencing aero as if it was a flat pancake shaped like the base, but with a centre of mass higher up. FIIK what causes this, or if I'm really seeing what I seem to be seeing. It just looks like the closed airbrakes forma protective shell around the craft that prevents any aero forces from covered areas, but doesn't provide any of it's own. I'm going to go with "deploy airbrakes early".

I was getting the same, re: closed airbrakes=prograde, open=retrograde. I think they have a size, and thus a drag cube. And that drag is applied as if the centre is at the part's root, which is the middle of the hinge. I have to figure how to alter that drag centre in a way that's appropriate for an airbrake (ie, it has to move).

I don't think so. It seems to happen whether I have SAS set to retrograde or radial out, which shouldn't be affected by losing the definition of prograde etc. It's like hitting a trampoline. Coming down nice and gentle, and suddenly the craft is doing cartwheels, usually with about 1(local) G of TWR pointing the wrong way. If no-one else sees this, I'll put it down to "weird sh!t with my install/bunch of mods". And I tried getting MJ to land, but I couldn't tell if it was experiencing the same issue, as MJ is still of the opinion that throttling the descent engines is something that can happen after passing through a few km of regolith. I was getting some strange behaviour with the airbrakes as well. I need to set the CoL I think. I thought the control surface modules would do that. But the part's root is at the hinge, so the drag will centre on that. That's not so good for either state. I'll have to check how the stock airbrakes handle it. Maybe I shouldn't have a collider for the airbrake surface. Maybe I should have a CoL adjustment. Not sure. Also thinking (if I can keep the collider) that I could add a generic animation that has them fold further out and provide ramps. Especially as I notice Mars' gravity is just enough to make Kerbal rocket packs useless. And full scale, it's big compared to the little green men

My craft still wants to turn upside down at ~100m, but by expecting that, and keeping the ballute I've managed a landing with the craft the pointy end upwards. And the lab decoupler CLS config isn't working. So no moving kerbanauts to the lab, or an airlock. :-( I'll have a go at fixing that. Gotta go do that going-to-work thing. But I'll see if I can get onto the surface using the airbrake alternative next (after fixing that decoupler). PS: Plenty of fuel in the descent stage without extra tanks now that the descent engine thrust isn't lame. The remainder shown is after quite some hovering balance work going downslope even.

My flights keep doing daft things at about 100m off the ground. The SAS just goes nuts and decides up is down or retro is sideways. At first I thought it was bad interactions with the chutes, but I made sure to cut the chutes this time. If it happened higher up, or just happened once, I think I could recover. But it's like I have to pass through a field of stupid to get to the ground, and with the ground that close, the only survival method is throttle-up-abort, and then I have to come back through the stupid field. nerdraaaaaaaaage

I feel the pain. All you need is a fairly obscure subject and a few posts. I doubt my Land Rover Defender mod will EVER get there, but last time I googled "North American Rockwell Mars Excursion Module" the 1st hit was my mod.