lvz

[Samapico]

...I'm watching the lvz form, and I just can't figure out how it should be...

 

Any ideas on how the interface should allow you to:

 

-Add/Remove lvz files

-Add/Remove files from each of these lvzs

-Define ImageObjects (IMAGE#=file....) in each of these lvzs (note, files arent always from the same lvz)

-Add mapobjects/screenobjects in each lvz, !@#$%^&*ociate them with ImageObject definitions from the same lvz, and define their properties

 

For now we have a treeview that shows lvz's and their files... but then, to do object definition stuff, i dunno...

 

Think of how you'd feel the more confortable to build your lvz files, and feel free to draw a draft on paint or something

[L.C.]

Have you tried !@#$%^&* (CLT?) and its LVZ feature before? Maybe you could get an idea from that interface. I would post a reply better than this and more of "my own idea" sort of thing, but I'm doing my homework right now. Recently I've been nuked with pressure from two huge !@#$%^&*ignments.

[Samapico]

Yeah I did see CLT...

 

But there are some things buggering me.. You can't add files other than images

You can't seem to change image properties after you imported it

We'd like to set screenobjects as well... but that's pretty easy once the setup is done for mapobjects

[Drake7707]

don't nuke my interface >.<" It took long to get it right

[Samapico]

yeah I know, but how do you get image definitions in there? another treeview? I don't think that's the way to go :/

[Drake7707]

well no, just like map objects, 2 treeviews. The upper for lvz package contents, the lower for the image objects similar like map objects

[L.C.]

You're looking for a good interface, eh? Hold on, let me draw one. I think I can draw up an excellent design.

 

EDIT :: I need a quick screenshot of this "tree" you speak of in DCME.

[Samapico]

well no, just like map objects, 2 treeviews. The upper for lvz package contents, the lower for the image objects similar like map objects

hmmm maybe

 

upper tree view for available ressources

lower tree view for current items

 

like in image definitions, the different lvzs and their files (only images) will appear in upper tree view

 

in map/screen objects, the different lvzs and their image definitions will appear up there...

 

yeah that might work

 

But I don't know if it will be very intuitive... the first time I saw these 2 treeviews I was like 'wtf' and couldn't find how to do stuff... of course there were no labels yet or anything, so I guess it could work

 

 

Edit: just realised what made it un-intuitive... the Add object / Remove objects buttons are above the property list while they should be placed near the treeview

Let's see what you can come up with LC... but basically this could work, just have to figure out where to place stuff and choose good labels to make it easy to understand and use

Edit2: I also guess OK and Cancel buttons should be out of the tabs cause they affect the whole thing ... mhmmmmm

[L.C.]

http://www.hlrse.net/Qwerty/dcme_lvzgui.JPG

This isn't perfect, but this to me would be a very convenient and lovable interface (not saying yours isn't either).

 

Display Time can be like 12.5 for example - 12 seconds and a half is what it means of course.

You have to have the Animation flag checked to use the animation fields.

I forgot what ObjectID is.

Coordinate Presets of course would be premade locations - of course this would only work with screen objects. The center to screen would calculate the proper coordinates to get it centered to someone's client screen (my XY values are made up).

Image preview would have that checkered background Photoshop uses to show "null" backgrounds. Maybe underneath the preview the user could control whether it uses checkered/null background or a colored background (which also can be adjusted right there on the spot). Could be useful for transparent parts in images.

 

Why this isn't perfect is because this is based for images and animations. I forgot about *.hlp, *.wa2, *.bm2, etc files. Maybe you atleast get a good idea from this.

[L.C.]

http://www.hlrse.net/Qwerty/dcme_lvzgui.GIF

Heh. I realized this doesn't have too much to do with your tree. I tried to find a way to include the tree as I was first doing it, but got carried away by the creativity. Sorry.

 

DCME should be "saving" the data you enter for this LVZ on-the-go as you work. There really isn't any need for any OK, Apply, or Cancel buttons.

 

If you were to select one of the files under the box with the list of images, it would "bring the blue selector bar" down (instead of leaving a grey one on the last image you had selected). When you do that, it will basically "erase" (disappear) the content to the right of these lists and load another kind of list. Maybe this list could have things like "Comments" (useless), Play (for WA2/WAV/MP3 files), maybe some kind of rendering "preview" box for the *.hlp file, and perhaps a full blown preview box for images.

 

