TES4LL Woes

[Jimi diGriz]

As Andalay said on Nexus, we've been having problems getting TES4LL to run with Argonia.  It stops running when it calls TES4qLOD.

We have managed to build the project and debug it. 

The first problem we ran into was that the directories were not being created properly.  I tracked that problem down to an issue in llutils.cpp with it deleting variables while they were still in use. 

I also fixed an issue with the processing of the "-w" parameter in tes4ll.cpp where it was trying to process the subsequent worldspace name as a parameter.  I don't know if that actually caused any problems but it was confusing to trace.

Once past there we found that tes4qlod was failing.  We were able to build and debug tes4qlod by itself and found an issue with the processing of one of the cells in Argonia.  In Process4LANDData it tries to decode the VCLR, ATXT, BTXT, and VTXT fields after decompressing the LAND record.  It manages to find the VTXT field before processing the BTXT field so doesn't have any quad info to work with.  This causes a memory access error.  There isn't any error handing here so I assume it just dies quietly.  I am guessing that the ZLIB decompress is not working properly so we are looking at pulling in a more recent version of ZLIB. 

[AndalayBay]

Just to clarify: we grabbed the separate TES4qLOD program and set up a project for the source code, so we're debugging tes4qlod.c, not the cpp version. Both versions have the same issue. We found the c version easier to debug.

We compiled TES4LL and I ran the new version with MPGUI. I can now generate the LOD meshes and Normal Maps. It's just the Colour Maps that fail, or TES4qLOD as Jimi said.

We're using Boost 1.82.0.

[Gruftikus]

Thank you very much for your effort.

If you fixed the issue, the best thing for me for further processing is is you could fork the project on Github, commit the changes (please, only the lines with the issue, so no editorial changes over the entire code) to your fork, and create a pull request. In that flow I can go through the changes line by line and finally accept the pull request.

I'm using git in my professional field (a project with 20-30 members) and it is really the best tool to create and maintain community projects

 

[Jimi diGriz]

I have created the pull requests for tes4ll and lltool (under AndalayBay).

When I started using source control professionally git hadn't been invented yet.

[AndalayBay]

Jimi has been in IT for almost half a century!! No kidding. I couldn't resist phrasing it that way.

I'm a mere pup at only 30 years or so...

[Gruftikus]

Thank you very much, these are indeed some bugs which normally only unraveled if outer boundary conditions changed.

BTW when I started my career as a programmer, the internet was not yet born (at least not for me) and I had to type hex dumps which were printed page by page in journals into my C64

[AndalayBay]

5 hours ago, Gruftikus said:

Thank you very much, these are indeed some bugs which normally only unraveled if outer boundary conditions changed.

I thought that might be the case, but what really confused me is that Argonia is smaller than Tamriel. The NW boundary coordinates are -36,37 and the SE is 50,-37. Actually, that might be something. Do the physical dimensions of the land have to match the Cell Coordinates specified in the World Space window for the map?

Physically the NW is -40,40. The farthest landscaped point in the east is 49,7, but in the SE it would be 41,-32. I had to set the coordinates to be slightly different to get the map to line up properly with the land. If TES4qLOD is trying to access 50,-37 there's nothing there. In fact that cell doesn't exist in the world space.

I think I just figured out what the problem is. I need to change the cell coordinates in the world space window to use values that actually exist or I have to extend the land a lot farther in the south-east. I had to set it to the farthest point in the east (49) and the farthest point south (-36) to get the map to line up, but as I said, the resulting coordinates don't correspond to an actual cell.

5 hours ago, Gruftikus said:

BTW when I started my career as a programmer, the internet was not yet born (at least not for me) and I had to type hex dumps which were printed page by page in journals into my C64

Yeah it's amazing how quickly things have changed. Did you ever use punch cards?

I remember when there was a disaster somewhere overseas in 1990. It might have been Bosnia. Anyway I had a coworker who couldn't get in touch with her husband's family. Jimi worked for the university at the time and they had something called Usenet that they could use to contact a university in the area. She was able to send a message and found that his family was ok.

Jimi's first small computer was an Apple II. It had a whopping 64kb of memory with the expansion card. He also managed to save up enough money to get a 10MB hard drive. All told it cost over $8000!!

[AndalayBay]

It still doesn't work. I fixed the map coordinates so they are now pointing to actual physical cells, but the program still halts at the call to TES4qLOD.

[AndalayBay]

We also tried using the new version of zlib and that didn't help, so we don't think it's anything to do with the decompression. I'll have to set the map coordinates back to what they were because now our in-game map is not aligned properly. I'm in the process of extending the coastal region, so the coordinates might correspond to an actual cell, but I haven't gotten to that point yet.

Any ideas?