Mrooney, just wanted to let you know that your replies were appreciated. Thank you very much, most of it, despite having spent a ton of time learning and using the networking features of the Unreal Engine, was completely unknown to me. <Exposition> **I took notes on all of it for use later (ease of indexing). I’ve had the LOVELY experience of back to back food poisoning and am still sick so when I got the Email Notification of a response I quickly realized it was super useful and decided to check on it later when I wasn’t dying. Got tired of waiting. Decided to look at this thread and start the video tutorials. ** </Exposition>
Random Streams: My use case for this was: 1. Server Only (not hidden just… not used by clients): Determining what the damage will be for Crits, Min-Max damage ranges, ect. and being able to reliably generate completely random™ variables for them. 2. Semi-large level generation. The original idea being that I’d be able to generate about 400 cubes as walls, a giant plane as a floor, and use that data to also spawn in items at specific locations. But instead of replicating the cubes I wanted to replicate the Stream Seed and save a ton of bandwidth and time (and not mess about with replicating non-moving structures, something I now realize wouldn’t have been a problem as things are only replicated if they change) while generating the level. THREE things went wrong:
Static Seed, Draw Calls, Pop-in.
Static Seed: For whatever reason I couldn’t get the seed to change. My changes in the value never stuck (manual or generated) so I always got the same results each game. Exact same numbers. In fact, iirc my walls were all placed in a diagonal line because the randomly generated numbers Output by a Stream Int InRange (or whatever) was ALWAYS the same exact number. This wasn’t a problem when not using the Stream versions of those nodes.
Draw Calls: When not using Instanced Static Mesh Hierarchies this was an unplayable game. And an indevelop-able game. My Editor FPS would start off at 160, drop to 5 when hitting play, and never recover past 15FPS when the game ended. Just… awful. Draw calls were over 4000. With ISTMH’s it went down a bit and became playable (at 14MS per frame on a much better rig than I’m developing for) but it caused the Pop-In problem.
Pop-in: Seemingly without reason (only the) cubes would “become hidden and then become unhidden” for brief periods of time. Flickering, “pulsing”, ect. This simply killed the game as it made it an utter displeasure to play/view and, in addition, forced players attention away from where it should have been toward the flickering. In a game where lots of stuff is happening and I’m pushing Player Bandwidth and designing around keeping it from being overloaded with information… having the relatively irrelevant walls working against the player’s ability to play the game meant, well, the game couldn’t be played.
From there I tried modular level design but even that had too many draw calls. So I had to move to prototyping with BSP’s and then turning those into full meshes ect. (the Content Examples’ “Level Design” method). Thus creating 1 map. Of about 10. And then adding in some randomization here and there to kind of achieve what I was going for. By that point I shelved the prototype, deeming it a timesink, and moved on to the next prototype with everything that I’d learned in mind. I’ve seen the Level Generation tutorials out there (for UE4) but none of them do what I was trying to do in a way that solved my problem. Epic’s YouTube video (and downloadable example) were actually the first thing I turned to when my Draw Calls were crazy high. They, however, didn’t suffer from my popping problem. Or weird seed issue. I plan to revisit the prototype once DX12 and Vulkan are properly implemented, rendering my Draw Calls issue a non-issue as, if I recall correctly, both APIs heavily reduce drawcalls… or basically remove them. Can’t recall which; I’m not positive.
Non-Character Movement: Saw that video a bunch actually And looked at the Content Examples. Lots of notes. So maybe I’m missing something but here’s what I’m trying to solve:
Case 1) Flying Ai. Not sure if I could make them characters. Point is, I want enemies which, for all accounts and purposes, are large mosquitos that attempt to evade player attacks, fly about in all coordinates, land on things including the ceiling, and attack the player. My confusion is mainly about how to do this as Behavior Trees seem to require Ai Controllers which seem to require Characters. I’m more than well aware that I’m on my own in figuring out exactly how to make them land (select a suitable place, move to simple, “stick to”) and plenty else. Main concern is how to actually make these characters fly. If I can do that then replication is easier. I’ve noticed that non-Character-movement replication is a bit less smooth. More jittery. Things like moving platforms on a Timeline.
Non-Character-Player-Movement: This seems far simpler. Player Controllers can possess Pawns. Temporary camera swap (with a clean transition), do the thing, repossess character. Maybe my concern was actually about the jitters? Honestly I’m thinking I threw this in here just because I thought of a related problem and didn’t give it any thought before adding it in as a “I’d like to see how this would be done” sort of thing. Next best thing would be my concern with how to solve for input changes but even that’s simple enough. When possible (almost always) use the PlayerController ONLY to pass inputs to the Possessed which then uses that information uniquely. When dealing with unique Pawns/Characters use Interfaces (“How do I have the door tell me I can open it when I’m nearby?”), and, in the worst case scenario, use States to determine whether or not you should do something (ie “But I don’t want pressing E to open up the door if I’m an Airplane”) if, for whatever (cough I did it dammit) dumb reason you decided to put Interaction logic in the Player Controller. >-> It would be simpler to migrate / rewrite that rather than sorting out where to put States, remembering to use them properly, ect. though.