Silv

Can't say I disagree with you. Unfortunately chat platform like Discord add the most value to those most "chatty" in a project and that naturally brings the focus of discussions there. Using a forum is nice for long term archived discussions but for quick back and forth discussions chat platforms have a much superior user experience. And gamers in particular are used to have everything on Discord.

Being a meaningful part of a well organized team.

As to why such votes don't exist, usually it's one of two reasons: none of the programmers considers it to be a good use of their free time (remember we're all volunteers) or it was discussed internally and the team thinks it's not a good idea. In this case it seems like a nice idea but as usual the devil is in the detail. Say there's a vote to turn off building damage. The server empties and new people come in who didn't see the vote. Buildings are still indestructible. People post bug reports. Devs waste time figuring out what's going on. Not desirable. Say there's a mitigation that says "Buildings are indestructible", people who aren't experienced with the game still won't know how to turn it off, still generating support requests. But this already makes the change more complicated (sending a message is easy, but it would need to be sent only every so often and not when a building just happens to be in the line of fire, good luck getting it right). Say the mitigation explains how to do votes in sufficient detail for anyone not familiar with the game to find the voting menu. This requires very careful phrasing and a substantial potion of new players would probably still both find it to be too confusing and be annoyed by it. I know for every objection there's an answer but these kinds of things tend to become sufficiently complex with all the consequences and mitigations that people just go "forget about it". Also the people who are actually good at these kinds of changes have quite a bit of work on their plate already seeing that Firestorm is still in development and the team is really rather eager to get it released (I know it may look from the outside that nothing is happening, from the inside it's a very different matter). Compare this to the alternative: social pressure and kick votes which don't require any code change.

Regarding beacons that can be set by server owners. If a beacon limit is configured the game will only allow buying beacons once enough players have connected (though they remain available even after players drop again). This is not enabled on the public TA servers but anyone hosting their own server can use it.

Early game harvester kills don't give that much VP. The VPs gained by killing harvester is 2 x the number of trips the harv has taken (including the current one) since its last destruction, up to a maximum of 40. Killing the harv on its first trip gives 2 VP to all team members. It's nice but 2 VP is something you can also get just by repping a tank for a few seconds and is but1/50th of the VPs you need to level to veteran. The much bigger impact of killing the harv early is economy denial. In particular the first harv dump is necessary for a team to get access to heavier classes and vehicles. Delaying that harv dump while having it yourself creates an imbalance in strength which can be used to gain map control and set the stage for further economy denial. Protecting the harv is pretty easy if you have a halfway competent team, the harv is pretty easy to rep (gives good cover to reps) and it's closer to your base than the enemy's so it's easy to send reinforcements to protect the harv but any attacker that goes down will be out of the fight for much longer. In the early game taking an economical lead is one of the primary objectives along with gaining map control. You're supposed to take out the enemy harv and protect your own. If your team ignores the harv and instead goes straight to fighting the enemy or their base and gets their economy harmed that's the logical consequence of a badly chosen strategy. At the same time even without harvester dumps a team still gets economy and teams can and do fight back from such a position all the time.

