K4thos

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:

How about 187/195 or the two stats holding titles (class strings)?

*runs screaming for the hills*

 

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.

good point, completely forgot about it.

(...)

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.

//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

XPVALUE is a good find if that's true, but... is there an opcode that can change it?

Various mods of mine use different bits of stat 134; the still-in-progress psionics mod uses some of 134 and all of 132.

will skip this one in this case

Kjeron mentioned an example once of a stat whose checks in the vanilla game were moved entirely to a spellstate, as of patch 2.0. But I forget which stat it is. It's in some thread around here... maybe that thread started by you about a year ago? Also there may be more stats freed up in the latest patch.

thanks, will check my old topic.

There are also the arcane and divine spell failure stats, which can be 0-100 and can be set/changed by opcodes... these could be useful for classes with no access to one or the other kind of spellcasting...

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).

There is Tracking, which can go from 0-99 and has an opcode that can set/increment/decrement it.

 

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

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

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

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!

'Radius' most likely scales to search units, which roughly translates to 16 pixels horizontally and 12 pixels vertically per unit.

 

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?

Exists(Player1[110.520.190.600])

PointX = x1+(0.5*(x2-x1))
PointY = y1+(0.5*(y2-y1))

NearLocation(Player1,150,560,I:Range*)

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:

Another issue is probably WeiDU-specific, but I have to test it further to be certain. You cannot specify an absolute path to the BGEE+SoD installation. Using relative paths works though.

setup-EET.exe --force-install 0 --skip-at-view --language 0 --args-list p "D:/Games/00806"

            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.

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?

That's what you get when you make unapproved and unauthorized pseudo update versions: chaos reigns and players get confused (and original mod authors are annoyed or more, btw.)

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).

Version 3.3 of Quest Pack, which, among other things, adds EET compatibility is officially on PPG now!

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