IRC logs for #openttd on OFTC at 2008-12-29
⏴ go to previous day
00:03:37 <Markk> Hellu, havin a little problem with a railcrossin
00:04:14 <Markk> w8, shall upload a prtscr
00:06:06 <Markk> Yes, I'm not so serious about my typing right now
00:06:43 <Eddi|zuHause> you should be serious about typing, because we are.
00:06:54 <Markk> Okey then, I will be :)
00:07:17 <dihedral> i thought i could have been a theme on thingy-bob-OS
00:07:27 <Eddi|zuHause> and this is probably the most stupid screenshot i have ever seen
00:07:29 <dihedral> so - what's your prob?
00:07:44 <Markk> But I'm not so good at english right now though (tired and swedish is my motherlaunguage)
00:08:05 <dihedral> being good at, and being darn lazy are 2 different things ;-)
00:08:07 <Markk> I'm wondering if there is any better solution that can be used?
00:08:08 <dihedral> we can handle the one
00:08:27 <dihedral> checkout the junktionary at www.openttdcoop.org/wiki
00:08:31 <Eddi|zuHause> why play a mountaneous map when you flatten everything for your rails anyway?
00:08:54 <Eddi|zuHause> play a flat map right from the start, if you do not care about the landscape
00:09:09 <dihedral> and yes - double bridge per single track
00:09:23 <Markk> Eddi|zuHause: I'm not flattening everything out
00:09:29 <dihedral> Eddi|zuHause, it's more realistic :-D
00:09:38 <Eddi|zuHause> the rails are completely flat, Markk.
00:09:53 <XeryusTC> Eddi|zuHause: tell that to the british, they dug 160m for one of their tracks IIRC :P
00:10:18 <dihedral> Eddi|zuHause, perhaps the mountains grew after the tracks were down :-P
00:10:22 <XeryusTC> or it was 160 foot :P
00:10:29 <Markk> You've only seen a little part of that map, and I'm not begging for help to solve my problem with a lite rocky map
00:10:31 <dihedral> XeryusTC, and probably below see level
00:11:12 <dihedral> Markk, you upload a screenshot for comments, you get comments!
00:11:43 <dihedral> Eddi|zuHause, yes - that is a nice one :-)
00:12:04 <Markk> Eddi|zuHause: yes, but that's very inefficient
00:12:57 <Markk> The germans are not especially populair in sweden
00:13:06 <Eddi|zuHause> Mark: on the contrary, that structure is amazingly efficient
00:13:50 <mincepie> how can that possibly be more efficient than a straight line?
00:13:51 <XeryusTC> are the germans populair anywhere then?
00:13:56 <Eddi|zuHause> on a smaller scale than most openttdcoop structures, though
00:14:06 <Markk> XeryusTC: don't think so
00:14:41 <Eddi|zuHause> XeryusTC: not the germans themselves, but their products
00:14:54 <dihedral> XeryusTC, sure - germany, austria, switzerland
00:15:31 <Eddi|zuHause> germany has a higher export rate than the USA
00:15:38 <mincepie> VWG cars are among the finest available altogether and IMO the best available in many price ranges
00:15:44 <dihedral> try checking missiles :-D
00:15:54 <dihedral> they 'send' them abroad all the time
00:16:10 * Rubidium then wonders why the Germans are coming here en-masse to buy coffee
00:16:25 <Eddi|zuHause> yes, but they also have a problem with the trade deficit (export - import << 0)
00:16:35 <Eddi|zuHause> e.g. they import much more dead bodys
00:16:59 <mincepie> don't forget budget deficits!
00:17:23 <XeryusTC> Eddi|zuHause: the dutch only like you because you are silly enough to be worth 70% of our export :P
00:17:34 <mincepie> the UK and US have record deficits; the UK has national debt exceeding 40% of GDP
00:22:05 <Markk> We have blonde women that are great looking, that does not the UK, germany or austria have
00:22:24 <Markk> (And no, we're not exporting them)
00:22:50 <dihedral> "ob schwarz, rot, oder braun, Markk liebt nur blonde fraun"
00:23:02 <mincepie> the UK has adequate supplies of attractive young women, I believe
00:23:20 <mincepie> granted, there is something of a deficit since the 60s ended
00:23:22 <dihedral> adequate is something else
00:24:25 <dihedral> what the girls (sadly) do have is self-esteem
00:24:43 <dihedral> even those who are 'mildly' oversized
00:25:10 <dihedral> self-esteem in a way that they ware less then you'd hope for
00:25:27 <dihedral> at least that was oxford for me
00:25:28 <mincepie> you're blathering, man
00:26:02 <dihedral> london, richmond, 9am is a different picture :-)
00:26:35 <dihedral> but i never cared for london 9am when i was in oxford!
00:28:57 *** lobster has joined #openttd
00:33:14 *** Eddi|zuHause has joined #openttd
00:38:43 *** sigmund has joined #openttd
01:15:13 *** ChanServ sets mode: +v tokai
01:33:03 *** roboboy has joined #openttd
01:42:16 <CIA-1> OpenTTD: glx * r14762 /branches/noai/ (178 files in 15 dirs): [NoAI] -Sync: with trunk r14689:14761
01:53:08 <CIA-1> OpenTTD: glx * r14763 /branches/noai/src/ai/api/ai_sign.cpp: [NoAI] -Fix (r14762): a sync is not a sync if there isn't an error in it
02:09:29 *** Progman_ has joined #openttd
02:17:17 *** Progman_ is now known as Progman
03:30:53 *** Nite_Owl has joined #openttd
03:32:34 <mincepie> I must change that nick eventually
03:36:36 *** mincepie is now known as goodger
03:36:52 <goodger> I'll keep mincepie for the moment...
03:36:55 *** goodger is now known as mincepie
03:47:30 *** rangaparmastan has quit IRC
04:07:10 *** elmex_ is now known as elmex
04:18:18 <zircu> hmm.. ctl-G on my mack produces a black screen
04:18:47 <glx> giant screenshot is never a good idea
04:19:14 <glx> requires a lot of memory and can take more than 10 minutes
04:20:19 <zircu> 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
04:21:39 <zircu> i am running a game that is based on the nighly build
04:21:53 <zircu> i'm about a week old right now
04:22:55 <mincepie> how can it take 10 seconds to render to PNG what takes less than 1/30 second to render to screen? :S
04:22:57 <glx> ctrl-s takes a screenshot of what you currently see
04:23:13 <glx> ctrl-g takes a screenshot of the entire map
04:23:32 <zircu> what is the map that is looking at?
04:23:41 <zircu> i dont understand the difference
04:24:08 <glx> it's like if all the map was visible in the window with the same details
04:24:34 <zircu> it is true that ctrl-g takes a long time vs ctrl-s but i'm not exactly sure if i should worrry about it
04:24:56 <glx> usually you only need ctrl-s
04:28:15 <zircu> yeah, i'm knew here, i am working on a nightly build so i am sure i would want to say that since i relay a lot on the path signals
04:29:16 <zircu> a lot of stuff i read are based on non-path signals
04:32:17 <zircu> i dont know how many peoplel have adjusted their junctions and stuff to the PBS, i've been playing around with it
04:34:47 <zircu> i would like to add a wiki page for PBS junctions but i need advise from people that may see a flaw in the design
04:48:01 *** sigmund_ has joined #openttd
04:55:48 <ccfreak2k> One of them takes a picture of the WHOLE map (which can be as much as ten thousand pixels in either direction.
04:56:00 <ccfreak2k> OpenTTD probably doesn't usually bother drawing anything off-screen.
04:57:03 <ccfreak2k> zircu, hit ctrl-g. Wait. Go to your screenshot folder and find the newest screenshot.
04:57:11 <mincepie> interestingly, it sometimes doesn't bother to draw things that should be on-screen, but whose tile of origin is not
04:57:55 <zircu> ccfreak2k: yeah i have a black screen on my png on that image
04:58:42 <zircu> ccfreak2k: my main concern was what the difference was, i will do ctrl-s for examples
04:59:08 <ccfreak2k> mincepie, fast culling. :)
04:59:23 <mincepie> zircu: what filesize is the png?
04:59:34 <zircu> let me redo it just a sec.
05:02:18 <zircu> my ctrl-g size = about 9.1MB in png format
05:03:42 <zircu> my ctrl-s size == 140K and it is showing everything
05:04:29 <zircu> i am running a snapshot.. i can get that just in case
05:05:12 <zircu> i'm running r14657 for the mac
05:06:40 <mincepie> if you open the file in $text-editor is it a pattern, or is it apparently random? (look a few screens down...)
05:08:11 <zircu> open the file in a text editor.. not sure what to look for from there
05:09:01 <mincepie> the result should be a very, very large amount of garble
05:09:06 <zircu> yeah i'm going to be dropping it into vim
05:09:28 <mincepie> oh, if you're in bash, just cat it
05:10:25 <zircu> the first bytes are binary starting with the standard PNG header
05:11:25 <zircu> let me check a few differnt readers of png
05:12:09 <zircu> ah there we go, firefox is reading it but taking forever...
05:13:36 <zircu> this area could be optimized i think
05:14:05 <mincepie> ok, and the remaining few hundred screens?
05:14:05 <mincepie> if they are truly black it should be a simple repeating pattern
05:14:05 <mincepie> otherwise your png reader's fecked
05:14:10 <mincepie> were you using preview before?
05:14:18 <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
05:14:33 <zircu> preview refused to show the image when i double clicke it
05:14:48 <mincepie> in that case, the problem (like many other problems) is caused by apple.
05:15:24 <zircu> now i see the diff i know why i dont need to do ctrl-g
05:16:03 <zircu> let me try sfari anyway
05:16:06 <mincepie> I might have to go to bed in a minute
05:17:31 <zircu> i dont normaly use safari
05:17:41 <mincepie> either macs are slower than you claim, or safari has some horrific performance issue
05:18:18 <zircu> it is a PNG rendering issue
05:18:53 <zircu> safari loads it quickly, i can't blink that fast
05:19:05 *** grumbel has joined #openttd
05:19:32 <mincepie> you underestimate the speed of blinking
05:19:49 <zircu> well i blinked 2-3 times
05:20:17 <mincepie> *tut* this kernel isn't even properly popped
05:20:21 <zircu> with firefox i blinked several hundred times
05:20:52 <zircu> and 'preview' just showed a black screen
05:21:11 <mincepie> yes, preview is appalling
05:21:51 <zircu> what is bad is with the png I could watch each pixel line come in
05:22:30 <mincepie> damn, now I've run out of euro chocolate coins
05:22:48 <mincepie> will have to start on the "oversized 2p coin" chocolate coins
05:24:00 <zircu> how big are those coins?
05:24:22 <mincepie> a couple of inches in diameter, possibly
05:24:39 <mincepie> the normal ones are about half the size
06:03:19 *** svippery has joined #openttd
06:40:32 *** Deathmaker has joined #openttd
06:46:35 *** svippery has joined #openttd
07:35:28 *** Alberth has joined #openttd
07:40:24 <petern> ctrl-g for "giant screenshot" is not exactly a hard concept, is it?
07:41:26 *** Deathmaker has joined #openttd
07:56:35 <dihedral> hehe - 1 hour screenshot support?
07:58:16 <dihedral> 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
08:52:37 *** svippery has joined #openttd
09:17:12 *** Vikthor has joined #openttd
09:39:12 <dihedral> 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
09:39:51 *** Kokunai has joined #openttd
09:40:47 <Kokunai> anyone here up to answer some qustions about load balancing?
09:41:21 *** [com]buster has joined #openttd
09:41:23 <dihedral> dont ask if you can ask
09:41:35 <dihedral> usually does not go down very well
09:41:41 <Kokunai> well it is a long question so here goes
09:41:45 <dihedral> and then also be patient to receiving an answer ;-)
09:46:37 <Kokunai> ...ok i usually run LL___RR mainline...
09:47:40 <Kokunai> 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
09:47:49 <Kokunai> I think the main problem was using them in junctions
09:48:31 <Kokunai> 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?
09:49:24 <dihedral> again - i think you will find the answer looking at screenshots and archived games at www.openttdcoop.org
09:50:14 <Eddi|zuHause> dihedral: that assertion could use a backtrace
09:50:41 <Kokunai> alright will check there
09:51:03 <Kokunai> looked through other sources short of downloading old games but I'll do that
10:22:48 *** rubyruy has joined #openttd
10:38:10 <CIA-1> OpenTTD: rubidium * r14764 /trunk/src/ (10 files in 3 dirs): -Codechange: make the '***' chat messages like "Game paused (not enough players)" fully translateable.
10:41:00 <CIA-1> OpenTTD: rubidium * r14765 /trunk/src/lang/ (40 files): -Update (r14764): remove changed strings from translations.
10:47:23 * Rubidium wonders how everyone trying HydraIRC will make you different
10:50:09 <mincepie> 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
10:52:07 <dihedral> mincepie, just because something is 'most used' does not mean it's good
10:52:15 * dihedral points at MS Windows
10:52:23 <mincepie> I didn't imply it was
10:52:57 <mincepie> 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
10:54:22 <mincepie> 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
10:54:55 *** Yorick_ has joined #openttd
10:55:13 <Rubidium> everything starting with i<capital> is likely to be in that category
10:55:35 <mincepie> well, of course. everything produced by Apple Computer starts with i
10:55:35 *** Yorick is now known as Guest1841
10:55:36 *** Yorick_ is now known as yorick
10:55:54 <mincepie> except the things that are profoundly uncool; these are, ironically, the useful products
10:57:22 <mincepie> oh, except Time Machine, and Time Capsule
10:57:28 <mincepie> both of which are appalling
10:58:48 <mincepie> I like how I have managed to engage three people in one conversation, with one sentence each
11:09:30 * yorick is updating the extra zoom levels patch...it segfaults :(
11:09:54 <yorick> on "src_n += n;" in 32bpp_optimized.cpp
11:16:43 *** Progman has joined #openttd
11:17:27 <CIA-1> OpenTTD: rubidium * r14766 /trunk/src/network/core/tcp.h: -Fix (r14730ish): remove unused typedef.
11:27:52 <yorick> r13639 seems to have made it fail on the bigger sprites
11:33:27 *** lewymati has joined #openttd
11:34:55 <mincepie> the pound is now €1.02... could it hit 1.00 today?
11:57:44 *** Dred_furst has joined #openttd
12:13:46 *** Brianetta has joined #openttd
13:44:15 *** Yorick_ has joined #openttd
13:47:54 *** yorick is now known as Guest1861
13:47:54 *** Yorick_ is now known as yorick
14:17:40 *** jawsper has joined #openttd
14:20:09 <Belugas> 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
14:20:37 <Belugas> therefro, if yo need to see them change, they will be changed for all of the houses of the same type at once.
14:21:04 <Belugas> and i think it might be cpu intensive to trigger a refresh map-wide
14:39:00 *** Celestar has joined #openttd
14:39:00 *** ChanServ sets mode: +o Celestar
14:44:08 <nicfer> one question, I've copied the opengfx files to its dir but the game says that I don't have them
14:44:50 <nicfer> I'm trying to run it on 0.6.3
14:52:31 *** Celestar has joined #openttd
14:52:31 *** ChanServ sets mode: +o Celestar
15:15:57 *** Phoenix_the_II has quit IRC
15:46:28 <CIA-2> 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.
15:48:13 *** Swallow has joined #openttd
15:50:56 *** stillunknown has joined #openttd
16:13:03 *** Yeggstry has joined #openttd
16:20:34 *** |Jeroen| has joined #openttd
16:33:55 *** Vikthor has joined #openttd
16:42:50 <Swallow> According to MSVC the following strings are not used anywhere:
16:42:52 <Swallow> STR_0131_TOO_MANY_NAMES_DEFINED
16:42:53 <Swallow> STR_8832_TOO_MANY_ORDERS
16:42:55 <Swallow> STR_3007_TOO_MANY_STATIONS_LOADING
16:43:30 <Swallow> It might be possible to remove them...
16:44:05 <Yorick> the blitter 32bpp code is heavily unreadable :/
16:44:09 <Eddi|zuHause> leftovers from the conversion to pools, probably
16:46:27 <Yorick> pointer += (uint32 *) + 4 :o
16:46:43 <glx> Yorick: it has to be fast
16:47:28 <Yorick> glx: comments shouldn't matter in speed
16:48:42 <Yorick> and then it segfaults when stuff is too big :/
17:00:38 *** Yeggstry has joined #openttd
17:08:04 <George> 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
17:09:21 <George> if it takes much CPU - run it once when build and obce a month. I hope that is not too often
17:09:39 <Eddi|zuHause> everything that affects only one house must be stored in the map, everything that is not stored in the map affects all houses simultaneously
17:11:16 <George> 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?
17:11:47 <Eddi|zuHause> i'm not sure what the discussion is about
17:11:56 <Yorick> no, that the population is stored for every house
17:13:08 *** Brianetta has joined #openttd
17:17:26 <Yorick> it takes to much CPU to run the callback every time it is needed
17:17:38 <Yorick> and it can't be stored for each house indivitually
17:19:11 <Belugas> 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
17:19:23 <Belugas> so all in all, it's a pretty intense situation
17:20:01 <Belugas> so the call back is really done on the house types, and not on the houses themselves
17:29:12 <George> but it would make it useless. I wanted to have the result depending on the current graphics
17:29:35 <George> and that means PERSONAL value for every house
17:29:48 <Yorick> why not just run the callback for every time population is needed?
17:30:09 <George> and when do the game reads house population? when is it needed?
17:30:35 <George> Yorick: and how often does it happen?
17:30:38 <flexd> is there a max limit on the amount of trains clients/servers can manage?
17:30:52 <flexd> (i assume there is, but what is that limit?)
17:31:09 <Yorick> flexd: 65535 or 2**32, I think
17:31:22 <flexd> okay, we are nowhere near the limit thne :P
17:31:50 <Yorick> src/vehicle_type.h:typedef uint16 VehicleID;
17:32:32 <flexd> well, it's alot in any case
17:32:40 <Yorick> unless it is set with the patches
17:33:35 <Belugas> 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.
17:34:31 <Belugas> 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
17:35:28 <welshdragon> That's me. Silence spoiler
17:36:31 <welshdragon> Oops. Wrong channel
17:36:47 <Yorick> what are the depot structs actually needed for?
17:38:09 <Yorick> they store owner, xy :p
17:38:18 <Yorick> but houses are with more
17:38:22 <Eddi|zuHause> flexd: 5000 per company
17:48:29 <svip> Eddi|zuHause: Noticed something?
17:49:38 <Eddi|zuHause> when someone is busy, they usually do not notice the lack of annoyance
17:50:24 <svip> But they do appreciate it.
18:21:37 *** baudchan has joined #openttd
18:26:54 *** evandar has joined #openttd
18:31:04 <Rubidium> George: it reads the population when the house is built and on loading savegames
18:31:52 <Rubidium> making it "variable" over time or whatever non-constant thing you can image means it is very likely to cause desyncs
18:35:06 <George> Rubidium: It would be Ok if it happens on 1-st day of the year or any time based condition, that allows sync.
18:36:15 <Rubidium> no, because clients don't join on the first day of the year
18:37:04 <George> 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
18:38:35 <Rubidium> but where would people base their callbacks results on?
18:38:56 <Rubidium> which in it's turn will cause desyncs
18:39:36 <Rubidium> I'm disliking TTRS for doing it's road replacement stuff based on year-of-load too
18:40:30 <Rubidium> especially as exactly the same mechanism can be used to differ in e.g. house population
18:40:40 <Rubidium> which would again mean desyncs
18:41:16 <CIA-2> OpenTTD: translators * r14768 /trunk/src/lang/ (8 files in 2 dirs): (log message trimmed)
18:41:16 <CIA-2> OpenTTD: -Update: WebTranslator2 update to 2008-12-29 18:40:47
18:41:16 <CIA-2> OpenTTD: dutch - 13 fixed, 5 changed by Excel20 (18)
18:41:16 <CIA-2> OpenTTD: french - 13 fixed by glx (13)
18:41:16 <CIA-2> OpenTTD: hebrew - 22 fixed, 1 changed by yitzc (16), davidx123 (7)
18:41:17 <CIA-2> OpenTTD: italian - 13 fixed by lorenzodv (13)
18:41:19 <CIA-2> OpenTTD: norwegian_nynorsk - 94 fixed, 20 changed by Grilldyret (114)
18:43:18 <petern> Rubidium, didn't we change it so that the date was start date instead of load date?
18:43:29 <petern> (at least, for network games)
18:43:37 <petern> ((if not, why didn't we?))
18:44:27 <Rubidium> 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
18:53:34 <Eddi|zuHause> i thought someone recently said something along the line of "the code looks like it uses the start"
18:55:31 <Rubidium> Eddi|zuHause: more likely "the code should use the start"
18:56:26 <glx> but the grf checks current date
19:00:41 <Eddi|zuHause> grah... i wanted to point to the logs entry, but there are no logs for the given date...
19:01:42 <Eddi|zuHause> you should probably just change "on build or load" to "on build, load or save"
19:02:19 <Yorick> wouldn't that look ugly with TTRS?
19:02:24 <Eddi|zuHause> [Do Dez 25 2008] [08:17:27] <De_Ghosty> like 80%
19:02:26 <Eddi|zuHause> [Do Dez 25 2008] [08:17:41] <De_Ghosty> cuz some vheical spent all year in a station waiting
19:03:06 <Rubidium> and that is relevant in what way?
19:03:22 <Eddi|zuHause> that was a reply to the "on load or on start" question
19:11:56 <Wolf01> 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?
19:25:12 <George> 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?
19:31:13 <Eddi|zuHause> hm... this asterix film is silly...
19:33:12 *** Zealotus has joined #openttd
19:40:23 <Rubidium> George: the problem is that the desync question is likely to be unsolvable
19:53:12 <George> 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.
19:54:41 <edeca> Where's the list of stuff that needs fixing in the copy&paste patch?
19:55:03 <edeca> I can't see it in flyspray or the wiki
19:55:54 <Yorick> edeca: start by removing most of the macros
19:56:26 <Rubidium> George: it's the callback that will be the cause of desyncs
19:56:38 <Yorick> then try to optimize duplicated lines
19:56:46 <edeca> Yorick: I'll put that on my list of stuff to look at, the 2nd is already on my list
19:56:46 <Rubidium> edeca: it's scattered around the forum I reckon
19:57:13 <Yorick> then extend the multiplayer protocol so that it can send the whole template at once
19:57:21 <edeca> I was going to look at signal types first, as there seem to be sensible functions for them HasSignalOnTrackdir etc
19:57:23 <Rubidium> and probably also in the IRC logs
19:57:36 <Yorick> and the templates have no versioning ;)
19:57:57 <edeca> Yorick: Yeah, but that's not something I'm going to be able to fix easily ;)
19:58:05 <edeca> My C skills are really limited, but I might be able to do something
19:58:59 <George> 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 :)
19:59:26 <George> Or do you mean "it may cause"
19:59:39 <Eddi|zuHause> George: he can prevent one case, but then the grf authors will find ways that are not checked for
20:00:36 <Eddi|zuHause> George: easy example
20:00:39 <George> Eddi|zuHause: How, if Rubidium knows how it will cause desync? All, the GRF can do, is to provide CB result, nothing more
20:01:01 <Yorick> also, the templates need compression
20:01:10 <Eddi|zuHause> let's assume you have a house callback that says: "this house has 10 population before 1925 and 20 after 1925"
20:01:26 <Eddi|zuHause> the first client joins in 1920, so his house has 10 population
20:01:52 <Eddi|zuHause> the second client joins in 1930, the callback is run on his side during load, but not on the first client
20:02:04 <edeca> Yorick: I assume they can be compressed like savegames?
20:02:11 <Eddi|zuHause> so the second client has a house with population 20, at the same spot, where the first client has population 10
20:02:27 <Eddi|zuHause> do you understand?
20:02:58 <George> Eddi|zuHause: if he joins to exssiting game, he should check day of build, not current day - so they both should get 10
20:03:29 <George> if a new house appears - they both get 20
20:03:30 <Yorick> edeca: yes, you could use the zlib compression
20:04:04 <Yorick> 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
20:04:05 <Eddi|zuHause> George: well, might not be the best example, but it should illustrate the point
20:04:15 <George> Isn't joining is like loadidn the game, that exists on the server?
20:04:15 <Yorick> and it should clear land that is needed for terraforming
20:04:18 <edeca> Yorick: Hrm, lots of notes ;)
20:04:19 <Eddi|zuHause> and usage of this kind of callback cannot be checked
20:04:22 <Yorick> and not try to clear land that is already clear
20:04:24 <edeca> Yorick: I hate the way it clears land
20:04:33 <edeca> Yorick: Should it ignore sea tiles?
20:04:45 <Yorick> edeca: nah, just warn :p
20:04:57 <Yorick> and it should check for money before start if it doesn't already do so
20:05:10 <edeca> Yorick: It supports shift-click, so it might support money
20:05:12 <Yorick> option to convert to newest bridge type automagically
20:05:21 <edeca> Yorick: Not sure if it does it correctly
20:05:31 <George> Eddi|zuHause: No, I do not understand how can cause desync if the process (desync reason) is well known
20:05:35 <Eddi|zuHause> George: because the callback engine of NFO is turing complete
20:05:36 <Yorick> the sprites should reside somewhere else
20:05:58 <Yorick> the array size needs to be variable some way
20:06:04 <George> Eddi|zuHause: What did you mean with your last text?
20:06:19 <edeca> Yorick: It currently uses a "biggest size" array, wont that do?
20:06:34 <edeca> Yorick: It's more cycles to count the amount of space needed surely, you'd have to check every tile
20:06:41 <Yorick> wasn't there something about memory usage?
20:06:44 <Eddi|zuHause> George: "turing complete" is an expression of theoretical computer science.
20:07:07 <Yorick> look at even the most basic template file
20:07:07 <George> what does it mean? And what does it mean here?
20:07:27 <Yorick> when you copy the biggest space possible
20:07:34 <Yorick> it uses that, permanently
20:07:43 <edeca> Yorick: Ah, yes I see. But zlib compression would help that enormously?
20:07:59 <Yorick> not on memory usage ;)
20:08:06 <edeca> Yorick: Oh, in memory. Sorry :0
20:08:09 <Eddi|zuHause> a calculation system is "turing complete" if any problem that can be solved with a turing machine can be solved with this system
20:08:23 <Yorick> edeca: I'll try to see what zlib does ;)
20:08:24 <edeca> Yorick: Hrm, well that's a problem if the buffer stays around a while
20:08:37 <Yorick> it stays around when loading
20:08:38 <edeca> Well, you could gzip a .tpl to get an idea :)
20:08:47 <Eddi|zuHause> and backwards, any problem that could possibly be solved by any computer can be solved with a turing machine
20:09:03 <George> Eddi|zuHause: I can't understand, if you know one of desync rules, why can't you make the code to prevent it?
20:09:05 <Eddi|zuHause> and then there are proofs about problems that cannot be solved by a turing machine
20:09:13 <Yorick> the template format needs a rework
20:09:35 <edeca> Yorick: Well most of these problems can be tackled invididually from what you're saying
20:09:52 <edeca> Yorick: So for tonight, I might take a look at the macros and see what sort of a state it is in
20:10:08 <Eddi|zuHause> 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
20:10:27 <Eddi|zuHause> George: SOME callbacks may be safe, but others might not
20:10:32 <Eddi|zuHause> and there is no way to tell them apart
20:10:53 <Eddi|zuHause> so the only way to really make sure they are safe, is to make them constant
20:10:59 <Yorick> I think the macro usage is down a bit
20:11:05 <edeca> Yorick: What's wrong with them, just overuse?
20:11:17 <Yorick> can't find anything currently
20:11:25 * edeca crosses that off the list
20:11:40 <Yorick> void CopyPaste::CP_PlaceRoad(TileIndex tile, uint8 road_bits)
20:11:51 <Yorick> it has that for every type of commmand it does
20:12:06 <edeca> Yes, it does have a 1 line function per action
20:12:14 <Yorick> it seems to have 8 map arrays
20:12:59 *** HerzogDeXtEr has joined #openttd
20:13:32 <edeca> So, what to start on. Hrm. I hate the way it doesn't copy signals right
20:14:17 <Yorick> CMD_BUILD_SIGNALS should have new parameters
20:14:26 <Yorick> that allow you to specify direction instantly
20:14:36 <edeca> Yorick: It needs to look at the type of signals too
20:14:48 <Yorick> that'd be the second thing to do
20:14:52 * Eddi|zuHause slaps everyone in the channel on the forehead
20:15:09 <George> Eddi|zuHause: As I understood you, checking the date makes it unsafe. But every CB is unsafe than, because it can check the date?
20:15:27 <Belugas> 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
20:15:40 <Belugas> i shold have realized that when i was telling you of my plan :(
20:15:44 <Eddi|zuHause> George: no, only those that are not saved in the map
20:16:09 <petern> don't houses have a build date stored on the map?
20:16:27 <Yorick> edeca: it has 8 different map arrays :p
20:16:57 *** Dred_furst has joined #openttd
20:17:09 <George> Belugas: And what the problem then? I check and return population according to it.
20:17:27 <Yorick> edeca: and the magical values it uses should be enumified
20:17:38 <edeca> Yorick: Yeah, they're ugly. I'll fix that as I come to them
20:17:54 <Belugas> one problem is the fact that the population cannot be on the map, since there is no room
20:17:54 <edeca> Yorick: Currently looking where to start is a nightmare. I'm looking at CMD_BUILD_SIGNALS
20:18:22 <Yorick> you should overload void CopyPaste::CP_PlaceSignals(TileIndex tile, uint8 track, bool cycleSignalType, bool semaphore)
20:18:35 <petern> so every time it's needed it needs another CB test
20:18:46 <edeca> Yorick: Hrm, do you think those need keeping then? 1 line per function?
20:18:58 <Yorick> it's easier to start with ;)
20:19:15 <Eddi|zuHause> petern: means recalculating the town population every time a house is queried
20:19:27 <Belugas> second problem is that the CB will need to be run cyclickly, plus as soon as someone joins too in order to the safe
20:19:48 <Belugas> mm... and that too, indeed, Eddi|zuHause
20:20:01 <edeca> Yorick: Are you Yorick on the forums too?
20:20:13 <Eddi|zuHause> edeca: no, that is a different Yorick
20:20:33 <edeca> Eddi|zuHause: I didn't look to see if there *was* one on the forums ;)
20:20:44 *** Yorick is now known as yorick
20:20:56 * edeca throws socks at Eddi|zuHause
20:21:34 <yorick> edeca: it should handle error messages in another way
20:21:46 <edeca> yorick: What would you suggest?
20:21:56 <yorick> it should abort when CmdFailed ;)
20:22:29 <George> Belugas: But what's the problem? It will get the same result, because the data for test is stored in the map??
20:22:41 <yorick> if possible, it should first dry-run at every stage of laying
20:23:01 <yorick> if, offcource, you're gonna keep the docommands
20:23:31 <George> I have to go to sleep, but I can't understand yet, what makes this CB to desync the game.
20:23:31 <yorick> it's easier, but uglier
20:23:38 <edeca> yorick: My intention was to make it work in the easiest but nicest way
20:24:24 <yorick> "/** This function calculates the ehight the given tile will have */"
20:24:32 <yorick> int8 CopyPaste::ClampToRight()
20:25:34 <edeca> Comments don't get compiled :)
20:25:48 <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?
20:25:52 <edeca> glx: Yes but not the *worst* bug in it..
20:26:15 <yorick> Yexo: something with setting the default?
20:26:51 <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
20:27:12 <yorick> CheckSavegameVersion in AfterLoadGame ;)
20:27:35 <Eddi|zuHause> there should be plenty of instances already there ;)
20:28:38 <glx> will need a new "instance" of it as it requires a savegame bump
20:29:22 *** NukeBuster has joined #openttd
20:29:40 <Rubidium> petern: the map stores the age of houses, which is capped at 255
20:29:40 <Eddi|zuHause> i meant as examples, not for hijacking :p
20:30:26 <Eddi|zuHause> just prevent games from lasting more than 255 years :p
20:31:23 <Eddi|zuHause> really, we should introduce some kind of layered map, and houses may reserve more than one layer for storing data
20:31:44 <glx> Eddi|zuHause: show us a working version :)
20:31:53 <Rubidium> I tried that and it's *much* slower
20:36:25 <CIA-2> OpenTTD: rubidium * r14769 /trunk/src/newgrf.cpp:
20:36:25 <CIA-2> OpenTTD: -Change: when loading games in "network" mode use the start date of the save
20:36:25 <CIA-2> OpenTTD: game for the server and all clients when loading the NewGRFs instead of the
20:36:25 <CIA-2> OpenTTD: current date. Prevents desyncs caused by action 7/9s skipping parts of the GRF
20:36:25 <CIA-2> OpenTTD: based on the date or some other variables that can differ at NewGRF load time.
20:36:59 <edeca> Is there an irc log kept online that I can refer to?
20:37:36 <Rubidium> SpComb keeps logs and you could take a look at thegrebs.com
20:37:46 <Eddi|zuHause> Rubidium: so now TTRS roads will eternally have the old style?
20:38:07 <Rubidium> unless you start the game after a certain date
20:38:17 <Rubidium> and only for network games
20:40:39 *** Dred_furst has joined #openttd
20:42:10 <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
20:42:37 <yorick> any recent windows binary of grfcodec?
20:43:12 <edeca> yorick: Right, I've just looked at CopyPaste::CP_PlaceSignals and boy is it ugly
20:43:12 <Rubidium> which is basically everything that can read data from outside the NewGRF
20:43:57 <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
20:44:28 <yorick> that it doesn't store the direction?
20:44:47 <edeca> yorick: Hrm, so how does it reverse it? Or even remember it in the first place..
20:45:22 <yorick> it calls the function multiple times for different directions and types
20:45: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 :)
20:47:02 <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?
20:47:38 <yorick> no idea, CmdBuildSignal might provide clues
20:49:21 <Eddi|zuHause> edeca: map storage should be completely abstracted through map accessors
20:49:45 <edeca> Eddi|zuHause: I wasn't trying to change anything, sorry. Was just looking at how DoCommandP works
21:00:06 <yorick> edeca: the command queue should have another CallCommandQueueTick() thing
21:01:04 <edeca> yorick: Damnit, you're very demanding! :)
21:01:33 <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.
21:02:09 <edeca> Oh, idiot, it does that :)
21:02:15 <edeca> Helps if you scroll up sometimes.
21:06:24 <yorick> CmdBuildSingleSIgnal has a nice comment :0
21:06:46 <yorick> bit 15-16 allow to cycle signal direction x times
21:07:32 *** baudchan has joined #openttd
21:07:35 <yorick> bit 5-7 are SignalType
21:08:52 <edeca> It's weird, the patch copies signal type but doesn't paste them
21:11:35 <yorick> CommandContrainer from command_queue.h, doesn't that do quite the same as CommandPacket?
21:12:47 <edeca> Well bits 11-13 of the template array store signal type from GetSignalType
21:13:03 <edeca> But they're not used when pasting
21:13:31 *** rubyruy has joined #openttd
21:14:22 <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
21:14:42 <edeca> Can I use GetTrackBits for that somehow?
21:16:31 <edeca> Well at the minute, the patch cycles through this: if (HasTrack(tile, TRACK_Y) && HasSignalOnTrack(tile, TRACK_Y)) { for each direction
21:16:48 <edeca> I think I can change that and replace TRACK_x with GetTrackBits()
21:18:49 <yorick> for_each_trackbit or something?
21:19:09 <yorick> or loop trough GetTrackBits result
21:19:15 <edeca> Well I don't think you need to enumerate through. Signals can only be placed where there's a single TrackBit
21:19:30 <Eddi|zuHause> no, there can be two trackbits
21:19:48 <edeca> Is a straight track in two parts? :(
21:20:04 <yorick> the horizontal one can be
21:21:02 *** flexd was kicked by DorpsGek (Wrong channel. Retry in #openttdcoop.)
21:21:08 <Mark> anyone knows about people being disconnected from multiplayer games with the reason: (not enough cash - requires $0)
21:21:22 <Eddi|zuHause> i haven't seen that in a long time :p
21:21:23 <flexd> You know.. it could just say that >_<
21:21:24 <edeca> And that would return TRACK_BIT_HORZ from GetTrackBits?
21:21:27 <flexd> I pressed the wrong window :P
21:21:57 <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.
21:21:58 <Eddi|zuHause> flexd: but if it just said that, people would not take notice
21:22:27 <Rubidium> and is the message from the server or the client?
21:23:01 <Mark> i was just checking if it was a known issue :P
21:23:15 <Mark> i could post you a screenie?
21:23:38 <Rubidium> a screenshot isn't useful
21:23:43 <Rubidium> in this case at least
21:23:56 <Rubidium> knowing whether the message was shown on the server or the client or both is
21:24:00 <Mark> how can i tell if it's from the server or the client?
21:25:16 <edeca> OK, so is the nicest way to say for(x=TRACK_BEGIN;x<TRACK_END;x++) then? Rather than check each direction manually?
21:26:34 <Rubidium> maybe use FOR_EACH_SET_BIT ?
21:27:02 <edeca> yorick: Heh don't worry about actual names, I'm grepping other source code for the exact format (and reading the wiki)
21:28:15 <edeca> Rubidium: For each set bit in what, GetTrackBits?
21:29:02 <edeca> Enlightenment feels great.
21:29:25 <Rubidium> Mark: and I'd like to know the exact message, i.e. what was for the "(not enough cash..."
21:31:29 <Mark> ... has left the game (Not enough cash - requires $0)
21:31:44 <Mark> though he didnt leave but got disconnected
21:32:20 <Mark> well he did leave, but not on purpose :P
21:32:27 <yorick> if (!dosomething) dosomethingelse(); else donothing(); doanothersomething(); <-- that is ugly
21:32:45 <yorick> there was another if in there :p
21:33:00 <Mark> it seems to be giving different amounts of cash in different currencies to different people on the server
21:33:41 <CIA-2> OpenTTD: rubidium * r14770 /trunk/src/network/network_client.cpp: -Fix: gracefully handle an invalid packet instead of asserting.
21:34:44 <Eddi|zuHause> Mark: my guess is that it is displaying the wrong message
21:34:46 <Rubidium> Mark: 14786 doesn't exist yet
21:36:19 <Eddi|zuHause> possibly related to r14764, but i don't have any further insight
21:36:50 <yorick> edeca: I'm getting it to compile first :p
21:36:54 *** terjesc has joined #openttd
21:37:24 <edeca> I've got it working with trunk
21:37:47 <Eddi|zuHause> yorick: when nesting if statements, use {} to clarify the position of else clauses
21:38:15 <edeca> Oh, so what doesn't compile?
21:38:26 <edeca> My code there doesn't, because it's not right yet :)
21:38:28 <yorick> the docommands and player<>company changes
21:38:35 <edeca> Er I fixed that, last night
21:39:07 <edeca> Except my session ID, heh
21:39:36 <edeca> Sorry if you've just wasted all that time :(
21:39:41 <edeca> I was logged out, session ID is invalid ;)
21:39:56 *** Wolfolo|AWAY has joined #openttd
21:39:56 *** Wolf01 is now known as Guest1914
21:39:56 *** Wolfolo|AWAY is now known as Wolf01
21:41:39 <CIA-2> OpenTTD: rubidium * r14771 /trunk/src/network/network.cpp: -Fix (r14764): resolving of error types to error messages kinda failed :(
21:43:21 <edeca> Got kicked off my own PC! How rude.
21:43:43 <edeca> So are we both in the same position now? ;)
21:45:26 *** rubyruy has joined #openttd
21:47:32 *** Celestar has joined #openttd
21:47:32 *** ChanServ sets mode: +o Celestar
21:50:38 <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.
21:51:57 <Rubidium> good evening Celestar
21:54:13 <edeca> Rubidium: Silly question, will using FOR_EACH_SET_BIT with a TrackBits have the same effect as with a Track?
21:54:24 <edeca> Rubidium: I understand enums but get confused with << bit shifting
21:55:17 <edeca> I get the TrackBits from GetTrackBits but want to check for signals, which are only valid on X/Y/UPPER/LOWER
21:55:52 * Rubidium has no idea what edeca wants to know
21:55:55 <yorick> FOR_EACH_SET_BIT only works on track
21:56:04 <yorick> it does not work on Track
21:56:17 <edeca> Ah! Of course, they're just numbers
21:56:30 <edeca> Right, so I'm going about it the right way with my preliminary paste, just not there yet
21:58:17 <edeca> yorick: HasSignalOnTrack expects a Track though, so how to work around that?
21:58:38 <Eddi|zuHause> TrackdirToTrack?
21:59:13 <edeca> Sorry, I'm not intentiionally stupid
21:59:27 <yorick> *cough*TrackBitsToTrack*cough*
21:59:45 <Eddi|zuHause> err, yes, of course
22:00:15 <Eddi|zuHause> but at least the compiler should have complained about incompatible types :p
22:00:25 <edeca> Eddi|zuHause: It did, that's how I spotted it ;)
22:01:09 <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
22:01:37 <Eddi|zuHause> that is simple, just ssh into your other computer...
22:02:11 <edeca> Heh, I haven't got round to setting that up yet
22:03:50 <edeca> And if I kick her off, we will have no food ;)
22:03:58 <edeca> yorick: That's what I develop with, just never needed an ssh server
22:05:07 * Belugas thinks it's time to return home and join the family
22:05:17 * Belugas waves bye bye to all who are still standing
22:06:44 <Belugas> night Rubidium :) have fun, as always hehe
22:07:05 <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.
22:07:35 <edeca> yorick: I'll finish off that pastebin patch tomorrow during quiet time at work ;)
22:13:52 *** jawsper has joined #openttd
22:14:01 <edeca> I'm off to sleep now, cheers yorick and Eddi|zuHause for your help
22:14:24 <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
22:48:28 *** Dred_furst has joined #openttd
22:52:40 <Eddi|zuHause> cool vapourware this year... a gps/phone/camera that tells you where you parked your car
23:14:06 *** Jerimiah40 has joined #openttd
23:21:17 *** Eddi|zuHause2 has joined #openttd
continue to next day ⏵
