• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 09:43:33 PM

News:

World Racing Series beta14 available! :)


code error openGL

Started by yoshimura, October 02, 2014, 07:29:38 AM

Previous topic - Next topic

matty0l215

Quote from: HornetMaX on October 03, 2014, 09:32:53 AM

@matty: if you can reproduce it at will, maybe piboso can have a look.

Hit any of the joins in the wall, its easier to ode core when the bike is moving (like when the bike wobbles mid lean), but saying that i don't think i've ever had just a plain core.exe offline and there were never many people online when testing so i can't remember weather i could get it to core.exe online
For faster responses, please visit the discord server- HERE

matty0l215

October 03, 2014, 12:40:11 PM #16 Last Edit: October 03, 2014, 12:49:52 PM by matty0l215
Just tried it again online

Doesn't even need to be right in the corner. As long as it's near.



Not a great picture, but the corner is just out of shot on the left and this is where it crashed, I can do it on most corners, it's more difficult on shallower corners ( 90 degrees and below is easier)

Edit, its not the corners, its the join/gap between edges.

Again sorry for the potato picture, but look how the bikes rear wheel is off the floor and when i hit, the bike jumped as the front wheel went through the gap, the whole front wheel has gone through
For faster responses, please visit the discord server- HERE

Hawk

October 03, 2014, 01:44:15 PM #17 Last Edit: October 03, 2014, 07:40:40 PM by Hawk_UK
If it's gaps causing these core crashes(which in part I believe it is), then surely that is a problem due to the methods and modelling procedures of track authors, not GPB?
I honestly believe this is part of the problem but not a solution to the whole core crash problems. But it would help if track authors made sure the tracks were clean of any artifacts before they were released, especially with regards to ripped tracks, as it is these ripped tracks that in my opinion are the cause of a vast majority of core crashes(the positive is: they seem to be getting better as updates are released). :)

But I also believe that the work required to go through a ripped track to make sure it is clean, the author would be better using that considerable time to create the same track from scratch.

So with ripped tracks: If the tracks were made NDS and the tracks were properly cleaned up after ripping, then I think the vast majority of core.exe crashes would cease?

The only track Piboso can rely on for his testing of GPB is the default track that came with GPB, namely Victoria, as this track I'm presuming he created cleanly using his own track making rules, which I also presume he understands completely. This is why I presume he is seemingly not taking much notice or making any response to tests we make with tracks created by anyone else, or even tests made on tracks created by others as it would simply be too time consuming to have to check everything on a track to make sure that every track making rule was followed correctly on top of having to check all the 3D models of the track to make sure they were complete without any errors.
If we could trust that GPB wasn't causing the core.exe problems(which I guess we will be able to in the future?), then we could easily sort out the good tracks from the bad. But in conclusion, my opinion is that it is the ill prepared ripped tracks that are the cause of the vast majority of core.exe issues with GPB at this time.

These are just my thoughts on this subject and by no means a statement for a complete solution to this on-going problem as I also think there are other issues that are probably contributing to the core.exe crash problem too, ie: the memory leak problem which I believe Piboso is already aware of.


Hawk.

matty0l215

Quote from: Hawk_UK on October 03, 2014, 01:44:15 PM
If it's gaps causing these core crashes(which in part I believe it is), then surely that is a problem due to the methods and modelling procedures of track authors, not GPB?
I honestly believe this is part of the problem but not a solution to the whole core crash problems. But it would help if track authors made sure the tracks were clean of any artifacts before they were released, especially with regards to ripped tracks, as it is these ripped tracks that in my opinion are the cause of a vast majority of core crashes(the positive is: they seem to be getting better as updates are released). :)

But I also believe that the work required to go through a ripped track to make sure it is clean, the author would be better using that considerable time to create the same track from scratch.

So with ripped tracks: If the tracks were made NDS and the tracks were properly cleaned up after ripping, then I think the vast majority of core.exe crashes would cease?

The only track Piboso can rely on for his testing of GPB is the default track that came with GPB, namely Victoria, as this track I'm presuming he created cleanly using his own track making rules, which I also presume he understands completely. This is why I presume he is seemingly not taking much notice or making any response to tests we make with tracks created by anyone else, or even tests made on tracks created by others as it would simply be too time consuming to have to check everything on a track to make sure that every track making rule was followed correctly on top of having to check all the 3D models of the track to make sure they were complete without any errors.
If we could trust that GPB wasn't causing the core.exe problems(which I guess we will be able to in the future?), then we could easily sort out the good tracks from the bad. But in conclusion, my opinion is that it is the ill prepared ripped tracks that are the cause the vast majority of core.exe issues with GPB at this time.

These are just my thoughts on this subject and by no means a statement for a complete solution to this on-going problem as I also think there are other issues that are probably contributing to the core.exe crash problem too, ie: the memory leak problem which I believe Piboso is already aware of.


