kujuman

Optimizations would be great, but yeahhhh, I've always thought that'd be after Unity 5 was out. Of course, I also thought Unity 5 would be out before "1.0". Physics won't be touched until then. Better RAM management of course would be amazing, but I have no idea what's actually involved in doing that properly. As to mod-ability of the new aero: as long as it's done remotely similar to how it is now (ie, having public variables attached to parts and part mods for surfaces), it shouldn't matter what's running under the hood for FAR to override it. We did survive the transition from part types to part modules okay, and the move towards partless plugins, so I wouldn't say that we're exactly doomed from the get go.

When testing Nav Utilities I noticed something odd, that stutter happens every 6km. So it's krackensbane recentering the universe. It's an issue with larger ships because every part has to be recentered. At least, that's the most probable answer.

As an addendum, apart from modeling time and design time (and RAM, but I hope that may possibly maybe get improved at some point), I don't see why KW style and p-fairing style fairings couldn't both be stock. save p-fairings for the end? Or make them much more expensive (2x?) than using standardized fairings? They both have their places, but my main thrust is that IF WE ONLY HAVE ONE STYLE, I think they'd best fit the game if they were KW style or dimensionally limited p-fairings. - - - Updated - - - It's the idea that p-fairings (that shape themselves, although this is making some big assumptions as to implementation) change based on payload, meaning that standard launchers aren't quite standard. One F9 launch looks the same as the next (unless there's a Dragon) because the fairings are standard sizes. This is very easy to do ensure with KW style fairings as opposed to p-fairings. I'm not really saying that people on here desire to limit others (rather, they want what they would like best as a primary motive); if we get dimensionally limited p-fairings I'm not going to enjoy them just because I can lord it over people who have the same desires as Brotoro, I will enjoy them because I enjoy them. I imitated Brotoro's language to demonstrate that arguing for p-fairings because the other half of KSPers want to limit creativity is not an argument for p-fairings (if I can use the same "argument" against p-fairings as can be used for them, then it's just rhetoric, not an argument).

Limited fairing size IS conforming to the laws of physics. One can't just cantilever a fairing 10 meters out to the side and expect some simple linear (in some number of dimensions) growth in cost/mass to be appropriate; the torsional and shear forces will accumulate pretty quickly. No solution Squad chooses will be able to account for all edge cases, so bringing them up as examples of what players might build is not helpful (because there will ALWAYS be a limitation to a chosen implementation). P-fairings can't be balanced (cost mass etc) as well as KW style fairings; and depending on how they might get special physics, they are still point masses and point sources of drag etc, which is not ideal from a physical accuracy perspective. As to the "urge to try to limit what OTHER players might want", this is a statement used to shame others, rather than to convince them. Not to mention that it flies contrary to how Squad has thought of KSP; it's a space Lego game, not a space Modeling Clay game. Not to mention that players can still launch ridiculous payloads even if they don't have a fairing. Or they could presumably roll their own fairings the way people have been making stock fairings forever since they're aiming to have occlusion (which I'm taking to mean that we won't need parts labeled "fairing" to act as fairings, as is the case in NEAR/FAR). I personally don't get the urge to try to limit access to premade fairing parts to OTHER players I've seen in this thread. Forcing us to use P-fairings will limit our creativity in fitting payloads to rockets. And then we can't build launchers with payload fairings like this Where the fairings were standardized and makes it so rockets fly the same payload to payload and look the same. Why won't you p-fairing fans allow us to build nice clean rockets like this? Just like in real life?

I'm really tired of these kinds of responses on this forum. The emphasis on "tried" takes it from helpful update on p'fairings to condescending. That said, I never said p'fairings didn't have limits, just that there ought to be limits on any p'fairings squad makes. Which really means that p'fairings would save part count more than anything compared against KW style fairings.

