DMagic

Version 0.4 of Flexible Docking is out; try it from GitHub. It adds the 2.5m flexible docking port that matches the stock Clampo Tron Sr. It also uses the Sr and standard stock texture assets, so make sure you don't delete those. It adds a better fix for the non-dominant docking problem. This allows for the docking ports to engage from a longer distance. I also added in the srf attach bulkhead profiles and search tags. If nothing else needs fixing I'll work on finalizing the part configs (I'm thinking I'll put each in the tech node position directly after their standard counterpart), and cleaning up some of the texture maps on the parts. The final release should be out relatively soon.

What @kcs123 says is the idea, though none of that would actually happen, you just have to pretend that it would happen if you were to extend it during flight. As for the Ore scanning altitude, it isn't meant to scan Kerbin (I'm not sure why anyone would really want to scan Kerbin for Ore anyway). It is intentionally crippled as a resource scanner since it comes so much earlier than the Narrow-Band scanner (which also has other useful functions).

@Deimos Rast An oversized strut is another method for making flexible docking ports. It works using KAS, but obviously requires a Kerbal to move it around. An automated version of that would also be possible, but I don't really like the way that looks, it's just a single straight component. I also like having fairly strict limits on how much the port can move. Thanks for the config file parameters. The current versions are more or less place holders, so I'll add all of that information, along with proper names, manufacturer, tech tree positions, cost, and descriptions. Does CLS set the Jr as passable? It seems like it should be too small to allow a Kerbal. Extending the ports in the editor might not work. I would need to either move or disable the top attachment node, and I'm not sure how well that will work. Using EC while the port is acquiring in the extended mode can be added.

@Mapoko I'll need to see log files to figure out what's wrong.

Version 0.3 of Flexible Docking is out now; get it on GitHub. The name of the folder has been corrected and parts should load properly. Make sure to completely delete any existing FlexoTube and/or FlexoTubes folders.

@Maverick_aus The BTDT is only used for scanning anomalies up close. The Multi Spectral Scanner can identify their position from orbit, and the BTDT can give you more info about them, see the KSPedia entry for an example. I don't know of anything that keeps track of your path on a map. It sounds like an interesting idea, though it might be complicated to actually implement.

A new version of the flexible docking ports is available on GitHub. This adds a Flexible Clampotron Jr part, this also uses stock textures. The folder structure has changed, so you'll need to fully delete all existing files. This fixes some issues with the attachment nodes (which should prevent FAR from detonating vessels with these parts), fixes a problem when docking two flexible ports together, and fixes some startup errors. It also fixes a problem that was preventing the flexible ports from working when not the dominant port. This can happen for several reasons; different vessel types, or different vessel masses, it doesn't have anything to do with which vessel is active. Let me know if any new problems are found, or if any of the existing problems still exist.

@THX1138 Surface attachment is one of the things that is yet to be added; the config file is mostly just place holder info for now. As for lining things up, I would follow the same general guidelines that have always been used (try to use a standard height of some kind, test things out, etc...), it's just that the docking ports no longer need to be absolutely perfect when using the flexible ports. It looks like the FAR problems might also be related to the unfinished attachment nodes and attachment rules. The plugin itself doesn't seem to have any problem with FAR, just the part.

@ii_DyNaMiCs_ii I'm not quite sure how, but it seems like you have two copies of the DMagic plugin somewhere. I'm seeing duplicates of some of the log entries for DMOS. The root cause of the specific problem you are having is Squad's carelessness, they aren't checking for duplicate entries in a dictionary that is used for the contract weighting system. The only way that I can think of for that to be a problem is if two copies of the same assembly get loaded. The only problem is that I don't see any mention of a second assembly being loaded in the log files. Check your GameData folder (and maybe look in those other folders in the root KSP folder; Kerbal Space Program/Plugins, etc...) @Zero_Out Version 0.3.3 and 0.3.2 of what? This mod is on version 1.3.2.

SCANsat version 16.3 is out; get it on Space Dock. It is updated for MechJeb 2.5.8 and adds support for several KSP Interstellar Extended resources (a minor KSPI update will be required for full compatibility). It also removed the unused resources Thorium and He-3.

Version 1.3.2 is out; get it on Space Dock. It fixes a critical bug in the recon contract generator.

@genericeventhandler Do you have pictures of the situation you are describing? Are you trying to use multiple ports right next to each other on the same vessel? Also, did you try disabling the magnets?

@biohazard15 Yep, that's definitely a problem. I'm not really sure how that bug snuck in there. I'll try to get an update out soon. In the mean time you can either use Contract Configurator to disable the dmReconContract type, or edit the max allowed Recon contracts in the dmContracts.cfg file in the DMagicOrbitalScience/Resources folder to 0 (set maxOffers and maxActive to 0 in the DMRecon section).

I'll need actual log files, not excerpts.

Correct, as long as the stock docking port texture is still there it will work fine. If it has been removed with a part pruner then it won't work.

