Відео

Hey, thanks for kind words. I have a video on push replication already :D (compared with the previous method of replication). Find it by searching for my video "How to network C++ variables in Unreal"

Thanks. I haven't learned much about Iris yet. I also haven't learned much about NetGraph either. I am mostly familiar with the default networking set up for the engine. Iris and Netgraph are topics I hope to learn more about later. :)

I notice that Iris was used in Lyra for the equipment.

@@l_t_m_f I haven't explored equipment yet but nice info.

Thanks! Hm, I'm not sure how I would go about it now. If I had to do it again, I think I'd first get really comfortable with blueprint. I attempted to learn BP after learning Unreal C++. But lately I have been thinking, it probably would have been easier if I learned BP nodes first, then learned how to do that in C++. BP is very quick to write (you don't have to do things like include headers, etc.). So you can really get going fast with learning the gameplay framework. Then once you understand how things like Pawn, PlayerController, etc. work together, you can explore doing those things in C++, only having to learn syntactical things like what to include, how modules work, etc, -- but already understanding the pawn/playercontroller classes from experience in bp. Though, I'm not sure that is the best way to learn it, that's just a thought. Also, I'd study the example projects a bit more (like lyra). Learn to use "find references" "symbol search" etc in the example projects, and it can answer a lot of questions about how to set up things.

@enigma_dev I also have done CPP first and not BP, I am in deep now can't go switch to BP just yet lol but you are totally right it is better to get around visual script first. Lyra is super cool framework bit hard to her around at start. Thanks to your videos as well, I have been learning from over a year from you 🤝

How did you get it to work? I can’t get it to work when I press f9 in game, nothing happens.

@huntermurphy7515 thats the thing i have no clue, i just installed a first person mod instead bc i was getting frustrated then all of a sudden it all started working for me, well kind of again the zombies wont do any actual damage just circle around me.

Thanks! I guess it is a fairly niche topic, so low on views.

Hey, sure. :) I feel like I sort of learned it in a backwards way. I knew C++ before blueprint, and I really liked the C++ language. So I tried to learn how to just do everything in C++, skipping blueprint. But in hindsight, I think that is the not the best way. The engine has so many features that are quickly and elegantly expressed in blueprint/editor. In my current opinion, learning those (blueprint/editor/etc.) first will be easier than learning C++ first; so learn the C++ side of it second. (you can learn it in parallel, just don't neglect learning blueprint in favor of C++) And once you have a grasp on how all the things fit together (like pawns, player controllers, gamestate, game mode, etc.). Then you can learn how it is done in C++. So you're only really having to learn the syntax of how to do it in C++, because the concepts are already pretty clear from learning the easier scripting side of things. Learning how to read engine code will help vastly too, start small with like the parts of AActor you are using. Eventually it will hopefully snowball, and you will get to the point where you can investigate things by just reading engine code (well, most of the time :D) and answer your own questions. I want to make some videos to that, at some point. The engine is large, and there's still a lot for me to learn. I think the most important thing is to get to the point where you can do investigations yourself without needing tutorials. But watching tutorials is great way to learn fast, and still useful once you reach that point too. But there isn't always a tutorial covering the exact thing needed. With my videos, my goal is to try and save people time by giving a lot of good knowledge nuggets and understanding points. So people can hit the ground running and hopefully get past the early learning phases quicker. I don't plan to cover everything in the engine, but I think it would be cool to have a set of videos that would serve as a good starting point for someone getting into programming C++ with Unreal. -- There's not really one singular place for these tips I learned. I've learned things from official tutorials, official documentation, third party tutorials, forum posts, verbally from people, projects (check out lyra), and just reading engine code to try and figure out how things work. There's a vast amount of examples of how to do things in C++, just in the engine code. So learning how to navigate that is helpful (mostly I just use find-references and raw text searches, can see my rider video on the tools I use, there is equivalents in visual studio, but I covered them in my rider IDE video). Learn to get fast at navigating code with keybinds. I have not yet made a video on the widget reflector, but check that Unreal tool out. There's multiple ways to open it iirc, I just type WidgetReflector into the console that pops up from ~. The Widget reflector lets you put your mouse on windows in the engine, which takes you to the slate code, where you can find how it is displaying and reading C++ code. Slate code can be intimidating to read at first, but if you are used to UMG, it is essentially what you see in the widget trees, just a special syntax built on top of C++. The widgetreflector gives you starting points for research in reading the engine code. You can drop breakpoints and get callstacks to inspect what calls what (if you download engine symbols from the epic games launcher, or built the engine yourself). Also I try to play around, or experiment with, new concepts to get a better grasp on them. Live coding + console-commands and actor iterators make it really easy to write bespoke tests to test how something works. (I have some videos on those topics individually). Sometimes you have to hunt for information online. Like I knew there had to be a concept to force collect garbage. With some searching I found that cvar to collect garbage every frame. But in that case, it was searching for a concept I thought surely existed. But the console window now has autocomplete in ue5, so sometimes clever combination of words can yield nice discoveries on cheats in the engine has by default. (eg summon). But you may work backwards from finding the cheat, and where it is executed in code, to see how to use it properly. Well, that turned into a wall of text. Hopefully you found some part of it useful.

Hey thanks for the kind words, and thanks for the honest feedback. I've recently got a new dynamic mic to help improve the quality, but I've still got some videos I am editing using the old condenser mic -- that I need to finish before the mic makes it into new videos. I also learned a new noise-gate workflow to help improve the audio and remove breaths etc, which will hopefully cut down on editing time. Some of the this issues here is due to trying to edit out pauses between words. I've been doing a lot of these unscripted as I don't have a lot of time to spend making the video. This video in particular was a one-off video I wanted to make quickly, so it is more rough than normal. I sort of have a high level plan of the next few videos I am going to make, and this video I decided to try and fit in-between my plan and editing of other videos. I've recently been experimenting with ways of improving production quality. I found out recording a video, writing a script, and overlaying that video on top of the VO is way more work than I can do (not exact numbers, but it is way more than it seems -- something between 10-30 minutes editing for every 1 minute of video with that method). Also I tried recording the video and then recording myself talking over it playing back -- that is a lot more work than I thought too (maybe 5-10 editing minutes per minute in video, so better but not great). Not considering video prep time either. So right now I'm experimenting again with doing it "live" but perhaps some code written before-hand. Or talking over a slide presentation of code snippets. But I'm still iterating on how to best make videos quickly, but at the right quality bar. Hopefully I'll find something that works well :D

By PDA you mean primary data asset? UPrimaryDataAsset inherits from UDataAsset, so inherit from PDA instead. You shouldn't need multiple inheritance. Just inherit from UPrimaryDataAsset if you want a PDA, is that is a UDataAsset as well, just with extra features. UPrimaryDataAsset is an extension of UDataAsset (PDA is child class of DA), PrimaryDataAssets has some extra features than a raw UDataAsset like discussed here. Note this video is about the base class UDataAssets, not UPrimaryDataAssets (I wanna make a video on PDA at some point, but it will refer back to this video to get the basics of UDataAssets first, since a lot of it is the same because it inherits from UDataAsset, but I want that video to focus on the additions, if I can get around to making it)

@@enigma_dev I want a DA instance inherited from my PDA, created in C++ and available in UE Editor

I'm not sure I follow. Are you getting an error? Like what is in your inheritance hierarchy? You can make child classes of PDA in C++, you can do a multiple linear class inheritance hierarchy (note: not multiple inheritance) I think this should be possible: PDA<-PDA_CPP1<-PDA_CPP2<-BP_PDA<-BP_PDA_INSTANCE. So it would could look something like this: 1) class UPrimaryDataAsset : publuc UDataAsset //this is the engine class 2) class UMyPDA_InCPP : public UPrimaryDataAsset //this is a new c++ base class you set up 3) class UMyPDASubclass_InCpp : public UMyPDA_InCPP //this is a new c++ child class you set up 4) BP_DataInstance //this is what is defined in editor, data instance based on UMyPDASubclass_InCpp Is that what you have but are finding an error or something?

@@enigma_dev I need PDA -> MyPDA -> My DA instance. And because multiple inheritance is forbidden in UE and Interfaces don't do much, I can't have a DA instance of my custom PDA (MyDA : DA, MyPDA)

Hm, the example you gave (PDA -> MyPDA -> My DA) this part doesn't look like multiple inheritance to me, looks like a linear inheritance hierarchy. That part seems fine. I'm assuming that means MyPDA inherits from PDA, (arrows are backwards than what I would expect). I just tested what I spoke to in the last comment without issue in 5.4. I was able to make a code base class of PDA, a child code class of that, a blueprint code class of that, and finally a data instance of that bp class. I didn't get any errors/warnings from that. But that's about all I tested of it. Multiple inheritance is having multiple base classes, perhaps that is what you mean by "PDA (MyDA : DA, MyPDA)" Do you mean that as "MyDA inherits from both a DA and MyPDA"? So in cpp that'd look like "class MyDat : public DA, public MyPDA". If that is the case, then I think you're right, you can't do that because it requires multiple inheritance. I'm not sure what to advise for that situation. Perhaps a PDA/DA that has references to other DAs. IE using composition. eg sudocode: " class MyCombinedDAClassType : public UPrimaryDataAsset{ UPROPERTY(EditDefaultsOnly, ...) TObjectPtr<DAType> DA; UPROPERTY(EditDefaultsOnly, ...) TObjectPtr<DAType2> MyPDA; } " and make an data instance of that. But that may be awkward for other reasons (eg you have to make 3 DA instances since it won't have inline editing in MyCombinedDAClassType, you'd make 3 DAInstances, DA, MyPDA, and the the thing referencing DA&MyPDA.).

I think so yeah, I think that falls under the behavior at 9:23. Simplest form of changing order would be swapping 2 elements in the middle of some array. That's like modifying 2 array elements. AFAIK there's nothing really special about a swap, other than we are overwriting existing elements with copies of the swapped elements. For push replication, you will still need to mark the array dirty, after a reorder But let me know if you seem other behavior. Pretty sure a reorder is just effectively a modify though.

Hey, if you get a chance can you copy-paste the warning as a reply? I don't recall seeing that issue, but I don't do too much with slate. Anyways, I did some google searching and found a forum post: SlateBasics.h(6): warning: Monolithic headers should not be used by this module Maybe that is your issue too? I just opened up SlateBasics.h, it looks like an older header that only really just includes a bunch of files for convenience. I believe it was the IWYU effort (search unreal IWYU) that advocated for better patterns of only including the headers you use (IWYU means include what you use). But this might not be exactly the same thing as IWYU. Anways, If you open up SlateBasics.h yourself, you'll see all it does is include a bunch of headers. A whole lot. It seems like it is a single (monolithic header) full of a bunch of slate headers. Chances are you only need like 2-3 of those headers for your given cpp class. But by including SlateBasics.h, you're implicitly including all of those other files too, which slows down compile times. You don't need all ~100 headers (or whatever number is there) implicitly included in SlateBasics.h. I think you only need to include the few you are actually using (easiest way to figure this out, I think, is just hit compile, with SlateBasics.h removed, and see what types are undefined) Once you know the undefined types, then navigate to where those types are defined in a header, and include those headers; I think? I think the fix may be to remove SlateBasics.h anywhere you are using it. And see what doesn't compile (ie undefined type) and include those individual headers. It looks like that forum post above, the person only needed #include "Engine/GameViewportClient.h". But in your case, it may be a different header (and there may be multiple you need, not just 1). Again, not something I remember fixing locally for myself, but sounds like maybe that is the issue, but I am not sure.

@@enigma_dev sure , i was and away from my pc but later on will open it and build it again and come with the warning, thanks sir

@@enigma_dev Wow that's exactly my case, and also what i Found on google but to be honest didn't know what to do with the information XD , but thanks for further explaining it for me i really appreciate it

@@arrowsdev No problem :)

