• Content count

  • Joined

  • Last visited

Community Reputation

358 Excellent

About Mihara

  • Rank
    Mad (social) scientist
  1. That would be difficult, and I'd rather set up a proper test environment with only HGR, Landertron and preferably nothing else, which will take time I don't have at the moment. But I was able to replicate the behaviour with a hyperedited pod reliably in a sandbox save. Mind you, it's a bit voodoo, but it suggests the likely mod interaction that triggers the issue. Test article: Descent pod, parachute, nothing else. Pod and parachute in stage 0. Launch. Use hyperedit ship lander to send it to 7000m and drop the pod. Max out physical warp. Wait until you're no more than 2000m up, but still above the full parachute deployment altitude. Stage. What happens: The parachute opens fully, and at this point, SafeChutes plugin drops physical warp. That's the moment landertrons fire, anywhere between 200 and 700m off the ground. What triggers the early firing is apparently coming out of physical warp while above a certain speed, and since with SafeChutes you can usually speed up parachute landings with no ill effects, I've been using physical warp extensively while landing.
  2. Aha, there we go, replicated. I was worried my memory is playing tricks on me and I did something wrong, but nope, the problem exists. Numerous tests hyperediting and dropping a pod from 2-10km resulted in landertrons working as designed. So did simple orbit tests in sandbox mode by hyperediting the assembled vehicle and doing the landing by the numbers. However, once I tried the test in career mode, this happened: I return a Soyjuice from a moon flyby, dropping to a periapsis of 40km and reentering after separating the modules. This results in bouncing back and a second reentry. Once the pod slows down to a speed safe enough to open the parachute, I stage the chute, the heatshield and the landertrons all at once while still flying nearly horizontally. The landertrons immediately fire long before I'm at the ground. P.S. So I did it again: I reloaded the save made before landing and this time, manually decoupled the heatshield, then deployed the chute, then waited until I was strictly vertical and the chute was fully open, and only then armed the landertrons. Landertrons fired immediately.
  3. Double checking. .version file in GameData/Landertron insists it's 1.1.0, .version in GameData/HGR says it's 1.5.2, and yes, I'm running KSP 1.3. I never had any prior installations of HGR on this installation of KSP and I never used Landertron before. Mind you, it works on the pad -- If I mount the pod on a clamp, arm it, and stage the clamp, it activates properly. But if I stage it during an actual orbital landing, it fires immediately, whether I already have the parachute open or not. I tried doing it while a hundred meters away from the ground and somehow it still fired immediately and burned out well before the pod landed. Let me try some more tests with numbers... P.S. I don't use RSS or planet mods or anything that affects the entire physics except KJR, almost all of the rest are UI/control/spawn mods and parts.
  4. So, I installed the plugin to make the soft landing motors in HGR's SoyJuice work, and somehow I can't get it to behave the way I expect: When descending, whether parachute is open or not, regardless of how far the pod is from the ground, arming the motors (using the rightclick menu, but staging seems to do the same) results in them firing immediately. I was under the impression that upon staging them, the actual firing will not happen until they can suicide burn the capsule into zero on the ground, or some close approximation? If so, what could I be doing wrong?
  5. Actually, this works better: <string name="exemptModuleType5">ModuleGrappleNode</string> This makes the claw exactly as exempt as the Lynx rover joint, (or as the IR parts are supposed to be) and the Advanced Grapple Unit starts pivoting as designed. At least, I just tested this on the ground and I'm going after an asteroid now... EDIT: Well, it works. That is, it pivots even on a real asteroid. But it breaks the universe: the resulting connection starts oscillating with phantom forces which eventually quietly tear the ship apart...
  6. I am. That is, I eventually drifted out of modding because I realised that launching KSP to test out a change in the code takes up all the time I could be playing it instead, and then I got a job. I am not going to give in to the temptation to start coding for KSP again. But it would be sad if all that work went to waste, wouldn't it?
  7. I endorse this product and/or service. And the Sensible Pumps one. Really, I'm happy that someone's up to maintaining my old code, keep up the good work.
  8. But the bundled one is not new either. Ack. EDIT: Fixed, please redownload if that you use KSP-AVC.
  9. Well, I'm not dead. I am, however, very busy with my day job, so I don't really have time to continue working on RPM for the upcoming month or so. (It should clear up later) As such, I only have time for a maintenance release to correspond with 0.25 and make it work again. This is it. RasterPropMonitor v0.18.3 This is a maintenance release to make RPM work with KSP 0.25 again. Bundled ModuleManager version updated to 2.5.1. Bug where transparent pods would cause spurious configuration error warnings has been fixed.
  10. You don't need one. Check the targeting page, and then use the "Reference part" option in the targeting menu to select a docking port.
  11. Then talk to the author of StarSystems to make it stop crashing and breaking the initialization chain. Show them this post: http://forum.kerbalspaceprogram.com/threads/57603-0-24-2-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-18-1%29-27-Jul?p=1297893&viewfull=1#post1297893 This is utterly impossible to fix on the RPM end. Not really. People rarely think to post here about the things they made with RPM these days.
  12. This is trivial, but I won't be able to add that into a published release in the immediate future, (like ten days or so) I'm afraid.
  13. Might be an illusion, but regardless, since when anything in KSP internals is sane anway?
  14. The catch is that the models will not load if all textures the names of which are compiled into the MU file are not found directly where the model is -- regardless of how the model is used after that, the model loader is silly. The workaround is to keep dummy files of minimal possible size, which is 32x32 pixels at 24 bits, in the same directory as the model, with names the same as what is compiled into the model. Then substitute real textures with MODEL {} when you actually use the model in a prop/part/whatever.
  15. Yes it does. PROP { name = IndicatorPanelRPM MODEL { model = Squad/Props/IndicatorPanel/model texture = model000,JSI/RasterPropMonitor/Library/Props/IndicatorPanelReplacement/model000 texture = model001,JSI/RasterPropMonitor/Library/Props/IndicatorPanelReplacement/model001 } ....