AlmightyR

Ok, thanks!

SUGGESTION+QUESTION: Is there a way to define Fuel or Life-Support preset configs for the fuel tanks or pods, capsules, etc, using the configs? Basically like the... MODULE[ModuleEngineConfigs] { CONFIG { (...) } } ...nodes but for fuel, or in this case, LS resources. Something like... MODULE[Module[U][I]Fuel[/I][/U]Configs] { CONFIG { (LF resources for 12 hours) } CONFIG { (LF resources for 1 day) } CONFIG { (LF resources for 7 days) } (...) } I know TANK_DEFINITION exists, but it doesn't seem to be the right way to do it... EDIT: I know this kinda belongs to the RealFuels thread, but the change would be made on RO's configs, since RealFuels doesn't imply in the need for LifeSupport, which is the main reason for the question/suggestion; So I thought it appropriate to ask/suggest here first...

Chris...It's probably been suggested but since I didn't see it in the OP or the last few pages of this and the (now closed) Dev-thread, I'll go ahead and suggest it (again?): Can you make an option so that the automatic calculator, while configuring a certain chute, considers just the current stage's weight? (based on the presence of a decoupler on the same stage as the chute or the next decoupler going up the stages, and summing the weight of all parts between the "top" decoupler and the next one down the chain [the parachute in question being in between])? Right now it seems to be calculated through the whole craft. It isn't a major problem since you can make and (auto-)configure individual stages using the sub-assembly system, and them plugging them all together for the final craft; But still, I don't know about others, but I make A LOT of "one time wonders" (crafts completely and specifically design for one single mission), and I'm currently having to go back and forth a billion times between the parts tab, to check the dry weight of the parts, my trusty calculator, since math is a pain, and the AGM+Chute-Configurator, to manually adjust each chute. I'll also be suggesting a per-stage wet/dry weight calculation on MechJeb (for the stage info panel) and EngineerRedux, since they apparently don't currently have it and it would also be useful for this and other reasons... As usual, thanks for the mod! ----- Oh, and one last thing: Since you did release the update within a week, I guess I'll spare you from the salt mines when I dominate the world (SOONâ„¢)...You will be working as a construction assistant instead... http://media1.break.com/dnet/media/2012/8/31/9c5f0206-1a5c-4264-81cb-c6f6f0426392.jpg

Great news! Thanks! But now I'll have to think of another excuse to myself to start modding KSP tho...That desire for new projects even tho I'm already kinda overloaded from the final semester in college...

Specifically it was the mk1pod I took the code from, but all pods had the problem. Other parts like lander cabins kept the ElectricCharge resource nodes, so they were fine tho.

*Mind Blownâ„¢* - I didn't know that! Is this some kind of average of the volume of the battery needed to store that charge? Or is it actual volume of electric-charge-carries (such as electrons)? Do you have a link or a google search-term I can use to learn more about this? [EDIT:] BTW, just to be clear, the file I posted that code from was RealismOverhaul\RO_Squad_Command.cfg

[EDIT] Code from was RealismOverhaul\RO_Squad_Command.cfg !RESOURCE[ElectricCharge] { } (...) MODULE { name = ModuleFuelTanks basemass = -1 type = ServiceModule volume = 120 TANK { name = Oxygen amount = 0 maxAmount = 1 } TANK { name = Food amount = 0 maxAmount = 1 } TANK { name = Water amount = 0 maxAmount = 1 } TANK { name = CarbonDioxide amount = 0 maxAmount = 1 } TANK { name = Waste amount = 0 maxAmount = 1 } TANK { name = WasteWater amount = 0 maxAmount = 1 } } The one that DOESN'T have any ElectricCharge between the list of "fuels" available to be added? And even if there was, how exactly does ElectricCharge occupy fuel "volume"? I think that either having the batteries installed or not makes a whole lot more sense...Just sayin~

The pods don't have ANY internal ElectricCharge storage now? Not even emergency batteries? Something seems wrong here...Just sayin~

Oh well...I guess I'll create some of my own models and revive the mod, even if it's just through the idea... I was thinking about starting to make my own mods for KSP, and I guess this would be a good start... No promises tho...

