Jump to content

creating a modified "Identify" spell


Recommended Posts

11 minutes ago, Lauriel said:

This is one of the coolest things I've ever seen.  "It's a thing of beauty, boss!"  (sorry, couldn't resist the Buffy reference - yes, I'm a nerd)  I wish I knew what to do with that TPH file but I'm such a newb at this, even that throws me.  So I'm with @Grammarsalad, please talk to me as if I were 5, please.  Maybe make that 3....

Near as I can tell, it can pretty much be dropped into a mod and it will work.  I haven't really tested yet, but I will and I will release it as a proper mod in the near/mid term, because as I said, this is the only way a number of my existing kit mods could use the Identify spell.  It will need a slight bit of finessing - like, a relatively simple check to allow it to be installed multiple times from multiple mods without duplicating the result.  But, as soon as we figure out a home for it (maybe in @Aquadrizzt's mod) and ensure we have @Bubb's permission, I'll finalize it.

Actually Bubb, I wonder if it would make sense for something like this to be uploaded as a modder's resource, rather than an actual mod?  Something like Aquadrizzt's multiclass kit installation function, or my Spell Evasion function or armored casting system?  Wrap it in enough Weidu that anyone can easily drop it into their mod with little or no effort, and installation from multiple sources won't interfere with each other?  I'd be happy to fill out the required Weidu code and host it on our GitHub account.

Link to comment
6 minutes ago, subtledoctor said:

Actually Bubb, I wonder if it would make sense for something like this to be uploaded as a modder's resource, rather than an actual mod?  Something like Aquadrizzt's multiclass kit installation function, or my Spell Evasion function or armored casting system?  Wrap it in enough Weidu that anyone can easily drop it into their mod with little or no effort, and installation from multiple sources won't interfere with each other?  I'd be happy to fill out the required Weidu code and host it on our GitHub account.

Yes please!

Link to comment

Subtledoctor has given me a clue--lol, it pays to look and think--so that's something to start with.   


Actually, @subtledoctor if you don't mind, I wouldn't mind trying to dissect the code here to see if I can figure it out in a public forum (where people can point out my dumb errors and/or make use of any 'breakthroughs' )  

 

Edit: Responding to this:

 

Quote

This is one of the coolest things I've ever seen.  "It's a thing of beauty, boss!"  (sorry, couldn't resist the Buffy reference - yes, I'm a nerd)  I wish I knew what to do with that TPH file but I'm such a newb at this, even that throws me.  So I'm with @Grammarsalad, please talk to me as if I were 5, please.  Maybe make that 3....

 

Edit2:  I'll upload a quick and dirty example tomorrow if SD doesn't get to it first 

Edited by Grammarsalad
Link to comment

Sure!  I was offering the use of our shared GitHub account anyway :p  As long as Bubb is okay with it, of course, go to town.  I'll note what I was thinking of, meanwhile.

As I said, I think it's already more or less ready to go with the .tph file and his example code.  Feed the function a filename and it should modify a spell to work as shown in the video.  My suggestion for avoiding duplication would be to either 1) add a marker file and wrap the necessary parts of the code in a function that won't run if the marker is already present; or 2) actually create a .2da file listing the RESREF or IDS name of each spell used with the function.  This way if the function was already used on a spell (like WIZARD_IDENTIFY) it could gracefully decline to run again and move on to the rest of a mod's installation; but if the spell is not already in the 2da list the function would run and then append the spell to the list for future reference.

My suggestion for actual implementation in a mod would be to run the function a few times to make custom subspells with 1/2/3 identification 'uses;' and then add a new version of Identify with several headers to cast each subspell at an appropriate level.  (It should be different from SPWI110, because we would want to actually remove the old inventory-screen method from the player; so SPWI110 should be added to HIDESPL.2da and SCRL75.itm would be altered to point to the new "Identify" spell.)

Edited by subtledoctor
Link to comment
1 hour ago, subtledoctor said:

Sure!  I was offering the use of our shared GitHub account anyway :p  As long as Bubb is okay with it, of course, go to town.  I'll note what I was thinking of, meanwhile.

As I said, I think it's already more or less ready to go with the .tph file and his example code.  Feed the function a filename and it should modify a spell to work as shown in the video.  My suggestion for avoiding duplication would be to either 1) add a marker file and wrap the necessary parts of the code in a function that won't run if the marker is already present; or 2) actually create a .2da file listing the RESREF or IDS name of each spell used with the function.  This way if the function was already used on a spell (like WIZARD_IDENTIFY) it could gracefully decline to run again and move on to the rest of a mod's installation; but if the spell is not already in the 2da list the function would run and then append the spell to the list for future reference....

 

Yeah, it's easy peasy 123sy with the provided .tph.  I did it in about ~5 mins on one of my comps (not sure which one atm).  

