Jump to content

Yski

Members
  • Posts

    152
  • Joined

  • Last visited

Posts posted by Yski

  1. The issue isn't that it disappears at an altitude, with toss bombing, as I've been having some fun doing toss bombing myself. The issue is actually that the indicator disappears at an inclination of 10° or more, making it more a guessing game than anything.

    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.

  2. Currently predicted impact point marker dissapears when you start climbing.

    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.

  3. is there any specific place? and is that number at least or specificly 1.334* 5000

    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

  4. Can you make it so the bomb reticle does not not disapear at 5k? It's annoying when using powerful bombs

    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.

  5. Toggle on, then toggle off, matching the boolean state of the action group variable, would be the most sane way.

    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.

  6. I think he stated he won't do that as it made it that the gun would stay firing.

    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 :P

  7. Ah ok thanks :) Is it just an unfinished part of the mod then rather than me doing something silly?

    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.

  8. ok ill try to give you that .

    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 :)

  9. hiya i have been trying to install and use youre mod for a while now but it keeps causing a bug in my game which renders me unable to use my game and the mod unless the mod is removed . this is wahat happens . imigur: arknidsine

    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.

  10. Heh... I had the same idea. I already have 3 models waiting in the wings, with a few more in the works. All they need to work is for Baha to add a bit of code that allows me to remove the "fire" option so they only jettison, and for me to figure out a way so that they drain fuel first. I did attempt to use the fuel flow module thing for fuel lines on my pylons, but that just made the game crash... so obviously I need to wait until I can get a coder type to give me a hand, or for Baha to add something to BDA that allows drop tanks to function without having to add fuel lines to them. :)

    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.

  11. I did, to be honest 4 new, but it doesn't work at all. :/

    I tried to figure out what weapons made this happen, but when I launch a plane without ANY weapons/cannons/missiles, it still freezes it.

    Also, when i go to orbit map, the target is the sun.

    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.

  12. 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 fileName
    git 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.

  13. 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 :P

    EDIT: Looks like there's already a pull request.

  14. I'm looking for a mod (for 1.0.4) that either gives you a sensor package (like B9 did) or has a certain science part that will allow you to slowly gather science over time.

    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.

×
×
  • Create New...