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

---Logopened Mon Dec 29 00:00:36 2008
00:02<zircu>my ctrl-g size = about 9.1MB in png format
00:02<mincepie>interesting
00:03<zircu>my ctrl-s size == 140K and it is showing everything
00:04<zircu>i am running a snapshot.. i can get that just in case
00:05<zircu>i'm running r14657 for the mac
00:06<mincepie>if you open the file in $text-editor is it a pattern, or is it apparently random? (look a few screens down...)
00:07<zircu>how do you mean?
00:08<zircu>open the file in a text editor.. not sure what to look for from there
00:08<mincepie>open a text editor
00:08<mincepie>click file > open
00:08<mincepie>select the image
00:09<mincepie>the result should be a very, very large amount of garble
00:09<zircu>yeah i'm going to be dropping it into vim
00:09<mincepie>oh, if you're in bash, just cat it
00:10<zircu>the first bytes are binary starting with the standard PNG header
00:11<zircu>let me check a few differnt readers of png
00:12<zircu>ah there we go, firefox is reading it but taking forever...
00:13<zircu>this area could be optimized i think
00:14<mincepie>ok, and the remaining few hundred screens?
00:14<mincepie>if they are truly black it should be a simple repeating pattern
00:14<mincepie>otherwise your png reader's fecked
00:14<mincepie>aha
00:14<mincepie>were you using preview before?
00:14<mincepie>hmm
00:14<zircu>yea
00:14<mincepie>I just found a lump of solid popcorn-flavouring, the size of an ordinary piece of popcorn, at the bottom of my bag of popcorn
00:14<zircu>preview refused to show the image when i double clicke it
00:14<mincepie>in that case, the problem (like many other problems) is caused by apple.
00:14<zircu>let me test safari
00:14<mincepie>closed/wontfix ^_^
00:15<zircu>now i see the diff i know why i dont need to do ctrl-g
00:15<mincepie>goodo
00:15<mincepie>hmm, 5am
00:16<zircu>let me try sfari anyway
00:16<mincepie>I might have to go to bed in a minute
00:16<zircu>thanks for you help
00:16<mincepie>that was a joke
00:16<mincepie>is safari working?
00:17<zircu>just a sec
00:17<mincepie>0.o
00:17<zircu>i dont normaly use safari
00:17<mincepie>either macs are slower than you claim, or safari has some horrific performance issue
00:17<mincepie>s/you/they/
00:18<zircu>it is a PNG rendering issue
00:18<zircu>safari loads it quickly, i can't blink that fast
00:19-!-grumbel [~grumbel@i577BB390.versanet.de] has joined #openttd
00:19<mincepie>you underestimate the speed of blinking
00:19<zircu>well i blinked 2-3 times
00:20<mincepie>*tut* this kernel isn't even properly popped
00:20<zircu>with firefox i blinked several hundred times
00:20<zircu>and 'preview' just showed a black screen
00:21<mincepie>yes, preview is appalling
00:21<zircu>what is bad is with the png I could watch each pixel line come in
00:21<zircu>and firefox
00:22<zircu>a firefox bug
00:22<mincepie>damn, now I've run out of euro chocolate coins
00:22<mincepie>will have to start on the "oversized 2p coin" chocolate coins
00:24<zircu>how big are those coins?
00:24<mincepie>the oversized ones?
00:24<mincepie>a couple of inches in diameter, possibly
00:24<mincepie>the normal ones are about half the size
01:03-!-svippery [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
01:10-!-svippy [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
01:30-!-svippy [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
01:38-!-svippery [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
01:40-!-Deathmaker [~Miranda@a89-182-129-249.net-htp.de] has joined #openttd
01:46-!-svippery [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
01:47-!-sunkan [sunkan@sunkan.bsnet.se] has joined #openttd
01:48<mincepie:#openttd>hi, svippp
01:48<mincepie:#openttd>svippy, rather
01:53-!-svippy [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
02:06-!-Deathmaker [~Miranda@a89-182-129-249.net-htp.de] has quit [Ping timeout: 480 seconds]
02:11-!-grumbel [~grumbel@i577BB390.versanet.de] has quit [Quit: Ex-Chat]
02:35-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
02:40<petern:#openttd>ctrl-g for "giant screenshot" is not exactly a hard concept, is it?
02:41-!-Deathmaker [~Miranda@a89-182-149-25.net-htp.de] has joined #openttd
02:44<mincepie:#openttd>shhhh
02:45<mincepie:#openttd>;)
02:56<+dihedral:#openttd>hehe - 1 hour screenshot support?
02:58<+dihedral:#openttd>zircu> [05:20:19] the ctrl-g froze access to the game for about 15 seconds and produced a black screen but the ctrl-s is what i need, not sure what the diff is between the two <- cute
03:06-!-Deathmaker [~Miranda@a89-182-149-25.net-htp.de] has quit [Read error: Connection reset by peer]
03:44-!-svippy [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
03:48-!-svippery [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
03:52-!-svippery [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
03:53-!-svippy [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
04:00-!-svippery [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
04:17-!-Vikthor [~Vikthor@161-18-80-78.strcechy.adsl-llu.static.bluetone.cz] has joined #openttd
04:17-!-Vikthor [~Vikthor@161-18-80-78.strcechy.adsl-llu.static.bluetone.cz] has quit []
04:18-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has quit [Quit: This computer has gone to sleep]
04:38-!-Mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has joined #openttd
04:39<+dihedral:#openttd>openttd/src/network/../oldpool.h:125: failed assertion `index < this->GetSize()' <- i have been seeing this quite often.... though sadly i cannot say why / what i did
04:39-!-Kokunai [~Kokunai@cpe-76-183-37-106.tx.res.rr.com] has joined #openttd
04:39<+dihedral:#openttd>:-)
04:40<Kokunai:#openttd>thanks
04:40<Kokunai:#openttd>anyone here up to answer some qustions about load balancing?
04:40<Kokunai:#openttd>questions
04:41<+dihedral:#openttd>just ask
04:41<Kokunai:#openttd>lol
04:41-!-[com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd
04:41<+dihedral:#openttd>dont ask if you can ask
04:41<+dihedral:#openttd>usually does not go down very well
04:41<Kokunai:#openttd>well it is a long question so here goes
04:41<+dihedral:#openttd>and then also be patient to receiving an answer ;-)
04:46<Kokunai:#openttd>...ok i usually run LL___RR mainline...
04:47<Kokunai:#openttd>and I tried to use the outer tracks for turning/exiting into sidelines...but for some reason I ended up with trains going long ways around the map and I think it was due to badly done load balancers
04:47<Kokunai:#openttd>I think the main problem was using them in junctions
04:48<Kokunai:#openttd>do they still work effectively used along the track rather than at junctions to move trains to the right tracks before they get to the junctions? Or do I have their purpose confused?
04:49<+dihedral:#openttd>again - i think you will find the answer looking at screenshots and archived games at www.openttdcoop.org
04:50<Eddi|zuHause:#openttd>dihedral: that assertion could use a backtrace
04:50<Kokunai:#openttd>alright will check there
04:51<Kokunai:#openttd>looked through other sources short of downloading old games but I'll do that
04:58-!-mikl [~mikl@gw.imtnet.dk] has quit [Quit: Leaving...]
04:59-!-mikl [~mikl@gw.imtnet.dk] has joined #openttd
04:59-!-mikl [~mikl@gw.imtnet.dk] has quit []
05:00-!-mikl [~mikl@gw.imtnet.dk] has joined #openttd
05:16-!-Yorick [~Yorick@s55924da0.adsl.wanadoo.nl] has joined #openttd
05:22-!-rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has joined #openttd
05:23-!-rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has quit []
05:32-!-OwenS [~OwenS@host86-128-252-186.range86-128.btcentralplus.com] has joined #openttd
05:38<CIA-1:#openttd>OpenTTD: rubidium * r14764 /trunk/src/ (10 files in 3 dirs): -Codechange: make the '***' chat messages like "Game paused (not enough players)" fully translateable.
05:41<CIA-1:#openttd>OpenTTD: rubidium * r14765 /trunk/src/lang/ (40 files): -Update (r14764): remove changed strings from translations.
05:43-!-Kokunai [~Kokunai@cpe-76-183-37-106.tx.res.rr.com] has quit [Quit: Want to be different? Try HydraIRC -> http://www.hydrairc.com <-]
05:47*Rubidium:#openttd wonders how everyone trying HydraIRC will make you different
05:48-!-[com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has quit [Quit: Operator, give me an exit]
05:50<mincepie:#openttd>Rubidium: there will come a point at which hydraIRC will become the most commonly used IRC client. at this point, the same author is poised to launch an entirely different IRC client that continues to appeal to the idiotic, attention-seeking market
05:52<+dihedral:#openttd>mincepie, just because something is 'most used' does not mean it's good
05:52*dihedral:#openttd points at MS Windows
05:52<mincepie:#openttd>I didn't imply it was
05:52<mincepie:#openttd>I implied that niche products were often used by those who only wished to draw attention to themselves by appearing to be different by using the product
05:54-!-svip [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
05:54<mincepie:#openttd>Apple Computer have somehow managed to persuade everyone that iPods are, in fact, used only by a tiny fraction of the population, a societal elite that can be joined for the low price of £289.95
05:54-!-Yorick_ [~Yorick@s55924da0.adsl.wanadoo.nl] has joined #openttd
05:55<@Rubidium:#openttd>everything starting with i<capital> is likely to be in that category
05:55<mincepie:#openttd>well, of course. everything produced by Apple Computer starts with i
05:55-!-Yorick is now known as Guest1841
05:55-!-Yorick_ is now known as yorick
05:55<mincepie:#openttd>except the things that are profoundly uncool; these are, ironically, the useful products
05:55<petern:#openttd>yeah
05:56<petern:#openttd>powerbook...
05:57<mincepie:#openttd>oh, except Time Machine, and Time Capsule
05:57<mincepie:#openttd>both of which are appalling
05:58<mincepie:#openttd>I like how I have managed to engage three people in one conversation, with one sentence each
06:01-!-Guest1841 [~Yorick@s55924da0.adsl.wanadoo.nl] has quit [Ping timeout: 480 seconds]
06:03-!-svip [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
06:09*yorick:#openttd is updating the extra zoom levels patch...it segfaults :(
06:09<mincepie:#openttd>hurrah!
06:09<yorick:#openttd>on "src_n += n;" in 32bpp_optimized.cpp
06:16-!-Progman [~progman@p57A1C80A.dip.t-dialin.net] has joined #openttd
06:17<CIA-1:#openttd>OpenTTD: rubidium * r14766 /trunk/src/network/core/tcp.h: -Fix (r14730ish): remove unused typedef.
06:17<+dihedral:#openttd>y
06:22<mincepie:#openttd>z?
06:27<yorick:#openttd>r13639 seems to have made it fail on the bigger sprites
06:28<petern:#openttd>harr harr
06:30<mincepie:#openttd>?
06:33<yorick:#openttd>:(
06:33-!-lewymati [~lewymati@aejc19.neoplus.adsl.tpnet.pl] has joined #openttd
06:34<mincepie:#openttd>the pound is now €1.02... could it hit 1.00 today?
06:46-!-SpComb [terom@zapotek.paivola.fi] has joined #openttd
06:57-!-Dred_furst [~Dred_furs@90.242.99.253] has joined #openttd
07:13-!-Brianetta [~brian@client-82-3-228-220.glfd.adsl.virgin.net] has joined #openttd
07:22-!-Mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has quit [Quit: Checking whether build environment is sane ... build environment is grinning and holding a spatula. Guess not.]
07:31-!-zircu [~curt@c-67-166-144-33.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
07:31-!-zircu [~curt@c-67-166-144-33.hsd1.ca.comcast.net] has joined #openttd
07:44-!-Wolf01 [~wolf01@host105-233-dynamic.14-87-r.retail.telecomitalia.it] has joined #openttd
07:44<Wolf01:#openttd>hello :D
07:45<+dihedral:#openttd>hi
07:56-!-svip [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
08:02-!-CIA-1 [~CIA@208.69.182.149] has quit [Ping timeout: 480 seconds]
08:04-!-CIA-2 [~CIA@208.69.182.149] has joined #openttd
08:14-!-glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd
08:14-!-mode/#openttd [+v glx] by ChanServ
08:21-!-mikl_ [~mikl@gw.imtnet.dk] has joined #openttd
08:26-!-mikl [~mikl@gw.imtnet.dk] has quit [Ping timeout: 480 seconds]
08:44-!-Yorick_ [~Yorick@s55924da0.adsl.wanadoo.nl] has joined #openttd
08:47-!-yorick is now known as Guest1861
08:47-!-Yorick_ is now known as yorick
08:50-!-mikl_ [~mikl@gw.imtnet.dk] has quit [Ping timeout: 480 seconds]
08:50-!-Guest1861 [~Yorick@s55924da0.adsl.wanadoo.nl] has quit [Ping timeout: 480 seconds]
09:08-!-mikl [~mikl@gw.imtnet.dk] has joined #openttd
09:17-!-jawsper [~jawsper@P85ae.p.pppool.de] has joined #openttd
09:18<@Belugas:#openttd>hello
09:20<@Belugas:#openttd>George, about the two callbacks you requested, i have a tiny little problem: it should apply to all the houses of the same type at once, or none at all. Reason is that the population and the name string are not stored on the map itself, but on the specs array
09:20<@Belugas:#openttd>therefro, if yo need to see them change, they will be changed for all of the houses of the same type at once.
09:21-!-mikl [~mikl@gw.imtnet.dk] has quit [Ping timeout: 480 seconds]
09:21<@Belugas:#openttd>and i think it might be cpu intensive to trigger a refresh map-wide
09:21-!-svip [~svip@0x50a5b14e.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
09:39-!-Celestar [~Jadzia_Da@mnch-5d87baee.pool.einsundeins.de] has joined #openttd
09:39-!-mode/#openttd [+o Celestar] by ChanServ
09:39<yorick:#openttd>heya celestar
09:41<Forked:#openttd>\o :)
09:42-!-nicfer [~usuario@168.226.105.69] has joined #openttd
09:44<nicfer:#openttd>one question, I've copied the opengfx files to its dir but the game says that I don't have them
09:44<nicfer:#openttd>oh I remember why
09:44<nicfer:#openttd>I'm trying to run it on 0.6.3
09:46-!-nekx [~asd@0x3e42e6e6.adsl.cybercity.dk] has joined #openttd
09:47-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
09:52-!-Celestar [~Jadzia_Da@mnch-5d87baee.pool.einsundeins.de] has quit [Remote host closed the connection]
09:52-!-Celestar [~Jadzia_Da@mnch-5d87baee.pool.einsundeins.de] has joined #openttd
09:52-!-mode/#openttd [+o Celestar] by ChanServ
09:52<petern:#openttd>i pity tha foo'
09:53-!-nicfer [~usuario@168.226.105.69] has quit [Remote host closed the connection]
09:57-!-Zorni [zorn@e177228160.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
09:58-!-Zorn [zorn@e177228160.adsl.alicedsl.de] has joined #openttd
09:59-!-yorick [~Yorick@s55924da0.adsl.wanadoo.nl] has quit [Quit: Poef!]
10:05-!-mikl [~mikl@gw.imtnet.dk] has joined #openttd
10:08-!-dfox [~dfox@r5cv134.net.upc.cz] has quit [Ping timeout: 480 seconds]
10:09-!-dfox [~dfox@r5cv134.net.upc.cz] has joined #openttd
10:10-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
10:15-!-Phoenix_the_II [rdeboom@home.deboom.biz] has quit [Read error: Connection reset by peer]
10:16-!-roboboy [3aad2910@webchat.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
10:22-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
10:27-!-Celestar [~Jadzia_Da@mnch-5d87baee.pool.einsundeins.de] has quit [Ping timeout: 480 seconds]
10:28-!-Fuco [~dota.keys@ip-105.imafexbb.sk] has joined #openttd
10:30-!-Wolle [Dr_Jekyll@p57B0EDFB.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
10:40-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
10:46<CIA-2:#openttd>OpenTTD: rubidium * r14767 /trunk/src/ (settings.cpp settings_gui.cpp): -Codechange: remove some unneeded artificial limits from currencies and use the bounds of the data type.
10:48-!-Swallow [~chatzilla@5355F5FD.cable.casema.nl] has joined #openttd
10:50-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd
11:11-!-Wolle [Dr_Jekyll@p57B0D08E.dip.t-dialin.net] has joined #openttd
11:13-!-Yeggstry [~mind@cpc1-rdng14-0-0-cust946.winn.cable.ntl.com] has joined #openttd
11:19-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
11:20-!-|Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has joined #openttd
11:31-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
11:33-!-Yeggstry [~mind@cpc1-rdng14-0-0-cust946.winn.cable.ntl.com] has quit [Ping timeout: 480 seconds]
11:33-!-Vikthor [~Vikthor@161-18-80-78.strcechy.adsl-llu.static.bluetone.cz] has joined #openttd
11:41-!-Yorick [~Yorick@s55924da0.adsl.wanadoo.nl] has joined #openttd
11:42<Swallow:#openttd>According to MSVC the following strings are not used anywhere:
11:42<Swallow:#openttd>STR_0131_TOO_MANY_NAMES_DEFINED
11:42<Swallow:#openttd>STR_8832_TOO_MANY_ORDERS
11:42<Swallow:#openttd>STR_3007_TOO_MANY_STATIONS_LOADING
11:43<Swallow:#openttd>It might be possible to remove them...
11:44<Yorick:#openttd>the blitter 32bpp code is heavily unreadable :/
11:44<Eddi|zuHause:#openttd>leftovers from the conversion to pools, probably
11:46<Yorick:#openttd>pointer += (uint32 *) + 4 :o
11:46<+glx:#openttd>Yorick: it has to be fast
11:46<Yorick:#openttd>(uint32 *)n *
11:47<Yorick:#openttd>glx: comments shouldn't matter in speed
11:48<Yorick:#openttd>and then it segfaults when stuff is too big :/
12:00-!-Yeggstry [~mind@cpc2-rdng14-0-0-cust631.winn.cable.ntl.com] has joined #openttd
12:08<George:#openttd>Belugas: What do you mean by that? That all houses run callback at one tick, or the callback result is the same for all the houses of the type? If first, than I do not see any problem here. If second, than it ruins all the idea
12:09<George:#openttd>if it takes much CPU - run it once when build and obce a month. I hope that is not too often
12:09<Eddi|zuHause:#openttd>everything that affects only one house must be stored in the map, everything that is not stored in the map affects all houses simultaneously
12:11<George:#openttd>Eddi|zuHause: What does it mean? That the game will run population callback for every house on the map as soon as the game requests population of a single house?
12:11<Eddi|zuHause:#openttd>i'm not sure what the discussion is about
12:11<Yorick:#openttd>no, that the population is stored for every house
12:12-!-Brianetta [~brian@client-82-3-228-220.glfd.adsl.virgin.net] has quit [Quit: Tschüß]
12:13<George:#openttd>Eddi|zuHause: http://bugs.openttd.org/task/2441
12:13-!-Brianetta [~brian@client-82-3-228-220.glfd.adsl.virgin.net] has joined #openttd
12:13<George:#openttd>Yorick: And what?
12:17<Yorick:#openttd>it takes to much CPU to run the callback every time it is needed
12:17<Yorick:#openttd>and it can't be stored for each house indivitually
12:17<Yorick:#openttd>d*
12:18-!-dfox [~dfox@r5cv134.net.upc.cz] has quit [Remote host closed the connection]
12:19<@Belugas:#openttd>George : the fact is that the population and the name is not stored on the map (not enough space). So the thing is i've got that idea that the callbacks should be running once every blabla for the first house, grab that result, apply it to all the houses and stop the call back for the other houses of the same type. But every houses type would need to run the call back
12:19<@Belugas:#openttd>so all in all, it's a pretty intense situation
12:20<@Belugas:#openttd>so the call back is really done on the house types, and not on the houses themselves
12:24-!-Mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has joined #openttd
12:29<George:#openttd>but it would make it useless. I wanted to have the result depending on the current graphics
12:29<George:#openttd>and that means PERSONAL value for every house
12:29<Yorick:#openttd>why not just run the callback for every time population is needed?
12:30<George:#openttd>and when do the game reads house population? when is it needed?
12:30<George:#openttd>Yorick: and how often does it happen?
12:30<flexd:#openttd>is there a max limit on the amount of trains clients/servers can manage?
12:30<flexd:#openttd>(i assume there is, but what is that limit?)
12:31<Yorick:#openttd>flexd: 65535 or 2**32, I think
12:31<flexd:#openttd>okay, we are nowhere near the limit thne :P
12:31<flexd:#openttd>then*
12:31<Yorick:#openttd>src/vehicle_type.h:typedef uint16 VehicleID;
12:32<flexd:#openttd>well, it's alot in any case
12:32<Yorick:#openttd>unless it is set with the patches
12:33<@Belugas:#openttd>George, until the population is installed in the map for each house (which is not posible right now), writing the reslt in the specs is the only way to go right now.
12:34<@Belugas:#openttd>the other approach would be to remove some stuff from the map and create a pool of house data, much like we havve for industries. But i'bve got no idea on how cpu /memory intensive that will be
12:35<welshdragon:#openttd>That's me. Silence spoiler
12:36<welshdragon:#openttd>Oops. Wrong channel
12:36<Yorick:#openttd>what are the depot structs actually needed for?
12:37<@Belugas:#openttd>dunno
12:38<Yorick:#openttd>they store owner, xy :p
12:38<Yorick:#openttd>but houses are with more
12:38<Eddi|zuHause:#openttd>flexd: 5000 per company
12:48<svip:#openttd>Eddi|zuHause: Noticed something?
12:49<Eddi|zuHause:#openttd>when someone is busy, they usually do not notice the lack of annoyance
12:50<svip:#openttd>But they do appreciate it.
13:21-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has joined #openttd
13:26-!-evandar [~evandar@213.168.176.142] has joined #openttd
13:31<@Rubidium:#openttd>George: it reads the population when the house is built and on loading savegames
13:31<@Rubidium:#openttd>making it "variable" over time or whatever non-constant thing you can image means it is very likely to cause desyncs
13:35<George:#openttd>Rubidium: It would be Ok if it happens on 1-st day of the year or any time based condition, that allows sync.
13:36<@Rubidium:#openttd>no, because clients don't join on the first day of the year
13:37<George:#openttd>Rubidium: If "on loading savegame" and "when house is build" are the only possible solution (but allowing a callback tu have different values) that would be enough for me
13:38<@Rubidium:#openttd>but where would people base their callbacks results on?
13:38<@Rubidium:#openttd>exactly... dates
13:38<@Rubidium:#openttd>which in it's turn will cause desyncs
13:39<@Rubidium:#openttd>I'm disliking TTRS for doing it's road replacement stuff based on year-of-load too
13:40<@Rubidium:#openttd>especially as exactly the same mechanism can be used to differ in e.g. house population
13:40<@Rubidium:#openttd>which would again mean desyncs
13:41<CIA-2:#openttd>OpenTTD: translators * r14768 /trunk/src/lang/ (8 files in 2 dirs): (log message trimmed)
13:41<CIA-2:#openttd>OpenTTD: -Update: WebTranslator2 update to 2008-12-29 18:40:47
13:41<CIA-2:#openttd>OpenTTD: dutch - 13 fixed, 5 changed by Excel20 (18)
13:41<CIA-2:#openttd>OpenTTD: french - 13 fixed by glx (13)
13:41<CIA-2:#openttd>OpenTTD: hebrew - 22 fixed, 1 changed by yitzc (16), davidx123 (7)
13:41<CIA-2:#openttd>OpenTTD: italian - 13 fixed by lorenzodv (13)
13:41<CIA-2:#openttd>OpenTTD: norwegian_nynorsk - 94 fixed, 20 changed by Grilldyret (114)
13:43<petern:#openttd>Rubidium, didn't we change it so that the date was start date instead of load date?
13:43<petern:#openttd>(at least, for network games)
13:43<petern:#openttd>((if not, why didn't we?))
13:44<@Rubidium:#openttd>I fear we didn't and I fear it's (Belugas, don't read the rest of the sentence) getting caught in real life and being forgotten
13:53<Eddi|zuHause:#openttd>i thought someone recently said something along the line of "the code looks like it uses the start"
13:54-!-dfox [~dfox@r5cv134.net.upc.cz] has joined #openttd
13:55<@Rubidium:#openttd>Eddi|zuHause: more likely "the code should use the start"
13:56<+glx:#openttd>but the grf checks current date
14:00<Eddi|zuHause:#openttd>grah... i wanted to point to the logs entry, but there are no logs for the given date...
14:00<@Rubidium:#openttd>http://rbijker.net/openttd/sync_newgrf_start_values.diff <- like so
14:01<Eddi|zuHause:#openttd>you should probably just change "on build or load" to "on build, load or save"
14:02<Yorick:#openttd>wouldn't that look ugly with TTRS?
14:02<Eddi|zuHause:#openttd>anyway:
14:02<Eddi|zuHause:#openttd>[Do Dez 25 2008] [08:17:27] <De_Ghosty> like 80%
14:02<Eddi|zuHause:#openttd>[Do Dez 25 2008] [08:17:41] <De_Ghosty> cuz some vheical spent all year in a station waiting
14:03<@Rubidium:#openttd>and that is relevant in what way?
14:03<Eddi|zuHause:#openttd>that was a reply to the "on load or on start" question
14:11<Wolf01:#openttd>Rubidium, sorry but I can't find the right commit message, how many companies can be created and how many clients can now connect simulteaneously to a MP game?
14:13<Eddi|zuHause:#openttd>15 and 255
14:14<Wolf01:#openttd>thank you
14:15-!-tim [~chatzilla@port-92-201-83-220.dynamic.qsc.de] has joined #openttd
14:16-!-tim [~chatzilla@port-92-201-83-220.dynamic.qsc.de] has left #openttd []
14:18-!-Yexo [~Yexo@32-88-ftth.onsneteindhoven.nl] has joined #openttd
14:18<Yexo:#openttd>good evening
14:19<Wolf01:#openttd>good evening Mr.Yexo
14:25<George:#openttd>Rubidium: So, does meant that ASAP general desync question is solved there would be no problem for houses to use callback on start and build, checking the date?
14:31<Eddi|zuHause:#openttd>hm... this asterix film is silly...
14:31-!-OwenS [~OwenS@host86-128-252-186.range86-128.btcentralplus.com] has quit [Remote host closed the connection]
14:33-!-Zealotus [~Ping@78-69-54-150-no70.tbcn.telia.com] has joined #openttd
14:35-!-OwenS [~OwenS@host86-128-252-186.range86-128.btcentralplus.com] has joined #openttd
14:40<@Rubidium:#openttd>George: the problem is that the desync question is likely to be unsolvable
14:53<George:#openttd>Rubidium: If desyncs are unsolvable, than why not to provide CB then? It does not matter, if they would cause desync, and desyncs may happen anyway and can't be solved.
14:54<edeca:#openttd>Where's the list of stuff that needs fixing in the copy&paste patch?
14:55<edeca:#openttd>I can't see it in flyspray or the wiki
14:55<Yorick:#openttd>edeca: start by removing most of the macros
14:56<@Rubidium:#openttd>George: it's the callback that will be the cause of desyncs
14:56<Yorick:#openttd>then try to optimize duplicated lines
14:56<edeca:#openttd>Yorick: I'll put that on my list of stuff to look at, the 2nd is already on my list
14:56<@Rubidium:#openttd>edeca: it's scattered around the forum I reckon
14:56<edeca:#openttd>Rubidium: Ah darn :)
14:57<Yorick:#openttd>then extend the multiplayer protocol so that it can send the whole template at once
14:57<edeca:#openttd>I was going to look at signal types first, as there seem to be sensible functions for them HasSignalOnTrackdir etc
14:57<@Rubidium:#openttd>and probably also in the IRC logs
14:57<Yorick:#openttd>and the templates have no versioning ;)
14:57<edeca:#openttd>Yorick: Yeah, but that's not something I'm going to be able to fix easily ;)
14:58<edeca:#openttd>My C skills are really limited, but I might be able to do something
14:58<Yorick:#openttd>how's your c++?
14:58<George:#openttd>Rubidium: If you say "it will", then it means you know, how would it lead to desync and can provide a way to prevent it just for the exact case :)
14:59<edeca:#openttd>Yorick: Worse
14:59<George:#openttd>Or do you mean "it may cause"
14:59<Eddi|zuHause:#openttd>George: he can prevent one case, but then the grf authors will find ways that are not checked for
15:00<Yorick:#openttd>:(
15:00<Eddi|zuHause:#openttd>George: easy example
15:00<George:#openttd>Eddi|zuHause: How, if Rubidium knows how it will cause desync? All, the GRF can do, is to provide CB result, nothing more
15:01<Yorick:#openttd>also, the templates need compression
15:01<Eddi|zuHause:#openttd>let's assume you have a house callback that says: "this house has 10 population before 1925 and 20 after 1925"
15:01<Eddi|zuHause:#openttd>the first client joins in 1920, so his house has 10 population
15:01<Eddi|zuHause:#openttd>the second client joins in 1930, the callback is run on his side during load, but not on the first client
15:02<edeca:#openttd>Yorick: I assume they can be compressed like savegames?
15:02<Eddi|zuHause:#openttd>so the second client has a house with population 20, at the same spot, where the first client has population 10
15:02<Eddi|zuHause:#openttd>=> desync
15:02<Eddi|zuHause:#openttd>do you understand?
15:02<George:#openttd>Eddi|zuHause: if he joins to exssiting game, he should check day of build, not current day - so they both should get 10
15:03<George:#openttd>if a new house appears - they both get 20
15:03<Yorick:#openttd>edeca: yes, you could use the zlib compression
15:04<Yorick:#openttd>edeca: also, it should make use of the new command param that can specify signal direction instantly if you're going to use the DoCommands
15:04<Eddi|zuHause:#openttd>George: well, might not be the best example, but it should illustrate the point
15:04<George:#openttd>Isn't joining is like loadidn the game, that exists on the server?
15:04<Yorick:#openttd>and it should clear land that is needed for terraforming
15:04<edeca:#openttd>Yorick: Hrm, lots of notes ;)
15:04<Eddi|zuHause:#openttd>and usage of this kind of callback cannot be checked
15:04<Yorick:#openttd>and not try to clear land that is already clear
15:04<edeca:#openttd>Yorick: I hate the way it clears land
15:04<edeca:#openttd>Yorick: Should it ignore sea tiles?
15:04<George:#openttd>Eddi|zuHause: Why?
15:04<Yorick:#openttd>edeca: nah, just warn :p
15:04<Yorick:#openttd>and it should check for money before start if it doesn't already do so
15:05<edeca:#openttd>Yorick: It supports shift-click, so it might support money
15:05<Yorick:#openttd>option to convert to newest bridge type automagically
15:05<edeca:#openttd>Yorick: It does that
15:05<edeca:#openttd>Yorick: Not sure if it does it correctly
15:05<George:#openttd>Eddi|zuHause: No, I do not understand how can cause desync if the process (desync reason) is well known
15:05<Eddi|zuHause:#openttd>George: because the callback engine of NFO is turing complete
15:05<Yorick:#openttd>the sprites should reside somewhere else
15:05<Yorick:#openttd>the array size needs to be variable some way
15:06<George:#openttd>Eddi|zuHause: What did you mean with your last text?
15:06<edeca:#openttd>Yorick: It currently uses a "biggest size" array, wont that do?
15:06<edeca:#openttd>Yorick: It's more cycles to count the amount of space needed surely, you'd have to check every tile
15:06<Yorick:#openttd>wasn't there something about memory usage?
15:06<Eddi|zuHause:#openttd>George: "turing complete" is an expression of theoretical computer science.
15:07<Yorick:#openttd>look at even the most basic template file
15:07<George:#openttd>what does it mean? And what does it mean here?
15:07<Yorick:#openttd>when you copy the biggest space possible
15:07<Yorick:#openttd>it uses that, permanently
15:07<edeca:#openttd>Yorick: Ah, yes I see. But zlib compression would help that enormously?
15:07<Yorick:#openttd>not on memory usage ;)
15:08<edeca:#openttd>Yorick: Oh, in memory. Sorry :0
15:08<Eddi|zuHause:#openttd>a calculation system is "turing complete" if any problem that can be solved with a turing machine can be solved with this system
15:08<Yorick:#openttd>edeca: I'll try to see what zlib does ;)
15:08<edeca:#openttd>Yorick: Hrm, well that's a problem if the buffer stays around a while
15:08<Yorick:#openttd>it stays around when loading
15:08<edeca:#openttd>Well, you could gzip a .tpl to get an idea :)
15:08<Yorick:#openttd>yes, that
15:08<Eddi|zuHause:#openttd>and backwards, any problem that could possibly be solved by any computer can be solved with a turing machine
15:09<George:#openttd>Eddi|zuHause: I can't understand, if you know one of desync rules, why can't you make the code to prevent it?
15:09<Eddi|zuHause:#openttd>and then there are proofs about problems that cannot be solved by a turing machine
15:09<Yorick:#openttd>the template format needs a rework
15:09<Yorick:#openttd>and documentation
15:09<edeca:#openttd>Yorick: Well most of these problems can be tackled invididually from what you're saying
15:09<edeca:#openttd>Yorick: So for tonight, I might take a look at the macros and see what sort of a state it is in
15:10<Eddi|zuHause:#openttd>George: the problem is, for a callback to be desync-proof, it must yield the exact same value on each side. and that is something that cannot be proven
15:10<Eddi|zuHause:#openttd>George: SOME callbacks may be safe, but others might not
15:10<Eddi|zuHause:#openttd>and there is no way to tell them apart
15:10<Eddi|zuHause:#openttd>so the only way to really make sure they are safe, is to make them constant
15:10<Yorick:#openttd>I think the macro usage is down a bit
15:11<edeca:#openttd>Yorick: What's wrong with them, just overuse?
15:11<Yorick:#openttd>can't find anything currently
15:11*edeca:#openttd crosses that off the list
15:11<Yorick:#openttd>oh, just converted :p
15:11<Yorick:#openttd>void CopyPaste::CP_PlaceRoad(TileIndex tile, uint8 road_bits)
15:11<Yorick:#openttd>it has that for every type of commmand it does
15:12<edeca:#openttd>Yes, it does have a 1 line function per action
15:12<edeca:#openttd>Which seems odd
15:12<Yorick:#openttd>it seems to have 8 map arrays
15:12<Yorick:#openttd>previously macros
15:12-!-Dred_furst [~Dred_furs@90.242.99.253] has quit [Quit: Leaving]
15:12-!-HerzogDeXtEr [~Flex@88.130.191.153] has joined #openttd
15:13<edeca:#openttd>So, what to start on. Hrm. I hate the way it doesn't copy signals right
15:14<petern:#openttd>burp
15:14<Yorick:#openttd>CMD_BUILD_SIGNALS should have new parameters
15:14<Yorick:#openttd>that allow you to specify direction instantly
15:14<Eddi|zuHause:#openttd>Schultz
15:14<edeca:#openttd>Yorick: It needs to look at the type of signals too
15:14<Yorick:#openttd>that'd be the second thing to do
15:14*Eddi|zuHause:#openttd slaps everyone in the channel on the forehead
15:15<Yorick:#openttd>aw
15:15*edeca:#openttd enjoys
15:15<petern:#openttd>Rubidium, committed?
15:15<George:#openttd>Eddi|zuHause: As I understood you, checking the date makes it unsafe. But every CB is unsafe than, because it can check the date?
15:15<@Belugas:#openttd>George, the only way for a callback like that to not happen is for the data to be set on the map array. All other ways are just asking for trouble. The idea of our networking system is to provide no differences between server and client. Any differences lead to desyncs
15:15<@Belugas:#openttd>i shold have realized that when i was telling you of my plan :(
15:15<Eddi|zuHause:#openttd>George: no, only those that are not saved in the map
15:16<petern:#openttd>don't houses have a build date stored on the map?
15:16<Yorick:#openttd>edeca: it has 8 different map arrays :p
15:16<George:#openttd>petern: good question
15:16<@Belugas:#openttd>they do (asair)
15:16-!-Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has joined #openttd
15:17<George:#openttd>Belugas: And what the problem then? I check and return population according to it.
15:17<Yorick:#openttd>edeca: and the magical values it uses should be enumified
15:17<edeca:#openttd>Yorick: Yeah, they're ugly. I'll fix that as I come to them
15:17<@Belugas:#openttd>one problem is the fact that the population cannot be on the map, since there is no room
15:17<edeca:#openttd>Yorick: Currently looking where to start is a nightmare. I'm looking at CMD_BUILD_SIGNALS
15:18<Yorick:#openttd>you should overload void CopyPaste::CP_PlaceSignals(TileIndex tile, uint8 track, bool cycleSignalType, bool semaphore)
15:18<petern:#openttd>so every time it's needed it needs another CB test
15:18<edeca:#openttd>Yorick: Hrm, do you think those need keeping then? 1 line per function?
15:18<Yorick:#openttd>it's easier to start with ;)
15:19<edeca:#openttd>Yorick: Heh true!
15:19<Eddi|zuHause:#openttd>petern: means recalculating the town population every time a house is queried
15:19<@Belugas:#openttd>second problem is that the CB will need to be run cyclickly, plus as soon as someone joins too in order to the safe
15:19<@Belugas:#openttd>mm... and that too, indeed, Eddi|zuHause
15:19-!-HerzogDeXtEr1 [~Flex@89.246.219.173] has quit [Ping timeout: 480 seconds]
15:20<edeca:#openttd>Yorick: Are you Yorick on the forums too?
15:20<Yorick:#openttd>I think so
15:20<Eddi|zuHause:#openttd>edeca: no, that is a different Yorick
15:20<edeca:#openttd>Eddi|zuHause: I didn't look to see if there *was* one on the forums ;)
15:20-!-Yorick is now known as yorick
15:20*edeca:#openttd throws socks at Eddi|zuHause
15:21<Eddi|zuHause:#openttd>eeww...
15:21<Eddi|zuHause:#openttd>i hate cheese
15:21<yorick:#openttd>edeca: it should handle error messages in another way
15:21<edeca:#openttd>yorick: What would you suggest?
15:21<yorick:#openttd>it should abort when CmdFailed ;)
15:22<edeca:#openttd>Ah! And error?
15:22<George:#openttd>Belugas: But what's the problem? It will get the same result, because the data for test is stored in the map??
15:22<yorick:#openttd>if possible, it should first dry-run at every stage of laying
15:23<yorick:#openttd>if, offcource, you're gonna keep the docommands
15:23<George:#openttd>I have to go to sleep, but I can't understand yet, what makes this CB to desync the game.
15:23<yorick:#openttd>it's easier, but uglier
15:23<edeca:#openttd>yorick: My intention was to make it work in the easiest but nicest way
15:24<yorick:#openttd>"/** This function calculates the ehight the given tile will have */"
15:24<yorick:#openttd>int8 CopyPaste::ClampToRight()
15:24<yorick:#openttd>:o
15:24<edeca:#openttd>Now you've lost me
15:25*tokai:#openttd detects a typo
15:25-!-Irssi: You are now talking in #openttd
---Logclosed Mon Dec 29 15:25:25 2008
---Logopened Mon Dec 29 15:25:27 2008
15:25<yorick>that's a quote :p
15:25<yorick>tokai spoke!
15:25<edeca>Comments don't get compiled :)
15:25<+glx>not a valid reason
15:25<Yexo>what is the best solution to force a patch value to something for all savegames that didn't have that patch value? Just adding an CheckSaveGameersion in openttd.cpp?
15:25<edeca>glx: Yes but not the *worst* bug in it..
15:26<yorick>Yexo: something with setting the default?
15:26<yorick>yes, it is
15:26<Yexo>yorick: I've set the default, but openttd seems to prefer the value from the config file above the default value for old savegames
15:27<yorick>CheckSavegameVersion in AfterLoadGame ;)
15:27<Eddi|zuHause>there should be plenty of instances already there ;)
15:28-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has quit [Quit: This computer has gone to sleep]
15:28<+glx>will need a new "instance" of it as it requires a savegame bump
15:29-!-NukeBuster [~NukeBuste@80.101.115.82] has joined #openttd
15:29<@Rubidium>petern: the map stores the age of houses, which is capped at 255
15:29<Eddi|zuHause>i meant as examples, not for hijacking :p
15:30-!-Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has quit [Quit: Leaving]
15:30<Eddi|zuHause>just prevent games from lasting more than 255 years :p
15:31<Eddi|zuHause>really, we should introduce some kind of layered map, and houses may reserve more than one layer for storing data
15:31<+glx>Eddi|zuHause: show us a working version :)
15:31<@Rubidium>I tried that and it's *much* slower
15:32<@Rubidium>factor 3 to 4-ish
15:36<CIA-2>OpenTTD: rubidium * r14769 /trunk/src/newgrf.cpp:
15:36<CIA-2>OpenTTD: -Change: when loading games in "network" mode use the start date of the save
15:36<CIA-2>OpenTTD: game for the server and all clients when loading the NewGRFs instead of the
15:36<CIA-2>OpenTTD: current date. Prevents desyncs caused by action 7/9s skipping parts of the GRF
15:36<CIA-2>OpenTTD: based on the date or some other variables that can differ at NewGRF load time.
15:36<edeca>Is there an irc log kept online that I can refer to?
15:37<@Rubidium>SpComb keeps logs and you could take a look at thegrebs.com
15:37<Eddi|zuHause>Rubidium: so now TTRS roads will eternally have the old style?
15:37<Sacro>http://zapotek.paivola.fi/~terom/logs/openttd
15:37<@Rubidium>Eddi|zuHause: yes
15:38<@Rubidium>unless you start the game after a certain date
15:38<edeca>Sacro: Ta
15:38<@Rubidium>and only for network games
15:40-!-Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has joined #openttd
15:42<@Rubidium>George: the only way to stop desync due to NewGRFs is getting completely rid of *all* actions 2, 6, 7, 9, A, D and E
15:42<yorick>any recent windows binary of grfcodec?
15:43<edeca>yorick: Right, I've just looked at CopyPaste::CP_PlaceSignals and boy is it ugly
15:43<@Rubidium>which is basically everything that can read data from outside the NewGRF
15:43-!-Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has quit [Read error: Connection reset by peer]
15:43<edeca>yorick: So what were you suggesting was wrong with it? Other than the fact it doesn't store the signal type, only whether it is semaphore or not
15:43<yorick>heh
15:44<yorick>that it doesn't store the direction?
15:44<edeca>yorick: Hrm, so how does it reverse it? Or even remember it in the first place..
15:45<yorick>it calls the function multiple times for different directions and types
15:45<edeca>Ah! I should have looked there. I see what you were suggesting now. So overload that with one function which takes direction & type in a sensible format :)
15:46<yorick>yes
15:47<edeca>So looking at the way the game stores track internally, whether it has a signal or not is a bitmask against the actual track tile?
15:47<yorick>no idea, CmdBuildSignal might provide clues
15:49<Eddi|zuHause>edeca: map storage should be completely abstracted through map accessors
15:49<edeca>Eddi|zuHause: I wasn't trying to change anything, sorry. Was just looking at how DoCommandP works
15:49<@Belugas>not should... MUST
16:00<yorick>edeca: the command queue should have another CallCommandQueueTick() thing
16:01<edeca>yorick: Damnit, you're very demanding! :)
16:01<edeca>yorick: I'm only just figuring out how the signal copying works. I'm guessing I can use HasSignals() to completely skip signal checking if it's not needed.
16:01<edeca>s/checking/copying
16:02<edeca>Oh, idiot, it does that :)
16:02<edeca>Helps if you scroll up sometimes.
16:06-!-mikl_ [~mikl@gw.imtnet.dk] has joined #openttd
16:06<yorick>CmdBuildSingleSIgnal has a nice comment :0
16:06<yorick>bit 15-16 allow to cycle signal direction x times
16:07-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has joined #openttd
16:07<yorick>bit 5-7 are SignalType
16:08<edeca>It's weird, the patch copies signal type but doesn't paste them
16:09<yorick>current?
16:10<edeca>SOrry?
16:11<edeca>current what?
16:11<yorick>CommandContrainer from command_queue.h, doesn't that do quite the same as CommandPacket?
16:11<yorick>you mean with pbs?
16:12<edeca>Well bits 11-13 of the template array store signal type from GetSignalType
16:12-!-mikl [~mikl@gw.imtnet.dk] has quit [Ping timeout: 480 seconds]
16:13<edeca>But they're not used when pasting
16:13-!-rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has joined #openttd
16:14<edeca>Is there a way to get the track direction from a tile? Rather than what the patch currently does, cycling through each direction speculatively
16:14<edeca>Can I use GetTrackBits for that somehow?
16:15<yorick>huh?
16:16<edeca>Well at the minute, the patch cycles through this: if (HasTrack(tile, TRACK_Y) && HasSignalOnTrack(tile, TRACK_Y)) { for each direction
16:16<edeca>I think I can change that and replace TRACK_x with GetTrackBits()
16:18<yorick>for_each_trackbit or something?
16:19<yorick>or loop trough GetTrackBits result
16:19<edeca>Well I don't think you need to enumerate through. Signals can only be placed where there's a single TrackBit
16:19<Eddi|zuHause>no, there can be two trackbits
16:19<edeca>Ah damn.
16:19<edeca>Is a straight track in two parts? :(
16:19<yorick>no
16:20<yorick>the horizontal one can be
16:20<yorick>______
16:20<yorick>__________
16:20<edeca>Yep, that makes sense.
16:21<flexd>!ip
16:21-!-flexd was kicked from #openttd by DorpsGek [Wrong channel. Retry in #openttdcoop.]
16:21<Mark>anyone knows about people being disconnected from multiplayer games with the reason: (not enough cash - requires $0)
16:21-!-flexd [~flexd@127.79-160-12.customer.lyse.net] has joined #openttd
16:21<Eddi|zuHause>i haven't seen that in a long time :p
16:21<flexd>You know.. it could just say that >_<
16:21<edeca>And that would return TRACK_BIT_HORZ from GetTrackBits?
16:21<flexd>I pressed the wrong window :P
16:21<@Rubidium>Mark: what version?
16:21<edeca>Which can't have a signal. Hrm, so that approach wont work. Cycling through in a loop is the way to go then I guess.
16:21<Eddi|zuHause>flexd: but if it just said that, people would not take notice
16:22<Mark>r14786
16:22<@Rubidium>and is the message from the server or the client?
16:22<Mark>not sure
16:23<Mark>i was just checking if it was a known issue :P
16:23<Mark>i could post you a screenie?
16:23<@Rubidium>a screenshot isn't useful
16:23<@Rubidium>in this case at least
16:23<@Rubidium>knowing whether the message was shown on the server or the client or both is
16:24<Mark>how can i tell if it's from the server or the client?
16:24<Mark>i'll ask
16:25<edeca>OK, so is the nicest way to say for(x=TRACK_BEGIN;x<TRACK_END;x++) then? Rather than check each direction manually?
16:26<yorick>make it i ;)
16:26<@Rubidium>maybe use FOR_EACH_SET_BIT ?
16:26<yorick>or that ^^
16:27<edeca>yorick: Heh don't worry about actual names, I'm grepping other source code for the exact format (and reading the wiki)
16:28<edeca>Rubidium: For each set bit in what, GetTrackBits?
16:28<yorick>mhm
16:28<@Rubidium>yes
16:28<edeca>Ah!
16:29<edeca>Enlightenment feels great.
16:29<@Rubidium>Mark: and I'd like to know the exact message, i.e. what was for the "(not enough cash..."
16:31<Mark>... has left the game (Not enough cash - requires $0)
16:31<Mark>though he didnt leave but got disconnected
16:32<Mark>well he did leave, but not on purpose :P
16:32<yorick>if (!dosomething) dosomethingelse(); else donothing(); doanothersomething(); <-- that is ugly
16:32<yorick>there was another if in there :p
16:33<Mark>it seems to be giving different amounts of cash in different currencies to different people on the server
16:33<CIA-2>OpenTTD: rubidium * r14770 /trunk/src/network/network_client.cpp: -Fix: gracefully handle an invalid packet instead of asserting.
16:34<Eddi|zuHause>Mark: my guess is that it is displaying the wrong message
16:34<@Rubidium>Mark: 14786 doesn't exist yet
16:35<edeca>yorick: http://paste.openttd.org/178262 is my start.. sorry about indent
16:35<Mark>768, sorry
16:35<Mark>today's
16:35-!-gryph [~gryph@0x50a1213f.hrnxx7.dynamic.dsl.tele.dk] has joined #openttd
16:36<Eddi|zuHause>possibly related to r14764, but i don't have any further insight
16:36<yorick>edeca: I'm getting it to compile first :p
16:36-!-terjesc [terjesc@horisont.pvv.ntnu.no] has joined #openttd
16:37<edeca>Er, I've done that..
16:37<edeca>I've got it working with trunk
16:37<edeca>Last night!
16:37<Eddi|zuHause>yorick: when nesting if statements, use {} to clarify the position of else clauses
16:38<yorick>I know
16:38<edeca>Oh, so what doesn't compile?
16:38<edeca>My code there doesn't, because it's not right yet :)
16:38<yorick>the docommands and player<>company changes
16:38<edeca>Er I fixed that, last night
16:38<edeca>Like I said.
16:39<edeca>yorick: http://www.tt-forums.net/viewtopic.php?p=753163&sid=639f1cc994e76ccf9886e50dc3d93cce#p753163
16:39<edeca>Except my session ID, heh
16:39<yorick>it works here now
16:39<yorick>ooh
16:39<yorick>session ID :p
16:39<edeca>Sorry if you've just wasted all that time :(
16:39<edeca>I was logged out, session ID is invalid ;)
16:39<edeca>Back in a few minutes.
16:39-!-Wolf01 is now known as Guest1914
16:39-!-Wolfolo|AWAY [~wolf01@host105-233-dynamic.14-87-r.retail.telecomitalia.it] has joined #openttd
16:39-!-Wolfolo|AWAY is now known as Wolf01
16:40<yorick>:(
16:41<CIA-2>OpenTTD: rubidium * r14771 /trunk/src/network/network.cpp: -Fix (r14764): resolving of error types to error messages kinda failed :(
16:43<edeca>Right, back
16:43<edeca>Got kicked off my own PC! How rude.
16:43<edeca>So are we both in the same position now? ;)
16:44-!-rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has quit [Read error: Connection reset by peer]
16:45-!-Guest1914 [~wolf01@host105-233-dynamic.14-87-r.retail.telecomitalia.it] has quit [Ping timeout: 480 seconds]
16:45-!-rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has joined #openttd
16:45-!-murr4y [murray@2001:470:1f0a:1be::42] has quit [Ping timeout: 480 seconds]
16:47-!-Celestar [~Jadzia_Da@mnch-5d870451.pool.einsundeins.de] has joined #openttd
16:47-!-mode/#openttd [+o Celestar] by ChanServ
16:49<edeca>yorick: Poke!
16:50-!-NukeBuster [~NukeBuste@80.101.115.82] has quit [Quit: http://www.interplay.com/]
16:50<CIA-2>OpenTTD: rubidium * r14772 /trunk/ (11 files in 3 dirs): -Codechange: make the "dump log of game to reproduce" desync debug stuff a runtime configurable debug option instead of a compile time option.
16:51-!-murr4y [murray@2001:470:1f0a:1be::42] has joined #openttd
16:51<@Rubidium>good evening Celestar
16:54<edeca>Rubidium: Silly question, will using FOR_EACH_SET_BIT with a TrackBits have the same effect as with a Track?
16:54<edeca>Rubidium: I understand enums but get confused with << bit shifting
16:55<edeca>I get the TrackBits from GetTrackBits but want to check for signals, which are only valid on X/Y/UPPER/LOWER
16:55<edeca>(etc)
16:55*Rubidium has no idea what edeca wants to know
16:55<yorick>FOR_EACH_SET_BIT only works on track
16:55<yorick>trackbits*
16:56<yorick>it does not work on Track
16:56<yorick>as those aren't bits
16:56<edeca>Ah! Of course, they're just numbers
16:56<edeca>Right, so I'm going about it the right way with my preliminary paste, just not there yet
16:56-!-nekx [~asd@0x3e42e6e6.adsl.cybercity.dk] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )]
16:58<edeca>yorick: HasSignalOnTrack expects a Track though, so how to work around that?
16:58<Eddi|zuHause>TrackdirToTrack?
16:58<edeca>Eddi|zuHause: Ah! :)
16:59<edeca>Sorry, I'm not intentiionally stupid
16:59<yorick>*cough*TrackBitsToTrack*cough*
16:59<edeca>Heh, that's the one
16:59<edeca>But grepping found it
16:59<Eddi|zuHause>err, yes, of course
17:00<Eddi|zuHause>but at least the compiler should have complained about incompatible types :p
17:00<edeca>Eddi|zuHause: It did, that's how I spotted it ;)
17:01<edeca>Except I've been kicked off my PC by somebody who is internet shopping, gr. And I don't have cygwin on this one
17:01<Eddi|zuHause>that is simple, just ssh into your other computer...
17:02<edeca>Heh, I haven't got round to setting that up yet
17:03<yorick>cygwin :o
17:03<edeca>And if I kick her off, we will have no food ;)
17:03<edeca>yorick: That's what I develop with, just never needed an ssh server
17:04<yorick>heh, mingw :)
17:04<yorick>own pc :)
17:05*Belugas thinks it's time to return home and join the family
17:05*Belugas waves bye bye to all who are still standing
17:05<@Rubidium>night Belugas
17:06<@Belugas>night Rubidium :) have fun, as always hehe
17:06*Belugas is gone
17:07<edeca>yorick: So are you actually doing work on it now? I don't want to duplicate effort. You can see what I've done from the forum post and the pastebin earlier.
17:07<edeca>yorick: I'll finish off that pastebin patch tomorrow during quiet time at work ;)
17:09-!-jawsper [~jawsper@P85ae.p.pppool.de] has quit [Ping timeout: 480 seconds]
17:13-!-jawsper [~jawsper@P85ae.p.pppool.de] has joined #openttd
17:14<edeca>I'm off to sleep now, cheers yorick and Eddi|zuHause for your help
17:14<edeca>yorick: Drop me a PM on here or the forums (I'm davidc) if you do any more.. I don't want to duplicate anything
17:14*edeca goes
17:14<yorick>k
17:29-!-rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has quit [Ping timeout: 480 seconds]
17:44-!-OwenS [~OwenS@host86-128-252-186.range86-128.btcentralplus.com] has quit [Remote host closed the connection]
17:48-!-Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has joined #openttd
17:49-!-Celestar [~Jadzia_Da@mnch-5d870451.pool.einsundeins.de] has quit [Ping timeout: 480 seconds]
17:52<Eddi|zuHause>cool vapourware this year... a gps/phone/camera that tells you where you parked your car
17:53-!-yorick [~Yorick@s55924da0.adsl.wanadoo.nl] has quit [Quit: Poef!]
17:54-!-gryph [~gryph@0x50a1213f.hrnxx7.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
17:58-!-|Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has quit [Quit: oO]
18:09-!-glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Read error: Connection reset by peer]
18:13-!-Jerimiah40 [~jerimiah4@h72-2-8-124.pmcnet.ca] has quit [Ping timeout: 480 seconds]
18:13-!-glx [~glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd
18:13-!-mode/#openttd [+v glx] by ChanServ
18:14-!-Jerimiah40 [~jerimiah4@h72-2-8-124.pmcnet.ca] has joined #openttd
18:17-!-glx [~glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Read error: Connection reset by peer]
18:21-!-Eddi|zuHause2 [~johekr@p54B7603A.dip.t-dialin.net] has joined #openttd
18:25-!-Eddi|zuHause [~johekr@p54B77DAE.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
18:27-!-lewymati [~lewymati@aejc19.neoplus.adsl.tpnet.pl] has quit []
18:47-!-TinoM| [~Tino@i59F5CA26.versanet.de] has quit [Quit: Verlassend]
19:00-!-Vikthor [~Vikthor@161-18-80-78.strcechy.adsl-llu.static.bluetone.cz] has quit [Remote host closed the connection]
19:07-!-Swallow [~chatzilla@5355F5FD.cable.casema.nl] has quit [Quit: ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]]
19:09-!-mikl_ [~mikl@gw.imtnet.dk] has quit [Remote host closed the connection]
19:23-!-Mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has quit [Remote host closed the connection]
19:23-!-Mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has joined #openttd
19:24-!-OwenS [~OwenS@host86-128-252-186.range86-128.btcentralplus.com] has joined #openttd
19:28-!-roboboy [3aad2910@webchat.mibbit.com] has joined #openttd
19:28-!-roboboy [3aad2910@webchat.mibbit.com] has quit []
19:28-!-roboboy [3aad2910@webchat.mibbit.com] has joined #openttd
19:33-!-Eddi|zuHause2 [~johekr@p54B7603A.dip.t-dialin.net] has quit []
19:33-!-Eddi|zuHause2 [~johekr@p54B77DC2.dip.t-dialin.net] has joined #openttd
19:46-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has quit [Quit: This computer has gone to sleep]
19:50-!-Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has quit [Read error: Connection reset by peer]
19:58-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has quit [Ping timeout: 480 seconds]
20:03-!-Brianetta [~brian@client-82-3-228-220.glfd.adsl.virgin.net] has quit [Quit: Tschüß]
20:09-!-svip [~svip@0x53589c76.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
20:10-!-glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd
20:10-!-mode/#openttd [+v glx] by ChanServ
20:13-!-tokai [~tokai@p54B8403B.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
20:15-!-tokai [~tokai@p54B83EDB.dip0.t-ipconnect.de] has joined #openttd
20:15-!-mode/#openttd [+v tokai] by ChanServ
20:18-!-jawsper [~jawsper@P85ae.p.pppool.de] has quit []
20:36-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Ping timeout: 480 seconds]
20:54-!-OwenS [~OwenS@host86-128-252-186.range86-128.btcentralplus.com] has quit [Remote host closed the connection]
20:55<Wolf01>'night
20:55-!-Wolf01 [~wolf01@host105-233-dynamic.14-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
20:55-!-Progman [~progman@p57A1C80A.dip.t-dialin.net] has quit [Remote host closed the connection]
21:01<Wolle>I'm playing rcpp (r13691) with ecs - sombody knows how to transport petrol? ...petrol trains won't load...they wait and wait and wait and...
21:02<Eddi|zuHause2>Wolle: custom builds are not supported here
21:03<Eddi|zuHause2>there is a thread in the forum, maybe you can ask there
21:03-!-Mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has quit [Quit: Checking whether build environment is sane ... build environment is grinning and holding a spatula. Guess not.]
21:06<Wolle>ahh Eddi|zuHause2 i'm not looking for support...just for a hint
21:06-!-Eddi|zuHause2 is now known as Eddi|zuHause
21:06<Wolle>thread in the forum sounds good..but what i have to search for?
21:06<+glx>you need a train set that can transport petrol
21:07<Wolle>i have a set that supports petrol... - i can refit it to it ...
21:08<Wolle>but the trains won't load petrol...
21:10<Wolle>..i'm (almost) sure i've read all wikis and searched all forums but i couldn't find a solution
21:11<+glx>petrol != oil
21:11<Wolle>yes? ...?
21:11<Wolle>=yes! ...?
21:12<+glx>which set are you using?
21:12<Wolle>what do you mean whith "set"? i'm usin rcpp with ecs
21:13<+glx>train grf
21:13<Wolle>dbsetxl with ecs extension
21:14<+glx>then it should work
21:14<Wolle>hm *grmpf*
21:14<+glx>try with a nightly
21:15<Wolle>no the nightlies don't have the features i need more than petrol
21:15-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has joined #openttd
21:15<+glx>but you can check if you can transport petrol
21:17-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has quit []
21:17<Wolle>that's right...you have one second? ...i'll getting the last nighly and set the options as in my game - could take 5 minutes...
21:18<Wolle>in rcpp (r14239) transporting petrol won't work too, the trains stay at the stations for ages but won't load anything
21:25-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has joined #openttd
21:26-!-Yeggstry is now known as Yeggzzz
21:27-!-roboboy [3aad2910@webchat.mibbit.com] has quit [Ping timeout: 480 seconds]
21:29-!-roboboy [3aad2910@webchat.mibbit.com] has joined #openttd
21:30-!-roboboy [3aad2910@webchat.mibbit.com] has quit []
21:30-!-roboboy [3aad2910@webchat.mibbit.com] has joined #openttd
21:31-!-Digitalfox [~Digitalfo@bl11-5-80.dsl.telepac.pt] has joined #openttd
21:33<Eddi|zuHause>Wolle: then it probably is a compatibility problem with dbxl-ecs and ecs
21:54-!-Sionide- [sionide@cornflakes.imen.org.uk] has joined #openttd
21:54-!-Sionide [sionide@cornflakes.imen.org.uk] has quit [Read error: Connection reset by peer]
21:55<Wolle>Eddi|zuHause ...i'm playing a outdated version, in the latest build of rcpp the chemical plant won't produce petrol...i''ll update and add the missing feature to my "you have to implement list"...
21:55-!-Sionide- is now known as Sionide
22:13-!-glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Quit: bye]
22:19-!-baudchan [~princess@c-71-233-42-192.hsd1.nh.comcast.net] has quit [Quit: This computer has gone to sleep]
23:00-!-Zorni [zorn@e177225240.adsl.alicedsl.de] has joined #openttd
23:02-!-elmex_ [~elmex@e180064163.adsl.alicedsl.de] has joined #openttd
23:07-!-elmex [~elmex@e180068079.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds]
23:07-!-elmex_ is now known as elmex
23:08-!-Zorn [zorn@e177228160.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds]
23:24<George>Rubidium: rid of actions 2? May be we do not need GRFs at all? :) In this case I'd suggest to stop viewing desync reason in the point of view for callbacks realisation. I mean CB question should be done regardless desync question, why desync qestion should be viewed on its own.
---Logclosed Tue Dec 30 00:00:39 2008