HaTe

Ramjets are stronger against them though. People just need to realize that still.

ah, the old YiP, KH, and NXC days. Brings back some real memories. But screw hourglass haha. Probably was on gz0ne judging by the names. Considering I was a mod there, yes, that is me

with an i7 anything and a gtx 970, you'll get above 60 on ultra.

Games built with UE are highly CPU intensive. The r9 290 is considered the equivalent of the 970 and that is what I own. I get 50-90 FPS (depending on what map and how many people are in-game). My CPU is an i5-4590. I play on ultra, and I think the lowest I've ever seen it drop is about 43. It averages over 60 FPS. Again, it's highly CPU intensive though, so it depends on what CPU you have too.

If I knew how, I would gladly do it. It's truly important that this does happen.

Renegade's developers themselves have been quoted saying that they believe that the game and their maps made around it are made for 8v8-16v16's. Yet people vastly enjoy having far more people playing than that. If Renegade servers had limited their playercount to 32, many of the servers and communities would have died off much faster than they did. So the game was literally built for 32 people max, yet the majority of people enjoyed having 40-50 people in public servers. I don't think increasing the current playercount by 10 would cause that much lag, really, as servers have practically no noticeable lag right now as is. The maps can literally be "designed" for 40 players (Goldrush, lakeside, under, and even complex would disagree though), but people still prefer to have more people playing than that. I didn't mean game/engine optimization neither (though updating the version from b3 to b4 surely had some affect with this), I meant vehicle optimization, as the main issue in B1 with the large player count was that vehicles were incredibly shaky. Not to mention that the reduction in size of the download caused issues back then too. Those are the optimizations I was hinting towards. That's all I'll say on the subject, as it's clear that you're sticking to your guns and not going to change your mind anyway. I just really wish you would re-consider, coming from a long time (since release) Renegade addict, and witnessing how this played out there. 50 is nowhere near the same as 64 neither. That's increasing it by 5 people a team, rather than by 12 people a team. That's not a fair comparison to use.

Not 64. 50. It clearly states that in the first post.

It happens when you press alt fire (right click) while primary fire is reloading I believe. Maybe it's the same thing as the stealth tank firing while stealth client-side? I'll go on at some point tomorrow and try to 100% reproduce it to find out exactly what is causing it. It's related to the same bug that screws up reload times for the apache/orca/mammy. When you manually reload, it reloads BOTH weapons, but you can only shoot EITHER weapon when BOTH weapons are fully reloaded, even though one of the weapons appears on the hud as reloaded far faster.

64 or 50? And there's been countless optimization changes too since then, correct?

Both Campin and Hand's ideas are one's that we have previously discussed in private as CD's. We're looking into both of those, as well as a few other possible ideas too.

They may not have been designed for it, but the original release of the game had a max of 64 players. Along with that, even the re-makes are almost all larger (and have more hiding opportunities) than the original Renegade's, which 64 and 50 player servers were/are the most common in. The game's average number of players would increase with a higher cap too. Why not at least test it out? If it gets too laggy, then it can easily be reverted back. If it does somehow hurt either of the server's player counts (which I highly doubt it will), it could be reverted back.

That would be true if people did not care about how many players are in the game prior to joining. The fact that ONLY EKT and TMX servers are populated ever proves otherwise. There's only a few select people who will join an empty server to try and populate it, and then the number of people who will join into a server slowly increases as the playercount in that server increases. People who join and are looking for a high player count server are going to ignore the lower player count server anyway. If there's one at 35 and one at 12, they will never join the one at 12. Your logic states that people will join the smaller playercount server because the larger one is full (at 40, currently). My point is that that is very rarely the case. If people want to join the smaller server, they will join that server. If people want to join the larger server, they will wait for that server to lose a player. The vast majority of people won't simply just join the smaller one because the larger is full. They'll sit there and wait to join the full one. That's why it's not helping the other server out by limiting the cap at 40. If you want factual evidence to support this, watch the next time your server is full. Within 3 minutes of a single player leaving, another one will almost always join and fill up the server again. He didn't join the smaller server because he didn't want to play in a smaller game. People who like the smaller games will join those smaller games, and then eventually it will keep increasing or decreasing from there on its own. Let me put it like this: Player 1 - 20+ Player 2 - 15+ Player 3 - 20- Player 4 - 30+ Player 5- 25+ Player 6 - 0 Player 7 - 10+ Player 8 - 35+ Player 9 - 30- Player 10 - 5+ The number and the corresponding + or - is how many players are in-game that it would take for each player to consider joining that server. + means anything over that #, and - means anything under that number. 0 is the rarest occurrence, and is the players who join an empty server. Now lets say the server count is (for example's sake): TMX 40 EKT 12 Players 1, 2, 4, 5, and 8 will not join EKT and will either wait for someone from TMX to leave, or close out of the game. Players 3, 6, 7, 9, and 10 will join EKT. The point is that increasing the player count max will provide players 1, 2, 4, 5, and 8 more opportunity to play and have fun. It has no real affect on the other players, as there will always be a server with less players. I saw this happen in Renegade time and time and time and time and time again throughout the years too, so its not like this is just being pulled out of no where. The only time Renegade servers even considered lowering their max playercount was when they were consistently not hitting that max, for this reason. The fact that the max is being hit daily, and that the last max player leaving is replaced almost immediately should be enough support for this logic. It would increase both server counts on average in the end too, because the group quits would still see the player count at a relatively high number, and the people who will only join a server with 35+ would still join if it was 50 and 10 people left, but wouldn't if it was 40 and 10 people left.

