Faark

Yea, the transparency of that window is indeed broken because of that stupid TGA loader that doesn't "find" any alpha channels. I'll see what i can do. There was some discussion earlier about converting them to PNG as temporary workaround.

Both! I'm a fan of SpaceX's goals, but spaceflight needs any competition it can get to promote R&D. And they better come up with some crazy cheap / efficient rockets, since i want to see a mars city grow within my lifetime! Thus i'm not very happy about the announced cuts to CCDev, even in case SpaceX wins the next round.

It isn't, since its just cil byte code. All objects have to go on the heap and thus have to be garbage collected. And this is what my mods disassembly looks like. It could only use the stack for objects that are created and only used within the current method at all, but i would hope the .net JIT would make such an optimization anyway. The only advantage that C++/CLI seems to have in terms of memory management is its deterministic object destruction, but that is nothing but wrapper around .Net commonly used IDisposable. GC has to do the cleanup nonetheless.

Both isn't correct. Mono is mostly compatible with .NET bytecode (since thats what it was supposed to be). The problem is that Unity uses a very outdated cut down version of the .NET class library. Yes you have to use .net 3.5, can't use a few types and should probably use an external tool to target a unity framework. Same for #2... you only need the correct references. And any reasonable KSP mod will include references to unityengine and ksp's Assembly-CSharp, so not a problem at all. @philotical: That's not real JS but their UnityScript.

Yes, i had to compile a specific part as 64bit, as expected. Here is a 64bit version that seems to work fine on my machine. You probably need the 64bit redist as well for it. Hope there isn't anything else missing. Thanks, downloaded the logs, will inspect them tomorrow. @Transparency issues: Has someone tested those parts with only a stock install, the particular mod of that broken transparency part and LOD? Hope i'll have time to investigate it tomorrow as well.

Well there are minor effects like they at least having some memory impact and the current version adds ~10 types, so all code that does reflection will be slowed down a tiny bit. That's ofc not significant unless this mod grows in complexity or is very frequently updated. I though about that for the error reporting stuff i'll probably never have the time to realize anyway, and one approach might be to manually load assemblies. KSP won't touch them as long as they are named *.notdll, allowing the mod to load or delete whatever dependencies it likes... But imo the more serious problem is trust. Automatically downloading and running code can end very bad for the user.... very very bad. Who cares about privacy of uploaded data when you can push code that uploads all my password files without me noticing. I certainly wouldn't install anything like that from some community member that isn't that well respected as you, but it still doesn't feel great.

Writes a list of Languages to code Unity mods with but doesn't mention UnityScript. But yes, C# is the popular language for KSP modding and rightfully so, imho. What makes you think it is so much faster? It makes interop with native code very easy and "direct", but otherwise the generated IL is pretty much the same as C# (At least telling from the disassembly of my mod). But using native stuff seems to also give you the same platform dependency drawback as using pure native code. Also why those focus on performance? 90% of all mods don't care about perf anyway (kinda the opposite. Had quite a few cases of infinite exception spams, what regularly freezes the game for a few ms to write the log to the disk). And even if they do, they usually should identify that bottleneck and replace it with better scaling code. If someone wants to start a new mod, choose a language you are familiar with and can get help. That's usually C#.

Guys please move that multithread discussion somewhere else. As someone who has a brief experience with multithreading does this just feel awkward to me. And no, LOOM doesn't magically make a game run in parallel. Thanks but those links give me a 403 error. Where they rly intended by dropbox to be shared? Also what is the exact part/texture that was wrong on those logs? PumpkinLanderCabin? No idea, yet. I still consider KSP fundamentally flawed for loading everything on startup, but a mod could never give the same experience KSP should have in the first place. From a tech point of view i'm not sure whether the current version of Lod would run under 64bit. Most likely not, but changing that shouldn't be that hard and would ofc take away any kind of memory pressure this plugin had.

Interesting, i always thought Unity does generate an exe file especially for the particular game. Knowing this isn't the case would have made stuff easier, might even have easily allowed getting a debug version. Unity places all directx textures in a managed pool, in other words DX keeps a copy of them in RAM for a few reasons. That might be the reason, though i have no idea how OpenGL handles textures.

