iamzac

This bug also affects me, as I posted earlier, but Ferram said he can't reproduce it.

I meant that when the ship is first loaded in 0.14.3.1 the COL is in the same position as in 0.14.3 (and I notice no errors in the log), and after that it changes (and errors appear in the log that seem to come from that change in the code, but I can't know if they are causing the problem or not). I didn't mean that the COL was loaded from somewhere. Edit: If anyone read my previous edits to this post ignore them, they where wrong.

I did further tests, I downloaded the older 0.14.3 version and there this bug doesn't exist and the COL is like it is with 0.14.3.1 at the first load, so the bug appeared between 0.14.3 and 0.14.3.1 . I also tested the latest dev version with the "let's try this" change and the bug is still there. I also found that I don't need to reinstall FAR to reproduce this bug, everytime I start KSP the COL changes if I follow this simple steps: load the ship (I get the COL from 0.14.3), exit SPH, and return to SPH (I get a new COL that is closer to the front). Edit: After having a quick look at the output log errors and the github changes maybe this might be the problem: [spoiler=] - Collider[] colliders = p.GetPartColliders(); + FARPartModule farModule = p.GetComponent<FARPartModule>(); + + Collider[] colliders; + + if ((object)farModule != null) + colliders = farModule.PartColliders; + else + colliders = new Collider[1] { p.collider }; Since I have no experience with the FAR code this sugestion might be completely nonsense.

To be sure that no other mods i have are causing this problems I tested again like this: Step 1: Removed all the mods including FAR, loaded a stock ship in the SPH and took a screenshot: https://www.dropbox.com/s/bhvqdsfbsohr2v1/no_far.png?dl=0 Step 2: Added only FAR 0.14.3.1 as it was downloaded, with no customizations, clean install, loaded the same ship and made another screenshot: https://www.dropbox.com/s/rclx24i4ch353z8/far_firstload.png?dl=0 Step 3: Exit SPH, then return to SPH and made another screenshot, now the COL has moved: https://www.dropbox.com/s/eiuegpwhrtgsmlm/far_secondload.png?dl=0 Here is the KSP_Data\output_log.txt.

I found a bug that I think it's recently introduced, probably in 0.14.3.1 or maybe in the last dev versions before 0.14.3: If I modify general settings for FAR in the menu from the space center window the COL of all my ships is modified, in my case it moves forward and it remains there even if I change the settings back. I noticed before 0.14.3.1 that my COL moved forward while using a recent dev version but I assumed that this might have been an intentional modification but today I installed 0.14.3.1 then I checked my ships and the COL was again as before, more to the rear, then I changed some settings and it moved again forward, I changed the settings back and it was still forward. I don't know which of the two COL positions is the right one and which is the buggy one... Update: I did additional tests and this is NOT related to changing settings as I thought the first time: when you first load a ship after installing a new FAR it shows the COL closer to the rear, if I load it again later without changing anything it shows the COL closer to the front.

FAR already does some rebalances for jet engines, modifying not only thrust but also the velocity curve for some of them, what I was suggesting is that it should also do the rebalances that are available in the Kerbal Isp Difficulty Scaler as "FAR to Stock KSP, Atmosphere only" to complete somehow the partial basic rebalancing of the jet engines. And also undo all or some of the rebalancing for helicopter rotors and VTOL engines because like I said I don't think that the effect it has on them is in line with the reason it was done for all the other engines, as they are a special kind of engines that are not affected very much by FAR (or not at all when only hovering).

Reducing the thrust of air breathing engines at half is very good at balancing the performance planes and spaceplanes vs the stock aerodynamics where the drag is much higher but there are two problems with this: 1) You should not reduce the thrust of hellicopter rotors and VTOL engines by 50% since they gain nothing from FAR during low speed hovering and become almost useless after such a large thrust reduction. Maybe reduce their thrust with a lower value like 10% or 20% so they will not be too fast when not hovering but not 50%. They can be excluded easy from the general filter because they usually have the words rotor, helicoper or vtol in their name or description. 2)Rockets are still overpowered vs. the stock game and it feels a bit like cheating if you are playing with FAR without RSS. The simplest way to fix this would be to reduce the atmospheric ISP for all rockets, this way they will work the same in space or on planets with no atmosphere where FAR doesn't change anything but where you use FAR you will need more fuel which will balance the lower drag. Especially going to EVE for a return mission with FAR feels cheaty because you can get a huge reduction in the required dV if using FAR to launch a rocket from there.

