Suspiria
-
Posts
226 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Events
Gallery
Posts posted by Suspiria
-
-
7 hours ago, limsup said:
That goes without saying.
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. -
2 hours ago, limsup said:
Not working for me. As usual, I get the sound bug immediately on loading in the next map.
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. -
41 minutes ago, Sarah. said:
Unless this one is special, you would also have to change it in UDKEngine.ini, as the DefaultEngine.ini should only be used to generate the UDKEngine. It is possible that it generates a new one when you open it, but I can't test that now.
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. -
1 hour ago, roweboat said:
If more testing needed I can try doing this later in the week.
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.-
1
-
-
Quote
I agree that we need a clean secure server for a healthy community to grow -- but really the core issue we have is not many people are aware of RenX, is still a huge market of players who just need to be made aware of this gem of a game.
QuoteOver the years i seen many players leave because they don't like where the game is heading with all the nerfs and buffs - changes to characters like spread (it's not CS)
- I feel like the community should be more involved with upcoming changes. polls would be a great idea to have an idea what people like and what they don't like.Quote1-More publicities
QuoteThis indie game developed by a ragtag group of pirates would thrive in the Steam marketplace. Bite the bullet and strip the CnC branding.
Gliven already has new lore/backstory figured out.QuoteI have been thinking this is really the only path to actually expand the game.
QuoteI agree that awareness is one of the biggest issues. Paying large youtubers / streamers to do promotion may work or it may not. I for one ignore most ads and favour smaller, more humble creators that aren't as cheesy or moronic, and don't put a ton of sponsored crap in their content.
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
-
2
-
-
11 hours ago, HIHIHI said:
Well... I'm not sure now that they were all set to 0. I only know about two of them... Now I have confirmed that they are all set to 0, though. I have also commented out the lines, and will try to remember to send you the log if the sound bug occurs again.
HIHIHI
EDIT: Whoops, I did that stuff in the SDK... I'll do it in the game now... : )
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
-
On 12/14/2017 at 9:41 PM, SilentKnight said:
Hi all,
what kind of music "Renegader" hears.
That's one song i really enjoy.
Wow.... That hits home.
Beautiful song. -
On 3/25/2019 at 4:05 AM, HIHIHI said:
I must regretfully report that this is not a full fix for the sound bug, although it may reduce the chance of its occurrence (I cannot say this with certainty as I have a small sample size.). Today, on the official server, after a bot war on Field X, I got the sound bug on Under. : (
HIHIHI
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.SpoilerAfter doublechecking all 7 CommonAudioPoolSize entries, open up the ../Engine/Config/BaseEngine.ini again.
And comment out these lines:
Suppress=Dev
Suppress=DevAssetDataBase
Suppress=DevAudio
Suppress=DevAudioVerbose
Suppress=DevSound
Suppress=DevStreaming
By putting a semicolon ; before the line.
Logs are kept in ../UDKGame/Logs.
The most recent log is called "launch.log". The others are datetime-stamped.
Now, the best thing would be for the bug to occur again.
And to send me the fresh launch.log then.
If that takes too long, you can also just start your x64 client with the settings, join a game, then exit.
And there will also be some useful information for me in there that will help.
Just not as useful as the crashlog itself.
Do as you like. And thank you. 🙂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.-
1
-
2
-
-
31 minutes ago, HIHIHI said:
I can be another tester forthis. I'll follow your suggestion and set the CommonAudioPoolSize to 0, and try to remember to use 64-bit all the time. When using the 64-bit binary, I do get the soundbug pretty often, so we'll see what happens.
Thanks,
HIHIHI
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
--------------------------------------------------------------------Spoiler-
Commenting out these three lines in Engine/Config/BaseEngine.ini:
Suppress=DevAudio
Suppress=DevAudioVerbose
Suppress=DevSound
So that we can properly log.
And then start the x64 UDK.exe with the flag "-log", for the funz.
In-game, use STAT AUDIO and STAT LEVELS to monitor memory management.
-
Preventing the CommonAudioPoolSize mismatch:
../Engine/Config/BaseEngine.ini
../UDKGame/Config/DefaultEngine.ini
../UDKGame/Config/UDKEngine.ini
The currently set value of 96000000 in DefaultEngine.ini is NOT 96Mb - as suggested by the comments.
Either set all of them to a power-of-2 value (e.g. 96MB = 100663296), or set them to 128, 64 or even 0.
-
With the audio shutting down with a small "bang" on my system, it seems to me that the entire subsystem just shuts down.
Could the problem be in the codec? ::
Search for older/newer versions of the audio codec DLL's, and try replacing them:
libvorbis_64.dll (Vorbis Audio Codec) (current is 1.3.2.12709)
libvorbisfile_64.dll (Vorbis Audio Codec) (current is 1.3.2.12709)
libogg_64.dll (Ogg Container Support) (current is 1.2.2.12709)
libresample_x64.dll (Audio Resampler) (current is 0.1.3.0)
-
Unreal Engine 4 library grab
I am currently running UE4's Ogg Vorbis DLL's on RenX-x64. Running butter smooth so far.
Those are at versions 1.3.2.0 and 1.2.2.0 - the zero's possibly indicating older and/or final stable builds.
-
Xiph.org
Complete Ogg Vorbis source code up to 1.3.6.
This is a whole other ballgame as we're not even sure that the problem is actually in the codec.
I like to go deep, but not too deep. ..;p
So let's not go this route, for now.
-
Bug reproduction
Let's keep our eyes open for a quicker way of reproducing this bug.
Can we trigger it somehow?
I've personally experienced, and heard from others, that it usually happens at the end of a match; just when the next map starts loading.
Is there anyone here that has actually encountered this midmatch? Specific maps or servers? Influenced by playercount?
This kind of information could prove useful and should be carefully documented if we are to work this issue.
On 3/21/2019 at 8:41 PM, SonnyX said:Some members of the developer team have already stated before that these are confirmed bugs and that some have already tried looking into fixing it, yet to my understanding the problem lies in the engine's source-code
Thank you for your input.
I haven't been able to find any information whatsoever about this particular "confirmed bug" with audio in UDK, at all.
Not on the internet anyway.
If the fault is truly in the engine itself, then all the applications in the world that are using UE3/UDK should suffer the exact same fate.
Those are 617+ games.... All having a 10% chance for all audio to go out with a bang, until a hard reset. .....Yet noone is writing about it?!This makes me wonder where these "bug confirmations" originated from.
And more importantly: how exactly this conclusion was reached.What I mean to say with that, is that we might not be able to fix this in the source code.
But we may very well come to more thoroughly understand the bug, and be able to work our way around it.
TEST RESULTS | 22-24 march 2019
-----------------------------------SpoilerTested with UE4's Ogg Vorbis libraries. Actually works butter smooth, but still crashes our audio.
Tested with 100663296 instead of 96000000 Bytes CommonAudioPoolSize. No joy.Now testing with CommonAudioPoolSize 0, disabling the persistent pool for audio data.
So far I've played 32+ games in a row, with no audio shutdown when loading the next map.
Nor have I had any stuttering, or whatsoever.
If you were to Google "CommonAudioPoolSize", you would find that noone, absolutely noone, sets this value higher than between 0 and 512.
Let alone 96000000. I am quoting: "It could fix or create audio issues, so keep that in mind and change it back to 0 if needed."
So,.. 96000000 seems like a ri-di-cul-ous value, to me. And I strongly suspect this to be our causal agent.It seems waaay too easy though, just .iniïng ourselves out of this mess.
....But it wouldn't be the first time us humans overlook something. ;-D
We might just catch a break here.
Feels really great not to have the 32-bit "Ran out of video memory" crashes anymore.
Tbh, I haven't noticed anything negative at all with the x64 now that the sound issue seems to have been fixed for me.
That leaves me wondering what exactly those other issues with this client are about.
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.iniSpoiler@dev: I believe this setting was designed for the Xbox platform. It may be better to keep it at 0 on Windows!
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
-
1
-
2
-
Commenting out these three lines in Engine/Config/BaseEngine.ini:
-
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. -
5 hours ago, Marinealver said:
Well this is a mod project and not a commercial game. The only reason why EA allows this project to exist is that remains a non-commercial project. That being said we can let some things slide that would be considered inexcusable in a commercially sold or profit monetized product. But the fact that this is entirely free and not monetized in any way, with what they have here available now is rather impressive.
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.-
1
-
-
2 hours ago, Sarah. said:
Not only is a lot of stuff out of our control for more than a few things, as a lot it is just built into the engine. Such as the audio engine and what not. It's all built into the engine, and we can't read any of the code for any of it. But I'll see what I can do.
As will I.
Thank you! -
3 hours ago, roweboat said:
Although the x64 sound bug is a bit of annoyance, it should remain a low priority problem. On my system, it happens maybe 1 out of 10 games, and at most I lose 1-2 mins of game time. Not a big deal.
I think if the "out of memory issue" cannot be solved at this point, the launcher should integrate the x64 version and maybe just add some sort of disclaimer about the loss of sound bug.
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..
8 hours ago, Sarah. said:but admittedly I personally have never looked at the issue myself.
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. -
16 hours ago, Sarah! said:
Thank you, I really appreciate feedback from devs and all community members!
Maybe by accident
Should be fixed in main version (using old one?). There are blockers there
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.
What kind of music do you hear?
in Off Topic
Posted
Nod song