Times are UTC Toggle Colours
00:19:40 *** Alberth has left #openttd.dev 00:20:59 *** andythenorth has quit IRC 01:52:56 *** FLHerne has quit IRC 01:53:12 *** FLHerne has joined #openttd.dev 03:36:45 *** FLHerne has quit IRC 09:46:50 *** Alberth has joined #openttd.dev 09:46:50 *** ChanServ sets mode: +v Alberth 10:51:41 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24877 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 11:03:34 *** Zuu_ has joined #openttd.dev 11:07:31 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24878 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 11:43:41 *** Zuu_ has quit IRC 11:53:43 *** fonsinchen has joined #openttd.dev 11:53:43 *** ChanServ sets mode: +v fonsinchen 12:58:52 *** FLHerne has joined #openttd.dev 13:11:23 *** andythenorth has joined #openttd.dev 13:11:23 *** ChanServ sets mode: +v andythenorth 13:18:06 *** ntoskrnl has joined #openttd.dev 14:01:21 *** Zuu has joined #openttd.dev 14:01:21 *** ChanServ sets mode: +v Zuu 16:06:20 *** Alberth has left #openttd.dev 17:53:30 <planetmaker> anyone fancy looking at some desync data, newly gathered at the coop public server. Didn't need much time to create after enabling desync=3 and reload 17:58:28 *** andythenorth has quit IRC 17:59:34 <Rubidium> planetmaker: where can it be found? 18:00:15 <planetmaker> I got the data all still on our public server. Dunno... do you have ssh there (ps.o.o)? 18:00:47 <Rubidium> I remember there being some URL to get the data, but can't remember the begin... so no help from my browser 18:01:22 <planetmaker> right http://ps.openttdcoop.org/public/save/ 18:01:54 <planetmaker> and the autosave subdir 18:02:12 <planetmaker> meanwhile 4 desyncs should be found therein 18:02:19 <planetmaker> just doing nothing suffices 18:02:52 <planetmaker> thus very easy to reproduce, I guess 18:05:09 <planetmaker> http://paste.openttdcoop.org/show/2027/ mind. We compiled with blitter active. But... that shouldn't matter really 18:07:07 <Rubidium> any idea how long till desync? 18:07:47 <Rubidium> ah... there it is 18:08:05 <Rubidium> or at least the cache mismatch 18:15:14 <Rubidium> cached_power isn't in sync 18:19:12 <planetmaker> it took a few minutes at best 18:20:00 <Rubidium> the how and why is still a mystery though 18:20:37 <planetmaker> it uses the NUTS trainset. So probably some weired NewGRF stuff going on 18:23:04 <Rubidium> the vehicle is started, but still in a depot 18:23:26 <Rubidium> not sure what the reason is why something would change at that moment precisely though 18:23:37 <planetmaker> track type change 18:24:48 <Rubidium> but by the looks of it the vehicle doesn't actually leave the depot 18:27:33 *** andythenorth has joined #openttd.dev 18:27:33 *** ChanServ sets mode: +v andythenorth 18:29:45 <planetmaker> Rubidium: power is decided upon in a random varaction2 upon service, unload and load... http://paste.openttdcoop.org/show/2028/ 18:34:39 <planetmaker> Rubidium: look at the orders 18:35:05 <planetmaker> maybe they give a clue... 18:38:19 <Rubidium> it might just reach the station roughly that very tick 18:38:58 <Rubidium> so... no power update upon service happening? 18:42:56 <planetmaker> random power assigned during update. possibly. dunno which train :-) 18:43:05 <planetmaker> *during servicing 18:43:16 <planetmaker> and during load. and after unload all 18:43:17 <Rubidium> unit 23 18:45:05 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24879 || 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:45:06 <planetmaker> yes, that's one of those 18:57:29 <Rubidium> does it also change that upon random varaction2s? 18:57:36 <Rubidium> uhm... I mean loading/unloading? 18:58:07 <planetmaker> yes. See the NML in the link I pasted above. That's the relevant code 18:58:16 <planetmaker> according to V45... 18:59:28 <Rubidium> so a vehicle's power changes by unloading? 18:59:37 <Rubidium> do we really want to support that? 18:59:58 <planetmaker> it does in that case 19:00:52 <planetmaker> I fear, if power is an issue. Other properties might show similar issues. 19:01:18 <Rubidium> things with the looks shouldn't matter 19:01:28 <planetmaker> e.g. everything which can be done by CB 36 19:01:45 <Rubidium> but... then he could also change the capacity 19:01:52 <Rubidium> which we, I hope, disallow 19:02:09 <Rubidium> otherwise there are a lot of asserts that'll trigger 19:02:14 <planetmaker> it's more of a "the mood of the train changed". It's called NUTS for a reason ;-) 19:03:07 <Rubidium> but should *everyone* suffer because of that? 19:03:56 <planetmaker> what is the actual problem here? 19:05:55 <andythenorth> cb36 is a fricking nightmare :) 19:05:55 <planetmaker> if it's a matter of randomness: where would it need to got on that groundsß 19:06:06 <planetmaker> *grounds 19:07:11 <planetmaker> or asked differently: why is that randomness not synced, but others are? 19:07:50 <planetmaker> shouldn't it work, if the right random call is used? 19:08:24 <Rubidium> that for *every* trigger we *must* rebuild all caches and information, and possibly even trash cargo because the cargo type or capacity of the wagon changed 19:09:23 <planetmaker> hm, I see 19:10:28 <Rubidium> I have no problem that some things change during triggers, but it should be conceptually sound 19:10:30 <planetmaker> but we still want to allow random calls for the graphics branch upon load / unload 19:11:41 <planetmaker> well. Removing that possibility "just because it's not realistic" would not suit our usual arguments too well 19:11:57 <andythenorth> how about removing it because it doesn't work? o_O 19:14:11 <Rubidium> we already do "prevent" certain actions, such as changing wagon length 19:14:31 <Rubidium> changing cargo capacity is IMO a big no-no 19:15:11 <planetmaker> capacity isn't changed. Power is, Or do I err? 19:15:53 <Rubidium> currently it is power 19:16:00 <Rubidium> but those nutjobs can also change the capacity 19:16:21 <Rubidium> or at least return a different number 19:16:47 *** V453000 has joined #openttd.dev 19:16:50 <andythenorth> this is when unloading? 19:16:59 <planetmaker> @voice V453000 19:16:59 *** DorpsGek sets mode: +v V453000 19:17:16 <planetmaker> quoting: 19:17:16 <planetmaker> <Rubidium> currently it is power 19:17:16 <planetmaker> <Rubidium> but those nutjobs can also change the capacity 19:17:16 <planetmaker> <Rubidium> or at least return a different number 19:18:15 <V453000> hello :) 19:18:16 <Rubidium> andythenorth: one could while servicing 19:18:22 <V453000> nutjobs wont randomize capacity, they promise :) 19:18:46 <andythenorth> lots of this stuff should only be explicitly on refit afaict 19:18:51 <andythenorth> otherwise it's explodely 19:18:58 <Rubidium> *luckily* it doesn't seem to have much effect as the capacity is saved in the savegame (but it could in theory just be cached) 19:19:00 <andythenorth> maybe we need frosch's thoughts on views 19:19:17 <andythenorth> I am dubious about the capabilities of CB36, it is too powerful 19:20:36 <Rubidium> CB36 isn't that bad, but I don't think random triggers should be allowed to be used to change capacity, weight, power, tractive effort, whether wagons are powered, ... 19:21:36 <Rubidium> though... I reckon "speed" is already changed, so why not the rest? 19:21:53 <andythenorth> changing weight and TE is valid 19:22:11 <andythenorth> erm, perhaps not using random :P 19:23:49 <Rubidium> issue is... somewhat... 19:26:02 <Rubidium> that during (un)loading it doesn't really matter because the cache is (already) updated afterwards 19:26:55 <V453000> the loading is a bit more complicated, it is upon receiving any cargo which can be multiple times 19:27:05 <V453000> but honestly that trigger is a bit weird :) 19:29:55 <Rubidium> V453000: you know what'd make it even nuttier? Change it randomly in the 32 day callback 19:31:25 <V453000> nah that would be stupid :P My very most original idea was only 2 triggers. 1. upon unload, 2. upon service. Also because I thought you can check consist power by conditional orders ... like "jump to order 3 (go to depot - service) if power is < X" so you could "force" them to have good power 19:31:42 <V453000> but as I noticed that isnt under conditional orders I just added that condition of loading too to have more train faces showing 19:32:19 <V453000> they randomize faces (intended to be dependent on ther power random switch - which causes nmlc error) 19:34:09 <V453000> is some particular trigger a problem? (like the loading one) or is it the randomize power issue in total? 19:36:19 <Rubidium> http://rbijker.net/openttd/might_work.diff 19:37:30 <Rubidium> the power trigger during service is what currently is the suspect cause of the desyncs 19:38:02 <V453000> oh :( 19:38:37 <Rubidium> so, to prevent desyncs... prevent servicing ;) 19:39:15 <V453000> he 19:39:25 <V453000> any way to fix those desyncs? :) 19:39:34 <V453000> please? :) 19:39:48 <V453000> it would also be nice if zebras walked the moon and cats could fly 19:40:42 *** ntoskrnl has quit IRC 19:54:07 <Rubidium> ask frosch about the diff I posted not long ago 19:55:41 <V453000> will do 20:58:50 *** fonsinchen has quit IRC 22:04:11 *** andythenorth has left #openttd.dev 22:12:12 <Rubidium> @calc 000be7bf - 000be05d 22:12:12 <DorpsGek> Rubidium: Error: invalid syntax (<string>, line 1) 22:12:18 <Rubidium> @calc 0x000be7bf - 0x000be05d 22:12:18 <DorpsGek> Rubidium: 1890 22:12:41 <Rubidium> @calc (0x000be7bf - 0x000be05d)/365.25 22:12:41 <DorpsGek> Rubidium: 5.17453798768 22:13:09 <Rubidium> it seems to be running for 5 years now without cache "issue" 22:13:25 <V453000> :> 22:19:20 <V453000> are these 0x00 numbers ticks? 22:21:27 <V453000> ah no days 22:21:31 <V453000> zz :) 23:11:05 *** vr6apparatus has quit IRC 23:49:03 *** Sturmi has joined #openttd.dev