@Bubb Actually, never mind. It doesn't have to do with animation-changing effects. It has to do with the type of animation. Only normal humanoid character animations (e.g. MAGE_FEMALE_HUMAN) are affected by opcode 406.
They also skip over sleeping/unconscious/prone creatures, for whatever reason.
Has this always been the case, or was this something introduced in a recent patch? It's hard to tell if this is intentional.
The engine moves sleeping creatures into a "back" list, the main effect of which is that creatures in this list are rendered behind any "normal" creatures. From what I can tell, only dead and sleeping creatures are moved into this state.
For some reason the functions responsible for finding creatures, (used in object selectors and other internal targeting mechanisms), only iterate through creatures in the "normal" list. I'm trying to decide whether it's intentional that these functions don't consider the "back" list creatures, as I might go ahead and fix it.
And @AndreaColombo: First off, nice to see you around here again. The problem looks pretty complex from a cursory look through the assembly, but I'll do my best to see if I can't fix it.
@Bubb It's something that Beamdog has fixed before in at least once instance.
When IWDEE was first released, "Wall" projectiles (Wall of Moonlight) could not hit sleeping/unconscious creatures, this was fixed in one of the 2.x versions.
There are some instances where ignoring sleeping creatures is intended though - those that fail/trigger if they detect a nearby hostile creature: Berserk, Stealth, Set Traps.
You can hide in shadows or set traps around sleeping creatures, and you don't lose control to berserk around sleeping creatures.
There are some checks that include them though: You cannot rest around sleeping creatures, and the contingency option "See Enemy" can fire off sleeping creatures.
I wouldn't doubt that it's intended for "dead" creatures to be ignored by most everything, as only dead party members are ever expected to be targeted, and there are alternate mechanics in place to do so.
@Bubb
Would it be possible to extend opcode#404 to set a 'custom button' which simply fires a spell (instant cast, target self, keep spell)?
e.g.:
Param2: '999 or some value' → custom button
Resource 2 : bam to display
Resource 3 : spell to fire
this would allow for all sorts of custom abilities; auras, shapeshifting, sped up trap detection, and, and, and...
*edit*
Actually, it would probably be better to just use the spell's target and timing/casting modes to allow for maximum customizability.
That way we could even implement cantrips and such.
I made the switch today to the 0.6 alpha from 0.2.1 as I had been on a break. I'm now no longer able to use the hotkey lua. I have placed it in the override file am trying to use the following lines starting at line 4 in the B3_Hotke.lua file:
Good news! @fearless and I have found a fix for the issue outlined here. The alternate renderer should now preserve floating point precision, allowing EEex to work with it enabled!
Currently I'm laying the groundwork for creating new skills, so a character can add points to a new stat on level up!
Brilliant work
Would if be possible to add proficiency slots to specific kits at various levels? Or adjust the a specific characters/kits carry weight using a similar method?
@Bubb
Very cool, not something I'm personally interested in but I think a lot of people would love to have this option.
By the way, I've discovered a minor issue with the extended opcode #280.
If you select #51 as a surge roll the game will crash if a roll is triggered indoors. I assume that is because #51 re-rolls when indoors, thus going into an infinite loop.
I doubt that this warrants a fix since I can't see how this would ever cause any issues for practical applications but I thought I'd mention it anyway.
* I've made it so the new skills can be displayed on the character record screen with the character's other skills:
* I made a new LUA file which has the list of new skills; the new code in UI.MENU looks at this list. I also made a WeiDU function that can add a skill to this list.
* With each new skill, you can set which classes can put points in the skill. You can also let specific kits put points in the skill, even if they're not one of those classes. You can also prevent specific kits from putting points in the skill, regardless of their class. Finally, you can set stat requirements for putting points in the skill (e.g. a character can only do so if they have at least 16 Wisdom).
* All the changes to UI.MENU are patched in, without overwriting it.
@Bubb I would like to add this new skills feature to EEex. By itself it does not add any new skills to the game, but it enables modders to do so (the changes to UI.MENU should be invisible if no new skills are added). However, it requires some WeiDU patching. Should the patches be included in the main EEex component, or should I add a new component to EEex?
@OlvynChuru: If completely invisible, it would be fine to extend the main EEex component. Depending on how complex the UI.MENU changes are, it might be possible to have them dynamically loaded in, as to not cause incompatibility with UI mods. I'd have to see your changes to assess if that's possible, though.
Once I merge it in I'll see about the possibility of doing it dynamically. Sounds like a really cool feature, would be glad to add it to EEex.
@Bubb - One more request from me, as though I hadn't put forth enough already (I almost feel guilty now) XD
Speaking of ToBEx components that never made it to the Enhanced Editions, I was browsing the SCS readme when I ran into this:
Allow players to use the individual versions of Spell Immunity in triggers
Spell Immunity is really eight sub-spells. This component allows a subspell to be placed into a Contingency or Spell Trigger.
On Enhanced-Edition installs, this is done crudely, by introducing scrolls of the eight different versions of Spell Immunity. ToBex allows it to be done more smoothly on original-game installs.
Would it be possible to implement the ToBEx solution via EEex?
I was hoping for a solution that didn't require SCS to introduce scrolls of all different sub-spells.
It doesn't. I don't have SCS, that was the unmodded behavior. All I have memorized is Spell Immunity, the sequencer/contingnecy menu automatically replaces it with it's 8 subspells.
I was brainstorming a bit. Is there any reason to externalize which familiar the engine chooses for find familiar, and the hardcoded link to the protagonist? Modders can already make "lite" familiars with the
AddFamiliar()
script action, so would externalizing Opcode #192 really help anything?
(also, I'm currently working on EEex_MatchObject - it's more complicated than I thought, heh)
Comments
https://support.baldursgate.com/issues/26799
IIRC, ToBEx fixes it for the originals but that's unfortunately part of the half Beamdog never implemented.
Has this always been the case, or was this something introduced in a recent patch? It's hard to tell if this is intentional.
The engine moves sleeping creatures into a "back" list, the main effect of which is that creatures in this list are rendered behind any "normal" creatures. From what I can tell, only dead and sleeping creatures are moved into this state.
For some reason the functions responsible for finding creatures, (used in object selectors and other internal targeting mechanisms), only iterate through creatures in the "normal" list. I'm trying to decide whether it's intentional that these functions don't consider the "back" list creatures, as I might go ahead and fix it.
And @AndreaColombo: First off, nice to see you around here again. The problem looks pretty complex from a cursory look through the assembly, but I'll do my best to see if I can't fix it.
When IWDEE was first released, "Wall" projectiles (Wall of Moonlight) could not hit sleeping/unconscious creatures, this was fixed in one of the 2.x versions.
There are some instances where ignoring sleeping creatures is intended though - those that fail/trigger if they detect a nearby hostile creature: Berserk, Stealth, Set Traps.
You can hide in shadows or set traps around sleeping creatures, and you don't lose control to berserk around sleeping creatures.
There are some checks that include them though: You cannot rest around sleeping creatures, and the contingency option "See Enemy" can fire off sleeping creatures.
I wouldn't doubt that it's intended for "dead" creatures to be ignored by most everything, as only dead party members are ever expected to be targeted, and there are alternate mechanics in place to do so.
Would it be possible to extend opcode#404 to set a 'custom button' which simply fires a spell
(instant cast, target self, keep spell)?
e.g.:
this would allow for all sorts of custom abilities; auras, shapeshifting, sped up trap detection, and, and, and...
*edit*
Actually, it would probably be better to just use the spell's target and timing/casting modes to allow for maximum customizability.
That way we could even implement cantrips and such.
(That's a placeholder description)
B3Hotkey_Hotkeys = {
{function() B3Hotkey_TogglePrintKeys() end, {}, {0x60}}, -- Key-Pressed Output Toggle
{function() B3Hotkey_AttemptToCastViaHotkey("SPWI112") end, {}, {0x61, 0x73, 0x64}},
However, when I press ASD in game (am using BGEE instead of BG2EE) I can't get Magic Missle to trigger.
Am doing something wrong here?
Brilliant work
Would if be possible to add proficiency slots to specific kits at various levels? Or adjust the a specific characters/kits carry weight using a similar method?
The first thing is probably doable; I don't know about the second thing.
Is changing the UI scale level something anyone would want to do?
Very cool, not something I'm personally interested in but I think a lot of people would love to have this option.
By the way, I've discovered a minor issue with the extended opcode #280.
If you select #51 as a surge roll the game will crash if a roll is triggered indoors. I assume that is because #51 re-rolls when indoors, thus going into an infinite loop.
I doubt that this warrants a fix since I can't see how this would ever cause any issues for practical applications but I thought I'd mention it anyway.
This is fantastic! And they way you have implemented it looks so professional as if it had always been part of the game. Very cool indeed!
* I've made it so the new skills can be displayed on the character record screen with the character's other skills:
* I made a new LUA file which has the list of new skills; the new code in UI.MENU looks at this list. I also made a WeiDU function that can add a skill to this list.
* With each new skill, you can set which classes can put points in the skill. You can also let specific kits put points in the skill, even if they're not one of those classes. You can also prevent specific kits from putting points in the skill, regardless of their class. Finally, you can set stat requirements for putting points in the skill (e.g. a character can only do so if they have at least 16 Wisdom).
* All the changes to UI.MENU are patched in, without overwriting it.
@Bubb I would like to add this new skills feature to EEex. By itself it does not add any new skills to the game, but it enables modders to do so (the changes to UI.MENU should be invisible if no new skills are added). However, it requires some WeiDU patching. Should the patches be included in the main EEex component, or should I add a new component to EEex?
Once I merge it in I'll see about the possibility of doing it dynamically. Sounds like a really cool feature, would be glad to add it to EEex.
Speaking of ToBEx components that never made it to the Enhanced Editions, I was browsing the SCS readme when I ran into this:
Would it be possible to implement the ToBEx solution via EEex?
script action, so would externalizing Opcode #192 really help anything?
(also, I'm currently working on EEex_MatchObject - it's more complicated than I thought, heh)