Times are UTC Toggle Colours
00:23:02 *** Zuu has quit IRC 01:06:23 *** Sturmi has quit IRC 03:28:22 *** FLHerne has quit IRC 07:27:22 *** Zuu has joined #openttd.dev 07:27:22 *** ChanServ sets mode: +v Zuu 10:13:05 *** FLHerne has joined #openttd.dev 12:04:38 *** Sturmi has joined #openttd.dev 13:19:40 *** FLHerne has quit IRC 14:27:41 *** ntoskrnl has joined #openttd.dev 14:38:16 *** FLHerne has joined #openttd.dev 14:44:44 *** FLHerne has joined #openttd.dev 15:15:52 *** FLHerne has joined #openttd.dev 15:41:03 *** Sturmi has quit IRC 15:44:10 *** Sturmi has joined #openttd.dev 16:16:36 *** FLHerne has quit IRC 18:45:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24880 || 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:48:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24881 || 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:56:55 *** FLHerne has joined #openttd.dev 19:20:02 *** Alberth has joined #openttd.dev 19:20:02 *** ChanServ sets mode: +v Alberth 19:38:47 *** frosch123 has joined #openttd.dev 19:38:47 *** ChanServ sets mode: +v frosch123 19:48:24 <V453000> frosch123: hello, I got an issue ... I somehow got an amazing idea to randomize power of trains ... which resulted in desync errors. Rubi did some stuff I dont understand http://rbijker.net/openttd/might_work.diff and I was told to consult it with you :) 19:48:30 <V453000> could you have a minute please? :) 19:48:39 <V453000> also hi :) 19:49:22 <frosch123> give me some time to catch up with 2013 :p 19:50:09 <Alberth> already? the year barely started :p 19:50:15 <V453000> :P 19:52:13 <Rubidium> happy 2013 frosch123 ;) 19:52:18 <Rubidium> good luck catching up 19:52:37 <Rubidium> reviewing all those translation updates that have passed must be a lot of work ;) 19:55:46 <frosch123> yeah, i managed to finish that part before i started irc :) 20:03:53 *** ntoskrnl has quit IRC 21:42:22 *** Alberth has left #openttd.dev 21:55:22 <Rubidium> frosch123: did you look at my patch? "People" thought it was nice to randomise power in the randomisation trigger 21:57:22 <frosch123> yes, i saw it 21:57:44 <frosch123> for now it surprised me that MarkDirty would invalidate such caches 21:58:49 <Rubidium> the documentation of the method says it updates caches 22:00:29 <Rubidium> was kinda surprised myself as well 22:02:37 <frosch123> the function should likely be renamed... but it is not called in places like Sign::MarkDirty and similar, so it is no perfomance issue than i first thought of it 22:04:52 <frosch123> anyway, diff looks fine to me 22:05:07 <frosch123> but if V453000 wants to change power depending on date, we won't have a fix :p 22:07:39 <V453000> I would prefer it to be "controllable" :P 22:09:28 <frosch123> V453000: people change livery depending on current date, service date or purchase date, but since you are ignoring a core balance feature of the game, you would likely not use the service date; and most likely you would also change vehicle stats 22:10:32 <V453000> I just want to randomize power when trains visit station or depot :) 22:13:49 <V453000> if possible .. :) 22:19:15 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24882 || 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:19:31 <Rubidium> frosch123: if you want to change power, you should do it in the 32 day trigger ;) 22:38:13 <V453000> gnight 23:10:02 <michi_cc> frosch123: Regarding your post in the road types thread: I believe most issues can be solved by carefully handling the compatible/powered bitmasks with separate road-like and tram-like types. Road types only have a surface and thus only contribute to the set of compatible types on the tile. Tram types can have both a surface and a power source, so they provide both compatible and powered bits. 23:11:27 <michi_cc> A vehicle for a certain road/tram type can drive on anything that is compatible with the road/tram type. Additionally, they also need a compatible power type (or none for self-powered vehicles). 23:11:37 <frosch123> well, i also have a problem with "connections" of different roadtypes :) 23:11:58 <frosch123> like a mud road branching off from a concrete road 23:12:06 <frosch123> similar like catenary/non-catenary rail :) 23:12:12 <michi_cc> The only real problem not touched by compatible/powered is how to handle crossings. 23:12:27 <frosch123> also, i wonder whether there should be exactly one road- and exactly one tram type per tile 23:12:37 <frosch123> or whether there may also be two road or two tram 23:12:56 <michi_cc> Drawing problems are mostly avoided by only allowing a single catenary per tile. 23:13:11 <michi_cc> No, one road, one tram. Everything else becomes much too messy. 23:13:43 <frosch123> yeah, likely :) 23:14:08 <frosch123> but i guess the use-case "trolley-bus" is quite popular 23:14:53 <michi_cc> So, ROAD might say it is compatible with HWAY. DIRT might be compatible with both ROAD and HWAY. So DIRT vehicles can drive everywhere, ROAD vehicles only on ROAD or better. Both would declare none for power type. 23:16:00 <michi_cc> For a trolley-bus, it would be a ROAD vehicle (compatible with HWAY). It would additionally need a power compatible with OBUS, which would be a tram-like type that provides only a catenary. 23:17:31 <michi_cc> Electrified tram might have a different, non-compatible power type. To allow both trolley and tram you'd have a second tram type with some special catenary that as TRAM as compatible, and both TRAM and OBUS for powered. 23:20:07 <frosch123> i am not sure whether all DIRT vehicles should be able to drive on HWAY :) 23:20:37 <frosch123> road types have maximum and minimum speed or something ilke that :p 23:21:08 <michi_cc> Put more formally: A road tile would have as compatible types [road-like type, tram-like type] + everything those two types declare as compatible (in my example e.g. [ROAD, HWAY, TRAM]). It would also have powered types, but just from the tram-type + whatever other types it declares as powered (it might make sense to add powered to the road type as well, but it couldn't have special graphics then). 23:21:18 <frosch123> also HWAY might want to reject any tram type 23:21:53 <michi_cc> A road/tram vehicle would have a *two* road types, one for compatible, one for powered. 23:22:36 <frosch123> would you also have to build trolley-tracks in two steps then? 23:22:42 <frosch123> first the road, then the catenary? 23:23:30 <michi_cc> You could add a "road type to build if none present" property to tram types. 23:24:50 <frosch123> sounds complicated :) 23:26:50 <michi_cc> For crossings of different types I'd simply say that OTTD tries to find a road type and a tram type (if applicable) that together are compatible and powered to both crossed types. If no such type exists (e.g. crossing of TRAM and OBUS, but no dual-catenary type defined), simply fail with an error. 23:27:49 *** Sturmi has quit IRC 23:28:29 <frosch123> yeah, that might work 23:34:46 <michi_cc> To retain current behaviour, you'd check the owner of the tram type but not the road type (i.e. consider only the road type for wrong owner). There could be a flag to change that, but it might be used for abuse (or at least irritation of other players). 23:38:10 <michi_cc> Completely unrelated question: NewGRF can read the animation frame (where present) at any time, right? But is there a way (or a feature) where writing is possible without setting any kind of misc flag, CB flag or other property? 23:44:06 <frosch123> frames are either changed by the animation callbacks, or by build-in animation (which loops the frame in a fixed interval) 23:44:24 <frosch123> i am not sure whether all animation callbacks have a flag to enable them 23:46:30 <frosch123> likely they all have some flag 23:46:56 <frosch123> also, they need to register animated tiles (AddAnimatedTile) if they want non-glitchy animation 23:58:34 <michi_cc> So in theory without an animation callback (or the build-in stuff), the animation frame will always read out as the default value (0 I guess).