Config Editor/Hierarchy and #macro

[steady saffron]

Imagine, I have set up my configs in the project like this:

[steady saffron]

Now, from the hierarchy, one would expect, that "beta" is a child of "release".

I just tested this hierarchy with a macro:

#macro TESTVAL        42
#macro release:TESTVAL 1337

log($"********* {TESTVAL}");

Assuming, that "beta" derives from "release", I had expected to see the value 1337 in the log when starting in "beta" configuration.

But it printed 42.
So, even if I set up a hierarchy of configurations, they do not inherit.

My question now is:

• Is this a bug and should I make a ticket?
• Is this working as intended? If yes, what-the-h... is the purpose of such a hierarchy then, if it does not forward defined values? What is this entire thing for, then?

Your oppinions please!
Cheers G

thing is, in my current game i have a lot of macros defining room-order, available options, etc...
"default" is the dev-configuration.
without that inheritance this means to copy many macros with almost identical values from "release" to "beta" where only some change (this is why i did a hierarchy).
having all those settings multiple times opens up a new error source, if you forget to set one of those.
It also simply doubles the maintenance work if you need to adapt a setting.
Now imagine, it's not two, but many levels of hierarchy, not only release-beta, but release-beta-closedbeta-alpha or any set of possible build configurations.
Copying all values x times can't be the way-to-go.

imho this should really be inherited.

[tacit vigil]

There is no hierarchy

When a config is created you can base it on another one (in which case the settings and game options are inherited... AT THE POINT OF CREATION) after they are created they are separate entities

it is badly represented in the IDE to make you think that they are continuously inheriting

it is only showing that initial creation relationship - not the ongoing one

So it is not a bug as such... (we will not be "fixing" that part) - we should change how it is shown though

[steady saffron]

@tacit vigil Thanks for replying, however, I created a ticket this morning for this
https://github.com/YoYoGames/GameMaker-Bugs/issues/3935

where I think, that it explains quite good the need to derive macro values.
Please reconsider this and take a look -- it would be a huge advantage and step forward for our code-configuration options!
thanks

from my humble knowledge about the compiler, I think, it can't be a too hard task to implement it in the macro-interpretion engine when the compiler starts.
it's like a fallback-system.

Example:
config-hierarchy is default->release->beta

compiler starts in config "beta", finds a macro
looks into beta, no match, looks into release, match!

[tacit vigil]

Actually we have just discussed this in Triage and apparently the IDE may well keep the config hierarchy

in which case it IS a compiler bug that the macros are not reflecting this

we are getting this confirmed first before we decide if it is a bug that needs fixed in the compiler

[steady saffron]

this would be so awesome!
no kidding: i could remove over ONE HUNDRED macro lines in my current game, holding 98% the same values -- an incredible error source

[tacit vigil]

the original design was that the hierarchy is NOT active... but looks like the IDE team may have implemented this differently

[steady saffron]

"default" holds all my dev-values, shows editor buttons and other things.
"release" is a full second layer, turning most of the features off, and then
"beta" is "almost-like-release" (so i have to copy ALL of them), but has another server-ip and a handful of settings different (staging vs prod).

this is really a mess to maintain