A Basic Modder's Guide to Git and Github

[AL|EN]

@Luke That's limitation of the submodules. Generalny I would recommend to use "directory junction" if you want to keep some 'libs' folder in sync locally. Then, when you pull or "download master" all those junction directories are normal directories with files.

[Luke]

17 hours ago, AL|EN said:

@Luke That's limitation of the submodules. Generally I would recommend to use "directory junction" if you want to keep some 'libs' folder in sync locally. Then, when you pull or "download master" all those junction directories are normal directories with files.

OK, I see...

So what are you suggesting exactly...?

Edited September 15, 2022 by Luke

[AL|EN]

@Luke Well, you should remove submodule from you git mod repo, clone an repo with the required files into some other folder (eg: IELib) and then create 'directory junction' from that repo into you 'modRepo/modFolder/libs/' directory. So every time when you update the lib repo (previously as submodule) you local mod folder will have those updates. You could even have copies of "IELib" repo with different version for different mods. This require some brainpower and remembering what have you done but is doable.

[subtledoctor]

On 9/16/2022 at 6:20 AM, AL|EN said:

@Luke Well, you should remove submodule from you git mod repo, clone an repo with the required files into some other folder (eg: IELib) and then create 'directory junction' from that repo into you 'modRepo/modFolder/libs/' directory. So every time when you update the lib repo (previously as submodule) you local mod folder will have those updates. You could even have copies of "IELib" repo with different version for different mods. This require some brainpower and remembering what have you done but is doable.

Oh my God that’s amazing. So I could have one set of files with functions and resources shared across all my mods, and only have to update it in one place?? Crap, I wish I knew about this about two years ago

Edited October 16, 2023 by subtledoctor

[Incrementis]

39 minutes ago, subtledoctor said:

Oh my God that’s amazing. So I could have one set of files with functions and resources shared across all my mods, and only have to update it in one place?? Crap, I wish I knew about this about two years ago

I would say it depends a lot on what the changes entail. I would say that it can have disadvantages. Those are:

* If you change your library, some of your mods will break as the changes are so extensive that each mod must be adapted to your new library.

* Adding new features to your library might bloat your mod as these new features are not needed in some mods.

[subtledoctor]

Ya I had a shared library of functions, but it was gigantic and I had to update every mod every time I fixed a bug in one, even if they didn’t use the same functions within that library. Last week I broke it all apart. But there are still some back-end resources shared among the disparate functions, which would be appropriate for this kind of thing. 

[suy]

1 hour ago, subtledoctor said:

Oh my God that’s amazing. So I could have one set of files with functions and resources shared across all my mods, and only have to update it in one place?? Crap, I wish I knew about this about two years ago

Not exactly. There is no way around making new commits to register changes in the repository. The key thing about the repository is that it registers an exact state. If you have a set of files in one location, and that location is shared to two repositories, you'll nave to make two commits.

[AL|EN]

@subtledoctor While using "Junctions" can be very helpful and time-savvy, Incrementis is right. It's possible that the library update made for one mod in order to fix one thing or add a new feature will break another mod because of this 'one little thing'. You can bet that there will be at least one bug that will happen because of it. Having to know a little bit about the nature of your mods, I'm sure that this will be helpful. 

Today, I lean towards that mod components should be monoliths unaffected without dependences. Even if it means that the mod doesn't use the newest, sexiest and up-to-date functions, unless there are bugs fixed, without changing behavior. Mainly because Weidu/IE doesn't have any means for testing mod changes in a running game except actually running the game and verifying everything manually. Having automated tests of the actual outcome of the function/libs would also be helpful. But it's not where we are with Weidu and I doubt that we will ever be.

[DavidW]

18 hours ago, Incrementis said:

If you change your library, some of your mods will break as the changes are so extensive that each mod must be adapted to your new library.

Adding new features to your library might bloat your mod as these new features are not needed in some mods.

Handling library changes is just about good library design in the first place. Once you've designed a function, except in very special cases you shouldn't be modifying (as opposed to adding to) its functionality.

Bloat isn't really a problem: WEIDU loads functions very quickly and they take up very little space compared to other files.

It's worth remembering that we all use at least one function library already: the one that ships automatically with WEIDU. I don't think many people would advocate for stripping that out and getting modders to include WEIDU functions bespoke as and when they wanted them.

[Incrementis]

1 hour ago, DavidW said:

Handling library changes is just about good library design in the first place. Once you've designed a function, except in very special cases you shouldn't be modifying (as opposed to adding to) its functionality.

Bloat isn't really a problem: WEIDU loads functions very quickly and they take up very little space compared to other files.

It's worth remembering that we all use at least one function library already: the one that ships automatically with WEIDU. I don't think many people would advocate for stripping that out and getting modders to include WEIDU functions bespoke as and when they wanted them.

I agree with your argument to some extent. That it is true that good library design is very helpful in the first place. Still, a good design is not a guarantee of perfection, which means the library may change due to different circumstances, such as: Adding new, improved logic that results in one or more new necessary parameters being added, which will then need to be corrected in every mod that uses that function (due to the missing parameter when calling the function).

I think that WeiDU offers integrated libraries/functions makes perfect sense since WeiDU is its own programming language and therefore offers basic functionality requirements (could be even more if you ask me), but external WeiDU libraries should in my opinion be handled differently. For example, if we take every externally implemented library and put it in the lib folder of every mod so that it can be accessed without having to laboriously search through it, then I would call that bloat. It would be like the logic of installing all existing packages in Python, which would be very questionable.

 

[DavidW]

1 hour ago, Incrementis said:

Adding new, improved logic that results in one or more new necessary parameters being added, which will then need to be corrected in every mod that uses that function

This would count as bad design. If you want to include a function in a library, it needs to carry on working just the way it did before if the new parameter is omitted: that is, the new parameter needs not to be necessary.

If you write a library function, and then decide it would have been better done with a different interface, write a new function with a different name.