TiktaalikDreaming

Yeah, something's wrong with the deltaV and the whole lot of the deorbit stack. It used to be fine to come in on a highly elliptical orbit, but now it'll basically manage a deorbit burn on a just above atmosphere circular orbit, or just shift it slightly. Mixed with it not showing anything for a plume, I suspect all sorts of weirdness. I'm going to do the full RO engine thing to it. I think RO/RFuels doesn't really have any variation in the solid fuels. Which is why there's only minimal RF config. But seems having a more detailed config might be required. I'd like to at least get a plume Darn it. The RCS is also overpowered. For most of the trip down, I have it limited to around the 10-20%. I only allow it full thrust if I'm using it to adjust orbit or something. If you use it at full thrust, it'll burn through fairly quickly. Just looking at the RO config for the deorbit single piece engine. It added ModuleEnginesRF without removing ModuleEngines. I suspect a working fix will be coming shortly.

Killing off all the old chute parts plus their MM config, and the file ModuleManager.ConfigCache seems to have gotten me parachutes that are visible. I probably should have killed those things off one at a time to check which. https://github.com/TiktaalikDreaming/NAR_MEM/releases/tag/0.14ro2

Um, yeah. The github is a straight copy of my working folders. So it does tend to have a lot of excess bits n bobs. A bit weird you're not getting the new ballute. But it does (unlike the drogue) have the same part name. Still can't get the parachutes to be visible, except for the final stage of deployment of the ballute. And I cut down the number of spare chutes from the default (the NAR MEM chutes were huge, and heavy, no way they'd be carrying lots of spares), but when in flight it's showing 5 spares still. So maybe we both have lingering module manager weirdness, or I have lingering module manager files. I think I'm sold on the new chute units, so I'll kill off the old ones. And find and kill off all the old parts and old MM config bits. I have no idea how many bad landings I'd done in the last 16 hours or so. 3 worked. But then I had the staging wrong for ascent and made things explode. I think in all cases, the kerbanauts were capable of walking away. But that doesn't do you a lot of good when there's no-where to walk to.

OK, this isn't a big report, it's more of a "has anyone seen this weirdness before?" question. If the answer is no, I'll do more digging before I even chose what thing needs a big report. I'm doing up some (well updating to 1.2.2 from 1.0.5, it's been a while) real cute and realism overhaul config for some chutes in a mod. And they function. That is, they deploy correctly, cut when asked etc. But rc isn't using the meshes or animations it's been told to use. With one exception. One chute, a ballute, appears out of thin air and inflates to full when it should be going from partly deployed to fully deployed. So that bit is fine. But the initial deployment is kaput. Without visuals, I'm not 100% sure the other chute wouldn't do the same. It might not be triggering full deployment. I've checked the obvious things. Mesh names. Animation stage names. I'm no where near my wit's end, but find myself thinking about it while away from my computer. And I can ask if someone's seen this before from my phone, even if I can't go check stuff from here. And, like most times when sitting down to write out a question I find I've established a few paths to check. Namely, I should check the mm patch cache to verify in patching what I think I'm patching.

Well, today has taught me I've lost the skill of judging when to initiate my landing burn. If it weren't for "revert to...", Mars would now be scattered with the debris of several almost landed MEMs. I shall land and test the ascent stage some time, I'm sure. Still puzzled by the parachute issues. I'll wander off and check the RealChute topic. Things do seem to basically be working as well as can be expected.

That's definitely not using the new config for some reason. Apart from the Ballute. Which makes it just a tad stranger. Actually, the Ballute didn't change name, so it's just using the existing rescale. Can you check the file was in the same place and had same file system properties (permissions, ownership etc) as the other realism config file? It seems the game just isn't reading it. I've also put a pre-release quasi updated package up on git to avoid any mismatch there might be between the core parts and the RO config. If you delete the existing NAR MEM and replace from the github release https://github.com/TiktaalikDreaming/NAR_MEM/releases/tag/0.14ro it *should* apply RO config to the parts. Fixes in this RO config. "fixed" the drogue from being totally daft, by applying the correct mesh names to the config bits, so now it knows the drogue chute is the chute part so shouldn't start extended. RCS fixed so it uses hydrazine and ClF3. Fixed up the TAC Life Support bits so they should only apply if TACLS is installed. Marked the RO converted parts as RO so they don't show up as nonRO in VAB Known issues: Chutes are still being weird in that they don't seem to animate, so when deployed, nothing much happens, when they go to fully deployed they go to the start of that animation, which looks a lot like partly deployed. Still no plume from deorbit solid rockets multipart deorbit module is strange and not scaled right, and is basically unusable No testing of the ascent stage has happened yet, because I staged for ascent on my test in such a way that parts ran into each other and the ascent engine exploded. Who woulda thunk it could be an issue with that design???

it's an additional MM patch file for the new parts. So it just gets added into the configs folder. No replacing anything.

OK, some config here - https://github.com/TiktaalikDreaming/NAR_MEM/blob/master/Config/NewPartsRealismConfigs.cfg I spot at least a few issues. RCS isn't changed but RCS fuel is, I assume because the underlying RCS changed modules in 1.2 Taking out the hydrazine and ClF3 and replacing with monoprop does fix this, but it'd be better to fix the RCS in the MM patch. The drogue is being stupid. Not sure why. Will look. No flames visible for the de-orbit engines. They still function. I assume something silly going on with real plume config.

I'm still messaging around getting a working RO install, but I think the only remaining hurdle is not trying to use the 8k textures in RSS. But, I have to go to work, so that's on hold for some hours. There's some untested RO and RF config in the github (link to be added when I'm not on a bus... and have actually updated github version).

Ha! Now read back through the last fifty or so forum pages. The legs are old, and don't work.

Cool. I have an aborted attempt to get a RO 1.2.2 install working somewhere on this PC. I'll fix that up and do up some config.

On yeah. There's no RO config for the parts that have split, so they'll be completely wrong. Oh, which version of ksp are you using for ro? 1.2.2?

Glad someone else said something. I was trying to think of a forum safe way of saying what I was thinking. Seriously, RD had made his position clear. If you want to play with some patch converting the drive, go for it, but don't expect support from RD. Stopping before I get sweary.

It was a reference to Austin Powers before autocorrect got to it.

Those parts will get the revamp treatment too. Not too worry. When I get there. Bogged down a bit with the lab IVA at the moment.

The test thing had a battery and a remote control unit at the top. Control unit should be even more buoyant. But, buoyancy is easier to measure if the item doesn't completely sink. I'll add MM to my test.

That ship looks just like a... Private! What are you starting at??

Can you check with an actual stock install? I can't replicate. My first attempt, I thought, hey, that's very buoyant ore, but it turns out the large wheels are super buoyant; So, puzzlement, Followed by "what happens if I dump the ore; So, those wheels are really seriously buoyant. AFAIK, buoyancy is determined by mass vs collider volume. And wheels are a bit weird with colliders, for one, the wheel collider system in Unity uses a 2D circle. There may be some guestimates working badly with those wheels. So, I just tested with rockets. Cos rockets make everything better; Buoyancy with purely stock everything, no hyperedit, no nothing except the squad folder (That's still more buoyant than I'd set for giant tubs full of rock, but meh) And with stock plus ModPods only; Can you check for any MM patches that might be lingering in the system? If you open an cmd prompt, navigate to the GameData folder (You can I think Right click a folder in explorer and select "Open Command Prompt Here"). And run the command findstr /BLS "@" *.cfg That should list out anything written as a MM patch to alter other parts.

No. I never even checked buoyancy. There's no code, no resource changes, no module manager patches. I'm a bit baffled to be honest. I'll grab a clean KSP 1.3.1 and do some tests.

That's super nice. I especially like the changes to the engine bell and the piping. Is that some sort of isometric view? It may be optical illusion, but it looks a bit like anti-perspective almost.

That's um, very weird. You might want to check if anything else is installed in GameData, because ModPods doesn't (shouldn't) affect any other parts. I'd be looking for resource mods like Community Resource Pack, which has a MetallicOre that's 55% as heavy as stock ore. Which version of ModPods? And which version of KSP? I'll double check there's nothing like a misconfigured module manager patch. There's actually no module manager patches in the mod. If it's to blame (I'm not saying it isn't, working with computers means you can't maintain a belief in a deterministic universe) then it's a properly weird bug.

Just messing around trying to find how to embed imgur links in the current combination of shifting forum code and shifting imgur embed stuff. Please ignore this post https://imgur.com/gallery/FGQa0 <blockquote class="imgur-embed-pub" lang="en" data-id="a/FGQa0"><a href="//imgur.com/FGQa0">Duna Excursion Module mission cycle</a></blockquote><script async src="//s.imgur.com/min/embed.js" charset="utf-8"></script>

I concur. Damn yooos imgur!!!!

For really large craft, KJR works better. Of course it's nice to be able to keep it stock, so until you reach the point where autostrut isn't cutting it, it's probably the preferred solution. A full Saturn V stack may be at the level you would be thinking KJR though.

Updated on Spacedock. BUT: WARNING!!! It will break saved craft, as the old ascent module has been removed. I also updated the saved craft file and am testing that at the moment. So I know I've forgotten something... Thankfully it's Duna not Mars.