Stone Blue

ahhh.. ok... so I have them/would *like* to have them switchable in flight, as well as in editor

SO I ased a well-know KSP modder, and its seems Unity automatically fixing ngons, while not a big problem, and probably not doing it all the time, *could* potentially show tessalation issues in-game... vOv

Hmmm... The question is, if it adds unexpected edges, which would also means unexpected *faces*, I have to wonder how that affects things like the UV map, and seams. Like, would it change how the faces/textures look in-game, and give you odd shading &/or unwanted visual artifacts? Since that seems unknown to me, it would seem to me, it would be better to be safe, and just manually have them fixed yourself, before export, so you *know* how everything *should* look..?? vOv

@Papa_Joe Just ran across an issue with using CLS with switch-enabled stack nodes. Basically, I have parts, that I have using optional stack nodes, for attachment of "stuff", in cargo bays. When i have a CLS patch declaring imapassable nodes, it seems CLS over-rides the switching patch... ie, I guess by defining impassable nodes, CLS declares them as present, whether they are or not... Actually, so I removed the impassable key, with the impassable nodes, and added a passable ey with the passable nodes... But I STILL have CLS overiding the switching on the impassable nodes. So, I'm guessing, CLS has no way of detecting/updating when nodes are actively present or not, after game start.. ??

Ngons are faces with more than 4 vertices. Hmmm.. they might export... i usually get a warning, and fix them. Having extra verts on a face, may mess with face/edge/vert normals, shaders, or other weirdness... I dont know. I was just alwaays taught from the start, at least for Unity/KSP: " Ngons, BAD!..." to fix them, you either eliminate the extra verts, but usually cant, because they are usually there, because *other* geometry intersects/connects ther. The way to fix, is to delete the Ngon face, and make new faces... there may be other options, but i just sdelte the face, and redo it as a couple faces, or tris... vOv So, I guess faces need to have *exactly*, either 3 verts (a tris), or 4 verts (a quad) EDIT: wait, now that I think of it, Unity converts *everything* to tris.... so having Ngons & polygons, which cant evenly be converted, leaves extra verts, which Unity may not kknow what to do with...? Idk... vOv

link for v4 is dead... Latest I have is 3.1

@610yesnolovely I'll go thru my hoard of old mods, and makke a list up for you, too Umm... on AIPS... Do you *have* a copy of v4?... i only have three previous versions...

Oh.. yup.. i forgot about the facing coloring red/blue thing... i dont use that one Oh, I cant remember if it was discussed earlier, but any Ngons will prevent an export. I usually, occasioanlly check for those as/if I add a lot of new faces... Also, one moar good, quick check to do before *every* export. Just for everyone's FYI, easy way to check for Ngons is, in Edit mode, with NOTHING selected in the mesh, do Select-->Faces by Sides. In bottom left corner, a little thing will popup, ">Select Faces by Sides", click the dropdown, mae sure its set to "4", and change to "Greater Than"... Any Ngons will then automagically be selected and show up as highlighted. Then you just have to manipulate them. If nothing shows up highlighted, then you're good to go on Ngons (or lack of, which is what you are shooting for )

@ColdJ Ah... yeah.. thats a pop-up of a snippet from the log... Usually, or at least *sometimes*, there is an actual error/warning message that pops up, with a clearer message, without the details... Like, IIRC, one place it shows, is in the status bar... right where that yellow triangle icon, and the red bar are in your screenshot I still cant read the log details well with Blender/BFA/Python.... But that *could* be a file permission problem, due to C:? vOv The other thing i would say to try, might be to edit the plugin's folder name... delete the "-master" from it... I know a long time ago, it was established that Taniwha was using special characters in the folder name, specifically a period (.) .... Its a Blender or Python thing that you cant use some special characters in folder names... Dash (-), *might* be one of them... Ever since I found that out, whenever I install/update, I always edit the folder name to: /io_object_mu