It might work fine to run it over and over again in different mods.  It's worth testing. (lol, I've borked my menu so many times with no long term repercussions).  Also, if necessary, we could tweak the tph to deal with multiple iterations if necessary (once we've figured out a few basics re what it actually does).  

Quote

My suggestion for actual implementation in a mod would be to run the function a few times to make custom subspells with 1/2/3 identification 'uses;' and then add a new version of Identify with several headers to cast each subspell at an appropriate level.  (It should be different from SPWI110, because we would want to actually remove the old inventory-screen method from the player; so SPWI110 should be added to HIDESPL.2da and SCRL75.itm would be altered to point to the new "Identify" spell.)

Agreed.  Or, maaaybe SPWI110 could just be modified to cast the subspells(?)  Not sure if it'll work.  I used a modified detect evil spell.  I tried to modify SPWI110 and it didn't work.  But, I didn't change the headers, targets etc., and moved on to detect evil.  I just wanted to create a proof of concept.  

Edit: Nope.  It doesn't work if you replace SPWI110 with an otherwise working version. You have to use a different res.  So, yes to adding SPWI110 to HIDESPL.2da.

My thinking was also to investigate what else we can do; what other menus can be accessed (hla menu, proficiency menu, etc.)

Edited by Grammarsalad
Link to comment

Okay, I have two Identify related findings:

1) This does not work with SPWI110.spl.  The original identify needs to be added to hidespl.2da and a new spell needs to be added.

2) the functions seems to work fine when run in two different mods on the same install.  That is, I made a wiz version in one mod and installed it (over grease).  Then, I made a cleric version in a second mod, and installed that (over detect evil).  Both work just fine in BG2EE.  I created a cleric/mage with the wiz and cleric version memorized.  She cast both, and they both worked.  The two quick and dirties are attached.  

B_Identify.zip

Edited by Grammarsalad
weird upload
Link to comment
6 hours ago, subtledoctor said:

Actually Bubb, I wonder if it would make sense for something like this to be uploaded as a modder's resource, rather than an actual mod?  Something like Aquadrizzt's multiclass kit installation function, or my Spell Evasion function or armored casting system?  Wrap it in enough Weidu that anyone can easily drop it into their mod with little or no effort, and installation from multiple sources won't interfere with each other?  I'd be happy to fill out the required Weidu code and host it on our GitHub account.

It's mostly set up that way, as far as I can tell. No components involved, just three functions that can be called after it is INCLUDE'd. It also already uses marker files for the two UI-patching functions, so it should be safe to throw into any mod and call B3_IDENTIFY_INSTALL.

I have verified that the UI patching plays nice with EET; however, there was a bug in that previous tph which made opening the spell book impossible after casting the spell, (oops!). It's fixed in this one:

B3Identify.tph

 

You guys can totally use, modify, and host this however you want - that's why I made it! To be clear, this is briefly how it is organized:

1) B3_CONTINGENCY_REDIRECT_INSTALL is a helper function that installs the code necessary to redirect the contingency menu. This is automatically called by B3_IDENTIFY_INSTALL, you don't need to touch this.

2) B3_IDENTIFY_INSTALL installs the new identify menu / the code necessary to register a spell to use the menu. Both this function and the previous use marker files, preventing multiple calls to these functions from installing them more than once.

3) B3_IDENTIFY_REGISTER appends:

B3Identify_RegisterResref("%resref%", %uses%)

to M_B3IDEN.lua, the main file which controls the new Identify system. Note that if you can maintain your own M_*.lua file, appending the aforementioned line manually, that would be preferred, (rather than potentially having several mods altering the same vital file). This function does *not* make the resref completely ready - the spell still needs an Opcode #234 in order to be detected.

 

On 1/21/2020 at 9:31 PM, Grammarsalad said:

So, when you talk about this 'pattern matching'.  What sort of thing should we look for? 

As subtledoctor says, it uses REPLACE_MULTILINE, (I believe made by K4thos), to patch certain parts of UI.MENU. In particular, if a UI mod alters the wrong place in either the mage book, contingency screen, or inventory screen, it might conflict. It's possible to provide different patching cases to support specific UI mods, should it be requested.

5 hours ago, Grammarsalad said:

My thinking was also to investigate what else we can do; what other menus can be accessed (hla menu, proficiency menu, etc.)

Any menu can be opened, the question is whether it is functional without it being invoked engine-side. What sort of things would you want to do with the HLA menu, for instance?

Edited by Bubb
Link to comment
5 hours ago, Bubb said:

...

Any menu can be opened, the question is whether it is functional without it being invoked engine-side. What sort of things would you want to do with the HLA menu, for instance?

 

