Closed marangonico closed 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.
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?
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....
Bug is set for adding scenery pack multiple times in scenery_pack.ini when activate pack is set to 1.
If you agree, I'll check the scenery_packs.ini insert procedure.
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?
This would be great.
LOL.. you are lucky then, I'm abstemious :-) I'll create a new issue, I think you can close this one.
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