IRC logs for #openttd on OFTC at 2008-08-05
⏴ go to previous day
00:00:23 <Belugas> no, actually, it is not possible
00:00:36 <Belugas> because it's only fields that are planted
00:01:10 <Belugas> and iirc, it's the same kind of graphics wether you are in temperate or in subarctic
00:01:25 <Belugas> but i wonder what it would require to do so...
00:01:36 <nicfer> I saw a topic in the suggestion forums about it and I was thinking about making it more expansible
00:05:38 <SmatZ> "The wurst I ever seen."
00:10:33 <Belugas> mmh... it's not totally impossible
00:10:49 <Belugas> but not with current newgrf specs tough
00:12:31 * Belugas goes back to its game in subarctic
00:18:09 <CIA-5> OpenTTD: peter1138 * r14000 /trunk/src/smallmap_gui.cpp: -Codechange: Missing enum entries kind of defeat the point of the enum
00:18:09 <peter1138> Wow, what a rubbish commit for r14000 :p
00:20:28 <peter1138> (That was the cause of the black map in the cargo dest tree)
00:20:40 <SmatZ> I was considering adding a missing space for r14000...
00:33:55 *** Eddi|zuHause2 has joined #openttd
00:45:55 <Belugas> there are an awfull lot of hardcode in colour management
00:52:09 <Belugas> ho... thanks SmatZ for the url :)
01:08:56 <Belugas> that forest-farm-field request is intriguing
01:09:07 <Belugas> just do not know from where to handle it
01:12:24 <Belugas> SmatZ, to your knowledge, which is the fastest between "return (x == true) ? 1 : 25;" from "return this[x];" as an example
01:12:48 <Belugas> given that this is an array[2] containing1 and 25
01:14:45 <Belugas> SmatZ or.. any one else, of course
01:17:34 <SmatZ> maybe if this (bad name for C++ ;)
01:17:44 <SmatZ> was a static const array, compiler could optimise that
01:21:12 <Belugas> i was looking at code for _use_dos_palette
01:21:25 <Belugas> as you know, i'm hooked on colours recently :)
01:26:12 <Belugas> but tonight, nothing good to do
01:48:17 *** dragonhorseboy has joined #openttd
02:00:17 <dragonhorseboy> me going to bed in a moment too
02:15:38 *** dragonhorseboy has left #openttd
02:20:24 <AAK> I unknowingly downloaded the latest directx sdk, and I cannot build openttd because I get 10 unresolved external symbol errors. Can I easily fix this, or do I have to downgrade?
02:23:24 <glx> you need direct music files (they are not in recent SDK)
02:25:14 <glx> Note:You should not use a version newer then August 2007 as DirectMusic is no longer support as of the November 2007 release. <-- it's said on the wiki
02:25:53 <AAK> i know. so the only option is to get an older sdk? or can i download the direct music files somewhere?
02:28:43 <glx> btw I have only april 2007 SDK and it works with 2008 express
03:07:41 *** elmex_ is now known as elmex
04:05:53 *** Doorslammer has joined #openttd
05:50:12 <Tekky> Are the TTD-Forums down also with everyone else?
05:50:32 <Tekky> I can't seem to access them, I can't establish a HTTP connection.
05:52:54 <Doorslammer> Unless your name is Draakon, I cant understand the fuss ;)
05:58:10 <Doorslammer> Hmmm, could possibly be
06:09:41 *** Sir-Bob has joined #openttd
06:34:13 <peter1138> It's not just forum.openttd.org that's down...
06:36:56 <peter1138> Oh yes, it all does now...
06:47:23 *** stillunknown has joined #openttd
07:04:50 <Eddi|zuHause2> wahh... it's way too early...
07:04:57 <Eddi|zuHause2> who invented these hours?
07:16:25 *** Vikthor has joined #openttd
07:41:32 *** GoneWack0 has joined #openttd
07:44:30 <peter1138> Celestar, only that I did the merge cos r14000 fixes the black minimap bug
07:45:57 <Celestar> peter1138: I've done some fixes
07:46:06 <Celestar> peter1138: we need another playtest
07:46:34 <Celestar> peter1138: I'll add a console command to manually reconstruct the routing system
07:47:50 <Celestar> that way the server will behave the same way as a freshly connected client
07:52:16 <Celestar> (this is something we could always do :P)
07:52:26 <Celestar> just have the routing system reset when a client connects, but that's UGLY
07:53:58 <planetmaker> heya Celestar :) Reading here, I start to really feel like testing your CargoDestinations, too :)
07:57:49 <planetmaker> uh... I guess I should really get around and install hg one day :)
07:58:57 <Celestar> we're you on opensuse?
07:59:29 <planetmaker> depends. Here on work: yes. At home, I'm doing my OpenTTD dev on MacOS Tiger
07:59:58 <planetmaker> But what compiles on SuSE, compiles on MacOS mostly, too
08:00:56 <Celestar> and zypper in boost-devel (=
08:01:43 <planetmaker> :) I guess, I got something to install in the weekend :)
08:02:10 <Celestar> erm peter1138: you know more about the GUI than I do. the scrollbar in the station view window is not updated when the number of lines change. where do I set this?
08:02:42 <Ammler> you can't use zypper in on OSX, can you?
08:03:08 <Ammler> has osx also such repos, btw?
08:03:50 * planetmaker just investigates
08:05:33 <Ammler> how do I permanently change the url for pull?
08:05:47 <Ammler> hg pull likes still to use peters repo...
08:06:28 <planetmaker> k, there're both, package managers for OS-X and there's mercurial for OS-X :) All feasable therefore :)
08:16:51 <peter1138> Celestar, not that simple to reset, as you need to reset it for all the clients. A similar solution was proprosed for the YAPF cache problem, but it ended up being fixed instead...
08:17:48 <peter1138> I don't know if that's the proper way to switch, but it worksish...
08:17:49 <Celestar> peter1138: I'm not sure whether we have a cache problem
08:18:25 <peter1138> Celestar, if 'rebuilding the network' fixes it, it is similar to a cache problem.
08:18:42 <Celestar> peter1138: yeah, maybe it is the edge order within a vertex
08:18:57 <Celestar> peter1138: I'm still trying to find out what sorting scheme is used
08:19:06 <peter1138> The whole routing system is a cache of sorts, because the real data is the station and order pools.
08:19:48 <peter1138> A console command to reset just the routing network on the server is a good way to test if that is the case of course :)
08:19:59 <peter1138> So we just need to play again until it desyncs chronically...
08:20:40 <Celestar> I'll stop the server, rebuild and reload (=
08:20:45 <Celestar> because it is pretty large a game
08:21:37 <Celestar> ps u | grep csh | wc -l
08:23:27 <Celestar> I don't find the terminal where the server is running on
08:25:11 <Celestar> oh .. it's in a detached screen :P
08:29:12 <Celestar> peter1138: server running :P
08:34:55 <Celestar> this is NOT the same version :o
08:35:16 *** KillaloT has joined #openttd
08:35:48 <Celestar> is the version string changed by "hg pull" or by "hg update" ?
08:37:27 <Ammler> hg pull is like downloading the "patch", hg up is aplying.., isn't
08:38:52 <Celestar> but it displayed the same version string even though the sources were totally different
08:44:36 <peter1138> It should have an M...
08:45:34 <rortom> at what time are the nightlies compiled?
08:46:52 <peter1138> 8pm in whatever timezone the server is in ;)
08:51:31 * Celestar wonders how to tackle the next items on the TODO
08:53:43 <Kloopy> What is the next item on the list?
08:54:31 <peter1138> rortom, we were playing it last night...
08:55:50 <peter1138> Celestar, I think I've bagsyed 2a and 7a. 2b is done...
08:56:27 <peter1138> rortom, well it worked. Not all there yet, heh...
08:58:54 <Celestar> rortom: the graph is finished
09:03:09 *** Eddi|zuHause3 has joined #openttd
09:08:25 *** Brianetta has joined #openttd
09:10:29 <Brianetta> Don't suppose you're coming on Saturday?
09:14:51 <ln> What's in London on Saturday?
09:17:13 <ln> the names look quite british.
09:17:27 <Brianetta> Britain's quite close to London.
09:18:11 <Celestar> 11:17 < Brianetta> Britain's quite close to London.
09:18:11 <Celestar> 11:17 <@peter1138> Hmm, don't know.
09:23:33 <rortom> i would have come if its after november
09:24:47 <Celestar> bad date too, I have a meeting this weekend :(
09:24:58 <rortom> "Any other ladies that see this page and wonder why the hell their bloke is going to meet some other geeks, feel welcome to go shopping around London with your fellow better halves! "
09:27:21 <ln> maybe i should tell w-ber about that page and meeting...
09:29:46 <ln> where the hell are you actually going to meet and play?
09:33:53 <ln> (if anyone remembers w-ber, he is the first finnish translator, used to hang around here years ago, and now lives in London)
09:36:56 <Celestar> I have an endless loop somewhere
09:52:13 <rortom> mh you thought about themes for grfs?
09:52:30 <Ammler> rortom: already in trunk :-)
09:52:44 <rortom> so users can simply setup a candian/japan/us/whatever server without crawling grfs?
09:53:01 <peter1138> UpdateStationRating() is fishy
09:53:21 <Ammler> but you have grfpresets...
09:53:40 <peter1138> I think it will truncate cargo for all cargo types after one that should be truncated.
09:54:14 <ln> when will the TT meeting be arranged in Copenhagen?
09:54:46 <Celestar> I'm really nerd. I'm usually running openttd in the debugger with -snull -vnull :P
10:00:03 <Celestar> peter1138: When I'm caching the reachable stations, the time taken to find whether there is a reachable station is decreases from 1 million to 1000 cycles, and the destination generation from 1 million to 20000 cycles
10:03:04 <ln> Will not the next TT meeting not be arranged anywhere but in Copenhagen?
10:03:21 <Brianetta> I find it fascinating that the OpenTTD crowd seem to have missed the 2008 TT meet so completely.
10:03:50 <ln> Brianetta: It hasn't been on the topic here.
10:04:01 *** Progman has joined #openttd
10:04:15 <Brianetta> It hasn't been on the topic anywhere; it's a sticky thread in the forum.
10:04:18 <Noldo> I have seen no mention of in on the medias I follow
10:04:48 <Celestar> peter1138: er .. and that's with debug (=
10:05:04 <Celestar> factor 50 is worth the effort, right? (=
10:06:35 <Celestar> peter1138: I've given some thoughts about selective cache invalidation, but I'm not sure it's worth the hassle
10:07:05 <ln> Brianetta: I don't read the forum, and therefore I assume 84.5% of other people do not read it either.
10:07:56 <Brianetta> ln: How on Earth do you find out about upcoming new features etc?
10:08:04 <peter1138> Brianetta, he doesn't ;)
10:08:16 <peter1138> He doesn't know about GRFs...
10:08:27 <peter1138> Oh damn, too much in that diff :o
10:09:38 <Celestar> peter1138: this does what? (=
10:10:04 <Celestar> my generation code on the repo is favouring distance stations :P
10:10:11 <peter1138> My analysis says that wrong cargo types are truncated...
10:11:12 <Celestar> peter1138: ok I'm down another factor of 5 in the destination generation
10:11:43 <Celestar> compared to 1 million before (=
10:16:35 <Celestar> randomrange(42) gives random numbers [0:42] or [0:42)
10:16:53 <peter1138> What's the difference? ;)
10:17:02 <Celestar> including or excluding 42 ;)
10:17:16 <SpComb> Celestar: depends on the implementation
10:17:35 <Celestar> the openttd implementation of course :P
10:17:53 <SpComb> although imo it should be exclusive, because that's how python defines range
10:19:16 <Celestar> what does python have to do with it
10:21:10 <peter1138> return GB(this->Next(), 0, 16) * max >> 16;
10:21:47 <peter1138> 65535 * 100 / 65536 = 99
10:22:52 <rortom> mh use the debian way: return 4; // determined by fair dice roll
10:27:21 <ln> 13:08 <@peter1138> He doesn't know about GRFs... <-- I do!
10:30:13 <ln> 13:07 < Brianetta> ln: How on Earth do you find out about upcoming new features etc? <-- By reading commit messages on this channel. And as if there were new features introduced on a regular basis...
10:30:52 *** ChanServ sets mode: +v tokai
10:37:32 <rortom> Noldo: thanks i was unable to find it :)
10:38:05 <Brianetta> ln: COmmits aren't upcoming.
10:39:45 <Noldo> rortom: it has quite good search
10:42:46 <Celestar> do we have any wiki maintained?
10:50:19 *** Tekky_ is now known as Tekky
10:53:43 <peter1138> I can do some things, but not much.
10:53:45 <Celestar> maybe because our internal wiki maintainer just called and asked stupid question
10:54:02 <DorpsGek> peter1138: mihamix was last seen in #openttd 29 weeks, 0 days, 14 hours, 32 minutes, and 24 seconds ago: <MiHaMiX> s/t$/d/
10:54:23 *** welshdragon has joined #openttd
10:59:23 *** kais58_2 has joined #openttd
11:01:24 <rortom> mh is there an option to enable the loading status in the transparent mode?
11:04:06 <SmatZ> lock the transparency option
11:04:25 *** kais58_3 has joined #openttd
11:04:55 *** kais58_4 has joined #openttd
11:05:20 *** kais58_4 has joined #openttd
11:06:22 *** kais58_4 is now known as kais58
11:15:35 *** kais58_3 has joined #openttd
11:18:00 <Celestar> peter1138: I'm not sure how to keep the caches in sync
11:20:52 <Celestar> it's gotten much worse with the reachcache, but it's reproducible now :P
11:25:32 <peter1138> I've got MS SQL stuck in YYYY/DD/MM format dates :o
11:25:58 <peter1138> Celestar: can we sort the cache, and will that help?
11:26:39 <ln> i didn't know OTTD supports MS SQL.
11:26:47 <Celestar> peter1138: "sort" in what way?
11:26:48 <ln> should be reading the forums apparently.
11:27:44 <Celestar> peter1138: the reachcache is sorted by stationid
11:28:45 *** Dred_furst has joined #openttd
11:29:00 <Celestar> peter1138: that'S the one giving me a hard time
11:30:32 <mikl> peter1138: that's got to be the most confusing date format ever :)
11:33:35 <Celestar> I normally use YYYYMMDD
11:34:39 <Celestar> but yyyy/dd/mm is just stupid
11:35:00 <Celestar> either you have LSB on the right or LSB on the left. not LSB is the middle :S
11:39:27 <Celestar> peter1138: is it ok to populate the route cache on game load?
11:39:30 <peter1138> Celestar: if it's sorted by station id then it should be consistent, yes?
11:39:58 <Brianetta> yyyy/dd/mm isn't used in any country that I know of
11:40:01 <peter1138> It is populated in the InitializeRouting() call in AfterLoadGame()
11:40:10 <Celestar> peter1138: no, it's set to dirty (=
11:40:15 <Celestar> populate means recompute it
11:40:57 <peter1138> Brianetta: it's an MS SQL bug. If you have it set to GB locale, it seems to swap MM with DD regardless of the format actually used.
11:41:13 <peter1138> Celestar, would it help?
11:41:49 <Brianetta> Stupid yank products.
11:41:55 <Celestar> peter1138: it helps a lot apparently
11:42:17 <Celestar> it costs a second in load time however :P
11:42:40 <peter1138> Hmm, if it helps then the route cache isn't being automatically created properly.
11:42:51 <peter1138> So you'll have problems anyway.
11:43:03 <Celestar> there's some weirdness in it
11:43:18 <Celestar> somewhere a dirty cache is being used, or the cache is not set dirty correctly
11:47:27 <peter1138> Did you write anything to compare the hopcache with a freshly built hopchace?
11:47:49 <Celestar> not yet. I'm still trying to find out how to do this best
11:50:02 <peter1138> Hmm, I see it's not possible to have two equal cost routes load-balanced :o
11:52:01 <Celestar> well if they go from the same A to the same B it shouldn't matter
11:52:40 <peter1138> well, non-shared orders count as a different route, don't they?
11:53:08 <peter1138> It's a hopcache, not a route cache...
11:53:22 <peter1138> So the if the next hop is the same that shouldn't matter...
11:53:36 <peter1138> I should go back to doing some work :p
11:53:38 *** kais58 is now known as kais58_2
11:53:43 *** kais58_2 is now known as kais58
11:54:47 <Celestar> peter1138: check the console. the "findroute" command and the last-but-one line of the debug
11:59:15 *** Wezz6400 has joined #openttd
12:01:32 <peter1138> Er, I don't understand it.
12:03:22 <Celestar> I get a "cannot reach any stations" error for coal. but I can manually find that route
12:15:25 *** Singaporekid has joined #openttd
12:18:19 <peter1138> Hmm, my updated station cargo view seems to work...
12:18:40 <peter1138> It now stores the cargo list individually for each cargo type, so that it can be sorted more easily
12:19:02 <peter1138> It also means we only need to update the if it changes (and the window is showing the list) instead of every time the window is redrawn
12:30:04 <Forked> seems I got that shitty station to work.. I guess the obvious trick was to not have all the entrance and exit tracks on the same side of the station.. and instead try to even it out a bit =p
12:30:23 <Forked> still a mess, but no clogging
12:38:47 <planetmaker> whooo. I just noticed. Commit 14000 last night. Well done! :)
12:43:57 <Celestar> I have apparently coded some crap somewhere
12:44:03 * Celestar goes finding said "crap"
12:44:45 <Noldo> maybe the crap coded itself
12:45:23 <Celestar> I need someone to blame
12:45:31 * Celestar points in a random direction
12:49:15 <planetmaker> ^^ you keep saying that today... ;)
12:50:05 <Celestar> how do I set the server to pause if no clients are connected?
12:51:03 <planetmaker> or something like that in the config
12:51:26 <Celestar> I think I found it thanks
13:02:31 <Celestar> er no wait. false alarm
13:10:22 *** tamentis has joined #openttd
13:10:58 <Celestar> peter1138: if you got a minute, can you have a look at Routing_t::CanReachAnyStation? It's doing crap
13:12:17 <peter1138> Celestar: Dunno, but swap the CanReach with the HasBit
13:12:30 <peter1138> The HasBit should be cheaper to process...
13:13:25 <peter1138> Celestar, what crap is it doing?
13:14:17 <Celestar> it writes empty lists for stations that clearly shouldn't be
13:15:28 <peter1138> I just updated and the code is majirly different :p
13:17:16 <peter1138> So ComputeReachList is not working right?
13:17:57 <peter1138> this->reachcache[from] = list;
13:18:10 <peter1138> ... is not too efficient.
13:18:26 <peter1138> It has to copy all the data.
13:19:00 <Celestar> yeah, but from a computing point of view, it's only run once per aeon
13:19:06 <Celestar> I'll optimize that later, if it works
13:25:34 <peter1138> Just that "this->ComputeReachList(from, this->reachcache[from]);" would do the same more efficiently.
13:25:43 * Celestar goes overhauling the whole system
13:27:59 <Progman> dih: still showing "hasted"
13:30:19 *** ChanServ sets mode: +v tokai
13:31:25 <peter1138> Heh, my colleague just saw this bit of code ;)
13:31:30 <peter1138> "Oh my god that looks complex"
13:32:11 <Rubidium> then peter1138 said: "is not"
13:33:11 <hylje> peter1138: notwork@work?
13:33:11 <Celestar> peter1138: and you explained it to him
13:40:21 *** grumbel has joined #openttd
13:41:59 <Celestar> \o/ infinite recursion
13:43:26 <hylje> recursion is a representation of the infinite
13:43:50 <Celestar> in programming, you normally only curse finitely
13:44:38 <Celestar> otherwise you stack will be pissed
13:45:26 <planetmaker> hehe. I tried that with the rivers. Pretty darn fast got a crash...
13:49:24 <dih> there is no output from server_pw blah
13:49:30 <dih> (setting the server password on console)
13:55:55 <Celestar> cache system repaired somewhat
13:56:03 <Celestar> code more readable and less duplication
13:56:14 <hylje> implies there's still copypasta around
13:57:08 <Belugas> Does anyone have a TTD's DOS palette available somewhere?
13:57:15 <Belugas> woldbe nicely appreciated
13:57:37 <Celestar> Belugas: I might have at home. will check later
13:57:48 <Celestar> it's possibly on 3.5"
13:57:57 <Celestar> so I need to find whether they are still readable
13:58:32 <glx> you want the palette only?
13:58:56 <Celestar> peter1138: when I load a game from before tonight's merge, all my "go to nearest depot" orders have become invalid.
13:59:08 <Celestar> peter1138: is this a side effect, or a real problem from the fixes in trunk?
14:00:06 <Belugas> i want to be able to compare and eventually name all the colours. I have the win one, so it wold be a matter of comparaison (and understanding of course)
14:00:36 <glx> I have them in paint shop pro format
14:00:37 <Eddi|zuHause3> doesn't grfcodec know the palettes?
14:00:56 <Eddi|zuHause3> or the grf specs?
14:02:04 <Celestar> peter1138: do you have any changes I should pull?
14:02:20 <Belugas> Eddi|zuHause3, maybe, but it's me that i'm worried, not grfcodec, which is not what i'm working on ;)
14:03:10 <Celestar> peter1138: ok I have repaired my fuckup
14:03:11 <peter1138> Celestar, I never use 'go to nearest depot' orders...
14:03:46 <Celestar> peter1138: and it's a bit annoying having to repair shitload of orders.
14:03:51 <Celestar> peter1138: I'll check in trunk a bit later today
14:06:06 <Celestar> peter1138: It'd be awesome if you could do some profiling on the latest repo. mine doesn't work for some reason
14:06:43 *** Dinsdale has joined #openttd
14:25:56 <Eddi|zuHause3> yay for full recompiles \o/
14:26:17 <Eddi|zuHause3> "The system detected that source.list or any configure file is altered."
14:32:34 *** Dinsdale is now known as Doorslammer
14:33:32 *** Dred_furst has joined #openttd
14:42:09 *** [1]KillaloT has joined #openttd
14:42:09 *** [1]KillaloT is now known as KillaloT
14:45:25 *** trainboy2004 has joined #openttd
15:03:33 <peter1138> Celestar: RecomputeCache() is not exactly const is it?
15:08:09 <Eddi|zuHause3> you certainly know you're in a channel of geeks when one xkcd reference is countered by another xkcd reference...
15:08:21 <Eddi|zuHause3> [2008-08-05 12:22] <rortom> mh use the debian way: return 4; // determined by fair dice roll
15:08:21 <Eddi|zuHause3> [2008-08-05 12:25] <Progman> [citation needed]
15:12:24 *** Dred_furst has joined #openttd
15:13:13 *** lobster_MB has joined #openttd
15:19:42 <Celestar> peter1138: anything that doesn't change the class logically is const
15:20:09 <Celestar> peter1138: for the "user", Routing behaves before any after the Recompute cache exactly the same way
15:24:49 <Rubidium> but... doesn't that mean that the compiler can keep a cache of the routing stuff somewhere and use that later on, e.g. a tick later
15:30:57 <Rubidium> const is a hint for the compiler that nothing changes
15:31:59 <Rubidium> if it changes the routing table and it just cached some data before the Recompute call and uses it afterwards it might be reading stale (incorrect data) evt. leading to a desync
15:33:56 <Celestar> const is not only a hint
15:34:18 <Celestar> const tells a compiler that nothing must change, except mutable members, otherwise it throws an error
15:35:42 <Celestar> mutable overrides const
15:37:50 <blathijs> Celestar: That sounds pretty cool :-)
15:37:50 <Rubidium> still, does the compiler know that it actually might change internal stuff that changes the state of the routing table?
15:38:12 <Ammler> how is the link to your screen for the GRF Downloader again?
15:38:31 <Celestar> Rubidium: because the compiler throws an error if you modify a const object
15:38:46 <Rubidium> you just said that it doesn't for mutable
15:38:51 <Celestar> unless you explicitly mark the members in question as mutable
15:38:59 <Celestar> Rubidium: the compiler knows that it is mutable (=
15:39:40 <Rubidium> Celestar: the compiler only sees routing.h, not the internal implementatin of the recompute, when writing the code that calls the recomputer
15:40:04 <Rubidium> there it doesn't know that recompute does change the state (via mutable)
15:40:30 <SpComb> what's the context for this?
15:40:48 <SpComb> (currently it's on hold until I manage to kludge the OpenTTD network code into doing what I want it to do)
15:41:40 <peter1138> Ammler: "what", not "how"
15:42:57 <Celestar> Rubidium: the compiler sees the mutable members.
15:43:28 <Rubidium> Celestar: so the consts of that class are all totally ignored!
15:44:07 <Ammler> SpComb: we have a talk about our GRFPack and tars and such :-)
15:44:15 <Celestar> const means all non-mutable members are unchanged (=
15:46:17 <Rubidium> Celestar: but you are reading the mutable members for determining the routing stuff
15:46:47 <blathijs> Celestar: I think the point is that the results of other methods can change after calling a const function?
15:47:00 <Rubidium> yes, as blathijs said
15:47:02 <Celestar> blathijs: they don't
15:47:03 <blathijs> Rubidium: But const doesn't guarantee anything about that
15:47:18 <Celestar> the result (i.e. return value, out paramenters) are the same
15:47:32 <Celestar> they only update the cache when it is dirty
15:47:41 <Celestar> if the cache is clean, they read it
15:48:11 <blathijs> Rubidium: You might expect const to give such guarantees, but it doesn't :-)
15:49:54 <Ammler> peter1138: thanks, btw. :-)
15:51:05 <Rubidium> blathijs: that's a very stupid design choice then (IMO)
15:54:03 *** Dinsdale has joined #openttd
15:54:29 <Eddi|zuHause3> would possibly help with the excess passenger generation problem ;)
15:56:04 <Rubidium> in what way? It'll only create more passengers
15:56:27 <Eddi|zuHause3> have you read my comment?
15:56:39 <Eddi|zuHause3> i am saying the opposite ;)
15:56:40 <Rubidium> it's basically: if transported i the last half year, 100% rating
15:57:01 *** mikegrb has joined #openttd
15:57:03 <Rubidium> you are saying keep the current one (or that's what I understand)
15:57:04 *** Dinsdale is now known as Doorslammer
15:57:37 <Eddi|zuHause3> no, i said improve the current one to cope with very low transportation levels
15:58:35 <Eddi|zuHause3> the current system is kind of a sinus-curve, because it only accounts for the last visit, not for the actual distance between visits
15:58:44 <Eddi|zuHause3> so it doesn't really stabelises
15:59:19 <Eddi|zuHause3> it also does not care for capacity
16:00:01 *** daspork has joined #openttd
16:00:23 <Eddi|zuHause3> i say: reduce the dependency of ratings from the stockpile, and add a dependency of vehicle capacity and frequency
16:01:38 <Eddi|zuHause3> if i schedule a train with capacity of 1000 every 30 days, the rating should be stable if the stockpile is <1000 and the last vehicle is <30 days ago
16:03:36 <Eddi|zuHause3> so, like, there is not much difference if i have a train with 100 capacity every 10 days, or a train with 500 capacity every 50 days
16:03:53 <Eddi|zuHause3> since both can transport the same amount of cargo in the long term
16:05:14 <Eddi|zuHause3> it would encurage stable clockwork networks instead of greedy take-all-you-can networks
16:10:07 <Eddi|zuHause3> what i am aiming at: if you can only transport 10% of the cargo, only 10% of the cargo should show up at the station, not 70%, and then get mad at you for not transporting them...
16:11:10 <Rubidium> that's going to kill your ECS industries
16:11:23 <Eddi|zuHause3> that's an ECS problem :p
16:11:45 <Belugas> [11:59] <@peter1138> Gets up your nose? <--- lol
16:12:16 <Rubidium> and it's going to kill normal industries too, because of the low rating
16:14:26 <Eddi|zuHause3> that is really a secondary problem, balancing the industry system to the new ratings. it is probably sufficient to leave both the changed rating as well as the changed industry behaviour to newgrfs
16:14:48 <Eddi|zuHause3> afaik newgrfs have already the ability to tweak ratings
16:15:10 <Eddi|zuHause3> it should just get additional variables to base the calculations on
16:16:06 <Eddi|zuHause3> but it is really impossible to get 70% of a standard industry transported with horse carriages
16:16:30 <Eddi|zuHause3> or the passengers that pile up in a paxdest game
16:29:52 <peter1138> if (re.IsMatch(inputEmail)) {
16:34:56 <Rubidium> but... true and false might be a macro!
16:35:39 <Eddi|zuHause3> or objects with a default property accessor
16:37:44 <Eddi|zuHause3> true = new ValidationCheck("FileNotFound");
16:39:05 <Eddi|zuHause3> ValidationCheck::operator==(...){...} :p
16:44:56 <Belugas> docs/ottd-colour-palette.gif is wrong, some values are not really exact
16:45:44 *** lobster_MB has joined #openttd
16:47:43 <Belugas> it's the "OpenTTD Palette Colours: stuff that screws a bit the palette
16:49:08 <Belugas> oh boy... i just found out an old installatin of Open, rel. 0.4.5
16:49:43 <Rubidium> Belugas: nah, 0.1.4 is antique
16:50:59 <Eddi|zuHause3> Belugas: signs of Alzheimer? ;)
16:51:48 <Belugas> yeah, it's within my age-range :)
16:52:01 <Belugas> hello dih, i do indeed kow you :)
16:54:55 <Belugas> giving meaninfull name to 255 colours is quite a tedious job
16:55:49 <Eddi|zuHause3> green1..green10?
16:56:10 <Belugas> meaningfull, Eddi|zuHause3, meaningfull :)
16:56:31 <Eddi|zuHause3> greenthatlookslikeasandwich5weeksold
17:00:10 <Eddi|zuHause3> but really, what is wrong with a naming scheme in the likes of <base colour><lightness%>?
17:02:13 <Belugas> in code, it would look a bit strange
17:02:36 <Belugas> i'm trying to enumifying all hardcoded colour values
17:02:49 <Belugas> trtying to make a bit more... clear
17:04:06 <Belugas> and regrouped logically too
17:04:14 <Belugas> like the animated ones and such
17:04:25 <Belugas> i just do not know how deep i should go
17:05:03 <Wolf01> I started directly with 20 colors defined in my project, so if I need to use one of them I should only remember its name :P
17:09:35 *** frosch123 has joined #openttd
17:15:10 <dih> server_pw used to bring the output 'server_pw' changed to:
17:15:15 *** GoneWacko has joined #openttd
17:18:42 * peter1138 considers what to do...
17:20:07 <dih> it used to be there, i know that :-P
17:20:26 *** Wezz6400 has joined #openttd
17:20:26 <dih> autopilot used to rely on it as a trigger
17:20:38 <dih> to know when the password was manually changed
17:21:17 <Belugas> have you checked the svn logs?
17:21:42 <dih> well - i can only guess that it dissappeared when things were moved around on the console
17:21:55 <dih> so that server_pw now is an alias to patch server_password
17:22:11 <dih> rather than a console variable
17:34:41 <Eddi|zuHause3> but "patch <variable> <value>" still yields output like "new value: <value>"
17:35:03 <Eddi|zuHause3> i don't use the console very often ;)
17:35:29 <Belugas> does the array "_extra_palette_values" is used anywehere else than on gfx.cpp DoPaletteAnimations?
17:36:42 <Belugas> answer seems to be no, from what i can tell
17:37:04 <Eddi|zuHause3> just remove it, and then see where it crashes :p
17:42:04 <Belugas> before crashing, it will fail to compile :P
17:42:30 <Belugas> and since i cannot compile from where i am right now, it's pretty useless ;)
18:13:23 <Tekky> when I use the "list_patches" console command in the console, it no longer displays the YAPP patch variables. Is this due to the history buffer of the console being too small to remember all the output of the list_patches command? Is there a way to increase the size of the history buffer of the console?
18:14:12 <Eddi|zuHause3> i think you can "list_patches <prefix>"
18:26:52 <Eddi|zuHause3> it really should ;)
18:27:01 <Eddi|zuHause3> maybe that was only proposed back then...
18:34:35 <peter1138> Rubidium, is there a reason why we only use 8 digits of the hg changeset identifier?
18:35:28 <Rubidium> so it fit-ish in the revision string
18:36:28 <peter1138> What's the maximum length of that?
18:42:15 <peter1138> Reason I ask is that 'cut -c19-26' is not particularly optimal...
18:43:58 <Rubidium> they changed hg? booh!
18:44:33 <peter1138> Hmm, well `hg tip | awk -F: '/changeset/ { print $3; }'` gets the whole thing.
18:44:40 <peter1138> But we seem to have removed all trace of awk.
18:45:27 <Rubidium> the "problem" is that the branch comes after the revision number
18:45:42 <peter1138> Why is that a problem?
18:45:47 <Rubidium> ofcourse with hg you don't really work with branches
18:45:50 <peter1138> The problem is someone fixed it to character position...
18:46:31 <Rubidium> well, you need to truncate the changeset info
18:46:53 <peter1138> 12 is less than 15 ;)
18:46:54 <Rubidium> and actually use the part after the colon after the numerical revision
18:47:17 <Rubidium> or is that doing awk magic I'm missing
18:47:18 <peter1138> 12 + h + M + \0 is, indeed, 15
18:47:48 <peter1138> It's the third field, as separated by :
18:48:13 <peter1138> Of course, that assumes that all verions of hg output it that way :o
18:48:24 <peter1138> Celestar, so is the cache fixed now?
18:51:10 <Eddi|zuHause3> that was not it...
18:54:36 <Eddi|zuHause3> no, i am trying out the DCOP interface to Konversation
19:29:36 *** Alberth has joined #openttd
19:32:35 *** dragonhorseboy has joined #openttd
19:33:59 *** ChanServ sets mode: +o Bjarni
19:36:45 <dragonhorseboy> how're you bjarni?
19:42:12 <Bjarni> around average, I guess
19:43:09 *** Phoenix_the_II has quit IRC
19:43:19 <dragonhorseboy> doing ok here..just annoyed with the incomptent people at a particular office .. nothing real to worry about tho
19:45:39 *** Eddi|zuHause has joined #openttd
19:49:48 <Bjarni> There is a general "windows explorer" loving community in Denmark called online banking
19:50:11 <Bjarni> hence the reason I never really got into how it actually works
19:51:48 <dragonhorseboy> dunno if its just this city or the transportation office can't tell any difference between "tractor" and "straight body" trucks .. oh well... *goes to read another train magazine*
19:52:12 <Bjarni> One disgruntled customer took an axe to a wooden desk at a Sampo branch after learning his account was supposedly empty. <--- if it contained my life savings I would have gone to the police and reported a theft
19:53:24 <Bjarni> and it's actually a severe kind of theft as they are intrusted with valuables they don't own. Stealing something like that is way more severe than stealing it from just a random person
19:54:06 <dragonhorseboy> ic.. axe to desk? :-S
19:54:08 <Eddi|zuHause> i have absolutely no problem accessing my online banking site in konqueror
19:55:29 <Bjarni> Eddi|zuHause: you aren't using a Danish bank, right? ;)
19:56:53 <Bjarni> then you aren't affected by the group I just mentioned
19:57:14 <Bjarni> now get this: it's for security reasons they only allow IE
19:57:28 <Bjarni> firefox is banned for security issues
19:57:40 <Bjarni> that's the official statement about it
19:58:47 <Bjarni> you can say that again
20:03:05 <dragonhorseboy> bjarni...how is IE with *less security* actually allowed to be alone?
20:04:34 <Ammler> he, I can remember how I complained about that to my bank about 5 years ago...
20:05:04 <Ammler> I wasn't the onlyone :-)
20:05:35 <Ammler> not for Firefox, but for Opera.
20:05:37 <Eddi|zuHause> Bjarni: does it work when you tell firefox to "identify as IE"?
20:06:25 <Eddi|zuHause> konqeror has this entry in the "tips" section: "Verwenden Sie die Funktion Browserkennung ändern, falls eine besuchte Website Sie dazu auffordert, einen anderen Browser zu benutzen (und vergessen Sie nicht, sich beim Webmaster zu beschweren)."
20:08:01 *** Dred_furst` has joined #openttd
20:12:31 <Alberth> The question is, would you trust a bank that considers Firefox unsafe :)
20:18:49 <blathijs> From reading the wtf article, I think that's just a minor issue
20:20:24 <Celestar> peter1138: I think so, yes
20:20:41 <Celestar> peter1138: I haven't made a direct comparison however
20:25:37 <Celestar> peter1138: is your server up?
20:26:33 <peter1138> I've not made any changes today.
20:28:07 *** [com]buster has joined #openttd
20:29:07 <Celestar> I'm going to solve the if-mess in economy.cpp (VehilePayment)
20:29:32 <peter1138> Yeah, there is some redundancy there, or was.
20:29:33 <SpComb> although that claims that it wasn't related to the IT-glitches
20:32:33 <Celestar> peter1138: and inconsistency
20:32:41 <Celestar> peter1138: I've sorted it out mostly already
20:36:44 <Eddi|zuHause> TRWTF is that this is a perfect instance of "never change a running system"
20:37:49 <SpComb> don't fix what isn't broken
20:38:24 <Eddi|zuHause> especially in the paranoid banking sector, where they put each transaction through an identical chain in a second computer system in nuclear safe bunker
20:38:41 <Eddi|zuHause> i can't understand why they would pull a stunt like this
20:38:50 <Eddi|zuHause> Celestar: not about you ;)
20:39:31 <Celestar> we need another playtest of cargodest in the not-too distance future ..
20:41:47 <glx> Celestar: without newgrfs
20:43:12 <Celestar> peter1138: I'll go offline in a new minutes, but I will not keep you ;)
20:46:40 <Celestar> glx without newgrfs is a good idea possibly
20:47:24 <Celestar> if everything else fails, try a) rebuilding the caches after game load or b) reset the routing system of the server
20:47:24 <glx> it's always better to do "desync" tests in a clean environment ;)
20:53:38 <dragonhorseboy> I'm a bit curious about one thing...
20:54:13 <dragonhorseboy> is it plauseable to run openttd on top of low-level emulator to that it could work on a few game consoles? (I meant actual one, not handheld's)
20:54:37 <dragonhorseboy> beside I know there's several that had offical keyboard/mouse device support
20:55:17 <Eddi|zuHause> many newer game consoles can run linux
21:00:04 <dragonhorseboy> eddi...not quite
21:00:21 <dragonhorseboy> so .. question is .. is it possible to get openttd ported in this manner or not really?
21:00:30 <Celestar> anything is possible ;)
21:03:56 <dragonhorseboy> hmm so celestar.. SH-4 200mhz with 16mb of ram good to go? :p
21:18:43 <Eddi|zuHause> dragonhorseboy: you need an sdl port for the console
21:19:15 <Eddi|zuHause> and i have no idea, what an "SH-4" is
21:20:16 <Eddi|zuHause> and these stats look awfully close to the minimum requirements of openttd
21:22:21 <dragonhorseboy> heh its hitachi (now renesas)'s processor anyway
21:22:51 <dragonhorseboy> still in production to today oddly enough
21:25:46 <Eddi|zuHause> ln: there exist !logs
21:26:09 <Eddi|zuHause> ln: didn't you notice that i replied to that?
21:27:09 <ln> omg, i didn't know anyone can use !logs without saying !logs
21:27:30 <ln> i did, but you could have been replying to what Bjarni and others were saying.
21:29:02 <Bjarni> you weren't talking to me :s
21:29:13 <Bjarni> maybe that's a good thing :P
21:32:15 <ln> in general, switching to the Danske Bank web bank system is said to be a 10-year jump back in time in usability.
22:00:42 <Bjarni> you farted and then everybody left
22:09:48 *** dragonhorseboy has left #openttd
22:36:18 * SmatZ just found Michael Moore...
22:38:33 <SmatZ> no, a documentarist :) in TV
22:38:46 <SmatZ> or so... I am never sure about prepositions :-/
22:44:02 <SmatZ> like "I am sitting on TV"? :-)
22:45:13 <SmatZ> maybe it has something to do with article - like "on TV" (media) is somethine different than "on the TV" (my box :)
22:45:18 <Eddi|zuHause> yes, unlike "i am sitting on the TV[-set]". where you would sit on the physical object
22:46:22 <Eddi|zuHause> note that i am not a native speaker either, but i am pretty sure about that one ;)
22:47:20 <Eddi|zuHause> also note that in german you would say "im Fernsehen"
22:47:51 <Eddi|zuHause> (not to confuse with "im Fernseher")
22:49:34 <SmatZ> die Fernseher = media, der (das?) Fernseher = "box"?
22:50:28 <Eddi|zuHause> "das Fernseh[e]n" = the broadcast, "der Fernseher" = the TV set
22:50:39 <SmatZ> aha sorry :-x thanks :-)
22:50:58 <Eddi|zuHause> "fernseh[e]n" = the action of watching TV
22:52:23 <Eddi|zuHause> "im" [=contraction of "in dem"] is never used when the article is "die"
22:52:41 <Eddi|zuHause> "die" -> "in der"
22:53:26 <SmatZ> shame on me, I am not even able to type
22:54:04 <Eddi|zuHause> just pretend you were trying to write french ;))
23:07:15 <glx> it's just "la télévision"
23:18:08 *** Digitalfox has joined #openttd
23:49:03 *** mib_ek0v7x has joined #openttd
23:51:42 *** mib_ek0v7x has left #openttd
continue to next day ⏵
