r4m0n

The engines will throttle down to keep your vessel level. If you add engines in a way that will unbalance the vessel, you will lose thrust.

Yes, you can include the latest version of MuMechLib.dll (always found here). It is already included in half a dozen packs, so always using the newer one is a must.

Feel free to use anything from MuMechLib

Here is a reference of all keys Unity will accept, just use anything from the first column.

'all the particle\'s behavior' is also incorrect. Unity doesn\'t have C# classes for MeshParticleEmitter and EllipsoidParticleEmitter, so the attributes unique to them are inaccessible, making some changes impossible. Also, I haven\'t been able to change the color of the particles in my attempts, but maybe I just didn\'t try hard enough.

Correction: Cloning one of the existing effects and changing a few parameters takes only a few lines of code, creating a new particle effect purely from C# is currently IMPOSSIBLE.

2. return base.RequestFuel(Dest, Amount, Part.getFuelReqId());. This is a working standard fuel call I came up with. Dest is the engine itself, Amount is fuelconsumption normalized for deltaTime, and possibly timewarp depending how used. getFuelReqId is complicated. Looking at the parameter lists, it appears vanilla fuel handling is done (async?) with a call index. This method call works for me, but I\'ve seen multiple versions in other people\'s code. 3. protected void ApplyThrust(Part Me, Vector3 force, Vector3 origin) { if (force.magnitude == 0 || physicalSignificance != Part.PhysicalSignificance.FULL || rigidbody == null) return; Me.rigidbody.AddForceAtPosition(force, origin, UnityEngine.ForceMode.Force); } ApplyThrust(this, thrVector.normalized * thrust, transform.position + thrustCenter); I call this in a function, so Me = this. This is the heart of the engine code, is the AddForceAtPosition. It takes a direction vector with magnitude=m/s^2, the position to apply force at, and the mode. 4. Visual effects I just use an on/off if statement, and Mathf.Lerp(0.5F, 1.0F, (float) (thrust/maxThrust)); to scale the effects. No idea if this is the right way to do it, but it works for me. I\'ve done this in 3 posts just incase it\'s decided something is too detailed. I don\'t use or have a decompiler, and this is all my own code, anyone if free to use it. I tried to keep it as generalized as possible to avoid possible appearance of duplicating KSP code, some things can only really be written one way without intentionally adding slowcode however. Talking about trying to 'avoid possible appearance of duplicating KSP code' makes it sound like you read the source . I haven\'t used your code in the VariableEngine yet due to the lack of gimballing, which is quite important (and tricky to implement well). I did have an idea of an ugly hack to do away with the deathray while keeping the base code intact, though, and I\'ll be trying it soon.

By using several of them. The new Toggle/Servo module supports an unlimited number of colliders (sure, if you use too many the game will slow to a crawl ).

Are you talking about using the toggle_collision flag? If so, don\'t, it doesn\'t work well... If you are talking about using the new servo class for making proper doors, I\'ll document them soon.

There is no 'locking' with ConfigurableJoint, you can only use limits (which with linear joints you only get one, that limits from -X to X, and so is useless for my purposes) or a motor to set the position somewhere. For rotation I set an upper and lower limit to the same spot, which effectively locks it (with a VERY stiff spring trying to move it into position), but for translation I\'m left with the motor, which works rather poorly. Also, 95% of the possible configurations of the ConfigurableJoint do absolutely nothing without any explanation, which consumed several of my hours until I\'ve managed to get them to behave (and they still misbehave when I\'m not looking).

Is there any way to skip over the Part1 method in the daisychain and call the Part methods themselves? I found something on delegates, but it was getting ridiculously complicated. ED: Assuming the only code that can be modified is the Part2 class. Too lazy to try it out, but you could try something like: class Part2 : Part1 { public override void MethodA() { dosomething; typeof(Part).GetMethod('MethodA').Invoke(this); } } Mind you, this is an abomination in the name of inheritance, but probably works because of the way Reflection works. There may be some actual mechanic in the language to do that more cleanly, but I\'m not familiar enough with C# to tell for sure (but apparently I know enough to spill that abomination above ???).

