MOD_FOLDER variable should not be set via using BACKUP keyword content

[AL|EN]

Hi,

MOD_FOLDER variable should not be set via using BACKUP keyword content, since people try to do "Immutability and encapsulation in mod design"
https://www.gibberlings3.net/forums/topic/29677-immutability-and-encapsulation-in-mod-design/?page=1

So BACKUP path is completely different than standard ones: https://github.com/Gibberlings3/immutable/blob/master/mymod/setup-mymod.tp2#L6

MOD_FOLDER should be taken directly from tp2 filename, without "setup-" to have them matched.

[The Imp]

And why in the freaking hell would you ever need the backups to be away from the mods own workspace folder ?
You do know that the backup folder and the sub-folders are created during the install process... so you only need to push the delete button once when you want to move the folder from an installed game to a clean folder that's used to package the mod(as you need a renamed-weidu.exe in it too).

[AL|EN]

Jarno, calm down. History show us that while it's a matter of single button click, modders often forget about it. But more importantly, it's not what my post is. It's about the variable which suppose to have "string value of the folder name where mod data/files are stored". I'm saying that using using BACKUP keyword content might worked for the last 10 years but it breaks today because if someone is using different BACKUP path, this variable became useless.

[The Imp]

Jarno, calm down. History show us that while it's a matter of single button click, modders often forget about it. But more importantly, it's not what my post is. It's about the variable which suppose to have "string value of the folder name where mod data/files are stored". I'm saying that using BACKUP keyword content might worked for the last 10 years but it breaks today because if someone is using different BACKUP path, this variable became useless.

Then simply learn to use the already 10 years working programming restraints.
This is unless you(or anyone) can show me that it would allow better usage of the application. Like the conversion of data from another game... but that's highly doubtful, as the converters do this already, but of course, I will miss things anyone in the know might be able to come up with if it wasn't so, but that requires a case by case rendition, and assestment by say Wisp.

And assuming I am not calm ... is not a pass.
PS, your archive tool can delete the folders in any given archive without requiring it to be technically opened(aka extracted). Well, at least the WinRAR can... it might take the same effort from the computer, as the bits need to be rewritten, but it spares the human effort.

[Wisp]

MOD_FOLDER should be taken direction from tp2 filename, without "setup-" to have them matched.

This suggestion is not workable. The TP2 can be called anything; in no way does it correlate to the name of the mod folder (examples off the top of my head include Worldmap, FFT and QP). The root of BACKUP is conventionally the same directory as the mod folder.

If your BACKUP is not your mod folder, you can unfortunately not use MOD_FOLDER (and additionally, those parts of the standard and other libraries that use MOD_FOLDER). Given the trade-offs, I'd say the balance leans towards putting your BACKUP in you mod folder, per convention, and accepting that the design of TP2 imposes some constraints. Edit: well, I suppose you could define MOD_FOLDER in your ALWAYS and that'd override the default derived from BACKUP. Yeah, do that.

[Gwendolyne_FP]

It's the first bug that crashed my mod install when I used immutable thingy for the first time. There are two ways to fix it:

1. Use %mod_root% instead of %MOD_FOLDER%.
2. Define %MOD_FOLDER% as before to make WeiDU read it.

and

3. both of them...

[The Imp]

It's the first bug that crashed my mod install when I used immutable thingy for the first time.

Is it ? If so, attach the involved code and we can actually look at what's what.

[AL|EN]

MOD_FOLDER should be taken direction from tp2 filename, without "setup-" to have them matched.

This suggestion is not workable. The TP2 can be called anything; in no way does it correlate to the name of the mod folder (examples off the top of my head include Worldmap, FFT and QP). The root of BACKUP is conventionally the same directory as the mod folder.

It would mean that weidu/tp2 doesn't have concept of "mod folder" as it only care about backup folder (keyword is required). Is that true?

MOD_FOLDER should be taken direction from tp2 filename, without "setup-" to have them matched.

If your BACKUP is not your mod folder, you can unfortunately not use MOD_FOLDER (and additionally, those parts of the standard and other libraries that use MOD_FOLDER). Given the trade-offs, I'd say the balance leans towards putting your BACKUP in you mod folder, per convention, and accepting that the design of TP2 imposes some constraints. Edit: well, I suppose you could define MOD_FOLDER in your ALWAYS and that'd override the default derived from BACKUP. Yeah, do that.

Accepted workaround as a TP2 constraints.

[CamDawg]

MOD_FOLDER should be taken direction from tp2 filename, without "setup-" to have them matched.

This suggestion is not workable. The TP2 can be called anything; in no way does it correlate to the name of the mod folder (examples off the top of my head include Worldmap, FFT and QP). The root of BACKUP is conventionally the same directory as the mod folder.

