Issues with file copying/moving

[Colins2]

This is with v0.3.2 Starting out with no already created files the program runs fine but it doesn't move the new DSF file,it remains in the created folder ./muxp/Eartn nav data/etc.... I copied that file to the zzz_Muxp_default_mesh_updates and it worked fine. I decided to change a few parameters and tried to re-run muxp but it wouldn't work, complaining of missing files. After deleting the new dsf in zzz_Muxp.... and the folder in muxp/Earth nav data it worked fine again.

The program just keeps getting better! I wrote a program to allow me to edit the mesh under an airport in a rectangular area defined by me. I process the underlying mesh first and create a new dsf with the edited mesh and then muxp uses that to perform it's magic on the triangles. So far, the results are outstanding!

[nofaceinbook]

Hmm. MUXP only moves original default dsf files from Global Scenery folder to zzzz_Muxp_default... In case you adapt other dsf files they stay at their location. This is with intention. E.g. in case you adapt an O4XP tile then it should still stay in the Custom Scenery folder at that position in order to be still in the same loading hierarchy. In that case it creates a copy of the original file in the existing folder ending .muxp.original. Or was at onther issue?

I'm interested what adaptions you are doing. Something that schould be inclueded in MUXP as well?

[Colins2]

Hi, That's what I understood but I don't think it is working properly just now with version 0.3.2. I have d/l 0.3.3 but haven't tried it yet. I will make a note of any error messages that come up. Nothing gets copied to the zzz_muxp folder, it remains in the ./muxp-master/Earth nav data/±yy±xxx/ folder. When copied manually to the xxx_muxp folder it works fine. That's no big deal but if I want to further modify the file I have to delete everything or I get an error. I delete the dsf in zzz_muxp.../ and also the copy in ./muxp-master/Earth nav data and it all works again. I always use the original dsf file because I read somewhere (maybe WED?) that each time you edit / re-create the dsf it dilutes the accuracy. The recommendation was to always use the original or d/l from the gateway but nothing I am working on exists on the gateway site.

I used the auto-mux feature from my apt.dat file and that seems to work OK, I guess depending on the terrain. In my test case, I just have the runway defined in WED so it has a very small bounding box. Will auto-muxp use the airport boundary if it exists? I haven't tested this yet as it is all rather time consuming, as no doubt you know!

My idea, from using muxp a lot, is that it would benefit from having the underlying terrain dem data as accurate as possible. Muxp does a fine job of creating a splined runway but it doesn't always mesh very well with the surrounding terrain and there are some strange artifacts at times. I am assuming that this has more to do with the existing dem data than what muxp does re-arranging the trias? My area of interest is Asia, especially Papua, Indonesia and PNG. There are some really interesting small airstrips there that are a real challenge both to 'fly' and to create. Maybe checkout Missionary Bush Pilot on youtube for examples in PNG or even more dramatic, Zehr Air in Indonesian Papua.

In brief, what I do is to compare the 3 arcsec SRTM data with Google Earth. I have read that Google Earth is often more accurate as it takes data from many sources to produce it's dem model. I use QGis for this. If they are very similar then I just go with that but often in PNG there are some quite big differences 5+ metres at times which makes it difficult to create runways. In this case, I map an area to include the airport area and edit that with the better values and then patch the dem data section of the dsf. Doing this first, I can use the 'cut_polygon' command with -37268 as elevation and muxp will use my patched data. Similarly, the cut_spline command works better and integrates the runway better with the terrain. I did experiment with meshtool, using the latest SRTM data and having my airport areas as shapefiles so as to prevent any tria apexes being created in there but I found that it spoiled some existing airports and so prefer to use muxp now. I am half-way through writing a manual for my program; I will send it to you or post a link when it is more complete.

Regards Colin

On Fri, 4 Dec 2020 at 01:26, schmax notifications@github.com wrote:

Hmm. MUXP only moves original default dsf files from Global Scenery folder to zzzz_Muxp_default... In case you adapt other dsf files they stay at their location. This is with intention. E.g. in case you adapt an O4XP tile then it should still stay in the Custom Scenery folder at that position in order to be still in the same loading hierarchy. In that case it creates a copy of the original file in the existing folder ending .muxp.original. Or was at onther issue?

I'm interested what adaptions you are doing. Something that schould be inclueded in MUXP as well?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nofaceinbook/muxp/issues/50#issuecomment-738196933, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQF55JIWS3JMNTKYBG5E63SS7J4JANCNFSM4UMDOALA .

