164 replies to this topic

[Qwinn]

Ok, was pretty easy to do, so.

Oh, I was expecting that people would set the Q_Game variable actually within the file where the macros were saved, so it wouldn't have to be reset with every use (after all, most WeiDU mods only work for a single game, right? Though I suppose a function like this could be an exception.), but setting it like this would work too. I did need to move your SET deeper into the code, though, because the Process macro would run InitVars and reset all the variables, including Q_Game.

I got rid of the call to the delete macro as I didn't see it as necessary especially after most of the variable assignments are removed, that macro is incorporated directly into the COPY_EXISTING.

"LAUNCH_PATCH_FUNCTION ~Move_good_sounds_into_slots_less_than_sound_count_if_in_slot_greater_than_sound
_count~ //<-- you may not need and it may not work"

I can look at this and the LookupAndWipeout macros if you would like, but for the moment I'm not doing so as they're really not within the scope of what my macros are about. Just assuming they work.

COPY_EXISTING_REGEXP GLOB ~^\([^xX].*\|[xX][^rR].*\|[xX][rR][^2].*\|[xX][rR]2[^46].*\)\.are$~ ~override~
PATCH_IF SOURCE_SIZE > 0x11b BEGIN //If a valid area
  LAUNCH_PATCH_MACRO ~Q_ARE_InitVars~
  LAUNCH_PATCH_MACRO ~Q_AREAdd_InitVars~
  SET "Q_ManualInsert" = 1
  LAUNCH_PATCH_FUNCTION ~Lookup_Bad_Ambient_Sound_Refs_and_Wipe_out~
  LAUNCH_PATCH_FUNCTION ~Tidy_up_sound_entries_to_not_leave_empty_slots_between_good_slots~
  FOR (index=0;index<"Q_Num_Ambie";index+=1) BEGIN			  //loop through ambient entries
	SET amb_e = "Q_Siz_Ambie" * %index%								 //set index into ambient entries
	READ_SHORT ("Q_Off_Ambie" + %amb_e% + 0x80) s_num	  //Sound count
	PATCH_IF (%s_num% <=0) BEGIN										  //See if number of sounds is 0 or less
	  SET "Q_Game" = 2 //1 for PST engine; 2 for BG2 engine; 3 for IWD and BG engines
	  DELETE_BYTES ("Q_Off_Ambie" + %amb_e%) "Q_Siz_Ambie" //delete current entry
	  SET Q_NewAmbie = 0 - 1
	  LAUNCH_PATCH_MACRO ~Q_AREAdd_Process~
	  SET index = 0										 //set index back to 0 and loop through ambients again.
   END
 END
END
BUT_ONLY_IF_IT_CHANGES

EDIT: Didn't see your post. Sure, the library-of-writes sounds like a great idea.

Logically I didn't find any problems with what you were doing, so if you already sent it, should be fine. (Though, remember, I didn't look at the two functions, just talking about this part)

Qwinn

Edited by Qwinn, 02 June 2009 - 06:54 PM.

[Qwinn]

Just thought I'd add... if this is something you actually plan on running, I would first just run a function that reported which sounds were unused, and look at the filenames and make sure they weren't just slightly misspelled. You could thus fix the filenames as a bugfix/restoration. That happened in a few similar cases in PS:T (neck cracking sound, bell tolling in Mortuary, etc.). After that was done, -then- I'd run the purge.

Qwinn

Edited by Qwinn, 02 June 2009 - 09:31 PM.

[Miloch]

Just thought I'd add... if this is something you actually plan on running, I would first just run a function that reported which sounds were unused, and look at the filenames and make sure they weren't just slightly misspelled. You could thus fix the filenames as a bugfix/restoration. That happened in a few similar cases in PS:T (neck cracking sound, bell tolling in Mortuary, etc.). After that was done, -then- I'd run the purge.

Yeah, that was the whole point of this. I'd probably run it first in "report" mode like I did originally (just comment out the WRITE though), then hard code any misspellings, and also hard code the ones we want to purge. No real need to resort to regexp in a fixpack, since it's getting installed on an unmodded game.

