Agent

https://renegade-x.com/discord

The player count modifier mutator is actually banned from the forums, though it'll be irrelevant anyways next patch.

Thanks for the post; fixed. Feel free to PM me on Discord next time to get my attention faster.

So, there's a few topics to highlight. Let's start with the part @ShrewdTactician mentioned we plan to improve. Downloading mechanism The current downloading mechanism uses HTTP downloads, technically across multiple threads but only allowing a single HTTP request to actually process at a time. Once upon a time, the launcher actually attempted to download every single file simultaneously, which led to issues where people's downloads would cease halfway. While we could get a slight performance boost by setting up an HTTP thread pool to permit some arbitrary number of simultaneous downloads (~4), it's not currently worth the risk of reintroducing the previous issue where downloads ceased entirely. Such a regression would require additional development resources to resolve, which could be caused by anything from running out of socket descriptors, to threads failing to spawn, to unreported socket timeouts/closures. Stability is far more important than performance here, especially when there are limited development resources. HTTP mirror selection A critical part of the HTTP download mechanism is our mirror selection algorithm, since we only download from one of the mirrors at a time. It's not based on ping though (though it was in the past). Instead, we send out an HTTP request to every mirror listed for a small (10 KB) file, and we queue up the mirrors in the order that the requests complete; if you have connectivity problems with a mirror (i.e: it goes down), you'll failover to the next server in the queue. So theoretically, the server you are downloading from should be the one you have the best connection to. However it's not guaranteed that the mirror will have a particularly large pipe. HTTP mirror maintenance While this isn't directly a part of the launcher, it's definitely worth noting that all of the distribution mirrors are donated by various members of the community such as @Cronus, @iTweek., and Speedy059. Those people are paying out of their own pockets for those mirrors. As such there's minimal requirements and quality control for the majority of these mirrors, and their pipe sizes cannot be guaranteed. Downloading patch data at 100 Mb/s (12.5 MB/s) should be considered optimal given that many of the mirrors only have a 100 Mb/s pipe. Anything beyond 100 Mb/s is excess. CDN Performance This isn't directly a part of the launcher, but the official downloads are served through our own little adhoc CDN formed by a subset of the HTTP mirrors. In addition to the details mentioned in "HTTP mirror maintenance", there's actually very little going on in the background to make sure you're getting the best mirror -- currently, it's just a round-robin setup. Some of the files may be moved from the CDN in the future to a higher availability platform (such as AWS), which I will pay for out of my own pocket, but this is not presently a high priority item. This would also only affect very commonly accessed items, such as the installer and some versioning files; larger or less frequently downloaded files such as the SDK would not be migrated. Future downloading mechanism(s) The aforementioned processes will actually be improved if/when we add the p2p based solution @ShrewdTactician hinted at by downloading simultaneously from multiple sources and therefore also providing significantly better load distribution and download performance. The above process will still exist though as a fallback, because not all users can actually use p2p protocols for a wide range of reasons. Download speed calculation The download speed is calculated simply by getting the average speed over a number of data points as progress is made on downloads; this is not going to be identical to what Task Manager might say, nor should it be. Task Manager is showing you your exact total download speed over the last second. The launcher just calculates the average over the last 10 samples to give the user an idea of how fast they're downloading on average. So if for example the launcher collects these points over the course of 5 seconds {5, 5, 5, 5, 5, 5, 5, 5, 2, 2}, where these numbers are in MB/s, the launcher would report 4.4 MB/s while Task Manager would report 2 MB/s. Neither of these numbers are actually wrong; they're just calculated differently, and the number the launcher currently reports will be more useful to the average user trying to estimate how long the download's going to take. Verification The verification phase determines which files are necessary to download by downloading the patch instructions and validating hashes of every single file by comparing SHA256 hashes of files to the hashes in the instructions file. If the file is missing, or the existing file's hash does not match the new files hash, the file is going to need to be downloaded. This process actually runs in parallel with the downloading phase -- as files are determined necessary, they're queued up to be downloaded. The primary constraint here is going to be disk operations, so SSDs will be faster than HDDs for example. This process could probably be optimized so that we don't need to recalculate the hashes of files that haven't been modified, but it won't anytime in the foreseeable future. Patch files There are 2 types of patch files the patcher will download: deltas and fulls. Deltas contain the differences between the old version of a file and the new version of the file, while fulls contain the entire file to be downloaded. If you're skipping patches and a file has been updated multiple times, then some of the deltas will be ignored and the full versions will be downloaded instead. If you want a visual aid, take a peek at the patch directories themselves and their file structure. All patch files are compressed -- both the deltas and the full files. Tip Don't be a pretentious cunt when talking to people, and think about problems before calling something a "beginner mistake"; give people benefit of the doubt if you want to come across as a team player who people will want to be around. Don't just come into other people's spaces and complain. Problems and processes are often more complex than they might appear at first glance, so it's important to get as much context as possible when trying to understand a problem.

