Dodovogel

Ok so I spent 2 hours testing the issue and it is obscure. I can not reliably recreate it but I do experience it repeatedly. The only constant is: some staging event happens, i.e. some part of the ship detaches. Then it is not clear what needs to happen but under certain circumstances some or all Interstage Fairing Adapters on the ship lose their shielding ability even though visually they are still shielding their payload perfectly. There is nothing in the KSP.log or the Console that distinguishes this from situations when it does not happen. Other things to note: - It did happen on the Stock+MM+PF install as well but much less. - The vessel consists only of Interstage Fairing Adapters with Conic Fuselage Fairings, the rest are stock rocket parts. - I *think* some collision event may be responsible for triggering the problem. The collision does not necessarily happen at the fairing or the adapter. - I also think that it might be a runtime issue, which is what makes it hard to recreate. I observed that more complex crafts tend to be more prone to the problem and the problem tends to appear more often when I launched and reverted several times before. Perhaps something to do with some update occurring too slow or some event being undetected because of a skipped cycle in the physics engine? My computer is relatively old, KSP runs ok though. I have no idea how KSP and this mod work internally. Just speculating. I wish I could provide a more specific report but that's all I got. Perhaps somebody else will notice this issue too and provide new insights.

Well there is something off with PF in this situation. I created a stock craft (no mods except PF and MM) that will break on the launchpad for me (check F3 Report) and I think it should not do that. When I turn PF auto struts OFF it does not break. Craft file: https://drive.google.com/file/d/0B2tCogndf1O1VW9JYmoteTFtR2c/view?usp=sharing I am still not able to reliably reproduce this issue. I have the problem occurring with a rocket in a very modded install. I am not sure if PF is to blame for it. Just wondered if someone else had this problem too. I will continue to try and reproduce it in stock + MM + PF.

Hi I wanted to say that I do experience the same symptoms as @VonFrank but in my case I think it really is due to PF auto-strutting. Generally speaking it happens to me with heavy rockets, typically my interstage breaks the link with the engines (setup is: Interstage top node connects to fuel tank node and the engines are attached to the tank using surface attachment) and the fairing walls break off the interstage adapter. I long though it is a 'squeezing' issue so I tried all possible ways to to strengthen the connections with struts or give the parts more clearance. When I turn PF auto struts off, it usually fixes the issue. Another thing I observed is that when I play with stock auto struts, the point where the break occurs can change. But usually it breaks somewhere; latest, once the rocket starts accelerating. Further I observed another issue which I believe is not connected to the breaking of structural connections. I had a rocket with multiple PF interstages and when loading up on the launch pad the shielding works as expected. Parts shielded counts also seem right. When flying nothing changes about this until I decouple the first interstage. Then suddenly I get aerodynamic problems. The aero overlay suggests that the remaining fairings stopped shielding as there is huge drag forces applied to the inside parts and the 'parts shielded' count reads 0 for all remaining fairing bases - despite their fairings still being in place. I play without FAR. I will try to reproduce the problem tonight when I get home and provide you with a reproducible scenario. I didn't manage to track the problem down last night. But I meanwhile I wanted to mention this. Perhaps somebody else has some more insight.

About the readouts of the window and popup: I think I can only trigger it with experiments that have 0% science value remaining. Yet the lab in question could still use their data value for processing. Anyway in these cases there's no boost being shown. Also I can partially recreate the problem. It does not work in each case so i must be missing some condition but when it does, it is triggered in the following manner: 1. Perform experiment that has been transmitted/recovered before (0% science value in the tooltip when hovering over the blue dish icon). 2. Click the greenish science relay button; check the popup; it should say Xmit: <some value larger than 0>%. 3. Click "Cancel Transfer". 4. Click "Keep Experiment" (Green Stock Button) 5. Click "Review Data" in the action menu of the experiment. 6. Click the greenish science relay button; check the popup; it should say Xmit: 0%. Hope this helps. About the debug log: I understand that debugging all possible paths in the network would be too complex to make sense out. But perhaps there would be some way to at least log the link it uses when it finds one (as in when the Xmit is >0%). Then I can check if that link is theoretically valid if later it shows me 0%. Also.

I am playing with Science Relay 2.1 but it behaves mysteriously. Is there any debug output that could help me understand what is happening? I don't know if I am experiencing bugs or if I don't understand how it is supposed to behave. Specifically, I seem to have inexplicable situations when my Xmit value is 0% despite having connection on all ships. But sometimes only for some experiments (but the same experiments will have xmit >0% at some other, seemingly random time). Anyway I can't recreate the problem as I can't figure out the circumstances when it occurs - and it might not actually be a bug at all. It would be nice if we could see somewhere how the Xmit value is derived - for debugging. Anyway, thanks for this fantastic little mod.