For images, there probably should be a "Locate" button at the bottom right corner of the window, underneath the preview box (and if you were to say that the button were inside the preview box, almost as if the preview box was a

in HTML, the button would be 'd right). This function would take you to wherever this image is used in the map in DCME.

[Samapico]

ObjectID is the # when you'll want to *objon # your image... I'm not sure if it can have ANY use if the mode isn't set to ServerControlled

and ImageID can't be over 255

 

Select which LVZ file you are working on with a drop-down list, or via treeview... I wonder which would be better... hmm... Treeview wouldn't be much of a treeview anymore with just the list of files in current lvz though...

 

Saving on-the-go... I dunno... Anyways, by putting a ok and cancel buttons, we can easily make the Enter key (or escape to cancel) close the dialog (hm, well we could still do it by setting them invisible perhaps)

 

Preview stuff would be good... for sound files too yeah I thought about that. However, mp3's aren't supported... However... I wonder how hard it would be to make a built-in mp3-to-wav >=) ... (DCME Plug-ins? )

[L.C.]

Select which LVZ file you are working on with a drop-down list, or via treeview... I wonder which would be better... hmm... Treeview wouldn't be much of a treeview anymore with just the list of files in current lvz though...

I inherited that kind of listing style from Valve Hammer Editor (map editor) for Half-life and mods. Personally, I feel more comfortable using this kind of interface (the drawing I made up). But that's me.

[Drake7707]

lemme find this pecular smiley

 

 

hmm aaah there it is or will apply here for me

 

I dunno, i usually make a pretty good GUI, but the lvz form really was something else this time.

It has to keep the overview of all packages, yet specify things when 1 is selected. It has to be compact for easy use, yet not too crowded to look between a forest of buttons. I thought the property list would be a good idea because thats how its used in elvl and i like (re)using stuff in all the same way.

[Samapico]

I'd go with that too if it wasn't for the fact that, for example, Image Definitions can be !@#$%^&*ociated with files from a different LVZ

[L.C.]

I'd go with that too if it wasn't for the fact that, for example, Image Definitions can be !@#$%^&*ociated with files from a different LVZ

You've confused me. What do you mean by "image definitions can be !@#$%^&*ociated with files from a different LVZ?" Well only the files from the LVZ you have selected will be shown (as you can see, LVZ File "Un!@#$%^&*led" is selected through that drop down list).

 

If you want to add a toggled ability to have all files from all !@#$%^&*ociated LVZ files shown in the list, you might have to have an unselectable entry to categorize like this in the list:

 

 

-------Un!@#$%^&*led1-------

File01.ext

File02.ext

File03.ext

 

-------Un!@#$%^&*led2-------

File01.ext

File02.ext

File03.ext

 

 

Saving on-the-go... I dunno... Anyways, by putting a ok and cancel buttons, we can easily make the Enter key (or escape to cancel) close the dialog (hm, well we could still do it by setting them invisible perhaps)

In Valve Hammer Editor, the way to close this window would be the [X] at the top right corner of the window. Not too hard to learn. I've seen some applications use this method before.

 

Maybe to the right of the "Locate" button a "Close" button to close the window, eh?

[Samapico]

I know a [X] isn't hard to learn ... But to look like the rest of the application, it will definitly have a Ok and Cancel buttons (and a [X] that would ask you if you want to save... or maybe just save)

 

And for the different lvz stuff...

 

Example:

 

In LVZ1, you put all your files

 

In LVZ2, you can define:

Image0=filefromlvz1.bmp

Image1=anotherfilefromlvz1.bmp

 

and then mapobjects/screenobjects using these Image# are defined in LVZ2 as well

 

This has a HUGE advantage cause if you make an update (move images and stuff), LVZ1 will not have to be redownloaded (unless you changed files completly), only the definitions in LVZ2 are re-downloaded by people, and LVZ2 will be like 10k if you have almost 1000 mapobjects defined

[Drake7707]

there could be a hovering image preview (when you mouse over the image) ?

[L.C.]

Ok and Cancel buttons (and a [X]that would ask you if you want to save... or maybe just save)

But why? I think that in this situation they're a bit unnecessary ("Close" removes the need for another button). The "on-the-go" process would really be "saving" data each time after you've editted an entry (or 1 field).

 

Maybe an Undo/Redo system for the LVZ could do it. Maybe you can split the Undo/Redo system into 3 compartments: Normal, eLVL (Regions), LVZ. That way you can control exactly what you're undoing or redoing.

 

 

