Dr_Chat

I'm going to drop a write-up of what's happening with the soundbug here: It appears that for whatever reason, during a map change, the system will temporarily change sound devices. On XAudio 2.7 (the version the UDK uses), this is fatal. WASAPI informs XAudio2 that the endpoint (e.g. your headphones) is gone, and XAudio2 would call the OnCriticalError callback to inform the game. The UDK does not register to receive these callbacks, so it continues on, completely unaware that the XAudio2 context is now invalid. What should happen is that when the game receives this callback, it should destroy and re-create the XAudio2 context so that it can output audio to the new endpoint. Reproduction The soundbug is trivial to reproduce by changing the output audio device on the desktop. 32-bit UDK For some reason this bug is not present on the 32-bit version of the UDK. I checked, and they use the same version of XAudio2 (2.7), so it isn't that. This would warrant some more investigation. Perhaps there's a piece of code that changes audio devices present only in the 64-bit version? Resources https://stackoverflow.com/questions/35600946/why-oncriticalerror-is-called-in-directx-version-of-xaudio2

It looks like Epic was very thorough in error checking, so there should be something logged to your console or game log when the soundbug happens. Can someone look at the game log ("RenegadeX/UDKGame/Logs/Launch.log") and give me the output?

Hm... perhaps visibility issues caused by transparent or thin objects is a mapping issue? Like they should be marked as transparent for line-of-sight tests in the editor? Saturating the server with line-of-sight traces could be a problem as well. Is there any way to configure the settings so that they're done asynchronously?

The game is running rather slowly on my machine, so I figure I'll make a thread to document my adventures in profiling and what I find. Scenario While playing on a 64 player game on Daybreak, I noticed that I was running at 48fps. This is constant no matter what my graphics settings are set at. I ran through some basic profiling guides from Epic. Doing so reveals that RenX is bottlenecked on game logic rather than graphics. As seen in the following picture, the FrameTime and GameEngine tick lines are aligned. Drilling down with another tool reveals that we're wasting time ticking a bunch of pawns, and notably all of these pawns were not visible when the trace was taken (I was repairing inside the Obelisk): For vehicle pawns, this is likely from updating vehicle treads and other graphical effects without checking "`TimeSince(LastRenderTime)" (if the object was visible within the last frame). Ditto for player pawns (Rx_Pawn), where the server/client logic should be split more carefully to avoid performing updates on invisible objects. Most importantly, a lot of time is spent calculating movement for these objects (Move Actor Time). Actor relevancy Epic also details actor relevancy here. Notably, it looks like RenX is configured to indicate that all actors are always relevant, which bypasses UDK engine optimizations. See bVehiclesAlwaysRelevant and bInfantryAlwaysRelevant in DefaultRenegadeX.ini. This causes all actors to always be replicated to all clients, and all clients will subsequently tick every character and vehicle present in the match. GameEngine Tick <self> There's also a ton of time attributed to GameEngine tick itself. Using a kernel-mode profiler, it looks like the game is hammering on the GetPerformanceInfo syscall in the main loop, wasting about a quarter to a half of its processing time in this function. Fortunately, Microsoft provides another function called GlobalMemoryStatusEx. This provides the same information that the game is interested in, and it's infinitely faster. It's trivial to patch UDK.exe to call this function instead, and that shaves off roughly 6mspf.

Appears to now be fixed, or I'm at least unable to reproduce this anymore.

This bug seems to have happened consistently to me over the past years. After I change in-game resolution, drawing the HUD eats a lot of in-game performance. If you do something that hides the HUD like open the map view or the main menu, performance jumps back up to 60fps and the game runs fine. I seem to recall that others had the same issue, and the fix was to just restart the game. Repro: Launch game. Set resolution to some really low value (800x600) Restart game. Join a server. Set resolution to max (3840x2160 in my case). Framerate is low when in-game HUD is displaying.

I'm guessing you mean you want to export the original w3d maps into Blender. You can do it with a combination of XCC mixer and this plugin that I'm working on.

@Madkill40: You're right on the first two points. For vehicles - I meant they all had similar colors (to a much lesser extent) across team lines. In the original screenshot, the yellows do blend together which is okay. It makes the red enemies easier to see. In that middle screenshot, those GDI units are primarily black/grey/not yellow. I looked at them for less than a second before thinking they were teammates. In the last screenshot, I looked at that NOD unit behind my teammate, and right away thought he was a teammate. So I go back to fighting, then later on he snuck up behind me and killed me. It is not enough to have an absence of colors indicate that someone is an enemy. Correct - I could look at them to confirm (which I have to do too often in RenX).

Hey, First off: I loved the original Renegade, and I really love a lot about Renegade X and would really like to see this game succeed. One thing I've noticed from playing this game is how hard it is to see who's a teammate vs. who isn't. I played a bit of RenX earlier today for the first time in a long time, and I noticed I would constantly mistake friendly infantry units as enemies, and enemies as friendlies. The problem is a lot of the infantry units look the same color from a distance, which makes them hard to distinguish. Here's a few examples of what I mean: Look at this picture from the original (in fullscreen preferably): If I had a better character - at first glance who would I shoot? The red guy, duh! Now - a picture from RenX. Featured: two NOD infantry guys running up to help attack GDI's base. Or are they NOD units? Either way, they didn't raise enough suspicion for me to go back and see if they were friendlies or not. Here's a picture of a bunch of GDI units going for an early-game attack on the NOD base: Yeah - first, seriously, the characters look amazing. Great job! They also just need to be more colored depending on the team. In the original, characters were primarily team-colored - even down to the bullets coming from their guns! This makes enemies really easy to distinguish compared to teammates in milliseconds without ever directly looking at them. I understand though that one issue may be Renegade's lighting is rather simple compared to the UDK's lighting, making it harder for a character to actually show their team color. Why not try another solution, e.g. subtle team-colored outlines only on friendlies? I feel that this issue extends to vehicles as well - but in a much more minor way. Either way - let's open a discussion on this issue.

Honestly, it might just be me driving in a really loud vehicle but I've noticed that the superweapon warning messages really aren't noticeable. The message needs to be at least 3x as loud as it is now, because the vehicle I was driving was at least 2x the volume of the warning message, so I didn't notice it. I've also noticed that unless if the team is on top of things, the superweapon can go completely unnoticed.

Basically, the servers (non-graphical part) aren't sorted, but the graphical text is.

Unfortunately I don't have experience in Unreal Script.

You people still need a programmer? I'm great at C++.