Agent

This is the data stored in each entry, in a custom database format I wrote: uint64_t steam_id, total_score; uint32_t total_kills, total_deaths, total_headshot_kills, total_vehicle_kills, total_building_kills, total_defence_kills, total_captures, total_game_time, total_games, total_gdi_games, total_nod_games, total_wins, total_gdi_wins, total_nod_wins, total_beacon_placements, total_beacon_disarms, total_proxy_placements, total_proxy_disarms, // totals (15) top_score, top_kills, most_deaths, top_headshot_kills, top_vehicle_kills, top_building_kills, top_defence_kills, top_captures, top_game_time, top_beacon_placements, top_beacon_disarms, top_proxy_placements, top_proxy_disarms, // tops (12) most_recent_ip; // other (1) time_t last_game; Jupiter::StringS most_recent_name;

'Rx_TeamInfo.MineCount' is only ever incremented in 'Rx_Weapon_ProxyC4', which 'Rx_Weapon_ATMine' does not extend. I also cannot replicate this issue; please provide a video or steps to otherwise replicate (and also double check that this bug actually exists).

It's quite obvious that the issue was while playing on Field_Day, if you bother watching the linked video.

That's interesting. It sounds like some sort of replication issue.

Another fun PUG this week; looking forward to the next!

I still want this translated into a wiki.

If an APC or pretty much anything other than a buggy/humvee can get around then yeah that could be an issue. I appreciate the buggy/humvee being able to do so, because it's one of those difficult things to pull off that can be fatally risky if you're not quick enough. Like I said, buggys getting around on Walls were well known, but most of us found it interesting rather than abusive. Getting around stuff with various types of tanks, however, was definitely not intended.

It'd be better to put a visible object there, instead of a blocking volume Edit: Also, the only situation I'm aware of involving Walls is that you can get a humvee or buggy around the boundary, but that's it.

If whiteout has major issues, then yes, whiteout needs to be fixed. That doesn't mean invisible blocking volumes. Also, this thread is about Walls, Henk; nothing about Whiteout is mentioned in the subject line.

This route was well-known before the patch was pushed; I have no problem with it. ...Especially since if you mess up at all, you're dead! =D

In general I'm supportive of making mines more intuitive so that they actually make sense to new players; the concepts of mine-limits, over-mining, and "a perfect way to mine" aren't at all intuitive, and make the game more difficult for players to learn and enjoy. Even after playing Renegade and Renegade-X for years, I still can't stand the mining system; it's an obnoxious mechanism that seriously needs to be replaced. I'm unsure as to if I support a "door-hacking" type system or not; it's more code, but it does mostly make sense. For some insight on one possible solution, here's a quick little screenshot from one of the internal forums: Maybe a similar poll should be made publicly.

If a player picks up a crate and all crate types have a probability of 0, the crate system will default to the last crate type in the crate type list. For now, the last crate in the list the TS Vehicle crate. This functionality was never meant to be reachable, and isn't reachable in a properly configured server because there are crates other than vehicle crates. Servers owners shouldn't misconfigure their server; this is a server configuration issue.

Please don't. Fixed rotations are an old mechanic that's been replaced by voting mechanics in pretty much every game that isn't story based.

So you're saying the splash was too large? Sounds odd to try to fix a large splash with a delay.

I absolutely preferred Remote C4 as being instantaneously ready; suicide engineers weren't really an issue in the previous patch, and honestly have no idea why this was added. It's not because Engineer's were too strong, that's for sure.

I /eventually/ plan to do some elaborate stuff using the stats bot/server to push extensive ladder data about players. This data is already actively collected and stored, so if you need access to it, let me know.

Just turn the water into Lava; they'll learn. Edit: I can't remember, is this a flying map?

Sounds like an awesome idea tbh

This definitely wasn't a particularly well coordinated PUG in terms of team-play. Several rushes were still organized, but overall it was overly difficult to coordinate things and people ended up playing closer to that of a standard pub game. This wouldn't be too difficult to remedy -- just make sure there's at least one decent team captain that can coordinate their team, and give them priority speaker so that they're easier to hear and understand. This way, there's a singular and clear action to take, and it's easier to hear and understand what to do. There's also certain options available in large player-count games such as these, like organizing split rushes (one group pushes tanks through the vehicle path while a Mobius or Gunner group pushes through infantry path), which weren't really effectively utilized too much during the games. Seeing more proper strategy would be greatly beneficial, but would absolutely require a high level of coordination, which in turns requires an exceptional team captain and players who are willing to listen.

Re: IRC in launcher This should be relatively easy to implement, given that I've already written an IRC client library in C++ -- it shouldn't be too hard to communicate with C# code to utilize it, though I might have to make a custom API for it? I have nearly zero experience with C#. I also have zero experience with implementing user interfaces. Yosh, RypeL, or somebody else would likely have to implement the user interface, though I could certainly do the back-end stuff. Since it'd most likely be a global chatbox (rather than per-server), we'd probably just have it connect to the #RenegadeX channel (similar to RypeL's old launcher). Queue: Since the stats bot already knows the population levels of servers in real-time, it'd be very easy to utilize it to implement a queue system (clients connect to the bot, send a queue_request, and wait for a queue_proceed event), so that clients don't have to constantly refresh the launcher. In addition, I'd be able to set up the queue such that if the number of queued players goes above a certain number (say 10), it just throws them into another server that can fit all of the queued players (perhaps with a bias towards servers running on the same IP).

Speed crates are going to be less common by default in the upcoming patch iirc.

If there's interest, just hop on TeamSpeak at the usual time and I'll toss a server up for it.

Another very pleasurable PUG, and likely the closest game of Islands I've ever played. Good plays all around.

I shall be here ^-^

This was intentionally added back in Phase 2 beta testing (closed beta 9, for those curious).