RedAV8R

The absolute latest is on the RO GitHub, I haven't gotten the OP updated yet. Try this.

Does this error cause KSP to stop working??? What did you do immediately previous to this error??? Have you followed the 'standard' steps of troubleshooting KSP???

rdfox: tmikesecrist3's question was directly related to RSS/RO and FASA, of which your technique does not apply. - - - Updated - - - Yep, it sure does.

Hey I totally understand wanting things 'your way', and we aren't talking about Burger King here:) But FWIW, we've spent A LOT of time on RealismOverhaul to ensure it's as realistic as it can get for KSP. I started out the same way you did, nothing anybody else made was quite 'good enough'. So I started on my own, NathanKell and I met and now all my work is being incorporated into the package. Best of luck to you!

Edit#n: This forum has revealed some weird problems with file. I think this might be the cause of the problems with this engine at least. Some weird stuff here doesn't show up in notepad. { @title = Space Shuttle SRB @description = American: Space Shuttle Solid Rocket Booster @mass = 91 @maxTemp = 1700 @rescaleFactor = 2.968 @MODULE[ModuleEngines] { @maxThrust = 12000 @heatProduction = 180 @atmosphereCurve { @key,0 = 0 268 @key,1 = 1 242 } !PROPELLANT[SolidFuel] {} PROPELLANT { name = SolidFuel ratio = 1 DrawGauge = True } !MODULE[ModuleEngineConfigs] {} MODULE { name = ModuleEngineConfigs techLevel = 6 origTechLevel = 6 engineType = S origMass = 91 configuration = SolidFuel modded = false CONFIG { name = SolidFuel maxThrust = 12000 heatProduction = 180 PROPELLANT { name = SolidFuel ratio = 1 DrawGauge = True } IspSL = 0.852 IspV = 1.03 throttle = -1 ModuleEngineIgnitor { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 25.5 } } } } !MODULE[KM_Gimbal] {} @MODULE[ModuleGimbal] { @name = SmarterGimbal %gimbalRange = 8 %gimbalResponseSpeed = 10 %useGimbalResponseSpeed = true } !MODULE[ModuleEngineIgnitor] {} MODULE { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 25.5 } } }@PART[MassiveBooster]:Final //SSRB Note: In the original config I've changed the amount of fuel to 360000 @PART[Size3AdvancedEngine/F-1B]:Final //F-1B { @title = F-1B @description = American: Upgraded version of the famous F-1 engine used on the Apollo missions. @mass = 8.4 @maxTemp = 1700 @rescaleFactor = 1 @MODULE[ModuleEngines] { @maxThrust = 8000 @heatProduction = 180 @atmosphereCurve { @key,0 = 0 304 @key,1 = 1 265 } !PROPELLANT[LiquidFuel] {} !PROPELLANT[Oxidizer] {} !PROPELLANT[MonoPropellant] {} PROPELLANT { name = Kerosene ratio = 2.2674 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 1 } } !MODULE[ModuleEngineConfigs] {} MODULE { name = ModuleEngineConfigs techLevel = 6 origTechLevel = 6 engineType = L origMass = 8.4 configuration = Kerosene+LiquidOxygen modded = false CONFIG { name = Kerosene+LiquidOxygen maxThrust = 8000 heatProduction = 180 PROPELLANT { name = Kerosene ratio = 2.2674 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 1 } IspSL = 0.796 IspV = 1.018 throttle = 1 ModuleEngineIgnitor { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 25.5 } } } } !MODULE[KM_Gimbal] {} @MODULE[ModuleGimbal] { @name = SmarterGimbal %gimbalRange = 1 %gimbalResponseSpeed = 10 %useGimbalResponseSpeed = true } !MODULE[ModuleEngineIgnitor] {} MODULE { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 25.5 } } } @title = RS25 Cluster @description = American: A cluster of four RS25 engines. @mass = 15 @maxTemp = 1700 @rescaleFactor = 2.133333333333 @MODULE[ModuleEngines] { @maxThrust = 9116 @heatProduction = 180 @atmosphereCurve { @key,0 = 0 452.3 @key,1 = 1 366 } !PROPELLANT[LiquidFuel] {} !PROPELLANT[Oxidizer] {} !PROPELLANT[MonoPropellant] {} PROPELLANT { name = LiquidH2 ratio = 85.775249 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 14.224751 } } !MODULE[ModuleEngineConfigs] {} MODULE { name = ModuleEngineConfigs techLevel = 6 origTechLevel = 6 engineType = L+ origMass = 15 configuration = LiquidH2+LiquidOxygen modded = false CONFIG { name = LiquidH2+LiquidOxygen maxThrust = 9116 heatProduction = 180 PROPELLANT { name = LiquidH2 ratio = 0.85775249 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 0.14224751 } IspSL = 1.071 IspV = 1.61 throttle = 0.7 ModuleEngineIgnitor { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 25.5 } } } } !MODULE[KM_Gimbal] {} @MODULE[ModuleGimbal] { @name = SmarterGimbal %gimbalRange = 2 %gimbalResponseSpeed = 10 %useGimbalResponseSpeed = true } !MODULE[ModuleEngineIgnitor] {} MODULE { name = ModuleEngineIgnitor ignitionsAvailable = 1 autoIgnitionTemperature = 800 ignitorType = Electric useUllageSimulation = true IGNITOR_RESOURCE { name = ElectricCharge amount = 25.5 } } }@PART[Size3EngineCluster]:Final //RS25C{ Edit#n+1: I did some major changes to the configs after I checked them with Notepad++. I'll see if that helped. Note to self: never use Notepad again. Edit#n+2: The XS25 only has problems with my own stupidity now, that's cleared. I think the ARM single chamber is also fine. The other two are still broken. Your cluster is broken because your first bracket is commented out, put it on the line below and you are fine there. Pay attention to your bracket usage. Your SRB is broken because you are missing at least two brackets I see. Hint...What I'll do if I have a problem In Notepad++ EDIT:BLANK OPERATIONS:Trim leading and trailing space EDIT:LINEOPERATIONS:Remove Empty Lines (containing blank characters) LANGUAGE:C:C# Get a plugin - search for Indent by Fold ReIndent your config with that plugin Will look cleaner and easier to read (IMO)

