Recon over Tunngle and Xwis on my mod using Ares 0.1.1166

[EricAnimeFreak]

Recons occur shortly after game start in every test, 7 tests were conducted, dll 1147 was also tried with same result. I will include debugs and syncs from both players as well as my crashdump "he only got recons, no option to create crashdump, so only my crashdump is provided" and my current rulesmd.ini as well.

Link to my logs:
http://www.megaupload.com/?d=9T3U6H5D

Link to my Friends logs:
http://www.megaupload.com/?d=62ZWSS6R

Thank you again for whatever information you can provide for this issue.

##### STEPS TO REPRODUCE #####
Play my mod over Tunngle or Xwis. Previously it had worked. I'm thinking its either my friends setup or a change in my setup or some other kind of error.

##### ADDITIONAL INFORMATION #####
The friend I was playing with for tests lives in Great Britain while I live in the USA. This may be another issue rather then an ares issue, but I have played many games with him in the past. If possible I'd like to know the reason the recons are occurring but you don't need to put a huge priority to this thanks.

[Graion Dilach (graiondilach)]

Not yet looked into the files, but if both of you use the same dll versions, both of you should get the recondumper option.

In other words... update your player's Ares. Mismatching dll revision can cause recons, and the dll version is mentioned ion the first ~5 lines.

[EricAnimeFreak (ericanimefreak)]

Well we definitely both used the same dll versions and even tried different Dll's. But only I received the recondumper option.

I'm also thinking after looking at his recons he uploaded the wrong ones, either that or he was screwing with me the entire time, "which is highly unlikely due to his good character." But that said, I think there might be another issue, does Ares have trouble writing to debug folder if multiple mod's exist in separate directories?

And thus debugs are being written in incorrect location or are not writing at all? I swear I had issues with this before, but am not 100% sure as its not happening on my current computer. It seemed my friend was having difficulty locating his debug files etc, it seemed like they were not where they were supposed to be. I will try and get with my friend to perform another test and have him set my mod as his normal RA2 directory instead of a separate sub folder EXAMPLE: EA Games\Command & Conquer The First Decade\Command & Conquer Red Alert(tm) II\RA2 Ares.

Anyways I'll post again hopefully with better information as soon as my friend and I can test again. Thanks Again!

[EricAnimeFreak (ericanimefreak)]

Okay I recently tried playing game over tunngle with my mod with a friend, and got this bug again 3 times in a row, I still have no idea what's causing it, this time i got debug, sync, and dumps from both players as well as my rules in a rar file. If you could help me narrow down the culprit, that would be good.

Game was on a standard westwood map which I've played numerous times online. DLL was compiled by Graion which includes: merged v02 and AE.

DLL for the logs: http://www.mediafire.com/?eyg0i2ue8y8i1zb

[Graion Dilach (graiondilach)]

One pdb coming up!

[DCoder DCoder (dcoder1337)]

LOL @ the mime-type for the pdb.

Eric, your debug.log says you're using more than 512 BuildingTypes. While we cannot positively prove that this is a problem, it might be - it would be great if you could eliminate that as a possible reason.

[EricAnimeFreak (ericanimefreak)]

Alright, somehow I manged to get in another test with the guy. To test it i switched out my mods rules file with the games original rules file. Recon still occurred. 512 bug is not to blame, neither is my rules.

Latest rules, debug logs, syringe logs, sync logs, and dump reports from both players: http://www.mediafire.com/?hhf78u31e7lsaec

When I get a chance I'll ask my friend what his pc configuration is etc, it might just be he's somehow at fault, I'd like to do another test with other players to confirm that. Will get back to you on that test as soon as i can find someone else to test with my mod online.

[Graion Dilach (graiondilach)]

Bug me when you see me online, ok?

[EricAnimeFreak (ericanimefreak)]

Did a online test with Graion Dilach. Recon occurred, Everything debug, dump, etc is attached.

[EricAnimeFreak (ericanimefreak)]

We played a second game, his sync.txt got overwritten so here's new stuff from a second test.

