Config
Log for #openttd.dev on 2nd January 2013:
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).

Powered by YARRSTE version: svn-trunk