Why not go to the RealismOverhaul Github and grab the RealEngine files...boom...RS-25 via Klockheed Martian.

You have an old version of AJE then...because mine sure is configures the RAPIER.

1. Gemini SM - Let me take a look! 2. Centaur, yes that I do know, best I can do is use the Titan Silver tanks, which would then NOT look like a TransStage, so that's not a bad thing. 3. I have not experienced this yet...I'll take another look though.

If you download what is currently on github (which is the most current (still a few things left to update before released as v5.2) then yes, SFJBRealEngines is no longer required, and should be deleted, as it is now integrated into RO.

Good to know! No rush at all, plenty on my list to do while I wait for Alpha6.

That is already on my ever growing list:)

Why, yes, that is exactly the purpose and reasoning behind v6. All stock KSP parts are going to be using TweakScale with RO type scaling where appropriate. This removes approximately 67 parts from the list, while giving a user easier access to what they want, and actually gives a user MORE selections as parts will now go up to 5m. Now, added parts as part of like FASA pack and things will still be there. That includes having a wide selection of payload bases and nosecone sections to match what was available on the real Agena, Atlas, and Titan missions. Those I will not depreciate out, however those only appear when FASA is installed as well. In addition, I'm slightly modifying the folder structure, so that my realism patches are in folders matching the mod they rework, so there is a 'FASA' folder within the 'RedAV8R' folder...this is an easy fix for people, like me, who use PartCatalog (seriously why wouldn't a person? Anywho). All a person needs to do is simply select all the folders, cut and paste into their main GameData folder, which will then insert those *.cfg files into their respective mod folders, this process will automatically put new parts created in certain mods to appear in the part list under those mod's tab.

We have our own very special thread for RO, which includes the realism pack for FASA. For orbit of Explorer probe, you must launch the Juno I to achieve your wanted final perigee, using the 1st stage only, then at apogee fire the 3 stages of mini-Sergeants in order, which if done properly should achieve orbital velocity. FYI, this is just like the real bird did it. Hence why in RSS/RO, you must fly it the same way.

