JaredTheDragon

This looks great! But I'm curious why you don't have the KSP version number in your title, for quick compatibility reference?

What version of KSP is this optimized for? It would be nice if you had that in the title, much like every other add-on here on the site.

It's actually unnecessary for physical reasons - chiefly, Einstein's Equivalence Principle. Acceleration is always, always caused by a continues bombardment of faster particles upon a slower particle or substance - except in the case of gravity, which is an acceleration caused by... Nobody knows. Lots of theories, some great, some garbage, but nobody knows. But THRUST is an acceleration caused by the exploding particles of the fuel striking the front (top) of the combustion chamber. They then bounce back or down and exit the chamber, in various ways of course depending on the engine. Their exhaust doesn't CAUSE thrust, it is the RESULT of thrust. The thrust isn't pointing backwards or down, it's pointing forwards (or up). That's the vector you have to follow. Now a wing or fin behind the exhaust can cause DRAG, but drag is not thrust. Vectoring the thrust isn't just vectoring the exhaust, it's vectoring the forward-moving exploding substance that is CAUSING the thrust. To sum up, the angle of the exhaust isn't the same thing as thrust at all. Anything that happens outside the engine doesn't affect what's in front or above it - that's action-at-a-distance, and is not physics. There are no actions at a distance in physics; there are no attractions, only repulsions. Even magnetism is a local lesser repulsion; it's not actually an attraction. All perceived attractions come from fields of less repulsion, relative to the local environment. All motion and therefore energy is caused by direct collision between masses, gravity aside. The ship doesn't feel what happens AFTER its engines, since that's behind it already. All thrust happens INSIDE the engines, not behind them.

I really don't know. I'll try it tonight and see, but it shouldn't be a problem really. You'd still want to line up properly it seems like.

I mean is Kerbol considered a low-gravity body? There are no places in the system I haven't used it, that I can think of. Sure, they get the dynamics wrong a bit (there's no Charge Field in the game, and Pi is wrong) but for the most part it's pretty good. Still better than every other game ever made, you know?

I've never had a problem docking with MechJeb really, that I myself didn't cause. Still playing 1.45 here however so I couldn't say for newer versions. It's not always flawless but once you try it a few times, you should do fine.

I mean these are cool to have, glad you made them, but your analysis of physics is just beautiful in its chimerity. But what VERSION of KSP did you compile this for? You need to indicate it in the title and the body of the post. Every other mod or add-on here does this and you could at least make some effort here. But mostly, this isn't how an E/M ("Em" ) drive works, or any other drive. Electromagnetism isn't something from nothing, it's photons pushing ions and larger particles, by definition. While this mod is cool and I have absolutely no problems with you making it, you might take a moment to do a cursory study of electromagnetism and ask yourself, "What IS electricity? What IS magnetism?" Currently, your answers are wrong but very cute.

This is yet another example of "going the cheap route" to design something that shouldn't be done cheaply. Unity is what it is - a basic game development engine. It was never intended to replace or compete with CryEngine or Frostbite, much less Unreal. When KSP began, however, the cost to license Unreal was also unreal, so Squad chose to go with a free engine that at least let them get the game up and running rapidly and still allowed them to take a paycheck. Unreal has since changed their pricing scheme, but unless Squad were to hand off the project to another team with more Unreal experience and prep KSP 2.0 for Unreal instead, it's just not going to happen. Cases in point: Subnautica vs. Everspace. Subnautica is a great game so far, a huge underwater landscape several square KM in size and 1KM in depth, give or take. It's the best of its kind - but is still a Unity game. It stutters everywhere, even on the best machines. The graphics aren't great. The water is nice enough and has come a long way, but doesn't behave much like a liquid. Then you have Everspace, on the Unreal engine. It's even bigger than Subnautica, as its in space, and has roughly the entire volume of Subnautica in every level - which are procedurally generated and different every time you play. It's beautiful. It's smooth as silk, even on lower-end machines. The controls are not only perfect but genre-redefining. It's everything Subnautica isn't. I don't see KSP switching engines at this point, so what we can hope for is ANOTHER game, similar, but using the Big Kid engine instead. If KSP continues to garner such fan support, I have no doubt a Big Kid game in the same vein would get even more support. And Unreal supports GPU-based physics far, far better than Unity.

There are several decent GPU-based physics engines that could vastly improve KSP, but implementing them inside Unity is probably a massive task and very tedious. KSP gets most physics right, or close enough for the game's sake. PhysX would mean only Nvidia-GPU users would benefit, and it does have its benefits but also its flaws. Bullet is probably just too slow - usually firing up a blank scene takes much longer than PhysX, for example. You'd really feel that in-game. I use GPU-physics all the time in Maya but you can't directly compare that to Unity. Not even the same universe, really. A better comparison would be Universe Sandbox², which is a beautiful use of GPU physics but still only recreates a gravity field, not the unified gravity/charge field we experience in reality. For example, the elliptical orbits of the planets are hard-coded, not the dynamic gravity/charge orbits we have in real life. What I'd like to see someday is the Universe engine inside KSP. Along with the Planetbase engine. But hey, a dragon can dream, right?

