Jognt

*anticipation intensifies*

Showing just fine here. To be sure I checked in a separate browser that didn't have the images cached and they showed up fine there too

Cheers! Did you by any chance do a quick one on surface attach parts to see how nodes compare to that? Mostly worried about node-attached wings/gear snapping under strain and currently unable to test it myself. ps. Yay, I contributed \o/

Same here. But it wasn't long ago that another belief was shattered

My apology if this is another nonsensical question of mine: How does the attachment strength of these nodes compare to the regular surface attachment strength? Or is the strength of attachment defined 'in general' for a given part regardless of node type/size?

Sounds good! To be honest I've been holding off on getting KS3P because I'd rather not have to delve into .cfgs for basic customization like disabling dirty cam effect and other camera specific limitations. Having said that, my inner UX person couldn't help but wonder a few things: Are these preset profiles from the later mentioned Editor part or are you planning on making profiles containing seperate profiles? By which I mean, if the user were to define a custom anti aliasing and a custom something-else, would these be selectable seperately or would they need to be saved into another profile one level up? Besides my wondering about that, I'd call this section "Profiles" or "Scene setup" to differentiate it from "Editor". Similarly to the above-mentioned setup menu the term "Editor" has quite an overlap with "Setup". I'd recommend naming it a bit more specific or merging it with setup and just having a single screen alltogether. After all, both menus are about customizing (setting up) the mod. I can understand the desire to split up functionality to prevent info-overload but I can't help but wonder what specific actions you wish end-users to be able to perform and what interface structure would be best suited to it. Sounds good, though I'd place a return button in the top left instead of top right just to keep it easy to grasp at a glance. --------------------------- Let me know if you could use a hand with deciding on a UI structure

For the longest time I thought (and built my crafts with that in mind) that stock aero used nodes in its calculations. I can't find where I got that idea from at the moment except for a segment in the wiki where it says drag "is dependent on the shape of a part and which of the part's attachment nodes are in use" but maybe I misinterpreted it. Wow.. do I have an apology to make to my mates who had all joined my no-open-node religion..

How are these nodes treated by the stock aero system drag wise?

I think I know what the problem is but I’m not sure I can explain it. Here goes: The legs were probably made with the piston vertical. The attachment point was then added later at an angle. To get it to the ‘proper’ look they had to rotate the model so the angled attachment point looks straight. In other words, all offset is relative to the piston, not the attachment plate. Maybe ive missed it, but what happens when you use the default rotation values? edit: and what happens when you use a side node instead of a top node? Maybe it’s just the top node not rotating along nicely with different rotation placements. Edit 2: it does look like the node isn’t rotating with the part.. was this when you used symmetry?

Considering the below bit in the OP I'm guessing something's not quite going as it should. I haven't yet had time to actually play KSP so I can't comment on the performance just yet.

From what I've seen on my mate's KSP that's entirely possible. Note that I haven't yet played much with FAR myself but from what I can tell there's less drag in general than in stock (less 'soup-y' atmosphere?). Every time my mate asked me for advice in stock it was "How can I make my plane go faster?" yet in FAR it was "How can I stop my plane from stalling at take-off and landing?" I could be wrong though, in which case I'll probably be corrected in about 12 garbage collection cycles.

I didn't mean to pass judgement on what was 'harder'. I merely pointed out the flaw in Bla Bla's comment that essentially said "if it works in FAR, it'll work in stock" which just is not true.

My mate’s spaceplane that worked fine in FAR couldn’t get up to speed in Stock aero. Spaceplanes are super forgiving in FAR because you are far less limited by the weird drag system that is stock, allowing you to easily get up to speed on air. I fail to see what you claim is self demonstrating.

Agreed. Using OpenGL is a pretty serious flaw.

Oh my god.. how did I ever KSP without this? One question though: do Kerbals emit rainbows and stars when they bounce over the surface? Why do I ask? No idea. It’s 6am and I’m still awake

There there. It’s ok. We won’t send you back in there. *gestures towards drag-cube darkroom*. This is a safe space now. *humms in a soothing manner*

