TiktaalikDreaming

The only issue there, is I haven't really got the hang of C# and the chance of me being able to code that up, is unlikely. If you're interested, I'm happy to make the 3d assets and mess with unity and so on. Apart from that, the mod has been updated to add in RealFuel config, independent of realism overhaul.

Let me know how it goes. I found it interesting as a concept, but a bit annoying. If you think it's worth revisiting in 1.2.2 (or 1.3, some year), I think I'd rather redo the assets from scratch anyway.

Confirmed my suspicion that removing the current RO config works better. RO sees an unpatched RCS, converts it to hydrazine, and carries on. I'll update with an unRO-configed version that will stop being a nuisance, and look at adding back in fuel choices later.

The RO config is in need of updating. Seeing as stock now uses ModuleRCSFX and the 1.1 ro patch replaced ModuleRCS with ModuleRCSFX there's going to be issues. I can confirm I get the same silly effects. I'll have a go at fixing this in the next day or so. Off to work for me right now though.

I actually did a mod like that before this mod. It can work, but yeah, it increases part count for the craft and more annoyingly, it's really insanely fiddly adding on the nozzles. At least it was back in the day (0.8ish from memory). Things might have improved enough in the VAB UI to make it workable. It was a PC and a mod-hosting-solution ago though, and I don't seem to have any record of it. Found it on the forums, only 2015 (1.0) age; it's a bit primitive, and is most likely undownloadable due to kerbalstuff not being there. @basila, I'll take a look. I had a nice test install of RO+ everything way back in 1.1.3, but they were a long time getting RO into 1.2.2, and I just stopped checking if it was updated. I don't currently have a RO install. And all th modules for RCS changed in stock, which has probably stuffed up the RO config patch.

Only just noticed this is in both the dev and prod threads. As discussed, this was due to limitations in the physics system vs CPU capability. Not everyone will notice it (depends on computer). Should be significantly reduced by updating to 1.0.3 which has 18 thrust vectors instead of 36.

OK, 1.0.3 released. Half the nozzles are essentially off. You get the same thrust, but spread over less thrust vectors (yay for KSP working that out for me). I'm not guaranteeing the 18 vectors will be OK, but it should be OK more often than 36. I'm not really sure how low I should take this. As the number drops, the visual effects get sparser, and it's not the sort of engine that would look right with just one big effect in the middle. So, I'd like to keep some semblance of the multi-nozzle visual effect. Obviously not at the cost of it being completely useless though. Some time, hopefully this weekend, I'll load this up on the dodgy laptop and see how it goes. I suspect the issue will escalate as CPU gets slower. Thus testing with something slower than my desktop. The test mu file linked a few posts above, has 12 nozzles if people want to test that (presumably only if they have issues with the 18). I'll end up doing a series of different numbers if the dodgy laptop can't handle the 18, for testing. Also, if you installed that test mu, and are running CKAN, I'm not sure if you might need to remove it before CKAN will let you update to 1.0.3. Oh, and since I first made these parts I finally got around to adding the tags for hiding things in the VAB icons, so the fairing are now hidden in the icon view. And I corrected the incorrect name of the thrust vector for surface effects, so you should get nice KSP ground scatter with associated drop in frame rate

Here's a view of the tilt on the heat shield engine, The Z rotation doesn't affect anything as it's the Z vector that the game uses. (or Y for RCS, 'cos reasons). The 13.233 degrees beyond the 180 "pointing down" is intentional. But that 0.182d off to the side will induce a roll. On the left you can see I bundle the nozzles into 4, with child thrusts, and then copy the sets of 4 around. So, I should be fine to just delete the copies, fix 4 vectors (already done, which is why this screen shot is of the second group of 4) and re-copy. I just need to decide how many nozzles should have thrust vectors. Gonna try half.

Each thrust vector is angled in 13degrees. It should average out over all the nozzles. It's so you get this effect; That said, clearly the game chooses to simplify to a subset of nozzles at times, so I shall be dropping off probably half to two-thirds of the thrust vectors for the next release. I don't think it likes 36 thrust vectors. Oh, and checking Unity, there was a slight tilt to the thrust vectors (0.18d) on the heat-shield style as well, which would have (by virtue of copying it all around) introduced a rotation. That will be being deleted as well. Even if (unintentionally) it may have caused a cool, unrealistic spiral effect (but too subtle to really see). Now, I have to go experiment with how many vectors seems stable with an issue that seems intermittent. Yay! I love diagnosing intermittent things.

OK. In that case, I'll do one with just less thrust transforms, rather than removing all the visible nozzles as well. That was purely to get the thing done quickly, as the hierarchy in Unity made that really easy to do. Legs. I've been working on some really simple extending legs like they planned for the ROMBUS. They'd be next to useless for a lot of craft, because they only really work if there's a taper on the side walls. But they should work nicely for this