Hey thanks :) AFAIK this is all still true for 5.4. I think the only difference with AActors, from regular UObjects, is it seems the uworld/level implicitly(or explicitly) has a refence to all the actors spawned; so spawned actors don't seem to get GC'd if they're unreferenced by a uproperty Even if nothing in your code that has a uproperty referencing them. The level seems to keep them around, unless you mark them garbage. (btw, looks like at 8:51, I see ue5.1 symbols loading, so I think that was the version I made the video on)

Hey, check out SAT and GJK. I'm more familiar with SAT (separating axis theorm, aka separating axis test), less so with GJK. SAT basically cleverly looks at projections of vertices to determine if they are colliding. Think of it as casting shadows on axes (eg y axis/ x axis). I think of them like lines going through the origin. But each axis is defined based on properties of the objects. If two shadows are NOT overlapping, then the objects cannot be colliding. The trick is to find all the different axes to test. If we talk about 2 cubes, it is the face normals. But it also needs to test the edge-on-edge collisions. You can cross product each pair of edges in the cube, to get another vector, which is an axis to test. Since some of these results are the same, you can get clever and avoid testing on redundant axes. (eg the left and right faces point in same but opposite directions, so only need to test one). So basically the SAT finds if any of these axes have shadows that don't intersect, and if there is a gap between them, then the object's cannot be colliding (because if they were, their shadows would at least be touching). SAT also gives you a MTV (minimum translation vector) to get you out of collision. This is basically the axes with the smallest overlap. You get the overlap distance, and multiply that by the normalized axis vector (with some care to make sure it points away from the object that was hit during the move). I should make a video on that, I did an implementation way back in college. It is a cool algorithm.

