Log for #openttd on 7th October 2009:
Times are UTC Toggle Colours
00:00:17  *** Muxy [] has quit [Quit: PACKET_CLIENT_QUIT]
00:03:53  *** KenjiE20|LT [] has joined #openttd
00:04:18  *** KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.0]
00:12:30  *** StM [] has quit []
00:39:25  *** Brianetta [] has quit [Quit: Tsch?ss]
00:40:37  *** Rubix`` [~wrqwer@] has joined #openttd
00:46:57  *** Fuco [] has quit [Ping timeout: 480 seconds]
00:48:41  <Rubidium> just to cut another hour of TrueBrain's sea of green I say: good night :)
00:49:01  <glx> hehe
00:51:28  *** Dred_furst [] has quit [Quit: Leaving]
00:51:42  *** PeterT [] has quit [Quit: I'm off]
01:17:10  *** PeterT [] has joined #openttd
01:17:28  <PeterT> any programmers willing to help me with something?
01:23:31  <Eddi|zuHause> no.
01:23:42  <Eddi|zuHause> they are all fed up with you.
01:24:05  <PeterT> yes, thanks for that
01:29:31  *** Lakie [~Lakie@] has quit [Quit: Sleeps.]
01:46:02  *** Chris_Booth [] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
01:46:04  *** PeterT [] has quit [Quit: I'm off]
01:49:59  *** Rubix`` [~wrqwer@] has quit [Quit: Ping timeout: 540 seconds]
02:00:03  *** Xaroth_ [~Xaroth@] has joined #openttd
02:03:30  *** Rubix`` [~wrqwer@] has joined #openttd
02:07:06  *** Xaroth [~Xaroth@] has quit [Ping timeout: 480 seconds]
02:09:39  *** me [] has joined #openttd
02:14:55  *** KenjiE20|LT [] has quit [Quit: Leaving]
02:16:36  *** zodttd [] has quit [Ping timeout: 480 seconds]
02:39:46  *** me [] has quit [Quit: me]
02:47:06  *** DaleStan_ [~Dale@] has joined #openttd
02:48:29  *** DaleStan is now known as Guest463
02:48:30  *** DaleStan_ is now known as DaleStan
02:53:51  *** Guest463 [~Dale@] has quit [Ping timeout: 480 seconds]
03:03:14  *** glx [glx@2a01:e35:2f59:c7c0:40eb:2ff9:2e62:38a3] has quit [Quit: bye]
03:10:21  *** Rubix`` [~wrqwer@] has quit [Quit: Ping timeout: 540 seconds]
03:38:42  *** luckz [] has quit [Remote host closed the connection]
05:13:38  *** lugo [] has joined #openttd
05:18:17  *** Zahl [] has quit [Quit: *schiel*]
05:37:56  *** Polygon [] has joined #openttd
05:51:16  *** Splex [~splex@] has quit [Quit: Leaving]
06:05:57  *** Splex [~splex@] has joined #openttd
06:06:34  *** Polygon [] has quit [Quit: Flieht, ihr Narren!]
06:18:47  *** Cybertinus [] has joined #openttd
06:32:24  *** Phoenix_the_II [] has joined #openttd
06:38:19  *** thepalm [~chatzilla@] has joined #openttd
06:40:12  *** Doorslammer [] has joined #openttd
06:42:32  <Rubidium> morning, yup it's early
06:50:31  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
06:55:42  *** TheMask96 [] has joined #openttd
06:56:26  *** hickop [] has quit [Quit: Lost terminal]
07:09:15  *** Nickman_87 [] has joined #openttd
07:31:38  *** Fuco [] has joined #openttd
07:32:20  *** Muxy [] has joined #openttd
07:43:45  *** ecke [] has joined #openttd
07:45:09  *** thepalm [~chatzilla@] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
07:48:36  *** fonsinchen [] has joined #openttd
08:01:46  *** ecke [] has quit [Ping timeout: 480 seconds]
08:10:49  *** thepalm [~chatzilla@] has joined #openttd
08:25:25  <CIA-4> OpenTTD: rubidium * r17735 /trunk/src/ (cargopacket.cpp cargopacket.h):
08:25:25  <CIA-4> OpenTTD: -Codechange: update the cache one inserting/removing CargoPackets from the
08:25:25  <CIA-4> OpenTTD: CargoList via Append/Truncate instead of rebuilding the whole cache. For Append
08:25:25  <CIA-4> OpenTTD: this changes the O(n) cache rebuild into a O(1) cache update. For Truncate no
08:25:25  <CIA-4> OpenTTD: temporary list is needed anymore (based on patch by fonsinchen)
08:28:02  *** Progman [] has joined #openttd
08:31:40  <fonsinchen> Oh, you're merging the cargolist patch. That's nice, thanks.
08:31:54  <CIA-4> OpenTTD: rubidium * r17736 /trunk/src/ (cargopacket.cpp cargopacket.h):
08:31:54  <CIA-4> OpenTTD: -Codechange [FS#3135]: rewrite CargoList::MoveTo; don't require the secondary
08:31:54  <CIA-4> OpenTTD: list, use cache updates instead of rebuilds. This is usually faster because of
08:31:54  <CIA-4> OpenTTD: primarily gradual loading that only moves a (small) part of the cargo each time.
08:31:54  <CIA-4> OpenTTD: Based on patch by fonsinchen.
08:32:11  <Rubidium> pff... finally
08:33:26  <Rubidium> well, have been working on that patch for like 6 hours
08:34:26  <Rubidium> validating it is right, splitting in small pieces that make sense, testing the effect of some changes and whether that effect is benificial
08:35:01  <Spoons> Grats? ;p
08:35:46  <Rubidium> is that like iPhone and Gmail?
08:36:12  <Rubidium> i.e. if Apple would release it it would be called iRats
08:52:15  <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"
08:52:55  *** th1ngwath [] has joined #openttd
08:54:09  <thepalm> is there any way around this?
08:54:40  <thepalm> the patch doesn't apply cleanly using commandline patch and Im not sure what else to try
08:59:56  *** thingwath [] has quit [Ping timeout: 480 seconds]
09:00:55  <Spoons> Apply the patch to trunk then switch?
09:02:09  <thepalm> ill try that
09:06:42  *** sdafsdf [] has joined #openttd
09:06:42  *** LadyHawk [] has quit [Read error: Connection reset by peer]
09:06:52  *** sdafsdf is now known as LadyHawk
09:09:17  <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
09:09:20  *** Spoons is now known as FauxFaux
09:15:47  <thepalm> seems to be working
09:17:15  <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?
09:20:17  *** Yexo_ [] has joined #openttd
09:25:17  <Rubidium> fonsinchen: with patch queue, but that seems quite troublesome with so many branches
09:26:21  <Rubidium> testing happened with big savegames and small, reviewing code that called it, reviewing the actual changes etc
09:27:21  *** Yexo [] has quit [Ping timeout: 480 seconds]
09:29:21  <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.
09:29:51  <fonsinchen> That didn't show much of a benefit, though.
09:30:12  <Rubidium> true, the benefit is very small in most cases
09:43:35  *** ecke [] has joined #openttd
09:49:36  *** ecke [] has quit [Read error: Connection reset by peer]
09:55:43  *** Xaroth_ is now known as Xaroth
09:59:57  *** StM [] has joined #openttd
10:06:58  *** ecke [] has joined #openttd
10:07:03  *** sulai [] has joined #openttd
10:07:08  <sulai> hi there
10:08:29  <sulai> is the bug about loading save games still in trunk? if yes, which revision was the last known working?
10:09:02  *** Belugas [~belugas@] has quit [Ping timeout: 480 seconds]
10:09:34  <Noldo> and are the best sources
10:10:17  *** Belugas [~belugas@] has joined #openttd
10:10:20  *** mode/#openttd [+o Belugas] by ChanServ
10:16:00  <sulai> oh it's been removed 11 hours ago, thanks Noldo
10:26:41  *** ecke [] has quit [Read error: Connection reset by peer]
10:37:26  *** Xaroth_ [~Xaroth@] has joined #openttd
10:37:59  *** Muxy [] has quit [Remote host closed the connection]
10:39:40  *** Muxy [] has joined #openttd
10:44:01  *** Xaroth [~Xaroth@] has quit [Ping timeout: 480 seconds]
10:51:42  *** sulai [] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
10:53:21  *** tux_mark_5 [] has joined #openttd
10:53:42  *** Yexo_ is now known as Yexo
11:04:33  <Noldo> Yexo: are NoAIs run only on the server?
11:04:40  <Yexo> yes
11:05:02  <Noldo> do they se the same DoCommand structure as normal clients?
11:05:07  <Yexo> yes
11:06:16  <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?
11:06:46  <SmatZ> there is no asynchronism from humans
11:07:00  <SmatZ> (sorry, I couldn't let Yexo answer anything else that "yes") :)
11:08:04  <TrueBrain> we humans do threading :) And FAST!
11:08:37  <Yexo> SmatZ: still "yes" would be correct, because of the "_if_ it can handle..." :p
11:08:44  <SmatZ> Yexo: right :)
11:09:03  <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
11:10:12  <TrueBrain> SmatZ: commands are queued, aren't they? :) (for networking, that is)
11:10:13  <SmatZ> like, AI executing "add new sign" could cause crash in other AI that is just getting the sign list
11:10:21  <SmatZ> TrueBrain: yeah :) but not for AIs
11:10:26  <SmatZ> I thought I said that
11:10:40  <Yexo> if you just test a command (hold shift) the command isn't queued
11:10:43  <TrueBrain> lol, that is what I meant .. I thought AIs queue them too
11:10:51  <SmatZ> hmmm
11:10:52  <TrueBrain> (in exec of course)
11:10:53  <SmatZ> ok
11:10:59  <SmatZ> right
11:11:03  <TrueBrain> well, in SP not of course
11:11:11  <SmatZ> right
11:11:13  <SmatZ> now
11:11:21  * SmatZ runs away in shame
11:11:24  <TrueBrain> why?
11:11:27  <TrueBrain> stop doing that :(
11:11:42  <SmatZ> I shouldn't talk about things I think I know about, but I don't :-p
11:11:49  <TrueBrain> I do the same :p
11:11:51  <SmatZ> it results in shame
11:11:53  <SmatZ> :)
11:11:54  <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
11:11:54  <TrueBrain> we would need to check the code :)
11:12:02  <TrueBrain> see ;)
11:12:04  <Yexo> but don't forget that static variables in functions are globals too
11:12:17  <dihedral> TrueBrain, define 'we' :-P
11:12:18  <Yexo> so also functions like OTTD2SFS should be fixed
11:12:32  <TrueBrain> Yexo: fix suggest it is broken ;)
11:12:44  <Yexo> s/fix/chang/
11:13:03  <SmatZ> if the only needed change was a mutex in DoCommandP, it would be easy :)
11:13:03  <dihedral> :-P
11:13:39  <TrueBrain> but this boils down to: make OpenTTD threaded :p
11:14:02  <Yexo> several noai api functions use _current_company
11:14:52  *** Grelouk [] has joined #openttd
11:15:16  <TrueBrain> hmm ... NoAI doesn't even queue in networking .. not via the normal queue anyway
11:16:17  <TrueBrain> it is queued in the server-queue
11:16:18  <TrueBrain> sucks
11:16:24  * Rubidium wonders in what way humans, or at least their interaction, with OpenTTD is more async than for AIs
11:16:52  <TrueBrain> so SmatZ, you are correct, and I run away in shame now ;)
11:17:13  *** tux_mark_5 [] has quit [Remote host closed the connection]
11:17:44  <Rubidium> the only thing is that humans 'clone' a (small) part of the game state
11:17:59  <TrueBrain> AIs can too :)
11:18:02  <Rubidium> and they can only look at that part. AIs can look at *all* the game state
11:18:24  <Rubidium> TrueBrain: AIs can, in one tick, look at all game state. A human only a small subsection of the state
11:18:32  <TrueBrain> very true
11:18:35  <TrueBrain> so AIs cheat!
11:18:41  <Noldo> :D
11:19:13  <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
11:19:33  <Rubidium> which would make the AIs kinda incredibly complex
11:19:58  <StM> And for a AI is it a LOT harder to interact with the world while for a human its very easy
11:20:53  <Rubidium> it isn't easy for a human; humans need to do image analysis, OCR, etc. AIs can query the information directly
11:21:24  <StM> true but humans do that extreme fast :>
11:21:33  <TrueBrain> not as fast as you might think :)
11:21:34  <Rubidium> only the difficulty is mostly hidden from the humans
11:21:42  <StM> true
11:21:42  *** tux_mark_5 [] has joined #openttd
11:21:48  <Noldo> Rubidium: can you give examples about 'certain information'
11:21:55  <Noldo> or is it everything
11:22:16  <StM> but finding a path cost me maybe 1-2 seconds between 2 points, then build it
11:22:27  <Rubidium> Noldo: basically it's everything except current date/bank balance (which a human always sees)
11:22:32  <StM> For a AI is that a lot more complicated
11:23:02  *** KenjiE20 [~KenjiE20@] has joined #openttd
11:23:37  <Rubidium> but *you* do pattern matching/use heuristics, an AI does not; it has to precisely calculate the best outcome
11:23:59  <StM> true :)
11:24:47  <dihedral> <TrueBrain> not as fast as you might think :) <- hehehe
11:25:17  <dihedral> not as fast as he imagined it might be, or really not as fast as he might think :-P
11:26:27  *** KenjiE20 [~KenjiE20@] has quit []
11:27:32  *** KenjiE20 [~KenjiE20@] has joined #openttd
11:28:23  <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
11:28:47  <TrueBrain> (well, everything inside the VM is threaded, any call outside (via the API) would not)
11:31:41  <Rubidium> TrueBrain: but effectively it's the same; it has to wait for data
11:32:02  <TrueBrain> it depends very much on how much CPU it takes to do something with that data
11:32:29  <TrueBrain> and it only has any benefit if you have 2+ AIs
11:33:01  *** thepalm [~chatzilla@] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]]
11:33:05  <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)
11:33:58  <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
11:47:01  *** glx [glx@2a01:e35:2f59:c7c0:972:6243:da38:cc4d] has joined #openttd
11:47:04  *** mode/#openttd [+v glx] by ChanServ
11:48:14  *** tokar [] has quit [Remote host closed the connection]
11:48:31  *** tokai [] has quit [Ping timeout: 480 seconds]
11:50:44  *** tokai [] has joined #openttd
11:50:47  *** mode/#openttd [+v tokai] by ChanServ
11:50:52  *** Coco-Banana-Man [] has joined #openttd
12:14:08  *** Dred_furst [] has joined #openttd
12:16:06  *** Biolunar [] has joined #openttd
12:23:05  <StM> Has somebody already created a simple travelling Salesman implementation build in squirrel? :) For ~ 10 city's max
12:23:24  <SmatZ> @calc 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2
12:23:24  <DorpsGek> SmatZ: 3628800
12:23:34  <StM> I know :>
12:23:46  *** Chruker [] has joined #openttd
12:24:06  <StM> But i'm afraid squirrel is too slow for it
12:25:29  <SmatZ> you have ~20000 ops per tick
12:25:37  <SmatZ> @calc 2628800 / 20000
12:25:37  <DorpsGek> SmatZ: 131.44
12:25:51  <StM> And how long is a tick? :)
12:25:58  <SmatZ> 131 ticks, ~2 game days, if each iteration needed 1 op
12:26:10  <StM> yes but they need a LOT more :(
12:26:11  *** Fast2 [] has joined #openttd
12:26:53  <Muxy> @calc 10!
12:26:53  <DorpsGek> Muxy: Error: unexpected EOF while parsing (<string>, line 1)
12:28:44  <StM> And i'm afraid this will be a little bit above my C skills :p
12:29:00  *** welshdragon [~markjones@] has joined #openttd
12:29:25  <SmatZ> :)
12:46:57  *** Eddi|zuHause [] has quit [Remote host closed the connection]
12:47:27  *** Eddi|zuHause [] has joined #openttd
12:49:37  <Yexo> SmatZ: default is only 10.000 ops per tick
12:49:50  <Yexo> and the first result was, not
12:50:30  <SmatZ> [14:49:54] <Yexo> and the first result was, not <== what result?
12:50:38  <Yexo> <@DorpsGek> SmatZ: 3628800
12:50:41  <Yexo> <SmatZ> @calc 2628800 / 20000
12:50:55  <SmatZ> ah
12:50:57  <SmatZ> :)
12:51:00  <Yexo> assuming 10 ops per route (very optimistic), it would be
12:51:10  <SmatZ> [14:25:38] <DorpsGek> SmatZ: 131.44 <== I thought this one
12:51:19  <Yexo> @calc 368800 * 10 / 10000 / 74
12:51:19  <DorpsGek> Yexo: 4.98378378378
12:51:37  <Yexo> nearly 5 days
12:51:55  <Yexo> @calc 3628800 * 10 / 10000 / 74
12:51:55  <DorpsGek> Yexo: 49.0378378378
12:51:59  <Yexo> oh, 50 days :p
12:52:07  <StM> :( :p
12:52:15  <StM> for some simple roads :p
12:52:30  <Yexo> just take 5 cities max :)
12:52:42  <Yexo> or don't compute an exact best but do with an approximation
12:53:03  <StM> yea but the math for a suboptimal route is VERY hard :)
12:53:59  <SmatZ> well
12:54:11  <Eddi|zuHause> TSP has really good heuristics
12:55:15  <SmatZ> you don't have exact data anyway
12:55:26  <SmatZ> there can be hill between A and B
12:55:34  <SmatZ> or lake
12:55:39  <StM> :X true
12:55:44  <StM> ARG! :p
12:56:09  <SmatZ> :)
12:57:05  <StM> Hmm maybe can i limit the options
12:57:20  <StM> for a city are only the 2 or 3 who are the most near interesting
13:05:08  <Eddi|zuHause> there are algorithms for calculating "neighbour" relationship
13:07:03  <StM> You dont want to know how much headache i already have :D
13:07:41  <Eddi|zuHause> hey, those are already solved problems... just look up the solutions and implement them :p
13:10:42  <StM> Thats only a reason for more headache :>
13:11:47  *** Fast2 [] has quit [Ping timeout: 480 seconds]
13:17:42  *** Muxy [] has quit [Quit: Back to the Goulp]
13:18:02  <De_Ghosty> drink more wateR?
13:21:21  *** luckz [] has joined #openttd
13:24:12  *** Chris_Booth [] has joined #openttd
13:28:51  *** Nickman_87 [] has quit [Ping timeout: 480 seconds]
13:42:41  <StM> If i do a keepBelowValue and a keepTop on a list, will the top then overrule the keepBelowValue?
13:43:59  <StM> it looks it doesnt, he will really remove the other values if i'm right? :)
13:50:53  *** Jhs [] has joined #openttd
13:54:27  <Yexo> KeepBelowValue removes all items with a value higher than the parameter
13:54:41  <Yexo> if after that you do KeepTop, only the first x items will be kept
13:54:48  <StM> :)
13:57:31  *** Nickman_87 [] has joined #openttd
13:57:40  *** Nickman_87 is now known as Nickman87
14:18:44  *** Zahl [] has joined #openttd
14:45:44  *** Chris_Booth is now known as Guest500
14:45:47  *** Chris_Booth [] has joined #openttd
14:51:59  *** Guest500 [] has quit [Ping timeout: 480 seconds]
14:53:57  <Belugas> hello
14:56:01  *** sulai [] has joined #openttd
15:05:18  *** Biolunar [] has quit [Quit: gn8]
15:10:29  *** Lakie [~Lakie@] has joined #openttd
15:17:31  *** Singaporekid [] has joined #openttd
15:20:23  <_ln> you could say that
15:23:50  <Nickman87> Anyone know if it is possible to add internal padding to an WWT_EDITBOX?
15:29:29  <Nickman87> I want to lower the text inside it by one pixel
15:30:19  <Nickman87> Rubidium, you fixed the savegames I see? :)
15:36:46  *** sulai [] has quit [Ping timeout: 480 seconds]
15:43:30  *** Polygon [] has joined #openttd
15:48:26  *** Dred_furst [] has quit [Read error: Connection reset by peer]
15:52:53  *** oskari89 [] has joined #openttd
15:53:53  *** Fast2 [] has joined #openttd
16:01:27  <SmatZ> /me was in bed all day long... hope I will get better for tommorow :)
16:04:33  <FauxFaux> After spending a whole day in bed, pretty much everything is worse.
16:05:04  <SmatZ> :(
16:08:23  *** _ln [] has quit [Quit: reboot]
16:15:46  * Belugas would LOVE to spend all day in bed...
16:16:15  <Belugas> if nit possible, can i at least get out AFTER 6:00am?
16:16:20  <Belugas> ppleeeeeaaaase???
16:18:34  *** frosch123 [] has joined #openttd
16:23:12  *** Pikka [PikkaBird@] has joined #openttd
16:23:36  <Pikka> Singaporekid what have you done
16:23:52  *** Doorslammer [] has quit [Ping timeout: 480 seconds]
16:26:46  *** Doorslammer [] has joined #openttd
16:29:46  <Singaporekid> who knows
16:30:29  <Pikka> okay, well don't do it again
16:35:27  *** Zuu [] has joined #openttd
16:36:32  *** SHADOW-XIII [] has joined #openttd
16:36:51  <SHADOW-XIII> @all: hi
16:37:28  <Pikka> hello
16:37:44  <SHADOW-XIII> how is going ?
16:38:17  <Pikka> it's going fine
16:38:48  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
16:39:21  <SHADOW-XIII> i finished my uni and looking for it job now ... :/
16:41:13  *** Prof_Frink [] has joined #openttd
16:43:05  *** SHADOW-XIV [] has joined #openttd
16:43:53  <SHADOW-XIV> is ourdge around ?
16:44:56  <Pikka> orudge gets around round round...
16:45:37  *** Progman [] has quit [Remote host closed the connection]
16:47:41  *** SHADOW-XIII [] has quit [Ping timeout: 480 seconds]
16:48:59  <Singaporekid> orudge is round?
16:49:20  <Pikka> yes
16:51:19  <SHADOW-XIV> anyone here can send google wave invitations ?
16:52:21  <StM> nope :(
16:52:22  <SHADOW-XIV> suppose not
16:53:01  *** Jhs [] has quit [Quit: Leaving]
17:03:22  <Pikka> hmm
17:03:46  <Pikka> orude is just post on the forums
17:03:48  <Pikka> and I am to bed
17:03:50  <Pikka> g'night
17:03:51  *** Pikka [PikkaBird@] has quit []
17:13:41  <SHADOW-XIV> anyone from UK oriented at least a bit about job market ?
17:13:50  *** SHADOW-XIV is now known as SHADOW-XIII
17:15:46  *** Terkhen [] has joined #openttd
17:15:59  <Terkhen> hello
17:16:02  <SHADOW-XIII> hi
17:17:47  * SHADOW-XIII slaps orudge around a bit with a large trout
17:18:22  <Prof_Frink> SHADOW-XIII: He's in t'shower.
17:19:18  <Rubidium> SHADOW-XIII: why do you need orudge?
17:19:55  <SHADOW-XIII> 30 min?
17:20:05  <SHADOW-XIII> he isnt a girl  :)
17:20:17  <SHADOW-XIII> i need to ask him thing
17:22:28  <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
17:22:32  <Rubidium> just ask the question
17:23:06  <SHADOW-XIII> apparently he is here but he is not :)
17:23:21  <Belugas> or use a very nice feature given to you by the forums: PM ;)
17:23:54  <Rubidium> for what it's worth, I usually ignore the 'is Rubidium here' questions
17:24:32  <SHADOW-XIII> Owen does not from what I know :P
17:25:19  <SHADOW-XIII> maybe someone can give me his opinion
17:25:27  <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)
17:25:37  <SHADOW-XIII> fund = *found
17:26:15  <SHADOW-XIII> but this training so damn expensive, otoh smells fishy like a scam but who knows
17:26:29  <StM> Do you need to pay it on your own?
17:26:32  <StM> Dont do it :)
17:27:02  <Prof_Frink> Anyone guaranteeing a job in the current economic climate is lying.
17:27:12  <StM> yea
17:28:05  <SHADOW-XIII> yh, pay on my own
17:28:21  <StM> dont do it :)
17:30:26  <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
17:32:05  <SHADOW-XIII> just wanted to ask Owen is it normally look like that or it's not normal
17:34:57  <Belugas> do you have to pay them for the courses and all?  if so, don't
17:35:12  * Rubidium thinks Owen doesn't know much about those things
17:36:45  <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.
17:38:12  *** Alberth [] has joined #openttd
17:38:51  <SHADOW-XIII> 4 courses nearly 10k, can be done via deposit 3k + rest over paying next 12 months
17:40:16  <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
17:40:58  <SHADOW-XIII> suppose so
17:43:43  *** bb10 [] has joined #openttd
17:43:47  <fonsinchen> in cargopacket.cpp:156 you're still creating a CargoList tmp which you don't use anywhere.
17:45:19  <CIA-4> OpenTTD: translators * r17738 /trunk/src/lang/russian.txt:
17:45:19  <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
17:45:19  <CIA-4> OpenTTD: russian - 1 changes by Lone_Wolf
17:45:28  <Rubidium> hmm, that the compiler doesn't warn about that
17:45:43  <SmatZ> my words :-p
17:46:41  * SHADOW-XIII pre-ordered Windows 7
17:46:49  <Rubidium> poor you
17:46:54  <SmatZ> hehe
17:47:11  <CIA-4> OpenTTD: rubidium * r17739 /trunk/src/cargopacket.cpp: -Cleanup: compiler didn't warn about an unused variable, fonsinchen did
17:48:41  <Ammler> wasn't there once a discussion about png support from grfcodec?
17:49:01  <Rubidium> yes
17:49:14  <Rubidium> wasn't there once an implementation of that?
17:49:16  <Rubidium> no
17:49:19  <fonsinchen> :)
17:49:20  <SHADOW-XIII> i had Win 7 beta and got Win 7RC and runs great on my laptop (which lost Win Vista during hdd failure)
17:49:33  <Ammler> Rubidium: just because "someone" didn't or not possible?
17:50:09  <Rubidium> there is, AFAIK, no reason why it's not possible
17:50:34  <SHADOW-XIII> my first Windows (box) ... preordered cost 80 pounds less than normal price
17:50:57  <Ammler> was dalestan involved in that discussion?
17:51:09  <Rubidium> don't know
17:51:38  <Rubidium> guess he was:
17:52:19  <Ammler> m?h :-P
17:58:32  *** Zahl_ [] has joined #openttd
17:58:57  *** Zahl [] has quit [Remote host closed the connection]
17:58:57  *** Zahl_ is now known as Zahl
18:10:36  <Nickman87> Ammler, you tried my patch yet? :D
18:11:19  <Ammler> no, I wait for next and text all 3 together :-P
18:12:23  <Nickman87> three patches? What are you expecting of me? :D
18:12:54  <Nickman87> I'll be off for a while ;)
18:13:01  <Ammler> coding?
18:13:04  <Nickman87> :D
18:13:46  *** sulai [] has joined #openttd
18:18:17  *** Zuu [] has quit [Ping timeout: 480 seconds]
18:29:03  *** boekabart [] has joined #openttd
18:37:08  *** sulai_ [] has joined #openttd
18:38:35  *** Zuu [] has joined #openttd
18:41:44  *** welshdragon [~markjones@] has quit [Quit: welshdragon]
18:44:06  *** sulai [] has quit [Ping timeout: 480 seconds]
18:47:31  *** SHADOW-XIV [] has joined #openttd
18:48:44  *** KenjiE20 [~KenjiE20@] has quit [Ping timeout: 480 seconds]
18:49:35  *** SHADOW-XIV [] has quit []
18:52:39  *** SHADOW-XIII [] has quit [Ping timeout: 480 seconds]
18:53:23  <fonsinchen> With newgrf, is it possible to define vehicles with capacity > 65535 units?
18:53:46  <frosch123> when using multiple parts
18:54:17  <frosch123> 0x7EFF is the maximum capacity per articulated part
18:54:39  <frosch123> hmm, no, you can cheat to 0x7fff
18:54:48  <fonsinchen> @calc 0x7fff
18:54:48  <DorpsGek> fonsinchen: 32767
18:55:18  <Alberth> that is a number you should know :)
18:55:50  <frosch123> ohoh, ships and aircraft can use full 16 bit
18:56:04  <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.
18:56:18  <fonsinchen> I probably can assert on that.
18:56:56  <frosch123> uint16 cargo_cap; <- for sure :p
18:57:32  <fonsinchen> I have: if (last->SameSource(cp)) last->Merge(cp);
18:57:39  <fonsinchen> so this can be more, technically
18:57:41  *** Progman [] has joined #openttd
18:58:01  <fonsinchen> but not really as the capacity of the vehicles is limited to 2^16
18:58:05  <frosch123> (that was Vehicle::cargo_cap btw)
18:58:14  <fonsinchen> ah, OK
18:58:22  <fonsinchen> then it should really be safe
19:07:24  <Rubidium> stations?
19:11:59  <frosch123> do stations have an overflow check, or will the cargo just vanish when you unload 2^32 units?
19:12:13  *** HerzogDeXtEr [~Flex@] has joined #openttd
19:13:04  <frosch123> oh, single packets are also 16bit
19:14:18  <Rubidium> not sure
19:14:59  <fonsinchen> That's only for vehicles
19:15:00  <Rubidium> probably overflow at 2**31, although... it's (on rating updates) limited
19:15:23  <Rubidium> to something considerably lower than that
19:15:26  <fonsinchen> I have different subclasses of cargolist for vehicles and stations
19:16:42  <fonsinchen> In trunk, CargoList has an overflow check for Append, btw
19:17:32  <frosch123> but AddToCache does not have any
19:18:48  <CIA-4> OpenTTD: alberth * r17740 /trunk/src/company_gui.cpp: -Codechange: Extract financial expenses drawing routines.
19:19:29  *** HerzogDeXtEr1 [~Flex@] has quit [Ping timeout: 480 seconds]
19:23:05  <fonsinchen> We implicitly expect the difference between uint (CargoList::count) and uint16 (CargoPacket::count) to be large enough. That's somewhat evil.
19:25:00  <Rubidium> I really wonder how you would want to get 2 billion cargo into a cargolist that quickly
19:26:43  <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
19:27:12  <fonsinchen> that's what I mean with "somewhat". It's not that bad.
19:28:06  <fonsinchen> but there might be machines with sizeof(uint) < 32.
19:28:14  <Rubidium> nope
19:28:17  <fonsinchen> s/32/4/
19:28:27  <frosch123> you can make a industry that produces 65535 units everytime a vehicle unloads the next gradual loading step
19:28:41  <fonsinchen> I though the C++ standard allowed that ...
19:28:59  *** Muxy [] has joined #openttd
19:29:09  <Rubidium> it might allow that, but stdafx.h doesn't allow it
19:29:27  <fonsinchen> probably we're safe then
19:29:54  *** stuffcorpse [~stuffcorp@] has quit [Remote host closed the connection]
19:30:06  *** sulai_ [] has quit [Ping timeout: 480 seconds]
19:30:10  *** stuffcorpse [~stuffcorp@] has joined #openttd
19:35:20  <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
19:41:56  *** sulai [] has joined #openttd
19:45:14  *** KenjiE20 [~KenjiE20@] has joined #openttd
19:51:39  *** Singaporekid [] has quit [Quit: Leaving]
19:51:40  *** KritiK [] has joined #openttd
19:55:07  *** Doorslammer [] has quit []
19:56:32  *** _ln [] has joined #openttd
20:00:47  *** Brianetta [] has joined #openttd
20:09:57  *** bb10 [] has quit [Ping timeout: 480 seconds]
20:10:07  *** boekabart [] has quit [Ping timeout: 480 seconds]
20:11:48  *** andythenorth [] has joined #openttd
20:21:22  *** Alberth [] has left #openttd []
20:23:15  *** frosch123 [] has quit [Remote host closed the connection]
20:28:11  *** Rubix`` [~wrqwer@] has joined #openttd
20:34:32  *** Eddi|zuHause [] has quit [Remote host closed the connection]
20:35:00  *** Eddi|zuHause [] has joined #openttd
20:41:07  * Muxy is happy, watching gui works...
20:42:01  <andythenorth> evening
20:46:02  *** Rubix`` [~wrqwer@] has quit [Quit: Ping timeout: 540 seconds]
20:54:58  *** Xaroth_ is now known as Xaroth
20:55:28  *** Zuu [] has quit [Quit: Leaving]
20:55:49  *** Zuu [] has joined #openttd
20:56:07  <Zuu> Nickman87: Are you there?
20:58:26  <CIA-4> OpenTTD: rubidium * r17742 /trunk/src/network/ (5 files in 2 dirs): -Codechange: remove unused variable from Recv_Packet
21:00:11  * Zuu crosses his fingers for that the upgrade of VS Express didn't cause OpenTTD to stop compile.
21:01:01  <Zuu> hmm, it tid. png.h has went out of search path..
21:01:05  <Zuu> did*
21:01:17  <Nickman87> I am here yes Zuu :)
21:02:03  <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.
21:03: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.
21:03:26  <Nickman87> I think I started from an updated version made by planetmaker for revision r16039
21:04:01  <Zuu> Okay, hmm, that version is not in the thread right?
21:04:12  <Nickman87> I got it here:
21:04:18  <Nickman87> Ammler lead me to that page :)
21:04:51  <Zuu> I'll check that one too. 16039 is pririor to the window got nestified right?
21:04:52  <Nickman87> it is possible that I made some small adjustments to the code yes, I didn't really compare them both one-on-one :)
21:04:59  <Nickman87> yes indeed
21:06:15  <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.
21:06:54  <Nickman87> if you want to you can point them out and I can take a look at it too :)
21:07:14  <Zuu> One thing I noticed is that you don't give focus to the edit box when the window is created.
21:07:20  <Nickman87> My intentions were to just port it to the new system, not to make changes to it just yet :)
21:07:48  <Nickman87> at line 150: this->SetFocusedWidget(SLW_FILTER_TEXT);
21:07:53  <Zuu> Yep
21:08:02  <Nickman87> but maybe it should be in the InitializeFilterTextWidget function...
21:08:24  <Nickman87> brb ;)
21:09:01  <Zuu> Hmm, actually it is the other way around.
21:09:08  *** StM [] has quit []
21:09:16  <Zuu> You give focus to it when it is created, which the original v22 does not do.
21:09:26  <Zuu> Instead the user have to press the f-key to focus it.
21:09:40  <Zuu> Otherwise if you open the sign list all hotkeys will stop to work.
21:10:16  <Zuu> (It was long time I used the patch or looked on it so I am a bit rusty on it)
21:12:00  <Zuu> <-- Good work. The path to "OpenTTD essentials" was wrong or the directory was unziped at the wrong location. :-)
21:12:02  <Ammler> Zuu: Nickman87, did you see my post about ESC and focus?
21:12:08  <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.
21:12:14  <Zuu> Ammler: I did see that
21:12:33  <Zuu> I could not see anything strange in v22, but will test on nickmans update as soon as I have a binary.
21:13:08  *** oskari89 [] has quit [Quit: Utm Aœ - Aja 35]
21:13:36  <Muxy> ok men, watch GUI patch published on tt-forum.
21:14:11  *** andythenorth [] has quit [Quit: andythenorth]
21:14:53  <Ammler> Zuu: wasn't it possible to have the sign list open and chat at same time?
21:15:28  <Zuu> Ammler: Yes it was the idea with the widget focus patch.
21:16:42  <Ammler> I tested, it might be a "feature" of the new gui system
21:16:59  <Ammler> you can't chat while the password textfield is open either
21:17:15  <Zuu> You should be able to try with the savegame window and the chat. etc.
21:17:19  <Zuu> But i see you have done that.
21:17:27  <Ammler> oh
21:17:39  <Zuu> Hmm, strange
21:17:44  <Zuu> I'll take a look
21:18:01  <Zuu> Have mostly been doing AI-stuff so haven't really paid notice.
21:18:12  <Ammler> yes, you can't
21:18:34  <Ammler> well, mostly it doesn't matter
21:18:41  <Ammler> but for the sign list, if would be nice
21:18:51  <Ammler> it*
21:20:36  <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.
21:21:50  <Zuu> Hmm, seams to work okay here. I can switch between eding my company name and the savegame name.
21:22:09  <Zuu> Or is it specficly the combination with the chat window that doesn't work?
21:22:09  <Ammler> without patch?
21:22:16  *** Muxy [] has quit [Quit: PACKET_CLIENT_QUIT]
21:22:18  <Zuu> That is without the sign list patch.
21:22:22  <Zuu> r17739
21:22:48  <Ammler> I have to admit, I didn't try with plain trunk
21:23:04  <Zuu> What did you use?
21:23:17  <Ammler> the patch from nick
21:23:39  <Zuu> And that one killed the possibility to change between two edit fields?
21:23:46  <Ammler> yes
21:23:57  <Ammler> or it isn't possible in trunk either
21:24:08  <Zuu> Even two edit fields apart form the signs window?
21:24:31  <Ammler> save window and chat doesn't work
21:24:32  <Zuu> My binary is done, so let me test...
21:25:58  *** tux_mark_5 [] has quit [Quit: KVIrc Insomnia 4.0.0, revision: , sources date: 20090115, built on: 2009/03/07 00:45:02 UTC]
21:26:52  <Zuu> I can change between the save window and the chat window with Nicks patch.
21:27:00  <Zuu> There is a problem though with the sign list patch.
21:27:17  <Zuu> It opens the OSK when it is clicked and does not have focus.
21:28:09  <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.
21:28:19  <Zuu> Eg. globally focused
21:28:53  <Zuu> There is a Window function probably in the global scope that checks if a widget is globaly focused.
21:29:05  <Zuu> Unless the devs have removed it.
21:29:36  *** Fast2 [] has quit [Ping timeout: 480 seconds]
21:32:28  <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?
21:33:10  <Eddi|zuHause> oh... speaking of which, i had edit box focus trouble with the timetable patch
21:33:26  <Eddi|zuHause> maybe someone with actual gui knowledge could look over that?
21:33:42  *** Nite_Owl [] has joined #openttd
21:34:02  <Nite_Owl> Hello all
21:36:56  <Nickman87> back
21:38:00  <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)
21:38:44  <Ammler> Nickman how to leave the focus from the list?
21:38:59  <Nickman87> currently not I think :)
21:39:17  <Nickman87> When I click inside another window, the focus gets changed though?
21:39:26  <Zuu> Previously you unfocused the edit box with escape so that you could perform regular hotkeys
21:39:36  <Zuu> Including 'f' to re-focus the edit box
21:40:16  <Nickman87> yeah, esc doesn't seem to un-focus
21:40:57  <Nickman87> this->focused_widget = 0;           // Unfocus the text box
21:41:05  <Nickman87> that should do it, but probably changed in the new system
21:41:05  <Zuu> Yeah I saw that one
21:41:54  <Zuu> The SetFocusedWidget function does still take widget indexes and does not support a special index from what I can see.
21:42:22  <Zuu> I'm currently looking into why the OSK opens when you focus the edit box for the first time.
21:42:47  <Nickman87> it happens in other windows to I think?
21:42:53  <TrueBrain> Rubidium: 3252 misses the most important step: HOW it fails ... how did you confirm it?
21:42:55  <Nickman87> for example the edit company name window
21:43:10  <Zuu> Nickman87: Nope
21:43:26  <Nickman87> Happens here? :)
21:43:40  <Rubidium> TrueBrain: not personally, but... lots of people have been complaining about it
21:43:41  <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.
21:43:48  <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
21:43:51  <TrueBrain> lots of people == 1 bug report
21:43:55  <Zuu> This time you can click on the edit box to focus it without open the OSK window.
21:44:14  <Zuu> Nickman87: Hmm, okay
21:44:15  <Rubidium> TrueBrain: yes, lots of people - 1 didn't file a bug report, even when they were asked to do so
21:44:34  <TrueBrain> well, I can't reproduce it when I try, and when they retry it works
21:44:37  <Nickman87> the functionality is the same inside the sign list window
21:44:37  <TrueBrain> which leaves me completely in the dark
21:44:40  <Nickman87> so it seems :)
21:44:40  <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
21:44:51  <TrueBrain> see, that error message is more useful
21:44:59  <Zuu> Nickman87: Can confirm that that did not happen in r14658, so that bug has been introduced. I'll take a look
21:45:22  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
21:45:23  <Nickman87> Then it has to do with the new widget system perhaps?
21:45:31  <Rubidium> TrueBrain: < ac84> I was trying to upload my lib to Bananas, but receiving error "Unexpected error while uploading".
21:45:33  <TrueBrain> Rubidium: I have 0 clues what goes wrong, even more as nothing changed, and it works most of the time ...
21:45:34  <Zuu> It is probably in the mess called DispatchLeftClickEvent function.
21:45:44  <Nickman87> :D
21:46:01  <Nickman87> yeah, when a window looses focus, so should all the edit boxes...
21:46:01  <TrueBrain> either way, I will put it on my list of things to do ..
21:46:03  <Zuu> It is quite big and hard to grasp from just reading it a few  seconds.
21:47:00  <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.
21:47:13  <Zuu> And then there is a global pointer _focused_widget
21:47:18  <Nickman87> that is another way to look at it yes
21:47:27  <Zuu> This is why it is important too separate global and local focus.
21:47:46  <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 :)
21:48:40  <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.
21:48:49  <Nickman87> indeed :)
21:49:04  <Zuu> And I either can continue to argue or try to understand the code hehe
21:49:39  <Nickman87> :D
21:49:58  <Zuu> Should probably study the old code to see how it did work before trying to understand why it does not work now. :-)
21:50:20  <Nickman87> :)
21:50:30  <Nickman87> that is often helpfull
21:51:25  <Nickman87> ok, I fixed it that you can unfocus the edit box by pressing esc, should I remove the autofocus to?
21:51:37  <Zuu> Yes I think so
21:51:55  <Zuu> Since you can press the f-key to focus it.
21:52:07  *** TheMask96 [] has joined #openttd
21:52:21  <Nickman87> indeed
21:52:26  <Zuu> And I would guess users would get more comfused when they wonder why the hotkeys stop working.
21:52:58  <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.
21:53:02  <Nickman87> done ;)
21:53:12  <Nickman87> yeah, that is indeed a bad choise
21:53:44  <Nickman87> But it is still impossible to close the window by pressing esc
21:54:15  <Nickman87> ah, but not all windows can be closed by pressing esc so that is not really a problem
21:55:50  *** welshdragon [~markjones@] has joined #openttd
21:59:14  <Nickman87> I'll be off for a while, going home, you can always post remarks in the thread ;)
21:59:28  <Nickman87> Don't know if I'll come back online tonight
22:02:55  <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.
22:03:16  <Zuu> And there is lot of corner cases in that one.
22:07:32  *** Nickman87 [] has quit [Ping timeout: 480 seconds]
22:08:50  *** Grelouk [] has quit [Read error: Connection reset by peer]
22:13:46  *** Cybertinus [] has quit [Remote host closed the connection]
22:16:07  *** sulai [] has quit [Ping timeout: 480 seconds]
22:16:28  *** Progman [] has quit [Remote host closed the connection]
22:24:55  *** fonsinchen [] has quit [Quit: Leaving.]
22:31:25  <Terkhen> good night
22:31:28  *** Terkhen [] has quit [Quit: ...]
22:32:58  <Zuu> Fix to the OSK-bug has now been uploaded to
22:34:03  <Zuu> I don't know when it was introduced. More than somewhere between 14658 and now.
22:34:23  *** Nickman_87 [] has joined #openttd
22:34:26  *** Nickman_87 is now known as Nickman87
22:35:22  *** Rubix`` [~wrqwer@] has joined #openttd
22:36:52  *** Rubix`` [~wrqwer@] has quit []
22:40:49  <Eddi|zuHause> i hate the forum
22:41:04  <Eddi|zuHause> it way too frequently forgets my login
22:41:42  <Eddi|zuHause> and when i relogin, it doesn't return to the page that i visited, but instead to the forum main page
22:41:55  *** Nite_Owl [] has quit [Quit: Read You Soon]
22:42:49  <_ln> that's why irc is better
22:44:12  <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.
22:45:43  <Zuu> But checking the thread it is not really obvious from my uploads (without reading my posts) that those two versions exist.
22:46:52  <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.
22:48:07  <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.
22:49:30  <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.
22:52:21  *** Coco-Banana-Man [] has quit [Quit: Joyful it seems - but then suddenly - by one false move it's blown away]
22:55:46  <Nickman87> hmmmm, Zuu I don't really see what you mean?
22:56:16  <Zuu> Devs usually prefere patches in several stages whet it is possible.
22:56:19  <Nickman87> My arrow keys do nothing?
22:56:21  <Nickman87> :)
22:56:31  <Zuu> The smaller the patches the better
22:56:41  <Zuu> Then you have droped some features...
22:56:45  <Nickman87> yeah, but I don't see the arrow key code?
22:56:46  <Nickman87> :)
22:57:22  <Zuu> Hmm, you still have WKC_UP etc.
22:57:36  <Nickman87> you mean the "SelectNextSign" and "SelectPreviousSign" functions?
22:57:44  <Zuu> And the SelectNextSign/SelectPreviousSign functions..
22:57:45  <Zuu> Yep
22:58:02  <Zuu> When the edit box is focused, try arrow down
22:58:09  <Nickman87> yeah, but when I press the arrow keys, it does nothing?
22:58:29  <Nickman87> must have broken it somehow?
22:59:21  <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.
22:59:22  <Nickman87> I see the code
22:59:35  <Nickman87> I never get a blue marked sign :)
22:59:58  <Zuu> You seam to have uncommented the invalidate code
23:00:14  <Zuu> Your patch have //this->SetDirty();
23:00:19  <Zuu> :-)
23:00:27  <Nickman87> where?
23:01:28  <Zuu> Though you later make the list widget dirty...
23:01:44  <Zuu> In SelectNextSign and SelectPreviousSign.
23:02:26  <Zuu> It has some uncommented lines in it.
23:02:35  *** Lakie [~Lakie@] has quit [Quit: Sleep]
23:02:43  <Nickman87> I'm trying something ;)
23:03:56  <Nickman87> still no selecting...
23:05:37  <Zuu> Are you on Visual Studio or something else with a good debugger?
23:06:01  <Zuu> Then you can try to see what happens when you hit arrow down and see if it goes wrong somewhere.
23:06:08  *** welshdragon [~markjones@] has left #openttd []
23:06:12  <Zuu> I'll do that as soon as the compiler is done.
23:06:52  *** Brianetta [] has quit [Quit: Tsch?ss]
23:07:23  <Nickman87> yes, I'm on VS :)
23:07:29  <Nickman87> going to check now :)
23:11:56  <Nickman87> now its working, the "if" check wasn't working anymore ;)
23:12:16  <Zuu> Try to replace it with this->IsWidgetFocused(f
23:12:30  <Zuu> this->IsWidgetFocused(SLW_FILTER_TEXT)
23:12:45  <Nickman87> I have this now: this->HasEditBoxFocus(this, SLW_FILTER_TEXT) :D
23:12:54  <Nickman87> but yours sounds more logical
23:13:29  <Nickman87> but indeed, those two different patches can be split very easily
23:14:02  <Nickman87> but now I have to go to bed, have to get up in about 6 hours already so... :)
23:14:10  <Zuu> Hmm, I wonder why HasEditBoxFocus is not static..
23:14:31  <Nickman87> yeah, its strange that I have to pass my window to it...
23:14:54  <Zuu> But they might do different things thoug.
23:15:11  <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...
23:15:13  <Zuu> IsFocusedWidget only checks for local focus.
23:15:30  <Zuu> So HasEditBoxFocus might actually be better.
23:16:45  <Nickman87> but wont it be true even if the widget is not focused then?
23:18:48  <Nickman87> IsWidgetFocused is not good, it also triggers events when the window is not focused
23:18:52  *** Polygon [] has quit [Quit: Flieht, ihr Narren!]
23:18:54  <Nickman87> I'll try the other one again
23:19:36  <Zuu> Hmm
23:19:37  <Zuu> yea
23:20:08  <Zuu> I have to check if HasEditBoxFocus was mostly intended for internal use in that class.
23:20:38  <Nickman87> HasEditBoxFocus doesnt have that problem, but since I have to pass the window to it, it looks a bit strange
23:21:29  <Zuu> HasEditBoxFocus is indeed not intended to be used in this case.
23:21:39  <Zuu> use this->IsWidgetGloballyFocused( .. )
23:21:44  <Nickman87> trying IsWidgetGloballyFocused now
23:21:46  <Nickman87> hehe :d
23:21:57  <Zuu> That one is intended for this case.
23:22:09  <Nickman87> just saw it existed ;)
23:22:35  <Nickman87> perfect
23:22:56  <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.
23:24:04  <Nickman87> It is only used inside the "misc_gui.cpp" file it seems
23:24:21  <Nickman87> and querystring_gui.cpp once
23:24:29  <Nickman87> .h I mean
23:24:42  <Zuu> It is declared in .h
23:25:01  <Nickman87> yeah
23:25:17  <Nickman87> so that is allright
23:25:21  <Zuu> But it seams only QueryString uses it and no children of it. So it could be made private.
23:25:24  <Nickman87> it is never used outside of the class
23:25:40  <Nickman87> but it calls "if (w->IsWidgetGloballyFocused(wid)) return true;" itself :)
23:26:44  <Nickman87> so it is only used for OSK things?
23:27:07  <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).
23:27:39  <Zuu> This is one of the reasons why you can only have one text edit box per window.
23:27:46  <Nickman87> well, I'm off for today, need some sleep :)
23:27:48  <Zuu> Focus used to be another reason.
23:27:56  <Zuu> Yea, good night
23:27:57  <Nickman87> but that is not a problem anymore?
23:28:06  <Nickman87> night :)
23:28:41  <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.
23:29:43  <Nickman87> I'll see if I can split the code into two base patches without much interference from eachother tomorrow ;)
23:29:54  <Nickman87> So you should be able to apply the patches independant of eachother
23:29:59  <Zuu> If you havent looked into hg queues, take a look on that.
23:30:29  <Nickman87> hg queues?
23:30:48  <Zuu> Well, if you don't mind sure. But don't push you into it just for me.
23:30:58  <Zuu> Do you know hg?
23:31:06  <Nickman87> what is hg? :)
23:31:08  <Zuu> The versioning system
23:31:18  <Zuu> Like svn but you can run it locally without a server
23:31:34  <Nickman87> yeah, I have some of that installed I think :)
23:31:40  <Zuu> There is a module to it called queues which makes it very easy to maintain patches that apply in series.
23:31:56  <Nickman87> I have TortoiseHG :)
23:32:33  <Zuu> You tell it which patch you are at. Make your changes. Refresh patch. Go to next patch. Do some thing. Refresh..
23:32:53  <Nickman87> kewl :)
23:32:56  *** Eddi|zuHause [] has quit []
23:33:08  <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.
23:33:11  <Nickman87> I'll take a look at it :)
23:33:29  *** Eddi|zuHause [] has joined #openttd
23:33:51  <Zuu> And leave TortoiseHG aside, it doesn't contain the queue functions.
23:34:14  <Nickman87> ah :D
23:34:16  <Zuu> So you will need to use the terminal, but it is quite straight forward.
23:34:56  <Nickman87> I'll search around about it tomorrow ;)
23:35:03  <Nickman87> night!
23:35:08  <Zuu> Night!
23:36:40  *** lugo [] has quit [Remote host closed the connection]
23:43:07  *** Nickman87 [] has quit [Ping timeout: 480 seconds]
23:44:31  *** PeterT [] has joined #openttd
23:48:27  *** PeterT [] has quit []

Powered by YARRSTE version: svn-trunk