Agreed. Currently we have the potential to play on 2 servers, but if you raise the limit to 50, only 1 server will be played on and the other completely deserted. I don't most think people just join one or the other. People like me prefer to just join the server hat has the largest number of people. I believe that many RenX'ers are the same way. If there's a limit of 50 people in the server, it means that there is more opportunity to join that server, and an overall higher appeal because of more people in it. From my analysis, the vast majority of people leave in bunches after a game has been lost or it is clear that they will lose and the game will drag out. That's what kills the server player count. People leave in bunches, then people who load up the game see a small number of people playing and don't bother to join that server. With more people in the server at one time, it means that even if that big bunch leaves, there is still a significant amount of people in the server, and so more people will be prompted to join. It's not like there is only 75 people who play the game. There's much more, it's just that they all play at different times, but most people aren't going to join a server with a low player count. If you don't believe me, check for yourself. Sit there and watch the playercount of the 2 servers. If both are equal at 12, one will rise rapidly while the other stays about the same or loses players. That's because if one is at 12 and the other is at 20, the majority of people would rather join the 20 server. tl;dr It would increase playercount in the game and in each server at any given time.

Of course everyone is going to prefer different things, and there will always be those small games available certain times of the day still regardless. When I start the game up and see 40 players in one server and 12 in the other though, I personally either just close out of RenX or wait for the 40 one to lose a player. People who prefer the larger games are really feeling hindered in this respect. At certain times in the day, there's almost always at least one server with 40 players in it. It's a pain in the ass sitting there refreshing it or watching on irc for someone to leave. 50 would make this wait less time, or occur less sometimes too. And I really think 25 aside would play wonderfully in Renegade X. It was fun in Renegade, and that was with smaller maps and less sneaking potential.

Alright, so first off, please don't flame with "already been discussed." We've discussed why 64 player servers aren't for RenX (or UDK in general). How about 50 player servers, though? I really think it would be beneficial, given that the maps are mostly larger. It really seems as if it is designed for 50 players (25 a side). I know the prevailing issue is the lag, but with 40 I am experiencing little to no server lag whatsoever. Can the game handle 50 player servers? Can the servers up handle that many players in a game in a UDK game? I really hope so.

I think excluding team votes and forcing them to communicate like that if they think that the team has voted for that option would be fine

You only can do that to 1 person at a time though, and again, you still have no idea if they chose that option or not. That's what makes it interesting.

Updated. Mods don't currently have access to sticky/pin, otherwise I probably would. It should be noted that some of these balance issues have already been discussed in private between the CD's, and a solution has been established. We will notify you of those at some point in the near future.

It'd show their chat and q spots, but not their commands. And there's only a very few limited amount of people in-game using teamspeak at any given time. The thing is, the enemy team knows WHEN a silo is captured, but NOT which option is selected by the team. They have no idea if the team chose that option or not. There's only a few situations in which this should be the primary choice anyway. For instance, if you realize that your team will only be able to hold the silo for a very short amount of time, selection #5 gives the most benefit.

I always thought it'd be nice to have the silo give options to the team instead of just automatically giving one benefit. Something like: 1. Harvester dumps +65 each dump, and crates appear as white permanent stars on the minimap. 2. +1 credit tick per 2 seconds, and sidearms become purchasable. 3. Mine limit increased by +10, and all infantry on your team gain an auto-regeneration of 1 HP per 2 seconds. 4. Increase vehicle limit by 2, and "Items" cost reduced by 25%. 5. For 2 minutes, your team gains the ability to see the enemy team chat. When captured, it would initiate a team vote, and each member votes for what they want. They have 15 seconds to vote, and any tied vote is randomly selected between the tied options. Each selection is situational. The map is largely focused on capturing this (or these) silos in the center of the map. I also drew out a quick rough shitty mspaint sketch of a map that I believe would play well. Drew it a year back for Renegade, but now that the SDK is out, I think it could play well in X too. The silo's could be added on each side of the center paths. Don't critique the drawing, as it was literally just to show the map layout. The holes in the airstrip and WF walls are holes that are in the wall that allow the ability to shoot those structures from outside of the base, but no vehicles can enter them (they are exit holes similar to canyon's GDI side hole). It's also focused strongly on flying vehicles, but the flying vehicles have to be very cautious. Anyway, here is the sketch: http://postimg.org/image/v8bwnzehp/full/ The idea of the map was a CentralPark theme. So it would be similar to City_flying in terms of visually. I didn't add them in, but there would be trees throughout the center section, and a giant circular fountain on both sides of the open middle-section too. I just don't have the time or patience to learn the SDK

I'd rather have 1 character purchased 20% of the time and another 30% than just having one purchased 50%. It's more about making the current hotwire/technician less universal though. Splitting up their role so that they can still do the things they have always done, but they will be more efficient at doing something more specific. I don't really understand your second point, because the mechanic based character would be just as efficient at repairing vehicles as the current hotwire/technician is. The same goes for the infantry based one. They even are a little bit better at their specific role, just not as good at doing the other half of their role.

I'm assuming option 1 is only to vehicles? Definitely NOT lock-on. GDI already has the advantage in AA.

It's been tried and failed several time it seems. I'm not sure if anyone is continuing its development or not.

Not sure if I just missed the post or what, but where's the download link?

I do not think it would be hard to do. I haven't seen the code for it, but it seems like it could be as easy as just ifvehiclehit=yes, stick=yes. Or something along those lines. Again, never played around with UE so I could be totally off the mark there.