Sam.

That does raise the question of what the overall status of the project is. New bugs are still being identified, but the rate they're coming in is starting to approach a trickle. Is there an estimate of the percentage of reported bugs that have fixes implemented? Alternatively, what additional milestones need to be reached before an official first release?

Let me start by saying I've only half been following this thread while traveling, so just ignore me if my ignorance is showing. With that being said, I believe there was something about (certain?) mobile platforms using a different DTX compression scheme than desktops for (some?) PVRZ file variants? Something like DTX3 on mobile vs the normal DTX1 & DTX5...? Sorry my details are vague, but I didn't commit them to memory as I don't play on mobile, but it tickled a memory so I thought I'd (attempt to) mention it.

Done. Sorry for the delay.

I'm not sure I follow. As a purely contrived example, let's say my string is ~IETME~ and my RegEx is ~^I\(t*\).T.*\(.\)$~. My current results (looking for matched values) look something like: The RegEx '^I\(t*\).T.*\(.\)$' was found at position 0. The matched pattern is 'IETME'. RegEx SubPattern 0 is 'IETME' RegEx SubPattern 1 is '' RegEx SubPattern 2 is 'E' I already have the offset for SubPattern 0. The offset for an empty matched SubPattern should probably be -1 (i.e. not found). Can you step me thru how you're suggesting I get the offset to SubPattern 2?

I'm trying to write my own RegExMatch PATCH function that wraps other built-in commands to achieve some functionality I find hard to get at using only the base commands. With INDEX_BUFFER or RINDEX_BUFFER I can get the offset of the entire first matched regular expression. Using REPLACE_EVALUATE I can make an array containing the first match of the regular expression as well as what was matched by each of it's subgroups (submatches?). For my purpose I'm ignoring any subsequent matches beyond the first. Using these, I can get the length of the entire match and the length of each subgroup. I now have what was matched by the RegEx, where it is, and how long it is. I also have what was matched by each of the subgroups (submatch?) and how long each is. My question is: Is there a way to reliably retrieve the OFFSET to each subgroup of the matched regular expression?

Sent you a PM.

As far as I recall, EET converts the classic movies from the original format to the EE format and dimensions on-the-fly during installation. I believe it uses ffmpeg to do this. BGEE Classic Movies pre-converts the movies to the EE format and dimensions using a combination of several different software programs and a variety of specialty filters to address the compression artifacts present in the originals which are typically exacerbated when up-scaled. In my opinion, BGEE Classic Movies's version are visually superior to the native EET version, but if having the classic movies there at all is enough to satisfy one's sense of nostalgia then yes I suppose this component is redundant. BGEE Classic Movies also restores the original chapter background screens, and supports several different UI themes. I don't recall EET doing this, so this component of the mod wouldn't be redundant.

I see your point. The remainder of this post exclusively concerns RNDTRES.2DA, also in BG2EE v2.6.6.0 (Steam edition). I’ll keep the topic of these observations consistent with the numbering from my previous post for clarity. N/A Using a script like the one in my previous post to directly generate random items from a new row in this table did nothing unless the actual ITM file named for the new row name in this table actually existed in the game. Item names pointing into this table correspond to the row names within the table, so obviously if you try pointing to a row name not in this table you aren’t actually pointing into this table at all. Duh… Changing the “2DA Default Value” appeared to have no effect whatsoever. If you do something against the rules, you get an invisible, unmovable item. This table supports purely numeric entries which translate into that number of gold coins. It is unnecessary to zero pad these numbers. For example, column values of [001 01 1] all give 1gp. A value of 0 (zero) gives one gold. The maximum number of gold coins that can be given at a time is 255. The asterisk use of giving multiples of an item that is stackable does work here (e.g. MISC07*10 gives 10 gold coins). The max stack using this method is also 255. I didn’t bother discerning the logic behind how many you get if you exceed 255, but it is less. You get a uniform distribution (equal chance) of the valid values on a row from this table. How the engine determines the valid values is outlined in the next point. The engine stops counting valid values with the first asterisk (*) it finds in the row reading from left to right. If the first column in that row is an *, then you only get invisible, undroppable items. If the 1st column has a valid item (or gold) and the 2nd column is an *, you only get what was in the first column, even if there was a valid item in the 3rd column. Don’t use sparse "arrays" here.

