AxleGreaser

Can anyone think of any reason this might happen? Why do the vessels all have no parts? =============== Code snippet declare function FindGndRelays { Global AllShips is 0. list targets in AllShips. for AS in AllShips { Print AS:Name + " AS " + AS + "Parts " + AS:Parts. log "<" + AS:Name + "> AS " + AS + "Parts " + AS:Parts to "BugParts.txt". if isAGndRelay(AS) { AddGndRelay(AS). } } return AllRelays. } ========================== log file output Contents of "BugParts.txt" <Overseer> AS VESSEL("Overseer")Parts LIST of 0 items: <Scansat> AS VESSEL("Scansat")Parts LIST of 0 items: <Bad lands lake> AS VESSEL("Bad lands lake")Parts LIST of 0 items: <Ice shelf tundra ice caps> AS VESSEL("Ice shelf tundra ice caps")Parts LIST of 0 items: <Relays> AS VESSEL("Relays")Parts LIST of 0 items: ========================== Print vessel("Overseer"):Parts (also says the list is of zero length) Print vessel(name of current ship) (does give me the part list) I believe as (I am sure i remember the code working) that I used to be able to interrogate the parts on vessel outside physics range. has that changed? ========================= Also maybe relevant that i have a LOT of vessels ... (just checked 132) ========================= So I slept on it: it plausible that code never worked (parts wer never available unless loaded) and i remembered wrong...

PRIMARY PLAN of attack. Hi I am actually after some advice from a programmer familiar with Remote Tech. I expect I will probably just wind up reading source code to find out but no need to rediscover the wheel if I dont have to. (crosses fingers) (even a hint where to start in which source file would be nice) My goals are very modest, I want to use std Commnet but with some small tweaks, I am hoping RT in effect documents how to hook what I need. (of course it may just reimplement it from the ground) What I need is to tweak how Comnet decides exactly 'where' the antennae relay is, it currently (TBMK) uses center of mass of the ship as a whole. perfection would be approximated by tweaking that to be centre of mass of just the antennae, but just getting it to use just the root part would do. The issue is exemplified by: if i build floating (yes floating) commnet relay station with its CoM under the water level to make the ship stable. It works very poorly no matter how high the mast with an antennae on top is. Designing and moving a ship with its CoM a substantial distance above sea level is just a bit challenging, a bit too challenging ====================== You: Huh? Why? Yes in game, I am indeed making my own ground based relay network (mainly leveraging hills) , but some water passages are just too wide, and that makes making a (quasi) equatorial token ring network impractical. (even for really small values of practical :) ====================== ALTERNATE plan of attack. alternatively if there is way to configure RT to behave almost exactly like COMMNET, I could manually add the very few ground stations where having an aerial effectively on tall mast is required for my gameplay/style. (basically cheat a ground station at a coordinate and altitude, to mimic the one I know i just built(with KAS + tweaks)) ====================================== Edit: A while later: RESOLUTION My reading of the source indicates (TBMK which is very limited) remote tech does not modify or hook Commnet. I cant do what I needed based on it. I could reimplement commnet as Remote tech has, with my one small difference in deciding where the transmitter is (based on part location not CoM) Instead I just got better (cheatier) at construction. I wont specify exactly how as working it out is a reasonable (no spoiler) puzzle. Spoiler a bit: But the parts list of an engineer, KAS, ground tethered stabiliser, 2G antenna 2 PV panels, and two liquid fuel tanks. is enough to build a really (80+m) tall comms tower. It might be Ok (buildable) with one tank, but I liked having one on the ground under the other. (Such tanks dont seem to clip into the ground and explode so very often.) (caveat I suggest once you build tower and sucessfully physics unload it, that you never go back.) Weirdly enough NAV HUD is a beneficial as its NS and EW HUD sight lines are true vertical, and building leaning over towers is bad. And that is enough to reach across the water, with skillful tower placement. kOS and program to draw sight lines from the last relay tower tangent to sea level in the direction of the kOS processor, is also a pretty handy tool when laying out land relays.

