Back to Home / #openttd / 2009 / 10 / Prev Day | Next Day
#openttd IRC Logs for 2009-10-07

---Logopened Wed Oct 07 00:00:49 2009
01:13-!-lugo [~lugo@mgdb-4db87a0b.pool.mediaWays.net] has joined #openttd
01:18-!-Zahl [~Zahl@g226152205.adsl.alicedsl.de] has quit [Quit: *schiel*]
01:37-!-Polygon [~Poly@x0581b.wh7.tu-dresden.de] has joined #openttd
01:51-!-Splex [~splex@121.165.245.76] has quit [Quit: Leaving]
02:05-!-Splex [~splex@121.165.245.76] has joined #openttd
02:06-!-Polygon [~Poly@x0581b.wh7.tu-dresden.de] has quit [Quit: Flieht, ihr Narren!]
02:18-!-Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd
02:32-!-Phoenix_the_II [ralph@j104246.upc-j.chello.nl] has joined #openttd
02:38-!-thepalm [~chatzilla@121.210.80.70] has joined #openttd
02:40-!-Doorslammer [Doorslamme@PIPP-p-203-54-115-147.prem.tmns.net.au] has joined #openttd
02:42<Rubidium>morning, yup it's early
02:50-!-TheMask96 [martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
02:55-!-TheMask96 [martijn@greed.vhost.ne2000.nl] has joined #openttd
02:56-!-hickop [~hickop@AGrenoble-257-1-19-53.w86-194.abo.wanadoo.fr] has quit [Quit: Lost terminal]
03:09-!-Nickman_87 [~nick.defr@d515370C5.access.telenet.be] has joined #openttd
03:31-!-Fuco [~a@fuco.sks3.muni.cz] has joined #openttd
03:32-!-Muxy [~Muxy@nt2001.opsio.fr] has joined #openttd
03:43-!-ecke [~ecke@pc150-39.upce.cz] has joined #openttd
03:45-!-thepalm [~chatzilla@121.210.80.70] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
03:48-!-fonsinchen [~alve@BAEad17.bae.pppool.de] has joined #openttd
04:01-!-ecke [~ecke@pc150-39.upce.cz] has quit [Ping timeout: 480 seconds]
04:10-!-thepalm [~chatzilla@121.210.80.70] has joined #openttd
04:25<CIA-4>OpenTTD: rubidium * r17735 /trunk/src/ (cargopacket.cpp cargopacket.h):
04:25<CIA-4>OpenTTD: -Codechange: update the cache one inserting/removing CargoPackets from the
04:25<CIA-4>OpenTTD: CargoList via Append/Truncate instead of rebuilding the whole cache. For Append
04:25<CIA-4>OpenTTD: this changes the O(n) cache rebuild into a O(1) cache update. For Truncate no
04:25<CIA-4>OpenTTD: temporary list is needed anymore (based on patch by fonsinchen)
04:28-!-Progman [~progman@p57A1FC2D.dip.t-dialin.net] has joined #openttd
04:31<fonsinchen>Oh, you're merging the cargolist patch. That's nice, thanks.
04:31<CIA-4>OpenTTD: rubidium * r17736 /trunk/src/ (cargopacket.cpp cargopacket.h):
04:31<CIA-4>OpenTTD: -Codechange [FS#3135]: rewrite CargoList::MoveTo; don't require the secondary
04:31<CIA-4>OpenTTD: list, use cache updates instead of rebuilds. This is usually faster because of
04:31<CIA-4>OpenTTD: primarily gradual loading that only moves a (small) part of the cargo each time.
04:31<CIA-4>OpenTTD: Based on patch by fonsinchen.
04:32<Rubidium>pff... finally
04:33<Rubidium>well, have been working on that patch for like 6 hours
04:34<Rubidium>validating it is right, splitting in small pieces that make sense, testing the effect of some changes and whether that effect is benificial
04:35<Spoons>Grats? ;p
04:35<Rubidium>is that like iPhone and Gmail?
04:36<Rubidium>i.e. if Apple would release it it would be called iRats
04:52<thepalm>I am trying to backport one of my patches from trunk to 0.7.3 but tortoisesvn keeps complaining that "the patch seems updated, the file line *** and the patchline *** do not match"
04:52-!-th1ngwath [~thingwath@r2ap232.net.upc.cz] has joined #openttd
04:54<thepalm>is there any way around this?
04:54<thepalm>the patch doesn't apply cleanly using commandline patch and Im not sure what else to try
04:59-!-thingwath [~thingwath@r2ap232.net.upc.cz] has quit [Ping timeout: 480 seconds]
05:00<Spoons>Apply the patch to trunk then switch?
05:02<thepalm>ill try that
05:06-!-sdafsdf [LadyHawk@78-105-102-180.zone3.bethere.co.uk] has joined #openttd
05:06-!-LadyHawk [LadyHawk@78-105-102-180.zone3.bethere.co.uk] has quit [Read error: Connection reset by peer]
05:06-!-sdafsdf is now known as LadyHawk
05:09<Spoons>At least that way you'll get illogical merge problems instead of illogical patch problems, the first are more common so easier to google. =p
05:09-!-Spoons is now known as FauxFaux
05:15<thepalm>seems to be working
05:17<fonsinchen>Rubidium: I can try to split my patches in smaller pieces in the future to make your life easier, but I'll have to find a practical way of managing them. If you've seen the diagram of my git branches in the cargodist thread you probably can imagine the problem. I can't do much about the validation I guess. And how did you test if it's beneficial?
05:20-!-Yexo_ [~Yexo@38-88-ftth.onsneteindhoven.nl] has joined #openttd
05:25<Rubidium>fonsinchen: with patch queue, but that seems quite troublesome with so many branches
05:26<Rubidium>testing happened with big savegames and small, reviewing code that called it, reviewing the actual changes etc
05:27-!-Yexo [~Yexo@38-88-ftth.onsneteindhoven.nl] has quit [Ping timeout: 480 seconds]
05:29<fonsinchen>yes, that's what I did, too. Do you have some special method of measuring performance? I used a rather simple wall clock method: Load a game that runs slow, see how long it takes to run a game month, compare with other version and so on.
05:29<fonsinchen>That didn't show much of a benefit, though.
05:30<Rubidium>true, the benefit is very small in most cases
05:43-!-ecke [~ecke@pc150-39.upce.cz] has joined #openttd
05:49-!-ecke [~ecke@pc150-39.upce.cz] has quit [Read error: Connection reset by peer]
05:55-!-Xaroth_ is now known as Xaroth
05:59-!-StM [~StM-freen@ip4da75f1e.direct-adsl.nl] has joined #openttd
06:06-!-ecke [~ecke@pc150-39.upce.cz] has joined #openttd
06:07-!-sulai [~chatzilla@p5B2B7A1A.dip.t-dialin.net] has joined #openttd
06:07<sulai>hi there
06:08<sulai>is the bug about loading save games still in trunk? if yes, which revision was the last known working?
06:09-!-Belugas [~belugas@216.191.111.238] has quit [Ping timeout: 480 seconds]
06:09<Noldo>hg.openttd.org and bugs.openttd.org are the best sources
06:10-!-Belugas [~belugas@216.191.111.238] has joined #openttd
06:10-!-mode/#openttd [+o Belugas] by ChanServ
06:16<sulai>oh it's been removed 11 hours ago, thanks Noldo
06:26-!-ecke [~ecke@pc150-39.upce.cz] has quit [Read error: Connection reset by peer]
06:37-!-Xaroth_ [~Xaroth@86.92.135.101] has joined #openttd
06:37-!-Muxy [~Muxy@nt2001.opsio.fr] has quit [Remote host closed the connection]
06:39-!-Muxy [~Muxy@nt2001.opsio.fr] has joined #openttd
06:44-!-Xaroth [~Xaroth@86.92.135.101] has quit [Ping timeout: 480 seconds]
06:51-!-sulai [~chatzilla@p5B2B7A1A.dip.t-dialin.net] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
06:53-!-tux_mark_5 [~kvirc@lan-84-240-29-163.vln.skynet.lt] has joined #openttd
06:53-!-Yexo_ is now known as Yexo
07:04<Noldo>Yexo: are NoAIs run only on the server?
07:04<Yexo>yes
07:05<Noldo>do they se the same DoCommand structure as normal clients?
07:05<Yexo>yes
07:06<Noldo>if it can handle the asynronism coming from humans, wouldn't it be able to handle asuncronism coming from AIs running in different threads?
07:06<SmatZ>there is no asynchronism from humans
07:07<SmatZ>(sorry, I couldn't let Yexo answer anything else that "yes") :)
07:08<TrueBrain>we humans do threading :) And FAST!
07:08<Yexo>SmatZ: still "yes" would be correct, because of the "_if_ it can handle..." :p
07:08<SmatZ>Yexo: right :)
07:09<SmatZ>maybe it would work if commands in test mode didn't use global variables and commands in exec mode were queued the same way as humans; are
07:10<TrueBrain>SmatZ: commands are queued, aren't they? :) (for networking, that is)
07:10<SmatZ>like, AI executing "add new sign" could cause crash in other AI that is just getting the sign list
07:10<SmatZ>TrueBrain: yeah :) but not for AIs
07:10<SmatZ>I thought I said that
07:10<Yexo>if you just test a command (hold shift) the command isn't queued
07:10<TrueBrain>lol, that is what I meant .. I thought AIs queue them too
07:10<SmatZ>hmmm
07:10<TrueBrain>(in exec of course)
07:10<SmatZ>ok
07:10<SmatZ>right
07:11<TrueBrain>well, in SP not of course
07:11<SmatZ>right
07:11<SmatZ>now
07:11*SmatZ runs away in shame
07:11<TrueBrain>why?
07:11<TrueBrain>stop doing that :(
07:11<SmatZ>I shouldn't talk about things I think I know about, but I don't :-p
07:11<TrueBrain>I do the same :p
07:11<SmatZ>it results in shame
07:11<SmatZ>:)
07:11<TrueBrain>we would need to check the code :)
07:11<Yexo><SmatZ> maybe it would work if commands in test mode didn't use global variables and commands in exec mode were queued the same way as humans; are <- that is completely correct
07:12<TrueBrain>see ;)
07:12<Yexo>but don't forget that static variables in functions are globals too
07:12<dihedral>TrueBrain, define 'we' :-P
07:12<Yexo>so also functions like OTTD2SFS should be fixed
07:12<TrueBrain>Yexo: fix suggest it is broken ;)
07:12<Yexo>s/fix/chang/
07:13<SmatZ>if the only needed change was a mutex in DoCommandP, it would be easy :)
07:13<dihedral>:-P
07:13<TrueBrain>but this boils down to: make OpenTTD threaded :p
07:14<Yexo>several noai api functions use _current_company
07:14-!-Grelouk [~Grelouk@122.72.200-77.rev.gaoland.net] has joined #openttd
07:15<TrueBrain>hmm ... NoAI doesn't even queue in networking .. not via the normal queue anyway
07:16<TrueBrain>it is queued in the server-queue
07:16<TrueBrain>sucks
07:16*Rubidium wonders in what way humans, or at least their interaction, with OpenTTD is more async than for AIs
07:16<TrueBrain>so SmatZ, you are correct, and I run away in shame now ;)
07:17-!-tux_mark_5 [~kvirc@lan-84-240-29-163.vln.skynet.lt] has quit [Remote host closed the connection]
07:17<Rubidium>the only thing is that humans 'clone' a (small) part of the game state
07:17<TrueBrain>AIs can too :)
07:18<Rubidium>and they can only look at that part. AIs can look at *all* the game state
07:18<Rubidium>TrueBrain: AIs can, in one tick, look at all game state. A human only a small subsection of the state
07:18<TrueBrain>very true
07:18<TrueBrain>so AIs cheat!
07:18<Noldo>:D
07:19<Rubidium>so probably AIs can be made async, but only if they have to request certain information via a callback taking at least a tick
07:19<Rubidium>which would make the AIs kinda incredibly complex
07:19<StM>And for a AI is it a LOT harder to interact with the world while for a human its very easy
07:20<Rubidium>it isn't easy for a human; humans need to do image analysis, OCR, etc. AIs can query the information directly
07:21<StM>true but humans do that extreme fast :>
07:21<TrueBrain>not as fast as you might think :)
07:21<Rubidium>only the difficulty is mostly hidden from the humans
07:21<StM>true
07:21-!-tux_mark_5 [~kvirc@lan-84-240-29-163.vln.skynet.lt] has joined #openttd
07:21<Noldo>Rubidium: can you give examples about 'certain information'
07:21<Noldo>or is it everything
07:22<StM>but finding a path cost me maybe 1-2 seconds between 2 points, then build it
07:22<Rubidium>Noldo: basically it's everything except current date/bank balance (which a human always sees)
07:22<StM>For a AI is that a lot more complicated
07:23-!-KenjiE20 [~KenjiE20@92.20.211.211] has joined #openttd
07:23<Rubidium>but *you* do pattern matching/use heuristics, an AI does not; it has to precisely calculate the best outcome
07:23<StM>true :)
07:24<dihedral><TrueBrain> not as fast as you might think :) <- hehehe
07:25<dihedral>not as fast as he imagined it might be, or really not as fast as he might think :-P
07:26-!-KenjiE20 [~KenjiE20@92.20.211.211] has quit []
07:27-!-KenjiE20 [~KenjiE20@92.21.50.189] has joined #openttd
07:28<TrueBrain>Rubidium: you can also make those points of query critical, then you don't need a callback :) But I guess then we can just call it fibers, as the real use of threads goes down the drain :p
07:28<TrueBrain>(well, everything inside the VM is threaded, any call outside (via the API) would not)
07:31<Rubidium>TrueBrain: but effectively it's the same; it has to wait for data
07:32<TrueBrain>it depends very much on how much CPU it takes to do something with that data
07:32<TrueBrain>and it only has any benefit if you have 2+ AIs
07:33-!-thepalm [~chatzilla@121.210.80.70] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
07:33<TrueBrain>like now, you handle AIs, just instead of 1 at the time, you run them all at once, synchronizing data when it goes over the border (the API)
07:33<TrueBrain>if you then queue DoCommands 1 tick, you can even avoid the critical section part, as AIs then only read, and writing they do in their own thread/stack .. well .. with the exception of OTTD2FS what Yexo pointed out :p
07:47-!-glx [glx@2a01:e35:2f59:c7c0:972:6243:da38:cc4d] has joined #openttd
07:47-!-mode/#openttd [+v glx] by ChanServ
07:48-!-tokar [~tokar@othala.n7mm.org] has quit [Remote host closed the connection]
07:48-!-tokai [~tokai@p5B2B07C1.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
07:50-!-tokai [~tokai@p5B2B08CB.dip0.t-ipconnect.de] has joined #openttd
07:50-!-mode/#openttd [+v tokai] by ChanServ
07:50-!-Coco-Banana-Man [~Stephan.D@p5B2DDE50.dip.t-dialin.net] has joined #openttd
08:14-!-Dred_furst [~Dred@cpc3-pool3-0-0-cust999.sotn.cable.ntl.com] has joined #openttd
08:16-!-Biolunar [mahdi@blfd-4db03bd7.pool.mediaWays.net] has joined #openttd
08:23<StM>Has somebody already created a simple travelling Salesman implementation build in squirrel? :) For ~ 10 city's max
08:23<SmatZ>@calc 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2
08:23<@DorpsGek>SmatZ: 3628800
08:23<StM>I know :>
08:23-!-Chruker [~no@port113.ds1-vj.adsl.cybercity.dk] has joined #openttd
08:24<StM>But i'm afraid squirrel is too slow for it
08:25<SmatZ>you have ~20000 ops per tick
08:25<SmatZ>@calc 2628800 / 20000
08:25<@DorpsGek>SmatZ: 131.44
08:25<StM>And how long is a tick? :)
08:25<SmatZ>131 ticks, ~2 game days, if each iteration needed 1 op
08:26<StM>yes but they need a LOT more :(
08:26-!-Fast2 [~Fast2@p57AF9FEA.dip0.t-ipconnect.de] has joined #openttd
08:26<Muxy>@calc 10!
08:26<@DorpsGek>Muxy: Error: unexpected EOF while parsing (<string>, line 1)
08:28<StM>And i'm afraid this will be a little bit above my C skills :p
08:29-!-welshdragon [~markjones@147.143.254.214] has joined #openttd
08:29<SmatZ>:)
08:46-!-Eddi|zuHause [~johekr@p54B77DA6.dip.t-dialin.net] has quit [Remote host closed the connection]
08:47-!-Eddi|zuHause [~johekr@p54B77DA6.dip.t-dialin.net] has joined #openttd
08:49<Yexo>SmatZ: default is only 10.000 ops per tick
08:49<Yexo>and the first result was _3_.xxx, not _2_.xxx
08:50<SmatZ>[14:49:54] <Yexo> and the first result was _3_.xxx, not _2_.xxx <== what result?
08:50<Yexo><@DorpsGek> SmatZ: 3628800
08:50<Yexo><SmatZ> @calc 2628800 / 20000
08:50<SmatZ>ah
08:50<SmatZ>:)
08:51<Yexo>assuming 10 ops per route (very optimistic), it would be
08:51<SmatZ>[14:25:38] <DorpsGek> SmatZ: 131.44 <== I thought this one
08:51<Yexo>@calc 368800 * 10 / 10000 / 74
08:51<@DorpsGek>Yexo: 4.98378378378
08:51<Yexo>nearly 5 days
08:51<Yexo>@calc 3628800 * 10 / 10000 / 74
08:51<@DorpsGek>Yexo: 49.0378378378
08:51<Yexo>oh, 50 days :p
08:52<StM>:( :p
08:52<StM>for some simple roads :p
08:52<Yexo>just take 5 cities max :)
08:52<Yexo>or don't compute an exact best but do with an approximation
08:53<StM>yea but the math for a suboptimal route is VERY hard :)
08:53<SmatZ>well
08:54<Eddi|zuHause>TSP has really good heuristics
08:55<SmatZ>you don't have exact data anyway
08:55<SmatZ>there can be hill between A and B
08:55<SmatZ>or lake
08:55<StM>:X true
08:55<StM>ARG! :p
08:56<SmatZ>:)
08:57<StM>Hmm maybe can i limit the options
08:57<StM>for a city are only the 2 or 3 who are the most near interesting
09:05<Eddi|zuHause>there are algorithms for calculating "neighbour" relationship
09:07<StM>You dont want to know how much headache i already have :D
09:07<Eddi|zuHause>hey, those are already solved problems... just look up the solutions and implement them :p
09:10<StM>Thats only a reason for more headache :>
09:11-!-Fast2 [~Fast2@p57AF9FEA.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
09:17-!-Muxy [~Muxy@nt2001.opsio.fr] has quit [Quit: Back to the Goulp]
09:18<De_Ghosty>drink more wateR?
09:21-!-luckz [~lkz@luckz.de] has joined #openttd
09:24-!-Chris_Booth [~Chris_Boo@82-32-243-15.cable.ubr11.newt.blueyonder.co.uk] has joined #openttd
09:28-!-Nickman_87 [~nick.defr@d515370C5.access.telenet.be] has quit [Ping timeout: 480 seconds]
09:42<StM>If i do a keepBelowValue and a keepTop on a list, will the top then overrule the keepBelowValue?
09:43<StM>it looks it doesnt, he will really remove the other values if i'm right? :)
09:50-!-Jhs [~Jhs4@214.80-202-210.nextgentel.com] has joined #openttd
09:54<Yexo>KeepBelowValue removes all items with a value higher than the parameter
09:54<Yexo>if after that you do KeepTop, only the first x items will be kept
09:54<StM>:)
09:57-!-Nickman_87 [~nick.defr@137.44-245-81.adsl-dyn.isp.belgacom.be] has joined #openttd
09:57-!-Nickman_87 is now known as Nickman87
10:18-!-Zahl [~Zahl@g226152205.adsl.alicedsl.de] has joined #openttd
10:45-!-Chris_Booth is now known as Guest500
10:45-!-Chris_Booth [~Chris_Boo@82-32-243-15.cable.ubr11.newt.blueyonder.co.uk] has joined #openttd
10:51-!-Guest500 [~Chris_Boo@82-32-243-15.cable.ubr11.newt.blueyonder.co.uk] has quit [Ping timeout: 480 seconds]
10:53<@Belugas>hello
10:56-!-sulai [~chatzilla@p5B2B7A1A.dip.t-dialin.net] has joined #openttd
11:05-!-Biolunar [mahdi@blfd-4db03bd7.pool.mediaWays.net] has quit [Quit: gn8]
11:10-!-Lakie [~Lakie@91.84.251.149] has joined #openttd
11:17-!-Singaporekid [~notme@cm52.psi148.maxonline.com.sg] has joined #openttd
11:20<_ln>you could say that
11:23<Nickman87>Anyone know if it is possible to add internal padding to an WWT_EDITBOX?
11:29<Nickman87>I want to lower the text inside it by one pixel
11:30<Nickman87>Rubidium, you fixed the savegames I see? :)
11:36-!-sulai [~chatzilla@p5B2B7A1A.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
11:43-!-Polygon [~Poly@x0581b.wh7.tu-dresden.de] has joined #openttd
11:48-!-Dred_furst [~Dred@cpc3-pool3-0-0-cust999.sotn.cable.ntl.com] has quit [Read error: Connection reset by peer]
11:52-!-oskari89 [~oskari89@212-149-205-119.bb.dnainternet.fi] has joined #openttd
11:53-!-Fast2 [~Fast2@p57AF9FEA.dip0.t-ipconnect.de] has joined #openttd
12:01<SmatZ>/me was in bed all day long... hope I will get better for tommorow :)
12:04<FauxFaux>After spending a whole day in bed, pretty much everything is worse.
12:05<SmatZ>:(
12:08-!-_ln [~lanurmi@dyn-xdsl-83-150-113-243.nebulazone.fi] has quit [Quit: reboot]
12:15*Belugas would LOVE to spend all day in bed...
12:16<@Belugas>if nit possible, can i at least get out AFTER 6:00am?
12:16<@Belugas>ppleeeeeaaaase???
12:18-!-frosch123 [~frosch@frnk-590fddd5.pool.mediaWays.net] has joined #openttd
12:23-!-Pikka [PikkaBird@58.173.248.50] has joined #openttd
12:23<Pikka>Singaporekid what have you done
12:23-!-Doorslammer [Doorslamme@PIPP-p-203-54-115-147.prem.tmns.net.au] has quit [Ping timeout: 480 seconds]
12:26-!-Doorslammer [Doorslamme@PIPP-p-203-54-229-129.prem.tmns.net.au] has joined #openttd
12:29<Singaporekid>who knows
12:30<Pikka>okay, well don't do it again
12:35-!-Zuu [~Zuu@c-75fae253.025-58-6e6b702.cust.bredbandsbolaget.se] has joined #openttd
12:36-!-SHADOW-XIII [Miranda@cpc2-lewi3-0-0-cust462.bmly.cable.ntl.com] has joined #openttd
12:36<SHADOW-XIII>@all: hi
12:37<Pikka>hello
12:37<SHADOW-XIII>how is going ?
12:38<Pikka>it's going fine
12:38-!-Prof_Frink [~proffrink@5ad1ee01.bb.sky.com] has quit [Ping timeout: 480 seconds]
12:39<SHADOW-XIII>i finished my uni and looking for it job now ... :/
12:41-!-Prof_Frink [~proffrink@5ad683fa.bb.sky.com] has joined #openttd
12:43-!-SHADOW-XIV [Miranda@cpc2-lewi3-0-0-cust462.bmly.cable.ntl.com] has joined #openttd
12:43<SHADOW-XIV>is ourdge around ?
12:44<Pikka>orudge gets around round round...
12:45-!-Progman [~progman@p57A1FC2D.dip.t-dialin.net] has quit [Remote host closed the connection]
12:47-!-SHADOW-XIII [Miranda@cpc2-lewi3-0-0-cust462.bmly.cable.ntl.com] has quit [Ping timeout: 480 seconds]
12:48<Singaporekid>orudge is round?
12:49<Pikka>yes
12:51<SHADOW-XIV>anyone here can send google wave invitations ?
12:52<StM>nope :(
12:52<SHADOW-XIV>suppose not
12:53-!-Jhs [~Jhs4@214.80-202-210.nextgentel.com] has quit [Quit: Leaving]
13:03<Pikka>hmm
13:03<Pikka>orude is just post on the forums
13:03<Pikka>and I am to bed
13:03<Pikka>g'night
13:03-!-Pikka [PikkaBird@58.173.248.50] has quit []
13:13<SHADOW-XIV>anyone from UK oriented at least a bit about job market ?
13:13-!-SHADOW-XIV is now known as SHADOW-XIII
13:15-!-Terkhen [~terkhen@44.69.220.87.dynamic.jazztel.es] has joined #openttd
13:15<Terkhen>hello
13:16<SHADOW-XIII>hi
13:17*SHADOW-XIII slaps orudge around a bit with a large trout
13:18<Prof_Frink>SHADOW-XIII: He's in t'shower.
13:19<Rubidium>SHADOW-XIII: why do you need orudge?
13:19<SHADOW-XIII>30 min?
13:20<SHADOW-XIII>he isnt a girl :)
13:20<SHADOW-XIII>i need to ask him thing
13:22<Rubidium>if you need to ask him something ask it, don't ask meta questions like "can I ask questions" or "is X here" when that person is online
13:22<Rubidium>just ask the question
13:23<SHADOW-XIII>apparently he is here but he is not :)
13:23<@Belugas>or use a very nice feature given to you by the forums: PM ;)
13:23<Rubidium>for what it's worth, I usually ignore the 'is Rubidium here' questions
13:24<SHADOW-XIII>Owen does not from what I know :P
13:25<SHADOW-XIII>maybe someone can give me his opinion
13:25<SHADOW-XIII>cuz i am looking for a job right now and i fund a company that guarantee job 30k/year after passing 4 certificates (ncomp,2x microsoft and ccna cisco)
13:25<SHADOW-XIII>fund = *found
13:26<SHADOW-XIII>but this training so damn expensive, otoh smells fishy like a scam but who knows
13:26<StM>Do you need to pay it on your own?
13:26<StM>Dont do it :)
13:27<Prof_Frink>Anyone guaranteeing a job in the current economic climate is lying.
13:27<StM>yea
13:28<SHADOW-XIII>yh, pay on my own
13:28<StM>dont do it :)
13:30<SHADOW-XIII>it looked like lots of ppl coming there for it so I took a look, seen some m$ certificates there and all looks nice, could always check out those cert. in M$ .... ayway, that's way lot of money
13:32<SHADOW-XIII>just wanted to ask Owen is it normally look like that or it's not normal
13:34<@Belugas>do you have to pay them for the courses and all? if so, don't
13:35*Rubidium thinks Owen doesn't know much about those things
13:36<CIA-4>OpenTTD: rubidium * r17737 /trunk/src/ (4 files in 2 dirs): -Codechange: remove the chat window when you were chatting with someone who lost his/her connection or when you were team chatting and moved out of the company.
13:38-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
13:38<SHADOW-XIII>4 courses nearly 10k, can be done via deposit 3k + rest over paying next 12 months
13:40<frosch123>you never have to pay to get a job. 10k is a silly amount for a company; if they really want to employ you, they would pay it
13:40<SHADOW-XIII>suppose so
13:43-!-bb10 [~nn@dhcp-077-249-031-191.chello.nl] has joined #openttd
13:43<fonsinchen>in cargopacket.cpp:156 you're still creating a CargoList tmp which you don't use anywhere.
13:45<CIA-4>OpenTTD: translators * r17738 /trunk/src/lang/russian.txt:
13:45<CIA-4>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-4>OpenTTD: russian - 1 changes by Lone_Wolf
13:45<Rubidium>hmm, that the compiler doesn't warn about that
13:45<SmatZ>my words :-p
13:46*SHADOW-XIII pre-ordered Windows 7
13:46<Rubidium>poor you
13:46<SmatZ>hehe
13:47<CIA-4>OpenTTD: rubidium * r17739 /trunk/src/cargopacket.cpp: -Cleanup: compiler didn't warn about an unused variable, fonsinchen did
13:48<Ammler>wasn't there once a discussion about png support from grfcodec?
13:49<Rubidium>yes
13:49<Rubidium>wasn't there once an implementation of that?
13:49<Rubidium>no
13:49<fonsinchen>:)
13:49<SHADOW-XIII>i had Win 7 beta and got Win 7RC and runs great on my laptop (which lost Win Vista during hdd failure)
13:49<Ammler>Rubidium: just because "someone" didn't or not possible?
13:50<Rubidium>there is, AFAIK, no reason why it's not possible
13:50<SHADOW-XIII>my first Windows (box) ... preordered cost 80 pounds less than normal price
13:50<Ammler>was dalestan involved in that discussion?
13:51<Rubidium>don't know
13:51<Rubidium>guess he was: http://www.tt-forums.net/viewtopic.php?f=26&t=26846
13:52<Ammler>mäh :-P
13:58-!-Zahl_ [~Zahl@e181182150.adsl.alicedsl.de] has joined #openttd
13:58-!-Zahl [~Zahl@g226152205.adsl.alicedsl.de] has quit [Remote host closed the connection]
13:58-!-Zahl_ is now known as Zahl
14:10<Nickman87>Ammler, you tried my patch yet? :D
14:11<Ammler>no, I wait for next and text all 3 together :-P
14:12<Nickman87>three patches? What are you expecting of me? :D
14:12<Nickman87>I'll be off for a while ;)
14:13<Ammler>coding?
14:13<Nickman87>:D
14:13-!-sulai [~chatzilla@dslb-088-073-181-164.pools.arcor-ip.net] has joined #openttd
14:18-!-Zuu [~Zuu@c-75fae253.025-58-6e6b702.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds]
14:29-!-boekabart [~boekabart@pizzapazzi.com] has joined #openttd
14:37-!-sulai_ [~chatzilla@dslb-088-072-184-216.pools.arcor-ip.net] has joined #openttd
14:38-!-Zuu [~Zuu@c-75fae253.025-58-6e6b702.cust.bredbandsbolaget.se] has joined #openttd
14:41-!-welshdragon [~markjones@147.143.254.214] has quit [Quit: welshdragon]
14:44-!-sulai [~chatzilla@dslb-088-073-181-164.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
14:47-!-SHADOW-XIV [~Miranda@cpc2-lewi3-0-0-cust462.bmly.cable.ntl.com] has joined #openttd
14:48-!-KenjiE20 [~KenjiE20@92.21.50.189] has quit [Ping timeout: 480 seconds]
14:49-!-SHADOW-XIV [~Miranda@cpc2-lewi3-0-0-cust462.bmly.cable.ntl.com] has quit []
14:52-!-SHADOW-XIII [Miranda@cpc2-lewi3-0-0-cust462.bmly.cable.ntl.com] has quit [Ping timeout: 480 seconds]
14:53<fonsinchen>With newgrf, is it possible to define vehicles with capacity > 65535 units?
14:53<frosch123>when using multiple parts
14:54<frosch123>0x7EFF is the maximum capacity per articulated part
14:54<frosch123>hmm, no, you can cheat to 0x7fff
14:54<fonsinchen>@calc 0x7fff
14:54<@DorpsGek>fonsinchen: 32767
14:55<Alberth>that is a number you should know :)
14:55<frosch123>ohoh, ships and aircraft can use full 16 bit
14:56<fonsinchen>so basically, if I merge equal packets in AgeCargo I don't have to check for overflow as there is no vehicle with that kind of capacity.
14:56<fonsinchen>I probably can assert on that.
14:56<frosch123>uint16 cargo_cap; <- for sure :p
14:57<fonsinchen>I have: if (last->SameSource(cp)) last->Merge(cp);
14:57<fonsinchen>so this can be more, technically
14:57-!-Progman [~progman@p57A1FC2D.dip.t-dialin.net] has joined #openttd
14:58<fonsinchen>but not really as the capacity of the vehicles is limited to 2^16
14:58<frosch123>(that was Vehicle::cargo_cap btw)
14:58<fonsinchen>ah, OK
14:58<fonsinchen>then it should really be safe
15:07<Rubidium>stations?
15:11<frosch123>do stations have an overflow check, or will the cargo just vanish when you unload 2^32 units?
15:12-!-HerzogDeXtEr [~Flex@89.246.200.11] has joined #openttd
15:13<frosch123>oh, single packets are also 16bit
15:14<Rubidium>not sure
15:14<fonsinchen>That's only for vehicles
15:15<Rubidium>probably overflow at 2**31, although... it's (on rating updates) limited
15:15<Rubidium>to something considerably lower than that
15:15<fonsinchen>I have different subclasses of cargolist for vehicles and stations
15:16<fonsinchen>In trunk, CargoList has an overflow check for Append, btw
15:17<frosch123>but AddToCache does not have any
15:18<CIA-4>OpenTTD: alberth * r17740 /trunk/src/company_gui.cpp: -Codechange: Extract financial expenses drawing routines.
15:19-!-HerzogDeXtEr1 [~Flex@88.130.181.251] has quit [Ping timeout: 480 seconds]
15:23<fonsinchen>We implicitly expect the difference between uint (CargoList::count) and uint16 (CargoPacket::count) to be large enough. That's somewhat evil.
15:25<Rubidium>I really wonder how you would want to get 2 billion cargo into a cargolist that quickly
15:26<Rubidium>64000 ships with 65535 cargo need to unload, and then they need to go to a large number of different stations to get more load and get that unloaded at the 'unload' station within the rating refresh
15:27<fonsinchen>that's what I mean with "somewhat". It's not that bad.
15:28<fonsinchen>but there might be machines with sizeof(uint) < 32.
15:28<Rubidium>nope
15:28<fonsinchen>s/32/4/
15:28<frosch123>you can make a industry that produces 65535 units everytime a vehicle unloads the next gradual loading step
15:28<fonsinchen>I though the C++ standard allowed that ...
15:28-!-Muxy [~Benoit@smtp.bdelalande.net] has joined #openttd
15:29<Rubidium>it might allow that, but stdafx.h doesn't allow it
15:29<fonsinchen>probably we're safe then
15:29-!-stuffcorpse [~stuffcorp@121.98.136.241] has quit [Remote host closed the connection]
15:30-!-sulai_ [~chatzilla@dslb-088-072-184-216.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
15:30-!-stuffcorpse [~stuffcorp@121.98.136.241] has joined #openttd
15:35<CIA-4>OpenTTD: rubidium * r17741 /trunk/src/ (46 files in 3 dirs): -Feature-ish [FS#3116]: show the nickname of the person you're PMing
15:41-!-sulai [~chatzilla@dslb-088-072-184-216.pools.arcor-ip.net] has joined #openttd
15:45-!-KenjiE20 [~KenjiE20@92.16.14.244] has joined #openttd
15:51-!-Singaporekid [~notme@cm52.psi148.maxonline.com.sg] has quit [Quit: Leaving]
15:51-!-KritiK [~Maxim@78-106-61-9.broadband.corbina.ru] has joined #openttd
15:55-!-Doorslammer [Doorslamme@PIPP-p-203-54-229-129.prem.tmns.net.au] has quit []
15:56-!-_ln [~lanurmi@dyn-xdsl-83-150-113-243.nebulazone.fi] has joined #openttd
16:00-!-Brianetta [~brian@client-86-27-177-5.popl.adsl.virginmedia.com] has joined #openttd
16:09-!-bb10 [~nn@dhcp-077-249-031-191.chello.nl] has quit [Ping timeout: 480 seconds]
16:10-!-boekabart [~boekabart@pizzapazzi.com] has quit [Ping timeout: 480 seconds]
16:11-!-andythenorth [~andy@87.114.101.222.plusnet.thn-ag2.dyn.plus.net] has joined #openttd
16:21-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
16:23-!-frosch123 [~frosch@frnk-590fddd5.pool.mediaWays.net] has quit [Remote host closed the connection]
16:28-!-Rubix`` [~wrqwer@69.49.68.95] has joined #openttd
16:34-!-Eddi|zuHause [~johekr@p54B77DA6.dip.t-dialin.net] has quit [Remote host closed the connection]
16:35-!-Eddi|zuHause [~johekr@p54B77DA6.dip.t-dialin.net] has joined #openttd
16:41*Muxy is happy, watching gui works...
16:42<andythenorth>evening
16:46-!-Rubix`` [~wrqwer@69.49.68.95] has quit [Quit: Ping timeout: 540 seconds]
16:54-!-Xaroth_ is now known as Xaroth
16:55-!-Zuu [~Zuu@c-75fae253.025-58-6e6b702.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
16:55-!-Zuu [~Zuu@c-75fae253.025-58-6e6b702.cust.bredbandsbolaget.se] has joined #openttd
16:56<Zuu>Nickman87: Are you there?
16:58<CIA-4>OpenTTD: rubidium * r17742 /trunk/src/network/ (5 files in 2 dirs): -Codechange: remove unused variable from Recv_Packet
17:00*Zuu crosses his fingers for that the upgrade of VS Express didn't cause OpenTTD to stop compile.
17:01<Zuu>hmm, it tid. png.h has went out of search path..
17:01<Zuu>did*
17:01<Nickman87>I am here yes Zuu :)
17:02<Zuu>Hey, I proof read your update of the filter sign list patch against version 22 of my patch which I believe was the last version pririor to your update.
17:03<Zuu>I found a few things I couldn't directly relate to nested widgets. But also I found that you have found things I have been blind against myself.
17:03<Nickman87>I think I started from an updated version made by planetmaker for revision r16039
17:04<Zuu>Okay, hmm, that version is not in the thread right?
17:04<Nickman87>I got it here: https://dev.openttdcoop.org/projects/clientpatches/repository/changes/filter_signs.diff
17:04<Nickman87>Ammler lead me to that page :)
17:04<Zuu>I'll check that one too. 16039 is pririor to the window got nestified right?
17:04<Nickman87>it is possible that I made some small adjustments to the code yes, I didn't really compare them both one-on-one :)
17:04<Nickman87>yes indeed
17:06<Zuu>I didn't see any bigger problems but there are some things I wonder if they are intended or mistakes. So I'm compiling it now to see what has actually changed in behaviour or not.
17:06<Nickman87>if you want to you can point them out and I can take a look at it too :)
17:07<Zuu>One thing I noticed is that you don't give focus to the edit box when the window is created.
17:07<Nickman87>My intentions were to just port it to the new system, not to make changes to it just yet :)
17:07<Nickman87>at line 150: this->SetFocusedWidget(SLW_FILTER_TEXT);
17:07<Zuu>Yep
17:08<Nickman87>but maybe it should be in the InitializeFilterTextWidget function...
17:08<Nickman87>brb ;)
17:09<Zuu>Hmm, actually it is the other way around.
17:09-!-StM [~StM-freen@ip4da75f1e.direct-adsl.nl] has quit []
17:09<Zuu>You give focus to it when it is created, which the original v22 does not do.
17:09<Zuu>Instead the user have to press the f-key to focus it.
17:09<Zuu>Otherwise if you open the sign list all hotkeys will stop to work.
17:10<Zuu>(It was long time I used the patch or looked on it so I am a bit rusty on it)
17:12<Zuu><-- Good work. The path to "OpenTTD essentials" was wrong or the directory was unziped at the wrong location. :-)
17:12<Ammler>Zuu: Nickman87, did you see my post about ESC and focus?
17:12<CIA-4>OpenTTD: rubidium * r17743 /trunk/src/network/network_server.cpp: -Fix: (post 0.7) memory leak in server in case handling a packet caused the connection to be closed. Also force-close the connection on invalid packets.
17:12<Zuu>Ammler: I did see that
17:12<Zuu>I could not see anything strange in v22, but will test on nickmans update as soon as I have a binary.
17:13-!-oskari89 [~oskari89@212-149-205-119.bb.dnainternet.fi] has quit [Quit: Utm A½ - Aja 35]
17:13<Muxy>ok men, watch GUI patch published on tt-forum.
17:14-!-andythenorth [~andy@87.114.101.222.plusnet.thn-ag2.dyn.plus.net] has quit [Quit: andythenorth]
17:14<Ammler>Zuu: wasn't it possible to have the sign list open and chat at same time?
17:15<Zuu>Ammler: Yes it was the idea with the widget focus patch.
17:16<Ammler>I tested, it might be a "feature" of the new gui system
17:16<Ammler>you can't chat while the password textfield is open either
17:17<Zuu>You should be able to try with the savegame window and the chat. etc.
17:17<Zuu>But i see you have done that.
17:17<Ammler>oh
17:17<Zuu>Hmm, strange
17:17<Zuu>I'll take a look
17:18<Zuu>Have mostly been doing AI-stuff so haven't really paid notice.
17:18<Ammler>yes, you can't
17:18<Ammler>well, mostly it doesn't matter
17:18<Ammler>but for the sign list, if would be nice
17:18<Ammler>it*
17:20<Zuu>It is still a bug that defets the main reason for the widget focus feature. Meaning we only have the drawbacks with it at the moment. Also unless the devs have something in mind it was kind of a step towards allowing multiple edit boxes on a window.
17:21<Zuu>Hmm, seams to work okay here. I can switch between eding my company name and the savegame name.
17:22<Zuu>Or is it specficly the combination with the chat window that doesn't work?
17:22<Ammler>without patch?
17:22-!-Muxy [~Benoit@smtp.bdelalande.net] has quit [Quit: PACKET_CLIENT_QUIT]
17:22<Zuu>That is without the sign list patch.
17:22<Zuu>r17739
17:22<Ammler>I have to admit, I didn't try with plain trunk
17:23<Zuu>What did you use?
17:23<Ammler>the patch from nick
17:23<Zuu>And that one killed the possibility to change between two edit fields?
17:23<Ammler>yes
17:23<Ammler>or it isn't possible in trunk either
17:24<Zuu>Even two edit fields apart form the signs window?
17:24<Ammler>save window and chat doesn't work
17:24<Zuu>My binary is done, so let me test...
17:25-!-tux_mark_5 [~kvirc@lan-84-240-29-163.vln.skynet.lt] has quit [Quit: KVIrc Insomnia 4.0.0, revision: , sources date: 20090115, built on: 2009/03/07 00:45:02 UTC http://www.kvirc.net/]
17:26<Zuu>I can change between the save window and the chat window with Nicks patch.
17:27<Zuu>There is a problem though with the sign list patch.
17:27<Zuu>It opens the OSK when it is clicked and does not have focus.
17:28<Zuu>The rule is that the OSK should only be opened when a edit box is clicked and both the window have focus and the edit box has focus.
17:28<Zuu>Eg. globally focused
17:28<Zuu>There is a Window function probably in the global scope that checks if a widget is globaly focused.
17:29<Zuu>Unless the devs have removed it.
17:29-!-Fast2 [~Fast2@p57AF9FEA.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
17:32<Zuu>Ammler: Exactly what is the glitch that happens when you press ESC? I see focus is not removed from the edit box. But apart from that?
17:33<Eddi|zuHause>oh... speaking of which, i had edit box focus trouble with the timetable patch
17:33<Eddi|zuHause>maybe someone with actual gui knowledge could look over that?
17:33-!-Nite_Owl [~Nite_Owl@c-76-109-50-97.hsd1.fl.comcast.net] has joined #openttd
17:34<Nite_Owl>Hello all
17:36<Nickman87>back
17:38<Nickman87>Ammler, Zuu: currently when you have a focus inside the Sign list window, the Esc and Return keys are used to perform actions (see my post in the thread)
17:38<Ammler>Nickman how to leave the focus from the list?
17:38<Nickman87>currently not I think :)
17:39<Nickman87>When I click inside another window, the focus gets changed though?
17:39<Zuu>Previously you unfocused the edit box with escape so that you could perform regular hotkeys
17:39<Zuu>Including 'f' to re-focus the edit box
17:40<Nickman87>yeah, esc doesn't seem to un-focus
17:40<Nickman87>this->focused_widget = 0; // Unfocus the text box
17:41<Nickman87>that should do it, but probably changed in the new system
17:41<Zuu>Yeah I saw that one
17:41<Zuu>The SetFocusedWidget function does still take widget indexes and does not support a special index from what I can see.
17:42<Zuu>I'm currently looking into why the OSK opens when you focus the edit box for the first time.
17:42<Nickman87>it happens in other windows to I think?
17:42<TrueBrain>Rubidium: 3252 misses the most important step: HOW it fails ... how did you confirm it?
17:42<Nickman87>for example the edit company name window
17:43<Zuu>Nickman87: Nope
17:43<Nickman87>Happens here? :)
17:43<Rubidium>TrueBrain: not personally, but... lots of people have been complaining about it
17:43<Zuu>In edit company name window the edit box is pre-focused. But if you click on the frame so the edit box is unfocused. Then try to click on the edit box.
17:43<Nickman87>I open up the change company name window, click on another window, reclick inside the company edit box and I get the OSK window
17:43<TrueBrain>lots of people == 1 bug report
17:43<Zuu>This time you can click on the edit box to focus it without open the OSK window.
17:44<Zuu>Nickman87: Hmm, okay
17:44<Rubidium>TrueBrain: yes, lots of people - 1 didn't file a bug report, even when they were asked to do so
17:44<TrueBrain>well, I can't reproduce it when I try, and when they retry it works
17:44<Nickman87>the functionality is the same inside the sign list window
17:44<TrueBrain>which leaves me completely in the dark
17:44<Nickman87>so it seems :)
17:44<Rubidium>TrueBrain: 18:24 <@Morloth> I have a problem with bananas. When I try to upload a new version of NoCAB I get a 'Unexpected error while uploading.' message
17:44<TrueBrain>see, that error message is more useful
17:44<Zuu>Nickman87: Can confirm that that did not happen in r14658, so that bug has been introduced. I'll take a look
17:45-!-TheMask96 [martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
17:45<Nickman87>Then it has to do with the new widget system perhaps?
17:45<Rubidium>TrueBrain: < ac84> I was trying to upload my lib to Bananas, but receiving error "Unexpected error while uploading".
17:45<TrueBrain>Rubidium: I have 0 clues what goes wrong, even more as nothing changed, and it works most of the time ...
17:45<Zuu>It is probably in the mess called DispatchLeftClickEvent function.
17:45<Nickman87>:D
17:46<Nickman87>yeah, when a window looses focus, so should all the edit boxes...
17:46<TrueBrain>either way, I will put it on my list of things to do ..
17:46<Zuu>It is quite big and hard to grasp from just reading it a few seconds.
17:47<Zuu>Each window keep track of which widget in the window has focus. So that when you click on the title bar (or in future use alt+tab equivivalent yet to be implemented) it will remember which widget was focused.
17:47<Zuu>And then there is a global pointer _focused_widget
17:47<Nickman87>that is another way to look at it yes
17:47<Zuu>This is why it is important too separate global and local focus.
17:47<Nickman87>but then, when you click inside an unfocused widow, inside an already focused widget, it should act as if it wasn't focused before :)
17:48<Zuu>Well, it should change focus to the widget you click on, but if that widget was already focused it shouldn't trigger the OSKWindow for edit boxes.
17:48<Nickman87>indeed :)
17:49<Zuu>And I either can continue to argue or try to understand the code hehe
17:49<Nickman87>:D
17:49<Zuu>Should probably study the old code to see how it did work before trying to understand why it does not work now. :-)
17:50<Nickman87>:)
17:50<Nickman87>that is often helpfull
17:51<Nickman87>ok, I fixed it that you can unfocus the edit box by pressing esc, should I remove the autofocus to?
17:51<Zuu>Yes I think so
17:51<Zuu>Since you can press the f-key to focus it.
17:52-!-TheMask96 [martijn@greed.vhost.ne2000.nl] has joined #openttd
17:52<Nickman87>indeed
17:52<Zuu>And I would guess users would get more comfused when they wonder why the hotkeys stop working.
17:52<Zuu>I mean if this is going to end up in trunk one day, there will be users that will not use the feature. And they shouldn't have to unfocus the edit box.
17:53<Nickman87>done ;)
17:53<Nickman87>yeah, that is indeed a bad choise
17:53<Nickman87>But it is still impossible to close the window by pressing esc
17:54<Nickman87>ah, but not all windows can be closed by pressing esc so that is not really a problem
17:55-!-welshdragon [~markjones@147.143.254.214] has joined #openttd
17:59<Nickman87>I'll be off for a while, going home, you can always post remarks in the thread ;)
17:59<Nickman87>Don't know if I'll come back online tonight
18:02<Zuu>Found and fixed the OSK-bug. Can partly blame myself for not documenting a peice of code that seam strange if you don't carfully read the entire DispatchLeftClickEvent function.
18:03<Zuu>And there is lot of corner cases in that one.
18:07-!-Nickman87 [~nick.defr@137.44-245-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 480 seconds]
18:08-!-Grelouk [~Grelouk@122.72.200-77.rev.gaoland.net] has quit [Read error: Connection reset by peer]
18:13-!-Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection]
18:16-!-sulai [~chatzilla@dslb-088-072-184-216.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
18:16-!-Progman [~progman@p57A1FC2D.dip.t-dialin.net] has quit [Remote host closed the connection]
18:24-!-fonsinchen [~alve@BAEad17.bae.pppool.de] has quit [Quit: Leaving.]
18:31<Terkhen>good night
18:31-!-Terkhen [~terkhen@44.69.220.87.dynamic.jazztel.es] has quit [Quit: ...]
18:32<Zuu>Fix to the OSK-bug has now been uploaded to http://bugs.openttd.org/task/3253
18:34<Zuu>I don't know when it was introduced. More than somewhere between 14658 and now.
18:34-!-Nickman_87 [~nick.defr@d515370C5.access.telenet.be] has joined #openttd
18:34-!-Nickman_87 is now known as Nickman87
18:35-!-Rubix`` [~wrqwer@69.49.68.95] has joined #openttd
18:36-!-Rubix`` [~wrqwer@69.49.68.95] has quit []
18:40<Eddi|zuHause>i hate the forum
18:41<Eddi|zuHause>it way too frequently forgets my login
18:41<Eddi|zuHause>and when i relogin, it doesn't return to the page that i visited, but instead to the forum main page
18:41-!-Nite_Owl [~Nite_Owl@c-76-109-50-97.hsd1.fl.comcast.net] has quit [Quit: Read You Soon]
18:42<_ln>that's why irc is better
18:44<Zuu>Nickman87: An issue I don't know how much of an issue it is. When you took the PM-patch, that patch is the combination of two sub-steps in my hg-queue. So now we have one big patch with all the features, but not the step inbetween which does not have the arrow-key code.
18:45<Zuu>But checking the thread it is not really obvious from my uploads (without reading my posts) that those two versions exist.
18:46<Zuu>Probably because 22 is the only version that contains that featrue. And it would have been a post with version 23 that would have been the first one containing both versions.
18:48<Zuu>But I guess it shouldn't be too hard to strip away some features from it if we want to make a simplier patch with just the core features for trunk reasons later on.
18:49<Zuu>Myself I think for example the arrow up/down feature is quite handy but could understand if it will not be trunked to keep the code size down. Or if it would be included, at least keep it as a separate patch.
18:52-!-Coco-Banana-Man [~Stephan.D@p5B2DDE50.dip.t-dialin.net] has quit [Quit: Joyful it seems - but then suddenly - by one false move it's blown away]
18:55<Nickman87>hmmmm, Zuu I don't really see what you mean?
18:56<Zuu>Devs usually prefere patches in several stages whet it is possible.
18:56<Nickman87>My arrow keys do nothing?
18:56<Nickman87>:)
18:56<Zuu>The smaller the patches the better
18:56<Zuu>Then you have droped some features...
18:56<Nickman87>yeah, but I don't see the arrow key code?
18:56<Nickman87>:)
18:57<Zuu>Hmm, you still have WKC_UP etc.
18:57<Nickman87>you mean the "SelectNextSign" and "SelectPreviousSign" functions?
18:57<Zuu>And the SelectNextSign/SelectPreviousSign functions..
18:57<Zuu>Yep
18:58<Zuu>When the edit box is focused, try arrow down
18:58<Nickman87>yeah, but when I press the arrow keys, it does nothing?
18:58<Nickman87>must have broken it somehow?
18:59<Zuu>Yea, it should select one of them. And then when you hit enter the blue marked sign will get viewed in the main veiwport.
18:59<Nickman87>I see the code
18:59<Nickman87>I never get a blue marked sign :)
18:59<Zuu>You seam to have uncommented the invalidate code
19:00<Zuu>Your patch have //this->SetDirty();
19:00<Zuu>:-)
19:00<Nickman87>where?
19:01<Zuu>Though you later make the list widget dirty...
19:01<Zuu>In SelectNextSign and SelectPreviousSign.
19:02<Zuu>It has some uncommented lines in it.
19:02-!-Lakie [~Lakie@91.84.251.149] has quit [Quit: Sleep]
19:02<Nickman87>I'm trying something ;)
19:03<Nickman87>still no selecting...
19:05<Zuu>Are you on Visual Studio or something else with a good debugger?
19:06<Zuu>Then you can try to see what happens when you hit arrow down and see if it goes wrong somewhere.
19:06-!-welshdragon [~markjones@147.143.254.214] has left #openttd []
19:06<Zuu>I'll do that as soon as the compiler is done.
19:06-!-Brianetta [~brian@client-86-27-177-5.popl.adsl.virginmedia.com] has quit [Quit: Tschüß]
19:07<Nickman87>yes, I'm on VS :)
19:07<Nickman87>going to check now :)
19:11<Nickman87>now its working, the "if" check wasn't working anymore ;)
19:12<Zuu>Try to replace it with this->IsWidgetFocused(f
19:12<Zuu>this->IsWidgetFocused(SLW_FILTER_TEXT)
19:12<Nickman87>I have this now: this->HasEditBoxFocus(this, SLW_FILTER_TEXT) :D
19:12<Nickman87>but yours sounds more logical
19:13<Nickman87>but indeed, those two different patches can be split very easily
19:14<Nickman87>but now I have to go to bed, have to get up in about 6 hours already so... :)
19:14<Zuu>Hmm, I wonder why HasEditBoxFocus is not static..
19:14<Nickman87>yeah, its strange that I have to pass my window to it...
19:14<Zuu>But they might do different things thoug.
19:15<Eddi|zuHause>gah... i'd like to trash the whole timetable gui and rewrite it from scratch, but i don't want to get involved in gui programming at all...
19:15<Zuu>IsFocusedWidget only checks for local focus.
19:15<Zuu>So HasEditBoxFocus might actually be better.
19:16<Nickman87>but wont it be true even if the widget is not focused then?
19:18<Nickman87>IsWidgetFocused is not good, it also triggers events when the window is not focused
19:18-!-Polygon [~Poly@x0581b.wh7.tu-dresden.de] has quit [Quit: Flieht, ihr Narren!]
19:18<Nickman87>I'll try the other one again
19:19<Zuu>Hmm
19:19<Zuu>yea
19:20<Zuu>I have to check if HasEditBoxFocus was mostly intended for internal use in that class.
19:20<Nickman87>HasEditBoxFocus doesnt have that problem, but since I have to pass the window to it, it looks a bit strange
19:21<Zuu>HasEditBoxFocus is indeed not intended to be used in this case.
19:21<Zuu>use this->IsWidgetGloballyFocused( .. )
19:21<Nickman87>trying IsWidgetGloballyFocused now
19:21<Nickman87>hehe :d
19:21<Zuu>That one is intended for this case.
19:22<Nickman87>just saw it existed ;)
19:22<Nickman87>perfect
19:22<Zuu>I'll look into HasEditBoxFocus if there is a real problem with it or if it can be made private so noone uses it instead of window->IsWidgetGloballyFocused.
19:24<Nickman87>It is only used inside the "misc_gui.cpp" file it seems
19:24<Nickman87>and querystring_gui.cpp once
19:24<Nickman87>.h I mean
19:24<Zuu>It is declared in .h
19:25<Nickman87>yeah
19:25<Nickman87>so that is allright
19:25<Zuu>But it seams only QueryString uses it and no children of it. So it could be made private.
19:25<Nickman87>it is never used outside of the class
19:25<Nickman87>but it calls "if (w->IsWidgetGloballyFocused(wid)) return true;" itself :)
19:26<Nickman87>so it is only used for OSK things?
19:27<Zuu>The QueryString class is a class that takes care of some of the edit box code. To add a edit box to a widget you need to use the HasEditBoxFocu class as a base class (which innerheits from QueryString).
19:27<Zuu>This is one of the reasons why you can only have one text edit box per window.
19:27<Nickman87>well, I'm off for today, need some sleep :)
19:27<Zuu>Focus used to be another reason.
19:27<Zuu>Yea, good night
19:27<Nickman87>but that is not a problem anymore?
19:28<Nickman87>night :)
19:28<Zuu>Focus shouldn't be a problem anymore. Some focus-code will need to change when the other part changes but in general focus is not a problem anymore.
19:29<Nickman87>I'll see if I can split the code into two base patches without much interference from eachother tomorrow ;)
19:29<Nickman87>So you should be able to apply the patches independant of eachother
19:29<Zuu>If you havent looked into hg queues, take a look on that.
19:30<Nickman87>hg queues?
19:30<Zuu>Well, if you don't mind sure. But don't push you into it just for me.
19:30<Zuu>Do you know hg?
19:31<Nickman87>what is hg? :)
19:31<Zuu>The versioning system
19:31<Zuu>Like svn but you can run it locally without a server
19:31<Nickman87>yeah, I have some of that installed I think :)
19:31<Zuu>There is a module to it called queues which makes it very easy to maintain patches that apply in series.
19:31<Nickman87>I have TortoiseHG :)
19:32<Zuu>You tell it which patch you are at. Make your changes. Refresh patch. Go to next patch. Do some thing. Refresh..
19:32<Nickman87>kewl :)
19:32-!-Eddi|zuHause [~johekr@p54B77DA6.dip.t-dialin.net] has quit []
19:33<Zuu>And you can move back and forth between the patches and the code tree is updated accordingly. And it stores the data as a set of patches. So you can actually replace that patch file if you want.
19:33<Nickman87>I'll take a look at it :)
19:33-!-Eddi|zuHause [~johekr@p54B77C63.dip.t-dialin.net] has joined #openttd
19:33<Zuu>And leave TortoiseHG aside, it doesn't contain the queue functions.
19:34<Nickman87>ah :D
19:34<Zuu>So you will need to use the terminal, but it is quite straight forward.
19:34<Nickman87>I'll search around about it tomorrow ;)
19:35<Nickman87>night!
19:35<Zuu>Night!
19:36-!-lugo [~lugo@mgdb-4db87a0b.pool.mediaWays.net] has quit [Remote host closed the connection]
19:43-!-Nickman87 [~nick.defr@d515370C5.access.telenet.be] has quit [Ping timeout: 480 seconds]
19:44-!-PeterT [~Peter@c-76-19-168-104.hsd1.ma.comcast.net] has joined #openttd
19:48-!-PeterT [~Peter@c-76-19-168-104.hsd1.ma.comcast.net] has quit []
20:01-!-KritiK [~Maxim@78-106-61-9.broadband.corbina.ru] has quit [Quit: Leaving]
20:13-!-Zuu [~Zuu@c-75fae253.025-58-6e6b702.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
20:20-!-Chris_Booth [~Chris_Boo@82-32-243-15.cable.ubr11.newt.blueyonder.co.uk] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
20:21-!-Zahl [~Zahl@e181182150.adsl.alicedsl.de] has quit [Quit: *schiel*]
20:29-!-dartagnan [~quassel@modemcable019.245-57-74.mc.videotron.ca] has joined #openttd
20:39-!-Rubix`` [~wrqwer@69.49.68.95] has joined #openttd
20:42-!-KenjiE20|LT [~Kenji@host86-170-58-126.range86-170.btcentralplus.com] has joined #openttd
20:43-!-KenjiE20 [~KenjiE20@92.16.14.244] has quit [Quit: WeeChat 0.3.0]
21:17-!-dartagnan [~quassel@modemcable019.245-57-74.mc.videotron.ca] has quit [Remote host closed the connection]
21:17-!-Dred_furst [~Dred@cpc3-pool3-0-0-cust999.sotn.cable.ntl.com] has joined #openttd
21:21-!-Rubix`` [~wrqwer@69.49.68.95] has quit [Read error: Connection reset by peer]
21:21-!-Rubix`` [~wrqwer@69.49.68.95] has joined #openttd
21:27-!-Dred_furst [~Dred@cpc3-pool3-0-0-cust999.sotn.cable.ntl.com] has quit [Quit: Leaving]
21:48-!-KenjiE20|LT [~Kenji@host86-170-58-126.range86-170.btcentralplus.com] has quit [Quit: Leaving]
21:54-!-Chruker [~no@port113.ds1-vj.adsl.cybercity.dk] has quit []
22:03-!-Rubix`` [~wrqwer@69.49.68.95] has quit [Read error: Connection reset by peer]
22:03-!-Rubix`` [~wrqwer@69.49.68.95] has joined #openttd
22:13-!-Dred_furst [~Dred@cpc3-pool3-0-0-cust999.sotn.cable.ntl.com] has joined #openttd
22:15-!-Dred_furst [~Dred@cpc3-pool3-0-0-cust999.sotn.cable.ntl.com] has quit []
22:22-!-Fuco [~a@fuco.sks3.muni.cz] has quit [Ping timeout: 480 seconds]
22:44-!-Rubix`` [~wrqwer@69.49.68.95] has quit [Read error: Connection reset by peer]
22:44-!-Rubix`` [~wrqwer@69.49.68.95] has joined #openttd
23:03-!-glx [glx@2a01:e35:2f59:c7c0:972:6243:da38:cc4d] has quit [Quit: bye]
23:07-!-Rubix`` [~wrqwer@69.49.68.95] has quit [Quit: Ping timeout: 540 seconds]
23:42-!-Pikka [PikkaBird@58.173.248.50] has joined #openttd
23:58-!-Pikka [PikkaBird@58.173.248.50] has quit [Ping timeout: 480 seconds]
---Logclosed Thu Oct 08 00:00:52 2009