Log for #openttd on 3rd January 2012:
Times are UTC Toggle Colours
00:05:18  *** valhallasw [~valhallas@] has quit [Ping timeout: 480 seconds]
00:15:24  *** encoded [] has quit [Ping timeout: 480 seconds]
00:17:00  <CIA-6> OpenTTD: frosch * r23722 /trunk/src/window.cpp: -Change: Give the chat query window the same Z priority as the normal text query window.
00:30:23  <frosch123> night
00:30:27  *** frosch123 [] has quit [Remote host closed the connection]
00:39:09  <CIA-6> OpenTTD: yexo * r23723 /trunk/src/ (object_cmd.cpp water_cmd.cpp): -Codechange: speedup flood checks a bit
00:40:07  <CIA-6> OpenTTD: yexo * r23724 /trunk/src/ (5 files): -Codechange: split of the check to see if ambient sounds are enabled to a header file allowing compilers to inline that check
00:40:43  <Yexo> ^^ with huge thanks to TrueBrain for the actual profiling part
00:41:42  <TrueBrain> yw :D
00:42:01  <TrueBrain> just compile before commit etc ;)
00:42:43  <CIA-6> OpenTTD: yexo * r23725 /trunk/src/water_cmd.cpp: -Fix (r23723): compile before commit
00:42:55  <TrueBrain> :D:D
00:43:18  <Eddi|zuHause> :)
00:44:16  *** MagisterQuis [] has joined #openttd
00:44:37  <Aali> so uh, on my box, threaded drawing prevents the game from doing.. anything at all really
00:44:45  <Aali> in r23721
00:45:06  <TrueBrain> in 23721? As in, since that revision?
00:45:16  <TrueBrain> or just a random one that fails?
00:45:21  <Aali> it just sits there, waiting on the mutex
00:45:28  <Aali> random one that fails
00:45:49  <TrueBrain> k :)
00:45:55  <TrueBrain> make a bug report I say?
00:46:00  <TrueBrain> including OS, CPU, ..
00:46:45  <Aali> not a known problem then? alright
00:46:56  <TrueBrain> I think that would be a critical error if it was common :D
00:47:11  <glx> happens at game launch sometimes
00:47:14  <TrueBrain> my reply would have been: see r<version> :D
00:47:35  <TrueBrain> glx: 1 out of the 20 runs in MSVC Debug never starts for me
00:47:40  <TrueBrain> never comes out of kernel initializing I believe
00:48:04  <glx> sometimes it deadlocks in MSVC for me
00:48:51  <Aali> uh
00:49:23  <Aali> looking at the code, I dont see how it could ever work
00:50:07  <Aali> it takes the mutex, creates the thread then waits for the signal
00:50:34  <Aali> while the thread takes the mutex then signals
00:50:48  <michi_cc> WaitForSignal() automagically unlocks the mutex
00:51:10  <Aali> ah yes of course it does
00:51:13  <michi_cc> and reacquires it upon return
00:51:14  <Aali> I had seen that already
00:51:34  <Aali> and then forgot it 5 minutes later
00:55:26  <Eddi|zuHause> damnit... two days in a row i hit the forum-backup time...
00:57:50  <Aali> okay, there it is, the draw thread is eating its own signal
00:59:25  <Aali> a Sleep(0) in SendSignal is enough to make it run on my box but I dont think thats the proper way to fix that..
01:04:34  *** Elu [] has joined #openttd
01:08:04  <michi_cc> So which OS are you talking about?
01:08:16  <Aali> windows
01:09:01  *** Zuu [] has quit [Ping timeout: 480 seconds]
01:10:04  *** Elukka [] has quit [Read error: Operation timed out]
01:12:05  <michi_cc> Hmm, normally SetEvent should release all waiting threads (and the mutex does make sure the main thread is waiting). Nevertheless I wouldn't add a sleep into SendSignal, but maybe only directly into PaintWindowThread.
01:12:37  <Aali> I'm thinking you should always prevent a thread from eating its own signal
01:12:42  <Aali> no matter how its scheduled
01:13:01  <Aali> the sleep is nothing more than a workaround
01:13:50  <Aali> I'm not sure how it works on other OSes
01:13:56  <TrueBrain> which OS?
01:14:02  <TrueBrain> owh
01:14:03  <TrueBrain> you already said
01:14:04  <michi_cc> Normally Send and Wait are done in different threads, only that initialization is different. Still, MS docs say that SetEvent should wake the waiting threads.
01:14:11  <TrueBrain> on Linux I can see issues with some weird scheduler :P
01:14:14  <TrueBrain> on Windows ... odd :)
01:14:26  <TrueBrain> anyway, night for me :)
01:14:48  <Aali> michi_cc: well, the other thread isn't waiting at that point
01:15:06  <michi_cc> It should :)
01:15:09  <Aali> it gets stuck waiting for the draw thread to signal (later)
01:15:38  <Aali> since the draw thread both sent a signal and then reset it all in one go
01:15:46  <Aali> (apparently)
01:15:51  <michi_cc> If it is not already waiting, it's not SendEvent that is broken, but the thread initialization/creation.
01:16:02  <michi_cc> (the OpenTTD code I mean, not windows)
01:17:36  <Aali> how could you make sure the main thread is waiting before starting the draw thread?
01:18:22  <Aali> not saying you can't, I just dont see how
01:19:41  <michi_cc> Because the main thread acquires the mutex for creating the drawing thread, which waits for it to be released as the first instruction.
01:20:06  <Aali> yeah but then the main thread releases the mutex before waiting
01:20:56  *** sllide [] has joined #openttd
01:21:35  <michi_cc> But that itself won't switch threads, but it's indeed is a race condition *only* if the time slice of the thread runs out exactly between releasing the mutex and the wait.
01:21:52  <Aali> apparently its causing trouble
01:22:00  <michi_cc> We should use a condition variable for that, but these are only available starting with Vista.
01:22:03  <Aali> I can reproduce it every time (so far)
01:22:51  <michi_cc> Then you have some very strange system, because this cause is *very* rare.
01:24:34  <michi_cc> And even a Sleep(0) isn't guaranteed to switch threads.
01:26:10  *** pugi [] has quit []
01:28:25  <Aali> to be fair, I only tried like 5 times
01:28:36  <Aali> this is a debug build by the way
01:28:40  <Wolf01> 'night
01:28:44  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
01:30:21  *** sliddy [] has joined #openttd
01:30:40  *** sllide [] has quit [Read error: Connection reset by peer]
01:35:39  *** Biolunar [] has joined #openttd
01:38:48  <Aali> release build works better, only happened once there
01:39:04  <Aali> explains why there haven't been many complaints about this
01:40:10  <glx> debug builds are slower, easier to trigger race condition in this case
01:41:58  *** Biolunar_ [] has quit [Ping timeout: 480 seconds]
01:43:54  <Aali> shouldn't make that much of a difference here..
01:44:51  <Aali> unless there's some wonderful misfeature that changes the behavior of critical sections in a debug build
01:46:09  *** encoded [] has joined #openttd
02:33:20  <CIA-6> OpenTTD: peter1138 * r23726 /trunk/src/blitter/32bpp_anim.cpp: -Fix (r23670): Remove debugging code added accidentally
02:38:45  *** Biolunar [] has quit [Quit: All your IRC are belong to us!]
02:39:06  *** Eddi|zuHause [] has quit [Remote host closed the connection]
02:39:36  *** Eddi|zuHause [] has joined #openttd
03:27:11  *** mahmoud [] has quit [Ping timeout: 480 seconds]
03:33:23  *** glx [glx@2a01:e35:2f59:c7c0:15f2:2c45:4202:17e5] has quit [Quit: bye]
03:42:42  *** sliddy [] has quit [Ping timeout: 480 seconds]
03:49:13  <Aali> is the autonightly server still operating?
04:08:21  *** pjpe [] has joined #openttd
04:10:17  *** dotwaffle [] has quit [Quit: Fixin' stuff]
04:10:46  *** dotwaffle [] has joined #openttd
04:28:17  *** TomyLobo [] has quit [Quit: Standby mode...]
05:00:39  *** kkb110_ [] has quit [Remote host closed the connection]
05:00:55  *** kkb110 [] has joined #openttd
05:03:04  *** ohnoes [] has joined #openttd
05:03:14  <ohnoes> hello everyone
05:09:26  <MagisterQuis> ohnoes: Hi.
05:11:18  <ohnoes> I was trying to build my first tunnel on openttd but my train refuses to cross it. I am using signals before and past the tunnel's railway in the direction I want the train to follow but right just when it approaches the tunnel entrance it stops and then tries to go in the opposite direction (it stops and reverses  almost right after that because of the one-way block signal I placed, and this loops forever)
05:13:06  <ohnoes> does anyway know why this is happenning?
05:14:50  <Aali> wrong railtype?
05:15:53  <ohnoes> wrong tunnel type! that is probably the problem
05:16:52  <ohnoes> solved!
05:21:58  *** kkb110__ [] has joined #openttd
05:21:58  *** kkb110 [] has quit [Read error: Connection reset by peer]
05:26:45  *** Snail_ [] has quit [Quit: Snail_]
05:36:43  *** kkb110__ [] has quit [Ping timeout: 480 seconds]
05:37:17  *** kkb110 [] has joined #openttd
05:41:09  <ohnoes> by the way, is it normal that after a certain year trains of the most basic railtype (the one before electrified railtype) cannot be built anymore?
05:44:31  <Elu> yeah, but you can turn off expiration dates somewhere in advanced settings
05:44:34  *** Elu is now known as Elukka
05:50:44  *** Eddi|zuHause [] has quit [Remote host closed the connection]
05:51:04  *** Eddi|zuHause [] has joined #openttd
05:52:57  <ohnoes> Elu, thanks!
05:53:55  *** KouDy [~KouDy@] has joined #openttd
05:59:20  *** supermop_ [] has quit [Quit: supermop_]
06:13:30  *** ohnoes [] has quit [Quit: ohnoes]
06:23:06  *** JVassie [~James@] has joined #openttd
06:28:51  *** DayDreamer [] has joined #openttd
06:35:10  *** HerzogDeXtEr [~Flex@] has quit [Read error: Connection reset by peer]
06:48:19  *** Twofish [] has joined #openttd
06:48:25  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
06:49:50  *** Elukka [] has quit []
06:53:07  *** TdlQ_ [] has joined #openttd
07:03:53  *** sla_ro|master [~slaco@] has joined #openttd
07:58:40  *** Devroush [] has joined #openttd
08:06:25  *** snack2 [] has joined #openttd
08:09:40  *** TdlQ_ [] has quit [Ping timeout: 480 seconds]
08:18:49  *** astol [~Adium@] has joined #openttd
08:29:45  *** Progman [] has joined #openttd
08:43:10  *** Neon [] has joined #openttd
09:03:20  *** pjpe [] has quit [Quit: ajax IRC Client]
09:24:05  *** TGYoshi [~TGYoshi@] has joined #openttd
09:29:09  *** DayDreamer [] has left #openttd []
09:41:21  <CIA-6> OpenTTD: truebrain * r23727 /trunk/src/blitter/32bpp_anim.cpp:
09:41:21  <CIA-6> OpenTTD: -Codechange: speedup the 32bpp palette animation by reducing the amount of
09:41:21  <CIA-6> OpenTTD: compares. This is possible because the function is called with only 2 possible
09:41:21  <CIA-6> OpenTTD: conditions: from 0 to 255 (full palette update, 8bpp only) or from
09:41:21  <CIA-6> OpenTTD: PALETTE_ANIM_START to 255
09:44:23  *** XaTriX [] has quit [Quit: ajax IRC Client]
09:53:49  *** astol [~Adium@] has quit [Quit: Leaving.]
09:54:34  *** astol [~Adium@] has joined #openttd
09:57:07  *** KouDy [~KouDy@] has quit [Quit: Leaving.]
10:02:16  *** fjb|tab is now known as Guest22544
10:02:16  *** Guest22544 [] has quit [Read error: Connection reset by peer]
10:02:17  *** fjb|tab [] has joined #openttd
10:02:36  *** astol [~Adium@] has quit [Ping timeout: 480 seconds]
10:07:14  *** KouDy [~KouDy@] has joined #openttd
10:17:56  <planetmaker> moin
10:18:36  <appe_> morning mr makerplanet.
10:18:50  *** astol [~Adium@] has joined #openttd
10:22:00  <CIA-6> OpenTTD: truebrain * r23728 /trunk/src/company_cmd.cpp: -Fix [#FS4942-ish]: when cheating into another company, the SignList was not updated
10:44:49  <CIA-6> OpenTTD: truebrain * r23729 /trunk/src/blitter/32bpp_anim.hpp: -Fix (r23670) [FS#4941]: if you increase the buffer size, also increase the bytes per pixel
10:45:41  <peter1138> :p
10:54:16  *** Wolf01 [] has joined #openttd
10:54:58  <Wolf01> hello
10:57:21  *** pugi [] has joined #openttd
11:06:18  <__ln__> good new year twothousandonetwo, Wolf01
11:06:30  <Wolf01> to you too, __ln__
11:07:46  *** DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183541]]
11:14:52  <__ln__>
11:16:18  <Yexo> lol
11:22:05  *** Zuu [] has joined #openttd
11:26:59  *** Darkvater [] has joined #openttd
11:27:02  *** mode/#openttd [+o Darkvater] by ChanServ
11:27:09  *** Darkvater [] has quit []
11:27:27  *** Darkvater [] has joined #openttd
11:27:30  *** mode/#openttd [+o Darkvater] by ChanServ
11:27:37  *** Darkvater [] has left #openttd []
11:29:40  <Mazur> Oh, my lordy, lordy, lord....
11:29:51  <Mazur> I just got 24" in the mail...
11:30:15  <Mazur> I'll be gone for a bit to amuse myself with it, shortly.
11:30:59  * __ln__ continues working with his dual-24" configuration at work
11:31:31  <appe_> does anyone of you use C# alot?
11:33:38  <peter1138> some
11:33:48  <appe_> im a complete newbie
11:33:57  <Yexo> I've used it a bit over the last few months
11:34:02  <appe_> and im making an if statement
11:34:11  <peter1138> same as C/C++
11:34:13  <appe_> and i need to search with a wildcard
11:34:25  <Yexo> search in what?
11:34:31  <appe_> well, not search, really.
11:34:34  <appe_> hold on.
11:34:54  <Yexo> <appe_> im a complete newbie <- with C# or programming in general?
11:35:03  <appe_> in general.
11:35:11  <appe_> if (myReader["cust_ed3"].ToString() == "text")
11:35:22  <appe_> that is the row of code i need to change. i didnt write that myself.
11:35:41  <appe_> i want "text" to be something like *text*
11:36:05  <peter1138> something like *text*?
11:36:05  <Yexo> if (myReader["cust_ed3"].ToString().Contains("text")) {
11:36:12  <appe_> ah, contains
11:36:22  <appe_> ill try it :)
11:37:45  <appe_> i have no experience what so ever in code
11:37:46  <appe_> but this is fun
11:45:02  *** tokai|noir [] has joined #openttd
11:51:06  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
11:57:00  *** fjb|tab [] has quit [Ping timeout: 480 seconds]
11:57:42  *** fjb|tab [~frank@] has joined #openttd
11:59:30  *** vb [~chatzilla@] has joined #openttd
11:59:32  <vb> hi
11:59:44  <vb> how to start a game with newgrf settings applied?
12:00:26  <Yexo> apply newgrf settings from main menu, start new game
12:00:37  <vb> i did so, i only had  some industries
12:00:39  <vb> but no trains
12:00:47  <vb> even though the newgrf was applied
12:00:56  <Yexo> upload your savegame somewhere
12:02:15  *** kkb110 [] has quit [Ping timeout: 480 seconds]
12:02:53  <vb> oh
12:02:59  <vb> i think i know the issue
12:03:17  <vb> i have ECS & FIRS original vehicle set, i think that is only for cargo
12:03:20  <vb> to change it
12:03:21  <vb> right?
12:03:26  <Yexo> no clue
12:03:34  <Yexo> if you want the default vehicles with refit options, try OpenGFX+
12:03:54  <vb> i want new trains
12:04:03  <Yexo> in that case use a different trainset
12:04:16  <Yexo> every complete trainset I know can refit to the firs/ecs cargoes
12:04:19  <vb> what is the best newgrf setting for a singleplayer game?
12:04:33  <Yexo> there is no single best setting
12:04:39  <Yexo> it all boils down to personal preferences
12:06:47  *** kkb110_ [] has joined #openttd
12:08:04  <vb> what trainset do you recommend?
12:08:19  *** Zuu [] has quit [Ping timeout: 480 seconds]
12:13:59  <V453000> UKRS 3.04 <3
12:14:04  <V453000> always good
12:14:44  <V453000> it depends on what you want to play, try yourself :) discovering all the joys by yourself is best after all
12:14:49  <vb> i only see version 2
12:15:39  <V453000> UK Renewal Train Set might be the exact name
12:15:48  <V453000> maybe without the Train
12:16:05  <V453000> the UKRS2 is awesomely drawn but lacks some variety in compare to the 3.04
12:16:05  <vb> found it
12:16:15  <vb> should i also get the addon pack?
12:16:19  <V453000> sure
12:16:38  <Ammler> best is if you load at least 50 newgrfs
12:16:51  <vb> :))
12:16:56  <V453000> or 64 right :p
12:16:59  <planetmaker> ...
12:17:28  <planetmaker> irony carries badly
12:17:35  <vb> i have at least 461 hours of openttd played
12:17:37  <vb> lol
12:17:39  <vb> :/
12:17:39  <Mazur> That way you get at least all the necessary NewGRF conflicts we want to know about.
12:17:52  <V453000> I have about over 9000 millions hours of openttd player :p
12:18:07  <V453000> d
12:18:10  *** KritiK [] has joined #openttd
12:18:39  <Mazur> I even have over 10 hours!
12:18:43  <Mazur> Ha!
12:18:51  <Ammler> vb: it could be fun to find your personal best newgrf yourself
12:19:22  <V453000> exactly as Ammler says :)
12:20:20  *** kkb110_ [] has quit [Ping timeout: 480 seconds]
12:23:04  *** Mazur [] has quit [Remote host closed the connection]
12:24:11  <vb> ok
12:24:18  <vb> what about AI?
12:24:25  <V453000> none :)š
12:24:40  <vb> i want some competition :)
12:25:15  *** TomyLobo [] has joined #openttd
12:26:58  <Ammler> try MP
12:27:20  <Ammler> or else, same with AI as with newgrfs, find it yourself :-P
12:29:21  <Yexo> has a table comparing some basic features
12:29:28  <Yexo> you'll still have to try some to see what works for you
12:29:46  <planetmaker> yes, either try out a few AIs in the game yourself. They really have different play styles and competitiveness is not always what counts
12:32:23  *** vb [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912]]
12:39:17  *** andythenorth [] has joined #openttd
12:39:24  *** Guest22251 is now known as AD
12:40:50  *** frosch123 [] has joined #openttd
12:48:34  <Eddi|zuHause> *mental note* amarok's OSD will not display the correct title while i'm playing radio in kaffeine...
12:51:44  <peter1138> no
12:51:48  <peter1138> odd that
13:11:21  *** glx [glx@2a01:e35:2f59:c7c0:dc84:ab0a:742f:56a7] has joined #openttd
13:11:24  *** mode/#openttd [+v glx] by ChanServ
13:28:23  <__ln__> meanwhile in finland:
13:41:35  *** Snail_ [] has joined #openttd
13:45:30  *** Remi_Woler [] has joined #openttd
13:51:56  <Hirundo> I knocked together a patch to config static newgrfs via the GUI:
13:52:20  <Hirundo> It's still WIP, before I continue I'd like some input on a few conceptual issues
13:53:51  <Hirundo> How should static newgrfs and newgrf presets interact? Should presets set static newgrfs also? Should static and normal newgrfs be configured via a single preset, or is it best to split that? Or just keep presets for normal newgrfs only?
13:54:30  <Eddi|zuHause> presets should be separate from static grfs
13:55:42  <planetmaker> Hirundo: presets should not care about static NewGRFs
13:56:07  <Hirundo> So presets affect normal grfs only, and when the user is editing the static grf list, the preset buttons are disabled
13:56:07  <planetmaker> I'm not sure whether it's better to split static and non-static config.
13:56:27  <planetmaker> I'd first try it in the same window. With possibly differently coloured entries or a checkbox
13:56:32  <planetmaker> behind each newgrf
13:57:07  <Hirundo> I currently made two tabs on the active newgrf list in the newgrf settings window
13:57:28  <planetmaker> ah, you made a separate tab. I'm fine either way
13:57:34  <planetmaker> it's less work that way, probably
13:58:33  <Ammler> shouldn't openttd be able to detect "static" newgrfs?
13:58:59  <Eddi|zuHause> different issue
13:58:59  <Hirundo> It is able to test if a grf is safe for static usage
13:59:33  <Ammler> Eddi|zuHause: well, it would mean, you do not need any manual selection of it
13:59:43  <Eddi|zuHause> yes, you do
13:59:53  <planetmaker> if a non-static newgrf tries to interact with a static newgrf, the static newgrf is disabled. And there's a static check in the newgrf loader
13:59:56  <Eddi|zuHause> just because a grf can be static, doesn't mean you want it to be
14:00:10  <Ammler> why not?
14:00:17  <Eddi|zuHause> e.g. german signals grf
14:00:26  <Eddi|zuHause> i wouldn't want that in a UKRS preset
14:01:00  <planetmaker> Ammler: it's much better if you can select the static newgrfs to use
14:01:15  <planetmaker> or you'd have ALL tree newgrfs. ALL signal newgrfs. And ALL landscape replacement sets
14:01:21  <Ammler> s/better/easier/, of course
14:01:33  <frosch123> if we transfer the newgrf settings to the "start new game" window, then static newgrfs would be moved to the "options"
14:01:48  <frosch123> e.g. next to the basesets
14:01:55  <frosch123> and not in the same window as newgrfs
14:02:06  <Ammler> the advantage would be that you for example could also disable a static grf loaded on a mp server
14:02:45  <frosch123> you cannot disable static grfs in a running game, you would have to do that before joining
14:03:08  <Ammler> frosch123: yes, now, that's the point :-)
14:03:19  <Eddi|zuHause> you cannot unload a grf if it is loaded non-statically by the server
14:03:22  <Hirundo> That gets you into trouble if other non-static grfs depend on that static-but-non-statically-loaded newgrf
14:03:26  <Eddi|zuHause> even if that grf could be static
14:04:00  <Ammler> well, the question is is there need to load a static grf as non-static?
14:04:13  <Eddi|zuHause> you can, however, make a static grf that counteracts the effects of the other non-static grf
14:04:22  <frosch123> yes, if non-static grfs depend on static grfs
14:04:31  <Terkhen> hello
14:04:47  <frosch123> afternoon terkhen :)
14:04:56  <Eddi|zuHause> Ammler: some canadian station grf checks for presence of the dutch catenary grf
14:05:08  <Eddi|zuHause> Ammler: at that point, dutch catenary cannot be static anymore
14:05:18  <Eddi|zuHause> even if by itself it could
14:05:20  <Ammler> ok, I see
14:07:14  <Hirundo> Currently I'm thinking about doing a safety scan for all grfs during the file scan at startup, then filter the list of available grfs when the user is selecting static grfs
14:07:40  <planetmaker> Hirundo: that'd mean really reading the NewGRFs completely
14:07:46  <Ammler> but the whole point about static grf is for MP, you agree?
14:08:02  <Eddi|zuHause> the grfs must be read once for md5sum anyway
14:08:02  <Hirundo> AFAIK, safety scan aborts at the first action0/3
14:08:03  <planetmaker> And: static yes/no can depend on the active NewGRF list (e.g. query for the static one)
14:08:11  <Eddi|zuHause> as long as the result is cached...
14:08:30  <planetmaker> well. Startup is not exactly instant with many newgrfs
14:08:40  <Hirundo> planetmaker: that part of the safety scan is executed only when starting a game, afaik
14:08:44  <planetmaker> I just wonder whether this scan should happen threaded in background
14:08:59  <Ammler> so the only time, you need static grf is when you join a MP game
14:09:10  <Eddi|zuHause> Ammler: no
14:09:16  <Ammler> why else?
14:09:24  <Eddi|zuHause> Ammler: static grfs also "survive" a preset change
14:09:34  <Eddi|zuHause> (at least they should)
14:09:48  <Eddi|zuHause> Ammler: or loading a scenario
14:10:06  <Ammler> ok, but that might not need to be static, that could be called "global" or so :-)I
14:10:25  <Ammler> does not need to be static grfs only
14:10:33  <Eddi|zuHause> just because you don't see the use-case, doesn't mean it doesn't exist
14:10:38  <Ammler> but for MP, you can only use static grfs
14:10:48  <Eddi|zuHause> Ammler: yes, for scenarios only static grfs can be changed
14:11:36  *** Snail_ [] has quit [Quit: Snail_]
14:11:52  <Ammler> Eddi|zuHause: mÀh, you discuss newbie scenario
14:12:23  <Eddi|zuHause> i discuss scenarios for 99% of the user base
14:13:43  <Ammler> you should talk for yourself :-P
14:14:19  <Eddi|zuHause> Ammler: i'm not in the target group for a static-newgrfs-gui
14:15:29  <Hirundo> Editing config files and hard-coding grf locations and parameters can be intimidating for many :-)
14:15:59  <Ammler> nobody does that anymore
14:16:16  <Hirundo> If I'd want to load a static grf, I'd load it as normal grf, set parameters, close openttd and copy-paste in openttd.cfg
14:16:24  <Hirundo> Not exactly a user-friendly process
14:17:01  <Ammler> well, the use for static grfs was high as you had to configure newgrfs via cfg
14:17:19  <Ammler> since there is the newgrf gui, most play with what they got
14:18:59  <planetmaker> which shows clearly that editing a cfg is... not user friendly. As at the same time the NewGRF usage skyrocketed since they could be configured ingame
14:24:06  <Hirundo> So, having a GUI for static NewGRFs makes sense, assuming that static NewGRFs make sense in the first place
14:25:14  <Ammler> the possiblity to add/remove grfs which don't affect gameplay on a running game makes sense
14:25:25  *** supermop_ [] has joined #openttd
14:25:47  <Ammler> from my view the only usecase for it, as Eddi|zuHause mentioned, there could be another use case :-)
14:27:13  <Hirundo> Are static newgrfs completely safe to add/remove even during a running game (w/o restart)?
14:28:00  <Ammler> well, it depends how you handle those static grfs, which become non-static :-)
14:28:14  <Hirundo> These are disabled
14:28:57  <Ammler> but if you restart the game anyway, why do you need static grfs?
14:29:56  <Hirundo> Currently you need to restart openttd to change static newgrfs
14:30:07  <Ammler> he, don't think so
14:30:17  <Ammler> or do you call joining a server a restart?
14:30:28  <Hirundo> Does that change static newgrfs?
14:30:40  <Ammler> of course
14:31:40  <Hirundo> They are just applied (or not, if they turn out to be unsafe), not changed during a live game
14:31:56  *** alluke [] has joined #openttd
14:32:00  <Ammler> you can join with different static configs
14:32:04  <Ammler> the same game
14:33:25  <Hirundo> but you cannot currently change the grfs with all other grfs already loaded, you just load a different config
14:34:07  <Eddi|zuHause> which means you need to make a temporary save and reload it
14:34:16  <Ammler> Hirundo: yes, but you do not restart the game
14:34:36  <Hirundo> Currently you have to restart openttd, thereby clearing all in-memory stuff
14:35:08  <Hirundo> Changing hot memory might or might not cause new problems, I don't know for sure
14:35:09  <Ammler> yes, you might need to restart the client, but the game still runs on the server
14:35:19  <Hirundo> ofc
14:35:32  <Eddi|zuHause> i don't think you two are talking about the same thing :)
14:35:37  <frosch123> Hirundo: adding static grfs requires to reload all grfs, i.e. means to reload a game resp. rejoin a game
14:36:23  <Hirundo> frosch123: reload also in single player?
14:37:05  <Hirundo> or is ReloadNewGRFData() enough?
14:37:28  <Eddi|zuHause> is that he function that is run when clicking "apply newgrfs"?
14:38:17  <frosch123> Hirundo: problem with the latter is that engine reliability is reset
14:38:59  <frosch123> (well, the same happens on "apply newgrfs" or "reload_newgrfs")
14:39:18  <frosch123> but for static newgrfs it is safe to not reset engines :p
14:39:51  <Eddi|zuHause> that function could use a sandbox to check what actually changed
14:40:16  <frosch123> yeah, one might only reset the engines of grfs which actually changed
14:40:35  <frosch123> though that fails if the engines depend on other grfs being present :p
14:40:36  <Eddi|zuHause> well, grf-order may have influence
14:40:54  <Hirundo> And perhaps other random data except reliability
14:40:56  <Eddi|zuHause> that's why a sandbox is needed
14:41:23  <Eddi|zuHause> create new newgrf config -> compare available engines -> resetengines
14:41:25  <Hirundo> frosch123: grfid checks on static grfs disable the static grf for that reason
14:41:57  <frosch123> yes, thus it is safe to preserve reliability when changing static grfs, but not when changing other grfs
14:42:05  *** alluke_ [] has joined #openttd
14:42:40  *** Mazur [] has joined #openttd
14:42:48  <Eddi|zuHause> but the sandbox would also cover cases where e.g. only station grfs were changed
14:43:48  <Mazur> Ok, everybody line up next to eachother.
14:44:01  <frosch123> hellion attack?
14:44:05  *** alluke [] has quit [Ping timeout: 480 seconds]
14:44:11  <Mazur> No, no need to scrunch up, use the space you want, I gots jme the pixels.
14:44:25  <Mazur> 1920x1080
14:44:48  * SpComb 1920x1200
14:44:55  <SpComb> you're missing a few pixels off the bottom, it seems
14:45:04  <BUTTMUNCH> 2560x1600
14:45:15  *** astol [~Adium@] has quit [Quit: Leaving.]
14:45:15  <SpComb> increase font size :)
14:45:19  <Mazur> Well, I did not have money for more.
14:45:29  <BUTTMUNCH> ya i have, i also have the gui double thing
14:45:40  * Mazur takes a dump on BM's face.
14:45:45  <Mazur> Can you now see shit?
14:45:46  <SpComb> no, it's just computer monitor manufacturers thinking that marketing video resolutions for computer displays is a good idea
14:46:54  *** fjb|tab [~frank@] has quit [Ping timeout: 480 seconds]
14:47:09  <Eddi|zuHause> with the whole HDTV hype, suddenly computer monitors stopped developing
14:47:29  <Eddi|zuHause> last time i searhced, it was really difficult to find monitors with higher resolutions
14:47:50  *** astol [~Adium@] has joined #openttd
14:48:08  <Eddi|zuHause> it contradicts moore's law
14:48:15  <BUTTMUNCH> it’ll change
14:48:17  <BUTTMUNCH> very soon
14:48:30  <BUTTMUNCH> in the next 2 years you’ll see better ppi monitors
14:49:06  *** DayDreamer [] has joined #openttd
14:51:45  *** astol [~Adium@] has quit []
14:57:55  *** KingJ [~KingJ-OFT@] has quit [Ping timeout: 480 seconds]
15:05:24  *** vb [~chatzilla@] has joined #openttd
15:05:26  <vb> hey
15:05:31  <vb> how do i make towns smaller?
15:05:34  <vb> when i start a new map
15:06:59  <BUTTMUNCH> is there a clear reason why someone would timeout from my server every 5 minutes?
15:07:22  <planetmaker> bad connectivity
15:07:50  <BUTTMUNCH> it’s not that
15:08:07  <BUTTMUNCH> we run other games together and they run fine
15:08:09  <BUTTMUNCH> for hours
15:08:18  <glx> crappy router
15:08:44  <BUTTMUNCH> it’s not that
15:08:46  <BUTTMUNCH> we run other games together and they run fine
15:08:48  <BUTTMUNCH> for hours
15:09:24  <vb> how do i make towns smaller? when i start a new game
15:09:38  <planetmaker> "my car got scratches and bumps" - "don't drive your Ferrari on a dirt road" - "But my LandRover works there for hours without a single dent"
15:09:54  <planetmaker> ^^ see the similarity, BUTTMUNCH ?
15:10:00  <BUTTMUNCH> yes
15:10:04  <BUTTMUNCH> in this case the ferrari is game 1
15:10:07  <BUTTMUNCH> and the landrover is game 2
15:10:19  <BUTTMUNCH> the road would be my router
15:10:24  <glx> not yours
15:10:25  <planetmaker> they use different protocols, different ports. Differently shaped traffic
15:10:42  <BUTTMUNCH> i bet openttd uses traffic shaped like penises
15:10:47  <BUTTMUNCH> my router is rather homophobic
15:10:57  <vb> :))
15:10:58  <planetmaker> vb: set town sizes to small...
15:11:01  <vb> i do
15:11:08  <vb> i still have some of 2000+ population
15:11:24  <vb> or actually i didn't
15:11:26  <vb> how to set it?
15:11:48  <vb> i also want even lower nr. of towns  than very low
15:12:46  <BUTTMUNCH> put it on custom
15:12:51  <planetmaker> then use the scenario editor to manually place towns
15:12:51  <BUTTMUNCH> and fill in a nyumber to your liking
15:13:25  <vb> tks
15:13:32  <vb> what about size?
15:13:35  <vb> where do i change that
15:22:03  *** yorick_ [] has joined #openttd
15:22:33  *** yorick [] has quit [Ping timeout: 480 seconds]
15:35:03  *** Adambean [] has joined #openttd
15:39:27  *** vb [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912]]
15:53:18  *** Twofish [] has quit [Quit: Leaving]
15:57:04  *** leeroberson [] has joined #openttd
15:57:09  *** leeroberson is now known as eberon
15:57:25  <eberon> hi all, quick gameplay question
15:57:59  <eberon> I've been playing this forever and I never figured this out: 'days in transit' for cargo -- that starts when a vehicle picks it up, right?
15:58:14  <planetmaker> iirc yes
15:58:16  <eberon> as soon as it leaves the station to a vehicle? so as you wait 20 days for a full load the cargo is losing value?
15:58:58  <eberon> I saw a lot of interesting and really useful graphs on the matter on the wiki and I was wondering if maybe my full-train-length full-load single train only system is not really that optimized
15:59:34  <planetmaker> yes... but full load makes sure you have good station rating which gives you more cargo delivered to the station in the first place
15:59:45  <CIA-6> OpenTTD: rubidium * r23730 /trunk/ (5 files in 2 dirs): -Add: Australian translation
15:59:57  <planetmaker> Australian? Nice
16:00:47  <eberon> planetmaker: awesome, cool, that's what I thought.
16:02:08  <andythenorth> needs a decent australian set :P
16:02:33  <andythenorth> I'll bring trucks
16:02:33  <andythenorth>,or.r_gc.r_pw.,cf.osb&fp=50d609503607b311&biw=1276&bih=
16:02:41  <andythenorth> where's pikka when you need him :D
16:03:35  *** supermop [] has joined #openttd
16:03:41  <TrueBrain> where are short URLs when you want them :P
16:04:42  <SpComb> most of that url is cruft, presumeably
16:05:05  <__ln__> it's possible it got truncated
16:05:33  <SpComb> probably just the ?q= bit would do
16:05:52  <encoded> indeed
16:06:27  *** supermop_ [] has quit [Remote host closed the connection]
16:07:26  <andythenorth>
16:07:44  <andythenorth> ^ they need quantum effects when queueing
16:07:45  <andythenorth> :P
16:07:58  <andythenorth> also - note they're using drive-through roadstops, not drive-in ones
16:08:09  <andythenorth> they're probably waiting for NewStations too
16:10:29  *** BUTTMUNCH [] has quit [Read error: Connection reset by peer]
16:10:33  *** iddqd [] has joined #openttd
16:12:49  *** kkb110 [] has joined #openttd
16:31:07  <CIA-6> OpenTTD: truebrain * r23731 /trunk/src/ (20 files in 8 dirs): -Add: add GSGoal::Question(), to ask a question to a(ll) company(ies). It can contain random text, and at most 3 buttons from a collection of 17
16:38:21  *** andythenorth [] has quit [Quit: andythenorth]
16:41:02  *** Prof_Frink [] has joined #openttd
16:44:23  *** Elukka [] has joined #openttd
17:00:18  <TrueBrain> CargoDist still fails on the CF ..
17:00:19  <TrueBrain> so sad
17:00:33  <Eddi|zuHause> and what's wrong?
17:04:34  *** Netsplit <-> quits: Vadtec, encoded, kkb110, JoeyJo0, jonty-comp, namad7, mikegrb_
17:05:00  *** Netsplit over, joins: kkb110, encoded, JoeyJo0, Vadtec, namad7, mikegrb_, jonty-comp
17:05:00  <TrueBrain> Eddi|zuHause:
17:06:12  *** andythenorth [] has joined #openttd
17:06:43  <Eddi|zuHause> so it only works for windows?
17:07:27  *** Biolunar [] has joined #openttd
17:15:39  *** andythenorth [] has quit [Quit: andythenorth]
17:19:15  *** andythenorth [] has joined #openttd
17:19:52  *** HerzogDeXtEr [~Flex@] has joined #openttd
17:27:56  *** mahmoud [] has joined #openttd
17:32:42  *** KritiK_ [] has joined #openttd
17:32:42  *** KritiK [] has quit [Read error: Connection reset by peer]
17:32:43  *** KritiK_ is now known as KritiK
17:35:10  *** andythenorth [] has quit [Quit: andythenorth]
18:09:33  *** andythenorth [] has joined #openttd
18:14:37  *** fonsinchen [] has joined #openttd
18:18:40  *** pjpe [] has joined #openttd
18:22:24  *** TdlQ_ [] has joined #openttd
18:27:50  *** |Jeroen| [] has joined #openttd
18:32:32  *** andythenorth [] has quit [Quit: andythenorth]
18:37:19  <TrueBrain> Eddi|zuHause: yes, and they are not published because the compilation fails for most targets :)
18:41:01  <CIA-6> OpenTTD: translators * r23732 /trunk/src/lang/ (13 files): (log message trimmed)
18:41:01  <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:41:01  <CIA-6> OpenTTD: bulgarian - 7 changes by kokobongo
18:41:01  <CIA-6> OpenTTD: croatian - 3 changes by VoyagerOne
18:41:01  <CIA-6> OpenTTD: dutch - 20 changes by Yexo
18:41:02  <CIA-6> OpenTTD: english_US - 20 changes by Rubidium
18:41:02  <CIA-6> OpenTTD: finnish - 22 changes by jpx_
18:43:47  *** andythenorth [] has joined #openttd
18:51:43  *** Chris_Booth [] has joined #openttd
18:53:03  *** kkb110 [] has quit [Read error: Operation timed out]
18:55:11  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
18:59:12  *** TheMask96 [] has joined #openttd
19:00:19  *** HerzogDeXtEr1 [] has joined #openttd
19:00:50  *** |Jeroen| [] has quit [Quit: oO]
19:00:53  *** Alberth [] has joined #openttd
19:00:56  *** mode/#openttd [+o Alberth] by ChanServ
19:03:18  *** alluke_ [] has quit [Ping timeout: 480 seconds]
19:04:38  *** HerzogDeXtEr [~Flex@] has quit [Ping timeout: 480 seconds]
19:04:38  *** alluke [] has joined #openttd
19:05:01  <alluke> is there a way to disable the yellow ottd mouse
19:05:44  <alluke> this huge mp game is lagging my ass off and the mouse does so too making building anyhing impossible
19:06:02  <Alberth> use a smaller map?
19:06:31  <Eddi|zuHause> and what would using the system mouse solve?
19:07:01  <Alberth> buying a faster computer helps more though
19:07:12  <Yexo> alluke: buy a faster computer or use a smaller map with less vehicles
19:07:20  <Yexo> most of all: don't use any newgrfs or AIs
19:07:20  <__ln__> *fewer
19:13:00  <alluke> the map aint mine...
19:13:04  <alluke> and my computer is fast enough
19:13:15  <alluke> and its multiplayer
19:13:21  <alluke> in sp it should work
19:13:41  <alluke> id prefer my own back mouse anyway
19:13:44  <alluke> black*
19:13:51  <Eddi|zuHause> so again, why is this the mouse pointer's fault?
19:14:10  <alluke> it lags with the rest
19:14:15  <alluke> my own mouse wouldnt
19:14:19  <Rubidium> it's just a single line of code to give you your little black mouse
19:14:30  <Rubidium> and probably a hell of a lot more to get the other one not there anymore
19:14:33  <alluke> i could jsut let the background lag and build stuff like before
19:14:55  <Eddi|zuHause> hiding the other game pointer can be done with a static grf
19:15:06  <alluke> oooh
19:15:25  <alluke> now wheres this little treasure
19:15:38  <Eddi|zuHause> you'll have to make one yourself
19:15:45  <alluke> duh
19:16:14  <CIA-6> OpenTTD: rubidium * r23733 /trunk/src/ (cheat_gui.cpp cheat_type.h lang/english.txt): -Fix-ish [FS#4939]: cheating to different climates messes things even more up than changing NewGRFs in-game... so guess what happened
19:16:23  <Yexo> and by hiding it you wouldn't stop it from functioning
19:16:57  <alluke> once there was a bug that put my original mouse above the game pointer
19:17:02  <alluke> sooooo smooooooth
19:17:21  <CIA-6> OpenTTD: rubidium * r23734 /trunk/src/lang/ (51 files in 2 dirs): -Cleanup: remove the translated strings as well
19:17:32  <Eddi|zuHause> alluke: i still think you should rather be solving the actual problem, not doctoring some weird symptoms
19:17:53  <alluke> mm ye
19:19:01  <Eddi|zuHause> alluke: anyway, you need to modify the ClaimMousePointer() function of your video driver and compile, to get the system pointer drawn
19:19:17  <Ammler> isn't there a option to disable the mouse pointer or was that something in TTDP?
19:19:19  <Eddi|zuHause> and replace the game sprites with transparent ones
19:20:12  <Ammler> or maybe completely another game I have in mind :-)
19:20:19  <Eddi|zuHause> probably that :p
19:21:52  <TrueBrain> Windows?
19:21:58  <TrueBrain> Backgammon?
19:22:39  <Eddi|zuHause> backgammon is a weird game
19:23:04  <andythenorth> +1
19:23:18  <andythenorth> Eddi|zuHause is thinking of Dice Wars
19:23:19  <TrueBrain> -12
19:23:29  <andythenorth>
19:27:45  *** alluke [] has quit [Quit: Page closed]
19:27:55  <andythenorth> oh he's gone
19:28:00  <andythenorth> probably not a Dice Wars fan
19:30:02  <Eddi|zuHause> dice wars is the one where you capture countries?
19:31:34  <frosch123> that's risk
19:32:37  <Eddi|zuHause> well, not exactly :)
19:32:58  <Eddi|zuHause> and in risk you "free" countries, because "capture" is too militaristic :p
19:54:44  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
20:08:32  <frosch123> Xaroth: why are you not running beta1 ? :p
20:08:36  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has joined #openttd
20:19:55  *** Zuu [] has joined #openttd
20:20:53  *** pjpe [] has quit [Quit: ajax IRC Client]
20:26:07  <CIA-6> OpenTTD: rubidium * r23735 /trunk/src/ (71 files in 7 dirs): -Codechange: remove ~50 includes from headers that weren't needed
20:27:34  <Eddi|zuHause> that sounds like breaking a number of patches :)
20:28:29  <CIA-6> OpenTTD: truebrain * r23736 /trunk/src/window_type.h: -Document: document correctly that WC_GOAL_QUESTION has a WindowNumber which is identical to the uniqueid given by the GameScript
20:29:51  <Zuu> What happens if you choose a uniqueid that is identical to another window class?
20:30:06  <Rubidium> class != number
20:30:38  *** fonsinchen [] has joined #openttd
20:30:43  <Zuu> oh, you are right. I read to quick.
20:32:01  <Rubidium> woohoooooo... I've taught andythenorth to be cryptic ;)
20:32:23  <Rubidium> well done my padawan ;)
20:32:34  <Eddi|zuHause> ;)
20:33:08  <Eddi|zuHause> imho all the diagonal roads, highways, etc. stuff could be done with "traffic objects" on top of the airport statemachines
20:34:03  <Eddi|zuHause> i.e. the newgrf will provide a (non-square?) area, a statemachine for vehicle movement, and a follow-track callback for the pathfinder
20:35:14  <Eddi|zuHause> as a side-feature we need a way to specify drag-able objects
20:37:57  <CIA-6> OpenTTD: truebrain * r23737 /trunk/src/ (97 files in 7 dirs): -Fix: fix the svn:properties of a few files that got added lately
20:38:42  <CIA-6> OpenTTD: truebrain * r23738 /trunk/src/ (4 files in 4 dirs): -Fix (r23731): forgot to sync the new window with the script API
20:40:16  * Rubidium smells misalignment in script_window.hpp
20:40:24  <TrueBrain> really?
20:40:40  <Rubidium> looks that way in the svn viewer
20:41:39  <CIA-6> OpenTTD: truebrain * r23739 /trunk/src/script/api/script_window.hpp: -Fix (r23738): owh vim, when can you learn to copy/paste tabs correctly?
20:43:51  <andythenorth> Eddi|zuHause: I shall await your patch :D
20:44:13  <andythenorth> TrueBrain your solution cheats :P
20:44:23  <TrueBrain> andythenorth: you didnt mention non-cheating-solutions :D
20:44:43  <andythenorth> you lose a lot of tile on one side to...'empty' :P
20:44:48  <andythenorth> big sidewalks?
20:44:54  <TrueBrain> I got this screenshot from one of the threads I linked
20:45:01  <TrueBrain> I tihnk it is edited in a paint application
20:45:16  <Zuu> andythenorth: Same amount is lost also for diagonal rails.
20:46:24  <TrueBrain> 90 degree turns on road .. now THAT would be funny to see
20:46:56  *** encoded [] has quit [Ping timeout: 480 seconds]
20:47:15  <Zuu> Is't that what we got in trunk?
20:47:36  <TrueBrain> the other 90 degrees darling
20:48:00  <__ln__> upwards?
20:49:19  <andythenorth> Zuu: town buildings don't try to build along diagonal rails in the same way ;)
20:49:43  <andythenorth> lots of small triangular parks?
20:49:51  <TrueBrain> lots of uglyness? :)
20:52:07  <Elukka>
20:52:14  <Elukka> diagonal roads in a similarly tile based game
20:52:19  <Elukka> just need some graphics to fill in the space
20:52:35  <TrueBrain> duallane
20:52:37  <TrueBrain> hmm
20:53:03  <andythenorth> 2 part diagonal buildings, with extended bounding box!?!?! :)
20:53:24  <Zuu> Actually, if there is enough bits, I think the diagonal roads of the image that TrueBrain posted could be just one lane to address the issue of them being narrow.
20:54:04  <TrueBrain> one lane diagonal would look better :P
20:54:31  <TrueBrain> but in the end, diagonal road is just a waste of tiles :)
20:54:47  <frosch123> did someone already make a mockup how 4 roadvehicles would fit onto a single tile?
20:55:25  <Eddi|zuHause> frosch123: that should be easy. a vehicle is 8px wide, a tile is 64px wide... plenty of room
20:56:32  * andythenorth will pay €500 for diagonal roads
20:57:04  <Elukka> i think diagonal roads would be very useful in the countryside, not so much inside towns
20:57:43  <Eddi|zuHause> the more important aspect is imho smoother curves (with less severe speed limits)
20:57:53  <TrueBrain> frosch123:
20:58:06  <TrueBrain> I can get more if you like :D
20:58:08  <TrueBrain> *troll*
20:58:30  <Rubidium> Eddi|zuHause: yes, we're in dire need of clothoids ;)
20:59:00  <Elukka> comedy suggestion: smooth rail curves
20:59:14  <Elukka> CETS would have sufficient sprite angles!
20:59:41  *** astol [~Adium@] has joined #openttd
20:59:51  <Yexo> TrueBrain: 4RV on one tile is much more trivial then your image leads to believe
20:59:59  <Eddi|zuHause> Elukka: i have an idea, but it needs more varaction2-variables for railtpyes...
20:59:59  *** Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20111228055358]]
20:59:59  *** astol [~Adium@] has quit [Read error: Connection reset by peer]
21:00:01  <TrueBrain> Yexo: I know :D
21:00:02  <Yexo> one RV is only half a tile long
21:00:05  <TrueBrain> briliant isnt it? :)
21:00:09  *** astol [~Adium@] has joined #openttd
21:00:15  <Aali> is the autonightly server still operating?
21:00:18  <TrueBrain> Yexo: you do know you can even fit 100 RVs on a single tile, right? :)
21:00:37  <Yexo> TrueBrain: by disabling queuing?
21:00:42  <TrueBrain> Yexo: by using my tile
21:00:49  <Eddi|zuHause> with quantum effects :)
21:00:52  <Elukka>
21:00:56  <Elukka> really small wagons are kinda weird to draw
21:00:58  <TrueBrain> queing is pretty much broken :)
21:01:00  <Rubidium> Aali: what/which autonightly server?
21:01:07  <Zuu> Aali: I haven't seen dihedral lately.
21:01:26  <Aali> Rubidium: dihedrals
21:01:28  <Aali> I see
21:01:40  <Aali> website is down and I dont remember the address
21:01:44  <Aali> guess its dead
21:02:00  <TrueBrain> Yexo: RV queue only checks what is in the direction of the vehicle
21:02:04  <Zuu> He is here in the channel though.
21:02:06  <TrueBrain> which kinda fails when they are turning
21:02:09  <TrueBrain> and they just merge into eachother
21:02:11  <Eddi|zuHause> last i heard of dihedral was "i need a new job" :p
21:02:15  <andythenorth> Elukka: that's not small :)
21:02:24  <Zuu> @seen dihedral
21:02:24  <DorpsGek> Zuu: dihedral was last seen in #openttd 4 days, 11 hours, 1 minute, and 49 seconds ago: <dihedral> it is 6am in YOUR timezone
21:02:28  <TrueBrain> so just run 100 RVs on a tile like mine, and they merge sooner or later into 1 smooth collision :)
21:02:37  <Elukka> heh
21:02:43  <Elukka> well you're better at drawing them :P
21:02:57  <Elukka> where it gets really odd is when it's wider than it's long on the 45 deg view
21:04:16  <Eddi|zuHause> that should only be for 3lu wagons
21:05:25  <Elukka> yeah
21:05:36  <Elukka> the shorter variant of this wagon will look odd unloaded
21:05:50  <Elukka> two tiny 3 lu wagons separated by long empty space and a coupling bar
21:13:35  *** astol [~Adium@] has quit [Quit: Leaving.]
21:16:10  <Xaroth> frosch123: because it's not a custom compile?
21:19:06  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has quit [Ping timeout: 480 seconds]
21:19:27  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has joined #openttd
21:20:36  <andythenorth> Eddi|zuHause: traffic object newgrfs?
21:21:14  <andythenorth> is there a spec? :D :P
21:23:54  <Eddi|zuHause> there will be a spec, if you follow the steps i laid out :p
21:24:20  <andythenorth> so a traffic object can handle multiple vehicle types?
21:25:06  <Eddi|zuHause> possibly
21:25:43  <andythenorth> can a traffic object tile control vehicle speed?
21:25:48  <Eddi|zuHause> openttd currently contains one hardcoded traffic object: the lock
21:26:09  *** pjpe [] has joined #openttd
21:26:42  <andythenorth> can a traffic object count the number of vehicles on the tile?  Can it have registers?
21:26:46  * andythenorth plots pipelines
21:27:28  <Eddi|zuHause> a traffic object can do the same thing airports can do
21:29:56  <Yexo> openttd will get incredible slow if you try to use that for diagonal roads
21:30:58  *** Adambean [] has quit [Quit: Gone fishing]
21:31:13  <TrueBrain> even slower?! :D
21:31:17  <Eddi|zuHause> pathfinder callback may be evil
21:31:27  *** JVassie [~James@] has quit [Ping timeout: 480 seconds]
21:32:11  <Eddi|zuHause> and lots of details are missing
21:32:28  <andythenorth> Yexo: it's fine - TB will optimise it :)
21:32:29  <TrueBrain> rly?
21:32:32  <andythenorth> just have to get him sick again
21:32:40  <TrueBrain> lol
21:32:41  <TrueBrain> :)
21:32:57  <CIA-6> OpenTTD: rubidium * r23740 /trunk/src/ (153 files in 10 dirs): -Codechange: remove some 300 unneeded includes from the .cpp files
21:33:22  <Yexo> andythenorth: one of the conclusions from all the profiling: newgrfs make things slow, but that can't be optimized away
21:33:23  <Xaroth> 153 files? :O
21:33:35  <TrueBrain> no worries; we have scripts :P
21:33:36  <Yexo> just following the spec means quite some code has to be executed
21:34:56  <andythenorth> change the spec
21:35:05  <Yexo> doesn't help
21:35:06  <andythenorth> reimplement everything
21:35:08  <andythenorth> in xml
21:35:38  <Rubidium> could be done, together with xsl ;)
21:35:41  <Yexo> the code already is quite fast for what is does, but any kind of "scripting" (which is what newgrfs are) will always be "slow" compared to native code
21:36:43  <andythenorth> the good news - changing the topic - is that I have this book:
21:36:59  <iddqd> when creating a new level (through game/gui) there are a bunch of options like size of map etc. When I start my dedi server, it does not start with the settings I picked in the game.
21:37:32  <iddqd> openttd.cfg is this the file I can find all the options in?
21:37:46  <andythenorth> the internet is quite short of good information
21:37:50  <andythenorth> at least wrt trucks
21:37:54  <andythenorth> books for the win
21:38:23  <Eddi|zuHause> iddqd: yes, but you can also create a game in singleplayer, save it, and load it onto the server
21:38:43  <iddqd> ah of course right
21:38:43  <iddqd> i’ll do that
21:42:32  <TrueBrain> This may come to you as a surprise since we have not met before.I have
21:42:33  <TrueBrain> made a deep and careful findings and reseach before contacting you and
21:42:35  <TrueBrain> believe you are related to this person. Can i please seek your consent
21:42:36  <TrueBrain> to present you to the bank as next of kin to our deceased costomer?
21:43:30  <andythenorth> TrueBrain: ok, fine by me
21:43:33  <andythenorth> how much do you need?
21:43:37  <Eddi|zuHause> i never get this kind of entertainment :(
21:43:42  <iddqd> paypal: gibemonieplox@gmail.comv
21:43:59  <TrueBrain> andythenorth: 500 euros :P
21:45:09  <frosch123> Eddi|zuHause: i can also forward you some contacts to russian/ukrainian girls from time to time, if you are interested
21:45:14  <andythenorth> Congrats!
21:45:14  <andythenorth> You've been personally selected to
21:45:14  <andythenorth> receive access to this ,407/a day
21:45:14  <andythenorth> software for no charge!
21:45:15  <andythenorth> Access here to access your exclusive download:
21:45:44  <frosch123>
21:47:02  <CIA-6> OpenTTD: rubidium * r23741 /trunk/src/ (5 files): -Revert (r23740): the few parts that the Windows / non-network compiles stumble on
21:47:19  <Eddi|zuHause> pffft :p
21:47:43  * andythenorth has failed to make BANDIT :[
21:48:53  <frosch123> start ROBBER instead?
21:49:10  <andythenorth> what is it?  A traffic objects grf?
21:49:58  <Guest22511> frosch123: :D
21:50:02  *** Guest22511 is now known as Markk
21:50:54  <frosch123> andythenorth: might be
21:51:11  * andythenorth concludes that trucks were rubbish before about 1940
21:51:18  <andythenorth> mostly <10t capacity
21:51:20  <andythenorth> lame
21:52:09  <frosch123> the same holds for rail wagons, doesn't it?
21:52:10  <Eddi|zuHause> you have trams before that :)
21:52:27  *** enr1x_ [] has joined #openttd
21:52:40  <andythenorth> frosch123: dunno if you noticed, you can have more than one wagon per train ;)
21:52:48  <Eddi|zuHause> frosch123: rail wagons of ~1900 typically have 15t capacity
21:54:15  *** enr1x [] has quit [Ping timeout: 480 seconds]
21:55:54  *** astol [~Adium@] has joined #openttd
21:58:27  <CIA-6> OpenTTD: rubidium * r23742 /trunk/src/cmd_helper.h: -Revert (r23735): for some reason gcc-trunk is more picky than basically everything else :(
21:58:56  * andythenorth somewhat overlooks RL weights
22:00:14  <andythenorth> also
22:00:15  <andythenorth> bed time
22:00:16  <andythenorth> bye
22:00:18  *** andythenorth [] has quit [Quit: andythenorth]
22:04:13  <CIA-6> OpenTTD: frosch * r23743 /trunk/src/vehicle_cmd.cpp: -Fix [FS#4906]: Call CB 15E for all vehicles before actually executing any refit.
22:08:28  <michi_cc> Eddi|zuHause: Why do I have the feeling that your railtype curve idea is similar to what I had as an idea? :)
22:09:01  <Eddi|zuHause> my idea isn't exactly new...
22:09:36  <michi_cc> It's not very hard code-wise if you limit the smooth part to half the track length on each tile.
22:09:52  <Eddi|zuHause> yes
22:10:11  <Eddi|zuHause> but you need to construct the sprite of two parts
22:10:37  <Eddi|zuHause> or more
22:11:32  <Eddi|zuHause> and you need to cache the sprite in the tile, otherwise the varaction2 evaluation takes too long for each draw
22:11:45  <michi_cc> The main blocker why I didn't code anything is that a) there are several ways to provide the needed info to the NewGRF, and I don't know which is the best because b) I utterly failed at trying to draw even one smooth curve, so I don't know how an artist would draw best.
22:14:40  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has quit [Ping timeout: 480 seconds]
22:16:22  *** Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
22:16:27  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has joined #openttd
22:17:21  <Eddi|zuHause> while speaking about railtypes: can i have a coord-variable so i can do (x+y)%4-style sprite variation?
22:17:56  <Eddi|zuHause> (similar to how catenary pylons are placed)
22:18:53  <planetmaker> when railtypes were implemented that was explicitly decided to not supply
22:19:03  <planetmaker> on grounds of possible performance impact
22:19:50  <Eddi|zuHause> and i always disputed that claim on grounds of the catenary code doing the same calculations
22:20:28  <Terkhen> good night
22:20:54  <planetmaker> I mean... many things are possible. And arguabley things like townzone would be an interesting thing, too
22:21:11  <planetmaker> for example in order to provide different fences then
22:22:58  <planetmaker> Eddi|zuHause: you have though a tile-coordinate variable via the two pseudo-random bits
22:23:35  <Eddi|zuHause> planetmaker: but it's a pseudo-randomized variable, not a regular one
22:23:58  <planetmaker> it's the least significant bits of the coordinate
22:24:09  *** encoded [] has joined #openttd
22:25:12  *** Progman [] has quit [Remote host closed the connection]
22:25:16  <Rubidium> it's the (x+y)%4-ish code that's used for trees
22:25:46  <Rubidium> but seemingly slightly more random so you don't easily see that it's repeating every 4 tiles
22:25:56  <michi_cc> I know we didn't implement it, but I don't think the performance impact would be that big. Catenary code is ridiculously expensive for small visual reasons (drawing a single catenary sprite will look at *13* map tiles), and still nobody noticed a slowdown from that.
22:27:02  <Rubidium> I think it was "land info of nearby tiles" that got dismissed
22:27:07  <michi_cc> (24 tile accesses actually, but only 13 unique tiles)
22:34:59  <Eddi|zuHause> for curvy rails i only need the 4 adjacent tiles, with some bitstuffing
22:35:55  <planetmaker> actually writing a patch, Eddi|zuHause? ;-)
22:36:16  <Eddi|zuHause> and the (x+y)%4 i need to place a km-stone every 2 tiles
22:36:38  <CIA-6> OpenTTD: frosch * r23744 /trunk/src/train_cmd.cpp: -Fix (r23142) [FS#4923]: Check the version of the right GRF.
22:37:07  <Rubidium> Eddi|zuHause: that's so unreal...
22:37:35  <Eddi|zuHause> DB places a plate every 200m
22:37:41  <Rubidium> then if I move my rail around a (new) station the kms would change
22:38:00  <Rubidium> Eddi|zuHause: if only those 200m would be really 200m...
22:38:12  <Rubidium> they're mostly on catenary masts, which are 70m apart
22:38:38  <Eddi|zuHause> yes, but the exact offset to the real 200m is written on the plate
22:38:43  <Rubidium> also... 200m "track kilometers" can easily be 300m in the real world
22:39:10  <michi_cc> Eddi|zuHause: Why 4? If each track bit is overlaid separately you only need the two tiles at each end.
22:40:11  <Eddi|zuHause> michi_cc: i mean 4 for the whole tile, not each trackbit
22:40:29  <iddqd> after each savegame my buddy timeouts
22:40:43  <iddqd> is there a console command that lets one timeout longer
22:40:59  <Eddi|zuHause> opposing to "land info of nearby tiles", which smells like potentially a 32x32 area
22:41:30  <Eddi|zuHause> iddqd: the timeout is 4 game days (ca. 10 seconds)
22:41:45  <iddqd> yeah
22:41:50  <iddqd> can i increase that time?
22:41:52  <michi_cc> Eddi|zuHause: I'm not sure drawing each tile as one sprite would make sense, that's a lot of sprites the NewGRF would need to provide.
22:41:54  <iddqd> to let’s say 25 seconds
22:41:54  <Eddi|zuHause> iddqd: only way around that is to disable autosave, or pause the game during that time
22:42:09  <iddqd> :(
22:42:14  *** Timmaexx [] has joined #openttd
22:42:21  <Eddi|zuHause> iddqd: i think the timeout is hardcoded
22:44:43  <michi_cc> Eddi|zuHause: Can you make a scheme how you'd select the proper sprite for each tile/track bit?
22:45:53  <Eddi|zuHause> hm...
22:48:36  <michi_cc> Ideally that scheme would select different sprite sheets with the same layout as currently (i.e. )
22:49:09  <peter1138> idkfa
22:49:14  <peter1138> idspispopd :S
22:49:48  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
22:52:02  <iddqd> no cheating please
22:52:03  <iddqd> only me
22:53:15  *** Zuu [] has quit [Ping timeout: 480 seconds]
22:55:52  *** fonsinchen [] has joined #openttd
22:57:36  *** KingJ [~KingJ-OFT@] has joined #openttd
22:58:18  *** DDR [~chatzilla@] has joined #openttd
22:58:54  <michi_cc> Actually, you'd always need overlay tracks for PBS reservations, so it would make sense to keep the current overlay method for junction tiles.
22:59:09  *** KouDy [~KouDy@] has quit [Quit: Leaving.]
23:02:13  *** TGYoshi [~TGYoshi@] has quit [Quit: Popidopidopido]
23:06:08  *** fonsinchen [] has quit [Remote host closed the connection]
23:06:25  *** astol [~Adium@] has quit [Quit: Leaving.]
23:06:57  *** michi_cc [] has quit [Ping timeout: 480 seconds]
23:08:16  <CIA-6> OpenTTD: frosch * r23745 /trunk/src/vehicle_cmd.cpp: -Fix (r23087): If autorefit fails, count the vehicle capacity nevertheless, if it is already carrying the right thing.
23:09:49  <CIA-6> OpenTTD: truebrain * r23746 /trunk/src/ (ai/ai_core.cpp game/game_core.cpp): -Fix: also set 'info' to NULL if 'instance' dies (for both AI and GS); avoids invalid memory reads
23:12:07  <planetmaker> g'niht
23:12:16  *** michi_cc [] has joined #openttd
23:12:19  *** mode/#openttd [+v michi_cc] by ChanServ
23:12:59  *** Alberth [] has left #openttd []
23:13:55  <CIA-6> OpenTTD: truebrain * r23747 /trunk/src/game/game_core.cpp: -Fix (r23746): forgot one more case
23:15:55  <frosch123> refit orders with cargo subtypes are a misfeature :(
23:16:06  *** saua [] has quit [Read error: Connection reset by peer]
23:16:29  *** saua [] has joined #openttd
23:17:12  <Eddi|zuHause> michi_cc: if we could select the sprite on a half-track basis, it could be a 2-step decision like this: for "full" trackbits and switches etc., some combinatorial stuff is needed (means larger switches, not more steps)
23:17:32  *** TdlQ_ [] has quit [Ping timeout: 480 seconds]
23:20:57  <Eddi|zuHause> (there's some potentially evil exponentiation there for the number of sprites needed)
23:25:28  *** snack2 [] has quit []
23:25:39  <michi_cc> Indeed, it's quite a lot of sprites, but not that many to be unmanageable.
23:26:04  *** DayDreamer [] has quit [Quit: Leaving.]
23:41:31  *** sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
23:42:10  *** Devroush [] has quit []
23:42:58  *** FLHerne [] has joined #openttd
23:45:42  *** KritiK [] has quit [Quit: Leaving]
23:48:15  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has quit [Ping timeout: 480 seconds]
23:49:28  *** fjb|tab [] has joined #openttd
23:53:54  <CIA-6> OpenTTD: frosch * r23748 /trunk/src/newgrf_engine.cpp: -Fix: Make vehicle variables A8 and A9 always return 0. Returning cur_image is a potential desyncer due to Action1 in static NewGRFs.
23:54:51  <Yexo> ah! you finally found a good reason to remove it :)
23:55:00  <frosch123> :)
23:55:36  <frosch123> i wonder whether someone used it as pseudo random value :p
23:57:32  *** Timmaexx [] has quit [Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912]]
23:58:31  *** kkb110 [~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU] has joined #openttd

Powered by YARRSTE version: svn-trunk