Log for #openttdcoop.devzone on 14th August 2011:
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) @
10:43:45  <Brot6> FIRS Industry Replacement Set - Revision 2378:c544b370841f: Codechange: Machine shop uses tile lo... (planetmaker) @
10:52:43  <Brot6> FIRS Industry Replacement Set - Revision 2379:d37ce45dd087: Codechange: Sawmill uses tile locatio... (planetmaker) @
10:55:26  <Brot6> FIRS Industry Replacement Set - Revision 2380:62b01bf5d93d: Codechange: Use advanced spritelayout... (Terkhen) @
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) @
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) @
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) @
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> <-- the 'ss' bits 0...4
12:10:11  <Webster> Title: VariationalAction2/Industry Tiles - GRFSpecs (at
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...
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) @
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:
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:
13:19:53  <Webster> Title: VariationalAction2/Industry Tiles - GRFSpecs (at
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:
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) @
13:35:53  <Brot6> SuperLib - Revision 11:d4c9c6fe5270: Take use_rvs, use_planes, use_trains and use_ships AI Settin... (Zuu) @
13:44:29  <Brot6> Total Town Replacement Set 4 - Revision 6:f603fa92df8c: Added new shops graphics (George) @
13:53:43  <Brot6> SuperLib - Revision 12:4741ea23a371: Added 'not implemented' comment to a Road station function. ... (Zuu) @
14:03:58  <Brot6> FIRS Industry Replacement Set - Revision 2384:12e0e6b9dc69: Codechange: Furniture Factory uses ad... (Terkhen) @
14:17:38  <Brot6> FIRS Industry Replacement Set - Revision 2385:ea10d63f8dc8: Codechange: Glass Works uses advanced... (Terkhen) @
14:39:02  <Brot6> FIRS Industry Replacement Set - Revision 2386:34b2dbed888a: Codechange: Recycling plant 'uses' ti... (planetmaker) @
14:45:40  <Brot6> FIRS Industry Replacement Set - Revision 2387:8a7f1b38d4b7: Codechange: Grain Mill uses advanced ... (Terkhen) @
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) @
14:58:46  <Brot6> FIRS Industry Replacement Set - Revision 2389:43a15a42fc47: Codechange: Hotel uses advanced sprit... (Terkhen) @
15:17:42  <Brot6> DictatorAI - Revision 141:fc21a4c4d577: - ... (krinn) @
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) @
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) @
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) @
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) @
16:25:47  <Brot6> FIRS Industry Replacement Set - Revision 2393:48e1ee712a18: Codechange: Sheep farm uses tile loca... (planetmaker) @
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) @
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) @
16:46:09  <Brot6> SuperLib - Revision 15:f4fea24f2db1: version 13 (Zuu) @
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) @
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) @
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) @
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) @
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) @
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 -
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) -
17:31:32  <Brot6> SuperLib - Revision 16:a67fc3d5261b: Fix: Don't require 8 in production since only one is require... (Zuu) @
17:31:32  <Brot6> Tutorial AI - Revision 4:8e07f72ea3b9: Use SuperLib to build road stations + depot. => Reduced co... (Zuu) @
18:32:50  <Brot6> Tutorial AI - Revision 5:5dbc5e64085e: Move menu to Town A, before building a road station there (Zuu) @
19:03:10  <Brot6> clientpatches: compile of r22751 still failed (#2964) -
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 -
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) @
19:09:52  <andythenorth> ho
19:09:53  <Brot6> serverpatches: compile of r22751 still failed (#2966) -
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) -
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) @
19:12:15  <Brot6> FIRS Industry Replacement Set - Revision 2400:f7fb6759fb6b: Fix #2972: Cargo acceptance of hardwa... (planetmaker) @
19:12:15  <Brot6> FIRS Industry Replacement Set - Bug #2972 (Closed): Hardware store acceptance wrong (planetmaker) @
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) @
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>
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://
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>
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
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) @
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) @
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> <-- here is a example
20:04:40  <Webster> Title: Merging MQ Patches with Rebase / hg tip (at
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
20:21:50  <Webster> Title: Chapter 12. Managing change with Mercurial Queues (at
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) @
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) @
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> <-- check this
20:51:36  <Webster> Title: Merging MQ Patches with Rebase / hg tip (at
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:
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) @
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

Powered by YARRSTE version: svn-trunk