Yeahhhhh, about that... Fairings for modern launchers are standardized. Custom fairings for each payload would require new jigs every time, engineering every time, testing every time, etc. So let's take another look at your statement: "I don't get why people keep making this argument. [Right back at you] Having fixed fairing sizes was never a challenge in real life [exactly...which is why we don't see the equivalent of custom fairings] (it's just an aeroshell- they design it to whatever specs are needed)[not for every payload. think, "it's just a fuel tank- they design it to whatever specs are needed"], and it wouldn't be a challenge in the game even if they did things that way either. [Great, so standard fairings aren't a problem?] All it would be is annoying- you would just have to use fairings a full size larger than your payload if the payload was just a *tiny* bit too large to the closest size... [squad should also include procedural engines, since it's annoying that you'd have to use engines a full size larger if your payload is just a *tiny* bit too massive to the closest size. And procedural crew. I only want the brain of Jeb to control SAS, I don't really want to lug around his whole body.]" The way KW fairings work is great for basically everyone who isn't launching space stations in one go. And because they are modeled and textured, they always look the same. For people who are launching space stations in one go: just don't bother with the fairings! Launch the way you did in all versions of KSP until 1.0. Just brute force it the same way you're brute forcing a crazy payload, moar boosters and moar tailfins. I'm not opposed to p-fairings in concept, but unlimited p-fairings are just silly. Maybe max diameter is 2x base diameter? Max height limits 10x base diameter?

I'm torn on ISRU, at least until I know more. If we can harvest resources anywhere, it's a bit too easy, and gamebreaking if we can harvest on Kerbin, particularly if we can create xenon. But I also don't want super complicated resource trees. Still, yay! Although I wonder if we will get proximity fueling for ground bases or KAS like pipes.

It'd be interesting to compare the dev time of the SLS to other engineering projects. Say F9/F9H, new jetliners (787, 350), and the like. Clearly engineering takes more time now than in the past. Now, we might need to adjust for funding/effort to compare these contemporary projects, but if the SLS is same ballpark then we can say the SLS isn't taking so long: It's just average. Another factor contributing to perceived longness of the SLS is that we found out about it before very much engineering work or budget allocation occured. Let's say SLS and F9H take the same duration of engineering work. We didn't find out about the F9H until at least some preliminary engineering work was done AND SpaceX had committed itself to the project. We knew about the SLS before that work had ever occurred: Not so with the SLS.

I'm on again off again with FAR. I love having flaps and airbrakes and percent responsiveness to different axes on control surfaces, but it's such a chore considering how annoying other parts of it can be. My mates shuttle has many of these annoyances. Split rudder airbrakes? Sure, they work great on the runway. They work great in low alt testing. But they give a rudder hard over when trying to fly reentry, every time. FAR's drag by node is kinda a pain with certain shuttle designs, where there are a lot of large nodes at the end (engines, radially attached girders etc). Figuring out proper camber and thickness on delta wings is...hard. FAR isn't "hard", but it is time consuming. And it makes designing things to look good hard when so many parts have unlogical CoM already. But when it works right? And your time pays off? Amazing.

Another factor is that for SRs, the entire casing is the chamber, whereas the chamber in a LFR is pretty small (it's part of the engine). A large, powerful SR needs relatively more structure than a LFR of similar performance. I don't know what development costs are for different variants, but I'd guess adding SRBs to a lifter is a pretty simple to get a small increase in mass to orbit compared to adding an LRB for the same performance. A very large number of launches in the US are to support military (or otherwise GOVT) operations, so there's a subsidy for liquid fuel rockets as well.

I'm not sure how applicable this is to the aerospace industry...I'd imagine a lot of that tech has export controls (so you can't export the engineering). And why do you think engineering costs are inflated in the US (compared to their value)? I was thinking about this some today, that the big improvements for lowering cost to space (for sat operators at least) is the relatively large improvements in sat life. A sat that lasts 15 years instead of 10 has 33% lower launch costs all by itself. To get back to the OP, I think the F9 S1 has some form of thruster at the top for orientation, they may be able to angle the rocket enough to provide body lift away from some particular target, though I don't think that'd be the simplest engineering solution.

I think that's more of the idea that gimballing is an after market addition to an engine nozzle, and its inclusion on any particular engine is tweakable (for a cost/mass penalty).

I disagree with the condition that the launch rate must be increased for reusability to make sense. It's all about the marginal costs. If refurbishing a stage costs $10 million and a new stage costs $15 million, you're better off refurbishing. Production space that used to be used for building Falcon 9 stages can be put to other uses, such as Dragon2 construction, construction of the Raptors or the next lifter design. At the very worst, production space can be sold/subleased to another company, assuming SpaceX isn't able to use the space themselves for something else. The Hawthorn facility is 1,000,000 sqft or so, and the cost of the space, is probably no more than $40/sqft/year. Assuming refurbishing saves SpaceX $5 million per F9 launch and only refurbishes two boosters per year... 1) the reusing customers probably get some discount, let's say $2 million/launch. (40% of the gains from reusability) 2) let's say the "wasted" part of the facility is worth no more than $2 million / year (5% of total space, assume 50% of sqft is F9 S1 production and SpaceX goes from 20 S1 -> 18 S1 built per year. Probably bad estimates, but on the conservative side) 3) PROFIT! of ~$4 million/ year for SpaceX Any discussion of per vehicle development cost is a succumbing to the sunk cost fallacy; we should only consider the ongoing costs of developing the reusability aspect (not trivial, the Grasshopper and Grasshopper 2 and the pad in TX and engineering the grid fins and landing legs etc aren't free, and are unnecessary for a disposable rocket. None of this is to suggest that reusability (in the manner of SpaceX) is a magic bullet for lower cost access to space. In the fictional example above, the customer is only better of by some figure, maybe $1.5 million (insurers will almost certainly demand a higher premium for using reused rockets). I have no idea the cost of a F9 launch, the CRS missions from a quick search are ~$200 million. So a customer of a reused F9 might see a savings of ~1% of the launch cost. Not exactly a revolution, but still a good start (any cost savings are a good start, even if it's free snacks for employees in lieu of $1,000 more in their paychecks )

Yay! New parts are always good I just did a search for space shuttle computer and I got this page http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html I like the style of rack mounted computers with plugs for ground testing and such, so I just made it fit in the US container. Yay computers!

So I'm just getting into kOS, mostly to support a shuttle program I'm in the planning phases of. I have a few scripts to automatically perform life support and other mundane tasks (this is also getting ready to support my station efforts). Anyway, I like simple, so each LS task (fuel cell, purification, etc) runs on its own CPU. Now for the meat of my post. Is anyone interested in additional CPU models? I have one made that is radially attachable and fits inside a Universal Storage science bay. If so, I'll improve the textures a bit and throw it up on kerbal stuff.

I really wish the gizmos didn't have the dang gui toolbar thing. Because I always end up clicking over to it rather than using 1-4. In short, my mouse hand gets quite a workout. More seriously, the gizmos are still buggy enough (having to reselect parts sometimes when changing modes, having to click a few times before the part changes) that I try to avoid them for gross adjustments. Once I'm just tweaking for fashion (as dasvaldez would say) I do use the gizmos a bit more. Although TBH, the one part I could not use were it not for gizmos is the slanted elevon (Elevon 5 I think) because getting it oriented correctly is a nightmare. And even when it's close, it's still off. I have a love-hate (mostly hate) relationship with that dang elevon.

Thank you for that compliment! It's phrasing like that which encourages modders to spend their time to make the game as deep as it is. And to be honest, depending on how the stock one is I may just spend the time to make this one better. The stock cockpits so far are terrible for actually flying (I somehow think the artists haven't actually flown a plane before) since you can't see down very well at all. The instruments are also located in bad spots. Granted, I think the SP+ cockpits were intended to give room for RPM, but actually trying to land in one is pretty hard without it. So while this cockpit doesn't look very nice, I find that it's very functional; functionality keeps me wanting to sit in IVA. Otherwise internals are a "gee whiz" factor and a background for kerbal portraits.

Yeah, that engine cluster totes rolls. Gimbals controlling roll is relatively new, maybe a .25 or .24 addition. It doesn't look like it rolls because the gimbal angle is so small. - - - Updated - - - From the 0.25 Changelog

Did someone say Shuttle?! But seriously, my time with AdvSRBs has demonstrated exactly what's been stated: stock SRBs have minimal late game application unless the player just spams the heck out of them. The SRBs on this shuttle are 2m (not 2.5m). Together, they hold 132,900 kg of SolidPropellant (@223-244s Isp), which is 35% of lift-off mass. Together, they give 3797 kN of thrust at lift-off, 66% of total thrust, and provide about 800 m/s of dV over 99 seconds. Did I mention 1.2 degrees of gimbal? For SRBs to work well in the late game in KSP I think they need a few things: 1. Stack-able. Fuel should burn evenly throughout the SRB stack so all segments burn out at the same time. Also players aren't stuck with only a few size options because they can build longer boosters.1a. Ceteris paribus, boosters with more segments should burn for higher thrust, as there is more surface area of propellant burning. Wider boosters burn longer at lower thrust than narrow boosters of equivalent fuel mass. 2. Gimbal. I think in general gimbal ranges should be increased, but SRBs that lift shuttles or SLS style need gimbaling to function. Shuttles for obvious reasons, SLS style because they now provide a great deal of roll control. 3. Burn profiles, not just constant thrust. These are easy enough to write automatic solvers for since I doubt Squad would want very editable SRBs in stock, because it'd make things too confusing for new players. The SRBs on the shuttle above use an automatic profile that is set to provide constant acceleration (TWR) for the vehicle (if we assume only the SRBs are burning), and that is a very good general purpose setting. No more massive TWR increases at the end of a stage.

I'd just like to add that I'm still planning on writing more failure modules once things settle down again. I have a module working where the lf/o ratio gets knocked off by some random amount. If you'd like, I could put together a guide on making a 3rd party failure module (very simple really) to give you more dev time.

After realizing that they shipped a shuttle cockpit featuring a sensory deprivation tank instead of the instrument panels, windows, and seats ordered by the KSC, C7 Aerospace Division immediately set to work to fix this oversight. By immediately going to work, I mean they hired an outside contractor to work for long hours and no pay. With that, the Kerbal Science Foundation is pleased to announce the Mk 3 Cockpit Internals! Requires: ModuleManager forum | d/l Does not require, but best with: RasterPropMonitor forum | d/l (you should have this installed if you have the ALCOR installed) ASET Prop Pack forum | d/l (you should have this installed if you have the ALCOR installed) NavUtilities forum | d/l DOWNLOAD at KerbalStuff This is intended only to be an interim release, and will not be maintained except for big bugs, or until we get the official internal models for the Mk3 Shuttle. License: CC BY-NC-SA 4.0

Oh, I wasn't even aware of the reliability modules. I think if the core system is able to receive instant failures from reliability modules on parts, then there's no need to change anything. Maybe a public method in the core module; FailSinglePart(Part) could roll the failure mode. A reliability module could then call FailSinglePart(this.part) so the failure doesn't have to wait until the update timer (this may be what you had in mind, I didn't read through the code yet). I think that'd allow the best of both worlds, since a reliability module could do MTBFs.

Another factor to consider is the mass of the structure. I'd guess that having 8 engines equally spaced from the load bearing tank wall is lighter than having the eight engines zig-zaged (from the perspective of the tank wall).

Try saving this text as MM_HSI.cfg to create a module manager file (Assuming you have ModuleManager installed). @INTERNAL[mk2CockpitStandardInternals] { PROP { name = analogHSI position = 0.3472729,0.2679975,-0.4824364 rotation = 0.5285116,0,-3.42179E-17,0.8489261 scale = 0.12,0.12,0.12 } PROP { name = analogHSI position = -0.3466099,0.267998,-0.482436 rotation = 0.5285119,0,0,0.8489259 scale = 0.12,0.12,0.12 } } @INTERNAL[cupolaInternal] { PROP { name = analogHSI position = 0.1203323,-0.1161163,-0.4592682 rotation = 0.7071067,0,-6.181725E-08,0.7071069 scale = 0.15,0.14,0.14 } } - - - Updated - - - Do you mean the ones in the .cfg by Virindi (linked a few pages back), or a different set? Or to create ones from scratch?

0.2.1 Ex1 In addition to the two points by razark (the gui not staying put is particularly an issue since it can get in the way of KSP windows (example, the AppLauncher and the show options panel button interferes with the staging list in the VAB) â–ºGlobal Reliability Modifier: This wasn't intuitive for me, I was expecting it to be a multiplier like some of the other settings, so when it went negative I became very...concerned. It took me a bit to realize that it added percentage points to reliability. So a setting of -25 would turn a 100% reliable part into 75% reliable? And a 50% reliable part into 25%? It makes sense for it to be additive (so a 100% reliable part could be changed to being 99% etc., but I just had a bit of a time figuring this out. EDIT: Just set this at 25, and now the MSD is reporting reliabilities at like 1500% - 2000%, so now I think it's a multiplier? â–ºI do like that the options drop-down is persistent between scenes â–ºFlying the default KerbalX, the MSD still was jittery with the options panel open; with the options open, the MSD was longer than my resolution height (I think 1600x900). - - - Updated - - - I have some ideas on this. I don't really have the statistics background to make the math work off the top of my head, but if given a bit of time I could probably make it work. 1) Failures should not be constant rate for some items, particularly ones that "start". For example, engines have a very high risk of not starting correctly, but once they are stabilized (0-6 seconds or whatever), the risk of failure is pretty low. Fuel tanks and similar items that don't "start" maybe need a constant risk of failure. 2) The current system of failures means that when failures do occur, they tend to occur in packs. This is sorta desirable, I'd imagine that a failure would increase the risk of failures for some time. So if a vessel experiences a MAJOR failure, maybe bump the vessel failure rate up by 25% for 3 seconds or something? 3) The concept used in real life for reliability is Mean Time Between Failures (MTBF). Fuel tanks maybe should have a MTBF and a StandardDeviation rating rather than a %. 3.1) MTBF calculations would be divided into periods. 3.2) We assume (for simplicity) that actual failure times are normally distributed around MTBF for certain items (like fuel tanks). 3.a) At the start of a period, the partmodule rolls a random number (0-1), this is our P-value 3. Use the P-value to reverse-lookup a z-value from a normal table (see the example 2 under the table here http://www.normaltable.com/) 3.c) Multiply the z-value by the StandardDeviation in the partmodule to determine the failure offset time from MTBF. 3.d) Save the FailureTime as UT. 3.e) At FailureTime, roll to determine which failure occurs, and do the failure. 3.f) After the failure is repaired (or at launch), start again at 3.a Example: A fuel tank has a MTBF of 1500 seconds and a StandardDeviation of 300 seconds. When the fuel tank is launched (or activated, or whatever), roll a random number, 0-1. We rolled a 0.236. Our p-value is 0.236 ([I]3.a[/I]) Lookup (we may be able to compute this as well, there probably is a Math function on the system) the z-value from our p-value. (For reference, normaltable.com only goes 0.5 -> 1, so we do 1 - 0.236 = 0.764, and multiply the z-value by -1). The z-value of 0.764 is right about 0.72. We multiply by -1 to evaluate 0.236, and our z-value is -0.72. ([I]3.b[/I]) -0.72 * 300 is -216. -216 is the failure offset time from MTBF ([I]3.c[/I]) FailureTime is UT + MTBF + Failure offset time. If we just launched a new file, UT is 0 seconds. 0 + 1500 + (-216) = 1284. Save 1284 in the part module. ([I]3.d[/I]) Not sure the most efficient way to do this in game, but when UT (the master time in KSP) reaches 1284 (21m24s after liftoff), roll a failure using the way it's already done. ([I]3.e[/I]) I have some ideas about using FloatCurves (or AnimationCurves, same thing really) for more complicated cases such as part activation, but you get the idea. For things that cycle like solar panels, a duty limit might make sense, so instead of a mean time between failures, we evaluate mean cycles between failures. Same math and concept, just without worrying about the clock. ---EDIT--- I'll look at it more later, and this is also so I don't lose it, but an open source (not sure of license) stats package is at https://github.com/mathnet/mathnet-numerics/tree/master/src/Numerics/Distributions It looks chock full of things. The exponential distribution looks like it'd be good for engines.