Page 1 of 1

can't make USE (or ME) persistent in editor

Posted: Thu Dec 20, 2018 7:27 pm
by filbo
I used to have the Level Creator configured to open the 'USE' section by default.

Now this no longer happens.

I've verified that toggling the 'TXT' section immediately causes ~/.rocksndiamonds/editorcascade.conf to be rewritten, changing the state of 'editor.cascade.el_chars'.

On the other hand, toggling 'ME' or 'USE' causes immediate rewrite, but does not write out the values 'editor.cascade.el_user' nor 'editor.cascade.el_dynamic'; and if I manually edit those into editorcascade.conf, RnD does not pay attention to them and deletes them on next write.

Re: can't make USE (or ME) persistent in editor

Posted: Thu Dec 27, 2018 7:09 pm
by Holger
Nasty bug introduced with the MM/DF element sections -- fixed in Git repo now!

Re: can't make USE (or ME) persistent in editor

Posted: Fri Dec 28, 2018 6:02 am
by filbo
Thanks, built & verified that it works correctly for USE (didn't check ME).

I would have done:

#define NUM_GLOBAL_SETUP_TOKENS (ARRAY_SIZE(global_setup_tokens))
(etc.)

rather than all the inline code changes. Even if it's only 2 uses per define.

Re: can't make USE (or ME) persistent in editor

Posted: Fri Dec 28, 2018 3:38 pm
by Holger
Good to know that it works for you now! :)

Regarding the use of macro identifiers, in this case I prefer to have a clear, visible reference to the name of the array that is iterated in those loops rather than using a "magic constant" for which it is not immediately clear from where it comes and which value it has, even though it indeed caused more changes in the code. IMHO, this is an improvement of code quality especially in this case, where the bug was caused by "NUM_EDITOR_CASCADE_SETUP_TOKENS" accidentally *not* being the size of the array "editor_cascade_setup_tokens", contrary to what it looked like. With the new code, this cannot happen again, as the array itself is used to calculate the number of iterations.

In other cases, I would agree that using a single constant is preferable over repeated use of complicated calculations in loop conditions (for readability of code -- the compiler will optimize it all away to a single integer constant in all these cases).