Jump to content

The Lone Wolfling

Members
  • Posts

    204
  • Joined

  • Last visited

Everything posted by The Lone Wolfling

  1. Agreed. Although, that being said, some rockets are rather specifically designed. Perhaps a mass penalty? ("Enable multiple engine configurations: y/n" - yes increases mass of engine by 10%) Water ice makes sense. Also, possibly aluminum for SRBs. Any chance of you releasing said custom config files? Not to mention that water, not to mention steam, not to mention superheated steam, is corrosive. That being said, what about using air (well, liquid nitrogen) as a reaction mass? (I have a vision of a Jool <> Kerbin tug that aerocaptures at each end, refilling its propellant tanks as it screams through the atmosphere). What about a liquid core reactor? (Nuclear fuel dissolved in molten salt). Rather heavy though. Also, look at the nuclear salt-water rocket. Reaction mass is water with uranium or plutonium salts dissolved in it. Storage is an issue - you have to store it in long thin tubes with moderator lest it attain critical mass. Then you squirt the water out the back into a nozzle shaped in such a way that it fissions in the nozzle. That way it can have an absurd exhaust temperature without melting the rocket, as the superheated steam never actually really comes into contact with the rocket. (Except for a bit in the nozzle) ...Yes, because superheated steam isn't bad enough, let's pump superheated oxygen through our reactor! Sounds Kerbal to me! Also, what does the overall specific impulse of water, after splitting, come to? 284s? (1.00794 * 2 * 810 + 15.9994 * 218) / (1.00794 * 2 + 15.9994). Although, that being said, it should be higher than that as you can burn the low specific-impulse oxygen first, and then the high specific-impulse hydrogen after. Finally, random: "For example, a mixture of lithium, hydrogen, and fluorine produced a specific impulse of 546 seconds; the highest ever of any chemical rocket motor." O.o - because superheated oxygen isn't bad enough.
  2. Added. Took a while, sorry. I was trying to sort out some math, and finally just gave up and hardcoded it.
  3. Hmm... I'm not sure if this is even possible, but could you look into the possibility of having a set of fairings that deleted the contained parts until they were opened? (For lag reduction, mainly. This would allow many people to launch much more complex payloads.) There's a whole bunch of challenges with this, though. You'd have to transfer any enclosed resources into the fairing part itself, as well as dealing with mass and center of mass. It also would potentially have issues with command pods / probes inside the fairings.
  4. Drat! Standard orbital maneuver calculators are a dime a dozen - it's long burn calculations that's the thing I'm unable to find anywhere.
  5. One of those days? Yep, one of those days. Hmm... What about dynamically adding a PartModule to every ModuleEngines that adds an additional GetInfo parameter (Thrust at see level)? FixedUpdate is for physics updates... (And for part modules, only when the part is enabled...) Try just Update. Also, Could you just have a button to press to toggle, at least for a first try? Hmm... Ioncross?
  6. I'm using a i5-3210M. (2 cores, with HT (so appears as 4 to many things)). Ran fine. First stage (finding departures) used 25% CPU: i.e. single-core. It also triggered turbo boost mode (pushed CPU speed above nominal maximum). Second stage (particle swarm) used both cores (50% CPU, because of hyperthreading). Interestingly, turbo mode was still engaged. Can you tweak this to include the possibility of long burn times? So for things like ion probes, where they take several orbits to do much of anything? Also, looks great!
  7. Seeing as I am the person who suggested this, I suppose I should pop in and say that the thrust corrector is a great plugin. By the way, it's a great plugin! Also, as for the VAB TWR being off, would it be possible to add a button in the VAB to toggle engines between atmosphere/vacuum stats? That seems like the easiest way to deal with it.
  8. Is there a way to make a specific maneuver node? I'm using KSPTOT for weird transfers, which gives me a time and prograde/radial/normal delta-v. I'd like to be able to enter it into a maneuver node at the specified time.
  9. Wow that solver looks great! Would restricting it to not burn on the flyby help any? It would certainly reduce the sample space. Also, any possibility of calculating possible aerobraking for the flyby? Sounds like it's time to try (more?) optimization... What's the most expensive part? Have you tried profiling? (Though, that being said, it's going to be computationally expensive regardless - the sample space is just so large...)
  10. Exactly. So if he repeats the test several times, and the with FAR results are clustered and different from the without FAR results, he can be sure that it isn't just variance.
  11. Again, nothing to do with time of flight. Here's an example: I want to find the earliest Moho arrival time after the start of the game, that requires <=7190 m/s delta-v. Earliest departure time = 0, departure body = Kerbin, arrival body = Moho. Compute porkchop plot. Compute departure burn. Departure time = 0. Find earliest arrival for delta-v: 7.19km/s. Current result: arrival time: 2645496.8329s, departure time 0s, delta-v 7.19km/s. Wanted result: arrival time 2605640.6069s, departure time 252538.0995s, delta-v 7.19 km/s. (Wanted result found by alternating delta-v and optimal departure time.) Almost 40,000s (11h) earlier arrival time. Not a great improvement in this case, but it's a simple case. Yes, it does reduce the time of flight, but that is incidental. (A time of flight minimizer would also be useful, but that isn't what I'm asking for here.) Could you add an option in the enter max delta-v GUI to change between solver types? This helps, but it's the act of having to switch between different windows constantly that makes it tedious for me. Also, minor tweak: could you make it so when the program starts it starts with Kerbin selected as the departure body, and Duna as the arrival body? Currently it starts with Moho as both. Sane defaults are always good
  12. Hmm... Yeah, that should be possible. I'll give it a go tomorrow. Although, that being said, the vanilla pipe has an infinite flow rate. Should the pump powered fuel line use power for fuel sucked by engines, or just fuel moved by the pump? Good point. I'm going to be splitting up the mod anyways before release(Modular SRBs; Fuel lines; Ad-hoc RCS, etc.), so I'll do it then.
  13. What about making Pwings compatible with the modular fuel tank mod, for use for people with FAR?
  14. One thing to note: you can view the mass of the current craft in the map view now. Also, large RCS tanks are probably the best weights. I'm currently making a fresh copy of KSP, and then I'll try this.
  15. No. What I want is a refinement of the current solver. Given an amount of delta-v and a minimum start time, find the earliest possible arrival time. In some cases delaying the launch can actually make the earliest possible arrival (given an amount of delta-v) earlier. Currently, the solver doesn't search for this. I disagree with this, but it's your program, after all. It's just a pain to have to go into the settings to double-check that you're solving for the right thing. I wasn't aware of the periodicity of the delta-v boundary. Interesting... ...And it goes away with a 2-burn solution? Weird. ...derp. I had the starting parameters set to the global minimum, so of course it wasn't changing. Weird bugs ahoy! Neat! Always nice to see things go according to plan.
  16. Hmm... Instead of overriding the fuel consumption method, could you instead change the thrust level according to the ratio between the vacuum Isp and the current Isp?
  17. Version 5 looks awesome! Some comments/queries/concerns, though, as usual: For the various calculation windows, would it be possible to add estimates of the remaining time until the calculation is complete? On the "find earliest arrival for delta-v" window, could you also search to see if delaying the launch might make an earlier arrival feasible? If you hit "Select Departure/arrival date", and then exit the main window, it crashes instead of exiting cleanly. The console window still shows v0.1. On the "find earliest arrival for delta-v" window, instead of using a value in the options, could you use the plot data type? It seems to me to be a little more intuitive that way. Can you add an option to enter in the orbital parameters of a spacecraft around the transfer central body, and calculate transfer burns from said orbit? (Say, my spacecraft currently in an odd inclined orbit around the sun after a failed aerocapture...) What are the "swirls" in this plot: ? [*]On the "find earliest arrival for delta-v" window, if there aren't any feasible options, could you still select the best trajectory? [*]The scroll wheel currently always zooms towards the center of the porkchop plot, and doesn't zoom at all in the transfer orbit view. [*]Would it be possible to calculate the time to start multipart burns? (Or rather, when your spacecraft doesn't have enough thrust to do the burn in a single orbit, so you do a burn into an elliptical orbit, then next time around do the final burn.)
  18. The only issue with that is that then people would use a bunch of the small pipes instead. The larger pipes need to use more power than the smaller pipes, but be more efficient per unit of fuel moved. Unfortunately, fuel pipes are physicsless, and as such don't contribute to mass, or I would just make the more efficient one heavier. Also, update incoming later today - fixed the issues with loading parameters (it was silantly discarding doubles for some reason - I had to switch to floats for power efficiency and flow rate), tweaked flow rate / efficiency, added in-VAB part info, tweaked the GUI (I had forgotten that KSPField can format for you), and added a second larger fuel pipe. Next step is properly applying a force to both connections so that momentum is conserved.
  19. Urgh. Of course there's a conflict. I'll look into it. FuelBalancer shouldn't conflict, because of namespacing, but due to the way that modules load I think they are conflicting with the module names anyways. I'll rename it to FuelBalancerLine. Thanks for the feedback, and yes, balancing is still needed, no pun intended. zekew11 has already said that he'd give the fuel dump port and fairings a try. That being said, go ahead if you wish, especially with the modular SRBs. I'm never opposed to more models
  20. I don't think I need much help other than texturing/modelling, but thanks for the offer! Although, that being said, currently it's rather hackish. If you have any suggestions on that, please let me know. The source is included.
  21. RogueTech Screenshots Download RogueTech v0.4 Source GitHub Version History / Old Versions RogueTech v0.4 Added a fuel transfer line Removed modular SRBs (See [thread=38597]here[/thread] for a better version) [*]RogueTech v0.3 Added two new fuel balancers - a large one and a small one that uses RCS. Added ability for fuel balancer lines to use other resources Tweaked power draw of the fuel balancer Misc. internal changes Fixed fuel balancer module not loading configuration from part.cfg ([KSPField] doesn't work with double for some reason?) [*]v0.2: Added modular SRBs! Changed fuel balancer to balance percentage of fuel, not absolute amount. [*]v0.1: Initial release. Parts FTX-3b External Fuel Duct This reconfiguration of the FTX-3 uses monopropellant instead. Note that it is slightly faster than the FTX-3. Model/texture wanted. FTX-3 External Fuel Duct This fuel duct attempts to balance the fuel levels (or rather, the fill percentage) of the parts it is attached to. Note: it uses electricity! Model/texture wanted. FTX-2c External Fuel Duct This fuel duct actively attempts to move fuel into its target. Model/texture wanted. FTX-4 External Fuel Duct This is a larger version of the FTX-3. It is more efficient per unit of fuel transferred, but uses more electricity overall, as its flow rate is much higher. Model/texture wanted. Place-Anywhere 8 Fuel Dumper This part (rapidly) dumps fuel when activated. Useful for larger planes that can't land at full weight, or for giving Jeb a shower. Model/texture (Something along the lines of this, just the nozzle.) wanted. Todo Get proper textures / models. Make stock-like payload fairings (models / textures wanted!) License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
×
×
  • Create New...