Reflector

Appears to break the new engine system and makes it consume fuel like the original mode when I tested it.

Since .16, the LiquidEngine module has been considered replaced by the LiquidFuelEngine module, any chance of updating this plugin jgjiscool? I\'ve found it useful on some ship designs which use mixed engine types for variable thrust vs fuel consumption capability.

You\'ll end up with two trees of code plus a variable (See: 'oldWarpSpeeds == true;') that splits you between making the time warp variables from the old and new modes. Tie your warp speed indication text to each tree. Unless you want to imply making graphical assets is easier than that.

Might I put in a suggestion for a variable warp setting? 'Old Warp Speeds' ticked = 2x retained, 100k x removed. Untick for 100k warp but no 2x. No GUI assets changed but there will be new lines of code there and a setting.

Figured it out, I had to convert all the solar panel types (D\'oh, that was all me for not looking closer). Batteries work fine now but it still seems to like to drain from the top one that is placed before the lower one.

Yeaaahh, doesn\'t look like Dropbox wants to not die, would you be able to upload that onto Mediafire or something? Edit: Have zKreuzung.dll already. Do I drop PowerTech_MuMech.dll? Double Edit: nope.

Looks like I have the MuMech version. Edit: But it looks like Dropbox also seems to hate me at this moment.

The solar panels do not recharge the first battery (It is indeed ordered at the top and has been deleted and readded before) when it is fully discharged. Even if I discard the lower stage with the massive battery, it will not recharge the top battery with the solar panels deployed (They are shown to generate power.) Any ideas? I should mention that the topside of that is placed upside down (So the order is, with right as topside: Capsule, Fairing-Decoupler, Decoupler, Decoupler, Battery, RCS tank, Decoupler, Decoupler...) I have tried it as 'Part' and it still does not recharge. As far as I can tell, I did a configuration copy so it should functionally be the same as the new values.

http://i.imgur.com/e7Qep.jpg http://i.imgur.com/LkD4Z.jpg Looks like I have an intense case of the 'nope's (I have copied the configuration over and modified the amount of energy stored in the battery) for staging order based battery discharge. Additionally depending on module type what those batteries are configured as ('Part' vs 'Strut' vs 'Battery') they will either stay dead when discharged (Former two) or only charge up to 100 on a single battery (Latter case.) Any idea what could be causing this on the updated version? It would be helpful if I could actually get them to discharge in order here (Not shown: This design is supposed to deorbit the lower stage while the upper stage can use smaller ion boosters to maneuver around.) since I\'m basically stuck with a dead smaller upper battery.

A well designed silencer without any wipes (Or bafflestrike) should not induce velocity drop. Once the bullet has left the muzzle and the zone of gas interference (Ex: 'Muzzleblast') it does not gain any more velocity. A silencer\'s chamber sits in that forward area and functionally contains the muzzleblast (And in this case: 'The acoustic report') of the muzzle blast within itself*. *Not necessarily entirely. There is still pressure differential between the interior of the silencer and the environment, you will just get a greatly reduced difference -> Less loud report. There are other tricks where the flow of gas can be used to induce resonance and work in the manner of 'noise cancellation' but gunshots are typically broad spectrum compared to cancelling out specific frequencies. Regardless, primary mechanism is through reducing the muzzleblast. Silencers DO NOT rob you of projectile velocity in practice unless there is actual physical interaction between the components of the silencer (Ex: 'Silencer with wipes'). As for a conic compressor attachment: Don\'t bother, as previously started before the nozzles on real life rocket engines are designed for the maximum efficiency obtainable at the time they\'re made. (Read: 'Oh whoops we found that we goofed on the FEA model, so the next production model will have slightly higher output.') You\'d only obtain a theoretical possible gas velocity increase with a massive drop in your efficiency but you\'re not going to get anything from this. Not to mention you\'re running into the problem of specific impulse. I mean you could strap on turbines on the bottom of your rocket and have lower fuel consumption but with a heavier engine you\'re not going to go any further.

Only thing that matters for me next to a keyboard and stylus. This would also imply I have remote desktop support.

So you\'re willing to risk a multi-hundred to (one to-a-few) thousand piece of hardware for a dollar or two? Uh...

I\'d test if those pantyhose (This is very desperate of you, a piece of A/C foam costs only a few dollars/pounds/euros) for airflow restriction. Most people don\'t run server fans like I do. Ergo you could end up with a computer with very, very little airflow.

Mainstream water cooling is highly overrated, given how people do not comprehend the concept of sealing and later start flailing and panicing when a leak develops. Until you hook up car radiators and have a prechill loop that chills a peltier, you really don\'t need water cooling. By the time you need that, you\'ll probably be looking at evaporation/phase change setups with multiple cascades.

Mineral oil cooling is weak, do it the Cray way: http://solutions.3m.com/wps/portal/3M/en_US/ElectronicsChemicals/Home/Products/ElectronicLiquids/?WT.mc_id=Electronics_Redirect&WT.tsrc=Redirect Immersion into Fluroinert, now that\'ll protect you from corrosive ocean air *and* it won\'t oxidize. It also costs an arm and a leg in comparison.