Agent

As far as I'm aware, you haven't been banned from anything, nor would you ever be banned for anything that's currently in your post. Can you please clarify what makes you believe you've been banned, and where? If it's on these forums, my only thought is maybe you happen to share an IP address with an old spam bot or something, since there's only 4 human users banned on these forums. Edit: Skimming through logs, nobody's been banned anywhere in the last 24 hours. If you're getting a ban message anywhere, it's almost certainly a false positive. If that's the case, can you send me a screenshot of the ban message and the IP address you're using via a PM so I can try to take a closer look / narrow down the cause? Thanks, Agent

There has been no greater pleasure than getting to work alongside you on Renegade X over the years. Alongside a great deal of support, advice, and motivation, there is no way I would be where I am in life without Renegade X and all the work you and the rest of the team put into it. Renegade X isn't just one of my favorite games of all time, but it's helped me meet the most wonderful people I've ever met, and opened up career options to boot. Thank you for making that possible. For one of the few times in my life, I feel at a loss of words. I'd never worked with anyone so long on a project I care so much about. Tears have been shed. One of our great pillars has been lost. We will push forward though, and will continue to make you proud. I look forward to seeing you around - Jessica

Please do not intentionally rejoin a server, repeatedly, after being kicked from said server. Players are free to do as they wish on public servers, including trying to organize a small play session and kicking whatever players for whatever reason they may so choose, absent server rules otherwise (official servers being an example of prohibiting both of those things) or global rules otherwise (kicks must not be used as a tool for harassment). Perhaps we need to implement a minimum amount of time before a player is allowed to rejoin after being vote kicked. I'll pitch the idea internally of having a public private server (passworded, but with the password in the title), to facilitate small groups being able to play together without as much interference. Also, there's absolutely no need to be rude to eachother. Since the topic isn't going to produce further constructive conversation, the thread is locked.

@isupreme I don't disagree with you, and we're discussing internally on how we can adjust the phrasing. I didn't know the GDI intro bit myself either initially, and I bet it's probably rubbed others the wrong way who weren't familiar with it. If you have any alternatives to suggest, please feel free to toss them in the thread

I'm trying to remember what our previous analysis was, but iirc this bug was narrowed down to how UDK makes a specific Windows API call during reinitialization of the sound engine. I think we were originally planning on just reinitializing it in a DllBind, potentially in such a way that would also allow you to select the audio device you want to use, as a bonus. I would have to reach out to the person who did that analysis previously to get finer details, since I can't seem to find notes of it anywhere anymore sadly. Glancing at the above, it's worth noting that the failover stuff still goes through ServerTravel. It sounds like the idea is mostly to try to ensure that the client attempts reconnect after the server has fully loaded the level, in order to minimize the opportunity for the garbage collector to run? Am I understanding this approach correctly?

Please @ me if you see or experience this elsewhere; the only other time I've seen anything like this, it turned out to be a weird browser extension that just didn't play well with the forums.

gay is not an inherently "bad" word; I for one consider it rather positive. It's when misused in aggressive contexts to harass others that it becomes problematic. Aggressors then just end up subverting filters (i.e: g4y), and it becomes an endless game of cat an mouse that only really punishes those who weren't necessarily using words in a hostile way. At best, you end up with people veiling their hostilities behind other words that are less egregious, making it harder to address the underlying behavior: being an extremely bigoted or toxic ass.

Time for an [Official] Furrygade X server

Hey there @AgentPigleton, It looks like by bad luck, you're being affected by a chat ban that was intended for a different player entirely. I've added an exemption that should allow you to play normally, as long as you're using Steam. Please feel free to shoot me a message on here or (preferably) Discord if you run into any issues. Sorry for any inconvenience!

I tend to agree, although we could immediately end any vote once half of eligible voters have voted yes (or alternatively, half have voted no).

Perhaps we could just make it easier to stop the harvester, such as by providing a default stop location so that commanders don't always have to explicitly set one. This default could maybe be set by the level designer, or just set to the refinery. That would also make a vote easier to implement to stop the harvester if there's no commander or the scenarios you mentioned.

