Tiron
-
Posts
939 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Tiron
-
-
Well I see two problems here:
First, and probably why you're exploding, the LV-Ns have a two-part fairing, unlike every other engine. Instead of remaining attached to the decoupler, the two pieces instead go flying off in opposite directions perpendicular to the engine. In your screenshot, The engines are positioned so that each will fire one of the fairings into the center of the engine cluster, which is a recipe for disaster.
Second...You've gone from a Tri adapter to three engines, to three decouplers, back to a tri adapter. This kind of connection isn't, so far as I'm aware, actually possible in KSP due to the tree structure, so two of those decouplers are most likely attached to the engines but not the tri-adapter (Meaning they get violently shot into the adapter when you decouple.) The struts would mask that, because they'd keep the two sections from flopping into each other.
To Go 1-3-1 like that you need to do something like this, using multidocking to get around the limitations of KSP's tree structure:
-
Mercury mk1 orbiting Kerbin for some "in space" tests of the new features of KAS v0.4. So far things are running fine
(This is only a partial view of one of the first new feature, there is more to come
)Big thanks to zzz for providing me the customized KAS models !
...Wut. *Head explodes*
-
Yes, I wrote a script to do it, and people for whom MapSat somehow works without making the game unplayable have annoyed me with this and associated advice (much of it bordering on voodoo) many times by now.
MapSat as it is only works for suitably small quantities of "works" and that suitably small is quite insufficient for me.
This is probably because many of us are seeing it work nearly perfectly, myself included. And we don't understand why you would say that it doesn't, since you're really not making it clear what's wrong with it (Other than 'the memory use is too high', which I'm going to quantify as soon as I finish mapping Dres.) And thus conclude you've probably botched up your install somehow.
Regardless, my KSP is only using 2.6GB right now (a bit higher than the normal 2.4GB), but then I don't really use parts packs. Because so many of them are imbalanced...and the textures eat a lot of memory. among other issues.
-
Can a KAS link transfer electrical power between ships?
A docked connection via a connector port, yes, because it's just like any other docking, as far as that goes anyway.
Hello!At first; thanks for the great mod! I do have one question (must be doing something wrong...). I'm trying to build a kethane station at Ike. This is happening if I connect a cable:
*Snip*
Had the same issue on Minmus:
*Snip*
I was lucky that everything could still work after it went down... Sorry if it is already in this thread, did read around 20 pages
.Try making sure the winch is in 'release' mode before connecting the cable. It automatically goes into a pseudo-release mode when a Kerbal grabs the cable, but you can retract or extend it a bit, then hit release manually, and I *think* it'll stay in release mode after being attached. Should prevent it pulling things over, I would think.
-
Pardon me, but as far as I'm aware, "it's a memory hog" to the point of total unusability with any reasonable amount of other mods.
Did you clean the duplicate entries out of your artifacts.dat file, as detailed here: http://forum.kerbalspaceprogram.com/showthread.php/9396-0-20-ISA-MapSat-4-0-Dev-Build?p=420617&viewfull=1#post420617
This should reduce the memory usage, possibly quite drastically (it really gets a LOT of duplicates.)
-
You'll be able to easily tell how much memory the mod is using by looking at the size of the artifacts.dat file in the ISA MapSat PluginData folder. IIRC scanning Kerbin itself can sometimes fill this file with multiple copies of each data point, which the 4.0 plugin doesn't clean up by default. The dev thread talks about a process for filtering the file to remove duplicates.
The other thing is the hilo.dat....I overwrote mine using values from the thread. I will try to find that link and post it here.
http://forum.kerbalspaceprogram.com/showthread.php/9396-0-20-ISA-MapSat-4-0-Dev-Build?p=420617&viewfull=1#post420617 is the thread with the directions on how to set up a .bat file to clear out the duplicate entries in artifacts.dat, which basically eliminates lag and reduces the memory usage.
There's another way to update your hilo.dat: make sure that the 'update hilo.dat' option is turned on, close the game, and flat out delete the hilo.dat file. Next time you load a ship with an ISA dish/GPS it'll rebuild the hilo database with the new values automagically(it makes the game hang during loading for a short time while it's rebuilding it, be patient.)
Either way, it won't affect any existing maps, because they're images. You can rescan without deleting the old maps, as the new scans will overwrite the old parts of the image.
-
Hi there !
Well, I post here because I couldn't "comment" the MapSat's Dev Blog.
So, I have a little problem with it : I have absolutly no textures from ISA MapSat. I've' installed it just today, and I've taken the latest Dev release, shown on its blog.
But, I can't see any button on the UI, and no button to open it (just were lucky to click at the nice place).
For the installation, I've just unzipped the archive in the KSP folder, and merged the directories.
Could please help me, or, if that's not the good Forum's Section, tell me where I should post that ?
Thanks.
You've installed it incorrectly. That's the pre-0.20 method of installing mods, you need to use the current method, which is to put the 'Innsewerants Space Agency' folder in Gamedata (after deleting the bits you put into parts and plugins.)
After that, you need to load the game, throw together something that has Either a Dish or a GPS on it, pull up the Mapsat UI, hit 'kerbalpedia', go to settings, and enable 'Update Hilo.dat' Exit the game, navigate to "<KSP Root>\GameData\Innsewerants Space Agency\Plugins\PluginData\ISA_MapSat" and DELETE hilo.dat entirely. The next time you load a ship with an ISA part on it, this will force it to rebuild the database of maximum and minimum planetary altitudes to accomdate the new planetary surface maps since the dev version was release. It'll make the game seem like it's hanging while it's rebuilding, just be patient.
You'll also want to follow the directions in this post after mapping things, to cut down the memory usage and prevent lag: http://forum.kerbalspaceprogram.com/showthread.php/9396-0-20-ISA-MapSat-4-0-Dev-Build?p=420617&viewfull=1#post420617
-
There IS an in-game volume slider you know... which persists between sessions
-
The only thing SRBs are really good for off-the-pad acceleration and extra thrust in the high-density lower atmosphere. Their efficiency is bad, but their thrust to weight ratio is extremely high. They're useful right at launch, but due to the poor efficiency not really worth hauling anywhere.
-
Hello! I'm the doofus who wrote those sentences in the first place. No need to guess. I'd say that if you visited multiple planets and then returned you have "returned" from all of them. You started at Kerbin, went to that place and returned to Kerbin. You just took the scenic route. The very, very long scenic route.
You might also grab the spaceport version and make yourself a Grand Tour shield.
Edit - and the RC does count for probes - in the current version of the game the difference between kerbals and probes is solely one of weight and remembering to pop the solar panels before hitting time acceleration. Well, and a slight pang of guilt when you auger in the kerbal. If you can design a craft that can make it to another world and then make it back, even if it's just a probe, you've done the tricky part. Doing it with kerbals just means scaling up a bit. This may change once life support becomes a thing and keeping kerbals alive for extended periods of time becomes a more serious design consideration.
Wasn't expecting the Man Himself to weigh in! o.o!
And yeah, I was thinking about the Grand Tour shield too (I actually already grabbed the spaceport version in fact).
Edit"
... I generally use the return chevron only for kerbals, but then again, I've never brought a probe back to Kerbin.There's not really any particular reason TO bring a Probe back right now. I'm not just not certain I have enough Delta-V to map Eve and Gilly both in one pass, and I'm quite sure there's no other system left unmapped that it has enough Delta-V to completely finish mapping either. I do have a *minor* need to remap Kerbin anyway, because my Oceans are mostly black (I didn't discover the 'delete hilo.dat' trick until I got to the Mun and it was coming out almost completely white.) So I may bring it back, have it Remap Kerbin so there's no need to have a later Probe do it, and then land it just because.
I'm not sure yet, I'm still waiting on the Dres mapping to finish.
-
You guys could test this by putting two kerbals with very high and low stupidity into a pod together and spinning it around like crazy. Stupid kerbals like being dizzy.
I did, actually, on the first[Third] page. And then again later. And I used four: Every possible combination with either 1/0.99 or 0/0.01 in each stat. (The second test used the second set of numbers to try to make sure that using the putative maximum and minimum didn't interfere with anything; it didn't seem to.)
What I found was that higher levels of the stats seem to increase their resistance to being scared: Stupidity slider seems to affect resistence to G-Forces (I think that's what it is) and being in the dark (except being on timewarp stops them from being scared of the dark). Courage seems to Only affect their resistance to being scared if you, say, tip over and break some stuff off. At least that I saw.
One thing I noticed on the test flights was that the 'high stupidity' Kerbals still had attitude drops from the things that were scaring the 'low stupidity' Kerbals. While the 'low stupidity' Kerbals were screaming their heads off, the 'high stupidity' ones were neutral. While the 'High Stupidity' ones were grinning like Jeb, the 'Low Stupidity' ones were neutral or maybe slightly worried.
The question being, how do you interpret that? The way I see it, you can either go with the 'Low Stupidity' ones being the UnIntelligent ones, because they're screaming at stuff that isn't actually dangerous. On the other hand, you could say the 'Low Stupidity' ones were the Intelligent ones, because they're scared of being on a Kerbal Rocket during the most dangerous points of the flight.
I tend to favor the former interpretation, but it appears to me that there's no ironclad way to determine which is which just from watching their reactions.
Courage, on the other hand, seems to be quite straightforward. When I tipped my lander over and broke it a bit, the 'Low Stupidity', Low Courage Kerbal and 'High Stupidity', Low Courage Kerbal were freaking the heck out, while the 'Low Stupidity', High Courage Kerbal was sitting there looking pretty neutral.
-
Interesting that all of the bodies have their highest point by the poles.
I wonder what the math would be on the various bodies for what the lowest energy burn to orbit would be taking in to account rotation of the body and dV then required to leave the SOI of the body.
Some places do have high elevations at the poles, but what you're seeing here is mostly just the effect of flying over more of the surface. For inclinations of 90 degrees or less, your orbit will take you back and forth between the Northern and Southern Latitude equal to your inclination. So if you're in a 30 degree orbit, you're going to be bouncing back and forth between 30N and 30S, potentially flying over a third of the planet's surface. If you increase to 45 degree inclination, you're now flying over half the planet's surface, including the bits from the lower inclination orbit. So the maximum possible elevation can only either increase or remain the same as the inclination increases.
Barring orbital resonance effects that keep you from passing over parts of the surface, but that's highly dependent on altitude and would make for one heck of a complicated graph.
-
All stock; just a decoupler, a modular girder adapter and twelve Sepratrons tied in with the Abort action group (the decoupler in the action group is the one holding the CM to the rocket; there's a second decoupler that will jettison the assembly from the stack). A second action group jettisons the tower post-abort and a third activates the descent chutes.
I did one like that, with 16 sepatrons (was having a lot of problems with rogue SRBs on that design) right after we got action groups.
I'm not sure if I'm reading that right but it sounds like you've got a decoupler mounted between the clamp-o-tron and the modular girder adapter... which isn't strictly necessary. You can save a part and a tiny bit of weight in there, because clamp-o-trons, when attached directly to a non-clamp-o-tron part in the VAB, gain a 'decouple' option. So you can mount the modular girder directly to the nose COT and use some or all of the sepatrons to pull it clear.
If you've already fired them, well, I find it's generally not such an issue at that point, since you're no longer under power.
Edit: And when I said the occasional disconnected liquid stage made things 'hairier', which I mean is that it was the center stage that was broken, and it remained attached to the bottom of the attempted abort through sheer thrust and friction. It's not a catastrophic problem in a situation like that because there's no actual impact: The connection is broken, but the parts stay in contact continuously.
In that situation, you can still steer with torque, if in a bit of a wobbly way. As long as you're not in a high speed dive with the engine driving you down, the parachutes will pluck the pod right off the top when you hit 500m. The best way I've found to do that is to swing it back and forth, using the out-of-control engine to slow your descent while still having the pod facing upward . And If you're still going up instead of down you can always just wait for the fuel to run out.
Broken off outer-stack liquid stages tend to go straight up, and frequently relatively slowly(In contrast to the inward-curving, very very fast SRBs). If you've got a powered upper stage at this point the chances of an impact are low, and the chances of a FAST impact are very low.
-
I vote: all of them. however:
1) The ribbon is not a regulated system
2) Sometimes it's not exactly clear what counts and what doesn't
3) There is no other reward than pride
So: do whatever makes you feel good. If lying outright makes you feel good, go for it. If only taking ribbons that you KNOW you've earned makes you feel good, do that.
Edit: Personally I don't like lying and think the ribbon acts as a good "game time spent" measure, so I keep my reasonably up to date.
1.) Yes, I wanted some other opinions on the subject is all.
2.) Oh I know. I've just had the thought that the way it's written I could probably technically take a Sun Return Chevron as well if I do bring it back(it's gone through Solar orbit twice already and would have to pull a third,) but I don't really feel too good about that one, because it's basically free.
I'd never lie because what's the point in that? As for 'keeping it up to date', well, I tend to treat the 'polar orbit' award as 'mapped the bloody thing' instead of just 'got in an orbit that could map the bloody thing'. Which is part of why I haven't thrown Dres up on mine yet even though I'm mapping it right this second.
The other part being that I prefer to combine predictable, sequential awards into one lump to save load on poor Moustachechauve's system. So when I *finish* mapping Dres, I'll slap it on there with an orbit+polar+probe.
-
I think that you can easily get Eve and Gilly, if you use good transfer orbit and aerobraking. Delta v from Dres to Eve's atmosphere should be about 1600 m/s. Then let's say 500 m/s to orbit fine tuning. It took something around 1000 m/s from low Eve orbit to Gilly orbit. Polar orbits may take some additional delta v, but you should still have about 1 km/s tolerance.
Therein lies the problem: I'm in a very high inclination orbit around Dres right now (85.2 degrees), and after primary mapping finishes I'm going to have to take it even higher to get the poles. I don't think I wanna try to transfer directly from an orbit with an inclination that high (I'm doubtful that it's even possible outside some extreme serendipity.) So I either have to jack the inclination way back down or pop out into a solar orbit (which would have a much lower inclination if I did it right.)
Either of which is going to eat into that margin, how much I don't yet know because I'm NOT taking this thing off timewarp until the primary mapping's done. It was hard enough getting the orbital parameters acceptable once!
Edit: Same problem going from Eve to Gilly, although maybe a bit more possible because you're more likely to get the orbit to line up with the proper ejection angle. Inclination changes are KILLER in terms of Delta-V, which is why I normally do the gross inclination setup for a mapping run right at the edge of the SOI (which is why I don't have equatorial orbital devices on any of the planets I've mapped.)
-
If it comes back to kerbin and is recovered or landed it gets a return chevron, the idea here is that you dont get return chevrons for one way trips, namely trips that finish somewhere other than kerbin. If it visited a planet and eventualy comes back it gets the return chevron, also visiting several places and coming back is harder not easier so I dont see any reason why you shouldnt add the chevron. The only question is in whatever probe missions count. As long as you note on the badge that it was a probe mission that question is covered since everyone will be able to see you did it with a probe not a manned craft so as long as you show the correct type of ship on the ribbon its perfectly fine in my opinion and its perfectly legit since your only claiming credit for things you've actually done.
Well the Guidelines for the Return Chevron explicitly say just 'a craft' with no mention of manned or unmanned, and also explicitly mention that it does NOT have to match with the craft device. The example he gives is that if you return a capsule, and then later put down a base, you can change it to a base and keep the return chevron, which doesn't matter for me as yet since the Probe's the only thing I've sent to any of those places on this run through (When my manned mission to Duna got wiped by the mod changes in 0.20 I restarted.)
Why would you want to return to Kerbin if you can map one more planet with a probe?Because, after having JUST gotten it settled into Dres mapping orbit, it has 4325 m/s remaining. It's definitely enough for one more interplanetary transfer, but the only place I'm absolutely certain I could map before running out would be Eve, or Maybe Laythe. I don't think I'd have enough Delta-V left after doing Eve to get to Gilly, and I'm reasonably certain I'd have nowhere near enough to do all five Joolian moons, and I prefer to do systems like that in one pass if possible.
I'm not at all certain it's enough to even successfully map Moho or Eeloo, which are the only single planet targets left. So I might bring it back just for the return chevron(s), basically.
I *may* remap Kerbin if I go back though, I didn't fix my hilo.dat until I got to the mun, so I've got black oceans...
-
The guidelines say "... a Return Chevron is added when a craft has successfully returned from a world to Kerbin." Which makes sense. It's not particularly easier to return a probe than it is to return a kerbal, it's just...there's not really any reason to bother right now (I'd be doing it basically just because I can and don't have any better ideas for what to do with the Delta-V.)
-
So my mapping probe is starting to get halfway close to the end of its Delta-V. After having Mapped Kerbin, the Mun, Minmus, Duna, and Ike, it's currently on its way to Dres with about 5413 m/s left. After all the orbital adjustments it'll need to make to map Dres, it'll probably have just about enough fuel left for one more Transfer, with a fair bit of fuel left over. I'm thinking of returning it to Kerbin afterwards rather than trying to map Eve (it probably wouldn't have enough fuel to do Gilly as well).
So, the question is...if I return it to Kerbin...would that award a return Chevron for just Dres, or for every world it mapped?
-
I didn't leave the lower stage of my mapping probe (in a high duna orbit, near Ike) enough Delta-V to Deorbit. So I did this:
Maximum separation was admittedly only about 1.4km, but I still half can't believe I pulled that off without even ONE explosion, or a broken solar panel.
-
As a KSP recruiter, stupidity is an essential quality I look for when choosing candidates for distant space station duty with good chance they will be stuck there forever.
Well just watch out, one thing I found on my second test flight (which I filmed, but haven't even watched let alone uploaded) that set off the 'low stupidity stat' ones was...being in the dark. Seriously. If they were eclipsed by the planet, they'd start freaking out...except if time acceleration was on, for some reason.
-
The Abort group can't shut down liquid engines on sections that have broken free of the spacecraft, so a high-gee powered escape (rather than tumbling through the debris cloud and hoping nothing hits the pod) is always desirable to me. My orbiters generally have very low TWRs to maximize delta V, pretty much always less than 0.5 gee, making an 8 gee LES option nice to have for outrunning lower stages (or even SRBs) when the fecal matter impacts the rotary air impeller.
I honestly can't think of an instance where I've had a broken-loose liquid section prevent me from safely landing the pod without an LES. I've seen times where it made it a lot hairier than it might have otherwise been, but it still worked. It's the SRBs that are *really* dangerous.
-
Very true. I've actually done pad-aborts in KSP, when a craft started crumbling when a support stand broke as the physics loaded.
But I do try to play with realistic safety concerns, so I include an LES. I also do a pitch and roll maneuver right off the pad, for range-safety purposes (so any debris will fall into the ocean instead of back down onto the launch site).
Actually that last is going to be a thing for all of us at some point I'm pretty sure: The ability for KSC facilities to get damaged and cost money to be repaired is on the planned features list.
As for 'realistic safety concerns', if you mean you're treating the explosions like they do damage, well, okay. Otherwise that alone doesn't really require a special LES (unless you have a low TWR upper stage.)
-
No, not really, so long as your first stage doesn't tear itself apart with structural failures, you're probably going to be fine.
I'm assuming at some point, though, in Career Mode, random equipment failures will become a possibility. That's when it's going to get interesting... deciding on the fly whether an engine cut-out leaves you with enough thrust to reach orbit, designing craft to remain in-balance during engine-out scenarios, and giving real value to including abort systems to keep your highly-trained crew alive.
As long as your first stage doesn't have SRBs you're probably going to be able to use the last stage for an abort even on a early structural failure(if you're fast enough). At least enough of one to parachute to a landing. The key thing is that any engines still connected to the rocket can have the throttle cut, largely removing their threat.
And last I heard squad had said no to random failures, but I could be wrong I suppose (or they could change their minds). Maybe as an optional difficulty toggle, like the permadeaths, if they think it's worth it. Lack of them is one the main reasons LETs aren't as useful in KSP: almost all launch failures are going to be caused by design problems you're going to fix, and end up with an all but completely reliable launcher.
Another thing though, keep in mind that the main reason real rockets have had LETs is pad aborts. In real life, if a rocket goes up on the pad the explosion is going to be massive and completely destroy anything nearby (meaning the crew needed to be NOT nearby in a heartbeat). Explosions in KSP don't (yet) do any kind of damage to things nearby, so it's less important. Particularly if your topmost stage has a TWR greater than 1 on Kerbin at launch(if it doesn't, an LES may not be unwarranted).
Just as an example, the soviets tried to launch an N1 Moon rocket for the second time on July 3, 1969: a loose bolt got sucked into an oxygen pump just a few a seconds after liftoff, causing the pump to explode. The onboard computer then shut off 29 of the 30 engines. It fell back onto the pad, and became the largest non-nuclear explosion in human history. It took 18 months to repair the launch facility.
Apollo 11 launched on July 16.
-
The really unfortunate thing would be discarding your abort option before you have another abort option replace it, and then needing an abort option.
By that argument, it would be smarter to take no LES tower at all.
If you take an LES, you're going for realistic safety options and/or historical accuracy. If your goal is simply maximizing efficiency at all expenses because you're just playing a game, leave the LES at home.
As a general rule, I've found that that for most purposes, KSP wise, you don't really NEED a LES all that badly. On the vast majority of the manned rockets I've ever designed, the final powered stage was more than able to fulfill basic abort requirements in most circumstances. Even on ones where it wasn't powerful enough to immediately land on Kerbin, it WAS generally powerful enough to get the pod safely clear of the damaged rocket. With one exception: SRBs.
If your SRBs get loose, well, god help you. They are FAST when they're not attached to a rocket, far faster than any liquid based design I've yet built, and have a nasty tendency to curve inwards, presumably due to the radial decoupler unbalancing them. On a number of my designs this has resulted in broken-loose SRBs having a fair chance of hitting the uppermost stage, or on a few occasions even the pod itself(I remember one that skimmed right along the outside of the pod, taking one of the radial parachutes off but the pod surviving. Interestingly that SRB started on the opposite side of the rocket from the parachute it destroyed.) That was the one thing I really found a LET to be uniquely useful for: mostly outrunning rogue SRBs (even with 16 sepatrons for a Mark 1-2 pod, it STILL couldn't quite outrun them if they went straightish!)
Almost every launch failure I ever had after cutting the SRBs loose, decoupling the damaged sections was able to handle without a LET. Admittedly sometimes only with the use of Mechjeb's PANIC! button, which decouples far faster than can be done manually, (it's an interesting trick, that) but that was pre-action groups. In some cases I was even able to land the upper stage at the space center without even using the parachutes!
)
Using tri- and quad-adapters both ways
in KSP1 Gameplay Questions and Tutorials
Posted · Edited by Tiron
I skimmed the thread honestly, so if I repeat something I missed, I apologize in advance.
KSP Uses a tree structure to represent a craft. There's a 'root part' (the first one placed), and every other part is ultimately attached to that part via a parent<->child relationship. The key thing is that each part can only have ONE parent, but a practically unlimited number of children. One of the effects of this is that it's impossible to build a structure that leads to one part via another by more than one 'path'. No loops, and no single->multi->single. This includes Bi/Tri/Quad Adapters/Couplers.
There are exactly two ways to get around this limitation, both use the ability to form a physical connection without forming a link in the actual craft tree. The first, most direct method is struts. The second is multidocking.
Multidocking still has to follow the tree: There can only be one parent<->child link, and that one link is the first port pair that connects. The subsequent pairs use a physical connection functionally identical to a strut connection between the two ports. This is why the magnetic attraction stops working the instant the first two ports connect.
You're also limited to one 'parent' port connection in the VAB, but if you set up port pairs so that they're facing each other in the VAB, they'll auto-multidock when the physics loads in on the pad:
Note the parent port pair is the set on the BOTTOM, the two upper pairs are physically connected only. This is showcased when you fire the decouplers:
You'll note that the bottom, fully connected port pair stayed connected, while the top two pairs lost their physical connection when they were decoupled (They lost their parent links, so the physical connection wasn't valid anymore.) They got pushed around quite hard by the engine exhaust firing into them, hard enough to cause some explosions when they hit the ports and tri-coupler (the one on the left lost its port but not the fairing, which hooked around the port on the second tricoupler, which I found slightly hilarious.)
Edit: Note for the multidocking to work you have to connect the lower ports to the adapter/coupler, and not the port attached to the engine: This means they have to be placed individually.