Computationally and physically, radiation is simply photon emission. So to calculate the mass of these emissions is really straightforward, since it's just the charge field. You don't need to calculate the individual photons (and every computer combined still couldn't do so, anyway), and it doesn't need to be a particle system at all - though to be predictive accurately of course that would be preferable. But unattainable. Photons fall off inversely proportional to the square of the distance from the source, so it's really easy to crunch.

I feel like all this adds is an annoying chromatic abberation, as if it were trying to mimic 3D dual-channeling. GTX 660 here, Bulldozer rig @5GHz. It uses no RAM really, as it's a GPU effect. So it uses a little Vram but no system memory really. Do you have DX11-capable GPUs in your Mac?

Can re-re-reconfirm. HX parts are working great in 1.04, from the latest dev versions. Tweakscale also works great for the HX parts now, which makes for both easier ship-building and kickass spaceplanes. The best SSTOs I've built are HX. Sometimes I combine them with Impossible Innovations parts to isolate design flaws and in-orbit construction logistics, and also just because they're really fun together.

I've posted quite a few screenshots, some from .90, 1.02, and 1.04, of huge HX-based structures, ships, and stations. To connect HX structures, use the huge HX docking ports. I've had 1,500+ part motherships and such, but of course Unity 4 can't really handle it very well. Tips: - You need Action Groups Extended. You needed this anyway, but for big multi-ship structures it's critical to re-work your engine configurations in space. - If your HX docks seem a bit flimsy, drop down to the command center and then go back to your ship. Kerbal Joint Reinforcement is also helpful here. - With TweakScale, you can make awesome 5M (smaller than stock) HX ships and create them with much greater ease in the VAB and SPH. There's not really much benefit to using the full-size pieces, but of course they work the same.

The new deut' tank looks amazing! Good work. Original and clean, much nicer than before or even the big tank.

The dev port in Blowfish's signature is perfectly usable, already. There may be a few minor problems here and there, but I've been using it for weeks. The HX parts specifically work fine.

Indeed, "Download is disabled for this file." Perhaps try a better host? I'd love to give this a spin, used ENB in Skyrim extensively.

I think nobody would mind if you started a new thread for B9, and went ahead and "released" it for 1.04. This is really the only way to avoid the question every other day. As far as I can tell, everything works fine. The tuning and pricing and minutiae don't really impede the usage of the parts, from a user perspective anyway. Even a "BETA release for 1.04" would go a long way. And if it's incomplete, so what? The entire game is incomplete. Nothing to worry about there.

No problem! Impossible is your baby, of course you should do with it what you like. The new part is looking quite crisp, too. Keep it up!

A noble cause, for sure. But you're not alone here. If you need help, either modeling or texturing, just say the word. I run Maya for a living (arch/viz) and Photoshop mastery coincides with that. I just don't know the inner workings of Unity or KSP, or else I'd have retextured those small Deuterium tanks, myself, to look like the larger ones with the blue ambience. Regardless, your pieces are the perfect tool for eliminating engine/fuel issues when troubleshooting or focusing on other aspects of the game, and I love them to pieces! Thanks again.

Yep, B9 has those already, and they work pretty well. It would be nice to have a switch that set them apart from Monoprop (or Tritium) though, out of the box. If you do make something like that, maybe think of a way to use them without having to action-group every single one? Also, something I may have brought up before, but your small Deuterium tanks don't have the original textures on them, and haven't for quite some time. At least .90. I'd love it if you brought them back! The current gray ones are quite bland. These are the ones I'm talking about, the big one in the middle: Here's a few screens of my spaceplane from last night, probably not what you're looking for in terms of the front page / OP, but the gray main cylinder is how those Deuterium tanks look, in 1.04, for me. And on back to .90, as well. But the ship flies GREAT. Easily my fastest/best spaceplane in 1.04. (you can also see the B9 air-based RCS thrusters on the wingtips and other locations. Tritium reaction wheels, air-based RCS here, as a prototype. a real ship would also need Mono/Tritium RCS for space, obviously)

Excellent! I've been awaiting this mod, didn't want to bug you too much, but thank you. I'll be testing it out thoroughly tonight, and send you some screenshots too. The RealPlumes would be nice, too, when you find time. I'd also run the lighter PI version if you get to that, just for fun, and the air-RCS. But B9 already has a rather decent air-RCS setup, did you plan on doing it like that or something different? Not sure if you've used B9 much or in 1.04 (still in dev mode, there), but it's working great.

Any chance we can get an update for 1.04? I miss this mod, tremendously.

Since you appear to have a decent graphics card, you could try forcing KSP to run in DirectX-11. I've been doing this since .90, but in 1.04 it also works amazingly well and I'm able to pile on tons of mods before hitting the 3.7GB mark. You add this in by right-clicking your shortcut and selecting "Properties", then alter the target line: To be clear, a 32-bit application has addressing for 2^32 bytes of memory, which is of course 4,294,967,296. That's why any 32-bit OS or program can only use 4GB of memory. So moving up to a 64-bit application gives it 2^64 addresses for memory, or 18,446,744,073,709,551,616 bytes. As you can see, it's a huge difference, and the chief reason for moving to 64-bit operating systems and applications. Most programs cap this for obvious reasons, and I believe Win7 Ultimate topped out at 256GB for example. I'm running around 70 mods in 1.04, Win7 x64, and it rarely goes over 3.4GB of memory usage. The DirectX-11 mode is MUCH more efficient at purging memory and much more dynamic. Sure, the game still doesn't saturate the CPU or GPU properly, but those are limitations of Unity 4 and not KSP, as far as I know. For this reason, any decent gaming setup is overkill for KSP, since the game (for now) cannot utilize your resources fully, by a long shot.

I use Maya and Photoshop for a living doing architectural visualiztion (arch/vi), and also Rhino3D (my main modeler). If we need any work done on models, I'm down to help. Here's a rather basic spaceplane I was building from the ground up, for practice, as a game-related example:

I messaged you two updated .pngs, 512 and 1024 for forward-compatibility. Hope it helps.