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 #openttd.dev 11:00:00 *** ChanServ sets mode: +v Zuu 12:11:23 *** frosch123 has joined #openttd.dev 12:11:23 *** ChanServ sets mode: +v frosch123 12:30:58 *** Supercheese has quit IRC 12:31:29 *** Supercheese has joined #openttd.dev 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> http://devs.openttd.org/~frosch/typefilter.png <- 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 #openttd.dev 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 #openttd.dev 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 #openttd.dev 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 #openttd.dev 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 http://bugs.openttd.org/task/5401 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 http://bugs.openttd.org/task/5401 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 #openttd.dev 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