Height and width information of items about source-x

[cbnolok]

Maybe the best thing would be to add a ART_HEIGHT and WIDTH prop to the itemdef

[cbnolok]

There isn't right now, but there's also a good reason for that, because in order to get that info you have to read and parse the pixel data of art.idx and that might be time consuming... If you and others think that's necessary, we could add that to x2 by parsing art data at startup, data will be much faster to access but at the cost of slightly increasing startup time and memory used

[falanlar]

Let's wait and see then :)

[Tolokio]

I can create a script for python that read that info and generate a def. (it is possible to have that lot of defs?)
[defname art_dimensions]

//art_n Width_Height

art_01 12_25
art_02 15_45
art_03 166_54

Then with a function u can split W_H format to get width and height.

[cbnolok]

It's possible but it will make defs in general slower, also you'd have to recreate the info when you change or update arts

[Tolokio]

I think third party tool could do the work. We get a "default" setting for vanilla client and a .exe or .py to allow user update it. We could load on cache from a .txt file that u can edit with notepad or use a thirdparty tool to generate a new one with updated arts. Whatever is done is fine for me. Just talking about.

what about a doswitch? Would it be fine or it is a very long list for it? Is there a max amount of lanes a dosswitch can deal with? I can try to do a .py or .exe to generate something like this meanwhile.

[function f_get_arts_dimensions]
// argn = # of the art.
doswitch <argn>
  return width_height
  return 12_14
  return 133_23
  ....

[Tolokio]

Do we create a console function for it?

example:
SyncroArts-> This command will note ur "art`s dimensions" into ur itemdefs scripts.

[canerksk]

There isn't right now, but there's also a good reason for that, because in order to get that info you have to read and parse the pixel data of art.idx and that might be time consuming... If you and others think that's necessary, we could add that to x2 by parsing art data at startup, data will be much faster to access but at the cost of slightly increasing startup time and memory used

---

In fact, the sphere is already reading Tiledaya data as many times as the next number with SERV.TILEDATA.id.UNK19. So, even if there was a memory problem here, wouldn't Tiledata be interrupted? Also the same applies to DumpUnscriptedItems. Moreover, it does not read all the files required to open the Sphere, it will only import them. I think this would be a great job with a memory optimization in this part, but it seems a bit difficult because the development process is very slow. The to-do list in X2 is starting to get bigger.

[xwerswoodx]

Maybe the best thing would be to add a ART_HEIGHT and WIDTH prop to the itemdef

Honestly I have noticed that we can use TAG under itemdef, so we can just add TAG.ART_HEIGHT and TAG.ART_WIDTH values in core scripts.

[Steinny]

the size don't help much, I use TAG for offsets like TAG.SIZEADJ = -7,8