gap

"Maybe" Meaning: if it was an overlook you might decide to correct it, otherwise feel free to ignore my note. Sorry for not having been clear enough.

Thank you, I had already set 1.8 mods as compatible and I understand that updating CKAN info for all the mods you support every time a new game version is released, is a PITA. That's why in the first place I had started by saying "just for your information" Thank you for your answer and for all your doing for KSP.

@jrodriguez Just for your information: CKAN's metadata points to the old Destruction Effects thread rather than this one as the main mod thread

@linuxgurugamer ,Just for your information. According to CKAN, max game version compatible with the last version of this mod (1.4.5.3) is KSP v1.8.1. Maybe you should updated its metadata.

Hi @linuxgurugamer , for your information: CKAN says that the max game version compatible with the latest release of this mod (1.1.10.4) is KSP v1.8.1. Maybe you should updated its metadata.

Thank you Moose. Does RealPlume deal with heat effects from atmospheric drag as well as engine effects? I can't imagine exhaust plumes surrounding the whole rocket like in the picture below

Read below please

Terrific screenshots! @Alex33212 I am sorry for derailing this thread, but may I ask if, besides AVP and its dependencies, you use any other visual mod? Are the flames in the first picture from the Reentry Particle Effect mod? What about the metallic reflections on satellites? I use Textures Unlimited + an unsupported config mod from spacedock.info. The specular reflections they give are superb, but they come at the cost of several visual glitches...

@cakepie I am wondering the same. On the other end, after the engine changes introduced with ksp v1.8, is this mod still needed?

By the way of that option, are there any news on this topic?

Okay thanks, good to know! I suppose this is a general rule applying to all the mods that in the meanwhile have been updated to KSP v1.8. Is my supposition correct?

Thank you for the update(s)! Should player who have not yet updated their game to KSP 1.8 stick to v7.7.3.1 of Deadly Reentry?

Thank you for your feedback mate, and of course for your work on KSP! When possible, I always install my favorite mods using CKAN so that I am (almost) sure that I am using the latest versions and that I am no missing any dependency or incompatibility

Hi @Eskandare , is there any good reason why this mod is not on CKAN, but it is its outdated (and unsupported) version 'Kerbin Side Continued'?

Never mind, sorry: I have just had another idea; add it to the list: Visual alarms 13. What about letting the player free to choose different mod buttons to be triggered by different alarms? We could use buttons of different colors from yellow to purple to represent various severity levels, or we could even put symbols on them to discern at first glance an alarm from the other.