I want to start keeping track of the things I learn from KSP gameplay, or that I end up researching to use in KSP gameplay. I thought about where I could host this, and, although this thread doesn't really have any defined main theme or objective, after just reading through the forum rules, I don't see anything prohibiting it's hosting here. Also, hosting here allows other people to discuss, disprove, confirm, review or learn the info. So I thought: "Well, why not?" So if you just clicked into this thread out of curiosity, feel free to read through my little knowledge database! And any feedback or discussion is welcome, as long as it's constructive! =========================MATH========================= Formula that can be pasted on Google to calculate the pressure at a given altitude in KSP. ATM -> Atmospheric Pressure at sea-level, compared to Earth/Kerbin. Obviously 1 for Kerbin/Earth. ALTITUDE -> Altitude relative to sea-level to calculate pressure from. SCALE -> Atmospheric scale of the planet's atmosphere. It's 5000 for Kerbin; 8500 for Earth/RealSolarSystem. Formula: ATM * e ^ ( -ALTITUDE / SCALE ) [*]Formula that can be pasted on Google to calculate the altitude of a given pressure in KSP. PRESSURE -> Pressure to calculate altitude from. ATM -> Atmospheric Pressure at sea-level, compared to Earth/Kerbin. Obviously 1 for Kerbin/Earth. SCALE -> Atmospheric scale of the planet's atmosphere. It's 5000 for Kerbin; 8500 for Earth/RealSolarSystem. Formula: ln( PRESSURE / ATM ) * -SCALE =========================Kerbin's Atmospheric Pressure Table========================= 70000m (100% | 1/1) = 0 ATM (space's vacuum) 52500m (75%) = 0.00002753644 ATM 35000m (50% | 1/2) = 0.00091188196 ATM 17500m (25% | 1/4) = 0.03019738342 ATM 14000m (20% | 1/5) = 0.06081006262 ATM 10500m (15%) = 0.12245642825 ATM 8750m (1/8) = 0.17377394345 ATM 7500m = 0.22313016014 ATM (Real-life drogue-chute deployment [~]) 7315.2m = 0.22313016014 ATM (Real-life drogue-chute deployment) 7000m (10% | 1/10) = 0.24659696394 ATM 5250m (7.5%) = 0.34993774911 ATM 4500m (1/20) = 0.40656965974 ATM 4375m (1/16) = 0.41686201967 ATM 3500m (5%) = 0.49658530379 ATM 3050m = 0.54335086907 ATM (Real-life main-chute deployment [~]) 3048m = 0.54356825289 ATM (Real-life main-chute deployment) 3000m = 0.54881163609 ATM (Real-life main-chute deployment [~]) LOWER ALTITUDES COMING SOONâ„¢ =========================Earth's (RSS) Atmospheric Pressure Table========================= COMING SOONâ„¢ =========================Apollo's (11) Parachute Deployment Profile========================= Values converted to metric: 24000 ft = 7315.2 m 10000 ft = 3048m

Can someone do an archive upload (of their local copy) of this for curse? Like how someone did for RLA?

Oh! I will gladly put up with such little inconvenience if such a big update is coming within the next few days! If you fail to bring this update within a week tho, I'll be making you work on the salt mines when I dominate the world (SOONâ„¢)! *[still] shamelessly puts pressure on Chris to release the fix update sooner.* (JK)

@StupidChris - So...I know this is annoying but...When is the minPressure fix coming out? I know you've already fixed it (since it was I who opened the issue on GitHub, lol), but where is the new (hotfix) version or download? It's kind of annoying that <(my precious!) pressure-deployment presets are not working (in the preset sense)... *Shamelessly puts pressure on Chris to release the fix sooner*

First of all, a complaint is made for someone. What I did was make a point. And it wan't about this specific mod, it was about the misinformation situation in general. I didn't quote you; I quoted one of your posts. Specifically, one that wasn't necessary since the post right before it was also yours, and one that didn't add anything to solve any mod's issues (no news nor logs about your problem), and just fuels the disinformation that is becoming a problem (as you can see by the fact your post triggered two people spreading even more nonconstructive and misinformative posts ["more nonconstructive and misinformative posts" here doesn't regard your posts, but the forum situation in general]). And I didn't change the subject from the nonconstructiveness; I used your self-quoting as an example of the noncosntructiveness. And I didn't belittle you; You immediately jumped to victim-mode and seemed (and still seem) to need a hug, so I offered you one. If you don't want my hugs you can stop playing victim and just say "Sorry, but I don't want no hugs" . I'll feel a little depressed if you don't let me hug you tho ; It was such a nice chance to hug and kiss you in public... As for your problem. I'm pretty sure "EditorLogic" regards the KSP editor in general, not the changes to it made by EE (Which aren't very extensive, btw). If you look at other mods' threads, you will see most of the logs being posted are throwing "EditorLogic" problems, but proportionally speaking, "none" of those problems has anything to do with EE (or whatever mod the log is posted on) or changes introduced by it (/them). What's causing the issue? I don't know! But the fact is that you can use the mod just fine in a new game, so the problem lies in the transition between the format the data was saved with on the old x32-only format and the new x32/x64 (interchangeable) format. Squad warned us all that the update would be a big one and that a lot of things with the transition from the old to the new version of KSP were probably going to be messy, so starting a new game was recommended. And that's exactly what's happening: There is noting exceptionally wrong with KSP or the mods that inherently breaks the current system. It's when the old system is involved that things start going wrong. (Small note here: I'm playing KSP x64, and, aside from EE and MM that I already had installed, I've installed a few more mods, like FAR, JointReinforcement, MechJeb, TimeControl, RealChute, HyperEdit, RealFuels, RSS, and a few more minor ones. I installed them one by one and started a new game for each new one. I've been playing for the past 3 hours on this same config without a single crash or even a hiccup for that matter, and so I dare say: My KSP has never run so stable with so many mods!) Don't worry! The devs (both Squad and mod devs) will figure and sort things out! But they need time to do that! And all this fuzz on the forums, with people posting error-logs in the wrong mod's thread (if there is any right thread in the first place, since most logs I've seen so far are KSP errors related to the transition in general), or worse still, simply saying "your mod is broken" or "my game crashes because of your mod", is not going to help! Like I said...Have patience. Test your most essential mods, installing one at a time, and play a new campaing of "KSP-stockish" for a little while, like one or two weeks. If you find any bugs on that time, report them. When you are feeling lucky, update the mods and try your old saves again; And if they don't work, actually google up some parts of the stack-trace and try to figure out what is the actual origin of the problem before going to the forums; If you can't figure it out, it's fine, at least you've tried. But when the last pages of pretty much all mods' threads are filled with logs that have noting that actually points to the mod being the problem, that in itself becomes a problem. Best regards.