@ultraviolet150 Is the docking port extended when this happens? Or is it docked to something in extended mode? I can see why either would cause problems, as it is has a constantly moving animation. I can see about making sure the animation stops when it doesn't need to be active.

I don't think stock parts have ever changed names (these are the internal names that I'm talking about, usually listed at the top of each part's config file, not what you see listed in-game). When you load a save with a part that doesn't exist anymore a little window will pop up in the Space Center scene telling you which parts are missing and what vessel they are on. If this happens you can always quit KSP right away (not through the exit menu, use Alt+F4, or Force Quit or whatever) and the game won't be saved, so you can try to rescue it.

@THX1138 Well, in all likelihood nothing will change so it won't be an issue. The worst case is that the part name is changed, which would cause all active vessels with the part to be destroyed, but there is no reason to change the part name. The only thing that I can think of actually happening is that a change in the current part model causes vessels that are already docked together with this docking port to have problems, maybe being shifted up or down a little. I don't foresee any major problems with the current part. Any changes are most likely to be in the part module code. The full release will have the versions of the 0.65m and 2.5m docking ports along with the current 1.25m part. Future versions may have additional variants, like shielded ports, a fairing-type nose cone port, and maybe a few others.

@akardam That's easy, just check in the contract settings file: GameData/DMagicOrbitalScience/Resource/DMContracts.cfg There are settings for each contract type, check under the DMMag section for the lines Magnetometer_Parts and RPWS_Parts. You can either add the desired part names to the ends of those lines (with each additional part separated by a comma), or make a MM patch to do the same, though I'm not sure exactly what the syntax is for adding something to the end of a line. The same is possible for the recon contracts. I should also tell @akron about that so that a MM patch can be included in Probes Plus.

@genericeventhandler It should work find for either. It was compiled for 1.1.3, but nothing really changed related to how this works. It uses the stock docking port module for the actual docking business, the code for my part is mostly just basic Unity stuff and lots of math to position the docking port head correctly.

Is this intended to be a part that people would use repeatedly on the same vessel, or just once? Unless someone is putting a dozen or so of them, 3500 polygons is not a lot. Some of the big fuel tanks are around 2k polygons, and the dish antenna is almost 6k, so I wouldn't spend too much time focused on getting the polygon count below an arbitrary number.

Like this: It's basically a regular docking port that can be extended to allow for a limited amount of translation and rotation (half of the node size, so 0.625m translation for the 1.25m docking port, and 10o), it works pretty well in my testing. If you want to test it out check here: This release is strictly for testing and only includes the 1.25m port, which pairs with the standard Clampotron (it should also work with the shielded and in-line versions). It uses the stock texture, so you can't move or replace that. If you're wondering why something like this hasn't been done before (ie, not an oversized KAS strut), it's because it is devilishly complex to get any kind of freely moving component like this to work in Unity. Making a working mock up in a 3D modeling program can be done in 15 min, but Unity doesn't understand some of the modeling constraints, so you are left with much messier options.

EVA Struts 2.0 is out; get it on Space Dock. It fixes an error that prevented struts from detaching upon decoupling or undocking without first reloading the vessel. This version should also work fine on KSP 1.1.2. Also, EVA Resource Transfer and Celestial Body Science Editor were both marked as compatible with 1.1.3. Also, I have a new modlet that I would like people to test out for me. A flexible docking port: As you can see it is designed to look like the stock clampotron and shares its texture. The docking port has two modes; when retracted it behaves like a normal port, but when extended it allows for a limited range of translation and rotation of the docking port head. There are controls for extending and retracting the port, and for deactivating the magnets (this works for both modes, and should work when this is not the dominant port). It is meant for facilitating base construction or other types of ground docking, but it also works in space. You might want to disable the magnets in space though, at least for lighter vessels, as they tend to get tossed around faster than the docking port can move. Also note that when two flexible ports are brought together only one will be active, when both are active they tend to chase each other around and you get odd results. For now I'm only releasing a version for testing. It has a single port, the 1.25m part that pairs with a standard clampotron. The stock 1.25m docking port is required (in case anyone has deleted or replaced it) as they share the same texture. The part is in the start node of the tech tree and it is very cheap. All aspects of the part are subject to change in future releases, so don't use this for anything you aren't willing to lose. Download it from GitHub and let me know how it works: https://github.com/DMagic1/KSP_Flexible_Docking/releases/tag/v0.1 It is release under the MIT license, and the stock docking port model was only used for reference, everything here was made from scratch.

These should all be working in 1.1.3. The only one I've tested and marked as compatible on Space Dock is Portrait Stats. I'll try to test the others out soon, in the mean time, let me know if anything isn't working correctly.

@Sigma88 There is no need to scale the default and range above/below numbers. The only thing that is likely to need to be scaled is the min and max height, the new multipliers were introduced specifically to avoid directly altering those. All that needs to be changed in an MM config are those multipliers.