Hi, great work, great functionality, will be using it, as is, real soon, I also like the under the hood src code. (I peeked). If anything below sounds interesting/useful feel free to start a dialog. =================== just heads up ... (or maybe an opportunity) ... (or maybe I wont go anywhere with this like last time)(hoping the long term stability of KSP 1.12 encourages me) I will be forking your KML code. I have some things I want that I don't think fit comfortably in your project space, but require either I roll my own KML reader or start from yours. In doing so I may find stuff that your project could do with. Having stood on your shoulders and borrowed your code, happy to give back. One thing I think I have found that may be of more general use is: USI life support makes "Vessel_data" nodes and they get left behind when the ship is deleted. (or explodes into debris) (or at least that happened in my save game, with 41 mods running ...) I will probably need to write some code to clean those up and understand them. I will also be writing some code to find every UID (any thing that looks like one), identify whether that is a known to me UID cross reference type or something new hence potentially something my automagic edit code may not understand. It might help you proactively find anything about the files that breaks stuff when edited. ======================================= I will need the vessel_data understanding as my real goal (step 0) is to: make a fork and merge cli. (think source code repository functionality but for KSP save files ...) Where I can fork some vessels out of a save game (take some fluff (relay network with that)) Do something like land a return capsule on kerbin Then play the other fork (do something time critical like a periapsis capture burn in the same time window as the atmospheric reentry) Then merge the two. (knowing intelligently what to do with fluff (one branch is master and if it fiddled with the relay network it owned them.)(perhaps the periapsis burn was also a relay satellite...) ======================================= Step 1 (comes after step 0 (a spike solution)) would be an actual mod will be to give that a sweet UI like FMRS. (the source inspiration) ======================================= As my final use case will be to have the save file editing occur unsupervised. I will also likely be tweaking the KML parser to be OCD levels of strict on what it expects EGs (it will notice if there is missing tab , or missing whitespace before or after an equals etc. respect preserve /r/n or just /n )(the whole 9 yards)

