Popular Content

Showing most liked content on 04/19/2017 in all areas

  1. 1 like
    Thanks for the positive comments. Of course I will share in due course. Hit a bit of a problem in the last week with palettes. It all started when I realised I had no Tumeroks, the capture had rejected them. Looking into it, I found the 3d model for Tumeroks must have changed from the old days. The new model number wasn't in the original portal.dat This led me to ascertain which models were not being used, and by forcing them onto creatures with a similar build, searched for the Tumeroks, and other extinct creatures. Many seemed to be variations on zombies and skeletons, and I found the Tumerok model. Then when I started looking closely at the values for the palettes, to see why the Tumerok types all looked the same, I realised that the new capture data referenced palettes that didn't exist in the old portal.dat file. I then took a step backwards, and looked closely at the capture data for palettes and realised that the original UAS2 and its companion capturing program were in error, but that a workaround somehow made it work. The original capture program did a weird thing when it loaded up the palettes, and made a field called Unknown-1 which it stored and presented when it was time to show that creature (or item). Each palette where it exists consists of a palette file number (in the portal file) and an offset and length, which overlay into the working palette. The values captured looked weird... I realised that the offset, length pairs were in fact actually palette file numbers misplaced in the data, so 6D for length of F was really palette file F6D. Because of the botched way UAS2 used the palette values, these somehow still came out correctly in most cases. In fact there is no need for an "unknown1" field. If a palette is present, it has a count of at least 1. What follows the counts of palette, texture and model is something that looks like a base palette, or a palette for part of the 3d model. This does not have an offset and length value, but is immediately followed by sets of palette overlays that do. These are often a value, and offset and length of 0. The length of 0 means 256. I played around for ages with a drudge ravener's palette. It seems some of the palette values come from that first palette, so it's not entirely that the subsequent palette(s) just overlay. So I have gone back to the original data, and applied various fixes to the data. We now have at least a correct set of data, and unknown-1 is replaced with BasePalette. I am now writing similar code for items. Of course I had to go through and put the base palette code into every class that presented palettes rather than the unknown_1 field. The big digression was trying to match the TOD palettes to the old palettes. This was like the old days for me, doing colour matching algorithms. And I think the results are pretty good.... but haven't helped me get Tumeroks looking correct! It seems that the old Tumerok model does not use the palette at all. The only thing I can do is make them slightly bigger or smaller! So onwards.. and then I need to get back to what I was doing last week.