Jump to content

CCraigen

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by CCraigen

  1. My guess is that there is a memory leak of some sort. This is the only point I have EVER crashed due to memory problems in the last ~3.5 years of playing. SSTO on reentry from a polar orbit; I can get within about 5km of the terrain near the mountains on this particular reentry trajectory before I see my memory usage shoot up from 2.7gb to 3.2gb, and then up another 100mb every 15 seconds or so until it crashes out. Haven't tried the forced graphics options yet but they may do the the job. I've heard Unity's OpenGL rendering on Windows has issues with shadow rendering (or lack thereof). -- Actually, hang on a tic. Should my crash logs be showing "0MB physical memory, 0MB paging file, 0MB user address space"? That doesn't jive with other logs I've seen posted.
  2. Ok, seeing some slight memory savings (~100mb) with normal map compression turned on. Still crashing due to running out of memory in the same spot on a Kerbin reentry regardless of whether I'm using texture compression or not. So, it works, but its not enough. Oh well, still a good plugin, just not enough to fix my particular issue.
  3. Using the basic configuration with compress_normals turned off, I see my RAM usage for KSP at the main menu at 3.7GB. Without ATM installed, I see it at 2.8GB. Is this not the reverse of what I should be seeing?
  4. I'm getting an issue where the KER screen is stuck showing the statistics for a single ship in the editor. I built a 6-stage rocket with flight engineer onboard and launched it, and apparently KER now thinks that a brand new craft I've built consisting of solely a Stayputnick contains 6 stages and 5km/s delta-V. This also happens if I exit to main menu and load a completely different profile. 0.6.10 as I'm still on 24.2
  5. I present the unwieldy KAF-1300 "Falcon" (crewed, as dumb luck would have it, by Mileny Kerman). Thought I'd test the frame before closing the rest of the body up. It takes the whole runway to hit 70m/s, but it flies, somehow. With roll and yaw maxed to the left, it does a nice, gentle banked curve to the right while slowly gaining altitude. Let them loose and it rolls over and makes a spectacular fireworks display on impact. Even 15T of counterweight on the left side can't counteract the cockpit. Haven't come up with a discrete solution to this yet.
  6. Got a few new ones for ya. Firstly, "Return to SPH" doesn't bring the actions with it or load the saved version's actions, although reloading the ship file loads them properly. Haven't checked the VAB yet. The second bug is more involved. (1) Large aircraft with belly cranes and extendable stilts - action groups 1-10 dealing with engine management and cranes - action groups 20-24 dealing with stilt operation (2) EVA kerbal from (1) (3) Small kethane mining rig All groups labeled, action groups persisted from SPH to runway for (1). EVA'd (2) and moved him out of the way, switch to (3) and drove it underneath (1). Switched back to (1), actions still good. Switched to (2) and grabbed KAS attachment nodes from containers on (1). Began switching between all 3 repeatedly since it was hard to tell which I was in control of. Bug occurred at this point. At some point during this quick switching, (1)'s actions in group 1-10 had been cleared of names, but all actions were still present. Actions in groups 20-24, however, were cleared completely. No trace of them. Reloading the saved ship in SPH did not restore the original actions, and it appears they are gone permanently. Log file is here. Ship in question is "Packmule". --- Just did it again, names cleared again. Didn't map the 20-24 groups this time so not sure if that behavior would have been the same. Might have something to do with Kerbal Attachment System changing the part count of vessels on-the-fly.
  7. Ditto what cttw said, I'm impressed with how timely you are with these fixes, Diazo. This is by far my most used mod and it's certainly in good hands Grabbing 1.16b to test now.
  8. Ummm.... latest update I can't even use the window in the editor. This is what I see: The second I cross the border of the window, everything vanishes and I can't interact with it, drag it around, anything. Move the mouse back out, and suddenly everything reappears. It's taunting me... EDIT - apparently it fixed itself? I exited out to main menu and came back and it's suddenly working again. *shrug*
  9. Makes sense why that system needs to stay in place. The change I made just makes it more selective in its deletion of old files. ---- Code did this previously: {Check an existing ##.cfg file against an sfs file {if it doesn't match ## or ##-1 delete the ##.cfg file} repeat for all remaining sfs files} repeat for all remaining ##.cfg files} Changed code reorders this slightly to avoid clobbering all files if you've got multiple sfs files with differing save ##: {Check an existing ##.cfg file against an sfs file {if it matches ## or ##-1 sets "keep" to true} repeat for all remaining sfs files} if "keep" has not been set to true delete the ##.cfg file} reset "keep" to false and repeat for all remaining ##.cfg files} This results in the most recent 2 ##.cfg files being kept for each sfs file present, provided the cfg files exist in the first place.
  10. Ok... when I updated, I wiped the Editor and RootDrive files so I could start fresh. Now none of the action groups are saving on in-flight ships if I exit to main menu. Also, the numbered files are only showing up when I have a ship actively in focus and they appear to delete themselves almost instantly. [--- code babble warning ---] I just took a peek at the code and I'm wondering if the DeleteOldSaveGames() function in Scenario.cs might be a culprit (at least for my particular bug). If I'm reading it right, it's loading every .SFS file in the current save folder and checking the AGextScenario number inside it against the filename of AGext#####.cfg. It then deletes any AGext#####.cfg file that isn't either A) the AGextScenario number or the AGextScenario number - 1. The problem I see with that is that there are no checks in place to make sure that "persistent.sfs" is the only file actually checked; it will follow the above procedure for every .SFS file without stopping. The quicksave file also contains an AGextScenario number, as do (in my case, anyways) a grand total of 18 other .SFS files created at various times in the last week (some of them backups automatically created by Kerbal Alarm Clock, some created by me). This results in the procedure will loop 20 times with 20 different AGextScenario numbers and wipe any and all AGext#####.cfg files out in the process. I might suggest keeping only a current, backup, and quicksave version of the .cfg file rather than the numbering system. Short term, this could probably be fixed by only loading persistent.sfs and no other save files when checking for AGextScenario, or saving a list of all AGextScenario numbers found and doing all the file deletion post-loop (which would keep a current and backup .cfg for each .sfs file found, which was probably the original intention). I'm going to grab the code and try these, see what happens. --- UPDATE - Quick hack-job modification successful. No more file clobber and my test action groups in 51-52 and 201-203 persisted, names and all, across multiple load->in-flight->exit to menu cycles. Modified AGext.dll and Scenario.cs files are here. Changes made starting at line 86 in Scenario.cs. [/--- code babble warning ---]
  11. Got it, so the timewarp bug kicked in and wiped the actions for this ship, then when I swapped back to it and it couldn't find actions it grabbed the actions for a fresh ship of that name -- which just happened to be my old version of the design with a totally different set of actions. At least it's doing a pretty good job to try and recover. Where are those AGext###### files? I found the two core ones but not the numbered files. EDIT -- nm, found them, didn't realize I had to look in the folder while the game was still in flight mode.
  12. I'm currently getting an issue when I load a saved spaceplane, assign actions into #101-103, save and exit to Space Center, when I reload the ship in the SPH it's loading the action group names but none of the associated actions. This is on 1.15, and I'm assuming this is the same issue as described above? If I go straight from SPH to runway it keeps all actions assigned properly. EDIT - and, oddly, an unrelated issue where I had switched to one of the spaceplanes in orbit and discovered it had cleared it's action groups and adopted the action groups of an earlier flight with the same name I had launched and recovered yesterday. I'm guessing this one is related to the time warping bug so I'm grabbing 1.15a before continuing.
  13. Yes, it's only appearing on mouseover of the part in the AGE window. The feature is working exactly like it should (as far as I can tell), I think my brain was just expecting the purple highlight effect and when I got a checkerboard instead, I just assumed something was broken or corrupted. Only figured out it wasn't today when I poked into the folder and saw the png file. My bad.
  14. Searched the thread and saw this bug a ways back, but no solutions. I am experiencing red, pixelated distortion on the docking cam, same as FuriousSquirrel (page 146) and Bobe (page 147). FuriousSquirrel - http://i.imgur.com/4b8hGJw.jpg Bobe - http://i.imgur.com/hNEgFd6l.png Mine - https://dl.dropboxusercontent.com/u/5889104/ksp/rednoise.jpg I first noticed it when I went from a Radeon HD4890 to an HD7870 and updated to the latest Catalyst drivers. My experiments today on an unrelated problem showed that reverting to the old v13 Catalyst drivers suddenly fixed the red noise. I'm assuming the camera's viewpoint is rendered to texture and mapped onto a surface over top of dockingcam.png, and seeing as how the same sections of the cam window appear to be having the most problems in all 3 of our cases, I'm guessing a fix can be made by changing the way the textures are mapped. Has anyone else had these problems and confirm that the same parts of the grid are having issues? UPDATE - Curiously, using the Romfarer Lazor Cam part does not produce these artifacts like the Docking Cam does, and they use the same class in the code (as far as I can tell). The issue appears to be with either the image filtering taking place or the fact that it's translucent render to texture on top of a static image. Going to attempt a recompile with filtering commented out. -- Can't build atm, VS2012 is not being cooperative. Will try again later.
  15. .... Well now I feel more than a little bit dumb. Just did a KSP update and a plugin update as well after a few month hiatus, and now I've just spent several hours running video RAM tests, uninstalling and reinstalling drivers, and doing file verifications because of that yellow/black checkermark thingie that appears over a selected part on the in-flight interface. I thought I was getting texture corruption, I didn't realized that it was supposed to look like that now. :head->wall: You might want to change it out for something that looks a little less like an error. Something more akin to this, maybe? That being said, I love this plugin. Love it love it love it
  16. I've got a few to share, starting with the most recent. While assembling the Jool Express mothership in orbit (http://dl.dropboxusercontent.com/u/5889104/ksp/joolexpressmothership.jpg), I ran into issues building an efficient launch vehicle for the command section. After 4 aborted launch attempts, I had the design ready, and launched it in a rush. Didn't check it for staging errors first. 1st stage solid boosters went dry, so I hit the button to activate the second layer of boosters and jettison the first -- and accidentally severed the entire rocket below the payload. Didn't lose stability, so I rode it out just for the hell of it rather than reverting, and lo and behold it ended up in a stable rendezvous orbit. Munshot I was another interesting flight. The payload was a 4-part Munbase (http://dl.dropboxusercontent.com/u/5889104/ksp/munbase-ia.jpg) that I didn't want to land in multiple trips, as I wasn't confident I could hit the same target spot with reasonable accuracy a second, third, etc. time. I took the whole thing down as a single stack, landed the bottom module, detached it, hovered, moved over, landed the second, etc. All 4 modules landed successfully but the command module was further than I wanted it to be. Catastrophe followed when one of the RCS blocks glitched midway through relocation and the module entered an uncontrolled burn horizontally over the surface. The lander did not survive, but the capsule and crew did. (http://dl.dropboxusercontent.com/u/5889104/ksp/munbase-ib.jpg) Base expansion / rescue mission Munshot II was launched. Payload consisted of the Rover Maintenance Bay with 3 rovers attached, and an identical command lander (http://dl.dropboxusercontent.com/u/5889104/ksp/munshot-iia.jpg). I managed to maneuver the capsule/rovers to a landing spot within about 30m of the Munbase, when the fuel tanks ran dry. I'd forgotten to pipe fuel from the main tank to the rover's braking engines, so they had a more limited burn than they should have. It then fell the rest of the way to the surface, and hit at somewhere between 25 and 30 m/s. The ship telescoped down into itself, followed by a massive explosion. When the smoke cleared, I was pleasantly surprised to find that the rover frame and all three rovers had survived intact, as had the command capsule. Everything in-between blew up (http://dl.dropboxusercontent.com/u/5889104/ksp/munshot-iib.jpg). Lesson learned -- check your fuel flow ahead of time.
  17. Works wonderfully, fantastic mod. It's gotten rid of a huge headache I had in assembling a combo mission to Jool in orbit. The whole thing with group names not sticking when edited in-flight is a minor annoyance, but not the end of the world. Wouldn't mind seeing the Kerbal launcher bug in action, though
  18. Here we go. This was on a test of the last stage with real engines, the main boosters haven\'t even been made yet. Made using the Silisko variant on 0.13x2. Video when the whole thing is done. Command module is the only thing that touches the ground on liftoff. This thing is a pain to steer, RCS works as it should, but SAS and ASAS are useless because having the gimbals sit at the wrong end makes every orientation correction do the reverse of what it should. Turn on SAS and the ship immediately enters an uncontrollable somersault. Challenge: passed Bonuses: orbit (1), 3000k (1), 7000k (2), 12000k (3), solar orbit (4) edit: now with more boom.
  19. Been working on this for a week. With 0.13 and the fuel rework, my designs finally started working. Will post results once I can get a vid recorded.
×
×
  • Create New...