My sole frustration has been with Jorg/Seb saying “we’re going to get better w/ communicating and being quicker…” and I’ve yet to see any improvement from that end. Again, the community mods are amazing and they seem to always be on top of it, but they can only do so much. Just my 2 cents.
I agree there. Talk is cheap. Saying you will ‘get better’ at something is the easy part. I remain unconvinced by them saying they’ll do that, until they actively start to do it.
I just tested this and the engines no longer die with reheat, even down to -90C, so well done!
They are more than a bit slow. I can’t get fuel to move from tanks 9 to 11 at all. I can get it to move from 10 to 11 and the other way, but extremely slowly and hence not practical. The only way I can get fuel to move out of tanks 9 is to turn on its pumps and open the standby inlet valves to tanks 5, 6, 1, 2, 3, 4, 10, 7 and again it is a trickle.
Also, as reported earlier in this thread by me during the SU9 beta, there is a graphics glitch on what seems to be leading edge vortices shooting out of the centre fuselage, this time in an upwards direction. Not a biggie at all compared to fuel flow issues, just something to be aware of when cleaning up after hurricane SU9
Exactly what I reported at least 2 weeks ago. I can move fuel OUT of Tank 11 or OUT of Tank 10, but not OUT of Tank 9. Tank 9 is effectively a one-way fuel ballast tank at this point.
Transfers into or out of Tanks 10 and 11 are also slower than I would expect.
Ok, I think then the Afterburners issue is solved. I think that what Asobo has altered, I don’t know if consciously or not, is the amount of fuel demanded by the engines with Reheat. Increasing the fuel pressures corrects the problem.
Now, a modern fuel system in MSFS is made up of lines, valves, pumps and junctions, I think what is broken are basically the junctions, I have a fuel meter that analyzes the gph line by line, and where were used to flow fuel in SU8 by the junctions at a hefty 2000gph, has now dropped to 15gph. In other words, it is not that fuel does not flow from tank 9 to 11, it is that for each junction through which it passes, the amount of fuel that flows is reduced… I do not think it is the only plane affected, but it is the one with more junctions in the sim…
To put you in perspective, each red circle represents a junction, in which the fuel can flow in various directions. Where before it flowed perfectly, now those joints are plugging the flow of fuel. It’s what I’m trying to solve.
In the real world, the orders of magnitude you’re talking about make it sound like you went from a pump-driven flow rate to a gravity-feed flow rate. Also for flow passing through a series of junctions without branches, the flow at each junction should be equal - flow in = flow out. Otherwise, you have a virtual fuel “leak”.
You could consider debugging by dramatically simplifying the fuel system to four tanks connected directly to each of the four engines for some static tests on the ground. Then add some junctions. Basically just work through a unit test. Looking at a partial set of data, it’s hard to tell if this is as simple as a bug or as complex as an aspect of the simulation was fixed and induced unexpected behavior in previously simplified code.
There are 181 lines, 48 junctions, 33 valves and 37 pumps. Undoing it is not that easy, and it worked perfectly on SU8. The only thing that fails right now is the transfer between tanks 9, 10 and 11, the rest continues to work as before except that I have had to increase the fuel flow that reaches the engines directly. Something that affects junctions must have been changed.
I also can’t tell what has changed regarding junctions because there is no changes in the SDK documentation
Obviously on the right trail, I’m just trying to come up with some intermediate steps to help narrow this down given the pace of getting information back and forth from Asobo.
Do you have most of your junctions working and just a few not working? Or is every junction a massive restriction?
Does any pump in the system operate off of a curve? Any benefit to defining curves for the elec and engine driven pumps to confirm the set value is as expected?
Do you have any complex junctions with options? I could see this coming down to a junction option getting set incorrectly or the default of all-open for a complex junction not getting picked up.
I hope you don’t mind me playing with the cfg but I managed to find a way to get fuel to flow between tanks 9 and 11 in either direction. Essentially, I just changed the junction from tanks 9 and 11 and its associated inlet valve to go direct to its opposing tank’s inlet valve. Yes I know this is contrary to the fuel schematic diagram you posted, but it now allows fuel to transfer between tanks 9 and 10 at up to 10000 gph (my estimate based on 14 gallons flowing every 5 seconds) in either direction. This most likely breaks fuel flow somewhere else involving these tanks, but at least it gets us to be able to transfer fuel for CofG management again, which is the primary function of these tanks.
Anyway, here’s what I changed in the flight_model.cfg for your consideration in solving this issue properly.
FuelFlowAt1PSI Float This is used to calculate the effect of pressure on fuel flow. Value is in lbs per second, and if not set will default to 0.1.
0.1 lbs per second is very low. 10 feet of 1 inch steel pipe with a 1 psi driving pressure and an atmospheric outlet will flow at more like 1.5 lbs per second. This default value for lines without pressures set is probably more appropriate for small planes, think like 1/4" fuel lines.
Looking at the SDK and the potential for mis-configured things that might get thrown out of whack by a minor update, I’d look at FuelFlowAt1PSI settings for accidental massive restrictions.
I seem to have an entirely different problem with the Concorde in SU9… it simply won’t even lift off the ground despite being over 200 knots. Thats after I started up from cold and dark.
I then tried again this time just spawning on the runway. In this attempt, the engines simply quit out after three seconds and it coasted to a stop.
Given that the particularly slow transfer seems to be a long line of junctions without pumps en-route based on the schematic, I’d guess either un/mis-configured FuelFlowAt1PSI could contribute, or something about SU9 is forgetting pressure between junctions. If, looking at a list of various connectable points, you have less and less flow the more junctions you have, the corollary is you also have more lines (more junctions need to be connected by more lines). The SDK says nothing about offering resistance at a junction. The SDK does offer resistance to flow along a line.
My next guess for the transfer issue would be to try setting #FuelFlowAt1PSI:1.5 for a known set of lines, for example the transfer lines you indicated between the junctions on the schematic. (or, some higher-than-0.1 value – no idea what the ‘right’ value is since this relationship between pressure and flow is linear with length but non-linear with velocity, not sure how Asobo modeled this).
Setting the fuel pumps to their book values in PSI and then adjusting the book flow rates from point to point by varying FuelFlowAt1PSI for the lines seems like the rational approach to debugging this system.
I also don’t know how they modeled fuel starvation, the engines “demand” a certain amount of fuel based on their operating point, and a combination of pumps and lines can supply some quantity of fuel based on this simplified pipe model they’ve laid out. I would assume that if the pump x line function outputs a supply flow that’s lower than the engine’s demand flow the result is starvation. Again, FuelFlowAt1PSI would be critical for modeling this system.
Last, the values you likely need for the Concorde are so far beyond what would be supplied using 0.1 pounds per second (about 57 gallons per hour) I could see a tiny tiny change either to this logic or to this default majorly skewing the results of the calculation, especially after a complex system of half a dozen lines in series. Perhaps pre SU-9 they incorrectly did not apply multiple pressure / flow reductions in series, perhaps they changed the default, perhaps perhaps… nonetheless, looks like a good path to explore here given the nature of the bug.
After poking around at airspeeds and altitudes, it appears that Asobo is using the 1976 Standard Atmosphere values for the speed of sound, which at cruising altitudes for Concorde is 573.6 KTAS (Knots True Airspeed). Calculating Concorde’s cruise true Mach number is just dividing ship’s KTAS by 573.6. This can be calculated from KCAS, but it quickly gets complicated at high speeds. Since Asobo already seems to have an appropriate true airspeed, I wouldn’t think too hard about it.
I suspect that the chase around chart you posted has some engine inlet correction, causing a mismatch in Mach and KCAS (Knots Calibrated Airspeed). Also, for the sake of simplicity, I’d just assume that indicated = calibrated since we can probably assume perfect source error corrections in the sim.