diomedea

Truly happy to find this mod. I always thought KSP too easy because of KSC placement at almost 0° latitude. And, happy to see you made the license known with the first post .

Truly impressive those new features, but that one to allow some form of identification of the aimed port is a must-have for me. I would like a way to name single parts (so to assign specific names to docking ports and be able to know what I am targetting), but having a visual aid on the selected port is possibly even better. It would save me the hassle of placing beacon lights close to the ports, and switch them on for the selected port to see which one I have to dock with (plus, I still have to target that port). Though, if there could be an interaction with the targeted port, so to simulate that having a lighting device attached, it could be even better IMHO.

Non me ne sono dimenticato. E' un argomento che continuo a tirare fuori col Kommunity Manager, gli ho scritto in proposito anche due giorni fa. Spero presto, mi sto stancando anch'io di aspettare... (certo, ci sono stati alcuni problemini di recente e l'admin si è dedicato a quelli...)

Given the interest with bigger asteroids, there's a trick allowing anybody to experiment what it would be like to redirect a really huge one. What is important is not the size or class, but the mass. It appears that mass is given only after an asteroid is grappled (mass with any discovered asteroid is = 150). So, after having grappled one, save the game and exit. Edit the savegame, find your ship grappling the roid, look for a PART { } data with name =PotatoRoid, find "mass = xx" and change it to a value of your liking (in tons). Can't tell what is the upper limit for a class E (the biggest) but probably anything greater than 10,000 tons would deserve being a class F. By comparison, the greatest recorded asteroid event on Earth was at Tunguska, 1908; NASA estimates give a mass of 100,000 tons. Can't say if anybody can successfully redirect one asteroid of that size in KSP....

It seems you perceive your security based on what you can see. Unfortunately things work very differently (security on internet is a tragedy because on such misperceptions). Any time you connect to a service on Internet, you give away you IP address. It's unavoidable, because of the way IP works. You can't get anything back, if the remote server can't know where to send it. Skype is no exception, but it won't (directly) give away your IP, it acts as a middleman allowing P2P communications: it gives your IP to anyone able to see your contact address. (don't believe me: believe any of the many who found out, just google Skype + IP address). If you are concerned about not giving the IP address away, there is a possibility: use an anonymizer. You then can't connect to any service requiring registration (e.g., no forum access, and no Skype either), 'cause those check against your IP address that you're that user when logging. But (*surprise*) you will be able to connect and use IRC, because you don't need to log, you just provide an username of your choice.

Must say I am failing to see the need to create yet another chat about KSP. In case it wasn't known, there already is a IRC channel (#KSPOfficial) on Esper.net, everybody can connect using the IRC Chat button on the top line of this website. Plus, there's plenty of people using that channel (including very knowledgeable ones), so you'll never feel lonely; you don't reveal any private info about yourself to join; you don't have to keep another application open to chat while also visiting the forum.

About mods using the Toolbar, you'll find an extensive list of them with the OP of the Toolbar thread (courtesy of blizzy to have already listed them).

What, you say to be sorry for willing to provide us all with a better mod? Wish everybody was sorry, then . You already have the concept about how to make this better, and in a most sensible way (IMHO). 0.24 won't take too long, so I would say you don't have to rush for 0.23.5 compatibility.

Confirm it worked when doing the autoupdate in the correct way (still can't say what I did wrong before). Anyway, found another way to create trouble. Did not check and opened a second instance of KSP MA. It seems each instance loads and keeps info in its own memory. Made updates and closed one instance, then closed the other not updated one. Reopened, and KSP MA loaded the info as if it wasn't updated (but more probably, the updated files were overwritten when the latest instance was closed).

Hi, as a massive user of mods myself, I have exactly the same problem. To manage, I started creating a spreadsheet with all info about current and installed mod versions, compatibility with my (multiple) installed versions of KSP, and a lot of other useful stuff. Then, I found this tool: KSP Mod Admin, it allows to keep all the needed data together and automate most of the required operations (install, removal, compare, and with the latest version 1.4.0 PR5 also update of mods). I use it even for mods that I just want to keep track of, and not install. And it works for any number of KSP installs. No more use for my spreadsheet.

I believe your problems starts with the "kind of close" rendezvous. Getting within a few Km leaves enough distance for the orbits of the two crafts to be different enough, and orbital mechanics then bring to increase distance again. I would start with a good rendezvous. First, making sure the two orbits are in the same plane (inclination difference = 0), then changing altitude of the peri/apoapsis of the maneuvering ship so to match the altitude of the other ship at the same location, and in the end finely changing the other apside altitude so to achieve the closest possible distance at intercept. It is quite possible (without any help from mods) to achieve minimum intercept distance of 200-300 metres. When approaching the intercept point, I prepare to match speed with the target, therefore orient the ship towards the relative speed minus marker (Navball set on Target mode). It may help to set a node at the intercept point so to burn in the direction needed to have the two orbits match, so the blue marker of the node is giving the correct orientation and Delta-V required much sooner than the relative speed marker. At the intercept point, cancel almost entirely the speed difference (burn towards the relative speed marker until the relative speed goes close to 0). Once stable in the same orbit (relative speed 0), point towards the target and close at a slow speed. Once close enough (around 200 mt.) you can target the docking port, and then you need to bring your ship on the axis coming out of that port. The target ship must not rotate. There are different styles for approaching the axis to the docking port, one is to rotate your ship parallel to the axis and use only traslation to move towards the axis, another is to move the ship to a point along that axis, stop it there and then rotate it towards the docking port. In both cases, you should now be at some distance from the docking port, aligned with its axis and pointing the port. The navball (in Target mode) provides relative speed markers and you need to bring them aligned with the purple marker (target), translation mode is essential now. Close slowly, keeping relative speed aligned with the target (while your ship must remain on the axis). Apply retroburn just enough to have a very slow speed at contact (0.1 - 0.2 mt/s). EDIT: it is useful to me to change the camera to "chase" mode and align it with the ship, while docking. That way, the translation keys (I-K-J-L) match the orientation of the ship.

Welcome aboard! Yes, better to have a look at the Gameplay Questions and Tutorials section about how to dock. Lots of tutorials there could be of help, and in case that's where your post for more help should go and receive best answers.

Hi, welcome aboard. Always a good time to become active on the forum .

Thanks for your support. About 1., that's right. I have it with MechJeb on KSP 23.5, that I first installed in version 2.1.1-198 and then manually updated to version 2.2; it has AddDate="03/04/2014 13.30.54" and CreationDate="06/04/2014 00.00.00", but sure AddDate was about the first version while CreationDate is about the second. Same is with RCS Sound, installed version 3.4 and now updated to version 4.0: AddDate="02/04/2014 23.10.27", CreationDate="04/04/2014 00.00.00". So I believe I have to update the AddDate too, when I manually update a mod. Easy, thanks for pointing the correct way to handle that. About 2., I had it happen with Mission Controller Extended version 0.61 (updating from version 0.60.1). But I have better run more tests with this new auto-update feature, before pointing any issue to a specific mod (easily I may have done a mistake). I was expecting KSP MA to automatically install files from the new version over the old one, once finished downloading; however it remained in the mod browser, so I returned to the mods tab and did a manual install. KSP MA actually adds the new version to the mod list, but there is no evidence its files are processed, while no change seems happening to the already installed (outdated) version, that remains in the mod list as well. Please note that I use to rename mods in the mod list (I move version info out of the name string), so that may also have influence on the automatic update.

The newest version 1.4.0 PR5 seems to be working outstandingly for me (really good the new features about modinfo and the forum link ), but for a few minor issues, some probably due to causes external to KSP MA itself. First, a few of the mods already updated (manually) to the latest version, when checked, are displayed in blue instead of in green. Rechecked, confirm they are to the latest version. Believe some data from spaceport do not match with what KSP MA expects to find. Not really a problem in the end. Second, I tried the auto-update feature (option: copy destination). Found the needed update on spaceport, downloaded (KSP MA asked where to download). But then I had to make the manual install procedure. Either KSP MA couldn't find matching files, or I did something wrong. Not really a problem, anyway, it already is a good step forward. Third, I installed version PR5 over the previous PR4, in the hope it would inherit the settings. However, it did not find the paths to the install directory, mod folder and the like. So had to input those anew. Small annoyance, only worth to report in case it may mean something to the author (but, it may be due to the new version not be intended to be installed that way). Fourth (just noted, but could always have been so). Using different install folders, (e.g. KSP ver 0.23 + KSP ver 0.23.5), KSP MA is able to record correctly the status of mods with each folder, and switch them from the options/paths menu. With each install folder, it is possible to give a "Backup path" and a "Download/Mod path". However, when switching, info about the "Download/Mod path" is retained only if the "Backup path" entry for the same install is not null. This may be intended behaviour, and easily I can enter any path for a backup and solve this. But believe, this too could be worth a note.

I hope you don't mind, but I'd like the two buttons to "Process Mods" be kept separate. I regularly use to process only mods I selected, and that allows me to have mods recognized and loaded with KSP MA mod list, but not installed in KSP. I routinely find performance issues or some incompatibilities with mods, and have to operate choices keeping some mods out. The current design allows me to do just that (also, I use the note field with each mod info to keep track of the reason it was to not be installed).

Very possibly yes, you got it. But let me make it in a way that could be good for others, too. So, you planned a maneuver with the roid grabbed, and have the blue marker for that. What you want is to align the CoM of the roid with that marker, and that most probably means orienting the roid. If a small roid, you can orient it with RCS or wheels on the ship, keeping the grabbing device pivot fixed after having oriented the ship to be alinged with the roid CoM. But with a large roid, you'll end your monoprop and even all electricity in the effort of orienting with RCS and wheels. My suggestion is then to free the pivot and let the ship orient so to have the thrust in the opposite direction (in respect of the roid CoM) than the blue marker. Thrusting will then make the roid rotate towards the blue marker. Actually, you need to plan for stopping that spin when CoM and blue marker are aligned, and that requires to reorient the ship in advance, while the roid is rotating, with a reversed deviation than the one used to make it spin. To orient only the ship (not the roid), RCS or wheels are good, so it shouldn't require much effort (unless the spin of the roid is so fast to be out of control, but then it is best left go or it will crash the ship). If the timing is just right, the spin will be cancelled when CoM and blue marker are aligned, so what's needed is just to realign the ship's thrust with the roid's CoM. If the ship was really perfectly aligned, then thrust would be all used to achieve the maneuver as planned. But, while pushing the roid, any slight deviation will again generate spin. It is then when I use the "wobble" effect, so if the roid begins a spin to the right (so the blue marker goes to the left), i wait when my thrust (NavBall center marker) has wobbled even more to the right than the CoM, and apply thrust then, with the effect to reduce or even reverse the spin and bring the roid orientation back where I want it to stay.

I may say I am sympathetic with what you're saying. I didn't use scenario ships, but my own (so can't and won't judge about those ships from Squad). The dimension (mass) of the roid is really of much importance, the same kind of ship I used without any trouble with Class C roids (about 100 tons) had a very hard time with a Class E (3500 tons). Those are sluggish, take a lot of time and attention to be oriented correctly, and I could only apply a fraction of thrust or the ship would go to pieces. But, even in that case, it was possible for me to bring that roid where I wanted by applying that "trick" with oriented thrust. Yes, if you can keep the roid lined up with your ship (so CoM and thrust aligned), it will go straight. For small roids, it is easy. It should also be easy with pulling roids, rather than pushing them (so you have to use a ship with the grabbing device in the same direction of the thrust of your engines, similar to the one shown in the video from MaxMaps), but I never went with that. But for pushing bigger roids, you can't keep the "purple circle" aligned, even the slightest deviation will make for increasing torque and spin. So the only way is to reorient the ship and counter that spin.

I'm not good (yet) at making videos, but hope the following can be clear enough. The spin on the roid is due to torque exerted on it, and the torque is due to how far off from the Center of Mass (CoM) of the roid you direct your thrust. With a normally built ship, your thrust is aligned with the root part, so the direction marker in the center of the NavBall is also showing your thrust direction. You normally want to push (or pull) the asteroid keeping its CoM exactly aligned with your thrust, therefore with the CoM in the center of the NavBall. Any deviation from true center will impart some spin. Even a very slight deviation, if kept during a long or powerful enough push, will impart crazy spins. What you want is to change the deviation so to apply thrust that will actually stop that spin. I normally use to push asteroids (did quite a lot while testing ARM), and when pushing to the left of the CoM, the roid will spin to the right. The same opposite relation goes with any other direction. I use to angle my thrust so to apply spin to the roid towards the direction I want it to rotate, and that way I can not only avoid it spinning wildly, but even rotate where I want more speedily than with other means. If need be, I use short impulses of thrust, only applied when the CoM is deviated from my thrust direction in the correct direction (I can use whatever means, RCS, wheels to rotate my ship so that the roid CoM comes in the correct position relative to my thrust). And, since the grabbing device is not rigid, but will allow some wobble, I use that wobble to time when to apply thrust in the correct direction, so to keep the roid oriented where I need it to be.

I've considered building ships so to pull asteroids, but as I learnt how to be effective in pushing them, I have always done that way. The important trick to know is how to center the CoM of the asteroid, aligned with your CoT, exactly as Navy2K said. But, when the CoM is not centered, the asteroid will begin to spin while pushed. Knowing where it will spin comes handy to rotate the asteroid in the correct direction (and so achieve a desired direction much sooner than using RCS or other means). If, e.g., your CoT is to the left of the asteroid CoM, the asteroid will rotate to the right when pushed. If you use angled pushes correctly, you can rotate your CoT around the CoM and apply spin so to keep the asteroid in a desired direction. It's a bit like pushing a trailer when going backwards with a lorry, it's not easy at first but after a bit of practice it can be done without effort.

I use to preplan as well as others advised, but if need be to change AGs in flight, you may try Action Group Manager. Or, give a try to Action Groups Extended, it should allow to assign so many new AGs that you may not need to change anything in flight.

Well, you seem to have quoted me wrongly while writing about Squad swapping modules (definitely not what I wrote, and you better acknowledge you did so). About the rest, you think the fault is from MM? Certainly it's not. SO what? Are we to change every other mod and constrain KSP itself, because of RT2? Again, No.

I would generally concur, better if need be to break compatibility earlier than later. But, in this case (thanks HoneyFox who clearly pointed the issue), the fault is entirely on RemoteTech. Any additional module will still change the module index number, and it can't be a viable solution to ask for any possible other modules (heck, even new ones from Squad?) to be renamed so to be loaded after "ModuleAnimateGeneric". The solution chosen by RemoteTech to use a module index is not perfect and needs to be addressed (and that may already be in the works, as Cilph said to be rewriting large parts of RT2).

If you want a precise, perfect inclination reading for an asteroid orbit (still, only valid once within the same SoI of your ship), you may want to use mods like MechJeb or VOID, then launch to match that reading. However, those mods are not strictly needed (I'm doing ARM testing without any, and intercepted successfully everything I wanted). My trick is, once the asteroid is within SoI (Kerbin's, unless you're launching from another body), to move the camera so that you're looking from one of the nodes (where the asteroid orbital plane and the ship orbital plane intersect - for the ship plane, I actually use Mun's orbital plane that has the same 0° inclination). Both orbits will then draw as straight segments, and you may easily judge the relative inclination (or, you can use a protractor on your screen for increased precision). Of course you know that you may be aiming from either AN or DN, and the inclination of one is just the opposite of the other: both are good, you have to use the one going according to the position of the launch site (if it is directly below the path of the approaching asteroid, or at the antipode, in which case the inclination to use is the opposite). I always wait to launch when the launch site is almost exactly aligned with a node, so to already be in the correct orbital plane, and take care of doing so that my initial LKO will be oriented in the direction the asteroid is coming from (you don't want to meet an asteroid head-on, actually, so the direction has to match).

The short answer is no, as your mod falls in the plugin category and these rules apply. Sorry, that means you have to provide the sourcecode for any part of it. If you can make the sourcecode for just the portion of that DLL that goes in the plugin, that's fine, as long as anybody may have a successful compile of your plugin from the sourcecode provided, without need to link to your closed DLL.