ModPod assets; https://www.dropbox.com/sh/v4lua8t89qr54j9/AABMKwld7gNYe-LQaU_-_cqna?dl=0 It's not the whole lot, just wading through all the pngs and .meta files looking for the xcf and blend files.

There should be no thrust offset. And sometimes there isn't. Weird. I checked the blender model, then the unity build, and the config for the part. I had the wrong transform name for the ground effect, but that would just lead to no exhaust fancy effects as it interacts with the ground. Then, I built a 3 stacker, mk1-2 pod, sz2-3 crew pod, sz3-4 service module and then the rombus style engine. Stuck some legs on it and took off. First flight was weird. The engine effects came out as they should, but the smoke effect definitely had an angled offset, right at the root, and the thrust was offset as you've been experiencing. So, I reverted, and did a more gentle take off (the first was a "how much G does it pull when still fully fueled?" take off). And the thrust was dead centre. Throttled to full, still dead centre. Cut the engines and then back on, still OK. So, I can, sometimes replicate the issue. I'll reiterate, the engine should not have an offset. There's a lifting body effect on the base so it behaves like a normal re-entry shield, but that should not effect the engine, as they're different modules. At a guess, I would assume it has to do with the engine effect being spread across 36 nozzles, all with their own thrust vector, and the game may struggle with that. maybe, sometimes it just does some of those thrust vectors, at random. I'll make a more minimal version and see if I get the same issue. If so, I may halve the nozzles or nozzle effects. Can you try dropping the mu file from https://dev.spacedock.info/TiktaalikDreaming/ModPods/src/master/Parts/Mk3to4/Rengine into your install? See if the off-centre thrust gets any better?

For some strange reason I've been flat out at work since Saturday too. I can do the Unity thing. I've fought getting Unity onto an ubuntu machine a few times (they recommend that flavour of nix), and although from time to time I've succeeded, it's never been totally satisfactory. And KSP can be picky about which version you use. For IVAs, I usually make them as separate meshes within the same blender file and do all the re-orienting in Unity. It helps that that means you can use boolean modifiers to drill windows through both outside and inside meshes using the same object, and line things up in other ways. I'll share my mess of Mod Pod work. It has some stuff to get started on at least. Including my "blanks" for the size, and the base collider mesh. I'll pop it up on the dev.spacedock.info place once I get around to a non-work computer.

