Jump to content

Search the Community

Showing results for tags 'weidu'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • G3 News and Announcements
    • Infinity Engine Modding News
    • General Mod Discussion
    • Fan Fiction
    • Noobermeet
  • Modding Discussion
    • IESDP Updates and Info
    • Modding How-Tos and Tutorials
    • Modding Q&A
  • Mods and Tools
    • Tools
    • NPC Mods
    • Tweaks and Fixes
    • Item, Kit, and Spell Mods
    • Quest Mods and Other Mods
    • Miscellaneous Released Mods
    • Unreleased Projects

Categories

  • NPCs
  • Quests and Others
  • Tweaks & Fixes
  • Items/Kits/Spells
  • Portrait Packs
  • Mini Mods
  • Tools
  • In Progress

Categories

  • Fixes
  • Items
  • Kits
  • NPCs
  • Quests
  • Spells
  • Tweaks
  • Other
  • Tools

Product Groups

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Discord


Website URL


Skype


AIM


MSN


ICQ


Yahoo


Jabber


Location


Interests


Mods Worked On

Found 12 results

  1. I'd like to share a VScode extension with support for WeiDU syntaxes. That includes highlighting, basic completion, hovers, etc. It's new and still rough, but usable. Some details (and instructions if you want to help with development) are here.
  2. Do special characters (e.g. ".") need to be quoted when they're inside square brackets? Unless I'm missing something, it should not be necessary to quote them (i.e., they're always treated literally except for "[" and "]")... But if that's really the case, then I cannot understand why the following string {none,1,\(1\|3\),\(1\|3\|5\),\(1\|3\|5\|7\)} DOES NOT match ^{[^.,;{}%TAB%]+,[^.,;{}%TAB%]+\(,[^.,;{}%TAB%]+\)*}$
  3. Pretty much what the title states. Suppose you have a folder containing 3 subfolders and 4 files. The first subfolder contains 5 files, the second one 14 and the third one just 1. How can I collect all those files/file paths (4 + 5 + 14 + 1 = 24) in a single array?
  4. When I was writing a guide about "How to properly handle mod components dependencies" and "Best practices for LABEL's" one important thing got my attention: Do labels from all of my mods are 'reserved' just as filename prefixes? So already defined labels can't be used for other mods, even if they are inside different tp2? So they can be utilized as globally unique ID of the component? Q: What is LABEL and why I should add LABEL's to my mods? A: LABEL is a better DESIGNATED. It allows assigning a unique textual identifier for a given mod component. And use this identifier to handle internal dependencies between the components of the same mod and external dependencies of the mods from different authors. By using globally unique LABEL's locally, you are saving yourself the trouble of fixing dependences after DESIGNATED changes. By using external mods LABEL's for defining dependencies, you avoid 'locking' DESIGNATED numbers changes of those mods so the author can freely change them when he needs to. You can read about how to create LABEL here: What is LABEL, why you should create it and how to do it properly You can read about how to use it here: How to properly handle mod component dependencies Before I can move forward with the guides and with the next PI features, I would like to know the modders opinion about this matter. So let me demonstrate examples of already existing LABEL which are globally unique across all existing and future mods: Ascension-RewrittenFinalChapterOfToB Ascension-BalthazarCanBeRedeemed #L-TRANSITIONS-MAIN #L-TRANSITIONS-BG1_DREAM isra_npc_for_bg isra_valerie_crossmod_content Some thoughts: Ensuring that the labels LABEL's are globally unique across ALL existing mods can be achieved without searching across all tp2's. The longer the LABEL is, the higher chance to be globally unique. Best practices can influence and make sure that all LABEL's created by any modder will be globally unique across all existing mods. I have a list of best practices but let's leave it for another topic. LABEL's which were unknowingly created by modders are indeed globally unique across all existing mods. This was achieved without any form of community contract or a best practice guide. If the LABEL's of certain mod contains the unique tp2 name, the label is globally unique. It is hard to imagine a mod that would have "Ascension-*" as a part of its LABEL and not be a component of the Ascension mod. That doesn't mean that a mod can't have for eg: a#-MyMod-Double-Ascension-Creature-Level as LABEL. LABEL's which contain modder prefixes are automatically reserved only for modders who reserved a given prefix. I think that we can agree that modders prefixes could be used as the first part of the LABEL thus making all labels globally unique. It appears to me that, similar to modder prefixes, LABEL's should be utilized as globally unique and not as a combination of tp2 name and label itself. And they became globall ID of the component. This is it! It's the most important missing functionality in the mod ecosystem. To underline the enormous importance of this, let me mention that if the concept of globally unique ID had been present since the beginning of WeiDU component system, the BWS project would still be bustling with life and would not require 24/7, never-ending Sisyphus work. All the work could be spared to improve mods. All problems related to changing DESIGNATED numbers are solved by adding a LABEL to the components. Additionally, LABEL's utilized as globally unique (and not only within tp2 files) allow for additional features outside of what WeiDU can do. Right now, it doesn't matter that WeiDU currently cannot use it without providing tp2 name. It can be improved later at least to some degree. Mod managers can use full advantages of LABEL's being utilized as globally unique. Those are extra advantages that mod ecosystem will get when LABEL's will be utilized as globally unique instead of being bound to tp2 name: so-called mod compilations will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods installation order guides will not become obsolete after changing DESIGNATED numbers or even donating components to other mods mod conflicts list will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods players can safely keep the list of selected components and use it without this kind of nightmare Everyone, please share your thoughts and opinions. @CamDawg @argent77 @subtledoctor @DavidW @jastey @Gwendolyne @Bartimaeus @Angel @kjeron @Luke @Magus @Lauriel
  5. I would like to get your feedback, thoughts, and experience regarding the installation routine of WeiDU mods. Assume that we have a mod called "MurphyLaw" , version "1.1.1" with the description of "Anything that can possibly go wrong, does." Most players have this mod installed with version "1.1.1". After a long time, there was an update to "v2.0.0". Players want to update the mod. For every possible case that might exist, what would be the safest and least error-prone workflow in order to have a successful mod update? Case A - Single mod or the mod that was installed as the last one A1 - What players do: Extract new 'MurphyLaw v2.0.0' version into the game directory, overwriting old 'MurphyLaw' files Re-install the same components by launching Setup-MurphyLaw and selecting "Re-install" for every component (WeiDU will then reinstall updated MurphyLaw) A2 - Proposed workflow: Keep the names of the currently installed components Uninstall the old version of the 'MurphyLaw' by launching Setup-MurphyLaw --uninstall Remove old 'MurphyLaw v1.1.1' directory from the game directory Extract 'MurphyLaw v2.0.0' version into the game directory Install the same components again by their names Case B - Updating and reinstalling mod that was installed between other mods: B1 - What players do: Extract new mod version into game directory overwriting old 'MurphyLaw' files Re-install the same components by launching Setup-MurphyLaw and selecting "Re-install" for every component (WeiDU will then reinstall updated MurphyLaw and all mods installed after) B2 - Proposed workflow: Keep the names of the currently installed components for the 'MurphyLaw v1.1.1' and for all other mods installed after Uninstall all mods after the updated mod by launching Setup-MyMod --uninstall in reverse order from WeiDU.log Uninstall the 'MurphyLaw v1.1.1' by launching Setup-MurphyLaw --uninstall Remove 'MurphyLaw v1.1.1' mod directory from the game directory Extract 'MurphyLaw v2.0.0' into the game directory Install 'MurphyLaw v2.0.0' using the same components Install all remaining mods that were installed after updated mod Explanation: Why uninstallation and removal is required instead of simply overwriting the mod files? The first reason would the way how WeiDU handles reinstalling mod components. WeiDU keeps 'uninstall information' inside sub-folder name of component index number or mod DESIGNATED number if exist. "MurphyLaw v1.1.1" comes with 3 components: "Weapons", "Armors", "Shields". WeiDU.log contains the following: ~MURPHYLAW/MURPHYLAW.TP2~ #0 #0 // Weapons: v1.1.1 ~MURPHYLAW/MURPHYLAW.TP2~ #0 #1 // Armors: v1.1.1 ~MURPHYLAW/MURPHYLAW.TP2~ #0 #2 // Shields: v1.1.1 "MurphyLaw v2.0.0" comes with 6 components components: "Armors: Mail", "Armors: Plate", "Shields: Large", "Shields: Medium", "Weapons: Sling", "Weapons: Spear". The indexes of those components are 0,1,2,3,4,5. So If you do 'Extract> Overwrite and Reinstall' you would actually install completely different components of "MurphyLaw v2.0.0": "Armors: Leather", "Armors: Plate", "Shields: Large" The next thing would be the code loops. Mods often contain code that has some sort of loops: for (every file inside MurphyLaw/ITM directory) COPY file TO override directory. If the author of "MurphyLaw v2.0.0" removes some files from the MurphyLaw/ITM directory and the user simply extract the new version into game folder, the old files won't be removed. Mod re-installation via weidu will still copy old files that should no longer exist. This also can lead to problems and false bug reports. Questions: Assuming that even if I A2 and B2 workflows are complicated and manually preforming those steps require multiple actions and is time consuming: Do you think that those are correct or there are some missing steps that I should include? Do you think such A2 and B2 workflows should be the default and forced when the players re-install mods to achieve safest and least error-prone mod updates? @Wisp Could you provide insights?
  6. I've finally take some time to talk about this topic. When I take look at the amount of the BWS 'custom extraction rules' and 'custom code' which was written only because modder made simple packaging mistake and then went MIA, i decided that there won't be any kind of 'extraction' feature for PI unless there will be a well-defined standard for all IE mods. Having a well-defined, universal and cross-platform Infinity Engine Mod Package and the cross-platform tool for creation of such package would be wonderful. Definitely there are advantages for players and for mod managers. This general idea was originally posted by wisp at PPG boards. Key points: - the era of caring about package size on disk or download times are long gone - there is no point for offering two separate zip packages for macOS and Linux if the only differences are weidu and few OS-specific tools resulting ~1MB of file difference - macOS/Linux users offter are asked to download weidu, extract it, copy & rename and set executable bit. Example: http://www.shsforums.net/files/file/949-atweaks-platform-independent/ - just look at the 'Installation instructions' - it's horrible idea to require preforming all of those actions by macOS/Linux users. Those things must go away, thus the simple requirements for new package: it needs to have everything which is needed for mod installation. Advantages: standardization, no more rar, tar etc, all community created tools can support it without worrying about edge-cases players will no longer need to install 3-rd party tools in order to extract mod, mod manager will do it such mod packages can be double-clicked inside OS and associated program will be open and offer extraction (and possible installation) it will allow to introduce 'infinity mod package protocol link' similar like Steam steam:// or Nexus Mod Manager nmm:// protocol links The Infinity Engine Mod Package:// protocol link: Those are special links on the web page, they look like this: steam://run:<AppId> - if the user click at this link, his local Steam application will be executed and the game will launch or the user will be asked if the game should be downloaded. nmm://ModID - if the user click at this link, his local NMM application will be executed and the mod will be automatically downloaded and added to mod list. If you never have used them, please try via Steam or NMM/Vortex - it is a pleasure to see how everything works with one click. I want this to happen. So Infinity Engine Mod Package:// protocol could be defined like this: iemod://github.com/Gibberlings3/Tweaks-Anthology player click at such link associated application will open mod will be downloaded and extracted (no overwrite) additional option would be to offer installation after extraction but i'm not sure about this and how it will play Support for such 'protocol' can't be established if there is no package definition because associated app must know ahead what's at the other side. If someone will point to the non-standard package either download/extraction will fail or extraction into game directory won't be correct so the installation cannot be started properly. 1. File format: ZIP Quoting wisp: I agree that zip is very good choice, every OS has build-in support for it. 2. File extension: .iemod - Infinity Engine Mod Package Different extension allows for custom file association for double-click action and extra actions for eg: Right-Click Menu: Install to> Game Folder. Besides, it's not only zip file, it's a zip contains IE mod with specific content/rules. Zipping mod files won't prevent package mistakes, modders need to use special mod packager utility. The .iemod file extension is not the good choice, it's "Infinity Engine Mod Package", not "Infinity Engine Mod" source file. So how about .iemp as file extension? If the 4-letter extension looks odd, how about .iep (but it's already used by other programs) or .iex (no application use such extension) ? 3. Filename: Simple format: ModName-version.iemp, nothing fancy about it, mod name can be taken from metadata Name. Question: should spaces be allowed? Filename doesn't mater at all under the condition that it doesn't contains forbidden special characters/folders: Absolute minimum set of forbidden special characters: < > : " / \ | ? * '\0' (NUL) Absolute minimum of forbidden special filenames: CLOCK$, CONIN$, CONOUT$, CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 cross-platform package simply cannot contain such special characters and cannot use such special filenames because those are reserved. 4. The content of the package: Across all those years, people put crazy things inside their mod packages: executable's inside zip, double compressed files like zip inside rar, override & backup folders, Windows 'thumbs.db' cache files and macOS '.DS_Store' folders etc. So let's exclude some files and folders: $RECYCLE.BIN/ __macosx backup/ temp/ tmp/ .* !/.gitattributes !/.gitconfig !/.github !/.gitignore *.bak *.bat *.iemod *.lnk *.rar *.tar* *.tmp *.zip Thumbs.db all of those files/folders can be easy excluded at the creation time and should not be part of the final package. 5. WeiDU executable: I would much prefer a solution where modder explicitly defines the weidu version which he used in order to create and install the mod. But until we get to this point, there is a simple solution: - weidu windows: .exe - weidu macOS: no extension - weidu Linux: .bin (please don't tell me that 'Linux don't have executable file extension', it doesn't matter) this way modder can include all necessary files in order for mod to be installed. I will post universal '.command' file later. 6. Mod structure: We need to eliminate possibility of double and tipple extra top-level directories, for mods: player should be able to extract such package into game directory and everything should work correctly. The way how to do it is to check the level of the tp2/tp3 mod definition file and fail if it's more that one-level. 7. Tools: I've created packaging utility which is very similar to 'G3 ModPackage' tool but it's cross-platform and can produce .iemod packages and optionally pure .zip files, it's using ModID-version.iemod filename schema. It doesn't have validation yet but it's easy to implement. I will post it latter when I will do final touch. That's all for now, please share you feedback.
  7. As you know, something like [^abc] processes one character at a time. So in this case everything but a, b or c. What if I need to match everything but the sequence abc? Is it possible to achieve that in WeiDU? EDIT: well, in this case this should be enough [^a-c] but what about the following pattern =>èàè+@@()[][]/>>>| ?
  8. "conflicts + dependencies" is no minor feat, that's why I keep bringing up existing package managers that have had this solved for ages. In that sense python would be a better choice than powershell, but maybe there are some written in csharp too (eg. the windows contenders like chocolatey, nuget?).
  9. Ken and I have been playing around with interjections a lot lately and I've noticed a peculiar issue that I could use some help with since neither of us can explain it. I've chosen a random situation where our NPC interjects Shoal as she asks for a kiss and simplified the example for the sake of brevity. INTERJECT SHOAL 1 InterjectShoal == MYNPCJ IF ~IsGabber("MyNPC")~ THEN @1 DO ~Something()~ = @2 DO ~SomethingElse()~ EXIT As expected, that adds a forced transition with the global and the custom trigger to the dialog. The strange part is that after @1, the dialog should immediately transition into @2, but instead, weidu adds two transitions, one of which is a dead end and exits and the other goes to @2, but has the IsGabber() trigger repeated for some reason. Again, simplified for brevity: IF ~~ THEN BEGIN N SAY #1 IF ~~ THEN DO ~Something()~ EXIT IF ~IsGabber("MyNPC")~ THEN DO ~Something()~ GOTO N+1 END IF ~~ THEN BEGIN N+1 SAY #2 IF ~~ THEN DO ~SomethingElse()~ EXIT END What are we missing here? Are the initial triggers supposed to be repeated for every step of the chain? Why would that be? And why create an exit transition after the first one in a chain? On a side note, is there a way to add the same interjection to multiple states without copy pasting it?
  10. Avenger

    DLTCEP

    Version v7.8.0.2

    13,126 downloads

    The DragonLance Total Conversion Editor Pro (DLTCEP) is an unofficial game file editor/checker/browser for Infinity Engine games. Support forum
  11. Version v1

    698 downloads

    Note: This package has not been updated in several years. For more recent highlighters, we recommend checking out Argent77's excellent WeiDU highlighters for Notepad++ at Spellhold Studios. This is a copy of NotePad++'s userDefineLang.xml file, usually found either in the install directory or within the following directory: users/myname/appdata/roaming/notepad++ The language has the following user defined languages filled out with almost all IESDP data currently available, with the following mapping: name="WeiDU_BAF" ext="baf" name="WeiDU_tp2" ext="tp2" name="WeiDU_d" ext="d" If you have already defined your own languages within NotePad++, copy the entries from this version. If you have not, then overwrite your version with this one, and restart NotePad++. Have fun modding! -cmorgan
  12. While working on a recent mod attempt I’ve come to some impasses due to my rather poor skills at using weidu; in fact, that would be a rather kind appraisal, as I find myself near illiterate when it comes to weidu, doing most of my work by repurposing others’ code for what I need to accomplish, otherwise the actual coding process is rather opaque to me. Let me get to what I’m stuck upon: firstly, I’m trying to create a code that will patch all quarterstaves to remove the backstab feature by toggling the “EE/Ex: Toggle critical hits (25)” feature in the itm files. So far based on previous reference, I’ve managed to bang out this code: COPY_EXISTING_REGEXP "^.+\.itm" override PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN READ_SHORT 0x31 weaprof PATCH_IF (weaprof = 102) BEGIN WRITE_[bor or Byte?] 0x1b (THIS [bor or Byte?] 0b[?]) END END BUT_ONLY_IF_IT_CHANGES But in reading the Bor/Byte tutorial I’ve found myself over my head. I can’t seem to figure out whether the [bracketed] parts should be a Bor or Byte (I think it’s Bor), and I know I need a binary to accomplish the task, but I can’t seem to grasp how I translate what I want into the proper 1s and 0s. Could anyone help me with the missing pieces? The second problem is a bit more vague. What I need to accomplish is to create a weidu code that patches the WEAPPROF file so that all 3’s within the “2Weapon” row are turned into 2’s. This is what, with some help, I’ve put together: COPY_EXISTING ~WEAPPROF.2DA~ override COUNT_2DA_COLS cols FOR (col = 3; col < cols; ++col) BEGIN READ_2DA_ENTRY 34 cols col val PATCH_IF %val% = 3 BEGIN SET_2DA_ENTRY 34 cols col 2 END END For obvious reasons (though not to me) this code does not work, and, being a poor hand at weidu, I imagine I’ve made a bunch of syntactical errors in this code that prevent it from working. Could correct the code or tell me what I did wrong? I’m immensely thankful for any help I can receive, in advance, and I hope you can be patience with me, given I lack a great deal of the Programmer’s savvy.
×
×
  • Create New...