IRC logs for #openttd on OFTC at 2012-01-03
⏴ go to previous day
00:22:16 <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:44:25 <CIA-6> OpenTTD: yexo * r23723 /trunk/src/ (object_cmd.cpp water_cmd.cpp): -Codechange: speedup flood checks a bit
00:45:23 <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:45:59 <Yexo> ^^ with huge thanks to TrueBrain for the actual profiling part
00:47:17 <TrueBrain> just compile before commit etc ;)
00:47:59 <CIA-6> OpenTTD: yexo * r23725 /trunk/src/water_cmd.cpp: -Fix (r23723): compile before commit
00:49:32 *** MagisterQuis has joined #openttd
00:49:53 <Aali> so uh, on my box, threaded drawing prevents the game from doing.. anything at all really
00:50:22 <TrueBrain> in 23721? As in, since that revision?
00:50:33 <TrueBrain> or just a random one that fails?
00:50:38 <Aali> it just sits there, waiting on the mutex
00:51:12 <TrueBrain> make a bug report I say?
00:51:16 <TrueBrain> including OS, CPU, ..
00:52:01 <Aali> not a known problem then? alright
00:52:12 <TrueBrain> I think that would be a critical error if it was common :D
00:52:28 <glx> happens at game launch sometimes
00:52:30 <TrueBrain> my reply would have been: see r<version> :D
00:52:51 <TrueBrain> glx: 1 out of the 20 runs in MSVC Debug never starts for me
00:52:56 <TrueBrain> never comes out of kernel initializing I believe
00:53:20 <glx> sometimes it deadlocks in MSVC for me
00:54:39 <Aali> looking at the code, I dont see how it could ever work
00:55:24 <Aali> it takes the mutex, creates the thread then waits for the signal
00:55:50 <Aali> while the thread takes the mutex then signals
00:56:05 <michi_cc> WaitForSignal() automagically unlocks the mutex
00:56:26 <Aali> ah yes of course it does
00:56:29 <michi_cc> and reacquires it upon return
00:56:50 <Aali> and then forgot it 5 minutes later
01:00:43 <Eddi|zuHause> damnit... two days in a row i hit the forum-backup time...
01:03:06 <Aali> okay, there it is, the draw thread is eating its own signal
01:04:41 <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:13:21 <michi_cc> So which OS are you talking about?
01:17:21 <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:17:53 <Aali> I'm thinking you should always prevent a thread from eating its own signal
01:17:58 <Aali> no matter how its scheduled
01:18:17 <Aali> the sleep is nothing more than a workaround
01:19:07 <Aali> I'm not sure how it works on other OSes
01:19:20 <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:19:28 <TrueBrain> on Linux I can see issues with some weird scheduler :P
01:19:31 <TrueBrain> on Windows ... odd :)
01:19:42 <TrueBrain> anyway, night for me :)
01:20:05 <Aali> michi_cc: well, the other thread isn't waiting at that point
01:20:25 <Aali> it gets stuck waiting for the draw thread to signal (later)
01:20:54 <Aali> since the draw thread both sent a signal and then reset it all in one go
01:21:08 <michi_cc> If it is not already waiting, it's not SendEvent that is broken, but the thread initialization/creation.
01:21:19 <michi_cc> (the OpenTTD code I mean, not windows)
01:22:52 <Aali> how could you make sure the main thread is waiting before starting the draw thread?
01:23:38 <Aali> not saying you can't, I just dont see how
01:24:57 <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:25:22 <Aali> yeah but then the main thread releases the mutex before waiting
01:26:51 <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:27:08 <Aali> apparently its causing trouble
01:27:16 <michi_cc> We should use a condition variable for that, but these are only available starting with Vista.
01:27:19 <Aali> I can reproduce it every time (so far)
01:28:07 <michi_cc> Then you have some very strange system, because this cause is *very* rare.
01:29:51 <michi_cc> And even a Sleep(0) isn't guaranteed to switch threads.
01:33:41 <Aali> to be fair, I only tried like 5 times
01:33:53 <Aali> this is a debug build by the way
01:40:55 *** Biolunar has joined #openttd
01:44:04 <Aali> release build works better, only happened once there
01:44:20 <Aali> explains why there haven't been many complaints about this
01:45:27 <glx> debug builds are slower, easier to trigger race condition in this case
01:49:10 <Aali> shouldn't make that much of a difference here..
01:50:07 <Aali> unless there's some wonderful misfeature that changes the behavior of critical sections in a debug build
01:51:25 *** encoded has joined #openttd
02:38:37 <CIA-6> OpenTTD: peter1138 * r23726 /trunk/src/blitter/32bpp_anim.cpp: -Fix (r23670): Remove debugging code added accidentally
02:44:53 *** Eddi|zuHause has joined #openttd
03:54:30 <Aali> is the autonightly server still operating?
04:16:03 *** dotwaffle has joined #openttd
05:16:35 <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:18:23 <ohnoes> does anyway know why this is happenning?
05:21:10 <ohnoes> wrong tunnel type! that is probably the problem
05:27:15 *** kkb110__ has joined #openttd
05:46:27 <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:49:48 <Elu> yeah, but you can turn off expiration dates somewhere in advanced settings
05:56:21 *** Eddi|zuHause has joined #openttd
06:28:24 *** JVassie has joined #openttd
06:34:09 *** DayDreamer has joined #openttd
06:53:36 *** Twofish has joined #openttd
07:09:10 *** sla_ro|master has joined #openttd
08:03:58 *** Devroush has joined #openttd
08:35:03 *** Progman has joined #openttd
09:29:23 *** TGYoshi has joined #openttd
09:34:27 *** DayDreamer has left #openttd
09:46:39 <CIA-6> OpenTTD: truebrain * r23727 /trunk/src/blitter/32bpp_anim.cpp:
09:46:39 <CIA-6> OpenTTD: -Codechange: speedup the 32bpp palette animation by reducing the amount of
09:46:39 <CIA-6> OpenTTD: compares. This is possible because the function is called with only 2 possible
09:46:39 <CIA-6> OpenTTD: conditions: from 0 to 255 (full palette update, 8bpp only) or from
09:46:39 <CIA-6> OpenTTD: PALETTE_ANIM_START to 255
10:07:34 *** fjb|tab is now known as Guest22544
10:07:35 *** fjb|tab has joined #openttd
10:23:54 <appe_> morning mr makerplanet.
10:27:18 <CIA-6> OpenTTD: truebrain * r23728 /trunk/src/company_cmd.cpp: -Fix [#FS4942-ish]: when cheating into another company, the SignList was not updated
10:50:08 <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
11:11:36 <__ln__> good new year twothousandonetwo, Wolf01
11:32:18 *** Darkvater has joined #openttd
11:32:18 *** ChanServ sets mode: +o Darkvater
11:32:46 *** Darkvater has joined #openttd
11:32:46 *** ChanServ sets mode: +o Darkvater
11:32:55 *** Darkvater has left #openttd
11:34:58 <Mazur> Oh, my lordy, lordy, lord....
11:35:09 <Mazur> I just got 24" in the mail...
11:35:33 <Mazur> I'll be gone for a bit to amuse myself with it, shortly.
11:36:17 * __ln__ continues working with his dual-24" configuration at work
11:36:49 <appe_> does anyone of you use C# alot?
11:39:16 <Yexo> I've used it a bit over the last few months
11:39:20 <appe_> and im making an if statement
11:39:31 <appe_> and i need to search with a wildcard
11:39:50 <appe_> well, not search, really.
11:40:13 <Yexo> <appe_> im a complete newbie <- with C# or programming in general?
11:40:30 <appe_> if (myReader["cust_ed3"].ToString() == "text")
11:40:40 <appe_> that is the row of code i need to change. i didnt write that myself.
11:41:00 <appe_> i want "text" to be something like *text*
11:41:23 <peter1138> something like *text*?
11:41:24 <Yexo> if (myReader["cust_ed3"].ToString().Contains("text")) {
11:43:03 <appe_> i have no experience what so ever in code
11:50:21 *** tokai|noir has joined #openttd
12:03:00 *** fjb|tab has joined #openttd
12:05:02 <vb> how to start a game with newgrf settings applied?
12:05:45 <Yexo> apply newgrf settings from main menu, start new game
12:05:56 <vb> i did so, i only had some industries
12:06:05 <vb> even though the newgrf was applied
12:06:15 <Yexo> upload your savegame somewhere
12:08:36 <vb> i have ECS & FIRS original vehicle set, i think that is only for cargo
12:08:52 <Yexo> if you want the default vehicles with refit options, try OpenGFX+
12:09:22 <Yexo> in that case use a different trainset
12:09:35 <Yexo> every complete trainset I know can refit to the firs/ecs cargoes
12:09:38 <vb> what is the best newgrf setting for a singleplayer game?
12:09:51 <Yexo> there is no single best setting
12:09:58 <Yexo> it all boils down to personal preferences
12:12:06 *** kkb110_ has joined #openttd
12:13:22 <vb> what trainset do you recommend?
12:20:03 <V453000> it depends on what you want to play, try yourself :) discovering all the joys by yourself is best after all
12:20:58 <V453000> UK Renewal Train Set might be the exact name
12:21:06 <V453000> maybe without the Train
12:21:23 <V453000> the UKRS2 is awesomely drawn but lacks some variety in compare to the 3.04
12:21:34 <vb> should i also get the addon pack?
12:21:57 <Ammler> best is if you load at least 50 newgrfs
12:22:46 <planetmaker> irony carries badly
12:22:54 <vb> i have at least 461 hours of openttd played
12:22:58 <Mazur> That way you get at least all the necessary NewGRF conflicts we want to know about.
12:23:10 <V453000> I have about over 9000 millions hours of openttd player :p
12:23:58 <Mazur> I even have over 10 hours!
12:24:10 <Ammler> vb: it could be fun to find your personal best newgrf yourself
12:24:40 <V453000> exactly as Ammler says :)
12:29:59 <vb> i want some competition :)
12:30:33 *** TomyLobo has joined #openttd
12:32:39 <Ammler> or else, same with AI as with newgrfs, find it yourself :-P
12:34:46 <Yexo> you'll still have to try some to see what works for you
12:35:04 <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:44:35 *** andythenorth has joined #openttd
12:44:43 *** Guest22251 is now known as AD
12:46:09 *** frosch123 has joined #openttd
12:53:53 <Eddi|zuHause> *mental note* amarok's OSD will not display the correct title while i'm playing radio in kaffeine...
13:50:49 *** Remi_Woler has joined #openttd
13:57:38 <Hirundo> It's still WIP, before I continue I'd like some input on a few conceptual issues
13:59:10 <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:59:49 <Eddi|zuHause> presets should be separate from static grfs
14:01:01 <planetmaker> Hirundo: presets should not care about static NewGRFs
14:01:25 <Hirundo> So presets affect normal grfs only, and when the user is editing the static grf list, the preset buttons are disabled
14:01:25 <planetmaker> I'm not sure whether it's better to split static and non-static config.
14:01:46 <planetmaker> I'd first try it in the same window. With possibly differently coloured entries or a checkbox
14:01:51 <planetmaker> behind each newgrf
14:02:25 <Hirundo> I currently made two tabs on the active newgrf list in the newgrf settings window
14:02:47 <planetmaker> ah, you made a separate tab. I'm fine either way
14:02:53 <planetmaker> it's less work that way, probably
14:03:52 <Ammler> shouldn't openttd be able to detect "static" newgrfs?
14:04:18 <Hirundo> It is able to test if a grf is safe for static usage
14:04:52 <Ammler> Eddi|zuHause: well, it would mean, you do not need any manual selection of it
14:05:12 <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
14:05:15 <Eddi|zuHause> just because a grf can be static, doesn't mean you want it to be
14:05:36 <Eddi|zuHause> e.g. german signals grf
14:05:45 <Eddi|zuHause> i wouldn't want that in a UKRS preset
14:06:19 <planetmaker> Ammler: it's much better if you can select the static newgrfs to use
14:06:33 <planetmaker> or you'd have ALL tree newgrfs. ALL signal newgrfs. And ALL landscape replacement sets
14:06:40 <Ammler> s/better/easier/, of course
14:06:52 <frosch123> if we transfer the newgrf settings to the "start new game" window, then static newgrfs would be moved to the "options"
14:07:07 <frosch123> e.g. next to the basesets
14:07:13 <frosch123> and not in the same window as newgrfs
14:07:24 <Ammler> the advantage would be that you for example could also disable a static grf loaded on a mp server
14:08:04 <frosch123> you cannot disable static grfs in a running game, you would have to do that before joining
14:08:27 <Ammler> frosch123: yes, now, that's the point :-)
14:08:38 <Eddi|zuHause> you cannot unload a grf if it is loaded non-statically by the server
14:08:41 <Hirundo> That gets you into trouble if other non-static grfs depend on that static-but-non-statically-loaded newgrf
14:08:45 <Eddi|zuHause> even if that grf could be static
14:09:19 <Ammler> well, the question is is there need to load a static grf as non-static?
14:09:32 <Eddi|zuHause> you can, however, make a static grf that counteracts the effects of the other non-static grf
14:09:41 <frosch123> yes, if non-static grfs depend on static grfs
14:10:06 <frosch123> afternoon terkhen :)
14:10:15 <Eddi|zuHause> Ammler: some canadian station grf checks for presence of the dutch catenary grf
14:10:27 <Eddi|zuHause> Ammler: at that point, dutch catenary cannot be static anymore
14:10:37 <Eddi|zuHause> even if by itself it could
14:12:33 <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:12:59 <planetmaker> Hirundo: that'd mean really reading the NewGRFs completely
14:13:05 <Ammler> but the whole point about static grf is for MP, you agree?
14:13:21 <Eddi|zuHause> the grfs must be read once for md5sum anyway
14:13:21 <Hirundo> AFAIK, safety scan aborts at the first action0/3
14:13:22 <planetmaker> And: static yes/no can depend on the active NewGRF list (e.g. query for the static one)
14:13:30 <Eddi|zuHause> as long as the result is cached...
14:13:49 <planetmaker> well. Startup is not exactly instant with many newgrfs
14:13:59 <Hirundo> planetmaker: that part of the safety scan is executed only when starting a game, afaik
14:14:03 <planetmaker> I just wonder whether this scan should happen threaded in background
14:14:18 <Ammler> so the only time, you need static grf is when you join a MP game
14:14:42 <Eddi|zuHause> Ammler: static grfs also "survive" a preset change
14:14:53 <Eddi|zuHause> (at least they should)
14:15:07 <Eddi|zuHause> Ammler: or loading a scenario
14:15:25 <Ammler> ok, but that might not need to be static, that could be called "global" or so :-)I
14:15:44 <Ammler> does not need to be static grfs only
14:15:52 <Eddi|zuHause> just because you don't see the use-case, doesn't mean it doesn't exist
14:15:57 <Ammler> but for MP, you can only use static grfs
14:16:07 <Eddi|zuHause> Ammler: yes, for scenarios only static grfs can be changed
14:17:11 <Ammler> Eddi|zuHause: mäh, you discuss newbie scenario
14:17:42 <Eddi|zuHause> i discuss scenarios for 99% of the user base
14:19:02 <Ammler> you should talk for yourself :-P
14:19:38 <Eddi|zuHause> Ammler: i'm not in the target group for a static-newgrfs-gui
14:20:48 <Hirundo> Editing config files and hard-coding grf locations and parameters can be intimidating for many :-)
14:21:18 <Ammler> nobody does that anymore
14:21:35 <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:21:43 <Hirundo> Not exactly a user-friendly process
14:22:20 <Ammler> well, the use for static grfs was high as you had to configure newgrfs via cfg
14:22:38 <Ammler> since there is the newgrf gui, most play with what they got
14:24:18 <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:29:25 <Hirundo> So, having a GUI for static NewGRFs makes sense, assuming that static NewGRFs make sense in the first place
14:30:33 <Ammler> the possiblity to add/remove grfs which don't affect gameplay on a running game makes sense
14:30:44 *** supermop_ has joined #openttd
14:31:06 <Ammler> from my view the only usecase for it, as Eddi|zuHause mentioned, there could be another use case :-)
14:32:32 <Hirundo> Are static newgrfs completely safe to add/remove even during a running game (w/o restart)?
14:33:19 <Ammler> well, it depends how you handle those static grfs, which become non-static :-)
14:34:16 <Ammler> but if you restart the game anyway, why do you need static grfs?
14:35:15 <Hirundo> Currently you need to restart openttd to change static newgrfs
14:35:36 <Ammler> or do you call joining a server a restart?
14:35:47 <Hirundo> Does that change static newgrfs?
14:36:59 <Hirundo> They are just applied (or not, if they turn out to be unsafe), not changed during a live game
14:37:19 <Ammler> you can join with different static configs
14:38:44 <Hirundo> but you cannot currently change the grfs with all other grfs already loaded, you just load a different config
14:39:26 <Eddi|zuHause> which means you need to make a temporary save and reload it
14:39:35 <Ammler> Hirundo: yes, but you do not restart the game
14:39:55 <Hirundo> Currently you have to restart openttd, thereby clearing all in-memory stuff
14:40:27 <Hirundo> Changing hot memory might or might not cause new problems, I don't know for sure
14:40:28 <Ammler> yes, you might need to restart the client, but the game still runs on the server
14:40:51 <Eddi|zuHause> i don't think you two are talking about the same thing :)
14:40:56 <frosch123> Hirundo: adding static grfs requires to reload all grfs, i.e. means to reload a game resp. rejoin a game
14:41:42 <Hirundo> frosch123: reload also in single player?
14:42:24 <Hirundo> or is ReloadNewGRFData() enough?
14:42:47 <Eddi|zuHause> is that he function that is run when clicking "apply newgrfs"?
14:43:36 <frosch123> Hirundo: problem with the latter is that engine reliability is reset
14:44:18 <frosch123> (well, the same happens on "apply newgrfs" or "reload_newgrfs")
14:44:37 <frosch123> but for static newgrfs it is safe to not reset engines :p
14:45:10 <Eddi|zuHause> that function could use a sandbox to check what actually changed
14:45:35 <frosch123> yeah, one might only reset the engines of grfs which actually changed
14:45:54 <frosch123> though that fails if the engines depend on other grfs being present :p
14:45:55 <Eddi|zuHause> well, grf-order may have influence
14:46:13 <Hirundo> And perhaps other random data except reliability
14:46:15 <Eddi|zuHause> that's why a sandbox is needed
14:46:42 <Eddi|zuHause> create new newgrf config -> compare available engines -> resetengines
14:46:44 <Hirundo> frosch123: grfid checks on static grfs disable the static grf for that reason
14:47:16 <frosch123> yes, thus it is safe to preserve reliability when changing static grfs, but not when changing other grfs
14:47:24 *** alluke_ has joined #openttd
14:48:08 <Eddi|zuHause> but the sandbox would also cover cases where e.g. only station grfs were changed
14:49:07 <Mazur> Ok, everybody line up next to eachother.
14:49:30 <Mazur> No, no need to scrunch up, use the space you want, I gots jme the pixels.
14:50:14 <SpComb> you're missing a few pixels off the bottom, it seems
14:50:38 <Mazur> Well, I did not have money for more.
14:50:48 <BUTTMUNCH> ya i have, i also have the gui double thing
14:51:00 * Mazur takes a dump on BM's face.
14:51:06 <SpComb> no, it's just computer monitor manufacturers thinking that marketing video resolutions for computer displays is a good idea
14:52:28 <Eddi|zuHause> with the whole HDTV hype, suddenly computer monitors stopped developing
14:52:48 <Eddi|zuHause> last time i searhced, it was really difficult to find monitors with higher resolutions
14:53:27 <Eddi|zuHause> it contradicts moore's law
14:53:49 <BUTTMUNCH> in the next 2 years you’ll see better ppi monitors
14:54:25 *** DayDreamer has joined #openttd
15:10:50 <vb> how do i make towns smaller?
15:12:18 <BUTTMUNCH> is there a clear reason why someone would timeout from my server every 5 minutes?
15:13:26 <BUTTMUNCH> we run other games together and they run fine
15:14:05 <BUTTMUNCH> we run other games together and they run fine
15:14:43 <vb> how do i make towns smaller? when i start a new game
15:14:57 <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:15:13 <planetmaker> ^^ see the similarity, BUTTMUNCH ?
15:15:23 <BUTTMUNCH> in this case the ferrari is game 1
15:15:26 <BUTTMUNCH> and the landrover is game 2
15:15:38 <BUTTMUNCH> the road would be my router
15:15:44 <planetmaker> they use different protocols, different ports. Differently shaped traffic
15:16:01 <BUTTMUNCH> i bet openttd uses traffic shaped like penises
15:16:06 <BUTTMUNCH> my router is rather homophobic
15:16:17 <planetmaker> vb: set town sizes to small...
15:16:27 <vb> i still have some of 2000+ population
15:17:08 <vb> i also want even lower nr. of towns than very low
15:18:10 <planetmaker> then use the scenario editor to manually place towns
15:18:10 <BUTTMUNCH> and fill in a nyumber to your liking
15:27:22 *** yorick_ has joined #openttd
15:40:23 *** Adambean has joined #openttd
16:02:24 *** leeroberson has joined #openttd
16:02:28 *** leeroberson is now known as eberon
16:02:44 <eberon> hi all, quick gameplay question
16:03:18 <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?
16:03:35 <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?
16:04:17 <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
16:04:53 <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
16:05:04 <CIA-6> OpenTTD: rubidium * r23730 /trunk/ (5 files in 2 dirs): -Add: Australian translation
16:06:06 <eberon> planetmaker: awesome, cool, that's what I thought.
16:07:28 <andythenorth> needs a decent australian set :P
16:07:52 <andythenorth> I'll bring trucks
16:08:00 <andythenorth> where's pikka when you need him :D
16:08:54 *** supermop has joined #openttd
16:09:00 <TrueBrain> where are short URLs when you want them :P
16:10:01 <SpComb> most of that url is cruft, presumeably
16:10:24 <__ln__> it's possible it got truncated
16:10:53 <SpComb> probably just the ?q= bit would do
16:13:03 <andythenorth> ^ they need quantum effects when queueing
16:13:17 <andythenorth> also - note they're using drive-through roadstops, not drive-in ones
16:13:29 <andythenorth> they're probably waiting for NewStations too
16:36:26 <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:46:22 *** Prof_Frink has joined #openttd
17:05:37 <TrueBrain> CargoDist still fails on the CF ..
17:05:53 <Eddi|zuHause> and what's wrong?
17:10:16 *** encoded has joined #openttd
17:10:16 *** JoeyJo0 has joined #openttd
17:10:16 *** mikegrb_ has joined #openttd
17:10:16 *** jonty-comp has joined #openttd
17:11:31 *** andythenorth has joined #openttd
17:12:02 <Eddi|zuHause> so it only works for windows?
17:12:47 *** Biolunar has joined #openttd
17:24:34 *** andythenorth has joined #openttd
17:25:11 *** HerzogDeXtEr has joined #openttd
17:33:16 *** mahmoud has joined #openttd
17:38:02 *** KritiK_ has joined #openttd
17:38:03 *** KritiK_ is now known as KritiK
18:14:53 *** andythenorth has joined #openttd
18:19:56 *** fonsinchen has joined #openttd
18:33:10 *** |Jeroen| has joined #openttd
18:42:39 <TrueBrain> Eddi|zuHause: yes, and they are not published because the compilation fails for most targets :)
18:46:21 <CIA-6> OpenTTD: translators * r23732 /trunk/src/lang/ (13 files): (log message trimmed)
18:46:21 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:46:21 <CIA-6> OpenTTD: bulgarian - 7 changes by kokobongo
18:46:21 <CIA-6> OpenTTD: croatian - 3 changes by VoyagerOne
18:46:21 <CIA-6> OpenTTD: dutch - 20 changes by Yexo
18:46:22 <CIA-6> OpenTTD: english_US - 20 changes by Rubidium
18:46:22 <CIA-6> OpenTTD: finnish - 22 changes by jpx_
18:49:07 *** andythenorth has joined #openttd
18:57:03 *** Chris_Booth has joined #openttd
19:04:32 *** TheMask96 has joined #openttd
19:05:38 *** HerzogDeXtEr1 has joined #openttd
19:06:13 *** Alberth has joined #openttd
19:06:13 *** ChanServ sets mode: +o Alberth
19:10:21 <alluke> is there a way to disable the yellow ottd mouse
19:11:03 <alluke> this huge mp game is lagging my ass off and the mouse does so too making building anyhing impossible
19:11:51 <Eddi|zuHause> and what would using the system mouse solve?
19:12:21 <Alberth> buying a faster computer helps more though
19:12:32 <Yexo> alluke: buy a faster computer or use a smaller map with less vehicles
19:12:40 <Yexo> most of all: don't use any newgrfs or AIs
19:18:24 <alluke> and my computer is fast enough
19:19:01 <alluke> id prefer my own back mouse anyway
19:19:11 <Eddi|zuHause> so again, why is this the mouse pointer's fault?
19:19:39 <Rubidium> it's just a single line of code to give you your little black mouse
19:19:50 <Rubidium> and probably a hell of a lot more to get the other one not there anymore
19:19:53 <alluke> i could jsut let the background lag and build stuff like before
19:20:15 <Eddi|zuHause> hiding the other game pointer can be done with a static grf
19:20:45 <alluke> now wheres this little treasure
19:20:58 <Eddi|zuHause> you'll have to make one yourself
19:21:34 <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:21:43 <Yexo> and by hiding it you wouldn't stop it from functioning
19:22:17 <alluke> once there was a bug that put my original mouse above the game pointer
19:22:41 <CIA-6> OpenTTD: rubidium * r23734 /trunk/src/lang/ (51 files in 2 dirs): -Cleanup: remove the translated strings as well
19:22:52 <Eddi|zuHause> alluke: i still think you should rather be solving the actual problem, not doctoring some weird symptoms
19:24:21 <Eddi|zuHause> alluke: anyway, you need to modify the ClaimMousePointer() function of your video driver and compile, to get the system pointer drawn
19:24:37 <Ammler> isn't there a option to disable the mouse pointer or was that something in TTDP?
19:24:39 <Eddi|zuHause> and replace the game sprites with transparent ones
19:25:32 <Ammler> or maybe completely another game I have in mind :-)
19:25:39 <Eddi|zuHause> probably that :p
19:27:59 <Eddi|zuHause> backgammon is a weird game
19:28:38 <andythenorth> Eddi|zuHause is thinking of Dice Wars
19:33:20 <andythenorth> probably not a Dice Wars fan
19:35:22 <Eddi|zuHause> dice wars is the one where you capture countries?
19:37:57 <Eddi|zuHause> well, not exactly :)
19:38:18 <Eddi|zuHause> and in risk you "free" countries, because "capture" is too militaristic :p
20:13:52 <frosch123> Xaroth: why are you not running beta1 ? :p
20:26:08 <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:38 *** fonsinchen has joined #openttd
20:30:43 <Zuu> oh, you are right. I read to quick.
20:32:02 <Rubidium> woohoooooo... I've taught andythenorth to be cryptic ;)
20:32:23 <Rubidium> well done my padawan ;)
20:33:09 <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:58 <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:43 <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:17 * Rubidium smells misalignment in script_window.hpp
20:40:41 <Rubidium> looks that way in the svn viewer
20:41:40 <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:52 <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:44 <andythenorth> you lose a lot of tile on one side to...'empty' :P
20:44:54 <TrueBrain> I got this screenshot from one of the threads I linked
20:45:02 <TrueBrain> I tihnk it is edited in a paint application
20:45:17 <Zuu> andythenorth: Same amount is lost also for diagonal rails.
20:46:25 <TrueBrain> 90 degree turns on road .. now THAT would be funny to see
20:47:15 <Zuu> Is't that what we got in trunk?
20:47:36 <TrueBrain> the other 90 degrees darling
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:52 <TrueBrain> lots of uglyness? :)
20:52:14 <Elukka> diagonal roads in a similarly tile based game
20:52:20 <Elukka> just need some graphics to fill in the space
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:05 <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:26 <Eddi|zuHause> frosch123: that should be easy. a vehicle is 8px wide, a tile is 64px wide... plenty of room
20:56:33 * 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:44 <Eddi|zuHause> the more important aspect is imho smoother curves (with less severe speed limits)
20:58:06 <TrueBrain> I can get more if you like :D
20:58:31 <Rubidium> Eddi|zuHause: yes, we're in dire need of clothoids ;)
20:59:01 <Elukka> comedy suggestion: smooth rail curves
20:59:14 <Elukka> CETS would have sufficient sprite angles!
20:59:52 <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...
21:00:02 <Yexo> one RV is only half a tile long
21:00:06 <TrueBrain> briliant isnt it? :)
21:00:15 <Aali> is the autonightly server still operating?
21:00:19 <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:56 <Elukka> really small wagons are kinda weird to draw
21:00:59 <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:41 <Aali> website is down and I dont remember the address
21:02:01 <TrueBrain> Yexo: RV queue only checks what is in the direction of the vehicle
21:02:05 <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: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:43 <Elukka> well you're better at drawing them :P
21:02:58 <Elukka> where it gets really odd is when it's wider than it's long on the 45 deg view
21:04:17 <Eddi|zuHause> that should only be for 3lu wagons
21:05:37 <Elukka> the shorter variant of this wagon will look odd unloaded
21:05:51 <Elukka> two tiny 3 lu wagons separated by long empty space and a coupling bar
21:16:10 <Xaroth> frosch123: because it's not a custom compile?
21:20:37 <andythenorth> Eddi|zuHause: traffic object newgrfs?
21:21:15 <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:44 <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:43 <andythenorth> can a traffic object count the number of vehicles on the tile? Can it have registers?
21:27:28 <Eddi|zuHause> a traffic object can do the same thing airports can do
21:29:57 <Yexo> openttd will get incredible slow if you try to use that for diagonal roads
21:31:18 <Eddi|zuHause> pathfinder callback may be evil
21:32:11 <Eddi|zuHause> and lots of details are missing
21:32:29 <andythenorth> Yexo: it's fine - TB will optimise it :)
21:32:32 <andythenorth> just have to get him sick again
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:23 <Yexo> andythenorth: one of the conclusions from all the profiling: newgrfs make things slow, but that can't be optimized away
21:33:35 <TrueBrain> no worries; we have scripts :P
21:33:37 <Yexo> just following the spec means quite some code has to be executed
21:35:07 <andythenorth> reimplement everything
21:35:38 <Rubidium> could be done, together with xsl ;)
21:35:42 <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:37:00 <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:55 <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:42:32 <TrueBrain> This may come to you as a surprise since we have not met before.I have
21:42:34 <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:37 <TrueBrain> to present you to the bank as next of kin to our deceased costomer?
21:43:31 <andythenorth> TrueBrain: ok, fine by me
21:43:34 <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:10 <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> You've been personally selected to
21:45:15 <andythenorth> receive access to this $1,407/a day
21:45:15 <andythenorth> software for no charge!
21:45:15 <andythenorth> Access here to access your exclusive download:
21:47:03 <CIA-6> OpenTTD: rubidium * r23741 /trunk/src/ (5 files): -Revert (r23740): the few parts that the Windows / non-network compiles stumble on
21:47:43 * andythenorth has failed to make BANDIT :[
21:48:53 <frosch123> start ROBBER instead?
21:49:11 <andythenorth> what is it? A traffic objects grf?
21:50:03 *** Guest22511 is now known as Markk
21:50:55 <frosch123> andythenorth: might be
21:51:12 * andythenorth concludes that trucks were rubbish before about 1940
21:51:19 <andythenorth> mostly <10t capacity
21:52:10 <frosch123> the same holds for rail wagons, doesn't it?
21:52:11 <Eddi|zuHause> you have trams before that :)
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: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:57 * andythenorth somewhat overlooks RL weights
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:29 <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:02 <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:10:11 <Eddi|zuHause> but you need to construct the sprite of two parts
22:11:33 <Eddi|zuHause> and you need to cache the sprite in the tile, otherwise the varaction2 evaluation takes too long for each draw
22:11:46 <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:17:22 <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:51 <Eddi|zuHause> and i always disputed that claim on grounds of the catenary code doing the same calculations
22:20:55 <planetmaker> I mean... many things are possible. And arguabley things like townzone would be an interesting thing, too
22:21:12 <planetmaker> for example in order to provide different fences then
22:22:59 <planetmaker> Eddi|zuHause: you have though a tile-coordinate variable via the two pseudo-random bits
22:23:36 <Eddi|zuHause> planetmaker: but it's a pseudo-randomized variable, not a regular one
22:23:59 <planetmaker> it's the least significant bits of the coordinate
22:24:09 *** encoded has joined #openttd
22:25:16 <Rubidium> it's the (x+y)%4-ish code that's used for trees
22:25:47 <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:08 <michi_cc> (24 tile accesses actually, but only 13 unique tiles)
22:35:00 <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:39 <CIA-6> OpenTTD: frosch * r23744 /trunk/src/train_cmd.cpp: -Fix (r23142) [FS#4923]: Check the version of the right GRF.
22:37:08 <Rubidium> Eddi|zuHause: that's so unreal...
22:37:36 <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:01 <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:39 <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:30 <iddqd> after each savegame my buddy timeouts
22:40:44 <iddqd> is there a console command that lets one timeout longer
22:41:00 <Eddi|zuHause> opposing to "land info of nearby tiles", which smells like potentially a 32x32 area
22:41:31 <Eddi|zuHause> iddqd: the timeout is 4 game days (ca. 10 seconds)
22:41:51 <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:55 <Eddi|zuHause> iddqd: only way around that is to disable autosave, or pause the game during that time
22:42:15 *** Timmaexx has joined #openttd
22:42:22 <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:55:52 *** fonsinchen has joined #openttd
22:58:55 <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.
23:08:17 <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:50 <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:17 *** michi_cc has joined #openttd
23:12:17 *** ChanServ sets mode: +v michi_cc
23:13:55 <CIA-6> OpenTTD: truebrain * r23747 /trunk/src/game/game_core.cpp: -Fix (r23746): forgot one more case
23:15:56 <frosch123> refit orders with cargo subtypes are a misfeature :(
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: www.informatik.uni-halle.de/~krause/rail_bits.txt for "full" trackbits and switches etc., some combinatorial stuff is needed (means larger switches, not more steps)
23:20:57 <Eddi|zuHause> (there's some potentially evil exponentiation there for the number of sprites needed)
23:25:39 <michi_cc> Indeed, it's quite a lot of sprites, but not that many to be unmanageable.
23:42:59 *** FLHerne has joined #openttd
23:49:29 *** 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:37 <frosch123> i wonder whether someone used it as pseudo random value :p
continue to next day ⏵
