Booots

Sorry @linuxgurugamer if we're hijacking your thread. We could go elsewhere if you want. Right, 1m/s is obviously much too fine. I do 30 m/s by 750m steps and still get minute-long calculations for a moderately-sized mk 3 spaceplane. There are optimizations I can do and that I'm working on that might cut that time in half. Still, it's not just a line, but a surface and that means the number of calculations is squared. One of the major time sinks is calculating AoA. While in the real world, there is an approximately linear relationship between AoA and lift(until you near the stall region), this relationship would only be approximately accurate for a small range of Mach numbers and altitudes before the effect of those variables throws it too far off. I've been using Newton's method of root finding to locate the AoA where lift offsets weight. Unfortunately this means I have to iterate over all of the parts and calculate their lift at each AoA guess until it converges (about 8-10 times per speed/altitude pair). @Boris-Barboris is right. Any deflection of control surfaces to hold that AoA changes the amount of lift produced and thus the AoA required. Fortunately, this should? be minor and so I've just been assuming no deflection. (I think would be hard to simulate deflections)

I'm seeing that EnrichedUranium has flowMode = NO_FLOW which means unless your engine part itself has EnrichedUranium in it, you'll get the EN depleted message because the engine can't draw any.

From the Module Manager Syntax guide, exponents are @value != #exponent So, here you go: // Set up areaScale = #scale areaScale != 2 volumeScale = #scale volumeScale != 3 // Apply @mass *= #volumeScale @volumeBasedItem *= #volumeScale @surfaceBasedItem *= #areaScale // Clean up !volumeScale = 0 !areaScale = 0

