Jump to content

artwhaley

Members
  • Posts

    639
  • Joined

  • Last visited

Everything posted by artwhaley

  1. You're within 6 minutes of done! Before I saw that you were mostly there, I recorded a quick video where I took your blender file and got it all the way through to KSP and it's working just fine. The video is a little blurry... so if you can't see any of the things I'm doing... or if things look different on your end just ask! I deleted the stock tank inside the model because I assumed you used it as a size reference... then it occurred to me that it might have been the payload. It won't change the final outcome either way if you delete it or leave it. I did delete the blender camera and lamp while I was in Unity. I'm a little confused - when you said you didn't rename the single animation, but did say that you set the open and close actions to keyframe ranges... Philotical is correct that the moduleanimategeneric plays the animation forward the first click and then backwards the next click... so what you've done should work great if you just jump back in the animations tab of Unity, select "Scene" and change the ending keyframe to 50 then re-export to KSP. So you're actually within 30 seconds of it working. In the video you'll see me rename the Scene file to door to match the .cfg file you already made. It will work fine either way. I also went ahead and split the second half of the Scene clip into a separate animation in case you want to do something more complicated later, but right now KSP is ONLY using the first one and just playing it forwards on open and backwards on close, so just setting the new ending keyframe should be all you need to do. Art
  2. I think I see the problem, or at least the first one... and it drove me nuts on my first animated part. When I opened your fbx in Unity and set the rig to 'legacy mode' then open the animations tab... you've got 3 separate animations for your part's different actions. Unity is expecting it to all be baked into one animation! To make that happen, in the blender .fbx export window - scroll down the options on the left side. You want 'baked animations' checked but you want 'nla strips' and 'all actions' unchecked! By default my blender installation had those two checked and it caused the files to look exactly like yours! Now... load the new fbx into unity and when you get to the animations tab you should see a single animation instead of 3 - probably named 'Scene'. You can now follow the instructions in Nifty's video to split the 'Scene' animation into the two 'clips' that you want... name the first clip 'door' and you should be there. Let me know if that helps or not, or if it gets you a step closer and we'll figure out what's next! Art
  3. I finally got this working and wanted to post the details back here in case anyone else comes along with the same problem! I took a look at the code for the inline docking port in Spaceplane Plus and saw that there were two nodes - nodeTransformName , and controlTransformName - being defined. So I created another empty game object in unity at the same location as my docking port node and did some tinkering. I don't pretend to know why the stock lateral docking port only needs one node in the cfg file to work correctly, but what I did to get mine working right is : 1. created a node named dockingNode located on the surface of my docking port , in the exact center of the ring, with the blue+ axis (in unity) pointed out in the direction that a docking ship would be. 2. created a node named controlNode in the exact same spot but with the green+ axis pointing out towards the docking ship (parallel to the blue+ axis of the docking Node). 3. put the following in my .cfg file: MODULE { name = ModuleDockingNode nodeType = size0 nodeTransformName = dockingNode controlTransformName = controlNode } And now it just works!
  4. Updated again to .5.5. This update just gets the 'control from here' button working on both service module docking ports. For those interested in the details - they're in my thread about docking port problems! http://forum.kerbalspaceprogram.com/threads/92277-Docking-ports-and-control-from-here
  5. I'm uploading another update, numbered .5 now. It's a much improved mesh and texture on the main pod, and it adds two service modules to extend the WhimChaser's range outside of LKO! The service modules give additional fuel, battery, and monopropellant to the ship. They're heavy and they don't provide any lift... so they have to be detached before re-entry! The service modules also have integrated junior compatible docking ports... but 'control from here' doesn't work yet. I'm stuck on this... but haven't given up yet. They do work if you line them up visually... or if you're using them as the target port for a vessel with a working docking port! The roadmap to 1.0 is, as of now, Roadmap to V 1.0 Retractable docking port for Shuttle itself. IVA interior Fairing for launch NEAR and FAR integration Solar Panels on Service Modules Thanks for playing with it! Art
  6. Good question. I just checked it on the same install I'm using for development - yes the stock inline docking port does work correctly.
  7. I'm trying to make two parts that each have an inline docking port on their side, in addition to top and bottom attach points. One of the parts is a fuel tank... the other is a command pod. I've tried out the fuel tank... adding a dockingNode to the part in Unity with the blue axis pointing out towards space from the docking port, and adding MODULE { name = ModuleDockingNode nodeType = size0 controlTransformName = dockingNode } to the .cfg file. The docking port works... but right clicking and selecting 'control from here' doesn't reorient the navball or the linear rcs controls to match up to the port. Is there an extra step for this I'm missing? And... to make matters even more complicated... I want to do this with a command pod next - adding an integrated inline docking port that ISN'T along with the main control axis of the ship. Is there any way for one part to have the option to control from two different orientations? Thanks in advance! Art
  8. There's room on the 'back (aft of the cockpit)' for a Clamp-O-Tron JR, which is what I've been doing for docking so far. Way down the line I may try to build some sort of retractable docking port for it, in that same position - behind the cockpit on the dorsal side... but I haven't really wrapped my head around animations yet! As for control surfaces - it 'sort of' has them - they're defined in the config file and affect the flight of the ship, but they would have to be separate pieces to make the animation work (unless I wanted to write a .dll plugin that animated pieces of the model in response to control input... which probably wouldn't be that hard... now that I think about it?). But there's no reason that control surfaces can't just get thrown on the backside of the wing - that will move the COL further aft, which would only help with flying the thing, I would think! I'm glad you like it! I really built it because I loved the sketches of your Pteron, Sage, and wanted something like it to fly until yours got finished. As for making it fit in a cargo bay - I'll look at it! I wouldn't be surprised if it already fits in the b9 HL cargo bay... The wings are too long for a 2.5m fairing, but a 3.75 m fairing ought to hold it nicely. I'll see how far off it is from being compatible with other stuff. Art
  9. I just updated to version 0.2 on Kerbalstuff. I substantially improved the mesh and the texture. They're still not finished, by far, but better than they were! I've also added a couple of lines to the config file to make it possible to fly it remotely without any kerbals onboard... which is useful for rescue missions and is in keeping with the capabilities of the actual Dream Chaser as well!
  10. Download Link Alpha Release - WhimChaser Space Shuttle! Updated to v 0.5.5 Improved mesh and texture and added the two service modules! Obviously WhimChaser is inspired by Dream Chaser, but it's also inspired by a couple of half finished projects here on the forum - most notably Pteron . This is my second attempt at a KSP part(and at Blender in general), so I'm certain there will be bugs in it. I really built it to fill a niche in my gameplay, but given the enthusiasm around Pteron, I thought it might be useful to others, at least until they finish their shuttle. My idea was to create a craft that could handle rescue missions as well as providing a low-cost crew service vessel for my orbital station. I'm also in the process of designing an educational simulator around KSP that will be used by kids... so I wanted a part that would be fun to fly... and a vertical launch/glider return vessel fit that bill and gives a flight profile similar to Dream Chaser and the Space Shuttle, so it's something familiar and educationally valid. I ALSO wanted to make it an exercise in efficiency... and this is a part for those times when you want to fly... not build. Towards that end, the single part has, built in, Electricity, MonoPropellant, Liquid Fuel, Oxidizer, aerodynamic control surfaces, 6-way RCS Thrusters and main Engines! So with a part count of 1, you can throw this thing on the launchpad, hit the space bar, and leave the ground. You won't get far - as the fuel tanks only carry about 525 m/s of delta-V, but it's more than enough to blast off, turn east, and practice gliding to the water. The idea is to launch and insert the shuttle into orbit on top of a conventional rocket then decouple and use the built-in engines and fuel for orbital maneuvering - shifting orbits, rendezvous(if you planned the launch well!) and de-orbit burn. As a glider... the lift and drag numbers aren't great... but this is a spaceship first and a glider second. It's designed for water landing (it CAN tumble to a stop on land without killing kerbals... but I wouldn't call that a 'landing' exactly.) Because of the reasonably steep glideslope I haven't successfully landed it with wheeled gear without a lot of bounce and flip... though it might be possible? The engine also has sufficient TWR that you can operate in glider mode down to the last 250m, drop airspeed to 50m/s, and then turn the nose up and engine on and do a powered, vertical landing. It's a bit of a trick, but it can be done. Keep in mind that this thing DOES generate lift from the body(though not OODLES of it)... so if you throw it on top of a rocket without any other aerodynamic surfaces it will be unstable. Standard winglets at the bottom of the launcher will keep the pointy end towards space. Because it's a single part... when it's by itself the COM and COL are at the same point when it doesn't have anything else attached. If you attach anything to it that shifts the COM aft, you're going to have stability problems unless you also attach winglets back there. I've had no problem throwing a small docking port on the back of the vessel, but trying to just strap an engine or fuel tanks to the back is a recipe for disaster when you're inside the atmosphere. Keep the COM at or in front of the COL and keep SAS on and it flies rather nicely... for a stubby space brick! Here's a terrible youtube video showing the basics of flying the gizmo! I recorded it on my development machine which is set for low graphics quality to help speed up the thousand reloads required to get a mod working! Update to .5. I added two service modules that are designed to work with WhimChaser on longer ranged missions. They add additional LOX, MonoProp, and Batteries and include their own engine, so they can slap on the back of the shuttle. They are NOT designed to remain attached during atmospheric re-entry... they WILL make the shuttle unstable. The service modules also have integrated junior compatible docking ports! The docking ports now fully work! Roadmap to V 1.0 Retractable docking port for Shuttle itself. IVA interior Fairing for launch NEAR and FAR integration Solar Panels on Service Modules
  11. I'm working on a Kerbal related project for the Hackaday Prize, and thought it might be good to get conversation started here for suggestions, as I do want it to be as useful to other people as possible! I'm building a hardware cockpit for three 7th-12th grade students to fly a simulated space mission. I'll be catching all of the physical button presses with a TI Connected Launchpad microcontroller board. Most of the buttons it will just convert to keypresses via it's USB port, but for advanced stuff (Mechjeb control!) the Launchpad will send commands via the network. For the moment I'm going to use Telemachus to catch these commands and relay them to mechjeb, though I do plan to eventually build this into my own plugin, so you won't have to run both of them. I'm attaching a pic of the buttons - the pic really highlights the tiny bubbles and wrinkles in the panel labels... in person these are barely noticeable and the boards look like they have a piano finish! On the data out side, I'm writing a plugin that will use HTTP post to spit out all of the relevant flight data to an external C# application that will render a full cockpit's worth of instruments. I'm planning to use two monitors to display all of these. On the project page you can see a test render in the youtube video showing the first single screen mockup. The artificial horizon and orbit info display both fully work now! I'm heavily deriving my plugin from GoAtThrottleUp... I started with Telemachus, but the amount of data I was trying to drag out of it was causing performance hits in the game... so I looked at GoAtThrottleUp, then tried to go my own way... but I kept running into issues they'd already solved... so my code keeps looking more and more like theirs. I'm thinking I'll eventually start over with their code and fork it so my plugin winds up being completely backwards compatible with their relay server if you prefer the python/web-browser approach to my standalone c# method of using the data. At the moment I'm planning to use the left screen to display: Orbit Info Window Docking Assistance Window (similar to Navyfish's ingame plugin) Landing Data - Pitch, Roll, Yaw, Horizontal and Vertical Speeds, Altitude (both ASL and AGL) and remaining deltaV On the right screen I'm wanting to display: Artificial Horizon Rendezvous and Transfer data Time to Next Node and Delta V Engineering Panel with resource and staging information Once the bugs are out I plan to release my KSP plugin that spits out data- along with both a barebones C# project that just grabs all of that data and puts it into variables (for use as a template for other people's projects) and the full two screen instrument package I'll be using. Are there other features that would be useful in this package? I looked at the external camera system that GoAtThrottleUp has put together... and it's awesome, but on my system it was too slow on refresh rate to be all that useful, so I decided not to implement external cams at this time... I... like every other plug maker... wish I had a good plan for a 'map view' replacement that let you create and edit maneuver nodes... but at the moment this challenge is beyond me. I suppose I probably could hook in triggers for mechjeb's maneuver planner - so you could have a few commands - circularize at ap, circularize at pe, Hohmann transfer to target, match velocity at closest approach... what else would you want? Anyway - the project page is here: http://hackaday.io/project/2774-Send-Everyone-To-Space! I will update this thread with progress... and I will REALLY appreciate suggestions along the way. Once I'm reasonably certain it won't cause anything to smoke I'll start a release thread with links to code and such!
  12. I've been trying to work out the delta-v for a trip to Duna all night, so I can compare my work against the Olex calculator to know if I'm doing it right. I'm certainly not doing it right. And I'm about to bang my head into the desk. I'm sure I'm getting confused somewhere with either mismatched units, or I'm getting the variables from the firsts equation confused with the ones from the second. To start with... what I THINK I understand... is that the first velocity equation computes the deltav required to get from kerbin's orbit to duna's... so R1 and R2 are Kerbin and Duna's orbits, in km, respectively(, and u is kerbol's gravitational parameter... 1.167922e9 km3/s2. Is that all correct? I'm coming up with 1.92389... And the second equation is calculating the delta-v to escape kerbin orbit... so for a 100 km parking orbit, r1 would be 700km, r2 would be 82,000 km (the limit of kerbin's SOI), v2 is 3431.03 ( kerbin's escape velocity) and u is kerbin's gravitational parameter, 3530.461 km3/s2. I'm coming up with 4.6661434... Those numbers don't make any sense as answers to the question.... Am I starting with the right numbers? If so... then it's just a dumb math error... but it's apparently a dumb math error I'm making over and over again. I'm attaching a pic 'showing my work' in the hopes that this will make it easy to point out my stupidity.
  13. I haven't had any MAJOR trouble with the ascent autopilot - it sometimes overshoots the circularization burn, so I always keep an eye on that part of the launch... but otherwise, it does great. Things to watch out for - you must have 'control from here' set to a part that points towards the sky... if you're putting together a rocket that includes docking ports, probe cores, landers, etc. that face some direction other than 'rocket up' you need to verify before launch that the controls are being referenced from something that points the right way. You can tell easily by looking at the navball - if it's all sky before you launch, you're ready to go. If you see half ground or all ground, you need to right click a reaction wheel, docking port, or command pod that points the right way until you see all sky. If you don't, the autopilot will helpfully pitch you right over into the ground. Otherwise, if the rocket flies well - as in the loads are mostly straight over the centerline and there's not excessive wobble in between stages then mechjeb can launch it just fine. Does any of that help with your issue? Have you tried launching the rocket manually? Do you have any trouble controlling it at a certain point in flight? The docking autopilot frequently makes strange decisions- the only situational awareness it's got comes from looking at the math... so it doesn't see things the same way a human does. With two small ships that have well layed out RCS thrusters, it will do just fine. If you're trying to do anything more complicated... it has to make guesses about what is where based on the vessel size and such... so it will assign a far-off starting point and safe distance... and even when it doesn't get confused it can waste a lot of rcs fuel getting lined up the way it wants to. Here's a better way to dock with mechjeb - 1. On the less maneuverable vessel, you can select 'control from here' at the docking port you want to use, set the docking port on the OTHER vessel as the target, and then turn on Smart A.S.S. and select "Target +". This will make the vessel you're going to dock to point their docking port at you. You don't have to do this step, if it's a big station or something that doesn't like to rotate - but then you have to work a LITTLE harder because you have to get lined up yourself. 2. Switch back to the more maneuverable vessel. Target the docking port you're headed for. Select 'control from here' for the docking port on your vessel. Turn on Smart A.S.S. and select 'Parallel Minus.' 3. Now one vessel is keeping the ports parallel and the other vessel is keeping them facing at each other. Switch the navball to target mode, if it isn't already. Use the "H" key to get a little forward velocity towards the target, then use "IJKL" to put the yellow 'relative velocity plus' navball bug right in the middle of the pink navball 'target' circle. If you keep the yellow bug in the pink circle and keep moving forward at a reasonable rate- docking complete.
  14. I'm working on a hardware cockpit for kerballing... and discovering Telemachus today just saved me weeks of trying to learn to program in C# and figure out how to find my way around KSP and Mechjeb! I dug out the TI Connected Launchpad board that I bought when they came out, played with the demo app, and then put on the 'someday' shelf and told it that it's day has come.... and an hour later I had the two physical buttons on the launchpad commanding mechjeb to dance back and forth between prograde and retrograde! Along with the built-in ethernet support, the launchpad has over 60 GPIO pins, and with an impressive list of pwm, i2c, uart, and usb functionality - all for $20.00! And it can be programmed with Energia, which makes it accessible to anyone who's tinkered with arduino. And, because it's communicating with the simulator via network, there's no reason you couldn't expand it and have more than one... if you REALLY needed more than io (and didn't want to use an io expander). I think it's going to be perfect for getting myself a cockpit full of buttons switches and blinky lights.... and I'll of course share as I go. All that said - I've got a question for those who know more about Telemachus than I do... is there somewhere that documents the maximum and minimum value for all of the settable parameters? (other than the boolean ones... I think I can handle those! ) The API lists them... but I haven't found the range of values yet. I suppose it's the same range as what the query's report... so I'll just spend some time watching the values change and see if I can figure out what sorts of values it expects sent back... but I wanted to ask in case it's all written down somewhere I just haven't looked yet! And... one quick (and then one probably slow) feature request... Is there any chance Telemachus could get a mj.killrot api command to activate kill-rotate? And the (probably) slower one... I wish there was a way to query the mechjeb mode... or at least keep track of the last command that Telemachus sent to it... that way you could use lighted buttons that would show you what autopilot mode you currently had selected. This would be especially handy since the on-screen A.S.S. window just says "Auto" when it's responding to a Telemachus command. If that's overly tough... would it be substantially easier to query mechjeb to find out if ANY autopilot control is currently active, so you could activate a light that told you that mechjeb was controlling the ship, so you knew to press the 'off' button if you wanted it to let go? Thanks for any help anyone can provide! Art
×
×
  • Create New...