Server Help

LVZ/LVL Questions - LVZ Hell (part deux)

Cerium - Mon Jan 15, 2007 4:22 pm
Post subject: LVZ Hell (part deux)
Ok, so I've come to the conclusion that Priit added LVZ support over the course of two hours while heavily intoxicated and possibly drugged.

I've got a bunch of LVZs, each using a fair number of objects. LVZ 1 has 192 images, LVZ 2 has 103 Images (about 40 of them dummys) and LVZ 3 has a single image.

I really have no fucking clue how LVZs work on the client end. On the surface, Continuum seems to allow each LVZ file to have it's own unique set of images that can only be used by the objects in that file (which in itself is stupid, but makes a bit of sense when you consider he stupidly limited the total number of images to 256). However, when I started writing the bot I quickly noticed this is not the case.

Originally, LVZ 2 only had around 60 images, with holes inbetween a bunch of image definitions for organization. This works fine for your standard LVZ designs where nothing needs to be toggled or changed, but as soon as I had a bot start sending modification and update packets, Continuum broke. LVZ objects which have no object ID (and thus, should be constant) were changing on a whim and some were using images that were defined in other LVZs.
I figured the problem was that I would jump around on the image numbers (IMAGE15 to IMAGE20 being left undefined), so I filled all the gaps in with dummy images, but that only made things worse.

Now, even before the bot can do anything, the LVZ images are getting hosed. The single LVZ object defined in LVZ 3 is using an image defined in LVZ 1, but the bot's modification seems to work fine now.


So, yeah. I'm confused as fuck. Every time I think I make sense of this shit, something else that makes absolutely no sense happens and I'm right back to where I started. Does anyone (MGB) have any clue how the client handles this crap? I'm about to lose my mind here, as it seems like I've wasted a month of work thanks to this awful client.

Thanks
-C
Mine GO BOOM - Mon Jan 15, 2007 4:38 pm
Post subject:
One, and only one, LVZ file can have object ids. Thus the whole reason for my first Makelevel program I did, so I could create an LVZ file with just pure object information, and have other LVZs hold the files so if you updated an image, you wouldn't have to redownload a meg file.

Internally in the LVZ, all image numbers are renumbered from 0 to n-1. That is why if you debuild a LVZ file, they don't always keep the same numbering system as the original ini file that created it.

How you should do it: LVZ 1 has some images, LVZ 2 has more images, etc. Then another LVZ called lvzobjs.lvz or something is the only one with object information. lvzobjs.lvz should contain no files, as you can split those off into other LVZ files.
Smong - Mon Jan 15, 2007 4:38 pm
Post subject:
First I would assume cont loads the lvz in the order they are listed in the server settings. This would be the fallback order. Then I would assume as you have already stated - objects defined in a lvz will try and use images defined in the same lvz, otherwise fallback to the other lvz.

Another thing is avoid using the ID 0, and also large number ID's, since these might wrap around due to the number of bits given to them.

Other than my opinion I can't give you any solid advice. I've never tried implementing lvz in my client and probably never will.

When I wrote my skin viewer there were non-obvious undocumented things that were pretty confusing there too (I was going for exact clone). I consider my current implementation "good enough", but it could be better if I didn't get frustrated with it.
Cerium - Mon Jan 15, 2007 4:48 pm
Post subject:
So if you put all your image definitions in one file and the object definitions in another file, how do you define which image you're using? How does continuum know you want IMAGE0 from redlvz instead of IMAGE0 from bluelvz?
Mine GO BOOM - Mon Jan 15, 2007 5:03 pm
Post subject:
All file= lines are in a bunch of LVZs. Everything else, images, screen objects, and map objects, are in one LVZ file. Do not split this into more than one LVZ file.
Cerium - Mon Jan 15, 2007 5:06 pm
Post subject:
So I am limited to 256 images? Fucking Priit.

Oh well, looks like I've got a lot of work to do. Thanks for the info.
Mine GO BOOM - Mon Jan 15, 2007 5:18 pm
Post subject:
Cerium wrote:
So I am limited to 256 images? Fucking Priit.

Source: ASSS Wiki: LVZ
Quote:
Continuum only supports 256 different images in all of your lvz files combined. If you exceed this limit, toggling the 257th image will turn on the 1st image. This is often undesired, so be careful.

Chambahs - Mon Jan 15, 2007 6:38 pm
Post subject:
I would have thought 256 was enough..
Bak - Mon Jan 15, 2007 6:42 pm
Post subject:
Are you sure you have to define all your object ids in one file? i've never had any problems using more than one file, as long as your total number of images is less than 256.
Cerium - Tue Jan 16, 2007 5:03 am
Post subject:
@Bak:
You don't absolutely have to, but it certainly makes it easier to figure out how the images and objects will be defined and handled on the client end -- less likely to end up with bizzaro problems like mine. Plus, as he said, you can change stuff around without requiring a complete redownload.