Any slur or bigoted remarks will put you at great risk of being muted; this is probably the fastest way to get muted. Using those in your name, especially if you're already muted, will probably be met with a warning/kick/ban depending on context. Hack/cheat distribution or development, encouraging others to use hacks/cheats/severe glitches, encouraging others to break rules in general. Otherwise it's just normal stuff like don't be hateful towards or harass others. So, I guess the question here is more "when does it become harassment?", and this is going to depend a lot on how the receiving person takes it, whether others agree that it was offensive, and whether this person's been targeted before (especially by the same person). In general, don't make public comments or jokes at other people's expense if you're not really buds with them or otherwise are sure they aren't going to complain to a moderator about it. The receiving person complaining/reporting to a moderator is probably one of the most significant bits though. Generally if nobody complains, we either just don't know about it or just assume it's a joke that nobody cares about. Nothing's immediately coming to mind. It's generally encouraged that folks are warned first, but this step often doesn't actually get taken for a host of reasons. For reports, or anything that requires team discussion before acting, it's common that a mute isn't placed until well after the incident actually occurred, and by then it can be harder to actually track down or reach out to the person. Also if someone's been warned or muted in the recent past for similar to what's being reported, action is more likely to follow through than a simple warning. Anything deemed egregious enough will skip warnings as well. For your current mute specifically, you were actually probably the least egregious offender of the 4 who were all muted for 2 weeks each. Someone reported some extremely bigoted stuff from in-game to the team, it was then brought up and discussed among the moderator team, and pretty much anybody involved just got chat banned for 2 weeks. That being said, it's probably not a great idea to wish death upon folks or to say "no lives matter", especially if others in the chat are being terribly racist and littering it with slurs. Doing so really just encourages the more egregious offenders to keep going, in addition to still being distasteful. Reading through those chat logs was just gut-retching, and not what we'd want players to have to be exposed to, especially if they're new players. This is true. For a while now (probably at least 5 months or so) I've been trying to encourage more active moderation and more team-wide responsibility/discussion. One goal was to increase team responsibility, so no longer would any individual be responsible or blamable for every mute they place, but rather the moderation team as a whole, since anything beyond 24 hours would need to be discussed as a team. This helped ensure folks they were being treated fairly as well. Another goal was to hopefully spread out responsibility for receiving and handling user reports, since for a while I was receiving the majority of them, most of which were just handled by pointing people to server moderators instead. I still probably receive the bulk of the user reports though, so typically I triage (basically make sure it's valid, collect any relevant logs, and forward) the report to the greater moderator team and query for opinions to see if there's consensus. Time constraints are still a thing though -- with DDoS attacks going on, there were some weeks where I was spending as much time doing RenX-related stuff as I was with my full time job, putting a huge strain on personal life and relationships (which I think @SMayhew could attest to). It wasn't uncommon that I just didn't even have enough time or energy left to even cook on some days. A consequence of that was I just didn't really have the time or patience to keep going through what felt like the same exact discussions every time which always ended up feeling like an endless cycle of warnings and hand holding, nor did I want to distract other folk who were really focused and working hard on trying to mitigate attacks. These issues still needed to be addressed though, so chat bans got entered, and things just moved on. More recently, normalcy is returning so those rapid responses have gone back to wider discussions that then get retroactively acted upon, such as with these 4 bans. Not everything is the same though, and we're still trying to be more responsive moderation-wise and trying to be more responsible for what happens in the game. I don't think anybody wants players feeling like they're being bullied by the community and pushed out the game, and the same certainly goes to developers and moderators as well. We've brought on new moderators who were active in the community servers, as part of the new official servers. The new and active moderators have been doing a great job relaying reports to the moderation team as a whole, greatly improving our responsiveness. The previous unanimous-consent mod-jury thing has been replaced with moderator team consensus instead as well, meaning we're actually able to process through reports faster and more voices are being involved in every part. A lot of what I've posted is really just repeating or updating on what's happened since the moderator guidelines were last updated, which are currently posted here (I'll update these sometime in the next few days if I remember to): I'm not sure if those answers were quite what you looking for, but I hope that at least clarifies what's been going on.

Thanks! As an update, these Rx_VersionCheck_Lib related crashes should be resolved in the next game patch.

Also if you've experienced this crash please post both a UDK log file and (especially if deleting the DLL resolves your issue) the NativeLog.txt file from the UserCode dirs. It seems there's a more than a few potential crash sources around this.

