Just wanted to ask if there’s a way to disable the context sensitive checkbox altogether? because I see absolutely no use in having it only be partially context sensitive. By that I mean it just gets incredibly frustrating having to constantly toggle the checkbox on and off in order to try and find out if a node is in the context or not.
I would probably be OK with it, if there was some way of determining what the actual context where node names seem to work are reliably. But as it is right now I’m constantly having to search for how to enable the node I want (and know is available, but can’t figure out what context its looking for). I’d rather just take things from the palette and have done with it, or always get the node. At the very least, it’d be nice to have ALL nodes shown in the list, with maybe a colour coded list such that red list items are suggesting they don’t belong in that context.
So basically, rather than filter nodes out depending on context, which I don’t think is reliably working, why not show them in a colour (red for instance) so that we still know they exist and can use them anyway.
Watch how many people when using blueprint editor have to toggle that checkbox (do some UX testing with people new to blueprint and watch the frustration).
The problem you’d run in to is that context sensitivity is, IIRC, REQUIRED for BP interaction. I’m fairly confident that calling functions on another BP or Casting is actually impossible to select UNLESS context sensitive is checked.
Doesn’t the editor remember if you have Context Sensitive checked or not? That way you can just uncheck-and-forget…
The problem is that context sensitivity tends to filter out viable options. So you have to go around toggling it every time you want to find a node because the context sensitivity has filtered out a node that actually DOES work in the given context.
I suppose you could say the CS is buggy, but its probably not, its just that the context isn’t clear enough to give a selection and the default is to filter rather than not filter. False negatives rather than false positives I guess. Either way if you KNOW a node exists and can’t find it without messing with a checkbox then the context sensitivity is hurting rather than helping, so I’d rather switch it off and rely on my own mind filter
As I say, a colour coded “this will likely not work” would be better for me… but I’m happy for ANY fix to this behavior. Which seems to get worse over time weirdly enough.
As a workaround, I believe you can Star nodes to make them appear in Context Sensitive… so if you find yourself frequently having to disable Context Sensitivity to get to certain nodes, you might try starring those nodes for the time being?
The problem with disabling CS outright is that some nodes only show up when context-sensitive is enabled, like event dispatchers, variables and adding event nodes. I also think some cast operations only show up with CS enabled.
Having a key to quickly toggle CS on off would be nice, but what I would prefer would be for CS to work properly. AFAIK there is only one major bug with CS that requires me to disable it: It won’t show pure functions for other objects. Ever. Even trivial stuff like getting an Actor’s transform is not shown with CS on. This is incredibly annoying and encourages developers to use properties instead of getter functions, which is a bad coding practice (properties should be private and getters should be public, but right now it’s the other way around in UE4).
Fix that and there would be no need for a better toggle.
[=pedro_clericuzzi;212457]
The problem with disabling CS outright is that some nodes only show up when context-sensitive is enabled, like event dispatchers, variables and adding event nodes. I also think some cast operations only show up with CS enabled.
Having a key to quickly toggle CS on off would be nice, but what I would prefer would be for CS to work properly. AFAIK there is only one major bug with CS that requires me to disable it: It won’t show pure functions for other objects. Ever. Even trivial stuff like getting an Actor’s transform is not shown with CS on. This is incredibly annoying and encourages developers to use properties instead of getter functions, which is a bad coding practice (properties should be private and getters should be public, but right now it’s the other way around in UE4).
Fix that and there would be no need for a better toggle.
I guess the problem is that context sensitivity is probably harder for blueprint than it first seems. Because the context is the wider graph and not just the node/pin you’re dragging from. I’m just spitballing here though, it definitely FEELS broken to me (for instance drag off a pin and look for a node that you know takes that kind of pin and not find it unless you “toggle” is annoying.
My preference would be to fix it, I’m just not convinced of how easy that would be. I’m kind of surprised that nobody at Epic is moaning about it if I’m honest, because its a huge pain in the rear.
AFAIK, the only nodes missing from the context menu are pure functions from classes other than the one you’re currently editing or from blueprint function libraries. Do you have any other examples?
Getting the context just right is a more difficult problem than anyone initially imagines (myself included).
Right now, we try to guess at the “target” context. If you right-click in a graph, that target is your blueprint (meaning you get all global, function library functions, plus any functions/variables on your blueprint).
If you drag off a output pin, then that context would be any object outputs that node has. This second case is where we have problems. Sometimes you want to call a function on your blueprint, and you don’t have that option anymore (annoying). I want to fold in the current blueprint to that context as well, but there are other scenarios where you can imagine any “target context” is problematic… just give me all possible nodes ever that match this type! right?
There is trade off between finding the right narrowed context, and just allowing for every node that ever matches a pin type. The context menu can be massively overwhelming for new users, and a lot of people use it as a learning tool to find things they can actively use (would you want component functions offered for a component your blueprint doesn’t have? when there are no references to one in your graph?). There was internal debate about the right approach, and to aid the more experienced power users (who aren’t afraid of ALL the nodes, and know more what they want to place) there is an editor setting!
In editor preferences, under “Blueprint Editor”, there’s an option “Context Menu: Use Target Context”. If you turn that off, then you should just get all possible nodes that match the type you’re dragging off of.
[=pedro_clericuzzi;212457]
The problem with disabling CS outright is that some nodes only show up when context-sensitive is enabled, like event dispatchers, variables and adding event nodes. I also think some cast operations only show up with CS enabled.
This should have been fixed up with 4.6 menuing system refactor. Disabling context sensitivity should no longer hide anything that was available otherwise.
