IRC logs for #openttd.dev on OFTC at 2013-01-01
⏴ go to previous day
00:20:32 *** Alberth has left #openttd.dev
01:54:03 *** FLHerne has joined #openttd.dev
09:47:42 *** Alberth has joined #openttd.dev
09:47:42 *** ChanServ sets mode: +v Alberth
11:04:26 *** Zuu_ has joined #openttd.dev
11:54:34 *** fonsinchen has joined #openttd.dev
11:54:34 *** ChanServ sets mode: +v fonsinchen
12:59:44 *** FLHerne has joined #openttd.dev
13:12:15 *** andythenorth has joined #openttd.dev
13:12:15 *** ChanServ sets mode: +v andythenorth
13:18:57 *** ntoskrnl has joined #openttd.dev
14:02:13 *** Zuu has joined #openttd.dev
16:07:11 *** Alberth has left #openttd.dev
17:54:22 <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
18:00:26 <Rubidium> planetmaker: where can it be found?
18:01:07 <planetmaker> I got the data all still on our public server. Dunno... do you have ssh there (ps.o.o)?
18:01:39 <Rubidium> I remember there being some URL to get the data, but can't remember the begin... so no help from my browser
18:02:46 <planetmaker> and the autosave subdir
18:03:04 <planetmaker> meanwhile 4 desyncs should be found therein
18:03:11 <planetmaker> just doing nothing suffices
18:03:43 <planetmaker> thus very easy to reproduce, I guess
18:07:59 <Rubidium> any idea how long till desync?
18:08:57 <Rubidium> or at least the cache mismatch
18:16:06 <Rubidium> cached_power isn't in sync
18:20:04 <planetmaker> it took a few minutes at best
18:20:52 <Rubidium> the how and why is still a mystery though
18:21:29 <planetmaker> it uses the NUTS trainset. So probably some weired NewGRF stuff going on
18:23:56 <Rubidium> the vehicle is started, but still in a depot
18:24:18 <Rubidium> not sure what the reason is why something would change at that moment precisely though
18:24:29 <planetmaker> track type change
18:25:40 <Rubidium> but by the looks of it the vehicle doesn't actually leave the depot
18:28:25 *** andythenorth has joined #openttd.dev
18:28:25 *** ChanServ sets mode: +v andythenorth
18:35:31 <planetmaker> Rubidium: look at the orders
18:35:57 <planetmaker> maybe they give a clue...
18:39:11 <Rubidium> it might just reach the station roughly that very tick
18:39:50 <Rubidium> so... no power update upon service happening?
18:43:48 <planetmaker> random power assigned during update. possibly. dunno which train :-)
18:43:57 <planetmaker> *during servicing
18:44:08 <planetmaker> and during load. and after unload all
18:45:58 <planetmaker> yes, that's one of those
18:58:21 <Rubidium> does it also change that upon random varaction2s?
18:58:28 <Rubidium> uhm... I mean loading/unloading?
18:58:59 <planetmaker> yes. See the NML in the link I pasted above. That's the relevant code
18:59:08 <planetmaker> according to V45...
19:00:20 <Rubidium> so a vehicle's power changes by unloading?
19:00:28 <Rubidium> do we really want to support that?
19:00:50 <planetmaker> it does in that case
19:01:44 <planetmaker> I fear, if power is an issue. Other properties might show similar issues.
19:02:10 <Rubidium> things with the looks shouldn't matter
19:02:20 <planetmaker> e.g. everything which can be done by CB 36
19:02:37 <Rubidium> but... then he could also change the capacity
19:02:44 <Rubidium> which we, I hope, disallow
19:03:01 <Rubidium> otherwise there are a lot of asserts that'll trigger
19:03:06 <planetmaker> it's more of a "the mood of the train changed". It's called NUTS for a reason ;-)
19:03:59 <Rubidium> but should *everyone* suffer because of that?
19:04:48 <planetmaker> what is the actual problem here?
19:06:47 <planetmaker> if it's a matter of randomness: where would it need to got on that groundsß
19:06:47 <andythenorth> cb36 is a fricking nightmare :)
19:08:03 <planetmaker> or asked differently: why is that randomness not synced, but others are?
19:08:41 <planetmaker> shouldn't it work, if the right random call is used?
19:09:16 <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:11:20 <Rubidium> I have no problem that some things change during triggers, but it should be conceptually sound
19:11:22 <planetmaker> but we still want to allow random calls for the graphics branch upon load / unload
19:12:33 <planetmaker> well. Removing that possibility "just because it's not realistic" would not suit our usual arguments too well
19:12:49 <andythenorth> how about removing it because it doesn't work? o_O
19:15:03 <Rubidium> we already do "prevent" certain actions, such as changing wagon length
19:15:23 <Rubidium> changing cargo capacity is IMO a big no-no
19:16:03 <planetmaker> capacity isn't changed. Power is, Or do I err?
19:16:45 <Rubidium> currently it is power
19:16:52 <Rubidium> but those nutjobs can also change the capacity
19:17:13 <Rubidium> or at least return a different number
19:17:39 *** V453000 has joined #openttd.dev
19:17:42 <andythenorth> this is when unloading?
19:17:51 *** DorpsGek sets mode: +v V453000
19:18:08 <planetmaker> <Rubidium> currently it is power
19:18:08 <planetmaker> <Rubidium> but those nutjobs can also change the capacity
19:18:08 <planetmaker> <Rubidium> or at least return a different number
19:19:08 <Rubidium> andythenorth: one could while servicing
19:19:14 <V453000> nutjobs wont randomize capacity, they promise :)
19:19:38 <andythenorth> lots of this stuff should only be explicitly on refit afaict
19:19:43 <andythenorth> otherwise it's explodely
19:19:50 <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:52 <andythenorth> maybe we need frosch's thoughts on views
19:20:09 <andythenorth> I am dubious about the capabilities of CB36, it is too powerful
19:21:28 <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:22:27 <Rubidium> though... I reckon "speed" is already changed, so why not the rest?
19:22:45 <andythenorth> changing weight and TE is valid
19:23:03 <andythenorth> erm, perhaps not using random :P
19:24:41 <Rubidium> issue is... somewhat...
19:26:54 <Rubidium> that during (un)loading it doesn't really matter because the cache is (already) updated afterwards
19:27:46 <V453000> the loading is a bit more complicated, it is upon receiving any cargo which can be multiple times
19:27:57 <V453000> but honestly that trigger is a bit weird :)
19:30:47 <Rubidium> V453000: you know what'd make it even nuttier? Change it randomly in the 32 day callback
19:32:17 <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:32:34 <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:33:11 <V453000> they randomize faces (intended to be dependent on ther power random switch - which causes nmlc error)
19:35:01 <V453000> is some particular trigger a problem? (like the loading one) or is it the randomize power issue in total?
19:38:21 <Rubidium> the power trigger during service is what currently is the suspect cause of the desyncs
19:39:28 <Rubidium> so, to prevent desyncs... prevent servicing ;)
19:40:17 <V453000> any way to fix those desyncs? :)
19:40:40 <V453000> it would also be nice if zebras walked the moon and cats could fly
19:54:58 <Rubidium> ask frosch about the diff I posted not long ago
22:05:03 *** andythenorth has left #openttd.dev
22:13:04 <Rubidium> @calc 000be7bf - 000be05d
22:13:04 <DorpsGek> Rubidium: Error: invalid syntax (<string>, line 1)
22:13:10 <Rubidium> @calc 0x000be7bf - 0x000be05d
22:13:32 <Rubidium> @calc (0x000be7bf - 0x000be05d)/365.25
22:13:32 <DorpsGek> Rubidium: 5.17453798768
22:14:01 <Rubidium> it seems to be running for 5 years now without cache "issue"
22:20:12 <V453000> are these 0x00 numbers ticks?
23:49:55 *** Sturmi has joined #openttd.dev
continue to next day ⏵