kujuman

Updated Roadmap Development and testing of features for RPM version-Complete Development and testing of toolbar enabled (standalone) GUI-In progress Need to get text to display on GUI, though I know how to do this (just have to do it) Need to implement scaling for GUI Want to save window position Release v.3, RPM + "standalone" GUI (estimate 3 days) Development and testing of in game runway editor/adder (so you can set up ILSs wherever, ie, bases on laythe). (rewrite nav beacons to be simpler, runway beacons to be 2x of the new beacons)? Release v.4 bugfixing Release v1.0 Current Known Bugs: 1) G/S not unidirectional. I don't know what logic I want to use for this Current Wants (not assigned to a version yet) 1) In game runway configuration data page (think http://aeronav.faa.gov/d-tpp/1407/00377AD.PDF )

I'm planning on doing this challenge correctly in the next few days from IVA...it's to test a mod I'm working on ...but... I couldn't help but think about this challenge a lot today...so I thought, what would be the stupidest way to go around a bridge if we could use what ever parts we wanted...

Successfully completed moving almost all functionality of the HSI from the InternalModule that works with RPM to being in a central NavUtilLib. The idea behind this move is three fold: 1) I want to make very easy to add new types of navigation displays if required 2) help reduce computational overhead by calculating certain figures only once (may not be a net gain in speed, but it makes maintaining much easier) 3) make the experience between the RPM and a future stand alone version much more unified for both the user and the developer. Still to do: -Move on screen text from being managed by RPM to being rendered on to the RenderTexture -Design and implement a GUI, including in game runway configurations -Figure out if Toolbar should be a hard dependency or not, then integrate it -Test on OSX and Linux (testers wanted ) -Develop a Runway information page -Make G/S only work in one direction (right now it "bounces" off the runway)

Very cool! I don't have the skill required to compete in this challenge, but I was wandering if anyone had used the thrust from another engine blowing onto the aircraft to help it accelerate? I would think this would be of most help at launch. Also the rules say the craft can't be on the ground during the flight...is it allowed to use wheels on the walls of buildings or vehicles we park (particularly the astronaut complex, assuming the colliders are okay with it)?

I've added marker beacons, with both visual and aural clues. I'll throw up a video sometime today of the current version. To do: Debating LOC and G/S flags for out of range conditions Need to make G/S one directional Restore LOC backcourse functionality (I don't know where I broke it) Debating adding a "Zone of confusion" Debating adding a Runway Information Page (airport diagram, other parameters) Test with a few RPM implementations and write MM configs Right now it only works in RPM, but I am going to release it as a standalone as well. My current roadmap: Development and testing of features for RPM version-Ongoing Release v.2, RPM version only (estimate at least 1 week for public release assuming everything works well, please PM me if you're willing to test before that) Development and testing of toolbar enabled GUI-not yet started Release v.3, RPM + popup GUI (estimate 2 weeks after v.2) Development and testing of in game runway editor/adder (so you can set up ILSs wherever, ie, bases on laythe) Release v.4 Release v1.0, bugfixing

First off, I'd like to thank you for not only developing and maintaining a great mod, but providing such helpful documentation in the wiki. With that said, I figured I'd show off a plugin I've gotten back into the swing of developing that provides a horizontal situation indicator to allow for instrument landings from the pit. Developing it for RPM was a steep learning curve (the worst part was figuring out how to work with RenderTextures) but thanks to the wiki it was relatively simple once I cleared that first hurdle.

