king of nowhere
-
Posts
2,385 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by king of nowhere
-
-
without downloading the file, I can assert that it's very normal for early tech planes to have poor performances. just accept that your first low tech plane won't be a great one.
that said, my early tech plane could get to 10 km easily, so it's likely it can be improved. you'll have to wait for someone to download that plane.
i recommend posting screenshots of the plane in flight and in the sph too, with as much relevant data as you can think. few people will want to download a plane and launch it in their game to give you feedback, but a lot more people will be happy to look at the pictures and give feedback on that
-
14 hours ago, GlitchyTypo said:
I think theres a diconnect here. When I say orange, I mean the text that says "needs repair" not the highlight color of the part
I suspected something like that, which is why I asked twice to clarify that part. I'm glad we can finally be on the same page.
So, you mean the malfunctions tab you can open in the kerbalism menu. I never used it, because it's unreliable when using very large ships. anyway
yellow and red. both refeerring to a ship in orbit, not shown here.
orange, i didn't have any, I had to break my own engine here to create one. corresponds to yellow highlight.
so, color-coding malfunctions the way you prefer:
- yellow means the part is still functioning, but it may get broken eventually. it shows in the tab, saying "needs maintenance" (or something similar, I have the italian translation), but the part is not colored in game.
- orange means the part has malfunctioned. it is highlighted yellow in game, as shown in the second picture. An engineer can still fix the part in this state; indeed, the tab says "needs repair"
- red means the part is broken and cannot be repaired, period.
Then I can use this color coding to clarify.
yellow parts are still working. your probes are fine for now. with time, yellow parts will degrade further, and they will become either orange or red; in both cases they will not work. for my manned missions, orange or red are completely different beasts - one entails a short eva with an engineer, the other entails losing the part for good - but for your unmanned probes there is no difference; even if a malfunction could get fixed, you'd be better off sending a shiny new satellite rather than an engineer to fix it. in this case, you'll make full use of your deorbiter.
when i said malfunctions do not progress, i was saying that orange does not become red. i do not consider yellow to be malfunctioning at all, because - due to some quirks of game settings and really large ships that the devs never thought someone would make - those yellow parts, in my games, will stay there for centuries. but it's a quirk of how i use the mod, in your case they should last the nominal time of a few years.
hope that clears things up
-
your docking ports are placed correctly, but you have two big ships that are not perfectly aligned. in this case the magnetic docking ports will align the ships, but it will take time. and it won't happen if rcs and reaction wheels are holding the shops in place, so, as @18Watt aleady said, you have to turn them off. preferably on both ships.
-
1 minute ago, GlitchyTypo said:
Hoping that yellow would degrade to orange would degrade to red, although it would still have the chance to go straight to a higher damage state (y,o,r)
there is no orange, only yellow and red.
wait, i did not upgrade the latest kerbalism versions, maybe they changed it?
-
21 hours ago, GlitchyTypo said:
I think it would be more interesting to where if you left a module/part alone in a damaged state for long enough, it would degrade again to the point where it reaches the "busted" state. I'm trying a "semi"realistic run right now and enjoy sqeezing the use out of a limited functionality satellite when on a tight budget. The deorbiter is part of that, trying to not use the debris delete option.
again, for the sake of clarity: what do you mean by "damaged" and "busted"? because i thought by "damaged" you meant "yellow", but if you instead mean "needs maintenance", then it will break.
this engine is red, it is broken, it does not function, it cannot be fixed by an engineer. hence I am decoupling it and will place a new one on the docking port, i prepared those engines to be interchangeable. the drill on the left is equally broken.
the convert-o-tron is yellow, also the engine on the lower right. they are broken, they do not function, but they can be fixed by an engineer.
now, if you have a yellow part, it will stay yellow. it will not become red.
but you talk like you do not mean yellow and red, you talk like you mean a part without color, i.e. a part that is not broken and that functions. and in that case, those parts will eventually become yellow or red.
-
5 hours ago, GlitchyTypo said:
Darn.
Kind of annoying cause I had this whole system in place ready to de-orbit my comms satellites as they failed.what's annoying about it? your comms satellites are still getting malfunctions. being unmanned, they can't be fixed when they malfunction. even if they could, some malfunctions are critical and can't be fixed anyway. your deorbiter can still make itself useful.
wait, are we talking about the same thing or there was a misunderstanding? I understood you asking if a part with the reversible malfunction - yellow - can become red, and no, it cannot. maybe you mean you sent a kerbal in inspection on a functioning part and got told that a part needs maintenance, in that case yes, it will eventually break and get yellow or red. likelyhood and timing of either scenario depends on settings and difficulty level
in any case, if you let yourself get stopped by game mechanics, you wouldn't make a deorbiter because you can always delete debris from the tracking station anyway.
-
reliability buff for ion engines? they are by far the most reliable of all, in all my grand tours - which included small ion-powered auxiliary ships - I never experienced a single malfunction to an ion engine.
nuclear engines are fine, if you repair them before their time expire. the trick is that while an engine has a certain burn time, it will start with a greater chance to break a lot before that. high quality nuclear engines are nominally rated for 52 minutes, but I always did maintenance to them when they had 30 minutes left. my latest kerbalism grand tours involved 18 and 24 nuclear engines respectively, and both had expanded planetary packs, and I suffered a half dozen critical malfunctions combined between both grand tours.
I would say neither needs any reliability buff.
-
On 12/14/2023 at 10:34 AM, RoninFrog said:
I think the more quantitative rules are there more to prevent someone from spending hours and hours doing an Elcano that breaks the spirit of the challenge, only to be denied entry. As long as the rover is within the spirit of the challenge, it's probably fine. A green-light given by the Elcano caretaker overrules any fiddly rule breakages.
Indeed, a few months ago I asked permission to do an elcano on a plane, just going slow enough to not take off. And @18Watt approved the intention, provided I'd cut off thrust if I made a jump longer than a couple seconds, and I'd try to get down to ground when airborne. the spirit of the challenge is to drive the plane on the ground, and there's also quite some reason to use that plane - related to one of my grand tours where I would have liked to stay longer on Tekto, but I couldn't because of a bug. Anyway, there was enough of a case.
Incidentally, I got to around one sixth of the way before becoming engrossed with other projects and I haven't progressed in months, but I may come back to it eventually.
Now, one may question if I would actually abide by those limitations, or if I would obey the rules a couple of times while taking screenshots, and then fly gleefully the rest of the way. But then, if one wanted to cheat, one could just as easily alt-f12 his rover in a dozen places spaced around the planet and take screenshots, and pretend he circumnavigated the thing. At some point, you have to trust people. After all, what's the worst that could happen? Someone makes an entry in an internet challenge related to a 10-years-old game without fully earning it? Earns some underserved bragging points with the couple dozen people who actually bother looking at the scoreboard?
if people have a cool idea and want to try it, i wouldn't worry too much about the technicality of the rules or the prospect of cheating
-
4 hours ago, GlitchyTypo said:
Something I cant find online that I am curious about. Can the failures degrade over time? For example, can a "needs repair" degrade into a "busted" if not repaired?
No.
My longest mission lasted 1000 kerbal years. I kept some "needs repair" components that way as a backup, because they could not break further and i could reactivate them as needed. Never had any further issue
-
Is your rocket flipping?
The command pod has very low drag. If it falls head first, it keeps accelerating and will go too fast for the parachute. It must fall tail first.
And it's been a long time since i last tried that, so i can't help any more
-
I considered, since @JacobJHC seemed to appreciate radiations adding spice to the mission, I have my second kerbalism grand tour that I never submitted here. It was done at hard level, which means radiation shielding is three times less effective - effectively tripling radiation doses. It led to a very tense mission where radiations, bugs, and life support shortages conspired to almost cause complete failure - until finally, after a dozen attempts, I managed to leave Laythe and rejoin the mothership with 10 m/s spare deltaV, 90% radiation damage, and half a day worth of food and water left. Definitely one of my exciting missions, worth submitting here
-
5 hours ago, Jacob Kerman said:
preferably plane, my good sir
like, i was thinking ducted fan behind a plane kinda propeller science
where to start... take a rotor, put some ducted fans on it. for rotor size and blade size and number, go by trial and error: you obviously want the rotor to be as light as possible, but if it can't push the propellers at 460 rounds per minute in the conditions you want to achieve, then it's too small.
the hard thing is blade angle. make sure angle of attack is activated on the blades. put a KAL controller on the plane. use it to control blade angle.
the thing is, propellers generate thrust only with proper blade angle, which changes with speed (and possibly a bunch of other factors that aviation nerds will be able to tell at lenght, I'm not a plane guru). your blade inclination must also change with speed, hence the kal controller to do it in real time.
You also need to keep the aerodinamic interface open, as you see in the image (also featuring beautiful Neidon from the OPM pack). the number you want is total drag, because thrust from the propellers is displayed as negative drag. So in that image I have -22 kN drag, which means that propeller thrust minus actual drag totals -22 kN. And with the kal controller I slide the bar to change the inclination of the propellers, and I watch the drag number, trying to get it as negative as possible.
Some people prefer to link blade angle to the main accelerator, but all my planes are rocket planes, I prefer to reserve the main accelerator for the rockets. on a purely atmospheric plane it could be easier, though.
How to set the blade angle in the fist place? I go by trial and error. I place the blades, set the angle, then test the plane and see which way thrust is produced. I fiddle with the blade orientation until I get thrust in the right direction. Controller generally goes from 90 to 45 degrees, a 45° arc is more than enough for what you need and gives more fine control.
I'm sure the greater experts use more refined means, but my method is robust to be used by someone who doesn't really know the details. All you need to know is to set up the kal controller to change the blade angles, everything else you can figure out with trial and error.
-
15 hours ago, ctbram said:
of course, it is not I am still killing relative velocity. When the relative velocity is 0.0 I press x to kill all thrust. But then the ship accelerates with NO THRUST 0.0 0.1 0.2... Then I have to reorient target retrogade and burn to reduce relative velocity to zero again and hit X to cut the throttle and once again the ships accelerate towards each other with the throttle cut.
in the video you posted you were NOT killing velocity. Look at 0:34, when you said at this point it should stay, the thrust is not at 0. the most likely explanation, if you were pressing x, is that some mod was interfering with that. maybe some kind of autopilot. maybe you were miclicking. maybe you changed config so that x does not zero thrust. whatever the reason, thrust is not zero.
-
3 hours ago, ashcanpete said:
As you can see, the high quality part is barely worse than double normal components for the short term, and better after about the MTBF is reached. Considering the weight savings of using the high quality parts (seems to only add 10% in this case), it seems that I would always chose high quality.
why not high quality and two parts? or three high quality parts?
ok, I suppose if one wants to run a realistic space program one has to account for cost and mass.
me, using kerbalism for grand tour challenges, I never had to worry about mass and cost but I did have to worry about lasting for centuries. So I went for 6 redundant high quality parts.
3 hours ago, ashcanpete said:when one component fails in a redundancy group, the other components in that same group have the time until their next failure doubled
and I finally understand why at some point the ship just stopped getting broken. after a dozen malfunctions the remaining time of every other piece is just so long that it stops mattering.
-
2 hours ago, DennisB said:
Today I made my first successful ascent from Jool's lower atmosphere to orbit. It took so long, because I had to change the wings on my plane, and something went wrong. Even if I used the symmetry tool and the parts of the old plane, it was uncontrollable on the ground above 30m/s. So I had to rebuild it completely and went through the entire testing and optimization process for the Laythe configuration.
I think, I will work on it further, because I'm still not really happy with it, and I haven't tested the descent and the science collection yet, only with an older construction.
Now I'm curious. How much mass had Not Albatros in its Jool configuration? Watching the video, I think my plane is much lighter, and it has a completely different concept-
it's been a while, but iirc somewhat over 100 tons. the final plane is around 30 tons.
nowadays I am a lot more experienced and I recognize going reusable there was a suboptimal choice. Not Albatross is a perfectly fine laythe plane, to turn it into a jool plane I had to add somewhere between 80 and 100 tons. I could have made a disposable jool lander for less than that, and save mass overall.
-
19 hours ago, ctbram said:
Here is the video I made that shows the bug. It does not repeat even in the same save but it does happen again only with different ships. It occurs in other runs not just the save file I was grabbing the videos from. What's more, I will run the save one time and a pair of ships that failed to behave properly in one run will fail in another, and then work again in yet another run.
I have tried going to the space center and back to the ship or the tracking station and back to the ship and the bug seems to remain.
I have not tried switching ships with the target yet as dunbaratu suggested. He has looked at the video and confirmed that the behavior looks like a bug. We just do not know what triggers it. However, I have seen a few posts describing the exact behavior. So it may be rare but others seem to have seen it.
Here is a link to the video. I tried to keep it as concise as possible in the first clip I show rendezvous and station keeping as it should work. In the second clip, I show a series of attempts to get to station keeping only to have the ship accelerate towards or away from each other after reaching a relative velocity of 0.0 m/s.
problem solved. when the "bug" manifests, you simply did not shut down the engine properly. look closely at the throttle.
see how the needle is not exactly on zero. see also how there's a light glow behind your engines, further showing that those engines are, indeed, working. see also how, on the data window on the left, in the first case it says acceleration 0, twr 0, and in the second it says acceleration 0.16 and twr 0.02
I don't know if you changed the default controls, but on pc standard to shut off engines is X. that will shut down the engines for real. Unless some of your mods can activate them, maybe some kind of mechjeb docking mode; I'm not familiar with those.
well, turns out both sides were right. you were right in that it was not orbital drift. we were right in that the game was not bugged.
-
Today I discovered I have to give a raise to whoever is developing the solar panels. Because I botched a landing and tilted the ship and...
A single solar panel is holding up a 64 tons lander! In 0.3 g! What do they make them of?
One of the drills was still touching the ground, so I was able to refuel and launch back to orbit. The ship was even conveniently pointing eastward - roughly.
I wonder what other used one can have for nigh-indestructible solar panels
-
Quote
Furthermore, once you have achieved 0.0 relative velocity even taking into account the gravitational effects of the ship's masses and they - "not" being in the "perfectly same orbit" ships do not rapidly accelerate towards each other and apart accelerating infinitely.
first you said that the acceleration was slow, now you say rapidly. which description is false?
keep in mind that ksp has smaller planets with faster orbits, and so the effects of drifting are bigger than in real life.
QuoteAnd can you explain why one time I can hold at a stable distance at 0.0 relative velocity and then in the very same save get to roughly the same point get to 0.0 relative velocity and then just accelerate past the ship infinitely with zero external force being applied and never be able to achieve station keeping?
both hotel26 and 18watt already did mention the possibility in their answers. if the two ships are sharing the same orbit, one in front of the other, they can be very stable. if they are one above the other, they will drift away much faster.
QuoteI have a video of Physics working as it should and then with the bug I am describing here from the same save, rendezvousing with the same two ships. Perhaps you are all just not clear on what I am describing. The same two shiips should not behave one was (the correct way) one time and then completely differently another!
perhaps. what you described the first time is perfectly compatible with normal orbital drift, now you say that the change in speed is fast. I have experienced bugs with trajectories too, so there may be a bug at work.
QuoteI think with a MS in aerospace engineering from UofM in 1985 with a focus on control systems and 40-plus years of writing guidance control code I have a pretty damn good idea of how orbital mechanics and physics work and don't appreciate being talked down to with snarky comments questioning what I know about physics.
I do not want to go off and get snarky myself. I will make a video and post it here showing the behavior I am describing so you can understand that this is a bug and improper physics simulation.
we questioned what you know of phisics because you do not talk like an expert. Except for a few throwaway line that do hint at technical competence, like mentioning the physics of two spaceships orbiting each other (without whom I'd just dismiss your claims of MS as internet bravado), most of your messages come across as just ranting about things that have perfectly reasonable explanations. what you described in your first post was perfectly compatible with orbital drift, so the simplest explanation was that you were experiencing orbital drift and had no physical knowledge. even now, you boast of a MS in aerospace engineering but you never correctly describe orbital drifting.
We who are posting here have years of practice at this game. we do not have a degree, we do not know how to write guidance control code, nor we know about crafting techniques for advanced aerospace materials, realistic aerodinamic models, actual gravitational equations, or a bunch of similar stuff I suppose is studied in aerospace engineering.
but we do have a lot of practical experience running orbits, rendez-vous, dockings, transfers. I showed ksp to a friend with a phd in physics - he specialized in particle physics, but he took courses in orbital dynamics - and I was surprised at how much more knowledgeable I was than him. I would bet good money that when it comes to this practical understanding of the kind of orbital operations required in this game, we are actually more experts than people with actual degrees. in this specific field of space navigation, we are even more experts than several people working at nasa, because there's plenty of people who are not working on orbital mechanics but are instead building rovers, improving thermal shields, ruggedizing delicate science instruments so that they will survive space, how to establish communication protocol. Or perhaps writing code.
And so we also don't appreciate being talked down to with snarky comments questioning what we know about physics either.
-
23 hours ago, ctbram said:
This is not working there is some kind of loveing physics bug. I get 10m apart in target mode reduce relative velocity to ZERO that is ZERO.ZERO ZERO ZERO ZERO. and then then ship magi-loveingly starts accelerating. the navball goes to 0.0 I turn off all thrust so the thrust is zero then the navball goes to 0.1 0.2 0.3... until I am moving away at meters per sec!!!! Then I turn target retrograde AGAIN reduce relative velocity to 0.0 then kill ALL THRUST then the navball goes to 0.1 0.2 0.3.... all over again!!!!
others have already explained well why drifting happens and why it's so normal (really, I am surprised that you are knowledgeable enough to think of the two ships orbiting each other and realize the physics is wrong, but you still didn't realize how those ships, close as they are, they are still in slightly different orbits).
I will add that, for the purpose of docking, once you kill velocity you have enough time to dock. just don't take too much time, you can ignore drift if you dock fast enough. otherwise you can use rcs to correct for the drift.
-
11 hours ago, camacju said:
What are the rules for drag reduction techniques? It's possible to SSTO on Jupiter with stock parts and all the aero tricks in the book, but I don't think it fits with what you're thinking.
yeah, right, I forgot to mention.
I'm not the greatest expert in aerodinamics, but I'm aware of a few techniques:
1) magic wings, with lift/weight ratio of hundreds.
2) fairing/cargo bay sheanigans, to make parts dragless
3) placing parts and dragging them inside the ship, to close a node without generating additional drag
of those, I suppose 3 is allowed (an open node causing extra drag is a game issue anyway). 1 is definitely not allowed, I've seen stuff way too ridiculous based on it. in a normal challenge I would not allow 2, but what the hell, it's probably impossible without it.
any other aerodinamic trick I didn't mention?
EDIT: wait a moment, how is it possible to ssto jupiter? all the stock aero tricks will get you out of the atmosphere, but you still need to provide, like, 20 km/s or so of orbital speed...
45 minutes ago, Lt_Duckweed said:The saving grace it might have is that the atmosphere is:
- Much flatter than Eve, with a more reasonable scale height than Eve.
- Templated off of Laythe, making heating gentler. (Eve, Duna, and Eve/Duna templated bodies have 20% higher shock heating external temp. This doesn't necessarily translate to exactly 20% part temps, but it certainly does not help)
- A light atmosphere by molar mass, raising the speed of sound.
I still think it's probably impossible, but if it ends up being doable, those three factors will be why.
1) it is much flatter. it starts at 6 atm, but it reaches 1 atm around 7-8 km and it disappears completely at 55 km. so you have to climb roughly 20 km from the higher point you can reach on propellers to the point where drag becomes low, as opposed to 35 on eve
2) I wasn't considering reentry. i used inflatable thermal shields for my mission there. a spaceplane may actually be unable to land in one piece. however, the objective is to take off and orbit.
3) composition is 65% nitrogen 30% hydrogen 2% helium, so it's definitely a lot lighter than eve.
-
the spaceplane community keeps getting better and better. nowadays an eve ssto is considered pretty standard, and somebody even managed an eve ssto that can save enough fuel to reach gilly.
can you guys step up and make an ssto for valyr?
valyr is a planet in the whirligig world planetary system. It is significantly bigger than Eve, with a surface gravity of 2.17g and 1100 km of radius. speed of a low orbit is roughly 5 km/s. so a valyr ssto would need to have 1.5 km/s more than an eve ssto, and a greater thrust. seems pretty impossible so far.
but valyr has two saving graces in its favor. first, it rotates fast. on the equator, you already have 600 m/s of lateral speed, reducing quite a tad the deltaV requirement. second, its atmosphere, while denser than eve at sea level, thins more quickly, disappearing at 55 km. this translates in less overall drag and less altitude to climb.
with those two factors reducing the cost, going ssto on valyr may quite barely be possible. I think it's not, but I'm throwing this challenge to the spaceplane community because I may be wrong.
alternatively, i'm declaring the winner of the contest whoever comes closer to orbit in deltaV terms. to take this measure, you have to have an apoapsis outside of the atmosphere, run out of fuel, and create a maneuver node to enter a stable orbit. that would show how much deltaV you're missing.
good luck
In case somebody manages to orbit valyr, the next step is derbin. derbin is a moon of mesbin, it's as big as valyr but it does not rotate. so it's basically same as valyr, but with extra 600 m/s required. but while I may be wrong on valyr being impossible to ssto, i feel pretty confident that derbin is completely impossible.
a view of valyr. it's basically a bigger version of laythe. according to the science reports, there's life in the oceans.
valyr is lovely, isn't it?
-
23 hours ago, Jeb x Valentina said:
Bad news. Turns out it's impossible to get the ratio right while still having over 10 km/s...
So I'll have to grind for the rtg... if that's even possible and still get to Maubrett on time...
Should I cancel? I mean, I already have 10M funds and 45% ish reputation...
it's possible. you can get 10 km/s even with a nuclear engine, and the right ratio of fuel cells + on should give almost twice the Isp.
furthermore, you can get nearly as much deltaV as you want with drop tanks. simply put your tanks on decouplers and discard them when they are empty.
-
16 hours ago, camacju said:
this already took nine months
that's why i see your new records only every once in a while.
it took me nine months for the rss/kerbalism grand tour, and it involved 360 years, with regular inspections of the nuclear reactors every three years, with a very laggy ship, with 47 recorded bugs getting in the way. nine months for a simple stock system grand tour is mind blowing.
-
On 11/8/2023 at 3:03 AM, JacobJHC said:
Really good point regarding the vessel recovery science, although there is science for recovering vessels that have landed on planets or moons, which would be Jool related. Honestly I think that since it probably has been included in every mission previously that we just keep accepting it, although I do see you point. For deployed science the science counts but do keep track of how much is making its way back to Kerbin.
in my mission where i still hold the current record i didn't get that vessel recovery science. i sent the mothership back to kerbin orbit and sent up a shuttle to land the crew, specifically to avoid faking the result in this way.
no, just kidding. i sent the mothership back to kerbin orbit and sent up a shuttle because in all my planning I completely forgot to think on how the crew would land. still, the unintended result was there.
I think, anyway, removing that small science contribution should be trivial, if it was ever needed.
The Ultimate Jool 5 Challenge Continued
in KSP1 Challenges & Mission ideas
Posted
wha do you mean by "ok"?
it's ok in the sense that it will work? as far as i know, yes, because pretty muh anything can be made to work. I'm going to land a whole aircraft carrier on laythe, a shuttle won't be an issue.
it's ok in the sense that it is best optimized? depends optimized for what. certainly not for low mass, as you can go below 5 tons. but it may be a good way to do what you want. whatever it is you want to make. in this game there is no such thing as being "ok", there are only mission objectives.
only the challenge keeper can answer that, but regarding quicksaves: don't you any any more recent quicksave? or did you already delete all of them, except the first one which you accidentally loaded instead?
i recommend you never delete your most recent quicksaves. the persistent file is not reliable. also, the best way to delete quicksaves is to go in the game folder, not to do it in game one at a time