I am working through my process of producing a development environment robust enough to produce mods. and highly robust reproducible bug reports. Currently my setup does not pass my own quality control requirements for producing release level production code. And the failure for the things I have reported so far to be reproducible means I don't yet meet the external requirements either. =============== So while I have ships that produce the bugs, and ways that I fly them (travelling sideways >autoCut speed when hitting the water means chutes dont cut and thermal event fail (yellow text) happens) that results in that thermal event bug, and logs. I don't have what I can definitively state cant be dismissed as hacks. I also have no idea why there is any problem at all reproducing that effect, or how idetifying the actual lines of code producing the effect (that I changed locally that fixed the effect) does not definitively define where/what it is. But as for me producing definitive reports. My machine has indeed had many local versions of RealChute compiled on it and only one is the original. I'm also finding it hard to work out what I could say more definitively and more explicitly that would allow someone to reproduce what I see than I have already. When I get there with my production environment setup I will be in position to produce robust bug reports. With ships/craft and logs. And descriptions of how to fly them to produce the effects. Because sometimes just a craft file doesn't reproduce a bug you also have to fly it as described. (mainly in my case hands free, apart from staging) but, I take this as a sage warning to myself. until I have worked through my processes, and have a robust development environment, I am taking heed of the above and making sure I dont get burned out before I even start. On reading the above quote, I noted with some alarm, that I had stopped having fun playing the game at all while trying to deal with the chutes issue. So i have stopped doing that. Following your lead, like you, I will get back to the issue when I have the time. Currently I am having fun coding and setting up my development environment again. ============== In the meantime: the best i have got is: If you'd like to see chute "fail" due to a thermal event. (see some yellow writing) Either modify the code so that the chutes groundstop check, also checks vertical speed is > -autocutspeed (see code snippet below for the change i made in my local copy of realChutes) (That is a change that I made: in order to try and make realchutes behave more like stock on splashdown (note it happens only in the last few physics ticks so it is very easy to blink and not see it. As mentioned, it becomes much more visually apparent when splashing down larger ships, as they "fall" further and explode more with real chutes than stock.) or (if that seems like a hack or something) in an unmodified RealChute mod (without changing that line of code). Make sure the ship has a sideways velocity > autocutspeed when it touches the water. (This can happen in real game scenarios when parachuting planes into the water as they have motors running and may be trying to get close to something else already parachuted into the water and be moving sideways faster than the auto cut speed) When that happens then, for me every time, the existing 10C thermal gradient between the chute and the water/air (this.Vessel.externalTemperature) (and the then the sudden huge change in this value this.Vessel.convectiveCoefficient) in the first physics tick after splashdown = true. Results in >300C temp jump and the chute failing. I have no idea why there is any difficulty replicating any of that or even observing that, as that is what the code says it will do. A Change I made locally that Fixes GroundStop issue (chutes being cut, and then (unlike stock) and the craft dropped into the water, accelerating the last few meters from first contact until neutral bouancy) But fixing that achieves nothing, as the thermal bug described below then happens every time. (instead of happening when moving sideways on splashdown) ==== The code below could perhaps be described as a hack, but given the desire for minimalist changes with least chance of side effects it seemed like a reasonable compromise. That change prevents the bug/misfeature of chutes failing on splashdown. It fixes the only aspect of the physics that matters to the game play: AKA excessive temp spikes in one physics tick. It also rather accurately simulates reality that once in the water the chutes are very rapidly the same temp as the water. (it ignores as the current mod does, that the chutes are not actually visually in the water at that time) And that one thing is certain and that that conduction and convection from the water wont heat the chute up a lot. This patch ensures that as a fact These 4 line of code guarantees that while splashed the chutes cant heat up hotter than the water those lines of code are in some sense a "hack" in exactly the same way the following existing in the mod lines of code are those existing lines, prevent the chute from cooling colder than 4K(space temperature). There are i think conditions under which the rest of incomplete modelling of radiation physics could otherwise make the chutes cool to colder than 4K. The is the line of code prevents that unphysical reality from occurring. And it was in going along with that existing paradigm, of bounding things by known constraints, that I fashioned my patch to prevent overheating on splashdown. All changes are what I would describe as minimalist and low risk, as they by inspection usually (in nearly all physics ticks (while flying with chutes open)) have absolutely no effect at all. Both only occur when splashed or landed() Travelling vertically downwards under those conditions is not situation that can reasonably persist for long. (see submarines... for an 'unreasonable' case.) The temp limit code basically ensures chutes remain no warmer than the temp of the water they are immersed in. Which is the limit required that has an effect on game play. So in order to be minimalist its the only part of the thermal simulation that i fixed, as its the only one effecting gameplay. While I could devise a more complex computational analogue, it would not make any difference to game play, and would be harder to diagnose and debug. And have much more risk as patch to otherwise very stable code. I commend my chnages to the aether. Submarines. Stock behavior And unexplored (in detail by me) feature of Chutes in stock 1.9.1 is I have observed heavier than water craft parachute into the water and at least some chutes remain intact while the craft sank to the bottom at 0.9m/s. Attempting to reproduce that may be hard as on my test craft some stock chutes cut and some didn't. I am suspecting rotational velocity somehow counted in decided which stock chutes were cut. many tricksy experiments will be required to fully characterise what stock does, reproducibly. I am probably going to make (by maybe Christmas.. 202x.) make a flying merry go round with "stationary" chutes in the middle and moving ones on the spinning edge then fly and somehow land the thing with chutes deployed... and that is what it would take to 'reproducibly' test stock submarine like behaviors to get baseline to test realchutes on submarines with. So yeah, maybe after Christmas. RealChute Current real chute behaviours is that if any craft touches the water the chutes are either cut due to ground stop, or if moving sideways are failed due to thermal overheating. So realchute behavior isn't a thing for underwater ships at this time. What the behavior of a real chute mod will be underwater is like all its other features entirely up to the author of the mod. All the behaviors described above could be simply defined as correct desired behavior. On the subject of what correct even means: Not behaving liked deadly rentry does or not having a coms black out during reentry are unphysical(realWorld) things but to make the game work for some people they just happen(in kerbal physics). There is no "right" there is only a fun immersive game or not. Making the changes above to real chutes may lead to chutes remaining uncut and unfailed when underwater if the craft is flown with appropriate care. AKA it may be much harder to reproduce stock underwater chutes that I have seen than the other easy things described so far. Also: The concept of some kind of real world underwater "chute" does exist: They are called google:"sea anchor" but realistic ones are nothing like parachutes in size. Submarines are for me an unresolved issue. I don't parachute heavier than water craft into the ocean so in terms of the chutes I use it is a non issue for me. But i flag is as possible problem with any fix of the above two issues. Bottom line: my code on my machine works for me. I am having fun. Sooner or later if the issue persists I expect I would produce craft that strongly tend to produce the bug I described the fixes for. And do so in an environment I can make it clear that was standard and not hacked or borked by the other stuff that i do: But to do that I will need to set up my production code environment. ============ The issues that happen inside the VAB with copy chutes to symmetry parts, is another level of hard for reproducibility. It is not a thing, and likely will never be a thing where i can provide craft file as my experience is it is dynamic interface issue and that saving the craft tends to make it go away. I did however provide screen shots of the chute info window showing what ought to be impossible outputs where the mass of a 70m chute was reported as much lower than it can possibly be, if the code inside was computing mass from area correctly all the time. I have produced step by step reproduction steps and cant possibly diagnose "doesn't happen for me". I have not found or fixed the problem in the code but do have interface based work arounds, so again i run into the trade off between having fun and it all becoming hard work. When i become a much better C# programmer, mare familiar with the application framework structure of the VAB and its callbacks, and better at debugguing I might come back to this one day. until then i will be following the sage advice above and making sure i keep having Fun and not frustration with what I choose to do.

