Log for on 25th December 2012:
Times are UTC Toggle Colours
08:23:53  * Terkhen ponders if the layers of the new scenario format should have png metadata information or not
11:00:00  *** Zuu has joined
11:00:00  *** ChanServ sets mode: +v Zuu
12:11:23  *** frosch123 has joined
12:11:23  *** ChanServ sets mode: +v frosch123
12:30:58  *** Supercheese has quit IRC
12:31:29  *** Supercheese has joined
17:10:25  *** Zuu has quit IRC
17:42:44  <planetmaker> Hi, what is the sprites' lru? (spritecache.cpp:604ff)
17:43:48  <frosch123> least recently used
17:44:15  <frosch123> when the spritecache is full, it drops the sprites which have been used the longest time ago
17:44:53  <planetmaker> ah. Hm, maybe I should increase my spritecache :-)
17:49:07  <planetmaker> this crash george reports... it's weired at best. And the savegame is... well... of the type with many changed and added and removed newgrfs
17:51:09  <planetmaker> what's the most promising way to find out which newgrf causes dbg: [sprite] Tried to load character sprite #14 as a recolour sprite. Probable cause: NewGRF interference
17:51:55  <frosch123> add a conditional breakpoint
17:52:18  <frosch123> or even just add a breakpoint where the DEBUG output is
17:52:24  <planetmaker> meh. Even with all all newgrfs it complains about missing and wrong newgrfs... seems a hopeless cause nearly...
17:52:29  <frosch123> then see what draws it
17:52:40  <planetmaker> hm. yes
17:53:03  <frosch123> if it is drawing the viewprot
17:53:15  <frosch123> you can check the coordinates and determine the tile which is being drawn
18:02:38  <planetmaker> is it worth to test on such tempered map?
18:03:42  <frosch123> saves store no spritenumbers
18:04:05  <frosch123> so, if they are messed up, it should be reproducible with just the newgrf config
18:06:38  <frosch123> btw. this sprite #14 business remembers me about the firs issue
18:06:50  <frosch123> does firs still draw questionmarks?
18:07:12  <frosch123> back then i wondered whether it might be an nml issue
18:07:17  <planetmaker> yes, it does in parts still do that
18:07:25  <frosch123> but i failed to read firs code, so i have no clue what it tried to do
18:07:29  <planetmaker> in FIRS it's a programming issue with calculation of fences
18:07:52  <planetmaker> thus in FIRS I'm moderatly convinced that my code is buggy
18:35:03  <frosch123> <- i don't think it needs filtering for stuff like company+game settings or client+game or client+company
20:27:10  *** Zuu has joined
20:27:10  *** ChanServ sets mode: +v Zuu
20:35:23  <planetmaker> frosch123, I agree. The shown selection is quite nice. and sufficient
21:20:28  *** LordAro has joined
21:20:28  *** ChanServ sets mode: +v LordAro
21:20:44  <frosch123> hi LordAro
21:20:56  <frosch123> i did not quite understood what is missing on the release todo list
21:20:56  <LordAro> hey frosch123
21:22:10  <LordAro> basically should include modifying Template:OTTDVersions & "OpenTTD Release History" & obviously the wikipage for that version
21:22:24  <LordAro> doesn't really matter, but if you're documenting it...
21:25:15  <frosch123> hmm, that release history page looks quite useless considerung the ottdversions template :p
21:25:52  <LordAro> maybe, but they were both there before me :L
21:25:58  <LordAro> i just maintain them :)
21:26:59  <frosch123> added
21:27:15  <LordAro> yay :L
21:29:53  <LordAro> while we're at it, you/Rubidium forgot Template:Version :L
21:30:07  <LordAro> dunno what it's used for though
21:30:08  <frosch123> it's in the "after branch" section
21:30:35  <LordAro> no it's not "update wiki pages: Template:Version, FAQ General Questions"
21:30:39  <LordAro> :P
21:30:46  <frosch123> ah, that one, well that is only after stable
21:31:07  <frosch123> it's used in exactly one place, which says "the latest stable release ist {{version}}"
21:31:29  <LordAro> hence the "you/Rubidium" since it was set at 1.2.2 :P
21:31:34  <frosch123> oh, due to translations there are more places meanwhile
21:31:36  *** Eagle_Rainbow has joined
21:31:36  *** ChanServ sets mode: +v Eagle_Rainbow
21:32:12  <frosch123> LordAro: ah, ok :)
21:32:25  <frosch123> hi ER :)
21:32:31  <LordAro> heyo
21:32:51  <Eagle_Rainbow> hi frosch123
21:33:16  <Eagle_Rainbow> hi everyone and - merry Christmas to everyone!
21:34:10  *** FLHerne has joined
21:34:39  <Eagle_Rainbow> frosch123: Just read your email. Thanks for the insights; sounds like (1) - (3) was just a matter on the sequence of the patch (on which I wasn't convinced either); (4) I will have a second read with a bit more context some time later :)
22:06:25  <Eagle_Rainbow> mmhm.. I am a bit puzzled on the definition of DistanceSquare(TileIndex, TileIndex). It is defined as "return dx * dx + dy * dy", but reported to be the euclidian distance. Am I blind or is there missing the square root...?
22:09:06  <planetmaker> square of euclidean distance
22:09:15  <planetmaker> still it's euclidean. And not a jungle metric or so
22:09:23  <michi_cc> It's the squared euclidean distance (it's called DistanceSquare, isn't it?)
22:09:42  <Eagle_Rainbow> but the comment is "Also known as euclidian- or L2-Norm squared"
22:09:55  <planetmaker> yes. The norm
22:09:56  <frosch123> "squared"
22:10:04  <Eagle_Rainbow> or is the hyphen meant to go with "-norm"?
22:10:15  <planetmaker> nope
22:10:20  <planetmaker> euclidean is not a norm
22:10:39  <frosch123> planetmaker: sure it is :p
22:10:50  <frosch123> euclidian norm = L2 norm
22:10:51  <planetmaker> hm... yes :D. synonymous
22:11:14  <planetmaker> tbh, I guess I can't recall the norm being called euclidean. Always L2
22:11:21  <Eagle_Rainbow> but anyway - the function is intended to produce the squared value of the euclidean distance...
22:11:32  <frosch123> Eagle_Rainbow: anyway, all eucldian places in ottd use the square. instead of using sqrt the other side of the comparison is just squared as well
22:11:55  <Eagle_Rainbow> so, it's just an optimization to go with squared values, right?
22:12:01  <frosch123> instead of sqrt(...) < 20, you just do (...) < 400
22:12:21  <frosch123> yup, ottd contains no floats in the game mechanics
22:12:26  <Eagle_Rainbow> yes, but in my current case, I need the sqrt of the distance...
22:12:28  <frosch123> (only scripts may use them)
22:12:38  <Eagle_Rainbow> but on gui they are allowed?
22:12:41  <planetmaker> Eagle_Rainbow, where is the actual distance needed?
22:12:59  <frosch123> planetmaker: i assume the max aircraft distance thingie :p
22:13:18  <Eagle_Rainbow> yes :)
22:13:18  <frosch123> Eagle_Rainbow: gui should be fine
22:13:19  <planetmaker> yes... GS. We explained it recently in a bug report, I think :D
22:13:29  <planetmaker> don't compare map distances with aircraft distances
22:13:35  <planetmaker> use aircraft distances between tiles
22:14:08  <Eagle_Rainbow> !? Ok, apparently there's another thing which I don't know yet :)
22:14:10  <frosch123> floats just cannot be used in game mechanics, since we cannot rely on different processors returning the same result
22:14:21  <Eagle_Rainbow> frosch123: that's clear&ok
22:14:22  <planetmaker> don't ever try to match aircraft distances with real map distances. It's both arbitrary, but different units
22:14:35  <frosch123> planetmaker: Eagle_Rainbow is no AI author :p
22:14:52  * Eagle_Rainbow is ashamed :)
22:15:04  <planetmaker> I thought so... but ... then the question's background is very fuzy for me :-)
22:15:14  <frosch123> it's funny how you miss each other in your discussion
22:15:21  <planetmaker> :D
22:15:31  *** FLHerne has quit IRC
22:15:39  <Eagle_Rainbow> Background: I am currently trying myself on the second part of
22:17:13  <Eagle_Rainbow> it's providing the distance between two airports in the order list...
22:17:40  <frosch123> Eagle_Rainbow: anyway, what pm was refering to: there are two maximum distances in ottd
22:17:40  <Eagle_Rainbow> (in fact it's more - not just airports, but also depots, ... but that's a different story)
22:17:49  <frosch123> aircraft use euclidian
22:17:53  <Eagle_Rainbow> clear
22:17:54  <frosch123> while ships use manhattan
22:18:01  <Eagle_Rainbow> also known :)
22:18:13  <Eagle_Rainbow> and map distances are manhattan normed?
22:18:26  <planetmaker> oh, I missed that FS so far completely. Thanks. Valid request IMHO
22:18:28  <Eagle_Rainbow> and the fees are calculated via manhattan, right?
22:18:30  <michi_cc> Ah, DorpsGek misses op again, that's why we get no topic...
22:18:43  <frosch123> both things are exposed to ais, but ais are explicitly told to not rely on the manhatten thingie staying like that forever
22:19:02  <frosch123> @reload openttd
22:19:03  <michi_cc> ChanServ access list is a bit stupid for this channel, either no auto-op for DorpsGek, or almost the whole channel get's it.
22:19:10  <frosch123> hmm, how does that work :p
22:19:33  *** ChanServ sets mode: +o DorpsGek
22:20:32  <Eagle_Rainbow> so, ok - if I go with the euclidean one and use the sqrt myself I should be fine, right?
22:21:24  <frosch123> yup, gui is fine :)
22:22:45  <michi_cc> frosch123: You can tell ChanServ to auto-op everybody with CHANOP or MASTER on the access list, but then we have more ops than other channel members.
22:22:56  <michi_cc> @reload openttd
22:22:57  <Eagle_Rainbow> thx
22:24:02  <frosch123> @commit
22:24:02  <DorpsGek> frosch123: Commit by peter1138 :: r24853 /trunk/src (3 files) (2012-12-25 22:10:43 UTC)
22:24:03  <DorpsGek> frosch123: -Fix: Extend widget data member to 32 bits so that sprite IDs >= 2^16 can be used.
22:24:13  <frosch123> well, i guess it will fix with the next commit then
22:29:23  <Eagle_Rainbow> What is your opinion: Should it read "go to A (142)" or should it better read "go to A (distance: 142 tiles)"?
22:30:25  <planetmaker> "go to A (142 tiles)
23:15:19  <Eagle_Rainbow> planetmaker: fyi, patch available for the "add distance to order list" featurette at
23:18:23  <Eagle_Rainbow> During that I detected by chance that all translations of STR_ORDER_TEXT are outdated compared to english.txt - english.txt says "{STRING4} {STRING2} {STRING1}" whilst all other languages say "{STRING} {STRING} {STRING}"
23:19:34  <planetmaker> #day
23:19:36  <Eagle_Rainbow> apparently it does not cause any harm, as strgen's safety belt at "CheckCommandsMatch" detects that the translations do not match
23:20:57  <frosch123> Eagle_Rainbow: that's intentional
23:21:10  <frosch123> STRINGx and RAW_STRING are always translated as STRING
23:21:45  <frosch123> translators don't need that information, so it is easier if strgen just adds it
23:22:14  * Eagle_Rainbow is surprised
23:22:26  <Eagle_Rainbow> And what happens if the sequence needs to be changed in translation?
23:22:42  <frosch123> change what?
23:22:50  <planetmaker> you explicitly state the parameter order, if it differs
23:22:51  <frosch123> the string parameters have to match
23:23:11  <Eagle_Rainbow> ok, that could work...
23:23:31  <Eagle_Rainbow> Did I overlook that piece of the information on the strings wiki page?
23:24:13  <Eagle_Rainbow> yes, I did
23:24:58  <Eagle_Rainbow> ok, then again - sorry, my fault :)
23:25:41  <planetmaker> don't worry. it can be confusing
23:25:52  <Eagle_Rainbow> it is confusing :p
23:26:40  *** Supercheese has quit IRC
23:29:29  *** Supercheese has joined
23:40:14  <michi_cc> Eagle_Rainbow: math.h is a system header, use <> for that. Even then, it's probably better to use cmath and std::ceil/sqrt to avoid naming conflicts.
23:41:26  <Eagle_Rainbow> ok, will change
23:41:29  <Eagle_Rainbow> it
23:46:55  <Eagle_Rainbow> michi_cc: done
23:55:05  *** frosch123 has quit IRC
23:55:22  * Eagle_Rainbow is also leaving for the day....
23:55:24  <Eagle_Rainbow> n8
23:55:48  *** Eagle_Rainbow has quit IRC

Powered by YARRSTE version: svn-trunk