Devo1929

Just click the OK button in that error message and continue installing. It doesn't block you from installing.

This issue has been identified and will be fixed in the next release.

Assuming you're talking about the message that sometimes appears during installation, you should be able to ignore that error and continue with the installation. It should be a non-blocking error.

Per the log file you uploaded, it appears the client is unable to render properly at your machine's native resolution. Please find the `ra2md.ini` file in your installation path and edit the ClientResolutionX and ClientResolutionY properties in the [Video] section. Set these values to something lower for the time being, simply to get the client to launch successfully. You can then change your client resolution from within the options in the client to something more suitable. Example: [Video] ClientResolutionX=1920 ClientResolutionY=1080

As much as I love the back and forth and as easy as you obviously believe it would be, apparently I'm simply not explaining it well enough to spell out the complications, the complexities and the outright impossible aspects.. Alas, my lack of clear explanation does not make it any easier or even possible in some situations. We will continue to look into ways to try and implement this in a way that won't crash the entirety of our communication with IRC, which is what the request of "Let the "IRC get all online users" request return idents as well" has done in the past. You don't get to pick and choose what data comes back with the two very specific IRC requests we have access to. One contains the nicks of each person (which we currently use). One contains a ton of additional user information which was used until it caused IRC floods and was kicking players out of lobbies left and right. It's not a "mistake". It's completely intentional and for good reason.

Please do not do this until an absolute last resort..... There are many other good reasons why the issue might be happening before this. THIS is very very very far down on that list of reasons.

When you befriend them, we could absolutely do the same thing. I realize this. However, that's not the issue. Let's assume we went this route though and I'll lay out the scenario that would happen. Right-click a user and befriend them. At this point, the client captures the ident of the user. You sign off and close the client for the day. The next day, you launch the client and the entire player list comes in WITHOUT idents attached to any of the players as mentioned. We have nothing to compare to what was captured in step 1. Friend list broken And here is why: Right-click a user and block them. At this point, the client captures the ident of the user. You sign off and close the client for the day. The next day, you launch the client and the entire player list comes in WITHOUT idents attached to any of the players as mentioned. The user in mind attempts to send you a message. With that message comes the Ident. We have something to compare it to. We can simply discard the message. Idents are only gathered/known for someone when they do something like send a message or join a game lobby, same as above. When they do that, the client will receive an ident with that action. Until they do something, the client has no ident for a particular user. I'm aware we could have the client do a compare on each of these requests to the player list and start linking nicknames, but there would be a few caveats with that. It would be an expensive process for everyone's client, because we would have to do it on every single inbound message and the longer that player list is, the more processing/expensive it would be to find the linked player. IRC messages are flying around in the background of the client for EVERYTHING. Doing it for every one of those messages would simply be an expensive process. There would obviously be a window in which there is NO link to the friend until that person took an action like mentioned above. At least for now with using nicknames, knowing your friend is online is immediate assuming they don't change their nickname.

You are correct. The game will launch even if you have more players than assigned locations. We could implement this, but it's also very simple for the host to simply kick any players over 4 in your scenario. As for the loading page and the sorting of players, I don't know that we have the ability to enforce that. We develop for the client which is everything you see up until the game launches. The actual game loading and game play is done in a different executable, one that we do not have the ability to modify.

Can you reinstall the client from the following link and then update from there? The actual version of your Yuri/Red Alert should show up on the main menu, above where it says "YR Online" (in your first screen shot). https://downloads.cncnet.org/CnCNet5_YR_Installer.exe

Just click the OK button and you should be fine. This error appears when the installer is unable to render some background images that it attempts to use. It's a non-blocking error and shouldn't prevent you from installing.

There are two ways in which players show up in your player list (the one on the right of the main lobby) When you initially log into cncnet and the entire list comes to you immediately. In this case, the client does NOT get the Idents of users, only nicknames. When you're already logged, people that join are then added one at a time to your list. In this case, the client gets the Ident of each single user. The reason for #1 above is because a year or so ago when there was an extreme increase in player base. As a result, the IRC communication was absolutely flooded and people were actually getting booted. In an effort to mitigate this, that initial request to get all users currently online started using a different IRC request to only get nick names for less data transfer. This is why "block" will still work whether they come from that initial players load or from the one at a time. Any action they take, like sending you a message, comes with their Ident, which the client has captured when you block them. When you actually take the action to block someone, whether coming from the initial load or from one at a time, we actually make an individual request to IRC to get their ident for their current nick. This is why "friend" will NOT work on the initial players load if the client captured Ident instead of nick name, because that initial load simply doesn't have Idents. This is why your friend list will not be accurate for those that are a part of that initial page load if one of your friends changed their nick.

