Log for #openttdcoop.devzone on 16th April 2010:
Times are UTC Toggle Colours
00:31:17  <Webster> Latest update from devactivity: Nutracks - Bug #865: Track costs are inconsistent and exploitable <>
00:47:04  <Webster> Latest update from devactivity: Nutracks - Bug #865: Track costs are inconsistent and exploitable <>
09:14:52  <Webster> Latest update from devactivity: Nutracks - Bug #865: Track costs are inconsistent and exploitable <>
09:32:10  *** ODM has joined #openttdcoop.devzone
09:50:27  *** ODM has quit IRC
09:56:50  *** ODM has joined #openttdcoop.devzone
10:37:40  *** ODM has quit IRC
11:09:07  *** KenjiE20 has joined #openttdcoop.devzone
11:53:56  *** ODM has joined #openttdcoop.devzone
12:04:25  <Webster> Latest update from devactivity: Nutracks - Bug #865: Track costs are inconsistent and exploitable <>
12:46:46  <planetmaker> <-- Ammler zip with tar like that?
12:48:41  <Ammler> if [ -e $</$(MAIN_TARGET) ]; then rm $</$(MAIN_TARGET); fi --> [ -e $</$(MAIN_TARGET) ] && rm $</$(MAIN_TARGET)
12:48:56  <Ammler> the same and better readable, imo
12:49:15  <Ammler> ah, might be bashims
12:49:29  <planetmaker> it's not a bashism. I use such already
12:49:48  <planetmaker> but... not sure it's better readable :-)
12:50:25  <planetmaker> also: it will issue an error, if the first is false
12:50:29  <planetmaker> iirc
12:50:33  <Ammler> no
12:50:45  <Ammler> then, it wouldn't be the same
12:50:51  *** ODM has quit IRC
12:51:46  *** ODM has joined #openttdcoop.devzone
13:44:58  <Ammler> planetmaker: <-- still needed?
13:46:45  <planetmaker> nope
13:47:01  <planetmaker> it's in trunk for long time
13:51:25  <Webster> Latest update from devactivity: Example NewGRF Project - Feature #897: make bundle in a subdir <>
13:52:04  <Ammler> <-- other obsolete patches?
13:53:06  <planetmaker> well. clientpatches_070.diff is only for openttd 0.7.0. Not sure it's needed.
13:53:17  <planetmaker> possibly moved to a separate folder
13:58:06  <Ammler> Hmm, I still wait for Hirundos Docs about patch queue workflow :-)
13:59:26  <planetmaker> hm, isn't there a bash script by which can be used?
13:59:32  <planetmaker> Not that it is very descriptive...
14:01:06  <Ammler>
14:01:14  <Ammler> I see nothing...
14:03:11  <planetmaker> not there
14:03:55  <planetmaker>
14:04:01  <Hirundo> Ammler: I'll look this weekend
14:04:32  <Ammler> thank you in advance :-P
14:21:53  <Webster> Latest update from devactivity: NFO Meta Language - Revision 81: Feature: finish list of vehicle vars <> || #openttdcoop Client Patch Pack - Revision 760: Remove compile_mac, already in trunk for a long ti... <>
14:30:52  <Hirundo> Yexo: are 60+x variables possible?
14:31:05  <Yexo> thsoe are a problem
14:31:27  <Yexo> they are possible, but only via the var[0x60, shift, mask, param] syntax
14:33:41  <planetmaker> all "related object" variables are 60+x
14:34:17  <Yexo> huh? "related object" variable sjust have another type byte, 8A instead of 89
14:34:39  <planetmaker> eh?
14:35:09  <Yexo> under "type"
14:35:24  <Yexo> "Use 81/85/89 to decide upon a general variable, or a variable of the object in question.Use 82/86/8A to refer to the "related" object:"
14:37:25  <planetmaker> hm... :-)
14:38:13  <Hirundo> Yexo: will varname(param) or varname[param] work, or does that give rise to parser conflicts?
14:38:24  <PeterT> does the #openttdcoop web-irc allow connecting to BNCs?
14:38:34  <PeterT> /server, for example?
14:38:48  <Yexo> ID() is already used, but ID (expression) is not I think
14:39:31  <Yexo> reduce_expr would need some work though
14:40:18  <Yexo> did you already think about real action2 for industries? the production callback thing?
14:42:17  <planetmaker> hm, learnt something new, Yexo :-)
14:42:25  <Ammler> PeterT: why not?
14:42:37  <planetmaker> Still it seems to me that (nearly?) all "related" vars are 60+x
14:42:43  <PeterT> I don't know, does it Ammler?
14:42:47  <PeterT> never seemed to work for me?
14:42:52  <Ammler> yes, but another port
14:43:14  <PeterT> what port?
14:43:17  *** PeterT|IRC has joined #openttdcoop.devzone
14:43:23  <PeterT> I'm using ttp://
14:43:31  <Yexo> planetmaker: "related vars" are just the vars of another object
14:43:36  <PeterT|IRC> +h
14:43:44  <Yexo> related vars for industry tiles are the normal industry vars
14:44:01  <Ammler> yep, that is fine, the other web client is for bnc users only and therefor no need to have it public
14:44:03  <Yexo> so if all related vars for industry tiles would be 60+x then all normal industry vars would be 60+x
14:44:33  <PeterT> Ammler: "[10:44] == You may not reregister"
14:44:33  <Yexo> and keep in mind that most 80+x vars aren't listed in the ttdpatch wiki
14:44:45  <PeterT> I tried /server 7777 username:pass
14:45:12  <Ammler> does our client support that?
14:45:30  <PeterT> that's what I'm asking :-P
14:45:42  <PeterT> <PeterT> does the #openttdcoop web-irc allow connecting to BNCs?
14:46:01  <planetmaker> hm... why aren't those 80+x vars listed there...
14:47:04  <Ammler> PeterT, I don't know
14:47:14  <Ammler> I made a new webirc instance for our bnc
14:47:14  *** PeterT|IRC has quit IRC
14:47:23  <PeterT> oh :-(
14:47:28  <PeterT> I need one that does
14:47:58  <Ammler> ask joelton to setup qwerbirc on his bouncer
14:48:16  <Ammler> it is very easy to setup
14:48:30  <Ammler> or try mibbit
14:48:36  <PeterT> Nope.
14:48:37  <PeterT> Doesn't work
14:52:19  <Hirundo> Yexo: how does writing to (temp/persistent) storage currently work?
14:52:31  <Yexo> not yet implemented
14:53:06  <Yexo> I had planned to introduce STORE_TEMP(expr, expr) and STORE_PERSISTANT(expr, expr) functions for that
14:53:11  <planetmaker> hm, you should add a small example newgrf to the repo ;-)
14:53:26  <Yexo> planetmaker: yes, that's on my todo list
14:53:32  <Yexo> but the syntax is still changing
14:53:37  <planetmaker> :-)
14:54:06  <Yexo> Hirundo: but suggestions for an alternative syntax there are very welcome
14:55:01  <Yexo> we also need a syntax for "expr1 SOMETHING expr2" that evaluates to expr2
14:55:07  <Yexo> so you can store and calculate something else
14:55:51  <Hirundo> local x = 1 + variable_foo <- write x into temp storage
14:56:07  <Yexo> Hirundo: it has to be part of an action2
14:56:44  <Hirundo> main problem wrt to temp storage is that dynamic adressing is not possible
14:57:03  <Hirundo> else, we could setup a stack with local variables and such cool stuff :)
14:57:05  <Yexo> loading a dynamcic adress is possible, storing not
14:57:19  <Hirundo> it's the other way around
14:57:37  <Yexo> you're right
14:58:27  <Yexo> but local variables are no problem, you just have to resolve the locations at compile time
14:59:26  <Yexo> supporting (x ? y : z) for example is possible
14:59:54  <Yexo> where all of x,y and z can be dynamic
15:00:28  <Hirundo> when starting to combine action2s with 7E proc calls, you may run into problems
15:00:48  <Yexo> I think I already solved that
15:01:11  <Yexo> resolving the temporary storage locations is done after parsing the actions, so the proc calls are known at that time
15:01:16  <Hirundo> I mean, how to avoid slot conflicts between different variables in different action2s
15:01:45  <Yexo> look at resolve_tmp_storage in
15:03:13  <Yexo> there might be a bug in parse_actionD :(
15:03:22  <Yexo> param[0] = param[1] + param[2] + 9; <- that doesn't compile as it should
15:03:59  <Hirundo> :(
15:05:28  *** Seberoth has joined #openttdcoop.devzone
15:05:46  <Hirundo> regarding 60+x, there are quite a number of variables that accept extra parameters in storage 0x100
15:06:44  <Yexo> su ID(param_list) ?
15:06:59  <Hirundo> That might be most flexible, yes
15:07:02  <Yexo> first param is byte-sized, the rest is stored in temp[0x100+num] ?
15:07:23  <Hirundo> yup
15:15:49  <Yexo> actionD code is fixed now
15:16:04  <Yexo> it could use some optimalizations, but that's not a major problem
15:18:57  <Yexo> for example this, it first stores param[0] in param[0x40], then uses param[0x40] in an action6 while it could just as well use param[0x00] directly in that action6
15:24:36  <Hirundo> Basically any \D= operation without preceding action6 and without usage of <data> can be optimized away
15:36:07  <Yexo> I don't think so
15:36:44  <Yexo> oh, \D=, yes
15:37:23  <Yexo> actually no
15:37:53  <planetmaker> :-D
15:37:56  <Webster> Latest update from devactivity: NFO Meta Language - Revision 82: Fix: the code that parsed actionD was a little too happy to use ... <>
15:38:52  <Yexo> consider this code:
15:57:27  <Hirundo> Add "intermediate" to my statement
16:14:10  <Hirundo> Yexo: What are the main todos currently?
16:14:32  <Yexo> real action2 for industries is completely missing
16:15:00  <Yexo> I'm going to implement STORE_TEMP/STORE_PERM/LOAD_TEMP/LOAD_PERM now
16:17:45  <Yexo> after that the property / variable lists need to be completed
16:17:58  <Hirundo> and documented
16:18:09  <Yexo> that too
16:18:33  <Yexo> basically everything needs to be documented
16:18:38  <Yexo> and we need some examples
16:19:19  <Hirundo> Where will the documentation go? openttd wiki? devzone wiki?
16:19:28  <planetmaker> docs/ :-)
16:19:40  <Hirundo> docs/x in html format?
16:19:47  <Yexo> fine by me
16:19:55  <Yexo> that way it's also browseable
16:19:56  <planetmaker> well, having it as a wiki would also make sense
16:20:32  <planetmaker> that'd help to get others contribute / refine / explain details
16:20:40  <planetmaker> get rid of the tedious details ;-)
16:22:06  <Yexo> in that case I think it's best to keep it in the devzone nml wiki
16:22:22  <Yexo> so
16:22:35  <planetmaker> redmine wiki sucks, though ;-)
16:22:54  <planetmaker> I know, I'm not helpful :S
16:23:13  <PeterT> "See the examples/ subdirectory for examples of the syntax."
16:23:16  <Hirundo> We need some proper I/O and error reporting as well, no stack trace dumping please
16:23:18  <planetmaker> though for a documentation like this it's fine, I think
16:25:10  <Yexo> proper i/o shouldn't be too difficult
16:25:22  <Hirundo> It just needs doing
16:25:26  <Yexo> but as I said, I'm going to do the storage in varactio2 first
16:25:35  <Yexo> so work on whatever else you like :)
16:26:04  <Hirundo> I won't really work on anything tonight :)
16:26:25  <Yexo> another todo: store the cargotable labels somewhere global so they can be used in action0 properties and in some action2 resutls
16:26:48  <Yexo> that'll need some thinking, as sometimes we need a bitmask and sometimes the index
16:27:26  <Hirundo> So the cargotable becomes "passengers: "PASS";", right?
16:27:50  <Yexo> why? isn't just PASS enough?
16:28:37  <Hirundo> To me it feels more natural to have it enclosed in quotes, since it is not resolved compile time but copied verbatim, might be me though
16:29:33  * Hirundo adds rail type translation table to the list
16:30:20  <Hirundo> Leaving the quotes makes no difference basically, it's just a different token type
16:30:53  <Yexo> yes, but I was planning on exposing those tokens (PASS, MAIL, ...) in action0 properties
16:31:18  <Yexo> if we use 'passengers: "PASS"' then we could use 'passengers' as token instead
16:31:26  <Yexo> make no difference, but needs an extra token
16:32:12  <Hirundo> hmm
16:33:00  <planetmaker> Yexo: so using PASS and "passengers" as synonymous things? Or...?
16:33:19  <Yexo> planetmaker: that depends on what syntax we're going to support in the end
16:33:43  <planetmaker> well, I just wonder what you just proposed :-)
16:33:44  <Yexo> <- that is the current syntax
16:34:31  <planetmaker> hm. Alternatively then cargotable { passengers, mail, grains, goods, oil, milk } ?
16:34:39  <planetmaker> eh. add quotation marks
16:36:00  <Yexo> <- added an example use
16:36:49  <Yexo> <- I think that was the syntax Hirundo is proposing
16:38:29  <PeterT> Ammler: I just updated join-part
16:38:34  <PeterT> Much, much better
16:38:47  <Ammler> PeterT: I DON'T need it :-P
16:39:04  <PeterT> Ok
16:39:07  <Webster> Latest update from devactivity: Autopilot - Patch #896: Join and Part commands <> || Autopilot - Patch #896: Join and Part commands <>
16:39:09  <PeterT> I still updated it
16:39:19  <Ammler> do you want a list from custom commands I would like?
16:39:26  <PeterT> yes.
16:39:27  <Hirundo> basically, the cargo table is needed to determine which cargoes go in the first 32 for the refit mask, right?
16:39:28  <PeterT> Please
16:39:42  <PeterT> of course, I won't be able to finish them today, I'm going to Spain :-P
16:40:05  <DJNekkid> PeterT: by plane?
16:40:10  <PeterT> Yeah :-(
16:40:16  <DJNekkid> gl on that!
16:40:19  <PeterT> ty
16:40:19  <Ammler> basically everything for updating and patching openttd
16:40:27  <Ammler> restart the server etc and such
16:40:38  <PeterT> restart or reset?
16:40:49  <Yexo> Hirundo: yes, but the order of the cargos is also important
16:40:50  <Ammler> what's reset?
16:40:59  <PeterT> reset == new map
16:41:04  <PeterT> restart == same map again
16:41:13  <PeterT> for server's with World Maps and such
16:41:15  <Ammler> I meant closing openttd
16:41:22  <Ammler> and start new version
16:41:39  <Ammler> with the whole logging
16:41:54  <Hirundo> If we tell the user to refer to cargos by name and not by index, does order then really matter?
16:42:02  <PeterT> Ammler: I don't know if that's possible with TCL
16:42:30  <PeterT> starting new instance of autopilot.tcl with autopilot.tcl? strange...
16:43:50  <planetmaker> Hirundo: IIRC there are some instances where at least the order in the cargo translation table as now matters
16:44:09  <planetmaker> e.g. for defining town effect cargos.
16:44:17  <planetmaker> (or I remember that wrongly)
16:44:31  <Yexo> Hirundo:
16:45:42  <planetmaker> Yexo: Hirundo could one of you give me a very basic newgrf (action8 and maybe one actionA) with this and tell me how to convert that source then into NFO?
16:46:01  <Hirundo> good point, action A and 5 need adding too
16:46:07  <planetmaker> :-)
16:46:21  <Yexo> <- that is what I use to test
16:46:21  <planetmaker> ok. s/actionA/actionF/
16:46:26  <Yexo> comment out the bits you want to test
16:46:30  <Yexo> actionf isn't supported either :p
16:47:19  <planetmaker> ok. That test newgrf will get me started. How do start the compilation / interpretation, though?
16:47:28  <Yexo> python
16:47:42  <Yexo> it'll read the input from data.nml and write to data.nfo
16:47:51  <planetmaker> is the filename of what you pasted?
16:48:05  <Yexo> no, what I pasted is data.nml
16:48:09  <Yexo> is part of the repo
16:48:11  <planetmaker> ah. it's data.nml which you pasted
16:48:29  <Yexo> <- and you a file formatted like this in lang/default.txt
16:48:41  <Yexo> unused strinsg are never written to the nfo, so don't worry about that
16:49:13  <planetmaker> nice :-)
16:49:51  <Hirundo> Yexo: Are you adding this to the todo list, else I will
16:50:02  <Yexo> just add it
16:53:19  <planetmaker>   File "", line 12, in <module>
16:53:21  <planetmaker>     import ply.lex as lex
16:53:22  <planetmaker> ImportError: No module named ply.lex
16:53:35  <planetmaker> Python 2.6.5
16:53:44  <Yexo> that part _is_ documented :p
16:53:47  <Hirundo> planetmaker: you need ply:
16:53:49  <Yexo>  you need to install ply
16:54:16  <planetmaker> :-)
16:56:20  <planetmaker> nice. and now macports installs as dependency sqlite3...
16:58:20  <planetmaker> <-- that's ok?
16:58:32  <Yexo> yep
16:58:41  * Yexo adds randomaction2 to the todo list
16:59:16  <planetmaker> hm. I got no NFO file
16:59:43  <Yexo> what happens if you run it again?
17:00:06  <Yexo> the warnings from ply only display the first time
17:00:07  <planetmaker> ' at line 1racter '
17:00:15  <planetmaker> yup, those are gone
17:00:57  <Yexo> hmm, could be the line endings
17:01:35  <Yexo> yep
17:01:57  <planetmaker> yes
17:02:08  <Yexo> macs use "\r" as line ending by default, python doesn't interpret that \r as newline
17:02:17  <planetmaker> they don't
17:02:28  <planetmaker> the \r is out-phased for years
17:02:40  <Hirundo> We might want to add a table of constants to eliminate magic numbers, e.g. RUNNING_COST_STEAM = 0x4C30
17:02:50  <Yexo> Illegal character '%s' at line %d <- that is the error message it should print
17:03:04  <planetmaker> I just downloaded what you pasted
17:03:05  <Yexo> the %s is replaced the by illegal character
17:03:14  <planetmaker> as file download
17:03:23  <Yexo> you can see the racter in your output, that's the end of "illegal character"
17:03:41  <PeterT> Ammler: how do you view channels outside of the top bar with qwebirc?
17:03:53  <Yexo> Hirundo: indeed, adding that to the todo list
17:05:10  <planetmaker> Yexo: actually the files you pasted were windows style.
17:05:18  <planetmaker> so it chokes on windows style line endings
17:05:22  <planetmaker> the \r\n
17:05:28  <Yexo> it doesn't for me
17:05:42  <planetmaker> well. If I run unix2dos on it here it fails
17:05:54  <Yexo> you need dos2unix to make it \n endings
17:05:55  <planetmaker> if I run dos2unix on it it works
17:05:56  <Yexo> does it work then?
17:05:58  <Yexo> ah, ok
17:06:14  <Hirundo> is \r on the list of ignored characters?
17:06:32  <Yexo> nope
17:07:14  <Yexo> planetmaker: can you pull, then try with windows line endings agani?
17:07:25  <planetmaker> sure
17:08:24  <planetmaker> Yexo: all fine now
17:08:28  <Yexo> good :)
17:08:30  <Yexo> thanks
17:08:36  <planetmaker> thank you :-)
17:12:28  <Ammler> [19:03] <PeterT> Ammler: how do you view channels outside of the top bar with qwebirc? <-- don't join thousands channels :-P
17:13:57  <PeterT> Ammler: that's not a solution, that's an excuse
17:16:29  <Hirundo> <- off for today
17:16:38  <PeterT> Bye bye Hirundo
17:16:40  <planetmaker> enjoy, Hirundo
17:26:38  <Webster> Latest update from devactivity: NFO Meta Language - Revision 83: Fix: add '\r' to the list of ignored characters <>
17:48:59  <andythenorth> evening
17:51:15  <planetmaker> hi andythenorth
17:55:22  *** frosch123 has joined #openttdcoop.devzone
18:13:01  *** ODM has quit IRC
18:40:29  <Yexo> road vehicle prop 08 uses mph*3.2 as unit, prop 15 uses mph*0.8 as unit
18:40:40  <Yexo> what would be the best unit to have as default in nml?
18:40:43  <Yexo> andythenorth: ^^?
18:41:31  <andythenorth> I don't know, I always set both
18:41:46  <andythenorth> ask Terkhen in #openttd
18:42:14  <Yexo> terkhen doesn't write any newgrfs as far as I'm aware
18:44:53  <Webster> Latest update from devactivity: NFO Meta Language - Revision 85: Feature: implement storing/loading in tmp/persistant storage <> || NFO Meta Language - Revision 84: Fix: reduce_expr set the var.param to var.num <>
18:45:16  <Ammler> Hmm, maybe someone should tell tell the Swedish guys that ikea owner is located in the Netherlands and the founder in Switzerland. :-)
18:46:07  <Ammler> terken made a tf mod
18:47:40  <Rubidium> Ammler: cool, didn't know that
18:47:52  <Rubidium> guess we Dutch "own" half of Sweden then
18:48:07  <Rubidium> Ikea + Saab... what else is there?
18:48:42  <frosch123> [20:40] <Yexo> what would be the best unit to have as default in nml? <- is nml able to detect usage of callback 36, so it can handle the unit conversion also there? and also in computatons?
18:48:59  <Yexo> frosch123: no
18:49:03  *** ODM has joined #openttdcoop.devzone
18:49:42  <frosch123> then it might be easier to not do any unit conversion in the property either, so it stays somewhat consistent
18:50:04  <Yexo> what is the default unit for cb 36? can it change?
18:50:18  <frosch123> it is just the same as the property
18:50:29  <frosch123> i.e. also different for all vehicle types
18:50:36  *** Seberoth has quit IRC
18:51:04  <Yexo> neither prop 08 nor prop 15 is supported by cb 36
18:51:26  <Ammler> Rubidium: I knew the founder lifes here but just saw that ikea foundation is located in holland :-
18:52:07  <frosch123> oh, then i missed the topic. i thought you would abstract all speed properties to km/h or so :o
18:52:30  <Yexo> not at all :)
18:52:42  <Yexo> I just don't want to define "speed for road vehicles" twice
18:52:52  <frosch123> yeah, now i get the point :)
18:52:59  <Yexo> I just want a single value for "speed" and then set both 08 and 15 depending on that value
18:53:16  *** Seberoth has joined #openttdcoop.devzone
18:53:56  <frosch123> maybe that is the reason why only rv have no speed control via cb36 :p
18:54:00  <Yexo> so the choice is between 3.2*mph or 0.8*mph as unit
18:55:38  <frosch123> the best choice would be to pick the same unit as cb36 would use, as it is very unlikely that cb36 would be implemented for both properties. and assuming cb36 can handle 15bit results, 0.8*mph sounds more useful
18:56:17  <frosch123> err. the other way around :) 3.2*mph
18:56:46  <Yexo> ok, that one it is then
18:56:48  <frosch123> the one with finer resolution
18:59:24  <Rubidium> support 26.5 km/h-ish
18:59:44  <andythenorth> I suggested Terkhen as he is pretty familiar with RV code.  IIRC he was looking at the cbs (and may have slightly abandoned part of it)
19:00:05  <andythenorth> from a newgrf point of view I would rather have one value which is the real value :)
19:01:33  <Rubidium> i.e. don't call it km/h, but do not make it .8mph either. Just use the unit as-is and describe in the (donot)readme that it's mph/1.6 or km/h*1.0something
19:07:46  <Yexo> the wiki says "Speed in mph*3.2", but I think it's actually mph/3.2
19:08:52  <Yexo> if so, that would be the best choice as it has the highest resolution
19:09:37  <Rubidium> well, the value would be "speed in mph" * 3.2
19:09:53  <Rubidium> the unit is then "mph/3.2"
19:10:02  <Yexo> ah, yes ;)
19:54:35  <planetmaker> hm.... an abstraction to km/h could be added later, I guess
19:55:22  <Yexo> it's very easy to add, questions is, do we want to add that?
19:55:55  <planetmaker> well... personally I'd like that. Possibly in a way that it rounds to the nearest acceptable value.
19:56:11  <frosch123> how about adding some "KM_H_RV" constant which evaluates to "* 2"
19:56:24  <planetmaker> the usage of these mph/3.2 units is... not quite intuitive to me :-)
19:56:29  <frosch123> s/* //
19:57:12  <frosch123> then you could write 2 * KM_H_RV and you would get 4, and you might also use it in callback 36
19:57:56  <planetmaker> ah. You mean to define KM_H_RV as the multiplicator between the GRF-unit and km/h? Sounds fine to me.
19:58:15  <planetmaker> it would just need a rounding at some stage so that one could possibly also enter 0.5 ;-)
20:14:17  *** Doorslammer has joined #openttdcoop.devzone
20:19:15  <Webster> Latest update from devactivity: NFO Meta Language - Revision 86: Feature: support for all road vehicle properties <>
21:16:09  *** Seberoth has quit IRC
21:28:09  *** welshdragon is now known as Guest228
21:29:05  *** Doorslammer has quit IRC
21:29:08  *** Doorslammer has joined #openttdcoop.devzone
21:33:23  *** Guest228 is now known as welshdragon
22:11:54  *** ODM has quit IRC
22:18:00  *** frosch123 has quit IRC
22:40:21  *** GT has joined #openttdcoop.devzone
22:56:11  <Webster> Latest update from devactivity: #openttdcoop Client Patch Pack - Revision 765: Add: client patch pack for 1.0.0 <> || #openttdcoop Client Patch Pack - Revision 764: Add: station_gui for 1.0 (5.1 r19159) <> || #openttdcoop Client Patch Pack - Revision 763: Update: filter_sign_list to v35 (r19523) <> || #openttdcoop Client Patch Pack - Revision 762: Add: watch_gui for 1.0 <> || #openttdcoop Client Patch Pack - Revision 761: Update station_build_gui to 6.2 (r19525) <>
23:00:51  *** Doorslammer has quit IRC
23:00:55  *** Doorslammer has joined #openttdcoop.devzone
23:26:08  *** Seberoth has joined #openttdcoop.devzone
23:26:47  <GT> If anyone's still around, fyi, Ive created a patch queue with the history of the 32bpp-ez patch in the 32bpp-ez-patches repo, and also a subproject of 32-ez for it (actually, currently it is a main project, but I dont have rights to change it to a subproject of 32bpp-ez)
23:26:47  <Webster> Latest update from devactivity: 32bpp-EZ - Support #874: Create repository <>
23:31:14  <Ammler> GT, I will
23:31:28  <Ammler> Hirundo: should also post his workflow
23:33:26  <Ammler> moved
23:40:29  <GT> Thanks, I think the main repo also needs to be dumped and cloned from trunk again, I've tried every possible trick to repair it, but there's no way in hg to undo previous changesets.
23:40:48  <Yexo> GT: 32bpp-ez-patches doesn't contain a patch queue, it's just a repository with patch history
23:41:10  <Yexo> a patch queue is a series of patches that need to be applied on top of eachother
23:43:54  <GT> Nontheless, it's a patch queue of size one, clone it to 32bpp-ez/.hg/patches and it'll work
23:44:27  <GT> Unless I missed a way of creating a patch q
23:45:08  <Yexo> ah, right
23:45:19  <Yexo> a patch queue of length 1 is indeed possible
23:45:33  <Ammler> he will split later...
23:45:37  <Ammler> :-)
23:46:14  <GT> I'm thinking of splitting it up indeed, but for starters, I wanted to reflect the patch history
23:47:31  <Ammler> yes, that is ice
23:47:34  <Ammler> nice*
23:49:17  <GT> Btw, I did get a little disgusted with hg, it seems there is no way to undo a change in the file log. For example, if I change a file, undo that change in the next commit, I'll have to merge forever, even when there's no change in the code anymore
23:49:49  <Yexo> you have to merge because the history of your repo differs from the repo you pull from
23:50:01  <Yexo> you can use hg strip to remove changesets from your repo completely
23:50:24  <GT> Only local, not when you've pushed the mess
23:50:25  <Yexo> but hg strip will remove a changeset and also all child-changesets!
23:50:29  <Ammler> but that doesn't work if you pushed it already
23:50:36  <Yexo> yes, but that's intended
23:50:53  <Yexo> if you could modify a pushed repo then everyone who already pulled from that has the problem he has to merge
23:53:05  <GT> Correct, but the problem with the 32bpp-ez repo is that I used an svn-checkout to push the first version, afterwards I pullled a trunk hg repo, and they will never get merged again.
23:53:26  <Yexo> that's indeed a problem
23:53:49  <Ammler> did you try to stip the svn trunk?
23:53:49  <Yexo> on the other hand, if you plan on having your patch in there you'll have to merge everything anyway
23:54:05  <Yexo> Ammler: you can't strip a remote repo
23:54:25  <GT> Yes, but only the files I've changed for the patch, not the complete codeset
23:54:32  <Yexo> besides, if that was his initial commit then stripping it would remove everything from the repo
23:54:32  <Ammler> I meant from his local repo
23:54:50  <Ammler> hmm
23:55:10  <Yexo> easiest solution is to just start over with a clean trunk hg checkout
23:55:18  <Yexo> then apply the patch you have
23:55:35  <Yexo> but then maintaining both a patch queue and a hg repo is double work
23:55:36  <GT> right, check the request I made on the project page
23:55:56  <Yexo> it'd be a lot easier to chose either of the two and go with that
23:57:01  <Ammler> GT, I moved the repo to 32bpp-ez.bak
23:57:02  <GT> Yexo: it is not really a lot of work, ie just qpush the patch and push it to the main repo
23:57:16  <Ammler> and initialized a empty 32bpp-ez repo
23:57:34  <Yexo> GT: you can't just push the patch from the patchqueue to the main repo as it already has an older version of the patch
23:58:10  <Ammler> Yexo: I would do it like Hirundo with IS2
23:58:23  <Ammler> he has a script which does merge
23:58:40  <GT> Yexo, my flow would be, qpop, pull, qpush, merge and push
23:58:41  <Ammler> we need the merged repo for the compile farm
23:58:50  <Rubidium> getting the workflow flowing is always the hardest work :)

Powered by YARRSTE version: svn-trunk