taniwha

Members
  • Content Count

    3,561
  • Joined

  • Last visited

Community Reputation

2,071 Excellent

About taniwha

  • Rank
    Construction Gingerbeer

Recent Profile Visitors

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

  1. @Lgg159: sorry, I need more details. I just tried all the mesh collider options (in blender 2.80) and they all worked.
  2. @Nertea: that is possible, I will have to investigate. I do bake the skins to meshes, but I might be doing something wrong in the process. @Tonka Crash: thank you for the sleuthing. Knowing just what parts (even a small sample) gives me a lot to work with.
  3. Oh, yeah, ok. But if you can take note of what triggers it in the future, that would be great. In the meantime, I will keep an eye out for oddities.
  4. I went through the log file, and the biggest excitement I saw was the missing tweakscale module (present in save but not on prefab).
  5. @Tonka Crash: thank you. The data says it all: there is extra geometry. Do you happen to know what it is? I suspect I might need to check for disabled objects. (Yes, I use blender as a debugger ) D'oh, forgot about that case. Thank you. As for the weird physics... very strange. I suspect something is hanging around longer than it should, and somehow becoming part of your station. Can you try with EL 6.5.1 (just edit the version number from the download link) to see if it's limited to hulls?
  6. I have released version 6.6.1 of Extraplanetary Launchpads. Changes from 6.6.0: Add option to display craft hulls. Defaults to off (controlled via EL settings in the space center scene). Add option to dump craft point data: the data is saved to quickhull-points.bin in your current save directory every time a hull is created when the option is on (also, when debugging, a hull will be created every time craft file is loaded). Fix craft hull hanging around after the vessel has been built. Fix incorrect error indication on hulls. @Tonka Crash: if you turn on the debug option, reload the craft file that produces that bloated hull, and get me the file, I can take a look to see what's going on. If you're worried about what's in the file, this is the "format" (for want of a better word): https://github.com/taniwha/Extraplanetary-Launchpads/blob/master/Source/Hull/RawMesh.cs#L67-L86
  7. @LatiMacciato: I was going to ask you to look for the recycler's OnStart message, but you already thought of it, thank you . That confirms what I suspected: the recycle field (trigger collider) is not being found. Is this with EL's recyclers, or another mod's? I tried the recyclers just now and they're fine here (and the files are older than the zip, so they should be the same as yours). If the recyclers are from another mod, it may be that those recyclers are misconfigured: the recycler's trigger collider needs to be named RecycleField, or the name specified by a RecycleField_name = transformname line in the ELReycler node. Recent versions of hierarchy.py in my blender addon make it relatively easy to find the name: any transform with a collider component has a c beside the name (but doesn't show whether it's a trigger collider). I've answered your texture question in the addon thread (not because it's off topic here, but because it's very much on topic there). @Tonka Crash:: I have a suspicion as to why your shell is so oddly shaped: inflatable (or otherwise deployable) parts. If that is the case, then I suspect EL is grabbing the mesh verts in the wrong state.
  8. @LatiMacciato: Answering here not because it's off topic in EL, but because it's on topic here (others with similar questions are more likely to look here). Dealing with textures for KSP in blender varies in difficulty: most difficult being dds (they're upside down). However... UVs are are done the same way as any other blender model. The exporter uses the first layer on the list (and only one layer because when I tried supporting two, I found that KSP ignored the second layer). That's the easy part (hah, from what I've heard from other modders regarding UVs...) done... Materials are a little fiddly, but not too bad... Before doing anything (this is generally once-only), ensure the shader presets are installed: in User Preferences -> Add-ons, open the Mu model import panel. You should find a Shaders section with an "Install KSP Shader Presets" button. Click that, it will install a bunch of shader configs that you can use later. (config templates are a little advanced and off topic for this post, but the color palettes might interest you (for texture and image painting in blender). gamedata path is for importing craft files). With your object selected, go to the materials panel and add a material (make sure it's connected to the mesh rather than the object: dropdown to the right of the new material button/material name). Then scroll down through the panel until you find the Mu Material section. At the top of that, you will find a "Shaders" dropdown: from that select the shader you want to use (requires previous step, so if there's no list, go do that). Selecting a shader will fill in a bunch of values with reasonable defaults. The "Name" field is the name of the material in the .mu file. "Shader" is the name of the shader that will be used and must be one available to KSP when the model is loaded (Unity, KSP, or mod shader should be ok). I'll use "KSP/Diffuse" as an example because it's simple. Below that is a series of collapsed boxes: Textures, Colors, Vectors, Float2 and Float3 (I never did figure out whether the two float types in a mu material spec can be merged, or what the exact difference is in unity): those hold the various shader properties, and those with fields in them will have a dot to the right of the bar. For KSP/Diffuse, only Textures and Colors have values. In general, you need to edit only Textures, so open that. In there you'll find a list of shader properties (click on the one you edit, but for KSP/Diffuse, there's only _MainTex), a field with the property name (don't edit unless you know what you're doing), and below that, the name of the texture to use (default is "gray"): set this to the name of your texture (for preview in blender, you need to have an image loaded with the same name in the image editor). I think that's pretty much it. Other shaders just have more/different properties. Note that not all shaders are supported for viewing in blender (I haven't figured out the node setup), but for those that are, they look pretty cool in Eevee render .
  9. Hmm, I've noticed odd shapes on some ships, but they all had launch clamps (everything else seemed right). I should have put that debug flag (to dump the point cloud) in after all. As for when it should go away: when you build and release. I thought I tested that but I realized now that I tested only with the disposable pad, which of course destroys the shell when the pad module is destroyed, so not a valid test. Oops, sorry. I had debated the toggle: my thought was the shell would stand in for the ship under construction as an aesthetic thing. Obviously not . I'll try to get some fixes out soon (including that debug option!)
  10. I got the rotations sorted out. There's still a problem with either bind pose setup or location/scale animation, but it works much better now.
  11. @Olympic1: another update: the cause of the fcurve problem is that it seems the skeleton/armature is not anywhere near the skins in the hierarchy. I'm not sure how, of even if, I can automate this. [edit] or at least partially caused by that [edit 2] Actually, I'm not sure about that at all. Not one skirt bone has a nice rotation, and none of the skirt bones work properly. The switches are all unrotated and do work properly. I did noticed while getting export that blender's bone rotation fcurves are in bone space (location can be forced to be parent space), so I guess I've got to figure out what I'm doing wrong with the rotations.
  12. @Olympic1: the problem was exactly what I thought it was: two skins sharing the skeleton. That is fixed, but it turns out I've got the fcurve transformation wrong so that still needs fixing.
  13. Yeah, that's pretty messed up. Just a general failure all-round. I see the problem, though: it's because there are two skins sharing the one armature hierarchy. I was wondering if I would need to support that situation. It looks like the answer is a resounding "yes".
  14. I have finally got armature (ie, skinned mesh renderer with bone deformation) support working, for both import (which it wasn't, really, before) and export, including animation of bones. (post got merged) @Olympic1: oh, great well, thanks, I'll look into that (I did my testing on the launch clamp and @Angel-125's DSEV centrifuge).
  15. That I have automated (I haven't looked at it for month) However, due to the way Kethane is packaged, automation is a little more difficult so I haven't gotten there yet.