Suspiria

I am sorry to report that after 49 successful games, I have now encountered the bug again. Therefore, I hereby nominate this bug for PITA-bug of the year. We'll have to take this to the next level. I still recommend setting that value to 0 though. As it's not supposed to be non-zero at all. (Xbox only) I'd like to ask everyone to keep your eyes and ears open. For a pattern, or a way of reproduction. Anything at all. That would help. It's still pretty odd imo that there are so many games made with UDK and UE3 and nobody is complaining except RenX. Or so it seems anyway.

Nod song

I'm sure I seem patronizing here. The reason I'm saying this is because UDK will rewrite certain .INI's on exit. That is: With the (old) values that it originally started up with. If one were to change those .INI's while the client is running, and then think that it will be enough to just restart the client....... ...Then one would actually still be working with the old value(s), because the engine has changed that back on exit. ** So, even if one is a really smart person - and I do appreciate your intelligence - : One may simply not expect this particular thing to happen. And we will receive another report that the fix ain't working. And - this goes without saying - we would all lose our valuable time and energy on figuring thát one out. 😉 I want to make sure that doesn't happen. ** Except for the Default .ini's. Those particular .ini's actually do not get overwritten on exit. So now that you mention it: It wouldn't even be a problem to change it while it's running, as we are working with DefaultEngine.ini here.

Hmm interesting. Are you sure you're not working inside some SDK? Did you save the .ini file(s) while UDK was NOT running? I'm still going strong with 35+ while before I had it like once every ~7-10 games. When I reach 50+ I'm gonna conclude that *something* permanently fixed the issue on my system. Looking forward to HIHIHI's new results now that we know he's edited the right file.

Thank you for chiming in. Yes I've checked this, and the UDKEngine.ini copies and overwrites from DefaultEngine.ini at startup every time, reliably. And in BaseEngine.ini, the values are already set to 0 by default, coming from the installer package. Thank you very much for pointing this out though, as this could have been a major fuckup.

Hi Roweboat, Great! Please don't feel obligated to read everything in those posts. If you want to help test this, the only thing that should be required is this: Set CommonAudioPoolSize to 0 in:../UDKGame/Config/DefaultEngine.ini And then just make sure to launch the UDK.exe from the Win64 folder. If you want, you can set it to skip movies by making a shortcut and then adding -nomoviestartup to the "Target" box. With a space between. Let's squash this bug guys.

What I think would help the RenX community grow From an entrepreneur's perspective - let me just give this to you straight: Customers leaving after the initial hype, is called "churn". And as with all entrepreneurship and sales: having a truly, truly excellent product will help a lot with this. The difference between a good and a great product, is the difference between having a hard time selling it versus having it pretty much sell itself. If the product is great, then the persistent word-of-mouth will be your most powerful ad campaign that you will néver have to pay for. It's a simple math: If one person has 50 friends, family, coworkers and regular acquintences in their regular life, of which they enthusiastically tell 3 about this reaaally cool game. Those 3, also have 50 people in their regular lives, of which they tell 3 about the game.... 3x3x3x3x ................ Not including social media friends and influencers such as Youtubers and streamers!!! Those are X^Y walking billboards all over the f place, that don't have to be managed ánd who don't ask for money all the time. All of them can work fór you, or against you. If we can make it so, that those 3 persons are completely, totally, wowzers blown away and sold to the game... ...Bam. Not enough servers. Until that point of "truly excellent gamechanging product", it is, ofcourse, a great idea - necessary even - to help things along with promotional activities. As it's important to gain traction, receiving feedback, and to have an online presence at the point of release. Another of its fruits being the attraction of new developers and contributors. Priority now however, in my humble opinion, should remain somewhat more toward developing those Renegade game mechanics and stability that everyone has been dying for. To far excel the original game in its C&C features. With the exception of a selectable "Classic Renegade" server-mode. The way I see it, what could help the RenX community grow right now, is to actually offer two selectable gamemodes: "Classic Renegade" | "Renegade X". "Classic Renegade" mode being a serious attempt to remaster the old-school Ren experience, with greatly improved graphics and UI's, while having 95% the same gameplay. The "Renegade X" mode, on the other hand, introduces all-NEW features such as base (re)building, exotic vehicle crates, sprinting, abuse-proof spectator mode, and whatnot. While "Classic Renegade" primarily satisfies the nostalgia fanbase, the "Renegade X" mode catches the much bigger loyal-C&C fanbase of people who have been, in one way or another, disappointed with the relatively limited C&C feature-set and early EOL of Ren. The latter party being our primary target audience for promotionals. This ends the constant fights and disappointments of whether updates are Ren-like enough, and the leaving of Classic players. The new discussion would then be about updates being or not being C&C-like enough. As it should be. While inviting delightful out-of-the-box thinking, and dreams coming true. Programming-technically, it's a matter of disabling-changing certain X-features, as to gain a Classic experience. The gamemodes could even be made votable in the endgame voting UI, should the admin decide not to dedicate the server to a certain gamemode. Furthermore: Beware of the day that a bunch of fresh developers decide that it's actually not thát much of a nightmare to rebuild the entire codebase on UE4. As half of all programming efforts are always in the (program-)design part, while the other half is the actual coding itself. That is: Programming-wise, we're already half done. Having a modern, graphical, VR-capable and performance-optimized engine goes a long way towards attracting new players, as the game will be viewed as hot, modern, future-proof, and well.. NEW! ...And not as some random nostalgic mod with old-fashioned people who just Can't. Let. Go. But I digress. I think, for now, we're perfectly good (on a roll, even!) with the current UDK. And I'm seriously impressed by what we have going right now, and the degree of openness and community engagement that I've seen so far. I will never forget my first RenX Ion Beacon experience. It's been crafted into my retina, so to speak. Ever since, Totem Arts has gotten themselves a great fan and supporter. Contributor, even. I'm warming up. -DH

