IRC logs for #openttd on OFTC at 2011-10-01
⏴ go to previous day
00:04:06 *** Strid__ has joined #openttd
00:04:17 <Elukka> ah, no more 360mm curves on the main bend...
00:09:18 <Eddi|zuHause> i'm amazed by your complete lack of track geometry :)
00:10:37 <Elukka> why did i ever decide to make this out of sectional track?
00:11:28 <Elukka> how i'm actually gonna solve that detachable bridge to the coal mine table... well that's a mystery
00:11:59 <Eddi|zuHause> curvy bridges are nasty
00:12:46 <Elukka> yeah that'll be.... a challenge
00:13:01 <Elukka> but i dunno how i'm gonna attach it to the mountain side in a non-terrible-looking way
00:13:06 <Elukka> on the main table's side
00:13:23 <michi_cc> I don't think the bottom curve on the main table can fit two trains at the same time...
00:13:30 <Elukka> i was just gonna test that
00:13:34 <Elukka> it probably doesn't, true
00:14:00 <Eddi|zuHause> you don't seem to have a lot of space to place walls there
00:15:05 <Eddi|zuHause> a bridge usually lies on a wall on the mountain end
00:15:30 <Elukka> there's no reason the bridge can't start earlier
00:15:43 <Elukka> it's the technical side of things i'm worried about
00:17:23 <Eddi|zuHause> not sure what you mean then
00:19:27 <Elukka> how to actually build it so it's easy to attach and detach yet doesn't look completely terrible
00:21:39 <michi_cc> Check if models going into the curve on the track below the bridge don't swing out su much the would conflict with walls or pillars of the sloping track.
00:24:26 <Elukka> i'll just have to put any wall or pillars far enough
00:24:59 <Elukka> curve should be more workable now...
00:25:26 <Elukka> i originally had it like this
00:25:50 <Elukka> longer tracks for the station area but longer wagons looked terrible on the curve since the turnouts were 360 mm
00:27:49 <michi_cc> Eddi|zuHause: Note to my paste: NML r1673 makes it redundant (thanks Yexo :)
00:28:25 <Eddi|zuHause> michi_cc: did you check the difference in sprite count?
00:30:31 <michi_cc> Not the exact number, but it's not very much, as most vehicles have simpler availability checks so the savings aren't that big.
00:31:54 <Eddi|zuHause> probably more things can be saved if nml kept results available until register pressure forces them out
00:32:30 <Eddi|zuHause> and gather all action0 in one place
00:52:45 *** supermop has joined #openttd
01:05:07 *** supermop has joined #openttd
01:23:25 <planetmaker> good night or morning
01:24:10 <supermop> how is it going in Germany?
01:27:39 <planetmaker> tired :-) Thus... see you another night :-)
03:39:41 <z-MaTRiX> mov ax;$a000;mov es,ax
04:56:17 *** Eddi|zuHause has joined #openttd
06:14:33 *** Kurimus has joined #openttd
06:15:24 *** sla_ro|master has joined #openttd
06:44:13 *** andythenorth has joined #openttd
07:21:32 *** Alberth has joined #openttd
07:21:32 *** ChanServ sets mode: +o Alberth
07:43:41 *** andythenorth has joined #openttd
07:51:28 *** JVassie has joined #openttd
08:14:16 *** mahmoud has joined #openttd
08:32:43 *** Progman has joined #openttd
08:58:24 *** Brianetta has joined #openttd
09:07:31 *** RichardBarrell has joined #openttd
09:07:49 *** |Jeroen| has joined #openttd
09:26:48 *** xmirakulix has joined #openttd
09:48:21 <Eddi|zuHause> so we have a version 1.1.13 now?
09:48:52 <planetmaker> the lucky version
09:49:43 * Rubidium wonders what he's missing... tt-ms?
09:51:52 *** Devroush has joined #openttd
09:52:45 *** frosch123 has joined #openttd
10:00:58 *** DayDreamer has joined #openttd
10:12:44 <Eddi|zuHause> hm... i don't think we need "special transport wagons for luxury horses"
10:18:23 *** KenjiE20 has joined #openttd
10:31:43 <Eddi|zuHause> apparently the DRG built 5 of these in 1935 prior to the olympic games, they were refitted with express wagon bogies
10:49:25 <__ln__> Wolf01: that's a shortened version of the original which is about as old as the internet.
10:50:06 *** Brianetta has joined #openttd
11:11:57 *** valhallasw has joined #openttd
11:16:54 *** Doorslammer has joined #openttd
11:22:16 *** Biolunar has joined #openttd
11:23:15 <xmirakulix> I just updated the extrazoom patch(es) to apply against the current trunk
11:23:41 <xmirakulix> does anybody have deeper knowledge about patch queues in mercurial?
11:24:43 <xmirakulix> Does it support you in maintaining patches that mutually depend on each other in order to compile?
11:25:21 <planetmaker> a queue is actually exactly that: a stack of patches. The firs depends on nothing. The next (can) depend on the first. etc
11:25:41 <planetmaker> then I didn't understand your question :-)
11:26:00 <xmirakulix> but in the ez repo the two patches on top of each other depend mutually each on another
11:26:01 <Ammler> the order defines the dependency...
11:26:06 <Eddi|zuHause> Wolf01: i've seen a version of that with explanations what actually happened
11:26:30 <xmirakulix> so the lower doesn't compile with the one on top
11:26:48 <planetmaker> then it would make sense to make it one patch, wouldn't it?
11:27:05 <Eddi|zuHause> xmirakulix: either merge them, or split them further apart
11:27:07 <xmirakulix> yes, I thought that too :)
11:27:13 <planetmaker> each patch can be whatever you want. Of course you can make a patch which will break compilation and only fix that in a subsequent patch
11:27:35 <Ammler> you can't apply the lower without applying the higher, without moving
11:28:47 <Terkhen> I prefer to use patches that are "complete": you should be able to compile each one requiring only all the previous ones
11:28:52 <Terkhen> that way it is way less confusing
11:29:05 <Terkhen> and it is easier to test each one if you need to go back and make changes
11:29:11 <planetmaker> xmirakulix: what you can do with mq is "guard" patches. That is tell a patch further down in the queue to only apply when another patch has been applied previously
11:29:21 <xmirakulix> thats exactly my opinion Terkhen
11:29:43 <planetmaker> xmirakulix: I guess most people in this channel have that opinion ;-)
11:30:58 <planetmaker> "as small as possible / sensible". But never break compilation
11:31:55 <xmirakulix> just wanted to know, if mercurial had any magic to deal with this. seems it hasn't :)
11:32:23 <Ammler> he, it has, people just do not prefer it
11:34:21 <Ammler> multiple patches depending on others
11:34:33 <xmirakulix> not compiling patches
11:34:56 <xmirakulix> mutually depending patches
11:34:58 <Terkhen> I never had the need to use something like that so I can't help you there
11:35:01 <Alberth> mercurial does not require compilability, you do
11:35:09 <Ammler> you are not able to apply patch2, if patch1 isn't applied
11:35:57 <Ammler> quite simple dependency, isn't it? :-)
11:36:21 <Alberth> xmirakulix: mercurial as well as most other VCSes do not say how to use them, you can use them in any way you prefer. The trouble is of course that you have to find an approach that you like :)
11:36:35 <xmirakulix> Ammler: No it isn't in case of the extra zoom patches on openttdcoop
11:36:50 <Ammler> that is just one patch there
11:37:21 <Ammler> the compilefarm.diff is ignoreable...
11:37:30 <xmirakulix> no, its a queue that contains along with others the ez.diff and the lookupcolour.diff that depend on each other
11:37:44 <planetmaker> xmirakulix: a bit besides the current point: do you just want to update the extra zoom patch or do you want to really implement the feature? :-)
11:37:54 <Ammler> bot patches don't work alone?
11:37:59 <Alberth> xmirakulix: so your pre-decessor clearly had different ideas about how to use the queue
11:38:00 <planetmaker> Personally I think the EZ needs to be completely separate from 32bpp...
11:38:15 <xmirakulix> Alberth: yes, thats now obvious to me :)
11:38:25 <xmirakulix> Ammler: no, they dont
11:38:44 <Ammler> ok, that is silly, imo
11:39:09 <xmirakulix> and a pain to maintain and test
11:39:11 <Ammler> xmirakulix: if you prefer, you could also make fork/branch instead mq
11:39:35 <xmirakulix> that's how I do it in my local git repo
11:40:14 <Ammler> the ez patch on devzone is kinda stalled
11:40:42 <Alberth> forking/branching has the disadvantage that pulling the patch into small pieces is non-trivial
11:40:45 <Ammler> but on the other side, you chould be able to create a patc from your git and reaplce the hg mq
11:41:03 <xmirakulix> yeah, that's why I updated it today, LordAro asked me to update the separate patch files, so they can be published there
11:41:03 <Ammler> Alberth: merging is easier imo
11:41:17 <planetmaker> xmirakulix: like Ammer says, the EZ there is stalled... it probably would be nice if someone would pick it up again
11:41:33 <Alberth> Ammler: not for trunk-inclusion, where you need many small patches
11:42:34 <planetmaker> xmirakulix: personally I have the idea that zoom should work independent of blitter
11:42:46 <planetmaker> and the whole thing could be cut into two separate queues:
11:43:14 <Ammler> planetmaker: you should also think about, if it is really worth to keep 8bpp
11:43:16 <planetmaker> a) zoom b) extra sprites for other zoom levels and maybe c) improve 32bpp blitter / handling
11:43:57 <Alberth> Ammler: ditch all newgrfs?
11:44:02 *** Brianetta has joined #openttd
11:44:19 <Ammler> Alberth: last time I checked, I was able to use newgrfs with 32bpp blitter
11:44:29 <planetmaker> then one has no issue there
11:44:56 <TrueBrain> (wrong game, but I dont care :P)
11:45:19 <xmirakulix> could you give me a head up on the plans on trunk inclusion of any of a, b or c?
11:45:41 <planetmaker> xmirakulix: all three are desirable features
11:45:42 <frosch123> is opendune already ported to the quake engine?
11:45:58 <TrueBrain> frosch123: depends; did you make the plans for that and executed them?
11:46:17 <planetmaker> but I think a) is the most important one
11:46:17 <TrueBrain> (why on earth would anyone want to 'port' a 2D game to a 3D engine?)
11:46:22 <Terkhen> I remember a nice thread about scaling methods for a)
11:46:24 <planetmaker> as b) clearly would depend on it
11:46:51 <Terkhen> TrueBrain: someone at tt-forums is suggesting to port OpenTTD to the unreal engine :)
11:46:55 <planetmaker> Terkhen: that's where I bookmarked that page from
11:47:13 <TrueBrain> Terkhen: what is wrong with that person?
11:47:33 <frosch123> TrueBrain: nothing, he will present his results in only 6 months :)
11:47:36 <TrueBrain> people do love their random suggestions, dont they?
11:47:48 <TrueBrain> frosch123: like the C# port I guess?
11:47:50 <Terkhen> nothing, the suggestion is wrong, not the person :P
11:48:10 <frosch123> TrueBrain: who cares about c# :) today they want facebook apps :p
11:48:25 <Eddi|zuHause> there's plenty of these suggestions as well :p
11:48:44 <TrueBrain> Terkhen: to come up with something like that, you do need one twisted mind, or a very small IQ :P
11:49:03 <TrueBrain> frosch123: lolz; I got asked by a customer if we too compile our PHP code via the facebook compiler
11:50:02 <Terkhen> you got to be kidding :P
11:50:47 <xmirakulix> You know that they do "compile" php code?
11:51:03 <xmirakulix> It's called HipHop, translates php code to c++
11:52:51 <TrueBrain> xmirakulix: I just said that, didn't I?
11:54:02 <xmirakulix> TrueBrain: Yes you did :)
11:54:35 <TrueBrain> you just wanted to show off, ah, I see :)
11:56:50 <Alberth> however, xmirakulix showed me that the customer is less crazy than I thought.
11:57:38 <Alberth> as in, he was referring to an actual piece of software :)
11:57:47 <xmirakulix> that was my original intention :)
11:58:39 <frosch123> now i wonder what is worse: git, php, hiphop or facebook
11:58:58 <planetmaker> frosch123: a combination thereof ;-)
12:03:58 <TrueBrain> Alberth: you didn't know? Pfff :P
12:04:03 <TrueBrain> one of the worst inventions ever :P
12:04:24 <TrueBrain> to improve performance of a broken language by compiling it to a sane language ... the world is doomed ;)
12:05:42 *** TWerkhoven has joined #openttd
12:07:10 <frosch123> damn... i put a hangar into the orders instead of the airport, and wondered why it does not make any profit :p
12:07:17 <Alberth> I stay far enough away from horror software to miss such 'news' completely
12:07:23 <TrueBrain> frosch123: you play the game?
12:07:33 <Eddi|zuHause> frosch123: typical newbie mistake :p
12:07:39 <Alberth> TrueBrain: we pay him to do that :)
12:07:47 *** mahmoud has joined #openttd
12:07:50 <TrueBrain> wuth? He gets paid?! :P
12:23:45 *** Chris_Booth has joined #openttd
12:41:24 *** vpelletier has joined #openttd
12:41:55 *** rhaeder has joined #openttd
12:44:15 <vpelletier> hi. I'm new to openttd (and ttd in general), and started to play with 1.1.3 (debian sid). I find the window placement quite annoying on a large screen (1920x1200), as very often new windows are spawned at what feels like the furthest possible screen location from cursor...
12:44:55 <vpelletier> is there a way to tweak that ? (didn't find anything about this in advanced settings, although I did find sticking-window-border distance setting)
12:45:28 <planetmaker> iirc, the only way would be to change the source code
12:52:52 <vpelletier> found in the code, thanks
12:54:00 *** Brianetta has joined #openttd
12:56:46 <frosch123> first time someone is happy about that answer :)
13:16:46 *** Adambean has joined #openttd
13:20:19 <Eddi|zuHause> planetmaker: is it normal that scripts/Makefile.in contains the line "clean::" with two :?
13:20:53 <planetmaker> Clean is a double-colon target. All occurances work independently of eachother
13:21:07 <Eddi|zuHause> what's the meaning of it?
13:21:40 <planetmaker> thus one can add additional clean code without changing where the original code is implemented
13:21:46 <planetmaker> all parts executed, but independently
13:22:12 <Eddi|zuHause> my syntax highlighting seems to fail on that... or i don't understand it
13:22:28 <planetmaker> thus the clean:: in Makefile.in cleans only that part which Makefile.in also generates.
13:22:43 <planetmaker> It's called in parallel (or before or after) the clean:: target in Makefile.common
13:22:48 <Eddi|zuHause> yeah, i think i get it
13:23:06 <Eddi|zuHause> i just have never seen this before, and it looked weird
13:23:36 <planetmaker> for clean it's the cleanest solution for making it modular (pun intended ;-) )
13:24:03 <Elukka> "Small cattle shed cars to model sheet A8 genus districts Altona"
13:24:12 <Elukka> "For the promotion of small livestock (pigs, calves, sheep, goats, poultry). Unloaded compartments are loaded with individual pieces by exploiting animals."
13:24:48 <Eddi|zuHause> i think it's about 70% accurate :)
13:25:22 <xmirakulix> poor exploited animals…
13:26:04 <vpelletier> is there a way to build openttd to run from working copy ? it compalins about not finding opensfx (otherwise available from system, installed by package)
13:26:19 <frosch123> whoo, my gold mine increased from 6 to 18 bags a month
13:26:28 <Eddi|zuHause> the grammar is a little off... the "exploiting" ("ausnutzen") refers to optimal space usage. not the animals
13:26:32 <frosch123> now 2 helicopters cannot handle it anymore :p
13:27:08 <Eddi|zuHause> how is 6 pieces per month even possible?
13:27:34 <Eddi|zuHause> when the industry produces 8 to 9 times a month
13:27:40 <planetmaker> vpelletier: if opensfx is installed in the default localtion it *should* work.
13:27:46 <Elukka> Eddi, i figure 'association type' refers to standardized wagons of the german... something... railway car association, but what's interfchange type and what do the city names in wagon classes refer to?
13:28:28 <Eddi|zuHause> "interchange" because most parts were standardized by then, so replacement parts could be easily interchanged
13:28:46 <xmirakulix> vpelletier: you should have an OpenTTD folder in your homedir
13:29:11 <vpelletier> planetmaker: $ dpkg -L openttd-opensfx\n[...]\n/usr/share/games/openttd/data/opensfx-0.2.3.tar\n[...]
13:29:32 <vpelletier> no idea what is standard :)
13:29:42 <planetmaker> the readme tells you /usr/games
13:29:49 <planetmaker> thus your distro uses a non-standard path
13:29:58 <planetmaker> and probably put the other things also in a non-standard path
13:29:59 <frosch123> Eddi|zuHause: by transferring the cargo in units of 6 to the station
13:30:07 <planetmaker> and compile openttd also to use the non-standard path
13:30:15 <planetmaker> which fails on self-compiled binaries
13:30:22 <Eddi|zuHause> vpelletier: the path must be given to configure
13:30:26 <planetmaker> (unless specifically told to change that, too)
13:31:17 * vpelletier slaps himself a bit around with a trout
13:31:20 <Eddi|zuHause> something along the lines of "./configure --shared-dir=/usr/share/games"
13:31:34 <vpelletier> I used /usr/games/openttd as the prefix...
13:31:44 <vpelletier> whereas /usr works
13:32:58 <vpelletier> time to test my revolutionary window placement algorythm...
13:39:12 <Elukka> always thought the bavarian coal cars looked american, apparently they were based on american ones
13:41:21 *** Progman has joined #openttd
13:57:48 <vpelletier> as such, it deadcode-ify auto placement function
13:59:34 <vpelletier> but at least, with this code I'll stop having to move all the way through the screen for the just-opened window
14:00:04 <vpelletier> I'll try to play with this more than just testing to see if it's easier to live with than original auto-placement
14:10:22 <frosch123> it will likely suck when opening multiple windows in a row
14:10:26 <frosch123> like pressing clone multiple times
14:12:53 <vpelletier> it will also probably suck with a stylus, as I read it is supported in the code
14:13:24 <vpelletier> I initially wanted to place window next to its parent, finding closest open space...
14:13:48 <vpelletier> but the code is much more complex, and requires knowing parent position - which I couldn't find from a quick search
14:13:54 <vpelletier> so I went with cursor position
14:15:12 <Alberth> w->left and w->top :)
14:15:52 <Eddi|zuHause> designing proper UI is tricky :)
14:18:40 <vpelletier> Eddi|zuHause: indeed. and I don't intend to blame auto-placement code author :)
14:19:02 <vpelletier> Alberth: I thought it was the toolbar
14:19:18 <Eddi|zuHause> vpelletier: most of the UI is from before "standard" GUIs like Windows were widespread
14:19:36 <Alberth> vpelletier: everything is a window, including the toolbar and the main display
14:19:42 <vpelletier> I mean, I don't know which is the parent winfow from which new one is created
14:20:11 <vpelletier> Alberth: indeed, but I don't know how to get the right "w"
14:20:12 <Alberth> w->parent not filled in at that time?
14:20:34 <vpelletier> mmh, I didn't notice a ->parent was available
15:07:29 *** valhallasw has joined #openttd
15:08:45 *** DayDreamer has joined #openttd
15:43:39 *** Brianetta has joined #openttd
15:59:54 *** Cybertinus has joined #openttd
16:00:47 *** sla_ro|master has joined #openttd
16:10:27 *** vpelleti1r has joined #openttd
16:23:24 *** vpelleti1r is now known as vpelletier
16:45:27 <CIA-2> OpenTTD: frosch * r22968 /trunk/src/ (ai/api/ai_road.cpp road_cmd.cpp): -Feature: Allow road corners on steep slopes.
16:46:27 *** Chris_Booth has joined #openttd
16:47:24 <Eddi|zuHause> have i mentioned that i need "inverse foundations" to lay double tracks along a slope?
16:48:12 <frosch123> i always build those on two levels
16:49:38 *** mahmoud has joined #openttd
16:53:08 <Eddi|zuHause> there are a few other situations where you occasinally need to cut into the mountain
16:53:19 <Eddi|zuHause> like trying to place a wide curve
16:56:05 <Wolf01> frosch123, what's allowed more than before with this feature?
16:56:33 <frosch123> before steep slopes allowed only straight uphill roads
16:56:42 <frosch123> now you can build a corner at the top
16:57:09 <Wolf01> uhm, maybe I don't remember well the game
16:57:15 <Eddi|zuHause> can town houses already be placed on steep slopes?
16:57:41 <frosch123> i guess default ones cannot
16:58:06 <frosch123> however, we need a solution for building on steep slopes with the highest corner in the south
16:58:41 <frosch123> build a half road on the top and then try to turn it into a straight downhill road :p
16:59:23 <Eddi|zuHause> we need it displaying the road bit
16:59:31 <Eddi|zuHause> nobody ever implemented that
16:59:51 <Eddi|zuHause> there are sprites for that in the forum
17:00:12 <Eddi|zuHause> i mean similar to how autorail displays the rail bit
17:01:43 <frosch123> does not help in this case :p
17:02:09 <frosch123> maybe the mouse movement should consider the direction it comes from
17:02:41 <frosch123> so the selection stays behind the foundation when approaching from the back, and it stays on the foundation when approaching from the front
17:04:16 *** JVassie has joined #openttd
17:04:45 <Eddi|zuHause> all that needs is a "trigger" whether the curser left the currently selected tile
17:17:38 *** LordAro has joined #openttd
17:19:23 <Rubidium> LordAro: after sunset ;)
17:20:27 * LordAro doesn't see how that is bad...
17:21:22 <Rubidium> are you sure sunset hasn't passed for you yet?
17:21:40 <LordAro> (i can't see outside atm)
17:21:56 <Rubidium> it's pretty light outside for me as well, yet the sun has set already
17:23:54 * LordAro stops googling, and remembers why he came on here
17:24:26 <LordAro> is there a good example in ottd code i can code for converting a char* to utf format?
17:26:09 <Rubidium> utf8 is an encoding that uses chars as storage
17:26:20 <Rubidium> but there are many other encodings that use chars as storage
17:27:32 <Rubidium> so the real question is what encoding you want to convert the input data from is
17:28:07 <Rubidium> and whether that encoding uses a single byte or multiple bytes
17:28:09 <Alberth> wouldn't just utf-8 support not be enough?
17:28:36 <LordAro> Alberth: that is the intention :)
17:28:49 <Alberth> given that you cannot in general guess the encoding from a file
17:30:01 <Alberth> if so, Utf8EncodedCharLen could be the elementary function
17:30:50 <Alberth> hmm, you may also need to really convert to code points otherwise you cannot detect whitespace and such
17:31:25 <LordAro> the name 'oberhuemer' (with umlout) is a good testing example - the 'u' is displayed in the grf (short) description, but is just a '?' in the readme
17:31:25 <Alberth> have a look in string.cpp & friends for some functions
17:31:31 <Rubidium> in any case, OpenTTD assumes that all internal strings are utf8 encoded strings
17:32:33 * frosch123 would blame the readme in first instance as well
17:32:33 <Alberth> another good reason to assume utf-8 (otherwise you'll have to convert your encoding to utf-8 :)
17:33:08 <LordAro> so... what do i have to do? :)
17:33:34 <Alberth> LordAro: it is possible that 'oberhuemer' is not utf-8, but eg some windows encoding
17:34:08 <LordAro> true - i guess strings in grfs are automagically converted to utf-8
17:34:45 <Alberth> nothing automagic there either, it is all programmed (but not by us) :p
17:34:46 <Rubidium> LordAro: somewhat sometimes, though generally they are just utf8 encoded
17:35:49 <Rubidium> or plain ASCII, in which case they are (by definition) utf8 encoded as well
17:36:29 <LordAro> so, do i need to do anything, or just 'blame the readme'?
17:37:43 <Alberth> LordAro: convert the readme to utf-8 to check :p
17:37:58 <Rubidium> ghehe... then you first need to guess the encoding
17:38:13 <Rubidium> though, iconv may help you
17:38:33 <Rubidium> and `file` may tell you the encoding (in some cases)
17:38:53 <Rubidium> iconv is a tool for codepage conversions
17:45:23 <CIA-2> OpenTTD: translators * r22969 /trunk/src/lang/ (4 files):
17:45:23 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:23 <CIA-2> OpenTTD: simplified_chinese - 3 changes by sebastian_my
17:45:23 <CIA-2> OpenTTD: traditional_chinese - 4 changes by sebastian_my
17:45:23 <CIA-2> OpenTTD: danish - 2 changes by beruic
17:45:24 <CIA-2> OpenTTD: latvian - 25 changes by Parastais
17:46:05 <LordAro> Rubidium: ok, is it used in the source anywhere?
17:47:00 *** DayDreamer has joined #openttd
17:47:00 *** DayDreamer has left #openttd
17:47:32 <Rubidium> LordAro: just some OSX code
17:48:13 <Rubidium> but you shouldn't use it in OpenTTD as you can't correctly guess the codepage. I mentioned it so you can convert the oberhuemer readme to utf8 for testing
17:49:29 <LordAro> oh, and i think i found a bug - view the description of the icarus set (5.3 IIRC)
17:49:48 <LordAro> comes up with 'DrawString being used to draw newlines' etc
17:52:32 <Rubidium> might be a difference between '\r\n' and '\n'
17:53:18 <LordAro> should i make a ticket? or will it be fixed in the next few minutes? :)
17:54:49 <LordAro> that looks like it :)
17:55:23 <LordAro> but surely ottd should handle it (better)?
17:56:02 <Yexo> how should it handle it better?
17:56:08 <Yexo> nothing actually goes wrong
17:56:35 <LordAro> "please notify the developers of this"
17:57:12 <Yexo> at that point openttd can't determine where the string came from
17:57:15 <frosch123> we could add a blacklist of broken grfs :p
17:57:33 <Alberth> LordAro: 'this' meaning the newgrf
17:58:51 <LordAro> if title has a newline in it, [strip/do not show/whatever] newgrf
18:03:05 *** jonty-comp has joined #openttd
18:16:15 *** Chris_Booth has joined #openttd
18:17:15 *** HerzogDeXtEr has joined #openttd
18:29:45 *** JVassie has joined #openttd
18:36:30 *** KenjiE20 has joined #openttd
19:10:34 *** Chris_Booth has joined #openttd
19:13:37 *** erik1984 has joined #openttd
19:36:37 *** z-MaTRiX has joined #openttd
19:37:03 *** TWerkhoven[l] has joined #openttd
19:37:39 <Eddi|zuHause> yeah, probably not.
19:40:38 *** supermop_ has joined #openttd
20:03:41 <Elukka> amazing how much stuff we've shot up to space
20:04:00 <Elukka> while i was out for perhaps 15 minutes, discussing life, the universe and everything with a friend
20:04:16 <Elukka> we saw four satellites (and a couple meteors)
20:04:54 <Elukka> and jupiter was bright as hell
20:06:39 <Eddi|zuHause> <Alberth> given that you cannot in general guess the encoding from a file <-- if you encounter a non-utf8 character, you can try to use an ASCII-esque fallback, like windows-1252, which will be "good enough" unless you have cyrillic texts
20:11:35 <Eddi|zuHause> and if you meet lots of \0 characters, you can try utf16
20:13:57 <Alberth> some ad-hoc heuristic is stil 'not guessable in general' imho :)
20:14:37 <Eddi|zuHause> no, of course not
20:15:11 <Eddi|zuHause> but sometimes a bad heuristic is giving waaaay better results than the best exact algorithm :p
20:15:29 <Eddi|zuHause> (especially if no exact algorithm exists)
20:20:10 <Rubidium> I'd not make any effort; just document openttd only supports utf8 readmes
20:21:23 <Rubidium> saves so much effort
20:31:23 <CIA-2> OpenTTD: rubidium * r22970 /trunk/src/ (newgrf.cpp newgrf_text.cpp newgrf_text.h): -Fix [FS#4769]: strip newlines from NewGRF strings that should not have newlines, e.g. the NewGRF's name
20:37:12 *** valhallasw has joined #openttd
20:47:24 *** vpelletier has joined #openttd
20:49:26 <vpelletier> as was detected, my window placement code is annoying when copying vehicles. otherwise, it's nicer to me than existing code
20:50:03 <michi_cc> Eddi|zuHause: I think the CETS wagon cargo classes need some special case for FIRS 'BEER' (exp+piece+liquid)
20:50:43 <Eddi|zuHause> put that at the end of the priority list ;)
20:51:17 <Eddi|zuHause> or better: write that into the cargo wagon ticket
20:52:58 <Elukka> oh google translate again
20:53:13 <Elukka> "Märklin Dampflok Br. 50 MFX Sound aus 29500 Neuware"
20:53:15 <Elukka> is "Märklin Steam Locomotive Br 50 29 500 MFX sound from virgin"
20:56:45 <planetmaker> not that I entirely understand the German either
20:59:04 <Rubidium> brand: Maerklin, type: Dampflok BR. 50 MFX, extra info: sound from <location>, where location is postal code and town name ;)
21:01:19 <Elukka> it's just supposed to say 'märklin steam locomotive br 50, mfx sound decoder, new, from the 29500 set"
21:02:55 <planetmaker> Rubidium: 29500 would be very lucky to have that as post code ;-) ... though feasible, of course
21:03:53 <Alberth> just search your new house by postal code :)
21:05:25 <michi_cc> Eddi|zuHause: Ticket commented
21:20:13 *** Monarch1st has joined #openttd
21:20:49 <Monarch1st> are real people on today?
21:21:33 <Monarch1st> i've got a question about openttd stations
21:24:03 <Eddi|zuHause> i have an answer, but i don't know if it fits your question
21:24:32 <Monarch1st> ha! all we do is try it and see
21:24:51 <Monarch1st> i'm trying to set up a advanced 2-bay terminus staion
21:25:31 <Monarch1st> (under the heading 'variations')
21:26:25 <Monarch1st> i've tried to copy it precisely, but whenever there is a train in the right side, it will not let a train out of the right side
21:26:47 <Monarch1st> there seems to be missing a signal that clears the others when the train fully enters the right side
21:26:51 <Monarch1st> am i missing something?
21:27:45 <Monarch1st> sorry that should be will not let a train out of the left side
21:28:07 *** Hyronymus has joined #openttd
21:30:00 <Eddi|zuHause> there's probably one under the bridge that you missed
21:31:49 *** supermop_ has left #openttd
21:32:12 <planetmaker> and.. one can link images directly instead of "2/3 down"
21:32:30 *** supermop_ has joined #openttd
21:33:32 <Monarch1st> didnt know you could put a signal under a bridge - which would it be, vertical bar or horizontal bar, and i'm thinking one way out?
21:33:50 <Eddi|zuHause> Monarch1st: on the way out only normal signals are needed
21:33:58 <Monarch1st> (dont know much about signals, only get the game out once a year or so, and forget what i learned last time!)
21:35:22 <Monarch1st> hey, that did indeed work! cool beans
21:35:40 <Monarch1st> can a not be made on the wiki page marking this?
21:36:54 <Eddi|zuHause> it's a wiki, just put it there
21:42:37 <Monarch1st> my first time editing a wiki. eeeexcellent
21:59:27 <supermop_> hey planetmaker, do you think I should wait for nml before doing anymore work on my grf?
22:05:09 *** Chris_Booth has joined #openttd
23:01:37 <Wolf01> uhm, I can't get the mean of the new "road corners on step slopes" feature
23:01:54 <z-MaTRiX> someone needs data deduplication script?
23:02:26 <Eddi|zuHause> Wolf01: what's the problem? you can now place road curves where you couldn't any before
23:02:44 <Wolf01> that's what I can't get!
23:02:59 *** supermop_ has left #openttd
23:03:53 <Wolf01> i can't found any new road configuration which I wasn't able to build before
23:06:49 <Wolf01> ok, maybe now I understood
23:10:53 <Wolf01> I was clicking in the middle of the tile so I was placing a straight road instead of the roadbit
23:17:12 <Elukka> why are they called steep slopes?
23:17:16 <Elukka> they don't seem any steeper to me
23:18:03 <Eddi|zuHause> they pass 2 heightlevels in one tile
23:19:57 <Eddi|zuHause> so in manhattan metric they have steepness 16hu/16lu, while normal slopes have 8hu/16lu. and even in euclidean metric it would turn out steeper gradient
23:20:42 <Eddi|zuHause> that's also (partly) why we don't have diagonal rails on slopes
23:28:48 *** supermop has joined #openttd
23:31:41 <supermop> Can you have more than 16 station types in one station category?
23:43:03 <Eddi|zuHause> supermop: i was under the impression the limit was 256
23:43:16 <Eddi|zuHause> but i have actually no clue
23:49:43 <supermop> i am grasping at straws
23:49:54 <supermop> as to what might be causing this not to work
23:50:04 <supermop> it's really simple nfo
continue to next day ⏵
