Times are UTC Toggle Colours
05:39:51 *** andythenorth has joined #openttdcoop.devzone 05:50:32 *** andythenorth has quit IRC 06:21:18 *** andythenorth has joined #openttdcoop.devzone 06:51:05 *** andythenorth has quit IRC 08:11:52 *** frosch123 has joined #openttdcoop.devzone 08:22:31 *** ODM has joined #openttdcoop.devzone 10:32:41 <Brot6> FIRS Industry Replacement Set - Revision 2377:425fa56c1cf7: Codechange: Cement plant uses tile lo... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/425fa56c1cf7 10:43:45 <Brot6> FIRS Industry Replacement Set - Revision 2378:c544b370841f: Codechange: Machine shop uses tile lo... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c544b370841f 10:52:43 <Brot6> FIRS Industry Replacement Set - Revision 2379:d37ce45dd087: Codechange: Sawmill uses tile locatio... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d37ce45dd087 10:55:26 <Brot6> FIRS Industry Replacement Set - Revision 2380:62b01bf5d93d: Codechange: Use advanced spritelayout... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/62b01bf5d93d 10:57:32 <planetmaker> Terkhen: can use put the industry name first in the commit messages ;-) 10:57:42 <planetmaker> then I see in this channel which you touched :-P 10:57:52 * planetmaker is PRETTY lazy 10:58:06 <Terkhen> hmm... what do you mean? 10:58:14 <planetmaker> read what brot said ;-) 10:58:28 <Terkhen> ah, ok :) 10:58:55 <planetmaker> don't take this comment too serious, though ;-) 10:59:04 <Terkhen> since brot is already spamming this channel while we are working, it could mention full commit messages too 10:59:12 <Terkhen> no more harm anyways 10:59:17 <planetmaker> it could. Is it possible, Ammler? 11:00:25 <planetmaker> btw, things like sheep farm will be interesting. 11:00:42 <planetmaker> I can't template it w/o using the adv. sprite layout at the same time 11:00:45 <planetmaker> it queries the tile slope 11:01:24 <Terkhen> ok, I'll do it after finishing the fertiliser plant 11:01:52 <planetmaker> it needs to be done concurrently, templating and adv. sprite layout 11:02:07 <Terkhen> hmm... at the same time? 11:02:10 <planetmaker> as it uses some nice location checks for slopes 11:02:12 <Terkhen> o_O 11:02:16 <planetmaker> linking to different action2s 11:02:34 <planetmaker> thus the prime example for adv. sprite layouts 11:03:03 <Terkhen> the spritelayout / industry tile layout code looks quite normal to me 11:03:07 <Terkhen> (the sheep farm one) 11:03:28 <planetmaker> look at the var 0x60 switches 11:03:31 <Terkhen> everything is linked to action2_7353, which is the switch block that decides between different terrains 11:03:32 <planetmaker> they're looking at slopes 11:03:48 <planetmaker> lines 297 ff 11:04:22 <Terkhen> those make no sense to me :P 11:04:35 <Terkhen> I have always ignored them while doing spritelayout conversions 11:04:37 <planetmaker> that's land info of nearby tiles 11:04:44 <Terkhen> I don't see how they are related to the spritelayouts 11:05:01 <planetmaker> they very likely link to just a different layout for a different slope 11:05:09 <planetmaker> each of the 10(?) 11:05:30 <planetmaker> thus the slope needs to be part of the layout. 11:05:38 <Terkhen> there are three layout switches, one for each terrain type 11:05:38 <planetmaker> it's most likely the meadow for the sheep 11:05:46 <planetmaker> not terrain type. terrain slope 11:05:56 <Terkhen> all of them are only referenced by action2_7353, which is the terrain_type switch 11:06:04 <planetmaker> type != slope 11:06:09 <planetmaker> type = normal / desert /snow 11:06:16 <planetmaker> slope = well... slope ;-) 11:06:34 <planetmaker> thus 19 possible ones 11:06:53 <planetmaker> or at least 15, if no steep slopes 11:07:19 <Terkhen> I still don't understand it :P 11:07:41 <Terkhen> I have been converting a lot of layouts already, and I have seen no relations with the 0x60 switches 11:07:56 <planetmaker> Terkhen: it's somewhat an auto-fencing 11:08:10 <planetmaker> a slope-awareness. We didn't have that templated yet 11:08:14 <planetmaker> we just look at climate 11:08:32 <planetmaker> But for some we need to look at morphology of terrain, whether it's flat, sloped north, etc 11:08:41 <planetmaker> thus it needs a (new) tile template 11:08:52 <planetmaker> s/tile template/sprite layout template/ 11:09:02 <Terkhen> hmmm... 11:09:21 <Terkhen> I always supposed that it was just drawn at a different height with foundations as required 11:09:39 <planetmaker> hm, I'll look ingame. I don't think so 11:12:23 <planetmaker> hm, you're right, it doesn't use slopes... 11:12:36 <planetmaker> then... what *is* that? /me investigates 11:12:47 <Terkhen> everything I have been converting "hangs" only from the terrain_type switch 11:12:59 <Terkhen> that includes spritesets, spritelayouts, relative_pos switches and layout switches 11:13:10 <Terkhen> they are not called elsewhere in the code 11:13:16 <Terkhen> that's all I know :P 11:14:39 <planetmaker> well. So far I only converted the callbacks... no interactions with layouts :-) 11:14:57 <planetmaker> I just thought this might be required here... but let's see. 11:21:39 <Terkhen> we need to get andy to start learning nml, and then solve this kind of problems for us :) 11:22:36 <planetmaker> :-) 11:22:41 <planetmaker> quite so ;-) 11:23:08 <planetmaker> well. This sheep farm can be improved, I guess, by using auto-fences and using a slope-dependent offset for the sheep sprites 11:23:15 <planetmaker> but that'd be most probably a custom layout 11:23:39 <Ammler> planetmaker: how should I know :-P 11:23:41 <Terkhen> just keep it as a conversion for now :P 11:23:53 <planetmaker> Ammler: you know brot, don't you? 11:24:02 <Ammler> not really 11:24:10 <planetmaker> Terkhen: sure. For now. But... still, I wonder what this slope magic does... 11:24:32 <planetmaker> @base 10 16 10 11:24:32 <Webster> planetmaker: A 11:24:35 <planetmaker> hm 11:24:37 <Terkhen> industries like the sheep farm and the junk yard can have their tiles placed at different heights 11:24:47 <planetmaker> yep 11:24:53 <planetmaker> but with foundations 11:24:54 <Terkhen> that's why I just assumed that slope code is not related to layout code 11:24:59 <Ammler> since webster is on our server too, we could do those rss feeds also with it 11:26:08 <planetmaker> I don't mind either way much 11:26:33 <planetmaker> @base 10 16 17 11:26:33 <Webster> planetmaker: 11 11:26:43 <planetmaker> hm, I see 11:26:49 <planetmaker> it's the relative position code, I guess 11:26:57 <planetmaker> @base 10 16 16 11:26:57 <Webster> planetmaker: 10 11:27:09 <planetmaker> @base 10 16 240 11:27:09 <Webster> planetmaker: F0 11:29:30 <planetmaker> links to the founder check... or to eachother... checking some weired steep slopes...(?) 11:29:35 <Brot6> FIRS Industry Replacement Set - Revision 2381:7e572b790658: Codechange: Fertiliser Plant uses adv... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/7e572b790658 11:29:58 <planetmaker> 0x60 shift by 10, mask 0x01, with tile rel. pos as 4th param 11:29:58 <Terkhen> should I do the sheep farm now? 11:30:16 <planetmaker> if you wish. I haven't done anything. I didn't yet understand the 0x60 so far :-) 11:30:28 <planetmaker> so go right ahead, if you want 11:30:29 <Terkhen> only if you need it, otherwise I prefer to go in order :P 11:30:43 <planetmaker> then do what you want to do anyway 11:30:54 <Terkhen> ok :P 11:30:55 <planetmaker> I might have jumped to the wrong conclusion initially 11:31:27 <planetmaker> though this sheep farm will - if converted 1:1 - have MUCH potential for improvement. But that's fine, I guess 11:31:31 <planetmaker> we can improve it later 11:32:23 <Terkhen> yes :) 11:34:16 <Terkhen> the code is starting to look understandable :P 11:36:05 <Terkhen> who did the tmpl_ground_tile and tmpl_building_sprite templating? :P 11:36:37 <Terkhen> in the fishing grounds, the only sprite used as ground childsprite has tmpl_building_sprite, the other buildings use tmpl_ground_tile :P 11:37:00 <planetmaker> I guess I might have done that in ogfx+airports once 11:37:14 <planetmaker> but I don#t recall touching anything sprite-related here 11:37:19 <Terkhen> I'm not bothering much with the ground/building distinction anyways 11:37:25 <Terkhen> it is in most cases confusing 11:37:33 <planetmaker> :-P 11:37:38 <Terkhen> ground as building, buildings as childsprites of ground, etc 11:37:47 <Terkhen> since it works, I prefer to not touch it at all 11:37:58 <planetmaker> it's important: the highlight rectangle is drawn on the ground, but under buildings 11:38:09 <Terkhen> the most confusing cases (like the quarries) are not templated at all 11:38:10 <planetmaker> thus it should be taken care of 11:38:18 <Ammler> webster cuts even more 11:38:20 <Terkhen> hmm... I have not seen that problem ingame 11:38:30 <Ammler> I need to figure out how to change it 11:38:37 <planetmaker> look at the (default) steel mill 11:38:51 <planetmaker> it has tiles which are buildings (completely) and some which are ground 11:39:45 <Ammler> so if kenji is around, ask him, if he can do that with webster 11:45:19 <Brot6> FIRS Industry Replacement Set - Revision 2382:276cfbf11797: Codechange: Fishing Grounds uses adva... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/276cfbf11797 11:48:34 <Terkhen> this is new, fishing harbour has no ground sprites at all 11:56:36 <Terkhen> planetmaker: the fishing harbour is different; it has a var 0x60 switch hanging from the relative_pos switches 11:57:11 <planetmaker> hm, how does it look in transparent view? 11:57:21 <planetmaker> no ground sprite is probably not good... 11:57:50 <planetmaker> sounds like many things can go wrong in that case. 11:58:23 <Terkhen> some spritelayouts have GROUNDSPRITE_WATER, but most don't 11:58:36 <Terkhen> it does not look wrong to me in transparent mode 11:59:11 <planetmaker> ok then 12:02:21 <Brot6> FIRS Industry Replacement Set - Revision 2383:dd63d10302be: Codechange: Fishing Harbour uses adva... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/dd63d10302be 12:03:15 <Terkhen> planetmaker: can you give a look to the switch in line 740 of the fishing harbour code? if I understood var 0x60 correctly, it seems to be choosing different spritelayouts depending on some nearby tile 12:03:27 <Terkhen> it's the first time I see it in my part of the conversion :P 12:04:28 <Terkhen> meh, there goes my day 12:04:31 <Terkhen> now it is the forest turn 12:08:11 <Terkhen> I don't understand it so I'll leave it for the end :P 12:08:12 <planetmaker> that is basically var (0x60 shift 0) & 0x1F at position (0,0) 12:09:17 <planetmaker> thus it's a slope check 12:09:31 <planetmaker> tests the 5 slope bits of the tile 12:10:10 <planetmaker> http://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Industry_Tiles <-- the 'ss' bits 0...4 12:10:11 <Webster> Title: VariationalAction2/Industry Tiles - GRFSpecs (at newgrf-specs.tt-wiki.net) 12:11:31 <planetmaker> one can use probably slope_to_sprite_offset(slope) for that in conjuction with the layout 12:11:38 <planetmaker> possibly should 12:12:09 <planetmaker> that is actually what I initially thought to be the case with the sheep farm :-) 12:14:28 <planetmaker> bah... similarly "easy" as sheep farm, though 12:15:20 <planetmaker> nice.... forest... 12:15:29 <planetmaker> it should also use special layouts, Terkhen 12:15:36 <planetmaker> with snowline height as parameter 12:15:48 <planetmaker> line 5221 12:16:20 <planetmaker> … how many frigging lines does it have?! 12:17:23 <planetmaker> and yes, it uses fully slope aware tiles 12:17:29 <planetmaker> line 5052ff 12:18:23 <planetmaker> but... what is var 0x03 ?! 12:19:58 <Hirundo> that'd be current climate 12:22:37 <planetmaker> oh, thank you 12:23:49 <planetmaker> now, could you verify that my comments make sense, please? I'm somewhat unsure and the result doesn't make too much sense for me... http://paste.openttdcoop.org/show/458/ 12:24:06 <planetmaker> or look at sheep_farm:296ff 12:28:03 <Hirundo> I'll look later 12:34:45 <Terkhen> so complicated :) 12:35:22 <planetmaker> yeah... there's some prettry complicated stuff ahead, it seems 13:05:16 <planetmaker> hm... george is talking to me. He obviously wants to use the DevZone. But his way of re-generating the whole code and graphics from using grfcodec to de-compile the compiled grf is not something which lends its way to using a repo 13:05:43 <Brot6> GRFCodec - Feature Request #2971 (New): not put sprite numbers in the PNG (George) @ http://dev.openttdcoop.org/issues/2971 13:06:25 <planetmaker> and wants ^ and the ability to split de-compiled png output by using special 0C comments 13:06:33 <planetmaker> sounds to me like the complete wrong approach 13:06:47 <planetmaker> but there's litle chance to convince him of 'proper' programming techniques 13:07:53 <Hirundo> planetmaker: I think it should be like this: http://paste.openttdcoop.org/show/459/ 13:08:18 <Hirundo> The varact2 parameter is x + 16*y (mod 256) 13:10:05 <planetmaker> then 255 cannot translate to (-1/0) 13:10:58 <planetmaker> as it's FF which should be -1 / -1. Or how do you come to (-1 / 0) there? 13:12:17 <Rubidium> that doesn't sound like something I fancy coding 13:12:26 <planetmaker> no, nor me 13:12:31 <planetmaker> he'll ask you now :-P 13:14:17 <Hirundo> hmm.. now I'm confused :S 13:19:52 <planetmaker> Hirundo: it's afaik a signed nibble. Thus F = -1: http://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Industry_Tiles#Land_info_of_nearby_tiles_.2860.29 13:19:53 <Webster> Title: VariationalAction2/Industry Tiles - GRFSpecs (at newgrf-specs.tt-wiki.net) 13:20:05 <Hirundo> yes, you're right 13:20:26 <planetmaker> but it's right that it tests the desert-ness? 13:20:40 <planetmaker> one after the other, linking to the previous switch? That sounds very odd... 13:22:06 <Hirundo> Probably it tests if either any or all of the tiles are desert 13:22:28 <Hirundo> you'll probably want to replace the var accesses with nearby_tile_terrain_type(x,y) 13:23:02 <planetmaker> yes, I want :-) 13:23:23 <Hirundo> as for the offsets, convert them to hex and use that :P 13:23:24 <planetmaker> but I'm still not sure the result I see makes sense to me in terms of desired effect 13:23:34 <planetmaker> I did it for all of them 13:23:42 <planetmaker> and then wrote the comments ;-) 13:23:52 <planetmaker> the result is either 1,0 or F for each nibble 13:24:59 <Hirundo> mind though, that the order in hex is 0xYX while the coordinates are like (x, y) 13:25:59 <planetmaker> hm, I might have confused that 13:29:01 <Hirundo> New comments, this time hopefully right: http://paste.openttdcoop.org/show/460/ 13:31:54 <planetmaker> thanks :-) 13:33:27 <planetmaker> Ammler: what do you think: would it make sense to commit the "source" of ECS vectors to the DevZone even in this de-compiled state as is being used as "source"? 13:34:01 <Brot6> GRFCodec - Feature Request #2889: Special command to start new png file (George) @ http://dev.openttdcoop.org/issues/2889#change-7439 13:35:53 <Brot6> SuperLib - Revision 11:d4c9c6fe5270: Take use_rvs, use_planes, use_trains and use_ships AI Settin... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/d4c9c6fe5270 13:44:29 <Brot6> Total Town Replacement Set 4 - Revision 6:f603fa92df8c: Added new shops graphics (George) @ http://dev.openttdcoop.org/projects/ttrs4/repository/revisions/f603fa92df8c 13:53:43 <Brot6> SuperLib - Revision 12:4741ea23a371: Added 'not implemented' comment to a Road station function. ... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/4741ea23a371 14:03:58 <Brot6> FIRS Industry Replacement Set - Revision 2384:12e0e6b9dc69: Codechange: Furniture Factory uses ad... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/12e0e6b9dc69 14:17:38 <Brot6> FIRS Industry Replacement Set - Revision 2385:ea10d63f8dc8: Codechange: Glass Works uses advanced... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ea10d63f8dc8 14:39:02 <Brot6> FIRS Industry Replacement Set - Revision 2386:34b2dbed888a: Codechange: Recycling plant 'uses' ti... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/34b2dbed888a 14:45:40 <Brot6> FIRS Industry Replacement Set - Revision 2387:8a7f1b38d4b7: Codechange: Grain Mill uses advanced ... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/8a7f1b38d4b7 14:51:27 <Terkhen> all industries should be like the hardware store 14:51:43 <Brot6> FIRS Industry Replacement Set - Revision 2388:1c215263574d: Codechange: Hardware Store uses advan... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1c215263574d 14:58:46 <Brot6> FIRS Industry Replacement Set - Revision 2389:43a15a42fc47: Codechange: Hotel uses advanced sprit... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/43a15a42fc47 15:17:42 <Brot6> DictatorAI - Revision 141:fc21a4c4d577: - ... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/fc21a4c4d577 15:21:04 <planetmaker> hm... andy here? I wonder whether an industry like clay pit really should not be buildable in desert, also not by the player 15:21:42 <Terkhen> it is probably supposed to be prospected 15:22:04 <planetmaker> that has no influence. prospecting also counts as "built by player" 15:22:07 <planetmaker> in this context 15:22:22 <planetmaker> though... hm 15:22:32 <planetmaker> well, I disallow desert now always. as it is now, too 15:23:04 <planetmaker> sheep farm, btw, has also this "no desert check" :-) 15:23:10 <planetmaker> this var 0x60 chain 15:24:39 <planetmaker> hm... the industrytile "slope_check" callback IMHO is wrongly named. 15:24:53 <planetmaker> It's much more than slope. It's rather a tile_check or similar 15:24:58 <planetmaker> or location_check 15:25:20 <planetmaker> hardly any of FIRS slope_check callbacks check (only) the slope ;-) 15:25:33 <planetmaker> and checking for player type... is "interesting" :-) 15:26:15 <Rubidium> yeah, it's be interesting to give other behaviour for competitive players than aesthetic players ;) 15:26:22 <planetmaker> :-P 15:26:48 <planetmaker> player1 gets other behaviour than player2. Perfectly possible 15:27:06 <planetmaker> And players2..7 may do nothing and 9...15 only in 50% of the time ;-) 15:27:09 <planetmaker> sounds fair 15:31:45 <planetmaker> probably the "player" or "founder" variable only returned "human" and "not human" 15:31:54 <planetmaker> and the usual "by game" versions 15:39:05 <Ammler> [15:33] <planetmaker> Ammler: what do you think: would it make sense to commit the "source" of ECS vectors to the DevZone even in this de-compiled state as is being used as "source"? <-- does it matter? 15:39:32 <planetmaker> not sure 15:39:37 <planetmaker> it might matter to george 15:39:42 <Ammler> but if you want to host ECS on devzone, you should change the license to opensource 15:39:57 <Ammler> as it is open anyway 15:40:25 <Ammler> CC license on devzone is stupid 15:40:26 <Brot6> FIRS Industry Replacement Set - Revision 2390:5c7f3d1b89fb: Add: Template to check for a certain ... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5c7f3d1b89fb 15:40:56 <Ammler> but up to you :-) 15:41:34 <Ammler> hmm, openttd release without opengfx update? 15:41:57 <Brot6> FIRS Industry Replacement Set - Revision 2391:a2e4c0a364d1: Codechange: Clay pit uses tile locati... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/a2e4c0a364d1 15:43:05 <planetmaker> hm 15:43:18 <Ammler> just a question :-P 15:53:32 <Rubidium> Ammler: generally only -beta1 and .0 might require a release 15:59:29 <Brot6> SuperLib - Revision 13:b77c7f560f38: For version 12: add Vehicle::GetVehicleTypeDisabledBySetting... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/b77c7f560f38 16:11:48 *** andythenorth has joined #openttdcoop.devzone 16:25:47 <Brot6> FIRS Industry Replacement Set - Revision 2392:39f53afb2f32: Add: Template to check for coast for ... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/39f53afb2f32 16:25:47 <Brot6> FIRS Industry Replacement Set - Revision 2393:48e1ee712a18: Codechange: Sheep farm uses tile loca... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/48e1ee712a18 16:27:40 <planetmaker> holla andythenorth 16:28:01 <planetmaker> question: is the player supposed to be allowed to build a clay pit in desert or should it generally not be allowed? 16:29:07 <Terkhen> hi andythenorth 16:29:34 <andythenorth> hello 16:29:42 <andythenorth> clay pit is fine in desert 16:29:50 <andythenorth> bit weird that it fills with water 16:30:02 <andythenorth> but as TTD geology is a mystery anyway.... 16:30:10 <andythenorth> we'll assume it's some kind of groundwater 16:30:34 <andythenorth> tbh, if we restrict claypit in any way, it's very unlikely to appear in game 16:30:47 <andythenorth> it's already missing from lots of maps due to size + need for flat ground 16:32:23 *** Zuu has joined #openttdcoop.devzone 16:32:47 <Brot6> SuperLib - Revision 14:f4ba44d2ad82: Fix: Don't use this.Sleep(..) in SuperLib. It is several yea... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/f4ba44d2ad82 16:33:17 <planetmaker> hm, ok. Then I should remove the desert check it has? 16:33:27 <planetmaker> because... I just duplicated what I found ;-) 16:41:07 <planetmaker> andythenorth: maybe that graphical glitch is the reason it so far was not possible? 16:45:42 <Brot6> FIRS Industry Replacement Set - Revision 2394:99caf72f77b1: Codechange: Hotel 'uses' tile locatio... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/99caf72f77b1 16:46:09 <Brot6> SuperLib - Revision 15:f4fea24f2db1: version 13 (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/f4fea24f2db1 16:46:36 <Ammler> Rubidium: opengfx needs a release because of bug 16:47:21 <Brot6> FIRS Industry Replacement Set - Revision 2395:4f3d1d5ce09d: Codechange: Hardware store 'uses' til... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/4f3d1d5ce09d 16:50:29 <andythenorth> planetmaker: possibly there is a graphic glitch yes 16:50:35 <andythenorth> I don't remember :| 16:51:03 <planetmaker> well. Then we keep it as is for now 16:51:17 <Brot6> FIRS Industry Replacement Set - Revision 2396:003de4b124be: Codechange: Grain mill uses tile loca... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/003de4b124be 16:52:14 <Terkhen> andythenorth: the animated version of the grain mill was missing an animation frame (it jumped a bit), can you check if now it works as intended? 16:54:40 <andythenorth> Terkhen: I would :) 16:54:40 <andythenorth> b 16:54:45 <andythenorth> but none are built ;) 16:55:05 <Terkhen> hmm? strange 16:55:28 <andythenorth> indeed 16:55:35 <Terkhen> oh, maybe planetmaker just broke it with the last commit :P 16:55:44 <planetmaker> pffft! ;-) 16:55:58 <planetmaker> at least not compilation :-P 16:55:58 <Brot6> FIRS Industry Replacement Set - Revision 2397:ed405a029212: Codechange: Glass works uses tile loc... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ed405a029212 16:56:22 <planetmaker> and I hope that my manual pattern matching code <-> template works sufficiently well 16:59:42 <Terkhen> I can place them fine in r2389, let's update 17:01:00 <andythenorth> Terkhen: I manually placed 17:01:06 <andythenorth> animation *is* fixed :) 17:01:10 <andythenorth> glad about it 17:02:17 <Terkhen> in the latest revision I can also place grain mills manually in the SE and they appear randomly during game creation 17:02:20 <Terkhen> good to hear that :) 17:03:04 <planetmaker> :-) 17:04:54 <Brot6> FIRS Industry Replacement Set - Revision 2398:2c7ab7fbe7b8: Codechange: Furniture factory uses ti... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2c7ab7fbe7b8 17:04:56 <planetmaker> the adv. of templates again is "one fix to fix them all" ;-) 17:07:13 <Brot6> FIRS Industry Replacement Set - Revision 2399:b1f779e690f1: Codechange: Fishing grounds 'uses' ti... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/b1f779e690f1 17:07:53 <planetmaker> I like the commit messages with 'uses' :-P 17:07:59 <planetmaker> they're quite easy ;-) 17:08:10 <planetmaker> (as compared to normal uses 17:21:20 <Brot6> firs: update from r2374 to r2399 done - http://bundles.openttdcoop.org/firs/nightlies/r2399 17:22:56 <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r248), narvs (r37), bros (r52), ogfx-industries (r122), opengfx (r722), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r126), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r638), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1612), 32bpp-extra (r40), manindu (r7), newgrf_makefile 17:22:56 <Brot6> (r305), ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r107), fish (r684), ogfx-landscape (r76), ttrs (r36), ogfx-trees (r51), swedishrails (r205), grfcodec (r833), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8), indonesiantowns (r41), 17:22:58 <Brot6> ailib-string (r29), airportsplus (r107), comic-houses (r71) 17:23:48 <Brot6> narvs: compile of r37 still failed (#2789) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r37 17:31:32 <Brot6> SuperLib - Revision 16:a67fc3d5261b: Fix: Don't require 8 in production since only one is require... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/a67fc3d5261b 17:31:32 <Brot6> Tutorial AI - Revision 4:8e07f72ea3b9: Use SuperLib to build road stations + depot. => Reduced co... (Zuu) @ http://dev.openttdcoop.org/projects/ai-tutorialai/repository/revisions/8e07f72ea3b9 18:32:50 <Brot6> Tutorial AI - Revision 5:5dbc5e64085e: Move menu to Town A, before building a road station there (Zuu) @ http://dev.openttdcoop.org/projects/ai-tutorialai/repository/revisions/5dbc5e64085e 19:03:10 <Brot6> clientpatches: compile of r22751 still failed (#2964) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22751 19:04:40 <andythenorth> he 19:04:46 * andythenorth tests FIRS 19:06:42 <andythenorth> hardware store is borked for cargo acceptance 19:08:18 <Brot6> openttd-vehiclevars: update from r22743 to r22751 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22751 19:08:56 <planetmaker> goods + bdmt ? 19:09:15 <planetmaker> hm.. but the industry says grain ;-) 19:09:30 <andythenorth> I opened a ticket ;) 19:09:38 <planetmaker> what about fixing it? ;-) 19:09:41 <Brot6> FIRS Industry Replacement Set - Bug #2972 (Confirmed): Hardware store acceptance wrong (andythenorth) @ http://dev.openttdcoop.org/issues/2972 19:09:52 <andythenorth> ho 19:09:53 <Brot6> serverpatches: compile of r22751 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22751 19:09:56 <planetmaker> that's easy peasy after all 19:10:01 <andythenorth> fixing it might be a step too far :P 19:10:05 <andythenorth> writing tickets is easy 19:10:08 <andythenorth> also 19:10:17 <andythenorth> 0 industries built for most of the secondaries 19:10:22 <andythenorth> I guess a template issue 19:11:32 <Brot6> 32bpp-ez-patches: compile of r22751 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22751 19:11:58 <andythenorth> oh 19:11:58 <andythenorth> ffs 19:12:02 <planetmaker> you should start working on the code ;-) 19:12:09 <andythenorth> I remember why I didn't 19:12:15 <Brot6> FIRS Industry Replacement Set - Bug #2972 (Closed): Hardware store acceptance wrong (andythenorth) @ http://dev.openttdcoop.org/issues/2972 19:12:15 <Brot6> FIRS Industry Replacement Set - Revision 2400:f7fb6759fb6b: Fix #2972: Cargo acceptance of hardwa... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/f7fb6759fb6b 19:12:15 <Brot6> FIRS Industry Replacement Set - Bug #2972 (Closed): Hardware store acceptance wrong (planetmaker) @ http://dev.openttdcoop.org/issues/2972#change-7440 19:12:16 <andythenorth> my repo is fucked 19:12:19 <andythenorth> this is annoying 19:12:35 <andythenorth> maybe not 19:12:37 <planetmaker> then just clone a brand new one 19:12:40 <andythenorth> maybe I just keep getting unlucky 19:12:49 <andythenorth> you pushed the same fix :P 19:12:54 <planetmaker> dunno how you manage to bork it all the time 19:12:59 <andythenorth> me neither 19:13:08 <andythenorth> commit, pull, push 19:13:11 <andythenorth> it's not hard 19:13:27 <andythenorth> this one was just unlucky timing 19:14:15 <planetmaker> that's wrong. Pull, commit push is proper 19:14:43 <andythenorth> hmm 19:14:47 <andythenorth> then I need to use a queue instead 19:14:51 <andythenorth> anyway 19:14:55 <andythenorth> my repo is fucked again 19:15:31 <andythenorth> I pulled, committed 19:15:32 <andythenorth> you pushed 19:15:35 <andythenorth> I tried to push 19:15:43 <andythenorth> now I have to blitz my repo :P 19:15:49 <Hirundo> use rebase 19:15:59 <Ammler> hg rebase -d tip 19:16:17 <Hirundo> pull pm's change from the server first, ofc 19:16:26 <Ammler> yep, without update 19:17:36 <andythenorth> ok 19:17:46 <andythenorth> that appears to have created new heads on the remote repo 19:18:07 <andythenorth> oops 19:18:24 <andythenorth> that is undesirable :P 19:18:25 <planetmaker> you don't do that, unless you force it... 19:18:36 <planetmaker> thus that won't happen unless you want to screw up 19:18:36 <andythenorth> I forced it - I didn't intend to, my fingers got ahead of me 19:18:40 <Brot6> FIRS Industry Replacement Set - Revision 2402:808ca15f2c81: Fix: Hardware Store acceptance was wr... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/808ca15f2c81 19:18:46 <planetmaker> *sigh* 19:18:49 <andythenorth> sorry 19:18:52 <andythenorth> genuine accident :( 19:18:53 <planetmaker> then please fix it,too 19:19:15 <andythenorth> what to do? 19:19:28 <planetmaker> is there any occasion where one needs to force anything? 19:19:33 <Ammler> you used -f unintended? :-o 19:19:40 <andythenorth> yes 19:19:41 <planetmaker> yeah, I wonder... 19:19:45 <Ammler> sometimes :-D 19:20:16 <planetmaker> only a merge now fixes it 19:20:20 <Ammler> well, now you should merge... 19:20:26 <andythenorth> I just typed what I saw in the shell on the line above, which was stupid 19:20:37 <andythenorth> I know better than to force a push :( 19:22:40 <andythenorth> ah 19:22:41 <Ammler> ah well, this is not so bad, you made a lot merges, so you can quite easy fix 19:23:00 <andythenorth> also there is another head from the last time I had a failed push 19:23:05 <andythenorth> so that's tidy :P 19:23:28 <Ammler> already forgot the alias I gave you once? 19:23:33 <Ammler> hg slog 19:24:10 <andythenorth> no I used that 19:24:22 <andythenorth> http://paste.openttdcoop.org/show/462/ 19:24:48 <andythenorth> FWIW, before I pushed 19:24:48 <andythenorth> pdq2s-macbook-3:firs_build andy$ hg rebase -d tip 19:24:49 <andythenorth> nothing to rebase 19:24:59 <planetmaker> you didn't pull? 19:25:10 <planetmaker> there's not my last changeset in your history 19:25:26 <andythenorth> pdq2s-macbook-3:firs_build andy$ hg pull 19:25:27 <andythenorth> pulling from ssh://ottdc@mz.openttdcoop.org/hg-repos/firs 19:25:27 <andythenorth> searching for changes 19:25:27 <andythenorth> no changes found 19:25:40 <andythenorth> I pulled :P 19:25:51 <andythenorth> I was dumb to use -f, but there are other problems here 19:25:59 <andythenorth> there are 4 heads in my repo 19:26:03 <andythenorth> as far as I can see 19:26:03 <Ammler> hmm 19:26:10 <Ammler> hg heads 19:26:26 <andythenorth> http://paste.openttdcoop.org/show/463/ 19:26:39 <andythenorth> I think I need to bin this repo 19:26:51 <andythenorth> previous failed pushes have created new heads 19:26:52 <Ammler> well, there are 3 release branches 19:27:07 <andythenorth> yeah, but I have 3 heads of my own it appears 19:27:10 <andythenorth> and no good reason for that 19:27:27 <Ammler> well, those are already pushed 19:27:37 <Ammler> so you will again clone/pull those 19:27:48 <Ammler> just merge your recent heads 19:28:01 <Ammler> forget about 2110:a6ce45f6ea1c 19:28:32 <planetmaker> yeah 19:28:49 <andythenorth> now I remember why I wasn't writing code :( 19:29:33 <Ammler> planetmaker: what I don't get is that all heads are from andythenorth 19:29:47 <planetmaker> nor do I 19:29:53 <andythenorth> nor do I 19:30:02 <andythenorth> I should have binned this repo when the first push failed 19:30:14 <andythenorth> working on a broken repo is *dumb* 19:30:34 <Ammler> the need to trash a repo is strange too 19:30:57 <Ammler> you have somewhere a serious flaw in your workflow 19:31:11 <andythenorth> empirically, I can't argue 19:31:22 <andythenorth> I don't know what though 19:31:26 <andythenorth> it's not exactly hard 19:31:48 <Ammler> I guess, you forgot not just pull, also to update before your last commit 19:32:11 <andythenorth> not really 19:32:18 <andythenorth> the last one was just unlucky 19:32:28 <Ammler> then you pulled and updated with -c and made again a new commit 19:32:43 <andythenorth> what is -c? 19:33:03 <Ammler> -c --check update across branches if no uncommitted changes 19:33:18 <Ammler> else your hg would have complained 19:34:00 <Ammler> anyway, try to merge 2401:6c1a810b2282 19:34:43 <andythenorth> hmm 19:34:52 <andythenorth> Ammler: FWIW http://paste.openttdcoop.org/show/464/ 19:35:09 <planetmaker> shall I? 19:35:30 <andythenorth> I tried using instructions via google, I can't get them to merge 19:35:39 <andythenorth> it needs a manual resolve 19:35:43 <andythenorth> that's likely to break things 19:35:46 <planetmaker> you always need to do that 19:35:46 <Ammler> hg pull -u <-- proves you already made the pull before 19:35:53 <planetmaker> a merge usually needs check 19:35:59 <andythenorth> which is fine if you understand the code :P 19:36:04 <andythenorth> I am unqualified to merge here 19:36:30 <Ammler> the issue is your 2nd last change is based on a very old parent 19:36:41 <Ammler> then you made a pull with forced update 19:36:42 <andythenorth> I am going to add new entry to my long list of firs.borked to my local filesystem 19:37:08 <Ammler> so you made 2 committs to different parents 19:37:14 <Ammler> before you pushed 19:37:26 <andythenorth> how did I make the pull with forced update? 19:37:29 <andythenorth> -u forces? 19:37:30 <planetmaker> merged them 19:37:30 <Ammler> with -c 19:37:38 <andythenorth> how did I do that? 19:37:45 <Ammler> hmm, planetmaker does it? 19:37:47 <andythenorth> planetmaker: thanks - and sorry 19:37:54 <Brot6> FIRS Industry Replacement Set - Revision 2403:ce032223f92f: Merge heads (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ce032223f92f 19:37:56 <andythenorth> Ammler: I can't do it 19:38:04 <planetmaker> you can 19:38:07 <Ammler> andythenorth: you can't do what? 19:38:16 <andythenorth> manually resolve changes in code I can't read 19:38:18 <planetmaker> when a merge fails it gives you the files with merge conflicts and both codes 19:38:26 <planetmaker> <<<<< one code ====== other code >>>>> 19:38:27 <planetmaker> or so 19:38:34 <Ammler> or kdiff3 19:38:40 <Ammler> a nice gui 19:38:40 <planetmaker> you'll have to decide which (or something else) is right 19:38:48 <andythenorth> exactamly 19:38:51 <andythenorth> anyway - sorry 19:38:58 <andythenorth> I'm not going to do any more on this today 19:39:03 <Ammler> planetmaker: does pull -u force update like -c? 19:39:05 <planetmaker> nah, don't worry. 19:39:12 <planetmaker> Exactly now is a good point to continue ;-) 19:39:19 <Ammler> would be a reason not to use -u 19:39:24 <planetmaker> or the frustration potential and entry barrier rises ;-) 19:39:34 <planetmaker> Ammler: dunno 19:39:37 <andythenorth> I need a new checkout, that means copying all hg stuff again, and I'm tired ;) 19:39:53 <andythenorth> I'm so bored of rebuilding .hg and other local files 19:39:54 <Ammler> rather make a alias fetch = pull && update 19:39:58 <planetmaker> hg export. and hg import 19:40:05 <andythenorth> :o 19:40:11 * andythenorth -> google 19:40:17 <planetmaker> Ammler: hg pull -u is identical to hg pull && hg update 19:40:30 <Ammler> planetmaker: I thought so too 19:40:48 <Ammler> but then I wonder, how andythenorth were able to switch branch without hg comölaining 19:40:59 <andythenorth> I didn't 19:41:13 <Ammler> andythenorth: you had to, as you had 2 heads 19:41:17 <andythenorth> planetmaker pushed his change in the exact time between my pull and my push 19:41:21 <andythenorth> is one factor 19:41:34 <andythenorth> the other factor is I had old commits that were never pushed 19:41:43 <andythenorth> which should create 1 or 2 new heads 19:41:57 <andythenorth> so total, 4 heads :P 19:42:00 <Ammler> andythenorth: yes, but then you switched from that head sometime ago 19:42:16 <andythenorth> will still get pushed though if I have a local commit on it 19:42:16 <Ammler> hmm 19:42:18 <andythenorth> won't it? 19:42:35 <Ammler> andythenorth: as said, reclone your repo is useless 19:42:40 <Ammler> since you already pushed it 19:42:49 <Ammler> you will again pull everything 19:43:01 <Rubidium> just strip the last rev on the server? 19:43:08 <Ammler> Rubidium: we could :-) 19:43:11 <andythenorth> Ammler: I still have a broken local repo 19:43:13 <Ammler> but too late 19:43:19 <andythenorth> it contains uncommitted merges 19:43:28 <andythenorth> committing those is just reopening the problem 19:43:30 <Ammler> andythenorth: then strip some 19:43:50 <Ammler> in worst case strip 0 19:43:53 <Ammler> hg strip 0 19:44:26 <planetmaker> uhm... I don't like history-changing commits 19:44:30 <andythenorth> no 19:44:55 <Ammler> planetmaker: what's that? 19:45:14 <andythenorth> new repo time 19:46:09 <planetmaker> Ammler: ops like strop 19:46:12 <planetmaker> *strip 19:46:26 <andythenorth> just going to cause trouble 19:46:27 <planetmaker> rather use a hg ci --close-branche 19:46:38 <planetmaker> just checking whether it works 19:46:42 <Ammler> planetmaker: you can't commit a strip :-P 19:47:20 <Ammler> I didn't mean andythenorth should strip on the server 19:47:26 <Ammler> he should strip his local repo 19:47:48 <Ammler> easier as reclone 19:48:06 <planetmaker> I don't think so 19:48:14 <andythenorth> come back .hgignore_local, I need you :P 19:48:20 <planetmaker> cloning anew is easier than strip and 0% error chance 19:48:25 <andythenorth> 0% error chance 19:48:38 <andythenorth> nothing that might reintroduce boring, time wasting issues 19:49:00 <andythenorth> incidentally, what was hg rebase -d tip supposed to do? 19:49:11 <planetmaker> I just closed the dead head ;-) 19:49:15 <planetmaker> pull 19:49:26 <Rubidium> just use subversion. They you can't get these kinds of issues (you just get some other issues) 19:49:26 <planetmaker> works nicely. hiding dead heads :-P 19:50:04 <Brot6> FIRS Industry Replacement Set - Revision 2404:26e5cf5fa99b: Close dead head (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/26e5cf5fa99b 19:50:06 <planetmaker> :-) 19:50:31 <Ammler> Rubidium: which issue you don't get we have here? 19:50:50 <planetmaker> merges cross-branch / head 19:50:50 <Ammler> you mean because subversion has no branches at all? 19:50:57 <planetmaker> it does 19:51:19 <Ammler> planetmaker: yes, call directories branches ;-) 19:51:39 * andythenorth has a working repo 19:51:45 <Ammler> and some other random directory we call tags :-P 19:52:22 <Rubidium> Ammler: a mess when you "schedule" committing and pushing incorrectly 19:52:52 <Ammler> Rubidium: that is the bid advantage of dvcs, you don't need to "schedule" 19:53:04 <Ammler> hg (or git) is able to merge :-) 19:53:32 <Rubidium> yes, which is the mess I'm talking about 19:53:38 <andythenorth> it's a mess :P 19:53:43 <Ammler> only user issue 19:53:47 <andythenorth> it's clearly not safe for users 19:54:04 <Ammler> I don't think, andythenorth would be able to handle the same better with svn 19:54:05 <Rubidium> creating new heads as there are different interpretations of newest based on the user 19:54:18 <andythenorth> I don't like svn much either, but I've not lost work through it 19:54:23 <planetmaker> non-unique "nice" versions 19:54:43 <planetmaker> andythenorth: you don't need to loose work through hg either 19:54:47 <planetmaker> it's just mis-handling it 19:54:53 <planetmaker> and you'd get the same with svn 19:55:03 <andythenorth> maybe 19:55:04 <Ammler> I mean, hg is not just svn but dedicated, it has also much better merge functionalitiy 19:55:13 <andythenorth> I didn't lose work to svn so far 19:55:21 <andythenorth> in four years 19:55:46 <planetmaker> you didn't use it with people commiting conflicting stuff? 19:55:58 <planetmaker> that's always when you mess up (sorry to say) 19:56:05 <andythenorth> with svn you just merge 19:56:10 <andythenorth> manually usually 19:56:13 <planetmaker> which basically indicates you should need learn about proper merging 19:56:18 <Ammler> andythenorth: yes, just liked to say :-) 19:56:20 <planetmaker> yes. Why don't you do it here? 19:56:21 <Rubidium> Ammler: yet I'd dread using hg at work... (for LabView) 19:56:34 <andythenorth> merge? 19:56:38 <andythenorth> because I've been told not to 19:56:53 <andythenorth> and because some of the issues I've had are just...weird 19:56:53 <planetmaker> always merge before you loose work ;-) 19:57:12 <Ammler> well, you don't need to merge, you can also push your own branch 19:57:16 <planetmaker> but merge it in a sensible way without undoing work others did 19:57:21 <Ammler> you don't lose work 19:57:27 <planetmaker> or that 19:57:33 <planetmaker> which adds new heads... 19:57:33 <andythenorth> it's easier just to save a patch and bin the repo 19:57:41 <planetmaker> ho... 19:57:41 <Ammler> and merging unfinished features is bad imo 19:57:50 <Ammler> it is "svn behavior" 19:58:01 <planetmaker> andythenorth: for that reason mq was invented 19:58:05 <planetmaker> no need to bin anything 19:58:08 <Ammler> planetmaker: not really 19:58:31 <Ammler> git doesn't use patch queue 19:58:37 <andythenorth> it's confusing tbh 19:58:44 <andythenorth> when I use svn it's simple 19:58:55 <Ammler> andythenorth: because svn can't be complicated 19:59:07 <planetmaker> simply as svn knows no heads 19:59:15 <Rubidium> still... you try to use hg as if it were subversion 19:59:17 <planetmaker> as there's a unique order 19:59:25 <Ammler> it is so basic limited technique 19:59:26 <Rubidium> trying to prevent merges and the likes 19:59:36 <Ammler> Rubidium: that is the case here, yes 19:59:50 <planetmaker> might be not a good idea, though 20:00:10 <planetmaker> why should we use it like svn? 20:00:51 <Ammler> Rubidium: a rebase is basically also a merge 20:00:59 <Rubidium> I'm not saving you should, I'm saying that the current behaviour is as if you were using subversion 20:01:03 <Ammler> technically* 20:01:21 <Rubidium> Ammler: not really, it's like svn up 20:01:39 <Ammler> yep 20:01:51 <Ammler> svn up does merge too, doesn't? 20:01:57 <andythenorth> no 20:02:07 <andythenorth> not if you have conflicts 20:02:16 <Rubidium> it tries to keep the changes applied, and if it fails it creates a conflict 20:02:18 <Ammler> how you call it? 20:02:36 <andythenorth> in an svn team the workflow is totally different 20:02:37 <andythenorth> it has to be 20:02:38 <planetmaker> it basically does what hg merge does 20:03:29 <Ammler> planetmaker: the issue with import export pop and push is that it does much worse merges 20:03:49 <Ammler> it can quite easy conflict, while a rebase or merge doesn't 20:04:39 <Ammler> http://hgtip.com/tips/advanced/2010-02-11-merging-mq-patches-with-rebase/ <-- here is a example 20:04:40 <Webster> Title: Merging MQ Patches with Rebase / hg tip (at hgtip.com) 20:05:59 <andythenorth> ok so here's a question 20:06:14 <andythenorth> when I want to back out of a commit, I use hg rollback 20:06:16 <Rubidium> in any case, hg sucks very much with LabView. Much more than subversion would do 20:06:31 <andythenorth> but if I commit, then pull, and use rollback, that backs out of the pull 20:06:38 <andythenorth> so how do I then backout of the commit? 20:06:57 <planetmaker> a single one? hg rollback 20:07:02 <planetmaker> if it's the last one 20:07:12 <andythenorth> but assume I've pulled since commit 20:07:16 <planetmaker> if there's more than one: don't 20:07:35 <planetmaker> andythenorth: don't first pull... 20:07:53 <andythenorth> just try to push? 20:08:00 <planetmaker> first push. if it fails, rollback, then pull, then commit, then push 20:08:14 <andythenorth> and if I have a stack of n commits 20:08:14 <andythenorth> ? 20:08:16 <planetmaker> push will fail, if you'd create a new head ;-) 20:08:19 <andythenorth> (other than use mq) 20:08:20 <Ammler> the commit is easy done via history 20:08:27 <planetmaker> if you have n commits: pull. merge. commit push 20:09:02 <andythenorth> so a merge *is* allowed? 20:09:06 <planetmaker> but... why would you have n commits? 20:09:17 <andythenorth> because it's dvcs? 20:09:24 <Ammler> was it ever forbidden? 20:09:34 <planetmaker> Ammler: you complain(ed) every single time ;-) 20:09:44 <planetmaker> I complained 50% of the time ;-) 20:09:52 <Ammler> well, it is stupid 20:09:52 <andythenorth> every merge I get rapped on the knuckles 20:09:55 <Ammler> not forbidden 20:10:05 <andythenorth> hmm 20:10:06 <andythenorth> see 20:10:08 <Ammler> but if you can't better, d 20:10:13 <andythenorth> I don't understand what I'm supposed to do 20:10:24 <Ammler> in your case, merge 20:10:33 <Ammler> the rest here does rebase 20:10:54 <planetmaker> andythenorth: the point imho is: there's usually little reason to commit n times without pulling the repo 20:11:03 <Ammler> I will try to remember not to complain anymore ;-) 20:11:06 <andythenorth> depends how good your wifi is :P 20:11:11 <planetmaker> only when one travels. And it can be solved via mqs 20:11:18 <andythenorth> I suspect at least one head is caused by my loss of wifi 20:11:20 <planetmaker> thus merges can be avoided. But... 20:11:41 <planetmaker> they're certainly no no-no 20:11:44 <Ammler> andythenorth: the issue is your merges were just forgotten pulls, and I am sure it was everytime just one commit 20:12:25 <Ammler> it just looks silly, but it for sure not forbidden 20:13:30 <Ammler> specially for features, it would be nice to make (unnamed) branches and merge if the feature is finished 20:13:56 * Rubidium remembers the times he made a dozen or so patches before he could commit them 20:14:25 <Ammler> Rubidium: yes, that is bad, as appling patches is much harder then merging 20:14:55 <andythenorth> it's clean + safe though ;) 20:15:22 <andythenorth> an mq is increasingly appealing 20:15:25 <Ammler> andythenorth: check the link I posted about mq rebase 20:15:34 <planetmaker> Ammler: not if done properly... 20:15:49 <planetmaker> like the mq rebase 20:15:52 <Ammler> appling a patch can conflict, while merging works 20:16:04 <Ammler> mq rebase is not pop and push 20:16:17 <Ammler> that's the point 20:16:24 <andythenorth> hmm 20:16:28 <planetmaker> ach... 20:16:30 <Rubidium> that's merely because patch can't perform a 3 way merge 20:16:33 <andythenorth> anyway, it's becoming a bit of a headache for all of us 20:16:37 <Ammler> Rubidium: exactly 20:16:50 <planetmaker> Ammler: but that is _no_ argument against using mq 20:17:02 <Ammler> planetmaker: well, you use mq with pop and push 20:17:05 <Rubidium> which is why you generally ought to patch the revision it was made for and them use the vcs to update it to HEAD 20:17:19 <Ammler> if you would rebase, you could as could not use mq 20:17:33 <Ammler> good* 20:17:54 <Rubidium> imo mq and rebasing are the same thing 20:18:05 <Rubidium> but done differently 20:18:14 <Rubidium> each with their own benefits and drawbacks 20:18:40 <Rubidium> one allows easier changing/reordering of patches, whereas the other allows easier updates 20:18:55 <Rubidium> and basically mq should get 3 way merge for updates 20:20:16 <planetmaker> quite so. 20:20:25 <andythenorth> 12 open issues for FIRS 0.7 20:20:27 * andythenorth suspects more 20:20:31 <planetmaker> and that's the reason the rebase command is part of the mq extension 20:21:43 <Terkhen> I should finish spritelayout templating in two or three days 20:21:49 <planetmaker> see Updating your patches when the underlying code changes in http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html 20:21:50 <Webster> Title: Chapter 12. Managing change with Mercurial Queues (at hgbook.red-bean.com) 20:21:50 <Terkhen> I go slow because of summer laziness :P 20:22:26 <Ammler> mq is mq, rebase is rebase, you compare different things 20:22:48 <planetmaker> ^ Ammler that way mq works nicely. But in 90% of the cases this complicated way of updating is not needed 20:23:14 <Ammler> I meant qpop qpush is not rebase 20:23:56 <Ammler> or rather qpop - up - qpush 20:24:13 <Ammler> planetmaker: isn't that how you do it? 20:24:33 <planetmaker> as said: 90% of the time it works well 20:25:00 <planetmaker> in 10% of the time the way as described in the link in the chapter given works 20:25:00 <Ammler> compared to "hg rebase -d tip" (1 command) which works in more cases better 20:25:04 <planetmaker> no 20:25:17 <planetmaker> not needed 20:25:28 <Ammler> it is less command for better results? 20:26:05 <Ammler> mq should be used for patches imo, not for complicated rebase :-) 20:26:17 <planetmaker> that's what is done... 20:26:27 <Ammler> you use it for rebase 20:26:28 <planetmaker> and it is the very same thing 20:28:18 <Ammler> :-) 20:29:40 <planetmaker> anyway, the result is now (again) that nothing became clearer to andy as everyone say "do it this way" which all differ 20:29:42 <Terkhen> with rebase you mean hg qpop -a && hg pull -u && hg qpush? 20:30:00 <planetmaker> that's not a rebase 20:30:27 <planetmaker> though it'll rebase the patches without work, if there's no conflict ;-) 20:31:04 <planetmaker> ammler wants to first permanently merge the patches, then pull, then rebase 20:31:13 <planetmaker> which I consider not optimal 20:31:42 <Ammler> why? 20:32:14 <planetmaker> as it means to merge something permanently which you know requires work and testing 20:32:25 <planetmaker> before it becomes useful 20:32:34 <Ammler> he? 20:33:07 <Ammler> so you force conflicts to force yourself to test your commit? 20:33:09 <planetmaker> if it didn't a patch would apply to both revisions just the same ;-) 20:33:30 <Terkhen> anything else than what I listed requires me to learn more stuff, and if it works I don't want to learn more :P 20:33:58 <planetmaker> practical ;-) 20:33:59 <Ammler> Terkhen: planetmaker does not rebase, he does pop patches, update and push patches 20:34:14 <planetmaker> obviously both of us do so ;-) 20:34:17 <Ammler> rebase is like a merge 20:35:12 <Ammler> planetmaker: but back to andy, best way is indeed to merge :-) 20:35:37 <Ammler> but then you merge your feature, not just forgotten pulls ;-) 20:36:50 <andythenorth> commit hook :P 20:37:30 <Ammler> Terkhen: if you develop for svn, do you create patches and commit or do you develop in svn directly and then merge? 20:37:38 <Ammler> s/svn/openttd/ 20:37:48 <planetmaker> Ammler: we use hg mq ;-) 20:37:59 <Ammler> so patches 20:38:10 <Ammler> or do you rebase? 20:38:47 <planetmaker> that question doesn't apply really 20:39:07 <frosch123> Terkhen: rebase is qimport+update+qfinish 20:39:14 <Ammler> frosch123: no 20:39:25 <frosch123> sure 20:39:30 <Ammler> :-) 20:39:40 <Ammler> that would make heads 20:39:47 <planetmaker> no 20:39:53 <Ammler> ah well, you should know 20:40:06 <Ammler> planetmaker: qimport does apply the patch to parent 20:40:17 <Terkhen> Ammler: I use hg mq for svn too 20:40:18 <Ammler> and parent does not change with update 20:40:23 <Terkhen> and later apply the patches one by one 20:40:38 <frosch123> Ammler: qimport is not only to import patches into the queue, but also to import revisions into the queue 20:40:56 <frosch123> so you compeltely undo one head and turn it into patches, then update, and reapply the patches 20:41:08 <Ammler> frosch123: but update doesn't change the parent of your patch 20:41:15 <Terkhen> I have never used qfinish either anyways :P 20:41:36 <frosch123> well, with update i mean update to the other head 20:42:31 <Ammler> hmm, qimport does import a patch 20:44:09 <frosch123> hg qimport -r<common base>:<one head>; hg qpop -a; hg up -r<other head>; hg qpush -a; hg qfinish 20:44:53 <Ammler> is that documented? 20:45:02 <frosch123> hg help qimport lists it 20:45:09 <frosch123> and i used it several times instead of rebase 20:45:32 <frosch123> well, i used it instead of rollback 20:45:37 <frosch123> for multiple revisions 20:46:04 <Ammler> why sould that work, but pop - up - push doesn't? 20:46:28 * Terkhen goes to work a bit more :) 20:46:46 <andythenorth> Terkhen: make sure you pull :P 20:46:46 <frosch123> Ammler: qimport is for the case when you already commited the queue 20:46:54 <frosch123> it's the reverse of qfinish 20:46:54 <Brot6> FIRS Industry Replacement Set - Revision 2405:17f27a82670e: Fix: Metal Foundry layouts using wron... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/17f27a82670e 20:47:01 <Ammler> andythenorth: he doesn't 20:47:15 <Ammler> need 20:47:25 <andythenorth> he does :P 20:47:26 <planetmaker> I should use qimport more ;-) 20:47:26 <Ammler> that't the whole point about :-) 20:47:58 <Brot6> FIRS Industry Replacement Set - Bug #2969 (Closed): Metal Foundry wrong sprites in layout 1 (andythenorth) @ http://dev.openttdcoop.org/issues/2969#change-7441 20:48:02 <frosch123> oh, there is even a -P option for qimport 20:48:18 <frosch123> and there is also -P for qfinish :o 20:48:22 <andythenorth> Terkhen: template the metal foundry? :P :) 20:48:39 <frosch123> hmm, no there is not 20:48:46 <Terkhen> I always create a backup diff (which I usually forget), pull, commit, push in that order 20:48:59 <Terkhen> and if you prefer it I'll do the metal foundry first 20:48:59 <planetmaker> frosch123: for qfinish? 20:49:07 <frosch123> yeah, only for qimport 20:49:10 <Terkhen> I already left the forest and fruit plantation for the end :P 20:49:17 <Terkhen> that code is crazy 20:49:23 <andythenorth> not crazy 20:49:26 <andythenorth> just big 20:49:26 <planetmaker> ok... I thought my 1.9 hg was already again too old ;-) 20:49:27 <Ammler> frosch123: what qimport and qfinish is is clear, but why should that be rebase? 20:49:43 <Ammler> why does qpop and qpush a patch not work, but rebase does? 20:49:56 * Terkhen does metal foundry 20:50:21 <Ammler> accoring to you, this is the same 20:50:46 <andythenorth> Ammler: how about a commit hook for those who can't remember how to use hg properly? 20:51:02 <andythenorth> you like that kind of challenge :) 20:51:02 <frosch123> Ammler: what? that was my whole point: you can do a rebase also with qimport 20:51:35 <Ammler> http://hgtip.com/tips/advanced/2010-02-11-merging-mq-patches-with-rebase/ <-- check this 20:51:36 <Webster> Title: Merging MQ Patches with Rebase / hg tip (at hgtip.com) 20:52:03 <Terkhen> something like a "you forgot to pull" commit hook? 20:52:09 <Ammler> there is clearly a difference between rebase and qpop-up-qpush 20:52:21 <Terkhen> s/commit/precommit/ 20:52:30 <andythenorth> Terkhen: yes 20:52:42 <andythenorth> poka yoke 20:52:42 <Ammler> andythenorth: you got me wrong, obviously :'-( 20:52:58 <andythenorth> when a problem recurs, prevent it 20:53:32 <frosch123> Ammler: yes, the 3-way merge 20:53:47 <Ammler> frosch123: your "rebase" isn't 20:53:53 <frosch123> yip 20:53:58 <Terkhen> I'd like that too, I keep a clean firs checkout around just in case I mess mine up if I forget to pull :) 20:54:48 <andythenorth> I think it's just a shell script or such needed 20:54:51 <andythenorth> but I dunno 20:54:56 <Ammler> there is backup repo at bitbucket 20:55:24 <Ammler> so you do not really need to backup just because you fear devzone isn't reachable 20:56:03 <Terkhen> no, I keep the clean firs checkout because it is way faster to copy locally than to checkout from the net 20:56:08 <Terkhen> my internet sucks sometimes :) 20:56:16 <andythenorth> it's not a bad idea 20:56:26 <andythenorth> hmm 20:56:28 <Ammler> ah well, also a local copy is much smaller 20:56:43 <Ammler> (if you use linux fs), dunno how windows works 20:56:45 <andythenorth> I saw a thing where you can push to a local repo, then push from there to remote 20:56:48 <Terkhen> FIRS is huge, and it has a lot of revisions... depending on the day it can take 6 or 7 minutes to clone from internet 20:57:08 <Terkhen> andythenorth: yes, just clone from internet and after that clone from that folder 20:57:47 <Ammler> andythenorth: it is another kind of branching 20:57:49 <Terkhen> I don't do it because I just want to push once 20:58:31 <Ammler> andythenorth: but it is useless if you make the other repo pushing automatically ;-) 20:58:52 <andythenorth> I'd be happy with a precommit hook that just pulled 20:59:07 <Ammler> well, or simply do not push with -f 20:59:18 <Ammler> I mean there is a reason for that flag 20:59:34 <andythenorth> I should alias that command to something else :P 20:59:51 <andythenorth> poka yoke 21:00:09 <Ammler> anyway, merging is never wrong 21:00:34 <Ammler> also one commit, it was just funny to watch it that often from you :-) 21:00:50 <andythenorth> poka yoke 21:00:52 <andythenorth> :P 21:00:52 <Ammler> I really didn't mean it evil 21:01:25 <andythenorth> I didn't think so ;) 21:03:27 * andythenorth has to use this poka yoke sometimes: http://www.thetoyotasystem.com/wp-content/uploads/2009/05/pokayoke4.png 21:12:30 *** andythenorth has left #openttdcoop.devzone 21:15:39 <Terkhen> of course he's gone before I finished :P 21:15:59 <Terkhen> planetmaker: is there any unused register on industry persistent storage? 21:16:15 <planetmaker> yes 21:16:19 <planetmaker> what / why do you need? 21:18:06 <Terkhen> it's something minor, but right now the smoke of all industries of the same type is synchronized, it would be nice to give a random offset to animation frames for each industry 21:18:08 <planetmaker> the only consistently unused pers. storage is 14: sprites/nml/defines.pnml 21:18:16 <Terkhen> maybe there is some other way than wasting a persistent register for that 21:18:32 <planetmaker> yes... just use the random bits of the industry... 21:18:36 <planetmaker> no register needed 21:18:37 <Terkhen> oh :) 21:18:46 <Terkhen> nice, I'll use that once I template smoke 21:19:18 <planetmaker> variable 5F or a random_switch which writes it into temp storage 21:19:42 <planetmaker> from the industry permanet random bits. 21:20:19 <Terkhen> hmm... but I'll need some way to get the random offset, and it must be always the same 21:21:55 <planetmaker> yes. The random bits need not be re-randomized. And they aren't, if there's no re-randomizatin trigger set 21:22:30 <planetmaker> which by default isn't 21:22:56 <Terkhen> hmm... ok, I'll look into it once this is done 21:22:58 <planetmaker> thus you can just add a few random bits to the animation frame and modulo that by the animation frame number 21:24:24 <Terkhen> yes :) 21:24:34 <Terkhen> but are we sure that the random bits are not rerandomized in any case? 21:24:48 <planetmaker> quite. As you have to ask for it 21:25:01 <Terkhen> ok :) 21:25:13 <planetmaker> or things like colour would change, too ;-) 21:26:07 <Brot6> FIRS Industry Replacement Set - Revision 2406:33a9085216ed: Codechange: Metal Foundry uses advanc... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/33a9085216ed 21:29:08 <Terkhen> I'm going to template smoke right now, it is boring to write which "smoke template" I'm using once I figure out which one it is 21:36:57 *** frosch123 has quit IRC 21:49:07 <planetmaker> Good night 21:53:10 <Terkhen> good night planetmaker 22:12:38 *** Zuu has quit IRC 22:17:51 *** ODM has quit IRC