Faark

I would expect one of the 3 most common causes: - Not properly installed / working - To many non-part Textures and thus not enough memory - Some kind of internal issues (incompatibility, crazy file, whatever) Logs would be nice to know what is actually going on.. Especially GameData\LoadOnDemand\LoadOnDemand.log and KSP_Data\output_log.txt, pls.

Not getting spoiled about ARM is getting harder every day. Hope it will come out soon!

@Non-Windows Yes, one bigger problem is DirectX and the way its currently written doesn't make it easy to provide an OpenGL version as well. I hope there will be time to do so, but last time i checked Steams HW stats (currently down) Windows was by far the most frequent used gaming system, so thats where my priorities are for now. Btw, next version will use net4.0 instead of 4.5, to support WinXP as well. @sidfu / LOD does not manage all textures / non-part-textures like planets It only handles part textures! To load and unload textures this mod have to know when textures are used. It currently does so by tracking vessels in flight / parts in editor. For anything else we would need logic to load and unload those textures. For parts it currently uses a not-that-smart directory based heuristic. Feel free to share your KSP.log, if you think LOD should manage more textures. It currently logs all textures it doesn't managed (search for "REM_IMG:") so we can check what it misses and what we could/should improve. @changing texture quality Never used that feature, thus never considered it when working on LOD. Will add it to the todo list, but with a lower priority. Thievery! But seriously, it will be interesting how you do that without making the game appear to be crashed for a long time^^ @BananaDealer Any idea what finally solved your problem? In case others have the same issue... @Bloodbunny Thanks, il'll have a look. @TomatoSoup Do you have problems with this mod accessing your harddrive? It shouldn't influence your game and only take slightly longer, so creating sth like that doesn't really seem worth the effort for me for now. Apart from that use current window versions (8 for sure, duno about 7) unused RAM to cache frequently used file, so the physical drive might not be used anyway.

Hm, TextureReplacer doesn't seem to replace part textures, so that shouldn't be a problem. But it does try to compress all textures... likely including the ones this mod wants to handle. You might want to try turning it of in your TextureReplacer.tcfg (isCompressionEnabled). StretchySRB is probably an easy fix (next version), looks like i missed to set the textures name. Can't ofc tell how it will behave once the names are like in the stock game. What do you mean with "sort of"? Low-res-version? Does that mean you do notice this mod loading stuff? How bad is it? There will be mod incompatibilities. But this mod works on a white-list (i kinda create my own database of textures that probably belong to parts) and only handle those textures, so "partless" mods should be fine (though they clutter up memory, of). If it gets established i hope to provide an easy-to-use API in case someone want to integrate optional support into his mod. Haven't looked at Distant Orbital Objects, yet.

Wait, crashes are great. This build is supposed to crash on any form of texture loading issue, so we will actually notice, can identify and resolve issues. Can you send me the logs, pls? KSP.log, KSP_Data\output_log.txt and especially GameData\LoadOnDemand\LoadOnDemand.log But yes, ActiveTextureReduction might be a problem. It might attempt to compress textures, what this mod doesn't yet support and thus "quits" once it encounters a compressed texture.

That is definitively the intention. But it looks like i have missed a dependency that was present on the computers i developed & tested on. Hope to have more information later today. Update: I think it is Visual C++ Redistributable Packages for Visual Studio 2013. Microsoft offers versions for 32bit, 64bit and ARM (nothing to do with asteroids in that case^^) devices. This mod does require the one for 32bit, filename "vcredist_x86.exe". I haven't found a direct link to that file and worse, the old dl link defaulted to a wrong version. Please try this one, it will at least force you to choose.

It shouldn't be noticeable, yes. Thats kind of the point and the mod already does so (though there might be a delay... thus the current version might crash on very fast VAB browsing). For the better, i hope (Though FPS shouldn't really change) Interesting... scary. Through it would/should be gone with next version anyway. It will be gone once the next version is out, hopefully tomorrow. For now just drag it somewhere in the bottom where its pretty much outside of the game window and doesn't distract you. Still crashes? It shouldn't, unless there are some nasty mods that spend lots of RAM on part-unrelated stuff... Kerbin City really took a lot in my test environment. Have you properly installed this mod and its dependencies? In that case log files would be nice, both output_log.txt and GameData\LoadOnDemand\LoadOnDemand.log

It seems like persistence files and craft files partially use the same code for saving. And it seems like PartModule.OnSave(CfgNode) is called after all Fields are already written. The easiest workaround might be to write your data to the given ConfigNode directly...

A little less than 4min to the main menu. Thats the beauty of not loading textures on startup Though it admittedly takes another ~2min until background-loading part texture thumbs finishes.

Hey guys, this mods loads textures as required instead of on start. It is still far from done (thus not being under releases... loaded textures are not even DXT compressed), but it is time find out about potential compatibility issues and collect a bunch of helpful crash reports Download Plugin Version 3.3 (for KSP 0.25; Different versions; Source available here or via ILSpy) It is an experimental release, so don't expect it to not break anything! Key features - Part textures won't be loaded on startup (cuts initial loading times pretty much in half). - Starts to background-load a low-res 32x32 thumb for any texture managed by this mod once the game finished loading. - Once a texture is required (used in flight or editor), the mod will replace that thumb with the high resolution texture. - There should barely be any performance impact at all caused by this mod loading textures. Installation - Make sure you satisfy all requirements (see below). - Download zip archive and drop the containing .DLL into GameData. Requirements - Windows & DirectX9 only, for now. - Latest .NET Framework (4.0) installed. - Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x86.exe) installed. License All rights reserved for now, until i've decided what real license to use. You will likely get approval for *insert stuff*, so just aks. Do whatever you want as long as you mention that your stuff is based on this and ofc do whatever is inferred by licenses of 3rd party stuff used by this project. Known Issues (at least the more important ones) - Not really a problem, but even compared to stock KSP the current memory savings might not be as huge as expected, since this mod currently doesn't compress loaded textures. - The current versions aims to crash KSP in case of unexpected situations. Please report those. - Textures used on Parts might be up/down-scaled depending on part-lifetime, regardless of potential other usages. - The current memory management is rather underdeveloped and will happily attempt to load more textures than memory available, resulting in a crash (e.g. when quickly browsing parts in Editor). Mod Compatibility - Active Texture Management: Compatible since ATM 3.0. LOD will not work with older versions of ATM - TextureReplacer: You have to disabled texture compression and cannot use it to replace part textures. - Other mods might depend on LOD or like ATM would take control of textures thus preventing LOD to do the same. Thus LOD usually has to be loaded before those are. KSP loads mods as it finds them, and it recursively searching for them in GameData. Files are processed before directory, each sorted by name. The the following mods would be loaded in this order: GameData\ModA.dll GameData\ModC.dll GameData\ModB\ModCode.dll GameData\ModD\BlaStuff.dll The easiest way to make sure LOD is loaded first is to drop the DLL file directly into GameData, without creating a subdirectory. Feel free to rename the DLL, in case you want stuff like version info. You can also place it into a subdirectory, but you better name it sth like "aaLoadOnDemand", so it is loaded before ATM. Regardless of what you do, LOD will create GameData\LoadOnDemand for its config and temporary files. - Please report any problems you occur when using LOD and please be detailed as possible. * Logs: Beside KSP's usual detailed log at KSP_Data\output_log.txt LoD also has its own file at GameData\LoadOnDemand\LoadOnDemand.log. Both should usually be included when reporting an issue. * RAM: LoD will often be used when available memory is rare, thus a lot of problems are memory related. Task manager isn't particular great for that job as well, especially in its default configuration. Microsoft's VMMap is a great little tool to visualize the actual memory usage of a process. Use it e.g. to verify there actually is enough memory available, and saving & including one of its mmp-files can't hurt as well. Thanks for your interest & testing. I hope this project will be useful to you and any form of feedback is welcome!

Oh yeah, lets compare sizes. My GameData directory is 5cm bigger than yours! Proof:

No, scenario modules might be great to save data into a game save, but i don't see how to use them on a ShipConstruct / craft file. That seems required for your project, though...

Keep it simple, especially for the first test release. Couldn't you just combine all of the current parts AG assignments into a single string? Kinda like struts do... I don't see how else you could save data into a ShipConstruct and thus a .craft file. A dummy part might work as well, but would make even more problems when removing your mod. ps: Are you sure your problems are Multi-Threading related? Would surprise me. Can't await to inspect your code for details

I would approach it the other way around: Create a savegame with your debris vessel, inspect its ConfigNodes and learn how to generate those ConfigNodes, then create the ProtoVessel from them and use its loading code...

Afaik isn't he really looking for that kind of dependency. AG methods are defined as usual in KSP and he can use them. But utility features like managing or firing those custom action groups will be a problem. Imo, the best approach would be to offer a .cs file doing exactly that for the users. It doesn't just offer compatibility but also provides a simplified API to do so, that way how ever wants to use it doesn't have to learn the KSP-way to do the same in the first place. Though i'm not really sure what features an action group manager should expose anyway^^ Guess the best solution would be to just release the mod for now and think about such stuff later

Why? Modding is "Do it yourself". You barely ask Squad to implement feature X so you can make mod Y. And yes, thats usually not easy. But asking modders sth *edit:* something like this seems to be against the philosophy in the first palce^^ As for an auto update feature in a mod-managers... i don't think you have to track more than maybe two dozen mods to provide a real benefit to most of your users. Thats definitively sth someone can do manually yourself, if he is serious about getting sth like that started.

As already stated... there is no reason to force sth like that. If you want to index mod, feel free to build up and maintain such an index yourself. Its not that hard to do so, might require half an hour per day to get current versions for unknown checksums. Sure, your request looks rather simple. But there are an infinite number of possible "simple requests" that would pile up. What about a version history? I would like a contact address for legal issues. You could always come up with just one additional simple request that shouldn't be a problem at all. Thats why any request will looked critical upon, especially if there isn't an immediate benefit. And there isn't really any for this one... no one is indexing mods or allowing auto updates anyway. But if you actually already provide a tool that does sth like that, a request like this would be sth totally different.

Reflection is the only reasonable (and by the way highly efficient) way to go, if you can't avoid a dependency altogether and the other mod does not necessarily need your mod. I don't see the any real difficulty here, since you provide a fully functional .cs file that does all the heavy lifting and that they don't have to edit at all. Btw, best thing would be if its behavior doesn't change, regardless whether your mod is present or not. If it is, use your Code... if not, fall back to what the stock version of that method.

You could also try to add an new element to Events. Though this will probably come with some issues you have to resolve manually, like GUIs not properly updating (though that might be an issue anyway; there was some expensive code to force-update the right menu in some forum thread) or KSP trying to save & restore your events. Haven't used it in a while, but the code could look sth like that: class myBomb: PartModule{ void updateEvents(){ Events.Clear(); if(ExplodeEventAvailable){ Events.Add(new BaseEvent(Events, "explodeMyBomb", ()=>{ Part.Explode(); // more logic to dmg related stuff }, new KSPEvent{ guiName = "Detonate NOW!", guiActive = true }); } foreach(var vessel in VesselsInCloseRange){ Events.Add(new BaseEvent(Events, "targetVessel"+vessel.id, ()=>{ SetTarget(Vessel); }, new KSPEvent{ guiName = "Target Vessel "+vessel.name, guiActive = true }); } } void Awake(){ updateEvents(); } void SetTarget(Vessel vessel){ // ... } }

I would certainly like to see you play with Lego for science Btw, since this is a thread about repulsion-less propulsion... I always wondered why you can't use earth's magnetic field to accelerate a spaceship.

Wow, they really are. I never noticed when setting up my action groups in the VAB^^ Though i don't see a problem with his DeployEvent(...). An UI label like KethanDrillXXL->Deploy should be easy enough to understand. Unless ofc the part creator did sth really crazy... but since you have the same data as KSP has for its action group manager, it would mean this parts action groups are crap anyway, even without your mod.

I'm not 100% sure what your problem is. If you are designing classes, there isn't any problem with designing a simple "tree" structure similar to KSP (pseudo-example, KSP is ofc a little more complicated): class FlightGlobals{ public static List<Vesel> Vessels; } class Vessel{ public List<Part> Parts; } class Part{ public String Name; } UnityEngine.Debug.Log(FlightGlobals.Vessels[1337].Parts.First().Name); What i don't understand is "without an instance". The only way to store a string in an class is via an instance or a static var. Ofc you could write all into a single line: AGXVessel.Parts.First().Name (yours looks a little odd, btw)

Well, you can specify your own log callback and write/filter whatever you want, for example a KSP.log-like file that includes stack traces. Check out KSPLog.AddLogCallback(...) and/or Application.RegisterLogCallback(...). Though i'm afraid you cannot write into KSP.log that way. "WheelCollider requires an attached Rigidbody to function." is most likely a warning generated by Unity itself.

Well, not exactly. Squad made the files we are talking about in a way that already expose a lot of information & functionality, including ways to remove/replace some functionality. Together with Unity's API that should be enough for most mod ideas. But you better not get caught using a decompiler to peak behind what exactly one of those exposed methods does.

There are actually a lot of things you are not allowed to do, no matter whether it is on you own computer or not. For example stuff like ordering a contract killing or (in the light of recent events in germany) any kind of **** involving minors. If you made an valid/legal agreement with Squad, and I'm pretty sure you did agree to their EULA somewhere when buying or installing the game, you have to comply with it. Thus Squad could drag you to a german court and you would still loose. You better not get caught decompiling KSP^^