Thank you for taking the time to look at this. Yeah, I suspected the problem is more likely to be found on the side of KIS but the problem does only appear in combination with mods, DR being one of them. I thought you might have an idea what is up because nothing seemed to be happening on the issue. Now, your comment got things going again on the KIS side. Thanks!

Hey guys can anyone help with this? It should be easy to test. Just strap this part onto any vehicle and try to fly it to orbit. The problems you're looking for is strange camera behavior (camera points behind the vehicle, zooms out without interaction, when zooming in is not centered on the CoM of the vehicle, ...). It does not start immediately. For me around 6 km altitude. But it gets worse over time.

Whatever the exact limitations are; they should be made explicit. Most frustrating is when you construct a mission only to find out that it doesn't work because you expected some other behavior. KSP does not help much in this respect as some of the part stats are not really intuitive. Like in this case I assumed "resettable" means the experiment can be "restored" by a scientist - but it can not. So I am not really sure what that means exactly. You can "reset" the experiment before you recover or transmit a photograph (which again is not really logical in case of a film camera). But there may be hardcoded limitations or gameplay considerations at play as well. I guess all I want to say is that whatever is chosen to be the right behavior, the player should be able to understand it when he constructs the vehicle. IMHO it is best to explicitly state limitations in the part description.

Yep, I am using the latest DRE, MM and KIS releases on an otherwise unmodified KSP 64 bit install on Windows 10.

Hi Starwaster It appears to me that Deadly Reentry and KIS have some incompatibility. KIS does not work when I have DRE installed. The symptom is that I can not add any items to inventories in the VAB. The issue is documented on the KIS github repository here: https://github.com/KospY/KIS/issues/151 I was just wondering if you are aware of this problem. Maybe you have some insight. Thanks

I think i used the low and mid tech ones, so those with film. Now it's not about re-running, actually. I understand that film capacity is limited (you can re-run it only a limited number of times - until film is full). But I figured a highly trained Kerbal scientist could exchange the film ("clean"/reset the experiment so the camera can be used again ). Here is my understanding how it ought to work: The low tech limit is that you can not transmit the image but you need to recover the experiment (i guess that would be the film). The mid tech can transmit a bad copy of the film (only partial science), else you need to recover it. Both of the previous experiments operate on film which is full after 4 exposures. The high tech one uses digital sensor and can transmit a perfect copy, no need to recover the experiment ( I did not actually test it but the part stats say this one is limited to 4 exposures as well - I don't understand why that should be a limit). Anyway if you have a different interpretation that is fine too. I just expected it to work differently.

Hi again I used the camera science experiments and I was surprised that they do not seem to be reset/cleanable using a scientist/science lab. Is this intended behavior?

Ok here we go. KSP 64 bit on Windows 10. Unmodded KSP installation except Tantares 35 from Spacedock. Craft: Just launch it. At about 6 km the camera goes crazy. The thing is that from there on the problem persists with the craft even after reloads/restarts/quickloads/whatever and irrespective of situation (i.e. flying in atmosphere or in orbit). When I remove the RCS tanks or replace them with other tanks the problem does not occur.

I don't know when I get to it (I am at work now). I could reproduce it by taking a Mk 1 Command Pod with a "Kickback" SRB below and two of those photovoltaic rcs tanks attached in radial symmetry to the SRB. I guess the type of propulsion doesn't matter, I just wanted to reach ~6 km in altitude with as few parts as possible. But I did not try with an unmodded (except Tantares of course) KSP install. Very well possible that some of the other mods I have installed is responsible for it. I just wanted to give a quick note about my finding, perhaps someone is having similar issues and/or can confirm my finding until I get around to play KSP again.

I don't know if this has been reported. I had an issue when a craft reached about 6 km in altitude, the camera started to act really weirdly, like the craft CoM is somewhere behind the craft. Anyway it got so bad that affected crafts are almost unplayable. There seem to be no errors in the log when this happens. I do have lots of mods installed so I can not rule out that this is the result of some cross-mod interaction. But if any of you have this issue. I tracked it down to the A-U2R Photovoltaic Monoprop Tanks. If I remove those from the craft or replace them with the non-solar panel version everything is fine. It would be cool if someone could verify this (perhaps without other mods installed).