AL|EN

Use Visual Studio Code + BGforge MLS - Visual Studio Marketplace

@MooseMilk It's know issue when you have DPI set to higher than 100%. The workaround is: Used windows Enhanced scaling on app compatibility option.

On 3/6/2024 at 9:37 PM, DavidW said:

Those numbers look broadly compatible with my own observations: a slowdown of about 30-60 seconds at the very start of running the mod, and subsequent slowdowns at the start of every component. The 2.5 minute slowdown for SCS is if anything worse than I recall (but then the architecture of SCS has changed a bit since then).

That might be tolerable for end users (though a 10% slowdown for SCS is not nothing in a mod which already takes far too long to install) but they are intolerable for development, in the quite literal sense that I put LABELs in some years ago, couldn't tolerate the slowdowns, and took them out again.

I have done more testing, LABEL slowdown (pocketplane.net), provided an easy-to-use Testing Suite and offered help if Wisp wanted to do some experiments. It seems that the dummy tp2 has slowdowns also because of LAF. I'm hoping for Wisp to pick up this again. 

Or, weidu could have a command line switch, like "--disable-backup" so the 3rd-party tool could take over the job. It's also useful when a player has no intention to reinstall any mod aka he always starts from a clean installation, like myself. The "BACKUP MyMod/backup" problem can be easily mitigated by weidu itself.

13 hours ago, jmerry said:

The source of legitimate complication is that other languages don't do that "make backup copies of everything" step by default. The "don't back anything up" state that you have to deliberately invoke with a special modifier in WeiDU is normal in other languages.

13 hours ago, subtledoctor said:

Just that any doofus like me can, with Weidu, get the benefit of that without even trying. Whereas, with another language I would have to intentionally set that up, and 1) hopefully I don’t forget, 2) hopefully it’s not too much extra effort, and 3) hopefully I don’t screw it up.

That’s a lot of hopefully!

Even if the WeiDU has build-in backup, I see no difference between:

1. Install weidu mod by launching "Setup-Mod1 --yes" (state of the game files: 1)
2. Install weidu mod by launching "Setup-Mod2 --yes" (state of the game files: 2)
3. Uninstall the Weidu mod by launching "Setup-MyMod2 --uninstall" (state of the game files: 1)

and

1. install weidu mod by launching "Setup-Mod1 --yes",  the state of the game files is saved by an external thing aka MyBackupTool (state of the game files: 1)
2. install a mod using any tool/mod framework (state of the game files: 2)
3. restore game files via MyBackupTool -RestoreState 1 (state of the game files: 1)

This way, you can use pretty much anything to modify game files and still have the ability to 'uninstall mods', no matter how they were made.

@DavidW 

Please forgive my ignorance, I don't get the 'reversible' part. As far as I know, WeiDU reverses its changes simply by making copies of files in various backup folders. So the uninstallation is only a matter of going back to the previous state of the files. I don't see the magic here which would be a source of legitimate complication. But again, I may just don't see oblivious.

3 minutes ago, subtledoctor said:

AL|EN you are being very coy here… the thread is already on the third page. 

I needed some time to gather my thoughts and reflect on them, especially when it comes to the different proposal and their scale. But hey, as you wish  

The number of active WeiDU-only developers is decreasing. Modding with WeiDU involves programming, and there are many programmers out there. We just need to attract them. One of the ways is by allowing modders to use other tools alongside WeiDU. I strongly believe that this could be very beneficial. Creating a WeiDU-like library in Python, C#, or Java could attract hobbyists and professional programmers. They could develop mods using their favorite language or technology, bringing expertise, knowledge, and better tools that could result in better mods. I don't think sticking solely to WeiDU without even considering alternatives is wise. Imagine if the authors of ToBEx/EEEx had thought, "It's not WeiDU, so I'm not going to do it," etc.

In my opinion, it's not about the amount of time needed to learn WeiDU. It's about the fact that you can't use it elsewhere for any other purposes than modding IE games. Even in the hobbyist/professional developer world, language syntax and feature sets are the main reasons why some programmers won't touch another language at all. Of course, some use them all, but that's the minority.

Possible approaches:

- Developing a WeiDU replacement that functions and behaves like WeiDU and uses the same tp2 syntax.
  Apparently, this is in progress by Wisp. https://forums.pocketplane.net/index.php?topic=30011.msg340720#msg340720

- Creating a WeiDU replacement that works like WeiDU but uses tp2 syntax with some additional improvements, also known as tp3.
  Instead of revolution, it's evolution. Depending on the implementation, this could also be what Wisp is currently working on.

