JavaProphet

@maltesh I'm talking about using this purely in space. No earth. Perhaps on earth, but it would need some pressure difference. A pressure battery. You use a pressure difference from anything to make a fluid spin, from there, stick a generator on the spinning fluid, and wallah. You lose fluid to the vacuum, but in space, this wouldn't reduce efficiency. In say, a battery, it would slowly fill with the fluid, and equalize in pressure, losing efficiency.

So, I was sipping my mountain dew, and I discovered something fun. The pressure of my sucking was causing it to rotate in the cup. I figure it was having more come towards to low pressure than there was available to enter my mouth. Could this rotation be harnessed, say in space, to generate energy from the vacuum? My concern is that space has no energy, so where is it coming from? Space sucks. I figure the energy is coming from the pressure of the water, which would be stored in the water on earth. Water battery? It could be done with any fluid, theoretically. Will it work for power generation?

So, I was thinking about it earlier, and I came up with an idea. What if it was just one massive particle? Why that? If a neutron star just kept collapsing, wouldn't all the neutrons just fuse into one big mega-neutron (perhaps the quarks are bonding, or becoming neutron-star like)? I, by no means, have any idea if that is possible, but I wanted to get your guys' thoughts on it.

I made a 2D physics engine, and with it my own vector math library. Vector addition takes the number of computations for scalar addition * number of dimensions. You would only reduce poll density for the trajectory, otherwise you need the same poll density, or your going to have saving/loading issues(if you keep up the abstract time step idea). If you didn't base where the craft is based on time, but rather on a static coordinate plane(which is a problem in itself), and a velocity vector, you wouldn't have to worry about save/load sync. Some calculation math for 100000x warp: Assume we need 50(ships)*n(in this example, 10)*100000(warp) calculations. As for a 'compression', you could reduce poll density for time warp, but this would either need to be recorded, or you would need to discard the time step thing. Each calculation would be calculating gravity (mass*distance*grav_contstant, or 6 cycles according to Kermunist) = 6 cycles. Accessing an array for an arbitrary entry, would take an average of 5 cycles per access. 5 * 10 = 50 cycles (for cache) So, my bet is that real-time-calc is better for anything with more than 3 bodies. (1.5 * 3 = 4.5 cycles) For n = number of planets: So, 6 cycles per body to get the gravity speed. 6n cycles. Then, you need to subtract any vessels position from all planets positions, and then multiply by that gravity for each body(to get the gravity vector). So, 3n cycles + 9n(? multiplication of vectors, not going to think about too critically right now) cycles = 12n cycles to get the gravity vector. So now we have 18n cycles. NOTE* at this point, Kermunist's post about the CPU cycles for these ops may not be too accurate for precision floating point ops. We may use a cache or perhaps just more cycles than I'm calculating. I don't work with processor-level stuff much. Now we need to add up all of those vectors, so 3n more cycles to get the final vector. A total of 21 * number of planet CPU cycles per ship per calculation. So for 50 ships, 10 planets, and 100000x warp, we would need (assuming 1 step/calculation/warp) 50*10*100000*21*10 CPU cycles per second, or: 10.5 billion CPU cycles, 10.5 GHz of processor power. Before you say, we don't have much past 4, we all run an average of 6 cores(or so), so we have 24 GHz available(potentially). It's not impossibly on your typical gaming computer, but it'd be considerable. However, that is 100000x warp. This does not take into account how we would be dealing with floating point ops, so it could be much higher. EDIT: I do now see you would need some trig in order to get the actual force vector + you need to apply it as a force and calculate velocity. The real number is probably 4 times higher or more.

1) I completely agree with this. I'm not saying I want n-body physics, but rather curious about it. 2) I'm talk about a per-body cache. May not be necessary, depends on the complexity of the gravity calculation. I'll assume I'm missing some important fact about gravity. 3) For on-rails simulation, you could just have the sim-frame thread go ahead of time to calculate this out. For non-on-rails, you would use the same sim-thread. You could reduce the poll-density as the trajectory grew longer. I'll take a look at that thread, thanks.

I've read some posts here about adding n-body physics to the game, and people seem to believe that it's not algorithmically complex, but very CPU intensive? Where does this CPU intensiveness come from? As a hobby programmer, assuming you have your calculation for gravity for any given celestial body, for any given craft(in this case), would you not just calculate the gravity for the other bodies, and add the vectors, to get a final gravity vector? I understand you'd be getting into some high decimal point calculations(easily thousands of zeroes from my first guess), but there are a lot of optimization techniques to be had. First thing that comes to mind: Cache the values, radially, for a certain distance from each body, exponentially increasing to infinity(for efficiency with inverse-square). For instance 0-10000 has 9.81g(kerbin), 10000-100000 has 9.8g(example), so on and so forth. A one-time calculation for each distance. Since it's a game, we don't need insane to the power of -10000 accuracy. I might just be a moron, but what is computationally slow about any of this? For those interested, the original thread another user posted in the Suggestions section was closed, so I didn't reply to it. EDIT: I did more research, and people also say on-rails is impossible for this. From what I know, KSP does on-rails by getting position based on time, rather than frame-by-frame. If you could do subframes, or have your gameframe, then a simulation-frame, in which you did a pure lookup for the gravity for each body on your object, added, and then calculated a force vector, treated everything(crafts) as points rather than complex crafts(part-part physics), I don't see so much CPU lag involved. This might require a rework of savegames to instead specify current location and velocity rather than orbit and time, although I personally wouldn't expect/want this in the game for gameplay reasons.