I have spent some time testing how various aspects of the RNDEQUIP, RNDTREAS, RNDMAGIC, RNDWEP, and RNDSCROL random treasure 2DA tables work in BG2EE v2.6.6.0 (Steam edition). Some of my observations matched my expectations based on currently available descriptions of this mechanic, and some of them were surprises (at least to me). I will attempt to summarize my findings here, along with any caveats about the scope of my testing. Note that I have not yet tested RNDTRES.2DA at all. Everything here pertains to the 5 I listed above. There are either 19 or 20 columns of random treasure on any given row in these 2DAs that can be drawn. I determined that making 2000 draws against these 19 or 20 potential items (a factor of two orders of magnitude) would be enough to draw sufficient statistical conclusions about the distributions. To facilitate this in a somewhat timely manner, I wrote the following script, assigned it as the custom script on the PC, let it run to completion, and had them and an NPC collect and consolidate the results. Note that the actual ITM name varied with the tests performed. IF GlobalLT("PS_RandomTableTest","GLOBAL",400) THEN RESPONSE #100 GiveItemCreate("RNDEQU04",Player1,1,0,0) GiveItemCreate("RNDEQU04",Player1,1,0,0) GiveItemCreate("RNDEQU04",Player1,1,0,0) GiveItemCreate("RNDEQU04",Player1,1,0,0) GiveItemCreate("RNDEQU04",Player1,1,0,0) IncrementGlobal("PS_RandomTableTest","GLOBAL",1) END My first observation is about the naming of the RND***x#.ITM files that point into these tables where *** depends on the 2DA and # is the row index in the table. Some sources claim that the x must only be 0 (zero) in the EEs whereas other sources claim it can be any arbitrary character. I found it could be any arbitrary character (I tested letters and numbers), subject to the restriction specified in the following point. This applied to all 5 of the 2DAs. Generating the random items directly via the above script required the actual ITM file called out to actually exist in the game. If it did not, nothing at all happened: no real items nor any erroneous invisible and unmovable items were created. I did not test if this hold true if the ITM files are referenced indirectly (from one random treasure 2DA into another). This applies to Point# 1 insomuch as the second to last character can’t directly be any character not supported as a filename character by the OS. This applied to all 5 of the 2DAs. When the “2DA Default Value” (line 2 of the file; not to be confused with line 2 of the table) is set to * (the value set in the unmodded game), then any call from an ITM pointing out of bounds in the table (such as pointing to the 4th row in a table with only 3 rows) generates an invisible, unmovable item. This applies to all 5 of the 2DAs and is subject to Point# 2. The next logical question becomes what happens if the “2DA Default Value” is changed. I found that changing this value in RNDEQUIP, RNDMAGIC, RNDWEP, and RNDSCROL and then referencing a row not in the table (like row 4 out of 3 as above) gave this default item instead of an error item. In all 4 of these 2DAs, a quantity value was also supported here (e.g. MISC07*100). However, I also found that if a valid row in the table contained any entries consisting of a plain asterisk (*), these generated invisible, unmovable items regardless of the “2DA Default Value”. I found changing this value in RNDTREAS.2DA had no effect whatsoever. All 5 ransom treasure tables supported purely numeric entries which translated into that number of gold coins. It was unnecessary to zero pad these numbers. For example, column values of [001 01 1] all give 1gp. I did not test the upper limits of how much gold can be specified at a time, nor did I test what happens when the value is 0. For each of the sets of 2,000 rolls I made into any of the treasure tables, I ALWAYS got exactly 2,000 items. I was never shorted any, not even in RNDEQUIP. The following chart summarizes the distributions I got rolling into each of these random treasure tables. RNDEQUIP RNDTREAS RNDMAGIC RNDWEP RNDSCROL Column Headings 1->20 2->20 2->20 1->20 1->20 Estimated dice roll 2D10-1 2D10 2D10 1D20 1D20 Distribution quasi-normal quasi-normal quasi-normal uniform uniform RNDEQUIP has column headings from 1 to 20. One might expect to roll onto this table with a 1D20 and get a uniform distribution (an equal chance of rolling any number from 1 to 20). Alternatively one might expect to roll onto this table with a 2D20 and get a quasi-normal distribution where possible rolls fall between (inclusive) 2 and 20 with the greatest chances of rolling into the middle of these possibilities. Neither of these appear to be the case. It may be apparent that the first time I ran RNDEQUIP I couldn’t quite believe the results, so I rand them again and got the same result. The dice roll appears to be something like a 2D10-1 meaning column 20 is impossible to roll instead of the expected column 1. The bottom right plot in the above chart is what I get when I delete column 1 from RNDEQUIP and make the 2,000 rolls. This matches what is expected from a 2D10 roll and all table columns are “rollable”. I contest this is either an engine bug (it should be rolling 1D20 onto this table), or there is a bug in the 2DA and column 1 should be deleted and the entries there incorporated into the other columns on the same row. Preferably supplanting a duplicated entry where possible.