It doesn't prevent you from playing, but it has been fixed. If you're seeing it, you need to update your client.

That's a false message, but that also tells me that you haven't updated your client, because that issue has been fixed.

I never considered the lack of Specator option with Force Random Sides... I'll have to give that some thought on how it would work, but it should be doable. I probably wouldn't add a Force Random Soviet or Force Random Allied checkbox. To me, that's too specific.. Rather, I think it would be a better general approach to convert the "No France/Yuri" checkbox to be a drop down of "Available Factions/Sides" where the host could choose from a multi select list of factions available for players to choose from. I believe the "No France/Yuri" checkbox already limits crates from generating these MCVs. If the drop down suggested above were to work out, I don't see any reason why the same logic couldn't be used for it. All in all, these are great suggestions. Thanks!

This already exists and was a part of this feature from the beginning. The syntax however is: TeamStartMapping0=A,A,B,B TeamStartMapping0Name=TopLeft vs BottomRight TeamStartMapping1=A,B,A,B TeamStartMapping1Name=TopRight vs BottomLeft The feature was originally called "Team Start Mappings", then rebranded to Auto Ally. The order in which A,B,C,D appear is based on spawn positions (per the map preview). IE, spawn 1 = Team A, 2 = B, 3 = C, 4 = D. This above syntax is used for both mpmaps.ini as well as .map files so that custom map creators can incorporate it, too. Release Notes: https://github.com/CnCNet/cncnet-yr-client-package/releases/tag/yr-8.9

The client on some machines struggles with large resolutions. Your log file suggests that it's trying to open at 4112x2572. Go to your installation directory and open the file `ra2md.ini`. In, there you should find to settings called ClientResolutionX and ClientResolutionY under the [Video] section. Change these values to something smaller for now just to get your client to launch. Once you can get it to launch, you should be able to select a more appropriate one in the client itself in the Options. I would try simple 1080 resolution for now: ClientResolutionX=1920 ClientResolutionY=1080

This is a planned feature, but not yet started. The host will be able to select the auto ally teams directly on the map positions as well, rather than having to go into the drop downs. Also, any player in the lobby has the ability to go into the auto ally player options area to see what the teams are set as.

If you're attempting to play a game online as RA2 and not YR, there is a checkbox in the game lobby for RA2 Mode, when you are the host of the game.

Make sure you're client is up to date (currently at 8.12.0 at the time of this writing). Make sure those that you're playing with are also up to date. If everyone is up to date, try a different Tunnel as the host.

We were able to identify an issue causing the 8.11.0 version to crash immediately upon launch on Win7 and Linux (w/ Wine). We've recently released patch 8.11.1 to resolve it. You'll need to reinstall the client from the following link and then update to version 8.11.1 from within the client itself. https://downloads.cncnet.org/CnCNet5_YR_Installer.exe

We were able to identify the issue causing this and recently released patch 8.11.1 to resolve it. You'll need to reinstall the client from the following link and then update to version 8.11.1 from within the client itself. https://downloads.cncnet.org/CnCNet5_YR_Installer.exe I assure you that the client is still compatible with Win7 and .NET 4.5. This was due to a missing DLL for clients relying on the XNA UI framework.

We were able to identify the issue causing this and recently released patch 8.11.1 to resolve it. You'll need to reinstall the client from the following link and then update to version 8.11.1 from within the client itself. https://downloads.cncnet.org/CnCNet5_YR_Installer.exe I assure you that the client is still compatible with Win7 and .NET 4.5. This was due to a missing DLL for clients relying on the XNA UI framework.

You're absolutely correct that the Ignore list works that way. When you select to Ignore someone, it will request their Ident individually from IRC, then use the response to store in your ignore list. I could absolutely do the same thing for the Friend list, but it's how you interact with the Friend list vs the Ignore list that is the issue. When using the Ignore list, it's when someone on that list attempts to interact with you. IE, they send you a message. At that time, the message sent also contains that user's ident. Because we have that from the Ignore list, we can compare the two and confidently drop the message from ever reaching your client. When using the Friends list, it's when you are trying to interact with them (in the reverse of the Ignore list). IE, you're simply viewing your list of friends either in the full list of players in the main lobby or in your Friends list window. Like I said before though, when those lists of players load, your client only receives their Nicknames from IRC, not their Idents. So, even if we were to use the same method as the Ignore list to get your friend's Ident, there'd be nothing to compare it to in that full list of players.