I just deleted a few paragraphs of blah blah blah. lol.  Like, I was thinking of possible ways to bypass the limitation of not being able to select HLAs at character creation.  Basically, I'm just interested in finding out what sorts of things can be done.  Once I know that, the ideas will come.  Like, is the class button array considered a menu that you could access with this?  That's probably too good to be true.  Well, I also just get excited at the possibility of doing new things. 

Edited by Grammarsalad
strange white box over text?
Link to comment

Still playing with the modified identify spell.

I was able to access Imoen's (and then Minsc's) inventory.  When I tried casting on Jaheria, who had not yet joined my party, it showed Imoen's inventory instead.   Non-allies should be protected from the spell.  Anyway, very cool!  

Also, I see how to restrict it to certain inventory slots.  As such, you could give warriors an ability to identify a weapon (and/or armor/helmets) if they can swing it around it for a bit (i.e. if they hold it in one of their weapon slots).  This, of course, makes them vulnerable to cursed items, but still, pretty cool and useful.  I'm going to totally add this to a kit/class revision I'm working on.  They're even going to do a little attack animation when the ability is activated.  Good fun!

Edit: just comment out or delete all slots that you don't want them to access, e.g.:

--    button {area 26 347 52 52  bam "STONSLOT" slotinfo "characters[id].equipment.personal0" action "B3Identify_IdentifySlot(characters[id].equipment.personal0)"}

Basically, the only thing I know about lua is that "--" comments out a line

I see how to create my own M_* file. 

Just replace all instances of "M_B3IDEN" with the alternate name.  

lol, brain getting tired

 

Edited by Grammarsalad
Link to comment
On 1/19/2020 at 8:29 PM, Bubb said:

B3_IDENTIFY_INSTALL performs the necessary UI patches - make sure to run this before subsequent tasks.

...

This is the small test tp2 I was using to install, as an example:


INCLUDE ~bubb_test/B3Identify.tph~
LAF B3_IDENTIFY_INSTALL END

COPY ~bubb_test\copy\B3IDEN.SPL~ ~override~
    SAY 0x8 ~Bubb Test Identify~
BUT_ONLY

LAF B3_IDENTIFY_REGISTER INT_VAR uses = 4 STR_VAR resref = ~B3IDEN~ END

Edit: The above should work for vanilla BG:EE, BG2:EE, and IWD:EE. UI Overhauls will probably break the pattern matching.

So @Bubb if you're around: what did that "B3Iden.spl" spell look like before the B3_Identify_Register function ran on it?  Is it just an empty spell with a header and no effects?  Is it a contingency spell?  Does it matter?

@Grammarsalad if you've replicated this already maybe you know the answer.

Link to comment

It contained a single spell header with an Opcode #234 effect; Opcode parameters don't matter, timing mode / duration doesn't matter.

The only requirements are: 1) The spell resref is registered, and 2) It fires an Opcode #234.

Edited by Bubb
Link to comment

This mechanic is completely vanilla - unless there was a Lua error in a vital engine call the game shouldn't crash. I can't get it to crash in BG:EE 2.5.17.0, so, uh, weird. Could you please upload the SPL file in question, and perhaps the .dmp it generated from the crash?

Edit: Actually, if you don't use B3Identify_RegisterResref("<resref>", useCount) in either a M_*.lua file or by calling B3_IDENTIFY_REGISTER the game would crash. Just to verify, you are doing this, right?

Edited by Bubb
Link to comment
44 minutes ago, Bubb said:

This mechanic is completely vanilla - unless there was a Lua error in a vital engine call the game shouldn't crash. I can't get it to crash in BG:EE 2.5.17.0, so, uh, weird. Could you please upload the SPL file in question, and perhaps the .dmp it generated from the crash?

Edit: Actually, if you don't use B3Identify_RegisterResref("<resref>", useCount) in either a M_*.lua file or by calling B3_IDENTIFY_REGISTER the game would crash. Just to verify, you are doing this, right?

I'm attaching the offending .SPL.

The code looks like:

INCLUDE ~will_to_power/lib/b3identify.tph~
LAF B3_IDENTIFY_INSTALL END

COPY ~will_to_power/data/d5ps501.bam~ ~override~
COPY ~will_to_power/data/d5ps501.spl~ ~override~   //                 object reading
    SAY NAME1 @5011
    SAY UNIDENTIFIED_DESC @5012
    WRITE_LONG 0x34 5
    WRITE_ASCII 0x3a ~d5ps501~ #8
    LPF ALTER_SPELL_HEADER INT_VAR target = 5 speed = 1 location = 2 STR_VAR icon = ~d5ps501~ END

LAF B3_IDENTIFY_REGISTER INT_VAR uses = 1 STR_VAR resref = ~d5ps501~ END

That version only has a single 234 effect and still crashes, so it's not the accompanying effects that cause it.  Most likely just something I'm doing wrong.  :rolleyes:

EDIT - attached now.

d5ps501.spl.zip

Edited by subtledoctor
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...