Answer Hub has > 15 question/ hours -> 360questions/day -> Answer hub is useless

Timing is not equal casual dependency… that’s what you just said. So the when what after what, aka timing, is not equal casual dependency. Say, for example, I wait for your reply where you say you waited for weeks for an reply on answer hub. Say I just waited for it, only to say: ‘see, answer hub is useless…weeks and weeks before your problem MAYBE gets solved’ in reply. See, that is timing. When what after what. Had I said from the beginning, that answer hub is useless because your question drowns in an ocean of question and if it gets solved then only in weeks, then you would have never admitted that you waited for weeks. So I applied the right casual dependency or layman terms: I had the right timing.
Without me timing the weeks argument properly, you would have never admitted that answer hub is useless! And that undirectly that uselessness comes from the amount confused users, who amount to such numbers because UE4 does not do high level GUI scripting.
Thank you! Case closed. :wink:

About PhysX capping: not talking about fps, but when physX objects amout to large numbers. The 1000 cubes test case, when physics make the fps drop.

I did not. I said it is more important than timing… Read carefully.

I have never said that. Why do you keep putting words into my mouth.
To repeat: I find AnswerHub extremely useful and if a question is not answered within a few days, yes thats right- “days”, than that is perfectly acceptable.
After I submit a question there, I dont even bother checking if there is an answer for the first 24 hours. (make it 72 on weekends).

Again, its not surprising that UE4 confuses new users. Since UE4 has become free, many people grabbing it and try to find the “make cool game now” button in the menu.
Then they are frustrated that this button doesnt exist and blame Epic for it.

But hey, do as you feel. You dont have to use AnswerHub but then dont complain about lacking support.

Casual dependency, if you set it up like in multithreading, IS timing. But hey, there is actually no definition of ‘timing’.

In that sense Stackoverflow and the likes should just close…

In that sense Stackoverflow and the likes should just close…

EDIT: btw I like how the thread started about blueprint errors > answer hub > physics and multi-threading.

Causal, not casual… :slight_smile:
Although its really starting to get OT, nevertheless:
E = F - B | C = A * B | D = C + E

While E and C can be evaluated in arbitrary order, D will always come after E or C.
And it does not matter whichever is calculated faster, E, or C. Both results are required for the evaluation of D.
So, if E finishes faster than C, the E thread is inevitably idling. But there is no way it could “help” C with its calculation.
Also keep in mind that (if you are really counting CPU cycles), the CPU does a lot of MT relevant stuff that is beyond the control of the compiler (Out of order execution, jump prediction, etc).

I still fail to se the connection.

There is: Just look up terms like “time slices”. In the old days, this was the only MT concept around. There were no priorities. Each task got the same amount of time from the CPU.
Back in those days, if timing would be of your concern, dropping your pile of punchcards also would be… :smiley:

Yeah, boys talk. Natural thread evolution that is. In my defence, I am actually at home on crutches.

But again, I definitely think, that IF you go for GUI scripting, then the scripting must reflect high level programming.
I mean on answer hub it was like,that even before they went free. UE4 is just confusing, in a way that low level programming is confusing if you are new to it.

Regarding the example: Say E is the PhysX thread and clogs up with 1000 physics objects, then I would not want that, right. I would multi-thread it to not have it as a bottleneck.

Regarding casual vs causal: shutty! :slight_smile:

Just read through this whole thing and I feel like you are missing a few points here, .

First of all Blueprints are . It pi**es me off more often then it should and of course it isn´t perfect but I was never before able to implement something so fast and with so little background knowledge.

I mean, what the hell are you expecting?
This whole thing is about realtime graphics and game development. One of the most complex and versatile topics you can choose.
We are talking about a visual scripting language that is able to provide designers the ability to implement something without asking a programmer first, inside a state of the art cross-platform engine. To programm something that this sentence applies to is already a huge piece of work. And you are complaining about the “high levelness” and the lack of super- async multithreading?

Which leads me to the next point you seem to miss. Epic really cares about feedback. You can see that just by reading through the posts in the subforum you decided to post in.

Thus, you complaining in a really agressive and offended tone of voice, using terms like “That´s that” and “Case closed” is just utterly unfair towards the guys at Epic and ignorant regarding the complexity of an issue like this.

Learn to give feedback you have actually thought about. The whole thread is useless without a clearly formulated suggestion regarding the issues you mentioned.

P.S. As if closing the Answer Hub would solve any problems. Seriously.

Look here is my suggestion, as repeated many time during this thread:

