GPxPatch 4.20 [RELEASED]

The log contains a lot of assertions. Would be easier to see assert.txt for that, but I assume at least some are expected?
It crashes on an invalid segment eventually. The gpxtrack.log belonging to this crash should help a bit.

@R_Scandura: I successfully patched the scenery limit, your track is working. I don't see any scenery or kerb textures though, not sure why.

René Smit, Independent Software Developer.
Download my GPx tools here.

great news, thanks René!

I didn't used many kerb profile commands in that track, but i remember in another track at some point it crashed and the log assertion talked about the too many kerb profiles. The same happened with the texture mapping, at some point it crashed everytime i added just one more command. So i figured that all commands may have some container limit. Anyway these commands are not vital issues at all. Thanks again!

-------------------------------

So Rene you need me to upload the gpxtrack.log and assert.txt for ya? Lemme know so I can go back replicate the crash and upload said files.

It seems to be only monaco and montreal to generate a ctd, and most odd : also the reduced tracks cause this.

Maybe as they were made for 2K something inside 1.13 is saying "NO you're trying to load a 2K track"?

if the games loads fine but crashes when lapping even in free practice what comes to mind is about jam id. i remember a couple of jam id are allocated differently in both games.
you can try to clean the folders related to those tracks and then put jams in groups and see which one makes the game crash.
otherwise the other alternatives are the far sights commands that should be removed ALL, the track details too heavy to be computed or troubles with the distance view or camera settings...

i guess you already sorted the md part. another thing that i can think about is in the split times. belini used a sort of double lap to assign the split times so in gp3 you can finish a lap without having the second intermediate being shown. give a check inside the Gp3Info from the menu and reassign the split positions. if it won't solve the issue will clean the path at least

-------------------------------




Edited 2 time(s). Last edit at 06/07/2013 06:15PM by R_Scandura.

ipswich2007 Schreef:
-------------------------------------------------------
> So Rene you need me to upload the gpxtrack.log and
> assert.txt for ya? Lemme know so I can go back
> replicate the crash and upload said files.

Yep

René Smit, Independent Software Developer.
Download my GPx tools here.

I will soon find out for montreal as i am using a reduced track. Maybe its related to the new patch.

Right-o assert.txt and gpxtrack.log have been uploaded Rene matey links below:

Roberto: all far sight commands have been removed and it still CTD's. See if you can figure it out from the crash logs?

Gpxtrack.log:

[www.mediafire.com]

Assert.txt:

[www.mediafire.com]



Additional: jus going to try reassigning the split positions, will report back in 2 secs
Edit 2 - Nope that resulted in the same crash. New assert after split modification below:
[www.mediafire.com]





Edited 2 time(s). Last edit at 06/07/2013 07:14PM by ipswich2007.

Thanks. Do you also have gpxpload.txt? I need to match the information there with gpxtrack.log.

René Smit, Independent Software Developer.
Download my GPx tools here.

Yep rene the gpxload is:
[www.mediafire.com]

the issue of the split times is shown in the assert.
need to check about the problem about >=112 internal object. will see in some of my tracks if i exceeded that number

the long list of things related to object or camera is out of my understanding

-------------------------------

Roberto after I changed the split positions that message about >=112 has now gone, so it was A problem but not THE problem.

EDIT no it hasnt its this:0x00411976 -> Split segment too high. Maybe the track is too small:
Let's say E is the last segment nr, and S is the split segment number.
Then GPx can't find 8 consecutive segments in the range [S, min(E-64, S+24*8)]
without bridged fences.

That has now gone





Edited 1 time(s). Last edit at 06/07/2013 07:18PM by ipswich2007.

The amount of objects shouldn't be a problem though because Belini Singapore 2010 has 130 so..

seen.

don't know, i've put up the typical 'conversion' issues. if none was the case, let's see what René finds.
btw have you tried Hungaroring? I remember being another complicated track

-------------------------------

Yup Hungaroring works perfectly (after removing farsight of course) :/ As do all the other tracks, it's just Monaco & Montreal

I found the problem with the crash. It's some obscure code that does something at 6 segments before some other segment, but when it's at the start of the track this will reference code outside of the allocated track segment buffer. I already patched this for GP4, but I forgot to patch it for GP3/GP3-2000. The patch is to subtract 0 instead of 6, i.e. use the segment itself. No idea what the code actually does though

René Smit, Independent Software Developer.
Download my GPx tools here.

For a noob who doesn't understand what you mean, how do we fix this or do we need to wait for an updated GPXpatch? (which I am okay with)?

You need to wait for 4.21
Where can I download this crashing track? This is so I can double check it here.

René Smit, Independent Software Developer.
Download my GPx tools here.

I'll link ya to it as I don't know where the belini farewell stuff is hosted these days you can download the dat here:

Monaco:
[www.mediafire.com]


Canada:
[www.mediafire.com]