IRC logs for #openttd on OFTC at 2009-07-17
⏴ go to previous day
00:14:22 *** goodger has joined #openttd
00:17:46 *** KenjiE20|LT has joined #openttd
00:30:41 <Rubidium> ofcourse what is "lot", 1 is more expensive CPU wise than 2
00:31:31 <Akoz> but it could be like 10-20% at least if I went from 1 to 2 and I have most my trains running the same track?'
00:31:44 <Akoz> guess I have some work in front of me
00:32:41 <Akoz> the server has 1400 trains now
00:34:18 *** orudge` has joined #openttd
00:34:18 *** ChanServ sets mode: +o orudge`
00:38:11 <Rubidium> the YAPF pathfinder usually caches stuff from junction to junction. Adding more junctions means smaller caches and more needs to be calculated when finding a path
00:38:11 <Rubidium> e.g. in the first image the train has to choose at least 10 times and it has to consider several times more different paths; even if the destination is straight ahead the signals cause the train to look at the neighbouring routes
00:38:11 <Rubidium> so it will calulcate and then ignore about 30 paths
00:38:11 <Rubidium> with 2 is would need to calculate 3 paths
00:38:11 <Rubidium> and with 1 it has to redo the calculations each time it reaches another junction
00:38:38 <Rubidium> even so, 1400 trains is quite a lot
00:39:12 <Akoz> yes and we're not even close to the goal
00:40:12 <Akoz> so it only calculates when it reaches a path signal?
00:40:34 <Rubidium> no, when it reaches a junction
00:40:53 <Rubidium> or even more precise, when it needs to take a decision on a junction
00:41:26 <Aali> YAPF caches some things per-path (junction)
00:41:30 <Rubidium> which means that those big washboard junctions are quite uhm... unoptimal
00:41:51 <Akoz> washboard junctions ey.. :)
00:42:04 <Akoz> unoptimal for cpu... more optimal for trains
00:42:11 <Akoz> its all about the balance
00:42:21 <Aali> but obviously signals need to be considered every time
00:42:52 <Akoz> so if theres signals every 1 step of the way (with no junctions) that takes quite some cpu as well?
00:43:17 <Rubidium> yes, but that's due to updating signal blocks
00:43:52 <Akoz> btw paths are then calculated over and over again for each decision.. theres no storage at all?
00:44:13 <Rubidium> Aali: YAPF doesn't cache paths through junctions
00:44:59 <Aali> but, straight lines (no junctions) cannot be cached entirely either, because of the signals
00:45:29 <Rubidium> Aali: they can because after a few signals the signals are ignored
00:46:05 <Rubidium> ignored for path cost calculations
00:53:34 *** KingJ is now known as kingj
00:56:38 *** delazari has joined #openttd
01:00:39 *** elmex_ is now known as elmex
01:01:24 <Akoz> how come one keeps getting more and more "unable to load save game" and "network sync errors" the longer the game you try to join has run?
01:01:27 <Akoz> and is there any workarounds?
01:02:53 <Akoz> doesnt happen during gameplay though
01:03:09 <Akoz> big games.. big load files
01:03:09 <glx> so something is not saved when it should
01:04:25 <Akoz> the clients arent modified in any way.. nor is anything to do with the savegame stuff
01:04:40 <Akoz> is this unheard of in unmodified server/clients?
01:06:05 <glx> the rule is simple, clients and server should do exactly the same and have the same state (map, cached values, ...)
01:07:27 <Akoz> afaik it has though.. all I've modified is added some extra stored values for the server only, and then I interrupt some command packages, and send some
01:07:47 <Akoz> nothing that should interfer with basic game play
01:08:00 <Akoz> or in the savefiles I mean
01:08:52 <glx> anyway sync errors are the hardest to debug
01:09:12 <Akoz> how about "unable to load savegame" ?
01:11:21 <glx> can be for many reasons, more details are available with sl debug_level (I don't know the minimum level required though)
01:12:45 <Akoz> do u know the cmd to turn off the "queried from" debug msgs?
01:14:18 <Akoz> is there a way to turn off chat ?
01:15:48 *** reldred has joined #openttd
02:24:41 *** SirSquidness has joined #openttd
02:57:27 *** sdafsdf has joined #openttd
02:57:37 *** sdafsdf is now known as LadyHawk
03:12:42 *** TinoDidriksen has joined #openttd
03:42:57 *** TinoDidriksen has joined #openttd
04:14:18 <Nebri> anybody know of some good stragety guides for new players?
06:04:54 *** Huriance has joined #openttd
06:09:12 <Forked> urgh. cellphone with wlan and a browser.. using wikipedia while on the toilet makes your legs fall asleep since you sit too long
06:32:25 *** Cybertinus has joined #openttd
08:31:02 *** [_-|t|d|e|v|-_] has joined #openttd
09:07:54 <SmatZ> wow, just received kernel panic
09:10:14 <TrueBrain> you sent something back? :)
09:10:42 <SmatZ> I am working in GUI, all I saw was blinking KB LEDs
09:10:49 <SmatZ> too bad I couldn't switch to console :(
09:10:55 <SmatZ> I would send back the report ;)
09:27:29 *** Alberth has joined #openttd
09:27:32 *** ChanServ sets mode: +v tokai
09:28:52 *** fonsinchen has joined #openttd
09:39:24 *** eleusis has joined #openttd
09:44:04 *** reldred has joined #openttd
10:15:29 *** Dred_furst has joined #openttd
10:23:28 *** kingj is now known as KingJ
10:38:20 <CIA-2> OpenTTD: alberth * r16856 /trunk/src/rail_gui.cpp: -Fix: Allow the rail toobar window to align vertically for larger sprites.
11:03:26 *** KenjiE20 has joined #openttd
11:06:07 *** Biolunar has joined #openttd
11:21:57 *** Singaporekid has joined #openttd
11:22:19 *** Dred_furst has joined #openttd
11:23:13 <SmatZ> hmm, Firefox 3.5 officially needs at least 233MHz CPU... I tried that :-/
11:25:01 <Rubidium> and, they lied didn't they?
11:26:22 <Rubidium> cause I can find no reason how to limit for processors of at least 233 MHz
11:26:39 <Rubidium> (or why, except for slowliness)
11:28:39 <SmatZ> actually, I was running it at 200MHz CPU
11:28:47 <Rubidium> if they would've said 125 MHz or 500 MHz I could've believed them
11:28:50 <SmatZ> maybe it would be magically 10 times faster at 233MHz...
11:29:17 <SmatZ> but it takes ~15 seconds to start
11:30:19 <Rubidium> hmm, there's a non-MMX 233 MHz Pentium proc too, so that can't be it either
11:31:21 <SmatZ> maybe even regular 80486 (maybe even 386 if FF doesn't need recent glibc) would suffice to "run"
11:33:38 <Rubidium> SmatZ: just get eglibc ;)
11:37:32 <Rubidium> SmatZ: ~15 seconds doesn't sound that much; with Windows it seems to be much worse with 3.5
12:13:58 *** Polygon has joined #openttd
12:18:50 *** SirSquidness has joined #openttd
12:47:51 <Akoz> oh Im sorry.. I thought u were talking to me
12:48:49 <Alberth> he is, he is probably also doing other things, and not constantly watching the irc
12:49:15 <Akoz> other things than irc? how dare he!
12:59:20 <Belugas> well.. indeed, i have a family to take care of, and work@work is my (sadly) prioroty after family
13:02:02 <Ammler> translator counter for gws: 2 :-)
13:03:48 *** Azrael- has joined #openttd
13:24:20 *** MizardX has joined #openttd
13:28:46 *** glx changes topic to "0.7.1, 0.7.2-RC1 | Website: *.openttd.org (BaNaNaS: bananas, Translator: translator, Gameservers: servers, Nightly-builds: nightly, WIKI: wiki, Dev-docs: docs, Patches & Bug-reports: bugs, Revision log: vcs, Release info: finger) | #openttd.notice for SVN notices | UTF-8 please | No Unauthorised Bots | English only :D"
13:30:54 *** Polygon has joined #openttd
13:51:00 *** MizardX has joined #openttd
13:54:19 <CIA-2> OpenTTD: smatz * r16857 /trunk/src/ (saveload/afterload.cpp train.h train_cmd.cpp): -Fix [FS#3036](r16652): crash when train partially in depot crashed
14:04:25 *** HerzogDeXtEr has joined #openttd
14:17:23 *** |Jeroen| has joined #openttd
14:30:39 *** Progman has joined #openttd
15:07:36 *** thingwath has joined #openttd
15:23:19 <Alberth> be glad, with power comes responsibility which makes life much more complicated.
15:24:18 *** DorpsGek sets mode: +o Alberth
15:24:50 *** Coco-Banana-Man has joined #openttd
15:25:09 * Alberth wouldn't know what to do with that power :)
15:25:22 *** orudge` has joined #openttd
15:25:22 *** ChanServ sets mode: +o orudge`
15:26:34 <Akoz> depends if ou want to be liked or not.
15:26:42 <Akoz> you can try /kick *.* if you want to amuse yourself
15:27:48 <SmatZ> wildcards work in /kick ?
15:28:22 <DorpsGek> SmatZ: Error: Akoz* is not in #openttd.
15:29:24 <Akoz> I havent used irc activly for 12 years or so
15:30:07 *** DorpsGek sets mode: +o SmatZ
15:30:34 <SmatZ> it works for bans though :)
15:31:00 <Akoz> hmh.. well I wouldnt want you to try that.. :p
15:31:31 <Akoz> I'll take your word for it ;)
15:36:35 * Belugas grabs the word, puts it in his coat and runs away
15:41:02 <Akoz> oh noes. he stole the word!
15:43:16 <Alberth> Let him have word, use LaTeX instead
16:13:12 *** Abenhor has joined #openttd
16:42:48 *** TheMask96 has joined #openttd
16:45:01 *** el[cube] has joined #openttd
16:55:26 *** frosch123 has joined #openttd
17:00:27 *** Phoenix_the_II has quit IRC
17:00:31 *** PhoenixII has joined #openttd
17:01:17 *** ChanServ sets mode: +v tokai
17:41:14 <Ammler> hello Yexo SmatZ and belugs :-)
17:45:37 <CIA-2> OpenTTD: translators * r16858 /trunk/src/lang/ (indonesian.txt russian.txt simplified_chinese.txt):
17:45:37 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:37 <CIA-2> OpenTTD: simplified_chinese - 1 changes by Gavin
17:45:37 <CIA-2> OpenTTD: indonesian - 1 changes by prof
17:45:37 <CIA-2> OpenTTD: russian - 16 changes by Lone_Wolf
17:51:41 <Akoz> is there a way to join the chat of an ottd game only?
17:52:10 <Yexo> not in clean OpenTTD, but with a 3rcparty wrapper it's possible
17:52:23 <frosch123> it is also possible in 0.6.x
17:52:24 <Akoz> is there any such wrappers out there?
17:52:33 <Yexo> yes, autopilot for example
17:52:46 <Yexo> avignon (I think that's a newer version of autopilot), and more
17:53:53 <Akoz> cool. let me google a bit
17:55:33 <Ammler> Akoz: active example at #openttdcoop :-)
18:13:12 *** Antigon has joined #openttd
18:34:46 <Ammler> There are 155 clients, 140 IPv4 servers and 1 IPv6 servers. <-- :-o more clients than servers
18:36:27 <Rubidium> still, < 2 players per server, so not quite "multiplayer"
18:37:42 <frosch123> make the master server refuse information about 0.6.x servers :p
18:39:00 <Alberth> simply don't count them :p
18:39:40 <Ammler> same with 0.7.0 servers
18:41:14 <frosch123> and those starting with #
18:41:26 <Ammler> sad is, still no newgrf servers.
18:41:53 <Rubidium> Ammler: no NewGRF servers?
18:42:08 <Ammler> frosch123: shall we rename to !openttdcoop?
18:42:15 <frosch123> sad is, no rc1 servers :(
18:42:55 <Ammler> Rubidium: except our and maybe brians, I didn't find one.
18:42:55 <Rubidium> that's because the peter template scared the n implementation of said template away
18:42:58 <SmatZ> hmm is there RC1 post at tt-forums?
18:43:01 <Ammler> (generic trams don't count)
18:43:29 <frosch123> SmatZ: muhahaha, you asked it first, you have to do it :p
18:44:00 <SmatZ> frosch123: ok, I guess someone should do it
18:44:41 <fonsinchen> When zooming in on the smallmap vehicles occupy more than one pixel. They are - naturally - drawn as diagonal rectangular boxes. When the smallmap is partly redrawn (for example when another window overlaps it) an orthogonal rectangular box is passed via _cur_dpi. If a vehicle is partly in that box and just moving out I get ugly artifacts. Does anyone have a spontaneous idea on how to prevent that?
18:44:41 <frosch123> but indeed, most 0.7.1 serves use generic trams
18:44:42 <SmatZ> 54560202 82E873A57BC19B24F0AE8D1EC6A6E30B
18:44:42 <Ammler> Rubidium: it uses a buggy 2cc :-)
18:45:12 <SmatZ> fonsinchen: umm don't implement zooming-in? :-x
18:45:22 <Ammler> Rubidium: it is good :P
18:45:22 <fonsinchen> I need zoom in for cargodist
18:45:39 <fonsinchen> That's the whole point of the exercise
18:45:39 <SmatZ> yeah, but you are making me hard times splitting that FS patch :)
18:46:11 <fonsinchen> Just set the limit in OnClick to ZOOM_LVL_NORMAL instead of -ZOOM_LVL_MAX
18:46:11 <Rubidium> and that's ONLY the 0.7.1 servers
18:46:34 <fonsinchen> oh, actually in ZoomIn I gues
18:46:48 <fonsinchen> but wait a minute, I have an improved version.
18:46:54 <Rubidium> SmatZ: they are using it because they are ignorant and because Addi added it to bananas for no reason
18:46:57 <Ammler> Rubidium: so 10% use newgrfs?
18:47:04 <fonsinchen> Just need to sort out that one problem ...
18:47:57 <Rubidium> Ammler: no idea, I haven't counted and can't be bothered to do that
18:50:57 <fonsinchen> Smatz, I have pushed a new version into my git repository at http://fickzoo.com/fonsinchen/openttd.git. It documents some more things in DrawSmallmap and DrawSmallmapStuff and it makes absolutely sure that DrawSmallmapStuff doesn't draw outside its dpi. This used to create some artifacts.
18:51:05 <fonsinchen> Also the code looks better now.
18:52:24 <Belugas> sanity has dropped on the floor
18:52:33 <frosch123> fonsinchen: it's friday
18:52:36 <fonsinchen> I can't solve the issue with half-drawn vehicles on zoom-in now, as I have to leave in 10 Minutes
18:53:13 <fonsinchen> And I'd like to remind you of tile iteration and diagonal levelling which is also in my git repository and always up to date with trunk.
18:53:21 <SmatZ> fonsinchen: nice set of patches
19:04:03 <Prof_Frink> Sacro: I have better plans.
19:04:56 * KenjiE20 points to the other channel
19:05:23 <Sacro> Prof_Frink: stop this confusing
19:05:56 <Prof_Frink> KenjiE20: Sacro's not in the other channel.
19:06:24 <KenjiE20> no wait... you're not in the other channel
19:06:34 <Sacro> no, i'm banned from the other channel
19:07:58 <Sacro> KenjiE20: there is 'another channel', i am aware of its existence but have not been invited to join it
19:07:58 <Sacro> suffice to say there are possibly some people in there that don't wish for me to be there
19:08:04 <KenjiE20> I was thinking #openttd and #tycoon alter-verses
19:12:42 *** Boombox has joined #openttd
19:14:03 *** Boombox has joined #openttd
19:29:28 <Belugas> heheh Boombox is not a loud box
19:30:00 <Akoz> what do I do wrong when I get error C2471: cannot update program database '...\objs\win32\debug\openttd.pdb' ...\src\rev.cpp when compiling?
19:41:59 *** orudge` has joined #openttd
19:41:59 *** ChanServ sets mode: +o orudge`
19:44:27 <CIA-2> OpenTTD: rubidium * r16859 /trunk/src/ (6 files): -Codechange: split the Station struct into two so parts of it can be reused for Waypoints.
19:49:38 <Belugas> heheh... would not be he first time, i guess :)
20:00:56 <SpComb> structure-oriented programming
20:21:36 <CIA-2> OpenTTD: rubidium * r16860 /trunk/src/ (4 files in 2 dirs): -Codechange: introduce a helper to assign a station spec to Waypoints
20:29:35 *** Zephyris has joined #openttd
20:30:19 <CIA-2> OpenTTD: rubidium * r16861 /trunk/src/ (station.cpp station_base.h): -Codechange: move a few more bits from station to basestation (to be shared with waypoints)
20:40:42 <CIA-2> OpenTTD: rubidium * r16862 /trunk/src/ (4 files in 2 dirs): -Codechange: make waypoints use the same system of station station spec lists.
20:44:46 <Ammler> waypoints over multiple lines now?
20:47:39 <planetmaker> not yet :-) ... but newgrf waypoints maybe? hm...
20:51:37 <CIA-2> OpenTTD: rubidium * r16863 /trunk/src/ (5 files): -Codechange: GetWaypointByTile -> Waypoint::GetByTile, like used for e.g. stations
20:52:43 *** Nite_Owl has joined #openttd
20:53:53 <Nite_Owl> Hello Rubidium & SmatZ
20:54:33 * planetmaker goes compiling... I wanna see what waypoints do now :)
20:55:00 <Rubidium> except possibly crash
20:55:09 <planetmaker> well :-) I don't expect them to be different with orders, but :-)
20:55:43 <planetmaker> Should I find a crash... well, not what I hope for, but alas, also useful
21:04:42 *** Brianetta has joined #openttd
21:06:08 *** Chruker has joined #openttd
21:06:19 <CIA-2> OpenTTD: rubidium * r16864 /trunk/src/ (5 files): -Codechange: make Waypoints a subclass of BaseStation.
21:06:52 <glx> planetmaker: you won't have enough time to find crashes between commits ;)
21:07:14 <planetmaker> glx, there are way worse things in life.
21:07:42 <planetmaker> And I certainly don't want to stop one of you, if you're in a commit frenzy or spree :P
21:24:40 *** KritiK_ has joined #openttd
21:24:41 *** KritiK_ is now known as KritiK
21:36:39 <CIA-2> OpenTTD: yexo * r16865 /trunk/src/ai/api/ (ai_airport.hpp ai_order.hpp ai_road.hpp ai_vehicle.hpp): -Doc [NoAI] [FS#3037]: replace old exception names with current ones and fix a type in the noai documentation (patch by Chruker)
21:42:27 *** orudge` has joined #openttd
21:42:27 *** ChanServ sets mode: +o orudge`
21:42:46 *** Progman has joined #openttd
21:46:09 <CIA-2> OpenTTD: yexo * r16866 /trunk/src/ai/api/ai_vehicle.hpp.sq: -Fix (r16865): forgot to run squirrel_export.sh
21:57:30 *** George3 has joined #openttd
22:00:26 <CIA-2> OpenTTD: frosch * r16867 /trunk/src/ (9 files): -Feature(ette): Turn variable 0E/8E (vertical offset for trains in depot) and variable 1E/9E bit 3 (wagon width in depot) into grf-local variables.
22:38:26 <Coco-Banana-Man> Is there somewhere a sound or video file with those funny horn sound of (at least the early) UKRS diesels? :D
22:47:13 <Nite_Owl> I will not swear to this but would they not have to be part of the NewGrf
22:47:52 <Nite_Owl> so if you decoded the NewGrf would they not be there
22:47:52 <DaleStan> Nite_Owl is correct. The sound file is embedded in the GRF.
22:49:35 *** DJ-Burtybob has joined #openttd
22:50:50 <DJ-Burtybob> just a quick question. would an error of "error LNK2001: unresolved external symbol _u_shapeArabic_4_0" at linking be todo with the openttd useful zip??
22:51:24 <Rubidium> did you update useful.zip?
22:51:32 <Rubidium> if so, try a full rebuild
22:51:56 <Rubidium> or at least force a rebuild of fontcache.cpp (I think)
22:52:02 <DJ-Burtybob> Yes it is a fresh set up with the latest openttd useful download from the ottd dot org site...
22:52:21 <DJ-Burtybob> hmm the file that is chucking the error is gfx.obj
22:53:00 <DJ-Burtybob> ok thanks I will try that now :D
23:03:21 <Nite_Owl> Need to feed - later all
23:18:59 <DJ-Burtybob> Ok now its erroring on "src\network\core\address.cpp(101) : error C2065: 'AI_ADDRCONFIG' : undeclared identifier" and this was a clean checkout
23:21:41 <Rubidium> you need a newer platform SDK
23:33:19 *** Eddi|zuHause has joined #openttd
23:38:05 *** XeryusTC is now known as Xeryus|bnc
continue to next day ⏵
