Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Grammarsalad
« on: May 03, 2020, 10:26:28 PM »

Nice!
Posted by: Argent77
« on: March 14, 2020, 08:17:42 AM »

A new beta is available: Version 0.4

Changelog:
  • Added option to specify multiple clab paths for multiclass kits
  • Added multiclass kit installation to example mod
  • Removed class/kit restrictions from thieving-related parameters
  • Fixed incorrect autocompletion of thieving parameters containing only one entry
  • Fixed incorrect kittable entry validation
  • Various minor fixes and improvements
Posted by: Argent77
« on: February 29, 2020, 01:59:07 PM »

That's good to know!

I have fixed several issues recently (see commit list). Let me know if there are more issues to fix or if you have suggestions how to further improve the library.
Posted by: subtledoctor
« on: February 23, 2020, 11:00:28 PM »

It's been a few months, but it's worth mentioning here that I think this project is the bee's knees.  Fantastic.  The way I'm using it is fairly ambitious, I think:
 
  • We have a mod that add ~50 cleric kits to the game
  • In a settings file, each kit has a few variables set to represent allowed multiclasses.  For example, the Cleric of Helm can be a F/C or a C/M, but not a C/T or C/R.
  • A separate component asks, in essence: "would you like to install all of the allowed multiclass variants for all these cleric kits?"
  • It then reads those variables and auto-generates a kit for every valid multiclass version of the single-class clerics.  They inherit the characteristics of the single-class cleric kit, and have things like proficiencies and thief skills adjusted as appropriate.

Depending on how many cleric kits you install from our mod and other compatible mods like DR, and depending on how you set those variables, this can install upwards of 150 kits in one fell swoop.  It's been in the wild for a few months now and I haven't had a single complaint that there is anything wrong with the kits generated by ADD_KIT_EX.  They seem to be working perfectly.  I think that's a pretty good stress test - most use cases will be substantially simpler than mine.  This gets my endorsement.
Posted by: Argent77
« on: October 16, 2019, 10:16:06 AM »

This is nice:
Quote
Example of a minimalistic kit definition:
Could you also show a kit definition without any omitted variables ? Similar like this.

It just helps a bit more, in the transition.

The project contains an example mod that shows several use cases in more detail. There are components for:
Posted by: The Imp
« on: October 16, 2019, 12:07:58 AM »

This is nice:
Quote
Example of a minimalistic kit definition:
Could you also show a kit definition without any omitted variables ? Similar like this.

It just helps a bit more, in the transition.
Posted by: Argent77
« on: October 13, 2019, 12:17:34 PM »

Another beta is available: Version 0.3

Changelog:
  • Added full multiclass kit support for Enhanced Edition 2.0+ games (based on QDMULTI plus various improvements)
@subtledoctor: I have also updated my fork of QDMULTI, so that both libraries are on the same feature level.
Posted by: Argent77
« on: October 12, 2019, 01:54:50 PM »

Incidentally, if you are going to include multiclass kits in this function, there is no real need to glue QDMulti into it - you could of course also simply implement your own solution to achieve the same results - specifically, the creation of kit menu tables, and the use of .eff files or something similar to apply multiclass kit abilities via the single-class unkitted CLAB tables.
It would still make sense to use the same naming scheme for game resources to prevent compatibility issues if multiclass kits are installed by ADD_KIT_EX or the conventional way.

