Hi, is there a way to change (on the fly) between 2 kinds of text elements? That is, having hit the 'A' (Enter Text Elements) button on the palette, and typing using the keyboard.
I think that the Enter Text Elements feature uses the set of text elements that were last used, which is good, but I would like to be able to easily enter a mixture of the 2 kinds. (Because RnD doesn't offer cases for letters, and I use these 2 sets with normal representing lowercase and steel representing upper case. So I want to be able to mix.)
For some things, eg pipes, there is extra/different functionality available by holding down Shift, but that doesn't seem to be the case with text elements. I imagine holding down Shift could be used to enter the steel text elements, or maybe opposite to whichever one was being added? - so Shift would function as a toggle button.
Sorry I should have put this into New Features.
BTW, I wanted to search in the forum on "text elements" in case someone had discussed this, but the search finds pages where either word is present but not adjacent in the form in the double quotes. I have clicked on the gearwheel and used the advanced search, which defaults to 'Search for all terms or use query as entered'.
Does anyone know how to do this?
Changing between 2 kinds of text elements
Moderators: Flumminator, Zomis
Re: Changing between 2 kinds of text elements
Using the "Shift" key to change between steel and non-steel text elements seems to be a good idea indeed, and would make using a graphics set that has upper and lower case characters instead of normal and steel characters very easy. 
And it should be easy to implement.
And it should be easy to implement.
Re: Changing between 2 kinds of text elements
Just added this feature! Works like a charm!
-
TheOnyxGuy
- Posts: 647
- Joined: Wed Oct 30, 2013 5:32 am
- Location: Russia
- Contact:
Re: Changing between 2 kinds of text elements
Pretty sure when you have one of steel chars in the left slot the game types in steel chars, but that idea works too
Previously known as Eizzoux (boooo)
Re: Changing between 2 kinds of text elements
Thanks Eizzoux for your clarification.
Thanks Holger for making the change, I am especially interested in enhancements to the editor. In that vein, I will co-opt this post to mention a couple more ideas
Please could you make these enhancements:
#1
When the 'Enter Text Elements' button is active, could the arrow keys move the cursor, rather like how the Enter key does now, except the arrow keys would move the cursor one cell at a time, in the appropriate direction.
This would have a side-benefit, being that when the right arrow key is hit, it could be an alternative to hitting the Space key, which (when in 'Enter Text Elements' mode) overwrites the existing cell with the Space text element. Thus you could easily create a mixture of text elements and non-text elements, which would be more fun, because both the player and monsters could easily get amongst the text elements, unlike now, when they form a monolithic 'wall'.
#2
when in 'Enter Text Elements' mode, if the player hits Ctrl+V, and there is text on the Clipboard (from another program), could this be automatically mapped to text elements, and written to the grid.
I can see a few complications, but I think there could be simple workarounds:
- would only work with ASCII.
- some characters are not implemented in ASCII, eg the pipe character. A workaround would be to map any such character to one of the text elements that has no matching character, eg the button text element. Really I don't see this as important - just do 'whatever it takes' to get the transfer of text into the level, working.
- how to handle case of letters? Well, in the manner agreed on already, that is to map lowercase letters to ordinary text elements, and uppercase letters to steel text elements. But, this is ambiguous for handling of numbers and punctuation marks. So make it more sophisticated by checking the 'last set of text elements used', maybe as per Eizzoux's statement that "when you have one of steel chars in the left slot the game types in steel chars";
ie in that case default to pasting in steel text elements, and use ordinary text elements for uppercase.
I know this sounds fiddly/wishy-washy, but I am aiming for a good level of flexibility and user control.
#3
Yesterday, I noticed that after having copied a range using the Scissors,
hitting Ctrl+Z rotates the copied range;
but it also undoes changes made. This spoils the otherwise useful feature of being able to rotate the copied range, which I would like to start using, a lot.
So, is there a way of rotating a copied range without affecting anything else, and if not, could there please be?
Likewise, maybe Ctrl+Z needs to be tidied up, in the edge case of there being a copy of a part of the grid, floating around?
#4
Please could there be a way of rotating the entire level? - i.e. similar to rotating a copied block, but for the entire level? In the simplest implementation, this would require swapping the dimensions of the level (if the level is non-square), but it could also be done without changing the dimensions of the level, and just affecting the sub-region of the level which matches the shape of the rotated block, reduced to whatever will fit. The program could ask the user if he/she wants to auto-swap the dimensions of the level.
With these suggestions, I think there can't be any harm in implementing them, even if they need enhancing later, as they only affect the grid and placed elements at the time of entering/changing, and don't have any effect upon file format etc.
Holger, if you were willing to implement one of these changes, I'd be delighted, 2, 3 or all 4 of them, I'd be over the moon
John
Thanks Holger for making the change, I am especially interested in enhancements to the editor. In that vein, I will co-opt this post to mention a couple more ideas
Please could you make these enhancements:
#1
When the 'Enter Text Elements' button is active, could the arrow keys move the cursor, rather like how the Enter key does now, except the arrow keys would move the cursor one cell at a time, in the appropriate direction.
This would have a side-benefit, being that when the right arrow key is hit, it could be an alternative to hitting the Space key, which (when in 'Enter Text Elements' mode) overwrites the existing cell with the Space text element. Thus you could easily create a mixture of text elements and non-text elements, which would be more fun, because both the player and monsters could easily get amongst the text elements, unlike now, when they form a monolithic 'wall'.
#2
when in 'Enter Text Elements' mode, if the player hits Ctrl+V, and there is text on the Clipboard (from another program), could this be automatically mapped to text elements, and written to the grid.
I can see a few complications, but I think there could be simple workarounds:
- would only work with ASCII.
- some characters are not implemented in ASCII, eg the pipe character. A workaround would be to map any such character to one of the text elements that has no matching character, eg the button text element. Really I don't see this as important - just do 'whatever it takes' to get the transfer of text into the level, working.
- how to handle case of letters? Well, in the manner agreed on already, that is to map lowercase letters to ordinary text elements, and uppercase letters to steel text elements. But, this is ambiguous for handling of numbers and punctuation marks. So make it more sophisticated by checking the 'last set of text elements used', maybe as per Eizzoux's statement that "when you have one of steel chars in the left slot the game types in steel chars";
ie in that case default to pasting in steel text elements, and use ordinary text elements for uppercase.
I know this sounds fiddly/wishy-washy, but I am aiming for a good level of flexibility and user control.
#3
Yesterday, I noticed that after having copied a range using the Scissors,
hitting Ctrl+Z rotates the copied range;
but it also undoes changes made. This spoils the otherwise useful feature of being able to rotate the copied range, which I would like to start using, a lot.
So, is there a way of rotating a copied range without affecting anything else, and if not, could there please be?
Likewise, maybe Ctrl+Z needs to be tidied up, in the edge case of there being a copy of a part of the grid, floating around?
#4
Please could there be a way of rotating the entire level? - i.e. similar to rotating a copied block, but for the entire level? In the simplest implementation, this would require swapping the dimensions of the level (if the level is non-square), but it could also be done without changing the dimensions of the level, and just affecting the sub-region of the level which matches the shape of the rotated block, reduced to whatever will fit. The program could ask the user if he/she wants to auto-swap the dimensions of the level.
With these suggestions, I think there can't be any harm in implementing them, even if they need enhancing later, as they only affect the grid and placed elements at the time of entering/changing, and don't have any effect upon file format etc.
Holger, if you were willing to implement one of these changes, I'd be delighted, 2, 3 or all 4 of them, I'd be over the moon
John
Re: Changing between 2 kinds of text elements
Once I get posting with ideas/requests, I find it hard to stop, even straight after making a post or reply.
#1
In my post just now, I forgot to describe how pasting from the Clipboard should wrap.
I think the program must track the starting column, in order to do the wrapping when the user types Enter. So we could just use this.
Caveat: I just want to make sure that if the user types some text:
eg
12345678
90
[using numbers to make it clear the column numbers]
and then pastes from another application, "the rain in Spain",
the outcome should be
12345678
90the ra
in Spain
as opposed to
12345678
90the ra
XXin Spa
XXin
[where X represents a cell as it was prior to these changes].
- rotation of the entire level would apply when no block has been selected with the Grab brush.
#2
I would like to ask for a Cut mode, as opposed to the Copy feature that the Grab brush currently offers;
not instead of, but as well.
This would allow editing an existing level by a kind of drag and drop, which would be a lot more intuitive and quick and enabling than trying to do that now.
The complex bit is, what should the cut cells be replaced with?
At the simplest level, just Space;
or could get a bit more complex, and 'blend in' from the surrounding elements,
eg if the block is bordered by Sand, replace with Sand,
if Grass, replace with Grass,
etc.
I don't mind, I wouldn't want that aspect to impede implementing a Cut feature.
This ties in with the next idea:
#3
I hope I don't offend saying this, but it is amazing how much of the palette is taken up by Wrap buttons.
So, implement a Shift key modifier on the action for the Wrap buttons;
-- reduce the number of Wrap buttons to 2;
I would suggest Right and Down.
Now, use Shift to provide the other 2 directions for Wrap;
this frees up 2 button spaces for other features:
--- 1) the Rotate block/level feature I asked for in my last post;
--- 2) Cut cells, vs the Copy feature [i.e. Grab brush]
#4
Even with repurposing two of the existing buttons,
there are still lots of buttons I would love to see oneday, for example:
- 'Hover mode' for inspecting cells; i.e. when this is enabled, don't need to hold down Control button in order to get the element's name in the lower left of the app window.
-- This is, I would argue, necessary for the game to function properly on a smartphone, where there is no Control key.
--- and yes I know the argument that no-one should be editing levels on a smartphone, but respectfully I don't agree with that.
- Replace one kind of element with another
- Convert all instances of a Group Element into the elements specified within the GE
[a kind of Replace, or Random Element Placement, depending on how you implement it].
Thanks again, and I promise to ask for no more things, for a while at least.
John
#1
In my post just now, I forgot to describe how pasting from the Clipboard should wrap.
I think the program must track the starting column, in order to do the wrapping when the user types Enter. So we could just use this.
Caveat: I just want to make sure that if the user types some text:
eg
12345678
90
[using numbers to make it clear the column numbers]
and then pastes from another application, "the rain in Spain",
the outcome should be
12345678
90the ra
in Spain
as opposed to
12345678
90the ra
XXin Spa
XXin
[where X represents a cell as it was prior to these changes].
- rotation of the entire level would apply when no block has been selected with the Grab brush.
#2
I would like to ask for a Cut mode, as opposed to the Copy feature that the Grab brush currently offers;
not instead of, but as well.
This would allow editing an existing level by a kind of drag and drop, which would be a lot more intuitive and quick and enabling than trying to do that now.
The complex bit is, what should the cut cells be replaced with?
At the simplest level, just Space;
or could get a bit more complex, and 'blend in' from the surrounding elements,
eg if the block is bordered by Sand, replace with Sand,
if Grass, replace with Grass,
etc.
I don't mind, I wouldn't want that aspect to impede implementing a Cut feature.
This ties in with the next idea:
#3
I hope I don't offend saying this, but it is amazing how much of the palette is taken up by Wrap buttons.
So, implement a Shift key modifier on the action for the Wrap buttons;
-- reduce the number of Wrap buttons to 2;
I would suggest Right and Down.
Now, use Shift to provide the other 2 directions for Wrap;
this frees up 2 button spaces for other features:
--- 1) the Rotate block/level feature I asked for in my last post;
--- 2) Cut cells, vs the Copy feature [i.e. Grab brush]
#4
Even with repurposing two of the existing buttons,
there are still lots of buttons I would love to see oneday, for example:
- 'Hover mode' for inspecting cells; i.e. when this is enabled, don't need to hold down Control button in order to get the element's name in the lower left of the app window.
-- This is, I would argue, necessary for the game to function properly on a smartphone, where there is no Control key.
--- and yes I know the argument that no-one should be editing levels on a smartphone, but respectfully I don't agree with that.
- Replace one kind of element with another
- Convert all instances of a Group Element into the elements specified within the GE
[a kind of Replace, or Random Element Placement, depending on how you implement it].
Thanks again, and I promise to ask for no more things, for a while at least.
John
Re: Changing between 2 kinds of text elements
This all sounds like good fun :)
For text-paste, I guess it should truncate large pastes (maybe 100 chars? And maybe with that limit tunable...) I've copy-pasted 1MB+ texts on my Linux desktop, would not really like to see what that would do in RnD level editor...
For text-paste, I guess it should truncate large pastes (maybe 100 chars? And maybe with that limit tunable...) I've copy-pasted 1MB+ texts on my Linux desktop, would not really like to see what that would do in RnD level editor...
Re: Changing between 2 kinds of text elements
Yes, that's a good point. I would say that the way Enter Text Elements mode works now, would guide how this feature would work:
- text entry proceeds right-wards from starting point, until it hits the end of the screen or the user hits Enter;
-- then it wraps to the next line.
- each line is filled or exited,
and wrapping happens,
until we reach the last row visible on the screen. At that point, no matter what you type, nothing else happens.
So I would expect the paste-from-clipboard to behave the same way.
BTW, Holger when I am in Enter Text Elements mode and hold down the U key,
it works normally [= enters the U text element] until it reaches the last cell in the window,
then it treats it as a Ctrl+U, or Undo, and undoes the changes made, and says the Undo buffer is empty. A bug?
John
- text entry proceeds right-wards from starting point, until it hits the end of the screen or the user hits Enter;
-- then it wraps to the next line.
- each line is filled or exited,
and wrapping happens,
until we reach the last row visible on the screen. At that point, no matter what you type, nothing else happens.
So I would expect the paste-from-clipboard to behave the same way.
BTW, Holger when I am in Enter Text Elements mode and hold down the U key,
it works normally [= enters the U text element] until it reaches the last cell in the window,
then it treats it as a Ctrl+U, or Undo, and undoes the changes made, and says the Undo buffer is empty. A bug?
John
Re: Changing between 2 kinds of text elements
Been rereading my own posts [in the hope of finding a reply from Holger] and have found one or two mistakes which might cause confusion.
eg when I typed "some characters are not implemented in ASCII, eg the pipe character."
I made a mistake, what I should have typed was
"some characters are not implemented in Rocks'n'Diamonds, eg the pipe character."
So that is why I was suggesting co-opting couple of the RnD text elements that have no obvious correspondence to anything in ASCII, eg
- button
- cursor.
eg when I typed "some characters are not implemented in ASCII, eg the pipe character."
I made a mistake, what I should have typed was
"some characters are not implemented in Rocks'n'Diamonds, eg the pipe character."
So that is why I was suggesting co-opting couple of the RnD text elements that have no obvious correspondence to anything in ASCII, eg
- button
- cursor.
Re: Changing between 2 kinds of text elements
Hi, there are quite some good points among your ideas and suggestions!
Let's have a closer look at some of them:
I had the feeling that this feature would be incomplete without support for text input and text area gadgets (like the "level name" and "level author" text input fields, or the "envelope" text area fields), so I also added support for "Ctrl-v" for these two gadget types.
Then, again this felt incomplete without support for "Ctrl-c" and "Ctrl-x", so I added those, too. So you can just click into text input or text area gadgets now, press "Ctrl-c", and have the text content of the active gadget copied into the clipboard (ready to be pasted somewhere else, including other text gadgets in R'n'D). When using "Ctrl-x", the text gadget is cleared after copying its contents. (These two key shortcuts do not work with text elements in the playfield, as they are already used to copy brushes as brush sketches into the clipboard, to be used for brush sketches for the R'n'D web forum.)
Regarding case, "Ctrl-v" (when used in the playfield) currently only supports pasting the complete text as either normal wall or steel wall (when using "Ctrl-Shift-v"), but currently does not differentiate between upper and lower case text in the clipboard, as this is a special use case which is currently only supported when directly typing text into the playfield.
Now, "z" rotates a brush, while "Ctrl-z" acts as "undo", as it should be.
However, there is a workaround, if you need this from time to time:
- zoom out to see the whole level
- select the whole level with the "select brush" tool
- rotate the brush using the "z" key as desired
- press "Ctrl-c" to copy the brush into the clipboard
- select any other drawing tool (like the default "single items" tool)
- press "Ctrl-v" to copy the brush in the clipboard into the playfield
- this even adjusts the playfield dimensions accordingly, if needed
That's it!
- select brush with left mouse button => normal behaviour (copy)
- select brush with middle or right mouse button => replace area with drawing element 2 or 3
By default, this is "space" and "sand", but you can select any other element you like to fill the selected areas with, of course.
- select the "CONF" button
- select the "Editor" tab
- set "random element placement" to "percentage"
- set value to "100" (percent)
- restrict random placement to the element you want to replace with another element
- use the "random element placement" () tool to replace all defined elements on the playfield with the current drawing element
That's it!
This happens because currently text input mode ends when reaching the bottom right playfield corner, then using "u" as the key shortcut for "undo"!
Something similar happens when holding down the "enter" key, causing the editor going into play test mode after reaching the bottom border.
I have changed this in both cases not to leave text input mode, but staying in input mode with the cursor at the bottom border or bottom-right playfield corner. This seems to work better, and prevents unexpected behaviour due to repeated key input for keys held pressed down.
I hope you will all like these new features (which will be available with the next R'n'D release version).
Let's have a closer look at some of them:
I have added this feature, which is really useful.When the 'Enter Text Elements' button is active, could the arrow keys move the cursor, rather like how the Enter key does now, except the arrow keys would move the cursor one cell at a time, in the appropriate direction.
The new feature works as described above.This would have a side-benefit, being that when the right arrow key is hit, it could be an alternative to hitting the Space key, which (when in 'Enter Text Elements' mode) overwrites the existing cell with the Space text element. Thus you could easily create a mixture of text elements and non-text elements, which would be more fun, because both the player and monsters could easily get amongst the text elements, unlike now, when they form a monolithic 'wall'.
Very useful -- added now.when in 'Enter Text Elements' mode, if the player hits Ctrl+V, and there is text on the Clipboard (from another program), could this be automatically mapped to text elements, and written to the grid.
I had the feeling that this feature would be incomplete without support for text input and text area gadgets (like the "level name" and "level author" text input fields, or the "envelope" text area fields), so I also added support for "Ctrl-v" for these two gadget types.
Then, again this felt incomplete without support for "Ctrl-c" and "Ctrl-x", so I added those, too. So you can just click into text input or text area gadgets now, press "Ctrl-c", and have the text content of the active gadget copied into the clipboard (ready to be pasted somewhere else, including other text gadgets in R'n'D). When using "Ctrl-x", the text gadget is cleared after copying its contents. (These two key shortcuts do not work with text elements in the playfield, as they are already used to copy brushes as brush sketches into the clipboard, to be used for brush sketches for the R'n'D web forum.)
Regarding case, "Ctrl-v" (when used in the playfield) currently only supports pasting the complete text as either normal wall or steel wall (when using "Ctrl-Shift-v"), but currently does not differentiate between upper and lower case text in the clipboard, as this is a special use case which is currently only supported when directly typing text into the playfield.
This is a bug I have fixed now -- thanks for reporting this problem!Yesterday, I noticed that after having copied a range using the Scissors,
hitting Ctrl+Z rotates the copied range;
but it also undoes changes made. This spoils the otherwise useful feature of being able to rotate the copied range, which I would like to start using, a lot.
So, is there a way of rotating a copied range without affecting anything else, and if not, could there please be?
Now, "z" rotates a brush, while "Ctrl-z" acts as "undo", as it should be.
This is currently not implemented. And I think it won't be needed very often (just like the "clear" button is probably not needed very often, as I have to say).Please could there be a way of rotating the entire level?
However, there is a workaround, if you need this from time to time:
- zoom out to see the whole level
- select the whole level with the "select brush" tool
- rotate the brush using the "z" key as desired
- press "Ctrl-c" to copy the brush into the clipboard
- select any other drawing tool (like the default "single items" tool)
- press "Ctrl-v" to copy the brush in the clipboard into the playfield
- this even adjusts the playfield dimensions accordingly, if needed
That's it!
Yes, it works that way.the outcome should be
Code: Select all
12345678 90the ra in Spain
Rotating the whole level just by accidently pressing the "z" key seems to be a bit too unexpected to me, so I haven't added this. Better use the workaround above.- rotation of the entire level would apply when no block has been selected with the Grab brush.
This is already implemented. Use it as follows:I would like to ask for a Cut mode, as opposed to the Copy feature that the Grab brush currently offers;
not instead of, but as well.
This would allow editing an existing level by a kind of drag and drop, which would be a lot more intuitive and quick and enabling than trying to do that now.
The complex bit is, what should the cut cells be replaced with?
At the simplest level, just Space;
- select brush with left mouse button => normal behaviour (copy)
- select brush with middle or right mouse button => replace area with drawing element 2 or 3
By default, this is "space" and "sand", but you can select any other element you like to fill the selected areas with, of course.
No offense at all, but I think I do not like this.I hope I don't offend saying this, but it is amazing how much of the palette is taken up by Wrap buttons.
So, implement a Shift key modifier on the action for the Wrap buttons;
-- reduce the number of Wrap buttons to 2;
Already there: Just use the "pick element" tool.- 'Hover mode' for inspecting cells; i.e. when this is enabled, don't need to hold down Control button in order to get the element's name in the lower left of the app window.
A bit special, but this can already be done using the "random placement" tool:- Replace one kind of element with another
- select the "CONF" button
- select the "Editor" tab
- set "random element placement" to "percentage"
- set value to "100" (percent)
- restrict random placement to the element you want to replace with another element
- use the "random element placement" () tool to replace all defined elements on the playfield with the current drawing element
That's it!
Interesting idea! Haven't thought about that one very much so far...- Convert all instances of a Group Element into the elements specified within the GE
Pasting the clipboard content just stops when it reaches the bottom right playfield corner.For text-paste, I guess it should truncate large pastes (maybe 100 chars? And maybe with that limit tunable...) I've copy-pasted 1MB+ texts on my Linux desktop, would not really like to see what that would do in RnD level editor...
Yes, that's how it works now.- text entry proceeds right-wards from starting point, until it hits the end of the screen or the user hits Enter;
-- then it wraps to the next line.
- each line is filled or exited,
and wrapping happens,
until we reach the last row visible on the screen. At that point, no matter what you type, nothing else happens.
Definitely a bug!BTW, Holger when I am in Enter Text Elements mode and hold down the U key,
it works normally [= enters the U text element] until it reaches the last cell in the window,
then it treats it as a Ctrl+U, or Undo, and undoes the changes made, and says the Undo buffer is empty. A bug?
This happens because currently text input mode ends when reaching the bottom right playfield corner, then using "u" as the key shortcut for "undo"!
Something similar happens when holding down the "enter" key, causing the editor going into play test mode after reaching the bottom border.
I have changed this in both cases not to leave text input mode, but staying in input mode with the cursor at the bottom border or bottom-right playfield corner. This seems to work better, and prevents unexpected behaviour due to repeated key input for keys held pressed down.
I hope you will all like these new features (which will be available with the next R'n'D release version).
Re: Changing between 2 kinds of text elements
Fantastic news, I am thrilled. I was pleased to get the BDX engine, but I am even more pleased about this - I suppose, because IMHO it represents a big upgrade to part of the application which is above the level of game engines, and especially enhances the RnD engine (because of being the only engine that supports both sets of text elements).
I should really wait to reply in detail until the new version comes out. On the other hand... a few quick thoughts:
Text from clipboard:
In the future, after I download the new version, I will see what happens if the clipboard contains certain key characters:
- backquote
- tilde
- pipe
I guess they will be stripped, but I would still vote for mapping to any of: degree, cursor, button, TM sign.
- I guess this would seem a bit arbitrary to be comfortable, but I do think that would be preferable to an 'arbitrarily stripped' string.
Would the presence of extended chars (code > 126) in the string on the Clipboard,
a) lead to them being omitted, and non-extended chars (code between 32 and 126) after them being pasted without interruption?
b) or with gaps in the in-level output, i.e. skip [= leave unchanged] the corresponding cell?
c) or do nothing, i.e. don't paste anything at all?
Or course I would vote for b), or at a pinch, a). Option c) offers fewer possibilities.
'support for "Ctrl-c" and "Ctrl-x"' - yay!
'These two key shortcuts do not work with text elements in the playfield, as they are already used to copy brushes as brush sketches into the clipboard, to be used for brush sketches for the R'n'D web forum.'
- wah
TBH I can't imagine how this would work, and I do get that the shortcuts are already used for existing features. But maybe I do not properly understand the existing features? I use Ctrl+C and Ctrl+V a lot, with and without the Grab brush. But I do not use Ctrl+X. When I try it on an existing Grab brush selection, it seems to flip the cells in the selection vertically, and not do anything else? - It doesn't seem to copy to the Clipboard.
Ctrl+Shift+C seems to behave the same as Ctrl+C.
Could Ctrl+Shift+C be repurposed/specialised to do 'text element-style copying'?
eg, instead of copying like this:
it could copy like this:
abba---
agnetha
frida--
bjorn--
where - represents a non-text element;
obviously - is actually the text element 'char_minus',
but it could be something non-confusable,
eg,
since RnD doesn't include the backquote,
use the backquote:
abba``
agnetha
frida``
bjorn``
Although I find backquote annoying to use as I have to hit the key twice to be able to enter it, so maybe tilde would be better:
abba~~
agnetha
frida~~
bjorn~~
p.s. Apologies to Benny!
Or even (getting pretty wild here)
Output an 'all elements' representation,
e.g.
abbaff
agnetha
fridabb
bjornbb
Where the f at the end of line 1,
and the b at the ends of lines 3 and 4,
are obtained from the first letters of the descriptions of the elements: 'butterfly (starts...)' and 'firefly (starts...)'
This probably seems arbitrary and flakey. I chose the description rather than the ele,ment name, because the latter is often prefixed by the game engine or source game, in abbreviated form.
Or, now I think about it,
rather than one-character-per-element representation,
what would be better would be a multiple-characters-per-element representation, hence delimited'
it could be like the current representation, but with text instead of numbers;
except for the text elements, where it could be single letter;
hence with the example above:
`a`b`b`a`firefly`firefly
`a`g`n`e`t`h`a
`f`r`i`d`a`butterfly`butterfly
`b`j`o`r`n`butterfly`butterfly
Above is a simplified example, as there are many elements corresponding to firefly,
but each of them could be handled, if the entire description was output.
Above looks ugly, but in Excel or Calc or Sheets you could easily break above into a 2-D array, with the description of each element in its cell.
Even if the text elements were treated just like any other element, it would be easy to extract the letter from the description, in Sheets etc, or with regex.
Although above seems easy and good to me, the problem would be getting it back to R'n'D;
I suppose it would lead to a need for R'n'D to be able to parse input like the output above. It would be vulnerable to mistypes, but quite robust to say dragging the cells around in Sheets, maybe doing some Replace actions, and then copying the amended structure and pasting back into R'n'D.
And most importantly to me, the output/input is human-readable, and so in a sense, superior to the strings-of-delimited-numbers format. Definitely inferior in other ways of course; I figure that R'n'D manages an array of numbers, rather than of strings, for reasons of performance
'Regarding case, "Ctrl-v" (when used in the playfield) currently only supports pasting the complete text as either normal wall or steel wall (when using "Ctrl-Shift-v"), but currently does not differentiate between upper and lower case text in the clipboard, as this is a special use case which is currently only supported when directly typing text into the playfield.'
- Fair enough, but I hope that oneday it could do it, if only to prevent an increase in entropy
'- select brush with middle or right mouse button => replace area with drawing element 2 or 3'
-- maybe this doesn't work using a laptop touchpad? My touchpad is configured to treat a two-finger tap as right-click, and that works for me in the text editor I am typing this message into. But when I two-finger tap on the brush icon, it is selected, but when I then select a rectangle of cells in the level, the range is copied to the Grab brush 'outlined box', but NOT replaced with sand or space, or when I click elsewhere in the level; the range is always copied, never copied-plus-overwritten.
In fact, I think I have caused a bug, which is somehow I got R'n'D to start pasting in some other element:
(only the '927 part)
which is MM_wooden_wall.
I don't know how I did that, although I did have the MM engine chosen at some point; currently on RND engine, and have been for some time.
'- 'Hover mode' for inspecting cells; i.e. when this is enabled, don't need to hold down Control button in order to get the element's name in the lower left of the app window.
Already there: Just use the "pick element" tool.'
This works fine on my Windows PC, but not at all on my Android phone. I realize that you cannot hover on Android, like you can with a mouse pointer, so this request needs amending. Maybe in Android, a way of arrowing across the level, like arrowing around on a spreadsheet using the arrow keys on a keyboard, only using virtual buttons, like for game play, but for designing? But I understand and sympathise with your view that isn't value in supporting editing levels on Android.
So, I will do a volte face and suggest, having a moving cursor for editing levels (in Windows/Apple/Linux);
currently, hitting the arrow keys pans the level;
let it be like in text mode,
a cursor that can be moved, and hit Enter to wrap it back to the start of the next line,
and the user can hit the Space key, say, to enter the drawing element 1,
and hit the Space key again to enter the drawing element 2,
and hit the Space key again to enter the drawing element 3,
and hit the Space key again to revert to the element that was there pre-edit,
and so on.
The screen/level-panning could still happen, maybe trying to keep the cursor near the middle of the screen, as much as possible.
I feel like I am being overly demanding typing all this, but it is to be expected, I guess, that new possibilities invoke ideas for further new possibilities, and so on.
Thanks again
John
I should really wait to reply in detail until the new version comes out. On the other hand... a few quick thoughts:
Text from clipboard:
In the future, after I download the new version, I will see what happens if the clipboard contains certain key characters:
- backquote
- tilde
- pipe
I guess they will be stripped, but I would still vote for mapping to any of: degree, cursor, button, TM sign.
- I guess this would seem a bit arbitrary to be comfortable, but I do think that would be preferable to an 'arbitrarily stripped' string.
Would the presence of extended chars (code > 126) in the string on the Clipboard,
a) lead to them being omitted, and non-extended chars (code between 32 and 126) after them being pasted without interruption?
b) or with gaps in the in-level output, i.e. skip [= leave unchanged] the corresponding cell?
c) or do nothing, i.e. don't paste anything at all?
Or course I would vote for b), or at a pinch, a). Option c) offers fewer possibilities.
'support for "Ctrl-c" and "Ctrl-x"' - yay!
'These two key shortcuts do not work with text elements in the playfield, as they are already used to copy brushes as brush sketches into the clipboard, to be used for brush sketches for the R'n'D web forum.'
- wah
TBH I can't imagine how this would work, and I do get that the shortcuts are already used for existing features. But maybe I do not properly understand the existing features? I use Ctrl+C and Ctrl+V a lot, with and without the Grab brush. But I do not use Ctrl+X. When I try it on an existing Grab brush selection, it seems to flip the cells in the selection vertically, and not do anything else? - It doesn't seem to copy to the Clipboard.
Ctrl+Shift+C seems to behave the same as Ctrl+C.
Could Ctrl+Shift+C be repurposed/specialised to do 'text element-style copying'?
eg, instead of copying like this:
it could copy like this:
abba---
agnetha
frida--
bjorn--
where - represents a non-text element;
obviously - is actually the text element 'char_minus',
but it could be something non-confusable,
eg,
since RnD doesn't include the backquote,
use the backquote:
abba``
agnetha
frida``
bjorn``
Although I find backquote annoying to use as I have to hit the key twice to be able to enter it, so maybe tilde would be better:
abba~~
agnetha
frida~~
bjorn~~
p.s. Apologies to Benny!
Or even (getting pretty wild here)
Output an 'all elements' representation,
e.g.
abbaff
agnetha
fridabb
bjornbb
Where the f at the end of line 1,
and the b at the ends of lines 3 and 4,
are obtained from the first letters of the descriptions of the elements: 'butterfly (starts...)' and 'firefly (starts...)'
This probably seems arbitrary and flakey. I chose the description rather than the ele,ment name, because the latter is often prefixed by the game engine or source game, in abbreviated form.
Or, now I think about it,
rather than one-character-per-element representation,
what would be better would be a multiple-characters-per-element representation, hence delimited'
it could be like the current representation, but with text instead of numbers;
except for the text elements, where it could be single letter;
hence with the example above:
`a`b`b`a`firefly`firefly
`a`g`n`e`t`h`a
`f`r`i`d`a`butterfly`butterfly
`b`j`o`r`n`butterfly`butterfly
Above is a simplified example, as there are many elements corresponding to firefly,
but each of them could be handled, if the entire description was output.
Above looks ugly, but in Excel or Calc or Sheets you could easily break above into a 2-D array, with the description of each element in its cell.
Even if the text elements were treated just like any other element, it would be easy to extract the letter from the description, in Sheets etc, or with regex.
Although above seems easy and good to me, the problem would be getting it back to R'n'D;
I suppose it would lead to a need for R'n'D to be able to parse input like the output above. It would be vulnerable to mistypes, but quite robust to say dragging the cells around in Sheets, maybe doing some Replace actions, and then copying the amended structure and pasting back into R'n'D.
And most importantly to me, the output/input is human-readable, and so in a sense, superior to the strings-of-delimited-numbers format. Definitely inferior in other ways of course; I figure that R'n'D manages an array of numbers, rather than of strings, for reasons of performance
'Regarding case, "Ctrl-v" (when used in the playfield) currently only supports pasting the complete text as either normal wall or steel wall (when using "Ctrl-Shift-v"), but currently does not differentiate between upper and lower case text in the clipboard, as this is a special use case which is currently only supported when directly typing text into the playfield.'
- Fair enough, but I hope that oneday it could do it, if only to prevent an increase in entropy
'- select brush with middle or right mouse button => replace area with drawing element 2 or 3'
-- maybe this doesn't work using a laptop touchpad? My touchpad is configured to treat a two-finger tap as right-click, and that works for me in the text editor I am typing this message into. But when I two-finger tap on the brush icon, it is selected, but when I then select a rectangle of cells in the level, the range is copied to the Grab brush 'outlined box', but NOT replaced with sand or space, or when I click elsewhere in the level; the range is always copied, never copied-plus-overwritten.
In fact, I think I have caused a bug, which is somehow I got R'n'D to start pasting in some other element:
(only the '927 part)
which is MM_wooden_wall.
I don't know how I did that, although I did have the MM engine chosen at some point; currently on RND engine, and have been for some time.
'- 'Hover mode' for inspecting cells; i.e. when this is enabled, don't need to hold down Control button in order to get the element's name in the lower left of the app window.
Already there: Just use the "pick element" tool.'
This works fine on my Windows PC, but not at all on my Android phone. I realize that you cannot hover on Android, like you can with a mouse pointer, so this request needs amending. Maybe in Android, a way of arrowing across the level, like arrowing around on a spreadsheet using the arrow keys on a keyboard, only using virtual buttons, like for game play, but for designing? But I understand and sympathise with your view that isn't value in supporting editing levels on Android.
So, I will do a volte face and suggest, having a moving cursor for editing levels (in Windows/Apple/Linux);
currently, hitting the arrow keys pans the level;
let it be like in text mode,
a cursor that can be moved, and hit Enter to wrap it back to the start of the next line,
and the user can hit the Space key, say, to enter the drawing element 1,
and hit the Space key again to enter the drawing element 2,
and hit the Space key again to enter the drawing element 3,
and hit the Space key again to revert to the element that was there pre-edit,
and so on.
The screen/level-panning could still happen, maybe trying to keep the cursor near the middle of the screen, as much as possible.
I feel like I am being overly demanding typing all this, but it is to be expected, I guess, that new possibilities invoke ideas for further new possibilities, and so on.
Thanks again
John
Re: Changing between 2 kinds of text elements
There is already some sort way of representing level elements in text, which can be used in some manner to copy-paste level snippets into the forum here, and they get displayed as the correct elements. I have used it once or twice when I discovered it and it was fresh in my memory; now the existence is still there, but the means are long since fled :)
Anyway, such a thing does exist, and could be a sensible way to copy-paste arbitrary non-text elements within the RnD editor was well as between it and the forum. I'm sure Holger knows what I mean (and whether it would actually make sense to expand its use in this way); and you can probably find it somewhere in the forum history...
Anyway, such a thing does exist, and could be a sensible way to copy-paste arbitrary non-text elements within the RnD editor was well as between it and the forum. I'm sure Holger knows what I mean (and whether it would actually make sense to expand its use in this way); and you can probably find it somewhere in the forum history...
Re: Changing between 2 kinds of text elements
Thanks Filbo, you mentioned a way of "representing level elements in text" when copying from the level, that sounds potentially very useful. Unfortunately my searches in the forum posts have drawn a blank. I don't like trying to search in the forum posts because when I try to do a search on an exact string it breaks the string up into words and returns matches that have some/any of the words.
Does anyone else have any thoughts on how to achieve this?
Does anyone else have any thoughts on how to achieve this?
Re: Changing between 2 kinds of text elements
I found an example. I clicked on my own name, then 'Search user's posts', and searched for 'paste'. That led to this post: viewtopic.php?p=16852&hilit=paste#p16852 -- which has an example. You can see what the code looks like by using the forum's 'Reply with quote' (image of ["]) button on the top post); and Holger describes how to use it.
It is basically a block of 3-digit tile numbers separated by backticks, (edited to fix this from actually displaying tiles!)
Knowing this, and that 013 is the code for 'wall of level', a search for 013 -- search.php?keywords=013 -- finds a zillion examples. (I'm sure it's not every example, as interior snippets won't use that, and different game engines have different wall types. But plenty enough to learn from!)
=====
Hah. I scrolled back up and noticed that this very post is already talking about the backtick-number form of copy-paste. In fact your comment that I was replying to, where I mentioned 'representing level elements in text', itself contained examples of the backtick notation! So clearly you already know about it.
I guess you're hoping for a more 'text-like' representation, giving tiles names rather than numeric codes. I guess this would be slightly useful, e.g. for better human interpretability of the codes; but the forum already interprets them back into tile images, so there isn't a lot of value there. And the names would almost certainly be variable-length, so a pasted level excerpt would be very weirdly formatted!
It is basically a block of 3-digit tile numbers separated by backticks,
Code: Select all
`OOO`OO1`...Knowing this, and that 013 is the code for 'wall of level', a search for 013 -- search.php?keywords=013 -- finds a zillion examples. (I'm sure it's not every example, as interior snippets won't use that, and different game engines have different wall types. But plenty enough to learn from!)
=====
Hah. I scrolled back up and noticed that this very post is already talking about the backtick-number form of copy-paste. In fact your comment that I was replying to, where I mentioned 'representing level elements in text', itself contained examples of the backtick notation! So clearly you already know about it.
I guess you're hoping for a more 'text-like' representation, giving tiles names rather than numeric codes. I guess this would be slightly useful, e.g. for better human interpretability of the codes; but the forum already interprets them back into tile images, so there isn't a lot of value there. And the names would almost certainly be variable-length, so a pasted level excerpt would be very weirdly formatted!
Re: Changing between 2 kinds of text elements
Yes that's right, I do a lot of copying and pasting between RnD and other programs, so I am well used to the numbers-as-text form of information storage. What I would like is an option to transfer the data by 'element token', which is the name of the element, according to Setup > Editor.
eg for steel wall the token is:
[steelwall]
So for a 2-by-2 square, with a BD diamond and a rock on the left, and space on the right:
I don't know what you did to preserve the text-ness so I have just changed backquote to single quote:
'056'000
'004'000
I would like to have another transfer format,
which for the example above would produce:
`bd_diamond`empty_space
`rock`empty_space
You are right this doesn't line up nicely in a text editor, but in Google Sheets or MS Excel you can split these lines by the backquotes and then each word is in its own cell and of course the cells automatically align; this is very different from in MS Word, Notepad etc.
This allows doing mods that are hard in RnD but easy in a program with formulas and macros etc,
eg
... transform the shape of a level from eg 64 by 32 to 128 by 16, without losing any data,
or:
... replacing every 3rd occurrence of a certain element type with something else.
In a perfect world there would be a third transfer format [i.e. a third keypress combination] that would allow output of the element's description instead of its token, so that eg for a CE, instead of outputting say:
`custom_1`custom_2
you could get e.g. [using hypothetical examples of changing the CEs' names]:
`halloween mask`broomstick
etc. But that might be a bit of an ask.
The alternative to this is:
It would be possible to map between the numbers and the element tokens etc using eg scripting or formulas and lookup tables in Excel.
But it would be quite arduous to build, and need occasional maintenance, because as new elements are added to RnD, so too they would need to be added to the structures in the external program.
So I think it would be better for RnD to handle it itself. There is a precedent for this: the palette can be customized, if you want, using editorsetup.conf,
and this uses the element tokens, not the number codes.
e.g. I can add some of the Supaplex ports to the 'MY' section of the Palette, using these entries:
sp_port_left
sp_port_right
sp_port_up
sp_port_vertical
John
eg for steel wall the token is:
[steelwall]
So for a 2-by-2 square, with a BD diamond and a rock on the left, and space on the right:
I don't know what you did to preserve the text-ness so I have just changed backquote to single quote:
'056'000
'004'000
I would like to have another transfer format,
which for the example above would produce:
`bd_diamond`empty_space
`rock`empty_space
You are right this doesn't line up nicely in a text editor, but in Google Sheets or MS Excel you can split these lines by the backquotes and then each word is in its own cell and of course the cells automatically align; this is very different from in MS Word, Notepad etc.
This allows doing mods that are hard in RnD but easy in a program with formulas and macros etc,
eg
... transform the shape of a level from eg 64 by 32 to 128 by 16, without losing any data,
or:
... replacing every 3rd occurrence of a certain element type with something else.
In a perfect world there would be a third transfer format [i.e. a third keypress combination] that would allow output of the element's description instead of its token, so that eg for a CE, instead of outputting say:
`custom_1`custom_2
you could get e.g. [using hypothetical examples of changing the CEs' names]:
`halloween mask`broomstick
etc. But that might be a bit of an ask.
The alternative to this is:
It would be possible to map between the numbers and the element tokens etc using eg scripting or formulas and lookup tables in Excel.
But it would be quite arduous to build, and need occasional maintenance, because as new elements are added to RnD, so too they would need to be added to the structures in the external program.
So I think it would be better for RnD to handle it itself. There is a precedent for this: the palette can be customized, if you want, using editorsetup.conf,
and this uses the element tokens, not the number codes.
e.g. I can add some of the Supaplex ports to the 'MY' section of the Palette, using these entries:
sp_port_left
sp_port_right
sp_port_up
sp_port_vertical
John