Jump to content

Starwaster

Members
  • Posts

    9,282
  • Joined

  • Last visited

Everything posted by Starwaster

  1. @gap yes FlightGlobals is stock. And I’ve duplicated this without Krash. @severedsolo maybe there was a time when it made sense to reload the modules when switching the inventory but the more I think about it The less sense it makes. The only two times those modules should be loaded at all is once from prefab when a part is spawned in the editor for default values and when a craft is loaded to grab persistent values that might have been changed. Some modules won’t do well with reloading at arbitrary times such as ModularFuelSystems/RealFuels where it obliterates custom tank content. As for FlightGlobals I’m still trying to get a handle on that one. If I ONLY let Scrapyard work automatically or at least only Quick Apply it doesn’t seem to have issues...
  2. @jpinard Realism Overhaul is a collection of mods designed to make for a realistic experience. In fact Real Solar System is one of the mods that is required for Realism Overhaul. Some mods are only suggested; others are required.
  3. @severedsolo This seems to be where it starts having trouble. 696639599 is the id of the part that was recovered and that is apparently used to track it. But FlightGlobals changed the id of that part (in the editor? really KSP??) and so I'm thinking that SY is understandably getting confused seeing as how 618416144 isn't in inventory.... FlightGlobals just pulled that number out of the air. This started happening when at some point I clicked Select on the inventory window. It's happened that way three times now but I can't get it to do that reliably. [FlightGlobals]: Part persistentId changed from 696639599 to 618416144. Vessel PersistentId 0 [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. Rockomax64.BW:618416144 I can get you the full logs from that sessions later. Also a copy of the persistence file BEFORE entering the editor and after exiting it. Comparing the two might show what's getting corrupted
  4. I like the Tundra parts - they don't have an official RO patch for them yet, I don't think. But the author says it will be compatible 'soon'
  5. Ok @severedsolo so I just reproduced @gap 's problem on a new save. So I created a brand new minimum install with just KCT, SY, OS and their dependencies and made sure I couldn't reproduce it in just that environment. Then I put in Deadly Reentry and.... still can't reproduce. I think that I do see the error you mentioned on parts that didn't explicitly have DR's module on it but I tracked that down in ScrapYard's code and that's something you're doing exception handling on so the worst that should happen is that SY doesn't try to load that module in right? And I don't know if this means anything but I only saw that error if I explicitly tried to apply a used part to it... (as opposed to being set on automatic) Anyway, from a Deadly Reentry standpoint, if I can't reproduce it with just DR then I should probably forget about it except that if I'm using SY too then I might have to poke at this some more. Probably start adding more mods back into the mix until I find something that breaks things. I'll let you know if anything happens.
  6. If it's KSP 1.7.2 then Kopernicus will not load. It is version locked. EXTREMELY version locked. Major, minor and revision all have to match or it will not load. Have to wait until he releases an update for it.
  7. ksp.log can be found in your main KSP folder. It will probably be sufficient. (there is another log file but it might not be getting generated in more recent versions of KSP unless run with a specific command line option but don't worry about that right now) In addition to the log you should also submit ModuleManager.ConfigCache from your GameData folder Any files you submit must be generated during a time period when you are actually experiencing the problem. You should run the game up until the point you experience the problem and then quit the game. Do not paste the log file in the forums! It and the cache file should be uploaded to something like DropBox and the link to the files provided here. (you can zip them up if you want)
  8. Oh gawd just the thought of that makes me want to cap the minimum at 100%
  9. I'm really not sure how to answer this... the actual heating takes place in the stock KSP code since about KSP 1.0 The sound and effects are limited to metal being wrenched and rent asunder by high G forces.... or the visual appearance of things catching fire and burning (which needs that heating aspect you mentioned) Oh and screaming. Kerbals screaming if you send them out of their ship during reentry. The config files also do some specific temperature limit rebalancing so that things don't all have the melting point of tungsten. I suppose you could delete those. Except that then when the plugin runs it will put it all back on the chopping block and will coldly and uncaringly slash all your parts until they have the sturdiness of aluminum sheeting. And you can't delete the plugin or you will lose those sound effects. So.... no. You can't.
  10. No. It's outside the GameData folder so it's inaccessible. It doesn't get processed into a set of ConfigNode s.
  11. Did you teleport into space or did the planet disappear? Because it kind of looks like the planet broke... Either way you need to post some logs.
  12. No, because the pull request hasn't been accepted yet. The file changes mention still exist ONLY in the pull request. It is possible to go through the pull request file by file and download each one. (click Files changed, then next to each file difference set, click the three dots ... and on the menu that pops up click view file. It will show you the actual patched file. For best results right click Raw and then click save as
  13. I'm not seeing anything in the logs that you posted that really implicates Deadly Reentry. I do see that any mention of ModuleAeroReentry is missing from your craft files and from your save files. Which would make sense if they predated your installation of Deadly Reentry, but then it means that those aren't files that reflect your current installation state so I don't think I can get any useful data out of them.
  14. If they want to they can but are you sure that's really the problem? There are going to be a lot more parts not having that module explicitly patched in. Looking at one of my most used installations, only 329 parts with MAR patched in. There are a total of 1567 parts listed in the MM cache. Installations with parts from newer mods will have a greater proportion of unpatched vs patched parts (because the module adds itself in at runtime, I usually only create a patch for a part if it requires special handling such as space plane parts) So how is it that @gap is only having trouble with the Mk1Pod? That just doesn't make sense to me. He should be having the same problem with lot more parts than just that pod.
  15. @gap @severedsolo Deadly Reentry adds that module to a part's prefab at runtime for any part lacking one. It's always done that for the years it has been in existence so I'm not understanding why it's a problem now. Just loaded up KSP, launched and recovered a Mk1 Pod several times and this is what I get. SY Inventory shows a Mk1pod. SY window shows 3 previous uses. I click 'Quick Apply' . Entry in SY window goes away. The Mk1 Pod's PAW now indicates that this part has three previous uses. Imgur album linked below. (still not able to do imgur albums properly on the forums?) https://imgur.com/a/CbizhEm So, is something DIFFERENT supposed to be happening here than what I'm getting?
  16. The problem with the latter piece of advice is that SSTU has changed enough between versions that it may not work properly for later versions of KSP. You need the appropriate versioned plugins and mismatching plugin and SSTU part versions can cause problems for sure.
  17. You need a third party life support mod. (KPBS has support for a number of them including parts that are not ordinarily available without a LS mod)
  18. @Jognt no a simple config change wouldn’t be enough, it would need some sort of support in the plugins code. We’ll see.
  19. Most (all but two lines) Deadly Reentry PAW info is only visible when physics thermal debugging is turned on so if you turn that back off, the DR stuff will go away too. And it serves the same purpose as the rest of the thermal physics info. The aforementioned two lines that are visible without debugging turned on are there to remind the player of temperature limits that are lower than what the part says in the VAB. (usually lower) FYI, scaled up planets are actually usually easier for a given velocity due to the fact that stock KSP scales up reentry heating to compensate for the low stock reentry speeds.
  20. The most recent official version was built for KSP 1.6 but will work for KSP 1.7.* but you want KSP 1.7.2 because there are a few PAW bugs introduced in 1.7.1
  21. Yeah, it's the sucky very unfortunate nature of the beast; not much you can do about it. Although I do wonder: Is it possible to make surface attach nodes themselves rigid and fixed joint? You can do it when nodes are defined using the NODE config but I'm not sure how or if you can define that as a surface attach node.
  22. @RaiderMan@Shadowmage Ditto on the autostrutting. Rigid connection helps too. The issue that I've always noticed with that decoupler part is the typical squishy KSP/Unity connection coupled with the long lever arm when the decoupler is scaled vertically. (you don't get that with individual sepratrons, Raider which is why it separated cleaner for you)
  23. But it is based on the size of the reactor because greater propellant mass flow means you'll need more thermal output to heat up the propellant to the desired temperature which means a larger reactor. 7.5 klbf = 33.4 (rounded) 15 klbf = 66.7 kN 25 klbf = 111.1 kN
×
×
  • Create New...