Ability to use a folder as IWAD

[Marisa the Magician]

This is really just an inconvenience for testing standalone games during development, so I guess it wouldn't be a priority, but it is a pain that I have to pack the whole thing into an ipk3 every time I change anything to be able to load it.

[SanyaWaffles]

I'd second this as a feature.

[_mental_]

First of all, why do you think that it's a bug? If you take a look at the corresponding code, you will see that it accepts only a file with one of these extensions.

There is no need to pack everything to .iwad/.ipk3/.ipk7. It's enough to add one file, IWADINFO, and load everything else from a directory as PWAD. DEFBINDS should be in IWAD too, maybe something else I forgot, but most of content is usable as separate files.

Of course, you can invest some time into making it work from a directory directly. Probably, it's quite easy to do.
However, I would say that such feature has a pretty low priority for us.

[Marisa the Magician]

I guess this can be moved to feature suggestions then.

[QuotePilgrim]

Hi.

So I've been working on astandalone game in .ipk3 myself since last month, and as I was trying to figure out how to do it from a directory instead. Eventually I figured out by myself a solution that seems to work perfectly, and since this is a recent thread I decided to create an account just to share my findings.

What I did was create a dummy .ipk3 file containing nothing but an IWADINFO file inside it, so that GZDoom tries to run it as an IWAD when you run it (also you should delete game_support.pk3 and brightmaps.pk3 from your project's GZDoom copy, if you haven't already). This will of course throw an error if you just run GZDoom with no other parameters, but what it accomplishes is you can now run GZDoom like so:

Code: Select all

gzdoom.exe -file <your_project's_directory>

and, boom, there you have it, you can now test your project from a directory so you don't to repackage it every time. You can set up SLADE to run it by adding "file %a" to your game executable's run configuration; I'm not sure how to do it for UDB because I don't use it.

Then, when you're ready to distribute your game online, all you need is to package your directory into an ipk3 file and delete the dummy one.

To be honest I only figured this out because I was curious, I really don't mind editing the pk3 file directly on SLADE haha.

[QuotePilgrim]

Lol I'm an idiot, the solution I described was mentioned literally two posts above. I really need to read more carefully. Oh well.

[Graf Zahl]

I do not see any real use here outside mod development and for that the existing options are good enough

[dawnbreez]

I do not see any real use here outside mod development and for that the existing options are good enough

Disagree. This would be incredibly useful for standalone game development, especially since I use git to do version control on my work. The disconnect between what's in my .ipk3 and what's in the git repo might seem small, but it's a real pain in the ass. Unless there's some major issue with allowing folders to be loaded as ipk3s, I think the community would benefit greatly from making the ipk3 workflow smoother.

[Matt]

What Dawnbreez said.

If you're working on a standalone game like this your workflow is going to be either:

1. every time you want to try out a change, stop everything you're doing, re-archive everything, rename the thing to .ipk3, then run

2. do everything as a mod (with some barebones thing as the underlying iwad) and then convert it all into a new .ipk3 when it's ready to be released

instead of just running the thing right away.


I mean, it is possible to create a batch file to automate 1, but I remember how much of an annoyance that was for compiling ACS every time (creating the file, making sure it was referring to the right folders, removing it from the final pk3)... it's all a bunch of really tiny little things but they're all flow-breaking tiny little things.

[Marisa the Magician]

Honestly I do wonder how quickly I'm chipping away at the life of my SSD by having to repeatedly repackage everything over and over for each small change.