Pubs are inherently unbalanceable. When you join a pub you hope to end up in a nice match but there are no guarantees. Match making is an extremely hard problem that AAA games producers struggle with. Pugs are kinda balanced but it's a very different way to play (you get told what team you're on, what your role is, there's a commander from the start, and you are very much expected to listen to the commander). The game however isn't about individual player abilities as much as it may seem so when you get your head shot off for the umpteened time because of some super sniper. I've seen teams that seem to have better players lose plenty of times. On the other hand I can count on one hand the times teams were so utterly unbalanced that the game wasn't winnable for the losing side. If you look at why teams win it's generally a combination of two things: coordination and morale. Teams that act like a team rather than a collection of individuals, supporting each other and making coordinated attacks (e.g. rushes), have a massive force multiplier. On the other hand teams where half the people have already decided they're at a disadvantage are pretty much guaranteed to lose, internal chatter about imbalance often does more than any enemy action. These things can't be caught in code. Kills, repairs, etc can but are a pretty crappy indicator when it comes down to it. Someone who sits in base all game but prevents three sneak attacks that would have destroyed a building will have a lousy score and VP but probably did more to win the game than a frontline tanker. Regarding the specific suggestions: Moving people to a special team is one of those things that sounds easy but it would probably require a lot of effort due to all kinds of internal dependencies and consequences. Just to highlight one: with the current player screen you can't see spectators so doing this would lead to server slots being occupied without that being visible from inside the game. I didn't really understand the point about player allocation and server settings play a role here anyway (there are several different algorithms that a server owner can choose) but as a general point having a new player assigned to you doesn't need to be an advantage. It happens all the time that a team is behind on players, a few unknown players come in filling it back up and then a known strong player gets assigned to the other side. Using the average of both teams would mean that someone joining later into a team that's behind on points will have more VP than the average player who earned it "the hard way". Is that fair? Furthermore it's not uncommon for a team that's behind in overall game state to be ahead in VP so this might actually be counterproductive. A typical reason for such an effect is that a vehicle factory or air strip was destroyed causing the team to kill tanks but not have their own tanks killed, tanks are great sources of VP. (Just to be clear, I may have a TA staff tag but I don't work on these kinds of things so my opinion is worth as much as that of an average player here.)

Try installing this and then launch again.

The issue with selecting a new folder might well be choosing a folder which already has data in it like "C:\Program Files". The launcher needs an empty folder, one can be made from the open folder dialog. With the default location the launcher will handle creating the folder itself so that works.

