Jump to content

CaribouGone

Members
  • Posts

    73
  • Joined

  • Last visited

Posts posted by CaribouGone

  1. Yeah, once attached to the asteroid it's all considered to be one craft so the main module is filled. The drills also get most of their power from the main module.

    If I was playing with KAS then I'd probably add fuel lines just to make it look better, but that wouldn't be needed for functionality.

    sweet, i figured as much. time to go grab some 'riods!

  2. I just want to say how much I'm enjoying asteroid capture missions now! Really didn't like them before, kinda felt like Sisyphus (pushing his bolder up a hill), but now with mining it's totally changed. I used to find that if I managed to get one back to orbit, it was only just and never with enough dV to maneuver it to a useful parking orbit. Now I can get fuel out of them I can bring them back to a nice neat parking orbit, and still have fuel to mine.

    The tug I have is totally self sustaining and has now brought back 3 class C's, 1 class E and 1 class A back to LKO and the asteroids have provided all the fuel it needs to just keep on doing that indefinitely;

    http://i.imgur.com/mCN3IT3l.jpg

    I did go a bit over the top with the system for extracting ore from them once in LKO, a central-control/ore silo section with 4 deployable drill modules that unpack;

    http://i.imgur.com/1JkOxszm.jpghttp://i.imgur.com/rMaFBaIm.jpg

    http://i.imgur.com/LMIjOZNl.jpg

    The arm that the drills attach to repositions to form a connection point for large tankers;

    Wow.

    because the mining units are all attached to the same 'craft,' does the ore feed into the converter properly despite not appearing to be connected?

  3. another factor to consider is what % of the asteroid's mass is ore.

    unfortunately, you won't know that till you're there.

    from what i understand, even a high % class A can give you more fuel than a mediocre D or E.

    while 9 mk3 is a lot of fuel, you may have grabbed a dud asteroid.

    also, towing is often easier than pushing.

  4. Does the part break/explode? : My guess is to raise the value partBreakForce, staticBreakForce, breakingForce or breakingTorque

    nothing breaks, the hooks just pull loose. i tried raising part&static BreakForce to 999. it didn't help. there's also breakForce under KASModulePort. do you know what that does?

    also, it was a class d. it might actually work if i went after something reasonable.

  5. hellion, once you decouple the craft from the driver, switch back to the driver with [ or ]

    when you decouple, control is probably going to the "projectile"

    also, make sure you have a command part on the mass driver, or it will be unusable.

    as i said in the post right before your's, the driver doesn't seem to do anything to kerbals.

    Northstar1989, i may have figured out the acceleration problem i've been rambling about.

    rather than deal with acceleration and time, velocity can be found through kinetic energy.

    this site describes force (on the projectile) as a function of distance from the magnet. the integral of that function is in units of Newton-meters (equivalent to joules).

    once that number is found, just plug into gif.latex?%5Cfrac%7B1%7D%7B2%7Dmv%5E%7B2%7D and solve for v (this will be velocity gained, in case you're already moving).

    the integral in our case should be easy, because the force-penetration curve will be a horizontal line. the distance over which we integrate will be the length of the ship, plus the width of the stack (and any gap between the ship and driver; i'll try to keep that to a minimum once i get motivated to test this theory).

    i figured this out assuming only one mass driver unit. if all stacks are at the same power level, i think you should be able to just add the energy gained from each unit together (or increase the range of the integration).

    again, i haven't tested this yet. i've been distracted by games that don't require knowledge of physics and math. but according to that site, these calculations work in real life. i'll post some pictures and numbers soon enough.

  6. i'd like to see a tidally locked body large enough to allow geostationary orbit.

    as a planet, it would allow permanent darkness, which is cool if you really like flood-lights.

    as a moon, it would just look neat.

    like Nothalogh suggested above, a binary system with their barycentre lying between the two would be awesome. mutual tidal locking like Pluto-Charon would be fun, especially if they were absurdly close together. (SOI's only a few km apart?) if they had considerable orbital speed around the barycentre, landing would be an interesting challenge.

    if they both had atmospheres you could fly figure 8's with a jet-plane!

    as for your gas giant picture, Thomas988, i like it. the colors are a little dark, but i think it looks realistic. maybe rings?

  7. The mass driver exerts force on the spacecraft as long as it is passing through the ring sections.

    Ah ha! that explains a lot, actually. i had assumed the forces were being handled in a much more simplistic way, no offense.

    in fact, i feel a little dumb now. :blush:

    with all else held equal, doesn't that mean a longer ship will receive more acceleration, as it would spend more time passing through the driver? i'm gonna have to make a 200m flying needle and test this.

    There are calculations that can be run to predict exit velocity based on the mass of a craft and the force exerted on it (and the distance those forces are exerted over)

    Uh oh, that smells like calculus. surely NASA has some equations laying around that could be borrowed. i'll poke around and see if i cant find something.

    hmmm... that would be a lot of info to cram into a right-click menu as well. this might end up being a job for the people that make those tools and calculators.

    do all the units need to be attached directly to one another? or do they just need to be part of the same ship? obviously, using the main center stack node would cause problems. but, with clever use of radial attachments, could i dock several short stacks together and have them function as one driver?

    another issue i foresee (an in-game engineering issue, not an issue with your mod) is maintaining stability while traversing excessively long drivers. if what i asked above does work, the lazor systems mod could provide a solution. (have diametrically opposed repuslor/tractor lazers every few units to push the craft toward the center of the drive) if not, even a few set up at the "mouth" of the driver would probably work.

    but, one day in the future, it would be neat if the driver could provide some sort of stabilization itself. maybe something could be borrowed from the docking-port "magnets"?

    also, the mass driver doesn't accelerate EVA'd kerbals. ;.;

  8. that g rule of thumb is useful. i found acceleration through F=ma, but never thought to put it in terms of g.

    out of curiosity, a kerbin g is also 9.81 m/s^2. right?

    but the problem still remains: if i accelerate at 50m/s^2, for one second, my final velocity should be about 50m/s faster, right?

    but if i accelerate at 50m/s^2 for some unknown fraction of a second, my final velocity is a number i can't calculate.

    if i'm remembering physics class correctly (i'm sure i'm not), this whole issue is due to the fact that acceleration found through F=ma is instantaneous, which is mostly useless info unless it can be treated as constant and exist for period of time.

    i was never suggesting power be tied to the ship's mass. the available acceleration should definitely depend the ratio of driver power to craft mass. it would be neat if the driver could magically know the target's mass, and tell us power in terms of g's, relative to the ship.

    also, while it wouldn't allow for nearly as precise control, tying the power of all units together, so that only one menu would need to be tweaked would save a lot of time.

    while i definitely respect trying to maintain realism and abide by the laws of physics, there's a fine balance between realism, and gameplay. i know what i'm suggesting is not at all how a coil-gun would work. but its well within the means of the ksp engine to apply force over time. that is basically what a rocket does, after all.

    the idea behind my suggestion was that 1: a set unit of time would make estimating change in velocity from F=ma much easier. (in it were 1 sec, (F/m)=change in V)

    and 2: if ksp wants things to behave like rockets, why not play along? while i know very little about computing, i got the feeling that the massive lag and kraken attacks were the result of instantaneous forces freaking the physics engine out.

    to me, sacrificing a bit of realism to make the game behave properly is worth it. besides, the end result is the same: a big machine that accelerates things absurdly fast. i don't think many people are going to care if they were secretly under thrust a moment longer than they should have been.

    now, don't get me wrong, this mod is really cool as is. the parts look good; its fun to use; and almost free dV is always welcome. but calculating final-velocity needs to be easier before this joins my always-install list.

  9. poked around in the cfg's a bit. couldn't figure anything out, so i figured i should build a rocket in stead. :P

    making those parts shouldn't be too hard, but i probably don't need to go messing with anything else until i know what i'm doing. besides, the way i play, 1.0 will be out before any asteroids run out of goods.

    but thanks for all the advice. honestly, its games, and communities, like this that make me want to learn how to write code and make mods.

    so, one last round of questions: what are the preferred programs for modelling/textures/fx? compiling/decompiling dll's?

    Thanks!

  10. Thanks, Ricardo79!

    i primarily play sandbox mode, so recovering Rare/Exotic MKS materials for funds is pointless for me. I want to make a converter that turns them into building/refueling materials.

    i probably know the answer to these next questions, but its worth saying aloud in case anyone else is wondering too:

    the amount/s refers to units, not mass? to make a separate part, the model, texture, and config need to have the same name (as well as the config containing all the standard part info)? (i'll be "making" parts through a lot of copy&paste)

    questions i definitely don't know the answer to:

    is the rate of depletion configurable? i'd like the resources to last as long as possible. (i don't want my sandbox to run out of sand!)

    and, completely unrelated to this mod, do more asteroids spawn eventually?

    thanks again for the help!

    and, Roverdude: Thanks for all your hard work, you've made ksp at least 2.3 times more awesome!

  11. Hey!

    just a few questions:

    1) i use karbonite and mks (and, thus Regolith). these implement asteroid resources? i don't need AMT/ART, right?

    2) where can i find the lazers/claws? were these moved the AMT or ART?

    3) is resource conversion mainly handled with .cfg's? i'd like to make my own converter, but i know nothing about writing code. if it requires compiling a .dll, its likely beyond my abilities.

    Thanks!

  12. Hey!

    i like this mod so far, but i ran into many of the same issues people reported earlier: drivers exploding, ships vanishing, and lots of lag.

    but i had an idea. it sounds like a lot of the problems stem from forces acting (and ending) faster than the physics engine can handle. so, rather than applying all the force at once, would it possible to spread the thrust over the course of several seconds? that way, you could gradually increase the acceleration during the first second, similar to throttling up a rocket. not only will it provide a smoother ride for Jeb, it will hopefully cut down on the lag upon firing the driver. also, it should guarantee that there is thrust being applied to the mass driver (if the lack of recoil was indeed from things happening too fast to be calculated).

    having a known duration for the thrust will help with estimating our resultant velocity, as well.

    speaking of estimation, tweaking the max thrust value to some easy number would be nice too. 11,760 is a weird number. an even ten or twelve thousand would make math a lot easier.

  13. Roverdude, to be clear, the config edit did exactly what it should; i can warp at sea level just fine. its just that the failsafe was hiding this other behavior. it could be tied in the collapsing bubble animation, because i don't get the collapsing bubble anymore. thanks for looking into it.

    Halaeon: thanks for the advice, i'll try some non-zero numbers to see if i can't find something both comfortable and error free.

    trapping gamma waves and high energy particles is definitely a concern. some physicist postulated the amount of stuff trapped during an interstellar warp would be capable of destroying planets upon release.

    concering atmospheric warps, this guy thinks they have already happened, naturally no less. honestly, his theories sounded a little wacky at face value, but the more i read, the more i was convinced.

    sure, the sample of atmosphere brought along to space would expand, but the pressure would drop just as quickly. the forces exerted on the ship would be no where near the punishment suffered a traditional during re-entry.

    doing the opposite might cause problems: warping from a space into an atmosphere. upon exiting warp, gases would rush in to fill the vacuum "brought along" by the bubble. the turbulence caused by that might be unpleasant. but again, how would it compare to the stresses aircraft and spacecraft already deal with?

    barely related: Dennis Hopper blew himself up with dynamite in 1983. unscathed! because the explosives were arranged symmetrically around him, the forces inward cancelled each other out, creating a little bubble of safe space.

  14. Hi!

    so, i changed the .cfg so that minAltitude=0, so i can warp in the atmosphere.

    but now, when i launch a ship, the drive starts activated, no matter how the staging is set up.

    i've also noticed that, with the altitude fail safe in place, upon launch, you can see a bubble collapsing, similar to trying to activating the drive below minimum altitude.

    so it would seem that the "starting active" behavior is already present, but the fail safe shuts it down before causing problems.

    i don't think this is a bug per se; this mod works just as advertised, and my ksp install is very stable, with and without mods.

    still, this is something i'd like to change. hopefully, its as simple as another .cfg edit.

    either way, thanks for yet another great mod, roverdude!

×
×
  • Create New...