-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pwad list issue duplicates #25
Comments
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). |
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:
***@***.***>
|
I did some test, and unfortunately your request cannot be implemented without a major rework, as it will break presets. 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 |
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:
***@***.***>
|
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. |
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.
The text was updated successfully, but these errors were encountered: