REDACT3D

Note that when importing an .mu the 3d model will not be all joined togeather and Ngons have been created. so I just Merge by distance to clean up stuff. and dissolve ngon edges. it all gets automatically cut up again when exported Alright, so the wings. The things that cause problems: -Angled flap rotations. (how the surface of the flap mount is not at 90dagree angles) Flaps ignore local rotations and rotate along root X? -Textures are not flipped when mirrored. (how textures do not auto correct flipping, so words will be reversed like reading in a mirror) -Wing generates hardly any lift. feels like a barn door. but has blue lift arrows when toggled on (rotations or semithin) - Authority limiter and deploy are reversed lol Note that this is a .mu file loaded from backup. so the correct origin point and root location have not yet been applied . Now, if I apply a Mirror Modifier in blender, it demonstrates how the textures are mirrored in KSP. Up is still up and down is still down but everything else is flipped as one would expect. this needs to be corrected for. The easy way out is to design textures that are identical. Would make it faster to make too. But less room for detail. And note how the wing tapers out to the tip. It's basically a Dimond shape cross section. So it's imperative the fins be placed exactly lol Then the 3 colliders that get parented to the wing. low poly. 90dagree flat face for mounting. here you can see how the fins are children of the wing but buffered with an Empty called ___Rotation. This offsets the rotations so that in theory all I need to do is apply a rotation on the X axis and the flap SHOULD rotate as expected. because I'm rotating around individual origins and using the local rotation. And this works in blender. Note that i've set all rotations to Quats The wing mesh has it's origin at the center of geometry, then it's pairented to the root Wing empty at 000 Made a new texture so that it can be mirrored. But as you can see, the rotations and locations did not work out that well. gotta fix. All I did, was set the origin of the wing from the center of geometry to the world origin 000. to fix the offset with the fins. The center of the wings is now where the attach point is. But the overall rotation of the wings clearly needs fixin' Okay. Graphically the wings appear to be rotated correctly. I rotated the wing mesh object inside the root empty by -180 on the z and -90 on the x. And it's important to note that i haven't even added flap functionality yet. Checkout the crazy offset and drag going on here. no lift and lots of drag leading to low speed and just rolling off the runway. if i can avoid the dam lights at the end! Remember, no flaps yet. but how the heck do yeah fix the lift thing? PART { name = WingK35 module = Part author = REDACTED rescaleFactor = 1 CoMOffset = -1.2, 0.4, 0 CoLOffset = -1.2, 0.4, 0 CoPOffset = -1.2, 0.4, 0 TechRequired = 0 entryCost = 0 cost = 0 category = 0 subcategory = 0 title = WingK35 manufacturer = REDACTED description = A wing. attachRules = 0,1,0,1,1 mass = 0.2 thermalMassModifier = 8.0 emissiveConstant = 0.95 dragModelType = none maximum_drag = 0.02 minimum_drag = 0.02 angularDrag = 2 crashTolerance = 15 maxTemp = 2400 explosionPotential = 0.1 fuelCrossFeed = True bulkheadProfiles = srf tags = Wing MODEL { model = REDACTED/Parts/Aerodynamics/WingK35/WingK35 } MODULE { name = ModuleLiftingSurface useInternalDragModel = True deflectionLiftCoeff = 2.0 dragAtMaxAoA = 0.6 dragAtMinAoA = 0.0 } } Clearly it's offsets now as mentioned before. What is the actual value of the offset? is it a Eular? and XYZ Quat or a XYZ location with a multiplier on it? can I just point to a game object to get this offset value or does it need to be manually assigned? It appears like i've finally got the rotations correct. using the Shuttle delta wing as the template. the x is -90 y is 0 and z is -180. Holy smokes that took like 25 runs of the game to get right >.< moving onto fins.. lol PART { name = WingK35 module = Part author = REDACTED rescaleFactor = 1 node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 1 CoMOffset = -1.6, -0.4, 0 CoLOffset = -1.6, -0.4, 0 CoPOffset = -1.6, -0.4, 0 TechRequired = 0 entryCost = 0 cost = 0 category = 0 subcategory = 0 title = WingK35 manufacturer = REDACTED description = A wing. attachRules = 0,1,0,1,1 mass = 0.5 thermalMassModifier = 8.0 heatConductivity = 0.06 emissiveConstant = 0.95 dragModelType = none maximum_drag = 0.02 minimum_drag = 0.02 angularDrag = 2 crashTolerance = 15 maxTemp = 2400 explosionPotential = 0.1 fuelCrossFeed = True bulkheadProfiles = srf tags = #autoLOC_500207 MODEL { model = REDACTED/Parts/Aerodynamics/WingK35/WingK35 } MODULE { name = ModuleLiftingSurface useInternalDragModel = True deflectionLiftCoeff = 5.0 dragAtMaxAoA = 0.6 dragAtMinAoA = 0.0 } RESOURCE { name = LiquidFuel amount = 0 maxAmount = 300 } }