Please don't necro polls from June. Thread locked.

Yeah, right about half.

Pretty much this. Admittedly, I didn't even know this issue existed?

Updated original post.

You mean any urban levels?

WE PROMISE NOTHING

We host the images on our own server for security, reliability, and performance reasons. So updating the original is not sufficient to update this.

It's certainly possible, but is it desirable? Back when EKT and TmX were around for example, server owners would go decent lengths to seed their servers to encourage players to join (disclaimer: I did this as well with up to 4 simultaneous clients). There is no telling what the future may hold, but if we get a larger active player base again, this practice will likely resume as servers and communities begin to compete for players. It's also conceivable that a player could exploit such a mechanism to prevent another player from joining. If someome really hated Madkill for example, they could theoretically snag his HWID to prevent him from joining a server. If it were implemented, it would need to be a server option.

HWIDs are currently incomplete, and can be expected to be finished in the future.

@DarkSn4ke The permanent link to the Discord is https://renegade-x.com/discord

Why don't we just move mines in destroyed buildings to the front of the mine queue, so that they're the first ones that get deleted when over-mining?

I'm all for removing the Ctrl + Alt menu completely, and replacing a radio command with "Mines!"

Discord seemed to be having issues that day actually, like with people not being able to use the official discord.

An easier to remember (and also permanent) link is https://renegade-x.com/discord

At some point it was a TmX event, but was at some point converted into an official event hosted by TmX/CT since we don't actually have any official game servers to host it on, nor did we have an official TeamSpeak/Discord for players to gather on. As far as Discord goes, here's the link. I'll put it on the front page later: https://renegade-x.com/discord

I'm pretty much against adding "Repairs Made" and "Building Damage". Score is still decent (at least in concept) for ranking player performance. In fact if we add a personal stats box I really wouldn't be against just removing everything but Name, Score and Ping. Adding credits wouldn't be a bad idea though. Already planned, except we want to put the actual veterancy icon next to player names. It's also worth noting though that all of this depends on an active UI developer, which quite frankly we do not have. The primary UI dev on the team already has a large backlog of tasks, in addition to being generally busy.

I expect them to post that they're having an issue with the .msi. That way if there's a legitimate problem with the launcher, we can fix it. That way if there's a legitimate problem with their system, we can try to help fix it. That way we can prevent legitimate permissions problems that come from installing it this way, which actually causes issues with the launcher. This method of installation is neither encouraged nor supported. It's a last resort option.

Is there any public interest in an official Renegade X Discord server? Vote in the poll. I've been poked by a few people about this but the only immediate benefits seem to be organizational.

Yup, that's actually exactly what I had in mind. Could even toss in less useful stats for the round similar to the stats on the global leaderboard.

If you just want to know your own personal deaths, then you probably want extended personal stats box of some sort added to the leaderboard, so you can see less team-relevant data. Could also move KDR there as well, actually.

Replacing the death counter (or KDR) with a vehicle kill counter would probably be a nice addition in terms of actually tracking personal performance compared to to other players -- kills are significantly more important than deaths in this game than deaths. If we do replace the death counter though, it needs to be something genuinely useful to know (such as vehicle kills), as opposed to arbitrary scores with no comprehensive meaning or purpose (something which was discussed internally sometime ago that I was wholeheartedly against). With that said, I am against removing both KDR and the death counter -- people do enjoy seeing these stats, though having both is pretty redundant when there's more important information we could be displaying (such as vehicle kills).