Nuke

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.

reset xform

the power of 2 requirement is usually required for mipmap generation. mipmaps for those that dont know are a set of textures that are progressively scaled down from the original texture using division by 2. as you divide down using integer math you cant have any remainders because that will ruin the alignments. the idea is you dont need to render the full texture for objects that are far away, so you use a lower mip level while rasterizing those objects. its sometimes possible to have non-square textures so long as both dimensions are powers of 2, but this depends on what the developer decides to do (im not sure if ksp supports this, i usually err on the side of caution and use powers of 2). you might have other restrictions imposed by texture formats. if you use any kind of block compression (like dxt*) your resolution must be divisible by 4. of course if you have power of 2 textures you are almost always divisible by 4. now ive modded several games over the last decade and a half. what i usually do is make textures at about 4* the desired resolution, and down sample them for release. ive seen graphics card caps quadruple during the development of a mod, and i like to future proof my textures. it would be foolish to release full size textures though.

im working on a set of half meter parts to use for doing orbital maneuvers and other non-launch operations. but im kinda stuck on the gimbaled engine. i got the engine modeled as 2 parts with the gimbal joint aligned with 0\'0\'0. im not sure if this is correct or what to name the parts or if there is any kind of other setup required. gimballed thrust works but i cant seem to get my engine to rotate like the stock engine. im modeling under max 8, and im not sure what collada plugin im using. i would have normally imported the stock gimballed engine and checked out how that was set up and set mine up accordingly with respect to naming conventions and mesh center, but i cant seem to import the stock model (my plug in is not supporting the collada version used on some parts). i did however look at the dae file in a text editor and got what i think are the mesh names, which seem to be obj_gimbalMesh and obj_anchorMesh, i tried those names but they didnt seem to work. is there any other configuration that needs to be done here?

what about using dxt textures directly? it would save a lot of processing at load time doing conversions to the proper format. i can understand needing to match video card caps but for most kinds of textures (particularly diffuse), dxt1 or dxt5 will do, and those are supported on practically everything. you might have issues with normal maps. bc5 is superior to dxt5nm (its essentially 2 dxt5 alpha channels), but its a newish format thats not supported on older video cards, and it would be bad to convert from one lossy format to another. png is nice and all but its really not a texture format, and the game is gonna convert it anyway. not to mention both ati and nvidia have conversion tools for free, so its not like its gonna make the modders life all that difficult. just my 2 cents.