Agent

Accounts are on the back burner primarily due to lack of development resources. We have existing trello cards for it, though nobody has started on it and likely won't. I can give some architectural help since I've already planned it out before @yosh56

Sort of

hahahahaha sorry I forgot these things made posts. Was trying to test something out with the website

View File test test Submitter Agent Submitted 03/26/2018 Category Tools

The leaderboard tracks you solely based on your SteamID, so nothing should change for you. Have fun!

Probably not for the vehicle theater, but I'll add converting the medical center over to the to-do list. Ideally though it'd be nice if @nBab were around to refactor the medical center.

Missing textures and assets? You might want to work with @ShrewdTactician to figure out what's missing, and when the SVN state is fixed poke at @Cronus to generate a new one. I'll look into giving more members of the team access to the SDK creation script in the nearish future.

We should make an "Incompatible Software" thread for general troubleshooting.

@Jedor Restart your launcher, or install the new launcher by downloading here:

I think my favorite implementation for this has been to display a vote during the pre-game so that people can vote for their initial commander based on the player list. It forces people to remember that they need a commander, and also gives something to do other than fly around the map. Players would nominate themselves so that they aren't forced into the role constantly, and would appear on a list of players wanting to be commander that's almost similar to voting for the next level, except it'd make most sense to organize it by votes. This shouldn't be too hard to implement, but would require some UI development that is just generally in high demand and low supply around the team.

There's a bug with the banner images atm.

@Madkill40, @KrypTheBear is definitely not Dutch. He's German (made in Russia).

So I thought I had resolved the cause of this problem, but apparently Google Cloud does some fun caching stuff when we push a file of the same name and size which affected the installer. This should be fully resolved now, and people should be able to download from the download page normally again.

Hey, listen!

3.6MB? I'm impressed.

So basically some sort of overtime?

I mean, bribery is one way to get things moved up in priority I guess?

If there's any issues with the launcher, it'll be narrowed down by in-depth debugging and analysis which to the best of my knowledge nobody has done. Your proposed solution is not sufficient not only for the reasons previously mentioned, but also because it would add complexity to the installation process without any significant performance gain, would remove the ability to resume installation, and would hurt performance on unstable internet connections due to clients having to redownload the entire client (or in your later suggestion, very large chunks) if a single file is corrupted during download. And again, existing infrastructure could not possibly handle the additional data which would double the storage requirements for each mirror. Your proposed solution would take substantially more effort than you realize to implement, substantially more effort than you realize to maintain, and would provide substantially less benefit than you believe. There are many other possible solutions which would require less effort, and provide much greater value to the end client. Such possible solutions include adding a torrent client, downloading multiple files concurrently, downloading from multiple mirrors concurrently, etc.

When we add the torrent client, you will still be able to use the HTTP downloads as you would normally. The launcher will first attempt to use the torrent client though, before failing over to HTTP. This feature has already been discussed in-depth internally and is planned. Showing server names rather than URLs is already planned. I plan to run some benchmarks with the launcher to narrow down any issues with the launcher, if any exist. It's impossible to be reasonably convinced there is or is not an issue without any data to back up such claims. However, we're absolutely not going to change the patch process by consolidating the initial installation into a single or even multiple but still large files, for the reasons aforementioned in my previous post. There is nearly zero benefit to doing so, and would directly harm existing infrastructure. Any possible changes would likely be related to trying to better parallelize tasks, buffer files better to reduce disk I/O, make the existing failover more aggressive (as previously mentioned), or otherwise improve mirror selection (maybe we could adjust it to source from multiple mirrors concurrently, which is one of the primary benefits the torrent client will also provide).

The Renegade X launcher's source code is now publicly available on GitHub! This is the authoritative repository for the Renegade X launcher, and all future development work related to it will be made directly to here. https://github.com/TotemArts/Rx_Launcher If you'd like to contribute to the launcher, feel absolutely free to pick up any open issues and make a pull request.

So breaking down the components of what yo're suggesting: 1: "We should have a drop-down menu to be able to select the source mirror" I actually have 2 issues with exposing mirror selection to the end user. The first one you're probably already familiar with; I don't want to expose mirror selection to the end user because I feel it should be fully automatic -- if it's not selecting the best mirror, we should look into coming up with a better algorithm to select the best mirror. Perhaps we could even implement more aggressive failover, such that if your download speed drops significantly, act as if the mirror has failed and move on to the next. My second issue with this proposal is that it will create some UI inconsistency if/when we add additional download mechanisms, such as peer-to-peer torrent based downloads. Since such a mechanism doesn't have mirrors to select, the UI element would need to be completely hidden from the launcher. This is similar to the first issue where it just makes the launcher feel unpolished and not fully flushed out. 2: "We should make initial installation download a single large zip file" As far as compression goes, all of the patch data is already zip compressed -- there's no potential compression benefit here. The amount of data downloaded will be the same; only the HTTP request overhead would be reduced. Additionally if the user is using a poor connection and downloading a single large file, and the download gets corrupted or the connection fails, then we have to restart the download entirely. We cannot simply resume the download. This contrasts starkly with the current method of downloading -- since you're downloading many smaller files, if one of them is corrupt or if the connection fails, you can just redownload the file from the same or another mirror. You can't accomplish that level of stability using a single large file. Finally, a critical issue with this is that many of the mirrors do not have the necessary storage capacity available to support all of the current patch data in addition to all of the patch data again in a single large zip file. We would have to drop mirrors from the list, which is much more harmful to download performance than the overhead of HTTP requests. 3: "We should make accessing the internal beta client easier, by providing separate server lists for example" The internal beta client is internal -- it's not meant to be used by the public. It's primarily intended for closed testing between developers, moderators, and other occasionally invited guests. There is no desire to make this more easily accessible at this time. 4: "We should have a chat box" Yes, we absolutely should, but it's not a particularly high priority at this time. There are other features we have planned (such as the aforementioned p2p torrent client) that are much more critical to, say, a 1.0 release. For an idea of the current priorities, here's the currently queue'd tasks for the launcher: Apologies for the late response, though these topics have certainly be hashed over and discussed before -- there's not a whole lot of need for re-discussion when no variables have changed.

It should be fixed now; there was a configuration error. Thanks @AlienXAXS for the help debugging.

An out-of-match party system is not in the works, and would be dependent on the implementation of other (larger) items such as a login system which is not currently slated for implementation.

Locking this thread since it's completely off topic and toxic; if you want to bash each other, take it to PMs.

It's also often enabled by accident, due to things like steam running in the background.