helaeon

@PunkRockZoologist Keep in mind too large part counts have a very large and fast detrimental effect due to the way we need to move all those parts through space to make the warp effect happen. Every frame a new position and velocity is applied to each part in the vessel. This is done on a vessel wide basis but, KSP is still doing all of that and calculating all that it usually does to keep that wad of parts together. I part clip pretty severely and have never really had huge problems, but they have happened. Radial connections of course are more dangerous than node connections. My part counts are nearly always under 300 or so if I have a lander docked individual ships are 150 or less (usually closer to 100). Keep in mind too I'm running an i7-8770k, 32gb DDR4 memory, and a nVidia 1080 so I can get away with more than a lot of people can.

@capi3101 I honestly don't remember where I set the minmax at. If it's in the file as .001c then that's what it is at. You may tune as you see fit. I probably left it exposed in the cfg for just this reason (and so could be altered by module manager as desired).

@capi3101 how severe of a braking effect are you expecting? That video was looking about right to me for Duna. Especially after the Laythe + Jool fix (apparently that combined gravity well is quite deep and you can't get out at all with the way I had it originally with much stronger braking). Now there is an absolute minimum max speed the warp drive will make you go. It's a floor on how severe the braking can get. I think it happens to be 0.0001c if I remember right. So yeah, looks like working as expected.

Physics Tick is in the settings. It's Max Physics Delta-Time per frame. Different versions of KSP have had different defaults here. Also people with heavily modded games have often made this number larger, which means the warp-drive's calculation update less often. Instead of your warp drive "flying" through space think of it that it's doing successive hops of a calculated distance and in that physics delta time, you're in a new location everything gets updated and another jump. To give you an idea of how this can be a big issue: at 1c in with a physics tick of .04 seconds (which may be the minimum one can set it to) your ship jumps 12,000 km. Kerbin has a diameter of 1200km.

@capi3101 What is your physics tick set at? The amount of distance being covered here, higher physics tick times can make big jumps in all the calculations happen due to the obscene distances being covered very quickly and I have most of the calculations happening exponentially or logarithmicly - due to the extremely large speeds and distances being considered. There isn't much I can do about this and it's been a problem since I first started tinkering with the laws governing warp in KSP. Are you trying to approach the planet at full throttle? Just like Elite Dangerous you're going to blow by (or through) and the brakes aren't going to work very well. Unlike E:D the warp drive is not an integral part of the game so the functions I'd probably need to keep everything nice and tidy aren't there, so... we get a much more finnicky and unpredictable warp drive. Also unlike E:D if you blow through the planet and are unlucky to be in it during the next physics tick you super explode not be placed at fail-safe altitude. Further, with most bodies other than Jool or Kerbol (I think), even with a physics tick of .04 you can blast by the entire failsafe altitude in one tick if at full throttle. You do know that our "lore" that's part of the deal with getting to use a warp drive... that it is a bit unpredictable and we'll call certain bugs features. Also FYI I'm playing a lot of Warframe so I'm unlikely to be doing much with KSP. I do check in once in a while to answer questions, but I won't be making any coding changes to this in the near future. Anyone is welcome to make adjustments though It is also possible something has happened between 1.3 and 1.6 that has broken how the brakes worked. I personally haven't ran a warp-drive ship since my last burst of coding to put the brakes in.

I haven't flown one since I made the changes to the braking code that made it not trap you at Laythe. Actually I'm on 1.6 right now and don't even have my own mod installed... yet. Duna has a small gravity well, and "physics ticks" are a major issue with anything warp drive related. Sometimes you just cover too much space per tick for the game to do much with your warp velocity. I did test the brakes with Dres and I do remember having to come in kinda slow to get the brakes to kick on (I may have had to turn some of the braking related settings up. It's been a while so I don't remember). It really is like the Frame Shift Drive in Elite:Dangerous, you come in too hot and there's not much the brakes can do for you.

I play this way exclusively with an xbox one controller and have been since version .24 or something like that. Bluetooth works but if it disconnects you can't get it to connect again without re-starting the game, so USB cable is the way. You'll need to figure out your own key mappings, and using a button as a mod/shift key doesn't work very well. I don't do any of the steam controller driver stuff, just map the axes and buttons directly through KSP. For VAB and most of the UI I'm using keyboard/mouse (mostly mouse). Flight is all controller and action groups (up on the keyboard)

@capi3101 Velocity vector direction doesn't change from your start. Velocity magnitude (speed) changes a lot. That's mostly due to my own limitations with the math and for simplicity's sake. You can't just do regular algebra on vectors, so I had to keep that direction constant. Then I can mess with the other parameters. Velocity magnitude changes in order to conserve angular momentum / orbital energy. As you move your ship around the gravity well, the resulting orbit(s) will have roughly the same energy as when you started. The total velocity conserving version gives you lots of free energy. Example I always use is that Jool has a lot more orbital energy than Kerbin (that's why it is further away), so when you get out to Jool from an orbit starting at Kerbin, you should be falling into Kerbol (what AM mode does), not trying to escape it (what velocity mode does). Turns out that warp drive in AM mode still makes you "pay" for your translation in DeltaV almost the same as your normal escape and capture burns if you went at the same time. You just pay for it all at the end (and you can do trickery with repeated slingshots to match orbits). You should also be able to drive out to Jool, turn around, return to your original location around Kerbin and have the same orbit. As a practical piloting manner one can't do that, but you can get close and it was one of the scenarios I tested against. One of the reasons for the new speed reductions in the gravity well were so you could drive your ship in warp more slowly so place it more precisely when you drop out of warp for more complex and precise maneuvers. Side Note: I learned recently that my intuition as to why I liked the Angular Momentum mode better and seemed more "right", is actually kinda based in work Emmy Noether did and how it relates to the mathematical symmetry gravitational field. Turns out the conserved quantity in conservation of energy in such a system like how we use our warp drives is in fact angular momentum. Which is probably why the math all fell out very nice and clean once I hit upon the correct equations.

Because they are almost exact opposites. By switching between the two modes you can cancel out the undesirable effects of the other mode. There should be a flag on the part in your save file that will let you switch it. I was using a quicksave so I could change it in the file, save the file, then reload. That's how I was testing between the two modes easily.

The USI warp drive works pretty well... I may have had a hand in making it though so filter that as you may.

Have you tried running timewarp? Sometimes when you come out of time warp, especially high warp, the game will re-do the altitude & position calculations. Another thing to do is attach landing legs then do the suborbital landed thing you did. I used to always have problems with bases without legs. Lately, less so, but around 1.2 and before I had to always have legs on the rigid parts.

I have noticed this as well. Can menu snipe and click the "open" button again from the right click dialog and it closes it, but yeah no close window. I think this one may be a bug in OSE workshop however.

You are basically talking about Nertea's Near Future pack of mods. Which is one of the community's top shelf mods and always has been. It's awesome. I would think Squad would be hesitant to go into this territory because this particular mod is so high quality. Kerbal Re-usability Expansion has the landing legs you want.

@capi3101When I made the 25x EC configs I was thinking about the fusion reactors from DSEV so didn't include WildBlue/Pathfinder as a whole. Pathfinder's SAFER reactor didn't exist then, neither did Flying Saucers, so right now WildBlue generally should probably trigger the higher numbers but I have no plans to push such a change.

If mods aren't a problem Coatl Aerospace has some great small probe parts. Including a bunch of small reaction wheels.

Yes, but I think it may not be too bad. The SEP station can be used as the cable origin, and the plugs can probably now be part of the destination part (see the new pylons with built in fuel-pipe ports). Which that's handy. What I don't know is if a single part can be the origin of multiple cables. @IgorZ?

I put a waypoint in the middle of the Rangeland with Waypoint Manager from Nightingale and use that instead of targeting the base.

KER + Trajectories. With trajectories you can predict your impact even through atmo when you make your de-orbit node, makes landing back at KSC super easy. It even has an - in flight marker to update your updated impact as you do burns or aerodynamically glide. KER's hud gives a moment by moment read out, think of it as your instrument cluster. The relevant ones here are altitude above terrain & time to impact. I tend to do propulsive landings now so time to suicide burn is good too. If you want to go to MechJeb, it has mostly the same readouts as KER but you have programs too... so you can turn the landing over to mechjeb once your re-entry is complete and do a spaceX style precision landing on the runway! (Not rough to do manually but the computer uses nearly minimum deltaV. I'm a pretty good pilot and I don't think I can beat the computer on hitting that suicide burn that exact).

Alright here is the fix. Stage1.cfg reads like this PART { name = MD-Stage1 module = Part author = bcink MODEL { model = MarsDirect/Stage1/MD-Stage1 } rescaleFactor = 1.0 node_stack_top = 0.0, 1.29, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -1.73, 0.0, 0.0, -1.0, 0.0, 2 node_stack_engine1 = 0.0, -1.47, -0.93, 0.0, -1.0, 0.0, 1 node_stack_engine2 = 0.0, -1.47, 0.93, 0.0, -1.0, 0.0, 1 node_stack_engine3 = 0.93, -1.47, 0.0, 0.0, -1.0, 0.0, 1 node_stack_engine4 = -0.93, -1.47, 0.0, 0.0, -1.0, 0.0, 1 node_stack_legs1 = -1.08, -0.34, 1.07, -0.5, 0.0, 0.5, 1 node_stack_legs2 = -1.08, -0.34, -1.07, -0.5, 0.0, -0.5, 1 node_stack_legs3 = 1.08, -0.34, -1.07, 0.5, 0, -0.5, 1 node_stack_legs4 = 1.08, -0.34, 1.07, 0.5, 0, 0.5, 1 node_attach = 0.0, 2.48, 0.0, 0.0, 1.0, 0.0 node_stack_laddernode = -0.86737, 0.01652, -1.52199, -0.29, 0.0, -0.55, 1 NODE { name = bay1 transform = Empty_001 // GameObject size = 1 method = FIXED_JOINT } NODE { name = bay2 transform = Empty_002 // GameObject size = 1 method = FIXED_JOINT } NODE { name = bay3 transform = Empty_003 // GameObject size = 1 method = FIXED_JOINT } CoMOffset = 0.0, -1.0, 0.0 stackSymmetry = 3 TechRequired = experimentalAerodynamics entryCost = 12000 cost = 4000 category = FuelTank subcategory = 0 title = Baker 1st Stage manufacturer = Direct description = Duna Direct's Baker first stage with cargo / rover bay and ramp, bay light and exterior spotlights. attachRules = 1,1,1,1,0 mass = 7 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 1 crashTolerance = 50 maxTemp = 2900 emissiveConstant = 0.87 fuelCrossFeed = True bulkheadProfiles = srf, mk3 breakingForce = 300 breakingTorque = 300 tags = Duna Baker Mars Direct Stage1 fx_gasBurst_white = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, decouple sound_decoupler_fire = decouple MODULE { name = ModuleAnimateGeneric animationName = Deploy startEventGUIName = Open Bay Door endEventGUIName = Close Bay Door actionGUIName = Toggle transform allowDeployLimit = true revClampDirection = false revClampSpeed = true revClampPercent = true instantAnimInEditor = false } MODULE { name = ModuleDecouple ejectionForce = 20 isOmniDecoupler = false explosiveNodeID = top } MODULE { name = ModuleToggleCrossfeed crossfeedStatus = false toggleEditor = true toggleFlight = true } MODULE { name = ModuleReactionWheel PitchTorque = 20 YawTorque = 20 RollTorque = 20 RESOURCE { name = ElectricCharge rate = 1.2 } } MODULE { name = ModuleLight lightName = spotlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 resourceAmount = 0.04 animationName = LightAnimation useResources = true } MODULE { name = ModuleLight lightName = spotlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 resourceAmount = 0.04 animationName = LightAnimation2 useResources = true } MODULE { name = ModuleLight lightName = spotlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 resourceAmount = 0.04 animationName = LightAnimation3 useResources = true } MODULE { name = ModuleColorChanger shaderProperty = _EmissiveColor animRate = 0.8 animState = false useRate = true toggleInEditor = true toggleInFlight = true toggleInFlight = true unfocusedRange = 5 toggleName = #autoLOC_502011 //#autoLOC_502011 = Toggle Lights eventOnName = #autoLOC_502012 //#autoLOC_502012 = Lights On eventOffName = #autoLOC_502013 //#autoLOC_502013 = Lights Off toggleAction = True defaultActionGroup = Light redCurve { key = 0 0 0 3 key = 1 1 0 0 } greenCurve { key = 0 0 0 1 key = 1 1 1 0 } blueCurve { key = 0 0 0 0 key = 1 0.7 1.5 0 } alphaCurve { key = 0 1 } } MODULE { name = FlagDecal textureQuadName = flagtransform } MODULE { name = FlagDecal textureQuadName = flagtransform2 } } MD-ISRU-CommunityResourcePack.cfg reads like this // Mars Direct ISRU Patch. Required community Resource Pack, compatibility with cryotanks. // Special thanks to dvdwilliams88 and helaeon for this patch! @PART[MD-Stage1]:NEEDS[!CommunityResourcePack,!CryoTanks] { RESOURCE { name = LiquidFuel amount = 775 maxAmount = 775 } RESOURCE { name = Oxidizer amount = 1210 maxAmount = 1210 } RESOURCE { name = MonoPropellant amount = 200 maxAmount = 200 } RESOURCE { name = ElectricCharge amount = 200 maxAmount = 200 } } @PART[MD-Stage1]:NEEDS[CommunityResourcePack,!CryoTanks] { MODULE { // ---specific module parameters --- name = ModuleResourceConverter ConverterName = Sabatier StartActionName = Start ISRU [Sabatier] StopActionName = Stop ISRU [Sabatier] AutoShutdown = false GeneratesHeat = false UseSpecialistBonus = true SpecialistEfficiencyFactor = 0.2 SpecialistBonusBase = 0.05 Speciality = Engineer EfficiencyBonus = 1 INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 0.1 } INPUT_RESOURCE { ResourceName = LqdHydrogen Ratio = 0.001 FlowMode = STAGE_PRIORITY_FLOW } INPUT_RESOURCE { ResourceName = CarbonDioxide Ratio = 0.019 } OUTPUT_RESOURCE { ResourceName = LiquidFuel Ratio = 0.009 FlowMode = STAGE_PRIORITY_FLOW } OUTPUT_RESOURCE { ResourceName = Oxidizer Ratio = 0.011 FlowMode = STAGE_PRIORITY_FLOW } } MODULE { name = ModuleResourceIntake resourceName = CarbonDioxide checkForOxygen = false area = 0.0085 intakeSpeed = 10 intakeTransformName = Intake } RESOURCE { name = CarbonDioxide amount = 0.85 maxAmount = 0.85 } RESOURCE { name = LqdHydrogen amount = 100 maxAmount = 100 } RESOURCE { name = LiquidFuel amount = 775 maxAmount = 775 } RESOURCE { name = Oxidizer amount = 1210 maxAmount = 1210 } RESOURCE { name = MonoPropellant amount = 200 maxAmount = 200 } RESOURCE { name = ElectricCharge amount = 200 maxAmount = 200 } } @PART[MD-Stage1]:NEEDS[CommunityResourcePack]:AFTER[zzz_Cryotanks] { MODULE { // ---specific module parameters --- name = ModuleResourceConverter ConverterName = Sabatier StartActionName = Start ISRU [Sabatier] StopActionName = Stop ISRU [Sabatier] AutoShutdown = false GeneratesHeat = false UseSpecialistBonus = true SpecialistEfficiencyFactor = 0.2 SpecialistBonusBase = 0.05 Speciality = Engineer EfficiencyBonus = 1 INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 0.1 } INPUT_RESOURCE { ResourceName = LqdHydrogen Ratio = 0.001 FlowMode = STAGE_PRIORITY_FLOW } INPUT_RESOURCE { ResourceName = CarbonDioxide Ratio = 0.019 } OUTPUT_RESOURCE { ResourceName = LiquidFuel Ratio = 0.009 FlowMode = STAGE_PRIORITY_FLOW } OUTPUT_RESOURCE { ResourceName = Oxidizer Ratio = 0.011 FlowMode = STAGE_PRIORITY_FLOW } } MODULE { name = ModuleResourceIntake resourceName = CarbonDioxide checkForOxygen = false area = 0.0085 intakeSpeed = 10 intakeTransformName = Intake } RESOURCE { name = CarbonDioxide amount = 0.85 maxAmount = 0.85 } RESOURCE { name = LqdHydrogen amount = 100 maxAmount = 100 } RESOURCE { name = LiquidFuel amount = 775 maxAmount = 775 } RESOURCE { name = Oxidizer amount = 1210 maxAmount = 1210 } RESOURCE { name = MonoPropellant amount = 200 maxAmount = 200 } RESOURCE { name = ElectricCharge amount = 200 maxAmount = 200 } } I am thinking I might make an addition to the ISRU patch to make this play with Pathfinder/WildBlue. If I do (and no promises) I will post it here. The above I'm only considering fixing breaking what CryoTanks does with it's B9 patch. I run a decent mod load so its compatible with quite a few, but I don't have a way to test or consider things like RealFuels, InterstellarFuelSwitch, etc.

Disabling ISRU is actually easier. (that's what I did for my own interim until I can make a real fix - I can post that when I get back to my KSP computer just for now). I do kind of agree with MaverickSawyer that those of us running CryoTanks probably are running other mods that give more ISRU options so wasn't a big deal if it wasn't available for us. I tried the obvious ways last night to disable tank switching and ended up with the tanks I tried to protect from B9 being deleted. I have a couple more ideas I'll try those too as that is your wish.

I know exactly what is going on now and the change is really easy so question is how would ya'll ( @bcink being primary) like me to fix it? In the case that CryoTanks is present: 1) Disable ISRU entirely? 2) Disable fuel switching entirely so the ISRU can work as designed? There is a much harder 3rd option that involves setting up lots of ISRU options and figuring out balancing and such, so no. Once I know that I will alter the relevant file and post it here for bcink to integrate into the next release.

How about this: We're using module manager as a requirement for the mod anyway so let's write the config that way. Do the resources with a :NEEDS[!CryoTanks]. Then another block for :NEEDS[CryoTanks] that will be set-up as it should be for that use case. Then the resources aren't exposed for the cryotanks patch to mess with AND you get to explicitly describe the resource load in each case. You should be able to do that right in the part's cfg. I may not have any KSP time tonight, but unless someone beats me to it I can try to get this to work.

Something for the next patch. MM_Drills.cfg should read @PART[RadialDrill,MiniDrill] { !MODULE[ModuleOverheatDisplay]{} !MODULE[ModuleCoreHeat]{} @MODULE[ModuleResourceHarvester] { @name = WBIGoldStrikeDrill @GeneratesHeat = false !TemperatureModifier{} !ThermalEfficiency{} } @MODULE[ModuleAstroidDrill] { @Name = WBIGoldStrikeAsteroidDrill @GeneratesHeat = false !TemperatureModifier{} !ThermalEfficiency{} } MODULE { name = WBIEfficiencyMonitor efficiencyType = extractionModifier efficiencyGUIName = Extraction Rate } MODULE:NEEDS[BARIS] { name = ModuleQualityControl quality = 100 mtbf = 400 } } I saw the patch notes so removed my MM patch that handled the thermal modules... and had slow drills. Just tested the above and it works as intended. Otherwise 1.5 update looks good to me so far! Looking forward to seeing what you do with the new KIS/KAS.

I took a quick look tried shuffling the .cfg around a bit, and spied the log. Seems to be a problem with simpleboiloff (Cryotanks) + B9. After figuring that out I was stumped. To me it looks like it should be fine and I'm not quite sure where the stack of null-refs is coming from or how to resolve them. @blowfish? @Nertea? here's the part of KSP.log where I drop in stage 1 to stage 2 in the VAB [LOG 00:53:25.213] MD-Stage2 [LOG 00:53:25.216] [MechJeb2] Loading Mechjeb Dev #814 Sarbian [LOG 00:53:25.279] [Part MD-Stage2] [ModuleB9PartSwitch 'fuelSwitch'] Switched subtype to LF/O [LOG 00:53:25.319] ScaleModList: listSize 328 maxListSize 1403 [LOG 00:53:25.815] MD-Stage1 [ERR 00:53:25.817] Module ModuleCryoTank threw during OnStart: System.InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at SimpleBoiloff.ModuleCryoTank.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 [LOG 00:53:25.817] MD-Stage1 [ERR 00:53:25.818] Module ModuleCryoTank threw during OnStart: System.InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at SimpleBoiloff.ModuleCryoTank.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 [WRN 00:53:25.826] DontDestroyOnLoad only work for root GameObjects or components on root GameObjects. [EXC 00:53:25.828] Exception: Conflict found between ModuleB9PartSwitch (moduleID='fuelSwitch') on part MD-Stage1 and ModuleB9PartSwitch (moduleID='fuelSwitch') on part MD-Stage1: Two modules cannot manage the same resource: Oxidizer Two modules cannot manage the same resource: LqdHydrogen Two modules cannot manage the same resource: Oxidizer Two modules cannot manage the same resource: LqdHydrogen Two modules cannot manage the same resource: Oxidizer B9PartSwitch.ModuleB9PartSwitch.CheckOtherSwitchers () B9PartSwitch.ModuleB9PartSwitch.Start () [WRN 00:53:25.830] DontDestroyOnLoad only work for root GameObjects or components on root GameObjects. [EXC 00:53:25.830] Exception: Conflict found between ModuleB9PartSwitch (moduleID='fuelSwitch') on part MD-Stage1 and ModuleB9PartSwitch (moduleID='fuelSwitch') on part MD-Stage1: Two modules cannot manage the same resource: LqdHydrogen Two modules cannot manage the same resource: Oxidizer Two modules cannot manage the same resource: LqdHydrogen Two modules cannot manage the same resource: Oxidizer B9PartSwitch.ModuleB9PartSwitch.CheckOtherSwitchers () B9PartSwitch.ModuleB9PartSwitch.Start () [EXC 00:53:25.869] NullReferenceException: Object reference not set to an instance of an object SimpleBoiloff.ModuleCryoTank.Update () [EXC 00:53:25.869] NullReferenceException: Object reference not set to an instance of an object SimpleBoiloff.ModuleCryoTank.Update () [EXC 00:53:25.880] NullReferenceException: Object reference not set to an instance of an object SimpleBoiloff.ModuleCryoTank.Update () [EXC 00:53:25.880] NullReferenceException: Object reference not set to an instance of an object SimpleBoiloff.ModuleCryoTank.Update () It's easy to reproduce if the full log or another log is needed.

I think... from what I've seen fiddling with new KAS in-game there is probably one semi-simple way to set up the mineshaft without a special addition to KIS/KAS for pathfinder: 2 part solution (really one existing and one new). One half of the mine-shaft is the side with the tube this would be set up similarly to "RTS-1 Resource Transfer Station" using the KAS Cable and KAS Joint Source modules. You make a special joint source something like "MS-125". The other shaft is a receiving port similar to "JS-1 Joint Socket" but configured for the MS-125 cable type, this would be the existing part. Ideally these would connect by default in docked mode, not sure if that is possible though. Though not the end of the world if that has to be done manually. I'm not sure how new KAS handles multiple connection points as there are no example parts that operate that way. I think from reading IgorZ's response to you on the KAS thread you'd also need to make a special mesh for the connection "cable". Want me to try and make some part .cfgs that do the above using existing meshes and see if it works?