This has a HUGE advantage cause if you make an update (move images and stuff), LVZ1 will not have to be redownloaded (unless you changed files completly), only the definitions in LVZ2 are re-downloaded by people, and LVZ2 will be like 10k if you have almost 1000 mapobjects defined

In this case, when you "Create" or "New" an LVZ, you will be asked whether it's a normal LVZ (or something) or a "Configurations" LVZ. Configurations and Normal might not be the best terms...I was thinking along the lines of Linear and Hybrid or something.

 

The user should be able to "color code" the LVZ files. A small box with a 1px black border should be rendered to the left of the LVZ name, and inside this box a fill color. Any color (user can choose during creation process?). The user should also be able to "link" LVZ files together (ie. link a "Configurations" and "Normal" together); when linked together, both would EITHER..

 

-Have the same color, and there would be a number from 1 to 255 (or whatever) inside the box over the color.

 

-Color doesn't matter, but both would have the same number inside the colored box.

 

-A black box, both would have same number (number MIGHT be colored for visual aide).

 

This could help as a way of (visual?) representing which LVZ files work with each other or something.

 

 

 

Of course besides "Normal," "Configuration," "Linear," "Hybrid," or whatever - there should be some way to directly look at how DCME is writing the *.ini file for the LVZ. The user should be able to manually edit ANY LVZ file at any time they wish.

[Drake7707]

a last comment for me today: don't forget about the 4mb filesize limit. Off to bed now

[Samapico]

Actually it would be much more complicated to change stuff on-the-go, programming-wise. It's easier to copy the whole LVZ stuff, modify it, then dump it back to map ; else we need to create methods for 'every' property. So it wouldn't change anything memory-wise. But u're right maybe a cancel isnt needed... anyways... thats a detail

 

hmm... no need to show 'links'... If user deletes a file that is used by one of the image definitions in any lvz, a warning would appear. Same if user deletes an image definition used by a map or screen object in the current lvz

 

technically there aren't any 'links'... it's just that files from every lvz's are somewhat 'shared'

 

And there won't be 2 types of lvz, it would be a frustrating limitation that doesn't exist (current LVZ format already has enough limitations as it is )

 

Thanks for all the ideas though... It definitly got my brain going... Gonna eat some, then I'll work on that

 

Anyways, it doesn't have to be perfect for the first release, as long as it's functional, it will be a great tool. It will be improved alot in the future... I have way too much features ideas in my mind for lvzs... I used to work with them alot, so there are alot of things that I wanted to do, but couldn't, or it was very complicated... Essentials are moving lvz's with tile / adjustable snap (CLT's tile snap was frustrating cause I needed a half-tile snap... I have that map that would be done by now if I had that... grr) , tile images on background , oh, and I wanted to use some kind of expression parser so you could write things like: 512*16 in the X or Y field and it would calculate it

 

As for manual ini editing, thats not a concern yet... It will probably be a possibility, mostly to build the lvz with other programs, but average user should never even see a .ini file... And in the actual lvz file, the "ini" data is not in text format, so we don't have to generate it for now

[Samapico]

either that... or... i'll do that tomorrow and play games for now... haven't played something for a long time now, so

[L.C.]

And there won't be 2 types of lvz, it would be a frustrating limitation that doesn't exist (current LVZ format already has enough limitations as it is )

I wasn't meaning file format. I was meaning it as a form of categorization (two different styles or purposes, uses maybe).

 

oh, and I wanted to use some kind of expression parser so you could write things like: 512*16 in the X or Y field and it would calculate it

You just gave me an idea. Maybe you could have loop functions - so for example:

Image1.gif is a 512x256 image. We want it to loop on its X axis.

512*16 could MAYBE stand for "loop this image 16 times on X axis." The first, top left image would be the "origin," which is where and how you can move this around. Maybe this can be placed under Flags as...

 

X-Axis Loop

Y-Axis Loop

 

If you check either one (or both), a grayed out field can become usable where you can define a specific number of times this loops that way or fills up the entire map or something.

 

I'm exhausted too. I'm going to go cause massive destruction in Oblivion or play Medieval II: Total War.

[Samapico]

I know you didnt mean file format... but still, a single lvz should be able to have both files and object definitions

 

as for the looping stuff, this would go in the tile background image... of course you don't have to tile it in the whole map... startx, starty, distancex, distancey, numberx, numbery, and poof

[Samapico]

so far...

 

got to fill in the property lists now, and make the preview functional

[L.C.]

That looks complicated. O.O