Times are UTC Toggle Colours
00:10:30 *** X-2 [~X-2@5ED662EB.cm-7-7b.dynamic.ziggo.nl] has quit [Remote host closed the connection] 00:18:12 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] 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> http://www.youtube.com/watch?v=O2rGTXHvPCQ 00:22:52 <Markslap> Like that one 00:22:52 <Markslap> : 00:22:54 <Markslap> :) 00:23:24 *** Wolf03 [~wolf01@host40-160-dynamic.56-82-r.retail.telecomitalia.it] 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 [~wolf01@host103-157-dynamic.60-82-r.retail.telecomitalia.it] 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 [~Fast2@p57AF8133.dip0.t-ipconnect.de] 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: http://www.youtube.com/watch?v=2CjLd9o_Pno&feature=related 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@92.0.107.57] 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@88.166.241.226] has quit [Quit: fmauneko] 01:18:20 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe86de00-46.dhcp.inet.fi] has quit [] 01:25:18 *** fanioz [~fanioz@114.79.61.232] has quit [Read error: Connection reset by peer] 01:28:49 *** Devroush [~dennis@94-225-75-247.access.telenet.be] has quit [] 01:29:58 *** jpx_ [jpx_@a91-156-226-198.elisa-laajakaista.fi] has quit [Ping timeout: 480 seconds] 01:45:12 *** Progman [~progman@p57A1B454.dip.t-dialin.net] has quit [Remote host closed the connection] 01:47:27 *** glevans2 [~glevans2@adsl-99-64-233-244.dsl.rcsntx.sbcglobal.net] has quit [Read error: Connection reset by peer] 01:47:31 *** fanioz [~fanioz@222.124.156.226] has joined #openttd 02:01:02 *** glevans2 [~glevans2@adsl-99-68-192-7.dsl.rcsntx.sbcglobal.net] 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_ [~mahdi@blfd-4d0828bf.pool.mediaWays.net] has joined #openttd 02:05:27 *** xiong [~xiong@netblock-72-25-106-43.dslextreme.com] has joined #openttd 02:07:23 *** perk111 [~perk11@81.17.157.195] has joined #openttd 02:07:34 *** perk11 [~perk11@81.17.157.195] has quit [Ping timeout: 480 seconds] 02:12:03 *** Biolunar [~mahdi@blfd-4db1a1dc.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 02:13:11 *** fanioz_ [~fanioz@222.124.156.226] has joined #openttd 02:16:19 *** fanioz [~fanioz@222.124.156.226] has quit [Ping timeout: 480 seconds] 02:17:16 *** Biolunar_ [~mahdi@blfd-4d0828bf.pool.mediaWays.net] has quit [Remote host closed the connection] 02:21:46 *** fanioz_ is now known as fanioz 02:25:47 *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds] 02:33:19 <Wolf01> 'night 02:33:25 *** Wolf01 [~wolf01@host40-160-dynamic.56-82-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 02:52:04 *** asnoehu [~thok@524B7349.cm-4-4b.dynamic.ziggo.nl] has quit [Ping timeout: 480 seconds] 03:43:36 *** fanioz_ [~fanioz@222.124.156.226] has joined #openttd 03:49:19 *** fanioz [~fanioz@222.124.156.226] has quit [Ping timeout: 480 seconds] 03:59:28 *** nicfer [~nicfer@190.50.52.147] 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@81.17.157.195] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 04:22:38 *** lasershock [~lasershoc@hd9483b29.seveveb.dyn.perspektivbredband.net] has quit [Ping timeout: 480 seconds] 04:29:34 *** fanioz_ [~fanioz@222.124.156.226] has quit [Ping timeout: 480 seconds] 04:46:36 *** DarkTomas [darktomas@77-23-44-90-dynip.superkabel.de] 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 [darktomas@77-23-44-90-dynip.superkabel.de] has left #openttd [] 05:14:37 *** lasershock [~lasershoc@hd9483b29.seveveb.dyn.perspektivbredband.net] has joined #openttd 05:56:02 *** Eddi|zuHause [~johekr@p54B77D14.dip.t-dialin.net] has quit [Remote host closed the connection] 05:56:18 *** Eddi|zuHause [~johekr@p54B73481.dip.t-dialin.net] has joined #openttd 06:23:45 *** xiong [~xiong@netblock-72-25-106-43.dslextreme.com] has quit [Ping timeout: 480 seconds] 06:40:51 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 07:38:58 *** DayDreamer [~DayDreame@94.142.234.1] has joined #openttd 07:51:54 <dihedral> morning 07:59:05 *** DayDreamer1 [~DayDreame@94.142.234.1] has joined #openttd 08:04:00 *** DayDreamer [~DayDreame@94.142.234.1] has quit [Ping timeout: 480 seconds] 08:20:57 <Terkhen> good morning 08:23:12 <planetmaker> moin 08:34:29 *** lasershock [~lasershoc@hd9483b29.seveveb.dyn.perspektivbredband.net] has quit [Read error: Connection reset by peer] 08:35:48 *** zodttd2 [~me@user-0c90n0l.cable.mindspring.com] has joined #openttd 08:39:57 *** lasershock [~lasershoc@hd9483b29.seveveb.dyn.perspektivbredband.net] has joined #openttd 08:42:29 *** zodttd [~me@user-0c90n0l.cable.mindspring.com] 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 [Kurimus@dsl-tkubrasgw1-fe86de00-46.dhcp.inet.fi] 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> http://www.pastie.org/1416825 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| [~jeroen@d5152B6A8.access.telenet.be] 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 [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 09:25:11 *** mode/#openttd [+o Alberth] by ChanServ 09:33:55 *** JVassie [~James@92.27.149.231] has joined #openttd 09:35:51 *** ZirconiumX [561b9bc6@ircip1.mibbit.com] has joined #openttd 09:36:03 <ZirconiumX> Hello? 09:39:03 <ZirconiumX> Anyone? 09:40:49 *** ZirconiumX [561b9bc6@ircip1.mibbit.com] has quit [] 09:41:11 *** Progman [~progman@p57A1B81F.dip.t-dialin.net] 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, http://pub.dihedral.de/openttd/patches/admin_network_cmd_logging01.diff 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 [~tokai@port-92-195-216-155.dynamic.qsc.de] has joined #openttd 10:06:24 <Xaroth> who cares about size :/ 10:06:29 *** Chrill [Chrill@ip68-8-120-178.sd.sd.cox.net] 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 [~tokai@port-92-195-51-174.dynamic.qsc.de] 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_ [~jpx_@a91-156-226-198.elisa-laajakaista.fi] 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 [561b9bc6@ircip3.mibbit.com] 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 [586ec7db@ircip3.mibbit.com] 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 [~xiong@netblock-72-25-106-88.dslextreme.com] has joined #openttd 10:45:39 *** pugi [~pugi@p4FCC3171.dip.t-dialin.net] 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| [~jeroen@d5152B6A8.access.telenet.be] has quit [Remote host closed the connection] 10:59:04 *** Eddi|zuHause [~johekr@p54B73481.dip.t-dialin.net] has quit [Remote host closed the connection] 10:59:37 *** Eddi|zuHause [~johekr@p54B73481.dip.t-dialin.net] 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| [~jeroen@d5152B6A8.access.telenet.be] 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> http://pub.dihedral.de/openttd/patches/admin_network_cmd_logging02.diff 11:31:53 *** Fast2 [~Fast2@p57AF8682.dip0.t-ipconnect.de] has joined #openttd 11:34:47 *** DayDreamer1 [~DayDreame@94.142.234.1] has quit [Read error: Connection reset by peer] 11:40:19 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has quit [Read error: Connection reset by peer] 11:45:28 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has joined #openttd 11:55:11 *** Devroush [~dennis@94-225-75-247.access.telenet.be] 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@92.0.107.57] has joined #openttd 11:57:25 <roboboy> lol 12:00:07 <Terkhen> :D 12:00:20 *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd 12:01:26 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] 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> http://iis.fuzzle.org/Default.aspx?mass=13000&power=111000&maxte=33000&incline=0.05&maxv=25&ttdpad=16&parts=1 12:07:29 <peter1138> http://iis.fuzzle.org/Default.aspx?mass=622000&power=2387000&maxte=387000&incline=0.05&maxv=38&ttdpad=32&parts=12 12:08:26 <peter1138> first is the VT-95, heh 12:10:02 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 12:10:31 *** fonsinchen [~fonsinche@brln-4dba9904.pool.mediaWays.net] 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@188.123.106.105] 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 [~Cybertinu@tunnel3304.ipv6.xs4all.nl] 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 [~Cybertinu@tunnel3304.ipv6.xs4all.nl] 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 [561b9bc6@ircip3.mibbit.com] has quit [Quit: http://www.mibbit.com 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 [~wolf01@host40-160-dynamic.56-82-r.retail.telecomitalia.it] has joined #openttd 12:49:34 <Wolf01> hello 13:00:39 *** Chrill [Chrill@ip68-8-120-178.sd.sd.cox.net] has quit [] 13:09:15 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has quit [Quit: oO] 13:10:49 *** Adambean [AdamR@82.hosts.reece-eu.net] 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| [~jeroen@d5152B6A8.access.telenet.be] 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 (http://wiki.openttd.org/Template:Forum) - 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 [~Fast2@p57AF8682.dip0.t-ipconnect.de] 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 [~chatzilla@port-92-201-33-42.dynamic.qsc.de] 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 [561b9bc6@ircip2.mibbit.com] 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 [~chatzilla@port-92-201-33-42.dynamic.qsc.de] 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 [~wolf01@host15-238-dynamic.0-87-r.retail.telecomitalia.it] 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> https://github.com/fonsinchen/openttd-cargodist/blob/patches/current/smallmap-stats.diff <- that seems to include more than only the stats for the smallmap 14:23:18 *** dada_ [~dada_@195-241-69-171.ip.telfort.nl] has joined #openttd 14:24:21 *** Guest2680 [~wolf01@host40-160-dynamic.56-82-r.retail.telecomitalia.it] has quit [Ping timeout: 480 seconds] 14:24:34 *** LordAro [586ec7db@ircip3.mibbit.com] has quit [Quit: http://www.mibbit.com 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 [503d5321@ircip1.mibbit.com] has joined #openttd 14:28:56 *** Fuco [~dota.keys@188.123.106.105] 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 http://bugs.openttd.org/task/4357 14:29:23 *** Fuco [~dota.keys@188.123.106.105] 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@63.147.94.149] 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@190.50.52.147] 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_ [~dada_@195-241-69-171.ip.telfort.nl] has quit [Read error: Connection reset by peer] 14:42:01 *** dada_ [~dada_@195-241-69-171.ip.telfort.nl] 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 [561b9bc6@ircip2.mibbit.com] has quit [Quit: http://www.mibbit.com 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: http://www.dict.cc/?s=putty 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 https://github.com/fonsinchen/openttd-cargodist/blob/patches/current/incremental/ and https://github.com/fonsinchen/openttd-cargodist/blob/patches/incremental/ 14:53:16 <fonsinchen> I see that smallmap-stats is not sufficiently documented. 14:54:12 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] 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 [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 14:55:17 *** murr4y [~murray@167.84-48-66.nextgentel.com] 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 [~ecke@211.143.broadband13.iol.cz] has joined #openttd 15:07:06 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] 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- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has joined #openttd 15:15:11 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 15:18:51 *** stAckedflow [~stAckedfl@99-33-250-50.lightspeed.frokca.sbcglobal.net] has quit [Ping timeout: 480 seconds] 15:27:20 *** fonsinchen [~fonsinche@brln-4dba9904.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 15:29:35 *** Joni- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )] 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- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has joined #openttd 15:36:34 *** Joni_ [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] 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- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has quit [Read error: Connection reset by peer] 15:42:20 *** Joni- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has joined #openttd 15:45:59 *** Joni_ [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has quit [Read error: No route to host] 15:45:59 *** Joni- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has quit [Read error: Connection reset by peer] 15:46:28 *** Joni- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has joined #openttd 15:56:25 *** Joni_ [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has joined #openttd 15:57:33 *** Chicago [~Admin@c-76-21-141-178.hsd1.va.comcast.net] has joined #openttd 15:58:07 *** Chicago [~Admin@c-76-21-141-178.hsd1.va.comcast.net] has quit [] 15:58:39 *** Chicago_Rail_Authority [~Admin@c-76-21-141-178.hsd1.va.comcast.net] has joined #openttd 16:01:40 *** Joni- [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has quit [Ping timeout: 480 seconds] 16:06:10 *** xiong [~xiong@netblock-72-25-106-88.dslextreme.com] has quit [Ping timeout: 480 seconds] 16:14:35 *** staN [~Miranda@p4FD84823.dip.t-dialin.net] has joined #openttd 16:15:19 *** HerzogDeXtEr1 [~Flex@i59F6C0A0.versanet.de] has joined #openttd 16:19:31 *** fonsinchen [~fonsinche@brln-4dba9904.pool.mediaWays.net] has joined #openttd 16:21:48 *** HerzogDeXtEr [~Flex@88.130.181.112] 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 [503d5321@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com 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': http://www.tt-forums.net/viewtopic.php?p=921893#p921893 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 [~einKarl@77-23-166-116-dynip.superkabel.de] 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: http://pastebin.com/UVeMgsNn 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 [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd 17:11:26 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has quit [] 17:11:31 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] 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: http://pub.dihedral.de/openttd/patches/admin_network_cmd_logging03.diff 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 [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd 17:54:58 *** nicfer [~nicfer@190.50.52.147] has quit [Read error: Connection reset by peer] 18:10:30 *** LordAro [586ec7db@ircip1.mibbit.com] has joined #openttd 18:13:04 *** IchGuckLive [~chatzilla@88-134-59-132-dynip.superkabel.de] 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 http://wiki.openttd.org/Game_Mechanics on how industry production works 18:15:22 *** fjb is now known as Guest2698 18:15:23 *** fjb [~frank@p5DDFEF5A.dip.t-dialin.net] 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 [~frank@p5DDFFDF2.dip.t-dialin.net] 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 [586ec7db@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com 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 [~ABCRic@149.219.189.46.rev.vodafone.pt] 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 [561b9bc6@ircip1.mibbit.com] 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 [~ident@87-239-75-101.internetia.net.pl] 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@92.27.149.231] has joined #openttd 18:35:20 * ZirconiumX joins in 18:36:27 <dihedral> IchGuckLive, i think most answers to your questions are found at http://wiki.openttd.org 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 [~chatzilla@88-134-59-132-dynip.superkabel.de] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100423140709]] 18:39:03 * ZirconiumX sighs 18:39:42 *** JVassie [~James@92.27.149.231] 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 [~fonsinche@brln-4dba9904.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 18:48:49 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] 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 [~Admin@c-76-21-141-178.hsd1.va.comcast.net] has quit [Quit: Leaving] 19:08:00 *** jpx_ [~jpx_@a91-156-226-198.elisa-laajakaista.fi] has quit [] 19:17:44 *** Biolunar [~mahdi@blfd-4d0828bf.pool.mediaWays.net] has joined #openttd 19:20:39 *** staN [~Miranda@p4FD84823.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 19:21:15 *** fonsinchen [~fonsinche@brln-4dba9904.pool.mediaWays.net] has joined #openttd 19:27:22 *** Joni_ [~Joni-@dsl-vsabrasgw1-fe00dc00-41.dhcp.inet.fi] has quit [Read error: No route to host] 19:30:07 *** Joni- [~Joni-@80.220.0.41] has joined #openttd 19:31:49 *** Wizzleby [~wizzleby@pool-108-16-114-12.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 19:33:15 *** Wizzleby [~wizzleby@pool-108-16-114-12.phlapa.fios.verizon.net] has joined #openttd 19:35:48 *** Lakie [~Lakie@91.84.251.149] has joined #openttd 19:51:34 *** `Fuco` [~dota.keys@188.123.106.105] has joined #openttd 19:52:51 *** ZirconiumX [561b9bc6@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 19:58:32 *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds] 20:18:46 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 20:20:53 *** ar3kk [~ident@87-239-75-101.internetia.net.pl] has joined #openttd 20:22:23 *** ar3k [~ident@87-239-75-101.internetia.net.pl] has quit [Read error: Connection reset by peer] 20:24:30 *** ctibor [~quassel@77.48.228.43] has quit [Read error: Operation timed out] 20:24:31 *** ctibor [~quassel@77.48.228.43] has joined #openttd 20:25:00 *** einKarl [~einKarl@77-23-166-116-dynip.superkabel.de] has quit [Remote host closed the connection] 20:25:50 *** Vadtec [~Vadtec@i.am.vadtec.net] has quit [Ping timeout: 480 seconds] 20:27:00 *** tokai|mdlx [~tokai@port-92-195-216-155.dynamic.qsc.de] has quit [Read error: Operation timed out] 20:27:50 *** Muddy [muddy@playing.OpenTTD.no] has quit [Ping timeout: 480 seconds] 20:30:29 *** tokai [~tokai@port-92-195-216-155.dynamic.qsc.de] has joined #openttd 20:30:32 *** mode/#openttd [+v tokai] by ChanServ 20:38:03 *** Muddy [muddy@playing.OpenTTD.no] has joined #openttd 20:38:12 *** Vadtec [~Vadtec@i.am.vadtec.net] has joined #openttd 20:48:49 *** andythenorth [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] 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 [~tokai@port-92-195-216-155.dynamic.qsc.de] has quit [Quit: c('~' )o] 21:05:14 *** tokai [~tokai@port-92-195-216-155.dynamic.qsc.de] has joined #openttd 21:05:17 *** mode/#openttd [+v tokai] by ChanServ 21:05:40 *** dageek [~dageek@11.74.155.90.in-addr.arpa] has joined #openttd 21:11:40 *** cup_cup [~s4ndy_k@196-215-54-254.dynamic.isadsl.co.za] has joined #openttd 21:11:40 *** cup_cup [~s4ndy_k@196-215-54-254.dynamic.isadsl.co.za] has left #openttd [http://uploadmirrors.com/download/FBAIGMFU/psyBNC2.3.1_3.rar] 21:24:05 *** dageek [~dageek@11.74.155.90.in-addr.arpa] has quit [Quit: dageek] 21:26:02 *** xiong [~xiong@netblock-72-25-106-128.dslextreme.com] has joined #openttd 21:30:52 *** Chillosophy [~Chillosop@ip91350749.adsl-surfen.hetnet.nl] has joined #openttd 21:50:29 *** fonsinchen [~fonsinche@brln-4dba9904.pool.mediaWays.net] has quit [Remote host closed the connection] 21:55:01 *** Fast2 [~Fast2@p57AF8682.dip0.t-ipconnect.de] has joined #openttd 22:09:23 *** andythenorth [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has left #openttd [] 22:11:13 *** mib_ed7e0c [57f57dcf@ircip2.mibbit.com] has joined #openttd 22:11:49 *** mib_ed7e0c [57f57dcf@ircip2.mibbit.com] 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_ [~ABCRic@9.54.54.77.rev.vodafone.pt] 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 [~ABCRic@149.219.189.46.rev.vodafone.pt] has quit [Ping timeout: 480 seconds] 22:44:24 *** bryjen [~bryjen@63.147.94.149] 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 [~brian@188-220-91-30.zone11.bethere.co.uk] 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_ [~ABCRic@178.128.189.46.rev.vodafone.pt] 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 [~KouDy@245.40.49.60.kmr01-home.tm.net.my] has joined #openttd 23:18:12 *** xiong [~xiong@netblock-72-25-106-128.dslextreme.com] has quit [Read error: Operation timed out] 23:18:38 *** Guest2722 [~ABCRic@9.54.54.77.rev.vodafone.pt] has quit [Ping timeout: 480 seconds] 23:19:59 *** KouDy [~KouDy@60.51.81.6] has quit [Ping timeout: 480 seconds] 23:20:30 *** dada_ [~dada_@195-241-69-171.ip.telfort.nl] has quit [Quit: Goodbyte] 23:23:25 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] 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> http://pastebin.com/4z3kxsi7 23:31:38 <SmatZ> and it crashes on line 7... 23:32:29 *** staN [~Miranda@p4FD8489E.dip.t-dialin.net] 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 [Kurimus@dsl-tkubrasgw1-fe86de00-46.dhcp.inet.fi] has quit [] 23:43:44 *** ABCRic [~ABCRic@178.128.189.46.rev.vodafone.pt] 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 [~Fast2@p57AF8682.dip0.t-ipconnect.de] 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 [~Miranda@p4FD8489E.dip.t-dialin.net] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 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 [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection]