Back to Home / #openttd / 2011 / 05 / Prev Day | Next Day
#openttd IRC Logs for 2011-05-01

---Logopened Sun May 01 00:00:55 2011
00:28-!-gartral [] has joined #openttd
00:28<gartral>is the svn/hg server down or something? or is it just REALLY slow
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
00:58-!-sla_ro|master [slaco@] has joined #openttd
01:06-!-bryjen [~bryjen@] has quit [Remote host closed the connection]
01:27-!-gartral [] has quit [Ping timeout: 480 seconds]
01:28-!-roboboy [] has joined #openttd
01:57-!-seanbotv20 [] has joined #openttd
02:11<seanbotv20>Are there any pros out there
02:11<seanbotv20>I can't seem to turn a profit
02:22-!-KouDy [] has joined #openttd
02:35-!-Absurd-Mind [] has joined #openttd
02:39-!-Alberth [] has joined #openttd
02:39-!-mode/#openttd [+o Alberth] by ChanServ
02:41-!-JVassie [~James@] has joined #openttd
03:07-!-Neon [] has joined #openttd
03:10-!-fonsinchen [] has joined #openttd
03:11-!-|Jeroen| [] has joined #openttd
03:12-!-Chrill [] has joined #openttd
03:18-!-seanbotv20 [] has quit [Quit: Leaving]
03:51<@planetmaker>hm, is there a way to place an object on steep slopes?
04:00-!-Absurd-Mind [] has quit [Ping timeout: 480 seconds]
04:05-!-LordAro [] has joined #openttd
04:17-!-LordAro [] has quit [Ping timeout: 480 seconds]
04:17<Rubidium>planetmaker: prop10 |= 20h + prop15 |= 01h?
04:20<@planetmaker>I use both, the flag and callback
04:21<@planetmaker>i.e. both bits you suggest are set. But I still get 'slope not suitable'
04:21<@planetmaker>and the CB never fails
04:22<Rubidium>I see no checks for slope when callbacks succeed
04:23<Rubidium>have you tried tracing it in OpenTTD?
04:24<@planetmaker>not yet.
04:24<@planetmaker>I shall dig further.
04:25<Rubidium>I at least didn't implement (or did but took out later) anything to limit steep slopes
04:27-!-|Jeroen| [] has quit [Quit: oO]
04:27<@planetmaker>hm... maybe I've forgotten one slope. I need to check :-)
04:28<@planetmaker>hm, yes. Thanks for putting me on the right track
04:29-!-Pulec [] has joined #openttd
04:32-!-Zuu [] has joined #openttd
04:32-!-Chrill [] has quit []
04:46-!-Kurimus [] has joined #openttd
04:56-!-Cybertinus [] has joined #openttd
05:05-!-douknoukem [] has joined #openttd
05:09-!-DOUK [] has quit [Ping timeout: 480 seconds]
05:09<@Terkhen>good morning
05:12-!-frosch123 [] has joined #openttd
05:20<Zuu>good morning Terkhen
05:24<CIA-1>OpenTTD: rubidium * r22396 /trunk/src/ai/ (18 files in 2 dirs): -Document: some AI doxygen stuff
05:31<@planetmaker>moin Zuu & Terkhen
05:43-!-DDR [] has quit [Ping timeout: 480 seconds]
05:46-!-Progman [] has joined #openttd
05:55<@planetmaker>is ok to define child sprites for ground tiles (for NewObjects)?
05:55-!-DayDreamer [~DayDreame@] has joined #openttd
05:56<@planetmaker>I get some funky glitches:
05:58-!-DayDreamer [~DayDreame@] has left #openttd []
06:02-!-Progman [] has quit [Remote host closed the connection]
06:03-!-Progman [] has joined #openttd
06:15<CIA-1>OpenTTD: rubidium * r22397 /trunk/src/ (20 files in 2 dirs): -Document: some tidbits of the blitter code
06:21-!-yorick [] has joined #openttd
06:26-!-Chillosophy [] has joined #openttd
06:30<@planetmaker>I still don't quite follow why I get that glitch. Test GRF: NML-source: and NFO:
06:30<@planetmaker>the specs tell me that a child sprite gets the same bounding box as the parent sprite - which in case of a ground tile should cover the whole ground tile
06:30<@planetmaker>But it seems only to cover the extend of a plain ground tile without slope
06:31<@planetmaker>On the other hand: specs also tell that I may not set the x and y extend for ground sprites
06:32<@planetmaker>nor for child sprites
06:36-!-tycoondemon [] has quit [Ping timeout: 480 seconds]
06:40<@Alberth>planetmaker: "..For example increasing the production of the power at the power station?" <-- I would have answered 'yes, the citizens of openttd are very happy with the extra power'. :D
06:40<@planetmaker>err_no_context ;-)
06:41<@planetmaker>ah :-)
06:41<@Alberth>oh, I should have pasted a bit more. sorry
06:42-!-tycoondemon [] has joined #openttd
06:43<@planetmaker>two, three days ago I wrote that, how should I remember when I have even trouble to recall what I wrote yesterday? :-P
06:43*planetmaker hugs Alberth
06:49-!-dfox [] has joined #openttd
06:50-!-KenjiE20 [~KenjiE20@] has joined #openttd
06:53<fonsinchen>distyacd works nice.
06:55<fonsinchen>only the destination lists in the town an industry GUIs need some care so that they don't overflow ...
06:55<fonsinchen>but that should be a problem with plain YACD, too.
07:02<CIA-1>OpenTTD: rubidium * r22398 /trunk/src/network/ (4 files in 2 dirs): -Codechange: remove some defines from the tcp/admin code, so doxygen can create better documentation
07:04-!-KritiK [] has joined #openttd
07:05-!-Chris_Booth [] has joined #openttd
07:09<+michi_cc>fonsinchen: Yes, some scrollbar and/or collapsible entries are definitely required for compatibility with smaller screens.
07:09<fonsinchen>Or with excessively long lists of destinations ;)
07:10<fonsinchen>You might want to have a look at my repository. Especially the refactoring of link weight modifiers would look good in yacd, too.
07:12*Zuu thinks about a generic filter for lists in OpenTTD. Or perhaps something SQL-ish. :-)
07:13<Zuu>To start, each object type (eg. vehicles, towns, industries etc) would need a list of properties that can be filtered.
07:13<CIA-1>OpenTTD: rubidium * r22399 /trunk/src/network/ (4 files in 2 dirs): -Codechange: replace some defines in the tcp/content code so doxygen can create better documentation
07:13<Zuu>Operations like SUM(col_name) etc. would also be useful :-)
07:14-!-Wolf01 [] has joined #openttd
07:14<Zuu>But a simple SQL implementation might be to advanced for the average OpenTTD player?
07:14*Alberth proposes to replace OpenTTD with a spreadsheet with numbers
07:15*Zuu likes
07:15<Rubidium>Alberth: OpenTTD's output can easily be put into a spreadsheet
07:16<@Alberth>indeed, and the iterative simulation can be done too, no need to display any graphics
07:16<Zuu>In my last game I had problem keeping track of all different routes (shared orders groups) that served each station.
07:16<Rubidium>just make the cells as small as possible while still visible (preferably square), and then color the cells appropriately. Maybe you need to zoom out for the required effect.
07:17<@Alberth>hello Wolf01
07:18<@Alberth>Rubidium: good exercise for the office, make a row of 1's that travel in a circle in your spread sheet
07:18<Zuu>With a lot of vehicles serving a station, it is non-trivial to figure out which stations/vehicle routes that service that station.
07:19<+michi_cc>fonsinchen: Indeed, most of it makes sense. I'm going to include that into the matching commits if you don't mind. And probably some of your minimap graph stuff as well (or maybe from the old cargodest, have to see what is easier to reuse).
07:19<fonsinchen>I don't mind at all. Go ahead
07:20<fonsinchen>Also you might want to look at the "capacities" branch. That's where I do my version of prefilling orders/routes.
07:20<fonsinchen>I think there are some corner cases you haven't covered yet.
07:21-!-romazoon [] has joined #openttd
07:21<fonsinchen>and eventually people will ask for something like my ext-rating. But maybe that shouldn't be part of yacd.
07:23-!-ndh [] has joined #openttd
07:25<+michi_cc>Yeah, I could handle deterministic conditional orders, even if the route links will still be created when the vehicle actually travels.
07:26<ndh>hello, is there a specific channel for developers? i'm trying to port the old Train Counter patch to 1.1.0
07:26<@Yexo>feel free to ask any questions you have in this channel
07:27<fonsinchen>Another thing people were complaining about in cargodist was that links timed out while a vehicle was still full loading.
07:28<fonsinchen>I solved that with the "Refresh" thing where I periodically reset the timeout while vehicles are loading.
07:28<fonsinchen>That would translate to setting the timeout to some "max_timeout - X" for yacd.
07:28<fonsinchen>But maybe you should wait until the problem arises ...
07:30<CIA-1>OpenTTD: rubidium * r22400 /trunk/src/network/ (6 files in 2 dirs): -Codechange: replace some defines in the tcp/game code so doxygen can create better documentation
07:30<ndh>in rail_cmds.cpp there's a vehicle_enter_tile_proc callback, VehicleEnter_Track. i'm trying to set increment the counter of the waypoint when a train enters there, but IsRailWaypointTile(tile) apparently never returns true. here's the code
07:30-!-pugi [] has joined #openttd
07:30<Rubidium>waypoints aren't rail tiles anymore
07:31<ndh>i don't know what that means... how do i find out if a tile is a waypoint?
07:32<ndh>i tried IsRailWaypoint(), but the assertion in GetStationType() failed
07:33<@Alberth>there are different tile types, depending on that type a different callback is called. Perhaps look at what tile type is used when building a waypoint?
07:33<@Terkhen>check the preconditions of IsRailWaypoint()
07:33<@Yexo>waypoints use MP_STATION, not MP_RAIL
07:33<@Alberth>better :)
07:34<@Yexo>IsRailWaypoint has as precondition that the tile is of the type MP_STATION, IsRailWaypointTile has that check included in the function
07:34-!-Adambean [] has joined #openttd
07:34<ndh>oh ok, do you mean that the vehicle_enter_tile_proc isnt even called for waypoints, since the type is station?
07:35<@Yexo>indeed, it's only called for tiles with tile type MP_RAIL
07:35<Rubidium>at least not the one in rail_cmd.cpp
07:35<ndh>alright, thanks
07:35<@Yexo>VehicleEnter_Station in station_cmd.cpp is the correct function
07:36<ndh>cool, thanks
07:36-!-glx [glx@2a01:e35:2f59:c7c0:f1f7:c0f6:f53c:c79e] has joined #openttd
07:36-!-mode/#openttd [+v glx] by ChanServ
07:39<ndh>yay it works :) thanks guys
07:41-!-DOUK [] has joined #openttd
07:42-!-Mazur [] has quit [Remote host closed the connection]
07:45-!-ZirconiumX [] has joined #openttd
07:45-!-douknoukem [] has quit [Ping timeout: 480 seconds]
07:49<ndh>btw, vehicle_enter_tile_proc isn't called only once when a vehicle enters a tile, is it?
07:54<@Yexo>IIRC you're right, it's called multiple times per tile
07:54<@Yexo>but I'm not really sure, didn't check just now
07:56-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
07:57<ZirconiumX>What is the maximum number of towns a map can have?
07:58<Zuu>Try to write a huge number in custom town amount :-)
07:59-!-romazoon [] has quit [Ping timeout: 480 seconds]
07:59<@Yexo>ZirconiumX: limited by the minimum distance between towns and the map size
08:00<@Yexo>the actual limit in the code is 64000 towns, but you won't be able to reach that on a 2048x2048 map
08:02-!-frosch123 [] has quit [Ping timeout: 480 seconds]
08:04<ZirconiumX>Is there an <easy> way to optimise the A* pathfinder
08:04<ZirconiumX>I think WmDOT did it with a Fibbonacci heap
08:05<@planetmaker>:-) A* is already an optimized PF. The question is by which criteria you want a PF optimized
08:05<@Yexo>do you want a perfect path or does that not matter so much?
08:05<Zuu>You can reduce how much it will search for different paths.
08:05<@planetmaker>then use 'drive straight unless not possible'
08:06<ZirconiumX>Yexo: as long as it connects the towns - I don't care
08:06<@planetmaker>but it might not find the destination then ;-)
08:06<@Alberth>ZirconiumX: didn't you have a fast D* ?
08:06<Zuu>Original Clueless had a pathfinder that drove stright until it hit an obstacle, turned 90 degrees and continued. :-)
08:06<ZirconiumX>I haven't finished it yet - you could barely say I've started it
08:07<ZirconiumX>I've heard you can play around with the _Cost function of the RoadPF
08:08<Zuu>I've experimented slightly with a pathfinder that would use a straight line between the origin and destination and identify obstacles that this line hit and generate a path around these obstacles. This can be found in wayfinder.nut in CluelessPlus, but I've not reall come very far with it.
08:08-!-frosch123 [] has joined #openttd
08:08<@Alberth>yes, by overestimating costs, it explores less alternatives but paths may be less optimal
08:09<@Yexo>ZirconiumX: simplifying the Cost function might give some speedup, also making Estimate return a higher value that necessary
08:09<Zuu>Its a good idea to play around both with _Cost and the function that creates neighbours. For example to find paths that use a bridge to cross railway, canals etc.
08:10-!-Intexon [] has joined #openttd
08:10<Zuu>Though, these kind of things will make the pf slightly slower per iteration - though in some cases it might find a path in less iterations.
08:11<ZirconiumX>Yexo & Zuu: local cost = RoadPathFinder._Cost x 1.1 <---- Will that help?
08:11-!-Cybertinus [] has quit [Remote host closed the connection]
08:11<Zuu>(bridging canals that is - bridging rail is not faster as in terms of building, just makes your trucks survive better ;-) )
08:13<Zuu>ZirconiumX: I don't know as I don't keep those details in my memory. I would have to read up on the different costs in a documentation before fiddeling with them.
08:13<@Alberth>ZirconiumX: it's a very useful site imho, in the past I have found it fun reading it
08:14<ZirconiumX>what is the DorpsGek function for factorials?
08:15<@Yexo>@calc 5!
08:15<@DorpsGek>Yexo: Error: unexpected EOF while parsing (<string>, line 1)
08:15<@Yexo>no idea
08:15-!-aber [] has joined #openttd
08:15<Zuu>Why not use stand-alone calculator program or physical calculator?
08:16*ZirconiumX uses the built in calculator called the Brain
08:16<@planetmaker>@calc factorial(5)
08:16<@DorpsGek>planetmaker: Error: 'factorial' is not a defined function.
08:17<@Alberth>planetmaker: 120
08:18<ZirconiumX>number of calculations possible = 64000 ^ 63999 + 64000 ^ 63998 + 64000 ^ 63997 ... - 1
08:18<ZirconiumX>Zuu: that's why
08:18<@planetmaker>@albert sin(sqrt(exp(i**sqrt(2))))
08:18*planetmaker wonders if that works :-P
08:18<CIA-1>OpenTTD: rubidium * r22401 /trunk/src/network/ (core/packet.h core/udp.cpp core/udp.h network_udp.cpp): -Codechange: replace some defines in the udp code so doxygen can create better documentation
08:19<ZirconiumX>@calc sin(sqrt(exp(i**sqrt(2))))
08:19<@DorpsGek>ZirconiumX: 0.655543174835+0.225407719727i
08:19<ZirconiumX>planetmaker: there's your answer
08:20<Zuu>I usually hit Win+R and type calc whenever I need a calculator. So at the end of the day I may end up with 3-5 calculator instances :-)
08:21<ZirconiumX>@myself 4**(4**(4**(4**9)))
08:21<ZirconiumX>ZirconiumX: I don't know
08:21<ZirconiumX>the brain needs improving it seems
08:21<CIA-1>OpenTTD: rubidium * r22402 /extra/masterserver_updater/src/ (7 files in 3 dirs): [MSU] -Fix: compilation after changes in trunk
08:22-!-Brianetta [] has joined #openttd
08:23<ZirconiumX>bc:Runtime error (func=(main), adr=18): exponent too large in raise
08:23<ZirconiumX>too big
08:24<ZirconiumX>you can't ! the answer to life the universe and everything
08:24<ZirconiumX>42 ! = 1.40500612 × 1051
08:26*Alberth helps ZirconiumX a little bit: 4**(4**9) is
08:27<ZirconiumX>I'm trying to see if bc can do it
08:28<ZirconiumX>it failed at the last hurdle
08:30*ZirconiumX is going to kill my computer
08:35*Alberth provides a sledge hammer to assist
08:35<ZirconiumX>I'm computing pi to 10000 places
08:35<ZirconiumX>and I only have 1Ghz to do it with
08:36<ndh>does it even make sense to increment the SAVEGAME_VERSION by 1 in a patch?
08:36<ndh>shouldnt it be set to something special like SL_MAX_VERSION or sth?
08:39<@Alberth>ZirconiumX: but the computer already knows the value: 𝛑 <-- see?
08:39<ZirconiumX>01D6D1 is all that it says
08:40<@Alberth>you are missing a few fonts then :)
08:41<@Alberth>ndh: several values make sense afaik, although SL_MAX_VERSION is unlikely to be one of them
08:41<@Alberth>+1 are steps done in trunk
08:42<@Alberth>+more can be used to maintain compability between your patch and several trunk versions
08:42<ndh>yea exactly, but if someone uses a patch, it's probably not going to be compatible with the next version used in trunk
08:43<Ammler>Zuu: on KDE, you don't need a calc, you just type the formula and get the answer ;-)
08:43<@Alberth>ndh: that even holds for patches that do not increment save game versions :)
08:43<Zuu>sounds useful as the calc keyboard UI sucks.
08:44<Zuu>It can't for example handle / if it is on a Alt+Gr key.
08:44<Ammler>wow, it is in your layout?
08:44<Zuu>Alt Gr + o
08:45<Zuu>(O is on qwerty S)
08:46<ndh>if someone saves a game from a patched exe, it shouldn't be possible to load that game from an official version, so wouldnt SL_MAX_VERSION make the most sense?
08:46<Ammler>sometimes, I wonder, why it is alt gr and not just alt
08:47<Ammler>so you could use the left one too
08:47<Rubidium>ndh: eventually SL_MAX_VERSION will get increased as well
08:47<Zuu>But then you would lose Alt for menues etc.
08:47<ZirconiumX>Ammler: because it's angry
08:47<ndh>Rubidium, yea, it seems kinda low
08:48-!-romazoon [] has joined #openttd
08:48<@Alberth>ndh: and it doesn't help, if you have 2 patched exes (with different patches applied), they would both accept each others save games
08:49<Zuu>But yes, one of the main criterias I use when buying a laptop is that the alt + gr key is not to far to the right as that would mean bending your thumb in a way to akward position.
08:52<ndh>Alberth, true, but at least it wouldn't be possible to crash an official version with it :)
08:52<@planetmaker>ndh: OpenTTD should not crash but just complain about invalid chunks
08:53-!-amkoroew1 [] has joined #openttd
08:58-!-amkoroew [] has quit [Ping timeout: 480 seconds]
09:02-!-sla_ro|master [slaco@] has quit [Quit: Mutant Co-Op - C&C Renegade]
09:08<Markk>Can't you transport oil i planes anymore?
09:08<@planetmaker>could you ever?
09:09<Markk>I think so. :o
09:10<xQR>i think i remember it was possible in the past to refit planes for oil, but that got removed a quite long time ago
09:10<xQR>maybe it was 0.6.3 or something where that still was possible
09:10<Markk>Oh, that sucks then. :D
09:10<Markk>Too oldskool here.
09:11<Markk>I remember 0.4.7.
09:11<xQR>hey planetmaker my C# implementation of the admin interface is making progress :)
09:12<@planetmaker>good :-)
09:12<xQR>though that program is only to test the classes, so i can see whether utilizing it from an application really works
09:14<xQR>in the end i went with just reading the openttd source, imho it has a better documentation than joan or that python implementation
09:19<Rubidium>yeah, especially tcp_admin.h's documentation is meant for those trying to implement the protocol
09:20<xQR>yep, i found the info in there is absolutely sufficient
09:20<xQR>and if in doubt you can still always check the source to see what he really expects when receiving a packet or what he does when sending one
09:26<ndh>does openttd use threading?
09:26<Rubidium>ndh: yes
09:27*Rubidium now expects some question why something doesn't happen while it's being said that OpenTTD uses threading
09:28<ndh>well i was just wondering if i have to pay attention to synchronize stuff
09:29<ndh>does the GUI run in a different thread than e.g. the pathfinder or sth?
09:30<CIA-1>OpenTTD: rubidium * r22403 /trunk/src/network/core/ (9 files): -Document: some more network/core code
09:31-!-douknoukem [] has joined #openttd
09:32<@planetmaker>mostly not
09:35*Rubidium loves meta questions
09:38-!-DOUK [] has quit [Ping timeout: 480 seconds]
09:39<ndh>:) it's just that from work i'm used to have the GUI run in a different thread, so special care has to be taken when displaying stuff so that it won't get changed during a drawing call
09:40<Rubidium>it's just that if you asked whether a particular part requires synchronisation we could give a better answer
09:41<Rubidium>e.g. drawing sometimes runs in a different thread: but... that's only during map generation when there's only a single window on the screen. Thus for all other windows it doesn't happen
09:42<ndh>is that what _draw_threaded is for?
09:44<Rubidium>on the other hand... on at least Linux the blitting happens in another thread. However, that prepares everything synchronised and then does the drawing while the other thread runs the game state and that has no influence on the stuff that's going to be drawn
09:44<ndh>i see
09:44<Rubidium>and as such the *actual* drawing code the you're working on runs in the same thread as the code that modifies the game state
09:45<ndh>ok, thank you
09:46<Rubidium>likewise with savegame stuff. It quickly makes a snapshot and then starts a thread for compressing that, so it doesn't burden any other code with threading issues
09:46<Rubidium>(well, except a bit of the networking code but that's by design as it means it can start sending the savegame sooner so joins are significantly faster now)
09:49-!-APTX_ [] has joined #openttd
09:50-!-APTX [] has quit [Remote host closed the connection]
09:51-!-sla_ro|master [~slaco@] has joined #openttd
10:11-!-ZirconiumX [] has quit [Quit: ajax IRC Client]
10:23-!-andythenorth [] has joined #openttd
10:41-!-aber1 [] has joined #openttd
10:41-!-aber [] has quit [Read error: Connection reset by peer]
10:54<ndh>does the generate project recreate the .vcxproj file?
10:54<ndh>and unset my include/lib dir?
10:56<+glx>include/lib dir should not be in vcxproj
10:56<ndh>it kinda does
10:57<+glx>that's a VC2010 feature I don't like
10:57<ndh>where should it be then?
10:57<ndh>it does make sense though
10:57<+glx>yes it does
10:58<ndh>is there a global setting in 2010?
10:58<+glx>but previous version used to have vcproj.user for that
11:00<+glx>check property manager
11:05-!-Vadtec_ [] has joined #openttd
11:06-!-Vadtec [] has quit [Remote host closed the connection]
11:06-!-Vadtec_ is now known as Vadtec
11:06-!-sigue [] has quit [Remote host closed the connection]
11:09<ndh>ok got it, thanks
11:10<ndh>the files in projects/ don't need to be included in patches, right?
11:11-!-Chris_Booth [] has quit [Read error: Connection reset by peer]
11:12-!-Chris_Booth [] has joined #openttd
11:13<@Yexo>ndh: doesn't matter much, but feel free to include also those changes
11:13-!-DOUK [] has joined #openttd
11:19-!-fonsinchen [] has joined #openttd
11:19-!-douknoukem [] has quit [Ping timeout: 480 seconds]
11:19-!-sigue [] has joined #openttd
11:22-!-KenjiE20 [~KenjiE20@] has quit [Remote host closed the connection]
11:22-!-KenjiE20 [~KenjiE20@] has joined #openttd
11:23-!-pugi [] has quit [Ping timeout: 480 seconds]
11:23-!-pugi [] has joined #openttd
11:25-!-HerzogDeXtEr1 [] has joined #openttd
11:30-!-HerzogDeXtEr [~Flex@] has quit [Ping timeout: 480 seconds]
11:33-!-KouDy1 [] has joined #openttd
11:33-!-KouDy1 [] has quit []
11:44-!-Devroush [] has joined #openttd
12:00-!-andythenorth [] has quit [Quit: andythenorth]
12:01-!-benj014 [] has joined #openttd
12:02<benj014>Hi everyone
12:04<benj014>hope your ok :-)
12:04<benj014>im new to all this and im looking for some help
12:05<benj014>or direction :-)
12:06<benj014>with regards to downloads and update
12:07<@planetmaker>in what way?
12:07-!-andythenorth [] has joined #openttd
12:07<@planetmaker>Get the installer from and then extensions, if you want some mods, via ingame content download
12:08<@planetmaker>I suggest though, to start first without mods
12:08<@planetmaker>and get a feel of how the game works
12:09<benj014>oh sorry had the game for ages -- lookin for help with mods and 32bpp update lol
12:09<benj014>im on a mac tho
12:10<@Yexo>openttd supports 32bpp graphics out of the box, if you're looking for the extra-zoom project you should say so
12:10<@Yexo>also: when you say "mods", are you talking about patches to the source code or about NewGRFs?
12:11<benj014>i got the extra zoom working - but could not use any NewGRFs
12:11<@Yexo>you can only change newgrfs in the main menu
12:12<benj014>it would not find any on the 32bpp
12:12<@Yexo>32bpp tars are not newgrfs
12:13*andythenorth wonders if there's a better term than "Engineering Supplies"
12:14<andythenorth>english is quite flexible...other languages apparently less so
12:15<@Alberth>what are they?
12:15<benj014>when i was on the 32bpp i could not use any GRF's - so had all the old trains and stuff - im looking to get better trains and graphics if that makes sence
12:15<andythenorth>stuff you need to dig stuff up mostly
12:15<andythenorth>machinery, parts, fabricated structures, fuel, wooden structures
12:15<frosch123>"Heavy Equipment"
12:16<@planetmaker>oh, hi andythenorth
12:16<@Yexo>benj014: where is your openttd.cfg?
12:16<@Yexo>if it's in the installation directory of your old installation, move it to "Documents/OpenTTD"
12:17<@Yexo>all newgrfs/savegames/scenarios/AIs should go there too, that way they can be used by all installations you have
12:18-!-supermop [] has joined #openttd
12:19<@Alberth>andythenorth: I'd call it mining equipment
12:19*andythenorth ponders
12:19<benj014>Yexo - sorry wots a cfg
12:19<@planetmaker>andythenorth: supplies is a generic word as can be. That is intrinsically difficult to translate
12:19<Zuu>benj014: A file with the .cfg extension.
12:19<@Yexo>benj014: just search for a file called "openttd.cfg"
12:20-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
12:20<@planetmaker>But IMHO it should not be your (main) concern, but spark the creativity of the translators
12:20*andythenorth returns to current main concern
12:20<andythenorth>playing YACD
12:20<@planetmaker>it would either be, benj014 with your or in ~/Documents/OpenTTD
12:20<@planetmaker>usually at least :-)
12:22<@planetmaker>hi supermop
12:22<Eddi|zuHause>what's the town size that a town accepts noise level 4 (with 'tolerant')?
12:22<benj014>its with my original ttd folder
12:23<@Yexo>is also there?
12:23<Eddi|zuHause>a large city near a small town should influence their noise level
12:24<benj014>then the 32bpp is in a new folder - called ttd2
12:24<@Yexo>and also directories called "save", "scenario", "downloaded_content" and "data"?
12:24<@Yexo>move openttd.cfg and those directories to ~/Documents/OpenTTD/
12:24<@Yexo>that way they are shared between all your openttd installations
12:25<@Yexo>also move "gm" if you have it and want the music to work
12:25<benj014>yeah moved that already
12:27<supermop>I am thinking of buying a bonsai tree.
12:27<supermop>I was reflecting on how it is similar to my current long running game
12:28<benj014>still no grfs
12:29<@Yexo>benj014: and if you download a few newgrfs via the online content system in your 32bpp version, do those show up?
12:29*andythenorth thinks mail in YACD is much like real life
12:30<andythenorth>a postal service is only truly useful if every node is connected
12:30-!-frosch [] has joined #openttd
12:30<benj014>no :-( - i go onto new grfs .. look for new content but nothing there
12:30<supermop>does intra-city bus and metro service work in yacd?
12:30<andythenorth>better than before
12:30<supermop>better than in CD?
12:30<andythenorth>didn't try CD
12:32*andythenorth wishes towns didn't shrink when serviced
12:32<andythenorth>I thought I raised a FS about that months ago, but can't find it
12:32<supermop>people using your great service to get the hell out of town
12:32<Rubidium>might it be the town newgrf you're using that's causing that?
12:33<andythenorth>providing service causes the town to start rebuilding, but it rebuilds with smaller buildings
12:33<andythenorth>I can reproduce it I reckon
12:33<andythenorth>it seems worse < 1900
12:33<andythenorth>or maybe 1930
12:33<benj014>and then on the 32bpp the GFX graphic option also is not there
12:33<andythenorth>and it seems worse with ships, but can't be sure
12:34<supermop>everyone migrating away, call it realism
12:34<@Yexo><benj014> and then on the 32bpp the GFX graphic option also is not there <- which gfx graphic option?
12:34<@Yexo>benj014: where did you download your 32bpp version? what is the version number?
12:36<andythenorth>last time I got interested in the town problem, I tried to figure out why town-growth mechanism is selecting different buildings to map gen
12:36<andythenorth>but I didn't find an obvious answer
12:36<benj014>on my original game - in game options i can choose the graphics set - GFX gives me better looking roads and tracks etc
12:36-!-frosch123 [] has quit [Ping timeout: 480 seconds]
12:37<@Yexo>ah, you mean "OpenGFX"
12:37<@Yexo>benj014: again, which version is your 32bpp build?
12:37<@Yexo>just giving a link to the location you downloaded it from is also ok
12:38<benj014>got it from - for mac's - version r9538-32bpp
12:38<@Yexo>r9538 is ancient
12:38<@Yexo>that's 4 year old or something like that
12:38<__ln__>it's pre-cake1
12:38<benj014>oh thats the only mac one i could find
12:38<@Yexo>yes :o
12:39<andythenorth>^^^^ basically the large blocks of flats are replaced with smaller buildings
12:39<@Yexo>it'll be hard to find any newgrfs that work in that version
12:40<benj014>cool thanks
12:40<@Yexo>benj014: download a newer version here:
12:40<@Yexo>and more in general you'll find updated information on the forum:
12:41<@Yexo>and the relevant wiki page:
12:41<@planetmaker>andythenorth: that's just the normal fluctuation
12:41<@planetmaker>replace one house by another, that's it
12:41<andythenorth>planetmaker: I think it's unhelpful
12:41<andythenorth>but got to go :)
12:42-!-andythenorth [] has left #openttd []
12:43<benj014>so do i just down load the ones for mac ?
12:43<@Yexo>only this one:
12:43<benj014>and then what do i do with them ? sorry im not the most techincal person
12:43<@Yexo>you extract the zip and run whatever you find inside
12:45<benj014>cool thank you
12:45<benj014>just downloaded
12:46<benj014>so take it i have to copy all the data folders and the gm again
12:47<@Yexo>as long as they are in ~/Documents/OpenTTD/ they can be used by every version of OpenTTD you install
12:47<@planetmaker>if you kept it in ~/Documents/OpenTTD you can keep it forever for all versions
12:47<@planetmaker>at least which exist so far ;-)
12:48<benj014>ahhh im confussed
12:52-!-Mazur [] has joined #openttd
12:54<benj014>yay got it workin .. thank you very much
12:55<supermop>Ok, weather is too nice, I am going outside
12:56<ndh>there's no list window with all waypoints in the game, is there?
12:57<@Yexo>benj014: your post on the forum was removed because on it's not clear where to find anything related to openttd
12:57<@Yexo>also next time please state more clear was you actually tried and _what exactly_ does not work
12:58<benj014>found new trains on wot do i do with the down loads ... sorry yexo i will try to be more specific
12:58<welshdragon>benj014, they're not for OpenTTD
12:59-!-Sacro [] has joined #openttd
12:59<benj014>thank you
13:00<benj014>so you know when people say they have made a new set of trains on the forums .. can they be found in NewGRFs ?
13:00<@Yexo>usually those same people will also upload a grf file to the forums
13:01<benj014>thanks for the help
13:05-!-benj014 [] has quit [Quit: Bye for now!]
13:10-!-Devroush [] has quit []
13:19*Zuu just gave CluelessPlus a slightly more human behaviour by limiting new connections to be constructed near existing ones.
13:20<Zuu>In a first test with two CluelessPlus instances against eachother, the one with this limitation performs not as good in terms of profit, but is still working good.
13:22<Zuu>So the question is, shall the AI default settings be for AI battles (no limit) or for humans (limits on)
13:22<Zuu>The AI without limits is about 40-60% better than the limited one.
13:23<Zuu>(on a 256x2048 map)
13:23<Zuu>(or if it was even 128x2048)
13:27*Zuu decides to have the limit enabled for easy, medium and disabled for hard and custom. Most AI-battles will probably use custom dificulty.
13:31<@planetmaker>I wonder how many games actually are rather custom difficulty over one of the other difficulties
13:32<@planetmaker>Zuu: I'd choose one option for all difficulty levels
13:32<@planetmaker>makes it easier to configure
13:33<@planetmaker>IMHO nothing is worse, if a behaviour changes, just because I changed something somewhere totally unrelated ;-)
13:33<@planetmaker>(without need for that behaviour change, of course)
13:34<@planetmaker>unless you 'unexpose' it and just include it in the difficulty setting
13:34<Zuu>I would assume that if you had set any settings for an AI they will not change when you change dificulty. Only the "defaults" will be based on your current difficulty.
13:35<@planetmaker>Well, yes. But that would come to me at a surprise, if the AI behaviour other than 'difficulty' changes with difficulty
13:36<@planetmaker>though maybe not, but... feels at least initially slightly awkward
13:37<Zuu>I would say the AI is easier if it does have some kind of fog-of-war limitation than not.
13:38<@planetmaker>well, possibly
13:43-!-tokai|mdlx [] has joined #openttd
13:45<CIA-1>OpenTTD: translators * r22404 /trunk/src/lang/brazilian_portuguese.txt:
13:45<CIA-1>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-1>OpenTTD: brazilian_portuguese - 4 changes by Tucalipe
13:47-!-DanMacK [~DanMacK@] has joined #openttd
13:49-!-douknoukem [] has joined #openttd
13:50-!-tokai|noir [] has quit [Ping timeout: 480 seconds]
13:52<DanMacK>Hey all
13:54-!-DOUK [] has quit [Ping timeout: 480 seconds]
13:57<Eddi|zuHause>Zuu: isn't there an AI intelligence setting for such stuff?
13:58<Eddi|zuHause>i would say most people play custom...
14:00<Zuu>But I guses there is at least some that just want to set the dificulty level and go.
14:00<Zuu>(I know there are vast amount of settings in adv. settings that don't change when you change dificulty.)
14:03<Zuu>as AI you could write a setting-layer so that all your settings are [via intelligence setting, ON, OFF] in the GUI, and then you have a middle-layer in your AI that tell if the setting ON/OFF to the AI logic layer depending on the intelligence if that GUI-setting has been selected.
14:04<Zuu>However, it is not done automatically and as far as I know, no AI use this. The different defaults for each difficulty-level on the other hand is something that is supported in the API.
14:07-!-andythenorth [] has joined #openttd
14:07<DanMacK>Hey Andy
14:12-!-dfox [] has quit [Ping timeout: 480 seconds]
14:32<Eddi|zuHause>Zuu: not all things that are supported are a good idea...
14:37<andythenorth>planetmaker: the town growth could be normal fluctuation
14:37<andythenorth>it's possible that I only notice the ones that shrink, and not the ones that grwo
14:37<andythenorth>like confirmation bias
14:44<@planetmaker>I suppose so, yes
14:44<andythenorth>I think there's a problem though
14:44<andythenorth>I'd have to read src I guess
14:48*andythenorth ponders
14:48<andythenorth>YACD can switch amounts-per-destination for industry cargo quite brutally
14:50-!-fonsinchen [] has joined #openttd
14:52-!-douknoukem [] has quit [Ping timeout: 480 seconds]
14:53-!-ar3k [] has quit [Quit: —I-n-v-i-s-i-o-n— 3.2 (July '10)]
14:59-!-Sacro [] has quit [Ping timeout: 480 seconds]
15:01-!-andythenorth_ [] has joined #openttd
15:05-!-Sacro [] has joined #openttd
15:08-!-andythenorth [] has quit [Ping timeout: 480 seconds]
15:14<@Yexo>Zuu: when the difficulty level is not set to custom you can't change any AI settings. As soon as you change the setting of any AI the difficulty level is reset to custom
15:14-!-ar3k [] has joined #openttd
15:14-!-ar3k is now known as ar3kaw
15:14<@Yexo>so there really is no need to handle the difficulty level separately in an AI
15:14<CIA-1>OpenTTD: rubidium * r22405 /trunk/src/ (35 files in 3 dirs): -Document: some more "random-ish" tidbits
15:17-!-andythenorth_ [] has quit [Read error: Connection reset by peer]
15:18-!-andythenorth [] has joined #openttd
15:31*andythenorth needs to change FIRS to support YACD
15:41<devilsadvocate>andythenorth: FIRS already works with YACD, doesnt it?
15:41<andythenorth>not very well in some respects
15:41<devilsadvocate>there are some wierd bits, but in general it seems to be ok
15:42<devilsadvocate>the major issue is stuff like engineering supplies
15:42<andythenorth>there's that
15:42<devilsadvocate>but even that can sort of be handled
15:42<andythenorth> the split of primary cargo production makes some routes almost impossibe
15:42<andythenorth>and I have an issue with secondary industry closing that isn't YACD specific, but is worse with YACD
15:43<devilsadvocate>i probably never had that issue since my primary industries always supplied a single secondary industry
15:44<devilsadvocate>it takes some time to switch, but in general its ok
15:44<devilsadvocate>also, i usually end up having to drop things off / pick stuff up by train a bit away from primaries, and use trucks to space the deliveries
15:46<andythenorth>there's a lot of people doing that it seems
15:47<devilsadvocate>thats the only way to get the primary to stay open
15:47<andythenorth>how interesting
15:47<devilsadvocate>they take too little supplies at a time, and cargodist makes it a bit... harder
15:47<andythenorth>I always play with primary closure off
15:47-!-Twerkhoven[L] [] has joined #openttd
15:48<andythenorth>I provide the option for people who like the challenge of primary closure, but it bugs me
15:49<devilsadvocate>i've found that doing that (stations far away, smallest trucks available pacing deliveries) works almost always
15:50<devilsadvocate>that usually means the supplies routes operate in the red, but thats fine since the primaries more than pay for them
15:50<devilsadvocate>and the manufacturing sites for the supplies always have wierd stations on them, with 20 or 30 tiny platofrms
15:51-!-Mucht [] has joined #openttd
15:51-!-Mucht is "Martin Nussbaumer" on @#coopetition @#JJ @+#openttdcoop.association #wwottdgd #openttd @#openttdcoop
15:51<Eddi|zuHause>feature request: in the vehicle list, make right click do the same as in depot: view statistics about capacity
15:52<CIA-1>OpenTTD: rubidium * r22406 /trunk/ (33 files in 7 dirs): -Document: some more "random-ish" tidbits
15:52<andythenorth>devilsadvocate: that gameplay is fun? It doesn't annoy you?
15:53<devilsadvocate>andythenorth: well, i like intricate networks
15:53<devilsadvocate>every so often it, um, breaks
15:53<andythenorth>so long as it's fun ;)
15:54<devilsadvocate>one train stopping at the wrong station totally messes up cargodist
15:54<devilsadvocate>but otherwise its fun
15:59-!-sla_ro|master [~slaco@] has quit [Quit: Mutant Co-Op - C&C Renegade]
16:04<CIA-1>OpenTTD: rubidium * r22407 /trunk/src/ (driver.cpp driver.h): -Document: the "root" driver related stuff
16:11-!-Biolunar [] has joined #openttd
16:11<Eddi|zuHause>what's DB Regio doing with diesel engines?
16:11<Eddi|zuHause>i'd assumed DB Cargo would rather use those
16:12-!-Devroush [] has joined #openttd
16:22-!-Absurd-Mind [] has joined #openttd
16:31-!-tokai|noir [] has joined #openttd
16:33-!-frosch [] has quit [Remote host closed the connection]
16:35-!-Cybertinus [] has joined #openttd
16:37-!-tokai|mdlx [] has quit [Ping timeout: 480 seconds]
16:46<CIA-1>OpenTTD: yexo * r22408 /trunk/src/ (newgrf.cpp newgrf.h): -Cleanup: remove unused variable GRFFile::sprite_offset
16:49-!-douknoukem [] has joined #openttd
16:49-!-Juo [] has quit [Quit: Juo]
16:49-!-Juo [] has joined #openttd
16:50-!-Alberth [] has left #openttd []
16:51-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
16:52-!-andythenorth [] has left #openttd []
16:53-!-Juo [] has quit []
16:55-!-roboboy [] has quit [Read error: Operation timed out]
16:58-!-DanMacK [~DanMacK@] has quit [Read error: Connection reset by peer]
17:02<CIA-1>OpenTTD: yexo * r22409 /trunk/src/newgrf.cpp: -Fix: [NewGRF] make sure the action2 ID of a generic feature callback is valid
17:08<@Terkhen>good night
17:28-!-ar3k [] has joined #openttd
17:33-!-Mucht [] has quit [Remote host closed the connection]
17:36-!-ar3kaw [] has quit [Ping timeout: 480 seconds]
17:39-!-KouDy [] has quit [Quit: Leaving.]
17:45-!-ndh [] has left #openttd []
18:11-!-Cybertinus [] has quit [Remote host closed the connection]
18:14-!-Cybertinus [] has joined #openttd
18:17-!-Kurimus [] has quit []
18:21-!-Twerkhoven[L] [] has quit [Read error: Connection reset by peer]
18:27-!-lasershock` [] has joined #openttd
18:27-!-lasershock` [] has quit []
18:27-!-bryjen [~bryjen@] has joined #openttd
18:28-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:30-!-Cybertinus [] has quit [Remote host closed the connection]
18:30-!-Chillosophy [] has quit []
18:31-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:38-!-Pulec [] has quit []
18:52-!-Zuu [] has quit [Ping timeout: 480 seconds]
18:55-!-Adambean [] has quit [Quit: Gone fishing]
18:59-!-DDR [] has joined #openttd
19:03-!-Absurd-Mind [] has quit [Ping timeout: 480 seconds]
19:34-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
19:36-!-Sacro_ [] has joined #openttd
19:41-!-Xaroth_ [~Xaroth@] has joined #openttd
19:42-!-Sacro [] has quit [Ping timeout: 480 seconds]
19:44-!-Sacro_ [] has quit [Ping timeout: 480 seconds]
19:48-!-Xaroth [~Xaroth@] has quit [Ping timeout: 480 seconds]
19:53-!-romazoon [] has quit []
19:57-!-aber1 [] has quit [Quit: Leaving.]
20:16-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
20:18-!-DabuYu [DabuYu@] has joined #openttd
20:26-!-bryjen [~bryjen@] has quit [Quit: Leaving]
20:26-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
20:37-!-KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.4]
20:38-!-KritiK [] has quit [Quit: Leaving]
21:01-!-dfox [] has joined #openttd
21:05-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
21:07-!-DabuYu [DabuYu@] has quit []
21:09-!-DabuYu [~jkuckartz@] has joined #openttd
21:30-!-DOUK [] has joined #openttd
21:35-!-douknoukem [] has quit [Ping timeout: 480 seconds]
21:37-!-dfox [] has quit [Ping timeout: 480 seconds]
21:39-!-DOUK [] has quit [Ping timeout: 480 seconds]
21:47-!-Progman_ [] has joined #openttd
21:53-!-Brianetta [] has quit [Quit: Tschüß]
21:54-!-Progman [] has quit [Ping timeout: 480 seconds]
21:54-!-Progman_ is now known as Progman
22:05-!-Progman [] has quit [Remote host closed the connection]
22:26-!-rhaeder1 [] has joined #openttd
22:31-!-rhaeder [] has quit [Ping timeout: 480 seconds]
22:36-!-Intexon [] has quit [Read error: Operation timed out]
23:52-!-glx [glx@2a01:e35:2f59:c7c0:f1f7:c0f6:f53c:c79e] has quit [Quit: bye]
---Logclosed Mon May 02 00:00:26 2011