Jump to content

paul23

Members
  • Posts

    661
  • Joined

  • Last visited

Posts posted by paul23

  1. Well I currently am running an MSI gp 60 laptop (with some added ram to make it 32 gb). However I notice that KSP is slow as snail on this setup, really not running well and playing terrible at times, even simply modded instals with just a 100ish rocket parts drain framerates to abysmal levels like 5-10 frames per second. So much that I often give up on larger missions like eve space stations. (With USI life support to be fully self sustained).

     

    I've now looked into buying a normal pc and am looking for advice regarding the video card/processor (and motherboard) to buy. Can anyone give me suggestions?

     

    For cpu, I am thinking between: amd ryzen 5 5600x/ AMD Ryzen 7 5800X / intel i5-10600k / intel i7-10700k

    For GPU:  the gtx 1660S or (high end) rtx 2060.

     

    I also wish to have at least 64 GB of ram, though those price  are much lower.

    In total I wish to pay around 1200, max 1500 euros for the total build, so the GPU + CPU should be below 1000 euros.

     

    What I mainly use my pc for will be kerbal space program, and (modded) minecraft. As well as for programming (hence the requirement for at least 64 GB ram).

  2. I consider mechjeb also vital nowadays. The boring idea of constantly burning at right the correct time is just annoying, similarly after you've made 20+ transfers it's just a matter of inserting those - and then mechjeb just solves that.

  3. On 11/15/2020 at 12:23 AM, bewing said:

    As I recall, the last time I did the full comparison the Tailfin is superior to everything else. You don't need a lifting surface at the back end. You need control surface area.

    Having a lifting surface means that the center of lift moves further back due to an object. The more lift a tailfin generates the further it moves back. One would always want the center of lift behind the center of mass.

  4. 1 minute ago, swjr-swis said:

    I like the looks and form of the AV-R8, but there's plenty of practical reasons to pick the delta:

    • Cost. 40 funds cheaper. Depending on the requirements or the available budget that might just make the difference.
    • Lift. 0.15 wing area more to get higher (or lift more overall weight).
    • Weight. 0.022 t less per winglet to push.
    • Form. The shape of the wing may be just the fitting piece of the puzzle for your airframe.
    • If you need something that adds a good amount of stabilization and just a bit of control, the delta wins.
    • If you need something that gives you both a fixed wing with better lift, and a control surface, the delta wins.

     

    The main reason it's often scoffed upon is its not-so-sleek looks. So when you explicitly single that out, the delta pretty much wins on all counts except as a pure control surface.

    How are the delta wing better, when they have so little actual control surface area?

  5. Well those two winglets seem to fit the same purpose, both adding control at the bottom of a rocket-stack.

     

    However the av-r8 winglet seems clearly superior: much larger control surface (full winglet instead of a tiny fraction). Only weighing a fraction more (and often in the first-to-throw) stage so it won't matter.

     

    Is there any reason I would pick delta-deluxe winglet over the av-r8? Other than looks which cannot be discussed.

  6. 5 hours ago, Caerfinon said:

    You may find this of use;

    "Crew management and transfers are now only a small part of what Ship Manifest can do.

    It can transfer Crew, Science, and Resources between parts within your ship or station. It also manages docked vessel refueling, hatches, deployable solar panels, antennas, and lights. Kinda like your ship's bridge..."

     

    I tried that mod.. However it still has a similar problem: I still need to scroll (in a very small window) through the 20-30 parts that hold crew to find that single crew I need to return to kerbin for a medical emergency contract. This mod shows which compartments have crew, but not the other way around: showing where specific crew is in the station.

  7. On 10/19/2020 at 7:27 AM, Rocket Witch said:

    With its ring of asteroids, low gravity, and healthy distance from the local star, Dres is something I see developing into a major centre of orbital industry and gateway to the stars, in an advanced colonisation era.

    Healthy distance from star is actually not a good thing to have.  Being close is often preferable for a space faring society: any such society should have fixed the "propulsion" system down to energy. And close to a start means much more readily available energy. (Until we start going dyson sphere)..

    But more importantly: close to a star means many more times a transfer window. Where a far planet would take several years, and another far planet would also take those, to get the correct alignment would easily take 10+ years at distance dres-jool.

     

    Yet with something close like moho it happens multiple times a year.

  8. Well as per title, I often have stations with 10+ the same hithchiker or a few science labs. And it becomes a real pain trying to find the location where a kerbal is sitting, to move it to another location. This is especially impossible with modules that have to air-lock and thus I can't quickly eva just to notice their location.

     

    So is there a mod that can help me? Either (preferably) a mod that allows me to "move" kerbals without selecting the cabin they're in, rather by using the protrait. Or otherwise a mod that (in the protraits) gives me a hint at which kerbal is where.

  9. Well I have small drones/satellites that should be added to a big hangar-like generation ship used to travel between kerbin and the final destination of choice. In the vab, while editing the big ship, I tried to add the small satellites.

     

    However they wouldn't attach to decouplers (surface attach). Even the root node won't.

     

    How would I handle this where I have drones and wish to add (say) 12 to a mothership?

  10. Well as per title I came back to my old save and wish to update the game.

     

    However I notice that the modlist I use has most mods "stuck" at version 1.8.(9). Which means I wish to play that version. However I can't seem to find any download for version 1.8.x anymore? The websites only lists 1.9 and 1.10... And older than 1.4.

  11. 5 hours ago, SpaceFace545 said:

    Liquid fuel could literally be anything and if they are adding metallic hydrogen deuterium and other fancy stuff they should probably split up liquid fuel into kerosene-for some rockets and jets, liquid hydrogen-for advanced rockets and fuel cells, Methane-for cool rocket engines, and hydrazine- for when You just want some plain cancerous fun. What are your thoughts?

    There is hardly any reason not not go oxygen-hydrogen unless you take many more complex situations into account. (like being able to store the liquid, on earth). Hydrazine would never ever be used if it didn't need to be used, it has worse chemical efficiency per mass is highly toxic and hard to handle. Then there's the corrosiveness and hence the choice of metals that depend on the fuel. Or how do you model the toxic disadvantages for the environment in a fuel?

    If this is then reduced to "you can have fuel xyz with engine abc, and other fuel with other engine", where each engine can have a single fuel. Then what's the difference in just abstracting it away under thrust and specific impulse? 

     

    I suggest you'll first read the book "Ignition!" by John D Clark. It shows the choice of liquid fuel.

  12. On 5/1/2020 at 4:20 PM, JoeSchmuckatelli said:

    I worried about the same thing during the first two attempts - and took a much lower flight profile on the third run to get a longer burn / better flight path.  I'm pretty sure it's mountains. 

    Reentry vehicle is the basic pod with heat shield, goo, thermometer and barometer.  Even with a nice long reentry burn (heat indicator on the shield went about 1/2 way down during the reentry) and a fully grey chute icon before deployment - the chute fully deployed, btw, and I was hanging nicely - when I was rudely exploded, again, at 1500m.

     

    I'm now thinking that I set the chute deployment for too low of an altitude for the wider variety of Kerbin landing zones - something I never did way back when - but I picked up on the option during the tutorials. 

     

    Love this game!  Been grinding on how to run the mission and save Jeb all night 

    The altitude difference between mountains and flat area is really minimal in regards for landing: if you crash on mountains you'll crash on sea level too. Mountains just make you tumble over easier.

  13. I hade a lander fully landed in water once, then before recovering I went back to base for some reason. When I reloaded the craft, it apparently started "sinking into the water" and went through too high speed submerging, making the tank and consequent lander above it go "poof".

  14. Hey I wonder if I can ask a question about syntax here? - can I "repeat" a part of the configuration "for each element in a list", or in other words: use an iterator inside a behaviour node?

    Currently I have a (working) solution that is like:

    	    BEHAVIOUR
        {
            type = ChangeKerbalType
    	        onState = CONTRACT_COMPLETED
    	        KERBAL_INFO
            {
                kerbal = @/candidates.ElementAt(0)
                trait = @/candidate_traits.Random()
                kerbalType = Crew
            }
    	        KERBAL_INFO
            {
                kerbal = @/candidates.ElementAt(1)
                trait = @/candidate_traits.Random()
                kerbalType = Crew
            }
    	        KERBAL_INFO
            {
                kerbal = @/candidates.ElementAt(2)
                trait = @/candidate_traits.Random()
                kerbalType = Crew
            }
        }
    	

    With candidates and candidate_traits being lists. This sets at completion the trait of candidates to a random trait. However I wish to update this to not explicitly call `ElementAt(x)` and instead reuse the whole `KERBAL_INFO` part for each candidate inside the candidates. Something like:

    	    BEHAVIOUR
        {
            type = ChangeKerbalType
    	        onState = CONTRACT_COMPLETED
    	        for (candidate in @/candidates) 
    	        KERBAL_INFO
            {
                ITERATOR 
                {
                    type = Kerbal
                    kerbal = @/candidates
                }
                trait = @/candidate_traits.Random()
                kerbalType = Crew
            }
        }
    	

     

    However that doesn't seem to work, when I do above the following error occurs (in alt-f10 menu):
     

    [ERROR] ContractConfigurator.ChangeKerbalTypeFactory: CONTRACT_TYPE 'Tourism_SpaceCamp', BEHAVIOUR '' of type 'ChangeKerbalType: Missing required value 'kerbal'

     

    so how to iterate in behaviour nodes?

  15. 5 hours ago, kerbiloid said:

    Just it isn't liquid, while the Kerbin ocean is.
    They are at same distance from Sun.
    So, either Kerbin has some internal source of heat, or Minmus should melt.

    Actually greenhouse gasses keep a planet warm, without those earth (and other planets) would be frozen over: so it's perfectly normal, just like the average temperature on the moon is also around -70 degrees.

  16. On 12/24/2019 at 12:08 PM, 5thHorseman said:

    You can sometimes get away with just typing the bbcode you're used to and then submitting, but a lot of times it won't work.

    What you remember is the old forum software. When they changed software (for security reasons, it was old) we lost our glorious BBCode.

    Hmm I wonder: is there a converter to allow me to enable editing like it's stackexchange/github? To convert markdown to forum posts, and also vice versa? Especially the editing is abysmal.

  17. I have a real aversion to things like wormholes and warp drives: mainly because it removes a core function from the game: the orbital mechanics. When you travel faster than light gravity can no longer be an influential factor. As such the whole idea of "orbits" is removed from the game, and you can almost travel in a straight line. Even if relativity is not taken into account.

     

    "near future" things like orion engine, or vasimir and solar sails (infinite specific impulse for a solar sail) would be perfectly fine with me: they have theoretical roots and do not violate physical laws.

  18. My biggest gripe, apart from what mods like far/kopernicus fix, is the fact that ksp considers kerbal a perfect sphere. Being an oblated sphere adds a lot of fun to the mix, from having to do station keeping, so actually using it to change argument of periapsis "for free".

  19. You are presuming Kerbin is flat.  (The curvature of kerbin means that flying in a straight line towards the horizon is actually upwards.)

    Where did I do that? I am not talking about the trajectory at all, I'm just outlining a baseline for calculations. You are the one making a statement, so the burden of proof falls upon you.

    17 hours ago, Ruedii said:

    You are presuming the only option is to fly the rocket in a straight line.

    Again I'm not talking about a straight line. Though I'm considering a simple trajectory where you always fire prograde, but instead of lowering thrust to make a "gravity turn" you turn just like doing a hohman transfer. 

    17 hours ago, Ruedii said:

    You are presuming your rocket has the same ASLISP as Vacume ISP

    ...

    You are presuming your rockets has the same ASL Thrust as Vaccume Thrust.

    Indeed I am. However as the vacuum specific impulse is not that much higher than the sea level impulse. Combined with the fact that the more simple proposal, of just firing much more straight/with full thrust, and "firing again during apoapsis", means a larger proportion is fired in vacuum.

     

    17 hours ago, Ruedii said:

    You are presuming your rocket has the same start and end TWR

    Not at all, I'm not talking about thrust to weight ratio. The gravity loss I do consider to be equal, since the distance traveled (70km) is small compared to the total radii (600 and 670 km).

     

    17 hours ago, Ruedii said:

    You are presuming the start weight and end weight of the rocket are the same.

    Again not at all, where do you get his impression?

     

     

    17 hours ago, Ruedii said:

    Do you need a video?

    Do you need a craft file?

    What we need is something that can easily be repeated by anyone. Something that can be verified, a craft with instructions how to fly. Either a video talk about the control input and design or something else. So long as anyone can repeat your results. I'll test out the design later once I got time away from the family.

     

    17 hours ago, Ruedii said:

    Your math is not scientific.  It's fuzzy math making false predictions.  Specifically, it presumes a linear trajectory.  Do you launch with a linear trajectory?   Do you launch with your nose pointing any direction other than prograde?  If so, that's your problem.

    This I get a chuckle with "fuzzy math". If there's one field you simply cannot be fuzzy in it's math. I come back to my earlier statement which is that the burden of proof lies with the claimer, the "simple" formulas show otherwise. As for why you see such low thrust to weight ratios in real life applications: this is due to (a) payload restrictions, and (b) it's hard to make rockets with more thrust, and more thrust means often much less thermal efficiency.

    17 hours ago, Ruedii said:

    You are applying 8th grade algebra to a math problem that requires calculus.   THAT is why you are getting a wrong answer.  You are specifically using formulas made for model rockets and low altitude sounding rockets, where the curvature of the earth becomes moot.  You are failing to account for orbital mechanics, and the oberth effect of how energy spent towards the horizon will raise both your apoapsis and periapsis, and energy spent burning straight up will lower your periapsis, while raising your apoapsis, and do so at a lower efficiency because it's spending energy doing both.

    No what I propose is just firing enough power to get a short burn to get the apoapsis up, the direction I am not even talking about, I'm just talking about doing a very short burn. Doing a short burn will mean you will fly "straight" as you call it for the latter part/coasting to the end of the atmosphere. After which you complete the circulation near the  apoapsis.

     

    I am advocating always burning at full thrust, or at least after reaching a minimum altitude, and not lowering thrust to "keep doing a gravity turn". The direction I have not made any statements about.

     

×
×
  • Create New...