Matrix Games Forums

Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

Coder Diary #16 -- Adventures in Bug Fixing

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [Current Games From Matrix.] >> [World War II] >> John Tiller's Campaign Series >> Coder Diary #16 -- Adventures in Bug Fixing Page: [1]
Login
Message << Older Topic   Newer Topic >>
Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 1:25:31 PM   
berto


Posts: 17239
Joined: 3/13/2002
From: metro Chicago, Illinois, USA
Status: offline

[Apologies for the very long Coder Diary, so long that I am having to split it into several different posts. The issue is huge!]


Coder Diary #16 -- Adventures in Bug Fixing, Part 1


<emoticon>

And now, the announcement you've all been waiting for:

  • The "skittish unit", dithering back and forth bug -- fixed!







    ...

    Not!!







    </emoticoff>

    Seriously, fixing this one bug was near the top of my personal wish list. But this goes to the heart of the A/I processing, not something I understand at all well just yet. I figured that, with imperfect understanding, there was too much risk of my fixing this, breaking that. Of fundamentally breaking the game A/I.

    As an A/I player, I am as interested as anybody in seeing this fixed. It will get fixed, of that I can assure you. Just not yet.

    Happily, there are a good number of other bugs that did get fixed...

  • The legacy code persistent IF crosshair bug -- fixed!

    From the very beginning of the Campaign Series, how many times have we seen this?



    In the screenshot, indirect fire into that one hex is concluded, but the crosshair hasn't cleared. In the impending release, it will be!

  • The edmap (and also?) horizontal banding and saw-tooth screen edge legacy bug -- fixed!

    If you have run edmap (efmap.exe, wfmap.exe, rsmap.exe), maybe you have seen something like this:



    Note the saw-tooth map edge. The horizontal banding. And other glitches, like the 1-1/2 square cursor.

    This problem may affect only certain graphics cards and/or buggy graphics card drivers in combination with this or that version of Windows patched or not to one Service Pack or another... It's hard to say.

    But if your rig and setup shows this problem, most likely the new release will have solved it.

    Which brings us to Windows 8*. One of the Dev Team members runs Windows 8. He was reporting graphics glitches, especially when running several game EXEs simultaneously and attempting to resize them. As it happens, he had activated some Windows compatibility options that were contributing to these problems. When he switched them off, most but not all of his graphics problems cleared.

    Strangely, however, he reported that, with several game EXE windows open, when he attempted to access some Facebook pages using Mozilla Firefox, this would corrupt the CS game windows! Observe:




    An obvious "fix": Don't do that! [Don't access the problem Facebook pages when running the game. Or switch to a different web browser. But see below.]

    Still, it's a problem we tried to solve ... but in the end just couldn't. So I implemented a new Redraw Display (Alt-D) menu selection (hot key), for hopefully fixing any graphics glitches and map display corruption.

    A copout? If so, we're in good company. Witness this graphics corruption in Google Chrome (running on Fedora Linux):




    If the geniuses at Google can't get it right, I'm to feel embarrassed for the same failure?

    What's the solution to this graphics corruption? A page reload. We've come to accept this sort of thing. We think nothing of it.

    Indeed, in earlier versions of IE there was an explicit control button for refreshing and hopefully fixing corrupted displays. Much like the CS' new Redraw Display (Alt-D) menu selection (hot key)!

    I think there is no shame if I add a similar work-around in the CS EXEs.

    Another legacy code graphics bug:



    In the top panel, the RS Bootcamp4.scn in ZoomIn25 (3-key) display mode as displayed in CS 1.04 and before. In the bottom panel, as you will see it in the impending CS release.

    This is an extremely difficult problem to fix. It's a case of fix one thing, break another. The cures can be worse than the disease. See the ugly black gashes in the top display? Maddeningly, they often appear when I attempt this or that "cure". For yet unknown reasons, they can be difficult to avoid.

    I have attempted to isolate the problems by introducing three new graphics files: Gray3d.bmp, Gray4d.bmp & Gray5d.bmp. By means of careful pixel by pixel editing of these new gray shader image BMPs, and maybe also some coding cleverness, it is possible to mitigate if not quite (yet) solve these vexing graphics issues. Yes, this game's graphics engine is really showing its age!

    Fortunately:

  • By far, most scenarios are daytime scenarios. Night shader graphics glitches don't come into play.
  • In EF & WF, the relatively few night scenarios typically don't have open water, are land-bound only.
  • Most of the problems, what relatively few there are, are in RS. The problems only reveal themselves in night scenarios, showing open water, and in ZoomIn50 (2-key) and the little used ZoomIn25 (3-key) modes.

    So all in all, maybe not that big of a deal.

    I have said

    quote:

    ORIGINAL: berto

    Sorry, guys. Improved graphics are not the focus of the impending release. It's beyond our time and capabilities (30,000+ graphics and sound files!). With the help of Slitherine and Lordz Studio, maybe next time.

    Overhauling the games' graphics engine is on the to-do list. Just not this time.

    Other bug fixes:

  • A legacy bug involving BunkerMorale (bunkers were mistakenly using TrenchMorale) -- fixed!

  • Many legacy date-related bugs in both code and data -- fixed!

  • For nations ID#s & Msg* strings, many omissions, inconsistencies, and other faults -- fixed!

    But please note: No French or German versions of the game for the impending release. Not enough time or Team expertise. For future releases.

  • Erroneous "slots" and/or "slot" designations for several nations: Australia, New Zealand, Communist Vietnam, Communist China, South Africa, Philippines, etc. -- fixed!

  • Several problems involving gliders -- fixed!

  • The Variable Visibility (optional rule) changing Visibility each phase, more than once per game turn -- fixed!

  • A bug involving potential crashes when selecting/deselecting Background Music or Background Sound.

    Here's a screenshot from that debugging session:




    To the right, in black, a Cygwin terminal window. Circled in red, the third and fourth lines in sounds.dat.

    To the left, in the Visual Studio display, you can see where the sounds.dat lines 3-4 numbers have been assigned to elements 23 through 29 of the _movement[] array!

    Above, you can see where _assault, _load, _mine, _backg[0], _backg[1], _backs, _neutral are therefore assigned, not with the lines 3-4 numbers, but numbers in sounds.dat lines 6 and beyond, what are then supposed to be the _defeat[], _draw[], and _victory[] data. Which is why we all lost background sounds & music for a while there.

    And on an on...

    [to be continued]

    _____________________________

  • Post #: 1
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 1:26:42 PM   
    berto


    Posts: 17239
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    Coder Diary #16 -- Adventures in Bug Fixing, Part 2


    ... to the game data!

    quote:

    ORIGINAL: Crossroads

    Remember: Game engine code + data = JTCS. Many crashes are result of corrupt data, not corrupt game code.

    Very true! There is an understandable tendency, when encountering crashes, to point the finger of blame at the coder, me! Fair enough, sometimes, but not all of the time. No, many times the fault lies in the game data, not in the code.

  • Thousands of bugs in the game data -- fixed!



    How can that be? How could there have been so many bugs in the game data that, mostly, went unnoticed for so long?

    If you think (maybe you don't) that coding this game can be mind numbingly exacting and tedious, consider the game data, for example (from EF's platoon00.oob):



    ...
    P00857 1 3 6 50 0 0 60 22 9 1 3 1 10 0 1 6 2 P00005 4 33 0 1 16 15 42 4 53 12 6 3 3 T-70 Light Tanks , T-70 ,
    P00062 5 5 3 40 0 0 27 21 9 2 3 1 3 0 0 6 3 P00062 3 33 0 1 0 15 31 1 42 12 3 1 1 T-26 Model 1931 Light Tanks , T-26 M31 ,
    P00922 3 5 3 40 0 0 27 21 9 2 3 1 3 0 0 6 3 P00062 3 33 0 1 0 15 31 1 42 12 3 1 1 T-26 Model 1931 Light Tanks , T-26 M31 ,
    P00926 2 5 3 40 0 0 27 21 9 2 3 1 3 0 0 6 3 P00062 3 33 0 1 0 15 31 1 42 12 3 1 1 T-26 Model 1931 Light Tanks , T-26 M31 ,
    P00830 2 4 3 45 0 0 27 21 9 2 3 1 29 0 1 6 3 P00062 3 33 0 1 0 15 32 1 42 12 3 1 1 T-26 Model 1932 Light Tanks , T-26 M32 ,
    P00923 3 4 3 45 0 0 27 21 9 2 3 1 29 0 1 6 3 P00062 3 33 0 1 0 15 32 1 42 12 3 1 1 T-26 Model 1932 Light Tanks , T-26 M32 ,
    P00924 5 4 3 45 0 0 27 21 9 2 3 1 29 0 1 6 3 P00062 3 33 0 1 0 15 32 1 42 12 3 1 1 T-26 Model 1932 Light Tanks , T-26 M32 ,
    P00921 3 4 3 45 0 0 27 21 9 2 3 1 8 0 1 6 3 P00734 3 33 0 1 0 15 32 1 42 12 3 1 1 T-26 Model 1932 Artillery Tanks , T-26A M32 ,
    P00925 5 4 3 45 0 0 27 21 9 2 3 1 8 0 1 6 3 P00734 3 33 0 1 0 15 32 1 42 12 3 1 1 T-26 Model 1932 Artillery Tanks , T-26A M32 ,
    ...



    Or (from the EF weapon.pdt):



    P00001 2
    3 1
    P00843 0
    0
    P00874 20 20 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 9 8 7 6 5 4 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
    27 27 27 27 27 27 27 27 27 26 26 26 26 26 26 26 26 26 25 25 25 25 25 25 25 25 24 24 24 24 24 24 24 24 23 23 23 23 23 23 23 22 22 22 22 22 22 21 21 21 21 21 21 20 20 20 20 20 19 19 19 19 19 18 18 18 18 1
    ...



    Who can create and maintain such data without making the occasional mistake? Now consider how many different players and modders have been mucking with the data over the 15+ years of this game's life. Not to mention the data bugs likely in the original game. The result? The "thousands" of bugs in the game data, many of them now fixed.

    How discovered? How fixed?

    Remember Coder Diary #6 -- CSlint?

    You might want to look back over that introduction to CSlint.

    quote:

    What is CSlint? Akin to the well-known C programming language utility lint. ("Lint: A Unix C language processor which carries out more thorough checks on the code than is usual with C compilers. Lint is named after the bits of fluff it supposedly picks from programs." See here.) Similarly, CSlint is a toolkit of programs designed to discover and report bugs, problems, glitches, anomalies in the Campaign Series game data files.

    If anybody thinks that CSlint is poppycock, that I'm just making this up, please read this:

    http://en.wikipedia.org/wiki/Static_code_analysis

    http://en.wikipedia.org/wiki/Automated_code_review

    Proactive, pre-execution debugging (CSlint) vs. reactive, post-execution debugging (the traditional way).

    Static analysis (CSlint) vs. dynamic analysis (playtest the game, inspect the log files).

    Each approach has its strengths and weaknesses, but together they've got the bugs surrounded -- no escape!

    Here are some more recent examples of CSlint in action...

    quote:

    csgfxchk.pl

    csgfxchk.pl is a Perl script (program) to check the unit graphics files (.bmp, .bit) for various errors.

    ...

    units with missing bitmap3d files:



    ERROR: for unit P00673, no corresponding [MUX]p00673.bmp bitmap3d file (P00673: Boats )
    ERROR: for unit P00674, no corresponding [MUX]p00674.bmp bitmap3d file (P00674: Rafts )
    ERROR: for unit P03001, no corresponding [MUX]p03001.bmp bitmap3d file (P03001: M4 Medium Tanks )
    ERROR: for unit P03002, no corresponding [MUX]p03001.bmp bitmap3d file (P03002: M4 Medium Tanks )
    ERROR: for unit P03003, no corresponding [MUX]p03001.bmp bitmap3d file (P03003: M4 Medium Tanks )
    ERROR: for unit P03004, no corresponding [MUX]p03004.bmp bitmap3d file (P03004: Type 97 CHI-HA Kai Medium Tanks )
    ...
    ERROR: for unit P03054, no corresponding [MUX]p03054.bmp bitmap3d file (P03054: Type 1 HO-NI 75mm Tank Destroyers )
    ERROR: for unit P03055, no corresponding [MUX]p03055.bmp bitmap3d file (P03055: SU-100 100mm Tank Destroyers )
    ERROR: for unit P03056, no corresponding [MUX]p03056.bmp bitmap3d file (P03056: SU-85 85mm Tank Destroyers )
    ERROR: for unit P03057, no corresponding [MUX]p03057.bmp bitmap3d file (P03057: SU-76 76mm Assault Guns )
    ERROR: for unit P03101, no corresponding [MUX]p03101.bmp bitmap3d file (P03101: Type 83 152mm SPA )
    ...



    These are serious errors. If selected for use in a scenario, such units would not display in the 3D maps, or the Info Box; and worse, would cough up error message boxes on game startup.

    ...

    quote:

    cssndchk.pl

    cssndchk.pl is a Perl script (program) to check sounds.dat, the sound files (.ogg, perhaps also any .wav), also the .oob files, for various errors.

    ...



    Robert@roberto ~/cslint
    $ ./cssndchk.pl +e +w -g wf
    ERROR: for file 26explosion0.ogg, type 26 exceeds sound types max 26
    ERROR: for file 26weapon0.ogg, type 26 exceeds sound types max 26
    ERROR: for file 30movement0.ogg, type 30 exceeds sound types max 26
    ERROR: mistaken or anomalous filename: 5xplosion2.ogg
    ERROR: sounds.dat:2: missing 16movement0.ogg file
    ERROR: sounds.dat:2: missing 17movement0.ogg file
    ERROR: sounds.dat:2: missing 18movement0.ogg file
    ERROR: sounds.dat:2: missing 19movement0.ogg file
    ERROR: sounds.dat:2: missing 20movement0.ogg file
    ERROR: sounds.dat:2: missing 21movement0.ogg file
    ERROR: sounds.dat:2: missing 22movement0.ogg file
    ERROR: sounds.dat:2: missing 23movement0.ogg file
    ERROR: sounds.dat:2: missing 24movement0.ogg file
    ERROR: sounds.dat:2: missing 25movement0.ogg file
    ERROR: sounds.dat:13: missing mvictory8_2.ogg file
    ERROR: sounds.dat:14: missing defeat9_3.ogg file
    ERROR: platoon19.oob:44:: illegal movesound 30 for unit P19048 Pack Horses
    ERROR: platoon19.oob:45:: illegal movesound 30 for unit P19049 Pack Horses



    ...

    quote:

    cswpnchk.pl

    cswpnchk.pl is a Perl script (program) to check weapon.pdt for various errors.

    ...



    Robert@roberto ~/cslint
    $ ./cswpnchk.pl +e -w -n -g wf
    ERROR: for unit 1282 Opel 3.6-47 type W39 Omnibus, no corresponding range effect values in weapon.pdt
    ERROR: for unit 1947 Sd.Kfz.302 Goliath, no corresponding range effect values in weapon.pdt
    ERROR: for unit 1956 SdKfz 2 Kettenkrad HK 101, no corresponding range effect values in weapon.pdt
    ERROR: for unit 1957 SdKfz 2 Kettenkrad HK 101, no corresponding range effect values in weapon.pdt
    ERROR: for unit 1958 SdKfz 2 Kettenkrad HK 101, no corresponding range effect values in weapon.pdt
    ERROR: for unit 1959 SdKfz 2 Kettenkrad HK 101, no corresponding range effect values in weapon.pdt
    ERROR: for unit 2272 Ski Rifle Platoon G, no corresponding range effect values in weapon.pdt
    ERROR: for unit 2311 Large Army Supply, no corresponding range effect values in weapon.pdt
    ERROR: for unit 9009 A9 CS Cruiser Tanks, no corresponding range effect values in weapon.pdt
    ERROR: for unit 9011 A10 CS Cruiser Tanks, no corresponding range effect values in weapon.pdt
    ...



    ...

    Very serious errors. If a unit does not have a value in weapon.pdt it cannot fire at all. There were hundreds of such errors!

    quote:


    ...



    Robert@roberto ~/cslint
    $ ./cswpnchk.pl -e +w -n -g wf
    ...
    WARNING: in weapon.pdt, for unit 1269, range effects don't uniformly decline: h 17 14 11 8 5 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 s 24 24 24 24 23 23 23 23 22 22 22 22 21 22 21 21 21 21 20 20 20 20 20 19 19 19 19 19 18 18 18 18 18 17 17 17 17 17 16 16 16 16 16 15 15 15 15 15 14 14 14 14 14 13 13 13 13 13 12 12 12 12 12 11 11 11 11 11



    ...

    quote:

    csutxchk.pl

    csutxchk.pl is a Perl script (program) to check unittext.txt entries.

    ...



    Robert@roberto ~/cslint
    $ ./csutxchk.pl -e +w -n -g wf | head -n 40
    WARNING: for unit 1 T-38 Tankettes, no corresponding unit text in unittext.txt
    WARNING: for unit 2 T-40 Tankettes, no corresponding unit text in unittext.txt
    WARNING: for unit 3 T-60 M40 Tankettes, no corresponding unit text in unittext.txt
    WARNING: for unit 4 T-60 M42 Tankettes, no corresponding unit text in unittext.txt
    WARNING: for unit 5 T-70 Light Tanks, no corresponding unit text in unittext.txt
    WARNING: for unit 6 T-26 Model 1937 Light Tanks, no corresponding unit text in unittext.txt
    WARNING: for unit 7 OT-133 Flamethrower Light Tanks, no corresponding unit text in unittext.txt
    ...



    ...

    csutxchk.pl alone reported



    Robert@roberto ~/cslint
    $ ./csutxchk.pl -e +w -n -g ef | wc -l
    162

    Robert@roberto ~/cslint
    $ ./csutxchk.pl -e +w -n -g wf | wc -l
    450

    Robert@roberto ~/cslint
    $ ./csutxchk.pl -e +w -n -g rs | wc -l
    178



    ~800 missing unittext.txt entries!

    Thanks to Crossroads, no unit will lack a unittext.txt entry, even if just a perfunctory one. Which means that every unit should have a description (even if in some cases a very brief one) in the Unit Handbook.

    Speaking of which:

  • If a unit has no assigned Unit Handbook picture file, attempt to display any graphic defined in its bitmap3d field instead -- fixed!

    In future, more of this



    much less of this



    [to be continued]

    < Message edited by berto -- 1/27/2014 2:34:15 PM >


    _____________________________


    (in reply to berto)
  • Post #: 2
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 1:27:44 PM   
    berto


    Posts: 17239
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    Coder Diary #16 -- Adventures in Bug Fixing, Part 3


    I code; I don't "do data". (I am not knowledgable or qualified.) I have fixed my share of bugs, but by far the Team has fixed the many thousands (no exaggeration!) of data bugs:

    Crossroads writes:

    quote:

    ORIGINAL: Crossroads

    Be sure to add my compliments to the various CSlint utilities. What a base they are for the new MW series: the tools themselves, and then us using them with a lot of experience from this release

    Sound bugs and fixes:

    - Created a base set of movement and weapons sounds, similar to all three engines.
    - Added 4 new weapon sound and 3 new movement sound categories.
    - Reorganized existing weapon sounds, for an example
    -- Tanks and ATGs only within five sub categories of theirs, and
    -- Artillery and SPA only within six sub categories of theirs
    - Verified all ~ 8 500 platoons for their weapon and movement, sounds, with total of 1171 weapon and 113 movement sound fixes / reallocations

    OOB, weapon.pdt and unittext.txt verification and fixing

    - Went through (well Jason and Mike did this for WF mostly) the all OoB organization levels, ensuring there are no units out of range of correct dates, checked reinforcement probabilities etc. Literally hundreds upon hundreds of fixes.
    - Ensured all units have a value in the weapon.pdt file that have a Hard/soft attack capability
    - Ensured all units have at least a basic entry in the unittext.txt. Added some 1500 entries.

    And the disclaimer: given the vast legacy of game data under the three engines, there no doubt remains errors that we did not spot. But this is a grand opening for the new era for the MCS series!

    And Warhorse writes:

    quote:

    ORIGINAL: Warhorse

    2D graphics rework

    Started with EF, but was compelled to instead start over with WF, due to the EF files being in use in another venture. Underway is a whole rework to the 2d military organisational Symbols(NATO), AND the 2d pictures one sees in 2d mode. Most of WF is well underway, however ran out of time for this release, so most will be in a future patch. All three engines will utilise this icons2d.bmp formatting, also, for the first time in over 10 years or more, the icons1d.bmp one uses when in extreme 2d zoom matches the icons2d.bmp!! No more blank counters!!

    Thanks, also, to Jason, K K Rossokolski, and others who have worked on maintaining and fixing the game data.

    A hearty expression of thanks too for the other play testers on the Dev Team who have helped out with their comments, suggestions, and bug reports.

    There are many spiffy new features in the impending release. But you know what? These many thousands of data fixes are no less significant!

    Other things...

    Remember Coder Diary #12 -- Automated Crash Testing?

    By now, I have run many hundreds of crash test trials testing nearly 500 scenarios across EF, WF & RS. Out of all those many test trials, I have encountered

  • fewer than five crash-prone scenarios -- three in RS, one in WF, all involving amphibious invasions
  • three freeze-certain scenarios -- all in WF, all amphibious invasion scenarios, and all when the A/I plays the invader

    There is obviously something(s) wrong in the amphibious operations code (and/or data?). This will definitely be a focus of future bug hunts.

    In the games' Release Notes, we will be sure to mention these problematic scenarios (we leave them in for PBEM play, where probably there are no problems), and others (if any) as we continue testing and come across them.

    Remember Coder Diary #15 -- Logging?

    Here is another example from some recent edorg.log output:



    ...
    2014-01-21 11:16:25 wforg.exe: [WARNING ID 200] corps00.oob, line 712: duplicate ID, same org type: 50207 $(1-25) Mechanized Corps 38 (BT-7 M35) , conflicts with 50207 $(1-5) Mechanized Corps (T-26 M33)
    2014-01-21 11:16:27 wforg.exe: [WARNING ID 200] corps00.oob, line 1895: duplicate ID, same org type: 52257 $ Guards Rifle Corps Dec 44 (Veteran), conflicts with 52257 $ Guards Rifle Corps Dec 44
    2014-01-21 11:16:28 wforg.exe: [WARNING ID 200] corps00.oob, line 2338: duplicate ID, same org type: 52273 $(1-14) Mechanized Corps 49 (T-54), conflicts with 52273 $(1-14) Guards Mechanized Corps 46 (veteran)
    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 511: missing closing bracket
    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 512: missing closing bracket
    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 513: missing closing bracket
    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 514: missing closing bracket
    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 515: missing closing bracket
    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 635: suborganization out of range: 149009 Kampfgruppe Schmidt (Hermann Göring Division), in Kampfgruppe Schmidt (Hermann Göring Division), in 152808 Korpsgruppe Weber
    2014-01-21 11:16:31 wforg.exe: [WARNING ID 200] corps01.oob, line 748: suborganization out of range: 119313 Panzer-Abt.z.b.V.12, in Panzer Abt.z.b.V 12, in 152017 Military Commander Serbia (12th Army)
    2014-01-21 11:16:32 wforg.exe: [WARNING ID 200] corps02.oob, line 250: suborganization out of range: 242054 Lybian Infantry Division(1935-36), in Lybian Division(1935-36), in 252145 Grazziani Column (Somaliland)
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 100] corps03.oob not found
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 200] corps04.oob, line 1: suborganization out of range: 439001 1st Cavalry Brigade, in 1st Cavalry Brigade, in 452001 Fast Corps
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 200] corps04.oob, line 112: suborganization out of range: 149068 556. Infantry Division, in $(31-31). SS Waffen Grenadier Division, in 452004 IV. Army Corps
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 100] corps05.oob not found
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 100] corps06.oob not found
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 100] corps07.oob not found
    2014-01-21 11:16:35 wforg.exe: [WARNING ID 200] corps08.oob, line 61: duplicate ID, same org type: 852003 6th Army Corps, conflicts with 852003 3rd Army Corps
    2014-01-21 11:16:35 wforg.exe: [NOTICE ID 200] corps08.oob, line 280: duplicate ID, different org type: 0 , conflicts with 0
    2014-01-21 11:16:35 wforg.exe: [NOTICE ID 200] corps08.oob, line 280: duplicate ID, different org type: 0 , conflicts with 0
    2014-01-21 11:16:36 wforg.exe: [NOTICE ID 200] corps09.oob, line 176: duplicate ID, different org type: 0 , conflicts with 0
    2014-01-21 11:16:36 wforg.exe: [NOTICE ID 200] corps09.oob, line 176: duplicate ID, different org type: 0 , conflicts with 0
    ...





    In the legacy code (and in v1.04 and before), there was output like the above, but without file names and line numbers -- how useful is that?

    Logging -- yet another invaluable tool in our growing QA toolkit.

    Many thousands of bugs, many if not most of them fixed -- It's no exaggeration, no lie.

    Have we discovered and squashed all bugs? Hardly. There Will be Bugs. And





    Have we made a good faith effort to debug this game, its code and its data? You bet!

    Bug fixing and QA -- what we've been focusing on in recent weeks. Thankfully nearing an end. For now. But you can be sure that in future it will continue, with as much seriousness and ingenuity as we can muster.

    Until the next time...

    _____________________________


    (in reply to berto)
  • Post #: 3
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 1:32:09 PM   
    wings7


    Posts: 4608
    Joined: 8/11/2003
    From: Phoenix, Arizona
    Status: offline
    Amen...Thank you!

    Patrick

    (in reply to berto)
    Post #: 4
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 1:35:13 PM   
    lecrop


    Posts: 246
    Joined: 4/14/2009
    Status: online
    Simply amazing work

    _____________________________


    (in reply to berto)
    Post #: 5
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 2:08:55 PM   
    benpark

     

    Posts: 3841
    Joined: 8/12/2002
    Status: offline
    I've been following all of these threads, and I'm amazed and tankful for your hard work. This is one of maybe 3 older games that still hold up for me that I keep on hand to play. It's really great to see people caring for it and keeping it alive.

    _____________________________

    "Fear is a darkroom where the devil develops his negatives" Gary Busey

    (in reply to lecrop)
    Post #: 6
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 2:11:46 PM   
    Crossroads


    Posts: 14393
    Joined: 7/5/2009
    Status: online

    quote:

    ORIGINAL: berto

    2014-01-21 11:16:30 wforg.exe: [WARNING ID 200] corps01.oob, line 635: suborganization out of range: 149009 Kampfgruppe Schmidt (Hermann Göring Division), in Kampfgruppe Schmidt (Hermann Göring Division), in 152808 Korpsgruppe Weber
    2014-01-21 11:16:31 wforg.exe: [WARNING ID 200] corps01.oob, line 748: suborganization out of range: 119313 Panzer-Abt.z.b.V.12, in Panzer Abt.z.b.V 12, in 152017 Military Commander Serbia (12th Army)
    2014-01-21 11:16:32 wforg.exe: [WARNING ID 200] corps02.oob, line 250: suborganization out of range: 242054 Lybian Infantry Division(1935-36), in Lybian Division(1935-36), in 252145 Grazziani Column (Somaliland)
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 200] corps04.oob, line 1: suborganization out of range: 439001 1st Cavalry Brigade, in 1st Cavalry Brigade, in 452001 Fast Corps
    2014-01-21 11:16:34 wforg.exe: [WARNING ID 200] corps04.oob, line 112: suborganization out of range: 149068 556. Infantry Division, in $(31-31). SS Waffen Grenadier Division, in 452004 IV. Army Corps




    If I never see another suborganization out of range error it will be too soon!

    And, I seriously need a life.

    Seriously though, Berto's CSlint tools made it all possible. Without them, we would have been in the dark, fixing the bug we ran straight into. But missing the one right behind it, in the shadows...


    _____________________________

    Visit us at: Campaign Series Legion
    ---
    CS: Vietnam | CS: East Front 1939-1941 IN-THE-WORKS
    CS: Middle East 1948-1985 Fully reimaged v2.0 available now!

    (in reply to berto)
    Post #: 7
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/27/2014 4:35:43 PM   
    Crossroads


    Posts: 14393
    Joined: 7/5/2009
    Status: online

    quote:

    ORIGINAL: Crossroads

    And, I seriously need a life.



    Speaking of which, I just left my computer do the testing on two big scenarios, while I am spending a nice evening with my family


    _____________________________

    Visit us at: Campaign Series Legion
    ---
    CS: Vietnam | CS: East Front 1939-1941 IN-THE-WORKS
    CS: Middle East 1948-1985 Fully reimaged v2.0 available now!

    (in reply to Crossroads)
    Post #: 8
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/28/2014 8:20:13 PM   
    kool_kat


    Posts: 551
    Joined: 7/7/2008
    From: Clarksville, VA.
    Status: offline
    Hey Berto:

    What about the Rising Sun cave movement bug?

    e.g. When designing RS scenarios, sometimes cave movement would not work correctly. I believe it also can occur when playing RS scenarios that feature caves.

    _____________________________

    Regards, - Mike

    "You have to learn the rules of the game. And then you have to play better than anyone else." - Albert Einstein

    (in reply to Crossroads)
    Post #: 9
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/28/2014 8:34:08 PM   
    berto


    Posts: 17239
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    I thought that the cave crash bug had been fixed in 1.04, no?

    The three RS scenarios that crashed in recent test trials (will be noted in the Release Notes) were all amphibious scenarios. (In three WF amphibious scenarios, the invading A/I will invariably freeze. Will also be noted.)

    If the A/I, in auto-play mode (which is how the test trial system operates), used cave movement -- likely -- there were no crashes that I know of.

    I could be wrong. If so, too late to fix for this release, but surely the next one.

    The new Logging System will be of inestimable value in debugging these and other problems. Fun times ahead!

    _____________________________


    (in reply to kool_kat)
    Post #: 10
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 1/28/2014 8:54:23 PM   
    kool_kat


    Posts: 551
    Joined: 7/7/2008
    From: Clarksville, VA.
    Status: offline
    Hi Berto:

    Actually, I hope I am wrong!

    I remember trying to design a RS scenario with caves... and the AI got it's "wires crossed" and was unable to utilize cave movement. I believe it was with the 1.04 patch update.

    However, once the dust settles with the 1.05 patch, I'll look back into designing a RS scenario with cave movement and see how it behaves.

    _____________________________

    Regards, - Mike

    "You have to learn the rules of the game. And then you have to play better than anyone else." - Albert Einstein

    (in reply to berto)
    Post #: 11
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 2/3/2014 11:22:08 PM   
    e_barkmann


    Posts: 1307
    Joined: 4/18/2000
    From: Adelaide, Australia
    Status: offline
    Yes the cave movement crash in RS was annoying and I think it was still there in 1.04.

    _____________________________

    Scourge of War multiplayer group

    http://steamcommunity.com/groups/sowwaterloo

    (in reply to kool_kat)
    Post #: 12
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 2/4/2014 3:11:55 PM   
    Bigeard


    Posts: 39
    Joined: 12/25/2011
    From: Cambridge U.K.
    Status: offline
    I'm doing an Iwo Jima PBEM scenario at the moment, and have had no problems whatsoever with cave movement in over 50 moves. I'm pretty sure it was fixed a while ago.

    _____________________________

    Regards

    Paul Kirkland

    (in reply to e_barkmann)
    Post #: 13
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 2/6/2014 4:09:17 AM   
    e_barkmann


    Posts: 1307
    Joined: 4/18/2000
    From: Adelaide, Australia
    Status: offline
    hmm yes pehaps I am confusing with crashes due to allied amphib landings Berto has noted above

    _____________________________

    Scourge of War multiplayer group

    http://steamcommunity.com/groups/sowwaterloo

    (in reply to Bigeard)
    Post #: 14
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 2/7/2014 1:52:22 AM   
    Kim

     

    Posts: 6
    Joined: 2/7/2014
    Status: offline
    Just wondered if you'd noticed (at least it used to be true) that it the scenarios with transport vehicles (trucks, halftracks) loaded in landing craft that crash. Used to be able to create the crash with the next unit button as well.

    _____________________________

    Kim

    (in reply to e_barkmann)
    Post #: 15
    RE: Coder Diary #16 -- Adventures in Bug Fixing - 2/7/2014 4:22:52 AM   
    berto


    Posts: 17239
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    Thanks for the tip! This will help us in our bug search.

    _____________________________


    (in reply to Kim)
    Post #: 16
    Page:   [1]
    All Forums >> [Current Games From Matrix.] >> [World War II] >> John Tiller's Campaign Series >> Coder Diary #16 -- Adventures in Bug Fixing Page: [1]
    Jump to:





    New Messages No New Messages
    Hot Topic w/ New Messages Hot Topic w/o New Messages
    Locked w/ New Messages Locked w/o New Messages
     Post New Thread
     Reply to Message
     Post New Poll
     Submit Vote
     Delete My Own Post
     Delete My Own Thread
     Rate Posts


    Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

    0.152