55aa

Alright, I see now (apparently I haven't had more than one private chat open at any given time thus far). I assumed particular private chats are separate windows like in Funky's client (where what I was talking about would apply). I agree that the way it's currently done in the YR client is not optimal, and tabs or separate windows would be preferred. TBH I didn't myself experience the above to be much of an issue, but I suppose it's a matter where your proverbial milage may vary heavily. IMHO the default settings should most closely reflect what is being used in practice most often, which doesn't necessarily have to be the original games' default settings (for instance, originally superweapons are on by default in RA2/YR, while I find most games are being played with them off). In TS, you can recognize completely new people easily because they use the default CnCNet settings, which differ significantly from what is actually being used by experienced players in most games. That's quite an obvious thing to expect, and I hope too that it's going to be implemented soon. I'm not sure you understood me correctly, I never talked about faction selection, but rather about starting spot selection and team (A/B/C/D) selection. Faction and color selection seem fairly unproblematic (if you neglect the occasional "omg no yuri" protests), it's the starting spot and team (i.e. pre-game alliance) where most prolonged and uncoordinated tinkering takes place, which can delay getting the game started significantly. It does, but it doesn't support enforcing them to actually stay random, like RA1 does: While that's true... ...this unfortunately isn't. The host having specified another player's option does not set it in stone, there's no way to prevent stubborn or confused folks to keep meddling with their settings and just rechanging them (see above). This has been an annoyance in TS over a year ago already (at least traditional in-game allying using the 'a' key always worked there, as opposed to YR where right now pre-game alliances are the only option to ally at all). IMHO ideally every setting category (faction, color, spot, team) should have two flags changeable only by the host, one being "force random" (or "force none" in the case of teams, i.e. so that alliances can only be made in-game), and another "freeze host's selection". With the first flag set the given setting category would be locked at "random"/"none" for everyone, with the second flag set a given setting would become locked for a given user if the host has explicitly specified it.

While I'm not quite certain it could be called a "balance issue" (especially that it affects everyone just the same), I find it rather pointless that the F5-F8 "taunts" (which are actually messages intended for your teammates) are just being broadcast to everyone. I mean, what use is it to e.g. ask an ally to distract an enemy, if the enemies themselves hear the message too? Also, apparenty it's been an issue since RA2 actually.

AFAIK there's been some controversies lately concerning the file mph.exe (CRC32: 6CF70229), which was being alleged by a handful of antimalware programs as supposedly carrying a trojan or somesuch. Truth of the matter is that this file has been the same since when YR was released, so unless Westwood/EA Pacific have been leveraging malware all these years which somehow had only recently come to be known, then the file is probably safe (i.e. a "false positive").

I found several of the game modes to actually be disfunctional (other than affecting the list of available maps): - "Team Alliance" doesn't force a team assignment to players like it should (meaning that it can end up a FFA if nobody chooses a team); - conversely, "Free For All" doesn't prevent players from selecting teams, which it should; - the "Naval War" and "Meat Grinder" modes don't impose any restrictions on what units can be built, which they should. (Grant: please advise if it's actually OK for users to report bugs directly in this thread, or whether you'd rather prefer the reports to be made in the feedback/error logs threads and do the housekeeping here yourself.)

Every desynced game (i.e. a game interrupted by a "Reconnection Error!" message) leaves a log file in your game folder. The log files are named SYNC[i]n[/i].TXT , where n is a number between 0 and 6 (thus there can be up to seven of them, they get "rotated" afterwards, i.e. older ones will be overwritten by newer ones). If you upload these files, a developer might review them and quite possibly find out what the culprit is.

The scroll bar in the " Select Map " dialog can behave incorrectly if there are just a few more maps in the list than would fit into view, such as here: While there actually are two more maps in this list ("Arctic Circle" and "Territorial Imperative"), the scroll bar implies there aren't any, and, as it won't move, doesn't allow to scroll to them. The maps can only be accessed by selecting any visible map and scrolling down with the mouse wheel (this isn't too obvious though, especially given that most people probably subconsciously infer from the scroll bar whether there's even anything else to scroll down to or not).

The client crashes if it finds a wsock32.dll file in the game folder, but is unable to delete it due to the file being write-protected or in use. BTW it might not be the best course of action for the client to simply silently delete the file - bear in mind that the custom Winsock DLL serves as an IPX>UDP wrapper, and users might be intentionally keeping it in the game folder to facilitate LAN play on the physical local network. Perhaps it would be better for the client to instead backup the file and restore it upon exit (that restoration probably wouldn't be particularly reliablie though given the frequency of the client still crashing, but at least there would be a backup of the file). Alternatively, something like the launcher Funkyfresh made for TS might be a good idea; such a launch panel could give an option to either connect to CnCNet (without the DLL), or start the game "traditionally" (with the DLL active so that LAN play over UDP is functional).

As a matter of fact, many (if not most) of the desired features you listed are already available in Funkyfresh's client for the pre-RA2 games. Personally I'd much welcome support for RA2/YR added to that client rather than reinventing the wheel with another one, but apparently there are some reasons for why Iran adapted Rampastring's TDotTA/TI client for YR instead. Hopefully one day a unified solution for all CnCNet-supported games, with all the benefits and none of the drawbacks, emerges. If I understood correctly what you're referring to, then it's not really the client's fault, but much rather a result of Windows' default behavior (on XP it was called "Grouping of similar taskbar buttons", on 7 it's "Taskbar buttons combining", etc.). You can edit the relevant options in your taskbar properties to prevent that, and to keep every open window's taskbar button separate and always in view (here is some info on this for Windows 7 and 8 ). I'm not sure what the issue is with one person hosting games repeatedly (define "active"?). That's admittedly a real bummer, and should be fixed as a priority IMHO. In addition to that, options should be added enabling the host to force random starting spots and no preset teams - that would allow to prevent players from meddling with options endlessly, starting the game much quicker with random teams instead. (IIRC, RA1 already has at least a "force random starting spots" option - this should be added to TS and YR too, along with a "no preset teams" option).

The Scroll Rate sliders in Settings > YR Settings and Settings > RA2 Settings have their positions inverted (i.e. maximum scroll speed has the slider sitting all the way to the left, rather than all the way to the right as it should be). EDIT: This mishap most likely occured due to the fact that the raw .ini values for scroll speed (and also game speed) are rather counterintuitive, with 6 representing minimum and 0 representing maximum speed respectively.

Hm, I'm not sure whether and how this might be related, but your mention of it may be valuable to the developers who will review the problem. BTW, I observed another quirk, namely if a game is started while anyone of the participants has a YR instance running, then the game room chat window will print an error message along the lines of "the host has not yet left the previous game". This may be misleading, as apparently it doesn't necessarily have to be the person who is hosting the current game (this occured while someone else was hosting, and it was actually me who had a "someone's-not-loading" instance of YR still running). EDIT: I've been trying to reproduce this on my own, but no success so far. There was no connection made and the client of the user with a running YR instance crashed once, but I didn't get to see that message again. Perhaps when I originally saw it it was after all the hosting player not having exited YR what caused it to appear, and the fact that I had a YR instance running too had no effect on it. EDIT 2: OK, I got the message to appear - it's the "persistent lobby" option that makes all the difference, and in hindsight it's actually quite logical the message appears for the "offending" user. The user who has a YR instance running in the background when the game is being started is separated from the starting game immediately, and the following happens: - with "persistent lobby" OFF, his game room window just disappears and he's back in the main lobby, while the others are attempting connection on the usual loading screen (the "offending" user's loading bar obviously isn't progressing). - with "persistent lobby" ON, the "offending" user immediately finds himself again in the game room being kept open by the "persistent lobby" logic, and as the host (and all other players, if any) is still attempting connection for the game that was just started, the "offending" user receives the "host still playing the game that was started" message. With the above in mind, the logic displaying said message seems just fine after all in the given circumstances - what might be useful here is a means for the client to detect instances of YR that are (still) running on users' systems and that would interfere with the starting of a new game.

Concerning the above issue: I had a look at how the game's plain old LAN/skirmish lobbies deal with player nick strings, and found the following: - The odd "color-inverted x" character is how the game prints any ASCII control character (codes 0x0 - 0x1f and 0x7f ) that are encountered in the player nick string, with a few exceptions ( 0x0 is interpreted as end-of-string, 0x9 is printed as horizontal tabulation, 0xa and 0xd are ignored and not printed at all, and 0x1f and 0x7f are somewhat curiously printed as a character resembling a "pipe" character, only a bit shorter); - The game seems to handle nicks of up to a length of 19 actual characters just fine (the skirmish "lobby" allows to specify up to 19, while the LAN lobby up to 16, wherever you were last gets saved to the .ini ). Now if you force a nick longer than 19 characters by editing the .ini directly, then the 20th character is kept, the 21st character is given the ASCII value 1 , and the rest (if any) is truncated away. In such a case the first 20 characters are shown correctly, and the 21st as the "color-inverted x", and actual problems start happening - if the user with such a malformed nick creates a new LAN game, then his game won't be visible to anyone else in the lobby, and if he joins someone's game, he won't load for anyone else, and himself will be stuck with a black screen; - If the character count in a nick doesn't exceed 19, then even inserting control characters into a nick is harmless and doesn't cause any connection issues or other problems (if the first character is NUL , then the nick is considered empty and thus invalid). From what I found, all of the above holds for both the standard YR 1.001 executable ( gamemd.exe ) and the executable provided by CNCNet ( game.dat ). However, for some reason when game.dat is invoked by the YR client, the tolerable character limit in a player's nick appears to drop from 19 to 15.

While the YR client allows nicknames of up to 16 characters in length, if a nick indeed has 16 characters... ...then that user never actually loads, and the last, 16th character of his nickname on the loading screen is replaced by an odd symbol: (Interestingly enough, from the "offending" user's point of view everybody seems to load fine, and only after his game has started he gets a disconnection screen showing that he doesn't actually have a connection to anybody else.) I suspect that the game itself might be storing nicks in arrays of 16 char s including a terminating ' \0 ', so the actual character limit would be one less. The obvious remedy is for the client to simply limit the length of a nick to 15 characters. EDIT: added some further info in the Bug tracker thread.

That's what I've been referring to earlier. The above that's found within Settings.ini seems being ignored (and overwritten with defaults if changed). The exe itself has these settings inside it too, but tampering with it serves no purpose as a modified exe will not pass checksum validation and will be overwritten with an unmodified copy. Nyerguds: yes, I guess you're right about the disassembler, but of course even more so about actually a "civilized" method to change the port being called for rather than some silly hacks (I was merely experimenting). BTW Rampastring's client behaves elsewhere (i.e. with the mods it was originally created for, TDotTA and TI) just the same, ignoring the .ini setting and always connecting to port 6667.

The alternate ports CnCNet servers listen on are 8000 and 443, so they're out of that range, hence that shouldn't be an issue. The problem is to convince the YR client to connect to a port other than 6667 in the first place. (I even tried to patch the port number in RAM, but the fact the client has such a large memory footprint doesn't help at all, there are way too many locations matching the little-endian representation of the number to change and all I accomplished was crashing the client.)

What you are referring to seems to be emulated correctly in " RA2 Classic Mode " (in that mode a Rhino Tank builds in about 16 seconds on speed 4, versus about 22 seconds in " Battle " mode), and this is easily controllable via .ini settings. The things Iran was talking about are rather more subtle. EDIT: an example of such a hardcoded feature is the ability to see precisely how many enemy troops have garrisoned a given building (which IMHO is actually pretty senseless from a logical standpoint, because how the heck would you know that, but whatever). That thing came with YR, and stays active even if you play " RA2 Classic Mode ".

The funnier thing is, connecting there via an actual IRC client is supposedly considered an offense to get banned for. Go figure.

While the irc.cncnet.org servers do listen on alternative ports, I can't seem to get the YR client to connect to any of them, even though it has a " CnCNet_Port_2=6667 " line in its control file (no matter what you change it to, it connects to port 6667 anyway and overwrites any change in the .ini back to 6667 ). The client seems to have some default settings hardcoded into it, but hacking the exe is pointless as it fails a hash check and gets replaced by the original one. I don't see any command line switches to specify a destination port either. So, dunno.

Initially I assumed it was just the tech trees, but looking at RA2 Classic Mode.ini it indeed shows that you actually made an attempt to emulate vanilla RA2 as closely as possible (sans the soviet Yuri faction that has been added). Though, of course you're right about there being some more fundamental engine changes between RA2 and YR which cannot really be overridden via .ini settings. Still, I'd guess that most players aren't relying particularly heavily on those changes, and should for now be served very well by the RA2 mode you provided if wishing to play vanilla RA2.

I'm posting this here as TS/FS, RA2, and YR are all affected. The above screen is from player baz ' perspective. Player bar disconnected, whereupon player foo proposed to kick both bar and baz . While for baz the nicks of both other players are being shown correctly, the string " (null) " is being shown instead of his own nick (apparently a pointer that should be pointing to the player's own nick is due to some derpiness being NULL instead). This is probably an old Westwood bug that somehow had never been addressed.

Players not loading is an entirely separate issue (which just happens every now and then), on XP without the above fix you normally wouldn't even get to see the loading screen in the first place.

(EDIT: I see you managed to get it working in the meantime. I'll leave the additional comments here just in case they might be helpful to someone.) You should save the text file with a .[b]reg[/b] extension, not .dat (the latter is the extension of the CnCNet5 YR executable, which fact calls for the workaround in the first place). The saved file should look in Windows like this: (you won't see the extension itself though if going with the default Windows folder option "Hide extensions for known file types" .) Also, take care to verify the specified path to your game installation is correct, as per the note in my previous post. If still unsure, just use the file I attached and check/edit the target path in Notepad (then you won't have to mess with the file type, just save and merge). (EDIT2: I suppose this fix can be easily integrated into the client itself, so as for the registry entry in question to be added automatically if Windows XP is detected).

You kinda can play vanilla RA2 already, at least as far as the tech trees are concerned. To do that, select the "RA2 Classic Mode" from the game mode list in the map selection dialog. [code]"Yuri" [/code] will still be selectable, but is just another Soviet faction (with the Siege Chopper as special unit). AFAIK any other YR vs vanilla RA2 changes still apply. This is a handy way to prevent players from playing the Yuri faction, should you so desire in your hosted game.

Unfortunately Windows only allows easy setting of compatibility parameters (via the file properties dialog) for files which have the extension *.exe , thus it's indeed not obvious how to accomplish this for executable code which resides within a file with another extension (such as game. [b]dat[/b] in this particular case). The necessary registry entry needs to be made either directly (using the registry editor utility) or via a [code]*.reg [/code] file. To do the latter, paste the following into a new text file in Notepad: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\\Westwood\\RA2\\game.dat"="WIN98" Save the file with the .[b]reg[/b] extension (to do that, select "All files" from the "Save as type" list and give the file a .reg extension). To make it do its work you need to right-click the file, select "Merge" from the menu shown, and confirm the action. You can also just use the file from the archive attached below instead (you can view and edit it via a text editor). [glow=red,2,300]NOTE[/glow]: the above assumes that your RA2/YR installation resides in C:\Westwood\RA2 - if necessary, modify the path accordingly before you save the file. Pay attention to the double backslashes in the target file path specification, it's important. yr_cncnet_appcompat-win98_default_path.zip