linuxgurugamer

OK, but doesn't the conversion to dds also make the images smaller? the default option in the DDS4KSP.exe has options for the format.

Gaaah!!! This is driving me up the wall! I installed ddsloader in another install, virtually identical to the one I was doing earlier. This is using KSP 32 bit, ATM Aggressive. No customizations made to any config file. A simple load using ATM uses about 2.9 gig of memory. Ran the dd4ksk.exe on the gamedata directory, deleted the texturecache of ATM. All icons, etc seem to be OK, but it's using 3.2 gig of memory. If I remove ddsloader without undoing the dds conversion (ie: so very few pngs are there), it only uses about 2.4 gig So for this one, it looks like the DDSloader loads about .8 gig of data. To summarize: Normal load with ATM Aggressive: 2.9 gig Load with DDSLoader, have NOT run the dds4ksp yet: crashes (too much memory usage Removed ATM, ran dds4ksp: Folder infos : MBM files count : 764 TGA files count : 217 PNG files count : 1763 Backup files count : 0 ----- Used default settings Memory usage after this was now about 3.2 gig Reinstalled ATM (made sure texture cache was empty), ran ksp and exited, then ran it again (to make sure that whatever ATM was compressing wasn't causing issues because of the compression). Memory usage now was: 3.15 gig I know this works, but am beginning to wonder what I'm doing wrong. Any suggestions?

Thanks. And I'll check the files this evening.

I'll do that when I get home, thanks. Re. the config files, I'm a little dense today :-) You said "Also I'd like to remind everyone that DDSLoader can use the ATM exception config to save more space by making more texture read only." How?

Oh wow! I just deleted the ATM cache, reran the converter with the 2 lines you mentioned above, and now my memory usage is only 2 gig!!!!! Only problem now is (this is minor) the Squad icons are blurry, see the 2 pictures below: Regardless, thanks for responding so quickly. What is the ATM exception config? This one shows the blurry site icons: And this one shows the orbit icons:

I just tried this along with the DDS converter. Unfortunately, my results were less than spectactular. First off, my system is Windows 7 64bit, 16 gig memory. KSP 32 bit, 0.90 I have over 70 mods installed, 65 of then through CKAN. With ATM, after starting and going into the Tracking station, memory usage is about 2.9 gig With this mod, after running the DDS converter, memory usage was about 3.5 gig. Also, in the tracking station view, the icons on the planet for locations of missions were square blocks, as were the dots which were going around the orbits of the available satellite contracts. It then crashed when I tried to load a ship in the VAB I reverted the DDS conversion, removed the mod and memory went back to normal Loading the same ship in the VAB, memory went up to about 3.3 gig. One note: I had ATM installed and running for a while before I found this. So, one question is, should I delete all the ATM textures first, then install this and then put ATM back in?

Well, it started again, and I verified that all the nVidia settings were defaulted. Anybody have any ideas? - - - Updated - - - Facepalm! I was starting KSP with the following option: -force-d3d11 Deleting it solved the problem

Wow! Amazing! Thank you!

Just came across a possible bug: For debugging purposes, I had to rename the game directory. After running the game, I noticed that SAVE had done it's save in the original location. It seems that you are storing a complete path. This could be a problem if someone needs/wants to rename everything or move it to a new location and SAVE then won't seem to be working properly. How about adding an option which would, if the backup directory is inside the game directory, either automatically alter the path to be relative to the game directory, or ask the user if they would want it to be relative or absolute? My personal preference would be to make this automatic, and only store the complete path if the selected directory is outside the game directory.

Now we go into the rabbit hole! I renamed the directory of my old install, then took my new install, with all the mods, and moved it to the same place as the old directory, so that it was in the same logical location. Started it up, loaded my test file and Minmus was GONE! Moved the directory back to where I had first put it (for this new install), Minmus was back! Now I took the original install with the problem and ran it without renaming it back, so the directory name is now KSP_win.bad. Minmus was back! My conclusion is that this may be in the Windows registry, or possibly a file elsewhere. My only other guess which I'll look into is that I have an nVidia GTX 760, and I suppose that the nVidia drivers may be doing something - - - Updated - - - And I found the problem! I must have modified the settings in the nVidia control panel for the game. I reset them back to the global default, and it now works. So for anyone else who may be having texture problems like this, check your video settings, specifically of the driver.

I've been running a heavily modded version. Most of the mods were installed using CKAN. System is: Windows 7 16 gig memory KSP 32 bit Video & Graphocs settings: Anti-Aliasing 8x texture Quality: Full Res Pixel Light Count: 64 Shadow Cascades: 64 Aerodynamic FX Quality: Normal Edge Highlighting (PPFX): disabled I did try turning off the antialiasing, reducing the texture quality to 1/8, and turning down both the Pixel Light Count and Shadow Cascades. Didn't seem to make a difference I was going to Minmus, and saw that it was totally black when I was close. So, I tried to do some debugging: 1. I removed ALL mods 2. I recopied the two folders in the GameData directory from the install zip file: NASAmission and Squad 3. I reinstalled the KSP_Data directory from the zip file 4. I loaded new sandbox game 5. I created a simple ship (capsule, 3 tanks and an engine), used the alt-12 to get infinite fuel, and blasted off to Minmus. I got the ship in an orbit, and observed Minmus as it went around. Above a height of about 180,000 m, it shows normally. When it goes below that height, it goes black, but with the edge lit up, kind of as if it was between my ship and the sun, however, I am on the sun side when I see this. Another thing I noticed, was that at this "edge", when I flipped back and forth between the map mode and the normal view, it shows Minmus normally for about 1/10 second, then it gets blacked out. It seems that this gets worse the closer I get to Minmus. So, I've tried to reduce this as much as possible, and have gotten to the point where there is nothing left to remove So, I created a new install, copied the save into it and started it up. The basic startup without changing any options. It worked, Minmus is there. I then turned on all options to their max, restarted the game, Minmus was still there. Any suggestions? I don't mind debugging, but need a direction. thanks in advance Edit: I copied ALL of my mods into the new install, and started it up. Minmus was there. Thinking about this, I remembered that a few days ago I had used Hyperedit to get a lander close to Minmus for a test. That's when I first noticed this. I dismissed it assuming that Hyperedit had screwed up something, but am now wondering if it might have corrupted a file. My big problem is that I have no idea which file, I've replaced all the ones I can think of.

