Bug tracker

[Grant]

Client GUI update bug. < Reference >

[Grant]

No menu screen

Windows 8

<Reference>

 

Outcome: Fixed with Win8 Bug Fix

[Grant]

Launching a game does not work.

File in game directory: wsock32.dll

 

Outcome: Fixed by removing wsock32.dll from game directory.

Status: Resolved with update that removes this file from directory.

[Grant]

Had several reports of: Settings.ini denied.

Possible solution people have been saying is: Run as admin though this is quite annoying.

Possible fix?

[Nyerguds]

The fix is, don't install your games in Program Files. Windows doesn't allow write access to files in there without administrator mode. If you want a fix for that, ask MS. All of the old C&C games have their settings inside the game folder, so they'll all need adminstrator mode if you install them there.

[Iran]

Good job collecting bugs.

 

wsock32.dll: I can program the client to remove it if found.

settings.ini: I'll ask Rampa, it's his code doing stuff with it.

win8 menu: win8 issue, needs ts-ddraw. Will look at semi-automating this with the client in the future (probably in a few months)

clientgui update issue: Not sure, might be that update site is temporarily down, I've had it happen to me once when I was testing. Please collect more bug reports for this one (or other updater files)

 

[Grant]

Invoke or BeginInvoke be called on a control until the window handle has been created.

 

 

Log file: http://cnc-comm.com/community/index.php?action=dlattach;topic=3591.0;attach=4791

New log file: http://cnc-comm.com/community/index.php?action=dlattach;topic=3591.0;attach=4798

Status: Sent to Rampastring for review

[Grant]

Reports of lag

Outcome: http://cnc-comm.com/community/index.php?topic=3636.0

Status: Iran to review

[Grant]

Reconnection errors with weatherstorm

Status: Iran to review

 

 

Currently the allied Weather Storm superweapon somehow seems quite prone to desync issues (thus superweapons are IMHO recommended to generally be turned off for now, unless for testing purposes of course).

 

From my experience if the problem occurs, then the game is mostly aborted by a reconnection error just as the weather storm kicks in (not when its timer reaches zero or the EVA announcement is made, but once the actual storm starts on the map), although yesterday I also witnessed just one player getting disconnected at that exact moment.

 

Attached are some CnCNet YR sync files from the last few days - don't remeber which particular of the pack exactly, but at least one or two should be from a game desynced by a  weather storm. I suppose the other sync files might prove useful too anyway, as desyncs do happen at this point under other circumstances as well (such as shortly after the beginning of a game, but also somewhat into the game).

 

< Reference >

 

Sync files: http://cnc-comm.com/community/index.php?action=dlattach;topic=3545.0;attach=4793

[Grant]

Do we check to see if binkw32.dll exists and provide it?

Error: The procedure entry point_BinkSetVolume@8 could not be located in the dynamic link libary binkw32.dll.

 

< Reference >

Outcome: https://www.dropbox.com/s/xlidkrvsfkom3q0/BINKW32.DLL?dl=0

 

Status: For Iran to confirm patch or not

[Grant]

Patriot missile not firing at enemy Rocketeers within range.

 

< Reference >

 

Status: Not a bug

[Devole]

Hey Grant, I think this may not be a bug but perhaps a perception difference. The view that we see when playing the game isn't exactly bird's eye view, but more on an angle, So what appears to be in the range, may be actually out. This would only affect things that are suspended above the ground. If we were to look at the same image from directly above the rocketeers, we would see their EXACT position.

For example:

What we see vs what actually is:

[Grant]

The client routinely crashes when someone's not loading and I go back to desktop to kill game.dat

Error Log: http://pastebin.com/pePjaPH9

Status: Iran to review

[Grant]

Update failed....Please check your connection, anti-virus and firewall settings

Status: Iran to check

<Reference>

[Jacko]

yeah Grant thats a 3D effect you see there.

As the crude editing shows its the shadows you want in range.

[Grant]

Hey guys - thanks for confirming!

[Grant]

The client routinely crashes when someone's not loading and I go back to desktop to kill game.dat, here an example:

 

Status: Iran to check

<Reference>

Log: http://pastebin.com/pePjaPH9

[Grant]

Some dude boasted about how he supposedly "had a cheat"; the game indeed desynced a minute or two after start. Associated syncfile attached.

 

<Reference>

 

Syncfile: http://cnc-comm.com/community/index.php?action=dlattach;topic=3545.0;attach=4820

 

Status: Iran to investigate

[Grant]

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.

 

<Reference>

 

Status: Rampastring to review

[55aa]

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.

[yahoo]

hey 55, its me dar2.

when we were testing and some players did not load, i noticed this in the lobby. "cannot send"

dont know if this is something.

[55aa]

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.

[Grant]

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

Great spot thank you

[55aa]

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

[55aa]

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