IRC logs for #openttd.dev on OFTC at 2012-12-25
⏴ go to previous day
08:24:38 * Terkhen ponders if the layers of the new scenario format should have png metadata information or not
11:00:45 *** Zuu has joined #openttd.dev
12:12:08 *** frosch123 has joined #openttd.dev
12:12:08 *** ChanServ sets mode: +v frosch123
12:32:15 *** Supercheese has joined #openttd.dev
17:43:30 <planetmaker> Hi, what is the sprites' lru? (spritecache.cpp:604ff)
17:44:33 <frosch123> least recently used
17:45:00 <frosch123> when the spritecache is full, it drops the sprites which have been used the longest time ago
17:45:39 <planetmaker> ah. Hm, maybe I should increase my spritecache :-)
17:49:52 <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:55 <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:52:41 <frosch123> add a conditional breakpoint
17:53:03 <frosch123> or even just add a breakpoint where the DEBUG output is
17:53:09 <planetmaker> meh. Even with all all newgrfs it complains about missing and wrong newgrfs... seems a hopeless cause nearly...
17:53:14 <frosch123> then see what draws it
17:53:49 <frosch123> if it is drawing the viewprot
17:54:01 <frosch123> you can check the coordinates and determine the tile which is being drawn
18:03:24 <planetmaker> is it worth to test on such tempered map?
18:04:27 <frosch123> saves store no spritenumbers
18:04:51 <frosch123> so, if they are messed up, it should be reproducible with just the newgrf config
18:07:24 <frosch123> btw. this sprite #14 business remembers me about the firs issue
18:07:36 <frosch123> does firs still draw questionmarks?
18:07:57 <frosch123> back then i wondered whether it might be an nml issue
18:08:03 <planetmaker> yes, it does in parts still do that
18:08:11 <frosch123> but i failed to read firs code, so i have no clue what it tried to do
18:08:14 <planetmaker> in FIRS it's a programming issue with calculation of fences
18:08:37 <planetmaker> thus in FIRS I'm moderatly convinced that my code is buggy
20:27:55 *** Zuu has joined #openttd.dev
20:36:09 <planetmaker> frosch123, I agree. The shown selection is quite nice. and sufficient
21:21:14 *** LordAro has joined #openttd.dev
21:21:14 *** ChanServ sets mode: +v LordAro
21:21:41 <frosch123> i did not quite understood what is missing on the release todo list
21:22:56 <LordAro> basically should include modifying Template:OTTDVersions & "OpenTTD Release History" & obviously the wikipage for that version
21:23:10 <LordAro> doesn't really matter, but if you're documenting it...
21:26:00 <frosch123> hmm, that release history page looks quite useless considerung the ottdversions template :p
21:26:38 <LordAro> maybe, but they were both there before me :L
21:26:44 <LordAro> i just maintain them :)
21:30:39 <LordAro> while we're at it, you/Rubidium forgot Template:Version :L
21:30:53 <LordAro> dunno what it's used for though
21:30:53 <frosch123> it's in the "after branch" section
21:31:21 <LordAro> no it's not "update wiki pages: Template:Version, FAQ General Questions"
21:31:32 <frosch123> ah, that one, well that is only after stable
21:31:53 <frosch123> it's used in exactly one place, which says "the latest stable release ist {{version}}"
21:32:15 <LordAro> hence the "you/Rubidium" since it was set at 1.2.2 :P
21:32:20 <frosch123> oh, due to translations there are more places meanwhile
21:32:22 *** Eagle_Rainbow has joined #openttd.dev
21:32:22 *** ChanServ sets mode: +v Eagle_Rainbow
21:34:02 <Eagle_Rainbow> hi everyone and - merry Christmas to everyone!
21:34:56 *** FLHerne has joined #openttd.dev
21:35:25 <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:07:10 <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:51 <planetmaker> square of euclidean distance
22:10:01 <planetmaker> still it's euclidean. And not a jungle metric or so
22:10:09 <michi_cc> It's the squared euclidean distance (it's called DistanceSquare, isn't it?)
22:10:28 <Eagle_Rainbow> but the comment is "Also known as euclidian- or L2-Norm squared"
22:10:50 <Eagle_Rainbow> or is the hyphen meant to go with "-norm"?
22:11:06 <planetmaker> euclidean is not a norm
22:11:25 <frosch123> planetmaker: sure it is :p
22:11:36 <frosch123> euclidian norm = L2 norm
22:11:37 <planetmaker> hm... yes :D. synonymous
22:12:00 <planetmaker> tbh, I guess I can't recall the norm being called euclidean. Always L2
22:12:06 <Eagle_Rainbow> but anyway - the function is intended to produce the squared value of the euclidean distance...
22:12:18 <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:12:41 <Eagle_Rainbow> so, it's just an optimization to go with squared values, right?
22:12:47 <frosch123> instead of sqrt(...) < 20, you just do (...) < 400
22:13:07 <frosch123> yup, ottd contains no floats in the game mechanics
22:13:12 <Eagle_Rainbow> yes, but in my current case, I need the sqrt of the distance...
22:13:14 <frosch123> (only scripts may use them)
22:13:24 <Eagle_Rainbow> but on gui they are allowed?
22:13:27 <planetmaker> Eagle_Rainbow, where is the actual distance needed?
22:13:45 <frosch123> planetmaker: i assume the max aircraft distance thingie :p
22:14:04 <frosch123> Eagle_Rainbow: gui should be fine
22:14:04 <planetmaker> yes... GS. We explained it recently in a bug report, I think :D
22:14:15 <planetmaker> don't compare map distances with aircraft distances
22:14:21 <planetmaker> use aircraft distances between tiles
22:14:54 <Eagle_Rainbow> !? Ok, apparently there's another thing which I don't know yet :)
22:14:56 <frosch123> floats just cannot be used in game mechanics, since we cannot rely on different processors returning the same result
22:15:07 <Eagle_Rainbow> frosch123: that's clear&ok
22:15:07 <planetmaker> don't ever try to match aircraft distances with real map distances. It's both arbitrary, but different units
22:15:20 <frosch123> planetmaker: Eagle_Rainbow is no AI author :p
22:15:50 <planetmaker> I thought so... but ... then the question's background is very fuzy for me :-)
22:16:00 <frosch123> it's funny how you miss each other in your discussion
22:17:59 <Eagle_Rainbow> it's providing the distance between two airports in the order list...
22:18:25 <frosch123> Eagle_Rainbow: anyway, what pm was refering to: there are two maximum distances in ottd
22:18:26 <Eagle_Rainbow> (in fact it's more - not just airports, but also depots, ... but that's a different story)
22:18:35 <frosch123> aircraft use euclidian
22:18:40 <frosch123> while ships use manhattan
22:18:58 <Eagle_Rainbow> and map distances are manhattan normed?
22:19:12 <planetmaker> oh, I missed that FS so far completely. Thanks. Valid request IMHO
22:19:14 <Eagle_Rainbow> and the fees are calculated via manhattan, right?
22:19:15 <michi_cc> Ah, DorpsGek misses op again, that's why we get no topic...
22:19:29 <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:49 <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:56 <frosch123> hmm, how does that work :p
22:20:19 *** ChanServ sets mode: +o DorpsGek
22:21:18 <Eagle_Rainbow> so, ok - if I go with the euclidean one and use the sqrt myself I should be fine, right?
22:22:10 <frosch123> yup, gui is fine :)
22:23:31 <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:24:47 <DorpsGek> frosch123: Commit by peter1138 :: r24853 /trunk/src (3 files) (2012-12-25 22:10:43 UTC)
22:24:48 <DorpsGek> frosch123: -Fix: Extend widget data member to 32 bits so that sprite IDs >= 2^16 can be used.
22:24:59 <frosch123> well, i guess it will fix with the next commit then
22:30:09 <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:31:10 <planetmaker> "go to A (142 tiles)
23:19:09 <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:20:22 <Eagle_Rainbow> apparently it does not cause any harm, as strgen's safety belt at "CheckCommandsMatch" detects that the translations do not match
23:21:43 <frosch123> Eagle_Rainbow: that's intentional
23:21:56 <frosch123> STRINGx and RAW_STRING are always translated as STRING
23:22:30 <frosch123> translators don't need that information, so it is easier if strgen just adds it
23:23:12 <Eagle_Rainbow> And what happens if the sequence needs to be changed in translation?
23:23:36 <planetmaker> you explicitly state the parameter order, if it differs
23:23:37 <frosch123> the string parameters have to match
23:23:56 <Eagle_Rainbow> ok, that could work...
23:24:17 <Eagle_Rainbow> Did I overlook that piece of the information on the strings wiki page?
23:25:44 <Eagle_Rainbow> ok, then again - sorry, my fault :)
23:26:26 <planetmaker> don't worry. it can be confusing
23:26:38 <Eagle_Rainbow> it is confusing :p
23:30:14 *** Supercheese has joined #openttd.dev
23:41:00 <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:42:12 <Eagle_Rainbow> ok, will change
23:56:08 * Eagle_Rainbow is also leaving for the day....
continue to next day ⏵
