Keyboard control in editor
Moderators: Flumminator, Zomis
Keyboard control in editor
Let's say that your wireless mouse is out of battery and you don't want to use Mouse Keys in windows or any other mouse-helper.
Then why not have possibility to use the level editor with the keyboard?
Pressing Tab to move 1 tile left/right/up/down (or move mouse over the down-right controls or the right tile listbox)
Pressing down space button would correspond to pressing and holding left mouse button, and releasing space is like releasing the mouse button.
These was just examples Maybe they could be configured in the Setup?
And don't forget to add a keyboard button for middle and right mouse button
Then why not have possibility to use the level editor with the keyboard?
Pressing Tab to move 1 tile left/right/up/down (or move mouse over the down-right controls or the right tile listbox)
Pressing down space button would correspond to pressing and holding left mouse button, and releasing space is like releasing the mouse button.
These was just examples Maybe they could be configured in the Setup?
And don't forget to add a keyboard button for middle and right mouse button
Hmm, I'm also a bit confused about using the "Tab" key for moving the cursor in the playfield, and I think that using the cursor (arrow) keys for moving inside the playfield seems to be a lot more intuitive. And it wouldn't be slow, because it would of course not work pixel-wise, but for each time pressing a cursor key, the position in the level playfield would move one full tile.
And the usual "snap" and "drop" button could then indeed be the left/right mouse button, like Richard suggested.
Using the "Tab" key would probably best used to switch between the playfield, the elements selection box, and the toolbox buttons, where you then would navigate with the cursor keys.
And the usual "snap" and "drop" button could then indeed be the left/right mouse button, like Richard suggested.
Using the "Tab" key would probably best used to switch between the playfield, the elements selection box, and the toolbox buttons, where you then would navigate with the cursor keys.
Lol, now I see what I wrote...of course I meant Tab to switch between the playfield, selection box, and the toolbox button. I apologize to both Richard and Holger, and to those who read the post and thought I was an idiotHolger wrote:Hmm, I'm also a bit confused about using the "Tab" key for moving the cursor in the playfield, and I think that using the cursor (arrow) keys for moving inside the playfield seems to be a lot more intuitive. And it wouldn't be slow, because it would of course not work pixel-wise, but for each time pressing a cursor key, the position in the level playfield would move one full tile.
And the usual "snap" and "drop" button could then indeed be the left/right mouse button, like Richard suggested.
Using the "Tab" key would probably best used to switch between the playfield, the elements selection box, and the toolbox buttons, where you then would navigate with the cursor keys.
And now I also understand the use of those "snap" and "drop" buttons, but there is a middle button aswell, isn't it?
Again, I apologize for writing not what I meant earlier and because I misunderstood what Richard wrote
> And now I also understand the use of those "snap" and "drop" buttons, but there is a middle
> button aswell, isn't it?
Yeah, right... Although the editor (and the whole game) does not really depend on that middle mouse button. As a Unix user, I couldn't live without the third mouse button, but many Windows systems only have a two button mouse, which works also. (But I think that today's mice always have that scroll wheel, which also works as a middle mouse... But I don't like that wheel, although I've tried it. :-) )
But the middle mouse button would then get its own key, of course. ;-)
> button aswell, isn't it?
Yeah, right... Although the editor (and the whole game) does not really depend on that middle mouse button. As a Unix user, I couldn't live without the third mouse button, but many Windows systems only have a two button mouse, which works also. (But I think that today's mice always have that scroll wheel, which also works as a middle mouse... But I don't like that wheel, although I've tried it. :-) )
But the middle mouse button would then get its own key, of course. ;-)
The middle mouse button should not be a standart in a game. Not everybody has a third mouse button.
Oh by the way....... about the theme "shortcuts and buttons".... what is, if you could have shortcuts from 0 to 9 for placing elements ? I mean "hold cursor over an element (in the list) and click "1" for example. So the game notices, that the number "1" = A rock.
Now you could hold the cursor on the editor-playfield, and click the number "1" to insert that rock. And the same in the CE configurations (what would be an important point !).
...just an idea crossed my mind maybe implented if you have time...
BTW: That smiley seems a bit... weird.... ->
Oh by the way....... about the theme "shortcuts and buttons".... what is, if you could have shortcuts from 0 to 9 for placing elements ? I mean "hold cursor over an element (in the list) and click "1" for example. So the game notices, that the number "1" = A rock.
Now you could hold the cursor on the editor-playfield, and click the number "1" to insert that rock. And the same in the CE configurations (what would be an important point !).
...just an idea crossed my mind maybe implented if you have time...
BTW: That smiley seems a bit... weird.... ->
Having "element slots" and switch between them quickly by using key shortcuts could indeed be very useful, now that I think about it. Especially if you're building something that consists of a small number of elements (like the acid pool), you currently have to always re-select the elements you need next. This is easy if all of them are close together, but this may not be the case with CEs.
I'll think about some elegant solution. Suggestions and comments from other users are always welcome, though. :-)
I'll think about some elegant solution. Suggestions and comments from other users are always welcome, though. :-)
Last edited by Holger on Thu Oct 28, 2004 5:11 pm, edited 1 time in total.
-> but this may not be the case with CEs
Not the case with CEs ? Why ? I have many CEs (now for example) I construct a level...
Or if you mean, that it´s not the case _in_ a CE ? Now there is for example a counter CE. And other more-CE-elements (4 CEs for "1" element).
-> I'll think about some elegant solution. Suggestions and comments from other users are always welcome, though.
*cough* I have an idea... if we already speak about that theme... ;)
Maybe no shortcuts, but elements, you could insert into 12 or 10 (whatever) in a bottom menü (maybe by clicking the element on the list, and pushing it into the slot in the bottom menü).
Screenshot: (Sorry for it´s bigness !) :D
Not the case with CEs ? Why ? I have many CEs (now for example) I construct a level...
Or if you mean, that it´s not the case _in_ a CE ? Now there is for example a counter CE. And other more-CE-elements (4 CEs for "1" element).
-> I'll think about some elegant solution. Suggestions and comments from other users are always welcome, though.
*cough* I have an idea... if we already speak about that theme... ;)
Maybe no shortcuts, but elements, you could insert into 12 or 10 (whatever) in a bottom menü (maybe by clicking the element on the list, and pushing it into the slot in the bottom menü).
Screenshot: (Sorry for it´s bigness !) :D
> -> but this may not be the case with CEs
>
> Not the case with CEs ? Why ?
A misunderstanding: I meant, it could work without shortcuts, if the elements are close together in the elements list, but there may be a lot of CEs that you need more or less at the same time when building a level, so especially for CEs it might be very useful to have those shortcuts.
> Maybe no shortcuts, but elements, you could insert into 12 or 10 (whatever) in a bottom menü
> (maybe by clicking the element on the list, and pushing it into the slot in the bottom menü).
Well, although the solution you demonstrated with the screenshot would probably work just fine, you could already achive something similar by using the "editorsetup.conf" file (which I plan to modify in a way that you can have a different "editorsetup.conf" file for *each* level set). But it wouldn't be as flexible as the "on-the-fly" solution.
Well, lots of new ideas in one single thread, and not the worst ones... :-)
>
> Not the case with CEs ? Why ?
A misunderstanding: I meant, it could work without shortcuts, if the elements are close together in the elements list, but there may be a lot of CEs that you need more or less at the same time when building a level, so especially for CEs it might be very useful to have those shortcuts.
> Maybe no shortcuts, but elements, you could insert into 12 or 10 (whatever) in a bottom menü
> (maybe by clicking the element on the list, and pushing it into the slot in the bottom menü).
Well, although the solution you demonstrated with the screenshot would probably work just fine, you could already achive something similar by using the "editorsetup.conf" file (which I plan to modify in a way that you can have a different "editorsetup.conf" file for *each* level set). But it wouldn't be as flexible as the "on-the-fly" solution.
Well, lots of new ideas in one single thread, and not the worst ones... :-)
-> "editorsetup.conf" file for *each* level set
Yuhuuu ! :D
-> But it wouldn't be as flexible as the "on-the-fly" solution
No, but you could insert both things... So the user (who wants to make levels from an existing graphic set) could see which objects are needed and which to insert into the level (and which may fit into the graphic style)... and than set the elements (mostly CEs) in the slots at his left and use them there.
Or the graphic creator may disallow the level creator from inserting standart elements. Like an amoeba for example, maybe because it doesn´t have graphics.
Question: How much work is it with the slots at the right, and how much work with the editorsetups per levelset ? :)
Yuhuuu ! :D
-> But it wouldn't be as flexible as the "on-the-fly" solution
No, but you could insert both things... So the user (who wants to make levels from an existing graphic set) could see which objects are needed and which to insert into the level (and which may fit into the graphic style)... and than set the elements (mostly CEs) in the slots at his left and use them there.
Or the graphic creator may disallow the level creator from inserting standart elements. Like an amoeba for example, maybe because it doesn´t have graphics.
Question: How much work is it with the slots at the right, and how much work with the editorsetups per levelset ? :)