Jump to content

Infinite_Maelstrom

Members
  • Posts

    26
  • Joined

  • Last visited

Reputation

27 Excellent

Profile Information

  • About me
    nop;
  • Location
    Dropping things into space from the Southern Hemisphere

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics, 3600 Mhz, 4 Core(s), 8 Logical Processor(s) | GPU: Name NVIDIA GeForce GTX 1660 Ti | RAM: 32GB If you zoom in on a craft in the VAB enough, the craft will disappear. It will reappear if you zoom out enough. The game automatically zooms out this 'enough' for you if you attempt to rotate the vessel while zoomed in too much. HOWEVER, if you manually zoom out enough to see the vessel again, and then rotate the view, the game will jump to a further zoomed-out view. Expected behaviour: If the craft is visible, zoom level does not change when rotating. Reproduction steps: In the VAB, zoom in on a craft until it disappears. Then, zoom out any distance so that it is visible again, and rotate the view.
  2. Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics, 3600 Mhz, 4 Core(s), 8 Logical Processor(s) | GPU: Name NVIDIA GeForce GTX 1660 Ti | RAM: 32GB When building a vessel, if there is a subvessel with a fairing that has been built, connecting that subvessel to any other subvessel - or connecting any other subvessel to that subvessel - or even just connecting any new part to the subvessel with the fairing - causes the fairing to lose its secondary colouring. This affects fairings on either subvessel. Neither subvessel needs to be the active vessel to cause this bug. A new part does not need to have been placed into the workspace before placing it on the subvessel to activate this bug. Expected behaviour: The fairing retains its secondary colours. Steps to reproduce: Add a fairing to the workspace, and build it. Then either connect it to any other part or connect any other part to it - including other built farings. The secondary colours on the fairings will disappear.
  3. Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics, 3600 Mhz, 4 Core(s), 8 Logical Processor(s) | GPU: NVIDIA GeForce GTX 1660 Ti | RAM: 32GB The craft editor generates unnecessary craft files when building a vessel. When building a craft, the game periodically autosaves my vessel (good). However, each autosave generates an entirely new, but identically named, craft file in the "Load vehicle" menu. This clutters up the menu, making it difficult to find the craft I want, and the identical naming makes it very hard to tell which ones are old versions and safe to delete - especially when there are only non-visual changes between different files. Expected behaviour: Each new autosave overwrites the last autosave, and manual saves overwrite the most recent autosave, so that there is only ever one saved file for each craft. Steps to reproduce: Create a new craft, make some changes, edit it for a while, then visit the "load vehicle" menu. There will be multiple autosaved versions of your craft in the list of vessels.
  4. Ok, so I didn't really feel like troubleshooting the virtual memory, so I just went and bought 16GB more RAM ($86nzd, less than half the price I got the first 16GB for!). Guess what? No more crashes! Nice! Thanks for the help @Lisias. KSP is currently using 12.6GB RAM, with ~5GB used by the OS. The quantity of RAM used by KSP jumps massively when it first loads into the menu screen, and again when you load into a save, explaining why my game crashed in those situations. I suspect that there was a Windows 10 update that increased the RAM requirements, after which KSP stopped being able to load.
  5. I tried deleting the CKAN cache, that cleared up about 30GB of space on my C: drive. Instead of rolling back to an old GPU driver, I updated to the latest one (531.41), hoping that would contain a fix. Despite issues with CKAN, KSP managed to load further than before - I got to the sound of birds chirping before it crashed. (The strange colour issue also occurred, but had resolved by the time the crash actually happened.) Unfortunately I had absent-mindedly closed my HWMonitor 'to save RAM,' so I don't know if the GPU overheated or anything like that. When it crashed, this time Firefox's tabs did not crash, but windows 10 nightlight did. A popup appeared with the following: Error in GC Virtual alloc remapping failed (forgot to screenshot, pretty sure that's what it said though) When I clicked 'OK', then Firefox's tabs crashed. I have included the same selection of logs as last time (this time with 7-zip for better compression). https://drive.google.com/file/d/1zC0tZWxGzckXHxSUSJ6ac9Wlf7xEPh6R/view?usp=sharing This time, the Windows logs STRONGLY suggest that the failure was caused by a lack of RAM. (Note, in the .evtx file, the event that occurred at 11:48:07pm was when I clicked "OK" on the error pop-up window - I had left it open for a while to try to understand what it meant. The other errors are roughly simultaneous with the observed crash.) Edit: scrolling back through the windows logs to the last time I opened KSP, I see that there are 4 very similar memory-related errors there too. I must have missed them when uploading the last set of logs.
  6. So I haven't gone to bed yet... I emptied windows' recycle bin, this cleared up 22GB on my KSP drive and 240MB on my C: drive. Then I closed all the non-essential programs I could find, and restarted KSP (also closing CKAN afterwards). This worked a little better, getting to the home screen. I opened a save, and after waiting a long time, KSP crashed. This time the night light did not crash though. Shortly afterwards, however, when I was trying to get the logs from file explorer, the "windows application" crashed (according to the pop-up error dialogue). The PC did not BlueScreen, but the screen did go blue with nothing but an empty firefox window for a few minutes, then it recovered. I think this lends credence to the theory that the lack of space on my C: drive might be amplifying the issue, even if it is not causing it directly. In any case, the logs for this crash - including windows error reports from a minute or two later - are here: https://drive.google.com/file/d/1p9AecmZzsKeKPlHIpauFUxsbPRCtFwJc/view?usp=share_link One additional potentially interesting note is that often, just before KSP crashes, it will show a screen that is like an extremely over-exposed version of the current screen, except with all colours above a fairly low-ish luminosity shown as black. This does not always happen before a crash, and a crash does not always occur after this happens, but they are very strongly correlated.
  7. Hello, I have been having this issue with my most-modded install of KSP for about 20 months, but it has been getting worse and now KSP will not even fully load before it crashes - where previously I could play for at least 30 mins or more before a crash occurred. (Windows 10 x64; AMD Ryzen 2400G; GTX 1660Ti; 16GB RAM; 105GB free on KSP install drive, 1.84GB free on system install drive; KSP 1.12.5; 128 mods, for modlist see attached files.) Situation: When KSP is loading, or when in space (usually switching craft or views), but especially when opening a save, the game will suddenly and unexpectedly crash. Sometimes a runtime error window will appear, not always though. (I'm afraid I don't have a screenshot of the error window.) However, one thing always seems to happen: all open tabs in Firefox will also crash, needing to be reloaded, and if Windows nightlight is on, it will crash too (needing to be turned off and on again to start working). I have on a couple of occasions attempted to narrow down the culprit, but because of the unpredictable nature of the bug, and the number of mods in this save, this has so far been unsuccessful. This evening, I had enough free time to play KSP for the first time in about 8 months. I first ensured that all of my mods were fully up-to-date (I needed to use this workaround to force CKAN to notice the most recent versions of each mod). But then KSP crashed 4 or more times in a row due to this bug and I decided I needed to go to bed instead. I have attached all the logs I could find from the most recent crash. This crash occurred during loading rather than during opening a save, but hopefully it is still helpful. Firefox itself did not crash this evening (sometimes it does), only all the open tabs did. The only logs for Firefox I can find are records of Firefox crashing completely, therefore this evening's error is not recorded, and so I have not included it in the attached logs. All logs that I could find from this evenings latest crash (some may be from earlier crashes). Modlist is also included in this drive folder: https://drive.google.com/drive/folders/1GtKJdmbLnmkG7A6-wAy4crQpU0yDnd-1?usp=sharing Hopefully someone is able to make some sense of this issue, it has been frustrating me for a long time. Thanks I.M.
  8. This is a really cool mod! Thanks @Nertea! I have a quick question - is the PAF-1B 'Winston' inflatable module supposed to be the same mass as the PAF-1A 'Volleyball' inflatable module? The part description seems to suggest it should be lighter. If you had a few minutes to investigate that it'd be greatly appreciated. Thanks
  9. I wonder if solar panels in ksp2 will have a luminosity cutoff like real ones? I think IRL solar stops working altogether past Saturn. Do you still have the classic VAB music too?
  10. You missed "normal" colonies in the poll. I quite like the idea of underwater colonies, now you mention it!
  11. Hi, one of my mods is causing vessels that are not the active vessel to ignore aerodynamics. This almost ended in disaster for a multi-part reentry I just attempted (and barely survived). Heating effects are not disabled. Example: Bill EVAs to get science while the pod is gently floating down to sea under fully inflated parachutes. Instead of holding onto the ladder, he is forced off the ladder by aero forces, and the pod plummets beneath him (despite its parachutes). Almost immediately, a message appears on screen saying that the main parachute has been destroyed by aero forces and heat. Switching back to it, it rapidly decelerates with the drogue chute, but I notice Bill falling rapidly from where he was previously. Switching between them rapidly allowed both to survive with the help of "no crash damage." (Interesting additional note: When Bill reached the water I was not focussing him, since I know Kerbals survive impacts better when they are not the active vessel. However he was not stopped by the water and continued accelerating underwater until I switched to him in concern for his safety.) Example 2: I used to attach "Flea" boosters with parachutes for a bit of extra kick at launch. Their short burn time combined with PRE meant I could recover them afterwards. However, at some point this stopped working. I did no think of it at the time, else I would know exactly what was causing the issue. Now I think the same problem as described in the above example is causing them to fall to the ground without being decelerated by their parachutes - or anything. Does anyone know which Mod causes this problem? I suspect Restock or KSP Ground Effect, but I'm not sure. Here's my full modlist:
  12. Sup @SuicidalInsanity The Mk2 engines seem to be ignoring crossfeed rules. eg if the part tree goes: Rockomax x200-16 fuel tank <-- Hydraulic Detachment Manifold <-- Mk2 Rocket Fuel Fuselage short <-- any M2X rocket engine The fuel in the Mk2 fuel tank will be used up first, but then instead of the engine flaming out, it will begin to consume the fuel in the Rockomax tank. I've checked that crossfeed is turned off on the detachment manifold, and also checked that other (non-M2X) engines work correctly.
  13. That's pretty interesting, thanks for explaining it so clearly. I do have one question though: For my rocket (see post in spoiler), why does the drag appear to work correctly for the stock HG-5/fairing, but not with ReStock? Wouldn't the incorrect drag centre be outside of the fairing in both cases? Thanks!
  14. The 73rd out of a planned 198 orbital ring stations, and the second of these stations to be in orbit of Luna. Shortly after it was completed, financial constraints forced the number of stations to be reduced to 96, and the ensuing litigation from disgruntled clients forced cancellation of the program. Station 73, or "Posy" as it is known to those who live there, is shaping up to be one of the nicer of these stations to live on, although the construction of habitation facilities (by 3rd party contractors) has slowed since the bankruptcy of the parent company. Ink, Pencil, Watercolour pencil, Sharpie.
  15. Yes. My HG-5 Antennae are inside the fairing. Does ReStock change the size of stock part's drag cubes? I thought it only changed the appearance of the parts.
×
×
  • Create New...