Making ZoneBuilder a separate EXE

[Rackover]

I think we should investigate on the possibility to make ZoneBuilder a separate EXE while retaining the same codebase. That would mean using compilation macros to build either one project or the other from the same codebase - producing two DLLs, and then we can use the existing iw4x.exe and a zonebuilder.exe (identical) to start either.

What problem will this solve? It is not obvious to people that IW4x comes with a fully fledged zone tool and starting it requires fiddling with a shortcut or setting up a batch script - it's not user friendly.

What other alternatives have you already considered? Shipping the client with a batch file could be a start but i frankly don't think it's a very robust solution, nor a very elegant one.

[mxve]

If a zonebuilder.exe has to be shipped additionally to the zonebuilder.dll anyways, wouldn't a small zonebuilder.exe that runs iw4x.exe -zonebuilder <additional args> be an easier solution? As you said shipping a batch file isn't a very nice solution, but an EXE is a good compromise in my opinion, allowing for a custom icon and metadata being set.

Is there a use case that heavily profits by having only zonebuilder instead of all of IW4x installed? I think separating it into 2 DLLs just for the sake of making it easier to see that zonebuilder exists and additionally shipping basically renamed variants of iw4x.exe and iw4x.dll isn't that elegant either.

Also in my opinion right now IW4x is very easy to build, even with no experience with the project, could adding macros for conditional compilation complicate the initial setup/build process?

[Rackover]

The problem of making another EXE start iw4x.exe with the -zonebuilder argument is that now if you delete IW4x.exe because you just want to use zonebuilder, it doesn't work, and that could be unexpected. Also it might become harder to pipe the output of zonebuilder to an external program like MPU does it, if it starts a subprocess instead.... maybe? :I It feels shoddy to me but maybe I'm mistaken.

I think the benefit of Macros is it would also help split up the code between completely separate parts of the client that don't talk to each other anyway - reducing both compilation time and complexity in the library. Right now, some parts only useful to zonebuilder are actually running in the client on occasions, and those are easy to miss. IF they were compiled separately, maybe, it could be better?

There is also an overarching issue of maybe trying to convert IW4x.dll to run as an EXE the way Open IW5 does it. It might not be insanely hard. It's hard to say. Maybe this should be given a try before trying to separate Zonebuilder?

[mxve]

The problem of making another EXE start iw4x.exe with the -zonebuilder argument is that now if you delete IW4x.exe because you just want to use zonebuilder, it doesn't work, and that could be unexpected. Also it might become harder to pipe the output of zonebuilder to an external program like MPU does it, if it starts a subprocess instead.... maybe? :I It feels shoddy to me but maybe I'm mistaken.

Checking for the existence of iw4x.exe would be mundane, possible other dependencies could be verified by it too if necessary. It would probably have to run it as a child process, yes. I still believe this would be the "cleanest" way of wrapping the -zonebuilder arg in a runnable format and having it shipped in a timely manner. Everything else seems like rather big undertakings that may run into issues during implementation or stop being worked on. Also when separating IW4x and zonebuilder into different binaries works out, this exe can be replaced with the new zonebuilder.exe and it should behave the same to the end user.

I think the benefit of Macros is it would also help split up the code between completely separate parts of the client that don't talk to each other anyway - reducing both compilation time and complexity in the library. Right now, some parts only useful to zonebuilder are actually running in the client on occasions, and those are easy to miss. IF they were compiled separately, maybe, it could be better?

I can't say too much about this as I don't know the codebase well enough, if you think it would reduce complexity thats definetly a big plus.

There is also an overarching issue of maybe trying to convert IW4x.dll to run as an EXE the way Open IW5 does it. It might not be insanely hard. It's hard to say. Maybe this should be given a try before trying to separate Zonebuilder?

Having iw4x.exe distributed through the rawfiles always had a bit of a weird feel to it. But if iw4x.exe is removed and the client uses the iw4mp binary there may (or rather will) be compatibility issues with different versions that would need to be addressed somehow. That's not just limited to people using older versions, but different regions may have slightly differing binaries too. The server binary Open IW5 uses is probably the same across all regions.