projectinfinity IEMod - standardized, universal and cross-platform Infinity Engine Mod Package

[subtledoctor]

The current front-runner (after all of 3 votes, so...), ".iemp" just looks kind of wrong to me.  Just aesthetically - enough so that I was about to file the tie vote for ".iemod."

But it just hit me, and now I know what the answer to the poll is.  The extension which we should hereafter attach to all Baldur's Gate mods is... ".imp."

...Come on.  You know I'm right.  Just try to deny it.

[AL|EN]

26 minutes ago, subtledoctor said:

The current front-runner (after all of 3 votes, so...), ".iemp" just looks kind of wrong to me.  Just aesthetically - enough so that I was about to file the tie vote for ".iemod."

But it just hit me, and now I know what the answer to the poll is.  The extension which we should hereafter attach to all Baldur's Gate mods is... ".imp."

...Come on.  You know I'm right.  Just try to deny it.

The Imp! How we could not think about it  On a serious note, I expected more than 3 votes. Indeed aesthetically ".iemod." wins.

1 hour ago, Wisp said:

Zeitgeist keeps WeiDU in the same directory as itself, which could be anywhere the user has appropriate permissions. On account of the version-pinning thing, I am considering more complicated systems, since we'd no longer be talking about 1 WeiDU executable; rather, it would be 1 for each version in play. I propose the location of WeiDU be left as an implementation detail of the front-end, but I would suggest it's in some location that is user-wide, rather than game-wide. If there is benefit in consolidating in the future, it would be safe to do so then.

The source of the weidu/tools doesn't really matter. But when those tools will be copied by manager into the game directory itself, which directory structure they should have, in order for the tp2 code of the mod to use the path?

<GameDir>\IEModTools\iconv-1.16.0.0\iconv.exe

Or did you have something else in you mind? Like global paths "%userprofile%\IEModTools\iconv-1.16.0.0\iconv.exe" ?

1 hour ago, Wisp said:

If I get to decide, I say .iemod.

Less letter salad + better aesthetically. We have a winner: .iemod.

1 hour ago, Wisp said:

I have no real objections to those restrictions on filenames or package contents, but I see no reason to prohibit override/, tmp/ and temp/. As long as it is not $GAME_DIR/override, it seems kind of arbitrary.
I suggest dot-files (and directories) should also be filtered out, or at least the ones used by git. Off-hand I can't think of a good reason for wanting to include dot-files, and if there are any present in the mod tree, chances are they are not intended for distribution in this context.

My concern was only about top-level directory. It is literally "$GAME_DIR\override" when you unpack a mod package with root 'override' folder:

Mymod\
Mymod\Mymod.tp2
override\<RandomGameFiles>

into $GAME_DIR. Since we are talking about this, what about other 'game folders' like: data, lang, music etc? Should package system allows top-level directory names which are the same as main game folders?

+1 for .dot files and .dot directories.

1 hour ago, Wisp said:

That is not quite an accurate assessment. Backward compatibility will still very much be a thing. Version-pinning would be optional, so all unpinned mods would need WeiDU to remain backward-compatible. It would allow those modders so inclined to get off the ride, as it were, and remain on some specific version indefinitely. Very hypothetically, it would also allow breaking changes to be made, since you could branch off the last non-breaking version and put it on life-support; breaking changes would be opt in. However, it's both exhausting and infuriating to be working against something that makes frequent breaking changes, so I wouldn't expect a great many of those, in any event.

That's off-topic but is this is also valid for tp3? (If it's not one line answer, we can move this part of the discussion into PPG Roadmap 2 topic)

[Wisp]

16 hours ago, AL|EN said:

The source of the weidu/tools doesn't really matter. But when those tools will be copied by manager into the game directory itself, which directory structure they should have, in order for the tp2 code of the mod to use the path?

<GameDir>\IEModTools\iconv-1.16.0.0\iconv.exe

Or did you have something else in you mind? Like global paths "%userprofile%\IEModTools\iconv-1.16.0.0\iconv.exe" ?

Oh, you mean like that. For Zeitgeist I solve this by running the WeiDU process with its working directory set to the game directory and a local process environment that has the tools directory on its PATH. That way the location of the tools is transparent to mods. I have not yet gotten around to making the corresponding change to the relevant WeiDU functions; to allow them to use system executables and optionally free the modder from needing to include the executables in the mod itself. If it's agreeable to you, I imagine you could do the same. The guarantee would then be that if a mod manager is running the show, the relevant tools exist on the PATH and can be called without specifying their location.

 

16 hours ago, AL|EN said:

Should package system allows top-level directory names which are the same as main game folders?

Excluding all  top-level features of the base games is a good idea, yes. Mods should not overwrite anything (but possibly themselves, or an unfortunately named other mod, I suppose) when extracted.

 

