Jump to content

Qwinn's WeiDU PS:T FixPack


Qwinn

Recommended Posts

These restorations and other components sound more like an "Unfinished Business" for PS:T, which is cool, but maybe it should be a separate mod from a fixpack. That lets you just concentrate on fixes in one mod, then you can add all the new material you want in the other at your leisure.

 

Oooh... that's an excellent idea, actually, and I think I'll go with that. Although at this point, since I've already done a lot of the Unfinished Business stuff, looks like I'll be releasing at least initial versions of both simultaneously.

 

Qwinn

Link to comment
Ok, never mind for now... just found this post:

http://forums.gibberlings3.net/index.php?s...&pid=103476

Yeah, that's the post I was talking about for adding effects to spells, etc., but I don't think it's necessary for adding CREs to AREs if you can do it by script.

 

Maybe something like this for the scales? I probably won't have time to make a BAM for another week or two though. If you need it before then, you might have more luck on shsforums.

scales.jpg

Link to comment

That's excellent! Something like that in a slightly rougher PS:T style with the right color background would be perfect.

 

And I'd love for ya to do it, no hurry, since that'll be an optional thing I do it won't be released for a while yet. If you think you could do it within a month, that'd be great, if you think it might be longer than that then I may try SHS.

 

Actually, looks like I'll be releasing -three- mods at once, heh. The Ultimate Fixpack, Unfinished Business and then Qwinn's Bonus Mods, hehehe.

 

Qwinn

Link to comment

Nother progress update for any who are interested..

 

I now have a tentative readme written up for the Fixpack giving some details of what it contains, which I'll happily post publicly wherever and whenever I wind up getting hosting for the mod. Now that I'm separating out the UB stuff, the Fixpack will probably be ready for alpha testing in a week or two, maybe sooner.

 

The bits I described above about fixing the dialogs of the thugs in the Dangerous Alley in the Hive will go in the fixpack, I really believe it was intended that way.

 

A fair amount of things I consider fixes from the Restoration Pack will go into the Fixpack and not UB, things like the extended journal entries, bestiary entries and sound files that were hidden away in the game files and mainly prevented from being seen in game by simple misplaced file names or bad references. That says "bug", not "unfinished business" to me.

 

Here's what is definitely intended for the Unfinished Business project so far, all WeiDUized, of course:

 

Platter's Restored Candlestick Quest, with SKARDAVNELNATE's fixes

SKARDAVNELNATE's Restored Elyce and Company quest

SKARDAVNELNATE's Restored Pendant of Yemeth quest

SKARDAVNELNATE's Restored Truth of Deionarra's Death conversations

SKARDAVNELNATE's Restored Curst Citizens

Qwinn's Restored Morte & Ingress's Teeth Banter

Cilantro's Restored Githzerai Respect and Tattoo component

Cilantro's Restored Items (things like Tome of Cheats, Sword of Whynn, Eye of Vecna, Devil's Due, Chaos Feather, Lockpicks, Spell Keys, etc.)

 

(Cilantro was, it is my understanding, the author of the Restoration Pack)

 

I won't be adding "Morte's Original Intro" from the Restoration Pack, because I felt it was rather lame change compared to what's in the game and can understand why the designers nixed it.

 

Not sure yet where some of the other Restoration Pack stuff will go, like the buying Lothar's skulls stuff.

 