I have some questions about the BG-style random treasure 2DA tables for BG2EE. Question 1) RNDEQUIP.2DA claims its item filenames are RNDEQUx#.ITM RNDTREAS.2DA claims its item filenames are RNDTRE0#.ITM RNDMAGIC.2DA claims its item filenames are RNDMAGx#.ITM RNDWEAP.2DA claims its item filenames are RNDWEPx#.ITM RNDSCROL.2DA claims its item filenames are RNDSCRx#.ITM Where x=any character (even letters and symbols, and has no bearing on how RND*.2DA is read), and #=the row number of RND*.2DA to use (can be 1-9). Of the above, RNDTREAS.2DA is the outlier with the second to last character being a static 0 instead of the variable x. However, the rndtreas expansion topic indicates that, for the EEs, the 2nd to last character must ALWAYS be 0, and the 2DAs can in fact use more than Rows 1-9. I take it the topic is correct and the IESDP was just never updated? Question 2) Is it necessary to have these random treasure table ITM files physically in the game, or is it enough simply to reference the relevant filename in the CREs, containers, etc.? Question 3) RNDEQUIP.2DA, RNDWEAP.2DA, and RNDSCROL.2DA have column headers from 1 to 20, but the IESDP claims 2D10 dice are rolled into a row of this table, meaning the possible values you can roll are 2 to 20. This means column 1 can never be rolled. Conversely, RNDTREAS.2DA and RNDMAGIC.2DA have column headers from 2 to 20, but the IESDP claims 1D20 dice are rolled into a row of this table, meaning the possible values you can roll are 1 to 20. This means that if you happen to roll a 1, you get nothing. Don’t these dice rolls seem… backward? Question 4) Is it safe to make the assumption that when the engine “rolls a die”, it generates a random number from 1 to the maximum die face using a uniform distribution? In other words, you have an equal chance of rolling any of the possible numbers on the die? If so, then rolling onto these random loot tables with a 1D20 does NOT have the same probability distribution as rolling onto them with a 2D10. Adding multiple uniformly distributed random numbers tends toward the shape of a normal/Gaussian distribution: In essence, if you roll using a 1D20 you have an even chance of getting any of the items on that row of the table. If you roll using 2D10, you have a far higher chance of getting an item towards the middle of that row than you do getting an item towards the left or right ends… If this is correct, then an item’s position within the row for the 2D10 2DAs is quite impactful… Also, I found it useful to have a visual representation of which random treasure table 2DAs could reference which others, so here it is.

Cast the Clairvoyance spell?

