St. Obj. Attributes become mislabeled

[Raeven]

I didn't notice this mentioned in any of the evaluation feedback threads, which is understandable since the issue only comes up when multiple objects are affecting each other (or multi-tiled objects are being treated like multiple objects), but Volcanic always displays the attribute label (STR #256) from the current object, even when the stack object attribute that is being affected has a different label.

Example: In a fridge's "create food" BHAV you will find several nodes creating food and then assigning values to the "stack object's attribute 12". Fridges don't have an attribute 12 so it shows up in an unhelpfully-non-labeled, but non-confusing manner. Off to the right hand side, however, there's "Stack Object Attributes Random Bias (meal/snack):= 1" which is misleading/mislabeled. The label for the fridge's attribute one is displayed, but in reality it is the food's attribute one, "Current State", that is being assigned a value of 1.

The objects all still function properly, of course, since they go by the numbers, but it could cause some confusion for any humans relying on the labels.

 

[Rhys]

This is a problem with edith as well. There's not really any way to tell what type the stack object will contain for UI display, except maybe in some very specific circumstances.

Edith implements an "expected stack object type" to deal with functions with an obviously different stack object, though it is not used often. I could either implement that or make it more clear that certain variable names only belong to the owner object.

 

[Raeven]

Yeah, to be perfectly honest, I wasn't sure if I should bother posting it at all, because I really couldn't imagine how you might pull the labels from the targeted objects without having to bog Volcanic down checking such things frequently (and awkwardly). The best I could come up with is that (assuming checking to see if the stack object Not The Owner Object doesn't bog things down much) then perhaps the attribute's ID# could be displayed whenever they don't belong to the owner object, but that seems like it would probably be troublesome in multi-tiled objects. But I figured it was better to add it to the list and let you figure out if it was solvable or not (or, indeed, worth the effort).
I'd never heard of the "expected stack object type" before seeing the field in Volcanic, and I found it pretty intriguing, but I could not imagine what it was/was for. So interesting!