K4thos

subtledoctor, don't worry, if I will be able to implement this system (as mentioned I'm not even sure if the system will be possible the way I've envisioned it considering it depends on Bubb implementing control over spell casting level and access to disabled cleric scroll), there will be a stand alone version with more options as well. And I don't have a problem with component that removes 2nd ed progression rules all-together from game for example, if there is demand for such feature. The system itself could be also used as a base for other mods. I'm open to collaboration too (keep in mind that work on it will start once I finish IWD-in-EET, not now). But yes, currently I'm designing it with IWD-in-EET in mind first and foremost. There are for example tons of skill checks in IWD2 dialogs, so instead of converting them to ability score checks like I did before, now I'm thinking about keeping them as they are, with this system in mind. For now I'm probably going to convert IWD2 dialogue skill checks into variable checks which will be set passively based on character's ability scores and existing skills. This way it will be easy to implement active skill selection once the system is implemented. IWD2 creatures (even non-humanoids) uses feats, so I've decided to port them over and assign those feat features into cre files. Exactly the same feats would be selectable for player when the system is implemented. etc. If by "this stuff" you mean Lua than maybe. All the other things I'm pretty sure you have more knowledge about. The core of this idea is not really that complicated - most of the leveling system stuff would be handled via external lua code, not really intrusive patching of vanilla spells, items etc. (the only intruisive skill that I can think of would be Item Use, feats are not intrusive at all, multi-classing working like in IWD2 doesn't really change that much, acces to items is handled by using W/M/T class as a base for character following this system, even though we're not using progression of that class) Think about it more like a kit that brings new possibilities (pretty much "create your own kit as you play") not something that will turn the gameplay upside-down. edit: didn't notice your second post, will reply to it once I finish reading.

I've just checked the 2 stats mentioned by lynx (Class String Override Mixed, Class String Override Lower) and they seem like a perfect fit for 2 skills that absolutely require to be stats in order to work as expected: - these stats can be modified by opcode 282 (Modify script state) - they are not used by any mod yet since changing them alters what is displayed in record screen - not a problem for this mod, I can alter what will be displayed - they don't have limited ranges like profiniencies - can be checked in scripts via CheckStat() Overall perfect, without any drawback that I can think of. Thanks!

Thanks subtledoctor. I have few issues with the proposed implementation, though: - it sounds like a hell to implement and test (can't say I understood all of the stuff you've mentioned) - the system is meant to be used alongside classic BG functionality, not replace it (you can still play with NPC using some awesome kit alongside another NPC or player character that follows IWD2 style rules hybrid) - grouping proficiency together would likely conflict with many mods and would force IWD-in-EET to be installed at the very end in order to implement those changes, which is not really something I would like to be the case (like EET, the mod is meant to be open platform that other mods can expand) - updating item descriptions etc. sounds like a nightmare (can be implemented though) All of these headaches just to make items that can increase all skills? Sounds excessive to me considering I've just finished testing this idea and it works as expected. Still not sure why you've mentioned that "Repeating 272 and invisicres are things I try to avoid at all costs. Combining them is my modding nightmare." when it's actually extremly easy to implement (took me like 5 minutes to test it) and seems reliable, unless I'm missing something. edit: those class strings seems like a good idea, considering the characters that follows progression system introduced in this mod don't really need them (we can adjust what is displayed in record screen etc.), but what exactly sets them? Can they be altered via opcodes, detected in scripts, accept values instead of strings?

care to elaborate? edit: simplified the script by moving variable increment into item and spell effects. This way ActionOverride and unique variable are no longer needed.

When I now think about it items that give bonus could still exist for all skills, even if 6 of them is stored only in local variables, not stats. Just make the item use opcode #272 (Apply Repeating EFF) which spawns invisible creature, with script like this: //the item increases "ALCHEMY" local variable via opcode 309 //spell_with_opcode321 has item name as resource to remove further spawning, also decreases "ALCHEMY" local variable IF HasItemEquiped("nameOftheItem",LastSummonerOf(Myself)) THEN RESPONSE #100 DestroySelf() END IF True() THEN RESPONSE #100 ApplySpellRES("spell_with_opcode321",LastSummonerOf(Myself)) DestroySelf() END So I think we're back to just 2 stats (Concentration and Use Magic Device) that are needed with at least 0-20 range. Although I will need to test it first.

