Nuke

i miss the good ol days of modding back in the 90s when a vague link was all you needed, crappy ascii art bandwidth permitting i also apologize im a horrible screencapper.

this mod is currently in the process of being adopted. old post content: a message from my cat: legal stuff for purposes of the re-release of the mod by zer0Kerbal: mod is released into the public domain. links to adoption dev threads: this thread will be locked pending the addition of more links.

during launch i like to listen to laibach's b mashina. during a bad launch i like to listen to arcturus's shipwrecked frontier pioneer, for orbital transfers i just play the blues on my guitar.

yea that was the problem. i got it to work and posted a diff on the mumech thread.

would be ok if i release my freetrack enabled version of mumechlib (il call it a beta since its to the tweak it till it feels right stage). it would come with a virtual cockpit part and instructions for usage. rules say i need permission to do that though, and im not quite sure if dynamically linked things is allowed either.

anyway i updated my patch for freetrack support. http://pastebin.com/XGAR01SW it now handles exceptions properly. so your not dependent on the dll to run the plugin. i fixed a bunch of quirks with the translation. like the vector needed to be transformed into part space. and cleaned up the class abit. still needs a virtual cockpit to really shine though. still needs part specific constraints. the FreeTrackClient class supports changing of constraints, but nothing changes them yet. but thats probibly easier than doing interop stuffs.

yea i did a round of testing and the version i compiled will crash ksp if the dll is nor present. also the example code i based the interface off of was lacking some idiot proofing. it neither bothered with exception handling nor did it close the dll out when it was done. but what can i say, im fairly new to dynamic linking, not to mention c#. so i got some work to do on it. it works though and is a fairly good for a proof of concept. just need some virtual cockpits now. i could probibly cut one off of one of my mods for other games. ive done a lot of virtual cockpit mods for freespace2 open, and so i have a large number of assets lying around. otherwise its probibly not a very long wait for the iva features in the next version. ive heard about there being some linux head tracking software. and there have been a few people interested in porting freetrack to mac. if there is some way to detect platform and then load up whatever interface library is neccisary to support head tracking on that system. i dont know a whole lot about macs, i haven't used one since the late 90s, so i dont know whats available as far as head tracking goes. if something does exist i suppose i could make the interface support head tracking protocols on those systems. it would likely be some time before that happens. my next job is to make the code tolerant of the absence of the dll, but first i need sleep.

k heres a diff against rev 61. this adds freetrack support to mumech hull cameras. this is preliminary, id like to have other features like part specific camera constraints later on. i definately need feedback. http://pastebin.com/dV2NQwG6 also since im using the freetrack api, that means you should also be able to use facetracknoir for head tracking. freetrack also supports wiimotes, webams etc. im using a trackir4 with freetrack, but dont tell natural point another issue that im not sure if the ksp devs will like is that i am using freetrackclient.dll to supply the data to the new system (to be fair the rules didnt say anything about dynamically linking external dlls). the free track source (which comes with the dll source) is available on their website, be warned, its written in dephi pascal. you require the dll on your system, which if the freetrack installer did its job right should end up in the correct system path, if not you may need to copy the freetrackclient dll to your ksp folder. another thing, im kind of a c# noob, so tell me if i did anything bad.

oh thanks that worked. im able to modify the view with freetrack, but i need to brush up on my quaternion maths to get my rotations to work right. il post a diff on pastebin or whatever when im done. *edit* k i think i got the liner algebra worked out. so i can look around and translate. probibly needs a little tweaking. im currently constraining rotations to 180 degrees on any axis, and confining leaning to a 1-unit cube. rotational and translational constrains might be wise to define in the part so that modders can prevent freetrack users from backing into the geometry or seeing something they shouldn't see. i still have an ugly bug to fix. every once in awhile the freetrack interface doesn't respond and my code treats it as an error even though its just a hiccup in the api. as a result the view reverts to the default view for the camera. this just produces a frame where the camera is pointing in a different direction, and is only a minor graphical annoyance. i probibly just need to queue up the last good frame's position local camera info and use that, and if thats no good, then handle the no freetrack scenario. gonna fix that one at least, tweaks and features can come later.

k, so it turns out talking to freetrack is easy, getting mumech to work, thats hard. i decided to take a different approach. i followed the basic hello world in the wiki (normally i skip these and dive into the advanced stuff, after all code is code), and it worked for the most part. then i tried the freetrack interface code that i had intended to use for mumechlib. it just printed the data to the log when the part was inited. so its at this point i either re-invent the wheel and spin my own camera plugin. id rather not do that since mumech already has a pretty good camera feature. i had intended to get it working and post a diff against their svn repo for them to implement at their leisure. im not sure what to do at this point. though i have a hunch that sharp lua has something to do with it, that perhaps there is extra configuration neccisary for it not throw an exception. problem solved

