Let's say I'd like to match 75% of player1 XP for party members XP adjustment. With the above posted Bubb_LUA example code it would be a matter of adding:
Player1XP = Player1XP * 0.75
Doing the same with opcodes would be another riddle.
Would it be possible to have a characters total critical hit chance be displayed on the character record?
For example: If a character placed two stars in two-handed weapon proficiency and wielded the Sword of Ruin (SoD) there critical hit chance should be +2 or 18-20? Currently only the +1 from two-handed weapon proficiency is displayed
Lefreut suggests the bonus from the Sword of Ruin is not exposed to the UI so it can't be displayed right now.
I've created an Issue 35645 but it's a low priority.
@Greener: Sounds doable; it is added to the queue. -----------------
Here's another piece of magic I finished: I externalized the "enabled" status of the divine spell book to a LUA function. This means that any class can now have their divine spell book switched on by modders. Right now non-default classes / kits aren't granted any divine spells upon level up, or given any memorization slots. These can however by manually added by scripts and the like, so I don't think I need to delve into the riddle of enabling these other features.
Here's the bit of LUA code responsible for enabling the divine spell book:
And here's Imoen, (a Mage / Thief), able to cast bless:
Now you've got my attention. I'm not sure if this is true. Admittedly I haven't looked at scripts (I don't even know if there is a script action affecting spell slots) but in my experience giving "bonus" spell slots to someone only works if their number of spell slots is already nonzero.
Hmm, you are correct. I thought opcodes 42 / 62 would work to give the memorization slots, but you are correct that they don't grant any slots if the character has zero to begin with. I guess I'll have to make my own opcode / scripting action that doesn't care about having zero slots.
Now you've got my attention. And of course, to cast a divine spell you need the "cast spell" UI function, so this only helps wizards and wizard multiclasses.
I guess I'll have a look at action bar customization, then.
I guess I'll have a look at action bar customization, then.
Please do. Action bar customization (especially thief skills and spell book accessibility) would enable a LOT of new class designs. A fighter that could pick locks, or a cleric that has a Song instead of Turn Undead, etc...
Hmm, you are correct. I thought opcodes 42 / 62 would work to give the memorization slots, but you are correct that they don't grant any slots if the character has zero to begin with. I guess I'll have to make my own opcode / scripting action that doesn't care about having zero slots.
It also does not grant an actual caster level - all such spell are still cast at level 1. Similarly, opcode 191 (casting level bonus) also does not apply if they do not already possess a caster level of the appropriate type (priest/wizard).
Similarly, opcode 191 (casting level bonus) also does not apply if they do not already possess a caster level of the appropriate type (priest/wizard).
The fact that this opcode exists in the first place with distinction for Wizard and Cleric levels is very promising, maybe Bubb will be able to change its functionality as he is planning to do with opcodes 42 / 62.
Except, hmm. I don't mean to sound like a downer - really! - but I'm not sure what that adds. I mean, we can easily give Imoen the mage/thief a wizard spell that clones Bless or uses 146 to cast the real Bless. I guess this wouldn't use up her arcane spell slots, but then we could always give her Bless as an innate rather than an arcane spell.
Since it was me who requested this feature, let me explain what I need it for. If both mentioned problems would be resolved (access to cleric spell scroll and casting spells on a level of our choice), it should be possible to bypass the hardcoded level progression and multi-classing entirely (whole level up functionality could be moved into UI.MENU and in-game scripts, using Bub_LUA to communicate between them. Vanilla Level-up menu button leading to our custom window for the characters that follow this system).
I'm planning to implement a mix of Advanced Dungeons & Dragons 2nd Edition progression rules (AC, THAC0, XP, spell selection) and D&D 3rd Edition rules introduced in IWD2 (loosened item, race and multi-classing restrictions, progressing ability scores starting at fixed number, skills available for all classes, new skills, feat system replacing proficiency slots) for the mod I'm working on. To be more precise:
– May use all kinds of weapons, armor and shields. – Race and multi/dual-class restriction rules don't apply to to this class. On each level, character may start progressing in another class, if prerequisites ability scores for choosing the class are met. The character gets all features of all classes chosen but must also suffer the consequences of all special restrictions of those classes. – Starts with 16 points to allocate across the six ability scores. Extra ability points can be assigned every four character levels, regardless of individual class level. – At each level receives skill points used for buying skills. A 1st-level character gets four times this number. Buying a skill that belongs to class that the character specializes in, grants 1 rank for each skill point. Buying other classes' skills (cross-class skills), half rank per skill point is acquired. The maximum rank in a class skill is the character's level plus 3. The maximum rank in a cross-class skill is half of this number. – Starts with proficiency feats in a number of weapons dependent on the class specialization and can choose one additional feat. At 3rd level and every three levels thereafter another feat is granted. Some feats have prerequisites, requiring the listed ability score, feat, skill, base attack bonus, or any number of other requirements in order to select or use that feat. There are also Special Feats available only for characters following specified class paths. – Depending on the class levels and race, character might or might not suffer an XP penalty. If any of the classes are two or more levels apart, the strain of developing and maintaining different skills at different levels takes its toll - for each class that is not within one level of the most experienced class, character needs to gain 20% more XP in order to advance into the next level. – No access to high-level abilities. – Hit Die: variable, depends on class specialization.
All of this while still maintaining full compatibility with tweak and kit mods - IWD2 progression system is meant to be implemented as a fake class (let's call it "All-rounder" or whatever). The class would be added to vanilla UI.MENU class selection table and assign F/M/T if chosen - used only to enable all important GUI buttons and loosen item restrictions, character is NOT forced to level up all classes at the same time or follow F/M/T progression. The character starts with a single class specialization of your choice instead (all IWD2 classes available, with a bit different advantages to normal BG2 classes since we're using Feat system) and the mod controls how the progression goes.
Player would be able to select normal class and classic AD&D kits instead or enjoy the new, optional system in the same game.
I plan to learn myself some BG modding soon. I already know Lua.
Do you know if with what you found out it is possible to get spell buffs duration? I wanted to make UI mod which shows buffs expiration but visually instead of chat like in jimfix. What are your thoughts on this?
@Myrag: I think it's a great idea! Off the top of my head, the vanilla game doesn't expose buff times to the LUA environment, but I'm sure that can be externalized with what I am doing. I'll look into it
I plan to learn myself some BG modding soon. I already know Lua.
Do you know if with what you found out it is possible to get spell buffs duration? I wanted to make UI mod which shows buffs expiration but visually instead of chat like in jimfix. What are your thoughts on this?
@Myrag: I think it's a great idea! Off the top of my head, the vanilla game doesn't expose buff times to the LUA environment, but I'm sure that can be externalized with what I am doing. I'll look into it
So, if anyone didn't get the memo it's pretty easy to externalize what buttons appear in the action bar. Every class-specific button seems to work exactly as it should in other classes, except for Turn Undead. It is greyed out for non-default classes - I'm sure I can fix that, though.
Here's an interesting thing I found: there is this actionbar button, from what I can figure out, that is only accessible by editing the exe. Its tooltip is "Shape Change". It does not function, even when it is "lit up" by some sort of condition. Possibly a remnant from development...
If it shows up somewhere in the vanilla game, well, please call me out -
So, if anyone didn't get the memo it's pretty easy to externalize what buttons appear in the action bar. Every class-specific button seems to work exactly as it should in other classes, except for Turn Undead. It is greyed out for non-default classes - I'm sure I can fix that, though.
It's automatically greyed out if the characters Turn Undead level is 0. This is how Paladin's have it greyed out until they reach level 3. Same happens if you drop a cleric to level 0, the button becomes greyed out.
I'm nearly certain that the Shape Change button showed up in some early demo of the Shaman. I remember that sheep from something.
On another note, is there a way to control class/kit/whatever wise which buttons appear on the hot bar? Alternatively, could one ditch the hot bar all together and construct unique class/kit/character interfaces? '
Oh also, is it possible to change the Bards "Pick Pockets Disguised as Thievery" button to a pure "Thievery" button. What about defining other unique buttons (such as a Fast Movement toggle)?
So, if anyone didn't get the memo it's pretty easy to externalize what buttons appear in the action bar. Every class-specific button seems to work exactly as it should in other classes, except for Turn Undead. It is greyed out for non-default classes - I'm sure I can fix that, though.
It's automatically greyed out if the characters Turn Undead level is 0. This is how Paladin's have it greyed out until they reach level 3. Same happens if you drop a cleric to level 0, the button becomes greyed out.
Out of curiosity how would I go about using your hard work to give a bard song button to a cleric or thieving abilities to a fighter?
@Greener: It would all be externalized to a LUA function in either UI.MENU or a M_*.LUA file. Every time the engine wants to know what actionbar buttons to show it would, for example, call setActionbarType(creID, slotNum) and use its return value. The following would be the LUA code... wall of text incoming!
On another note, is there a way to control class/kit/whatever wise which buttons appear on the hot bar?
Using the LUA system I defined earlier, it would be possible to use any information source available to the LUA environment to determine the buttons shown. So, that is a yes.
Alternatively, could one ditch the hot bar all together and construct unique class/kit/character interfaces? '
I have already tested and proven that it is possible to call the functions which preform the actionbar button's actions directly. So, yes, it will be possible to not even need to use the hardcoded hotbar with my solution.
...The button's actions are hardcoded. I could externalize the conditions that determine which behavior they follow; I believe that would do as you wish?
That sounds like what would be needed. The button only performs pick pocket, but does nothing when (e.g.) hovered over a door. If it could preform the open lock when hovered over a door and disarm trap when hovered over a detected trap, that would be super
Not quite sure how to show this - but I've managed to get a very experimental patch up and running that unlocks the full LUA standard library. Well, technically I've actually replaced the engine's limited inbuilt LUA interpreter with an external dll, but it works... kind of. The game crashes in a couple of situations, but the important thing is that I know it is possible to implement, if not a little hard.
I think the most important thing is the unlocked io library. This should allow mods to store their own files, allowing for more flexible persistent data, and even saved data per savegame.
I have several kits that only have known spells - they have no spell slots and so cannot actually memorize anything. And I don't think there's any in-game way to add memorization slots and fill them with spells, so I can't fudge it with some automated tomfoolery. Now, if there was a way to fill a sequencer with spells from your known spells instead of your memorized spells...
This is already doable with normal UI modding. You would still need a way to decrement the spells per day though.
Comments
It's a COMPILE weidu command equivalent supporting multi-line Lua code.
For example: If a character placed two stars in two-handed weapon proficiency and wielded the Sword of Ruin (SoD) there critical hit chance should be +2 or 18-20? Currently only the +1 from two-handed weapon proficiency is displayed
Lefreut suggests the bonus from the Sword of Ruin is not exposed to the UI so it can't be displayed right now.
I've created an Issue 35645 but it's a low priority.
-----------------
Here's another piece of magic I finished: I externalized the "enabled" status of the divine spell book to a LUA function. This means that any class can now have their divine spell book switched on by modders. Right now non-default classes / kits aren't granted any divine spells upon level up, or given any memorization slots. These can however by manually added by scripts and the like, so I don't think I need to delve into the riddle of enabling these other features.
Here's the bit of LUA code responsible for enabling the divine spell book:
And here's Imoen, (a Mage / Thief), able to cast bless:
Similarly, opcode 191 (casting level bonus) also does not apply if they do not already possess a caster level of the appropriate type (priest/wizard).
The fact that this opcode exists in the first place with distinction for Wizard and Cleric levels is very promising, maybe Bubb will be able to change its functionality as he is planning to do with opcodes 42 / 62.
Since it was me who requested this feature, let me explain what I need it for. If both mentioned problems would be resolved (access to cleric spell scroll and casting spells on a level of our choice), it should be possible to bypass the hardcoded level progression and multi-classing entirely (whole level up functionality could be moved into UI.MENU and in-game scripts, using Bub_LUA to communicate between them. Vanilla Level-up menu button leading to our custom window for the characters that follow this system).
I'm planning to implement a mix of Advanced Dungeons & Dragons 2nd Edition progression rules (AC, THAC0, XP, spell selection) and D&D 3rd Edition rules introduced in IWD2 (loosened item, race and multi-classing restrictions, progressing ability scores starting at fixed number, skills available for all classes, new skills, feat system replacing proficiency slots) for the mod I'm working on. To be more precise:
– May use all kinds of weapons, armor and shields.
– Race and multi/dual-class restriction rules don't apply to to this class. On each level, character may start progressing in another class, if prerequisites ability scores for choosing the class are met. The character gets all features of all classes chosen but must also suffer the consequences of all special restrictions of those classes.
– Starts with 16 points to allocate across the six ability scores. Extra ability points can be assigned every four character levels, regardless of individual class level.
– At each level receives skill points used for buying skills. A 1st-level character gets four times this number. Buying a skill that belongs to class that the character specializes in, grants 1 rank for each skill point. Buying other classes' skills (cross-class skills), half rank per skill point is acquired. The maximum rank in a class skill is the character's level plus 3. The maximum rank in a cross-class skill is half of this number.
– Starts with proficiency feats in a number of weapons dependent on the class specialization and can choose one additional feat. At 3rd level and every three levels thereafter another feat is granted. Some feats have prerequisites, requiring the listed ability score, feat, skill, base attack bonus, or any number of other requirements in order to select or use that feat. There are also Special Feats available only for characters following specified class paths.
– Depending on the class levels and race, character might or might not suffer an XP penalty. If any of the classes are two or more levels apart, the strain of developing and maintaining different skills at different levels takes its toll - for each class that is not within one level of the most experienced class, character needs to gain 20% more XP in order to advance into the next level.
– No access to high-level abilities.
– Hit Die: variable, depends on class specialization.
All of this while still maintaining full compatibility with tweak and kit mods - IWD2 progression system is meant to be implemented as a fake class (let's call it "All-rounder" or whatever). The class would be added to vanilla UI.MENU class selection table and assign F/M/T if chosen - used only to enable all important GUI buttons and loosen item restrictions, character is NOT forced to level up all classes at the same time or follow F/M/T progression. The character starts with a single class specialization of your choice instead (all IWD2 classes available, with a bit different advantages to normal BG2 classes since we're using Feat system) and the mod controls how the progression goes.
Player would be able to select normal class and classic AD&D kits instead or enjoy the new, optional system in the same game.
I plan to learn myself some BG modding soon. I already know Lua.
Do you know if with what you found out it is possible to get spell buffs duration? I wanted to make UI mod which shows buffs expiration but visually instead of chat like in jimfix. What are your thoughts on this?
Hmm... that action bar looks quite weird for a Cleric / Mage!
20 years
20 years
Fantastic job man.
Here's an interesting thing I found: there is this actionbar button, from what I can figure out, that is only accessible by editing the exe. Its tooltip is "Shape Change". It does not function, even when it is "lit up" by some sort of condition. Possibly a remnant from development...
If it shows up somewhere in the vanilla game, well, please call me out -
Out of curiosity how would I go about using your hard work to give a bard song button to a cleric or thieving abilities to a fighter?
On another note, is there a way to control class/kit/whatever wise which buttons appear on the hot bar? Alternatively, could one ditch the hot bar all together and construct unique class/kit/character interfaces? '
Oh also, is it possible to change the Bards "Pick Pockets Disguised as Thievery" button to a pure "Thievery" button. What about defining other unique buttons (such as a Fast Movement toggle)?
@kjeron: Thanks for the clarification! @Greener: It would all be externalized to a LUA function in either UI.MENU or a M_*.LUA file. Every time the engine wants to know what actionbar buttons to show it would, for example, call setActionbarType(creID, slotNum) and use its return value. The following would be the LUA code... wall of text incoming!
That is, once I release my modifications, you would append the actionbarConfigurations table using an M_*.LUA file.
@Aquadrizzt: Using the LUA system I defined earlier, it would be possible to use any information source available to the LUA environment to determine the buttons shown. So, that is a yes. I have already tested and proven that it is possible to call the functions which preform the actionbar button's actions directly. So, yes, it will be possible to not even need to use the hardcoded hotbar with my solution. The button's actions are hardcoded. I could externalize the conditions that determine which behavior they follow; I believe that would do as you wish? While a workaround, you could set an actionbar button to NONE, then use a custom button element to simulate a custom actionbar button.
That sounds like what would be needed. The button only performs pick pocket, but does nothing when (e.g.) hovered over a door. If it could preform the open lock when hovered over a door and disarm trap when hovered over a detected trap, that would be super
I think the most important thing is the unlocked io library. This should allow mods to store their own files, allowing for more flexible persistent data, and even saved data per savegame.