Hey ColdJ. Tanks for responding with more great info! Geez no need to apologize! Before this I was sitting around by myself banging my head on the desk by myself lol This is way more help then I expected and is very appreciated thank you! KSP forums are the best apparently haha I was actually comin' back here to advise that the 'module = part' seems to be automatically added when I export from Blender. even if I remove it manually from the script before exporting, the blender addon I'm using must add it to the config just like the node attach points. Also realized that I didn't say that I was using a Blender Addon to begin with. I assume everyone uses this addon to make parts. The Blender addon is called "Mu model format (KSP). This is the thing that lets me import the .mu files as a 3d object along with the dll textures. I assume one could create a part without this addon, but sure would be hard to guess the names of game objects and hexarchy. lol Not a bad way to start off though, getting to open the .mu files and looking at how it's put together helps sooo much compared to visualizing abstract code on a game object that gets all of it's components instantiated at run time. There's actually stuff to look at. Neat. Right? Ahhhhh, okay. that makes sense. encountered an issue during testing parts that hinted towards this. Was one of those times when you change a number of things to see if it works. It worked so didn't look into it more. but this explains it. Awesome! That's what I get for not doing one thing at a time haha. But takes a while to load the game so.. you know ^.^ Currently my file structure looks like: GameData/ REDACTED/Parts/Robotics/SquarePiston/SquarePison You can see that I place a folder inside with the same name of the part. Makes it funny lookin' on the directory point. And got a Category and Parts folder inside Parts (just like how Squad has it) This is where I have my Category.cfg and tab icon. At least this way I have a tab on the main parts screen to dump all of my creations. Going to get spammed soon and will have to start organizing better. This format will help with that. Beauty. I was dreaming of the possibility of creating one standard size part and just duplicating the files and resizing them for added variations, but it's not as easy as you'd think. just because it doesn't seem to work with every style of part. for example BD Armory's targeting ball cam. The size will change correctly in the Build view but when you load the craft it reverts back to the stock size. Had to actually make a new .mu and manually scale the objects down in blender. and that stuck. But that's like a mod of a mod thing going on. Don't expect stock parts to all act like that. For BD armory, looks like there's an rescale code that applies to all parts set to 2.5. contained in a settings file located in the parts folder. so it has special conditions. Ohhh awsome just what I'm lookin' for. Perfect thanks bud. I'll experiment with this a little woot. My thought proses right now is like: What kind of part did I always want but did not exist? okay, what current part is near that function? Then will find that part in the list and open the files to observe. A lot of the time It's a combination of more than one. Like, do I make a standard wing? No. I want to make a wing with built in front and rear flaps that make sound and also is a fuel tank with a drain valve. that's just how I roll. LOL But if I made just a simple wing with separate parts you attach the same every time. it would be easier. For example, my f35 style wing. it's always going to need front and rear flaps, not very fun to place those every time. so why not just build it as a single object? Didn't turn out well because of how the mirroring in symmetry mode flipped things. like the deploy was reversed and pressing up makes you go down lol. For some reason wings are hard for me. Or one wing will be lifting up while the other pushes down. I'll have a spend a bunch more time on this wing thing before getting it working properly. Need a wind tunnel over here haha Thanks, guys, for all the help really appreciate it PS: Made some forklift parts. Forks, Shifting fork mount, lifters and this Skid. The skid is basically a hollow collider with adjustable friction like a grip pad, also changes color. and has 9 attach points to secure luggage. Will be makin' standard airline style carco containers to work with this as well. Figure I should learn to walk before going to the moon. PART { name = Skid module = Part author = REDACTED rescaleFactor = 1 TechRequired = 0 entryCost = 0 cost = 0 category = 0 subcategory = 0 title = Skid manufacturer = REDACTED description = non-slip, three grip levels. attachRules = 1,1,1,1,0 mass = 0.1 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 99 maxTemp = 2000 bulkheadProfiles = 0 tags = #autoLOC_6011097 mapActionsToSymmetryParts = false MODEL { model = REDACTED/Parts/Payload/Skid/Skid } MODULE { name = ModulePhysicMaterial activePhysicMaterialName = MediumGrip PhysicMaterialName = MediumGrip PhysicMaterialName = HighGrip PhysicMaterialName = ExtremeGrip PHYSICMATERIALCOLORS { MATERIALCOLOR { name = MediumGrip color = 1,1,1 } MATERIALCOLOR { name = HighGrip color = 0.63,0.63,0.63 } MATERIALCOLOR { name = ExtremeGrip color = 0.38,0.38,0.38 } } } NODE { name = bottom2 transform = node_stack_bottom2 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom3 transform = node_stack_bottom3 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom4 transform = node_stack_bottom4 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom5 transform = node_stack_bottom5 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom6 transform = node_stack_bottom6 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom7 transform = node_stack_bottom7 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom8 transform = node_stack_bottom8 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom9 transform = node_stack_bottom9 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top2 transform = node_stack_top2 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top3 transform = node_stack_top3 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top4 transform = node_stack_top4 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top5 transform = node_stack_top5 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top6 transform = node_stack_top6 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top7 transform = node_stack_top7 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top8 transform = node_stack_top8 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top9 transform = node_stack_top9 size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = top transform = node_stack_top size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom transform = node_stack_bottom size = 1 method = FIXED_JOINT crossfeed = True rigid = False } }

