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.

Hi I thought i should provide some feel good feedback. For some reason (probably mental illness, or some other mental blindspot) I had not used Ckan until recently (blush) and managed everything by hand.... (puffs out chest) hence I did it all really badly (was often way out of date). Rather obviously now that i use Ckan, My local KSP is all sweet shiny new and as up to date as i choose to be. (at minimal effort) but I am moving onto the next level, (developer 101, where I fork some mods and use/test those instead. Then develop a mod I have feature specced out (on the downlow/QT/ had on the backburner for a year or two) and I was stuck at "yeah but how do I manage that" (and can I be bovered with the over head to the relative fun of coding, or should I just write a better KOS launch scrip... I am sure I can circualrise at 73k for less fuel).). Then I Found mechjebs example of a dev Mod using ckan... but then I got to your documentation.... https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md and I know you cant test that. (how >effective< is your documentation at fulling its use case.) You can make it definitive, complete, and whatever, but will it meet the self help needs of a naive but informed user is a thing you cant test, as you are no longer one of those, and you don't have any lying around. I am such person (a naive but highly informed user), and yes I am seriously confident and assured i can make ckan meet all my new dev needs. And note the assurance is probably the more important measure than whether or not i later get tripped up by a detail at some point. The documentation has met its primary function of informing a naive user (me) enough to let them proceed forward with confidence and purpose. Its done so (for me, an eats code for breaky developer) so well, I felt the need to comment. (AKA excrements hot, comment worthy work) <me: runs off to play with some code (new toys)>

Edit :AND Note the baviours described happen with Stock Radial chutes when copying to symmetry counter parts BUT not with the equivalent real chute chutes. I have new weirdnesses. I have my manual preset with a 70m chute, with 3.5 m prechute, material kevlar with an autocutout of 0.01m/s. I place one brand new out of the list copy of a stock radial chute. (with 3 fold symmetry) I select my preset above copy it to others. The application of parameters success! dialogs both appear, one when i choose the preset one when I do the copy. I choose toggle info on one of the copies it says yep it is Kevlar, 70 m predeploy of 3.5m but its mass is the default 0.093t sooooo... mischevious me wonders what happens if I copy that strangely light chute onto its symmetry counterparts.... (can I get mass balanced set of cheated underweight chutes?) ( i could call that clever engineering and move on..?) (not yes i can 'cheat' place 6 fold symmetry copy from one to all the other remove the 3 I don;t want including the heavy one that I edited.)(im almost scared to try in case that works) When I click on the radial counterpart that toggle info just claimed was Kevlar.... Nope the RealChute Parachute editor now reports to me that it is Nylon.... hang on.. the toggle info window is still open and yep it says the >same chute< is kevlar. Now mass being wrong might be some algorithm or computation but a chute being both Kevlar and Nylon at the same time.... thats something else. Undaunted I press on (nothing exploded, yet, kerbal engineering must proceed) So I copy to all symmetry counterparts the Nylon and Kevlar 70m chute that weigh too little (0.093t) to "really" be a70m chute from any material. and .... that makes the formerly 70m kevlar light chute (was created by copy symmetry) heavier and "toggle info" window notices it is now nylon and (still) 70m and its gets as heavy as 70m nylon chute would be. The first chute, the one I set the preset on... It according to the info wind is now Nylon, but the parachute editor claims it is still Kevlar. and its keeps its 70m kevlar chute mass whatever its mass really is) And the third chute the one I hadn't looked at yet, It thinks it is a 70m Nylon chute in both the info and editor windows. Bottom line it is not just mass that is behaving weirdly material Nylon vs Kevlar is doing borked stuff too. Also as mentioned but not tested recently I found this "feature" when trying to work out why my supposedly symmetrical rockets flew crooked.

