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.

Yes sry, i'm pretty busy with my education atm, thus barely any time for KSP. I've now enabled email notifications for PMs, so... Shouldn't be a problem, just did and will have a test run and upload if there are no issues. *Edit* Done, no issues on my stock KSP 0.24 test flight (both 32/64): v3.2 (same as v3.1 but works with KSP 0.24) Having all stuff load at startup is still crap imo, and not just because of load times. But cant blame Squad for doing so, just Unity for not providing the necessary tools.

C# bytecode (those .dll files you generate) are supposed to be platform independent. The runtime should take care of that for you. Thus you should target "Any CPU", unless you're doing stuff that requires a specific one. I doubt there will be a mentionable difference, but you can check that yourself... just create both version dlls versions of your own mod and compare their IL byte code with something like for example ILSpy.

RPM works fine on my test installs (Screen) with the latest LOD. Are you sure this isn't caused by some other mod? And what other mods are involved anyway? *sigh* Thats the kind of the issue i was afraid of... the now existing alpha channel is causing trouble in case its badly used. Had a similar problem while down-scaling images to low res not-loaded-thumbnails. They don't look great anyway, so i could use a crappy looking workaround. But that's ofc not acceptable for full detail images. Thanks for the reports, guys. I'll look into it. Its an OutOfMemory error. This is fine (*) if your KSP was already very close to the max amount of memory. But ofc could also be a bug, if there are some memory "spikes" or sth like that (I'd love have a vmmap graph for your particular case, but will also generate one like this it myself). As mentioned early, DXT compression is the next bigger feature coming to LOD (& probably the last till this mod reaches Scope Completion) and should reduce memory usage of loaded texture and thus crashes a lot. Another approach might be to instead of crash just "abort" the load and display some kind of "could not load textures X. Ignore, Retry, ..." msg. Will think about it. * = ofc not for the user, but from a development stand point.

@Unanimous Fu my fault, i uploaded the wrong file (same as earlier). Please try again, i've now uploaded the correct one. @Beetlecat Its just about the bug reported by BananaDealer. TR replacements for parts are still not supported.

Thanks. Wow, you have a lot of mods screaming in your log files. The one LOD complainied about seems to be caused by TR killing textures unrelated to LOD. But LOD still didn't expect such "invalid" textures when it collects debug infos about textures it doesn't manage. So yes, nothing serious at all in case this particular case, though I've uploaded a fixed version (same link). Also interesting that it doesn't happen on the last version. ___ Anyone else found any issues or can i update the start page link?

Hey Unanimous, you are talking about version 3.1 i linked in the post above yours? I cannot reproduce this error on my test installs. Could you please share you KSP_Data\output_log.txt and GameData\LoadOnDemand\LoadOnDemand.log?

I don't really want to know anything about TGA file formats, to be honest. That is why i am using external code to take care of that and it seem to handle quite a few cases. I have no idea who is breaking the format rules (and frankly don't want to know), but this mod a. has to load those apparently somewhat frequently used TGAs properly and b. most other loaders i've found on the net and could switch to seemed to be very "limited", thus also not an optimal solution. Instead I now have modified the current loader to default to Argb for 32bpp TGAs. We'll see whether this breaks sth else... please leave a note in that case. Thanks again for the reports, it should be fixed with the next version. Actually, here it is: LOD 3.1 - TGA transparency fixed, Parts not loading fixed

No, it doesn't make a lot sense. A place where "all mods" battle around attention isn't the right place to get informed about updates, since this solution "doesn't scale well" and you always will be slammed information you don't care about. A better approach might be to make a subforum where mod devs can make an extra thread for each mod only to announce updates, beside the usual thread for that mod. It would serve as a changelog and this way we could even subscribe & get e-mail notifications when loved mods are updated.

Oh sry, you didn't knew. KSP uses Unity and Unity does stuff the Unity way. Their messages don't require you to "overwrite" anything. The class just needs to have a method with such a name and signature. It doesn't even have to be public. Unity will call it via evil magic you probably don't want to hear about. Check out some other mods in case you want some examples. Even usual non-part KSPAddons are MonoBehaviours, just like PartModule is.

You probably want MonoBehaviour.FixedUpdate (and other messages listed for MonoBehaviours). OnFixedUpdate is something KSP specific and because of that probably behaves weird