16 hours ago, AL|EN said:

That's off-topic but is this is also valid for tp3? (If it's not one line answer, we can move this part of the discussion into PPG Roadmap 2 topic)

Yes, once the format is well-defined.

Edited June 27, 2019 by Wisp

[AL|EN]

1 hour ago, Wisp said:

Oh, you mean like that. For Zeitgeist I solve this by running the WeiDU process with its working directory set to the game directory and a local process environment that has the tools directory on its PATH. That way the location of the tools is transparent to mods. I have not yet gotten around to making the corresponding change to the relevant WeiDU functions; to allow them to use system executables and optionally free the modder from needing to include the executables in the mod itself. If it's agreeable to you, I imagine you could do the same. The guarantee would then be that if a mod manager is running the show, the relevant tools exist on the PATH and can be called without specifying their location. 

If you can change weidu to use globally available tools, that's even better. Installing those and adding them to PATH is easy. I will do it, no problem.

1 hour ago, Wisp said:

Excluding all  top-level features of the base games is a good idea, yes. Mods should not overwrite anything (but possibly themselves, or an unfortunately named other mod, I suppose) when extracted.

Wonderful, let me arrange all the pieces together.

[AL|EN]

So... I got a list of excluded

only top-level files/folders:

CD0
CD1
CD2
CD3
CD4
CD5
CD6
cache
characters
data
debugs
dlc
lang
movies
mplayer
mpsave
music
override
portraits
save
script compiler
scripts
sounds
temp
tempsave
workshop

All levels files/folders:

__macosx
$RECYCLE.BIN
backup

.*
*.7z
*.bak
*.bat
*.iemod
*.rar
*.tar*
*.tmp
*.zip
bgforge.ini
Thumbs.db
ehthumbs.db

Is there anything I miss?

Edited July 3, 2019 by AL|EN

[kjeron]

folders:

• dlc
• workshop

[AL|EN]

24 minutes ago, kjeron said:

folders:

• dlc
• workshop

Correct, thanks.

[Leeux]

Also, you should exclude the desktop.ini files generated by windows explorer too...  Some mods seem to contain them!

 

[AL|EN]

7 hours ago, Leeux said:

Also, you should exclude the desktop.ini files generated by windows explorer too...  Some mods seem to contain them!

That's a feature of some of G3/SHS mods:

the mod folder icon is changed when viewing it via Windows Explorer.

[Leeux]

2 minutes ago, AL|EN said:

That's a feature of some of G3/SHS mods:

the mod folder icon is changed when viewing it via Windows Explorer.

Oh right, you're right... I saw some mods like that, true! Sorry for the false report then...

I tend to hate them myself, they're annoying when having to clean the installation up, requiring an extra prompt on deletion due to them being marked as system/hidden 

[AL|EN]

Just now, Leeux said:

I tend to hate them myself, they're annoying when having to clean the installation up, requiring an extra prompt on deletion due to them being marked as system/hidden 

I hate that too! Great idea for new PI feature

[AL|EN]

@lynxCase-Sensitivity problem:

- Windows and macOS don't need renaming mod files as lowercase
- Linux need this, unless case-insensitive partition (best solution)

@Wisp

How about we leave mod files intact and let mod manager to preform 'ToLower()' ?

 

[lynx]

Linux doesn't need it either, unless the mod author is inconsistent in their casing of the same filenames. Or unless weidu requires it, which I doubt (it comes with tolower to fix the original chitin/files).

[Jarno Mikkola]

2 hours ago, lynx said:

Linux doesn't need it either, unless the mod author is inconsistent in their casing of the same filenames. Or unless weidu requires it, which I doubt (it comes with tolower to fix the original chitin/files).

Right, you are looking this from the perspective of only Linux mod maker.

But the overall idea is to make EVERY mod compatible with all the OS'es, and the process of installing them ... aka the same as BWS ... but with all the OS'es. Platform that NEEDS consistent characters, with capital and non-capital being different ones. AKA, you either skip the compatibility of Linux, or you ToLowel every-fucking-thing. Because you can't trust the mod makers to be consistent... cause they are not(aware of the necessity of being case-sensitive). Case-and-point: Just look at the PC BG1EE in-game files. Case sensitive as.. 

..my ugly Imp @$$. 

[kjeron]

I don't have enough understanding of the issue regarding case-sensitivity, so apologies if these are not relevant:

Portrait files still require uppercase in the EE's to be detected and assigned properly.

You can break a mod if you change it's files to lowercase, and it uses weidu's SOURCE_RES/DEST_RES variables from it's own files assuming them to be in uppercase (the game requires uppercase resource strings in some fields).