Edit :AND Note the baviours described happen with Stock Radial chutes when copying to symmetry counter parts BUT not with the equivalent real chute chutes. Hence my obv solution is to use real chutes. Again you are correct the code does what it says it does. Does it also recompute the mass of the counter parts? After it copies the size? I have chute on rocket right now which claims it is a 70m chute but claims its weight is still only 0.093t in the toggle info panel while the one I manually edited changed to 0.357 tonne. because I am remembering how to stop assuming. I have verified that the editor has moved the COM marker off center towards the chute I edited and made heavier and away from the ones I copied to that did not get heavier. and they did not get heavier both according to toggle info and the game/VAB COM calculator/display tool. (to make it easier to see (in the linked images below) I put the 3 chutes on the end of two girders so the mass being changed was along way out from center of a light craft.) metrically heavier chute. images of info box and the displaced COM and the craft. (thepoint of the images is that i should be able to get a 70m chute that only weighs the original mass of the chute. So it doesnt matter much how I got there that shouldn't happen (TBMK understanding)

Ill have to check that against how I am using it in the editor as I usually end up copying sizes by hand, because they are not copied using whichever buttons I push. (edit :nope turns out its not size I have problem with being copied but mass see post below. Id always assumed the size was wrong as the mass was wrong.) given that I think I press the copy to others button. I wonder. What happens if I start AT a symmetry counter part not the first one placed. yeah its weird (unlikely) but I m looking for a way it doesn't work for me when the code says it does. Again my problem. Some debug printf will let me marry what I am doing to that code, that is correct code. Then Ill find out why I keep end up with asymmetric chutes unless I do them all by hand. One possibility, is Axle is stupid Axle, whose head is full of grease. another possibility is it is PAD or editor extensions/redux/revisted/whatever. or one of the other umpteen(?) editor mods that I normally use messing with symmetry so that valid code in your mod misses the other chutes.

The code in this function does what it says it does too. CopyToCounterparts() is there a reason it doesn't copy the size of the chutes. if there was one thing Id as user (rocket designer) like propogated to all symetries its size and hence weight. manually setting everyone in the symmetry group to the same size so I can get balanced rockets has been annoying me for a while. Indeed I use asymmetric deployment at height strategies. Open enough chutes to get under say 20ms by 200m then open the rest at 100m to impact. but I always have to manually copy the oversized chutes around my ship. As i need the rocket balanced going up and the chutes balanced coming down.

Ahhhhh, explains everything. Sorry I always assumed that was any speed in any direction. (and we all know what happens when I assume stuff) unsurprisingly the code does exactly what the code says it does,. and the code on my machine will say different things any day now real soon now (tm). FYI: Stock DOES NOT cut the chute that early on splash down. (maybe it used to but my memory isn't what it was.) (trouble is Ive been using real chute for so long stock feels just weird now) What i have done: AKA: where the diagnositic data in spoiler below comes from. I made a teeny modded game with just KOS, module manager, and included real chute or not. details of data recorded by KOS in tight (has wait 0. in it so it records data every 0.02 secs) loop is shown below. With Real chute the craft accelerates downwards from the moment it is splashed down, because as you say the chutes will be cut as its status is splashed and its side ways V is zero. For non small craft doing water drops they results is substantial breakage. Id hate to try and drop say a staged rocket for "water" launch on say eve using real chute. I have had enough drama trying to land aeroplanes with chutes that i wanted to build a water base out of. And they have the advantage of large flat bottoms and wings. So they only "fall" 1m or so. for really large ships. Might just be a no can do. ================================================================= This might play better for splashing down big craft without breaking them. public bool GroundStop => this.vessel.LandedOrSplashed && this.vessel.horizontalSrfSpeed < this.cutSpeed && (this.vessel.verticalSrfSpeed < this.cutSpeed) << probable buggy sugegstion It (or perhaps some related(see below) variant) probably what will be running on my machine in few hours or so. I will probably look for something cleverer that tests for "stopped going downward" so not a speed test but a signed vertical velocity component.) If when I find a good (fast/efficient and useful) choice I will be back. untested Addendum: (I suspect https://wiki.kerbalspaceprogram.com/wiki/API:Vessel vessel:verticalSpeed is not physics version of speed and hence is not as physics would say it is strictly unsigned -ve NUMBERs will be downward velocities.... public bool GroundStop => this.vessel.LandedOrSplashed && this.vessel.horizontalSrfSpeed < this.cutSpeed && (this.vessel.verticalSrfSpeed > - this.cutSpeed) // possible valid code and what that would implement is speed must be less than cut speed sideways AND less than CUTSPEED Downwards. AKA if the ship has hit the ground bounced and is going up at greater than cut speed. The chute would be cut as its positive upward speed is > - this.cutSpeed That is if vertical speed as seen by kOS (logged in the file below) is direct reflection of the sign values coming out of Vessel vertical speed. if not, dot product of srf_velocity with upAxis might yield signed velocity in up direction. (assuming upAxis is already normalized) Once again, ta, love the work, I never fly safe (leave kerbin) without real chutes. postscript: Also regarding my other bounding box related issue. yeah that will be my problem to find. I need to get KOS module on something that crashes and check the (ship:status +vel in real time to a log ) because not every ship does just seemingly some... or it may even be a somewhere thing. or I might get lazy and wait to see if the scatterer or eve update makes it go away. (TBMK scatterer maybe messes with planet surfaces, and the scatterer I'm using but now emotionally/aesthetically wedded to is not yet 1.9.1 compliant.)

ta I will see if i can work that out. (It does seem to only happen when I am in complex game mode doing real missions.. which is a tad frustrating. I was mainly hoping that if I mentioned bounding boxes if there was problem a light would come on.) I am apparently n going to need to get into modding.... And compiling and debugging my own code. My game just went next level. I accept your your next anwser. (it is intended behavior) (I am even open to the idea that fixing it would make the game like too easy and less explosive. (less fun)) but tell you that a place where I will be investigating the physics of chutes once I get my dev environment up to speed. My be i will find something helpful or improving. That said: I suspect my description of what i see wasn't detailed enough. I am also possibly wrong in that it may not be chutes cutting that drops me in the water but chutes failing... I think it says they failed, but that they failed just as all the forces started rapidly decreasing always made so little physics sense, (the physicist in me) kind of just ignored that fleeting displayed text. perhaps... what I am seeing is the chutes deciding they failed due the very fist physics tick of the craft decelerating on water contact? (AKA if it looks like a massive force on the craft so the chutes fail...) Indeed now that i think about it as 'code' rather than physics. It may even be that unity set the speed to zero on water contact and then starts the bouyancy simulation from there?. GAK knows, All i know is the ship behaves in very non (human)physics like way and cuts(breaks?fails) the chute at time when I know for sure the speed in real physics would still be circa 1-2ms/ while the auto cut speed is 0.001 m/s and the chutes also will have just started getting decreasing not increasing forces so they ought to be the opposite of likely to fail. I can however see that the velocity direction may change pretty damn fast once in contact with water contact and chutes don't cope with or simulate that very realistically. basically many hours of fruitful programming ahead of me and white box debugging once I open the lid of the mods code. And stick in some judicious printf... debugging. If I find any useful or helpful I will be back. (once "easy" thing i might do is get a bog std KSP add just kOS, and then create LOG files the speeds and positions on trivial craft at a max rate of data acquisition which will be about once or more per physics tick...) (then do it again without kOS as check the same kind and size of splash occurs. (AKA the chutes drops the ship before bouyancy holds it up.) thinking and remembering hard (back many years) it may actually be stock functionality...) I am pretty sure I am not seeing this flying on gets in contact with water or ground, and the ship moves under a specified speed. specifically I am confident the AND clause is not also true. ( i may have another clue, it may not so much be chutes being cut (AKA I said the wrong thing) but failing due to mistakenly... ? perceived aero forces)) It is a fast thing.... (hard to see but the human physics absolutely infers the following.) Situation: I typically have auto cut speed at absolute mininum, (0.01m/s) such that on land if my ships fall over on a slope the chutes >hang on< and slow the fall over. it is Sooo low that when i land on slopy ground i need to manually cut chutes as simply the side slip on the lander on its legs is keeping them open. AKA my in game observed behavior ought to be the ship is visually at seeming total rest before they cut. When my ships very first come into contact with water. And i mean the instant the colliders touch. While bouancy force is still much less that weight of ship. (thus the ship according to human physics must still be going down) AKA it is still travelling at *very near* constant speed downward (as almost zero water is yet being displaced) the chutes cut. The ship then splashes hard into the water sinking way.... below balance of flotation. Whatever as i said. I will get back to you if I find something more definitive useful measured or reproducible,. TLDR: Ta for you time. Much love for the mod. (ball is in my court.)

