Patching to correct Container in an Area?

[jastey]

I use this code to put a letter into Mulahey's chest:

COPY_EXISTING ~%NashkelMines_MulaheysCave%.are~ ~override~
  LAUNCH_PATCH_FUNCTION  ~fj_are_structure~
    INT_VAR
    fj_con_itm_idx    = SHORT_AT 0x74 - 1 
    fj_flags          = 1 // identified
    STR_VAR
    fj_name           = c#q13le1
    fj_structure_type = itm
  END
BUT_ONLY

Problem: if another mod adds a container before my mod is installed, the letter no longer goes into Mulahey's chest but into the inventory of the dead dwarf (added by Ascalon's Questpack, as an example).

I am sure WeiDU was developped further and there is a way to actually patch the container I want by its name so I do not need to post hex numbers and count backwards blindly to reach it? If anyone knows how to do that I'd appreciate the help.

[Angel]

Just use the absolute container number.  New containers are added to the end of the list, not inserted somewhere in the middle, so the numbers for containers existing in the core game never change.

[jastey]

Would you have an example code for me?

[argent77]

I wrote a small function once that returns the container index based on the container name: https://github.com/Argent77/A7-GolemConstruction/blob/master/A7-GolemConstruction/lib/functions.tph#L860

Maybe it helps in your case, too.

Another option could be adding the item by (area) script:

ActionOverride("Container 1",CreateItem("c#q13le1",1,0,0))

 

[Angel]

4 hours ago, jastey said:

Would you have an example code for me?

This is from the UB Restored Items component, adding Shazellim +1 to Prebek's home:

COPY_EXISTING ar0407.are override
   LAUNCH_PATCH_FUNCTION ADD_AREA_ITEM
     INT_VAR
     container_to_add_to     = 2
     STR_VAR
     item_to_add             = "sw1h50"
   END
   BUT_ONLY

Note that ADD_AREA_ITEM is fully documented in the WeiDU manual.

[temnix]

I have a related problem: patching triggers. Just like containers, they have no fixed offset. Actors come before them, so their position in AREs shifts all the time. But even worse than containers, they can't be patched by their number, only by their particular name, and I'm looking for a way to patch all of them in all areas - assign a script to them, specifically. Actually, extend that script, if there is one, which is a separate problem. Anybody has suggestions?

[DavidW]

If you want to patch all of them, detecting them isn't a problem. Just do GET_OFFSET_ARRAY and then loop through with PHP_EACH, as demonstrated in the WEIDU tutorial (except that the offsets for triggers are prelisted - ARE_V10_REGIONS - and so you don't need to enter them manually).

[jastey]

@Angel @argent77 Thank you for your answers!

[temnix]

5 hours ago, DavidW said:

If you want to patch all of them, detecting them isn't a problem. Just do GET_OFFSET_ARRAY and then loop through with PHP_EACH, as demonstrated in the WEIDU tutorial (except that the offsets for triggers are prelisted - ARE_V10_REGIONS - and so you don't need to enter them manually).

Okay, I'm not going to go ahead with implementing, but I will leave the idea up for grabs: I thought of patching all triggers of the Travel type with a script; here there is another problem, that they may already have a script, some way of extending to it instead would have to be devised; assuming that can be managed, this script addition would make the trigger start shouting when a global was set or when it, the trigger, itself heard a shout. It'd be better to allow both. This way from the area script the global could be set or from within a conversation a shout sent, followed by SmallWait(3) ActionOverride(Player1,MoveToObject(LastHeardBy)) ActionOverride(Player1,LeaveAreaLUA("AR1234","",[X.Y],Z). The number shouted by the triggers in response doesn't matter, the point is simply to get party members to tune in to the shouter (a short interval is required for party members to process the shout). The same commands would be given to the rest of the party after Player1, making them walk towards the trigger first and only then disappear into another area, because this is how commands given after MoveToObject are followed - they are delayed until arrival. This I know.

The problem that I wanted to circumvent this way is that triggers can't be represented by objects in scripts, so it's impossible to tell a character to go to the nearest trigger, especially if it must be a travel trigger and not, say, a trap or an info box. Even Doors aren't present in every area: NearestDoor may fail even when there is, in fact, a door object in the area. This system would have to be universal to be really useful, covering all games and mods, so going by the names of the triggers themselves, "Door4845" and so on, is not an option. Triggers need to shout to be noticed or, if regions can't shout, which is also possible, their scripts need to spawn, OnCreation(), invisible minions to serve as objects the party can approach. This is not such a complicated system, and if all travel triggers could be patched one way or the other, it would be possible to send characters to areas of choice in a natural way, by walking towards entrances, easily. But it's complicated to write the code for. I'm going to leave it to those who want to sit down at Weidu.

And jastey, I didn't mean to hijack the thread. I thought this was a good place to ask. I'm done here.