IRC logs for #openttd on OFTC at 2010-03-13
⏴ go to previous day
00:11:01 *** Eddi|zuHause has joined #openttd
00:15:47 <CIA-6> OpenTTD: Yexo * r19395 /trunk/src/ (ai/ai_gui.cpp ai/ai_gui.hpp saveload/afterload.cpp): -Fix [FS#3669]: the AI Debug window didn't open if an AI or library fails to compile when loading a savegame
00:38:33 *** derethor_ has joined #openttd
00:41:45 *** Coco-Banana-Man has quit IRC
01:12:19 <CIA-6> OpenTTD: yexo * r19396 /trunk/src/station_cmd.cpp: -Fix [FS#3690] (r19351): trying to remove a too large rail station rect caused crashes
01:30:42 *** Chris_Booth has joined #openttd
01:31:02 *** Chris_Booth has left #openttd
03:55:09 *** Wizzleby has joined #openttd
05:16:23 *** DanMacK has joined #openttd
05:26:10 *** Wizzleby has joined #openttd
05:33:24 *** Gorillagram has joined #openttd
05:43:07 *** Gorillagram is now known as Pikka
06:11:03 *** Gorillagram has joined #openttd
06:19:39 *** Gorillagram is now known as Pikka
07:04:38 *** DaleStan is now known as Guest753
07:04:38 *** DaleStan has joined #openttd
07:42:54 <Yexo> AIIndustry.IsStrangeIndustry(industry_type_id) <- lol, the api suggestions keep getting funnier
07:43:24 <Yexo> AIIndustry.WhatCargoIsNeededToProceedBeforeThatCargo <- .... at least the naming is clear
08:23:33 <TrueBrain> people are strange, does it make me a stranger (8)
08:31:16 *** einKarl has joined #openttd
08:32:28 *** Terkhen has joined #openttd
08:34:55 <TrueBrain> # The morning has broken, like the first morning
08:35:01 <TrueBrain> # Blackbird has spoken, like the first bird
08:35:08 <TrueBrain> # Praise for the sining, praise for the morning
08:35:15 <TrueBrain> # Praise for the springing fresh from the word
08:42:26 <TrueBrain> # You say goodbye, and I say hello
08:42:33 <TrueBrain> # I don't know why you say goodbye
08:54:22 *** Alberth has joined #openttd
08:54:52 *** Singaporekid has joined #openttd
08:55:19 <Singaporekid> Pikka: stand on dispenser
08:58:25 * andythenorth looking for song lyrics
08:58:32 * andythenorth stops looking for song lyrics
08:59:38 <dih> andythenorth->getNumSongLyricsFound();
09:02:43 * andythenorth is a bit scared of railtypes
09:18:51 <DJNekkid> is the railtypes limit in one game 16 types?
09:32:44 <Pikka> why is my grf doing funny things with station names viz industries... D:
09:33:23 <Rubidium> because that's how you coded it?
09:33:49 <Pikka> but setting property 24 to 0 doesn't stop it.. it just makes it act weird in a different way...
09:35:02 *** devilsadvocate has quit IRC
09:41:19 <Pikka> putting in an actual text id works perfectly... putting 0(0 00) doesn't.
09:47:09 *** Companion_Cube has quit IRC
09:50:49 *** Progman has joined #openttd
09:55:25 *** woldemar has joined #openttd
10:17:43 *** ajmiles has joined #openttd
10:19:18 *** JVassie has joined #openttd
10:19:22 <CIA-6> OpenTTD: terkhen * r19397 /trunk/src/ (lang/english.txt toolbar_gui.cpp): -Add: Enter the starting year at the scenario editor by clicking at the date panel.
11:02:35 *** Doorslammer has joined #openttd
11:24:32 *** fonsinchen has joined #openttd
11:24:55 *** Rhamphoryncus has joined #openttd
11:37:08 *** Coco-Banana-Man has joined #openttd
11:43:04 <OwenS> Oh god. I'vbe just spent hours tracking down what I thought was memory corruption. What was it? This: Fragment* frags[]; private: Size m_hash;. >____M
11:47:31 <SmatZ> I don't see anything obviously wrong in that, OwenS
11:47:51 <OwenS> SmatZ: frags[]. I.E, zero length array (For putting a block of memory at the end of a structure)
11:48:04 <peter1138> which is not at the end
11:48:15 <SmatZ> strange compiler didn't warn
11:48:21 <OwenS> Weird interation of C++ and C99 features not generating an error :p
11:48:56 <OwenS> So my string gets hashed... then the hash replaces the first fragment pointer. Wonderful!
11:51:27 <OwenS> This also explains how the pointer ended up as the ASCII value of 'i'... Because hashing a single character string results in the character's codepoint as it's value :p
11:52:13 <peter1138> lovely hash algorithm ;p
11:52:17 *** ajmiles2 has joined #openttd
11:52:32 <OwenS> peter1138: Same as Java uses. For longer strings, it produces better values ;-)
11:52:50 <OwenS> Besides, I haven't found a better algorithm for UTF-16 strings
11:53:22 <OwenS> it seems std::tr1::hash_value(int i) = i as well :p
11:55:18 <peter1138> people use utf-16? o_O
11:55:31 <OwenS> peter1138: Yes. UTF-8 is slooow to process
11:58:13 <OwenS> (And don't talk about the bloated UCS-4...)
11:59:01 <peter1138> inefficient space wise, but doesn't require any processing for long encodings
11:59:56 <OwenS> Yes, but it's always at least 30% inefficient. UTF-16 surrogate pairs are easy to detect, and you can make the code in the common (none of them) case very fast with a few hints to the compiler
12:01:25 <OwenS> Crash only in release builds...
12:02:45 *** ajmiles3 has joined #openttd
12:23:15 <ashb> OwenS: utf-8 surrogate pairs (or tripples) are just as easy to detect
12:23:58 <OwenS> ashb: Yes, but you encounter them more often, and they're more complex to decode. Also, they can be up to 6 bytes long
12:24:35 <ashb> OwenS: usage outside the BMP is quite rare, isn't it?
12:24:59 <OwenS> ashb: Yes, and both inside and outside are much simpler with UTF-16 ;-)
12:25:47 <ashb> i never write utf8 code myself - i always let something else deal with the hassle of bytes<->code points
12:26:51 <OwenS> My strings are "ropes", so no ready-made library can deal with them ;-)
12:27:22 <OwenS> Aah, UTF-8 is up to 4 characters
12:28:06 <ashb> it depends on your needs wether 8 or 16 is better for you
12:28:35 <OwenS> As I provide easy converter calls to my users, it shouldn't be a problem
12:29:00 <OwenS> (Also, UTF-16 makes it easy to implement conversion to SCSU for minimizing string size in bytecode files :P )
12:30:38 <OwenS> Simple compression scheme for Unicode
12:31:46 <OwenS> Aah, a 6-byte series in UTF-8 means it's actually CESU-8, aka, UTF-16 converted to UTF-8 through codeunits rather than codepoints (So you get two UTF-8 sequences for supplemantary plane characters)
12:32:34 *** frosch123 has joined #openttd
12:32:44 <OwenS> No, it's CESU-8, which is not a Unicode standard, but some things (E.g. Oracle and Java) use it internally
12:33:05 <ashb> seems odd that 'compressing' it takes up more space
12:33:18 <OwenS> Also, quite a few apps generate it because they naively convert UTF-16 to UTF-8
12:33:50 *** Adambean has joined #openttd
12:40:17 *** DaleStan has joined #openttd
12:40:21 *** Biolunar has joined #openttd
12:43:04 *** devilsadvocate has joined #openttd
12:43:47 *** ajmiles2 has joined #openttd
12:48:54 <Rhamphoryncus> OwenS: technically they're actually interpreting UTF-16 as UCS-2, then encoding UCS-2 as UTF-8. UCS-2 doesn't have surrogates (the space is simply unassigned characters), so that's the valid way it would convert to UTF-8
12:49:12 <Rhamphoryncus> ashb: "utf-8 surrogate pairs" is a wtf :P
12:50:08 <ashb> Rhamphoryncus: codepoints U+80 to U+FF take two bytes as utf8 - what else do you call them?
12:50:39 <Rhamphoryncus> par for unicode :(
12:50:53 <ashb> unicode is hard - lets go down the pub
12:50:59 <Rhamphoryncus> "scalar values" is now the unambiguous term, not "code points". Unfortunately the latter is ambiguous for UTF-16
12:51:19 <ashb> doens't the spec use "code point"?
12:52:15 <Rhamphoryncus> The problem is "code point" refers to both the individual two surrogates in a pair, and the collective value they encode
12:52:42 <ashb> i've never seen it used to be anything but the uncode character (U+XXXX)
12:53:37 <OwenS> Rhamphoryncus: The normal term I've seen is "Code point" for a character, and "Code unit" for a 16-bit unit
12:53:43 <Rhamphoryncus> I've also seen surrogates in UTF-32 and UTF-8 :(
12:53:58 <ashb> surrogate in UTF-8 at least makes more sense than in UTF-32
12:54:04 <OwenS> Rhamphoryncus: The afformentioned surrogates means CESU-8, not UTF-8 ;-)
12:54:08 <Rhamphoryncus> OwenS: code point is common historically. Code unit is valid for all 3 encodings
12:54:40 <OwenS> Rhamphoryncus: Heh. Did I get the definitions correct, however? (Except for the size issue there)
12:54:58 <Rhamphoryncus> OwenS: basically yeah
12:55:07 <OwenS> And I'm still calling it String::CodepointIterator not String::ScalarValueIterator :p
12:55:14 <ashb> i usually refer to "byte-sequence" to mean the actualy bytes and "code point" to be the logical unicode character
12:55:19 <Kovensky> IIUC, a code point is unique, it being the U+\d{4,} code
12:55:32 <Kovensky> the only difference is how each unicode encoding encodes those
12:55:41 <Rhamphoryncus> OwenS: well, other than code point being ambiguous
12:55:58 <OwenS> Rhamphoryncus: I'll just have to make the documentation good:p
12:56:00 <Rhamphoryncus> OwenS: it's perfectly valid for CodepointIterator to return a single surrogate
12:56:10 <OwenS> Rhamphoryncus: Not by my API documentation ;-)
12:56:33 <Rhamphoryncus> OwenS: of course. It'd be stupid. What you want is Scalar Values, which is exactly the distinction
12:57:18 <OwenS> Rhamphoryncus: People are more likely to understand CodepointIterator than ScalarValueIterator. And Scalar Value is a horrible term :p
12:57:50 * peter1138 plays doom 2 instead
12:58:03 <Rhamphoryncus> OwenS: only because most people refuse to switch terms.. IMO, unicode itself isn't fully committed
12:58:46 <Rhamphoryncus> What they should have done is rename the old term
12:59:54 <Rhamphoryncus> but then, there's no reason to have surrogate code points in UTF-32 or UTF-8 either
13:00:16 <Rhamphoryncus> Anybody got a time machine?
13:00:18 <OwenS> CESU-8 I kinda understand
13:00:19 <ashb> why not in utf8 but yes in utf16?
13:01:56 <Rhamphoryncus> ashb: do you reserve 0x80 through 0xFF for utf-8 code units?
13:01:57 <OwenS> ashb: Because surrogate pairs are UTF-16's way of representing multiunit characters. UTF-8 has it's own mechanism
13:02:30 <ashb> i always just assumed 'surrogate' was 'this unit isn't a char in its own right'
13:03:15 <Rhamphoryncus> Functionally, a surrogate is only a code unit. Just like utf-8 code units, multiples of them combine to be a single scalar value
13:03:22 <ashb> but utf-16 has code point explicitly used for surrogates
13:03:38 <peter1138> the utf-16 surrogate pairs use codepoints that would otherwise be valid
13:03:42 <peter1138> utf-8 doesn't work like that
13:03:55 <Rhamphoryncus> But since historically UTF-8 wasn't a variable-width, those were considered to be valid (but unassigned) characters
13:04:09 <OwenS> Rhamphoryncus: You mean UTF-16 ;-)
13:04:29 <ashb> oh its to deal with windows wchar_t not being wide enough, isn't it?
13:04:31 <Rhamphoryncus> And I'm well rested too. Unicode talk hasn't melted my brain yet
13:04:37 <ashb> s/deal with/an artifact of/
13:04:40 <Rhamphoryncus> ashb: that's orthogonal
13:05:11 <OwenS> ashb: Lots of systems used UCS-2 characters. Should they change to UCS-4? Why, when that wastes ~12 bytes per character?
13:05:56 <ashb> my point is why do those U+D800-DFFF need to be 'valid code points' - why couldn't they just be encoded differently similar to in utf8
13:06:07 * Rhamphoryncus is still waiting for a UTF-24 encoding
13:06:13 <ashb> OwenS: if only computers weren't so centered around powers of 2, eh?
13:06:36 <OwenS> ashb: Hehe. Weren't so centered around bytes. You'd still be wasting 4 bits per character ;-)
13:06:37 <Rhamphoryncus> ashb: they *don't*. It's a historical accident of retrofitting fixed-width UTF-16 (and UCS-2) into being a variable-width UTF-16
13:07:14 <ashb> like i said earlier - i dont deal with utf16 much, and with the actual mechanics of encoding very rarely
13:07:29 <ashb> my knowledge is enough to recognize utf8 (mis)encodings
13:07:30 <Rhamphoryncus> Originally even the code unit/code point distinction wasn't there. Maybe for UTF-8, but I'd have to find a timeline
13:09:17 *** devilsadvocate has quit IRC
13:10:29 *** woldemar has joined #openttd
13:10:47 <OwenS> Yay! My interpreter times about as fast as Lua :-)
13:11:01 <ashb> what are you interpreting?
13:11:07 <OwenS> ashb: My own language :-)
13:15:20 <Rhamphoryncus> OwenS: does it use LLVM yet? ;)
13:15:38 <OwenS> I want a good speed baseline interpreter too
13:16:25 <Rhamphoryncus> I don't. I want the baseline to be LLVM (just not with fancy profile-guided optimizations). Lets you easily modify how code is generated
13:16:47 <OwenS> The reason I want the interpreter is for systems where LLVM isn't an option
13:18:28 *** zachanima has joined #openttd
13:18:28 <Rhamphoryncus> bah, fix LLVM :D
13:19:43 <OwenS> But, on compilers with computed goto, my interpreter is very efficient :-)
13:19:56 <ashb> Low-Level Virtual MAchine
13:19:57 <OwenS> peter1138: Low Level Virtual Machine, a compiler infrastructure
13:20:26 <ashb> can be used as a backend for gcc, or as a runtime lib to do JIT etc.
13:20:54 <Rhamphoryncus> err, not a backend for gcc
13:21:03 <ashb> sure - that was why the 'etc.'
13:21:13 <peter1138> found a megasphere :D
13:21:13 <OwenS> Rhamphoryncus: Using the new LLVM gcc plugin, it can ;-)
13:21:40 <Rhamphoryncus> So what, llvm-gcc as a llvm frontend, gcc middle, and llvm backend?
13:21:43 <ashb> /Developer/usr/bin/llvm-g++-4.2
13:21:54 <ashb> gcc front, llvm the rest
13:22:09 <OwenS> Rhamphoryncus: The plugin replaces llvm-gcc. It plugs into GCC using its plugin interface, and replaces the backend completely
13:22:26 * Rhamphoryncus hopes he's not the one getting it confused
13:23:03 <Rhamphoryncus> curse their ambiguous terminology!
13:24:39 <Rhamphoryncus> Okay, looks like I was wrong. It's a GCC frontend (parser/etc) with LLVM for code generation
13:34:52 <OwenS> Rhamphoryncus: So, how does your VM/language handle exceptions?
13:35:39 *** fjb is now known as Guest777
13:36:03 <Rhamphoryncus> I was speaking hypothetically *g*
13:36:32 <OwenS> Rhamphoryncus: Hah. I'm currently implementing them on top of C++ exceptions. The main difficulty is correctly unwinding the script stack
13:36:50 <OwenS> (But I have to do that to propogate things like std::bad_alloc anyway)
13:38:05 <OwenS> Scripts can only interact with those of C++ class AS::ScriptException though, which wraps an Object implementing AS.Exception (i.e, the script-side exception class)
13:45:57 *** ajmiles has joined #openttd
13:49:35 <fonsinchen> What is the preferred place to put new container classes? src/misc or src/core?
13:52:20 <SmatZ> src/core is the new src/misc I would say :)
13:53:03 <Alberth> what's with these container thingies? everybody seems to want to wrap existing data structures into some container class nowadays, it seems
13:54:02 * Alberth looks in src/misc for the first time
13:54:31 <Alberth> hmm, directory should be called 'containers' :)
13:56:11 <frosch123> src/misc is src/tobecleanedup
13:56:34 <fonsinchen> I'm creating an auto-growing vector to replace the arrays for GoodsEntries
13:56:56 <fonsinchen> this will save space and time by reducing the needless cycling through empty goods entries
13:57:00 <frosch123> isn't that just SmallVector?
13:57:23 <fonsinchen> no, I want one that auto-constructs its entries and that auto-grows on operator[]
13:57:34 <fonsinchen> (within bounds set by template parameter)
13:58:32 <Alberth> at least you derive from SmallVector, I hope
13:58:43 <fonsinchen> no, I derive from std::vector
13:58:57 <fonsinchen> as that requires less coding for me
13:59:01 <frosch123> you mean SmallMap ?
13:59:16 <fonsinchen> no, smallmap doesn't provide constant-time lookup
14:00:10 <fonsinchen> What I'm doing is an emulation of the current array, but only as long as the last active entry's index
14:00:19 <fonsinchen> most times this will be a lot less than 32
14:00:45 <frosch123> cargoids are not reserved consecutively, are they?
14:01:01 <fonsinchen> in a second step I'm going to provide a static index translation table which places the most used cargo ids in front
14:01:13 <frosch123> so you optimise for no-newgrf-usage?
14:01:31 <fonsinchen> the translation table may be configurable on game start
14:02:30 <fonsinchen> but the first step should cut the cycling at least in half already
14:02:35 <Ammler> Eddi|zuHause: possible stuck_trains.diff is broken on trunk HEAD?
14:03:07 <Eddi|zuHause> you mean the data part or the gui part?
14:04:15 <Ammler> but I don't have the minimap anymore
14:04:20 <Eddi|zuHause> even more likely, since the smallmap gui was changed fairly significantly
14:30:28 *** lobstar has joined #openttd
14:32:53 *** DanMacK has joined #openttd
14:37:30 *** woldemar has joined #openttd
14:48:18 *** devilsadvocate has joined #openttd
14:51:11 *** Brianetta has joined #openttd
14:59:02 <CIA-6> OpenTTD: rubidium * r19398 /trunk/src/openttd.cpp: -Codechange: move the desync cache checking code to its own function. Also make the drive through and cargo list checks only run when 'desync' debugging is enabled.
15:13:33 <CIA-6> OpenTTD: alberth * r19399 /trunk/src/town.h: -Doc: Doxyment enum TownRatingCheckType.
15:19:35 *** De_Ghosty has joined #openttd
15:33:20 <CIA-6> OpenTTD: alberth * r19400 /trunk/src/ (road_cmd.cpp town.h town_cmd.cpp tunnelbridge_cmd.cpp): -Codechange: CheckforTownRating returns a CommandCost.
15:42:48 <CIA-6> OpenTTD: alberth * r19401 /trunk/src/station_cmd.cpp: -Codechange: Use curly braces with multi-line if statements.
15:53:56 <CIA-6> OpenTTD: alberth * r19402 /trunk/src/ (road_cmd.cpp road_internal.h station_cmd.cpp): -Codechange: CheckAllowRemoveRoad() returns a CommandCost.
15:55:17 <CIA-6> OpenTTD: frosch * r19403 /trunk/src/openttd.cpp: -Fix (r19398): Test inverted.
16:05:38 *** oskari89 has joined #openttd
16:10:17 *** Born_Acorn has joined #openttd
16:34:59 *** Illegal_Alien has joined #openttd
16:38:37 <CIA-6> OpenTTD: alberth * r19404 /trunk/src/tunnelbridge_cmd.cpp: -Codechange: CheckAllowRemoveTunnelBridge() returns a CommandCost.
16:40:11 *** DanMacK has joined #openttd
16:40:52 *** Goulpy is now known as Muxy
16:57:08 <geirha> 1.0.0-rc2 freezes on exit for me. I've narrowed it down to the config file. If I start openttd without ~/.openttd/openttd.cfg, it exits cleanly. When that file is there, it'll freeze as soon as I click the quit button. Neither INT nor TERM has any effect. I have to resort to KILL.
17:07:25 <Alberth> the known-bugs.txt may also be helpful
17:07:54 *** Brianetta has joined #openttd
17:09:37 <geirha> Ah, I was looking at bugs.openttd.org without luck. The SDL+PulseAudio bug listed in known-bugs.txt sounds like the culprit.
17:12:03 <CIA-6> OpenTTD: alberth * r19405 /trunk/src/ (15 files): -Codechange: CheckOwnership() returns a CommandCost.
17:12:16 <glx> ha right I suggested the wrong file :)
17:12:52 *** |Jeroen| has joined #openttd
17:14:14 <geirha> Yup, setting the env var SDL_AUDIODRIVER=pulse did the trick. Thanks :)
17:23:46 *** Eddi|zuHause has joined #openttd
17:36:20 <Ammler> he, "Hide stupid Pink" :-)
17:38:32 <Ammler> how do I "simulate" those building "magic browns"?
17:38:52 <frosch123> you mean wrong dos/win ?
17:41:00 <Ammler> no, the houses, which can change colors...
17:41:40 <frosch123> either company color, structure remap or church remap
17:42:00 <frosch123> they are all different :p
17:42:33 <Ammler> ah, structure remap it is
17:45:17 *** TheMask96 has joined #openttd
17:46:05 <Ammler> planetmaker: // Recolour: BLUE, GREEN, ORANGE, RED <-- means remap to company colors and // Recolour: STRUCT_BLUE, STRUCT_WHITE <-- to structure?
17:46:27 <frosch123> that would match tables/sprites.h
17:47:43 <Ammler> and where is documented which colors are used for those structure remap?
17:47:47 <planetmaker> Ammler: most probable, yes
17:48:09 <frosch123> Ammler: see "filter palette"
17:48:25 <frosch123> or get the source and look into recolor.xml
17:48:44 <planetmaker> well, struct is structure. Not CC and not church.
17:49:02 *** KenjiE20 has joined #openttd
17:49:06 <planetmaker> Maybe I should have made the comments CC_BLUE etc
17:50:31 <Ammler> frosch123: you filter "recolor colors" which looks like cc
17:51:30 <frosch123> it filters whatever you selected
17:51:53 <Ammler> yes, but there is nothing to select those "magic brown"
17:52:02 <planetmaker> hm... there's also just CREAM and DARK_GREEN, PINK, GRAY, RED in my comments
17:52:24 <planetmaker> and BROWN, YELLOW, ORANGE
17:52:49 <planetmaker> in the comments I added to the sprites in Opengfx
17:53:22 <planetmaker> Ammler: the house just has to feature the colours which are of that magic type
17:53:43 <planetmaker> and openttd will randomly choose a replacement for those magic colours
17:54:00 <Ammler> but the "map" should be documented somewhere, isn't?
17:54:10 <frosch123> Ammler: if you select "filter recolored colors", it excludes those colors from the top palette which are recolored by the recolor choosen below
17:54:13 <Ammler> I mean, Zeph was able to remove those :-)
17:54:26 *** Eddi|zuHause has joined #openttd
17:54:35 <planetmaker> yes, that's what the ttd palete without magic colours does
17:55:22 <Ammler> frosch123: I see, thanks :-)
17:58:17 <CIA-6> OpenTTD: rubidium * r19406 /trunk/src/lang/english.txt: -Fix: unneeded space in English string
17:58:43 <Eddi|zuHause> who needs space anyway
17:59:36 *** ajmiles has joined #openttd
17:59:57 <Ammler> planetmaker: looks like you forgot one color?
18:00:22 <Ammler> or what sense does have a remap to only one?
18:01:01 <planetmaker> I don't know :-) Maybe I forgot default. Whatever that is.
18:01:26 <Ammler> hmm, indeed, might be STRUCT_BROWN
18:02:02 <Ammler> no, that is also an additional option
18:02:30 <Ammler> STRUCT_NORMAL is another "brown"
18:06:23 <CIA-6> OpenTTD: rubidium * r19407 /trunk/src/lang/ (32 files in 2 dirs): -Fix: incorrect number of dots in '...' in translations
18:10:53 *** woldemar has joined #openttd
18:13:50 <CIA-6> OpenTTD: rubidium * r19408 /trunk/src/lang/ (45 files in 2 dirs): -Change: make the space after ... consistent in the translations too
18:21:56 <CIA-6> OpenTTD: rubidium * r19409 /trunk/src/lang/ (46 files in 2 dirs): -Codechange: remove some spaces from translations that were already removed from English (a long while ago)
18:23:25 <__ln__> who's guilty for changing the english without changing IDs?
18:25:21 <Rubidium> removing a space isn't really such a big reason to trash all translations
18:31:47 <peter1138> why would we change IDs just because a string changed ?
18:32:38 <__ln__> to avoid unsynchronized translations maybe. dunno. maybe you like those.
18:33:06 <Rubidium> just trash the translations. Works much better
18:33:26 <peter1138> looks to me that the translations were also all changed...
18:33:29 <Ammler> is there a easy way to convert a already "right" colored png to pcx?
18:33:29 <planetmaker> __ln__: how does a removed space unsyncs a translation?
18:33:35 <peter1138> so nothing is unsynced
18:34:05 <peter1138> even so, the WT system flags up when the english string is changed
18:34:35 <__ln__> planetmaker: how would i know
18:36:12 <__ln__> peter1138: fine. i was simply assuming that since the WT is written by MiHaMiX, it does everything against the common sense, like in the good old days.
18:37:11 <planetmaker> __ln__: WT isn't written by Mihamax.
18:37:19 <planetmaker> or mihamix. whatever
18:37:35 <planetmaker> at least not the current WT3
18:37:41 <Rubidium> planetmaker: WT is, WT2 is too, WT3 isn't
18:45:56 <CIA-6> OpenTTD: translators * r19410 /trunk/src/lang/ (12 files): (log message trimmed)
18:45:56 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:56 <CIA-6> OpenTTD: esperanto - 41 changes by Ailanto
18:45:56 <CIA-6> OpenTTD: estonian - 4 changes by irve
18:45:56 <CIA-6> OpenTTD: finnish - 1 changes by jpx_
18:45:56 <CIA-6> OpenTTD: french - 1 changes by glx
18:45:56 <CIA-6> OpenTTD: german - 2 changes by planetmaker
18:46:30 <frosch123> Ammler: what is "right coloured"? palettised with animation colours, or real coloured without animation colours?
18:47:03 <Ammler> frosch123: I just need to open it in gimp, apply ttd palette and save again as pcx
18:47:47 *** Eddi|zuHause has joined #openttd
18:48:12 <CIA-6> OpenTTD: rubidium * r19411 /branches/1.0/src/lang/ (52 files in 2 dirs): [1.0] -Backport from trunk: language updates
18:52:29 <Eddi|zuHause> hmzz... this game is crashing way too often...
18:54:50 <Ammler> frosch123: I have also no idea, how to save a "palettisised" png :-)
18:55:31 <Rubidium> Ammler: check OpenTTD's screenshot code
18:56:13 <Ammler> Rubidium: I meant in GIMP
18:56:30 <Ammler> If I add a index, I just get a lot options on saving
18:56:51 <Rubidium> reduce colour depth to 256, load the palette, save?
18:57:34 <Ammler> specially the compression rate confuses me
18:58:04 <Rubidium> Ammler: why? It's just the gzip compression 'rate', i.e. 0..9 (but scaled to 0-100%)
18:58:28 <Ammler> oh, that would explain :-)
18:58:52 <Ammler> I thought, it is something with quality, like on jpegs
18:59:53 <planetmaker> nope. Both have kinda in-built zlib support
19:00:49 <Rubidium> planetmaker: jpeg has some data compression, but it gets most of it's compression from trashing data (i.e. lossy compression)
19:01:31 <planetmaker> I meant to compare pcx and png. Not jpg ;-)
19:02:17 <planetmaker> and jpg is bad, I know. Never use it to measure anything.
19:03:53 <Rubidium> well pcx just uses RLE, slightly simpler than zlib
19:03:53 <OwenS> planetmaker: JPEG is good for photographs ;-)
19:04:00 <OwenS> Rubidium: "Slightly?" Much!
19:04:02 *** ajmiles2 has joined #openttd
19:05:37 <Rubidium> OwenS: calling zlib is really easy, making sure the 'user' has zlib is the difficult part; for RLE you probably have to copy some code from somewhere or implement it yourself
19:06:20 <OwenS> Rubidium: RLE can be implemented in 10 lines of C. It's also often a file fattener ;-)
19:06:23 <planetmaker> any windoze has some RLE decoder at least. Might even be encoder
19:07:35 <Rubidium> yeah, and zip is (occasionally) better than 7z
19:08:03 <OwenS> Yes, but what I'm saying is that RLE is basically useless ;-)
19:08:51 <planetmaker> OwenS: also that depends.
19:09:14 <planetmaker> If speed is your top priority, RLE can be what you can afford while anything else is too CPU intensive
19:09:59 <OwenS> If you're looking for speed, then RLE may be a good option anyway: It can often make faster code, at the expense of bigger files
19:09:59 <planetmaker> E.g. for live compressing video.
19:10:32 <OwenS> RLE is going to make video bigger. Just store the raw video, or use something useful and fast like HufYUV
19:11:15 <Rubidium> pff... why not put your computer in a time dilation "field"?
19:11:32 <planetmaker> the equipment was too bulky, Rubidium ;-)
19:12:11 <SmatZ> OwenS: unless it's a cartoon :)
19:12:42 <OwenS> SmatZ: Riiight... And thats live? :p
19:13:13 <OwenS> Someone really ought to make a codec designed for animated works, as all the current ones are suboptimal
19:14:03 <SmatZ> when I want high-quality compression, I use some mpeg4 encoder with very high-quality settings
19:14:20 <SmatZ> it's about ten times smaller than huffyuv output
19:14:31 <SmatZ> well, I haven't encoded video for long time :)
19:14:37 <SmatZ> guess H.264 is the way to go now...
19:15:01 <OwenS> Even my phone does H.264 :p
19:15:19 <OwenS> It's only an relatively el-cheapo Nokia 5800 :p
19:15:42 <OwenS> And nothing is more irritating than MPEG-4 ASP HD. Why? A) Huge for the quality B) HTPC can't play it (GPU doesn't accelerate MPEG-4 ASP...)
19:17:14 <SmatZ> what does new realvideo use? I saw some DVD-rip that had about 400MiB, and the quality was insane
19:17:33 <SmatZ> better than any 2CD RIPs I have seen :)
19:17:50 <OwenS> Whatever. DVD rips are easy
19:18:05 <SmatZ> it's easier to just copy the DVD :)
19:18:29 <Rubidium> dd if=/dev/cdrom of=themovie
19:18:32 <OwenS> And leave non-generation-lossed MPEG-2 + DTS (Or AC3) :-)
19:19:03 <OwenS> Rubidium: I prefer my script which converts it into a nice Matroska file ;-)
19:20:34 <Ammler> Rubidium: you need cut off the FBI
19:20:38 <OwenS> (Though remuxing in the vobsubs is difficult ;-) )
19:21:00 <Rubidium> Ammler: then it isn't a proper rip anymore!
19:21:20 <Ammler> yeah, it is like bugfix release :-)
19:21:44 <OwenS> Your DVDs have FBI warnings? :P
19:22:29 <Ammler> I run my dvds through dvd:rip
19:23:06 <Ammler> a nice app, where you can add all idle pcs in the network :-)
19:24:25 <Ammler> he, that is indeed true.
19:26:07 <OwenS> Ammler: Get a DVD player which doesn't obey operation restriction flags :p
19:26:28 <OwenS> (Also, none of my DVDs have trailers... Neither does the sole BD in my collection)
19:27:07 <Ammler> OwenS: I don't have a DVD player anymore (except the pc)
19:27:20 <Ammler> the tv box does use vlc streams
19:28:10 * KenjiE20 uses AnyDVD for watching my imported R1 EVA discs :)
19:28:56 <OwenS> KenjiE20: Why import the R1 version? :p
19:29:10 <KenjiE20> because it was the limited platinum edition
19:29:18 <KenjiE20> and R2 gets crap all for Anime
19:29:25 <OwenS> Aah, limited platinum. I have the non-limited-platinum I assume
19:29:32 <OwenS> Though yes I do have some R1 imports
19:29:42 <KenjiE20> Limited had a numbered decal in DVD 1
19:30:02 <KenjiE20> which came with the boxset box
19:30:29 <KenjiE20> but I bought the full set off Animesuperstore on promotion :P
19:30:33 <OwenS> It's a shame ADV/Their fission fragments are so small, they had a pretty good international operation
19:31:11 <KenjiE20> most licenced stuff gets utterly mangled
19:31:21 <KenjiE20> so I usually grab stuff from fansub sites
19:31:48 <OwenS> I must say, in a comparison of the original vs R1/R2eu releases, I've generally not spotted any differences in the video
19:32:23 <KenjiE20> depends who get it usually
19:32:35 <KenjiE20> funimation are awful
19:32:59 <KenjiE20> and buerna vista/disney tend to rewrite things
19:33:00 <OwenS> If you're refering to them seeminly using the world's worst MPEG-2 encoder, I understand that :P
19:33:46 *** Terkhen has joined #openttd
19:34:01 <KenjiE20> funimation like to remux things
19:34:20 <KenjiE20> they've been know to utterly change soundtracks and story
19:34:43 <Ammler> frosch123: FeatureRequest for TTDViewer: drag&drop scroll for the sprite sheet.
19:36:23 <Eddi|zuHause> hm... the "feature" that Day of the Tentacle contains Maniac Mansion is only in the CD version, right?
19:36:38 <KenjiE20> OwenS: DBZ / Sunabouzu
19:36:53 <KenjiE20> GSG / Fullmetal Alch
19:38:33 <OwenS> Aah, so except for Sunabouzu (Which I've never heard about), really rather popular shows which I'm not that interested in (And it must be noted that I also check reviews before I buy ;-))
19:39:39 <KenjiE20> Sunabouzu is brilliant, but get fansubs
19:41:51 <frosch123> Ammler: there is already a feature of the day
19:43:01 <Ammler> ok, then I will ask tomorrow again :-P
19:45:33 <OwenS> KenjiE20: Oh, and there really needs to be an English re-release (Preferably Blu-Ray; the film stock has the resolution) of the original Eva movies. I don't know WHAT made them think it was a good idea to take a widescreen movie, then letterbox it, then pillarbox it, so that you end up with it squashed into 1/3rd of the available pixels...
19:46:25 <KenjiE20> I grabbed COR and...
19:47:01 <KenjiE20> oh not COR, zx releases of Death and End of
19:47:49 <KenjiE20> currently last rebuild 1.20 BD rip and waiting for the 2.xx
20:04:35 <CIA-6> OpenTTD: alberth * r19412 /trunk/src/road_cmd.cpp: -Codechange (r9942): One pair of parentheses is enough.
20:14:18 *** RainbowNines has joined #openttd
21:10:06 <DJNekkid> just some advertiseing for myselv...
21:10:13 <DJNekkid> www.clublife.no/tv live from a club from about midnight
21:10:22 <TrueBrain> you do know what we do with spambots here, right? :)
21:11:51 <OwenS> yay! The Alterscript interpreter just dynamically built an object based on typeinfo
21:18:10 <Alberth> DJNekkid: with TB you never know what happens
21:20:36 <lestat> hal someone who speaks Spanish?
21:22:08 <Terkhen> lestat: I still talk spanish
21:25:28 <lestat> then enters openttd-es
21:55:21 *** lobstar has joined #openttd
22:07:41 * peter1138 ponders updating to squeeze
22:14:48 *** Chris_Booth has joined #openttd
22:16:07 <Terkhen> my debian squeeze freezes a lot :/
22:24:08 <fonsinchen> it finally has working suspend
22:24:20 <fonsinchen> to disk AND to ram - this is really nice
22:34:06 *** ajmiles3 has joined #openttd
22:37:36 <fonsinchen> rubidium: in CheckCaches, you should return if _debung_desync < 1
22:37:56 <fonsinchen> not if it's > 1 ...
22:41:05 *** ProfFrink has joined #openttd
22:41:54 <Rubidium> fonsinchen: rather <= 1
22:47:32 *** ProfFrink is now known as Prof_Frink
22:50:35 *** Chris_Booth is now known as Booth
22:52:34 *** Booth is now known as Chris_Booth
22:52:57 *** Chris_Booth is now known as Booth
22:53:37 *** Booth is now known as Chris_Booth
22:53:55 <andythenorth> did transfer payments get seriously fixed? The last vehicle in the chain now seems to make money
22:54:48 <Rubidium> it's more like a painkiller
22:55:14 <Jolteon> this old 0.7.* save won't load.
22:55:19 <Jolteon> OTTD just crashes to desktop.
22:55:26 <Jolteon> Is there any known issues, or is this save just dodgy.
22:55:32 <Jolteon> Loading under 1.0.0 RC1
22:55:50 *** Chris_Booth has joined #openttd
22:55:55 <Jolteon> oh well, I can finally make another one
22:55:57 <Rubidium> having the savegame would help
22:56:10 <Jolteon> for some reason, I always feel I must complete one I start, until it gets too jammed to fix.
22:56:11 <Rubidium> determining whether it's a bug or a broken savegame
22:59:47 <fonsinchen> I think I've hit the wall with those optimizations ...
23:00:17 <fonsinchen> one should think that reducing all iterations over goods entries by 2/3 would have a noticable effect
23:00:28 <fonsinchen> but that's not the case :(
23:01:09 <fonsinchen> maybe it's still nice that it takes less memory now ...
23:02:55 <Rubidium> maybe because at the first autosave the full array gets filled because it's trying to write the whole thing to the savegame?
23:03:10 <Rubidium> same with loading "old" savegames
23:04:58 <fonsinchen> no, I've changed the saveload code to avoid that
23:05:20 <fonsinchen> and I've made sure the goods arrays are compacted after loading old games
23:06:51 <fonsinchen> but obviously the added overhead of length checks and pointer dereferencing is about the same as the time saved by reducing the number of iterations
23:07:42 <Eddi|zuHause> orudge: i tried disabling the "Display images within posts" option in the forum, which in itself works fine, but i have two problems:
23:08:02 <OwenS> fonsinchen: Does the OpenTTD source have LIKELY/UNLIKELY macros?
23:08:12 <Eddi|zuHause> 1) when opening some attachments i get "unknown mime type", so images don't open in the image viewer etc.
23:08:53 <Eddi|zuHause> 2) when someone makes [url=blah][img][/url], i cannot click on it to follow the url, it only can open the image
23:09:02 <fonsinchen> at least I haven't seen them so far
23:09:33 <Eddi|zuHause> fonsinchen: i suppose they should tell the compiler which code path to optimise
23:09:43 <PeterT> Eddi|zuHause: PM, he probably isn't on his bouncer right now
23:10:16 <Eddi|zuHause> PeterT: he isn't marked as away...
23:10:49 <OwenS> fonsinchen: I've found that they can make real differences on intensively accessed code
23:11:34 <OwenS> You probably want to change the "#if GCC" to something that works :p
23:16:56 <fonsinchen> Hmm, when loading a "new" savegame it's faster. I guess the compacting of the old save was quite expensive.
23:35:29 *** takamichi has joined #openttd
23:42:29 *** takamichi has left #openttd
23:56:07 <Illegal_Alien> Shell as in clambshell?
23:56:14 <Illegal_Alien> Shell as in gass?
23:57:13 *** TheMask96 has joined #openttd
continue to next day ⏵
