igor_perusco

So we have a new SAS now that people seem pleased about. But i was wondering if the old code for the SAS is still floating around somewhere and usable. Would it be possible to have it back? This isn't a request for a dedicated mod as much as it is a question of, is it possible at all?

"Fairings also received a bit of attention, and the dreaded “cannot activate while stowed” issue for interstage fairings has been fixed, though it requires rebuilding your interstages to take effect" So i may be overreacting or misreading this, if this is so, i apologise. But this means that the unintended *bug* part of the can't-activate-while-stowed "feature" has been fixed but the overall mechanic is here to stay. So no hotstaging in 1.1? Nice, cool, absolutely fantastic, gg squad 10/10

oh if you got your mods from ckan, you now probably have a more urgent problem there's ads on the forum? that's news to me

If i may make a suggestion for a future version, this is a shower thought i just had. There's code in RCS build aid right now to account for gimbal range and display resulting torque with gimbal actuation. Would it be possible to visualize the gimbal range of a rocket as a visible cone extending up into the rocket. If the center of mass is contained within this cone then the rocket would have sufficient control authority to overcome offcenter thrust, if it is not then the rocket would spin out of control even with maximum gimbal actuation. Optionally an arrow would show the direction that the center of mass should be offset in order to balance the rocket If allowed the cone could be colored green, yellow or red depending on how close the CoM would get to its edges. In the case of multiple engines or engine clusters, the half angle of the resultant cone would be a weighted average of the half angles of all the cones, where the weight is the thrust of the engine. The tip of the resultant cone would lie at the center of thrust and the cone would be aligned with the resultant axis of thrust.

If anybody still has performance troubles with KSPRC and the fixes posted above don't work for them. Try cutting out EVE and the EVE configs and see if that helps, it made a 70fps difference on my end. The 0.24 of EVE can still function as an alternative for now. Thanks Proot and everybody else for an awesome mod

Newnard, it doesn't glitch out, throw errors or crash the game, but some of the parts are unreliable, especially when activating on ships not in focus (ex: jettisoned boosters) I don't know if this is a problem having to do with 1.0.5 particularly, because it did that in a previous version too (at least for me)

having pointed a small engine at a ridiculously large heatshield (with a lot of ablator), i can get it to hold for a few seconds, so the parts don't blow up *instantly* (it's not a glitch) rather they heat up and explode as before, it's just the heating that's very high in other news, PSA: the new fuselage is HOLLOW -> http://imgur.com/a/yyu3q engines can fire through it, use this to avoid blowing stuff up, and it doubles as a nice interstage

unfortunately russians don't like to put cameras *inside* interstages (like spacex does) probably for reasons which will become apparent when watching this: this beautiful video shows you everything you'll ever need to know about russian staging boosters separation happens around 2:25 second stage separation happens around 3:15

this is a huge problem, even the sepratrons toast an orange tank note that when the shuttle SRBs separate, the retrorockets scorch large and very visible dark patches into the external tank (which the shuttle is using at that time, and still functions) since lazarus mentioned the proton, that one (alongside several other russian rockets) hotfire their second (and third) stages and in neither does the spent stage below deatomize instantly this needs a serious nerf, or at least make a few parts immune to it did anyone verify if engines can wreck an asteroid by the way?

a̶l̶o̶n̶g̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶1̶.̶0̶ ̶"̶e̶n̶g̶i̶n̶e̶ ̶c̶a̶n̶n̶o̶t̶ ̶b̶e̶ ̶a̶c̶t̶i̶v̶a̶t̶e̶d̶ ̶w̶h̶i̶l̶e̶ ̶s̶t̶o̶w̶e̶d̶"̶ ̶t̶h̶a̶t̶ ̶s̶e̶r̶v̶e̶d̶ ̶n̶o̶ ̶r̶e̶a̶l̶ ̶p̶u̶r̶p̶o̶s̶e̶ this pretty much killed hotstaging squad hates russian rockets i suppose.. edit: apparently i'm an idiot and that feature was removed still the engine heat could use a nerf, an lv-30 can chew through several layers of heatshield instantly

Thank you for the lightning fast response! The density curve not working is indeed due to my own stupidity. The addition of that flag would be awesome, the effect i have for ignition is way over the top and looks weird when used while the throttle is down. Allright so the stock sparks are off limits. How should i go about copying that with smokescreen? The "Stretch" render mode doesn't work it seems (particles are generated and appear in the counter in the UI, but are invisible), and i have no clue what shader, if any, i could use to make particles "trail" like that

