IRC logs for #openttd on OFTC at 2009-10-07
⏴ go to previous day
00:03:53 *** KenjiE20|LT has joined #openttd
00:40:37 *** Rubix`` has joined #openttd
00:48:41 <Rubidium> just to cut another hour of TrueBrain's sea of green I say: good night :)
01:17:28 <PeterT> any programmers willing to help me with something?
01:23:42 <Eddi|zuHause> they are all fed up with you.
02:00:03 *** Xaroth_ has joined #openttd
02:03:30 *** Rubix`` has joined #openttd
02:48:29 *** DaleStan is now known as Guest463
02:48:29 *** DaleStan_ has joined #openttd
02:48:30 *** DaleStan_ is now known as DaleStan
05:37:56 *** Polygon has joined #openttd
06:18:47 *** Cybertinus has joined #openttd
06:32:24 *** Phoenix_the_II has joined #openttd
06:38:19 *** thepalm has joined #openttd
06:40:12 *** Doorslammer has joined #openttd
06:42:32 <Rubidium> morning, yup it's early
06:55:42 *** TheMask96 has joined #openttd
07:09:15 *** Nickman_87 has joined #openttd
07:48:36 *** fonsinchen has joined #openttd
08:10:49 *** thepalm 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:55 <CIA-4> OpenTTD: list, use cache updates instead of rebuilds. This is usually faster because of
08:31:55 <CIA-4> OpenTTD: primarily gradual loading that only moves a (small) part of the cargo each time.
08:31:55 <CIA-4> OpenTTD: Based on patch by fonsinchen.
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: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:41 <thepalm> the patch doesn't apply cleanly using commandline patch and Im not sure what else to try
09:00:56 <Spoons> Apply the patch to trunk then switch?
09:06:42 *** sdafsdf has joined #openttd
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: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: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: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:55:43 *** Xaroth_ is now known as Xaroth
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:34 <Noldo> hg.openttd.org and bugs.openttd.org are the best sources
10:10:17 *** Belugas has joined #openttd
10:10:17 *** ChanServ sets mode: +o Belugas
10:16:00 <sulai> oh it's been removed 11 hours ago, thanks Noldo
10:37:26 *** Xaroth_ has joined #openttd
10:53:21 *** tux_mark_5 has joined #openttd
11:04:33 <Noldo> Yexo: are NoAIs run only on the server?
11:05:02 <Noldo> do they se the same DoCommand structure as normal clients?
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: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:14 <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: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:52 <TrueBrain> (in exec of course)
11:11:03 <TrueBrain> well, in SP not of course
11:11:42 <SmatZ> I shouldn't talk about things I think I know about, but I don't :-p
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: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:13:03 <SmatZ> if the only needed change was a mutex in DoCommandP, it would be easy :)
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: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:44 <Rubidium> the only thing is that humans 'clone' a (small) part of the game state
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: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 *** tux_mark_5 has joined #openttd
11:21:48 <Noldo> Rubidium: can you give examples about 'certain information'
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 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: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:27:32 *** 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: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:50:44 *** ChanServ sets mode: +v tokai
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: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: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:52 <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 has joined #openttd
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 _3_.xxx, not _2_.xxx
12:50:30 <SmatZ> [14:49:54] <Yexo> and the first result was _3_.xxx, not _2_.xxx <== what result?
12:50:38 <Yexo> <@DorpsGek> SmatZ: 3628800
12:50:41 <Yexo> <SmatZ> @calc 2628800 / 20000
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:55 <Yexo> @calc 3628800 * 10 / 10000 / 74
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:02 <StM> yea but the math for a suboptimal route is VERY hard :)
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: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:24:12 *** Chris_Booth has joined #openttd
13:42:41 <StM> If i do a keepBelowValue and a keepTop on a list, will the top then overrule the keepBelowValue?
13:43:58 <StM> it looks it doesnt, he will really remove the other values if i'm right? :)
13:54:27 <Yexo> KeepBelowValue removes all items with a value higher than the parameter
13:54:40 <Yexo> if after that you do KeepTop, only the first x items will be kept
13:57:31 *** Nickman_87 has joined #openttd
13:57:40 *** Nickman_87 is now known as Nickman87
14:45:44 *** Chris_Booth is now known as Guest500
14:45:47 *** Chris_Booth has joined #openttd
15:17:31 *** Singaporekid has joined #openttd
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:43:30 *** Polygon has joined #openttd
15:52:53 *** oskari89 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: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:18:34 *** frosch123 has joined #openttd
16:23:36 <Pikka> Singaporekid what have you done
16:26:46 *** Doorslammer has joined #openttd
16:30:29 <Pikka> okay, well don't do it again
16:36:32 *** SHADOW-XIII has joined #openttd
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:49:00 <Singaporekid> orudge is round?
16:51:19 <SHADOW-XIV> anyone here can send google wave invitations ?
17:03:46 <Pikka> orude is just post on the forums
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: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: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:20 <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: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:27:02 <Prof_Frink> Anyone guaranteeing a job in the current economic climate is lying.
17:28:05 <SHADOW-XIII> yh, pay on my own
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: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:46:41 * SHADOW-XIII pre-ordered Windows 7
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:14 <Rubidium> wasn't there once an implementation of that?
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?
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:29:03 *** boekabart has joined #openttd
18:47:30 *** SHADOW-XIV has joined #openttd
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: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:22 <fonsinchen> then it should really be safe
19:11:58 <frosch123> do stations have an overflow check, or will the cargo just vanish when you unload 2^32 units?
19:12:13 *** HerzogDeXtEr has joined #openttd
19:13:04 <frosch123> oh, single packets are also 16bit
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: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: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:29:09 <Rubidium> it might allow that, but stdafx.h doesn't allow it
19:29:27 <fonsinchen> probably we're safe then
19:30:10 *** stuffcorpse 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:45:14 *** KenjiE20 has joined #openttd
20:00:47 *** Brianetta has joined #openttd
20:11:48 *** andythenorth has joined #openttd
20:28:11 *** Rubix`` has joined #openttd
20:35:00 *** Eddi|zuHause has joined #openttd
20:41:07 * Muxy is happy, watching gui works...
20:54:58 *** Xaroth_ is now known as Xaroth
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: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: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: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:08:02 <Nickman87> but maybe it should be in the InitializeFilterTextWidget function...
21:09:01 <Zuu> Hmm, actually it is the other way around.
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: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:36 <Muxy> ok men, watch GUI patch published on tt-forum.
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:18:01 <Zuu> Have mostly been doing AI-stuff so haven't really paid notice.
21:18:34 <Ammler> well, mostly it doesn't matter
21:18:41 <Ammler> but for the sign list, if would be nice
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:18 <Zuu> That is without the sign list patch.
21:22:48 <Ammler> I have to admit, I didn't try with plain trunk
21:23:39 <Zuu> And that one killed the possibility to change between two edit fields?
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: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: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: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: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:45 <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: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: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: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 <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: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:34 <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: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:49:04 <Zuu> And I either can continue to argue or try to understand the code hehe
21:49:59 <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: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:55 <Zuu> Since you can press the f-key to focus it.
21:52:07 *** TheMask96 has joined #openttd
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:13 <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:51 *** welshdragon 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: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`` has joined #openttd
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: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 IRC
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: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: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: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: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: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: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 has left #openttd
23:06:12 <Zuu> I'll do that as soon as the compiler is done.
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:55 <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:54 <Nickman87> I'll try the other one again
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:40 <Zuu> use this->IsWidgetGloballyFocused( .. )
23:21:44 <Nickman87> trying IsWidgetGloballyFocused now
23:21:57 <Zuu> That one is intended for this case.
23:22:09 <Nickman87> just saw it existed ;)
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: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:25 <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:40 <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:57 <Nickman87> but that is not a problem anymore?
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:48 <Zuu> Well, if you don't mind sure. But don't push you into it just for me.
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: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:52 <Zuu> And leave TortoiseHG aside, it doesn't contain the queue functions.
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 ;)
continue to next day ⏵