oops (too late) If I wanted to understand what can happen, id check, "provides" and "any_of" in the relationships section of the ckan spec to see which of various approaches would work. https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md

[.. elided confused post where I misundesrtood what i was looking at ..] and for a moment I got very confusalled. ================= Ok so now I understand what Im looking at. This repository is a fork https://github.com/prestja/Kopernicus of this https://github.com/Kopernicus/Kopernicus and the sln in file in both refers to "Kopernicus.Parser", "src\external\config-parser\src\Kopernicus.Parser.csproj", which is in this repsitory https://github.com/Kopernicus/config-parser and if I knew about git modules it would probably all have made sense in the first place. *I* learn new stuff everyday. So What I will be doing in the forks in Axlegreaser/Kopernicus etc is work out a procedure to get the project built with relative ease on a random new machine. AKA lower the barrier to entry for contributions by new people. (initially me)

Edit: ok. So I am an idiot who still didn't RTFM. Now I've got past wanting to write code and wanting build instead. I have found the build.ps1 script and hey... (<puffs out chest>, the changes that I made compiled first time. I wonder what will happen when i run them first time.) ========== So Ive been looking at forking the CKan repository to flesh out some CLI tweaks. (becoming more minimalist all the time) I ran into this. If I checkout the CKAN repository change nothing and simply click on the solution file and let >>>Vis Studio 16<<< open it (on my machine) then VisTudio hangs while opening the solution. My workaround is below, how to best to fix it is no freaking idea. (specifying which of Vis Studio 15 and 16 must be used for development of ckan comes to mind) or documenting how to use the wrong one and not to checkin its sln. ... ============== in spoiler below is the Diff file I get after cajoling Visual Studio version 16 into opening the solution file. I do that by opening Vis studio 16 explicitly from start menu. Then once its open choosing the solution file but checking the box and not loading the projects. Then loading the projects one at time manually ignoring the exceptions/errors that throws in the GUI Saving the solution. (exit VisStudio16) Then Diffing the saved solution file with the repository. That produces this spoiler below (which I suspect for people who understand solution files will be diagnostic. (where diagnosis == "bloody Microsoft, incompatible with even themselves: ... again.")) TLDR: is Debug_NetCore/Release_NetCore is no longer a thing on the RHS of the equals signs in solution files. (whatever the heck that means) (welcome to the latest barrier to entry generated to maximize scope for profit margins.)

