IRC logs for #openttd on OFTC at 2010-06-10
⏴ go to previous day
01:28:50 *** theholyduck has joined #openttd
02:01:04 *** JVassie has joined #openttd
02:49:16 *** devilsadvocate has quit IRC
02:53:32 *** woldemar has joined #openttd
02:56:59 *** woldemar has joined #openttd
02:58:28 *** woldemar has joined #openttd
03:00:54 *** woldemar has joined #openttd
03:05:41 *** devilsadvocate has joined #openttd
03:11:23 *** woldemar has joined #openttd
03:13:52 *** woldemar has joined #openttd
03:15:12 *** woldemar has joined #openttd
04:42:12 *** Kurimus has joined #openttd
04:47:16 *** welshdragon has joined #openttd
04:56:23 *** Eddi|zuHause has joined #openttd
05:14:18 *** devilsadvocate has quit IRC
06:04:30 *** charanjeet has joined #openttd
06:16:23 *** devilsadvocate has joined #openttd
06:36:34 *** ^Spike^ has joined #openttd
07:14:25 *** ChanServ sets mode: +v tokai
08:27:03 <Eddi|zuHause> "Guten Morgen, liebe Sorgen" isn't from Otto...
08:50:57 <Eddi|zuHause> i'm fairly sure it's Jürgen von der Lippe
09:48:00 *** woldemar has joined #openttd
10:22:49 *** Progman has joined #openttd
10:38:12 *** KenjiE20 has joined #openttd
10:58:07 *** theholyduck has joined #openttd
11:26:50 *** SirSquidness has joined #openttd
11:36:30 *** Devroush has joined #openttd
11:57:18 *** Adambean has joined #openttd
11:58:39 <Eddi|zuHause> so... which constant would i have to tweak in order to make acceleration on straight track take longer?
12:00:08 *** George is now known as Guest540
12:01:26 <Yexo> Eddi|zuHause: see void Train::UpdateAcceleration(), train_cmd.cpp:445
12:02:06 <Yexo> you could edit the *4 there for example to *3
12:06:31 <Eddi|zuHause> that's only for the original acceleration model...
12:07:41 <Eddi|zuHause> Train::UpdateSpeed(), uint accel <-- this seems like a more appropriate place
12:08:04 <Eddi|zuHause> 2897: uint spd = this->subspeed + accel;
12:09:06 <Eddi|zuHause> as this applies to both acceleration models
12:11:04 <Eddi|zuHause> this formula has an implied factor: v_new = v_old + a * delta t
12:11:21 <Eddi|zuHause> where delta t is the time one tick (?) takes
12:11:48 <Yexo> did you look at ground_vehicle.cpp already (GetAcceleration() ?
12:12:14 <Eddi|zuHause> yeah, skimmed it
12:12:21 <Eddi|zuHause> have seen that part of the code many times
12:13:39 <Eddi|zuHause> not entirely sure why there is a /2 in the end when accelerating, but not when braking
13:26:31 *** MindlessTux has joined #openttd
13:49:21 <major> i have a question do i need original deluxe files? to play open ttd?
14:03:52 *** orudge_ has joined #openttd
14:06:48 *** George is now known as Guest553
14:11:14 *** Coco-Banana-Man has joined #openttd
14:38:44 *** theholyduck has joined #openttd
14:45:13 <Eddi|zuHause> Chuck Norris has abused priests as a child
14:45:26 <orudge_> It took me a moment to parse that sentence
14:46:27 <Eddi|zuHause> might be more ambiguous in simplified english grammar
14:47:29 <Eddi|zuHause> you can have it in german grammar: "Chuck Norris has as child priests abused", if that helps you ;)
14:48:03 <peter1138> that would be stupid grammar
14:48:59 <orudge_> oh no, I understood it, my brain just didn't quite "get" the joke
14:49:14 <orudge_> because, y'know, it's slow that like that, and it isn't even 10am yet
14:50:00 <Eddi|zuHause> mid-west time zone?
14:51:06 <orudge_> seeing as I am in the midwest
14:59:52 *** DX_Ipad has joined #openttd
15:13:56 *** DX_Ipad has joined #openttd
15:14:35 *** frosch123 has joined #openttd
15:14:43 *** Dreamxtreme has joined #openttd
15:31:16 *** Brianetta has joined #openttd
16:23:05 <CIA-2> OpenTTD: smatz * r19951 /trunk/src/waypoint.cpp: -Fix [FS#3869]: close buoy's vehicle list when the buoy is deleted
16:24:14 <CIA-2> OpenTTD: smatz * r19952 /trunk/src/waypoint_gui.cpp: -Fix: do not close list of waypoint's trains when the waypoint view is closed - unify behaviour with other station types
16:24:50 *** MindlessTux has joined #openttd
16:34:11 <CIA-2> OpenTTD: terkhen * r19953 /trunk/src/vehicle_cmd.cpp: -Fix [FS#3874]: Don't show an error message when trying to start/stop a crashed plane.
16:39:35 *** |Jeroen| has joined #openttd
16:46:18 <frosch123> elho: that is a very old picture. during development the one-way signals had yellow bars, as those sprites already exisited, while the current ones were not yet drawn
16:46:41 <frosch123> feel free to update the image :)
16:47:16 <frosch123> (the rightmost signals in both driving directions are one-way)
16:48:05 <frosch123> oh, and the opposite signals on those tracks are not needed
16:56:52 <elho> ah, i see. i was wondering why there (also in other pictures) where the yellow bars despite the signal dialog not showing them, but thought that was how it looks :)
17:02:33 <elho> is there a way to get around the train-length gap
17:06:38 *** George is now known as Guest570
17:06:51 <elho> rather a way (as there are no intermediate pb signals) to make trains drive closely one after another through path sections? ie. with a block signal on every second tile they are closely packed, a pbs section would make the following trains wait until the first cleared it (assuming other paths blocked by trains from the other direction), right?
17:27:56 <Yexo> just place the pbs also closer together
17:40:09 <elho> i thought that would mean trains blocking junctions if they stop at one that is too close after it
17:41:04 <elho> but thinking about it, it should at least work where the number of available paths is not lower than before
17:45:35 <CIA-2> OpenTTD: translators * r19954 /trunk/src/lang/ (6 files in 2 dirs): (log message trimmed)
17:45:35 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:35 <CIA-2> OpenTTD: croatian - 3 changes by UnderwaterHesus
17:45:35 <CIA-2> OpenTTD: danish - 10 changes by beruic
17:45:35 <CIA-2> OpenTTD: french - 58 changes by ElNounch
17:45:36 <CIA-2> OpenTTD: irish - 107 changes by tem
17:45:36 <CIA-2> OpenTTD: norwegian_bokmal - 103 changes by mantaray
17:55:31 *** Chris_Booth has joined #openttd
17:59:15 *** ChanServ sets mode: +v tokai
17:59:39 <Belugas> SHIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIT!!!!
17:59:43 <Belugas> MEEEEEEEEEEEEEEEEEEEEEEEEEEEERDE!!!
18:00:01 <Belugas> they chage specs and behaviours
18:00:11 <Belugas> and there is not a singhle warning about that
18:00:26 <Belugas> two days i've been strufggling with that memory corruption
18:00:37 <Belugas> not even my freaking fault!
18:00:52 *** George3 has joined #openttd
18:10:18 <Hirundo> Java. *crashes* <- fixed it for you
18:15:48 <elho> that's a good fix indeed, you even get all the memory back, it ate :D
18:18:08 *** Qcco is now known as Kurimus
18:29:41 *** Polygon has joined #openttd
18:30:57 <andythenorth> perhaps I haven't been talking to myself much :P
18:32:15 <frosch123> what should I say? i am failing on gui code again :p
18:34:26 * andythenorth is not doing TTD at the moment
18:35:07 <frosch123> oh sorry, i misread the topic :p
18:41:30 *** ajmiles has joined #openttd
18:54:18 <elho> hmm, 1.0.1 makes a slight crackling sound during sfx playback, 0.6.2 does not :/
18:55:21 <peter1138> default sample rate changed from 11025 to 44100, iirc
19:00:54 *** theholyduck has joined #openttd
19:04:08 *** George is now known as Guest592
19:04:34 <elho> yes, that probably is the problem, now i just gotta find the setting for it :)
19:14:44 *** George3 has joined #openttd
19:25:50 <elho> but that seems to be the hard part
19:39:51 <elho> and sound.cpp seems to set 11025 Hz for old sounds, sdl_s.cpp however has 44100 Hz hardcoded
19:43:26 <orudge_> elho: you can edit the frequency in openttd.cfg, I believe
19:43:33 <orudge_> should you want to for some reason
19:45:21 <elho> orudge_: that was the first place i looked, but did not find any setting looking like it (searched for sound,audio,sample,rate,hz,44100,11025)
19:45:22 <orudge_> you could also manually resample the TTD sounds to 44.1KHz so they sound "nicer", and then create your own sounds package, but that might be a slightly more complicated way of doing things :)
19:46:33 <elho> but i just found a commandline argument, just not yet how to specify the parameters with it:
19:46:37 <elho> -s drv = Set sound driver (see below) (param bufsize,hz)
19:47:38 <orudge_> bufsize = the buffer size, typically 4096 or 8192 or so
19:47:43 <orudge_> hz = frequency, typically 44,100
19:48:18 <elho> but trial and error revealed: sdl:hz=11025
19:49:22 <elho> and the config has a sounddriner setting, so i'll try sticking that in there...
19:59:00 *** andythenorth has left #openttd
20:00:55 *** TheMask96 has joined #openttd
20:05:29 <Eddi|zuHause> <elho> is there a way to get around the train-length gap <-- the typical solution is make the exit of the junction double tracked, and merge them after the first signal
20:06:05 <Eddi|zuHause> or triple, if your trains are longer
20:06:43 *** Chris_Booth has joined #openttd
20:09:57 *** devilsadvocate has quit IRC
20:16:33 <elho> Eddi|zuHause: ah, i see. now that i have 1.0 backported and running without crackling sound, i can start to actually play with them a bit. :)
20:21:08 <elho> are there also yapp variants of mainline prioritisation/acceleration lines?
20:21:14 <Ammler> using trainlength gap is just a recommendation, you don't need to do it that way...
20:21:50 <elho> i do not want deadlocks either ;)
20:22:59 <Eddi|zuHause> no, path signals aren't really useful for priorisation
20:23:09 <Ammler> and you can simply combine path signals with blocksignals to make prios
20:25:07 <elho> just wish there was a smart priorisation thingy, tuning those setups to train length and speed is so tedious...
20:26:08 <Ammler> if you use trainlength signal gaps, not really :-)
20:27:43 <elho> that defeats the whole idea of packing trains densely to maximise line usage ;)
20:36:23 *** fonsinchen has joined #openttd
20:36:31 <elho> is the ttd savegame support still incomplete in 1.0.1 or does "data integrity error" actually mean that my old savegames are currupted?
20:38:22 *** TheMask96 has joined #openttd
20:38:51 <Ammler> you should be able to load every save from earlier revisions inclusive tto/ttd save games (also ttdpatch should be possible)
20:45:06 <Eddi|zuHause> ttdpatch is not guaranteed to work, if certain advanced features are used
20:49:26 <Eddi|zuHause> gnah... i just hit "x" on a screenshot :p
20:49:41 <Eddi|zuHause> ... didn't have the desired effect :(
20:50:05 <Ammler> hehe, as long as you don't scroll around with the right mouse button :-)
20:50:15 *** Fast2_ is now known as Fast2
20:50:35 <Eddi|zuHause> i'm beyond that point for years...
20:56:14 <elho> no, no patch or anything, that was plain old tt i had back then. its *.sv1 files i have - i copied them (from a diskette i guess :P) to my ~/.openttd/save years ago to find them not supported. now with the tto support i though i'd take a look
21:02:50 <Belugas> feelings woo whoo woo feelings
21:02:56 <Belugas> ho... faling.. sorrry
21:06:59 <Eddi|zuHause> elho: theoretically they should load, yes
21:13:54 <Yexo> elho: if you keep getting that error on tto/ttd (not ttdpatch) savegames upload them to the bugtracker so someone can take a look at them
21:14:17 <elho> yeah, the the floppy from back then might as well been bad
21:18:16 <Eddi|zuHause> elho: but usually they detect that on copying
21:18:40 <Eddi|zuHause> (usually "data error" or "crc32 error"
21:20:02 *** sashimi has joined #openttd
21:20:41 <sashimi> i am utterly new to openttd
21:20:47 <sashimi> haven't yet even tried the game
21:21:05 <sashimi> i randomly came accross the so called hd gfx
21:21:15 <sashimi> are they worth the hassle ?
21:22:38 <sashimi> the original gfx really look shitty
21:23:40 <Eddi|zuHause> you won't get fancy 3D animation...
21:23:57 <sashimi> oh i'm not talking about fancy 3D
21:24:07 <sashimi> if only nice looking 2D
21:24:27 <sashimi> simcity 2K looked pretty nice in it's time
21:24:45 <Eddi|zuHause> to the original question: no, the 32bpp graphics might look nice in places, but they are not finished, and they are _very_ troublesome to install
21:25:30 <elho> .oO(flipping the map around in 90 degree steps would be 3D heaven already ;) )
21:28:58 <sashimi> really early stage then
21:40:02 <elho> hmm, thinking i'd start with something easy trying pbs, i built the dual track as in the wiki (TTBOMK ;)), but it does not work as i expected: http://stranger.elho.net/yapp-fail1.png shouldn't train 85 overtake train 84?
21:41:02 <Eddi|zuHause> overtaking doesn't work very well, try to avoid it...
21:41:15 <Eddi|zuHause> and you likely have a track penalty problem
21:41:48 <Eddi|zuHause> 2 reverse signals + 2 track changes are penalised worse than 7 tiles of reserved track
21:43:06 <Eddi|zuHause> and your train looks reversed...
21:43:45 <elho> ah, changes are penalised, that's good. (the wiki somewhere claimed that the setup is bad as trains would keep alternating :P)
21:44:27 <elho> heh, yeah, i'm driving them on the right hand side :)
21:45:37 <elho> i'm actually not after overtaking that way, just thought it was the most simple thing to play with :o
21:58:10 *** Fast2_ is now known as Fast2
21:58:18 *** MindlessTux has joined #openttd
22:02:38 <Eddi|zuHause> elho: yes, they will do that
22:06:10 <Eddi|zuHause> the problem is that there is no way to tell "only overtake if train ahead is more than 30km/h slower"
22:20:13 <elho> well that's actuassy of no concern for me, the lev4 is strong enough to do a constant 643km/h and that is why i am not really interested in overtaking ;)
22:21:17 <Zuu> Another thing you want with overtaking is that the trains stay in the overtake "lane" long enough that the back of that train pass the front of the overtaken train, or the overtakning train will cut the path for the overtaken train.
22:22:22 <Zuu> Some pre-signal magic can maybe implement that, but the question is how ugly will it look.
22:22:40 <elho> sensor field and connection lines (that can be laid everywhere) to do easier priorisation than laying feedback tracks with pre-signals would be what i'd need. (or smart trains that automatically accelerate so that they hit the gap in the mainline traffic ;))
22:23:12 <Zuu> Eg, what is needed is a gap acceptance model. :-D
22:23:29 <Zuu> Which happen to be a major part of my master thesis :-p
22:23:40 <elho> yeah, that ugliness is what my sensor/signalling cable idea tries to circumvent :)
22:26:04 <elho> uh, i just had an idea how the priorisation could be enhanced to approach the gap detection with a lot more ugliness :D
22:27:52 <Zuu> A gap detector + accelertaion area can be quite easily be setup with pre-signals. However you will need to configure it for the current speed limits of your trains.
22:28:52 <elho> have a long acceleration line, so that every train is doing top speed, after that have a whole array of priorisation setups, each having different length lanes that merge the main line, the feedback lines connecting to different points of the main line determining which of them the train takes depending on the position of the gap on the hain line
22:29:32 <Zuu> Sure, and blow up a couple of towns in the process.
22:30:22 <elho> Zuu: i've been doing that (the simple one) and using sharp bends to force trains leaving the station at different speeds back to a similar level
22:31:26 <elho> i've ever since wished for a "buy out town" option that avoids the bribe 3-4 times, save / reload if detected cycle :P
22:32:03 <Zuu> Not sure if it works the same in OpenTTD physics but IRL, with lower speeds the minimum gap length in time will decrease.
22:32:05 <elho> (yes, i know there's magic bulldozer, but that's cheating ;))
22:33:23 <Zuu> (that is lowering the speed on the main-line)
22:36:05 <elho> when taking acceleration of the merging train into account?
22:37:14 <elho> (and braking, of course, the instant-stop signals in openttd aren't too realistic ;))
22:42:51 <elho> thinking about it, the path reservation is
22:43:21 <elho> bah, my enter key is too enthusiastic :P
22:44:44 <elho> thinking about it, the path reservation is a good foundation speed limiting signals could build on, ie. go gradually slower if the way is blocked anyway instead of rushing to do a full stop
23:06:21 *** Coco-Banana-Man has quit IRC
23:11:45 <elho> what is the deal with the option for trains to stop as the near/middle/far end, does that have any other effects than how it (de-)accelerates?
23:18:52 <Eddi|zuHause> marginal, mostly eyecandy
23:19:03 <Eddi|zuHause> i suggest setting the default to "middle"
23:22:32 <elho> yes, that seemed like a sane default to me, too
23:23:55 <elho> and then manually chaning it to near for orders to non-roro stations
23:24:36 <Eddi|zuHause> people have been suggesting, for terminus stations, far end is the best
23:30:40 <Yexo> "near end" being the most efficient for terminus stations would be more intuitive
23:31:12 <Eddi|zuHause> the issue was trains unblocking the junction faster when using the far end
23:31:33 <Eddi|zuHause> plus, it's more realistic
23:35:31 <Yexo> but when the train leaves the station it'll block the exit longer if you set them to middle/far end
23:35:50 <Yexo> unless you have signals in front of each platform
23:36:50 *** devilsadvocate has joined #openttd
23:37:02 <elho> i have no junctions on terminus stations, those are all point to point feeders
23:37:52 <elho> so near end could still be good with these, i guess
23:48:01 *** Brianetta has joined #openttd
continue to next day ⏵
