Akira_R

Yes, you need to make a cfg file to tell it which folders not to compress, you can also tell it not to compress specific textures in the same way. As an example: ACTIVE_TEXTURE_MANAGER_CONFIG { folder = RealChute enabled = true OVERRIDES { RealChute/Flags/.* { compress = false mipmaps = false scale = 1 max_size = 0 } RealChute/Agencies/.* { compress = false mipmaps = false scale = 1 max_size = 0 } RealChute/Plugins/PluginData/.* { compress = false mipmaps = false scale = 1 max_size = 0 } } } It can go any where in the gamedata folder, but there is a folder in the main ATM folder that has a bunch already in it, I also recommend doing the same for flags and stuff otherwise those are going to look weird to. You need the version that coresponds to the version of KSP, so if you are on the x86(32bit) version of KSP you need the x86 version of ATM. Now my own question, does any one know if ATM has a method for handling spaces in folder names?

That's weird, I don't know if that has anything to do with ATM though. Now reposting my question since it ended up at the bottom of a page and I doubt it was seen: That is the config I am using, I have tried setting enabled to false and that had no effect it still compresses the stuff. Adding a cfg like the one above has worked for every other folder I have done it to, so I can't seem to figure out why no matter what it gets compressed

Ok so in my experience switching from 0.24.2 to 0.90 I was unable to run nearly as many part mods as before because the base game is taking up a lot more memory now, I think 100% stock it runs at like 2.4Gbs which is big! Plus since you are on a 32bit OS with only 4Gbs total RAM a chunk of that is going to get allocated as system only memory, so KSP is already not going to be able to use the 3.8ish gigs it normally can utilize. Basically you are either going to have to trim down parts or go back to .25 My personal recommendation is to cut out stock parts that are made redundant by mods and parts that you rarely use (Stayputnik who really uses it anyways lol) and then look at your mods and remove things that you don't really use in them. my laptop has 8Gbs of ram so I can give KSP the full not quite 4 gigs it will take, I have 120+ mods installed, probably 20 of them are part mods and of those I really picked and chose what parts I will actually use, and I removed a good prtion of the stock parts and in order to play it for more than 45 minutes to an hour at a time I have to run it on quarter res textures. In .24.2 I was able to run all the same mods but leave in all the stock parts and could load it on half res textures, 0.90 is unfortunately quite bloated.

Ah that second part explains why things weren't showing up when launching the com sat network. The first part may explain the issue I am seeing, I will have to check it more when I get home. Will it hide multiple redundant links to ground stations? I have multiple ground stations in my game and it used to always show the links to them but only one would be the "active" green link, sometimes this link would bounce through another satellite even though there is a direct link to a ground station. In the new version will these other ground station links be hidden? Because that would definitely explain what I am seeing.

Welcome to the forums! In order for us to help we need more information, the basic info you should always provide when asking for assistance are as follows: KSP version and if it's 32 or 64 bit (x86 or x64) Operating system version of the mod you are using (in ATMs case this also means is it standard or aggressive and is it the x86 or x64 version) if you could provide that information then we can start helping you in some cases more info will be needed such as your ksp log, this can be found in the KSP_Data folder that is in the same location as the GameData folder, inside is an output_log.txt No the mono.dll isn't the issue, for starters 0.90 added a lot of new stock stuff to the game. You would probably have problems with crashing just playing stock with out ATM. Some things you can do would be to trim down stuff you don't really use from both stock and the mods you have installed. Also make sure you are using the aggressive version. If you haven't already you can also try this suggestion. Edit: I almost forgot, are you also using the DDS converter to convert stuff? If you are make sure you are telling it to also compress things when it converts, because ATM wont compress them if they have already been converted to DDS and if you didn't compress them with DDS loader then you are still loading them at full size.

Pretty sure it's just connections aren't being shown in the map, and yes I have cycled through the icons to see if it will reset or something, I will check to make sure my mapping sat is still connected when I get home. I was also having issues with connections not being drawn before when I was launching the network, I would launch a com sat get it all set up, go to map view and switch to the booster used to get it up into keo to boost it out to a graveyard orbit and when I switched in map view it wouldn't show any of the connections for the new sat, I would then switch back to the com sat to check and it would show all it's connections again, including omnis.

