Times are UTC Toggle Colours
00:30:56 *** Supercheese has joined #openttd.dev 00:30:56 *** ChanServ sets mode: +v Supercheese 03:12:06 *** LuHa has joined #openttd.dev 03:12:06 *** ChanServ sets mode: +v LuHa 06:08:12 *** LuHa has quit IRC 06:47:31 *** Supercheese has quit IRC 08:51:33 *** Alberth has joined #openttd.dev 08:51:33 *** ChanServ sets mode: +v Alberth 13:12:31 *** frosch123 has joined #openttd.dev 13:12:31 *** ChanServ sets mode: +v frosch123 14:11:40 *** LuHa has joined #openttd.dev 14:11:40 *** ChanServ sets mode: +v LuHa 14:26:09 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26360 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:32:38 *** LuHa has quit IRC 18:45:29 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26361 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:58:55 <frosch123> wow 18:59:55 <frosch123> hmm, how boring 19:00:29 <frosch123> so, i replayed the desync files which pm saved. the dmp_cmds savegames from the orignal server and the replay match 19:01:10 <frosch123> so, either the desync really only started after the last dmp_cmds 19:01:35 <frosch123> or it affects something that is not part of the savegame at all 19:10:43 <frosch123> oh, not true, i compared the wrong files :/ 19:14:52 <Alberth> hopefully with better results 19:15:06 <frosch123> yes, the first two saves match 19:15:09 <frosch123> that last pair does not 19:23:22 <Rubidium> evening 19:34:58 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26362 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:44:28 <Rubidium> http://rbijker.net/openttd/fs5894_worth_they_effort%3f.diff <- shouldn't change a bit, except being more explicit 19:49:04 <frosch123> looks safe 19:49:15 <frosch123> the invalid case cannot happen when extracting 2 resp. 1 bit 19:50:17 <Alberth> comment is a bit silly indeed 19:52:20 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26363 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:00:57 <fonsinchen> frosch123, I'll go and test your patches for FS#5867 now... 20:01:12 <fonsinchen> That means I'll be offline. Any final comments? 20:01:19 <frosch123> thanks :) 20:01:41 <Rubidium> @base 10 16 148 20:01:41 <DorpsGek> Rubidium: 94 20:03:36 <frosch123> hmm, what's the CMDL hunk 20:03:47 <frosch123> cargomonitor 20:11:35 <frosch123> pff 60k of gamescript save data 20:28:25 <frosch123> http://paste.openttdcoop.org/show/3120/ <- difference of the last cmd_dmps from the public server desync 20:28:34 <Rubidium> @base 10 16 2980539799699456 20:28:34 <DorpsGek> Rubidium: A96C900000000 20:29:11 <Rubidium> definitely a wrong value for first_unused 20:29:32 <frosch123> basically two industries, stations and cargopackets differ in the amount of some cargo 20:31:02 <Rubidium> frosch123: FS#5831? 20:31:28 <Rubidium> their solution was to revert to the "broken" persistent storage 20:31:31 <frosch123> no, pm last weekend 20:31:50 <frosch123> 1.4.0-beta4 20:32:01 <Rubidium> frosch123: no, not that you are looking at FS#5831, but that it smells like the same thing 20:32:07 <frosch123> i took the start-savegame and cmd_dmp saves from planetmaker 20:32:32 <Rubidium> i.e. something with the persistent storage 20:33:04 <frosch123> hmm, ok, i'll check the 'closure_counter' 20:33:27 <frosch123> that should behave deterministaclly or something, it looks like it is incremented at defined places 20:45:13 <Rubidium> FS#5892 is weird 20:46:07 <Rubidium> if that jptracks newgrf is loaded in a debug build of that exact revision, then it crashes upon closing with a orderlist pool first_unused of HUGE (number of 21:28) 20:46:15 <Rubidium> however, the pool is completely empty 20:46:30 <Rubidium> if the NewGRF isn't loaded, nothing bad happens 20:46:38 <frosch123> valgrind? 20:46:59 <frosch123> or windows only? 20:47:21 <Rubidium> valgrind on Linux doesn't seem to trigger anything 20:47:45 <Rubidium> should check the actual revision though 20:48:02 <Rubidium> although today Windows nightly crashes in the same way 20:49:10 <frosch123> well, if it is windows only, it may very likely be fs#5867 which looks like a random invalid write to me 20:49:27 <Rubidium> yup 20:57:05 <Rubidium> @base 16 10 A96C9 20:57:05 <DorpsGek> Rubidium: 693961 20:57:14 <Rubidium> @calc 693961/365 20:57:14 <DorpsGek> Rubidium: 1901.2630137 20:57:21 <Rubidium> @calc 693961/365.25 20:57:21 <DorpsGek> Rubidium: 1899.96167009 21:06:06 <Rubidium> http://rbijker.net/openttd/fs5892.diff <- I have high hopes that fixes it 21:07:21 <frosch123> how? 21:07:44 <Rubidium> memset(this->railtype_map, INVALID_RAILTYPE, sizeof(this->railtype_map)); 21:07:57 <Rubidium> if (rt == INVALID_RAILTYPE) return CIR_INVALID_ID; 21:08:13 <Rubidium> now INVALID_RAILTYPE = 0xFF 21:08:22 <frosch123> ah 21:08:25 <Rubidium> imagine that sizeof(RailType) != 1 21:09:47 <Rubidium> valgrind wouldn't notice because it's all in the global-allocated-at-start pool 21:10:14 <frosch123> looks nice .) 21:12:34 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26364 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:32:59 *** Alberth has left #openttd.dev 23:13:09 *** frosch123 has quit IRC 23:17:43 <fonsinchen> Well, with those new insights about FS#5867 I'll look at the code again with a less claustrophobic editor tomorrow to see if and where those cursor sprites are actually changed.