[EricAnimeFreak (ericanimefreak)]

This was another bug i saw while we were both trying to play online, it happened when i tried to return to lobby from game menu.

[Graion Dilach (graiondilach)]

And the stuff from my part.

[EricAnimeFreak (ericanimefreak)]

Okay I did a lot more testing on this, what did I discover?

Well using merged v02 and AE by Graion DLL I managed to avoid this bug by deleting my MLEP mix file which alters original westwood maps. However, after this I tested more and discovered that it does not recon when using stock game no ares, or when using ares 0.1 p1. I have been using MLEP with previous Test dlls, in the past and it worked fine. I have to think something was introduced at some point which broke map overwriting, to test this I ran a test where I altered the maps in the original Multimd.mix to use my MLEP pack. This test showed that the game still reconed, despite the altered maps from MLEP being in the original game mix.

I then created a MLEP enabled map, which would transfer over internet. Using Ares 0.1 p1 the game did not recon. I then repeated the test with the same exact conditions accept I used merged v02 and AE by Graion DLL, this resulted in another Recon. This means sometime during a dll test build change, "will later try to narrow down which dll" the dll has broken something within MLEP's base. This base worked in previous DLL and in stock game as well as ares 0.1 p1. Whatever is happening it is causing recons, and might be a source for other peoples recons. I think it's a trigger related recon bug which was introduced by a dll.

This testing took some time and as a result I have not tested yet to see in which dll this first occurred.

The MLEP Map base ini file can be added into any map to test for this bug, if someone else wants to confirm it as well.

I'd also like to try and track down which trigger is causing the recon as well, but I don't think I can do anymore testing for a bit since I have to work.

[EricAnimeFreak (ericanimefreak)]

Alright, I did some more testing, seems I get recon only when using any dlls created after dll 1145.

1146

    * Rev 1146 2011-07-30 07:29:56
    * Author: DCoder
    *

      Log message:
          <strong>Related to issue #1676</strong> - Removed debug logging.

This was in SVN as change between 1145 and 1146.

Tried removing -log %* from runares.bat and then even tried using a fresh runares.bat from ares 0.1 p1 with no commands/logging at all, not even nocd. This still resulted in Recon.

To test this run the map provided as attachment with this comment, using DLL 1145 and 1146. Anything stock game or pre dll 1145 = no recon.

[EricAnimeFreak (ericanimefreak)]

Seems I was in error after further testing. Kinda screwed up my own tests earlier and had to redo them.

Recon occurs after 1156, starting with 1158.

Note from SVN:

    * Rev 1158 2011-09-04 14:52:12
    * Author: DCoder
    *

      Log message:
          Recon Error dialog changes, compiled. TODO: test.

I'm going to see which trigger or combination there of cause recon.

[EricAnimeFreak (ericanimefreak)]

Tried to recreate with 1158 , seems I can't so Pretty sure its 1160 and above that causes recon as I was able to create recon with that one 10 times in a row... I have no idea why i keep getting such strange data from tests, maybe cause I've been at it for 4 hours straight using 2 laptops. Getting recons with earlier dll's are either flukes from incorrect testing or whatever is causing recons was less ingrained as those dlls after 1160. I tried to figure out which trigger or combination thereof was causing recon but couldn't figure that out either. If someone else wants to take a crack at this one please try, Start with 1160 and work your way down.

I was able to get the recon during tests before on lower dll's but seem to be unable to anymore, only 1160 and above now. Maybe I made a copy paste mistake or something while sending dlls over from one comp over network to other etc. Anyways I'm quitting for tonight. 4 hours of testing has made me angry with this bug.

[Renegade (renegade)]

Thank you, that is going to be helpful. :)

[EricAnimeFreak (ericanimefreak)]

Okay did even more testing.

1160 recon
1158 recon
1145 recon
1130 recon
1010 recon
0.1 p1 no recon
Stock Game no recon

Logs for testing are here: http://www.mediafire.com/?oa2uo1d2a2r0e8x

