Suspiria

Oh snap you're probably right. 😆

That'd be one mighty coincidence.

I do: It is completely gone on my SDK and comes right back whenever I revert my fix. I'm pulling my hair out lol. Also this fix, as you can see, works on the deep level of ChangeVisibility inside Rx_Weapon and specifically addresses the particle system. So not just the repair gun. Wouldn't be surprised if this would fix "the" particle bug.

EDIT: ... 'tis confusion!

Oh snap, I hunted some more and found the true cause. Renaming this topic from "Work-around" to "FIX candidate". *** WARNING *** For demonstration purposes only. Do not implement directly. Talk to Hande for how to do it safely. Honorable mentions: @JeepRubi and possibly others far into the past

Afaik the only reason why people complained is because this feature introduced a bug with the railgun. The rest of the uproar seems to be autistic clinging to old routine.

Ooh, fancy! That looks really good, Sarah. I had located dinput8.dll through IDA before aswell, it had only 1 call indeed. Perfect candidate to prevent triggering AV with injection, yes. Sounds like a great plan B. More technical talk about how to potentially salvage your library in here:

Found something! I'm a little more confident about this one as I'm starting to better understand what is happening. Also thanks to @Agent for mentioning the allocator a couple of years ago. So, here goes the incredibly complex and arduous fix: Add this within ProcessClientTravel within GameInfo.uc, (or override in Rx_Game) at the beginning of the PlayerController foreach: P.ClientForceGarbageCollection(); Done. Let's hope this fixes it before Firestorm. 🥂 If this doesn't work we could still look into byte-patching towards some code cave from which to reinitialize XAudio2. But hopefully that won't even be necessary.

This brought me to tears (of intense compassion) today. You see, I love humans. And I love the music that we enjoy together.

Did we get it?

