LVZzz

[»SOS]

So, like, what is going on? Any LVZ support on the horizon? Any development on DCME at all?

[Witchie NL]

I !@#$%^&* hope there is!

[Samapico]

So, like, what is going on? Any LVZ support on the horizon? Any development on DCME at all?

Nothing on LVZ yet... but eLVL support is a big step forward and will probably make us gain some market in the ASSS zones (eLVL is about 90% done now, just need to fix a little bug when saving region tile data, and then we need to make a Region tool... and its ready )

And before LVZ we need to redo the Undo system completly... If you noticed, the current undo system cannot support anything related to the selection... But I have something in mind that would allow DCME to undo anything.

And then, we'll start working on LVZ The first step will probably be to just read ini files... then generate them... without necessarly displaying the images at first (perhaps only rectangles or something)...

 

But yeah... there IS development on DCME don't worry

[Drake7707]

lvz isn't all that different from regions, its just that pictures get pasted on those spots, but there has to be a way to manage lvz easily, like how are you going to access those files required for an lvz file

 

If anyone has any suggestion concerning that matter, feel free to let us know

[Samapico]

perhaps you could ask Bak and how he does it for CLT (or just check the source , if you know java)

[»SOS]

How to access the files? Silly man, with fopen or whatever the command was in VB6

 

But seriously, accessing the files can be done in 50 ways. It all depends on the central architecture.

 

For example, are LVZ things going to be kept in raw (ini + image) form or compressed form (.lvz)? Will people be able to edit the graphics that are already in DCME?

 

Most likely answers: raw, yes.

 

Now, how to actually organize it in the program? I would have an ExtendedLevel object that contains all the LVZ data (objects, images, included files). At program start, a LvzLoader object would load the ini file and read all the info. It would then load graphics objects and !@#$%^&*ociate them with 1) the loaded image; 2) the path the image was loaded from. It would then load the LVZ object objects and !@#$%^&*ociate them with the graphics.

 

That's it. At save, the ini would be overwritten. You can even use the Windows INI write methods that preserve existing comments and everything (but are awfully slow).

 

I would also hook change monitors to the graphics files, so that if you change something while DCME is open, it would automatically update the graphics in DCME. $$$

 

Nothing to it

[L.C.]

You could just have the entire LVZ Placement & Editting system under OGL/D3D editting along with in-editor map testing. Would save some pain, maybe. :?