Log for #openttd on 30th December 2010:
Times are UTC Toggle Colours
00:10:30  *** X-2 [] has quit [Remote host closed the connection]
00:18:12  *** Cybertinus [] has quit [Remote host closed the connection]
00:21:18  <Xaroth> hah, in tron legacy you actually see a unix console with commands that are .. somewhat accurate
00:21:25  <Xaroth> normally you just see bollocks on the screens
00:22:50  <Markslap>
00:22:52  <Markslap> Like that one
00:22:52  <Markslap> :
00:22:54  <Markslap> :)
00:23:24  *** Wolf03 [] has joined #openttd
00:23:25  *** Wolf01 is now known as Guest2630
00:23:25  *** Wolf03 is now known as Wolf01
00:27:47  <Xaroth> heh, bit less accurate than tron tho
00:28:37  <Xaroth> tron was a bit more ps -somethign | grep something \n kill -9 <some pid>
00:29:01  *** Guest2630 [] has quit [Ping timeout: 480 seconds]
00:29:01  <Xaroth> which, is exactly how you kill something :P
00:29:35  <__ln__> you mean t*** legacy
00:30:12  <__ln__> anyway, i was watching that one tonight
00:30:53  <Xaroth> yeh, it's not the 1982 tron :P
00:31:46  <__ln__> they had 'top' running in some window, but i think it looked too modern
00:32:16  <Xaroth> hah, login to 'backdoor' user...
00:32:17  *** Fast2 [] has quit [Ping timeout: 480 seconds]
00:32:20  <Xaroth> it actually makes -some- sense
00:32:36  <Xaroth> normally in movies they just type 'login' 'win' and they win
00:33:24  <__ln__> i didn't realize the girl is 'thirteen' from house m.d. until i checked the imdb.
00:33:56  <Xaroth> heh
00:50:20  <Eddi|zuHause> "load porn"
00:55:27  <SmatZ> Eddi|zuHause: wrong window :p
00:56:50  <Eddi|zuHause> this was meant as an example of nonsensical commands ;)
01:01:13  <Mazur> This one is very funny:
01:02:16  <Mazur> B.t.w. I've seen some picture attachments being scrolled in text form as output from commands, I think it was on NCIS.
01:03:23  <Mazur> And commands like: connect hacker
01:03:35  <Mazur> with the name of the hacker where I wrote hacker.
01:03:40  *** KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.3]
01:05:16  <Mazur> And of course a picture of the world with lines "following" the IP packets come up on a different, large wallscreen as a result.
01:07:27  <Mazur> Enhancing pictures is also such fun, lots of details not in the original picture come up when they do that.
01:14:49  *** fmauneko [~fmauneko@] has quit [Quit: fmauneko]
01:18:20  *** Kurimus [] has quit []
01:25:18  *** fanioz [~fanioz@] has quit [Read error: Connection reset by peer]
01:28:49  *** Devroush [] has quit []
01:29:58  *** jpx_ [] has quit [Ping timeout: 480 seconds]
01:45:12  *** Progman [] has quit [Remote host closed the connection]
01:47:27  *** glevans2 [] has quit [Read error: Connection reset by peer]
01:47:31  *** fanioz [~fanioz@] has joined #openttd
02:01:02  *** glevans2 [] has joined #openttd
02:02:11  <Xaroth> worst part is when they show an IP Address that's not even remotely posible
02:02:25  <Xaroth> like 952.7125.1.8574
02:04:31  *** Biolunar_ [] has joined #openttd
02:05:27  *** xiong [] has joined #openttd
02:07:23  *** perk111 [~perk11@] has joined #openttd
02:07:34  *** perk11 [~perk11@] has quit [Ping timeout: 480 seconds]
02:12:03  *** Biolunar [] has quit [Ping timeout: 480 seconds]
02:13:11  *** fanioz_ [~fanioz@] has joined #openttd
02:16:19  *** fanioz [~fanioz@] has quit [Ping timeout: 480 seconds]
02:17:16  *** Biolunar_ [] has quit [Remote host closed the connection]
02:21:46  *** fanioz_ is now known as fanioz
02:25:47  *** Fuco [~dota.keys@] has quit [Ping timeout: 480 seconds]
02:33:19  <Wolf01> 'night
02:33:25  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
02:52:04  *** asnoehu [] has quit [Ping timeout: 480 seconds]
03:43:36  *** fanioz_ [~fanioz@] has joined #openttd
03:49:19  *** fanioz [~fanioz@] has quit [Ping timeout: 480 seconds]
03:59:28  *** nicfer [~nicfer@] has quit [Read error: Connection reset by peer]
04:15:00  *** glx [glx@2a01:e35:2f59:c7c0:ed36:cff1:cfc0:bbcb] has quit [Quit: bye]
04:15:39  *** perk111 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
04:22:38  *** lasershock [] has quit [Ping timeout: 480 seconds]
04:29:34  *** fanioz_ [~fanioz@] has quit [Ping timeout: 480 seconds]
04:46:36  *** DarkTomas [] has joined #openttd
04:46:45  <DarkTomas> Hello Everybody
04:46:52  <DarkTomas> I have a question *gg*
04:47:21  <DarkTomas> anyone here?
05:07:48  *** DarkTomas [] has left #openttd []
05:14:37  *** lasershock [] has joined #openttd
05:56:02  *** Eddi|zuHause [] has quit [Remote host closed the connection]
05:56:18  *** Eddi|zuHause [] has joined #openttd
06:23:45  *** xiong [] has quit [Ping timeout: 480 seconds]
06:40:51  *** Cybertinus [] has joined #openttd
07:38:58  *** DayDreamer [~DayDreame@] has joined #openttd
07:51:54  <dihedral> morning
07:59:05  *** DayDreamer1 [~DayDreame@] has joined #openttd
08:04:00  *** DayDreamer [~DayDreame@] has quit [Ping timeout: 480 seconds]
08:20:57  <Terkhen> good morning
08:23:12  <planetmaker> moin
08:34:29  *** lasershock [] has quit [Read error: Connection reset by peer]
08:35:48  *** zodttd2 [] has joined #openttd
08:39:57  *** lasershock [] has joined #openttd
08:42:29  *** zodttd [] has quit [Ping timeout: 480 seconds]
08:56:51  <dihedral> i am totally confuddled
08:56:56  <dihedral> i have a const NetworkClientSocket *owner
08:57:07  <dihedral> and get an error when using owner->client_id
08:57:21  <dihedral> invalid use of incomplete type ‘const struct ServerNetworkGameSocketHandler’
09:00:17  *** Kurimus [] has joined #openttd
09:01:47  <Rubidium> dihedral: you need to include the right header
09:01:59  <Rubidium> I guess it's network_server.h
09:02:04  <dihedral> i just found that out too :-P
09:02:10  <dihedral> thank you though
09:03:06  <Rubidium> also, why do you need direct access to the command array when there are appropriate accessor functions?
09:04:23  <dihedral> i am using CommandPacket when it gets appended to the clients queue on the server side
09:05:01  <dihedral> but then it did get late last night ^^
09:07:01  <dihedral> or would you rather i use a different approach
09:08:57  <Rubidium> doing it in DistributeCommandPacket seems the most sane approach
09:09:24  <dihedral>
09:09:59  <dihedral> i actually am one level up from that
09:10:10  <dihedral> after the call to DistributeCommandPacket
09:11:50  <Rubidium> the src/command.cpp and second chunk from command_type are not needed; there is a perfectly good accessor function for that
09:12:17  <Rubidium> i.e. GetCommandName
09:16:46  <Rubidium> maybe it also makes sense to put the index of the first command in a CMD_NAMES packet
09:17:32  <Rubidium> also, you only need to send the lower 16 bits of cp->cmd as the high 16 bits aren't useful for logging in any case
09:18:42  <dihedral> the upper 16 bits are flags?
09:19:03  <Rubidium> no, they are the default error message StringID
09:19:13  <dihedral> ah - wonderful :-)
09:19:21  *** |Jeroen| [] has joined #openttd
09:19:31  <dihedral> are the flags somewhat stable?
09:19:32  <Rubidium> also line 223 of the diff is badly aligned
09:20:18  <Rubidium> actually the flags are all masked out before sending the commandpacket
09:21:03  <Rubidium> but I rather leave the lower 16 bits in case we get more than 255 commands
09:21:18  <dihedral> makes sense
09:25:08  *** Alberth [] has joined #openttd
09:25:11  *** mode/#openttd [+o Alberth] by ChanServ
09:33:55  *** JVassie [~James@] has joined #openttd
09:35:51  *** ZirconiumX [] has joined #openttd
09:36:03  <ZirconiumX> Hello?
09:39:03  <ZirconiumX> Anyone?
09:40:49  *** ZirconiumX [] has quit []
09:41:11  *** Progman [] has joined #openttd
09:42:25  <dihedral> at least he left like 3 minutes for "Anyone" to reply
09:48:08  <Mazur>    1 minute.
09:48:30  <Mazur> --- Anyone :No such nick/channel
09:48:30  <Mazur> --- [Anyone] End of WHOIS list.
09:52:14  <dihedral> Rubidium,
09:52:43  <Xaroth> dihedral: cmd names?
09:53:49  <dihedral> i am not quite happy with NetworkAdminCmdLogging, i feel client_id should only be assigned if an admin is asking for command logging
09:54:48  <dihedral> Xaroth, cmd names is useful in combination with cmd logging - as the names of commands can change and i do not want that to have an affect on the admin network, making the network protocol stable by transmitting an enum over the network
09:55:00  <Xaroth> ah
09:55:20  <dihedral> poll for ADMIN_UPDATE_CMD_NAMES and you will receive 2 packets full of names :-)
09:55:37  <Xaroth> heh
09:56:01  <dihedral> Rubidium, another thought ;-) if the id is not transmitted in combination of the names, you cannot create offsets
09:56:33  <dihedral> so it would probably make sense to always transmit id, name, bool (has next)
10:02:55  <dihedral> lets the packet fill up a little sooner but not that much - makes about 1/8 difference of the amount of cmd names that fit into the first packet
10:03:05  <dihedral> 70 instead of 79
10:05:04  <Rubidium> dihedral: or use command ID ffffh to flag "end of packet"
10:05:26  <Xaroth> the bool next one is used in other stuff as well
10:05:29  <Xaroth> so that'd work
10:06:09  <dihedral> but it's 70 bytes less for the first packet :-P
10:06:22  *** tokai|mdlx [] has joined #openttd
10:06:24  <Xaroth> who cares about size :/
10:06:29  *** Chrill [] has joined #openttd
10:06:31  <Xaroth> it's often only sent once
10:06:43  <dihedral> size does not (always) matter
10:06:56  <dihedral> i like the 0xffff better
10:07:14  <dihedral> that way you know you have reached the end
10:07:42  <Xaroth> but iirc it's <bool> <id> <name>
10:07:50  <dihedral> ah - yes :-P
10:07:52  <Xaroth> if not <bool> == true, abort
10:08:05  <dihedral> Xaroth, the data does not fit in one packet
10:08:10  <Rubidium> but the bool isn't needed when you have a flag in ID
10:08:11  <dihedral> currently it's split over 2 packets
10:08:24  <dihedral> ah wait :-S
10:08:26  <Rubidium> (or a sentinel value)
10:08:37  <Xaroth> Rubidium: but why create yet another way to pack an array of values :P
10:08:38  <dihedral> well - does not really matter
10:08:56  <dihedral> Xaroth, yet another way will mean, stable over admin network
10:09:18  <Xaroth> how is creating 50000 different ways to send sets of data, stable?
10:09:31  <dihedral> how many sets are sent?
10:09:55  <dihedral> i recall client and company details and updates, but they are each in their own packet
10:10:14  <Xaroth> yep
10:10:34  <dihedral> i think putting each cmd name in it's own packet a waste of space and overhead
10:10:42  <Rubidium> hmm, just leave the bool; it's consistent with the rest of the packets
10:10:46  <Xaroth> correct
10:11:07  <Rubidium> (admin packets that is)
10:11:23  <Xaroth> i would suggest: <packet header> < array of <bool next> <id> <name> > <bool of 'more follows'>
10:11:40  <Xaroth> or instead of a bool a count of how much more follows
10:11:54  <dihedral> we do not know how much more follows
10:12:35  <Xaroth> then a bool
10:12:38  <dihedral> i was otherwise considering a marker packet, that indicates the end of a set of data
10:12:44  *** tokai [] has quit [Ping timeout: 480 seconds]
10:12:56  <dihedral> which for Client and Company info when joining the game would also be relevant
10:13:08  <Xaroth> well you need a way to either mark the start or end of the data
10:14:07  <dihedral> a single client info packet is fine - i more refer to when you join the game and poll for all client info's
10:14:20  <dihedral> when does the bot know it's done :-P
10:15:03  <dihedral> it could make sense to send a End Of Data type packet
10:15:19  *** jpx_ [] has joined #openttd
10:15:48  <Rubidium> dihedral: that's kinda implicit by another packet type arriving :)
10:16:14  <Rubidium> although sending "true ffffh false" instead of "false" at the end of the last packet would make some sense
10:16:31  <dihedral> heh :-)
10:16:48  <dihedral> that would then get rid of the end of data packet i am thinking of :-D
10:17:36  <dihedral> because - what if no other packet arrives for some time? :-P
10:17:50  <Xaroth> then the admin needs to sort out his network :P
10:18:25  <dihedral> paused game, no clients, 5 companies
10:21:41  <dihedral> so, 0xffff, or another packet type as marker
10:23:39  <Rubidium> just use 0xffff
10:23:42  <Rubidium> much simpler
10:23:56  <dihedral> but also not adaptable to other packets
10:24:28  <dihedral> currently the end of client info and company info is not marked, and waiting for another packet can potentially take a while
10:24:51  <Rubidium> imo you don't need to send such explicit markers
10:25:03  <dihedral> ok
10:25:53  <dihedral> also, as 0xffff false does not fit into the structure of the rest of the packet, 0xffff "" false?
10:33:42  <dihedral> then just adding another bool is easier
10:35:06  *** ZirconiumX [] has joined #openttd
10:35:31  <dihedral> @topic get 3
10:35:31  <DorpsGek> dihedral: Don't ask to ask, just ask
10:36:23  <ZirconiumX> hello dihedral
10:36:37  <dihedral> hi
10:36:57  <ZirconiumX> thanks for confirming my bug...
10:37:10  <ZirconiumX> FS4345
10:37:18  <dihedral> true 0xffff <- that is odd, because it defeats the meaning of true as 0xffff is not really a cmd id :-P
10:37:33  <dihedral> ZirconiumX, it's been fixed already
10:37:53  <ZirconiumX> I know, and I wanted to thank you for that
10:38:03  <dihedral> ah - you are welcome :-)
10:38:28  <dihedral> though i did not write the fix :-P
10:38:58  <ZirconiumX> You still helped!
10:39:18  <dihedral> :-)
10:39:35  <ZirconiumX> ;)
10:41:38  <dihedral> Rubidium, what benefit does true 0xffff false have over false false
10:41:43  *** LordAro [] has joined #openttd
10:41:44  <dihedral> you said it makes sense
10:41:51  <LordAro> moin
10:42:01  <dihedral> writing the code for it i am coming to think it's more mind boggling
10:42:01  <ZirconiumX> Hello, LordAro
10:43:31  <dihedral> i could send a false : next id if another packet is to follow, then false 0xffff would make sense as end of transmission
10:43:44  *** xiong [] has joined #openttd
10:45:39  *** pugi [] has joined #openttd
10:46:26  <dihedral> but that would be as good as a 2 boolean values (more data : more packets)
10:47:32  *** |Jeroen| [] has quit [Remote host closed the connection]
10:59:04  *** Eddi|zuHause [] has quit [Remote host closed the connection]
10:59:37  *** Eddi|zuHause [] has joined #openttd
11:04:45  <Rubidium> still I wonder why you're so bothered with sending a "no more packets of this type" marker
11:04:53  <Rubidium> why would you need it?
11:05:09  <Rubidium> it's not like you'd receive other packets until you received all of the command name packets
11:05:27  *** |Jeroen| [] has joined #openttd
11:05:42  <Rubidium> so, just adding them to a mapping when receiving them would be perfectly fine
11:05:51  <Rubidium> s/be/work/
11:06:50  <Rubidium> I wouldn't be bothered to even consider checking whether there would be more packets of that type; I would handle them and be done with them
11:07:35  <dihedral> perfect :-)
11:07:42  <Rubidium> and when someone queries for a command name given an id I'd just return from whatever I have... but requesting the command name without having received a command seems kinda pointless
11:09:14  <dihedral> i was just going to transmit the whole lot
11:09:30  <Rubidium> I know
11:09:36  <dihedral> you query for all names instead of just one
11:10:02  <dihedral> right, so querying for a single command name is what you would like supported?
11:10:13  <Rubidium> no, I'm talking from the perspective of an "admin" tool talking to the library which talks over the admin protocol to OpenTTD
11:10:53  <Rubidium> dihedral: no, it's how I would implement the "get command name" API in my libopenttdadmin
11:11:08  <dihedral> ah
11:11:23  <dihedral> yes, that is what i was after
11:11:36  <dihedral> static mapping of name -> id
11:12:03  <dihedral> and i'll probably build something to implement a type of Dynamic Enum
11:12:26  <dihedral> though it never really will be of the Enum type in java .... grrr
11:14:17  <dihedral>
11:31:53  *** Fast2 [] has joined #openttd
11:34:47  *** DayDreamer1 [~DayDreame@] has quit [Read error: Connection reset by peer]
11:40:19  *** |Jeroen| [] has quit [Read error: Connection reset by peer]
11:45:28  *** |Jeroen| [] has joined #openttd
11:55:11  *** Devroush [] has joined #openttd
11:55:48  <dihedral> looking at a product page: Supported Filesystems: UTF-8, .EXT3, .NTFS
11:55:49  <dihedral> lol
11:56:53  *** KenjiE20 [~KenjiE20@] has joined #openttd
11:57:25  <roboboy> lol
12:00:07  <Terkhen> :D
12:00:20  *** Adambean [] has joined #openttd
12:01:26  *** Cybertinus [] has quit [Ping timeout: 480 seconds]
12:06:32  <peter1138> so i added michi's tweaks as a separate graph
12:06:43  <dihedral> \o/
12:07:10  <dihedral> where is the graph?
12:07:11  <peter1138> on a 5% incline, for the two vehicles i tested yesterday, the graphs is eerily similar to ttdpatch
12:07:22  <peter1138>
12:07:29  <peter1138>
12:08:26  <peter1138> first is the VT-95, heh
12:10:02  *** Cybertinus [] has joined #openttd
12:10:31  *** fonsinchen [] has joined #openttd
12:10:31  <dihedral> what is the black line in the graph
12:11:07  <peter1138> acceleration output, but the units are meaningless
12:11:19  <dihedral> i love you "Button" :-P
12:11:26  <peter1138> it was added when i was experimenting with 16 bit subspeed
12:11:30  <peter1138> hehe
12:12:01  <peter1138> incline should be 0.03 for ottd sloeps and 0.05 for ttdp
12:12:04  <peter1138> and slopes
12:14:55  *** Fuco [~dota.keys@] has joined #openttd
12:17:01  <peter1138> of course, if you want exact ttdpatch curves... well
12:17:15  <peter1138> the code's behind that graph, heh
12:19:50  *** Cybertinus [] has quit [Ping timeout: 480 seconds]
12:21:16  <Eddi|zuHause> but the calculated top spead doesn't really match the observed top speed?
12:21:25  *** Cybertinus [] has joined #openttd
12:22:08  <peter1138> in what?
12:23:41  <Eddi|zuHause> hm... the dbset readme doesn't contain all values
12:23:51  <Eddi|zuHause> it misses the mass and the air drag
12:24:05  <peter1138> i'm getting them from ottd
12:24:18  <peter1138> printed out the airdrag value, heh
12:24:30  <peter1138> the rest is shown in the gui anyway
12:25:41  *** ZirconiumX [] has quit [Quit: ajax IRC Client]
12:44:47  <dihedral> peter1138, could you do that same thing using values from something like the 2cc set?
12:45:06  <dihedral> i.e. the locs mentioned in the thread
12:45:44  <Eddi|zuHause> oh... is that mass of the vT95 empty or full?
12:46:24  <peter1138> empty
12:49:08  *** Wolf01 [] has joined #openttd
12:49:34  <Wolf01> hello
13:00:39  *** Chrill [] has quit []
13:09:15  *** |Jeroen| [] has quit [Quit: oO]
13:10:49  *** Adambean [] has quit [Ping timeout: 480 seconds]
13:16:54  <CIA-2> OpenTTD: alberth * r21665 /trunk/src/ (5 files): -Codechange: Make GetCallbackWnd a method of _thd.
13:18:15  *** |Jeroen| [] has joined #openttd
13:18:23  <CIA-2> OpenTTD: alberth * r21666 /trunk/src/ (vehicle_gui.cpp viewport.cpp): -Codechange: Use GetCallbackWnd at more places.
13:18:48  <peter1138> hmm, so 40 passengers
13:19:24  <dihedral> que?
13:21:00  <peter1138> Eddi|zuHause, makes no difference
13:21:19  <peter1138> (13t vs 15t)
13:21:37  <peter1138> maxte increases to 38kN
13:21:41  <dihedral> those were fat 40 people :-P
13:22:00  <peter1138> each person weighs 1/16th of a ton
13:22:19  <ctibor> they have some luggage :-)
13:22:19  <dihedral> i dont :-P
13:22:19  <peter1138> i guess it gets rounded down, or it's display incorrectly, heh
13:22:55  *** glx [glx@2a01:e35:2f59:c7c0:bc20:e152:e2d5:12b6] has joined #openttd
13:22:58  *** mode/#openttd [+v glx] by ChanServ
13:23:06  <peter1138> dihedral, it's 62.5kg
13:23:08  <peter1138> not that heavy
13:23:14  <dihedral> oh - true
13:23:40  <dihedral> where did that study come from? :P
13:23:43  <peter1138> in fact it's quite below normal for an adult male
13:23:47  <dihedral> america would not fit into that :-P
13:24:08  <dihedral> but then people in openttd are smaller
13:24:12  <dihedral> and gravity is different
13:24:16  <peter1138> heh
13:25:19  <peter1138> interesting that wagons have unladen and laden weight displayed
13:25:30  <peter1138> but engines that take cargo don't
13:26:05  <dihedral> hehe
13:26:16  <peter1138> and max t.e. is unladen max t.e.
13:27:06  <peter1138> how long should a BR612 be?
13:27:12  <dihedral> we should introduce a new passenger loading algorythm
13:27:18  * LordAro wonders why my wiki template isn't working ( - it won't add the third parameter... any clever people out there want to help? ;)
13:27:34  <dihedral> passengers may have different weights (randomly determined at station when loading)
13:27:58  <dihedral> passengers to not fill waggons from the front to the back, only taking the next waggon when the previous one filled up
13:28:03  <dihedral> noooo, they sit all over the place
13:28:18  <planetmaker> it's realistic!
13:28:33  <dihedral> realistic passengers
13:28:38  <dihedral> or rather new passengers?
13:29:22  <peter1138> hmm, all the photos i see of BR612 are either two or four parts, all (look as if) they're powered
13:29:40  <dihedral> and a low chance of one out f 100 passengers being obese - needing two seats, weighing more, and paying for one
13:30:04  <planetmaker> dihedral: you can already do that via newgrf
13:30:11  <planetmaker> so no need for new work there
13:30:30  <planetmaker> might be a bit hackish, but feasable
13:31:02  <dihedral> you make me a fatpass newgrf? :-P
13:31:43  <planetmaker> well. If I do that, you can only buy those wagons with that feature in Februaries where it has 29 days, but feasable ;-)
13:31:46  <dihedral> or if you like leave the p away
13:31:49  <peter1138> you could only make 62.5 kg and 125 kg passengers :p
13:31:53  <planetmaker> you have to provide graphics though :-P
13:31:59  *** Fast2 [] has quit [Ping timeout: 480 seconds]
13:32:17  <dihedral> peter1138, no tripple weights? :-P
13:32:18  <planetmaker> peter1138: nah, I'd use CB38 and change capacity and wagon weight ;-)
13:32:29  <planetmaker> (that's why I call it hackish)
13:32:41  <planetmaker> *CB36 probably
13:32:41  <peter1138> dihedral... 30st people? :S
13:33:32  <dihedral> ?
13:36:20  <peter1138> 187.5kg, then
13:36:33  <peter1138> approximately 30st
13:37:33  <planetmaker> who uses those kind of funky units?
13:37:54  <peter1138> british people
13:38:22  *** tim [] has joined #openttd
13:38:33  <planetmaker> strange folks ;-)
13:38:44  *** tim is now known as Timmaexx
13:39:18  <peter1138> not really, it's a convenient unit that doesn't result in big "hard to understand" numbers ;P
13:40:19  *** ZirconiumX [] has joined #openttd
13:40:27  <ZirconiumX> hello?
13:41:31  <dihedral> @topic get 3
13:41:31  <DorpsGek> dihedral: Don't ask to ask, just ask
13:42:02  <ZirconiumX> hello dihedral, what you doing this time
13:45:44  *** Timmaexx [] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101206121845]]
13:47:01  <Alberth> dihedral: it is just ZirconiumX his way of saying hello, it seems
13:47:27  <ZirconiumX> how else do you say hello?!?
13:47:37  <Alberth> without question mark
13:47:49  <SpComb> lolhaiguyz
13:48:09  * ZirconiumX attempted to break ice, but failed...
13:48:36  <Alberth> temperatures are above 0 celcius here :)
13:48:51  <ZirconiumX> not sure here
13:49:04  <Alberth> here == in the channel
13:50:10  <dihedral> is there at all a termperature in the channel?
13:50:20  <dihedral> and don't start with cpu temp :-P
13:50:40  * ZirconiumX gives server a blanket
13:50:46  <dihedral> ZirconiumX, the questionmark threw me off i just thought you wanted to have some questions answered :-)
13:51:44  <planetmaker> dihedral: that's usual ;-) He always enters the channel and asks cautiously for a 'hello' ;-)
13:51:47  * dihedral will go out do some shopping and phoning and then sit in starbucks and enjoy a coffee :-P
13:52:30  <planetmaker> and I'm slow it seems :-P
13:52:49  <peter1138> starbucks sell coffee?
13:52:59  <ZirconiumX> which would you prefer, a friendly hello, or a barge into the conversation, that may not even be on the same track, and a kicking as a result
13:53:35  <dihedral> a friendly hello of course, just one needs to get used to friendly hellos as they don't usually exist from new people :-P
13:53:44  <dihedral> peter1138, for a certain definition of ....
13:55:11  <Rubidium> peter1138: in the dozens of times I've been to Starbucks I've never bought coffee, so I guess they don't sell coffee
13:55:18  <dihedral> Rubidium, in case you did not get the message, dell diagnostic software is not os dependent anmore :-)
13:55:38  <dihedral> i've had a coffee there... once
13:56:11  <Rubidium> dihedral: the diagnostics software is fine, just the stupid hell-desk employee who *must* be able to see stuff happen in Windows is the problem
13:56:45  <Rubidium> even though the can't really use anything from the Dell diagnostics software in Windows
13:56:52  <ZirconiumX> I had a Packard Bell computer,
13:57:06  <dihedral> hmmm - i have a vm :-D
13:57:09  <peter1138> poor you
13:57:15  <dihedral> perhaps i can break stuff in there on purpose
13:57:20  <Rubidium> nor does the hell-desk employee have any clue about how to get the GPU/CPU temperature under Windows, even though I gave them the temps as given to by Linux
13:57:30  <ZirconiumX> It was renamed the Packard Hell, after it took 3 hours to boot up...
13:57:51  <dihedral> hehe - i hope i get different support Rubidium
13:57:58  <glx> Rubidium: speedfan does that
13:58:10  <glx> though I don't know if it can read ATI sensors
14:01:45  <ZirconiumX> maybe?
14:01:48  <ZirconiumX> DELL support is now tested on more chipsets.
14:01:58  <ZirconiumX> no idea if that's correct
14:03:55  <Rubidium> glx: I don't care what does, what I'm annoyed about is that I needed to install Windows so the hell-desk morons could do their work properly, but when I installed it it seemed that the morons were really morons and didn't even know how to get the CPUs temperature
14:04:19  <ZirconiumX> Rubidum: Ouch!
14:04:25  <glx> they just follow the script
14:05:00  <Rubidium> what really helped though is that when the overheat protection kicks in it's quite loud, so whenever the Dell moron was doing something under Windows (that took more than a few minutes), the overheat protection would kick in
14:05:23  <Rubidium> and even then they kept telling me it was probably a BIOS issue
14:05:42  <ZirconiumX> Earmuffs, anyone?
14:06:11  <Rubidium> and not just their tech that put about a inch of cooling paste between the chips and the heat pipes
14:06:18  <glx> it may be a bios issue
14:06:52  <ZirconiumX> An inch?!?
14:06:59  <ZirconiumX> that's a lot!
14:07:00  <Rubidium> glx: eventually it was, when he was updating the BIOS and it went into thermal protection
14:07:03  <glx> like a too slow fan rotation for given temp
14:08:06  <Rubidium> glx: it was at max speed
14:08:15  <ZirconiumX> ah...
14:08:18  <glx> wrong design then ;)
14:08:36  <Rubidium> glx: it is wrongly designed
14:08:46  <Rubidium> that's definitely true
14:08:53  <ZirconiumX> Fix: PIDB
14:09:14  <ZirconiumX> Put In Dust Bin *ahem*
14:09:55  <Rubidium> nah, I more or less got free-at-home-next-business-day support...
14:09:55  <glx> I still need to try to open my brother's laptop to clean it and maybe change thermal paste
14:10:21  <Rubidium> so they're starting to become a regular by now
14:10:26  <Eddi|zuHause> <peter1138> hmm, all the photos i see of BR612 are either two or four parts, all (look as if) they're powered <-- if you mean the modern BR 612, they seem to be fixed double-units which may occasionally travel in pairs.
14:11:36  <Rubidium> so they're definitely making a loss on my laptop, which is what they should make for ill designed hardware
14:13:18  <Eddi|zuHause> peter1138: each wagon has one set of driven axles and one set of undriven axles
14:14:12  <dihedral> i get next business day support for my laptop too
14:14:31  <Rubidium> dihedral: how many bytes are 16 bits?
14:14:37  <Rubidium> +		/* Should SEND_MTU be exceeded, start a new packet (magic 18: uint16 for the id + 2 x bool)*/
14:14:44  <Rubidium> also
14:14:44  <Rubidium> +	p->Send_uint32(cp->cmd & 0xFFFF);
14:14:51  <roboboy> gnight
14:14:53  <Rubidium> +	 * uint16  ID of the command (Lower 16 bits) (see command.h).
14:14:58  <dihedral> 2 :-P
14:15:16  <planetmaker> g'night roboboy
14:15:18  <dihedral> ops
14:15:22  <Rubidium> moi moi roboboy
14:16:44  <Rubidium> I'm also missing the documentation that very clearly states that the command IDs and such are inherently unstable so they must not trust on a particular value having the same meaning between releases
14:17:04  <dihedral> yes.
14:17:54  <fonsinchen> Rubidium: now that we have auto-orders and thus stopping orders work better in cargodist ... What is the most significant remaining problem with cargodist in your opinion?
14:19:17  *** Wolf03 [] has joined #openttd
14:19:17  *** Wolf01 is now known as Guest2680
14:19:17  *** Wolf03 is now known as Wolf01
14:20:01  <Rubidium> fonsinchen: I don't know exactly at this point; I haven't really looked at the code recently
14:20:24  <Rubidium> well, I tried but I found that the patches were compound patches that because bigger and bigger
14:20:33  <Rubidium> instead of patches to apply on top of eachother
14:20:52  <Rubidium> which made seeing what each individual branch is about somewhat more tricky to understand
14:21:12  <planetmaker> <3 patch queues ;-)
14:21:25  <fonsinchen> ok, that's a problem. They should be such that they can be applied on top of each other.
14:21:30  * fonsinchen investigates
14:22:21  <Rubidium> <- that seems to include more than only the stats for the smallmap
14:23:18  *** dada_ [] has joined #openttd
14:24:21  *** Guest2680 [] has quit [Ping timeout: 480 seconds]
14:24:34  *** LordAro [] has quit [Quit: ajax IRC Client]
14:25:24  <fonsinchen> Somehow I removed the code for incremental patches in order to get clean names for the "cd.diff", but didn't replace it.
14:25:29  <fonsinchen> I'm fixing that.
14:26:25  *** Dante123 [] has joined #openttd
14:28:56  *** Fuco [~dota.keys@] has quit [Read error: Connection reset by peer]
14:29:18  <dada_> not sure if this is known but compiling fails for me (OSX PPC) starting with revision 21666. I filed a report here
14:29:23  *** Fuco [~dota.keys@] has joined #openttd
14:29:50  <ZirconiumX> Can I just say something
14:30:35  <ZirconiumX> why don't you wait till tomorrow, and you can play with that!
14:31:11  <ZirconiumX> or download r21659
14:31:34  *** bryjen [~bryjen@] has joined #openttd
14:31:45  <glx> dada_: and 21665 is ok ?
14:31:52  <dada_> glx: I'm about to try
14:34:01  <planetmaker> dada_: what compiler (version) do you use?
14:34:24  <dada_> powerpc-apple-darwin9-gcc-4.0.1
14:35:21  <ZirconiumX> OK, that's normal
14:35:31  <ZirconiumX> What version of Xcode?
14:35:59  <dada_> Do you know where I can find that? I thought Xcode was just a collection of multiple things
14:36:17  <dada_> But I think it's the last one that works on 10.5, they stopped making them install after a particular version
14:36:25  <ZirconiumX> Look in your Hard disk
14:36:40  <ZirconiumX> Look for a folder that says Xcode
14:36:45  <Eddi|zuHause> ZirconiumX: a person may stay silence and risk others perceiving him as an idiot, or he may open his mouth and remove all doubt.
14:37:14  <dada_> there doesn't seem to be an xcode dir, but I still had the DMG around, which states: xcode314_2809_developerdvd
14:37:17  <Eddi|zuHause> *silent
14:37:40  <dada_> 3.1.4 that is
14:37:43  <planetmaker> dada_: the error is in your compiler, not in OpenTTD, I'm afraid
14:38:05  <planetmaker> but it will be interesting which version it breaks for you nevertheless
14:38:11  <dada_> aha, new function that 4.0.1 doesn't support? I'll update it then
14:38:17  *** nicfer [~nicfer@] has joined #openttd
14:38:34  <planetmaker> you cannot update it...
14:38:48  <planetmaker> unless you update your OS which is probably not an option for PPC macs.
14:38:55  <planetmaker> i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494) <-- that one builds it
14:38:56  <Rubidium> an "internal compiler error" means the compiler itself is broken. That's not something OpenTTD can do about
14:39:36  <ZirconiumX> PPC support on GCC was dropped some time ago
14:40:07  <planetmaker> ZirconiumX: in this case again: si tacuisses :-P
14:41:33  *** dada_ [] has quit [Read error: Connection reset by peer]
14:42:01  *** dada_ [] has joined #openttd
14:42:11  <Eddi|zuHause> get a virtual machine that runs x86 code :p
14:42:14  <Eddi|zuHause> or get a real computer :p
14:42:19  <Rubidium> ZirconiumX: I really doubt that GCC dropped PPC support
14:42:26  <planetmaker> dada_: does the current nightly of OpenTTD work for you?
14:42:28  <dada_> aand we're back
14:42:45  <dada_> by the way planetmaker, that version number you showed me is just one build higher than my gcc
14:42:53  <dada_> the nightly? you mean bin?
14:43:05  <planetmaker> yes, the binary download from our website
14:43:13  <dada_> I'll try
14:43:15  *** ZirconiumX [] has quit [Quit: ajax IRC Client]
14:43:34  <dada_> ah, that's 21659
14:44:38  <ccfreak2k> What happened to the first 21,659...whatevers?
14:44:52  <dada_> seems to work just fine
14:45:41  <planetmaker> ok.
14:45:44  <Rubidium> Zirwhoisgonenow: powerpc is a primary platform for gcc 4.5, whereas apple's platforms are secondary
14:46:14  <planetmaker> Not sure whether you have other compilers at your disposal; you might try those, dada_
14:46:31  <Rubidium> (and for what it's worth in 4.5 Apple's platforms got bumped from primary to secondary targets)
14:46:31  <dada_> I'll see if I can
14:46:38  <Ammler> no macport for ppc?
14:46:48  <planetmaker> you can easily switch them via gcc_select
14:46:54  <dada_> I don't know if there is, I haven't tried macports myself
14:47:06  <planetmaker> Ammler: the gcc from macports don't compile openttd
14:47:25  <Ammler> ok :-(
14:48:05  * dada_ make clean and tries again for good measure..
14:48:08  <planetmaker> they don't respect the file system layout and hirachy as apple's compilers do, thus they fail
14:48:29  <planetmaker> (roughly speaking)
14:48:37  <planetmaker> longer ago that I tried some versions
14:49:01  <Eddi|zuHause> sometimes i really don't understand xkcd...
14:49:48  <planetmaker> Eddi|zuHause: word play:
14:50:27  <planetmaker> makes it IMHO a tiny bit better, but oh well...
14:51:01  <Noldo> languages are funny
14:51:13  <Eddi|zuHause> not really helping either...
14:52:45  <Eddi|zuHause> why would "krasse Spachtelmasse" say "don't touch me"? and what does that have to do with "Impact"?
14:53:00  <fonsinchen> Rubidium: now you can get incremental patches at and
14:53:16  <fonsinchen> I see that smallmap-stats is not sufficiently documented.
14:54:12  *** |Jeroen| [] has quit [Remote host closed the connection]
14:54:27  <fonsinchen> I'm still wondering if I should further simplify it. I could remove the mouse-over functionality.
14:54:31  *** roboboy [] has quit [Ping timeout: 480 seconds]
14:55:17  *** murr4y [] has quit [Ping timeout: 480 seconds]
14:57:34  <dada_> planetmaker: I believe the segmentation fault might have been entirely incidental...I'm recompiling the same version and it just passed the group_gui.cpp with no problem
14:58:26  <planetmaker> uhm...?
14:59:06  <dada_> maybe I should close my bug report then
14:59:34  <planetmaker> you can only request it. Don't bother though ;-)
15:00:27  <dada_> well, I'll just post anyway to let others know that it must have been some weird failure on my part...this is an old machine, maybe one of the memory units is faulty
15:00:56  <planetmaker> I just closed it ;-)
15:01:14  <dada_> alright :)
15:05:33  *** ecke [] has joined #openttd
15:07:06  *** roboboy [] has joined #openttd
15:08:43  <planetmaker> right... now I know again why I couldn't be bothered with macports gccs anymore: after tricking the sdk detection one ends up with things like /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147:120: error: format string argument not a string type
15:13:39  *** Joni- [] has joined #openttd
15:15:11  *** roboboy [] has quit [Ping timeout: 480 seconds]
15:18:51  *** stAckedflow [] has quit [Ping timeout: 480 seconds]
15:27:20  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
15:29:35  *** Joni- [] has quit [Quit: ( :: NoNameScript 4.22 :: )]
15:32:58  <CIA-2> OpenTTD: alberth * r21667 /trunk/src/ (tilehighlight_type.h viewport.cpp window.cpp): -Codechange: Introduce _thd.Reset().
15:33:46  *** Joni- [] has joined #openttd
15:36:34  *** Joni_ [] has joined #openttd
15:37:21  <dada_> planetmaker: openttd 21666 successfully compiled
15:37:33  <planetmaker> good to hear :-)
15:37:49  <planetmaker> was it really 40 minutes compile time, though?
15:38:25  <dada_> no...I went to get groceries :)
15:39:31  <dada_> now...if only I could figure out how to get these stuck trucks out of that tunnel...
15:40:03  <planetmaker> sounds like an old(er) savegame which was made with a version which had a bug ;-)
15:41:23  *** Joni- [] has quit [Read error: Connection reset by peer]
15:42:20  *** Joni- [] has joined #openttd
15:45:59  *** Joni_ [] has quit [Read error: No route to host]
15:45:59  *** Joni- [] has quit [Read error: Connection reset by peer]
15:46:28  *** Joni- [] has joined #openttd
15:56:25  *** Joni_ [] has joined #openttd
15:57:33  *** Chicago [] has joined #openttd
15:58:07  *** Chicago [] has quit []
15:58:39  *** Chicago_Rail_Authority [] has joined #openttd
16:01:40  *** Joni- [] has quit [Ping timeout: 480 seconds]
16:06:10  *** xiong [] has quit [Ping timeout: 480 seconds]
16:14:35  *** staN [] has joined #openttd
16:15:19  *** HerzogDeXtEr1 [] has joined #openttd
16:19:31  *** fonsinchen [] has joined #openttd
16:21:48  *** HerzogDeXtEr [~Flex@] has quit [Ping timeout: 480 seconds]
16:42:50  <DJNekkid> sorry for asking, as i probably could have tested it, but what happens if a railtype have ID higher then 0xF ?
16:43:21  <DJNekkid> if i, for example, have 14 types with ID 0x00-0x0D
16:43:33  <DJNekkid> and then two types with id 0x10 and 0x11 ?
16:43:39  <DJNekkid> for a total of 16 types
16:43:59  <Yexo> the railtypes with ids >= 0x10 are ignored
16:44:33  <DJNekkid> is it possible to change that?
16:44:43  <Yexo> is there a good reason to?
16:45:35  <DJNekkid> full freedom to choose what to be included in nutracks. Can give, say, 20or so different ones to include, but only 16 of them can be used at once
16:45:45  <DJNekkid> thus do i need IDs higher then 0x10
16:46:07  <Eddi|zuHause> why not set the ID by action 6?
16:46:28  <DJNekkid> probably because i didnt know it were possible :P
16:46:58  <Eddi|zuHause> combined with action D you can make sure each ID is only used once
16:46:59  <Yexo> it can be changed, but either it requires quite a lot of changes to the openttd code or it'd use more memory for _every_ newgrf (not only those including railtypes, but every one)
16:47:17  <DJNekkid> oki, then thats not a (good) option :)
16:48:21  <DJNekkid> but that action6 thingy might be...
16:48:51  <Eddi|zuHause> DJNekkid: i'm imagining like this: for each (not skipped by action 7/9 or conditional compiling) railtype definition you have an action 6 replacing the ID with the content of parameter N, and right afterwards, you increase content of parameter N with action D.
16:49:48  <DJNekkid> that is one way to do it... :)
16:50:05  *** Dante123 [] has quit [Quit: ajax IRC Client]
16:50:22  <Yexo> try nml, you'll get the action6 for free :)
16:50:36  <planetmaker> hehe
16:50:39  <Eddi|zuHause> DJNekkid: that's what i can come up with within 2 minutes ;)
16:50:53  <DJNekkid> i had some other thoughts as well, but sure... :)
16:51:11  <planetmaker> Eddi|zuHause: that's what sounds the easiest straight-forward approach
16:51:21  <DJNekkid> i was thinking of a action14 table with 16 parameters... one for each ID
16:51:31  <DJNekkid> brb
16:51:56  <Eddi|zuHause> that sounds tedious... and unnecessarily exposing implementation details to the user
16:52:18  <Yexo> that means your grf will break when a user accidentally assigns two railtypes to the same id
16:52:47  <DJNekkid> Yexo: no, because each ID will have its own parameter
16:53:01  <planetmaker> yep. The one obstacle with the increasing ID type is to write the RTT with the desired IDs
16:53:04  <Yexo> so the users will chose a railtpye for every id?
16:53:15  <Yexo> what happens if the users selects the same railtype twice?
16:53:16  <DJNekkid> exactly
16:53:31  <Yexo> will he get the same railtype twice?
16:53:48  <DJNekkid> most likely
16:53:58  <Eddi|zuHause> planetmaker: what does the railtype grf need railtype labels for?
16:54:14  <Yexo> also, it will be quite tedious to implement that in nfo, you'll have to create a loop over all railtypes for every parameter and check every time if this one has been selected by the user
16:54:15  <DJNekkid> Eddi|zuHause: invisible engines to enable the different ones
16:54:36  <Eddi|zuHause> DJNekkid: imho that's a big design flaw of railtypes
16:54:58  <DJNekkid> Yexo: i dont think it would be too hard, as everything but the action0s are templated
16:55:48  <DJNekkid> Eddi|zuHause: true enough, but still a valid awnser :)
16:56:54  <Eddi|zuHause> planetmaker, DJNekkid: i was imagining more like one parameter to choose from like 3 or 4 predefined subsets, and a second (invisible to the user) parameter for the internal ID numbering, then one can have fixed railtype tables for each of the subsets
16:57:46  <planetmaker> Eddi|zuHause: I imagine to allow selecing certain railtype 'blocks':
16:57:49  <Eddi|zuHause> for each of the subsets, the ID numbering would be deterministic enough to fix the RTT
16:58:09  <planetmaker> probably those two ideas can be considered equivalent
16:58:37  *** einKarl [] has joined #openttd
16:58:53  <DJNekkid> but then the problem arise, again
16:59:07  <Eddi|zuHause> if you think in "blocks", you might have the need for "padding" railtypes that don't actually exist, to align the blocks, and then can switch around the block contents with action 6 again
17:00:00  <Eddi|zuHause> but this may get complicated/difficult to maintain
17:00:02  <DJNekkid> if, lets say, the 230kmh tracks is disabled
17:00:22  <DJNekkid> and my 230kmh engine is set to use E230 in its trainset RRT
17:00:25  <DJNekkid> *RTT
17:00:39  <DJNekkid> then it wont appear, because nothing is known about E230
17:00:55  <planetmaker> where's the problem?
17:01:26  <DJNekkid> the engine wont appear
17:01:27  <Yexo> DJNekkid: basically this are your options:
17:01:35  <Eddi|zuHause> DJNekkid: the trainset can check the existence of E230, and choose to fallback to the default electric railtype instead
17:02:49  <Yexo> either that or just have 1 parameter where you can chose between a few presets, that makes it a lot easier
17:03:20  <Eddi|zuHause> yeah, that's what i said
17:03:36  <DJNekkid> i did have a plan to do that once...
17:03:52  <DJNekkid> there even is a image/table in the nutracks tread about it
17:04:19  <Eddi|zuHause> i like "Option A" and "Option 2" ;)
17:04:48  <Yexo> well, "A" is different from "2", not? :p
17:04:57  <DJNekkid> about in the middle of page11
17:05:52  <planetmaker> DJNekkid: that table is not equivalent to chose different blocks
17:06:20  <planetmaker> My main desire for that is to get NuTracks compatible with other railtype newgrfs so that it does not claim the whole chunk of railtypes
17:06:46  * SmatZ zuHause
17:06:52  <planetmaker> :-)
17:07:47  <SmatZ> planetmaker: this time I remembered the password, so I changed it on this computer too :)
17:07:57  <planetmaker> :-D
17:09:03  <planetmaker> actually it'd do NuTracks quite good if it cut out e.g. the 230km/h track entirely
17:09:30  <planetmaker> and make it maybe, if you want 140 and 200km/h instead of 120 and 160
17:10:22  <planetmaker> or 100,200,highspeed
17:11:06  *** zachanima [] has joined #openttd
17:11:26  *** zachanima [] has quit []
17:11:31  *** zachanima [] has joined #openttd
17:12:08  <planetmaker> but possibly the most easy solution would be to offer not one giant railtypes newgrf but one for each block ;-)
17:12:24  <planetmaker> easier for the player to select. and also easier to programme
17:12:35  <planetmaker> like nutracks-3rdrail
17:12:41  <planetmaker> nutracks-rail
17:12:46  <planetmaker> nutracks-planning
17:12:50  <planetmaker> nutracks-narrowgauge
17:12:54  <planetmaker> or alike ;-)
17:13:04  <Wolf01> that's what I said yesterday
17:13:10  <planetmaker> :-)
17:13:50  <planetmaker> not to forget the marvelous nutracks-subway
17:14:06  <Wolf01> yeah, good use of catenary :D
17:14:28  <Wolf01> too bad building's roof is blinking where is red
17:14:39  <planetmaker> uh?
17:14:51  <planetmaker> that's just a graphics issue which would be easy to fix
17:15:10  <planetmaker> or what do you mean?
17:15:26  <Wolf01> what you said
17:16:29  <Wolf01> the worse thing are the tunnel entrances, I think there isn't a way to fix them with only a grf since the topmost part is always drawn over the catenary
17:17:45  <planetmaker> hm, yes, probably.
17:27:23  <dihedral> Rubidium:
17:27:31  <dihedral> or whoever might want to look at it
17:27:39  <dihedral> i'll be back in 15
17:39:16  <dihedral> tada
17:42:08  *** Mucht [] has joined #openttd
17:54:58  *** nicfer [~nicfer@] has quit [Read error: Connection reset by peer]
18:10:30  *** LordAro [] has joined #openttd
18:13:04  *** IchGuckLive [] has joined #openttd
18:13:45  <IchGuckLive> Good evening from Germany. Why are in the desert the Waterwells not rising production if i take water from them ??
18:14:49  <dihedral> because wells do not produce the water, they provide access to water
18:15:07  <dihedral> imagine a balloon full of water below the ground
18:15:12  <Yexo> IchGuckLive: please read on how industry production works
18:15:22  *** fjb is now known as Guest2698
18:15:23  *** fjb [] has joined #openttd
18:15:26  <planetmaker> also why do oil wells disappear? Just because.
18:15:28  <dihedral> wells provide means of accessing them and the more you drain the less is left
18:16:15  <Rubidium> and once more I broke someone's patch
18:16:36  <dihedral> which patch did you break?
18:18:14  * planetmaker would bet on dihedral
18:18:38  <dihedral> sounds more like my patch broke something
18:18:49  <planetmaker> nah. your patch is broken ;-)
18:18:56  <planetmaker> try to apply it now to trunk :-P
18:19:04  <dihedral> lol
18:19:05  <IchGuckLive> Yexo: so there is no need to play stop and go with the game it rises only in 20years of time  BAD
18:19:05  <Rubidium> or just try to svn up :)
18:19:16  <Rubidium> (that'll fail)
18:19:21  <dihedral> hmm... nothing happened :-D
18:19:35  <IchGuckLive> im in year 3 after start
18:19:40  <dihedral> oh - svn !!
18:19:42  <Yexo> IchGuckLive: I have no idea what you mean with "no need to play stop and go with the game"
18:19:50  <Yexo> and it seems like you totally didn't understand it
18:20:00  <Yexo> or you don't truely understand what "random" means
18:20:01  <planetmaker> nice work :-)
18:20:27  <IchGuckLive> Yexo:  iread it now ones more !
18:21:18  <dihedral> planetmaker, got another wish for the admin network? :-P
18:21:42  <planetmaker> yes. A usuable interface now which connects to it ;-)
18:22:10  *** Guest2698 [] has quit [Ping timeout: 480 seconds]
18:22:20  <planetmaker> can I take a screenshot via console?
18:22:23  <dihedral> pffft
18:22:26  <dihedral> who wants that? :-P
18:22:38  <dihedral> i'll give you a command logger ;-)
18:22:46  <planetmaker> :-)
18:24:18  *** LordAro [] has quit [Quit: ajax IRC Client]
18:24:25  <IchGuckLive> ok i go with that and provide as mutch service as i coudt to the water well so i will now run 1train per wagon to a diferent city
18:26:02  *** ABCRic [] has joined #openttd
18:27:03  <Yexo> you still didn't understand
18:27:11  <Yexo> the production increase/decrease is random
18:27:12  *** ZirconiumX [] has joined #openttd
18:27:29  <ZirconiumX> hello (no question mark)
18:27:48  <Yexo> the chance of a production increase is higher when the percent of transported cargo is higher
18:27:59  <IchGuckLive> as i see all industries except the providet ones are in or decresing AFTER 1 year
18:28:01  <Yexo> the percent of transported cargo depends on the cargo ration in your station
18:28:31  <IchGuckLive> thats shown in the station list
18:28:34  <Yexo> the very same wiki page I linked you to earlier has a section on how the station rating works
18:28:38  *** ar3k [] has joined #openttd
18:28:39  <dihedral> ZirconiumX, lol :-) hello
18:29:07  <ZirconiumX> Yexo, In NoAI, is it possible to set a penalty for crossing into the local authority's tiles?
18:29:08  <planetmaker> ho ZirconiumX
18:29:09  <Yexo> try to get it over at least 60% and if possible over 80%
18:29:28  <ZirconiumX> hello PM, and dihedral
18:29:53  <Yexo> ZirconiumX: yes, you can use AITile::IsWithinTownInfluence
18:30:01  <IchGuckLive> Yexo: i will try
18:30:03  <ZirconiumX> OK
18:32:11  <IchGuckLive> one more Question Halicopters are only going done on by one ,even on a 3 park area is this correct ?
18:32:33  <CIA-2> OpenTTD: rubidium * r21668 /trunk/ (7 files in 4 dirs): -Feature: command logging using the admin interface (dihedral)
18:32:47  <Rubidium> oh, only 18 minutes lag
18:33:26  <ZirconiumX> Rubidium: 18 minutes?!?
18:33:51  <planetmaker> commit to cia - message
18:34:59  * dihedral kicks CIA-2
18:34:59  <CIA-2> ow
18:35:10  *** JVassie_ [~James@] has joined #openttd
18:35:20  * ZirconiumX joins in
18:36:27  <dihedral> IchGuckLive, i think most answers to your questions are found at
18:36:42  <IchGuckLive> agree
18:37:08  <IchGuckLive> but you got to find them
18:38:33  <IchGuckLive> by
18:38:42  <IchGuckLive> and Thanks for the help
18:38:51  *** IchGuckLive [] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100423140709]]
18:39:03  * ZirconiumX sighs
18:39:42  *** JVassie [~James@] has quit [Ping timeout: 480 seconds]
18:39:58  <ZirconiumX> OMG 2991ms lag...
18:40:15  <Wolf01> I reached 48s
18:40:18  * ZirconiumX then kicks CIA-2 again
18:40:38  <ZirconiumX> 30secs
18:40:52  <ZirconiumX> ah, lag's back to normal
18:40:56  <ZirconiumX> 146ms
18:44:45  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
18:48:49  *** Mucht [] has quit [Remote host closed the connection]
18:49:08  <CIA-2> OpenTTD: translators * r21669 /trunk/src/lang/ (34 files in 2 dirs):
18:49:08  <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
18:49:08  <CIA-2> OpenTTD: simplified_chinese - 6 changes by ww9980
18:49:08  <CIA-2> OpenTTD: greek - 10 changes by fumantsu
18:50:27  <ZirconiumX> While (!pub_found) DeclareWarOnRussia (no offence intended)
18:54:11  *** Chicago_Rail_Authority [] has quit [Quit: Leaving]
19:08:00  *** jpx_ [] has quit []
19:17:44  *** Biolunar [] has joined #openttd
19:20:39  *** staN [] has quit [Ping timeout: 480 seconds]
19:21:15  *** fonsinchen [] has joined #openttd
19:27:22  *** Joni_ [] has quit [Read error: No route to host]
19:30:07  *** Joni- [~Joni-@] has joined #openttd
19:31:49  *** Wizzleby [] has quit [Remote host closed the connection]
19:33:15  *** Wizzleby [] has joined #openttd
19:35:48  *** Lakie [~Lakie@] has joined #openttd
19:51:34  *** `Fuco` [~dota.keys@] has joined #openttd
19:52:51  *** ZirconiumX [] has quit [Quit: ajax IRC Client]
19:58:32  *** Fuco [~dota.keys@] has quit [Ping timeout: 480 seconds]
20:18:46  *** Brianetta [] has joined #openttd
20:20:53  *** ar3kk [] has joined #openttd
20:22:23  *** ar3k [] has quit [Read error: Connection reset by peer]
20:24:30  *** ctibor [~quassel@] has quit [Read error: Operation timed out]
20:24:31  *** ctibor [~quassel@] has joined #openttd
20:25:00  *** einKarl [] has quit [Remote host closed the connection]
20:25:50  *** Vadtec [] has quit [Ping timeout: 480 seconds]
20:27:00  *** tokai|mdlx [] has quit [Read error: Operation timed out]
20:27:50  *** Muddy [] has quit [Ping timeout: 480 seconds]
20:30:29  *** tokai [] has joined #openttd
20:30:32  *** mode/#openttd [+v tokai] by ChanServ
20:38:03  *** Muddy [] has joined #openttd
20:38:12  *** Vadtec [] has joined #openttd
20:48:49  *** andythenorth [] has joined #openttd
20:48:57  <andythenorth> ho ho hi
20:49:07  <ABCRic> hi andythenorth
20:49:17  <Alberth> hi hi ho  andythenorth
21:04:53  *** tokai [] has quit [Quit: c('~' )o]
21:05:14  *** tokai [] has joined #openttd
21:05:17  *** mode/#openttd [+v tokai] by ChanServ
21:05:40  *** dageek [] has joined #openttd
21:11:40  *** cup_cup [] has joined #openttd
21:11:40  *** cup_cup [] has left #openttd []
21:24:05  *** dageek [] has quit [Quit: dageek]
21:26:02  *** xiong [] has joined #openttd
21:30:52  *** Chillosophy [] has joined #openttd
21:50:29  *** fonsinchen [] has quit [Remote host closed the connection]
21:55:01  *** Fast2 [] has joined #openttd
22:09:23  *** andythenorth [] has left #openttd []
22:11:13  *** mib_ed7e0c [] has joined #openttd
22:11:49  *** mib_ed7e0c [] has quit []
22:16:06  * Zuu feels bored
22:16:27  <Wolf01> me too :/
22:17:47  <Zuu> good then at least we can feel bored togeather :-)
22:20:17  <Zuu> Oh, I found a bug in my software. At least some excitement :-)
22:23:29  <Eddi|zuHause> you should declare it an easter egg ;)
22:24:25  <fjb> New year egg...
22:30:03  <Zuu> hehe, it was a repaint-error so you could use it to figure out how and when it repaints the screen. :-)
22:38:12  *** ABCRic_ [] has joined #openttd
22:40:23  *** ABCRic is now known as Guest2720
22:40:23  *** ABCRic_ is now known as ABCRic
22:43:32  *** Guest2720 [] has quit [Ping timeout: 480 seconds]
22:44:24  *** bryjen [~bryjen@] has quit [Quit: Quit]
22:55:37  <Wolf01> I converted my entire site in php this evening... it should demonstrate how bored i get :|
22:57:21  <Wolf01> *how much bored I can get... and I should avoid to speak like Yoda
22:58:41  <Eddi|zuHause> yoda speak like avoid you should
23:01:48  <dihedral> yes!
23:02:11  <__ln__> to what language did you convert your entire site in php into?
23:02:22  *** Brianetta [] has quit [Remote host closed the connection]
23:02:46  <Wolf01> from plain static html to php ;)
23:04:33  * Zuu has designed a new example for his junction simulator but pounders to draw different vehicle types with different colors or something ^^
23:07:50  <Zuu> Or maybe get some comic clipart images :-p
23:10:25  <__ln__> who can be blamed for the british narrator of mythbusters?
23:12:35  <peter1138> the whole thing went downhill when they introduced a team
23:13:31  *** ABCRic_ [] has joined #openttd
23:13:55  *** ABCRic is now known as Guest2722
23:13:55  *** ABCRic_ is now known as ABCRic
23:14:14  <__ln__> that's one way of putting it, but doesn't remove the fact that the british narrator is pretty annoying and apparently all the non-dubbing europe has to listen to him.
23:15:02  *** KouDy1 [] has joined #openttd
23:18:12  *** xiong [] has quit [Read error: Operation timed out]
23:18:38  *** Guest2722 [] has quit [Ping timeout: 480 seconds]
23:19:59  *** KouDy [~KouDy@] has quit [Ping timeout: 480 seconds]
23:20:30  *** dada_ [] has quit [Quit: Goodbyte]
23:23:25  *** Alberth [] has left #openttd []
23:28:24  <SmatZ> hmmmmmmmmmm
23:28:56  <SmatZ> anyone ever experienced that SIGFPE handler is ignored?
23:29:07  <SmatZ> and division by zero kills the app instead?
23:29:26  <SmatZ> I even have assert(handler == signal(SIGFPE, handler))
23:31:33  <SmatZ>
23:31:38  <SmatZ> and it crashes on line 7...
23:32:29  *** staN [] has joined #openttd
23:34:59  <SmatZ> the handler is not executed
23:35:49  <peter1138> heh
23:37:04  <__ln__> SmatZ: signal man page says: "Integer division by zero has undefined result.  On some architectures it will generate a  SIGFPE  signal."
23:38:15  <SmatZ> __ln__: it should generate SIGFPE on x86 (and it does according to gdb), just the handler is ignored and the app crashes
23:38:28  <SmatZ> I am not trying to find out what causes the misbehaviour
23:38:42  <SmatZ> because simple code doesn't crash...
23:38:55  <SmatZ> maybe it has something to do with SDL being used
23:39:25  <SmatZ> actually...
23:39:37  <SmatZ> maybe the signal is delivered to the SDL thread, that has no handler
23:39:39  <SmatZ> hmmm
23:40:00  <SmatZ> if that's possible
23:41:35  <__ln__> SmatZ: i guess you are aware that by default SDL sets its own signal handlers for things such as SIGSEGV?
23:42:18  <SmatZ> __ln__: I expect those are overriden if I call signal() and three lined below I do 1/0
23:42:22  <SmatZ> *lines
23:42:42  <__ln__> i expect that too
23:43:13  *** Kurimus [] has quit []
23:43:44  *** ABCRic [] has quit [Quit: The bad thing about quit messages is that you never know how people react to them.]
23:44:03  <SmatZ> hmm and it works now
23:44:09  <SmatZ> looks like the signal delivery is "random"
23:44:19  <SmatZ> (to which thread the signal is delivered)
23:44:34  <SmatZ> it makes me wonder how ottd's signal handling actually works...
23:44:45  <SmatZ> or, why it works, if it really works :P
23:46:09  <__ln__> the signal man page also says: "The effects of signal() in a multithreaded process are unspecified."
23:47:19  *** Fast2 [] has quit [Quit: <Nachricht>]
23:47:38  <SmatZ> __ln__: thanks :(
23:48:40  <SmatZ> __ln__: I remember reading something about that in the past, too
23:49:02  <SmatZ> then I wonder even more why we use signal() in openttd if it's very unreliable
23:49:13  <Mazur> I vote for the best sitcom line I heard this year for: "Sheldon is one lab-accident away from being a super-villain."
23:50:12  <Mazur> Although TBBT has some other strong contenders.
23:51:07  <SmatZ> it just took me time to realise you are in multithreaded environment when using SDL
23:51:42  <Terkhen> good night
23:51:54  <SmatZ> good night Terkhen
23:53:08  <dihedral> SmatZ, i noticed when playing with tcl and signals that a bunch of signals can be ignored
23:53:49  *** staN [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
23:54:03  * SmatZ tests signaction() now
23:54:14  <SmatZ> dihedral: I need to call the handler, not ignore the signals :)
23:55:30  <dihedral> i replaced handling of signals, and i was not as the signals were not even available
23:56:00  <dihedral> it was like the os did not even know them - it was not i who tried to ignore them :-P
23:58:06  <__ln__> SmatZ: may i recommend the PowerPC architecture where division by zero does not cause any signals nor aborting the app.
23:58:32  <SmatZ> __ln__: your recommendation has been taken into consideration :)
23:58:33  *** Cybertinus [] has quit [Remote host closed the connection]

Powered by YARRSTE version: svn-trunk