[FIX candidate: Repair gun visual bug]

Oh snap you're probably right. 😆

[FIX candidate: Repair gun visual bug]

5 minutes ago, NodSaibot said:

We must be talking about different bugs then

That'd be one mighty coincidence.

[FIX candidate: Repair gun visual bug]

12 minutes ago, NodSaibot said:

I don't see it anywhere in the newest patch notes.

I do:

Quote

Fixed the well-known issue with the particle effects a.k.a The Particle Bug

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.

[FIX candidate: Repair gun visual bug]

EDIT:
... 'tis confusion!

[FIX candidate: Repair gun visual bug]

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.

Spoiler

In Rx_Weapon.uc inside ChangeVisibility:
Replace:
    Primitive.SetHidden(!bIsVisible);
With:
    if (ParticleSystemComponent(Primitive) == None)
        Primitive.SetHidden(!bIsVisible);

CLEANUP
In Rx_Controller.uc: delete all calls to "ResetRepGunEmitters" aswell as the function itself.
In Rx_BeamWeapon.uc: delete the Tick() function in its entirety.

Done.

Should be gone for good now.

Honorable mentions: @JeepRubi and possibly others far into the past

[Renegade X: Patch 5.592.238 Notes]

On 2/9/2022 at 10:59 PM, NodSaibot said:

Will most likely be reverted in an upcoming patch.

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.

[Possible solution: x64 audio bug]

2 hours ago, NodSaibot said:

I'll take a look at it. We had some interesting progress regarding XAudio stuff as well.

 

https://github.com/TotemArts/RenegadeX-Extensions

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:

Spoiler

And if not for the sound bug (if it can be fixed my way) then perhaps can still use such a library to byte-patch some expensive Actor loops towards a threadpool that is initialized in DLLmain.
See if we can pump the game thread a bit lol. Hand off some stuff.

Loops that change data would require some mutexes and joins on the threadpool, but on those AllActors read-only loops it should easily work without all that. A couple of weeks ago I (re)started some profiling of the game thread but haven't specifically located expensive code sections yet.

But then again I'm not so sure whether or not it would be more rewarding to "just" *ahum* migrate the codebase to UE5. I've found that porting code can be relatively quick because you don't have to think of game design all the time. (although one probably will, still)

Also, another idea I had: to see if we can recreate the entire UE3 scripting system into UE5. (multithreaded ofcourse)
Yet I'm not sure of the legal implications of this.
Afaik it is really not allowed to modify the code in this way and then distribute such an SDK.

[Possible solution: x64 audio bug]

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.

Spoiler

How it works:

While the client awaits the server to switch maps, it suffers a window of vulnerability where its periodic GC sweep could crash XAudio2. By forcing this periodic GC sweep to occur just before travelling, this timer gets reset and the next sweep will come much later.

This also explains why the sound bug occurs so randomly.
If these conditions occur together:
- server is switching maps (like 8-15 seconds)
- client was notified of the travel with native ClientTravel (-> here starts the vulnerability)
- map duration including mapvoting was X min and 30secs or X min and 0secs

.. in goes the sweep and adios goes your audios.

So, in theory, this little trick here will allow the server a whopping 30 seconds to switch maps without the sound bug occurring on its clients.

 

[What kind of music do you hear?]

This brought me to tears (of intense compassion) today.

You see, I love humans.
And I love the music that we enjoy together.

[Purchase Terminal Crashes]

Did we get it?

[Purchase Terminal Crashes]

7 hours ago, KCRITON' said:

Hello

Sorry that I have not come back to you in the last few days, I have been really busy.

I have played a fair few games now and had no crashes. - But I am keeping in mind Ram and the possiblity of it being related to either that or perhaps Steam connectivity? (Since its one of the only things left running).

Thank you for all your time and efforts in helping me with this issue, whilst I  dont think its gone, I think its abaited for a while yet.

I hope the new release of firestorm proves more stable on my machine going forward.

Thank you again!

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.  

[Purchase Terminal Crashes]

1 minute ago, KCRITON' said:

Just played a 40min ish game with all Non essential programs turned off,  Virus protection turned off, latest 2020 DLL and max update on everything.

Didnt crash.

Will keep you posted.

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.

[Purchase Terminal Crashes]

27 minutes ago, KCRITON' said:

I have the latest Drivers for all items on the offical Asus site for my specific motherboard.

Above is my Windows 10 64bit details.

I am now trying the 2020 Dll.

This fresh install for his machine was done on the 27/8/2018 so yea I suppose you could make the argument for a fresh install since its been over a year.

CPU is standard motherboard settings.

Ram testing did not occur last night, I will get it sorted and get some results back to you, just been using the machine a lot in the past few days and have not had the time to leave it to test freely.

Thank you once again for all your time and efforts!

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?

[Purchase Terminal Crashes]

2 hours ago, KCRITON' said:

OK so ran the UDK 64 bit SDK straight from the .exe - As Vista mode As Admin - Redownloaded and installed UDK installer - Used the 2010 Varient of the DLL. Still same thing.

Did two quick games and on the third game as soon as  I bought a Chem trooper, boom crashed like always.

When I am way from PC tonight, I will run the RAM testers.

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.

[Purchase Terminal Crashes]

1 hour ago, KCRITON' said:

Attached in the .txt file. Logs
Launch.log 427.76 kB · 0 downloads

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.

[Is the !noob command good for the RenX community?]

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. 😂

[Purchase Terminal Crashes]

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?

[Purchase Terminal Crashes]

3 hours ago, KCRITON' said:

As for your first question - I only have one other game that crashes and thats PUBG - But mate, comon that is a filty unoptimised POC. So I don't think that is a fair test, but if you think its relevant.

If it crashes in more or less the same fashion, then it might be relevant.
 

3 hours ago, KCRITON' said:

I currently have 32GB of DDR4.

OK so #1 Insufficient RAM has been ruled out.
 

3 hours ago, KCRITON' said:

On the .dll do i need to replace all or just one specific one?

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.

[Purchase Terminal Crashes]

3 hours ago, KCRITON' said:

With the Ram testing do you want me to cover only the UNUSED ramm when nothing is running or the UNUSED ram when things ARE running?

Or all ram when everyting is running etc?

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.

[Purchase Terminal Crashes]

Please do answer my question that I wrote before:

Quote

Are you, by any chance, experiencing issues with other software and games aswell? (this includes your browser and such)
Instabilities, errors, files missing, crashes, anything out of the ordinary at all even if it seems small or meaningless. This is very important to know.

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

[Purchase Terminal Crashes]

On 8/17/2020 at 9:48 PM, KCRITON' said:

Here is the most recent log file coupled with it being a time when it crashed mid game losing me, command, mvp, nuke, spy and an assured victory.

Launch.log 1.6 MB · 5 downloads

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.

[Purchase Terminal Crashes]

Could you provide your UDKGame/Logs files please?

[Observations & Suggestions Detail 2020-2021]

21 hours ago, isupreme said:

Look and Feel    ~       As I often do repair work, I would oppose changing the vehicle Exit to the same side as facing.   As it is now, when i am repairing a player's tank and things get dangerous - I can safely jump in a tank that I am helping, and then safely exit to the back and continue repairs. 

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.

[Possible solution: x64 audio bug]

.

[Sound Issue]

On 8/9/2020 at 9:39 PM, Cynthia said:

You can try running the UDK.exe file with compatibility mode to WIndows 7. That fixed the sound bug pretty much for me

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.