IRC logs for #openttd on OFTC at 2009-02-07
⏴ go to previous day
00:29:25 *** NukeBuster has left #openttd
00:30:40 <Rubidium> petern: Ctrl or CTRL? CTRL-click, CTRL+click or CTRL - click?
00:31:12 <Rubidium> it's kinda inconsistent at the moment and I'd like to know what's prefered way of writing it
00:33:02 <Rubidium> and Eddi's say Strg or so
00:33:12 *** Eddi|zuHause has joined #openttd
00:33:46 <Yexo> RS-SM: a german keyboard
00:34:47 <petern> yeah, well germans can translate it :p
00:36:43 <Rubidium> hmm... more inconsistencies
00:37:17 <petern> although CTRL sounds out more :p
00:38:22 <Rubidium> I don't care which form, as long as it's consistent
00:38:43 <Sacro> channel tunnel rail link?
00:38:45 <el_en> i've never seen a keyboard that says CTRL
00:41:17 <petern> doesn't work on its own of course
00:41:57 <petern> hmm, where should i add my base graphics set chooser?
00:42:03 <petern> currently it's in Game Options
00:43:29 <Yexo> I cant think of a better place
00:53:56 <CIA-1> OpenTTD: Yexo * r15383 /trunk/src/ (genworld_gui.cpp openttd.cpp): -Cleanup: Don't call MakeNewgameSettingsLive more often than necessary.
00:53:56 <CIA-1> OpenTTD: rubidium * r15384 /trunk/ (bin/ src/settings.cpp): -Change: tweak some settings to make OpenTTD easier to use for first-time users (or upgraders)
00:54:00 <CIA-1> OpenTTD: peter1138 * r15385 /trunk/src/settings.cpp: -Fix: Saving of char* to configuration file did not work due to incorrect parameter order and no handling of NULL.
00:54:00 <CIA-1> OpenTTD: peter1138 * r15386 /trunk/src/ (openttd.cpp settings.cpp):
00:54:00 <CIA-1> OpenTTD: -Codechange: During start up, store driver/blitter/graphicsset selection in
00:54:00 <CIA-1> OpenTTD: local variable instead of in the global _ini_* variables. This means that
00:54:01 <CIA-1> OpenTTD: specifying a driver/blitter/graphicsset on the command line does not clobber the
00:54:01 <CIA-1> OpenTTD: configuration value, which can now be saved like other values.
00:54:03 <CIA-1> OpenTTD: peter1138 * r15387 /trunk/src/widgets/ (dropdown.cpp dropdown_type.h): -Codechange: Add a drop down list item type for char* strings.
00:54:03 <CIA-1> OpenTTD: rubidium * r15388 /trunk/src/lang/english.txt: -Change: unify the way Ctrl+Click is written.
01:01:42 <CIA-1> OpenTTD: peter1138 * r15389 /trunk/src/ (gfxinit.cpp gfxinit.h lang/english.txt settings_gui.cpp):
01:01:42 <CIA-1> OpenTTD: -Feature: Add ability to select which base graphics set is used from the Game
01:01:42 <CIA-1> OpenTTD: Options window. The change takes effect when the window is closed. This option
01:01:42 <CIA-1> OpenTTD: can only be used from the intro menu, as reloading graphics during a game may
01:02:26 <petern> well, you can now download opengfx and use it in game without a restart
01:02:46 <petern> and, er, now switch back to a working base graphics set without a restart too ;p
01:17:31 <CIA-1> OpenTTD: Yexo * r15390 /trunk/src/openttd.cpp: -Cleanup: Remove old hack that wasn't used anymore.
01:18:12 <glx> I think it should not show obg with missing files ;)
01:24:34 <glx> hmm ok, when I start with windows then switch to dos some sprites disappear (cross, down arrow)
01:25:29 <petern> i don't have dos data files, so...
01:25:39 <petern> only missing sprites i saw was in opengfx, heh
01:26:02 <glx> opengfx has the black boxes and ugly font ;)
01:26:58 <glx> hmm but it may be a palette thing
01:27:17 <glx> cross and arrows are chars IIRC
01:29:04 <glx> yes palette, I changed language to english (so it uses sprites)
01:29:12 <glx> and no texts are visible :)
01:39:21 <Rubidium> glx: sounds like you've got some exotic combination of base graphics files then
01:51:41 <Rubidium> seems to work without artefacts without that patch
01:53:38 <glx> no when the window is closed the dos grfs are loaded using windows palette, so all text become transparent
01:53:59 <glx> dos->windows is ok, windows->dos "fails"
01:54:28 <Rubidium> hmm... and because dos is the default for me it doesn't fail
01:54:51 <Rubidium> but the font failing means that the conversion mechanism isn't right
01:54:51 <glx> yes it works if openttd is started using dos :)
01:55:11 <glx> font doesn't fail, there are just transparent
01:55:40 <glx> dos has "more" colors than windows
01:56:26 <Rubidium> them being transparent is wrong, don't you agree?
01:57:03 <glx> I think remapping is not done for base grfs
01:58:49 <Rubidium> I think the remapping for the font somewhat fails/doesn't exist
01:58:58 <Rubidium> as the non-font stuff isn't pink
02:00:36 <glx> hmm and now the text is white :/
02:05:20 *** TinoDid has joined #openttd
02:06:04 <glx> ok white with msvc, transparent with mingw :)
02:06:28 <glx> looks like it's reading memory it should not :)
02:09:58 <Rubidium> valgrind doesn't speak about reading uninitialised memory
02:14:27 <Rubidium> looks like sprite type's set to ST_NORMAL for font sprites?
02:15:04 *** TinoDid is now known as TinoDidriksen
02:16:01 <glx> font sprites always use colors 0, 1 and 2, whatever the palette is
02:16:34 <Rubidium> something's loading the font sprites as normal sprites
02:17:16 <glx> for dos2win it works because 0 1 2 are remapped to 0 1 2
02:18:27 <glx> but I think you are right, or there's a missing check to prevent conversion
02:19:10 <glx> ,...if (requested == ST_FONT && available == ST_NORMAL) return GetRawSprite(sprite, ST_NORMAL); <-- maybe this
02:19:44 <Rubidium> it's more likely the function that calls it
02:19:59 <glx> but as I don't get warnings it's not there :)
02:21:08 <glx> ,...,...,...return GetRawSprite(SPR_IMG_QUERY, ST_NORMAL);
02:26:52 <Rubidium> glx: it's strange that MSVC give you white and gcc gives you transparent though
02:27:33 <glx> that's probably another bug ;)
02:29:20 <CIA-1> OpenTTD: rubidium * r15391 /trunk/src/spritecache.cpp: -Fix (r14997): loading font sprites should not trigger a palette conversion.
02:38:44 <CIA-1> OpenTTD: belugas * r15392 /trunk/src/ (unmovable.h unmovable_cmd.cpp unmovable_map.h): -Codechange: move the spec getter to a place where it's only required, without the use of extern
02:48:31 *** roboboy has joined #openttd
02:52:20 *** roboboy has joined #openttd
02:54:22 *** roboboy has joined #openttd
03:06:26 *** goodger has joined #openttd
03:06:50 <CIA-1> OpenTTD: belugas * r15393 /trunk/src/unmovable_cmd.cpp: -Fix: little typo
03:32:27 <CIA-1> OpenTTD: glx * r15394 /trunk/src/gfxinit.cpp: -Fix (r15389): no new line at end of line warning
03:42:18 *** Zealotus has joined #openttd
05:04:15 *** TinoDid has joined #openttd
06:20:38 *** Alberth has joined #openttd
07:39:21 *** DaleStan has joined #openttd
08:26:05 *** worldemar has joined #openttd
08:30:59 *** DaleStan is now known as Guest240
08:31:01 *** DaleStan has joined #openttd
09:23:59 *** Vikthor has joined #openttd
09:35:28 <dihedral> reset_company seems to not be working anymore!
09:37:36 *** Progman has joined #openttd
09:38:20 *** roboboy has joined #openttd
09:58:22 <petern> /* If the server is a spectator, it may only do server commands! */
09:58:23 <petern> if (_current_company == COMPANY_SPECTATOR && (cmd_flags & CMD_SERVER) == 0) return false;
10:02:17 <dihedral> petern, however, autoclean works
10:03:48 <dihedral> and autoclean sends the same DoCommandP
10:06:08 <dihedral> petern, DoCommandP(0, 2, c->index, CMD_COMPANY_CTRL); <- sent from autoclean
10:06:25 <dihedral> DoCommandP(0, 2, index, CMD_COMPANY_CTRL); <- send from reset_company
10:07:40 <petern> console command is done as COMPANY_SPECTATOR
10:07:46 <petern> autoclean is done as OWNER_NONE
10:08:30 *** frosch123 has joined #openttd
10:09:29 <dihedral> petern, introduce COMPANY_DEDICATED_SERVER :-P
10:11:33 <dihedral> thankfully pause and unpause still works :-P
10:12:20 <petern> i suggest you put it on flyspray like a good little bug reporter
10:13:50 <dihedral> somehow that if block does not make a bunch of sense to me
10:14:13 <dihedral> perhaps once Rubidium wakes up he can enlighten us :-P
10:21:35 <dihedral> CMD_SERVER ///< the command can only be initiated by the server
10:21:36 <Wolf01> meanwhile, there is anyone who can help me on adding newgrf graphics to roadstops?
10:21:46 <dihedral> now that makes it hard to do that for CMD_COMPANY_CTRL
10:22:50 <frosch123> Wolf01: increment ROADSTOP_SPRITE_COUNT
10:23:15 <Wolf01> ok, but then how do I use the sprites?
10:23:24 <frosch123> create a newgrf consisting of one action 8, one action 5 and followed by the sprites
10:23:48 <frosch123> draw sprite SPR_ROADSTOP_BASE + index
10:24:34 *** OsteHovel^EEE has joined #openttd
10:24:56 <frosch123> you should also checkout svn://svn.openttd.org/extra/ottd_grf
10:25:05 <frosch123> and copy the existing roadstop graphics from there
10:25:32 <frosch123> you can also copy the action5 from there, but have to increment the "number of sprites" in it
10:28:10 <Eddi|zuHause> # Sie ist ein Model und sie sieht gut aus
10:28:25 <Eddi|zuHause> # ich nähm sie so gerne mit zu mir nach Haus
10:33:02 *** GoneWacko has joined #openttd
10:37:42 <dihedral> # denn sie steht nur auf fraun und ich bin leider nur ein mann
10:38:16 <Wolf01> gah, errors compiling squirrel things... retry with msys
10:39:52 * frosch123 ponders cleaning his desk
10:39:59 <OsteHovel^EEE> Wolf01, you compiling with MinGW?
10:41:30 <Wolf01> I usually use vs80, but I switch to mingw when things go wrong
10:42:24 * OsteHovel^EEE uses GCC for Linux Builds and MinGW for cross-compiling to windows :D (/me is always building using DistCC to compile on more than 1 server at a time)
10:43:10 <Wolf01> ok, linking succeeded, so it is vs80 which is broken
10:46:04 *** tkjacobsen has joined #openttd
10:51:47 <Wolf01> good, I made ottd to crash loading a grf
10:53:53 <Wolf01> I think it has something to do with the change I made on sprites.h
10:54:23 <Wolf01> (I should not touch what I don't know)
10:55:45 <Wolf01> ooooh, I'm stupid... the grf is not automatically loaded
10:56:48 <Wolf01> yes now it doesn't crash
10:57:43 <Wolf01> but seem that I didn't load the right graphics :/
10:59:43 *** SHRIKEE has joined #openttd
11:07:33 <Wolf01> uhm, there's something I can't understand, I found where it draws the road, I found other parts where it draws catenary and tram tracks but I can't find where it draws the infrastructures o_O
11:08:23 <Wolf01> it should be in the dtss (drawtileseqstruct)
11:10:03 <frosch123> _station_display_datas_bus, _station_display_datas_truck in station_land.h
11:10:30 *** smallfly has joined #openttd
11:11:04 *** FloSoft has joined #openttd
11:14:28 <Wolf01> nice, this is really complicate
11:16:12 <dihedral> will give it a try Rubidium
11:17:17 <dihedral> however, that lets me assume that spectators could not create a new company as the patch marks it a 'server' only command?
11:18:11 <Rubidium> company creation goes via another route
11:18:28 <dihedral> Rubidium, i get a kick as soon as i join the server (with wanting to create a company)
11:18:35 <dihedral> where does creating a company go another route?
11:18:50 <Rubidium> via NetworkSend_Command
11:19:17 <dihedral> WARNING: server only command from client 2 (IP: 127.0.0.1), kicking...
11:19:39 <dihedral> it kicked me for that :-P
11:20:03 <Rubidium> ah... server side checking ;)
11:21:26 *** [1]smallfly has joined #openttd
11:21:58 *** [1]smallfly is now known as smallfly
11:22:20 <dihedral> now that's a hack :-P
11:22:50 <Rubidium> but CMD_COMPANY_CTRL is kinda a hack anyways
11:23:02 <dihedral> i'll give it a shot, hang on
11:23:12 <petern> 2 wrongs makes 1 right?
11:23:34 *** |Jeroen| has joined #openttd
11:23:36 *** smeding has joined #openttd
11:23:39 <dihedral> Rubidium, have an idea how that CMD could be cleaned up?
11:23:51 <petern> i couldn't create a new company on a non-dedicated server, heh
11:23:53 <Rubidium> oh... I see petern has a better solution for the problem
11:24:20 <petern> you could add a new flag just for that feature, heh
11:24:26 <dihedral> Rubidium, why not clean it up properly, i mean CMD_COMPANY_CTRL
11:24:40 <Rubidium> it's not about cleaning up the command
11:24:48 <Rubidium> it's about allowing commands to be ran as spectator
11:28:25 <dihedral> Rubidium, works fine
11:28:40 <Rubidium> new diff, less hacky
11:29:11 <dihedral> i was gonna suggest something along those lines :-P
11:29:19 <dihedral> with a CMD_SPECTATOR
11:29:39 <petern> so a new flag is not that much effort after all :D
11:30:35 <petern> did you shuffle the order for fun?>
11:30:56 <Rubidium> just to group the stuff a bit
11:34:05 <dihedral> that'll take a while
11:41:46 *** Yeggstry has joined #openttd
11:48:50 <dihedral> Rubidium, works great :-)
11:48:52 *** smeding has joined #openttd
12:02:28 <CIA-1> OpenTTD: rubidium * r15395 /trunk/src/ (command.cpp command_type.h network/network_server.cpp): -Fix [FS#2611] (r15377): one couldn't reset companies anymore in a 'dedicated' server.
12:05:47 <Rubidium> no, I don't... stupid SpamIRC client
12:12:08 *** evandar has joined #openttd
12:12:16 *** stillunknown has joined #openttd
12:16:39 *** tkjacobsen has joined #openttd
12:37:25 *** Eddi|zuHause2 has joined #openttd
12:49:42 *** pomivehin has joined #openttd
12:52:19 *** jirofoviz has joined #openttd
12:58:41 *** OsteHovel^EEE has joined #openttd
13:26:40 *** worldemar has joined #openttd
13:30:41 *** JapaMala has joined #openttd
13:32:05 *** JapaMala is now known as |Japa|
13:49:24 *** NukeBuster has joined #openttd
13:53:53 <CIA-1> OpenTTD: smatz * r15396 /trunk/src/economy.cpp: -Fix [FS#2601](r15027): since AIs can have vehicle groups now, convert the groups correctly
14:10:09 *** bleepy is now known as Guest268
14:10:10 *** pleeby is now known as bleepy
14:24:50 *** Swallow has joined #openttd
14:41:55 *** Scuanor has joined #openttd
14:43:04 *** mortal` has joined #openttd
14:43:15 *** Mortal is now known as Guest273
14:43:15 *** mortal` is now known as Mortal
14:51:07 *** Scuanor is now known as AgentLeMan
14:51:17 <AgentLeMan> hello everybody :o)
14:54:18 *** OsteHovel^EEE has joined #openttd
14:58:07 *** Hirundo has joined #openttd
15:01:46 <AgentLeMan> why got multicore support rejected? ( i have a single core CPU, so i dont care, just curious )
15:02:32 <frosch123> because there are hardly independent tasks
15:03:33 <AgentLeMan> meaning, there isnt at all anything that would require more than one core, expecially not for the amount of work in such a change, right?
15:03:37 *** NukeBuster has joined #openttd
15:03:40 <glx> and we use multicore for aving ;)
15:03:49 *** Hirundo is now known as Swallow
15:04:52 <glx> it's not a problem of requiring multicore or not, it's a problem of doing it correctly (without slowing down single core)
15:05:07 *** Hirundo has joined #openttd
15:05:21 <AgentLeMan> yes, i can see that
15:05:30 <glx> and for openttd it's very hard to do (and not really needed either)
15:05:31 <Rubidium> planetmaker: how's the font detection goin?
15:05:39 <AgentLeMan> anyone want to show me, how i apply a diff?
15:05:40 *** Schwalbe has joined #openttd
15:06:15 *** Hirondelle has joined #openttd
15:07:06 <Progman> patch -p0 < your_patch.diff
15:09:09 *** mortal` has joined #openttd
15:11:57 *** Hirondelle is now known as Swallow
15:15:49 <OsteHovel^EEE> multicore is not needed in a game like openTTD if you wanna to use your cores compile with more than 1 thread :p
15:16:32 <|Japa|> 32bpp, however, need all the CPU it can get
15:16:53 <AgentLeMan> OsteHovel^EEE: see initial question ;oP
15:18:30 <AgentLeMan> if i checkout with turtoiseSVN, i get the last nightly as source?
15:18:55 <Aali> you get the latest revision
15:19:15 <AgentLeMan> hm, where can isee, which version that is?
15:19:31 <Aali> which could be the latest nightly, but it could also be a newer version
15:19:53 <Aali> AgentLeMan: svn log -l 1
15:20:38 *** Mortal`` has joined #openttd
15:22:14 <AgentLeMan> Aali, ah got it, 15396, thanks :o)
15:31:24 *** TinoDid is now known as TinoDidriksen
15:33:09 <Swallow> waypoint_gui.cpp uses CheckOwnership, which checks against current instead of local company
15:33:54 <Swallow> this may need a fix similar to r15336
15:36:26 *** evandar has joined #openttd
15:37:37 *** Eddi|zuHause has joined #openttd
15:40:38 *** tkjacobsen has joined #openttd
15:46:05 *** mortal` has joined #openttd
15:49:08 *** NukeBuster222 has joined #openttd
16:02:41 <CIA-1> OpenTTD: rubidium * r15397 /trunk/src/town_cmd.cpp: -Fix [FS#2618]: a town could build a statue under a bridge.
16:10:43 *** Ridayah has joined #openttd
16:11:34 <CIA-1> OpenTTD: smatz * r15398 /trunk/src/waypoint_gui.cpp: -Fix (r14135): _current_company shouldn't be used in GUI code (Swallow)
16:17:15 <CIA-1> OpenTTD: frosch * r15399 /trunk/src/newgrf_engine.cpp: -Fix [FS#2617]: For articulated parts v->cargo_type == CT_INVALID is possible.
16:22:34 *** Mortomes has joined #openttd
16:23:57 <CIA-1> OpenTTD: frosch * r15400 /trunk/src/ai/api/ (ai_event_types.hpp ai_industry.hpp ai_industrytype.hpp): -Fix: Typos in comments.
16:35:38 *** Sacro|Mac has joined #openttd
16:37:00 *** Sacro|Mac is now known as Sacro
16:47:27 *** Guisepe has joined #openttd
17:01:15 *** OsteHovel^EEE has joined #openttd
17:01:57 <CIA-1> OpenTTD: smatz * r15401 /trunk/src/ai/ai_core.cpp: -Fix [FS#2619](r15027): AI::Stop changed _current_company, but didn't restore its original value
17:02:36 <Eddi|zuHause> companies are a bitch. we should abolish them
17:14:04 *** tkjacobsen has joined #openttd
17:16:33 *** StarLionIsaac has joined #openttd
17:24:27 <Eddi|zuHause> # Darling, don't give me shit
17:24:35 <Eddi|zuHause> # 'Cause i know, that you're full of it
17:44:17 *** ChanServ sets mode: +v tokai
18:05:23 *** Roujin_ has joined #openttd
18:08:32 *** evandar has joined #openttd
18:09:42 <CIA-1> OpenTTD: smatz * r15402 /trunk/src/command.cpp: -Codechange: verify _current_company didn't change when executing a command
18:11:05 *** Roujin_ is now known as Roujin
18:23:21 *** worldemar has joined #openttd
18:27:32 <Roujin> heh, I've just updated an ancient patch
18:30:41 <Roujin> yes, actually I didn't apply anything nor did any c&p...
18:31:33 <Roujin> so I rewrote it, then ;)
18:33:36 <Roujin> parts of the old one were obsolete anyways, because it was already implemented in trunk meanwhile
18:34:20 <Roujin> it's the waypoint statistics (trains passed this month, last month & highest)..
18:46:20 <Swallow> Looks nice.. not sure whether I like the white text though
18:47:02 <Roujin> the wording, or the color?
18:47:40 <Swallow> the colour, black seems more natural to me
18:48:51 <CIA-1> OpenTTD: translators * r15403 /trunk/src/lang/ (17 files in 2 dirs): (log message trimmed)
18:48:51 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2009-02-07 18:48:00
18:48:51 <CIA-1> OpenTTD: arabic_egypt - 6 fixed by khaloofah (6)
18:48:51 <CIA-1> OpenTTD: brazilian_portuguese - 15 fixed by tucalipe (15)
18:48:51 <CIA-1> OpenTTD: catalan - 3 fixed by arnaullv (3)
18:48:53 <CIA-1> OpenTTD: dutch - 2 fixed, 21 changed by Yexo (21), Excel20 (2)
18:48:55 <CIA-1> OpenTTD: finnish - 3 fixed by jpx_ (3)
18:50:07 *** NukeBuster222 has joined #openttd
18:51:24 <Roujin> I shall change it right away... any other remarks?
18:51:28 *** Hirundo has joined #openttd
18:53:47 <Hirundo> Roujin: maybe use InvalidateWindowClasses(...) instead of invalidating every window independently in the monthly loop
18:54:13 *** Progman has joined #openttd
18:54:55 *** Hirundo is now known as Swallow
18:55:43 <Roujin> Hirundo: does that have any advantage if I have to iterate through the waypoints anyway to update their stats?
18:57:13 <Roujin> oh, I just looked at the particular functions, it is indeed better
18:57:41 <Roujin> yep, changed that. thanks
19:04:16 <Roujin> upped the new version..
19:14:59 *** lobster has joined #openttd
19:19:23 *** Roujin_ has joined #openttd
19:21:51 <Roujin_> the german translations the webtranslator update just included are..... urgh :P
19:25:04 *** Roujin_ is now known as Roujin
19:51:22 * dihedral wonders where the nightlies are
19:52:11 <Rubidium> it's waiting for Apple
19:53:40 <Roujin> yes, the compile farm runs on fruits...
19:55:15 <kd5pbo> Why's it waiting on Apple?
19:56:04 <Rubidium> cause the OSX compile is horribly slow
19:56:41 <Rubidium> takes more than half an hour to make the OSX binary
19:57:22 <Rubidium> kd5pbo: that's what I'd like to know too
19:57:36 <Rubidium> partly it's due to the fat binary containing 3 binaries
19:57:48 <Rubidium> but even then it's slower than MSVC release
20:00:13 <Rubidium> OSX took a mere 1854
20:01:13 <Rubidium> win9x + win32 + win64 'only' 531 + 500 + 546 = 1577 seconds
20:04:01 <Rubidium> for Windows that includes starting/stopping windows 3 times, extracting the sources 3 times and making the language files 3 time. For OSX it's one boot+shutdown and extraction+lang generation happens also only once
20:17:59 <Roujin> what to do.. what to do..
20:19:45 <Rubidium> except the cargodest stuff
20:20:19 <Roujin> don't you mean > #2500 ?
20:21:20 <Rubidium> being able to reproduce FS#2429/FS#2365 and fixing that would be very helpful
20:23:51 <Rubidium> you could also update the wiki's documentation
20:26:53 <Roujin> that I can do.. but right now someone needs the internet cable heh
20:27:38 <Rubidium> the < FS#2500 can be fixed without internet
20:41:24 <el_en> he could've converted ottd to c#.
20:43:14 <NukeBuster222> some issues with --with-png what exactly needs to be behind it
20:43:25 <NukeBuster222> i have libpng-config (which is available)
20:43:31 <NukeBuster222> but it doesn't work.
20:44:00 <Rubidium> --with-png=/path/to/libpng-config
20:44:07 <Rubidium> so you need to fix libpng-config
20:45:40 <NukeBuster222> you supplied '/usr/bin/libpng-config', but it seems invalid
20:45:48 <NukeBuster222> it really is at that location...
20:46:09 <NukeBuster222> do i need a specific version?
20:46:32 <NukeBuster222> i have 2:1.2.10-7.1
20:49:13 *** NukeBuster222 is now known as NukeBuster
20:49:29 <Rubidium> hmm... who gives such messed up version?
20:50:54 <Rubidium> what does /usr/bin/libpng-config --version do?
20:51:08 <Rubidium> I reckon giving an error
20:51:32 <NukeBuster> something with packageconfig
20:52:13 <Rubidium> that's not very meaningful to me
20:52:28 <Rubidium> it should return the version
20:52:38 <NukeBuster> libpng is not in the searchpath of pkg-config
20:53:17 <Rubidium> so there's some local configuration error of libpng/pkgconfig
20:53:44 <NukeBuster> i'm already searching for the libpng.pc file to check if it happens to be misplaced
21:21:41 *** NukeBuster has left #openttd
21:24:56 *** NukeBuster has joined #openttd
21:52:53 *** joepie91 has joined #openttd
21:53:07 <joepie91> i got a little question again :P
21:53:25 <joepie91> my map is so big on my multiplayer server, that everybody times out because there are too many packets being sent
21:53:34 <joepie91> is there any way to solve this, except for resetting my server? :P
21:53:58 <joepie91> (i am somewhere in year 2500 now, and the cities have grown quite big.. which means a lot of DoCommands)
21:56:40 <el_en> maybe get more bandwidth?
22:04:08 <joepie91> it's on a 100mbit server
22:04:14 <joepie91> that should be enough for an openttd server :P
22:04:27 <joepie91> and i had someone else test it
22:04:30 <joepie91> he is on 100mbit as well
22:04:49 <joepie91> so even with both ends on 100mbit, it desyncs
22:06:02 <joepie91> (I'm using Mega's Europe Map on a cargodest server, and its running for over 500 years now)
22:13:28 *** HerzogDeXtEr has joined #openttd
22:13:31 <el_en> is it that CPU load is too high then?
22:14:09 <joepie91> nope, only 15% on the server, and 10% on my pc
22:14:20 <joepie91> it is running in dedicated mode, btw
22:23:31 <Rubidium> joepie91: you're probably hitting a bug that's already fixed in trunk
22:25:32 <joepie91> but trunk doesnt have cargodest :(
22:26:09 *** lewymati has joined #openttd
22:29:54 *** NukeBuster has joined #openttd
22:30:18 *** NukeBuster has joined #openttd
22:31:43 <joepie91> so there are no other solutions?
22:32:43 <el_en> find a girlfriend and openttd desyncs will start feeling very unimportant.
22:34:41 <thingwath> not if you want to play openttd with her
22:34:59 <joepie91> i'm gay, so that wouldn't work :P
22:41:03 <joepie91> and there was a silence :P
22:44:05 <Zahl> why is the only train i can build in 2048 the SH40 and not the asiastar? O.o
22:44:27 <Mark_> because you didnt electrify your depot, probably
22:45:23 *** tkjacobsen_ has joined #openttd
22:51:04 <Zahl> Mark_: i mean they disappeard from the lift of buildable engines
22:51:35 <Zahl> and i think i disabled electric rails
22:52:19 <petern> bah, servers playing up again?
22:53:29 <Rubidium> it's a cargodest server
22:54:31 <petern> hmm, at least ssh is working, i suppose
22:55:50 <Rubidium> oh, you're talking 'bout another server
22:56:15 <petern> i'm talking about what provides our web-stuffs
22:56:25 <petern> which magically started working
22:57:09 <Rubidium> the magic of leaky lighty
22:59:38 <Rubidium> which is really annoying as we can't reliably reproduce it
22:59:59 <Rubidium> and it doesn't leak in a manner that valgrind catches it
23:05:14 <Rubidium> so it's caching something, but it doesn't clear the caching of it
23:07:01 *** DaleStan has joined #openttd
23:11:10 *** OsteHovel^EEE has joined #openttd
23:41:42 *** OsteHovel^EEE has joined #openttd
continue to next day ⏵
