Jump to content

Tiron

Members
  • Posts

    939
  • Joined

  • Last visited

Everything posted by Tiron

  1. It makes it 'playable' because 3.3.4 uses much lower resolution maps that use less memory, and thus it plays nicer with your 'too many parts' installation. Your problem is not mapsat, it's that you installed too many parts and didn't leave mapsat enough memory to run. And do NOT use unofficial versions. Unless Innsewerants gave 3.3.4 a permissive license (which he did not, so far as I'm aware), 'unofficial' versions are illegal and are not going to stay up.
  2. @Ferram: It most definitely does not spawn minimized if it was left minimized. Every time I load a craft, the FAR Flight Systems window is open again. Even if it's a Rover. On the Mun. That I just switched away from a bit ago. It stays closed if you switch between craft that are in range of each other, I'm pretty sure. I think it re-opens if you go through a loading transition though, like using the Map/Tracking Station to go out and switch craft. It DEFINITELY re-opens if it's your first flight after starting the game up again, even if it was a flight in progress. There's no reason for it to open at all if you're in orbit or on a body with no atmosphere, and in theory it shouldn't be too hard to set it up to check if you're in an atmosphere and stay closed if you're not. Equally, you could set it up so that if you're not in an atmosphere and enter one, it automatically opens; or if you're in an atmosphere and exit it, it automatically closes. (Although you'd probably want a checkbox toggle option for that.) If you wanted to be a little more fancy about it you could probably have it check to see if your current orbit is going to take you into an atmosphere or not, and base the behavior on that, but I suspect the only way to do that would be to code in the atmospheric limits for each body, so much more of a pain in the butt (especially if the limits change at some point.)
  3. ...I'm pretty sure they all respawn unless you turn Permadeath on.
  4. Seriously...landing on the Mun and returning is not really that hard. It only really requires six things: A basic grasp of the most basic bits of orbital mechanics (Specifically: The knowledge of how to reach Kerbin orbit, and how to circularize into Munar orbit once you get to the Mun.) Knowledge of how to get to the Mun (either using the 'just after it rises' rule of thumb or brute forcing it via a lot of timewarping.) An understanding of how to land in vacuum (Killing your downrange, then limiting your vertical velocity.) The realization that to return you need to get out of the Mun's SoI, ideally in the direction of Kerbin (my first return trip I aimed in the wrong direction but was able to correct my orbit once I got into Kerbin's SoI.) A craft with the TWR and Delta-V to accomplish all of these tasks. Sufficient practice in accomplishing these tasks to pull them off without botching it up. Learning all this and getting the practice is far harder than actually doing it: I saw a video on youtube recently (which I can't find at present), where a guy landed on the Mun and returned...using only his FEET. No Mechjeb. My first mun landing came within a week or so of getting the 0.13.3 demo, using no mods. I used the 'just after it rises' rule of thumb, which was well known and easy to find (without any picture/video references however I ended up burning a bit early, it worked anyway.) I landed on AV-R8 fins because of the lack of landing legs (the main game had them already so guides on how to use fins as legs were nonexistent, just some references to having done it that way before.) I had distinct trouble killing my downrange velocity and tipped over on all of my first attempts, but my lander was so massively overbuilt that the undamaged part of it was able to take off while lying on the surface and return to Kerbin anyway. I started using mechjeb some time after having bought the game, and largely don't bother doing non-atmospheric landings by hand anymore. Lately I've been taking SSTOs to the Mun. Yes, without refueling. My most recent trip was with my large rover-carrier SSTO: The larger of the two flew there without refueling...and that's why the smaller one is there in this screenshot. The larger one turned out not to have enough fuel left to make orbit again, so I refueled the small one in Low Munar Orbit, then landed it next to the big one to refuel it. Both of them ended up with just enough fuel to reach the tanker in LMO. I flew both back to Kerbin and landed them both at the space center. The smaller one on the runway, the larger one I botched it and landed short, the engines touching the ground and being destroyed in the process. Here's a video of the larger one landing on the Mun and deploying the rover. It's got pretty crazy methods for doing both, and I already posted it in the 'crazy invention' thread, so if you saw it there go ahead and skip it. Edit: Okay, now I found that video of the guy flying to the Mun and Back with his feet: NO THIS IS NOT ME DOING IT, IT'S ABYSSAL LURKER!
  5. I know that! Sheesh. But Mechjeb's supposed to keep them from flaming out at all by managing the throttle to prevent it, and when this happens it fails to do so. Normally it's quite good at it. I think when I put the DSIs back on the Ravenspear they might've gone on at a slightly different angle, so it could be something dumb like that, yeah. They're mounted on a tapered nose on the Ravenspear and that could be masking it. The Valkyrie has them mounted perfectly straight, so far as I can tell anyway.
  6. That's the part that confuses me more than anything. The DSIs are most definitely the cause of the problems I'm having, I'm just not sure WHY or how to clear it. Despite having solved it once already. That's a screenshot of the last flight I had on that plane before I fixed it. The spiral of sparks is because I'm in the midst of a very slow spin caused by the left engine basically constantly flaming out and immediately re-igniting. It only did that on that flight, where I'd replaced the Sabre S intakes with the cone intakes from your very own mod, because the turbojet version of the plane didn't have that problem and I thought it might be the Sabre intakes. Prior to that, it had been just flat flaming out, and then reigniting after it had yawed off axis a ways (?!). I was subsequently able to determine that closing both DSIs stopped it. With both of the DSIs closed, Mechjeb was able to correctly compensate for the intakeair dropping with altitude and prevent a flameout. I then stripped the DSIs off and replaced them with new ones, in approximately the same position, and the problem went away. And stayed gone even after I put the Sabre S intakes back on it. I'm now having the same problem on my Valkyrie rover carrier SSTO: Same symptomology: one engine flames out at altitude, with FAR saying I still have plenty of air and Mechjeb not cutting the throttle to prevent it like it's supposed to. Just like the first time, it started after making some adjustments to the plane that didn't involve the DSIs, after having successfully flown it clear to orbit without issues(Or in this case, not just a single flight to orbit, but also to the Mun and back.) Just like the first time, closing the DSIs causes Mechjeb to correctly compensate for the intakeair drop and prevent the flameout, and FAR to correctly indicate that I just barely have enough intakeair as it's doing so. The difference being that this time, replacing the intakes isn't helping. I've swapped ALL of the intakes out multiple times, to no avail.
  7. It's not the only thing weird with the B9 inlets. The Diverterless Supersonic Intake (the smallish radial one) has a habit of causing me to have flameouts. FAR reports having more than 100% of intakeair requirement. On one of my planes, it would flame out pretty reliably at around 107% of intakeair requirement. It's also throwing Mechjeb off, because the 'Prevent Flameouts' isn't catching it at all, either. On one of my planes I fixed it by swapping out the DSIs for new instances of the same intake, like it was something intermittent that was tied to that particular instance of them. Now It's recurring on one of my other planes, even after swapping the DSIs out multiple times. I Know it's the DSIs causing it, because if I close them, mechjeb throttles down and the engine relights, with FAR showing just barely over 100% of airflow requirement. I suspect it's related to what you noted, but it suggests something more deeply weird could be going on with those intakes.
  8. That's exactly what SHOULD happen. It also backs up the old version of the file as artifacts.dat.bak, but it deletes the old backup and makes a new one every time you run it, so if you did it multiple times it's probably got the same thing in both now.
  9. Yep. Unless he specifies otherwise, you have to start from scratch, because using anything from Mapsat would be a copyright violation. 'All Rights Reserved' is automatic upon the creation of any copyrightable content (at least in the US), and he has to explicitly state otherwise for any other situation to apply. (Note that I'm not a lawyer, however.) Time elapsed DOES alter it...but only after he dies. Current US Copyright law gives a license that expires 70 years after the death of the author. So if he gets hit by a bus today, it'll be legal to modify and redistribute on Oct 8, 2083, barring any changes to the law in the meantime. He also occasionally shows up on the official kerbal IRC. Last time I spoke with him he said he was distracted by another project (a game of his own) and hadn't messed with mapsat since he started it because he'd been told it still works (which it does.) He kinda implied that if it actually broke, he'd fix it. The evidence available to me suggests that the memory problems are a product of the way KSP loads textures, and would be endemic to any other mapping mod that used maps of the same size (3.3.4's maps were MUCH smaller, and so use much less memory.) Unless Squad/Unity fixes the texture memory usage problem, a new mod is not going to work any better on that front than Mapsat. It's also set up so that it can handle new planets or changes to the existing ones without needing an update, so unless a future update DOES break it, there's no reason to replace it.
  10. The first part is a C# program someone did, and yeah, you'd need visual studio or something in order to compile it. The second part however, is a Batch file, which is a very old, much simpler method of repeating a set of instructions: To use it, you simply copy and paste the bit from the 'code' window into a new notepad file, and then save it with a .BAT extension instead of .txt. Put the resulting file in your KSP folder. Double-click the file when needed. Which should only be after you've been scanning things (and even then, my last scanning run only seemed to get duplicates on Kerbin for whatever reason.) 'Batch Files' are basically a way of executing a series of DOS commands automatically, without having to sit and do it manually. The intent was to be able to automate a repetitive task so that if you needed to do the same thing on a hundred systems, (or every boot, or every time a particular program was started...) you didn't have to waste time doing it manually. Not used much anymore, but the functionality still exists.
  11. There's a couple regular struts connecting the front and back sections through the cargobay (at the top where they're hard to see in this vid) to keep it from just flopping downwards, the IR docking washer connections are EXTREMELY floppy for some reason. I originally used docking struts to attach the pieces in front of and behind the cargobay to the cargobay when in flight (and also the cargobay to the rover for stability), but switched to KAS 4 struts when it came out. That's the boring part I skipped: Sending Bill into the cargo bay to disconnect all the struts so the bay can rotate without tearing the ship in twain. Heh. I had a monster of a time getting this to work, but I'll share my key secret because I'm nice: For IR at least, you need to make the CargoBay the root part. Elsewise the docking washers MAY change rotation orientations when the craft gets rebuilt after docking the rover. I also did some, shall we say, manual .craft editing (in notepad) to keep there from being a gap where the docking washers are.
  12. it's your tail gear. when on the runway, the plane acts as a lever, with the fulcrum at the rearmost landing gear (that's touching the ground) and the force applied at the control surfaces. If they're too close together you get no leverage and the nose won't come up. It helps to have the rearmost landing gear near the Center of Mass.
  13. Yeah, I was doing that. If there's no craters 40 m/s works fine, if there are Bill and Jeb get jolted out of their seats. That happened once on the way back to the lander while I was in the shower (it covered the no-craters spot I had lined up faster than I expected.) Jeb was 5 km behind the rover, Bill was 3km behind it, and the rover was inside TWO stacked craters with a very steep wall between it and the Crew when I got back. It took some doing, but with the 120% wheels it was just BARELY able to climb up that wall. Had some problems because the speed readout kept changing modes, and because there were parts of it where it could only maintain a climb, not start one, but it worked eventually. Loving those wheels, man. That was the only time they had major trouble with a hill on the Mun, and that one was STEEP.
  14. Been having some problems of my own trying to use KAS 4.1 for in-orbit (Munar) refueling. I made one pipe connection and started transferring fuel, and it started causing the two docked vessels to shake relative to each other. SAS and Smart A.S.S. were both off, but it seemed to amplify anyway. Kept coming back after timewarping to try to kill it too. Once during timewarp the refueling tanker's parts near the pipe connector all shifted out of position slightly during the warp, and snapped back afterwards. Hit a point where I COULDN'T timewarp because it thought the ship was 'under acceleration'. Stabilized it somewhat (ironically with the SAS), and had Bob emergency unlink(Unlink really needs to not be EVA-Only, I think.) The two parts went flying off away from each other and I burned quite a lot of monoprop getting close enough to try again. I decided to try reinforcing the connection with struts. Ended up with the 'no attach pointer' problem, so I saved and reloaded to try to clear it. After reloading, Bob's jetpack didn't work. The thrusters would fire but imparted no movement. Right clicking on the strut connector brought up no menu. I couldn't recall what the 'drop part' button was since the controls are apparently undocumented, and just started pushing buttons. One of them worked, and the instant it detached it went flying away from Bob VERY fast, achieving several KM distance in a matter of seconds. It despawned at some point before I checked to see if it was orbiting the Mun, no idea why. After another save and reload, Bob's jetpack worked again and he was able to get back inside the pod with less than 30% fuel. The struts turned out not to be long enough anyway. The subsequent fuel transfer was successful, though I kept it short. The tanker turned out to have somehow had its periapsis dropped by 5km in all this. After landing, partially refueling a craft on the ground, and heading back up to the refueling tanker, the craft once more tried to pipe-dock with the refueling tanker. I decided to bring it in closer and better aligned on the fuel pipe connector, almost like docking normally, and see if that helped the shaking. I hit 'link' on the first pipe connector while Bob was still on the ladder. There was instantly a very violent kick. I don't know precisely what happened, but bob was sent spinning off one way, the main body of the plane another, and the cockpit of the plane a third. The front end of the refueling tanker was also broken off the main body of it, but floating stably a short distance in front of the main body. The Mechjeb unit on it was set to KillRot at the time, so it may have auto-stabilized it (it had a large probe core and a large ASAS and could've stabilized very quickly with the fuel tanks broken off.) Edit: New attempt of that last resulted in a similar effect, only this time only when I activated the second half of the link, to the refueling tanker. the tanker was instantly torn in half approximately at the connection point, parts sent flying all over. Bob went flying. Plane underneath appeared to be intact but was seen to be firing its thrusters to correct orientation, probably got hit by something?
  15. Unfortunately some of those things can encompass multiple mods. MagicSmokeIndustries for example, I have two from: Reflaginator and Infernal Robotics. We need to know which mods are being used in those.
  16. The pipes are mostly rigid (assuming removing the collider didn't break that, but I doubt it did.) There's SOME flex but you expect that. They work in docked-mode ONLY. Struts only work between parts of a single craft, but use the same model (scaled down) for the pipes. There's a very satisfying metallic TINK when they engage too. Both work similarly to how docking struts do, only with ExternalToEVAOnly turned on (so only an EVA Kerbal can make the connections.)
  17. It's back quite a ways, I linked to it in one of my earlier posts, I'll see if I can find it...sec... and yeah, it cleans up artifacts.dat so that there's only one copy of each anomaly. I only got multiples on Kerbin on my last scanning run though *shrug* Edit: Found one of my posts that linked to it: http://forum.kerbalspaceprogram.com/showthread.php/9396-0-20-ISA-MapSat-4-0-Dev-Build?p=420617&viewfull=1#post420617
  18. Left click on Innsewerant's name, hit 'view blog posts', boom. http://forum.kerbalspaceprogram.com/blogs/16471-Innsewerants Then go to "[0.20]Dev build of Mapsat 4 available and blog update. Bang, http://forum.kerbalspaceprogram.com/entries/414-0-20-Dev-build-of-Mapsat-4-available-and-blog-update Then hit the link that's under 'download the dev build here.' Install that into gamedata. delete the hilo.dat from plugindata before you use it. It'll take it some time to rebuild the hilo.dat database, during which it will appear to have hung. (It actually checks each planet's maximum and minimum heights above ground to do it, and also checks for new planets.) According to IS, it can take several minutes depending on your CPU speed (mine didn't take anywhere near that long.) I've got it from him directly that you do NOT need to have update checked before deleting it, that just has it check for new planets and rebuild if there are any (so it'll work if new planets are added later without an update.) Sawzall: If you've deleted your hilo.dat to fix the issues with that, it being rebuilt might be the cause of your 'hang', in which case it'll be a one time thing if you just wait it out.
  19. Well I've got two in this one: The craziest landing method ever for an SSTO (which I've used on two planes, but it's much crazier on this one, which is much larger and heavier than the other), and the craziest rover storage/deployment mechanism ever:
  20. Not that I've seen, thus far. I think the controls are too different for it, mostly. It might be able to do some stuff, but I haven't really tried it seriously.
  21. They form a rigid connection as opposed to a soft cable link. They're also dramatically lighter and use the same, grabbable piece on both ends. They also don't come with an undocked mode, they're docked-mode-only. The grabbables list for non-KAS parts is defined in Gamedata/KAS/AddModule.cfg . You can add additional grabbable parts without editing their part.cfg file by putting them in there. The file structure is fairly self-explanatory. The only things that really need tweaking generally are the placement parameters for the part's position on a Kerbal's Back, and the size they take up in a container. You'll note though that there's two themes in the parts that are included by default: They allow radial attachment, and they're small. He hasn't included large items a Kerbal probably couldn't carry. So far as I know, none of the tiny fuel tanks allow radial attachment. There's Stratus Roundified Liquidfuel and Oxidizer tanks in KSPx, though. Also, I did this earlier, via the addmodule.cfg, it made me laugh:
  22. Specifically, what he's referring to is that aerospikes have a property that makes them automatically correct for altitude. Traditional rocket bells have to be tuned to a particular altitude, and at any other altitude their performance suffers. Aerospikes are less efficient at any given altitude than a rocket bell tuned for that particular altitude, but the aerospike has almost that same efficiency at any other altitude, whereas the bell does not. You'd have to look at statistics on real aerospikes compared to the stock one to get a proper idea, but I can say right off that atmosphere curve is well out of whack. 600 seconds Isp is way too high. 400 is probably also a bit high. It also changes way too much: the whole point of aerospikes is that they have a more constant efficiency. One thing to keep in mind though, is that because of the reduced sizes on everything in KSP, realistic items would generally be 'overpowered'. Reaching Low Kerbin Orbit takes around 40% of the delta-V that it takes to get to Low Earth Orbit...and not only is LEO higher, but it's still well within the atmosphere too. As an example, let us take the J-2X, which isn't a particularly spectacular real engine: It's 3 meters in diameter, a bit bigger than size 2 which is around 2.5m. It weighs about 99% what a poodle does, has 87% of the mainsail's thrust, and 112% the Isp rating of the LV-909 (or about 115% of the poodle's.) It's not even close to the most spectacular thing ever in real life, but in KSP, it would be TITANICALLY overpowered.
  23. Funfact: R4m0n is back and has released a new dev build. Freaky, huh? I talked to him for a minute on IRC and he said he was planning on folding the changes from this version into the main branch, if Sarbian is agreeable...now we just have to get both of them to show up at the same time huh?
  24. This is one of the big things hampering Hybrid Jet/Rocket designs for SSTOs: You end up with a LOT of extra weight, if nothing else the ducting for the intakes, but in a lot of cases the engines themselves as well. One thing you'll note is that planes designed to go supersonic tend to have fancier intakes with fancier ducts, up to and including variable aspect intakes (Moving ramps, moving cones, that kind of thing.) This is because most jet designs don't handle supersonic intake flow speeds well at all, and it has to be slowed down before it can be fed into the engine using a number of techniques, most of which involve particular shaping of rather long ductwork. The 'big circular opening' you see on airliners only really works at subsonic speeds. This gives a decent view of the F-35's ductwork. You can see it in green leading back from the intakes into the front of the engine, going through a weird loop to get around the vertical lift fan (the -A model has a a fuel tank where the fan goes on the -B.) On a real aircraft, that's what you have to do: have an uninterrupted duct from the intakes to the engine(s) they service. Something like attaching it to a cubic octagonal strut or putting a cargo bay right behind them would, realistically, cut off the air flow. In KSP the air just magically flows to the engine regardless of where the intake is, which is one of the main things that allows airhogging. Frankly the entire 'intakeair' system is kind of a dirty hackjob to make the engines better balanced than they were, as was changing rockets to bipropellant (they used to burn just liquidfuel, so you could run jets and rockets off the same tanks. I used to mix jets in on the first few asparagus stages on my rockets back then.) It's also why we get flameout spins like we do: When one engine flames out, the intakeair it was consuming magically transfers to the other engines, which keeps them alive. On an even-engined plane, this puts you in a spin unless they're mounted very close to the centerline. Realistically, the output of each intake should be designated for a particular engine and unable to transfer to another if that one shuts down, meaning all engines would flame out at once. There'd also realistically need to be a logical flow path through parts with sufficient capacity, and very limited amounts of bending. Neither of these is possible with current game systems.
  25. Actually, they don't. It works as a mostly-rigid, docked-mode-only connection that is placed between the pipe ends in a fashion similar to docking struts. A very simple design failed to crossflow automatically through the pipe. Seems like it's mostly a dedicated thing for using KAS as an alternative to traditional docking, with the problem of being floppy. It's also DRAMATICALLY lighter than using winches.
×
×
  • Create New...