Kreuzung

No offense, but your post is nonsense except for the sound files and the 1024^2 textures. Mu had a reason to introduce mbm as a texture format, and I'm sure it won't work to keep the textures in a separate folder, try that out before you post:sticktongue:. This is a mod still in development for a game still in development so you cannot expect it to be optimized to the death.

Yes. place a decoupler inside:sticktongue: (There's a bug with snap angles, if it's turned on, you need to rotate the decoupler manually) I reported some bugs on the previous page, did that got lost due to failBulletin not showing you new posts made while you where typing?

Some issues... 1) I cannot find which key to use in your post, only in the part.cfg 2) Saving a ship with opened cargo bay fails (after loading, the doors are closed, but if you press the key, they insta-open then close again) 3) Does not work if the cargobay wasn't activated by staging 4) It still works if the ship is not controllable anymore (all on EVA etc) 5) Why not a context menu instead of a key? You don't have to quickly open and close the cargo bay, so using a key here is overkill in my opinion. It could also result in conflicts with other plugins (some have HARDCODED keys AFAIK!) 6) It's possible to control them from outside the ship. This can of course be seen as an advantage, but it might become annoying if you have multiple cargo bays at the same spot. Using a context menu whould help here too.

Both IonRCS and Powerconsume are unfinished stuff, I know much people want energy consumption on everything, might be the next thing to be added.

The solar panels behave weird if rotated, I didn't write the code for sun detection myself because I have no real idea how to.

I said "OR a crew tank", means that it works without if you choose another option:sticktongue:

I did just convert Kethane to fuel for the first time, and it seems to give you more fuel mass than the mass of the used Kethane for me, can anyone confirm this?

A cart either needs a normal Pod, a MechJeb, a remote control with connection or a crewtank to work.

There are differences on the existing bodies, but the new ones will all have the same count and similar sizes until the code is adjusted manually. With the next kethane version, it will probably be possible to make a kethane generator.

Well, EPS does ignore other batteries, but the EPS ones will be recharged by ElEnergy and PowerTech.

Let me explain some things about energy plugins in KSP. Shortly after I got the full version, I played around with the DSM ion engine which was based on an old plugin by Cephei, AFAIK it even was the first plugin ever. It was horribly bugged so I downloaded the source code to se how it works and learn to use the KSP API myself to improve the plugin, however I found out that it was made from decompiled game code so I reported it to the moderators and started rewriting it based on MuMech. ZO2 was not based on EPS at the moment, it had an easy way to recharge it though which I used to make an airfilter part which filtered ZO2 during the night. A bit later PowerTech_MuMech came out to provide compatibility with my plugin and MuMech. With the release of .15, I tried to get away from the MuMechVariableTanks as they weren't made for recharging, and PowerTech_MuMech becaume obsolete and was replaced with a simpler system integrated in the main class for solar panels, SolarPanels_adv_PowerTech. A bit later Zoxygene updated to EPS 0.1, which didn't allow for part modules AND had the old recharge thing removed and therefore all compatibility to ZO2 was lost as I didn't want to go back to normal part types. PowerTech contained an EPS-Compatible type from then on. With the new EPS 0.2, there is however a limited compatibility between it and my plugin, as my plugin does recognize EPS batteries, but EPS ignores other batteries. I did even ask if we should merge the plugins into one before releasing EPS 0.2 and ElEnergy 1.4, but got the reply that they'll work together anyway (which is no reason to not merge them in my opinion), so I did release ElEnergy 1.4 a week or so before EPS 0.2 came, and I think the fact that it does work together with EPS (which I only knew about that it uses part resources to save the energy too), but NOT the other way round shows that it'S the better choice. Also, if someone wants to write an energy-dependend plugin and chooses EPS, he does end with incompatibility to most stuff and needs a dependency (plugin dependencies are the worst case, had enough of them in the times ElEnergy was based on MuMech), while using ElEnergy does not require a dependency because one can just copy a bit of CC BY (least restrictive CC license) code and also has compatibility to EPS. I don't even know why EPS was made, it whould've been good in .14 times, but now it's just a collection of overcomplicated code that does nothing you cannot have with ElEnergy (direct linking without battery can be simulated in ElEnergy by allowing the source and/or destination store a very very little amount of energy). Summary: MuMech (r4m0n) + PowerTech_MuMech + PowerTech (both Alchemist) = outdated, not the best for energy, though Alchemist fixed a lot of bugs in the system EPS (l00) + (optional) PowerTech = provides around the same as ElEnergy, but is more restrictive Electrical Energy (mine) + (optional) PowerTech = first real energy plugin, had a few problems at first but now it doesn't have any known issues. Compatible to anything that uses energy as a part resource, so it's the easiest thing to base other plugins on. Will probably interact with Kethane and LazorSystem in the future. PowerTech is a plugin for animated things such as satellites and solar panels, it's not a real energy plugin but has been made compatible to all of them.

Information cannot be added from part modules, that's why nothing is displayed.