Quoting yourself for no reason, and not using the edit button when it's literally just a few pixels from where you were typing a new message, is silly, just FYI. BTW, I think your log indicates a problem with KW, not EE. Oh, and one last thing: You've completely missed the point. Congratulations. Do you need candy? A hug? Both? Here, have some! *Gives flex some candy and the proceeds to bearhugâ„¢ him* Can we go back to the EE subject now? Preferably constructively? Thanks in advance!

This is what I read from these quotes: "Hey mod-developer! I'm having crashes! Now go ahead and try to guess what's wrong with your mod, since, never mind providing the error-logs, I don't provide any useful info whatsoever! Actually, on that note, you should go ahead and try to guess if my crash is even related to your mod! Since I don't provide any info on if or not I have other mods installed either! Good luck fixing things! In case there is something other than my lack of constructiveness to be fixed in the first place, that is!" As for the crashes, I'm playing 0.24.2 64-bit on a new career with just MM and EE, and so far the total amount of crashes I've had is ZERO. From what I'm seeing happen in pretty much all mods' threads' last pages, there are a lot of people spreading misinformation out of their own misunderstandings of which mods are causing which problems. My guess is that some people want to install the whole pack of mods they had prior to 0.24 and expect their still-outdated mods to work fine with a game that is still not done the hot-fixes and the other after-effects of a major update, and when the inevitable errors and crashes happen, they blame whichever mod comes to mind first. Dear other mod-users. If you can't play KSP stockish for a week or two, or if you don't have the patience to actually install and test mods individually after the core game's updates, please at least have the decency of not spreading your own confusion about which mods are incompatible! You are not helping! And if you are not going to help, at the very least you shouldn't make things worse! ----- @MachXXV - EE is NOT incompatible with 0.24.2; Or at least not for some users (me for one instance). I imagine you, as well as the other modders are going through a lot of stress due to the update, and I sincerely hope that you do not let yourself be affected by all the confusion generated by people who don't have the slightest clue about what they are talking, and who are reporting crashes and bugs on the threads of mods completely unrelated to the errors. I love your mod and I hope you keep up the excellent work! - AlmightyR.

The same menu that is being useless (at least for pressure-deployment) since the minPressure parameter is not being saved, and you need to configure it on-pad for every single chute at every single launch? Well, at least it's just ONE config parameter that needs to be re-done...Not the whole thing...I give you that.

Pressure-deployment's minPressure value doesn't seem to be persisting here. If I set it up on the garage's AG window, when I launch the vessel and check the parachute's "info", the value "goes" back to 0.01. Consider the aforementioned "goes" as an "are", because even if I don't open the "info" panel, the parachutes behave and deploy as if set to 0.01 pressure. Anyone else having this problem? I want to confirm if this is just a local problem or if it's something broken by v0.24. Note: I was and am using KSP's 64-bit version 0.24".0" (Didn't update to 0.24.1 yet).

