Ratzap

Yep, I didn't bother putting in fiddly code to work out efficiency and whether or not an engineer is present etc. Maybe one day.

Cheers, I'm having good fun with the soviet stuff so far even though I sometimes puzzle over which bit goes where

Would it be possible to remove the fairings from the subassemblies you provide? When I try to use one it appears off to one side, unclickable and KSP.log fills up with: [EXC 03:44:06.214] NullReferenceException: Object reference not set to an instance of an object ModuleProceduralFairing.<SetupEditorFSM>m__190 () KerbalFSM.LateUpdateFSM () ModuleProceduralFairing.LateUpdate () [EXC 03:44:06.249] NullReferenceException: Object reference not set to an instance of an object ModuleProceduralFairing.UpdateXSectionPlacement (ProceduralFairings.FairingXSection currentXsc, ProceduralFairings.FairingXSection previous, Vector3 wAxis, Vector3 wPivot) ModuleProceduralFairing.<SetupEditorFSM>m__18F () KerbalFSM.UpdateFSM () ModuleProceduralFairing.Update () Seems the VAB really dislikes fairings on subassemblies.

I know, that's what I was pointing out to that other bloke.

From the KSP.log, it looks like OSE references something in the KIS libraries and is linked to the older ones. So with the new KIS version it stops working. I'm getting the same thing, I picked a bad time to try out OSE... Still, once recompiled against the new KIS it should be good to go.

That's all there is that fits the bill. There are a few others with 10 or 16 ignitions but unlimited is nicer and the other options have other disadvantages. All the near future engines are realistically useless (unless you fancy a 16 month burn) and the sad fact seems to be that there just aren't many other real world options. They probably design the engines knowing exactly how many times they plan on burning and fit round that.

Don't work too hard my friend, you live once so you need time to relax. Come back if/when you feel like messing with rockets again.

Ok, that being the case then to change from 'very stable' 1.0 to 'very unstable' 0.0 should take 1 / 0.0012 = 833 Update() changes right? Is that 833 frames or a set time slice of some sort? If Update() was called 50 times a second it should still take 16 seconds to settle and that's clearly not the case. As the other guy said, documentation of the whole thing would be great and will definitely save answering a lot more posts in the future I think If we knew what times were expected then we'd have a baseline.

Yes, once the U5 port is done and KSP moves to a new gui I will rewrite Fusebox to support the standard app bar. If blizzy updates I may add support for that too since people seem to want to keep it but that's a big if, he may not bother.

But that is wrapped by if (ventingAcc <= RFSettings.Instance.ventingAccThreshold) If there's no boil off venting, it'll just work out the current acceleration and then switch states no? What I would have in there is something like a configurable minimum length of time in a state. So if you reach very stable you should at the very least get fuelRatio x statechangeConstSeconds before it can switch down another notch. Ie prevent jumping from very stable to very unstable in a couple of updates.

I had a look at the source on github, it seems that there is no 'fade off' in the ullage simulation so the next Update() after acceleration drops to zero it'll transition straight to very unstable. If you had a DLL with the debug sections compiled I'd be happy to run a few tests. The RCS is 3.2 kN for a 22t full stage, 1.2 kN for a 5t full stage - not a huge TWR but it should be sufficient to settle things.

I have ullage on all but the first stage but like I said, it just doesn't 'stick' for long enough to light the fire so to speak. From what I was seeing just now, even the attempts to start the engine where making it switch to unstable again. I ended up keeping the RCS running and using action groups to toggle the engine on/off to eventually get it to start. With limited ignitions, this needs to be reliable. Heh, Nathan trigger detected It's just I was reading about it and the design they were talking about had the propellants in a bladder with the pressurant round it squeezing. No empty spaces, no ullage. Those must have been the membrane things you mention.

Carraux, ullage and ignitions as such are fine additions to the realism. The current implementation however seems a little aggressive: my full 2nd stage tanks plus engine went from very stable to very unstable in the time it took me to stage the payload fairing away and stage to 2nd. I also noticed this while I was trying to get my curcularization burn and later the burn to lift the AP: it switches from stable to unstable in less than a second. I ended up using action groups to flip the engines on and off rapidly while holding down H to produce RCS thrust. Eventually the timing fits and the engine catches. I also noticed that using hypergolic fuels with pressurized tanks also needed ullage - surely that should not be?

I use CKAN to keep track of all the RO/RSS mods and since the last solver engine update it's been spitting this error message out: Is this something for the CKAN people or one of the plugin authors to change their meta data? Edit: before someone asks, I did create a new issue on github as the message asks.

1.50 released, I finally got around to pulling the solar system parameters from FlightGlobals. The dark time calculator will show pick options for whatever bodies your system has. For your debug pleasure (as it's a new feature) you can look in KSP.log for lines with 'FB - ' in them. That will show what supported mods it found, which planets/moons were added and what your home world is.

Odd, it's working fine for me (I was playing last night). Career is of course broken but that's known. Science and sandbox worked fine - I put together and launched explorer 1.

1.45 released, will try and get CKAN to update as the guy who was doing it seems to have stopped. NF should all be working now (including the variable RTGs but I didn't test them).

If it's any consolation it does the same in RSS career. Soon as a sounding rocket breaks out of upper atmo into space it all locks up.

That looks good thanks. I'll do something about it when I release the next version. No that's because everything just bumped up 2 KSP versions and people are recompiling. So when Fusebox tries to access their functionality, the DLL versions no longer match and it can't do it. I'll release a new one soon (once the main other mods are updated).

That's pretty bizarre, are you running 64 bit or something? I'll add the icons to the list and see, if they look ok when resized then I don't see why not.

It can't which is why KSPI is not supported. It may be possible once the code change we asked for goes live.

I heard that. Hakan did the CKAN config previously. I'll have to look at it soon and figure out how to keep it rolling. That said, 1.0.3 should/may be coming out tomorrow. Depending on how much that changes I'll release a newer version sometime toward the end of the week.

Nice idea, I'll have to give this a go sometime. Especially if there's a soviet historical contracts set kicking about.

No link I'm afraid, just a message from Maxmaps saying "Tasked. Shouldn't be much of a hassle. " We all write the same way, no big deal. Free software naturally builds on pre-existing work or we'd spend all our time reinventing basics. I keep putting off my own big re-write. First this callback stuff is in the pipeline and now they're moving to Unity 5, any large pieces of effort now would be kinda wasted to be honest.

Since you're using a large chunk of code from Fusebox, I thought you might want to know that Squad accepted a change request for RequestResource. It hasn't yet been implemented but hopefully "soon". The change is to allow delegate callbacks whenever ResourceRequest is called with resource and part granularity. Meaning resource tracking for charge will work for all modded parts without having to jump through hoops. Do you update your core on FB releases or was it just a one off usage? I've been meaning to rewrite parts and I could make it more modular if it'd be useful.