IRC logs for #openttd on OFTC at 2012-05-01
⏴ go to previous day
00:34:52 *** supermop has joined #openttd
01:00:46 <michi_cc> orudge: The forum server seems to live in the future, I already got the backup message *before* 1:00 UTC ;)
01:23:29 <supermop> whats the best way to create 1x zoom sprites from hand-drawn 4x zoom?
01:27:37 <supermop> am thinking of antialiasing, then retracing
01:28:14 <supermop> maybe producing 2x zoom first, then 1x would help
01:28:28 <supermop> as it won't be as big of a change
01:29:00 <supermop> scale 50%, redraw for smaller size, scale 50% again, redraw
01:29:42 <supermop> I could also just make different sources
01:29:58 <supermop> current ive drawn all rail sprites in false color at 4x
01:30:09 <supermop> and am recoloring per railtype
01:31:40 <supermop> i.e. color the currently orange ties brown for wood, grey for concrete, color green rails red-brown, dark grey, or light grey
01:32:36 <supermop> I could have another layer with the same thingss drawn either smaller, or chunkier
01:33:06 <supermop> monorail is still a tricck, but i think i have a workaround
01:33:11 <supermop> I am making a new one
01:33:29 <V453000> well yeah but what sort ... trains?
01:34:18 <supermop> for ages i've wanted someone to code MLSD to be railtype aware, so that i could use each rail type to in a given set to implement a different depot style
01:34:42 <supermop> no one ever did, so now I am trying to make my own rail grf
01:35:09 <V453000> hm rescale might work there fairly well I guess
01:35:15 <supermop> so that i can provide different railtypes to give different depots
01:35:55 <supermop> im doing opposite of fine scale - they are a bit wider than normal
01:36:10 <supermop> so n one will likely use the grf
01:36:54 <supermop> hopefully someone will put it over a popular rail grf somehow
01:37:35 <supermop> anyway here is the thing with monorail though
01:38:07 <supermop> at 1x zoom its just a fat white line, but at 4x, the beam has real height
01:39:03 <supermop> which means that if you draw it to give it the illusion of depth like in TTD, it will either look bad on corners, or bad on straights
01:39:21 <V453000> idk :) I find drawing in EZ pointless tbh
01:39:50 <V453000> but even if you do that, I would personally recommend to focus on the 1x the most
01:40:39 <supermop> so i am thinking of making the beam actually have height - and fake it with caternary
01:41:22 <supermop> ie have monorail have a custom caternary, with the sprite drawn and positioned as the monorail beam
01:41:38 <supermop> hmm yeah most people play at 1x most of the time anyway
01:46:25 <supermop> actually redrawing at 2x isn't bad
01:47:10 <supermop> if i make 2x look good then i can probably scale to 1x from there without it looking muddy
01:47:20 <supermop> maybe even repeat for .5x
01:47:59 <V453000> I think it is a lot different between 4x->2x and 2x->1x but not sure, never done that
01:48:50 <supermop> well with thin rails as is the fashion,
01:49:18 <supermop> going straight from 4 to 1 you can lose place of where the rails actually go
01:49:37 <supermop> at 2 you still have some remininds
01:50:17 <supermop> so touch those up so that something carries through to 1x
01:50:33 <supermop> going from 4 to 1 only 1 pixel in 16 survives
01:50:46 <supermop> unless you use aa, inwhich case its all a blur
01:51:37 <supermop> going from 4 to 2 and 2 to 1, its 1 in 4, and if rails are 2px wide, those are good odds
02:02:31 *** HerzogDeXtEr1 has joined #openttd
02:06:58 *** Djohaal has joined #openttd
03:41:11 <supermop> hmmm i guess i should add layers to my false color template for NG, 3rd rail, etc
04:23:43 *** kkb110_ has joined #openttd
04:56:18 *** Eddi|zuHause has joined #openttd
05:26:14 *** Keyboard_Warrior has joined #openttd
07:05:25 *** andythenorth has joined #openttd
07:05:45 * andythenorth goes to toil honestly at the coalface of python, and mostly jquery
07:05:53 *** andythenorth has left #openttd
07:15:57 *** th_gergo has joined #openttd
07:29:28 *** fonsinchen has joined #openttd
07:32:31 *** frosch123 has joined #openttd
07:46:53 *** Devroush has joined #openttd
07:57:09 *** TWerkhoven has joined #openttd
08:06:17 *** telanus has joined #openttd
08:08:50 *** sla_ro|master has joined #openttd
08:11:21 *** julien0 has joined #openttd
08:12:52 <julien0> Hi, I've just started hacking around NoGo and I have some questions
08:12:54 *** mahmoud has joined #openttd
08:13:29 <Terkhen> Don't ask to ask, just ask :)
08:14:08 <julien0> The goal is to use it as an assistant (watch if lines are ok, add/remove vehicles depending on station loading, ...)
08:15:04 <julien0> to communicate with script, I've added an API to add commands to interactive console
08:15:17 <julien0> so far it seem to work, I will make a patch soon
08:16:42 <julien0> but I have seen that most standard Squirrel functions are not available (getroottable, newthread, regexp, ...) why ?
08:17:27 <julien0> I understand that I/O functions can cause security problems, but most of the rest of API seem safe
08:17:31 *** Keyboard_Warrior has quit IRC
08:17:52 <__ln__> first very well written english, but then a questionmark preceded by space. not completely unexpected though.
08:18:52 <julien0> French typographic rules :)
08:18:55 <Eddi|zuHause> julien0: most internal functions have been disabled for performance reasons. you need a way to count the "operations" a script is doing, to prevent it from using too much CPU
08:19:23 <__ln__> julien0: yeah, i know, but they don't apply to english. :)
08:19:36 <Eddi|zuHause> julien0: people have been making openttd hang by a simple sort() call
08:21:57 <julien0> ok, I've not thought abou that one
08:24:53 <Terkhen> if you think that something is missing from the API, you can always file a feature request
08:25:16 <Terkhen> IIRC we already had some inclusions from such suggestions
08:25:27 <Terkhen> of course, it is a lot better if the suggestion comes as a patch :P
08:26:45 <julien0> sure, I think that coroutine could allow some cool things, and I don't think that it is CPU intensive.
08:27:30 <Terkhen> OpenTTD is not very thread friendly
08:28:12 <Terkhen> I don't know how OpenTTD handles Squirrel execution (scripts are not my forte) but probably it would lead to desyncs
08:28:32 <julien0> yes but coroutines are not parallel threads, it's just multiple stacks of execution
08:29:19 <Terkhen> as long as they don't introduce a non-deterministic order of execution, they should be okay
08:29:40 <julien0> there is only one control flow, and couroutines tranfer control with resume/yield
08:29:42 <Eddi|zuHause> coroutine is what "yield" is in python?
08:30:42 <julien0> Eddi|zuHause: more or less. IIRC the python yield is a "generator", coroutines are a bit more powerful
08:31:13 *** Progman has joined #openttd
08:37:20 *** |Jeroen| has joined #openttd
08:37:21 <SpComb> julien0: python's generators support .send(...)
08:37:32 <SpComb> julien0: i.e. `foo = yield bar`
08:37:46 <SpComb> so they're kinda like coroutines
08:38:04 <SpComb> in a limited sense, in that you can hack them to do some similar things :)
08:39:00 <SpComb> you just have to keep the control flow explicit, vs with coroutines any innocent-looking line of code could resume/yield
08:39:14 <SpComb> giving you the same issues with mutable shared state that you have with threading..
08:40:12 <julien0> SpComb: ok, I didn't used Python generators so munch, I'm more used to Lua coroutines (I think that Squirrel ones are similar)
08:40:38 <SpComb> python has real coroutines as well, in the form of stackless/greenlets
08:41:03 <SpComb> but uh, I guess this is off-topic, Python wouldn't really be the right choice for embedding into OpenTTD anyways
08:41:48 <julien0> Yes, with couroutines you are only sure that two concurrent threads will not write the same data at same time but a hidden yield can be harmful
08:43:50 *** tokai|noir has joined #openttd
08:43:50 *** ChanServ sets mode: +v tokai|noir
09:13:02 <NGC3982> i cant seem to get the gnome font right.
09:13:14 <NGC3982> when i start changing it, it turns into poop.
09:18:42 *** valhallasw has joined #openttd
09:37:22 *** TWerkhoven has joined #openttd
09:40:44 *** fonsinchen has joined #openttd
10:41:32 *** ZxBiohazardZx has joined #openttd
10:46:27 *** TGYoshi has joined #openttd
11:23:40 *** oskari89 has joined #openttd
11:31:38 *** Freudian has joined #openttd
12:47:11 <NGC3982> what has happend here?
12:47:24 <NGC3982> for god sake, wake up you swabs!
12:47:52 * MNIM thwacks NGC3982 on the head
12:53:26 <Zuu> I don't know if more countries have holliday today.
12:54:15 <NGC3982> most of europe celebrate 'may day'
12:54:50 <Zuu> According to wikipedia 80 countries have it as national holiday.
12:55:26 <NGC3982> the swedish article needs to be updated. it stated that number as "many" :3
12:57:25 * Zuu likes the "a pair" count. In some regions it really means two, while in others it could be up to 7 items or so.
12:58:12 <Zuu> and in some contexts, it is just one item :-)
13:00:49 <frosch123> Zuu: in german it depends on the capitalisation :p
13:00:57 <frosch123> "Paar" is two, "paar" is a few
13:02:03 <frosch123> though argueably capitalisation is hard to pronounce :p
13:03:10 <NGC3982> Zuu: i read a paper on boson 3-sigma experiments at CERN, where they collided "a pair" of protons.
13:04:02 <NGC3982> about 3-4 millon per bunch, that is.
13:05:57 <ZxBiohazardZx> May day is for the nubs
13:06:03 <ZxBiohazardZx> still being drunk after queensday is the key
13:07:17 *** robotboy has joined #openttd
13:10:52 <frosch123> yay, turned of the opengl renderer of widelands, now it works much better
13:11:27 <frosch123> somehow opengl interlocks my whole machine into a single core thingie
13:27:44 *** Stimrol has joined #openttd
13:30:06 *** telanus1 has joined #openttd
14:02:37 *** hackalittlebit has joined #openttd
14:03:49 *** goodger has joined #openttd
14:05:06 <hackalittlebit> STR_FILE_MENU_LOAD_GAME appears only in language files. Is that correct?
14:08:29 <frosch123> my grep says the same :)
14:08:57 <hackalittlebit> and other question, in game options ; option "Road Vehicles" " drive on right side" or " drive on lLeft side" is that for trains also?
14:09:20 <frosch123> depends on the signal side setting
14:09:47 <frosch123> the signal side setting is entirely stupid, it allows to choose between "always on left" and "on driving side"
14:09:58 <frosch123> i.e. you cannot drive on left and have the signal right :p
14:10:35 <hackalittlebit> I will look into it :)
14:11:05 <frosch123> that string was added between 0.7 and 1.0
14:11:12 <frosch123> but is not used in 1.0 either
14:11:56 <frosch123> ah, though maybe it was only renamed in 1.0
14:15:13 <frosch123> STR_015D_LOAD_GAME was already unused in 0.3.5
14:16:20 <frosch123> hackalittlebit: the string is used
14:16:40 <frosch123> the strings in a classic dropdown follow consecutively
14:16:51 <frosch123> thus only the first one (STR_FILE_MENU_SAVE_GAME) is referenced in the code
14:17:39 <NGC3982> is there any reason to ever use other string names then "STR_*"?
14:17:41 <peter1138> trains don't drive on a side
14:18:30 <NGC3982> it seems like your previous corrections of the same word didnt really help.
14:19:46 <NGC3982> for some reason, all these years on the internet still havent blessed me with adequate english.
14:21:30 <hackalittlebit> peter1138:could it be seperated for cars and trains, here in portugal cars on the right and trains on the left
14:21:47 <peter1138> hackalittlebit, train drive in the middle of a tile, they don't have a side
14:22:20 <hackalittlebit> I mean signals
14:28:11 <hackalittlebit> so for now the string in the "option menu" should be "cars and signal" "on the right" or "on the left"
14:31:56 *** Rhamphoryncus has joined #openttd
14:34:01 <frosch123> hackalittlebit: likely the best option is to make the signal side setting a three way setting: left, driving side, right
14:36:34 <frosch123> well, actually let's just do that
14:36:37 *** andythenorth has joined #openttd
14:37:40 <NGC3982> in a system with low powered engines. is more and shorter trains preferable in terms of economy?
14:38:04 <NGC3982> the running cost is negligible
14:40:32 <hackalittlebit> don't know what's happening but I can not change that setting anymore inside the game :(
14:41:02 <frosch123> road vehicle side can only be changed as long as there are no roadvehicles on the map
14:41:11 <frosch123> well, and only singleplayer of course
14:42:13 <hackalittlebit> do new map, build car, still possible, drive car not possible anymore.
14:42:34 *** fonsinchen has joined #openttd
14:42:54 <frosch123> ah, so it is enough if they are in depot :)
14:43:13 <hackalittlebit> not after you drove
14:43:22 <frosch123> anyway, that is the reason why the driving side belongs into the mapgen settings
14:43:32 <hackalittlebit> should be possible if inside depot
14:43:57 <hackalittlebit> no not good idear
14:44:25 <hackalittlebit> should only be possible before game starts
14:44:47 *** dotwaffle has joined #openttd
14:44:50 *** dotwaffle has joined #openttd
14:51:29 <hackalittlebit> frosch123: I'll implement your proposal.
14:51:52 <frosch123> i am already doing it
14:52:19 <frosch123> just need to figure out how to cause minimum hassle for the conversion of openttd.cfg
14:53:36 *** hackalittlebit has quit IRC
15:08:45 *** lorem_ipsum has joined #openttd
15:09:38 <lorem_ipsum> is there a way to set the revision manually for the configure script?
15:11:13 <lorem_ipsum> --revision worked earlier, but not anymore
15:13:31 <CIA-1> OpenTTD: frosch * r24191 /trunk/src/table/settings.ini: -Fix: If you consider a settings to potentially cause desyncs via NewGRFs and thus disallow changing it in network games, you should probably also sync it to clients.
15:14:22 <frosch123> lorem_ipsum: no, there was a major incident with that setting, it it was doomed for all times
15:16:01 <lorem_ipsum> is there an other way to set the revision? Like an environment variable
15:20:58 *** supermop has joined #openttd
15:22:24 <Rubidium> lorem_ipsum: wanting to override the revision means you want to do something that you shouldn't be doing
15:22:54 <lorem_ipsum> i'm trying to build a gentoo ebuild for openttd nightly
15:23:17 <lorem_ipsum> The problem is the build system makes an svn checkout and copies the content (without .svn) to a workdir
15:23:20 <Rubidium> previous results have shown that the majority think they are doing it 'right', but they're simply not
15:23:39 <lorem_ipsum> so the information is lost in that process
15:24:19 <lorem_ipsum> i just wanted to check if there's a solution which doesn't require copying the .svn as well
15:24:44 <Rubidium> if you want nightlies, then download the tarball from the website
15:25:10 <Rubidium> instead of using subversion, as then it's quite likely you're not getting a nightly but some other trunk revision
15:27:24 <lorem_ipsum> correcting nightly to latest
15:27:52 <lorem_ipsum> but the nightly should work
15:27:56 <Rubidium> though doesn't emerging a new version require a new ebuild (one with a different name)
15:28:46 <lorem_ipsum> i want a 9999 ebuild always fetching the latest revision and building it
15:29:28 <Rubidium> what's so hard about svn up && make ?
15:29:43 <supermop> I have a rail sprite question:
15:29:45 <Rubidium> to me it seems a bit bureaucratic
15:29:56 <supermop> there is a separate sprite for x junction
15:30:14 <supermop> can i also provide special sprites for Y junctions?
15:30:19 <lorem_ipsum> portage removes the .svn and i wanted to check if it works without addintion copying of the .svn
15:30:36 <lorem_ipsum> s/addintion/additional
15:31:04 <supermop> Rubidium: that no to me?
15:31:16 <Rubidium> (unless being pedantic, then yes as one could use git or mercurial)
15:31:19 <lorem_ipsum> i guess he means me :-)
15:31:29 <lorem_ipsum> would be the same there
15:31:51 <lorem_ipsum> so i'm just copying the .svn as well
15:32:06 <supermop> also; can rail tiles have CC, and if not, can caternary have CC?
15:33:44 <CIA-1> OpenTTD: frosch * r24192 /trunk/src/settings.cpp: -Fix [FS#5153-ish]: Also use default value when reading an invalid integer setting value.
15:34:46 <CIA-1> OpenTTD: frosch * r24193 /trunk/src/settings.cpp: -Fix (r24191): Also update comments accordingly.
15:35:37 <frosch123> supermop: depos and fences can have cc
15:35:41 <frosch123> i guess the rest cannot
15:36:08 <supermop> guess not, or know not?
15:36:28 <supermop> I can at least have custom caternary sprites per rail type though?
15:36:29 <frosch123> i know for depots and fences, not for the rest :)
15:36:42 <frosch123> catenary is per railtype, yes
15:37:17 <supermop> so I could postion and draw a 3rd rail with cover as a caternary? or is that a bad idea?
15:37:48 <supermop> i want to give it the appearance of height relative to the rails at 4x zoom
15:39:14 <frosch123> supermop: height is not a matter of catenary
15:39:26 <frosch123> the question is the sorting order with the train
15:39:52 <frosch123> the rail is drawn before drawing the train, the catenary after the train
15:41:07 *** TWerkhoven[l] has joined #openttd
15:41:59 <supermop> but if the 3rd rail is in front of the track, and is 'tall' I might want it to appear in front of the train
15:42:08 *** fonsinchen has joined #openttd
15:42:16 *** lorem_ipsum has left #openttd
15:42:24 <supermop> that is occlude part of the bogies
15:43:08 <supermop> I guess i could always draw the 3rd rail behind
15:43:40 <supermop> then it wouldn't matter
15:46:12 <supermop> want to help me draw and code andy?
15:46:18 <andythenorth> make each FIRS industry a self-contained nml file, have nml compile it to nfo (as needed)
15:46:31 <andythenorth> then use python to mangle the nfo header stuff off, and concatenate
15:46:38 <andythenorth> then compile grf with grfcodec
15:46:40 <supermop> you always seem to want to make things complicated....
15:46:55 <andythenorth> slow thing is slow
15:47:01 <andythenorth> dull thing is dull
15:48:49 <andythenorth> nmlc migt be persuaded to leave a comment in the compiled nfo
15:48:57 <andythenorth> like '//split_here'
15:49:07 <andythenorth> split on that, join, write file
15:49:10 <andythenorth> it's about 7 lines :P
15:49:15 <andythenorth> it will be quick
15:49:21 <andythenorth> to write and run
15:51:05 <andythenorth> when economies are added to FIRS, it will be unbearably slow to compile
15:52:15 <andythenorth> compile needs to be made parallel before that's of value
15:52:21 <andythenorth> nml is not currently parallel
15:52:33 <andythenorth> my proposal goes towards making it parallel, or compiling only what's needed
15:53:46 <andythenorth> Eddi|zuHause....planetmak*r, Yex* and Terkh*n are all busy with RL. Alb*rth doesn't like newgrf or cpp much, and Foobar is buried in Dutch trains. How much do you want economies? ;)
15:53:58 <CIA-1> OpenTTD: frosch * r24194 /trunk/src/ (60 files in 4 dirs): -Change: Rename the 'signal_side' setting to 'train_signal_side', and add a third option while doing so.
15:54:01 <andythenorth> this question is unrelated to monologue above
15:54:09 <Eddi|zuHause> andythenorth: make nml output a special action C?
15:54:51 * andythenorth wonders if nmlc likes being run via python multoprocessing
15:57:44 <Eddi|zuHause> does nmlc support action C yet? like a "document()" macro or something?
15:58:11 <Eddi|zuHause> or a special #pragma
16:02:47 <andythenorth> multoprocessing?
16:02:57 * andythenorth wonders if that's like multiprocessing :P
16:07:55 <andythenorth> Eddi|zuHause: would the technique work for CETS?
16:08:28 <Eddi|zuHause> yes, but CETS compile time is fairly reduced now...
16:10:11 <Eddi|zuHause> from like 7 minutes to 2 minutes
16:11:47 <Eddi|zuHause> 3 steps: using grfcodec as intermediate step, removing the "deps" run, and removing all sprite template calculations
16:12:49 <Eddi|zuHause> nmlc: "sprites/nml/industries/arable_farm.pnml", line 167: Unrecognized identifier 'build_prod_change' encountered
16:13:44 *** Progman has joined #openttd
16:14:36 <andythenorth> sprite templates is interesting optimisation
16:14:58 <andythenorth> probably applies to FIRS
16:15:21 <Eddi|zuHause> firs builds in 48 seconds here
16:19:11 <Eddi|zuHause> 251/1 0.005 0.000 3.471 3.471 base_statement.py:151(get_action_list)
16:23:21 <Eddi|zuHause> andythenorth: your sprite templates don't seem to use a lot of calculations...
16:23:57 <andythenorth> FIRS is ~39s for me
16:24:07 <Eddi|zuHause> but the first two steps may shave off like 50%
16:24:10 <Freudian> okay well I have been here for about five hours and I haven't understood a single word any of you have said.
16:24:56 <Eddi|zuHause> freudian slipped...
16:27:40 *** brambles has joined #openttd
16:28:42 <andythenorth> a grfcodec encode of FIRS is about 1-2s
16:28:53 <andythenorth> I should patch the makefile to use that route :P
16:29:22 <andythenorth> and remove the deps
16:29:36 <andythenorth> I *always* build 'make clean' anyway, because deps are unreliable
16:32:55 *** th_gergo has joined #openttd
16:38:39 <Eddi|zuHause> CETS revisions 548 and 549 might be for you then
16:46:57 <andythenorth> Eddi|zuHause: I've copied cets r549 to firs
16:47:02 <andythenorth> nmlc: "scripts/Makefile.nml", line 1: Syntax error, unexpected token "USE_NML"
16:47:15 <andythenorth> palette was wrong for some reason :P
16:47:33 <Eddi|zuHause> err... yes... i modified the palette flag
16:47:46 <Eddi|zuHause> if FIRS uses windows palette, you need to change that back
16:47:49 <andythenorth> I know where that is
16:48:00 <Eddi|zuHause> in the grfcodec line
16:48:55 *** FLHerne has joined #openttd
16:49:29 <andythenorth> any idea about the unexpected token?
16:49:54 <andythenorth> [line 1 not new]
16:49:55 <andythenorth> didn't throw errors before though
16:50:37 <Eddi|zuHause> no idea what that even is
16:53:27 <andythenorth> nmlc tries to parse Makefile.nml?
16:54:07 <andythenorth> happens during the dep check I think
16:54:19 <andythenorth> I need to murder the dep check anyway, but not sure how to yet
16:54:36 <andythenorth> r548 looks quite specific to cets
16:57:07 <Eddi|zuHause> ignore the python part, just make an empty file firs.grf.dep or so
16:57:45 <Eddi|zuHause> or put all .png files into that file
16:58:14 <Eddi|zuHause> as in "firs.grf: file1.png file2.png ..."
17:04:46 <andythenorth> so removing the dep check also clears the error
17:06:34 <andythenorth> 'touch firs.gfx.dep' is sufficient to get the check to pass
17:06:46 <andythenorth> but unfortunately make clean removes it :P
17:07:07 * andythenorth is worried about leaving a mess all over the makefile
17:07:43 <Eddi|zuHause> yes. put the "touch firs.gfx.dep" line to the place where the nml call was before, i.e. under the "firs.gfx.dep:" entry
17:09:51 <Eddi|zuHause> or if you're evil, something like: echo 'firs.gfx.dep: \\' > firs.gfx.dep; find -iname '*.png' >> firs.gfx.dep
17:10:50 *** Zeknurn has joined #openttd
17:12:24 <Eddi|zuHause> err... that should be: echo 'firs.gfx: ...
17:20:33 <andythenorth> it is loud when a toddler tips over a box of lego
17:24:33 <Belugas> it's loud too when a father's foot steps on a pointy lego block
17:25:09 <Belugas> OSTI D"CRISS DE TABARNAC!!!! RANGE TES BLOCS!!!!
17:25:35 <Eddi|zuHause> andythenorth: www.informatik.uni-halle.de/~krause/firs_dep_check.diff
17:26:08 <Eddi|zuHause> andythenorth: makes firs.grf depend on all png files unconditionally
17:26:36 <Eddi|zuHause> which is "close enough" if you assume that (almost) all png files are actually used
17:27:05 <Eddi|zuHause> ./sprites/graphics/industries/grainmill.old.png <-- things like this possibly not :)
17:33:05 <Eddi|zuHause> NGC3982: that misses half the joke
17:33:45 * andythenorth had lego tidying issues :P
17:34:23 <andythenorth> makefile editing sucks when you write a lot of python
17:34:29 <andythenorth> my editor converts tab to 4-space :P
17:34:32 <Eddi|zuHause> NGC3982: (and see the hover text)
17:35:07 <Eddi|zuHause> get a smarter editor, who can do these settings based on (autodetected) language
17:36:24 <andythenorth> it's parsing -iname as chars I think :P
17:36:42 <Eddi|zuHause> your find is weirder than mine, then
17:37:50 <andythenorth> -name looks like a similar flag
17:38:08 <Eddi|zuHause> -iname makes case-insensitive matching
17:38:26 <Eddi|zuHause> at least in GNU find
17:41:08 <Eddi|zuHause> andythenorth: try to make it "find . -iname blah"
17:42:32 <Eddi|zuHause> andythenorth: or try just "-name"
17:45:39 <CIA-1> OpenTTD: translators * r24195 /trunk/src/lang/czech.txt:
17:45:39 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:45:39 <CIA-1> OpenTTD: czech - 1 changes by Paragulis
17:46:06 *** fonsinchen has joined #openttd
17:49:45 *** peteris has joined #openttd
17:49:48 *** Devroush has joined #openttd
17:51:39 <andythenorth> find: -printf: unknown option
17:51:50 <Eddi|zuHause> ah. then forget it.
17:51:53 <Eddi|zuHause> your find is stupid
17:52:12 <andythenorth> bsd has to be different :)
17:59:24 <CornishPasty> Just install gnu, andythenorth
18:00:46 <frosch123> any is more into ponies than gnus
18:02:52 <andythenorth> it stupidly requires make clean for first build :P
18:03:05 <andythenorth> it does build in 20s though :D
18:03:42 <Eddi|zuHause> the %.grrf: line is wrongly indented
18:05:02 <Eddi|zuHause> and don't put the touch in clean: put it under %.gfx.dep:
18:05:13 <andythenorth> now it doesn't build after I fixed the indentation :P
18:06:46 <Eddi|zuHause> %.gfx.dep: $(V_) touch $@
18:07:20 <Eddi|zuHause> on two separate lines, of course
18:10:05 <andythenorth> this is back: nmlc: "scripts/Makefile.nml", line 1: Syntax error, unexpected token "USE_NML"
18:10:34 * andythenorth wonders if it's L56
18:10:37 <andythenorth> depend:: Makefile.dep $(patsubst %.grf,%.src.dep,$(GRF_FILES)) $(patsubst %.grf,%.gfx.dep,$(GRF_FILES))
18:11:38 <Eddi|zuHause> no idea what that means
18:13:19 <planetmaker> it means that the target 'depend' is executed when...
18:13:44 <planetmaker> - Makefile.dep, *.src.dep for every *.grf and *.gfx.dep for every *.grf is made
18:14:26 <planetmaker> makefile differs between tab and space. They have a meaning
18:15:01 <andythenorth> planetmaker: I don't want to drive a bus through all your makefile work with this
18:15:11 <andythenorth> I'm kind of hacking at stuff with no real idea
18:17:59 <andythenorth> this builds in 23s but with 3 errors
18:18:20 <andythenorth> all errors are nmlc: "scripts/Makefile.nml", line 1: Syntax error, unexpected token "USE_NML"
18:34:12 *** Alberth has joined #openttd
18:34:12 *** ChanServ sets mode: +o Alberth
18:38:31 *** supermop has joined #openttd
18:46:08 <Alberth> I'll be in time for 0.7.6 :)
18:49:31 <andythenorth> you missed the makefile discussion :)
18:51:11 <Alberth> did anything interesting came out of it?
18:51:26 <DorpsGek> andythenorth: 0.410256410256
18:51:44 <andythenorth> with Eddi's patch I have FIRS building 40% faster, but with 3 errors
18:52:16 <andythenorth> the errors don't affect the grf, only the dep check afaict
18:52:24 <Alberth> ditch dep construction?
18:52:47 <andythenorth> I don't know how though
18:52:56 <andythenorth> my attempts to delete .dep things made the build slower :P
18:53:31 <andythenorth> ^ current state of scripts/Makefile.nml
18:54:53 <Alberth> rm -rf parsetab.py <-- haha :)
18:56:15 <Alberth> hmm, update to tip fails
18:57:52 <Alberth> nmlc: "sprites/nml/industries/arable_farm.pnml", line 167: Unrecognized identifier 'build_prod_change' encountered <-- it does boem :(
18:58:48 <Eddi|zuHause> Alberth: update nml, had the same problem
18:59:30 <Alberth> thanks for helping though :)
19:01:24 *** mahmoud has joined #openttd
19:01:27 * andythenorth did patch nml ;)
19:01:38 <andythenorth> I should patch the errors too :P
19:06:58 <Alberth> translation updated :)
19:07:18 <andythenorth> now you just need to fix the makefile ;)
19:08:13 <andythenorth> this is the wrong approach to optimisation, but...
19:08:18 <Alberth> making a newgrf linker would be fun, I think :)
19:08:20 *** Firartix has joined #openttd
19:08:25 <andythenorth> I want to be able to put in delimiters for identifier scope
19:08:29 <andythenorth> to reduce scanning
19:08:46 <andythenorth> in a well-designed newgrf, it's trivial to localise all varaction 2 IDs
19:08:55 <andythenorth> perhaps only if you wrote a lot of nfo though :P
19:09:37 <andythenorth> BANDIT for example would scope easily to each vehicle
19:09:57 <andythenorth> FIRS uses one varaction 2 ID shared between industries, not more
19:10:14 <andythenorth> with local scoping, the problem becomes more parallel afaict
19:10:32 *** Chris_Booth has joined #openttd
19:11:08 <Alberth> I don't know what things get transfered from one nfo rule to another one
19:11:39 <andythenorth> if you read the chain of IDs it's usually trivial
19:11:47 <andythenorth> nfo is remarkably, pleasingly simple in that respect
19:11:52 <andythenorth> not in others :P
19:12:12 <andythenorth> I'm not convinced that the globally scoped identifiers are a significant win
19:12:21 <andythenorth> they might be a bad design
19:12:35 <Alberth> it's easy to implement, perhaps
19:12:53 <andythenorth> that's very important
19:12:58 <andythenorth> perhaps the most important thing
19:13:08 <andythenorth> bad designs aren't bad necessarily
19:13:32 <andythenorth> every time I use nml, I'm grateful for it
19:15:01 <andythenorth> the consistent use of ${vehicle.id} in BANDIT is telling
19:15:01 <andythenorth> switch (FEAT_ROADVEHS, SELF, ${vehicle.id}_articulated_cb_switch, extra_callback_info1) {
19:15:15 <andythenorth> every identifier uses that pattern
19:15:21 <andythenorth> which suggests scopes :P
19:15:34 <andythenorth> and if we had scopes, we could have partial compile
19:17:00 <andythenorth> no partial compile while identifiers *might* be global
19:17:41 <andythenorth> compile of a grf like FIRS needs to be in ~10s range
19:23:08 <Alberth> I think it is not enough; you need the concept of a code-thingie with some 'holes' in it, which does not exist (for nml, nfo, nor grf)
19:26:33 <frosch123> wasn't the longest time for nml the encoding of the realsprites?
19:26:42 <andythenorth> Alberth: you mean, 'a template' ?
19:27:17 <Eddi|zuHause> frosch123: that is "fixed" by using grfcodec
19:27:17 <frosch123> so, maybe those should be preencoded
19:27:42 <Eddi|zuHause> frosch123: nml outputs to nfo, nfo is processed by grfcodec
19:27:54 <frosch123> does andy also do that?
19:28:00 <andythenorth> nobody seriously encodes the grf with nmlc
19:28:10 <andythenorth> at least if they can figure out how to hack their makefile to avoid it :P
19:28:12 <Eddi|zuHause> yes. he copied that from CETS
19:28:26 <andythenorth> nml -> nfo -> grfcodec is *significantly* faster
19:28:32 <andythenorth> everyone should do it
19:29:24 <planetmaker> it's a hack at best
19:29:33 <Eddi|zuHause> andythenorth: you need to add a dependency for the devzone's build farm
19:29:57 <planetmaker> yes, devzone won't build that w/o updating the .devzone spec file
19:30:18 <andythenorth> I'm not committing any of this makefile hacking right now
19:30:24 <andythenorth> I don't trust what I'm doing :P
19:30:59 * andythenorth reverts the makefile changes for safety reasons
19:31:40 <Alberth> you should do such experiments in a clone :)
19:31:54 <andythenorth> FIRS nml -> nfo -> grfcodec is < 11s
19:32:01 <andythenorth> FIRS nml -> grf is < 40s
19:32:18 <andythenorth> maybe I just dev with the quickbuild.sh I made
19:32:23 <andythenorth> and leave the makefile alone for the CF
19:41:01 <Alberth> a template is where you define where the hole is, and you supply its value. Linking copies values from the defining part to the part that needs it, and it is not fixed before you start linking what values are missing, where it should be copied from, or what its value is going to be
19:43:42 <andythenorth> linking sounds like a thing for grown up developers :)
19:44:31 <Alberth> if you want to make it, yes. Using it should be simple, not much more complicated than gcc with .o files :)
19:45:51 <andythenorth> my idea is to be able to call partial compiles on nml
19:45:54 <andythenorth> which is probably bad
19:46:38 <Alberth> grf would be ideal in a sense
19:47:47 <Alberth> although you need a bit more than just grf, as you need to keep track of values you define and values you need (names, offsets, and value)
19:51:15 <Alberth> the 'only' problem is however that currently nothing generates partially compiled output, so it's a format without any users.
19:53:15 <planetmaker> well. With container format v2, one could possibly write chunks of that in separate files or so. And then combine that
19:54:57 <Alberth> too many nice projects, and too little time :(
20:06:23 <planetmaker> Did I mention that I really like the output of your lang check script, Alberth?
20:06:55 <Alberth> not before now :) thanks :)
20:07:43 <planetmaker> I'm just pondering how the best way to get it flying.
20:07:51 <planetmaker> Probably make it part of the makefile frameworkß
20:08:04 <planetmaker> then every project has it and it can be called. Also offline by authors
20:08:15 <planetmaker> Ammler suggested to make --html the default
20:08:25 <planetmaker> it would mean the existing CF need not really change
20:08:40 <planetmaker> just the files which need copying to the bundles server
20:09:16 <Alberth> the script queries and builds a cache of old revisions of the master language, if it can process several languages in the same run, it would become cheaper
20:10:15 <planetmaker> can it or would it be a (future) enhancement?
20:10:55 <Alberth> currently you cannot do that, mostly because you cannot express it to the script
20:11:54 <Alberth> ie I don't destroy any data I build in the process, so just chaining several calls together inside the script should work
20:12:47 <Alberth> but you need to be able to say *.lng, and have a different way than > x.html for catching output :p
20:13:18 <planetmaker> w/o stating it explicitly
20:13:23 <planetmaker> and just --all instead
20:14:24 <Eddi|zuHause> Alberth: not in CETS
20:14:53 <Alberth> we need at least one project to confirm the rule :p
20:14:59 <Alberth> but ok, it's not thus :)
20:15:04 <Eddi|zuHause> Alberth: we use ".lng.in", because we add strings
20:15:16 <planetmaker> what do you mean with ".lng is fixed"? The extension?
20:15:50 <Alberth> yes, otherwise you have to state what extension is safe to cut
20:17:50 <Alberth> so something like "cl --html -d --extension=.lng --output-dir=foo lang/english.lng lang/*.lng" <-- where the second english.lng should silently get ignored
20:18:25 <Eddi|zuHause> Alberth: "--master lang/english.txt"?
20:18:34 <Alberth> giving you foo/*.html, I guess
20:18:46 <Eddi|zuHause> Alberth: and use "english" as default when nothing is given
20:19:39 <Alberth> Eddi|zuHause: to make the master language a bit more explicit? could be, but is more typing when called manually
20:20:20 <Eddi|zuHause> Alberth: well, if you add a default value, you actually have less typing :p
20:21:20 <Alberth> Currently, I don't do magic searches for *.lng files, so unless you are in lang, and your master file is called 'english', it won't work :p
20:21:48 <Eddi|zuHause> Alberth: and if you give it an --input-dir and an --extension, then you can ommit all the lang/*.lng, and have it just go through all files in the directory
20:21:49 <Alberth> but defaults should be looked into as well
20:23:50 <Alberth> now we just have to extend the nml format to state that translations are up-to-date even when the revisions say otherwise, and extend to state strings don't need translations :p
20:25:13 <supermop> can railtypes have custom foundations?
20:25:24 <Alberth> oh, and multi-line strings too of course (which is still in the inqueue of nml :( )
20:26:00 <planetmaker> railtypes have no foundations
20:26:09 <planetmaker> they use the default ones, if needed
20:27:39 <supermop> can i use any sprite template of my creation for railtypes, or must i draw sprites in the same order as the originals
20:28:40 <Alberth> as long as you mention them in the right order in nfo or nml, it should be fine, I think
20:29:08 <Alberth> at least I don't see how that could break
20:29:50 <supermop> and can I add both the 1x and 4x sprites in nml?
20:33:06 <planetmaker> you can add any zoom level or bit depth which OpneTTD supports
20:33:10 <planetmaker> You must supply 8bpp 1x
20:40:41 *** andythenorth has left #openttd
20:56:38 *** Prof_Frink has joined #openttd
21:21:44 *** theholyduck has joined #openttd
21:38:48 <Ammler> planetmaker: having --html as default was just an example, not really important, if the synstax isn't exactly the same as current
21:39:10 <planetmaker> what is important then?
21:39:30 <planetmaker> and what is nice to have?
21:40:11 <Ammler> either exact the same as now or it does not matter at all
21:41:59 <Ammler> if I got that right, just read partially back :-)
21:42:56 <Ammler> well, cache might be usefull, if you run it locally...
21:45:53 <planetmaker> cache as in not generating the info for the default language over and over when creating output for any language file.
21:46:22 <Ammler> ah ok, so not meant to be used over different revs?
21:46:35 <planetmaker> no... over different lang files
21:46:55 <planetmaker> so, yes. Not meant to be used over revs. Over lang files
21:47:10 <planetmaker> or that's how I understood it
21:47:27 <Ammler> ok, never mind then...
22:03:37 <Zuu> Ammler: At the bundles server of openttdcoop.org, do you always keep the bundles now in a /releases/ path appended to the path given in the finger?
22:04:23 <Zuu> Eg, can I fix OTTDAU by assuming the /releases/ path or will that break in some cases?
22:08:51 <Zuu> According to the syntax definition at finger.openttd.org, the third column should be the path it the binaries server. However, if you add /releases/ there, it breaks identification of those items as there is no other ID-column. So perhaps the best is that I implicitly adds it if the finger-address is the openttdcoop server.
22:10:42 <Zuu> hmm, I just prove me wrong. yacd doesn't have a "releases" directory added to the path. So it is not predictable for all items.
22:37:25 <Ammler> afaik, it is like the finger file on openttd.org
22:37:49 <Ammler> but there is also LATEST
22:54:01 *** Maarten has joined #openttd
22:58:32 *** EyeMWing has joined #openttd
22:59:29 *** Rhamphoryncus has joined #openttd
23:05:52 <Zuu> yes yacd works correctly like finger on openttd.org, however cargodist does not, as there is no way to resolve the path using only the information in the finger-file of openttdcoop.org
23:06:46 <Zuu> Other than hardcoding that for cargodist one has to insert the /releases/ directory at the right place of the URL.
23:25:31 *** Hazzard has joined #openttd
23:31:10 *** Keyboard_Warrior has joined #openttd
23:52:21 *** holyduck has joined #openttd
23:57:37 *** ccfreak2k has joined #openttd
23:59:44 *** Keyboard_Warrior has quit IRC
continue to next day ⏵
