MeateaW

Yep; at one stage in my development I had 2 different files one for the 64bit library and one for the 32 bit library and then a "shim" that would pick which library to call depending on the operating system. As soon as I started thinking about mac-os support I realised it started to balloon out, instead of a simple "if 64bit" shim, I needed to add in functions to detect operating system. And I hadn't even considered the Linux OS at that point. It didn't help that the library I was using had on the order of 200 exported functions that I was trying to import. ~600 lines of code for each operating system/architecture combination just to import the files was a bit of a waste. I went down a very deep rabbit hole of DLL loading paths and functions (most of them DotNet related, not Mono) until I found some forum post about someone asking for DotNet to implement something similar to the "dllmap" feature of Mono. It was a lucky find that led me to the above solution.

Edit: @Sarbian: This post might be of interest for you also! Edit2: I just tested renaming all the files. I added .dat on the end of each filename, and did the same in the dll-map, and it works as expected. I realise you have solved all your problems but I've just recently dredged up my old modding files and got them running in the latest KSP and thought I would share something that I figured out for cross-platform external-library KSP/Unity development that might help you. (For context my mod was a variation on the various engine-balancing mods that existed back then, and still exist, ThrottleControlledAvionics [aka TCA] which still exists!) So; I learned this initially because KSP when I started modding was primarily a 32 bit application; with only a beta 64 bit branch; so I wanted to have a single list of function imports that worked for 32 and 64 bit applications; and I had a mac so I wanted to look at loading the library on that platform also. I found out about a feature that exists only in Mono, known as the "DLL Map" This allows you to use a single DLL Import, and a "Map" that maps the import to an appropriate library depending on other factors. I'll use code copy and pasted from my project: I use a library called LpSolve55, I have 32bit and 64bit modules, and modules for Windows/Mac/Linux, which gives me 6 different files I need to choose from. I do it like this: Project: LibSolver (Generates "LibSolver.dll" in my example, replace where appropriate) Create XML file: LibSolver.dll.config (MUST be the same name as the DLL that has the DLLImport commands) Mark it as BuildAction: "Content" and "Copy if Newer" (file must be sitting right next to the DLL) <?xml version="1.0" encoding="utf-8" ?> <configuration> <!-- DLL map files only work in Mono, hopefully Unity on windows (for KSP) also uses mono. --> <!-- OSX --> <dllmap dll="lpsolve55" os="osx" cpu="x86-64" wordsize="64" target="gamedata/AdvancedAvionics/x64/liblpsolve55.dylib" /> <dllmap dll="lpsolve55" os="osx" cpu="x86" wordsize="32" target="gamedata/AdvancedAvionics/x86/liblpsolve55.dylib" /> <!-- Linux --> <dllmap dll="lpsolve55" os="linux" cpu="x86-64" wordsize="64" target="gamedata/AdvancedAvionics/x64/liblpsolve55.so" /> <dllmap dll="lpsolve55" os="linux" cpu="x86" wordsize="32" target="gamedata/AdvancedAvionics/x86/liblpsolve55.so" /> <!-- Windows - Mono only potentially --> <dllmap dll="lpsolve55" os="windows" cpu="x86-64" wordsize="64" target="gamedata\AdvancedAvionics\x64\lpsolve55.dll" /> <dllmap dll="lpsolve55" os="windows" cpu="x86" wordsize="32" target="gamedata\AdvancedAvionics\x86\lpsolve55.dll" /> </configuration> The file is pretty self explanatory, depending on the architecture it loads a different file. Then for your actual DLLImport you do something like this: [DllImport("lpsolve55", SetLastError = true)] public static extern bool add_column(long lp, double[] column); Note: that the path I use for the DLLImport is the "dll" field in the dllmap file above. The actual Config file does the hard work of specifying the path to the platform-specific library. This allows you to maintain a single DllImport file, which is cross-platform. Lets you save your DLLs Libs and So's in a folder that makes sense. I haven't yet tried changing the extension on the DLLs (I'm getting your other error your other post references too) but I don't see why it won't work. Note; as mentioned in the XML config file, this is Mono specific. If Unity ever changes to run on something other than Mono (IE on Windows they use DotNet proper?) this will all fall over, and I have no idea how to fix it after that! Edit3: There is actually a side benefit from all of the above. If the basic library remains the same, but an updated version comes out, or a bug-fix and for some reason, or it relies on an operating system DLL that lives in a specific path, the dll-config file is editable by users, without needing to recompile the whole project. IE people can update files; or perhaps add their own for an architecture you don't currently have a native library for. As long as the DLL exports the same functions someone else can get a library that works; and with minimum effort supply it in addition to your existing libraries. (IE you don't list a linux library, but someone might cross-compile one for you, and adding support for it is a simple matter of updating the config file). PS. turns out I was working on this almost 4 years ago. Sigh.

Hey Allista, I made an attempt to do this kind of mod using an external library to do the solving. (http://lpsolve.sourceforge.net/5.5/). I found it capable of solving both rotation and translation linear problems for (small) ships with upwards of 10 or so engines. (see for a small example)Have you thought about dropping to a library to try to solve this kind of problem? I can give you some help integrating the lpsolve library, given you seem to understand the maths it is a pretty easy library to use. If you've done any LP problems by hand the solver is pretty intuitive.

I wonder if you could write a mod that dynamically modified the torque curve based off relative velocity to the surface (default), or nearest other entity (say nearest vessel). Does KSP notice dynamic changes to the torque curve? Or is it locked after the part is instantiated... (So, the torque curve is 0-30 surface velocity or whatever, you are in orbit doing 2200m/s (surface relative). You come near another vessel and are travelling at 0m/s target-relative velocity. Mod would dynamically modify your torque curve to be 0 between 0-2170, curve in to 100% at 2200m/s, then curve out to zero at 2230 (simulating a 30m/s torque curve at whatever orbital altitude you are at) If your nearest vessel is travelling at 5m/s relative to you; you would modify the torque curve to simulate a ground-speed equivalent curve of 5m/s. So, since you are at 2200, your torque curve would have its "centre" point (max torque) at 2195, and it would hit zero at 2225. So it would simulate you having the same torque as ground-speed 5m/s equivalent. I say use nearest vessel rather than target, because I suspect - while there would be oddly shaped ship exceptions - it would be more realistic than just using your target, since you could move on another object while targeting a significantly different vessel. IE. moving on the outside of a space station while targeting an incoming rendezvous? But this solution hinges on being able to change the torque curve dynamically, and having KSP actually take it into account.

Was looking at adding a window to my mod (to avoid using the part popup menus) and I just couldn't be bothered trying to figure it out. It will be useful having a base to start with. Thanks Trigger!

But, given that this is a simulation of the start of a Space program, not all of your satellites are going to be multi-year. Your first generation of satellite is going to have a lifetime measured in days, not years. Also; think about the first generation of satellites from a scientific stand point - we could measure things like the time dilation effects of general relativity by using satellites, it helps for more accurate measurement for it to be there for years; but if it only does a couple of orbits we can still get some value out of it!

The problem with Jet engines in space: The fuel isn't being used as the mass to be expelled out the back, it is used as the chemical energy to spin the turbine. The turbine then grabs air from in front of the engine, and pushes it out the back. (Sure, it uses some of this air as part of the burning process - the oxidizer) but it is the actual air itself forming the reaction mass (the thing you "push away" to then gain speed). In space, there is no reaction-mass for a turbine to use. In addition to no oxidizer. The reason rockets are less efficient is due to the Rocket-fuel+Oxidizer mix must also constitute your reaction mass. So, there is little physical reason for the jet engines to work in space (well, except as a really weird rocket engine - RAPIER?) But, As others have said, the use of non-oxygen rich atmospheres as reaction mass (combined with some oxidizer) actually sounds really interesting. I'd say a high-tech level Jet Engine that has a "closed cycle-Jet" mode (as opposed to closed-cycle rocket mode), which injects fuel and oxidizer, could operate much more efficiently in inert atmospheres, it would be less "efficient" than in oxygen-rich atmospheres (since it would need oxy in addition to your liquid fuel), but you could theoretically use the atmosphere as your reaction mass to massively reduce fuel requirements.

Not true; philotical is explaining the problem. Lo-fi described the (easiest) solution precisely. lo-fi even described the difficult solution precisely. The method I would use; would be to measure speed relative to the surface but as soon as surface speed exceeded some threshhold (300m/s? maybe altitude? maybe ground-altitude greater than 5? or 50? or something), measure speed based off relative velocity to current target (if there is one). The problem, is wheels don't provide force when you are moving quickly relative to the surface. (exactly what philotical said) The proof of this; is despite contact with the ground/another craft. Despite being "stuck" to it by BDs legs, unless you are in geostationary orbit nothing happens. Because the engines are defined not to do anything when your surface speed is too high. (being in anything other than geostationary orbit means your surface speed is likely too high). lo-fi provided the solution to this, in order for the engines to provide a force, they need to be within their velocity curve. lo-fi's simple solution is to modify the curve so that the wheels work "normally" upto (for example) 30m/s, cease working between 30 and 300, and then after 300, always provide acceleration. That way as long as your orbit is not in the band near geostationary where you are moving at a surface speed between 30 and 300, then you'll have traction on anything. (including the craft you are "glued" to using the legs stickyness).

Just an update, I haven't stopped work. But in case people are interested I thought I should mention mods (that really should have popped up earlier in my searching!) I have found this: http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-(April-6) I haven't downloaded it and tried it out, but it sounds like it is still working in 24.x This sounds like it does at least one major component of what mine does (rotation torque control with variable engines). And it sounds like it does what I am currently calling "thrust mode". I am slowly cleaning up my code, with the intention of releasing a first version soon. My initial code was all over the place, and hosted on my works source repository, I have since separated it to my own personal repo, and am considering a github release repository. I can tell you it now takes into account engine ISP when deciding which engines to use, so when it is in hover mode you can be assured it is using the most efficient combination of engines to achieve it. Not to mention millions of bugs have met their end. Once I have finished getting the code so that it implements all the features it used to (I killed position lock recently in my refactor, it is now back, but I am going to do it better than ever).

This sounds pretty cool! Regarding your issues spitting out information, you might want to flip it. Poll KSP for the information, rather than push. Push gives complications like, what happens if your push update takes longer for the remote server to process than the time between update pushes? Whereas a pull (like using telemachus) means that the processing time is limited by the KSP end. If polling telemachus is causing performance issues, it sounds like telemachus hasn't separated out enough of his web server related code? Otherwise sounds fun! I'll keep an eye on this thread. Regarding a "map" view, the 2d map they use in orbiter is kind of useful for "visualising" your orbit. It isn't particularly useful for showing orbits in 3 dimensions however! (And just as if not even more useless for node creation!) Just describing that: the circle is the "earth" or "ground" and the little elipse is the current "orbit". I think this image is showing a ship stationary on the ground. (a little forward momentum, and positioned on the circle - AKA traveling at 0 "surface" velocity)

RCS is still on the to do list, and I haven't yet tackled it. In a way however using real engines is better, since the ISP of RCS is pretty poor. (The biggest advantage it has is no worries about hooking up fuel) The new engines should be working the same way as the older engines, the only proviso is I haven't confirmed what it does with the RAPIER yet, but since atmosphere mode of the RAPIER is similar to a jet engine it sort of isn't worth getting confused over till I have a better solution in place with them. Also, with engines like the new cluster engines from the NASA pack it would be great if they were actually 4 separate engine modules, as then with those alone I could do some torque control with them, but sadly as far as I can tell they are ultimately throttleable only as a single unit. Maybe one day I'll override the engine module and split up each engine by its own nozzle, and vary the output independently , but that is a whole lot of work for a grand total of 2 parts. (Maybe 3 if the RAPIER is considered 4 thruster transforms... Sounds a little silly though)

Thanks Nathan, working on making it actually useful, right now it runs using MaxThrust and assumes maximum throttle, I need to get it to do its work based off real-time available thrust, maybe with some smoothing or other special treatment for jet engines.

2014-08-22 Updated! Includes new video, and various position locking.

Unity uses Mono, which is an open source implementation of DotNet. They use mono so they can use dotnet on mac, and linux. As far as I am aware they have most of .net 2, and 3.5 is based off the 2 framework. (4 onwards did new [awesome] things, which we sadly cannot use due to mono not implementing them [yet??]).

When it finally did what I was hoping for it turned out quite fun! I did have one build that would always be moving sideways; but always at a stable altitude, I made a hover car and had some fun with that. Which leads me to think that perhaps a few mode could be implemented - "Stable Altitude" mode; where it tries to keep a craft x meters off the ground. I am also considering a "landing mode" which uses your engines and evenly slows you down based on altitude, so you always get perfectly soft landings. The precision the solver lets you get is pretty good. In some tests I was controlling my speed down to 0.1 m/second, and that was without any guidance systems trying to keep me horizontally stationary.

Open Avionics 2014-09-02 Just an update, I haven't stopped work. But in case people are impatient I thought I should mention similar mods (that really should have popped up earlier in my searching!) http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-(April-6) I haven't downloaded it and tried it out, but it sounds like it is still working in 24.x This sounds like it does at least two major components of what mine does (rotation torque control with variable engines). And it sounds like it does what I am currently calling "thrust mode". Slightly disappointing that I didn't find this before starting work, but I am going to continue my work (since I find it actually fun, not work!). I am slowly cleaning up my code, with the intention of releasing a first version soon. My initial code was all over the place, and hosted on my works source repository, I have since separated it to my own personal repo, and am considering a github release repository. I can tell you it now takes into account engine ISP when deciding which engines to use, so when it is in hover mode you can be assured it is using the most efficient combination of engines to achieve it. Not to mention millions of bugs have met their end. Once I have finished getting the code so that it implements all the features it used to. IE I killed position lock recently in my code-cleanup, it is now back, but I am going to do it better than ever. I plan to make it choose a velocity that best matches the available thrust, to minimise overshooting your target position. It did a basic version of this in the past, but large displacement still ended up with big overshoot, which I hope to basically eliminate. 2014-08-22 Fought a lot with trying to implement altitude lock, before I realised that the world-space transform is at all kinds of wiggy angles, some dot products and unit vectors later it all works flawlessly. I now have Altitude lock, East-West lock and North-South lock. (obviously EW and NS locks aren't quite as useful, individually, but they aren't too bad). Combined they form 3D-space-surface-position-lock. I also have movement dampening mode, which holds you still*! * where still is defined as some velocity** at or below 0.1m/s. ** Rotating isn't considered velocity. (but your SAS can help here) I would like to apologize right now; for the horrible piloting, and pretty poor example of what everything is doing. I cut the building since it is less important. What you are seeing Most of the video is showing the various position lock methods. Note the "Movement Dampening" option, that doesn't lock you in a specific location, but does attempt to reduce your surface velocity (in all axes) to zero. When you hit a translation key, the dampening limits the maximum velocity you can get, and after letting go of the translation key the movement dampening halts your movement. 2014-08-11 First post. I am working on remaking from scratch the KerbComAvionics module that appears no longer maintained. see: http://forum.kerbalspaceprogram.com/threads/29387-0-21-x-KerbCom-Avionics-0-3-0-6-Alpha-(29-August)-now-with-video! for the original. Due to the license around that module (CC no Derivatives); (and the complexity of the code) I have had to re-implement everything. (I had intended to refurbish, and contact ZRM to get permission to release, but I honestly couldn't figure out how to get the mod to work, and had literally no idea where it was actually doing anything) ZRM had identified an open source solver, so I had a library to begin work with. And luckily about 7 years ago I took a single subject at uni that covered Linear Programming (the type of mathematics to solve this species of problem), so the whole concept wasn't foreign - and the library was doing the maths-heavy part. But; about 3 weeks of fairly solid development time (that have severely impacted my output at work! ssh don't tell!) the above is where I am at. Some history ZRM began his mod; as a way of simplifying RCS thruster placement. By automating the output intensity at each nozzle; he would ensure no errant torque from poorly or imbalanced RCS thruster placement. Eventually after ZRM completed these tasks, he moved on to balancing everything; from Gimballed engines, Reaction Wheels and RCS simultaneously. All whilst (apparently) taking the most fuel efficient route. what I have right now I am no where near the complexity of ZRMs implementation. I solve exclusively for Torque and Translation using Engines right now. I do take into account Solid Rocket Boosters (I don't believe ZRM ever bothered). I do take into account Gravity (this is useful for arresting translations) I do not take into account Gimbals. I do not take into account Reaction Wheels. I haven't even considered what I am going to do about RCS yet. Gimbals and Reaction Wheels are important when we start thinking about Fuel Efficiency. To be honest; I am not sure I can figure out how to plug efficiency numbers into the solver. And from the moment I decided to re-implement I have specifically avoided looking into ZRMs code. My code is ugly right now, and I have only just today gotten it to do what I actually intend. (The above video was made about 1 hour after the maiden flight of the solver model that first actually worked as intended). Does it really work yet? Mostly! See (skip to 3:30 for the actually interesting part!) What you are seeing here: The solver is currently configured to cancel gravity. When at full throttle there is a slight vertical acceleration (I think this is rounding error) I use the rotation and translation controls to modify the constraints of the model. So; if I hit the RCS 'Translate Up' key; the model no longer solves for zero upward translation, and instead adds some amount of upward translation into the "solution". A quirk you'll notice, is when I "Translate Down" it turns out that gravity is still greater than the amount of translation I pass in. So there is no "downward" thrust; just a massive reduction in the force counteracting gravity. It is of course using infinite fuel - the only practical way to perform on-pad testing. I left the reaction wheels in place; but 99% of all rotations and translations are performed by the Rocket Engines. You will notice that SAS performs amazingly well with the solver in place. SAS was a perfect fit for precisely calculated torques. It isn't great for the reaction model (you get lots of bouncing back and forth), but when your engines produce the exact torque required to right the ship; SAS has a firm grip and rarely gets it wrong. Why am I making this? And what will I do with it Well; think about all those times in vanilla KSP where you had an imbalanced rocket. There weren't many. Now think back to the first time you ever tried to perform an Asteroid Redirect, and how easy it was to just claw up and push in the direction you actually wanted to go. It is the ARM that really got me to think about this. I intend to release this code under a very permissive, to near completely permissive license. I am thinking of something like a; Creative Commons - Attribution, (but maybe even less restrictive than that?)

And thinking about it even more; I have realised the ultimate way to do it, that simplifies even my code, and avoids unnecesary duplication. On initialization of the plugin; copy the relevant library to a common name, and use the standard pinvoke calls. Due to the lazy-loading; you should be able to copy (or link?) the to the required file during plugin initialization.

as an aside; since you are going to be pinvoking an external library; to make things easiest on users; you could do what I did for my library. Basically; KSP lazy loads the libraries; so you can execute code that chooses which precise library to load. http://forum.kerbalspaceprogram.com/threads/87533-64bit-KSP-External-library-question?p=1302106#post1302106 I am not going to claim it is the best way to do it (it is certainly pretty ugly - and requires a lot of duplication when you have lots of functions in your library); but it certainly makes the effort of picking which version to install trivial for the user. The only reason I would consider not doing this method; is if your library compiles to many megabytes, in which case to save download space you may not want to include multiple copies. But I suspect that this is not the case. (no embedded difficult to compress resources - unless there are some kind of large pre-computed lookup tables that can speed up the mathematics?)

In this instance, the native code DLL was the Linear Programming solving library: "Lpsolve". Used by Kerbal Avionics. When running KSP 64 bit it failed to load the DLL (the debugger indicated that it "could not find DLL"). Process monitor indicated that it could indeed find the DLL (many "Success" open-file events), however even after finding it it kept looking in other locations. On a hunch I tried the code on KSP32 bit and it worked fine (all other things were the same). So, I grabbed a 64 bit version of the DLL off the web, replaced it, and tried it again in 64bit and it worked. So; there was no obvious "this DLL is the wrong archictecture" message, however by a process of elimination I came to that conclusion. (and with something somewhat related to this code have effectively solved the problem). Just to explain how I solved it: (Note: this is not the only method, there are easier methods, and for my particular problem this method resulted in a LOT of extra code! - but it was all automated searches and replaces so wasn't as bad as it sounds). Lets say you need to import a function from a library: You would use something like this: public static class Library { [DllImport("dllpath\dllfile.dll", SetLastError=true)] public static extern bool add_column(int lp, double[] column); } And you would call that code like this: void Function() { if (Library.add_column(intvalue, arrayofDouble)) { /* Cheer! */ } } I wanted to ensure that whatever bit-version I needed was loaded, without changing any of my native calls. So I don't change my calling-code, but I *do* change my library to the following: public static class Library { [DllImport("dllpath\dll_32bit.dll", SetLastError=true)] public static extern bool add_column_32(int lp, double[] column); [DllImport("dllpath\dll_64bit.dll", SetLastError=true)] public static extern bool add_column_64(int lp, double[] column); public is64bit { get { return IntPtr.Size == 8; } } public delegate bool add_column_delegate(int lp, double[] column); public static add_column_delegate add_column { get { return is64bit? (add_column_delegate)add_column_64 : (add_column_delegate)add_column_32; } } } I can guarantee this is not the "simplest" way of doing it, but it is certainly *a* way of doing it. Also; the internet when it saw this problem was similarly confused about why a 64bit application couldn't call a 32bit dll. (In fact most of the internets response was: "Just call the 32bit version"). However for whatever reason this did not work for the default compilation method of the ksp mod. Note: My actual code was slightly more complex than this, but only because I had to split it over 3 files. Eg: public static class Library { private is64bit { get { return IntPtr.Size == 8; } } public delegate bool add_column_delegate(int lp, double[] column); public static add_column_delegate add_column { get { return is64bit? (add_column_delegate)Library_64.add_column : (add_column_delegate)Library_32.add_column; } } } public static class Library_64 { private const string DLLPath = "dllpath\dll_64bit.dll"; [DllImport(DLLPath, SetLastError=true)] public static extern bool add_column(int lp, double[] column); } public static class Library_32 { private const string DLLPath = "dllpath\dll_32bit.dll"; [DllImport(DLLPath, SetLastError=true)] public static extern bool add_column(int lp, double[] column); } The main reason for this, is the difference between the 32 and 64 bit import-classes, is precisely 2 lines. The class Name, and the Constant-String variable. Again; no guarantees this is the best way of doing this, just that it is *a* way of doing it.

Can I add an idea for asteroids? Add a module to an asteroid that places a resource, in the asteroid. Make it so you can't "transfer" the resource out, without the use of an Zero-G Drill. Reduce the base-mass of an asteroid, and replace that with the Asteroid-Bound Karbonite. So as you mine the Karbonite out; the mass is shifted from the asteroid, to your storage container. The final result should be a significantly lighter asteroid once you have shifted it into tanks and sent it on its way!

Thanks Daid, I'll give it a shot.

Hi All, I am fixing up a mod (for personal use - license doesn't let me distribute derivatives - but will contact the author if I get it going). That mod imports some functions from a DLL, obviously it was a 32bit DLL in the past. Is there any way within the KSP API to detect if you are running 64 or 32bit? I obviously need to have some code that detects which mode I am in, and load the DLL that is appropriate. Thanks! PS. I am a developer by trade, but have very little KSP modding experience (so don't know where to start to look for API documentation). (The mod I am refurbing is kerbcom avionics, which was last touched by its dev for ksp ~21.something, things have changed since then! - but yeah wont be releasing anything due to license - I may release diff files to allow the adventurous to compile their own version of my changes if I ever get it working, but tbh I wonder if even that is against the license - need to research first).

Hi evilC; letting you know that I am investigating refurbing this mod; but look at the license. ZRM left it with a share as much as you want; as long as you don't change anything license. If I ever get it working (it has a lot of old KSP stuff going on - no guarantees) I would have to release it as a "patch" (a series of diff files, that merely contain my changes). There is no way to release that code with its current license as an "updated" version (no derivatives allowed). Unless ZRM came back and accepted a pull-request (which I might do if I like my code - not likely!). I'd like to add, debugging someone elses code using the KSP debug window is a nitemare. WISH I could attach the visual studio debugger ((