I am running into a very frustrating problem with ATM compressing things that I am telling it not to touch. I am running KSP 0.90 x86 on Windows 7 using aggressive x86 the latest version available on GitHub I haven't touched anything in the main ATM settings config. The issue is with Contracts Window+ all of it's textures are getting compressed despite me adding a config saying hey don't touch this stuff and deleting the texture cache. ACTIVE_TEXTURE_MANAGER_CONFIG { folder = Contracts Window enabled = true OVERRIDES { Contracts Window/Textures/.* { compress = false mipmaps = false scale = 1 max_size = 0 make_not_readable = false } } } That is the config I am using, I have tried setting enabled to false and that had no effect it still compresses the stuff. Adding a cfg like the one above has worked for every other folder I have done it to, so I can't seem to figure out why no matter what it gets compressed

So I am having a problem with the display in map view, basically none of my satellites omni connections are being drawn. I have a three sat coms network set up and all of the dish connecctions are being drawn in the map view, but only one satellite has it's omni connections being shown, I also noticed while I was launching the network that some times it just wouldn't show the connections for freshly launched satellites when I would switch vessels from the map view. I'll get some screen shots later as I am currently at work Edit: A little more information The comms network is in a Keostationary orbit. I am using the Root range model, with the range multiplier set to 0.6 and the multi antenna multiplier is set to 0.7 each sat has four largish omni antennas I will have to look at what their range is later (they are AIES antennas and I set the RT ranges for them up myself so I will have to look at what values I set for them) Each sat has four dishes two that target the other two sats in the network and one currently set to active vessel (this will be changing soon as it was needed for a contract) the fourth dish is unused currently. I am using the additional ground stations provided by KerbinSide I used this same network in my last game (0.24.2) and had omni contact with the ground on all the sats. But in this game only one sat is showing any omni connections the others do not, not even to the mapping sat I have in a polar LKO, which also isn't showing omni connection to any ground stations when it passes over them. I am using 0.90 x86 on Windows 7 RT version 1.6.3 Any input on this problem?

It "worked" as in everything did what it was supposed to do, but i was getting NRE spam that would crash my game after only like 45 minutes of play. Of course I did have RealChutes installed

This is so awesome. One thing though in regards to the response by Newt on the spin axis of the sat, and I am sure some one has mentioned it at some point, but wouldn't the axis the cubesat is spinning on need to remain constant in order to get reliable data on the effects of 0g-1g on the growth? In the picture posted by apopapi1 I am going to call x-axis running left to right, y-axis up and down, and z-axis front to back, the view point is oriented towards the origin at 45 degrees between the z and y axis, rotated around the x axis. Wouldn't you want the sat continuously spinning on the y-axis so that the experiment container would act as a centrifuge applying a reliable and calculable amount of g forces to the experiment? If the spin axis changed to the x or z-axis then you would end up with g forcess that vary around the ring making things more complicated and at least in my view a little less reliable in terms of data collected. Or is this a non-issue or something that is desirable? Just looking to better understand the workings.

I am getting a small 3D printer soonish and if this enables me to some day start printing craft models I am going to be soooo happy!!

Sweet, trying it out when I get home Edit: If this is installed on a game with a career save already in progress and ships in orbit (comm sats in keostationary and some mapping sats) will there orbits be adjusted properly or will things get interesting?

How will this work with E.V.E. will custom packs be needed like with RSS?

What is wrong with using tweakscale? Delete the configs that apply tweakscale to all of the other mods and only let it do it's thing with KSPI there won't be any issues, oh and just don't make a scaled part your root part

I was getting continuous NREs when I was flying unmanned craft, anytime I flew something with a kerbal and an IVA it was fine

Tweak scale only effects part scale and attachment nodes as far as I am aware. Tweak scale would have to be coded to go in look for scalable engine effects and scale them up. The problem with this is that with the curve's and such that are involved with HR's atmo expansion stuff you won't really get any kind of reliable results. This would be something that needs to be handled on the TweakScale side.

Right on thanks for the input, it's been awhile since I've actually had a desktop, and after using my brain and the googles I found what I needed to know lol

