Call of Chernobyl loading a save completes all current objectives

[AMS21]

Describe the bug
Loading any save game that has active tasks in CoC instantly completes all of them upon loading the save.

To Reproduce
Steps to reproduce the behavior:

1. Start a new game with story mode enabled or accept any tasks from an NPC
2. Save the game
3. Load the same save file
4. All tasks are now completed

Expected behavior
Active tasks stay uncompleted after loading them.

Screenshots, videos
N/A

BugTrap error report
N/A

Desktop (please complete the following information):

• OS: Linux 6.17.7-4-cachyos
• OpenXRay build version 5ad9a8b

Additional context
Not sure why but it seems that after loading the task_complete LUA function always returns true for every task which it did not before loading.

[AMS21]

Okay I think the issue comes somewhere from the alife_storage_manager.script

function CALifeStorageManager_load(fname)
	if not (USE_MARSHAL) then
		return
	end

	local path = fname:sub(0, -6) .. ".scoc"

	local savegame = io.open(path, "rb")
	if not (io.type(savegame) == "file") then -- This check fails as io.open apparently returns nil
		return
	end
...
end

Since it apparently has to do with file IO it might be a Linux issue. Although I'm really not sure why the open call fails as the file definitely exists on my machine and creating the file from the save script works without a problem.

[Xottab-DUTY]

@AMS21, maybe, the file is opened by the engine's FS (LocatorAPI) and it fails because of that? Or the path is wrong?

[AMS21]

@AMS21, maybe, the file is opened by the engine's FS (LocatorAPI) and it fails because of that? Or the path is wrong?

It is the classic Windows vs. posix filesystem problem. The engine's FS stores the paths with forward slashes and passes them like this to LUA and LUAJit calls fopen directly with that given string here.

With this patch it works on Linux

diff --git a/src/xrGame/alife_storage_manager.cpp b/src/xrGame/alife_storage_manager.cpp
index cd21d9191..a59f81f45 100644
--- a/src/xrGame/alife_storage_manager.cpp
+++ b/src/xrGame/alife_storage_manager.cpp
@@ -108,10 +108,16 @@ void CALifeStorageManager::save(LPCSTR save_name_no_check, bool update_name)
 
 void CALifeStorageManager::load(void* buffer, const u32& buffer_size, LPCSTR file_name)
 {
+    string_path os_file_name;
+    xr_strcpy(os_file_name, file_name);
+    #if !defined(XR_PLATFORM_WINDOWS)
+    convert_path_separators(os_file_name);
+    #endif
+
 	//Alundaio: So we can get the fname to make our own custom save states
     luabind::functor<void> funct;
     if (GEnv.ScriptEngine->functor("alife_storage_manager.CALifeStorageManager_load", funct))
-        funct(file_name);
+        funct(os_file_name);
 	//-Alundaio
 
     IReader source(buffer, buffer_size);
@@ -147,7 +153,7 @@ void CALifeStorageManager::load(void* buffer, const u32& buffer_size, LPCSTR fil
 	//Neloreck: For consistency with before/after save callbacks.
     luabind::functor<void> funct2;
     if (GEnv.ScriptEngine->functor("alife_storage_manager.CALifeStorageManager_after_load", funct2))
-        funct2(file_name);
+        funct2(os_file_name);
 	//-Neloreck
 }

It's a bit of a hacky solution but these load callbacks are only used in CoC anyways. The proper fix would probably be to ensure that all stored paths inside the FS Locator are using the correct slashes but I guess that would be a pretty big change with lots of pitfalls. From looking around a bit I've noticed quite a few places which assume forward slashes to be the path separators.

One idea might be to use C++-17's std::filesystem which I believe should handle these 'conversions' internally and get you the "correct" paths.