Immutability and encapsulation in mod design

[DavidW]

In case this is any use to anyone, here's an immutable wrapper for HANDLE_AUDIO:

 

////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////
////////////    immutable version of HANDLE_AUDIO
////////////
////////////    Assumes "ext_music_loc" and "ext_audio_loc" have been set appropriately
////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////

DEFINE_ACTION_FUNCTION handle_audio_immutably
	INT_VAR music=0
	STR_VAR	oggdec_path="%MOD_FOLDER%/audio"
			sox_path="%MOD_FOLDER%/audio"
			audio_path="%MOD_FOLDER%/audio"
BEGIN
	OUTER_SET new_files=0
	ACTION_IF music BEGIN
		ACTION_IF !VARIABLE_IS_SET ext_music_loc BEGIN
			OUTER_SPRINT ext_music_loc "weidu_external/music/%MOD_FOLDER%"
		END
		OUTER_SPRINT new_audio_path "%ext_music_loc%"
	END ELSE BEGIN
		ACTION_IF !VARIABLE_IS_SET ext_audio_loc BEGIN
			OUTER_SPRINT ext_audio_loc "weidu_external/audio/%MOD_FOLDER%"
		END
		OUTER_SPRINT new_audio_path "%ext_audio_loc%"	
	END
	MKDIR "%new_audio_path%"
	// copy everything over
	ACTION_BASH_FOR "%audio_path%" ".*\.ogg" BEGIN
		ACTION_IF !FILE_EXISTS "%new_audio_path%/%BASH_FOR_FILE%" BEGIN
			OUTER_SET new_files=1
			COPY_LARGE "%audio_path%/%BASH_FOR_FILE%" "%new_audio_path%"
		END
	END
	ACTION_IF new_files BEGIN
	PRINT "handling audio"
		LAF HANDLE_AUDIO INT_VAR music STR_VAR audio_path="%new_audio_path%" oggdec_path sox_path END
	
	
	END


END

To use: just call handle_audio_immutably, with the same arguments as HANDLE_AUDIO.

(Not extensively tested yet!)

[AL|EN]

FWIW, the immutability of HANDLE_CHARSETS function that is described here, can now be done with out-of-the-box features by using newly added "out_path" parameter. The instruction and examples can be found here.

 

[AL|EN]

I found nice tool to help detection of changes inside mod folder during installation:

FolderChangesView

https://www.nirsoft.net/utils/folder_changes_view.html

Usage should be explanatory, just add folder to watch and start mod installation with every component.

[mickabouille]

Wouldn't git work ?
 

git init && git add . && git commit -m "init"

<installation>

git status

 

Edited May 13, 2023 by mickabouille

[AL|EN]

@mickabouille I've missed this, yep, it's one of the possible ways to check. But there is a chance that the mod author already uses .gitignore to exclude some folders/files so it might not get reliable results.

[AL|EN]

One of the benefits of mod immutability is that "%MOD_FOLDER%" can be used multiple times for many installations, even at once. Instead of coping the mod folder which takes time, the "%MOD_FOLDER%" is "deployed" into the game folder via Junctions/Symlinks/HardLinks instantly. Enabling players to use such an improvement would require the modder to consciously place an additional entry in the .ini file.

@DavidW @CamDawg @argent77 (to name few) Would you be interested in such a feature?

[DavidW]

For end users, you mean? It seems an unnecessary complication: a mod folder is normally pretty small and the time to copy it is very small compared to the installation time.

[AL|EN]

Yes, it's for end users. The coping time depends: coping 20 mods is relatively quick, but 200 mods with BGGO, SoS, RoT, CtB etc might take minutes. I see this as a nice benefit without extra work since immutability is something that you set only once.  I should probably prepare some data and testing but I wanted to get some initial feedback before actually coding such feature.

[Jarno Mikkola]

2 minutes ago, AL|EN said:

The coping time depends: coping 20 mods is relatively quick, but 200 mods with BGGO, SoS, RoT, CtB etc might take minutes.

Wouldn't you rather extract an archive than copy ? Cause yes, extracting data from a smaller source file is FASTER than copying a files form one folder to another, at least in todays computers(multi core) .. I don't know the details, but I know it's true.

[suy]

On 2/1/2024 at 12:55 PM, AL|EN said:

@mickabouille I've missed this, yep, it's one of the possible ways to check. But there is a chance that the mod author already uses .gitignore to exclude some folders/files so it might not get reliable results.

In that case, you can still check with `git clean`, using the `-x` flag. E.g. `git clean -xdn` won't delete anything, but will list the files that would have to be removed.