It would mean that weidu/tp2 doesn't have concept of "mod folder" as it only care about backup folder (keyword is required). Is that true?

Yes. Remember that setup-foo looks for foo.tp2, setup-foo.to2, foo/foo.tp2, and foo/setup-foo.to2 in order. Using either of the first two options, the folder name does not matter since all of the pathing for COPY and BACKUP and whatnot is defined in the tp2 actions. In Ye Olde Days this was not uncommon--one of the first things I did with Item Upgrade was to change its folder name from 'c2' so that I could tuck the tp2 into the mod folder. I just changed another one in the recent spate of portrait pack updates, too.

[AL|EN]

Yes. Remember that setup-foo looks for foo.tp2, setup-foo.to2, foo/foo.tp2, and foo/setup-foo.to2 in order. Using either of the first two options, the folder name does not matter since all of the pathing for COPY and BACKUP and whatnot is defined in the tp2 actions. In Ye Olde Days this was not uncommon--one of the first things I did with Item Upgrade was to change its folder name from 'c2' so that I could tuck the tp2 into the mod folder. I just changed another one in the recent spate of portrait pack updates, too.

What you say is true, but if so, it means that in fact weidu is aware about 'mod folder' because it already trim 'setup-', dot and finally file extension from executable filename and then it look for the tp2 inside specific directory, you own example shows it.

So why %MOD_FOLDER% variable isn't set to this directory but instead it's taken from "BACKUP" keyword?

[CamDawg]

Yes. Remember that setup-foo looks for foo.tp2, setup-foo.to2, foo/foo.tp2, and foo/setup-foo.to2 in order. Using either of the first two options, the folder name does not matter since all of the pathing for COPY and BACKUP and whatnot is defined in the tp2 actions. In Ye Olde Days this was not uncommon--one of the first things I did with Item Upgrade was to change its folder name from 'c2' so that I could tuck the tp2 into the mod folder. I just changed another one in the recent spate of portrait pack updates, too.

What you say is true, but if so, it means that in fact weidu is aware about 'mod folder' because it already trim 'setup-', dot and finally file extension from executable filename and then it look for the tp2 inside specific directory, you own example shows it.

So why %MOD_FOLDER% variable isn't set to this directory but instead it's taken from "BACKUP" keyword?

Only in the last two usages. In the case of 'setup-foo.tp2' with a 'bar' folder in the game directory, setting MOD_FOLDER to 'foo' is incorrect. You could adjust MOD_FOLDER to be set by the setup name in the latter two cases and continue to use BACKUP for the former to enhance accuracy a bit.

[The Imp]

So why %MOD_FOLDER% variable isn't set to this directory but instead it's taken from "BACKUP" keyword?

It's because people usually do things the way they want...
As in, a mod maker doesn't need to "setup" a folder name for their mod to be under, it's whatever the .tp2 notes it to be, it doesn't need to do with the backup folder either. Nor the .tp2 & .exe need to reflect the backups name.

Go figure, this can be done:

Code: [Select]

BACKUP ~impposibblegame/backup~
AUTHOR ~Jarno Mikkola aka The Imp~
VERSION ~v1~

BEGIN ~Adjust monsters hitpoints to be 2*original+40~ DESIGNATED 1

COPY_EXISTING_REGEXP GLOB ~^.+\.cre$~ ~override~
PATCH_IF (SOURCE_SIZE > 0x2cc) BEGIN // kinda protects against invalid files
READ_SHORT 0x48 "ismonster"
PATCH_IF ("%ismonster%" != 10) THEN BEGIN
READ_SHORT ~0x24~ "currenthp"
READ_SHORT ~0x26~ "maxhps"
OUTER_SET curhp = (%currenthp% *2 +40)
OUTER_SET mxhp = (%maxhps% *2 +40)
WRITE_SHORT ~0x24~ curhp
WRITE_SHORT ~0x26~ mxhps
END
END
Does the code come with a definite folder ?!? No. Is there a need to call the .tp2 a "setup-impposibblegame.tp2" No. Nor is there a need to place it in so it's path in an archive can be said to be: impposibblegame.zip\impposibblegame/setup-impposibblegame.tp2. But there's a distinct factor that it can be so... but there's no NEED to do any of that. Call it: nothing and don't even upload the file, just a text print out of it to a forum will do you well in spreading it. This is only of course if the mod doesn't have to copy things from it's own folder.. but that's natural today more than before as there's no need to copy files anymore in large part dues to them being able to be generated with more ease in weidu, via new functions(not talking about media file of course, but of .cre's, .spl's etc small files).

But what's a ".to2", did the toad eat the p's pole ?

[AL|EN]

