Actually it's more of an happy start: http://forum.mx-bikes.com/index.php?topic=1329.msg19656#msg19656 (http://forum.mx-bikes.com/index.php?topic=1329.msg19656#msg19656)
@PiBoSo: thanks, sincerely.
Thank you, Thank you, Thank you! ;D
Grazie Mille
Ohhh that's good news.
Quote from: HornetMaX on October 19, 2016, 07:43:06 PM
Actually it's more of an happy start: http://forum.mx-bikes.com/index.php?topic=1329.msg19656#msg19656 (http://forum.mx-bikes.com/index.php?topic=1329.msg19656#msg19656)
@PiBoSo: thanks, sincerely.
Does it mean the netcode would be fix on MXB or in All PiBoSo games ?
That is as good as an early Christmas! Superb news indeed! ;D 8)
Thank you Piboso! :-* ;D 8)
Hawk.
Hallelujah :D
Excellent news.
Thank you.
Great and long awaitet news!!
Thank you so much ;D
Great, great new!!!
THANK YOU!!!!
Glad to hear. Best of luck! I hope like hell the community is right and sales take off after the online issues are resolved. :)
Woop!! Great news!!!
Thank you Piboso and team!!!
Thank you Piboso
good decision there, thank you
So I take it all work is for MXB and everything else is on hold?
It would be nice to know thanks Piboso
DD
Quote from: doubledragoncc on October 20, 2016, 10:01:59 AM
So I take it all work is for MXB and everything else is on hold?
It would be nice to know thanks Piboso
DD
It would be more than logical to assume the fixed netcode works on every Piboso sim since they share so many things.
Yes but that is not a given FACT B. Look at the size of MXB to GPB, there is a massive difference in file size so WHAT is GPB missing and does it mean it will have to have GPB netcode done separately?
Only Piboso can answer it and it is a simple yes or no really.
I think it is only fair we know exactly where we stand in this situation. Not much to ask.
DD
The file size difference is probably due to this DD -
GPB - 1 Track, 3 Bikes
MXB - 6 Tracks, 5 Bikes
Not sure but I thought all Piboso's produce shared lots of things, base net code included.
Quote from: doubledragoncc on October 20, 2016, 10:01:59 AM
So I take it all work is for MXB and everything else is on hold?
It would be nice to know thanks Piboso
DD
+1
Hiiiiiiiiiiiiiiiihaaaaaaaaaaaaaaaa, youplaboum, tralalilala, wow
Thank you piboso
Quote from: doubledragoncc on October 20, 2016, 10:01:59 AM
So I take it all work is for MXB and everything else is on hold?
It would be nice to know thanks Piboso
DD
Work is on netcode and everything else is on hold ( physics, new features, ... ).
It hasn't been decided yet, but GPB will probably be the platform used for public tests because, of the two projects with "stable" physics ( GPB and KRP ), it is the one that should be easier to organize tests with, and also the one that gives generates more online problems.
The other simulators, mostly MXB, will instead be used for internal testing to fix the "lag" ( or, to be precise, lack of smoothness ) issue.
Thank you so much for the answer. I am sure it will please everyone and put many questions to rest.
I am glad you have taken this road and sure it will be the right one.
Thank you for hanging on and making such a good and professional choice.
DD
Thanks for the info Piboso, appreciated. ;) 8)
Hawk.
PS: +1 DD. Well said mate. ;) 8)
Quote from: PiBoSo on October 20, 2016, 01:35:55 PM
Work is on netcode and everything else is on hold ( physics, new features, ... ).
It hasn't been decided yet, but GPB will probably be the platform used for public tests because, of the two projects with "stable" physics ( GPB and KRP ), it is the one that should be easier to organize tests with, and also the one that gives generates more online problems.
The other simulators, mostly MXB, will instead be used for internal testing to fix the "lag" ( or, to be precise, lack of smoothness ) issue.
Excellent ! I'm convinced we have two issues at hand: one is game stability (crashes), the other is multiplayer netcode (lack of smoothness).
They may be related, but it's not 100% sure. From what I've seen, the 1st seems to affect more GPB, the second more MXB.
Quote from: HornetMaX on October 20, 2016, 02:37:36 PM
Quote from: PiBoSo on October 20, 2016, 01:35:55 PM
Work is on netcode and everything else is on hold ( physics, new features, ... ).
It hasn't been decided yet, but GPB will probably be the platform used for public tests because, of the two projects with "stable" physics ( GPB and KRP ), it is the one that should be easier to organize tests with, and also the one that gives generates more online problems.
The other simulators, mostly MXB, will instead be used for internal testing to fix the "lag" ( or, to be precise, lack of smoothness ) issue.
Excellent ! I'm convinced we have two issues at hand: one is game stability (crashes), the other is multiplayer netcode (lack of smoothness).
They may be related, but it's not 100% sure. From what I've seen, the 1st seems to affect more GPB, the second more MXB.
Unfortunately the situation is worse.
There are additional reported problems:
- very long connection times
- laptimes arriving very late
- chat not working after a while
I really noticed how long load times for MXB are compared to GPB and to be honest it showed me how lucky we have been in GPB>
If I can help with testing in anyway I am at your service Piboso. For both MXB and GPB
DD
Quote from: PiBoSo on October 20, 2016, 02:45:14 PM
Unfortunately the situation is worse.
There are additional reported problems:
- very long connection times
- laptimes arriving very late
- chat not working after a while
True, but from what I've seen chat issues and laptime issues seems to be part of the broader "server going nuts" problem.
Absolutely right about connection time, sometimes one just can't connect to the server (stuck at "Connecting" or "Connected" state). This may be independent from anything else.
[Side note, mostly for others: some recent mod bikes are huge in size and it seems to me that that has an influence on the connection time, even when everything goes fine]
Mod bikes definitely play a part when returning to the pit after someone joins. Sometimes hangs for 30 + seconds and sometimes cores
Quote from: HornetMaX on October 20, 2016, 03:38:29 PM
Quote from: PiBoSo on October 20, 2016, 02:45:14 PM
Unfortunately the situation is worse.
There are additional reported problems:
- very long connection times
- laptimes arriving very late
- chat not working after a while
True, but from what I've seen chat issues and laptime issues seems to be part of the broader "server going nuts" problem.
Absolutely right about connection time, sometimes one just can't connect to the server (stuck at "Connecting" or "Connected" state). This may be independent from anything else.
[Side note, mostly for others: some recent mod bikes are huge in size and it seems to me that that has an influence on the connection time, even when everything goes fine]
The huge size could be because some bikeMODS are being shipped with a lot of bike paints - Many in the region of 4MB+ in size for a single paint file(Too much and there's no need for paints that size in my opinion).
Hawk.
Quote from: PiBoSo on October 20, 2016, 02:45:14 PM
Unfortunately the situation is worse.
There are additional reported problems:
- very long connection times
- laptimes arriving very late
- chat not working after a while
From my point of view it should also be taken into consideration that the netcode problems are 90% gone as soon as non dynamic tracks are used. I have said it before, with NDS I am experiencing very rare/almost no core.exe problems. Maybe you should try to tackle it iterativelly.
1. get rid of problems in NDS
2. then gradually turn dynamic features on (testing e.g. with very simple dynamic track features that use less variables, testing with small groove multipliers etc etc)
That way you can maybe gradually corner isolate the biggest problems and memory leaks. I am confident you can locate most of the erratic stuff if you go at it deliberately and well-planned.
I have said it before, without dynamic track stuff (NDS tracks), your netcode actually seems pretty good in GPB. I have seen "jumping" or "lagging" very rarely, even with guys that have very high pings.
Quote from: Hawk on October 20, 2016, 03:53:36 PM
The huge size could be because some bikeMODS are being shipped with a lot of bike paints
Partially. Even removing the paints, some bikes are much bigger than others (edf files).
With all the paints removed (which i didn't know they were there :P) the pack is still 2.75GB
Quote from: HornetMaX on October 20, 2016, 05:32:53 PM
Partially. Even removing the paints, some bikes are much bigger than others (edf files).
Yes, mostly because of the size and number of maps applied on the model :)
Quote from: Stout Johnson on October 20, 2016, 04:02:38 PM
From my point of view it should also be taken into consideration that the netcode problems are 90% gone as soon as non dynamic tracks are used. I have said it before, with NDS I am experiencing very rare/almost no core.exe problems. Maybe you should try to tackle it iterativelly.
Quite true, but thats with 6-7 riders. I would say with 12-15 riders things goes nuts with or without Nds
Quote from: GuiTP on October 21, 2016, 03:52:24 AM
Since I gave GPB a shot again, I've had about 10 core.exe, all in the menu when going through different bikes ( < 10 paints even). Memory utilization wasn't even high, ~130mb.
Yes. This is a known problem..... A work around is to restart GPB if you want to change a bike or track to avoid further problems should you manage to succeed and get online. ;)
Hawk.
At least for MXB, I turned up my virtual memory to 64GB (have 32 GB physical) and since doing so I can switch bikes/tracks and get online without restarting the sim.
Also, since doing this I have had absolutely 0 cores at all even with graphics totally max'd.
Quote from: geofanatec on October 21, 2016, 02:47:33 PM
At least for MXB, I turned up my virtual memory to 64GB (have 32 GB physical) and since doing so I can switch bikes/tracks and get online without restarting the sim.
Also, since doing this I have had absolutely 0 cores at all even with graphics totally max'd.
That may be interesting. Something fishy with memory allocation/deallocation has always been my #1 suspect for core.exe crashes (except the ode ones and except the netcode related ones).
Well, also 1 other thing I do too that I did at same time of virtual memory adjustment (so, could be combination of things). I have the Poseidon 980 TI card and in their GPUTweak I never cared before, but started to enable gaming boost (shuts down unneeded Windows crap) and run it in over-clock instead of just gaming mode.
Quote from: geofanatec on October 21, 2016, 02:47:33 PM
At least for MXB, I turned up my virtual memory to 64GB (have 32 GB physical) and since doing so I can switch bikes/tracks and get online without restarting the sim.
Also, since doing this I have had absolutely 0 cores at all even with graphics totally max'd.
That is interesting.
Maybe you should post this in a dedicated thread of it's own as a temp-workaround suggestion/solution for the core.exe issue?
Hawk.
Quote from: Hawk on October 21, 2016, 03:36:00 PM
That is interesting.
Maybe you should post this in a dedicated thread of it's own as a temp-workaround suggestion/solution for the core.exe issue?
Yes. Or one of the moderators should maybe try to gather the most helpful hints (in terms of likeliness to be linked to core.exe) from here and present them to Piboso.
Btw: Geofanatec seems to be very new to GPB - I don't know if we can trust that guy :P ;D
Quote from: RiccoChicco on October 20, 2016, 06:02:34 PM
Quote from: HornetMaX on October 20, 2016, 05:32:53 PM
Partially. Even removing the paints, some bikes are much bigger than others (edf files).
Yes, mostly because of the size and number of maps applied on the model :)
You could make a scaled set of textures to make them much smaller and give that a try for online
I didn't want to imply that online issues could come from the bike size, it was just to say that connection times can be a bit longer on big bikes (and it's probably normal).
Quote from: h106frp on October 21, 2016, 04:27:59 PM
You could make a scaled set of textures to make them much smaller and give that a try for online
U need a test for see that a bike with smaller maps load more fast? ;D