Might I suggest adding ‘_1.3’ and ‘_1.6’ to those filenames for their respective version? Having them both have the same name yet different contents is a nightmare waiting to happen.

Something like this by any chance? (Edits existing stock parts with just the values that were changed. Removing ones not present in Porkjet's cfgs and adding those that differ/are new. Done using Notepad++ with the Compare plugin) // Mk1 Command Pod @PART[mk1pod]{ @author = Porkjet @mesh = PartOverhauls\Parts\Command\Size1Pod\Size1Pod.mu @node_stack_bottom = 0.0, -0.375, 0.0, 0.0, -1.0, 0.0, 1 @node_stack_top = 0.0, 0.6125, 0.0, 0.0, 1.0, 0.0, 0 } // T-30 Reliant @PART[liquidEngine]{ @author = Porkjet !mesh !scale rescaleFactor = 1 @node_stack_top = 0.0, 0.90625, 0.0, 0.0, 1.0, 0.0 @node_stack_bottom = 0.0, -0.90625, 0.0, 0.0, -1.0, 0.0 @MODULE[ModuleEngines]{ @fxOffset = 0, 0, 0.1 } } // T-45 Swivel @PART[liquidEngine2]{ @author = Porkjet !mesh !scale MODEL{ model = PartOverhauls/Parts/Engine/JebsJunkyard/LV-T45 } rescaleFactor = 1 @node_stack_top = 0.0, 0.90625, 0.0, 0.0, 1.0, 0.0 @node_stack_bottom = 0.0, -0.72, 0.0, 0.0, -1.0, 0.0 @fx_exhaustFlame_blue = 0.0, -0.72, 0.0, 0.0, 1.0, 0.0, running @fx_exhaustLight_blue = 0.0, -0.72, 0.0, 0.0, 0.0, 1.0, running @fx_smokeTrail_light = 0.0, -0.72, 0.0, 0.0, 1.0, 0.0, running @fx_exhaustSparks_flameout = 0.0, -0.72, 0.0, 0.0, 1.0, 0.0, flameout @MODULE[ModuleEngines]{ @fxOffset = 0, 0, 0.1 } MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = Piston01Target rotatorsName = Piston01Anchor } CONSTRAINLOOKFX { targetName = Piston02Target rotatorsName = Piston02Anchor } } } // LV-909 Terrier @PART[liquidEngine3]{ @author = Porkjet !mesh !scale MODEL{ model = PartOverhauls/Parts/Engine/JebsJunkyard/LV-909 } rescaleFactor = 1 @node_stack_top = 0.0, 0.275, 0.0, 0.0, 1.0, 0.0, 1 @node_stack_bottom = 0.0, -0.475, 0.0, 0.0, -1.0, 0.0, 1 @fx_exhaustFlame_blue_small = 0.0, -0.0, 0.0, 0.0, 1.0, 0.0, running @fx_exhaustLight_blue = 0.0, -0.0, 0.0, 0.0, 0.0, 1.0, running @fx_smokeTrail_light = 0.0, -0.0, 0.0, 0.0, 1.0, 0.0, running @MODULE[ModuleEngines]{ @fxOffset = 0, 0, -0.05 } } @PART[fuelTankSmallFlat]{ @author = Porkjet !mesh MODEL{ model = PartOverhauls/Parts/FuelTank/Size1/FL-T100_A } @node_attach = 0.625, 0.0, 0.0, 1.0, 0.0, 0.0 } @PART[fuelTankSmall]{ @author = Porkjet !mesh !scale rescaleFactor = 1 @node_stack_top = 0.0, 0.55, 0.0, 0.0, 1.0, 0.0 @node_stack_bottom = 0.0, -0.55, 0.0, 0.0, -1.0, 0.0 @node_attach = 0.625, 0.0, 0.0, 1.0, 0.0, 0.0, 1 } @PART[fuelTank]{ @author = Porkjet !mesh !scale rescaleFactor = 1 @node_stack_top = 0.0, 0.9675, 0.0, 0.0, 1.0, 0.0 @node_stack_bottom = 0.0, -0.9075, 0.0, 0.0, -1.0, 0.0 @node_attach = 0.625, 0.0, 0.0, 1.0, 0.0, 0.0, 1 MODEL{ model = PartOverhauls/Parts/FuelTank/Size1/FL-T400_A position = 0.0, 0.03, 0.0 //original was slightly off center, trying to retain compatibility } } @PART[fuelTank_long]{ @author = Porkjet !mesh !scale rescaleFactor = 1 @node_stack_top = 0.0, 1.875, 0.0, 0.0, 1.0, 0.0 @node_stack_bottom = 0.0, -1.875, 0.0, 0.0, -1.0, 0.0 @node_attach = 0.625, 0.0, 0.0, 1.0, 0.0, 0.0, 1 MODEL{ model = PartOverhauls/Parts/FuelTank/Size1/FL-T800_A } } Note: I haven't doublechecked or tested this yet. Last I remember I wasn't completely done yet, but well on my way. This was part of my project to make patches for use with patchmanager to select from ModdedAsExtra (just fixes), ModdedAsStock (the cfg you found before), ModdedAsEyecandy (this one), and ModdedPlusUpgrades (adding upgrades to the engines where base (non-upgrade) performance equals stock performance). If you're interested in that, let me know, maybe it'll be the edge I need to continue on it. edit: Again, feel free to use it as-is, as inspiration, or however you want. Honorable mention would be nice if it was of help.

Memgraph works fine in 1.4.

I'm not familiar with licenses, feel free to use what I post however you see fit (a mention would be lovely though). The upper bit about the missing upgrade and the typos is copy/pasted from @PocketBrotector's cfg though if that matters. Is that integration cfg all you want? I'm fine with writing some more (like the patchmanager stuff) but my brain is far more motivated by external stimuli than internal ones so you'd have to mention what you'd like. ps. I am a bit weary about the "-part" bits in the linked cfg since a mistake there would mean deletion of previously built/active craft. One of the cfgs I am/was working on edited over all the new/changed parameters of the porkjet parts to the stock parts, but that one is quite a bit longer/more complex than the 'simple' -part/+part one. edit: Optional cfgs that could be included for patchmanager (ingame on/off button for these parts): Yes/No to Upgrades, replacing-of-stock, no 'extra' engines, tanks/engines-only, whatever you can think of.

Hmm, I'll check it out. No word on 1.4 compatibility so far. What turned me away from that mod initially is because it listed "realistic counterparts" as the source of files. And the last thing I want is more realistic sounds, because nobody wants to listen to what an actual jet sounds like for any length of time. (in that sense, the new 1.4 sounds are quite a bit more realistic, in that they'll cause permanent brain damage if you listen to them for too long)