Hmm.. I'll take a look at the Wiki again for that. If its refusing to export, it *should* be giving an error message, with what the issue is... also, IIRC, theres a way to look at the "log", but I cant recall off-hand That sounds like some kind of Blender/BFA setting not doing normals the way you want, while you're working... you shouldnt have to mess with the Solidify faces setting. There is a toggle in Blender/BFA, that will display normals direction, for faces, as well as edges & verts... I usually turn it on, to check over the whole of the model right before i export, to make sure there are no strays. To find it, (in BFA), Edit Mode... go along the top toolbar in the 3d view...3 icons over from the UV button, the "Show Overlays/Overlays" button... click the dropdown... scroll down past "Shading", till you see "Normals".... only 3 icons there: Verts, Edges, Faces.... click which you want normals to be displayed on (multiple can be selected at same time)... to the right is numeric textbox... that is length of the blue indicator line, you can adjust. Just toggle the normals display on/off, here, when you do/do not want them visible. You could also try unchecking "Autosmooth", and/or clicking "Clear Custom Split Normals", under "Normals", in the object Properties window... I just *cannot* recall the ramifications of that, so test it on something you dont mind losing. EDIT: Oh... also, if after making sure all your *face* normals are properly facing, and you *still* see weird coloration/shadows/z-fighting on certain faces in-game, it might be good to go back and check your *vertex* normals. Use the method above to display the vertex normals. If you see some pointing differently from others, *on the same face*, you may need to redefine/fix those verts. Pretty sure, when you do the Merge on the dupe verts, sometimes Blender/BFA will delete the incorrect ones (at least as far as Unity/PT/KSP/Taniwha's exporter, are concerned. Lie, theres no way it knows *which* duplicate vert to delete... and the whole reason we *have* those dupes is because of the vertex normal data... Make sense?...

Mmm.. not *quite*... Pretty sure it does that on *export*... You're seeing it happening every time you re-import, because it all got converted on the *previous* export. Its a Unity thing... Unity will automatically convert everything to tris, anyway... Having faces as tris or quads, is not what duplictaes the verts. It makes no difference having tris or quads after you import into Blender. The only advantage to converting everything to quads in Blender, is maybe it makes it easier on your eyes, and causes less mis-selection of edges, because there *are* less edges drawn in the 3D view. Converting tris/quads has NO affect on final model. The duplicating of the verts on import, IIRC, is Vertex Color being used in the shaders, and to store/write the additional shader data, the plugin duplicates those verts that *do* have the extra data. Its not a failing of the plugin, its a required feature/function, so you get complete & correct import of the KSP shaders... Its a Unity/PartTools thing. EDIT: Some clarification I have on this from @Katniss218: "duplicated verts is a unity thing too Unity doesn't do flat shading every piece of flat shading in unity relies on duplicated verts Unity's meshes don't support multiple normals per vertex... so to get multiple vertex normals, you have to have seperate/duplicate vertices" These two points are two of several reasons, why you shouldnt re-import the .mu after changes/edits and exporting it. If you import a .mu only the *first*, initial time, yes, you need to go thru *every* mesh object manually, and delete the dupe verts with Merge. But that should be the *one & only* time you need to do that. This whole thing could be avoided, if actual *source* files (.blend/.obj/.fbx) were originally available for all these old mods we are trying to update/fix. Thats why its a good idea to do repos (ala Github or similar), and host these files, or even the Unity project(s)... Not many modders have, or even to this day, do that, unfortunately FYI @Waifu Art Thou Romeo @darthgently

Uh.. No? Just drag the whole GameData folder from the zip, to your main KSP folder... if on Windows, click "Yes" when the popup asks if you want to combine this folder with the existing GameData... Profit!

SpaceDock is good for that... theres a simple CKAN checkbox, when you list the mod, to have an automatic PR generated on NETKAN... the CKAN team takes over from there

Rover Science Re-Mobilized ?

@linuxgurugamer Sorry if this has been asked/discussed already... I went back thru *some* of thread, and couldnt find any relevant posts. I guess this would be a feature request, and if anyone has input on it, plaease also pipe up Possible to add in over-rides/version compatability for mods, that *do* have updates, but for the *same* version of KSP? ie a mod that *is* current for current KSP, but has an update for the same KSP version, *but* I dont want to update, *but* I dont want to keep getting nagged with an "update available" notice everytime I restart... It looks like you *cant* add the mod to the compatability list, *unless* its for a *different* version of installed KSP. ie say I have a mod, "AAA", which I want to use in conjuction with a certain, supported mod "BBB".... however "BBB" is version locked, which then means "AAA" is *also* version locked by "BBB", when used together. SO even tho there are newer updates to "AAA", I cant update it because new versions wont support "BBB"... So I can over-ride "BBB" for an older version of KSP, but I cant add "AAA" to the over-ride list, because it *is* already compatable with installed KSP... Make sense? Basically, I want to be able to over-ride *any* mod I want, for whatever reason. LGG, if you think this is a valid request, lmk, and I can request it on the repo if you dont want to look into it now.. vOv

@ColdJ now that you are getting into animations, if you are making *new* animations, make *sure* you are setting your loc/pos/rot coords to Quaternions, when inserting your key frames. Not a problem i guess, if you already model using quats... but if like me, you model using Euler, switch to quats before inserting keyframes. I think thats covered in one of the pages in the Wiki on the repo.

Good points on having only female kerbals used There *might* be a way to change the female viewpoint to equal the male one... meaning you *might* be able to mae your offsets universal across the two. If you open the Settings. cfg, in the main KSP folder, go down to line 281, or search for "female", in it. It should take you to 4 lines regarding female eye offset... the last, scale offset caught my eye (pun intended? :P) Looks like its defaulted to 2.03... you *could* try playing with that (I would start by setting it to 1.00 ??)... to see if you get it close to equalling whatever the default is for the males..?? Or try setting the Z_OFFSET to 0.00... it looks like its set for ~3.4 CM??.. I assume offset that much from the male position..?? Again, this is spitballing, as I havent tested or played with editing it. I also do not know if this is strictly for EVA view, IVA view, or both..??

@Zanaten so I just looked at both the KSP API Docgen, and the RPM source code. Unfortunately, it does look like its an RPM key, and not stock Heres the relevant keys available for the stock InternalSeat module, from the official API: https://kerbalspaceprogram.com/api/class_internal_seat.html

Yeah, what happens there, is, as long as the camera location is *inside* the model mesh of the Kerbal's head, you will never see the head. Basically, only the *outside* skin of the mesh gets drawn... the *inside* is, well, invisible from the inside. So, if the camera is *just* in front of the mesh, you dont see the head, until you rotate the camera to one side, to the extreme edge of FOV... if you see the eyeballs, or part of the head appear, that means the camera location is placed in-front of, or too close to, the front of the Kerbal's head-mesh. Good job on figuring that all out. And, yes, on each and every IVA, when they get created, depending on the "space" in the IVA model, and the props used, and placement of them, a good creator will adjust the camera offset properly.

Uhh.. Thats exactly what ModuleManager does

@johnnydope Nice to see someone not only do a new IVA... but especially one using MAS! As 610YesNoLovely said above, you're supposed to state a license in your OP. Good practice to also include a copy *in* the mod folder. In case you're new to licenses, heres a decent thread about them:

Sorry... Dont know if you saw my edit in that other thread, but you have to install RasterPropMonitor Adopted for those two added modules to work. They are from RPM, *NOT* stock modules. Once you install it, those edits you quoted should work. If you do NOT want the added RPM IVAs, modded *or* modified stock IVAs, you should be able to delete the GameData/JSI/RPMModPatches folder. If you want to keep the modified stock IVAs, just delete the /PatchesMod folder inside that one.

Have a look in this thread (near the end). There's a (relatively) easy way to manipulate field of view and view rotation limits, in it, if you can do simple config file editing or ModuleManager patches.

I'm on Firefox also. Yeah, Idk... I rarely have a problem with SD speeds/connectivity, whenever orthers report bandwith/connection issues. I usually only ever see issues when its a kknown issue with the SD server in Germany itself... vOv Maybe I am just lucky, always being able to connect with good servers.. ?? vOv

I'm in Eastern US, and just downloaded that 1GB test file... Only took a few minutes, and very constant and steady 3.0-3.6 MB/s .... averaged to 32.6Mbps for the whole thing... I usually get 3.8-4.5MB/s on SD... but... you know how it goes...