There's an unreleased pack of new energy parts (5 or so solar panels, 2 batteries, 1 engine) which I'm responsible for. They look really cool but need to be balanced against the other stuff, which means I first have to calculate efficiency values for the other stuff.

They can be anywhere since version 0.13 (when it switched over to my plugin). I always place solar panels on the centrifuge so that they can't be blocked by other parts.

Yes, had Avira Internet Security at the point I got it:sticktongue: Though I think the virus programers deserve the money much more than the people who just copy and torrent everything:D

I have 2 cargo bay test parts on my hard drive and heard of some others. One of them was finished and just waiting for my part module to be released, which happened yesterday, so it will come out soon.

Don't worry about solar panels, there's a much better set by Dani-Sang which I'm responsible for, but I got tired of it after calculating the energy/volume and energy/mass ratios of all the batteries we have so far (did you know that the large one from the Deep Space Mission Pack is way underpowered even if it feels likea cheat part?). Did something else instead, but now I'll probably resume to work on that. Don't even know where to get solar panel surface area from for most parts except bugging the authors and searching for old parts in my .14 folder...

As of 1.4.2, the energy plugin also contains a part module called ModuleKrAnimation, which can be used for different things, such as cargo bay doors, landing legs, parts that deploy in some form if they activate (should work with anything activated by staging), stuff that can be "used" by EVAs etc. Usage: MODULE { [INDENT]name = ModuleKrAnimation <parameters> [/INDENT] } Do NOT use the string paramters with the Quotes!!! extendAnim = used animation (this has to be set. If you don't know the name, just apply the part module without parameters and load the game. Place the part on a new ship, and open debug console with Alt+F2. It should show some lines that start with * or **, AFAIK the ** ones are the animation names.) extendGUI = GUI name for extending (default: Extend) retractGUI = GUI name for retracting (default: Retract). Set this to 'none' to disable the retract GUI option. controllableInside = 'always' to always allow controlling it, 'commandable' to only allow if the vessel can be controlled, 'never' to disable manual control from inside the ship completely (default: always) EVA_Range = range in meters in which Kerbals are able to control it from outside (default: 0, deactivates it completely) stage = if set to 1, it will extend if the stage it is in is activated (default: 0) landingGear = if set to 1, it will extend or retract if the landing gear key is pressed (default: 0) key = Unity keycode for extend/retract. Please don't spam the keyboard for nothing. state = if set to 1, it will show up the extended state in the editor and start extended on flight scene (default: 0) animPlayStart = if set to -1, it will show the retract animation in the editor, if set to 1, it will show the extend animation (default: 0, might require state to be set to work) energyConsumptionExtend = overall energy consumption while extending (default: 0) energyConsumptionRetract = overall energy consumption while retracting (default: 0) energyConsumptionExtended = energy consumption per second while extended (default: 0, may cause deadlock situations if energyConsumptionRetract is set too) As for modeling, it requires a model in the .mu format with an animation called whatever exendAnim is set to (again, if you don't know which animations the model contains, use the way described in the spoiler to find all animations in the model). For retracting, the animation is played backwards. Note that the part module assumes that the model is in retracted state by default, if it isn't, you might have to use extend as retract and the other way round for some parameters. Get the plugin from the link in my signature, source code included, CC BY license.

Third AKA second but folding the top parts in the other direction. Also, why is everyone making cargo bays at the moment?

http://svn.mumech.com/KSP/trunk/MuMechLib/KerbalAccessorizer.cs creates a unity GameObject that acts independent from the part which just stays unattachable in the VAB/SPH. This is a secret feature of MuMech only available for the testing team, it adds sunglasses to the Kerbals.

Yes, but that's because all the other 3m parts are wrong. This pack uses real 3m, the other ones are all rescaled and should either rescale or rename their parts in my opinion.

You don't want to know how much of these we have in Germany. http://bka-trojaner.de/ Each one works different, there's no way that works for all of these except formatting the hard drive. If you need your data, you depend completely on Google and your knowledge... for example, I couldn't find a tutorial for my version, but I did find it by searching suspicious processes in the task manager from another user while the thing was active. Was just a file in temp and a shortcut in Autostart.

For DynaVolt it's not necessary if you have the latest Dynasat pack (get it here). EPS and ElEnergy parts are not really balanced against each other, you might want to increase the "power =" value in the DynaVolt config as they're a little weak compared to the ZO2 system. Not that as far as I know, EPS energy gain values are per fixed frame (1/50 second), while PowerTech and ElEnergy values are per second.

Currently only the Deep Space Mission pack, but there will be a cargo bay part using this plugin soon. The next Truss Pack might contain some parts using this plugin too. Also, uploaded 1.4.2, only slight changes here, will be required for the cargo bay though. Documentation will follow, too tired for that at the time...

I thought about that, but I didn't want to mess with just another thing in the source code, and what whould happen if you run out of energy while the animation is going? A solution to that might be consuming the whole energy that's needed before playing the animation, might add that before releasing it.