No idea what mod will be the home for my Scale of Souls yet :(

 

Oh, one last thing. I could grow old, and no one would ever see the mod, trying to make the zillion changes to files in the Fixpack be 100% compatible with being installed -after- every other mod in the world by making all it's changes to .CREs and .ITM's recognize variable offsets caused by other mods changing file sizes. I do do the vast majority of my changes by edits, not file overwrites, so it could -probably- be installed after other WeiDU mods and work fine, but I'm not going to put off release for an extra 6 months to make absolutely sure of it, not when all logic and tradition says that the Fixpack is always the first thing installed 100% of the time. It will generally be assumed that future WeiDU mods will be developed with the Fixpack previously installed, though it shouldn't be really necessary in 99% of cases. That's the way it's normally done with BG1 and BG2 stuff, yes? People don't mod for it -without- taking changes made by the G3 fixpack into consideration normally, right?

 

All UB components and other mods I write, though, will be written with great care to recognize variable offsets so that they can be installed in any order with other WeiDU mods. That is reasonable I hope, and not out of line with common practice, yes? Not a rhetorical question, I'd love a response to that, if doing it that way would make people queasy about installing it, let me know.

 

Qwinn

Link to comment

Okay, because I'm a sucker for punishment, I've taken what I figured had to be the most obnoxious modification I could find in what I've run into so far to see if I could super-WeiDUize it so that it would install properly no matter what changes had been made to that file previously by other modders.

 

The challenge? Take a .ARE file, and edit the fifth trigger point which has 6 vertexes, modifying the existing 3rd through 6th vertexes and adding another 13, without interfering with any previous patches that could've altered the file, including other mods that could have added vertexes to previous trigger points. Heh.

 

The only assumption I'm allowing myself is that if someone did add a totally new trigger point, they did so after the current last one, rather than inserting a new one between the 1st and 5th trigger points definitions. They can add vertexes all over,

they just can't insert a new trigger definition between old ones. I have to make that assumption because if they did insert one like that, I can't think of any way I could possibly tell. Seems a safe assumption anyway.

 

To be specific, I'm trying to recreate this fix. The 5th trigger point originally has 6 vertexes, and it's updated to be 19.

 

// AR1404.ARE

// Made Lowden more accessible by excluding his area from the larger trigger.

// Trigger Point 5

// Vertex 0 X: 467, Y: 688 <- Keep

// Vertex 1 X: 778, Y: 604 <- Keep

// Vertex 2 X: 970, Y: 929 <- Splice

// Vertex 3 X: 943, Y: 929 <- From Trigger Point 6

// Vertex 4 X: 911, Y: 959 <- From Trigger Point 6

// Vertex 5 X: 916, Y: 981 <- From Trigger Point 6

// Vertex 6 X: 934, Y: 983 <- From Trigger Point 6

// Vertex 7 X: 938, Y: 974 <- From Trigger Point 6

// Vertex 8 X: 928, Y: 974 <- From Trigger Point 6

// Vertex 9 X: 938, Y: 957 <- From Trigger Point 6

// Vertex 10 X: 954, Y: 956 <- From Trigger Point 6

// Vertex 11 X: 950, Y: 946 <- From Trigger Point 6

// Vertex 12 X: 940, Y: 946 <- From Trigger Point 6

// Vertex 13 X: 943, Y: 929 <- Same as Vertex 3

// Vertex 14 X: 970, Y: 929 <- Same as Vertex 2

// Vertex 15 X: 1102, Y: 1153 <- Moved down

// Vertex 16 X: 810, Y: 1251 <- Moved down

// Vertex 17 X: 705, Y: 1206 <- Moved down

// Vertex 18 X: 739, Y: 1143 <- Moved down

 

 

I did manage to do it - yay me. And I made so many comments for my own sake that I figure it's now a nice little tutorial on how to do it, so I figured I'd share.

 

Note that the file I did this to had only 1 container and no doors, so the code at the end of this hasn't been tested under any extremes, but the logic did work to patch this file well. No unused bytes or anything else odd when I was through, and I think I've accounted for all eventualities other modders could introduce.

 

So - here goes. How to add a crapload of vertexes in the middle of the vertex section in a file with a mess of trigger points with total compatibility with all other mods as the end goal. Note that the definitions for triggers, doors and containers each have their own section but they basically all share one big area for all their vertexes.

 

 

// 13 new vertices to be inserted, 4 bites each, total of 52 bytes or 0x34 in hex,

// add 0x34 to all offsets beyond that of the point I'm doing my insert. The

// comments after my writes in this little section are just the values I'd find were I

// patching the vanilla version of PS:T AR1404.ARE.

 

COPY_EXISTING ~AR1404.ARE~ ~override~

READ_SHORT 0x80 "oldnumverts"

WRITE_SHORT 0x80 ("oldnumverts" + 13) // # Vertices 109 -> 122

READ_LONG 0xa0 "oldoffset"

WRITE_LONG 0xa0 ("oldoffset" + 0x34) // New Explored Bitmap Offset cf4 -> d28

READ_LONG 0xb0 "oldoffset"

WRITE_LONG 0xb0 ("oldoffset" + 0x34) // New Animations Offset ca8 -> cdc

READ_LONG 0xbc "oldoffset"

WRITE_LONG 0xbc ("oldoffset" + 0x34) // New Songs Offset cf4 -> d28

READ_LONG 0xc0 "oldoffset"

WRITE_LONG 0xc0 ("oldoffset" + 0x34) // New Rest Spawn Creatures Offset d84 -> db8

 

// Now, as mentioned before, the trigger points, doors and containers all

// share one big vertex section, and they all use a single index to position

// themselves in relation to the single vertex offset.

// Each trigger point, container and door has at least one field named "First

// Vertex Index" which places it's position in the big vertex pool. So if a given

// trigger point's first vertex was the 44th vertex in the big pool, and that

// trigger point went on to list 19 vertexes, the next trigger point (or door, or

// container)'s "First Vertex Index" would be 63. Actually, doors have FOUR

// "First Vertex Index" fields because of the various states a door can be in

// (open, closed, etc.)

 

// Anyways, so. Let's grab the vertex offset. This is the offset of the very

// first vertex in the big vertex pool, in this case belonging to the first trigger

// point in the file. Store it in variable "v0".

 

READ_LONG 0x7c "v0"

 

// We also need the offset for the trigger point definitions.

 

READ_LONG 0x5c "infotriggeroffset"

 

// Trigger point definitions are 0xc4 in length, and the # of vertexes in that

// trigger point is at 0x2a from the start of each definition. We want to access the

// fifth trigger point definition so we can update the vertex count in it from 6 to 19,

// and we also want the "First Vertex Index" value from it to calculate our offset

// from the main vertex offset in order to do our insert and writes. The FVI is

// stored right after the # of vertexes, at 0x2c. So:

 

// I chose "FVI" as my variable name to mean "First Vertex Index" for this trigger.

// In this case, it's 44. That means that trigger points 1-4 used up 43 vertexes

// between them, and the 5th one starts at 44.

 

WRITE_SHORT ("infotriggeroffset" + (0xc4 * 4) + 0x2a) 19

READ_LONG ("infotriggeroffset" + (0xc4 * 4) + 0x2c) "FVI"

 

// Now find the offset of the third vertex of trigger point five (because

// we're not changing the first two) and insert 0x34 bytes there, then write

// vertexes 3-19 at that point. Each vertex is 4 bytes (X in the first two

// bytes, Y in the second pair of bytes), and I know my vertexes

// for this trigger point start at 44 vertexes in from the main vertex offset

// (FVI = 44, although if another mod had added vertexes prior to it, my FVI

// value would be different and that's okay, that's precisely the reason we're

// going through all this trouble, just in case another mod did just that).

// The old values of vertexes 3-6 get pushed forward to the positions of 16-19,

// by the INSERT_BYTES but I'll be overwriting them so no big deal.

 

INSERT_BYTES "v0" + (("FVI" + 2) * 4) 0x34

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 0) 970

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 2) 929

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 4) 943

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 6) 929

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 8) 911

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 10) 959

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 12) 916

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 14) 981

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 16) 934

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 18) 983

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 20) 938

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 22) 974

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 24) 928

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 26) 974

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 28) 938

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 30) 957

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 32) 954

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 34) 956

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 36) 950

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 38) 946

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 40) 940

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 42) 946

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 44) 943

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 46) 929

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 48) 970

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 50) 929

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 52) 1102

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 54) 1153

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 56) 810

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 58) 1251

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 60) 705

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 62) 1206

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 64) 739

