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

Found a bug in R'n'D? Report it here!

Moderators: Zomis, Flumminator

Post Reply
filbo
Posts: 326
Joined: Fri Jun 20, 2014 10:06 am

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

Post by filbo » Thu Dec 20, 2018 7:27 pm

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.

User avatar
Holger
Site Admin
Posts: 2999
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

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

Post by Holger » Thu Dec 27, 2018 7:09 pm

Nasty bug introduced with the MM/DF element sections -- fixed in Git repo now!

filbo
Posts: 326
Joined: Fri Jun 20, 2014 10:06 am

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

Post by filbo » Fri Dec 28, 2018 6:02 am

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.

User avatar
Holger
Site Admin
Posts: 2999
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

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

Post by Holger » Fri Dec 28, 2018 3:38 pm

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).

Post Reply