dodrian

Whenever I build a spaceplane with a Mk3 Fuselage, attaching an engine on the end causes the plane to flip out of control when I leave the atmosphere. I can tell that it's because the attach point isn't lined up behind the center of mass of the craft, but do people have any tips on how to fix this?

Perhaps not what you had in mind, but using the Crew Tank, I landed 14 Kerbals on Minimus. I could have had more, the craft holds up to 18. I staged the excursion from the Mun, I had an established base there, and the craft was originally there as an emergency return-to-Kerbin vehicle. But then I decided to change the mission spec! Captain Bill leads the crew

.16 allows for non-command module parts to be crewed (eg. crewtank), but they spawn empty on the pad. Kerbals walk reaaaaaaally slowly, so loading those empty modules can be a pain. It also makes designing rockets tricky, as the largest extendable ladder is too short to reach the ground above a big engine, especially if you\'re using the launch pad clamps. What we really need is a ground crew transport to get kerbins to the launch pad! Crew Transport requires Carts Crew Test craft requires Damned Aerospace crewtank. Warning: Crew transport not suitable for evacuating vessels. I\'d be interested to see what other crew transports people come up with, especially using Damned Robotics.

Really fantastic film!

I also enjoy listening to the Portal 2 soundtrack. 'The Courtesy Call' is my favorite track for launch (time launch ignition with 1:10), 'Bombs for Throwing at You' is good for deorbiting, followed by 'Your Precious Moon' for landing. 'PotatOS Lament' is a hauntingly beautiful track for playing in orbit

Thanks togfox, I am still working on it, though I got a bit distracted doing research for my BA dissertation :-). I\'ll consider that for the next version, which I hope to have out later this week, it\'s certainly a cool idea.

Can you add extra batteries / other energy storage systems onto a probe?

Yeah, it doesn\'t like a lot of sideways movement, nor does it like it when the capsule is travelling up (though I thought I killed the bug which was causing it to flip over when you were travelling at very low speeds). Part of the problem is I\'m adapting some of the rotating code from MechJeb, and even though r4m0n has helped explain what it does, I\'m still not quite sure of the exact mechanics behind the vector rotations! Vectors was never my strong subject in maths

Thanks for the suggestions, what\'s really really odd, is after posting the other day, I shut down KSP to do some work. When I came back to it today, it was working correctly! I swear I haven\'t touched the code! Maybe the real problem was I forgot to copy over the correct dll or something equally stupid. Sorry for bugging you!

