IRC logs for #openttd on OFTC at 2009-10-20
⏴ go to previous day
00:15:42 *** KenjiE20 has joined #openttd
00:39:31 *** Peter is now known as PeterT
00:41:37 *** KenjiE20|LT has joined #openttd
01:42:46 *** lobster has joined #openttd
03:11:29 *** De_Ghosty has joined #openttd
03:57:33 *** thepalm has joined #openttd
04:00:02 <George> Can't update a GRF at bananas - "Unexpected error while uploading."
04:19:43 *** George3 has joined #openttd
04:22:31 *** George34 has joined #openttd
04:23:09 *** zachanima has joined #openttd
04:44:23 *** George3 has joined #openttd
05:17:44 *** boekabart has joined #openttd
05:40:36 *** lobster has joined #openttd
05:57:13 <Rhamphoryncus> Any tricks to get trucks to spread between stations? I've currently got a 3x3, but they prefer to build a giant backlog for 1
05:57:33 <Rhamphoryncus> Particularly bad if they're all unloading and the front vehicle is loading
05:59:29 <Rhamphoryncus> and they always refuse to pass each other..
06:08:17 <boekabart> screenshot to 'explain' ?
06:09:43 <Forked> |_|_|_| <- three truck stops. They only use one of them (if I understood the question correct)
06:09:54 <Forked> Rhamphoryncus: maybe seperate load and unload with waypoint?
06:10:40 <Rhamphoryncus> I don't seem to have waypoints for trucks
06:11:10 <Forked> hm, I haven't played in some months.. you might be right there
06:11:17 <Rhamphoryncus> I actually have a 3x3 block, supposedly to handle the load. Occasionally they'll use the 2nd or 3rd, but they vastly prefer the 1st
06:13:20 *** Cybertinus has joined #openttd
06:59:02 <Rhamphoryncus> heh another station managed to deadlock itself. 4 goods trucks all waiting to load, with grain, livestock, and steel waiting behind them
06:59:17 <boekabart> Rhamphoryncus: could it be that the 3x3 f's it up?
06:59:39 *** Polygon has joined #openttd
07:00:28 <boekabart> and eh, have you heard of Shared Orders?
07:00:46 <boekabart> multiple vehicles can share the same order, saves you a LOT of work
07:06:29 <Rhamphoryncus> most of those are shared
07:07:54 <Rhamphoryncus> Might be an orientation thing. I've turned it all and they're not doing it
07:20:36 <Rhamphoryncus> Not really my bug, but it'd be nice if they had a penalty for waiting behind someone who's loading something different from you
07:21:10 <planetmaker> [08:10] <Rhamphoryncus> I don't seem to have waypoints for trucks <-- you do: just another, separate station with "go via" orders in the vehicles' orders
07:36:25 <Forked> can also have seperate stations for loading and unloading
07:39:15 <boekabart> indeed: penalty is no deadlock-proof
07:39:27 <boekabart> it might just make it improbable
07:39:39 <boekabart> but also very inpredictable
07:42:21 *** fonsinchen has joined #openttd
07:51:13 *** Terkhen has joined #openttd
07:52:38 <Rhamphoryncus> Forked: pretty hard to do. It'd be easier to have entirely separate road networks to the same station
07:54:21 <Rhamphoryncus> boekabart: depends. If you have as many queues as load types, long enough in each queue for all the vehicles of that type, and it consistently picks the right queue, I don't see a problem
08:01:14 *** welshdragon has joined #openttd
08:04:47 <dihedral> hehe - rv's? use go via dtrs
08:05:01 <dihedral> then you can force a queue
08:20:34 <welshdragon> can somebody throw Nekomaster a dictionary?
08:23:47 *** Terkhen has joined #openttd
08:27:08 <boekabart> welshdragon: and that's not all that can be said about him
08:29:25 <dihedral> welshdragon, you complain about his spelling??
08:29:38 <dihedral> you have so many international people there
08:29:47 <dihedral> look at alains posts :-P
08:29:59 <dihedral> and consider again if the e in custom is such an issue :-P
08:30:14 <welshdragon> Alain's is appaling!
08:32:39 *** DaleStan_ has joined #openttd
08:32:39 <boekabart> i was more referring to his .. inability to follow a frikkin tutorial...
08:32:40 *** DaleStan is now known as Guest1699
08:32:40 *** DaleStan_ is now known as DaleStan
08:46:50 <dihedral> boekabart, that matches close to 80% of tt-forum users (if not more!)
08:53:30 *** TrainzStoffe has joined #openttd
08:56:52 *** kleinie has joined #openttd
09:15:37 *** TrainzStoffe has joined #openttd
09:17:50 *** TrainzStoffe is now known as Stoffe
09:21:01 *** boekabart has left #openttd
09:24:13 *** TrainzStoffe has joined #openttd
09:41:04 *** TrainzStoffe has joined #openttd
09:47:00 *** TrainzStoffe is now known as Stoffe
09:48:46 *** boekabart has joined #openttd
10:09:10 *** Belugas has joined #openttd
10:09:11 *** ChanServ sets mode: +o Belugas
10:18:29 *** oskari89 has joined #openttd
10:31:43 *** Chris_Booth has joined #openttd
10:49:13 <Rubidium> so Sacro got his package a few days too early?
10:52:45 <boekabart> Rubidium: sorry , third time: did you get my remark about the MakeWater() fn name? (that it should be called MakeSea(), just like the Is-fn is called IsSea()
10:53:25 *** TrainzStoffe has joined #openttd
10:53:59 <boekabart> it should not really or you didn't really get it :)
10:54:14 <boekabart> (get as in: receive)
10:54:23 <Rubidium> didn't get it; I saw it but forgot about it again
10:54:23 <boekabart> (or get as in: understand)
10:55:04 <boekabart> ok then. So the idea is that you have IsCanal IsSea and IsRiver, but MakeCanal, MakeRiver and MakeWater
10:55:26 <boekabart> (where MakeWater doesn't do smth generic, just makes the tile Sea)
10:58:31 *** TrainzStoffe is now known as Stoffe
10:58:34 <Sacro> welshdragon: alain's *are* appaling
10:58:44 <Rubidium> Sacro: your Windows 7 installation CD
10:59:21 <Sacro> no no, i'm a CS student, MSDNAA access
10:59:27 <Sacro> had it for months just never got around to it
11:00:06 <Sacro> nice having it for free
11:00:16 <Sacro> shame we don't get office :(
11:00:59 <Rubidium> students ought not to use office but VCS+latex!
11:01:14 <boekabart> aren't most students eligible to purchase office for like 10 euros through most universities?
11:01:45 <boekabart> Rubidium: I'm trying to tell my (student) wife that, but she refuses....
11:02:25 <TrueBrain> VCS === Version Control System
11:03:10 <boekabart> or maybe Rb was referring to Visual C-Sharp?
11:03:21 <TrueBrain> hahahahahahahahahahahahaha
11:04:06 <Rubidium> first of all, I'd never call it C-Sharp, but C-Hash
11:04:20 <boekabart> Rubidium: that's because you're not a musician
11:04:32 *** Chillosophy has joined #openttd
11:04:36 <Rubidium> no, because it's a hash of crap
11:04:50 * boekabart feels a flamewar coming!!!
11:05:12 <TrueBrain> a ware requires someone saying it isn't a hash of crap
11:05:16 <Rubidium> let me tell you that the last time I used it I've used some APIs that aren't quite .NET-ish
11:05:26 <boekabart> Sacro just did that
11:05:41 <TrueBrain> he just said he likes a hash of crap
11:05:48 <Rubidium> boekabart: no, Sacro said he loved it
11:06:05 <Rubidium> you can still love something that is crap, e.g. DSB
11:06:24 <boekabart> Rubidium said you COULD
11:06:31 <boekabart> not that he does (did)
11:06:37 <TrueBrain> so I am asking if he does :)
11:06:44 <boekabart> but one doesn't speak ill of the dead
11:06:59 <TrueBrain> well, DSB Beheer isn't dead (yet) :p
11:07:04 <Rubidium> the soap is so much better than ATWT, GTST, ONM, TBATB, ...
11:07:30 <boekabart> Rubidium: you know them all?
11:08:27 <Rubidium> boekabart: know is maybe a bit 'too much', but ... sometimes there're commercials on discovery (and I don't have commercial free discovery science anymore)
11:09:07 <boekabart> pf, I haven't had cable in 2 years, haven't missed it a day
11:09:37 <boekabart> ... good thing Sesame Street and Tele Tubbies are on FTA dvb-t ;)
11:22:05 *** TrainzStoffe has joined #openttd
11:27:42 *** TrainzStoffe is now known as Stoffe
11:33:41 *** TrainzStoffe has joined #openttd
11:35:53 *** Biolunar has joined #openttd
11:40:38 *** TrainzStoffe is now known as Stoffe
12:14:19 *** KenjiE20 has joined #openttd
12:17:49 *** andythenorth has joined #openttd
12:21:16 <CIA-9> OpenTTD: rubidium * r17816 /trunk/src/ (5 files in 2 dirs):
12:21:16 <CIA-9> OpenTTD: -Codechange: move the CargoList invalidation-after-saveload to the function that
12:21:16 <CIA-9> OpenTTD: handles the CargoPackets instead of spreading it around over the saveload files.
12:21:16 <CIA-9> OpenTTD: Also add some code to validate whether the caches are valid; to be removed later
12:21:16 <CIA-9> OpenTTD: when no problems turn up
12:21:34 *** thingwath has joined #openttd
12:21:49 <andythenorth> my eyes are bleeding
12:22:01 <andythenorth> would anyone like to go in my FIRS thread and talk to Neko?
12:22:40 <boekabart> You mean ForumId|26|ThreadId|41607 ?
12:23:07 <andythenorth> I just click read the words, click on the links....
12:24:13 <boekabart> :) hm. He suggests a game that's impossible to start
12:24:52 <andythenorth> horrible-gridlock mode
12:25:04 <andythenorth> He's arguing against a straw man
12:25:30 <andythenorth> FIRS does what he thinks 'easy mode' is, only the delivered cargo is actually useful
12:25:37 <andythenorth> Hard mode is non-existent
12:25:52 <andythenorth> I have a soft spot for Neko, I don't want to slap him down again
12:26:02 <andythenorth> He's so.....enthusiastic
12:31:23 <CIA-9> OpenTTD: rubidium * r17817 /trunk/src/ (saveload/afterload.cpp water_cmd.cpp water_map.h): -Codechange: MakeWater actually made sea tiles, so rename it to MakeSea and unduplicate the code to make sea, rivers and canals.
12:34:54 *** Doorslammer has joined #openttd
12:46:07 *** TrainzStoffe has joined #openttd
12:49:30 *** thingwath has joined #openttd
12:53:33 *** TrainzStoffe is now known as Stoffe
13:15:11 <Eddi|zuHause> winter semester...
13:15:53 *** andythenorth has joined #openttd
13:15:58 <Forked> cows in the sky with diamonds..
13:18:43 <Eddi|zuHause> ... i was referencing a joke... "after waking up, one student asks the other: 'what time is it?' - 'thursday.' - 'i didn't need it that specific, it would have sufficed to say summer or winter semester.'"
13:37:30 *** Coco-Banana-Man has joined #openttd
13:37:53 *** fonsinchen has joined #openttd
13:44:17 *** andythenorth has joined #openttd
13:51:02 *** welshdragon has joined #openttd
13:57:35 *** TheMask96 has joined #openttd
14:00:20 <Rubidium> got to 'love' profiling :(
14:01:27 <Rubidium> especially when the results are odd
14:02:54 <Rubidium> okay, profiling results can be binned again
14:06:49 *** lewymati has joined #openttd
14:08:28 *** Progman has joined #openttd
14:12:43 <fonsinchen> Profiling the cargo loading without lots of transfers is rather pointless IMO.
14:13:32 <fonsinchen> Because most stations only have 1 packet then.
14:13:53 <Rubidium> append is 11% faster, moveto (including calls to Append, excluding allocs) 7% slower
14:13:53 <fonsinchen> PS154 still isn't as extreme as the average cargodist game.
14:14:23 <fonsinchen> which configuration compared to which?
14:14:32 *** George34 has joined #openttd
14:14:49 <Rubidium> overall sets are 15 seconds slower over ~3 minutes (7% slower)
14:15:06 <Rubidium> current trunk vs trunk with your patch (kinda reworked) applied
14:15:59 <Rubidium> fonsinchen, anyhow the question is: should trunk get 7% slower for something it does not need (yet)?
14:16:13 <fonsinchen> did you follow the proposal of appending only to the last packet in stations?
14:16:39 <Rubidium> I copied your append functions verbatim
14:17:05 <fonsinchen> That's strange. I'll have to recheck that myself.
14:18:52 <Rubidium> I'm going to fiddle a bit seeing whether I can improve some things (at cost of compile time)
14:19:16 <Rubidium> I reckon the results could be better *if* gcc had working link-time-optimisation
14:19:37 <fonsinchen> Maybe it's some interaction with the reservation lists or the sorting by next hop.
14:21:05 *** Dred_furst has joined #openttd
14:22:03 <fonsinchen> are you using x86 or amd64?
14:23:07 <boekabart> can I help by profiling on win32 (msvc)?
14:26:24 *** Lofwyr is now known as Dr_Jekyll
14:27:37 <Rubidium> maybe I ought to test without asserts too
14:36:31 *** deghosty has joined #openttd
14:36:48 <Rubidium> with sets and the lot: ~10% more appends and 10% more allocs
14:37:45 <Rubidium> without asserts: Append 15% faster, MoveTo 15% slower (incl. calls to Append); caused by the extra packets maybe?
14:39:35 *** Grelouk has joined #openttd
14:42:43 <fonsinchen> I don't quite get yet why the extra packets are a speed problem. They should be a memory problem at most. But I'll have a look at it tonight.
14:44:32 <fonsinchen> ah, I think I know it. With cargodist the number of packets is already higher because of the different destinations. There just aren't as many merging opportunities in stations.
14:44:52 <fonsinchen> This means more packets have to be loaded to get the same amount of cargo onto a vehicle
14:45:27 *** Grelouk_ has joined #openttd
14:46:01 <fonsinchen> The merging only at the end probably doesn't add much to that kind of fragmentation while it significantly increases the fragmentation in trunk.
14:46:14 <fonsinchen> I should check that.
14:48:20 <Rubidium> 'reverting' the station merging reduces the number of extra Append calls drastically, yet the average time spent in Append is now up 20% instead of down 15%
14:50:14 <Rubidium> which basically implies that not (or only with the last) is incredibly cheap
14:50:27 <fonsinchen> How can the average time spent in Append increase if Append is the same as before and the number of calls to Append has decreased?
14:50:30 <Rubidium> whereas keeping a sorted set is relatively expensive
14:51:31 <Rubidium> fonsinchen: stationmerging 'as in trunk' + vehiclemerging 'as with set' != merging 'as in trunk'
14:51:51 <fonsinchen> So that's both Appends added up. OK
14:52:44 <Eddi|zuHause> does it matter that much if packets in the vehicle (which are usually far less than at stations) are merged upon loading?
14:55:04 <Rubidium> well, AgeCargo iterates over them every so many ticks
14:55:22 <Rubidium> so that may be something to consider
14:56:13 <Rubidium> although fonsinchen's strategy for only checking the last packet might pay off with vehicle loading
14:57:00 <Rubidium> could reduce (half?) the packet splits/merges
14:57:19 <Rubidium> but it's a memory vs cpu thing
14:58:39 *** StarLionIsaac has joined #openttd
14:58:40 <Eddi|zuHause> i think memory is usually less of an issue
14:59:04 <Eddi|zuHause> so i'd favour the memory version over the cpu version
15:04:02 <Eddi|zuHause> i don't understand it either
15:04:33 <StarLionIsaac> That was my bad wording of it, and mistaking what was said
15:04:52 <StarLionIsaac> Apologies over that, I haven't had a cuppa yet today, I'm still not working in a straight line
15:07:51 <fonsinchen> What about using only-last Append on stations and classic Append with list on vehicles. It might be that the set was indeed detrimental all the time as I have only checked set Append on vehicles and only-last Append on stations combined.
15:09:13 <Eddi|zuHause> anyway, i can see how you "love" profiling that :p
15:11:53 <Rubidium> okay: only-last for only vehicles: 6% improvement overall for append and 6% improvement for MoveTo (excl. allocating); number of Append/Alloc calls are the same (I only count per 1000, so it can be a few hundred off, which is still less than 2%)
15:13:56 <fonsinchen> Another idea: We could search the list from back to front for classic Append. This way it will find mergable packets faster if it unloads multiple equal packets in a row. Also it's better in line with the FIFO principle.
15:16:13 <Rubidium> both using 'only merge last': 29% improvement for Append, but 5% more calls (so in effect 25% improvement). For some reason the allocs were 20% more expensive, but only 2% more allocs. MoveTo is 16% faster without allocs, but with Append
15:16:56 <fonsinchen> So, that's with only-last for both vehicles and stations?
15:17:25 *** zachanima has joined #openttd
15:17:29 <fonsinchen> so only-last has a greater effect on stations than on vehicles.
15:17:55 <fonsinchen> I suspect only-last for stations and reverse-classic for vehicles is best if you consider AgeCargo
15:18:07 <Rubidium> in effect for MoveTo performance both "merge last for both" and "merge last for vehicles" are equally fast; assuming Append doesn't get called
15:18:48 <Rubidium> otherwise it's 3% for vehicle last merge and 5% for both last merge
15:19:28 <Rubidium> ah, good point to check agecargo too
15:19:35 <fonsinchen> I don't get it. Where did you get the 25% then?
15:20:50 <fonsinchen> AgeCargo for same number of packets is cheaper with lists than with sets. It doesn't have to create a tmp set.
15:21:25 *** boekabart has left #openttd
15:22:56 <Rubidium> if Append gets 25% cheaper, but MoveTo gets more expensive (more packets) then overall it'll become less than 25% cheaper
15:24:30 <fonsinchen> but reverse-classic merging in vehicles should reduce the number of packets compared to only-last merging ...
15:25:53 <fonsinchen> at the same time of course increasing the time for Append, but each vehicle generally has fewer packets than a station.
15:26:45 *** TheMask96 has joined #openttd
15:29:28 *** TrainzStoffe has joined #openttd
15:31:10 <Rubidium> with all last-merge AgeCargo gets 10% more expensive; as it makes up ~40% of sum(MoveTo, Append, Alloc, AgeCargo) that's quite considerable
15:31:48 *** HerzogDeXtEr has joined #openttd
15:38:50 <Rubidium> full merge in vehicles and only last merge in stations -> 8% slower AgeCargo
15:39:00 <Rubidium> last merge for all -> 10% slower AgeCargo
15:39:42 <Rubidium> for both overal a 3% slowdown
15:42:21 <Rubidium> though I can imagine that when there's nothing to merge at all that last merge is quicker
15:45:38 <Rubidium> now... full merge for both, but searching from the back
15:45:47 <Rubidium> got to love reverse_iterator :)
15:46:27 <fonsinchen> how can AgeCargo be slower if we do a full merge in vehicles?
15:47:57 <fonsinchen> is that full merge with set? Then it's clear
15:48:06 <Rubidium> no merging at station -> more small (different source) packets at the station -> packets of more sources loaded into the vehicle
15:50:45 <Rubidium> with reverse_iterator: ~5% improvement overall; 10% improvement of MoveTo/Append
15:51:58 <Rubidium> no difference, besides random variation on AgeCargo
15:52:13 <fonsinchen> Of course not, the result is the same ...
15:55:29 <fonsinchen> is that reverse merging for both or only for stations?
15:55:42 <fonsinchen> ah, you already said. Sorry
15:57:09 *** worldemar has joined #openttd
16:00:44 *** Rhamphoryncus has joined #openttd
16:07:40 *** TrainzStoffe has joined #openttd
16:12:01 <Rubidium> vehicle set + station last merge: 5 times slower age cargo (400%), 42% slower Append, 20% slower MoveTo (incl. Append)
16:13:21 <fonsinchen> That's indeed very strange. I'm just trying to reproduce that 2.5 vs 4 seconds thing I reported in the thread.
16:13:26 <Rubidium> reverse iterator: 10% faster Append, 5% faster MoveTo (incl. Append)
16:15:18 *** TrainzStoffe is now known as Stoffe
16:19:11 *** TrainzStoffe has joined #openttd
16:21:11 <Eddi|zuHause> so... reverse iterator is faster because ...?
16:21:29 <Eddi|zuHause> it is more likely that the last packet is the one being joined to?
16:21:36 <fonsinchen> it's likely that several similar packets are generated/unloaded in a row
16:21:45 <Eddi|zuHause> how about using move-to-front instead?
16:22:33 <Rubidium> basically if it gets loaded in a vehicle a packet gets split over all vehicles, later those vehicles are unloaded in (usually) the same order they were loaded
16:22:34 <Eddi|zuHause> i.e. if a packet is being joined to, move that to the front of the list, so if it is being joined again, it'll be the first one to be checked?
16:23:02 <Rubidium> that makes it (way) less fifo
16:23:42 <Eddi|zuHause> hm, yeah, i see how that might be an issue
16:25:58 *** TrainzStoffe is now known as Stoffe
16:28:18 <Rubidium> Stoffe: could you please acquire a more stable internet connection?
16:35:27 *** |Jeroen| has joined #openttd
16:36:47 <CIA-9> OpenTTD: rubidium * r17818 /trunk/src/cargopacket.cpp:
16:36:47 <CIA-9> OpenTTD: -Codechange: iterate the cargo list from the back when trying to merge packets.
16:36:47 <CIA-9> OpenTTD: Chances are higher that the last packet (in the FIFO-ish queue) is mergeable
16:36:47 <CIA-9> OpenTTD: with the to be added package. If a train gets loaded packets get split up and
16:36:47 <CIA-9> OpenTTD: put into the different carriages, at unload they are unloaded in the same order
16:36:49 <CIA-9> OpenTTD: so the last in the FIFO-ish queue is likely the packet it can merge with.
16:36:49 <CIA-9> OpenTTD: This results in a 5-10% performance improvement of CargoList's Append/MoveTo without performance degradation of AgeCargo.
16:41:32 *** ChanServ sets mode: +v tokai
16:44:11 *** frosch123 has joined #openttd
16:49:13 <Sacro> anyone here have any knowledge of Silicon Graphics Indys?
17:00:06 <fonsinchen> so, some results with cargodist: 30 days of PSG 154 wall clock:
17:00:27 <fonsinchen> vehicle: set, station: only-last - 2:45
17:00:42 <fonsinchen> vehicle: reverse, station: only-last - 2:50
17:01:00 <fonsinchen> vehicle: set, station: reverse - 2:45
17:01:11 <fonsinchen> vehicle: reverse, station: reverse - 2:47
17:02:13 <fonsinchen> Mind that reverse means reverse on the subset of packets with the same next hop.
17:03:45 *** TheMask96 has joined #openttd
17:05:11 <Rubidium> so it's heavily cargodist related
17:05:33 <Rubidium> could you try with -vnull:ticks=10000 ?
17:06:37 *** welshdragon is now known as Guest1734
17:06:38 *** welshdragon has joined #openttd
17:20:14 <DorpsGek> fonsinchen: 135.135135135
17:20:46 <fonsinchen> bah, this will take more than 10 minutes for each run
17:24:43 <Eddi|zuHause> where do you get the 74 from?
17:25:21 <fonsinchen> 74 ticks are a game day
17:25:43 <Eddi|zuHause> and what relevance does that have?
17:25:51 <fonsinchen> this means these are 135 days and for 30 days it took a little less than 3 minutes
17:26:15 <fonsinchen> probably more like 12 to 15 minutes then
17:26:31 *** ChanServ sets mode: +v tokai
17:27:39 <Eddi|zuHause> @calc (2+5/6)*3.5
17:27:39 <DorpsGek> Eddi|zuHause: 9.91666666667
17:28:07 <Eddi|zuHause> @calc (2+5/6)*4.5
17:28:16 <Eddi|zuHause> i shouldn't calculate stuff in my head :p
17:33:40 *** Alberth has joined #openttd
17:35:45 * Rhamphoryncus wonders why 74 would be chosen, rather than 72 or the like
17:36:19 <CIA-9> OpenTTD: smatz * r17819 /trunk/src/smallmap_gui.cpp: -Codechange: replace magic constant by symbolic constant
17:38:31 <Rubidium> Rhamphoryncus: 27*74 is ~2 seconds and 0x357 x 74 is ~65536 ?
17:38:42 <Rubidium> fonsinchen: does it take that long for you?
17:39:09 <Rubidium> it takes ~2.5 minutes for me
17:39:11 <fonsinchen> ah, shit, I compiled with debug=3
17:39:17 <Rubidium> you've disabled assertions too?
17:39:24 <Rubidium> ./configure --disable-assert
17:39:29 *** th1ngwath has joined #openttd
17:45:27 <CIA-9> OpenTTD: translators * r17820 /trunk/src/lang/ (indonesian.txt traditional_chinese.txt):
17:45:27 <CIA-9> OpenTTD: -Update from WebTranslator v3.0:
17:45:27 <CIA-9> OpenTTD: traditional_chinese - 6 changes by josesun
17:45:27 <CIA-9> OpenTTD: indonesian - 1 changes by prof
17:51:51 *** b_jonas has joined #openttd
18:03:39 <fonsinchen> vehicle:set, station:only-last - 2:33
18:03:39 <fonsinchen> vehicle:reverse, station:only-last - 2:35
18:03:39 <fonsinchen> vehicle:set, station:reverse - 2:31
18:03:39 <fonsinchen> vehicle:reverse, station:reverse - 2:32
18:04:08 <fonsinchen> with disable-assert and without debug
18:04:39 *** TrueBrain has joined #openttd
18:07:00 <fonsinchen> so, for vehicles reverse is almost equally as good as set on PSG 154
18:08:23 <fonsinchen> reverse is better than only-last and both effects are not as interdependent as thought. But maybe there is random variation at work.
18:15:59 <CIA-9> OpenTTD: smatz * r17821 /trunk/src/smallmap_gui.cpp: -Codechange: make more mathods of SmallMapWindow private
18:33:03 *** Grelouk has joined #openttd
18:38:53 <CIA-9> OpenTTD: smatz * r17822 /trunk/ (5 files in 3 dirs): -Codechange: move 'extra viewport' code from smallmap_gui.cpp to viewport_gui.cpp
18:39:59 <CIA-9> OpenTTD: alberth * r17823 /trunk/src/autoreplace_gui.cpp: -Codechange: Use top of the matrix widget as offset for row calculation in autoreplace window.
19:03:45 <Rhamphoryncus> Rubidium: where do 27 and 0x357 come from?
19:05:40 <frosch123> 0x357 is rougly 1/74 in fixed point notation with 16 fractional bits
19:10:58 <Rhamphoryncus> floor(65535 / 74) = 0x375
19:12:52 <Rhamphoryncus> If that was a typo and 0x375 was meant then that'd explain that constant. That just leaves 27
19:14:19 *** HerzogDeXtEr1 has joined #openttd
19:15:28 <Eddi|zuHause> i presume these numbers are completely made up on the spot, and 74 was a constant inherited from the original game...
19:17:49 <frosch123> if you reverse that sentence you might get quite close
19:18:40 <Rhamphoryncus> yeah, we have them now because they're inherited
19:20:09 <Belugas> 74 sounds like ticks per day
19:23:14 <Rhamphoryncus> Belugas: scroll up. It is ticks per day. My question was why that particular value was chosen for ticks per day, rather than something like 72
19:24:21 <Alberth> No doubt CS came, saw, and concluded that 74 was the best number to represent a day.
19:24:40 <Rhamphoryncus> 74 has the prime factors 2x37. 72 has the prime factors 2x2x2x3x3
19:30:19 <Eddi|zuHause> maybe he chose it because it _doesn't_ have that many prime factors
19:30:56 <Eddi|zuHause> you can go and ask him himself, i'm sure you can find contact addresses around the forum
19:31:03 <CIA-9> OpenTTD: frosch * r17824 /trunk/src/newgrf.cpp: -Fix (r4594): _date_fract runs from 0 to 73 since r2041. Variable 0x09 should not.
19:31:15 <frosch123> thanks Rhamphoryncus :)
19:32:05 <Eddi|zuHause> nobody noticed in 13000 revisions :p
19:32:24 <DorpsGek> frosch123: Commit by peter1138 :: r4594 /trunk (newgrf_spritegroup.c newgrf_spritegroup.h) (2006-04-27 19:53:58 UTC)
19:32:25 <DorpsGek> frosch123: - NewGRF: introduce the basic sprite group resolver. This code isn't used yet.
19:33:04 <frosch123> likely noone uses it anyway
19:36:16 *** Nite_Owl has joined #openttd
19:37:45 <Belugas> Why does it matter if it's 72 or 74? it's a number anyway...
19:38:11 <Alberth> perhaps 73 was not that bad :p
19:39:03 <CIA-9> OpenTTD: smatz * r17825 /trunk/src/smallmap_gui.cpp: -Change: 'animate' the 'center to current position' button in SmallMapWindow when pressed
19:47:51 <Eddi|zuHause> maybe 73 was a bit too primey ;)
19:51:40 <Nite_Owl> or when added together they become tenuous at best
19:55:21 <CIA-9> OpenTTD: frosch * r17826 /trunk/src/ (roadveh.h roadveh_cmd.cpp): -Codechange: GetRoadVehLength() is only used in one file, make it static.
19:56:03 <Nite_Owl> I am sorry - I thought this was #badpuns
19:57:59 <Rhamphoryncus> Nite_Owl: don't worry, the worst we'll do to you is have you drawn and quartered
19:58:39 <Eddi|zuHause> Nite_Owl: honestly, i don't get it...
19:59:45 <Nite_Owl> 7+3=10 or is tenuous
20:00:14 <Rubidium> but... 07 + 03 != 010
20:02:08 <CIA-9> OpenTTD: frosch * r17827 /trunk/src/roadveh_cmd.cpp: -Codechange: Deduplicate some lines of code.
20:03:16 <Nite_Owl> it might loose something in translation
20:04:12 <Nite_Owl> it is difficult to play to an international audience
20:06:28 *** andythenorth has joined #openttd
20:06:38 <CIA-9> OpenTTD: alberth * r17828 /trunk/src/industry_gui.cpp: -Codechange: Variable declaration code style, and a few comment typo-ish fixes.
20:19:42 <TrueBrain> awh, your son learns to type? :)
20:21:08 *** andythenorth has joined #openttd
20:22:04 <Eddi|zuHause> # nur der Mann im Mond schaut zu
20:23:36 <frosch123> TrueBrain: he will shortly catch up
20:24:29 <Eddi|zuHause> soon he'll have more commits than Belugas ;)
20:26:22 <Belugas> i hope he'll keep his sanity...
20:26:30 <Belugas> i still have not found mine yet...
20:31:45 *** andythenorth has joined #openttd
20:41:23 <Eddi|zuHause> i wonder why i heard so much about it, but never actually saw this movie
20:43:59 <Nite_Owl> it is not a great film but that end scene is very spooky in context
20:47:23 <Aixx_> am i missing something or?
20:48:08 <Eddi|zuHause> well, obviously you are missing the files it lists there, check the readme for details
20:48:40 <Eddi|zuHause> or you use a .cfg with incorrect settings
20:49:12 <Aixx> i dont think i'm using invalid cfg or something :P
20:49:15 <Eddi|zuHause> and why does it have to be black text on dark blue background?
20:49:35 <Aixx> cuz i'm on mates computer and he likes ugly win themes..
20:53:08 <Aixx> those third-party files are located in "data" ?
20:53:25 *** boekabart has joined #openttd
20:53:52 *** boekabart has left #openttd
20:55:26 <Aixx> and where shoult i put them?
20:57:05 <Aixx> okay, got those. where can i get sample.cat ?
20:57:43 <CIA-9> OpenTTD: smatz * r17829 /trunk/src/smallmap_gui.cpp: -Codechange: move code used for adding vehicles and town names to minimap to separate functions
20:57:45 <Eddi|zuHause> where you got the other files?
21:00:23 *** andythenorth has joined #openttd
21:01:23 * Rubidium really wonders how hard reading can be
21:03:58 *** Luukland has joined #openttd
21:04:32 <DorpsGek> Muxy: I have not seen xi.
21:04:40 <DorpsGek> Muxy: luukland was last seen in #openttd 4 days, 2 hours, 45 minutes, and 43 seconds ago: <Luukland> Anyways, thx for the answer, pls next time hold the sarcasm Belugas, dont be such an ass to ppl who just ask normal questions
21:05:23 <Belugas> that was nasty... i was not even the smallest sarcastic!
21:06:05 <Muxy> hi Belugas, nobody blames you.
21:11:26 <Belugas> but it seems that i can be sarcastic when i am not conscious of it :S
21:25:37 <CIA-9> OpenTTD: frosch * r17830 /trunk/src/ (autoreplace_gui.cpp depot_gui.cpp window.cpp): -Fix [FS#3276]: Some windows already need their window_number when setting up smallest size (e.g. for DParams). So assign it earlier in Window::InitializeData instead of dealing with each window separately.
21:27:08 <CIA-9> OpenTTD: smatz * r17831 /trunk/src/smallmap_gui.cpp: -Codechange: move code used for adding map indicators of the smallmap to separate functions
21:27:56 <CIA-9> OpenTTD: smatz * r17832 /trunk/src/smallmap_gui.cpp: -Codechange: make Alberth happier
21:31:24 <zachanima> OpenTTD: kanye * r17833 /trunk/src/video.cpp I'm gonna let you finish, but Beyonce has one of the best commits of all time
21:32:28 *** Digitalfox has joined #openttd
21:39:59 *** welshdragon has joined #openttd
21:41:57 <CIA-9> OpenTTD: alberth * r17833 /trunk/src/depot_gui.cpp: -Codechange: Depot gui should use relative widget coordinates for clicking.
21:46:25 *** fonsinchen has joined #openttd
21:50:36 <Eddi|zuHause> zachanima: i clearly missed the pun again
22:02:24 <Rubidium> planetmaker wants to be a moderator?
22:05:58 <planetmaker> that's nothing new, or?
22:06:11 <welshdragon> read the IS2 topic
22:06:47 <CIA-9> OpenTTD: rubidium * r17834 /trunk/src/economy.cpp: -Fix [FS#3274] (r17808): you got paid a bit too much... ofcourse the index of the source station generally doesn't equal the location of said station.
22:15:16 *** Coco-Banana-Man has quit IRC
22:17:51 <CIA-9> OpenTTD: smatz * r17835 /trunk/src/smallmap_gui.cpp: -Codechange: constify few variables
22:24:46 <CIA-9> OpenTTD: rubidium * r17836 /trunk/src/ (cargopacket.cpp cargopacket.h station_cmd.cpp):
22:24:46 <CIA-9> OpenTTD: -Codechange: split the CargoPacket constructor for creating 'real' new
22:24:46 <CIA-9> OpenTTD: CargoPackets and saveload. For saveload we do not need to set anything except
22:24:46 <CIA-9> OpenTTD: two variables (the rest is always overwritten by the load), for new 'real' cargo
22:24:46 <CIA-9> OpenTTD: also pass the source_xy; dereferencing st before calling is easier than
22:24:47 <CIA-9> OpenTTD: resolving st->index back to st and then dereferencing. Also don't set
22:24:49 <CIA-9> OpenTTD: loaded_at_xy because that is of no importance when not loaded in a vehicle.
22:25:53 <Eddi|zuHause> i have a feeling these are only the most tiny drops of cargodist
22:26:38 <Rubidium> nope, the last few weren't
22:26:57 <Rubidium> or at least not in the cargoset branch
22:27:35 <Eddi|zuHause> yeah, that may be, but cargoset itself is only a small part of cargodist, or not?
22:29:01 *** TrainzStoffe has joined #openttd
22:30:00 <Eddi|zuHause> so... facit: i have one engine completely falling apart, one engine with loose soldering contacts, three engines that don't make a full round on their own, one untested engine and two that make their round fairly reliable, unless the track contacts are acting up...
22:30:35 <Eddi|zuHause> oh, and at least one missing engine...
22:32:32 <Eddi|zuHause> i know that engine was there 20 years ago...
22:33:27 <Rubidium> so... make a quantum leap and ditch them. One big leap for Edii, but a small one for his trains :)
22:34:55 <Eddi|zuHause> and i could use some capacitors to prevent flickering of the lighted wagons
22:36:33 *** TrainzStoffe is now known as Stoffe
22:56:11 <fonsinchen> I think I'll revert the actual "set" part of cargoset. reverse-linear searching for mergable packets in the vehicle cargo lists isn't really slower but much easier to implement and maintain.
23:03:48 <fonsinchen> I think I'll start merging the stuff now. Or are there more things coming, Rubidium?
23:04:14 <Rubidium> am messing with new/delete
23:04:24 <Rubidium> but that shouldn't bother you (I think)
23:33:16 *** Eddi|zuHause has joined #openttd
continue to next day ⏵