- Introducing small, side-by-side tools that are alternatives for specific parts of WeiDU, called by WeiDU itself or outside of it.
  This doesn't pressure the author to be the "next big thing." You can quickly check what works and what doesn't. In the future, you can replace that small part of the file processing with yet another thing. Unlike one big monolith, it has a low cost of making improvements that are breaking changes. I like this approach.

- Developing a WeiDU side-by-side alternative that can do what WeiDU can but doesn't use the same syntax and is not compatible with WeiDU.
  It's a lot of work, yet according to DavidW, "90% of mods use only 10% of WeiDU," so maybe it's not as daunting as it seems? It would be nice for a new tool to have lots of good stuff and/or a so-called "killer mod/feature" to have chances to attract modders.

- Combining the current WeiDU, WeiDU side-by-side alternative, and side-by-side tools with the freedom to call all of them outside of WeiDU at any given time.
  This allows for total freedom in using old and new tools to modify game resources. An easy uninstall/reinstall procedure is pretty much required for a modder's workflow.

I would love to play with the IE engine. Unfortunately, WeiDU puts me off. I don't want to spend another year learning WeiDU only to find that working with it is cumbersome. I would rather use anything else. But going against everything may not be the right solution. Since no alternative to WeiDU has emerged then there must be some deeper reasons/problems for it. Now at least I know that besides binary file modifications, dialogs and installation/reinstallation system are equally important. etc.

5 hours ago, Incrementis said:

Yes, that is exactly the basic routine that I go through. I'm trying to reduce these steps by using Near Infinity. Basically I use WeiDu for implementation purposes and NI for debugging/analysis/testing purposes.

So you don't even start the game, you just refresh resources inside NI and check/verify the desired outcome, correct?

On 3/12/2024 at 5:07 PM, Incrementis said:

This is something I need to test the mods. If the successor doesn't have that, I don't know if I want to use it.

Correct me if I'm wrong, you specifically have 'an installation routine as of:

1. create tp2, install it via setup-mymod
2. launch the game, verify results and quit
3. make edits to tp2, reinstall mod via setup-mymod
4. launch the game, verify results and quit
5. repeat

right? Can I assume that this is the 'spoiled' part?

On 3/12/2024 at 2:49 PM, mickabouille said:

For me that’s the only real blocker.

In my (really limited more proof-of-concepty) experiments with this, I just generate a weidu mod that I then install to keep weidu happy.

Never went really far, really, just generating fixup minimums without needing to remember the baroque syntax of tpX files.

I'm assuming that you creating this "fake tp2" is for mods-in-the-middle? What if the 'backup' system were decoupled and externalized from WeiDU? Would this solve the problem of installing mods/uninstalling only the last one/uninstalling only a few?

Hey,

This is a long overdue post, let's have a loose discussion about this. What do you think are the core bricks that prevent WeiDU's successor or alternative?

My own would be:

• It's too late for a new thing to attract attention, no matter how good it would be.
• It's too much work to learn new, shiny things even just for fun.
• WeiDU interoperability with dialogs added from other mods, you either recreate it or you can forget about adding cross-mod content.
• WeiDU backup system, you either recreate it completely or fail to uninstall/reinstall a mod.
• Lack of accompanying tools that are specifically created for WeiDU.
• Lack of a mod manager that can install WeiDU mods along with mods that are using other 'modding frameworks'.

Those are some loose examples from my memory. I'm not sure about the weight of each thing, or how it affects the subject and I would love to hear your thoughts!

EDIT: I've added 'or alternative' to not limit the potential scope of the discussion.

On 3/2/2024 at 9:38 PM, CamDawg said:

The claim is that it frees us from the tyranny of fixing a DESIGNATED value, which is nonsensical, as that's the whole point of DESIGNATED. It's like arguing that by using DESIGNATED it frees us to change LABELs, an equally nonsensical proposal.

DESIGNATED was created so that mods with multiple components (e.g. Tweaks) could present the components in a sensible order in the installer without causing massive compatibility headaches down the line. Prior to DESIGNATED, WeiDU simply numbered components itself starting with 0, so if you wanted to add components they had to be at the end of existing ones. Tweaks is barely manageable as it is; I want you to imagine the horrific mess it would be if it was organized in a purely chronological order of the components by creation date. With fixed DESIGNATED values I can freely add components where I think they fit in the order, move them around, or do whatever without making David and other modders having to constantly shift around their compatibility checks.