My 2 cents: To stop the tangent(?) force from the release of the payload, you would need to release something of equal mass at the same speed in the opposite direction, or on the other side of the circle. To charge the 'wheel', just use a generic motor(one helluva strong one), and reverse the charge direction to slow down instead. As for the amount of energy required, I'll do the math I know. A one ton payload requires two tons to be launched in each direction(you'd need a strong wheel, as so the forces don't rip it in pieces). Say you wanted to launched this one-ton payload at... 10 KM/s relative to the wheel. Since the velocity of one the objects is our angular velocity, we need to get a net torque on the wheel of some large amount(torque is always confusing for me, we need a math guy to analyze this better). As mentioned earlier, the other part of the launching craft would rotate opposite. How do we fix this? I saw in an Artificial Gravity video by HOCGaming a while back, that you can have a wheel on the opposite side in the opposite direction. You'd need the same mass for the payloads. You would likely want the wheels to be slightly tilted back, as so the two forward payloads DO NOT collide, but the two behind do(?). Orbital debris would be an issue regardless. As for power, in modern technology, perhaps a large solar field? The amount of energy we need I don't feel(could be wrong), is the main issue, but the strength of the spinning wheels. The forces on those things would be twice what you have for torque, just trying to rip those things in half. We'd need some kind of inward force, or just a super-strong material(Carbon Nano-Fiber?) to keep the contraption together.

It is getting lift, kind of. It helps with yaw stability, the theory is just a really big rudder = hard to yaw in atmosphere = good for one winged craft.

So, I thought it was about time I used my increasing knowledge of physics to create a one-winged plane. Imgur Album: Or you can watch the stream clip in which I built and flew it: http://www.twitch.tv/maximumtech/b/509398932 Or just the flight: http://www.twitch.tv/maximumtech/c/3850446 Unfortunately, I think I killed Jeb in my Passenger Jet trials. Now let's see if I can make it properly landable.

I couldn't find anything on automating, say, moving of joints and ligaments that I made with kOS? I just made this walker rover thing that is stable without SAS, but it is very complicated to use... and I feel a little kOS script could change that. Anyone have some ideas as to how I would do this? I've also began the same ambition as to make a relatively large human model, with muscles and such. It will be unpilotable without kOS.

Visit me at: http://www.twitch.tv/maximumtech/ I'm currently on a mining operation on Minmus, where I must send ONLY one ship to be able to mine and refine kethane and ore into functional rockets from the surface(and/or orbit) of Minmus.

All I added were pipes, no inter-craft struts, in fact no struts in the entire base. I think it had something to do with a quickload, and the center of mass. I had did my first quickload during that landing.

I connected about 15ish landers together, while I was in the process of landing my 16th or so, they flew up into the air(connected with pipes), and ultimately broke. I noticed the landing carriage on one seemed to be the culprit, as it was missing. I assume it was that I had sent an empty orange tank, and transferred all of the extra fuel over there, messing with my CoM. This was just game breaking for me, I could have fixed it, but a majority of the landers were broken, each launch taking about 30 min. I have a video recording here: http://www.twitch.tv/maximumtech/b/501941127 Highlight @ 53:30 - 55:00. I think I want to try the base again, except this time with wider modules, centered in a lake(on minmus), and with a tension multi-lander landing system, to make transit faster. Anyone know what caused the issue so I can avoid it?

Well, instead of rewriting all of that code, why not just make it a multiple-root system, and implement a custom SOI transfer node. What if the planet is in an orbit sufficient as to where it would be escape velocity? As in at the apoapse, you would be traveling < 0 m/s?

Just a thought, Krag, for the planets outside of Kerbol's orbit, since planets have set in stone orbits can't you have them outside the SOI of the sun, and have their velocity set to 0 m/s?

I'm currently playing with the following mods: EditorExtensions Engineer EnhancedNavBall Extraplanetary Launchpads Firespitter KAS Kethane KW Rocketry NovaPunch RealChute I'm hoping to scan, land, and mine on Duna and Ike today, if not tomorrow. Hop on my stream at: http://www.twitch.tv/maximumtech