Most of these are complaints are due to lazyness or bad design of the code
i think instead of new features there are so much need for improvements at the basis.
today i have two more that i can remember:
copy/paste multiple actors from scene into blueprint components did not work.
set active did not work for collision spheres, they hava a extra node for enable/disable.
Actually this one is quite something I’d like to see!
Actually this is possible, you just need to create a “get” node for each variable you want and then select them all, ctrl+c, ctrl+v into the blueprint you want to copy to, then right click on each variable node and select “Promote to variable”. This will add the variable name/type to the blueprint.
Having to use shift+f1 to regain mouse control is something you can turn off in Editor Preferences, however using it this way will require you to click somewhere in the viewport in order to gain control of your character in game. This will allow you to use the console immediately upon hitting play.
Go to: Edit -> Editor Preferences -> Select the “Play” tab under Level Editor -> Uncheck the “Game gets mouse control” option.
If you want the command line during development, go to:
Window -> Developer Tools -> Output Log
Can you go into a bit more details for these questions? Such as what you are trying to do for each? For example on the “Attach To” one, is this in Component view or in the graph editor?
Mmmh, that’s only half a solution though, really, isn’t it? Its often quicker to purge/clean-out a Blueprint of code / assets leaving the ONLY the variables in place. THEN clone the BP… Then copy / paste the code in afterwards. The reasoning is this…
You can’t select multiple Variables in the left-hand-side Variable-pane and have those create a series of Gets all in one go. It has to be done one by one. You also can’t select multiple variables in the Graph, and then right-click on them ‘Create-Variable’. It only works on the ‘last highlighted’ iirc. So where’s the advantage here? You might as well just copy / paste the code. Then right click on each Variable-error in the Compiler-Results tab/window, and chose ‘Create-Variable’ that way.
So its still a PITA overall / a BP shortcoming. It makes no sense that you can’t copy BP variables directly** - **Even UDK-Kismet had this! - For sure, experienced devs will limit times this arises through arrays or inheritance or whatever. But for less experienced devs with hundreds of variables, it must be slow torture…
That is true, it’s not just copy/paste, you do have to create a Get node for each one by one before you can do anything. I agree it would be nice if you could just select them in the panel itself, but I gave that example just because it’s easier than starting from scratch.
Hopefully not many people are creating hundreds of variables though. Collapsing a group of related variables into a Struct, or using a MaterialParameterCollection (if they are editing numerous variables to modify parameters on a material) are both better choices than straight up variables imo, plus they make the variables reusable to some extent. BP Structs are pretty much just variable containers so they are ideal for lowering your BP variable count, but can be a bit of a pain to work with in the graph editor… You could even create a base class in C++, put all your variables in there then create an override in BP, but this requires that you know C++ which inst a given.
No matter what though, compromise is the key to keeping things clean & reusable, whether it is code or BP. The cleaner it is, the longer it takes to set up, but once you do you save yourself from headaches down the road!
Currently compilation times for Blueprints are horrendous; I’m moving more and more things to their own C++ modules because of that…
(Being a relatively small module in C++ it’s compiling in blink of an eye since I recompile only that one module I was changing)
As for the copy&paste thing I’ll take a look into the source, maybe I can code something and add it via PR.
A solution to Copy / Paste of Variables would be very cool!
Because no matter what approach is used: Mine / DotCam…
All Default-Values are all completely lost, which is a PITA.
@franktech Don’t get your hopes high, my last PR is from August 2017 and its still being reviewed… So no clue when this actually lands in the engine :S
Next to perhaps Event Dispatchers, Casting is probably the least well explained thing.
Let me see if I can try a different approach. Imagine you’re firing Missiles at a Building.
If a Missile hits the building you want the Mesh Material to reflect burn marks/damage.
But all around this building are obstacles: lampposts, cars, trees, animals, characters…
These will get new material changes too, but unique for animals / characters / cars etc.
How can you implement this? Maybe add Tags to all the different actors ahead of time…
That’s work though. So instead you could use Casting to discern which object is which.
Cast to Character… If successful, use the special Character-Material, if not cast again…
Look for Animal object… Look for Car… Look for Foliage… Detect Lamppost/Building…
In UDK Visual-Scripting wasn’t object oriented, so there was no way to detect Classes…
Or types etc… What that meant was you ended up with lots of silent failures. Not good!
So Epic made a very deliberate decision to add typing / classes into UE4 to end this!!
No worries @TriNityGER… That’s understood! I don’t really expect this to get done until UE5.
But even just having a PR floating around may act as a reminder to one of Epic’s developers.
You could use an interface for that and check if the hit object implements it. The interface has an method “onExplosion” and implementing objects can change their material based on that.
This would remove the casting to specific classes and replace it with a single “implements interface” call.
As TriNityGER said, the casting problem is a problem of your implementation instead of the engine.
Using this validation:
and calling the interface method.
Every “obstacle” knows how should react when a missile is hitting it, implementing its behahivor in the “onExplosion” interface implementation.
Absolutely! My example wasn’t the most practical as solutions go, just a hypothetical way of thinking about Casting and why it exists… Because new devs often post in frustration about Casting… Its like all their Blueprint Classes are locked away in different rooms in some crazy hotel. So it can helpful to see where Casting is actually useful for a change… Rather than an obstacle / puzzle you have to figure out and solve…
As regards Interfaces vs Casting or Pros/Cons for the OP. Interfaces are incredibly useful, especially for comms between UI and Game Logic. But they’re a little more abstract at first to get used to. They also require you to assemble a list of classes that support specific interfaces and call them all in a loop, which adds another layer of complexity when you’re just starting out. That’s why some devs prefer Event Dispatchers. One call and all of them are activated wherever they reside in whatever Blueprint etc.
But setting up Event Dispatchers can also be a little messy when you’re just getting started. I find one of the best examples of why they exist in the first place or how they differ from Interfaces, is to imagine objects spawned at runtime. For example, imagine a game that spawns traffic cone meshes players have to run over. After a cone is hit, it should fall over etc. But how do you setup a Hit or Overlap event on a dynamic object like this. You can’t have a Hit / Overlap event in advance unless its part of a BP. So Event Dispatchers can help here. In UDK, this concept was called Attach-To-Event, which was a little more intuitive perhaps.
Well, often the best solution is to have clean class structure. So every object reacting on hit is a child of the specific class with an abstract event. It’s super convenient for content creators to work in with such setup.
Of course, it could be not easy to develop a clean code architecture like this if overall game design changes often xD
There is a reason for that though isnt there, its because the selection in that panel relates directly to the defaults property panel for that variable. I had thought about multiple selection myself as a way to quickly change variable types but Im not sure it would work, the details panel in the level editor portion works abit different and allows different values for multi-selection but thats because those variables have been flagged specifically.
Just to touch on casting, if youre really accessing an object of a specific type so often then it might be best to have a reference to that type rather than one of its parents.
today i have something new that waste my time:
a dlc or something added to my project kills/overwrite my project settings^^
i wonder why my gamepad did not work in my level. my input settings are lost.
i mean the list where variables is listed, it already have a context menu, i like to see a multiselect here + copy/paste. thats intuitiv.
or at least a hint use copy/paste via blueprint there.