oops fat fingers.

ta. I'm good to go now. (be back if i do something that seems useful) Well i was being wrong headed somewhere. I'm not sure how but I had overlooked the idea that CKan would have a CLI. (that is what i get for not RTFMing) And yes my post build stuff will be interacting with a CLI Ckan.... in some way Question: Can the CLI specify which install path it should operate or do the commands only work on the default one? (This appears to be the case ) dont worry answering, I'm getting the source it will tell me, but if thats what it does adding that capability seems like it would be useful, to me, the CLI seems stuck back in the days(mindset) when you didn't manage multiple instances. BUT i might just try adding some features to my local version of cli ckan to make my life easier. ckan cache flush ModName // or some identifier like that than then just flushes the right stuff. (not using keyword clear in purpose: reasons see below) ckan In Instance_Name refresh Modname // which also then causes modname to be refreshed (uninstalled and reinstalled) in the specified instance_name // similarly not re-using keyword "KSP" due to how the CLI help currently works. Suggestion: if "ckan Help Cache" printed out exactly what "ckan cache" does. Then users could type "ckan Help Cache clear" to see if there were more options such as clear [but which mod]) or that was it and it would now do something specific like clear everything. The idea that you get help by typing ill formed commands and that when you type formed one (A thing you don't know for sure in advance) it happens rather than telling you "yep that does this". Seems ill formed to me. (I expect i will come back with source code for that after a bit, unless someone else says heck yeaah and does it first.) maybe refresh is what replace does? (downloading source now) [-ta. I'm good to go now. (be back if i do something that seems useful)-] Um... err I just forked/downloaded the source clicked on the sln and it didnt open... (it hung up with 6 of 7 project open... weird?) nvm if I open it without projects loaded then load then it doesnt barf... weird -ta. I'm good to go now. (be back if i do something that seems useful) Addendum: progress rpt: (from reply to this post) yep, having seen the code it will. Not what id imagined, a way more OO feel. probably, I hadn't found that feature of the CLI yet. yes this does what i needed: The switch --ksp likely is one of the things i wanted/needed but hadn't found documented. I am also finding it unusual(non intuitive) that ckan --help clean while ckan clean --help does something quite different.

As is usual for me I seem to be doing something weird and hence, Im on my own not seemingly walking a well trod path. (perhaps im just being wrong headed, in what i think my goals are) I am trying to use Ckan to manage not only all the mods I install from the net, but also any I compile and build locally. I have seen how Mechjeb2 has a repository dev versions of the code. I have taken that as my template and made my own local equivalent for any mod/fork I build locally. used handy hints from that like making sure it tells my lcoal Ckan install, that my local mod is incompatible with the public mod its a private fork of. as hint for anyone who thinks heck yeah I wanna do that: the required by ckan URL's can begin "file://"<pathname> which then gets stuff off the local file system rather than the net. What I am asking for is guidance about, what minimal things I can update in my local_mod.ckan file or the locally built local_mod.zip file stuff that will prompt ckan to download a new copy to the ckan cache. For most users of ckan that detail left to developers, so ive failed to find that definition in the documents that i read. At this moment I am trying avoid version spam, for the many small dev cycles I usually work and test in so Id like to find the smallest easiest changes that would cause my ckan.exe to think it needed a fresh download to update its cache. Currently I (blush) copy what I build into ckans cache directly. Then remove and reload the mod I want to test a new build of. Id like something less hacky more automated but least amount of extra leg work. I want to avoid having to make all the ones that would normally naturally happen anytime a mod made new full release. Ive read the new release process for say KOS and its too many steps I am going to be more automated than that. My ideal goal is if I press build in my dev environment, Ckan notices and offers to update my locally built mod if it in the current KSP configuration. So Ineed to find out what minimal thing will cause ckan to do that. My second best goal is removing and adding the mod in ckan triggers it fetching the new built mod into its cache. id prefer not to have to make my postbuild script say reach into the ckan cache and delete the old version. (EG: Currently i took out the ckan cfg shas because that way there is less work in building and running something, although if need I can make post build scripts etc to compute them and (edit/modify) update my localMod.ckan file.)