7 tests were conducted.
All Tests used stock Game with various DLL's.
All Tests tested with a single map test 01.yrm. "Is in logs in download."
More maps had been made to try and narrow which part of map causes recons, those remain untested, but are included.
All tests Reconed, except DLL 0.1 p1 and stock game.
Haven't figured out which DLL has caused recon yet.

Tests with 1160 and 1158 also resulted in Dumps and Except.txt with an unkown EIP 738B5DF2.

Hopefully I can narrow down cause of recon on map file, or maybe find out at which DLL was the first case of recon.

[EricAnimeFreak (ericanimefreak)]

Okay got to do some testing again where I left off.

Narrowed down cause of recon.

No Recon map file has:

[Structures]
0=Neutral,NATBNK,256,46,44,64,None,1,0,1,0,0,None,None,None,0,0

Recon Map has:

[Structures]
0=Neutral,NATBNK,256,46,44,64,None,1,0,1,0,0,None,None,None,0,0
X1=Neutral,PLAYERB1,256,1,1,64,MLEP6957,1,0,1,0,0,None,None,None,0,0
X2=Neutral,PLAYERB2,256,1,2,64,MLEP6957,1,0,1,0,0,None,None,None,0,0
X3=Neutral,PLAYERB3,256,2,1,64,MLEP6957,1,0,1,0,0,None,None,None,0,0
X4=Neutral,PLAYERB4,256,3,1,64,MLEP6957,1,0,1,0,0,None,None,None,0,0
X5=Neutral,PLAYERB5,256,3,2,64,MLEP6957,1,0,1,0,0,None,None,None,0,0
X6=Neutral,PLAYERB1,256,3,3,64,MLEP6959,1,0,1,0,0,None,None,None,0,0
X7=Neutral,PLAYERB2,256,2,2,64,MLEP6959,1,0,1,0,0,None,None,None,0,0
X8=Neutral,PLAYERB3,256,2,3,64,MLEP6959,1,0,1,0,0,None,None,None,0,0
X9=Neutral,PLAYERB4,256,1,4,64,MLEP6959,1,0,1,0,0,None,None,None,0,0
X10=Neutral,PLAYERB5,256,4,1,64,MLEP6959,1,0,1,0,0,None,None,None,0,0
X11=Neutral,PLAYERB1,256,2,4,64,MLEP6961,1,0,1,0,0,None,None,None,0,0
X12=Neutral,PLAYERB2,256,3,4,64,MLEP6961,1,0,1,0,0,None,None,None,0,0
X13=Neutral,PLAYERB3,256,4,4,64,MLEP6961,1,0,1,0,0,None,None,None,0,0
X14=Neutral,PLAYERB4,256,4,3,64,MLEP6961,1,0,1,0,0,None,None,None,0,0
X15=Neutral,PLAYERB5,256,4,2,64,MLEP6961,1,0,1,0,0,None,None,None,0,0
X16=Neutral,PLAYERB1,256,5,1,64,MLEP6963,1,0,1,0,0,None,None,None,0,0
X17=Neutral,PLAYERB2,256,5,2,64,MLEP6963,1,0,1,0,0,None,None,None,0,0
X18=Neutral,PLAYERB3,256,5,3,64,MLEP6963,1,0,1,0,0,None,None,None,0,0
X19=Neutral,PLAYERB4,256,5,4,64,MLEP6963,1,0,1,0,0,None,None,None,0,0
X20=Neutral,PLAYERB5,256,5,5,64,MLEP6963,1,0,1,0,0,None,None,None,0,0
X21=Neutral,PLAYERB1,256,5,1,64,MLEP6965,1,0,1,0,0,None,None,None,0,0
X22=Neutral,PLAYERB2,256,5,2,64,MLEP6965,1,0,1,0,0,None,None,None,0,0
X23=Neutral,PLAYERB3,256,5,3,64,MLEP6965,1,0,1,0,0,None,None,None,0,0
X24=Neutral,PLAYERB4,256,5,4,64,MLEP6965,1,0,1,0,0,None,None,None,0,0
X25=Neutral,PLAYERB5,256,6,1,64,MLEP6965,1,0,1,0,0,None,None,None,0,0
X26=Neutral,PLAYERB1,256,6,2,64,MLEP6967,1,0,1,0,0,None,None,None,0,0
X27=Neutral,PLAYERB2,256,6,3,64,MLEP6967,1,0,1,0,0,None,None,None,0,0
X28=Neutral,PLAYERB3,256,6,4,64,MLEP6967,1,0,1,0,0,None,None,None,0,0
X29=Neutral,PLAYERB4,256,6,5,64,MLEP6967,1,0,1,0,0,None,None,None,0,0
X30=Neutral,PLAYERB5,256,6,6,64,MLEP6967,1,0,1,0,0,None,None,None,0,0
X31=Neutral,PLAYERB1,256,1,6,64,MLEP6969,1,0,1,0,0,None,None,None,0,0
X32=Neutral,PLAYERB2,256,2,6,64,MLEP6969,1,0,1,0,0,None,None,None,0,0
X33=Neutral,PLAYERB3,256,3,6,64,MLEP6969,1,0,1,0,0,None,None,None,0,0
X34=Neutral,PLAYERB4,256,4,6,64,MLEP6969,1,0,1,0,0,None,None,None,0,0
X35=Neutral,PLAYERB5,256,5,6,64,MLEP6969,1,0,1,0,0,None,None,None,0,0
X36=Neutral,PLAYERB1,256,7,1,64,MLEP6971,1,0,1,0,0,None,None,None,0,0
X37=Neutral,PLAYERB2,256,7,2,64,MLEP6971,1,0,1,0,0,None,None,None,0,0
X38=Neutral,PLAYERB3,256,7,3,64,MLEP6971,1,0,1,0,0,None,None,None,0,0
X43=Neutral,PLAYERB4,256,7,4,64,MLEP6971,1,0,1,0,0,None,None,None,0,0
X44=Neutral,PLAYERB5,256,7,5,64,MLEP6971,1,0,1,0,0,None,None,None,0,0
X45=Neutral,FOGMODE,256,0,0,64,None,1,0,1,0,0,None,None,None,0,0
X46=Neutral,FOGMODE,256,0,125,64,None,1,0,1,0,0,None,None,None,0,...

