TiktaalikDreaming

Main download site now updated. That was going to happen a lot faster, but my internets died horribly.

Interim release https://github.com/TiktaalikDreaming/ModPods/releases/tag/1.0.6 Github releases won't necessarily be all cleaned up and tidy. But I don't have access to my normal build folders at work\\\ where I currently am. EDIT: the other thing about the git things, they haven't been DDS'ed. My work flow has them DDS'ed after copying them to a build folder for tidy up.

Ha! Well spotted good sir. Fix incoming. After I grumble some about damned typos.

It's possible to deal with the same way as for rpm though. You just make a second IVA and have some mm config redirect the internal space to that of RSS is installed. Resized seats make the IVA look spacious. Maybe a spiral staircase and a pool table?

Yeah, I very much want to do an RPM IVA. As for RO/RSS, the rescaling messes with things. I think for that I'll do a completely different IVA (same internal walls, but otherwise, different) this time. The seating has to be different or it looks daft. And the head position needs to match them windows. etc etc. It's funny (a bit) that the RO IVAs are pretty much forced to be less-matching the real world spaces, because RSS doesn't rescale the kerbanauts.

I knew this github thing would be useful... https://github.com/TiktaalikDreaming/NAR_MEM/blob/master/Parts/DeOrbitFrame/DeOrbitUnit.cfg

Yeah, thinking you could raise the de-orbit engine frame to it's old mass, and drop the actual mini SRB pieces to a small number (plus the propellant). Total mass should stay about the same. I'm assuming with RO, RSS, and the size of that thing you're running with KJR. Which means I can go take a squiz at how the stiffness is actually calculated. Or at least adjusted. There may be ways I can improve the stiffness, like with the parachute bases, adding spurious non-colliding colliders. oooo... MaximumPossiblePartMass Time to add a max 9999999999, default 0 ablator resource to EVERYTHING! Or, change the frame RO MM patch section to read @PART[MEMDeOrbiterFrame]:NEEDS[RealismOverhaul] { @manufacturer = North American Rockwell Space Division @rescaleFactor = 1.0 @mass = 0.065 RESOURCE { name = Ablator amount = 0 maxAmount = 1000 } }

non-RPM IVA first... still quite a bit of work to do.

The only part with up to date texture is the crew cabin. The parachute frame and ascent stage body are plain base colours with panel edges, which is why they look different. That's one vote for 2x IVAs. That's pretty much all I need. I'll work on a stock prop IVA

Yeah? I'd have to scrounge a bit for all the mods you're using, but a fair chunk are just part of what I already have on the old 1.1.RO I did go through testing what does and doesn't affect joint stiffness, and I've completely forgotten. I do remember colliders make a fair sized difference, so i'll check that. Can't check that at work though. Need Unity. It'll be hours before I can look again. But if you can find the bit of config for the deorbit engine frame and adjust the mass for RO/RSS, that would eliminate (or implicate) part mass; @PART[MEMDeOrbiterFrame]:NEEDS[RealismOverhaul] { @manufacturer = North American Rockwell Space Division @rescaleFactor = 1.0 //325 * 9.81 * ln(49,437/46.357) = 205 m/s (200 m/s was the real thing) @mass = 0.065 } change to @PART[MEMDeOrbiterFrame]:NEEDS[RealismOverhaul] { @manufacturer = North American Rockwell Space Division @rescaleFactor = 1.0 //325 * 9.81 * ln(49,437/46.357) = 205 m/s (200 m/s was the real thing) @mass = 0.276689484 (Mass of the monolithic edition) } UPDATE Well, the stack nodes and colliders are exactly the same. So my guess is on the mass. Presumably the mass of a part adjusts the stiffness KSP assigns to the nodes.

There could be differences in the stack nodes. I'll check. And double check the booster units don't have bottom nodes. They're a size 0 node. I'll check if there's any other differences too. It's possibly related to the mass change of the part the nodes are on.

IVA is underway. I'll be using RPM props and marking it as a dependency going forward. If anyone desperately wants the MEM without RPM props, let me know and I'll do a quick stock IVA, and call the rpm IVA using modulemanager code instead. But, just look at those RCS/SAS switches. You know you want RPM. I know I don't want to do two IVAs.

