pshkong

I see, good to know MakeRunway has better numbers than in the BGL file! I tried to compared with the Google map, some of the airports are quite accurate. I think it is highly dependent on the developers of the airports. If they have done it right (according to the proper definition of runway threshold), the threshold should be where the runway pavement start (i.e. including the threshold offset), and the runway end line point should exclude the offset. The runway length should include the offset too. I guess that's not strictly defined in the sim so there are different ways of doing it... Regards, Phil

Thanks! Very clear. With best regards, Phil

Just a small question about make runway, how is the threshold offset being dealt with? Does the threshold include the offset or not? Many thanks!

The new version works like magic! Thanks! Ha... nice, I've unearthed an ancient bug. I am using C++ so the binary file is way more efficient way to work with, at least in my case. 🙂 patch_log.txt

Sorry for the late reply. I am using P3D v5.3 and MakeRunway 5.128. I dump a list of problematic airports in the attach file. I think most of them are default airports. The CSV file is OK, so I guess its the problem of BIN file generation. Thanks! patch_log.zip

Hi Pete, I hope I had posted on the correct forum. Recently, I have been playing with Makerunway's binary file. I found that there are some errors in the wRwyNum and chDesig field of the R5.bin file. For instance: In R5.bin chICAO, wRwyNum, chDesig CYLT,50,\0 ENKR,240,\0 UENN,2602,C ESMS,1705,L In R5.csv CYLT,0050 ENKR,0240 UENN,0260 ESMS,0170 So I found that the wRwyNum sometimes is showing an extra trailing zero and/or with an unspecified number attached to it, and the chDesig field sometimes have \0 as the content. I tried to programmatically filter out these spooky entries, but rRwyNum = 40 and rRwyNum = 50 will overlap with SW-NE, and E respectively. Do you have an idea how what's going on? Thanks!