Back to Home / #openttd / 2011 / 12 / Prev Day | Next Day
#openttd IRC Logs for 2011-12-29

---Logopened Thu Dec 29 00:00:22 2011
00:11-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
00:12-!-Pixa [~pixa@] has joined #openttd
00:26-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
00:26-!-Pixa [~pixa@] has joined #openttd
00:30-!-Kurimus [] has joined #openttd
00:48-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
00:48-!-Pixa [~pixa@] has joined #openttd
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
00:59-!-KouDy [] has joined #openttd
01:25-!-thefiler [] has joined #openttd
01:25-!-thefiler [] has quit []
01:26-!-thefiler [] has joined #openttd
01:28<thefiler>any experts here?
01:28<thefiler>need some questions answered
01:29-!-XaTriX [] has joined #openttd
01:30<Afdal>Me too :(
01:31<Afdal>I might be able to help, but probably not
01:33<Rubidium>thefiler: experts of what? Does your question really need an expert, or just someone knowing the answer
01:33<Rubidium>in any case, I'm an expert but possibly not in the area you need the expert in
01:37-!-thefiler [] has quit [Remote host closed the connection]
01:37<Afdal>Afdal Can someone explain to me how depot pathfinding for maintenance works?
01:37<Afdal> Afdal Why do trains service more often when you split depots from the main track using a path signal and less with a block or presignal?
01:39<Rubidium>I guess thefiler quit right after asking his meta question... why are people so unpatient?
01:39-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
01:39-!-Pixa [~pixa@] has joined #openttd
01:40<Rubidium>Afdal: vehicles try every X ticks to find a depot that is within Y pathfinder penalties (don't know the exact number)
01:40<Afdal>When they're in need of a maintenance, right?
01:40<Afdal>So does a one-way path signal have less penalty than regular signals?
01:40<Afdal>That still doesn't explain how
01:41<Afdal>trains find the depot with regular signals
01:41<Afdal>They can find depots with both
01:41<Rubidium>with path signals it starts looking from the end of the reservation, whereas with normal signals it's from the front of the train
01:41<Afdal>but if you use a path signal they maintain themselves significantly more often
01:42<Afdal>hmm, I don't understand how that would bias the path-signaled depot
01:42<Rubidium>if the signal blocks are large/long, then it is more likely to that the depot is sought when the train's reservation ends near the depot
01:43-!-thefiler [] has joined #openttd
01:43<Afdal>Here's an example by the way
01:43<Afdal>in case I'm not being very clear
01:43<Afdal> versus
01:43<Rubidium>Afdal: it really depends on the situation; with many short signal blocks with path signals it's less likely to find one with path signals
01:44<Afdal>But in this case it's the opposite of that
01:44<Afdal>The path signal favors maintenance
01:45<Rubidium>as I said, it tries to find a depot every X ticks, and does so with a max distance of Y
01:45<Rubidium>now I'd reckon that the distance from depot to main track is very close to Y
01:46<Afdal>yes, in that picture
01:46<Afdal>If you make the track between the main track and the depot
01:46<Afdal>any longer, trains won't service at all
01:46<Afdal>8 tiles is the maximum
01:46<Afdal>err, track length
01:47<Afdal>When you say ticks
01:47<Afdal>Do you mean tiles?
01:47<Afdal>or time?
01:47<Rubidium>so, likely the only place a train can be to 'see' the depot within max distance is the tile with the pre/path signal
01:48<Afdal>yes, that makes sense
01:48<Rubidium>ticks are time
01:48<Afdal>I just don't see how that would be any any different between signal types
01:49<Rubidium>now for the path signal, once the train passes the signal before the path signal the train reserves a path up to the path signal. From that moment *all* pathfinding of that train happens "from" the path signal's location
01:49<Rubidium>which means that with the path signal it sees the depot two tiles earlier
01:50<Afdal>So with the path signal it has more time to look for a depot
01:50<Afdal>more time to coincide with the depot check tick
01:50<Afdal>What about
01:50<Rubidium>and this is where the X ticks comes to play as well. If the train tries at the tile just before the pre signal it is unlikely to try at the tile with pre signal due to its speed, as such it doesn't see the depot. With the path signal it would see the depot because of the reservation ending at the signal
01:51<Afdal>Thanks, that makes a lot of sense
01:51<Rubidium>... changing the maximum distance to depot for maintenance?
01:51-!-thefiler [] has quit [Ping timeout: 480 seconds]
01:51<Rubidium>there's a setting for that ;)
01:52<Afdal>What's the setting?
01:52<Afdal>Does that mean I could help trains service even better by making the signal block just before the path signal longer?
01:53<Rubidium>yapf.maximum_go_to_depot_penalty or npf.maximum_go_to_depot_penalty depending on the chosen pathfinder
01:53<Rubidium>Afdal: yes
01:54<Afdal>So just so I'm clear on this
01:54<Afdal>The train looks for depots in front of its reserved path?
01:55<Afdal>Agh, now I'm confused again. It sounds like the way you're arguing it, it would only affect if there was a path signal just before the split signal
01:55-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
01:56<Afdal>instead of at the split signal
01:56-!-Pixa [~pixa@] has joined #openttd
01:56<Rubidium>well, depends of what's "in front" is ofcourse
01:56<Afdal>Because it reserves the extra track before the split, there's more chance to hit the depot check
01:56<Afdal>but a block signal won't do that
01:57<Afdal>Now I'm confused again :(
01:58<Rubidium>well, to confuse you even more...
01:59<Rubidium>the pathfinding *always* happens from the "front" of the reservation, but with path signals it reserves till the next safe waiting point (signal / end of track), but with block signals it only reserves the track directly under the train
01:59<Afdal>front being the furthest from the train, right?
01:59<Rubidium>front is the reservation furthest away from the train in the direction it is riding
02:00<Afdal>Yeah, the way you're describing it sounds like a path signal BEFORE the split signal is what would matter
02:01-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
02:01-!-Pixa [~pixa@] has joined #openttd
02:01<Rubidium>Afdal: but a block signal leading to a path signal reserves a path as well
02:02<Afdal>It does?
02:02<Rubidium>yes, but only when there's no other train in that signal block
02:02<Afdal>It doesn't show it like that with track reservation on
02:02<Afdal>Looks like the block signal acts the same as usual
02:02<Afdal>show track reservation*
02:03-!-lordnokon [] has joined #openttd
02:03<Afdal>with the reserved track only directly under the train
02:04<lordnokon>is there no way to custom industries, instead of using on the 2040 tones per month limit
02:04<Rubidium>for me it allocates the whole track from the block signal up to the path signal
02:04<Afdal>Are you on 1.1.4 or 1.20 beta?
02:04<lordnokon>so if i want to have a coal mine produce 1mil tones a month, that would save on the amount of industries needed to be build or funded, which will help not slowing down the game with lots of industries?
02:05<Afdal>Here's what I'm seeing
02:05<Rubidium>but 1.1.4 behaves the same as the way I'm describing it
02:06<Afdal>The track reservation shows the same before with the block signal before the path signal as per usual block signals
02:06<Afdal>same behavior*
02:06<Rubidium>oh, I'm not using the one way path signal
02:07<Rubidium>but the 'normal' path signal
02:07<Afdal>The plot thickens :o
02:07<Afdal>oh hey you're right
02:07<Afdal>That doesn't explain why one-way path signals favor servicing still
02:08<Afdal>all over factors being equal
02:08<Rubidium>different pathfinder penalties between the signals I'd guess
02:09<Afdal>Is there a penalty for exit signals?
02:09<Afdal>no wait that shouldn't matter
02:09<Afdal>It's the same with each branch
02:10<Rubidium>I don't know by heart what the different pathfinder penalties are
02:10<Afdal>Also the maintenance rate with presignals and regular block signals at the track split is the same
02:10<Afdal>It's only higher with a path signal
02:13<lordnokon>any help on my questions?
02:13-!-DayDreamer [] has joined #openttd
02:15-!-DayDreamer [] has left #openttd []
02:15<Afdal>The way you describe it, there should be a significant service rate difference between a two-way and a one-way path signal at the split
02:15<Afdal>Let me test that
02:22<Afdal>Wow, there is
02:22<Afdal>So that explains why a two-way path signal will allow better servicing than a one-way
02:22<Afdal>But it doesn't explain why a one-way path signal will allow better servicing over block/presignals
02:24-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
02:24-!-Pixa [~pixa@] has joined #openttd
02:32<Afdal>Actually, a second test gives slightly lower maintenance rate for two-way than one-way
02:32<Afdal>I guess I need to run it a lot longer to be conclusive
02:33-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
02:33-!-Pixa [~pixa@] has joined #openttd
02:40-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
02:41-!-Pixa [~pixa@] has joined #openttd
02:47-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
02:47-!-Pixa [~pixa@] has joined #openttd
02:48-!-TWerkhoven[l] [] has quit [Ping timeout: 480 seconds]
02:51-!-Pixa [~pixa@] has quit []
02:51-!-Pixa [~pixa@] has joined #openttd
02:55-!-Pixa [~pixa@] has quit []
02:56-!-Pixa [~pixa@] has joined #openttd
02:57-!-Netsplit <-> quits: jonty-comp, Vadtec
02:58-!-Netsplit over, joins: Vadtec, jonty-comp
03:00-!-Pixa [~pixa@] has quit []
03:00-!-Pixa [~pixa@] has joined #openttd
03:03-!-TWerkhoven[l] [] has joined #openttd
03:09-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
03:10-!-Pixa [~pixa@] has joined #openttd
03:14-!-Pixa [~pixa@] has quit []
03:14-!-Pixa [~pixa@] has joined #openttd
03:20-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
03:20-!-Pixa [~pixa@] has joined #openttd
03:21-!-[1]Mark [] has joined #openttd
03:21-!-Mark is now known as Guest22060
03:21-!-[1]Mark is now known as Mark
03:21<@Terkhen>good morning
03:24-!-Pixa [~pixa@] has quit []
03:24-!-Pixa [~pixa@] has joined #openttd
03:35<@Terkhen>hi lordnokon
03:36-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
03:36-!-Pixa [~pixa@] has joined #openttd
03:37<Rubidium>moin Terkhen
03:38<@Terkhen>hi Rubidium :)
03:45-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
03:46-!-Pixa [~pixa@] has joined #openttd
03:50-!-Pixa [~pixa@] has quit []
03:50-!-Pixa [~pixa@] has joined #openttd
03:52-!-DDR [~chatzilla@] has quit [Remote host closed the connection]
03:54-!-Pixa [~pixa@] has quit []
03:55-!-Pixa [~pixa@] has joined #openttd
03:59-!-Pixa [~pixa@] has quit []
04:00-!-Pixa [~pixa@] has joined #openttd
04:07-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
04:07-!-Pixa [~pixa@] has joined #openttd
04:08-!-DDR [~chatzilla@] has joined #openttd
04:11-!-pugi [] has joined #openttd
04:13-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
04:13-!-Pixa [~pixa@] has joined #openttd
04:17-!-Pixa [~pixa@] has quit []
04:17-!-Pixa [~pixa@] has joined #openttd
04:18-!-DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183541]]
04:21<lordnokon>can anyone help me, my trains are suffering, on hills in nightly, i've tried the advanced options. Am i missing something? i've seen youtube clips where people's trains fly up and down hills
04:22-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
04:23-!-Pixa [~pixa@] has joined #openttd
04:24<@Terkhen>lordnokon: do you have realistic acceleration enabled? if so, with which slope inclination?
04:24<@Terkhen>also, it might just be that people in those videos have trains carrying less cargo or with more power
04:26<lordnokon>train acceleration is set to orginal
04:28-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
04:28<@Terkhen>try to set it to realistic, slope 3%
04:28<@Terkhen>those are the default settings
04:29-!-Pixa [~pixa@] has joined #openttd
04:32<lordnokon>no real change
04:32-!-Pixa [~pixa@] has quit []
04:32-!-Pixa [~pixa@] has joined #openttd
04:33<lordnokon>my trains are the same size, with power and speed. still they lose speed, theirs never does
04:33-!-andythenorth [] has joined #openttd
04:34<Afdal>Original acceleration is the default
04:35<lordnokon>ok hang on it works now... but now at the stations everything slows down
04:36<lordnokon>and all corner speeds are fooked lol
04:37-!-Pixa [~pixa@] has quit []
04:38-!-Pixa [~pixa@] has joined #openttd
04:39-!-Neon [] has joined #openttd
04:47-!-Pixa [~pixa@] has quit [Quit: No Ping reply in 180 seconds.]
04:47-!-Pixa [~pixa@] has joined #openttd
04:49-!-Progman [] has joined #openttd
04:51-!-LordPixaII [] has joined #openttd
04:53-!-TGYoshi [~TGYoshi@] has joined #openttd
04:53-!-KingPixaIII [] has joined #openttd
04:57-!-Pixa [~pixa@] has quit [Ping timeout: 480 seconds]
04:59-!-LordPixaII [] has quit [Ping timeout: 480 seconds]
04:59<@Terkhen>Afdal: original was the default :)
05:00<@Terkhen>lordnokon: my guess is that he is playing with 0% slopes
05:01<@Terkhen>but without a savegame it is just a guess
05:01-!-Pulec [] has joined #openttd
05:05-!-Progman_ [] has joined #openttd
05:07<@Terkhen>hi andythenorth
05:10<@planetmaker>hello andythenorth
05:11-!-Progman [] has quit [Ping timeout: 480 seconds]
05:11-!-Progman_ is now known as Progman
05:13-!-KouDy [] has quit [Quit: Leaving.]
05:13-!-Alberth [] has joined #openttd
05:13-!-mode/#openttd [+o Alberth] by ChanServ
05:31-!-mahmoud [] has joined #openttd
05:39-!-ohnoes [] has joined #openttd
05:39<ohnoes>hello everyone
05:39<TrueBrain>oh noes! It is ohnoes!
05:42<ohnoes>I would like to ask a question. I am still novice but I am facing a problem regarding a coal mine, a power station and the railways I built. For some reason I do not understand, my coal keeps accumulating at the station next to the power station and when I click it there is a "x tonnes of coal en-route from <the station where the coal mine is>"
05:43<@planetmaker>do you use transfer or unload orders or does the power plant station not accept the coal?
05:44<ohnoes>I am using full load <coal mine> -> full unload <station near the power station> -> maintain at <some depot>
05:45<@planetmaker>don't use unload
05:45<@planetmaker>just use normal 'goto'. It'll unload, if accepted
05:45<@planetmaker>and does the station accept coal?
05:45<ohnoes>I think I tried that before too before I changed to "full unload" but I will give it a try again. thanks!
05:46<@planetmaker>if it doesn't unload then, the power plant or station does not accept coal.
05:46<@planetmaker>hard to say what when talking w/o savegame
05:46<ohnoes>it didn't unload
05:47<ohnoes>but the power station says "requires: coal". what do you mean by it "does not accept coal" ? Is there a way I can check that?
05:48<@planetmaker>if you don't use industry newgrfs, the power plant will always require coal
05:48<@Alberth>I always open the 'build station' window, make station the same size as you have, and hover over the existing station. Then watch the build-station window, it should say 'accepts coal'
05:49<@planetmaker>so do I :-)
05:49<@Alberth>there should be an easier way to do this, I agree ;)
05:50<@planetmaker>so do I :-P
05:51<ohnoes>exactly, that's what I did too
05:51<ohnoes>but actually since yesterday I am trying the 32bpp
05:51<ohnoes>newgrfs... is that the cause of the problem ?
05:51<@Alberth>could be, do you use ECS ?
05:52<ohnoes>Oh sh**...
05:53<ohnoes>my bad. I just noticed that the power station was partially covered by the train station (without accepting coal)
05:53<@Alberth>always nice to solve a problem just by asking questions ;)
05:53<ohnoes>like I said. noob :) thank you everybody
05:53<@Alberth>Extending the station a bit should work, I think
05:54<ohnoes>yeah, that's probably what I'll do :)
05:54<ohnoes>I made it parallel, so probably I will just add a new line
05:54<@Alberth>existing cargo at the station will not be accepted until you transport it again though
05:55<@Alberth>just letting it linger is also an option, it will disappear in time
06:00-!-Devroush [] has joined #openttd
06:08-!-JVassie [~James@] has joined #openttd
06:17-!-Zuu [] has joined #openttd
06:20-!-|Jeroen| [] has joined #openttd
06:30-!-mahmoud [] has quit [Ping timeout: 480 seconds]
06:35-!-valhallasw [] has joined #openttd
06:36-!-Elukka [] has joined #openttd
06:37-!-Wolf01 [] has joined #openttd
06:44-!-mahmoud [] has joined #openttd
06:48-!-tokai|mdlx [] has joined #openttd
06:48-!-tokai [] has quit [Read error: Connection reset by peer]
06:51-!-Amis [] has joined #openttd
06:52<Amis>Whoever did the hot air balloooooon newgrf...
06:52*Amis bow
06:52<@Alberth>it does not say who the author is?
06:53<Amis>I have no idea. I just put together a newgrf pack quickly and was playing it and all of a sudden
06:53<Amis>Hot air balloon
06:53<Amis>I'm like... wtfawesome
06:53<@Alberth>or if you can find the topic in the forum, you can find his forum name and send a PM to him
06:54-!-Adambean [] has joined #openttd
06:58<Amis>Haha, I didn't know it's possible :D
06:58<Amis>"Aircraft ran out of fuel"
06:58-!-ohnoes [] has quit [Quit: ohnoes]
06:58<@Alberth>it was recently added
06:59<@planetmaker>well. it was possible before, if you destroyed all airports
06:59<@planetmaker>and the aircraft had nowhere to land
06:59-!-KingPixaIII is now known as Pixa
07:02-!-valhallasw [] has quit [Ping timeout: 480 seconds]
07:02-!-mahmoud [] has quit [Ping timeout: 480 seconds]
07:21-!-Markavian [] has joined #openttd
08:03-!-Biolunar [] has joined #openttd
08:17-!-Brianetta [] has joined #openttd
08:18-!-Brianetta [] has quit [Remote host closed the connection]
08:19-!-Brianetta [] has joined #openttd
08:27-!-valhallasw [] has joined #openttd
08:45-!-appe_ [] has joined #openttd
08:45-!-appe [] has quit [Read error: Connection reset by peer]
08:55-!-sla_ro|master [~slaco@] has joined #openttd
08:59<@Alberth>hi hi
09:01<@Belugas>mister Alberth, how are you going?
09:01<@Belugas>damned.. fingers are slow today
09:02<@Alberth>a bit annoyed with my lack of progress w.r.t. paths in freerct, so I am playing a bit of OpenDune :p
09:02<@Belugas>-18 celcius...ooch
09:02<@Alberth>ieks, please keep that there :)
09:02<@Belugas>you are? cool :) I should give it a try indeed :)
09:02<@Belugas>herm... at OpenDune...
09:03<@Belugas>not at sending you da cold
09:05-!-Neon [] has quit [Ping timeout: 480 seconds]
09:19-!-HerzogDeXtEr [] has joined #openttd
09:35-!-Elukka [] has quit [Read error: Connection reset by peer]
09:36-!-Elukka [] has joined #openttd
09:37<Eddi|zuHause> <-- that's seriously the weirdest "preserved engine" i have seen yet :p
09:41<@Alberth>looks like an Orcs machine from warhammer 40000 :p
09:54<JVassie>can anyone see anything wrong with ym query pls?
09:54<JVassie>1064 normally means reserved keyword
09:54<JVassie>but i cant see any that im usign which are reserved
09:56-!-glx [glx@2a01:e35:2f59:c7c0:34e7:b910:a468:8ee9] has joined #openttd
09:56-!-mode/#openttd [+v glx] by ChanServ
09:58<JVassie>even if i change it to this
09:58<JVassie>ti doesnt work
10:01<JVassie>driving me crazy :(
10:05<@Belugas>JVassie, i would remove the quotes on the INSERT statement. I never use them. But i'm not useing MySQL, so i cannot tell
10:06<JVassie>around the column names or the values in inserting?
10:06<@Belugas>INSERT INTO Transferees (title,firstname,lastname...
10:07<JVassie>Belugas: genius :D
10:07<@Belugas>i am? cool :)
10:08<JVassie>brain acheing, hard to think what i couldve been doing wrong :p
10:08<@Alberth> <-- doesn't mention the columns at all
10:08<JVassie>INSERT INTO Persons (P_Id, LastName, FirstName)
10:08<JVassie>VALUES (5, 'Tjessem', 'Jakob')
10:09<Eddi|zuHause>planetmaker: <- opinions?
10:12-!-ptr [] has joined #openttd
10:15<andythenorth>JVassie: your column IDs are escaped in strings
10:15<andythenorth>try them without
10:15<JVassie>aye that fixed it
10:15<JVassie>s'what belugas suggested :)
10:15<JVassie>but thx
10:15<andythenorth>oh ok
10:15*andythenorth was just guessing
10:15<JVassie>good guess then :D
10:24-!-snack2 [] has joined #openttd
10:25-!-fjb|tab is now known as Guest22088
10:25-!-fjb|tab [] has joined #openttd
10:25-!-Guest22088 [] has quit [Ping timeout: 480 seconds]
10:28-!-ptr_ [] has joined #openttd
10:28-!-ptr [] has quit [Read error: Connection reset by peer]
10:28-!-ptr_ is now known as ptr
10:30-!-JVassie_ [~James@] has joined #openttd
10:33-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
10:33-!-Amis [] has quit [Ping timeout: 480 seconds]
10:34-!-Pulec [] has quit []
10:42-!-Aali [] has joined #openttd
10:47-!-Neon [] has joined #openttd
10:48-!-Chris_Booth [] has joined #openttd
10:49-!-ptr [] has quit [Read error: Connection reset by peer]
10:49-!-ptr [] has joined #openttd
10:56-!-DayDreamer [] has joined #openttd
---Logclosed Thu Dec 29 11:06:07 2011
---Logopened Thu Dec 29 11:06:18 2011
11:06-!-mikegrb_ [] has joined #openttd
11:06-!-Irssi: #openttd: Total of 119 nicks [9 ops, 0 halfops, 2 voices, 108 normal]
11:08-!-Irssi: Join to #openttd was synced in 121 secs
11:10-!-mikegrb [] has quit [Ping timeout: 600 seconds]
11:16-!-Brianetta [] has quit [Remote host closed the connection]
11:16-!-leeroberson [] has joined #openttd
11:17<leeroberson>wow, lots of users in this channel, hurray
11:17-!-leeroberson is now known as eberon
11:17<eberon>I'm just starting back on OpenTTD after an extremely long hiatus.
11:18<andythenorth>good choice
11:18-!-supermop [] has joined #openttd
11:18<eberon>can someone tell me, does OpenTTD ship with an AI in the installer, or do I need to find and pick one in order to play with an AI?
11:18<andythenorth>download AIs from in-game content service
11:18<andythenorth>I don't think one comes bundled
11:18<eberon>okay great, I got the sense I needed to do that
11:19<eberon>most of them seem experimental, is there a solid one?
11:19<andythenorth>Zuu: ^ ?
11:20<@Alberth> perhaps?
11:20<Zuu>There are several good ones.
11:20<Zuu>I use to play with CluelessPlus and AIAI.
11:21<eberon>durr, my eyes skipped the wiki link on the site, this should be super helpful.
11:21<Zuu>Convoy is also very stable.
11:22<eberon>thank you for the recs, clueless so far seemed to be the one with the most reasonable looking description but I will try a few of them
11:22<Zuu>And there are more, it's just that I tend to only play with 2-3 in a single game.
11:22<eberon>I am so excited at how much OpenTTD has improved in the last couple of years. This is one of my first childhood games, got it on floppies at a computer store that had racks of shareware in ziplock bags.
11:23<@Belugas>floppies... long time ago indeed :)
11:23<andythenorth>there's a *lot* of new stuff :)
11:23<Zuu>My other AI, PAXLink is something you could stay away from if you look for rock solid AIs :-)
11:24<eberon>Zuu: I hope to become killer at this game again!
11:24<eberon>andythenorth: one thing that turned me off of OpenTTD was the vast changes. I liked that it improved gameplay issues but otoh some of the changes were a little extreme and felt like cheating. I like the rules manager in the game. I wish it had presets.
11:25<eberon>I've done some work on other FOSS projects in the past, maybe that is something I will try to advocate for or work on in OpenTTD at some point
11:25<eberon>after a play a few dozen games :D
11:25<Zuu>You are more than welcome to contrubute to the OpenTTD project :-)
11:26<Zuu>But starting by playing is probably a good idea to get an idea of the vast changes and improvments compared to TTD :-)
11:27<eberon>Yeah. I just noticed the server list on, that's amazing, I guess there's network code now?
11:27<@Alberth>nah, we have a 'multiplayer' button at the intro screen just for looks :)
11:27*Zuu remembers the WWOTTDGD2
11:28<Zuu>(world wide openttd game day 2)
11:28<eberon>Alberth: ha, in open source games there's a ~50% chance that means you'll get a "coming soon!" screen when you press a button like that
11:28<andythenorth>ottd doesn't do that so much
11:28<@Alberth>eberon: our buttons are mostly quite functional :)
11:28<andythenorth>if it doesn't work, it's not shipped
11:29<@Alberth>of ocurse, it may not do what you think it does :)
11:29<andythenorth>more often it doesn't do what I think it should :P
11:31<Elukka>Eddi|zuHause: starting to look alright?
11:32<+michi_cc>Elukka: Slightly related question: Would you say that drawing such a wagon for x2/x4 zoom in still in 8bpp makes sense and looks good? Or are zoomed in sprites not in 32bpp useless?
11:34<Elukka>i think i'd do it in 32bpp (why not?) but still in the pixel art style if it's meant to fit together with current graphics
11:35<+michi_cc>Because the 32bpp-anim blitter is a lot more expensive than all other blitters.
11:35<Elukka>well, dunno then
11:36<Elukka>that sprite is for the default zoom level, just zoomed in in photoshop so it's easier to see
11:36<+michi_cc>The question is more like, is it possible to draw proper zoomed-in sprites in 8bpp or are the colours too limited?
11:36<Elukka>i think it's possible
11:36<Elukka>i haven't tried though
11:37<+michi_cc>So it does make sense to implement/allow it :)
11:37<andythenorth>michi_cc: it's possible
11:37<andythenorth>what the style would be I have no idea
11:38<TrueBrain>michi_cc: if it doesnt hurt, there is never a loss by allowing it ;)
11:38<+michi_cc>andythenorth: How horrible does look to you?
11:38<Elukka>could just do the current style at higher resolution, andy
11:38<Elukka>depends on if it's meant to fit in with current graphics or with typical 32 bpp graphics
11:38<andythenorth>Elukka: in that case just zoom in photoshop, with interpolation turned off
11:39<andythenorth>instead of clicking 4x as often
11:39<andythenorth>or 16x as often
11:39<Elukka>that's not a higher res sprite though
11:39<+michi_cc>The current typical 32bpp graphics don't even fit themselves :)
11:39<Elukka>if the sprite was double or four times the resolution there's much more room for detail
11:39<andythenorth>that's a style change :)
11:40<Elukka>not necessarily
11:40<andythenorth>michi_cc: what does it do? Additional realsprites?
11:40-!-Neon [] has quit [Ping timeout: 480 seconds]
11:40<+michi_cc>Extended RealSprite (or however you'd want to call it) for multiple zoom levels and/or 32bpp.
11:41<Elukka>hm. i'll do a quick 2x version of one of my sprites (just one angle) to see how it'd look
11:42<andythenorth>michi_cc: looks ok
11:47<Elukka>so, is there/will there be a trunk implementation of higher res sprites for the extra zoom levels?
11:47<Elukka>because that'd be really nice
11:48<TrueBrain>Elukka: I think that is what michi_cc is hinting about ;)
11:53-!-bremerjoe [] has joined #openttd
11:53<bremerjoe>Good evening everybody!
11:55-!-ptr [] has quit [Read error: Connection reset by peer]
11:55-!-ptr [] has joined #openttd
11:56<TrueBrain>"We received instruction from the Debt Management office, The Presidency, to have your fund approved by the contract Review and Payment Committee"
11:57<Elukka>oh man twice the resolution is lovely
11:58<Elukka>so much more room for detail
11:59<andythenorth>there speaks someone who doesn't have about 250 open tickets for newgrf sets :P
12:00<Elukka>technically i'm supposed to do the rolling stock for CETS, i'm just too lazy to get much done :P
12:00<andythenorth>EZ should be rendered not drawn
12:01<andythenorth>and with the extra angles in CETS, you might seriously consider it
12:01<andythenorth>build one model, render all 16 angles
12:02<Elukka>i'd do that even for default resolution sprites because all those angles get really tedious but i don't have the required rendering wizardry skills
12:02<andythenorth>possibly use UV mapping
12:02<andythenorth>with UV mapping, you draw a net and then wrap it to a mesh
12:02<Elukka>i could do the models easily enough, but i can't make a renderer poop out pixel art
12:03<Elukka>it's possible and i've heard someone does it through arcane scripting magics, i just don't know how
12:03<Elukka>i'd love to know, though
12:03<andythenorth>no idea
12:03<andythenorth>voxels :P
12:03<Elukka>it'd make it immeasurably easier and faster... i don't think i'd use uv maps, i'd just get the basic shape and overpaint that
12:04<TrueBrain>what happened to that dude anyway?
12:04<Elukka>which dude
12:04<TrueBrain>our voxel / cubical dude
12:04<andythenorth>we drove him away, he was a fool
12:04<Elukka>can we get a non-fool who can help me set up a rendering thing? :P
12:05<andythenorth>this isn't rendered pixel art...but:
12:06<TrueBrain>Elukka: I just setup a blender file which renders my lego for me :P
12:06<andythenorth>apparently the best thing is to use something called Qubicle Constructor
12:06<andythenorth>where did I hear that before? :p
12:07-!-TomyLobo2 [] has joined #openttd
12:07<Elukka>is openttd actually isometric?
12:07<Elukka>or dimetric or something
12:07<Elukka>important to get the projection right
12:07<TrueBrain>andythenorth: minecraft for grownups :)
12:08<TrueBrain>Elukka: which app you use?
12:08<andythenorth>Elukka: dimetric
12:08<Elukka>i've used kerkythea for general rendering work but it's been having issues
12:08<Elukka>i can do blender too
12:08<TrueBrain>for blender: Isometric, 30 degrees, at a 45 angle
12:09<TrueBrain>12.5 in 'width' is 1 tile
12:09<TrueBrain>(on a 128x64 resolution)
12:09<Elukka>thanks, i've gotta try it out
12:10<TrueBrain>took me a while to find the right values ...
12:10<Elukka>i'm thinking maybe i'll make my models out of pixel-sized blocks
12:10<TrueBrain>the .blend on te wiki (and tt-forums) is wrong
12:10<TrueBrain>annoying as fuck :P
12:10<Elukka>24 angles by hand is... tedious as hell
12:11<TrueBrain>unwise :P
12:11<TrueBrain>single change, and redo them all :(
12:11<TrueBrain>atm I just hit RunScript, and 2 minutes later I have new files :P
12:12<Elukka>you have script for it?
12:12<Elukka>what's it do?
12:12<TrueBrain>render all faces, save them correctly, runs pngcodec over them
12:13<Elukka>if i can have that you'll get all the cookies
12:13-!-TomyLobo [] has quit [Ping timeout: 480 seconds]
12:13-!-TomyLobo2 is now known as TomyLobo
12:13<TrueBrain>power of Python in Blender :P
12:14<TrueBrain>very specific for my case, but you get the point :)
12:14<TrueBrain>hope to finish my 'master' blender soon; will make sure to publish it
12:14<TrueBrain>(linking to other blend files is AWESOME)
12:17<bremerjoe>hi all, trying to save translated file to the wiki but can not get it link correctly. Could anyone give me a hint?
12:19-!-LordPixaII [] has joined #openttd
12:19<@Yexo>bremerjoe: your article is named "Ladebuchten", it should be named "Ladebuchten/De"
12:20<@Yexo>I've now moved it for you
12:21<@Yexo>and I see it's time to run the language script again
12:21<TrueBrain>what does it do?
12:22<@Yexo>if you add a new translations and link it from the english page, the script adds links from all translated pages to the new translation
12:23<TrueBrain>nice :)
12:23<@Yexo>so in the case above: You add it to "Loading bays", script adds the link to "Ladebuchten/De" from "Estaciones_para_vehículos_de_carretera/Es" "Aire_de_chargement/Fr" and "Laadperrons/Nl"
12:23<@Yexo>last time I ran that script was somewhere in the summer I think, completely forgot about it
12:23<TrueBrain>should we run it every night?
12:23<@Yexo>would be best if it ran every night on the server
12:23<bremerjoe>THX Yexo! Could you tell me how you edited the article name?
12:23-!-fjb|tab is now known as Guest22099
12:23-!-fjb|tab [] has joined #openttd
12:23-!-Guest22099 [] has quit [Read error: Connection reset by peer]
12:23-!-Pixa [] has quit [Ping timeout: 480 seconds]
12:23<TrueBrain>Yexo: either do it under your own user, or I can move it to www-data or something if you like
12:24<TrueBrain>or do it under your own user, and I will move it :P
12:24<@Yexo>bremerjoe: on the top next to "page" and "edit" there is a "move" button
12:24<@Yexo>TrueBrain: ok, currently I run it from my laptop. I'll run it again first and later upload it and notify you again
12:24<TrueBrain>great :)
12:24<TrueBrain>useful scripts :)
12:24<bremerjoe>learning step by step. Thanks again Yexo!
12:25<@Yexo>you're welcome :)
12:25<bremerjoe>I understand correctly that I need to link mine to the english version by adding |de=Ladebuchten there, right?
12:26<@Yexo>yes, but you've already done that
12:26<@Yexo>you don't need to edit all other languages, I'll do that (with a script) later
12:26<bremerjoe>OK. Just wanted to make sure I know that this is necessary and not messing up anything
12:27<@Yexo>dinner time
12:27<TrueBrain>eet ze Yexo
12:32<JVassie_>doing a mysql query 27k times in php sucks ass
12:32-!-Chris_Booth is now known as mdf
12:32<TrueBrain>doing (..) php sucks ass
12:33<andythenorth>lol @TrueBrain
12:33-!-mdf is now known as Chris_Booth
12:33*JVassie_ shall play RIFT whilst it trundles along
12:33<andythenorth>JVassie_: what are you doing / why?
12:34<JVassie_>i have a table of soem 27k rows
12:34-!-|Jeroen| [] has quit [Quit: oO]
12:34-!-DDR [~chatzilla@] has joined #openttd
12:34<JVassie_>which is a copy of another table
12:34<JVassie_>the new table is using the old tables unique id as a foreign key
12:35<JVassie_>so the new table needs a new unique id
12:35<JVassie_>starting from 0 etc
12:37-!-ptr_ [] has joined #openttd
12:37-!-ptr [] has quit [Ping timeout: 480 seconds]
12:37-!-ptr_ is now known as ptr
12:38-!-supermop [] has quit [Remote host closed the connection]
12:39-!-supermop [] has joined #openttd
12:39<andythenorth>27k doesn't sound that much
12:41*andythenorth knows very little about mysql
12:41<andythenorth>couldn't you just drop the old data to csv, then write an import script, using mysql's auto-inc when you add the new record?
12:43-!-lordnokon [] has quit [Ping timeout: 480 seconds]
12:45<@Belugas>... and you're doing youre query once per row???
12:45-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
12:47<andythenorth>also, why copy the table?
12:47<andythenorth>why not just add a column?
12:49*andythenorth learns about database normalisation
12:50-!-ntah [ntah@] has joined #openttd
12:50*Belugas learned a ling time ago that sometims, normalization is the opposite of performance
12:50-!-Alberth [] has left #openttd []
12:51<@Belugas>so, sometimes, for sake of performance, y9u have to sacrifice a bit of normalisation, or put TONS of indexes. Which sometime sucks on inserting
12:51<@Belugas>but is fast on reading. since I do more inserts than reads... well...
12:53-!-Biolunar [] has joined #openttd
12:57-!-snack2 [] has quit [Ping timeout: 480 seconds]
13:03<@Belugas>-16 :( i will not go out shopping a new guitar today :S
13:06-!-ntah [ntah@] has quit [Quit: 전 이만 갑니다.]
13:08-!-encoded [] has joined #openttd
13:08<encoded>i love TTD, i was playing it off and on till... yesterday
13:09<encoded>only now i found out about openttd
13:09<@Belugas>cool :)
13:09<encoded>it's great... but i can bearly see stuff needs a few more zoom levels
13:10<encoded>and the controls too
13:11<TrueBrain>even more zoom levels?
13:11<TrueBrain>I thought 4 times zoomed in should be sufficient, even for a 60" screen
13:11-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
13:11<encoded>not at 1920x1080
13:12<@Belugas>what stuff are you talking about?
13:12<@Belugas>fonts or items?
13:13<encoded>even at 1280x768 it could be bigger
13:14<encoded>i cant belive im the first to comment about it
13:15<andythenorth>it's never been mentioned before ever ever ever :)
13:15<TrueBrain>You are absolutely the first, and this issue hasn't been adressed at all!
13:16<TrueBrain>TO THE BATMOBILE! (*tune starts here*)
13:16<encoded>how do i get a screenshot?
13:16<eberon>I think I'm going to be spending a lot of time lurking in this channel from now on ;)
13:16<TrueBrain>put your screen on a photocopier
13:16<andythenorth>encoded: '?' then 'screenshot'
13:17<andythenorth>unless you have opengfx, then I have no idea :)
13:17<TrueBrain>eberon: you and the other 114 people in here :D
13:17<andythenorth>encoded: if you were playing TTD, I figure you have the original graphics?
13:17<encoded>i went with the openfx
13:18<andythenorth>well it seems to also be '?' in opengfx
13:18<andythenorth>also if you go to 'advanced settings' -> 'interface' -> 'display options' -> 'maximum zoom level'
13:19<andythenorth>what value do you have?
13:19<TrueBrain>andythenorth: start first by asking which version he is playing ;)
13:19*andythenorth forgets these things
13:19<andythenorth>hg pull -u; make run -j13 is like a daily thing for me
13:19<encoded>latest stable
13:20<TrueBrain>@topic -2
13:20<@DorpsGek>TrueBrain: topic [<channel>]
13:20<TrueBrain>@topic #openttd -2
13:20<@DorpsGek>TrueBrain: topic [<channel>]
13:20<TrueBrain>how does this work?
13:20<@DorpsGek>TrueBrain: 1.1.4, 1.2.0-beta1 | Website: * (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | Don't ask to ask, just ask | 'Latest' is not a valid version, ever | English only
13:20<TrueBrain>encoded: ^^
13:20<TrueBrain>"'Latest' is not a valid version, ever"
13:20<TrueBrain>that part, to be clear ;)
13:20<@Belugas>[13:16] <TrueBrain> put your screen on a photocopier <-- lol!!!! Made my day :D I DO LOVE YOU, It's now official !
13:21<TrueBrain><3 Belugas
13:21<eberon>mm, abundant room to look at the terrain
13:21<eberon>you must love that
13:21<andythenorth>encoded: looks lovely :)
13:22<andythenorth>there is a way to get big gui, I forget how
13:22<Aali>its a grf, its in bananas
13:23<encoded>but youre saying i can get more zoom levels in latest beta?
13:23<Aali>also, long time no see #openttd
13:23<andythenorth>openttd 1.2.0-beta1 has extra zoom levels
13:25<encoded>thx i'll check it out later
13:29<eberon>guys, I have a question of clarification here
13:29<eberon>Is this trying to state that when a train needs to move on an angle, it slows down (seems obvious, you can even watch it happen) or that one type of track that orients in one direction is actually slower than another (seems absurd).
13:31<eberon>if the former, I'm not sure "move slower on angled track" is exactly precise, not to be a nitpick, probably a more accurate way of saying it is that trains slow down for tracks that turn/change direction
13:31<TrueBrain>diagonal track != angled track
13:31<TrueBrain>I guess there you go wrong
13:32<SmatZ>In OpenTTD, trains move slower on angled track (thanks SmatZ!),
13:32<SmatZ>yay, I am thanked to there! :)
13:32<eberon>yeah, I was going to say, IMO the header there confuses me too
13:33<eberon>are we talking about tracks that are not perpenticular to the isometric view of the terrain or tracks that change direction?
13:33<eberon>sorry if I'm coming off nutty
13:34<TrueBrain>angled track, 2 pieces of track with an angle
13:34<TrueBrain>diagonal track, track that goes diagonal
13:35<SmatZ>on || or == tracks, the train moves slower
13:35<eberon>wow, really?
13:35<SmatZ>from your point of view
13:36<eberon>it has the same max speed but it has lower acceleration?
13:36<eberon>so you mean pixel distance on the screen
13:36<SmatZ>yeah, something like that
13:36<SmatZ>the problem is that it slows down the train behind it
13:36<SmatZ>eg. when you have two 10-tiles long trains
13:37<SmatZ>the second one is waiting behind the first one, the first one is stopped
13:37<SmatZ>and you start the first one
13:37<SmatZ>on a // or \\ track
13:37<eberon>mind = blown
13:37<eberon>the signaling page both excites and brings great fear to me
13:37<SmatZ>they will soon keep some constant distance
13:37<eberon>ah, so openttd's contributors do consider it a flaw
13:38<SmatZ>but once the first train enters a || or == track (long enough), you will see the second trains will get more near to the first one, possibly slowing down or even stopping
13:38<Aali>its not something you need to worry about 99% of the time
13:38<SmatZ>it's been that way since the dawn of times
13:38<SmatZ>eg. TTO
13:39<andythenorth>do some newgrfs really have trains that change direction according to orientation of route?
13:39*andythenorth calls BS on that
13:39<andythenorth>length / direction /s
13:39<SmatZ>on heavily used tracks, like in #openttdcoop games, it sometimes is a problem
13:39-!-ptr [] has quit [Read error: Connection reset by peer]
13:40<andythenorth>"The following examples have been created under the assumption that the length of the train also changes on diagonal track. This seems to be true for only some NewGRFs! (Iirc, it is true for the JapanSet and wrong for the default trains.)"
13:40<SmatZ>andythenorth: length of a vehicle can't change outside of a depot
13:40<SmatZ>andythenorth: maybe there are some news I don't know about :)
13:40-!-ptr [] has joined #openttd
13:41<SmatZ>but... just imagine an engine suddenly gets longer... so the wagon behind it has to hop back, or whatever
13:41<andythenorth>smells of more wiki crap to me
13:41<andythenorth>curvature you can get
13:41<andythenorth>orientation is not a varact2 afaik
13:41<andythenorth>unless it's in the 80+ vars
13:41<SmatZ>actually, a newgrf can do that
13:42<Aali>sure its not some rounding "error"?
13:42<SmatZ>but it triggers a "newgrf bug" in openttd
13:42<Aali>since default wagons are all half-tile
13:42<Aali>and I assume japset isn't
13:42<+glx>@topic get -2
13:42<@DorpsGek>glx: 'Latest' is not a valid version, ever
13:42<+glx>TrueBrain: ^^
13:42<+glx>"get" is the word :)
13:43<TrueBrain>glx: tnx :)
13:43*andythenorth roams the 80+ vars
13:43<andythenorth>I could change graphics depending on where a ship/plane is trying to get to :P
13:44<andythenorth>there is a var for direction
13:44<@Belugas>there is an app for that
13:45<SmatZ>you are not the first to ponder about "smooth" vehicle rotation, by supplying different sprites depending on the "angle" of the vehicle
13:45<+glx>it's an ithing ?
13:45<CIA-6>OpenTTD: translators * r23685 /trunk/src/lang/ (norwegian_bokmal.txt swedish.txt vietnamese.txt welsh.txt):
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: norwegian_bokmal - 67 changes by mantaray
13:45<CIA-6>OpenTTD: swedish - 25 changes by tobjork
13:45<CIA-6>OpenTTD: vietnamese - 1 changes by nglekhoi
13:45<CIA-6>OpenTTD: welsh - 50 changes by kazzie
13:45<andythenorth>SmatZ: I have no intention of smooth rotation :P
13:46<andythenorth>there are curvature props anyway. CETS uses them
13:46<@Belugas>hehe @ glx
13:51-!-Lakie [~Lakie@] has joined #openttd
13:51<andythenorth>80+ var 3F
13:51<andythenorth>Cargo transit time, in +185 ticks
13:51*andythenorth wonders which cargos catch fire if not shipped in time
13:52<andythenorth>new industry: iceberg harvester
13:52<andythenorth>new ship: iceberg tug
13:54<bremerjoe>andythenorth: there are chemicals that need to be cooled as they would burn at regular outdoors temperature, at least my former gf told me so (she: Dipl. chem)
13:55<bremerjoe>so if the dry ice used for cooling is used up after certain time the stuff would burn
13:57-!-KouDy [~KouDy@] has joined #openttd
13:59*andythenorth ponders road vehicles that wheelie whilst overtaking
13:59<andythenorth>whatever happened to newgrf smoke?
14:00-!-ZirconiumX [] has joined #openttd
14:01<ZirconiumX>Hello everyone
14:01*ZirconiumX is having issues with Squirrel
14:01<TrueBrain>give it a nut
14:02<+glx>TrueBrain was faster than me :)
14:02<ZirconiumX>AITown::GetTownCount() returns and int
14:02<ZirconiumX>yet when I put it in a for() loop:
14:03<ZirconiumX>for (int loop_a = 0; loop_a < AITown.GetTownCount(); loop_a++)
14:03<ZirconiumX>it spits it out
14:03<bremerjoe>squirrel + nut = squirrel taking of with nut, so no more programming
14:03<andythenorth>do while i < 1: i=0;
14:03<ZirconiumX>Unless you are watching Ice Age
14:04<TrueBrain>"it spits it out"
14:04<TrueBrain>it mostly gives you a bit more, then a broken nut
14:04-!-Simon_ [] has joined #openttd
14:04<+glx>one day you'll learn it :)
14:04<TrueBrain>keep hoping :P
14:04<ZirconiumX>Your script made an error: comparison between '0' and 'function'
14:04<+glx>store the value in a var
14:05<TrueBrain>ZirconiumX: odd. You sure you have the ()
14:05<TrueBrain>anyway, better to use AITownList
14:05<TrueBrain>and foreach ()
14:05<Simon_>Hi, I'm still pretty new to openttd.. I seem to be having troubles using
14:05<ZirconiumX>^^ is main.nut
14:05<+glx> for (local loop_a = 0; loop_a < AITown.GetTownCount; loop_a++) { // error
14:06<+glx>yes missing () :)
14:06<TrueBrain>I love it when my first guess is right
14:06<TrueBrain>too bad your first copy/paste did have the ()
14:06<TrueBrain>but using AITownList will speed up your script by a lot
14:06<Simon_>Whenever I select "Unload if accepted" the game deselects the order to unload.. net effect I'm only able to Unload All
14:06<Simon_>am I missing something?
14:08-!-Chris_Booth [] has joined #openttd
14:08<bremerjoe>Simon: that is normal for the game, nothing missed. If possible it will unload all
14:08<bremerjoe>if cargo is not accepted at station it will leave again
14:08-!-andythenorth [] has quit [Read error: Connection reset by peer]
14:08<bremerjoe>with all cargo
14:08-!-andythenorth [] has joined #openttd
14:09<Simon_>The game will unload cargo that isn't accepted at the station, then reload the cargo to the train
14:09<Simon_>exactly, so does that drop down box not work?
14:11<ZirconiumX>@TrueBrain - So squirrel represents an array by usng an int?
14:11-!-ptr [] has quit [Read error: Connection reset by peer]
14:11<TrueBrain>huh? no!
14:11<TrueBrain>your script is missing a (), that is why it fails
14:11<TrueBrain>so you can add a (), and it will work
14:11<ZirconiumX>I have
14:11<TrueBrain>but using for-loops like that is inefficient
14:11-!-ptr [] has joined #openttd
14:11<TrueBrain>using AITownList with foreach is much more efficient
14:12<ZirconiumX>Ah - you didn't say that
14:12<TrueBrain>I did, but that is not really important
14:12<andythenorth>is it possible to write an unclosed for loop in squirrel?
14:12<andythenorth>those tend to be performance sucks :P
14:17<ZirconiumX>so foreach (val in townlist1) {
14:17<ZirconiumX>or something like that
14:18*ZirconiumX apologises for being noobish
14:19<ZirconiumX>Also, Shouldn't there be a 1.1.4 API version?
14:22*ZirconiumX realises no-one wants to talk to a noob like me
14:23<bremerjoe>you do not want answers from a noob like me...
14:23-!-namad8 [] has joined #openttd
14:23<ZirconiumX>Well, they are better than no answers at all
14:26<bremerjoe>not really, just showing you that the channel is still being updated, so no internet connection issue or program freeze...
14:28-!-valhallasw [] has quit [Ping timeout: 480 seconds]
14:30-!-namad7 [] has quit [Ping timeout: 480 seconds]
14:36<bremerjoe>in spite of several users timeouts
14:37<bremerjoe>btw: extra zoom levels in 1.20beta rock, finally able to really see the signals on 1920x1080 (24")
14:38<bremerjoe>THX to all who made that possible!
14:44-!-Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20111221135037]]
14:46<Elukka>yeah it's pretty great
14:52-!-Simon_ [] has left #openttd []
14:52<@Belugas>yup, it's pretty and it's great
14:56<bremerjoe>would not exactly call it pretty with regular 8bpp ;) but I am still grateful that it exists, makes some tasks much easier and when I want to enjoy the results I zoom out further anyway
14:58<encoded>openttd is in C++?
14:59<encoded>with opengl or dx ?
14:59<encoded>or something else?
15:00<ZirconiumX>@encoded OpenTTD is in C and uses SDL or Allegro (or other stuff)
15:00<ZirconiumX>But AFAIK it doesn't use GL
15:04<TrueBrain>OpenTTD is very much in C++
15:05<TrueBrain>and for Windows GDI is used, much faster than DX I can only imagine :)
15:07*Belugas finds it darn pretty in 8bpp. been like that for so many times! 32bp is so... realistic . grumble grumble
15:09<encoded>ok so does it use SDL or not?
15:10<CIA-6>OpenTTD: michi_cc * r23686 /trunk/src/water_cmd.cpp: -Fix [FS#4921] (r23413): Infrastructure count of canals/locks/ship depots wasn't updated properly when a company went into bankruptcy or was taken over.
15:10<+michi_cc>encoded: Yes :)
15:10<ZirconiumX>Quote from configure
15:10<TrueBrain>encoded: it is one of the possible video drivers
15:10<ZirconiumX>checking for SDL: no
15:11<ZirconiumX>checking for Allegro: no
15:11<TrueBrain>encoded: it is a modular system; other video outputs can be used, depending on system (OS, libs, ..)
15:11<encoded>ZirconiumX, you suck, you dont know what language its written in
15:11<TrueBrain>for anything not Windows SDL is very common
15:11<TrueBrain>for Windows it is almost always GDI
15:11<TrueBrain>for DOS it has to be allegro
15:12<TrueBrain>Windows can use SDL (not recommended)
15:12<+michi_cc>for OS X it is Cocoa
15:12<TrueBrain>ah, good one michi_cc :)
15:12<TrueBrain>I believe OSX can no longer use SDL :P
15:12<TrueBrain>crappy support :(
15:12<+michi_cc>It can compile with SDL, but reports say the result isn't very pretty.
15:12<TrueBrain>SDL needs to be bootstrapped, which is silly at best :P
15:13<TrueBrain>owh, I thought we just dropped the support; easier :P
15:13<TrueBrain>but like using SDL on Windows: dont :D
15:13<encoded>i wish Windows(R) windows worked like TTD windows
15:13<TrueBrain>you do? Why ..
15:14<TrueBrain>TT windows annoy the crap out of me :P
15:14<encoded>they always know where to pop up
15:14<TrueBrain>X on the wrong side ... OK/Cancel always reversed ... :P
15:14<TrueBrain>well, 'wrong' and 'reversed' are of course up for debate, obviously :)
15:15<ZirconiumX>@TrueBrain - that is a good feature - becuase you always click Yes accidentally
15:15<ZirconiumX>Also, I note that a lot of smileys are being used :p
15:15<encoded>i still dont understand wtf is up with graphics
15:16<TrueBrain>encoded: turn them around?
15:16<encoded>SDL can use gdi and opengl and dx in windows
15:16<encoded>if youre using SDL for linux, why would it be bad to use it for windows?
15:17<ZirconiumX>OMFG - Hal the computer is running an OpenTTD AI
15:17<TrueBrain>encoded: such questions go so deep, I wonder if you have the time to sit down for it to listen to the complete answer :)
15:17<TrueBrain>encoded: I wonder if I can do it off by replying: because it is faster
15:17<TrueBrain>so I will try:
15:17<TrueBrain>encoded: because it is faster to not use SDL
15:17*ZirconiumX pictures the pixelated men running around
15:18<encoded>but but but... Crysis and Skrim and assasins creed and such use DX
15:18<TrueBrain>then again, they are 3D games
15:18<TrueBrain>so it is like comparing a chair with a plane
15:18<encoded>ok ok
15:18<TrueBrain>and SDL != DX :)
15:18<ZirconiumX>Windows GDI is direct to the screen - SDL has to communicate with Windows to show the picture
15:18<TrueBrain>you don't see them using SDL, do you? :)
15:19<encoded>ok, i'll investigate that SDL claim later
15:19<ZirconiumX>GL is not much use either - IIRC you cannot create buttons
15:19<TrueBrain>libSDL: if possible, avoid
15:20<TrueBrain>ZirconiumX: lol; trolling much; that or you have no clue what you talk about :)
15:20<ZirconiumX>I know what I'm talking about
15:20<TrueBrain>you could have fooled me there :)
15:20*ZirconiumX digs out SDL for Dummies
15:21<TrueBrain>encoded: the only reason I guess we still use SDL for Linux, is that 90% of the systems have it, or can easily install it
15:21<TrueBrain>I haven't found a (good) video library yet that does the same
15:22<TrueBrain>SDL is nice and all, for a small project; to quickly make something. If you don't want to bother with performance too much (or if your application is much slower than your blitter)
15:22<TrueBrain>it builds easy. Works the same for many platforms
15:22<TrueBrain>very useful for that
15:22<ZirconiumX>But very slow
15:23<encoded>ok, relax you threw the ball to SDLs corner, i'll investigate them later
15:23<TrueBrain>a few other problems exist with SDL
15:23<TrueBrain>the ypromise us 2.0 for ... years? now
15:23<andythenorth>ottd windows have the controls in the correct places
15:23<encoded>i'll tell them openttd is talking shit about them ;p
15:23<TrueBrain>I don't think anyone believes it will ever come out :P
15:23<TrueBrain>or was it 1.3?
15:23<TrueBrain>can't remember which next version they promised :)
15:23<TrueBrain>it should solve "all" problems
15:23<TrueBrain>but for that it has to be released :D
15:24<ZirconiumX>SDL is still in 1.0
15:24<TrueBrain>and that is why we all use 1.2.14+ I guess
15:25<ZirconiumX>sorry 1.2.X
15:25<TrueBrain>encoded: I wouldn't call it 'shit'. SDL is good for what it does
15:25<TrueBrain>GDI just does a better job :)
15:25<TrueBrain>(but only rusn on Windows)
15:25<ZirconiumX>@TrueBrain Not fair - you've got a time machine!
15:26<ZirconiumX>1.3 is supposed to be the new version
15:26<ZirconiumX>(still not released)
15:27*ZirconiumX bursts out with laughter
15:27<+glx>1.3 is dead since main dev is gone I think
15:27<ZirconiumX>SDL 1.3 is currently under active development and beta is anticipated Summer 2011
15:28<TrueBrain>encoded: in regards to DX, there is not really a performance gain to be expected by using a 3D API over a 2D API (which GDI is). Of course we can be wrong, not sure if anyone ever tried :)
15:28<TrueBrain>we do have OpenGL implementations, but they have either never been stable, or very slow
15:28<TrueBrain>(again, drawing 2D on a 3D canvas is a bit silly :D)
15:28<ZirconiumX>@TrueBrain - 32,000bpp for DirectX?
15:29<+glx><TrueBrain> it builds easy. Works the same for many platforms <-- even on OSX ?
15:29<TrueBrain>glx: yes
15:29<TrueBrain>see OpenDUNE
15:29<TrueBrain>it needs the silly bootstrap
15:29<TrueBrain>but so does Windows :)
15:29<encoded>ive been here a short time, but.. dunno... i find ZirconiumX extremly annoying
15:30<+glx>I remember the tweak for windows yes
15:30<ZirconiumX>@encoded - you haven't seen anything yet.
15:30<+glx>but it's mainly because dune2 is timer based
15:30<TrueBrain>hmm, I cannot find our benchmarks in regards to SDL and GDI. Sad :(
15:30<TrueBrain>ZirconiumX: I would take encoded advise, and not see it as a challenge
15:31<Mek>someone mentioned openttd 3d? ;) (a rather useless/silly experiment)
15:32<encoded>anyway im gonna try openttd a bit on ReactOS, if it uses gdi it might reveal a bug or 3!
15:32<ZirconiumX>@Mek - That is very good
15:32<encoded>Mek, ZOMG i wants!
15:34<Mek>:) it isn't very usable yet, not interaction possible etc
15:35<TrueBrain>encoded: good luck ;) Let us know!
15:35<TrueBrain>Mek: so that makes you alive, nice to know your trigger-words :P
15:35<ZirconiumX>@Mek - who cares - judging by encoded's response you have a fan club dedicated to just looking at it
15:36<Mek>yeah :) so far it is mostly a "I'm bored during the holidays, lets have some fun with opengl" project
15:36*encoded discovers
15:37<TrueBrain>Mek: <- taking something similar to the next level: in browsers :p (WARNING: only works if you have a sane video card on a sane (sorry linux) OS)
15:38<TrueBrain>encoded: yup; I am waiting for the day it is more commonly available :)
15:40<encoded>ok g2g, bye guys
15:40<encoded>i'll idle until i come back
15:40<TrueBrain>oeh, so we can fill your backlog with highlights like thisone encoded
15:40<TrueBrain>that can be very funny encoded
15:41<TrueBrain>or better yet: I just encoded my lego pngs
15:41<TrueBrain>and I wonder how to get my encoded pngs in a tar or grf
15:41<TrueBrain>I read michi_cc was working on getting such encoded pngs there
15:41<TrueBrain>would be quiet epic to have, dont you agree, encoded?
15:41<TrueBrain>sorry :D
15:42*ZirconiumX decides to have TrueBrain encoded into a .tar.gz file
15:42<ZirconiumX>which is a tar file encoded with Gnu zip
15:43*ZirconiumX bursts out with laughter
15:43<ZirconiumX>wouldn't you agree that I am being a bit of a <encoded>
15:43<ZirconiumX>At least I am not the only one
15:46<@Yexo>TrueBrain: that rts/test.html works fine for me (under linux)
15:46<TrueBrain>Yexo: it works in special conditions :)
15:46<TrueBrain>I believe Firefox + NVidia
15:47<TrueBrain>either ATI or Nvidia is still blacklisted, can't really remember :P
15:47<@Yexo>I did test in firefox, and I do have NVidia :)
15:47<TrueBrain>well, there you have it :)
15:47-!-Brianetta [] has joined #openttd
15:47-!-Brianetta [] has quit [Remote host closed the connection]
15:47<TrueBrain>on Windows it works under "almost" all browsers/GPUs .. with the clear exception of Intel GM GPUs :P
15:47<TrueBrain>those are not GPUs :)
15:47<@Yexo>about the for-loop before to iterate over towns: it's not only slower, it's (more importantly) completely wrong
15:48-!-Brianetta [] has joined #openttd
15:48<TrueBrain>Yexo: lol; nowedays town array is not sequential, is it? :)
15:48<TrueBrain>something I can never get used to :(
15:49<@Yexo>it never was
15:49<TrueBrain>never? You sure? :D
15:55<@Belugas>y9u mean there are holes in it?
15:55<TrueBrain>awh, SVN doesnt go back far enough :'( Sad sad panda! But okay, you are right :) I still somehow keep forgetting ;)
16:00-!-ZirconiumX [] has quit [Quit: ajax IRC Client]
16:02<andythenorth>oh he's gone :)
16:03<andythenorth>when he's here, there's usually more arguising
16:03<TrueBrain>people like him come and go. White noise, I guess.
16:04-!-Chris_Booth [] has joined #openttd
16:14-!-XaTriX [] has quit [Quit: ajax IRC Client]
16:49-!-eberon [] has quit [Remote host closed the connection]
16:50-!-eberon [] has joined #openttd
16:50<eberon>hi everyone, I'm running 1.1.4 and I can't seem to assign a bus to one of my bus+train stations, no matter what part of it I click on
16:51<eberon>is it maybe possible there's a square or two of road right inside/next to the city owned by a competitor that I'm not allowed to use?
16:51<MNIM>eberon: are you sure it's a bus station and not a truck station?
16:52<eberon>blah! it is a truck loading area
16:52<eberon>thanks for the advice
16:54-!-DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183541]]
16:56-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
17:07-!-Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20111221135037]]
17:10<eberon>another question -- is there any way to quickly tell elevation? I kind of hoped it would be in the 'about this square' tool
17:11<Progman>it isn't?
17:13<@Belugas>cool.. google "openttd elevation" first hit :
17:13<eberon>owner, cost to clear, coordinates, and local authority is all I get =\
17:13<Afdal>So can anyone explain to me why trains service for maintenance more often when you
17:13<Afdal>have a path signal leading them to their depot?
17:14<Afdal>Here's an example versus
17:14<eberon>Belugas: thanks, actually, now that I think about it, the elevation is there, it's just the third coordinate
17:15<eberon>Belugas: but I wouldn't have really thought about it hard enough to realize it until seeing that person's forum post confirming it's in there.
17:15<Afdal>Someone tried explaining to be earlier that the way pathfinding works, it looks for a depot ahead of the reserved track
17:16<Afdal>and a block signal before a two-way path signal allows a track to reserve the whole block between them
17:16<Afdal>meaning there's more time to coincide with the tick where it looks for a depot, and more probability to service
17:17<Afdal>But that doesn't explain a one-way path signal
17:17<Afdal>And the service rate between a one-way and a two-way should be different, but I haven't found any significant difference
17:20<Afdal>Did Belugas leave just after I typed that :(
17:22<@Terkhen>good night
17:30<Aali>Afdal: do you have trains going through the depot who are not targeting it per se?
17:31<Aali>might be that the penalties sometimes shift in favor of the depot track
17:31<Afdal>I don't think so
17:31<Aali>servicing without a service order was always unpredictable anyway
17:32<Afdal>At least not on the path signalled example
17:32<Afdal>I checked one time for that
17:32<Afdal>they all said going to such-and-such for maintenance
17:33<Aali>but, if anything, the PBS solution should make them service a tiny bit less
17:33<Aali>since a train can block the path to the depot with its own reservation
17:34-!-ptr [] has quit [Quit: Zzzzzz]
17:38<bremerjoe>g2g, goodn8
17:38-!-bremerjoe [] has left #openttd []
17:40-!-valhallasw [] has joined #openttd
17:45<+michi_cc>Afdal: A train searches a depot for automatic servicing in exactly two situations: a) When the pathfinder is called to extend the path or choose between tracks on a junction tile, and b) when the game time jumps to the next day.
17:46-!-encoded [] has quit [Ping timeout: 480 seconds]
17:47<+michi_cc>Afdal: This search is limited by how many tiles (or more precisely by pathfinder cost) the appropriate config variable defines. The search starts always at the last reserved tile furthest away from a path.
17:49-!-mahmoud [] has joined #openttd
17:49<+michi_cc>Afdal: In your example that means that in the first image, the depot search (if service is needed) is done either when entering the junction tile leading to the depot (and also starting at this tile) or whenever a new day rolls over, starting from the tile of the train engine.
17:51<Afdal>you mean the last reserved tile furthest from the front of the train right?
17:51<+michi_cc>Afdal: In the second image, the new day search will start at the end of the reserved path, which means that for the area between the last and the second last signal before the junction tile the starting tile is the junction tile *and not the train's engine tile*, so the depot is closer pathfinding wise with path signals.
17:52<Afdal>Yeah but
17:53<Afdal>trains only reserve track on a block signal before a two-way path signal
17:53<Afdal>My example uses a one-way path signal
17:54<Afdal>Don't you mean the area *on* the junction tile?
17:54<Afdal>not before it?
17:56<Afdal>Let me see if I'm understanding this correct: for the purposes of pathfinding, track reservation only counts entire tiles, and pathfinding happens BEFORE the actual track-specific reservation happens?
17:56<+michi_cc>For path signals pathfinding is initiated when entering the tile the signal is on.
17:57<Afdal>So.... How is that different for the two signals
17:57<+michi_cc>For non-path signals nothing happens when the signal tile is entered.
17:57<Afdal>I'm sorry if I'm still not understand this, it's confusing :(
17:58<Afdal>Am I right about this then?
17:58<Afdal> Let me see if I'm understanding this correct: for the purposes of pathfinding, track reservation only counts entire tiles, and pathfinding happens BEFORE the actual track-specific reservation happens?
17:58<Afdal>that doesn't seem to make sense actually
17:59<+michi_cc>Track reservation doesn't count anything. Pathfinding happens if needed, and if the train is (or is entering) a signal block with path signals, the result of the pathfinding is marked as the reserved path.
18:00<Afdal>So the path signal adds the length of its possible track reservation to the servicing pathfinding?
18:01<Afdal>I still don't see how that would bias it to service more often
18:01-!-KouDy [~KouDy@] has quit [Quit: Leaving.]
18:02<+michi_cc>The originating tile of the depot search is the last tile of the reserved path furthest away from the train engine. For a signal block not having any path signals, this is equivalent to the tile the engine itself is on.
18:03-!-sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
18:04<Afdal>Uh, so a train on the track with a path signal before the depot split will activate its pathfinding *sooner*?
18:04<Afdal>If so, how would that make it service more often
18:06<Afdal>Originally when this was explained to me I was thinking that the path signal gives more of a chance for a depot checking tick to coincide with the train while its on that path
18:06<Afdal>twice as much time, in fact
18:06<Afdal>But how does that work if a train reserves only one of the pathways anyway
18:07<+michi_cc>A path signal does not lead to more chances for finding a depot, it only changes the time/location the search might be done.
18:08<Afdal>Okay then, so...
18:08<Afdal>How does it end up with more servicing
18:08<Afdal>I've tested this pretty thoroughly too,
18:08<Eddi|zuHause>a path signal may prevent a depot visit in some cases where the distance between the signal and the depot is very high
18:09<Afdal>the example with a path signal definitely results in significantly higher servicing
18:09<Eddi|zuHause>because if a path is reserved beyond the depot, it cannot be changed to go into the depot afterwards
18:09<+michi_cc>Are you sure it actually does end up with more servicing, e.g. do the trains are actually in need of servicing when passing the last signal or passing the junction tile, respectively?
18:10<Afdal>Yeah, an easy way to test this without counting is to place another depot right on the track after the first depot
18:10<Afdal>well, I'll count it again just to be sure
18:10<Afdal>hold on
18:11<+michi_cc>And, also important, how close are the trains on the track? Is it possible that the non-path signal is still red when a depot search (via the new day route) is initiated? A red non-path signals has a pathfinder penalty which a path signals has not.
18:14<Afdal>the servicing rate with a path signal is nearly twice as high as with block or presignals
18:14<Afdal>Is it possible that the non-path signal is still red when a depot search (via the new day route) is initiated? Which signal?
18:15<Afdal>the signal at the split?
18:16<Afdal>No, I don't think so
18:16<Afdal>those depots are already at the maximum possible distance from their main track
18:16<Afdal>If I separate them any further trains don't service at all
18:16<Afdal>Because they can't find the depots
18:17<Afdal>so the depot search must be happening right on or very close to the split
18:20<Afdal>a successful depot search, that is
18:24-!-andythenorth [] has left #openttd []
18:26<Afdal>In fact
18:26<Afdal>I'll even say this
18:26-!-Devroush [] has quit []
18:26<Afdal>On the presignaled version,
18:27<Afdal>if a train is making the exit signal on the main track red when another train gets to the junction, it will take the depot path regardless if it needs to service or not
18:27<Afdal>Whereas with the path signaled version, it won't
18:27<Afdal>And yet the path signaled version *still* has higher train to depot rates
18:28<+michi_cc>Savegame and which version?
18:29<Afdal>Shall I upload it?
18:30<+michi_cc>Yes. I don't remember any major changes between 1.1.4 and 1.2.0-beta1 that should affect depot searching.
18:32<Afdal>It's better to test the disparity between servicing on those depots with the cyclotrons
18:33<Afdal>to be absolutely sure there's no involvement with the pathfinding from those priority merges just ahead ont eh track
18:35-!-TGYoshi [~TGYoshi@] has quit [Ping timeout: 480 seconds]
18:39<Afdal>For example, over a 2 year period, for two of those depots
18:39<Afdal>14 trains in total will service
18:39<Afdal>with regular signals
18:39<Afdal>With a path signal in front, they'll service 27 times
18:40-!-FLHerne [] has joined #openttd
18:43-!-DayDreamer [] has quit [Quit: Leaving.]
18:44<Afdal>the presignals before a depot are a bad idea now that I think of it, because of this
18:44<Afdal>Afdal On the presignaled version,
18:44<Afdal> Afdal if a train is making the exit signal on the main track red when another train gets to the junction, it will take the depot path regardless if it needs to service or not
18:45<Afdal>Even so, the servicing rate between block signaled and presignaled depots is roughly the same
18:45<+michi_cc>The answer is actually very easy, I'm just not sure if it really is intended behaviour or a bug.
18:46<+michi_cc>The check for serving on pathfinding is only done if a path reservation happens but not without path reservation. This means the non-path signal version has to rely purely on the "new day" check.
18:46<Afdal>oh, really?
18:47<Afdal>Also interesting is how that check was balanced so well with the new day check
18:48<Afdal>So it has nothing to do with probability then?
18:48<Afdal>the difference between the two, I mean
18:49<Afdal>Are you an OpenTTD developer?
18:49<Afdal>We should see if this is a bug or not
18:50<+michi_cc>The non-path signal variant searches for a depot (if the train actually needs service that is) whenever a new game day starts. The path signal variant does the search *additionally* when extending the reservation at a path signal.
18:51<Afdal>Thanks a lot, so nice to finally understand this
18:51<@Yexo>I think the reason for that was that if you have a bit longer signal blocks a train with a path reservation would never find a depot since it would always have a too long path
18:51<@Yexo>the exception is when it extends the reservation, since at that point it can start searching from the head of the train instead of from the next signal
18:51<Afdal>You might want to add it to both signal types then
18:51<Afdal>Unless you're fine with path signals being the only one to use for servicing
18:51<Aali>trains can still block the way to the depot with their own reservation
18:52<@Yexo>no, for block signals the train can change paths after going through the signal, that's a big difference
18:52<Aali>and never find a depot even though they should be able to
18:52<@Yexo>Afdal: before we had path signals servicing already worked fine
18:52<+glx>for block signals pathfinding is done at each split
18:52<+michi_cc>It's not really a bug per se, because originally there was never a service check on pathfinding. The only problem is that I can't remember anymore (even if I wrote all that path signal crap) why I added the check only for path reservation and not for all cases.
18:52<Aali>dont know how to solve *that* except allowing a train to change its reservation on the new day trigger
18:53<Afdal>yeah, but path signals result in better servicing
18:53<Afdal>so now that you have them, you should always use them for depots because of this
18:53<@Yexo>it really depends on the layout of your rails
18:53-!-Lakie [~Lakie@] has quit [Quit: sleep.]
18:53<Afdal>How so?
18:54<@Yexo>if you have a signal rail with a depot connected directly to it, looking for it everyday is often enough
18:54<+michi_cc>But I guess I didn't add it for block signals it could be expensive if it is really called on each and every junction tile.
18:54<@Yexo>even with block signals a train will almost never miss the depot in that case
18:54<@Yexo>the "problem" occurs when you put your depots away from the mainline so the trains don't hold up traffic, in combination with a smallish maximum penalty to the depot
18:54<Afdal>A Lev4 can easily go through 8 tiles (the default distance to check for a depot)
18:55<Afdal>in a whole day
18:55<Afdal>and miss its servicing
18:55<Aali>service at nearest or service at X orders "fixed" this problem already :)
18:55<@Yexo>Afdal: are you sure it's 8 tiles? I thought it was 16 or so
18:55<+glx>yes it's way better to tell where you want to be serviced if needed
18:55<@Yexo>same problem will still happen for faster trains of course
18:56<Afdal>It's 8 or 9 tiles
18:56<Afdal>I know because that's the maximum distance you can put your depot
18:56<@Yexo>but there is no perfect solution for that. Increasing the maximum search distance to depots can lead to trains going too far out of their way to go to a depot
18:56<Afdal>away from the main track
18:56<Afdal>any further than that and trains will never service period
18:56-!-supermop [] has quit [Remote host closed the connection]
18:56<+glx>prevents your trains to go to places from where they can't reach their normal schedule (on very bad layouts)
18:57<@Yexo>pf.yapf.maximum_go_to_depot_penalty = 20 * YAPF_TILE_LENGTH
18:57<+michi_cc>The default is 20 diagonal tracks, but e.g. curves and slopes also count towards that limit.
18:57<Afdal>Is the default is 20
18:57<Aali>does the depot itself count?
18:57<Afdal>Then why can't trains find depots any further out than 8?
19:01<Afdal>The real problem is
19:01<Afdal>If you want to play with realistic acceleration
19:01<Afdal>distancing your depots from the main track
19:01<Afdal>really helps prevent jams
19:01<Afdal>since they have to slow down at depots
19:02<Afdal>And when you distance them from the main track, you run into this problem more
19:02<Aali>Afdal: seriously, use service orders
19:02<Afdal>I don't know how to use servicing orders effectively
19:02<Afdal>How do you know when exactly it's the best time to service
19:02<Aali>service orders are skipped if the train doesn't need service
19:03<Afdal>Will it still service somewhere else if it needs to?
19:03<+michi_cc>It is impossible to have defaults that fit each and every playing style, but you are of course free to increase the mentioned setting for your games.
19:03<Aali>so just put it after the drop order (so it doesn't go to depot with cargo)
19:03<Aali>no it wont
19:03<Afdal>exactly, so how do you know
19:03<Afdal>when its best to place a service order
19:04<Aali>having a service order in the order list prevents the train from servicing on its own
19:04<Afdal>Normally I space my depots about a full maximum screen zoom apart
19:04<Afdal>That works pretty well
19:04<Afdal>Yeah, and then the train can go longer than it should without service, resulting in higher breakdown rates
19:05<Aali>you must have some long routes
19:05<Aali>could solve that with waypoints I guess
19:05<Afdal>How so?
19:05<Aali>its a bit fiddly though
19:05-!-KenjiE20 [] has quit [Ping timeout: 480 seconds]
19:05<Aali>station -> service -> waypoint -> service etc.. -> station
19:06<Afdal>then how is that any different
19:06<Afdal>than just letting them service on their own
19:06<Afdal>when you select so many depots manually
19:06<@Yexo>if you give your trains a service order the distance doesn't matter
19:06<+michi_cc>Service orders do not care about the tile limit.
19:07<+glx>an the train goes to service only where you want
19:07<Afdal>yeah and then when it passes that spot you wanted it to service, because it didn't need to at that time
19:07<Afdal>you can end up with lower reliability
19:08<Afdal>if you don't allow it to service at other depots too
19:08<@Yexo>the same happens already, I don't see your point?
19:08<Afdal>Exactly, I don't see the point of servicing orders
19:08<@Yexo>yes, hence the waypoints and allowing it to service at other depots
19:08<Afdal>Again, which is pretty much the same as just letting it service manually
19:08<Afdal>If you're going to select a bunch of other depots
19:08<@Yexo>except that letting them service automatically you have a limit of tiles the depot can be away from your mainline
19:08<Afdal>Oh I see what you mean
19:08<+glx>just use "go to nearest"
19:08<@Yexo>with service at depot orders you can circumvent that limit
19:09<+glx>no need to click on every depot
19:09<Afdal>Well, that could be awfully tedious with big tracks
19:09<Afdal>But I guess you only need to do it once
19:09<@Yexo>but trains don't need to service that often
19:09<Afdal>setting up the order list, I mean
19:09<@Yexo>I mean, you don't need a depot every 20 tiles
19:09<+glx>and use shared orders too :)
19:10<@Yexo>or just play without breakdowns and without servicing :p
19:10<Afdal>Do you really need waypoints?
19:10<Afdal>I don't see how that would help
19:10<Aali>default breakdowns are kind-of a big deal though :)
19:10<Afdal>oh u
19:10<Aali>never managed to go beyond ~100 trains with them
19:10<Afdal>I like the extra challenge servicing brings to the game
19:10<@Yexo>the "service" orders are evaluated at the time the train leaves the station
19:10<Aali>for me its unbearable
19:10<Afdal>Gotta figure out ways to make the best depots, like now :3
19:11<Afdal>Well the "normal" breakdown rate is horrendous, true
19:11<Aali>the improved breakdowns patch made it sane
19:11<Afdal>I don't find Reduced that big a deal though
19:11<Aali>well, a bit more sane anyway
19:11<Afdal>Are you guys ever planning on adding that patch to OpenTTD?
19:11<Afdal>as an advanced setting?
19:11<Afdal>I've never played with a patch before
19:12<Aali>it was pretty dead back when I used it.. which was like.. years ago
19:12<Aali>so no, I dont think that particular patch has any chance
19:12-!-DDR [~chatzilla@] has joined #openttd
19:13<Afdal>What was whoever saying about waypoints in addition to the goto depot order now?
19:13<Afdal>Why would you need waypoints?
19:13<Afdal>Yexo the "service" orders are evaluated at the time the train leaves the station
19:13<Afdal>Oh, does that apply to waypoints too
19:14<Afdal>But wait, what you end up doing with service orders then
19:14<Afdal>is spacing out the possible check
19:15<Afdal>so it's possible for it to be less efficient, even though the check will always occur
19:15<FLHerne>Can anyone suggest any compile options to cut CPU load ingame?
19:15<Afdal>I guess you could just put the waypoints directly before the depot splits
19:15<Afdal>that would work
19:15-!-Progman [] has quit [Remote host closed the connection]
19:16<FLHerne>This 133MHz processor is irritating, and the game lags a bit...
19:16<+glx>don't use ships
19:18<Afdal>only problem with this fix is you can't put waypoints on diagonal track
19:18<FLHerne>Is that a compile option? I thought there was a setting in the .cfg for that?
19:20<FLHerne>i.e. max ships = 0 or however it's phrased
19:21<+michi_cc>It is a setting for the person sitting in front of the keyboard.
19:21<FLHerne>I am sitting in front of the keyboard, so that's OK
19:22<+michi_cc>It means, just don't build any.
19:22-!-Snail_ [] has joined #openttd
19:23<FLHerne>I won't...
19:23<+michi_cc>I don't know what OS/hardware you use, but you could test whether the 8bpp-optimized or the 32bpp-optimized blitter is faster (32bpp-anim will very likly be the slowest).
19:24<FLHerne>8bpp is faster, I tried that on my last build
19:24<FLHerne>This time I'm building without networking or sound support, to try and get a couple more FPS
19:25<FLHerne>I was just wondering what else I could disable :-)
19:26<+michi_cc>Networking will likely have no effect, and there's no need to disable sound support, just pass '-s null' and '-m null' on the command line to get the 'do nothing' sound and music driver.
19:27<FLHerne>OK, thanks
19:29<FLHerne>I'll start, compiling then, hopefully it'll finish before I get up...took about 6 hrs last time...
19:30<Afdal>So does filling your track with path signals
19:31<Afdal>Eat up more CPU
19:31<Afdal>Because trains are constantly checking if they have to service?
19:31<Snail_>hi, I have a question probably for OTTD developers
19:31<Snail_>in the "railtypes" feature, when drawing tunnels, the tunnel head is always the original one
19:32<Snail_>this keeps compatibility with different landscapes, but limits the newGRF authors as to drawing different tunnel entrances across different types
19:33<Snail_>would it be possible to add an option to replace the original tunnel head with a custom sprite provided by the railtype newGRF? of course, this custom sprite would need to be compatible with the landscapes...
19:34-!-Adambean [] has quit [Quit: Gone fishing]
19:34<Afdal>Actually... If a path signal always ensures a depot check anyway, how is putting maintenance in orders along with waypoints any different?
19:35<+michi_cc>Snail_: Just Action A the original tunnel sprite. It is not possible for a NewGRF to query the base set in use though.
19:36<Snail_>michi_cc: you mean it's not possible for a newGRF to figure out which landscape the game is in?
19:37<JVassie_>bonjour Snail :D
19:38<+michi_cc>You can query for temperate/arctic/tropical etc, but not for the base set. If you could, you'd have an instant desync if both players with the original base set and players with OpenGFX join the same multiplayer game.
19:38<Snail_>salut jvassie ;)
19:39<Snail_>I see... so if I decided to "action A" the original tunnel sprite with a different one based on the base set, someone playing with OpenGFX would see that sprite being different from the rest of the landscape?
19:40<+michi_cc>Yes. And GRF parameters work for single player, but still fail for multiplayer.
19:40<+michi_cc>All that is the reason why you can't provide a custom tunnel sprite in the railtype definition.
19:41<Afdal>If a path signal always ensures a depot check anyway, how is putting maintenance in orders along with waypoints any different? Doesn't seem to make any difference, just tested it on an old save game.
19:42<+michi_cc>Maintenance orders will always find the depot, regardless of the length of the track leading to thedepot.
19:42<Afdal>I see
19:42<Afdal>So maybe that would be better if you were using 8 tile+ length trains
19:43<Afdal>But if you're not it really makes no difference
19:44<Afdal>err not "maybe", it would be
19:44<Afdal>So does filling your track with path signals over block signals eat up more CPU because trains are constantly performing depot checks??
19:45<Snail_>michi_cc: so I can't provide a custom tunnel sprite in the railtype definition, but I can still change it through action A, right? so what's the difference?
19:45<+michi_cc>You get *one* custom sprite, not one per railtype.
19:46<Snail_>ohh, I see
19:46<Snail_>all the railtypes will have the same then
19:47<+michi_cc>But even with Action A, as soon as your sprite contains even a bit of grass it will always be a mismatch for about half the players (depending on which base set's grass you take).
19:48<Snail_>how about making tunnel entrances as sprites that only contain the entrance and no landscape? a little bit like the track sprites, which contain only the tracks and the ballast underneath, but no landscape...
19:49<+michi_cc>The only sane way IMHO is to introduce a parameter for the tunnel sprite that by default (for multiplayer compatibility) is set to "use base set tunnel sprite".
19:49-!-FLHerne [] has quit [Quit: Leaving]
19:50<+michi_cc>The grass would overlap with the tracks and the train because you'd need to know where to cut a "hole" into the sprite.
19:51<Snail_>but the hole could remain the default one in terms of size... so OTTD would still know where to cut
19:52<Snail_>re. the parameter, yes I agree, but still it would be awkward to draw a custom tunnel head that would suit both XIXth century NG rails and modern TGV tracks
19:55-!-JVassie_ [~James@] has quit [Ping timeout: 480 seconds]
19:55-!-JVassie_ [~James@] has joined #openttd
19:56<+michi_cc>Someone™ would need to draw all needed sprites for the original base set.
19:57<+michi_cc>(I.e. all landscape types in all orientations.)
19:58<Snail_>you mean if one wanted to create custom tunnel heads?
19:58<Snail_>as a matter of fact I already drew some, for my NG tracks
20:00<Afdal>Does filling your track with path signals over block signals eat up more CPU because trains are constantly performing depot checks?
20:04-!-valhallasw [] has quit [Ping timeout: 480 seconds]
20:05<+michi_cc>Snail_: I mean grass sprites with a fitting hole.
20:05<Afdal>Last question I swear :3
20:06<+michi_cc>Afdal: The depot check is only expensive if it decides to search for a depot. As long as the train does not need servicing, it will be very quick.
20:06<Afdal>ah, but it will use more CPU then won't it
20:06<Afdal>just less if you have your depots spaced properly
20:06<Afdal>err, less the less space you have between them
20:08<Snail_>but the grass could be that of the default sprite, on which the new head would be the overlay...
20:08<@planetmaker>that's difficult.
20:08<@planetmaker>tunnel heads most likely have different slopes than the tile slopes
20:08<Snail_>just like in the normal tracks... the grass would be around the tunnel head, but the tunnel head itself would be replaced
20:08<@planetmaker>just look at the ttd tunnels - they have grass on top
20:09<@planetmaker>thus it looks awkward then, too
20:09<+michi_cc>I doubt you can even measure the extra check for the no service case. And do remember that only a very limited amount of tiles is searched for a depot, so a depot search is still cheap in comparison to a full pathfind at a junction tile.
20:09<Snail_>yes, perhaps we could restrict such an overlay to approximately follow the original head. I could live with that
20:10<+michi_cc>Snail_: It would need grass tiles with a proper transparent area, otherwise the grass would overlap the vehicles.
20:10<Afdal>Yeah but if a train needs to service
20:10-!-pugi [] has quit [Ping timeout: 480 seconds]
20:10<Afdal>It's going to check every 2 tiles for a depot when path signals
20:11<Afdal>and with a lot of trains and a lot of track, that could add up
20:12<@planetmaker>thus it would need terrain sprites for all 4 slopes, one for each of the track sides. Thus two per each of the slopes and terrain type. For both base sets
20:12<+michi_cc>So more or less a tile that is all grass and has the same shape and outline as the default tunnel portal. If a set wants to provide a tunnel portal wider on the inside, it would have to hide the extra grass with some kind of darkness.
20:12<@planetmaker>then it *might* work
20:12<Snail_>planetmaker: that would be great
20:12<@planetmaker>well. Go ahead and create those sprites
20:13<@planetmaker>would be a first step ;-)
20:13<@planetmaker>Please do for both basesets
20:13<+michi_cc>Or maybe where the portal hole is a bit bigger, under the assumption that no one would like to draw a tunnel portal just a pixel "thick".
20:13-!-pugi [] has joined #openttd
20:13<@planetmaker>still, the problem is where to place the hole
20:14<Snail_>ok :)
20:14<@planetmaker>now the entry portal can be anywhere on the tile
20:14<Snail_>I already have a set of custom tunnelheads
20:14-!-Elukka [] has quit []
20:14<Snail_>you want me to PM it to you?
20:14<@planetmaker>Snail_: not custom tunnel heads
20:14<@planetmaker>the grass sprites
20:14<@planetmaker>for the sides
20:14<@planetmaker>where stuff can be overlayed onto
20:15<Snail_>oh, oko
20:15<@planetmaker>I wonder though... how much it needs on the top side of the slopes...
20:15<@planetmaker>or whether at all
20:15<+michi_cc>planetmaker: Totally arbitrary tunnel portals wouldn't work, graphics artists would just have to draw sprites that fit onto the default hole (which would roughly the shape and size of the default hole).
20:16<@planetmaker>hm.... I'd make that bigger by quite a bit
20:16-!-dfox [] has quit [Remote host closed the connection]
20:17<+michi_cc>Some, but a bigger hole means the portal itself has to be more massive as well.
20:18<@planetmaker>hm... would it work to always draw the default background, then a custom background on top, then the train, the default top and then a custom top?
20:18<@planetmaker>that'd not allow bigger portals, though
20:18<@planetmaker>thus it needs a bigger portal
20:18<+michi_cc>Oh, and the tunnel sprite actually consists of two parts, one drawn behind and one drawn over the vehicle sprite (Base set sprites 2365 and following).
20:19<@planetmaker>yes, of course
20:19<@planetmaker>a back where the track and the train is drawn onto. And then overpainted by the front
20:20<@planetmaker>where the front must include the top
20:20<+michi_cc>planetmaker: The default tunnel sprites have shading that suggests the roundness of the tunnel tube, so that wouldn't really work as a base sprite.
20:21-!-Zuu [] has quit [Quit: Leaving]
20:21<@planetmaker>I know. And they even have no grass. Depending on track type
20:23<+michi_cc>Anyway, that results in 48 sprites per base set to be drawn. Get to work, someone™ :)
20:23-!-dfox [] has joined #openttd
20:23<@planetmaker>Thus what it needs is like the untouched part of the tunnel sprites
20:23<@planetmaker>And the player needs to supply the additional back part and the additional front / top part
20:24<@planetmaker>@calc 2 * 4 * (4+2)
20:24<@DorpsGek>planetmaker: 48
20:24<@planetmaker>yup :-)
20:24<@planetmaker>but I see no other way to implement it otherwise
20:24<@planetmaker>and it's not like it's not feasible. But someone [TM]
20:24<Snail_>sorry was afk
20:26<Snail_>planetmaker: I'm willing to give it a try if you need "someone" to draw ;)
20:26<Snail_>I can use the sprites I already drew as base
20:26<Snail_>do I need to break them in a certain way? or can I just send you the final result and you can try and break it up?
20:27<@planetmaker>Snail_: mind, it needs those sprite parts which are NOT the tunnel of the tunnel tile
20:27<@planetmaker>and yes, I'll need the two parts separately. I don't need finished tunnels
20:27<@planetmaker>as that breaking up is IMHO the hard part. After all I don't want new tunnels. But the default tunnels properly split up into parts that the actual portal can be replaced by a custom one
20:28<@planetmaker>i.e.: no custom portals. But the existing tunnels broken into "back grass", "portal" and "front + top grass"
20:28<@planetmaker>hm... no, "front grass"
20:28<@planetmaker>portal was extra and includes top grass
20:30<Snail_>oh I see
20:30<@planetmaker>let me best make a dirty example...
20:30<Snail_>you only need the default parts, so that a custom portal can later replace the default one
20:31<Afdal>You guys know your wiki is kinda messed up right now, right?
20:31<Afdal>It hasn't been displaying pages properly the last several days
20:31<@planetmaker>yes. For this to work we first need to change the default to a way that it can be modified
20:31<@planetmaker>Afdal: works for me.
20:31<@planetmaker>so: no, I don't know nor experience troubles
20:32<Afdal>Well I'm not blocking any ads or scripts
20:32<Afdal>And openttd's wiki is the only wiki I go to that's not displaying correctly
20:32<@planetmaker>there are no ads except a link to our sponsor
20:33<Snail_>planetmaker: ok. Will it work if I take a screenshot from a game and then split up the tunnel from there?
20:33<Afdal>oh wait a second
20:33<+michi_cc>I guess you ned something like
20:33<Afdal>disabling Adblock fixed it
20:33<Afdal>I wonder what I'm blocking
20:33<Afdal>No wait, it fixed itself just now
20:33<Afdal>without my doing anything
20:33<+michi_cc>Snail_: Decode trg1r.grf and look at sprites 2365+.
20:33<Afdal>Weird, I wonder what the problem was
20:35<@planetmaker>^^ quicker ;-)
20:35<Snail_>thanks ;)
20:35<+michi_cc>And also the appropriate plain slope sprites, but they are distributed over all base GRFs.
20:36<Eddi|zuHause>has the railtype yet an option to choose whether to use the rail/monorail/maglev tunnel?
20:36<Snail_>those sprites are split already, but we'll need to split them even further, right? the tunnel head needs to be separated from the grass above the tunnel?
20:37<@planetmaker>I'd say 'yes'
20:38<@planetmaker>I'd split it into three parts... then the actual normally sloped grass part can be made a bit bigger to allow for more custom tunnel portals
20:38<Eddi|zuHause>it needs 4 parts
20:38<Eddi|zuHause>ground-front, ground-back, entrance-front, entrance-back
20:40<@planetmaker>ground and back are the same
20:40<Eddi|zuHause>"ground" meaning the grass, and "entrance" meaning the wall/roof
20:40<+michi_cc>The base set would only need the grass though, if no custom tunnel sprites are defined for a railtype the code would just fallback to drawing the default tunnels like now.
20:41<+michi_cc>The railtype NewGRF would then supply only the back and front sprites with the portal itself. And it does *not* need an extra back part, because that can be attached to the tunnel track sprite that is already used.
20:41<Eddi|zuHause>i believe the 32bpp-ez tunnel entrance is cut wrong...
20:42<+michi_cc>So a NewGRF would supply one back sprite with rails + back part of tunnel portal and a new sprite with the front portal overlay.
20:42<Snail_>so, the sprites where the tunnel head is facing the viewer need to be in three parts: track underlay, portal overlay, grass overlay?
20:44<+michi_cc>The base set needs sprites like the two I linked (just tweaked a bit better to allow as many different portal outlines as possible), just in all four directions for all 6 different grass types.
20:44<Snail_>any link to the other grass types?
20:45<+michi_cc>Basically I don't know if a bigger or a smaller cutout is better, simply because I don't draw tunnel portals :)
20:46<Snail_>hehe, the only ones I drew so far have a smaller cutout, but a bigger portal itself (NG has smaller loading gauge)
20:46<+michi_cc>For the original TTD sprites you need to decode all trg*.grf and search the slopes in there, for OpenGFX there is probably also some nice page with them.
20:46<@planetmaker>I do believe something like is needed
20:47<@planetmaker>there's a gimp file with all terrain sprites for OpenGFX
20:47<+michi_cc>And just a note on my examples: The sprites are very crude combinations of the tunnel sprites with the portal erased and the slope grass to fill them up.
20:47-!-sllide [] has joined #openttd
20:48<@planetmaker>but same as michi, I'm not sure on the exact way a good cut would need to be
20:48<+michi_cc>planetmaker: One thing they do need to show is some shading to indicate the tunnel "bulb", because if you really just use the slope it would look weired.
20:48<+michi_cc>Oh, and the cutout needs the identical between TTD and OpenGFX of course :)
20:49<@planetmaker>probably that's best...
20:49<@planetmaker>doesn't make it easier, though
20:49<Snail_>I guess that if one supports custom portals, the grass over the tunnel would be drawn *before* the custom portal itself, right?
20:50<Snail_>so that if one supplied a larger portal (like the massive ones in the XIX century) with lots of masonry around the cutout, it would be drawn over the grass
20:50<+michi_cc>Yeah, drawing order would be back grass, then tracks with back portal, front grass, front portal overlay.
20:50<@planetmaker>michi_cc: but showing the "bulb" implies already a terrain-covered thing... though... maybe not, as it can be overdrawn. So you might be right that it's a good thing to have
20:50<Snail_>michi_cc: sounds great
20:51<+michi_cc>planetmaker: The point is that you can overdraw/hide the bulb, but you couldn't add it in the portal overlay to match the grass.
20:51<@planetmaker>quite right
20:52<+michi_cc>So the shading needs to be just so to not look off. Quite a challenge to draw.
20:53<Snail_>what do you mean by tunnel bulb? the part of the slope that is actually horizontal coz there's the tunnel underneath?
20:53<Snail_>like, the semicircle emerging from the slope?
20:54<+michi_cc>The right sprite in my example has a lighter area at the top which indicates that the area in the middle isn't sloping like left and right.
20:56<Snail_>you mean the "bulb" has to be separated? why can't it be drawn in the same sprite as the slope?
20:57<+michi_cc>I mean it has to be present so you can't just take the plain sloped grass.
20:58<Snail_>anyway I did a quick example for one orientation only. Can I show you guys so that I see if I'm on the right track?
21:03<+michi_cc>Snail_: You are allowed to, but you have to decide for yourself if you can :p
21:03<@planetmaker>well... ^^ ;-)
21:04<Eddi|zuHause>typical german answer :p
21:04<Snail_>I meant across irc (I'm not an expert of this)
21:04<Snail_>perhaps I should PM?
21:04<@planetmaker>just post a link to what you mean ... ?
21:04<@planetmaker>to that image
21:04<@planetmaker>I mean... we did, why wouldn't you be allowed to?
21:05<Snail_>ok, well I have no space to upload it to
21:05<Snail_>I'll just PM it to you guys
21:05-!-Afdal [] has quit [Remote host closed the connection]
21:05<@planetmaker>just use imagebin as I used
21:08<Snail_>thanks for the tip about imagebin :)
21:09<@planetmaker>well. that back part of the grass is not large enough imho
21:09<@planetmaker>it should not contain the cut-out of the "bulb", I guess...
21:09-!-JVassie_ [~James@] has quit [Ping timeout: 480 seconds]
21:10<@planetmaker>you might not need create the portals itself. That'd only be needed for an actual railtype NewGRF
21:11<@planetmaker>And the ground/back (with tracks)...not sure the walls are needed. Just the ground
21:11<@planetmaker>if at all
21:11<Snail_>but perhaps new walls might be supplied by the newGRF
21:12<+michi_cc>Snail_: The back grass part should also have grass in the area where the tracks are to allow tracks that are smaller than default.
21:12<Snail_>for instance, a portal made of bricks would have reddish walls, while one made of stone would have greyish walls
21:12<@planetmaker>yes. But this task is not a newgrf task, but what the base set must supply
21:12<@planetmaker>i.e. those parts which the newgrf must not / need not include
21:12<Snail_>michi_cc: got it, you have a point
21:13<Eddi|zuHause>planetmaker: btw, do you have anything to say on the report i linked earlier where people have problems with the opengfx signals?
21:13<Snail_>planetmaker: ok... well, ideally a newGRF should either provide its own walls, or no walls at all, and then the custom walls would be used
21:13<@planetmaker>I'm not aware of any signal issue and OpenGFX has signals of both types, Eddi|zuHause
21:13<+michi_cc>And I guess the cut-out of the left-most sprite should be a bit bigger as otherwise it would be impossible to have portals that are "bigger" than default on the inside.
21:14<@planetmaker>though I never play with British, thus it's long ago I checked
21:14<Eddi|zuHause>planetmaker: as far as i read out of it, opengfx shows british semaphore signals regardless of the traffic-side setting
21:15<+michi_cc>Snail_: A NewGRF would provide either no tunnel sprites at all, in which case the current (uncut) tunnel sprites are shown, or it would provide the two portal sprites (i.e. second-left and right sprite in your example).
21:15<@planetmaker>I don't play with semaphore either. So... don't know currently either
21:15<@planetmaker>but I shall check. But not before sleep
21:15<@planetmaker>but what's a "british" semaphore and what a German, Eddi|zuHause?
21:16<Snail_>michi_cc: ahh I understand. So those "cut" sprites (1st and 3rd column in my drawing) would *only* be used if a newGRF provided custom portals
21:16<Eddi|zuHause>planetmaker: british semaphores point to the left if red, and downwards if green, german semaphores point to the right if red and upwards if green
21:16<@planetmaker>Snail_: and those sprites would have to be supplied by that very newgrf
21:16<Snail_>therefore walls would not be needed, because the newGRF would need to provide them. Same for the portals themselves. So all I need to draw are my 1st and 3rd columns, perhaps with a larger bulb to allow for larger tunnel heads?
21:17<Eddi|zuHause>planetmaker: which is problematic alone for the fact that they're pointing into the track if they are drawn on the right side
21:17<+michi_cc>Which is why the cut-out needs to have a good shape (I don't know if good here means large or small, you'd probably have to test that with your french portals) to allow the most flexibility for NewGRFs.
21:18<@planetmaker>Eddi|zuHause: at least there are sprites of both types
21:18<Snail_>mich_cc: yes. Well, we would need a "one size fits all", both for NG and SG. I'm not gonna draw two bulb sizes :D
21:18<@planetmaker>in sprites/png/infrastructure/semaphores.png
21:18<Eddi|zuHause>planetmaker: i don't have opengfx
21:19<Snail_>perhaps I'll just enlarge this a little bit. Would look a little bit weird for NG. But considering the vast majority of sets out there uses SG, the latter needs priority
21:19<+michi_cc>Snail_: Yes. And that is the difficult part of the job :)
21:19<@planetmaker>Eddi|zuHause: whatever you use, it's an easy thing to check as you can switch base sets easily
21:19-!-pugi [] has quit []
21:19<@planetmaker>if you know what to look for
21:19<Snail_>the grass in the underlay is not a joke too, cz it needs to be shaded (a little bit darker)
21:20<+michi_cc>A bigger cut-out doesn't necessarily mean a big tunnel inside though, just that the portal would have more walls/decoration to cover the space.
21:20<Eddi|zuHause>planetmaker: and the bandwith to get it and keep it up to date?
21:20<@planetmaker>oh. my. god
21:20<@planetmaker>all those wasted bits. I'm really sorry
21:20<Snail_>michi_cc: yes it's true. I'll do some tests
21:20<Eddi|zuHause>i'm also really sorry that i'm living in the most underpriviliged village around
21:21<Eddi|zuHause>but seriously, my whole garden hose bandwidth is already used for the whole day now
21:21<@planetmaker>last time I heart you talk about bandwidths it was in terms of movies / hour ;-)
21:22<Eddi|zuHause>the last time i spoke about bandwidth was that it doesn't suffice for viewing a low-res livestream like the openttd-yogscast
21:23<Snail_>time ago I made this
21:23<@planetmaker>which still is a lot compared to 3MB for opengfx
21:23<Eddi|zuHause>which is 3MB of something else i won't get instead
21:23<Snail_>I think this encompasses all the climates for OpenGFX. It shows the final result of how my NG tunnels should look like. Are those all the openGFX climates I need?
21:24<Snail_>oh :p
21:25<@planetmaker>a base set is a base set and all need to supply exactly the same sprites
21:25<Eddi|zuHause>the sprites look like the wall is standing in the middle of nowhere
21:26<@planetmaker>anyway, I'm off to bed. Have a good night, folks
21:26<Snail_>good night
21:27<Snail_>Eddi|zuHause: yep because I didn't edit it much
21:28<Snail_>and that would be the inconveniences of a "one size fits all" base I guess... it needs to accommodate both old-style tunnel heads like the one I drew (which includes a big wall) as well as more modern heads without a wall around the opening
21:29<@planetmaker>you start to understand why it wasn't (yet) done ;-)
21:30-!-sllide [] has quit [Quit: Ex-Chat]
21:30<Snail_>anyway I think I found the toyland sprites, I've got a file with all the openGFX infrastructure
21:31<Snail_>I'll just need to decode the original sprites and give it a try... I still think it's gonna be better than nothing
21:31-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
21:34-!-Biolunar_ [] has joined #openttd
21:41-!-Biolunar [] has quit [Ping timeout: 480 seconds]
22:00<Snail_>hmm, I just decoded trg1r.grf, I could find the sprites for the normal and snow-covered tunnels, but not the others (desert and toyland)
22:00<Snail_>perhaps they're in another *.GRF file?
22:13<Snail_>nevermind I found them
22:20-!-adamkex [] has joined #openttd
22:35-!-Brianetta [] has quit [Quit: Tschüß]
22:44<Eddi|zuHause>yes, the climates are in the other grfs
22:46-!-Biolunar_ [] has quit [Quit: All your IRC are belong to us!]
22:48<adamkex>Can somebody help me explain how a a feeder service with busses and trains work? x1 is a trainstation outside of city x. x2 is a busstation inside city x. y1 is a trainstation outside of city y. y2 is a bustation inside city y. What I want is that passengers travel by bus from x2 to x1, then by train from x1 to y1, and then by bus from y1 to y2. i seem to have set this up but my trains seem to be loading the same passengers as it unloade
22:52<Eddi|zuHause>transfer only works one-way
22:52<Eddi|zuHause>pr you need really complex systems with more than one station
22:53<Eddi|zuHause>one station only handling incoming passengers, the other one only handling outgoing passengers
22:55<adamkex>so my best bet is just to place trainstations very close to the city?
22:55<Eddi|zuHause>yes, at least close enough so the trains can unload without transfer
22:56<Eddi|zuHause>and use the trams to haul passengers to the stations with transfer and leave empty, so more pople use the long distance trains
22:59-!-glx [glx@2a01:e35:2f59:c7c0:34e7:b910:a468:8ee9] has quit [Quit: bye]
23:02<adamkex>Eddi|zuHause: but how would the arriving passengers enter the city if all busses are set so they leave the train station empty?
23:21-!-pjpe [] has joined #openttd
23:29-!-mahmoud [] has quit [Ping timeout: 480 seconds]
23:55-!-fjb|tab is now known as Guest22163
23:55-!-Guest22163 [] has quit [Read error: Connection reset by peer]
23:55-!-fjb|tab [] has joined #openttd
---Logclosed Fri Dec 30 00:00:32 2011