gap

I have no experience of modding this game, but I know how to flip a 3D mesh once it is imported in Blender or any other 3D editing program. As I read, there is a Blender plugin for importing/exporting directly from/to the KSP 3D format, so I guess no problem here. Yes please!

Okay for a start I will install the mod and I will play a bit with it (though I have to learn how to build an airworthy plane first lol). One last question: have you tried flipping the chute model over the axis of its deployment? I know this fix might sound too obvious to actually work... but you never know if you don't try.

Wait, do you mean that KSP (unity) reads dds textures upside down, so they need to be flipped in order to look okay in game?

Hi linuxgurugamer, I have read your PM, can you please be more specific on the following point? Namely: which chute placement(s) relative to the horizontal plane, cause the chute to deploy backwards?

Okay, that makes sense. Luckily I have not built many parts in my career: I mostly recycled used parts from previously launched rockets, so I have not lost too many generation points...

Thank you very much sevredsolo! If I replace SY 1.1.2 with SY 1.1.1, will the generation # of already built parts be updated automatically to reflect their actual generation, or only newly built parts will benefit from that?

Just a couple of notes for @severedsolo (in case he decides to bring the last little fixes to his mods before handing them over to someone else), or for whoever will succeed him in taking care of ScrapYard/OhScrap! 1st note, I must confirm the reports below: I am using KCT v 1.4.6.4, SY v1.1.2, FT v1.0.0.1 and OhScrap v 1.6.1.1 on top of KSP v 1.7.0 and I have no part nor life support mods installed. 2nd note, the safety rating calculation seems messed up. If I assemble a craft in VAB or load a save one, OhScrap's windows always gives me a safaty rating of 0 (horrible). The get the actual rating I must leave the craft loaded in the VAB, exit and enter it again If you think it helpful, I can upload here the full list of my mods, the most recent game logs and save files and I can describe how to reproduce the said bugs.

Hi @severedsolo I have started playing the game and using your mods just recently but I want to thank you all the same for all your work on them and for the patience you have demonstrated into listening and helping fellow players and forum members. Though being a newcomer here, I have been reading old posts and threads and I must admit that the dedication demonstrated by you and other modders over the years, is commendable. The time you spend with your family and/or doing what you like is always well spent. I wish you all the best with your next projects, and I hope to read your comments here from time to time.

No, it is not about formats. Some textures are just flipped upside down, which BTW seems to be the correct orientation for TR + the latest version of KSP, but some other textures (from other texture packs) are not, and they look wrong in game. The same goes for space suit textures as well as kerbonaut head skins