It works, does exactly what i wanted it to do. Thanks Sarbian! I do have some feedback and a few questions. Is it possible to set power and density curves for single emissions? I would like an ignition flash to happen only if the engine is started with open throttle. Right now it looks like none of the single emission effects react to either power setting or density. Also, what exactly is the nature of the stock "fx_exhaustSparks_flameout"? Is it treated as a particle emitter? Can i use it with smokescreen and alter its behaviour? If yes how would i go about referencing this effect? I can't physically locate it in the squad folder, and i don't know how to call it if it's within the sharedassets files. edit: Is it possible to move an entire effect node and/or rescale it? Not the emitters themselves, i know it's possible to move those individually. I would like to move and resize an existing (pre made) effect, so i can copy and paste it to several engines. The fxoffset thing doesn't appear to work on ModuleEnginesFX for custom effects made with smokescreen Thanks!

I have a formal request to make to a few people, i hope this is the right place to post this. I am currently using a combination of textures from several packs at once, the KSPRC, Scart91's class suits aswell as his large texture pack, Sylith's extended kerbal heads posted by Shaw, Hotaru's simple female kerbal texture pack and a few of my own textures based on or derived from the works of the above mentioned. Most of these have been modified in significant ways, and a few of them have features transplanted from one texture to another, so pointing people towards the individual downloads is not an option. I have people asking me (on twitch) for the texture pack i'm using, and the best i've been able to provide are precise instructions on how to modify these in the same way as i have. I would very much like to provide people with a one click option of downloading and playing with the stuff they see on my screen, in the form of a dropbox link where they can get the exact same pack that i'm using (no ad fly nonsense or any shady business). I would provide links for the individual packs, aswell as credit each contributing person for the textures used. This is an imgur album of how the pack looks like: http://imgur.com/a/M69us As follows is a list of all the textures used in the pack: The main feature of the pack is that all the kerbal textures are consistent with each other, nothing is mismatched or feels out of place. The textures are also compressed and downscaled for memory usage considerations and loading speed. I will remove any of the features if any of the authors desire so before putting up a download link (if and only if i am permitted to do so in the first place) Thank you in advance

Thank you i'll definitely give this a try in a few days when my pc becomes usable again (HDD failure)

I don't know if it's the 1.0 quick fix which broke something, or i'm doing something wrong (most likely) but i cannot get any particles working for the engage/disengage effects @PART[liquidEngine]{ !fx_exhaustFlame_blue = DELETE !fx_smokeTrail_light = DELETE !fx_exhaustLight_blue = DELETE !fx_exhaustSparks_flameout = DELETE !sound_vent_medium = DELETE !sound_rocket_hard = DELETE !sound_vent_soft = DELETE !sound_explosion_low = DELETE @MODULE[ModuleEngines] { @name = ModuleEnginesFX %powerEffectName = exhaustfx } EFFECTS { exhaustfx { // NOTE: I removed the 10 or so emmiter spam that was under here to shorten the post // and replaced it with a generic one, as what was there was not really relevant (i hope) MODEL_MULTI_PARTICLE_PERSIST { name = plumeExtBoundary modelName = MP_Nazari/FX/flamejet transformName = thrustTransform } AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } engage { AUDIO { channel = Ship clip = sound_vent_medium volume = 1.0 pitch = 2.0 loop = false } MODEL_MULTI_PARTICLE_PERSIST { name = ignitionFlash modelName = MP_Nazari/FX/fusionflame2 transformName = thrustTransform singleEmitTimer = 1.0 // curves go here, yadda yadda, you know the rest } } disengage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } } However i mess around with the curves and the different variables, nothing i do affects the "ignitionFlash" emitter. It's stays on constantly at its default setting and responds to no variable i put in there, not even resing it works. What do i have to do to get a particle emitter to work under the engage/disengage effects? note: i've tried both MODEL_MULTI_PARTICLE and MODEL_MULTI_PARTICLE_PERSIST i apologize for the messy code, it looked much better in NP++

you're doing god's work teflon mike o7

