Weird "Include" behavior.

[kyriakos876]

Hello,
In the attached skin below I have the same skin 2 times with different @Includes on both of them.
I take the context of one of them and I put it in .txt file at @Resources\UpdateOutput\Updater.txt
Then I include it in the BugExplorer\ButThisDoesnt\Updater.ini skin.

Now if you load the
BugExplorer\WhyDoesThisWork\Updater.ini
and
BugExplorer\ButThisDoesnt\Updater.ini
you will see that only the one in the WhyDoesThisWork works correct.
I figured out that if you open
@Resources\UpdateOutput\Updater.txt
and go to line 85, and change the [Header] to anything else, for example [Header900] this skin will work normally, only without the style applied to the first string.

Why is this happening?
I understand that this might be a bit confusing, so let me know if you have trouble understanding.

-Thanks in advance.

[jsmorley]

I have no idea what behavior you are talking about.

[kyriakos876]

I have no idea what behavior you are talking about.

Both skins are the exact same when you load them?

[jsmorley]

I'm not sure how they can be. They are radically different.

[kyriakos876]

I'm not sure how they can be. They are radically different.

They are the exact same thing, it's just the one has the code stored in another .txt file... Here's a GIF trying to demonstrate the issue:

preview.gif

Incase you didn't notice, in the Variables.inc there's a style named [Header] that should automatically apply to the [Header] in the skin, just like it does in the other skin, which works fine.

[jsmorley]

Well, the first place I would look is the fact that @Include files are inserted at the point in the skin where the @Include option is invoked. This can easily make a huge difference in Z-position with meters. The order things are in the skin makes a difference, with Z-position on meters, and with the order measures are executed in.

[kyriakos876]

Well, the first place I would look is the fact that @Include files are inserted at the point in the skin where the @Include option is invoked. This can easily make a huge difference in Z-position with meters. The order things are in the skin makes a difference, with Z-position on meters, and with the order measures are executed in.

They are in the correct order. Everything works fine except for the Style. Check this other GIF that I think will help you understand better:
Click to animate

preview.gif

See how I only change the name of the section and manually set the meterstyle?

[jsmorley]

Yeah, I don't follow. You can't have a MeterStyle reference itself... You simply can't have

[Header]
Meter=String
MeterStyle=Header

Is there actually another MeterStyle called [Header]? If so, that just creates a conflict.

[kyriakos876]

Yeah, I don't follow. You can't have a MeterStyle reference itself... You simply can't have

[Header]
Meter=String
MeterStyle=Header

Is there actually a MeterStyle called [Meter900]?

It's not referencing itself... In the variables.inc there's a style like this:

Code: Select all

[Header]
StringAlign=Center
FontColor=#AccentColor#
FontFace=Roboto
FontSize=(18*#WVar#)
AntiAlias=1

No, there's no other meter called [Header900] except for the one you see me edit.

[jsmorley]

It's not referencing itself... In the variables.inc there's a style like this:

Code: Select all

[Header]
StringAlign=Center
FontColor=#AccentColor#
FontFace=Roboto
FontSize=(18*#WVar#)
AntiAlias=1

No, there's no other meter called [Header900] except for the one you see me edit.

But it IS referencing itself.

You have
[Header]
Meter=String
;MeterStyle=Header

So ok, that isn't referencing itself yet, but it also isn't using any MeterStyle.

If you remove the comment, you break it. A MeterStyle can't reference itself. If you have another section called [Header] in your .inc file, that is a MeterStyle, that's fine, but depending on the order things are loaded in the skin, only one section called [Header] will ever be acted upon. One will win, and one will be ignored.