Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[R-26 Lightspeed]

As visible in the attached screenshot, i'm hovering my cursor over an operator (sensed through a trojan) in order to see what level this Operator is to see if it could be responsible for the level 2 terminal i'm next to.
However, the game only labels the item the Operator is hovering over.
This happened before in the same run, with directly visible allies also standing over items. However, it only happened to some of my allies that were standing on items, not all of them.
I didn't think to save & quit to see if the bug persisted through relaunch and copy the save file.

Also visible in this screenshot, i clicked the /SCAN/ [1 - HOSTILE] button, to try to get the class rating that way, but it says there are "No hostiles to label". I don't know if this is related.


(I ended up getting the class rating by comparing the color to a different Operator. (I'm not familiar with the Operator color levels with SHIFT_HUE(340) yet.))

[Kyzrati]

Ah, it appears that specifically for manually labeled locations out of view, a robot and item occupying the same location will have overlapping labels, unlike when in view where these two labels will each be presented in a different direction so as to not overlap. So the label exists there, it's just under the other one.

This is because labeling items outside view requires basing it on old map knowledge, which is handled by different code unaware of any other label conditions, and that label must happen second. Will have to see about somehow letting it have necessary state info.

...

There we go

[R-26 Lightspeed]

out of view,

I don't know if the bug you fixed also fixed other occurences, but as i mentioned, it also happened with allies in view.
Relevant screenshot attached.

[Kyzrati]

Actually not yet since that's a lot more complicated, but I've known about that one since the first version of Cogmind

Will look into it again but no guarantees. Maybe there's an easier way to solve it that won't involve too much spaghetti. (Inter-type label avoidance is not something the systems were really designed for, since normally you're not simultaneously labeling multiple different types of objects at once, just different instances of the same type.)

Edit: Actually though, now I recall this being inconsistent for some reason--it usually works even when manually labeling, but not always, would have to explore why that is...

[Kyzrati]

Okay yeah I've definitely confirmed that the system is capable of handling that situation properly, when a robot in view is standing on an item and you manually call up labels on that position. It always works properly in all the tests I've set up now, so I'd need a specific case where it doesn't work. I know I've encountered this myself in the past, but it seems to be rare, and actually may simply be behaving according to the rules, for example the labels end up overlapping and preferring the same direction due to what would otherwise be overlapping other parts.

Hm, actually... on looking at your image I can see that's exactly what's happening here! All orientations happen to have about the same "coverage cost," as in what objects will be covered if the desired labels are in a different direction, and covering objects themselves has a higher cost than covering labels (usually anyway, since they're based on actual length of the label that will be covered), so in the interest of keeping objects visible these labels in that scenario end up overlapping one another, but they do both still exist. Now ideally in this case since you're creating the labels manually for a specific location it would prioritize labeling instead of avoiding objects, but it uses the same system for both processes (since they're rather complex overall), meaning it is going to follow the same avoidance rules.

Maybe this specific scenario could be addressed by having a dynamic cost for label covering, and adjusting that when doing manual labeling... overall this is quite a lot of work for something that doesn't come into play very often :/ (you can right-click on your ally if you really really need their info, or use the pure/mass robot labeling option)

(Note this is overall different from the original non-FOV version addressed earlier in this thread, as those labels are created more directly, rather than using a generic system, so can more easily have special handling applied.)

Edit: Yep, based on that screenshot I created a specific testing scenario to confirm that's what's happening. You can see all the blocking items in your screenshot there--I can force the labels to overlap in that scenario.

[Kyzrati]

Okay yep I actually did find a way to force it to avoid other labels in this particular scenario using the existing system:



Above is the same scenario in your screenshot, just more obvious--without adjusting the relative label overlap cost for this case both labels would've been immediately right-oriented, but here they split due to a change in priority. I'll look at more widely implementing this change for the next release (it can actually affect some other types of objects as well), but hopefully there are no negative side effects. The thing is, something like this changing can cause negative/undesirable impacts on other scenarios, and you don't always know until you know