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

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.

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...

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.

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

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.))

Multi-shot would help increase total damage output, for sure. It's more likely to spread, but if you can overcome that while at the same time having a large multislot weapon, it punches through anything, not to mention imagine creating such a thing that not even any damage resists can block

Multislot constructs, and maximizing your total number of constructs for even more compounding bonuses, are where it's at. We've seen some insane construct builds before.

To clarify just in case (even if it's marked on the save files' names and wouldn't cause many issues anyway), those are save files for Beta 13.
(I'd forgotten that this topic was created mentioning Beta 12 specifically.)

Recently a guide was created by some on the Discord about the scrap engine.
https://noemica.github.io/cog-minder/wiki.html#Scrap%20Engine

Thanks! It isn't as informative as i hoped, but still very useful.

Scrap Engine is actually one of the most powerful items in the game when used properly (people have put together flying builds with massive integrity and weapons that can one-shot any bot in the game--any bot)

I don't doubt its power when used well (and with sensors to avoid constant fights), though i wasn't expecting the "one-shot any bot" part.
After reading the guide lyrabold linked to, i think i can see how to create those "one-shot" weapons, which i think would need to be multi-shot?

Yeah, the way the Scrap Engine is just laying on the ground clearly implies that it isn't its final place in the game world.
I am never taking that gamble again, though. My first experience with it was bad enough. I didn't imagine i would skip a total of four depths to end up in -5.
I was also (and still am) unfamiliar with the Scam Engine (as you might have guesses by the surname i'm giving it), so attempting to make it work alongside with desperately trying to find any infowar went pretty horribly. I ended up getting my first Sensor Array in -3, at which point i discarded the Scam Engine to transition to flight and now the run is going much better.

Recently a guide was created by some on the Discord about the scrap engine.
https://noemica.github.io/cog-minder/wiki.html#Scrap%20Engine

Oh, that's so nice! Thank you for that change, I always disliked how autopathing moved me through collapsed tiles, especially when moving long distances.
I'm surprised i didn't notice the auto-avoidance in my first Beta 13 run. Habit of segmenting mouse movements to avoid pathing through collapsed tiles, i suppose. (I mean i did notice it, but only in the very last area, so i thought it was a special case...)