@Shrike99, here you go // Adds FSFuelSwitch to all LFO tanks, except service module type tanks (monoprop detected), engine/tank combos or boosters or tanks which already have switchers @PART [*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!RESOURCE[MonoPropellant],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:FINAL { MODULE { varVol = #$../RESOURCE[LiquidFuel]/maxAmount$ @varVol += #$../RESOURCE[Oxidizer]/maxAmount$ varLF = #$../RESOURCE[LiquidFuel]/maxAmount$ varO = #$../RESOURCE[Oxidizer]/maxAmount$ varOnlyLF = #$varVol$ varOnlyO = #$varVol$ @varOnlyLF *= 0.9 @varOnlyO *= 1.1 varMassOnlyLF = #$../mass$ varMassOnlyO = #$../mass$ @varMassOnlyLF *= 0.9 @varMassOnlyO *= 1.1 varCryoH2 = #$varVol$ varCryoO = #$varVol$ @varCryoH2 *= 5 @varCryoO *= 0.5 varOnlyH2 = #$varVol$ @varOnlyH2 *= 11 varMassOnlyH2 = #$../mass$ @varMassOnlyH2 *= 1.1 varMassStructural = #$../mass$ @varMassStructural *= 0.8 name = FSfuelSwitch resourceNames = LiquidFuel,Oxidizer;LqdHydrogen,Oxidizer;LiquidFuel;Oxidizer;LqdHydrogen;MonoPropellant;Structural resourceAmounts = #$varLF$,$varO$;$varCryoH2$,$varCryoO$;$varOnlyLF$;$varOnlyO$;$varOnlyH2$;$varVol$;0 tankCost = 0;0;0;0;0;0;0 availableInFlight = false availableInEditor = true displayCurrentTankCost = true hasGUI = true showInfo = true basePartMass = 0 tankMass = #$../mass$;$../mass$;$varMassOnlyLF$;$varMassOnlyO$;$varMassOnlyH2$;$../mass$;$varMassStructural$ } !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} } // Adds FSFuelSwitch to all LF tanks aswell @PART [*]:HAS[@RESOURCE[LiquidFuel],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:FINAL { MODULE { varVol = #$../RESOURCE[LiquidFuel]/maxAmount$ varLF = #$varVol$ varO = #$varVol$ @varLF *= 0.45 @varO *= 0.55 varOnlyLF = #$varVol$ varOnlyO = #$varVol$ @varOnlyLF *= 0.9 @varOnlyO *= 1.1 varMassOnlyLF = #$../mass$ varMassOnlyO = #$../mass$ @varMassOnlyLF *= 0.9 @varMassOnlyO *= 1.1 varCryoH2 = #$varVol$ varCryoO = #$varVol$ @varCryoH2 *= 5 @varCryoO *= 0.5 varOnlyH2 = #$varVol$ @varOnlyH2 *= 11 varMassOnlyH2 = #$../mass$ @varMassOnlyH2 *= 1.1 varMassStructural = #$../mass$ @varMassStructural *= 0.8 name = FSfuelSwitch resourceNames = LiquidFuel;Oxidizer;LqdHydrogen;MonoPropellant;LiquidFuel,Oxidizer;LqdHydrogen,Oxidizer;Structural resourceAmounts = #$varOnlyLF$;$varOnlyO$;$varOnlyH2$;$varVol$;$varLF$,$varO$;$varCryoH2$,$varCryoO$;0 tankCost = 0;0;0;0;0;0;0 availableInFlight = false availableInEditor = true displayCurrentTankCost = true hasGUI = true showInfo = true basePartMass = 0 tankMass = #$../mass$;$../mass$;$varMassOnlyLF$;$varMassOnlyO$;$varMassOnlyH2$;$../mass$;$varMassStructural$ } !RESOURCE[LiquidFuel] {} } // And adds MP switch to the pods, don't use it in conjuction with tacls @PART [*]:HAS[@RESOURCE[MonoPropellant],@RESOURCE[ElectricCharge],@MODULE[ModuleCommand],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch]] { %varMP = #$RESOURCE[MonoPropellant]/maxAmount$ %varEC = #$RESOURCE[ElectricCharge]/maxAmount$ MODULE { name = FSfuelSwitch resourceNames = MonoPropellant,ElectricCharge;ElectricCharge resourceAmounts = #$../varMP$,$../varEC$;$../varEC$ tankCost = 0;0 availableInFlight = false availableInEditor = true displayCurrentTankCost = true hasGUI = true showInfo = true basePartMass = #$../mass$ tankMass = 0;0 } !RESOURCE[MonoPropellant] {} !RESOURCE[ElectricCharge] {} } This is my take on tank switching, balancing is mostly preserved as is in the original mod. The LF and O only tank setups have appropriate mass ratios, the LH2 only tank setup has a mass ratio assuming that LH2/O tanks have a 50:50 volume ratio NERVAs should work just fine, in both LF and LH2 configurations Attaching two identical tanks in a stack and filling one with LF and one with O will feed a LFO engine properly Attaching two identical tanks in a stack and filling one with LH2 and one with O will feed a cryo engine properly As a bonus i have structural tank setups (.8 the mass of the tank, is balanced stockalike, does not render wet wings op), MP setups aand.. A tank switcher for the manned pods to take out the monopropellant (warranty void if used with TACLS srsly, remove that bit if you have TACLS or any mod adding resources to the pods ) Back up your save and enjoy, feedback is welcome sorry for the slow response but NP++ decided to revert to an older version of the patch and i had to redo it

