NathanKell

@SpacedInvader then RF Stockalike is using an old and deprecated form of setting these things. It will probably switch to the current, correct method at some point, so best to patch both.

@PART[*]:HAS[@MODULE[ModuleEngineConfigs]:HAS[#engineType[O]]]:FINAL { @MODULE[ModuleEngineConfigs] { @CONFIG,* { @ModuleEngineIgnitor { @ignitionsAvailable = 0 @useUllageSimulation = False } @ullage = False @ignitions = 0 } } }

According to the current code in git, this mod does handle mass properly when FAR is detected, so...

Lift is not the only aerodynamic force that provides torque. Simple as that.

OnGUI is not a good choice. It chucks garbage and is itself slow. Also IIRC from Sarbian you will at least get toplines without pdbs. I highly suggest you try the method described before baldly dismissing it.

This does not work because one makes various wing shapes out of the combinations of other wing parts.

No, I reverted a fix to rendering things twice. The fix to rendering things n^2 times is still in.

@OhioBob yeah, ok, the issue is that Kerbin's orbit has no eccentricity whatsoever, which means the eccentricityTemperatureBiasCurve is passed 0 divided by 0 which blows everything up. If you don't include eccentricityTemperatureBiasCurve in the cfg for any bodies with 0 eccentricity you should be fine.

@OhioBob: Ah! Sorry, I totally misunderstood. Oops. Been a bit scattered of late. I'll try it with the node added back in and try to figure out what's breaking. Ya, ok, repro'd the issue. Trying with just a recompile for 1.1.2, if that fails too I'll do some debugging.

The autostruts are breaking things under those circumstances. Turn them off.

@OhioBob the reason BodyLoader isn't doing anything with Kerbin is that there is no Kerbin node in your cfg.

Wayland said he'd get this sorted tomorrow, so all good

Bleh, thought I did, but nope, the release is off master with no code changes shown. @WaylandSmith did you merely recompile, or are there code changes not reflected in git?

Give me your github usernames and I'll add you to the repo. I'll also be doing a merge from @WaylandSmith's update branch. With that done, and barring anything turning up, I suggest we make an official release so that people have at least something to use in 1.1 while other cool stuff gets done.

@pellinor sounds good to me! If you pass me an absolute scale that should work fine. Note that in the editor I will fire an onvesselmodified event on receipt, so we need to avoid loops...

If I did, I'd have had a more concrete suggestion.

It's the Docking Port Jr., so same place as that is for ya.

All mods must release source with them, therefore you can recompile them with pdb files.

Awesome, thank you both! I would suggest waiting a bit before locking in case @TaranisElsu has anything else he'd like to post--maybe until there's a new release from the continuation.

Close: the bigger the _number_ of parts, the bigger the lag. Basically, the "render cubes" event was sent by SendEvent, which by default sends it to all parts on a vessel rather than just the affected part.

That's true for RF tanks. RF engines will need their own work.

@Dman979 you've got exceptions from FAR, AGExt, a few other things. I suggest trimming down to just what's required for RO and trying there, then adding things back in until you figure out the problem. Make extra super duper sure that all the mods you have are on their versions for 1.0.5 not 1.1.

@danfarnsy what other stuff have you worked on, both KSP and not? Languages? @Zyx Abacab it'd be helpful if you'd mention too, since you offered to help as well. EDIT: I'd also really like to get @WaylandSmith involved, since s/he already did the heavy lifting on porting.

I did fix the PP issue, guys, you don't have to worry...

Yep, concur 100%, that sounds great!