rm5248

After playing around a bit more, while the performance is very nice it does crash for me randomly. Especially on map changes. Ultimately I think that while it is possible to run on Linux, it's never going to be a great experience unless somebody can really put in the time and effort to debug. It would be really great if UE5 could be used(so that a native Linux binary could exist), but given the amount of work it would take to port it I don't really see that happening. I would be willing to help out on that effort if it did ever happen.

For anybody still wanting to play on Linux, I've had good luck yesterday/today using Proton to play the game(launch via Steam). The steam overlay doesn't work, but it is at least stable! Longer story: a year or two ago, I upgraded something on my system(I don't know what) that would cause the game to become very very laggy after ~45 minutes quite consistently. Oddly, it would only happen if the mouse was moving, where my FPS would drop to ~8. As long as the mouse wasn't moving though, my FPS was fine. I've tried updating things(e.g. mesa, wine) without much luck. Running through wine has been somewhat inconsistent as well, lately it's been crashing after <10 minutes. Running it on Proton today though it ran for ~1.5 hours without problems(although I only played one map). Yesterday it continually crashed when I tried to load in, but I only tried it when the server was on Mines, so it could be something with that map. It's a bit of a weird setup, but I basically have my launcher(that works to keep the game up to date and shows the server information) as a native Linux app, I just need to launch from Steam. I did figure out today how to pass command-line arguments to the game though via the steam command line, so it should be pretty easy to extend how I launch the game to pass the arguments(for connecting to the server) to Ren-x via the Steam launch. If this is something you're interested in, let me know(I only work on it occasionally, but more people being interested keeps my interest up).

I experienced something similar as well with Debian. I did eventually get the launcher built, however it appears that the source code that is available on github is not the same version that is available for download, which is really quite frustrating to get this working. The version that I built manually did appear on screen at least, but when I tried to drag the window around it went kinda crazy all around the desktop. I did update my launcher to point at the correct URL to get the server list at least though; I need to check to see if the URL for the updates changed at all.

I've also updated my launcher recently(github) which does at least download the files and let you launch the game. It is somewhat finicky at the moment, so use at your own risk.

Here's a thought on SBH spy crates: what if they're a very low percentage of the character you could get(<2%), unless GDI has lost at least two buildings, in which case it becomes equally common with all the other spy crates? This is probably rather complicated to do though, and I'm not sure it would really have any impact on the game.

This probably doesn't help, but it did happen to me just now. One interesting thing that I noticed was that it seems to happen right before the map switches(as opposed to when the new map loads). When it happened, I did also hear a small pop through my headphones, kinda like I just unplugged my headphones.

To roweboat's idea, that seems plausible to me. I wrote some quick code to get the player count every 5 minutes, and over the past almost week I have accumulated some data on actual player counts, and not just theories. Anyway, these times should be in UTC. The first spike is larger than the rest, I believe when the PUG is on. Basically, two servers are full at that time. During the week, the player counts spike for several hours. However, this spike is contained mostly within one server, given that it is 64 players. Anyway, pretty graph time: It seems that player counts go high and low rather quickly, but the baseline does seem to be ~5-10 people. Really the question that I have is: if you make the servers smaller, does the player count average out to be the same, or is it depressed?

FWIW I never got the sound bug up until the past few weeks. It seems to be quite random. It has only happened to me about 3 times.

This is probably wishful thinking, but it does seem like there are enough players to fill two moderately-sized servers instead of one large server. Personally, I think that the people who push for 64 are crazy people. The maps and game mode just aren't built for that number of people!

Goto 64-player limits considered harmful As I've been playing again the past few weeks, I have some thoughts on the player limits on the servers. Frankly, I believe that the 64-player limit is much too high for the type of gameplay that Renegade is. At it's core, Renegade is not a free-for-all game, the base aspect of it gives a very different feel from the "kill everybody" vibe. There is a certain amount of strategy that is involved that doesn't involve just shooting anything that moves. You have the resources, character upgrades, and vehicles that you can buy, which set Renegade apart from other free-for-all games. The large player limit means that it becomes much harder to have a good game, where there is more of a balance - it tends to devolve into one side repairing all game and the other side attacking all game. Next point, the maps themselves aren't that good for 64 players. Most of the maps are much too small to effectively have 64 players at once - I think immediately of all of the Westwood maps. The possible exception to this is Walls, but even that gets very crowded when you have a full server. Even the maps that are large(e.g. Outposts, Eyes) don't work effectively with 64 players. It is still quite possible to have one team totally dominate the field, while the other team stays locked in their base. Some maps have different problems - the map name escapes me at the moment, but the one where the Tiberium silo is in a low point between the Nod and GDI bases(Steppe?). There is a lot of open area directly in front of each of the bases, but this chokepoint makes it hard for a team to effectively push forward. The game just becomes a slog at that point, trying to gain an upper hand against each other, and often not really doing anything for 40-60 minutes at a time. Some maps have made this less bad(Field X), but others don't effectively help to spread people out in the map(Islands X). These map changes are in my opinion not solving the problem, as it is certainly possible to play a very small map if it comes up for a vote. They simply go with "If we make a bigger map, things will be better," which I have found to not be true in all cases. Ultimately, I think that a better experience is had with a smaller number of players(40-50), rather than the 64 that currently exist. This should also help with the long stalemate games where one side can't effectively mount a counterattack against the besieging enemy. For example, I just came from a ~1.5hr match on Field(not Field X), where I joined at the ~10min mark. At that point however, it was pretty likely that Nod was going to lose. We were locked in our base at that point, and because the server was full it was effectively impossible for us to do anything to dislodge GDI from the base entrance, or to mount a rush through the tunnels; there were too many GDI players to overwhelm in either direction. There were even tunnel spamming MRLS in the GDI base, so even when we did manage to get to the tunnel entrance we couldn't do anything effective. This implies to me that the player counts are too large, since it was possible for GDI to attack from the main entrance and tunnel at the same time, as well as having enough people left over to tunnel spam their base entrances. Thoughts?

https://en.wikipedia.org/wiki/Security_through_obscurity

I did notice that the other week, but I'm not sure why that's the case. Does anybody know if something changed in the launcher? It seems to work fine on Windows.

Minor adventures time! For those of you on Linux who want a native application for browsing the server list, I've started on a C++/Qt GUI application. At some point it will probably grow more to let you actually launch the game, but that's for another day! You can get pre-built packages for Debian here: https://jenkins.rm5248.com/job/Renegade-X_Launcher/ Or get the code from here: https://github.com/rm5248/RenegadeXLauncher I probably wont work on it this weekend at all, but it's up incase anybody has an urge to update it.

@testman re: bad z-order: that's the second screenshot, the one with the white spots(black for you). It looks like this is actually a problem with a volume/emitter or something - on Field, I get a whole lot of small cubes on the river. It's just that because it's white, it looks an awful lot like bad Z-ordering, but it doesn't appear to actually be that. As for the DX11, I just tried it on my system and I got a black screen as well, but I noticed that UE3ShaderCompiler.exe is running when I try to start the game. It took a while for this to happen(15+ minutes), and the game does start after that point, but I can't use any of the menus and my mouse goes in and out of view. I think it did crash a few times when it was compiling the shaders, so I'm wondering if I need to delete my cache of shaders and have UE3 recompile them...

Here are some notes from me on getting Ren-x to work. I installed through Lutris, as the script in the wiki doesn't seem to install all of the proper dependencies into wine. Also I haven't used wine much before, so the lutris route was the easiest way. Note that I didn't install the lutris package through apt(even though it is on their website through a deb package) because when I tried to install it, it complained about unrar not being installed, so at least for Debian their package is broken. I don't know if Ubuntu has the same problem. I'm running Debian 9 with the latest NVidia drivers(410.93), and the game does run, albeit I do get some weird graphics issues. Since I'm on a 64-bit system, I did have to install some 32-bit compatability libraries(at least vulkan to use the DXVK configuration in the Lutris install script). To do that, do the following: sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install libvulkan1:i386 Some strange things found so far: I had to go into the lutris launcher, right click on the game and go to 'Wine configuration', go to the 'Graphics' tab, and select 'Automatically capture the mouse in full-screen windows'. Without this, I couldn't look around as the mouse would stop at the edge of the screen and also go to the other screen when playing. The launcher runs, but if I have a server selected and then click the 'refresh' button it crashes. Starting the game from the launcher works, but it is very unreliable. I need to click the launch button a few times for it to launch, and when it does it will pop up an error about not being able to start. This error doesn't seem to actually be bad though, as the game will still run. On certain maps, I have some really weird graphics issues(see attached image). Any thoughts on what this could be? Related to the weird graphics, some places are also completely white with some bad Z ordering, e.g. the texture doesn't exist. Some maps are worse than others. I haven't played an online game yet(will do shortly), but overall it's not completely unplayable at least.