I was working on downsizing/cropping some original artwork from 1024x1024px to the EE portrait sizes, and decided to do a little testing. I tested with BG2EE v2.6.6.0. My results seem to be contrary to conventional wisdom. Using ImageMagick I resized and cropped a test portrait to the three EE sizes: 210x330 Large, 169x266 Medium, and 54x84 Small. On a hunch I also made one that was 420x660 (I’ll call it G for Giant) and tried all of them in-game. On the Records screen (which conventional wisdom says should use the Large size), the Giant portrait was noticeably the clearest, the Large was a bit blurry, and the blurriness got worse with decreasing size. When I took a screenshot and counted the pixels of the portrait on the Records screen, I got 253x392px (I’ll call it H for Huge). The portrait overlapped the border by at least 1 column of pixels on the right, and a row of black/dark pixels between the portrait and the bottom of the frame around it, and 1-2 rows of black/dark pixels between the top of the portrait and the frame. I believed this was an indication the engine was maintaining aspect ratio when resizing the portraits. To be sure, I tried the original 1024x1024 portrait, but the same 253x392px with the same border was displayed on the records screen (with the aspect ratio clearly distorted). I then used ImageMagick to resize the original to 253x392px and tried it in the game. I compared the in-game screenshots for the Giant, Huge, and Large portrait sizes to each other and to the Huge size outside the game. The Huge was less blurry than the Large, but perhaps ever so slightly more blurry than the Giant (with a caveat). The Huge portrait displayed in the Records screen at a slightly different aspect ratio than did the Giant and Large. Comparing in-game and out-of-game Huge portraits, I could perceive no visual difference between the two. This indicates the game is distorting the aspect ratio of the Giant and Large portrait sizes. For the caveat: the difference in perceived blurriness was so minor I was probably just seeing artifacts caused by the different area ratios. All of this was tested with the “Scale User Interface” in-game option turned ON. When I turned it OFF and counted the pixels of the portrait on the records screen, I got 180x279 which is the same aspect ratio as the Huge listed above (actually the same area ratio would be 180x278.8932806 but it rounds to the nearest whole pixel). I maintain this is evidence all of my observations so far remain true with this setting turned off, it’s just that everything appears smaller on screen and so the differences would be harder to spot. Moving on to the portraits on the game screen, I again tested with “Scale User Interface” in-game option turned ON. I tested all three (Large, Medium, and Small) of the traditional EE portrait sizes as well as the Giant and Huge sizes specified above. On the game screen (which conventional wisdom says should use the Medium size), the Giant by far looks the worst, Huge is pretty bad too, and the Small is very blurry. Large and Medium are pretty close in my test case, but Medium is just a bit better. When I took a screenshot and counted the pixels of the portrait on the game screen, I got 76x118px. For comparison, Medium is 169x266px which means it is being downscaled significantly even when up-scaling the user interface. Comparing the Medium portrait to a 76x118px one sized/cropped with ImageMagick, the results are quite similar. Personally, I prefer the ImageMagick result in terms of detail vs blurriness. I also think ImageMagick’s 76x118px result is more accurate in terms of aspect ratio, but the difference is probably on the order of half a pixel. Note that the 76x118px game screen portrait has the same aspect ratio (within rounding) to the Huge one calculated from the Records screen screenshots above. I suspect that DPI scaling settings and monitor dimensions may play a role in this, for the sake of transparency I am testing on a modest 1920x1080 laptop screen with 125% DPI scaling with OpenGL version 4.4.0 – Build 21.20.16.4550 running on Intel ® HD Graphics 530. My takeaways: · BG2EE’s internal scaling algorithm: o Does not maintain aspect ratio o Is better at downscaling than upscaling, but only up to a certain point. Large factor downscaling produces inferior results to what can be achieved by 3rd party tools. · On my setup, ideal dimensions for the “Large” portrait size are 253x392px and NOT the conventionally accepted dimension of 210x330px. · On my setup, ideal dimensions for the “Medium” portrait size are 76x118px, but the conventional 169x266px size produces similar results depending on the scaling algorithm. · Using only a single (Large) portrait in both the “Large” and “Small” slots found within a PC/NPC’s CRE structure results in inferior results for the smaller portrait (depending on quality of the internal/external scaling algorithm). The unmodded EEs only allow to select a single portrait during character generation that is assigned to both slots. I would appreciate if anyone else testing under a different environment could confirm/deny my findings. @Bubb, I recognize this is not likely your area of interest, but if you have any particular knowledge about what the engine is actually doing here that would be very informative.

Try these with helm18.itm and VVCs as-is. Seems to work for me, but not sure how robust it is. I have a second idea if this one doesn't work out. [attachments removed] Edit: These weren't very good either. They fixed the issue with the gaps, but made the animations doubly dark because they were playing on top of each other. More importantly, rapidly pausing and unpausing while fully zoomed in de-synced the two animations, so it would gradually appear as if two separate ioun stones were circling, but buggy. Is is probably true of all split foreground/background animations, but was particularly noticeable here. The solution was that because the ioun stone animations didn't need to actually pass behind the character model (just over their head), and single animation+VVC could be used for the entire circuit, but the offsets had to be adjusted to get everything ordered right.

@paladin84 Sent you the modified BAMs at SHS. BTW, I misremembered how these worked. You don't need to edit the VVCs. You'll need to edit the items to play only the first VVC and not the second. Edit: That didn't work as I expected (same issue as here). Working on figuring it out.

I started playing around with it tonight. I can mostly automate the combining process with PS BAM. The VVCs will need to be edited to use only the first of the two BAMs (I've kept the offsets in that BAM the same). First one attached. However, the 1st and last frames end up in the same position but aren't the same graphically. Should I remove one or the other? After your answer I'll finish combining them tomorrow. [attachment removed]