IRC logs for #openttd on OFTC at 2014-01-19
⏴ go to previous day
00:37:06 *** Hazzard has joined #openttd
00:51:59 *** GriffinOneTwo has joined #openttd
01:22:36 *** jjavaholic_ has joined #openttd
01:49:33 *** GriffinOneTwo has joined #openttd
01:58:09 *** gelignite_ has joined #openttd
02:01:13 *** Aleksandr has joined #openttd
02:01:21 <Aleksandr> Is their anyway to issue orders to an entire group? x.x
02:07:35 <Pinkbeast> Aleksandr: Use shared orders.
02:09:21 <Aleksandr> There's a way to issue them to an entire group at once?
02:09:58 <Pinkbeast> No, I mean that the right way to do this is to cause vehicles you wish to give orders to at once to have shared orders, irrespective of the group they are in.
02:45:21 *** HerzogDeXtEr has joined #openttd
03:26:16 *** eviltoaster has joined #openttd
03:34:41 *** Aleksandr_ has joined #openttd
04:31:48 *** retro|cz has joined #openttd
05:34:42 *** LeandroL_ has joined #openttd
05:35:48 *** GriffinOneTwo has joined #openttd
05:44:40 *** Flygon_ has joined #openttd
05:56:15 *** Eddi|zuHause has joined #openttd
06:03:59 *** LeandroL has joined #openttd
07:16:13 *** sla_ro|master has joined #openttd
08:08:07 *** Progman has joined #openttd
08:12:33 *** andythenorth has joined #openttd
08:35:27 *** LeandroL_ has joined #openttd
09:01:26 *** Pensacola has joined #openttd
09:13:16 *** Alberth has joined #openttd
09:13:16 *** ChanServ sets mode: +o Alberth
09:19:50 <andythenorth> oh hello Alberth :)
09:20:52 <Alberth> trying to outsmart Python? :)
09:20:56 <V453000> got ships on rails yet?
09:21:24 <Alberth> a nice shipyard will do :)
09:21:24 <andythenorth> Alberth: PIL issues :P
09:21:36 <andythenorth> I wonder at the wisdom of making pixa a module
09:21:59 <andythenorth> rather than just having it be classes in the project
09:22:31 <andythenorth> the version of PIL that my project is calling loads images correctly
09:22:42 <andythenorth> but calls to pixa that wrap the same code fail with IO errors
09:22:46 <andythenorth> probably due to PIL
09:22:49 <andythenorth> I hate this stuff :)
09:24:33 <andythenorth> yeah, if I just move pixa from myvirtualenv/bin into my project src dir, everything works
09:24:56 <andythenorth> I wonder how much to bother doing it the right way
09:25:49 <andythenorth> the maintainability is broken if I move pixa into each project's repo
09:26:01 <andythenorth> but the deployability is significantly increased :P
09:26:23 <DorpsGek> Commit by fonsinchen :: r26265 trunk/src/smallmap_gui.cpp (2014-01-19 09:26:17 UTC)
09:26:24 <DorpsGek> -Fix: Don't rebuild the link graph overlay cache twice in a row
09:27:02 <DorpsGek> Commit by fonsinchen :: r26266 /trunk/src (3 files in 2 dirs) (2014-01-19 09:26:56 UTC)
09:27:03 <DorpsGek> -Fix [FS#5860]: Update smallmap overlay if player joins different company and make sure company masks are valid
09:27:28 <andythenorth> I assume having sub-repos is a frighteningly bad idea?
09:27:50 <DorpsGek> Commit by fonsinchen :: r26267 /trunk/src (order_base.h order_cmd.cpp) (2014-01-19 09:27:44 UTC)
09:27:51 <DorpsGek> -Fix [FS#5865]: Really fix the infinite recursion problem and always consider all branches of conditional orders as possible next stopping stations.
09:28:22 <Alberth> it's considered to be a "last resort" afaik
09:28:33 <Alberth> but there are a few sub-repos @ devzone
09:29:17 <andythenorth> pixa is a single .py file of classes and, and an init
09:29:30 <andythenorth> the maintenance is copy-paste :P
09:29:36 <andythenorth> wonder if I could symlink it ;P
09:31:37 <Alberth> makes it difficult for others to work in your repo
09:32:02 <Alberth> you could build a test to check whether a project has the latest version of pixa :)
09:32:05 <andythenorth> the plot thickens
09:32:21 <andythenorth> import Image <- imports ok, but the image loading fails
09:32:31 <andythenorth> from PIL import Image <- everything works
09:32:44 <andythenorth> so I have multiple installs of PIL somewhere
09:32:48 <andythenorth> some are probably evil
09:32:54 <Alberth> the latter is the recommended way of doing things, at least for Pillow
09:44:50 <Xaroth|Work> if you use "import Image" you're probably running a strange version of PIL
09:45:22 *** ChanServ sets mode: +v tokai
09:45:29 <andythenorth> my system is probably full of legacy PIL versions
09:45:40 <andythenorth> and virtualenv is not as isolated as I thought :P
09:46:06 <andythenorth> I wonder how long before most python devs are working in VMs :P
09:46:12 <andythenorth> seems to be the only sane solution
09:46:20 <Xaroth|Work> virtualenv works fine
09:46:31 <Xaroth|Work> there are just a few modules around that 'hack' their way around virtualenv
09:46:36 <Xaroth|Work> because they want to be smart or something
09:46:44 <andythenorth> nml breaks out of my virtualenv
09:46:48 <Xaroth|Work> PIL is one of them.. but Pillow works pretty good with it
09:47:50 <andythenorth> actually maybe nml is calling a version of PIL that breaks out of the virtualenv
09:47:58 <andythenorth> it got really boring when I tried to diagnose it ;P
09:55:26 *** Midnightmyth has joined #openttd
10:05:15 <planetmaker> andythenorth, if pixa is not updated properly for building the NewGRFs on the CF, please do tell. It *should* update upon push
10:05:40 <andythenorth> I think it's fine on the CF :)
10:05:54 <andythenorth> the CF doesn't have 5 different installs of PIL :P
10:05:59 <planetmaker> as to PIL/pillow. CF uses pillow afaik
10:06:21 <planetmaker> heck I even have a page which does tell :D
10:07:35 <planetmaker> python-imaging on debian is pillow iirc
10:09:16 <Xaroth|Work> PIL is deprecated anyhow
10:09:21 <Xaroth|Work> so people should stop using it :P
10:09:29 <planetmaker> hm, no. On wheezy it is still PIL
10:09:48 <planetmaker> testing and sid replace it by pillow only
10:09:58 <planetmaker> and yes, people should use pillow
10:14:27 <andythenorth> afaik I have pillow
10:14:40 <andythenorth> I cleaned everything up a few weeks ago when I got a new laptop
10:14:52 <andythenorth> but somewhere something is still calling PIL in some system python
10:15:03 <andythenorth> which would take most of the morning to fix :(
10:15:17 <andythenorth> so I'm cheating for now
10:15:19 *** skyem123 has joined #openttd
10:15:55 <andythenorth> skyem123: IH still fork-bombing your box? o_O
10:16:43 <skyem123> Haven't tryed it yet.
10:17:05 <skyem123> I managed to make it spit out the NML last night.
10:19:53 <skyem123> To answer your question: with some modifications i got the python code to output the nml
10:20:19 <skyem123> aka: no, it isn't fork-bombing.
10:30:10 *** Devroush has joined #openttd
10:30:45 <andythenorth> skyem123: did you turn the MP code back on?
10:32:45 <andythenorth> definitely won't fork bomb then :)
10:34:51 <skyem123> enabled the MP code.
10:35:02 <skyem123> now we can only wait...
10:39:34 <andythenorth> maybe someone better then me can fix it
10:40:43 <skyem123> Somehow, somthing makes it go back to the start of the whole program.
10:44:27 <planetmaker> yay, with proper transparent sprites, the animate water works again :D
11:06:30 *** Andreas has joined #openttd
11:09:06 *** tokai|mdlx has joined #openttd
11:17:11 *** frosch123 has joined #openttd
11:18:50 *** valhallasw has joined #openttd
11:40:56 *** andythenorth has joined #openttd
11:42:15 <andythenorth> skyem123: somebody who is better at python than me can probably spot what guarding needs to be added for Windows
12:02:48 *** Progman has joined #openttd
12:22:47 *** Aristide has joined #openttd
12:29:06 *** skyem123_ has joined #openttd
12:36:42 *** Djohaal has joined #openttd
12:39:54 *** gelignite has joined #openttd
12:40:30 *** skyem123_ has joined #openttd
12:41:59 *** skyem123_ is now known as skyem123
12:43:15 *** HerzogDeXtEr has joined #openttd
12:44:08 *** Andreas has joined #openttd
12:45:47 <frosch123> pasky comments are the best
12:47:30 <frosch123> every now and then you find one :)
12:47:32 <planetmaker> you mean source? :)
12:48:07 <frosch123> yeah, every few years you encounter some comment like "this could be improved --pasky", and you know that noone looked at that function for years :)
12:49:55 <frosch123> V453000: so we are back to zero?
12:50:31 <V453000> I suppose, I have no idea where could the desync be from but it looks like not newgrf related
12:50:56 <V453000> but I tried having many of the suspicious trains on the server, no desync happened
12:52:08 <V453000> will try again with a larger scale network, but hard to say
12:55:23 <planetmaker> nuts repo still is not updated :(
12:56:13 <frosch123> well, now V claims it also desyncs without nuts :)
12:56:32 <V453000> I know pm, my timetable is way too busy to be able to spend a day setting it up again
12:57:12 <V453000> it definitely desynced tonight without nuts ... if nuts could be additional cause in some obscure conditions, possibly? :d
12:59:28 <planetmaker> that setup would take 10 minutes. Alas.
12:59:59 <V453000> didnt look that way last time I tried
13:01:16 <fonsinchen> What kind of setup is that?
13:01:35 <V453000> some ssh thing to push with
13:02:35 <planetmaker> fonsinchen, just telling tortoiseHG to use a ssh key
13:03:13 <V453000> I was fiddling with some putty?
13:03:24 <fonsinchen> So, supposedly we need V453000's version of NUTS to reproduce the desync ...
13:03:58 <planetmaker> which incidentially doesn't necessarily exist anymore due to ceasing to use VCS at all
13:04:05 <fonsinchen> If he's not able to upload it to the repository, couldn't he just PM the file to someone who's willing to reproduce it?
13:05:34 <fonsinchen> Well, if you send it to me. I'll try to do something about it next weekend. I like elaborate descriptions on how to actually reproduce the desync.
13:06:55 <V453000> sure, can try ... thing is I ceased to have any clue about where the desync could come from
13:07:30 <V453000> I was suspicious that trains which change power based on cargo_loaded or what is the variable .... but after trying to buy dozens of those trains visiting stations all the tima nd loading/unloading, no desync happened
13:08:33 <fonsinchen> Do you have any kind of documentation of what you did last time the desync did happen?
13:09:11 <V453000> I did not see it personally, some person is saying that he reversed a train at PBS block, but was unable to reproduce it
13:09:23 <V453000> another says upon building a bridge, if there was a PBS is unknown
13:09:39 <planetmaker> desync doesn't happen upon an action necessarily.
13:11:07 <fonsinchen> Do we have saves of the games that triggered the desyncs?
13:11:26 <andythenorth> hrm, this pixa thing is overkill for just replacing colours in a sprite :D
13:11:26 <planetmaker> there's autosaves on servers
13:11:49 <fonsinchen> And can we nail down between which two autosaves the desync happened?
13:12:28 <Taede> yes, we keep timestamped logs
13:14:35 <fonsinchen> Then it should be possible to at least roughly quantify what kind of actions happened before the desync.
13:14:54 <fonsinchen> Of course if there were 10 people building at the same time that's hopeless.
13:15:13 <fonsinchen> But if the desync happened multiple times maybe there is a pattern somewhere.
13:15:43 <planetmaker> it's relatively easy to turn on desync debugging
13:16:27 <fonsinchen> From V453000 comment I read that it's hard to reproduce the desync on purpose, though.
13:16:43 <Taede> yes, but usually that happens after all the desyncs have happened
13:17:11 <fonsinchen> So maybe it's a good idea to look at the data we already have and try to narrow it down.
13:17:18 <planetmaker> fonsinchen, well, yes...
13:22:26 *** oskari89 has joined #openttd
13:24:32 <fonsinchen> I'll take a look at it. Right now I have to leave, though.
13:24:34 <Taede> 95.sav is 3 mins post-desync
13:25:02 <fonsinchen> Who experienced the desync?
13:25:19 <Taede> the bunched up quits at the bottom of the log
13:26:21 <Taede> Anson mentions there was at least one player left in the game, but i cannot confirm that
13:26:49 <planetmaker> Taede, can the quit reason be added to the logs?
13:27:12 <Taede> yes, kinda wondering why i didn't do that in the first place
13:27:56 <planetmaker> it's not a command
13:28:19 <Taede> easier to just do find desync
13:28:24 <Taede> instead of scrolling and looking
13:28:34 <V453000> pm: thanks, will attempt now
13:28:46 <planetmaker> or other strange things. Like 'strange packet received' :)
13:28:53 <planetmaker> (yes, that does exist)
13:29:01 *** FLHerne has joined #openttd
13:29:15 <Taede> or 'wrong companyID in commandpacket'
13:29:25 <Taede> soap can cause those in exceptional circumstances
13:30:05 <planetmaker> soap can *cause* them?
13:30:27 <Taede> moving players named player* to spectator when they start a company
13:30:43 <planetmaker> ah, yeah. But that's not soap's fault
13:30:50 <planetmaker> you can do that with rcon regardless
13:30:54 <Taede> starting a company takes (at least) 2 command packets im guessing, starting a company, and then setting default values
13:31:14 <Taede> and sometimes the rcon move to spectators gets processed before the 2nd command packet
13:31:39 <frosch123> gah, wagon overrides
13:31:44 <frosch123> BURN TTDPATCH BURN!
13:33:00 <frosch123> anyone uses wagon overrides with the can-wagon-be-attached callback?
13:33:09 <frosch123> anyone uses wagon overrides with articulated wagons?
13:34:21 <frosch123> should we just define the ottd behaviour as the correct one? and claim that no ttdp guy ever spend any thought on what is the correct behaviour?
13:34:49 <planetmaker> hm, sorry, can you explain a bit more? what kind of override and what's the problem exactly?
13:35:19 <planetmaker> oh, you mean the grfid override thing which we had a few years back even for 3 vehicles in base sets?
13:35:29 <frosch123> no, livery override
13:35:50 <frosch123> the deprecated thing :p
13:37:02 <planetmaker> and what's your suggested change?
13:38:33 <frosch123> for articulated part of train wagons (not engines) there is the difference that ottd uses the engine for the livery override, while ttdp uses the first articulated part
13:38:33 <planetmaker> also NML offers livery overrides, so it likely will be used
13:39:16 <planetmaker> you likely want the engine, yes
13:39:34 <frosch123> but given that all trainsets which use articulated parts for wagons are likely designed for ottd, i would rather expect to break stuff when changing ottd behaviour to ttdp
13:40:10 <frosch123> the more weird case is callback 1d (can wagon be attached)
13:41:56 <frosch123> it uses the action3 of the engine, while all the variables refer to the wagon
13:42:24 <frosch123> ottd and ttdp agree that the action3 should use the cargo type of the wagon
13:43:05 <frosch123> ottd never applies wagon overrides though, while in ttdp i am not sure yet whether it applies them always, never or randomly :p
13:45:00 <frosch123> ok, i guess i can classify this as ttdp bug
13:45:19 <frosch123> no normal grf would trigger the case where ttdp would apply wagon overrides
13:46:26 <planetmaker> path=ssh://hg@hg.openttdcoop.org/nuts
13:46:40 <planetmaker> default-push=ssh://hg@hg.openttdcoop.org/nuts
13:47:12 <planetmaker> no idea why there's line NUTS=...
13:48:14 <V453000> I guess I need to send you some key now?
13:48:49 <Eddi|zuHause> i would use the "normal" checkout path and the ssh path only for push
13:48:54 <planetmaker> you can also paste on irc
13:49:02 <Eddi|zuHause> otherwise you need to enter pasword for every pull
13:50:22 <V453000> it sez public key for pasting...
13:50:31 <V453000> ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAsoEAblsEQzzTM7rT9SeLQkB6FUgieK5YVEeWEWwW+xpUqR6xuvi4DDLahKmQoEqFN9QCVAm4mt8sA0uU6r810hNe3Z91pTRHBTIWzIcWoPUD0AKSrAuti8FM3f9lHQnFK8WC9KGVw1HV+rrTwQS2BDBfXhIuSCt6i6vmAHSl+38= rsa-key-20140119 ? :D
13:50:53 <planetmaker> V453000, the thing shown in the image 5.7
13:51:37 <V453000> yeah the long thing, that is where it is from
13:52:54 <V453000> bundling 24/52 files? :D
13:53:34 <planetmaker> let's hope it actually pushes successful :P
13:55:25 <planetmaker> right. you added some file which usually shouldn't be added. I'll disabled the hook temporarily. Try again
13:55:40 <planetmaker> probably some temporary file, the grf itself or so
13:55:47 <planetmaker> there's sanity checks ;)
13:56:06 <V453000> thought that is in some hgignore buuuut trying again
13:58:05 <Alberth> hgignore doesn't prevent you from adding a file, it just suppresses printing it as "untracked"
13:59:11 <planetmaker> strange enough I don't see a bad file
14:00:05 <planetmaker> added 5 months ago :P
14:00:13 <V453000> WTF are the orig files anyway :D
14:00:19 <V453000> guess I should delete those?
14:00:21 *** oskari892 has joined #openttd
14:00:23 <planetmaker> editor backup files
14:00:36 <Alberth> or patch merge backup files
14:01:04 <V453000> I have some PSD files which are both source-helpful, or just for wiki ... should I push those too?
14:01:27 <V453000> (at least two I see have 80MB each)
14:02:10 <V453000> wagon stuff with many layers :d
14:02:16 <planetmaker> if you use them to create stuff, add them
14:02:39 <V453000> now I am happy it works (: thanks for your help
14:02:53 <planetmaker> if it's more general, wiki might be more appropriate. dunno :)
14:03:44 <V453000> two are general (the engine table graphic), and then there are some psd files to create the shipz
14:03:59 <V453000> it will take time to upload so I will do that later :)
14:06:43 <V453000> well, there is your source fonsinchen :P
14:07:12 <planetmaker> -rw-r--r-- 1 pm pm 83M Jan 19 15:05 terrain_32bpp.xcf
14:07:40 <Alberth> bitmaps in xml format? :D
14:11:30 <planetmaker> bitmap in xml? where?
14:16:19 <frosch123> "xtra cool format" or so
14:16:46 *** FLHerne has joined #openttd
14:17:07 <frosch123> hmm, actually, the real meaning is way better than my lame joke
14:17:19 <frosch123> "eXperimental Computing Facility" <- wtf
14:17:53 <planetmaker> probably someone toyed and no-one could bother to make a proper name
14:19:38 *** Pensacola has joined #openttd
14:27:18 <frosch123> haha, neve noticed those busses
14:27:28 <frosch123> they almost have more windows on the back than at the sides
14:27:47 <V453000> they mainly take the whole road :d
14:28:11 <planetmaker> yes, one window less wide would do, too.
15:00:27 *** oskari89 has joined #openttd
15:47:47 *** fjb is now known as Guest4249
16:00:00 *** andythenorth has joined #openttd
16:00:27 *** oskari892 has joined #openttd
16:04:04 *** FLHerne has joined #openttd
16:27:07 *** tokai|noir has joined #openttd
16:27:07 *** ChanServ sets mode: +v tokai|noir
16:28:38 <andythenorth> it's kind of working
16:36:15 <andythenorth> I feel bad that I have ignored most of pixa
16:36:26 <andythenorth> and written my own 4 line function :P
16:40:49 <FLHerne> Does NML have constants for fence sprites, or do I have to look them up somewhere?
16:41:18 <Eddi|zuHause> i'd look at opengfx
16:45:12 <FLHerne> The browsing script seems to be borked. 504s.
16:46:34 <planetmaker> fence sprite numbers should be found in ogfx+landscape company land
16:47:52 <planetmaker> oh... haven't seen that URL in a long time
16:48:34 * FLHerne looks at OGFX+ instead
16:48:51 <FLHerne> planetmaker: Well, it's on the OGFX project page
16:50:29 *** Djohaal_ has joined #openttd
16:50:56 <FLHerne> Thanks for the tip, the fence-handling stuff there is almost exactly what I needed :-)
16:52:06 <planetmaker> I actually wonder which server mz redirected to :D
16:56:01 <FLHerne> The dev one 404s for me, the mz one 504s :P
16:56:22 <planetmaker> yes. I actually meant to try that URL instead of pasting it here :D
17:00:33 *** oskari89 has joined #openttd
17:09:44 *** tokai|mdlx has joined #openttd
17:19:28 <andythenorth> I have some code that makes a cheatsheet from a sprite sheet
17:19:39 <andythenorth> it magnifies each pixel, and writes the colour index number on it
17:19:45 <andythenorth> the magnification is 30x...
17:20:01 <andythenorth> I just accidentally made a 1GB png :P
17:28:49 *** nicferirc has joined #openttd
17:30:50 <nicferirc> I can't run openttd 1.4.0b2 under xubuntu 13.10, I get an error about libsdl-1.2.so.0 missing even if I have installed the package
17:46:19 <Pikka> 32bpp sprites should be rendered on a transparent background. Why am I only just now realising this? :D
17:47:42 <Pikka> did you post on the forums, nicferirc? you'll get a larger audience there.
17:48:41 <peter1138> lies, pikka doesn't make 32bpp sprites
17:48:52 <Pikka> is it that I don't, peter1138?
17:49:30 <planetmaker> hihi, Pikka :) Did you have nice white or blue slabs on the screen?
17:49:39 <planetmaker> (been there, seen that)
17:50:24 <Pikka> I'm glad to say it occurred to me before I got that far. :P
17:50:51 <planetmaker> well. changing white to transparent is one click and one ctrl+x
17:50:53 <Andreas> Pikka, is that the beginning of a new set of intended as part of some other set?
17:51:10 <Pikka> only if all the transparent areas are contiguous, planetmaker
17:51:18 <Andreas> looks nice byt the way :)
17:52:06 <Pikka> new set(s), Andreas. and thanks.
17:52:35 <planetmaker> Pikka, no. colour select white and then cut
17:52:53 <Pikka> but what if there are white pixels on the vehicle? :D
17:53:02 <planetmaker> they should not be there anyway
17:53:15 <planetmaker> should be slightly not white
17:53:42 <planetmaker> transparent looks funky though :D
17:53:49 <Andreas> how do they look on normal zoom levels Pikka? (some 32bpp grfs look great zoomed in, but not so great on normal zoom)
17:54:27 <Pikka> not too bad. at least, not too bad when I render them at normal zoom sizes...
17:56:45 <Andreas> just have to wait and see I guess :)
18:00:42 *** oskari892 has joined #openttd
18:01:08 <__ln__> anyone working on Oculus VR support for openttd yet?
18:02:20 <FLHerne> __ln__: Trying to look at a dimetric projection in 3D would hurt your head :P
18:04:47 <Pikka> it wouldn't, it would just be not 3d. :P
18:10:47 *** andythenorth has joined #openttd
18:11:42 <FLHerne> With OTTD's restricted camera angles, yes
18:12:16 <planetmaker> especially as my screen still is flat
18:12:50 <FLHerne> But if you had 3D models, you could have projections from slightly different angles for each eye?
18:13:55 <Eddi|zuHause> i'm sure google can create 3D models from flat images
18:14:42 <frosch123> yup, chuck norris is working there
18:15:13 <planetmaker> well, it's not magic. It can be done to some degree
18:15:37 *** retro|cz has joined #openttd
18:21:55 *** valhallasw has joined #openttd
18:35:18 *** andythenorth has joined #openttd
18:45:23 <DorpsGek> Commit by translators :: r26268 /trunk/src/lang (danish.txt unfinished/persian.txt) (2014-01-19 18:45:16 UTC)
18:45:24 <DorpsGek> -Update from WebTranslator v3.0:
18:45:25 <DorpsGek> danish - 50 changes by Elyon
18:45:26 <DorpsGek> persian - 1 changes by rey
19:00:48 *** oskari89 has joined #openttd
19:14:16 *** andythenorth has joined #openttd
19:22:37 *** eQualizer has joined #openttd
19:35:24 *** DarkAce-Z has joined #openttd
19:43:57 <andythenorth> is this formatting ugly?
19:44:10 <andythenorth> I don't like that it's not obvious what is a param, and what is a dict pair
19:44:46 <andythenorth> I could compose the dict before the object creation call, but I have been trying to teach myself to declare less stuff, and do more inline
19:47:14 <Alberth> I make a temp variable for such cases
19:47:46 <andythenorth> temp = {blah: blah, blah: blah}
19:49:25 <Alberth> also gives you more room at line, so less wrpping
19:57:26 <Alberth> the graphics_template may be a bit overkill
19:59:41 <andythenorth> 1 abstraction too far?
20:00:46 <Alberth> it's a matter of personal taste
20:00:56 *** oskari892 has joined #openttd
20:01:04 <Alberth> also it depends on how often you expect to change the string
20:01:39 <andythenorth> that's what find and replace is for :)
20:02:08 <andythenorth> I've removed that
20:02:21 <Alberth> I usually try to rely on having one source :p
20:03:22 *** DanMacK has joined #openttd
20:08:04 *** Supercheese has joined #openttd
20:10:21 <andythenorth> DanMacK: look, a pikka!
20:10:42 <andythenorth> over there, on the stair
20:33:12 *** KritiK_ has joined #openttd
20:38:51 *** KritiK_ is now known as KritiK
20:49:34 *** retro|cz has joined #openttd
21:07:25 <andythenorth> is it acceptable to dump constants into __init__.py for a module?
21:07:32 <andythenorth> it's not worth fucking around with a constants.py imgo
21:25:24 *** Midnightmyth has joined #openttd
21:48:13 <Eddi|zuHause> andythenorth: might get you into trouble if you use these constants within the sub-modules
21:48:36 <andythenorth> what can go wrong?
21:48:44 <andythenorth> besides naming colissions?
21:48:45 <Eddi|zuHause> andythenorth: circular includes
21:48:56 <andythenorth> collision is a hard word to spell :P
21:49:13 <andythenorth> Eddi|zuHause: presumably I'll notice if that happens? o_O
21:50:45 <andythenorth> hmm so this would be the case where I have a constant in __init__.py for graphics_processor module
21:50:56 <andythenorth> so I use it as graphics_processor.CC1
21:51:01 <Eddi|zuHause> andythenorth: well python happily supresses circular includes without warnings, so only items before the include will be processed until after both modules are initialised
21:51:02 <andythenorth> which means I have to import graphics_processor
21:51:18 <andythenorth> so if I import graphics_processor to a submodule of graphics_processor, bad happens?
21:52:32 <andythenorth> should I just make a constants file? It's a well established pattern...
21:52:46 <Eddi|zuHause> if __init__ imports a module, and that module imports __init__, that module cannot see any constants that are after the __init__'s import
21:54:30 <Eddi|zuHause> basically import checks the three states: "already initialized"->use that, "currently initializing"->do not recurse, "not initialized"->start initalization now
21:55:02 <Eddi|zuHause> a "constants" file sounds like a way better approach
21:55:15 <Eddi|zuHause> circular includes are an anti-pattern
21:55:44 <Eddi|zuHause> means your modules are not isolated enough
21:55:54 <Eddi|zuHause> so either merge them or refactor them
21:57:02 *** DarkAce-Z is now known as DarkAceZ
21:57:09 <andythenorth> moved to constants file
22:05:56 <andythenorth> Eddi|zuHause: if you wanted a fun challenge, you could figure out why my multiprocessing code forkbombs on windows :)
22:06:07 <andythenorth> I know I'm doing it wrong, it's a known issue for python MP
22:06:18 <andythenorth> but I don't understand how to implement the standard fix
22:07:46 <andythenorth> but also bed time :)
22:07:47 *** andythenorth has left #openttd
22:17:37 <Eddi|zuHause> ... that's why i use make's multiprocessing instead of python's...
22:53:46 *** Aristide has joined #openttd
23:12:59 *** Hazzard has joined #openttd
continue to next day ⏵
