IRC logs for #openttd on OFTC at 2009-05-31
⏴ go to previous day
00:07:40 *** Eddi|zuHause2 is now known as Eddi|zuHause
00:15:54 *** stuffcorpse has joined #openttd
00:19:15 *** HerzogDeXtEr has joined #openttd
00:26:03 *** KenjiE20|LT has joined #openttd
00:56:51 *** Eddi|zuHause has joined #openttd
02:07:57 <Eddi|zuHause> i have seen something like this before
03:12:28 *** TinoDidriksen has joined #openttd
03:42:58 *** TinoDidriksen has joined #openttd
04:29:03 *** ChanServ sets mode: +v tokai
04:37:40 *** ChanServ sets mode: +v Belugas
04:37:40 *** ChanServ sets mode: +v Rubidium
04:37:40 *** ChanServ sets mode: +v orudge
05:23:35 *** Singaporekid has joined #openttd
05:52:27 *** De_Ghosty has joined #openttd
06:53:00 *** andythenorth has joined #openttd
07:00:31 *** andythenorth_ has joined #openttd
07:09:13 *** frosch123 has joined #openttd
07:17:32 *** andythenorth has joined #openttd
07:39:34 *** ChanServ sets mode: +v tokai
08:08:14 *** |Jeroen| has joined #openttd
08:13:21 *** Progman has joined #openttd
08:16:52 *** Alberth has joined #openttd
08:19:01 *** Azrael- has joined #openttd
08:35:58 *** andythenorth has joined #openttd
08:37:00 <Benny> Teh big machine master has arrived!
08:38:48 <andythenorth> apologies if there was a double post there, connectivity troubles...
08:39:51 *** eQualizer has joined #openttd
08:41:45 <andythenorth> Problem context: articulated road vehicle where the lead vehicle (tractor, 0t capacity) uses different graphics according to cargo of the trailer. Works as expected in r15297, doesn't work in r16470. Here's the code dealing with the varaction: 1462 * 14 02 01 B2 // provide different graphics depending on cargo
08:41:45 <andythenorth> 81 42 08 FF // check cargo type
08:41:45 <andythenorth> A3 00 07 07 // wood
08:41:46 <andythenorth> A2 00 // default
08:42:05 <andythenorth> (hmm, is there a better way to post code to irc? lots of unexpected line breaks there!)
08:43:19 <Benny> Nothing is stopping the spambots.. :(
08:43:39 <frosch123> noone cares about them anyway
08:44:41 <Benny> Wait a minute! WTF!? Do you have 1400 sprites in your NFO!? :O
08:45:04 <frosch123> 1400 is really not a lot :)
08:45:13 <frosch123> 14000 starts to become lot :)
08:45:24 <Benny> For my diesel shunter, I only have like 30..
08:45:55 <Benny> 1400 sprites is A LOT of writing!
08:46:10 <Benny> And it all has to be written in numbers..
08:47:17 <andythenorth> 2405 sprites in my nfo so far and it's 25% complete compared to my plan. Most of it is endless loading state graphics for all the different mineral cargos. I know about recolour sprites, but it looks like a world of pain if you need to use both company colours (I do)
08:47:19 <frosch123> andythenorth: can you provide a test grf somewhere, as your code looks correct :)
08:47:29 <andythenorth> PM to you direct?
08:47:51 <frosch123> never tried that :)
08:48:16 <z-MaTRiX> spambots can be limited by using visual verification ;)
08:48:27 <andythenorth> @ frosch - or whatever suits you
08:48:47 <Benny> I suppose you meant PM the link?
08:49:02 <Benny> Or is it possible to send a file via IRC?
08:49:20 <andythenorth> (I meant PM via the forums)
08:49:30 <frosch123> PM via forums is fine
08:50:00 <frosch123> there is also some DDC file transfer in irc, but I never tried that, so I have no idea, whether my router blocks that, or simliar
08:50:39 <Benny> And DDC stands for what? Or should I google it?
08:50:56 <frosch123> no idea, I would have to google myself :)
08:51:09 <frosch123> oh, it's DCC actually
08:51:37 <Tefad> DCC is limited on the receiver's end
08:51:48 <Tefad> no i lie, sender it is.
08:52:35 <z-MaTRiX> also there are filesharing websites
08:52:38 <Benny> Direct Client to Client
08:54:11 <Benny> Sounds like a piece of nerd porn... o_O
08:54:24 <andythenorth> @frosch, ignore the PM i just sent, missed some stuff
08:58:52 <kkb110> are you playing ttd now?
08:59:07 <xahodo> Is it feasable to stuff the map array and anything tileindex related in a bunch of classes?
08:59:08 <z-MaTRiX> i was playing bashscipt now
08:59:50 <kkb110> good :D my spring semester is now over yeah!
09:01:10 <frosch123> [10:59] <xahodo> Is it feasable to stuff the map array and anything tileindex related in a bunch of classes? <- no, because map accessors and tile types are not hierarchical organised
09:01:33 <andythenorth> @frosch new PM sent
09:04:28 *** reldred1 has joined #openttd
09:04:30 <xahodo> Not even with some workarounds for the time being? i.e. let the class refer to the "old" map array in the first place, and then slowly convert everything to use the class.
09:05:03 *** Cybertinus has joined #openttd
09:05:40 <frosch123> andythenorth: he, that is the unmodifed 0.4 version :) I already had that file :p
09:07:26 <andythenorth> @ frosch, yep sorry, bit slow this morning, didn't think about whether you already had the file. anyway the screenie might help show what *should* happen?
09:11:56 *** Cybertinus has joined #openttd
09:12:59 <frosch123> haha, I guesses I messed something up there :o
09:14:31 <andythenorth> Ach well. So did I, I've just realised my latest revision should be 0.4c not 0.4b. 0.4b already exists :O
09:14:35 *** oskari89 has joined #openttd
09:15:08 <frosch123> -es <- even more :p
09:16:33 <andythenorth> @ frosch - so can I put that one down to a problem in trunk? i.e. I don't need to change my nfo?
09:29:50 *** worldemar has joined #openttd
09:32:09 <CIA-3> OpenTTD: rubidium * r16474 /trunk/src/settings_gui.cpp: -Fix [FS#2933]: could set company related settings via query window
09:33:07 <Alberth> zahodo: that sounds like the usual procedure
09:33:24 <CIA-3> OpenTTD: smatz * r16475 /trunk/src/ (order_cmd.cpp station.cpp): -Codechange: move code invalidating Vehicle::last_station_visited to more logical place
09:34:25 <Alberth> xahodo: ^^^ sorry, I misspelled your name
09:34:53 <CIA-3> OpenTTD: smatz * r16476 /trunk/src/station.cpp: -Fix (r16475): wrong version of the patch
09:36:26 <SmatZ> xahodo: why would you want to do that?
09:37:50 <Rubidium> SmatZ: because it is "better"
09:38:10 <frosch123> SmatZ: maybe he hopes it would become more clear when to use which accessors :) I.e. he hopes tile classes would make it more transparent that some functions apply to rail, road and station tiles, but only when they contain railtracks, and other functions apply to all tiles except industries, and ...
09:38:14 <SmatZ> ah yeah, I forgot... ;)
09:39:17 <xahodo> Well, as far as I can see it would increase readability quite a bit.
09:39:33 <Xaroth> why does one need readability?
09:39:33 <z-MaTRiX> į see big code constructions
09:39:41 <Rubidium> xahodo: an undoubtedly decrease speed quite a bit
09:39:56 <SmatZ> and increased memory usage quite a bit
09:40:12 <frosch123> and it would not increase readability as you would need 100 different classes implementing 300 different interfaces
09:40:27 <Rubidium> SmatZ: nah, only two or so pointers worth for each tile...
09:41:22 <z-MaTRiX> wonder why versions are incompatible :)
09:41:31 <SmatZ> Rubidium: using bitpacked data in map array as they are now is hardly readable ;)
09:41:45 *** ChanServ sets mode: +v tokai
09:41:56 <Rubidium> which is only 16/9 times more memory per tile, although... you can reduce memory as you don't need to save empty bytes for void tiles and such
09:42:25 <Rubidium> z-MaTRiX: read the wiki/forum; it's explained more than enough there
09:42:36 *** XeryusTC is now known as Xeryus|bnc
09:42:52 *** Xeryus|bnc was kicked by Rubidium (you wanted to be bounced, right?)
09:42:52 *** Xeryus|bnc has joined #openttd
09:43:05 <z-MaTRiX> was only thinking about things you are talking about now
09:43:24 <SmatZ> given malloc allocates data in 16B blocks, you need at least 16B for every struct
09:47:20 <xahodo> huh? I wasn't talking about creating a pool of tiles.
09:49:33 <SmatZ> you can't have an array of objects of varying size
09:52:01 <xahodo> I'm aware of that, and if done that would be a leap backward in performance.
09:52:32 *** reldred has joined #openttd
09:52:53 <Rubidium> you can't have an array of objects of varying type either
09:54:20 <xahodo> I was thinking about stuffing the tile struct and tileextended byte in a class. Subclasses could then be used to handle the appropriate tileclasses (station, houses, industries, etc.). However, what would the performance impact of this be?
09:55:59 <SmatZ> you can't have an array of objects of varying type either
09:56:43 <xahodo> Yes, but you can do typecasting, can you?
09:57:08 <xahodo> errr... garbled sentence :s
10:00:03 <Rubidium> to if (_m[t].GetType() == MP_RAIL && ((RailTile*)(&_m[t]))->GetSubType() == RAIL_PLAIN)
10:00:20 <Rubidium> hmm, okay, maybe not quite
10:00:29 <Rubidium> but the casting is going to cause trouble
10:01:11 <Rubidium> and make one big mess like ((Type*)&_m[t])->x instead of _m[t].x
10:03:51 *** tux_mark_5 has joined #openttd
10:09:48 <frosch123> xahodo: And in which class would you put function like GetTileOwner and GetRailType ?
10:10:58 <xahodo> gettileowner would be in the tile class. getrailtype would be in errr... the "tilerail" class.
10:11:29 <frosch123> and how do you handle that gettileowner is not valid for houses and industries, and that railtype is also valid for stations and levelcrossing?
10:12:43 <xahodo> The potential performance impact from typecasting keeps bugging me, though.
10:15:43 <Alberth> xahodo: don't worry, it is not going to be potential, it is going to be very real.
10:17:13 <xahodo> if using dynamic_cast or doing it by hand?
10:18:34 <andythenorth> anyone know the original map size in TTD (expressed as no. of tiles x and y)
10:18:55 <Alberth> if you do it manually, what do you gain then? Wouldn't you end up with the same interface we have now?
10:18:58 *** racetrack has joined #openttd
10:18:59 <frosch123> 256x256 or 255x255 depending on your counting
10:21:18 <xahodo> Alberth: if you do it manually, what do you gain then? Wouldn't you end up with the same interface we have now? <- not nescesarily.
10:22:37 <frosch123> you still did not told me in which class to put getrailtype so it can access railtiles, levelcrossing, stations and bridges
10:24:01 <xahodo> that would be the baseclass, I guess.
10:24:24 <frosch123> so if you put half of the functions in the baseclass, what do you gain?
10:30:10 <xahodo> Are there more examples of cases like that?
10:31:39 <xahodo> Won't something like this help with the de-spaghettification of openttd?
10:31:47 *** Hirundo has joined #openttd
10:34:40 <Rubidium> xahodo: GetRoadOwner
10:35:20 <Ammler> andythenorth: you should change GRFID, if it isn't compatible anymore. OpenTTD does load the grf also, if it has an other filename.
10:36:48 <Ammler> (ususally, you use the last byte for versioning)
10:36:57 <andythenorth> ammler. was wondering about that. I would prefer to have savegame compatibility. I think the savegame issues are minor, but I haven't had time to test properly. Does bumping the grfID break savegame compatibility?
10:37:27 <Ammler> no, just a red dot, if you don't have the old one.
10:39:02 <Ammler> changing filename on GRF with same ID is "suboptimal", if you use grf presets and such.
10:43:37 <andythenorth> OK I'll change the ID on the GRF before I do an official release
10:44:04 <Ammler> well, I would do it only, if it breaks the game.
10:45:49 <Ammler> oh, and btw, if you use banans, you don't need to rename them anyway, as that does the job for you, sadly. ;-)
10:46:15 <xahodo> yes, well... there is a pattern emerging. The only thing I'm not really certain about is what to do with bridges.
10:46:18 <Ammler> (still didn't find a way to make presets)
10:52:51 <xahodo> But, ok... I'll just leave and forget about this idea altogether. Sorry for proposing something extremely useful. :(
10:54:38 <Rubidium> yay for someone decreeing something is "extremely useful" without showing any proof of it
10:57:05 <elmz> hehe, what has his idea?
10:57:39 <Alberth> switching to OO in the map
10:59:30 <Rubidium> and his final proposal was making classes and then an array of the base class with the map struct wrapped into it and then casting it to dozens if not close to a hundred classes based on the data in the map array and then using those classes to access the data
11:00:20 <Rubidium> which to me sounds like the worst case scenario of OO (even worse than no-OO)
11:02:11 <Rubidium> then one dimwit comes, sees the OO and assumes he can just add stuff to a subclass and... memory corruption frenzy!
11:05:08 <CIA-3> OpenTTD: rubidium * r16477 /trunk/src/vehicle.cpp: -Fix [FS#2936] (r12650): loading indicator when 'unload' in and 'no loading' is off was pointing to the wrong direction.
11:26:27 *** Xeryus|bnc is now known as XeryusTC
11:26:39 *** KenjiE20 has joined #openttd
11:27:24 <CIA-3> OpenTTD: frosch * r16478 /trunk/src/newgrf_engine.cpp: -Fix (r15378): Determining most common (sub-)cargo-type was broken due to someone confusing similiary named variables.
11:31:22 <CIA-3> OpenTTD: frosch * r16479 /trunk/src/aircraft_cmd.cpp: -Fix (r5146): Call callbacks after initialisation of vehicle variables.
11:48:33 *** racetrack has joined #openttd
12:03:26 <CIA-3> OpenTTD: frosch * r16480 /trunk/src/ (7 files): -Fix (r15617): Invalidate newgrf variable caches of more vehicles in more places. Esp. they were only invalidated for trains.
12:07:50 <frosch123> andythenorth: should work now :)
12:11:28 *** KenjiE20 has joined #openttd
12:18:16 <CIA-3> OpenTTD: rubidium * r16481 /branches/0.7/src/ (7 files in 5 dirs):
12:18:16 <CIA-3> OpenTTD: [0.7] -Backport from trunk:
12:18:16 <CIA-3> OpenTTD: - Fix: [NoAI] Another try/catch related bug (r16454)
12:18:16 <CIA-3> OpenTTD: - Fix: Road vehicles ending up on the pavement when they are in a drive through station that got removed due to bankruptcy [FS#2909] (r16448)
12:18:16 <CIA-3> OpenTTD: - Fix: [NoAI] AIRail::GetRailStationDirection returned incorrect information (r16440)
12:18:17 <CIA-3> OpenTTD: - Fix: Crash when a company is deleted while a dropdown with company names is open (r16430)
12:18:19 <CIA-3> OpenTTD: - Change: [NoAI] Stop an AI when it takes too long to initialize or load [FS#2869] (r16425)
12:23:05 <CIA-3> OpenTTD: rubidium * r16482 /branches/0.7/ (10 files in 2 dirs):
12:23:05 <CIA-3> OpenTTD: [0.7] -Backport from trunk:
12:23:05 <CIA-3> OpenTTD: - Fix: [NewGRF] Invalidate NewGRF variable caches of more vehicles in more places. Esp. they were only invalidated for trains (r16480)
12:23:05 <CIA-3> OpenTTD: - Fix: [NewGRF] Call callbacks after initialisation of vehicle variables (r16479)
12:23:05 <CIA-3> OpenTTD: - Fix: [NewGRF] Determining most common (sub-)cargo-type was broken due to someone confusing similiary named variables (r16478)
12:23:07 <CIA-3> OpenTTD: - Fix: Loading indicator when 'unload' in and 'no loading' is off was pointing to the wrong direction [FS#2936] (r16477)
12:23:09 <CIA-3> OpenTTD: - Fix: Track reservation was drawn at bridge heads in the menu (r16470)
12:26:04 *** DephNet[Paul] has joined #openttd
12:43:35 *** oskari89 has joined #openttd
12:49:13 *** Biolunar has joined #openttd
12:52:45 *** stuffcorpse has joined #openttd
13:20:24 *** morpheus has joined #openttd
14:04:31 <CIA-3> OpenTTD: frosch * r16483 /trunk/src/ (train_gui.cpp vehicle_gui.cpp vehicle_gui.h): -Codechange: Enumerate tabs in train details window.
14:05:47 *** fonsinchen has joined #openttd
14:31:11 <CIA-3> OpenTTD: alberth * r16484 /trunk/src/window.cpp:
14:31:11 <CIA-3> OpenTTD: -Cleanup: Renamed widget variable to widget_index and introduced widget_type variable.
14:31:11 <CIA-3> OpenTTD: -Fix: Prevented out-of-bounds array access when not clicking at a widget.
14:37:47 <dihedral> svn diff -r 8242 says something else though :-P
14:38:39 <Alberth> hmm, that should be svn diff -r8241:8242
14:40:06 <Alberth> (unless you wanted to know what has changed since then :) )
14:41:53 <dihedral> i bet they used svndumpfilter and forgot to use --drop-empty-revs
14:43:09 <dihedral> thanks for the enlightenment glx
14:43:29 <dihedral> perhaps one should post a report to subversion directly ^^
14:44:48 *** Frostregen has joined #openttd
14:55:12 *** paul is now known as Guest59
14:55:46 <Guest59> CAn someonr help please, i've downloaded 'disable_train_reverse R16183.diff' to my desktop, how do i get it to work in the game? thanks
14:56:12 <FauxFaux> By building openttd after applying that patch to the cdoe (i.e. not trivial).
14:56:53 <Guest59> so i couldn't use this patch in my current saved game then? sorry new to all this
15:00:12 <Alberth> that will be a long read :)
15:26:23 *** Dred_furst has joined #openttd
15:27:49 *** Brianetta has joined #openttd
15:39:42 *** Tha_Muffin_Man has joined #openttd
15:40:03 *** mikk36|w has joined #openttd
15:40:32 <Tha_Muffin_Man> n008 question.... I can not figure out how to upgrade my vechicles?
15:42:04 <Tha_Muffin_Man> I have an old plane, rather then scrap the route, can I simply upgrade the plane?
15:42:30 <Tha_Muffin_Man> additionally if I have 5 buses I want to upgrade, can I tell them all to upgrade or do I have to do with for each one?
15:45:40 *** frosch123 has joined #openttd
15:46:12 <FR^2> Tha_Muffin_Man: vehicle replacement is a little bit "hidden".
15:49:25 <FR^2> Tha_Muffin_Man: Go to the list of vehicles, on the lower border, the right-most button... move your mouse over it, click on it, but keep the mouse button pressed...
15:49:41 <FR^2> Tha_Muffin_Man: Argh, just klick on it ;)
15:50:31 <Tha_Muffin_Man> does it look like a train with a large yellow arrow growing from it?
15:51:05 <dyzdyz> if i have 2 or more versions of openttd (for example one with cargodist and one without), do they share the openttd.cfg file?
15:51:49 <frosch123> if your openttd.cfg is in your user folder then yes, if it is in the folder of the binaries then no
15:52:29 <frosch123> same holds for base graphics, newgrfs, content download, ....
15:52:46 <Tha_Muffin_Man> I just found the auto replace feature in the manual
15:55:44 <dyzdyz> ok, so did anyone had a problem with cargodist and custom fonts? i have 2 versions of ottd sharing .cfg, and one works with custom fonts, and the second one (with cargodist) uses sprite font
15:56:44 <Tha_Muffin_Man> worked a treat... thanx mate
15:56:47 *** Tha_Muffin_Man has left #openttd
16:30:41 *** Limpaaar has joined #openttd
16:31:05 <Limpaaar> I could not find a place where I can report a crash of OTTD
16:31:39 <Limpaaar> I made a screenshot and copy of the whole text... but I don't know where to send it
16:34:48 <Limpaaar> So I need to be a registered user to send bug report... hmm...
16:35:08 <Limpaaar> sorry for disturbing
16:58:10 <tompaw> is there a way to play openttd in realtime mode?
16:58:26 <tompaw> and then 1 year of gameplay == 1 year of real time?
16:58:45 <Sacro> grab a daylength patch and increase it to whatever
16:59:00 <Sacro> though you might never complete it
16:59:49 <tompaw> I don't want to complete it, I do want to deal with rail tracks only, not interested in those fancy monorails
17:03:04 <elmz> well, you might be interested in having more than just the Kirby Paul all the time? :P
17:03:17 <Sacro> it'll take you a long time
17:03:55 <Sacro> i've often considered 1 day irl is one year in game
17:04:04 <elmz> but yeah, with a daylength patch you can make time pass slower
17:04:35 <elmz> hehe, I'd run out of space in 1937 ^^
17:06:21 <tompaw> so, the only way is to patch the sourcecode and build it myself?
17:08:31 <Eddi|zuHause> do i even want to know the reference?
17:08:53 <Eddi|zuHause> tompaw: no, you can also pay someone to do it for you
17:09:01 <elmz> If you don't know it you won't care :P
17:09:06 <Sacro> I will write a daylength patch for money
17:09:19 <Sacro> I just need a catchy name...
17:09:45 <tompaw> what about the one your parents gave you?
17:11:41 *** Hirundo_ has joined #openttd
17:12:10 *** Hirundo_ is now known as Hirundo
17:14:08 *** rain```` has joined #openttd
17:19:10 *** ChanServ sets mode: +o Bjarni
17:23:42 <tompaw> what's the easiest way to build on vista64?
17:26:36 <Eddi|zuHause> sonic screwdriver, please...
17:26:52 <Eddi|zuHause> but it doesn't do wood...
17:28:28 *** maristo has joined #openttd
17:31:32 <Ammler> has grfcodec a "hidden" feature, so it does output one line per sprite?
17:34:02 <Bjarni> I think you can specify how many sprites you want on each line
17:34:25 <Bjarni> so setting this one to 1 would do the trick
17:34:36 <Bjarni> I'm not entirely sure though
17:35:05 <Eddi|zuHause> no, that's about the width of the .pcx
17:35:14 <Eddi|zuHause> not about the lines in the .nfo
17:40:56 <frosch123> Ammler: iirc nforenum has some setting for that
17:41:17 <frosch123> like maximum line length and when to put newlines at logical positions
17:48:58 *** fonsinchen has joined #openttd
18:11:26 *** Hirundo_ has joined #openttd
18:12:19 <DorpsGek> oskari89: Pikka was last seen in #openttd 3 days, 0 hours, 56 minutes, and 24 seconds ago: <Pikka> planetmaker: but they still own the copyright
18:15:52 *** Hirundo_ is now known as Hirundo
19:17:11 *** microshit has joined #openttd
19:21:24 <dihedral> i wish SirXavius cam on irc
19:22:49 <dihedral> nobody can decently bash / flame him on the forums
19:30:04 <CIA-3> OpenTTD: alberth * r16485 /trunk/src/news_gui.cpp: -Fix [FS#2938]: Move date in news window a pixel away from the right-edge (erikjanp)
19:37:02 *** lewymati has joined #openttd
19:40:40 *** |Jeroen| has joined #openttd
19:50:57 *** microshit has left #openttd
19:52:01 <CIA-3> OpenTTD: alberth * r16486 /trunk/src/airport_gui.cpp: -Codechange [FS#2939]: Added widget numbers to the airport toolbar (based on work by erikjanp)
20:18:59 <CIA-3> OpenTTD: alberth * r16487 /trunk/src/news_gui.cpp: -Codechange [FS#2940]: Add widget numbers to news display and news history windows (based on work by erikjanp)
20:24:58 <Xaroth> dihedral: i think bash/flame on irc would be easy
20:33:21 <CIA-3> OpenTTD: alberth * r16488 /trunk/src/graph_gui.cpp: -Codechange [FS#2941]: Use widget numbers of base grap window and cargo payment window in the window handling code (erikjanp)
20:37:20 *** Nite_Owl has joined #openttd
20:43:37 *** DephNet[Paul] has joined #openttd
20:52:47 <CIA-3> OpenTTD: alberth * r16489 /trunk/src/misc_gui.cpp: -Fix [FS#2937] (r16258): Do not resize a widget twice (erikjanp)
20:53:12 <SJr> Um I don't understand PBS and when to use them
20:53:32 <SJr> I'm looking at the guide, but it only gives me an idea of what they are
20:54:11 <Nite_Owl> place them only in a spot where it is safe for a train to wait
20:54:45 <SJr> Will trains wait in front of the back of a PBS?
20:55:03 <Nite_Owl> such as at the entrance to a junction not in the middle of a junction
20:57:12 <SJr> So use them at junctions and only junctions, and keep the front of them far enough away from exits so that they don't block.
20:58:19 <Nite_Owl> they can be used at stations too
20:59:00 <Alberth> except that platforms are not safe stopping places by default, you need to put a sign after the platform.
21:00:32 <Nite_Owl> now I am confused - a sign?
21:00:43 <SJr> Should I use one way path signals for one way tracks?
21:01:29 <SJr> Or do I want to make my track two way
21:01:40 <SJr> with frequent cross overs
21:01:41 <Rubidium> yes, unless you want a train to be able to go in reverse direction over the track if it can reserve a path through the whole track (until the next safe waiting point from that direction)
21:02:00 <Rubidium> how you want to make your tracks heavily depends on your playing style
21:02:53 <Eddi|zuHause> you typically want double track lines to be one-way
21:03:19 <SJr> Well I've been playing OpenTTD for years (off and on), but this PBS is new.
21:03:58 <SJr> Normally I just have one way track sections, but I remember seeing an example where you could actually have two way tracks that favor one way
21:04:33 <Alberth> Nite_Owl: s/A/B/ means replace A with B
21:04:45 <Eddi|zuHause> yes, but that is not fully implemented
21:47:38 *** TheMask96 has joined #openttd
22:32:34 *** reldred has joined #openttd
23:25:43 *** KenjiE20|LT has joined #openttd
23:33:49 *** Eddi|zuHause2 has joined #openttd
23:34:27 *** Eddi|zuHause2 has left #openttd
23:35:52 *** Eddi|zuHause2 has joined #openttd
23:41:27 *** HerzogDeXtEr1 has joined #openttd
continue to next day ⏵