I give up. Just spent another 3 hours trying to spawn two cylinders and connect them with a spawned constraint without funny stuff to happen and ‘this is not compatible with that’ messages.
Guys, if you decide to do a graphical editor and release one, then free the users of all c++ problems. It belongs under the hood. It is the raw low level coding smell that you can smell when using the editor.
Free your users of it! Free the answer hub. Under the hood with it. I do not want to see it in a node based editor. At least for raw C++ there is documentation. In the Editor I get ‘this is not compatible with that’ and god knows what you have stirred up…‘shape cylinder reference is not compatible with primitive component reference’ when trying to connect to the ‘set constrained components’ node. Guys, I am not sitting in your brains and can look at the picture that has evolved there during the years of development.
Here is what I see: ‘What is not compatible with What?’ … What?
Under the hood with it!!! Nobody wants to care about it!
I dont get the connection between Blueprints and Answer Hub…
Yes, Blueprints has some shortcommings. I would like to see some improvements as well, but ranting doersnt help either…
That might stem from an initial confsion about node types. Like references, actors, components, clsses, etc.
If these shortcommings would be solved, UE4 would have a fully fledged “Prefab” system, but until then, just work with what BP offers, or use C++.
For how long are you using UE4? 3 month?
You cant really expect to be fluent with the engine conectpt after such a “short” period.
Look, if they decide to go to a node based 3D Editor, then all conversion, casts etc etc have to be done without the user noticing it. They really managed to just put a graphical interface on C++ and present it to users. Imagine a standard 3D Software (3dsmax, …). You do a scene there and in this scene are objects! Done! There are no this and that objects, references, cast to XY and so on. There are only Objects! Last I looked at a game, on the screen if front of me there were also only objects! That’s what i care about.
Now I take a blueprint and do my game logic and I only use Objects. Spawn Object, Add Object, Object here, Object there, Hide Object, tracee from object to, dadada. That’s that. The user only sees objects! All he knows is that there are objects. Done! He does not know what is going on under the hood. If he wants to know, he can use C++.
That is the idea.
Then there is Epic and UE4. Thank you very much.
If they followed the above idea, then they could close the answer hub, because all would be fine. The avalanche of questions right now is simply because of the mess they produced with the current ‘nothing under the hood’ editor approach.
‘shape cylinder reference is not compatible with primitive component reference’ when trying to connect to the *‘set constrained components’ *node.
… I mean, what are they thinking? Seriously, what is the thinking here?
And then, try to google primitive component reference. Try to solve it with google or their documentation. Hours pass by…hours! Please Epic, I want to pay money for my subscription. I WANT to pay you money to be able to hire more people and do decent work!
“Blueprinting” is just programming. , how often do you want to give up? Have you watched all the nice tutorials about blueprints? Maybe programming just is not the right thing for you and you are more happy with creating 3D assets or music
Blueprint is really simple to use, but I can understand that it might seem hard if you have never used a programming language before.
Could be just me, of course. But it might be Epic was a too bold about awakening the idea that one doesn’t need to code with UE4. In my mind BP are good to assemble and configure stuff or make sketches of how functionality should be in the end, not really to make complex, final logic in it. It, for me, ends up way to complicated in BP then it would be in code. And so brittle. All that drama about unloadable or unupgradeable BPs I read…
I see BPs as the “glue logic” between the beefy parts of the code.
I want complex AI behvior? I code it in C++ and expose it as a node to the blueprint system. Then I can tweak inputs, etc in the BPS system.
That allows for much faster iteration than tweaking hardcoded values in code, etc.
But again, the BP system needs definite improvements and bug fixes…
But when one does realize he now can program, he shouldn’t fear C++ all too much. The hard step (learn how to program) has been done. C++ as language has mind bending or unreadable concepts (go try to read and understand webkits metaprogramming f.e.), but noone needs to know and use all the corners of the language to get them ideas expressed. That, just in my opinion, is less brittle and, depending how complex that is what you want to do, will be faster done (as well as you beeing faster at coding it, the computer will be faster executing the result).
Simpler stuff -> fast and easy in BP.
Complex stuff -> faster and less brittle in C++.
And of course its a bug if your BPs become unloadable, wether it due to errors in them, the BP system itself or by just an engine upgrade, but that fact alone doesn’t help it.
To the OPs remark, it really sometimes isn’t always obvious what exact type is required on input pins in blueprints, or how to get it. Worsened by the editor hiding stuff deemed out-of-scope. All the questions asked about it are prove of that. That is obvious in C++ and if one doesn’t know how to get the type in question, a simple search, or even trial and error with help of intellisense does it. Only questions I see about that is when signatures or whole types change on upgrade (though then the ppl didn’t really look for an answer themselves).
Guys, come on, the simpliest point to prove that UE4 graphical editor gets it wrong is the storm on answer hub.
To reply to a few points:
I have used many languages before profesionally
i disagree that the Editor has to reflect any C++ pecularity. In fact, all conversions, casts etc really should not be sth the user has to worry about. Think LUA or HLSL…the Editor should graphically reflect high level languages. You simply can not just put a pretty node based skirt on a low level language, especially if you are working heavily with self defined data types (primitive component…what?) and a less comprehensive documentation.
the C++ API of UE4 gets constantly updated without documentation keeping up. I actually bought Sherifs book hoping there would be a better API doc than Epics. Turns out the very first example was already outdated.
I really think that Epic will sooner or later move towards a editor that reflects a high level language. I mean you can code your own high level language using C++. All the conversion things when you try to conmect this to that and that give you errors just need to be dealed with under the hood. This is really just coding effort.
Which is not surprising when looking how many people are joining the UE4 community…
That is supposed to tell us what exactly?
This would create more overhead. All objects would have to carry what is known in Delphi as RTTI (runtime type information). As far as I know Epic started to implement something like that more or less recently. Thats why you can now check if casts are valid. It travels the parental chain through the class hierachy to verify the cast.
I did that even within Excel, using VBA.
Would you rather see stagnation in the engine and the documentation polished up?
Sometimes it seems people think “Oh come on, we are already at 4.76 and the engine is not perfect yet…”
UE4 has made spectacular progress over the last year.
Currently, I use the time to learn the engine. Personally I expect it to be “carefree robust” in about another year or so. Probably around version 4.15.
I fully agree on that part. At the moment I would never buy any book about the Unreal Engine. Stuff is still changing too rapidly for that.
Overhead is not relevant for people who use only blueprints. In blueprints you can not do your own multi-threading, but you need C++ for that. And looking how many cores are idle with the default multithreading of UE4 if.you run a ship built, I do not think high level language overhead would make it worse. If someone decides to use blueprints, then performance is not optimized anyway because of the standard task manager of UE4 that you have to use then and how it leaves so many cores idle.
When I think about it, I actually can not recall any relevant piece of software ever attempting to create low level visual scripting. It is kind of an oxymoron, right? If you go visual, then high level. Or wait, or you come from the zombie killing FPS MMORPG YTD whatever business
…you’re making no sense man, what does answerhub have to do with Blueprints?
Also I tried out your two projects you uploaded on the forums, the vehicle one and the body parts one, I think you accidentally uploaded the same project twice.
Let’s say you code in Blueprint and throw 2 of your 4 cores away because you can not multithread properly. With that waste, why would you worry about wasting a tiny bit more with high level language overhead, KV?
Bot:
tricky low level blueprinting -> many difficulties -> many people confused -> many answer hub questions.
Who sais that 2 cores are idling. Dont say the “Windows Task Manager” :rolleyes:
Are you sure you are not miscounting your (virtual) cores? :rolleyes:
Who sais that the task in question can be parallelized? Not everything can be distributed to multiple cores.
The language overhead in BPs becomes evident when accessing a lot of components in loops. And this can become an issue during gameplay.
So I use Blueprints extensively in construction scripts and simple OnTick stuff.
If it gets more complex, then i would resort to C++.
What is a bit “unlucky” in BP is the fact that you have to use much more local variables than in code.
So in some cases 5 lines of C++ code replaces a whole nest of nodes.
In other cases, three nodes connected together does the same as a whole class definition and the VS rituals, etc.
But AnswerHub does not solely revolve around Blueprints. There are far more C++ questions, btw
Just out of curiosity: You said you have expierience in several languages. What languages?
UE4 multi threading ticks execute each tick group on max 8 threads (not long ago it was set to 4 technicly it can be set to more) and there game thread and rendering thread. Problem with multithreading in games is not number of threads, but diffculty of time planing, you can make as much as threads all you like but soon you will discover that what most of threads will be waiting for other threads to finish, because they need data from other thread to be ready, so still you gonna have a lot of idle time.
So yes, I asked my question on answer hub 18h ago. There are 122 new questions on top of it. Just close the answer hub. Most questions on top of it should not even be ask for any user app.
My question should not need to be asked.
Anyway, sure timing is the heart of multi-threading. It is were quality and the ideas of the people working on software gets decisive.
I mean they are working on it, see async scene, but in experimental phase.
Look at PhysX integration. It is natively multithreaded, but capped in UE4. It is just that when they laid out the concept and then coded the engine, they did not get it done properly.
There is no reason why physics calculations should be capped if there is cpu left, it is just the integration that is lacking.
UE4 is nice and everything, but performance wise it is a sink hole. I can actually just block 2 cores of my cpu, and there is no difference in performance.
That said, I do not want to black paint everything. The entire UE4 graphical editor is actually a nice effort.
I’ve personally found the answer hub to be pretty **** helpful, I’ve never asked anything on it but have found info on thing I was having trouble with/interested in.
Ah, ok. That makes sense now. Initially, I thought you were just lacking some knowledge and that you maby underestimated the complexity of the engine.
But it seems that you are also severely lacking patience. :rolleyes:
I have a question open in AnswerHub for weeks now. I still keep calm. Other questions I had before were also open for days and days.
In th end, they got answered.
On AnswerHub, questions are not answreed by FIFO. So your question might get answered before or after these 122 are addressed…
You completely failed to understand the concept of multithreading.
Timing is (nearly) irrelevnt. The processes could even run asynchronously. What matters is causal dependency.
How about predictable performance. The capping (this goes as well for the FPS) has a reason. I rather have a steady 35 FPS than wild changes between 40 and 60…
And again: Maybe its simply not possible to parallelize the processes further.
See how efficient the engine uses even your capped CPU
That is obvious in C++ and if one doesn’t know how to get the type in question, a simple search, or even trial and error with help of intellisense does it. Only questions I see about that is when signatures or whole types change on upgrade (though then the ppl didn’t really look for an answer themselves).