i have weird issue that i have perhaps nailed down. (in a way that could be found and corrected) (first let me caveat this with Im running a lot of (mainly mainstream tweak MKS, KAC scansat, EVE, scatterer, ... yadda ) mods not all of which are labelled as 1.9 compliant) (AND some ship configurations with a range of masses and part counts also do NOT exhibit this behavior)(I will start checking the bounds boxes of those when i can) Sometimes when returning from space, and I think its only when splashing down as its never happened on land. The chutes cut out early and drop me from 10m or so. result ship shattering kaboom. Same SHIP, same quicksave, EVA once speed is low (chutes fully open) disassemble a few parts (specifically the engine...) get back in... stage via a decoupler, the fuel tank I was only keeping for its recovery value. no problems.... but heres the weird bit where i may have found what seems to be the identifying part of the issue. 9adn hence makes it maybe a realchute addressable issue) I also am running kOS, and happened to have this script https://ksp-kos.github.io/KOS/tutorials/display_bounds.html#display-bounds lying around and so out of an abundance of curiosity I ran it. The chutes fail not just at about 10m above the water The chutes fail when the lower edge of the bounding box of the radial chute [part] (not just the whole ship)(but it also happens to be the bottom edge of the ship) touches the water. The bound box of the radial chute extends multiple meters below the ship COM or the lowest part. When i excise(remove) both the motor and the fuel tank the chute now 'correctly' checks and cuts when some part of the ship that is not a chute bounding box, touches the water. (which IMO is still 'early' but usually survivable.) FYI: My radial chutes are resized to 70m kevlar (touchdown speed would be sub 3m/s about 2.9)(auo cut is set wayyyyy low at 0.01 or whatever the smallest i can set) I can possibly (with time and effort) manually edit the many meg saved file with circa 100 ships down to something manageable and reproducible if its required and useful. Also while I am here. Is it a 'feature' or a bug that chutes cut out on splash down contact not when the ship has sunk far enough for the boyancy forces to equilibrate?

Hi an FMRS fan here. ( Recycle reuse repair is always fun. ) Also i play in self imposed modes where funds are tight and shoestrings frequent. but i have what may be hard to answer question. (as its vague) Background: What i think i know from playing with FMRS. (not from reading source code yet) I am thinking of making a very different mod that leverages the same core functionality. Id like to check if the developers agree this is a vague description of how the mod works under the hood. FMRS is used : At a time in the game where physics focus "ought to be" (for the plot line) (of recovering a stage) in two different places at the same time... So fundamentally FMRS implements multiasking the physics engine by [*branching*] the game, then later [*merging*] it. (kinda like a version controls system) Where branching is split the game into one simulation with some ships in it. (ones that count... and are later preserved) AKA the "one" staged booster. Then later merging the branch (one ship) back into the game as it that already happened. Details that dont I think matter to FMRS functionality but may to me. I am not sure how they handle or if it handles anachronisms. As I always have flown a stage to stable place like landed/splashed before leaving it. When i jump back to main, the ship is on the fground even if in that time its should not be ... yet. I am not sure what would happen if I flew the staged thing to stable orbit, then jumped back to main. .... Will the stage be retrograded to place so it will be where it is when the main stage gets to the same UTC or not... To implement what i want, use case: for cases such as branch some(>1) ships in the game so as to run ground manufacture at warp and simulate power usage correctly (inc say shadows on solar panels). To do that properly *I* will need to >>schedule<< the merge, to happen later. If I did that with an FMRS situation when i jump back to main the booster would simply not exist until the UTC when it splashed down and then "pop" back into existence then. (im not sure what capability of popping ships into existence by code is..., or whether I will need to pop them into a save file and load it.(which is my back stop method if I cant do the merge in real time.) ) Also noting for my other user stories (such as running base manufacturing) i might need to fork out multiple ships at once and merge them all back later. (including the new ship that got built.) I am thinking, it will likely/possibly require user consent for the merge and some flexibility. So as to be sure the user at some not crucial juncture agrees the mod can save and reload the game with the extra ships merged now. Doing that while a kOS script is running a sucide burn is a bad plan. Although if code can seamlessly pop ships outside of physics range into existance them I am all good. ( Still have more questions than answers about how my code will work.) Vague question basically any advice or help appreciated. That is if I have been clear enough about what I am considering building. (bearing in mind I am not sure what I am building yet I just know which game frustration could be solved if I just forked the universe. Well that and what game frustration I did once solve with notepad++ and forking the universe. (double simultaneous atmospheric reentries). Landed one. reloaded landed the other. Cut and pasted the landed ships into one game. (yes if i get the concept out of Beta, FMRS might want to take it over, and Id be good with one big pile. But for a start its quite a bit different beasty as it will require scheduled merge steps (a needless to FMRS use case complication).) ---- addendum Just happened to run into this oldish post. and yes thats what I am proposing that i write the code for would allow to to be done. (it would require users to do some work) (so my current work around for burn coflicts which is small retro grade and up burn so I keep the perapsis but change when it happens (and a teensy change to where) is I see that several hours out via kerbal alarm clock the burn is usually small. My harder to solve gameplay issue is reentries if I am coming home nearly dry, and don't have the spare dv to change the timing. Currently if I get caught out my work around is to cheat to on infinite fuel break the conflict. or cheat by never switching to the rentry ship until after it leaves the atmo and just let it rail through without physics then cheat an infinite fuel for the 20-300 ms per sec I guess I would have lost on that pass through. The other user story (game situation) is wanting to run a "fair" physics simulation on a production facility. Another one is sometimes, as the mood takes me I like to go for joy flight in pane for an hour or two of game time but unless I scheduled multiple missions to have hole in the schedule several real world days in advance. I can just do it out of game so to speak and revert it but i like to think jeb deserves holiday in the badlands from time to time. I am also wondering if the amount of work it is to implement is easier to think about when its me that will be doing it? ( : P ) How often if happens depends on how the user wants to play the game. I try to when I make play through not waste time... I have umpteen simultaneous missions. mainly I avoid conflicts. But reentires are the hardest as the tend to take while and come in bunches where timing of the second entry is harder to shift and bit flaky in terms of depending how brave(regarding heating) I was bleeding off speed with the first pass..

Context: Question is Regarding KOS code development. So I have a new weird difficulty. Ive been trying to write some code that looked at what parts ships have that are a long way away from the CPU SHip. Indeed i wanted to do that for all 50 ships in the game at the time so I could decide which ones actually had relay parts. This code snippet prints out (and logs see below) that the Variable is indeed a >> Hop AS VESSEL("Hop")<< With or without the wait the LOC local MyParts is AShip:Parts. go bang (but only on new chip each time) and says Code snippet: Error Text: object reference not set to an instance of an object. But it just Printed out that it was a "Vessel("Hop")" . Conclusion? Ok so I'm not allowed to inspect parts of vessels that long way away. (I was pleasantly surprised when i found i could rename them) but the weird bit is if I run the program second time it works for "Hop", then barfs at the next new ship (as I am looping through all of them). Huh? Does anyone know what will happen if I ran the program enough times to get all 50 ships loaded and unpacked or whatever it is that is causing it? I could make another CPU power cycle this CPU 50 times.... : but hat seems way too kerbal to be sane. ============= I have one or more work arounds.... I write save file parser in C++ and do the task I was doing in game outside the fourth wall. Also currently all 50+ ships (except the one running the code) are all landed relays. So I don't reallly need to check. What worries me is just how big a kraken i might summon if I kept unpacking or whatever it is I am doing by rerunning the program. Questions: Am I right in thinking that when I get a Ship via list targets in AllShips thats its parts are expected not to be available? I cant currently as too many ships have the same name. But I if I create a local AShip Vessel("a unique Ship name"). Will that improve accessibility to its parts list? ====== Addendum: I also discovered something else today. if your code goes boom and terminates the entire KSP game,really unceremoniously. As in poof its gone. Its plausible one of your collection objects has reference to itself containing itself and thus forms a DCG not a DAG. That makes things like PRINT Object_that_recusively_contains_reference_to_itself go boom. ================ reading ================