IRC logs for #openttd on OFTC at 2012-03-04
⏴ go to previous day
00:59:56 <Zuu> Hmm, I've hit a strange error where CmdSellVehicle thinks that the vehicle is not in the depot when it is called from a GS.
01:00:54 <Zuu> I tried to set the current road type and have stepped thoght the CmdSellVehicle code without figuring out why it doesn't work. Selling the same vehicle via GUI works fine.
01:01:44 <Zuu> But it's getting late now. I'll have to look into it more another day or just report it to bugs.openttd.org and hope that it's not my fault. :-)
04:08:26 *** DrSpangle has left #openttd
05:28:36 *** welshdragon has joined #openttd
05:34:31 *** Devroush has joined #openttd
05:56:22 *** Eddi|zuHause has joined #openttd
06:18:47 *** supermop has joined #openttd
06:39:59 *** sla_ro|master has joined #openttd
06:42:05 *** kkb110__ has joined #openttd
06:49:41 *** tokai|mdlx has joined #openttd
06:55:47 *** andythenorth has joined #openttd
06:58:12 *** tokai|noir has joined #openttd
06:58:12 *** ChanServ sets mode: +v tokai|noir
07:00:10 <sponge> Yet, when I try to set a callback for the property, NML gives an error that it expects a constant value.
07:04:25 <sponge> too bad he made the station and wagons so small
07:04:29 <andythenorth> sponge: set the value of that property to some default, then we need to call the callback from the graphics{ } block
07:04:58 <sponge> andythenorth: the graphics block has a coeffecient property too?
07:05:09 *** tokai|mdlx has joined #openttd
07:05:28 <andythenorth> "The following callbacks all have an equivalent property. The property description applies here also, except where otherwise noted."
07:05:58 <andythenorth> so you add tractive_effort_coefficient to the graphics block to use the cb
07:06:16 <andythenorth> I could explain this in terms of raw newgrf if it helps, but maybe not needed
07:06:20 <sponge> andythenorth: my switch is bad
07:06:32 <sponge> bad expression in switch
07:06:47 <sponge> the TTwiki has some subtle differences from openttd and modern nml
07:07:15 <sponge> andythenorth: is there an easier way to just have power to the lead car?
07:08:05 <sponge> and in the case of the c20 only for 2/3 of the cars
07:08:32 <andythenorth> I don't code trains
07:08:43 <andythenorth> is there a powered wagon cb?
07:09:52 <andythenorth> visual_effect_and_powered
07:10:06 <andythenorth> set to DISABLE_WAGON_POWER ?
07:10:42 <andythenorth> the way you're using is fine, but you would better use hp (power) not TE
07:11:45 <andythenorth> final tractive effort is a calculation of (hp * TE coefficient * physics stuff)
07:12:18 <andythenorth> so setting hp to 0 or some value is the correct way to do this - otherwise vehicle info reports too much power
07:12:49 <andythenorth> you can leave te coefficient at default if you do that
07:13:15 <andythenorth> or make a new vehicle ID for unpowered vehicles, but that duplicates a lot of code and wastes buy menu space
07:13:18 <sponge> how do I write a switch to return that value?
07:13:30 <andythenorth> looks to me like you did already
07:13:39 <andythenorth> does you te switch not work?
07:13:51 <sponge> get bad expression error
07:14:02 <sponge> "This expression is not supported in a switch-block"
07:15:29 <sponge> the power switch works, just not the traction
07:16:39 <andythenorth> do you have 2/3 in the switch block somewhere
07:17:39 <sponge> but in any case, here's what works now: only the lead car has power
07:18:19 <sponge> coefficient 1.0 means full hp to tracks, right?
07:19:09 <andythenorth> coefficient more or less represents the friction between wheel and surface
07:19:17 <andythenorth> 1.0 is an insanely high value for steel on steel ;)
07:20:01 <andythenorth> otherwise you'll be way out of balance with other sets ;)
07:20:09 <andythenorth> I'd leave it at default usually
07:21:01 <sponge> acceleration is looking good
07:21:14 <sponge> the c1 rarely reaches top speed of 80km/h
07:21:19 <sponge> goes down to 60 in the corner
07:21:27 <sponge> c14 is slightly better with it's additional 80k
07:21:39 <sponge> the c20 has no problem getting up to speed.
07:24:11 <sponge> it has more than twice the power of the c14, so...
07:24:17 <sponge> andythenorth: where did you think i should UL this?
07:27:27 <sponge> ok, im registered, how do I UL? :)
07:28:16 <andythenorth> you need to choose a license (use GPL)
07:28:23 <sponge> that site seems rather incomplete
07:28:49 <andythenorth> for GPL you need a license.txt in your zip
07:28:55 <sponge> if you press profile all you get is "index" and "profile" menus
07:29:17 <sponge> oh i thought the newgrf's came in tar
07:30:43 <andythenorth> you might also write a readme.txt
07:37:07 <sponge> put in the gpl 3 clause everywhere needed
07:37:17 <sponge> a quick readme thingsy
07:38:18 <sponge> andythenorth: im guessing bananas doesnt provide any repository or a way to upload?
07:50:54 <andythenorth> tar is fine afaik
08:04:13 <sponge> andythenorth: should I also put sources and everything into what is the downloadable content file?
08:04:19 <dsdeiz> hi is there a way to explicitly set the screen resolution openttd in windowed mode?
08:05:02 <sponge> under "screen resolution"
08:06:11 <dsdeiz> any way to add a new screen resolution on that option?
08:08:30 <sponge> dsdeiz: how come you cant just resize the window?
08:10:26 <dsdeiz> i can though if i do that i need to resize it everytime i start the game :(
08:11:48 *** mahmoud has joined #openttd
08:11:58 *** tokai|noir has joined #openttd
08:11:58 *** ChanServ sets mode: +v tokai|noir
08:12:38 <sponge> dsdeiz: can't you tell your window manager to lock the geometry of the window?
08:12:56 <sponge> i do it on both icewm, fluxbox and compiz
08:15:33 <dsdeiz> oh. hm, not sure how to do that but will try. thx! i'm using xmonad if that helps
08:19:09 <andythenorth> sponge: if the source is small, bundling it with the grf is fine / good
08:19:45 <andythenorth> if it's hundreds of KB, or several MB, make a devzone project for it...
08:23:36 <sponge> dsdeiz: isnt xmonad tiling?
08:23:48 <sponge> dsdeiz: it's possibly to do this through Xresources
08:24:57 *** tokai|mdlx has joined #openttd
08:52:01 *** Firartix has joined #openttd
08:54:27 <sponge> where is a list of what colours are used for company?
08:55:02 <andythenorth> newgrf wiki somewhere
08:58:56 <Zuu> dsdeiz: You can access the game options window in-game as well as from the main menu.
08:59:20 <Zuu> You find it in the same menu as save/load scenarios.
09:02:12 *** andythenorth is now known as Guest4990
09:02:13 *** andythenorth has joined #openttd
09:06:11 *** TWerkhoven[l] has joined #openttd
09:19:37 *** Progman has joined #openttd
10:06:15 *** kleinerdrache has joined #openttd
10:14:21 * andythenorth has to make a design decision and is stumped
10:14:49 <andythenorth> +ve y on the canvas: up or down?
10:15:07 <andythenorth> - the correct answer in coding is usually 'down'
10:15:34 <Arafangion> andythenorth: Actually, it's generally up these days.
10:15:36 <andythenorth> - the correct answer in most GUI bitmap editors (and I think, most people's intuition) is up
10:15:40 <Arafangion> andythenorth: Mathematically, it should be up.
10:15:45 <Arafangion> andythenorth: But, winforms has it down.
10:16:02 <andythenorth> Flash has it down, and I spent 7 years far too intimately with Flash :P
10:16:18 <andythenorth> confusingly, the Flash drawing tools treat it as up iirc
10:16:23 <Arafangion> andythenorth: It seems a bit silly now, but the reason that some (legacy?) GUI toolkits had it down was to optimise rendering while keeping in mind the scan rate of the CRT's.
10:16:51 <andythenorth> yeah, afaik it's a scanline-optimised co-ordinate system
10:16:52 <Arafangion> Mac OS X's Cocoa lets you toggle it rather easily (elegantly, even), but it defaults to up.
10:17:18 <andythenorth> I can work with it 'up' throughout my API, but the code expects 'down'
10:17:28 <Rubidium> andythenorth: take the worst solution and add some buzz words to it
10:17:37 <Rubidium> so... start from the middle
10:17:41 <Arafangion> It's actually not a big deal.
10:17:48 <andythenorth> so anyone who subclasses Pixa stuff to extend it will run smack into inverted y
10:17:52 <andythenorth> Rubidium: x and y :P
10:17:58 <Arafangion> No, x is remarkably consistent, it's y that flips.
10:18:06 <andythenorth> Rubidium is trolling again :P
10:18:12 <andythenorth> someone should kick him
10:18:13 <Eddi|zuHause> andythenorth: mostly screen-coordinates have y=0 at the top
10:18:34 <Arafangion> Eddi|zuHause: Not on the mac os x.
10:18:37 <andythenorth> PIL has origin top left
10:18:40 <Arafangion> Not sure if that's true in Xorg either.
10:18:46 <sponge> in my experience, y=0 at the top comes from the fact that nearly all video chipsets had top left as memory offset 0
10:18:52 <andythenorth> PIL is the significant issue here tbh
10:19:09 <andythenorth> I have no problem flipping it so +ve y is up
10:19:15 <andythenorth> it's kind of done already
10:19:18 <Rubidium> andythenorth: actually, some geographic datums have x and y swapped
10:19:29 <Eddi|zuHause> andythenorth: if you do pixel-by-pixel scans, starting at the top and going in reading-direction feels more natural
10:19:50 <Rubidium> andythenorth: good question ;)
10:20:00 <andythenorth> Eddi|zuHause: I could also make it configurable, but that's a bit of an arse
10:20:22 <Eddi|zuHause> that seems somewhat silly
10:20:33 <Eddi|zuHause> just pick one and stick with it
10:20:45 <Rubidium> configurable by XML ofcourse
10:21:01 <andythenorth> I want to pick 'up'. But I'm leaving dragons lurking for those who want to extend my classe :P
10:21:15 <andythenorth> ach, if they know how to extend a class, they can handle inverting y
10:21:34 <Eddi|zuHause> andythenorth: openttd internally also has y as "down"
10:21:58 <andythenorth> nfo offsets work that way
10:22:03 <Eddi|zuHause> as do pretty much all pixel-editors i know
10:22:35 <andythenorth> yeah, actually I was mistaken there, photoshop has y = 0,0
10:22:42 <andythenorth> oops, origin = top left
10:22:55 <andythenorth> typing ahead of thinking :P
10:23:08 <sponge> it's a legacy from the time when you needed to handle video memory directly.
10:23:28 <sponge> who ever made the first one felt it natural to go from left to right and then down
10:23:32 <Rubidium> anyhow, in google maps enter something like 52.0 5.0. That will show you you basically enter them in y x (and y goes up from the bottom)
10:23:56 <sponge> (which also happens to be the orientation for western text)
10:24:22 <Eddi|zuHause> Rubidium: but they call it "North" and "East"
10:24:27 * andythenorth might use origin top-left
10:24:35 <andythenorth> which means rewriting a lot of stuff already written
10:24:46 <andythenorth> but what else is code for, except rewriting?
10:25:25 <Arafangion> Reading for fun and pleasure?
10:25:31 <Rubidium> Eddi|zuHause: that's just some label you add to it
10:25:52 * Zuu is amused about his vehicle that is in depot, but GS thinks not
10:26:11 <andythenorth> Zuu: is it stopped in depot, but not actually in depot?
10:26:27 <andythenorth> yesterday I somehow managed to crash two vehicles in a depot, one was stopped
10:26:43 <Zuu> Its a road vehicle. And it doesn't show if I make the depot transparent.
10:26:58 <sponge> andythenorth: sometimes trains jump to other tracks
10:27:04 <sponge> like foxes over fences
10:27:36 <Zuu> I have a mini-GS that demonstrates a problem in SendVehicleToDepot. It was planed to show a problem in SellVehicle but got problems earlier already. :-)
10:27:40 <Eddi|zuHause> Rubidium: something similar happens with mathematical and physicist diagrams. the name for a mathematical diagram is "x-y-diagram", but for a physicaist diagram it's an "y-x-diagram" (where y and x denote some measurements)
10:28:20 * andythenorth hopes missile control systems avoid using multiple co-ordinate directions
10:28:46 <Zuu> hmm, no. that problem with my mini-GS was later solved by setting company mode
10:28:50 <Eddi|zuHause> andythenorth: when not even mars probes properly handle unit conversions?
10:29:32 <andythenorth> so who would like to rewrite my code for me?
10:29:51 <Arafangion> andythenorth: For how much? ;)
10:30:07 <andythenorth> it's only swapping the sign on a load of items in tuples
10:30:20 <Arafangion> Why not use an editor macro?
10:30:25 <andythenorth> I could just patch what I have already in the code
10:30:30 <Eddi|zuHause> andythenorth: sounds like a job for a regexp :p
10:30:35 <Terkhen> andythenorth: as long as the requirements are low enough I can rewrite your code for free
10:30:45 <andythenorth> requirements = '' ?
10:30:53 <Terkhen> "this code does not need to have any functionality at all"
10:31:11 <andythenorth> I could just plug a transform into the render pipeline: dy = -1 * dy
10:31:28 <andythenorth> the lazy solution using the API :P
10:32:00 <andythenorth> leaves code debt lying around though :P
10:32:44 <Eddi|zuHause> #TODO: clean this up
10:33:13 <Arafangion> andythenorth: Not really, as long as it all stays consistent.
10:33:19 <Arafangion> andythenorth: A transform is routine.
10:33:29 <Jogio> planetmaker here? I changed 4 little strings in translation, one was a clear typo. Just that you know.
10:34:35 <Jogio> hi xD . Then all is fine. :-)
10:37:14 * andythenorth incurs where and tear on his '-' key :P
10:40:53 *** TGYoshi has joined #openttd
10:52:06 <Terkhen> ooh, a new spanish translator
11:15:31 <andythenorth> 'origin' or 'centerpoint' ?
11:15:53 <andythenorth> make_a_bitmap_a_pixa_sequence(file, origin)
11:17:17 <andythenorth> it specifies a center point when drawing the sequence
12:16:51 *** KasperVld has joined #openttd
12:32:49 *** valhallasw has joined #openttd
12:37:56 *** Alberth has joined #openttd
12:37:56 *** ChanServ sets mode: +o Alberth
12:42:58 <Alberth> Pixa insanely ricx already? :D
12:45:14 <andythenorth> best suggestion yet :)
12:50:37 <Alberth> a boring one would be Pixa is for graphix artists ;)
12:51:33 *** frosch123 has joined #openttd
13:24:27 *** andythenorth has joined #openttd
13:39:03 *** cmircea has joined #openttd
13:47:39 *** TWerkhoven has joined #openttd
14:04:54 <_maddy> anyone up for a multiplayer game guys?
14:15:22 <Rubidium> Zuu: does the tutorial GS actually use the AI order flags?
14:17:05 *** sla_ro|vista has joined #openttd
14:18:20 *** peteris has joined #openttd
14:22:19 <andythenorth> smoothing is not included :P
14:26:00 *** peteris is now known as pecisk
14:29:18 <andythenorth> prize for telling me what that zoomed in sprite is
14:30:56 <Rubidium> a coil of steel or so?
14:32:13 *** Devroush has joined #openttd
14:34:01 *** Firartix has joined #openttd
14:34:17 *** theholyduck has joined #openttd
15:05:24 *** JVassie has joined #openttd
15:27:18 <Zuu> Rubidium: The tutorial GS doesn't use the AIOF_* constants.
15:27:35 <Zuu> So it shouldn't be using order flags.
15:47:16 *** sla_ro|master has joined #openttd
16:02:05 *** lofejndif has joined #openttd
16:20:33 *** kleinerdrache has joined #openttd
16:33:19 <CIA-1> OpenTTD: rubidium * r24003 /branches/1.2/ (6 files in 4 dirs):
16:33:19 <CIA-1> OpenTTD: [1.2] -Backport from trunk:
16:33:19 <CIA-1> OpenTTD: - Fix: Do not load a game during UpdateWindows as that might trigger changing the blitter which triggers re-entrant locking (r23980, r23977)
16:33:19 <CIA-1> OpenTTD: - Fix: [SDL] Palette update was done too late making switching from 8bpp -> 32bpp look ugly (r23978)
16:33:19 <CIA-1> OpenTTD: - Fix: Sprites of different zoom levels were not always padded correctly to a common size (r23976)
16:33:20 <CIA-1> OpenTTD: - Fix: Also save the maximum travel speed for the current vehicle order (r23973)
16:38:07 <CIA-1> OpenTTD: rubidium * r24004 /branches/1.2/ (8 files in 4 dirs):
16:38:07 <CIA-1> OpenTTD: [1.2] -Backport from trunk:
16:38:07 <CIA-1> OpenTTD: - Fix: Zero the offsets of disabled zoomlevels, so they do not influence offset calculations (r23989)
16:38:07 <CIA-1> OpenTTD: - Fix: Invalid reads when scaling an odd-sized sprite smaller (r23986)
16:38:07 <CIA-1> OpenTTD: - Fix: Inconsistent quit/abandon/exit game/scenario/editor strings [FS#5074] (r23985)
16:38:08 <CIA-1> OpenTTD: - Fix: Tarred heightmaps would not be found [FS#5083] (r23983)
16:39:15 <CIA-1> OpenTTD: rubidium * r24005 /branches/1.2/ (33 files in 4 dirs):
16:39:15 <CIA-1> OpenTTD: [1.2] -Backport from trunk:
16:39:15 <CIA-1> OpenTTD: - Fix: Fix the order of lights on the helipad [FS#5082] (r23984)
16:40:11 <CIA-1> OpenTTD: rubidium * r24006 /trunk/ (9 files in 5 dirs): -Fix [FS#5088]: AI used in names in API for GSOrder
16:43:44 <CIA-1> OpenTTD: rubidium * r24007 /branches/1.2/ (57 files in 4 dirs):
16:43:44 <CIA-1> OpenTTD: [1.2] -Backport from trunk:
16:43:44 <CIA-1> OpenTTD: - Fix: Improve rounding when converting display speeds to internal speeds [FS#5079] (r23995)
16:43:44 <CIA-1> OpenTTD: - Fix: Also reset the font glyph cache when switching blitters (r23992, r23987)
16:43:44 <CIA-1> OpenTTD: - Fix: [NewGRF] Also display the cargo subtype for vehicles which have no capacity, but a subtype [FS#5076] (r23991)
16:54:14 <CIA-1> OpenTTD: rubidium * r24008 /trunk/src/script/api/ (22 files): -Cleanup/doc: try not to mention (No)AI in script APIs
16:56:43 <CIA-1> OpenTTD: rubidium * r24009 /branches/1.2/ (30 files in 6 dirs):
16:56:43 <CIA-1> OpenTTD: [1.2] -Backport from trunk:
16:56:43 <CIA-1> OpenTTD: - Fix: [Script] AI used in names in API for GSOrder [FS#5088] (r24006)
16:57:37 *** JVassie has joined #openttd
16:58:05 *** tokai|noir has joined #openttd
16:58:05 *** ChanServ sets mode: +v tokai|noir
17:01:24 <CIA-1> OpenTTD: rubidium * r24010 /branches/1.2/ (. src/fontcache.h): [1.2] -Fix: forgot to backport r23992
17:03:28 *** ChanServ sets mode: +v tokai
17:06:05 *** brambles has joined #openttd
17:09:09 <CIA-1> OpenTTD: translators * r24011 /trunk/src/lang/ (5 files in 2 dirs):
17:09:09 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:09:09 <CIA-1> OpenTTD: catalan - 1 changes by arnau
17:09:09 <CIA-1> OpenTTD: german - 4 changes by Jogio
17:09:09 <CIA-1> OpenTTD: italian - 1 changes by Snail_
17:09:10 <CIA-1> OpenTTD: tamil - 24 changes by aswn
17:09:18 *** tokai|mdlx has joined #openttd
17:11:20 <CIA-1> OpenTTD: rubidium * r24012 /trunk/src/lang/luxembourgish.txt: -Fix (r24011): Luxembourgish got messed up by accident
17:12:43 <CIA-1> OpenTTD: rubidium * r24013 /branches/1.2/src/lang/ (40 files in 2 dirs): [1.2] -Backport language updates from trunk
17:16:38 <CIA-1> OpenTTD: rubidium * r24014 /branches/1.2/ (6 files in 4 dirs): [1.2] -Prepare for 1.2.0-RC2
17:22:19 <CIA-1> OpenTTD: rubidium * r24015 /tags/1.2.0-RC2/: -Release: 1.2.0-RC2
17:31:16 *** TWerkhoven[l] has joined #openttd
17:34:08 *** HerzogDeXtEr has joined #openttd
18:24:25 <andythenorth> can I compare two tuples?
18:25:14 <NGC3982> if tuples is the word for tits in your local language, sure!
18:25:36 <SpComb> oh, I thought he meant the Python tuples thing
18:26:55 <planetmaker> you can compare everything. But some comparisons are tasteless, others meaningless, yet others invalid and yet even others... useful
18:27:15 <andythenorth> this one turns out to be useful
18:27:27 <andythenorth> it even works usefully when the second tuple is None
18:27:57 <SpComb> less than/greater than comparisons can error out
18:32:16 <andythenorth> it's a straightforward == ;) but thanks
18:35:01 <andythenorth> cheatsheets: now with optional display of a custom origin (in pink)
18:35:30 <andythenorth> the origin indicates where the pixel generator will begin drawing
18:36:10 <andythenorth> the numbers are of course palette indexes :D
18:43:17 *** lofejndif has joined #openttd
18:58:19 <Zuu> Hmm, it helps to use the correct vehicle id variable when trying to sell them.
18:58:46 <Zuu> Which is also why OpenTTD rejected me selling a vehicle and told that it was not in the depot.
19:04:14 <Eddi|zuHause> andythenorth: on immutable objects, comparison is usually by hash (i.e. memory location)
19:10:31 <Yexo> on other objects it is by default (no matter if they're immutable or not), unless you implement a __cmp__ function yourself
19:10:48 <Eddi|zuHause> i wrote that wrong, yes
19:12:21 <Eddi|zuHause> i meant to say: "on objects it is usually done by hash, but immutable objects are usually singletons"
19:16:32 <Eddi|zuHause> and if you implement __cmp__ you probably should also implement __hash__
19:17:48 <Alberth> Eddi|zuHause: by 'id', actually
19:18:40 <Eddi|zuHause> Alberth: i'm pretty sure that "id(object)" is the same as "object.__hash__()"
19:19:41 <Alberth> but hashing is used for sets/dicts, not for equality
19:20:30 <Eddi|zuHause> i should probably stop this discussion, as i am dangerously close to the limits of my half-knowledge :p
19:20:43 <Yexo> but there are indeed rules that if you implement __cmp__ you also have to implement __hash__
19:20:57 <Yexo> or the other way around, not sure, I think the way I wrote it
19:21:26 <Eddi|zuHause> i vaguely remember falling into that trap before
19:21:58 * Alberth normally disables __cmp__ and uses __eq__ and __ne__
19:22:47 <Eddi|zuHause> that doesn't really change anything
19:23:05 <Alberth> Eddi|zuHause: equality implies equal hash, but not the other way around
19:23:14 *** kleinerdrache has joined #openttd
19:23:58 <Eddi|zuHause> yes, so if you implement __eq__, you also have to implement __hash__ to fulfil that condition
19:24:17 <Eddi|zuHause> whether you implement __eq__ or __cmp__ doesn't matter in that case
19:27:12 *** DrSpangle has joined #openttd
19:29:43 <Alberth> it prevents accidental use of __lt__ / __gt__ comparisons :)
19:40:10 *** Rhamphoryncus has joined #openttd
19:45:34 <NGC3982> is there any perticular reason why i cant sell a depot, but simply destroy them?
19:49:43 <NGC3982> or what am i missing :)
19:50:22 <Alberth> you don't sell tracks and bridges either, so why would you dell depots?
19:51:25 <andythenorth> so wrt tuple comparison :P
19:51:39 <andythenorth> "if (x,y) == origin: stuff"
19:51:57 <andythenorth> where origin is assumed to be a tuple or None (it's unguarded though)
19:52:07 <andythenorth> and I only care to get the result when they're equal...
19:53:08 *** Chris_Booth has joined #openttd
19:55:29 *** Devroush has joined #openttd
19:57:11 <NGC3982> Alberth: a correction, i cant remove it (as i can with a station) without using the bomb-button.
19:58:39 *** Biolunar has joined #openttd
20:00:49 <Alberth> correct, same as bridges thus
20:01:27 <Alberth> andythenorth: I'd test explicitly for non-None-ness, but that's me :p
20:01:43 <Alberth> if origin is not None and (x,y) == origin: ...
20:02:16 *** lmergen has joined #openttd
20:03:02 <Alberth> NGC3982: you can use other tools with tracks & stations, as you often want to keep other parts of the same structure
20:03:13 <Alberth> but a depot is 1 tile exactly
20:03:38 * andythenorth could use a code review, although...it's growed :P
20:03:49 <NGC3982> Alberth: ah, i understand.
20:03:54 <andythenorth> might be coming time to figure out how to package this thing
20:05:06 <andythenorth> some kind of easy_install or setup.py or such?
20:05:17 <andythenorth> maybe I should revisit buildout :P
20:05:19 <Alberth> didn't you make that?
20:05:34 <andythenorth> someone I know made it
20:05:40 <andythenorth> the buildout part fails :P
20:05:59 <andythenorth> we ought to revisit how nml is packaged, but it's felt to be mostly solved
20:06:20 <andythenorth> however I don't like that it includes things that are known broken :(
20:06:42 <Alberth> oh, the hg revision thingie?
20:07:22 *** Illegal_Alien has joined #openttd
20:09:03 * Alberth switched from distutils to autoconf tools, and it works great....... at unix systems :p
20:10:11 <Yexo> andythenorth: I don't disagree that the nml packages might have to be revised, however I haven't seen any complains from people who failed to install it, and there are more interesting things to work on
20:10:28 <andythenorth> I think I'm just unfamiliar with the methods
20:10:47 <andythenorth> the frameworks I normally use are buildout driven, or very occasionally, virtual-env
20:11:12 <Alberth> that a separate issue, isn't it?
20:11:27 <andythenorth> so rather than system-wide module installs, I'm used to isolating deps for a specific project
20:11:34 <andythenorth> kind of separate yes
20:11:48 * Alberth used Combinator tools for python projects
20:11:56 <andythenorth> although afaict, nmlc requires a system wide PIL, PLY and nml
20:12:16 <andythenorth> I have very limited knowledge, I'm normally just a buildout user, or someone else setsup a virtual-env on my box for me
20:12:28 <Alberth> no, they just need to be findable on the PYTHONPATH
20:13:01 <Alberth> (just like all modules :p )
20:13:55 <Alberth> I'd not bother with virtual-env. If a user wants it, he can make it himself
20:14:37 <andythenorth> that's a common conclusion :)
20:15:16 <Alberth> of course it is; how else are you going to do virtual-env of a random selection of modules
20:16:00 <Alberth> ie if both nml and pixa would do their own virtual-env, I cannot combine them any more
20:17:26 <andythenorth> so normally I'm using (relatively) massive web frameworks, with easy_install or something else pulling down 1 bazillion modules / eggs / whatever from pypi or other locations
20:17:59 <andythenorth> and normally all that goes in a buildout (or - rarely - a virtual-env)
20:18:13 <andythenorth> so...I guess buildout simply sets a search paths
20:18:32 <andythenorth> anyway it's not critical here :)
20:18:39 <Alberth> could be, I never looked into those things
20:18:58 <andythenorth> the goal in those cases is to isolate projects entirely
20:19:04 <Alberth> Combinator does it for branches in the svn
20:19:51 <Alberth> so you can run code in one branch , and still be able to switch branch in a single command
20:19:54 <andythenorth> Alberth: got a link?
20:20:04 <andythenorth> google only finds Y-combinator stuff
20:20:51 <Alberth> hmm, the inventors went bankrupt, it moved to github or bitbucket or so, let me see whether I can find it
20:24:04 <andythenorth> so for Pixa, should I just move it to its own repo, and those interested will be able to figure it out?
20:24:26 <andythenorth> I have no idea how they'd include it into a project
20:24:38 <andythenorth> something like svn externals?
20:25:03 <andythenorth> or add to the module search path I guess
20:27:12 <Alberth> just as nml, have the root package dir next to the 'run' script
20:27:44 <Alberth> ie the script dir is automagically added by Python in its PYTHONPATH
20:28:08 <Alberth> that's why nmlc can do 'from nml import ....'
20:29:02 <andythenorth> that's the connection I couldn't make
20:29:33 <andythenorth> if you checkout say...BANDIT...you need to be able to get fewest number of deps
20:30:00 <Alberth> if you have code that a user is supposed to modify, rename it to foo_example.py or so, so users can make foo.py rather than messing up source file under the VCS
20:30:36 <andythenorth> I'd consider shipping Pixa inside the project to reduce deps - but then how do authors pull changes?
20:31:27 <Alberth> why does it work with nml?
20:31:53 <andythenorth> you have to install nml separately
20:31:55 <Alberth> oh, I don't include it in my project, of course :p
20:32:00 <andythenorth> it doesn't come with the project
20:32:19 <NGC3982> how can i use rcon <password> "command" - if there is no rcon password set?
20:32:34 <andythenorth> it's just a different approach to some of the python web frameworks I guess, which try to avoid separate deps
20:33:02 <andythenorth> if you want to deploy 200 clients to production servers, you don't want to arse about with the deps for each one :P
20:33:17 <andythenorth> different context
20:33:45 <Alberth> but you then also don't run trunk at the 200 clients, do you :)
20:33:59 <andythenorth> no, you run known good sets if you have any sanity
20:34:09 <andythenorth> running trunk is proven to impinge on drinking time
20:34:14 <andythenorth> or making profit
20:34:30 <Alberth> 'tick those that apply'
20:35:22 <Alberth> luckily not, or you cannot make money while sleeping :p
20:35:43 *** tokai|noir has joined #openttd
20:35:43 *** ChanServ sets mode: +v tokai|noir
20:35:44 * Zuu just re-invented sign commands :-)
20:36:17 <NGC3982> Yexo: if i already have a server running (and doesnt wish to terminate it) with no rcon password set - im pretty much face down stuck.
20:37:27 <Zuu> You could connect as client to download the savegame and restore from it if you take town the server.
20:37:36 <Zuu> All company passwords wolud however then be lost.
20:37:50 <glx> you can also access the console on the server
20:37:56 <Yexo> NGC3982: connect to the server over ssh and (if you have it running in a screen session) use that as console
20:38:34 <NGC3982> although, i have physical access to the computer running it.
20:39:23 *** chester_ has joined #openttd
20:40:06 <Yexo> if you can access the console there you might be able to set an rcon password
20:46:42 *** tokai|mdlx has joined #openttd
20:54:34 <andythenorth> I was just too lazy to look up the PIL spec :D
20:56:40 <Alberth> my width is not broken; it simply does not have such a parameter :)
20:58:12 <andythenorth> what I should really do is figure out how to centre the index numbers in cheatsheets :P
20:58:16 <andythenorth> clearly very important
20:58:49 <andythenorth> or perhaps right-align them
21:05:52 <NGC3982> i actually didnt realize i could write commands directly in the openttd server-program
21:17:25 *** glevans2 has joined #openttd
21:46:49 <andythenorth> can python multi-thread?
21:47:25 <TrueBrain> but it has a global place it does things, which makes it poor for certain applications
21:47:36 <TrueBrain> that was no english .. hmm ...
21:47:46 <TrueBrain> I guess a better answer is: python can make threads
21:47:58 <TinoDidriksen> But the global lock limits the usability of them.
21:48:12 <TinoDidriksen> Though they reduced the lock in Python3
21:48:19 <TrueBrain> but its still there :(
21:48:30 <andythenorth> but I could spawn multiple python processes? and distribute work between them?
21:48:34 <TrueBrain> not so much a lock, more of a general storage, but meh
21:48:40 <TinoDidriksen> andythenorth, sure
21:48:53 *** valhallasw has joined #openttd
21:48:57 <NGC3982> please make me a star trek the next generation food processor.
21:49:09 <TinoDidriksen> You mean a replicator?
21:49:10 <andythenorth> but I'd have to use something not-python to start the processes?
21:49:42 <TinoDidriksen> andythenorth, I'm sure Python has a fork() equivalent which would spawn a whole process, not just a thread.
21:49:49 <andythenorth> that's what I need
21:49:57 <TrueBrain> andythenorth: Python is pretty self-contained; you can do almost anything within Python :)
21:50:15 <TrueBrain> but all this vague talk is not really helping anyone
21:50:27 <andythenorth> their is zero requirement for them to share any data except input from disk, and some parameters passed when spawning a process
21:50:33 <andythenorth> their / there /s
21:51:02 <TrueBrain> data from disk, sounds like a job for mmap
21:51:13 <andythenorth> it's a map type problem imho
21:51:26 <andythenorth> I need to generate n pngs
21:51:30 <andythenorth> each is self contained
21:51:39 <andythenorth> all the input is read-only, never modified during the process
21:52:00 <TinoDidriksen> Embarrasingly parallel, is the term.
21:52:03 <andythenorth> I can lock 1 of the thread units on my 4-thread CPU
21:52:20 <andythenorth> I'm looking into a future where generating graphics takes 10 mins
21:52:25 <andythenorth> 2.5 mins would be better :P
21:52:59 <TinoDidriksen> How many and how large PNGs? And what kind? Maybe OpenCL could help...
21:53:37 <andythenorth> probably not a big enough problem
21:53:46 <andythenorth> and I"m quite tied to python imaging library (PIL)
21:54:23 <andythenorth> but yes, it's embarrassingly parallel, once divided into segments, which is not too hard
21:54:31 <TinoDidriksen> 10 full minutes of image generation sounds like 1 million tiny PNGs, or 4 huge ones?
21:58:06 <andythenorth> it's probably low thousands of small PNGs
21:58:14 <andythenorth> 10 mins might be exagaerated
21:59:43 <andythenorth> the code is not particularly optimised
22:00:02 <TinoDidriksen> Plus it's Python.
22:00:40 <andythenorth> building all the PNGs is not a frequent task...
22:00:54 <andythenorth> still it would be nice to be able to run it at max speed
22:07:32 *** KasperVld has joined #openttd
22:19:55 * andythenorth a la bed, toute suite
22:34:32 *** theholyduck has joined #openttd
22:39:22 *** theholyduck has joined #openttd
continue to next day ⏵
