Jump to content

AL|EN

Modders
  • Posts

    1,319
  • Joined

  • Last visited

About AL|EN

Profile Information

  • Gender
    Male
  • Location
    Poland
  • Mods Worked On
    Project Infinity
    Infinity Auto Packager Tool
    Mod Release Tool

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

AL|EN's Achievements

  1. Even if the WeiDU has build-in backup, I see no difference between: Install weidu mod by launching "Setup-Mod1 --yes" (state of the game files: 1) Install weidu mod by launching "Setup-Mod2 --yes" (state of the game files: 2) Uninstall the Weidu mod by launching "Setup-MyMod2 --uninstall" (state of the game files: 1) and 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) install a mod using any tool/mod framework (state of the game files: 2) 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.
  2. @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. 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.
  4. So you don't even start the game, you just refresh resources inside NI and check/verify the desired outcome, correct?
  5. Correct me if I'm wrong, you specifically have 'an installation routine as of: create tp2, install it via setup-mymod launch the game, verify results and quit make edits to tp2, reinstall mod via setup-mymod launch the game, verify results and quit repeat right? Can I assume that this is the 'spoiled' part? 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?
  6. 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.
  7. 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. 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?
  8. 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.
  9. 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.
  10. 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: Clean BG2EE, clean extraction of SCS/ToF, don't forget to uninstall SCS if you are testing ToF! 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.
  11. 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.
  12. 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.
  13. 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.
  14. @subtledoctor Nope, PI doesn't have a BWS-like separate internal component dependency list for each mod.
  15. Check if suddenly your Documents folder didin't end up encrypted (aka Private) or at the OneDrive.
×
×
  • Create New...