You've stumbled across the square-cube law! You're about the furthest thing from incorrect when it comes to volume. Like you noticed, every time you double the linear size, the volume goes up by a factor of 8. You'll notice that the area goes up by a factor of 4. You'll further notice all of these are powers of the linear scale. Size goes up with scale, surface area goes up by scale^2, and volume goes up by scale^3. All of this is a solid facet of math and so you won't go wrong. Fortunately for you, this means you don't have to do exponents in MM at all (unless your scale is in a variable but then you can do @value*=#scale and repeat that line twice for surface area and thrice for volume). Unfortunately for me, this means coming to this thread to see how exponents are done in MM doesn't help me. In conclusion: @surfaceArea *= scale^2; @volume(or mass) *= scale^3; EDIT: The square-cube law actually has a bunch of fascinating applications and side effects. Note, though, that it applies to the geometry of your part. What I mean is, you could imagine the mass of the part won't quite go up at 8 times the size because a different fraction of the volume might be needed for structure and, since the part is non-homogeneous, this might mean the mass doesn't quite go up at the expected rate (or wouldn't, in real life).

I'm working on a mod right now that calculates the flight envelope of a spaceplane (mostly to assist myself with having enough thrust to get past the Mach drag rise). As a side effect, I'm calculating the required AoA for level flight throughout the flight envelope. So, yes, it's possible to make something do what you're looking for, but I think @linuxgurugamer is right in saying no to adding it to this mod because it's a completely new feature and would reuse hardly any code. Another issue that you've correctly identified is the time to calculate it all. Instead of doing a couple dozen angles of attack at a set speed and altitude and then looking at which AoA creates the right amount of lift, you're looking to analyze the whole thing at several hundred altitude and speed points for some tens of thousand data points overall. For testing the mod I'm writing, I'm doing a very coarse graph and it still takes on the order of a minute to analyze a spaceplane's flight envelope. So certainly not auto-updating.

@Papa_Joe, I'll look into what changes I need to make for Recoupler to make them play nicely again. Although I am kind of hurt that there hasn't been an outcry about it ( *cough* @linuxgurugamer)

It defaults to using blizzy's if Toolbar is installed. I didn't think to add an option to force use of the stock app button because I assumed people install Blizzy's to get away from the app launcher. Is that something I should add? It wouldn't be hard.

I'm glad to hear it! If you're adding distant planets, let me know how the balance works out for you or if you find yourself needing a cheaper but slightly more difficult method for the long transfers.

@Tokamak, your work is impressive! If you're still looking for parts to model, my ESLD Beacons mod could really use refreshing. It's exactly like what you described in your first post - a released mod with heavily reused models and slight texture changes to tell the parts from each other. I'd like to keep the style and feel of the beacons but they could use better models and textures. The techboxes you could really go to town with and give them different styles based on what they do. I'm actually working on a new functionality for the mod but am held back by the fact that I'd have to create an all-new model. If you're interested, I can describe what the new part would do and you can have full creative license to make something that looks like it should do what it does, but, more importantly, looks cool.

So... Yeah... This... The short answer is that you could use Persistent Thrust to accomplish this. It doesn't look quite as intuitive to use as the stock maneuver node system, but it might accomplish what you want. The longer answer is that you probably don't need this as much as you think you do. Bear with me, maybe you're doing something cool I haven't considered, but I tried spiral trajectories and found they were rarely useful or necessary. I actually spent a lot of time writing a mod that hacked the stock Orbit and ManeuverNode classes to make the patched conic solver accept patches that were solved through a differential equation solver rather than the usual Keplerian model. This let me create maneuver nodes that did exactly what you're envisioning and would even have let me use non-physical timewarp with the engine running because the 'orbit' was precomputed through the differential equation since it knew the thrust and mass burn rate. I never released it for a few reasons, one of which being that the way I hooked into some private methods is in a gray zone for forum rules (I don't think it ever broke the EULA, but when I asked if I was crossing a line I never got a clear go-ahead. The other reason I never pushed further towards releasing it was that it wasn't nearly as useful as I imagined. For interplanetary transfers, brachistochrone trajectories never materialized because I got super short flight times with ejection burns on the order of a few hours. While that's obviously not ideal, things like BetterTimeWarp would make those doable. For local orbital changes, bi-elliptic or multi-'impulse' maneuvers accomplished things just fine. Even when I was trying to create scenarios where a spiral burn would be used, I ended up making spiral segments of a few degrees of arc before coasting to the next maneuver. I guess with KSP's small scale, burn times are only rarely of an order where the impulse assumption gives unacceptable errors.

Yep, that's basically it. Its costs, efficiency, and stats are different. It actually uses a slightly different cost formula from the other beacons, but it ultimately is pretty close to the LB-100. Woo! Someone's using my guide! But also, thanks for pointing out the discrepancy. I'll see about editing that. Actually, @TMarkos, are you able to do that? I think I'm still linking to your GitHub's wiki instead of building my own wiki. If you want the raw data from that guide, I can probably dig it up again.

To those of you who use multiple star systems, I have an idea for a way I can give you a break on the cost of super long-distance jumps. Let me know what you think! Introducing the SL-20 Lensing Beacon: While not a beacon per se, this part assist in transferring a vessel by acting as a space-time lens between the source and target beacons. Simply* line up the SL-20 along the jump path and the cost of the jump will be drastically reduced. For better results, have the SL-20 at least 10 000 km from the source beacon.** Then, the smaller the angle between the source beacon and its target and the source beacon and the SL-20, the greater the decrease in jump cost. For example! A lensing beacon that is 10 000 km from the source beacon and that is 10 degrees off the transfer path will save you 8%. But wait! If it's only off by 2 degrees, it can save you 35%! Or, if you can manage to line it up exactly, you can save 50, that's right, 50% of the jump cost!! But wait! There's more! If your lensing beacon is 60 000 km from the source beacon, you can save up to 92%! This arrangement will save you 52% even if you're off by 5 whole degrees! * Disclaimer: lining up the three vessels may not be so simple. ** For best results, we recommend at least 50 000 km. I'm open to balancing suggestions on the distances, angles, and savings. Is this something you might use? How realistic is it to try to line up vessels like this? Would a GUI showing alignment help when flying the lensing beacon?

I've never played with other star systems before, but I'm thinking I want to try. Problem is, I'm rather attached to the stock planets. Is it as simple as nixing some configs to have this mod leave the Kerbol system as-is? Also, Is anyone able to post a screenshot of the tracking station showing the orbits of the new stars around the galactic center (the All?) for me? I'm just curious about the scale of this and want to visualize it a bit before I install it. Thanks!

It's fine, I was just pointing out that for the average user, one does not need Karbonite.

There is an included MM patch that adds Karborundum mining to the stock drills. I don't even play with Karbonite*/K+ myself. The resource definition is in CRP and with the stock drill mining Karborundum you can do anything you want. The trickiness is that surface Karborundum is in hard-to-reach places to keep in line with not making superluminal travel easy.

@JadeOfMaar Thanks! Merry Christmas / Happy holidays to you too!

Are you using the existing beacons? I think I remember hard-coding the parts with the standard beacon names (or with the standard beacon name within the module) to use Karborundum when I was more concerned about backward compatibility. They shouldn't be re-adding the tanks, though, just using Karborundum for the jump. Like I said, though, I'll be taking a look at it after Christmas - I don't really have time to get into the code before I leave my dev computer for the holidays.

Does anyone know if he ever launched? I remember his first attempt was scrubbed by the government (they want to keep us from finding out the secret! ). Does anyone have video of it if he has launched?

There should be a line in the config for the beacon where it says the resource to use. Unfortunately, I've had reports that it might be buggy and revert to using Karborundum regardless of what the config says. I'm going to be looking into that in the new year to make sure it's working perfectly.

Oops, thanks. It should read KSP 1.3.1 but I always forget to edit that thing.

I don't think so. The need for ReCoupler comes from the fact that KSP vessels are built using a tree structure where each part has a single parent, going back to the root part. The problem is when a part is added and could be a child of multiple parts - where its parent is ambiguous. KSP just chooses one and then doesn't connect it, physically or otherwise, to the others. ReCoupler creates the physical connection that KSP misses. So I'm quite sure it's an oversight by KSP and not Unity.

I've released version 1.0.0. Unfortunately, I haven't found time to add the requested overall cost multiplier. That will probably come this weekend. This update is for KSP 1.3.1 and fixes the out-of-power bug! I think. I had it working perfectly fine in testing in an earlier version of KSP but haven't had time to test it at all on 1.3. Please let me know if there are any bugs!

@GenjoKoan, I'm glad you like it! I was also surprised you couldn't do this - especially when people said it would be impossible to fix. I'm still waiting for my email from Squad asking to make this stock.

Can confirm, my housemate was wooing a German girl and we had a good laugh when we all went hiking and saw a "squiwrwel".

Hey writer types! I am not really a writer or a world builder. But I'm looking to collaborate with one or two on a mod that adds Easter Eggs and kind of revives the idea of a storyline behind them. I've got a few notes of my own for background but would like some help fleshing it out (or brand new ideas that are better than I could have come up with). I won't say too much here so that the people can explore the story once the mod is released but if anyone is interested, let me know and I'll add you to a DM group chat. Cheers!