Hawk.

well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe

I found out yesterday that KRP tracks work in GP bikes but i had no end of ODE cores (nearly every time i left the track in some cases) so I stopped using them but does KRP suffer from cores?? and if no, what is different that stops them from hapening.
For faster responses, please visit the discord server- HERE

HornetMaX

Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe
Exact. Personally, in the few cores I used to have, I had more crashes due to something else than due to the ODE normalization error.

Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
I found out yesterday that KRP tracks work in GP bikes but i had no end of ODE cores (nearly every time i left the track in some cases) so I stopped using them but does KRP suffer from cores?? and if no, what is different that stops them from hapening.
That's interesting, very interesting. But only Piboso can have a look.

MaX.

matty0l215

Quote from: HornetMaX on October 03, 2014, 08:47:39 PM
Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe
Exact. Personally, in the few cores I used to have, I had more crashes due to something else than due to the ODE normalization error.

Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
I found out yesterday that KRP tracks work in GP bikes but i had no end of ODE cores (nearly every time i left the track in some cases) so I stopped using them but does KRP suffer from cores?? and if no, what is different that stops them from hapening.
That's interesting, very interesting. But only Piboso can have a look.

MaX.

Also, if you put a GP bikes track into MX bikes, it throws a ODE Error as soon as you go to track
For faster responses, please visit the discord server- HERE

RBp

ODE is the physic engine used.

Hawk

Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
Quote from: Hawk_UK on October 03, 2014, 01:44:15 PM
If it's gaps causing these core crashes(which in part I believe it is), then surely that is a problem due to the methods and modelling procedures of track authors, not GPB?
I honestly believe this is part of the problem but not a solution to the whole core crash problems. But it would help if track authors made sure the tracks were clean of any artifacts before they were released, especially with regards to ripped tracks, as it is these ripped tracks that in my opinion are the cause of a vast majority of core crashes(the positive is: they seem to be getting better as updates are released). :)

But I also believe that the work required to go through a ripped track to make sure it is clean, the author would be better using that considerable time to create the same track from scratch.

So with ripped tracks: If the tracks were made NDS and the tracks were properly cleaned up after ripping, then I think the vast majority of core.exe crashes would cease?

The only track Piboso can rely on for his testing of GPB is the default track that came with GPB, namely Victoria, as this track I'm presuming he created cleanly using his own track making rules, which I also presume he understands completely. This is why I presume he is seemingly not taking much notice or making any response to tests we make with tracks created by anyone else, or even tests made on tracks created by others as it would simply be too time consuming to have to check everything on a track to make sure that every track making rule was followed correctly on top of having to check all the 3D models of the track to make sure they were complete without any errors.
If we could trust that GPB wasn't causing the core.exe problems(which I guess we will be able to in the future?), then we could easily sort out the good tracks from the bad. But in conclusion, my opinion is that it is the ill prepared ripped tracks that are the cause the vast majority of core.exe issues with GPB at this time.

These are just my thoughts on this subject and by no means a statement for a complete solution to this on-going problem as I also think there are other issues that are probably contributing to the core.exe crash problem too, ie: the memory leak problem which I believe Piboso is already aware of.


Hawk.

well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe

Very rare my above statements cause a ODE crash, they mainly do certainly cause core.exe crashes, of which I can reproduce at will.  ;)

The reality is that none of us know what is the root cause of these problems. We are certainly only seeing the symptoms of some issue that is causing the crashes, be they ODE or Core.exe. I presume this is why Piboso is talking about designing special debug tools to finally nail down the issue?  :)


Hawk.

matty0l215

Quote from: Hawk_UK on October 05, 2014, 11:05:18 AM
Very rare my above statements cause a ODE crash, they mainly do certainly cause core.exe crashes, of which I can reproduce at will.  ;)

The reality is that none of us know what is the root cause of these problems. We are certainly only seeing the symptoms of some issue that is causing the crashes, be they ODE or Core.exe. I presume this is why Piboso is talking about designing special debug tools to finally nail down the issue?  :)


Hawk.
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
For faster responses, please visit the discord server- HERE

HornetMaX

Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.

yoshimura

October 05, 2014, 04:37:24 PM #25 Last Edit: October 05, 2014, 04:38:58 PM by yoshimura
Quote from: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.


why not include a log / file errors, to provide support for piboso?as in any program.

HornetMaX

Quote from: yoshimura on October 05, 2014, 04:37:24 PM
Quote from: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.


why not include a log / file errors, to provide support for piboso?as in any program.

Which log file error ? The standard windows one ? That's basically useless.

If we want a meaningful log file, Pibos has to add some debug/logging code to GPB. Hence we cannot help.

MaX.

matty0l215

Quote from: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.
Fair enough. Don't want to start that argument again  :P
For faster responses, please visit the discord server- HERE