Well in that case i wont get back to you with patch to fix the observed behavior issue. Well no that not the case, That is only a potential issue in my actual campaign game (this patch work has been done on brand new install) for just that kind of reason. the comments above are from observations of code executing in a clean install with no to zero other mods running, in sand box game, with the behavior being observed being the first flight on any ship in the game. And the observation that this.Vessel.convectiveCoefficient changes drastically on splash down is trivially confirmable. (it is both expected and actual behavior) (Splashed ships have (and should have) a comparatively huge value for this variable.)) That that (a large temp rapid temp change) would (from simply reading the code) is the expected behavior from reading the code, and then that has been confirmed by observation ( added Debug.Log() statments ) does is observed to produce a temp spike of +300C on splash down is also trivially confirmable. but yes "but this mod is not in development anymore." and yes it is always your choice whether to pull a claimed to work patch into your mod or not. Well yeah any patch I provided would have the problem it was saying it solved included. But i am not sure I understand what not in development means. Every craft falling into the water under any conditions, (with chutes open) experiences a sudden change in this.Vessel.convectiveCoefficient every craft where the temp of the chutes was just below ambient which given the math will I think be every craft as it only has simple radiation convection model where that is the equlibrium condition. So to be safe every craft that has had it chutes open for more than few secs. Will when it touches the water have thermal gradient of some degrees between the chute and the outside world. In the first physics tick after the craft touches the water the temp of the chute will spike dratstically upwards to be much hotter than ambient.) For a small craft this produces the survivable effect of cutting the chute earlier than stock chutes. For larger craft it causes breakage, when the chutes suddenly heat to over 600C (internally known temp variable this.chuteTemperature) on contact with water. Demo Craft file that will launch hands free at the sea supplied (will be linked here) shortly when i pick somewhere to upload it. This craft has a particularly long tail fin so it is clear when the the craft visually phsyically touches the water. (is when the chutes are reported to fail) =========== as previously mentioned this is about an issue of the chutes on the very first physics up date when the ship is reported to be splashed down. the chutes are in no real sense under water and the issue is when the chutes are failed, the ship then falls the remaining distance into the water and parts are destroyed. They are not underwater when something happens. Do note I have not only printed out that value but basically every value in the computation and observed them all change, the one that changed drastically and caused the 300C temp spike (in a single phsyics tick) is this one this.Vessel.convectiveCoefficient Also Nothing is really "under water". This issue is not about chutes behavior "under water". It is what happens when ships with chutes first physically touch the water. The convectiveCoefficient is so enormously large that it computes the amount of energy to be transferred by the 10C temp gradient and it is enough to raise the temp of the chute by 300c. I know a 300C temp change being made by 10c Temp gradient makes no sense it is however what the code does. That claim is not based on my code or the mods it is based on me (bench testing) doing the thermal physics (using the formulas your code uses) of what goes on using the numbers your mod uses comparing it with what your mods function then computes and concluding yes its simulation math is wrong when convectiveCoefficient is so very high and the surface area to volume ratio so very high that, in the real world, it would have come to thermal equilibrium in much less time than one simulation timestep. but yes it is always your choice whether to pull patch into your mod or not. So it is irrelevant whether the bug is real or the potential patch works. My code on on my machine works, I personally have no problems. Thanks for your time . and Always enjoyed and long used the mod, thought i might give something back and fix a glitch Ive noticed as a player for years but lived around. cu.

