-
Posts
127 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Tanya Sapien
-
well....yeah >..< I parked three objects in the exact same orbit, then adjusted their Epochs
-
by parking a small body equidistant between two larger bodies inside the orbital path of one of the two. check it out on wikipedia, it's an interesting property in physics.
-
well Red is already used for Ore for the launchpads addon, but I do like where you're going with that. Currently ISA mapsat is the only Easter egg hunting mod I know of, however I've noticed parameters in the Kethane config files which would theoretically allow overrides of deposit locations. If one were very crafty and very meticulous, they could make a unique resource titled "Anomaly" and manually override the spawn locations to make them match the coordinate list of anomalies detectable with ISA. You give them a unique color, like maybe blue, and then have at it. while you're scanning, any region which contains an anomaly will show up blue. So somewhere inside that hexagon/pentagon is an easter egg. It wouldn't be cheaty since on planets like Kerbin you're still looking at roughly 100 square kilometers to search. I think when I've got the time this evening I'll try to do some coding and see if I can come up with anything.
-
I just got an idea which I have no idea if it's already been pitched; Kethane + KAS + Kerbtown What if the ability to lay kethane pipelines was added? You take a special kind of docking port and activate it with a Kerbal, that's point A. Then you get that Kerbal across the surface of the planet or moon by whatever means to the refinery/warehouse where he activates a second special docking port, that's point B. Once point A and point B are defined, a pipeline composed of tessellated world objects is erected between them. As a game balancing element it could even take time to erect and have a cost of X resources per kilometer to build it. A resolution to load-in distances would be as easy as giving the pipeline a buffer based on how long it is. A pipe of X length can hold Y units of resources. You switch between vehicles attached to the pipeline to dump into or pull out of it. Doing that, you could have four or five off-site drilling rigs which all connect to a central refinery and storage site. Assuming you've got the launchpads too, you now have KSC-3. Perhaps I'm over-thinking this...I blame Minecraft.
-
This colloquialism has always bugged me. When you say five times lighter, you're using a multiple to define a reduction without a referenced unit which is being multiplied. If the reference object was only 100 grams lighter than a base object weighing 10 kilograms, then your multiple of five means 500 grams lighter, so 95% of the original weight. Likewise, if the reference object was 1 kilogram lighter than the base object weighing 10 Kilograms, then five times that would be 5 Kilograms lighter, and 50% of the original weight. Taken literally, your colloquialism has too few variables to find a solution. We're scientists here, accurate data is mandatory.The method I'd recommend using if you have KAS is to have a mobile refinery and use shuttle craft to get into orbit. The refinery can get away with being a bit heavy because it only has to move when a deposit runs dry, so that's 1 period of losses due to gravity. The shuttle craft can just be fuel tanks with engines on them, so that would minimize the Delta-V needed to move fuel back and forth between the ground and orbit. As far as an orbital tanker goes, the solution to that is simple, have the tanker itself be the ascent stage. Instead of having tanks that jettison as it leaves Kerbal, keep them. That way when you're mining later you have somewhere to store all the fuel you refine. Unless I'm mistaken, those are air-breathing engines that while they do require intake air, they are capable of running in atmospheres that have no oxygen, like Duna for example. Hope that helps
-
No, sorry. It's not a bug. There is no way to save HyperEdit changes persistently yet, but it is on our list of improvements. When, is the big question.Ah. I'll be eagerly awaiting it then. I've been wanting to begin work on This Project for a little while and it's dead in the water until a fix is found. Editing planets and moons is quite pointless when they revert every time the game's rebooted. Other than that, it's a great plugin and I get a lot of use out of it. Send my best to the other devs.
-
This has likely already been addressed, but is there any way to save edits you make to the planet's orbits? I spent a good four hours completely redesigning the solar system earlier today, and I saved with the intent to come back and play with it later, only when I reloaded the game, the planets were back in their original places, all of that work for nothing. Is this an optional thing? did I run into a bug? What's going on here?
-
EDIT After all that work, Hyperedit reverted the planets on me. Until I figure out what happened and how to fix it, this project is dead in the water. By Jove! I've been gone for a while, but now I've finally got the time to make Kerbal creations again, and this time with much better software. So I was thinking to myself last night, I want to do Kerbal stuff again, but all the basics have already been done. There have been missions to every planet and all the habitable ones have been colonized. People have made massive space stations and all sorts of other wonders, so how can I set mine apart? Then it hit me, "What if Kerbin was one of Jool's moons?" So to that end, I've begun work on "BY JOVE!" a Jovian alternate reality series in which Jeb has accidentally-- wait, why am I giving you spoilers? Here's the save file, extract it and put the folder in your saves folder. The planets should be rearranged and waiting for you when you begin! Jovian System save file Features: A geosynchronous moon directly over KSC (I want it to be tidally locked, if anybody knows how to do that please contact me) Use of Lagrange points Use of orbital inclinations Use of eccentricity Every attempt made at preventing overlapping SOI's Dres and Eeloo are finally able to play with the cool planets The monoliths and archaeological sites will come into play in the series The new Jovian system: Outer planets Inner planets Eve has stolen the Mun and run away to a higher orbit with it, but Minmus is now in geosynchronous orbit directly over KSC-1. Also, Eve got a break from that eye-straining purple. It'll still look the same color in map view, but when you land there it'll be a much softer desert yellow. Duna kept Ike and Dres now has Pol orbiting it pretty closely. Both of the two planets are now in synched and offset orbits from one another Laythe now has playmates, Gilly and Bop are enjoying their new homes in her L4 and L5 Lagrange points Moho is in a low and fast orbit around Jool, where gravitational shearing would explain the intense heat there Tylo and Vall are in their own little orbits doing their own little things. Vall because nobody wants to disturb Stonehenge, and Tylo because as everybody knows, you can't do a thing with Tylo. That just leaves Eeloo. The consummate vagabond is still off on her own little thing, but the icy ball now has a cometary orbit I'm wide open to suggestions, so any ideas you've got feel free to throw them at me, they're very likely to be included. ~Tanya Sapien
-
yousir, have no concept of the effects of varying wattages and voltages on DC current. It's entirely possible to force an electric charge from one battery into another using the right setup, however there would be entropy in the system due to heat losses which this game fails to take into consideration. However even if one were to assume the potential energy of the electrons in the material must remain even across all connected units, it would still be possible to balance them out. In essence; if the pod's completely dead, but the reserve has juice, then you would still be able to move 50% of the power to the pod so they each have half a charge (although the batteries usually have more juice than the pods, so it would actually be like 75% or something since the meter for the pod would move up faster than the meter for the battery would move down)
-
I'm currently working on a project which is planned to be the reboot for DRAkTEC and my 'Foxxing Around' youtube series, however I'm needing a few very exact numbers and finding them on my own has been being difficult to no end. Right now, I'm trying to park Gilly in a geosynchronous and tidally locked orbit around Kerbin using Hyperedit (don't ask.) but I'm having issues getting it exact. Using 2868.75Km causes drift. I punched in the radius of Kerbin thinking Hyperedit was calculating from core instead of surface, but that didn't work either. By playing around with time warp then continually resetting the game timer to zero and punching in narrower and narrower adjustments I managed to fine tune it with a long, arbitrarily complex set of numbers, but then when I tried moving the next planet on my list I came back to it and the tiny bugger was nearly 45 degrees off position. And this is just the orbit, I haven't tried making it tidally locked yet. Any help would be absolutely invaluable and would get annotation in the videos when they're done.
-
Try using the coordinate logger function. Put the module on a vehicle capable of reaching the ocean by itself, then launch it with the water launch option deactivated. get the vehicle to a nice spot in the water, park it, then right click the module and tell it to save the coordinates. Unless I misunderstand how the module works, it should store those as your new launch coordinates. (Don't forget to move the scout before launching anything!)
-
I installed the newest FS build then booted up the game to do some diagnostics, and this is what I've gathered: The bug occurs immediately upon the vehicle being visible on the runway, before physics has been loaded in. It occurs even on a fresh game with the cockpit being the only vehicle component. The framerate drops come in chunks, causing the game to run smoothly for about 0.3 seconds, then lock up for about 0.3, cycling between the two. Going into IVA does not change the issue in any way, however looking at the screens shows that they update the memory fetching by exactly 8KB with every cycle of locking and playing smoothly. Affected cockpits: FS20C Attack Helicopter Cockpit MK2 Cockpit (From B9 Aerospace, features Firespitter OS v4.0) I had the debug toolbar open while testing this, and got no errors while on the runway, however when reverting to the hangar, I get a mass of messages like this: [Log]: [mecanim]: BindSkeleton: cannot find Transform 'Lower_Assembly' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'Satellite_Dish' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'satellite_dish_props1' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'satellite_dish_props2' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'lower_assembly_props_hvac' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'lower_assembly_props_pipes' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'Component_281_1' [Log]: [mecanim]: BindSkeleton: cannot find Transform 'Group1' The 'group' error messages went all the way from 'Group1' to 'Group39' I don't think it's the firespitter OS itself that's causing the issue, as I tested the 'S2 Cockpit' from B9 Aerospace, which also features your guidance system and it runs smooth as silk for me.
-
I'm not sure if this has been asked before in this thread, but 59 pages is a lot to sift through for a maybe, I have a potential bug to report. The parts work fine, they're great and I love them, but I have a problem with some of your cockpits. Certain cockpits which contain the Firespitter OS guidance aid cause an extreme framerate drop on my computer any time they're loaded into the game. I'm sure it's not the mesh itself because there's no framerate drop in the hangar nor in the time it's preparing on the runway, it's only after the physics load in that it has the issue. Additionally, any time I encounter this framerate drop, the OS in the cockpit takes an inordinate amount of time to fetch the memory, taking upwards of 45 seconds to boot. I have MechJeb2, B9 Aerospace, ISA Mapsat, Kethane, and Extraplanetary Launchpads installed. However, the issue persists even if no parts from the other mods are currently loaded in. If this is something I've done wrong I'd like to know what I did so I can fix it. Otherwise this can be considered the lamentations of an underpowered computer
-
Disregard my previous post. Also, my friends are way too nerdy. I gave the SSTV files to a friend, he not only discovered that the handshake was at the wrong speed, but re-calibrated and then stitched them for me >..< here's the speed-corrected and stitched file, the codec is B/W 12 sstv.ogg Cudos to the mod dev for the images, but they may need to be tweaked slightly, I used two separate clients and neither could lock onto the handshake. If not for my friend using SSTV streams way too often, I wouldn't even have been able to view them.
-
You never listed what codec you used for the SSTV images! I ran them through my decoder and I keep getting slanted and distorted images. nothing I do can clean them up. I've used SSTV before with great success, and I ran them through two seperate clients, so I know it's not a problem with the software itself. So far the best I've gotten was using the Scottie2 codec and that still came out with RGB bleed. any help here?
-
[1.2] Procedural Fairings 3.20 (November 8)
Tanya Sapien replied to e-dog's topic in KSP1 Mod Releases
note to self: tackle e-dog to the ground and make out with him for no less than thirty uninterrupted seconds, because this is THE BEST THING SINCE SLICED ROCKETS!! -
personally I love the new overlay, and the modified main menu is pure liquid eye candy to me. What's so unappealing about it anyways? I mean; you install Kethane because you want to take your engineering to the next level, right? and this geodesic grid is the perfect expression of engineering progress. It's a sexy new look for a dull menu we've all stared at hundreds of times. If change is so frightening to you then stay on Kerbin, I'll be on Duna when you figure out how to enjoy science.
-
Okay I hope I'm not the only one thinking this, but if I am then it's something I think others should be thinking about as well. Between Kethane, H.O.M.E. And the Extraplanetary launchpads mod that just came out, we now have all the utilities needed for complete colonization of the stars. All that remains is duct taping them together Kethane allows us to create all fuels we need. In the case of a long-term base, the atmospheric miner in H.O.M.E. Lets us have a functionally infinite supply of liquid fuel and oxidizer on atmospheric planets in addition to habitation for our kerbals. This means we can gas up and crew up anywhere with kethane deposits and/or an atmosphere. The new Extraplanetary Launchpads mod allows us to harvest ore in the same manner as kethane (actually exactly the same as kethane) to the end of processing it into metal and assembling ships from it. This means that leapfrogging and colonization is now a potential reality. At this point in time, the Extraplanetary Launchpads are incompatible with Kethane because of a shared .dll file, but that's a simple matter of adding a secondary mineral spawn attribute to the generator and/or creating a parallel resource. All that remains to be done is for somebody to work on crosspeak between them and to put some spit and polish on the meshes (because lets face it, Launchpads still needs some heavy work). Once launchpads and kethane can crossspeak, a line of code to probe fuel capacities of the vehicle being spawned in could be added, requiring that you have enough processed fuels or raw kethane to fuel it up before you're allowed to spawn it in. Or, a more ambitious and undoubtedly more complex method would be that if you don't have enough fuel, it spawns in only partially filled. Though, due to obvious problems with manually setting resource quantities on the fly, that would be more trouble than it's worth. I've already been tinkering on my own install and I've had marginal success with combining these three mods, but I think if the original creators of Kethane were to get their hands into this, it would be the Midas touch it needs. As an added note, and what I think is the most pivotal point of my entire proposal, the ability to spawn ships in on other planets and moons is still very low on Squad's to-do list, meaning: A Kethane update of this fashion would NOT become repugnant in an update that adds vanilla mining! This means working on Kethane updates has purpose again! So mod devs, programmers, countrymen, please, the Kerbals need you, spare the time and help them get closer to the stars today!
-
The TRiKE orbital shuttle is a highly versatile if not eye-pleasing vehicle. Features: Seating for nine. Landing lights. Internal RTG powerplant. Enough ÃŽâ€v for at least three trips from orbit to the surface on the Mun and back (up to five if using an Oberth suicide burn) RCS control for docking. Skycrane functionality. Kerbin soft landing capability, to function as an escape pod for Jeb's team plus six lucky survivors in the quite likely event of a catastrophic mun base explosion. thanks to a fullbody suspension system, it can survive landing at upwards of 15m/s with no structural damage. TRiKE.CRAFT file Instructions for safe boarding while landed: Board from the bottom seats upwards. The first kerbal on should stand on the landing gear, the second should stand on the face of the first, and the third should stand on the face of the second while boarding. Don't worry, Kerbals are quite stackable. Mass: 21.35 TWR@Kerbin: 0.85 (exceeds 1.00 at ~3/4 fuel supply remaining) Part Count: 58 ÃŽâ€v: 4960m/s without passengers Can liftoff on the Mun at only 20% throttle. orbital altitude only using a 5th of a tank. Soft landing on kerbin. Jeb approved.
-
casting a vote here, "Roc SSTO MKX variant a" by TheFod looks epic with a side of fries. The one and only thing I could say in terms of improvement is to add some tail gear for vertical landings on Mun and Minimus. The added weight would reduce fuel efficiency a bit, but you can't put a price on smooth landings.
-
That sounds like a good idea. There's a section of code the jet engines use which would work perfect for it. I'm just not too thrilled with the whole ten minutes thing. maybe three minutes would be better, and a throttle down delay too. the only way to instantly cut the throttle would be to furl the sails. this of course would leave us with the problem of tying sail deployment to engine activation. as it stands in the pack I threw together, they're separate modules. any coders who want to take a whack at it?