Times are UTC Toggle Colours
00:56:28 *** LordAro has quit IRC 07:00:34 *** Alberth has joined #openttd.dev 07:00:35 *** ChanServ sets mode: +v Alberth 09:40:16 *** Ristovski has joined #openttd.dev 09:49:07 *** frosch123 has joined #openttd.dev 09:49:07 *** ChanServ sets mode: +v frosch123 10:05:28 *** LordAro has joined #openttd.dev 10:05:28 *** ChanServ sets mode: +v LordAro 11:18:06 *** Zuu has joined #openttd.dev 11:18:06 *** ChanServ sets mode: +v Zuu 11:19:02 *** Sturmi has joined #openttd.dev 11:32:02 *** Supercheese has quit IRC 11:32:33 *** Supercheese has joined #openttd.dev 11:38:50 *** LordAro has quit IRC 12:37:30 *** LordAro has joined #openttd.dev 12:37:30 *** ChanServ sets mode: +v LordAro 14:41:25 *** Sturmi2 has joined #openttd.dev 14:42:40 *** Sturmi3 has joined #openttd.dev 14:47:31 *** Sturmi has quit IRC 14:48:49 *** Sturmi2 has quit IRC 15:21:28 *** zydeco has joined #openttd.dev 16:29:43 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25830 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:30:06 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25831 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:30:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25832 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:30:43 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25833 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:31:33 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25834 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:31:56 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25835 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:32:16 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25836 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:32:59 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25837 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:33:20 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25838 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:34:05 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25839 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:34:23 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25840 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:35:01 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25841 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:35:18 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25842 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:35:32 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25843 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:35:51 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25844 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:03:15 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25845 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:14:41 *** ntoskrnl has joined #openttd.dev 17:45:38 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25846 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:00:11 *** Lord_Aro has joined #openttd.dev 19:00:12 *** LordAro has quit IRC 19:00:44 *** Lord_Aro is now known as LordAro 19:01:06 *** LordAro has left #openttd.dev 19:01:11 *** LordAro has joined #openttd.dev 19:01:11 *** ChanServ sets mode: +v LordAro 19:06:46 *** Lord_Aro has joined #openttd.dev 19:06:46 *** LordAro has quit IRC 19:08:08 *** Lord_Aro is now known as LordAro 19:08:25 *** ChanServ sets mode: +v LordAro 19:32:36 <Zuu> Regarding the patches that LordAro posted (https://www.dropbox.com/sh/dmj7ld3m2s6wryy/net05D2XY4), they look good in general. 19:32:45 <Zuu> I did study 001 in detail and it looks good. 19:32:58 <LordAro> :p 19:33:05 <LordAro> "<planetmaker> LordAro, I'd aggregate 001 with possibly more doxygen. I'm not exactly sure about how 003 compares to 005... they go basically different direction imho; I'd skip 3" for reference 19:33:34 <Zuu> oh, in #openttd :-) 19:33:42 <LordAro> i'll continue here: 19:33:53 <planetmaker> :-) let's stay here 19:33:58 <LordAro> 003 and 005 aren't supposed to be related, as such 19:34:05 <planetmaker> no, not related 19:34:11 <LordAro> they're just random optimisations/fixes 19:34:24 <planetmaker> I meant: 003 adds a special function. Which imho doesn't make it clearer or much shorter 19:34:49 <planetmaker> and 005 basically removes the special functions. And makes it longer where it's called 19:35:09 <planetmaker> But 005 makes somewhat sense to me. At least places with 003 and 005 look similar then 19:35:19 <planetmaker> going by visual structure, calling syntax 19:35:46 <Zuu> hmm, 003 is IsFlatTile and 005 is fence here 19:35:48 <LordAro> as far as i can tell (according to cirdan, i haven't done any testing myself) the IsTileFlat function is somewhat faster than the (old) GetTileSlope 19:35:53 <planetmaker> yes, here, too 19:36:15 <Zuu> How is the flat tile patch related to fence? 19:36:34 <LordAro> it's not, at all 19:36:41 <planetmaker> not at all 19:36:42 <LordAro> just numerous fixes and optimisations 19:36:51 <LordAro> that's all i'm operating on 19:36:58 <LordAro> i'm not touching the map array stuff (for now) 19:37:03 <planetmaker> speed might be an argument, yes 19:37:34 <Zuu> as I understood 003 is motivated by speed arguments 19:38:03 <LordAro> his explanation makes sense, at least :L 19:38:05 <planetmaker> good enough argument 19:38:10 <planetmaker> yes 19:39:35 <planetmaker> why is the z-height called 'a' though? 19:40:08 <LordAro> which patch? 19:40:13 <planetmaker> 3 19:40:54 <LordAro> no idea 19:41:01 <LordAro> i'll change it 19:41:25 <Zuu> 002: changes "x != MapMaxX()" to "x < MapMaxX()" in adition to introducing the helper method. 19:43:16 <Zuu> From my understanding it will not affect the behaviour. 19:44:00 <LordAro> as far as i can tell, it won't 19:44:13 <Zuu> Oh, your dropbox link is now empty 19:44:13 <LordAro> (makes sense that it won't, anyway :) ) 19:44:21 <LordAro> crap, hang on 19:44:44 <planetmaker> Zuu, it's inverted the check for edges 19:45:01 <LordAro> check again, and i changed 003 19:45:06 <LordAro> i did a mv instead of a cp :L 19:45:48 <planetmaker> yeah, that's what I wondered. ty 19:46:22 <planetmaker> Zuu, for 002: see lines 57/58. It checks for edge 19:46:30 <planetmaker> and Line 84 checks for not edge 19:46:42 <Zuu> I compared with line 25/26 19:46:52 <Zuu> 26/27* 19:47:04 <LordAro> either way, that's a basic check, and the patches doesn't break the game that badly, so it must work fine :) 19:47:59 <planetmaker> that's afaik logically equivalent. checking for non-border tiles 19:48:53 <planetmaker> but, I do believe that the result is a bit slower 19:49:15 <planetmaker> as always x and y are retrieved via TileX and TileY respectively 19:49:21 <planetmaker> and the check is only done subsequently 19:49:27 <Zuu> Yep it works the same. I was just wondering why changing "=="/"!=" to "<" / ">". If it may have a tiny speed impact on the low level. 19:50:23 <planetmaker> while currently the check can abort already after having accessed the respective first expression of the total boolean expression 19:51:00 <planetmaker> not sure it makes any difference though... whatever the compilers optimize this into 19:51:27 <Zuu> The compiler may be able to detect that y is used later 19:51:31 <LordAro> does it really matter that much? :L 19:51:43 <LordAro> the differences will be negligible 19:53:12 <planetmaker> hm, I see where tile height a comes from 19:53:41 <LordAro> ? 19:54:02 <planetmaker> Slope GetTileSlope(TileIndex tile, int *h) in tile_map.cpp uses it, too 19:54:11 <LordAro> ah 19:54:27 <planetmaker> but it uses 4 heights. So... different :D 19:54:40 <LordAro> a c&p thing then 19:54:55 <LordAro> either way, a bit of extra confusing that isn't necessary 19:55:02 <LordAro> and i've already changed it :) 19:55:20 <Zuu> 004 could do with doxygen comment of the merged method 19:55:25 <planetmaker> ok, looking at the complete code, the speed thing is void 19:56:01 <planetmaker> s/could do with/needs/ :) 19:57:01 <planetmaker> the use of that method, old and new is kinda a bit shrouded to me. Why would I NOT allow fields when checking for valid farm fields? 19:57:31 <planetmaker> possibly when searching place for new field tiles... 19:57:48 <frosch123> you do not want to plant fields over fields 19:57:54 <frosch123> that results in half fields, which is ugly 19:58:08 <LordAro> for all i know, he may change that later, i haven't even looked over the whole patch queue yet :L 19:58:28 <Zuu> I find it odd that it do: "count += IsValidFarmFieldTile(cur_tile, false);" --- increase an integer with boolean result. 19:58:46 <Zuu> It did that before, so the patch is not changing anything there really. 19:59:37 <planetmaker> oi. I would think we get warnings about that :D 20:00:08 <Zuu> It may be in the c++ standard what a bool converts to as int, but it is different in some programming languages and therefor I tend to stay away form it to not get biten by having the wrong idea for the current language. 20:00:23 <planetmaker> ^ 20:00:29 <frosch123> it is valid c, but normally you use "? 1 : 0" :) 20:00:57 <frosch123> anyway, getting rid of GetTileSlope is a valid optiisation 20:01:05 <frosch123> we also have getmin/maxtileheight for that reason 20:01:31 <frosch123> resolving a slope is complicated, if you do not need all the info 20:02:09 <frosch123> 009 is quite tricky wrt. that :) 20:02:12 <planetmaker> I like 005 and 007. 20:02:29 <planetmaker> I've no clue whether 009 works :-) 20:02:49 <frosch123> it works, but it makes assumptions on the slopes a tunnel entrance can be on 20:02:54 <LordAro> doxygening 004 function - what is the allow_fields paramter for? i'm not sure :L 20:02:57 <frosch123> it assumes that they can only be on plain slopes 20:03:15 <frosch123> and will thus hurt if you ever want tunnels with foundations or similar 20:03:40 <planetmaker> meh 20:03:49 <planetmaker> thus he cuts his own leg there :D 20:04:24 <frosch123> he replaces the expensive GetTileZ function with TileHeight, which only checks the north corner 20:04:48 <frosch123> but assuming the fixed slopes for tunnel entries you can tell the rest of it from the north tile height :) 20:05:14 <planetmaker> hm :-) 20:05:36 <planetmaker> I guess, that's ok as it's capsuled in a separate function, though 20:05:49 <frosch123> though in south direction it is even more trickier, as the height of the north corner does not identify the tunnel end, so the uses the height of the next tile after tunnel exit, then goes one tile back 20:05:49 <planetmaker> rewriting such function when tunnels are enhanced is a valid task 20:06:09 <frosch123> so, yeah, quite tricky, might need a comment :p 20:06:56 * LordAro pokes poeple about doxygen comment 20:11:08 <LordAro> "@param allow_fields include existing field tiles in the check" good enough? 20:11:08 <Zuu> LordAro: If allow_fields is true, the method will return true even if the tile is a farm tile. 20:14:29 <LordAro> assuming yes :p 20:14:38 <LordAro> what else did you decide needs to be done? 20:14:42 <Zuu> Perhaps "If allow_fields is true, the method will return true even if the tile is a farm tile, otherwise the tile must not be a farm tile" 20:14:56 <Zuu> + the @param stuff 20:15:26 <Zuu> It is always good to have a clear if true, blah, otherwise, blah2 statement for parameters. 20:15:46 <planetmaker> yeah 20:17:14 <LordAro> updated 004 patch, can you check? 20:18:17 <planetmaker> I think the return value is not true 20:18:31 <planetmaker> Maybe it should actually be renamed, the whole function 20:18:41 <planetmaker> To CanBecomeFarmField 20:18:55 <LordAro> k 20:18:56 <planetmaker> or IsSuitableForFarmField 20:19:03 <frosch123> IsSuitable sounds better 20:19:31 <planetmaker> MP_CLEAR and MP_TREEES in any case are not yet valid farm fields :-) 20:19:50 <LordAro> indeed :) 20:19:53 <LordAro> done 20:20:18 <LordAro> next? :L 20:21:35 <frosch123> does the "L" in ":L" stand for "LordAro" ? 20:21:36 <Zuu> It now says IsValidFarmFieldTile in 004 20:22:01 <LordAro> Zuu, press f5 20:22:14 <LordAro> frosch123: i do use that emoticon a lot, don't i? :p 20:22:34 <frosch123> so it stands for "lot" ? :o 20:22:40 <planetmaker> :D 20:22:44 <LordAro> :p 20:22:54 <LordAro> stop making the conversation go offtopic 20:22:55 <LordAro> :p 20:23:07 <Zuu> The text about allow_fields could replace the current @param farm_field text 20:23:48 <LordAro> farm_field? 20:24:14 <planetmaker> what do you mean, Zuu ? 20:24:21 <LordAro> oh, right, allow_fields, but the existing text is a bit long, imo 20:24:22 <Zuu> @param allow_fields If true, the method will return true even if the tile is a farm tile, otherwise the tile must not be a farm tile. 20:24:31 <LordAro> a bit long, imo 20:24:43 <planetmaker> not long. accurate :-) 20:24:50 <planetmaker> s/must not/may not/ 20:25:56 <Zuu> LordAro: http://paste.openttdcoop.org/show/2714/ 20:26:19 <LordAro> got it, done 20:26:50 <Zuu> This is not longer than your version in total. Infact it is shorter by only explaining allow_fields once and clearly directly. :-) 20:27:07 <LordAro> ok 20:27:09 <LordAro> next? 20:27:16 <planetmaker> 5 is fine with me 20:29:04 <Zuu> Hmm, I get confused by that diff viewer showing removed lines in green. 20:29:16 <planetmaker> yeah, that's confusing 20:30:39 <LordAro> little bit :L 20:31:57 <Zuu> 5 looks good to me too 20:33:18 <planetmaker> 006 as well. It makes it clearer when being called 20:35:58 <planetmaker> actually... 006 misses also doxygen 20:38:52 <Zuu> I agree that 006 is an improvement. But yes, that method should have doxygen comments. 20:40:13 <LordAro> wait, crap, i missed a patch out 20:41:32 <Zuu> make it 006.5 or so to not distrub the discussion 20:42:21 <planetmaker> 006a or similar 20:43:43 <Zuu> 007 is a slight code reduction but will instead give us the situation where there is both IsBridgeAbove and HasBridgeAbove. 20:44:21 <Zuu> Doxygen for IsBridgeAbove do however have a clear @pre for MayHaveBridgeAbove. 20:44:43 <Zuu> So it may not be an issue to have both IsBridgeAbove and HasBridgeAbove. 20:44:57 <planetmaker> uh, good point. HasBridgeAbove and IsBridgeAbove... having both is awkward 20:45:57 <planetmaker> before your comment I liked it :-( Now I don't :D 20:46:34 <Zuu> The code reduction in this patch is not very much at each location. Altohugh number of affected locations is quite many. 20:46:41 <planetmaker> yeah 20:46:59 *** Alberth has left #openttd.dev 20:47:17 <planetmaker> where's IsBridgeAbove defined? 20:47:30 <LordAro> right, added the new patch - 004.5 20:48:23 <Zuu> I kind of wonder why we have both MayHaveBridgeAbove and IsBridgeAbove, but I guess there are some locations when we only want to do the former check or where that result can be cached. 20:49:43 <planetmaker> MayHaveBridgeAbove definitely is needed for bridge building :-) 20:50:02 <Zuu> I guess so :-) 20:50:58 <Zuu> IsBridgeAbove: bridge_map.h:58 20:52:34 <Zuu> 004.5 looks good to me 20:53:22 <Zuu> 008 looks good (I didn't knew about this problem until seeing this patch) 20:54:20 <LordAro> 006 doxyment - http://paste.openttdcoop.org/show/2715/ no idea about what size is doing 20:55:07 <LordAro> and guessing about the other params 20:56:03 <planetmaker> @param size Size of the field being planted in tiles 20:57:17 <Zuu> Perhaps 010 should contain an assert that verify that the @pre is true? 20:57:59 <Zuu> Also a "default: NOT_REACHED();" is good 20:58:37 <Zuu> with that, the assert may not be needed as the NOT_REACHED macro will be trigged if the @pre doesn't hold. 20:59:59 <planetmaker> hm... 21:00:34 <Zuu> "Set farm fence positions" <--- doesn't sound right to me 21:00:36 <planetmaker> hunks 1 and 2 do not contain aircraft 21:00:39 <planetmaker> in 010 21:00:43 <planetmaker> while the 4th does 21:00:59 <LordAro> so are we just discussing 009 and 010 now? (and doxygen in 006) 21:01:17 <Zuu> LordAro: my last comment was about doxygen 006 21:01:20 <planetmaker> thus currenthly the NOT_REACHED is triggered in hunks 1 and 2 21:01:38 <LordAro> Zuu: other suggestions required ;) 21:02:42 <Zuu> s/Set farm fence positions/Build farm field fence/ ? 21:02:50 <LordAro> k 21:04:00 <Zuu> LordAro: Did you add a default: NOT_REACHED just now? 21:04:13 <LordAro> no... where? 21:04:19 <Zuu> In 010 21:04:29 <LordAro> i haven't touched that, no 21:04:36 <planetmaker> Zuu, 010 is fishy... 21:04:46 <Zuu> I just saw there is one, in the beginning of the switch { } block 21:04:52 <planetmaker> look at the switch options in hunk 1 and 2... 21:05:04 <Zuu> We always have them at the end as far as I can remember. 21:05:25 <planetmaker> I NOT_REACHED is good 21:05:32 <planetmaker> but the vehicle types change in the patch 21:05:35 <Zuu> Yep, but should be at the end? 21:05:39 <planetmaker> the considered ones 21:06:00 <planetmaker> it relaxes conditions, being more relaxed about allowing stations also in hunks 1 and 2 21:06:06 <Zuu> I see your comment planetmaker 21:06:10 <LordAro> planetmaker, maybe in hunks 1 & 2 there should be a "assert(vt != VEH_AIRCRAFT)" ? 21:06:19 <LordAro> after the func call 21:08:35 <planetmaker> hm... sounds a bit hackish 21:09:26 <LordAro> it's not like that an airport ever gets to those functions anyway - when was the last time the NOT_REACHED() was triggered there? 21:11:10 <planetmaker> brb 21:11:17 <LordAro> D: 21:13:21 <Zuu> If we want to take 010, and add an assert for airport hangars, I would add that earlier in those methods if it makes sense. 21:13:58 <Zuu> The two affected locations are closing hangar window and repainting hangar window. 21:15:46 <Zuu> In this case I think it is not a problem that the assert conditions are relaxed in 010. If I understand it correctly, the aircraft hangar is not handled by depot.cpp / depot_cmd.cpp. 21:16:33 <Zuu> In depot_cmd.cpp, it verify that the input tile is a valid depot tile. This verification should filter out hangar tiles assuming that the hangar is not a depot in the internal data structures. 21:18:11 <Zuu> Hmm, oh interesting fact: You cannot rename an hangar at all. While all other depots can be renamed. 21:18:37 <LordAro> indeed 21:19:03 <LordAro> i guess because it's permanently linked to the 'station' 21:19:19 <planetmaker> back 21:21:05 <LordAro> how about now? see updated patch 21:21:27 <LordAro> as of now actually 21:25:18 <planetmaker> hm, asserts are not compiled in releases, yes? 21:25:33 <LordAro> that's true 21:25:51 <LordAro> but again, NOT_REACHED() is never normally... reached 21:26:39 <planetmaker> that's the point. It's like an assert 21:27:01 <planetmaker> but I think Zuu is right. We can be more relaxed here 21:27:07 <LordAro> ok 21:28:06 <LordAro> as i said, i can't say i've heard of these particular NOT_REACHED ever been triggered 21:28:38 <Zuu> They usually get triggered when you develop a patch or so. They should never get triggered in trunk. 21:29:04 <Zuu> Eg. they are a reminder that when adding an enum type to add it to all switch blocks. 21:29:37 <planetmaker> yeah. Asserts must never be triggered :-) And are here for us only. To know where/why it fails 21:29:48 <planetmaker> before it fails in very awkward ways which no-one can reconstruct 21:30:08 <planetmaker> like "if it's wrong, fail here" 21:31:10 <Zuu> We also got for example the Extract template method that will bark if you change the bit size in the template definition in a .h file but not updating the corresponding call in the DoCommand procs. 21:31:13 <planetmaker> 005a makes sense to me, too 21:32:36 <Zuu> 009, I saw frosch123 and you commented on being good 21:33:28 <Zuu> Thus, if I remember correctly 001 to 010 is good except for 007 where we get both IsBridgeAbove and HasBridgeAbove which may be an argument for not applying that patch. 21:34:20 <planetmaker> 009... was the comment by frosch wrt assumptions on tile types. 21:34:29 <planetmaker> Not sure what to make of it really... 21:35:19 <planetmaker> so maybe skip 7 and 9 for now. You want the honour to commit, Zuu ? 21:35:24 <planetmaker> I'm too tired to do so today 21:35:45 <LordAro> remember to credit cirdan :) 21:35:55 <planetmaker> and ^ 21:36:11 <planetmaker> that guy here, LordXY, too ;-) 21:36:19 <LordAro> whose that? :p 21:36:28 <LordAro> who's, rather 21:37:23 <LordAro> great, well, i'll start on the next 10 21:37:34 <LordAro> we can discuss those tomorrow :p 21:37:38 <planetmaker> I think what you do here, is good work, too, LordAro. thanks 21:37:55 <planetmaker> good night from my side for today though :-) 21:38:00 <LordAro> :3 thanks pm 21:38:04 <LordAro> and goog night 21:38:06 <LordAro> good 21:38:34 <Zuu> Indeed, you do a great job LordAro with exctarting patches and provide them in a format that is good for reviewing. 21:38:47 <LordAro> :3 so much praise :) 21:38:51 <planetmaker> yeah... seems little. But important 21:39:51 <Zuu> Ok, all but 7 and 9 for now. 22:01:15 *** frosch123 has quit IRC 22:01:21 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25847 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:03:14 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25848 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:04:59 <LordAro> Zuu: make sure you check 010 - patch in the folder (until a moment ago) still had my unneeded asserts 22:06:14 <Zuu> LordAro: Thanks for your notice 22:07:59 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25849 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:09:01 <Zuu> LordAro: 004: you have managed to misspell 'if' at two locations. 22:09:20 <Zuu> I'm fixing that locally 22:09:38 <LordAro> twice? 22:09:41 <LordAro> i can see once 22:09:58 <Zuu> ff and iff 22:10:07 <LordAro> iff is intentional ;) 22:10:21 <Zuu> What does that mean? 22:10:40 <LordAro> http://en.wikipedia.org/wiki/If_and_only_if ;) 22:11:04 <LordAro> it's used in quite a few other places in the code 22:11:12 <LordAro> it confused me initially too 22:11:31 <LordAro> still confuses me a bit, tbh 22:11:41 <Zuu> In NoAI and NoGo it is written out without using that abbrivation. 22:11:53 *** ntoskrnl has quit IRC 22:12:44 <LordAro> it appears at least 108 times in the ottd source already :) 22:12:49 <Zuu> In this case it is not really good actually. As the method is "Is suitable" rather than a black/white "can be placed here" method. 22:13:50 <LordAro> i based it on the above function IsTileForestIndustry 22:13:55 <LordAro> although that is written out 22:14:01 <LordAro> the functions do the same sort of thing 22:15:24 <LordAro> anyway, you're committing, you can decide :) 22:17:12 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25850 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:18:01 <Zuu> I see where you got it from, and thanks for explaining the abbrivation. Though I don't really see that it fits here. and well end of discussion unless you want to suggest a patch for that :-) 22:18:31 <LordAro> :) 22:18:49 <LordAro> s/iff/if and only if/ solves it nicely 22:19:15 <LordAro> although you'd probably won't to check for a space on one end of it ('different') 22:21:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25851 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:23:44 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25852 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:28:39 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25853 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:39:15 <Zuu> hmm with 001 to 010 applied (including 7 and 9), there is an assert on generating a new game. 22:39:35 <Zuu> With the currently commited patches there is no assert when generating the game 22:40:03 <Zuu> Nor with 008 also applied 22:40:48 <LordAro> 008 causes the assert? 22:41:02 <Zuu> Nope 22:41:13 <LordAro> which assert? 22:41:18 <Zuu> Hmm, could be your extra assert in 010 that I didn't remove yet :-) 22:41:36 <LordAro> :) 22:42:12 <LordAro> odd, as far as i can tell, that should cause a NOT_REACHED, instead 22:45:20 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25854 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:45:50 <Zuu> It needs further investigation. I'll leave that for tomorrow. 22:46:30 <Zuu> Eg. you could create a sub directory "applied" and move 001-005b, 006 and 008 there. 22:47:29 <LordAro> already doing so :) 22:47:35 <Zuu> great :-) 22:47:46 <LordAro> so 009 or 010 cause the error? 22:48:06 <Zuu> 007 and 009 has not been applied. 22:48:15 <LordAro> so just 010 then? :L 22:49:06 <Zuu> 010 may work without your extra assert. But now its getting bed time here. 22:49:16 <LordAro> kk, i'll take a look 22:49:23 <LordAro> thanks for the commits and reviews :) 22:57:04 <LordAro> Zuu: although, fyi, i'm not getting any assert at all 22:57:19 <LordAro> (without extra asserts in 010) 22:57:26 <Zuu> ok 22:58:27 <Zuu> I'll verify that tomorrow. 22:58:40 <Zuu> Good night and thanks for your work too 22:58:45 <LordAro> :3 22:58:48 <LordAro> good night 23:00:28 *** Ristovski has quit IRC 23:07:08 *** Zuu has quit IRC 23:16:29 *** zydeco has quit IRC