• Content Count

  • Joined

  • Last visited

Community Reputation

44 Excellent

1 Follower

About CrayzeeMonkey

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

1,142 profile views
  1. 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).
  2. 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?
  3. 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.
  4. 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
  5. 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.
  6. 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?
  7. CrayzeeMonkey

    [1.5.X]Aircraft Carrier Accessories

    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.
  8. 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.
  9. CrayzeeMonkey

    [1.3] Kerbal Joint Reinforcement v3.3.3 7/24/17

    I think I fixed IR compatibility without bringing along many of the side effects current workarounds bring. I implemented gomker's suggestion in this issue and made a pull request with the implemented suggestion. Basically, the plugin acts like multiPartAttachNodeReinforcement is 0 for exempted parts (defined in the config file), but acts like it's set to 1 for other parts. For me, it works as well as I expected it to, there's that IR wobble on the hinges, but hey it moves! If you want to get it, go here, download a .zip of the repository, and extract GameData/KerbalJointReinforcement into KSP's GameData. Please test it if you have the time, I'd rather know if I've made a big broken mess sooner. EDIT: Took it down after some concerns were voiced about ferram's tolerance of custom dlls. If you are already using the custom dll, DO NOT BUG FERRAM ABOUT THE PROBLEMS IT MIGHT CAUSE.
  10. CrayzeeMonkey

    [1.5.X]Aircraft Carrier Accessories

    This is a great mod and the parts work perfectly. Great work. I myself was trying to develop an arrestor hook system with the dynamic cables, but I wasn't sure how it should handle physics and I abandoned it. Does this mod have a code repository (like Github) of some kind? I had to go into the code and make a copy of the Catapult class you made but with a toggle setting so that the catapult doesn't grab everything all the time when it's disabled by the user (On an aircraft carrier I use, the same platform is used for landing and takeoff). I would have made a pull request and I don't want to just post the new plugin file so I posted this. Also, please include the .csproj file in your Source.rar file if you are willing to. It's so that people can just open the project in whatever IDE they are using and start looking at it. Thanks! EDIT: Made it change color on enable/disable change.
  11. I'm sorry, but what "dev version"? The link on the instructions post seems to be outdated, and even if it isn't, it's vague and terrible. It links to the entire Github page, and says to download a "master file". I have the latest version of KJR and I am using the 1.2 development build of Infernal Robotics + Legacy Parts and the hinge joints I'm using for folding wings are not working at all. The root wing and the folding wing (both B9 procedural wings) just 'bend' around the joint. No autostruts (or any struts really) were used. Here's a picture of the wing joint: Picture. I was thinking this "dev version" would fix the problem but apparently it doesn't even exist (anymore). What's even more bizarre is that the part I'm trying to move is supposed to be excluded from part stiffening, also, it the hinges work fine in other cases. I'm not even sure anymore, any help would be appreciated.
  12. CrayzeeMonkey

    Official FAR Craft Repository

    Not really. There is only a *tiny* bit of thrust vectoring in the pitch axis (about five degrees maximum) which might be pushing the craft to critical AoAs. I usually don't use thrust vectoring on a lot of my aircraft since I'm not very interested in making supermanuverable planes (I like building planes like they're from the 50's to the 80's), so I might also lock the vectoring on the plane I'm working on. On the sideslip, I never use the rudder while turning unless it's some sub par 'light' fighters I've made early in my save. Though after adding variable camber wings (more on that later), I did seem to notice a slideslip effect during turning where the nose yaws upwards about ~3-4 degrees. It could be different deflections on the flaps/slats, but I would need to dive into the FAR code and make it show current deflection on the right click menu. On the 1.2 version of FAR (Not sure if you're asking me specifically), I'm not using it. I bit the bullet and decided to stay with 1.1.3 instead. I know there's a pull on the FAR github page, but I have no idea how to get either the source or the compiled libraries. I want to ask but I'll probably be made fun of and shamed forever. Actually, It seems like I missed a decimal point. It's actually 0.15t/m² with a mass of ~10.51t and ~69.10m² of reference wing area. I keep an excel file with all the masses and wing areas of all my planes and it calculates the wing loadings for me. The most lightly loaded plane I have has a wing loading of 0.12t/m² and effortlessly turns around and shreds everything with its two 20mm guns. Wing rakes, fences and vortex generators, while very good in real life, don't look like they'll work as effectively in FAR. I don't think FAR models wind vortices yet (If an update adds that, I would kill to get it, it would literally change everything). I added both leading edge slats and AoA activated flaps on the wings and made them taper off a bit more at the end. I feel like the tapering of the wings did very well to improve turn characteristics overall, but I can't solidly confirm that. Though the variable camber wing (made possible by slats/flaps) were a different story. I don't know if adding variable camber either restricted the plane from pitching up into its critical AoA or increased wing lift, but it definitely did something that stopped the plane from pitching up into its doom. Besides the odd 'slideslip' effect I mentioned earlier, the variable camber did it. I've tried AoA activated leading edge slats before, but I never tweaked them enough to make them really work until now. Here's the (partially) variable camber in flight. I also added variable camber to the wings of that 0.12t/m² I mentioned, and it added a lot more turn stability while keeping roughly the same turn (rate?). Here's a photo of it. Thanks to both of you for your suggestions and ideas! PS: Where do you get the transparent cockpits?
  13. CrayzeeMonkey

    Official FAR Craft Repository

    I'm currently having a problem with some of my planes concerning (mostly) low speed control. While trying to make tight turns at speeds less than 150m/s, the highest wing in the turn starts stalling and the plane jerks to the direction opposite of the turn (Like the FW 190 when you try to push it too hard). Why does it do this? How can the wings stall at different times during a turn? Is there any way to prevent this from happening? Plane I'm currently working on, also has this problem at low speeds. Graphs if anyone is interested. -5 to 50 AoA Sweep at Mach .3 -5 to 50 AoA Sweep at Mach .3 and Pitch Setting 1 Wing loading (mass according to engineer's report / reference area in stability derivatives window): 15 t/m^2 Thanks in advance!
  14. How do you reliably run code at game start? Trying the KSPAddon startup attributes and [RuntimeInitializeOnLoadMethodAttribute] on a static function yields no joy. I'm trying to run some code to change some hardcoded values in the game for myself.