IRC logs for #openttd on OFTC at 2011-11-20
⏴ go to previous day
00:02:49 *** Cybert1nus has joined #openttd
00:24:10 *** Progman has joined #openttd
02:03:39 *** Eddi|zuHause has joined #openttd
02:29:10 *** Biolunar_ has joined #openttd
03:26:07 *** rhaeder1 has joined #openttd
03:26:20 <Eddi|zuHause> 7 Seek_Error_Rate 0x000b 200 001 051 Pre-fail Always In_the_past 0
03:26:29 <Eddi|zuHause> suddenly it's like nothing ever happened
03:33:01 <Eddi|zuHause> Nov 19 21:44:39 johannes-i smartd[2774]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 1 to 200
03:34:39 <__ln__> if you start the long smart test, does it complete?
03:34:40 <Eddi|zuHause> Nov 18 14:13:15 johannes-i smartd[2766]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 200 to 100
03:34:41 <Eddi|zuHause> Nov 19 02:14:38 johannes-i smartd[2756]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 100 to 1
03:35:17 <Eddi|zuHause> i think the last one didn't... i'll try another one... takes an hour
03:37:07 <Eddi|zuHause> # 1 Extended offline Completed: unknown failure 90% 1055 4294705486
03:37:21 <Eddi|zuHause> not entirely sure what that means
03:39:30 <__ln__> me neither, but doesn't sound good
03:41:56 <Eddi|zuHause> Nov 20 04:41:10 johannes-i kernel: [95391.463330] TCP: Possible SYN flooding on port *****. Sending cookies. <-- not sure what that means either
05:56:23 *** Eddi|zuHause has joined #openttd
06:53:56 *** andythenorth has joined #openttd
07:33:50 *** andythenorth has joined #openttd
07:37:06 *** DayDreamer has joined #openttd
07:40:48 *** sla_ro|master has joined #openttd
07:55:49 *** SmatZ- is now known as SmatZ
07:56:25 *** |Terkhen| is now known as Terkhen
08:08:15 <CIA-6> OpenTTD: rubidium * r23271 /trunk/src/ (fontcache.cpp fontcache.h openttd.cpp strings.cpp): -Codechange: don't repeatedly initialise and free the freetype library
08:14:23 *** Kurimus has joined #openttd
08:29:38 *** Devroush has joined #openttd
08:52:50 * andythenorth needs rack trams
09:07:36 <peter1138> andythenorth, maybe you should delve into the code some time ;)
09:23:54 *** JVassie has joined #openttd
09:24:02 *** Progman has joined #openttd
09:25:51 *** Alberth has joined #openttd
09:25:52 *** ChanServ sets mode: +o Alberth
09:32:56 <andythenorth> peter1138: I started once...
09:33:42 <andythenorth> got quite stuck quite soon
09:33:52 * andythenorth is not short of other distractions :P
09:58:32 *** Arafangion has joined #openttd
10:05:57 *** Cybertinus has joined #openttd
10:07:45 *** mahmoud has joined #openttd
10:46:23 *** TGYoshi has joined #openttd
11:15:11 <Eddi|zuHause> # 1 Extended offline Completed without error 00% 1082 -
11:21:37 * andythenorth wonders if articulated vehicles can build articulated vehicles...
11:27:37 <peter1138> andythenorth, no, obviously :)
11:27:48 <andythenorth> empiricism agrees with you :P
11:27:58 * andythenorth will have to write some actual code
11:50:13 <CIA-6> OpenTTD: rubidium * r23272 /trunk/src/ (gfx.cpp gfx_func.h): -Codechange: pass the initial font size to DrawString and friends
11:52:12 <CIA-6> OpenTTD: rubidium * r23273 /trunk/src/ (5 files): -Codechange: allow passing a MissingGlyphSearcher to CheckForMissingGlyphs (default to the language pack strings)
11:56:53 <CIA-6> OpenTTD: rubidium * r23274 /trunk/src/ (5 files in 2 dirs): -Add: internal support for a monospaced sprite font
11:59:37 <CIA-6> OpenTTD: rubidium * r23275 /trunk/src/ (fontcache.cpp fontcache.h openttd.cpp strings.cpp): -Codechange: allow loading of the monospace (freetype) font at another moment than the other fonts
12:00:14 <andythenorth> if a template has more #ifdef than nfo, is it a template any more?
12:01:42 <Eddi|zuHause> hm... let me check
12:01:46 <CIA-6> OpenTTD: rubidium * r23276 /trunk/src/ (strings.cpp strings_func.h): -Codechange: add the answer for the question whether we're looking for monospace fonts in the searcher
12:02:07 <CIA-6> OpenTTD: rubidium * r23277 /trunk/src/fontcache.cpp: -Codechange: fallback font support for fontcache
12:02:29 <Eddi|zuHause> michi_cc: if it "breaks" too much, could it be grfv8 only?
12:03:25 <michi_cc> No, because it isn't at all about NewGRFs but about OpenTTD internals (that are unfortunately exposed at some places).
12:04:10 <CIA-6> OpenTTD: rubidium * r23278 /trunk/ (8 files in 2 dirs): -Add: monospaced sprite font with the same characters as the normal font
12:10:43 <CIA-6> OpenTTD: rubidium * r23279 /trunk/src/fontcache.cpp: -Codechange: try to prevent slanted and skinny fonts with fontconfig. This should generally make the fallback choice better legible
12:13:47 * andythenorth tries to insert one extra vehicle into trams
12:13:53 <andythenorth> (articulated engine)
12:14:13 <andythenorth> this is stunningly complicated without splitting off a new template :P
12:23:18 <Eddi|zuHause> michi_cc: i think the movement of shorter wagons is better, but the longer wagons need some reviewing
12:25:05 <Eddi|zuHause> michi_cc: and i think the glitches near slopes got bigger
12:26:48 <andythenorth> Eddi|zuHause: I need to convert the tram wagons to count from rear of consist when handling change of properties etc :O
12:27:11 <Eddi|zuHause> andythenorth: what for?
12:27:34 <andythenorth> I think it's the easiest way to handle having 1 or 2 locomotives
12:27:42 <andythenorth> which I'm currently trying to implement
12:27:54 <andythenorth> or I could split templates, but that's bad for maintainability :P
12:30:04 <michi_cc> Eddi|zuHause: Yes, the result of var 62 will be slightly different with the patch. But as 62 is recent, CETS is the only GRF actively using it I'd guess, so not that much of a problem.
12:30:25 <michi_cc> It does fix that trains with an indicated length of 1.0 use more than one tile in stations for example.
12:30:33 <Eddi|zuHause> michi_cc: i think the russians may be using it
12:30:56 <CIA-6> OpenTTD: rubidium * r23280 /branches/1.1/ (7 files in 5 dirs): [1.1] -Prepare: 1.1.4-RC1
12:30:57 <andythenorth> in russia, var uses you
12:31:05 <planetmaker> een then, their code isn't old either, Eddi|zuHause
12:31:42 <Eddi|zuHause> michi_cc: judgin from recent discussion in nml thread, i think so.
12:31:48 <michi_cc> var 45 isn't affected by that change, it's only 62, which is only ~6 week old.
12:32:32 <Eddi|zuHause> michi_cc: but what i mean is that the sprite sorter now more often does The Wrong Thing (tm) near slopes
12:32:45 <michi_cc> And if they really use it it's an argument to commit that stuff as fast as possible before anybody else starts using it.
12:32:46 <Eddi|zuHause> at least it appears to me like that
12:33:07 <michi_cc> In general or for CETS vehicles?
12:34:03 <Eddi|zuHause> i don't have any general vehicles
12:35:41 <CIA-6> OpenTTD: rubidium * r23281 /tags/1.1.4-RC1/ (. src/os/windows/ottdres.rc.in src/rev.cpp.in): -Release: 1.1.4-RC1
12:37:09 <michi_cc> That's probably because the bounding boxes now have the proper length and not 7/8 for every vehicle. So if CETS somehow relied on the longer bounding box to resolve the graphics better this would be different now (Side note: this only applies to the diagonal directions, the bounding box for the other directions is and was always 3x3 regardless of length or orientation).
12:38:13 <Eddi|zuHause> yeah... i'll need to think about that...
12:39:57 * andythenorth ignores idea of articulated tram locomotive :P
12:40:03 <andythenorth> solved that differently
12:47:56 *** frosch123 has joined #openttd
12:59:42 *** Brianetta has joined #openttd
13:29:37 <Xaroth> frosch123: up again with heq
13:29:47 <Xaroth> i'll leave it in your good hands
13:29:52 <Xaroth> tb has rcon power if needed.
13:30:09 <Xaroth> gotta run, already late
13:30:14 <frosch123> there is still only dutch trams set :s
13:31:00 * planetmaker starts to create a map
13:32:53 <Xaroth> i'll fix it when I'm back.
13:33:38 <Rubidium> frosch123: just download some NewGRFs using rcon
13:34:21 * frosch123 is having fun reading the nogo topic :)
13:34:37 <frosch123> some did some awesome research :)
13:44:49 *** TomyLobo2 has joined #openttd
13:46:43 <planetmaker> hm... do I need the script during generation? Or how does that work?
13:47:16 <Yexo> you need it when playing the game
13:47:25 <Yexo> afaik the script can't save any state in the savegame yet
13:47:34 <frosch123> does nogo just always use the script, or does it already store it in the save?
13:47:58 <Yexo> I haven't seen code yet to store it in the savegame
13:50:39 *** TomyLobo2 is now known as TomyLobo
13:52:32 *** HerzogDeXtEr1 has joined #openttd
14:02:45 <planetmaker> slight update... missed the station NewGRFs
14:08:05 <frosch123> we have to start our own server :p
14:09:17 <planetmaker> I could fire-up the dev server
14:14:46 * andythenorth should hang out and watch :)
14:39:14 <CIA-6> OpenTTD: frosch * r23282 /trunk/src/ (group_cmd.cpp group_gui.cpp): -Fix [FS#4844] (r23212): CmdRemoveAllVehiclesGroup() was not passed the vehicle type in all cases, but the type is actually not needed.
14:50:05 <andythenorth> how do I provide smoke for a locomotive with two chimneys?
14:51:03 <Xaroth> planetmaker: if you wnt i can give you access to the machine
14:51:30 *** Adambean has joined #openttd
14:51:30 <Xaroth> so you can change whatever is needed
14:53:14 <Eddi|zuHause> andythenorth: by implementing NewSmoke :p
14:53:24 <andythenorth> what's the spec?
15:17:39 <CIA-6> OpenTTD: rubidium * r23283 /trunk/src/newgrf.cpp: -Fix: [NewGRF] Prevent against writing data for unknown fonts
15:21:13 *** Eddi|zuHause has joined #openttd
15:31:18 *** Maarten1 has joined #openttd
15:39:24 <CIA-6> OpenTTD: rubidium * r23284 /trunk/src/water_cmd.cpp: -Fix [FS#4845]: Pathfinders go haywire when you build a lock over a ship going perpendicular to the axis of the new lock
15:41:00 *** KritiK_ has joined #openttd
15:46:11 *** KritiK_ is now known as KritiK
16:29:15 <TrueBrain> there, published a new version of NoGo. It now detects scripts, instead of trying to open one :P It still has to be called 'test', but that are minor details ;)
16:29:20 <TrueBrain> Xaroth / planetmaker ^^ :P
16:37:00 *** TWerkhoven[l] has joined #openttd
16:37:49 <frosch123> so, can we get a server with the game pm prepared?
16:38:00 <TrueBrain> Xaroth is at the movies
16:38:06 <TrueBrain> you will have to wait till he is back I am afraid :)
16:38:24 <frosch123> then i continue trolling :)
16:38:27 <planetmaker> my autopilot fails for me. I could of course just start the server without
16:57:17 <TrueBrain> shit, forgot to fix the bug where on pause, the growth updates are not getting through
16:58:04 <frosch123> set the right setting then
16:59:09 <frosch123> but, did you actually post new binaries? just fix it now :p
16:59:33 <TrueBrain> fixed; I guess I can put the CF to work again yeah .. why not :)
16:59:35 <Zuu> There are binaries of today on finger.
17:03:52 <TrueBrain> compiling new version then
17:04:56 <frosch123> i guess toyland would be quite an annoying challenge
17:05:34 <frosch123> it has this nasty effect that small house accept sweets, while big houses accept fizzy drinks
17:05:46 <frosch123> so, if the town growths, it stops accepting sweets iirc
17:08:30 <TrueBrain> now that my friends is a huge: FAIL :D
17:09:40 <panna> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
17:10:31 *** panna is now known as virrpanna
17:14:30 <andythenorth> so...if you have LH drive set, HEQS is just going to look dumb
17:20:01 <Eddi|zuHause> you can certainly duplicate the sprites with different offsets for LH drive
17:20:27 * planetmaker wondered what Lufthansa had to do with this... :-P
17:21:19 <Eddi|zuHause> if you had nml, you could do this calculation in the template
17:24:29 <z-MaTRiX> Eddi|zuHause<< actively hiding errors from users ;)
17:25:12 <z-MaTRiX> though there are anomalies
17:25:39 <z-MaTRiX> the'd need to not report, or double buffer the results to not show anything
17:27:52 <andythenorth> can we have a cb for offsets?
17:27:59 <andythenorth> then I can do the calculation
17:30:45 <Eddi|zuHause> maybe during graphics callback, one of the 0x100+ registers could contain an offset-adjustment
17:32:36 <andythenorth> shame cpp can't do arithmetic
17:34:28 <frosch123> you first have to invent a preprocessor called "asm" to give that line any sense
17:35:52 <z-MaTRiX> and it compiles itself in 0.1 seconds
17:43:36 *** Progman_ has joined #openttd
17:45:41 <Alberth> andythenorth: use a proper macro processor, like m4
17:46:17 <andythenorth> tbh, there's no gain from doing the arithmetic on the fly
17:46:41 <andythenorth> if every RV needs custom offsets for left-hand-drive-side, then I should just make more action 1s
17:46:50 <andythenorth> although it's twice the number of realsprites to make :(
17:47:54 *** Progman_ is now known as Progman
18:02:24 *** valhallasw has joined #openttd
18:15:24 *** DayDreamer has joined #openttd
18:16:38 <andythenorth> TrueBrain: can scripts be bound to a specific map? i.e. mostly specific towns
18:16:54 <andythenorth> can / will / is it a good idea /s
18:17:23 <Zuu> It might be a good idea to allow a scenario to bind to a specific goal script.
18:17:37 <TrueBrain> savegames will store the script they used to run with
18:17:44 <frosch123> a scenario will bind a goal script just like ais
18:17:51 <frosch123> and scripts can read town names
18:18:01 <frosch123> so, unless you rename the towns, it should be fine :p
18:18:17 <frosch123> though the script could actualy catch the townid on start, before you rename it :p
18:18:30 <andythenorth> or bind to the id :P
18:19:04 <andythenorth> presumably bundling a newgrf + a script is insane?
18:20:03 <frosch123> industries are quite a newgrf derivate, not much a script can do about their production
18:20:11 <andythenorth> cases would be things like industry closure, which have proven unsolvable
18:20:23 <Zuu> Probably not, but it depends on if scripts are going to be available as AIs on bananas and thus should be general purpose enough to survive any map.
18:20:48 <TrueBrain> I think a script should be able to 'suggest' newgrfs too, with which it works best
18:20:58 <frosch123> i was wondering whether it makes sense to load multiple scripts at once
18:21:03 <Eddi|zuHause> Zuu: you can make a script unavailable for general download, only as a dependency for the scenario
18:21:10 <Eddi|zuHause> frosch123: i do think so
18:21:11 <frosch123> i.e. one for the gameplay, and one for the statistics and admin stuff
18:21:18 <TrueBrain> frosch123: for now, we limit it to one
18:21:26 <TrueBrain> mostly because the implementation becomes so much easier ;)
18:21:28 <frosch123> TrueBrain: sure for now :)
18:21:29 <Eddi|zuHause> one may be too limited
18:21:30 <andythenorth> frosch123: how would they interact? Should a script be able to import another script? Sounds ...explodey :)
18:21:49 <TrueBrain> solving the implementation issue to allow more can be very tricky ;)
18:22:00 <andythenorth> in some respects, FIRS is doing things that are perhaps not best done in newgrf - industry clustering, open dates, and such
18:22:07 <frosch123> maybe since scripts are easy enough, we can just say: you have to combine the source
18:22:14 <frosch123> makes it easier for us: no conflicts
18:22:16 <andythenorth> possibly even some of the placement things - snowline, towns etc should not be in newgrf
18:22:41 <frosch123> yeah, the statistics stuff would suit a library
18:23:06 <andythenorth> industry handling library
18:23:22 <TrueBrain> but having 2 scripts active at the same time can be tricky, as you need to be sure they do not collide in settings etc ;)
18:23:29 <TrueBrain> so yeah, via libraries or what-ever is much easier :)
18:24:22 <Zuu> An interesting problem is if all current libraries will need to have a duplicate eddition that uses Goal* instead of AI* or if OpenTTD can handle that.
18:24:26 * andythenorth plots a FIRS library :P
18:24:45 <TrueBrain> Zuu: there are no current libraries that are useful to Goal :)
18:24:45 <Eddi|zuHause> must teach the script authors properly
18:24:52 <Xaroth> TrueBrain: so I should compile new version?
18:24:53 <andythenorth> hmm...could grfs specify certain libraries are needed via action 14? Again, could be explodey...
18:25:01 <TrueBrain> Xaroth: yes please :)
18:25:11 <TrueBrain> and hurry, we want to play :P
18:25:32 <andythenorth> what are the game rules? I haven't played MP for ages...
18:25:41 <andythenorth> I'm no good at hardcore coop styles :P
18:25:46 <Xaroth> andythenorth: don't be a dick.
18:25:53 <Xaroth> one rule to rule them all
18:25:55 <planetmaker> which server, TrueBrain?
18:26:12 <andythenorth> Xaroth: last time I played MP I wasn't too good at that :(
18:26:24 <andythenorth> I annoyed everyone else with my routes :P
18:26:39 <Xaroth> recompiling new version
18:26:40 <andythenorth> we should go all out, test NoGo, YAIM + YACD :P
18:26:54 <Eddi|zuHause> "wine: could not find the Wine loader" <-- wth did i do wrong?
18:27:24 <planetmaker> Xaroth: which hash?
18:28:05 <planetmaker> Will the OpenTTD CF compile, too?
18:28:37 <Eddi|zuHause> mäh... i guess i should really finally try to figure out a real windows install...
18:28:47 <TrueBrain> the CF has been done for hours already
18:28:53 <andythenorth> shame there's no way to distribute nightly grfs on bananas easily
18:29:02 <z-MaTRiX> Eddi|zuHause<< dd? :)
18:29:13 <TrueBrain> planetmaker: latest :P
18:29:16 <Zuu> the CF build is also now available through OTTDAU for the lazy people :-)
18:29:26 <planetmaker> oh... a refresh works wonders ;-)
18:29:42 <z-MaTRiX> my win98 install was 1 minutes 30 seconds fdrom a cd in 1998
18:30:07 * andythenorth lost the binary server
18:30:47 <Eddi|zuHause> z-MaTRiX: let me express my doubts that win98 runs CivV or HeroesVI
18:31:21 <z-MaTRiX> never heard ot those ;<
18:31:45 <z-MaTRiX> but after a full ntfs fail i installed linux
18:33:27 <planetmaker> Xaroth: I prepared a savegame
18:33:29 <frosch123> Xaroth: use pm's save?
18:33:52 <Xaroth> whats so special about the savegame?
18:34:02 <planetmaker> it has a usable newgrf config
18:34:13 <Xaroth> and which newgrf might that be?
18:35:04 <planetmaker> some bananas newgrfs, like ogfx+airports, ogfx+industries, brazilian townnames to macht tropical climate, ISR, CHIPS, av8, heqs, fish, TRS
18:35:29 <frosch123> isn't that damn ugly?
18:35:30 <planetmaker> tropical refurbishment set
18:35:33 <TrueBrain> why not save the newgrf, and give that to him? So he can also generate new maps etc?
18:35:33 <planetmaker> like we had before
18:35:41 <andythenorth> where is the filter widget on multiplayer window?
18:35:45 <frosch123> oh, i thought town renewal set
18:35:52 <frosch123> but that is ttrs :)
18:36:03 <Xaroth> planetmaker: I prefer randomly generated maps, so the server can just re-set itself over and over again
18:36:11 <Xaroth> .. and it won't break when tb (again) breaks saves :P
18:36:13 <planetmaker> Xaroth: it's randomly generated...
18:36:27 <TrueBrain> planetmaker: he wants to run it for more than one map ;)
18:36:55 *** Illegal_Alien has joined #openttd
18:36:56 <CIA-6> OpenTTD: rubidium * r23285 /trunk/src/network/network_content_gui.cpp: -Fix: scanning of content after download didn't work
18:36:57 <planetmaker> ja, my god. grab the save, make a newgrf preset and save that
18:37:19 <planetmaker> one _can_ make it complicated
18:37:39 <TrueBrain> yes; you can also give the preset :D
18:37:41 <Xaroth> like providing a save instead of info, yes
18:37:54 <TrueBrain> works two ways, complications :D
18:38:06 <Xaroth> i want info, not a save :P
18:38:22 <TrueBrain> planetmaker: you seriously don't get that a savegame is just a one time thing? In the order of: giving a fish instead of learning to fish? :)
18:38:51 <frosch123> tb: there is no better way to specify grfs than using a savegame
18:38:55 <Rubidium> TrueBrain: but giving you a set of (unreadable) instructions doesn't work either
18:38:56 <TrueBrain> hihi: why dont we make newgrf presets uploadable to BaNaNaS? :D
18:38:59 <frosch123> it also contains the md5sums and all settings
18:39:06 <planetmaker> TrueBrain: and the parameters set...
18:39:23 <TrueBrain> a newgrf set should do that too, wouldn't it? Anyway, it is a clumpsy way of sharing settings ...
18:39:23 <planetmaker> ... load the damn savegame
18:39:34 <TrueBrain> I had that issue earlier when I asked you about some good settings a few weeks ago :)
18:39:51 <Eddi|zuHause> hm... what linux tool can mount .wim files?
18:40:12 <TrueBrain> would it be hard to make some kind of file which loads the preset like as with a savegame?
18:40:15 <TrueBrain> including parameters etc?
18:40:27 <TrueBrain> so you can easily share such (obvously complex) information?
18:40:46 <Rubidium> we should go from filenames in the config to grfid_md5sum = params I guess
18:41:14 <Rubidium> then you can easily copy it between versions of OpenTTD, *and*... you can possibly download it with bananas when it's on there
18:41:35 <planetmaker> but that doesn't give you the parameters
18:41:54 <TrueBrain> newgrfs became too complex :D
18:42:02 <planetmaker> nor the landscape which I made sure fits our purpose
18:42:08 <planetmaker> they're dead easy
18:42:22 <Eddi|zuHause> Rubidium: but that still does not solve updating grfs from bananas
18:42:23 <TrueBrain> yet you have a hard time giving the information to someone else :D
18:42:28 <TrueBrain> so 'dead' easy is not thw word I would use ;)
18:42:33 <planetmaker> because you don't want the info
18:42:39 <planetmaker> I gave you all you can want
18:42:44 <Eddi|zuHause> Rubidium: if i update a grf, it should be updated in all presets
18:42:47 <planetmaker> load. save. re-use
18:42:56 <planetmaker> no better way THAN a savegame
18:42:59 <TrueBrain> planetmaker: you can keep repeating that, but clearly we (As users) want more than just that :)
18:43:04 <planetmaker> so, no, I don't see the point
18:43:08 <TrueBrain> so clearly there is a gap here between what you can supply, and we want to get
18:43:24 <planetmaker> I just see that I spend like looking for a good landscape and stuff for... nothing
18:43:35 <planetmaker> because of "I want to do it my way"
18:43:36 <Xaroth> with the specified newgrf
18:43:42 <TrueBrain> planetmaker: it is not about a single map; it is about a server running for a few weeks
18:43:45 <planetmaker> Xaroth: parameter for industries?
18:43:49 <TrueBrain> your map is not sufficient for that
18:43:58 <Xaroth> = 16 1 3 4 1 1 1 1 1 1 3 1 1 1 1 1
18:44:10 <planetmaker> dunno the numbers. Configuration ingame rulez
18:44:37 <Xaroth> frosch will be chuffed, no swedish rail o_O
18:44:38 <frosch123> another point why savegames are supiriour to any text info
18:44:50 <planetmaker> Xaroth: in tropical climate they're not that much of an advantage
18:44:52 <frosch123> Xaroth: why? pm pushed that
18:45:11 <planetmaker> and mostly I forgot them, but doesn't matter too much
18:45:12 <Xaroth> frosch123: because they weren't in the preset in the save
18:45:28 <CIA-6> OpenTTD: translators * r23286 /trunk/src/lang/ (croatian.txt unfinished/basque.txt welsh.txt):
18:45:28 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:28 <CIA-6> OpenTTD: basque - 1 changes by Thadah
18:45:29 <CIA-6> OpenTTD: croatian - 8 changes by VoyagerOne
18:45:29 <CIA-6> OpenTTD: welsh - 4 changes by kazzie
18:46:03 <andythenorth> could I disable HEQS if game drive side is left?
18:47:02 <frosch123> andythenorth: there is at least one another set, giving a warning "this set is supposed to be used with rhs driving"
18:50:13 <andythenorth> but not disabling?
18:51:11 <frosch123> no, not so harsh :p
18:52:59 <frosch123> TrueBrain: fix nogo
18:53:29 <frosch123> the towns show no goal again
18:53:44 <TrueBrain> I am playing Saints Row Third
18:53:48 <TrueBrain> I really have to quit that game? :(
18:54:06 <andythenorth> I should update the newgrf wiki to indicate that offsets need to be different for LH drive and RH drive
18:54:22 <andythenorth> what's a good way to explain that?
18:54:43 <frosch123> enable the bounding boxes and make a screenshot?
18:56:00 <andythenorth> do I miss the flag for drive side here?
18:56:09 <andythenorth> I know there's a global varaction 2 for it
18:56:41 <frosch123> there is only that var
18:56:52 <frosch123> why should there be also a flag?
18:57:09 <andythenorth> I want to use action 7 for it
18:57:31 <frosch123> where's the problem?
18:58:26 <andythenorth> there isn't, I misunderstand action 7 :)
18:58:46 * andythenorth is wondering if an offset fix can be scripted by the devzone makefile
18:59:18 <Xaroth> right, nogo #1 is running
18:59:25 <andythenorth> is the required delta for the offset deterministic across all vehicles that have same length reduction?
19:00:25 <planetmaker> so... one company or many?
19:01:08 *** TWerkhoven has joined #openttd
19:01:11 <Eddi|zuHause> nobody actually solved the payment in IS yet...
19:01:19 <TrueBrain> Rubidium: tbh, if only you could Export and Import prsets, which do it via md5, it would be sufficient I think ;)
19:01:23 <andythenorth> meh, version mismatch :P
19:01:43 <Eddi|zuHause> <andythenorth> is the required delta for the offset deterministic across all vehicles that have same length reduction? <-- i guess so
19:02:43 <XeryusTC> oh, OTTDAU is already updated for NoGo :D
19:03:49 <TrueBrain> Zuu is that awesome yeah
19:03:59 <Xaroth> Yexo: potatoe potatoe :)
19:04:09 <TrueBrain> Xaroth: not really; his URL is better
19:04:11 * XeryusTC will try to get the El Kinky Negro Party to do some NoGo :o
19:04:13 <TrueBrain> goes via the load balancer
19:04:29 <Zuu> XeryusTC: Yep, why download manually instead of "just" updating it :-)
19:04:49 <Xaroth> right, i'll keep that in mind
19:04:52 * XeryusTC hands Zuu a free beer
19:05:23 <Zuu> thanks, but I got quite some beers yesterday night and doesn't really want a beer today :-)
19:05:54 <Eddi|zuHause> anybody has an idea about 3D-acceleration in combination with libvirt/kvm?
19:06:30 <CIA-6> OpenTTD: rubidium * r23287 /trunk/src/table/misc_settings.ini: -Fix (r23274): mono_size is a better name than large_mono for the size variable in the configuration file
19:07:57 <andythenorth> anybody like awk or some such, and want to help fix HEQS? :| :D :P
19:08:58 <Xaroth> I like python, but i'm too busy working on my admin-port lib.
19:09:17 <CIA-6> OpenTTD: rubidium * r23288 /trunk/src/newgrf_gui.cpp: -Feature: use the monospace font for the NewGRF text windows
19:19:22 <Eddi|zuHause> ah... great... "this rescue/install DVD will only run flawlessly on HP systems. [cancel]"
19:21:24 <Eddi|zuHause> of course it tells that _after_ letting me wait to copy 5GB of data
19:21:24 <TrueBrain> Eddi|zuHause: that would take you a long time :(
19:25:47 <Eddi|zuHause> i hate days when nothing works...
19:27:23 <Eddi|zuHause> i have a game that doesn't run which ran before. i have a game that doesn't run and needs a wine patch. i have a wine patch that makes a game run but doesn't apply. i have a wine compile that doesn't run even without patch. i have a windows-install-cd which doesn't install
19:27:53 <__ln__> could be worse, it could rain
19:33:24 *** Devroush has joined #openttd
19:34:17 <planetmaker> devs.openttd.org/~planetmaker/patches/nogo3.sav <-- Xaroth
19:35:06 <Xaroth> planetmaker: let me load it on the server
19:35:48 <Xaroth> it's on the server, will use it at some point
19:35:54 <planetmaker> it's the current savegame minus all trains
19:36:03 <planetmaker> at some point it's pointless
19:36:08 <planetmaker> either now or scrap it
19:36:35 <planetmaker> but I guess I'll never provide a savegame anymore
19:37:36 <Xaroth> it also seems a bit pointless to have half a dozen people constantly reconnect and whatnot
19:37:43 <Xaroth> but if you want, you can have rcon access
19:38:08 <TrueBrain> lol, planetmaker, you just loaded the game in SP and reloaded it on the seed, or?
19:38:13 <TrueBrain> kinda like that approach :D
19:38:16 <planetmaker> I fixed the trainset
19:38:24 <planetmaker> so that the game can be continued
19:38:39 <planetmaker> save -> fix in SP -> load back on server
19:38:46 <TrueBrain> I have to remember that :D
19:38:50 <planetmaker> standard procedure
19:39:23 <TrueBrain> hehe; you have played too many games :D:D (a positive thing)
19:39:42 <planetmaker> nah, but I care for the game being played on my servers
19:41:35 <TrueBrain> it is also the way you build etc :)
19:56:11 *** HerzogDeXtEr has joined #openttd
19:58:13 *** DayDreamer1 has joined #openttd
21:02:01 *** DayDreamer1 has left #openttd
21:13:13 *** valhallasw has joined #openttd
21:30:06 <XeryusTC> planetmaker: do you have skype?
21:46:06 *** Brianetta has joined #openttd
22:24:03 <TrueBrain> XeryusTC: OpenTTD needs a TS (Mumble?) server! Skype is for pussies :P
22:25:21 <XeryusTC> TrueBrain: i'm recording skype
22:29:23 <XeryusTC> making a let's play ;)
22:29:30 <XeryusTC> i'm kind of into recording OpenTTD atm
22:33:14 *** welshdragon has joined #openttd
22:36:40 *** Prof_Frink has joined #openttd
22:46:23 <z-MaTRiX> what does openttd use for accurate timing?
22:47:28 <Arafangion> z-MaTRiX: openttd has accurate timing?
22:47:52 <z-MaTRiX> framerate limit or game timebase?
22:50:03 <Arafangion> I'm sure it uses something... I was questioning your claim that it was "accurate timing".
22:51:30 <z-MaTRiX> i believe gettimeofday() is our best option for now
22:52:13 <z-MaTRiX> since rdtsc is unstable on most cpus
22:53:07 <Arafangion> And this matters... how?
22:54:05 <z-MaTRiX> well i'm coding and was interested
22:54:52 <z-MaTRiX> and instead of digging through all the openttd sources, was thinking about i may ask the developers
22:58:24 <TrueBrain> well, you started off with the assumption OpenTTD has one
22:58:31 <TrueBrain> no clue what makes you think it does :)
22:59:02 <z-MaTRiX> btw SDL has a SDL_GetTicks
22:59:27 <z-MaTRiX> that should be millisecond resolution
22:59:36 <TrueBrain> and this matters ... how?
22:59:43 <TrueBrain> (hihi, sorry to steal your line Arafangion :D)
22:59:50 <z-MaTRiX> well for measuring fps a timer is needed
23:00:08 <TrueBrain> lol .. fps for OpenTTD .. that would be useful?
23:00:20 <michi_cc> For Windows QueryPerformanceCounter() is likely your best bet.
23:00:23 <z-MaTRiX> or updating the screen accurately timed
23:00:35 <TrueBrain> wihch game would want to update its screen accurately?
23:00:58 <z-MaTRiX> TrueBrain<< welll if i do animation i'd like it to go on constant rate
23:01:13 <TrueBrain> which is totally unrelated to screen updates
23:01:17 <TrueBrain> and, for that matter, to OpenTTD
23:01:38 <z-MaTRiX> ok well in openttd animation is not a real issue
23:01:54 <z-MaTRiX> thats mor elike some slideshow
23:02:22 <TrueBrain> I wonder what patch you are making that adds slideshows to OpenTTD
23:03:26 <z-MaTRiX> well how about an animation for the background of the console window? or options menu?
23:03:35 <z-MaTRiX> like some moving fractals
23:03:36 <Arafangion> TrueBrain: You're welcome to it. :)
23:04:02 <TrueBrain> z-MaTRiX: sounds like a welcome improvement to OpenTTD ........ NOT (hihi, I just Boratted you :D:D)
23:04:13 <TrueBrain> sorry, that was not nice :)
23:04:42 <TrueBrain> I can't imagine something like that to be useful; but feel free to make us a patch and proof us wrong :)
23:05:01 <z-MaTRiX> just to say something
23:05:23 <z-MaTRiX> its one thing that bothers me though
23:05:51 <z-MaTRiX> the good-old ttd in dos has much higher animation speed
23:06:25 <z-MaTRiX> i guess its related to the SDL_Flip framerate limit
23:06:31 <TrueBrain> you sure about that?
23:07:02 <z-MaTRiX> i'm somewhat sure if the video rendering would be a seperate thread, it would result in an instant speed-up
23:07:14 <TrueBrain> haha; that is just a lie :)
23:07:31 <TrueBrain> but how would that help animation speed?
23:07:49 <TrueBrain> I promise you, on the fastest machine you can find, OpenTTD will still run on the same speed as a new created map does
23:08:17 <z-MaTRiX> if the display function introduces an unwanted delay every refresh, then it cannot result in smooth animation
23:08:31 <Arafangion> TrueBrain: On my machine, actually, OPenTTD is much faster in multiplayer mode than it is in a single-player mode.
23:08:34 <TrueBrain> where do you see non-smooth animation in OpenTTD
23:08:44 <TrueBrain> Arafangion: lol; that is ... very ... weird :)
23:08:59 <Arafangion> TrueBrain: If the architecture was multithreaded, it would run faster. Then again, I run on an Atom D525 system.
23:09:11 <z-MaTRiX> TrueBrain<< like when i click a maglev, and make the viewfinder follow it
23:09:21 <TrueBrain> the assumption anything would run faster threaded, is a lie :)
23:09:28 <JGR> Multithreading would just move the bottleneck elsewhere, and make coding a nightmare
23:09:32 <TrueBrain> it is not a magic powder you can drip over software
23:09:40 <Arafangion> JGR: I'll agree with that.
23:09:45 <TrueBrain> z-MaTRiX: is that animation?
23:09:49 <TrueBrain> animation is the sea you see animating
23:09:52 <TrueBrain> (hence the word: animation)
23:10:01 <z-MaTRiX> click the fast forward at top left
23:10:04 <z-MaTRiX> i was thinking about that
23:10:16 <z-MaTRiX> time goes slow compared to the dos ttd
23:10:17 <TrueBrain> increase the speed of the whole game?
23:10:22 <TrueBrain> no, it should be near identical
23:10:28 <TrueBrain> else someone fucked up something 8 years ago
23:10:47 <TrueBrain> or your DOS emulator is bad, that is also an option
23:10:48 <z-MaTRiX> or i dont have good-enough hardware ...
23:10:48 <Yexo> z-MaTRiX: and how are you comparing to dos ttd?
23:11:03 <XeryusTC> planetmaker: it may actually not have recorded voice because of some fubar mess up :o
23:11:12 <Arafangion> z-MaTRiX: Move your map so that the far right corner is the only part that's visible... And disable the fancy graphics so that the water is not moving, and compare performance.
23:11:14 <TrueBrain> XeryusTC: lolz .....
23:11:16 <z-MaTRiX> Yexo<< ok i know the whole thing differs
23:11:18 <XeryusTC> because it did record what i did before server reset xD
23:11:25 <z-MaTRiX> resolution is larger too
23:11:32 <XeryusTC> but the long 3 hour conversation is not on my hdd it seems xD
23:11:45 <TrueBrain> z-MaTRiX: well, your 'idea' of the speed of TTD (DOS) might be widly different then the reality
23:12:00 <TrueBrain> it happens a lot to people .. they remember old games differently than they really are
23:12:14 <TrueBrain> install DOSBox, install TTD, and play it. Then compare.
23:12:22 <TrueBrain> (without fast-forward, of course)
23:12:34 <TrueBrain> now press .. I think F3 in DOSBox
23:12:39 <Arafangion> z-MaTRiX's linux system may will have crappy graphics.
23:12:39 <z-MaTRiX> i was talking about fast forward
23:12:54 <TrueBrain> okay, z-MaTRiX, that is something you cannot compare in any sane way :D
23:13:04 <TrueBrain> that is so silly, and has absolutely nothing to do with timing (accurate or not :))
23:13:12 <Yexo> but dos ttd doesn't even have fast forward, right?
23:13:18 <z-MaTRiX> its a different question
23:13:24 <TrueBrain> huh? Where did you change the question?
23:13:35 <TrueBrain> [00:05] <z-MaTRiX> the good-old ttd in dos has much higher animation speed
23:13:39 <z-MaTRiX> that should only demonstrate the botleneck caused by displaying
23:13:41 <TrueBrain> that sounds like we are talking about timing ..
23:13:53 <TrueBrain> owh, so fast forward is limited by the display, in speed?
23:14:05 <TrueBrain> and you know this .. how?
23:14:11 <TrueBrain> a magic bird told you, or did you do any profiling?
23:14:21 <Yexo> TrueBrain: the magic bird of course
23:14:24 <z-MaTRiX> well i just started to use SDL too
23:14:29 <Yexo> z-MaTRiX has yet to start looking at the source code
23:14:30 <TrueBrain> I thought I shot down that bird a while ago ...
23:14:30 <z-MaTRiX> and the birds were telling it
23:14:36 <Yexo> yet he knows everything about why it's limited in speed
23:14:54 <TrueBrain> z-MaTRiX: a piece of advise ... don't come with lies in this channel. They often die fast. Unless you can proof something is true, sure, feel free
23:14:59 <TrueBrain> but what you just said is just gibberish
23:15:06 <Arafangion> Hilariously, the reason is because OPenTTD makes bad decisions in code that gets the current time of day.
23:15:13 <z-MaTRiX> currently doing testing and fps meter
23:15:29 <Arafangion> z-MaTRiX: What makes you think the fps is indicative?
23:15:30 <TrueBrain> so come back AFTER you have data, instead of 'guessing' before you do
23:15:39 <TrueBrain> next you are going to tell us we should use voxels, as they are epic!
23:16:22 * Arafangion ... must resist... talking about voxels...
23:16:23 <z-MaTRiX> i was not complaining
23:16:29 <TrueBrain> no, but you are telling lies about the game
23:16:36 <TrueBrain> not in a question. You were stating
23:16:44 <TrueBrain> [00:13] <TrueBrain> owh, so fast forward is limited by the display, in speed?
23:16:46 <TrueBrain> [00:14] <z-MaTRiX> yes
23:16:49 <TrueBrain> that is saying you know something
23:16:53 <z-MaTRiX> i believe i did only reply to questions
23:16:56 <TrueBrain> asking is good. Lying is not.
23:17:07 * Arafangion rushes off to work.
23:17:14 <TrueBrain> Arafangion: have a nice working day
23:17:19 <TrueBrain> it is 0017 here .. lolz
23:17:32 <TrueBrain> means you are ... East of me! :P
23:17:34 <z-MaTRiX> [001417] TrueBrain it is 0017 here .. lolz
23:18:03 <TrueBrain> you can't go much further :P
23:18:18 <Arafangion> :) And with that, I must take my leave. :)
23:21:06 <z-MaTRiX> im currently working on an sdl example program that does asynchronous display update
23:21:20 <z-MaTRiX> and comparing it to one that does not have it
23:24:16 <z-MaTRiX> but since SDL_Flip is synchronized to vertical retrace, and SDL is not thread-safe, i guess the SDL_Flip will introduce a random forced delay in the mainloop
23:25:07 <z-MaTRiX> so putting the SDL dusplay update into a seperate thread/process will increase performance in all cases,
23:25:31 <JGR> You generally do not want a loop to run continuously with no delays
23:25:42 <z-MaTRiX> but at minimum, i can have a core function that runs at 10kHz while updating screen data at 60Hz
23:26:27 <JGR> If eeking out extra performance is that critical, investigate triple buffering
23:26:33 <TrueBrain> it is a bold statement, to say it will increase performance in _all_ cases
23:26:36 <TrueBrain> I know plenty in which it wouldn't
23:26:53 <TrueBrain> threads still aren't the holy cure
23:27:38 <z-MaTRiX> until you want to run the display on the second core :)
23:27:55 <JGR> It's not as simple as that
23:28:22 <TrueBrain> switching threads is very expensive, so are mutexes ... there is so much more to it then 'just adding threads to make it faster'
23:28:39 <JGR> Generally, for any useful display drawing function, it will need to access some data which is periodically modified by the "main" code
23:28:40 <TrueBrain> if it was so simple to increase performance of _all_ applications by threading it, tiw ould be done much more
23:29:04 <TrueBrain> in many cases it in fact slows down an application, if you are threading the display code ..
23:29:17 <z-MaTRiX> TrueBrain<< i don't care if its not simple, just coding
23:29:33 <TrueBrain> I am just complaining on your statements of 'all' and stuff like that :)
23:29:43 <z-MaTRiX> well i could do a process and have shared memory communication
23:29:55 <TrueBrain> shared memory requires a lock
23:30:02 <TrueBrain> which means the main thread freezes during display updates
23:30:02 <JGR> shared memory would be even worse
23:30:05 <TrueBrain> which makes them fibers
23:30:09 <z-MaTRiX> but i can use threads too...
23:30:14 <TrueBrain> which is juse a useless context switch
23:30:21 <JGR> Process swicthes are even more expensive than thread switches
23:30:55 <TrueBrain> JGR: lol, I missed he said processes, that is even worse yeah :D
23:31:03 <TrueBrain> an inter-process-lock, hehe :D
23:31:18 <z-MaTRiX> inter-process-communication
23:31:28 <z-MaTRiX> now google will find this log on it
23:31:30 <TrueBrain> communication is fine, we have shit for that
23:31:35 <TrueBrain> OpenMP, OpenMPI, you name it
23:31:38 <TrueBrain> locks ... ieuw ....
23:31:54 <JGR> Having locks is better than having horrendous rae condition issues
23:31:56 <TrueBrain> hmm, OpenMP is in fact threading :P
23:32:04 <TrueBrain> JGR: haha, for that you have locks, yes :)
23:32:07 <TrueBrain> but they are very expensive :)
23:32:16 <TrueBrain> and in result, performance will degrade ;)
23:32:58 <z-MaTRiX> and if i just pipe the display data into the display process?
23:33:08 <z-MaTRiX> what will cause performance degradation?
23:33:20 <TrueBrain> is that the prepared display, pixel by pixel?
23:33:28 <TrueBrain> as then you can just write it to the video memory directly, much faster
23:33:28 <z-MaTRiX> display command, or the whole buffer.
23:33:29 <JGR> That will cause horrendous performance slowdowns
23:34:07 <JGR> Piped data is buffered, marshalled, etc by the OS and that takes time and context switches
23:34:33 <TrueBrain> not to start about locks to avoid race conditions, bus-uses, cache-polution, ...
23:34:57 <JGR> I really don't see the problem with the wait in the loop, in the original question
23:35:10 <TrueBrain> JGR: which original question? :)
23:35:28 <JGR> [23:24:14] <z-MaTRiX> but since SDL_Flip is synchronized to vertical retrace, and SDL is not thread-safe, i guess the SDL_Flip will introduce a random forced delay in the mainloop
23:36:08 <TrueBrain> in general, how long does displaying really take?
23:36:14 <TrueBrain> 1% of the application? 2?
23:36:24 <JGR> A wait here implies that neither buffer is ready to be written to, and hence there's nothing to do anyway
23:36:29 <TrueBrain> so even if you thread it perfectly, the gain is to be noticed :)
23:37:14 <TrueBrain> on another approach, if you want performance of your display, you don't use SDL :D
23:37:19 <TrueBrain> it has so many compatability layers, ugh
23:37:37 <z-MaTRiX> TrueBrain<< so you say it would have no benefits to have a continuously rolling mainloop, and a parallel snapshotting display thred?
23:37:38 * JGR is unfamiliar with SDL, to be honest
23:37:50 <TrueBrain> z-MaTRiX: for OpenTTD, I am very sure it won't help you
23:37:54 <TrueBrain> in general, it rarely does
23:38:02 <TrueBrain> as you need to lock down the main thread to access information to build your display
23:38:15 <TrueBrain> and those things are expensive like fuck
23:38:19 <z-MaTRiX> no i dont want to lock down my mainloop
23:38:30 <TrueBrain> JGR: SDL is a combination of layers to make it to work on all platforms. This costs a lot of performance :)
23:38:41 <TrueBrain> z-MaTRiX: you have no choice; else you get race conditions, which are worse
23:38:42 <JGR> @ z-MaTRiX, the majority of the main loop would be spent modifying the map/vehicle/etc arrays
23:39:01 <glx> TrueBrain: and may add some limits too
23:39:03 <TrueBrain> you cannot have a write in any area the display is trying to display, while it is displaying
23:39:06 <JGR> You can't reliably use those same arrays for drawing, when they're being modified
23:39:17 <TrueBrain> JGR: hence the locks ;)
23:39:29 <TrueBrain> there are some achitectures which introduce CoW in memory, which do allow it
23:39:40 <TrueBrain> but that is just really advanced fancy state-of-the-art shit, no user has ;)
23:40:16 <JGR> Those are generally quite trivial structures, and tend to involve things like CAS operations
23:40:27 <z-MaTRiX> TrueBrain<< i was thinking about double buffering...
23:40:29 <JGR> Which are also a bit nasty
23:40:35 <z-MaTRiX> rendering in a buffer
23:40:53 <TrueBrain> z-MaTRiX: double buffering is commonly used, yes
23:40:56 <Yexo> z-MaTRiX: before you render you need to know which sprites to render
23:40:58 <TrueBrain> but that is to avoid the user seeing a screen being drawn
23:41:12 <Yexo> I think that part is way more expensive than the actual rendering
23:41:39 <TrueBrain> but what Yexo says: you are talking about improving a piece of code that takes no time to execute in the first place
23:41:40 <glx> even dune 2 used double buffering at that time
23:41:52 <JGR> The main point of double-buffering is to have the buffer ready and waiting, as the re-trace occurs, to avoid screen-tearing
23:42:13 <TrueBrain> JGR: to avoid partial screens, yeah
23:42:55 <TrueBrain> can't remember a game which did not do double buffering tbh
23:43:15 <TrueBrain> Alleycat even did ...
23:43:19 <JGR> Some do triple, but I'm not sure how common that is these days
23:43:29 <TrueBrain> these days it is all not that important anymore
23:43:37 <TrueBrain> 3D graphics is another can of shit :D
23:43:43 <TrueBrain> (which is what is used these days ;))
23:43:57 <TrueBrain> AA 8x draws the screen many times for 1 screen :P
23:44:03 <JGR> The strategy seems to be to just let the card handle it
23:44:04 <TrueBrain> (hihi, now I am pushing it, I know :D)
23:44:19 <TrueBrain> nowedays you send: screen-done-building
23:44:22 <TrueBrain> and it does the swapping for you
23:45:09 * JGR has not done graphical coding for ages
23:45:18 <TrueBrain> but okay; the topic was threading the display part
23:45:30 <TrueBrain> then it heavily depends what you consider 'the display part'
23:45:44 <TrueBrain> in general, there is very little to gain there
23:46:00 <TrueBrain> unless you are doing some high-value up-scaling :P
23:46:09 <TrueBrain> but then you should be caching :D
23:46:16 <JGR> It makes sense if the front end and back end aren't really doing the same thing at all
23:46:25 <TrueBrain> JGR: but when does that happen?
23:46:38 <TrueBrain> well, webservers do, of course
23:46:52 <TrueBrain> a webserver is strictly seen the perfect example of threading the display
23:46:59 <TrueBrain> server sends it to the client, which renders it in its own thread
23:47:02 <z-MaTRiX> i don't get it why are you against multithreading
23:47:07 <TrueBrain> but I am pretty sure that is not what z-MaTRiX is looking for :)
23:47:11 <z-MaTRiX> there is more and more cores in the cpus
23:47:18 <JGR> @ z-MaTRiX, I've written multithreaded code, it's not trivial
23:47:20 <Xaroth> z-MaTRiX: multithreading is a myth
23:47:29 <TrueBrain> z-MaTRiX: who said anyone was against?
23:47:38 <glx> openttd is multithreaded :)
23:47:42 <z-MaTRiX> you are telling it would not be any improvement.
23:47:48 <JGR> Multithreading is useful for parrallelisable algorithms
23:47:49 <TrueBrain> we are just telling you that it is very unlikely you get a gain by threading the display. But for sure it is not _the_ cure in _all_ cases
23:47:54 <glx> but only where it's possible
23:48:10 *** Brianetta has joined #openttd
23:48:11 <z-MaTRiX> The drawing function, and the screen flip function can be threaded too
23:48:24 <JGR> No, they can't we just explained that
23:48:29 <TrueBrain> well, clearly we cannot convince you with words, so I wish you the best of luck making it :D
23:48:34 <TrueBrain> I am not telling you you shouldnt
23:48:41 <TrueBrain> I am just telling you it is unrealistic to expect any improvement
23:49:23 <TrueBrain> and I am very alergic to statements like: "will increase performance in all cases,"
23:49:51 <z-MaTRiX> well its better than 640kB will be enough for everything ;>
23:50:01 <TrueBrain> which Bill Gates btw never said
23:50:10 <glx> IIRC multithreading experiments were done in openttd, the result was big slow down for single core for a very low improvement for multicore
23:50:26 <TrueBrain> glx: I remember the same :D So it has to be true :P
23:50:59 <TrueBrain> I see posibilities in YAPF to thread ... in Cargodest and stuff .. but in very restrictive ways :)
23:51:13 <z-MaTRiX> well things can be done various ways
23:51:14 <JGR> Hmm, even that is a bit dubious IMO
23:51:42 <z-MaTRiX> a circle's points can be calculated in parallel using 256 processors
23:51:43 <TrueBrain> caching often gives a better improvement (at the expensive of memory)
23:52:01 <TrueBrain> and where in OpenTTD do we do such math?
23:52:13 *** Swissfan91 has joined #openttd
23:52:40 <TrueBrain> I calculated the coming and going of weather by using over 100 machines with each 16 cores ...
23:52:49 <JGR> I seem to recall that a previous attempt at improving OpenTTD's performance focused on caching things like height data for each tile corner
23:52:50 <TrueBrain> sure, threading can be very useful. But it doesn't apply to OpenTTD :)
23:52:55 <JGR> I forget where I read that though
23:53:04 <TrueBrain> JGR: most of the imrpvoements in OpenTTD come from caching :)
23:53:08 <TrueBrain> or better hash functions :)
23:53:19 <TrueBrain> or just the plain old: improve the algorithm :)
23:53:21 <TrueBrain> hello Swissfan91 :)
23:53:29 <TrueBrain> JGR: some O(N**2) to O(N) goes a long way ;)
23:53:43 <glx> and then we added a VM for AIs ;)
23:54:01 <TrueBrain> now _those_ can be threaded .... with a lot of work :D
23:54:04 <JGR> Surely the AIs don't have that big an impact?
23:54:12 <TrueBrain> typical example of closely guarded input/output :)
23:54:14 <Yexo> JGR: they have a very big impact
23:54:17 <TrueBrain> JGR: lolz; they do :D
23:54:26 <JGR> Oh well, I always play without them :P
23:54:29 <TrueBrain> on my machine, 16 AIs can take up to 500ms per tick :D
23:54:40 <TrueBrain> (where a tick normally is 30ms, because of a Sleep of 30ms :P)
23:55:02 <TrueBrain> then again, I did alter the settings a bit :D:D
23:55:18 <z-MaTRiX> or a multithreaded pathfinder ?
23:55:27 <glx> you increased opcode limit TrueBrain ?
23:55:45 <Swissfan91> can anyone code NewObjects here?
23:56:00 <TrueBrain> z-MaTRiX: there are posibilities there; just VERY limited once. And all tests so far ahve been very negative in result (and by people who know a lot about threading)
23:56:00 <Yexo> z-MaTRiX: can't do that as long as every vehicle depends on on the pathfinding results of all previous vehicles
23:56:02 <JGR> Presumably the current OpenTTD AIs work better than the originals, given that they chew that many more cycles?
23:56:28 <JGR> I've never used the OTTD AI, I must admit
23:56:29 <Yexo> and a lot more versatile
23:56:33 <TrueBrain> JGR: well, those two are strictly not in relation of course :)
23:56:40 <TrueBrain> but they are much more fun :)
23:57:00 <TrueBrain> more cycles does not imply better :D
23:57:12 <JGR> Well, I'd hope that the extra cycles were doing *something* useful :P
23:57:19 <Yexo> depending a lot upon the map type, but I've seen games were very good human players didn't have it easy to beat an AI
23:57:19 <TrueBrain> just they no longer randomly terraform and shit :D
23:58:41 <TrueBrain> and now we are introducing NoGo, a script VM for goals in the game :P
23:58:45 <TrueBrain> even more cycles wasted :P
23:59:04 <JGR> As long as you can turn it off, it's not a problem
23:59:14 <Yexo> TrueBrain: what was the reason the threading for AIs was removed?
23:59:18 <z-MaTRiX> and what is your opinion of removing the scripting engine from openttd and coding everything in C?
23:59:33 <TrueBrain> Yexo: _current_company
23:59:47 <glx> OTTD2SQ is a nasty one :)
23:59:57 <TrueBrain> OpenTTD is not ready for threads like that. But for sur eit is possible, we have shown that :D
continue to next day ⏵
