Trace through glass fix

[GoogleCodeExporter]

Overall description:
The game acccidentally freezes.
I play BR with 10 bots (in UI there are 10, but in game only 9 (because one 
slot is reserved for me)).
See games.log in attachments.
And this info I see each time when game freezes.
All other files doesn't consist of anything unusual.

I thought it is related to Forcing models since I did a lot of changes in 
ClientUserinfo changed in CGAME.
But I checked r34 and it is working without freeze.

The freeze happens occasionally. So, maybe r34 isn't working too.

Variables affected:
None at the moment.

Original issue reported on code.google.com by igorpana...@gmail.com on 6 Sep 2009 at 7:39

Attachments:

• BUGgames.log

[GoogleCodeExporter]

Seems it is crosshairs patch.
Its removal in attachment.

Original comment by igorpana...@gmail.com on 6 Sep 2009 at 3:39

• Changed state: Investigating

Attachments:

• [Crosshairs removal.patch](https://storage.googleapis.com/google-code-attachments/sgfork/issue-52/comment-1/Crosshairs removal.patch)

[GoogleCodeExporter]

    // trace through glass
    // FIXME: doesn't work through more than one level of glass
    /*  while ( trace.surfaceFlags & SURF_GLASS ) {
        CG_Trace( &trace, trace.endpos, vec3_origin, vec3_origin,
                   end, trace.entityNum, CONTENTS_SOLID|CONTENTS_BODY );
    } <- This fix causes game's freeze   */
    if ( trace.surfaceFlags & SURF_GLASS ) {
            CG_Trace( &trace, start, vec3_origin, vec3_origin,
                      end, trace.entityNum, CONTENTS_SOLID|CONTENTS_BODY 
            );
    }

----

To be fixed.
Could set to just more than one depth and not internal (as workaround).
Like: check four times and then leave.

Original comment by igorpana...@gmail.com on 6 Sep 2009 at 5:13

• Changed title: Trace through glass fix
• Changed state: Accepted
• Added labels: Component-CGAME, Priority-Medium, Usability
• Removed labels: Priority-Critical

[GoogleCodeExporter]

I still saw trace returning with vector start == end, so loop can become 
infinite here.
Can you try the attached entity_scan_through_glass.patch patch (patch against 
SG 1.1
branch) and eventually enhanced it ?
Téquila

Original comment by bougar...@gmail.com on 7 Sep 2009 at 8:39

Attachments:

• entity_scan_through_glass.patch

[GoogleCodeExporter]

Have to try out as patch first.
If it is only about start == trace.end then why do we have 
max_trace_through_glass?
And what is more important - why are they in the same place (start and 
trace.end)?
And why do we decide to go further but not to stop if they are equal?
And if it is not only start == trace.end then what is it else?

It's not personally to you. As workaround this patch is ok.

The issue have to be investigated more.
Also I don't see any reason to call trap_CM_BoxTrace_New() instead of 
trap_CM_BoxTrace() @ CG_Trace()
to be fixed too.

Original comment by igorpana...@gmail.com on 8 Sep 2009 at 5:40

[GoogleCodeExporter]

I've committed a fix in rev. 276. on sourceforge.

The problem was that tracing doesn't advance through many of the lamps, or fake
windows with no space behind them.  I tested on alamo, hangemhigh, cobber, 
steamboat,
and tillian.  I couldn't find any places where limiting the number of traces was
needed, so I kept the fix simple.

Original comment by tor...@gmail.com on 11 Sep 2009 at 6:42

[GoogleCodeExporter]

Yes, the fix seems to be fine. Good job, though. Thank you very much.
I haven't tested it yet.
We will merge all such fixes once in two/one (depends on how many we'll have) 
weeks (to 
test them all-in-once). I'll create a separate document for that and publish it 
soon.
So I mark this one as "ToBeMerged".

Original comment by igorpana...@gmail.com on 11 Sep 2009 at 7:20

• Changed state: ToBeMerged