LVZ current status + todo list

[Drake7707]

- LVZ map objects can now be drawn like tiles with pencil, and anything involving lines (well maybe except sticky line)

- Mapobj properties can be set in the lvz tileset

- mapobj draw A LOT faster than before (but caching takes more time)

- lvz paths are saved in elvl chunk, meaning dcme will auto-load and auto-save the lvz's when a map is loaded/saved

 

todo:

 

- Remove the GUI of map objects in lvz form

- LVZ tool needs reworking to able to move map objects, move them around and change their properties in an easy way (small 'simulated' pop up menu)

- LVZ can be drawn on top of each other, but an option to remove a map object once it intersects with another on the same layer can be useful (kinda like it removes wormholes when placed partly on top of each other)

- Other tools need adaptation of lvz (bucket (with option to use either tiles or map objects as boundaries testing), etc)

[Samapico]

[Samapico]

There... if you guys want to have fun with the new stuff... It's pretty much functionnal... probably not very stable though. Feel free to report any crash

 

-removed attachment-

Edited October 14, 2007 by Samapico

[»SOS]

Cannot find VB6FR.DLL. !@#$%^&* frenchies

[Samapico]

 

oh right... I think I was able to set it up on my comp so it compiled without any language dependency... (using my dad's comp now...)

[»SOS]

Maybe it'd also be better to add it to the "required files" sticky?

[Drake7707]

it isn't necessary for other version usually, just this one because he compiled on a french vb computer (which isn't his own) (and usually i compile it )

[Samapico]

oh right... my own computer compiles it correctly because I have an english version of VB.. heh

[»SOS]

I am attaching a draft of my analysis for LVZ management in DCME.

 

In summary, I think the current functionality is a step in the right direction but it does not have a centric goal - it seems very haphazard and is not geared towards what I would call the complete devel design experience.

 

This draft contains the initial analysis of LVZ object functionality. It does not contain anything about the implmentation.

 

Comments are welcome. I hope you developers agree with me on this - I think if this were to be implemented, DCME could rise to a whole new level of kick!@#$%^&*.

 

 

Object_management_in_DCME_v0.1.pdf

 

 

Bonus reader-motivational tidbit! You can find out my real name by reading this do!@#$%^&*ent!

[Drake7707]

neat, use cases woo

 

this do!@#$%^&*ent so reminds me of my course of design & analysis

[Samapico]

ew... nice

 

LVZ file management[/b]

LVZ files should be completely opaque – LVZ objects should be entirely contained within the level file. Only at the last export step – when the level designer wants to publish the map to the zone – should the lvz file be generated. The generated LVZ file should be split into multiple LVZ files if they exceed Continuum’s maximum LVZ file size limit (4 MB TODO: Was this the correct limit?).

Yes it's the limit

But the developper should have some control on how the lvz files are built... You don't want to have everything in a single LVZ, else you get pissed off players whenever you update

 

DCME is centered around graphical objects in LVZ files. It should not provide any support for adding any other kind of file or performing any general file management of LVZ contents.

I disagree. Sound files, help files, or any other files are part of the development of an arena too.

 

There should be no process for first importing a file and then creating an image definition out of it.

Image definitions are now added automatically with gfx files

 

 

Didn't read the whole thing yet.. nice work though

[»SOS]

But the developper should have some control on how the lvz files are built... You don't want to have everything in a single LVZ, else you get pissed off players whenever you update

 

Yes, you are right. I must think about this some more.

 

I disagree. Sound files, help files, or any other files are part of the development of an arena too.

I agree. And I disagree.

 

Yes, they definitely are a part of arena development but they have nothing to do with level development. Settings and bots are also arena development but I don't think they have any place in DCME and neither do the things you mentioned. I would hate to see DCME bloated into some do-it-all Swiss army knife tool. It should be level editing only.