AL|EN

You need also provide weidu-BG1EE.log

AFAIR, you can have 10 party members but the game scripts are checking only 6, also no mod support 6+ Party Members.

What? Like Mike says, that's what `revert` is for. No rewriting history at all. Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones. No, it's not. `revert` is the proper way to undo a pushed commit. It creates an inverted commit that undoes the targeted commit entirely. The thing you are talking about, rewriting history, is arguably a bad way to work with pushed commits. It's fine for local stuff, knock yourself out, but once the commit is pushed, you should not rewrite it unless you have very good reason. Beyond `revert`, you "alter" a pushed commit by pushing a new commit that makes the desired changes. wisp, The recommended way is ofc to create next commit where you simply revert changes. I'm just explaining how to remove/alter already pushed commits. Is not desired and should not be generally used but it's good to know why and how to eventually do it.

What? Like Mike says, that's what `revert` is for. No rewriting history at all. Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons). Example: https://github.com/Gibberlings3/immutable/commits/master Suppose that you want to revert this commit: 6189a9f 1. You need to preform "git reset" for the one commit before: "Minimal content in the readme" 915f587 2. Then, you need to "git push --force" to rewrite online history, you basically replacing the online version of the repo with modified local copy 3. Depends on the type of the "reset" operation (mixed, soft,hard), you can also reset all local changes to files - it's like restoring local full backup What is the effect of such operation? When people will try to "pull" from you repo, they will get the error that mismatch history and they can't pull it anymore. So how software devs are dealing with such unwanted side effects? They never rewrite history: they simply revert commits and pushed new one where the changes are reverted. Rewriting history is used only when repo contain sensitive private data like passwords etc. Consider the nature of you project, I won't be a big deal when you rewrite history once a while if you really wanted to do so.

Please don't start with CLI. You will loose time and eventually be frustrated. The GUI will give you very nice flexibility and extra features like diff's across branches/taks without being git cli master. Take look at this: https://www.slant.co/topics/4985/~visual-git-guis and choose any GUI My personal suggestion would be: 1. SmartGit - it's free, cross-platform, every git operation is also presented as commandline version, simple operations take one click, advanced operations are easy, every time that something was fuckedup, I manage to recover without using CLI 2. SourceTree - almost exactly as above, key difference is interface 3. GItKraken - if you like dark interface If you really want CLI: https://gitforwindows.org

From the code perspective, it doesn't matter. I would go for config-default.ini + config.ini since the name without addition is common along other software and indicate "actual' configuration.

Indeed, false alarm

Got a nasty bug: Classic BG2, Polish, Patch 2.5.0.2 It is caused by wiedu 24600, if I use 24200 (shipped with mod), everything is fine. BG2FIXPACK-NALIA8.CRE-Error.zip

@Gwendolyne - the 'configuration' was too long, point taken - filename match pattern of *-config-default.<ini/json> I can present such file to the user in a window, when user click "Save", the configuration file will be copied into "1pp-config.ini" next to "1pp-config-default.ini" Does you mod reads non-default user configuration from 1pp-config.ini? If yes, then everything is ready.

@CamDawg The time gain is huge: 1h vs 2.5h. It's definitely wort the new release, but 32 might be to much. How about 31.1 ?

To confirm the results, FnP 2d07909 + SCS 6795eee. Installed all FnP + SCS components (answer 1), installation took 60 minutes, compared to 2.5h using SCS 31 a302cf8

If you create 'debugs' directory, weidu will put all .debug files there. Anyway, strategems_external is not a problem compared to something like this: https://image.prntscr.com/image/4y645suhRnuMeNSHPLQaww.png

Do you mean you have a temporary fix for this issue? No. But since SCS has github, a competent modder may send such fix as PR.

Fun fact: it seems SCS fails to apply that opcode ---> I mean, everything is fine but the special field: it is set to 0 (IWD mode) instead of 1 (IWD2 mode)........ Guess we need to make a little patch that should go right after SCS........ How about a fix in actual code?

I was busy with other things, the DS patch is a valid reason to make new Ascension release.

CamDawg, just remember that git itself can't store empty directories/files because "no data". You can set workspace to existing directory or add a code to create it at the beginning.

The ini format is suitable for mod metadata. Modder doesn't need to learn about JSON at all for things like mod name, author, description and simple url. The configuration sould be stored in another file anyway (because of the updatemod>overwrite settings problem) so it can have JSON format for those who will need it. But for simple o/1 or true/false options, I think ini will also be fine. So why not support for both ini and JSON? I think we all agree about 'data inside tp2' as a dead end.

@Mike1072 Thanks for suggestion but it looks like you are to bound to BWS 1. No, not true 2. Doesn't matter 3. No, not true No need for database/cache metadata. The <modname>.ini/json scheme is much better from the bigger picture(simple copy without adding "-metadata"), not from single mod and I'm happy that it's not a problem anymore. @subtledoctor I think that there isn't more to discuss, I've coded it as <modname>.ini/json + [Mod] file header with better named keywords

Got it, that's why I revert them and put them into separate branch + PR - if you accept such addition (you can even modify them before accepting), you can simply accept PR, the changes will land into master branch etc. If for any reason, you don't like them or you want to write different code etc, you just decline PR.

Why you renamed the file? It's literally ".gitignore" with a dot at the beginning.

I've made few commits to SCS master branch to show you how it would look like, then I revert them, then I created a PR with changes I would like to see, but if I put metadata on top, READ_2DA_ENTRY_FORMER will fail to read ini. Is there any standard way to overcome this? This was my initial reason to move "variable number" 2DA data outside of stratagems.ini and put it into settings.ini.

SCS 31 Release is fine, you were unlucky enough to use master branch, now it's fixed and the proposed changes are outside master branch.

I've reverted previous commits and made another one, looks better? Right, so you don't mind to keep advanced settings (they won't be show to players) inside stratagems.ini combined with mod metadata?

But <mymod>.ini means stratagems.ini or do you mean literally "mymod.ini"?