And here I thought I was alone on my dislike for the new sounds! (https://bugs.kerbalspaceprogram.com/issues/18541) If there is any way to get the old ones back, I'd jump on it.. In the meantime, I don't know how much of an impact it'd make, but maybe upvote my post on the bug/suggestion tracker? My only gripe with the old sounds was the Panther afterburning sound having a noticeable loop to it. Then again, that's better than listening to all the engines sounding like vacuum cleaners..

Hah. No, no way am I backing vaporware like that. Just because I'm not souring the mood with pitchforks and torches doesn't mean I'm not annoyed with the state of recent patches. It just means that I realize that those pitchforks and torches won't magically create better patches.

Man.. You're a wizard! I've done some work on making MM patches to be used with PatchManager to allow end-users to simply click to select options they want (such as upgrades and to replace or add the parts). Due to ADD I'm a bit unreliable in managing focus to finish stuff I started, but I'd love to (try) help out if there are specific patches you'd like written. By the way: The following MM patch works fine for replacing the stock parts with the new parts. Might need some editing of names if you've changed those, but that's all there should be to it.

I have way more respect for someone that delivers quality work late with an apology than someone that delivers rubbish on schedule. Of course I still want it all yesterday.. But that is only human and shows that despite my gripes with KSP, I still love it enough to want it so badly.