Overriding type-defined state in things.

[AmyAmy]

Hi!

not sure whether this was an intended concequence, but the fix for #25 may inadvertedly introduced a bug in how type defined state used to work.

Prior to version 3.1.2 it used to be possible to define a state in a thing with the same name as a state of that types thing, overriding the state in the thing.

Bit confusing wording, here's an example of something that used to work.

26-state-override.json.txt

TestType has a state TestState which is set to "default in type".

There are to things of type TestType:

• TestThingWithoutOverride doesn't have any own state defined, therefor gettitng TestState returns "default in type" as expected.
• TestThingWithOverride has own state defined: TestState is set to "Overridden in thing". However, as of version 3.1.2 getting TestState return "default in type". It used to return "Overridden in thing".

Use the things directory to look at the state of these things:

Was this an intended change?

Workaround is relatively easy but a bit cumbersome: rename the states defined in the things, get for that value and if it doesn't exist get the original value.

[hufftheweevil]

Ha, what's funny is that when doing the bugfix, I noticed that the state initiator was out of order. I thought the way I had previously coded it would have caused the issue you're explaining. And so therefore I thought I fixed the issue you're explaining. But it appears now that I've done the opposite. That's what I get for thinking I'm smarter than my own self and not fully testing before release. I'll get a new patch out later today. Sorry for the inconvience.

[hufftheweevil]

All fixed, v3.1.3 published. Sorry again!