Your thoughts on adding a playtest pop-up with options?

[Norbert]

I'm curious to read your thoughts on the following, especially how SDLPoP/MININIM developers look at this.

- add [to apoplexy] a pop-up when initiating playtesting that allows the user to pick between DOSBox and SDLPoP.

I could still implement this. MININIM has since arrived (Feb. 2016) and should also be presented as a launch option. First, the question is how to best implement this, given there are several options and obstacles. For example, should apoplexy ship with SDLPoP and MININIM, and if not - for instance to always have recent versions, should users manually add them or should there be an auto-download option (download from where? with scripts that ship with apoplexy? or should there be buttons in-program?). There should probably be 'Always playtest with: [X]' checkboxes under each option (DOS, SDLPoP, MININIM) that will auto-pick one of the options until apoplexy is closed. And then there is the challenge of launching the game for each option without messing up the prince/ files. Should a 4th requirement be added for native PoP1 implementations that want to function as drop-in replacements, namely a command-line option that specifies where the DAT files are (which, for apoplexy would then be e.g. "DAT=../prince" or something similar)? And should I add apoplexy to GitHub, and if so before or after adding this functionality? Also, is this even something that the developers of SDLPoP and MININIM would want, seeing MININIM will add an "advanced level editor" and SDLPoP was going towards something similar? Finally, there's also the question of how modders would then easily share their work, if the drop-in replacements wouldn't be in prince/. Related, what about the DOS executable (that should probably remain in that directory by default), if modders choose to launch with a non-DOS option.

[Falcury]

I think it's a good idea.

For SDLPoP, we should probably change the "mod" command-line parameter so that it allows passing the full path to the directory containing the modified DAT files. Then SDLPoP would meet the requirement you mentioned. Right now that parameter only accepts the directory name/path, which is then assumed to be located relative to the mods/ directory.

I would then let SDLPoP be entirely separate from the 'working directory' that contains the modified DAT files. So, it would not be a drop-in replacement as such, more of an alternative launcher for working with the same data files.

I don't really know if it would be best to bundle SDLPoP with apoplexy directly, or to let users point to the SDLPoP directory that they installed themselves. (Or, instruct users which minimum version of SDLPoP to download and where to put it so that apoplexy can find it.) If you choose to bundle SDLPoP, it's probably an advantage that users don't need to do any additional setup. Updating (a bundled) SDLPoP in the future should be as simple as deleting the folder with the old version, and putting the new version in its place, I guess.

And should I add apoplexy to GitHub, and if so before or after adding this functionality?

The answer to "Should I add the source code of my program [X] to GitHub?" should practically always be "yes", right? Regardless of what [X] is

[Norbert]

Thanks for the feedback Falcury.

[oitofelix]

For example, should apoplexy ship with SDLPoP and MININIM, and if not - for instance to always have recent versions, should users manually add them or should there be an auto-download option (download from where? with scripts that ship with apoplexy? or should there be buttons in-program?).

I'd rule out the static shipment of MININIM, because that would inflict dozens of extra megabytes to your package. Auto-download from the official upstream using in-program buttons sounds very convenient and appealing to me. In this case, we can easily standardize an URL for fetching the latest release of MININIM. If you come to think that implementing this feature is not doable in the short term, just a button opening a dialog pointing to the engine website and the integration instructions seems as a good compromise too.

There should probably be 'Always playtest with: [X]' checkboxes under each option (DOS, SDLPoP, MININIM) that will auto-pick one of the options until apoplexy is closed.

Or even better, persist the choice across editing sessions.

And then there is the challenge of launching the game for each option without messing up the prince/ files.

I'm not sure what the difficulties are here, but if there is something that could be done at MININIM's end point, let me know.

Should a 4th requirement be added for native PoP1 implementations that want to function as drop-in replacements, namely a command-line option that specifies where the DAT files are (which, for apoplexy would then be e.g. "DAT=../prince" or something similar)?

AFAIK, MININIM already implements this.

And should I add apoplexy to GitHub, and if so before or after adding this functionality?

I'd suggest to immediately add it, and commit this new feature implementation from there. This way it's theoretically easier for anyone (including MININIM and SDLPoP developers) to help.

Also, is this even something that the developers of SDLPoP and MININIM would want, seeing MININIM will add an "advanced level editor" and SDLPoP was going towards something similar?

