MegaPal

[Alan]

This is a huge idea, but I honestly think it will save people hours in editing time. I also believe it will give Holger piece of mind about adding more elements (not CEs, but new stuff like the steel alphabet and the new walls), without worrying about the palette.......

Seriously, most of my CE making time is spent navigating the bloody palette. The new jump keys (insert,del,home,end,pgup and pgdown) help a bit....but they don't help me with my memory. It's just too much tunnel vision since the palette is so small and it trips me up every time! You know what I mean....you have a flash of inspiration how to make a certain CE work.....you start making it....great, it works....need to give it a quick "uses graphic of", and I'm then totally de-railed because I forgot where the blue tubes are!

I do however have a very good memory when it comes to screen position (you want to see how fast I can change an element's properties, I'll blow your mind )

OK, this idea is bit mental, or is it?......I would find it very handy, would anybody else? How about a full screen sized palette which is toggled, and takes up ALL of the left side of the editor.

A picture paints a 1000 words....



As you can see we get all RnD and legacy elements in one page..(oh look I can see the blue tubes!)

There's not enough room for them all (hence the scroll bar on the right), but this could be spaced out, IE:- Page 1 is all the native elements, page 2+ are the custom,group and reference elements (has the same extendibility as the normal palette) You could even assign buttons for each group (BD,EM,CE+REF,User), there's room on the left for all of these buttons.

Bringing up the MegaPal is just a side bar button (or even better a hot key), and since it takes over the left side of the screen you can still use the element copy and paste functions. So how would it work? (I'd leave this one to Holger). Disappear when you click an element? Or stay until you tell it otherwise? Personally I'd use it to change a mouse brush, then disappear.

Anyway, the idea of the MegaPal is to remember where elements are by screen position. I only made this mock image a few minutes ago and I know that the blue tubes are in the middle of page 1, without looking

A big project I agree, but please think about this one Holger!




Another idea, customise the text tool....


How about changing what elements are printed when typing using the text tool? This could be placed in the editorsetup.conf like this:-

key_a: custom_12
key_s: steelwall
key_1: player_1

So instead of the usual abc you get your own elements....easy to add (I'm sure) but extremely powerful and handy. Imagine having a bevelled wall that uses about 9 elements (like BD2K3's walls), you could map these into a nice square on the keyboard...

(might look different on none UK keyboards) :-\

QWE
ASD
ZXC

These are the keys pressed to draw the edges and middle of a BD2K3 box. Handy because I don't even have to look at the keyboard to make one

[Daniel H.]

I like the idea of having a full screen sized palette.

[RTADash]

Me too, sounds awesome! All that scrolling up and down makes me dizzy after a while.

[Holger]

Very good idea, probably very useful! :-)

One question that comes to my mind is how the palette elements should be ordered. One solution is shown in your demonstration graphic and has the advantage that the bigger palette looks just like the normal palette put together to a bigger palette. But I think it is not yet consistent, because it wraps at the visible area, but not at the total vertical palette size. Wrapping around line by line would be another possibility, but would have the disadvantage that the big palette looks completely different.

Another question is how new elements should be handled. Imagine a new element somewhere at the start of the classic palette -- while this does only change a small portion of the classic palette, it would re-wrap the whole mega palette, forcing the user to learn again all element positions.

Any thoughts or ideas about these problems and questions by others?

[Davacardo]

Yes, finding a certain element can at times be annoying.
I would rather see a different grouping system where similiar elements are grouped together. As for CEs, I would like a 'drag and drop' system so you can place the CEs where you in the palette.

But, yes, a full screen palette display would be very useful.

[Zomis]

Very good idea, probably very useful!

One question that comes to my mind is how the palette elements should be ordered. One solution is shown in your demonstration graphic and has the advantage that the bigger palette looks just like the normal palette put together to a bigger palette. But I think it is not yet consistent, because it wraps at the visible area, but not at the total vertical palette size. Wrapping around line by line would be another possibility, but would have the disadvantage that the big palette looks completely different.

Another question is how new elements should be handled. Imagine a new element somewhere at the start of the classic palette -- while this does only change a small portion of the classic palette, it would re-wrap the whole mega palette, forcing the user to learn again all element positions.

Any thoughts or ideas about these problems and questions by others?

I think it's ok that it wraps at the visible area, maybe the palette could be divided into pages and not scrolling row-by-row, so that it's like
01 02 05 06
03 04 07 08
on page 1
and
09 10 13 14
11 12 15 16
on page 2

And I don't think learning all element positions again would be so painful. It's probably most often about just one row down that many elements will be moved. Their approx position remains the same (unless many new elements have been added, then they've moved more than one row down), and would still be easy to find the new position for it.

[Holger]

> I would rather see a different grouping system where similiar elements are
> grouped together.

You're perfectly right -- this is something I wanted to add long ago. :-o

The current element structure in the palette is highly inspired by the various game types that are included in R'n'D, like BD (Boulder Dash), EM (Emerald Mine) or SP (Supaplex). For those who know these classic games, the current structure may be useful and logical. For all others it is simply confusing.

Therefore, I want to have a switch in the editor section of the setup menu to select between "elements ordered by [game / type]", where "game" is the current element order, and "type" would be an order by, well, element type. So, as a result, the current sections "BD", "EM", "EMC" etc. could be optionally replaced by new sections "DIGGABLE", "COLLECTIBLE", "WALKABLE", "DESTRUCTIBLE", "INDESTRUCTIBLE", "MONSTER", "FRIEND" (or something like that, with abbreviations still to be defined).

> As for CEs, I would like a 'drag and drop' system so you can place the CEs
> where you in the palette.

This would indeed be nice, yes. Until that, the user defined element palette section ("MY") could be used for this purpose, defined in the file "editorsetup.conf" by adding the element tokens line by line, putting the resulting file into the level directory of the level set to edit.

[Zomis]

Therefore, I want to have a switch in the editor section of the setup menu to select between "elements ordered by [game / type]", where "game" is the current element order, and "type" would be an order by, well, element type. So, as a result, the current sections "BD", "EM", "EMC" etc. could be optionally replaced by new sections "DIGGABLE", "COLLECTIBLE", "WALKABLE", "DESTRUCTIBLE", "INDESTRUCTIBLE", "MONSTER", "FRIEND" (or something like that, with abbreviations still to be defined).

Those things remind me of the definition arrays in init.c...
ep_collectible and all those. Maybe one group for each?
And why choose either game grouping or function grouping? Why not in Setup -> Editor make one option for each (SP, BD, etc. and Walkable, collectible, destructible, etc...)

[Holger]

> Those things remind me of the definition arrays in init.c...
> ep_collectible and all those. Maybe one group for each?

This would be a possible solution, yes. A possible disadvantage would be that many of these groups contain the same elements, which could make things bloated and confusing.

> And why choose either game grouping or function grouping? Why not in
> Setup -> Editor make one option for each (SP, BD, etc. and Walkable,
> collectible, destructible, etc...)

Yes, this would probably be even better, so you could have both kinds of sorting/presentation of game elements.