Further testing with multiclass kits reveals that maximum number of kits is virtually unlimited (possibly only restricted by the CRE's kit field size or by secondary tables).

@Wisp: To fully utilize the single-class kit limit without restricting multiclass kits I think it is possible to fill kitlist.2da with placeholders up to row 255 and continue with multiclass kit definitions at row 256 and up. However, that would require ADD_KIT and COPY_KIT to detect and use these placeholders correctly as well. Would it be possible or feasible to update WeiDU accordingly?
Posted by: subtledoctor
« on: October 09, 2019, 07:56:48 PM »

Incidentally, if you are going to include multiclass kits in this function, there is no real need to glue QDMulti into it - you could of course also simply implement your own solution to achieve the same results - specifically, the creation of kit menu tables, and the use of .eff files or something similar to apply multiclass kit abilities via the single-class unkitted CLAB tables.

I suggest this simply because that would really make ADD_KIT_EX a true one-stop-shop for installing kits of every stripe.  There need be no conflict; even within the some mod, some kits could be installed with ADD_KIT_EX and other with ADD_KIT + fl#add_kit_ee + QDMulti.  The two methods could coexist perfectly well.

But, another suggestion, echoing one I already made to Wisp: if you do incorporate multiclass kits into this, I would put a check somewhere relatively early in the code looking at 1) is ToBEx present; and 2) is the kit single-class or multiclass... and if the answer to 1) is no, then only allow the kit installation to proceed if the answer to 2) is "multiclass."  (As discussed elsewhere, the EE engine is limited to 255 single-class kits, but multiclass kits added via a QDMulti-like fashion can exceed that limit.)
Posted by: subtledoctor
« on: October 09, 2019, 07:42:38 PM »

@subtledoctor: Btw, I've done a bit of cleaning and optimizing already (Project). I can create a PR if you want to use it as a basis for further bugfixing.

Let me take a look.  I've got an internal version 0.7 which fixes a couple bugs and optimizes a few things (not that much though) I don't want us to be working at cross-pruposes.  I only haven't had enough time to test it. 

Check that - I've uploaded it to my branch, just haven't made a release yet, until it gets tested.  Feel free to kick the tires if you like - you may have time to compare them before I do, given my current RL circumstances.

EDIT - looks very nice.  I incorporated both of our changes to create version 0.8.  Thanks!  (Still needs testing though, to make sure my opcode 206 subspells are working.)
Posted by: Argent77
« on: October 06, 2019, 05:51:41 AM »

I've forked the project to see whether I can save you some effort by integrating them myself, so you can just review a pull request.  Don't have a ton of time these days but it's roughly working already.  I just need to:
- fix the aforementioned 206 bug
- fix another little bug so it reads all rows of the clab file
- figure out how your function populate the K_x_y.2da menu tables, to integrate the (possibly not-yet-existing) multiclass ones
- I suppose, add a fail warning if the modder neglects to specify the new single-class variable
I've taken a closer look at QDMULTI and there seems to be a lot of potential for optimizing the code. With a bit of restructuring and fixing the aforementioned bugs I may be able to add most if not all of the functionality into ADD_KIT_EX.

@subtledoctor: Btw, I've done a bit of cleaning and optimizing already (Project). I can create a PR if you want to use it as a basis for further bugfixing.
Posted by: Gwendolyne_FP
« on: September 30, 2019, 04:29:56 PM »

Great. I really like the "invisible feature" that will solve one of my mod issue. ;)
Posted by: Argent77
« on: September 30, 2019, 10:45:03 AM »

A new beta is available: Version 0.2

Changelog:
  • Fixed kit limit check
  • Improved GemRB and TobEx checks
  • Made more parameters optional
  • Missing kit-related tables are provided if needed
  • Function autogenerates class ability tables for multiclass kits if needed
Posted by: Argent77
« on: September 24, 2019, 01:16:18 PM »

I think QDMulti should continue as a separate project (at least for the time being). Incorporating all of it into ADD_KIT_EX would make development of both projects needlessly complicated.

QDMulti is still actively developed. Bugs should be fixed in a timely manner, which may not be possible if this code is included in WeiDU. It would also prevent mods still using original ADD_KIT from using the library, unless you want to maintain two code branches.

I can make sure the necessary groundwork is properly laid when ADD_KIT_EX is called (creating or normalizing required 2DA files, etc.), but I'll leave the spell logic to QDMulti.
Posted by: subtledoctor
« on: September 24, 2019, 01:01:14 PM »

I've forked the project to see whether I can save you some effort by integrating them myself, so you can just review a pull request.  Don't have a ton of time these days but it's roughly working already.  I just need to:
- fix the aforementioned 206 bug
- fix another little bug so it reads all rows of the clab file
- figure out how your function populate the K_x_y.2da menu tables, to integrate the (possibly not-yet-existing) multiclass ones
- I suppose, add a fail warning if the modder neglects to specify the new single-class variable