* Could we make an opcode that temporarily replaces one of the target's scripts with a script of our choice (resetting the script after the effect ends)? This would let us make a lot of cool new enchantment spells (like one that forces the target to spin in place for the duration).
- ?Should? be possible to edit opcode #82 to store the previous script in Param3, and then restore it when it expires.
Could you do the same for opcode #72 (Set IDS State)?
@fortyseven: Hmm, after looking a the EE's keybind system, it's quite... interesting.
The engine only uses 500 dwords to store keybinding data in memory - meaning, the game can only keep track of 500 unique keybind actions. The reason it doesn't show modded spells is because it's completely impossible for it to do so.
The main keybind list ("keybindings") is stored in BGEE.LUA. The action the engine takes when a keybind is pressed is determined by the first column of this structure. Values 67 and below have hardcoded miscellaneous actions, while 68+ are bound to readying spells.
The engine uses the 4th column of the spell keybinding structure to grab the spell's name. It then iterates through all of the currently selected character's spell buttons, and readies one if the tooltip, (the raw one, without keybinding text), matches. It's not testing for resrefs, or even strrefs, it's testing against TEXT...
...combined keyboard inputs (i.e. combining modifier keys like shift/alt/ctrl (and combinations thereof like shift+ctrl etc.) with alphanumeric/symbol keys... Extending this further, many abilities cannot be mapped at all at the moment as they aren't listed in the in-game key mapping menu. This relates in particular to innate skills and to skills and abilities added through modding...
The EE keybinding system is inadequate in both regards; it will have to be a completely new system. I've already gotten key pressed / key released detection done, so it should just be a matter of implementing all of the actions again, and making a new graphical interface.
You sure are amazing. Your ability to x-ray the game code is something to behold.
I'm quite shocked at the system you have uncovered. That the spells are identified through their text is unexpected, but I guess it explains why modded spells that incorperate all the text elements of a stock spell continue to function with the keybinding system.
From what you are saying further, is rebuilding the keybinding system dependent on a rebuilding of the graphical interface? Could key bindings not be handled through an external list of definitions? I guess the old system then wouldn't work and would be left derilct in the options menu but that wouldn't bother me. The stock system is so awful and limited that any replacement in my view would be an improvement!
Really?? That was asking for more points to spend on the level-up screen, not an ability to alter existing prof values. (Opcode 233 can already apply negative modifiers to proficiencies.)
As always, you and kjeron are right. I misinterpreted the request. An opcode absolutely cannot affect the initial character creation, though I still could introduce a new 2DA or a Lua hook to achieve the desired result.
1: Opcode #318 and #324 share the same function, the only difference between the two is that the opcode # determines whether or not the code displays a string. It's easy enough to force Opcode #324 to display the strref present in the Special field, and it's only a 5 byte change.
2: There is a disconnect between what you want, and what is happening. States / Spell States, by their nature, don't have any sort of link back to the opcode that set them. A hacky way to get this to work with Spell States would be to introduce a new trigger that iterates through all the opcodes present on the target creature, and return true if an opcode #328 was found setting the given state with dispelable parameters. Of course this doesn't work in regards to opcodes that hardcoded a spell state change.
Tl;dr: it's quite the undertaking. It probably is possible, but will need to be thought out further.
@fortyseven: Well, I've got an experimental hotkey replacement up and running. It doesn't have a graphical interface yet, but it can handle any combination of keys, of arbitrary length.
Would it now be possible to create kits that allow for extra proficiency slots at 1st level, and/or extra proficiency slots upon levelling up?
So, like a PROFSMAX.2DA that works in relation to kits, instead of classes? Or are you talking about spendable points? Why do I get so confused about this topic?
2: There is a disconnect between what you want, and what is happening. States / Spell States, by their nature, don't have any sort of link back to the opcode that set them. A hacky way to get this to work with Spell States would be to introduce a new trigger that iterates through all the opcodes present on the target creature, and return true if an opcode #328 was found setting the given state with dispelable parameters. Of course this doesn't work in regards to opcodes that hardcoded a spell state change.
I think a trigger that checks if the target has *any* dispellable effects would be a good start. It's an oddity that there has never been a script trigger equivalent to opcode 225. Really this is something Beamdog should implement, as it affects the base game without mods (creatures are currently scripted to attempt to dispel the undispellable).
Sorry if I'm not replying right away guys - I'm not ignoring you, just investigating.
You take your time Bubb! As far as I'm concerned the fact that you are looking into these issues at all is a gift. Especially as Beamdog appears to be completely winding down their involvment with the infinity engine and there is little hope now they will look into any major opcode or interface expansions any time soon.
@fortyseven: Well, I've got an experimental hotkey replacement up and running. It doesn't have a graphical interface yet, but it can handle any combination of keys, of arbitrary length.
That's fantastic! Does that mean you can bind any spell or skill to any key combo you want? Is that for stock abilities using the text recognition system or have you replaced that with something else?
@fortyseven: The vanilla system actually had the capability of doing more than what the devs implemented using it. I didn't overwrite the vanilla system, (at least as of yet), I implemented another one alongside it.
I am matching resrefs instead of text. The resrefs can be bound to any key combination, and the system will look for said resref under the character's spells menu, usable items menu, and special abilities menu. Just gotta build an interface for it, and it should be good to go.
The only downside is that since the original system is still intact, you can accidentally bind the same key in both systems, and they both perform their respective actions. Most likely I'll just hide the old keybinding menu from the options.
Sorry if I'm not replying right away guys - I'm not ignoring you, just investigating.
I think we all appreciate what you are doing. No need to apologise. This stuff takes time. Some of us have waited for more than 18 years for these features. So, thank you. Seriously.
Subtledoctor:
Really?? That was asking for more points to spend on the level-up screen, not an ability to alter existing prof values. (Opcode 233 can already apply negative modifiers to proficiencies.)
Bubb:
As always, you and kjeron are right. I misinterpreted the request. An opcode absolutely cannot affect the initial character creation, though I still could introduce a new 2DA or a Lua hook to achieve the desired result
.
Grammarsalad:
The confusion is my fault. I was asking for multiple different things relating to proficiency points. Here is, I think, a few concrete and (I hope) clear requests.
* I'm not sure about @Greener , but I would love a profs.2da that works for kits so that they could gain profs at a different rate than the base class (or if profs 2da was extendable allowing kit entries, so that they could do this--whatever would be easier for you).
So, fighters get (iirc) 4 proficiency points that they can spend at first level, and get one additional point to spend every 3 levels.
It would be cool if we could create a 'mercenary' fighter kit that gets 6 proficiency points at first level that they can spend on proficiencies, and then gets one proficiency point every 4 levels to spend on proficiencies.
* Also, another 2da that would be cool is one that allows us to assign free slots to specific proficiencies for a given kit, like how the ranger gets (Iirc) two free slots in two weapon fighting at first level (it would also be cool as a bonus if this specific bonus was externalized so that we could take this bonus away from the ranger if we wanted).
So, for example, it would be cool if we could create a 'dervish' bard kit that (say) got one free slot to two weapon fighting.
This would be better than using an opcode because you can't predict whether a player might assign any slots to that proficiency at character creation.
Say, you wanted to have a kit that got a single free proficiency in dagger, and you wanted that kit to be able to specialize in dagger. If you restrict they kit to one point in dagger, the ideal situation is that the player assigns one point to dagger, and then the opcode assigns the bonus point after selection: yay, the character has specialization.
But, if they don't select proficiency in dagger at first level, the bonus will fill the one available slot and there player won't be able to advance to specialization later.
* Also, it would be cool if you could include a 2da that grants bonus proficiency points to be spent on proficiencies based on the characters intelligence attribute (either as a new 2da or by extending intmod.2da).
The values would need to be zeroed out by default, giving no bonus proficiency points, because (I think) the mage would get stuck in character creation or level up, but the idea is to let modders assign nonzero values (e.g. +1 proficiency point for characters with 15-16 int, +2 for characters with 17 int, etc).
I would do so much with this (I'm creating a non weapon proficiencies mod that would allow (e.g.) mages to assign those extra points to herbalism or another skill, etc.--so this would make that mod even cooler--imo)
I'm not sure about @Greener , but I would love a profs.2da that works for kits so that they could gain profs at a different rate than the base class (or if profs 2da was extendable allowing kit entries, so that they could do this--whatever would be easier for you).
So, fighters get (iirc) 4 proficiency points that they can spend at first level, and get one additional point to spend every 3 levels. It would be cool if we could create a 'mercenary' fighter kit that gets 6 proficiency points at first level that they can spend on proficiencies, and then gets one proficiency point every 4 levels to spend on proficiencies.
This is exactly what I meant...
The same applies for carry weight, I don't want to change the STRMOD.2DA as that would change the carry weight for everyone creature in the game I'd like something kit specific for example:
kit X gains a +50% carry weight bonus
What ever the STRMOD.2DA value could be multiplied by 1.5?
XP tables would also be kit specific instead of class specific
I think a trigger that checks if the target has *any* dispellable effects would be a good start. It's an oddity that there has never been a script trigger equivalent to opcode 225. Really this is something Beamdog should implement, as it affects the base game without mods (creatures are currently scripted to attempt to dispel the undispellable).
Yeah, this is probably easier to implement..... This trigger must return true *only if* [object] has at least one dispellable effect/opcode (i.e., resist_dispel == 1 or 3).
@fortyseven: The vanilla system actually had the capability of doing more than what the devs implemented using it. I didn't overwrite the vanilla system, (at least as of yet), I implemented another one alongside it.
I am matching resrefs instead of text. The resrefs can be bound to any key combination, and the system will look for said resref under the character's spells menu, usable items menu, and special abilities menu. Just gotta build an interface for it, and it should be good to go.
The only downside is that since the original system is still intact, you can accidentally bind the same key in both systems, and they both perform their respective actions. Most likely I'll just hide the old keybinding menu from the options.
You have made me a very happy person today. I can't tell you how long I have wanted a system like this!
Regarding the issue with the original system still being active, to prevent conflicts between the two systems would there maybe be a way to just zero all the key-bindings in the baldur.lua? I guess the difficulty is that the filepath differs for every player and you don't want to override the other options they have set. The concern I would have is that if the stock system is hidden without removing prior key bindings it could make it difficult for folks to rectify a dual binding if they don't know how to access the baldur.lua. Maybe that would be one for the readme?
At any rate I thank you immensely for your tremendous work in expanding the key-binding system! Let me know if you want any help testing it!
@Luke93: I got the "is anything dispellable?" trigger done. Like so: And in action:
Anything more specific would have to be checking against practically every other opcode manually, so, yeah. Will take a while to compile all of the hardcoded state / spell state changes...
If we're doing this in order to make AI that uses Dispel Magic well, wouldn't it be better simply to attach a single spell state/stat to the spells that someone would want to bother dispelling (e.g. Armor of Faith, Free Action, Chaotic Commands, Protection from Magical Weapons) and have the AI check if a creature has that spell state/stat? (The AI would check for Mirror Images and Stoneskins separately, since those can wear off prematurely). This way, enemies don't waste their Dispel Magic on a player under the effects of a dispellable Hold Person.
Anything more specific would have to be checking against practically every other opcode manually, so, yeah. Will take a while to compile all of the hardcoded state / spell state changes...
@OlvynChuru I don't think this is necessary. Let's take a look at the following example:
If EEex_HaveDispellableEffect(LastSeenBy(Myself)) returns true, it means that at least one of those 20 triggers is dispellable, so Remove Magic is not totally wasted (which is fine). Am I missing something?
@Luke93 The problem is that if your character is wearing a version of a major buff that is undispellable (e.g. a Ring of Free Action) and has some minor dispellable buff like Bless on, enemies will try to cast Dispel Magic on them. The idea would be that you attach a spell state (say, AWESOME_DISPELLABLE_EFFECT) to spells like Free Action and Chaotic Commands, but not to items like the Ring of Free Action. Both the Free Action spell and the Ring of Free Action will still have the Free Action spell state, but enemies will check that when casting Hold Person, not Dispel Magic.
That's also a lot of code you have there, especially when you multiply it by ten. How about this?
IF
!Difficulty(EASIEST)
!GlobalTimerNotExpired("BD_TStop","LOCALS")
!GlobalTimerNotExpired("BD_Cast","LOCALS")
HaveSpell(WIZARD_DISPEL_MAGIC) // SPWI302.SPL (Remove Magic)
See(ThirdNearestEnemyOf(Myself))
CheckStatLT(LastSeenBy(Myself),20,LEVEL)
CheckStatLT(LastSeenBy(Myself),20,LEVEL2)
CheckStatLT(LastSeenBy(Myself),20,LEVEL3)
!CheckStat(LastSeenBy(Myself),1,WIZARD_SPELL_IMMUNITY)
OR(3)
StateCheck(LastSeenBy(Myself),STATE_MIRRORIMAGE)
CheckStatGT(LastSeenBy(Myself),0,STONESKINS)
CheckSpellState(LastSeenBy(Myself),AWESOME_DISPELLABLE_EFFECT)
!StateCheck(LastSeenBy(Myself),STATE_DISABLED)
THEN
RESPONSE #100
SetGlobalTimer("BD_Cast","LOCALS",ONE_ROUND)
Spell(LastSeenBy(Myself),WIZARD_DISPEL_MAGIC) // SPWI302.SPL (Remove Magic)
END
@OlvynChuru: Good point. If you guys can think of a modification that would be of better help just let me know.
I haven't made much progress on the opcodes, but they're the next thing on my list. I was busy re-implementing some of my old stuff into the new loader system. This included 1. EEex_Lua(S:Function*) - A script action that calls a Lua function. 2. EEex_LuaObject - A script object that can be set by the Lua environment. 3. EEex_LuaTrigger(S:Function*) - A script trigger that calls a Lua function, and either succeeds or fails based on the return value.
Other than that, I finally figured out how to render stuff without the engine crawling to 1 FPS. For example, here is the range of Aganazzar's Scorcher visualized:
It's actually kind of interesting; while I was testing I observed that the Range(O:Object*,I:Range*) trigger "corrects" for the isometric view and thus results in a perfectly circular testing area, while the casting range very specifically uses the isometric perspective to create an "oblong" testing area, as can be seen above.
* Could we make a trigger that checks if a creature has protection from a certain opcode? This would simplify spellcaster scripting a lot.
* Similarly, could we make a new kind of SPLPROT condition that checks if the target has protection from the opcode specified in Parameter1? This would obviate the need for all those silly little protection effects scattered all over BG2's spells (e.g. disable display string, disable portrait icon, protection from specific visual effect). This way, the spell Horror, for example, could start with: if a creature has protection from the panic opcode, they have protection from ALL of this spell's effects.
* Also, I was considering an alternative to that awkward spell state modding we were discussing that could have similar benefits. Could we make a kind of SPLPROT condition that checks the value of a local variable on the target? The name of the variable would be stored in the Special field, so it could be up to four letters long (which is still enough for plenty of variable names). An EFF file could also store the variable name, but I'd rather not make individual EFF files for too many effects. The only issue with storing the variable in the Special field is that the Protection from Spell 2 opcode already uses that field as a string reference. However, that's not as big of a problem as it sounds. Any four-letter variable name, when translated from ASCII to a number, will be far beyond the number of any string in the game, so it won't display a weird string accidentally (and if we want it to display an immunity string we can use the Immunity to Spell and Message opcode).
* Could we make a trigger that checks if a creature has protection from a certain opcode? This would simplify spellcaster scripting a lot.
Ye got it boss:
(If you're wondering, I'm setting EEex_LuaObject via a key listener, hovering over the character and pressing "`"). Copying the opcode immunity detection into SPLPROT should be easy.
As for the local variable reading, it should be possible. I'll look into it.
EEex is now living on a shell of a GitHub repository: here.
You can find v0.2.0 in the releases tab. New files include: 1. EEex_Opc.lua (Opcode changes) 2. EEex_Tri.lua (New Triggers) 3. EEex_Obj.lua (New Objects) 4. EEex_Ren.lua (Render Hook)
Other than those files, there's some more utility functions in M__EEex.lua. The internals of EEex has had a major face lift; all EEex related functions / variables are now prefaced with "EEex_", some functions were renamed, the assembly writing system is significantly expanded, etc.
This project needs more exposure, like a hosting on Gibberlings3, imo.
So, I'm not able to alter the action bar anymore. This is what I have in my M_* (titled: "M_PAL.lua") file to give bards the find traps button in the 5th slot:
--------------------------------------------------
-- bard --
--------------------------------------------------
function B3ActionbarListener(config)
local actorID = getActorIDSelected()
if
-- config == 0x4
getActorClass(actorID) == 0x5
then
setActionbarButton(0x5, ACTIONBAR_TYPE.FIND_TRAPS)
end
end
EEex_AddActionbarListener(B3ActionbarListener)
Ahh, I see that I commented out the config check.
The above is the stripped down version to see if I could get the code working at all. The more expanded version is here:
EEex_AddResetListener(function()
Infinity_DoFile("M_PAL") --the name of the file
end)
outerConfig = 0 --to use in MENU.UI
--------------------------------------------------
-- bard --
--------------------------------------------------
function B3ActionbarListener(config)
outerConfig = config --to use in MENU.UI
local actorID = getActorIDSelected()
if
config == 4
and getActorClass(actorID) == 5
then
setActionbarButton(0x5, ACTIONBAR_TYPE.FIND_TRAPS)
end
end
EEex_AddActionbarListener(B3ActionbarListener)
Edit: I haven't tried to mess with MENU.UI yet
Edit2: Lol, also I no longer understand the code in EEex_Brd.lua, and so I don't know how to give all bards access to the thieves pick/disarm capabilities Nevermind edit2. I got it to work. I am still stumped on button displaying, though
If anybody is interested:
Not tested--I did it manually--but this should work:
ACTION_IF FILE_EXISTS_IN_GAME ~EEex_Brd.lua~ BEGIN //if EEEx is installed
COPY_EXISTING ~EEex_Brd.lua~ ~override~
SPRINT old @500016//
SPRINT new @500017//
REPLACE_TEXTUALLY ~%old%~ ~%new%~ //replacing old with new (Enable thievery for all bards)
END
Tra:
@500016 = ~return class~
@500017 = ~if class == 5 then
return 4 -- I'm totally a thief
else
return class
end~
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.
Since the possibilities of this mod seem endless, I just came up with this. If a player or a summon has opcode 193 (invisibility detection) active, would it be possible to change it so that enemies ALWAYS show their foot-circles even if they're stealthed/invisible so you can click on them?
Currently there's no way to attack manually in a situation like this, but assigning the generic "attack nearest" script will let a player with invisibility detection attack a hidden enemy when there's no foot-circle to click on. I thought it was pretty annoying that enemies who can hide after attacking can't be dealt with directly, even though this is the same kind of invisibility-piercing ability that dragons and liches have that let them see through it.
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.
EDIT - actually @Bubb there's a good request: can you change the hard-coded Sanctuary overlay from the horrible purple cylinder to an Improved Invisibility-style translucency?
Sure, should be easy. (since I already found the translucency switch when doing the above...)
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?
Comments
You sure are amazing. Your ability to x-ray the game code is something to behold.
I'm quite shocked at the system you have uncovered. That the spells are identified through their text is unexpected, but I guess it explains why modded spells that incorperate all the text elements of a stock spell continue to function with the keybinding system.
From what you are saying further, is rebuilding the keybinding system dependent on a rebuilding of the graphical interface? Could key bindings not be handled through an external list of definitions? I guess the old system then wouldn't work and would be left derilct in the options menu but that wouldn't bother me. The stock system is so awful and limited that any replacement in my view would be an improvement!
First and foremost, thank you for your incredible work.
Would it now be possible to create kits that allow for extra proficiency slots at 1st level, and/or extra proficiency slots upon levelling up?
Would it be possible to edit the carry weight of a kit or kit specific experience charts without modifying the entire class?
As always, you and kjeron are right. I misinterpreted the request. An opcode absolutely cannot affect the initial character creation, though I still could introduce a new 2DA or a Lua hook to achieve the desired result.
@Luke93: Yep. Tested and confirmed to work. 1: Opcode #318 and #324 share the same function, the only difference between the two is that the opcode # determines whether or not the code displays a string. It's easy enough to force Opcode #324 to display the strref present in the Special field, and it's only a 5 byte change.
2: There is a disconnect between what you want, and what is happening. States / Spell States, by their nature, don't have any sort of link back to the opcode that set them. A hacky way to get this to work with Spell States would be to introduce a new trigger that iterates through all the opcodes present on the target creature, and return true if an opcode #328 was found setting the given state with dispelable parameters. Of course this doesn't work in regards to opcodes that hardcoded a spell state change.
Tl;dr: it's quite the undertaking. It probably is possible, but will need to be thought out further.
@fortyseven: Well, I've got an experimental hotkey replacement up and running. It doesn't have a graphical interface yet, but it can handle any combination of keys, of arbitrary length.
@Greener: So, like a PROFSMAX.2DA that works in relation to kits, instead of classes? Or are you talking about spendable points? Why do I get so confused about this topic?
I am matching resrefs instead of text. The resrefs can be bound to any key combination, and the system will look for said resref under the character's spells menu, usable items menu, and special abilities menu. Just gotta build an interface for it, and it should be good to go.
The only downside is that since the original system is still intact, you can accidentally bind the same key in both systems, and they both perform their respective actions. Most likely I'll just hide the old keybinding menu from the options.
I think we all appreciate what you are doing. No need to apologise. This stuff takes time. Some of us have waited for more than 18 years for these features. So, thank you. Seriously.
Subtledoctor:
Bubb:
Grammarsalad:
The confusion is my fault. I was asking for multiple different things relating to proficiency points. Here is, I think, a few concrete and (I hope) clear requests.
* I'm not sure about @Greener , but I would love a profs.2da that works for kits so that they could gain profs at a different rate than the base class (or if profs 2da was extendable allowing kit entries, so that they could do this--whatever would be easier for you).
So, fighters get (iirc) 4 proficiency points that they can spend at first level, and get one additional point to spend every 3 levels.
It would be cool if we could create a 'mercenary' fighter kit that gets 6 proficiency points at first level that they can spend on proficiencies, and then gets one proficiency point every 4 levels to spend on proficiencies.
* Also, another 2da that would be cool is one that allows us to assign free slots to specific proficiencies for a given kit, like how the ranger gets (Iirc) two free slots in two weapon fighting at first level (it would also be cool as a bonus if this specific bonus was externalized so that we could take this bonus away from the ranger if we wanted).
So, for example, it would be cool if we could create a 'dervish' bard kit that (say) got one free slot to two weapon fighting.
This would be better than using an opcode because you can't predict whether a player might assign any slots to that proficiency at character creation.
Say, you wanted to have a kit that got a single free proficiency in dagger, and you wanted that kit to be able to specialize in dagger. If you restrict they kit to one point in dagger, the ideal situation is that the player assigns one point to dagger, and then the opcode assigns the bonus point after selection: yay, the character has specialization.
But, if they don't select proficiency in dagger at first level, the bonus will fill the one available slot and there player won't be able to advance to specialization later.
* Also, it would be cool if you could include a 2da that grants bonus proficiency points to be spent on proficiencies based on the characters intelligence attribute (either as a new 2da or by extending intmod.2da).
The values would need to be zeroed out by default, giving no bonus proficiency points, because (I think) the mage would get stuck in character creation or level up, but the idea is to let modders assign nonzero values (e.g. +1 proficiency point for characters with 15-16 int, +2 for characters with 17 int, etc).
I would do so much with this (I'm creating a non weapon proficiencies mod that would allow (e.g.) mages to assign those extra points to herbalism or another skill, etc.--so this would make that mod even cooler--imo)
The same applies for carry weight, I don't want to change the STRMOD.2DA as that would change the carry weight for everyone creature in the game I'd like something kit specific for example:
kit X gains a +50% carry weight bonus
What ever the STRMOD.2DA value could be multiplied by 1.5?
XP tables would also be kit specific instead of class specific
Regarding the issue with the original system still being active, to prevent conflicts between the two systems would there maybe be a way to just zero all the key-bindings in the baldur.lua? I guess the difficulty is that the filepath differs for every player and you don't want to override the other options they have set. The concern I would have is that if the stock system is hidden without removing prior key bindings it could make it difficult for folks to rectify a dual binding if they don't know how to access the baldur.lua. Maybe that would be one for the readme?
At any rate I thank you immensely for your tremendous work in expanding the key-binding system! Let me know if you want any help testing it!
And in action:
Anything more specific would have to be checking against practically every other opcode manually, so, yeah. Will take a while to compile all of the hardcoded state / spell state changes...
I don't think this is necessary. Let's take a look at the following example:
IF !Difficulty(EASIEST) !GlobalTimerNotExpired("BD_TStop","LOCALS") !GlobalTimerNotExpired("BD_Cast","LOCALS") HaveSpell(WIZARD_DISPEL_MAGIC) // SPWI302.SPL (Remove Magic) See(ThirdNearestEnemyOf(Myself)) EEex_HaveDispellableEffect(LastSeenBy(Myself)) CheckStatLT(LastSeenBy(Myself),20,LEVEL) CheckStatLT(LastSeenBy(Myself),20,LEVEL2) CheckStatLT(LastSeenBy(Myself),20,LEVEL3) !CheckStat(LastSeenBy(Myself),1,WIZARD_SPELL_IMMUNITY) OR(20) CheckStatGT(LastSeenBy(Myself),0,IMPROVEDHASTE) StateCheck(LastSeenBy(Myself),STATE_MIRRORIMAGE) CheckStatGT(LastSeenBy(Myself),0,TRUE_SIGHT) CheckStatGT(LastSeenBy(Myself),0,STONESKINS) CheckSpellState(LastSeenBy(Myself),RESIST_FEAR) CheckStatGT(LastSeenBy(Myself),0,CLERIC_DEFENSIVE_HARMONY) CheckStatGT(LastSeenBy(Myself),0,CLERIC_CHAOTIC_COMMANDS) CheckStatGT(LastSeenBy(Myself),0,CLERIC_FREE_ACTION) CheckStatGT(LastSeenBy(Myself),0,WIZARD_FIRE_SHIELD) CheckStatGT(LastSeenBy(Myself),0,DEATH_WARD) CheckStatGT(LastSeenBy(Myself),0,DEFENSIVE_MODIFIER) CheckStatGT(LastSeenBy(Myself),0,STRENGTH_MODIFIER) CheckStatGT(LastSeenBy(Myself),3,WIZARD_PROTECTION_FROM_MAGIC_WEAPONS) CheckSpellState(LastSeenBy(Myself),POTION_OF_MAGIC_BLOCKING) CheckSpellState(LastSeenBy(Myself),SCROLL_OF_PROTECTION_FROM_MAGIC) CheckSpellState(LastSeenBy(Myself),SCROLL_OF_PROTECTION_FROM_UNDEAD) HasItemEquiped("BLAKBLAD",LastSeenBy(Myself)) // Black Blade of Disaster HasItemEquiped("HARM",LastSeenBy(Myself)) // Harm HasItemEquiped("SLAYLIVE",LastSeenBy(Myself)) // Slay Living HasItemEquiped("MELFMET",LastSeenBy(Myself)) // Melf's Minute Meteor !StateCheck(NearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(SecondNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(ThirdNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(FourthNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(FifthNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(SixthNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(SeventhNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(EighthNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(NinthNearestEnemyOf(Myself),STATE_DISABLED) !StateCheck(TenthNearestEnemyOf(Myself),STATE_DISABLED) THEN RESPONSE #100 SetGlobalTimer("BD_Cast","LOCALS",ONE_ROUND) Spell(LastSeenBy(Myself),WIZARD_DISPEL_MAGIC) // SPWI302.SPL (Remove Magic) ENDIf EEex_HaveDispellableEffect(LastSeenBy(Myself)) returns true, it means that at least one of those 20 triggers is dispellable, so Remove Magic is not totally wasted (which is fine). Am I missing something?
That's also a lot of code you have there, especially when you multiply it by ten. How about this?
IF !Difficulty(EASIEST) !GlobalTimerNotExpired("BD_TStop","LOCALS") !GlobalTimerNotExpired("BD_Cast","LOCALS") HaveSpell(WIZARD_DISPEL_MAGIC) // SPWI302.SPL (Remove Magic) See(ThirdNearestEnemyOf(Myself)) CheckStatLT(LastSeenBy(Myself),20,LEVEL) CheckStatLT(LastSeenBy(Myself),20,LEVEL2) CheckStatLT(LastSeenBy(Myself),20,LEVEL3) !CheckStat(LastSeenBy(Myself),1,WIZARD_SPELL_IMMUNITY) OR(3) StateCheck(LastSeenBy(Myself),STATE_MIRRORIMAGE) CheckStatGT(LastSeenBy(Myself),0,STONESKINS) CheckSpellState(LastSeenBy(Myself),AWESOME_DISPELLABLE_EFFECT) !StateCheck(LastSeenBy(Myself),STATE_DISABLED) THEN RESPONSE #100 SetGlobalTimer("BD_Cast","LOCALS",ONE_ROUND) Spell(LastSeenBy(Myself),WIZARD_DISPEL_MAGIC) // SPWI302.SPL (Remove Magic) ENDI haven't made much progress on the opcodes, but they're the next thing on my list. I was busy re-implementing some of my old stuff into the new loader system. This included
1. EEex_Lua(S:Function*) - A script action that calls a Lua function.
2. EEex_LuaObject - A script object that can be set by the Lua environment.
3. EEex_LuaTrigger(S:Function*) - A script trigger that calls a Lua function, and either succeeds or fails based on the return value.
Other than that, I finally figured out how to render stuff without the engine crawling to 1 FPS. For example, here is the range of Aganazzar's Scorcher visualized:
It's actually kind of interesting; while I was testing I observed that the Range(O:Object*,I:Range*) trigger "corrects" for the isometric view and thus results in a perfectly circular testing area, while the casting range very specifically uses the isometric perspective to create an "oblong" testing area, as can be seen above.
* Could we make a trigger that checks if a creature has protection from a certain opcode? This would simplify spellcaster scripting a lot.
* Similarly, could we make a new kind of SPLPROT condition that checks if the target has protection from the opcode specified in Parameter1? This would obviate the need for all those silly little protection effects scattered all over BG2's spells (e.g. disable display string, disable portrait icon, protection from specific visual effect). This way, the spell Horror, for example, could start with: if a creature has protection from the panic opcode, they have protection from ALL of this spell's effects.
* Also, I was considering an alternative to that awkward spell state modding we were discussing that could have similar benefits. Could we make a kind of SPLPROT condition that checks the value of a local variable on the target? The name of the variable would be stored in the Special field, so it could be up to four letters long (which is still enough for plenty of variable names). An EFF file could also store the variable name, but I'd rather not make individual EFF files for too many effects. The only issue with storing the variable in the Special field is that the Protection from Spell 2 opcode already uses that field as a string reference. However, that's not as big of a problem as it sounds. Any four-letter variable name, when translated from ASCII to a number, will be far beyond the number of any string in the game, so it won't display a weird string accidentally (and if we want it to display an immunity string we can use the Immunity to Spell and Message opcode).
Keep it up!
(If you're wondering, I'm setting EEex_LuaObject via a key listener, hovering over the character and pressing "`"). Copying the opcode immunity detection into SPLPROT should be easy.
As for the local variable reading, it should be possible. I'll look into it.
You can find v0.2.0 in the releases tab. New files include:
1. EEex_Opc.lua (Opcode changes)
2. EEex_Tri.lua (New Triggers)
3. EEex_Obj.lua (New Objects)
4. EEex_Ren.lua (Render Hook)
Other than those files, there's some more utility functions in M__EEex.lua. The internals of EEex has had a major face lift; all EEex related functions / variables are now prefaced with "EEex_", some functions were renamed, the assembly writing system is significantly expanded, etc.
Documentation still pending™
What can you tell me of this? Do you know of any workaround?
So, I'm not able to alter the action bar anymore. This is what I have in my M_* (titled: "M_PAL.lua") file to give bards the find traps button in the 5th slot:
-------------------------------------------------- -- bard -- -------------------------------------------------- function B3ActionbarListener(config) local actorID = getActorIDSelected() if -- config == 0x4 getActorClass(actorID) == 0x5 then setActionbarButton(0x5, ACTIONBAR_TYPE.FIND_TRAPS) end end EEex_AddActionbarListener(B3ActionbarListener)Ahh, I see that I commented out the config check.
The above is the stripped down version to see if I could get the code working at all. The more expanded version is here:
EEex_AddResetListener(function() Infinity_DoFile("M_PAL") --the name of the file end) outerConfig = 0 --to use in MENU.UI -------------------------------------------------- -- bard -- -------------------------------------------------- function B3ActionbarListener(config) outerConfig = config --to use in MENU.UI local actorID = getActorIDSelected() if config == 4 and getActorClass(actorID) == 5 then setActionbarButton(0x5, ACTIONBAR_TYPE.FIND_TRAPS) end end EEex_AddActionbarListener(B3ActionbarListener)Edit: I haven't tried to mess with MENU.UI yet
Edit2: Lol, also I no longer understand the code in EEex_Brd.lua, and so I don't know how to give all bards access to the thieves pick/disarm capabilitiesNevermind edit2. I got it to work. I am still stumped on button displaying, though
If anybody is interested:
It's annoying, I know, but it had to be done at some point. There were bound to be namespace collisions if I didn't get a standard prefix going -
I missed those!! Lol, I know you said something like this in your release notes. I only noticed EEex_AddActionbarListener.
Thanks
Currently there's no way to attack manually in a situation like this, but assigning the generic "attack nearest" script will let a player with invisibility detection attack a hidden enemy when there's no foot-circle to click on. I thought it was pretty annoying that enemies who can hide after attacking can't be dealt with directly, even though this is the same kind of invisibility-piercing ability that dragons and liches have that let them see through it.
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.
Sure, should be easy. (since I already found the translucency switch when doing the above...)