IRC logs for #openttd on OFTC at 2009-10-16
⏴ go to previous day
00:35:11 *** Rubix`` has joined #openttd
00:37:52 *** sawtooth has joined #openttd
00:50:33 *** KenjiE20|LT has joined #openttd
00:52:14 *** ccfreak2k has joined #openttd
00:55:01 *** Belugas has joined #openttd
00:55:47 *** ChanServ sets mode: +o Belugas
00:57:07 *** De_Ghosty has joined #openttd
01:00:50 *** th1ngwath has joined #openttd
01:06:20 *** Dred_furst has joined #openttd
01:10:00 *** TrainzStoffe has joined #openttd
01:17:12 *** TrainzStoffe is now known as Stoffe
02:16:24 *** TrainzStoffe has joined #openttd
02:25:01 *** nicfer2 has joined #openttd
02:28:52 *** Rubix`` has joined #openttd
02:29:59 *** TrainzStoffe has joined #openttd
02:38:33 *** DaleStan is now known as Guest1327
02:38:33 *** DaleStan has joined #openttd
03:15:36 *** TrainzStoffe has joined #openttd
03:23:09 *** TrainzStoffe is now known as Stoffe
04:20:10 *** thepalm has joined #openttd
04:46:35 *** TrainzStoffe has joined #openttd
04:52:04 *** TrainzStoffe is now known as Stoffe
05:01:55 <Rhamphoryncus> umm wow... presignals are stupidly simple once you realize how to use them, and how *little* you need
05:08:42 <Rhamphoryncus> You don't put a signal at the start of a block. You only put one at the end, and the start happens automagically
05:12:49 <Rhamphoryncus> and it's quite easy to crash them while messing with the layout..
05:15:10 <Rhamphoryncus> Huh. Won't go backwards through a signal to a depot
05:43:41 *** Polygon has joined #openttd
05:48:35 <planetmaker> Rhamphoryncus: it's usually a good idea to use an entry-signal with pre-signals
05:54:03 <Rhamphoryncus> planetmaker: path signals seem to be as good in some cases, better in others
05:54:32 <Rhamphoryncus> It seems that the presence of a path signal magically make a station have a hidden path signal too. It does not do it to depots though
05:56:27 <Rhamphoryncus> heh, I can put a dummy path signal off to the side, then force a train past a normal signal, and it'll use pathing to avoid collisions
06:01:39 <Rhamphoryncus> Well, they'll try to. If they can't find a path they'll continue forward, since you just told them to ignore the stopping point
06:04:05 <Rhamphoryncus> Huh. My depots are pathing now. Dunno why they choked before
06:08:17 <planetmaker> [07:54] <Rhamphoryncus> Probably a bug <-- most probable not ;-) but insufficient understanding
06:08:26 <planetmaker> especially of how they work, if you mix signal types
06:09:09 <planetmaker> and moin Yexo :-)
06:09:19 <Rhamphoryncus> Further info: it seems trains will go backwards through one path signal, but not two. I don't know if that's a hard limit or a side effect of pathing cost
06:09:21 <planetmaker> and everybody else, too :-)
06:09:51 <planetmaker> Rhamphoryncus: yes, it probably is. They have comparably huge penalties
06:11:45 <planetmaker> e.g. you can nicely use them to set preferential routes for trains, so that e.g. the furthest station track is taken first by trains
06:11:46 <Rhamphoryncus> So when the path itself is quite large it could conceivably do 2 or more.. but it's still unlikely to skip ALLLLL the way down a two-way route
06:12:03 <planetmaker> them = backward path signals
06:13:26 <planetmaker> though making level crossings (using roads) is just as fine and might even work better in some of those cases
06:15:54 * Rhamphoryncus tries a 3 track system
06:19:33 *** Cybertinus has joined #openttd
06:35:51 <Rhamphoryncus> hrm. Still times when a train doesn't move, but there's a path available
06:36:38 <Rhamphoryncus> playing with a 4 track system now btw
06:41:01 <Rhamphoryncus> Outer lanes are one-way to avoid deadlock. Inner were two-way (plain pathing, but different at either end). Now I'm experimenting with just plain paths for the inner though
06:47:53 <Rhamphoryncus> heh, apparently giving back access to the station eliminates the stopping point
06:48:53 <Rhamphoryncus> and confuses the hell out of the train.. it still wants that slot, but it can't stop there until the entire block is cleared
06:49:28 *** andythenorth has joined #openttd
07:29:21 <planetmaker> morning andythenorth
07:32:02 *** boekabart has joined #openttd
08:09:29 *** Progman has joined #openttd
08:42:44 *** Chris_Booth has joined #openttd
09:05:28 *** andythenorth has joined #openttd
09:20:05 *** andythenorth has joined #openttd
09:32:49 * Rubidium wonders how often people update their working copies/nightlies
09:33:14 <andythenorth> when there's something interesting to test?
09:33:46 * andythenorth wonders what I've done wrong this time...
09:34:21 *** TheMask96 has joined #openttd
09:34:29 <boekabart> Rubidium: no way to check svn up stats, nightly download stats
09:35:09 <Rubidium> boekabart: was more a rethorical question
09:35:54 <Rubidium> andythenorth: a former teacher would say the compiler doesn't understand the last bit because it's not commented
09:36:09 <boekabart> it wasn't a question even, just a wondering :)
09:36:25 <andythenorth> Rubidium: good point
09:36:26 <Rubidium> nightly download stats yes, svn up stats no
09:36:34 <andythenorth> it is just a bunch of action 3s for industry tiles
09:36:54 <Rubidium> besides that... svn up stats don't tell how often (per working copy) an update is done
09:37:07 <Rubidium> only how often in total (or maybe per IP) an update is done
09:37:17 <boekabart> I meant per ip-ish, yes
09:38:03 <Rubidium> we don't gather download/ip stats
09:38:42 <andythenorth> Rubidium: I've added a few comments
09:39:30 *** fonsinchen has joined #openttd
10:06:21 *** Yexo is now known as Guest1353
10:06:53 *** Belugas has joined #openttd
10:06:53 *** ChanServ sets mode: +o Belugas
10:13:12 *** Chris_Booth is now known as Guest1355
10:13:14 *** Chris_Booth has joined #openttd
10:13:49 *** TrainzStoffe has joined #openttd
10:15:03 *** insulfrog has joined #openttd
10:21:19 *** TrainzStoffe is now known as Stoffe
10:24:14 *** Seberoth has joined #openttd
10:29:12 *** boekabart has joined #openttd
10:30:06 <andythenorth> I think my stockpiling code is one step closer to working
10:32:13 *** b_jonas has joined #openttd
10:53:44 <andythenorth> stockpiling produces *lot* of acceptance change news flashes
10:55:19 <b_jonas> I never read acceptance change news flashes
10:56:13 <andythenorth> I'd like to suppress them
10:56:13 *** tux_mark_5 has joined #openttd
10:56:19 <andythenorth> but I guess that's up to the player
10:59:06 <andythenorth> Rubidium: if the production callback is called very 256 ticks, how many times is that per month (assume 30 days)
10:59:17 *** ChanServ sets mode: +v tokai
11:00:21 <andythenorth> so about 8.7 times in a 30 day montb
11:02:35 <andythenorth> and now I've found my mistake :)
11:03:51 <boekabart> Devs; would it be an idea to add to the VC80/90 vcproj the following:
11:04:29 <boekabart> AdditionalLibraryDirectories="$(OPENTTD_USEFUL)\win32\library"
11:04:45 <boekabart> (and similar for AdditionalIncludeDirectories)
11:05:24 <boekabart> this way, everyone can put them anywhere they want; no-one NEEDS to include them in the VC default include dirs (because sometimes that's not good for other projects)
11:05:57 <boekabart> it doesn't break current 'deployments'.
11:06:20 <Rubidium> well, you better talk to the window devs
11:06:36 <boekabart> who's that this day and age?
11:06:36 <TrueBrain> and glx is not here yet ;)
11:08:31 <b_jonas> openttd is not limited to 256 depots like ttd, is it?
11:09:14 <Yexo> boekabart: I think you can also add the include directory to the project settings, that way you don't have to include themin the default include dirs either
11:09:19 <b_jonas> okay, one more reason to try it after I've played enough with ttdpatch
11:27:41 *** Terkhen has joined #openttd
11:30:43 <boekabart> Yexo: yes, but that way you always have a "M" project file, annoying when making patches
11:31:29 <Yexo> boekabart: sorry, I don't have enough time to look at it now
11:31:46 <Yexo> maybe glx can help you and otherwise I'll have a look sunday/monday
11:31:53 <boekabart> that's exactly what this patch does: add it to the project settings, but as an env. variable. Nothing breaks if it's empty; and it can work for everyone
11:32:55 <Yexo> I see, but I have to leave in 10 minutes so I can't test it now
11:43:49 *** |Terkhen| has joined #openttd
12:02:38 <andythenorth> How's this for explanatory industry text?
12:02:39 <andythenorth> This industry will try and use Engineering Supplies to increase production. Keep the stockpile above 0t for a chance of a production increase each month. Stockpile max limit: 200t
12:17:38 <b_jonas> what's the limit in ttd for the number of stations an industry delivers to?
12:19:58 <b_jonas> and how do they choose? highest rating?
12:20:17 <b_jonas> so that's why my train doesn't work
12:21:00 *** TrainzStoffe has joined #openttd
12:27:44 *** TrainzStoffe is now known as Stoffe
12:33:02 <Eddi|zuHause> did "they" tell you about Bielefeld, too?
12:33:48 <boekabart> Yes, about the Teutoburg Forest
12:34:37 <Eddi|zuHause> that means "they" trapped you in their Bielefeld Conspiracy!
12:35:20 <boekabart> hehe. I love that trillian pops up wikipedia explanations for stuff like that :)
12:35:21 <glx> boekabart: I'm used to the global setting, but why not :)
12:35:45 <boekabart> global setting: it conflicts with other stuff (for work) ...
12:36:03 <boekabart> and it's impractical to work as a different user for ottd
12:45:51 *** tux_mark_5 has joined #openttd
12:51:09 *** Seberoth has joined #openttd
12:58:02 <b_jonas> argh... I just built a great train network and my trains won't go in the right direction
13:02:04 *** andythenorth has joined #openttd
13:06:25 <Rubidium> boekabart: the M for projects comes from differences in '/src/', not from '/'
13:06:42 <Eddi|zuHause> b_jonas: check for ill placed signals or missing catenary
13:07:22 <boekabart> you mean, I could ignore all changes in projects and just make patches for src\ ?
13:07:32 <boekabart> true but still a hackish hack
13:07:50 <Rubidium> oh, M there... though you were talking about the M in the version
13:08:18 <boekabart> smart, btw, to make that src/ only
13:09:09 <Rubidium> nevertheless, svn diff src/ makes a -p0 diff for '/' without changes in e.g. the project files
13:09:20 <Rubidium> (or at least my svn diff does)
13:11:17 *** ChanServ sets mode: +v tokai
13:12:45 <b_jonas> I have a track where the train can turn back and it turns back despite that the station is forward
13:12:55 <b_jonas> but if I remove that turn back track the train works well
13:13:58 <Rubidium> well, usually it 'just' means it can't go the other way so it's forced to go a way even when it'll eventually deadlock itself somewhere else
13:14:32 <glx> weird I have linking errors with icu
13:14:33 <boekabart> Rubidium: true, it does, it would just be nicer if one could work without this kind of local changes in his WC
13:14:43 <boekabart> that's why severity is just Low
13:14:51 <glx> it used to work with my current setup
13:15:33 <Rubidium> ooh... glx is the second (or third if you count me) to notice
13:15:46 <Rubidium> after almost 2 days and 7 hours
13:16:08 <boekabart> libicu.lib(udata.obj) : error LNK2001: unresolved external symbol __imp__icudt42_dat
13:16:34 <Rubidium> the solution is simple... if you know where to 'look'
13:17:10 * glx knows there's a new version
13:17:47 <boekabart> wiki needs updating, still says 2.3
13:18:05 <Rubidium> wiki shouldn't mention versions; it's always out-of-date that way
13:19:04 <Rubidium> *especially* when a moron comes along and changes august 2007 into something else for the DirectX SDK
13:20:21 *** TrainzStoffe has joined #openttd
13:20:25 <Rubidium> or a moron on wikipedia that changes 'openttd is written in C++ since 0.6.0' into 'openttd is written in C++ since 0.7.2' or so
13:20:39 <Rubidium> b_jonas: then help us helping you...
13:21:03 <b_jonas> should I post ttdpatch savegames or screenshots with descriptions?
13:21:28 <b_jonas> maybe I should leave larger gaps between the signals after and before the turnback
13:21:32 <glx> or use an overcomplicated method to install DXSDK, like install latest and extract dmusic stuff from august 2007
13:21:49 <Rubidium> then it's just the PF only looking a relatively small number of tiles
13:21:50 <b_jonas> but it fails even with no other trains close so I don't think that would help
13:21:59 <Rubidium> you need to add waypoints etc. to route trains properly there
13:22:11 <glx> yeah linking works now :)
13:22:18 <b_jonas> Rubidium: doesn't it look at the general direction where the destination station is?
13:23:26 *** De_Ghosty has joined #openttd
13:23:48 <b_jonas> anyway, waypoints might be a good idea
13:24:23 <b_jonas> I'll try adding two waypoints forward and two backwards
13:24:26 <Rubidium> b_jonas: don't know specifics, but probably going back went closer to the destination quicker or so
13:24:40 *** TrainzStoffe is now known as Stoffe
13:25:36 <glx> boekabart: ok your patch doesn't break my setup :)
13:26:20 <glx> but it adds a warning, The following environment variables were not found: $(OTTD_USEFUL)
13:27:56 <b_jonas> or maybe I just shouldn't have the turnback at the middle of the route
13:28:14 <b_jonas> the two turnbacks near the ends are needed in case all station platforms are full
13:29:41 <b_jonas> can I use presignals for a station where trains enter and leave on the same side?
13:30:23 <b_jonas> this example shows how
13:30:29 *** KenjiE20 has joined #openttd
13:35:53 <boekabart> glx: yes, can we translate that warning somehow?
13:36:02 <boekabart> (not that I know of)
13:36:28 <glx> well the warning is valid and harmless
13:36:40 <glx> but I don't like warnings
13:37:15 <boekabart> are you pondering what i'm pondering?
13:38:52 <boekabart> Uh, I think so Brain, but this time, you wear the tutu.
13:39:42 * glx checks if it's a problem if "treat warnings as errors" is enabled
13:39:57 <boekabart> Is that default for release?
13:40:46 <boekabart> we can always add it to ignored warnings
13:40:55 <boekabart> *ugh* quick and dirty *uugh*
13:41:15 <glx> there's no warning code for this one :)
13:41:18 <Rubidium> can you? Or is that some project setting too? I only know the stuff in stdafx.h
13:44:12 * boekabart is trying the 'existing deployments don't break' scenario too
13:45:12 <boekabart> indeed, so the question is, is it a 'treat warnings as errors' warning
13:45:37 <Rubidium> luckily the compile farm doesn't bother about MSVC warnings *or* failures/errors (it doesn't notify us)
13:47:31 <Rubidium> MSVC is very good in a) delivering (some) binaries on failure and doesn't know stderr
13:48:02 <Rubidium> which is why the link failure took 2 days before someone notified us
13:48:26 <Rubidium> although I'm still wondering why it failed to link
13:48:39 <boekabart> supposedly, vs 10 will solve all this for us
13:49:25 *** Dred_furst has joined #openttd
13:50:34 <glx> ok the warning doesn't prevent compilation when warnings are treated as errors
13:50:39 <Rubidium> supposedly windows vista has/was going to have winfs
13:52:54 <Rubidium> let me say: don't install it on a working system, but run it in something virtualised
13:53:08 <Rubidium> uninstalling it breaks MSVC2005/2008
13:55:13 <Rubidium> and upgrading the project files doesn't work (at least in beta1)
13:55:53 <Sacro> Rubidium: longhorn was, vista wasn't
13:56:37 <boekabart> Sacro: nice spin...
13:56:53 <Rubidium> Sacro: Vista's original codename, "Longhorn"
13:57:52 <Rubidium> but heh, they're only working on structured storage for like... 20 years
13:58:08 <glx> so should we commit FS#3269 or not?
13:59:44 <Rubidium> depends on how often *you* want to tell people it isn't harmful and it should be ignored and that adding it + ignoring the warning is better than not adding it
14:00:43 <glx> well even with this warning the result is 3>openttd - 0 erreur(s), 0 avertissement(s)
14:01:37 <boekabart> it's not a warning in the IDE warning-list
14:02:24 <Rubidium> does it end up in stderr in MSVC2010?
14:02:39 <boekabart> no way to know until it's released
14:03:16 <boekabart> but msvc2010 has completely different project files so ... not yet relevant anyway.
14:10:18 <boekabart> Project : warning PRJ0018 : The following environment variables were not found:
14:10:23 <boekabart> sounds like it's ignorable
14:10:57 <Rubidium> boekabart: only for a small percentage of 'users'
14:11:43 <Rubidium> most people will read it as "the error" for their failure to patch
14:11:47 *** insulfrog has joined #openttd
14:13:16 * insulfrog is playing an openttd game
14:13:20 <boekabart> I mean, ignorable somehow
14:13:26 <boekabart> but it seems not to be
14:13:36 <boekabart> and it _does_ show in build warning list
14:14:36 <Rubidium> anyhow, the idea of the patch is good... just that it adds a pointless warning isn't :(
14:15:32 <boekabart> a pre-build "set OTTD_USEFUL=%OTTD_USEFUL%" doesn't help
14:19:04 * boekabart has to go pick up a little girl from the daycare
14:19:11 *** boekabart has left #openttd
14:21:54 *** lobster has joined #openttd
14:25:20 *** Coco-Banana-Man has joined #openttd
14:27:20 *** Coco-Banana-Man has quit IRC
14:27:32 *** Coco-Banana-Man has joined #openttd
14:35:34 *** TrainzStoffe has joined #openttd
14:41:21 *** andythenorth has joined #openttd
14:43:05 *** TrainzStoffe is now known as Stoffe
14:48:26 *** |Jeroen| has joined #openttd
14:57:39 *** |Jeroen| has joined #openttd
15:05:19 <andythenorth> Got production boosting and stockpiling working
15:05:25 <andythenorth> might have some dodgy code though
15:09:38 <andythenorth> For my next trick I have to learn to use the text reference stack in conjunction with cb 3A
15:09:51 <andythenorth> or I end up with a bazillion strings for each industry
15:48:29 <DorpsGek> Muxy: luukland was last seen in #openttd 1 day, 22 hours, 19 minutes, and 1 second ago: <Luukland> Muxy? Goulp?
15:53:36 <Eddi|zuHause> the joy of people always missing each other ;)
15:55:16 *** oskari89 has joined #openttd
15:57:35 <MyCatVerbs> Sex on a DOOR but OpenTTD builds fast.
15:57:46 <MyCatVerbs> 2 minutes 14 seconds on my laptop from scratch. ^^
16:03:09 *** Rhamphoryncus has joined #openttd
16:27:22 *** hickop_ has joined #openttd
16:33:13 *** welshdragon has joined #openttd
16:38:25 *** Grelouk has joined #openttd
16:43:13 *** ProfFrink has joined #openttd
16:48:33 *** ProfFrink is now known as Prof_Frink
16:54:39 *** Brianetta has joined #openttd
16:55:04 *** fonsinchen has joined #openttd
17:07:45 *** Alberth has joined #openttd
17:13:36 *** Dred_furst` has joined #openttd
17:14:26 *** TheMask96 has joined #openttd
17:16:07 <Pikka> what fun this business of fake-reversing trains is :D
17:16:16 <Pikka> especially when you have to deal with vehicles of differing lengths
17:17:15 *** _ccfreak2k has joined #openttd
17:19:09 *** Dred_furst has joined #openttd
17:19:09 *** sawtooth has joined #openttd
17:19:09 *** TrueBrain has joined #openttd
17:19:09 *** Rexxars has joined #openttd
17:19:09 *** mikegrb has joined #openttd
17:20:39 *** Phoenix_the_II has quit IRC
17:33:48 <Belugas> [13:16] <Pikka> what fun this business of fake-reversing trains is :D <--- try payment processing and customer requirements, now that is a hell lot more funny business..
17:38:58 *** StarLionIsaac has joined #openttd
17:42:20 <andythenorth> if you think that's fun, try writing nice text for industry windows
17:43:04 <Eddi|zuHause> i'd rather work on real reversing instead of fake reversing...
17:44:36 *** thingwath has joined #openttd
17:45:26 <CIA-4> OpenTTD: translators * r17779 /trunk/src/lang/ (3 files in 2 dirs):
17:45:26 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
17:45:26 <CIA-4> OpenTTD: basque - 5 changes by Thadah
17:45:26 <CIA-4> OpenTTD: hungarian - 1 changes by Petert
17:45:26 <CIA-4> OpenTTD: vietnamese - 31 changes by nglekhoi
17:49:53 *** duckedtapedemon has quit IRC
17:50:35 <andythenorth> I trust you guys more than I trust the forum bunnies
17:50:45 <andythenorth> I need just enough text to explain things
17:50:54 <andythenorth> And not so much that it looks complex
17:50:54 *** Brianetta is now known as Brianetta_changing_seats
17:51:22 *** Brianetta has joined #openttd
17:51:39 *** Brianetta_changing_seats has quit IRC
17:52:13 *** frosch123 has joined #openttd
17:53:23 <Albert> since when can we stretch that window? D:
17:53:25 *** Albert is now known as Pikka
17:55:07 <Pikka> I mean, the text part. or does it automatically expand for longer text?
17:56:12 <andythenorth> Pikka: it just expands to fit my text?
17:56:17 <andythenorth> I'm running recent nightly
17:56:23 <Eddi|zuHause> whoa... i just thought Alberth was asking that question...
17:56:25 <Pikka> I'd leave out the * part :P or say something like "Engineering supplies improve the chances of a production increase"
17:56:49 <Belugas> bunnies, funnies, newbies, stewpids
17:57:44 <Rubidium> multithreaded/multiprocess stew making?
17:58:59 <Alberth> Eddi|zuHause: I wish ;)
17:59:00 <andythenorth> Pikka: are you preferring the "don't tell the player everything" model of help text?
18:00:41 <Pikka> I think it's a fine line, andy
18:01:16 <andythenorth> There's no game if you don't have to work it out :)
18:01:20 <Pikka> you don't really need to explain /everything/ in game, but on the other hand you don't want to be george
18:01:52 <Alberth> you can also publish such info in the download or at your site
18:02:17 <andythenorth> If I bit the bullet and learnt to use registers, I could worry less about explaining things to the player...
18:02:44 <andythenorth> The current problem is they will only get a chance of an increase if cargo is waiting *at the end of the month*
18:03:38 <Pikka> you also don't necessarily have to explain the precise mechanics of how it works, as long as players get the gist :P
18:03:51 <andythenorth> I've simplified the text to your suggestion, it works fine
18:03:59 <Rubidium> but... isn't it "better" to just show a string of meaningless numbers? :)
18:04:10 <andythenorth> I can do that too
18:04:18 *** Luukland has joined #openttd
18:04:33 <Pikka> Rubidium: Prod: (15, 21, 0, 0, 0, 0), says the ECS glassworks!
18:04:38 <Alberth> stopping accepting will soon get noticed by the players, not sure you need to spend 2 lines text on that
18:04:52 <Rubidium> would be fun to mix octal, decimal and hexadecimal in those strings
18:05:00 <andythenorth> Engineering Supplies limit: 200 crates?
18:05:18 <andythenorth> Engineering Supplies limit: 200 crates *not currently accepting*
18:05:39 <andythenorth> "Cargo Waiting to be Processed" isn't under my control :(
18:05:53 <frosch123> Alberth:stopping accepting will soon get noticed by the players, not sure you need to spend 2 lines text on that <- if the lines say "THIS IS INTENTIONAL, DON'T COMPLAIN ABOUT THIS", they are fine
18:05:54 <andythenorth> Otherwise I could just stick (Max 200) on the end
18:06:51 <Alberth> would be enought for me :)
18:08:40 <Pikka> andy, you could do it like TaI, have a line which says no supplies / how fast the supplies are being consumed / stockpile limit looming :)
18:09:30 *** Chris_Booth has joined #openttd
18:10:19 <StarLionIsaac> TaI defines industries too? I thought it was just a town building set
18:10:55 <frosch123> you should explore more about the meaning of "TaI"
18:11:01 <frosch123> especially the "I" part :p
18:11:16 <StarLionIsaac> I do know that, I just never noticed any changes to industries before
18:11:26 <StarLionIsaac> that might have something to do with the fact I usually play with all the ECS vectors loaded though
18:11:31 <Pikka> TaI is more than one grf
18:11:43 <Pikka> and only the houses have been released :P
18:11:52 *** Luukland has joined #openttd
18:12:02 <Luukland> ladies, may I ask why max companies is set to 15?
18:12:16 <StarLionIsaac> that would explain it
18:12:52 *** Grelouk_ has joined #openttd
18:13:57 <Belugas> to what number you would like to have them, Luukland?
18:14:19 <Luukland> Or 18 will also suffice
18:14:20 <Eddi|zuHause> Pikka: the problem i noticed with PBI was, that as long as it says "near stockpile limit", i have no information anymore about the speed of processing
18:14:39 <Belugas> 1) problems with the colours
18:14:57 <Belugas> 2) problems with comapnies references in the code -> bitmap values -> 16 bits
18:15:13 <Belugas> 3) lots of savegames bumps to handle
18:15:15 <frosch123> Luukland: because there are 4 bits for storing the owner of certain tiles, and 1 is needed for town owner/no owner
18:15:44 <Luukland> dang, so raising it would cost a lot of work or can't be done completely?
18:15:45 <Belugas> and what frosch123 said, indeed
18:16:13 <Belugas> people will NEVER be satisfied, no matter what is given
18:16:24 <Luukland> If you give a finger
18:16:26 <Belugas> hey guys, why not 32?
18:16:28 <Luukland> we will take the hand :p
18:16:41 <andythenorth> Pikka: if I get extra friendly with the text stack, I might do it like TaI
18:16:52 <andythenorth> probably a future enhancement though :D
18:17:17 <Rubidium> Belugas: infinite ofcourse...
18:17:27 <Rubidium> it shouldn't even be limited by memory
18:17:43 <Luukland> Or what a fiberglass bandwith can handle :p
18:17:52 <Luukland> 100mbit 1,2kb/s a client :p
18:17:58 <Luukland> So thats around 800 clients xD
18:18:04 <Pikka> plz to make 1048576*1048576 maps too
18:18:41 <sawtooth> hmm...i wonder why the recent trunk releases eat up 100% of my cpu
18:18:57 <Luukland> Anyways, thx for the answer, pls next time hold the sarcasm Belugas, dont be such an ass to ppl who just ask normal questions
18:19:04 <andythenorth> no more work for me today
18:19:08 <andythenorth> except the nfo kind
18:19:25 <frosch123> sawtooth: what is recent? since r17776?
18:19:27 <Belugas> ? sarcasm? me? ho no not at all...
18:19:37 <sawtooth> frosch123: i think even a bit before that
18:19:54 <frosch123> since you added lots of noais in game?
18:20:07 <sawtooth> using none. cpu is even pegged at the main menu
18:20:10 <frosch123> since you play on a 2k x 2k map?
18:20:32 <Rubidium> sawtooth: is the music running?
18:20:46 <StarLionIsaac> linux might explain it there - it always runs at near to 100% on any Ubuntu box I've run OTTD on
18:20:58 <sawtooth> 0.7.3 doesn't hog cpu for me
18:21:26 <StarLionIsaac> I wouldn't know about that, I only run the nightlies
18:22:16 <frosch123> main menu uses 10% on my 5 years old machine
18:22:23 <sawtooth> i did remove all the newgrf's and reset to default settings. window/fulscreen doesn't make a difference either
18:22:46 <sawtooth> wonder if i should try with sfx off
18:22:59 <frosch123> (though i never know what 10% means with HT)
18:23:03 <Rubidium> sawtooth: can you find since which revision it became much slower?
18:23:30 <Rubidium> frosch123: usually 10% of one 'core', i.e. I've had > 100% some times
18:24:05 <sawtooth> Rubidium: i could try...might take a while though :)
18:24:13 <Rubidium> what video backend are you using?
18:24:30 <sawtooth> where is that setting at?
18:24:57 <Rubidium> it autodetects it; run with -d driver=1
18:28:07 *** TrainzStoffe has joined #openttd
18:28:08 <Rubidium> hmm, then I don't have a clue
18:28:11 <StarLionIsaac> out of curiosity, is there any significant difference to using allegro?
18:28:16 <Rubidium> good luck bisecting then
18:29:28 <sawtooth> cpu at main menu in 0.7.3 is 6-11% or so
18:29:41 <sawtooth> i guess i'll have to test a bunch of revisions then
18:31:02 <Rubidium> sawtooth: bisecting is usually the best approach
18:31:28 *** TrainzStoffe is now known as Stoffe
18:34:48 <Rubidium> StarLionIsaac: allegro doesn't like resizing to 'any' resolution, sdl does; sdl doesn't do midi, allegro does (or can do)
18:35:28 <Rubidium> and sdl is a few percent faster than allegro
18:36:45 <StarLionIsaac> useful to know if I ever want to make things harder deliberatly, basically
18:37:23 <Rubidium> with allegro you can run OpenTTD in dosbox though
18:37:58 <StarLionIsaac> I guess that might help if you need to run the DOS version... I can't see myself running it on an emulated DOS within Linux though
18:38:58 <Eddi|zuHause> maybe the mac users, if (dar)wine doesn't work :p
18:40:03 <StarLionIsaac> actually, wine seems to handle it pretty well, and darwine, as I understand it is wine ported to OSX, so it should handle it similarly
18:44:22 <StarLionIsaac> I know, should being the operative, I'm assuming that since under wine the past two weeks nightlies have worked on a five year old laptop, they'll work on a recent mac
18:44:40 <StarLionIsaac> probably a flawed premise, but I've never touched a mac, let alone used one
18:46:27 <Prof_Frink> If only there was someone employed by Codeweavers here...
18:56:57 *** andythenorth has joined #openttd
19:05:02 *** Terkhen has joined #openttd
19:06:05 *** TrainzStoffe has joined #openttd
19:11:56 *** insulfrog has joined #openttd
19:12:05 *** Nite_Owl has joined #openttd
19:12:54 *** TrainzStoffe is now known as Stoffe
19:13:20 *** HerzogDeXtEr1 has joined #openttd
19:13:25 <Nite_Owl> Hello andythenorth & insulfrog
19:22:21 <MyCatVerbs> Oh, wait, lost him. Oops, fail.
19:22:50 *** De_Ghosty has joined #openttd
19:33:46 *** De_Ghosty has joined #openttd
19:47:57 *** Phoenix_the_II has joined #openttd
19:50:47 *** Nite_Owl has joined #openttd
19:59:46 *** welshdragon has joined #openttd
20:06:19 *** TrainzStoffe has joined #openttd
20:11:51 *** Albert is now known as Pikkaa
20:12:37 <frosch123> did you change your timezone?
20:14:22 *** insulfrog has left #openttd
20:16:15 <sawtooth> the change that is causing 100% cpu usage on linux was introduced way back in 17140 as part of an update in the sound code
20:16:35 <sawtooth> well, causing 100% on my setup at least...
20:16:56 <StarLionIsaac> interesting.... I think I'm going to check this, is it that revision it starts, or that's the last one it doesn't happen on?
20:17:19 <sawtooth> 17139 was the last good revision
20:17:33 <sawtooth> the issue goes away if i use openttd -s null
20:17:52 <StarLionIsaac> I'm fairly certain for me it's been before then, but it has been a while
20:18:44 <frosch123> do you have a modified sample.cat or similiar? some sound replacement?
20:18:56 <sawtooth> not that i'm aware of :)
20:19:06 <StarLionIsaac> the latter in my case, but for that old a revision that shouldn't matter
20:19:29 <StarLionIsaac> I think it's before the option to use openSFX from the menu
20:19:29 <frosch123> the ttd dos version or the ttd win version of sample.cat?
20:19:52 <frosch123> 17140 was before opensfx
20:19:53 <StarLionIsaac> both, but I use dos (german) by default because that's what it picks up first
20:20:16 <frosch123> that's the graphic set, the sound set is choosen independently
20:20:35 <sawtooth> r17140 -Change: allow higher sample rate and higher quality samples. Based on work by orudge.
20:21:10 <StarLionIsaac> if I grabbed a fresh install of the current trunk, back up and remove my current config, and start up, it'll pick up sample.cat from dos (DE) first, then dos (ENG) then Win
20:21:16 <StarLionIsaac> then after that, OpenSFX
20:21:38 <StarLionIsaac> but for one that old, I'd guess it'll pick up the dos (DE) one, since that's what it seems to find first
20:21:49 <frosch123> there is only one dos sound set, de/non-de is only graphics
20:22:06 <StarLionIsaac> alright, my bad then, so dos sample.cat then
20:28:00 <StarLionIsaac> I can confirm it's revision 17140 where it starts using all available CPU on linux
20:28:11 <StarLionIsaac> and it doesn't appear matter which sound set is loaded, either
20:28:39 <Rubidium> StarLionIsaac: does -s sdl:hz=11025 fix the issue?
20:28:56 <sawtooth> StarLionIsaac: that fixed it for me. something about the sample size...
20:29:47 <StarLionIsaac> it does, but the CPU usage is still significantly higher than r17139
20:30:13 <StarLionIsaac> approx 20-30% more usage, at a guess and a glance at Conky
20:32:01 <Rubidium> don't see a reason for the 20-30% extra usage though
20:32:33 *** TrainzStoffe has joined #openttd
20:33:06 <StarLionIsaac> my guess may not be entirely accurate, since OpenTTD periodically dipped off the list of CPU using processes
20:33:34 <StarLionIsaac> plus, it was just a glance. I'm still fairly certain that there's some extra CPU usage between that suggested fix and the previous revision
20:33:36 <sawtooth> i tried setting the hz to 22050 and that seemed to be normal as well
20:35:04 *** _ccfreak2k is now known as ccfreak2k
20:36:18 *** steffan has joined #openttd
20:36:26 <StarLionIsaac> looking more carefully, setting it to 11025 makes it peak at 80% of the CPU usage, just before the main menu appears, but after that comes back down to about 40% usage
20:36:38 <Migran> Normal version OTTD can be run in a mode 32bpp?
20:37:02 <frosch123> hehe, -s sdl:hz=33000 has simliar effect to me :p
20:37:20 <StarLionIsaac> Migran: Have a look on the OpenTTD Wiki to find out how to do it exactly
20:38:02 <frosch123> StarLionIsaac: before the main menu appears ottd is loading and searching for files, high cpu usage is to be expected then
20:39:04 *** TrainzStoffe is now known as Stoffe
20:39:14 <StarLionIsaac> I guessed as such, as every version of OTTD I've run does the same, however, the more recent nightlies, this week's in particular, are peaking at 90% instead at that point, instead of the 80% I'm seeing with 17139 and 17140
20:39:38 <planetmaker> what does r12000 or so give you?
20:40:01 <frosch123> r12000? what's that?
20:40:25 <StarLionIsaac> planetmaker: give me a few moments to checkout and compile, and I'll be able to tell you
20:41:54 <Rubidium> frosch123: sdl:hz=33000 has a similar effect for me too
20:45:46 <Rubidium> hmm.. fill_sound_buffer uses *more* CPU cycles with 44100 than with 33000, but with 33000 cycles it's using more CPU
20:45:59 <Rubidium> so something happens in SDL
20:46:53 <StarLionIsaac> planetmaker: about 50% usage when OTTD starts up, and about 20% usage on the main menu, if that's what you meant by what it gives me
20:47:38 <planetmaker> yeah. I wondered about how it fares compared to recent nightlies
20:48:39 <StarLionIsaac> does suggest just how much extra there is now
20:48:57 <StarLionIsaac> also, I'm going to have to re-do my grflist, because r12000 just cleared all the bananas downloaded grfs from my list
20:49:07 <StarLionIsaac> I need to keep backups more often
20:50:03 <frosch123> just open your last autosave, and create a preset from the grfs used there
20:50:40 <StarLionIsaac> The last autosave is from a scenario with it's own list though
20:50:58 <StarLionIsaac> the last game using the closest to that list, doesn't load because it's from my pack, which I've slightly buggered
20:52:11 <Rubidium> if it doesn't find the bananas newgrfs it's 'obvious' it's faster, after all it doesn't do everything the newer revision does
20:52:52 <StarLionIsaac> Rubidium: all it did was remove the bananas ones from my list stored in the config file, it's not done anything else
20:54:10 <Rubidium> if it removes them from the config file it hasn't found them (and thus read their name)
20:54:52 <Rubidium> the first number is the number of CPU cycles for fill_sound_buffer/MxMixSamples, i.e. the mixing in OpenTTD
20:55:17 <Rubidium> with sdl:hz=33000 the sys time is, well... just huge
20:57:27 <Rubidium> can you 'reproduce' this increase in sys time between hz=11025 and hz=44100?
20:59:15 <Rubidium> for what it's worth, allegro behaves 'fine' with hz=33000
20:59:43 <_ln> i heard the Halle (Saale) team won the ice hockey game.
21:00:26 <StarLionIsaac> I can reproduce it most likely, if I can figure out why patch refuses to work today
21:01:50 <StarLionIsaac> it would help if I remembered to put -p0, I guess... today isn't going well for me
21:02:05 *** fonsinchen has joined #openttd
21:04:05 <StarLionIsaac> Rubidium: I assume the results go directly to the console, or is a debug option needed? just checking
21:04:52 <Rubidium> go directly to the console
21:05:10 <Rubidium> as long as you don't forget to use time :)
21:05:36 <StarLionIsaac> should have results shortly then, please be patient while my ancient computer creaks into life once more
21:05:45 <StarLionIsaac> well, not that ancient, but definatly old
21:16:54 <frosch123> sys 0m1.228s and sys 0m12.273s for me :)
21:17:08 <StarLionIsaac> hmm, question - I'm missing the real/user/sys parts on mine
21:17:08 <frosch123> so debian and gentoo agree this time
21:17:24 <frosch123> you forgot "time" ?
21:17:43 <StarLionIsaac> uh... I may have misinterpreted that as 'leave it for some time'
21:17:55 <StarLionIsaac> what exactly was it meant to mean
21:18:09 <frosch123> time executes a command and measures the used time
21:18:42 <StarLionIsaac> so, start it with "openttd time -s sdl:hz-44100" ?
21:18:56 <frosch123> no, "time openttd -s sdl:ht=44100"
21:18:56 <Rubidium> time openttd -s sdl:hz=44100
21:19:11 <StarLionIsaac> ah, gotcha... here goes again
21:20:21 *** TheMask96 has joined #openttd
21:23:22 <StarLionIsaac> gah, I might get it right yet
21:28:01 <Belugas> if you ask me, i prefer rz to hz...
21:28:05 <frosch123> user 18 -> 1 :o, is it everytime like that?
21:30:22 <Rubidium> the first debug line actually belongs to the 11025 hz case, right?
21:31:00 <StarLionIsaac> uh, yes... minor C&P error I made there, sorry
21:31:07 <Rubidium> can you try the allegro sound driver, -s allegro (you might need to install allegro + reconfigure and recompile)
21:31:50 <StarLionIsaac> if both sdl and allegro are present, which will configure pick up and use?
21:32:09 <Rubidium> at runtime sdl is prefered IIRC
21:32:33 <StarLionIsaac> ah, then in that case, does anyone know the name of the ubuntu package for allegro
21:33:21 <Rubidium> + the same but without -dev
21:33:32 <Rubidium> although that's probably automatically selected
21:33:55 <StarLionIsaac> indeed it is, I just didn't want to run through the entire list of packages again tonight
21:34:15 <Rubidium> StarLionIsaac: apt-cache search <keyword>
21:34:28 <StarLionIsaac> never knew about that one
21:35:18 <Rubidium> or in aptitude /allegro to start searching, n to go to the next hit
21:35:48 <StarLionIsaac> I've never got on well with aptitude, I prefer to use apt-get if I know the package, or Synaptic if I don't
21:35:55 <StarLionIsaac> or Adept, if I'm in KDE, which isn't often
21:36:25 *** welshdragon has joined #openttd
21:38:53 *** andythenorth has joined #openttd
21:43:18 <StarLionIsaac> recompiled with allegro installed, except it doesn't get started. Debug output says Failed to set up Allegro sound
21:43:30 <StarLionIsaac> hmm, no restart needed after installed allegro, is there?
21:44:18 <StarLionIsaac> I tried to run it with openttd -s allegro
21:44:24 <StarLionIsaac> nothing else, except the time
21:44:55 <Rubidium> why doesn't allegro start
21:45:14 <StarLionIsaac> sadly, my psychic link to my local linux expert died this morning, so I can't help there
21:50:22 <StarLionIsaac> more details, give me a moment to get them from the terminal
21:51:10 <StarLionIsaac> this is all it gets, it doesn't even manage to draw the window for OTTD
21:52:29 <Rubidium> that's because it aborts quite early
21:52:45 <Rubidium> but not being able to set alsa properties isn't a good sign
21:52:54 <sawtooth> was there allegro stuff fixed after 17140?
21:53:49 <StarLionIsaac> this is using the current nightly, by the way... does that make much difference?
21:53:51 <Rubidium> sawtooth: not that I'm aware of
21:53:55 <andythenorth> Is it time to attempt some register code in nfo, or is that for another day?
21:53:56 <sawtooth> i got the same error as StarLionIsaac regarding it not being able to open the midi device
21:54:14 <Rubidium> andythenorth: it's always time to attempt something
21:54:27 <Rubidium> StarLionIsaac: is pulseaudio running?
21:54:37 <sawtooth> i do have pulseaudio running here
21:54:40 <StarLionIsaac> possibly, and likely
21:55:22 <StarLionIsaac> correction: yes, it's definatly running
21:55:43 <StarLionIsaac> not without losing all sound entirely, something I'd rather avoid
21:56:36 <StarLionIsaac> uh... right, now how exactly does that work
22:00:53 <Rubidium> StarLionIsaac: the other possibility is compiling a newer (4.4? allegro)
22:02:04 <StarLionIsaac> all I have in the available repositories is 4.2, so unless there's an addable repo with it, I'll have to compile allegro itself as well
22:02:04 <Rubidium> hmm, which version of allegro got installed?
22:02:32 <StarLionIsaac> 4.2... and I'd rather not compile allegro myself, I don't think I've got enough space
22:02:39 <StarLionIsaac> at least not on this box
22:03:04 <Rubidium> StarLionIsaac: I need to know the 3rd digit
22:03:13 <Rubidium> I fear it's 2 (3 might fix the issue)
22:03:41 <StarLionIsaac> apt-cache search allegro just lists 4.2, I can check the detailed description to see if it has one as well
22:04:03 <Rubidium> allegro-config --version
22:06:56 <Rubidium> bah... package maintainers haven't updated the package :(
22:07:29 <Rubidium> but... is stopping pulseaudio just to test something really a problem?
22:07:34 <Rubidium> does it break that much?
22:07:34 <StarLionIsaac> this is Ubuntu Jaunty, if Ubuntu Karmic has an updated one, then wait until the 29th, when Karmic is released
22:07:46 <StarLionIsaac> it doesn't break as such, just prevent anything from making any sound at all
22:12:01 * Rubidium wonders whether the problem may lie in pulseaudio's resampling
22:12:40 <StarLionIsaac> again, that may have been fixed in a later version that isn't in Ubuntu's repo's
22:13:33 *** sawtooth has joined #openttd
22:13:33 *** TrueBrain has joined #openttd
22:13:33 *** Rexxars has joined #openttd
22:13:33 *** mikegrb has joined #openttd
22:14:05 <TrueBrain> hmm .. I liked this channel more a few moment ago
22:14:59 <Sacro> you're not the only one
22:15:28 <TrueBrain> you do understand that should result in a certain event happening, the BOFH speaking inside me, right?
22:16:10 <TrueBrain> this is what is called 'conditioning' ;)
22:17:12 <Sacro> this is more like 'grooming'
22:18:10 <Rubidium> StarLionIsaac: then I've got no clue how to find out what's the (exact) cause of the problem
22:26:58 *** andythenorth has left #openttd
22:41:12 <Eddi|zuHause> that's the first time ever i remember rubidium leaving...
22:43:55 <Eddi|zuHause> hm, the logs show like 5 more times...
22:48:38 *** Progman has joined #openttd
23:15:37 *** TrueBrain has joined #openttd
23:24:05 *** fonsinchen1 has joined #openttd
23:33:18 *** Eddi|zuHause has joined #openttd
23:38:58 *** Coco-Banana-Man has quit IRC
continue to next day ⏵
