HoneyFox

I added ^BoulderCo/ into the "generateMipmaps=" setting and set "isCompressionEnabled = never" inside @Default.cfg of TR. It still doesn't work properly in map view. The exception I mentioned above doesn't seem to be thrown by the game though. To be more accurate, the cloud displays when in normal view. When I switch to map view, for the first ~one second period of time in the map view, the cloud was there but after that it just disappears. BTW, in case this is a clue to the issue, I tried to switch the cloud shadow on and the shadow displayed correctly. EDIT: Alright, I gave up. I removed TR completely from my install and the cloud still disappear after 1 second when switched to map view...

There was once a thread that share rockets using RSS/RO, in the General Discussion section IIRC. But i wonder if .craft files are provided or just some screenshots.

Hey NK & RedAV8R, come to say that I'm pretty impressed by that NSTAR ion engine in RO. I mean the realistic thrust value of it. You are really aggressive on that, I thought tweaking it to something like 0.005kN was already weak enough to be a good balance between reality and game-play (even if it's used with my OMS plugin) And now those Near Future's ion engines are just like cheating.

I'm not using ATM. Guess that TR is grabbing some sort of file handle and disallow EVE to access it? I will check and see.

Hi. I had RSS/RO and the Overhaul mentioned in the above post #3547 installed and now I have a problem: The cloud texture doesn't seem to be displayed when in map view, and some sort of atmosphere effect suddenly disappears at a certain moment during a rocket's ascent to orbit when in normal view. Something I found in output_log.txt, which i think is suspicious: UnityException: Texture 'BoulderCo/Atmosphere/Textures/kerbin1' is not readable, the texture memory can not be accessed from scripts. You can make the texture readable in the Texture Import Settings. at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixelBilinear (single,single) at Atmosphere.CloudParticle.Update (UnityEngine.Texture2D tex, Vector3 offset) [0x00000] in <filename unknown>:0 at Atmosphere.VolumeSection.Update () [0x00000] in <filename unknown>:0 at Atmosphere.VolumeManager.Update (Vector3 pos) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsVolume.UpdatePos (Vector3 WorldPos) [0x00000] in <filename unknown>:0 at Atmosphere.AtmospherePQS.Update () [0x00000] in <filename unknown>:0 though the callstack seems to be related to the volume cloud effect...