The de-orbit rockets? That's weird as .... I'll recheck (possibly for the first time) the masses. Do you have anything linked to the bottom of the de-orbit motors? It has a bottom stack node, but it wouldn't normally be used.

I'll certainly look at the Texture Replacer mod. I'm not 100% sure I'll use it for this mod, but there are other places I used to use a reflective shader until the stand-alone one died off. Large metal brace thing... This?

Just about done the crew cabin. With lit windows; A functioning emergency hatch; And a lot of work to do updating the IVA

Just for the record, I've githubbed my dev edition of this (and other) mod. https://github.com/TiktaalikDreaming/NAR_MEM If you want to take a peek at where I'm up to, that's where the dev versions will be. Releases will be marked as releases there, but may include dev parts etc that aren't included in the release on Spacedock.

I've cut some new windows (with non-applied transform, so I haven't quite commited yet). The rectangular windows are just gone. They were daftly placed, and when I looked at where windows should be for the pilot to see the horizon, completely the wrong height. They're replaced with a window on either side, at pilot head height. The big funny looking windows are now classic Apollo/Orion style inset windows. Smaller, and in line with the pilot's head. Some adjustments to the UV and textures will be needed.

My assumptions fueled choosing values for this mod's parts. I can't see them magically cascading through to other mods. The mod uses Liquid Fuel (plus atmosphere via air intake or oxidizer via tank) to create EC. EC drives the wheels. The only part where the conversion from kW to EC took effect was on some note paper so I could decide how much EC the motor should generate.

Removed all the windows, just about ready to cut new ones;

OK, the windows. I was actually going to look up the current stock parts. For colour. The actual window placement is odd. The drawings from NAR and Scott Lowther show the rectangular windows which might be nice for viewing the landscape once landed, but are useless for things like docking. And the four evenly spaced windows really makes no sense. I added the big funny shaped blob things so you can see where you're going. None are inset like they would be on an earth/kerbin re-entry vehicle, as we're dealing with 1% the atmosphere. But, yes, I do see they're too big. I should grab my IVA and do some proper window placement. Should be able to see the horizon to the side when landing. Should be able to see forward when docking. The rest should really be by instruments. Paneling. Well, once I add an actual shading layer it may look different. That's just the panel normal map with a 12% overlay of the bump map for the normal to make the edges a bit darker. Plus some signage etc. So, just slightly more than plain colour plus edges. It's enough to get the basic look without spending too much time on stuff I might destroy to (for instance) change all the window placement. OK, totally going to use the nodes. Forgot to mention on the other reply.

Some parts are moving along. I have to redo my trig (hopefully by finding the old spreadsheet and adding 15degrees) for the attach nodes for the disposable ascent tanks. The top is the new MEM end cap with BDB chutes and docking port, mostly to check they work, and at that stage I didn't have a MEM chute. But, with four ballutes (over kill), and it failed to launch from Kerbin sea level So, popped the top on a different rocket, and tested it out;

Just a quick note that I've fixed the thrust offset when physX can't be bothered using all 36 thrust transforms, by finally realising the updated engine module allows thrust and engine fx to use different transforms. So I can keep all the pretty, while using just a single central thrust vector

Love it.

Well, it's taken me a year or two to notice, but moduleEnginesFX allows the thrust vector to be independent of the various visual effects. I'm currently converting all the engine parts so they have a single thrust vector and then the 36 odd visual effects nodes. This should mean there will be no more weird offset thrust, regardless of how loaded up the physics engine happens to be. Edit I've uploaded version 1.0.5,which should remove the chance of off centre thrust for good.

The choice of material in blender was mostly just to exaggerate the normals yeah. Blender can do weird sh*t with normal maps. I've just been importing mu files to check the sizes and so on. I'd like to keep using my own meshes, but it's nice to see how things are put together. On that topic, I've revised the parachute mount this morning to better fit the BDB chutes, and redesigned the MEM Chute mounts. Again, materials (rubber, red plastic and glass) selected to show the different parts; With a tiny bit of clipping, this now fits the BDB Apollo (um, forgot the KSP name) parachutes. I had to alter the angle a bit on the mount, but not too much.