How to set and adjust the chutes to pressure-mode on the configs? I modified the "minPressure" property to "0.13533528" but when I go to the ingame editor it's still "0.01". Here is my current ModuleManager's modifier: @PART[*]:HAS[@MODULE[ModuleParachute]]:Final { @maximum_drag = 0 @MODULE[ModuleParachute] { @stowedDrag = 0 @minAirPressureToOpen = 0.13533528 } } @PART[*]:HAS[@MODULE[RealChuteModule]]:Final { @maximum_drag = 0 @MODULE[RealChuteModule] { !minDeployment @mustGoDown = true @minIsPressure = true @minPressure = 0.13533528 @preDeploymentSpeed = 0.75 @deploymentSpeed = 1 } } @PART[*]:HAS[@MODULE[RealChuteModule]:HAS[#deploymentAlt[700]]]:Final { @MODULE[RealChuteModule] { @minPressure = 0.13533528 @deploymentAlt = 500 @preDeploymentSpeed = 0.75 @deploymentSpeed = 1 } } @PART[*]:HAS[@MODULE[RealChuteModule]:HAS[#deploymentAlt[2500]]]:Final { @MODULE[RealChuteModule] { @mustGoDown = false @minPressure = 0.04978706 @preDeploymentSpeed = 0.75 @deploymentSpeed = 1 } } @PART[*]:HAS[@MODULE[RealChuteModule]:HAS[#deploymentAlt[100]]]:Final { @MODULE[RealChuteModule] { !minPressure @mustGoDown = false @minIsPressure = false %minDeployment = 100 @deploymentAlt = 50 @preDeploymentSpeed = 0.5 @deploymentSpeed = 1 } } @PART[*]:HAS[@MODULE[RealChuteModule]:HAS[#secDeploymentAlt[2500]]]:Final { @MODULE[RealChuteModule] { !minDeployment @mustGoDown = false @secMinIsPressure = true @secMinPressure = 0.13533528 @secPreDeploymentSpeed = 0.75 @secDeploymentSpeed = 1 } }

Please no...As far as I'm observing, this is not a failure with MechJeb, but of craft design; And thus the problem shouldn't be patched by the mod, but learned and corrected by the designers.

Actually, I have found out, which almost complete certainty, that the problem lies with unbalanced reaction wheels coupled with RCS, balanced or unbalanced, and not with RCS per-see. The problem is that both are used simultaneously and independently, and if one or both are unbalanced... One example I tested unintentionally, was having a probe on top of a long 1.25m fuel tank, balanced RCS (also use RCS-BA here) distributed through 4x 4-symmetry rings, but "no reaction wheels", which actually means "unbalanced reaction wheels" because the probe's core has one. The end result was that, although the RCS pretty much dictated the turning and rolling operations, the difference to the same setup with a reaction wheel sitting just on top of the engine, below the fuel tank, was still quite noticeable. The first setup gets some Smart A.S.S. confusion, the second gets none. Hope it helps!

How do I access modules that are not named? For example, RemoteTech's "TRANSMITTER" sub-modules: MODULE { name = ModuleRTAntenna IsRTActive = true Mode0OmniRange = 0 Mode1OmniRange = 500000 EnergyCost = 0.01 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } I'd like to change the PacketInterval, PacketSize and PacketResourceCost parameters...

@BigNose - Is there a way to add the ModuleNavLight to other mods' lights? None of the configs for the lights in this mod actually state a "lightName" and/or a "animationName", which I think are necessary for the lights since they are 3D-model-based. Does this NavLights work with a standard? And if yes, does it have hidden "lightName" and/or "animationName"-like parameters I can add to the configs of light-parts from other mods? So that the mod's script can be used to strobe non-native lights? [Edit] Oh, and one more thing... Does NavLights already support, or are there plans to support models with multiple lights? For example: A single 2-on-1 model for wingtips, that has a colored (green/red) strobe to the front and a white strobe to the back.

Oh, I was turning a simple thing into a seven-headed monster...Again... "((3.5316*(10^12)) * (21600 / (2*pi)) ^2) ^(1/3)" [EDIT] Thanks to the community's help, with special thanks to @Horn Brain, here are the formulas for both operations (for circular orbit), which you can paste on google (without the quotes) to use the hidden calculator, needing only to substitute the texts with the appropriate values, that you can get in the wiki: Altitude-To-Orbital Period: "2 * pi * sqrt( ( ( PLANET_RADIUS_METERS + ALTITUDE_METERS ) ^ 3 ) / GRAVITATIONAL_PARAMETER ) seconds to hours" Orbital Period-To-Altitude: "(((GRAVITATIONAL_PARAMETER * ( PERIOD_SECONDS /(2*pi))^2)^(1/3)) - PLANET_RADIUS_METERS) meters to kilometers"

Ok, I've managed to calculate the orbital period from altitude (first equation), which I tested using the data for a geosynchronous orbit (2868.75km), and I've understood most of what's going on with the math, but I still have one problem: How do I solve "a^3"? I'm trying "log((3.5316 * (10 ^ 12)) * ( 21600 / ( 2 * pi ) ) ^ 2) / log(3)" but it results in 41.1227105891 rather than the geosynchronous semi-major axis of 3468750 (600000 + 2868750, altitude of 2868.75km) "(3.5316 * (10 ^ 12))" being Kerbin's gravitational parameter and "21600" being 6 hours in seconds.