pwad list issue duplicates

[rye-74]

Hi this is Rye from moddb. I just wanted to pass along an issue i found while using your great app. If you have a wad or pk3 or any file with the same name in different folders only the first one will be picked up. For example, I just made a copy of my ancient aliens folder and as you can see when i reload resources only Ancient Aliens\aaliens.wad wwhere i would also expect to see Ancient Aliens - Copy\aaliens.wad after reloading resources.

[Premo36]

Hi, thanks for the report, It works this way because DML shows folder/paths only from the later betas of 2.4, so most of it's logic is still working around names only. I'll take a look to it but the fix will probably slip to an eventual v2.5b (or even to the 3.X if it's too much tied into the software logic), as the developing cycle for 2.5 stopped a bit over a week ago, and since then It's in a testing-only state, where no new features are implemented. Fixing this issue may lead to new bugs and so I would need to start over again the testing phase, and since from this version it's also the first multiplatform version it would take too much time and it will delay the release more than I wanted (It's planned around the end of April).

[rye-74]

no problem, not a huge deal of course. i wish i could code, I'd help you fix it.

…

On Sat, Apr 16, 2022 at 1:19 PM Premo36 ***@***.***> wrote: Hi, thanks for the report, It works this way because DML shows folder/paths only from the later betas of 2.4, so most of it's logic is still working around names only. I'll take a look to it but the fix will probably slip to an eventual v2.5b (or even to the 3.X if it's too much tied into the software logic), as the developing cycle for 2.5 stopped a bit over a week ago, and since then It's in a testing-only state, where no new features are implemented. Fixing this issue may lead to new bugs and so I would need to start over again the testing phase, and since from this version it's also the first multiplatform version it would take too much time and it will delay the release more than I wanted (It's planned around the end of April). — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANQ6XPSHJDJL3KPKBW36ONLVFLZA5ANCNFSM5TQJDCBQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Premo36]

I did some test, and unfortunately your request cannot be implemented without a major rework, as it will break presets.
DML 2.X store preset in a text file, each row is a key:value pair, where the key is the mod order starting from 0 to N and the value is the mod name (there are also some special non-integer key that are used to store some extra data like the iwad, the engine etc... all values are always a name with no path when is some file on the user system). The problem is that due to the portable nature of DML 2.X paths are not relevant, so that preset can be shared between user or system and work right out of the box. By not storing paths, each name must be different, so even if I remove the same-name filter, while you could see in DML 2.X mods with the same and even playing them, presets will be totally broken because they will select only the first mod with the same name, even if you maybe made the preset using a second mod, because by not storing path it cannot "tell" which one is which. The simpler solution in order to make it work in the current version will be just to rename also the mod in the "copy" folder, so it's a file with an unique name and it will be displayed and handled correctly by DML 2.X. I will try to find a solution to this issue in the 3.X version, but I cannot make any promise as the portabilty and "solidness" of preset between different user/os/systems etc... it's a key feature.

Also could you explain what where you trying to achieve? Because as far as I can remember you're the first person to bring to my attention this issue. Is there a lot of totally different mods that share the same name? Thanks

[rye-74]

Thanks for the in depth answer. No it isn't some big issue. I did come across it once or twice in the real world. When i have the same mod in different folders (i think each folder held a different version) i just thought you could expand your pk and it might be an easy fix. nothing to stress about for sure!!

…

On Mon, May 9, 2022 at 1:25 PM Premo36 ***@***.***> wrote: I did some test, and unfortunately your request cannot be implemented without a major rework, as it will break presets. DML 2.X store preset in a text file, each row is a key:value pair, where the key is the mod order starting from 0 to N and the value is the mod name (there are also some special non-integer key that are used to store some extra data like the iwad, the engine etc... all values are always a name with no path when is some file on the user system). The problem is that due to the portable nature of DML 2.X paths are not relevant, so that preset can be shared between user or system and work right out of the box. By not storing paths, each name must be different, so even if I remove the same-name filter, while you could see in DML 2.X mods with the same and even playing them, presets will be totally broken because they will select only the first mod with the same name, even if you maybe made the preset using a second mod, because by not storing path it cannot "tell" which one is which. The simpler solution in order to make it work in the current version will be just to rename also the mod in the "copy" folder, so it's a file with an unique name and it will be displayed and handled correctly by DML 2.X. I will try to find a solution to this issue in the 3.X version, but I cannot make any promise as the portabilty and "solidness" of preset between different user/os/systems etc... it's a key feature. Also could you explain what where you trying to achieve? Because as far as I can remember you're the first person to bring to my attention this issue. Is there a lot of totally different mods that share the same name? Thanks — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANQ6XPQRDW7D5DJFR7742TTVJFC7HANCNFSM5TQJDCBQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Premo36]

Ok I got it now. I'll see if it's feasible in the 3.X version, although it seems a really edge-case scenario, given also that it would not be usable using the default modlist view (the "name-only" one). Thanks for the feedback! I'm closing this issue for now.