AL|EN's doing a little not-so-subtle lobbying here: no one is using LABELs to check against other components--at least not yet, and this paradigm shift was proposed three years ago. Keeping your component numbers DESIGNATED is more important, and I don't foresee that changing any time soon.

This isn't to say that LABELs aren't useful: they very much are, and you should use them, and they'll become even more useful is we ever get a new version of WeiDU with the proposed changes to LABEL handling. I'm simply clarifying that DESIGNATED is still relevant and not to be discarded, and that changing a DESIGNATED value is exceptionally bad practice.

While there is an appreciation for using LABELs at the end, I fear that the 'nonsense part' is where most people will be turned off, without reading to the end.

The claim is true if you take into consideration the compatibility checks: if your mod uses LABEL for compatibility check, or if an external mod would rewrite its checks to use LABEL, the modder is free to change the DESIGNATED value without breaking other mods, simply as that. There are no claims that 'LABEL can replace DESIGNATED in terms of the order of the components".

The majority of the mods have 1-5 components; often they use DESIGNATED 0, DESIGNATED 1, DESIGNATED 2 ... etc. Those mods could remove DESIGNATED and nothing would happen at all. The purely chronological order is fine for those, so in fact, simply adding LABELs is enough for serving WeiDU compatibility checks (both internally and externally) and PI 'save mod choices' features. There's no need for DESIGNATED if it doesn't add any value.

Changing a DESIGNATED value is an exceptionally bad practice, but there is a technical reason to do it, and if you weren't lucky enough to start with best practices for them, you are inevitably forced to change them at some point.

While the adoption of LABEL for compatibility checks is slow, there are a few mods that use them, with hopes of more to come.

On 3/2/2024 at 9:38 PM, CamDawg said:

... proposed changes to LABEL handling ...

Having the ability for LABELs to control the order of the components would be a nice addition. We can even extend the @suy proposal: let the WeiDU backup system use the label to be more reliable. Where can I read more about the proposed improvements for LABEL, just to avoid duplicating requests?

On 3/6/2024 at 3:21 PM, suy said:

You are also sending a clear message to users: you care less about them.

Don't get me wrong. Your previous message made me consider making a small program that wraps weidu and can accept installing something by label name (I'd make it cross platform, open source, and hopefully easy to use, etc., so it can spread usage of LABEL for more people, not just me). But given that weidu.log only stores component numbers, not using designated component numbers at all, and given David's findings on the bad performance of LABEL, this all points to a promising future for the labels, maybe, but a pretty limited present. This needs work on weidu's side. Note also that the JSON output is marked as experimental, so it's another problem to spread its usage.

PI has been doing what you describe for quite some time without problems. JSON output has been used for more than 5 years and there was only one bugfix, it's hardly 'experimental'. The slowdowns occur only for one, developer-related case having a mod with 150+ components, it's not noticeable for end-users. Not everything has to be done on the weidu side as weidu lacks a 'global' (using one, centralized directory/list of mods that can be used for installation) way of dealing with mods. Not to say that the work is easy and you would have to do workarounds for things that weidu doesn't provide out-of-the-box, but IMHO, you are too focused on problems instead of solutions.

That's fair. Having to wait extra time for component reinstallation can be a PITA. Let's see if something can be done about it.

6 hours ago, DavidW said:

Speaking personally, I'm not using it because adding LABELs to everything still leads to painful slowdowns in mods with very many components.

I'm not saying that you are wrong on this but my tests aren't confirming this. Here are my results when all components are installed (except 100):

| 'ToF Beta 7 tp2: | 'ToF Beta 7 tp2 with LABELS: |
|------------------|------------------------------|
| 18,06 minutes    | 18,32 minutes                |

| 'SCS 35.10 default tp2: | 'SCS 35.10 tp2 with LABELS: |
|-------------------------|-----------------------------|
| 22,44 minutes           | 25,15 minutes               |

Testing procedure, repeat for default tp2 and tp2 with added LABELS:

1. Clean BG2EE, clean extraction of SCS/ToF, don't forget to uninstall SCS if you are testing ToF!
2. Open PowerShell, change the directory to the game dir and paste the code below:

