CrayzeeMonkey

Are you using Scatterer? I am using 1.12 and had the same problem, and it seemed to go away when I uninstalled Scatterer. I was using the Runway Project fork but it might work for the 1.12 prerelease too. I did some digging and found these on Github, which gave me the idea to try it. https://github.com/PapaJoesSoup/BDArmory/issues/641 https://github.com/PapaJoesSoup/BDArmory/issues/564 Can't test this shot in the dark because it's late and I need to sleep, maybe a solution would be to downgrade Scatterer? When I was checking it out I put the RWP fork for 1.12 and installed it on my old 1.9.1 KSP+BDArmory install with Scatterer 0.07<something>, and the targeting pod rendered fine. The Scatterer I am using for 1.12 that broke the TGP was 0.08<something>. Also, posting for the first time after two years of hiatus from this forum Just discovered that RWP exists and sparked some old KSP interest again.

What could cause the text in these buttons to look misaligned? I have verified the style i'm using has alignment: MiddleCenter

I'm trying to make a debug installation out of a fresh installation of 1.8.1. I linked KSP_x64_Data to KSP_x64_Dbg_Data, moved WindowsPlayer.exe from windowsstandalonesupport\Variations\win64_development_mono in my Unity 2019.2.2f1 install. And renamed WindowsPlayer.exe to KSP_x64_Dbg, and edited player-connection-debug=1 into the boot.config. I'm using Windows 10. When I launch through the debug exe, KSP launches as if it's through a normal install. The development mode label and console isn't there, and I can't attach the Unity instance to Visual Studio. Worst of all, I'm getting no error message telling me what's wrong, it's just completely silent. I don't know what to do anymore. What's more frustrating is that the same procedure works immaculately for KSP 1.9. Am I using the wrong version of Unity? According to this and the details tab of the properties of the ksp .exe it should be correct. I tried the simplified method by @sarbian and it let me attach through Visual Studio at least, but when I use breakpoints I get "The breakpoint will not currently be hit. Unable to find corresponding location." Debugging information is set to Portable, if that matters. I'm going to give up and wallow in my frustration for now EDIT: Managed to figure it out. I remembered that I also had to copy over UnityPlayer.dll and WinPixEventRuntime.dll, but it didn't work the first time. After reinstalling KSP to ensure that it was 'fresh', doing the same worked.

One popup would probably be too big, and the options that I would put on the second popup won't be used as often, and since PopupDialogs are hard to update, I can't add another section to an already spawned PopupDialog when more settings are needed. I might try a scrollbar. Is there a way to make a set of settings look like they're greyed out? You can give settings a condition where they are unusable, but there's no visual indication that they're disabled, which is a problem.

How do you spawn two different PopupDialogs so that they look like they're attached and not overlapping? The coordinate system makes it really difficult. You can't use Screen.width/height to normalize pixel coordinates because there's a silly margin on the screen that shifts the origin away from the bottom left of the screen. I also tried to give the two PopupDialogs different anchors (example: first PD has anchor (0, 0), and second PD has anchor (0, 1)) so that when given the same Rect they should be at the same location, but for some bizarre reason they overlap. Is there a way to get this margin so I can account for it?

When patching wings for FAR, is there a more efficient and faster way to derive values for FARWingAerodynamicModel and FARControllableSurface than opening them in blender and deriving the values manually? Currently what I do is make a B9 procedural wing similar in shape to the unpatched part, and using the values on the procedural wing's PAW for the config. While more efficient than using Blender I am not sure if I am even using the numbers correctly. I'm making FAR patches for wings and fins that don't support FAR in my career setup. Normally in a sandbox game I would just use procedural wings, but they aren't always available and the look of non-procedural wings has kind of grown on me.

How do you use the stock trim system with this mod? I'd like to pitch up very gently using trim but it doesn't seem to affect the aircraft. Trim on roll and yaw also seems to have no effect. I looked up the word "trim" in this thread and someone does talk about it like it does work. Maybe it is a problem with my installation? Thank you for the mod by the way. I've been playing KSP for ages and I wish I had found this earlier.

Are the stock heatshields intended to be used with deadly reentry? I installed DRE manually and to my surprise the stock heatshields remained unchanged.

Can you send me the missile turret from your parts pack? If it has a MissileTransform that moves along with the turret I can use it for testing.

It is a fork of BDAC, yes. I'm planning to add auto-reload so you don't have to use action groups.

Results after working on ModuleMissileRearm while under quarantine

I wonder if someone can explain why this is necessary

Try this fix. Download the .dll and replace the original .dll with this one. I want to know if, with the new dll, you can reload the rail successfully, any other related errors occur, and any effects it might have on staging. https://www.dropbox.com/s/21a9epxskkj39dr/ACA.dll?dl=0

Does anyone else have this issue I'm having? Trying to reload throws a nullref at ReloadableRail.PartSnapshot() Another seemingly random question - when successfully reloaded, does staging completely break? As in the staging bar disappears and you cannot trigger any staging actions.

Yeah, thank you. I completely forgot reloadable missiles came from that mod. Can you describe how your missiles are reloaded? I'm not sure if mine is working correctly.

Is the reloadable rail system currently broken? If not, has anyone made a part or a part pack that has the reloadable rails implemented? I have a feature idea that I want to try implementing that involves reloadable rails.

Is there an elegant way to disable collisions for an entire vessel? Just setting the rigidbody detectCollisions false on all the parts of a vessel seems problematic (nullrefs are thrown).

