Agent

Yeah, that's part of why I suggested what I did; the only thing that I anticipate even maybe changing out of the things mentioned would be the mining system. Wouldn't be too hard to remove and replace that small bit, though. The unintuitive limits are important enough in the current system that they must be explained so that players don't mine poorly. It's one of those dumb broken mechanics carried over from Renegade -- nobody is going to understand it unless they played Renegade.

As long as we're using this broken mining system with limits, there will always be a correct way and a wrong way to use mines.

I'd like to expand on this a bit to make it understandable to a 5 year-old who's never played an RTS or FPS before, and take some inspiration from classic Ren in terms of the first 3 steps. Here's a full start-to-finish script, that i think would be nearly ideal. The above doesn't really explain the following though, and may want to get worked on a bit: 1) EMP Grenades 2) Smoke Grenades 3) Air strikes 4) Repair tool 5) How to use certain characters for certain tasks 6) The arsenal of neither side is really explored at all in-depth. 7) Crates other than spy crates I leave strategy out of this in general, because honestly most of that can just be learned in-game. As long as they know not to leave their vehicles out in the open, what a rush is, and general mechanics they should be fine. That's the kind of stuff you'd generally expect to either read up on or learn through playing the game.

There's actually a tiny bit of reworking going on regarding points, that might discourage classic point-whoring. I had previously tossed around the idea of using some sort of score-based or recommendation-based rank to select a commander by default, though. Back on topic though, it'd probably be better to just have q-spotting actually share some sort of noticeable indicator (separate from the commander spotting indicator).

Seems like this would be unnecessary if Yosh still plans to implement the commander stuff into the base game.

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).