WeiDU question - scope from READ_2DA_ENTRIES_NOW

[jmerry]

What's the scope of the array and variable created by a READ_2DA_ENTRIES_NOW command? If I use it, can I then put that 2DA away, open something else, and look at the data within to use in patching the new file? The WeiDU documentation isn't very clear on this but kind of implies that the array at least has a global scope. My cursory searches haven't spotted any uses like this; it seems that everybody (including the example in the documentation) uses them as if they're local.

Use case: I'm looking back at a quick mod I put together (tweaking Hexxat to a fighter/thief or shadowdancer) and trying to streamline the coding by externalizing the changed data to a 2DA file. I want to read that file, put it away with no changes, and use the data (levels, thief skills, etc) to patch the creature files.

[guyudennis]

Shouldn't INNER_ACTION achieve what you want to do?

Or, put the read (levels, skills , etc) into variables, which can surely be accessed later:

COPY_EXISTING ~mxsplran.2da~ ~override~ // ranger spell table
  COUNT_2DA_COLS cols
  READ_2DA_ENTRIES_NOW rows cols
  FOR (col = 1; col < cols; ++col) BEGIN // loop through each spell level
    FOR (row = 0; row < rows; ++row) BEGIN // loop through each class level
      READ_2DA_ENTRY_FORMER rows row 0 rng_lv_start // current class level
      READ_2DA_ENTRY_FORMER rows row col rng_lv_spell // max spells available for the combination of current class level and current spell level
      PATCH_IF (rng_lv_spell = 1) BEGIN // stop at the very 1st time spells for each spell level become available
        SET ~rng_lv%col%_start~ = rng_lv_start // set corresponding starting class level variables for each spell level
        SET row = rows // break loop
      END
    END
  END
  INNER_ACTION BEGIN
    ACTION_FOR_EACH ranger_clab IN ~clabrn01~ ~clabrn04~ BEGIN // true ranger, beastmaster
      COPY_EXISTING ~%ranger_clab%.2da~ ~override~
        LPF set_clab_2da_entries INT_VAR f_MinLevel = rng_lv1_start f_MaxLevel = rng_lv1_start STR_VAR f_Entry = ~GA_SPRA101~ END // blades of fire
        LPF set_clab_2da_entries INT_VAR f_MinLevel = rng_lv1_start f_MaxLevel = rng_lv1_start STR_VAR f_Entry = ~GA_SPRA102~ END // longstrider
        LPF set_clab_2da_entries INT_VAR f_MinLevel = rng_lv2_start f_MaxLevel = rng_lv2_start STR_VAR f_Entry = ~GA_SPRA201~ END // snare
        LPF set_clab_2da_entries INT_VAR f_MinLevel = rng_lv2_start f_MaxLevel = rng_lv2_start STR_VAR f_Entry = ~GA_SPRA202~ END // swift haste
        PRETTY_PRINT_2DA
      BUT_ONLY
    END
    COPY_EXISTING ~clabrn03.2da~ ~override~ // stalker
      LPF set_clab_2da_entries INT_VAR f_MinLevel = rng_lv1_start f_MaxLevel = rng_lv1_start STR_VAR f_Entry = ~GA_SPRA102~ END // longstrider
      LPF set_clab_2da_entries INT_VAR f_MinLevel = rng_lv2_start f_MaxLevel = rng_lv2_start STR_VAR f_Entry = ~GA_SPRA202~ END // swift haste
      PRETTY_PRINT_2DA
    BUT_ONLY
    ACTION_FOR_EACH priest_clab IN ~clabpr01~ ~clabpr02~ ~clabpr03~ ~clabpr04~ ~ohtyr~ ~ohtempus~ ~clabdr01~ ~clabdr02~ ~clabdr03~ ~clabdr04~ BEGIN // all cleric and druidic classes and kits
      COPY_EXISTING ~%priest_clab%.2da~ ~override~
        LPF set_clab_2da_entries INT_VAR f_MinLevel = 1 f_MaxLevel = 1 STR_VAR f_Entry = ~AP_DVRNCSN~ END // priest caster level anti-boost
        PRETTY_PRINT_2DA
      BUT_ONLY IF_EXISTS
    END
  END
BUT_ONLY

... few hundred lines later in the TPA, I accessed some of the variables (rng_lv1_start) again...

COPY_EXISTING ~dvrncs.spl~ ~override~ // ranger caster level boost
  // add spell extended effects: lv1
  PATCH_IF (ranger_caster_level_full = 1) BEGIN
    SET rng_cst_lv_boost = 7 // set ranger caster level to full class level, with ranger caster level hardcoded as class level minus 7 since spell-casting is originally available at lv8
  END ELSE BEGIN
    SET rng_cst_lv_boost = (7 - (rng_lv1_start - 1)) // set ranger caster level to class level minus (rng_lv1_start - 1), mimicking the original behavior but at the same time fully responsive to spell table alterations
  END
  LPF ADD_SPELL_EFFECT INT_VAR opcode = 191 target = 2 timing = 9 parameter1 = rng_cst_lv_boost parameter2 = 1 END // caster level bonus
BUT_ONLY

 

[jmerry]

Yes, INNER_ACTION would do what I need. In fact, I've already written that version; here's the code for the smaller component using that:

