7 replies to this topic

[Turambar]

I've noticed that the code of the last component did not reset the array containing the flags of the worldmap areas. Therefore, the flags from the first save (usually, an auto save) would be copied over all other saved games.
For instance, if someone had a new game inside an auto save and a game where he is much further in another save, all areas would result as "not visited" (and possibly not yet reachable) in the other save, or you could have a new game where all areas result already visited if the situation is the opposite.

Unfortunately, CLEAR_ARRAY does not really forget the current values of the array, so VARIABLE_IS_SET would still return 1 after a CLEAR_ARRAY.

What I suggest is to use different arrays for each saved wmp file.
Here's a suggestion of how to fix that:

/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\
/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\
/////												  \\\\\
///// Part 5: Convert old Savegames				    \\\\\
/////												  \\\\\
/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\
/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\


BEGIN @5000  //If you want to uninstall this component, you have to make a backup of your savegame folder manually!
//EDIT: after uninstalling the worldmap, you can install this component again in order to return to the original worldmap. You will lose all information about mod-added areas.
DESIGNATED 3
REQUIRE_PREDICATE ENGINE_IS ~soa tob~ ~This mod can only be installed on BG2-based games~
NO_LOG_RECORD

MKDIR save mpsave
OUTER_SET j=0 //we'll use a different array for every saved worldmap file

ACTION_FOR_EACH dir IN save mpsave BEGIN
  ACTION_CLEAR_ARRAY dir_array
  GET_DIRECTORY_ARRAY dir_array "%dir%" ~[0-9]+-.*~

//////////////////////////////////////
//SOA and TOB
  ACTION_PHP_EACH dir_array AS int => dir BEGIN
/*    ACTION_IF FILE_EXISTS ~%dir%/worldmap.wmp~ BEGIN OUTER_SPRINT worldmap worldmap.wmp END
    ACTION_IF FILE_EXISTS ~%dir%/worldm25.wmp~ BEGIN OUTER_SPRINT worldmap worldm25.wmp END*/
   ACTION_FOR_EACH worldmap IN ~worldmap.wmp~ ~worldm25.wmp~ BEGIN

    ACTION_IF FILE_EXISTS ~%dir%/%worldmap%~ BEGIN
/////////////////////////////////////////
//Store old flag and areanames in a table
	  COPY + ~%dir%/%worldmap%~ ~%dir%~
	    READ_LONG 0xc	   mo
	    READ_LONG mo + 0x20 na
	    READ_LONG mo + 0x24 ao
	    FOR (i = 0; i < na; ++i) BEGIN
		  READ_ASCII ao + i * 0xf0	    old_area
		  READ_LONG  ao + i * 0xf0 + 0x30 old_flag
		  TO_LOWER old_area
//		  PATCH_IF !VARIABLE_IS_SET $flags_array("%j%" "%old_area%") BEGIN //this caused flags from the auto-save (usually) to overwrite those of other saved games
		  SET $flags_array("%j%" "%old_area%") = old_flag //this array will only contain info from THIS saved game
//		  END
	    END //for
	  BUT_ONLY

///////////////////////
//New savegame wmp file
	  COPY_EXISTING + ~%worldmap%~ ~%dir%~
	    READ_LONG 0xc	   mo
	    READ_LONG mo + 0x20 na
	    READ_LONG mo + 0x24 ao
	    FOR (i = 0; i < na; ++i) BEGIN
		  READ_ASCII ao + i * 0xf0 new_area
		  TO_LOWER new_area
		  PATCH_IF VARIABLE_IS_SET $flags_array("%j%" "%new_area%") BEGIN
		    WRITE_LONG ao + i * 0xf0 + 0x30 $flags_array("%j%" "%new_area%")
		  END
	    END //FOR & copy
	  OUTER_SET ++j //update flags_array index
	  END //FILE_EXISTS
    END //worldmap
  END //PHP_EACH
END //dir

I've tested it and it appears to work as expected, and to keep the flags of each areas without mixing them up.

PS: This component clearly states that it can't be uninstalled, and that you must back up saved files manually. Well, actually there is a way to uninstall it. Strange as it seems, that way is to install it again, AFTER uninstalling the other components: that will copy back the old worldmap into the saved game, and keep all flags for all (vanilla only!) areas. So, visited areas will remain visited and so on. Mod-added area flags will instead be forgotten.

