Log for #openttdcoop.devzone on 24th October 2010:
Times are UTC Toggle Colours
00:05:27  *** KenjiE20 has quit IRC
00:09:58  <Lakie> ... yeah, of course push/pull is syncroizing and then you have to do update/commit seperate on this. :<
00:38:37  *** Lakie has quit IRC
01:16:19  *** Levi has joined #openttdcoop.devzone
01:20:30  *** thgergo has quit IRC
02:23:37  *** Levi has quit IRC
06:28:16  *** andythenorth_ has joined #openttdcoop.devzone
06:43:33  <Brot6> GRFCodec - Revision 785:b772b3b8f4f8: Fix: erroneous space in the makefile causing failure to com... (Rubidium) @
06:48:15  <Rubidium> morning andythenorth_!
06:48:22  <andythenorth_> hi
06:49:08  <Rubidium> already seen the nice grfcodec feature Lakie pushed last night?
06:49:22  <andythenorth_> no yet :o
06:51:21  <andythenorth_> png :)
06:52:04  * andythenorth_ will have to change some photoshop workflow :)
07:00:00  <Rubidium> you'll have to cook a new grfcodec first :)
07:06:02  <andythenorth_> done that
07:06:18  <andythenorth_> is there a spec for the png files?
07:06:24  <andythenorth_> I guess 8 bit, no transparency...
07:06:59  <Rubidium> paletted 8 bit
07:07:08  <Rubidium> same palette as the pcx files
07:14:32  <andythenorth_> now all of the path names will be wrong in FIRS / HEQS / FISH :D
07:14:39  <andythenorth_> they all use a 'pcx' directory
07:23:55  <Rubidium> so add a png directory and slowly migrate
07:24:10  <Rubidium> you can use both pcx and png in the same nfo
07:34:46  <andythenorth_> better to rename the path to something which doesn't imply a file format
07:35:57  <andythenorth_> real sprites?
07:36:04  * andythenorth_ ponders
07:36:30  <andythenorth_> 'graphics'
07:36:52  <Rubidium> ssf :)
07:38:53  <Brot6> HEQS "Heavy Equipment" Set - Revision 459:a478b8dd672b: Change: various documentation and other... (andythenorth) @
07:42:25  <Brot6> HEQS "Heavy Equipment" Set - Revision 460:4df5ef581314: Change: rename 'pcx' directory to 'grap... (andythenorth) @
07:51:17  <andythenorth_> "Unrecognized palette, aborting."
07:51:23  * andythenorth_ has some learning to do
07:52:03  <Rubidium> intel or ppc?
07:52:38  <Rubidium> <- does that compile for you?
07:53:41  <andythenorth_> let me see
07:54:35  <andythenorth_> Rubidium: yes
07:54:40  <andythenorth_> compiled fine
07:55:32  <Rubidium> okay, so you palette is incorrect/not the one (of quite a few) grfcodec expects
07:55:43  <andythenorth_> seems so
07:55:49  <andythenorth_> I'm trying to figure that out
07:58:09  <andythenorth_> hmm
07:58:19  <andythenorth_> I have limited options for this in photoshop
07:58:27  <andythenorth_> there's no magic 'make it work' button :P
07:58:58  <Rubidium> take one of my pngs, copy resize, copy graphics over, save?
07:59:06  <andythenorth_> let me test that
08:00:55  <andythenorth_> Rubidium: I saved the colour table from one of your pngs
08:00:58  <andythenorth_> that seemed to work
08:02:02  <andythenorth_> Rubidium is opengfx windows or dos palette?
08:02:12  <andythenorth_> (before I do something bad)
08:04:46  <Terkhen> andythenorth_: for opengfx-rv pngs (nml) I'm saving them with GIMP as indexed PNGs using the first palette here:
08:04:47  <Rubidium> AFAIK Windows paletted
08:05:02  <Terkhen> I don't know if it is correct with grfcodec too
08:05:09  <andythenorth_> Rubidium: thanks
08:06:08  <andythenorth_> so is it possibly just the order of the palette grfcodec is stumbling on?
08:06:53  <andythenorth_> andy_palette = rubidium_palette.reverse()
08:07:21  <Rubidium> well, I wonder why the pcx version works for you
08:07:29  <Rubidium> (assuming that at least)
08:07:41  <Rubidium> as as far as I know that is doing the same check
08:08:08  <andythenorth_> it's a puzzle :)
08:08:34  <andythenorth_> does pcx ignore the order?  or possibly when photoshop converts to pcx it re-orders
08:09:34  <andythenorth_> ach
08:09:38  <Rubidium> the pcx and png code use the exact same snippet to determine whether the palette is correct
08:09:49  <andythenorth_> I should just switch which palette I'm loading into photoshop
08:10:01  <andythenorth_> it's going to be the fastest result
08:10:04  <andythenorth_> for me
08:10:14  <andythenorth_> and no work for the rest of you ;)
08:15:20  <Brot6> HEQS "Heavy Equipment" Set - Revision 461:3a9ea5928255: Change: changed palette used for export... (andythenorth) @
08:19:50  *** Alberth has joined #openttdcoop.devzone
08:20:46  <planetmaker> good morning
08:20:55  <Alberth> good morning
08:21:30  <planetmaker> Rubidium: reading backlog: do you have a fully pcx->png converted version of OpenGFX?
08:21:31  <Alberth> judging by the amount of sun, that will quite likely succeed :)
08:21:40  <planetmaker> :-)
08:22:03  <Rubidium> planetmaker: hai
08:22:08  <planetmaker> we have all, sun and clounds and strong gusty winds here
08:22:15  <Rubidium> morning Alberth
08:22:59  <planetmaker> Rubidium: care to commit?
08:23:33  <planetmaker> png is so much nicer to treat :-)
08:24:01  <Rubidium> planetmaker: fine, though... it needs really leet grfcodec
08:24:14  <planetmaker> this night or next?
08:24:30  <Rubidium> and the next release is somewhat scheduled for ~1 week before Christmas
08:24:54  <planetmaker> well. That should do it
08:25:15  <planetmaker> Maybe you can make that 1 week earlier ;-)
08:25:19  <Rubidium> planetmaker: yes (both this night and next night, depending on the compile farm)
08:25:46  <planetmaker> but whatever, any packager will not want to try to ship it immediately, I guess
08:26:02  <planetmaker> Do you have a conversion script?
08:26:40  <Rubidium> find . -iname *.[tp]nfo | xargs sed s/pcx/png/g -i
08:26:49  <Rubidium> and irfanview batch conversion of the pcxes to png
08:26:53  <Rubidium> but I'll commit and push it
08:27:47  <planetmaker> k :-)
08:28:09  <Rubidium> massive upload :(
08:29:14  <planetmaker> yeah, it'll make the repo not smaller
08:29:34  <Rubidium> there
08:29:45  <planetmaker> thanks :-)
08:30:37  <Brot6> OpenGFX - Revision 551:de2a2166f5e7: Change: convert from pcx to png sprites. This will need GRFC... (Rubidium) @
08:32:44  <Rubidium> oh, make clean/mrproper doesn't remove sprites/*.bak
08:34:25  <planetmaker> hm, bad.
08:34:46  <planetmaker> I should look at the makefile(s) at some stage anyway again. They have a few not so nice glitches
08:45:49  * andythenorth_ wonders if nml could automate combining length adjust + vehicle offsets
08:46:02  <andythenorth_> based on a standard template which would be specified as part of the project
08:49:37  <Ammler> omg, what a commit (r551)
08:51:33  <planetmaker> :-)
08:51:37  <planetmaker> moin Ammler
08:52:32  <Ammler> good morning
09:03:11  <Brot6> OpenGFX - Bug #1707 (Closed): growth (or decay) stages of cone tree mis-aligned (planetmaker) @
09:03:11  <Brot6> OpenGFX - Revision 552:d5d19a1f3a29: Fix #1707: Alignment of inverse cone tree (planetmaker) @
09:03:11  <Brot6> OpenGFX - Bug #1707 (Closed): growth (or decay) stages of cone tree mis-aligned (planetmaker) @
09:03:38  <andythenorth_> a build in sprite magnifier is tmwftlb yes?
09:03:43  <andythenorth_> build / built /s
09:03:56  <planetmaker> andy why?
09:04:05  <planetmaker> fn+ctrl+scroll
09:05:04  <Brot6> OpenGFX - Revision 553:aeec343b4283: Fix: Some more toyland tree alignments and their documentation (planetmaker) @
09:05:08  <planetmaker> maybe a non-laptop doesn't have fn. But you'll surely have a screen magnifying glass there, too
09:05:17  <andythenorth_> I'm using pixie
09:05:26  <andythenorth_> it works, it's just a faff
09:05:34  <andythenorth_> but seriously, tmwftlb
09:05:37  <planetmaker> it's mac in-built function
09:06:02  <andythenorth_> pixie is better - it doesn't interpolate / degrade / whatever
09:06:06  <andythenorth_> it's in dev tools
09:06:20  <planetmaker> but doesn't work on a running game ;-)
09:07:23  <andythenorth_> depends how much cpu you're prepared to lose to it ;)
09:07:58  <planetmaker> well. Normally that's sufficient for me. For pixel-zoom I use gimp
09:10:37  <Brot6> HEQS "Heavy Equipment" Set - Revision 462:122ce7daf9f2: Change: finished rv offsets for pikka t... (andythenorth) @
09:21:27  <Brot6> HEQS "Heavy Equipment" Set - Revision 463:09489e0d6cf9: Change: finished rv offsets for pikka t... (andythenorth) @
09:33:00  <Brot6> HEQS "Heavy Equipment" Set - Revision 464:f7543c5b087e: Change: finished rv offsets for pikka t... (andythenorth) @
09:51:18  <Brot6> HEQS "Heavy Equipment" Set - Revision 465:868ade90daf9: Change: finished rv offsets for pikka t... (andythenorth) @
10:02:20  <Brot6> HEQS "Heavy Equipment" Set - Revision 466:354f1ba654cf: Change: finished rv offsets for pikka t... (andythenorth) @
10:11:20  <Brot6> Backup heqs: abort: no suitable response from remote hg!
10:11:32  <Brot6> Backup opengfx: abort: no suitable response from remote hg!
10:12:58  <planetmaker> hm
10:19:43  *** frosch123 has joined #openttdcoop.devzone
10:21:31  <Brot6> HEQS "Heavy Equipment" Set - Revision 467:cc2d60c6d82d: Change: finished rv offsets for pikka t... (andythenorth) @
10:24:00  <Brot6> HEQS "Heavy Equipment" Set - Revision 468:dcaf553b3130: Change: tweak to offsets (andythenorth) @
10:25:28  *** thgergo has joined #openttdcoop.devzone
10:28:20  <Brot6> HEQS "Heavy Equipment" Set - Feature #1124: Setup RV offsets for Pikka templates (andythenorth) @
10:36:01  *** KenjiE20 has joined #openttdcoop.devzone
11:28:21  <andythenorth_> looks like I planned more colours for HEQS trams
11:28:29  <andythenorth_> code is there but graphics are unchanged
11:28:35  <andythenorth_> wonder what I was planning :P
11:29:12  <Brot6> 2cc train set - Feature #1721 (New): Chicago L Northwest Elevated 1907 stock (Purno) @
11:30:12  <Alberth> andythenorth_: orders look quite hooked in other data structures
11:30:37  <Alberth> not easy to set them free :)
11:30:40  <andythenorth_> I tried to understand them, but it looks to be a major section of game code :P
11:30:48  <andythenorth_> what else are they tied into?
11:32:07  <Brot6> 2cc train set - Feature #1710: OS T1000 (Purno) @
11:32:22  <Alberth> shared orders, backupped orders (used for upgrading engines)
11:34:35  <andythenorth_> that they are tied to shared orders is....good no?
11:37:19  *** ODM has joined #openttdcoop.devzone
11:43:18  <Alberth> depends on how shared orders are handled
11:44:06  <Alberth> in my book, they will become obsolete, eventually
11:47:14  <Brot6> 2cc train set - Bug #1722 (New): Depot sprites misallignment (Purno) @
11:49:12  <Brot6> 2cc train set - Bug #1723 (New): MAV Class M44 - Action colors in depot sprite flag (Purno) @
11:49:16  <andythenorth_> Alberth: do shared orders become obsolete, or do all orders become shared orders?
11:50:02  <planetmaker> andythenorth_: there should be no difference
11:50:12  <planetmaker> just a matter of n(vehicles) == 1 or > 1
11:50:20  <planetmaker> (like now actually)
11:50:24  <Alberth> hopefully not the latter, as then you can have only one set of orders :p
11:50:31  <andythenorth_> planetmaker but if we speak of the difference between implementation and concept...
11:50:43  <andythenorth_> ....there is probably an implementation difference?
11:51:06  <planetmaker> IIRC it's done by pointing the vehicle to a set of orders
11:51:10  <planetmaker> so it doesn't matter
11:51:26  <Alberth> the question is how to change orders
11:51:56  <Alberth> ie I have 5 vehicles, all with the same order, and 2 needs to go elsewhere
11:52:29  <planetmaker> I un-share the orders and re-define them
11:52:39  <planetmaker> then I can assign another vehicle to that set, too
11:52:40  <andythenorth_> change the pointer to the set of master orders for those 2 vehicles
11:53:30  <Alberth> enter at the console "v1->order = &new_orders;"    :)
11:53:47  <Alberth> but in terms of a group-change?
11:54:03  <Alberth> do you define a new group first, and move the vehicles?
11:54:32  <Alberth> do you split the group in 2, and then change the orders of one sub-sgroup?
11:54:38  <planetmaker> dunno which concept you want to follow :-)
11:54:53  <Alberth> nobody does :)
11:54:56  <andythenorth_> Alberth: if you only have two, find each vehicle
11:55:04  <andythenorth_> if you have more than two, create a new group
11:55:16  <andythenorth_> 'if you do it more than twice, automate it' :P
11:55:34  <planetmaker> there's IMHO two fundamental approaches: lines as brianetta wants --> order based. Or andy's more freely-assignable groups where vehicles can be part of any number of groups
11:55:49  <andythenorth_> brianetta conflates lines and orders
11:55:56  <andythenorth_> he argued it out a lot and had a lot of good points
11:56:04  <andythenorth_> but they all lead to an upgrade of current shared orders
11:56:06  <planetmaker> in all cases though it might make sense to allow defining a set of orders and then assign vehicles to it
11:56:11  <andythenorth_> yes
11:56:22  <andythenorth_> which eddi said is roughly how shared orders work already
11:56:33  <andythenorth_> Alberth: is there an actual pool of shared orders?
11:56:38  <planetmaker> while allowing from the vehicle orders to just create such set (as now)
11:58:26  <Alberth> andythenorth_: no, 'order' (ie one line), order-list, and 'backupped-orders'
11:58:49  <Alberth> and order-lists support sharedness
11:59:17  <andythenorth_> order-lists sounds useful
11:59:19  <planetmaker> Alberth: sounds complicated. Just a list of different order sets would be nice already
11:59:44  <andythenorth_> I was thinking a GUI patch to make order lists visible.  Is that possible?
11:59:44  <planetmaker> whether vehicles are assigned or not is not relevant really for that list. But useful information, of course
11:59:49  <andythenorth_> just for prototyping...
11:59:55  <planetmaker> should be, andythenorth_
12:00:06  <andythenorth_> I think we test :)
12:00:07  <Alberth> backupped orders are just tricky, but they exist as you need to preserve orders while changing engines
12:00:18  <andythenorth_> assume there's a fix and ignore it for now :)
12:00:26  <andythenorth_> we might be entirely wrong about this being a good idea anyway
12:00:34  <planetmaker> Alberth: but that's nothing to expose to the user, is it?
12:01:13  <Alberth> everthing is internal, except for the existing guis
12:01:59  <Alberth> ie the order gui
12:02:34  <Alberth> andythenorth_: good idea, a gui patch should be doable
12:02:50  <andythenorth_> that way we see what hasn't been thought about :)
12:03:31  <andythenorth_> planetmaker: how many order-sets might a big coop game have?
12:03:46  <Alberth> some value close to 'everything'  :)
12:04:01  <planetmaker> andythenorth_: really depends.
12:04:05  <planetmaker> A few hundret
12:04:07  <Alberth> andythenorth_: equal to the number of trains?
12:04:18  <planetmaker> every primary industry one plus a few secondary
12:04:22  * andythenorth_ is secretly scared that order-sets might be an unmanageable concept
12:04:32  <planetmaker> so, what Alberth says: 3000 at worst ;-)
12:04:36  <andythenorth_> I play small games, and might have 500 vehicles
12:04:43  <andythenorth_> with maybe 200 order sets
12:04:53  <andythenorth_> so maybe 50 per vehicle type
12:04:55  <Alberth> mine usually end with less than 200 trains :)
12:05:01  <planetmaker> well. coop doesn't have 3000. But a few hundret easily
12:05:16  <andythenorth_> it's potentially a long list :)
12:05:20  <planetmaker> yes
12:05:26  <planetmaker> might need more sorting ;-)
12:05:42  <andythenorth_> filter
12:06:04  <andythenorth_> one thing to say - I am thinking order-sets list available from multiple places....stations, waypoints, depots etc
12:06:21  <andythenorth_> same as existing button to show vehicles using a station, waypoint, depot etc
12:59:12  *** Lakie has joined #openttdcoop.devzone
13:06:46  <Brot6> 2cc train set - Bug #1724 (New): Some chsnges in USSR engines. (simozzz_AK) @
13:11:55  *** Levi has joined #openttdcoop.devzone
13:19:13  *** Lakie` has joined #openttdcoop.devzone
13:24:55  *** Lakie has quit IRC
13:25:01  *** Lakie` is now known as Lakie
13:33:57  *** Lakie` has joined #openttdcoop.devzone
13:34:35  *** Lakie` has quit IRC
13:39:55  *** Lakie has quit IRC
13:47:04  <Brot6> xUSSR Set - Feature #788 (Closed): ТЭП70 / TEP70 (simozzz_AK) @
14:07:24  *** Lakie has joined #openttdcoop.devzone
14:08:06  *** Lakie has left #openttdcoop.devzone
14:10:31  *** Lakie has joined #openttdcoop.devzone
14:14:21  <Brot6> HEQS "Heavy Equipment" Set - Revision 469:f21a9c0a44f6: Change: mining trailer 1 uses cpp real ... (andythenorth) @
14:21:29  <Brot6> HEQS "Heavy Equipment" Set - Revision 470:a1e61445ddff: Fix: mining trailer 1 y pos values were... (andythenorth) @
14:25:53  <Brot6> HEQS "Heavy Equipment" Set - Revision 471:8c9f4c178c95: Change: mining truck trailer 2 uses CPP... (andythenorth) @
14:27:27  * Lakie wonders how many grf projects will migrate from pcx to png
14:27:32  <Brot6> HEQS "Heavy Equipment" Set - Feature #1715 (Closed): Convert articulated mining trucks to CPP r... (andythenorth) @
14:27:52  <andythenorth_> Lakie: I can name 3 that will use a mix
14:28:09  <Lakie> All yours?
14:28:12  <andythenorth_> yup
14:28:17  <Lakie> FIRS, HEQS and...
14:28:18  <andythenorth_> png for all new items
14:28:20  <andythenorth_> FISH
14:28:50  <Lakie> Ah, ok, makes sense, since replacing the old ones doesn't really help as they are all versioned previously. :/
14:33:10  <Lakie> Originally I was wondering how long it'd be before people notice, but then I noticed it'd been mentioned on the forums...
14:39:58  <andythenorth_> :)
14:42:05  <Brot6> HEQS "Heavy Equipment" Set - Feature #1720: Fix offsets for mining trucks (andythenorth) @
14:44:14  <Brot6> HEQS "Heavy Equipment" Set - Feature #1124 (Closed): Setup RV offsets for Pikka templates (andythenorth) @
14:46:17  <Brot6> HEQS "Heavy Equipment" Set - Feature #1712: Convert crawler trailers to CPP real sprites - as p... (andythenorth) @
14:46:17  <Brot6> HEQS "Heavy Equipment" Set - Feature #1714: Convert standard trailers to CPP real sprites - as ... (andythenorth) @
14:51:09  <andythenorth_> got a HEQS error in game
14:51:10  <andythenorth_>
14:51:19  <andythenorth_> how do I resolve that?
14:53:07  <Rubidium> you need the 'frosch' help line for that, I reckon :)
14:53:43  <planetmaker> andythenorth_: I can guess only: CB 36 results differ from action0 properties.
14:56:49  <frosch123> most likely you have an articulated vehicle and you did not implement the articulated callback for the purchase list
14:58:41  <frosch123> e.g. does the "refittable to" text in the purchase list match the list of actual refittability after purchase?
15:03:47  <andythenorth_> I think refittable is ok
15:03:53  <andythenorth_> probably didn't handle the cb
15:06:21  <andythenorth_> ach, I'm stumped :p
15:07:44  <andythenorth_> frosch123: it is articulated vehicle - trams
15:15:21  <andythenorth_> frosch123: this seems to be isolated to trams
15:16:03  <andythenorth_> it's recently introduced
15:16:08  <andythenorth_> by me
15:17:05  <andythenorth_> I'm 99% certain it relates to how I'm setting capacity in the consist, which I changed recently so I could provide cargo graphics
15:18:32  <frosch123> what are you doing?
15:19:40  <Alberth> hmm, I have a grey window without content, and stdout output "4 orderlists available in the game.". Now I need a compact way to state an order list :)
15:21:17  <Brot6> 2cc train set - Bug #1723: MAV Class M44 - Action colors in depot sprite flag (Voyager1) @
15:21:19  <planetmaker> Alberth: give them a name. If they don't have one, take the first N letters from the stations contained in the orders
15:27:30  <Brot6> OpenGFX - Bug #810: sprite of airport hangar (planetmaker) @
15:28:20  <Brot6> 2cc train set - Bug #1724: Some chsnges in USSR engines. (Voyager1) @
15:46:33  <andythenorth_> frosch123: the trams are complicated
15:46:52  <andythenorth_> vehicles have capacity 0 or n depending on (position in consist + refit subtype)
15:48:42  <frosch123> ah, so you set the capacity using cb 36. then you should make sure to set the property to a non-zero value, even if it is later set using cb35
15:48:55  <frosch123> *36
16:00:12  <Brot6> 2cc train set - Feature #1706: Alstom AGV (Voyager1) @
16:01:30  <Brot6> 2cc train set - Feature #1696: M131 DMU (Voyager1) @
16:01:30  <Brot6> 2cc train set - Feature #1683: Eurostar (Voyager1) @
16:03:42  <Brot6> 2cc train set - Feature #1680: Class 400 DMU (Voyager1) @
16:03:42  <Brot6> 2cc train set - Feature #1674: ALn668 DMU (Voyager1) @
16:03:42  <Brot6> 2cc train set - Feature #1652: TRAXX F140 (Voyager1) @
16:03:42  <Brot6> 2cc train set - Feature #1651: Desiro EMU and DMU (Voyager1) @
16:03:44  <Brot6> 2cc train set - Feature #1651: Desiro EMU and DMU (Voyager1) @
16:05:48  <Brot6> 2cc train set - Feature #1645: CFR 060-DA (Voyager1) @
16:08:29  <Brot6> 2cc train set - Bug #1723: MAV Class M44 - Action colors in depot sprite flag (Purno) @
16:10:39  <Brot6> grfcodec: update from r778 to r785 done -
16:12:27  * Lakie experiements with attempting to rewrite the png header after writing the file
16:12:39  <Brot6> nml: update from r914 to r915 done -
16:12:56  <Lakie> Which seems to work
16:14:08  <Lakie> Idea for those interested is o write a header with an insane length (one which will is unlikely to ever be relike 0x10000), write the image data then replace the header with one with the correct length.
16:15:04  <Lakie> Thus avoidding the cost of buffering and outputing in one block at the end.
16:15:20  <planetmaker> what's wrong with using a buffer?
16:15:21  <frosch123> how do you close the gap after that? or do you want to waste 64k on every png?
16:15:46  <Lakie> Nothing much except it causes grfcodec to pause for a while after it's 'wrote' the data
16:16:01  <andythenorth_> frosch123: do I need to run cb36 on the buy menu chain as well?
16:16:51  <Lakie> Um, the generated file is the same as one outputed from cache, frosch123, what 64K?
16:18:31  <frosch123> Lakie: the header with insane length?
16:18:51  <Lakie> Same size as the new header
16:18:58  <frosch123> andythenorth_: well, basically yes, but you cannot access the chain in the buy menu, so you do not know the position in consist and such
16:19:01  <Lakie> exactly 823 bytes or something
16:19:29  * andythenorth_ hmmms for a bit
16:19:30  <frosch123> Lakie: i guess i did not understand the initial problem then :)
16:19:42  <Brot6> heqs: update from r451 to r471 done -
16:20:00  <andythenorth_> cb36 runs in the trailing vehicles, the lead vehicle has capacity 0
16:20:11  <Brot6> newgrf_makefile: update from r219 to r220 done -
16:20:18  <Lakie> its not so much an issue as me getting annoyed with pause times when it should be done. The idea was literally to just replace the header with the known size when finishing the file
16:20:53  <Lakie> Since grfcodec doesn't know total image height until it finishes writing the file
16:21:48  <frosch123> andythenorth_: well, articulated vehicles in purchase list are generally troublesome as you do not have the chain. though providing position in consist might be possible with some work
16:22:20  <andythenorth_> if I can understand the cause of the error message, I might be able to figure out the fix
16:22:30  <Brot6> opengfx: update from r550 to r553 done -
16:22:52  <frosch123> andythenorth_: do i just need to pull, or is there more local stuff?
16:23:10  <andythenorth_> frosch123: one tiny local difference
16:23:13  <andythenorth_> I'll push
16:23:19  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r635), 32bpp-extra (r39), ai-admiralai (r71), airportsplus (r64), basecosts (r22), belarusiantowns (r7), comic-houses (r71), firs (r1481), fish (r404), frenchtowns (r4), grfcodec (r785), indonesiantowns (r37), manindu (r5), metrotrackset (r56), nml (r915), nutracks (r117), ogfx-trains (r85), ogfx-trees (r41), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r45),
16:23:19  <Brot6> swedishrails (r187), swisstowns (r20), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23)
16:23:44  <andythenorth_> frosch123: done
16:24:43  <Brot6> World Airliners Set - Bug #1725 (New): DevZone compile failed (compiler) @
16:24:43  <Brot6> HEQS "Heavy Equipment" Set - Revision 472:44887c9e33d8: Change: documentation tweak (andythenorth) @
16:25:40  <Lakie> Well, currently it uses the first process, but I actually prefer the second process though its more fiddly.
16:25:40  <Lakie> grfcodec -> filestart() { init libpng } -> encodebytes() { write to cache instead of file } -> filedone() { write header, data from cache finish }.
16:25:40  <Lakie> grfcodec -> filestart() { init libpng, write fake header } -> encodebytes() { write to file } -> filedone() { rewrite header }.
16:25:52  <frosch123> andythenorth_: in the version i pulled it says: ishizuchi, capacity n/a
16:26:48  <frosch123> so either the articualted cb is missing in the purchase list, or all vehicle have capacity 0 wrt. the property
16:28:06  <Rubidium> cool... grfcodec did compile on Ammler's compile farm as well :)
16:28:15  <Lakie> Cool
16:28:50  * Lakie is just padanic, as Rubidium said during testing, people very rarely decode grf files...
16:28:53  <Brot6> indonesiantowns: compile of r37 still failed (#1704) -
16:29:24  <andythenorth_> frosch123: quite right on capacity, that's not present in older versions of HEQS
16:32:48  <Brot6> 2cc train set - Bug #1723: MAV Class M44 - Action colors in depot sprite flag (Voyager1) @
16:33:05  <frosch123> andythenorth_: all vehicles report capacity 0 in purchase list. that's not going to work :)
16:33:15  <Brot6> swisstowns: compile of r20 still failed (#1705) -
16:35:19  <Brot6> worldairlinersset: compile of r666 still failed (#1725) -
16:35:19  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (7 errors), 32bpp-extra (Diffsize: 1), airportsplus, basecosts, belarusiantowns (3 errors) (Diffsize: 21), comic-houses (2 errors) (Diffsize: 14), firs (1 errors) (Diffsize: 872), fish (4 errors), frenchtowns (4 errors) (Diffsize: 9), manindu, metrotrackset (Diffsize: 1), nutracks (2 errors), ogfx-trains (1 errors), ogfx-trees, smts,
16:35:19  <Brot6> snowlinemod, swedishrails, transrapidtrackset (Diffsize: 12), ttrs (7 errors) (Diffsize: 1324)
16:44:20  <frosch123> andythenorth_: the articulated parts return capacity 0 in purchase list
16:44:26  <frosch123> via cb 36
16:44:46  <frosch123> maybe you try to access the chain?
16:49:41  <frosch123> <- andythenorth_: that is what the vehicle looks in purchase list
16:50:17  <frosch123> it gets no capacity (n/a), which causes it to not be refitable (no list of refitable cargos), and which causes the error message
16:54:53  <andythenorth_> frosch123: thanks I'll look some more in a few minutes (right now, baby crying = 1)
16:56:28  <frosch123> i guess i should turn that paste into some debug output
17:10:06  <andythenorth_> frosch123: maybe I need to check consist length during cb36 - if it's 0, then return different value for capacity
17:10:12  <andythenorth_> not sure that will solve it in this case though
17:10:30  <frosch123> better do not check consist length at all in purchase list :)
17:12:13  <andythenorth_> how do I know I'm in the purchase list?  The only method I know is one from DJ Nekkid - check if length is 0....
17:12:32  <frosch123> action3 type ff
17:12:38  <frosch123> is the only proper method
17:13:03  <frosch123> checking length 0 is only luck if it works, and may break in the future
17:14:07  <andythenorth_> hmm
17:14:17  <andythenorth_> there was some reason that FF wasn't being used for articulated vehicles
17:14:22  <andythenorth_> maybe it's legacy
17:14:57  <Alberth>   4 orderlists :)
17:14:57  <andythenorth_> i.e. now a non-issue
17:15:09  <andythenorth_> Alberth: win win
17:15:15  <andythenorth_> is that display-only?
17:15:45  <Terkhen> nice :)
17:15:47  <Alberth> yep, and not scrolling, and not updating the list, and no doubt a few other things also not
17:16:37  <planetmaker> :-D That link graph nearly looks like cargo dist. Or did I miss something?
17:16:44  <Terkhen> never thought about it, but displaying orders in the smallmap seems very useful
17:16:47  <Alberth> it does merge different orderlists that are the same though (ie no difference between shared and non-shared)
17:17:14  <Alberth> planetmaker: those are a few lines I added in post-processing :)
17:17:27  <andythenorth_> Alberth: I don't see a problem with merging shared / non-shared
17:17:37  <Alberth> neither do I :)
17:17:45  <andythenorth_> there will be downsides and upsides to that route, or the alternative
17:17:47  <planetmaker> Terkhen: how would you display them? Like those lines?
17:18:20  <planetmaker> But yes, might make sense. Though I'd only show them when the order-set is highlighted in order to avoid confusion. Or to at least show that in a different colour
17:18:21  <Alberth> orderlists are broken for such a display
17:19:16  <Alberth> since you don't have a 'vv' flag, you need to add orders from one end to the other end, and back, except for the first station
17:19:46  <Terkhen> planetmaker: it's the first time I think about this feature, so I don't have an opinion on which would be the best way
17:20:05  <planetmaker> :-)
17:20:24  <Alberth> cargo dist  draws every connection iirc, it gets very messy
17:20:53  <Alberth> Terkhen: not sure how useful it is, orders are usual where the tracks are :)
17:21:26  <andythenorth_> not for planes :P
17:21:33  <planetmaker> well. As such a switch like 'all' vs. 'this' ;-)
17:21:38  <andythenorth_> and ships are completely unpredictable :)
17:21:40  <Terkhen> yes... but it can help while checking a big network with trains following many paths, or with ships and airplanes
17:22:00  <Terkhen> IMO it does not make much sense to show more than a single conection at once
17:22:06  <andythenorth_> more useful, show the link graph from a station
17:22:21  * planetmaker tries to figure out how to build a 10.u-SDK univeral library
17:22:46  * andythenorth_ tries to figure out how to fix trams :P
17:23:13  <Alberth> for a while I thought you meant a 10u rack system, which is very high :)
17:23:28  <planetmaker> and the first google hit is my wiki entry on the OpenTTD wiki -.-
17:23:49  <planetmaker> damn, not *that* universal
17:23:57  <Alberth> well, at least you will be able to find your own text :)
17:25:48  <michi_cc> planetmaker: When I last compiled an OSX lib using the cross-compiler (was it liblzo or icu? Don't remember exactly anymore), I compiled all four archs separately with the appropriate SDK and lipo'ed them together in the end.
17:26:10  <planetmaker> sounds annoying
17:26:30  <planetmaker> sounds like the task for a script
17:27:02  <welshdragon> look out
17:27:07  <welshdragon> incoming Purno
17:27:07  *** Purno has joined #openttdcoop.devzone
17:27:19  <welshdragon> ;)
17:27:22  <Purno> Heya :P
17:27:24  <michi_cc> planetmaker: Well, 10.4u won't work for 64-bit, so that needs 10.5 if you want a four arch lib.
17:27:56  <planetmaker> michi_cc: I've all four SDKs, so it won't fail there, but yes. it needs PPC, i386 and x64, I guess
17:28:12  <planetmaker> remind me, what was the 4th architecture?
17:28:17  <Purno> Any of you familiar with the wiki feature of the devzone? :)
17:28:39  <planetmaker> Purno: I guess somewhat. What's the issue? (no meta questions please)
17:28:42  <michi_cc> Script depends very much on the library, icu is a bitch to cross-compile because it runs some compiled utilities during build (which didn't really work the first try)
17:28:55  <michi_cc> planetmaker: ppc64
17:28:57  <Alberth> planetmaker: you played   twice?
17:28:59  <planetmaker> aye
17:29:37  <Purno> Well, I've been trying to add a table to the 2ccSet projects wiki page, but when I copy the code from wikipedia, it doesn't work.
17:29:38  <planetmaker> why do you think so, Alberth ?
17:29:40  <michi_cc> planetmaker: The different SDKs just mean that you can't just use -arch i386 -arch x86_64 etc if you want 10.4 as base
17:29:58  <Purno> And the devzone's wiki help page doesn't mention anything about tables, which makes me think it's not a supported feature :P
17:29:59  <Alberth> planetmaker: your name is listed twice
17:30:12  <planetmaker> Purno: might be. I never tried that
17:30:34  <planetmaker> oh @ Alberth :-) - must be multiple personality disorder
17:30:36  <michi_cc> And of course using multiple -arch options is incomatible with gcc dependency generation which some makefiles depend on.
17:30:46  <planetmaker> nice
17:30:53  <Purno> Hmm... anyone else who'd know how to make a table on the devzone's wiki?
17:32:09  <planetmaker> ok, so doing it piecewise. As the macports universal is only i386 and x64
17:35:13  <Alberth> Purno: doesn't seem possible at first sight, perhaps a code block and white space?
17:36:11  <Purno> a code block and white space? what's that? sorry I'm totally new to wikiing :P
17:36:15  <Alberth> but that is not really nice
17:36:40  <Purno> oh I think I know what you mean :)
17:36:43  <andythenorth_> wikis are stupid
17:36:59  <andythenorth_> I refuse wiki editing
17:36:59  <Purno> but they're easy to use :P
17:37:05  <andythenorth_> yeah definitely
17:37:06  <Alberth> in particular the RM wiki imho
17:37:20  <andythenorth_> they're not like a really dumb broken abstraction of html
17:37:34  <andythenorth_> want to write html?  Write html :P
17:37:48  <Purno> well, I wanted to make a sortable table. Would you have an alterative for me where I can make one?
17:38:42  <Alberth> you can link repository files I think. You could make documentation, and link that at the wiki
17:38:43  <andythenorth_> honestly and usefully no
17:38:55  <andythenorth_> I would write a table and put js tablesort on it
17:39:36  <Alberth> we do that with the NML reference manual
17:39:39  <andythenorth_> but I'm a bit weird :)
17:39:44  <Purno> Alberth, but ordinary files cannot be easily opened by everybody as far as I know.
17:40:01  <Alberth> make an html file
17:40:01  <Purno> We currently have an open office spreadsheet in the repository, but we don't have open office installed :P
17:40:11  <Purno> Can HTML tables be sortable?
17:40:21  <planetmaker> indeed. make it a plain text file or html
17:40:36  <planetmaker> Personally I prefer a plain text file Nothing beats it
17:40:40  <Purno> plain text tables cannot be sortable :<
17:40:43  <Alberth> you have to do that while generating or writing the file
17:40:57  <planetmaker> ^
17:41:12  <planetmaker> a wiki table can also not be sorted
17:41:12  <Purno> Sorry, I'd need a list which can be sorted at any time on several colums, like the ones on wikipedia are :P
17:41:18  <Purno> They can
17:41:25  <planetmaker> do they?
17:41:31  <planetmaker> I never noticed :-)
17:41:33  <Purno> If you add it to their code, they can :P
17:41:40  <Purno> at least, that's what wikipedia says :P
17:42:21  <Purno> So I hoped to be able to make a sortable wiki table, but well, there doesn't seem a place where I can
17:42:48  <Alberth> can you not generate each variant instead?
17:43:01  <Purno> what do you mean?
17:43:24  <Alberth> make a file sorted on column 1, one on column 2, etc
17:44:10  <Alberth> and publish all those files
17:44:31  <Purno> that'd make adding stuff to the table a pain in the ass
17:44:39  <Alberth> note that wikis generally have another disadvantage, your data is not stored in the repository
17:44:54  <Alberth> I'd write a script to generate such files :)
17:45:03  <Purno> But I'm not a scripter :P
17:45:15  <Purno> and merely a simple person with easy to use tools :P
17:45:19  <planetmaker> Purno: make one plain text list with one sorting. If you need to sort it - you can always load that plain text table into your spreadsheat of choice
17:45:58  <Purno> planetmaker, that isn't easy-to-use enough. I'd have to share the table with some other people.
17:46:16  <planetmaker> yes?
17:46:21  <Purno> There wouldn't be any service or site which would allow you to make a wiki page for free, I guess? :P
17:46:32  <planetmaker> openttd wiki?
17:47:00  <planetmaker> but honestly, what you want probably is google spreadsheets or however it's called
17:47:11  <Purno> I've considered google docs
17:47:14  <planetmaker> besides any such document easily outdates
17:47:17  <Purno> but sortable wiki tables work even easier
17:47:21  <planetmaker> as Alberth pointed out
17:47:37  <planetmaker> and sorting - as said - can be done by every person in the local spreadsheet
17:47:45  <Purno> so I could just create a page on the openttd wiki to do some fiddling with tables?
17:48:05  <Alberth> you don't want to keep the data in the repository?
17:48:13  <planetmaker> As it's OpenTTD - related, I guess it's ok
17:48:15  <Purno> not as a file, no.
17:48:27  <planetmaker> But yes... vehicle data and stuff is MUCH better kept in the repo
17:48:41  <planetmaker> The OpenTTD wiki is full of old crap of tracking tables of all kind of things
17:48:53  <planetmaker> used for two weeks and then never updated
17:49:04  <Purno> That might be sufficient for now
17:49:19  <planetmaker> why does it need to be sortable in a browser?
17:49:26  <planetmaker> Why can't you use OpenOffice locally?
17:49:47  <Purno> Because having to install software before you can see a table is not easy-to-use :P
17:50:02  <Purno> especially since OpenOffice isn't a tiny small tool :P
17:50:03  <planetmaker> And why does it need sorting?
17:50:22  <Purno> To give a better overview :P
17:50:36  <Purno> I just want to do some fiddling with wiki tables to see how it works out :P
17:51:02  <Purno> If I can use the openttd wiki for that, that'd be cool, if that one does support tables :P
17:51:33  <Alberth> it does have tables, but not dynamically sortable afaik
17:52:01  <Purno> I'll try to see if it works :)
17:52:03  <Alberth> how much data and columns are we talking about?
17:52:03  <Purno> thanks :)
17:52:08  <Purno> not sure yet
17:52:38  <Alberth> would a shell script suffice?
17:52:42  <Purno> prolly over 100 rows, and somewhere between 5 and 10 columns I think
17:52:50  <Purno> what's a shell script?
17:52:55  <Alberth> no :)
17:53:30  <Alberth> you have a windows system of course :(
17:54:46  <Alberth> hmm, DOS had a sort.exe iirc, just don't know whether it accepts columns to sort on
17:56:35  <Alberth> it does, based on character count :p
17:58:24  <Alberth>  <rant>arg, how can one do any work at a system without decent tools :( </rant>
17:58:29  <Purno> Alberth,   <-- sortable table works :)
17:58:50  <Alberth> wooow!!
17:59:22  <Purno> code directly copied from the wikipedia article about how to make tables :P
17:59:25  <Alberth> it can do more than I expected! :)
17:59:41  <Purno> Yeah, but tables aren't sortable unless you add it to their code :)
18:00:12  <Alberth> most tables should not be sortable, so that makes sense :)
18:09:50  <Brot6> 32bpp-ez-patches: update from r21011 to r21028 done (2 errors) -
18:11:01  <andythenorth_> frosch123: the only fix I can find so far is to give the lead vehicle capacity of 1t
18:12:34  <frosch123> if the front vehicle has the same refittability than the trailing ones, that should work except for the capacity in purchase list
18:12:51  <frosch123> but that is always troublesome for articulated vehicles
18:12:58  <frosch123> unfortunatelly it confuses ais :)
18:14:21  <andythenorth_> front vehicle does have same refittability
18:14:57  * andythenorth_ wonders what changed between HEQS versions
18:19:04  <Brot6> clientpatches: update from r21011 to r21028 done -
18:20:39  <Brot6> serverpatches: compile of r21028 still failed (#1658) -
18:22:51  <andythenorth_> frosch123: using buy menu cargo FF fixes the main issue
18:23:10  <frosch123> :)
18:23:34  <andythenorth_> introduces a new issue
18:23:40  <andythenorth_> the capacity shown in buy menu differs from that which will get built by default
18:23:56  <andythenorth_> I need to force the default subtype I guess
18:26:05  <andythenorth_> grr :)
18:26:40  * andythenorth_ points at pony called rv-wagons 
18:26:44  <andythenorth_> pony points back
18:27:22  <andythenorth_> don't think I can fix this
18:28:15  <andythenorth_> hmm
18:28:56  <andythenorth_> I could use two IDs for each tram wagon, setting initial capacity to n or 0 in the  action 0
18:29:03  *** Purno has left #openttdcoop.devzone
18:30:08  <frosch123> or set action 0 property to n/2 or whatever
18:34:28  <andythenorth_> hmm
18:34:30  <andythenorth_> possible
18:34:35  <andythenorth_> better if CPP could do maths :P
18:42:13  <Alberth> nml does :)
18:44:19  * frosch123 bets andy does not want to know :p
18:44:58  <andythenorth_> andy wants to exit the crazy world of articulated rvs
18:45:25  <andythenorth_> can we patch some hacks together to find out what might break?
18:47:42  <Brot6> HEQS "Heavy Equipment" Set - Revision 473:7fcdfa6ca2ae: Fix: temporary fix to tram capacity / r... (andythenorth) @
18:49:49  <andythenorth_> ach
18:50:02  <andythenorth_> tram capacity issue was present in older revisions too
18:50:10  <andythenorth_> so screw it for now :D
18:53:45  <Lakie> Heh
18:56:10  <Brot6> 32bpp-ez-patches - Revision 72:5314e2668961: Codechange: update to trunk svn r21028 to prevent pa... (GeekToo) @
18:57:02  <Brot6> HEQS "Heavy Equipment" Set - Bug #1719 (Closed): Tram consists don't match refits (game warning... (andythenorth) @
19:02:26  * planetmaker now tests whether building a 4-architechture zlib library has been successful
19:23:14  *** Levi has quit IRC
19:26:01  <planetmaker> hm, seems to work, the universal lib. Let hilarity ensue and "only" do it for libpng, libicu, liblzo2, libfreetype, libiconv, too
19:30:50  <Terkhen> good luck with libicu... it's hell to work with that :/
19:33:12  <planetmaker> first libpng now :-)
19:46:38  *** Levi has joined #openttdcoop.devzone
19:48:57  <Brot6> 2cc train set - Feature #1726 (New): 81-740 (Voyager1) @
19:48:57  <Brot6> 2cc train set - Feature #1726: 81-740 (Voyager1) @
19:52:15  <Brot6> FIRS Industry Replacement Set - Bug #1709 (Rejected): Some industries appear to be incorrectly bu... (andythenorth) @
20:03:10  <Brot6> 2cc train set - Feature #1726: 81-740 (simozzz_AK) @
20:05:40  *** Alberth has left #openttdcoop.devzone
20:07:04  <andythenorth_> good night
20:07:25  *** andythenorth_ has quit IRC
20:09:59  <michi_cc> planetmaker: is what the compile farm is/was using. (Some libs are probably not the latest anymore.)
20:10:42  <planetmaker> thanks. Seems that already libpng is not quite as straight forward as zlib
20:35:34  *** frosch123 has quit IRC
22:16:04  *** ODM has quit IRC
22:16:45  <Lakie> planetmaker, how so?
22:18:05  <planetmaker> it doesn't accept the -arch variable as it should
22:18:13  <Lakie> :(
22:20:38  <planetmaker> but seems I meanwhile patched the Makefile sufficiently
22:21:10  <planetmaker> ld: warning: in /usr/lib/dylib1.10.5.o, missing required architecture ppc64 in file
22:21:12  <planetmaker> ld: warning: in /usr/lib/libSystemStubs.a, missing required architecture ppc64 in file
22:21:13  <planetmaker> ld: warning: in /usr/lib/libSystem.dylib, missing required architecture ppc64 in file <-- though I'm not too happy about this
22:22:25  <planetmaker> Architectures in the fat file: libpng14.14.dylib are: i386 ppc7400 ppc970 x86_64 <-- well
22:22:50  <planetmaker> Architectures in the fat file: libpng.a are: i386 ppc ppc64 ppc970 x86_64
22:23:01  <planetmaker> shouldn't differ though :S
22:24:28  <michi_cc> planetmaker: are you passing a proper -isysroot to gcc?
22:25:29  <planetmaker> I set it in the CFLAGS, CXXFLAGS, CPPFLAGS and LDFLAGS
22:25:41  <planetmaker> but libpng is... not always using them properly
22:25:49  <Rubidium> are you lipo-ing the different versions together or not?
22:26:31  <michi_cc> planetmaker: The openttd makefile also has "Wl,-syslibroot,$osx_sdk_104_path" for linking
22:26:58  <planetmaker> Rubidium: yes
22:27:55  <planetmaker> <-- similar to this zlib thing I put there
22:28:08  <michi_cc> You also need to pass either -mmacosx-version-min=10.4 or -mmacosx-version-min=10.5 (depending on the SDK)
22:28:17  <planetmaker> I pass that, yes
22:28:27  <planetmaker> 10.3 doesn't work for libpng ;-)
22:28:55  <michi_cc> Well, if you want 10.3 you have to use gcc 3.3 anyway
22:29:21  <planetmaker> 	flags="-arch $this -isysroot $sdk -I $sdk/usr/include -mmacosx-version-min=10.4 -L/opt/local/lib"
22:29:40  <planetmaker> ^ that's what I use with $sdk being the obvious 10.4u
22:31:05  <michi_cc> ppc64 and x86_64 require the 10.5 SDK
22:33:44  <michi_cc> And I wouldn't bother doing ppc970 for libs, including that into static libs sometimes caused linking problems for me. Might of course be a problem of the cross-compiler.
22:34:31  <planetmaker> well. pp970 is automatically selected when I configure --enable-universal=64 with OpenTTD
22:38:04  <Rubidium> Q: how many ppc64 installs are there?
22:38:24  <Rubidium> Q: how many ppc installs are there, compared to how many i686/x86_64 installs?
22:39:07  <Rubidium> might it not be a "good" idea to ditch ppc970 and the never officially built-for-openttd ppc64?
22:39:19  <Rubidium> ditching from the makefile that is
22:39:47  <michi_cc> planetmaker: It is, but the libs don't need it as it is just a subtype of ppc.
22:40:08  <michi_cc> I.e. if no ppc970 is present the ppc image is used.
22:40:14  <planetmaker> michi_cc: selecting 10.4u or 10.5 make no difference to the results
22:40:37  <planetmaker> in any case I seem to miss ppc64 libs required for the dylib one
22:40:55  <planetmaker> Rubidium: I guess not many, though I recall seeing one(?) bug report related to it once
22:41:01  <michi_cc> planetmaker: add -Wl,-syslibroot,$sdk like ottd is doing?
22:41:45  <planetmaker> to the linking?
22:44:28  <Rubidium> don't see any bug report with ppc64, powerpc 64 or ppc 64 where it's not me asking whether it's powerpc
22:46:44  <planetmaker> well. It'd probably be easy to say >= 10.5 and intel only
22:47:11  <planetmaker> Well... why not
22:47:53  <planetmaker> are there other big endian platforms?
22:50:13  <planetmaker> that'd mean i386 and x86_64 only...
23:01:34  <SmatZ> I don't have access to that big endian sparc anymore
23:09:51  <planetmaker> Does the CF build x86_64?
23:20:02  <SmatZ> yes
23:20:17  <SmatZ> both linux and win64
23:23:26  <planetmaker> :-) and OSX x86_64?
23:24:02  <planetmaker> rather: could it, if asked to build Intel 64 bit OSX binaries?
23:42:43  <SmatZ> I think it wouldn't be a problem if you provided working build environment :)
23:43:06  <SmatZ> I don't know if there ever were x86_64 OSX builds
23:43:11  <SmatZ> rubi knows ;)
23:44:57  <planetmaker> I know on my computer are :-P
23:45:40  <planetmaker> Basically I wonder wether I should change the meaning of --enable-universal to what it means e.g. with macports on Snow Leopart: i386 + x86_64 combined
23:46:15  <planetmaker> I guess I'll keep ppc as an option, but not default
23:47:25  <planetmaker> and that then only because it would otherwise be MUCH work to get it going, if wanted
23:49:24  <SmatZ> I am wrong person to answer your questions, sorry :)
23:49:38  <SmatZ> I shouldn't have started trying to answer :D
23:49:51  <planetmaker> :-)
23:50:09  <planetmaker> And I've never seen such broken screen as just when starting the built bundle :S
23:51:11  <SmatZ> :(
23:55:55  <planetmaker> now: why with bundle_dmg, but not without?
23:57:56  <planetmaker> hm... seems it doesn't like fat binaries
23:58:05  *** KenjiE20 has quit IRC
23:58:28  <planetmaker> anyway... for another day, not this night anymore
23:58:31  <planetmaker> good night :-)

Powered by YARRSTE version: svn-trunk