Times are UTC Toggle Colours
00:01:11 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has joined #openttd 00:02:04 <Eddi|zuHause> is it intended that there's neither makefile in media/extra_grf nor a target in the standard makefile? or am i just overlooking stuff? 00:04:22 *** KenjiE20 [~KenjiE20@92.9.138.165] has quit [Quit: Boo Humbug] 00:04:25 *** noom [~chatzilla@wopr-p-144-134-185-173.prem.tmns.net.au] has joined #openttd 00:04:40 <noom> hello again fellow transporters 00:04:51 <noom> i have yet more nooby questions - if anyones about :) 00:08:28 <davis> don't ask to ask , just ask 00:08:37 <noom> hahahahahaha 00:08:42 <davis> anyone will possibly answer your questions at some point 00:08:48 <noom> you dont happen to moderate a certain mmo called wurm do you ? :p 00:08:57 <noom> i've had that exact response in their IRC :p 00:09:10 <davis> I don't , it's a common thing to say though. 00:09:24 <noom> maybe just 'cus i always start a convo like that 00:09:26 <noom> haha 00:09:27 <davis> meta questions are hardly welcome 00:09:47 <noom> *sniff* 00:09:55 <noom> alright well my first problem is oil 00:09:55 <davis> haha 00:10:04 <davis> oh yeah , it's getting expensive. 00:10:13 <noom> (in oTTD) 00:10:17 <davis> =) 00:10:25 <davis> so what's the problem 00:10:32 <noom> i used a boat to move oil to a train station, then used trains to haul it accross the entire map 00:10:37 <noom> because all my refinery's had closed 00:10:42 <noom> and well, just 'cus i wanted to 00:10:50 <davis> sure 00:10:52 <noom> anyway, they pay me bloody 6k for the haul 00:11:02 <noom> i thought distance made it more valuable? 00:11:11 <noom> this is boat / train and at least 400 tiles 00:11:30 <davis> not excactly sure about the formula 00:11:42 <davis> but the profit is usualy about time the transport takes 00:11:44 <davis> and the distance 00:11:52 <davis> and ships usualy arn't quite fast. 00:12:03 <noom> well only a small portion of the trip was the ship 00:12:06 <noom> just rig to port 00:12:13 <noom> but he was behaving very strangely 00:12:28 <noom> if there were no trains waiting for him, he would empty out into the station, but then fill back up and bugger off with it 00:12:36 <noom> like he wouldnt wait at the port for a train 00:12:43 <davis> set orders to transfer and no loading 00:12:50 <davis> or transfer and leave empty 00:12:53 <davis> something like that 00:13:24 <noom> hangon lemme open up TTD 00:13:48 <noom> i tried every combo i think 00:13:52 <noom> he also wasnt getting paid 00:13:54 <noom> for the hauls 00:14:02 <davis> http://wiki.openttd.org/Orders#Transfer 00:14:07 <noom> was losing like 3k a week in him 00:14:16 <noom> ack i closed the line lol 00:14:28 *** tokai [~tokai@port-92-195-66-43.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 00:14:31 <noom> i think i stuck him on transfer 00:14:36 <davis> By default the vehicle will also collect any waiting cargo as usual (the order will show "Transfer and take cargo"). Confusingly this can include the cargo you just dropped off! If this is not what you want, you can select "No loading" from the loading options drop-down menu (so the order now reads "Transfer and Leave Empty"). 00:14:39 <noom> but then he wouldnt do anything 00:14:39 <noom> just pop in and leave 00:14:42 <noom> with a full load 00:14:57 <noom> hangon 00:15:04 <noom> i cant combine transfer and leave empty 00:15:14 <noom> i change it to transfer and its *always* take cargo 00:15:14 <davis> transfer and no loading 00:15:48 <noom> i dont know how to do that 00:15:55 <noom> i click trsnader is say transfer and take cargo 00:16:06 <noom> i click no loading it changes to no unload and take cargo 00:16:22 <davis> welll 00:16:22 <noom> omg i'm so stupid sometimes 00:16:26 <noom> sorry about that, i foundi t 00:16:29 <davis> theres the dropdown where you select "transfer" 00:16:30 <davis> right? 00:16:36 <noom> i wasnt looking under the loading 00:16:40 <noom> just the unloading 00:16:40 <davis> haha 00:16:44 <davis> well here we go 00:16:45 <noom> thanks mate :D 00:16:50 <davis> yw. 00:17:00 <noom> yaaay 00:17:17 <noom> but i'm still only making 6k for hauling gas accross the entire map 00:17:41 <davis> well , that's one bad connection then haha 00:17:54 <noom> it may be because this tanker wasnt set up properly 00:18:06 <noom> i'll buy some new engines and fire the line back up 00:18:21 <davis> goodluck 00:18:45 <noom> i had another question 00:18:53 <noom> along this epic map-crossing line 00:19:02 <noom> the trains on there end up at 0% reliability very fast 00:19:11 <noom> whats going on there? 00:20:27 <davis> well , not entirely sure since I usualy play with disabled breakdowns 00:20:38 <noom> ah 00:20:47 <noom> what exactly is reliability anyway? 00:20:58 <noom> it seems i can increase it just by telling them to stop in for maintenance after each trip 00:21:07 <davis> yeah that's it excactly 00:21:16 <davis> it defines how often a train tends to breakdown 00:21:21 <noom> so its the rating on that particular train determined by how i use them 00:21:23 <noom> i see 00:21:30 <davis> if it's 0% , the train will breakdown every few minutes 00:21:40 <noom> so by popping maintenance visits in their orders, i can keep them more reliable 00:22:00 <noom> i'm guessing that increases running costs though 00:22:29 <davis> yes 00:22:39 <noom> ah i see what my problem is 00:22:51 <noom> my oil hauling trains had one maintenance stop, at the end of the entire trip 00:22:57 <noom> so they had to go all the way over AND back 00:23:02 <noom> i'll just pop one in after the unload 00:24:06 <davis> makes more sense 00:25:05 <noom> hahah funny 00:25:12 <noom> the old oil refinery i was hauling for closed :p 00:25:18 <noom> lucky i'm rich mwahaha 00:25:21 <noom> *funds a new one* 00:28:11 <davis> :D 00:28:34 *** dfox [~dfox@ip-89-176-209-74.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 00:29:47 <noom> thats better 00:29:55 <noom> just tested with half a train of oil 00:29:57 *** Biolunar [~mahdi@blfd-4db0f8e3.pool.mediaWays.net] has quit [Remote host closed the connection] 00:29:57 <noom> 26k 00:30:53 *** glevans2 [~glevans2@adsl-99-129-146-48.dsl.rcsntx.sbcglobal.net] has quit [Ping timeout: 480 seconds] 00:31:36 *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds] 00:31:42 <noom> ok last nooby question 00:31:47 <noom> which i'm sure is in the wiki somewhere 00:31:58 <noom> how do you increase the output of resource points such as oil rigs 00:34:07 <davis> hmm 00:34:17 <davis> well , either you service them 00:34:19 <davis> over years 00:34:24 <davis> and they usualy do increase on it's own 00:34:27 <davis> or you use the cheat 00:34:33 <davis> to increase the production values. 00:35:51 <noom> so just keep on hauling for them really 00:36:06 <noom> would servicing their other resources help too ? e.g this rig also has passengers and mail 00:36:20 <davis> not entirely sure , but i don't think it'd damage. 00:36:29 <noom> *throws a hovercraft into the fray* 00:36:46 <noom> just takes my oil tanker about 6 months to get a full load right now thats all :p 00:37:47 <davis> haha 00:39:22 <noom> just gonna have to turn off "full load" for now 00:39:26 *** glevans2 [~glevans2@adsl-99-129-146-48.dsl.rcsntx.sbcglobal.net] has joined #openttd 00:40:33 <davis> yeah sometimes thats a good choice 00:45:45 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has quit [] 00:54:35 <noom> davis: i have another question for you - do timetables serve any real purpose? seems i can gain the same effect just by creating a set of orders 00:58:33 <davis> never used any of those , so i won't be any help concerning that 00:58:38 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has quit [Ping timeout: 480 seconds] 00:59:16 <noom> *pokes the chan* anyone out there who understand scheduling in orders? 00:06:22 <Eddi|zuHause> how many times do people have to tell you to not do that? 00:07:47 <noom> this would be the first 00:07:55 <noom> *pokes the chan again* 00:14:05 *** Wizzleby [~wizzleby@pool-108-16-114-12.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 00:21:21 <SpComb> . 00:21:27 *** tokai [~tokai@port-92-195-72-50.dynamic.qsc.de] has joined #openttd 00:21:30 *** mode/#openttd [+v tokai] by ChanServ 00:21:42 <SpComb> silly SpBot was ~160s off 00:23:19 *** pugi [~pugi@p4FCC5E1C.dip.t-dialin.net] has quit [Quit: I reject your reality and substitute my own] 00:23:26 <Eddi|zuHause> oh... yes... that would explain a few things ;) 00:24:06 <SpComb> doesn't explain everything, there still something a little weird with the timestamps 00:24:09 <Eddi|zuHause> btw, i was on the logs page earlier. and on the first load, it's set to +0 timezone, and on the next loads it was set to +2 00:24:21 <SpComb> yes 00:24:30 <SpComb> the first load includes some JS that sets a cookie 00:25:11 <Eddi|zuHause> i don't think i have cookies enabled... 00:28:33 <SpComb> default tz is UTC, if it changes when you refresh, it should be the cookie thing 00:29:04 <SpComb> but what is weird is the DST wrapped hour showing up in UTC 00:29:40 <SpComb> perhaps it's something with the timezone handling and the fact that the physical logs are in a DST timezone, so it'll be fine tomorrow 00:30:38 <SpComb> (i.e. it picks one timezone and then handles the whole log file with that timezone) 00:30:58 <SpComb> but zz -> 00:36:55 *** lugo [~lugo@mgdb-4db8cf3c.pool.mediaWays.net] has quit [Quit: Leaving] 00:40:16 <Eddi|zuHause> "zz" stands for "ziemlich zÌgig" 00:47:29 *** Pulec [~pulec@static-cl093181068250.unet.cz] has quit [] 00:51:04 *** theholyduck [~holyduck@82.147.59.59] has quit [Read error: Connection reset by peer] 00:59:48 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has joined #openttd 02:08:27 *** Giordano [724f37d0@ircip2.mibbit.com] has joined #openttd 02:08:48 *** Giordano [724f37d0@ircip2.mibbit.com] has quit [] 02:10:36 *** Web-sidux463 [~Web-sidux@chello080108037041.5.11.vie.surfer.at] has joined #openttd 02:11:28 *** glx [glx@2a01:e35:2f59:c7c0:f9d2:f52:5569:2a7e] has quit [Quit: bye] 02:28:10 *** noom [~chatzilla@wopr-p-144-134-185-173.prem.tmns.net.au] has quit [Ping timeout: 480 seconds] 02:44:54 *** Lakie [~Lakie@91.84.251.149] has quit [Quit: Sleep.] 02:51:29 *** davis [~b@p5B28AB97.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 03:02:09 *** Web-sidux463 [~Web-sidux@chello080108037041.5.11.vie.surfer.at] has quit [Quit: Verlassend] 03:56:47 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has quit [Ping timeout: 480 seconds] 04:05:04 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd 04:20:40 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has joined #openttd 04:56:50 *** Eddi|zuHause2 [~johekr@p54B75169.dip.t-dialin.net] has joined #openttd 05:04:05 *** Eddi|zuHause [~johekr@p54B73FF4.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 05:28:56 *** ecke [~ecke@188.75.128.2] has joined #openttd 05:56:01 *** Eddi|zuHause2 [~johekr@p54B75169.dip.t-dialin.net] has quit [Remote host closed the connection] 05:56:17 *** Eddi|zuHause2 [~johekr@p54B75909.dip.t-dialin.net] has joined #openttd 06:15:40 <Rubidium> Eddi|zuHause2: you're overlooking something 06:20:46 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has joined #openttd 06:20:55 <andythenorth_> morning 06:21:00 <andythenorth_> stupid clock change 06:21:11 <andythenorth_> I have no idea if it went backwards or forwards, but....ow 06:21:13 <Rubidium> stupid? 06:21:26 <andythenorth_> my head hurts :P 06:21:28 <Rubidium> now my bug tracker's time setting is correct again 06:22:14 <Rubidium> andythenorth_: October is always the longest month of the year 06:28:36 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd 06:34:24 <andythenorth_> grr 06:50:36 * andythenorth_ thinks up baroque stuff 06:57:35 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has quit [Quit: Not here] 07:04:00 <peter1138> spring forward, autumn back 07:04:07 <peter1138> that works better with US seasons :( 07:06:12 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe83de00-38.dhcp.inet.fi] has joined #openttd 07:09:09 * andythenorth_ has forgotten some stuff :P 07:09:35 *** Zuu [~Zuu@2.64.192.143] has joined #openttd 07:10:30 <Terkhen> good morning 07:11:02 <andythenorth_> I have to check date as a dword, but return a byte value 07:11:06 * Terkhen hates DST too 07:11:49 <andythenorth_> if I return a dword to cb 36 where a byte is expected, what happens? 07:12:48 *** nicfer [~nicfer@190.50.29.246] has quit [Read error: Connection reset by peer] 07:28:45 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has quit [Quit: andythenorth_] 07:30:37 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd 07:43:27 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 07:43:30 *** mode/#openttd [+o Alberth] by ChanServ 08:05:21 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has joined #openttd 08:16:21 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has joined #openttd 08:28:51 *** Zuu [~Zuu@2.64.192.143] has quit [Ping timeout: 480 seconds] 08:33:45 *** Scuddles [~notme@cm70.epsilon84.maxonline.com.sg] has joined #openttd 08:35:36 <ccfreak2k> If I write a CSV file of meteorological information once every 5 seconds (a good sample rate, I think), a 2GB SD card would be full in 8.73 years. 08:36:13 *** xiong [~xiong@netblock-72-25-106-165.dslextreme.com] has joined #openttd 08:36:31 <Alberth> the weather changes every 5 seconds? 08:37:16 <ccfreak2k> Gusting wind? Yes. 08:37:56 <ccfreak2k> The values being stored would be temperature, pressure, wind speed, wind direction, rainfall, solar panel voltage and battery voltage (the last two aren't weather related, but whatever)/ 08:38:12 <ccfreak2k> And humidity. 08:40:12 <xiong> Hi. 08:40:31 <Alberth> hi 08:40:56 <xiong> YAPF, when working path signals, will attempt to reserve the *shortest* possible length of track -- up to, of course, a signal. Correct? 08:41:32 <Alberth> no 08:42:26 <Alberth> it picks the track that leads to the destination of the train 08:42:51 <Alberth> s/the track/a track/ 08:44:11 <xiong> Understood. But given two or more choices... 08:44:15 <xiong> http://wiki.openttd.org/Talk:Advanced_path_signal_layouts#Problems_with_Basic_two-way_double_track_layout 08:45:05 <xiong> "... it will not reserve a path along the left hand track for as long as is possible, but for as short as possible." 08:45:25 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has quit [Quit: leaving] 08:45:27 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd 08:46:00 <xiong> Leaving aside the truth of this; I can experiment, although it's hard to control all variables. 08:46:12 <Alberth> 'path' means path to the destination with the least cost, it has very little to do with the length of the current block 08:46:55 <xiong> Then you say that comment is wrong? Or I'm interpreting it wrong? 08:47:10 <Alberth> where cost of passing a signal from the 'correct' side is cheaper than passing it from the 'wrong' side. 08:48:19 <xiong> Yes, I understand; that's always true. Given, though, a split/join such that two paths are possible, of equal or nearly equal length, is the track chosen predictable? If so, is it controllable? 08:48:22 <Alberth> path finders are very complicated beasts, they take #signals, directoin of signals, other trains, reserved tracks, hills, etc etc etc into account. Very hard to predict what happens in a case 08:49:22 <xiong> I can certainly experiment and try to control as many variables as possible. But if it is *known* to be a random choice and uncontrollable, I won't bother. 08:49:45 <Alberth> it is deterministic, but very complex to reason about 08:49:57 <Alberth> imho too difficult 08:50:15 <xiong> I don't consider putting a standard path signal in the 'discouraged' track, wrong way, to be a decent method. The penalty for that is too high, so I think. 08:50:49 <xiong> One might end up with a train taking a really circuitous route to avoid the wrong-facing standard path sig. 08:51:36 <Alberth> I never use bi-directional signals, except with terminus platforms sometimes 08:52:02 <xiong> Well, then, it's not an issue for either of us. 08:52:21 <xiong> Frankly, I don't quite see the point of standard path signals. Perhaps that time will come. 08:52:26 <Alberth> that wiki tries to use a track in two directions. Very complicated, just add another track, and the problem is solved 08:52:49 <xiong> Yeh well, my case is not that case. 08:53:20 <Alberth> block signals allow 1 train in a block only. Very limiting for eg junctions, or platform accessing 08:53:44 <Alberth> path signals allow as many trains as there are non-crossing paths 08:54:14 <xiong> Er, I'm not talking about block signals at all. I said, standard path, as opposed to one-way path. 08:54:38 <andythenorth_> xiong: standard path signals can allow a train to 'escape' a gridlock 08:54:47 <andythenorth_> by reversing 08:54:57 <xiong> Hm. That implies sloppy signalling. 08:55:00 <andythenorth_> well yes 08:55:15 <andythenorth_> but path signals enable sloppy signalling - for a certain playing style ;) 08:55:22 <andythenorth_> ymmv 08:55:27 <Alberth> very few people do perfect signalling at all times 08:55:53 <xiong> Methinks I'd rather see the desperate train backing up in the block, seeing the 1-path, going forward again, hitting the jam, repeat repeat, and call my attention to the issue. 08:56:41 <Alberth> that may be your (as well as mine) style of playing. Other people have different ideas 08:56:44 <xiong> I do get the feeling that normal block plus presignal sets is more challenge. 08:57:04 <andythenorth_> xiong: sounds plausible 08:57:33 <xiong> So long as I'm stuck with existing signal sets, though, I simplify the problem by using 1-path signals exclusively. I get the feeling it's a cheap way out. 08:57:39 <andythenorth_> block / presignals existed before PBS, and a fully-signalled reliable network can be built with them 08:57:45 <Alberth> xiong: that's why OpenTTD has so many options, signals, etc. You can pick what you like 08:58:16 <xiong> Oh, I'm sure of it. I started with presignal trees. I just find them too hard to diagnose. 08:58:26 <xiong> But that's not why I'm here. 08:58:30 <xiong> My case is an acceleration/deceleration siding. I have mainline running along, then a parallel track, not meant for through traffic, for getting on or off. 08:59:21 <xiong> I think it would be better to be able to encourage through traffic to avoid the siding; but even were it possible, I'm not sure I'd want to forbid it entirely. 08:59:47 <xiong> So, that's my case; and that's why I asked. 09:00:23 <Alberth> http://wiki.openttd.org/Priority we have a wiki page about, but no text :( 09:00:36 * xiong looks 09:00:53 <Alberth> http://wiki.openttdcoop.org/Priority this is the real wizard solution 09:02:01 <dihedral> i read that post in the forums as a good bye actually 09:02:01 <Alberth> a simpler solution is to add some track to the main line, so a train after the blocked one at the main line can pass both 09:02:05 <dihedral> looks like i was wrong 09:02:48 <Alberth> or, if you have breakdowns enabled, it is just another source of stopping, so nothing to worry about :) 09:02:57 <Alberth> good morning dihedral 09:03:38 <dihedral> lol :-) 09:03:41 <dihedral> good morning Alberth :-) 09:03:42 * andythenorth_ bangs head 09:03:49 <andythenorth_> am I missing a way to escape a cb result? 09:04:10 <andythenorth_> renum whines about \b12 80 09:04:31 <andythenorth_> /!!Warning (209): Offset 24: Found byte 1 of a 1-byte escape while reading byte 1 of a 2-byte field. 09:05:02 <Alberth> nice error :) 09:05:09 <dihedral> anyway :-) time for church :-) 09:05:29 <xiong> Alberth, Not sure where you'd add more track to the mainline. The siding is already extra. For that matter, I have a center track, too -- I've reserved sufficient right-of-way for 5 parallel tracks, the length of the mainline. 09:05:47 <Alberth> \b12 is a byte with decimal value 12 ? if so, you could try 0C 09:06:02 <andythenorth_> :) 09:06:11 <andythenorth_> I wanted to do it with escapes 09:06:22 <xiong> This is intended to support simply a double-track mainline, though; one track each way. The other three are spare positions, for loading sidings and passing sidings. 09:06:25 <andythenorth_> sometimes using escapes creates more head-scratching work than just using hex :P 09:07:29 <Alberth> you need a more wise renum guru than me for that problem :) 09:08:18 <andythenorth_> back to hex :P 09:08:56 <Alberth> you didn't start an esc sequence at the line above by accident? 09:10:08 <andythenorth_> nah - it's a valid renum complaint 09:10:16 <andythenorth_> it's trying to help me :P 09:10:18 <Alberth> ie the error looks like you did \w\b12 09:10:27 <Alberth> or so :) 09:10:45 <andythenorth_> well the result should be \w 09:10:47 <xiong> Alberth, I may be wrong but I think the topic that applies to my case is Balancing, not Priority. 09:10:56 <andythenorth_> so \b12 80 doesn't look right to renum 09:12:45 <andythenorth_> Terkhen: do you know what result(s) for cb36 var 10 will be rv speed? 09:17:00 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has joined #openttd 09:20:56 *** snack2 [~nn@dsl-hkibrasgw1-fe7cdf00-52.dhcp.inet.fi] has joined #openttd 09:22:08 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has joined #openttd 09:26:34 *** Progman [~progman@p57A1B0C3.dip.t-dialin.net] has joined #openttd 09:27:42 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has quit [Remote host closed the connection] 09:33:08 *** X-2 [~X-2@5ED67292.cm-7-7b.dynamic.ziggo.nl] has joined #openttd 09:35:34 <Alberth> does anybody understand the meaning of T1 and T2 in http://wiki.ttdpatch.net/tiki-index.php?page=Action0Cargos#Penalty_times_and_price_factor_10_11_12_ 09:40:23 <andythenorth_> Alberth: I need to understand them for future work in FIRS 09:40:43 <andythenorth_> so they are two time windows? 09:40:56 <Alberth> it seems that way 09:41:10 <andythenorth_> expressed in game ticks? 09:41:55 <andythenorth_> and one ultimate result will be that there is a change in the gradient of the cargo payment graph at points T1 and T2? 09:42:24 <Alberth> I read it as: T1 seems a lower bound, and then a linear decreasing price upto T2. After T2, it becomes very fuzzy. 09:43:07 <andythenorth_> I'm sure it makes sense to someone :D 09:43:09 <Alberth> oh, it goes down even after after T2. Of course 09:43:17 <Alberth> +faster 09:43:19 <xiong> Here's another thing that seems to be taken for granted: signal spacing. I'm not talking now about junctions of any kind. But on straight track, what reason is there not to signal every tile? 09:43:32 <Alberth> it looks very ugly imho 09:43:52 <Alberth> and fixing mistakes with stuck trains is complicated 09:43:56 <xiong> Game default seems to be 4 but it looks as though most coop players show 2 tile signal spacing. 09:44:26 <Alberth> and I am sure they have a good reason for picking 2 and not 1 or 3 09:44:37 <xiong> Hm. Ugly, I don't worry. Stuck trains is operational. 09:44:37 <Alberth> I use 5 or 6 usually 09:46:22 <xiong> If, for example, spacing is 4 tiles and there are, say, a line of three trains, all stopped, one to a block -- let them all be 4 tile long trains -- then when the first one starts off, it will have to gain a 4 tile lead before the next in line even starts to accelerate. Tighter spacing should make jams clear faster. 09:46:33 <xiong> I'm only theorizing. 09:46:58 <Alberth> you should build for not getting jams :) 09:47:10 <xiong> But I can see that if a train gets stuck to the point where intervention is required, too many sigs might complicate issues. 09:47:14 <Alberth> the capacity increases with less long blocks 09:47:34 <xiong> Agree. And you should build for not getting stuck. ;D 09:48:07 <xiong> ... which leads me to the tightest possible spacing, 1 tile, for max capacity. 09:48:12 <Alberth> and with block length of 1, a junction will have double block length 09:48:58 <Alberth> coop players probably care more for equal block lengths 09:49:00 <xiong> Junctions is another issue entirely. I'm carefully putting the first signal after a junction with enough space in front of the signal to allow the longest planned train to wait. 09:49:44 <Alberth> rendering your tight signalling useless :) 09:49:46 <xiong> So, since I'm planning a max train length of 6 tiles, then counting the junction tile itself as 0, I put the first signal at tile 7, possibly 8. 09:50:26 <xiong> And if another junction intervenes, I don't signal it at all. I let the train going that way stop at the previous signal and wait safely until the way is clear through both junctions. 09:52:01 <xiong> Well, dunno if tight signals on the straight are useless. I really have no idea. This is all new to me. The current map is the first one I expect to build out fully. All the previous ones ran into damfool fairly quickly. 09:52:45 <xiong> This is also the first I've made an offline plan for: http://i53.tinypic.com/290xzqq.png 09:52:47 <Alberth> suppose you have an endless stream of trains. You add a block of length 7, how long spaced do the trains get? 09:53:39 <Alberth> oh, you even make a plan ahead :) 09:53:42 <xiong> Dunno, Alberth; I have to try it out. I can answer the question in hydrodynamics and electronics. 09:55:06 <Alberth> this is simple reasoning. suppose a train is in the long block. there is a train waiting after it. when can the second train start running again? 09:55:25 <Alberth> ie how many tiles are between both trains then? 09:55:31 <xiong> You seem to think that after returning to 1 tile spacing, trains would remain spaced far out, after the long block. That would be true if there were no other complications. But I *suspect* that if, further down the road, there was a slowdown, then all the 1-tile straight track would fill up. 09:57:28 <xiong> But then, I'm only reasoning by analogy with things I *do* know -- queues in chains of I/O buffers, etc. Well, at some point, I gotta try something. Coop guys seem to go with 2-tile spacing although I'm pretty sure they run some very long trains. I'll try that first. 09:57:35 <Terkhen> andythenorth_: if you mean the property that it will allow to modify, IMO the best option is 0x15 09:58:04 <andythenorth_> yes 09:58:28 <andythenorth_> but I actually meant...which value of prop 10 will correspond to speed? 09:58:30 <andythenorth_> :) 09:59:14 * andythenorth_ seeks colours which go well with dark blue lego 09:59:39 <Alberth> 0x15 seems like you got half of the question about life, the universe, and everything, covered already :p 10:01:26 *** KritiK [~Maxim@89-178-114-206.broadband.corbina.ru] has joined #openttd 10:04:26 <Terkhen> andythenorth_: unless I have understood it incorrectly, variable 10 will contain the property number in its low byte, thanks to some generic code I'm not being able to find 10:04:29 <Alberth> andythenorth_: "...t is the time the delivery took, the unit is 185 game ticks (roughly 2.5 game days)" 10:06:41 *** Eddi|zuHause2 is now known as Eddi|zuHause 10:18:22 *** Biolunar [~mahdi@blfd-4db0f8e3.pool.mediaWays.net] has joined #openttd 10:19:39 <Eddi|zuHause> Rubidium: care to point out what i'm overlooking? 10:27:21 <Alberth> haven't seen him yet 10:32:36 <Rubidium> Eddi|zuHause: ^/trunk/Makefile.grf.in ^/trunk/Makefile.am 10:32:58 <Rubidium> hmm, although... the latter doesn't exist in the repository 10:33:30 <Rubidium> so replace that with ^/trunk/configure and ^/trunk/config.lib 10:33:58 <Rubidium> and likewise objs/extra_grf/Makefile 10:34:26 <Eddi|zuHause> Rubidium: i don't understand what you're saying 10:35:08 *** xiong [~xiong@netblock-72-25-106-165.dslextreme.com] has quit [Ping timeout: 480 seconds] 10:36:09 <Rubidium> that there is a Makefile, but it isn't in media/extra_grf. Similarly to the fact that there isn't a Makefile in src/ or src/lang 10:38:22 <Eddi|zuHause> yes, but the real question was: why is there no target in trunk/Makefile? 10:39:54 <Rubidium> that's a good question 10:40:01 <Rubidium> I never needed it 10:40:08 *** KenjiE20 [~KenjiE20@92.9.138.165] has joined #openttd 10:49:31 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has quit [Ping timeout: 480 seconds] 10:56:33 *** HerzogDeXtEr1 [~Flex@88.130.187.215] has joined #openttd 11:03:09 *** HerzogDeXtEr [~Flex@88.130.185.6] has quit [Ping timeout: 480 seconds] 11:14:53 *** zachanim1 [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd 11:14:54 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has quit [Remote host closed the connection] 11:19:27 *** Pulec [~pulec@static-cl093181068250.unet.cz] has joined #openttd 11:21:57 *** Fuco [~dota.keys@188.123.106.105] has joined #openttd 11:24:12 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has quit [Remote host closed the connection] 11:37:20 *** norbert79 [~Norbi@94-21-18-183.pool.digikabel.hu] has joined #openttd 11:37:25 <norbert79> afternoon 11:37:52 <Alberth> hello 11:38:21 <Eddi|zuHause> if your time is now 13:37 you are not 1337 ;) 11:39:52 <SirSquidness> It's a good thing my time was in fact 2238 at the point you mentioned that, I say 11:40:37 *** dfox [~dfox@ip-89-176-209-74.net.upcbroadband.cz] has joined #openttd 11:41:53 <Eddi|zuHause> i apologize, i was too slow... 11:44:24 *** SmatZ [~smatz@a40-prg1-22-216.static.adsl.vol.cz] has joined #openttd 11:49:42 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has joined #openttd 12:01:43 *** zachanim1 [~zach@2506ds3-od.0.fullrate.dk] has quit [Ping timeout: 480 seconds] 12:08:47 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has joined #openttd 12:14:51 <Alberth> nice, a bridge with max speed 241km/h in 1934 :) 12:18:00 <Eddi|zuHause> why not? (steel) bridge construction hasn't changed _that_ much since then... 12:18:32 *** Chillosophy [~fu@82-170-142-99.ip.telfort.nl] has joined #openttd 12:20:08 <Terkhen> andythenorth_: http://devs.openttd.org/~terkhen/patches/rv_speed_callback/ <--- it is still untested 12:25:55 *** Eddi|zuHause is now known as Eddi|zuHause2 12:25:57 *** Eddi|zuHause2 is now known as Eddi|zuHause3 12:26:01 *** Eddi|zuHause3 is now known as Eddi|zuHause2 12:26:03 *** Eddi|zuHause2 is now known as Eddi|zuHause 12:26:07 <Eddi|zuHause> err... 12:36:47 *** lugo [~lugo@mgdb-4db8db72.pool.mediaWays.net] has joined #openttd 12:40:04 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has joined #openttd 12:41:07 <__ln__> http://www.webking.com 12:41:31 *** davis [~b@p5B28AB97.dip.t-dialin.net] has joined #openttd 12:41:32 <norbert79> __ln__: Christ, my eye 12:41:57 <Alberth> what do you expect from a site that considers itself the king of the web 12:42:11 <andythenorth_> Terkhen: I'll finish some nfo to make use of that - have to do some chores first :P 12:42:26 <Terkhen> okay :) 12:42:48 <Terkhen> I'll have to play a bit with it to check if I did not break something while unifying speed 12:47:48 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 12:49:15 *** pugi [~pugi@p4FCC5E1C.dip.t-dialin.net] has joined #openttd 12:53:27 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has joined #openttd 12:53:39 <Rubidium> Terkhen: in the last patch in the last chunk the last added line seems to be unneeded. 12:54:07 <Rubidium> the rest looks okay to me 12:54:31 <Rubidium> odd though that the road speed property is in 2 km-ish/h instead of 0.5 km-ish/h 12:56:09 <Terkhen> the math could be wrong as I find the conversions a bit confusing; I'm currently testing each one 12:57:04 <Terkhen> I'm also ignoring the "old" speed property 12:57:08 <Rubidium> the math is in the last patch, right? The rest are "simple" replacements 12:57:12 <Terkhen> yes 12:57:54 <Rubidium> the math looks okay to me 12:58:05 <Terkhen> I should also remove magic numbers or at least add comments in the most confusing parts, but I'll add those after testing 12:58:08 <Terkhen> okay, thank you :) 13:12:17 *** glx [glx@2a01:e35:2f59:c7c0:44f9:5ff5:a171:1cda] has joined #openttd 13:12:20 *** mode/#openttd [+v glx] by ChanServ 13:22:01 *** Eddi|zuHause [~johekr@p54B75909.dip.t-dialin.net] has quit [Remote host closed the connection] 13:23:35 *** Eddi|zuHause [~johekr@p54B75909.dip.t-dialin.net] has joined #openttd 13:37:23 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 13:44:00 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has joined #openttd 13:51:17 <andythenorth_> Terkhen: this should try and set speed to 0xFF 13:51:18 <andythenorth_> http://tt-foundry.com/misc/heqs-nightly-r480M.zip 13:54:20 <andythenorth_> I haven't compiled and tested with your patch yet though :P 13:54:31 <CIA-1> OpenTTD: rubidium * r21061 /branches/1.0/src/ (3 files in 3 dirs): 13:54:31 <CIA-1> OpenTTD: [1.0] -Backport from trunk: 13:54:31 <CIA-1> OpenTTD: - Fix: Missing default values for the custom town number in the world generation options (r21034) 13:54:31 <CIA-1> OpenTTD: - Fix: Dropdown menu glitched in small screenshots, when issueing them from the menu (r21031) 13:56:20 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has joined #openttd 14:05:32 *** dfox [~dfox@ip-89-176-209-74.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 14:13:49 *** dfox [~dfox@ip-89-176-209-74.net.upcbroadband.cz] has joined #openttd 14:26:09 <CIA-1> OpenTTD: smatz * r21062 /trunk/config.lib: -Codechange: append -Winit-self to compiler flags 14:31:03 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has quit [Quit: Leaving.] 14:31:41 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has joined #openttd 14:34:00 *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd 14:37:10 *** JVassie [~James@92.27.149.231] has joined #openttd 14:43:20 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has quit [Quit: andythenorth_] 14:45:43 *** avdg [~avdg@78-21-59-217.access.telenet.be] has joined #openttd 14:46:45 <CIA-1> OpenTTD: rubidium * r21063 /branches/1.0/ (8 files in 5 dirs): [1.0] -Prepare for 1.0.5-RC1 14:48:44 *** pm [~chatzilla@dslb-088-071-054-210.pools.arcor-ip.net] has joined #openttd 14:49:03 *** pm is now known as planetmaker 14:49:21 <planetmaker> hello 14:50:39 <SmatZ> hello planetmaker 14:50:52 <CIA-1> OpenTTD: rubidium * r21064 /tags/1.0.5-RC1/ (5 files in 4 dirs): -Release: 1.0.5-RC1 14:51:32 <planetmaker> nice :-) 15:03:55 <dihedral> indeed :-) 15:04:19 <__ln__> rollercoaster 1 15:05:04 <davis> great game 15:09:13 *** saronpas_ [~saronpasu@catv075-208.lan-do.ne.jp] has joined #openttd 15:09:33 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has quit [Ping timeout: 480 seconds] 15:22:48 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 15:23:57 *** tokai [~tokai@port-92-195-72-50.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 15:24:22 * norbert79 just started playing Swat 4... I am stunned :) 15:24:42 <norbert79> Harder, than I thought 15:26:12 *** tokai [~tokai@port-92-195-17-192.dynamic.qsc.de] has joined #openttd 15:26:15 *** mode/#openttd [+v tokai] by ChanServ 15:34:18 *** avdg [~avdg@78-21-59-217.access.telenet.be] has quit [Read error: Connection reset by peer] 15:34:42 *** avdg [~avdg@78-21-59-217.access.telenet.be] has joined #openttd 15:35:46 *** HerzogDeXtEr [~Flex@89.246.221.122] has joined #openttd 15:35:51 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has quit [Quit: oO] 15:35:57 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has joined #openttd 15:42:52 *** HerzogDeXtEr1 [~Flex@88.130.187.215] has quit [Ping timeout: 480 seconds] 15:44:30 *** Chruker [~no@port113.ds1-vj.adsl.cybercity.dk] has joined #openttd 15:56:13 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has quit [Quit: Leaving.] 15:56:40 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has joined #openttd 16:02:05 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has joined #openttd 16:12:16 *** davis [~b@p5B28AB97.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 16:16:38 <CIA-1> OpenTTD: michi_cc * r21065 /trunk/src/newgrf_debug_gui.cpp: -Fix (r19733): Crash when displaying 60+x parameters in the NewGRF inspect window. 16:18:53 <planetmaker> all-svn/tags> ls 16:18:54 <planetmaker> 0.6.0-beta1 0.6.0-beta2 0.6.0-beta3 0.7.0-beta1 16:18:56 <planetmaker> ^ where are actually all the other tags wrt the root svn directory? svn://svn.openttd.org/tags/1.0.5-RC1 works for me, but I don't see it on a full(!) svn checkout 16:22:38 <Rubidium> they are all there, but maybe subversion is "smart" and did an "empty" tags checkout or something 16:24:24 <planetmaker> hm 16:24:45 <planetmaker> I hoped to update all the different parts... 16:25:10 <Rubidium> svn up --depth infinity? 16:25:59 <planetmaker> I shall try :-) 16:26:37 <planetmaker> seems to work, thanks :-) 16:26:44 <Rubidium> although a full tags checkout isn't that useful 16:27:46 <planetmaker> Probably :-) 16:30:00 *** JVassie [~James@92.27.149.231] has quit [Ping timeout: 480 seconds] 16:30:45 *** JVassie [~James@92.27.149.231] has joined #openttd 16:40:47 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has quit [Quit: Leaving.] 16:41:26 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has joined #openttd 16:43:39 *** HerzogDeXtEr1 [~Flex@88.130.184.187] has joined #openttd 16:49:05 *** HerzogDeXtEr [~Flex@89.246.221.122] has quit [Ping timeout: 480 seconds] 16:53:48 *** dfox [~dfox@ip-89-176-209-74.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 17:05:12 *** Scuddles [~notme@cm70.epsilon84.maxonline.com.sg] has quit [] 17:09:43 <avdg> hmm, is there no option to choose an grf townnameset in the game options? 17:10:11 <Eddi|zuHause> sure there is 17:10:32 <Eddi|zuHause> if you load a townname grf, the option gets added. 17:10:34 <avdg> or do I have to add the grf before the game starts? 17:10:50 <planetmaker> *every* grf has to be added before the start 17:10:51 <Eddi|zuHause> townnames can never be changed after the game starts 17:11:01 <avdg> :) 17:11:13 <Eddi|zuHause> newgrf or builtin doesn't matter 17:15:47 *** XeryusTC [~AndChat@94.157.202.137] has joined #openttd 17:19:52 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has joined #openttd 17:23:41 <avdg> hmm, why does openttd prefer the inbuild townnames above the grf townnames? 17:23:59 <Eddi|zuHause> what do you mean "prefer"? 17:24:06 <Alberth> select the one you want in 'options' iirc 17:24:38 <avdg> grf townnames aren't displayed in the "game options" 17:24:57 <Eddi|zuHause> they are. 17:24:58 *** saronpas_ [~saronpasu@catv075-208.lan-do.ne.jp] has quit [Ping timeout: 480 seconds] 17:25:03 <avdg> hmm 17:25:20 <avdg> strange 17:26:09 <avdg> ah, got it 17:26:35 <avdg> so you have to load it as standard grf first, and then select in the game options 17:26:44 <Eddi|zuHause> yes 17:27:05 <avdg> I get it now :) 17:27:20 <Alberth> http://devs.openttd.org/~alberth/options.png 17:27:31 <avdg> :D 17:29:56 *** saronpasu [~saronpasu@catv075-208.lan-do.ne.jp] has quit [Ping timeout: 480 seconds] 17:45:27 <CIA-1> OpenTTD: translators * r21066 /trunk/src/lang/ (korean.txt luxembourgish.txt unfinished/thai.txt): 17:45:27 <CIA-1> OpenTTD: -Update from WebTranslator v3.0: 17:45:27 <CIA-1> OpenTTD: korean - 8 changes by junho2813 17:45:27 <CIA-1> OpenTTD: luxembourgish - 7 changes by Phreeze 17:45:27 <CIA-1> OpenTTD: thai - 140 changes by animated 17:46:19 *** fjb is now known as Guest1369 17:46:19 *** avdg [~avdg@78-21-59-217.access.telenet.be] has quit [Read error: Connection reset by peer] 17:46:20 *** fjb [~frank@p5DDFEC88.dip.t-dialin.net] has joined #openttd 17:46:48 *** avdg [~avdg@78-21-59-217.access.telenet.be] has joined #openttd 17:53:09 *** Guest1369 [~frank@p5DDFF4A3.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 17:53:52 <CIA-1> OpenTTD: rubidium * r21067 /extra/catcodec/ (Makefile changelog.txt docs/readme.txt findversion.sh): [catcodec] -Fix: documentation got installed into the wrong location 17:54:28 *** Fast2 [~Fast2@p57AF85DE.dip0.t-ipconnect.de] has joined #openttd 17:59:19 *** Jolteon [~rdl@5ad09089.bb.sky.com] has joined #openttd 17:59:29 <Jolteon> Howdy! I'm having some issues with OpenTTD. 17:59:36 <Jolteon> Are there any specific system requirements for OpenTTD? 17:59:51 <Jolteon> Its running horrendously slow on my laptop, 1.7GHz Celeron M, 0.99GB RAM. 18:00:06 <Rubidium> running with AIs? 18:00:12 <Jolteon> (I know, its not mindblowing, but I figured OpenTTD should run at a playable speed) 18:00:48 <Jolteon> Rubidium: Its slow whether I use AIs or not, but using other players is indeed slower. 18:01:17 <Rubidium> what kind of operating system and which version of OpenTTD? 18:01:31 <Alberth> CPU load ? 18:01:46 <Jolteon> 1.0.4, and 1.0.5 RC1, i've tested both, and its Vista Home Premium, Acer Aspire 5310 laptop. 18:02:11 <norbert79> Sounds like a soundcard issue 18:02:40 <Jolteon> Any way to disable sounds, or otherwise bypass the issue, if it is that? 18:02:56 <Rubidium> start with -snull (at the command line) 18:03:04 <Rubidium> or -snull -mnull (disables sound and music) 18:03:18 <norbert79> openttd.exe -snull -mnull 18:03:20 <norbert79> this way 18:03:54 <Rubidium> if that doesn't help, try -b32bpp-optimized 18:04:15 <norbert79> Jolteon: One more thing: 32 bit or 64 bit Windows? 18:04:22 <Jolteon> 32 18:04:25 <norbert79> ok 18:06:12 <Jolteon> Rubidium: that appears to have made it run smoother. (-snull and -mnull) 18:06:40 *** nicfer [~nicfer@190.50.29.246] has joined #openttd 18:06:43 <Rubidium> and with only -mnull ? 18:07:40 <Jolteon> still dodgy with just mnull 18:08:07 <Jolteon> I also use all of the open sound / music / gfx files too. (Couldn't be bothered fishing around for the TTD Disc :p) 18:09:15 <Rubidium> hmm, so now there are cases where just playing the music is horribly slow as well :( 18:09:32 <Rubidium> why are operating systems getting progressively worse over time? 18:09:57 <Rubidium> (this is a general observation, not just something pinned to a particular brand of operating systems) 18:11:12 *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing] 18:11:56 <Jolteon> Yup, well with it all disabled (snull mnull) it runs just as it does on my desktop PC. 18:12:12 <planetmaker> n(bugs) ~ n(code lines)^(1+x) ~ t: x in |R, n in |N 18:12:32 <planetmaker> x in |R+ 18:13:17 <Jolteon> hm, just noticed a minor graphical glitch too. 18:13:34 <Jolteon> Although, if I take a screenshot using ctrl+s it displays fine in the PNG o.o 18:15:52 <Jolteon> Grabbed it with my camera: http://ft.fckitupload.com/zY87/PICT0102.jpg 18:16:11 <Jolteon> Fairly obvious, but incase you can't see it right, white pixels on things, mainly the trees, for some reason. Any ideas? 18:16:46 <Rubidium> I've never seen that before 18:17:04 <Jolteon> Bleh. Damned acer laptops, more cursed than I was warned about! :p 18:17:07 * planetmaker hasn't seen it either 18:17:37 <Rubidium> does -b32bpp-optimized help? 18:17:46 <Rubidium> (as command line parameter) 18:17:50 <planetmaker> Jolteon: and the same with other trees? 18:18:14 <Rubidium> I think it's more something with a particular colour of brown 18:18:32 <Rubidium> hmm, is there something like a movie/clip running/paused behind that? 18:18:45 <Jolteon> Rubidium: no. Thats just OpenTTD + vista. 18:18:56 <Eddi|zuHause> people have reported problems with some desktop feature that changes the background 18:18:57 <Jolteon> Vista isn't even using Aero theme, its set to use the old 98/ME style start bar. 18:19:08 <Jolteon> (Mainly to speed up other things) 18:19:13 <Sacro> zomg a Jolteon 18:19:17 <Jolteon> zomg a sacrosis. 18:19:36 <Jolteon> Sacro: I bought an Acer Laptop. Not evne OpenTTD likes it :( 18:19:56 <Sacro> hmm, drivers updated? 18:20:03 <Jolteon> planetmaker: Its not as obvious on some trees, but the ones on the start screen have the most obvious in your faceness. 18:20:21 <Jolteon> I've also loaded a game, its pretty much A-OK, except the trees. No white pixels on the grass, or anything. 18:20:53 <Eddi|zuHause> memory-corruption? 18:20:57 <Rubidium> Jolteon: actually, I see the pixels on the fields as well 18:21:06 <Terkhen> see you tomorrow 18:21:13 <planetmaker> bye, Terkhen 18:21:16 <Rubidium> early night Terkhen :) 18:21:18 <planetmaker> good night to you 18:21:18 <Sacro> Yeah, i'd check dxdiag out 18:21:20 <Sacro> night Terkhen 18:21:31 <Jolteon> Rubidium: hm, possible. I didn't really move around the game, just the opening thing after I randomly generated a map 18:21:57 <Jolteon> Ah yes, just reloaded it on the laptop. Definately on the fields, also on the brown of the train tracks. 18:22:11 <Rubidium> that made me think of a particular colour of brown being replaced 18:22:20 <Eddi|zuHause> so, did you try 32bpp yet? 18:22:21 <Rubidium> which is a trick I've seen being used for playing back video 18:22:37 <Eddi|zuHause> see also known-bugs.txt 18:22:41 <Jolteon> Rubidium: nup, definately nothing running in the background, I'll try switching to windowed, see if it helped. 18:22:45 <Jolteon> hhelps* 18:23:57 *** pugi [~pugi@p4FCC5E1C.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 18:24:12 *** Jolt|Slaptop [~Leftie@5ad09089.bb.sky.com] has joined #openttd 18:24:29 <Jolt|Slaptop> thats easier than running around the room 18:24:49 *** pugi [~pugi@p4FCC309E.dip.t-dialin.net] has joined #openttd 18:25:11 <Eddi|zuHause> it's a laptop, why does that require you to run around?!? 18:25:25 <Jolt|Slaptop> well, off the bed and to the other PC that had IRC loaded :p 18:25:42 <Jolt|Slaptop> 32bpp cmd line didn't change it 18:26:33 <Jolt|Slaptop> However, making it run windowed (at the same resolution) did fix it o.o 18:27:00 <Eddi|zuHause> weird... 18:27:07 <planetmaker> nice 18:28:20 <Eddi|zuHause> i have a wild theory: being aligned every 4 pixels might mean some MMX command goes wrong (MMX commands tend to handle 4 8-bit pixels simultaneously) 18:28:23 <Jolt|Slaptop> Alright, found a pattern now, anything above 1024 x 768 causes the issue full screen, anything else works fine, full screen or not. 18:28:58 <Eddi|zuHause> but i don't know why it wouldn't be solved with 32bpp 18:32:17 <Jolt|Slaptop> the gfx is: Mobile Intel 945GM Express Chips, and the sound card that it didn't like I can't find the exact model for, just says high def audio device. 18:32:29 <Jolt|Slaptop> But OpenTTD definately seems unamused at this system :o 18:33:19 <Eddi|zuHause> Jolt|Slaptop: most likely all of these are driver issues 18:33:45 <Jolteon> All the drivers are up to date, I've already checked before I came here :p 18:35:04 *** V453000 is now known as Guest1374 18:36:27 <Jolt|Slaptop> I've also had other games running fine, was testing what in my Steam library worked earlier, Tropico and Civilization run fine, as do GTAI/II (joy of joys) 18:37:02 <Rubidium> all using directx I presume? 18:37:30 <Rubidium> as OpenTTD doesn't use directx, except for playing midis 18:38:54 <Jolt|Slaptop> Well, their system requirements state DX, so I would assume they were ran using DX, yes. (This laptop has DX10 on it) 18:39:07 *** michi_cc [michi@dude.icosahedron.de] has quit [Ping timeout: 480 seconds] 18:43:00 <Jolt|Slaptop> Ah well, using the no sound / music and reducing the res, i've got OpenTTD working to a level thats as good as my desktop, so that'll be right. 18:43:27 <Jolt|Slaptop> Still slightly confused as to whats causing the graphic distortion though o.o 18:45:15 <CIA-1> OpenTTD: translators * r21068 /trunk/src/lang/luxembourgish.txt: 18:45:15 <CIA-1> OpenTTD: -Update from WebTranslator v3.0: 18:45:15 <CIA-1> OpenTTD: luxembourgish - 9 changes by Phreeze 18:46:54 *** Jolt|Slaptop [~Leftie@5ad09089.bb.sky.com] has quit [Quit: Oh Teh Noes!] 18:47:05 <Jolteon> Quite. 18:47:44 *** michi_cc [michi@dude.icosahedron.de] has joined #openttd 18:47:48 *** mode/#openttd [+v michi_cc] by ChanServ 18:48:52 *** Eddi|zuHause [~johekr@p54B75909.dip.t-dialin.net] has quit [Remote host closed the connection] 18:52:15 *** Eddi|zuHause [~johekr@p54B75909.dip.t-dialin.net] has joined #openttd 18:57:02 *** Jolteon [~rdl@5ad09089.bb.sky.com] has quit [Quit: Adios!] 19:01:15 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has joined #openttd 19:08:41 *** Jolteon [~Leftie@109.73.163.17] has joined #openttd 19:14:16 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 19:26:20 <norbert79> Jolteon: Just came back... Ok, this seems to be a video-card issue. Check if your computer does not overheat, and your GPU card has enopugh cooling 19:26:40 <norbert79> Jolteon: Can be also only a driver issue, but such errors are normally present during a video-card issue 19:35:36 *** lewymati [~lewymati@89.230.159.206] has joined #openttd 19:42:09 *** |Jeroen| [~jeroen@d5152B6A8.access.telenet.be] has quit [Remote host closed the connection] 19:59:58 *** avdg [~avdg@78-21-59-217.access.telenet.be] has quit [Remote host closed the connection] 20:01:18 *** avdg [~avdg@78-21-59-217.access.telenet.be] has joined #openttd 20:05:15 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 20:06:34 *** XeryusTC [~AndChat@94.157.202.137] has quit [Quit: Bye] 20:07:08 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Remote host closed the connection] 20:07:34 <andythenorth_> Terkhen: can I have the link to the speed patch again (sorry) 20:07:36 *** XeryusTC [~XeryusTC@52490A5B.cm-4-2a.dynamic.ziggo.nl] has joined #openttd 20:11:59 <michi_cc> andythenorth_: remind :) http://www.icosahedron.de/openttd/patches/accel.patch 20:12:12 *** Lakie [~Lakie@91.84.251.149] has joined #openttd 20:12:13 <andythenorth_> ooh 20:12:57 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe83de00-38.dhcp.inet.fi] has quit [] 20:13:21 <Jolteon> norbert79: the laptop doesn't overheat, actually one of the cooler laptops i've used. 20:13:28 <Jolteon> so not sure on the gfx overheat issue. 20:15:18 <andythenorth_> michi_cc: what does it do? Changes TE values? 20:16:13 <Hirundo> Is it possible to pass certain arguments to a python class (like a class template in C++) ? 20:17:27 <michi_cc> andythenorth_: changed realistic acceleration to make it more "realistic" and "slow" the acceleration. This also affects road vehicles and in e.g. HEQS I think power and TE are quite low for the vehicle sizes which makes work not that great with the patch. 20:17:27 *** kenneth [kenneth@cpc1-nrte13-0-0-cust531.8-4.cable.virginmedia.com] has joined #openttd 20:18:53 <michi_cc> andythenorth_: As you know better than me how HEWS vehicles should behave, maybe you can check their behavior with the patch to see whether the patch constants (that are currently mostly reality-based) or the HEWS values should be changed. 20:19:04 <michi_cc> s/HEWS/HEQS/g 20:19:12 <andythenorth_> compiling now 20:19:25 <andythenorth_> testing takes some time though, might not finish tonight 20:19:41 <andythenorth_> some of the bigger vehicles are *supposed* to fail on large hills ;) 20:20:03 <andythenorth_> but they shouldn't drop to 1mph 20:20:05 *** pugi [~pugi@p4FCC309E.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 20:20:18 <michi_cc> No worries, and you certainly don't need to test every single vehicle, just some to see if the patch isn't too wrong. 20:20:56 <kenneth> can you tweak the source code for a dedicated server, compile run and will it allow a 1.0.4 client to connect with no desync ? 20:21:55 <Eddi|zuHause> the newgrf concept of "Tractive Effort" is kinda ill-designed, because it describes the resulting force, instead of the effective weight. so you can't apply friction-coefficients 20:23:03 <Eddi|zuHause> you should rather give the fraction of the weight that lies on the driven axles, and the game applies friction coefficients. but that needs changing all newgrfs 20:23:18 <Rubidium> kenneth: it depends on the changes and source code you're starting with 20:25:12 <Rubidium> but generally people asking this question are those that want to change it in such a way that it will desync 20:25:33 <andythenorth_> Eddi|zuHause: I didn't know that :o 20:25:50 <andythenorth_> but tbh, I just fool around with 'TE' until the vehicle does what I want on the default slope settings 20:25:57 <andythenorth_> I thought that was 'wrong' 20:26:01 <andythenorth_> but maybe not ;) 20:26:31 *** xiong [~xiong@netblock-72-25-106-190.dslextreme.com] has joined #openttd 20:26:41 *** Biolunar [~mahdi@blfd-4db0f8e3.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 20:27:19 <Eddi|zuHause> something else i always wondered whenever i read through the acceleration code: on slopes, the tractive effort should be reduced by the factor cos(angle) 20:27:24 *** HerzogDeXtEr [~Flex@89.246.223.45] has joined #openttd 20:27:43 <Eddi|zuHause> but i did not find anything like that anywhere in the code 20:27:51 <michi_cc> Eddi|zuHause: cos(a) ~ 1 for a near 0 20:28:32 <Eddi|zuHause> yes... but "10%" is rather not "near 0" anymore... 20:28:40 <planetmaker> it's near enough 20:29:02 <Eddi|zuHause> for 0th order approximation? 20:29:09 <michi_cc> For 5% steepness, that becomes cos(0.0873) = 0.9962 20:29:26 <planetmaker> ^ 20:30:50 <planetmaker> michi_cc: that small? 20:31:00 <michi_cc> yes, that small :) 20:31:02 <planetmaker> 10% = 0.1 * 45° slope 20:31:05 <Rubidium> well, reducing it by 99.6% is quite a lot :) 20:31:17 <planetmaker> @calc cos(pi/4) 20:31:17 <DorpsGek> planetmaker: 0.707106781187 20:31:21 <planetmaker> ^ 100% 20:31:29 <planetmaker> @calc cos(pi/40) 20:31:29 <DorpsGek> planetmaker: 0.996917333733 20:31:33 <planetmaker> ^ 10% 20:31:58 <Eddi|zuHause> er... 20:32:02 <Rubidium> that's larger than 5% 20:32:06 <planetmaker> 100% slope = 45° 20:32:07 <Eddi|zuHause> that's rubbish 20:32:14 <Eddi|zuHause> you need to do arctan(0.1) 20:32:32 <planetmaker> = 0.1 20:32:46 <Eddi|zuHause> @calc cos(arctan(0.1)) 20:32:46 <DorpsGek> Eddi|zuHause: Error: 'arctan' is not a defined function. 20:32:50 <Eddi|zuHause> @calc cos(atan(0.1)) 20:32:50 <DorpsGek> Eddi|zuHause: 0.99503719021 20:33:18 <michi_cc> It's still small 20:33:33 <planetmaker> the speed rounding is worse than 1% 20:33:39 *** HerzogDeXtEr1 [~Flex@88.130.184.187] has quit [Ping timeout: 480 seconds] 20:33:51 <planetmaker> so indeed 20:34:57 <Eddi|zuHause> so, someone should do a comment "cos(10% slope) = 0.995, so effect of angle is negligible" 20:38:16 <Eddi|zuHause> planetmaker: for 10%, arctan(x)=x, but not for 100%... 45° is DEFINITELY not near 0 for any sane definition of "near" 20:38:38 <planetmaker> I didn't say so 20:38:51 *** pugi [~pugi@p4FCC309E.dip.t-dialin.net] has joined #openttd 20:38:53 <Eddi|zuHause> planetmaker: but you used it in your calculations as if it were... 20:39:34 <planetmaker> % slope is defined as height increase per horizontal distance 20:39:50 <planetmaker> So 45° angle is 100% slope 20:39:52 <Eddi|zuHause> planetmaker: your equations result in 10*arctan(10%) = arctan(100%) 20:40:16 <Eddi|zuHause> which is not the case, because arctan is _not_ linear near 100% 20:40:33 <SmatZ> [21:39:36] <planetmaker> % slope is defined as height increase per horizontal distance 20:40:36 <SmatZ> interesting 20:40:48 <SmatZ> I thought it's the same as "grades" 20:40:54 <planetmaker> it is 20:41:02 <SmatZ> oh 20:41:12 <SmatZ> then I dont know what "grades" are :) 20:41:19 <planetmaker> except translations now play us a trick 20:41:21 <Eddi|zuHause> (delta y)/(delta x) 20:41:51 <planetmaker> http://en.wikipedia.org/wiki/Grade_%28slope%29 20:41:51 <Eddi|zuHause> = tan(angle) 20:42:12 <SmatZ> thanks :) 20:42:27 <planetmaker> Eddi|zuHause: you try to prove me wrong, but I always only argued for the small angle approx. and never said 45° is small 20:43:11 <planetmaker> the 45° case was to just illustrate the meaning of 100% slope 20:43:21 <Eddi|zuHause> from here: <planetmaker> 10% = 0.1 * 45° slope 20:43:23 <Eddi|zuHause> to here: <planetmaker> @calc cos(pi/40) 20:43:34 <planetmaker> that's 10% and small 20:43:38 <Eddi|zuHause> you implicitly used that equation above 20:44:01 <Eddi|zuHause> pi/40 is nowhere near 10% slope 20:44:17 <planetmaker> pi/4 is 45° 20:44:24 <Eddi|zuHause> because you used 1/10 * pi/4 20:44:30 <planetmaker> pi/40 is 4.5° is 10% 20:44:58 <planetmaker> well... yes :-P 20:45:05 <Rubidium> that's not quite 100% true :) 20:45:29 <planetmaker> it's off by 1.21° 20:45:41 <Eddi|zuHause> that's like 30% off :p 20:45:54 <planetmaker> I'm astrophysicists. Powers of 10 matter only 20:46:04 <SmatZ> :) 20:46:06 <Eddi|zuHause> and that's entirely my point 20:46:07 <planetmaker> everything else is of order of one 20:46:27 <Rubidium> say that to the police officer when you're going with 200 km/h through the city centre with 50 km/h limit :) 20:46:42 <planetmaker> Eddi|zuHause: you don't honestly now argue with me in order to prove that slope doesn't matter? That's all I always said... 20:46:54 <planetmaker> Rubidium: yeah ;-) 20:47:21 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 20:47:27 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has joined #openttd 20:47:55 <Eddi|zuHause> planetmaker: what i am arguing is that your "proof" is useless even by physicist standards :p 20:48:10 <planetmaker> it's good enough for this experiment 20:48:41 <planetmaker> as the result turns out to not care ;-) 20:48:55 <planetmaker> proof a posteriori ;-) 20:51:05 <Eddi|zuHause> planetmaker: it's generally a bad idea to base your decisions on wrong maths, when doing right maths is so trivial :p 20:51:25 <planetmaker> hehe :-) I won't argue there 20:58:48 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has quit [Quit: andythenorth_] 20:59:17 *** Zuu [~Zuu@2.66.47.165] has joined #openttd 21:00:20 <Zuu> planetmaker: You effectivly blocked me from posting to the new music set thread, as I do not have anything constructive to say hehe. 21:01:01 <planetmaker> :-( 21:01:33 <Zuu> I'm even less experinced with music/gfx pack coding. 21:01:55 <planetmaker> I think constructive postings there would just need to be suggestions for additional titles 21:02:00 <planetmaker> He can do everything else himself 21:02:13 <planetmaker> He has done it already 21:02:32 *** theholyduck [~holyduck@82.147.59.59] has joined #openttd 21:02:58 <Zuu> So all he wants is us to come up with some names, and then he will compose music for those names? 21:02:59 *** elho [elho@psycho.elho.net] has quit [Ping timeout: 480 seconds] 21:03:13 <planetmaker> Those are existing titles as far as I understood 21:03:29 <Zuu> Yep that's my understanding too. 21:03:47 <planetmaker> And he transforms that into midi. Those need to by titles without copyright, though 21:03:55 <planetmaker> But those titles probably all are 21:04:03 <planetmaker> He's aware of it 21:05:12 <Zuu> Oh.. I see Jingle Bells on the list :-) 21:05:44 <planetmaker> :-) 21:05:50 <Zuu> And that needs to be transformed into "Happy bus ride" or something else. 21:06:04 <planetmaker> haha :-) 21:06:21 <Zuu> Isn't that song about santa and his dears? 21:06:34 <Zuu> So maybe more like taking the cab/taxi then? 21:06:35 <planetmaker> jingle bell? yeah 21:06:54 <planetmaker> would fit egrvts in early times ;-) 21:07:00 <Zuu> :-D 21:07:02 <Eddi|zuHause> what would santa have to do with a "one horse open sleigh"? 21:07:17 *** Yexo [~Yexo@153-88-ftth.onsneteindhoven.nl] has joined #openttd 21:07:20 *** mode/#openttd [+o Yexo] by ChanServ 21:07:48 <Yexo> good evening 21:07:58 <Zuu> hmm, thinking ... "toys ride to ... " 21:08:14 <Zuu> Good eevening Yexo 21:08:23 <planetmaker> hello Yexo 21:09:31 <Zuu> "a toy on the bus" or "toy-mobile" :-p 21:13:10 <planetmaker> :-P 21:13:38 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has joined #openttd 21:14:17 <Zuu> "my airbone taxi" or "dear deer taxi, please hurry" or "tram went of track" 21:15:06 <planetmaker> You should definitely write some lyrics ;-) 21:17:53 <andythenorth_> michi_cc: the modified physics values are a little harsh on HEQS mining trucks 21:18:12 <andythenorth_> I have slope steepness 7% 21:19:18 <planetmaker> make them more powerful ;-) 21:19:30 <andythenorth_> it's quite fine-grained 21:19:39 <andythenorth_> 6% is just a little too steep 21:19:45 <andythenorth_> 5% is a little too easy 21:21:03 <michi_cc> The calculated resistance actually is less than real-life, so either real-life values just don't work too good with RVs in contrast to trains or the HEQS values are too low. 21:21:18 <andythenorth_> the HEQS hp is accurate, or a little generous 21:21:21 <andythenorth_> the TE is tricky 21:21:27 <andythenorth_> TE might be low 21:21:37 <michi_cc> Can you try increasing the TE a bit? For rubber vehicles the values seem a bit too low to me. 21:22:02 <andythenorth_> yes, but not right now :) 21:22:11 <andythenorth_> you could checkout HEQS if you want to adjust 21:22:37 <andythenorth_> it's tricky for vehicles with trailers. 21:22:37 <Eddi|zuHause> TE = weight * driven axles fraction * friction coefficient 21:23:05 <michi_cc> Even under bad road conditions the friction coefficient should be something like 0.7 of the weight on the powered axles. The only problem is to determine how much weight actually is on the powered axles. 21:23:12 <andythenorth_> exactly 21:23:14 <Eddi|zuHause> where the fraction may vary on weight distribution, not just number of axles 21:23:42 <andythenorth_> so with a vehicle that has a fifth-wheel trailer, going up hill, a great deal of the weight may not contribute to drive 21:23:54 <Eddi|zuHause> yes 21:23:58 <andythenorth_> and with drawbar trailers it's actually easier 21:24:09 <andythenorth_> none of weight contributes to drive 21:24:22 <andythenorth_> but iirc RV physics discounts weight of trailed vehicles 21:24:26 <Eddi|zuHause> i'd just ignore the trailer 21:25:04 <andythenorth_> Eddi|zuHause: when I set the values, I just tweaked until the vehicle reached a chosen speed on an n tile slope 21:25:12 <andythenorth_> I ignored the physics :P 21:25:19 <michi_cc> A simple truck (without any trailers) should have most of the weight on the powered rear axles, so 0.5 of the weight is probably a not too shabby estimate 21:25:50 <Eddi|zuHause> also problematic is the case that the weight [and thus the TE] should differ between loaded and unloaded state, which is a non-issue for rail engines 21:26:00 <andythenorth_> michi_cc: with your patch HEQS looks to perform about right with 5% slope steepness 21:26:12 <andythenorth_> however if default is 7% that implies one of us has to change somethng 21:26:25 <Eddi|zuHause> openttd default is 3% 21:26:31 <Eddi|zuHause> ttdpatch default is 5% 21:26:33 <andythenorth_> not for RVs 21:26:35 <michi_cc> Only for rail, not for road 21:27:07 <andythenorth_> If I change HEQS, it's a bit broken for older versions of openttd 21:27:11 <michi_cc> What other sets supply TE/power for realistic acceleration? The default vehicles seem to do okay with the changes. 21:27:17 <andythenorth_> and I have to do the work :P 21:27:27 <andythenorth_> eGRVTS has it, but inconsistently 21:27:36 <andythenorth_> the horses are broken 21:27:56 <andythenorth_> some of the other vehicles are a little over-powered in my view 21:30:27 <Zuu> planetmaker: "dear deer taxi" might be a good catchy refrain. :-) 21:30:41 *** perk11 [~perk11@81.17.157.195] has joined #openttd 21:30:42 <planetmaker> indeed :-) 21:32:42 <CIA-1> OpenTTD: planetmaker * r21069 /extra/website/frontpage/ (feeds.py templates/frontpage/development.html): [Website] -Change: Update outdated descriptions and link to additionally required library liblzma 21:43:55 *** fonsinchen [~fonsinche@brln-4dba83d0.pool.mediaWays.net] has quit [Remote host closed the connection] 21:44:17 *** Keyboard_Warrior [~holyduck@82.147.59.59] has joined #openttd 21:44:21 *** Keyboard_Warrior [~holyduck@82.147.59.59] has quit [] 21:45:45 <planetmaker> hm... Zuu: I don't think that the song names he mentioned need new names: those are old traditional songs (most probably). I guess he rather nees more songs ;-) 21:51:49 *** snack2 [~nn@dsl-hkibrasgw1-fe7cdf00-52.dhcp.inet.fi] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )] 21:55:38 *** marc-andre [~marc-andr@78.115.94.77] has joined #openttd 21:56:02 <marc-andre> hiho 21:56:30 *** Chillosophy [~fu@82-170-142-99.ip.telfort.nl] has quit [] 21:57:09 *** HerzogDeXtEr [~Flex@89.246.223.45] has quit [Ping timeout: 480 seconds] 21:57:38 <marc-andre> i try to get into the save games, but i wanted to ask how all the parameters are saved ? i decompressed a savegame already and opened it in a hex editor, but now i'm stuck 21:57:40 <planetmaker> hi 21:58:07 <marc-andre> am i on the right way ? 21:58:09 <planetmaker> you want to hex-edit savegames?! 21:58:27 <marc-andre> planetmaker: rather retrieve informations from the savegame (stats mostly) 21:58:59 <planetmaker> the save game is divided into chunks. 21:59:24 <Rubidium> it has a number of (RIFF) chunks. The precise definition of the data in each chunk depends on the savegame version 21:59:29 <Rubidium> there 21:59:34 <marc-andre> ok, that makes sense from what i found in the saveload.cpp 21:59:47 <Rubidium> there's no documentation about the format except what is in the source code in the saveload directory 22:00:34 <marc-andre> but besides that a savegame is compressed with zlib, is there anything else ? are the chunks themself compressed ? 22:00:37 *** theholyduck [~holyduck@82.147.59.59] has quit [Ping timeout: 480 seconds] 22:00:53 <glx> no, only the final data is compressed 22:00:55 <SmatZ> marc-andre: the whole savegame image is compressed by lzo/zlib/lzma 22:01:07 <SmatZ> it can be stored uncompressed as well 22:02:01 <marc-andre> ok, well i managed to uncompress a savegame, but besides the company names, player names and the newgrfs i couldn't find much 22:02:13 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd 22:02:17 *** perk111 [~perk11@81.17.157.195] has joined #openttd 22:02:23 <SmatZ> hello zachanima 22:02:32 <zachanima> hello SmatZ 22:02:37 <planetmaker> binary data, of course. The settings are a bunch of numbers of variable sizes. Depending on version different ones 22:02:40 <SmatZ> marc-andre: numbers are stored in big endian format 22:03:04 <planetmaker> uh. and big endian 22:03:28 <marc-andre> where are the savegame versions defined ? 22:03:43 <Rubidium> somewhere in the very beginning of the file 22:04:22 <marc-andre> same as the game version ? 22:04:34 <SmatZ> no 22:04:43 <SmatZ> extern const uint16 SAVEGAME_VERSION = 151; ///< current savegame version of OpenTTD 22:05:45 <marc-andre> ahh, i have 138 in the src file... 22:06:49 <SmatZ> if you want to gather savegame statistics, the best way is to place your code at the end of AfterLoadGame() 22:06:54 <SmatZ> and then call exit(0) 22:07:02 <marc-andre> ok, different approach : in fact i try to retrieve company stats from the savegame via python. can i do that just by decompressing the savegame ? 22:07:17 <marc-andre> without modifing the codebase 22:07:42 *** perk11 [~perk11@81.17.157.195] has quit [Ping timeout: 480 seconds] 22:07:48 <Eddi|zuHause> you can start a multiplayer server and get some basic stats through the network interface 22:07:51 <Rubidium> depends on the stats and amount of effort you want 22:07:56 <SmatZ> yes, if you know where to find those data :p 22:08:04 <marc-andre> more then the server offers... 22:08:04 <Eddi|zuHause> there are already some libs for that 22:08:24 <marc-andre> i only found libs who acces the server console 22:08:54 <Eddi|zuHause> everything further than console or network interface can only be done by source code changes 22:09:05 <marc-andre> i see 22:09:20 <Eddi|zuHause> you can't really decode the savegame without having the source, anyway... 22:09:49 <Eddi|zuHause> it's definitely not easier than changing the source to output your data 22:10:09 <Eddi|zuHause> or you could write an AI 22:10:39 <marc-andre> or a program based on the saveload code 22:11:12 <SmatZ> which would mean modifying the program everytime saveload code changes 22:11:18 <SmatZ> if you want it up-to-date 22:11:21 <Eddi|zuHause> well, you can load the savegame, start your AI, and the AI can access/output the data for you 22:11:37 <Eddi|zuHause> AI can read most data you can also view as a player 22:11:53 <marc-andre> what about a newgrf ? possible ? 22:12:03 <Eddi|zuHause> AIs are done in a scripting language called "squirrel" 22:12:17 <Eddi|zuHause> nope, newgrfs can't do that. 22:12:48 <marc-andre> ok, the AI can read the informations, but how can i output them into a file ? 22:13:27 <Eddi|zuHause> by issueing debug statements 22:13:48 <Eddi|zuHause> with the right settings, those end up in the console, which you can redirect to a file 22:14:06 <SmatZ> can AI output to console? 22:14:14 <marc-andre> well, that takes proportions i can't handle... 22:14:57 <Eddi|zuHause> SmatZ: i'm pretty sure that's possible 22:14:57 <Rubidium> SmatZ: the stdout console 22:15:05 <Rubidium> given the right debug level 22:15:27 <SmatZ> ok :) 22:15:42 <marc-andre> thanks for all your answers 22:15:55 <SmatZ> I am just not sure if AI can gather the information you want 22:15:58 <Eddi|zuHause> hm... i fear HE has now found a valid argument against action 14 :( 22:16:03 *** lewymati [~lewymati@89.230.159.206] has quit [] 22:16:31 <Eddi|zuHause> apparently finding unknown actions makes TTDPatch 2.5 barf... 22:17:48 <Rubidium> pff... he ought to make stuff compatible with stable versions, not some arbitrary beta release 22:18:33 <SmatZ> silly firefox is unusable on systems with IO load 22:18:38 <Eddi|zuHause> i don't think aiming at 2.0 improves things :p 22:19:38 <SmatZ> because it uses some werd DB engine 22:19:39 <SmatZ> that sometimes operates a lot on data stored on HDD 22:19:41 <SmatZ> causing firefox to lock up for tens of seconds 22:19:42 <SmatZ> what a crappy idea! 22:20:08 <Rubidium> Eddi|zuHause: ofcourse it does, then he can't use engine sounds either 22:21:21 <Rubidium> SmatZ: yes, firefox writes its config file and due to a FS bug syncs to disk and only when that succeeded renames 22:22:22 <SmatZ> Rubidium: well, openttd does the same :) 22:22:40 <Rubidium> yep, but only upon closing (or saveconfig) 22:24:26 <Rubidium> though the question is why he need 2.5 support. What does he expect from that? 22:24:36 *** KouDy [~KouDy@ip-78-102-180-113.net.upcbroadband.cz] has quit [Quit: Leaving.] 22:25:33 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 22:26:55 <Eddi|zuHause> a) he thinks it's more widespread than 2.6, and b) everything else in the grf is compatible, so no reason to throw that away 22:27:28 <Rubidium> ah well, it's "only" 4.|3| years old 22:27:49 <Rubidium> (give or take a day or two) 22:28:03 <Eddi|zuHause> that's younger than most of his GRFs :p 22:28:40 <Eddi|zuHause> and this is only an "update" to his 0.4x series of newships, not a 0.5 release 22:29:47 <Rubidium> ah well, it won't be on bananas so most of our users won't use it anyways. So why bother? 22:30:28 <Rubidium> especially as OpenGFX plans to go for the DOS palette, which would mean the default palette for a lot of people changes 22:30:28 <Eddi|zuHause> i'm still working on that 22:34:01 * Rubidium wonders who would be willing to go through the 4+ years of changelog to compile a 2.5b9 to 2.5b10 changelog 22:34:24 <Rubidium> as well as checking whether other commits to their trunk need to be backported 22:34:29 <planetmaker> it should be 3.0-beta1 straight 22:34:52 <planetmaker> maybe even w/o beta1 22:35:01 <Eddi|zuHause> it should be 3.0-final-don't-bother-asking 22:35:09 <planetmaker> :-) 22:36:29 <Eddi|zuHause> apparently ttdpatch is more bitchy with un-renum'd grfs... 22:37:15 *** norbert79 [~Norbi@94-21-18-183.pool.digikabel.hu] has left #openttd [] 22:42:43 *** zachanim1 [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd 22:42:57 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has quit [Remote host closed the connection] 22:42:59 *** perk111 [~perk11@81.17.157.195] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 22:48:16 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has quit [Quit: andythenorth_] 22:53:09 *** TheMask96 [martijn@sloth.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 22:54:03 *** marc-andre [~marc-andr@78.115.94.77] has quit [Remote host closed the connection] 22:54:52 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has joined #openttd 22:55:52 <Eddi|zuHause> the versioning of nforenum is... problematic... 22:56:07 <Eddi|zuHause> compare: 22:56:09 <Eddi|zuHause> NFORenum r766 - Copyright (C) 2004-2010 by Dale McCoy 22:56:16 <Eddi|zuHause> NFORenum v3.4.6 r2309 - Copyright 2004-2009 Dale McCoy. 22:56:52 <Eddi|zuHause> first should better say "v5.0 r766" 22:57:34 <Rubidium> but then when you ask: what version of NFOREnum do you run you'll get "v5.0", which isn't the right version 22:57:56 <Lakie> 5.0.1? 22:58:00 *** TheMask96 [martijn@gluttony.vhost.ne2000.nl] has joined #openttd 22:58:01 <Rubidium> even then, nforenum's binary was changed from renum to nforenum which is more problematic 22:58:59 <Eddi|zuHause> yes, but the worse headache was really to decide which one is newer... 22:59:14 <Rubidium> Eddi|zuHause: then use 5.0.0! 22:59:35 <Eddi|zuHause> it's ammlers fault 22:59:51 <Eddi|zuHause> > rpm -qf /usr/bin/nforenum 22:59:52 <Eddi|zuHause> grfcodec-5.0.r766-6.2.x86_64 22:59:59 *** andythenorth_ [~andy@cpc9-aztw25-2-0-cust133.aztw.cable.virginmedia.com] has quit [Quit: andythenorth_] 23:00:05 <Rubidium> and nforenum/grfcodec now have somewhat regular releases again, whereas it has been "released" the same way as ttdpatch for a long time (i.e. only nightlies) 23:00:27 <Rubidium> Eddi|zuHause: then don't use his nightly builds :) 23:01:26 <Rubidium> guess we should release 5.0.1 now, that'll be seen as a lower version than 5.0.rXYZ. That's going to be FUN! 23:02:08 <Rubidium> although that doesn't honour Lakie's work enough 23:02:51 <Eddi|zuHause> NFORenum 5.0.0 - Copyright (C) 2004-2010 by Dale McCoy 23:02:55 <Eddi|zuHause> better now? ;) 23:03:19 <Rubidium> should be for you :) 23:03:54 <Rubidium> unless you want to compile an OpenGFX nightly (or the extra graphics of OpenTTD in trunk) 23:04:00 <Eddi|zuHause> hm. nforenum complains that it's a version 6 grf, but openttd happily processes the action 14 anyway 23:04:14 <Eddi|zuHause> so why the limitation to version 7 grfs? 23:04:30 <Rubidium> language codes IIRC 23:05:36 <Eddi|zuHause> but that's only a consistency problem, not a technical one? 23:07:41 <Rubidium> well, it only supports the version 7 language IDs 23:08:52 <Rubidium> *and* 23:09:12 <Rubidium> action14 needs to be before action8 (or we have to scan the whole NewGRF when OpenTTD starts) 23:09:23 <Rubidium> and action8 defines the NewGRF version 23:09:51 <Eddi|zuHause> so actually you don't even know the version yet when processing the action 14? ;) 23:09:58 <Rubidium> yes 23:10:00 <Eddi|zuHause> and you silently ignore it 23:10:17 <Rubidium> OpenTTD probably does 23:10:33 <Rubidium> or it just assigns the translations to the wrong language 23:10:45 <Rubidium> (that's actually likely what happens) 23:10:57 <Eddi|zuHause> well, it did show the german translation... 23:11:27 <Eddi|zuHause> using the version 7 language codes in the action 14, and version 6 language codes in the rest of the grf 23:11:59 <Eddi|zuHause> anyway, i don't think there's a way around ttdpatch complaining about invalid sprite for older versions 23:12:05 *** Progman [~progman@p57A1B0C3.dip.t-dialin.net] has quit [Remote host closed the connection] 23:12:43 <Rubidium> there is, but that involves taking over TTDPatch development and actually releasing a new 2.5 with "ignore action 14" 23:15:56 *** Lakie` [~Lakie@91.84.251.149] has joined #openttd 23:17:30 *** xiong [~xiong@netblock-72-25-106-190.dslextreme.com] has quit [Ping timeout: 480 seconds] 23:19:04 *** Zuu [~Zuu@2.66.47.165] has quit [Ping timeout: 480 seconds] 23:23:00 *** Lakie [~Lakie@91.84.251.149] has quit [Ping timeout: 480 seconds] 23:32:04 <Eddi|zuHause> hm... compile farm fails on cargodist builds, because "bundle_xz" is not a valid make target 23:33:10 <SpComb> xz? 23:33:17 <SpComb> what is this madness 23:33:57 <Eddi|zuHause> apparently a name for lzma output files... 23:42:51 <Rubidium> Eddi|zuHause: should go okay with the next run 23:44:30 *** planetmaker [~chatzilla@dslb-088-071-054-210.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]