Jump to content


  • Posts

  • Joined

  • Last visited


2,645 Excellent

Profile Information

  • About me
    Construction Gingerbeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Because .mu files are just dumps of Unity mesh objects, and mesh objects are optimized for the gpu, so each vertex is identified not only by its position, but also UV coordiinats, normal vector, tangent vector, and vertex colors. Thus as soon as you add a UV seam, or split normals (eg, flat shading), vertices must be duplicated in order to have the different properties at the same point in space. Short story, a vertex can have only one UV point, only one normal, etc etc Blender's edit-mesh format is optimized for editing: the one vertex can have multiple sets of attributes (multiple UVs, normals, etc). I won't go into details on how blender does it (for one, it uses more than one internal representation, for another, my head is full of Quake BSP stuff right now) Mesh editing and mesh rendering are two very different worlds.
  2. Import is not meant to be part of a workflow other than an initial import of a model for which the "source" (blender/maya/whatever file) has been "lost". I gave up on full round-trip support for import/export years ago. In fact, due to triangle vertex order issues, 100% round-trip support never existed. The intended workflow is to use the blend file as the model's source file, and export as needed. There's even script (mass-export.py) provided to facilitate doing whole scenes of models (makes it much easier to ensure model sets fit together and can even share sub-models). There are scripts in the addon directory for debugging exports. animprop.py, bones.py, cump.py, hierarchy.py, and the nuclear powered big stick: mucfg.py.
  3. No need to ask permission to ask questions Don't ask to ask, just ask.
  4. Two or more survey stakes having the same name make for a survey site. Within a site, all stakes of the same type are grouped together to produce a point that is the average of all their positions. Stake [sets] of different types interact in different ways to produce lines (direction stakes, for creating axes), or planes (bounds stakes). Origin stakes are special in that there's no difference between direction and bounds origin stakes (limitation in the PAW UI). If multiple stakes with the same name are giving you trouble, I want to know what that trouble is so I can either clear up any misunderstandings or fix it.
  5. This doesn't tell me much of anything at all. What does "bug out" mean? Do insects arrive on the scene and abscond with the stakes? (Not sure I blame them, stakes are tasty).
  6. No, the point of my post is that if going through an inventory broke parts when building with EL, something is very wrong.
  7. So long as the parts are spawned "correctly" (ie, such that in the end, KSP thinks it spawned them normally), it shouldn't matter how EL (or any other mod's parts) get into the game. Something many may not realize is that (at least pre stock inventory KIS) even just placing a part using a kerbal spawns the part into the game: the part doesn't exist at all when in the kerbal's inventory, and I'm pretty sure only the model itself exists when strapped to the kerbal's back.
  8. Actually, I fixed the addon to work with Blender 3.2.0 alpha (as of a git pull last night). May or may not work with 2.83, please let me know.
  9. I'm getting an Error in my KSP Log for this Mod.


    Empty part config file.

    Is that normal?

    1. taniwha


      Yes. Feel free to delete the file (if you look inside it, you'll see a comment regarding intention).

    2. Xtra


      Thank you

  10. I don't have any new official builds. If you can take care of it, that would be great, thanks.
  11. I just had a quick look at that code and it seems the vessel has specified a flag that doesn't exist, or things have changed in how to fetch a flag texture, but either way, I forgot to check that GameDatabase.Instance.GetTexture() didn't return null.
  12. EL doesn't actually do that. Rather, it finds the base of the vessel's bounding box and uses that to place the vessel. There are two possibilities: the bounding box is wrong (or really, the bounding box of at least one of the parts, since EL builds the box from the part bounding boxes), or there's a bug in the placement code. TweakScale has always been a thorn in my side: when I went to add support for TS to EL, I found that it broke KSP's camera after reverting to the VAB (or SPH), and when I reported the issue, I was told it was a KSP bug and the TS author (at time time) refused to do anything about it. Thus I abandoned all pretense of supporting TS. Sorry excuse, sure, but that's the way it is. I'm pretty sure I haven't changed the orientation of the micropads, but rotations can be a tricky thing, especially if it's a 180 degree rotation (rotation axis is undefined in such a case when you have only the two reference vectors (current and desired direction): rotations are intuitive only in 2d (ie, there is no 3rd dimension)). It's for this reason the pads have extra geometry internal to them making their orientation semi-apparent (can't tell which direction is which, but you can tell when you've rotated 90 degrees) when placing them using older versions of KIS (before stock inventories, haven't tried with more recent KIS). Ie, build goes wrong, load before building, reorient pad, try again. However, I don't think I've ever been out by 90 degrees, only 180 due to top vs bottom node selection. Hmm, actually, I might have changed something: it looks like I tried to ensure that starboard (VAB door side of default orientation) stays starboard when flipping, and starboard is aligned with the red arrow (yeah, a bit weird when the port navigation light is red). This code always has me scratching my head (and some of my git log messages aren't so great in hindsight). What was the bug? (next commit does fix a bug that's related to nodes and orientation, but...) On top of that, I haven't worked on the code since November 2020, and everything I knew about it has been pushed out of my head. This shouldn't be that hard: just include all the .cs files mentioned in Source/Makefile.and KodeUI.inc (note: I use a symlink in Source to the KodeUI source directory, check README.txt for KodeUI related instructions), and I directly reference the dlls in KSP's KSP_Data/Managed directory.
  13. @cineboxandrewI have no problem with any of my stuff being on CKAN, I just don't want to have to deal with it myself.
  14. I've got my server limping along: http (not https yet) is working, so all my mods can be downloaded again. Sorry about the inconvenience and delays. A combination of a few mistakes with the fiber model config (tried defeating some of its stupidity to no avail), working out how to get arcane configs right, waiting for DNS to sort itself out (after a few false starts), and rampaging around the Forbidden West I hope to get https going soon, and with a proper cert this time. Not that I know of, but see my above message [edit] https is working now, and is now actually the "only" option (http redirects to https), and the certificate is legit rather than self-signed, so it should be hassle-free.
  • Create New...