[nofaceinbook]

Looks more like you changed your muxp-folder from muxp-master to zzzz_Muxp... (or vice versa) in the config. Muxp only copies default dsf files to the muxp-folder defined in the config file. I'm currently wokring on better integration of cut_spline and cut_polygon commands into the surrundings. With the next release you could define an distance in meter from the cutting line where the elevation is smoothed to match. What could really be helpful to get automated good elevation values for muxp as probably most users will have difficulties to define these manually. So looking forward to your manual :-)

Ah and yes automuxp will make use of the boundary.

And also a link of the first PNG airport making use of muxp: https://forums.x-plane.org/index.php?/files/file/67463-png-airfields-series-1/

[Colins2]

Hmm, I don't recall changing any options in muxp. Anyway it's a minor problem. I have written the first draft of the manual, obviously it needs some 'polishing' VFC Manual https://github.com/Colins2/Vector_File_creator/blob/main/VFC%20User%20Manual.docx Comments welcome

On Fri, 4 Dec 2020 at 22:03, schmax notifications@github.com wrote:

Looks more like you changed your muxp-folder from muxp-master to zzzz_Muxp... (or vice versa) in the config. Muxp only copies default dsf files to the muxp-folder defined in the config file. I'm currently wokring on better integration of cut_spline and cut_polygon commands into the surrundings. With the next release you could define an distance in meter from the cutting line where the elevation is smoothed to match. What could really be helpful to get automated good elevation values for muxp as probably most users will have difficulties to define these manually. So looking forward to your manual :-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nofaceinbook/muxp/issues/50#issuecomment-738832787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQF55I5G6TUQLEELFZSSWLSTD25JANCNFSM4UMDOALA .

[nofaceinbook]

Great. Thanks. So you edit the DEM of the dsf file and then use MUXP to create the TIN for the runway. Right? Currently I just editing the mesh for ESKS Scandinavian Mountains Airport. The DEM are quite wrong, so I had a lot to do with MUXP. With your tool there would be a good base. But the new version of MUXP smoothens also the cuts. So I cut now the runway with correct elevation and smoothen elevation e.g. for 300m in each direction automatically. This fixes also elevation around, but probably not as accurate when having directyl the right DEM.

With regard to your MUXP issue. If you did not change the config. Perhaps you moved muxp with config from one folder to another. If you open the config then you see the MUXP-folder which is the only folder where dsf from X-Plane default global scenery are copied from.

[Colins2]

Yes, that is exactly what I do. It actually looks more complicated than it is but there seems to be a general lack of information and understanding of DEM data. The WED manual only gives a passing reference, no details. Meshtool isn't very informative on DEM data either. I really hope that the next version of X-Plane will support higher density mesh, at least in patches. It wouldn't be feasible to have the whole world in high density due to the space requirements. An uncompressed 1 arcsec tile is about 25mb and that is just the dem data. I did experiment with Meshtool and increasing the settings. It worked but the dsf quickly grew to over 10mb with the more dense TIN.

I'm interested to see the effects of the additional smoothing and how well it fits in with mountain airstrips. I see what you mean about the config file after comparing it with an older version of muxp. I tried to send some images but they are too big for the Github mail system. I will upload to my project page, if I can. Colin

On Mon, 7 Dec 2020 at 06:10, schmax notifications@github.com wrote:

Great. Thanks. So you edit the DEM of the dsf file and then use MUXP to create the TIN for the runway. Right? Currently I just editing the mesh for ESKS Scandinavian Mountains Airport. The DEM are quite wrong, so I had a lot to do with MUXP. With your tool there would be a good base. But the new version of MUXP smoothens also the cuts. So I cut now the runway with correct elevation and smoothen elevation e.g. for 300m in each direction automatically. This fixes also elevation around, but probably not as accurate when having directyl the right DEM.

With regard to your MUXP issue. If you did not change the config. Perhaps you moved muxp with config from one folder to another. If you open the config then you see the MUXP-folder which is the only folder where dsf from X-Plane default global scenery are copied from.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nofaceinbook/muxp/issues/50#issuecomment-739581330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQF55NORXJGQXHLHQBLEUDSTQFNPANCNFSM4UMDOALA .

[Colins2]

I have updated the VFC manual and also put a binary in the repository. The only file you need is the WinBinary.zip and the manual. VFC now creates .muxp files also. https://github.com/Colins2/Vector_File_creator

[nofaceinbook]

Great. I will definitely look into this. But unfortunately I have currently too less time. Will do hopefully next week.