IRC logs for #openttd on OFTC at 2012-02-17
⏴ go to previous day
01:48:21 <Nat_as> Hmm, here's a question
01:48:36 <Nat_as> is there any way to limit the maximum framerate when in fast forward mode.
01:48:52 <Nat_as> because on a fast computer that feature can be a problem, it goes too fast.
01:49:37 <Nat_as> it used to be you could sort of adjust it by turning full animation and full detail on and off, but now it does not seem to have an effect on framerate
01:50:13 <Nat_as> on my netbook fast forward is handy, but on my big gaming rig time progresses too fast.
01:54:36 <glx> fast forward uses as much cpu as it can (it removes all limits)
02:00:49 <Nat_as> yeah, i understand that, but if there was a way to make the game go faster without going into maximum overdrive that would be cool
02:00:54 <Nat_as> esp on modern computers
02:08:08 <Elukka> it's not a problem for most people know as far as i can tell, but it is one that is sure to become one in the future
02:08:20 <Elukka> would be nice to have a dropdown menu on it maybe
02:08:33 <Elukka> with a couple different speeds and also a max speed option
02:08:39 <Elukka> (no, i am not going to code this)
02:18:05 <Nat_as> it's something that will become more and more of a problem as mores law progresses
02:18:31 <Nat_as> right now it's only a problem for people who like to play retro games on nice computers
02:18:46 <Nat_as> on the other hand I laugh at people who have FPS issues in Dwarf fortress
03:48:57 *** LiteralKa has joined #openttd
03:49:05 *** LiteralKa has left #openttd
04:07:32 *** supermop has joined #openttd
04:38:02 *** cmircea has joined #openttd
05:11:51 *** tokai|mdlx has joined #openttd
05:20:34 *** Stimrol_ has joined #openttd
05:56:23 *** Eddi|zuHause has joined #openttd
06:14:14 *** kkb110_ has joined #openttd
06:20:42 *** tokai|noir has joined #openttd
06:20:42 *** ChanServ sets mode: +v tokai|noir
06:20:45 *** Firartix has joined #openttd
06:42:50 *** JVassie has joined #openttd
07:09:44 *** Progman has joined #openttd
07:14:47 *** TGYoshi has joined #openttd
07:20:01 *** sla_ro|master has joined #openttd
08:03:01 *** Zeknurn has joined #openttd
08:12:58 <dihedral> Rubidium, thanks :-)
08:21:35 *** DayDreamer has joined #openttd
08:24:01 *** DayDreamer1 has joined #openttd
09:21:41 <peter1138> anyone au fait with c#, threads and locking?
09:21:54 *** theholyduck has joined #openttd
09:23:45 *** Eddi|zuHause has joined #openttd
09:43:38 *** FLHerne has joined #openttd
09:46:59 *** Xaroth_ has joined #openttd
10:02:04 *** Markavian` has joined #openttd
10:10:50 *** chester has joined #openttd
10:17:47 *** Xaroth_ is now known as Xaroth
10:28:03 *** tokai|mdlx has joined #openttd
10:30:32 <planetmaker> ha, finally, the Bundespräsident resigned.
10:30:44 <Eddi|zuHause> took him long enough...
10:30:55 <planetmaker> yep. at least 6 weeks too long
10:31:15 <planetmaker> oh, welcome back, Eddi|zuHause :-)
10:31:35 <Eddi|zuHause> at least 2 full months...
10:31:39 * MNIM congratulates Eddi|zuHause.
10:32:45 <MNIM> well, for the loss of your bundesprasident. (excuse my lack of umlaut. not using US-int)
10:33:11 <Eddi|zuHause> it's more planetmaker's president than mine :p
10:33:39 <planetmaker> oh, he was never mine
10:33:53 <Eddi|zuHause> well, but he was from niedersachsen :p
10:34:01 <planetmaker> Can't say I voted for him there either ;-)
10:34:21 *** ChanServ sets mode: +v tokai
10:34:57 <planetmaker> I kinda always had the impression that he plays in the Robert Koch liga
10:37:06 *** tokai|noir has joined #openttd
10:37:06 *** ChanServ sets mode: +v tokai|noir
10:37:42 *** andythenorth has joined #openttd
10:46:22 <Eddi|zuHause> my estimate is that the government won't risk another "close" election and instead pushes for a "common" candidate over all "democratic" parties
10:47:09 <Eddi|zuHause> by the numbers on that page, the government would only have a 2-4 vote (absolute) majority
10:47:38 <Eddi|zuHause> and they had problems the last time with a ~40 vote majority
10:48:33 <Eddi|zuHause> "democratic parties" is conservative code for "not the left" :p
10:50:20 <planetmaker> nor the ultra-right
10:50:55 <Eddi|zuHause> yes. but there's a difference between 3 votes an 125 votes...
10:51:12 <DorpsGek> planetmaker: 41.6666666667
10:51:19 <planetmaker> about a factor of 42 :-P
10:53:40 <TrueBrain> Pi = 3 = 2 = 1, so meh, its nothing
10:54:36 <planetmaker> but only for small pi
10:56:07 <Eddi|zuHause> well, you can make pi smaller by eating some
10:58:10 <planetmaker> TrueBrain, the validity of the statement "1 = nothing" highly depends on the operation ;-)
10:58:43 <TrueBrain> 1 = nothing is just silly
10:58:52 <TrueBrain> we are not in the business of making nothing :)
11:29:01 <Eddi|zuHause> the most obscure suggestion i heard today: "they should make sarkozy the german president, because merkel likes him so much, and his reelection in france is questionable" :p
11:39:55 *** roboboy has joined #openttd
11:42:23 *** lofejndif has joined #openttd
11:49:56 <Eddi|zuHause> hm... operator priority/semantics: wth does a line like this do? Command & c = *current_cmds.top().cmd;
12:00:00 *** kkb110_ has joined #openttd
12:04:25 *** Rhamphoryncus has joined #openttd
12:20:13 <michi_cc> Eddi|zuHause: Both operators . and () have the same higher precedence than operator *, and . () are left-to-right associative.
12:20:31 <Eddi|zuHause> so * is applied at the end?
12:20:52 <michi_cc> If the compiler works according to the precedence rules, yes :)
12:22:02 <michi_cc> This is the same reason why you can't dereference a 'std::vector<struct A *>::iterator i' by doing *i->aa, but have to do (*i)->a.
12:23:56 <Eddi|zuHause> sure. if you know the priorities, this is probably all very logical :)
12:48:09 *** mahmoud has joined #openttd
12:59:51 *** lofejndif has joined #openttd
13:46:19 *** Phoenix_the_II has joined #openttd
13:56:52 *** roboboy has joined #openttd
14:13:32 *** tokai|mdlx has joined #openttd
15:06:46 <Ammler> someone able to use the 64bit linux nightlies?
15:10:14 <Ammler> is it useful to count the time for password input for joining too?
15:14:05 <dihedral> you want me to test?
15:15:57 *** |Jeroen| has joined #openttd
15:16:38 <Ammler> I am on it right now :-)
15:17:07 <Ammler> join ps and wait too long for pw input
15:17:12 <Ammler> then the server crashes
15:17:34 <Ammler> ah, you mean the 64bit binary?
15:17:41 <Ammler> that would be neat, indeed
15:18:29 <Ammler> hmm, this time, server stays up
15:18:55 <Ammler> anyway, why is the input time also part of the joining time?
15:19:07 *** HerzogDeXtEr has joined #openttd
15:28:17 <Rubidium> Ammler: because there can only be so many conections, and it's pretty easy to write something that connects N times, goes through all the steps to get the request for the password and then nothing but starving the server
15:28:25 <krinn> TrueBrain, i found my AI error, i've put the infos on the bugreport
15:29:05 <krinn> it's a bad recursive call, the VM/openttd goes oom and crash
15:29:26 <Rhamphoryncus> Rubidium: which you can do regardless
15:29:52 <Rhamphoryncus> And given how tight the map download timeout is to begin with it'd make sense to at least have a separate timeout for password entry
15:30:10 <Rubidium> Rhamphoryncus: what makes you think they are related?
15:30:13 <Ammler> well, we can rise the timeout
15:30:31 <Rhamphoryncus> Rubidium: that was my impression. I could be wrong of course.
15:30:55 <Ammler> Rubidium: they are just tested
15:31:11 <Rhamphoryncus> And I've hit the password timeout because I checked the IRC channel for it after it asked me for the PW. It's obviously a very short timeout
15:31:33 <Rubidium> IIRC it's 30 seconds per password
15:34:06 <dihedral> would it then not make sense to require passing the password in the join packet?
15:34:13 <Ammler> ok, they aren't, but that changed somehow too the last year, right?
15:34:31 <dihedral> it is alreayd known that the passwords (server and/or company) are needed
15:34:52 <Rhamphoryncus> dihedral: indeed. The server could say "connection refused; password needed" and the client could behave to the user just the same as before
15:35:21 <Ammler> I am sure, I had a lot more time to input the password before
15:35:28 <dihedral> the client would behave the same way, just postponing sending the join packet until the user has entered both passwords
15:35:46 <Rubidium> Ammler: you had infinite time, which makes starving the server easy
15:36:08 <Rubidium> and someone actually did starve a server so it was more than time to do something about it
15:36:23 <Ammler> so, if I get the input password mask nobody else was able to join that time?
15:36:38 <Rubidium> no, someone else can join
15:37:13 <Rubidium> *but* if I open 255 OpenTTDs and let them join and let them wait while I do not enter a password, then nobody can join
15:37:26 <Rubidium> as amount of players and such is checked *before* the password
15:37:50 <dihedral> Ammler, enable per IP max connections in iptables :-P
15:38:08 <Rubidium> ofcourse I don't need to open OpenTTD for that, just need to write a small script that does that
15:38:20 <Ammler> ah ok, well the crash at first time was something else, I wouldn't have rised this question without :-)
15:38:23 <dihedral> and then xargs it ^^
15:38:46 <FLHerne> Ammler: I have 64 bit Linux, what needs testing in the nightly?
15:39:18 <Ammler> do you use the generic nightlies from openttd?
15:39:45 <FLHerne> Not normally, but I can get them...
15:40:13 <Ammler> yes, those do not work here, can you confirm? :-)
15:40:53 <krinn> you mean nightly linux openttd doesn't compile or run ?
15:41:22 <Ammler> krinn: no, the generic nightlies from openttd.org do not work here
15:41:47 <Ammler> if I build self, I have working bins
15:41:48 <dihedral> i can start the copy i just downloaded - 'does not work here' might have to be more detailed ;-)
15:42:04 <krinn> Ammler, oh you mean the binaries so ?
15:42:22 <Ammler> yes, how else do you get 64bit from openttd.org?
15:43:12 <krinn> well, openttd.org provide source, and you can build it 64bits, that's why i ask binaries ones or not
15:43:15 <Ammler> well, it does not complain about mising lib or so like before
15:43:42 <dihedral> krinn, the source is not 64bit ;-)
15:44:28 <Rubidium> Ammler: I guess it's caused by some library that you updated locally
15:44:31 <Rubidium> no clue which one though
15:44:45 <Ammler> bash: ./openttd: cannot execute binary file
15:44:55 <Ammler> that's the whole output
15:45:06 <Rubidium> and what does ldd and file say?
15:45:26 <FLHerne> Seems to work - starts, generates map, plays...
15:45:29 <Ammler> not a dynamic executable
15:45:45 <FLHerne> Kubuntu 11.10, x86_64
15:46:03 <dihedral> Ammler, sure you got the 64bit version?
15:46:14 <krinn> linux will also tell you that if you try running a 32bits binary with a 64bits kernel without 32bits support
15:46:45 <dihedral> krinn, ubuntu will tell you that
15:47:04 <Ammler> dihedral: the path does hopefully confirm that ;-)
15:48:10 <Ammler> someone non ubuntu here?
15:48:52 <Rubidium> are you really running a 64 bits operating system?
15:48:53 <krinn> did you try "file openttd" ?
15:50:05 *** Illegal_Alien has joined #openttd
15:50:38 <Ammler> installing SDL-devel and try to build
15:50:53 <Ammler> this is a very young system :-)
15:51:20 <krinn> just do file openttd it will tell you the loader need on it
15:51:50 <Ammler> could it be, I used the wrong suse image last time I installed :-D
15:51:53 <krinn> openttd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x5a963baca627e5e01417294914812963f32a8266, stripped
15:51:53 <krinn> (that's the 1.1.5 amd build) i don't know where u get the nightly
15:52:58 <Ammler> let us come back to the password timeout issue :-P
15:53:20 <dihedral> Ammler: you are more amusing than my worst clients :-P
15:53:27 <dihedral> i do not believe this :-P
15:54:07 <Ammler> well, when do you check arch of a installed system, when you are used to use 64bit there?
15:54:28 <dihedral> is it YOUR computer?
15:54:39 <FLHerne> What is the password timeout issue? If I know, I can come back to it :-)
15:54:42 <Ammler> ah, let us speak about timeout
15:54:44 *** kais58_ has joined #openttd
15:55:16 <Ammler> this 64bit issue was just because I wanted to test the timeout
15:56:02 <Ammler> hmm, I might just stay with 32bit, should not hurt
15:56:49 <Ammler> oh, it does, memory is gone too :-)
15:57:26 <Ammler> what a stupid idea it was to install from that live image
15:57:53 <Ammler> seems like it just copied the content
16:02:18 *** TWerkhoven has joined #openttd
16:06:53 * andythenorth ponders procedurally generating stuff
16:07:00 <andythenorth> like the work I'm supposed to be doing
16:07:20 <andythenorth> for i in day.hours(): do_stuff
16:56:58 *** Devroush has joined #openttd
17:12:53 *** supermop has joined #openttd
17:16:30 *** sla_ro|master has joined #openttd
17:32:10 *** HerzogDeXtEr1 has joined #openttd
18:01:10 *** Alberth has joined #openttd
18:01:10 *** ChanServ sets mode: +o Alberth
18:04:42 *** Firartix has joined #openttd
18:27:42 *** kkb110_ has joined #openttd
18:37:52 *** Matulla has joined #openttd
18:38:21 <Matulla> hi all what happens in a city when i press generate new homes
18:38:43 <Matulla> can i press this more then once a year
18:39:19 <Alberth> SE = the scenario editor
18:39:35 <Matulla> no in the running game
18:39:37 <Eddi|zuHause> Matulla: it speeds up city growth and ignores the water/food requirement for some time
18:39:53 <Eddi|zuHause> Matulla: it is usually not helpful to do this more than once
18:40:12 <Alberth> it's a good way to spend your money :p
18:40:39 <Matulla> i got now money enoph after 30 game years
18:40:40 <Eddi|zuHause> Matulla: you can usually see when the effect wears off when the pavements change
18:41:50 <Eddi|zuHause> they should have railways in widelands... :p
18:41:51 <Matulla> i never saw a pavements yet i need to zoom in
18:42:17 <Matulla> sometimes there are post appearing if i press advertise
18:43:54 <Matulla> is there more effect at transportation higher then 90%
18:44:06 <Alberth> Eddi|zuHause: trains moving back and forth :)
18:45:03 <Eddi|zuHause> Matulla: station rating of 90% means you get 90% of the cargo produced nearby
18:45:10 <Matulla> and is this a bug when the message comes up production down at a 91% deliver rate
18:45:51 <Matulla> Eddi|zuHause: not the station rate the plant rate
18:45:57 <CIA-1> OpenTTD: translators * r23961 /trunk/src/lang/ (8 files): (log message trimmed)
18:45:57 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:57 <CIA-1> OpenTTD: belarusian - 6 changes by KorneySan, Wowanxm
18:45:57 <CIA-1> OpenTTD: catalan - 16 changes by arnau
18:45:57 <CIA-1> OpenTTD: croatian - 6 changes by VoyagerOne
18:45:58 <CIA-1> OpenTTD: dutch - 2 changes by Parody
18:45:58 <CIA-1> OpenTTD: finnish - 1 changes by jpx_
18:48:13 <Matulla> is this a must to get a company town
18:49:46 <Matulla> the place where the company is homed
18:50:01 <Eddi|zuHause> you can build that from your company window
18:50:14 <Eddi|zuHause> click the face icon in the menu bar
18:50:17 <Matulla> do i need to put this on i know that there is somthing but i never did that
18:50:30 <Eddi|zuHause> you don't need one
18:50:42 <Eddi|zuHause> it just looks pretty, and produces some passengers
18:54:01 <Alberth> hmm, it is not even used in the town rating :)
18:55:26 <Matulla> Thanks i will fil up all the tiles (almost) of my map
18:56:23 <Matulla> last question can a bigger airport only be build on the smaler one place
18:56:36 <Matulla> with same station name
18:56:58 <Alberth> size has nothing to do with it
18:58:01 <Alberth> it needs to be "close enough" to the old station, that's all
18:58:08 <Matulla> i tryed to get a bigger one on the othe end of the town by removing the smaler on e and it did not work maybe thrue to not enoph points to the town athoryty
18:58:55 <Matulla> it gave me a other station name and now i trevel by train to the airport
18:59:09 <Alberth> 'the other end of the town' sounds too far away
19:00:03 <Matulla> ok no factor just a guess
19:00:04 <Alberth> the old station name gets lost if you wait too long with building a new station
19:00:33 <Matulla> if you got planes in the air you cant wait to long
19:01:13 <Alberth> yeah, it's always a lot of stress to get the airport replaced
19:08:37 *** peteris has joined #openttd
19:13:52 <Alberth> woow, 130M for widelands :)
19:15:35 *** andythenorth has joined #openttd
19:18:37 * andythenorth unusually agrees 100% with oberhumer
19:22:02 *** lofejndif has joined #openttd
19:26:28 <andythenorth> the answer is not on FB or BBC news
19:26:34 <andythenorth> is there more internets I should look on?
19:33:41 <Alberth> depends on the question
19:34:43 *** frosch123 has joined #openttd
19:35:06 <Alberth> oh, download a random game, and try to figure out how to play it
19:35:10 <andythenorth> I should have made that procedural
19:35:28 <andythenorth> { 'frosch123' : ['quak','quak','quak']}
19:36:02 *** Linnefer has joined #openttd
19:36:45 <Linnefer> I have a question concerning instalation of openTTD without TTD
19:37:06 <Linnefer> where do the open gfx etc belong?
19:37:26 <frosch123> depends on your os and the version of ottd
19:37:43 <frosch123> the readme is linked on the download page
19:37:58 <Alberth> I had it book marked :)
19:38:01 <frosch123> ^^ that's for 1.2.0 only
19:38:18 <frosch123> 1.1 has a different location
19:38:54 <Linnefer> I have 1.1.5if I read that right
19:39:23 <frosch123> then you need to put it into the "data" folder instead of the "baseset" folder (compared to 1.2)
19:40:06 <Linnefer> just all the open gfx/music/sounds to that?
20:10:11 *** mikegrb has joined #openttd
20:10:11 *** TinoDidriksen has joined #openttd
20:11:06 *** break19 has joined #openttd
20:11:06 *** confound has joined #openttd
20:11:06 *** Maarten has joined #openttd
20:11:06 *** Rubidium has joined #openttd
20:11:06 *** graviton.oftc.net sets mode: +ov Rubidium Rubidium
20:12:20 *** ChanServ sets mode: +v Alberth
20:12:20 *** ChanServ sets mode: +v Belugas
20:12:20 *** ChanServ changes topic to "1.1.5, 1.2.0-beta4 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | Don't ask to ask, just ask | 'Latest' is not a valid version, ever | English only"
20:12:20 *** ChanServ sets mode: +o planetmaker
20:12:20 *** ChanServ sets mode: +v orudge
20:12:20 *** ChanServ sets mode: +v Terkhen
20:12:20 *** ChanServ sets mode: +v SmatZ
20:19:46 <Zuu> The title game vote is hard this year. Many good contributions.
20:22:38 <planetmaker> agreed. I'm quite happy about that
20:22:48 <planetmaker> but I haven't made up my mind so far either
20:23:10 <Zuu> I have made my list of 3 now but have changed their order a few times.
20:23:38 <Zuu> You are brave that take votes by user names and not entry numbers.
20:33:06 <frosch123> did fred submit this year?
20:44:24 <Alberth> dict(('andythenorth' : 'the approach works out very nicely, I must say'.split()))
20:44:58 *** Firartix has joined #openttd
20:45:00 <Alberth> hmm, s/:/,/ of course :(
20:45:10 <andythenorth> it's quite simple so far
20:45:28 <andythenorth> I could add more detail to lighting / shading with almost no work
20:45:28 <Alberth> yeah, quite surprisingly
20:45:43 <andythenorth> what's interesting is whether I need more floor plans for different truck types
20:45:47 <andythenorth> might be simplest
20:46:20 <Alberth> I was wondering whether you'd need a line drawing routine, but apparently not
20:48:58 <Rubidium> frosch123: doesn't seem like he did :(
20:50:13 <frosch123> i wonder whether someone resubmitted a save from the previous years .p
20:52:04 <Alberth> look at the game logs :)
20:52:54 <Eddi|zuHause> the images from the previous years are archived?
20:54:19 <Rubidium> yes, though not further back that 1.0 :(
20:56:12 <Rubidium> is SCO still not bankrupt? :(
20:56:15 <andythenorth> Alberth: it's a dumb sort of line routine
20:56:23 *** FLHerne has joined #openttd
20:58:45 <Eddi|zuHause> Rubidium: we didn't have title game contests before 1.0
21:08:45 <andythenorth> Alberth: if you're looking for a project, I still have to figure out how to render each set of angles, then write them out to the correct location in a new file ;)
21:09:14 <andythenorth> 1 input file = lots of rows of sprites for different load states, body styles
21:10:07 <Eddi|zuHause> there's not much point of a generator if you have to input the same number of images that you get out
21:13:45 <andythenorth> that would be more of a transformer :P
21:14:01 <andythenorth> it's akin to building ikea furniture from a flat pack :P
21:14:15 <Terkhen> why do you need an image generator?
21:14:34 <Alberth> that's a negative generator, if all goes well. It goes from many to 1 piece :)
21:14:51 <Alberth> Terkhen: people are lazy :)
21:15:18 <Terkhen> I reckon that the effort that the generator would take would be better spent in creating images
21:15:35 <Eddi|zuHause> Terkhen: the idea was "truck trailers mostly look alike, just have different length"
21:15:36 <andythenorth> Terkhen: would you like to draw for BANDIT? :)
21:15:56 <Terkhen> nope, as I usually say, I couldn't draw to save my life
21:16:05 <andythenorth> you can draw these trailers
21:16:15 <andythenorth> they're just a regular pattern, with tweaks for lighting
21:16:29 <andythenorth> I considered paying someone on amazon turk to do it :P
21:17:44 <Alberth> what's this "render each set of angles, then write them out to the correct location in a new file" ?
21:18:29 <Alberth> don't you do that already?
21:19:20 <andythenorth> I render out one result at the moment
21:19:44 <andythenorth> the load sprites I posted are copy-paste after tweaking a value :P
21:19:57 <andythenorth> which might be as effective as any other route, time-wise :P
21:20:38 <andythenorth> moving pixels around with PIL isn't hard by the looks of it, I just need to read the docs
21:20:56 <andythenorth> I think my code might benefit from review btw ;)
21:21:48 <Eddi|zuHause> why do you need multiple rows in a file?
21:21:56 <Eddi|zuHause> can just as well have multiple files
21:22:05 <andythenorth> Eddi|zuHause: good point
21:22:15 <andythenorth> naming conventions ftw....
21:22:35 <andythenorth> is there any compile time overhead to opening more pngs?
21:23:05 <andythenorth> Eddi|zuHause: btw whilst you were on...holiday....I switched bandit compile to nmlc -> nfo -> grfcodec
21:23:25 <andythenorth> compiles in ~50% of the time compared to nmlc -> grf
21:23:49 <Eddi|zuHause> same thing i did
21:23:51 <andythenorth> I also wrote a (dev only) shell script to build, skippinyg all dep checks
21:24:13 <andythenorth> I'm not ditching the makefile though
21:24:53 <andythenorth> I also started curling the bandit config from my website, which is....slow
21:25:20 <Alberth> nml is slow in the graphics conversion, isn't it?
21:25:32 <andythenorth> I don't know how to profile, but that seems a fair bet
21:25:48 <Alberth> I was wondering whether you could cache that
21:25:48 <Eddi|zuHause> nml is slow - period
21:25:51 <Terkhen> andythenorth: "time make" worked for me
21:25:56 <Terkhen> but yeah, nml is slower
21:26:14 <Alberth> Terkhen: 'profile' is about finding out what part is slow :)
21:27:03 <Terkhen> maybe it is the "working with a language instead of with a bunch of bytes" part
21:27:18 <andythenorth> I could patch nml src to print out elapsed times
21:27:27 <andythenorth> if I understand the pipeline better....
21:27:37 <andythenorth> but you don't want me doing that, I make wrong conclusions too often
21:27:39 <Terkhen> python must have some gprof equivalent
21:28:41 <Eddi|zuHause> i had the command a few weeks ago...
21:28:50 <andythenorth> for BANDIT and FIRS the times are ok
21:31:49 * andythenorth wonders what's slow
21:32:18 <Eddi|zuHause> "python -m cProfile -s time ../nml/nmlc -o cets.nfo cets.nml > profile2.txt"
21:32:35 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/profile_time.txt
21:32:37 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/profile_time.txt
21:32:46 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/profile_cumulative.txt
21:32:54 * andythenorth wonders if it's the kind of slowness that's amenable to cython or such
21:32:56 <Eddi|zuHause> the latter with "-s cumulative"
21:34:09 *** lmergen has joined #openttd
21:35:50 <Rhamphoryncus> reduce is almost always wrong
21:36:08 <andythenorth> reduce as in map:reduce?
21:36:42 <Rhamphoryncus> I should clarify: in python reduce is almost always wrong
21:36:48 <andythenorth> distributing tasks to worker threads?
21:37:06 <Rhamphoryncus> no, the reduce() builtin
21:37:07 <Eddi|zuHause> you're probably thinking something completely different
21:37:45 <Rhamphoryncus> Can't tell just from the profile output
21:40:09 <Rhamphoryncus> So it's a method with the same name as a builtin. Nope, I no longer feel like I was wrong. It's poor style that's to blame for my mistake.
21:40:44 <Eddi|zuHause> didn't even know there's a "reduce" builtin
21:41:32 <Rhamphoryncus> It's taken out of the builtin namespace in python3
21:42:29 <Rhamphoryncus> The thing about reduce is that, except for certain cases, the runtime is quadratic
21:42:38 <Eddi|zuHause> ah, so reduce is actually fold...
21:45:21 <Rhamphoryncus> looks like reduce is just a recursive evaluator?
21:47:05 <Alberth> or simplifier, I think
21:48:21 <Eddi|zuHause> Rhamphoryncus: not all values of the expression are actually constants, so "evaluation" is probably the wrong word
21:48:44 <Rhamphoryncus> partial evaluation?
21:49:05 <Rhamphoryncus> Or are they variables that it retrieves the current value from?
21:49:40 <andythenorth> Alberth: I wondered if I could knock out some of the structures
21:49:50 <andythenorth> seems a bit over-complicated right now
21:49:54 <CIA-1> OpenTTD: rubidium * r23962 /trunk/src/3rdparty/squirrel/squirrel/sqvm.h: -Fix [FS#5068]: [Script] Infinite recursion within a script wasn't caught properly, so they could cause crashes of OpenTTD instead of the AI
21:50:09 <Alberth> andythenorth: you seem to like disctionaries a lot
21:50:48 <Rhamphoryncus> sets are the new dictionaries ;)
21:50:50 <andythenorth> I prefer explicitly named values
21:50:59 <andythenorth> I don't like code that's some_list[27]
21:51:48 <andythenorth> l49-50 is much better
21:53:34 <Alberth> except it's some_tuple[..] :)
21:54:58 <Eddi|zuHause> Rhamphoryncus: expressions are trees, reduce transforms one expression-tree into a (potentially smaller) expression-tree
21:55:05 <Rhamphoryncus> If it's a tuple then take a look at namedtuple
21:55:06 <Alberth> I found your sequences quite interesting: bulk_load_1 = ([(0, 2), 4],) I'd write bulk_load_1 = [((0, 2), 4)]
21:55:36 <andythenorth> it's a naughty design choice - I just wanted the nested brackets to be easy to see :P
21:55:40 <Alberth> Rhamphoryncus: I was wondering about those too, but I couldn't pinpoint the name
21:55:52 <Rhamphoryncus> Eddi|zuHause: still sounds like evaluation
21:56:06 <Rhamphoryncus> reducing the tree.. by evaluating it.
21:56:15 <andythenorth> alberth in the sequences - I wondered if I needed to do (x,y) as a tuple at all
21:56:17 <Eddi|zuHause> Rhamphoryncus: like it will reduce "1+3" to 4, but "1+a" will stay "1+a" if a is not a compile-time constant
21:56:46 <Rhamphoryncus> that in particular is constant folding
21:57:11 <Rhamphoryncus> and constant propagation
21:57:25 <andythenorth> hmm namedTuple - fields accessible by name
21:57:33 <Alberth> it's not strictly needed, and here you don't gain much, except keeping coordinates more separate from the colour.
21:57:33 <andythenorth> I nearly wrote a stubby object to do that
21:57:52 <andythenorth> seemed like over-engineering at this stage
21:58:10 <Rhamphoryncus> namedtuple is basically for trivial classes
21:58:35 *** LordPixaII has joined #openttd
21:58:39 <Alberth> I like the (x,y) pairs
21:59:02 <Rhamphoryncus> (x,y) is usually too trivial even for namedtuple. Usually.
21:59:40 * andythenorth will stick with named pairs
21:59:42 <Eddi|zuHause> Rhamphoryncus: it also does some optimizations like preparing the expression for the shift/mask fields of nfo
21:59:50 <Rhamphoryncus> For graphics rendering it could easily grow a set of helper methods that put it beyond namedtuple
21:59:53 <andythenorth> Alberth: do you have a paste of the code? I can't get it to apply as a diff....
22:02:40 <Alberth> if colour != 255 and colour != 0 and colour != 15: if colour not in (0, 15, 255):
22:03:51 <andythenorth> I can probably figure it out though
22:03:57 <andythenorth> might just be upside down
22:04:57 <Rhamphoryncus> Eddi|zuHause: at least a translation would help
22:05:35 <andythenorth> now a ridiculously short amount of code considering what the results are :)
22:06:06 <Alberth> that's good; long python code is either very complex or it is wrong :)
22:06:16 <Eddi|zuHause> andythenorth: the beauty of (code) generators: they're usually very short
22:07:09 <Alberth> at work I am writing one, and I counted 10700 lines of Java today, and it's not even working yet :)
22:07:43 <Alberth> oh, excuding the language definition classes, as they are generated by EMF :)
22:07:46 <Eddi|zuHause> Rhamphoryncus: it's probably useless to simply translate this, if you don't get the context :)
22:08:29 <andythenorth> Alberth my biggest puzzle is how to write the configuration files
22:08:36 <andythenorth> or just put them inline
22:08:42 <andythenorth> this is just one trailer type
22:08:52 <andythenorth> I need about 5, plus recolor options
22:09:04 <Rhamphoryncus> andythenorth: start with inline. Add a config file later only if you need it
22:09:33 <andythenorth> I've had it rigorously drummed into me to separate code and content :P
22:09:35 <Rhamphoryncus> But.. it'd help if your config is a single object passed around, rather than a series of globals inspected all over the place
22:09:57 <Rhamphoryncus> Separate them structurally but leave them in the same file
22:10:42 <andythenorth> then instance it?
22:10:53 <andythenorth> Alberth: didn't you just murder my dicts :D
22:11:09 <Eddi|zuHause> that's what i usually do
22:11:12 <Alberth> andythenorth: dicts of 2-3 entries :p
22:11:13 <Rhamphoryncus> instance it, yes. Do *not* use singletons for state. They're stupid, nonsensical things :P
22:12:01 <Eddi|zuHause> andythenorth: read them from the tracking table
22:12:18 <Alberth> well, I am off to bed; everybody have a safe flight home, and see you all tomorrow somewhen hopefully
22:12:23 <andythenorth> Alberth: thanks ;)
22:12:29 <andythenorth> Eddi|zuHause: that might be a nightmare :o
22:12:36 <andythenorth> I did consider drawing them into a png
22:12:41 <andythenorth> then having PIL just read them :P
22:14:03 * andythenorth favours passing a dict around maybe
22:14:16 <andythenorth> or...instance objects, and call the render method directly on the object
22:14:32 <andythenorth> then I can stick objects in a list, render all, writing each one to a png
22:15:17 <andythenorth> Elukka: you keeping up with this? :)
22:15:34 <andythenorth> you might seriously consider generated sprites for regular-shaped wagons / coaches
22:16:11 <Elukka> i'm following, whatever i can understand :P
22:16:18 <Elukka> i would seriously consider anything that might make it easier
22:16:32 <andythenorth> it's not great yet
22:16:43 <andythenorth> but it might get you primitives that are easy to then improve
22:20:05 <andythenorth> good way to do that?
22:20:16 <andythenorth> passing it all in from the constructor call seems ugly
22:20:28 <Rhamphoryncus> You want a similar syntax?
22:20:38 <andythenorth> needs to be easy to read/write is all ;)
22:20:43 <andythenorth> (the data does need to be different per instance)
22:21:00 <andythenorth> I don't like this syntax tbh:
22:21:04 <andythenorth> body_outer = ([(0, 0), body_colour], [(0, 1), cc_colour], [(0, 2), body_colour], [(0, 3), body_colour], [(0, 4), 13])
22:21:11 <Elukka> is it possible to make more angles with it?
22:22:32 <Rhamphoryncus> Is it always (int, int), constant?
22:23:03 <Elukka> i mean as in the myriad extra angles of CETS :D
22:23:27 <andythenorth> Rhamphoryncus: (int, int), constant or (int, int), int
22:23:36 <andythenorth> the constants can be local to the object instance
22:23:46 <andythenorth> Elukka: it can do any angles you draw a floor plan for
22:23:51 <andythenorth> there is *no* clever maths
22:24:10 <Rhamphoryncus> ah. Hrm. Well, I will say this is a hard thing to do well.
22:24:19 <andythenorth> elukka when it finds a pixel of colour n, it draws more pixels offset by (some values)
22:24:26 <andythenorth> and whatever colour(s) you want
22:24:41 <andythenorth> I did try randomising pixel colours from a list to add variety, but it sucked
22:24:46 <Rhamphoryncus> You could replace [(0, 0), body_colour] with P(0, 0, body_colour)
22:25:08 <andythenorth> Rhamphoryncus: I could pass a dict to the object
22:25:25 <andythenorth> but then I don't gain much from the object
22:25:43 <andythenorth> the hardest part of this is the human-> code interface :)
22:26:18 <Rhamphoryncus> P(0, 0, body_colour) reduces the parenthesis/etc, which makes it less noisy
22:27:17 *** FLHerne has joined #openttd
22:27:18 <Rhamphoryncus> body_outer = [P(0, 0, body_colour), P(0, 1, cc_colour), P(0, 2, body_colour), P(0, 3, body_colour), P(0, 4, 13)]
22:27:58 <Rhamphoryncus> A list is more appropriate (that's homogenous data, not heterogeneous) and is a different character from P()
22:28:48 <andythenorth> the P thing is good for readability
22:28:59 <andythenorth> although it would have tripped me up if this was someone else's code ;)
22:29:34 <Rhamphoryncus> You could also replace body_colour and cc_colour with BODY and CC. Perhaps even make them singletons (the constant sort!) that are replaced with the configured value later
22:30:59 <andythenorth> so I make a singleton by...?
22:31:11 <andythenorth> singletons are unique in which namespace(s)?
22:31:24 * andythenorth asks dumb newbie questions
22:31:38 <Rhamphoryncus> A "global" in python is just an attribute of that module. Exact same as everything else in that module.
22:32:02 <Rhamphoryncus> the easiest way here is "BODY = object()", then use "if x is BODY: x = ..."
22:34:33 <andythenorth> Rhamphoryncus: any idea how to find docs on P for parentheses?
22:34:42 <andythenorth> all I can find with google is regex stuff
22:35:03 <Rhamphoryncus> umm, P isn't anything. It's just an arbitrary class name I picked :)
22:35:12 <Rhamphoryncus> you could used namedtuple to create it
22:35:30 <andythenorth> I thought it was a built in trick
22:45:38 <andythenorth> I could just write:
22:46:14 <andythenorth> body_outer = 0,0,BODY,0,1,BODY,0,2,14,0,3,14,0,4,ROOF
22:46:22 <andythenorth> not hugely readable :P
22:49:31 <dihedral> Zuu, are you interested in creating a NoGo lib for the json communication with the admin port?
22:50:12 <andythenorth> Rhamphoryncus: this might be dumb, but can I import a module into an object's namespace?
22:50:35 <Nat_as> Why are there no bidirectional path signals?
22:50:37 <Rhamphoryncus> No, but you can import in a method. Just use "import foo" as normal
22:50:41 <Eddi|zuHause> <andythenorth> there is *no* clever maths <-- that's probably what's wrong with it :p
22:50:53 <andythenorth> Eddi|zuHause: feel free to contribute :)
22:50:54 <Zuu> And the second, what do you relly want to do?
22:51:13 <andythenorth> Eddi|zuHause: procedural lighting, base on figuring out the angle....?
22:51:22 <Zuu> Sorry if I sound negative.. :-)
22:51:29 <Rhamphoryncus> importing a module in python is idempotent. The first time it gets stashed in sys.modules and every time after gets a reference to the same object
22:51:48 <Rhamphoryncus> (unless there's a pathing issue and it imports as two separate modules.. which does happen occasionally..)
22:52:18 <andythenorth> if I import a module that defines BODY, then later import another module that also defines BODY, will BODY be over-written?
22:52:31 <Rhamphoryncus> No, they're separate
22:52:34 <andythenorth> (that would be desirable in this case, usually not)
22:54:03 <Rhamphoryncus> If you use "from foo import BODY" then you'll have a local variable to the same object as foo.BODY. Modifying that object will affect both (they're the same object), but if you reassign such as "BODY = BODY + 1" it'll only replace the local variable
22:54:35 <Rhamphoryncus> I did suggest having BODY be a singleton. There'd be no reason to redefine it somewhere else.
22:54:55 <andythenorth> it will need redefining per recolour ;)
22:54:59 <andythenorth> but that's later....
22:55:47 <Rhamphoryncus> Have P() do "if x is BODY: x = config.body_colour"
23:00:25 * andythenorth needs to write def P: :P
23:04:57 <Nat_as> I can place normal path signals facing inward in stations?
23:05:05 <Nat_as> damn that makes my layout much better
23:05:16 <Nat_as> I was using bidirectonal plain signals the whole time
23:05:26 *** kkb110_ has joined #openttd
23:05:26 <Nat_as> maybe now I wont get gridlock
23:06:14 <Rhamphoryncus> def P: # :P fed
23:12:44 <Nat_as> why do all these layout examples have xbox huge rail yards.
23:13:15 <Nat_as> I don't like it when the junctions are more than twice as large as the stations.
23:13:39 <Nat_as> also I never build single track
23:13:58 <Nat_as> double or quad track Ro-ro drive through all day evrry day
23:15:29 <andythenorth> Rhamphoryncus: I'm going to file this python under 'problem for tomorrow' ;)
23:15:46 <andythenorth> but I'll keep the suggestions in mind
23:15:51 <Rhamphoryncus> Nat_as: volume :)
23:16:08 <Rhamphoryncus> Also, many are from openttdcoop, which does nothing small
23:16:15 <andythenorth> quite often I wake up with the answer to a code problem
23:16:36 <Rhamphoryncus> Nat_as: got a specific example in mind? There might be another reason
23:17:46 <Nat_as> I just had a gridlock in one of my ro-ro stations that ended in a catistrophic crash when I tried to un-jam it
23:20:23 *** andythenorth has left #openttd
23:20:30 <Rhamphoryncus> I think we've all done that
23:24:55 <dihedral> Zuu: to unify the communication options between bots and NoGo scripts ;-)
23:25:46 <dihedral> else each NoGo script will need it's own bot on the other end handling data (in case it should make use of the json part)
23:28:36 <Nat_as> i wish signals existed at the boarders between tiles instead of on tiles
23:28:42 <Zuu> It appears that the API doesn't parse the json string back to a table. That is probably the missing link in what you like to do.
23:28:43 <Nat_as> would make layouts much simpler.
23:32:07 <Zuu> dihedral: Or do you aim to also standardize some sort of protocol ontop of the json layer?
23:33:24 <Xaroth> no need to make a protocol on top of that
23:34:05 <Xaroth> 1 bit is the descriptor of what you send, the rest is the data attached to that, done
23:34:48 <Zuu> Hmm, actually GSEventAdminPort::GetObject might return a table or something else in usual Squirrel data types.
23:51:00 *** Progman has joined #openttd
continue to next day ⏵