Only in the last two usages. In the case of 'setup-foo.tp2' with a 'bar' folder in the game directory, setting MOD_FOLDER to 'foo' is incorrect. You could adjust MOD_FOLDER to be set by the setup name in the latter two cases and continue to use BACKUP for the former to enhance accuracy a bit.

No, it's the other way around:
In the case of 'setup-foo.tp2' having a 'bar' folder name in the game directory (for mod files) it's wrong because weidu (at execution time) already parse executable filename (trims 'setup-' and '.exe'), set a specific folder name, then try to detect tp2 filename location by using pattern of 'foo/foo.tp2' or 'foo/setup-foo.tp2'.

This is the weidu code itself: https://github.com/WeiDUorg/weidu/blob/b26ebf21541dc722485b4948b5b058b19c8a28c7/src/weinstall.ml#L48

So if this specific folder name (it might be even \. aka 'current game main folder') is used in order to detect tp2 file location and is the foundation for the execution of the tp2 code itself, I don't see a reason why MOD_FOLDER variable shouldn't use 'value of the previously parse executable filename operation'.

@wisp:
If I change my proposition from:

Code: [Select]

MOD_FOLDER should be taken directly from tp2 filename, without "setup-" to have them matched.to

Code: [Select]

MOD_FOLDER should be taken directly from the 'value of the previously parse executable filename operation'.would it be different? Is there any chance to change MOD_FOLDER value source so modders won't have to use workaround?

[The Imp]

@ALIEN, I fail to see the point of your proposal, aka what benefit does one get from the what you are proposing ? And is there more that you want to say ?
As you can for example use setup-modname.exe to "lauch" the setup-modname.tp2, while in there declare the usage of the "bar" folder as the backup folder, while the mod folder itself can be whatever by this command:
BACKUP ~bar/backup~ like said above. In this case the modname/foo doesn't need to be "bar".

Or is it that you don't understand that the setup-foo.tp2 is directly in the game primary folder... aka:
C:\Users\<username>\Games\BG2EE\setup-foo.tp2 , there is no required subfolder... yes it's cleaner when there is one... but that is not REQUIRED either.

[AL|EN]

Or is it that you don't understand that the setup-foo.tp2 is directly in the game primary folder... aka:
C:\Users\<username>\Games\BG2EE\setup-foo.tp2 , there is no required subfolder... yes it's cleaner when there is one... but that is not REQUIRED either.

I can assure you that I understand tp2 location relativity. I know that sub-folder isn't required but it doesn't mean that 'folder for mod files' doesn't exist. When you take look at weidu code, you will see that in above case, a 'folder for all mod files' is in fact 'C:\Users\<username>\Games\BG2EE\'. So weidu knows the concept of 'folder for all mod files' before it parse "BACKUP" keyword.

@ALIEN, I fail to see the point of your proposal, aka what benefit does one get from the what you are proposing ? And is there more that you want to say ?
As you can for example use setup-modname.exe to "lauch" the setup-modname.tp2, while in there declare the usage of the "bar" folder as the backup folder, while the mod folder itself can be whatever by this command:
BACKUP ~bar/backup~ like said above. In this case the modname/foo doesn't need to be "bar".

Yep I know that you can setup like that. And in the light of what weidu is doing at the execution (determining location of the tp2 via parse executable filename), using BACKUP keyword value to setup a variable called MOD_FOLDER which is treated as a source of the mod files is simply wrong. The path for the weidu backups should have nothing to do with the folder where mod data is stored.

As I said above, I understand that it might be tp2 constraints. But I see a chance to improve MOD_FOLDER variable so modders won't have to use workaround. Let's hear what wisp has to say about that.

[The Imp]

As I said above, I understand that it might be tp2 constraints. But I see a chance to improve MOD_FOLDER variable so modders won't have to use workaround. Let's hear what wisp has to say about that.

Well, then let's see that in action, where do you see the MOD_FOLDER variable to need improving in ?
As in, give a good example of where one could use an "improved" variable in ? As in, a use case from today. Gwendolyne_FP said there to be one... but hasn't replied to my above message, so...

I'll give a totally bad one, but only because of other mods that might do the same:
BACKUP ~backup~
AUTHOR... etc.

[DavidW]

Jarno, calm down. History show us that while it's a matter of single button click, modders often forget about it. But more importantly, it's not what my post is. It's about the variable which suppose to have "string value of the folder name where mod data/files are stored". I'm saying that using using BACKUP keyword content might worked for the last 10 years but it breaks today because if someone is using different BACKUP path, this variable became useless.

Just for the record, SCS started using a backup folder outside the mod directory as of v22, released in February 2013; MOD_FOLDER was introduced in Weidu v232, released in September 2013. So the assumption that MOD_FOLDER reliably picked out the actual mod folder was never correct.