I'm suspecting I'll need to not be extending Part, but PartModule to make this work. rewrite time coming up. :-(

thanks for the offers. A lot of the work I need to get done for the half finished parts is in Unity, which still doesn't work too well in 'nix. And pretty much why I still use Windoze The C# stuff is for the Orion. And I'm fairly sure I know what I need to do, I'm just reluctant to start. It needs to move from extending "Part" to extending "PartModule", which will break most of it, but enable fixing it. All that said, if you want to do up a crew module going from 3.75m to 5m, feel free. At that size, there's pretty much no existing guides for style. I'm at work at the moment, but I can get the heights if you'd like. The crew/control modules aren't generally animated, so shouldn't bee too much of a mess. If you're interested in doing an IVA, I'm trying to keep all furnishings as independent props for re-use. But obviously, there's a loot of internal shape for cupboards etc that would be specific. Props are in the props folder. You should feel free to do some props as well if you feel that way inclined. They make for nice practice parts, and nice still-life renders; Placing them is all Unity though. My partly done part, which is one I should finish, is a science lab. So, animated door for the experiment bay. IVA, etc. And I'm not 100% happy with its layout. But, I don't like dumping unfinished stuff on others.

I've actually been mostly working on the Orion mod, which has made most of my others a bit parked. There's a couple of 3.75-5m parts in partly done limbo. Fixing those up would free me from starting at the c# horrors.

I'll have to check. It's been a while. Pretty sure the MM config isn't complete. I was aiming for rereleasing with better textures etc. But spacedock now has a dev section. So I'll pop it there and link to here in a bit. Had the file, https://dev.spacedock.info/TiktaalikDreaming/Nexus/src/master/Parts Just grab that RealismConfigs.cfg file and drop into the nexus mod somewhere. It's all tagged as :NEEDS[RealismOverhual] though, so you'll have to have an RO install. I can do up a rescale config for stock, but that will take some time.

there's a RSS/RO config in test. It's big.

This, try something, compile, reload ksp, look at logs, repeat cycle is reminding me of that module I need that let's me reload modules without closing the game. Jeebus.

If I was working from scratch I think I would use a resource without a second thought, and just make sure it's only ever used in discrete amounts. But there's a lot of code already in place, so I'm trying to just get the existing stuff working. Having a look now at the IPartMassModifier. Thanks

I'm maintaining the USAF Orion mod, and it's been noticed that vessel mass is not decreasing as pulse units are expended. I chucked in some diagnostic logging and what seems to be happening is the parts (essentially custom fuel tanks) are decreasing in mass, but the vessel isn't. So, adjusting the mass of a pulse unit magazine is done with this super complex formula; this.mass = (this.bombStockpile * this.bombMass) + this.dryMass ; Debug.Log("[USAFOrion] adjusted mass of magazine " + this.bombStockpile + " to " + this.mass); With my little debug line. And mass (and bombStockpile) decrease as the units are used up. But when I add in; Debug.Log("[USAFOrion] Nominally this should have updated the vessel mass. It now shows : " + vessel.totalMass); the vessel doesn't change mass at all. Even if I run vessel.UpdateResourceSets(); base.onPartFixedUpdate () ; which would seem to be the sort of thing you do to recalc vessel things. So, A: Am I adjusting the part mass at all, or just some value that doesn't actually come into play anywhere? B: If (A:), is there a way of triggering KSP to recalculate mass (and CoM) of the vessel?

Updated to 1.0.4 May or may not have fixed some issues with weird bomb results in edge cases by removing the code that attempted to figure out if the vessel would be too close to the fireball effect of the pulse unit. The way the oddities manifested, with over-effectiveness just outside the atmosphere, changing frames of reference, and at very low altitude led me to believe this part of the code may have been at fault. I didn't quite have any smoking gun level evidence, but outputting variables it used suggested it certainly wasn't doing what it should have been doing. So, that's removed for now. Which means you can use Orions for braking in an atmosphere again. More work on the Staurn V/Jool V. Updated the F-1/K-1 rocket with the new mesh. Texturing not yet done, cos I had too much gardening to do. It has some basics, but it's primarily just blocking in different materials. And no, it won't stay quite that green. Tidied up descriptions for the Orion engine pieces Went through all the parts and adjusted cost, entryCost, and techRequired. I've gone with nuclearPropulsion as the node for all the pulse units, but heavyLanding for the engines themselves. All the other parts got put into suitable nodes as well. There's now a small CTT Module Manager cfg to adjust that to improvedNuclearPropulsion for the pulse units, and adjust some of the other parts for balance. This does not include a fix for adjusting mass as bombs are spent. EDIT: Dammit, just noticed I've called the 10m Orion a "33 Meter" Orion instead of "33 foot"

I keep editing then accidentally over-writing the descriptions again. It's a fairly typical error for me. I know about it and will fix it in the next update if I don't stuff it again. I've never so much as looked at the code that drops the mass of the magazines except to note it exists. I'll take a look and see if it actually does anything vs has some thoughts and comments. And check (if it does something) that it's using the current vessel part references to actually function. "When loading a vessel with Orion, it loses all magazin configuration" Do you mean the selection of which pulse units are active vs killed? If so, I don't know that there's any easy solution for that. There's definitely something really weird going on just at the edges of the atmosphere. I'm currently messing with various bits of the code to try to isolate what's causing it. Also, sometimes I get, not just one instant pulse unit, but what seems like about 10 all going off in a single burst. You can actually see that happening in the first large pulse of Kottabos' youtube video. The 15kt pulse units are strong, but they're not THAT strong. "Should does not appear to have any effect, perhaps just remove it" clarity required. Probably typo fixin.

I can see both sides of this. The nuclear fission technology maturity actually does need to be quite high for the pulse units for the Orion. So I'll be aiming a bit more towards @FreeThinker's idea of having it a bit further along the tree. As a comparison, remember they were doing the science for this when they were flying Gemini/Mercury and doing late stage engineering on the Saturn. The science for rockets was worked out decades earlier (sort of). So, realistically, (assuming development continued) I would expect working Orions no earlier than the 90s. A few tests earlier, sure, but by no means a mature technology you could put crew onto. Working Nuke thermo rockets were much earlier, because they're basically a thermal rocket, using fission for heat. Yeah, they're more complex than using an electric heater to heat the hydrogen, but it's rocket tech mixed with fission reactor tech. Having a critical, but not run-away chain reaction fission reactor, as needed for power plants and NTRs is actually simpler (although as demonstrated several times, involving a bit of a balancing act, that can go wrong) than designing something that's passive until you want it to be dramatically non-passive, and shrink to article to 140kg, and then also work out how to direct the majority of the energy through a tungsten propellant. EG: That stuff is still highly classified. BUT If anything, I'll be placing the 86foot earlier on the tech tree. Big Orions are easier to build, if much more expensive in materials. Pulse units, being separate parts can have their own slots in the tech tree. And I don't promise to never include interstellar grade fusion pulse units.

That may be the first use of the term SSTI. Love it. You probably don't want to hear my musing of whether I can get the code to apply damage effects to parts that stick out past the pusher plate shadow. Unless I also mention that my chances of coding that are so close to zero, I can't describe it using double floats in a way that isn't zero.