* Typing intensifies * Going to make a bunch of interesting shapes. since the animation thing works. that swings the door open for all kinds of stuff. Mabe some arch shapes that move along an arch shaped path. oh and some interesting air intakes that can deploy. or supersonic nose cones wow beauty haha Looks like you can also toggle if the attached part "sticks" to the local position or not. so you can use the commands to 'inch' a motor along a track. or control the position of an object like a grabber. looks like it unparents the game object when toggled. Can actually make payload doors with attach points nice! thanks again for the insight! I guess now I can focus on the best way to distribute and format it all. BEFORE I texture everything. Will Bake the diffuse textures at 1024 into a single atlas. and all that jazz. for testing I'm just using separate ,png's for each material. (at 4096 resolution lol) and that thing with the folders. could you please point me in the direction of how to get a mod package approved for others to consume? I know it's common to use Git, but what is the official way? standby.

https://i.imgur.com/655nYoP.mp4 https://i.imgur.com/VgsHGlH.png https://i.imgur.com/TzBe6lB.png Oh my god the Animated Attached works haha PART { name = SquarePiston module = Part author = REDACTED mesh = SquarePiston.mu //temp rescaleFactor = 1 TechRequired = none entryCost = 0 cost = 0 category = 0 subcategory = 0 title = SquarePiston manufacturer = REDACTED description = A square piston. attachRules = 1,1,1,1,0 mass = 0.001 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 1 crashTolerance = 50 breakingForce = 50 breakingTorque = 50 maxTemp = 2500 emissiveConstant = 0.8 bulkheadProfiles = 0 tags = Piston MODULE { name = ModuleAnimateGeneric animationName = NlaTrack actionGUIName = TogglePiston startEventGUIName = Retract Piston endEventGUIName = Extend Piston actionAvailable = true animationIsDisabled = false allowManualControl = true allowAnimationWhileShielded = true allowDeployLimit = true revClampDirection = false revClampSpeed = true revClampPercent = true } NODE { name = top transform = node_stack_top size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom transform = node_stack_bottom size = 1 method = FIXED_JOINT crossfeed = True rigid = False } } woot!