ASAS won\'t do anything, SAS will only help you keep it from moving. RCS will help, but it is pretty much broken for roll, so if you want to roll things with it, make them wide and have the RCS thrusters as far as possible from the center of the vessel. Gimballing engines also help a lot while you are with them on.

I think allowing MechJeb in this one makes things too easy, here is the result of my first try with a 100km, 0 and 180 inclination launch, with absolutely no correction after achieving orbit: That probably isn\'t even the closest approach, but I guess I got lucky that it was in the screenshot at all, that thing was FAST.

There are 5 Munoliths total in Kerbin

I\'ll have to promote all classes to public, but that is alright. I\'ll try to do that for the next release.

4 engines, without MechJeb 8) http://kerbalspaceprogram.com/forum/index.php?topic=9729.msg147295#msg147295

Try reinstalling it, and make sure to overwrite the MuMechLib.dll on the Plugins folder. If it\'s still giving errors after that, please attach your output_log.txt from the KSP_Data folder.

Install it in a craft, activate it, and if there is a Munolith in range (there is a short and long range version) it will beep with a frequency proportional with the proximity of the nearest Munolith. The long range version will also blink a green light if you are moving closer, or red if you are moving away from it.

Easter egg hunters may find this useful: http://kerbalspaceprogram.com/forum/index.php?topic=10170.0

Muon Detector - 1.3 After extensive research on the mysterious Munoliths, Multiversal Mechatronics has found out they emit a continuous Muon radiation, and made this detector to help locating the anomalies. Download here Source code available here, GPL license New products will become available as research proceeds.

Within the game simulation limitations, that is correct. In the real world things are a bit more complicated, with uneven gravity fields and multiple gravity sources, so a orbit too low on the Moon would probably eventually crash somewhere. But in the game, if you could switch to on-rails mode at 5km, you would keep orbiting forever.

Here are the last 2 Munoliths on Kerbin, near the KSCs: This one is the one found by Candre: And this one will be easy to find for the people who know where the second KSC is ;P Now, to the Mun!

First, for the request: Maybe. I could make an UI to toggle the modules else than just use buttons, but that also adds to the UI clutter, which I guess is a little better than the keyboard clutter we have right now. As for the 'bug': All is working as intended. Solar panels aren\'t meant to produce Liquid or RCS fuel, VariableTanks aren\'t meant to store Liquid or RCS fuel (use the default tanks for that), and the engine code can\'t look for real Liquid and fake 'liquid' fuel at once. If you want to use the Solar Panels, then go all the way, you can\'t keep compatibility with stock and use that.

Next time I\'ll tell Causeless there are ponies around Kerbin to see if he will also post that info, at least give some credits to your sources No, he hasn\'t found any yet XD I\'ll post some shots of the other Munoliths (can we even call them that now there are some on Kerbin?) soon. Update 1: Here are the 3 Kerbin Munoliths: The last one was particularly tricky to get to... I\'ll go visit the Mun ones later. Multiversal Mechatronics MAY or MAY NOT be studying the Munoliths, time will tell... :-X Update 2: And looks like I\'ve missed 2 extra Munoliths on Kerbin, are those things multiplying?

The so called 'Most Gee Force Endured' seems to to only record the value if you can keep approximately the same G reading for a period of time. This was probably coded in to ignore spikes in G, but else than averaging the last few values or something more sensible, it is simply ignoring values that change too fast, making the G meter useless. Trying to find the angle that measures the most G in my 400G deceleration ship going straight down is frustrating, so I\'ll just wait until it\'s fixed. PS: You can measure what the actual G\'s would be with the Reentry module of MechJeb. Just fire it up and check the predicted max G after you stop burning.