News:

Huge spam cleanup. I hope, everything important is still in place. :-)

Main Menu

Some tiles are not visible in the tile list

Started by Tatzelwurm, July 19, 2008, 12:03:35 AM

Previous topic - Next topic

Tatzelwurm

Hey,
I do not really know if this is a feature request or a support issue.

However,
we modified the art.mul. Normally, UO uses static arts from 0x0 to 0x3FFF. But we use an advanced art.mul with 0xBFFF entries. That means that our art.mul (for the static arts) starts at 0x0 and ends at 0x3FFF. CentrED does not have a problem in reading the modified art.mul (means we don't have any crashes) but in showing the tiles in the list. Of course, CentrED does only show 0x3FFF tiles (because it is standart).
Therefore, we cannot use the tiles from 0x4000 to 0xBFFF. Is there a possibility to change the limit of listed tiles in the settings? Otherwise I would ask you to set the limit to 0xBFFF (if that causes a problem for all users of a 0x3FFF art.mul an option in the settings would be nice).

I hope that is not a lot of work...

Hopefully you can help us,
Tatzelwurm

Hitman

It's already on my ToDo list. If you need it very urgent, you could modify the source code yourself - there aren't many occasions where that limit appears.

Smoothy

Hello,
I wanted to ask you if you are already working on this, and if, when do you think it will be ready?

Tare

So, I tried to modify the source code and changed the maxID to $FFFF at UfrmMain in procedure TfrmMain.BuildTileList. That extends the tilelist, so you can scroll under the $3FFF of statictiles. But if you reach $4000 the client shows a prompt for not a second and quit. Lazarus shows an error " Project raised exeption class 'External: SIGSEGV' " followed by the prompt that the execution is stopped Adress: $005B4F9A, Procedur: ??, File: " " and the text "(TODO: Assembler-Ansicht an dieser Stelle". After confirm, the same prompt appears once again.
The MulPatcher shows all arts in correct manner, but I noted that InsideUO shows the arts on ID $4000 and above at the tab of 'character test'. Could there be the problem?

Hitman

This shouldn't be a problem. But you probably have to enable some more options in the Lazarus project to help you debug ... mainly under Project --> Compilersettings --> Linker the options to include debug info and line numbers (take care to also remove the option to 'remove debug info' ;)).
I guess your problem could have to do with the TileDataManager which preallocates the necessary tiledata entries (and therefore is also limited currently).

Tare

Thanks for the clue, I wondered why report is this short. ^^ First time that I use lazarus. Hope I can fix it now :)

Tare

I got it. After changing the entries at TileDataManager, the tiles were shown, but on draw the server print 'error processing buffer of client: IP'. So I changed the buffer of client and server to 6144, the 1,5x of normal. Next try no error were shown, everything is fine now.
Just one question: Our art is only filled up to $5100. Could it happen that the buffer-error appears again, using art at $7FFF? How could I calculate the needed buffersize?

Thanks for your help and patience with me :)

Hitman

Did you recompile the server before doing anything with the buffer size (but after the changes to the tiledatamanager)? The buffer size should not have anything to do with these problems (since it's really only a buffer used to read data from the network ... at least if we talk about the same buffer [OnReceive?] ;)).

The "error processing buffer" comes from line 253 of UCEDServer.pas and comes everytime, when some exception is thrown during the processing of a packet. In case you didn't recompile the server too after making the changes to the tiledatamanager, it probably happend, that you added a tile with one of the new IDs, the server tried to lookup the data of this tile in the tiledata, and boom, exception (index out of range). So that it worked after the buffersize change would be pure coincidence then, and not really related :)

I'll think of something to make this "error processing buffer" message more verbose without throwing too much unneeded infos to the casual user (although it shouldn't hurt, since the bug reports can be more specific and helpful then ... hmm ...).

But thanks to this, I learned something: it might be a good idea to make the tiledata size an option of the server and submit it in the initial connection packets to the client. If I've some spare time, I'll implement that (finally ...).

Thanks for taking these first steps and reporting back here.

Tare

I ment the buffer mentioned in UdmNetwork.pas and UCEDServer.pas, but you are right ^^ I changed back the buffersize at both and it still work fine :) The problem was that the projectinspector didnt show the TileDataManager, so I didnt try to recompile the server before doing changes. I think that can happen, when someone try to read a complex program of an other in short time :) If I can help you with something, let me know, then I will try my best ;)