Hi, I've got some problem with SRBs in RO. it looks like some SRB's thrust is lower than that in RL. e.g. GEM-40 Air Lit In RL, vacuum thrust on ignition is around 106,000lbf according to ATK Solid Catalog 2008 pdf, which is 471kN, peak vacuum thrust is around 150,000lbf, which is 667kN. In RO, GEM40 has a maxThrust (I think it's also vacuum thrust) of 499.2kN, with the thrust curve having "key = 1 0.38", that means the actual thrust might be only about 189kN (I hope that the curve is fuelPercent <=> thrustPercent), which is much lower. Same with the peak thrust.

It's very weird that solid boosters are using EI modules... which should be only used by liquid fuel engines. You might need to ask if the author of the engine.cfg for RF has added EI module into SRBs or not. For the SLT thrust issue, judging from the screenshot, is because the SRB has RF thrust curve, so it's not giving maximum thrust all the time. (but it's strange to see two % Rated Thrust in the context menu though.)

Uh oh... i have to change my ETC's MM cfg, so that it won't affect any SRB that has a RF thrust curve inside. Otherwise the actual thrust curve will be modulated by both curves, i.e. finalThrust(t) = RFThrustDueToIspChange(originalMaxThrust, Isp) * RFCurve(t) * ETCCurve(t).

I have been using RT2 with EI since 0.22 or 0.23 and I didn't have problem like you said when I was controlling a probe that was far away from earth (which means all operations will have a pretty long delay). AFAIK in one case the engine will have "Ignited" state displayed with zero thrust: you run out of propellants. I use such method to do maneuvers (in the situation that signal delay is enabled): I plan a maneuver first. I click the NODE button to make the craft face to the maneuver direction. I activate the engine with zero throttle. I input the parameters needed for the burn, but do NOT click BURN or EXEC immediately. I use delay timer to set to the proper time, then subtract it like 10~20 seconds. Since now all operation will be delayed. I keep pressing RCS forward key for 10~20 seconds to plan the ullage operation, so that the fuel will be settled down at the bottom of the fuel tanks before the burn begins. I click the BURN button. After that amount of delay, the spacecraft will act like this: It first tries to turn to the maneuver direction (if it's not completely aiming it after exiting from time-warp) It then start to use the RCS and burn for 10~20 seconds. At the end of that RCS burn, the main engine will be ignited.

Have to agree with the "too short" issue. Though I can use some workaround (i.e. use the full name instead of the initials) to overcome that.

Well I would suggest the author of OP to change the title to: Mod Repository Divided... that's the case the author is talking about If i get the point... Modding community? No they are not divided at all, you can see them all right here, in this official forum.

Check the ignition resource requirement(s) in VAB/SPH by hovering the mouse over the engine. Make sure you bring sufficient resource(s) and make sure the resource(s) is/are reachable from the engine. (just like the general engine fuel)

For SRB I'm not changing maxThrust but manipulating the finalThrottle directly (with useEngineResponseTime = true of course) so there should be no problem with your changing maxThrust based on Isp. For liquid engine, that's a different story. but the function of adjusting liquid engine thrust by ETC has been obsoleted (and so deprecated) since the stock KSP introduced the ThrustLimiter feature.

I did an asteroid rendezvous mission yesterday using the Orbit Manipulator Series plugin with a probe which weighs 0.58 ton and was equipped with a modified PB-ION that has a max thrust of 0.02kN. It took me 4 days (of course in-game time) to finish the burn to kill most of the relative velocity and several correction burns to finally park my probe just near the big rock. Have to say it's quite a challenge, but do-able.

Ok. now i know what's wrong... blame my GitHub & network again... GitHub failed to sync one of my code change which was commited 1 month ago. Anyway, I will release an update soon.

Pressurization is only for RF users because RF provides fuel tank type information. For non-RF users, do NOT extract that cfg. Remove it if you already did.

Ok i will do the fix again with latest code then.

Wait a moment... it seems like your submit just removes the fuelRatioAsAFactorOfUllage calculation... Did you fotk from an earlier revision of code or is that intended? I wonder if I need to re-add the feature back, if so I want to know what changes the patch has applied onto. (perhaps just the "p.GetFlowMode()" part?) PS: I heard that you are integrating ETC into RF? Guess that you can also integrate the CurveEditor in my TP plugin, or perhaps MuMech's CurveEditor?

Perhaps just like '\r' '\n' '\t' .... here comes '\F'.

Basically they are still useful to some extent, but you will need several mid-course correction burns for your transfer to either moons or planets.

Sorry. [Moderator removed defunct website link]

Hi Mihara, I would like to take the next plugin place on the MFD. The updated MFD.txt and cfg are inside this package: http://beta.kerbalstuff.com/mod/60/Engine_Ignitor_MFD/1.1.0 EDIT: Wrong url.

Are you using the stock RPM or the MFD pack made by Hyomoto? Anyway I will do some test with the latest version of RPM and VV soon and see if anything is wrong. EDIT: Updated. The new version of MFD link is updated in OP. and you should install latest RPM version first, then install this.

The "whatever, here's six" issue might result from persistence feature. i.e. some values are stored in .craft/.sfs files and you need to reinstall the engines onto the rocket so that the new setting will take effect. I think it's possible to use an electric motor to start up the pump, but perhaps only for those smaller engines. Anyway you can change the IGNITOR_RESOURCE by your own, if you want it to consume ElectricCharge, just do it.

Great to hear the author of KT has come back! My dirty work can rest in peace then.