Thank you shaw. I have had a closer look into the head skins of several old and new texture packs, and what you have said obviously applies to them. What was confusing for me is that some textures packs have their textures flipped vertically (like TR's standard textures) while the textures of some other packs are not, but I think this inconsistency has nothing to do with a change of UV mapping method between TR and TRR...

I for one would welcome the introduction of a more articulated and realistic damage repair system to KKS. I have no experience of KSP coding that I can share, but if any custom 3D model is required, I would gladly assist you with that.

Thank you very much shaw, your answer makes perfect sense to me and it solves all my doubts! I have two last questions if you don't mind: I wanted to convert some skin packs made for TRR so to be able using them in TR, but I have noticed that head and suit textures made for the two mods look quite different. Is this because they patch the game in different ways, or because the UV mapping of Squads's kerbal models has changed since KSP v1.3.1 (the last one officially supported by TRR)? Whatever is the answer to the question above, are there any templates that I can use for manually rearranging TRR textures so to make them to fit the TR texture layout?

Hi @vardicd, thank you for tagging me in your notice, and sorry for the late reply... I don't know how, I had missed your post until today. So far I only tested ScrapYard in career mode, and since I was mostly busy testing mods rather than actually playing, I never made much progress in game. That is to say that, with only a few parts available in VAB/SPH, I never noticed any significant slow down or stuttering while there, whether the WIP fund override option was enabled or not. Things might change in the near future, as I am starting to enjoy the game balance of my current mods. As I progress in my career, I will let you know if I find anything that can confirm or disconfirm your report. Hopefully one day @severedsolo will support and optimize the WIP feature we are discussing, because I think it provides a much more realistic gameplay than the 'regular' SY mode

Hi @shaw, @HaArLiNsH, and all the KSP forum members, I am a new KSP player, and after messing with some other mods, I am now looking into face and uniform texture replacement. While digging in the forum I came across Texture Replacer and Texture Replacer Replaced but how come, despite its name, the latter seems lesser updated than the former? I am probably posing a silly question, but what's the difference between the two plugins, and which one would you recommend with the last KSP version? I know they are two different mods but their names seem to suggest a direct genealogy, thence my confusion...

@EnzoMeertens Quick update: that's weird, but after closing KSP and running it again, the above MM warnings are gone. Well done!

@EnzoMeertens I have just tested your latest release of KKS (v0.4.7) over KSP v1.7.0. Module Manager still throws three warnings: [WRN 2019-04-26 18:58:19.847] more than one pass specifier detected, ignoring all but the first: KerbalKrashSystem/Plugins/KKS-mods/KerbalKrashSystem_Leak/Configs/KerbalKrashSystem_Fuel_Leak/@PART[*]:HAS[@MODULE[ModuleKerbalKrashSystem_Container]]:AFTER[KerbalKrashSystem]:FOR[KerbalKrashSystem_Leak] [WRN 2019-04-26 18:58:19.847] more than one pass specifier detected, ignoring all but the first: KerbalKrashSystem/Plugins/KKS-mods/KerbalKrashSystem_Repair/Configs/KerbalKrashSystem_Repair/@PART[*]:HAS[@MODULE[ModuleKerbalKrash*]]:AFTER[KerbalKrashSystem]:FOR[KerbalKrashSystem_Repair] [WRN 2019-04-26 18:58:19.847] more than one pass specifier detected, ignoring all but the first: KerbalKrashSystem/Plugins/KKS-mods/KerbalKrashSystem_Science/Configs/KerbalKrashSystem_Science/@PART[*]:HAS[@MODULE[ModuleScienceExperiment],!MODULE[ModuleKerbalKrashSystem*]]:AFTER[KerbalKrashSystem]:FOR[KerbalKrashSystem] for the rest, everything seems to work flawlessly. I just crash-landed in the Mun-landing tutorial mission, and I got 25% damage to the engine.

Hi @severedsolo and thank you for this nice little mod, I am just writing to note that since the 2.1 update, the mod link on CKAN points to the Flight Tracker thread, not this one.

Good to know that! I was actually sure I had read somewhere in this thread that [x]Science! has the same problem with Oh Scrap!\ScrapYard as ScienceAlert ReAlerted, but I probably misread that piece of information...

Well, talking in my own defense I had warned you that I was going to think out loud lol, and at the beginning I asked you if OhScrap was still based on the considerations contained in that old post, receiving as an answer something that resembled an "essentially yes, with some tweaks" Okay, so if I got you correctly the pre-checks are used for relieving the CPU from having to check all the parts for failures, when (most of the times hopefully) no failure is going to happen anyway. If so, why not testing the overall failure chace for our crafts over the following probability: 1 - [1-p(1)] * [1-p(2)] * ... * [1-p(n-1)] * [1-p(n)] rather than this one: [p(1) + p(2) + ... + p(n-1) + p(n)] / n ?

Sorry, my bad I understand that. If you like the features I have just suggested just place them in your todo list, in case one day you will feel like working on a major revision of OhScrap!, otherwise for what they are worth just... scrap them One more note: You are right in stating that, given a sufficient number of eventualities where an event can happen, even the tiniest chance of it occurring at least once becomes substantial, but the way you are calculating this probability is wrong though. In statistic therms, a probability bigger than 100% or 1 (i.e. the certainty that an event will happen), would be a nonsense. The probability of an event occurring at least once is actually calculated as the complement of the event is never occurring. To give you an example, if a rocket is composed of n parts, each with a failure chance of p(1), p(2) ..., p(n-1), p(n), the probability of each part not failing during a failure check will be 1-p(1), 1-p(2), ..., 1-p(n-1), 1-p(n). From there we can calculate the overall probability of no failure happening at all as: [1-p(1)] * [1-p(2)] * ... * [1-p(n-1)] * [1-p(n)] and subsequently the probability of at least one failure happening during one check will be equal to: 1 - [1-p(1)] * [1-p(2)] * ... * [1-p(n-1)] * [1-p(n)] If, as in the example you had chosen, all the parts have the same failure chance, the formula above can be simplified as 1 - (1-p)^n where p = failure chance and n = number of parts. Using your numbers (p = 5%, n = 50), this gives a 91% probability that at least one part will fail during a check, which is of course very high. In the chart below I have plotted the overall chance that one craft will suffer at least one failure during one check, for different p and n values: Obviously those are the type of curves we can expect for an exponential function, but for values of p equal or lesser than 0.1% and values of n equal or lesser than 100 the resulting probability could be approximated by a linear function. If you kept the highest (1st generation, 1st use) failure chances of individual parts low enough , the pre-check (where you average those chances and roll the dices to see if any failure will actually happen or not) could be skipped without involving an abnormal increase in the actual failure rates of complex rockets. The advantage of doing that would be obvious since, within reasonable limits, more complex rockets and airplanes being more prone to failures, should be expected. This has a con though: due to the low number of parts used and to the short duration of missions they are usually involved in, early rockets would have a very low failure rate, which is neither realistic nor fun. Of course we can speculate on the many workarounds we could use to address the issue above; the one I have thought about, is starting with relatively high part failure chances, and dividing those chances by a factor that would reflect the technological advance achieved at any moment. This factor could be calculated as a function of total built parts, total flown and recovered parts and total science points spent in the tech tree. By the time we would start building rockets of some complexity and embarking in missions of some length, the factor would have become high enough that even a space air/craft composed of many mid-rate parts could be launched with some chance of accomplishing its mission. What do you think?

Whether or not you have actually launched the rocket? I think ou loud here, so forgive me if say something stupid or if I seem to criticize your work (which, by any means I am not), but I believe that engines are more prone to malfunctions when they are working at full throttle or during/immediately after their ignition; parachutes are more likely to fail in the moment they are deployed and they have to endure a strong deceleration; fuel tanks and aerodynamic parts are more subject to creaking while or after having been exposed to strong forces and high temperatures; gaskets, electric insulators, etc. are more likely to melt down and to cause leakage or short circuits, when they are exposed for a certain amount of time to high temperatures. Some of the failures above might also happen while parts are not active, and then reveal themselves when parts are activated. How hard would be for you to grab some (very much) simplified physical parameters from the game and applying them to your failure calculations?

Okay thanks, I think I have got the picture now but I have a few more questions if you don't mind How does this 10 seconds / 5 minutes roll-interval rule exactly works (when in the atmosphere)? Are failure chances checked also for currently inactive parts? Are physical factors (such as temperature, mechanical stress, ecc) and/or critical steps in the working of some components (i.e engine ignition, stage dropping, chute deployment, etc) also taken into account when calculating overall and part-specific failures? If you did, you could probably apply a more or less constant failure interval...

Okay, so if I got you correctly, the number of rolls is not limited, i.e. the longer a mission will last, the more likely one or more failures will happen. Right?

In other words, on loading a vessel you calculate its overall failure chance by averaging the failure chances of its components, then you roll the dices and check the result; if the check fails, no failures will ever happen during the current mission; else, every x in-game seconds (variable depending on circumstance and part) you keep rolling the dices over the individual failure chances of currently active parts, in order to determine which one will actually fail. If a cycle of dice rolls fails (i.e. all the currently active parts have been checked and none has failed), your code waits until the next roll and then checks again if one of the active parts fails. Is that correct?

Hi @severedsolo, I am a new KSP player and already a fan of your mod. I have a few questions/remarks relative to the failure system you have applied if you don't mind, but before I start exposing them I wish to know: it the current version of the mod (1.6.1.1) still based on your considerations below or something has changes since the last July?