Eleusis La Arwall
-
Posts
282 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Eleusis La Arwall
-
-
13 hours ago, juanml82 said:
-snip-
But when I posted, I was getting the spawned vehicle looking at the sky and with the root part at the ground level (so if the root part was the middle cargo bay in this screenshot, it would result with the plane spawning with half the fuselage underground.
I've used the LaunchPadSide to build a plane similar to the one from the screenshot. Once with cockpit as root part, once with fuselage as root part and once with a rotated ProbeCore inside a cargobay as root. I was not able to reproduce the problem you describe, all three vessels spawned with the correct orientation.
From the screenshot I see you use a well modded install, have you tried a fresh install with just EL & KD installed?
If you have a craft-file (stock only if possible) that reproduces the error all the time, I'd take a look at it. Otherwise there is not much I can do. -
It's been quite a while but I'm currently working on the next update for Keridian Dynamics. Similar to the EL update it will break savegames. Hopefully v.0.9 will be the last savegame-breaking update and if everything goes as planned it will become the 1.0 release.
I will not release this update before KSP 1.4.3 but I made a PreRelease of the current status for everyone who wants to take a look or do some testing (which I would greatly appreciate
). The PreRelease is only available on GitHub: Download
The picture below shows the new ExtensionPad (left) that can be used to extend exisiting vessels, the LaunchPad (OrbitalPad replacement, middle) and the powerfull LauchPad/ProbeCore combination Keronica.
The LaunchMarkers have been reworked and now show the unity axis at the vessel spawn point (toggleable).Changelog (so far):
Spoiler2018.04.15 - The No-Title-Pre-Release Update - v0.8.9
- Compatibility to EL 6.0
- Re-export all models (except Internals) with unity 2017.1.3p1 and latest parttools
- Language support (english)
- B9PartSwitch support
- A Resource-Switcher (FS, IFS or B9PS) is now mandatory
- All Resource Converters are enabled by default (some require CRP)
- Patchmanager support
- Ore->Metal converters can be disabled
- MetalOre->Metal converters can be disabled
- ScrapMetal->Metal converters can be disabled
- Metal->RocketParts converters can be disabled
- Metal->MaterialKits converters can be disabled
- Metal+Ore->SpecializedParts converters can be disabled
- Dirt->RareMetals+ExoticMinerals converters can be disabled
- Old costs can be restored
- Station Tank Series can be disabled
- (Cargo) Tank Series can be disabled
- Station Tank Series can be crewed
- OSE Workshop default Resource can be switched from MaterialKits to RocketParts
- Integrated 534443s cost-rebalance (thanks a lot!)
- Reintegrated Station Tank Series
- Fixed unused switcher for Cargo Tanks
- StockDrill Patch only applies if no other MetalOre harvester is present already
- Added MetalOre Harvester to MiniDrill
- Reworked Spawn Markers
- Redo MetalOre converters (density change 0.0275->0.026)
- Removed very old hexagonal tanks used when FS and IFS are not installed (no replacement)
- Removed KD-OrbitalPad, KD-SidePad and KD-TopPad
- New Parts:
- KD-Keronica: Rework of the old OrbitalPad. Advanced Probe Core with Launchpad.
- KD-LaunchPad (2 Variants 1.25,2.5): Light-weight replacement for OrbitalPad
- KD-LaunchPadSide (2 Variants 1.25,2.5): Light-weight replacement for SidePad
- KD-LaunchPadTop (2 Variants 1.25,2.5): Light-weight replacement for TopPad
- KD-ExtensionPad (6 variants, 0.625-5.0 meters): Light-weight part to extend exisiting vessels (ELDisposablePad)
- KD-FAVA (early prototype): Fully Automated Vessel Assembler. generates productivity without the need for KerbalsToDo:
Spoiler- Language support (german)
- Thermal Curves Rework
- Flag fix
- Verify KIS/OSE support
- InternalsBig THANK YOU to @534443 for the cost and entryCost rebalance!
On 18/02/2018 at 5:07 PM, b0ss said:This is really cool and I'm glad something like this is being maintained, so happy that there are alternatives to EPL's parts, however I can't be the only one who thinks the hexagonal tanks' textures and models look out of place in this mod, can I?
I think I'm confused about just one thing though, I'm unclear on what exactly the dependencies are for this mod. Does it need anything other than EPL's .dll files?And, will the recycler be able to consume ships part-by-part or will we have to disassemble them manually with KAS? Also, if I wanted to stick to realism and make it so that ore can only be refined into metal and I'll need a modded resource to make LFO, what sort of mods and config edits do you recommend?Yes, the hextanks were very outdated and now they are gone
Still thinking about the best way to make the dependencies a bit clearer. In general all dependencies are for the plugins (dlls), no parts, models or textures from other mods are(/should be) required.
Ships are recycled part-by-part as long as they remain in the RecycleField.On 08/04/2018 at 2:39 AM, LatiMacciato said:EL major update!
for everyone who uses EL 6.0 ONLY:
/GameData/KeridianDynamics/KeridianDynamics-EL.cfg:// ########## ModuleManager Patches ########## @PART[KD-Pad]:NEEDS[Launchpad|SimpleConstruction] { MODULE,1 { name = ELLaunchPad SpawnTransform = LaunchPos PadName = Surface Launchpad } } @PART[KD-OrbitalPad]:NEEDS[Launchpad|SimpleConstruction] { MODULE,1 { name = ELLaunchPad SpawnTransform = LaunchPos PadName = Orbital Launchpad } } @PART[KD-SidePad]:NEEDS[Launchpad|SimpleConstruction] { MODULE,1 { name = ELLaunchPad SpawnTransform = LaunchPos PadName = Launchpad (Side) } } @PART[KD-TopPad]:NEEDS[Launchpad|SimpleConstruction] { MODULE,1 { name = ELLaunchPad SpawnTransform = LaunchPos PadName = Launchpad (Top) } } @PART[KD-Recycler]:NEEDS[Launchpad|SimpleConstruction] { MODULE,2 { name = ELRecycler RecycleRate = 25 // RecycleField_name = RecycleField } MODULE,3 { name = ELTarget TargetName = Recycler TargetTransform = RecycleTarget } } @PART[KD-RecyclerSmall]:NEEDS[Launchpad|SimpleConstruction] { MODULE,2 { name = ELRecycler RecycleRate = 5 // RecycleField_name = RecycleField } MODULE,3 { name = ELTarget TargetName = RecyclerSmall TargetTransform = RecycleTarget } } @PART[KD-RecycleSite]:NEEDS[Launchpad|SimpleConstruction] { MODULE,1 { name = ELRecycler RecycleRate = 0.1 // RecycleField_name = RecycleField } MODULE,2 { name = ELTarget TargetName = Recycle Site TargetTransform = TransformRecycle } } @PART[KD-Fundament-*]:NEEDS[Launchpad|SimpleConstruction] { @MODULE[LaunchClamp] { @name = ELtendingLaunchClamp } } @PART[KD-LaunchSite]:NEEDS[Launchpad|SimpleConstruction] { MODULE,2 { name = ELSurveyStake } } @PART[KD-MobileVAB]:NEEDS[Launchpad|SimpleConstruction] { MODULE,2 { name = ELSurveyStation StationName = Mobile VAB } MODULE,3 { name = ELWorkshop ProductivityFactor = 5 } } @PART[KD-OrbitalHangar]:NEEDS[Launchpad|SimpleConstruction] { MODULE,1 { name = ELLaunchPad SpawnTransform = LaunchPosVAB PadName = Orbital Hangar VAB } MODULE,2 { name = ELLaunchPad SpawnTransform = LaunchPosSPH PadName = Orbital Hangar SPH } MODULE,3 { name = ELWorkshop ProductivityFactor = 3.5 } } @PART[KD-FC]:NEEDS[Launchpad|SimpleConstruction] { MODULE,6 { name = ELWorkshop ProductivityFactor = 2 } }Thank you very much for the quick fix!
On 10/04/2018 at 4:29 PM, juanml82 said:Question, is there a particular way to orient the sidepad? I had been using it, resulting in rovers spawning standing and with the root part at the ground altitude - which lead to fancy explosions if the root part was in the middle of the vessel. Even accounting for the root part, if the side pad is at the side of a base, can the rovers spawn horizontal to the ground?
I'm not sure if I understand that correctly, the rovers spawn looking at the sky? If a rover is spawned correctly aligned when normally launched from VAB/SPH it should also spawn correctly aligned from the SidePad. Could you upload some pictures visualizing the problem?
-
Here's a little preview to a new fusion reactor model I just finished:
-
@blackheart612 Thank you very much
Some more Landing Leg stuff:
After the basic landig leg I've tried to achive some more complex builds. Especially the second example took me lot of time to figure out. I won't explain them as detailed as before but hopefully enough to rebuild them. I save the blend file under a different name and start with a new unity scene for each example. Also the animation names change, so you may need to adapt the config ("animationTrfName" and "animationStateName" in ModuleWheelDeployment).
1.) Position
This example extends the whole leg 1 m to the side before deploying the piston and it also uses constraints (Pneuma objects). The hierarchy has changed a little and therefor all new or moved objects are marked in blender. The ChassisCollider is now a child of ChassisBlue, the rest is new. The Pneuma objects have the origin at their individual hinge points and PneumaHullRed is 180° rotated around the x-axis to make Z+ face down.Spoiler
The unity setup is pretty much the same as before. StaticCollider must be set up and the animation needs some new keys for the sideway-movement.
Spoiler
Config also stays the same, just the constraints need a new module:
MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = PneumaStickYellow rotatorsName = PneumaHullRed } CONSTRAINLOOKFX { targetName = PneumaHullRed rotatorsName = PneumaStickYellow } }Now check the wheelCollider position in KSP. I usually set gravity to 0.04 and move the vessel to the side on the launchpad until it drops down:
Spoiler
The constraints work as well.
2. Rotation
This example rotates the leg by 30° before deploying the piston and this is where it gets messy. First I'll explain my unsuccessfull attempt and show the problem that arises:
The blender setup is the same as the example above just the origin of ChassisBlue has been set to the hinge-point. All children except the PneumaStickYellow still have their origin at 0,0,0 (global coordinates).Spoiler
Unity setup is again the same, just the animation needs rotate keys instead of position.
Spoiler
Config is also the same again.
When I verify the position of the wheelCollider, it is off. First thing I noticed is a minimal vertical offset but the main problem is the horizontal offset. For hours I've tried everything I could come up with but the result is always the same (or a broken model).
Spoiler
My thoughts on deployTgt mechanic:
When the leg deploys in KSP, the animation is played and at a given point during this animation (TsubSys key in ModuleWheelDeployment), the suspension-object and all children are "moved" to the location of deployTgt. The (local) position of the suspension-object and children is identical to their position on the last frame of the animation. Y+ of the deployTgt also sets the axis for the suspension. The suspensionOffset in ModuleWheelSuspension is an offset for the "moved" suspension-object along the Y axis of deployTgt. What I don't know/understand is how the wheelCollider gets its offset from deployTgt position. So currently my best guess is that the wheelCollider is not lowered along the Y-axis of deployTgt but instead along the global Y-axis.I was about to write this down up to this point and ask for help when I realized that the model could be rotated by 30° in retracted state. This way the suspension is always along the global Y axis. The model would need to be rotated manually in the config file later. A quick look at the stock legs revealed that the models are rotated:
... node_attach = 0.0, 0.0, 0.0, 0.0, 0.3756781, 0.9267502 ... // From landingLeg1The solution
1.) In blender set the cursor to the hinge-point of ChassisBlue
2.) Make sure pivot point is 3D cursor
3.) Select ChassisBlue and PneumaHullRed and rotate them 30° around the X axis.Spoiler
Save and go to unity. Some of the animation keys need to be set up again but everything else should be fine. Export the model and open the config.
Now a direction vector is required that is perpendicular to the flat sides of StaticGray. It needs to be parallel to the green arrow in the picture above (the one on the textured model). 0.0, 0.5, 1.0 is such a vector and the config should look like thisnode_attach = 0.0, 2.4384, -0.26651, 0.0, 0.5, 1.0, 1Another thing I forgot to mention in the tutorial is Center of Mass Offset. It should be set to move it away from the foot.
CoMOffset = 0.0, 2.4, 0.0Fire up KSP and verify that the wheelCollider is in place now
Spoiler
Done! The attachment of the legs to the capsule is a bit off but it should be easy to fix with some trial and error on the attach node.
I will add the additions to OP after I did dome more experiments with legs (and maybe wheels ?!).
-
1 hour ago, Psycho_zs said:
That's what I ended up with for now:
An interesting problem. I couldn't find a solution to filter the same key for various exact matches, so I came up with a patch that adds a new key with identical values for all matches:
@PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#nodeType[size?]]]:BEFORE[stockSizeDockingPortPatch] { @MODULE[ModuleDockingNode]:HAS[#nodeType[size0]],*{stockSizeDockingPort = true} @MODULE[ModuleDockingNode]:HAS[#nodeType[size1]],*{stockSizeDockingPort = true} @MODULE[ModuleDockingNode]:HAS[#nodeType[size2]],*{stockSizeDockingPort = true} } @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#stockSizeDockingPort[true]]]:FOR[stockSizeDockingPortPatch] { @MODULE[ModuleDockingNode],* { // If you want X degrees wide margin, use cos(0.5*X) as captureMinRollDot // 0.5 degrees = 0.99999048 // 1 degree = 0.99996192 // 2 degrees = 0.9998477 // 3 degrees = 0.99965732 // 5 degrees = 0.99904822 %captureMinRollDot:NEEDS[!DockRotate] = 0.99996192 // more relaxed version to use with DockRotate %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 %snapRotation = true %snapOffset = 30 } } @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#stockSizeDockingPort[*]]]:FINAL { @MODULE[ModuleDockingNode],*{!stockSizeDockingPort = true} }( stockSizeDockingPort is key I made up, not a real one.)
I'd really like to see a more elegant solution.
-
Landing gear and wheels are not easy and even though there is quite some information spread across the forum it took me very long to get working results. One thing I really missed was a step-by-step tutorial that tells me what is required, where stuff needs to be placed and so on. A couple of days ago, I had successfully created my first working landing leg. It's very simple with just a suspension and rotateable foot but it works! Now I wanna try to write down a step-by-step tutorial on how to create the most basic landing legs. I also hope to get some feedback to improve my assembly of landing legs and/or this tutorial.
Software:
- Blender (v2.79)
- Gimp (v2.8.22)
- Unity (5.4.0p4)
- Part Tools
- NotePad/NotePad++1. Blender
The Blender part is rather easy just make sure to build the retracted version. Create the objects as shown in the picture and drag them in the correct hirearchy. What I found to be important is that the center of foot-hinge is at 0,0,0 and the model is build around it. All objects should have their origin at 0,0,0, rotation 0,0,0 and scale 1,1,1.Spoiler
2. Unity
1.) Start with a New Scene and delete everything in it. "Create Empty" (Ctrl+Shift+N) and set position to 0,0,0.
2.) Make sure the Layers are set up correctly in unity. The following are required: Layer26: WheelCollidersIgnore, Layer27: wheelColliders, Layer30: SurfaceFX. If the Layers aren't set up already, expand the Layers, click "Add Layer" and enter the Layer names at the corresponding User Layer.
3.) Add the Part Tools script and set up Model Name, URL and Texture Format.Spoiler
1.) Drag the TestLeg.blend file to the newly created GameObject (I use the .blend file directly with .fbx conversion done in the background)
2.) Select "ExampleLandingLeg" and remove the Animator Component (right click / Remove Component).Spoiler
1.) Create an Empty, rename it to "wheelCollider" and drag it as child of "GameObject".
2.) Create an Empty, rename it to "deployTgt"" and drag it as child of "ChassisBlue".
3.) Make sure their position is 0,0,0.Spoiler
Now all objects except the PistonCollider (comes later) are present and they can be configured. Start with the deploy animation.
1.) Select "ExampleLandingLeg".
2.) Hit "Add Component / Miscellaneous / Animation" (Note that AnimatoR and AnimatioN are two different things!).
3.) Click " Window / Animation" (or Ctrl + 6).Spoiler
The Animation Window pops up. Click "Create" and enter a name like "deployLegAnim".
1.) Click "Add Property" and navigate to "ChassisBlue / PistonRed / Transform".
2.) Add the "Position" entry by hitting the small +.
3.) Change to CurveView.Spoiler
1.) Go to Frame 60.
2.) Set Z position to -2 (suspension-distance).
3.) Animation is done, close the Animation window.Spoiler
1.) Select "ChassisCollider".
2.) Remove the MeshRenderer Component (right click / Remove Component).
3.) Hit "Add Component / Physics / MeshCollider" and check the "Convex" box.
4.) Set layer to "WheelCollidersIgnore" (26).Spoiler
1.) Select "wheelCollider".
2.) Hit "Add Component / Physics / Wheel Collider" and configure it as shown in the picture (non-default values are marked red).
Mass: IDK, just works
Radius: The distance from hinge-origin (0,0,0) to the lowest point of the foot (while retracted)
Suspension Distance: As the name says (should be the same distance covered by the animation)
Spring: Springhardness
Damper: IDK, just works
Target Position: Default suspension position. 1 is fully deployed (landing gear), 0.5 is half deployed (wheels).
3.) Set Layer to "wheelColliders" (27).Spoiler
There is one last step but I highly recommend to save the unity scene at this point and exported/test the model. Once the PistonCollider is added, it becomes much harder to verify that the wheelCollider is in the right position (in KSP).Spoiler
Switch to a filebrowser and navigate to the GameData folder of the KSP installation. Create a new folder "ExampleLandingLeg" and copy modelELL.mu and the texture in that folder. Also Create or copy a new config file in that folder and paste the following (the config already references "PistonCollider" which is not yet included but don't worry):
PART { // General parameters name = ExampleLandingLeg module = Part author = YourName // Asset parameters mesh = TestLeg.mu scale = 1 rescaleFactor = 1 // Node definitions - Position X, Position Y, Position Z, Up X, Up Y, Up Z node_attach = 0.0, 1.5, -0.19, 0.0, 0.0, 1.0, 1 // Editor parameters TechRequired = advLanding entryCost = 1 cost = 1 category = Utility subcategory = 0 title = ExampleLandingLeg manufacturer = None description = Soon TM tags = example landing leg // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 0,1,0,0,0 // Standard part parameters mass = 1.0 bulkheadProfiles = srf // Drag dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 // Damage and Temperature crashTolerance = 40 maxTemp = 2200 // Resources // Modules MODULE { name = ModuleWheelBase wheelColliderTransformName = wheelCollider // object with WheelCollider-Component wheelType = LEG FitWheelColliderToMesh = False // setting this to true will override the radius and center parameters radius = 0.1 // Same as set in unity center = 0,0,0 // Same as set in unity mass = 0.05 // Same as set in unity autoFrictionAvailable = False clipObject = PistonCollider // Moving Collider for the piston. Causes trouble if not set. TooltipTitle = none TooltipPrimaryField = groundHeightOffset = 4 } MODULE { name = ModuleWheelSuspension baseModuleIndex = 0 // Reference to the location of "ModuleWheelBase" in the config (first module is 0) suspensionTransformName = PistonRed // object (and children) that will be moved by suspension suspensionColliderName = PistonCollider // Moving Collider for the piston. Causes trouble with the wheelCollider if not configured suspensionDistance = 2 // Same as set in unity suspensionOffset = 0 // IDK. There is some interaction with the position of deployTgt in unity targetPosition = 1 // Same as set in unity; With no force applied the suspension will be fully deployed springRatio = 20 // Same as set in unity; Springhardness damperRatio = 1 // Same as set in unity } MODULE { name = ModuleWheelDeployment baseModuleIndex = 0 // Reference to the location of "ModuleWheelBase" in the config (first module is 0). animationTrfName = ExampleLandingLeg // object with Animation Component (not the animated object!) animationStateName = deployLegAnim // name of the animation deployedPosition = 1 deployTargetTransformName = deployTgt // object that will become the wheelCollider when deployed TsubSys = 1 // When will wheelCollider switch during the animation. 1=end, 0=start } MODULE { name = ModuleWheelLock maxTorque = 500 } MODULE { name = ModuleWheelBogey baseModuleIndex = 0 // Reference to the location of "ModuleWheelBase" in the config (first module is 0) bogeyTransformName = FootYellow // Object that will act as foot deployModuleIndex = 2 // Reference to the location of "ModuleWheelDeployment" in the config (third module is 2) maxPitch = 160 // Degree. Maximum positiv deflection minPitch = -160 // Degree. Maximum negative deflection restPitch = 0 // Degree. Position with no influences pitchResponse = 100 bogeyAxis = 1, 0, 0 // Axis to rotate around bogeyUpAxis = 0, 0, 1 // Axis pointing upward. Can be 0, 1 or -1 } }Save the config and fire up KSP. Choose a Pod, add four legs around it and launch vessel (it may jump a bit at first, use launchclamps to avoid). If everthing went well, the foot should be exactly level with the ground and the suspension should work as well. Hit Alt + F12 to bring up the cheatmenu and play a bit with the gravity to see if everthing is alright. Hit "g" to retract the landing gear and deploy it afterwards again. The piston will go in the ground and the vessel jumps high at the end of deployment. So the PistonCollider needs to be set up to avoid this. Close or minimize KSP and go back to unity.
The PistonCollider:
1.) Create another empty GameObject, name it "PistonCollider", make sure it is at 0,0,0 and set it as child of "PistonRed"
2.) Add Component "Physics / CapsuleCollider" and configure it as shown. The lower end should match the center of the wheelcollider (0,0,0)
3.) Set Layer to "SurfaceFX" (30)Spoiler
Re-export the model, fire up KSP or Reload the Database and test the deploy mechanic. Done!My sincere thanks to the people on the forum who shared their experience and knowledge about landing legs and wheels!
EmbersArc for the cheat-sheet
NecroBones and nli2work for the information provided in the Landing Legs 1.1 thread
SpannerMonkey(smce) for information provided in the most basic wheel thread
blackheart612 for the guide to making Deployable Landing Gears
Nils266 for the "LandingLeg2" part from PlanetaryBaseSystems, it was a very usefull example.
Nifty255 and linuxgurugamer for Kerbal Object Inspector Continued -
Thanks for the update!
Harvester and converter now work as intended. The MM-patch for IntakeATM does not. MM 3.0.6 shows an error during the loading screen and the log reveals:
[ERR 14:37:15.641] [ModuleManager] Error - pass specifier detected on an insert node (not a patch): GTI_Utilities/Resources/MM_IntakeAtm/RESOURCE_DEFINITION:FOR[GTI]Remove the :FOR[GTI] and it works just fine.
-
Yes it is:
@PART[*]:HAS[@MODULE[ModuleReactionWheel]] { @MODULE[ModuleReactionWheel] { @RESOURCE[ElectricCharge] { @rate *= 15 } } }The patch looks for all parts that use ModuleReactionWheel and applies the multiplication factor (15) to the rate. Have fun!
-
You need to apply the "Icon_Hidden" tag to the fairing-mesh(s). In unity select the mesh you want to hide in the preview. In the Inspector panel at the top is a field "Tag Untagged", expand it. If you haven't used this tag before it will propably not appear straight away (if it does, select it and you're done). Hit "Add Tag" and enter "Icon_Hidden" at one of the tags (you may have to add a new tag with the small + first). Afterwards select the mesh you want to hide again and make sure the Inspector says "Tag Icon_Hidden".
Here you can find a list of all tags and layers for KSP:
-
A simple ModuleManager patch to restore helmets in KV-X and MK 2 Command Pod:
@INTERNAL[KV?_IVA|MK2POD_IVA] { @MODULE[InternalSeat],* { @allowCrewHelmet = true } }If you don't want to use MM look into the Internal.cfgs (GameData\SquadExpansion\MakingHistory\Spaces\) and replace all "allowCrewHelmet = false" with "allowCrewHelmet = true".
-
It is possible but depends on the engine how to remove these effects. I've quickly wrote a small MM-patch that removes all visual/sound effects and damages to other parts as @steve_v suggested from the Mammoth Engine Cluster as an example:
@PART[Size3EngineCluster] { !EFFECTS{} // Removes all engine effects (flame, smoke, etc) @MODULE[ModuleEnginesFX] { @exhaustDamage = false // No damage to other parts } @MODULE[FXModuleAnimateThrottle] // This Module makes the heat-effects { @responseSpeed = 0 } !MODULE[ModuleSurfaceFX]{} // Removes Surface effects when engine is close to the surface }This patch won't work on some of the older engines like the LV-T45 because they use different configs for the effects.
-
When I wanted to download the MHE from KSPStore (direct download) I sadly noticed that there is no portable version for Windows.
1. Will there be a portable version for Windows in the future?
Since I use Linux and Windows, I also downloaded the linux package and it seems pretty much like a portable version. It contians an installer script but afaik it just checks the KSP version and extracts the (2nd) archive when version is valid.
2. Are the different versions really platform-dependant?
3. Do I have to expect the Kraken when extracting the contents of the GameData folder from the MHE-linux-package into the GameData folder of a Win x64 portable install?
-
- PatchManager
- PreciseNode
There are much more I wanna have but PatchManager is the most important one.
-
Propably I'm overthinking this but I can't stop thinking about it: So when I upload a screenshot of KSP to imgur, I accept imgurs ToS and thereby grant Imgur Inc. a non-exclusive, irrevokeable license to use that image. Am I able/allowed to grant an exclusive, irrevokeable license to use said image as required by TTIs ToS?
-
8 hours ago, kerbiloid said:
...
Please, is it possible to give a step--by-step sequence of this?
1. Given a Unity 5.4 project with a simple antenna part. As a static part it successfully gets exported and works.
2. In this part's GameObject we have two cubes (or at least just one for simplicity). Doesn't matter, imported or just created in Unity. But no animations, no FBX, etc.
3. Which steps should we click to make one cube to have two positions: "antenna retracted" / "antenna extended"? Without Blender, just Unity.
4. .. . and to correctly export it to mu file, so this would work in KSP.Step-by-step unity only sequence for 2 cubes with moving animation:
Creating an empty GameObject and the two cubes is self-explaining I think. Make sure GameObject is at 0,0,0 and has the parttools-component.
Select the GameObject (1) and hit "Add Component"(2). Under Miscellaneous click on "Animation"(3) (not AnimatoR!). This way the animation component
is located at the GameObject.Spoiler
Open the Animation window. Ctrl + 6 or Window/Animation.
Spoiler
Create a new Animation, in this case "TestAnimation".
Spoiler
In the top left (1) you can switch between different animations if you want to have multiple. Switch to curve-view (2) and hit "Add Property"(3). Navigate down to the transformation of the mesh you want to move and add "Position"(4).
Spoiler
Go to frame 60 (1) and change the value of the Y coordinate from 0 to 1 (2).
Spoiler
That's it. Close the animation window, export the model and all you need is a config:
PART { // General parameters name = TestAnim module = Part author = A // Asset parameters mesh = model.mu scale = 1 rescaleFactor = 1 // Node definitions - Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 2 // Editor parameters TechRequired = experimentalElectrics entryCost = 10 cost = 10 category = Utility subcategory = 0 title = TestAnim manufacturer = A description = // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,0,0 // Standard part parameters mass = 1.85 fuelCrossFeed = True bulkheadProfiles = size2, srf // Drag dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 // Damage and Temperature crashTolerance = 10 maxTemp = 1400 // Modules MODULE { name = ModuleAnimateGeneric animationName = TestAnimation actionAvailable = true actionGUIName = Toggle Cube startEventGUIName = Deploy Cube endEventGUIName = Retract Cube eventAvailableEditor = true eventAvailableEVA = true eventAvailableFlight = true evaDistance = 5 } // Resources }The only important lines inside the Module are name and animationName. I've used ModuleAnimateGeneric but ModuleAnimationGroup is also valid.
Notes: The hirarchy and names of GameObjects and meshes cannot be changed after you created the animation. There are ways around that but it's easier to make the animations as last step when everything else is already set up.
Hope this solves your problem
-
On 04/03/2018 at 11:46 AM, Warezcrawler said:
I will add resource def to the mod. I never noticed it missing since I had that in another personal mod of mine + I nearly always use CRP.
As for the harvester thing, I'm not sure why that happens. I will take a look at it, when I get access to it in my current game. Maybe I need another check for the state upon loading the scene.
Found it just because I wanted to make sure no other mod is causing the harvester thing
During my read through the thread I stumbled upon this from about a year ago:
Are any of the current modules you think are missing some functionality, which you would like to see them having in the future? Or are there something else that you think could be nice to add in? MultiMode RCS maybe?
I know it's very quick to ask for another feature already, but do you have plans for a MultiMode RCS Module?
-
1 hour ago, BlackMaverick said:
Ive been working on this cockpit, however the iva view is not aligned propely to the eva view in game, all the orgins of the objects are the same and when i imported into unity the allignement is correct, any help would be appreciated
Heres a picture : https://imgur.com/PER6qdA
Hm, without further information I don't know what went wrong but you can modify the position of the IVA manually in the internals.cfg:
INTERNAL { name = MyIVA MODEL { model = Path/to/model position = 0.0, -2.0, 0.0 } } -
1 hour ago, AntINFINAIt said:
Oh i just import it? I saw a vid on youtube . Is this wrong?
The model must be imported but before you export it to .mu file you need to configure it in unity.
1 hour ago, AntINFINAIt said:+ Did you like the model?
For a first part it looks pretty nice. My first part was a storage tank aka simple cylinder
1 hour ago, AntINFINAIt said:And Yes i used convex mesh colliders , and i put a fps controller to test it. It was going trough.
Never tested colliders in unity. Have you verified it in KSP?
-
32 minutes ago, AntINFINAIt said:
Hello guys! I need some help. So i've made a very good engine model . I exported all UV maps (working with blender) and i converted them to dds. I put the .mu model in a folder, the DDS images and a config. I copied the KS-25 Vector CFGs and i tweaked them with my gimbals , names , thrusts , engine mesh, and so on. But when i launched my clean install to check out, the name was showing Vector , nothing changed, and THE ENGINE WAS RENDERING WITHOUT TEXTURE in select menu, but the texture was correct once placed. I know that the dds img.s have to do with this, and i checked them to see if they were good. They were.
Am i doing something wrong in blender?
One more additional thing: is there something in unity like Auto-shaping collider? I tried with mesh collider , but it was not working. And the primitive colliders are awful.
Any advices on the problem with the rendering , cfgs, and Unity auto-shaping-collider?
Also, please rate my raw third ever engine model:
How do you set up your model in Unity? The thread is a bit old but it shows the material setup in unity:
Afaik the PartTools don't work with .dds files. I use .png for the unity setup and exchange them with .dds files at the end (KSP can load .png as well).
For the config your need a name (internal, must be uniqe) and a title (external, what you read ingame).
Mesh colliders must be convex (check the box) and may not exceed ~250 faces afaik. For non-convex shapes you need multiple colliders.
-
There is a way to use emptys / gameobjects directly as attachment nodes. Haven't used that myself but you can find some infos here:
The config nodes are pretty simple:
// Node definitions - Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0, 1.5, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -1.5, 0.0, 0.0, -1.0, 0.0, 2 node_attach = 0.0, 0.0, 1.3, 0.0, 0.0, 1.0Stack nodes need 7 values separated by comas. First three numbers are for the coordinate (unity axis, Y is up), the next three numbers define the directions of the node and the last number is for the size of the stack node. The direction of a node is very important and can be 1 or -1. For a node on top of your model the direction would be 1 on Y-axis, for a node below your model the direction would be -1 on y-axis (as shown in the example above). The size can be 0 (for 0.625 m diameter parts), 1 (for 1.25), 2 (for 2.5) or 3 (for 3.75).
Same goes for the attach nodes just without the need for a size.
I've opened your Motor001.blend and the highest vertex is ~2.63 and the lowest ~0.66 on the Z-axis (make sure you see global and not local coordinates in blender). So the following should be a good start:
node_stack_top = 0.0, 2.63, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, 0.66, 0.0, 0.0, -1.0, 0.0, 2Note that Blenders Z values are Unity/KSPs Y values.
-
Interstellar Fuel Switch has what you are looking for:
With examples in the OP & download
-
It seems like the ModuleAnimationGroup breaks landing gear when both are on the same part. I wanted to make a Landing Leg with integrated Resource Harvester but as soon as I add the ModuleAnimationGroup, the lang gear stops working. In the VAB it stays retracted no matter how often I hit "deploy" and when I launch the Vessel, the Landing Legs stay deployed and can't be retracted.
It doesn't matter if the part has multiple animations or not, a simple unconfigured Module is enough to break things. This example-patch breaks the stock medium landing leg:
@PART[landingLeg1]{ MODULE { name = ModuleAnimationGroup } }I've tried fully configured ModuleAnimationGroups with all animations on the same object (in unity) and also with animations on different objects, but nothing works.
ModuleAnimateGeneric doesn't break landing legs as far as I can tell.
So is this a bug or by design or am I missing something? Couldn't find any information on the topic.
-
I'm glad you wanna give it a try!
The recompiled version works with KSP 1.3.1 but requires CRP or a definition for Resource IntakAtm, othwerwise KSP won't start:
[LOG 11:30:48.557] PartLoader: Compiling Part 'Squad/Parts/Aero/airIntakeRadialXM-G50/airIntakeRadialXM-G50/airScoop' [ERR 11:30:48.558] [ShipTemplate]: No Resource definition found for RESOURCE [WRN 11:30:48.564] Could not create PartResource of type 'IntakeAtmThere seems to be a minor bug with the GTI MultiModeHarvester. The radial drill can extract ore without beeing deployed first.
Spoiler
Tested fresh KSP 1.3.1 install with GTI 2.4, CRP 0.8.0.0, ModuleManager 3.0.1 and 3.0.4 in a new game.
-
1 hour ago, Warezcrawler said:
Interesting Idea. I guess it could be done. However, you can achieve something close to this by simply defining a converter that does both of these tasks at the same time.
What is you thought on that?
From a design perspective, this would take some work. The current design i really very simple. It basically takes all resource converters and store them. Then it simply switches all of them off, except for the one selected. Your idea would mean, that a framework would have to be created, where all converters are tagged with their groups, and then having the switcher allow for one of each group at the same time.
As I said, possible, but is it worth the effort when a simple 80% alternative is available.
I look forward to you thoughts on the matter.
Think I have to elaborate my situation a bit more: The mod will focus around hybrid rockets that use Aluminium and Silicon in combination with Oxygen as propellant. Resources can be extracted from Regolith (Al+Si+O2), Spodumene (Al+Si+O2), Alumina (Al+O2) and Silicates (Si+O2).
One rocketmotor uses a slurry (Monopropellant) of Al/Si in LqdOxygen with different mixtures. For example Al/Oxygen slurry, Si/Oxygen slurry, Al/Si/Oxygen (50:50 Al:Si), and so on.
It requires a lot of converters to cover all possible solutions and that's only for one motor. This is why I split the converters into resource extraction and propellant production.Atm I use the converting part only for resource extraction. The propellant production converters are put in the storage tanks. It works but is a bit hacky and not intuitive. The search for a better solution lead me to the converter-groups idea (I'm also open for other/better ideas, was just the first that came to mind).
So to sum it, converter-groups would definitly be an improvement but only if it's not too much work
). The PreRelease is only available on GitHub: 
[WIP] Stock Tank Fuel Switcher - v0.0.1 alpha
in KSP1 Mod Development
Posted
What is STFS?
STFS is a mod that allows users to choose which switcher-mod they want to use on the stock LFO tanks. Furthermore users can configure the fuel-setups to their likings. The customization is done via PatchManager, no need to dive into the MM-patches.
What are the dependencies?
ModuleManager and PatchManager are hard-dependency and the mod will not work without them.
At least one Resource Switcher mod is also required. Currently InterstellarFuelSwitch (IFS), Firespitter (FS) and B9PartSwitch (B9PS) are supported.
Depending on the resource-setups you want to use, you may need CommunityResourcePack.
None of the dependencies are included in the download!
How to use it?
When you install STFS, it will do nothing (*1) unless you configure it. To do so:
1. start KSP, load a savegame and at the KSC open the PatchManager window. Navigate to STFS000priority and expand it. Now choose a mod to handle the fuel-switching. If no switcher is chosen, the mod is deactivated.
2. In the PatchManager window navigate to STFS100LFOtanks and expand it. Now choose the resources you want to have available on the stock tanks.
3. Apply the changes AND RESTART KSP!
Will it interfere with other mods patching stock LFO tanks?
STFS always plays nicely (hopefully) with other mods. By default the patching will take place at the end of MM load order (zzSTFS...). If fuel-switcher modules are detected, no further fuel-switcher modules will be applied. Even in aggressive mode, STFS will never add fuel-switchers to parts that already have a fuel-switcher module (not breaking stuff if other mods don't play nicely).
How does 'aggressive mode' work?
Aggressive mode adds a 'dummy' fuel-switcher in the :FIRST section of MM-patching and removes it right before STFS starts its usual patching. As long as your other mods also play nicely and don't apply additonal switcher modules, STFS can do its job.
How is STFS balanced?
That is the tricky part, which is mostly WIP currently:
- Each setup on a tank uses the same volume for resource-storage. The Resource-Storage-Volume (RSV) is calculated from the amount of stored LiquidFuel and Oxidizer on each tank.
- Cost of each stock LFO tank is reduced to its dry-cost (KSP default cost include resource-cost)
- Each setup uses the default tank-mass. The results are rather bad fuel-to-mass ratios on some setups. I'm open for suggestions!
No pics, no clicks?
Since there is not really anything to show, some screenshots of the PatchManager setups:
Currently supported fuel-setups:
Download:
The current release is very early development and I'm looking for testers! If you are interested let me know in this thread or via pm.
Download from GitHub (direct)
Limitations:
- Order of setups cannot be changed
- The setups are global for all savegames on the same installation of KSP
Notes:
(*1): The mod adds a useless key (stockLFO = true) to all stock tanks to make identification easier. The key will be removed at the end of MM-patching.
- The cost of stock LFO tanks is set to their dry-cost instead of the default wet-cost.
- The default RESOURCE nodes are removed.
Warranty:
The mod is VERY WIP, so no warranty if it breaks craft- or save-files. Make backups in time!
License:
CC-BY-SA 4.0 International
Changelog:
- 2018.04.22 - Initial release of 0.0.1 alpha
- support for IFS, FS and B9PS
- support for all stock LFO tanks
Thanks to
- @sarbian for ModuleManager
- @linuxgurugamer for PatchManager
- @FreeThinker for InterstellarFuelSwitch
- @blowfish for B9PartSwitch
- @Snjo & @RoverDude for Firespitter
- @RoverDude for CommunityResourcePack
- @NecroBones for FuelTanksPlus
- @534443 for the help with costs