Stone Blue

Oh, by-the-way, THANK YOU to everyone on the Kop dev team, for continuing the long trend of making, keeping, and supporting such a long chain of backports. I'm sure *THAT* in itself is a pretty huge time consumer... ... Especially for the Backport QA Test Analysts... lol

Peeps can hit that "Follow" button on the top right of the thread page, or just look for this change in the thread title while browsing main forum listings: I know many devs dont even list, arent specific, or are hit-or-miss with updating versioning in their thread titles, but rest assured, i am 110% sure that as Soon™ as you see this: [1.7.3-2 + Backports] Kopernicus & KittopiaTech become this: [1.8.1-1] Kopernicus & KittopiaTech I also hope SpaceDock, Curse and Github are ready for the *SLEW* of uploading and downloading of all the huge files from updating planet/system packs, on whatever day Kop updates... lol Its gonna be almost as bad as when a new version of KSP drops...

@linuxgurugamer So I discovered something, and am not sure if it might be useful with NodeHelper or not... but here goes: I found some information backing up what I was trying to explain in an earlier post. Per the following info in the Kerbal CFG Wiki regarding *both* scale = keys, (although the definitions seem to be listed incorrectly for the respective key: the definition for the one under MODEL{}, is the def. for the one that should be *outside* the MODEL node, and the one listed under mesh = is the one that should be listed for *inside* the MODEL node.) I've tested both. I just set a part cfg with this: Note the angy = 1.0 in the attach node. When using NH on the part, the initial node coord is displayed as angy = 1.15 in NH. I know rescaleFactor = also plays a part in factoring in the node coords also. I then set rescaleFactor = 2, and sure enough, the NH displayed value was 2.3. So, NH seems to display values as equal to ang(x/y/z) x rescaleFactor x scale(outside MODEL{}). Could it be just that simple and easy? vOv Also, @JadeOfMaar , I dont remember exactly whether I used scale = 0.75 *inside* the MODEL{}, or if it was 0.85 or something, but I know it was somehow smaller, but proportional to the rescaleFactor I used, to get the ZZZ boxes to fit a standard KSP stack size.... So that matches with the definition for rescaleFactor

Ditto, except i am using the last version for 2.79 (*in* Blender 2.79b), from the branch master. Part in the background is a Procedural fairing part, and oriented correctly. I imported that .mu, and just changed the material/textures... Export to .mu, and *my* part (foreground) is oriented incoreectly. I've tried rotating it around in Blender (everything from the parent transform at the top of the hierarchy, down to just the mesh itself), and no matter how I orient it in Blender, it keeps exporting *this exact same way*... vOv Also, once the part is selected and attached, it can no longer be selected (not even highlited)... so i guess the collider is not exporting properly. I did not add colliders using the Import Tool... Just left the existing colliders as-is... I assume you *have* to redo the colliders with the Tool?... I also recall something to do with code changes to handle existing colliders on export, *if* the object name was changed, to something like "_coll", or something? I tried appending both _coll and .coll, neither seemed to work ... vOv https://imgur.com/il2f0HM EDIT: Also, @taniwha when I go into User Prefs under the Mu Importer, I'm gettin an err that the shaders cant be loaded when browsing to my GameData folder. Is this because I'm on 2.79 Blender/Blender Import, using a KSP 1.8.1 install?.. or?... vOv I know shaders were changed in 1.8.+, right? EDIT2: Actually, still get the err with Blender 2.79b, Import Tool for 2.79 (from branch, dated 19-01-30), and KSP 1.7.3. I know you're not supporting 2.79 builds, so just wondering if theres a known, quick answer... no need to look into it on my behalf. EDIT3: well, it seems I was able to compensate for the rotation thing, by adding this rotation key to the MODEL node:

No way to make it 36x36? 36 is a power of two, which KSP complains and spams logs if textures are NOT power of two

I have a 0.4.1 version. Might be difficult to do anything with this, as it does NOT include source files... vOv Give me a few minutes to upload it. EDIT: Here it is: https://drive.google.com/open?id=14psaa4A6GAe5TufDOZW_uCk4N9UWMVMR I removed the DDS Loader mod (no longer required, as KSP natively loads DDS textures), as well as a VERY outdated ModuleManager and Kopernicus. I also added a copy/pasta'd copy of the thread OP, since there was no mention of a license anywhere *in the release package*. You might still want to at least try to contact @sdj64, as they do request that in the OP, despite the open license.