@Chambahs:
256 isn't even close to enough to what I'd like to do. To complete this project exactly to the original specs I'd need (atleast) another 576 images.
Doc Flabby - Tue Jan 16, 2007 7:32 am
Post subject:
one thing you could do. Is combine say 4 images or as many as you want into one. Then use a black (or whatever colour your background is) lvz to cover the sections you dont want to see.

This solutions i can see being horrible to impliment however. I also have no idea if it would acctually work.
Samapico - Tue Jan 16, 2007 6:59 pm
Post subject:
I thought mapObjects definitions could only apply to files in the same lvz... cool.
Samapico - Wed Feb 07, 2007 8:48 pm
Post subject:
Hmm, quick question about these lvzs...

Is it possible to have Image Definitions (IMAGE#=...) in a lvz, and the mapobjects using that image definition in a different lvz?
Bak - Wed Feb 07, 2007 9:52 pm
Post subject:
no, why would you want to? the meat of the filesize is when you include the File= part.
Samapico - Wed Feb 07, 2007 10:17 pm
Post subject:
its not that i want to.. just wanted to figure out how to make dcme's interface for lvz's, and if it was technically possible to do that, it would have complicated things a bit...
Didn't think it was possible either, just wanted to make sure... stuff started to get confused in my head tongue.gif
thx
Samapico - Fri Feb 16, 2007 8:30 pm
Post subject:
Another thing I'm wondering right now...
What happens if you have, say, a IMAGE0 in one lvz, and a IMAGE0 in a different lvz? Does continuum confuses them? Or does continuum creates its own imageID's anyway? (as long as total of all imageID's isn't more than 256, of course)
Cyan~Fire - Fri Feb 16, 2007 8:50 pm
Post subject:
Continuum does confuses them, it's actually supposed to be a feature.
Samapico - Fri Feb 16, 2007 9:47 pm
Post subject:
gah.. I just re-re-re-read the lvz format...

the Image Definitions sections don't have an ID identifier... so emm... When they are loaded, they get ID's automatically from 0 to 255 within that lvz file? or... ô.o

If that is the case, I can't see how continuum would confuse them... well it would depend on the order in which lvz's are loaded, which makes no sense...

Is MGB's lvz toolkit source available somewhere? I'd like to see how that is done exactly... that or a clear explanation would do tongue.gif
Bak - Fri Feb 16, 2007 10:34 pm
Post subject:
Continuum doesn't confuse them. The numbering is unique to the lvz file, although a total of 255 total images in all lvz files is all that's allowed. If you create an lvz using IMAGE10 instead of IMAGE0, create the lvz file, then decompress the lvz file, it will be IMAGE0 in the ini file.


X-LvzToolkit comes with source if you want a look.
Samapico - Fri Feb 16, 2007 10:37 pm
Post subject:
ok... that now makes sense in my head

So I'm guessing when you build lvz with mgb's lvztoolkit, when you write like

IMAGE23=file.bmp
IMAGE27=anotherfile.bmp

and then
IMAGE23,x,y,blahblahblah

when saving the lvz object definitions, image23 is the first to be saved (id = 0), image 27 is saved next (id = 1), so when the mapobject using image23 is saved, the actual 'ImageID' that is stored would be '0' ?
Bak - Fri Feb 16, 2007 10:41 pm
Post subject:
correct

Code: Show/Hide
/**
* We need to map the encoded image num, to the actual one, since we don't get a choice when
* we're encoding the image objects
* @param encodeNum the encoded number in the ini file, that we'll transform into the correct one
* @return the correct byte we should use for the image num in our lvz file
*/
private static int getImageNum(int encodeNum)
{
   int num = -1;
   
   for (int x = 0; x < imageObjects.size();++x)
   {
      ImageObject io = (ImageObject)imageObjects.get(x);
      
      if (io.num == encodeNum)
      {
         num = x;
         break;
      }
   }
      
   return num;
}

Samapico - Fri Feb 16, 2007 10:52 pm
Post subject:
alright, thanks

<finishing up DCME's lvz>
Bak - Sat Feb 17, 2007 3:12 am
Post subject:
can't wait bro, DCME is amazing.
Cyan~Fire - Sun Feb 18, 2007 1:03 am
Post subject:
Ooh, my bad. Is it that a file included in one LVZ can be referenced in another? There's something like that.
Samapico - Sun Feb 18, 2007 1:01 pm
Post subject:
Files can be referenced by other lvz yes.
But not image definitions.

So you can define an image definition using a bitmap from a different lvz, but can't define a mapobject using an image definition from a different lvz
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group