IRC logs for #openttd on OFTC at 2008-08-11
⏴ go to previous day
00:02:29 <fmauNeko> somebody could get grfcodec working on linux x86_64 ?
00:04:04 <Fennec> if you give it the right compile flags it might be convinced to work
00:18:55 * Fennec watched an x86-64 box and did school assignments on it from time to time
00:19:09 <Fennec> including the kind with pre-provided static libraries :P
00:28:31 <Eddi|zuHause> [10.08.2008 17:49] * peter1138 has discovered that 2.7m long planks of wood fit in his car... if I open the glove box. <- in germany, cargo can stick 1m out of the back of the car
00:30:37 *** Digitalfox has joined #openttd
00:33:10 *** Eddi|zuHause has joined #openttd
00:35:33 * fmauNeko was worndering if a grf file would be enough to add a button in a toolbar :p
00:37:04 <Eddi|zuHause> yay, another hornet...
00:37:16 <Eddi|zuHause> their nest is like 3m from my window
01:00:45 *** Digitalfox_ has joined #openttd
01:29:49 <fmauNeko> Makefile:81: *** multiple target patterns. Stop.
01:38:40 *** Digitalfox has joined #openttd
02:07:23 <Belugas_Gone> [20:35] * fmauNeko was worndering if a grf file would be enough to add a button in a toolbar :p <--- it's not the job of grfs to add buttons to the game
02:07:31 <Belugas_Gone> n fact, grfs cannot do that
02:08:20 <fmauNeko> i'm trying to patch the code :p
02:08:50 <Belugas_Gone> which on? grfcodec's or ottd's
02:08:58 <Belugas_Gone> and for what purpose?
02:11:37 <fmauNeko> Belugas_Gone: ottd, and i'm trying to make highways
02:14:06 <Belugas_Gone> good luck. first, what is the difference (in your mind) with current (one-way) roads?
02:15:09 <fmauNeko> the selection of line numbers
02:18:27 <Belugas_Gone> ---read as ---- what the hell are you talking about
02:26:16 *** Singaporekid has joined #openttd
02:34:08 *** fmauNeko is now known as fmauNekAway
05:12:12 *** De_Ghost has joined #openttd
06:08:22 <peter1138> Eddi|zuHause, yeah, but then I'd've needed straps to hold the boot hatch down.
06:23:55 *** KurtKraut has joined #openttd
06:35:26 *** SpComb^ has joined #openttd
07:22:46 *** [com]buster has joined #openttd
07:29:29 <Ammler> he, how to remove a ban?
07:41:11 *** Sir-Bob has joined #openttd
07:56:12 <Celestar> ey planetmaker I had a quessie for you
07:56:16 <planetmaker> or rather "Grüß Gott"?
07:57:37 <Celestar> what's the carbon content of Mars? Any different from earth?
07:57:57 <planetmaker> uh... no idea. So the assumption that it's approx. the same should be fine.
07:58:10 <Celestar> that's enough for me
07:58:11 <planetmaker> There's no reason Earth should be enriched in it.
07:58:28 <Celestar> Just wondering whether one could produce polymers on Mars with the resources available
07:58:44 <Celestar> peter1138: how is it going?
08:03:11 <planetmaker> Celestar: I guess you could produce polymers. But(!) C might be harder to obtain as it is not bound by any biosphere.
08:03:56 <Celestar> planetmaker: well apart from the CO2 in the atmosphere
08:04:03 <Celestar> but that's not much C
08:04:25 <planetmaker> well... all oil has been biosphere, too. :)
08:04:44 * planetmaker wonders where most C is bound in...
08:04:55 <Celestar> planetmaker: yeah I wonder that as well
08:05:12 <Celestar> dunno the composition of the soil my heart :P
08:05:15 <Celestar> Rubidium: you around?
08:06:29 <Celestar> Rubidium: the fullload game you showed me: WFM :/
08:09:15 <planetmaker> Celestar: limestone, dolomite, CO2, methane is quoted as most abundand representation on wiki
08:11:55 <Celestar> planetmaker: well, obtaining it from limestone and dolomite is easily possible. So you'd get Fe, C for normal structures, Mg for real lightweight system ..
08:12:48 <planetmaker> yeah. most of regolith is (Mg,Fe)2SiO4, which is overly abundant... so, no principal ressource problems, I guess :)
08:13:01 <planetmaker> Planning a new house of yours? ;)
08:13:39 *** Doorslammer has joined #openttd
08:14:17 <Rubidium> Celestar: okay, I looked at the savegame again and now it seems to not occur anymore... !but! ... every time I load the savegame the wagons that are loaded and the amount they are loaded with differs slightly
08:16:05 <Rubidium> 30, 30, 24, 20, 25, 25, 25, 25 vs 30, 30, 22, 20, 25, 25, 25, 25 vs 30, 30, 30, 20, 20, 27, 25, 25, 25
08:16:59 <Rubidium> see the train with the label "first" on the track "above" it
08:17:31 <Celestar> Rubidium: that is _very_ interesting
08:17:56 * Celestar wonders how that is caused
08:19:08 <Rubidium> any of: the routing tables not being cleared properly, the sorting of the routing tables depends on malloced memory, the sorting is unstable and the pivot is chosen randomly, ...
08:20:04 *** planetmaker is now known as pm|away
08:20:22 *** pm|away is now known as planetmaker
08:21:02 <Celestar> Rubidium: checking (=
08:23:54 <peter1138> Companies House is strange...
08:24:00 <peter1138> "The WebCHeck service is available from Monday to Saturday 7.00am to 12 Midnight UK Time"
08:24:13 <peter1138> Because servers can't run 24/7?
08:24:38 <Celestar> peter1138: anything I need to pull/merge?
08:24:46 <Noldo> so they can reboot nighttime and you can't whine
08:24:57 <peter1138> Er, I think there was but it's at home.
08:25:24 <peter1138> Nothing major though
08:26:12 <Celestar> GetVehicleOrder(v, v->cur_order_index)->GetNextUnloadingOrder()->GetDestination();
08:26:20 <Celestar> meant to paste that in gdb (=
08:26:37 <Celestar> doesn't work anyway :S
08:27:02 * Celestar recompiles with debug 3
08:30:39 <Gekz_> does it even run full speed on a good computer with debug 3?
08:31:03 <peter1138> enable-debug 3 or debug_level 3?
08:31:07 <peter1138> Totally different ;)
08:31:43 <Celestar> peter1138: --enable-debug=3
08:31:55 <Celestar> it cannot run full speed with debug_level 7 for me
08:32:05 <Celestar> because the terminal is too slow to print all the chars (=
08:32:45 <Gekz_> Celestar: openttd > somefile.txt
08:33:00 <Celestar> because debug prints to stderr (=
08:33:16 <Celestar> sometimes, I do too (=
08:36:25 <Gekz_> stop reversing the happy faces
08:44:57 <Celestar> Rubidium: mah, the station has 148 cargopackets :P
08:47:09 <Celestar> I coded some total crap :P
08:52:48 <Celestar> Rubidium: can you pull again and re-try?
09:04:25 <Rubidium> Celestar: seems to work now
09:04:43 <Gekz> git push, git pull, git off my lawn
09:05:02 <Celestar> Rubidium: awesome ;)
09:05:19 <Celestar> this is the last day I'm here for almost a week, we'd need to playtest today in the network (=
09:05:19 <Rubidium> yup, I'd prefer git too
09:05:37 <Rubidium> because it doesn't consume memory like hg does
09:06:14 <Gekz> mercurial isnt as bad as monotone
09:06:22 <Rubidium> hg sync with svn leaks 1-4 MB per revision
09:07:00 <Rubidium> git leaks nothing (or at least so near nothing that it isn't noticable in 14000 commits)
09:07:55 <Rubidium> got to reboot hg every night so it doesn't get OOMed by itself
09:08:37 <Rubidium> git is "still" using only 840 kiB since August 2nd
09:09:25 *** Singaporekid has joined #openttd
09:21:53 <peter1138> But hg is easier to use ;)
09:23:49 <peter1138> Right, I reckon I should be okay to load labels in reservation, and the rest in activation.
09:25:44 <peter1138> Hmm, I need to specify more sprites.
09:26:11 <peter1138> I've been working on NewGRF rail types.
09:26:21 <Celestar> what about NewGRF_ports :P
09:26:42 <peter1138> That probably needs rewriting ;)
09:27:03 <Celestar> peter1138: "probably"?
09:27:15 <peter1138> I've not looked at it for ages.
09:28:08 <peter1138> Hmm, I guess I should allow custom catenary too
09:28:18 <peter1138> I wonder how many sprites are needed that for...
09:28:32 <peter1138> Ah ha, I can investigate the wiki :D
09:30:47 <peter1138> Good enough for me :)
09:31:40 <peter1138> 48 sprites needed in TTDPatch for overhead wires... did we add any?
09:34:43 <peter1138> I thought we did something special with tunnels or bridges, but it looks like we still use 48 sprites.
09:35:37 <Celestar> nah we use theirs basically
09:35:46 <Celestar> I kind of tried to emulate their behaviour
09:36:20 <Rubidium> peter1138: the special's for tunnels and bridges are in TTDP too
09:37:23 * peter1138 considers specifying more sprites for bridge surfaces.
09:37:33 <peter1138> Just in case we ever have diagonal bridges...
09:39:24 <Rubidium> I'd keep snowy and desert ground separated
09:39:37 <Rubidium> so multiclimate maps remain fairly easily possible
09:40:38 <Rubidium> though... that'd mean a cargo ID per climate + snow + desert
09:41:11 <peter1138> We could just make it an overlay system, and only have one set.
09:41:21 <Noldo> what are you working on?
09:41:25 <peter1138> Although that wouldn't really work for tunnels.
09:43:40 <peter1138> Noldo: "Railtypes" in the URL might give it away.
09:44:37 *** Progman has joined #openttd
09:45:24 <Celestar> we'd just need to give each cargotype a unique ID
09:45:28 <Celestar> but we're limited to 32
09:47:16 <peter1138> Cargo types should be modified by GRF...
09:48:11 <Celestar> peter1138: we should make a (mental) list what missing until we can merge cargodest into trunk
09:48:42 <Rubidium> a proper desync test
09:49:19 <Rubidium> a review of the code
09:49:52 <Rubidium> a flame of boost (it gives me a lot of warnings because they use deprecated stuff)
09:51:41 <peter1138> Hmm, doesn't for me.
09:52:10 <Rubidium> /usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h.
09:53:47 <Celestar> Rubidium: we need to decide whether to put boost and a requirement (and adjust the configure scripts), or add the boost stuff to our repo (the licensing allows this)
09:54:22 <peter1138> Well in theory you can do everything using the existing data in the station and order pools, but that may be less efficient..
09:54:52 <Rubidium> I'd go for the latter, i.e. add the needed part of boost to our repository
09:55:04 <Rubidium> so we don't get desyncs because someone has a newer/older version of boost
09:55:12 <Progman> you fixed the bug routing edges got removed when autoreplace (try to) appears?
09:55:31 <peter1138> Autoreplace has bigger problems than that.
09:55:36 <Rubidium> Progman: fixing that requires autoreplace to be fixed before
09:55:40 <Celestar> Progman: it's still on my list, but I'm putting this on hold
09:55:51 <Celestar> I agree with Rubidium on that one (=
09:56:01 <peter1138> Hmm, I guess cursors and icons can go in the same lump.
09:56:15 <Celestar> frosch said something about rewriting autoreplace (=
09:56:31 <peter1138> Or do we have a separate cursor/icon for each railtype for depots?
09:57:16 <Peer> Is there an OpenTTD repo?
09:57:33 <Progman> svn, hg, whatever you want
09:58:08 <Rubidium> Peer: use debian/contrib
09:58:17 <Celestar> Who's the head of NoAI these days?
09:59:37 <Rubidium> Peer: and it is in ubuntu/multiverse and in gentoo
09:59:39 *** Peer is now known as HttpError
09:59:47 <peter1138> Hmm, yes, and there's a tunnel icon, and convert rail icon...
10:00:42 <HttpError> but i belive the ubuntu/multiverse is out dated.
10:01:01 *** HttpError is now known as HaloMaster
10:01:12 <Rubidium> then slap them to upgrade
10:01:37 <Rubidium> or just install the debian package that's on sourceforge
10:02:21 <Celestar> Rubidium: what's your idea of "a proper desync test" ?
10:02:31 <peter1138> All this nick changing is making me dizzy...
10:02:35 <Celestar> I mean just playing or something?
10:02:45 <peter1138> Celestar, openttdcoop ;)
10:02:46 <HaloMaster> soz, tryna find my registered nick
10:03:00 <Rubidium> Celestar: as peter1138 said
10:03:24 <Celestar> peter1138: Rubidium: good idea
10:03:29 <peter1138> Hmm, a depot is just two sprites, isn't it?
10:03:43 <Celestar> so Brianetta is my man, right?
10:03:43 <Rubidium> peter1138: depending on the orientation
10:03:49 <peter1138> Oh, that depends on direction :p
10:03:55 <Celestar> peter1138: let's say.. MAX two sprites
10:04:12 <Rubidium> the NE and NW ones have 1
10:04:14 <Celestar> two for the ones faced southish, one for the northish depots
10:04:22 <peter1138> Right, so 6 sprites in total for depots.
10:04:27 <Celestar> "northish" .. can you say that 10 times fast?
10:04:45 <peter1138> It comes out like "nor fish" though.
10:04:47 * Rubidium assigns Microsoft Bob to that task
10:05:59 <Forked> I wonder if it works in vista x64
10:06:03 <peter1138> Currently the level crossing lights/barriers are assigned by the roadside type. Should we keep that?
10:07:02 <peter1138> I'm avoiding varaction2 ;)
10:07:25 * Celestar still wonders whether to tackle NewGrfPorts after cargodest
10:07:25 <Rubidium> one for both road sides
10:07:45 *** stillunknown has joined #openttd
10:07:52 <Rubidium> Celestar: if you do multistop after cargodest and before newgrfports it fine by me ;)
10:08:00 <peter1138> The question I'm asking is should it be defined by road or by rail?
10:08:33 <peter1138> Hmm, I suppose newgrfports makes multistop for ports unnecessary?
10:08:48 <peter1138> Hmm, depends how flexible sea ports will be.
10:09:14 <Rubidium> peter1138: action0levelcrossingbarriers
10:09:33 <peter1138> But action 0 doesn't do anything with sprites.
10:09:51 <Rubidium> peter1138: action<whatever's the right number>levelcrossingbarriers
10:10:27 <peter1138> ActionAnything is missing the point of the question ;)
10:11:18 <Rubidium> I reckon the crossings belong more to the road
10:11:26 <peter1138> Hmm, 12 sprites for PBS reservation... Are they only used for reservation?
10:11:42 <Celestar> Rubidium: I've already got the WIP by mart3p that he did about multistop and he apoliziged that he didn't take care about it after the DTRS have been finished (=
10:11:48 <peter1138> I guess that's 4 for each rail type?
10:12:12 <peter1138> So it's just slope overlays...
10:12:22 <peter1138> So I can just add them to the existing overlays!
10:13:00 *** fmauNekAway is now known as fmauNeko
10:13:06 <peter1138> Technically you could draw all tracks using those 10 overlay sprites.
10:13:11 <peter1138> But it would look pretty ugly.
10:13:20 *** KillaloT has joined #openttd
10:13:36 <Rubidium> and probably tunnels too
10:13:46 <Rubidium> with some chop half of the sprite magic
10:15:09 <Rubidium> though the chop half of the sprite magic is already in trunk (for halftile foundations)
10:16:35 *** Tino|R152 has joined #openttd
10:17:44 <SmatZ> I have a code for sprite generating in runtime (for partially snowy tiles, so they work with newgrfs)
10:17:57 <peter1138> Hmm, level crossing overlay... do we want to allow for diagonal crossings?
10:18:17 <peter1138> Which is another 4 sprites, I believe.
10:18:31 <SmatZ> isn't the problem lack of space in the map array?
10:18:48 <SmatZ> if we want to reserve space for 3rd road type the way it is done now
10:19:46 <Roujin> huh? talking about additional road types?
10:19:49 <peter1138> SmatZ, I am writing down my NewGRF specification for rail types, in the process trying to remove some limitations.
10:20:21 <Roujin> the map array has already all the bits for a third road type reserved
10:20:50 <peter1138> Yes, apparently taking the space that was used by the diagonal crossing patch.
10:21:46 *** Vikthor has joined #openttd
10:21:54 <Rubidium> level crossings still have some free mapspace
10:22:08 *** Tino|R152 has joined #openttd
10:22:35 <Rubidium> so diagonal crossings isn't a mapspace issue
10:23:32 <peter1138> SmatZ, basically I need to do this specification so that we don't end up having to do it TTDPatch's way which will not be flexible enough.
10:23:50 <peter1138> ^ Is quite horrible and very limiting.
10:23:56 <peter1138> And is also unimplemented.
10:25:09 <peter1138> It misses the 'single ID per rail/road type' concept which imho is quite necesary.
10:25:33 <peter1138> Rubidium, so I should allow for it, do you think?
10:26:08 <Rubidium> yes, or at least not disallow it
10:26:17 <peter1138> I've added it in the spec :)
10:27:32 <Rubidium> what about autorail overlay sprites?
10:28:01 <peter1138> Does it need differentiating?
10:28:18 <Rubidium> maybe someone wants to make the distance between the two rails smaller for narrow gauge or make it a single line for monorail or something like that
10:28:57 <Rubidium> basically action 5 type 13
10:30:46 *** Brianetta has joined #openttd
10:31:25 <peter1138> Hmm, well, I'll add it. I guess I'll need a to make a reference on the layout of sprites within each section.
10:31:29 <Rubidium> "invalid pieces" for certain slopes where a train can't run
10:31:55 <peter1138> We should make normal rail building use autorail sprites too.
10:32:11 <peter1138> But that's a different issue :)
10:32:23 <SmatZ> peter1138: looks interesting, though it looks a lot of work :)
10:32:24 *** LilDood has joined #openttd
10:32:43 <peter1138> SmatZ, which are you looking at, my specification or that newroutes?
10:33:10 <Celestar> Brianetta: we could use your help ;)
10:33:27 <Celestar> Brianetta: you're running the ottdcoop right?
10:33:28 <SmatZ> peter1138: I haven't seen your specification
10:33:38 <peter1138> ^ Much saner, imho.
10:33:44 <Brianetta> Celestar: I'm running the web site
10:34:18 <Celestar> Brianetta: who's running the servers?
10:34:45 <planetmaker> Hm... I thought, Brianetta, one of the servers is also on your box?
10:34:49 <Celestar> cuz we'd like to have big test with cargodest
10:35:02 <Rubidium> Celestar: /join #openttdcoop
10:35:11 <planetmaker> Otherwise they're Ammler's and Phoenix_the_II's servers. But you may just ask #openttdcoop :P
10:35:33 <HaloMaster> hey, i can do a server if you need
10:36:38 *** lobster_MB has joined #openttd
10:36:42 <HaloMaster> i can give you root on it for a few days
10:38:45 <HaloMaster> or even keep it, im not using it for much.
10:40:07 <Brianetta> planetmaker: Used to be, certainly
10:40:58 <planetmaker> I guess we found a server :)
10:41:33 <HaloMaster> i have a server you can use
10:41:37 <planetmaker> seems somewhat appropriate :)
10:41:42 <Celestar> HaloMaster: I have a server (=
10:41:51 <Celestar> HaloMaster: the problem is players (=
10:42:02 <HaloMaster> ill play, i just need the files
10:42:23 <Celestar> Noldo: When the boost thing is solved and we have nightlies
10:42:27 <Celestar> sometime this week I guess
10:42:30 <HaloMaster> Celestar: Just pm me and ill give you the details to my server
10:44:42 <Celestar> peter1138: we should decide on a boost version at some point
10:44:43 <Noldo> Celestar: what is the boost thing about?
10:44:55 <Celestar> Noldo: it's a library we use for cargodest
10:45:31 <Celestar> Noldo: we're using the boost graph library (BGL) that is for, doh, graphs
10:45:48 <Noldo> but what it the 'thing' about it that needs solving?
10:46:17 <Celestar> Noldo: er ... basically how to include it in openttd
10:46:22 <Roujin> they want to include the necessary files so that users don't have to install it externally
10:46:26 <peter1138> Celestar, I'd say "latest", to be honest. It can be updated later then, too...
10:46:34 <Celestar> Noldo: currently preferred option is svn:externals
10:46:59 <Celestar> peter1138: you mean HEAD at time of checkout or HEAD of now?
10:47:53 <Celestar> Rubidium: you said you wanted a code review. Wanna do one? :P
10:49:27 <peter1138> Celestar, as long as it's always the same for a given OpenTTD revision...
10:51:35 <Celestar> peter1138: I'll try to identify a good and working boost revision
10:53:09 <Celestar> I have class foo { virtual void f() = 0; }; class bar : public foo { virtual void f() { DoSummin(); } }; class qux : public foo { void f() { DoSummin(); } };
10:53:23 <Celestar> what's the difference between bar::f and qux::f
10:55:49 <Noldo> the DoSummin is a static function or const in terms of this
10:56:34 <Celestar> or rather: when I should use one or the other?
10:59:41 <Progman> Celestar, peter1138: something new to pull for paxdest?
11:00:07 <planetmaker> Celestar: when you have a version which you want to run on our dev server, please just say so and then tell me where from :)
11:00:26 <Celestar> Progman: since when?
11:00:31 <Celestar> planetmaker: will do so
11:00:50 <planetmaker> having it as svn branch indeed would be easiest for me - I know how to handle that :)
11:00:51 <Progman> around the 7. and 8. Aug
11:01:20 <planetmaker> (or as patch to trunk)
11:01:41 <Celestar> Progman: quite some fixes
11:01:43 <planetmaker> and I'm quite looking forward :D
11:02:25 <Roujin> Celestar: the income/transfer display is not fixed yet, right?
11:02:29 <Celestar> planetmaker: let's hope there aren no desyncs
11:02:46 <Celestar> Roujin: no because I'm not quite sure what is actually going wrong
11:03:11 <Celestar> Roujin: if you have a savegame, it'd be awesome
11:03:17 <Celestar> Roujin: is it reproducible?
11:03:31 <Roujin> it seems to happen all the time at my game...
11:03:50 <Progman> how do I check which revision I got in the hg checkout?
11:04:14 <Progman> as there is no "hg info" o_O
11:05:19 <Progman> got it (..somehow) with hg heads
11:06:29 <Roujin> then again.. I'm not sure I'm really running the newest version since it said after pulling that i have to run "hg update" to get a working copy, which I haven't done
11:07:13 <Roujin> and right now my turtoiseHQ freezed :/
11:07:49 <Progman> Roujin: I got 19509:d2c82481a3b6 from Fri Aug 08 18:20:11 2008 +0100, check if you got a newer one ;)
11:08:50 <Progman> hmm, its eating cpu usage like hell
11:09:18 *** SmatZ is now known as Guest1211
11:09:57 <Celestar> how big is the game?
11:10:40 <Progman> ~100 trains with ~100 stations
11:10:41 <Celestar> Progman: there have been HUGE performance increases since then ;)
11:11:11 <Progman> so, 19509:d2c82481a3b6 isn't the newest update?
11:12:06 <Roujin> what number is that anyways oO
11:12:18 <Celestar> peter1138: Rubidium: when declaring a virtual function in a derived class, should we mark it with /* virtual */ and if so, declaration only or declaration and definition?
11:12:30 <Progman> how to get the newest?
11:12:39 <Celestar> the number is revision_number:SHA1hash
11:13:51 <Eddi|zuHause> hm... depot sprites... what if anyone wants to do a "transparent" depot, then he'd also need two sprites for the "northish" ones
11:14:01 <Roujin> I think I understand now why I had those desyncs when we did that multiplayer test
11:14:31 <Roujin> i forgot the hg update, so I got the new revision number but not the changes >_<
11:14:48 <Roujin> I think that was the case..
11:15:07 <Celestar> Roujin: yeah that is possible
11:15:07 <Progman> "abort: outstanding uncommitted merges"
11:15:17 <Celestar> Progman: you have local changes?!
11:16:03 <Celestar> peter1138: I'm moving all the method doxygen stuff into the ABC
11:16:25 <Roujin> well I still get a bunch of warnings on the boost files upon compiling, but meh.. :)
11:16:30 <Progman> abort: uncommitted merge - please provide a specific revision
11:16:44 <Progman> hg may be great if I know how to use...
11:17:21 <Roujin> ah and the makefile does still "grep -m" which my grep does not know :)
11:17:45 <Celestar> Progman: maybe you should just delete everything and start over with the pull (=
11:18:40 <Eddi|zuHause> and i'm far away from cygwin
11:18:44 <Roujin> quote on that page: Finding no such equivalent with the default grep, sorry. :/
11:19:43 <Noldo> what on earth is defaylt grep?
11:21:26 *** Digitalfox has joined #openttd
11:21:57 <Roujin> umm... grep is a program that lets you search through files, basically
11:22:36 <Eddi|zuHause> i'm pretty sure he wondered about the "default" part, not the "grep" part :p
11:23:29 <Roujin> well the guy that I quoted probably means "the grep that was shipped with my machine" or something
11:24:14 <Roujin> or, that came with my OS
11:24:14 <peter1138> SmatZ, does it make sense? heh
11:27:45 <Roujin> Celestar: i didn't have the latest version running, so I'm updating now and will then check if the income/transfer display still displays weird stuff :)
11:30:14 *** Wezz6400 has joined #openttd
11:30:44 <Celestar> Roujin: I guess it does (=
11:33:05 *** lobster_MB has joined #openttd
11:35:33 <blathijs> Celestar: Why do you want to put virtual in a comment?
11:35:48 <Progman> ou yeah, performence is much better ;)
11:35:53 <blathijs> Celestar: Or do you mean if the superclass function is virtual, but the subclass' version isn't?
11:37:09 <Celestar> blathijs: class foo { virtual void f() = 0; }; class bar : public foo { void f(int blah) {return blah + 1;} // this function is virtual! };
11:38:17 <blathijs> Celestar: You mean, our parent's version of this function is virtual, then
11:38:35 <blathijs> Makes sense to put that in comment I guess
11:38:46 <Celestar> blathijs: so some people write: class bar : public foo { /* virtual */ void f(int blah); }
11:38:52 <Celestar> well, doxygen knows that automatically
11:39:00 <Celestar> and I dunno whether the user of the class really cares
11:39:14 <Roujin> okay, so the income/transfer text issue is still there. It looks like the following:
11:39:46 <ashaw> is signal status stored in the map array?
11:40:09 <Roujin> I load a game. There are some trains that get both income and transfer money. They display "Transfer: [some amount] Income: 0"
11:41:01 <Roujin> after some time, it changes to "Transfer: [some amount] Income: DM 24.870"
11:43:00 <Roujin> in pounds it will always say "Transfer: [some amount] Income: 8,290"
11:43:08 <Celestar> Roujin: can you give me a savegame please?
11:43:16 <Celestar> hey doxygen inherits documentation \o/
11:49:52 <Roujin> the next three trains arriving at Sleburg train station should all show the behavior
11:50:46 <Roujin> hmm now it shows some other number than 24.870, but it's the same for all the trains
11:50:57 <Roujin> guess it's a pointer pointing somewhere into garbage memory
11:51:44 <Celestar> let me wrap this cleaning up and then I'll have a look at it
12:00:07 *** Dred_furst has joined #openttd
12:05:06 *** [1]Roujin has joined #openttd
12:06:05 <Ammler> Roujin: does your intro patch still work?
12:07:04 <Yorick> what's the max value a penalty for a tile can be in YAPF?
12:07:43 <[1]Roujin> Ammler: not with current trunk
12:08:00 <[1]Roujin> that part was OO'ified
12:08:38 <[1]Roujin> I can't just access it from the main menu any more :( so it'd need quite some rewrite
12:09:17 <Ammler> does commanderz's patch also jump?
12:09:51 <Ammler> also from sign to sign?
12:09:53 <[1]Roujin> to random positions or to signs?
12:09:59 <[1]Roujin> the jumping is not the problem
12:10:02 <Yorick> I think it's using roujin's patch
12:10:16 *** stillunknown has joined #openttd
12:10:37 <Yorick> what's the max value a yapf penalty can be?
12:11:16 <Yorick> Ammler: I'm working on penalty-points, what value shall I clamp them to?
12:12:31 <Ammler> too short stations have 4k, that is imo the highest default
12:12:34 <Yorick> Ammler: like openttdcoop uses stations to say trains shouldn't prefer to go somewhere
12:12:50 <Ammler> apart from the eol of 2way red
12:13:03 <[1]Roujin> the yapf patch settings are stored in UINT, and their max value is 1000000 for most
12:13:22 <Yorick> sizeof(uint) == sizeof(uint32)?
12:14:27 <[1]Roujin> 20000 for pf.yapf.rail_longer_platform_penalty, pf.yapf.rail_longer_platform_per_tile_penalty, pf.yapf.rail_shorter_platform_penalty and pf.yapf.rail_shorter_platform_per_tile_penalty
12:15:00 <Yorick> is that the default or the max?
12:15:14 <Yorick> ok, I'll clamp to that
12:15:18 <Ammler> hmm, thought 4k is default
12:15:26 <Celestar> Progman: any performance problems with the latest version?
12:15:29 <[1]Roujin> 1.000.000 for all others than those 4
12:15:29 <Ammler> but I might have a screwed cfg :-
12:15:43 <[1]Roujin> Ammler: default for what?
12:15:55 *** lobster_MB has joined #openttd
12:16:01 <Ammler> well, source should tell you better :-)O
12:16:23 * peter1138 ponders rearranging the sprites entries to have common ground between road & rail
12:16:57 <[1]Roujin> Ammler: default for what penalty?
12:18:29 <peter1138> Hmm, road types require a bit more thinking on the overlay front.
12:18:50 <[1]Roujin> for pf.yapf.rail_shorter_platform_penalty default should be 4k
12:19:40 <Celestar> recomputing the entire route network with debug=3 can be unfun
12:21:20 *** grumbel has joined #openttd
12:24:19 <Progman> running with routing=6 is unfun too ;)
12:29:43 <[1]Roujin> Celestar: economy.cpp:1485 --vehicle_profit ++route_profit
12:30:01 <[1]Roujin> compiling and testing atm
12:31:22 <[1]Roujin> could be wrong though..
12:33:21 <Celestar> what the HELL is Money :P
12:34:39 <Celestar> yeah and how do I print its value?
12:34:49 <Celestar> I mean human-understadible?
12:34:56 <Celestar> $17 = { m_value = 894842471656328
12:39:23 <Celestar> (gdb) p (long long)cost.m_value
12:39:24 <Celestar> $24 = -4636689425023685744
12:40:07 <Celestar> what kinda variable is this then :P
12:40:27 <Celestar> and how can "GetString" operate with "Money" ?
12:41:24 <peter1138> SetDParam(0, MoneyValue); ...
12:41:58 <Celestar> but how can I read out it's value
12:42:12 <Celestar> it appears impossible
12:42:13 <ln> errrr, that terrible SetDParam thing is still in use?
12:43:14 <Celestar> for lack of a better alternative
12:43:31 <peter1138> It works well enough.
12:43:48 <glx> and it supports newgrf params
12:44:57 <Celestar> I still wonder how to read the value :P
12:45:18 <Celestar> of a "Money" variable
12:45:37 <Celestar> #0 ShowFeederIncomeAnimation (x=7060, y=6248, z=16, cost={m_value = -4636689425023685744}, income={m_value = 894842471656328})
12:45:40 <Celestar> this looks all fucked up
12:46:25 <Ammler> how can I see, which svn rev is the last merged in a hg repo?
12:46:35 <Ammler> just look for (svn:XX)
12:47:54 <Ammler> then I update svn trunk to that rev and run "diff -u hg-repo svn-repo" to make a svn diff?
12:48:56 <[1]Roujin> Celestar: got something here
12:49:57 <glx> Celestar: there's a (int64) operator
12:50:38 <[1]Roujin> could it be that you wrote the second value in "SetDParam(1)" and here (texteff.cpp:309) it reads GetDParam(4) ?
12:51:22 <[1]Roujin> SetDParam(1) in misc_gui.cpp:590
12:52:34 *** Davidbrcz has joined #openttd
12:53:32 <[1]Roujin> oh. I thought it was an order
12:54:49 * [1]Roujin yet again rearranges himself, but is missing an eye that has rolled under the sofa :(
12:55:19 <Davidbrcz> guts, i'm a noob at openttd and i've a question
12:55:36 <Davidbrcz> train and camion fail down too much
12:56:22 <Davidbrcz> do you know how i could avrte this ?
12:56:45 <[1]Roujin> Celestar: seems to work better now, but there's a minus too much I think
12:57:01 <Celestar> [1]Roujin: yeah I'm already fixing it (=
12:57:05 <[1]Roujin> income: [red]- something DM
12:57:52 <glx> Yorick: yes you used tabs when you should use spaces
12:59:07 <[1]Roujin> comments are out of shape
13:01:26 <glx> Yorick: why not do it like other penalties?
13:01:55 <[1]Roujin> he wants it to be configurable on each waypoint
13:02:25 <[1]Roujin> so that one can set up different waypoints with different penalties
13:02:51 <Celestar> [1]Roujin: but good find
13:03:05 <Celestar> [1]Roujin: I dunno why the hell AddTextEffect only reads the first and fifth parameter :P
13:03:09 <Yorick> and it's the idea of it :)
13:03:18 <[1]Roujin> Celestar: you might hit another difficulty with that double scrolling text
13:03:29 <[1]Roujin> seems the right end flickers some times
13:03:36 <Yorick> Roujin: I only used tabs at the beginning of lines
13:04:03 <glx> not in english.txt Yorick
13:04:14 <[1]Roujin> Yorick: oh, then I don't know why it's misaligned. Maybe pastebin broke it
13:05:03 <Celestar> [1]Roujin: that's not the ONLY problem
13:05:09 <Yorick> glx: I'm quite sure I'm using spaces there
13:05:31 <glx> the misalignment proves the opposite
13:06:09 <[1]Roujin> Celestar:... beats me
13:06:32 <glx> if it's misaligned in pastebin, it's misaligned in your code (or you used tabs)
13:06:34 <Celestar> [1]Roujin: check the income .. it changes
13:06:41 <Yorick> what fonts are you using?
13:07:30 <Yorick> hmm, could you name one for me?
13:08:10 <[1]Roujin> uhm... what do you mean, it changes? :/
13:08:47 <Celestar> [1]Roujin: during the "ascent" of the text effect, the value it displays changes
13:08:52 <Yorick> but english.txt is a complete unaligned mess for me
13:09:27 <[1]Roujin> uh.. is that a known issue?
13:09:43 <glx> then your editor doesn't use a monospace font for .txt
13:09:44 <[1]Roujin> or is it specific to your code
13:09:46 <Celestar> [1]Roujin: no. only with transfers, sor not in trunk
13:10:41 <[1]Roujin> hmm, it only happens on the income part, not the transfer part it seems
13:11:35 <glx> Celestar: then the value is changed by something
13:12:12 <Yorick> ah, it was misaligned here
13:12:19 *** Belugas_Gone has joined #openttd
13:12:19 *** ChanServ sets mode: +o Belugas_Gone
13:13:49 *** Belugas_Gone is now known as Belugas
13:16:13 <Celestar> peter1138: is it ok when we display "Transfer: " and "Income: " on top of each other instead of next to?
13:18:51 <glx> better, still wrong in waypoint.h
13:18:53 <Progman> Celestar: the way it shown next to each other looks great
13:19:48 <Celestar> Progman: I agree, but that might mean rewriting the TextEffect thingy if I want it working :P
13:19:48 <glx> Yorick: and functions should start with a cap
13:21:19 <Progman> Celestar: what about sct like (the wow addon) *g*
13:21:32 <glx> Yorick: btw it should work for all PFs
13:21:52 *** tokai|ni has joined #openttd
13:23:35 <Belugas> _rename_what -> MAGIC NUMBERS :D
13:23:47 <Celestar> Progman: er .. what?! :P
13:24:31 <Progman> Celestar: I try to search for a video which shows this "scrolling combat text"
13:24:53 <Progman> for a new TextEffect thingy ;)
13:25:10 <Celestar> it's not my intention to rewrite the GUI in the cardodest development :P
13:25:39 *** JdGordon has joined #openttd
13:26:29 <Progman> imagine that with "Income" to the left and "Transfer" to the right ;)
13:28:05 <JdGordon> hey all... can anyone point me to roughly where in the code I would look to fix it so ctrl+alt+click would remove a signal (like ctrl+click does for tracks)? not being able to remove signals without manually chooising the removal tool is driving me nuts
13:28:06 <Progman> not just going up but like a rainbow ;)
13:28:40 <glx> JdGordon: press 'R' when tool signal is selected
13:31:07 <JdGordon> so, with the new signals are the old presignals still needed?
13:32:10 <[1]Roujin> Celestar: well it beats me why that happens to the income part but not to the transfer part
13:32:38 <Eddi|zuHause> JdGordon: not for normal users...
13:33:22 <Belugas> JdGordon, they can be mixed and we do not want to force users to use this or that signal
13:33:39 <Celestar> Belugas: do you know anything about the Texteffect thingy?
13:33:42 * JdGordon loving the new signals
13:33:55 *** ChanServ sets mode: +o Bjarni
13:34:00 <Belugas> Celestar, anything specific?
13:34:25 <Belugas> i've got very little knowledge of the whole text stuff, to be honest
13:34:41 <Belugas> but ask, and we'll dig it together (if time allows of course)
13:34:48 <glx> Celestar: do you have a diff?
13:35:00 <Phantasm> Belugas: Any significant updates on general for OTTD in uhm half a year?
13:35:23 <Celestar> Belugas: yes. I have added a texteffect with two Dparams (0 and 4 because AddTextEffect does that). Now while the text effect is on display, the second parameter (index 4) changes when I set it for another text effect
13:35:30 <Celestar> glx: diff against what? ;)
13:35:58 <glx> well is the bug in your working copy or is it commited?
13:36:54 <Belugas> dparams 0 and 4? seems wrong to me. maybe waht happens is that another string fiddles with your 2nd param
13:37:26 <Celestar> glx: the bug is in my working copy
13:37:52 <Celestar> Belugas: apparently texteffects are not ment to use > 1 DParam
13:37:56 <glx> then a diff can help to find the bug :)
13:39:24 <Celestar> this is where I am now :P
13:40:31 <Belugas> Celestar, add another SKIP ?
13:42:08 <[1]Roujin> why? it uses 0, skips 123, then uses 4..
13:42:19 *** Doorslammer is now known as Borkslammer
13:42:22 <glx> btw it seems there's never a SetDParam(4,xxx) before AddTextEffect
13:42:51 *** Borkslammer is now known as Doorslammer
13:43:17 <glx> so maybe you can change AddTextEffect() to take param 1 instead param 4
13:43:53 <[1]Roujin> is it documented somewhere which DParams are used for what?
13:44:08 <Celestar> [1]Roujin: yes. src/lang/$LANGUAGE.txt
13:44:48 * Belugas reads the code of AddTextEffect
13:46:04 <glx> ,...ss->params[0] = params_1;
13:46:04 <glx> ,...ss->params[1] = params_2;
13:46:23 <glx> that could explain things
13:46:55 <Celestar> glx: but it's never really set :P
13:47:13 <Celestar> glx: SetDParam(1, ss->params[1]);
13:47:18 <Celestar> that's where it is used
13:47:24 <Celestar> as a "normal" DParam
13:48:01 <glx> but params[1] is indeed param 4 used in AddTextEffect
13:48:19 <Celestar> but what's the idea behind this
13:49:03 <peter1138> Damn it, I don't have grfcodec :o
13:49:06 <glx> dunno, probably old stuff
13:49:44 <Belugas> confirmed, 4th param is never set
13:49:52 <Belugas> only used in misc_gui.cpp
13:50:05 <Celestar> Belugas: yeah, but why and how is it overridden?
13:50:12 *** Singaporekid has joined #openttd
13:50:24 <Belugas> i think it's more left overs, not sure, still digging
13:50:53 <peter1138> Nah, building it :)
13:51:21 <Celestar> Belugas: it's never used ANYWHERE :o
13:51:49 <Celestar> Belugas: the question is: why and how is it overwritten?
13:52:13 <glx> it uses what is in the memory
13:53:01 <Celestar> glx: so why is the parameter 0 not "overwritten" ?
13:53:19 * Belugas checks AddStringToDraw
13:53:31 <glx> just fix AddTextEffect() and UpdateTextEffect() to use param 1
13:54:25 <glx> text effect param 2 is dparam 4 but AddStringToDraw put it as dparam 1
13:54:58 <glx> so your string reads what ever is at dparam 4 when it's drawn
13:55:49 * Belugas wonders about usefullness of such a system, by the way
13:56:03 <Celestar> Belugas: zero, but that's what I have ...
13:57:08 * Belugas have learned recently that very view code is not usefull, no matter how "silly" it might look
13:57:31 <Yorick> glx: I can make it work for npf too, ntp I'm not sure of
13:58:40 *** [com]buster has joined #openttd
14:00:24 <Belugas> ViewportDrawStrings just copies back the copid params of AddStringToDraw to params 0 and 1
14:01:31 <Belugas> Celestar, have yoyu tried without the skips?
14:05:31 <glx> Belugas: the problem is probably in AddTextEffect and UpdateTextEffect
14:06:08 <[1]Roujin> The whole stuff with DParams has to do with newgrfs, so that they can override the strings, right?
14:06:41 <Belugas> not in this problem, [1]Roujin
14:07:14 <[1]Roujin> else they could just be passed as parameters?
14:07:43 <[1]Roujin> instead of writing them in some global array and then reading from it again? :/
14:08:02 <Belugas> just that the need to "jump" parameters like that eludes me a lot, knowing where the code is called
14:08:06 <Eddi|zuHause> [1]Roujin: the "DParam" system is probably from r1
14:08:07 <glx> [1]Roujin: it comes from how it's done in TTD
14:08:23 <glx> that's why newgrf use the same system
14:10:11 <Yorick> glx: ntp doesn't know penalties...
14:10:19 <Belugas> [1]Roujin, if ever the system has to be re-written, it will have to be able to read and adapt to newgrf strings
14:10:25 <Belugas> so, better let it as it is
14:10:33 <Belugas> and just fix incoherences
14:11:37 <Rubidium> [1]Roujin: but parameters can't be memcpy-ed to a secondary array to be drawn again later
14:13:23 <Rubidium> and doing things like: rotate the top 4 parameters is tricky to do too
14:13:29 <Rubidium> when using parameters
14:15:49 <Yorick> Belugas: should I enumify _rename_what?
14:16:39 <Belugas> not sure Yorick. I wonder if it can simply be replaced by a new process instead... pretty lame tu use a global to specify what is been renamed, in my book
14:20:16 <Progman> Celestar: the vehicle cargo view view will be updated to show all cargos destinations like in the station view, won't it?
14:21:58 <Celestar> Progman: ask peter ;)
14:22:15 <Celestar> not sure that is really practical
14:23:00 <Progman> atm you got "just": 45 Pax (360 Pax)
14:23:01 <[1]Roujin> I'd say in the "total cargo" tab only
14:23:13 <Progman> and have no clue where they want ;)
14:23:18 <Celestar> [1]Roujin: good idea. Pull again from galadriel and see what you see
14:23:37 <Celestar> peter1138 will gladly do it
14:23:54 <Celestar> I think for the individual wagon view it is 1) clumsy and 2) pointless, but the Total display .. why not
14:24:00 <Celestar> maybe only destinations and not origins
14:24:40 <Celestar> peter1138: I will be offline tomorrow, most likely wednesday and Thursday-Saturday
14:26:35 <[1]Roujin> shit, clicked on "browse"
14:27:26 <glx> it will be harder to do it for other than train I think
14:27:47 <Progman> btw. what happends to cargo packages which cannot delivered to the destination anymore? hanging around in the network or get they dropped/retargered?
14:28:20 <Celestar> Progman: depends on reason
14:28:36 <[1]Roujin> I have seen some mail lying around going to "anywhere"
14:28:41 <Celestar> Progman: if the acceptance changes, they get retargeted
14:29:32 <Celestar> Progman: that's about the only relevant thing for the routing system
14:29:33 <[1]Roujin> compiling.. that will take a while :D
14:29:42 <Celestar> [1]Roujin: er .. I'll have to go in a minute
14:29:50 <Celestar> just keep posting here or even better: PM me
14:30:28 <Celestar> celestar@openttd.org would be great too
14:31:08 <Celestar> Progman: if you cannot reach the station anymore at all, they get dropped
14:31:17 <Celestar> (cleanly, not while in transit :P)
14:31:46 <Progman> "no ticket" like in indy3/dogma ;)
14:32:18 <Celestar> peter1138: if you have any fixes/changes, can you fire up your hg later tnoight?
14:42:26 <Rubidium> peter1138: action 0 road type property 0D seems pointless to me
14:43:09 <Rubidium> hmm, actually a lot of numbers seem to be incorrect
14:46:14 <Belugas> + inline uint32 GetPenalty() { return this->penalty; }
14:46:29 <Belugas> would add const between penaly and {retu
14:47:36 <Yorick> it isn't really a const
14:47:55 <dih> patch setting for a default penalty?
14:48:20 <Belugas> granted, but you do not cahnge the internals by Getting Penalty
14:48:26 <Belugas> thus, the call is a const
14:48:36 <Belugas> even is the value is not
14:49:18 <Yorick> dih: no, programmable penalty for waypoints
14:50:01 <dih> yes - but why not a server default value, instead of a hard coded 0
14:50:10 <dih> like all yapf penalties are also configurable
14:51:09 <Yorick> why would you require a default any higher than 0?
14:51:22 <Belugas> becasue he's a server admin...
14:51:32 <Yorick> the idea is that you can optionally set a penalty for waypoints
14:51:55 <dih> and if i optionally want waypoints on my server to have the same penalty as road crossings?
14:52:14 <Yorick> then users would be able to change them away
14:52:23 <dih> yes - sure they can change them
14:52:27 <dih> but the default no longer was 0
14:52:29 * Yorick doesn't think belugas is always right
14:52:34 <dih> which has a totally different handling
14:52:41 <Yorick> dih: I'll implement :)
14:53:11 <dih> and while you are at it, an option that stops users from changing the server side configured default
14:53:31 <glx> + if (IsRailWaypoint(tile))
14:53:31 <glx> + cost += GetWaypointByTile(tile)->GetPenalty();
14:54:56 <Yorick> it is a single lime if
14:55:18 <Eddi|zuHause> no, it's clearly a two line if()
14:55:54 <Eddi|zuHause> i can count the lines: one, two. there? seen it?
14:56:03 <[1]Roujin> if (IsRailWaypoint(tile)) cost += ...; <-- that's okay
14:56:27 <[1]Roujin> if (IsRailWaypoint(tile)) [ENTER] <-- use brackets
14:56:34 <dih> well - you can detect single line if's just by the fact they are on a ... single line!
14:56:54 <Yorick> glx: look at line 129 of the same file
14:57:06 <Yorick> if (IsLevelCrossing(tile))
14:57:08 <Yorick> cost += Yapf().PfGetSettings().rail_crossing_penalty;
14:57:50 <glx> KUDr tends to not follow the style
14:58:21 <Yorick> what has he done today?
14:58:40 <dih> entered a channel, and greeted me
14:58:45 <dih> that's all i care for right now :-P
14:59:01 <Yorick> you greeted him first :P
14:59:17 <Belugas> Yorick, life wold be far more enjoyable if you stopped arguing abut every comments been done
14:59:30 <Yexo> Belugas: are you sure it is?
14:59:54 * Yorick still doesn't think belugas is always right, but is not going to argue about that
14:59:55 <Belugas> well.. Yorick cold disappear, that would help :D
15:00:32 <Belugas> but i'd say that sometimes, the kiddo does bring some vaguely usefull stuff, if not amusement
15:01:08 <Belugas> ho... i'm not always right, by far, and i never intended to be :)
15:01:35 <Yorick> could you stop channenging me to argue then :)
15:02:46 <Belugas> ho... like... /ignore Yorick?
15:02:52 <glx> @kick Yorick don't argue with the devs
15:02:52 *** Yorick was kicked by DorpsGek (don't argue with the devs)
15:03:07 <Yorick> glx: I didn't even do that yet!
15:03:26 <glx> better safe than sorry ;)
15:03:52 <Yexo> <Yorick> glx: I didn't even do that yet! <- you just started :p
15:04:40 <dih> good job Yexo aint an official dev
15:04:59 <Yorick> neither is he an unofficial one, afaik
15:05:12 <Belugas> who knows, he might eventually be
15:05:12 <dih> he's one of the favourd noai patchers :-P
15:05:14 <Yexo> what is an 'unofficial' dev anyway?
15:05:29 <Belugas> Yorick, he has far more stuff been commited than you :P
15:05:41 <dih> and he never talks gibberish
15:05:42 <Yorick> he makes far more useful patches
15:06:08 <Yexo> well, it's far more easy to get something committed to noai than to trunk
15:06:27 <Belugas> but since noai is going to be in trunk one day...
15:07:02 *** welshdragon has joined #openttd
15:07:40 * dih looks forward to that day
15:09:10 * Yorick looks more forward to the day newgrfports gets merged
15:10:03 * Yexo thinks both of them will take quite a while
15:10:04 <Pasko> Hi, would you guys be interested in a Grid Server mirror? i won free lifetime media temple hosting and i wish to support OpenTTD
15:10:41 * Belugas forwards to TrueBrain
15:11:24 *** Pasko is now known as Enkera
15:12:15 <Bjarni> lifetime hosting.... I wonder if it's still valid in 70 years
15:12:48 <dih> i'll show you the way :-P
15:12:51 * Yexo wonders if OpenTTD is still alive in 70 years
15:13:10 <SpComb> will media temple still be alive in 70 years?
15:13:15 <SpComb> less likely than OpenTTD being alive then
15:13:18 <Enkera> we'll all be in huge simulators and driving the trains ourselves
15:16:23 <Eddi|zuHause> i have a feeling in 70 years the copyright issues are still not resolved...
15:17:08 <Enkera> in 70 years you only have to think up a game and the computer will generate it for you :P
15:20:32 <Eddi|zuHause> that's a common misunderstanding of computers... when the easy questions are easier to answer, the questions get more difficult
15:20:53 <Eddi|zuHause> there are always questions left that are not easy to answer
15:26:22 <Yorick> dih: would you like the option of disabling waypenalties as a gui setting?
15:26:26 *** frosch123 has joined #openttd
15:27:08 <dih> Yorick: what do i do with qui setting?
15:27:32 <dih> perhaps it should be possible to have a server side default, that propagates to a client side default and the client side default is what is used
15:27:44 <dih> and a server side setting to enable / disable clients from changing that default
15:28:03 <Belugas> not all server admins are using console commands...
15:28:12 <Belugas> not all servers are dedicated
15:28:28 <dih> non-dedicated servers also have a console :-P
15:28:42 <dih> and how do you change the server password on a non dedicated server?
15:28:54 <Belugas> yeah, but not all server admin want to deal with console :P*2
15:28:57 <dih> how do you change yapf penalties on a non-dedicated server?
15:29:13 <fmauNeko> hmm, when trying to make, i have that : Makefile:81: *** multiple target patterns. Stop.
15:29:50 <Yorick> penalty settings don't have gui options
15:30:00 <Rubidium> fmauNeko: don't use a path with a colon in it
15:30:16 <Rubidium> as that breaks make horribly
15:31:19 <dih> Belugas: there are a lot of settings that cannot be changed with the gui
15:32:40 <Belugas> yeah well... might change one day
15:32:58 * Belugas has an idea for that, but no time to work on it
15:35:37 <Rubidium> dih: what settings can't be changed in the GUI version of OpenTTD?
15:37:16 <Yorick> NPFSettings, OPFSettings
15:37:18 <dih> to change those, one either has to enter a command via console, or change directly in the config
15:37:31 <Rubidium> the console is a gui! :)
15:37:58 <dih> Rubidium: now you are just splitting hairs, and you fully know what i mean ;-)
15:38:08 <dih> Yorick: you know what heppens when arguing with dev's
15:38:32 <dih> besides - why do you respond when a line starts with 'dih:'?
15:39:09 <Yorick> because I had a screen with the answers in front of it...
15:40:01 <dih> those are annyoing trades :-P
15:41:13 <dih> rephrase - those are trades that annoy me :-P
15:41:26 <dih> will not want to speak for others....
15:41:38 <Yorick> now I can agree to you :)
15:41:48 <Rubidium> dih: then you "just" have to wait till someone is bored enough to rewrite the configuration GUI stuff
15:42:20 <Brianetta> Any way to un-stick a stuck articulated tram?
15:42:32 <Brianetta> It's teleporting across its tile, then turning around
15:43:13 <Fennec> is their track on either end for it to go to?
15:43:24 <dih> Rubidium: i dont even use the gui, so i am not fussed :-P
15:43:41 *** Brainstorm has joined #openttd
15:45:01 <dih> Rubidium: i was merely making a point that there were such settings ;-)
15:47:27 <Belugas> may i make a point in specifying that it's not all server admin who want to type in commands in console? Lost of newbies are trying to be server admin, so i'd say do not ask them to all run under your style of management
15:48:01 <dih> Belugas: so you want to build a dedicated server gui?
15:48:31 <Yorick> doesn't such a thing already exist in the form of a nondedicated server gui?
15:48:54 <dih> a nice screen where you can chat, see all clients in their colors & companies, and have access to all options
15:48:58 <dih> without being in the game
15:49:52 <dih> who can consider runing a server without reading docs
15:50:00 <Yorick> dih: just for the newbies, there is a manual to the dedicated server
15:50:03 <dih> once they read the wiki pages, they are able to use console commands
15:50:49 <Yorick> list_patches currently overflows the console output ;)
15:51:05 <Belugas> [11:48] <Yorick> doesn't such a thing already exist in the form of a nondedicated server gui? <--- for once, i have to go with Yorick
15:51:30 <Yorick> there is a fs report of it somewhere
15:53:56 <Belugas> dih, you are too dedicated/console oriented to be a good judge
15:54:11 <Belugas> not saying that in an offensive way...
15:58:53 <dih> Belugas: yes - gui wise a draw back, but dedicated server wise a + :-P
16:01:08 <dih> but perhaps i can update the wiki pages to the console? that would be helpful to a bunch of newbies (if they ever read them)
16:02:12 <Belugas> "And Nothing Else matteuuuuurzzaa"
16:04:46 <Eddi|zuHause> # Das ist alles nur geklaut - eeh ooh eoh
16:04:59 <Eddi|zuHause> # Das ist alles gar nicht meine - eoh
16:05:33 <Eddi|zuHause> # Das ist alles nur geklaut, und gestohlen, nur gezogen und geraubt
16:05:42 <Eddi|zuHause> # Entschuldigung, das hab ich mir erlaubt
16:12:06 *** lobster_MB has joined #openttd
16:17:01 *** ChanServ sets mode: +o frosch123
16:17:24 *** ChanServ sets mode: +o SmatZ
16:24:39 *** lobster_MB has joined #openttd
16:26:49 <Bjarni> looks somewhat familiar :)
16:28:58 <Wolf01> I'm redesigning the brickland with mlcad
16:29:25 <Ammler> yay, we have a save which asserts everytime
16:29:41 <Yorick> yay, what have you done with it
16:31:50 <CIA-5> OpenTTD: belugas * r14040 /trunk/src/widget.cpp:
16:31:50 <CIA-5> OpenTTD: -Codechange:Remove a hard coded value that is not even representative,
16:31:50 <CIA-5> OpenTTD: since captions have their own encoded colours in string.
16:35:29 <peter1138> Yay, compatible/powered railtypes working :D
16:35:49 *** michi_cc has joined #openttd
16:35:49 *** ChanServ sets mode: +v michi_cc
16:38:15 <hylje> rails with actual attributes instead of arbitrary vehicle constraints?
16:38:17 <peter1138> Hmm, autoconvert seems messed up :(
16:38:26 <Yorick> another something with auto*
16:38:47 <Bjarni> <Ammler> dynamic tracks :-) <-- more like dynamic track gauge
16:39:38 <Bjarni> I have tried driving on that in real life
16:40:00 <Bjarni> the gauge is a curve is a little wider than the gauge in a strait track
16:40:54 <Bjarni> this is because certain locomotives (specially steam, but also 3 axle bogies) will make the gauge wider if it isn't already
16:41:52 <peter1138> Always getting stuck in tight places?
16:42:11 <Bjarni> locomotives that big don't get stuck
16:42:21 <Bjarni> they make room for themselves to move on
16:42:33 <Ammler> renamed the assertion save, because network_server won't be the same that long :-)
16:42:52 <Bjarni> too bad tight switches fails to turn after they passed
16:43:35 *** Wolf01 is now known as Wolf01|AWAY
16:43:42 <Bjarni> whereever I go... there is a Sacro
16:43:55 <Bjarni> #openttd and there he is
16:44:02 <Bjarni> tt-forums and there he is
16:44:04 <Eddi|zuHause> you obviously go to the wrong places :p
16:44:14 <Sacro> I want quite close to denmark
16:44:31 <Bjarni> but I don't want you quite close to Denmark
16:45:51 <Sacro> i wonder if those hungarians have dispatched my luggage yet
16:45:52 *** thgergo has joined #openttd
16:47:11 <Sacro> 3 hours in budapest and they lose it
16:47:51 <peter1138> Hah, RailConvertCost() is on crack...
16:48:30 <Prof_Frink> I want to close Denmark.
16:53:25 <Bjarni> Sacro: for your information: Budapest is nowhere near Denmark
16:54:17 <Sacro> my stepsister thought budapest was in vienna
16:54:41 <Bjarni> and you thought it was near Denmark
16:54:56 * Bjarni makes note not to hire a Sacro as navigator
16:55:19 <ln> Sacro: Bjarni claims he has never hear of a movie called "The Dark Knight".
16:55:55 <ln> what did you think it was?
16:56:18 <Bjarni> of that I have no idea
16:56:28 <Bjarni> might as well be your shoes
17:11:24 *** Wezz6400 has joined #openttd
17:12:00 <peter1138> RailConvertCost() can return zero, in which case nothing is converted :o
17:12:16 <Rubidium> serves them right ;)
17:13:05 <Rubidium> peter1138: though that reminds me of your spec; it misses cost of track
17:14:58 <peter1138> Even if the costs are the same, I should be able to convert :o
17:15:21 <Rubidium> though compatability between rail should determine the cost of conversion
17:15:44 <CIA-5> OpenTTD: glx * r14041 /trunk/src/ (console_cmds.cpp settings.cpp settings_func.h): -Feature(tte): make it possible to filter list_patches output like it's done for other list_* console commands
17:15:50 <hylje> moving a rail a few inches ~= building new monorail
17:15:59 <Rubidium> no compatability: cost of destruction + cost of construction, otherwise difference in the construction price (or something similar)
17:19:06 <Rubidium> peter1138: thought about how to handle the ground tiles for newroutes? Like ground from MP_CLEAR, the ballast and then the track itself?
17:20:56 <Rubidium> blathijs: new rail and road types implemented in an extendable manner
17:21:30 <Yorick> has one thought about the map array stuff?
17:21:55 <Rubidium> what map array stuff?
17:22:00 <Yorick> the current map array can hold about 3 road types
17:23:09 <Ammler> Yorick: but it has already 4
17:23:10 <Rubidium> or quite a bit more road types where only 2 can be on the same tile at the same moment
17:23:18 <blathijs> Hmm, "routes" doesn't sound like the perfect name, tbh. Is it something existing?
17:23:56 <Rubidium> blathijs: it's just the name of something similar that someone thought up long ago
17:24:49 <hylje> (just reading through Peterspec)
17:24:53 <frosch123> peter1138: just a note: drawing tracks as overlays would support different railtypes for horizontal/vertical track on the same tile (but don't ask about map space...)
17:26:05 <Yorick> frosch123: I don't think there is enouh map space for that
17:26:19 <Ammler> would it also allow double tracks in diagonal direction?
17:26:21 <Rubidium> Yorick: please stop thinking!
17:27:06 <Rubidium> then why do you write that you think?
17:27:11 <peter1138> frosch123, yup, although it's probably possible with magic half-sprites too ;)
17:27:16 <Yexo> Rubidium: just quote him correctly: 1) "I don't think" and 2) "there is enouh map space for that"
17:27:20 <hylje> peter1138: but.. magic..
17:27:32 <Yorick> Rubidium: Yorick> frosch123: I _don't_ think there is enouh map space for that
17:27:53 <peter1138> Easy, just add a couple of uint32s to the array :p
17:28:09 <Rubidium> peter1138: there's enough bits for that
17:28:15 <peter1138> 18:19 @Rubidium> peter1138: thought about how to handle the ground tiles for newroutes? Like ground from MP_CLEAR, the ballast and then the track itself?
17:28:52 <peter1138> Rubidium, indeed, with overlays, that is all possible. The question is whether we can cope with layering multiple sprites on everything...
17:28:59 <Rubidium> peter1138: just move m3 4-7 to m2
17:29:46 <Rubidium> peter1138: I'd say after newgrf load create those multiple layer sprites and cache them in memory or write them to a file or so
17:30:00 <frosch123> wasn't sprite sorting always the bottle neck? I.e. drawing tracks should not be slower than drawn towns
17:30:30 <Rubidium> frosch123: that's why I want to merge the sprites after the newgrf loading stage and use the merged sprites directly
17:31:02 <Belugas> mmh... so create one sprite out of all the layers just once
17:31:13 <Belugas> no need to repeat the same layering each time...
17:31:38 * Belugas wonders : could it already be done for other stuff?
17:32:06 <Rubidium> Belugas: yes, for the current junction sprites
17:32:09 <frosch123> ok, that would remove the need to always resolve the action123 chain, but would prevent adding varaction2 variables
17:32:34 <Rubidium> varaction2 is the root of all evil for performance
17:34:26 <Yorick> seems like notification is broken, but I added FS#2220 :)
17:37:04 <Rubidium> notification isn't implemented
17:37:10 <glx> Yorick: I already explained it to you yesterday
17:37:18 <peter1138> Rubidium... er... I'm not particularly interested in changing the map array...
17:38:04 <Yorick> glx: I know it's broken/unsupported in this version of flyspray, so I'm fulfilling the role myself now :)
17:38:17 <Rubidium> and most of the rest of the signal stuff is in m2
17:38:18 <peter1138> frosch123, i already only follow the action123 chain once.
17:41:27 <glx> rortom: shortcuts to change trucks?
17:42:01 <rortom> glx: using boost::python to expose the c++ classes of RoR
17:45:54 <dih> rortom, you have accumulated stats yet?
17:46:44 <Ammler> Yorick: of course, it shouldn.t :-)
17:47:42 <rortom> dih: not more than is currently online
17:48:49 <dih> rortom, can you make accumulated stats?
17:49:01 <dih> i am really really interested in them :-P
17:49:18 <rortom> yes, after im done with RoR 0.36 ;)
17:49:36 <Yorick> dih: excuse me, but could you explain?
17:49:52 <dih> rortom, cools - sounds great :-)
17:50:01 <dih> Yorick: rortom has stats of the servers
17:50:23 <dih> where are those stats again rortom ?
17:51:10 <peter1138> RoR really needs to be open source :o
17:51:58 <dih> rortom, you should really update your version of OpenTTDLib ;-)
17:52:45 <Ammler> hmm, those site has changed
17:53:34 <dih> Ammler, can the openttdcoop dev server be built from svn again,
17:53:40 <rortom> peter1138: we are working on that :)
17:53:44 <dih> h:d2c8248 as a version sucks
17:54:00 <Ammler> if you make me the patch :-)
17:54:29 <Ammler> or tell me, how I should do it :-)
17:54:51 <Ammler> I just pulled from celestar
17:55:18 <dih> and patch an svn checkout?
17:55:32 *** fmauNeko is now known as fmauNekAway
17:56:04 <Noldo> Ammler: change rev.cpp or give revision string as a ./configure argument
17:56:45 <Ammler> Noldo: I would need a patch to the last svn rev merged, else it doesn't make much sense, does it?
17:57:10 <Belugas> dih, because those guys like to work this way.
17:57:51 <dih> Belugas: pain only being getting people to join the game if it's hard to come by the patch
17:58:18 <dih> and there is hardly a good point in testing a network game if nobody can join
17:58:45 <Ammler> dih: hg is as easy as svn
18:01:22 <peter1138> What's the problem?
18:01:58 <peter1138> (the price of workers is 1 / 4 + price of copper sold to a recycle center)
18:02:03 <peter1138> What a silly comment :o
18:02:39 <peter1138> And the code is silly too.
18:07:19 <peter1138> calculate the price as 5 / 4 of (cost build el. rail) - (cost build rail)
18:08:51 <peter1138> Maybe I should just make it fall back to the default if it's 0...
18:13:04 <planetmaker> hm... is here someone around who can supply a svn diff for the current CargoDestinations?
18:13:12 *** welshdragon is now known as welshdra-gone
18:14:05 <planetmaker> or a diff which I could use with svn? <-- peter1138, Celestar ?
18:19:06 <peter1138> Just clone the repo... heh
18:19:07 <Yexo> planetmaker: you want a diff for cargodest?
18:19:27 <Ammler> Yexo: or a howto to make one...
18:19:47 <planetmaker> Yexo: yes... most people have svn and not hg - if we want many testers a svn diff is better :)
18:19:54 <Yexo> to make one: clone the repro, and do 'hg diff -r revision' where revision is the latest trunk revision you can find in the logs
18:20:19 <Yexo> where are you going to test it?
18:20:28 <planetmaker> on our dev server
18:20:55 <planetmaker> how current is that diff?
18:21:08 <Ammler> almost newest, I guess :-)
18:21:11 <Yexo> against 13040, just cloned :)
18:21:18 <Yexo> you can't get a newer one
18:21:32 <peter1138> Last trunk sync is r14000
18:22:11 <hylje> is development happening on hg with svn getting stuff pushed occassionally?
18:22:13 <Yexo> peter1138: as there were no conflicts, I merged it myself
18:28:19 <planetmaker> ah. bugger. But it doesn't compile :(
18:28:19 <planetmaker> ah. bugger. But it doesn't compile :(
18:29:37 <planetmaker> well... I hoped the svn diff could contain what I needed :)
18:31:05 <CIA-5> OpenTTD: belugas * r14042 /trunk/src/ (gfx.cpp table/palettes.h): -Codechange: Rename some structure members to more obvious names. And add a few comments on the _extra_palette_values array.
18:31:13 <planetmaker> hm... is it so far fetched? :S
18:33:19 <Belugas> i think it is, at this stage of the project, at least
18:34:57 *** Brianetta has joined #openttd
18:35:07 <Brianetta> My server keeps desyncing
18:35:42 <Rubidium> Brianetta: then make it reproducable and file a bugreport
18:36:58 <Rubidium> I can't really fix "my server keeps desyncing" when that's the only information
18:37:15 <Brianetta> I'm the only client. I'm not doing anything, and it's been desyncing others when they join. I was in for ages without desync; I think the server's in a state where desyncs are just a matter of time.
18:37:31 <Brianetta> If a core dump will help, I can connect gdb and save one.
18:37:51 <Brianetta> Trouble is, it doesn't desync immediately.
18:38:09 <Brianetta> But, it does desync.
18:38:47 *** lobster_MB has joined #openttd
18:39:15 <Brianetta> I suspect it's trams. I never used to have trams, and I never used to have these desyncs.
18:39:25 <Brianetta> I do know that the articulated trams have problems.
18:39:43 <peter1138> As long as they all have problems together... heh
18:39:43 <Brianetta> They can become stuck when you turn them around.
18:39:51 <Brianetta> No, they drift apart...
18:39:59 <peter1138> Used to be a array bounds problem with road vehicles overtaking a long time ago.
18:40:17 <Brianetta> Does "a long time ago" include 0.6.2?
18:40:42 <peter1138> Pre-0.4.5 I believe.
18:40:43 <Brianetta> You can seriously screw up a player's trams by funding road reconstruction.
18:40:59 <Brianetta> If they have articulated trams, many of them will never move again.
18:41:37 <Brianetta> Actually, I have two stuck trams in the game. If they're not stuck when I join, that could well be the difference between client and server,
18:43:30 <Brianetta> No, they're still stuck
18:43:37 <Brianetta> but playing with them got me this:
18:43:37 <Brianetta> dbg: [net] send failed with error 104
18:44:24 <Rubidium> 104 is connection reset by peer
18:44:29 *** Zealotus has joined #openttd
18:44:59 <Brianetta> There's definitely trouble with trams. Whether it's also the desync problem I don't know, but they cropped up on an otherwise stable server after trams were added.
18:51:11 <Brianetta> Rubidium: Would a core file help?
18:52:17 <Fennec> trams are awesome, yet trouble. :(
19:00:56 *** fmauNekAway is now known as fmauNeko
19:07:42 <Brianetta> Trams aren't awesome, though
19:07:53 <Brianetta> They're just road vehicles with a more restricted choice of road
19:09:41 <glx> <dih> glx: nice patch (r14041) <-- yes it was annoying to always get an incomplete list
19:16:15 * peter1138 wonders if the new rail type system should use overlays only...
19:19:58 <fonso> Is anyone still interested in diagonal leveling?
19:21:40 <fonso> I'm wondering if any of the versions I made satisfies the devs and if not, what I can do to improve it.
19:22:20 *** fonso is now known as fonsinchen
19:22:31 <fonsinchen> Even though you might call me impatient
19:22:34 *** fonsinchen is now known as fonso
19:28:51 <Ammler> Brianetta: autoreplace?
19:33:18 <Ammler> trains do now show reserved tracks on non-pbs blocks, is that intended?
19:34:30 <glx> why should it show unreserved tracks as reserved?
19:35:00 <peter1138> There was a PBS patch that didn't, but that is unrelated to YAPP.
19:51:21 <Belugas> trains can reserve tracks on non-pbs blocks?
19:52:24 <frosch123> now trains always reserve the tracks they are currently on
19:53:08 <frosch123> I guess that is related to some train crash bug reports, when someone messed around with signals/tracks while trains are driving inside the block...
19:59:30 *** LilDood has joined #openttd
20:12:18 <peter1138> Is it a problem? Not all is reserved, only that with a PBS signal near.
20:12:41 * peter1138 tests overlay-based rails
20:14:27 <peter1138> Only difference so far is that X crossing look different.
20:14:34 <peter1138> Oh, and I have no ballast :D
20:16:07 <peter1138> Bah, y-offset issues :(
20:17:24 *** lobster_MB has joined #openttd
20:24:47 <Ammler> peter1138: current cargo dest does desync a lot...
20:26:57 <Roujin> Ammler: you sure all clients are using the same build?
20:27:23 <Roujin> happened to me that I got the new revision, but not the changes, that can happen oO
20:27:27 <Ammler> we use all the patch from yexo
20:28:06 <Roujin> ah.. then never mind what I said..
20:28:16 <Ammler> but it did also desync with the hg repo
20:29:00 <Roujin> with the hg repo, you mustn't forget to do "hg update" after pulling, or else you'll have the new revision but not the changes
20:29:53 <Ammler> Roujin: you mean the client shows the new rev also if you don't apply them?
20:29:56 <Roujin> you running a test right now on the openttdcoop server?
20:30:14 <Ammler> yep, at #openttdcoop.dev
20:31:22 <Roujin> yes, that can happen with hg. when you pull, the revision is updated, but not the actual code. for that you have to do "hg update" then.
20:32:21 <Roujin> I didn't know/forgot to "hg update", and connected to a test game with the newer revision without problems (revision was the same) - but of course desynched pretty fast
20:34:52 <Brianetta> Rubidium: I reloaded the game on the server, and it's desyncing again. Will the saved game be helpful?
20:40:02 *** lobster_MB has joined #openttd
20:40:25 <Eddi|zuHause> <Rubidium> no compatability: cost of destruction + cost of construction, otherwise difference in the construction price (or something similar) <- there are problems with that interpretation, e.g. 3rd rail to catenary, they are not directly compatible, but they have a common "base" [conventional rail]. maybe grfs could specify an upgrade relation similar to the compatibility relation, and specify costs along this relation. then the
20:40:26 <Eddi|zuHause> conversion tool must figure out what is the "cheapest path" through that relation [there is always a path between two railtypes via the "no rail" type (build cost)]. so people could specify cost from normal rail to 3rd rail, and from normal rail to electrified, and the conversion tool would then add the conversion prices. newgrf people could also specify costs from normal rail to narrow gauge rail, where no regular compatibility exist,
20:40:28 <Eddi|zuHause> but not the full cost of a new rail applies. additionally they could specify conversion from electrified rail to electrified narrow gauge rail, where there would be no need to remove the electrification, regauge the rail, add new electrification.
20:43:27 <Eddi|zuHause> hm... that line was longer than i expected...
20:43:32 *** Osai is now known as Osai^zZz
20:46:50 <Eddi|zuHause> costs needn't be symmetric either... it's cheaper to remove catenary than to add it [you can even sell the copper]
20:47:50 *** Guest1211 is now known as SmatZ
20:49:14 <Brianetta> Selling train tracks gets you money
20:49:22 <Brianetta> Selling tram tracks gets you skint
20:50:16 <Eddi|zuHause> removing tram tracks from a road will almost always mean rebuilding the road ;)
20:51:54 <Eddi|zuHause> here, some roads still have embedded tram tracks even though the tram line was closed 50 years ago
20:59:23 <peter1138> I need some method of picking foundations.
21:07:05 <CIA-5> OpenTTD: truebrain * r14044 /branches/noai/ (7 files in 2 dirs): [NoAI] -Change [API CHANGE]: generalize AIEngine::IsBigPlane() to AIEngine::GetPlaneType (Yexo)
21:13:22 *** stillunknown has joined #openttd
21:17:27 *** Sacro_ is now known as Sacro
21:20:40 <Sacro> Right, why does OpenTTD take an aaaaaaaaaaaaaaaaage to connect to online servers?
21:22:04 <Fennec> your networks are slows
21:24:10 <Sacro> fine for everything else
21:25:43 *** fmauNeko is now known as fmauNekAway
21:25:55 <Prof_Frink> Sacro: KCOM.COM haet the openttd.
21:26:05 <Sacro> Prof_Frink: KCOM.COM sucks major arse
21:27:27 <Sacro> "Jenna Bush's Federally Protected Wetlands Now Open for Public Drilling"
21:28:20 <Eddi|zuHause> Honi soit qui mal y pense
21:29:33 <Ammler> Sacro: not your connection is slow, the servers connection might be...
21:29:44 <Sacro> Ammler: seems to be with every server
21:30:10 <Ammler> which rev do you have?
21:30:39 <Ammler> aren't you admin there?
21:32:40 <Sacro> yes, it is Brian's server
21:33:09 <Ammler> and you think that one is slow?
21:47:28 *** LilDood has joined #openttd
21:59:37 *** Sacro_ is now known as Sacro
22:07:40 <CIA-5> OpenTTD: rubidium * r14045 /trunk/src/network/ (5 files in 2 dirs): -Codechange: move the network's limitation to chat messages to a more logical location and give it a more consistent name.
22:08:37 <Eddi|zuHause> missing "... and set it to a more reasonable value" :p
22:09:10 <CIA-5> OpenTTD: rubidium * r14046 /trunk/src/ (6 files in 2 dirs): -Codechange: make the size of querystring "widgets" more configurable.
22:09:12 <Rubidium> Eddi|zuHause: 1000 is a reasonable value, isn't it?
22:10:47 <Eddi|zuHause> no, studies have shown that people rarely put more than one word on a line, so 10 is really enough ;)
22:11:25 <Yexo> whyisonewordnotenoughanyway?
22:11:57 <KurtKraut> Eita... Gmail t down (erro 502)
22:14:13 <Rubidium> Yexo: you should consider changing your nick ;)
22:14:35 <Rubidium> I almost put you on my ignore list
22:14:48 <Eddi|zuHause> to one that does not start with a Y? ;)
22:15:12 <Eddi|zuHause> i occasionally thought the same thing ;)
22:21:28 *** fmauNekAway is now known as fmauNeko
22:31:31 *** Wolf01|AWAY is now known as Wolf01
22:32:18 <ln> it's also possible to just quit from the away state.
22:45:24 <CIA-5> OpenTTD: rubidium * r14047 /trunk/ (17 files in 6 dirs): -Codechange: move chatmessage handling to the network directory as that's the only case chat messages are used. Furthermore remove any trace of chatmessages when compiling without network support.
23:00:55 *** lobster_MB has joined #openttd
continue to next day ⏵