You want to be able to stack two identical tanks on top of eachother, fill each with only one type of fuel, and have them feed a LFO engine, right? The problem with the above is: Currently LFO engines use a 9:11 (unit AND volume) ratio of LF to O. Cryogenic engines in this pack use a 1:10 (ksp unit) or 1:1 (volume as supplied by the tanks in this mod) ratio of LH2 to O If balancing were to be done so that the LF and O tank setups would provide 9:11 ratio of fuel to eachother, you would not be able to build separate LH2 an O tankage to feed a cryo engine properly If balancing were to be done so that the LH2 and O tank setups would provite the 1:1 ratio of fuel to eachother (volumetrically), you would not be able to build separate LF and O tankage to feed a LFO engine properly note: i'm going about this with the assumption that you're keeping the *as is* balancing for LH2/O tanks in this mod (1:1 volume ratio between LH2 and O) Lose/lose situation :c A thing you, i or someone else could do with a handy MM patch is balance the only LF and only O tank setups on a 9:11 ratio to eachother, the LH2 only tanks would have to hold a lot more to allow for separate LH2 and O tanks feeding a cryo engine. example: the FL-T800 would have the setups 360/440 LFO ; 4000/400 LH2/O ; 720 LF ; 880 O ; 8800 LH2 (the large amount of LH2 on the LH2 only tank would help with both feeding a cryo engine AND a nerva in LH2 setup, win win, except realism oriented people would be upset) another setup: 360/440 LFO ; 4000/400 LH2/O ; 654.54 LF ; 800 O ; 8000 LH2 (this would bring down the volume on the LH2 tank a bit and bring it in line with the LH2/O tank setup, the problem with this way is you get very little volume in the LF tank too and realism oriented people would still be upset) Of course on both setups you'd want to give the LF and O tanks altered dry mass (.9 and 1.1 times the standard tank mass) to preserve balancing. The only way i see to go about this semi realistically would be to have the cryo engines use a more extreme (volumetric ratio) of LH2 to O2 (2:1, 3:1 or 4:1) but without altering tank dry mass that would make the cryo engines useless. EDIT: I'd like to add i prefer the as-is balancing if it's of any worth to anyone, i don't believe in realism in ksp. Legit looking awesomely modelled engines with a "Cryo!" sticker slapped on the side? YES; real life fuels setups, nah. There's RSS and real fuels and whatnot for that. Also i pretty much have a patch doing exactly what you want, problem is it's for the firespitter tank switcher, i'll post it here if it's ok and if you're intereted

disclaimer: i am not criticizing the mod or modder, i love the mod, just require clarification I noticed when using this mod's patch to switch contents on fuel tanks, the amount of liquid hydrogen between LH2/Ox and all LH2 tanks is not consistent. On a given fuel tank, when filled with LH2/Ox the oxidizer takes up exactly half of the tank's volume with regards to stock balance. Example: FL-T400 holds 400 units of LFO, in the LH2/Ox setup the oxidizer takes up exactly half of that, 200 units This leads to reason the remaining half of the volume is being occupied entirely by the LH2 (within reasonable limits). Example: FL-T400 holds 200 units of oxidizer and 2000 units of lqdhydrogen, stands to reason the 2000 units of lqdhydrogen take up the same space 200 units of oxidizer would. When filling the tank with purely LH2, the amount added barely accounts for any of the extra space Example: FL-T400 holding 2200 units of LH2, only 200 more than the LH2/Ox variant, 180 *stock* units or the equivalent of 1800 units of lqdhydrogen vanished into thin air. I noticed the same formula for calculating LH2 tankage applies to the Near Future mods too, so i assume this is intended and not a typo. Is there a reason for this balancing? Is it supposed to be like this to balance the engines in the Near Future Propulsion pack? (i'm asking because i haven't messed around with the engines much, just the tank models, they look amazing) Interesting to note: if the tanks *would* fill with LH2 to their maximum logical volume it would open up interesting design possibilities. The oxidizer and lqdhydrogen take up the same space and are used by engines in a 1:1 volume ratio, so two tanks could be stacked but one filled with only the heavy oxidizer and one with the lightweight hydrogen (hard to pull off with stock LFO tanks). Makes me think of how the space shuttle tank mass is distributed in real life, could help a lot with spaceplane balancing

