So I downloaded EEex and started playing around with script hooks. I'm wondering, what do all the different offsets in an action do? (e.g. I know that actionData + 0x54 and actionData + 0x58 are the target X and Y coordinates of the action, but what information is stored in the various other offsets?)
What can you tell me of this? Do you know of any workaround?
@Luke93: Well, it certainly doesn't seem like desired behavior, but the code does it quite intentionally. Any effect that is applied to the creature will force the values back to normal. So, you're on the right track with using an ApplySpell, you just need to use a dummy effect that has no actual meaning. Like a 0 duration Opcode #0 with param1 = 0; something like that.
I'm sorry, but it's not (fully) working.... In particular, General is set to 0 (GENERAL_ITEM), the other values seem OK.......
IF
Global("gt_summ","GLOBAL",0)
THEN
RESPONSE #100
SetGlobal("gt_summ","GLOBAL",1)
MakeGlobalOverride()
ChangeEnemyAlly(Myself,FAMILIAR)
AddFamiliar()
ApplySpellRES("GTDUMMY",Myself)
Continue()
END
Bubb I know you are quite busy with getting things implemented but would you be able to give an example of how to implement a key binding with the EEex_Key.lua? Like for the really dense coding lay people like me?
Extract the attached archive and drop M_Hotkey.lua into your override folder. Open it, and you should see this starting at line 13:
In order to add a new spell => key combo, copy the "SPWI523" line and paste it directly on the next line. Change the resref to whatever spell / ability you want. The second column is used internally when processing the hotkey, always keep that a 3. The following numbers are the sequence of keys required to activate the action...
The first hotkey is defining a toggle which allows you to see the hexadecimal value of whatever keys you press. After pressing "`", you should something like this in the log:
Whenever you press a key a "[EEex] Pressed: x" will be shown in the log. You can then use these values in the keybinding definitions. -------------------------------------------------------------------
So I downloaded EEex and started playing around with script hooks. I'm wondering, what do all the different offsets in an action do? (e.g. I know that actionData + 0x54 and actionData + 0x58 are the target X and Y coordinates of the action, but what information is stored in the various other offsets?)
I haven't explored everything, but here's the structure that's defined in the debug file, (CAIAction being what is behind actionData):
Bubb I know you are quite busy with getting things implemented but would you be able to give an example of how to implement a key binding with the EEex_Key.lua? Like for the really dense coding lay people like me?
Extract the attached archive and drop M_Hotkey.lua into your override folder. Open it, and you should see this starting at line 13:
In order to add a new spell => key combo, copy the "SPWI523" line and paste it directly on the next line. Change the resref to whatever spell / ability you want. The second column is used internally when processing the hotkey, always keep that a 3. The following numbers are the sequence of keys required to activate the action...
The first hotkey is defining a toggle which allows you to see the hexadecimal value of whatever keys you press. After pressing "`", you should something like this in the log:
Whenever you press a key a "[EEex] Pressed: x" will be shown in the log. You can then use these values in the keybinding definitions.
Dear Bubb it works like a dream. I can't tell you how pleased I am with the system you have devised! I wish I could give you more than a paltry "like"!
Thing is what you have started here with your lua tie-ins to the game engine is so boundless in potential. It makes me excited as if someone had unlocked the source code itself.
I really think a moderator should at least bump this thread up to General Modding or better yet News and Announcements! These modifications need more exposure for people to see that a new age is dawning for the Infinity Engine!
Welp, I'm glad the same functionality can be implemented via the vanilla engine. I was already like 75% done doing it the hard way, so I finished because why not.
Terminsel has Opcode #193 applied. Whenever he is selected, invisible creatures can be seen by their selection circle. He is the only one that can target the creature, though.
Awesome! That's exactly what I wanted. You are a true treasure to modding. EEex is going to revolutionary.
@Bubb I have been thinking about different ways of targeting non party NPCs in the game including allies like summons, but also neutrals and hostiles using the keyboard.
Would it be possible to assign and display a number on such targets when they enter the visual range and then having those numbers assignable with hotkeys? Essentially, what I'm asking, would it be possible to extend the targeting system of party members, which by default can be selected by keys 1-6, to these other groups of targets?
So maybe if a number was displayed on all targetable creatures (friend and foe) say from 1-99 and those numbers could be linked with the keybinding system you have already developed? This would make controlling single target spells and abilities a hell of a lot less fiddly in the heat of battle. Now I know you have only just completed one of my requests and I don't want to seem greedy so I understand if you are busy with other things!
@fortyseven: Interesting idea! I'll look at it after I implement some new opcodees, don't want to leave the other guys hanging
The only thing I can think of off the top of my head: typing numbers that are more than one digit is a little tricky. How do I know that the 77 you just typed wasn't two "target 7" commands? One workaround would be to have a "starting" keypress, and then an "ending" keypress. So, if you wanted to target creature 22, for instance, you would type "`" + "2" + "2" + "`"
Gameplay changes are now opt-in, instead of being on by default. This version implements the idea of a module. Modules are gameplay changes that are included with EEex, but must be enabled by the user by altering EEex_INI.lua. Here's the currently included modules:
B3_Books.lua: Force-enables the mage book screen, (only the screen), for all classes. (Pretty useless right now, but I'm working on externalizing more of the magic system...)
B3_Hotke.lua: Implements a new hotkey system, (add new hotkeys by editing the "B3Hotkey_Hotkeys" table).
B3_Invis.lua: Changes Opcode #193 to allow player-controlled creatures, which have said opcode applied, to see invisible sprites. Invisible sprites that are detected using Opcode #193 will only have their selection circle visible, though there is a setting at the top of the file which makes these creatures render as if under a detected improved invisiblity.
@fortyseven: Interesting idea! I'll look at it after I implement some new opcodees, don't want to leave the other guys hanging
The only thing I can think of off the top of my head: typing numbers that are more than one digit is a little tricky. How do I know that the 77 you just typed wasn't two "target 7" commands? One workaround would be to have a "starting" keypress, and then an "ending" keypress. So, if you wanted to target creature 22, for instance, you would type "`" + "2" + "2" + "`"
How's that sound?
Not a bad idea but maybe more complicated than needed. The numbers themselves don't have to necessarily be literally reflected in their keybind. Number 0-9 could simply be combined with a modifier or even a letter key to denote increases of tens. Like shift could be tens, control could be twenties etc. Thus number 22 would simply be "ctrl" + "2". The system you have written is so flexible and extensive there is no limit to combinations.
Gameplay changes are now opt-in, instead of being on by default. This version implements the idea of a module. Modules are gameplay changes that are included with EEex, but must be enabled by the user by altering EEex_INI.lua. Here's the currently included modules:
B3_Books.lua: Force-enables the mage book screen, (only the screen), for all classes. (Pretty useless right now, but I'm working on externalizing more of the magic system...)
B3_Hotke.lua: Implements a new hotkey system, (add new hotkeys by editing the "B3Hotkey_Hotkeys" table).
B3_Invis.lua: Changes Opcode #193 to allow player-controlled creatures, which have said opcode applied, to see invisible sprites. Invisible sprites that are detected using Opcode #193 will only have their selection circle visible, though there is a setting at the top of the file which makes these creatures render as if under a detected improved invisiblity.
Love the idea of a modular system and is indeed what I was hoping you would implement! Also greatly looking forward to your plans for greater externalisation of the magic system!
This is just awesome, thank you @Bubb B3_Invis.lua with the imp. invis setting is actually something I've wanted for a long time.
Since this is the time of miracles, I'll add a few feature suggestions as well. (Not sure if those are within the scope of this project or of general interest though.)
- Externalized Stoneskin color .. .. or even better, not just color but maybe a 2da file that allowes to point to a specific spell that's applied to the target while a spell's Stoneskin effect is active.
- Externalized Stoneskin absorb effect. I wonder if it would be possible to also change the damage types a Stoneskin effect can absorb? (E.g. to create an effect that absorbs fire damage hits.)
- Continuing that chain of thought, would it be possible at all to create an "absorb"/absolute resistance effect? (Absorb x amount of damage (not hits) or reduce each hit by x amount of damage)
- Allow the new "character outline" render function (used for the black border around characters and the highlighting for selected characters) to be used as an opcode effect with a color parameter. I don't like using the sprite outlines myself but I think they would make a great aura effect (which fits all animation shapes and sizes).
-Some kind of flag that excludes specific kits from gaining spells on level up. Preventing a kit from accessing default cleric or wizard spells would allow for so many cool kits..
A really useful opcode that I know loads of people have wanted over the years, me included is "disarm trap" usable on a clickable target. That way we could make spells and abilities that would allow for trap disarming without having to have a thief action bar on one of our party NPCs. Just putting it out there.
- Externalized Stoneskin absorb effect. I wonder if it would be possible to also change the damage types a Stoneskin effect can absorb? (E.g. to create an effect that absorbs fire damage hits.)
While I do not know any way to implement this exact effect, you could make a spell that absorbs the first damage of the damage type(s) of your choice by using the Seven Eyes opcode to give the creature a special spell state and update 7eyes.2da to have that spell state absorb the damage type(s) of your choice.
Although BGEE and BG2EE do not have a 7eyes.2da file, it will work if you create one. Take a look at 7eyes.2da in Icewind Dale Enhanced Edition if you want to figure out how to do this.
... -Some kind of flag that excludes specific kits from gaining spells on level up. Preventing a kit from accessing default cleric or wizard spells would allow for so many cool kits..
I would really like something like this.
Or, maybe better a 2da that excludes specific spells from designated classes or kits. Like a kit specific hidespl.2da that prevents the spell from bring learned from scrolls.
So, like:
2DA V1.0
0
HIDE
KIT_OR_CLASS_NAME SPELL_NAME
Where the designated kit or class is barred from learning the designated spell at level up or character creation and is barred from learning the spell from scrolls.
But even just a class/kit specific hidespl.2da would be all I would need to create custom spell lists (i.e. by changing the way school based spell learning works--i.e. by summoning based dialog or something similar)
@Bubb, I have been experimenting with your hotkey mod and it really is incredibly flexible. What is unique is how it can handle multiple key assignments. For example it will handle "A+S" completely separately to "A", "S" and "S+A". They all work in parallel without triggering the other bindings as long as you perform the inputs cleanly enough (which works quite well after a bit of practice). This allows for really interesting and ergonomic layouts. It has sped up playing larger groups with broad and complex ability sets in a way that's making it feel almost like a new game. An average battle now takes about half the time and it's more live-action with fewer and shorter uses of pause. It really is a lot more dynamic if one is willing to put in the time to adjust the keyboard layout (took me a couple of hours with trial and error for a group of 6 high level casters). I'm now wishing other games used the same key-binding system but I have never seen it anywhere else!
One thing I have been wondering, would it be possible to add mouse keys as possible inputs? If mouse keys could be used in this flexible combo style with keyboard keys I think it would become even more dynamic and would possibly do away or at least significantly reduce the amount of practice and care that was needed to opearte a complex keyboard layout. At the moment you have one hand on the mouse anyway that isn't doing much apart from moving the pointer.
And finally, would you be able to add item abilities to be assignable as well? That is the ones that are accessed through the backpack symbol. Items with direct effects can't have keys assigned at present as far as I can see (i have tried using their *.itm resef). Also in your current system can you assign general game functions like "map" or "inventory"?
I know you are really busy and there are loads of others who have asked for your attention so I understand if you are occupied with other things right now!
- Externalized Stoneskin absorb effect. I wonder if it would be possible to also change the damage types a Stoneskin effect can absorb? (E.g. to create an effect that absorbs fire damage hits.)
While I do not know any way to implement this exact effect, you could make a spell that absorbs the first damage of the damage type(s) of your choice by using the Seven Eyes opcode to give the creature a special spell state and update 7eyes.2da to have that spell state absorb the damage type(s) of your choice.
Although BGEE and BG2EE do not have a 7eyes.2da file, it will work if you create one. Take a look at 7eyes.2da in Icewind Dale Enhanced Edition if you want to figure out how to do this.
Interesting, I have no clue what 7eyes is or does, so I'll have to look into that.
- Externalized Stoneskin color .. .. or even better, not just color but maybe a 2da file that allowes to point to a specific spell that's applied to the target while a spell's Stoneskin effect is active.
Yeah - you can override the gray color with some visual effect, but the difficulty is limiting the effect to the lifespan of the Stoneskin, which is quite variable.
For consistency's sake the ideal here would be to use a subspell identified in the Stoneskin effect - the way the Spell Deflection opcode works as of the 2.5 patch. Basically, every effect whose duration is not necessarily the same as the spell's stated duration (Stoneskin, Mirror Image, Spell Deflection/Turning, Spell Shield, etc.) should have this functionality.
Aye, having it as a spell parameter would probably be the best solution.
- Externalized Stoneskin absorb effect. I wonder if it would be possible to also change the damage types a Stoneskin effect can absorb? (E.g. to create an effect that absorbs fire damage hits.)
But that would leave out spells unless you also want to add that secondary type to real spells (which will most likely already use that type for something else) also, unless you can just new add secondary types, doing it this way would also provide unwanted immunity to a number of spells using the same subtype?
... -Some kind of flag that excludes specific kits from gaining spells on level up. Preventing a kit from accessing default cleric or wizard spells would allow for so many cool kits..
I would really like something like this.
Or, maybe better a 2da that excludes specific spells from designated classes or kits. Like a kit specific hidespl.2da that prevents the spell from bring learned from scrolls.
So, like:
2DA V1.0
0
HIDE
KIT_OR_CLASS_NAME SPELL_NAME
Where the designated kit or class is barred from learning the designated spell at level up or character creation and is barred from learning the spell from scrolls.
But even just a class/kit specific hidespl.2da would be all I would need to create custom spell lists (i.e. by changing the way school based spell learning works--i.e. by summoning based dialog or something similar)
Where there is a default 2da that defines restrictions (maybe that could actually be hidespl.2da) but where different kits or classes could reference alternate hidespl-like 2das (that modders would have to create)
Additionally, would it be possible to externalize the sprites assigned to CHARNAME at character creation? Currently they are hardcoded so if one were to, say, make a mod that changes player character sprites... at the end of character creation, CHARNAME would be unaffected, and players would have to use EEKeeper to get their new sprite.
Additionally, would it be possible to externalize the sprites assigned to CHARNAME at character creation? Currently they are hardcoded so if one were to, say, make a mod that changes player character sprites... at the end of character creation, CHARNAME would be unaffected, and players would have to use EEKeeper to get their new sprite.
Unless I'm missunderstanding what you're trying to do, you can already do this right now with scripts.
Additionally, would it be possible to externalize the sprites assigned to CHARNAME at character creation? Currently they are hardcoded so if one were to, say, make a mod that changes player character sprites... at the end of character creation, CHARNAME would be unaffected, and players would have to use EEKeeper to get their new sprite.
Unless I'm missunderstanding what you're trying to do, you can already do this right now with scripts.
In earlier versions you definitely can. It's done here, for example:
Edit: iirc, it's a pita. There are some redundancies you have to get around...
Edit 2: I believe you have to apply race based 177 effects in the clab and use scripting. I forget the details, but there are issues when using just one technique
Heh, I lose power for one day and I come back to this! I'll get to work on all of the suggestions
It might be a while before I get any particular person's done, as I now have around ~20 suggestions piled up - just know that I am indeed working on them! I'm only responding to the suggestions in which I have immediate questions on how to implement, all the rest are in the queue:
1) One thing I have been wondering, would it be possible to add mouse keys as possible inputs...
2) And finally, would you be able to add item abilities to be assignable as well...
1. Like allowing mouse clicks to be part of a keybinding? I'm not quite sure how that would work, as the mouse buttons are intrinsically hard coded to do other things.
2. Well, at first glance I thought this would be a 2 line fix, but sadly it isn't. Item abilities don't actually use resrefs; they are embedded inside the .ITM itself. I can target the item's resref, but if the item has more than one ability it will just pick the first one. I think the only way to target a specific item ability is to match text...
For consistency's sake the ideal here would be to use a subspell identified in the Stoneskin effect - the way the Spell Deflection opcode works as of the 2.5 patch. Basically, every effect whose duration is not necessarily the same as the spell's stated duration (Stoneskin, Mirror Image, Spell Deflection/Turning, Spell Shield, etc.) should have this functionality.
I've pushed a commit to master that implements this for Opcode #218, and I'll try to implement it for all the other variable-duration opcodes. If someone could post a list of all of these opcode numbers it would be appreciated, so I can make sure I got all of them.
Think about it: Stoneskins absorb physical attacks, right? But what happens when you have Stoneskin and get hit by the Flail of Ages? The blunt damage is blocked and a skin disappears. And... fire damage bypasses the Stoneskin and harms you, but a skin still disappears. Lightning damage bypasses the spell, but still expends a skin. (Please correct me if I'm remembering this wrong.)
I have never seen this happen, unless the countless magic missiles I've cast at stoneskin-buffed mages has somehow been lying to me.
Heh, I lose power for one day and I come back to this! I'll get to work on all of the suggestions
It might be a while before I get any particular person's done, as I now have around ~20 suggestions piled up - just know that I am indeed working on them! I'm only responding to the suggestions in which I have immediate questions on how to implement, all the rest are in the queue:
You really are admirable in how generously your are giving time and skill to this project of yours for the benefit of so many of us! I can't thank you enough!
1. Like allowing mouse clicks to be part of a keybinding? I'm not quite sure how that would work, as the mouse buttons are intrinsically hard coded to do other things.
2. Well, at first glance I thought this would be a 2 line fix, but sadly it isn't. Item abilities don't actually use resrefs; they are embedded inside the .ITM itself. I can target the item's resref, but if the item has more than one ability it will just pick the first one. I think the only way to target a specific item ability is to match text...
Sounds like mouse buttons are off-limits if they are hardcoded.
Regarding item abilities, using text might also not work all that well if there is more than one ability on the item. Those abilities have no text element linked to them as far as I can see. In nearinfinity they are numbered but I believe that is entirely internal to that programme. So I'm not sure what you could target? Would the icon.bam be an idea? That is often specific to a single ability and in cases when it isn't it could easily be made to be by copying and renaming the bam file to a unique name.
Also is it possible to target other interface functions at present like opening the "map" or "inventory" with your hotkey.lua?
Comments
IF Global("gt_summ","GLOBAL",0) THEN RESPONSE #100 SetGlobal("gt_summ","GLOBAL",1) MakeGlobalOverride() ChangeEnemyAlly(Myself,FAMILIAR) AddFamiliar() ApplySpellRES("GTDUMMY",Myself) Continue() ENDB3Hotkeys = {In order to add a new spell => key combo, copy the "SPWI523" line and paste it directly on the next line. Change the resref to whatever spell / ability you want. The second column is used internally when processing the hotkey, always keep that a 3. The following numbers are the sequence of keys required to activate the action...{B3TogglePrintKeys, 3, 0x60}, -- Key-Pressed Output Toggle
{"SPWI523", 3, 0x61, 0x73, 0x64},
}
The first hotkey is defining a toggle which allows you to see the hexadecimal value of whatever keys you press. After pressing "`", you should something like this in the log:
Whenever you press a key a "[EEex] Pressed: x" will be shown in the log. You can then use these values in the keybinding definitions.
-------------------------------------------------------------------
I haven't explored everything, but here's the structure that's defined in the debug file, (CAIAction being what is behind actionData): -------------------------------------------------------------------
Hmm, the same thing works flawlessly on my end. Are you sure the creature in question doesn't have a general of 0 to begin with?
Dear Bubb it works like a dream. I can't tell you how pleased I am with the system you have devised! I wish I could give you more than a paltry "like"!
Thing is what you have started here with your lua tie-ins to the game engine is so boundless in potential. It makes me excited as if someone had unlocked the source code itself.
I really think a moderator should at least bump this thread up to General Modding or better yet News and Announcements!
Would it be possible to assign and display a number on such targets when they enter the visual range and then having those numbers assignable with hotkeys? Essentially, what I'm asking, would it be possible to extend the targeting system of party members, which by default can be selected by keys 1-6, to these other groups of targets?
So maybe if a number was displayed on all targetable creatures (friend and foe) say from 1-99 and those numbers could be linked with the keybinding system you have already developed? This would make controlling single target spells and abilities a hell of a lot less fiddly in the heat of battle. Now I know you have only just completed one of my requests and I don't want to seem greedy so I understand if you are busy with other things!
The only thing I can think of off the top of my head: typing numbers that are more than one digit is a little tricky. How do I know that the 77 you just typed wasn't two "target 7" commands? One workaround would be to have a "starting" keypress, and then an "ending" keypress. So, if you wanted to target creature 22, for instance, you would type "`" + "2" + "2" + "`"
How's that sound?
v0.2.1-alpha is now released:
Gameplay changes are now opt-in, instead of being on by default. This version implements the idea of a module. Modules are gameplay changes that are included with EEex, but must be enabled by the user by altering EEex_INI.lua. Here's the currently included modules:Not a bad idea but maybe more complicated than needed. The numbers themselves don't have to necessarily be literally reflected in their keybind. Number 0-9 could simply be combined with a modifier or even a letter key to denote increases of tens. Like shift could be tens, control could be twenties etc. Thus number 22 would simply be "ctrl" + "2". The system you have written is so flexible and extensive there is no limit to combinations.
Love the idea of a modular system and is indeed what I was hoping you would implement! Also greatly looking forward to your plans for greater externalisation of the magic system!
B3_Invis.lua with the imp. invis setting is actually something I've wanted for a long time.
Since this is the time of miracles, I'll add a few feature suggestions as well.
(Not sure if those are within the scope of this project or of general interest though.)
- Externalized Stoneskin color ..
.. or even better, not just color but maybe a 2da file that allowes to point to a specific spell that's applied to the target while a spell's Stoneskin effect is active.
- Externalized Stoneskin absorb effect.
I wonder if it would be possible to also change the damage types a Stoneskin effect can absorb? (E.g. to create an effect that absorbs fire damage hits.)
- Continuing that chain of thought, would it be possible at all to create an "absorb"/absolute resistance effect? (Absorb x amount of damage (not hits) or reduce each hit by x amount of damage)
- Allow the new "character outline" render function (used for the black border around characters and the highlighting for selected characters) to be used as an opcode effect with a color parameter.
I don't like using the sprite outlines myself but I think they would make a great aura effect (which fits all animation shapes and sizes).
-Some kind of flag that excludes specific kits from gaining spells on level up.
Preventing a kit from accessing default cleric or wizard spells would allow for so many cool kits..
Although BGEE and BG2EE do not have a 7eyes.2da file, it will work if you create one. Take a look at 7eyes.2da in Icewind Dale Enhanced Edition if you want to figure out how to do this.
Or, maybe better a 2da that excludes specific spells from designated classes or kits. Like a kit specific hidespl.2da that prevents the spell from bring learned from scrolls.
So, like:
2DA V1.0 0 HIDE KIT_OR_CLASS_NAME SPELL_NAMEWhere the designated kit or class is barred from learning the designated spell at level up or character creation and is barred from learning the spell from scrolls.But even just a class/kit specific hidespl.2da would be all I would need to create custom spell lists (i.e. by changing the way school based spell learning works--i.e. by summoning based dialog or something similar)
One thing I have been wondering, would it be possible to add mouse keys as possible inputs? If mouse keys could be used in this flexible combo style with keyboard keys I think it would become even more dynamic and would possibly do away or at least significantly reduce the amount of practice and care that was needed to opearte a complex keyboard layout. At the moment you have one hand on the mouse anyway that isn't doing much apart from moving the pointer.
And finally, would you be able to add item abilities to be assignable as well? That is the ones that are accessed through the backpack symbol. Items with direct effects can't have keys assigned at present as far as I can see (i have tried using their *.itm resef). Also in your current system can you assign general game functions like "map" or "inventory"?
I know you are really busy and there are loads of others who have asked for your attention so I understand if you are occupied with other things right now!
Or maybe a hpclass.2da like set up:
2DA V1.0 DEFAULT(hidespl) TABLE KIT_OR_CLASS_NAME 2DA_NAMEWhere there is a default 2da that defines restrictions (maybe that could actually be hidespl.2da) but where different kits or classes could reference alternate hidespl-like 2das (that modders would have to create)Would it be possible for EEex to enable this?
Additionally, would it be possible to externalize the sprites assigned to CHARNAME at character creation? Currently they are hardcoded so if one were to, say, make a mod that changes player character sprites... at the end of character creation, CHARNAME would be unaffected, and players would have to use EEKeeper to get their new sprite.
https://github.com/aquadrizzt/MonasticOrders
Edit: iirc, it's a pita. There are some redundancies you have to get around...
Edit 2: I believe you have to apply race based 177 effects in the clab and use scripting. I forget the details, but there are issues when using just one technique
It might be a while before I get any particular person's done, as I now have around ~20 suggestions piled up - just know that I am indeed working on them! I'm only responding to the suggestions in which I have immediate questions on how to implement, all the rest are in the queue:
@fortyseven: 1. Like allowing mouse clicks to be part of a keybinding? I'm not quite sure how that would work, as the mouse buttons are intrinsically hard coded to do other things.
2. Well, at first glance I thought this would be a 2 line fix, but sadly it isn't. Item abilities don't actually use resrefs; they are embedded inside the .ITM itself. I can target the item's resref, but if the item has more than one ability it will just pick the first one. I think the only way to target a specific item ability is to match text...
I've pushed a commit to master that implements this for Opcode #218, and I'll try to implement it for all the other variable-duration opcodes. If someone could post a list of all of these opcode numbers it would be appreciated, so I can make sure I got all of them.
I have never seen this happen, unless the countless magic missiles I've cast at stoneskin-buffed mages has somehow been lying to me.
Sounds like mouse buttons are off-limits if they are hardcoded.
Regarding item abilities, using text might also not work all that well if there is more than one ability on the item. Those abilities have no text element linked to them as far as I can see. In nearinfinity they are numbered but I believe that is entirely internal to that programme. So I'm not sure what you could target? Would the icon.bam be an idea? That is often specific to a single ability and in cases when it isn't it could easily be made to be by copying and renaming the bam file to a unique name.
Also is it possible to target other interface functions at present like opening the "map" or "inventory" with your hotkey.lua?
Would this in any way be able to affect the party size? I doubt it, but one can dream!