Chris_C

I made a Pull Request on github, not only an ant build file, but I also got rid of a bunch of generics issues

I agree its probably nothing to do with physics ticks

Which doesn't happen exactly every 20ms if an underpowered system is being used....

Sorry mentioning a physics engine was probably a bad analogy for why calculations are interval dependent. I was discussing how mechJeb does its calculations NOT unity....

While my laptop isn't a slouch it certainly doesn't have a power house for a gpu... that said it can play KSP fairly well with very modest settings. Having taken a break from KSP (I know can you believe it...real life, sooo inconvenient sometimes!) The new update prompted a look see. MechJeb was behaving rather poorly, but obviously before posting some vague useless and time wasting "it doesn't work" issue on the tracker I though I should investigate further and gather as many clues as I could - see if I could find anything in logs etc... First port of call was reproducing the various issues on another machine, get it onto my desktop and it behaves like an absolute dream... It then dawned on me that most of the input to MechJeb probably happens at intervals ie once every frame probably, given the nature of the calculations - there will be very large differences in output in different input intervals are used... If you've ever played with physics libraries changing the number of iterations in solvers or the frame rate will usually have massive impact for similar reasons. This is no doubt obvious to the developers, however I posted here as its not obvious to less technical but avid KSP / MechJeb users. I do wonder how many "issues" on MechJebs tracker at at least partly if not wholly caused by systems running at low frame rates - I wonder if MechJeb shouldn't dump FPS to the logs every 5-10 seconds (maybe even have a debug mode you must use before having an issue accepted....yeah like people would use that....)

I cant remember where I read it but I was under the impression that the KSP dev's would try not to break mod during minor version updates ie 1.0.2 -> 1.0.3 shouldn't effect mods where 1.0.3 to say 1.1 probably would....

hmm isn't 1.0.x and 1.0.y supposed to be mod compatible ? 1.0.3 doesn't like current KAS/KIS

I've encountered this issue during a number of versions of KSP, usually fiddling and faffing I can get it to select, in my current save I'm in orbit around the Mun and cannot select Kerbin, if I zoom out far enough I can click the small selection sphere that's usually in the centre of the planets (at a normal zoom it's not visible), however as soon as I do this it says no target I can select other planets, but not Kerbin both 32 and 64 bit versions behave the same. here's a list of my GameData directory ModuleManager.ConfigCache ModuleManager.ConfigSHA FPSViewer.dll *TriggerTech *000_USITools *CommunityResourcePack *Firespitter ModuleManager.2.5.9.dll *Regolith *UmbraSpaceIndustries *MechJeb2 *dockingtube *Squad *NASAmission Has anyone else seen this or have any ideas about a solution?

Although I can pick up my model and place it on a ship and attach stuff to it, it doesn't highlight when the mouse is over it. I've tried making the collision mesh both slightly bigger and slightly smaller than the visual mesh without any difference (collisions do work with kerbals for example) I'm using blender and exporting as a dae anyone else seen this before any clues as to what I might be missing?

its already published in another mod, I have detailed above how you can separate the component from the mod (see above) should you not want all the complexity and 1001 other parts (its a great mod if you want all the extra complexity of resource management) but its a bit much if all you want is just the one component!

I'll do what ever I like on my own machine that's unpublished if you don't mind.... There is no code anyhow, just a config file where i changed a couple of paths ...... I'm more than able to read a licence file...

It does dock craft, and looks like it works with connected living space too..,,

anyhow although put off my the crazy complexity of MKS I did manage to break out flexotube to be a modlet of its own... here's what I did first I modified the .cfg file so it looked like this gameData/flexotube/flexotube.cfg PART { name = flexotube module = Part author = RoverDude rescaleFactor = 1 node_stack_bottom = 0.0, 0.25, 0.0, 0.0, 1.0, 0.0, 1 node_stack_top = 0.0, -0.25, 0.0, 0.0, 1.0, 0.0, 1 node_attach = 0,-.2,0,0,-1,0 MODEL { model = flexotube/parts/DockingPort } cost = 200 category = none subcategory = 0 title = MKS Kerbitrail(tm) flexotube manufacturer = Umbra Space Industries description = Expandable, Bendable, attachable tubes up to 50m long. Requires KAS. attachRules = 1,1,0,0,0 TechRequired = Unresearcheable entryCost = 50 mass = 0.05 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 12 maxTemp = 3200 fuelCrossFeed = True MODULE { name = KASModuleStrut nodeTransform = DOCKING type = TubeSize1 maxLenght = 200 maxAngle = 100 breakForce = 10 allowDock = true allowPumpFuel = true hasCollider = false tubeScale = 1.1 jointScale = 1.1 textureTiling = 1 tubeSrcType = Joined tubeTgtType = Joined evaStrutPos = (0.05, 0.059, -0.21) evaStrutRot = (190.0, 0.0, 0.0) tubeTexPath = flexotube/parts/FlexOTube } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.40, -0.3) evaPartDir = (0,0,-1) storable = true storedSize = 20 attachOnPart = true attachOnEva = true } MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true surfaceAttachmentsPassable = true passableDockingNodeTypes = top,bottom } } @PART[flexotube]:FOR[KolonyTools]:NEEDS[KAS] { TechRequired = advConstruction category = Utility } this is basically just altered paths the other files are unedited but the paths are different chris@localhost ~/.steam/steam/steamapps/common/Kerbal Space Program/GameData $ ls flexotube/ -R flexotube/: flexotube.cfg parts readme.txt flexotube/parts: DockingPort.mu TubeParts.png TubeParts_NORM_NRM.png FlexOTube.png TubeParts_GLOW.png so that saved a butt load of coding and pain! not the exact mechanic I had in mind but I use KAS quite extensively anyhow.....

Especially with bases on rough terrain, I've often thought it would make life so much easier to have a flexable docking tube. In some cases if modules are at different angles it can even be impossible to dock... try to imagine an old fashioned camera with a concertina lens body http://www.earlyphotography.co.uk/Images/C347.JPG here the Z axis is looking down the tube... the tube can change direction in a limited amount (say +/- 20 degrees) x & y axis and can go in and out along the z axis additionally the docking ring can rotate in a limited manner on 2 axis (x & y) This should give a vastly superior docking ability for bases I can handle simple modelling in blender and can code in a number of languages - however a very quick google failed to find and KSP API documentation? (I really don't go for intelli-guess programming) I've also managed to compile both MechJeb and KSP using a Makefile in Linux any guidance/help would be most welcome Does anyone have any thoughts about how useful or not this mod might be or suggestions for it?

Its a shame the licence is so restrictive... kinda tempting to reinvent the wheel under a permissive licence....