[EricAnimeFreak (ericanimefreak)]

Did more testing today after I got out of work to try and figure out which dll this bug first occurred. It seems that it first occurred in revision 941.

Notes from 941 Revision:

Last modification

    * Rev 941 2011-01-04 20:16:48
    * Author: DCoder
    *

      Log message:
          <strong>Related to issue #1037</strong> - I have not tested this, but projectile anim palettes should work now.
          Related to issue 1037 .

Recon did not occur with revision 940, but did occur with revision 941.

[EricAnimeFreak (ericanimefreak)]

I also thought I would include debug from both computers from revision's 940 and 941.

DeathNote Logs:
debug.20120318-033600.log R-940
debug.20120318-034042.log R-941

Salt Logs:
debug.20120318-033723.log R-940
debug.20120318-034127.log R-941

[EricAnimeFreak (ericanimefreak)]

Did another test on Main cause of recon, while i suspected the buildings, it turns out that it's a little bit tricky.

Change house triggers are the cause of recon. However to cause the recon the trigger must be placed on a building that is not on the visible area of map.

[EricAnimeFreak (ericanimefreak)]

New logs for tests ran on 940 and 941 per Dcoder's request.

[DCoder DCoder (dcoder1337)]

Ironically, the fact that you used MPDEBUG makes the sync logs *less* useful xD Can you rerun without that option?

[EricAnimeFreak (ericanimefreak)]

Did test again without mpdebug for 941.

[DCoder DCoder (dcoder1337)]

"Version Ares r940
Internal Version 1.001/Ares 0.1.940"

