Starwaster

Edit: actually I dont think that's correct about angularDrag. It's not sideways drag, it's how much drag is applied when trying to rotate the craft or part. Aaaand oh oh. This isnt an edit.... I accidentally replied to myself and I see no option to delete this message as I would normally do. Sorry

nose cones aren't entirely useless. Because they have less drag (stock cones do) they help orient the craft and make it less prone to tumble. But it's not like that's a huge problem with stock aerodynamics so they're offering little utility and imposing substantial mass that eats into your delta-V. If you're really thrifty about your DV then nose cones are wasteful. something else of interest is that parts apparently reference 'drag type' with choices being default, conical and cylindrical. But I've never seen a difference from changing dragType and I dont know if I'm setting it wrong or if the drag model doesnt actually implement different drag types. (as in maybe someone added those but then stopped working on drag without actually doing anything with that variable)

Actually I've had good results putting six (6) of them clustered around the CoM. Those were radially mounted however. (stock reaction wheels using that attachment point adapter thing whose name I can't remember)

Just realized, long standing issue that always bothered me is still unfixed: Here is a config file for Module Manager that runs after all others have run and if it finds parts with crew capacity that are lacking life support, it adds it. (up to 10 Kerbals only at this time) Download will be updated, but I kind of screwed that up and uploaded a second file that apparently has to be reviewed, which isnt how I wanted to do it This file is now part of the official download. All parts with crew capacity up to 10 will have life support added. (because this is being done as a config file and because of limitations with how it works, an arbitrary number had to be chosen and ten separate configs created.)

I don't think they really fight each other, but where you put them might be an issue. Try disabling all but the one nearest the center and see if you still have the wobbling issue. Also, on that subject, maybe your design itself is just wobbly, or maybe you're using parts that are prone to wobble. (I've seen certain parts that when in combination with each other will start all kinds of oscillations, wobbles and gyrations until the station/craft explodes like Oberyn's head. Most likely that was a collision mesh problem; if two parts have intersecting colliders, bad things can happen)

Not hostility. It's just that there is nothing you have to do to DREC's config to survive a reentry with any of the stock planets with FAR. If you're having survivability problems then you should look to your landing process before looking at editing config files to make DREC 'compatible'. True story.

I'm branching this off and creating a new thread for support. Plugin and Source download links on first post: http://forum.kerbalspaceprogram.com/threads/82084

Change Log 1.25.0 Compiled for KSP 1.25.0 Added tags to parts Added bulkhead profiles to parts Rebranded parts 1.23.0 Updated O2 density & cost. (recent changes to how KSP calculated part cost was hideously inflating Ioncross resource part costs) Added RESOURCE_DEFINITION for Light (for the greenhouse part) Cost rebalancing on all parts Updated description with more accurate duration in Kerbal days. (assuming Kerbin time where 1 Kerbin day = 0.25 Earth days) Replaced panel transform. (this part had stopped working properly due to KSP updates) Rescaled to account for added MODEL nodes Added drag cubes to part Changed generators to Ioncross generators Updated default config file Disabled experimental thermals Changelog for older versions

This is a branching off of Yongedevil's Ioncross Crew Support Plugin which he previously reported he was unable to continue working on. With the loss of the original download on Spaceport, I'm branching it off for the purpose of maintaining it and fixing bugs in it. Current bugs fixed in this version are the CO2 scrubbers, which should now stay activated if you left them activated. They should no longer revert to a deactivated state. Future changes are planned to the CO2 scrubbers. A real CO2 scrubber completely eliminates CO2 buildup until it reaches saturation, at which point it ceases to function only then will the part begin to accumulate CO2. I haven't decided what will happen next. Ideally I'd like for there to be two CO2 scrubber types available. One requiring cartridge replacement and one that works via regenerating scrubbers. (regenerating scrubbers can be restored to functionality via electrical charge and are offline during the regeneration cycle) Latest DOWNLOAD LINK Alternate download link: https://github.com/Starwaster/Ioncross-Crew-Support/releases/latest Github Source & Issue Tracking If you find this mod helpful and want to throw some money away, feel free to click the donate button below! License: This work is branched off under Yongedevil's original license found below. Additionally, Yongedevil has granted permission for me to host the original mod. Licence Modified source code, compiled dll, and configuration files may be distributed provided they attribute the original work to me, yongedevil. However, I request you do not simply re-post the original mod as I prefer it control where it is hosted myself. Additional License Info: Anything added by Starwaster post ver 1.1 (toolbar integration, contracts, etc) is licensed under Creative Commons Attribution-ShareAlike 4.0 International License.