Okay, for ease of reading I will group my questions in categories. Here they are: Alarm-triggering conditions 1. I don't know how collision risk is currently estimated, but how easy would be replacing it with more simple physical parameters (i.e. distance from the nearest celestial body, atmosphere pressure, distance from the soil, relative speed from the target body, velocity, vertical/horizontal speed and acceleration, g-force, pitch, roll and yaw angles, temperature, engine throttle, etc.), so to have an higher level of flexibility and so to enable the player setting his own customized alarms? 2. How about more complex variables like stall, system failures, etc? 3. For the first category (physical variables) could the user set a threshold beyond which a given alarm is triggered? e.g: if our craft's altitude relative to the surface is below 1,000 m or if its vertical speed is beyond 100 m/s, an alarm is triggered. 4. For all the variables: can we have per-part triggering conditions? e.g: if a solar panel fails, if capsule's temperature is beyond 100° C, or if the landing gear is not extended, an alarm is triggered. 5. For resources: can we have absolute (unit) thresholds besides the relative (percent) thresholds already featured in the mod? 6. Can we combine two or more conditions for creating triggering events? e.g: if altitude is below 1,000 m AND v-speed is beyond -100 m/s, if we are below 500 m AND our V-speed is lesser than 0 m/s AND the landing gear is not extended, or if air pressure is bigger than 0 AND velocity is bigger than 25 m/s AND solar panels are extended, an alarm is triggered. 7. In order to better simulate radio calls from Control Tower/Mission Control, could an alarm-triggering condition be active craft being in CommNet range and having a functional radio antenna fitted? Alarm tone settings 8. Can we set alarm volumes in game? (Maybe that's a feature already implemented, though I couldn't find any volume setting in the mod menu). 9 Could we create customized warnings by choosing more than one sound for each alarm? e.g. when a given alarm is triggered, one beep from a file is played followed by two beeps from another file, or rather: a quindar tone is played followed by a vocal warning by Mission Control. 10. Could we choose how many times our custom alarms should be played: e.g. alarm playing a configurable number of times and then stopping, alarm looped until reaction by the player (i.e. mod's button pressed), or looped until alarm conditions are satisfied. Textual alarms 11. Given the potentially high number of different alarms we can activate at the same time and the limited number of alarm tones we have available, having textual information on any possible alarm might be useful. Could information on the last triggered alarm be displayed on screen (maybe in a tooltip popping up when we hoover the cursor on mod's button, or wherever you think it more appropriate)? Warning texts could be typed directly by the player, or be taken from the (first or last in case of multiple conditions) alarm-triggering condition: e.g. excessive descent speed, RCS failure, liquid fuel too low, pitch angle too high, etc. Presets 12. Given the high number of alarms we can set and the complexity of the settings I suggested above, the ability to save/reload groups of pre-set alarms that we might use in different circumstances and share with the community, would be indeed an useful feature. That should be all for now, thank you in advance for your attention and for answering some or all of the points above in no special order and with your time

Take your time and let me know if you are plan adding some new features to this mod. I have quite a few ideas Re this topic, but I realize you are busy with the many more mods that you take car of

Little nice mod thank you for taking care of it (too) @linuxgurugamer ! This afternoon it got me inspired, so I have created a slightly improved set of icons for it and added several new alarm sounds, captured from videos I found on the web: http://www.mediafire.com/file/6ii93jeh3cx3ia3/Danger_Alerts_additional_sounds_%2B_new_icons.rar/file Several of the new sounds are from some of my favorite space movies, an many others are original T-CAS and GPWS alarms used on the Boeing 737. All the alarm tones can be looped or, if needed, they can be easily split into a single beep. Vocal warnings had noise added and voices "kerbalized" so to simulate radio calls from Mission Control. Most messages obviously have little or no use with the alarm types currently implemented in the mod, but I thought I would send them anyway, in case you decide to add new alarm-triggering events to the mod. They are mostly self-explanatory, but you can find descriptions for most of them at this link or in the comments to this youtube video.

Hi @severedsolo, while reading this thread today I had one or two ideas that you might find interesting (or maybe not). To cut short: I have not been playing the game for quite a while now so forgive me if am going to say something totally wrong, but IIRC when this mod is installed, failures are almost immediate. Indeed sudden and catastrophic failures are realistic in most situations, especially where rockets and big fuel masses are involved, yet I can imagine situations where a system starts malfunctioning before it fails. An engine for instance might start overheating and/or vibrating before it shuts down or explodes, a battery might start leaking liquid before it actually starts losing its charge, an electrical system might suffer electrical dispersion before it blows up, etc, etc. Moreover, some malfunctions might evolve in major failures, while others, like a loose electrical connection might cause certains parts to work intermittently. So my idea is: after certain parts * are marked for failure, a second dice should be rolled for deciding whether the said part will fail immediately or not. If true (sudden failure), the failure is handled as per current version of OhScrap!; if false (malfunction): the part is marked as "malfunctioning"; the player gets an alarm and a notification on the defective part and on the nature of the anomaly/malfunction **; another dice is rolled for deciding whether the malfunctioning part will eventually fail or not: if yes, after a random number of seconds unknown to the player, the anomaly will irrevocably evolve in major failure if not fixed; during this time the player can take action to limit the (future) damage, and he can try fixing the problem the way we currently do with normal failures ***; if no, no random timer will be set but, unless fixed, the part will have an higher chance of failure during the next dice rolls (i.e. a multiplier >1 will be applied to its regular failure chance). Malfunctioning/defective parts might still accomplish their function normally though, if not too complicated, it would be cool if they worked poorly (e.g: thrusters and engines working intermittently, burning too much fuel or having a reduced power, solar panels recharging batteries at a low rate, radio and other electrical equipment switching on and off, etc.). Only a a successful fix should revert a malfunctioning part to its normal status. Moreover, a defect/malfunction shouldn't apply to a defective part more than once, so if during regular failure checks a part previously (and still) marked as "malfunctioning" is chosen again for failure, the routines above shouldn't apply and the part should fail immediately. Notes: * Of course, the ideas discussed here can't apply to all the rocket parts. SRBs and probably tanks are a good example of parts that can surely fail but hardly malfunction. ** It would be cool if the detection and notification of some anomalies required appropriate sensors, in the form of stock or custom parts that we could fit on our command modules. In their absence, malfunctions would still happen as described above, but we would only know about them from their effects. *** Maybe, due to their lesser severe nature, malfunctions should have a slight better chances of being fixed compared to failures. Well, that should be more or less all. I hope I made myself clear enough. Let me know if among my ravings you found something useful.

Thank you, I will, but I may as well have waited a few hours or a couple of days. My last post wasn't meant to rush you but of course you quick feedback is highly appreciated here

Hi @linuxgurugamer I am dropping a note just to say thanks for your recent updates and to let you know that the latest KCT version available on CKAN is still the rather old v. 1.4.6.6.

Okay, I will patiently wait for your news. Good to know that you still have many new plans about your mods

Still talking about the WIP fund override mode (that despite the bugs I find more realistic than the 'regular' mode), is there any hope that a craft can built without the need of having the full amount of funds for its building, as if no used parts were available?

@Starwaster @severedsolo I am following your cogitations with the highest interest guys. I am afraid that my knowledge of the game is too modest for me to be of much help at this point, but I will add anyway a couple of considerations. During my tests, the inventory was correctly applied to my old vessels when I loaded them; the problem only became apparent when I started editing my crafts; so probably part id gets changed after the craft is loaded in memory and SY's inventory is applied for the first time, though I still don't ger why that happens only with the pod and not with other parts. To the best of my knowledge, the FlightGlobals API is a stock function, correct me if I am wrong, but if you are still looking for a mod that in my install of the game might mess with part modules (and with SY), the first mod that comes to my mind is Kerbal Krash System.

Wait guys, maybe I know what's the problem. The main save game file dates to a few days ago, when DRE was installed, but I am sure that the craft files were saved before installing DRE (and several other mods), which might explain why they are messed uo and why SY malfunctions when dealing with them. I will try saving them again in the new mod environment (or I will re-assemble them from scratch ) and see if SY manages them correctly this time... Thank you guys for your help and sorry for wasting your precious time!