The Dink Network

I'd like to propose a new feature for DinkHD, YeOldeDink and any future Dink ports.

A comment by RobJ has given me flashbacks to the days of the browser wars. There are already D-mods that refuse to launch on 'wrong' engine, and I fear that we might be heading to future where we have D-Mods that refuse to launch on anything other than Apache OpenDink™, while everyone has been using LibreDink++ Origin™ for years, and LibreDink++ Origin™ live-patches D-mods based on ther dmod.diz to evade "you are using incompatible port" messages.

I suggest a new function, feature_supported, that checks if a feature exists in current port.
The function would have a signature

bool feature_supported(string name)

.

Here is a piece of code from Hack 'n Slash start.c:

int &chkv = get_version();

//...

if (&chkv <= 108)
{
	&chkv = get_client_fork();
	if (&chkv == 3)
	{
		say_xy("`%THIS ADD-ON REQUIRES DinkHD to play CORRECTLY", -100, 200);
		say_xy("`%YEOLDEDINK may not show `0text `9in correct colours.", -200, 260);
	} else
	{
		say_xy("`% THIS ADD-ON REQUIRES DinkHD to play CORRECTLY", 0, 200);
		wait_for_button();
		kill_game();
		return;
	}
}

What will happen to D-mods like above if we ever get a new Dink port that gives a different value on get_client_fork()? Either we have to hope that the author is still active and updates the D-mod, the port has to check the D-mod against some list of badly behaving D-mods and live-patch matching D-mods, or the D-mods will just fail to run.

With feature_supported(), D-mod authors could do something like this:

if (feature_supported("png images") == 0)
{
	say_xy("`% THIS ADD-ON REQUIRES PNG IMAGE SUPPORT", 0, 200);
	wait_for_button();
	kill_game();
}

if (feature_supported("alpha channels") == 0)
{
	say_xy("`% THIS ADD-ON REQUIRES SUPPORT FOR IMAGES WITH AN ALPHA CHANNEL", 0, 200);
	wait_for_button();
	kill_game();
}

One potential issue with this function is, what happens if the port does not have the feature_supported() function? In this case the game uses last return value of a function, so one should call something that returns 0 immediately before using feature_supported():

//This will make sure that &return == 0 when feature_supported does not exist
math_abs(0);
if (feature_supported("png images") == 0)
{
	//...
}

Authors should really be using "!=" Stacked condition checks to exclude incompatible Dink forks, rather than check "==" and force a single compatible fork. But I guess ppl don't do it because it's seen as unlikely yet another port will come. I dunno.

I've often thought that if the dmod format had been standardised a bit later, it could have become a fully-fledged package/mod manager rather than a simple replacement for zips and RARs, in which if someone had used a graphics pack or a scripting library, it could be auto-downloaded at the same time and reused, saving data for all. Unfortunately this did not eventuate, but something similar could be patched in for checking engine features at the very least.

It might be easier in the future to add a metadata system to Martridge or another frontend that lists required engine features in a YAML file or similar that could assist in warning the user before they attempt to launch. It could very easily be patched into existing mods, as it would involve adding a file rather than having to comb through and edit individual scripts, or could even be included with the frontend itself as a sort of master list. Future engine forks could also read the metadata and have a compatibility mode where they pretend to be another engine etc.

It is worth considering that a lot of recently-released d-mods don't even bother to check to see if 24-bit mode is enabled even if they require it, suggesting sloth would be the main hurdle to adoption.

Authors should really be using "!=" Stacked condition checks to exclude incompatible Dink forks, rather than check "==" and force a single compatible fork.

Agreed. IMO D-mods should also allow user to try to play anyway even if the D-mod thinks it's incompatible, as, for example, Broken Windows does.