Thanks, but please at least LoadOnDemand.log and output_log.txt for the next case. KSP.log can also be nice since it contains less "spam" and times, though the actual info is mostly the same as in output_log. The linked log at least doesn't contain any error messages and so far i haven't found anything else thats unusual.

As usual i want loooogs! Please use this version. It does log some more related stuff. And please play with LODs debug menu activated. Once you notice such an issue please press its "info" button, then gracefully exit the game (via main menu; saving stuff is fine, ofc) and send me those logs. I also need the full name of the unloaded image file (or at least a screenshot and the name of the mod & part). Btw: There is also an DontLoadEditorCatalogParts config option that could reduce VAB crashes even further, but please stick with the current config for now while researching those unload issue. Well, my idea was to get a stock install with LOD, write down its memory usage, remove pretty much all parts, and check whether the change in memory is as small as expected. Will probably do this later today. This way i can at least verify that the problem isn't within LOD itself. But mod conflicts ofc are a lot more difficult to identify. Btw, the current version of writes a lot of stuff into log files, include the name and in-memory-sizes of textures it doesn't manage (the version linked above even those managed by ATM). Having a look at those as well might be worth it?

Yea, that should work for now. But i hope that LoD loading images compressed via DXT will save enough to not having to care about sth like that anymore. If it doesn't then this project will need some other kind of reduction, ofc. Thanks for the report and pics. Especially that "sometimes" part is worrying. Load requests cannot be "dropped" or sth like that, at least not without leaving those x/y status screen open forever. Is there any interesting in the logs? Also it would be interesting whether the necessary textures of those parts are actually referenced at that time according to DebugUI => Info (that button does write that stuff into the ksp log). So far at least i haven't experienced anything like that by myself It highly depends on what is slowing down KSP. If its to much stuff to render smaller textures can help, but lots of parts usually mean slow frame rate because of badly scaling physic calculations. Possible? Yes. Likely? No, to be honest. For sure not anytime "soon" (valve time, if you know what i mean), as slow as the project is currently progressing... Yes, MBM is a fully supported image format for this mod, just like TGA or PNG. But LOD can only handle images (of whatever format) that it can associate with a part, so that might be a cause. Images handled by LOD are listed in both the log files and its config. But again the best way to say anything about some issue (or in your case observation) would be to get fool proof instructions on how to reproduce it here, preferably with a near-stock installation. I guess you didn't just delete some random MBM files?

http://forum.kerbalspaceprogram.com/threads/78955-RasterPropMonitor-MechJeb-and-SCANsat

Some mods just stopped doing this automatic versioning because it makes it hard to share functions between mods...

Debug UI is intentionally gone, you can re-enable it via the cfg. Details about the other issues incl instructions on how to reproduce it would be nice. Please also try to delete the old LOD directory and report whether this makes any difference. There is definitively some mod modifying LOD textures, either an old ATM version or there might be other TR configs that re-enable this. I had quite a few "Parameter not valid" exceptions in situations where the game was running out of memory, even though it should give an OutOfMemoryException. Have you verified that this wasn't the cause? Since so far i couldn't reproduce this kind of error any other way. I guess the diff are textures that are handled by LOD and not loaded, thus don't require any memory.

Yes but error logs don't have to be submitted automatically. Just show the user the data and let him press "Send this stuff". At least from a legal pov this should be safe? Maybe with some flag to only Most assemblies don't have a version info embedded, so you might have to do ugly stuff like generating a file hash and resolving that from your database. Also error reporting has a bunch of other difficulties, especially preventing spam of known reports or resolved issues. It would extend this project by a lot and would require constant effort to maintain the project and while it would be awesome, i can understand that Majiir doesn't want that.