If you're facing this issue, please delete Rx_VersionCheck_Lib.dll from the Binaries\Win32\UserCode and Binaries\Win64\UserCode folders and report back whether or not the issue is fixed. It looks like this is likely going to be an issue there, rather than the launcher itself -- the launcher update just happened to coincide in timing with some other changes. The only feature lost from deleting this DLL, should be that pings will fail to display in the server list. I definitely need feedback as to whether this resolves the issues for others or not, as after deleting this DLL I haven't been able to reproduce this crash. I have some fixes locally but they will end up requiring a game patch, which is generally a slightly longer process than the launcher patches, so it may take a few days. I might also just rewrite the ping functionality in C/C++ instead since it's the last of 2 C# libs we have left.

Can you post crash logs please?

Jokes aside, it'll probably get fixed eventually. It would be nice though if folks would choose not to be so hostile though. It is much more difficult for devs to be motivated, or for me to try to motivate other devs, when players are just being constantly and openly hostile every time someone from the team (or anywhere really) speaks their quick opinion or thoughts. Let's try to foster a more positive environment, instead of a toxic one. People won't work in a toxic environment; in a non-volunteer project that's just workplace abuse.

Yup, `OldRenScore` is a slight misnomer now since the balancing code has sort of spread out and isn't just your previous match's score (which to be honest, I'd actually assumed it still was). To further clarify, it looks like your initial OldRenScore IS populated based on your previous server-local performance (using the aforementioned MMR stuff) as so: NewPRI.OldRenScore = PlayerMonitor.MyPlayersInfo[PlayerListIndex].SavedScore / PlayerMonitor.MyPlayersInfo[PlayerListIndex].JoinedGame; And the server-local score information is maintained via Rx_PlayerMonitor: class Rx_PlayerMonitor extends Actor config(PlayerMonitor); struct PlayersInfo { var string PlayerName; var string UUID; var float SavedScore; var float LastGameScore; var int JoinedGame; }; var config Array<PlayersInfo> MyPlayersInfo; function AddNewinfo(string ID,float Score,string MyName) { local PlayersInfo NewInfo; NewInfo.UUID = ID; NewInfo.SavedScore = Score; NewInfo.LastGameScore = Score; NewInfo.JoinedGame = 1; NewInfo.PlayerName = MyName; MyPlayersInfo.AddItem(NewInfo); SaveConfig(); } function float UpdateInfo(Rx_Controller Player) { local string PlayerID; local float Score; local int Index; PlayerID = Player.PlayerUUID; Score = CalcPlayerScore(Rx_PRI(Player.PlayerReplicationInfo)); Index = MyPlayersInfo.Find('UUID',PlayerID); if(Index >= 0) { MyPlayersInfo[Index].LastGameScore = Score; MyPlayersInfo[Index].SavedScore += Score; SaveConfig(); } else AddNewInfo(PlayerID,Score,Player.PlayerReplicationInfo.PlayerName); // shouldn't really happen, but just in case return Score; } function float CalcPlayerScore(Rx_Pri pri) { local float ret; ret = pri.GetRenScore(); if(ret < 1.0) ret = 0.0; else ret = loge(pri.GetRenScore()); if(pri.GetRenKills() - pri.Deaths > 0) ret += loge((pri.GetRenKills() - pri.Deaths) / 2.0); return ret; } The kill inclusion RypeL mentioned is seen above in CalcPlayerScore(), for anybody who wants to get a closer look into how things are presently setup.