Sorry, but shouldn't I make a pull request instead? I already wrote the code and it works well enough, but I can see why you guys might want to do it yourself because it's pretty bad . (Here's my branch by the way) If you want to make a change, do you always have to open an issue?

I made a new guidance/targeting type! (Sorry for the low quality, I thought the text would be a lot clearer than it would be) If the video wasn't clear enough, essentially: - Radars emit a 'tracking beam' from the locking radar to the actively locked target that a missile can follow. (If you have multiple locks the actively locked target is the highlighted lock) - A missile can start following a tracking beam when it is in either a narrow 'capture beam' or a wide, short range capture beam. The capture beams are like cones with the apex as the locking radar and the axis the tracking beam. - When in boresight mode, the boresighting radar emits a tracking beam in front of it that a missile can follow. While boresighting the radar won't attempt to lock up the last missile. (I created an entirely new 'scanning' mode for this one time, but I decided against that because it felt the changes were too 'destructive'.) - The tracking beam can be changed by relocking another target, and as long as the missile is in the new tracking beam's capture beam the missile will follow that tracking beam. Some things it's still missing: - Missile perfectly follows the tracking beam if it has enough energy (thinking of adding a random element by using Random.onUnitSphere() and projecting that point onto a plane with the tracking beam as a normal) - Time to impact (I'm not vector-savvy enough to do this) One of the reasons I made this was to give the ground radars more useful for ground attack. I also wanted my pseudo MiG-21s to have a little bit more ground attack functionality :). I highly doubt this is actually going to be merged and integrated into the mod, but I'm not terribly sure how to publish my changes to Github. I have a local branch (called "feature_RadarBeamRidingGuidance" based on master) up but I don't know if I should publish it to PapaJoe's repository (I'm not even sure if I can) or my own forked repository.

I did decipher a little bit though. I think I have an idea on how missiles receive radar data for guidance*, good enough that I made some changes I haven't managed to test yet. But I'll take your word for it and try to understand it for myself. *Might be wrong, but essentially for radar guided missiles on every FixedUpdate it checks if the launcher actually has a lock (target exists in some list in the VRD instance) and gets the current and predicted position of a targeted vehicle that it uses for guidance (For semi-active missiles at least). Sorry for any stupid questions or any rambling

What do the parameters tracerDeltaFactor, tracerInterval and nonTracerWidth do? The tracers for the Aviator's Arsenal guns look a bit wonky for me and I'm looking into trying to fix them (I'm using the MM patch provided at the end of the AA thread). I'm guessing the last two is to model only a certain proportion of bullets actually having tracers (Every third tracer from AA guns with the MM patch is 'fat'), but nonTracerWidth for the hidden vulcan part is 0.035 which is somewhat confusing (what's the point?)(Nevermind, this was pretty obvious). tracerDeltaFactor looks like it deals with Time.deltaTime and I'm not even sure if I need to worry about that. Also, I feel like this is a pretty big ask, but can someone who knows how the code works explain how targeting data is passed on to missiles for guidance? How does the VesselRadarData class work in general? I spent a whole whole night trying to decipher what's happening in the source code for something I'm thinking of doing and at the end of that my head and eyes were in agony. I might be able to do it myself but an explanation would be a big help.

Yes, It's working for me now. It's just that most of my ships go along at a steady 36m/s, which depending on its heading not giving missiles enough space to lock on and hit the target. Though I've seen some missiles that lock on at the last minute and hook into the ships sides or back. I can also tell it works as occasionally the RWR detects the missiles lock. Thanks! What will the sonar look like after it has surpassed its radar placeholder stage? Are sonar 'phenomena' like the thermal layer and maybe even biological noise going to be added?

I see. Thanks.

Uh, the tiedown explanation isn't totally clear to me. I got the green chain to show up, but what do I do? What do you mean by pressing 'break'? Deactivating the fixed point or the tiedown point just disconnects the green chain. Sorry if this was already talked about.

How exactly does the terminal guidance mode in BDArmory's cruise missiles work? Does it just switch to radar guidance (or some other guidance type) at the 'terminalGuidanceDistance' specified in MMPatches? Or do I have to lock a radar target in addition to specifying a GPS target and launching? Whatever it is, it doesn't seem to be working well for the AI (In my installation anyway). The AI launched missiles seem to just hit where the target was once 30 or 60 seconds ago. I'll have to play with it some more though in order to make sure it's the AI and not me, I don't want to waste anyone's time. Also, the node definitions in the configs don't seem to match the ingame nodes. There's only one node_stack_top definition on the missiles which is the same as the surface attachment node. What's the deal? Is there some magical hidden config patch hidden somewhere adding that second attachment node we see on the missiles booster end in game? I'd like to clear my bamboozlement as I'm thinking of making my own personal use anti-ship missiles and I'd like to get the node correct this time. (Since I feel that I'm neither responsible or confident enough to maintain my own mod, I'll probably donate them to some other person who can put it into a pack of their own). On the new sonar sensors, they could definitely use a higher impact tolerance, as I find that occasionally they break, leaving the ship using the sonar having no capability of using torps. If time and effort allows, a deployable towed array could be added, or a significantly larger sonar suite meant to be mounted on a keel of a ship. It would also be nice if the radar datalink can work with sonar, so that my torpedo armed helicopters don't have to have dipping sonar (Again though, I'm not sure if it actually doesn't work. There's probably also a way to make this work by looking at the datalink's configs, but I haven't looked at it yet.) Nevermind it works. Also the continued branch is 420 commits ahead of Bahamuto's last update. Heh.