COPY ~jtweaks/resource/j8hhexsd.2da~ ~override~ // Table of data for changes
	READ_2DA_ENTRIES_NOW sd 8
	INNER_ACTION BEGIN
		FOR (n = 0; n < sd; ++n) BEGIN
			READ_2DA_ENTRY_FORMER sd n 0 FileID
			READ_2DA_ENTRY_FORMER sd n 1 Level1
			READ_2DA_ENTRY_FORMER sd n 2 Hide
			READ_2DA_ENTRY_FORMER sd n 3 DetIll
			READ_2DA_ENTRY_FORMER sd n 4 Unlock
			READ_2DA_ENTRY_FORMER sd n 5 Silent
			READ_2DA_ENTRY_FORMER sd n 6 DetTrap
			READ_2DA_ENTRY_FORMER sd n 7 Pocket
			COPY_EXISTING ~%FileID%.cre~ ~override~
				WRITE_BYTE 0x273 4 // Class - thief
				WRITE_LONG 0x244 0x40210000 // Kit - shadowdancer
				WRITE_BYTE 0x234 Level1
				WRITE_BYTE 0x45 Hide
				WRITE_BYTE 0x64 DetIll
				WRITE_BYTE 0x65 0 // Set Traps
				WRITE_BYTE 0x67 Unlock
				WRITE_BYTE 0x68 Silent
				WRITE_BYTE 0x69 DetTrap
				WRITE_BYTE 0x6a Pocket
			BUT_ONLY // Done editing this cre
		END // End for loop
	END // End inner action
BUT_ONLY // Close the 2DA read, don't keep the override copy

And the 2DA I'm drawing the data from:

2DA	v1.0
*
	Level1	Hide	DetIll	Unlock	Silent	DetTrap	Pocket
ohhex8	8	40	20	50	30	60	15
ohhex9	10	42	25	60	42	70	16
ohhex10	10	42	25	60	42	70	16
ohhex11	11	47	30	60	47	70	21
ohhex13	13	57	35	65	57	75	26
ohhex15	15	72	35	70	72	80	26
ohhex25	15	72	35	70	72	80	26

The thing about saving things in variables for later is that I'm using every entry. It made sense for your code example, parsing the table to find a few key data points and saving them for later use. In my case, the table is there as a store of data. I don't want to store about fifty variables for later, or three times that in the case of the larger component turning her into a fighter/thief multiclass. Storing large numbers of variables like that is what arrays are for, and I already have one of those. I want to just use it.

[subtledoctor]

40 minutes ago, jmerry said:

don't want to store about fifty variables for later,

ha ha, that's what I did 

43 minutes ago, jmerry said:

here's the code for the smaller component

That… shouldn’t work? Inside INNER_ACTION should need actions… FOR and READ_ are patches. 

Then again you can just switch the INNER_ACTION down to the COPY, it work fine. 

[jmerry]

It's untested code. I'm not surprised I made a mistake ... yeah, your suggestion looks right here. Cut and paste a row, delete some tabs, swap a pair of comments. Master copy corrected.

Edited October 29, 2022 by jmerry

[argent77]

There's no need for INNER_ACTIONs. Table data persists even beyond the COPY scope. Something like this is perfectly viable:

COPY ~jtweaks/resource/j8hhexsd.2da~ ~override~ // Table of data for changes
  READ_2DA_ENTRIES_NOW ~j8hhexsd~ 8
BUT_ONLY

// table data is still valid
OUTER_FOR (row = 0; row < j8hhexsd; ++row) BEGIN
  OUTER_SPRINT FileID $j8hhexsd(~%row%~ ~0~)
  COPY_EXISTING ~%FileID%.cre~ ~override~
    WRITE_BYTE 0x273 4 // Class - thief
    WRITE_LONG 0x244 0x40210000 // Kit - shadowdancer
    WRITE_BYTE 0x234 $j8hhexsd(~%row%~ ~1~) // Level1
    WRITE_BYTE 0x45 $j8hhexsd(~%row%~ ~2~)  // Hide
    WRITE_BYTE 0x64 $j8hhexsd(~%row%~ ~3~)  // DetIll
    WRITE_BYTE 0x65 0 // Set Traps
    WRITE_BYTE 0x67 $j8hhexsd(~%row%~ ~4~)  // Unlock
    WRITE_BYTE 0x68 $j8hhexsd(~%row%~ ~5~)  // Silent
    WRITE_BYTE 0x69 $j8hhexsd(~%row%~ ~6~)  // DetTrap
    WRITE_BYTE 0x6a $j8hhexsd(~%row%~ ~7~)  // Pocket
  BUT_ONLY
END

WeiDU loads 2DA data into a 2d-array which can be accessed just like any other array via $array_name(~row~ ~col~). Afaik, the only restrictions with these arrays are that they don't work correctly with PHP_EACH, and you can't return them from a WeiDU function via RET_ARRAY.

Edited October 29, 2022 by argent77

[subtledoctor]

This is  a  really interesting  question, and I  was just working through it  on my own when sadly Argent77 posted the very helpful  answer. 

And BOY would it have been useful to know that when I wrote this code!

[jmerry]

Thanks. I kind of thought so, and that does simplify things another level. Especially being able to use array syntax to skip the intermediate step of defining variables before my write commands.