Interesting. DL stats are nice, but usage statistics ofc a lot better! How are reports intended to be? Mod devs contact you and get access to only their own mod stats? Or public stats? I wonder whether some mod authors would have a problem with that. The other day I was about to pm you about a concept of a mod that gathers error reports, since it is ultra annoying getting error reports from users where other mods spam exceptions all over the place, but wanted to sleep about it hadn't yet found the time to finish it. Hey Majir, do you still have spare server resources? What about an error reporting service for KSP (mods)? Its kinda annoying to get error reports with thousands of exceptions caused by other mods you have to ignore just to find the one line that's related to the actual problem the player is complaining about. I did something similar for a now dead javascript project some years ago and think it really helped to improve the quality of that code. A first concept could look like: - user downloads a separate error reporting mod for KSP to install in GameData - mod downloads a white list every few days for known or unfix-able errors, e.g. those caused by KSP itself - mod hooks into KSPs / mono's error handling and collects info - if there are exceptions or warnings to report user gets a "issues found, click to report" button. -- can or will contain additional info (full output_log, installed file info or whatever) -- can review submitted info -- can add additional comments -- screenshot? -- gets a report id once submitted that he give to devs - user can submit a report without exceptions but comment in case he experiences issues. Thus no need to manually collect and upload it - report can be shared and viewed online via its unique, randomly generated report id - reports have to forwarded to the developer of the respective mod causing it and might be white-listed, at least for some time - once the developer thinks he has resolved the issue reports and ignore logic can be deleted. Also old reports automatically, ofc. - if it identifies mod, it can probably even list recently added mods... - since its a separate "you have to install this" mod, the initial user-base and thus initial workload for the maintain should be manageable. Especially since he doesn't have to fix the actual errors himself^^ - privacy shouldn't be a concern since the user has to install this mod manually and manually submit reports Problems i see so far: - old mod versions. Version checks would be great but don't see a good way to do this right now. Maybe such a project would help in that regard - its a manual system. i don't see a good way to automatically distribute reports, at least - abuse. I don't see a lot of incentive to abuse this system above any other, but still it would be a [specialized] file upload service. So what do you think? Is something like this worth your support/server resources? Regards, Faark aka [..] Do you think this statistics mod could one day be expanded to include sth like this? Both tasks share at least the requirement to identify installed mods. And error info could be way more useful when refined with usage info, so they might rly benefit each other. But ofc would make the mod way more complicated, possibly even shifting the focus of this project to it wasn't supposed to be or sth you just don't want for this project. Do you think it could be worth expanding this mod to also log errors?

Okay, i spend way to much time today testing with a 85 and 250 [lod-]textures launch pad scenario. V SpaceCenter LaunchPad (WorkingSet/Commit) 84tex v3 1g121/1g267 1g450/1g665 v2 1g140/1g215 1g500/1g600 v3 1g155/1g272 1g450/1g680 v2 1g141/1g220 1g500/1g592 250tex v2 1g154/1g226 1g757/1g842 v3 1g144/1g267 1g783/1g914 v2 1g154/1g234 1g737/1g841 v3 1g155/1g279 1g800/1g942 v3 1g156/1g271 1g773/1g972(f) v3 1g155/1g268 1g790/1g890(n) v3 1g151/1g261 1g855/1g950(f) v3 1g149/1g270 1g780/1g908(n) v3 1g016/1g268 1g660/1g892(n) v3 1g157/1g269 1g941/2g036(f) are as expected v3 required about ~60-80mb in total. Measuring it is kinda complicated, since everything can have an impact. For example an focused app during SC=>LaunchPad had 40-150mb more memory committed. But stuff like that is in the nature of multi-threaded applications. I cannot reproduce such a significant increase in memory usage. There are some fixes that might relate to your issue. I changed some handling in case there were 2 similar named files with different extensions. Do you have stuff like that in your GameData? Did the amount of textures changed between version in the first place? (You can re-enable the debug UI via cfg) So far this kind of errors was always caused by a missing dependency, so please try to re-install all dependencies listed in the first post, including DirectX. Btw: nvd3dum.dll is the file used by KSP, not the one required for LOD. Thats exactly what LOD is supposed to do. It currently does not offer any kind of "low-res" textures and i hope this will never be necessary (apart from DXT compression, what will be one of the next features and should help a lot). LOD tries to always have enough memory available by not loading textures unless they are required, but itself requires logic to know when those textures are required. It currently only has those logic for part textures. ATM instead just scales down textures, thus is a perfect to handle textures LOD can't. Help would be appreciated, ofc!

Hi frash, this mod works on the layer below the unity engine and directly interacts with DirectX. I'm afraid the Linux version uses OpenGL, what this mod currently doesn't support and probably won't for quite a while, thus making this mod Windows only for now. @Alewx Found and fixed the issue causing the hang. Still not recommended to let TR mess around with LOD textures for the reasons mentioned, ofc. @SpacedInvader Did you ever buy a car that didn't work and then asked you mechanics to put the case of it around your old one, since the new one looks that nice? All changes i made to LOD i made for a reason and ofc won't support the old version. But i can't imagine what change could result in a large increase of memory required and thus as stated will look into the issue you have reported. That means I will try to reproduce the issue, find the cause and fix it. I didn't yet had time to do so, but as usually with mod issues you can help by giving fool-proof instructions on how to reproduce the issue. Preferably with a stock + lod install (or the instructions including what other mods are absolutely necessary to reproduce)

This [noparse]TextOutsideOfSpoiler[SPOILER=BlueTextToClickOn]TextOrStuffInsideTheSpoiler[/SPOILER]MoreTextOutsideOfTheSpoiler[/noparse] will looks like: ______________ TextOutsideOfSpoiler TextInsideTheSpoiler MoreTextOutsideOfTheSpoiler ______________ Also keep in mind that there is a preview feature you can use to tweak you spoiler until it works as intended.

To me it looks like the KSP forum is kinda "session" based. It will only mark you threads as unread that had new content between the current and the last session. This kinda makes sense since you don't have bazilion unread threads all over the forum, but can be annoying if you haven't read a thread in the last session (since you just wanted to DL a mod via google) or were distracted and didn't do anything on the forum long enough that the forum considers your comeback as a new session. Understanding this rly changed the way i'm using the KSP forum.

Ty, will be interesting to compare that to my test install. There is some mod messing around with LOD textures (try to remove TR for testing, disabled its compression and mipmap feature, etc). v2 could kinda handle this situation but i apparently missed a bug that prevents v3 from kinda-recovering. Bad in both cases, since it forces LOD to re-create its cache... You re-created those tga's from the png files using some program? My guess is that the original files don't fully follow TGAs standard (and/or the loader doesn't), but the program did a better [/ different] job creating TGAs. Ofc not. I'll look into it.

Anything else would be surprising since texture compression isn't yet implemented. I just added those compression flag since this feature was already planned when i created the config in the first place.

Thanks. This new version keeps some memory reserved for disk IO, thus some increase is fine. But it should only be between 32mb and your max texture file size (even though about 2x max size for faster loading, but kinda happy now that i didn't). I'll investigate on my test install, but some logs would be nice as well, especially those where DontLoad = false did crash the game. Please also re-download LOD from the link above, since it now also logs disk buffer size changes. @TGAs The slow / manual / non-batch way is to open the problematic TGA with e.g. GIMP and export as png (default settings should work). To make LOD ignore a particular file, open GameData\LoadOnDemand\LoadOnDemand.cfg, find the tga file and add "SkipImage = True" to the files configs. *edit* Okay, i tried my smaller test install: v2, 2nd start: 12sec, 0g915 w, 1g165 c v3, 1st start: 43sec, 1g182 w, 1g275 c v3. 2nd start: ~3sec, 1g082 w, 1g197 c (w = "Memory (private working set)", c = "Commit size")v2, 1st start: 66sec, 1g126 w, 1g212 c Its interesting that the "working set" size with v3 is mentionable larger while the commit size is kinda the same (+the expected 32mb). Commit size is what is important in terms of 32bit oom crashes, so i hope we are fine. The task mgr doesn't show this column by default, btw.

Okay, the transparency issue is definitively caused by the TGA loader LOD uses. Its this 3rd party code and should be able to handle transparency, though. No idea why it always detects the img format as rgb without alpha. Would love to replace it, but there doesn't seem much to choose from... So yes, for now you have to convert TGAs with alpha channel to e.g. png or make LOD ignore them via its config. Btw, when converting make sure KSP doesn't load both the PNG and TGA version! This would explain an increase in used memory (if your lucky LOD thinks it needs both and "only" prepares 32x32 versions of them). Deleting or renaming them to sth like "*.unusedtga" should do the job. It shouldn't be necessary to touch anything else (mu or mbm files) for the transparency issue and shouldn't really save memory as well. Are you talking about the 2x1 greenhouse containing green leafs? Works fine for me once i got rid of its 3 tag's in favor of png's. Anyways, could you guys please test this version and report and any changes you notice? Especially stuff like slower loading times for high res textures or other regressions...