[3.2] Custom IWADs not launchable via -iwad

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [3.2] Custom IWADs not launchable via -iwad

Re: [3.2] Custom IWADs not launchable via -iwad

by _mental_ » Mon Apr 02, 2018 7:26 am

Made duplicates removal consistent for all IWADs in c70f9cf.

The idea with usage of full path for duplicates check is nice. It requires a bit more effort though.
Lack of cross-platform path resolution and comparison is the main problem here.
Also, the detection should be implemented for all IWADs replacing existing name-based system.

Re: [3.2] Custom IWADs not launchable via -iwad

by _mental_ » Mon Apr 02, 2018 1:30 am

The case with multiple references to the same IWAD isn't handled indeed. Before the given commit duplicates were detected by their names only.
Full paths are not stored in the corresponding IWADs list at the moment. I'll try to fix it without significant changes.

Re: [3.2] Custom IWADs not launchable via -iwad

by Graf Zahl » Sun Apr 01, 2018 2:16 pm

It SHOULD eliminate duplicates with the same full path, though, in case two directories in the search path point to the same directory.

Re: [3.2] Custom IWADs not launchable via -iwad

by _mental_ » Sun Apr 01, 2018 1:09 pm

Yes, this is a known side effect of this change.

EDIT: To clarify, this commit doesn’t add duplicated entries for custom IWADs but removes elimination of entries for custom IWADs with the same name.

Re: [3.2] Custom IWADs not launchable via -iwad

by SanyaWaffles » Sun Apr 01, 2018 1:05 pm

now all ipk3s are duplicated. Was that intentional?

Re: [3.2] Custom IWADs not launchable via -iwad

by _mental_ » Sat Mar 31, 2018 6:36 am

Fixed in b36fc82.

Re: [3.2] Custom IWADs not launchable via -iwad

by _mental_ » Sat Nov 18, 2017 6:39 am

SiFi270 wrote:I've noticed that Rise of the Wool Ball is also subject to this despite officially being recognized without an "i" in its file extension or anything. Is that one just an oversight?
It was a different bug, fixed in 80b47ca.

Re: [3.2] Custom IWADs not launchable via -iwad

by SiFi270 » Fri Nov 17, 2017 10:53 am

I've noticed that Rise of the Wool Ball is also subject to this despite officially being recognized without an "i" in its file extension or anything. Is that one just an oversight?

Re: [3.2] Custom IWADs not launchable via -iwad

by drfrag » Thu Nov 02, 2017 1:09 pm

I know i'm not invited to this party but IMHO for now the best option is doing what _mental_ is proposing.
If it works it works. :)

Re: [3.2] Custom IWADs not launchable via -iwad

by Korell » Thu Nov 02, 2017 6:40 am

Rachael wrote:That isn't the report. Try for example Castlevania mod - what counts is launching it from the command line.

If you started Doom 2 last time you used GZDoom, and then typed the following at the command line:

Code: Select all

gzdoom -iwad castlevania.ipk3
It will either show the IWAD box or start Doom 2. It will ignore your -iwad request.
I had noticed this too when I tried playing Castlevania on it's release night (GZDoom 3.2.1), as I always write myself batch files to launch GZDoom and any mods I want to use. I just thought it was because it wasn't an official IWAD and so that's why the IWAD selection menu was showing up. In the end I changed my batch file to use Doom2.wad as the IWAD and load Castlevania.ipk3 with the -file parameter. I've not seen any issues loading it this way, but if this gets fixed so that I can then load it via a batch file without Doom2.wad that would be great.

Re: [3.2] Custom IWADs not launchable via -iwad

by Rachael » Thu Nov 02, 2017 5:13 am

I suppose I could try it, but I can't make any promises.

I'll probably just develop simple {return 0;} functions until it reaches a state where it compiles again, and then build it up from there.

Re: [3.2] Custom IWADs not launchable via -iwad

by Graf Zahl » Thu Nov 02, 2017 5:07 am

The right thing to do would be to take d_iwad.cpp, make some notes what actions it performs, then throw it away and redo from scratch. Essentially all it needs to output is a list of files to use which then gets passed to the resource manager (w_wad.cpp.)

Re: [3.2] Custom IWADs not launchable via -iwad

by Rachael » Thu Nov 02, 2017 4:49 am

I would've been willing to rewrite the IWAD detection mechanism but the problem is expressing my ideas on how to do it into actual C++ code is not that easy. I have absolutely zero experience with ZDoom's file manipulation systems, and I suspect that it's a spaghetti code mess where cleaning it out is going to take an effort pouring over multiple files just to remove the relevant bits out. I was all over the place across two files just implementing the zd_extra.pk3 loader, and that doesn't even count the shenanigans that occurred in the much wider codebase with some of the code making assumptions that the IWAD would never be past file #1.

(I did it the way I did because if an IWAD specifies its own resources it should never be overridden by zd_extra - that would cause its own issues)

Re: [3.2] Custom IWADs not launchable via -iwad

by _mental_ » Thu Nov 02, 2017 4:29 am

Rewriting IWAD detection and loading is out of scope for me. The best thing I can do at the moment is to fix bugs and this one in particular.
If the duplicate check I mentioned is needed another solution is to skip this check when -iwad is specified and the file is accessible.

Re: [3.2] Custom IWADs not launchable via -iwad

by Graf Zahl » Thu Nov 02, 2017 3:19 am

The entire IWAD selection process is just awful. When extending it for custom IWADs I wasn't able to sanitize it entirely. It may be smart to just throw it all away and start fresh - but I simply do not have the time for such a thing right now.

Ideally it should work as follows:

1. Specifying -iwad must be absolute and do no further file name checks at all. Any file loaded this way must be fully identified before being allowed to be used.
2. The IWAD search process should only start if -iwad failed.
2. If a single WAD is being loaded with -file, it should also be checked as an IWAD to allow drag & dropping IWADs.

Top