Boom! A little bump with the news of the morning. I have a version working in RPM right now, and it's pretty awesome I must say. Still really hard to fly with a keyboard, but that's my problem... The runway can be cycled with buttons 8 and 9 and the glideslope can be cycled up and down using the arrow keys on the right (I'm using Hyomoto's mod of RPM, so I may need to have additional configurations) I need to clean up the code a bunch (I'm using a lot of hard coded figures) and think about expanding it to work with an outside the pit mod (as originally envisioned), so that the targeted runway and glideslope are consistent when changing views.

I'd also add that it makes sense to have control surfaces as far from the CoM as possible if you're trying to induce rotation because the increased lever arm will lower the force required. Roughly speaking, a vertical stabilizer/rudder 2x as far from the CoM only needs to generate half of the force to get the same stability. Smaller control surfaces => less drag, less structure, and can induce the same torque with weaker materials. Consider that most early aircraft have a big ol' engine in front, leaving the front of the aircraft very close to the CoM. You'd need an enormous rudder if you placed it in the front, and a much smaller one if placed in the rear. So for structural reasons, in addition to the other aerodynamic reasons, an aft rudder makes sense. I was half expecting you to link this video of a B-52 which lost most of its vertical stab.

Oh I visit very often, just usually don't login. On this mod: I lost my windows install around February so I'm looking for my backup files for this mod. I recently got into spaceplanes again because of SP+ so I thought I'd go back and try to fix the (major) bugs left with this mod.

http://wiki.kerbalspaceprogram.com/wiki/Version_history#v0.18.4 In short, we got: Docking Maneuver Nodes All the labels on map view apart from Ap and Pe Renaming vessels I think that's when we got the new resources (with transfer and such) Music I think that's when we got the new menu (3d models of Mun and Kerbin) Probes Action Groups and a bunch other stuff. I still remember when I first read Harv's first post on the .18 update, when he showed us progress on being able to click on orbit lines in the map view (required for maneuver nodes) and that maneuver nodes were the big seller. It was a huge improvement from .17 when we had planets but it was very difficult to navigate to them in stock.

Ok, I think I got it now. So anti-roll is to keep the body of the vehicle more or less level (left to right) even if the wheels are not. I had originally thought it was some system to limit steering angle to keep the net acceleration (gravity + slope + centripetal) of the vehicle's CoM between the wheels, which seemed like a big task.

I really think this has a more fundamental problem: that we're trying to use a few sets of wheels to address a huge spectrum of gravity, rover masses, etc with one set level of friction. Instead of trying to balance for use on the Mun vs Kerbin vs Eve vs Gilly, tweakable frictions might be a better solution. As an aside, if you want to drift using stock wheels and not roll over, use physical timewarp, it screws with the physics enough to make rovers super easy to drive. I'm curious as to what this means/how it works.

Just curious if you mean that every rocket must have a separate contract or if every mission needs a contract? ie, does assembling a ship in orbit need two contracts or only one? And I've seen some posters refer to reputation being in .24; just wondering if there's a link to the source, see if there's any more info to be had from it.

I imagine that was due to 1) the purpose of the NOTSNIK program being a tech demonstrator rather than a fully developed program and 2) perhaps the mass of hardware had been significantly reduced by improved electronics (lower mass avionics make a bigger impact on low payload masses). If we take the nominal payload fraction of a ground-based launcher as .05, then a 100kg payload would require a 1900kg launcher (total start mass 2000kg). This is well within the capabilities of the F-15 (total lift, whether any individual hardpoint can carry that I don't know). For an idea of how big the F-15 is, its max take-off weight is 81,000lbs (for the strike eagle variant); the Falcon 1 massed 85,000lbs.

One of the things the article you linked mentioned was that the Israelis are looking at using F-15s to air launch 100kg payloads. For light military payloads (I have no idea what these would be...maybe anti satellite / ABM launchers?), this seems to make sense. Rapid deployment and avoidance of weather seem like useful attributes of air launch. Also, I'd expect air launches can be done more "stealthy" than ground launches. I'm curious as to the delta-V savings one would expect for certain orbits, eg, trying to launch equatorial payloads when your closest launch facility is 25 deg north or south of the equator, since a plane could possibly fly to the equator before launching. Compared to a space plane, some staging is always a good thing. I just don't see how you get around that with a space plane with modern propulsion.

Oh, we're adding albums of our creations with SP+? Can do I've always liked the Mk2 cross-section, but it just didn't have enough parts (particularly such mice parts) for me to bother with it too much. Now I have a heavy launcher space program and a light spaceplane program. Thanks Porkjet! I've always liked the types of names the Royal Navy had for its ships, and vessels so far are named based on real ships (Encounter and Amethyst are both Amethyst Class ships in my program and Champion is the sole Comus Class so far). I don't really role play in KSP that much, but these parts demand it.

I don't have time to answer this directly, but I think this video has an explaination

I'm trying to think of a world in which KSP never had mods. Would any of us be here if that were the case?

More updates Nozzle code is now based on ModuleEnginesFX, so it will natively support (at least, better support) the new effects system. I've also enabled the old effects system to work with it via a bool in the .cfg. So effects are working nicely. I wrote a MM config for the KW pack and it works nicely with AdvSRBs. Still want to enable the player to set one thrust curve for the entire stack. It shouldn't be too difficult, but integrating it into the UI nicely will take some thinking.

Does the current feature list include feedback to the user that a command has been inputted? I imagine you've thought of that. I just tried testing using System.Speech.Synthesizer but KSP did not want to load the .dll Oh well. "Mr. Crusher, take us out of here!" *mechjeb applies full thrust after rotating 180 degs* "Aye sir!"

That's not a problem. It gave me time to update the code to address all of the concerns that I had listed in my original post.

Update time! I'm refactoring the nozzle code yet again to be derived from ModuleEngines. The impetus for this was wanting to make AdvSRBs play more nicely with other mods, such as any center of thrust or auto gimbal mods. I don't think that this will help much with some of the mods which make bigger assumptions about fuel flow and need a maxThrust estimate, like MechJeb or Engineer, but it's still a step in the right direction. The testing I've done shows that almost everything is still working as designed except that I broke the effects system again. What a shock. This is something I've wanted to do for a long time, so it's really rewarding seeing it working, and in less time than I thought it would take. With .24 now in experimentals, I may actually get .7 released to coincide with it.

This is a problem for which a solution is being developed, although, I don't know if it will be part of EnhancedNavBall or not. http://forum.kerbalspaceprogram.com/threads/50524-0-23-5-Enhanced-Navball-1-2/page9 I actually visited this thread to test out my new engine detection code with the CSS.

There's been a lot of activity lately with asymmetric lifters and such, and it can be hard to control these lifters because the center of the navball doesn't correspond to the center of thrust. So I've forked the Enhanced NavBall to include a black center of thrust indicator here https://github.com/kujuman/EnhancedNavBall/tree/CenterOfThrust as a proof of concept. If you wanted to include this feature in the next version, there are a few things which should be addressed. 1) The CoT indicator should not display if the CoT is near enough the controlling direction 2) The CoT is computed using the CoT process the game uses in the VAB and SPH, so it is a bit more primitive than anyone would like a) It does not take into account multistages (I think, not tested) It would not include CoT from non ModuleEngines and ModuleEnginesFX (not a huge concern) c) It would not work for an SRB and a LFE if the LFE is throttled down (CoTQuery assumes all engines at max thrust) Link the the thread which sparked the idea http://forum.kerbalspaceprogram.com/threads/77710-0-23-5-Gimbal-Auto-Trim-1-0-%28April-24%29

I imagine this would be possible, but it would be a bad idea. With CoT moving everytime you make a control input, there are going to be really bad feedback loops in the control (like when you "Control From Here" on a really wobbly part ). A much better solution would be to add a node on the NavBall displaying the current CoT. Hmmm, time to head over to the Enhanced NavBall thread... [EDIT: Back from thread] I did some proof of concept work, using something like enhanced NavBall would work pretty well. Of course, your CoT solver looks (I only glanced at the code) way better than the solver I used (the one KSP uses in the VAB and SPH). http://forum.kerbalspaceprogram.com/threads/50524-0-23-5-Enhanced-Navball-1-2?p=1138899&viewfull=1#post1138899