IRC logs for #openttd on OFTC at 2010-10-31
⏴ go to previous day
00:03:58 *** saronpasu has joined #openttd
00:04:50 <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:07:26 <noom> hello again fellow transporters
00:07:37 <noom> i have yet more nooby questions - if anyones about :)
00:11:14 <davis> don't ask to ask , just ask
00:11:29 <davis> anyone will possibly answer your questions at some point
00:11:35 <noom> you dont happen to moderate a certain mmo called wurm do you ? :p
00:11:43 <noom> i've had that exact response in their IRC :p
00:11:57 <davis> I don't , it's a common thing to say though.
00:12:10 <noom> maybe just 'cus i always start a convo like that
00:12:13 <davis> meta questions are hardly welcome
00:12:41 <noom> alright well my first problem is oil
00:12:51 <davis> oh yeah , it's getting expensive.
00:13:18 <noom> i used a boat to move oil to a train station, then used trains to haul it accross the entire map
00:13:23 <noom> because all my refinery's had closed
00:13:28 <noom> and well, just 'cus i wanted to
00:13:39 <noom> anyway, they pay me bloody 6k for the haul
00:13:48 <noom> i thought distance made it more valuable?
00:13:57 <noom> this is boat / train and at least 400 tiles
00:14:17 <davis> not excactly sure about the formula
00:14:29 <davis> but the profit is usualy about time the transport takes
00:14:38 <davis> and ships usualy arn't quite fast.
00:14:49 <noom> well only a small portion of the trip was the ship
00:15:00 <noom> but he was behaving very strangely
00:15:14 <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:15:22 <noom> like he wouldnt wait at the port for a train
00:15:29 <davis> set orders to transfer and no loading
00:15:37 <davis> or transfer and leave empty
00:16:10 <noom> hangon lemme open up TTD
00:16:34 <noom> i tried every combo i think
00:16:38 <noom> he also wasnt getting paid
00:16:54 <noom> was losing like 3k a week in him
00:17:02 <noom> ack i closed the line lol
00:17:17 <noom> i think i stuck him on transfer
00:17:22 <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:17:26 <noom> but then he wouldnt do anything
00:17:51 <noom> i cant combine transfer and leave empty
00:18:00 <noom> i change it to transfer and its *always* take cargo
00:18:01 <davis> transfer and no loading
00:18:34 <noom> i dont know how to do that
00:18:41 <noom> i click trsnader is say transfer and take cargo
00:18:52 <noom> i click no loading it changes to no unload and take cargo
00:19:09 <noom> omg i'm so stupid sometimes
00:19:13 <noom> sorry about that, i foundi t
00:19:16 <davis> theres the dropdown where you select "transfer"
00:19:22 <noom> i wasnt looking under the loading
00:20:04 <noom> but i'm still only making 6k for hauling gas accross the entire map
00:20:27 <davis> well , that's one bad connection then haha
00:20:41 <noom> it may be because this tanker wasnt set up properly
00:20:52 <noom> i'll buy some new engines and fire the line back up
00:21:39 <noom> along this epic map-crossing line
00:21:49 <noom> the trains on there end up at 0% reliability very fast
00:23:13 <davis> well , not entirely sure since I usualy play with disabled breakdowns
00:23:34 <noom> what exactly is reliability anyway?
00:23:45 <noom> it seems i can increase it just by telling them to stop in for maintenance after each trip
00:23:54 <davis> yeah that's it excactly
00:24:02 <davis> it defines how often a train tends to breakdown
00:24:07 <noom> so its the rating on that particular train determined by how i use them
00:24:16 <davis> if it's 0% , the train will breakdown every few minutes
00:24:27 <noom> so by popping maintenance visits in their orders, i can keep them more reliable
00:24:46 <noom> i'm guessing that increases running costs though
00:25:25 <noom> ah i see what my problem is
00:25:37 <noom> my oil hauling trains had one maintenance stop, at the end of the entire trip
00:25:43 <noom> so they had to go all the way over AND back
00:25:48 <noom> i'll just pop one in after the unload
00:27:59 <noom> the old oil refinery i was hauling for closed :p
00:32:41 <noom> just tested with half a train of oil
00:34:33 <noom> which i'm sure is in the wiki somewhere
00:34:44 <noom> how do you increase the output of resource points such as oil rigs
00:37:03 <davis> well , either you service them
00:37:11 <davis> and they usualy do increase on it's own
00:37:20 <davis> to increase the production values.
00:38:37 <noom> so just keep on hauling for them really
00:38:52 <noom> would servicing their other resources help too ? e.g this rig also has passengers and mail
00:39:06 <davis> not entirely sure , but i don't think it'd damage.
00:39:16 <noom> *throws a hovercraft into the fray*
00:39:33 <noom> just takes my oil tanker about 6 months to get a full load right now thats all :p
00:42:09 <noom> just gonna have to turn off "full load" for now
00:42:12 *** glevans2 has joined #openttd
00:43:20 <davis> yeah sometimes thats a good choice
00:57:22 <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
01:01:20 <davis> never used any of those , so i won't be any help concerning that
01:02:03 <noom> *pokes the chan* anyone out there who understand scheduling in orders?
01:09:09 <Eddi|zuHause> how many times do people have to tell you to not do that?
01:21:27 *** ChanServ sets mode: +v tokai
01:21:42 <SpComb> silly SpBot was ~160s off
01:23:26 <Eddi|zuHause> oh... yes... that would explain a few things ;)
01:24:06 <SpComb> doesn't explain everything, there still something a little weird with the timestamps
01: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
01:24:30 <SpComb> the first load includes some JS that sets a cookie
01:25:11 <Eddi|zuHause> i don't think i have cookies enabled...
01:28:34 <SpComb> default tz is UTC, if it changes when you refresh, it should be the cookie thing
01:29:04 <SpComb> but what is weird is the DST wrapped hour showing up in UTC
01: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
01:30:38 <SpComb> (i.e. it picks one timezone and then handles the whole log file with that timezone)
01:40:16 <Eddi|zuHause> "zz" stands for "ziemlich zügig"
01:59:48 *** saronpasu has joined #openttd
02:08:27 *** Giordano has joined #openttd
02:10:36 *** Web-sidux463 has joined #openttd
04:20:41 *** saronpasu has joined #openttd
04:56:51 *** Eddi|zuHause2 has joined #openttd
05:56:18 *** Eddi|zuHause2 has joined #openttd
06:15:41 <Rubidium> Eddi|zuHause2: you're overlooking something
06:20:47 *** andythenorth_ has joined #openttd
06:21:01 <andythenorth_> stupid clock change
06:21:12 <andythenorth_> I have no idea if it went backwards or forwards, but....ow
06:21:27 <andythenorth_> my head hurts :P
06:21:29 <Rubidium> now my bug tracker's time setting is correct again
06:22:16 <Rubidium> andythenorth_: October is always the longest month of the year
06:28:37 *** ^Spike^ has joined #openttd
06:50:37 * andythenorth_ thinks up baroque stuff
07:04:01 <peter1138> spring forward, autumn back
07:04:08 <peter1138> that works better with US seasons :(
07:06:13 *** Kurimus has joined #openttd
07:09:10 * andythenorth_ has forgotten some stuff :P
07:11:03 <andythenorth_> I have to check date as a dword, but return a byte value
07:11:50 <andythenorth_> if I return a dword to cb 36 where a byte is expected, what happens?
07:30:38 *** ^Spike^ has joined #openttd
07:43:28 *** Alberth has joined #openttd
07:43:29 *** ChanServ sets mode: +o Alberth
08:16:22 *** andythenorth_ has joined #openttd
08:33:46 *** Scuddles has joined #openttd
08:35:37 <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:32 <Alberth> the weather changes every 5 seconds?
08:37:58 <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:40:57 <xiong> YAPF, when working path signals, will attempt to reserve the *shortest* possible length of track -- up to, of course, a signal. Correct?
08:42:27 <Alberth> it picks the track that leads to the destination of the train
08:44:13 <xiong> Understood. But given two or more choices...
08:45:06 <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:29 *** zachanima has joined #openttd
08:46:02 <xiong> Leaving aside the truth of this; I can experiment, although it's hard to control all variables.
08:46:14 <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:57 <xiong> Then you say that comment is wrong? Or I'm interpreting it wrong?
08:47:12 <Alberth> where cost of passing a signal from the 'correct' side is cheaper than passing it from the 'wrong' side.
08:48:20 <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:23 <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:24 <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:46 <Alberth> it is deterministic, but very complex to reason about
08:50:16 <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:50 <xiong> One might end up with a train taking a really circuitous route to avoid the wrong-facing standard path sig.
08:51:37 <Alberth> I never use bi-directional signals, except with terminus platforms sometimes
08:52:04 <xiong> Well, then, it's not an issue for either of us.
08:52:23 <xiong> Frankly, I don't quite see the point of standard path signals. Perhaps that time will come.
08:52:28 <Alberth> that wiki tries to use a track in two directions. Very complicated, just add another track, and the problem is solved
08:52:50 <xiong> Yeh well, my case is not that case.
08:53:22 <Alberth> block signals allow 1 train in a block only. Very limiting for eg junctions, or platform accessing
08:53:46 <Alberth> path signals allow as many trains as there are non-crossing paths
08:54:16 <xiong> Er, I'm not talking about block signals at all. I said, standard path, as opposed to one-way path.
08:54:40 <andythenorth_> xiong: standard path signals can allow a train to 'escape' a gridlock
08:54:59 <xiong> Hm. That implies sloppy signalling.
08:55:17 <andythenorth_> but path signals enable sloppy signalling - for a certain playing style ;)
08:55:29 <Alberth> very few people do perfect signalling at all times
08:55:54 <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:43 <Alberth> that may be your (as well as mine) style of playing. Other people have different ideas
08:56:45 <xiong> I do get the feeling that normal block plus presignal sets is more challenge.
08:57:05 <andythenorth_> xiong: sounds plausible
08:57:34 <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:41 <andythenorth_> block / presignals existed before PBS, and a fully-signalled reliable network can be built with them
08:57:47 <Alberth> xiong: that's why OpenTTD has so many options, signals, etc. You can pick what you like
08:58:18 <xiong> Oh, I'm sure of it. I started with presignal trees. I just find them too hard to diagnose.
08:58:27 <xiong> But that's not why I'm here.
08:58:31 <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:23 <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:49 <xiong> So, that's my case; and that's why I asked.
09:02:02 <dihedral> i read that post in the forums as a good bye actually
09:02:02 <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:07 <dihedral> looks like i was wrong
09:02:49 <Alberth> or, if you have breakdowns enabled, it is just another source of stopping, so nothing to worry about :)
09:02:58 <Alberth> good morning dihedral
09:03:43 <dihedral> good morning Alberth :-)
09:03:50 <andythenorth_> am I missing a way to escape a cb result?
09:04:12 <andythenorth_> renum whines about \b12 80
09:04:32 <andythenorth_> /!!Warning (209): Offset 24: Found byte 1 of a 1-byte escape while reading byte 1 of a 2-byte field.
09:05:10 <dihedral> anyway :-) time for church :-)
09:05:30 <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:49 <Alberth> \b12 is a byte with decimal value 12 ? if so, you could try 0C
09:06:13 <andythenorth_> I wanted to do it with escapes
09:06:24 <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:26 <andythenorth_> sometimes using escapes creates more head-scratching work than just using hex :P
09:07:31 <Alberth> you need a more wise renum guru than me for that problem :)
09:08:57 <Alberth> you didn't start an esc sequence at the line above by accident?
09:10:10 <andythenorth_> nah - it's a valid renum complaint
09:10:18 <andythenorth_> it's trying to help me :P
09:10:20 <Alberth> ie the error looks like you did \w\b12
09:10:47 <andythenorth_> well the result should be \w
09:10:49 <xiong> Alberth, I may be wrong but I think the topic that applies to my case is Balancing, not Priority.
09:10:58 <andythenorth_> so \b12 80 doesn't look right to renum
09:12:47 <andythenorth_> Terkhen: do you know what result(s) for cb36 var 10 will be rv speed?
09:17:02 *** fonsinchen has joined #openttd
09:22:10 *** |Jeroen| has joined #openttd
09:26:36 *** Progman has joined #openttd
09:40:25 <andythenorth_> Alberth: I need to understand them for future work in FIRS
09:40:45 <andythenorth_> so they are two time windows?
09:41:12 <andythenorth_> expressed in game ticks?
09:41:57 <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:25 <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:09 <andythenorth_> I'm sure it makes sense to someone :D
09:43:11 <Alberth> oh, it goes down even after after T2. Of course
09:43:21 <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:34 <Alberth> it looks very ugly imho
09:43:53 <Alberth> and fixing mistakes with stuck trains is complicated
09:43:57 <xiong> Game default seems to be 4 but it looks as though most coop players show 2 tile signal spacing.
09:44:27 <Alberth> and I am sure they have a good reason for picking 2 and not 1 or 3
09:44:39 <xiong> Hm. Ugly, I don't worry. Stuck trains is operational.
09:46:24 <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:47:00 <Alberth> you should build for not getting jams :)
09:47:12 <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:16 <Alberth> the capacity increases with less long blocks
09:47:36 <xiong> Agree. And you should build for not getting stuck. ;D
09:48:08 <xiong> ... which leads me to the tightest possible spacing, 1 tile, for max capacity.
09:48:14 <Alberth> and with block length of 1, a junction will have double block length
09:49:00 <Alberth> coop players probably care more for equal block lengths
09:49:02 <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:46 <Alberth> rendering your tight signalling useless :)
09:49:48 <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:28 <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:03 <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:48 <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:40 <Alberth> oh, you even make a plan ahead :)
09:53:44 <xiong> Dunno, Alberth; I have to try it out. I can answer the question in hydrodynamics and electronics.
09:55:07 <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:26 <Alberth> ie how many tiles are between both trains then?
09:55:33 <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:30 <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:36 <Terkhen> andythenorth_: if you mean the property that it will allow to modify, IMO the best option is 0x15
09:58:30 <andythenorth_> but I actually meant...which value of prop 10 will correspond to speed?
09:59:15 * andythenorth_ seeks colours which go well with dark blue lego
09:59:41 <Alberth> 0x15 seems like you got half of the question about life, the universe, and everything, covered already :p
10:04:28 <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:31 <Alberth> andythenorth_: "...t is the time the delivery took, the unit is 185 game ticks (roughly 2.5 game days)"
10:06:43 *** Eddi|zuHause2 is now known as Eddi|zuHause
10:18:24 *** Biolunar has joined #openttd
10:19:41 <Eddi|zuHause> Rubidium: care to point out what i'm overlooking?
10:32:38 <Rubidium> Eddi|zuHause: ^/trunk/Makefile.grf.in ^/trunk/Makefile.am
10:33:00 <Rubidium> hmm, although... the latter doesn't exist in the repository
10:33:32 <Rubidium> so replace that with ^/trunk/configure and ^/trunk/config.lib
10:34:00 <Rubidium> and likewise objs/extra_grf/Makefile
10:34:28 <Eddi|zuHause> Rubidium: i don't understand what you're saying
10:36:11 <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:24 <Eddi|zuHause> yes, but the real question was: why is there no target in trunk/Makefile?
10:39:56 <Rubidium> that's a good question
10:40:10 *** KenjiE20 has joined #openttd
10:56:35 *** HerzogDeXtEr1 has joined #openttd
11:14:55 *** zachanim1 has joined #openttd
11:37:22 *** norbert79 has joined #openttd
11:38:23 <Eddi|zuHause> if your time is now 13:37 you are not 1337 ;)
11:39:54 <SirSquidness> It's a good thing my time was in fact 2238 at the point you mentioned that, I say
11:41:55 <Eddi|zuHause> i apologize, i was too slow...
11:49:44 *** fonsinchen has joined #openttd
12:08:49 *** Devroush has joined #openttd
12:14:53 <Alberth> nice, a bridge with max speed 241km/h in 1934 :)
12:18:03 <Eddi|zuHause> why not? (steel) bridge construction hasn't changed _that_ much since then...
12:18:34 *** Chillosophy has joined #openttd
12:25:57 *** Eddi|zuHause is now known as Eddi|zuHause2
12:25:59 *** Eddi|zuHause2 is now known as Eddi|zuHause3
12:26:03 *** Eddi|zuHause3 is now known as Eddi|zuHause2
12:26:05 *** Eddi|zuHause2 is now known as Eddi|zuHause
12:40:06 *** saronpasu has joined #openttd
12:41:34 <norbert79> __ln__: Christ, my eye
12:41:59 <Alberth> what do you expect from a site that considers itself the king of the web
12:42:14 <andythenorth_> Terkhen: I'll finish some nfo to make use of that - have to do some chores first :P
12:42:50 <Terkhen> I'll have to play a bit with it to check if I did not break something while unifying speed
12:53:29 *** |Jeroen| has joined #openttd
12:53:42 <Rubidium> Terkhen: in the last patch in the last chunk the last added line seems to be unneeded.
12:54:09 <Rubidium> the rest looks okay to me
12:54:33 <Rubidium> odd though that the road speed property is in 2 km-ish/h instead of 0.5 km-ish/h
12:56:11 <Terkhen> the math could be wrong as I find the conversions a bit confusing; I'm currently testing each one
12:57:07 <Terkhen> I'm also ignoring the "old" speed property
12:57:10 <Rubidium> the math is in the last patch, right? The rest are "simple" replacements
12:57:56 <Rubidium> the math looks okay to me
12:58:08 <Terkhen> I should also remove magic numbers or at least add comments in the most confusing parts, but I'll add those after testing
13:23:38 *** Eddi|zuHause has joined #openttd
13:51:20 <andythenorth_> Terkhen: this should try and set speed to 0xFF
13:54:23 <andythenorth_> I haven't compiled and tested with your patch yet though :P
13:54:33 <CIA-1> OpenTTD: rubidium * r21061 /branches/1.0/src/ (3 files in 3 dirs):
13:54:33 <CIA-1> OpenTTD: [1.0] -Backport from trunk:
13:54:33 <CIA-1> OpenTTD: - Fix: Missing default values for the custom town number in the world generation options (r21034)
13:54:33 <CIA-1> OpenTTD: - Fix: Dropdown menu glitched in small screenshots, when issueing them from the menu (r21031)
13:56:23 *** fonsinchen has joined #openttd
14:26:12 <CIA-1> OpenTTD: smatz * r21062 /trunk/config.lib: -Codechange: append -Winit-self to compiler flags
14:34:02 *** Adambean has joined #openttd
14:37:13 *** JVassie has joined #openttd
14:46:48 <CIA-1> OpenTTD: rubidium * r21063 /branches/1.0/ (8 files in 5 dirs): [1.0] -Prepare for 1.0.5-RC1
14:49:05 *** pm is now known as planetmaker
14:50:54 <CIA-1> OpenTTD: rubidium * r21064 /tags/1.0.5-RC1/ (5 files in 4 dirs): -Release: 1.0.5-RC1
15:09:16 *** saronpas_ has joined #openttd
15:24:25 * norbert79 just started playing Swat 4... I am stunned :)
15:24:45 <norbert79> Harder, than I thought
15:26:15 *** ChanServ sets mode: +v tokai
15:35:49 *** HerzogDeXtEr has joined #openttd
15:36:00 *** |Jeroen| has joined #openttd
15:44:33 *** Chruker has joined #openttd
16:02:08 *** fonsinchen has joined #openttd
16:16:41 <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:57 <planetmaker> 0.6.0-beta1 0.6.0-beta2 0.6.0-beta3 0.7.0-beta1
16:18:59 <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:41 <Rubidium> they are all there, but maybe subversion is "smart" and did an "empty" tags checkout or something
16:24:48 <planetmaker> I hoped to update all the different parts...
16:25:13 <Rubidium> svn up --depth infinity?
16:26:41 <planetmaker> seems to work, thanks :-)
16:26:47 <Rubidium> although a full tags checkout isn't that useful
16:30:48 *** JVassie has joined #openttd
16:43:43 *** HerzogDeXtEr1 has joined #openttd
17:09:46 <avdg> hmm, is there no option to choose an grf townnameset in the game options?
17:10:35 <Eddi|zuHause> if you load a townname grf, the option gets added.
17:10:37 <avdg> or do I have to add the grf before the game starts?
17:10:53 <planetmaker> *every* grf has to be added before the start
17:10:55 <Eddi|zuHause> townnames can never be changed after the game starts
17:11:17 <Eddi|zuHause> newgrf or builtin doesn't matter
17:15:50 *** XeryusTC has joined #openttd
17:19:55 *** saronpasu has joined #openttd
17:23:44 <avdg> hmm, why does openttd prefer the inbuild townnames above the grf townnames?
17:24:03 <Eddi|zuHause> what do you mean "prefer"?
17:24:10 <Alberth> select the one you want in 'options' iirc
17:24:42 <avdg> grf townnames aren't displayed in the "game options"
17:26:39 <avdg> so you have to load it as standard grf first, and then select in the game options
17:45:30 <CIA-1> OpenTTD: translators * r21066 /trunk/src/lang/ (korean.txt luxembourgish.txt unfinished/thai.txt):
17:45:30 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:45:30 <CIA-1> OpenTTD: korean - 8 changes by junho2813
17:45:30 <CIA-1> OpenTTD: luxembourgish - 7 changes by Phreeze
17:45:30 <CIA-1> OpenTTD: thai - 140 changes by animated
17:46:22 *** fjb is now known as Guest1369
17:53:56 <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:59:23 *** Jolteon has joined #openttd
17:59:32 <Jolteon> Howdy! I'm having some issues with OpenTTD.
17:59:40 <Jolteon> Are there any specific system requirements for OpenTTD?
17:59:54 <Jolteon> Its running horrendously slow on my laptop, 1.7GHz Celeron M, 0.99GB RAM.
18:00:15 <Jolteon> (I know, its not mindblowing, but I figured OpenTTD should run at a playable speed)
18:00:51 <Jolteon> Rubidium: Its slow whether I use AIs or not, but using other players is indeed slower.
18:01:21 <Rubidium> what kind of operating system and which version of OpenTTD?
18:01:50 <Jolteon> 1.0.4, and 1.0.5 RC1, i've tested both, and its Vista Home Premium, Acer Aspire 5310 laptop.
18:02:14 <norbert79> Sounds like a soundcard issue
18:02:43 <Jolteon> Any way to disable sounds, or otherwise bypass the issue, if it is that?
18:02:59 <Rubidium> start with -snull (at the command line)
18:03:08 <Rubidium> or -snull -mnull (disables sound and music)
18:03:21 <norbert79> openttd.exe -snull -mnull
18:03:58 <Rubidium> if that doesn't help, try -b32bpp-optimized
18:04:19 <norbert79> Jolteon: One more thing: 32 bit or 64 bit Windows?
18:06:15 <Jolteon> Rubidium: that appears to have made it run smoother. (-snull and -mnull)
18:06:46 <Rubidium> and with only -mnull ?
18:07:43 <Jolteon> still dodgy with just mnull
18:08:10 <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:19 <Rubidium> hmm, so now there are cases where just playing the music is horribly slow as well :(
18:09:36 <Rubidium> why are operating systems getting progressively worse over time?
18:10:00 <Rubidium> (this is a general observation, not just something pinned to a particular brand of operating systems)
18:11:59 <Jolteon> Yup, well with it all disabled (snull mnull) it runs just as it does on my desktop PC.
18:12:15 <planetmaker> n(bugs) ~ n(code lines)^(1+x) ~ t: x in |R, n in |N
18:13:21 <Jolteon> hm, just noticed a minor graphical glitch too.
18:13:37 <Jolteon> Although, if I take a screenshot using ctrl+s it displays fine in the PNG o.o
18:16:14 <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:50 <Rubidium> I've never seen that before
18:17:07 <Jolteon> Bleh. Damned acer laptops, more cursed than I was warned about! :p
18:17:10 * planetmaker hasn't seen it either
18:17:40 <Rubidium> does -b32bpp-optimized help?
18:17:49 <Rubidium> (as command line parameter)
18:17:53 <planetmaker> Jolteon: and the same with other trees?
18:18:17 <Rubidium> I think it's more something with a particular colour of brown
18:18:36 <Rubidium> hmm, is there something like a movie/clip running/paused behind that?
18:18:49 <Jolteon> Rubidium: no. Thats just OpenTTD + vista.
18:19:00 <Eddi|zuHause> people have reported problems with some desktop feature that changes the background
18:19:00 <Jolteon> Vista isn't even using Aero theme, its set to use the old 98/ME style start bar.
18:19:11 <Jolteon> (Mainly to speed up other things)
18:19:39 <Jolteon> Sacro: I bought an Acer Laptop. Not evne OpenTTD likes it :(
18:20:07 <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:24 <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:56 <Eddi|zuHause> memory-corruption?
18:21:00 <Rubidium> Jolteon: actually, I see the pixels on the fields as well
18:21:20 <Rubidium> early night Terkhen :)
18:21:22 <planetmaker> good night to you
18:21:22 <Sacro> Yeah, i'd check dxdiag out
18:21:34 <Jolteon> Rubidium: hm, possible. I didn't really move around the game, just the opening thing after I randomly generated a map
18:22:00 <Jolteon> Ah yes, just reloaded it on the laptop. Definately on the fields, also on the brown of the train tracks.
18:22:14 <Rubidium> that made me think of a particular colour of brown being replaced
18:22:23 <Eddi|zuHause> so, did you try 32bpp yet?
18:22:24 <Rubidium> which is a trick I've seen being used for playing back video
18:22:41 <Eddi|zuHause> see also known-bugs.txt
18:22:45 <Jolteon> Rubidium: nup, definately nothing running in the background, I'll try switching to windowed, see if it helped.
18:24:16 *** Jolt|Slaptop has joined #openttd
18:24:32 <Jolt|Slaptop> thats easier than running around the room
18:25:15 <Eddi|zuHause> it's a laptop, why does that require you to run around?!?
18:25:28 <Jolt|Slaptop> well, off the bed and to the other PC that had IRC loaded :p
18:25:45 <Jolt|Slaptop> 32bpp cmd line didn't change it
18:26:36 <Jolt|Slaptop> However, making it run windowed (at the same resolution) did fix it o.o
18:28:23 <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:27 <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:29:02 <Eddi|zuHause> but i don't know why it wouldn't be solved with 32bpp
18:32:21 <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:33 <Jolt|Slaptop> But OpenTTD definately seems unamused at this system :o
18:33:22 <Eddi|zuHause> Jolt|Slaptop: most likely all of these are driver issues
18:33:49 <Jolteon> All the drivers are up to date, I've already checked before I came here :p
18:35:07 *** V453000 is now known as Guest1374
18:36:31 <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:06 <Rubidium> all using directx I presume?
18:37:33 <Rubidium> as OpenTTD doesn't use directx, except for playing midis
18:38:58 <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:43:04 <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:30 <Jolt|Slaptop> Still slightly confused as to whats causing the graphic distortion though o.o
18:45:19 <CIA-1> OpenTTD: translators * r21068 /trunk/src/lang/luxembourgish.txt:
18:45:19 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:19 <CIA-1> OpenTTD: luxembourgish - 9 changes by Phreeze
18:47:48 *** michi_cc has joined #openttd
18:47:48 *** ChanServ sets mode: +v michi_cc
18:52:19 *** Eddi|zuHause has joined #openttd
19:01:19 *** andythenorth_ has joined #openttd
19:08:44 *** Jolteon has joined #openttd
19:14:20 *** Brianetta has joined #openttd
19:26:24 <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:44 <norbert79> Jolteon: Can be also only a driver issue, but such errors are normally present during a video-card issue
19:35:39 *** lewymati has joined #openttd
20:07:38 <andythenorth_> Terkhen: can I have the link to the speed patch again (sorry)
20:07:39 *** XeryusTC has joined #openttd
20:13:25 <Jolteon> norbert79: the laptop doesn't overheat, actually one of the cooler laptops i've used.
20:13:32 <Jolteon> so not sure on the gfx overheat issue.
20:15:22 <andythenorth_> michi_cc: what does it do? Changes TE values?
20:16:17 <Hirundo> Is it possible to pass certain arguments to a python class (like a class template in C++) ?
20:17:30 <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:31 *** kenneth has joined #openttd
20:18:57 <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:29 <andythenorth_> testing takes some time though, might not finish tonight
20:19:45 <andythenorth_> some of the bigger vehicles are *supposed* to fail on large hills ;)
20:20:07 <andythenorth_> but they shouldn't drop to 1mph
20:20:22 <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:21:00 <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:58 <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:07 <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:22 <Rubidium> kenneth: it depends on the changes and source code you're starting with
20:25:16 <Rubidium> but generally people asking this question are those that want to change it in such a way that it will desync
20:25:37 <andythenorth_> Eddi|zuHause: I didn't know that :o
20:25:54 <andythenorth_> but tbh, I just fool around with 'TE' until the vehicle does what I want on the default slope settings
20:26:01 <andythenorth_> I thought that was 'wrong'
20:26:05 <andythenorth_> but maybe not ;)
20:27:23 <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:28 *** HerzogDeXtEr has joined #openttd
20:27:47 <Eddi|zuHause> but i did not find anything like that anywhere in the code
20:27:54 <michi_cc> Eddi|zuHause: cos(a) ~ 1 for a near 0
20:28:35 <Eddi|zuHause> yes... but "10%" is rather not "near 0" anymore...
20:29:06 <Eddi|zuHause> for 0th order approximation?
20:29:13 <michi_cc> For 5% steepness, that becomes cos(0.0873) = 0.9962
20:30:54 <planetmaker> michi_cc: that small?
20:31:06 <planetmaker> 10% = 0.1 * 45° slope
20:31:09 <Rubidium> well, reducing it by 99.6% is quite a lot :)
20:31:21 <DorpsGek> planetmaker: 0.707106781187
20:31:33 <DorpsGek> planetmaker: 0.996917333733
20:32:06 <Rubidium> that's larger than 5%
20:32:17 <Eddi|zuHause> you need to do arctan(0.1)
20:32:50 <Eddi|zuHause> @calc cos(arctan(0.1))
20:32:50 <DorpsGek> Eddi|zuHause: Error: 'arctan' is not a defined function.
20:32:54 <Eddi|zuHause> @calc cos(atan(0.1))
20:32:54 <DorpsGek> Eddi|zuHause: 0.99503719021
20:33:37 <planetmaker> the speed rounding is worse than 1%
20:35:01 <Eddi|zuHause> so, someone should do a comment "cos(10% slope) = 0.995, so effect of angle is negligible"
20:38:20 <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:57 <Eddi|zuHause> planetmaker: but you used it in your calculations as if it were...
20:39:38 <planetmaker> % slope is defined as height increase per horizontal distance
20:39:54 <planetmaker> So 45° angle is 100% slope
20:39:56 <Eddi|zuHause> planetmaker: your equations result in 10*arctan(10%) = arctan(100%)
20:40:20 <Eddi|zuHause> which is not the case, because arctan is _not_ linear near 100%
20:40:37 <SmatZ> [21:39:36] <planetmaker> % slope is defined as height increase per horizontal distance
20:40:52 <SmatZ> I thought it's the same as "grades"
20:41:16 <SmatZ> then I dont know what "grades" are :)
20:41:23 <planetmaker> except translations now play us a trick
20:41:25 <Eddi|zuHause> (delta y)/(delta x)
20:42:31 <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:15 <planetmaker> the 45° case was to just illustrate the meaning of 100% slope
20:43:25 <Eddi|zuHause> from here: <planetmaker> 10% = 0.1 * 45° slope
20:43:27 <Eddi|zuHause> to here: <planetmaker> @calc cos(pi/40)
20:43:38 <planetmaker> that's 10% and small
20:43:42 <Eddi|zuHause> you implicitly used that equation above
20:44:05 <Eddi|zuHause> pi/40 is nowhere near 10% slope
20:44:28 <Eddi|zuHause> because you used 1/10 * pi/4
20:44:34 <planetmaker> pi/40 is 4.5° is 10%
20:45:09 <Rubidium> that's not quite 100% true :)
20:45:33 <planetmaker> it's off by 1.21°
20:45:45 <Eddi|zuHause> that's like 30% off :p
20:45:58 <planetmaker> I'm astrophysicists. Powers of 10 matter only
20:46:10 <Eddi|zuHause> and that's entirely my point
20:46:11 <planetmaker> everything else is of order of one
20:46:30 <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:46 <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:58 <planetmaker> Rubidium: yeah ;-)
20:47:31 *** andythenorth_ has joined #openttd
20:47:59 <Eddi|zuHause> planetmaker: what i am arguing is that your "proof" is useless even by physicist standards :p
20:48:14 <planetmaker> it's good enough for this experiment
20:48:45 <planetmaker> as the result turns out to not care ;-)
20:48:59 <planetmaker> proof a posteriori ;-)
20:51:09 <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:29 <planetmaker> hehe :-) I won't argue there
21:00:24 <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:37 <Zuu> I'm even less experinced with music/gfx pack coding.
21:01:59 <planetmaker> I think constructive postings there would just need to be suggestions for additional titles
21:02:04 <planetmaker> He can do everything else himself
21:02:17 <planetmaker> He has done it already
21:02:36 *** theholyduck has joined #openttd
21:03:02 <Zuu> So all he wants is us to come up with some names, and then he will compose music for those names?
21:03:17 <planetmaker> Those are existing titles as far as I understood
21:03:33 <Zuu> Yep that's my understanding too.
21:03:51 <planetmaker> And he transforms that into midi. Those need to by titles without copyright, though
21:03:59 <planetmaker> But those titles probably all are
21:05:16 <Zuu> Oh.. I see Jingle Bells on the list :-)
21:05:54 <Zuu> And that needs to be transformed into "Happy bus ride" or something else.
21:06:25 <Zuu> Isn't that song about santa and his dears?
21:06:38 <Zuu> So maybe more like taking the cab/taxi then?
21:06:39 <planetmaker> jingle bell? yeah
21:06:58 <planetmaker> would fit egrvts in early times ;-)
21:07:06 <Eddi|zuHause> what would santa have to do with a "one horse open sleigh"?
21:07:21 *** ChanServ sets mode: +o Yexo
21:08:02 <Zuu> hmm, thinking ... "toys ride to ... "
21:09:35 <Zuu> "a toy on the bus" or "toy-mobile" :-p
21:13:42 *** andythenorth_ has joined #openttd
21:14:21 <Zuu> "my airbone taxi" or "dear deer taxi, please hurry" or "tram went of track"
21:15:10 <planetmaker> You should definitely write some lyrics ;-)
21:17:57 <andythenorth_> michi_cc: the modified physics values are a little harsh on HEQS mining trucks
21:18:16 <andythenorth_> I have slope steepness 7%
21:19:22 <planetmaker> make them more powerful ;-)
21:19:34 <andythenorth_> it's quite fine-grained
21:19:43 <andythenorth_> 6% is just a little too steep
21:19:49 <andythenorth_> 5% is a little too easy
21:21:07 <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:22 <andythenorth_> the HEQS hp is accurate, or a little generous
21:21:25 <andythenorth_> the TE is tricky
21:21:31 <andythenorth_> TE might be low
21:21:41 <michi_cc> Can you try increasing the TE a bit? For rubber vehicles the values seem a bit too low to me.
21:22:06 <andythenorth_> yes, but not right now :)
21:22:16 <andythenorth_> you could checkout HEQS if you want to adjust
21:22:41 <andythenorth_> it's tricky for vehicles with trailers.
21:22:41 <Eddi|zuHause> TE = weight * driven axles fraction * friction coefficient
21:23:09 <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:18 <Eddi|zuHause> where the fraction may vary on weight distribution, not just number of axles
21:23:46 <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:24:03 <andythenorth_> and with drawbar trailers it's actually easier
21:24:13 <andythenorth_> none of weight contributes to drive
21:24:26 <andythenorth_> but iirc RV physics discounts weight of trailed vehicles
21:24:30 <Eddi|zuHause> i'd just ignore the trailer
21:25:08 <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:16 <andythenorth_> I ignored the physics :P
21:25:23 <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:54 <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:04 <andythenorth_> michi_cc: with your patch HEQS looks to perform about right with 5% slope steepness
21:26:16 <andythenorth_> however if default is 7% that implies one of us has to change somethng
21:26:29 <Eddi|zuHause> openttd default is 3%
21:26:35 <Eddi|zuHause> ttdpatch default is 5%
21:26:39 <michi_cc> Only for rail, not for road
21:27:11 <andythenorth_> If I change HEQS, it's a bit broken for older versions of openttd
21:27:15 <michi_cc> What other sets supply TE/power for realistic acceleration? The default vehicles seem to do okay with the changes.
21:27:22 <andythenorth_> and I have to do the work :P
21:27:31 <andythenorth_> eGRVTS has it, but inconsistently
21:27:40 <andythenorth_> the horses are broken
21:28:00 <andythenorth_> some of the other vehicles are a little over-powered in my view
21:30:31 <Zuu> planetmaker: "dear deer taxi" might be a good catchy refrain. :-)
21:32:46 <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:44:21 *** Keyboard_Warrior has joined #openttd
21:45:49 <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:55:42 *** marc-andre has joined #openttd
21:57:42 <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:58:11 <marc-andre> am i on the right way ?
21:58:14 <planetmaker> you want to hex-edit savegames?!
21:58:31 <marc-andre> planetmaker: rather retrieve informations from the savegame (stats mostly)
21:59:03 <planetmaker> the save game is divided into chunks.
21:59:28 <Rubidium> it has a number of (RIFF) chunks. The precise definition of the data in each chunk depends on the savegame version
21:59:38 <marc-andre> ok, that makes sense from what i found in the saveload.cpp
21:59:51 <Rubidium> there's no documentation about the format except what is in the source code in the saveload directory
22:00:38 <marc-andre> but besides that a savegame is compressed with zlib, is there anything else ? are the chunks themself compressed ?
22:00:57 <glx> no, only the final data is compressed
22:00:59 <SmatZ> marc-andre: the whole savegame image is compressed by lzo/zlib/lzma
22:01:11 <SmatZ> it can be stored uncompressed as well
22:02:05 <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:17 *** zachanima has joined #openttd
22:02:21 *** perk111 has joined #openttd
22:02:42 <planetmaker> binary data, of course. The settings are a bunch of numbers of variable sizes. Depending on version different ones
22:02:44 <SmatZ> marc-andre: numbers are stored in big endian format
22:03:08 <planetmaker> uh. and big endian
22:03:32 <marc-andre> where are the savegame versions defined ?
22:03:47 <Rubidium> somewhere in the very beginning of the file
22:04:27 <marc-andre> same as the game version ?
22:04:47 <SmatZ> extern const uint16 SAVEGAME_VERSION = 151; ///< current savegame version of OpenTTD
22:05:49 <marc-andre> ahh, i have 138 in the src file...
22:06:53 <SmatZ> if you want to gather savegame statistics, the best way is to place your code at the end of AfterLoadGame()
22:07:06 <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:21 <marc-andre> without modifing the codebase
22:07:52 <Eddi|zuHause> you can start a multiplayer server and get some basic stats through the network interface
22:07:55 <Rubidium> depends on the stats and amount of effort you want
22:08:01 <SmatZ> yes, if you know where to find those data :p
22:08:08 <marc-andre> more then the server offers...
22:08:08 <Eddi|zuHause> there are already some libs for that
22:08:28 <marc-andre> i only found libs who acces the server console
22:08:58 <Eddi|zuHause> everything further than console or network interface can only be done by source code changes
22:09:24 <Eddi|zuHause> you can't really decode the savegame without having the source, anyway...
22:09:53 <Eddi|zuHause> it's definitely not easier than changing the source to output your data
22:10:13 <Eddi|zuHause> or you could write an AI
22:10:43 <marc-andre> or a program based on the saveload code
22:11:16 <SmatZ> which would mean modifying the program everytime saveload code changes
22:11:22 <SmatZ> if you want it up-to-date
22:11:26 <Eddi|zuHause> well, you can load the savegame, start your AI, and the AI can access/output the data for you
22:11:41 <Eddi|zuHause> AI can read most data you can also view as a player
22:11:58 <marc-andre> what about a newgrf ? possible ?
22:12:07 <Eddi|zuHause> AIs are done in a scripting language called "squirrel"
22:12:21 <Eddi|zuHause> nope, newgrfs can't do that.
22:12:52 <marc-andre> ok, the AI can read the informations, but how can i output them into a file ?
22:13:32 <Eddi|zuHause> by issueing debug statements
22:13:53 <Eddi|zuHause> with the right settings, those end up in the console, which you can redirect to a file
22:14:10 <SmatZ> can AI output to console?
22:14:18 <marc-andre> well, that takes proportions i can't handle...
22:15:01 <Eddi|zuHause> SmatZ: i'm pretty sure that's possible
22:15:01 <Rubidium> SmatZ: the stdout console
22:15:10 <Rubidium> given the right debug level
22:15:46 <marc-andre> thanks for all your answers
22:15:59 <SmatZ> I am just not sure if AI can gather the information you want
22:16:02 <Eddi|zuHause> hm... i fear HE has now found a valid argument against action 14 :(
22:16:35 <Eddi|zuHause> apparently finding unknown actions makes TTDPatch 2.5 barf...
22:17:52 <Rubidium> pff... he ought to make stuff compatible with stable versions, not some arbitrary beta release
22:18:38 <SmatZ> silly firefox is unusable on systems with IO load
22:18:42 <Eddi|zuHause> i don't think aiming at 2.0 improves things :p
22:19:42 <SmatZ> because it uses some werd DB engine
22:19:44 <SmatZ> that sometimes operates a lot on data stored on HDD
22:19:45 <SmatZ> causing firefox to lock up for tens of seconds
22:20:12 <Rubidium> Eddi|zuHause: ofcourse it does, then he can't use engine sounds either
22:21:25 <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:27 <SmatZ> Rubidium: well, openttd does the same :)
22:22:44 <Rubidium> yep, but only upon closing (or saveconfig)
22:24:30 <Rubidium> though the question is why he need 2.5 support. What does he expect from that?
22:25:37 *** Brianetta has joined #openttd
22:26:59 <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:33 <Rubidium> ah well, it's "only" 4.|3| years old
22:27:53 <Rubidium> (give or take a day or two)
22:28:07 <Eddi|zuHause> that's younger than most of his GRFs :p
22:28:44 <Eddi|zuHause> and this is only an "update" to his 0.4x series of newships, not a 0.5 release
22:29:51 <Rubidium> ah well, it won't be on bananas so most of our users won't use it anyways. So why bother?
22:30:32 <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:32 <Eddi|zuHause> i'm still working on that
22:34:06 * 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:29 <Rubidium> as well as checking whether other commits to their trunk need to be backported
22:34:33 <planetmaker> it should be 3.0-beta1 straight
22:34:57 <planetmaker> maybe even w/o beta1
22:35:05 <Eddi|zuHause> it should be 3.0-final-don't-bother-asking
22:36:33 <Eddi|zuHause> apparently ttdpatch is more bitchy with un-renum'd grfs...
22:37:19 *** norbert79 has left #openttd
22:42:47 *** zachanim1 has joined #openttd
22:54:56 *** andythenorth_ has joined #openttd
22:55:57 <Eddi|zuHause> the versioning of nforenum is... problematic...
22:56:13 <Eddi|zuHause> NFORenum r766 - Copyright (C) 2004-2010 by Dale McCoy
22:56:21 <Eddi|zuHause> NFORenum v3.4.6 r2309 - Copyright 2004-2009 Dale McCoy.
22:56:56 <Eddi|zuHause> first should better say "v5.0 r766"
22:57:38 <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:58:05 *** TheMask96 has joined #openttd
22:58:05 <Rubidium> even then, nforenum's binary was changed from renum to nforenum which is more problematic
22:59:03 <Eddi|zuHause> yes, but the worse headache was really to decide which one is newer...
22:59:19 <Rubidium> Eddi|zuHause: then use 5.0.0!
22:59:40 <Eddi|zuHause> it's ammlers fault
22:59:55 <Eddi|zuHause> > rpm -qf /usr/bin/nforenum
22:59:56 <Eddi|zuHause> grfcodec-5.0.r766-6.2.x86_64
23:00:10 <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:31 <Rubidium> Eddi|zuHause: then don't use his nightly builds :)
23:01:31 <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:13 <Rubidium> although that doesn't honour Lakie's work enough
23:02:55 <Eddi|zuHause> NFORenum 5.0.0 - Copyright (C) 2004-2010 by Dale McCoy
23:03:24 <Rubidium> should be for you :)
23:03:58 <Rubidium> unless you want to compile an OpenGFX nightly (or the extra graphics of OpenTTD in trunk)
23:04:04 <Eddi|zuHause> hm. nforenum complains that it's a version 6 grf, but openttd happily processes the action 14 anyway
23:04:18 <Eddi|zuHause> so why the limitation to version 7 grfs?
23:05:41 <Eddi|zuHause> but that's only a consistency problem, not a technical one?
23:07:45 <Rubidium> well, it only supports the version 7 language IDs
23:09:16 <Rubidium> action14 needs to be before action8 (or we have to scan the whole NewGRF when OpenTTD starts)
23:09:28 <Rubidium> and action8 defines the NewGRF version
23:09:55 <Eddi|zuHause> so actually you don't even know the version yet when processing the action 14? ;)
23:10:04 <Eddi|zuHause> and you silently ignore it
23:10:21 <Rubidium> OpenTTD probably does
23:10:38 <Rubidium> or it just assigns the translations to the wrong language
23:10:49 <Rubidium> (that's actually likely what happens)
23:11:01 <Eddi|zuHause> well, it did show the german translation...
23:11:32 <Eddi|zuHause> using the version 7 language codes in the action 14, and version 6 language codes in the rest of the grf
23:12:03 <Eddi|zuHause> anyway, i don't think there's a way around ttdpatch complaining about invalid sprite for older versions
23:12:48 <Rubidium> there is, but that involves taking over TTDPatch development and actually releasing a new 2.5 with "ignore action 14"
23:32:09 <Eddi|zuHause> hm... compile farm fails on cargodist builds, because "bundle_xz" is not a valid make target
23:34:01 <Eddi|zuHause> apparently a name for lzma output files...
23:42:55 <Rubidium> Eddi|zuHause: should go okay with the next run
continue to next day ⏵