WRITE_SHORT ("v0" + (("FVI" + 2) * 4) + 66) 1143

 

// Almost done. Now we have to increment the "First Vertex Index" for each

// trigger point after the fifth by 13. So we need a loop to count from 6 to the

// total number of trigger points, in case another mod added new ones. If

// there were no additions, the loop will only run once (the file originally had

// six.

 

// Fetch the total count of trigger points

 

READ_SHORT 0x5a "TotalTrigs"

 

// And here's the loop:

 

FOR ("i1" = 6; "i1" <= "TotalTrigs"; "i1" += 1)

BEGIN

READ_LONG (("infotriggeroffset" + (0xc4 * ("i1" - 1)) + 0x2a) + 2) "OldIndexCount"

WRITE_LONG (("infotriggeroffset" + (0xc4 * ("i1" - 1)) + 0x2a) + 2) ("OldIndexCount" + 13)

END

 

// Wait. Not quite done. Gotta do the same for the container in this file too, as

// it was mapped to the vertex section after all the trigger points (and another

// mod might've added more of them too, gotta account for those. The container

// section is 0xc0 in length. The "first vertex index" field is 0x50 from the offset of

// each container section.

 

READ_SHORT 0x74 "TotalContainers"

READ_LONG 0x70 "containersoffset"

 

