[2.0.62] Pipette does not work on all signals

[sben]

When working with electric network components, one can pick active signals with [Q] to quickly select them for setting them as input and output conditions on the combinator.

cannot-q-signals-2.png (173.39 KiB) Viewed 595 times

This seems to work for almost any signal, but there are a few that don't work.
In the picture below the ones that don't work:
- upper part of the screenshot below: few recipes don't yield in the recipe but in the resulting items
- bottom-left: fluid sources like oil patches and fluorine vents yield in pumpjacks
- bottom-right: some signals that are not [Q]-pickable at all

cannot-q-signals-1.png (122.44 KiB) Viewed 595 times

[pantabo1]

it also doesnt work with the asteroid icons

edit: nvm, you did includee it in the form of the one asteroid at the right, sorry

[Rseding91]

The problem with those is: those are entities, except there are no items to build them be so you can’t pipette an item that doesn’t exist.

[Meddleman]

Probably already known but I should point out that there is also a marked difference between Remote-View pipetting and Active-Player pipetting, with Remote-View able to pipette far more than Active-Player.

Reproducible in, for instance, the Decider combinator UI when quickly shorthanding conditions and virtual signals such as [Each]. Remote-View allows easier/seamless pipetting/copying, while Active-Player is restricted to 'inventory only' signals, e.g. entities, crafters, intermediates, and weapons.

If any changes/patches/bugfixes are planned for OP's issue, I would kindly ask that this too be included as grouped consideration.
Edit: To be specific, that Active-Player pipetting is brought up to par with at least that of Remote-View.

[sben]

Now I see this might qualify better as feature request than bug...

How would some solution be like when [Q]-ing a signal, the player gets a new intermediate item type that resolves to:
- to the original [Q]-ed item if placed into a signal slot
- otherwise unchanged behaviour, e.g.:
-- to the resulting item of the recipe if placed into a storage/input/output slot of a building
-- to the corresponding entity if available and placed on the map
-- ...

Although I don't know the implementation, this might be quite easy to implement (e.g. storing a second value like originalPipetteSource, using different object method for retrieving the original and derived target, etc.).

The tooltip shown could be the original source (e.g. heavy oil cracking, pipe casting) while hovering over the e.g. decider combinator interface and switching back to the resulting item (e.g. light oil, pipe - that is the current tooltip behaviour) when not inside this type of window?

I think something like this would be quite straightforward to understand and use