• SCS:

  • Measure-Command -Expression {
      & '.\setup-stratagems.exe' --no-exit-pause --noautoupdate --language 0 --force-install-list 1500 1510 1520 1600 1610 2000 2010 2020 2030 2040 2050 2060 2070 2080 2500 2510 2520 2900 3010 3015 3017 3020 3021 3022 3040 3041 3500 3501 3505 3510 3540 3541 3550 3551 3552 3580 4000 4020 4030 4050 4051 4052 4093 4099 4100 4115 4130 4135 4140 4145 4146 4150 4160 4161 4162 4163 4164 4170 4171 4172 4173 4174 4190 4210 4215 4216 4217 4218 4230 4240 4250 5000 5070 5080 5900 6000 6010 6020 6030 6040 6100 6200 6300 6310 6320 6500 6510 6520 6540 6550 6560 6570 6580 6590 6700 6800 6810 6820 6830 6840 6850 7000 7010 7020 7030 7040 7050 7060 7070 7080 7090 7100 7110 7130 7140 7150 7200 7210 7220 7230 7250 7900 8000 8010 8020 8040 8050 8060 8070 8080 8085 8090 8100 8110 8120 8130 8140 8150 8160 8170 8180 8190
    }

• ToF:

  • Measure-Command -Expression {
        & ".\setup-dw_talents.exe" --no-exit-pause --noautoupdate --language 0 --force-install-list 1500 1510 1520 1600 1610 2000 2010 2020 2030 2040 2050 2060 2070 2080 2500 2510 2520 20000 40000 40100 40200 40300 40310 40400 40450 40460 40470 40500 40600 40610 40650 40660 40700 40750 40751 40752 40753 40800 40850 40900 40925 40950 41000 50000 50100 50200 50300 50400 50500 55000 55100 55200 55300 55400 55500 55600 55700 55800 55900 60100 60200 60300 80000 80001 80100 80101 80102 80103 80104 80150 80500 81000 81010 81011 81012 81020 81030 81100 90000 90100
    }

I'm more than happy to run your tests and If the situation is that bad then I will make some noise about it.

On 3/2/2024 at 7:32 PM, Incrementis said:

Thank you for your short explanation. It makes things much clearer and understandable.

So far it's convinced me to just use LABEL, but there's still something I don't fully understand.

As far as I know, LABEL is the preferred method, because You wrote:

“LABEL is a better DESIGNATED…”

This leads me to believe that DESIGNATED is not necessary for completely new mods.

Could you therefore please go into more detail about the quoted point 3.(Maybe with a short and easy to understand example)?

Yes, DESIGNATED is not necessary for completely new mods if you are providing LABEL's all components. Having to not provide DESIGNATED sends a clear message to the modders: "When you want to check if one of my mods/components is installed, use LABELS.". It's safer that way.

On 3/3/2024 at 1:14 PM, suy said:

I would go even further. I wish the labels could replace the component numbers entirely (e.g. by writing in the weidu.log file #{label-name} instead of #XYZ, or some other extension to the file format that would not break too much), but in the current situation, I'm just not interested in adding labels. If I could install components by name instead of number (by calling weidu --force install label-name instead of a number), that's something that I can easily test, and which is easy to me. As is right now, I can't test labels, and serve no use to me, so I'm sticking to DESIGNATED without labels for now.

This is what PI Install Sequence already does. Some missing pieces are still left for me to add, but it's a good start. I do not hope this will end up in weidu (tip: you need to cover one more feature of DESIGNATED to be a successful replacement) but I would be happy to be proven wrong.

As for testing labels: sure you can, use --list-components-json, parse it, and make a general shell script that can launch weidu installation like this "Install-WeiDUMod -Label Ascension-RewrittenFinalChapterOfToB" etc. Also adding labels for your mods are mostly for other modders to be able to use them in the first place but ofc it can be used to cover local component dependences.

1. Yes. It serves both WeiDU and PI.

2. DESIGNATED should be added regardless of LABEL. My suggestion is to use 1000 for the first component, 2000 for the second etc so in case when you would like to add a new component between two already existing ones, you will have room for it aka 1100, 1200 etc

3. DESIGNATED is needed to keep WeiDU backup/reinstall/uninstall system happy. 

@subtledoctor Nope, PI doesn't have a BWS-like separate internal component dependency list for each mod.

Check if suddenly your Documents folder didin't end up encrypted (aka Private) or at the OneDrive.

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.

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?

@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.

@lzw104522773 You're right, sorry about that. Now, after future investigation, it seems that the main source of problems is EE_Gui. I don't think that ToF is compatible with it at this stage of development. For further installation using EET, I've installed EET+Ascension+ToF and I've got only two warnings:

So for now I would recommend uninstalling EET_Gui if you have plans to use ToF with EET.

For debugging ui.menu issues you need to post translated tra files.

@WanderingScholar The Worldmap mod has ongoing updates and I have plan to get rid of ACTION_READLN there soon.

Yes