ive been trying to compile mumech for a week now. i want to attempt to add freetrack support to hull cameras. but before i can do that i need to compile a build that works. ive tried both visual studio 2010 and monodev. both manage to compile the dll just fine. but the dll never wants to work in game. i always get the following error: Being asked to load D:/KSPdev/KSP_Data/../Plugins\MuMech.dll (Filename: C:/BuildAgent/work/300357e52574df36/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 43) Non platform assembly: D:\KSPdev\Plugins\MuMech.dll (this message is harmless) Loading assembly: MuMech, Version=1.9.1.0, Culture=neutral, PublicKeyToken=null (Filename: C:/BuildAgent/work/300357e52574df36/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 43) Exception when loading MuMech, Version=1.9.1.0, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at ModuleLoader.LoadAssembly (System.Reflection.Assembly asm) [0x00000] in <filename unknown>:0 am i missing something in my build configuration or something? i followed all the setup instructions on the wiki and have spent the better half of the last week searching the forum for a solution.

timestamps are your friend: function initTimeStamp(t) return whateverfunctiongetscurrenttime() + r end function evaluateTimeStamp(ts) if whateverfunctiongetscurrenttime() > ts then return true else return false end end just call initTimeStamp() before a while loop, and evaluateTimeStamp() each iteration. initTimeStamp(500) while not evaluateTimeStamp() do --do nothing end granted you should use a coroutine so you can do other things while waiting for the loop to end. disclaimer: this is generic code and does not reflect the proper usage in autom8.

seems i cant go back very far as far as revisions go before im at a version no longer compatible with version 0.16. and none of those seemed to work. probibly some kind of configuration issue with the build environment.

lua lets you be kind of sneaky. i have the beginnings of a lua standalone game engine that you can program while its running. the things you can do with it are actually quite amazing. ive got an opengl renderer, freetrack support, and a whole lot of other cool things implemented, without a line of compiled code. its quite impressive.

i guess i can keep rolling back revisions till it works. im not 100% sure i can load the freetrackclient.dll from the plugin, especially considering it was written in delphi. i was able to access the dll from lua standalone so i may end up being better off implementing it through autom8, assuming autom8 both lets you load modules and change camera angles. so i have a couple angles of attack with which to approach the problem.

so i got revision 60 loaded into visual studio 2010. and was trying to get it to compile. i want to add freetrack support for hull cameras. but before i can do that i need to get the thing to compile. it does actually compile but i get this when i try to launch ksp: .. Being asked to load D:/KSPdev/KSP_Data/../Plugins\MuMechLib.dll (Filename: C:/BuildAgent/work/300357e52574df36/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 43) Non platform assembly: D:\KSPdev\Plugins\MuMechLib.dll (this message is harmless) Loading assembly: MuMechLib, Version=1.9.1.0, Culture=neutral, PublicKeyToken=null (Filename: C:/BuildAgent/work/300357e52574df36/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 43) Exception when loading MuMechLib, Version=1.9.1.0, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at ModuleLoader.LoadAssembly (System.Reflection.Assembly asm) [0x00000] in <filename unknown>:0 ... did some search-fu, found the z trick, however that didnt work either. i haven't actually made any changes to the code yet. any help would be appreciated. i should also point out that my c# is not strong (i prefer c/++ and lua), though i did read the entire syntax article on wikipedia.

ive actually done stuff like that in other games. im not sure if the engine would let you but you could probibly require() luasocket with autom8, and you would be able to pass info from autom8 to other programs, or in my case (and in another game) i talked to an arduino with an ethernet shield and some 7 segment displays (a raspberry pi with a small touchscreen would be better). the result -> HARDWARE GAUGES! of course any game dev with an eye to security would lock down module loading facilities for securities sake to keep hackers out of the system.