Hello KCRITON, you have been on my mind today and I've also looked a couple of times if I saw you ingame. What is very important is that you try to remember (make a note of it if need be) the last series of changes you did just before the problem went away. For example: we know for sure that the following did NOT resolve it, because the problem still occurred right after it: - Latest Nvidia drivers - Fresh install on different SSD - Virus protection turned off - Vista mode as admin - Reinstalled UE3 redistributable (I assume that's what you referred to with "UDK installer") - 2010 DLL Whereas the problem seemed to go away after the following, and not limited to: - Checked on all motherboard drivers - 2020 DLL - Non essential programs turned off - "max update on everything" (?? did you mean with this that you actually updated something or did you just check if everything was maxed?) Also, while troubleshooting, users sometimes unconsciously do 'little' other things that tend to get forgotten, such as rebooting. Which is actually a great example, because since Windows 8 the normal 'shutdown' merely shuts down all programs after which it hibernates the kernel. Today, only a reboot is a reboot, whereas in the old days a 'shutdown' followed by a power-on also counted as a reboot. Stuff like that. (...yea, try rebooting btw. I must've thought we already did this, my bad.) So I wish for you that it was *something you did* that granted you "a fair few" games without problems. In which case it would be totally within your power to find the pattern and hunt the thing down. Good luck for now, and if you don't mind please also let us know if the problem turns out to have gone away permanently. In which case we may be able to extract a lesson from it for the next player with this problem. See you.

Interesting development. I'd say grab this opportunity: try not to do anything else with your computer right now other than Renegade-X. Because if you do, and it crashes again, then you will never know if these 40mins were just a coincidence or if something you did actually sticked.

Ok thank you for that information. Maybe you could also do the BaseEngine.ini thing that I talked about before, and then upload a newly generated crash-log. Also I consider 2018 fresh enough. I don't see how reïnstalling Windows would help you with this. BUT if you have a free drive, you could throw a temporary, non-activated (=1 month) Windows install on it without fully migrating everything. Just to check. But that'd be a last resort, I guess. Perhaps it would be better to first give it some space and maybe new inspiration will come. Wouldn't you think?

OK Did you close ALL programs on your computer, like, rigorously, before starting Renegade-X? Also try the 2020 variant of the dll. Now awaiting your RAM test results. Before or after that, you may want to specifically update your chipset, LAN and sound drivers of your motherboard. It wouldn't be the first time that doing so solves weird problems such as yours. To provide the right drivers for your motherboard, you can go to the manufacturer's website to find their drivers page. Then look for your particular model number and OS and look for 64-bit. With some manufacturers it can be a bit confusing as to which is wise to download. If you want you can also write down your manufacturer and model number here and I will put together the optimal driver-package for you.

There's no mention of tbbmalloc.dll in this log. It's giving us literally nothing to work with this time. Need more consistent and informative logs. Find the Engine/Config/BaseEngine.ini file. Search for "Suppress=" without double-quotes. Now for each of those lines, add a ; at the start and save the file.

Oh snap Did you know that Youtube's "dislike" button for comments actually does not work at all? It does exactly NOTHING publicly. It is only for yourself. 😂

Also, install this thing: Try closing ALL unnecessary programs on your computer before running Renegade-X. This time I do not mean this from a RAM perspective, but rather from an interference perspective. Run your 64-bit UDK.exe explicitly as an Administrator. (right-click -> Run as Administrator) MORE QUESTIONS ------------------------------------------------------------------------------------------------------------------------- What exact OS are you using? How fresh is the install? Have you installed the latest chipset, LAN and sound drivers for your motherboard model? Has your CPU/mem been manually clocked? While doing these attempts, could you from time to time check if UDK's newly-created crash log files keep pointing at tbbmalloc.dll consistently? Also could you tell more about those crashes with PUBG? Are there any peculiar similarities or differences in the details, compared with Renegade-X?

If it crashes in more or less the same fashion, then it might be relevant. OK so #1 Insufficient RAM has been ruled out. There is one tbbmalloc.dll file in your Binaries/Win64 folder. You rename that to tbbmalloc_BAK.dll, and then you copy a brand new tbbmalloc.dll from my .rar package and then test. You can pick any year you like. I suggest you try at least the oldest and the newest.

Good question. It'll be best to first close all applications, and then let those MemTest instances slurp up all the unused RAM at that point.

Please do answer my question that I wrote before: While you think of an answer to that, you can proceed with the following hypotheses: 1. Insufficient RAM How much free RAM do you have left while running Renegade-X? 2. Bad RAM Get MemTest, start 4 instances of it, and set each instance to test a quarter of your current free RAM. Make sure you get all of it. And do not close any applications while testing. If there is any error at all, your RAM is bad. One of my customers once had a defect in their 4th memory module that would only show up with heavy use because only then would that bank get addressed. That's why we do this. 3. Set your 64-bit UDK.exe compatibility mode to Vista. 4. I have attached a package of tbbmalloc.dll files from 2010 to 2020 which you can try to replace the current in Binaries/Win64 folder. Rename your old file to e.g. tbbmalloc_BAK.dll. TBBMALLOCS.rar

TBBMALLOC! This cannot be a coincidence. It is also one of the prime suspects relating to "the sound bug". Like Sarah said the log is not literally talking about the .exe itself. The actual payload for us is in that first line referring to tbbmalloc.dll. Anyway, thank you for submitting that log. So, first of all, I really cannot guarantee a positive outcome here. This is a nasty issue you're having and it's not looking good. Chances are relatively slim. That being said, there are still some things that we can try.

Could you provide your UDKGame/Logs files please?

Thou shalt not exit your own vehicle while facing off with an enemy. However, I did not account for the passenger-seat situation. If repairing is your thing, then that is a strong argument indeed. Perhaps this one can be made into a toggleable option in the input menu one day.

.

Oddly enough it did so for me aswell. I never ever had it again once, since I set my compatibility mode to Windows Vista. So you can try that, HavocPrime. But it will probably not work for you. Right now, members and developers are working together to find a true solution. But there are no guarantees here. It's a bit of a tough cookie for us too.