// And here's the loop:

 

FOR ("i1" = 1; "i1" <= "TotalContainers"; "i1" += 1)

BEGIN

READ_LONG ("containersoffset" + (0xc0 * ("i1" - 1)) + 0x50) "OldIndexCount"

WRITE_LONG ("containersoffset" + (0xc0 * ("i1" - 1)) + 0x50) ("OldIndexCount" + 13)

END

 

// And God help us, what if someone added a bunch of freakin' DOORS.

// Doors have no less than four "First Vertex Index" fields we have to update.

// The door section is 0xc8 in length, and the four fields are at 0x2c, 0x34, 0x48

// and 0x50 from the beginning of each section.

 

READ_SHORT 0xa4 "TotalDoors"

READ_LONG 0xa8 "doorsoffset"

 

FOR ("i1" = 1; "i1" <= "TotalDoors"; "i1" += 1)

BEGIN

READ_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x2c) "OldIndexCount"

WRITE_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x2c) ("OldIndexCount" + 13)

READ_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x34) "OldIndexCount"

WRITE_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x34) ("OldIndexCount" + 13)

READ_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x48) "OldIndexCount"

WRITE_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x48) ("OldIndexCount" + 13)

READ_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x50) "OldIndexCount"

WRITE_LONG ("doorsoffset" + (0xc8 * ("i1" - 1)) + 0x50) ("OldIndexCount" + 13)

END

 

// END Lowden Fix and Modding Vertexes for n00bs tutorial

 

 

 

And that's it. Consider this "Vertex Modding for n00bs", written by a n00b, hope it helps someone someday. And if I made any dumb rookie mistakes, please please please do tell me.

 