i think the big issue with landing huge payloads is rotational overshoot. i dont think mechjeb is accounting for the time it takes to change a massive ship's orientation, and as a result misses time critical burns. ive seen some ships where it can never seem to get into the right orientation at all. it would get close but because of the angular momentum and the time neccisary to stop it would be impossible to stop in time, and so the ship spins in circles just before it hits the ground at high velocity. thats my theory anyway. ive been able to get around it somewhat with about 3 dozen rcs thrusters, and no fewer than 5 1-meter rcs tanks. its also likely my fault as the 19-engine coupler (my part by the way) im using hasn't been thorough balanced yet. after i landed that base i realized that the weight for the part was 32 tonnes (x2). considering it does hold a large amount of fuel that seemed appropriate. but ive seen other parts with bigger volume and lower mass, so i halved both mass and fuel capacity and it works better now (i wasnt using all the fuel anyway, that ship is loaded). i need to find some better balance guidelines. for reference this is the stack i launched it on. this is however the motorcade version used to land all the rovers. the base launcher used the same descent tower and the same launch vehicle though, the only difference is the decoupler arrangement and the fact that the lower 19-coupler was hard attached to the launcher and the decouplers attatched right under the carts instead, and this provided slightly more fuel to the main engine which i believe was one of the 3 meter engines from novapunch. mechjeb could launch the thing if you set the target apoapsis high enough and tweaked the launch profile curve to get the ship all the way out of the atmo before doing the gravity turn. otherwise the ship would topple and explode. though it does have the delta-v neccisary to do a flat trajectory transfer to mun. should try that one day.

it has no re-launch capability. its kind of a moon base with room for 28 kerbals.

yea until you land something like this monstrosity. mechjeb only gets it right 1/3 of the time.

is the robotics stuff integrated with autom8? would be awesome to have some ik scripts that could do some advanced walking and grabbing on to another space craft for eva operations. also big stompy mechs.

those are fun. this is actually one of the things i never figured out when playing orbiter, as it had a pretty decent rendezvous gauge. i had to play ksp to figure out how to do it bny eyeball step 1: align planes (use procedure in my last post for this), be extremely precise. step 2: burn prograde/retrograde to move periapsis toward the target orbit till they touch (crossing it a little doesn't hurt). it doesn't really matter where in the orbit this is done. step 3: at periapsis burn pro/retro to bring the apoapsis closer to the orbit, not all the way. step 4: warp time till you have a close encounter with the target. should be a few degrees or less of a difference. after that it gets trickey. with the orbits on the same plane the problem is a 2d problem. so you have 4 possible manuvers, prograde burn, retrograde burn, and +/-rad burns, these will all be smallish maneuvers. essentially you want to match velocity with the target, plus or minus what is needed catch up to the target or let the target catch up to you. once that is done then match speed with the target. you should then be close enough to do an approach. its fairly easy to transfer kerbals via eva at ranges of about 3km, i did a 5 km crew transfer with a little bit of overshoot. doing it with a whole ship is harder, but possible. if you are behind the target, and your velocity is less than the target, burn prograde until your velocity is slightly higher than the target's velocity, when you pass the target you will want to then match speed as close as possible. if youre behind and velocity is more, then you are ok, just wait till pass it and match speed. if you are ahead of the target, and your velocity is more than the target, burn retrograde to drop your velocity slightly below the targets velocity, allowing it to catch up, and if the velocity already slower, you just need to wait for it to catch up. if you get a lot of yoyo try reducing the velocity difference during catch up-fall back maneuvers (i find a difference between 20 and 50 km/sec work fine). while you are doing that there is another thing to worry about. you need to keep an eye on whether or not your orbits are converging or diverging, if they are converging yay, you are doing it right. now if you are diverging you need to fix that. ive actually found that burning along your orbits radius (+/- rad) can tweak your trajectory. out diverges your orbit away from the gravity source, and down diverges it towards it. you will have to do this alot. eventually you will get within a few km of the target, and can approach visually. kill your rotation and try to gauge the horizontal and vertical motion of the object in your view. make appropriate burns to make that motion stop. while making sure the distance counter is counting down, but not too fast. its fun to practice with kerbals, as they can move fairly easy and can grab on to ladders.

antinormal at the ascending node or normal at the descenting node, i think. i usually eyeball the maneuver by looking at the target orbit edge on, and wait till your current orbit crosses it, and then burn normal or antinormal until the two orbits look like they are in the same plane. i learned this playing orbiter really the orbiter manuals are a must read because it pretty much breaks down all your basic flight maneuvers. ksp makes it a lot easier with its 3d orbital view though.

awesome plugin. any chance we cant get some graphic output for autom8? just a basic x,y plot window with functions like puts(x,y,color), line(x1,y1,x2,y2,color), cls(color), text(str,x,y,color), etc, which could be called from a script. im kind of interested in making some hud instrumentation.

cant help yea there then. i had this problem yesterday and a reset xform fixed it.