nofaceinbook / muxp

Mesh Updater X-Plane
GNU Lesser General Public License v3.0
18 stars 3 forks source link

muxp hangs when executed with the target dsf already present #36

Closed marangonico closed 4 years ago

marangonico commented 4 years ago

muxp execution with the attached configuration is completed correctly on the first run (target dsf is absent). If re-run for a second time, it hangs during the "cut_polygon.casera_1738" command processing.

muxp_files.zip

nofaceinbook commented 4 years ago

Did apply the same changes to a dsf tile that was alrady changed? This will most often fail, especially on cut commands, as you enter then edge cases that are really hard to solve. That is the reason why muxp usually checks for conflicts of already applied updates to same area of mesh. So when using e.g. IGNORE as conflict strategey it is recommended to always use the original dsf as source.

marangonico commented 4 years ago

I was simulating the user installing the mesh for a new scenery. The .muxp was the one provided by you to be tested in combination with the .exe, and yes it has IGNORE as the conflict strategy.

Would it be possible to detect if the user has already applied a patch and warn it? Or skipping the generation? Maybe storing the hash of the resulting dsf?

What do you think?

nofaceinbook commented 4 years ago

This detection is exactly what happens when idenifying conflicts. But not if you set conflictStrategy to IGNORE. Sorry, this was my fault. muxp.config should have the following entry: conflictStrategy: ORIGINAL This means that always the ORIGINGAL dsf is adapted, which will work. When you would like to skip set it to CANCEL. When you leave it empty the ugly conflict GUI will come up and user can choose on his own.

muxp does store all applied changes in dsf properties keys inside the dsf file. You will see them relativly at the beginnig when you open an adapted dsf file.

BUT I just saw that the scenery is now added twice to scenery_packs.ini. I have to check this and leave this issue open....

nofaceinbook commented 4 years ago

Bug is set for adding scenery pack multiple times in scenery_pack.ini when activate pack is set to 1.

marangonico commented 4 years ago

If you agree, I'll check the scenery_packs.ini insert procedure.

marangonico commented 4 years ago

muxp does store all applied changes in dsf properties keys inside the dsf file. You will see them relativly at the beginnig when you open an adapted dsf file.

So, in a deployment scenario, which conflict strategy is suggested in order to keep previous mesh patches?

nofaceinbook commented 4 years ago

This would be great.

marangonico commented 4 years ago

LOL.. you are lucky then, I'm abstemious :-) I'll create a new issue, I think you can close this one.