Just a suggestion, if you add a phased slowdown like I had described earlier, this problem may go away, since it won't be doing a suicide burn.

I ran into this as well when I started to build my first skycrane. Some engines worked, and some, the game just crashed. for now, I've uninstalled the mod, will reinstall it when the next version comes out.

The ship DID have SAS, I just didn't have it turned on. As I put in the other thread (for the vertical velocity control), it IS working, as long as MechJeb is off and SAS is on.

Is it going to work the same? I must confess, that when I was finally able to do the landing last night, I was somewhat nervous because it essentially did a suicide burn (ie: it just fell until it was able to do a full power burn to stop at just the right altitude). While I know that is probably more fuel efficient, it does cause a problem if you need to stage during the descent as I did. I had a stage with a Skipper engine which had enough to do most but not all of the landing, so about 5 seconds before I hit the target altitude it ran out and I had to stage, next stage had a much smaller engine and while I had the target altitude set to 200m, it actually got to within 5m before it actually stopped.

OK. Being in the software business myself, I was concerned that we were talking about the same thing. - - - Updated - - - Success! Both landing assistant and vertical velocity are now working, thank you!

OK, I'm looking at it. My ship is in orbit at about 42000m high. I've positioned it so that it is vertical to the surface.. The Vertical Velocity box has an entry field for "Fly to:" with a button next to it which says "auto height (free)", and a button below which says "Control Off". If I click the "auto height" button, it goes away and text "free pitch" shows up, and the button at the bottom shows "Height Control". Both of these are green. If I then click the green "Height Control", the Auto Height button comes back and the button at the bottom changes to a green "Velocity Control". This does not sound like what you described above. According to CKAN, it is version 1.17 Edit: Is it possible that the text is wrong, and where I see "Auto Height (free)" is what you said should be "Height Control (orbit)"?

Ok. I won't be doing anything with this until either late tonight or tomorrow night. I usually use CKAN to do all my updates, but will do this by hand if it isn't there yet. So, I remember that I usually don't see the "TWR LOW" label, so assume that the engine does have enough thrust. I do see it when I've oriented the wrong direction, so I know thats working. Thanks

Ah, that explains a lot. My ship has the Mark1-2 Pod, which from what I can tell has SAS (please tell me if I'm wrong). The engine is an RMA-3 orbital achievement device (from NovaPunch2), which, while efficient, is not super powerful (I think it has a maxthrust of 75), so it is possible that it does need more than 80% to slow down.

:-( Ok. Then it's my bad for not making sure the ship has SAS. I wonder if I can edit the save file to add SAS to this ship, for the duration of this mission only.

Thank you for a great explanation. I'll test this when I get home. What happens if the 80% thrust isn't enough to do it?

Oh, that explains a lot. Yes, this is a problem. Either one or the other, but not both. Personally, left click is an action, right click for a menu or popup.

Question: I have a ship with mechjeb and a pilot on board. The pilot has no xp, so when I turn on SAS, it doesn't show any of the icons to the left of the navball (maybe this is my problem?) I turn off mechjeb, but this doesn't seem to work. What do I need on the ship to make this work properly (I'm assuming I have a mistake somewhere). Thanks in advance

Diazo, Another suggestion, although I'm not sure how difficult it would be: Have two sets of numbers: Maximum Altitude to activate at Desired descent rate at max altitude Altitude to stop working at (location hover height) Desired descent rate at this altitude The idea would be to not start the engine until the maximum altitude is reached. Then to start slowing the ship down. Scale the descent rate from the first rate to the second rate along the flight path. For example, I'm landing on the Mun, from an orbit which is 45,000m high. I do my deorbit burn and start descending. I set the max altitude to 5000m, and a descent rate of 100m/s I set the min altitude to 10m, and a descent rate of 0m/s So, at 5000m, the control would start the engine and slow the ship to 100m/s. I'll list some values below, my feeling would be that the descent rate would be continously calculated depending on the height: At 4000m, the control would calculate a descent rate of 80m/s At 3000m, 60m/s at 2000m, 40m/s at 1000m, 20m/s at 10m, 0m/s, and in a hover mode. If altitude was set to 0m, then it would be a landing mode The calculation could be: maxAGL = max altitude above ground level maxAGLv = descent velocity at the maxAGL minAGL = min altitude above ground level minAGLv = descent velocity at the minAGL Assuming that current AGL is <= maxAGL: targetV = ((maxAGLv - minAGLv)*(curAGL / (maxAGL -minAGL))) + minAGLv This calculation would also work (if desired) for altitudes above the maxAGL, it would be proportional. Again, thanks for all your hard work.

Hi, running CKAN 1.5.6-0-g windows 7 KSP 32 bit I tried doing an update of two mods at the same time I wanted to install a new mod. CKAN had some sort of error. I don't think it actually did the updates, but now when I run it again, it says there are no updates available, even though I did do a refresh. How can I force CKAN to check to see what version are actually installed?