Ok now this is a total noob question, I have only ever done dual monitor set ups on my lap top (HDMI to my tv and then my main screen lol) never had any experience doing this with a desktop, in fact last time I did any playing on a desktop was back in 2007 when I still lived with my parents. I know normally you hook your monitor up to the output on your gfx card, if you only have a single gfx card do you need a card with more than one output? Can you hook one monitor up to the card and one to your mobo? Will that cause performance issues? If you do that and have the one on your card actually displaying your games and the other just doing web browsing etc. (^V maps!! lol) will that be ok? Also what are good specs for a gpu these days? I'm looking for an SLI capable nvidia, something that is going to be able to run say Elite:Dangerous on high settings on a high resolution with a good frame rate that isn't going to immediately double the price of my build lol. I was looking at this ASUS STRIX-GTX960

Timings, what is that? Is that the CAS latency? What are good numbers to look for?

When choosing RAM how much of an impact does the speed really have? For instance if I'm getting 2 X 8Gb DDR3 will there be a noticeable difference between 1600 and 2400? Will it be worth the price increase? Out of curiosity off numbered speeds (1333, 1866, 2133) don't seem to be used as much why is that?

I seriously hope this doesn't get abandoned I love the look of this pack!

Yeah I'm aware of that, however representing this by spawning the exhaust effect down away from the engine bell is in my opinion lazy and really doesn't look very good, I would much rather see people making use of different animations instead, for instance take a look at this gallery the effects used for the LV-909 and the Mainsail.

Is it confirmed that loosing ribbons only happens in modded installs and not in stock ones?

Ah see that was my question, I figured I should be able to do @MKSTEMPLATE but then I wasn't sure how to target a specific one, thank you I'm going to give that a try!

Please don't worry about stepping on toes, the great thing about the KSP modding community is the fact that it is a community and collaboration runs rampant lol If any thing it means less work that I will have to do which means the sooner it will get released. Also there is no way that I will be able to provide support for the plethora of engines that people use out there. As this project was started due to my desire to beautify my personal game, at first release I will only be supporting mods that I make use of, starting with Stock, NASA, KW, and Aerojet Kerbodyne as these contain my main launcher, upper stage and OMS engines. After that I would most likely do AIES and KOSMOS, although I only use a few engines they provide, or possibly look into doing certain USI or KSP-I engines, but that is way off in the future. So if people want other mods supported the best way is to start configs for them, which I will either use as is or adapt. That being said I have a certain set of standards that I want to follow throughout all the configs. What this means is that if some one gives me permission to use configs they have written I may include them as is if they meet my personal standards, if not I will tweak them until they do, however the person who originally wrote the config is of course still going to receive all credit due to them, and if they are unwilling to allow me to tweak the config any way I want then unfortunately I wont be able to include it. Tentative outline of standards will be as follows: All engines must provide effect changes based on atmo density and throttled power of the engine Atmo expansion effects must match the intended use of the engine to a reasonable degree. This means that engines intended for heavy lift first stage engines with low expansion ratio bells will exhibit little to no over expansion at sea level and increasing under expansion as atmo pressure drops and extreme under expansion in vacuum Engines intended for use in vacuum as OMS type engines with large expansion ratio bells will show severe over expansion at sea level with flow separation from nozzle walls, and almost no under expansion once in vacuum Engines that fall in between these two that are meant for upper stages of larger rockets, orbital insertion and engines intended for extreme operating ranges will logically fall in between with slight over expansion exhibited at sea level and slight under expansion seen in vacuum, exhibiting ideal expansion characteristics in the upper atmosphere [*]exhaust effects must always originate within the bell as much as possible, no gaps between engine bell and exhaust [*]little to no clipping of exhaust effects through the engine bell [*]smoke trail that expands with the exhaust effects and never becomes detached That is it for now, like I said tentative outline for the standards I am looking for. Now regarding your comment on limitations of the effects animation itself, this is where most of my problems crop up, and where most of my time gets spent trying to fix things lol. Changing animations and even combining multiple animations (have to be careful not to let the particle count get to high) can be useful in achieving the right look, one of the reasons I hope to get permission to use the effects included in Real Plumes as some of them are fantastic and I have seen interesting use of say using two different particle effects to work around some of the issues. This also brings up issues of continuity in regards to animation styles used and how to handle that but this post is long enough as it is lol, so I'll get into that later