SPECIFIC.IDS

[subtledoctor]

What is this? What does it do? When I look at NPC .cre files they are all "Unknown (0)"... does that matter for anything?

[Gwendolyne]

In fact, there are a lot of "unknown values". I wrote a macro to read all of them, then fill the first empty slot when I need a new one. Here is the specific.ids file rewritten with all the values used by BG2:EE unmodded plus mine (starting from 19 BLACK_DRAGON).

specific.txt

Edited December 27, 2017 by Gwendolyne

[CamDawg]

Scripting-wise specifics are used to identify groups, e.g. stuff like InMyGroup, NearestMyGroupOfType.

[subtledoctor]

Scripting-wise specifics are used to identify groups, e.g. stuff like InMyGroup, NearestMyGroupOfType.

Is it used for PCs at all, or just for enemy AI? Would setting a party member to a custom value upset anything?

 

I wrote a macro to read all of them, then fill the first empty slot when I need a new one.

Care to share that macro?

 

EDIT - cancel that, I have one.

Edited December 27, 2017 by subtledoctor

[Ardanis]

Vanilla BG2 iirc used specifics for feuding Trademeet families.

SoD makes more extensive use of it, using universal generic AI script for most non-party members and relying on specifics to control their allegiance (e.g. crusaders and coalition) and who should respond to shouts in the camp. So that if someone is going to side with party or with monsters, all you have to do is to ChangeSpecifics() and the AI script will take care of the rest. See BDSHOUT.BCS for reference.

 

Would setting a party member to a custom value upset anything?

 

You probably won't break too much, or even anything at all, but you'll be following in Chimeric's footsteps basically. The field's purpose is really for InMyGroup() trigger.

Edited December 27, 2017 by Ardanis

[subtledoctor]

You probably won't break too much, or even anything at all, but you'll be following in Chimeric's footsteps basically. The field's purpose is really for InMyGroup() trigger.[/font][/color]

You cut me deeply, sir.

 

I'm tearing my hair out trying to figure out a way to re-do Refinements' Use Scrolls, and everything I've tried has caused side effects that range from minor-but-annoying to partially-disastrous. Even with all of the stuff in the 2.5 engine there doesn't seem to be a good way to do it. Splstate.ids, splprot.2da, opcodes 318/324/326 have created some nice new capabilities, but none of it works for usability. Opcode 319 is limited to to the traditional IDS targets of 177, notwithstanding my feature request to expand it. And putting using 319 in an .EFF doesn't work at all.

 

So my most recent idea is, change all thieves to some custom specific.ids value, and make scrolls unusable by that value. Then, if they take the Use Scrolls feat/HLA, knock them back to the original value (0). Now they can use scrolls.

 

I'm really running out of ideas for any other way to implement this.

 

EDIT - also, you can't use opcode 101 to protect against opcode 319. The 319 usability restriction seems to be some kind of hard-coded UI thing, rather than something that interacts normally with other effects.

Edited December 27, 2017 by subtledoctor

[Ardanis]

I think I also suggested this to Demi back then, but personally I see no reason why you can't just set minimal INT requirement for scrolls (9-18) and enable them to thieves without further restrictions. This even makes perfect sense because the maximum level of spells wizards can learn were exactly based on their INT, which was removed in BG2.

[subtledoctor]

Because then I lose a cool HLA.

 

EDIT - also, this is in part for Refinements and Use Scrolls is, like, what Refinements is known for. I thought (and, um, loudly claimed) that I could use the new EE engine to recreate Use Scrolls without adding hundreds of shadow kits... obviously I spoke too soon, but the point is, I can't in good conscience remove that from the mod...

 

Using opcode 319 would really be the ideal way to do it, the problem is in the filtering options being so limited.

Edited December 27, 2017 by subtledoctor

[Jarno Mikkola]

I think I also suggested this to Demi back then, but personally I see no reason why you can't just set minimal INT requirement for scrolls (9-18) and enable them to thieves without further restrictions. This even makes perfect sense because the maximum level of spells wizards can learn were exactly based on their INT, which was removed in BG2.

Try this one down the size:

BEGIN ~Spell scroll usage~ DESIGNATED 9

