Yski

Oh, I see. I took a quick look at the source again, and it looks like there's a vertical speed limit in there as well. I assume horrible things would happen if I removed it completely, but I'll see if I could say.. multiply it by 100 or something later.

Someone asked about that a while back, so I made a quick little fix that made the altitude at which the bomb aimer disappears config file configurable. I never actually tested if it works, but you could give it a try if you want to. The download is here, and all you have to do is to replace BDArmory/Plugins/BahaTurret.dll with the one I linked, and add MAX_BOMB_AIMER_ALTITUDE to BDArmory/settings.cfg. You'll also need to increase the physics range for it to work, since the maximum altitude is calculated like this: float maxAlt = Mathf.Clamp(BDArmorySettings.PHYSICS_RANGE * 0.75f, 2250, BDArmorySettings.MAX_BOMB_AIMER_ALTITUDE); //Clamp(value, min, max) limits the value to something between min and max If you do give it a try, let me know if it works.

The maximum altitude the bomb aimer will show up is either physics range * 0.75, or MAX_BOMB_AIMER_ALTITUDE, whichever is lower. If, for instance, your MAX_BOMB_AIMER_ALTITUDE is 20000 and physics range is 15000, the aimer should only show when up to 15000*0.75=11250 meters high. If you'd want it to use the 20000 maximum limit instead, you'd need your physics range to be 26668 meters or more. 30000 would work just fine, for instance. I believe that's because you need to be within physics range for the bomb to be able to hit anything in the first place. ..Looks like I linked an earlier draft that was missing the actual dll by accident. Sorry about that, try this one: https://github.com/Yskinator/BDArmory/releases/tag/fix5.1

Could you try the .dll here? I did a quick fix that probably made the maximum altitude config file configurable, but I'm hungry so I didn't actually test it. Let me know if it works and I'll send the changes to BahamutoD Simply replace the BDArmory/Plugins/BahaTurret.dll with the one I linked, and add MAX_BOMB_AIMER_ALTITUDE to BDArmory/settings.cfg. Try setting it to something like 20000 for starters, and make sure your physics range is also 1.334 times that or it will be the limiting factor instead.

Exactly how I ended up doing it. Otherwise you'd find yourself doing ridiculous things like trying to hit the button every physics update to keep a laser firing, for instance. Also spot on on the reasoning behind doing it in the first place.

I'm not sure I understood what you meant by that. Both single toggle -> single shot and toggle firing on/off are easily doable, just depends on whether you flip the turret back off again after firing - I tried both before going with the on/off toggle. Either way, I don't really see a reason not to do it considering how many possibilities it would open when combined with something like kOS. If it's action group only with no separate button, you'd have to be actively looking for it to find it anyway, so I doubt anyone could find it confusing or anything. Still, it's up to Baha, so I guess we'll find out when he gets back. I figured it would be neat to have it in the official version, but in the meanwhile, it's not like there's anything stopping me from just using my own modified version should I feel like it

That might change though - I sent Baha a pull request that made guns action group fireable a while back.

Does that even need to be an option? I can't really think of a situation where you wouldn't want some of your guns to be firing if the target is within range.

Unfortunately, the AI tries to pick the best weapon for the situation, and proceeds to only use it. Personally I'd much prefer if it simply used every weapon that's in range.

Yup. HEKV hasn't seen much love since the new systems were added since the mod focuses more on air battles. I'm fairly sure I had working HEKVs a few versions ago* though, and I'm fairly sure I've seen this issue before. It should hopefully be an easy fix, so I'll see what I can do *As in, I had them in my installation, possibly after a bit of tinkering with the missile code. BahamutoD is the actual BDArmory dev, I'm just a random guy who occasionally fixes a bug or two. EDIT: Hmm, I did get the missiles trying to fly towards the target, but the aim is way off - possibly a side efffect of going from using orbital velocity (which makes sense for space missiles) to using surface velocity, as that's what the new systems like to use. I'll take another look tomorrow and see if I can get them working properly.

Thanks, that's exactly what I needed to know. I did some testing, and found a null reference exception in DoRCS() that's probably causing the issue. I'm getting a serious deja-vu here though. Have I already fixed this at some point..?

Details. How are you trying to use it, and what happens? Are you using Legacy Targeting or the new systems?

I don't see any mention of BDArmory in the log file. The log file is reset every time you launch the game, so could it be that you didn't have BDAmory installed when you last ran it before uploading the file? Either that, or something went horribly wrong when you installed it. EDIT: Ok, looks like it was an incorrect installation then. Glad it worked out for you

That doesn't look like the kind of thing BDArmory should be able to cause. I'm not sure what's happening, but could you post your log file for me to take a look? Maybe I'll find some explanation there. Depending on your operating system, it's either ~/.config/unity3d/Squad/Kerbal Space Program/Player.log on linux, [KSP]\KSP_Data\output_log.txt on windows.

I don't see a link, and googling that last bit only gave me this thread. In the meanwhile, do you have any other mods, and are you sure you installed BDArmory correctly? Try re-installing it with CKAN for instance, that way we can be reasonably sure everything is where it should be.

Wait, why would you need BDArmory for drop tanks? Sounds like you'd just need a tank, a decoupler and a fuel line to me.

If re-installing doesn't work, could you post your log file somewhere I can see it? It's ~/.config/unity3d/Squad/Kerbal Space Program/Player.log on linux, [KSP]\KSP_Data\output_log.txt on windows.

Hey Baha, I noticed someone asking for action group fireable weapons, so I made it happen and sent you a pull request on GitHub.

