Can’t seem to find a cause or a fix, but my thralls keep trying to attack, but they just draw out their weapon and then instantly put it back.
Seems an old bug returning. It’s a little different now then it used to be. In the past this would happen mostly when a player changed the thrall weapon say from a lethal weapon to a truncheon.
The work around still works the same with the new bug as it did with the old.
When your thrall does this you need to remove any article of clothing from your thrall and replace it. That will get them working again about 99% of the time. It’s a mystery why it works but it does.
Here’s a video in case you are a visual learner like me.
1 Like
I am not certain its the same bug. I think this one is more related to pathing changes. My thrall usually pulls out the weapon, starts to move to the target, then stows the weapon and sometimes even moves away, back toward its original location. I have also noticed if I move around the target enough, with the thrall following, it will suddenly start attacking. Which supports the pathing issue theory.
2 Likes
Hey @LZB_Gattsu
We’ve received some feedback about this issue recently, both from live and testlive.
We’ll add your report to the file about this problem so our team can have a broader picture of what could be causing it.
3 Likes
I think @Auculus might be right in this instance. I was having this same problem yesterday and tried the method you linked, but it didn’t work for me. He would randomize his attacks, which could be supporting evidence for a pathing issue. I think it carries a flavor of the old one, though, as I’m pretty sure he favored one weapon over another.
Certainly could be a pathing issue in the instances that I have encountered this bug recently, I have removed the thralls headgear and put it back on. In all the cases the thrall was back to fighting.
However after reading this it could be linked to my characters movement, as I move around a lot when playing. Ever seen that squirrel from over the hedge? Yeah that’s me running around all over the place. May require some more testing to see what the actual fix is.
Well before they used to just stand there with their fists at the ready and not attack. Now it’s a case of them constantly switching out their weapon and sheathing it over and over. We’re getting there slowly!
1 Like
I’ll add to this with what I posted somewhere on reddit not too long ago–kind of a temporary and not-completely reliable fix is to clear the server cache (if you have access) or (in the case of singleplayer games) your local cache in the Intermediate folder. Reason being, this forces the server to reload certain data that connects your thrall to your character in ownership–at least, that was what our error was.
After we got tired of this bug returning, some friends and I buckled down and did some extensive targeted tests to determine what was causing this on our dedicated server. We narrowed it down to an error that was firing client-side (zero records server side), it essentially said “you don’t own this NPC” from what data it was receiving from the server anytime a command was ordered or passively called from behavior presets. Google and the devkit allowed me to slap a sloppy fix to our server, wherein the BaseNPC blueprint has been rerouted to continuously fire off loading the NPC data tables and no, it cannot pass go or collect 200$ (it’s stuck in a loop and unable to go to the rest of the beginplay functions, rip my server log) until it finishes (which appears to be forcing it to load all required data to connect your thrall to your character, otherwise it zeros it out).
Causes 1-2 extra minutes per server restart and a little bit of random stuttering immediately after (I’d say for ~10 minutes), but it’s fixed it for us.
2 Likes
Thanks [Wak4863] for this topic. It is a bad thing, that get you killed. I think most of us are playing solo. (I do). So I need my thrall to fight with me or I cant kill the boss.
It is anoying this bug. And it happens all the time. I play 12 - 16 hours every day and I can tell you this bug happens a lot.
I realy hope they will fix this before thay change other thrall things as I said in an other post.
1 Like
I came back after hunting through the logs I collected over the past few days to find the specific errors that were creating issues that we managed to resolve with a nice sloppy mod-version hotfix. I want to add that thralls that were affected by this issue if by some miracle DID attack and managed to get the killing blow, would cause the owning player character to not get kill experience.
Client-side, the logs would reflect the following:
[524]LogNet:Warning: UIpNetDriver::ProcesRemoteFunction: No owning connection for actor PersistentHumanoidNPC_C_8. Function FlushTextures will not be processed.
You can replace that “8” in there with whatever number attached to the thrall affected, as this error was persistent across the logs of anyone with a problem and consistently appeared when a command was ordered or passively called to by the AI behavioral presets.
Server-side, the log would, while going through the boot-up sequence, reflect a series of warnings that would start usually with the name of the NPC asset, then follow similar to this:
[ 0]LogClass:Warning: Skipping saved property ThrallName of ThrallInfo since it is no longer serializable for asset: FMemoryReader. (Maybe resave asset?)
These thralls ultimately would be the ones that weren’t attacking or doing the constant sheathing/unsheathing of their weapons, because their data wasn’t being loaded.
Our dirty fix was to edit the BaseNPC blueprint through the function calling to load the NPC data tables into a loop until it had loaded all data (and giving it a timer to load the data for longer, as the blueprint has a comment that it only has ~5 seconds to load it all before it is zeroed out). Little longer boot-up time for the initial server start when I’ve cleared the cache, but that server-side error I notated above has disappeared save for some rare instances where it is then reloaded later in the file (otherwise it is instead replaced with gripes from the fix, but you gotta break some things to fix them I guess).
1 Like
Hi, me again. Sorry for the back-to-back post, but I found myself in the devkit again today for something unrelated (the need for optimization and re-implementing things left unfinished in the files fuels me to depths I just cannot explain, my experimental server is wild from exploring just the config files as it is) and I thought I’d back up my prior post with a screencap of what I implemented to the BaseNPC blueprint to fix thrall data not loading in time, timing out, etc.
I know very, very little about anything remotely related to code outside of web development and post-processing optimization (HLSL is my jam, let me tell you, program development is more my husband’s realm) so this was a caffeinated-fueled series of Googling, reading UE4 documentation, browsing the supported functions in the devkit, and trial-and-error debugging. Obviously, since it’s a “blanket” fix for the entire function, my server log loses its MIND and calls “bad functions” when the data loads on much less complicated NPCs but the timer isn’t over and the loop sends it back to “none”, but it hasn’t had a negative impact beyond the first server-cache rebuild time increase. Otherwise, the constant loop seems to be forcing it to load all the thrall data that it times out in on the first go, and we haven’t had an issue with thralls since (our only record of it being unable to load thrall data has been traced back to the server retaining records of deleted thralls, for some bizarre reason).
I hope it helps!
Same here, and also weapons completely disappearing when you equip the thrall. PC - Private - PVP
1 Like
Wandering back in here to post another update in the never-ending battle of fix-finding:
Mostly for the sake of mod conflict potential, I’ve been rooting around for potential workarounds to editing the BaseNPC blueprint to push thrall data through at server boot up. I’ve discovered that I can get the data to load with a different loop, but I also found a connection with this issue to mobs occasionally not giving experience on death (in that their data wasn’t being loaded on time either, it had been a prevalent issue for a few weeks now).
After narrowing down thrall kills not being the problem and poking at hard-wiring the XP holder variable that wasn’t assigned to the majority of the blueprints but REALLY not wanting to edit that many of them, we’ve found an additional workaround that simply involves a config file edit in the Saved folder directory. (I’m a config file edit junkie for optimizing stability and graphics, so this result was only natural, I guess.)
I did some research on what the optimal speed was on a byte-to-packet ratio for pulling large chunks of text/image data from a SQL database through the official Microsoft documentation, and discovered it to be 512 bytes at minimum (though there are many variations scattered across the internet in unofficial means for exactly how high you can go). I’m not sure exactly what the float value conversion is in the corresponding setting from the Game.ini, but I know from the dedicated server logs (and cross-referencing it with UE4 forum research in how the value is usually used in C++ algorithms for background code) that it was capping pretty low, so I tweaked the following default value:
[/script/engine.gamenetworkmanager]
MoveRepSize=42.0f → 512.0f
Since UE4’s documentation on the Game Network Manager settings section doesn’t explain what the float translates to, I went with the idea that it was bytes. The server log reflects way higher bytes than 512 being transferred in a two-second capture period, so I no longer believe that is the case, but what I do know is that by allowing the save file’s SQL database to send more data per packet in general between all involved parties, we’ve negated both thralls not loading their data (and then not listening to commands, the nerve they have to mutiny) on server boot AND the experience-not-rewarded error that was plaguing various NPC families.
Also got some pretty snazzy-looking upgrades to textures, rendering speed, lag reduction, and general functionalities actually, y’know, functioning in ways I didn’t know they functioned. So that was pretty cool.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.