AncientGammoner

Sorry guys, school year has started for me, which means a lot less time on my hands to create pretend rockets in a computer game and a lot more time spent learning how to create real rockets (<-- aerospace engineer). These days, the time I do spend on KSP usually involves actually playing the game lol. Jahulath, I'll send you the blender model if you like, not much else to the unity setup once you have that, just drag and drop textures. Dragon01, your suggestions are answered elsewhere in this thread, you can't stretch the top and bottom independently using the current method, it can only scale the model in x, y, z. Nathan, the zip I received only had a dll, not the code.

"Cheat" mod? It's just the Saturn V engine mod.

Noooope: Now that's an RCS thruster.

Based on your specifications, what else would it but this?

This is what I sent to sal_vager regarding this challenge and he asked me to post it here: I believe the cycler challenge is possible, very hard but possible. I did some calculations and a lot of testing using precisenode and I managed to get an orbit like this: It was just launched from the first crossing point with Kerbin on its orbit and notice that it encounters Duna then it encounters Kerbin again on the second crossing. The time until the Kerbin encounter is one synodic period, so when it encounters Kerbin again it will be lined up exactly how it was at launch, just like in a cycler orbit: As you can see you have to do a burn/gravity assist on that second encounter to rotate the orbit, and playing around with Kerbin gravity assists (without Duna encounter so you can see it better) I managed to get this: It shows a gravity assist that will alter the orbit exactly the right amount to restart the cycle. Approaching Kerbin looked like this: Now the resulting trajectory wasn't as perfect as the prediction (probably because you need a small correction burn to make it work like IRL), but I'm certain it's possible to do a cycler in KSP. Expanding on that, it looks the like 1 synodic period cycler (Aldrin Cycler) does require some burns in order to maintain (at least it does in real life for Earth-Mars). Here's an excerpt from a paper I was reading on a Mars transportation system: The real world has more complicated alignments and in depth physics so maybe it can be done in KSP without a burn, or maybe not I think it would be really interesting to see what people can come up with.

I never said RealFuels wasn't official, I said the modified configs for it aren't official. MFT is poorly written tbh. Nowhere does it store the multiplier its using to calculate basemass, nor does it give any indication to even know when it's using RealFuels instead of normal. Starwaster's "fix" is to store that information in my plugin... which I'm not exactly enthused about. First of all, it has to be overwritten since MF does not update basemass after the initial load, so it would have no way of knowing if the tank was stretched. I'm sorry but are you the author of MFT? Are the cfg files in your sig official releases? I agree, it's not really my obligation to make sure every mod is compatible with mine. Not sure why you're so incensed, you made your "fix". I'm perplexed at why are you still spamming this thread.

It's not a bug, the mod works fine with standard modular fuel tanks. RealFuels however is another story, because apparently there are multiple unofficial config files floating around that change various aspects of it. Clearly doing unofficial modding is going to affect other things including this mod and I can only base my support on the official release for obvious reasons.

This is intentional, you'll also notice the dry mass of the tank is lighter. I chose the wet to dry mass ratio and the overall density of each tank type based on the stock versions. Choosing a ratio for liquidfuel/oxidizer was easy because the ratio is nearly always 9:1 (except for the really tiny tanks), but choosing a ratio for things like pure liquidfuel was difficulty because you have a really dense jet fuel tank that has a high dry mass and also really light fuselages that have super low density. I tried to balance it as well as I could while not any parameter worse than stock, so I made pure liquidfuel have the 5:1 ratio of fuselages but denser than them closer to the dense cylindrical tank. For oxidizer I had no references, but clearly from the pure liquidfuel tanks it's more inefficient to store a propellant separately I chose a ratio of 6:1 for oxidizer. Its tanks also have a density greater than pure liquidfuel but less than liquidfuel/oxidizer combined.

You could change the rescaleFactor if you want it bigger or smaller. A plugin is probably feasible, I just went the simpler path with parts so I could whip it up quickly and it actually works pretty well. I'm just happy I can put flames on the side of a rocket (it does indeed make it go faster):

This is something I made for myself but I thought other people might have some use for it. Earlier today I was thinking "It sure would be nice to be able to write on the side of my vehicle". Not wanting to write yet another complicated plugin, I thought why not just keep it simple and make an ultra thin part with a transparent shader that surface attaches. A couple hours later... Why are they blue? Because I had to choose a color and I like blue, that's why. If you want to change it to black or alter the font or use the Greek alphabet or whatever, the textures are very easily editable pngs. I included a txt document on how to make your own, it's really simple, just plop the texture into the folder and change a few lines of text. You can put really anything you want on it, like this picture and flag I tested out (which are not included in the download to avoid any copyright issues): Download here How to use The decals can sometimes be tricky to attach or can jut out at odd angles when attached to curved walls. This is because collider meshes for most models are very simple and boxy. Use Shift + W,A,S,D,Q,E to fine tune the position of the decal on curved walls. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

This was just the result of me playing around with raycasting and unity particle effects, I don't really have plans to turn this into some kind of visual chatterer with a gui and everything lol. I did mess around with a version that if it hit a tank with a flammable fuel (liq/ox or mono) then there was a chance the tank would explode, but honestly that's just crazy since who wants to go to the trouble of launching stuff only to have it explode in orbit. I also created a 'meteor shower' button that acted like a self destruct where it would bombard your ship and everything it hit would explode, but the game would always crash once everything had been destroyed, guess the game didn't like 'death by micrometeorites' as a method of vehicle destruction.

