Changing between 2 kinds of text elements

[BrownSky]

Forgot to add:

I'm not much concerned with posting between the RnD level editor and the forum, my interests are more about using a 2nd program to make edits to a level which are hard to do in RnD.

BTW, the 3-digit representation can suddenly transform into 4-digit representation, once an element with a number more than 999 is added to the level, or part of the level that is selected with the Grab brush and copied; I don't know the finer details of how this works, but there are certainly _a lot_ of elements with 4-digit numbers - I think the numbers all begin with a 1, because the app hasn't reached the 2s yet... but oneday

John

[BrownSky]

Holger, you said you added the feature of using the "Shift" key to change between steel and non-steel text elements. Can I ask, will this apply in both situations:

a) at the time of adding the element to the level
b) holding down Shift and clicking on an existing text element

In my view, the second case is as important and useful as the first.

I've been investigating the aspect 'shift-click on an existing element' and I have found:

holding down Shift and clicking on eg:

- a pacman
-- causes it to rotate between different directions.

- diamond wall
-- toggles between diamond and diamond wall

- dynamite
-- toggles between burning dynamite and dynamite

- elements that have no 'opposite', or variants, do not change when shift-clicked.

- some elements that do have variants, eg ports, do not change when shift-clicked.

- some elements that do have variants, eg tubes, do not change when shift-clicked, but are placed adaptively when Shift is being held down.

There is probably a lot more to discover.

regards
John

[filbo]

It does seem clear that RnD already knows the elements 'by name', in order to support element-specific graphical tricks. So the ability to paste level excerpts in that sort of format seems like it wouldn't be super hard to do. And your reasons for wanting it seem sound...

[BrownSky]

Hi Filbo, TBH I am a bit behind the eight ball on the 'element-specific graphical tricks' of which you speak; I am very interested in anything that intersects with my idea of increasing the number of ways of data transfer between RnD and other apps. Please could you give an example (or two, or three...)?

[filbo]

Look in the (thousands of) files named 'graphicsinfo.conf' in the game levels directory tree.

This is another matter where there are dozens or hundreds of discussions in the forums here, but -- not sure what you would search for (except 'graphicsinfo.conf' will probably hit a good fraction of such discussions...)

[Holger]

Holger, you said you added the feature of using the "Shift" key to change between steel and non-steel text elements. Can I ask, will this apply in both situations:

a) at the time of adding the element to the level

Yes, that's what I added. (But only for characters "A" to "Z", else it wouldn't be possible to enter "!", which is "Shift-1" on many keyboards etc.)

b) holding down Shift and clicking on an existing text element

In my view, the second case is as important and useful as the first.

Also added this one now!

[BrownSky]

Holger, you said you added the feature of using the "Shift" key to change between steel and non-steel text elements. Can I ask, will this apply in both situations:

a) at the time of adding the element to the level

Yes, that's what I added. (But only for characters "A" to "Z", else it wouldn't be possible to enter "!", which is "Shift-1" on many keyboards etc.)

That is a very good point, which I had not thought about. Awkward. Ahem... Sorry to change my request on the fly (and I know you're not making these changes for me, but for the player community), but...

For toggling between non-steel and steel text elements,

My brief inspection of how Control is used shows that it has many uses;
- a 'default use', of combining with clicking on the level to read the clicked-on element into the first position in the trio of user-selected elements;
- other uses, which are specific based upon the button that has been chosen on the palette.

In view of the second one, I feel that Ctrl could have a specific use when the Enter Text Elements feature is active,
i.e. to switch between the two groups of text elements.

Right now, when the Enter Text Elements feature is active, holding down Ctrl and clicking reads the clicked-on element into the first position in the trio of user-selected elements, i.e. just the same as when most/all of the other buttons are chosen. That seems unnecessary to me, as 'Enter Text Elements' mode is very different from the other modes, and gives access only to a subset of elements, but with wide flexibility for using the keyboard to control element entry, unlike all the other modes.

There is e.g. Ctrl+Z for Undo and Ctrl+Y for Redo, but I would not think these would clash with my idea,
at least not when clicking on a text element in 'Enter Text Elements' mode - it would just toggle the element between the two kinds. Versus in Drawing mode, ctrl+clicking would still read the clicked-on element into the first position in the trio of user-selected elements.

But more tricky when typing text elements, as then you could submit Ctrl+Z, Ctrl+Y etc;

So maybe only repurpose Ctrl+mouseclick, and only when in 'Enter Text Elements' mode, to give the easy toggle between the two kinds of text element, for all text elements.

Another thought - when typing in 'Enter Text Elements' mode, hitting Ctrl without any other key could toggle between the two kinds of text element,
eg if I type A, B, C, D, 1, 2, 3, Ctrl, E, F, G, 4, 5, 6, Ctrl, H, I, J, 7, 8, 9
I could get:
- a run of non-steel elements A, B, C, D, 1, 2, 3
- a run of steel elements E, F, G, 4, 5, 6
- a run of non-steel elements H, I, J, 7, 8, 9

Or vice versa, if the last text elements entered PRIOR TO THE ABOVE were steel, or the first selected element was a steel text element, or something like that.

Phew, it's a heatwave here, going to go and have a lie down.

John

[BrownSky]

Look in the (thousands of) files named 'graphicsinfo.conf' in the game levels directory tree.

This is another matter where there are dozens or hundreds of discussions in the forums here, but -- not sure what you would search for (except 'graphicsinfo.conf' will probably hit a good fraction of such discussions...)

Yes I did know about 'graphicsinfo.conf' but I didn't realize that was what you meant. I have my own custom 'graphicsinfo.conf' file

Like editorsetup.conf, this config file uses token keys to represent different game elements. So, I ask myself, why does the level creator not do the same, thus enabling passing of meaningful IDs for game elements?

I suppose, because the level creator is fairly closely tied to the game engines, all of which use a 2D array to represent the state of a game being played. (I suppose.) This must be important because performance is critical, and if the elements in each location in the game are being represented by numbers, the engine can update them very quickly. The fact that the level creator also deals in numbers is a consequence of this. That makes sense.

Holger, the thing I am wondering is, since RnD can deal with 'two views' of game elements, numbers and strings, and can presumably map between them, might it be possible to transform the selected cells, or the entire level, upon being copied to the clipboard with Ctrl+C?

eg run a transform on eg



[pasted here with changed delimiters to try to defeat the forum's auto-conversion to the images:]

'080'001'000

so it can be output as

`player_1`sand`empty_space

I would still like to be able to get the original output,

eg like this but with backquotes:

'080'001'000

So ideally there would be two separate key combinations for 'as string-of-numbers' and 'as string-of-element-tokens'.

(I know there is already more than one key combination, for 'output as small icons' and 'output as large icons', although I have never used this.)

John

[filbo]

What I meant, and I think has been successfully communicated, but I still want to clarify myself, is:

By looking at graphicsinfo.conf files, we could deduce that yes, RnD already has the ability to internally translate between element 'names' like 'player_1', and internal numeric representations as needed for the different runtime game engines and save file formats.

This could also be learned by looking at the source; but I didn't :)

Anyway, just by this data-file-based evidence we know it can translate in one direction. I imagine (again, not looking at source) that there is already the ability to translate in the opposite direction; but even more than that, it is absolutely clear that if it can translate in one direction, the other direction is easily doable.

So, longwindedly, pretty much all I was saying was that the code needed to implement what you're asking for is already there, it is 'merely' a matter of stitching it together and deciding what kind of user interface it should have.