u/pab_lo_

Hey all,

Recently, I've been using cellular data while away from home, and I started noticing severe battery draining even when not using my phone at all.

During one of these periods, where 50 % of the battery had been drained in a matter of a couple of hours, I checked and saw that the Tailscale app was the main culprit, which had used a whopping 75 % of the charge up until that point.

I have Tailscale DNS enabled, no apps using split tunneling and subnet routing enabled. Can any of these explain the battery usage I'm seeing?

Once I noticed this with cellular data, I also saw it happening (although it wasn't as bad) when using Wi-Fi. This has forced me to keep Tailscale disabled most of the time, then manually enabling it when I need it, which is of course far from ideal.

Is this expected? Has anyone else noticed something like this? I'm kind of at a loss right now.

So, in light of the recent posts and the overall community reaction I'm seeing about the planned deprecation of Blueprints in UE 6, I decided to make a quick post to allow for the opposite view to be heard as well. I was glad to hear about this plan because this is something that I've been hoping for for years. I know I'm probably going to get downvoted to hell, but at least allow me to explain myself.

I believe that BPs are inferior to plain text code in almost every possible way, except in terms of accessibility for non-technical people. I emphasize non-technical because, for engineers, I believe that the learning curve of BPs is actually way harder than your typical programming language switch, say, in the case that you're onboarding a new engineer that comes from a different engine or tech field.

Parsing through BPs is way harder than parsing through code with an IDE. Yes, you can search across BPs for keywords and BP members, but anything beyond that, like more complex searches or refactoring, is completely out of the realm of possibilities. Debugging would be another task where traditional programming languages are just superior. Also, because certain features are only available in C++ (e.g.: subsystems), there's a pressure for BP-only developers to do absolute atrocities in an attempt to replicate whatever feature they miss (spawning actors/components to carry out UI-stuff, for example). Long story short, I believe that the pressure to write spaghetti code is way higher in BPs than in C++ (or any other programming language, for that matter).

Then, you have the fact that binary format is the kryptonite of version control: you're forced to use the in-editor version control revision tool. If you're using git, BPs are as inscrutable as an FBX file.

BPs are good for prototyping but, why would a purpose-built programming language be worse than BPs for prototyping? Also, let's be real: in many cases, prototypes that work end up making it into production without actually being rewritten from the ground up. So, the moment you have a BP that works, the risk of having to bear with it for the rest of the project is real. I'm not saying this is the right way to work, I'm just stating a reality that I believe many of us have witnessed first hand at some point.

I guess most people would be thinking: "Well, it's all about options. If you're fine using C++, why don't you leave people alone if they want to use BPs?". And this points to what's, for me, the biggest issue with BPs: they have severely fragmented the UE community. Fab plugins is one example: the ones that are C++-based cannot be modified by people that only know BPs, while the plugins that are 100 % BPs can be a huuuge pain to integrate into projects that are mainly programmed in C++. This extends to organizations: if you are not careful, you'll end up with huge swaths of logic trapped in binary files that cannot be collaboratively modified.

And then, the final aspect of this: from Epic's POV, maintaining BPs has to be a PIA beyond comprehension. All the code generation that you need to maintain, all the C++ changes that need to be ported over to BPs. Take TOptional, for example. It has been available for years, but it hasn't yet been fully exposed to BPs yet.

About BPs being a selling point, well, every other major engine has been doing just fine without an equivalent visual scripting solution. In fact, Unity and Godot don't have one and, to this day, are regarded as the go-to option for devs that are just getting started. And, speaking of Godot, they already do something very similar to this with GDScript, and it's a widely praised engine.

This doesn't mean I love Verse, as it's still too early to judge. This also doesn't mean that I'm comfortable with every other change planned for UE 6, or that I'm fine with the possibility that people in Epic are thinking about doing this because they hope everyone will be vibe coding their entire game logic by the time UE 6 comes out. This is purely about the concept of getting rid of BPs.

So, if someone from Epic reads this (which I doubt), please go on with your plan. Sure, it may be painful in the short term, but I'm convinced it's going to be so, so much better in the long run.

Of course, I'm entirely open to opposing views (I wouldn't be posting otherwise), but I wanted to let it be known that there's at least one person that's happy with the change.

Hi all,

I was thinking recently about how games like Fortnite or Call of Duty implement their challenges, as I think they hint at a very powerful way of querying the state of the game at any given point in time.

So, for Fortnite, there are challenges like:

• "Search chests at named locations".
• "Reach max ammo of any type in different matches".
• "Damage players at Painted Palms or Latte Landing".

In Call of Duty, there's a bonus for killing another player while jumping, another one for when you kill them while dashing, another one for when you kill the MVP, etc.

I'd like to know how these things are implemented on a conceptual level, as I couldn't find much about this Googling around. I guess that there is some kind of DB-like system where you can make very specific queries and set listeners for very specific events.

The other side of this is: how is all this information recorded in the first place? Right now, my only guess is that each function is instrumented to signal what happened. For example, the running function explicitly calls another API to register that the character is running, and so on an so forth. Then a subsystem collects those events and provides APIs for querying and listening for events. But I don't think this scales well, as every function needs explicit event signaling.

Any information about how is this all conceptually implemented would be much appreciated! I would also appreciate if you could tie these concepts to UE-specific ones. For example, for signaling events, I think the Gameplay Message module could come in handy. But, as I said, I find it hard to believe that that's the most scalable way of doing things.