Stay on target!

Why are you being so argumentative and pedantic? Yes, it's the VAB and FAR is assuming sideways airflow when it modifies CoL.

Depends on what you mean by 'compatible with FAR' If by 'compatible with FAR' you really mean 'make it so I don't have to learn how to land/fly with FAR properly' then just edit the same value you referenced above (shockwave exponent) and lower it instead of increasing it. DREC has no inherent compatibility issues with FAR. Technically, in real life, you would be correct. In real life, the surface of the capsule would be getting a lot hotter than it does while the interior remains cool. There's no way with the current system to model something like that. The entire part is assumed to be at that temperature. I'm assuming those are the reasons for using shockwave temperature and not part temperature. (density also factors in as part of the equation presumably to see how much heat is conducted to the craft)

That sounds a bit strange. Most modeling programs allow you to arbitrarily set a line (or edge) to be soft or hard.

Does that work properly with multi-quoting?

Sounds like similar to a known bug that's been discussed on previous pages. IIRC it had something to do with center of mass...? Where if center of thrust was in front of center of mass it was resulting in negative value in certain calculation causing the engine to gimbal to extremes.

under the person's message you want to quote is dialogue balloon thing with a + next to it.. far right, underneath. click that for everyone you want to quote. After you do the last person that way then click 'Reply With Quote'

reduce throttle a little before touchdown. It will flare. It has to or it will touch down short of the runway.

@PART[*]:HAS[@RESOURCE[ElectricCharge]:HAS[#maxAmount[0]]] { @RESOURCE[ElectricCharge] { maxAmount = 0.01 } } I think that should work but my PC has died again for like the 4th or 5th time so it's untested. And entirely from memory. And typed on an iPad. caveat emptor

I think it just used the Squad model.

I dont think % works as a condition. Only for modifying/adding.

Strut them and use caps lock for fine control. I used them for awhile bu to be honest, the things I wanted them for took so much of not-fun filled time that I decided the time was better spent learning to dock better. (large scale orbital construction is all I ever wanted them for)

there are already two such arms in existence. How many do we need?

You should direct that to a moderator. But since you did ask, I say no because lack of explicit permission from Semni does not constitute any sort of implicit permission. THSS is not public domain and is copyrightable by Semni whether he ever claims it or not. Distributing without his permission is a challenge to his copyright. That means liability for Squad which is why they insist on explicit licensing information that says what people can or can't do. Edit: Interesting story. Back in the day when the Internet was still in the early stages of going mainstream, all kinds of copyright issues were coming to light that we take for granted now. FASA, the game company found its material being used online for fan sites, MUDs and MOOs, etc. especially for Shadowrun. It was good for them, their gamers were happy but there was the issue of copyright. They were reluctant to grant permission en masse because of fear of unforeseen consequences. But they didnt want to issue Cease and Desist orders to their fans either. What they did officially was post a copyright notice for website owners to post that contained at the end 'used without permission'. Their trademarks and copyrights were considered protected and they generally agreed not to go after people as long as they used that notice while at the same time withholding explicit permission and everyone was happy. not that that is intended to have any bearing on the subject at hand nor to suggest a course of action (you should still talk to a moderator) I just wanted to share a story from the past.

Count your braces and make sure that you have one } for every { I can tell you right now you're missing one at the very end of that file. Since I apparently can't copy the contents I can't easily give it an in depth dissection. Also, I have a few concerns with some 'fillable=false' that I'm seeing. That's in no way related to your current trouble and I'm not familiar with the mod that uses those resources (helium 3 was one I think?) so maybe it's supposed to be like that. Basically if fillable=false then it cannot be filled in the VAB or on the launch pad from the feeder lines. If that's how it's supposed to be then no problems.

innerRadiusMult???? And of 6971000. Do you see the 'mult' at the end of that? It's short for multiplier. You could use that instead of innerRadius (which is what I said, not innerRadiusMult) but you just increased the inner radius of the atmospheric shell by 6.791 million. No wonder you have no atmo visible. that's not any sort of physical inner shell, it just controls where to put the beginning of the texture gradient. to reduce the white you want to move where it originates under the horizon. So you do not want it increased you want it decreased. So that means a multiplier of less than 1 (start with innerRadiusMult = 0.99 or assign innerRadius = (planet radius - (number of meters under the horizon the atmospheric band texture should originate)