Anyway, it seems like your buildings are totally out of sync, and both BuildingTypes and InfantryTypes are not synchronized (but that isn't checked at runtime, so no idea why that is unsynced.)

Can you re-run this test with the latest fatman/v02 binary and get sync logs and memory dumps? (If your Recon Error dialog doesn't give you the option of making a dump, leave the dialog open, open Task Manager, find gamemd.exe in the process list and Create Dump File for it.) This entire bug doesn't make much sense to me, I'm afraid.

[EricAnimeFreak (ericanimefreak)]

Alright performed test again with latest Fatman V02.12.78.1222

Logs attached.

[EricAnimeFreak (ericanimefreak)]

Well I wanted to narrow this down further and made multiple new maps when i came upon a discovery. It turns out, Triggers are not cause of bug. In fact it's just the existence of buildings off of visible portion of map. But there is more to it then even that, as the bug only triggers if a human controlled player is in position way-point 1. If both players avoid being player 1, the bug does not occur, This is really odd.

Here is a new DL link http://www.mediafire.com/?ktrydvivpg91yf0 for test that was performed on new map. Map is included.

I used to have random position settings in making games, as a result i got skewed results when testing this bug, now that i know it only occurs when someone is player 1's spot, I ran another test and found out that at revision 940, the recon still occurs, and it was by chance that i was not position 1 when i tested it. This also explains the weird tests results i had before., and how i was able to play online games in the past with MLEP despite this bug still being here. As most of you may also note the game has a habitat of placing players as far apart as possible, since my test maps had spots 1 through 8 it chose spots 1 and x 99% of the time.

I'm gonna go ahead and continue testing and find the real revision in which this bug first occurred, sorry for all the trouble I've caused in looking for the source.

[EricAnimeFreak (ericanimefreak)]

Well I tested more and finally found the original Revision which introduced this bug.

This bug does not occur on Revsion 748 but does occur in Revsion 750 and every dll after till current DLL.

Log for 750:

Author DCoder

<strong>Related to issue #1163</strong> - might fix the problem, dunno for sure.
<strong>Related to issue #1141</strong> - recoded the entire loop from scratch, no Westwood crap left.
Related to issue 1141,1163 .

[DCoder DCoder (dcoder1337)]

Build 12.169.660 has been uploaded with a potential fix.

[EricAnimeFreak (ericanimefreak)]

Didn't really haven't had much a chance to test this, I did Play a few games with friend though. Right now my testing rig is down as PSU went, so I can't do self testing of issue. I can say this fix still hasn't fixed the bug, as we Reconed twice before treating it like it wasn't fixed, still I want to do further testing before nailing down anything conclusive, for instance if its slightly better or not then before. I will get back to you when I can get some testing done.

"I did do a Test on my main rig after psu went with another, "low wattage OLD psu" I had and system isn't hurt so as soon as new psu comes I will test bug."

[EricAnimeFreak (ericanimefreak)]

New psu came, did new tests, and everything shows that bug is fixed, not sure why I reconed before. Perhaps it was user error of copying over DLL files for ARES. I don't want to call this fix confirmed, but instead left open for more confirmations.

Thanks Dcoder!

[EricAnimeFreak (ericanimefreak)]

Okay so I played 3 games with a friend, both times 3 of 3 games we played for about 5 minutes and then his computer said the Main executable for Yuri's Revenge has stopped working and closed. We tried various starting positions each time.

Also related to recon bug is a bug in which after playing an online game with a map which has stuff defined off non visible portion of map, the game refuses to close properly and must be closed through task manager. I always just thought this was an issue with windows 7 64 bit setup, but looking closely I noticed if i play skirmish or online with custom maps with no buildings defined off visible area of map the game closes itself correctly when exiting. "note this bug does not show up on windows XP at all" So it's somehow related to this bug.

Also I played a game yesterday with a friend, did not have the problem with game closing out on its own but did experience 2 recons, at the time I did not collect dumps and am unsure if it's related, but it's highly possible, but in this case it only happened twice in 5 games.