Back to Home / #openttd / 2011 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2011-08-06

---Logopened Sat Aug 06 00:00:14 2011
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:03-!-Kurimus [] has joined #openttd
01:15-!-a1270 [] has joined #openttd
02:11-!-bodis [] has joined #openttd
02:13-!-sla_ro|master [slaco@] has joined #openttd
02:26-!-andythenorth [] has joined #openttd
02:26<andythenorth>none of my grfs build
02:27<Rubidium>new grfcodec/nforenum on a BE architecture?
02:27<andythenorth>just about 5 minor arsey things
02:28<andythenorth>I didn't copy grfcodec over
02:28<andythenorth>I can't build it because I don't have boost
02:28<andythenorth>I haven't symlinked nmlc
02:28<andythenorth>other crappy stuff
02:28<andythenorth>I knew I should have rsynced /bin and other such
02:29*andythenorth </moaning>
02:35-!-Cybertinus [] has joined #openttd
02:36-!-xahodo [] has joined #openttd
02:43<andythenorth>so where should I symlink things grfcodec etc from?
02:43<andythenorth>it's apparently bad to do it from /bin
02:44<andythenorth>should I use /usr/bin?
02:46<andythenorth>or /opt?
02:51-!-KouDy [~KouDy@] has joined #openttd
02:52*andythenorth permits himself first "yay" of today
02:52<andythenorth>each day should have >1 "yays" in it
02:52<andythenorth>a zero-yay day is a bad day
02:52<andythenorth>but a day that has too many "yays" is a day that contained too many problems
02:52<duckblaster>about 5 is good?
02:53<andythenorth>3-7 is probably about right
02:53<andythenorth>20 would certainly be too many
03:11-!-Wolf01 [] has joined #openttd
03:12<andythenorth>planetmaker: hello
03:13<andythenorth>can you run the buildout for nml?
03:13-!-bodis [] has quit [Remote host closed the connection]
03:20<@planetmaker>I never tried so far
03:21<@planetmaker>how would I do that?
03:21<@planetmaker>or you mean... the CF?
03:28<andythenorth>planetmaker: in your nml checkout - run 'python' then 'bin/buildout'
03:28<andythenorth>it's all failing horribly for me :P
03:29<@planetmaker>uhm... that'll install NML somewhere, won't it?
03:30-!-pugi [] has joined #openttd
03:30<@planetmaker>hm, no.
03:30<@planetmaker>it can't
03:30<andythenorth>this is a fun morning :(
03:30<andythenorth> is broken
03:30<andythenorth>PIL won't install
03:31<andythenorth>setuptools can't be upgraded on Snow Leopard
03:31<andythenorth>Snow Leopard apparently ships with a broken version of python 2.6.1
03:31<@planetmaker>regressions work here
03:31<andythenorth> do you recall how you got PIL to install?
03:32<andythenorth>apparently compiler flags are set wrong - OS X is trying build PIL for PowerPC
03:32<andythenorth>(according to the internet)
03:32<@planetmaker>port install py-pil or something
03:32<andythenorth>planetmaker: you have the output I want :P
03:33<andythenorth>so it's clearly possible
03:33<andythenorth>you have 10.6.8?
03:33<andythenorth>and python 2.6.1?
03:34-!-Kurimus [] has quit [Ping timeout: 480 seconds]
03:36-!-Kurimus [] has joined #openttd
03:44-!-DayDreamer [~DayDreame@] has joined #openttd
03:46-!-DayDreamer [~DayDreame@] has left #openttd []
03:54-!-Alberth [] has joined #openttd
03:54-!-mode/#openttd [+o Alberth] by ChanServ
03:54<andythenorth>that was an *arse*
03:56<andythenorth>don't use OS X :P
03:56<andythenorth>now I broke my mercurial
03:59<@planetmaker>sudo port install mercurial ;-)
04:00-!-andythenorth is now known as Guest4911
04:00-!-andythenorth_ [] has joined #openttd
04:00-!-andythenorth_ is now known as andythenorth
04:03-!-Neon [] has joined #openttd
04:04-!-Guest4911 [] has quit [Ping timeout: 480 seconds]
04:21-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
04:27*andythenorth ponders
04:28<andythenorth>there is *zero* chance that we'd trust a newgrf author to mark some parameters as "safe to change during game" (via a14)?
04:28<andythenorth>for example, running & purchase costs
04:28<andythenorth>or climate availability of vehicles
04:29<Rubidium>climate availability is not safe by definition I'd say
04:29<Rubidium>after all, it allows removing vehicles from a climate
04:29<andythenorth>only from the buy menu
04:29<andythenorth>it's the route I use to deprecate vehicles without breaking savegame
04:29<@planetmaker>climate availability only removes it from purchase list afaik
04:30<andythenorth>but would we trust newgrf authors to mark up some items as 'safe'?
04:30<Rubidium>so it depends on the implementation; I assumed you'd just jump over the 'not for this climate' vehicles
04:30<@planetmaker>no. People err
04:30<@planetmaker>Rubidium: not action7. The availability property
04:31*Alberth ponders a newgrf test environment
04:31<andythenorth>I figured it would be unsafe :P
04:31<Rubidium>planetmaker: to me it'd be easier to just set the 'all climate available' bits for all vehicles and then jump over the vehicles that are not 'selected' for a particular climate
04:32<andythenorth>then you'd break savegames :P
04:32<andythenorth>and people would tell you off
04:32<@planetmaker>it's easy but not update-safe ;-)
04:33<@planetmaker>same as it was easy for isr to re-shuffle tileIDs from somewhere between 0.6 and 0.8
04:33<@Alberth>it is easy and wrong :)
04:35<@planetmaker>I try to be cautious with the word 'wrong' - but it's definitely not "best practise"
04:35<Rubidium>there you see that a 'noob' in NewGRF coding can easily make something that'd break, but he saw that andythenorth marked it as safe so he does as well. Because... if the experienced dev says it's safe, then the same feature should be safe in his NewGRF as well.
04:35<andythenorth>that's what I figured :P
04:35<andythenorth>I am still poking at things that cause you to have to restart your game
04:35-!-Juo [] has quit [Read error: Connection reset by peer]
04:36<Rubidium>though it would be interesting to know what things 'you' (plural) would like to be able to change
04:37<andythenorth>'safe' things <- that much is obvious
04:37<@planetmaker>- update to newer version of newgrf
04:37<andythenorth>^ assuming action 14 says it's ok
04:37<@Alberth>add new grfs that were forgotten
04:37<@planetmaker>yes, that's what we have comp. version for
04:37<andythenorth>Alberth: too complicated
04:38<@planetmaker>forgotten as in 'missing vehicles' mostly
04:38<andythenorth>update is valid - especially where the newgrf has bugs
04:38<andythenorth>adding can never happen
04:38<andythenorth>unless the spec is changed
04:38<andythenorth>disable disabling, then talk about it :P :)
04:38<@planetmaker>andythenorth: updating the version is the same
04:38<@Alberth>or we detect 'bad' things in some way
04:38<@planetmaker>FIRS for example queries TTRS version and changes behaviour accordingly
04:38<andythenorth>true. only if the author is toxic though
04:39<andythenorth>and if it's FIRS :P
04:39<@planetmaker>thus it's of the same level of un-safe-ness
04:39<andythenorth>good call
04:39<Rubidium>well... ;)
04:39<Rubidium>then just make the test environment for NewGRF changes ;)
04:39<andythenorth>so those examples are same as every other time we debated it
04:39<andythenorth>safe things should include:
04:39<andythenorth>- run & buy costs
04:39-!-perk11 [] has joined #openttd
04:40<andythenorth>- climate availability
04:40<andythenorth>actually none of the above
04:40<andythenorth>newgrf A can check the value of parameters in newgrf B?
04:40<andythenorth>in which case all bets are off
04:41<andythenorth>so no deal
04:41<andythenorth>end of discussion? :P
04:41<@Alberth>perhaps it is easier to start at the other end, what can you do that is always safe?
04:41<Rubidium>no, only one answer to the discussion
04:41<andythenorth>changing *anything* is like lighting the fuse on a bomb
04:42<andythenorth>no newgrf author can determine that their grf is 'safe'
04:42<andythenorth>because it is (almost) indeterministic
04:42<andythenorth>due to combination of other grfs
04:42<@Alberth>duh, that's what happens if you give people atomic bombs to play with
04:42<Rubidium>"refactor OpenTTD so it can load a second set of NewGRFs; after that use a heuristics whether anytime changed for the 'bad'. If it is proven to not cause anything bad: allow making the changes."
04:42<andythenorth>or - similar - handle disabling better
04:43<andythenorth>which might require same approach
04:43<andythenorth>i.e. dry-run the change; if any newgrf disables itself, forbid the change
04:43<Rubidium>andythenorth: but... that might not be 'for the bad'
04:43<@planetmaker>that might be the only call we really have, a dry-run sandbox for testing
04:43<@Alberth>Rubidium: refactor such that we create a 2nd map from the first one, copying/creating things from scratch?
04:44<andythenorth>hmm clone pattern
04:44<Rubidium>e.g. if one such NewGRF is a translation NewGRF. Disabling that because the new version of the translated NewGRF contains said translation is not bad.
04:44<andythenorth>forbid starting / updating any game with disabled newgrfs
04:44<@Alberth>but we have zillions of global variables :(
04:44<Rubidium>Alberth: you don't need to do it for the whole map
04:44<Rubidium>just load the spec variables.
04:45*andythenorth has like...5 line idea
04:45<@Alberth>hmm, what about making a kind of contract with the newgrf? "I will behave in this and this way" ?
04:45<Rubidium>if vehicle length changes: return bad, if vehicle is removed: return bad, if ...
04:45<andythenorth>currently the direction we're heading is that the community will start turning on newgrf developer tools
04:46<@Alberth>it still needs checking :(
04:46<andythenorth>which means I have to start handling invalid bug reports again
04:46<@Terkhen>good morning
04:46<@Alberth>moin Terkhen
04:46<@planetmaker>hello Terkhen
04:46<andythenorth>and the suggestion to forbid starting game with disabled grfs was nixed by some people here who want to use same grf config in every game
04:46<andythenorth>what if starting with disabled grfs was forbidden, unless developer tools are on
04:47<@planetmaker>that is IMHO not sufficiently justified
04:47<@Alberth>andythenorth: disabled newgrfs are not a problem. they are clearly labeled as 'i am not doing anything'.
04:47<andythenorth>I guess we disagree about them being a problem
04:47<andythenorth>I find them a problem
04:48<andythenorth>I can't prove everyone does :P
04:49<@Alberth>I can see the case that you want the same configuration every time. It takes ages to make it all working properly. I invariably forget some newgrf which I of course discover only after starting
04:49<andythenorth>what happens if I update my newgrf with bananas, then load a savegame
04:49<andythenorth>and grf A is updated, so grf B disables itself?
04:49<andythenorth>do I lose my game?
04:50<@Alberth>save game itself has the version
04:50-!-Juo [] has joined #openttd
04:50<@Alberth>so it loads the old one
04:50<@Alberth>(which is why people want to be able to update their newgrfs in the game)
04:50<andythenorth>and if I manually delete the old one?
04:51<@Alberth>then you have a missing newgrf file which you can pull from bananas, or the game doesn't run (I think, I'd have to test that)
04:52<@Alberth>but here you get the compability stuff into play, which I know nothing about :)
04:52<@planetmaker>The game will load a compatible NewGRF
04:53<@planetmaker>the one with the newest version - or a random one with the newest version
04:53<@planetmaker>only if no compatible newgrf is found it'll fail to load
04:53<andythenorth>in which case - boom
04:53<@planetmaker>not fail but resist ;-)
04:53<andythenorth>grf A is modified in some subtle way, grf B disables itself
04:53<@planetmaker>of course, can happen
04:54<andythenorth>FIRS will probably do that with TTRS if I try hard enough
04:54<@planetmaker>it *should* not be possible - or it's a min_version error in TTRS
04:54<andythenorth>*because* you've provided TTRS in a proper way
04:55<andythenorth>I reckon I could code this case if I could be bothered :P
04:55<@planetmaker>version downgrade is never considered compatible
04:56<andythenorth>recently someone else suggested a solution I thought was nice
04:57<andythenorth>if there are disabled grfs when starting game, show the newgrf window before map gen
04:57<andythenorth>giving player chance to address issue
04:57<andythenorth>dunno if that's necesary or sufficient
04:57<@Alberth>or even possible
04:58<@Alberth>ie how do you decide about disabledness based on climate at that point?
04:58<andythenorth>you know the climate?
04:58*andythenorth is guessing now
04:59<@planetmaker>well, on map generation one does
04:59<@planetmaker>though... you only know about disabled newgrfs after the map is initialized - as newgrf initialization is part of it
04:59<@Alberth>depending on when "before" exactly is
04:59-!-jpx_ [] has quit [Quit: Leaving.]
04:59<andythenorth>even if possible, seems like a sticking plaster
04:59<@Alberth>but I fear it is after the map is already generated
05:00<@planetmaker>I'm not sure... you need to know newgrfs during map creation
05:01<andythenorth>removing 'disable self' from newgrf spec is unworkable
05:02*Alberth believes the newgrf spec needs rigorous cleanup before even trying to solve things in the program
05:02-!-frosch123 [] has joined #openttd
05:02<andythenorth>Alberth: godwin :P
05:02<andythenorth>that's where this conversation always goes
05:02<andythenorth>and yet we've established that cleaning up newgrf spec is also unworkable :P
05:02<andythenorth>for legacy support
05:02<andythenorth>so we're stuck
05:03<@Alberth>there are 2 ways out of it.
05:03*andythenorth thinks of a third :P
05:03<@Alberth>1. defuse newgrfs
05:03<@Alberth>2. treat newgrfs as unsafe in the program
05:03<andythenorth>2 is the current situation
05:03<@Alberth>no, they are treated as 'safe', that's why accidents happen
05:04<@Alberth>ie we trust what you say
05:04<andythenorth>but we've put a lock on them
05:04*andythenorth just put a child lock on the cupboard where the mains fuses are
05:04<duckblaster>new spec, different format, but keep newgrf support?
05:04<duckblaster>as legacy
05:05<andythenorth>same issue would reappear, but we'd incur *lots* of work to get there
05:05<@Alberth>'keep newgrf as legacy' means you have to build & maintain 2 openttd programs. Unworkable
05:05<andythenorth>doesn't solve the issue
05:05<andythenorth>it's valid for a newgrf to disable itself
05:05<andythenorth>and therefore this is conceptually unresolvable
05:05<duckblaster>keep loader part only?
05:05<duckblaster>or is it too intergrated
05:06<@Alberth>it is *completely* integrated
05:06<duckblaster>rewrite openttd in c++ and object oriented system?
05:06<@Alberth>openttd just copies the data straight out the newgrf, and uses all data as trusted values
05:07*andythenorth doesn't particularly *want* to allow things like adding newgrf. The current locked-down situation is ok-ish
05:07<@Alberth>duckblaster: how does that solve things?
05:07<andythenorth>but the user experience sucks
05:07<duckblaster>so newgrf is just a memory dunp?
05:07<duckblaster>exact copy of memory?
05:07<@Alberth>in a bit nicer format, but mostly
05:08<@Alberth>ie some wrapper stuff is around it to know where to put what
05:08<andythenorth>you can rewrite it in Whatever Framework Is Flavour Of The Month, but the issue will persist
05:08<@Alberth>so it is not straight memory dump
05:08<duckblaster>"in a bit nicer format"? so it goes through something to get frmo disk to memory?
05:08<duckblaster>insert new loader there
05:08<andythenorth>the only solution I can see is proper domain
05:08<andythenorth>each newgrf declares explicitly which features it wishes to change
05:09<@Alberth>duckblaster: loading is not the problem, trusting the data is
05:09<andythenorth>only one newgrf can make changes to that features
05:09<andythenorth>newgrfs have to bid in an auction
05:09<duckblaster>what are the things that crash?
05:09<andythenorth>so only one newgrf can change houses
05:09<andythenorth>only one newgrf can change industries
05:09<andythenorth>only one newgrf can change cargos
05:10<@Alberth>duckblaster: everything can crash if you feed it values you trust blindly
05:10<andythenorth>vehicles are pooled, so probably safe
05:10<duckblaster>with sensible values i mean
05:10<duckblaster>if it's changed mid game
05:10<andythenorth>even with this explicit domain idea, the problem persists
05:10<andythenorth>basically I think OzTrans actually is doing it write
05:10<andythenorth>write / right /s
05:11<andythenorth>instead of newgrf list, you get to choose one newgrf
05:11<andythenorth>that's it
05:11<andythenorth>problem solved
05:11<duckblaster>not going to work
05:11<duckblaster>firs + fish + aviator + trains
05:11<@Alberth>it is at least clearing up the mess of finding out what newgrfs you need to use :p
05:12<andythenorth>duckblaster: you don't get that choice in the new system
05:12<duckblaster>with good newgrfs, if they are changed mid game, what could cause a crash?
05:12<andythenorth>you pick OzTrans.grf
05:12<andythenorth>or andythenorth.grf
05:12<andythenorth>or pikka.grf
05:12<andythenorth>or opengfx+.grf
05:13<andythenorth>that's it
05:13<@Alberth>duckblaster: the problem is how to recognize 'good'
05:13<andythenorth>the crash problem is a straw man
05:13<andythenorth>so the game crashed. that sucks. but you have autosave
05:13<duckblaster>firs, fish, aviators, other big popular ones
05:14<@Alberth>what are the units for airport noise level?
05:14<andythenorth>what's annoying is playing a game for an hour before discovering it's broken due to changed (or missing) newgrfs
05:14<@Alberth>ie what is a 'sane' value for that property?
05:14<duckblaster>why would it crash when switching mid game? what would cause the crash?
05:14<duckblaster>missing vehicles?
05:15<andythenorth>so options
05:15<andythenorth>(1) ditch newgrf spec, try a new one (same problem re-emerges)
05:15<andythenorth>(2) do nothing, it's all ok
05:16<andythenorth>(3) allow only one newgrf to be loaded
05:16<andythenorth>(4) grftopia
05:16<duckblaster>(5) make a newgame?
05:16*Alberth is very tired of this discussion
05:17<andythenorth>it's more of a monologue
05:17*andythenorth talking to /me
05:18<duckblaster>anyone interested in a rct clone?
05:18*Alberth is
05:18<duckblaster>theme park builder 3d
05:18<duckblaster>not done
05:18<@planetmaker>Alberth: arbitrary units for noise level
05:18*Alberth doesn't want 3d, it is not even working at my machine
05:19<@Alberth>planetmaker: useful :)
05:19*Alberth picks random number 5
05:19<@planetmaker>I'd take... ^
05:19<andythenorth>newgame or New game?
05:20<@planetmaker>why open? :-P
05:21<@Alberth>open is good, it's 2d isometric then :p
05:21<@planetmaker>hm... for separate building sprites I cannot choose separately "show / no show" in sprite layouts?
05:21<@planetmaker>we should call it DttNepo
05:22-!-Progman [] has joined #openttd
05:22<@planetmaker> <-- the last two building definitions in that layout
05:23-!-lugo [] has joined #openttd
05:23<@planetmaker>if the first "hide_sprite" returns "true" then the 2nd will always return "true", too, thus be hidden
05:24<andythenorth>you're trying to make the perfect layout with transparency on?
05:24-!-Alexdddd [] has joined #openttd
05:24<@planetmaker>no. the "hide_sprite" doesn't deal with transparency
05:24<@planetmaker>it allows to decide "show yes/no" depending on parameter
05:24*andythenorth is a dunce at nml :P
05:25<@planetmaker>transparency is handled by "always_draw" ;-)
05:25<andythenorth>one day I will learn this magic
05:25<Alexdddd>This a developer chat channel?
05:25<@planetmaker>but I just try to figure out what 'hide_sprite' relates to
05:25<@planetmaker>this is a general channel related to OpenTTD, Alexdddd
05:25<@planetmaker>but yes, developers are also sometimes here
05:26-!-duckblaster [] has quit [Ping timeout: 480 seconds]
05:26<Alexdddd>Just found Open TTD - played the original years ago
05:26<Alexdddd>Fond memories :p
05:27<Alexdddd>And IRC too... havent used this for years either ;)
05:29-!-Alexdddd [] has quit [Quit: ajax IRC Client]
05:30*andythenorth plays dice wars
05:33-!-andythenorth is now known as Guest4914
05:33-!-andythenorth_ [] has joined #openttd
05:33-!-andythenorth_ is now known as andythenorth
05:33-!-Biolunar [] has joined #openttd
05:34<@planetmaker>andythenorth: solving this issue would solve auto-fencing for arbitrary slopes ;-)
05:35<andythenorth>today is not a good day for learning nml
05:39<@planetmaker>frosch123: my understanding is correct that I can several parent sprites in one sprite layout, right?
05:39-!-Guest4914 [] has quit [Ping timeout: 480 seconds]
05:41*Hirundo misses a verb
05:41<andythenorth>planetmaker: wrt FIRS - 37 errors? Do you see those?
05:41*andythenorth is checking it's not a localised issue
05:42<andythenorth>unreferenced sprite blocks mostly
05:44<Hirundo>andythenorth: those errors (warnings, actually) are relatively harmless, as those unused sprites aren't copied to the actual grf
05:44-!-KouDy [~KouDy@] has quit [Quit: Leaving.]
05:45<Hirundo>It's just a hint that your nml contains dead code
05:45-!-xahodo [] has quit [Quit: I'm melting...]
05:46<andythenorth>Hirundo: thanks
05:46<andythenorth>they can mask real errors though :)
05:47<Eddi|zuHause>[06.08.2011 08:43] <andythenorth> so where should I symlink things grfcodec etc from? <-- at least on linux, you usually do manual changes to the system in /usr/local/bin, sometimes also ~/bin is allowed
05:48*Alberth use ~/bin
05:48<andythenorth>seems that /opt/local is acceptable on OS X
05:48<andythenorth>thanks though
05:49-!-andythenorth is now known as Guest4916
05:49-!-andythenorth_ [] has joined #openttd
05:49-!-andythenorth_ is now known as andythenorth
05:52<frosch123>planetmaker: yes, every parent sprite is a bounding box
05:53<frosch123>usually you have one bounding box per industry tile, and two per traversable station tile (one in front and one behind the train)
05:53<frosch123>you can use more, but usally grfauthors just mess up :p
05:53<frosch123>why do you need multiple bounding boxes?
05:55<@planetmaker>I want to separately hide / not hide the fences on the adjacent tile's object type
05:55<@planetmaker>+depending on
05:56<@planetmaker>thus my idea was to use a separate building sprite for each fence
05:56<@planetmaker>then I can in an adv. sprite layout hide / not hide it. Or so my idea
05:56<frosch123>well, basically you can do all that stuff with child sprites, just that the positioning of child sprites is relatively to the topleft of the parent sprite, i.e. it depends on the size, relx and rely of the parent sprite
05:56-!-Guest4916 [] has quit [Ping timeout: 480 seconds]
05:57<frosch123>however, for airports fences cause glitching between aircraft and foundation
05:57<@planetmaker>I'm currently doing NewObjects
05:57<frosch123>that's why ottd draws them as ground sprites
05:58<frosch123>planetmaker: if you want generic code, make all object use the bouding box at position <1,1,0> with size <14,14,maxz>
05:58<frosch123>then you can put the fences on the edges 0 and 15
05:59<@planetmaker>yes... but the hiding / not hiding is my problem. It doesn't work quite as I expect / want it to work...
06:00<@planetmaker> <-- that's the two code versions I play(ed) with
06:00<@planetmaker>one the childsprite approach, the other the building one
06:01<@planetmaker>it works perfect for the first fence, but the subsequent ones seem to be hidden, if a previous one gets hidden.
06:01-!-Pulec [] has joined #openttd
06:02<andythenorth>it remains amusing that the weight of Goods varies according to the vehicle it's travelling in :P
06:02<@planetmaker>and I at least need to make sure I understood what I can do before I start assuming it's a bug somewhere in NML or OpenTTD ;-)
06:02<frosch123>planetmaker: did you enable any transparency settings?
06:03<frosch123>smatz did some 'optimisation' that when the first sprite is invisible due to transparency settings, it will not draw the rest of the layout as well
06:03<@planetmaker>that might explain it, that's how it looks like
06:04<frosch123>try changing the 'return' in sprite.cpp:52 to a 'continue'
06:04<@planetmaker>but it looks like check first || draw first, check 2nd || draw 2nd, check 3rd || draw 3rd, check 4th || draw 4th
06:05<andythenorth>Eddi|zuHause: forklift will have generations with improving stats over time
06:05*planetmaker checks
06:05<andythenorth>so how fast at introduction (1936)
06:05<Eddi|zuHause>andythenorth: what kind of improving stats?
06:06<andythenorth>rest will be the same
06:06<Eddi|zuHause>andythenorth: but make it a new model, so autoreplace can be used.
06:06<andythenorth>nah, that's not the pattern used in HEQS
06:06<frosch123>planetmaker: <- maybe even like that
06:07<frosch123>hmm, might want to look up in the logs whether that was actually meant as optimisation
06:11<frosch123>everytime i pull a new project from devzone, i need to pull nml as well :p
06:12<frosch123>wow, ogfx-landscape takes quite long to build :o
06:12<frosch123>planetmaker: any diff i need to apply to tip?
06:14<@planetmaker>mind that you have both versions there, buildings or child sprites. Comment out the one you don't want / need
06:14<SpComb>kuuluu asiaan
06:16<@planetmaker>the fences are not supposed to be slope-aware yet
06:17<frosch123>hmm, the object gui lacks a colour string code
06:18<Rubidium>gofix ;)
06:19<frosch123>yeah, but first i want to moan about noone else mouning
06:20*planetmaker confesses to not have noticed
06:20<frosch123>planetmaker: the wind turbine?
06:20<@planetmaker>company land
06:20<@planetmaker>the "invisible" one
06:20<@planetmaker>I don't actually know why it is invisible...
06:20<frosch123>yeah, did not notice it :p
06:21<@planetmaker>but that's another thing to take care of separately
06:21<@planetmaker>frosch123: company land is best viewed with transparency = on (but not invisible)
06:23<@planetmaker>hm, mind that one of the fences (SE) is not well placed when using the 'building' approach
06:27<andythenorth>what happens if I run out of D0 texts?
06:27-!-pugi [] has quit [Read error: Connection reset by peer]
06:28<Hirundo>The world ends :P
06:28<Hirundo>How many do you currently use?
06:29<frosch123>andythenorth: use D1 to D3 texts :p
06:29<Eddi|zuHause>that's only 1024 strings
06:30<andythenorth>works for me :P
06:31*andythenorth assumes a forklift always costs same, no matter hp/speed
06:31<andythenorth>Eddi|zuHause: want a test grf?
06:33<@Alberth>where is the list of airport tile types to use for override? (property 8 of action 0) ?
06:35<@Alberth>although they are probably of no use anyway :p
06:36-!-perk11 [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
06:36<Eddi|zuHause>andythenorth: not in the mood for testing right now
06:36*andythenorth thinks the audience participation is lacking :P
06:37<frosch123>planetmaker: looks like a bug in ottd
06:37<@planetmaker>he... thanks for looking into it :-)
06:38<frosch123>yeah, works now (except for se)
06:38<@planetmaker>I assume you already meanwhile have an idea where?
06:39<@planetmaker>except for SE? How is that different?
06:39<frosch123>it draws the fence on the ne edge
06:39<frosch123>didn't you said that yourself?
06:39<@planetmaker>:-D I understood SE = scenario editor :-)
06:40<frosch123>oh :)
06:40<andythenorth>Eddi|zuHause: do you recall if you tested this?
06:40<@planetmaker>it draws the NW fence twice
06:40<@planetmaker>you see it in transparent view
06:40<@planetmaker>it's darker
06:40<andythenorth>I'm thinking of applying it, but I am not in the mood for testing it either :P
06:40<andythenorth>i.e. I'm not sitting watching trams go round for 30 mins :D
06:41<andythenorth>so I'm inclined to just trust your code
06:41<@planetmaker>andythenorth: setup a webcam and stream it. Someone will watch :-P
06:41<frosch123>planetmaker: well, if the nw is hidden due to adjacent tile, the se one is still drawn at nw
06:43<andythenorth>planetmaker: how about I just ship it :D
06:43<andythenorth>someone else found the original bugs
06:44<andythenorth>frick: patch: **** Only garbage was found in the patch input.
06:44<Eddi|zuHause>andythenorth: curl -L
06:45<andythenorth>doesn't resolve it :(
06:45<andythenorth>my mistake
06:45<andythenorth>attachment != download in redmine
06:46<@Alberth>andythenorth: but causing a traffic jam should be simple to do
06:46<andythenorth>planetmaker: wtf fast forward on snow leopard?
06:47<andythenorth>maybe it's a bug in a specific ottd version
06:47<andythenorth>hyper-fast :P
06:47<Eddi|zuHause>andythenorth: i don't seem to have an actual game using these changes, but i did test them in a test game
06:47<@planetmaker>andythenorth: hu?
06:47<andythenorth>super fast ffwd
06:47<frosch123>planetmaker: try again
06:47<CIA-2>OpenTTD: frosch * r22721 /trunk/src/newgrf_commons.cpp: -Fix (r22518): Conditionally hiding a sprite caused subsequent items of the spritelayout to use wrong registers.
06:47<andythenorth>I'll see if it's specific to an ottd rev later
06:48<Eddi|zuHause>andythenorth: fast forward is always as fast as your computer can go
06:48<andythenorth>in which case, this computer is insanely faster than the previous
06:48<andythenorth>despite only marginal nominal spec difference
06:48<Eddi|zuHause>depends on map size, amount of vehicles, etc.
06:48<@planetmaker>and window size
06:49<@Alberth>and video driver performance
06:50<@planetmaker>\o/ cookie and / or cold beverage for frosch :-)
06:51<Eddi|zuHause>meh, i can't get newgrf-information from a savegame if it has "invalid chunksize" or "newer version"...
06:51<Eddi|zuHause>how about a "game developer" setting? ;)
06:51<andythenorth>I don't have lzma
06:51<@planetmaker>Eddi|zuHause: it's called 'developer'
06:51*andythenorth now hates moving computer
06:52*Alberth gives andythenorth a hammer and some nails
06:52<Eddi|zuHause>planetmaker: i think that is mislabeled
06:53<@planetmaker>lool @ Alberth :-)
06:53<Eddi|zuHause>planetmaker: afair that setting just sets redirection of output
06:53<andythenorth>I should have just copied what I thought I should copy, instead of listening to others :P
06:54<@planetmaker>+ cheat shortcuts iirc
06:55<andythenorth>planetmaker: I assume you can compile ottd on snow leopard?
06:55<andythenorth>no surprise - I can't :P
06:55<andythenorth>do I need to build my own gcc?
06:55<@planetmaker>of course not
06:55<@planetmaker>actually my self-built gcc does NOT compile openttd
06:56<@planetmaker>the requirements on snow leopard are no different than on tiger
06:56<@planetmaker>so it applies most probably to leopard as well
06:56<@planetmaker>you'll need of course all the deps
06:57<andythenorth>next time I'll just do a migration the correct way :(
06:57<andythenorth>this is a PITA
06:58<@planetmaker>did you do any fancy configure?
06:58<@planetmaker>if not, try ./configure --enable-universal="i386"
06:58<@planetmaker>it's not a fix, but a workaround...
06:59<andythenorth>fails, same error
06:59*andythenorth is basically an edge case
07:00<@planetmaker>maybe not. Maybe I am
07:00<Hirundo>Anyone knows, what happens if a 7E procedure call fails (no CB result is returned) in TTDPatch?
07:01<Hirundo>In OpenTTD, it's always CALLBACK_FAILED right?
07:01<andythenorth>which gcc version should I be using?
07:01-!-fire1299 [] has joined #openttd
07:01<@planetmaker>andythenorth: both, gcc4.0 and 4.2 work for me
07:01<@planetmaker>default on 10.6 is gcc 4.2
07:02<andythenorth>that's what I have
07:02<@planetmaker>maybe try a gcc_select 4.0
07:02<@planetmaker>it defaults to i386 as architecture
07:02<@planetmaker>sudo gcc_select gcc40
07:02<andythenorth>I'll try
07:02<andythenorth>first I have to get gcc_select and gcc4.0
07:03<@planetmaker>uhm... 'get'?
07:03<andythenorth>port install
07:03<@planetmaker>isn't it installed with the developer tools?
07:03<@planetmaker>forget the gcc from macports ;-)
07:03<frosch123>Hirundo: "jb .gotfn // this'll give us a semi-random value, but it's invalid to do this anyway"
07:03<@planetmaker>they don't work
07:03<@planetmaker>what does gcc_select -l tell you?
07:04<andythenorth>gcc_select: command not found
07:04<andythenorth>same with python_select actually
07:04<frosch123>Hirundo: "semi-random" as in "whatever is written in bx currently"
07:04<@planetmaker>hm, right. gcc_select is a macports thingy
07:04<@planetmaker>so install that :-)
07:04<andythenorth>yeah, I've done that
07:04<andythenorth>no dice
07:04<andythenorth>I've installed quite a bit from macports this morning that's not working
07:05<Hirundo>frosch123: that is really nice :S
07:05<@planetmaker>define "not working"
07:05<@planetmaker>gcc_select: command not found?
07:05<andythenorth>not in the path < is my best guess
07:05<frosch123>Hirundo: well, what should happen?
07:06<@planetmaker>you have to add /opt/local/bin to your search bath
07:06<@planetmaker>when using macports
07:06<andythenorth>they're in opt/local/var
07:06<frosch123>ottd just givex 0x7fff
07:06<frosch123>i.e. just some value
07:06<andythenorth>opt/local/bin is in my path but not the other
07:06<@planetmaker>which other?
07:07<Hirundo>frosch123: 0xFFFF afaik
07:08<@planetmaker>that's not needed
07:09<frosch123>Hirundo: yeah, indeed, so the only 7e result which is not 15 bits :p
07:09<Hirundo>At least, it's not a valid CB result, so I can check for that (in NML) and for example let the entire CB fail
07:09<@planetmaker>what does the output look like if you try: set | grep '^PATH='
07:09<andythenorth>my bash_profile includes this:
07:09<@planetmaker>adding it there without sourcing it doesn't help
07:09<@planetmaker>ok, it's there
07:09-!-fire1299 [] has quit [Ping timeout: 480 seconds]
07:10<@planetmaker>and: which gcc_select
07:10<@planetmaker>port list gcc_select
07:11<andythenorth>gcc_select @0.1 sysutils/gcc_select
07:11<@planetmaker>and the output of "which gcc_select"?
07:12*andythenorth checks it's not driver error
07:12<andythenorth>it's driver error
07:12<andythenorth>wrt openttd failing to compile
07:12<andythenorth>dunno wtf is going on with ports
07:13<andythenorth>but not using make mrproper was my idiocy
07:14<CIA-2>OpenTTD: frosch * r22722 /trunk/src/sprite.cpp: -Fix: Skip invisible parent and child sprites due to transparency settings using the same logic as skipping due to grf-defined invisibility.
07:14<andythenorth>how odd
07:14<andythenorth>the intel i7 is a 2x2 cpu?
07:14<andythenorth>that's unexpected
07:14<andythenorth>so I have 4 CPU meters :P
07:14<Eddi|zuHause>i have 6 cores ;)
07:15<frosch123>Eddi|zuHause: does that increase the chance for a meltdown?
07:16<Eddi|zuHause>frosch123: i have installed additional cooling
07:16<@planetmaker>just connect directly to the Saale
07:17<Eddi|zuHause>planetmaker: that's a few km away ;)
07:17<andythenorth>so the hyper-speed is not an ottd bug :P
07:17*andythenorth will now find more problems to moan about
07:17<Eddi|zuHause>andythenorth: openttd uses only one core
07:17<frosch123>Eddi|zuHause: up to two
07:17<andythenorth>still seems to be about 3x faster on ffwd
07:17<frosch123>or even three?
07:18<@planetmaker>:-) maybe for concurrent network connections and autosave
07:18<andythenorth>it's either using 2 on my box, or the OS is offloading all tasks to the other cores
07:18<andythenorth>ffwd ottd causes two cores to spike usage
07:19<@planetmaker>autosave enabled?
07:19<frosch123>well, using the sdl backend it does the drawing of the ottd internal buffer to the screen in a separate thread
07:19<Eddi|zuHause>sdl is not used on OSX
07:20<andythenorth>maybe the OS is just being smart
07:20<frosch123>and if you have a composing window manager, it might do the composing on a different core as well
07:20<@Alberth>OS may be moving ottd back and forth between cores
07:20<frosch123>andythenorth: every os needs to be at least smatz enough to deal with the crappy hardware
07:21<andythenorth>anyone working on FIRS?
07:21<frosch123>though maybe they are the same :)
07:21*andythenorth is wondering what to work on
07:21<Hirundo>if 'improving NML to make coding FIRS easier' counts as 'working on FIRS', then yes :)
07:22<andythenorth>is this a bug? Or a feature request?
07:22<andythenorth>the guy annoys me
07:26<@planetmaker>as heqs is not designed (IMHO) as stand alone set: feature request
07:28<Ammler>I guess, the guy just isn't able to distinguish the trackers...
07:29<Ammler>(and used default)
07:29<frosch123>heavy equipment for oil seeds?
07:30<frosch123>i don't think heqs is meant for any transport of organic stuff, is it?
07:30<@Alberth>andythenorth: ask clarification
07:31<@planetmaker>andythenorth: can you try compilation again after you set
07:31<@planetmaker>CFLAGS="-isystem/opt/local/include ${CFLAGS}"
07:32<@planetmaker>in your ~/.bash_profile?
07:32<andythenorth>planetmaker: sorry - it does compile
07:32<andythenorth>it was my stupid mistake
07:33<@planetmaker>but what made it fail in the first place?
07:33<andythenorth>not using make mrproper
07:33<@planetmaker>and what did you change?
07:33-!-robotx [] has joined #openttd
07:33<andythenorth>I used make mrproper :)
07:33<@planetmaker>ah... you copied from your old machine?
07:33<@planetmaker>and then just compiled?
07:33<@planetmaker>ok, yes, that must fail :-)
07:33<andythenorth>driver error
07:33<@planetmaker>been there, seen that
07:34<@planetmaker>good :-)
07:34<@planetmaker>lucky me
07:35<@planetmaker>don't worry
07:39<Hirundo>frosch123: would something like this work?
07:40<Hirundo>(note: tested to the extent that it looks sane to my rather untrained eyes)
07:40<@planetmaker>andythenorth: today I'm not working on it. or currently
07:41<@planetmaker>might change :-P
07:41*andythenorth does other stuff
07:41<andythenorth>which is easier to understand:
07:41<frosch123>Hirundo: there is an /// instead of an //
07:41<andythenorth>"Running costs vary with capacity"
07:42<@planetmaker>why did you ask?
07:42<andythenorth>or "Higher capacities cost more to run"
07:42<frosch123>looks fine to me, but it will for sure cause some discussion about the "right" value :p
07:42<@planetmaker>what does that patch? ttdp?
07:42<Hirundo>of course MB will disagree :P just because he can
07:43<andythenorth>MB: grinch, or force for good?
07:43<Hirundo>planetmaker: provide a defined result for failed 7E procedure calls in TTDP
07:44*andythenorth thinks force for good
07:45-!-TWerkhoven [] has joined #openttd
07:46<Pulec>is there a dedicated ottd server for debian?
07:47<frosch123>Hirundo: so would eis_os. and the other patchdevs will most likely not understand what it is about, unless you explain it to them. the only one who could deal with it from ttdp would be dalestan
07:48<Ammler>Pulec: not from, you might need to build it self
07:48<Hirundo>What's the best way of reaching them? Are they around on IRC often, or is it best to create a forum post?
07:49<frosch123>on irc you will only catch lakie
07:49<Ammler>Hirundo: ttdp is dead
07:50<frosch123>and reaching the other "them" would first need defining who "them" is
07:50-!-JVassie [] has joined #openttd
07:50<Pulec>thats a bit more complicated, so the easiset way is to run ottd on some xwindows
07:50<frosch123>you can put it on the forum and wait for some trolls though :)
07:52<@planetmaker>Pulec: the default binary can work as dedicated
07:52<Hirundo>ah well, I'll do so and see what happens :)
07:52<Ammler>Pulec: well, you could install the build-dep of openttd
07:52<@planetmaker>./openttd -D and you're set
07:52<Ammler>planetmaker: no, they can't
07:52<Ammler>those need still X
07:52<Ammler>or sdl
07:53<Hirundo>As a side note, what was the 'correct' way of failing a callback again?
07:53<Eddi|zuHause>Ammler: so what's easier, installing the build-deps or installing sdl?
07:54<Ammler>Eddi|zuHause: I guess, it depends on the guy who installs :-)
07:54<Ammler>what he prefers
07:54<Hirundo>Do a real action2->action1, with action1 containing 1 set with 0 sprites?
07:54-!-KritiK [] has joined #openttd
07:54<Ammler>Pulec: we provide dedicated rpms :-)
07:56<Pulec>thx, will see what linux friend will try
07:56<@planetmaker> <-- :-) frosch123, andythenorth
07:56<andythenorth>how clever
07:57<@planetmaker>now the slopes ;-)
07:58<@planetmaker>minimum version requirement r22721 :-P
07:59<Eddi|zuHause>planetmaker: that should be default for company owned land
07:59<@planetmaker>hm... ok, possibly 1.1.3-RC1...
07:59<@planetmaker>Eddi|zuHause: you mean this fencing?
08:00<frosch123>planetmaker: rather 1.2 beta 1
08:00<frosch123>advsprlayout is not 1.1 stuff, is it?
08:00<@planetmaker>hm, yes, probably
08:01<@planetmaker>well, no new opengfx+landscape then for anyone playing stables :-P
08:01<andythenorth>Eddi|zuHause: 'spose you want load sprites for your forklift?
08:01<Eddi|zuHause>andythenorth: that'd be good, but a generic box might suffice
08:02<andythenorth>I'll have to find one :P
08:02<Ammler>planetmaker: fyi: ottdc@games:~> openttd -D
08:02<Ammler>openttd: error while loading shared libraries: cannot open shared object file: No such file or directory
08:03<@planetmaker>but that's only because it's not installed via package manager, right?
08:03<Ammler>I installed it via rpm with --nodeps
08:03<frosch123>it was not compiled as dedicated-only
08:03<Ammler>so it didn't install the whole sdl
08:04<@planetmaker>Ammler: well, then it's no surprise, is it?
08:04<Ammler>well, you expected it to work
08:04<@planetmaker>when installed properly
08:04<Ammler>maybe you aren't the only openttd dev doing that, that is why you don't provide dedicated bundles
08:04<Ammler>what is the point of building dedicated version, when you have sdl installed?
08:05<Ammler>I am not sure, if it would be possible to make openttd loading sdl only, if available
08:05<Eddi|zuHause>Ammler: we used to provide dedicated-only binaries, but there simply was not enough demand
08:07<Ammler>Eddi|zuHause: I know, it is aounrd one per year asking for it :-)
08:07<Ammler>better to provide 10 different formats of the same
08:12<Rubidium>frosch123, Eddi|zuHause: OpenTTD can use more than 2 threads (by itself): main thread, background save thread and... SDL drawing thread. Then there's also the other auxiliary threads such as sound playback and IP address resolution, though those are out of OpenTTD's control
08:14<Eddi|zuHause>"Der Pwnie für den "Most Epic FAIL" ging an Sony, was wenig überrascht"
08:15-!-glx [glx@2a01:e35:2f59:c7c0:c1c9:3888:5d28:99d2] has joined #openttd
08:15-!-mode/#openttd [+v glx] by ChanServ
08:38-!-MNIM [] has quit [Remote host closed the connection]
08:43<@planetmaker>hm... I now have a newgrf which 100% crashes OpenTTD on trying to start a game with it
08:44<Hirundo>nice :P is it because of an incompatible version, or should it actually work?
08:44<@planetmaker>should work
08:44<Eddi|zuHause>you know where the bugtracker is :p
08:48<@planetmaker>must be reading invalid memory or so...
08:48<@planetmaker>or writing
08:51<@planetmaker> <-- newgrf
08:53<Hirundo>ottd version?
08:53<frosch123>head :)
08:54<@planetmaker>no other is supposed to work anyway ;-)
08:54<@planetmaker> <-- nml code
08:55<frosch123>finally someone is testing advsprlayout :)
08:57<andythenorth>frosch123: I tested it
08:57<andythenorth>but I found that it failed :P
08:57<andythenorth>about 2 months ago :)
08:58<@planetmaker>see, people just don't listen to you ;-)
08:58<andythenorth>signal to noise ratio is bad
08:59<frosch123>planetmaker, Hirundo: more than 256 operations in an advvaract2?
08:59<@planetmaker>not sure... possible?
09:01<frosch123>it works if i change byte to uint :)
09:01<frosch123>nml entered a new dimension :p
09:01<@planetmaker>It's not the first time I run into that...
09:01<@planetmaker>Hirundo and Yexo will know :-P
09:02<frosch123>we will need to implement runtime scheduling and multi-threaded advact2
09:02<Hirundo>or... more operators, so NML doesn't need so many arcane workarounds :)
09:04<@planetmaker>this auto-fencing really stretches the VarAction2 limits...
09:05<@planetmaker>First it was just for level ones - that was sorted.
09:05<@planetmaker>Now... going for the arbitrary slope, we're there again ;-)
09:08<Hirundo>frosch123: It might be best to put those adjusts in a SmallVector, to reduce the endless reallocing
09:09<frosch123>yup, just doing that :)
09:11-!-ar3k [] has quit [Read error: Connection reset by peer]
09:12-!-ar3k [] has joined #openttd
09:12-!-ar3k is now known as ar3kaw
09:17<CIA-2>OpenTTD: frosch * r22723 /trunk/src/newgrf_spritegroup.h: -Fix: Do not restrict AdvVarAct2 to 255 operations.
09:22<Eddi|zuHause>i'm sure CETS will hit one or two limits in the near future as well :p
09:23<@planetmaker>I'm quite sure of that, too ;-)
09:23<@planetmaker>like the articulated vehicle limit
09:24<Eddi|zuHause>planetmaker: well, there are workarounds for that
09:24<@planetmaker>many limits can be worked around one way or another...
09:25<Eddi|zuHause>just not sure i can teach them to nml yet
09:27<Eddi|zuHause>right, what i wanted to ask: i used some undocumented feature like "var[0x45,0, 0x000F0F0F]", is there some similar undocumented feature for var6x?
09:28<@planetmaker>the same way
09:29<Eddi|zuHause>how does that handle the parameter?
09:29<@planetmaker>IIRC as 4th parameter
09:29<@planetmaker>uhm, no
09:30<@planetmaker>STORE_TEMP(value, 256+0x10), STORE_TEMP(value, 256+0x18)
09:30<@planetmaker>as the callback variables
09:30<@planetmaker>hm... or just a value beyond 255
09:30<@planetmaker>FIRS did something like that
09:32<@planetmaker>switch(FEAT_INDUSTRYTILES, SELF, action2_6811, var[0x60, 0, 255, 0]) {
09:32<@planetmaker>so 4th parameter it was
09:33<Eddi|zuHause>"action2_6811" sounds very autoconversion-y :)
09:34<@planetmaker>you need that for the yet not existing parameters, right?
09:35<@planetmaker>not for the existing ones?
09:35<@planetmaker>a very good reason to keep it, although undocumented :-)
09:35<@planetmaker>it = that syntax
09:36-!-douknoukem [~KEM@] has joined #openttd
09:36<Hirundo>Eddi|zuHause: Do you use other hard coded (var[...]) variables, except not yet existing ones and var 45 ?
09:36<Hirundo>k good
09:37*Hirundo puts var[0x45,0, 0x000F0F0F] on the NML feature list
09:38<Eddi|zuHause>this autoconverted FIRS is full of these things, though ;)
09:38<Hirundo>I know :S
09:39<@planetmaker>Eddi|zuHause: yes, it is. But they easily are converted to proper calls.
09:39<@planetmaker>And many (most?) are
09:39<@planetmaker>it was an old rev I linked
09:39<Hirundo>hmm... do you need the triplet info in this case?
09:39<@planetmaker>curv_info_prev_cur and friends?
09:40<Hirundo>I mean in var[0x45,0, 0x000F0F0F], does the triplet part add any useful information?
09:40<Eddi|zuHause>Hirundo: yes, the cases are 0x000F0F00, 0x000F000F, 0x00010100, 0x00010001 and default
09:41<Hirundo>You could distinguish these cases with var[0x45, 0, 0x00000F0F] also, right?
09:41<Eddi|zuHause>Hirundo: not really
09:42-!-Juo [] has quit [Quit: goodbye]
09:42<Hirundo>Isn't triplet just the same as front + back? ergo, it adds no information entropy
09:42<Eddi|zuHause>Hirundo: i have to know that when the front one is curved, the back one is straight
09:43<Hirundo>that's 0x0001 resp 0x000F, no need to use the triplet info for that
09:44<Eddi|zuHause>Hirundo: there might be some corner cases i'm overlooking
09:47<Hirundo>I'm not sure though, how a unified variable would work w.r.t. sign extension
09:48-!-Juo [~Juo@] has joined #openttd
09:49<Hirundo>currently negative values (0x0C - 0x0F) are sign extended to -4 .. -1, you can't just stick two (or more) of such values into a single dword
09:51<Eddi|zuHause>can you do operations in the case-constants? like "((-1 & 0xF) << 8) | ((-1 & 0xF) << 16)"?
09:52<Eddi|zuHause>or you need tuples ;)
09:52<Eddi|zuHause>"raw" var45 then returns a 3-tuple
09:54<Hirundo>tuples are about a dozen bridges further :)
09:55<Hirundo>We could do something akin to relative_pos for objects etc.
09:55<CIA-2>OpenTTD: frosch * r22724 /trunk/src/newgrf.cpp: -Codechange: Reduce number of realloc calls when loading VarAct2s.
09:56<Hirundo>that var returns 0xYYXX, and you get a helper function relative_coord(x, y) that does the bit magic for you
09:56<CIA-2>OpenTTD: frosch * r22725 /trunk/src/ (industry_gui.cpp object_gui.cpp): -Fix: Always draw NewGRF supplied texts with a default colour.
09:59<Eddi|zuHause>i thought lots of variables have that kind of bitstuffing
10:00<Hirundo>yes, but in most cases the variables are just split in parts and reading them as one isn't really useful
10:01<Hirundo>relative_pos is an exception, as a whole it turned out to be really useful to decide on graphics within an industry/object/airport
10:01<Hirundo>separate variables relative_x and relative_y are still available, though
10:03<Eddi|zuHause>hm, i think i never properly checked 90° curves for my vehicles...
10:07<Pulec>anybody can do restart comand via console? or is just wrongly sert permission
10:09<@planetmaker>rcon is your friend
10:09<@planetmaker>set an rcon password
10:16<Pulec>damn i dont like all the sounds off factories when zoomed out max
10:16<Pulec>its like neverending
10:17<Eddi|zuHause>use running sounds for train, then you hit the simultaneous sound limit :p
10:25-!-APTX [] has joined #openttd
10:32-!-APTX_ [] has quit [Ping timeout: 480 seconds]
10:50-!-variable [~balsa@216-165-29-133.DYNAPOOL.NYU.EDU] has left #openttd [Overflow in /dev/null]
10:56-!-Rezt [] has joined #openttd
10:58-!-Rezt [] has quit []
10:59*andythenorth has a tram moving inside a road depot :P
10:59<Eddi|zuHause>by changing newgrfs ingame? :p
11:03-!-pugi [] has joined #openttd
11:03-!-supermop [] has joined #openttd
11:03<andythenorth>by changing the type of an RV + reloading the grf :P
11:09-!-ZirconiumX [] has joined #openttd
11:09<ZirconiumX>Long time, no see - as they say.
11:10<ZirconiumX>Hello, everyone!
11:10-!-Sevalecan [] has quit [Quit: Leaving]
11:12*ZirconiumX is being minimalist.
11:12<Eddi|zuHause>don't believe what THEY say.
11:12<ZirconiumX>Only they would say it.
11:12-!-ZirconiumX is now known as they
11:13<they>The nickname they is protected...
11:13-!-they is now known as ZirconiumX
11:14<Eddi|zuHause>it must be capitalised
11:14-!-ZirconiumX is now known as THEY
11:14<THEY>That's protected, too.
11:14-!-THEY is now known as They
11:15<They>Not protected.
11:15-!-JVassie [] has quit [Ping timeout: 480 seconds]
11:15<They>He he.
11:15-!-They is now known as ZirconiumX
11:19*ZirconiumX is wondering if you could implement a minimalist AI
11:19*ZirconiumX thinks you'd need an alias command - or something of the sort
11:21<Eddi|zuHause>more minimalist than "Idle" or "IdleMore"?
11:21-!-Noxbru [] has joined #openttd
11:21<ZirconiumX>Much shorter is AIEEP.C(e).AEP compared to AIEventEnginePreview.Convert(event).AcceptEnginePreview
11:21<ZirconiumX>Openttd squirrel is very easy to read - unfortunately
11:22<Eddi|zuHause>as an AI i'd rather decline the offer by default...
11:22<@planetmaker>wooo... andythenorth, we can have fenced meadows now :-)
11:22<@planetmaker>even in Norway ;-)
11:25*ZirconiumX is messing around with a computer chess engine
11:25*ZirconiumX is using a lot of /me commands
11:29<@planetmaker>to me it sounds like a lot of on-topic talk
11:30*ZirconiumX detects sarcasm in that comment
11:32<ZirconiumX>@Eddi|zuHause, (apologies) minimalist as in it works, but is very small and has limited functionality
11:32<ZirconiumX>A guy implemented a chess program in less than 2KB of non-blank source
11:32-!-Juo [~Juo@] has quit [Quit: goodbye]
11:32<ZirconiumX>think that sort of thing
11:33<Eddi|zuHause>oh, you mean like obfuscated c contest
11:35<ZirconiumX>roughly yes
11:35<ZirconiumX>You could hold a contest fro it
11:35-!-Juo [~Juo@] has joined #openttd
11:41-!-Adambean [] has joined #openttd
11:46-!-Juo [~Juo@] has quit [Quit: goodbye]
11:46-!-Juo [~Juo@] has joined #openttd
11:47-!-KouDy [] has joined #openttd
11:52-!-robotx [] has quit [Ping timeout: 480 seconds]
12:02-!-ZirconiumX [] has quit [Quit: ajax IRC Client]
12:03-!-Adambean [] has quit [Ping timeout: 480 seconds]
12:26-!-Juo [~Juo@] has quit [Quit: goodbye]
12:39<andythenorth>HEQS 1.2.0 released.
12:39<andythenorth>done, done, onto the next one....
12:42-!-Juo [] has joined #openttd
12:42-!-Juo [] has quit []
12:44-!-robotx [] has joined #openttd
12:45-!-pugi [] has quit [Ping timeout: 480 seconds]
12:46-!-pugi [] has joined #openttd
12:52<Noxbru>hi, may I ask you some questions about AITile.GetCargoAcceptance/Production ?
12:52-!-Andel [] has quit [Read error: Operation timed out]
12:52<frosch123>@topic get -3
12:52<@DorpsGek>frosch123: Don't ask to ask, just ask
12:53<Noxbru>sorry :-[
12:53<andythenorth>at least he was specific :)
12:54<Noxbru>my problem is that i'm trying to sort some tiles by its passengers acceptance, and building a bus stop at the top one, but the AI puts the station at the last tile
12:54<Noxbru>I have told my AI to write at the log the acceptances of the tiles, and it says 0s and -1s
12:55<Noxbru>so I wanted to ask how more or less does AITile.GetCargoAcceptance/Production works
12:55<frosch123>-1 means error
12:55<frosch123>something is wrong about the arguments to the fnuction
12:56<frosch123>take a look at the preconditions for that function
12:56-!-pjpe [] has joined #openttd
12:57<Noxbru>AIMap.IsValidTile, width and height > 1 and radius >= 0
12:57<Noxbru>in my case is true, 1, 1, 5
12:57-!-orudge [] has quit [Ping timeout: 480 seconds]
12:58-!-Born_Acorn [] has quit [Ping timeout: 480 seconds]
12:58<frosch123>then the function shall not return -1
12:59<Noxbru>I am generating the tile list with: "tiles.AddRectangle(town + AIMap.GetTileIndex(-10,-10), town + AIMap.GetTileIndex(10,10));"
12:59<Noxbru>then, keeping the roads
12:59<frosch123>you can use the landscape info tool on the very right of the toolbar (the '?') to check the acceptance of indiviudal tiles
12:59<Noxbru>and checking their acceptance of passengers
13:00<Noxbru>AILog.Info(AITile.GetCargoProduction(tile,AICargo.CC_PASSENGERS,1,1,5) + "");
13:01<frosch123>AICargo.CC_PASSENGERS is no cargo type
13:02<frosch123>it's a cargoclass, but actually that should not matter in this case
13:02<Noxbru>ups... then, that's the error
13:04<frosch123>ah, it checks for coal acceptance that way :)
13:04<frosch123>resp. production
13:08<Noxbru>then, how I should pass the CargoID? at the AICargo there isn't any function that returns CargoID
13:09-!-Juo [] has joined #openttd
13:10-!-Juo [] has quit []
13:10<frosch123>i assume you want to build a busstop
13:10-!-Juo [] has joined #openttd
13:10<Noxbru>found here
13:11<Noxbru>yes I wanted some kind of function which you can pass the town_id and the type of station and looks for the best place to build it
13:11<frosch123>take AICargoListe, filter it by cargoclass, and then process those cargos
13:11<Noxbru>thank you very much
13:12<frosch123>you're welcome :)
13:12<frosch123>you even pointed me on a bug in ottd :)
13:12<Noxbru>really? :-[
13:14*andythenorth wonders if it's time for FIRS
13:16<andythenorth>89 tickets is a lot :|
13:16-!-douknoukem [~KEM@] has quit [Ping timeout: 480 seconds]
13:20<CIA-2>OpenTTD: frosch * r22726 /trunk/src/ai/api/ (ai_rail.cpp ai_rail.hpp ai_tile.cpp ai_tile.hpp): -Fix: AITile::GetCargoAcceptance, AITile::GetCargoProduction and AIRail::BuildNewGRFRailStation did not check the cargo argument for validity.
13:22-!-bodis [] has joined #openttd
13:24-!-ar3kaw [] has quit [Read error: Connection reset by peer]
13:24-!-ar3k [] has joined #openttd
13:24-!-ar3k is now known as ar3kaw
13:30-!-andythenorth [] has quit [Quit: andythenorth]
13:32-!-perk11 [] has joined #openttd
13:32-!-KouDy1 [] has joined #openttd
13:33-!-KouDy [] has quit [Quit: Leaving.]
13:42-!-andythenorth [] has joined #openttd
13:45<Noxbru>see you, thanks for the help
13:45<CIA-2>OpenTTD: translators * r22727 /trunk/src/lang/russian.txt:
13:45<CIA-2>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-2>OpenTTD: russian - 1 changes by Lone_Wolf
13:45-!-KritiK [] has quit [Ping timeout: 480 seconds]
13:45-!-Noxbru [] has left #openttd []
13:50-!-douknoukem [~KEM@] has joined #openttd
13:52-!-KritiK [] has joined #openttd
13:58-!-Juo [] has quit [Remote host closed the connection]
13:58-!-Juo [~Juo@] has joined #openttd
14:02<@planetmaker>19:12 Noxbru: really? :-[ <-- don't be afraid to point out those :-)
14:03<@planetmaker>better they're known (and fixed) than... lurking there forever :-)
14:03<@planetmaker>good bug reports are hard to come by. And we have to rely on people telling us about problems - we cannot detect them all ourselves
14:04<frosch123>are you sure he reads logs?
14:04<@planetmaker>skimming over them
14:04<frosch123>"he", not "you" :)
14:05<@planetmaker>and it seems he did the same to you as I did this afternoon to you ;-) - oh :-)
14:08-!-Juo [~Juo@] has quit [Quit: goodbye]
14:08<@planetmaker>looks wet
14:09<@planetmaker>or given the temperature and humidity here right now: refreshing
14:10-!-Born_Acorn [] has joined #openttd
14:12-!-Andel [] has joined #openttd
14:12<@planetmaker>I wonder still why the purchase list sprite for the company land does not show...
14:13<frosch123>are you checking fences in the purchase list?
14:15-!-Juo [~Juo@] has joined #openttd
14:15-!-orudge [] has joined #openttd
14:19-!-Juo [~Juo@] has quit []
14:19-!-Juo [~Juo@] has joined #openttd
14:19-!-Juo [~Juo@] has quit []
14:24<frosch123>planetmaker: the purchase list chain results in an callback result
14:24<@planetmaker>hm... I wonder why
14:24<frosch123>bug in nml?
14:24<@planetmaker>It works similar for the wind mill
14:24<@planetmaker>I even don't get an image when I link to the simplest sprite layout I can think of: a normal ground tile
14:25-!-Juo [~Juo@] has joined #openttd
14:27<Eddi|zuHause>planetmaker: have a stray "return"?
14:28<@planetmaker>not that I know... but I'm going to double-check
14:31<frosch123>that's the number of operations in that advvaract2 :p
14:32<frosch123>planetmaker: you are triggering the variable-not-available case
14:32<frosch123>so i guess you try to check adjacent tiles
14:35<@planetmaker> <-- but there I don't see any...
14:37<frosch123>well, i tested the grf you gave me earlier
14:37-!-KritiK [] has quit [Quit: Leaving]
14:38<@planetmaker>of course :-)
14:38<frosch123>whats' GROUNDSPRITE_NORMAL ?
14:38<@planetmaker>flat, green grass tile
14:38<@planetmaker>so to say
14:39<@planetmaker>errm.. not A. But default TTD sprite
14:49-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
14:52<frosch123>planetmaker: it works if you put the purchase layout also in the default case of the main graphics item
14:52<frosch123>so, looks like nml bug to me
14:54<frosch123>the purchase list case results in a callback switch which then ends up in a huge veract2 checking an not-available variable
14:55-!-Adambean [] has joined #openttd
14:56<@planetmaker>hm... yes... that makes sense
14:57<@planetmaker>I'll try the other way to use that callback
14:58<andythenorth>512GB SSD drives
14:58<andythenorth>price makes your eyes bleed :o
14:58*andythenorth votes against SSD
15:00<andythenorth>is this really a bug?
15:00<@Alberth>lol, you can store my entire HD 3 times at that disk :)
15:00<andythenorth>you clearly aren't stacking up baby pictures :P
15:00<andythenorth>or HD video of amusing toddler incidents
15:01<@Alberth>sugar refineries do not explode normally, do they?
15:01<andythenorth>dust I bet
15:01<andythenorth>like flour mills
15:01<@planetmaker>depends on properties set, I guess
15:01<andythenorth>flour mills explode with huge force
15:01<andythenorth>I'm going to close it
15:03<@planetmaker>that works actually remarkably well...
15:04<@planetmaker>hm... NML doesn't like cargo type 0xFF for objects...
15:37-!-robotx [] has quit [Ping timeout: 480 seconds]
15:42-!-George is now known as Guest4964
15:42-!-George [~George@] has joined #openttd
15:46-!-supermop_ [] has joined #openttd
15:47-!-Guest4964 [~George@] has quit [Ping timeout: 480 seconds]
15:50<andythenorth>are there any good RV sets yet? :P
15:50<andythenorth>is there a hungarian RV set?
15:52-!-Twerkhoven[L] [] has joined #openttd
15:52<Rubidium>andythenorth: ANYRV set?
15:52*andythenorth tries hungarian set
15:54<Eddi|zuHause>andythenorth: there's an ikarus set, yes
16:02<andythenorth>I have to restart my game
16:02<andythenorth>UKRS 2 disabled itself due to grf order :P
16:02<Eddi|zuHause>... or you could use developer settings :p
16:03<andythenorth>I forgot that I can do that :o
16:03<andythenorth>brain fail
16:11<George>Hi. A small question. Can towns above snow line/in desert grow when food/water are not defined?
16:14<frosch123>unless funded
16:14<George>Thanks. Then I'll give goods the food effect in case food is not defined
16:17<Eddi|zuHause>alpine has that problem
16:17-!-duckblaster [] has joined #openttd
16:21-!-DayDreamer [~DayDreame@] has joined #openttd
16:23<George>One more question. About CB 14B
16:24-!-DayDreamer [~DayDreame@] has left #openttd []
16:25-!-George|2 [~George@] has joined #openttd
16:25-!-George is now known as Guest4966
16:25-!-George|2 is now known as George
16:26<frosch123>that question did not arrive
16:26<George>Prop 11 of action 0 for industries supports this situation fine
16:27<George>[00:24:09] <George> What would happen, if the returned cargo is not defined?
16:27<George>[00:24:39] <George> Should CB fail or next run will happen?
16:28<George>(the situation is the case of the cargo, defined by other GRF)
16:28<George>Property 11 holds it fine. it works well when only the 3-d cargo is available
16:29<George>But would it be the same with CB 14B
16:29<frosch123>currently it fills the slot with "invalid cargo"
16:29<frosch123>so the slot will be disabled
16:30<frosch123>it will not fill up those slots with the 4th or 5th call
16:30<George>would it pass to the next cargo?
16:30<frosch123>it queries all 3 slots
16:30<George>Ok. Thank you.
16:31-!-Guest4966 [~George@] has quit [Ping timeout: 480 seconds]
16:32-!-andythenorth [] has quit [Quit: andythenorth]
16:33-!-andythenorth [] has joined #openttd
16:34*andythenorth is once again getting slaughtered by a YACD game :(
16:35<andythenorth>no PAX RVs in 1890 makes it *hard*
16:35<andythenorth>ho hey
16:35<andythenorth>good night ;)
16:35-!-andythenorth [] has left #openttd []
16:43<George>BTW, would during CB 14B var 86 be Number of the selected layout, according to property 0A? (starting from 0?)
16:44<frosch123>why 86? 44
16:45<frosch123>ah, 86 is only for cb 28
16:45<George>Industry is already build while CB 14B?
16:46<frosch123>almost, the tiles are not yet planted, but the rest is set up
16:48-!-George|2 [~George@] has joined #openttd
16:48-!-George is now known as Guest4969
16:48-!-George|2 is now known as George
16:48<George>[00:46:52] <George> so testing var 44 is safe?
16:49<George>Thank you
16:53-!-Guest4969 [~George@] has quit [Ping timeout: 480 seconds]
16:54<__ln__>np: Leonard Nimoy - Ballad of Bilbo Baggins
16:55<Eddi|zuHause>go away.
16:55-!-KritiK [] has joined #openttd
16:55<__ln__>who, me?
16:57<pjpe>is a network made using only path signals slower in cpu than the same network using only block signals?
16:57-!-supermop_ [] has quit [Quit: supermop_]
16:57-!-Alberth [] has left #openttd []
16:59<Eddi|zuHause>pjpe: depends
17:00<Eddi|zuHause>pjpe: there are factors that slow down and other factors that speed up
17:01<pjpe>mind elaborating?
17:03<Rubidium>having to make the reservation takes time
17:03<Rubidium>but once the reservation is there it simple follows that as if there are no junctions in the rail
17:04<Eddi|zuHause>pjpe: the state of block signals is calculated by breadth-first-search, so large crossings must be fully traversed every time a train is entering or leaving the block, while with path signals, the path finder marks the tracks as it would touch them anyway, also with path signals, generally fewer pathfinder runs are necessary, which takes less time. on the other hand, with path signals, stuck trains must repeatedly check whether the track
17:04<Eddi|zuHause>became free, which takes more time
17:04<Rubidium>when there is no reservation, each switch results in a call to the pathfinder
17:05<pjpe>stuck trains as in stuck at a light?
17:05<Rubidium>so it's balancing amount of reservations vs amount of pathfinder calls
17:05<Eddi|zuHause>pjpe: yes
17:05<pjpe>so if i get this right
17:06<pjpe>it's better to have block signals normally but path signals in front of say
17:06<pjpe>junctions or stations?
17:06<Eddi|zuHause>pjpe: if you have straight track with signals, path signals will probably be marginally slower than block signals
17:06<pjpe>just what i thought
17:06<pjpe>really pisses me off seeing that too
17:06<pjpe>just looks so wrong
17:07<Eddi|zuHause>maybe someone should do a profiling session to determine how much it is actually slower/faster
17:08-!-duckblaster1 [] has joined #openttd
17:09-!-duckblaster [] has quit [Read error: Operation timed out]
17:09-!-SmatZ [] has quit [Ping timeout: 480 seconds]
17:10-!-^Spike^ [] has quit [Ping timeout: 480 seconds]
17:11-!-tneo [] has quit [Ping timeout: 480 seconds]
17:11-!-avdg [] has quit [Ping timeout: 480 seconds]
17:11-!-DJNekkid [] has quit [Ping timeout: 480 seconds]
17:12-!-Hirundo [] has quit [Ping timeout: 480 seconds]
17:12-!-Osai [] has quit [Ping timeout: 480 seconds]
17:12-!-V453000 [] has quit [Ping timeout: 480 seconds]
17:12*Rubidium wonders how often pings out; seems to be somewhat daily
17:12-!-XeryusTC [] has quit [Ping timeout: 480 seconds]
17:12-!-Ammler [] has quit [Ping timeout: 480 seconds]
17:12-!-Terkhen [] has quit [Ping timeout: 480 seconds]
17:12-!-planetmaker [] has quit [Ping timeout: 480 seconds]
17:26-!-duckblaster1 [] has quit [Ping timeout: 480 seconds]
17:28<Eddi|zuHause>aye, probably a bad idea to check devzone tickets right now :p
17:32-!-HerzogDeXtEr1 [] has joined #openttd
17:38-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
17:38-!-^Spike^ [] has joined #openttd
17:39-!-Terkhen [] has joined #openttd
17:39-!-planetmaker [] has joined #openttd
17:39-!-mode/#openttd [+o Terkhen] by ChanServ
17:39-!-mode/#openttd [+o planetmaker] by ChanServ
17:40-!-tneo [] has joined #openttd
17:40-!-Ammler [] has joined #openttd
17:41-!-Hirundo [] has joined #openttd
17:41-!-SmatZ [] has joined #openttd
17:41-!-Osai [] has joined #openttd
17:41-!-George|2 [~George@] has joined #openttd
17:41-!-George is now known as Guest4975
17:41-!-George|2 is now known as George
17:41-!-XeryusTC [] has joined #openttd
17:41-!-V453000 [] has joined #openttd
17:42-!-avdg [] has joined #openttd
17:42-!-DJNekkid [] has joined #openttd
17:45-!-George is now known as Guest4977
17:45-!-George [~George@] has joined #openttd
17:47-!-Guest4975 [~George@] has quit [Ping timeout: 480 seconds]
17:50-!-Twerkhoven[L] [] has quit [Quit: He who can look into the future, has a brighter future to look into]
17:50-!-Guest4977 [~George@] has quit [Ping timeout: 480 seconds]
18:07-!-Kurimus [] has quit []
18:12-!-a1270 [] has quit [Ping timeout: 480 seconds]
18:19-!-George is now known as Guest4979
18:19-!-George [~George@] has joined #openttd
18:19-!-perk111 [] has joined #openttd
18:20-!-KouDy1 [] has quit [Quit: Leaving.]
18:21-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:23-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:24-!-Guest4979 [~George@] has quit [Ping timeout: 480 seconds]
18:25-!-perk11 [] has quit [Ping timeout: 480 seconds]
18:26-!-Illegal_Alien [] has joined #openttd
18:26-!-Progman [] has quit [Remote host closed the connection]
18:29-!-Pulec [] has quit []
18:31-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
18:31-!-sla_ro|master [slaco@] has quit []
18:33-!-Brianetta [~brian@] has joined #openttd
18:34-!-bodis [] has quit [Remote host closed the connection]
18:45-!-a1270 [] has joined #openttd
18:50-!-frosch123 [] has quit [Remote host closed the connection]
18:51-!-bellows [] has joined #openttd
18:51-!-bellows [] has quit []
19:04-!-Juo_ [] has joined #openttd
19:05-!-supermop [] has left #openttd []
19:08-!-Adambean [] has quit [Quit: Gone fishing]
19:11-!-Juo [~Juo@] has quit [Ping timeout: 480 seconds]
19:11-!-Juo_ is now known as Juo
19:22-!-Illegal_Alien [] has quit [Quit: HydraIRC -> <- It'll be on slashdot one day...]
19:33-!-Cybertinus [] has quit [Remote host closed the connection]
19:43-!-Polygon [] has joined #openttd
19:48-!-KritiK [] has quit [Quit: Leaving]
19:56-!-George is now known as Guest4984
19:56-!-George [~George@] has joined #openttd
20:00-!-perk11 [] has joined #openttd
20:01-!-Guest4984 [~George@] has quit [Ping timeout: 480 seconds]
20:02-!-perk111 [] has quit [Ping timeout: 480 seconds]
20:20-!-ar3k [] has joined #openttd
20:27-!-ar3kaw [] has quit [Ping timeout: 480 seconds]
20:33-!-robotx [] has joined #openttd
20:44-!-perk11 [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
20:58-!-AD [] has left #openttd []
21:00-!-a_p3rson [] has joined #openttd
21:00<a_p3rson>is there a way to debug signals?
21:00<a_p3rson>mine are not working how they should be
21:00-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
21:03-!-AD [] has joined #openttd
21:04<a_p3rson>does anyone have any advice?
21:05<pjpe>path based or presignals?
21:20-!-robotx [] has quit [Ping timeout: 480 seconds]
21:22-!-douknoukem [~KEM@] has quit [Read error: Connection reset by peer]
21:29-!-Brianetta [~brian@] has quit [Quit: Tschüß]
21:30-!-Polygon [] has quit [Remote host closed the connection]
21:34-!-MNIM [] has joined #openttd
22:10-!-Mazur [] has quit [Ping timeout: 480 seconds]
22:10-!-Mazur [] has joined #openttd
22:25-!-rhaeder [] has joined #openttd
22:29-!-duckblaster [] has joined #openttd
22:31-!-rhaeder1 [] has quit [Ping timeout: 480 seconds]
22:36-!-duckblaster1 [] has joined #openttd
22:40-!-duckblaster [] has quit [Ping timeout: 480 seconds]
23:04-!-llugo [] has joined #openttd
23:11-!-lugo [] has quit [Ping timeout: 480 seconds]
23:12-!-DDR [] has joined #openttd
23:13-!-DDR [] has quit []
23:14-!-DDR [] has joined #openttd
23:15-!-DDR [] has quit []
23:43-!-glx [glx@2a01:e35:2f59:c7c0:c1c9:3888:5d28:99d2] has quit [Quit: bye]
23:56-!-a_p3rson [] has quit [Quit: ajax IRC Client]
---Logclosed Sun Aug 07 00:00:16 2011