IRC logs for #openttd on OFTC at 2011-05-01
⏴ go to previous day
01:43:21 *** TinoDidriksen has joined #openttd
02:44:25 *** Intexon has joined #openttd
04:28:25 *** gartral has joined #openttd
04:28:50 <gartral> is the svn/hg server down or something? or is it just REALLY slow
04:56:18 *** Eddi|zuHause has joined #openttd
04:58:31 *** sla_ro|master has joined #openttd
05:28:53 *** roboboy has joined #openttd
05:57:41 *** seanbotv20 has joined #openttd
06:11:04 <seanbotv20> Are there any pros out there
06:11:11 <seanbotv20> I can't seem to turn a profit
06:35:55 *** Absurd-Mind has joined #openttd
06:39:39 *** Alberth has joined #openttd
06:39:39 *** ChanServ sets mode: +o Alberth
06:41:15 *** JVassie has joined #openttd
07:10:16 *** fonsinchen has joined #openttd
07:11:50 *** |Jeroen| has joined #openttd
07:51:21 <planetmaker> hm, is there a way to place an object on steep slopes?
08:05:56 *** LordAro has joined #openttd
08:17:38 <Rubidium> planetmaker: prop10 |= 20h + prop15 |= 01h?
08:20:25 <planetmaker> I use both, the flag and callback
08:21:01 <planetmaker> i.e. both bits you suggest are set. But I still get 'slope not suitable'
08:21:27 <planetmaker> and the CB never fails
08:22:42 <Rubidium> I see no checks for slope when callbacks succeed
08:23:17 <Rubidium> have you tried tracing it in OpenTTD?
08:24:32 <planetmaker> I shall dig further.
08:25:19 <Rubidium> I at least didn't implement (or did but took out later) anything to limit steep slopes
08:27:13 <planetmaker> hm... maybe I've forgotten one slope. I need to check :-)
08:28:42 <planetmaker> hm, yes. Thanks for putting me on the right track
08:46:16 *** Kurimus has joined #openttd
08:56:48 *** Cybertinus has joined #openttd
09:05:42 *** douknoukem has joined #openttd
09:12:13 *** frosch123 has joined #openttd
09:24:45 <CIA-1> OpenTTD: rubidium * r22396 /trunk/src/ai/ (18 files in 2 dirs): -Document: some AI doxygen stuff
09:31:40 <planetmaker> moin Zuu & Terkhen
09:46:38 *** Progman has joined #openttd
09:55:36 <planetmaker> is ok to define child sprites for ground tiles (for NewObjects)?
09:55:45 *** DayDreamer has joined #openttd
09:58:21 *** DayDreamer has left #openttd
10:03:54 *** Progman has joined #openttd
10:15:49 <CIA-1> OpenTTD: rubidium * r22397 /trunk/src/ (20 files in 2 dirs): -Document: some tidbits of the blitter code
10:26:47 *** Chillosophy has joined #openttd
10:30:44 <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
10:30:57 <planetmaker> But it seems only to cover the extend of a plain ground tile without slope
10:31:55 <planetmaker> On the other hand: specs also tell that I may not set the x and y extend for ground sprites
10:32:00 <planetmaker> nor for child sprites
10:40:00 <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
10:40:33 <planetmaker> err_no_context ;-)
10:41:59 <Alberth> oh, I should have pasted a bit more. sorry
10:42:40 *** tycoondemon has joined #openttd
10:43:06 <planetmaker> two, three days ago I wrote that, how should I remember when I have even trouble to recall what I wrote yesterday? :-P
10:50:05 *** KenjiE20 has joined #openttd
10:53:24 <fonsinchen> distyacd works nice.
10:55:11 <fonsinchen> only the destination lists in the town an industry GUIs need some care so that they don't overflow ...
10:55:26 <fonsinchen> but that should be a problem with plain YACD, too.
11:02:12 <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
11:05:18 *** Chris_Booth has joined #openttd
11:09:27 <michi_cc> fonsinchen: Yes, some scrollbar and/or collapsible entries are definitely required for compatibility with smaller screens.
11:09:50 <fonsinchen> Or with excessively long lists of destinations ;)
11:10:32 <fonsinchen> You might want to have a look at my repository. Especially the refactoring of link weight modifiers would look good in yacd, too.
11:12:20 * Zuu thinks about a generic filter for lists in OpenTTD. Or perhaps something SQL-ish. :-)
11:13:04 <Zuu> To start, each object type (eg. vehicles, towns, industries etc) would need a list of properties that can be filtered.
11:13:26 <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
11:13:47 <Zuu> Operations like SUM(col_name) etc. would also be useful :-)
11:14:33 <Zuu> But a simple SQL implementation might be to advanced for the average OpenTTD player?
11:14:58 * Alberth proposes to replace OpenTTD with a spreadsheet with numbers
11:15:46 <Rubidium> Alberth: OpenTTD's output can easily be put into a spreadsheet
11:16:17 <Alberth> indeed, and the iterative simulation can be done too, no need to display any graphics
11:16:22 <Zuu> In my last game I had problem keeping track of all different routes (shared orders groups) that served each station.
11:16:41 <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.
11:18:09 <Alberth> Rubidium: good exercise for the office, make a row of 1's that travel in a circle in your spread sheet
11:18:59 <Zuu> With a lot of vehicles serving a station, it is non-trivial to figure out which stations/vehicle routes that service that station.
11:19:04 <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).
11:19:30 <fonsinchen> I don't mind at all. Go ahead
11:20:12 <fonsinchen> Also you might want to look at the "capacities" branch. That's where I do my version of prefilling orders/routes.
11:20:27 <fonsinchen> I think there are some corner cases you haven't covered yet.
11:21:01 *** romazoon has joined #openttd
11:21:13 <fonsinchen> and eventually people will ask for something like my ext-rating. But maybe that shouldn't be part of yacd.
11:25:45 <michi_cc> Yeah, I could handle deterministic conditional orders, even if the route links will still be created when the vehicle actually travels.
11:26:16 <ndh> hello, is there a specific channel for developers? i'm trying to port the old Train Counter patch to 1.1.0
11:26:55 <Yexo> feel free to ask any questions you have in this channel
11:27:29 <fonsinchen> Another thing people were complaining about in cargodist was that links timed out while a vehicle was still full loading.
11:28:16 <fonsinchen> I solved that with the "Refresh" thing where I periodically reset the timeout while vehicles are loading.
11:28:40 <fonsinchen> That would translate to setting the timeout to some "max_timeout - X" for yacd.
11:28:52 <fonsinchen> But maybe you should wait until the problem arises ...
11:30:15 <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
11:30:21 <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 http://pastebin.com/QP0PkSvP
11:30:56 <Rubidium> waypoints aren't rail tiles anymore
11:31:52 <ndh> i don't know what that means... how do i find out if a tile is a waypoint?
11:32:28 <ndh> i tried IsRailWaypoint(), but the assertion in GetStationType() failed
11:33:14 <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?
11:33:28 <Terkhen> check the preconditions of IsRailWaypoint()
11:33:40 <Yexo> waypoints use MP_STATION, not MP_RAIL
11:34:09 <Yexo> IsRailWaypoint has as precondition that the tile is of the type MP_STATION, IsRailWaypointTile has that check included in the function
11:34:28 *** Adambean has joined #openttd
11:34:42 <ndh> oh ok, do you mean that the vehicle_enter_tile_proc isnt even called for waypoints, since the type is station?
11:35:00 <Yexo> indeed, it's only called for tiles with tile type MP_RAIL
11:35:11 <Rubidium> at least not the one in rail_cmd.cpp
11:35:19 <Yexo> VehicleEnter_Station in station_cmd.cpp is the correct function
11:39:15 <ndh> yay it works :) thanks guys
11:45:07 *** ZirconiumX has joined #openttd
11:49:12 <ndh> btw, vehicle_enter_tile_proc isn't called only once when a vehicle enters a tile, is it?
11:54:23 <Yexo> IIRC you're right, it's called multiple times per tile
11:54:33 <Yexo> but I'm not really sure, didn't check just now
11:57:52 <ZirconiumX> What is the maximum number of towns a map can have?
11:58:24 <Zuu> Try to write a huge number in custom town amount :-)
11:59:44 <Yexo> ZirconiumX: limited by the minimum distance between towns and the map size
12:00:18 <Yexo> the actual limit in the code is 64000 towns, but you won't be able to reach that on a 2048x2048 map
12:04:05 <ZirconiumX> Is there an <easy> way to optimise the A* pathfinder
12:04:19 <ZirconiumX> I think WmDOT did it with a Fibbonacci heap
12:05:09 <planetmaker> :-) A* is already an optimized PF. The question is by which criteria you want a PF optimized
12:05:48 <Yexo> do you want a perfect path or does that not matter so much?
12:05:49 <Zuu> You can reduce how much it will search for different paths.
12:05:52 <planetmaker> then use 'drive straight unless not possible'
12:06:27 <ZirconiumX> Yexo: as long as it connects the towns - I don't care
12:06:31 <planetmaker> but it might not find the destination then ;-)
12:06:32 <Alberth> ZirconiumX: didn't you have a fast D* ?
12:06:35 <Zuu> Original Clueless had a pathfinder that drove stright until it hit an obstacle, turned 90 degrees and continued. :-)
12:06:54 <ZirconiumX> I haven't finished it yet - you could barely say I've started it
12:07:36 <ZirconiumX> I've heard you can play around with the _Cost function of the RoadPF
12:08:10 <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.
12:08:17 *** frosch123 has joined #openttd
12:08:28 <Alberth> yes, by overestimating costs, it explores less alternatives but paths may be less optimal
12:09:13 <Yexo> ZirconiumX: simplifying the Cost function might give some speedup, also making Estimate return a higher value that necessary
12:09:44 <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.
12:10:38 *** Intexon has joined #openttd
12:10:58 <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.
12:11:17 <ZirconiumX> Yexo & Zuu: local cost = RoadPathFinder._Cost x 1.1 <---- Will that help?
12:11:42 <Zuu> (bridging canals that is - bridging rail is not faster as in terms of building, just makes your trucks survive better ;-) )
12:13:11 <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.
12:13:55 <Alberth> ZirconiumX: it's a very useful site imho, in the past I have found it fun reading it
12:14:48 <ZirconiumX> what is the DorpsGek function for factorials?
12:15:18 <DorpsGek> Yexo: Error: unexpected EOF while parsing (<string>, line 1)
12:15:50 <Zuu> Why not use stand-alone calculator program or physical calculator?
12:16:42 * ZirconiumX uses the built in calculator called the Brain
12:16:56 <planetmaker> @calc factorial(5)
12:16:56 <DorpsGek> planetmaker: Error: 'factorial' is not a defined function.
12:18:12 <ZirconiumX> number of calculations possible = 64000 ^ 63999 + 64000 ^ 63998 + 64000 ^ 63997 ... - 1
12:18:35 <planetmaker> @albert sin(sqrt(exp(i**sqrt(2))))
12:18:44 * planetmaker wonders if that works :-P
12:18:48 <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
12:19:17 <ZirconiumX> @calc sin(sqrt(exp(i**sqrt(2))))
12:19:17 <DorpsGek> ZirconiumX: 0.655543174835+0.225407719727i
12:19:33 <ZirconiumX> planetmaker: there's your answer
12:20:50 <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 :-)
12:21:26 <ZirconiumX> @myself 4**(4**(4**(4**9)))
12:21:35 <ZirconiumX> ZirconiumX: I don't know
12:21:46 <ZirconiumX> the brain needs improving it seems
12:21:52 <CIA-1> OpenTTD: rubidium * r22402 /extra/masterserver_updater/src/ (7 files in 3 dirs): [MSU] -Fix: compilation after changes in trunk
12:22:58 *** Brianetta has joined #openttd
12:23:11 <ZirconiumX> bc:Runtime error (func=(main), adr=18): exponent too large in raise
12:24:12 <ZirconiumX> you can't ! the answer to life the universe and everything
12:24:14 <ZirconiumX> 42 ! = 1.40500612 × 1051
12:27:16 <ZirconiumX> I'm trying to see if bc can do it
12:28:26 <ZirconiumX> it failed at the last hurdle
12:30:51 * ZirconiumX is going to kill my computer
12:35:00 * Alberth provides a sledge hammer to assist
12:35:26 <ZirconiumX> I'm computing pi to 10000 places
12:35:43 <ZirconiumX> and I only have 1Ghz to do it with
12:36:23 <ndh> does it even make sense to increment the SAVEGAME_VERSION by 1 in a patch?
12:36:58 <ndh> shouldnt it be set to something special like SL_MAX_VERSION or sth?
12:39:07 <Alberth> ZirconiumX: but the computer already knows the value: 𝛑 <-- see?
12:39:46 <ZirconiumX> 01D6D1 is all that it says
12:40:04 <Alberth> you are missing a few fonts then :)
12:41:45 <Alberth> ndh: several values make sense afaik, although SL_MAX_VERSION is unlikely to be one of them
12:41:59 <Alberth> +1 are steps done in trunk
12:42:39 <Alberth> +more can be used to maintain compability between your patch and several trunk versions
12:42:40 <ndh> yea exactly, but if someone uses a patch, it's probably not going to be compatible with the next version used in trunk
12:43:06 <Ammler> Zuu: on KDE, you don't need a calc, you just type the formula and get the answer ;-)
12:43:49 <Alberth> ndh: that even holds for patches that do not increment save game versions :)
12:43:52 <Zuu> sounds useful as the calc keyboard UI sucks.
12:44:11 <Zuu> It can't for example handle / if it is on a Alt+Gr key.
12:44:36 <Ammler> wow, it is in your layout?
12:46:26 <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?
12:46:48 <Ammler> sometimes, I wonder, why it is alt gr and not just alt
12:47:00 <Ammler> so you could use the left one too
12:47:06 <Rubidium> ndh: eventually SL_MAX_VERSION will get increased as well
12:47:12 <Zuu> But then you would lose Alt for menues etc.
12:47:27 <ZirconiumX> Ammler: because it's angry
12:47:40 <ndh> Rubidium, yea, it seems kinda low
12:48:32 *** romazoon has joined #openttd
12:48:56 <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
12:49:05 <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.
12:52:06 <ndh> Alberth, true, but at least it wouldn't be possible to crash an official version with it :)
12:52:35 <planetmaker> ndh: OpenTTD should not crash but just complain about invalid chunks
12:53:23 *** amkoroew1 has joined #openttd
13:08:00 <Markk> Can't you transport oil i planes anymore?
13:10:23 <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
13:10:40 <xQR> maybe it was 0.6.3 or something where that still was possible
13:10:46 <Markk> Oh, that sucks then. :D
13:11:57 <xQR> hey planetmaker my C# implementation of the admin interface is making progress :)
13:12:50 <xQR> though that program is only to test the classes, so i can see whether utilizing it from an application really works
13:14:09 <xQR> in the end i went with just reading the openttd source, imho it has a better documentation than joan or that python implementation
13:19:51 <Rubidium> yeah, especially tcp_admin.h's documentation is meant for those trying to implement the protocol
13:20:10 <xQR> yep, i found the info in there is absolutely sufficient
13:20:48 <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
13:26:05 <ndh> does openttd use threading?
13:27:20 * Rubidium now expects some question why something doesn't happen while it's being said that OpenTTD uses threading
13:28:22 <ndh> well i was just wondering if i have to pay attention to synchronize stuff
13:29:19 <ndh> does the GUI run in a different thread than e.g. the pathfinder or sth?
13:30:03 <CIA-1> OpenTTD: rubidium * r22403 /trunk/src/network/core/ (9 files): -Document: some more network/core code
13:31:55 *** douknoukem has joined #openttd
13:35:01 * Rubidium loves meta questions
13:39:04 <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
13:40:41 <Rubidium> it's just that if you asked whether a particular part requires synchronisation we could give a better answer
13:41:38 <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
13:42:44 <ndh> is that what _draw_threaded is for?
13:44:03 <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
13:44:34 <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
13:46:23 <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
13:46:58 <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)
13:51:42 *** sla_ro|master has joined #openttd
14:23:07 *** andythenorth has joined #openttd
14:54:26 <ndh> does the generate project recreate the .vcxproj file?
14:54:59 <ndh> and unset my include/lib dir?
14:56:09 <glx> include/lib dir should not be in vcxproj
14:57:12 <glx> that's a VC2010 feature I don't like
14:57:24 <ndh> it does make sense though
14:58:00 <ndh> is there a global setting in 2010?
14:58:19 <glx> but previous version used to have vcproj.user for that
15:05:04 *** Vadtec_ has joined #openttd
15:06:07 *** Vadtec_ is now known as Vadtec
15:10:34 <ndh> the files in projects/ don't need to be included in patches, right?
15:12:28 *** Chris_Booth has joined #openttd
15:13:16 <Yexo> ndh: doesn't matter much, but feel free to include also those changes
15:19:25 *** fonsinchen has joined #openttd
15:22:59 *** KenjiE20 has joined #openttd
15:25:36 *** HerzogDeXtEr1 has joined #openttd
15:44:06 *** Devroush has joined #openttd
16:01:09 *** benj014 has joined #openttd
16:04:33 <benj014> im new to all this and im looking for some help
16:06:07 <benj014> with regards to downloads and update
16:07:30 *** andythenorth has joined #openttd
16:07:38 <planetmaker> Get the installer from openttd.org and then extensions, if you want some mods, via ingame content download
16:08:16 <planetmaker> I suggest though, to start first without mods
16:08:24 <planetmaker> and get a feel of how the game works
16:09:03 <benj014> oh sorry had the game for ages -- lookin for help with mods and 32bpp update lol
16:10:11 <Yexo> openttd supports 32bpp graphics out of the box, if you're looking for the extra-zoom project you should say so
16:10:42 <Yexo> also: when you say "mods", are you talking about patches to the source code or about NewGRFs?
16:11:26 <benj014> i got the extra zoom working - but could not use any NewGRFs
16:11:52 <Yexo> you can only change newgrfs in the main menu
16:12:19 <benj014> it would not find any on the 32bpp
16:12:29 <Yexo> 32bpp tars are not newgrfs
16:13:57 * andythenorth wonders if there's a better term than "Engineering Supplies"
16:14:10 <andythenorth> english is quite flexible...other languages apparently less so
16:15:33 <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
16:15:37 <andythenorth> stuff you need to dig stuff up mostly
16:15:54 <andythenorth> machinery, parts, fabricated structures, fuel, wooden structures
16:16:15 <planetmaker> oh, hi andythenorth
16:16:21 <Yexo> benj014: where is your openttd.cfg?
16:16:54 <Yexo> if it's in the installation directory of your old installation, move it to "Documents/OpenTTD"
16:17:24 <Yexo> all newgrfs/savegames/scenarios/AIs should go there too, that way they can be used by all installations you have
16:18:45 *** supermop has joined #openttd
16:19:00 <Alberth> andythenorth: I'd call it mining equipment
16:19:38 <benj014> Yexo - sorry wots a cfg
16:19:45 <planetmaker> andythenorth: supplies is a generic word as can be. That is intrinsically difficult to translate
16:19:55 <Zuu> benj014: A file with the .cfg extension.
16:19:59 <Yexo> benj014: just search for a file called "openttd.cfg"
16:20:13 <planetmaker> But IMHO it should not be your (main) concern, but spark the creativity of the translators
16:20:30 * andythenorth returns to current main concern
16:20:37 <planetmaker> it would either be, benj014 with your openttd.app or in ~/Documents/OpenTTD
16:20:54 <planetmaker> usually at least :-)
16:22:43 <Eddi|zuHause> what's the town size that a town accepts noise level 4 (with 'tolerant')?
16:22:53 <benj014> its with my original ttd folder
16:23:28 <Yexo> is openttd.app also there?
16:23:47 <Eddi|zuHause> a large city near a small town should influence their noise level
16:24:08 <benj014> then the 32bpp is in a new folder - called ttd2
16:24:11 <Yexo> and also directories called "save", "scenario", "downloaded_content" and "data"?
16:24:38 <Yexo> move openttd.cfg and those directories to ~/Documents/OpenTTD/
16:24:48 <Yexo> that way they are shared between all your openttd installations
16:25:20 <Yexo> also move "gm" if you have it and want the music to work
16:25:40 <benj014> yeah moved that already
16:27:13 <supermop> I am thinking of buying a bonsai tree.
16:27:31 <supermop> I was reflecting on how it is similar to my current long running game
16:29:25 <Yexo> benj014: and if you download a few newgrfs via the online content system in your 32bpp version, do those show up?
16:29:51 * andythenorth thinks mail in YACD is much like real life
16:30:02 <andythenorth> a postal service is only truly useful if every node is connected
16:30:24 <benj014> no :-( - i go onto new grfs .. look for new content but nothing there
16:30:25 <supermop> does intra-city bus and metro service work in yacd?
16:30:34 <andythenorth> better than before
16:32:13 * andythenorth wishes towns didn't shrink when serviced
16:32:24 <andythenorth> I thought I raised a FS about that months ago, but can't find it
16:32:45 <supermop> people using your great service to get the hell out of town
16:32:47 <Rubidium> might it be the town newgrf you're using that's causing that?
16:33:15 <andythenorth> providing service causes the town to start rebuilding, but it rebuilds with smaller buildings
16:33:29 <andythenorth> I can reproduce it I reckon
16:33:43 <andythenorth> it seems worse < 1900
16:33:53 <benj014> and then on the 32bpp the GFX graphic option also is not there
16:33:53 <andythenorth> and it seems worse with ships, but can't be sure
16:34:09 <supermop> everyone migrating away, call it realism
16:34:19 <Yexo> <benj014> and then on the 32bpp the GFX graphic option also is not there <- which gfx graphic option?
16:34:38 <Yexo> benj014: where did you download your 32bpp version? what is the version number?
16:36:01 <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
16:36:06 <andythenorth> but I didn't find an obvious answer
16:36:17 <benj014> on my original game - in game options i can choose the graphics set - GFX gives me better looking roads and tracks etc
16:37:30 <Yexo> benj014: again, which version is your 32bpp build?
16:37:53 <Yexo> just giving a link to the location you downloaded it from is also ok
16:38:12 <benj014> got it from www.lemonamiga.com - for mac's - version r9538-32bpp
16:38:37 <Yexo> that's 4 year old or something like that
16:38:48 <benj014> oh thats the only mac one i could find
16:39:01 <andythenorth> ^^^^ basically the large blocks of flats are replaced with smaller buildings
16:39:03 <Yexo> it'll be hard to find any newgrfs that work in that version
16:41:38 <planetmaker> andythenorth: that's just the normal fluctuation
16:41:45 <planetmaker> replace one house by another, that's it
16:41:49 <andythenorth> planetmaker: I think it's unhelpful
16:41:57 <andythenorth> but got to go :)
16:42:02 *** andythenorth has left #openttd
16:43:13 <benj014> so do i just down load the ones for mac ?
16:43:36 <benj014> and then what do i do with them ? sorry im not the most techincal person
16:43:53 <Yexo> you extract the zip and run whatever you find inside
16:46:38 <benj014> so take it i have to copy all the data folders and the gm again
16:47:11 <Yexo> as long as they are in ~/Documents/OpenTTD/ they can be used by every version of OpenTTD you install
16:47:24 <planetmaker> if you kept it in ~/Documents/OpenTTD you can keep it forever for all versions
16:47:36 <planetmaker> at least which exist so far ;-)
16:54:59 <benj014> yay got it workin .. thank you very much
16:55:22 <supermop> Ok, weather is too nice, I am going outside
16:56:22 <ndh> there's no list window with all waypoints in the game, is there?
16:57:18 <Yexo> benj014: your post on the forum was removed because on www.lemonamiga.com it's not clear where to find anything related to openttd
16:57:38 <Yexo> also next time please state more clear was you actually tried and _what exactly_ does not work
16:58:40 <benj014> found new trains on www.amitrains.co.uk wot do i do with the down loads ... sorry yexo i will try to be more specific
16:58:56 <welshdragon> benj014, they're not for OpenTTD
17:00:19 <benj014> so you know when people say they have made a new set of trains on the forums .. can they be found in NewGRFs ?
17:00:48 <Yexo> usually those same people will also upload a grf file to the forums
17:19:57 * Zuu just gave CluelessPlus a slightly more human behaviour by limiting new connections to be constructed near existing ones.
17:20:48 <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.
17:22:16 <Zuu> So the question is, shall the AI default settings be for AI battles (no limit) or for humans (limits on)
17:22:56 <Zuu> The AI without limits is about 40-60% better than the limited one.
17:23:49 <Zuu> (or if it was even 128x2048)
17:27:59 * Zuu decides to have the limit enabled for easy, medium and disabled for hard and custom. Most AI-battles will probably use custom dificulty.
17:31:52 <planetmaker> I wonder how many games actually are rather custom difficulty over one of the other difficulties
17:32:22 <planetmaker> Zuu: I'd choose one option for all difficulty levels
17:32:40 <planetmaker> makes it easier to configure
17:33:07 <planetmaker> IMHO nothing is worse, if a behaviour changes, just because I changed something somewhere totally unrelated ;-)
17:33:17 <planetmaker> (without need for that behaviour change, of course)
17:34:10 <planetmaker> unless you 'unexpose' it and just include it in the difficulty setting
17:34:14 <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.
17:35:29 <planetmaker> Well, yes. But that would come to me at a surprise, if the AI behaviour other than 'difficulty' changes with difficulty
17:36:21 <planetmaker> though maybe not, but... feels at least initially slightly awkward
17:37:38 <Zuu> I would say the AI is easier if it does have some kind of fog-of-war limitation than not.
17:43:50 *** tokai|mdlx has joined #openttd
17:45:42 <CIA-1> OpenTTD: translators * r22404 /trunk/src/lang/brazilian_portuguese.txt:
17:45:42 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:45:42 <CIA-1> OpenTTD: brazilian_portuguese - 4 changes by Tucalipe
17:47:48 *** DanMacK has joined #openttd
17:49:47 *** douknoukem has joined #openttd
17:57:45 <Eddi|zuHause> Zuu: isn't there an AI intelligence setting for such stuff?
17:58:48 <Eddi|zuHause> i would say most people play custom...
18:00:04 <Zuu> But I guses there is at least some that just want to set the dificulty level and go.
18:00:42 <Zuu> (I know there are vast amount of settings in adv. settings that don't change when you change dificulty.)
18:03:12 <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.
18:04:31 <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.
18:07:19 *** andythenorth has joined #openttd
18:32:01 <Eddi|zuHause> Zuu: not all things that are supported are a good idea...
18:37:25 <andythenorth> planetmaker: the town growth could be normal fluctuation
18:37:41 <andythenorth> it's possible that I only notice the ones that shrink, and not the ones that grwo
18:37:48 <andythenorth> like confirmation bias
18:44:01 <planetmaker> I suppose so, yes
18:44:35 <andythenorth> I think there's a problem though
18:44:44 <andythenorth> I'd have to read src I guess
18:48:46 <andythenorth> YACD can switch amounts-per-destination for industry cargo quite brutally
18:50:09 *** fonsinchen has joined #openttd
19:01:19 *** andythenorth_ has joined #openttd
19:14:06 <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
19:14:20 *** ar3k is now known as ar3kaw
19:14:25 <Yexo> so there really is no need to handle the difficulty level separately in an AI
19:14:26 <CIA-1> OpenTTD: rubidium * r22405 /trunk/src/ (35 files in 3 dirs): -Document: some more "random-ish" tidbits
19:18:41 *** andythenorth has joined #openttd
19:31:33 * andythenorth needs to change FIRS to support YACD
19:41:40 <devilsadvocate> andythenorth: FIRS already works with YACD, doesnt it?
19:41:55 <andythenorth> not very well in some respects
19:41:56 <devilsadvocate> there are some wierd bits, but in general it seems to be ok
19:42:08 <devilsadvocate> the major issue is stuff like engineering supplies
19:42:22 <devilsadvocate> but even that can sort of be handled
19:42:29 <andythenorth> the split of primary cargo production makes some routes almost impossibe
19:42:52 <andythenorth> and I have an issue with secondary industry closing that isn't YACD specific, but is worse with YACD
19:43:59 <devilsadvocate> i probably never had that issue since my primary industries always supplied a single secondary industry
19:44:16 <devilsadvocate> it takes some time to switch, but in general its ok
19:44:55 <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
19:46:21 <andythenorth> there's a lot of people doing that it seems
19:47:10 <devilsadvocate> thats the only way to get the primary to stay open
19:47:39 <devilsadvocate> they take too little supplies at a time, and cargodist makes it a bit... harder
19:47:53 <andythenorth> I always play with primary closure off
19:47:59 *** Twerkhoven[L] has joined #openttd
19:48:18 <andythenorth> I provide the option for people who like the challenge of primary closure, but it bugs me
19:49:09 <devilsadvocate> i've found that doing that (stations far away, smallest trucks available pacing deliveries) works almost always
19:50:09 <devilsadvocate> that usually means the supplies routes operate in the red, but thats fine since the primaries more than pay for them
19:50:43 <devilsadvocate> and the manufacturing sites for the supplies always have wierd stations on them, with 20 or 30 tiny platofrms
19:51:28 <Eddi|zuHause> feature request: in the vehicle list, make right click do the same as in depot: view statistics about capacity
19:52:06 <CIA-1> OpenTTD: rubidium * r22406 /trunk/ (33 files in 7 dirs): -Document: some more "random-ish" tidbits
19:52:49 <andythenorth> devilsadvocate: that gameplay is fun? It doesn't annoy you?
19:53:25 <devilsadvocate> andythenorth: well, i like intricate networks
19:53:35 <devilsadvocate> every so often it, um, breaks
19:53:58 <andythenorth> so long as it's fun ;)
19:54:00 <devilsadvocate> one train stopping at the wrong station totally messes up cargodist
19:54:14 <devilsadvocate> but otherwise its fun
20:04:21 <CIA-1> OpenTTD: rubidium * r22407 /trunk/src/ (driver.cpp driver.h): -Document: the "root" driver related stuff
20:11:10 *** Biolunar has joined #openttd
20:11:21 <Eddi|zuHause> what's DB Regio doing with diesel engines?
20:11:39 <Eddi|zuHause> i'd assumed DB Cargo would rather use those
20:12:16 *** Devroush has joined #openttd
20:22:49 *** Absurd-Mind has joined #openttd
20:31:47 *** tokai|noir has joined #openttd
20:35:23 *** Cybertinus has joined #openttd
20:46:52 <CIA-1> OpenTTD: yexo * r22408 /trunk/src/ (newgrf.cpp newgrf.h): -Cleanup: remove unused variable GRFFile::sprite_offset
20:49:04 *** douknoukem has joined #openttd
20:52:35 *** andythenorth has left #openttd
21:02:31 <CIA-1> OpenTTD: yexo * r22409 /trunk/src/newgrf.cpp: -Fix: [NewGRF] make sure the action2 ID of a generic feature callback is valid
22:14:25 *** Cybertinus has joined #openttd
22:27:33 *** lasershock` has joined #openttd
23:41:55 *** Xaroth_ has joined #openttd
continue to next day ⏵