[Wisp]

Will fix. Thanks.

PS: This component clearly states that it can't be uninstalled, and that you must back up saved files manually. Well, actually there is a way to uninstall it. Strange as it seems, that way is to install it again, AFTER uninstalling the other components: that will copy back the old worldmap into the saved game, and keep all flags for all (vanilla only!) areas. So, visited areas will remain visited and so on. Mod-added area flags will instead be forgotten.

There is a difference between uninstalling the component and updating the saves with the sans-worldmap-mod worldmap.

[Turambar]

There is a difference between uninstalling the component and updating the saves with the sans-worldmap-mod worldmap.

You're right, it's not the same thing as uninstalling, but the result is IMO quite similar to what is usually achieved after uninstalling a mod (IE, the changes are reverted, but you can still continue with your saved game, at least in certain situations).
I think that a line, suggesting that you can use that component after uninstalling the worldmap in order to get back the original worldmap, inside the readme could be useful

[Wisp]

Yeah, it should be mentioned somewhere.

[Turambar]

Another suggestion, for Linux or OSX:
in lib.tpa, there is

ACTION_IF !FILE_EXISTS "%path%/%map_res%.mos" BEGIN
	ACTION_IF "%WEIDU_OS%" STRING_EQUAL_CASE win32 BEGIN
	  OUTER_SPRINT mosunpack "bp-bgt_worldmap/bin/win32/mosunpack.exe"
	END ELSE BEGIN
	  OUTER_SPRINT mosunpack "bp-bgt_worldmap/bin/%WEIDU_OS%/mosunpack"
	  AT_NOW ~chmod +x %mosunpack%~
	END
	AT_NOW "%mosunpack% -s -f -o %path%/%map_res%.mos %path%/%map_res%.moz"
  END

The chmod command will not work if the game is installed on a FAT or NTFS partition (as many guides for playing on Wine suggest to do); it will not give any error, but won't really work.
What I usually do is:

ACTION_IF !FILE_EXISTS "%path%/%map_res%.mos" BEGIN
	ACTION_IF "%WEIDU_OS%" STRING_EQUAL_CASE win32 BEGIN
	  OUTER_SPRINT mosunpack "bp-bgt_worldmap/bin/win32/mosunpack.exe"
	END ELSE BEGIN
	  AT_NOW ~cp "bp-bgt_worldmap/bin/%WEIDU_OS%/mosunpack" "/tmp/mosunpack"~
// optional: AT_EXIT ~rm -f /tmp/mosunpack~
	  OUTER_SPRINT mosunpack "/tmp/mosunpack"
	  AT_NOW ~chmod +x %mosunpack%~
	END
	AT_NOW "%mosunpack% -s -f -o %path%/%map_res%.mos %path%/%map_res%.moz"
  END

Because the /tmp folder is always on the system partition/one of the system partitions

You can find examples in BGT and the new DSotSC version (you can also see, if you're interested, how to log those commands too, to the .debug file).

Edited by Turambar, 26 February 2012 - 06:05 AM.

[Wisp]

Your scheme will fail for everyone who has /tmp mounted noexec, which is desirable from a security perspective. The real solution to this problem, and all like it, is for the user to place mosunpack on his path and chmod it himself.

Accordingly, BP–BGT Worldmap will attempt to run mosunpack on the path (as well as in the mod directory) before failing. That way the mod will run just fine for 99+% of everyone and the rest have a catch-all solution to fall back on.

Edited by Wisp, 27 February 2012 - 05:51 AM.

[Turambar]

I understand... actually, from what I see on the internet, that's more common on servers than on individuals using Linux (and I don't expect mods to be installed on the former), but it depends on distributions; some can have problems if /tmp is noexec (Debian-based).
I usually prefer not to add too many things to my path, especially for things such as mods and games, but that's a personal choice.
What about copying it to $HOME/.weidu-worldmap, or something similar? I don't think anyone would mount his HOME noexec

Edited by Turambar, 03 March 2012 - 02:26 AM.

[Wisp]

I do not know, it does not get around the problem that it is very unidiomatic to copy executables around like that (perhaps even bad form). Declaring the dependency on mosunpack, along with a few suggestions for how it can be met, and letting the user decide sounds better to me. For most people it won't be a problem if it runs in the game directory.

Edited by Wisp, 05 March 2012 - 04:47 AM.