Oh, Awesome, thanks for the formatting tips! Oh yeah lol, that scaleFactor was accidently left in lol. I was trying to rescale the part after exporting the .mu like a lazy person.. Spoilers. it didn't work. messes up the transforms. goes all whacky. But learned that there's a difference between the build view and the world view. As in, it appears to rebuild (and rescale) the part when you load the craft. I'd never even thought about that before. But obviously has to instantiate the gameobjects in non kinematic mode lol. Good eye man. Okay, I'll use the directory point method of defining the .mu asset files from now on. It seemed easier to just type mesh = demo.mu then to type the file location for each one at first. Like makes it easy to look at for my new eyes. less stuff going on. But if it's the new standard, why not. Seems like more work but must be used for somthin' . OH can you re-order the variables? does the order of operations apply to how the variables are laid out? Like could i do this instead? : PART { mesh = Actuator.mu // I know now this is not the right way name = Actuator manufacturer = REDACTED author = REDACTED title = Actuator description = An actuator. category = 0 subcategory = 0 TechRequired = none entryCost = 0 cost = 0 TechRequired = none attachRules = 1,1,1,1,0 mass = 0.001 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 1 crashTolerance = 50 breakingForce = 50 breakingTorque = 50 maxTemp = 2500 emissiveConstant = 0.8 bulkheadProfiles = 0 tags = Piston MODULE { name = ModuleRoboticServoPiston servoTransformName = Shaft servoSrfMeshNames = CapCOL.collider baseTransformName = Motor servoAttachNodes = top traverseVelocityLimits = 0.1, 1 hardMinMaxLimits = 0,1 softMinMaxExtension = 0,1 mainAxis = Y servoMass = 0.25 maxMotorOutput = 100 positionSpringMutliplier = 100 positionDampingMutliplier = 20 motorizedMassPerKN = 0.0002 motorizedCostPerDriveUnit = 1 efficiency = 0.75 baseResourceConsumptionRate = 0.01 referenceConsumptionVelocity = 1 RESOURCE { name = ElectricCharge rate = 0.1 } } MODULE { name = ModuleResourceAutoShiftState affectedResourceName = ElectricCharge affectedModuleName = ModuleRoboticServoPiston resourceShutOffHandler = true resourceStartUpHandler = true resourceShutOffStartUpUsePercent = true resourceShutOffAmount = 0 resourceShutOffPercent = 0 resourceStartUpAmount = 0 resourceStartUpPercent = 5 } NODE { name = top transform = node_stack_top size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom transform = node_stack_bottom size = 1 method = FIXED_JOINT crossfeed = True rigid = False } }

Oh perfect bud thanks! I will have to experiment with this Animated Attachment Module. Says it just makes it work automatically so should be easy to test lol this is the only code I can read from that file: // Add AnimatedAttachment modules to Squad assets @PART[*]:HAS[@MODULE[ModuleAnimateGeneric]]:NEEDS[AnimatedAttachment] { %MODULE[AnimatedAttachment] { } } @PART[*]:HAS[@MODULE[ModuleGimbal]]:NEEDS[AnimatedAttachment] { %MODULE[AnimatedAttachment] { } } @PART[*]:HAS[@MODULE[ModuleControlSurface]]:NEEDS[AnimatedAttachment] { %MODULE[AnimatedAttachment] { } } @PART[*]:HAS[@MODULE[LaunchClamp]]:NEEDS[AnimatedAttachment] { %MODULE[AnimatedAttachment] { } } Not a lot to work "with" (4 lines of code) but if it's automatic I guess all it has to do is toggle the metaphorical enable button. Good because it works. Bad because I don't know how it works. lol If I could get the stock game to scale the "boot" in the Y Axis while the "Cap" translates inside the Servo Module that would mean I don't have to use the module for that particular part. That would be a bonus in my eyes. Less to go wrong. You mentioned that it's possible to scale the game object dynamically with code along with the transform translation. Thats good news! But how is this accomplished? Is there a variable I can add that does this? I see the ModuleRoboticServoPiston has the Public variable "MainAxis = Y" That should define the Axis of translation. but is there a similar value that I can use to control the relative scale in the same axis? or can you think of a part that does both the piston movement, with dynamic attach point locations and also scales along a definable axis? Also just want to say thanks for helpin' me out here. really appreciate it. It's nice to chat about it with someone else who doesn't look at you like you're speaking a different language lol

beauty thanks Stone Blue. Quick question: Is it possible to use 'Animation Tracks' to animate Attachment Node positions? or are those just baked as a static location point and cannot be set dynamically? For example, a piston that has a "shaft boot" that "scales" like an accordion. or bellows, while the Cap translates along a linear axis. Giving the effect that the rubber boot is expanding. Rather than multiple several telescopic tubes that translate along the same axis. I can get the animation to work just fine, as in it will extend and retract and can even attach parts to the top of a piston however the attached part does not follow the attachment node when it is animating. I would expect that parenting the node_stack_top to the part of the piston that moves would also make the attachment point move with it. But doesn't? I guess that's why we don't see attachment nodes on payload doors and stuff eh? Can make a regular piston just fine, but it's trying to mix the animation with the piston thing that's gettin' me. Here's a piston I made last night that works great for example. but doesn't use the scale thing on a boot PART { name = Actuator module = Part author = REDACTED mesh = Actuator.mu rescaleFactor = 1 scaleFactor = 1 TechRequired = none entryCost = 0 cost = 0 category = 0 subcategory = 0 title = Actuator manufacturer = REDACTED description = An actuator. attachRules = 1,1,1,1,0 mass = 0.001 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 1 crashTolerance = 50 breakingForce = 50 breakingTorque = 50 maxTemp = 2500 emissiveConstant = 0.8 bulkheadProfiles = 0 tags = Piston MODULE { name = ModuleRoboticServoPiston servoTransformName = Shaft servoSrfMeshNames = CapCOL.collider baseTransformName = Motor servoAttachNodes = top traverseVelocityLimits = 0.1, 1 hardMinMaxLimits = 0,1 softMinMaxExtension = 0,1 mainAxis = Y servoMass = 0.25 maxMotorOutput = 100 positionSpringMutliplier = 100 positionDampingMutliplier = 20 motorizedMassPerKN = 0.0002 motorizedCostPerDriveUnit = 1 efficiency = 0.75 baseResourceConsumptionRate = 0.01 referenceConsumptionVelocity = 1 RESOURCE { name = ElectricCharge rate = 0.1 } } MODULE { name = ModuleResourceAutoShiftState affectedResourceName = ElectricCharge affectedModuleName = ModuleRoboticServoPiston resourceShutOffHandler = true resourceStartUpHandler = true resourceShutOffStartUpUsePercent = true resourceShutOffAmount = 0 resourceShutOffPercent = 0 resourceStartUpAmount = 0 resourceStartUpPercent = 5 } NODE { name = top transform = node_stack_top size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom transform = node_stack_bottom size = 1 method = FIXED_JOINT crossfeed = True rigid = False } } Also LOL, I would like to play audio when my items move but not sure how to set that up from scratch. for parts that normally have sound like landing gear. I can just coppy the FX event stuff but still not sure how to set that up. in unity it's fairly easy to make an Audio Clip Play, just don't understand how to set that up in the .cfg file lol Would be nice to add motor servo sounds that has the pitch change relative to the speed of the motor. I noticed BD Armory has some parts with sound that do this. but I guess the actual events are in some other file? hum. I'll get it.. lol

Wow thank you very much ColdJ, this helps quite a bit. Of course, this spawns more questions but you have confirmed that the hierarchy system works as expected in both unity and blender. with how parenting game objects works in relation to local transforms and world transforms. About those Rotations being a Quaternion instead of Euler Angles. Do you mean you have to manually change the "tool" from Euler to Quaternion within blender? I've noticed that for things like payload door animations, you have to change the rotations otherwise it uses the Euler and only operates the door a small rotation amount equivalent to that rotation angle From Quaternion to Euler. I assume this is because of how the unity engine uses those values and no conversions are being done as that would run slower. idk but yeah so you just set everything to Quat's eh? And thank you for explaining that the offset was for the lift point. And for telling me that it's the right hand side default. of course I'm using the left. I was considering that as an issue but I was like "nah that's too dumb" lol interesting. guess I need to pay closer attention lol how do you define the correct center of lift by referencing a game object? i see at the top the hardcoded position but it would be easier setup imo to reference an object origin in blender you know? Appreciate your input bud

hey guys. I'm just makin' a bunch of new parts and suddenly have hit a wall of confusion related to the Origin Points on each game object that's nested in each part hierarchy. For example, here's what a wing part hierarchy would look like to me in blender. --------eg:--------- -Wing | ------- WingMesh | _____ wing.collider Wing is an empty game object at world position 0,0,0 with a rotation of 0,0,0,0, (is the root .mu used for attaching and scale) WingMesh is the actual mesh with the UV's, textureing and mesh renderer and filter and material. basically what you see. and wing.collider a child of the Wing mesh. this is the convex hull or collider used to raycast for clicking and for drag? Can load up each kind of wing and look at how it's set up. but each one is not the same. As in: does not follow the same standard structure of hierarchy lol anyone have info how the rotations are actually supposed to be set up? it appears that the root is always 000000 but sometimes wings use a PointOfLift empty game object to define the forward vector for the lift i guess? the "documentation" that i can find, is just a big list of namespcaes. but they don't even say what they do lol Kerbal Space Program: PartModule Class Reference is "lift" calculated globally and always Y positive? lol basically im asking what way is up and forward haha What I do now is just set the angles to some arbitrary 90 dagree value and litrally load and run the entire game to see if the lift applies correctly and the mirroring works. but maybe some insight from a fellow nerd may save some time.

Hey folks, If interested, I've just uploaded a new KSP video on YouTube if you guys want to check it out. Would appreciate the feedback and pointers if you guys have em'. I wanted to make this for new players who are joining from playstation side and haven't gotten the chance to play Kerbal Space Program before (like myself!) Just want to say that I think Kerbal Space Program is a great example of an outstanding game. Great message and gameplay combined - I could go on for hours .. but then people think you're nuts. here's a video I made instead... Here's the link: