Faark

Yes. Just change the part's mass field. Ofc building a real plugin that does sth like that is more difficult, since you might have to do stuff like saving that data.

Yes, thats a difficult question, especially when considering version compatibility. Another mod that implements your interface would have to create a separate DLL for the your-mod-specific stuff anyway (unless it fully depends on your mod). This separate DLL will fail to load without its dependencies, what is kinda fine for KSP installs that doesn't have your mod installed. A problem might be the order in what mods are loaded. The depended assembly has to either be already loaded or has to be in the same directory as the current dll (+ some other specific paths not in GameData). A working solution could be for your mod to place a dll with those public interfaces directly within GameData (should be loaded first) & never change its version number.

Try to just name your texture model000.png, remove the mbm's and load the game. The current texture management within KSP barely uses file extensions any more, so it will work regardless of what file extension is stated in the MU file. Extensions in there likely only exist for backward compatibility. Afaik, MBM is a proprietary file format created for KSP. A small header + uncompressed rgba32/rgb24 data. It's crap and you shouldn't use it, but can find details about it in for example this source: http://forum.kerbalspaceprogram.com/threads/47068-mbm-Texture-File-Converter

1. I'm not aware of any, but implementing sth like this with Planetarium.GetUniversalTime() shouldn't be that hard. 2. Jop, that should work. Here is some code i used to find the game's file loading classes and stores them in dictionary by file extension: return AppDomain .CurrentDomain .GetAssemblies() .SelectMany(assembly => assembly .GetTypes() .Where(t => t.IsSubclassOf(typeof(DatabaseLoader<T>)) && t.GetCustomAttributes(typeof(DatabaseLoaderAttrib), true).Any())) .SelectMany(t => { var loader = (DatabaseLoader<T>)Activator.CreateInstance(t); return loader.extensions.Select(ext => ext.ToUpper()).Distinct().Select(ext => new { ext = ext, loader = loader }); }).ToDictionary(el => el.ext, el => el.loader); The code basically loops though all loaded classes, does some checking and uses Activator.CreateInstance to create the actual instances. It worked fine for KSP's stuff and should have for any other assemblies as well, though i never tried that. IsSubclassOf seems to not work on interfaces, so you might want to check out other stuff like IsAssignableFrom or GetInterface.

No. Guid's are randomly generated and supposed to be unique though pretty much all of mankind (exaggeration). That's the only reason to choose such a data type instead of e.g. int. A Wikipedia quote: The total number of unique such GUIDs is 2^122 or 5.3×10^36. This number is so large that the probability of the same number being generated randomly twice is negligible;

Can't say whether such a plugin exist, but how exactly do you want to realize it? A public market for everyone? That's kinda difficult, since a digital market does only make sense if someone the market trusts has actually control about the digital goods. CPP has, since they host the EVE servers. But KSP is a pure client game and you cannot trust the client to not cheat. So you either have to create lots of private markets that work via invite / authorization or you can only provide and somehow simulate prices without the possibility for clients to change data. Kethane might be a problem since it has a pretty restricted license.

I'm not aware of any. I "solved" the problem for myself by installing Visual Studio on my notebook and using Remote Desktop whenever i sit on another PC.

Letting someone else do the OS specific stuff? That's actually a great idea, even more if that could would supports multiple platforms. I was kinda afraid we would have to deal with 32vs64 bit stuff

NAT (actually, we are talking about Port Address Translation, but lets keep calling it NAT for simplicity) does offer quite a lot of protection to the common folk. It was invented so multiple clients can use the same external IP. For that, ports have to be dynamically assigned. If you send a web request for lets say port 12345 to google (port 80), another client does the same and google would respond to port 12345 for both requests, your router wouldn't know to what internal IP he should send the data to. Because of that he maps the sending port to some other available port that is reserve for you only and that google can respond to. Any response to that for you reserved port will be forwarded to your PC and port 12345. But your client has to start the communication to the outside to create such a port mapping, otherwise there is no way for your router to know what local client he should send the data to. You cannot really portscan a PC that is behind a NAT (*). And since blocking port is one of the primary things firewalls do (especially older ones), NAT has taken away a lot of their job, especially for security products that are/were targeted to non mobile home PCs. Also i don't get why you are fixated on security. Yes, with this stuff someone sending commands can do pretty much everything a mod can do, what is basically everything it wants. But this is something people will set up in their home LAN, hell i guess most of the time it will be on the local PC and not go via network at all. Yes, i would highly advise against using something like that via the internet or on a public network / wlan. And yes, authentication, encryption and stuff like that would be good. But is "implementing state of the art security" really what the projects current focus should be? Its good enough to use for someone who kinda knows what he is doing, IMO.

I agree with Orbits. The point of USB was to get rid of lots of different ports wherever possible, and we still got enough of them, so introducing new ones is the entirely wrong direction.

Here is the necessary part ripped from Mono's System.IO.Ports including some preparations for dynamic pinvoke. The native dependency (as mentioned above, mostly from serial.c) and its loading code is still missing, i hope Monk can contribute it.

Textures can be unreadable for other reasons than "is stock part". True, stock-ksp does load all its MBM files as unreadable, but normal maps will become unreadable as well and some texture related mods do this as well. It kind of makes sense, since this means Unity/DirectX can transfer the texture to GPU memory without keeping another copy in system RAM (=> kinda less memory usage). As for "how to fix t hat"... well, you can't, afaik. You can either go native and use e.g. DirectX directly to read the texture (you should try to avoid that for a number of reasons) or manually load the texture from disk... I haven't yet tried it, but from looking over the code: - where do you prevent the game from copying the texture when the player has not selected a custom color? You know, since this should be the default for most cases & memory isn't free. Sure you have alpha == 0, but the default value for every part seems to be 3/4 - where do you re-use textures painted in a specific color? Same reason as above... the img in your start post could save 6 textures that way - mipmapCount is always > 0, you want to check it for > 1 - why do you manually update mipmap levels? That should be done by Unity / DirectX for you. Thats actually the reason you pass "true" to Apply - I'm pretty sure GetPixels32 does returns a new array and copies the textures data into it. In that case you might not have to create another one - What about other texture formats? That currently annoys me in an own project. Do you plan to stick with ARGB32 for everything in a longer term?

Okay, there isn't much we have to take from mono to successfully compile against Unity 3.5 .net full Base Class Libraries: ISerialStream, SerialPort, SerialPortStream, SerialSignal & WinSerialStream WinSerialStream would actually be the windows stuff and depend on kernel32. SerialPortStream on the other hand depends on the native MonoPosixHelper (and libc). That's most likely the reason that class was cut from Unity-Mono and sth we would have to provide. I'm not very familiar with native code, but here is a VS project file that seems to be for what we want. It appears to compile few of the c files from this directory. So that might fit your expertise more than .NET stuff Once you got the native library, we still have to make sure the PInvoke does work properly. Unfortunately, the default lookup path appears to not include the directory of our dll-assembly and placing it somewhere outside of our GameData directory seems like a ****ty move & would complicate installation. As mentioned in my first post, in another not yet released (but windows-only) project i am using LoadLibrary from kernel32 to load my library from wherever i want. Guess you can do sth similar on non-windows? Though this stackoverlow-question implies that there might be issues and recommends dynamic pinvoke instead... what would be an OS-specific task for you to solve, again.

Uhm, you do have verified that the actual SerialPort-Library you are using is cross-platform? Your not using the standard .net/mono lib, so mono-docs are most likely not very helpful. Some quick googling for OpenNETCF.IO.Ports turned up this stackoverflow question, where an very old answer states that this is basically a wrapper around kernel32.dll. I couldn't find any source that produces the same library as zitronen's SerialPort.dll, but what i found doesn't look very promising as well. If OpenNETCF.IO.Ports does in deed require windows you have to find a port library for .net that does offer cross platform support. This might be not as easy, since .NET & Mono both come with a default implementation... Worst case might be creating such a library yourself from old Mono source or by back-porting the current version (ps: as already linked earlier). In that case i highly recommend you use a dev environment that compiles exactly against a unity runtime, so the compiler will notify you about other missing dependencies.

@magico A quick search in visual studios object browser found out that FlightDriver has two static methods that might be interesting for you: static void FlightDriver.RevertToLaunch() static void FlightDriver.RevertToPrelaunch(GameScenes sceneToLoad) ps: Keep in mind that this should reload the game and thus will kill most MonoBehavoir-instances. KSP should ofc create new ones as configured once the new scene is loaded.

Actually, Unity's mono environment isn't a standard net environment and just doesn't include System.IO.Ports. Such missing stuff is even more annoying when using third party libraries that depend on it. In your case would the compiler at least notify you, would you compile against the actual System.dll included in KSP. But thats even more tricky unless you let sth like UnityVS set it up for you. Anyway, back to the topic... you seems to have found a working port library. If not, another approach would be to use Mono's System.IO.Ports code... though getting it to work would take some time as well.

Interesting, but i was actually referring to code to use my own little profiler on^^. You know, since "what is faster" questions usually don't lead anywhere as long as there isn't actually a problem...

Na, your algorithm should scale just fine and have a negligible performance impact as long as you run the quoted code just once per frame. You might want to worry about saves with lots of debris (amounts with 4-5 digit), but that should be fairly rare. The performance issues i found in mods (mj2 & rt2) where when such a code was in a function that itself was called thousands of times per frame. Is there sth available to run some measurements on?

GameEvents.onCrewKilled. It should give you a name of the Kerbal you can use to find its ProtoCrewMember and might additional infos. There isn't any easier way i know of... you could ofc subscribe to a lot of other events...

All true (sounds kinda like the On/OffRails problem), but how to fix it? What about drag? Collisions? Decoupling? Acceleration by exhaust produced by other engines? Sounds like you would have to re-implement the entire physics engine and most other stuff in KSPs. And no, i ofc can't offer any good solution. Is precision that important while the vessel is off-rails? (Yea, I'm looking forward to read about the math involved as well )

There is a CelestialBodyScienceParams class that looks pretty much like what you want. An instance is accessible via CelestialBody.scienceValues / FlightGlobals.Bodies[index].scienceValues. Never looked into planet loading, so no idea where you can find them "outside" of an loaded KSP solar system.

Is it rly that inaccurate? I only have problems with stock orbital mechanics in two specific situations: - SOI transitions. The game should use sth like the patched conics there, since currently a high timewarp can screw the intended orbit. The system should not just patch orbits from different SOIs together but also stuff like aerobreak-segments (when entering atmosphere) - GoOnRails / GoOffRails... this isn't very accurate and starting & stoping timewarp has a messurable effect on your orbit (the forces are not correctly aggregated, presumably). I'm not sure that this N-Body mod as currently planned would automatically fix that. Wow, that doesn't sound very efficient. I always thought KSP stores way more temporary data from internal calculations in variables as necessary. Non of the stuff in vessel like .acceleration, .perturbation, .geeForce, .geeForce_immediate or sth in vessel.flightIntegrator is of any use to get the stock orbital forces?

Isn't it against the rules to place stuff outside the GameData directory? Its a bad style at least, thats why i use LoadLibrary(...) from Kernel32.dll to load my native dll from wherever i want... a Mac might allow sth similar?

@flower Looks like RT is doing it via a KSPModule attribute. Also AvailablePart seems to have an moduleInfos & messing around with that could offer some neat features as well.

Set your part's category to -1.