Log for on 1st January 2013:
Times are UTC Toggle Colours
00:19:40  *** Alberth has left
00:20:59  *** andythenorth has quit IRC
01:52:56  *** FLHerne has quit IRC
01:53:12  *** FLHerne has joined
03:36:45  *** FLHerne has quit IRC
09:46:50  *** Alberth has joined
09:46:50  *** ChanServ sets mode: +v Alberth
10:51:41  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24877 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
11:03:34  *** Zuu_ has joined
11:07:31  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24878 || Logs: || 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
11:53:43  *** ChanServ sets mode: +v fonsinchen
12:58:52  *** FLHerne has joined
13:11:23  *** andythenorth has joined
13:11:23  *** ChanServ sets mode: +v andythenorth
13:18:06  *** ntoskrnl has joined
14:01:21  *** Zuu has joined
14:01:21  *** ChanServ sets mode: +v Zuu
16:06:20  *** Alberth has left
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
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> 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
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...
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: || 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
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>
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
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

Powered by YARRSTE version: svn-trunk