toric5

simply because they are not modeled well, in atmosphere, the laser would diminish extremely rapidly with range. in space, it is not as bad, but the ranges are also mutch greater. (not to mention they are power and radiator hogs, as even the most efficent lasers today are only 70% effecinet, and the candiates for laser weapontry are about 30%.) to quote the children of a dead earth blog: there would be no way to make the weapons generate stock heat? (and shut down when the parts core temp gets to hot?) hence near future. if you have time and/or an interest in realistic space combat, take a look at atomic rockets and COADEs blog. hard sci-fi. how bout this? popellant tanks, truss, RCS thruster, and a cabasa howitzer. of course, you could replace the howizer with a nuke or frag warhead. also, you may have a pointy nose in front to act as sloped armor against point defense. however, no fins, unless its an orbit to surface missile, then you may have glide fins, but, of course, at that point, your just making a rod-from-god. sorry for the long post, and its probably to mutch to ask, but at this point im just trying to share what is kinda a special interest of mine.

thats star wars weapons, im looking for more of a near future pack. no 'laser' pistols and blasters, moreso rail/coilguns, missiles, and actual real lasers (speed of light, focused with mirrors, tiny ball turret with laser generator tucked safely inside of the ship type) wouldn't really fit in with the future weapons pack. (the weapons other than missiles would NEED radiators, unless you want them to be oneshot.)

@SpannerMonkey(smce) Would you consider making a weapon pack for 'near future' orbital and land based weapons? (space operational missiles, railguns and coilguns, realistic lasers, etc? I want to bring COADE and the expanse weaponry into KSP...

does it try to access any of these modules? //highly optional. removes most of mechjebs functionallity, making it a simpler, and IMO a mutch less 'cheaty' program. @PART[*]:HAS[@MODULE[MechJebCore]]NEEDS:[MechJeb2]:FINAL { @MODULE[MechJebCore] { %blacklist = MechJebModuleDockingGuidance MechJebModuleRendezvousGuidance MechJebModuleRendezvousAutopilotWindow MechJebModuleManeuverPlanner MechJebModuleAscentPathEditor MechJebModuleAscentGuidance MechJebModuleWarpHelper } } (as you can see, the blacklist only applies to parts, if that changes anything.

noticed the throttle was going down as it was landing. is that because of atmospheric drag? in a vacuum, at least, do you not want full throttle, to minimize gravity losses?

i would be happy to!

seems to be mechjeb causing it... uninstalled it, and it only, and it works flawlessly. i have most module blacklisted, if that would make a difference. ill get on the error log. here you go. it seems to set it to an arbitrary rotation whitch may or may not be 0 when you go into warp. the rotation it sets it at changes on scene changes, i think. https://www.dropbox.com/s/mcdtsmldqfgqbnx/KSP.zip?dl=0

is there a way to change the repaired resource from spares to materialkits?

use the CTT if you can. lots of nodes to spread stuff out in!

possibly just use SAS to point to the target. (if the probe core can handle it.) in fact, giving KAC the ability to control sas and throttle would work well, as an example of how simple it could be.

just as a request somewhat related to this, would you consider making a barebones manuver node executor? all the mods that include that also include a full suite of other autopilot features (looking at you, mechjeb.) i just want a really barebones one.

you get KER for free if you have a lvl 3 tracking station. (or have an engineer on board) possibly something similar for you mod, require the part, a lvl 3 building (tracking station, mission controll?) or a certain level of pilot?

if it its, may want to make it a physicsless radial core, so you don't have to worry about making a separate one for each form factor. will this be able to handle suicide burns with a large horizontal component?

well, got the atmospherecurve working, and the docking ports working. thanks a ton for all your help!

so that will just try to do this to most parts, and fail (gracefully?) on most parts? also, the aqquire roll part was meant to have a value of 2, must have borked something. trying this one now.

on a second note, this time something that is actually documented, i have this peice of code: @PART[*]:HAS[@Module[ModuleDockingNode]:HAS[~snapRotation[True]]]:FINAL { @MODULE[ModuleDockingNode] { %captureMinRollDot = .999 %snapRotation = True %snapOffset = 45 %acquireForce = 2 %acquireTorque = 2 %acquireTorqueRoll = } } this *should* add a 45 degree snap to any docking port that has no angle snap, correct? (MM wiki says ~ is the NOT version of #.) however, it is apparent that it is not being applied to any docking ports, both by looking at the MM cache and game play testing. so i would multiply the second term for ISP, as the first term is the atmospheric pressure. ok. do you know if MM will shoot errors if the terms do not exist? (if the curve on one of the targeted configs does not have tangents?) (other than the rediculosly complicated way you hinted at?) if so, i can just assume that most engines dont, and manually patch engines that do have tangents. and also, can i multiply every key by the same constant in a genral form, so it works regardless of the number of keys? if it helps, im trying to complete the reqested improvements to this pull request.

i see. what would i do to keep the shape of the curve the same? as i said, i want to either make it so that at any given altitude, the engine has 15 pecent (or any other value.) more ISP. failing that, i want it so that it has 15% more vac ISP, not caring too mutch about what it does to the curve, as long as nothing too strange happens to it. (read: as long as it doesn't have a dip anywhere.)

@PART[*]:HAS[@Module[ModuleDockingNode]:HAS[~snapRotation[True]]]:FINAL this shoud, in theory, target all docking ports that DONT have snaprotation, correct? (the mm wiki says ~ is the oppisite of #, similar to @ and !)

ahh, i thought you meant more than 2 key entries. no, none of them have that.

@blowfish atmosphereCurve { key = 0 800 key = 1 185 key = 2 0.001 } i would like to make it so i multiply by x, the curve will be atmosphereCurve { key = 0 800x key = 1 185x key = 2 0.001x }

http://www.kerbaltek.com/ribbons has sutch nice looking ship icons, is there any mod that adds more icons for the map view?

every engine ive looked at has 3 entries for the atmospherecurve. and for multiplying the curve, if i multiply everything by 1.1, than any point in the curve will be 1.1 higher than it was perviously, right? or will the slope change? (with 3 keys)

recently stopped working at all for me. have tried reinstalling, to no avail. timewarp just stops a ship in its tracks, as in stock. found a few things in the .log: [EXC 13:37:36.187] NullReferenceException: Object reference not set to an instance of an object (wrapper dynamic-method) PersistentRotation.Reflection. (object) <0x0000b> [EXC 13:37:36.374] NullReferenceException: Object reference not set to an instance of an object (wrapper dynamic-method) PersistentRotation.Reflection. (object) <0x0000b> PersistentRotation.MechJebWrapper.Active (Vessel) <0x00187> PersistentRotation.Main.GetStabilityMode (Vessel) <0x000a6> PersistentRotation.Main.FixedUpdate () <0x0064d> the last one is repeated over and over. (i have mechjeb with most autopilots disabled, if that helps at all.)

i would like to edit every key, regardless of the numbers. this is for engines ISP curves, whitch usually have 3 or 4 keys.

is it possible to do this?