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.