Large portions of MININIM's new GUI-based level editor is already implemented. However, I don't see why this feature would exclude the desire for or interest in interoperability between PoP editing tools. I want people to enjoy MININIM, with no chains. If apoplexy is their editor of choice, better yet, this way they enjoy the work of both of us at once.

Finally, there's also the question of how modders would then easily share their work, if the drop-in replacements wouldn't be in prince/.

I hope that for MININIM this question will be answered in a definitive manner on the next release.

Related, what about the DOS executable (that should probably remain in that directory by default), if modders choose to launch with a non-DOS option.

I'm not sure I understand what is the real problem here. If you show a tangible instance of the problem, maybe I could suggest something.

[Norbert]

Thanks for the input oitofelix.
I'll implement auto-download (and update) from the official upstream using in-program buttons.
I implemented something similar for poplaun, so I know what needs to be done.
For both programs, I'd need a <url>...-latest.zip with Windows and GNU/Linux executables included, or something similar.
Plus probably an XML or TXT that can tell me what is the latest version, to prevent pointless downloads.
[Edit: Or the XML/TXT could just give me the full URL of the latest release.]
The <url> bit could be, for example, at github.io or github.com.
We'll work out the details via private messages.

David, do you have any thoughts on all this?

[Falcury]

And then there is the challenge of launching the game for each option without messing up the prince/ files. Should a 4th requirement be added for native PoP1 implementations that want to function as drop-in replacements, namely a command-line option that specifies where the DAT files are (which, for apoplexy would then be e.g. "DAT=../prince" or something similar)?

Now that I think about it, you can already do it with SDLPoP as well:
Change or pushd to the working directory to the directory that contains the modified DAT files. Then launch SDLPoP from there. Then, the DAT files in that directory will be preferentially loaded. If any DAT files are missing, SDLPoP will instead use its own files.
As an alternative, you can use the "mod" command-line parameter, providing a path relative to the mods directory. But that's a bit ugly at the moment. Maybe that parameter should also take absolute paths, or paths relative to the current working directory (in addition to paths relative to the mods folder).

[Norbert]

I've added the code of the new 3.2 release to GitHub.
The program now includes the functionality to retrieve and unpack ZIP files (to customly specified directories), so step 1 of this thread's project is done.
Next, I'll be working on adding the overlay that will allow users to download and use SDLPoP and MININIM for playtesting.
I'm excited about this, because it'll bring new modding options to the general public.

By the way, it was a tremendous pain to get the Windows port to work+compile with cURL+libzip.
But, it works now, so I can start recovering from that process/work.

[Norbert]

The attached image shows what I have in mind.
(In the lower window, the user is hovering over MININIM.)
Does this look okay; can I move forward with this?

[Falcury]

Nice. Looks good, I think?
Will users see the pop-up every time they want to playtest? Or once, when they playtest for the first time, and thereafter if they decide to change the option they chose?

[Norbert]

Or once, when they playtest for the first time, and thereafter if they decide to change the option they chose?

Oh yeah, I'll add a checkbox to the overlay to "Use until I close the application".
That way I won't have to look into creating a settings file somewhere and it'll still be user-friendly.

[Norbert]

Or once, when they playtest for the first time, and thereafter if they decide to change the option they chose?

Oh yeah, I'll add a checkbox to the overlay to "Use until I close the application".
That way I won't have to look into creating a settings file somewhere and it'll still be user-friendly.

So, it'll be like this, essentially. (Checkbox unchecked by default.)
The links at the top will open the default web browser to DOSBox, MININIM, and I guess for SDLPoP either its GitHub or PoPOT page.

[oitofelix]

Very nice!

[Norbert]

Just a short note to let you all know that I'm still working on this.
I'm making good progress, despite many distractions (e.g. leapop 0.9b).

[YURA]

It is the excellent project. Thanks for your works. Continue, I use them at playing the game.

[Norbert]

prince $ ../SDLPoP/prince megahit 1

Works, gives me the edited level of LEVELS.DAT.

prince $ ../MININIM/mininim megahit 1
prince $ ../MININIM/mininim --level-module=DAT megahit 1
prince $ ../MININIM/mininim --data-path=. megahit 1
prince $ ../MININIM/mininim --level-module=DAT --data-path=. megahit 1
prince $ ../MININIM/mininim --level-module=DAT --data-path=../prince megahit 1

None of these give me the edited level of LEVELS.DAT.
I see an unedited level, probably from MININIM's data/ directory.
What should I run?