The key issue with using past-match data is that there is not yet a unique or universal user ID that can be used and trusted -- usernames can be changed, Steam isn't an enforced requirement, we haven't yet implemented any login system, and any hardware-based ID is inherently not a user ID. We do still hope to implement a login system to fix this issue, however work has not actually been started on it beyond the UMLs I drafted to show the general login flow and architecture. The key objectives of that login system are to provide a user ID that is always available, always unique, and always trustworthy/verified. This would have massive (but positive) implications for our infrastructure, necessitating updates to the leaderboard and other systems to use this ID. After that the ID would almost certainly end up being incorporated into some sort of server-local or global long-term balancing system, likely tied into leaderboard statistics and possibly displayed in some way on the leaderboard. Eventually I'd love to be able to hover over a user's forum profile, and see their leaderboard rank or have their leaderboard profile integrated with the forum profile page. There's a lot of moving parts though. In order to keep user credentials secure for example, no UnrealScript code can be trusted to store or manage that data directly (since a malicious server could theoretically use a mutator to steal someone's login credentials or session). Game clients can't pass any of their login information, or even be capable of passing their login information (beyond the unverified user ID) to the game server, for exactly that reason. Thus all actual login management code essentially has to be tied into our DLLBinds, which would be written in C/C++. This DLLBind would have to manage any web API calls to login or register, would have to interact with the Windows registry to store any cached login token, and would have to be polled for login status by the UnrealScript code, etc. The UnrealScript side would actually be relatively simple, since it'd only have to interact with the Flash-based UI for logins, and communicate those values to the DLLBind. Since the game servers can't necessarily trust data provided by the game clients, and since the server list can't necessarily trust data provided by the game servers, user ID validation requires a top-down approach of sorts: the game client tells the server list it's joining a server, the server list passes this on to the verification endpoint (likely somewhere on this website) and waits for a response, then the server list marks the player as verified and informs the game server (or if a negative response is received, kicks the client for an invalid login). That web API that manages the requests for registration, login, and validation requires PHP familiarity, and would have to interact with this forum software's own REST API to manage those requests effectively. What I'm trying to say with the above is, it's not a trivial task to implement a trustworthy and reliable user ID. It is doable, and the way to get there has been planned out. We just haven't gotten to it yet though, since it requires all of those moving parts: Flash (login/registration UI), UnrealScript (tie the UI to the DLLBind), C/C++ (Jupiter / server list changes, DLLBind for credential and API call management), Windows registry (authentication caching), PHP (authentication API), etc. It's a multiple-person task, and would likely require the combined efforts of several developers, just because no single person on the team is familiar with all of those components. I for example have never touched Flash and have limited exposure to PHP. Only 1 active dev is familiar with Flash / Scaleform. I'm not sure if anybody on the team is actually comfortable with PHP, though there is someone who might help us out on that front. I'm the only one who's worked on Jupiter (which powers the server list) in any significant capacity, so that (and probably the DLLBind) would end up having to fall on me to implement. This doesn't mean it won't happen though -- the process was already planned out because I'd planned for us to tackle this at some point. Our priorities have been elsewhere though, and I for example have been working more on development resources and infrastructure in the background, than I have actual code. Sometimes it might sound like I'm exaggerating the complexity of a task, but I'm actually trying to ensure we have every base covered and that we don't have to worry about massive security holes or such. Software developers, myself included especially, are notorious for underestimating the time or effort required for a piece of work, because unless something has been planned out in detail, it's impossible to actually know what's all required. We do have the above mapped out though; we know exactly how much work it is: somewhat substantial, but not too substantial as to rule out. The original game server architecture for RenX is also inherently server centric, and a lot of that remains today. Originally, we didn't even have the capability to monitor in-game activity and track player performance like we do now via the leaderboard's infrastructure. Originally there we didn't have the capability for global moderators, or any sort of real global moderation. Servers are entirely community provided, and they're expected to be capable of functioning on their own even if the server list is down for example. We're definitely better off than we were before though in terms of infrastructure capability, and having what we have now definitely does improve our ability to implement things like user IDs. We've tried quick-and-dirty solutions like using combinations of existing IDs to calculate player MMRs for example, but those are inherently going to always be limited to that specific server. The next step, a global balancing system, absolutely needs all of the above, and I hope we get to start work on that soon. Beyond that, once we have a user ID that we can rely upon, we can start hammering out the details for a better balancing algorithm. Right now, we can't take previous match data for the aforementioned reason (we can't reliably track it), so the best we can do is somewhat track player data on a per-server level, or to use the data for any match just completed (which is what the shuffling algorithm above does). If anybody is willing to incrementally improve the existing approaches, I have no doubt that server owners would be more than happy to test those changes out. I have no doubt that a reasonable code change could be incorporated into the base game. Also, sorry for the wall of text lol, hadn't planned to type nearly that much.

I feel like there is some miscommunication possibly going on -- to clarify, there is (and has been for a long time), the following shuffle algorithm by default: private static function ShuffleTeamsNextMatch() { local Array<Rx_Controller> Team1, Team2, All; local float Team1Score, Team2Score; local int GDICount, NodCount; local Rx_Controller PC, Highest; local Rx_Mutator Rx_Mut; LogInternal("autobal: shuffle" ); Rx_Mut = `RxGameObject.GetBaseRXMutator(); if (Rx_Mut != None) { Rx_Mut.OnBeforeTeamShuffling(); } if (Rx_Mut != None) { if(Rx_Mut.ShuffleTeamsNextMatch()) return; } // Gather all Human Players foreach `WorldInfoObject.AllControllers(class'Rx_Controller', PC) { if ( (PC.PlayerReplicationInfo != None) && (PC.PlayerReplicationInfo.Team != None) ) All.AddItem(PC); } // Sort them all into 2 teams. while (All.Length > 0) { Highest = None; foreach All(PC) { if (Highest == None) Highest = PC; else if (Rx_PRI(PC.PlayerReplicationInfo).OldRenScore > Rx_PRI(Highest.PlayerReplicationInfo).OldRenScore) Highest = PC; } All.RemoveItem(Highest); if (Team1Score <= Team2Score) { Team1.AddItem(Highest); Team1Score += Rx_PRI(Highest.PlayerReplicationInfo).OldRenScore; } else { Team2.AddItem(Highest); Team2Score += Rx_PRI(Highest.PlayerReplicationInfo).OldRenScore; } // If the small team + the rest is less than the larger team, then place all remaining players in the small team. if (Team1.Length >= Team2.Length + All.Length) { // Dump the rest in Team2. foreach All(PC) Team2.AddItem(PC); break; } else if (Team2.Length >= Team1.Length + All.Length) { // Dump the rest in Team1. foreach All(PC) Team1.AddItem(PC); break; } } // Figure out which team will be which faction. Just do the one that moves the least. foreach Team1(PC) { if (PC.PlayerReplicationInfo.Team.TeamIndex == 0) ++GDICount; else ++NodCount; } if (GDICount >= NodCount) { // Team 1 go GDI, Team 2 go Nod foreach Team1(PC) `RxEngineObject.AddGDIPlayer(PC.PlayerReplicationInfo); foreach Team2(PC) `RxEngineObject.AddNodPlayer(PC.PlayerReplicationInfo); } else { // Team 1 go Nod, Team 2 go GDI foreach Team1(PC) `RxEngineObject.AddNodPlayer(PC.PlayerReplicationInfo); foreach Team2(PC) `RxEngineObject.AddGDIPlayer(PC.PlayerReplicationInfo); } if (Rx_Mut != None) { Rx_Mut.OnAfterTeamShuffling(); } // Terribly unoptimized, but done. The above code essentially sorts players into teams based on the OldRenScore from the just completed match, which to the best of my understanding is akin to how Renegade sorted teams. I'm not sure why these mutator hooks exist in this particular place, nor why they only check the first mutator in the mutator list, but I suppose those are there as well to make it possible for mutators to adjust team balancing. A leaderboard based/influenced, or even MMR based/influenced, shuffling option has been planned for some time. I was under the impression something had already been implemented for MMR-based shuffling, however I cannot seem to find an algorithm implementation for it at this time.

The clock at the bottom is often wrong if I recall correctly; I think they may be checking time in separate ways.

Yeah, at the time of patch I believe support was > 60%. Like I said, it was originally planned to add an option to be able to use the classic layout -- part of the refactoring I did was to allow support for any theoretical bindings for radio commands, and to also allow for radio command localization. A function already exists to switch radio commands to the original bindings, it just wasn't ever bound to any UI piece or any exec function (console command). Programatically, it's very to rearrange radio commands now, so I'm sure we can change it or even move it to a config in the future. Just as an example, here's the code sitting in Rx_HUD that actually changes it back to the old layout: function SetRadioCommandsClassic() { local int index; // Populate Ctrl for (index = 0; index < 10; ++index) { RadioCommandsCtrl[index] = index; } // Populate Alt for (index = 0; index < 10; ++index) { RadioCommandsAlt[index] = index + 10; } // Populate Ctrl + Alt for (index = 0; index < 10; ++index) { RadioCommandsCtrlAlt[index] = index + 20; } } An option or command or config setting will be added.

An option to retain the classic layout was originally intended; I think it just got lost in the noise.

One thing to keep in mind that the PUG times are setup to cover as many players as possible, ranging from western NA to eastern EU. should hopefully be able to join. PUG time on the US west coast for example is 11 AM. Logistically it probably can't be moved back too much more.

I have absolutely no intention of ever moving mine and vehicle limits out of Rx_MapInfo; I was one of the people who strongly supported it being moved there to begin with lol. What I meant was that maps should be able to functional and that INI files should be optional / only needed to display info in the skirmish menu.