I was taught that the two terms are separate with "Flow" being flow and flux being flow through surface area. Note: i am aware the standard mathematical definition is slightly different, i am talking about, strictly speaking, the physical phenomenon Then again i didn't learn my physics in english so i might be mixing up words (we call torque, momentum over here, yeah...) EDIT: panicked searching through the interwebs yielded several definitions to support this pulled from stack exchange, i won't even attempt quoting wikipedia

It's obviously frame dragging.. try entering a retrograde orbit, it should help with landing attempts On a more serious note, ghost (the ksptv streamer in question) had a 23km Pe and about 1000 Ap, it was not a case of rounding errors making the orbit jiggle ever so slightly He went in twice around, you could tell he was in the atmosphere (and supposedly braking) because: - You couldn't hear his voice from the deafening aero effects - The camera was shaking vigorously - The ship was on firee - A chute was deployed (yes, really) Still, his craft was accelerating (at periapsis) and apoapsis was increasing

disclaimer: i like squad and love 1.0, i do not mean this as a complaint but simply an observation, thank you (also my physics is a bit rusty) There appears to be some confusion about the thermal model and specifically the debug menu for it. Right clicking on a part brings up (among other things) something called "flux" - Radiative flux - Convective flux - Conductive flux It does not appear to behave much like flux, rather the numbers seem to indicate energy flow rate? Suggestion: Either- - Rename the three values to something more like "- energy flow rate" and attach proper measuring units to prevent confusion (if it's not really flux) - Keep flux in there but add "contact area" for each of those, because it's useless without those (if it IS flux) attaching a proper measuring unit helps too - Scrap it completely and make up a "kerbal" thermodynamics model to replace the real world one A "better" model will arise in the form of a mod, as was the case with FAR and NEAR, the realism oriented players will use that, might be useful to keep a whackier simpler model in the game, avoiding the need for real life physics. I'd love feedback on this, thank you

Looks like the patch adding the telemetry report thing is missing from the download in the OP but not from the last link Yemo posted (a few posts up)? Mod folder hierarchy has become a bit confusing in the last few dev releases EDIT: Wait has the patch which adds telemetry readings changed position after the last release?

YES I LOVE IT not cool... oh well i'll manage in other news the game appears to behave very strangely as far as memory goes.. see below no atm, no opengl, no pruned parts just ddsloader and texture replacer it shoots up to the memory limit pretty quickly on scene changes (which i do a lot of) and on tweakables (i know this particular problem is unavoidable at the moment) scene changes also appear to crash the game sometimes without an error log and way below the memory limit there's definitely something in there causing memory problems, if not in the recommended mod list maybe in the seti folder itself?

well i've just come back from the mun and now sent something to eve... you seriously SERIOUSLY need to nerf the barometer i dragged all 300 kilograms of a goo pod (and another 300kg of useless clutter on the other side to balance it) all the way to the mun to find out: 1) you can't recover the data with a kerbal, you need to return the pod (futile to attempt with DRE installed as anything not made out of heatshields will blow up with this last version) 2) transmitting it amounted to pretty much nothing 3) the barometer, which is weightless and takes up as much space as a cubic octagonal strut has 100% transmission efficiency, is reusable and short of a surface sample was the most lucrative experiment on the lander... oh yeah and you can grab it with kerbal if you have KAS and run around with it taking readings for buckets of fun and science not to mention you're not really getting much data from a barometer on an airless body in the first place i would suggest adjusting the science rates for the early career experiments so the non-reusable ones (goo and lab) yield transmission efficiencies high enough to surpass the weightless experiments and their recover rewards worth their weight (big problem there) right now there is no incentive to bringing along any of the heavy experiments on science trips, this early into career (when the heavy experiments are worth doing) you've got two moons with plenty of biomes to spam light experiments in, bringing the other experiments along only starts making sense when you run out of places to do science in on an unrelated note, if for whatever reason you want to nerf the tweakscale on the DMagic stuffs, please consider nerfing the science returns on them instead, else it's going to make building small probes a nightmare keep up the good work