We're working on more code that adds a new door to an area including the BAM that represents it, all vertices, regions and whatnot. I don't know if your macro can handle that too (the BAM placement, mainly - I'm guessing it can do the rest).

[Qwinn]

The rest, yes, but aren't area BAM's handled in the .TIS file or something?

Qwinn

[Miloch]

The rest, yes, but aren't area BAM's handled in the .TIS file or something?

It'd be an animation entry in the .are file, and a version of this code.

[Qwinn]

Aaaah. Sure, that's easy stuff. My macro can handle all the offset/insert stuff, while as always the actual write is up to you. You could basically use a call to my macro to eliminate about the first 90% of Nythrun's code there, and then just use a tweaked version of her writes. About 5 lines of code that call my macro handles everything up until the point where she does her INSERT_BYTES. And note that you could use the same 5-7 lines of code to do all the offsetting for the doors, regions, vertexes, etc, with one call to the macro, you don't have to do 5 lines per section of the area file. 5-7 lines total, for everything you want to add (not counting the actual writes, of course).

Qwinn

Edited by Qwinn, 03 June 2009 - 12:06 AM.

[Sasha Al'Therin]

Oh, I was expecting that people would set the Q_Game variable actually within the file where the macros were saved, so it wouldn't have to be reset with every use (after all, most WeiDU mods only work for a single game, right? Though I suppose a function like this could be an exception.), but setting it like this would work too. I did need to move your SET deeper into the code, though, because the Process macro would run InitVars and reset all the variables, including Q_Game.

If I'm going to use a macro, I usually expect the file being called to be all set and ready to go. Perhaps you aught to consider avoiding the user setting the value and just use:

PATCH_IF (GAME_IS ~PST~) BEGIN //only pst games
 SET Q_Game = 1
END
PATCH_IF (GAME_IS ~soa tob bgt tutu tutu_totsc~) BEGIN //all bg2 engine games
 SET Q_Game = 2
END
PATCH_IF !(GAME_IS ~PST soa tob bgt tutu tutu_totsc IWD2~) BEGIN //any other ie game but pst, bg2 variants and iwd2
 SET Q_Game = 3
END

I got the list of values from a quote by the bigg when he was working on updating the GAME_IS values, they should be accurate for the latest version...

I got rid of the call to the delete macro as I didn't see it as necessary especially after most of the variable assignments are removed, that macro is incorporated directly into the COPY_EXISTING.

Interesting move.. but I was actually considering changing the way it deletes to go backwards as it deletes so that it can do all for that area file in one pass and increment a variable that would then get carried back to the tp2 to be used in subtracting from zero to set Q_NewAmbie and then call the update macro from there. It would keep the macro from being called multiple times within the for loop. And perhaps reduce overall mod run time (which is almost as important to Miloch as keeping all variables to no more than two letters and any other code shortening techniques)... In fact, I'll have to redo the whole thing and use your variables in all the functions/macros because that would shorten code...

"LAUNCH_PATCH_FUNCTION ~Move_good_sounds_into_slots_less_than_sound_count_if_in_slot_greater_than_sound
_count~ //<-- you may not need and it may not work"

I can look at this and the LookupAndWipeout macros if you would like, but for the moment I'm not doing so as they're really not within the scope of what my macros are about. Just assuming they work.

I just assumed they would work too. You could look at the PFE (in the quoted one) and tell me if the idea would work. I can explain but if you look at it, it might make better sense as to what I was hopping to achieve. Basically, I used numbers inside the PFE so that s1 would be set to 0 1 2 etc... I then used s1 as part of an array to match a predefined variable. But I was hopping that since s1 even though it's supposed to be a string could act as an integer because it's value was a number. If it could be treated as an integer that would be great and allow for all kinds of things.

EDIT: Didn't see your post. Sure, the library-of-writes sounds like a great idea.

Link us! Link us! As far as I know, you're the only one who has officially used this so when you get the initial posts/pages up let us know so that the rest of us can start using and sharing amongst each other...

Logically I didn't find any problems with what you were doing, so if you already sent it, should be fine. (Though, remember, I didn't look at the two functions, just talking about this part)

It's nice to know that my logic can at least be followed. Of course, no one said it made any sense but it could at least be followed...

[Qwinn]

I got the list of values from a quote by the bigg when he was working on updating the GAME_IS values, they should be accurate for the latest version...

Excellent idea, and thank you for providing the code. Will update soonish.

Interesting move.. but I was actually considering changing the way it deletes to go backwards as it deletes so that it can do all for that area file in one pass and increment a variable that would then get carried back to the tp2 to be used in subtracting from zero to set Q_NewAmbie and then call the update macro from there. It would keep the macro from being called multiple times within the for loop.

This would indeed be more efficient. I would even go a bit further and see if you can't combine the Wipeout function and the Cleanup function so that even those are done in a single pass. I'll see if I can come up with a logic for doing that when my brain stops hurting... got a headache today.

And in light of that... can you tell me what PFE stands for? I could figure it out, I suspect, but as I said, bit brain fried.

Link us! Link us! As far as I know, you're the only one who has officially used this so when you get the initial posts/pages up let us know so that the rest of us can start using and sharing amongst each other...

Link where, how? Not sure what you mean. If you mean start up a thread with area write-maps, I can put in some of the default maps I had for actors from my PS:T game, but as has been pointed out to me, BG2 requires more fields to be filled in than PS:T does, so my maps might be sorely incomplete. I'd say start with the Nythrun map for animations that Miloch pointed to earlier, that one seemed explicitly designed as the sort of map we're talking about.

And nah, your code was fine, I didn't have to make any logical changes to produce my version, all I really did was cleanup/efficiency stuff.

Qwinn

[Sasha Al'Therin]

PFE = PATCH_FOR_EACH

But it's okay... I took another look and was able to do it with a double for loop. One that loops through all 10 possible entries despite the count and if one is found outside of the count then loop through the entries within count and see if there is an opening. This MUST run AFTER the erase bad entry code, if it's ran at all. There is patch_print text so when Miloch runs it he'll know what is happening and can adjust/debug accordingly...

I would even go a bit further and see if you can't combine the Wipeout function and the Cleanup function so that even those are done in a single pass.

Not sure at this time. I'd rather Miloch actually run it and see if there is anything that would actually use it. If it would get used, then it could be combined OR the first calls the other. Shoot all of it could be put in the tp2, but the point of using function and macro is to make the code usable in other places. True, can't see much use for it other than this, but I need the practice in writing code that interacts at different levels...

Excellent idea, and thank you for providing the code. Will update soonish.

I think I had posted something similar earlier but it had gotten lost in all the other stuff....

I can put in some of the default maps I had for actors from my PS:T game, but as has been pointed out to me, BG2 requires more fields to be filled in than PS:T does, so my maps might be sorely incomplete.

True, but even incomplete writes-maps commented to the effect that they were designed for PST will give users of non-pst games something to start with.

I'd say start with the Nythrun map for animations that Miloch pointed to earlier

I must have missed that one... I'll have to put on my waders and go backwards to look for it...

@Miloch -- The code is up to date and ready to be tested. IT DOES REQUIRE Qwinn's macros now. The code won't work without at least the Q_ARE_InitVars being launched as it now uses his variables to help shorten code length. I'll send you a PM with the updated code. No sense spamming the thread with more code... Oh, I also created a new function that looks for and lists the bad sound refs in a text file in the main game dir. This is so you can have a chance to examine the sound files prior to erasing or deleting them... More specifics in the PM. Be looking for it...

@Qwinn -- I'll carbon copy the pm to you so you could double check the code as it stands now...

[Qwinn]

The animation map is the latter part of the code Miloch links to in his second link in post #85.

Haven't had a chance to look yet, will do so soon as I can.

Qwinn

[GeN1e]

Library-of-writes

Are you talking about listing offsets (which are found in IESDP) for a quick reference, or building something like

WRITE_LENGTH offset1 1 // comment1
WRITE_LENGTH offset2 2 // comment2
WRITE_LENGTH offset3 ~idiot~ #8 // comment3
...

for each object type, so everyone can just copypaste the stuff into their installer and replace 1, 2, ~idiot~ with whatever they want?

[Qwinn]

Yep, GeN1e, the latter.

Here is the animation write map that Nythrun did, from Miloch's link:

WRITE_ASCII  ("o" + 0x00) ~GiveMeANamePlease~ // name this animation entry, you've got 32 characters to work with
	WRITE_SHORT  ("o" + 0x20) 0x0 // center point x coordinate, you'll have to find these
	WRITE_SHORT  ("o" + 0x22) 0x0 // center point y coordinate, you'll have to find these
	WRITE_LONG   ("o" + 0x24) 0xffffffff //hours when it's active, this is active all the time
	WRITE_ASCII  ("o" + 0x28) ~resref~ // your eight character resource reference for the bam you've made
	WRITE_SHORT  ("o" + 0x30) 0x0 // animation number within the .bam, I'm assuming there's just one
	WRITE_SHORT  ("o" + 0x32) 0x0 // stopping frame number within the .bam
	WRITE_LONG   ("o" + 0x34) 0b00000000000000000001000000000101 // various flags, we're setting "is shown", "not light source", and "display in combat"
	WRITE_SHORT  ("o" + 0x38) 0x0 // center point z coordinate, you'll have to find these
	WRITE_SHORT  ("o" + 0x3a) 0x0 // transparency, use a higher number if the door's made of glass :)
	WRITE_SHORT  ("o" + 0x3c) 0x0 // starting frame number, the door only needs one frame anyway
	WRITE_BYTE   ("o" + 0x3e) 0x0 // looping chance where zero equals 100 percent
	WRITE_BYTE   ("o" + 0x3f) 0x0 // starting delay, shouldn't be any
	WRITE_ASCII  ("o" + 0x40) ~~  // resref to your palette bitmap, if you have one at all - otherwise, leave blank
	WRITE_LONG   ("o" + 0x48) 0x0 // unused

"o" is the variable she chose for her offset. We'd probably want to change that if the purpose is to use it with my macros, so, for example:

WRITE_LONG  ("Q_NewOffset_Anima" + 0x48) 0x0 // unused

or even (in case you added multiple animations at once:

WRITE_LONG  ("Q_NewOffset_Anima" + ("Q_Siz_Anima * 0) + 0x48) 0x0 // unused

And the modder updates the "* 0" to "* 1", "* 2", etc., for each successive animation being added.

Eh, might be better to just leave it as "o", and explain at the top of each map, "o" should equal "Q_NewOffset_Anima" + ("Q_Siz_Anima * X), where X starts at 0 for the first animation you are adding and should be incremented for additional animations.

Qwinn

Edited by Qwinn, 04 June 2009 - 01:56 PM.

[Sasha Al'Therin]

Library-of-writes

Are you talking about listing offsets (which are found in IESDP) for a quick reference, or building something like

WRITE_LENGTH offset1 1 // comment1
WRITE_LENGTH offset2 2 // comment2
WRITE_LENGTH offset3 ~idiot~ #8 // comment3
...

for each object type, so everyone can just copypaste the stuff into their installer and replace 1, 2, ~idiot~ with whatever they want?

IESDP is a quick enough reference for someone who wants the offset number

No I was thinking of listings like you would actually use inside the tp2

If you want just copy/paste and make adjustments as you see fit (to the example below) then see if you could get a sticky post that would
1. Offer download of macro
2. Re-display the macro code
3. Display the Library of Writes
After that you could open it up for other modders to contribute either their pre-existing write maps or write maps that they've developed to use with your macros. Then at your leisure you could examine the contributed maps edit as needed and add to the Library of Writes post...

Using info from this thread, I'll show you what I was thinking of:
-------------------------------------------------------------------------

Library-of-writes For Use with Qwinn's Area Macros
The library of writes is a collection of entries used by various modders using the Area Macros created by Qwinn.
The primary function of this library is to allow other modders to have the opportunity to copy and paste proper functioning code rather than doing the work that someone else has already done.
Example: WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x20 2 // Travel Trigger Flag
This entry is taken from a new Region Trigger addition. To use it for your own new region trigger you would copy the entire line and then change the information to be written.

The components of the write statement
The WRITE command - It's use depends upon the offset being written to and the type of data to be written. See WeiDU documentation for further information
The new addition to the section offset - This is a variable which is predefined to be the starting offset of your new addition to the section in question.
The index into new additons - In the event of multiple additions being added to the same section, the size of a single section entry is multiplied by 0 for the first section entry, by 1 for the second, by 2 for the third, etc...
The entry within the new section offset - This is a hex offset (it can be decimal if you want) of the given entry within the new addition. Please see IESDP for more information regarding these values.
The data to be written - Put very simply, it is the data you want to write to the file at the given offset.

Actor Section -- Current List of Writes
These were used for Planescape Torment there may be additional entries which you may need or wish to set.
WRITE_ASCII "Q_NewOffset_Actor" ~Ulthera~ #32 // Name
WRITE_ASCII "Q_NewOffset_Actor" + 0x80 ~ULTHERA~ #8 // CRE
WRITE_ASCII "Q_NewOffset_Actor" + 0x48 ~DULTHERA~ #8 // DLG
WRITE_LONG "Q_NewOffset_Actor" + 0x38 0xffffffff // Unknown
WRITE_SHORT "Q_NewOffset_Actor" + 0x20 1554 // Pos X
WRITE_SHORT "Q_NewOffset_Actor" + 0x22 2026 // Pos Y
WRITE_SHORT "Q_NewOffset_Actor" + 0x24 1554 // Des X
WRITE_SHORT "Q_NewOffset_Actor" + 0x26 2026 // Des Y
WRITE_SHORT "Q_NewOffset_Actor" + 0x34 9 // Orientation
WRITE_LONG "Q_NewOffset_Actor" + 0x40 0x00ffffff // Present
WRITE_SHORT "Q_NewOffset_Actor" + 0x28 1 // Visible

Region Trigger Section -- Current List of Writes
These were used for Planescape Torment there may be additional entries which you may need or wish to set.
WRITE_ASCII "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) ~candle1~ #32 // Name
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x20 2 // Travel Trigger Flag
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x22 695 // Left
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x24 686 // Top
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x26 804 // Right
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x28 839 // Bottom
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x2a 5 // Num of Vertexes
WRITE_LONG "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x2c "Q_Num_Vertx" - 10 // First Vertex Index
WRITE_LONG "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x34 48 // Cursor Frame
WRITE_ASCII "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x38 ~AR0207~ #8 // Destination Area
WRITE_ASCII "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x40 ~fr0109~ #32 // Entrance name
WRITE_LONG "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x60 0x0004 // Party Required Flag
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x70 749 // Trap Loc X
WRITE_SHORT "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x72 762 // Trap Loc Y
WRITE_ASCII "Q_NewOffset_Trigg" + ("Q_Siz_Trigg" * 0) + 0x7c ~~ #32 // Script Name (BCS)

Spawn Points -- Current List of Writes

Entrances -- Current List of Writes

Containers -- Current List of Writes

Items -- Current List of Writes

Vertices (Vertex Points) -- Current List of Writes
These are four bytes per coordinate/point first two bytes are the X value the second two bytes the Y value
WRITE_SHORT "Q_NewOffset_Vertx" + 0 804
WRITE_SHORT "Q_NewOffset_Vertx" + 2 779
WRITE_SHORT "Q_NewOffset_Vertx" + 4 784
WRITE_SHORT "Q_NewOffset_Vertx" + 6 686
WRITE_SHORT "Q_NewOffset_Vertx" + 8 698
WRITE_SHORT "Q_NewOffset_Vertx" + 10 736
WRITE_SHORT "Q_NewOffset_Vertx" + 12 695
WRITE_SHORT "Q_NewOffset_Vertx" + 14 839
WRITE_SHORT "Q_NewOffset_Vertx" + 16 804
WRITE_SHORT "Q_NewOffset_Vertx" + 18 779

Ambients -- Current List of Writes

Variables -- Current List of Writes

Explored Bitmask -- Current List of Writes

Doors -- Current List of Writes

Animations -- Current List of Writes
These were used without Qwinn's macros but can be adjusted to work with the macro simply change "o" to "Q_NewOffset_Anima" + ("Q_Siz_Anima * X) where X is 0 for a single animation addition or incremented by one for each additional animation addition.
WRITE_ASCII ("o" + 0x00) ~GiveMeANamePlease~ // name this animation entry, you've got 32 characters to work with
WRITE_SHORT ("o" + 0x20) 0x0 // center point x coordinate, you'll have to find these
WRITE_SHORT ("o" + 0x22) 0x0 // center point y coordinate, you'll have to find these
WRITE_LONG ("o" + 0x24) 0xffffffff //hours when it's active, this is active all the time
WRITE_ASCII ("o" + 0x28) ~resref~ // your eight character resource reference for the bam you've made
WRITE_SHORT ("o" + 0x30) 0x0 // animation number within the .bam, I'm assuming there's just one
WRITE_SHORT ("o" + 0x32) 0x0 // stopping frame number within the .bam
WRITE_LONG ("o" + 0x34) 0b00000000000000000001000000000101 // various flags, we're setting "is shown", "not light source", and "display in combat"
WRITE_SHORT ("o" + 0x38) 0x0 // center point z coordinate, you'll have to find these
WRITE_SHORT ("o" + 0x3a) 0x0 // transparency, use a higher number if the door's made of glass
WRITE_SHORT ("o" + 0x3c) 0x0 // starting frame number, the door only needs one frame anyway
WRITE_BYTE ("o" + 0x3e) 0x0 // looping chance where zero equals 100 percent
WRITE_BYTE ("o" + 0x3f) 0x0 // starting delay, shouldn't be any
WRITE_ASCII ("o" + 0x40) ~~ // resref to your palette bitmap, if you have one at all - otherwise, leave blank
WRITE_LONG ("o" + 0x48) 0x0 // unused

Automap Notes -- Current List of Writes

Tiled Objects -- Current List of Writes

Projectile Traps -- Current List of Writes

Song Entries -- Current List of Writes

Rest Interruptions -- Current List of Writes

[Sasha Al'Therin]

Had an idea that may help the user of the macros out without too much modification

In Q_AREAdd_InitVars add anywhere:

SET Q_NewEntry = 0 //this initializes the variable so weidu doesn't flip out...

In Q_AREAdd_Process add after this line SET $Q_NewOffset("%S1%") = "Q_Offset1" + ("Q_NumSect" * "Q_SizSect"):

SET $Q_NewEntry("%S1%") = $Q_NewOffset("%S1%") + ($Q_Siz("%S1%") * %Q_NewEntry%) //this adds the location of the new entries index within the new bytes

Then in the tp2 when the user wants to add two or more of any given section they can do (using region trigger as an example):

SET Q_NewEntry = 0
WRITE_SHORT "Q_NewEntry_Trigg" + 0x20 2 // Travel Trigger Flag
etc...

SET Q_NewEntry = 1
WRITE_SHORT "Q_NewEntry_Trigg" + 0x20 2 // Travel Trigger Flag
etc...

[Qwinn]

Eeeeehhh, I dunno on that last one, Sasha. The purpose seems to be to get rid of the "X" I mentioned in the Animations map description, so you hand back the user multiple "NewOffset" variables (only with a different name), one for each new record of a given section you just created? If so, seems to add a lot of complexity for little gain, as far as I can tell.

And that seems to be the purpose, but I'm not sure the logic there would work anyway. Not getting why changing the value of New_Entry is going to change the value of New_Entry_Trigg.

Qwinn

Edited by Qwinn, 06 June 2009 - 07:04 PM.

[Sasha Al'Therin]

Eeeeehhh, I dunno on that last one, Sasha. The purpose seems to be to get rid of the "X" I mentioned in the Animations map description, so you hand back the user multiple "NewOffset" variables (only with a different name), one for each new record of a given section you just created? If so, seems to add a lot of complexity for little gain, as far as I can tell.

And that seems to be the purpose, but I'm not sure the logic there would work anyway. Not getting why changing the value of New_Entry is going to change the value of New_Entry_Trigg.

Qwinn

The idea was that the user could set which entry their list of writes were going into without the possibility of forgetting to change some because they copied the list of writes from another local...

But I forgot that your macro runs only once to add the new space...
The user would then have to include this SET $Q_NewEntry("%S1%") = $Q_NewOffset("%S1%") + ($Q_Siz("%S1%") * %Q_NewEntry%) in order for it to work. So I guess that idea is out the window...

Guess my mind is still stuck in a for loop somewhere...

[GeN1e]

I guess the writes are better to be represented as

// [u]Actors[/u] //

SET ag_q_number = 1 // index of the item we're writing for, 1 is the default value. If you've added more than one, then repeat the whole block while increasing the value by 1 for each repeat
SET ag_q = (Q_NewOffset_Trigg + (Q_Siz_Trigg * (ag_q_number - 1))
WRITE_SHORT (ag_q + 0x20) 1234 // X
WRITE_SHORT (ag_q + 0x22) 4321 // Y

Shall start stitching the library together, then. Btw, I've been thinking about popularizing the process a bit, since Qwinn's documentation, albeit clear, still may remain red-coloured for some. Sort of 'Area patching for real noobs'. Don't mean to step on anyone's toes, of course, as you guys were first to deal with the issue.

[Sasha Al'Therin]

If your example is in an actor section than your dead wrong as you're giving trigger offsets....

SET ag_q_number = 1 // index of the item we're writing for, 1 is the default value. If you've added more than one, then repeat the whole block while increasing the value by 1 for each repeat
SET ag_q = (Q_NewOffset_Trigg + (Q_Siz_Trigg * (ag_q_number - 1))

what's ag mean? Actor Group?
That's what I was thinking in the earlier post, but had hoped that the player wouldn't have to do too much extra (i.e. the macro would handle the math). I since remembered that the macro can't because it's only called once, not after each section of writes. It's not part of Qwinn's macro, but if the user used it, it would cut down on the amount of 'typing' in each line. So if you were to create a Newbie Guide to Area Patching, be sure to state that it is not required for them to do that in order to use the macros effectively, but that it's an optional ease of use idea...
You could just start with 0 rather than 1 but I can understand that most people equate first section with 1 and second with 2...

Shall start stitching the library together, then. Btw, I've been thinking about popularizing the process a bit, since Qwinn's documentation, albeit clear, still may remain red-coloured for some. Sort of 'Area patching for real noobs'. Don't mean to step on anyone's toes, of course, as you guys were first to deal with the issue.

I'd wait for input from Qwinn first... It's his macros we are talking about after all. He's the one who's dealt with the issues... Miloch and I just discovered a few things that wouldn't work with non pst games. Other than theory, I've not actually used his macros yet...

Note to self... Re-do the trigger additions to ar1803.are in totsc to use qwinn's macro and test it out... While there since it will be called up... adjust all existing area edits to utilize his variables in the fixpack...

@Qwinn -- have you got a set of ITM macros that we could adjust for BG1?

[Kaeloree]

ag is GeN1e's personal prefix, IIRC.

[Miloch]

@Qwinn -- have you got a set of ITM macros that we could adjust for BG1?

Eh... WeiDU should already provide macros for most of what you'd want to do with items. If you need to do more advanced stuff, check the lib in PnP Free Action (link in my sig) for just about any other macros you'd need (items, spells or CREs).