I KNEW IT I had this in my head: what if he's working in his SDK Hahah I deleted my other posts in all channels because I thought the fix turned out bad, lol I hate you ❤️ So please do let me know when you pass the 20+, and all is good in my world again And still thank you for helping with testing

Wow.... That hits home. Beautiful song.

Hi there That sounds like bad news. Thank you so much for reporting in though! Could you check under all these files: ../Engine/Config/BaseEngine.ini../UDKGame/Config/DefaultEngine.ini../UDKGame/Config/UDKEngine.ini If all 7 entries "CommonAudioPoolSize" have indeed been set to 0 ? Could you perhaps provide me with a log file? If yes read the spoiler. I'm still going strong with a clean 32+ matches without the issue. A serious new record for me. Even if the solution turns out not to work, the logic of my attack vector post still applies. And I don't plan on giving up just yet. Could get hard though. To debug a bug that I can't reproduce on my system anymore. XD I pretty much documented all my steps here, so if my system goes 50+ things are gonna get tough.

Thank you! Hope this works out for you too. If this works for everyone, then Totem Arts might be one step closer to officially supporting x64. That is, from the launcher. I replaced my launcher shortcut with the 64-bit UDK.exe, and I've also added -nomoviestartup to its command line in properties. With that, it skips the movies and I can start playing almost as quickly as with the launcher.

The x64 audio bug seems to have been fixed on my system.

I play on x64 too, and am really satisfied with my current 1440p Ultra settings. Only issue I've had with x64 so far was the audio crashing at the end of match, requiring a restart. This issue now seems to have been fixed on my system.

Renegade-X | x64 AUDIO BUG | Possible attack vectors | 21-03-2019 -------------------------------------------------------------------- TEST RESULTS | 22-24 march 2019 ----------------------------------- CONCLUSION | 24-03-2019 --------------------------- The x64 audio issue seems to be resolved on my computer. The following is what I did: Set CommonAudioPoolSize to 0 in: ../UDKGame/Config/DefaultEngine.ini And that's it! Please do confirm and feedback this solution by replying in this topic or by PM. Thank you for giving me the opportunity to assist with this. DH out

Here it is, guys.

I believe I've found a solution to this issue. I'll file a full bug report with the fix, after I'm done running a few more tests.

Aah.. I'm sure it seems like I'm merely complaining here. To be honest,.. I just want to help out with this one bug. So that RenX development doesn't hit this memory limitation, and we can all gracefully switch to x64. Am working on it right now.

As will I. Thank you!

I agree with this. Adding to that: The memory issue seems to be getting worse with the new vehicle crates. As stated by some other players and myself, just now. My guess is that we are pretty much approaching this threshold - although I haven't been measuring it. Actually, the video memory issue seems to suck more as you'll lose all credits, and if you're doing something important you and your team are fucked aswell. The audio bug just sucks but you can finish the rush or (team)donate credits gracefully. x64 for president.. Maybe it's time to have a look. It may seem intimidating but you never know what inspiration might start flowing. The way I see it, "impossible" isn't always the end of the story. Sometimes "realism", is just a rationalisation for serial failure. Please PM me should dev make the decision to go ahead and take a look. I'd like to join in and investigate this with you. -Duge

Yes that confirms exactly what I'm saying. Calling it "memory crashes" to me seems a bit short-sighted though. These errors have everything to do with high-resolution textures being loaded into VRAM and then reaching the 32-bit 4GB limit. That could mean that - while it's not an issue right now - any future additions like buildings and vehicles may push people's VRAM to that max. 4GB. At which point, the only way to play will be to lower textures and/or resolution. Which itself could be a "fix" then. That is: if there is absolutely no other way - like you seem to be suggesting right now. Anyway. I've read somewhere on the forum that *someone* is actually seriously working on migrating the codebase to UE4. Do you happen to know who this is? -DugeHick

Well, the x86 version is also *not supported*, as it will frequently crash with "Ran out of video memory" on higher-end systems like mine.. So I suppose we have to tune down our resolutions and textures to not reach that 4GB (V)RAM usage..... or the entire thing will just break. And with all the new buildings and vehicles being introduced and all,.. x86 is definately not future proof. So at some point, fixing the x64's audio and linking would become a priority. Might aswell be now. Hopefully the real answer is not "We would have to migrate the entire project to Unreal Engine 4 for that." Or we'll all be bottlenecked by 4GB.

Yes, I've definately noticed the blockers. However, I can still drive through the small passage left of NOD Power Plant. I have just now redownloaded and rechecked this. I invite you to try as it's a gamebreaking glitch.

I've also tested your map and I have the following to add: I can sneak right past NOD Power Plant onto the infantry path with any vehicle. I am then able to damage GDI buildings with this vehicle from there.