TiktaalikDreaming

Thanks. I've been a bit low on time for the last few months, so I can't promise any deadlines. But a ladder is on the radar. And a new comms dish. Hope you find some eyes.

That's one area where I've found no guidance from Rockwell documents. Lots of ideas from various artists' impressions, although some of those would be bad ideas. Most of the time I've just been using the stock extending leaders (which would experience a lot of reentry heat) or just jumping. The realistic thing to do would be to have a fold away stair. Mars isn't the moon, gravity is higher, and once you add on a suit, I don't think you could realistically expect silly high jumps. And a ladder would need to angle away due to the craft's shape, so folding stairs. The other option would be a ramp, which would be better for equipment loading, but be a lot longer, so a lot heavier. I'm short, I've thought about it, but never really decided.

It's more in a coma. I need the time to learn to code modules and then rewrite the way it interacts with the game. The logic sections can then be lifted out and put into the new framework. This c# stuff isn't coming easy to me though.

It's essentially a resource converter in KSP language. Feed in widely available numbers for liquid fuel and oxidizer use, plus electrical output (guessing at conversion rates), and then discover you need a LOT of compressed air or a slightly smaller LOT of oxidizer (assuming LOX). They'll generally be more powerful but thirstier than fuel cells. And run a lot leaner (oxygen rich).

They're standard entries for the "tags" field. For example the Mk1-3 pod has the following #autoLOC_501807 = capsule cmg control ?eva fly gyro ?iva moment pilot react rocket space stab steer torque The "let's blindly convert from character encoding to different character encoding" entries are usually things like "smart" quote marks or emdashes and so on. EG: the quote marks from Mac documents used to show up around the internet as weird Q-like characters. It's just a feature of taking one extended character set and blindly assuming you can use a different extended character set. The characters making weird symbols usually aren't invisible, but they might be functionally invisible.

Yes. But, if I was to set up 2 chutes on one part, they wouldn't behave like 2 chutes. Yes, there'd be visual excuses for a CoM as it is matching the centre of where the chute pops out from, but there's all sorts of things that would go wrong. Or at least wonky. The main trouble with building a pod with the chute integrated in the same part is the chute creates a drag force at the centre of the chute's part. So, if it's the main part, then it doesn't provide any directional control. Also, I'd re-collide with the joys of multiple staging actions on one part. Or lose the retro deorbit solids. I did experiment with just a magical central chute to see how it behaved, ignoring the "there's nowhere to release the chute from" feature. And that still looked dodgy as. Conclusion: Chutes need to be separate parts, or weirdness ensues.

Two answers. I've looked at ways of simplifying the cute unit's attachment. I hadn't actually considered just altering the look to make it more obvious. It is a passion when the orientation isn't upright (like if it's being installed in the nest). If I get time this weekend, I'll make some changes. I am actually working on issues with a CLS patch. There's an example on the GitHub files (not packed yet; https://github.com/TiktaalikDreaming/KOOSE/blob/master/Parts/KooSE_CLS_RT.cfg). The problem is, the multiple docked craft seem to trigger CLS into segregating the craft regardless of the settings in the patch.

I've had a bit of time recently to go back and revisit the Gas Core rocket. As suggested, this will be a multimode beast this time around. High or low temp, low or high thrust, high or low ISP. So far, I've managed the hydrogen turbines and pumps and the various bits of LH plumbing. It needs a Liquid Helium system with plumbing and both a Uranium Hexafluoride feed system (the fuel) and a powdered tungsten feed (used to make the LH opaque). So there's more plumbing to come. But H2 makes up 99% of the exhaust by mass, so the plumbing requirements on the other systems will be much much lower (except LHe, it's for cooling and none goes out the exhaust).

Looking a bit ogrish. Nyrath would be proud.

Hmmm m... I might have some minimal (ISP) free hosting I could use.

It may be about time to start thinking of adding 1.4.4 to the version list. Apparently it's out.

The hatch, docking port and window are the one exit. On top. Finding an area big enough for a kerbal head is tricky at times. I should really take a look at comfortable landings. It looks awesome.

Yep. And it was pretty clear that I either moved the chute to the CoM which made no sense, or moved it to a different part, like every other chute in the game. I have some nice screengrabs of the single part edition floating down with the chute offset and the pod perfectly upright. Doesn't look weird at all, honest;

Oh, I was still using unity 5 for particles effects as the updated ui came with a stack of things that don't work. Only one particle emitter is a bit excrement.

Thanks. The main reason the parachute is even a separate part was because it acted very very strangely when it came from the pod itself. At least with it a separate part, the final decent looks roughly right. I'm actually a bit surprised you are the first person to mention the oddness. . I guess most ksp players are now used to weird parachute behaviour.

Another thing I've noticed, not sure if I've broken my part tools, or if it's a unity 2017 thing, since if the ksp shaders seem to be missing definitions. Imported objects using those shaders get unity pink, and selecting the shader (which are still selectable) the shader definition is empty, ie you can't choose textures or settings. I'm missing bumped specular (which I didn't notice because I was using the emissive equivalent) and one of the particle effects shaders. anyone else seeing similar?

That's unfortunately how the parachute module works. It's a lot less noticeable normally with his chutes tend to be arranged. But you'll notice similar behaviour if your non koose pod is facing the wrong way, the parachutes will deploy backwards until the animation has finished, then the module takes over and reoreints them. I'm aware of the weirdness though. I'm tempted to test some part reorientation. The parachute animation is straight up, as it has to be, but there's no reason the chute base can't be rotated a bit except if need to do maths for the stack node. The lazy bit of me suggests I should just speed up the deployment.

Yeah, the standard mattress plan has the chutes or whatever discarded before the last bit of landing, but due to ksp, I keep mine until landing. If it's a slope, after landing.

Interesting (and just as well) it doesn't do it on a suicide burn. It "feels" like hitting a jelly trampoline. I've usually been able to recover. But only just.

All the masses are from a bunch of rl sources. Sometimes divided up a bit arbitrarily. I'm glad you asked about that spinning behaviour. I was starting to think it was just me. I've never been able to find a reason for it. But noone but me seemed to be having the trouble. Which parts changed between issue and not issue? Just the cabin? Thanks.

Somehow I missed this when it was posted. I suspect the issue is your animation name. That's baked into the mu file and needs to match, so change to animationName = Extend And it might work

Thanks. Is an appreciative comment from you a speciation? A lot of the work to make this RO compliant came from @Nittany Tiger Plus North American Rockwell of course, for the numbers and design. Many things in the design seemed crazy at first. But they actually do seem to work.

RCS only got messed up in 1.4 if it was using the older module. I'm fairly sure I only used the newer moduleRCSFX for the pods.

I haven't yet looked at various compatibility patches for other mods. The pod will automatically be CLS passable, as it has a crew value. The nest will just need a few lines of MM code. But it *should* also have RealFuel patches and RSS/RO patches, and patches for all sorts of life support mods and so on. While I do usually make those, they're not inherently part of the mod itself.

Yes, but it's not defined in the config. The docking port on the koose uses the same module, with the same settings as the junior port. So it's whatever election force is built into the stock docking node module.