OK then, I hope you will not change it again. Actually it is a bit better now since I can have my COM and DCOM closer. The tail is not that large, look at the tail on the Antonov An-225, it's even bigger compared to the main wings. By the way, since I am talking about heavy stuff: the B9 landing gear behaves like it's made from rubber on large and heavy crafts no matter how many struts I use and I have to use the small gear bay which looks ridiculous. They can be used on heavy crafts only if you are extremely careful and gentle and I like landing in mountains sometimes Also, bigger (taller) landing gear would be very useful for large crafts... maybe something with 4 wheels... or maybe just an upscaled version of the existing ones.

After seeing this I checked my cargo plane which uses the HW21 wing to see if everything is ok and it's not: As you can see the COL moved enough to unbalance the plane. Before starting to redesign it again (I just finished redesigning it after moving from B9 4 to B9 5) I want to ask: Is this how the COL for HW21 will remain or is this a bug in B9 or FAR ?

Just wanted to mention since B9 is already made mainly for FAR, the turbojet in FAR is actually weaker than your SABRE, maximum thrust is 110 at 900 m/s and zero at 1800 m/s. And in case you didn't already knew that I hope you will not nerf the SABRE since they are already realistic, they should be able to reach around Mach 5.5. And about the Scimitar sounding a bit too good to be true... well, if SABRE will become real one day then Scimitar will work too since it's actually a simpler technology, SABRE minus the rocket mode. Also the Scimitar is designed for a longer life than SABRE so maybe it's not necessarily a simpler technology... In KSP we have to look a bit further in time because if we would be 100% realistic we would have no spaceplanes and kerbals would only be able to visit Mun I hope you will add a Scimitar engine since the stock turbojet doesn't look that pretty when paired with B9 components and using my own custom version of scimitar I showed earlier feels kind of cheaty somehow, I don't know why I prefer not to use custom components modified or made by me.

I "made" a test version of the Scimitar engine for the B9 mod team to use it as a starting point in case they wish to do so. Since I have no idea how to do 3d modelling for KSP I took your model.mu from the B9 4.0 SABRE S engine (since it is more similar to the Scimitar because of it's slightly funnel shape), put it over the new one and made the following modifications to the B9 5.2.1 SABRE S part.cfg: Changed name and description, removed all the Rocket Mode parts, decreased mass from 1.5 to 1.4, decreased cost from 3750 to 3500, increased thrust from 215 to 220. Everything else is the same and I tested it and it works. Here is the link: https://www.dropbox.com/s/gw2xctyw7z78m2a/Engine_Scimitar_updated.zip?dl=0 (edited, in the first upload I had accidentally deleted the alternator) This is 100% B9 material, I only modified the cfg.

The Scimitar engine can achieve the stock turbojet performance and it's no more or less "magical unicorn-pixiedust-and-friendship" than the SABRE engine included in the B9. Personally I am using it to replicate a hypersonic plane similar to the proposed Lapcat plane from the link I have included. I think it's perfectly balanced compared to the SABRE S engine from the point of view of thrust and weight. The only unreal thing is the name and the design but maybe you could make a B9 one. It would basically be a slightly lighter SABRE-S, with the same thrust and velocity curve and a slightly funnel shape. Maybe you could reuse the old SABRE model which was already slightly funnel shaped and put a modified texture... like the jagged texture around the F119 nozzle... or we can use the existing stock turbofan and imagine it's an scimitar engine Anyway, it would be nice to mention in the original post you modify the stock engines and also write how to undo this modification by deleting the MM file, otherwise people will find out their stock planes don't work no more and have no idea why, as not everyone reads the changelogs.

There is a simpler way to deal with the overpowered stock turbojet: just consider it to be a Scimitar engine which can do sustained cruise speed of mach 5 and could theoretically go to mach 5.5 You already have SABRE engines, Scimitar are (will be) the same thing, only without the rocket mode and with longer operational life. They are basically a turbojet + ramjet in one.

@sal_vager: thanks for your help, turning down render quality in wine does eliminate shadow flickering but also removes the shadows completely... anyway the main reason for testing with wine was to see if I can get better performance but it's the same so it doesn't matter. As for the problem with keyboard events: I tested further and it happens in both 32 and 64 bits versions and also happens with Kerbal Alarm Clock so it's not a bug related to MechJeb. Under wine the problem doesn't happen. Every time I type something into a Kerbal Alarm Clock or MechJeb window this triggers action groups and other events (for example space would trigger stage separation) which shouldn't happen if the window has focus. So this is a problem with event bubbling: in the Linux version the windows don't stop events to propagate to their parents when they are focused. Any idea how to fix this?

When I type something into a Mechjeb window, using the 64 bit KSP version under the latest Lubuntu, action groups are activated. I tried the windows version with wine and there this doesn't happen but I have another problem: the shadows are flickering. Does anyone have any idea how to fix these problems?