Glad I did this, I now feel confident that if I could super-weiduize -that- mess, I can do it for anything, heh. Course, someone will probably point out either that I screwed it up, or that that's way easy compared to other stuff that comes up regularly, heh, but I'm gonna enjoy the feeling as long as I can. :(

 

Qwinn

Link to comment
It will generally be assumed that future WeiDU mods will be developed with the Fixpack previously installed, though it shouldn't be really necessary in 99% of cases. That's the way it's normally done with BG1 and BG2 stuff, yes? People don't mod for it -without- taking changes made by the G3 fixpack into consideration normally, right?
Unfortunately, some poor unenlightened bastards still live in the stone age, and do not use the Fixpack. They use Baldurdash or no fixpack at all. I'm being a bit facetious, as it's more of a political thing as to what constitute's a "fix." There really shouldn't be such contention though - any fixes that are that debatable as to cause folks not to use it really should be optional. No need to force stuff down people's throats. It's probably not quite as big of a deal for PS:T which doesn't have much of a modding community, but still it's the reason I suggestion you put anything arguably not a fix in a separate mod or "OBC" (optional but cool) component. I suppose the ultra-thorough modders account for installs with and without the Fixpack. The thing is, no mod is going to be 100% compatible with some other mod that does something contrary.
All UB components and other mods I write, though, will be written with great care to recognize variable offsets so that they can be installed in any order with other WeiDU mods. That is reasonable I hope, and not out of line with common practice, yes? Not a rhetorical question, I'd love a response to that
Standard procedure, yes (should be at least). Again, probably not as big of a deal for PS:T, but who knows, maybe this will trigger a revival of mod interest for it. It really is one of the more underrated games out there.

 

And you should post your tutorial in the How To section. It's gonna get buried in this thread :(. I think Yovaneth wrote up something similar, but it's always good to have more.

Link to comment

Will do with the tutorial :( And thanks for responding to the other stuff. That makes sense. So yeah, I'm not going to stress unduly about making the fixpack installable after other stuff, standard practices of doing everything possible via edits should make that as viable as it probably should be, there'll be more than enough work making sure the UB and other new stuff can be installable in any order.

 

Oh, and, it should be known that Spellhold Studios has expressed interest in the mod and is willing to host it, so I'll be moving my progress updates and stuff over there, once they make room in the barn for me. I'll post a link to the new forum when it's ready. Hope to see ya there :D

 

Qwinn

Link to comment
I think Yovaneth wrote up something similar, but it's always good to have more.

 

You asked but he didn't.... my argument at the time was it was Weidu stuff and I was concentrating on writing DLTCEP tutorials. I 've recently reused the same piece of code to sort a problem out for cmorgan, so perhaps I should write something up. It was patching bams into the .are, BTW.

 

-Y-

Link to comment

I'm actually in the process of writing a couple of includes that are basically a tool for modifying areas that should, if it works, allow me to never worry about modifying offsets or indexes again. You include an init.tph file in your .tp2, then set some variables telling it how many areas and triggers and vertexes and containers and whatever else you want to add, run the second include, and it'll automatically reset all of the offsets and insert the bytes for you, filling in a variable containing the offset at which the new sections were inserted and you should start doing your writes at. It's also completely dynamic, and should work regardless of any previous modding to the file.

 

I've actually got the basic part of it done already... the part I'm trying to cover now is letting the coder tell the tool "I don't just want to add new vertexes, I need to modify (and change the number of, either up or down) the vertexes in an existing trigger, or door, or container". That has to be handled in a significantly different way (all of the "First Vertex Index" fields could potentially need updating). Same for adding items to an existing container. When I figure out the code for those situations, hopefully by tonight, it should be pretty slick.

 

Really there's no reason I couldn't do it for other file types like .CRE's and stuff, but let's see if I can make it work with .ARE's first.

 

Has anyone produced anything like that before?

 

Qwinn

Link to comment

Actually, rather than post that tutorial, I instead spent the last couple days writing a few macros that do a lot of the work of adding to .ARE files -for- you. I just posted the macros over at SHS... here's how I introduced it.

 

Just spent a lot of time writing these macros to help my own coding for the upcoming PS:T Fixpack and Unfinished Business, and I figured I'd share. I have modified several files with them.

 

One macro provides a lot of the offsets and stuff you generally need to look up in NI or IESDP and provides their values for you in consistently named variables for your use.

 

Another two macros will redo all the offsets and counters for you when adding any combination of new sections to a .ARE file with very very little work on your part.

 

Feel free to cut and paste this entire file and use it as an include in your programs. The comments within the file explain what it does and how it works.

 

Keep an eye here, because I hope to be adding a couple of macros that will allow you to edit the vertexes in an existing door, container or trigger, or add items to an existing container, hopefully within a day or two after I've worked the kinks out.

 

Enjoy!

 

Check it out here:

 

http://www.shsforums.net/index.php?showtopic=33231

 

And let me know what you think!

 

Qwinn

Link to comment
The only assumption I'm allowing myself is that if someone did add a totally new trigger point, they did so after the current last one, rather than inserting a new one between the 1st and 5th trigger points definitions.

 

There's no need, any area structure that uses vertices also has a 32 byte internal name that you can READ_ASCII offset string (0x20) NULL to make sure you're patching the correct trigger (or whatever).

 

You'll also want to be updating offsets based only on what changes as a result of your INSERT_BYTES, but it looks after a cursory inspection that you've done that in the other thread.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...