Closed i30817 closed 2 years ago
It starts if you add a OR to the name recognizing if in the agsplugin file:
else if (apl->filename.CompareNoCase("agsspritefont") == 0 || apl->filename.CompareNoCase("agsplugin.spritefont") == 0)
Although now that i ran it, it has a corrupted font (much like scummvm downstream has a corrupt font in some games).
What is "agsplugin.spritefont"? Is it how user has renamed a plugin? Because if so, I don't think we should support any random names introduced by users. So far this does not look like a mistake in AGS.
I'd rather propose to clarify this with the game developer to see how this had happened. Also double check that they did not use a custom engine (just in case).
Optionally, as a preliminary thought, we may provide a custom mapping for plugin names which you add yourself in config file. Alternatively, you could build a plugin yourself as a standalone *.so and name it to match the game's expectations.
My guess is they are using the clifftop variant of the sprite font plugin, so it should not use whatever they used and use the one we have in our repositories that has additional fixes.
so it should not use whatever they used and use the one we have in our repositories that has additional fixes.
The engine is already using the one from our repository as a built-in plugin.
The problem is that the clifftop variants are triggered by a game detection. Since this is a new game, so the detection does not trigger on it.
This will keep happening, until there will be a proper indication of which variant the game is using, either through a distinct plugin name, or API command that toggles between the plugin "modes".
Alternatively, one could investigate whether having the "clifftop" variant always active will break the other games or not. Because if not, then we could just use it all the time.
Is there any way to force the clifftop variant to test it? I can easily plant a so on the game dir, but it would be the 'normal' one, i think. I suppose it's being forced by the internal name of the project?
Should mention, it's possible to print game guid for the reference, e.g. here: https://github.com/adventuregamestudio/ags/blob/2c73c5191c94a3998075602294e4b3a5d835e1ac/Common/game/main_game_file.cpp#L839
as
Debug::Printf(kDbgMsg_Info, "Game guid: '%s'", game.guid);
Right, i forced that bool to true, then made, renamed and placed the plugin in the game dir. The font works, so that more or less confirms they're using the 'clifftop version'.
The guid if you're wondering about a 'half measure' of hardcoding it is :
{4d1d659d-f5ed-4945-b031-68fedcac7510}
(although this would still require a rename without that or i put in the second post).
Personally speaking, i'm quite fond of the engine ability to run without dlls in the game dir. Good for OS portability, and i suppose, for scummvm downstream instructions.
I'd leave this for a while to consider possible options. Right now our priority is to complete 3.6.0, and I would not want to add any more rushed hacks.
Why are we running Hob's Barrow in 3.6?
Also there's a native port of the game for Linux. So this is even more interesting.
Interestingly, scummvm doesn't actually run it, even with the hacked plugin with the right name. The reason for this is obvious if we check the output:
Plugin 'agsgalaxy' loaded from 'agsgalaxy.dll', resolving imports...
Plugin 'agsplugin.spritefont' loaded from 'agsplugin.spritefont.dll', resolving imports...
Plugin 'ags_shell' loaded from 'ags_shell.dll', resolving imports...
Apparently scummvm loads windows games dlls even on the linux operating system. One more reason to only use builtins.
edit: i'm not actually that sure this is the problem there, since it also has a 'WARNING: TODO: SetCurrentDirectory'. Might just be default variable kayfabe and any dll is not being loaded. Ah well, this is out of topic, so i'll hide it.
@Dualnames1
Why are we running Hob's Barrow in 3.6?
Because this is the official ags engine, and supposed to be backwards compatible; therefore many users use one engine binary to run all previously made games.
Additionally, afaik not every linux system can run the binaries distributed with the ags editor, and their users have or prefer to build engine from sources.
This of course is only suitable so long as the game was not made using a custom version of the engine, since we don't have a requirement of supporting these.
This of course is only suitable so long as the game was not made using a custom version of the engine
… and it's not running a custom plugin that doesn't have a version for the platform in question, surely?
The bug report says that the Windows version doesn't run on Linux, and it seems to be because it can't find the *.so plugins (I imagine that the Windows version only includes the DLLs). This seems like something that shouldn't work.
Also:
many users use one engine binary to run all previously made games.
Is this actually true? I would expect that only a small number of people actually do this.
Fine, I had enough of this.
For the record, the current plugin does work in the 'clifftop' configuration, when inevitably someone else opens the same bug report and gets pointed here. Just build it yourself.
Scummvm now loads the game by using the clifftop variant in their scanner and the inbuilt dll. They already had the variant name for Kathy Rain (apparently the name is used in some versions), so they only needed to change the scanner to use the right flag.
The commit is https://github.com/scummvm/scummvm/commit/23f15cfb2d1e072cc9a9d9131724af75f391f963 (it doesn't reflect on the ini file).
@i30817 i added the hack (or rather extended existing one);
Also added a compilation option for making a plugin strictly Clifftop-games compatible (see comments to 9f5244ad6c3c07b4e1a6c3623d2f508ec93b45f6). This may be useful to build this plugin yourself from our sources for the new games which need it, or for existing games made with the older engine versions (which did not support retrieving guids in plugin API).
Personally, I believe the Clifftop plugin version should have been simply renamed, e.g. like agsspitefont2, then this would be resolved without having to detect games at all.
Describe the bug New ags game from wadget eye studios and a collaborator.
AGS Version 3.6.0.35
Game No demo
To Reproduce start the game on master
Desktop (please complete the following information):
Additonal Information: Obviously this is running the windows version in linux ags. The windows version in wine is fine.