yeah sorry, the code does indeed refer to it as convective (this.Vessel.convectiveCoefficient) flux of the water on the first update after splash down that value is hundreds of times higher than the air was that in turn drive the temp quite physically unrealistically through the roof, in that one update it raises the temp of the chute by 300c due to the 10C or so diff in temp. So to be clear... contact of a chute (at=303C) with water(at 314C) causes, ... according to the code, the cute to heat up to > 600C and then the chute fails earlier than similar chutes in stock do. This causes larger craft to break on splash down where they would not in stock. I know that the temp changes makes no RW physical sense, it is however what the RC simulation code does presently in KSP. It does that because of the huge thermal flux (caused by Modelling inaccuracies induced by) the sudden massive value of this.Vessel.convectiveCoefficient. I have a relatively trivial patch that removes (works around) the problem, but i need to play test it some more. AKA: Where to from here? I will be back a bit later... probably with a functioning pull request.

FYI: I looked through the revision history and didn't find what it used to do that used vertical velocity instead of only horizontal. I have implemented some (2) patches in my local version. 1 The vertical velocity described recently change does do what it looks like it might but it is not enough to make real chute behave more like stock on splash down. (and hence break large ships less.) once I started paying close attention the chutes are not actually cut but are (briefly) reported to have "parachute has been destroyed due to aero forces and heat" judicious Debug log code in parachute.cs tracked the odd cause of that down too. When ships with chutes touch down in water their chute temp suddenly spikes to from about 303k to >6ook when ambient air temps are reported at about 313K... That turns out to be because the conductivity of water is so high that the math assumes a vast 2000 times as much energy flows in the chute in the next clock tick as in the past one. (to be clear the simulation math computes the 10 degree thermal gradient produces a 300k temp change in one physics tick) AKA one of the assumed approximations used in the temp calculation math was violated and thus gave unreal results. 2 The cheap fudge solution (works near enough on most planets...?) is to clamp the chute temp to no warmer than environment when splashed. (A "better" more generally robust solution would be to also if the chute was initially warmer than the environment clamp it to no cooler than the environment at the end of the calculation and to only do either if issplashed() is true.) (the later is because in very low conductivity environment like high atmosphere or space being hotter or colder due to thermal radiation is also possible. ) I will be testing out the code I have, in my main game, and get back to here if sometime I decide its solid.