Ok.. I got it to work. Yes, it was my MM feng-shui. This: @MODULE { @name = ModulePartVariants %VARIANT needed to be this: @MODULE[ModulePartVariants] { VARIANT

Half-correct... OPT Main itself is not getting updates anymore. However, OPT Legacy *is*. Also, OPT Reconfig, besides balancing and adding some "stuff" for OPT, is also a sort of a catch-all for patches and fixes for BOTH OPT Main and Legacy. Reconfig is required for one, not the other, but still can be used with the one that *doesnt* require it. Basically, *ANYTHING* that is not model related in OPT Main, (and that might be worked around), can be fixed/patched up in OPT Reconfig, if @JadeOfMaar is willing. He's been releasing updates for Legacy, so any IVA fixes would just go right into a Legacy update (again, as long as Jade is willing to keep supporting *that* pack).

Does this include the "blueprint" background? or does that have to be custom made by the user? If not, does anyone have a template/blank example that could be used? vOv And yeah, I saw the linked tutorial in the OP, but it looks like the blueprint background needs to be custom made?

Why do you want to know? Just asking, since depending on that, (and I cant put words in his mouth), but if you can get ahold of Taniwha, he can probably explain *anything* you could possibly want to know about scaling models in Blender, and how it might have effects when running it thru Unity/PartTools, and then how KSP handles it. Heck, if he's still as active developing his Blender Import Tool, you may even talk him into adding some kind of KSP-friendly scaling method into it... vOv He *knows* Blender... IIRC, he's even brought up issues/bugs during 2.8 dev that have been addressed/looked into..... vOv

First, I apologize, as I'm sure its just something dumb I'm missing, but i am trying to add a part variant (just to texture switch), to a Procedural Fairings part. It already has an existing part variant module, with 4 variants set up. I just want to add this additional one. I cant seem to get this patch to work. My MM syntax feng-shui is rusty, so i dont know if its that, or I'm missing something with how the stock variant system works... vOv Anyone have a clue? @PART[KzProcFairingSide1]:NEEDS[ProceduralFairings] { @MODULE { @name = ModulePartVariants %VARIANT { %name = 3SL %themeName = 3SL %displayName = 3SL Generic %primaryColor = #0D1C32 %secondaryColor = #935209 %TEXTURE { %materialName = fairing1 %_MainTex = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_D %_BumpMap = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_N } // EXTRA_INFO // { // <info name> = <info value> // // // Known Examples (ModuleProceduralFairing) // FairingsTextureURL = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_D // FairingsNormalURL = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_N // } } } } The part doesnt use the stock ModuleProceduralFairing module, but i copy/pasta'd that from the example in the OP, just incase, and for reference for myself.

YES!! ... THATS where I remember this issue from... I did extensive work on ZZZ's boxes, among most of his other models, when I first started dabbling in modding. i think the boxes were what prompted me contacting, and having that discussion with Felbourn.

Would require a unique set of models for each number. Not impossible but not a small amount of work Since each segment is a model I think attempting to make smaller sizes would result in stretched textures Someone would need to make variants of the textures. If someone wants to do that I'll figure out the code side. Isnt this pretty much what Procedural Fairings does, tho? vOv FYI @Craze

Nice! And can I also assume, like @Inqie, that it would support/be compatable with Connected Living Space?

LMAO... thats almost *exactly* the layout I was picturing in my head to explain what I was getting at Just didnt know how I would illustrate it, much less explain it... lol So, would using the "part tree" method select Cabin A before Cabin B?

... Hmm.. *I* would have assumed that, yes, they probably *do* mean literally the closest in distance.... *as long as its the shortest physical (internal) route to it* ... vOv But then i have NO clue how the part tree works, or what the ramifications are of that choice... vOv

That might just help a LOT... at least with consistent scaling across the mesh *AND* the nodes... (ie scale = *inside* the MODEL{}, and/or rescaleFactor) and probably as long as scale = used *outside* the MODEL{} isnt changed from KSP default... vOv I wouldnt bother with a user setting for that usage/instance... i think its so rare that someone actually defines that as other than "1", anyway... vOv i mean, who models in any metric unit scale *other* than 1m/unit??... mebbe 1.25m/per unit, if they dont know better... but anything else? vOv (even tho *I* seem to have been the lucky one to find a mod that fits that edge case...)

From what I have come to understand, yes, scale =, *inside* the MODEL{}, scales *only* the mesh, on x,y,z axes. (NOT the attachment nodes). Used *outside* the MODEL{}, it is used to determine the scale of metric units with which the mesh was modelled in. Supposedly, it defaults to 1 in KSP (hence why KSP defaults to 1.25 for rescaleFactor.) (1 = 1 meter, 10 = 10m, 1.25 = 1.25m, 0.1 = 1 dm, 0.01 = cm, 0.001 = mm, etc) In Blender, this would be the number entered in the Units->Metric entry. I'm pretty sure this doesnt need to be defined *outside* the MODEL{} unless the mesh was modelled in something *other* than 1 meter units in a modelling program... vOv... IMHO, if this is the case where scale = serves these two very different purposes, it was a bad choice to use the same name for the key. rescaleFactor = supposedly rescales the mesh *and* the attach nodes by the entered amount. It defaults to 1.25, if not defined. It can be combined with scale = *inside* the MODEL{} to offset scaling of the mesh, seperately and differently than the nodes. I wanna say maybe it was ZZZ that used this a lot in his models... vOv If anyone has definitive info/documentation/sources differing from what I (probably half-sensically) explained above, as to what I *think* all those keys do, PLEASE share it. And now that I sort of figured out my issue *NOT* being an NH bug, per se, and these last few posts, I *do* now remember having a conversation with Felbourn, a few years ago when i first started using NH. About how NH handled rescaled parts. IIRC, he said yeah, NH output numbers shouldnt be used directly in configs, when used on rescaled parts. (anything with mesh scale other than scale = 1, 1, 1 *inside the MODEL{} (KSP default when not defined); anything with rescaleFactor = defined as *other* than 1.25 (KSP default when not defined); and possibly, i cant remember for sure, with the units scale thing (scale =, *outside* the MODEL{}), as anything other than 1 or 1.0 (KSP default when not defined). He said, for anything rescaled going *into* NH, he had made himself a spreadsheet with common rescale factors, that he had to refer to, to get "final/corrected/true" values, rescaled from the NH displayed values, to use instead. What threw me off, with the issue *I* brought up that started this discussion, was that there *was NO* rescaling set at all in the configs. It wasnt till i thought to look at the models in Blender, that I found who ever modelled them, used inconsistent scales and sizes when they modelled them. (the Unit->Metric entry I mentioned above, that *should always* be either 1 (1meter), or 1.25 meter per unit, to make things easy and consistent for KSP modelling...) :face_palm: I have yet to figure out how they managed to get them all scaled, (I think), at 2.5m in KSP. I'm assuming they used some scaling trickery on each model when they got run thru Unity... vOv

I know its not technically aboot the forum, but I keep also getting it...EVERY...SINGLE...TIME... I open a page or link thaat takes me to the KSP Wiki... vOv

OK, false alarm I guess... Turns out the models are modelled at weird, insconsistent sizes across the board, but somehow, in-game they are all 2.5m... with NO scale/rescaleFactor keys defined.... vOv What ever is going on, its causing NH to display nodes at whatever weird scale number is being used to get the individual parts sized to 2.5m in-game...

Yup.. i know that... My issue is that what NH displays is different than whats actually in the config So I removed LGG's most recent, and installed Phineas' last fork (NodeHelper v1.5.1-1 (1.6.1, 1.5.1) [PhineasFreak fork]), and seeing the same thing. Initial poking, shows the node coords in the few configs I've looked at, are getting multiplied by a factor of 1.25 before being displayed by NH... This *inlcudes* the angx/y/z values... vOv Leads me to believe something with scaling... the cfgs I'm working with do *NOT* have any scale or rescaleFactor keys defined. These are from one mod, so I want to look at some other stuff, to see if its scaling with the models in *my* mod actually *needing* to have scaling keys defined... vOv

Just wondering if anyone else is seeing inconsistencies between shown NH node values and those already in part configs? I've also been seeing a lot of fractional numbers on the node directional axis... ie 1.25, 1.95, etc... when numbers are 0.0, 1.0, etc in the actual cfgs... vOv I'ma do some moar testing and poking, and see if I can come up with better info for a proper report if needed.

Most likely not... I dont think anyone has gotten anything done, as far as 1) getting other-than-stock maps, made and hosted on the (new) KerbalMaps site, and 2) any code changes that may need to be made to Telemachus to actually *use*, and switch to those maps. There was talk of getting JNSQ maps done... I dont know where that stands... vOv Relevant thread is here (bottom half of page 1, into pg 2):

Unfortunately, I havent fully tried it yet. I only need it, as a mod I am tweaking has its own PF part which isnt working (issues with the part, it seems, not necessarily PF). No idea on actual release... Its not my mod Instructions *should* be somewhere in the OP ... vOv I havent used the base PF mod in forever myself... so I am still in the process of re-familiarizing myself with it.