How I think it would work: A part implementing IGeneratesEnergy would, when created, search the ship for the EnergyManager, then register itself. A part implementing IStoresEnergy would do the same (there would probably need to be unRegister methods as well, for when parts are destroyed/disconnected/broken). Everytime the EnergyManager updates, it goes through its list of IGeneratesEnergy parts, and requests the energy from the part (perhaps it should pass a timestep, and they return how much energy they generated in that time period in wattHours, or an appropriate unit). It then goes through its list of IStoresEnergy parts, and attempts to put all the energy generated this timestep in the storage devices. Whenever an IUsesEnergy part updates (technically we don\'t actually need this interface yet, as there are no methods that are needed by the EnergyManager), it requests an amount of energy from the EnergyManager (which then searches through the IStoresEnergy list to find the energy), which returns the amount the EnergyManager was able to come up with (usually this should be the full amount requested).

So, Cephei got the ball rolling by creating a module for having an ion engine powered by solar panels and a battery. It\'s a great start, but as far as I can tell, it essentially copies the fuel system, requiring energy using parts to be physically attached to each other. I\'d like to propose a more generic system of electricity generation/storage/usage, the idea being that many different parts (sensors, ion engines, lights, etc) might wish to use electricity, and that wires on a spacecraft/station would be internal and not noticeable by the user (kind of like how RCS currently works). My basic idea is something like this: (please excuse me and correct me if I\'m using the wrong units, it\'s been a while since I did a course on electrical stuff!) The idea of this would be that there would be one main system for electrical usage, which modders could fairly use with their own parts/plugins. So, the plugin I\'m proposing would provide the EnergyManager (perhaps it should be renamed ElectricityManager to avoid confusion) part type, and three simple interfaces for interacting with it (generating, storing and using electricity) for other plugin makers to use. From the user\'s point of view, they would download this plugin (which would be licensed so that other modders could also include it in their downloads if they wanted), and then be able to mix and match different electrical using parts (for example, someone might make a set of ion engines, someone else might make various types of batteries, and someone different might make a radioisotope generator, and/or a set of solar panels), but have them all work nicely together (i.e., you don\'t need to use different sets of batteries to make sure your station can use parts from different peoples\' packs). I\'m mostly interested at the moment in what other modders think. I believe NovaSilisko intends to make some of his parts run on electricity, and personally I think building rovers would be more fun if we had to make sure they had a suitable power source + battery that could survive the Munar nights and be able to power all the sensors available, so I\'m sure I\'m not the only one who would like a general way of using electricity. It would also provide a way for new modders wanting a taste of KSP modding to be able to create a part, say a solar panel, without having to make an entire pack for that part to be useful. With that in mind, some specific questions: [list type=decimal] [li]Are modders interested in using this (i.e., would you implement an electrical standard in your parts if there were one available)?[/li] [li]Is anyone already working on something similar already?[/li] [li]Would anyone like to work on this? (Personally I\'d be very keen on coding the first version, with community input and help of course, but I don\'t want to start unless i know others would appreciate it!) [/li] [li]Do you think my interface ideas are appropriate? If not, how would you improve them?[/li]

The variable is definitely updating correctly, as it\'s the same variable being used to determine whether or not to take control of the throttle. What\'s happening: Game starts, GUI loads, toggle not set (correct behaviour). I press the input key. The computer takes over control of the throttle (correct behaviour), but the toggle remains unset (incorrect behaviour). Or, I can click on the toggle, it sets, and the computer takes over throttle control (correct behaviour). Ditto for turning it off. What\'s also odd is that I can click on the toggle, but pressing the input key won\'t turn the computer off. If I then click on the toggle again (setting the toggle back to the off), the computer continues running until I press the input key a second time. Ditto for the other way around (input key first, toggle second). It\'s as if there are two separate [tt]computerRunning[/tt] variables, and to determine whether or not to control the throttle, the program checks [tt]if (computerRunning1 || computerRunning 2)[/tt].

GUI question: I have this code: if(computerRunning != GUILayout.Toggle(computerRunning, 'Throttle', GUI.skin.GetStyle('Button'))) { if(computerRunning) stopComputer(); else startComputer(); } That works fine for turning the computer on and off with the toggle button. But if I turn the computer on or off by another means (in this case a key press), the toggle button doesn\'t get updated (and other weird behaviour). Does anyone know what I should be doing instead?

Is \'u\' not working as in it\'s not controlling the ship, or is \'u\' not working as in it takes over the ship but then causes it to crash? It only really works at the moment if you\'re heading down and don\'t have too much horizontal velocity. It will (hopefully) kill the last bit of horizontal Try manually coming in (with \'y\' assistance) and pressing \'u\' when the altimeter (the real one next to the part icon) says about 50, and let me know what happens.

OK, I\'ve made some changes and added a new version! Now it can help you with steering too :-) Press \'y\' to turn on throttle control. When descending, you can also turn on helm control with \'u\' (changeable in part.cfg). Remember, this is just meant to help you with the final few hundred meters of descent! You need to be going at a fairly low lateral speed for the helm control to work (otherwise testing has shown that dodADA will flip you over instead ;P) I want to make a few more changes in the next version, especially code restructuring to make it more readable and adaptable. But I forsee a few more things being added to make the module a bit more intelligent (at the moment it just guesses at things like speed and heading). I also realize that MechJeb now has landing options. I\'m not trying to make dodADA distinct or better than r4m0n\'s efforts, I\'m doing this because I enjoy tinkering with code ;D. I\'m going to keep releasing dodADA because people seem to like it and also in the hopes that others will see the dodADA source and be inspired to tinker themselves . Anyway, let me know what you think of the new changes, and if you see any problems!

Thank you! I finished my last assignment for term today, so I can get back into the coding. Currently the lander keeps flipping itself upside down right before landing, which isn\'t good :-/. When I\'ve sorted that out, I release another version.

My part currently works only on user input (pressing a button, but I hope to add a GUI which makes it easier to turn off/on in the next version), and the user always have the option of overriding the helm control (by turning it off). When off, dodADA shouldn\'t interfere with other autopilots at all (if it does then there\'s a bug in my code somewhere, or I\'ve misunderstood how the whole system works). If other developers felt we needed to add a helm-control system, I would implement it in my plugins, but I don\'t see it as necessary for what my part is designed to do (control the helm, but only when the user asks it to). Maybe this would become necessary for parts that are designed to fully-automate an entire mission, but at the moment that\'s not happening. A discussion I think maybe we should have though, is about namespaces, as I\'m pretty sure I\'m not the only one who will write a class called \'FlightComputer\' (I\'ll be calling it \'dodFlightComputer\' in the next release).

Yeah, I\'m definitely making that an option, don\'t worry

ordinateur-de-barabara-bouley:~ barabarabouley$ /Users/barabarabouley/Downloads/KSP_osx-3 You need to put [tt]cd[/tt] in your first line (change directory). cd /Users/barabarabouley/Downloads/KSP_osx-3

Well, you don\'t have to use it . Personally I\'m doing it because I\'m enjoying the challenge of coding it. I\'m just happy to release it for others to play with/learn from. I started it because I honestly found the throttle too difficult to control with just the keyboard. I\'ve found throttle control alone really helpful for when I\'ve been trying to maneuver at low altitudes on the Mun, it\'s stopped me from crashing a number of times. It\'s also really useful for landing top-heavy or large rockets, especially when they need a really sensitive touch on the controls. Adding in the rest of the landing automation was just the natural progression of what to do next! I have an idea for another cool plugin too, but want to get this one in a proper releasable state first.

Thanks r4m0n, that\'s really helpful and has shown me how to do this: I\'ve got a lot more exploring and testing to do, but now that I know what\'s going on I can better code a version to my purpose . Thanks for explaining!

A little sneak preview of the next alpha release: Still a few major bugs though, and I\'m really busy this weekend, so I can\'t promise a release yet, but will get it out before too long!

Thank you, that\'s helped me understand a bit of what\'s going on. If I wanted to remove the PID controller, could I replace the variable [tt]act[/tt] with [tt]err[/tt] in the following code and have the module still work? (obviously it wouldn\'t work as well, but would it work a bit?) s.pitch = Mathf.Clamp(s.pitch + act.x, -1.0F, 1.0F); s.yaw = Mathf.Clamp(s.yaw - act.y, -1.0F, 1.0F); s.roll = Mathf.Clamp(s.roll + act.z, -1.0F, 1.0F); (I don\'t want to remove the feedback controller, I\'m just checking if I\'m understanding it right.)

Could someone explain the maths in the MechJeb plugin? I want to write similar code that will let me point the ship in a direction of my choosing. I think this is the relevant bit: Quaternion tgt = Quaternion.LookRotation(tgt_fwd, tgt_up); Quaternion delta = Quaternion.Inverse(Quaternion.Euler(90, 0, 0) * Quaternion.Inverse(vessel.transform.rotation) * tgt); err = new Vector3((delta.eulerAngles.x > 180) ? (delta.eulerAngles.x - 360.0F) : delta.eulerAngles.x, (delta.eulerAngles.y > 180) ? (delta.eulerAngles.y - 360.0F) : delta.eulerAngles.y, (delta.eulerAngles.z > 180) ? (delta.eulerAngles.z - 360.0F) : delta.eulerAngles.z) / 180.0F; integral += err * TimeWarp.fixedDeltaTime; deriv = (err - prev_err) / TimeWarp.fixedDeltaTime; act = Kp * err + Ki * integral + Kd * deriv; prev_err = err; I see how the [tt]act[/tt] variable is later applied to the [tt]FlightCtrlState[/tt], that bit makes sense to me, what\'s confusing me is how the [tt]act[/tt] is being derived. I think it\'s partly confusing because there\'s a feedback loop to help make the movement smoother, could someone maybe write code / psuedocode showing how the process would work without the loop, so I could understand it better? I guess the main question is: How do I go from having a desired heading in a vector, to applying forces in the correct direction to orientate the ship towards that vector?

That\'s quite funny! I hadn\'t noticed that, and it\'s really not what I intended to happen! I\'ll see what I can do to stop it (I would rather have it only work for a ship that has the part on it, that way if there are mods that conflict with this one you can still use it in the same game). Tell me— when you tested without the legs was there another ship with the legs on in the game? Nearby? I think what might be happening is other ships are loaded, and the flight computer from that ship is being used.