Hey, ahh sorry that is good feedback. I have video dedicated to replicating properties that covers the legacy/old-way and the new push/new-way that will probably help. Also have a playlist with some other aspects of networking. But to just summarize it here, the new way is more performant ( so I infer at least). In the new way you have to explicitly mark properties dirty that have changed and need replicate down to a client. You mark a property dirty at runtime with one of the MARK_PROPERTY_DIRTY_FROM_NAME macros. Also in the GetLifetimeReplicatedProps virtual function override, it uses the struct FDoRepLifetimeParams with bIsPushBased set to true. and uses the macros with DOREPLIFETIME_WITH_PARAMS_FAST. Search for "unreal push replication" to get more info. The old way uses one of the DOREPLIFETIME macros in GetLifetimeReplicatedProps, and you don't have to explicitly mark things dirty with a MARK_DIRTY macro.

Hey, It was actually some custom C++ / OpenGL code I wrote to visualize it. It was really bespoke, but I basically had a class for "vector" "point" "plane" "line" etc, and some helper functions to draw them from mouse clicks. It was very bespoke and not general purpose, but what I needed for the video.

@@enigma_dev Thank you :)

Hey, great question. 6:41 is where I speak a little bit to this. But I think it depends on exactly how you mean here. The main thing I am referring to, is we have a single data asset in memory. So if you're using a data asset to represent an entities current health, if you write a new health value to the data asset, then you affecting entity that is using that data asset. IE if you have entity X and entity Y, you set a data assets current health to 5 for entity X, then Y get's their current health set to 5 as well (despite that likely being a mistake). In this case, I would use a Data asset to represent static values (like the max health, etc.) But runtime values, I would push to the actor itself (or a component on the actor to make it easy to share behavior). That way there's a clear separation between const data, and runtime data. But perhaps you mean, it is static data, but you're changing the "max health" for everyone at once. Perhaps with like a level or difficulty system? So you change difficulty, every enemies max health changes. That could work for UDataAssets I suppose, but I think at that point you need to set up delegate hooks for changes. I feel like there's probably some other subtle issues there I'm not thinking of. Personally I'd set up a UDataAsset for Easy, Medium, and Hard difficulties, and change which data asset the entity is pointing to. Or set up a UDataTable spreadsheet (see my other video on that) and have it point to a new row. Oh, one issue with using UDataAsset for shared values, is likely it won't work for replication. (though I personally have never tried this, replicating values on data assets). There might be a potential server/client desync if a server changes a value, but the client doesn't also go through the flow to change the value. I think things simplify a lot if you can push these changing values to the actors/actorcomponents themselves. edit: There's also perhaps what designers would expect a data asset file to be. They would want to open up to expecting to populate data. So changing it at runtime might violate some expectations there. Overall just isn't something I have seen used before, modifying the properties at runtime. But I haven't looked through all the sample projects, if there's some precedent for it then that would be interesting. Curious to know more of the specifics in this situation. For changing values, you could use FScaleableFloat which lets you set values per level but then you have to introduce a curve table spreadsheet. The levels are defined by columns in the table. You can get values as ints or bools too, not just floats, just have to call a different function and it will cast the float value to the type you request.

Hey that's okay, you can come back to this once you learn a bit more. It will make a lot more sense if you learn C++ before hand.