adventuregamestudio / ags

AGS editor and engine source code
Other
705 stars 159 forks source link

Escavation of Hob's Barrow will not load. #1796

Closed i30817 closed 2 years ago

i30817 commented 2 years ago

Describe the bug New ags game from wadget eye studios and a collaborator.

Adventure Game Studio v3.6 Interpreter
Copyright (c) 1999-2011 Chris Jones and 2011-2022 others
ACI version 3.6.0.35

Initializing backend libs
SDL Version: 2.0.20
Initializing game data
Located game data pak: /home/i3/Downloads/The Excavation of Hobs Barrow/TEOHB.exe
Opened game data file: game28.dta
Game data version: 50
Compiled with: 3.5.0.26
Startup directory: /home/i3/Downloads/The Excavation of Hobs Barrow
Data directory: /home/i3/Downloads/The Excavation of Hobs Barrow/
Setting up game configuration
Voice pack found: speech.vox
audio.vox found and initialized.
Initializing TTF renderer
Initializing mouse: number of buttons reported is 3
Install timer
Audio driver: pulseaudio
AudioCore: opened device "Default OpenAL playback device"
Supported sound decoders:
 - Play modules through ModPlug : 669,AMF,AMS,DBM,DMF,DSM,FAR,GDM,IT,MDL,MED,MOD,MT2,MTM,OKT,PTM,PSM,S3M,STM,ULT,UMX,XM,
 - MPEG-1 Audio Layer I-III : MP3,MP2,MP1,
 - Microsoft WAVE audio format : WAV,
 - Audio Interchange File Format : AIFF,AIF,
 - Sun/NeXT audio file format : AU,
 - Ogg Vorbis audio : OGG,
 - Creative Labs Voice format : VOC,
 - Raw audio : RAW,
 - Shorten-compressed audio data : SHN,
 - Free Lossless Audio Codec : FLAC,FLA,
Install exit handler
Initialize path finder library
Game title: 'The Excavation of Hob's Barrow'
Game GUI version: 119
Requested script API: v3.5.0-final (7), compat level: v3.2.1 (0)
Plugin 'agsgalaxy' could not be loaded (expected 'libagsgalaxy.so'), trying built-in plugins...
Placeholder functions for the plugin 'agsgalaxy' found.
Plugin 'agsplugin.spritefont' could not be loaded (expected 'libagsplugin.spritefont.so'), trying built-in plugins...
No placeholder functions for the plugin 'agsplugin.spritefont' found. The game might fail to load!
Plugin 'ags_shell' could not be loaded (expected 'libags_shell.so'), trying built-in plugins...
Placeholder functions for the plugin 'ags_shell' found.
unresolved import 'SetSpriteFont' in 'GlobalScript.asc'
unresolved import 'SetVariableSpriteFont' in 'GlobalScript.asc'
unresolved import 'SetGlyph' in 'GlobalScript.asc'
unresolved import 'SetSpacing' in 'GlobalScript.asc'
Loading game failed with error:
Script link failed.
Error (line unknown): in GlobalScript.asc: 4 unresolved imports (last: SetSpacing).

The game files may be incomplete, corrupt or from unsupported version of AGS.
Quitting the game...
***** ENGINE HAS SHUTDOWN

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.

i30817 commented 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).

ivan-mogilko commented 2 years ago

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.

ericoporto commented 2 years ago

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.

ivan-mogilko commented 2 years ago

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.

i30817 commented 2 years ago

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?

ivan-mogilko commented 2 years ago

The detection works by game guid.

https://github.com/adventuregamestudio/ags/blob/2c73c5191c94a3998075602294e4b3a5d835e1ac/Plugins/AGSSpriteFont/AGSSpriteFont/AGSSpriteFont.cpp#L242-L254

ivan-mogilko commented 2 years ago

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);

i30817 commented 2 years ago

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.

ivan-mogilko commented 2 years ago

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.

Dualnames1 commented 2 years ago

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.

i30817 commented 2 years ago

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.

ivan-mogilko commented 2 years ago

@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.

messengerbag commented 2 years ago

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.

messengerbag commented 2 years ago

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.

ivan-mogilko commented 2 years ago

Fine, I had enough of this.

i30817 commented 2 years ago

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.

i30817 commented 2 years ago

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).

ivan-mogilko commented 2 years ago

@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.