Ta I now have slightly different problem then. How and when do outputlog.txt get created. I went back to checked i hadn't typoed || fat fingered or something and my outputlog.txt was different. :\ It now reflects the no worky state I got into after this step Launch KSP with the KSP_x64_Dbg.exe and check that you have "Development Build" in your lower right corner when Id did that it said dialogBox["Failed to load Mono"] Now the outputlog.txt file says that too and nothing about unity. Given my instructions hadn't mentioned installing mono yet, I decided i was a long way up a creek not too long after that. Esp when the official install mono on windows instructions that I found and followed also failed and required rebuilding it from source but.... And google suggested (by the guy who made the breaking code submission) reverting things (not even recent top of the tree ones) in the repository to fix it. I can read not welcome here signs when they are writ that large. (So for me, Im at not going to mono develop this month.) My Outputlog.txt now says in its entirety... "Unable to load mono library from F:/games/KSP1.9.1/KSP_x64_DBG_Data/MonoBleedingEdge/EmbedRuntime/mono-2.0-bdwgc.dll". It even still says that after When I run a normal KSP install in different directory, it doesn't write outputlog.txt at all. Should I make KSP crash or something? (if so: then as some people do run multiple versions of KSP maybe the instructions need to point out the version number is from the most recently crashed version, or whatever it is that makes KSP actually write output log. ?) Currently I just gave up on proper debugging and will compile and use log debugging. (so far that making headway, even though I compiled against the wrong unity apparently. I'm guessing the bog std calls I required for my DLL didnt change.) (edit: nope checked this out, and when I set the references in the Vi Studio project i linked against whatever was in the game install not the unity I had installed on C drive.) Pls note (as it may be unusual): a reason i dont have monodevelop as mentioned above is I was following those steps while having no DEV environment at all. No vis C, C++, no, C#, F#, GTK, no mono, dont even currently have GCC. nuthin. I am just getting back into development on a clean new machine. So far dont even have a linux boot. I now can find it too. The trick for people (if any coem after me) that don't know any French is to change the selector at the top from "tout" to your specific number as close as you get then all the patch variants p# show up for that version. ( Tout is a very versatile word in French — you'll generally find it means “all,” but you'll notice different meanings when you see all its forms. This little word can be used as an adjective, an adverb, a noun, and a pronoun, and all with varying forms. ) but in this case tout seems to have meant something like "just show me the latest of each kind of all" not actually all. I suspect the later patch variants might be considered strictly better than earlier ones (only change is fewer bugs in the inside). Well thats what it would mean if they were my creations. Self help I will be doing. Poking around more trying to find out how to get currently generated outputlog.txt to get it to tell me what my real installs of KSP recently made from installed exes claim their unity version is. (edit: see below, KSP 1.9.1 juts wont do that (write unity version to output log) anymore apparently) I am instead moving on to printf style debugging. Although I am having real hard think about using KOS for some of my whitebox development tool debugging. If I hack a local version of it I can expose any damn thing I like to the KOS scripts then changeup my debugging printfs without reloading the entire KSP. That should help with the annoying little bugs like what happens in this corner case (shortunsual condition of temporary duration (recent eg during actual splashdown). ============================ edit more info that Ive found And yes it cant load it (MonoBleedingEdge/EmbedRuntime/mono-2.0-bdwgc.dll) from there as it is not there: MonoBleeding Edge is beside not under the link KSP_x64_DBG_Data -> KSP_x64_Data My Outputlog.txt now says in its entirety... "Unable to load mono library from F:/games/KSP1.9.1/KSP_x64_DBG_Data/MonoBleedingEdge/EmbedRuntime/mono-2.0-bdwgc.dll". and when I put soft link link in to make that work (put a MonoBleedingEdge where the code/errormsg expects it to be.) Its (launching KSP_x64_Dbg.exe) output_log.txt now says: (in its entirety) SOF. mono: function mono_unity_seh_handler not found mono: function mono_unity_set_unhandled_exception_handler not found mono: function lookup failed EOF Which gets me back to wanting to get some mod coding wins using debug log style debugging. Also that will get me more up to speed on simple stuff. me /out on proper debugging capability, for now (I will go old skool, its fail safe and fixable by me) yet another: Addendum Apparently .... outputlog.txt is a pre 1.9.1 thing... BUT it still can get updated anyway when I broke it trying to debugging. (but it seems never to contain the current unity 1.9.1 version identifiers anymore. The output log text file with the old unity version that i had (A few posts back) may have been from a carry over install I had for short time of 1.5.1/ (eventually i decided the disk data corruption) on the computer I salvaged it from was too much to bear and moved on.) hence it being olllld would have had an old unity install version number. Looking around in my much larger player Log (that1.9.1 creates), I have not yet found the unity build number identified in the same way.

Im trying for a 1.9.1 install and following the instructions... My unity engine is reported to be In output_log.txt .... (and its on line one...) Initialize engine version: 2017.1.3p1 (02d73f71d3bd) But engine 2017.1.3p1 doesnt seem to exist anywhere is eitehr location linked in OP Unity installation (or here There is a P4 ( Patch 2017.1.3p4 ) Sooooo... as p1 is not there.... I am going to hope P4 is just better but equiv version if the P1 that i have? help? maybe. (For future reference (other posters) if i dont come back that worked) ============= wait up. <misleading derp .... elided here> ============== double wait up Nope I derped.