An utterly pointless mod that I made which will randomly hit you every so often with a micrometeorite. Obligatory video (taken in the dark so you can see the effect better): No, it doesn't cause any damage, it just creates some sparks and gentle bump. Download here This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Now if I could just find a decoupler that size...

Subassemblies are coming to stock in 0.22 as well.

Yes I believe its converting it to DXT, I haven't noticed much of a difference but I have a huge number of parts and I don't know which textures were compressed. If you want to see what it's like, try it once, you can always delete the dll and reload the game to get it back to the way it was.

How did you compress the textures while they loaded? Also, I was trying earlier to figure out more information about what it was compressing, but the whole thing is a mess. I mean GameDataBase.TextureInfo has bools like isReadable and isCompress but I couldn't find a coordination between those and what was being compressed. I also tried storing the names of all the textures that threw an exception then removing those from the complete list of texture names to find the ones it compressed but it gave me back like everything so I probably did it wrong (I'm pretty new to C#), also it looked like some texture names were blank. If you have a piece of code that would show which textures are actually being compressed I'd be happy to run it and figure this out.

I found an interesting command while working on a plugin, basically it compresses textures in memory and I'm curious to see what it does for other people. The code is really simple: [KSPAddon(KSPAddon.Startup.MainMenu, false)] public class CompressRAM : MonoBehaviour { void Start() { foreach (GameDatabase.TextureInfo t in GameDatabase.Instance.databaseTexture) t.texture.Compress(true); } } It simply tries the compress command for all the loaded textures, most of them it doesn't work because the texture is 'not readable', but it obviously manages to compress some since task manager shows: Working Set (Memory), Memory (Private Working Set), Commit Size Without plugin: 3554 mb, 3530 mb, 3706 mb With plugin: 3164 mb, 3139 mb, 3306 mb ~ 400mb reduction If you notice I run with a huge number of mods (pretty much as many as I can without crashing the game), so every little bit helps. If you want to test it out you can download the dll here: http://www./download/xd4atz8ci9b4269/CompressRAM.dll Just drop it in the Plugins directory, then post the before/after RAM usage which I'm curious to see.

I just don't get why they changed some stuff that was working perfectly fine in the previous Total War's (like Shogun 2). Like you decide to cross an ocean and poof you magically have ships, I mean are you kidding me, whats the point of a navy then. That totally broke immersion for me when armies starting just vanishing into the ocean on their magic boats. And I can't recruit forces without a general? Dafuq? So if I want maximum troop production I have to station a general in every province. And the AI is still as crappy as ever. I march my army and end my turn on the front door of your capital city and your big army decides to run away and die of attrition in the deep ocean while I capture everything you own. Bah, it just saddens me because I had such high hopes for it.

If your extending PartModule then there is no OnDestroy, but Part has onPartDestroy so you would need to create a class that extends Part to perform those actions. Btw, it's Rigidbody.AddExplosionForce not explosive, and if you don't like that you could try making the part.explosionPotential really high then doing part.explode().

Yeah I use too many mods to count (and unfortunately I deleted the ship designs that are unstable so I don't accidentally use them). Nevertheless, I believe the oscillation I was seeing has to do with the flex of the ship. If you build large/tall vehicles (I typically use the 3.75m/5m KW and Novapunch2 engines for my first stages) they have some flex to them, so when mechjeb detects movement one way I'm guessing it assumes the whole ship is going off course when in reality it's just the ship flexing a bit in that direction. It then tries to compensate which causes it to swing back, causing more flex, then oscillations, then (if you don't have enough struts) usually destruction. I've found that enabling KerbCom Avionics "Stock Engine Control" mode will usually dampen those oscillations though.

I've flown a couple missions with the old dll and then this dll and honestly the only differences I noticed were actually regressive. The new dll turns towards nodes much less smoothly (almost whips around sometimes) and I've seen it struggle to get to really simple node locations (fly right past them and then barely come back). And is there a reason why it sometimes spins on the long axis when turning toward a node, because that makes no sense. Also I've seen the new dll warp right past nodes on multiple occasions (come out of warp at like +4 minutes for a simple 5 second burn). It's the same with the old version, but is MechJeb ever going to stop oscillating the whole ship, especially large vehicles with gimbaled engines. I mean mechjeb will rip apart some vehicles when they're going straight up just by oscillating it to death, yet you can turn mechjeb off then ignite them and not even touch the controls and they fly straight as an arrow.

I attempted to aerobreak at Eve. For once I think Jebediah actually looks concerned.

Are you using Linux? Because I noticed that happened with this mod on Linux, I have no idea why because it doesn't do that on Windows. Unfortunately its not really that simple for either of those, since the mod relies on scaling the model in x, y, z directions you can't really use it to change the actual shape like for changing the ends independently. A procedural SRB using this method would stretch the engine along with tanks and it would look really weird. I believe I saw a post before about someone working on procedural SRBs or something similar though. If the ship is really big make sure you're using high strength struts to make everything rigid, the game doesn't like large/long vehicles by nature, tends to break all the node/radial connections and rip them apart.

I'm not really sure it would increase performance any, but I do think it would be a cleaner approach overall to extend Monobehavior rather than Partmodule since this isn't really a part level mod. I'm assuming right now the code is simply using part and part.vessel, but you can just as easily access the current vessel and control part using FlightGlobals.ActiveVessel and something like foreach (Part p in FlightGlobals.ActiveVessel.parts) if (p.isControlSource) controlPart = p; to set those up. Most of the stuff MechJeb deals with is outside part/partmodule anyways, so I don't think it would be all that huge of a coding change to make it partless.

Any plans on making MechJeb partless? Would be nice for it to just always be there and not have to worry about parts.