If you want the latest go grab everything from github. Since there isnt any source to compile its all MM patches. Thatll be v5.2. NK has a few last touches and that release will be out. My overhaul should be v6 its that big. Likely won't be released until 0.24 of KSP is out with that around the corner and we make appropriate changes to support that. What I can do now is nearly done...a good solid day should be enough...then I can go back with bug testing.

You couldn't be further from the truth. Pay no attention to this claim.

You were using my RSS config, there was a bug, it has now been corrected and the file is available on the RO github.

Yep, there was an error in my LazTek. I fixed it on my end and it is now in the RO github source. With the integration of my packs into RO, I will be removing my DropBox downloads, and everything will be available via Github. Yes there will be *.craft files available at some point, finishing up the RO overhaul, yes that'd be the Realism Overhaul overhaul, once that is done, I'll go back to some function testing of my realism packs and build *.craft files to go with it.

Yep, there is nothing here we can do for you. Personally, as many problems as TweakableEverything introduces, you'd be wise to uninstall it and wait for a version which repairs everything. TweakableEverything does not play...nice...with A LOT of stuff.

Fortunately the way KSP works it's not a game breaker, but for the sake of good programming you really aught to, just because it works, doesn't mean it's right. It would require making a database/array, which could be deleted when the script is done running, but if you are going to do it, do it right.

Agathorn: To answer your other question in the MM thread you had...actually, when I get done, all RO files will have a :FOR[RealismOverhaul] tag on them, which means that you simply would need to add a :AFTER[RealismOverhaul] tag to the end of the call...like this... @PART[*]:HAS[~RSSROEnabled[]]:AFTER[RealismOverhaul] { %category = -1 } Speaking of that...for simple grammer...I believe we should change it to RSSROConfig = True, instead of 'Enabled' since that could be misinterpreted by the lay person.

That's MM code for you, sometimes something different is needed to get the same result. It's all in the 2nd post of the ModuleManager thread. The first gets everything that doesn't have it at all, the 2nd one gets everything that has the tag, but a false condition. Now I haven't tested it, but this is what it should be. As for your Python, what I'm saying is throughout the RO folder are multiple *.cfg files. Within those files are a ton of @PART[*] and some new parts as well PART{***}. The way KSP works is every part has a name. So initially somewhere there is: PART { name = whatchamacallit blah, blah, blah } Then elsewhere that part is edited via ModuleManager like this: @PART[whatchamacallit] { blah, blah, blah } What I'm asking you, is in your Python code, did you account for the fact that while there should only be one PART{***} (first code example)...there are numerous places where in different *.cfg files, and could be multiple within the same file a ModuleManager edit like the 2nd code example. Does your Python code just see PART{} or @PART[]{} and then insert "RSSROEnabled = True" because if so...then by the time ModuleManager gets done a part could have 12 different entries of "RSSROEnabled = True", instead of the one.

Maybe because nodes are handled by the module itself, not just read from the part. You might need a programming change to PP itself to get what you want. EDIT: What is the parent/child relationship? Do you want the PP tank to attach to a part...or do you want another part to attach to the PP tank...In other words, whatever part you want to attach, THAT is the surface node you need to edit. Ex...if attaching a part to the PP tank...the other part's node_attach is what needs changed, not the PP tank.

@PART[*]:HAS[~RSSROEnabled[]] { %category = -1 } just to be sure a person could also use this to get something that has RSSROEnabled = false @PART[*]:HAS[#RSSROEnabled[false]] { %category = -1 } Did you ensure that the part name is different? Otherwise a part, which may be touched in several different places could have multiple entries of the same thing. - - - Updated - - - Thanks for the heads up!

With coming on board, and clearing other items off my list, I am now doing a major revamp of old RO parts/configs, cleanup, updates, etc. With this adding a tag will be easy, easy, easy, so don't worry about your script, just give it some time, release will be the proverbial soon. Then I can start working on more pack patches, lots in store!

You know...Actually what can happen just as easy...is any part touched by RO/RSS I can add a "RSSROEnabled = True", then with a simple ModuleManger config file one can search for all parts that do not contain a 'RSSROEnabled = True' make 'category = -1', which effectively hides it from view in the VAB. No Python script required.