COPY_EXISTING_REGEXP ~.*\.itm$~ ~override~
READ_SHORT ~0x001c~ ~type~
READ_BYTE ~0x12a~ ~level~
PATCH_IF (SOURCE_SIZE > 0x140) BEGIN 						// protects against invalid files
PATCH_IF (type = 0x000b) BEGIN
WRITE_BYTE ~0x1e~ ~0b00000000~
WRITE_BYTE ~0x1f~ ~0b00000000~
WRITE_BYTE ~0x20~ ~0b00000000~
WRITE_BYTE ~0x21~ ~0b00000000~
PATCH_IF (level = 31) BEGIN
  WRITE_BYTE ~0x2a~ ~9~
END
PATCH_IF (level = 32) BEGIN
  WRITE_BYTE ~0x2a~ ~10~
END
PATCH_IF (level = 33) BEGIN
  WRITE_BYTE ~0x2a~ ~11~
END
PATCH_IF (level = 34) BEGIN
  WRITE_BYTE ~0x2a~ ~12~
END
PATCH_IF (level = 35) BEGIN
  WRITE_BYTE ~0x2a~ ~13~
END
PATCH_IF (level = 36) BEGIN
  WRITE_BYTE ~0x2a~ ~14~
END
PATCH_IF (level = 37) BEGIN
  WRITE_BYTE ~0x2a~ ~15~
END
PATCH_IF (level = 38) BEGIN
  WRITE_BYTE ~0x2a~ ~16~
END
PATCH_IF (level = 39) BEGIN
  WRITE_BYTE ~0x2a~ ~17~
END
END

It only works on standard mage scrolls... but that is at least something. It it could use BUT_ONLY... too.

And yes, that makes everyone able to use the scrolls with the req INT, not just thieves, well you can of course set it at codes lines 8-11.. or make a nand's etc into it.

Edited December 27, 2017 by Jarno Mikkola

[Avenger]

 

You probably won't break too much, or even anything at all, but you'll be following in Chimeric's footsteps basically. The field's purpose is really for InMyGroup() trigger.[/font][/color]

EDIT - also, you can't use opcode 101 to protect against opcode 319. The 319 usability restriction seems to be some kind of hard-coded UI thing, rather than something that interacts normally with other effects.

 

 

Look at 319's as additional usability flags. They are more like part of the item struct than real effects. These 'effects' don't even have a useful ApplyEffect method, and they are stored in a separate place when the item is loaded. They are just a hack to avoid changing the itm format. All of the EE changes kept header sizes intact, just to keep a semblance of backward compatibility

 

Edit: if you want to make thieves unable to use scrolls, why not use opcode 181 with param2=1, param1 = 11 (this should work in EE).

Edited December 28, 2017 by Avenger

[subtledoctor]

if you want to make thieves unable to use scrolls, why not use opcode 181 with param2=1, param1 = 11 (this should work in EE).

That's what I started with... about 12 iterations ago. It creates problems... I honestly don't remember all the problems I hit along the way but one was, to do this right you need to apply it to cleric/thieves as well, because dual-classing (which at this point is fully the bane of my existence). But then cleric/thieves can't use divine scrolls, and regular thieves can't use green scrolls that any dumb fighter can use. So you need to separate those out some way... if you're using opcode 181, that means changing their item type. To what? I went through potions, miscellaneous, food (!), wands... in each case there were unintended and problematic side-effects.

 

Yadda yadda, I tried an alternative: find every scroll that should be affected by this, and use opcode 180 to prohibit using them until such time as the feat or HLA cancels the 180 spell. Very nice, very fine-grained control over usability... but two fairly major drawbacks: 1) there is no visual indicator of unusability associated with opcode 180, for what reason I don't know; and 2) a spell with several hundred 180 effects in every thief kit's clab table brings SCS to its knees, extending its install time from hours to days.

 

The third way is to use opcode 319. This would be ideal: powerfully fine-grained control over what is usable, nice visual feedback, easy to apply, and doesn't slow anything down. The only problem is, as stated, the lack of a good way to filter to effect so that it can be applied to characters subject to a marker than can be removed. Like spellstates! Except, there's no way to link a spellstate to usability. Specific.ids seems like the one least likely to break things. (This Use Scrolls thing will only ever be used by party members, not the AI, so we can safely consider things from a party-centric perspective.) I suppose something like gender would be fairly harmless as well, but that would probably show up on the character sheet. (And apparently, among the cohort of BG players, gender-bending can cause a major freak-out )

 

I suppose you could do something with general.ids, changing thieves to from humanoid to boots or general_item or whatever, and clone every hold person/charm person/etc. effect in spells and items...