MAKE UE4 BLUEPRINTING LIKE A HIGH LEVEL LANGUAGE, NOT A LOW LEVEL LANGUAGE.

People will shower you with basic questions otherwise. And for good reason.

Sorry if I sound offensive. I am no native english speaker and actually have funny comedy characters in mind when saying ‘case closed’ etc…


Actually quite funny because we talked about bad multi-threading and UE4 being a cpu sink hole:

I googled UE4 forum and this showed up (in german)

Hardware eater for no reason.

Just in case some of you don’t speak German:
The linked article is about players who complain that a game using the Unreal Engine 4 is not well optimized. The author of that article assumes that is due to a lack of optimization of the engine not of the game itself.
There is absolutely no technical information in that article so that it is impossible to say whether this is true or not.

Well, I do.
And I must say that the article is very very biased and full of rethorical tricks.
The “problem” description starts like : “Due to the bad optimization, the game runs poorly on many PCs”.
And continues to say that “many current systems cant get to 35 FPS”.

Of course the article contains no specs. What PCs?
And no further argument about the optimiyation. It is just claimed to be bad and that is that.
This is not journalism, but professional trolling :slight_smile:
Also, its not even the final game version.

… claims the writer for no reason

PS: And if that the same casper who is presenting the video, then Im not surprised.
PC Games should really stop getting those teenies as interns… :wink:

well, then they all lie and when I measure multithreading, it magically shows me half of my quadcore cpu idling.
Look, a unicorn dancing on that rainbow! They exist!

On another take, I just tried for two hours to get UCX imported, no success. Well, UE4 does not have the ‘import collision mesh’ button, but ‘recognizes it automatically’. Well that’s nice, it does it automatically.

So yeah, you guys keep developing your first person shooters MMORPFSs RPG ZTD whatever with the nice unreal zombies, and Bob’s ya uncle and Ellie ya aunt.
Take a look at my dismemberment file. Targeted at UE4 users as an interest group. You can dismember zombies and other unreal creatures with it! OMG, how exiting!
Put a huge gun in your two FPS arms and rip them apart!

Lately i have noticed that a lot of people either do not use search or they lack the creative mind needed to find the solution to their problem. They expect a direct answer to their specific question when they could just tweak a similar one and solve their problem. I am not saying that the answerhub is perfect but i have personally answered the same question (regarding paper2d stuff) 3 times before i stopped caring. And i always wondered, how could they not find my previous post and they ask again and again the same thing? So my conclusion is that 80% of the myriad questions asked every day are redundant.

I share your opinion on the article. The quality is abysmal. I just wanted to keep my opinion separate from the article’s summary.

This reflects something important.

Too much nodes amount to achieve very simple things.

something like kismet should go back. For example, nodes with a complete Gameplay mechanics in a single box connected in a eventbegin (like ActorFactory, StartFiringAt, MoveToActor, StopFiring, AttachToEvent, CausesDamage, Death) All in a functional line.

But with less and less interaction and relevant answers to lay people.

What did eventually leads to a choice: Spending my time learning blueprint, or go straight to learn C ++ and so feel full longer, because the learning curve is getting almost equal between these two.

Aren’t most of the nodes you are talking about there already?

It does not uses the same approach!.

There could be nodes with more complete functionalities. An option as “Class blueprint Editor” based on a template as UTGame in UDK, which had a complete set of Gameplay features into the Kismet, but this time written in C ++ out instead of UScript. To help a layman to create a professional programing from scratch.

They are called “Macros” and “Functions”.
I guess people are disappointed as they find ou that not everything that the engine technically allows is already implemented.

That is the point. The layman can no longer avoid learning either C++ or adopting Blueprint

The more convienience a certain gameplay feature has, the less game type agnostic it becomes. And that is what Epic wants to avoid.
If something is only suitable for a specific subset of gameplay scenarios, its not considered as beneficial to the engine. This could then be a plugin instead.
However, plugins have their inherent limitations as well.
But thats why you have C++ and Blueprints to create your own more complex assets with primitive components that are still game agnostic.

Wants, not wnats… :slight_smile:

I still think if you go for GUI Scripting (Blueprints) then it has to be more mouth-ready. Anyone wanting more versatility can do C++ then.
But hey, everyone should have the freedom to dig their own grave. And if Epic decides to spend resources/time/money for years into developing blueprints, only to produce something that is as complicated as C++ itself and can only be fully used and understood by users who a capable of C++, then they are digging with da big shovel.

I dont think BP is that complicated, I can see there potential for some gamedev class for 15 y/o