good point, completely forgot about it. Here are the currently missing skills stats: - ALCHEMY (Alchemy) - ANIMALS (Animal Empathy) - BLUFF (Bluff) - CONCENTRATION (Concentration) - DIPLOMACY (Diplomacy) - INTIMIDATE (Intimidate) - SPELLCRAFT (Spellcraft) - MAGICDEVICE (Use Magic Device) And here are those that already exists: - DETECTILLUSIONS (Search) - TRAPS (Disable Device) - HIDEINSHADOWS (Hide) - LORE (Knowledge Arcana) - STEALTH (Move Silently) - LOCKPICKING (Open Lock) - PICKPOCKET (Pick Pocket) - TRACKING (Wilderness Lore) - SETTRAPS (this skill actually didn't exist in IWD2) Which means highjacking 8 stats would be better Although if I won't be able to do find good candidates, just 2 is still enough to make the skill system work, even if it won't be as good as it could be. Interesting, I will write a weidu code that analyze all files in game to check which ones are ready for re-mapping since they already use Spellstates. I will post results in this topic. I was thinking about patching all scrolls and wands in game to cast different spell if specific class is using it with checks for MAGICDEVICE value in order to determinate if the casting is successful (splprot.2da checks, maybe additional Apply effects list). I'm not that good when it comes to opcodes, so will need to test what will work first. Will post example item here when (if?) I manage to get it working. Unless Kjeron can confirm that it can't be implemented already. "Can't Use Itemtype" effect is not the way I'd like to implement it. In IWD2 player can use those items. Using them successfully is dependent on dice roll and MAGICDEVICE stat value (increased by modifier) Thanks, will check it out. In this system every single skill, feat, class level etc. is meant to be visible on record screen. Same for level-up stuff (all windows related to it will be rewritten, so that you can select feats, check their descriptions, increase ability points etc. - see IWD2 gui, that's how it's meant to work). GUI is coded in Lua, and with stuff that Bubb is working on it won't be a problem to fetch data into Lua variable that can be displayed: - Infinity_GetLocal(creatureID, local) - Bubb_StoreLocal(S:Variable*,S:Local*) - Bubb_StoreObjectStat(S:Variable*,O:Object*,I:Stat*STATS)) The system will either feel like it had been officially implemented (everything working with GUI, no workarounds that can be noticed in-game like selecting something via dialogue etc.) or I won't bother implementing it.

I don't think so, but modification via opcode is not needed for the mod I'm working on. XPVALUE works with CheckStat and ChangeStat. I need it as stat to make it work with splprot.2da. will skip this one in this case thanks, will check my old topic. if you mean in relation to the design I've proposed the bolded part is not the reason why I need those 2 stat.ids entries. They are meant to be used just for 2 missing skills that can't be implemented without stats: - Use Magic Device - Concentration (in order to implement it properly exe hack to change CONCENTR.2da formula would be needed as well (from Luck into some other stat number). Tracking (Wilderness Lore) is another IWD2 skill that the mod is meant to implement (well, it's meant to bring all of them). Even though this skill doesn't really need stat.ids entry to work as intended I think it would be a bit silly to replace it when it's actually used. May be useful for other mods, if someone decides to take advantage of Wilderness Lore via spells.

In order to implement this system I will need 2 stat.ids entries. Spell states functionality is not an option due to design decisions that Beamdog made (those stats don't accept values and splstate is capped at just 255 entries. I need a range of at least 0-20 per stat, which would be 40 spell states entries - unacceptable in heavily modded game). Hence the question - which stat.ids entry do you think would be a best candidate to highjack? I was thinking about following ones: 1. 31 INTOXICATION - can be made permanent if assigned with timing 9 and its effects don't seem to be present until you reach 50 points (as mentioned I need smaller range). On top of that can be easily checked and edited with CheckStat and ChangeStat in order to reset the value when player drinks booze. The effect can be simulated with ApplySepllRes and I don't think any mod uses this stat yet, so I think this one is pretty safe bet for one of the 2 stats needed in my mod. 2. 43 XPVALUE - other than XP that the character gives when killed I don't think this stat is used for anything else when it comes to Player1-6. On the other hand it would be a bit jarring if player decides to kill party NPC and see for example "3 XP gained" message, so maybe it's not the best candidate. Although I will use it if there won't be a better proposal. 3. 134 EXTRAPROFICIENCY20 - unlike other entries this one doesn't use name introduced by Detectable Spells mod. Is it used for anything in vanilla game? I'm pretty sure some mods may use it but if it's not related to commonly used Detectable Spells than conflicting with such mods is acceptable. 4. Moving one of the Detectable Spell entries into splstate.ids. Which of those DS stats requires check that is simple True/False and don't need value increasement, though? Maybe one of them is obsolete in EE engine? Any ideas?

just an update how IWD2 level and class rules will be implemented (if Bubb succedes with expanding the engine functionality): https://forums.beamdog.com/discussion/comment/1001653#Comment_1001653 Crazy ambitious plan but with the lua access it should be doable (I've worked with lua before) The idea for this system came during Feat spells conversion – since thier bonuses are implemented for creatures, why not add Feats as an option for player as well? This system hopefully will satisfy those who prefer 3rd edition rules introduced in IWD2.

Bolded part is not true anymore. Tested with Range 100 - works fine. And unlike See and LOS, Range actually ignores all obstacles (walls etc.).

The cap is not present in EE patch 2.5. Tested with See() trigger and visual range set to 100 with this opcode.

From what I understand it looks like Kulyok is interested in updating mods if someone sends her files, not necessarily giving permission to host them externally (not sure though). Dungeon Crawl being BG2 mod makes it easy to add native support for EET (probably just a chapter number evaluation), so having it in the official package would be preferable. I remember sending her update files with native EET support for all of her mods, but for some reason none of them have been internalized edit: huh, missed this part. That would explain why some of her mods landed on BWS Github. So yeah, I think the BWS fork may be fine, unless there is confirmation that author is against it. I've reverted the github commit that removed the link for now. Either way I think it would be better approach to have all platforms supported in one place rather than hosting forks, if she is still willing to update the official package if someone sends her files (no confusion, no situations when one version receives a bugfix but not another).

Seems to be working as expected. Tested with code attached to Imoen: IF Global("doOnce","LOCALS",0) THEN RESPONSE #100 JumpToPoint([2344.873]) SetGlobal("doOnce","LOCALS",1) END IF See(Player1) THEN RESPONSE #100 DisplayStringHead(Player1,1) // No, I'm sorry, none of them sound familiar. Continue() END IF NearLocation(Player1,2344,873,40) THEN RESPONSE #100 DisplayStringHead(Player1,2) // You played Elminster? END the message shows up a bit further than visual range: https://i.imgur.com/kTiQu6Y.jpg Here is where visual range kicked-in: https://i.imgur.com/qAWp3GD.jpg Increasing the range value also increases NearLocation range far beyond the visual range (for example NearLocation(Player1,5000,5000,521) covered whole area that I was in).

thanks!

just to be sure that I understand this correctly - the range in the example I've shown would be 8 (8.333 rounded down), is that right? (radius calculated like in the above mentioned formula but using rectangle length divided by 16 and rectangle height divided by 12) edit:

one more question. Let's say I want to limit the range in similar way to those rectangles using NearLocation(O:Object*,I:PointX*,I:PointY*,I:Range*) trigger. Does anyone know how Range refers to area pixels? Let's say I'd like to convert this rectangle into NearLocation check: Exists(Player1[110.520.190.600]) The middle of it can be calculated via: PointX = x1+(0.5*(x2-x1)) PointY = y1+(0.5*(y2-y1)) So we end up with: NearLocation(Player1,150,560,I:Range*) What would be the correct range value here? I don't think Range matches pixels 1:1, so calculation like this is likely not correct: edit: of course I'm talking about encircled rectangle:

thanks. Too bad that this feature doesn't exist in EE engine.

argent77, thanks, I forgot to change the weidu reference for macOS and Linux in EET_end.tp2. To be more precise this line refers to not existing weidu file: AT_NOW ~./EET/weidu_%WEIDU_OS% --noautoupdate --no-auto-tp2 --traify-tlk --min %str_min% --out "%USER_DIRECTORY%/save/saves.tra"~ The problem affects only saves.tra exportation (used by the optional save updating feature). Will fix it soon. edit: hmm, works on windows, I'm always installing like this: setup-EET.exe --force-install 0 --skip-at-view --language 0 --args-list p "D:/Games/00806" not sure what makes it different on linux. Maybe this code that alters the user typed path have something to do with it? OUTER_PATCH_SAVE bgee_dir ~%bgee_dir%~ BEGIN PATCH_IF ~%WEIDU_OS%~ STR_EQ ~win32~ BEGIN //Win32 REPLACE_TEXTUALLY ~[*?"<>|]~ ~~ //invalid characters in a path REPLACE_TEXTUALLY ~\~ ~/~ //change slashes REPLACE_TEXTUALLY ~[\\/]*$~ ~~ //remove terminal slashes END ELSE BEGIN //osx, unix REPLACE_TEXTUALLY ~\\~ ~~ //remove quotes REPLACE_TEXTUALLY ~^"\(.*\)"$~ ~\1~ //if the whole text is quoted, remove quotes REPLACE_TEXTUALLY ~/*$~ ~~ //remove terminal slashes END END edit: just to be sure, there is no way to get weidu path that is used for installation from within tp2 file, right? I don't see constant variable like that in weidu documentation.

In IWD2 objects/ids objects are often followed by another object type (?) consisting of 4 values. Examples: Exists(Player1[110.520.190.600]) See([0.0.LIZARDMAN][0.0.10000.10000],0) Dead([GOODCUTOFF][793.376.1093.676]) ChangeSpecifics([GOODCUTOFF.0.0.0.0.255][0.0.10000.10000],0) At first I thought those are just nested objects (even though no script in other games nests like this) but these values don't seem to have anything to do with IDS files. According to gemrb the normal ids object type in IWD2 should consist of following values: [EA.GENERAL.RACE.SUBRACE.SPECIFIC.GENDER.ALIGNMNT.CLASS.CLASS20.CLASSMSK]. Anyone knows what those bolded values are used for and what sets them?

nope. There was a mod for skipping SoD somewhere on this forum, but I can't find it anymore (too many posts, sorry).

thanks!

According to Near Infinity the unknown dword in SRC file format is Weight, from which I assume it's possible to adjust which string has higher chance to show up. I'd like to test it if this is the case and if SRC files are also supported by other EE games, but how exactly they are used in the first place? How to call the SRC file to display string in game?

Sorry to hear that it's hosted without permission. I've removed it from compatibility list. I think there was a small patch available for Dungeon Crawl at some point although I no longer have those files (it wouldn't work with updated version either way).

sure thing, AWizardDidIt Glad you're still interested.

Some more details regarding triggers that works in door scripts (tested on BG2:EE patch 2.5) 1. Clicked, Unlocked, OpenState - all works as expected. IESDP mentions that Clicked works only for trigger regions and Unlocked "Appears to be broken" which is not true. Worth mentioning that successful door bashing also triggers Unlocked. 2. Detected - works on trapped doors IESDP mentions that it works only for trap scripts which is a bit confusing when we can detect it from Door script as well. 3. SecretDoorDetected - works as described on IESDP 4. Opened, Closed - works only if door "Is Trapped = Yes" (only one time detection depending on the open state if "Reset Traps" flag is not set) Setting "Reset Traps" flag makes these triggers work all the time. If you don't set "Detectable trap" flag then there are no drawbacks in "trapping" the door in order to use these triggers. IESDP doesn't mention that these triggers are dependent on trap flags. 5. Disarmed - works on successful door trap disarming IESDP doesn't mention door scripts. -------------- Following triggers don't work with Door scripts (or at least I don't know how to use them correctly): Reset, TrapTriggered, Entered, IsOverMe, WalkedToTrigger