What about a new opcode that can set STATEs from STATE.ids? In other words, something similar to opcode #328 but with STATEs.............
You mean like:
Berserk(3)
Kill(13)
Haste(16)
Invisibility(20)
Panic(24)
Poison(25)
Silence(38)
Sleep(39)
Slow(40)
Stun(45)
Infravision(63)
Blur(65)
Non-detection(69)
Blindness(74)
Feeblemindedness(76)
Confusion(128)
The only ones you cannot set directly have a zero-effect by themselves (they need a value, which their existing opcodes provide): AID, BLESS, CHANT, LUCK, DUHM, BADCHANT, CHARMED, MIRRORIMAGE
I've been thinking about ways of making AREA script slot (SCRLEV.IDS) fully usable by creatures. Currently script can be assigned to this slot via ChangeAIScript action and opcode #82, but the assignment is gone after loading the game since (unlike IWD2) the game can't store the string with AREA script name.
I'm wondering if one of the below implementation ideas would be viable for EEex:
- new condition for opcode #232 (Cast Spell on Condition) that triggers only on the same circumstances that makes OnCreation() action return true (spawning, loading the game). Having it done via spell condition would also open a workaround for other stuff that are not remembered between game sessions.
- alternatively new opcode, timing mode or whatever would be the easier to implement
- or maybe using 8 bytes from 128 unused bytes in ARE Actor structure and forcing engine to use it the way it uses SPECIFICS slot
@swit: All possible. I could also expand the .CRE format itself; it is very easy to "push back" the dynamic-offset structures, allowing me more space to store new data. It's also nice because the vanilla game safely ignores new data that is stored in this manner.
Wow, I didn't had high hopes when asking about it. I'm looking forward seeing if the idea will indeed turn out to be feasible effort wise at some point.
As for the actual implementation I'm not sure which option would be optimal here. From what I remember SPECIFICS script slot (existing in ARE Actor structure, but not directly on CRE) is not permanent if the CRE has been spawned via INI file (script_specifics INI assignment only, no such problems if CRE is spawned via ARE or CreateCreature), so having additional script slot on CRE file instead may have benefits.
Is the object LastSummonerOf() one of those things that are not remembered between game sessions (e.g., after a save & reload)?
Unless I missed something in my tests LastSummonerOf(Myself) is indeed lost after re-load, so you need to spawn new CRE each session, if you want to maintain the link.
I've been thinking about ways of making AREA script slot (SCRLEV.IDS) fully usable by creatures. Currently script can be assigned to this slot via ChangeAIScript action and opcode #82, but the assignment is gone after loading the game since (unlike IWD2) the game can't store the string with AREA script name.
I'm wondering if one of the below implementation ideas would be viable for EEex:
- new condition for opcode #232 (Cast Spell on Condition) that triggers only on the same circumstances that makes OnCreation() action return true (spawning, loading the game). Having it done via spell condition would also open a workaround for other stuff that are not remembered between game sessions.
While I'm not sure if it will fulfill your request, While Equipped effects from equipped items trigger when the creature is spawned or the game is loaded. Perhaps you could give a creature an undroppable ring or something that has a While Equipped effect that gives the creature an area script.
@OlvynChuru, interesting, I've finished testing it and your idea indeed works when it's done via ITM with Instant/While equipped timing mode. Not directly, since for some reason setting opcode 82 on item itself doesn't work with SPECIFICS and AREA script slots (no problem with OVERRIDE), but it works as you described if opcode 82 is called via additional spell called from item via Cast spell (146) opcode. This way the Area script slot still works after game re-load.
I've also tried to make it work without item, by attaching opcode 82 and 146 directly to the CRE file with different timing modes, but none of those attempts were successful with maintaining the script after reload.
While not a perfect solution for the purpose I need it for (porting IWD2 into EE engine) due to tons of dummy items, dummy spells, and duplicated CRE files needed to make it work (since the same CRE can't have AREA script slot assigned via ARE file, so each case that requires different script in that slot would require another version of the creature) and potential for bugs (due to ChangeCurrentScript() and ChangeAIScript() action usage in scripts, which may be problematic if the wrong AREA script will be restored after reload - this will require finding all such cases and rewritting those scripts) but a solution nevertheless
@Bubb, should I continue with the idea proposed by OlvynChuru or maybe you're still interested in trying to expand ARE/CRE format with the missing slot in future?
@swit: I don't know IWD2 well enough to say, but I do know that you were the one who first proposed breaking hardcodedness in order to make porting IWD2 to the EEs possible. If you think you can port it without using EEex, I would, as of course it would be one less dependency for you to have to work around.
If there are portions that literally cannot be ported without engine modifications, I'd say using arguably tricky mechanics when you could be using a much simpler mechanic from EEex, (which you would already be relying on for some other reason), doesn't make much sense.
In this instance it's up to you; I'll attempt to make any modification you require for IWD-in-EET, if you believe you need it / want it.
@subtledoctor, current IWD2 in EE engine attempt is already designed and coded with EEex in mind. At the beginning the project started as a port of the work done by dradiel on Word of Baldur's Gate - vanilla engine (not EE) project available only in polish community that mixes many mods together and has whole IWD2 content ported in it. Due to engine limitations the author was forced to make some liberties and had to often rewrite scripts from scratch to make it work. Since the announcement of EEex and after contacting Bubb about the possibilities that it will bring I've scrapped everything and decided to port IWD2 from scratch, taking advantage of what EE engine has to offer + whatever I will manage to get out of EEex.
I've recently finished the weidu code that automatically converts IWD2 scripts and dialogs to work with EE engine (all done on the fly, so easy to make changes to conversion logic as needed). Few functions that awaits for EEex Lua functionality to work correctly also can be compiled since they have been turned into EEex_Lua and EEex_LuaTrigger blocks (Lua code is not ready yet). With the IWD2 8 script levels sorted (one way or another, mentioned in previous post) that I had in back of my mind for a long time, and with EEex functionality in mind, I'm very optimistic regarding the IWD-in-EET viability.
Not using EEex would mean (among other required changes and limitations) re-writing whole IWD2 combat AI from scratch, which would be a tremendous task considering IWD2 is really a hack'n'slash game. With access to object data, variables and vanilla actions/triggers run from within Lua environment (and/or natively but with highjacked data), the few IWD2 functions that I didn't manage to rewrite using IE/EE equivalents should be doable without breaking the original script logic.
Let me give an example of a recent discovery. Sounds like a mess at the first glance when it comes to porting scripts to EE engine, considering the amount of times variables are set like that in IWD2. Such engine difference may result in tons of bugs (unless you spend awful amount of time reading the script logic line by line and rewriting it as needed). With EEex it's a matter of changing SetGlobal (only if fallowed by Continue()) with EEex_Lua action that will update the variable at the same script run.
I'll attempt to make any modification you require for IWD-in-EET, if you believe you need it / want it.
@subtledoctor, it has been already communicated in this post from October. I will post a link to my previous post in that topic to clarify it.
As for the IWD1 content hanging up it's due to story related reasons (conflict between IWD1 story and SoD villain, as well as some characters and references showing up in both IWD1 and IWD2 story). Together with @AWizardDidIt we've managed to bring the story together without need of rewriting IWD2, but this approach favors distributing whole IWD1 and IWD2 content together. Also since IWD2 won't import resources on the fly and it's dependent on some IWD:EE resources (which are imported on the fly in similar way as EET) distributing both parts in the same package makes sense, imo.
Once the mod is ready I'm also considering making it work with just IWD:EE (without need of EET), but it has lower priority. Also keep in mind that IWD-in-EET is meant to also allow to play just IWD2 content without bhaalspawn story via "Select Campaign" functionality.
But let’s not high jack this topic any further - there is a dedicated forum for this mod.
@kjeron: Do you still experience crashes when attempting to use EEex? If so, please try the latest version. The loader fundamentally changes EEex startup and how it writes patches - it very well could have fixed an incompatibility caused by what I believe was an OS specific difference.
@kjeron: Do you still experience crashes when attempting to use EEex? If so, please try the latest version. The loader fundamentally changes EEex startup and how it writes patches - it very well could have fixed an incompatibility caused by what I believe was an OS specific difference.
On BG2EE - The newest build (v.0.4.0) crashes as soon as I load any game, without having made any modifications other than installing EEex.
On BGSOD - The newest build loads games just fine, but the actionbar still will not change. Haven't tested other things yet. So far - the HookBard Thieving function does work in BGSoD.
Is there a way to run EEex.exe through the command window to see feedback while the game is running, as can be done with baldur.exe?
@kjeron: I am really grasping at straws here - we already exhausted most avenues before...
It might be some sort of hardware configuration difference. I know that assembly has adjust for the user's CPU in some cases to decide which FPU instructions to use, so maybe your processor is old enough to not support the new vectorized variants?
Can you list your CPU please? I'm running out of ideas on how to debug other than teleporting to you and stealing your computer for a while.
Also, the launcher doesn't pass its environment to the game - I'll message fearless and see if that would be possible.
So far - the HookBard Thieving function does work in BGSoD.
Well... uhh... that is strange. Just to make sure, could you upload the EEex.ini and EEex.log of each game, noting the game versions?
Edit: Also, try flipping EEex_MinimalStartup from false to true in M__EEex.lua. If it still crashes after that, god help us.
Just wanted to pop in and say that even though I don't understand half the stuff talked here and I'm not a modder, the stuff talked and implemented here gets me excited. Great work guys. Now I'll let myself out.
It might be some sort of hardware configuration difference. I know that assembly has adjust for the user's CPU in some cases to decide which FPU instructions to use, so maybe your processor is old enough to not support the new vectorized variants?
Edit: Also, try flipping EEex_MinimalStartup from false to true in M__EEex.lua. If it still crashes after that, god help us.
BG2EE was at least able to load a game with this change.
In SoD (so far):
Changing action bar buttons does not work.
HookBard Thieving works
Lua action/triggers work, as did B3SpellToPoint function
Opcode changes work
Edit - ini/log files sent in PM - forum still is not allowing uploading archive (*.zip) files.
It might be some sort of hardware configuration difference. I know that assembly has adjust for the user's CPU in some cases to decide which FPU instructions to use, so maybe your processor is old enough to not support the new vectorized variants?
Edit: Also, try flipping EEex_MinimalStartup from false to true in M__EEex.lua. If it still crashes after that, god help us.
BG2EE was at least able to load a game with this change.
In SoD (so far):
Changing action bar buttons does not work.
HookBard Thieving works
Lua action/triggers work, as did B3SpellToPoint function
Opcode changes work
Edit - ini/log files sent in PM - forum still is not allowing uploading archive (*.zip) files.
Maybe some anti virus s software is returning a false positive and is deleting or otherwise disabling a vital file?
Edit: I know that my work computer will outright delete weidu exe, so that's what made me think of it
The action bar button changes don't work for me. This is the code in my M_ file (named M_B_BRD) as an ex to give find traps to bards:
EEex_AddResetListener(function()
Infinity_DoFile("M_B_BRD")
end)
--------------------------------------------------
-- bard --
--------------------------------------------------
outerConfig = 0
function EEex_ActionbarListener(config)
outerConfig = config
local actorID = EEex_GetActorIDSelected()
if
config == 0x4
then
EEex_SetActionbarButton(0x5, EEex_ACTIONBAR_TYPE.FIND_TRAPS)
end
end
EEex_AddActionbarListener(EEex_ActionbarListener)
@Grammarsalad: A small mistake that slipped through during the process of updating all the patches to use the loader. v0.4.1-alpha released to fix: here
There are undoubtedly more minor bugs introduced by the last patch, please report any you encounter!
@Grammarsalad: A small mistake that slipped through during the process of updating all the patches to use the loader. v0.4.1-alpha released to fix: here
There are undoubtedly more minor bugs introduced by the last patch, please report any you encounter!
@fearless and I have identified the source of @kjeron's crashes, and it is a doozy for sure.
In short, turning on the alternate renderer somehow lowers Lua's ability to precisely represent large numbers. This, in turn, causes all EEex calculations that involve high memory addresses to return the wrong answer, resulting in undefined behavior that eventually leads to a crash.
To see this for yourself, input the following command into the CLUAConsole:
Infinity_DisplayString(20000000 + 1)
Normal Renderer (Correct):
Alternate Renderer (Wrong):
I am attempting to find a work around, but for now EEex will not work if the alternate renderer is enabled!
Comments
Berserk(3)
Kill(13)
Haste(16)
Invisibility(20)
Panic(24)
Poison(25)
Silence(38)
Sleep(39)
Slow(40)
Stun(45)
Infravision(63)
Blur(65)
Non-detection(69)
Blindness(74)
Feeblemindedness(76)
Confusion(128)
The only ones you cannot set directly have a zero-effect by themselves (they need a value, which their existing opcodes provide): AID, BLESS, CHANT, LUCK, DUHM, BADCHANT, CHARMED, MIRRORIMAGE
I'm wondering if one of the below implementation ideas would be viable for EEex:
- new condition for opcode #232 (Cast Spell on Condition) that triggers only on the same circumstances that makes OnCreation() action return true (spawning, loading the game). Having it done via spell condition would also open a workaround for other stuff that are not remembered between game sessions.
- alternatively new opcode, timing mode or whatever would be the easier to implement
- or maybe using 8 bytes from 128 unused bytes in ARE Actor structure and forcing engine to use it the way it uses SPECIFICS slot
Is the object LastSummonerOf() one of those things that are not remembered between game sessions (e.g., after a save & reload)?
As for the actual implementation I'm not sure which option would be optimal here. From what I remember SPECIFICS script slot (existing in ARE Actor structure, but not directly on CRE) is not permanent if the CRE has been spawned via INI file (script_specifics INI assignment only, no such problems if CRE is spawned via ARE or CreateCreature), so having additional script slot on CRE file instead may have benefits.
Unless I missed something in my tests LastSummonerOf(Myself) is indeed lost after re-load, so you need to spawn new CRE each session, if you want to maintain the link.
While I'm not sure if it will fulfill your request, While Equipped effects from equipped items trigger when the creature is spawned or the game is loaded. Perhaps you could give a creature an undroppable ring or something that has a While Equipped effect that gives the creature an area script.
I've also tried to make it work without item, by attaching opcode 82 and 146 directly to the CRE file with different timing modes, but none of those attempts were successful with maintaining the script after reload.
While not a perfect solution for the purpose I need it for (porting IWD2 into EE engine) due to tons of dummy items, dummy spells, and duplicated CRE files needed to make it work (since the same CRE can't have AREA script slot assigned via ARE file, so each case that requires different script in that slot would require another version of the creature) and potential for bugs (due to ChangeCurrentScript() and ChangeAIScript() action usage in scripts, which may be problematic if the wrong AREA script will be restored after reload - this will require finding all such cases and rewritting those scripts) but a solution nevertheless
@Bubb, should I continue with the idea proposed by OlvynChuru or maybe you're still interested in trying to expand ARE/CRE format with the missing slot in future?
If there are portions that literally cannot be ported without engine modifications, I'd say using arguably tricky mechanics when you could be using a much simpler mechanic from EEex, (which you would already be relying on for some other reason), doesn't make much sense.
In this instance it's up to you; I'll attempt to make any modification you require for IWD-in-EET, if you believe you need it / want it.
I've recently finished the weidu code that automatically converts IWD2 scripts and dialogs to work with EE engine (all done on the fly, so easy to make changes to conversion logic as needed). Few functions that awaits for EEex Lua functionality to work correctly also can be compiled since they have been turned into EEex_Lua and EEex_LuaTrigger blocks (Lua code is not ready yet). With the IWD2 8 script levels sorted (one way or another, mentioned in previous post) that I had in back of my mind for a long time, and with EEex functionality in mind, I'm very optimistic regarding the IWD-in-EET viability.
Not using EEex would mean (among other required changes and limitations) re-writing whole IWD2 combat AI from scratch, which would be a tremendous task considering IWD2 is really a hack'n'slash game. With access to object data, variables and vanilla actions/triggers run from within Lua environment (and/or natively but with highjacked data), the few IWD2 functions that I didn't manage to rewrite using IE/EE equivalents should be doable without breaking the original script logic.
Let me give an example of a recent discovery. Sounds like a mess at the first glance when it comes to porting scripts to EE engine, considering the amount of times variables are set like that in IWD2. Such engine difference may result in tons of bugs (unless you spend awful amount of time reading the script logic line by line and rewriting it as needed). With EEex it's a matter of changing SetGlobal (only if fallowed by Continue()) with EEex_Lua action that will update the variable at the same script run.
As for the IWD1 content hanging up it's due to story related reasons (conflict between IWD1 story and SoD villain, as well as some characters and references showing up in both IWD1 and IWD2 story). Together with @AWizardDidIt we've managed to bring the story together without need of rewriting IWD2, but this approach favors distributing whole IWD1 and IWD2 content together. Also since IWD2 won't import resources on the fly and it's dependent on some IWD:EE resources (which are imported on the fly in similar way as EET) distributing both parts in the same package makes sense, imo.
Once the mod is ready I'm also considering making it work with just IWD:EE (without need of EET), but it has lower priority. Also keep in mind that IWD-in-EET is meant to also allow to play just IWD2 content without bhaalspawn story via "Select Campaign" functionality.
But let’s not high jack this topic any further - there is a dedicated forum for this mod.
https://github.com/mrfearless/EEexLoader
https://support.baldursgate.com/issues/40185
Edit: Some antiviruses might detect EEex.exe or EEex.dll as a threat - this is a false positive due to the loader's use of dll injection.
Does this mean that at some point, we will be able to play IWD2 in the EE engine? I assume it would use 2e rules, though?
On BGSOD - The newest build loads games just fine, but the actionbar still will not change. Haven't tested other things yet. So far - the HookBard Thieving function does work in BGSoD.
Is there a way to run EEex.exe through the command window to see feedback while the game is running, as can be done with baldur.exe?
BG1EE - launching game ok
SoD - launching game ok
BG2EE - launching game ok
IWD1EE - launching game ok
It might be some sort of hardware configuration difference. I know that assembly has adjust for the user's CPU in some cases to decide which FPU instructions to use, so maybe your processor is old enough to not support the new vectorized variants?
Can you list your CPU please? I'm running out of ideas on how to debug other than teleporting to you and stealing your computer for a while.
Also, the launcher doesn't pass its environment to the game - I'll message fearless and see if that would be possible.
Well... uhh... that is strange. Just to make sure, could you upload the EEex.ini and EEex.log of each game, noting the game versions?
Edit: Also, try flipping EEex_MinimalStartup from false to true in M__EEex.lua. If it still crashes after that, god help us.
In SoD (so far):
Changing action bar buttons does not work.
HookBard Thieving works
Lua action/triggers work, as did B3SpellToPoint function
Opcode changes work
Edit - ini/log files sent in PM - forum still is not allowing uploading archive (*.zip) files.
Maybe some anti virus s software is returning a false positive and is deleting or otherwise disabling a vital file?
Edit: I know that my work computer will outright delete weidu exe, so that's what made me think of it
Thanks, though I can't find all that much over there.
EEex_AddResetListener(function() Infinity_DoFile("M_B_BRD") end) -------------------------------------------------- -- bard -- -------------------------------------------------- outerConfig = 0 function EEex_ActionbarListener(config) outerConfig = config local actorID = EEex_GetActorIDSelected() if config == 0x4 then EEex_SetActionbarButton(0x5, EEex_ACTIONBAR_TYPE.FIND_TRAPS) end end EEex_AddActionbarListener(EEex_ActionbarListener)There are undoubtedly more minor bugs introduced by the last patch, please report any you encounter!
Works beautifully again!
In short, turning on the alternate renderer somehow lowers Lua's ability to precisely represent large numbers. This, in turn, causes all EEex calculations that involve high memory addresses to return the wrong answer, resulting in undefined behavior that eventually leads to a crash.
To see this for yourself, input the following command into the CLUAConsole:
Normal Renderer (Correct):
Alternate Renderer (Wrong):
I am attempting to find a work around, but for now EEex will not work if the alternate renderer is enabled!