Not that there's anything wrong with MOD_FOLDER in itself: it does exactly what it's documented as doing, it's just that sometimes its name is a bit misleading. (And a couple of standard WEIDU functions - I think just HANDLE_AUDIO and HANDLE_TILESETS - assume MOD_FOLDER is the root of your mod's file system, so you have to be cautious using them, or else redefine MOD_FOLDER in your always, as Wisp suggests.)

[AL|EN]

Ok let's take look at documentation:

BACKUP directoryName

A TP2 File is basically a prologue and then a list of Components. The BACKUP declaration tells WeiDU where to put backed-up versions of files that would be overwritten so that they can be uninstalled later. This directory will be created automatically if it is missing. ... The MOD_FOLDER variable is set to the root directory of directoryName. If directoryName is “mymod/thisIsUnconventional/backup”, MOD_FOLDER is set to “mymod”. ...

Now let's look at the examples. This one is exactly from the docs, it works correctly:
1.

Code: [Select]

BACKUP ~mymod/thisIsUnconventional/backup~
SUPPORT ~alien@alien.net~
VERSION ~0.0.0~

BEGIN "mymod" NO_LOG_RECORD
    PRINT "MOD_FOLDER: %MOD_FOLDER%"
Output:
MOD_FOLDER: mymod

2. But what happen when someone will use slightly different path?

BACKUP ~weidu_external/backup/ModFolderTestB~
AUTHOR ~alien@alien.net~
VERSION ~0.0.0~

BEGIN "ModFolderTestB"
    NO_LOG_RECORD
    PRINT "%MOD_FOLDER%"

Output:
MOD_FOLDER: weidu_external


Documentation is correct at the part of what MOD_FOLDER value is ( root directory of directoryName ). But by doing so, it makes %MOD_FOLDER% variable useless in such case (unless you redefine it later). Also the variable name itself is very misleading! If this is how it works, the variable should be called "BACKUP_ROOT_FOLDER" or something like this since it takes the value from BACKUP keyword variable, split it by "/" or "\" and take the first part.

The good news is that not many modders are using MOD_FOLDER with the combination of altered BACKUP path. The bad news is that this cannot be improved in any way for tp2 except for documentation. But there is a thing in the air called tp3 ...

[Gwendolyne_FP]

2. But what happen when someone will use slightly different path?

BACKUP ~weidu_external/backup/ModFolderTestB~
AUTHOR ~alien@alien.net~
VERSION ~0.0.0~

BEGIN "ModFolderTestB"
    NO_LOG_RECORD
    PRINT "%MOD_FOLDER%"

Output:
MOD_FOLDER: weidu_external


Documentation is correct at the part of what MOD_FOLDER value is ( root directory of directoryName ). But by doing so, it makes %MOD_FOLDER% variable useless in such case (unless you redefine it later). Also the variable name itself is very misleading! If this is how it works, the variable should be called "BACKUP_ROOT_FOLDER" or something like this since it takes the value from BACKUP keyword variable, split it by "/" or "\" and take the first part.

The good news is that not many modders are using MOD_FOLDER with the combination of altered BACKUP path. The bad news is that this cannot be improved in any way for tp2 except for documentation. But there is a thing in the air called tp3 ...

Just for the record, SCS started using a backup folder outside the mod directory as of v22, released in February 2013; MOD_FOLDER was introduced in Weidu v232, released in September 2013. So the assumption that MOD_FOLDER reliably picked out the actual mod folder was never correct.

Not that there's anything wrong with MOD_FOLDER in itself: it does exactly what it's documented as doing, it's just that sometimes its name is a bit misleading. (And a couple of standard WEIDU functions - I think just HANDLE_AUDIO and HANDLE_TILESETS - assume MOD_FOLDER is the root of your mod's file system, so you have to be cautious using them, or else redefine MOD_FOLDER in your always, as Wisp suggests.)

That's exactly the problem I faced.
I solved it using the solutions I gave (switching between variables %mod_root% and %MOD_FOLDER% redefined in ALWAYS block).

[Wisp]

@wisp:
If I change my proposition from:

Code: [Select]

MOD_FOLDER should be taken directly from tp2 filename, without "setup-" to have them matched.to

Code: [Select]

MOD_FOLDER should be taken directly from the 'value of the previously parse executable filename operation'.would it be different? Is there any chance to change MOD_FOLDER value source so modders won't have to use workaround?

It's the same thing, except the executable only has the same name as the TP2 in the setup-mymod.exe form (i.e., a subset of all forms).

CamDawg is correct that accuracy can be improved a bit in those cases mymod.tp2 is located in the mymod/ directory.