Faark

I actually prefer new tech being a surprise. Especially with a new save game after an update it was always nice to discover sth new. Knowing all the results of decades of research up front seems wrong imo. Maybe some sort of compromise? What about only showing tech nodes according to the players R&D center level?

Probably LOD running out of memory while preprocessing textures. Would be great to get LODs log file at GameData\LoadOnDemand\LoadOnDemand.log to verify this. I'm currently evaluating whats necessary to support OpenGL as well, but it will probably take a while until thats implemented.

Managed C++ is called c++/cli now for some reasons. It is important to note that afaik Mono can only handle pure .net assemblies (c++/cli allows some crazy .... with native libraries, but that's platform depended [=bad] and tricky to realize). That means you would have to exclusively rely on manged libraries, preferably the .NET Framework Class Library. That's like learning a new language, and thus not much harder to switch to c#. I think there were also some issues [though resolvable] with creating c++ assemblies for .net 3.5. Also pretty much all "reference" code (other mods) are in C#, so you should be able to read c# anyway. tl;dr C++ KSP modding is not worth it. Use/learn C#.

It could never be relied upon being effective. It intends to make a player aware of sth, that will never work all the time. Its definitively a ***ty move to create a mod disabling CC, but you saying this makes CC entirely useless is kind of a bash against your users as well. Most of them probably want to help you, so they can enjoy an awesome mod. Aren't those the users modders should focus on? Why should someone promote sth that kills a feature necessary to modders for supporting mods? All possible reactions (like disabling features instead of warning or modders having less time to improve the mod) would only hurt players in some way. Seems like CC actually has an image problem that needs to be "fixed". This should be considered feedback! Lesson learned: User don't understand why modders need to throw a dialog at them all the time. Possible improvements i see so far: - Explanation. There should be some "About" button. It should explain the user why such a dialog is necessary for modders and mods to exist (just a tiny click for you vs hours for the modders because of bad bug reports; especially for more popular mods; even experienced users/modders have written such false reports in the past; incompatible mods can appear to work but break later or even other stuff; modders could disable but won't to be nice to user, so user pls just bear with the click; did i miss any argument?). - The above text could also contain some call for action. Update mod, "Request an updated version", stuff like that. Or how to [temporarily] get rid of the msg, in case we actually go for it. - Can we improved the usability? Some clickable Web-Link might be nice to make getting the latest version easier. Maybe even some "click here to check for update available for this mod" solution? (A popup showing the user what online-stuff will be done should cover the legal part, i guess?) - "Dead" mods seem to be a problem. Why not allow some cfg file to silence a specific mod version for a specific KSP version. In a way that's more work for the average user than just clicking ok all the time. CC would probably not "work" with people doing this anyway. The only alternative i see is pushing mods using CC to include some license allowing users to share a recompiled version with CC removed/updated. As stated earlier: - Disabling the mod for incompatible KSP version. Kind of anti-user and a problem on KSP updates, but if its helps the modder... - Requesting log files on bug reports & co. Kinda annoying as well, but might help with other issues anyway It would also be possible to negotiate a CC version among trusted mods only, though that might require stuff like signed assemblies.

Could you please specify "after Mars"? There is little real benefit to go somewhere, return and pick a new target. But once we got a colony on mars, we should have a reusable rockets as well as the tech to keep us alive in space for a long time. Also one of the biggest business on mars will probably become spaceflight, since it costs less fuel to launch. On the long term (and we are talking about 10-20+ years anyway) humans will go where humans can survive.

Does Persistent work with Properties? I haven't used it in quite a while but think it only worked on fields. You might want to try this instead: class ... { ... /** The first element of the pair */ [Persistent] public T First; /** The second element of the pair */ [Persistent] public U Second; } If you want to use properties for public stuff since its good style you can use private fields fields to save the actual value. C# would do the same for you anyway.

New version available: v3.4, offers image compression. So far not for normal maps. Its also disabled by default, for now. You have to set ...Compress = true in the cfg file either for all (DefaultImageConfig) or individual images. Those config options might not appear .cfg file until LOD re-writes its cfg. The easiest way to force that is to delete the GameData\LoadOnDemand directory and start KSP. I've also seem to have broken the 64bit version, but that shouldn't be a big issue for this test version since most of you appear to use 32bit anyway. That's kinda intended. To make sure LOD doesn't create those annoying little freezes i've lowered the disk-thread's priority. Sadly that means most other non-KSP stuff comes first as well

There is a KerbalExpressionAI MonoBehaviour, exposing a bunch of properties including some levels and even meshes, that seems worth a closer look.

The current version of LOD should work with the current version of ATM, afaik. At least because of how they should currently operate. Haven't tested it lately, for the earlier stated reason. This usually indicates some dependency was not or incorrectly installed. Please try to re-install all requirements listed in this threads first post. Are you running a 64bit ksp install? This might require vcredist_x64.exe, btw. Logs! Would have been nice to check out the logs from that event. Did it happen again / can you reproduce it? This mod so far only works for KSP's on Windows using DirectX 9 (the default). Caused by LOD or unrelated to this mod? I'd love you to try it. Any kind of feedback is appreciated, including/especially those of the "it doesn't work/help because..." kind. Aw yes, there was sth like this still unresolved. Thanks for the logs, I'll have a look at it later this week, i need a break from texture compression anyway. They aren't using TGA's, right? I think TGA transparency was an issue as well and i kinda hoped not having to take care of this anymore since there was a lot of bad "talk" about TGA in KSP recently. Hey, it's probably still some kind of OutOfMemory error. Whatever it is, it occurs in a separate LOD-part, thus the actual message is logged in GameData\LoadOnDemand\LoadOnDemand.log. It actually might be worth a try to simply not load the high resolution texture in such a case. Though it would still mean KSP is close to running OOM and might crash because of sth else needing memory. Anyway, it would be good to have a look at LoadOnDemand.log first, just to make sure its not actually caused by something else. Yes, Issues on GitHub would be great. Its much easier to keep track of them there, since each can have its own thread.

Yes i've seen it. Its actually kinda worthless for this project, since LOD doesn't currently doesn't compress at all, doesn't gain any calculation time. But it even could have loaded DXT compressed data all along and that's what it was aiming for in the first place. The missing footwork i've never found the time for was to choose and integrate a compressor. But now with ATM trying the same someone will probably find a solution soon. I'm more concerned about some method the DDS loader Sarbian found uses (LoadRawTextureData). LODs real problem was to load textures without any impact on the game and all of Unity's methods to load textures i tried created short freezes. Thus i choose to use DirectX directly instead. But this one sounds kinda lightweight and i just can't remember whether i tried it back than. Might worth another try. Also too bad its undocumented.

Yes its a pretty seamless integration, would even work nicely together with my stuff. Though i wonder why you never worked around that white screen in the first place. LOD creates temporary textures that it does replace later on. Well i'd love to see this in stock KSP. Its partially the reason why i started LOD. But i doubt it will ever come unless Unity offers a way to load a texture without getting short freezes.

Hey guys, this version should be .25 compatible. Though i haven't tested very much. Most of my KSP .25 time was spent on a new un-modded space program that didn't made it beyond low Kerbin orbits because of relying heavy on ssto planes. ___ Its kinda interesting that download seem to be pretty consistent. I expected a much bigger hit by Squad releasing a 64bit version, especially on the long run. Glad you guys are using and/or do like LOD, but improving it can be quite time consuming and i'm struggling whether its worth it for "just another memory saving tool", to be frank. May i ask why you use/like LOD, especially compared to competitors like ATM or 64 bit. Should help a lot to know what to focus on in future development. It can't just be load times? I also hope it's not just because you weren't aware of those alternatives^^

Told you so So you guys haven't found a way without using reflection either? Damn it I think ill go with this for my stuff: typeof(GameDatabase) .GetFields(System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic) .Single(field => field.FieldType == typeof(DateTime)) .SetValue(GameDatabase.Instance, DateTime.Now); It makes KSP not reload already loaded images on startup, is way less invasive and imo how Squad should have implemented it in the first place. That way i can keep pretty much everything as it was, even simplify it since its not necessary anymore to remove the files form the DBs listing. Have thought about replacing the loaders as well, but my stuff only handles few textures, thus the replacement loader would have to forward calls to the games original code. That could get tricky easily, especially if multiple mods do so. I also despise DatabaseLoader<>'s seemingly "on image per frame" principle.

One problem is that seems not possible anymore to "hide" textures from KSPs own load mechanism. ATM and LOD used this to heavily speed up the loading process. Now you have to wait for the game to load the file, unload it and load the own version, what is an imo ....ty solution. ATM did this some time ago and could probably revert to it in case sarbian change isn't sufficient, but i hope we can figure out how to get it working in a non-stupid way, again. But so far i haven't found any using public writable properties. Hope to find one in this project but seems like we are all in the same boat. Also i don't understand why it's necessary to hide those loaded textures from GameDatabase's loader anyway. The logs says "OUT OF DATE" when reloading them, but there's no reason for them to be! Maybe a bug within KSP?

My Feedback so far: - Show Part details (MouseOver?) for Contracts before we have to accept those. I don't like having to look it up in the wiki. - Make those "active missions" sortable (drag&drop?). I'd like to have them in the same order i plan to fulfill them, especially on missions with multiple of them with ambitious conditions in a short timeframe - More infos for running contracts. Especially in the vab it would be nice to see whats the actual reward for sth. Had to switch between them quite a few times - Save system... I currently play somewhat casual & without mods. With no MJ predicting the landing site is complicated, and the rockets have much less margin for error (excess twr / delta-v) because of budgets, so failed missions are a lot more common now. But the goddamn revert feature breaks all the time, even by checking how long another ship is away from its maneuver. Having an "on last launch" save would be a good start and i wouldn't mind having 3-5 auto saves in a rotation i could choose from as well. Idk what exactly i wan't, but having to re-fly an hour long mission since jeb had to land in the mountains near KSC and missed one of the roofs by 50m, landing on a 100% degree slope wasn't that much fun. - I really hope there already is some kind of story mission. Haven't rescued the kerbal (currently night at KSC) or visited the moon yet, but it would be sad if there wasn't at least some small story arc. Yes, think i had this a few times as well.