Nice, I didn't know that one. Learned something new today

Right, let's see how well I can explain this. Before we begin, I should probably add that I don't claim to be an expert, so if you disagree with something I said, it's entirely possible I'm wrong. After writing this, I realize it's a bit of a wall of text, so I added quick TL;DR bullet points to the beginning, if that's all you were looking for. You'll find a more detailed explanation below, and feel free to ask if something's still unclear. Let's assume you want to fix a bug on mod X. Fork it. That's your own version of the mod you can make the changes on, before sending a pull request so that they can be added to the original. Clone the fork to your computer. Make a new branch for the fix. Every time you change something, make a new commit. Push the changes from your computer to your fork. Send a pull request to merge the changes you made on your fork on the new branch to the original repository. It's now up to the modder whether they accept your changes or not. First you'll need to fork it on your GitHub account. What this basically means is, you need to have your own version of mod X on GitHub where you do the changes, before you send a pull request to ask the original modder to make those changes part of the official repository. I imagine the idea is that you can branch away from the original if need be without making things messy, but thanks to the shared history it's easy enough to merge changes as well. Once you have your repository on GitHub, it's time to clone it on your computer. Copy the clone URL on the right of your fork, then use git clone url/to/fork.git to make your local version. By default your local copy only knows where to find the fork you cloned it from. You'll probably want to update your fork when the original mod gets updated, so it's worth telling it where to find the original repository as well. Use git remote -v to see existing remotes (=repositories on GitHub), and git remote add name URL to add new ones. In this case, the URL you'd want is the clone URL for the original repository you forked. While you're at it, if it's your first time using git on that computer, set up your user name and email so that they show up correctly on your commits. git config --global user.email "yourEmail@email_place.com"git config --global user.name "Your user name" Now, to the interesting stuff. The way git works is that everything you work on should have its own branch, so that it's sort of isolated from everything else that's going on. It's especially important when you want to contribute more than one change on someone else's project - pull requests ask them to merge all the changes made on that branch, and if you made all your changes on the same branch, they'll either have to accept or deny all of them instead of being able to choose which ones they actually want. In case you find branches difficult to understand, think of them as alternate universe versions of you code. No changes made in one branch affect the others until you merge them back together again. When you hop between branches, git replaces all the files with their correct "alternate universe" versions, then switches them back again when you return to the original branch. To create a new branch, use git checkout -b branchName To switch to branch branchName, use git checkout branchName To see a list of all your branches, use git branch To merge changes made on branchName to the current branch, use git merge branchName That little bug you were planning to fix on X? You'd want to make a new branch for it. Now, if you are safely on your new bug fix branch, it's time to do the actual coding. But first, let's talk about commits. Every time you change something, you should make a new commit, so that you can easily keep track of what changed and when, as well as revert those changes if need be. It's the same rule of thumb as with functions: your commit message should tell exactly what you changed, and if you had to use an "and", it should probably be two separate commits. So, once you've made your changes and saved them, use either or git add fileNamegit add -i to stage the files, in other words add them to be committed. If you just give git a file to add, it'll add all the changes to that file. Add -i on the other hand lets you pick files as well as specific chunks of code you changed that you want to stage, so that's what I'd recommend you use. If you accidentally added something you didn't mean to, use git reset fileName to un-add it. Once that's done, use git commit -m "Your commit message." to commit your changes. You can then use git log to see your commits, and git diff to see what changed between them. Once you've made and committed all the changes you want, it's time to push them to your repository. That just means you upload your changes to GitHub. When pushing from a new branch for the first time, go to that branch and use git push -u origin branchName It tells git to push changes on branchName to where the repository was cloned from, in other words your fork on GitHub, as well as to push there by default from now on. After that just git push will do the trick. If you need to do the opposite and pull changes from GitHub, use git pull remoteName branchName ,where remoteName is one of those remote repositories I had you tell Git about earlier. By default, origin points to the GitHub repository you cloned your local copy from. branchName is the branch you wish to update. Note that it'll only pull the changes made to that branch on the GitHub repo. Now it's time to send a pull request. Go to the branch you want to merge to the official version on your GitHub repository, and make a pull request. Explain what you changed and why, and wait until the requests gets accepted. Once that's done, you can safely delete the branch. Oh, and as for the second question, it's probably best to keep the project and your GameData folder separate. I'd just copy the relevant files to GameData as need be, feels more organized.

That could be it, I'm fairly sure they were all tweakscaled parts. I'll stick to the default size from now on then, and see if it keeps happening.

I've noticed my IR parts sometimes move slightly away from their proper positions, resulting in gaps between parts, usually after loading back in after leaving the ship in orbit for a few weeks. Is this a known issue, or should I see if I can reproduce it on an IR only install?

I was mainly asking in case it is there, but for some reason not showing up as being made by RoverDude and with the correct name. It's been a few days since this was released, so I figured the CKAN bots should've spotted it by now, but apparently not. It's not a huge deal since I can just as well keep it up to date manually, but with 170+ mods on my current install updating them can never be made too easy. I guess I'll take a look at those netkan files tomorrow, from what I've understood it shouldn't take me more than five minutes to just go and add it myself. I'd do it now, but I've been procrastinating on my physics exercises too long as it is EDIT: Looks like there's already a pull request.

The Kerbal Stuff page claims this has been listed on CKAN, but I'm not seeing it. Am I blind?

How about B9? The WIP version from Blowfish's signature works just fine. As for slowly gathering science things you might be interested in, take a look at Station Science and see if that's the kind of thing you are looking for.