The preset folder shouldn't be a temp folder. It should install under AppData\Local but that's not a temp folder (AppData\Local\Temp is but that's one directory deeper). AppData\Local is a folder under which a lot of stuff gets installed that's big but only for a specific user.

If you mean downloading on one computer and copying those files over to the others and then running launcher it will verify the files but unless something went wrong with copying the files or a new patch has been released in the meantime it shouldn't need to download anything. Providing the UE3 redist is a good idea as the current version of the launcher doesn't automatically install it, the next version will but it's not out yet.

The launcher should handle it, it will update the game before it lets you join a server.

I like how the effect of all those base defenses combined is that at match start you really only have your half and the central area where you can semi safely move around in. Then you kill a turret or the sentry and new paths open up. On the other side it becomes a narrative of ever increasing vulnerability. Now that the pier is nerfed I wonder if the CC is enough to draw action there. The CC is very exposed, even compared to things like silo on field. Now I don't know the exact range of a sniper but if it's long enough you could very comfortably snipe at the CC from the walls of your own base. It just feels like a suicide run for me to capture it, especially without the usual trick of driving or parachuting in.

If the server kicks you out that means the server was actually at full capacity. Sometimes it fills up quite fast in the time between starting the game and the game actually getting around to connecting to the server. Did you maybe wait a minute between clicking the Renegade X tab and connecting to the server? The launcher doesn't automatically refresh the server list so in that case the 50/64 would not reflect the current situation. That the server list inside the game is broken is a known issue.

Thanks for the update. Didn't even realize that you could actually shoot the other side's ref from the center inf path, that bus does improve things there. It also helpfully stops the inf path from becoming a straight sniper alley. The busses do a good job of making rushes take longer and be easier to spot from the central area which should make them less of a dominant tactic. And they preserve access to the central road from the inf path which could otherwise be effectively suppressed from the enemy inf path. On the other hand they may also help rushes a little. A rush is frequently stuff like rocket solders and the longer they are in line of sight of defenders the easier it is to take them down as building oriented classes are typically not great against infantry so having to go only about 1/3 of the way through clear enemy terrain helps them. On the whole I think they're a good improvement. A few other misc things: Rocket attacks from near the control center are difficult. There's only a very small area (feels like just a few pixels) where the rocket will actually connect and it's hard to spot buildings due to the fog. From near the CC I managed to damage Nod ref and obi with Gunner but couldn't damage GDI ref, agt and guard tower with rocket soldier even though I did get targetting info with them. The inf path is a single mine wide. That means it's gonna be heaven for miners. I see a 30 mine budget, assuming the usual 3 per doorway that's 24 mines needed for buildings on the Nod side and 24/27 (depending on mining pattern of barracks) on the GDI side. Both sides can thus pretty easily spend 6 mines on the inf path and it's possible to spread them well enough apart in the narrow section that disarming them with a single emp grenade will be difficult if it's possible at all. Expect good teams to lock down the inf path hard to the point where it's pretty much impossible to get through. I still believe inf path is going to be absolutely brutal if lost control of. There is simply no base defense at all that's going to intercede because the obi and agt both have vital lines of sight blocked to the point that I can attack every single building in the GDI base (didn't try on Nod side) including the agt without getting shot at by an automated defense. Which also means that if people get the idea of immediately buying rockets and doing an early inf path rush and the opposing team isn't prepared for that they can probably take out one or maybe even two buildings. If I may offer a suggestion, consider a guard tower covering a small part of the inf path or the first entrance. That both discourages early rushes and provides an early stepping stone goal for teams.

First of all this looks great and I absolutely love the different scenery from the usual RenX maps. Some semi-random feedback: Nod base is a bit too dark for my taste, makes it hard to see buildings. When standing on the walkway next to HoN and looking at the windows some of the windows show black and white checker patterns (i.e. black in lower left and upper right corner, white in upper left and lower right). I get that that's supposed to show windows with the curtains half closed but it feels like there's some texture that's not scaled correctly. It's easy to get into the barracks through the infantry path with only minimal AGT hits. Same for PP. All buildings except AGT can be hit from infantry path without being targeted by AGT. It's also easy to cover the bit of infantry path between the buildings with arti/mrls. Combined with the above that makes spamming the infantry path pretty much mandatory. GDI PP has a bit of terrain sticking through the floor near the reactor core. It's easy to shoot AGT and ref from way out on the beach with an arti but you can hit a problem where the arti range is actually too short to do damage. That just feels a bit wrong when it happens. I'm not sure guard towers on the GDI base are really great compared to Nod's turrets. Those guard towers cover a vehicle path so they are likely less effective than turrets. The degree to which the long path allows easy shooting of base defenses makes me wonder if this isn't going to be a constant fight for the long path. Actual playtesting is going to be interesting. Music on the ferris wheel, while absolutely fun at first, very quickly gets stale due to short loop.

If the launcher is installed in a central location, such as C:\Program Files that requires administrative access to write to it will need to ask for administrative rights to update itself. The launcher is by default installed in C:\Program Files and a launcher update has been released yesterday, so that's probably what you're seeing. When you click Join Server the launcher just starts the game. It doesn't do anything that should take any noticeable amount of time before that. The game however can take quite a while before popping up the splash screen in some cases.

If that fixes the problem you've selected an installation directory that you can't write to as a normal user like C:\Program Files\Renegade-X. It's recommended to install to a directory you can write to like "C:\Users\<your-username>\AppData\Local\Renegade-X" (Windows also accepts "%LOCALAPPDATA%\Renegade-X" as a shorthand for the same directory). If you install the game when the launcher runs as administrator you will always need to run the launcher as administrator or you might run into weird bugs.

No progress means the launcher hit an error. Currently error reporting by the launcher is not very good. The most common reason for stalling this early in the update process is that the directory you've selected can't be written to. Are you trying to install to `C:\Program Files` or `C:\Program Files (x86)` or something? If this is the case I recommend the following: Select a new install directory. In the dialog in the directory bar at the top of the dialog enter (without the quotes) `%LOCALAPPDATA%`. Once you press enter it should say something like `<your username> > AppData > Local`. Click on New folder button and create a `RenegadeX` folder. Double click on the new folder. Click on the Select Folder button to close the dialog. Then when you verify it should install properly.

The electron launcher currently doesn't work well on Linux for various reasons. This is known and being worked on.

I mostly agree with what you say. There actually are several anti-voting-spam mechanisms. You can't vote for a map changing vote (change, restart, surrender) more than once a minute. There's also a semi-global per team limit of at most one map changing vote every three minutes. The problem you're seeing is that the timeouts are so low that people who are really determined to vote in another map can easily keep voting until they eventually win a vote once. HUD info spam is, well, you learn to ignore most of it but you're right that there's quite a lot of information there. Unfortunately with these kinds of things you may need information only 1% of the time but it's annoying to pop up an overlay window for them with the risk of getting blindsided. Human centric UI design is unfortunately rather hard. The q-spotting spam (it's generated by pressing `q` when pointing at something) is indeed somewhat annoying. Some of it is legit, people spamming `q` to warn: hey the powerplant is currently under attack. But the system has a hard time prioritizing and summarizing (and I don't think it even tries). And because it's so easy to q-spot it happens a lot. My personal favorite in this regard is "I need repairs" (not a q-spot, but a radio command like it) being sent to everybody from a player on the far side of the map. I don't play offensively much but I don't know if a high degree of zoom really hurts that much. It can help function as binoculars but very few weapons are good at long distance and the ones that are tend to be sniper rifles. Meanwhile being zoomed in really hurts your situation awareness which can easily lead to your demise. The chat frankly isn't great. It's mostly mixed up all kinds of other messages so it's very easy to lose track of what's being said if you don't keep at least half your attention on it. It really boils down to UI design again. Classic Renegade's approach of splitting chat and gameplay messages worked better, albeit at the expense of screen real estate. As for Steam, be careful what you're wishing for. When a previously relatively small community suddenly gets an influx of a large amount of new players that can seriously throw things out of whack. Currently RenX has a good balance between newcomers vs experienced players and I think that's part of what allows the game to still thrive after all those years.

Game version looks the same as the one I have and that's the version that matters. The launcher provides a convenient way to update the game and launch the game but doesn't actually matter for connecting to a server from within the game (and that's the point you're at in the screenshot). Which server did you connect to?

That's not the actual new launcher (just compare the screenshot with what's in the Totem Arts Launcher and look at the dates in the repo to confirm). There are a few launchers floating about but the source of the one that's currently used is not in a public github repo as far as I know.

And thanks for the tutorial for making server-side mutators. Otherwise I wouldn't even have known I could.

This is a server-side mutator that increases the time between map changes. It works via the existing cooldown mechanism for map related votes (restart/change/surrender) per team. The mutator adds an initial team cooldown of 15 minutes upon match start and after a member of a team has proposed a map related vote there is another 15 minutes cooldown. Because the existing code works per team it's still possible to get two map change votes in quick succession, but people can't just keep spamming until a vote passes. There is a pity mechanism for teams that are losing. When a building is destroyed and map related votes are on cooldown for more than 3 minutes the cooldown is reduced to 3 minutes. Note that there's also an already existing personal map related vote cooldown which prevents individual players from proposing a map change more than once per minute. This mutator doesn't change that mechanism. When testing this mutator it's easy to confuse the personal cooldown with the team cooldown, the personal cooldown is checked first and results in a green text whereas the team cooldown shows up as a message near the center of the screen. Installation The mutator is supplied in source form. Extract the "AntiMapChangeSpam" folder to the "Development/Src" folder of a Renegade X SDK installation. Add "+ModEditPackages=AntiMapChangeSpam" to the "[UnrealEd.EditorEngine]" section of "UDKGame/Config/DefaultEngineUDK.ini". Then run compile.bat. The mutator can be added to a server like any other mutator. Configuration The mutator can be configured by creating a configuration file named "UDKAntiMapChangeSpamMutator.ini" with contents (these are the defaults): [AntiMapChangeSpam.AntiMapChangeSpamMutator] ; Time between successive map related votes, per team. MapVoteCooldownSeconds=900 ; Time since match start before the first map related vote for a team can be made. InitialMapVoteCooldownSeconds=900 ; Upper limit of how long the map related vote cooldown can be after a ; building of the team is destroyed. MaxVoteCooldownAfterBuildingDestructionSeconds=180 Note that setting a value to 0 is equivalent to setting it to the default. Use a value of 1 to effectively disable a mechanism. AntiMapChangeSpam.zip