IRC logs for #openttd on OFTC at 2007-06-21
⏴ go to previous day
00:29:25 *** ThePizzaKing has joined #openttd
00:55:41 <Smoovious> on one-way roads... what's the point of being able to set the red dot in between 2 yellow arrows?
01:11:02 <glx> to totally disallow vehicules to go through this road
01:12:26 <Smoovious> can see that being used in a hostile manner...
01:31:01 *** Eddi|zuHause3 has joined #openttd
01:35:57 *** Frostregen has joined #openttd
01:56:25 <Sacro> sorting of industries is broken in the nightlies
01:56:32 <Sacro> well, sorting by production is anyway
05:10:23 *** |Gekkko| has joined #openttd
05:10:35 *** |Gekkko| is now known as Gekkko
05:11:28 *** Thomas[NL] has joined #openttd
05:24:14 *** alanin is now known as Alanin
05:34:26 <mic> hello, i have 2 a little simple questions about build under slopes :)
05:34:55 <mic> 1) should we make puchased land slopable?
05:35:03 <mic> 2) should we make canals slopable?
05:35:53 <Gekkko> water can't run up hills
05:35:58 <Gekkko> and it would all rush down hill
05:36:09 <Gekkko> you could make a kind of conveyer belt
05:36:47 <eekee> What do you meqan by slopable?
05:37:05 <mic> slopable like build-on-slopes for roads and rails
05:37:21 <mic> (you can build them on slopes)
05:37:53 <eekee> Ah ;) hmmm, I'm not sure
05:39:59 <eekee> It's a question of realism, for me: Would the weight of the water be too much for the earth-works?
05:42:11 <eekee> As to purchased land, I'd like to see it stay purchased when you raise or lower the terrain. Is that what you meant?
05:42:53 <bencvt> i agree with eekee... canals with sidings would look odd
05:44:54 <bencvt> purchased land on slopes looks fine
05:44:55 <mic> i am his PR representative =)
05:45:50 <mic> "I'd like to see it stay purchased when you raise or lower the terrain" -- good idea i think :)
05:48:33 <mic> i meant actually... should other players be allowed to dig under puchased land (if it does not land's slope)?
05:48:51 <Gekkko> is the sloped land purchase a small patch?
05:49:12 <Gekkko> might be inserted easily
05:49:15 <Gekkko> if it doesnt require much management
05:49:48 <bencvt> r/i think so/mic: i think so
05:49:50 <mic> it is part of mine :) it is only display different - it draws foundation, nothing more
05:50:41 <mic> but other player may dig purchased in a such way that it block (future) station exit
05:51:13 <eekee> oops, didn't see the scroll
05:51:29 <mic> e.i. you wont be able to build station for which you bought the land
05:52:06 <bencvt> do you have a screenshot of such a scenario?
05:52:19 <bencvt> i think i know what you're saying but i'm a visual kinda guy
05:52:20 <eekee> I didn't see the scroll-bar wasn't all the way down
05:58:27 <bencvt> how's the end result any different than if blue bought those two tiles without digging down?
05:59:23 <eekee> I don't like the idea of dig-under for purchased land
05:59:32 <mic> you can not build road/rail/depot-exit/station-exit facing cliff
06:01:33 <mic> then digging purchased land is crap probably :)
06:02:57 <bencvt> otoh, disallowing digging around bought land makes the buy land tool seem even more powerful
06:03:15 <bencvt> in comparison to, e.g., rails
06:04:39 <mic> what to do then you may suggest? )
06:05:07 <bencvt> the 2nd option... disallow digging around bought land
06:07:35 *** mikk36[EST] has joined #openttd
06:10:14 <CIA-1> OpenTTD: miham * r10240 /trunk/src/lang/ (11 files): (log message trimmed)
06:10:14 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2007-06-21 08:03:49
06:10:14 <CIA-1> OpenTTD: american - 30 fixed, 1 changed by WhiteRabbit (31)
06:10:14 <CIA-1> OpenTTD: bulgarian - 1 fixed by thetitan (1)
06:10:14 <CIA-1> OpenTTD: dutch - 1 fixed by habell (1)
06:10:16 <CIA-1> OpenTTD: estonian - 25 fixed by kristjans (25)
06:10:16 <CIA-1> OpenTTD: french - 1 fixed by glx (1)
06:10:19 <Phazorx> any of decs available
06:10:33 <Phazorx> to join coopers game?
06:25:18 <mic> need to edit pathfinding also :(
06:29:10 <mic> is it a good idea or crap? )
06:32:11 <mic> heh you are right, ships are going uphill-canals easily (without editing pathfinding) :))
06:33:26 <hylje> can you make locks work on slopes too?
06:34:59 *** Vikthor has joined #openttd
06:35:02 <mic> not understood - lock are at slopes already
06:36:28 <hylje> i mean on foundationed slope
06:36:37 <mic> lock need 2 flat cells - you want them sloped?
06:36:55 <hylje> drag some railway on a diagonal slope, and you see what i mean
06:39:31 *** lordofthepigs has joined #openttd
06:39:33 <Phazorx> hylje: you'll like this
06:40:01 <hylje> well normally locks are placed on a "normal" slope: let's say it's positioned like this: |
06:40:04 <lordofthepigs> Can anyone explain to me how to use the new vehicle groups interface?
06:40:10 <mic> you mean drag rail at 45 to slope?
06:40:18 <lordofthepigs> I don't understand how to add vehicles to a group
06:40:40 <Phazorx> exit/combo pre-signal above tunnel is giving false reading to enter signal
06:40:52 <hylje> but to have full use of the foundationed canal, locks should be able to be built on not only |, but diagonal (\ and /, respectively) slope too
06:43:45 <Noldo> Phazorx: what happens if you remove the rail that goes in the same direction with the tunnel?
06:44:43 <mic> yes, lock can be slopes too, but it also need to be coded :)
06:44:48 <Gekkko> Phazorx: wtf two lights?
06:45:08 <Gekkko> I ask stupid questions, i should just ask where to get it
06:45:14 <Phazorx> Noldo: what do you mean'
06:45:24 <Phazorx> Gekkko: dont get ur queastion
06:45:36 <Gekkko> theres signals with two lights
06:45:48 <Noldo> Gekkko: presignals, old as hell
06:45:51 <Phazorx> have you hear about presignals>?
06:46:51 <Noldo> Phazorx: the on top of the tunnel going in the same direction as the tunnel on a square diagonally adjacent to the buggy signal
06:47:17 <Phazorx> Noldo: it is a part of priority window
06:47:24 <Phazorx> it i remove it construction does not work
06:48:11 <peter1138> lordofthepigs: drag from the vehicle list to the group list
06:48:17 <Noldo> Phazorx: then move it so that it doesn't fit the tunnel entrance
06:48:32 <Phazorx> Noldo: i removed it - doesnt matter
06:49:02 <Phazorx> oops it does when a train passes
06:49:03 <lordofthepigs> peter1138: Did you end up implementing the cool feature that would let you group vehicles based on their orders?
06:49:14 <Phazorx> but then construction does not work
06:49:24 <Phazorx> if i remove tunnel under light
06:49:30 <Phazorx> not the one aboe that track
06:50:24 <peter1138> that bug was fixed, but only for normal signals it seems
06:50:38 <mic> hylje: i am concerned if i should code sloped canals as well as other will like it and it would be included anywhere :)
06:50:53 <peter1138> and i didn't get it because i copied your 1.png, not 11.png
06:50:54 <Phazorx> peter1138: i have normal signal there
06:51:01 <Phazorx> one that shows the bug at least
06:51:29 <peter1138> no it's a presignal
06:51:29 <Phazorx> the one that stays red at 11.png
06:51:53 <peter1138> if you change it to a normal signal it doesn't stay red
06:52:08 <peter1138> the bugfix only worked for normal signals. hmm.
06:52:33 <Phazorx> wait peter1138 is it a fix for one which is red or for one which is above tunnel ?
06:53:55 <Phazorx> the save i have, with untouched tunnels has it with any combination of types of signals
06:54:04 <Phazorx> and with last oen being combo or exit
06:54:34 <Phazorx> only way to fix it temporary is removing middle or last one
06:54:40 <Phazorx> perma fix is removing the tunnel
06:55:41 *** dihedral has joined #openttd
06:55:48 <dihedral> good morning ladies :-)
06:58:15 <peter1138> the buggy one only gets stuck if the signal on the tunnel is a presignal
06:59:36 <Phazorx> and bug occurs only if tracks above tunnels are goign in same direction as tunnel
07:00:04 <Phazorx> if they are changed to lead to the lane instead of crossing it
07:00:48 <Phazorx> i think signals logic somhoe sees tunnels as linking factor
07:01:12 <Phazorx> if tracks above are somewhat connecttable from brid viewpoint
07:03:18 <Noldo> shouldn't it use the same track following thing as the train itself?
07:08:01 <hylje> how's yiff.grf going off? D:
07:10:27 <mic> am i the only who have noticed that half-desert with something built on it, is drawn as green?
07:11:10 <mic> it is a feature or unfixable bug?
07:13:06 <Ailure> limitation of the game engine
07:13:42 <Ailure> It's related to how the array works
07:16:55 <Phazorx> peter1138: i take it you dont need the save
07:27:08 *** Tefad_ is now known as Tefad
07:43:50 *** Maedhros has joined #openttd
07:43:56 *** nihil84 has joined #openttd
07:54:55 *** DNazarov has joined #openttd
08:45:23 <mic> i think headers in openttd are veeeeerrry bloated
08:45:59 <mic> am sure, reducing headers will reducin compilation time 5-50 times
08:47:35 <mic> c file include 3 headers... they include 10 header ... they include 50 header... they include ALL header
08:47:54 <mic> as result ALL source files are compiles will ALL headers inside
08:48:33 <mic> with thousands useless typedef, prototypes, templates, inline function, enums etc etc etc and only 1% of it is used
08:50:59 <Biff> hmm, only takes 30 seconds to compile anyway
08:51:03 <Biff> could you save that much?
08:51:19 <peter1138> takes 5 or 6 minutes for me
08:52:42 <Biff> for me i think the problem is compiling over nfs
08:53:01 <Biff> it may take longer over nfs, 30seconds is local disk
08:55:16 <Biff> hmm, takes alot longer on a p4 2.8
08:56:13 <Biff> i've heard the same about compiling on bsd vs compiling on linux, that bsd is alot faster, because they have much smaller headers
08:57:40 <peter1138> tron put it down to fork time or something like that
09:25:06 <Sionide> i got some errors from clear_cmd.cpp i think
09:28:52 <peter1138> i like how informative "some errors" is
09:30:53 <peter1138> 10:23 < Sionide> from r10240
09:31:17 <Sionide> yeah i tried 10236 cos that was the revision mentioned on the forums
09:31:37 <peter1138> it's not going to be removed
09:31:41 <peter1138> (unless it's pbs, hah)
09:32:21 <Sionide> oh it's a new url *shrug*
09:33:18 <Maedhros> have you got any local changes in there?
09:34:12 <Maedhros> run svn diff to find out ;)
09:37:37 <Sionide> changes to english.txt, clear_cmd.cpp, viewport.cpp, signs_gui.cpp, signs.h, signs.cpp and main_gui.cpp
09:45:32 <peter1138> or fix the conflicts
09:46:57 *** TheJosh has joined #openttd
09:47:40 <TheJosh> anyone with svn access want to make a few dollars?
09:48:17 <TheJosh> do you have svn access hylje?
09:48:37 <hylje> yes but not to ottd, apart from anon
09:49:12 <TheJosh> i have svn access to a project at work, but that doesnt help here
09:51:10 <TheJosh> i guess the only thing I can do is fix a heap of bugs in FlySpray, then my patches will get to the top quicker
09:56:13 <dihedral> that was actually quite cute
09:56:27 <dihedral> TrueBrain: may i bother you for a bit?
09:56:39 <TrueBrain> I won't respond if I don't have time :)
09:58:37 <TrueBrain> delays in new subdomains are rare :)
09:58:46 <TrueBrain> so first urls work fine
09:59:11 <TrueBrain> what did WizKid ever do for the lib?
09:59:37 <dihedral> i have no idea - but you said in a comment that you continued the work from WizKid
09:59:52 <TrueBrain> WizKid only made the site-design
09:59:59 <TrueBrain> he wasn't a PHP coder :)
10:00:02 <TrueBrain> so you can safely remove it
10:02:22 <TrueBrain> and as email you can give my @openttd.org email :p
10:02:34 <TrueBrain> the documentation is very nice
10:02:41 <TrueBrain> just remove WizKid from all the pages :p
10:03:02 <TrueBrain> really nice job on the docs, easy to read, should be easy for everyone to add
10:05:31 <dihedral> then after i have removed those references i shall make a zip and put it in the forums :-)
10:05:41 <TrueBrain> sounds like a plan :)
10:07:33 <dihedral> truelight or truebrain befor the at?
10:15:35 <mic> i made some script to analyze how many headers are included from each source file
10:16:09 <mic> here is example part of results for openttd:
10:16:25 <mic> heightmap.cpp: 14 direct includes, 43 total includes.
10:16:27 <mic> ship_gui.cpp: 14 direct includes, 50 total includes.
10:16:28 <mic> fileio.cpp: 9 direct includes, 16 total includes.
10:16:30 <mic> window.cpp: 15 direct includes, 34 total includes.
10:16:31 <mic> unmovable_cmd.cpp: 21 direct includes, 44 total includes.
10:16:33 <mic> map.cpp: 8 direct includes, 12 total includes.
10:16:34 <mic> order_gui.cpp: 24 direct includes, 48 total includes.
10:16:36 <mic> newgrf_sound.cpp: 9 direct includes, 36 total includes.
10:16:37 <mic> water_cmd.cpp: 26 direct includes, 56 total includes.
10:16:39 <mic> economy.cpp: 38 direct includes, 70 total includes.
10:16:41 <mic> news_gui.cpp: 16 direct includes, 39 total includes.
10:16:43 <mic> vehicle_gui.cpp: 30 direct includes, 59 total includes.
10:16:54 <Rubidium> mic: we know that very well
10:17:15 <Rubidium> but decreasing that dependency is pretty hard to do
10:17:33 <blathijs> mic: there's 70 includes for economy.cpp even :-)
10:18:23 <Rubidium> and the real problem is that most includes are included for their type definitions and not the inlined functions they contain, whereas the headers need to include other headers for the inline functions
10:18:24 <blathijs> Rubidium: We could simply put everything in one big cpp file: No more includes!
10:19:19 <ln-> that's onviously the best solution.
10:19:30 <blathijs> (in other words, having many includes might also be because the declarations are properly divided into very small pieces, not neccesarily bad)
10:21:00 <mic> simply suggestion: make functions not-inline :) it is doubtful if they speed up anything )
10:21:13 <mic> but it will speed up compile a lot
10:22:33 <Rubidium> mic: function call versus "return _m[x].m2". I really think that matters a lot
10:23:35 <Rubidium> mic: I can assure you that they speed things up considerably
10:23:51 <ln-> seeing some sort of graph of the include relations would be more interesting than just numbers.
10:25:54 <mic> if you need inlines, compile with -O3 not -O2 then, and remove impilcit inlines
10:26:39 <Rubidium> mic: you still need to put them in the headers
10:27:05 <mic> no, compiler make small functions inline
10:28:05 <Rubidium> not when they are in a different compilation unit (gcc isn't that smart yet AFAIK)
10:31:16 <peter1138> cat *.h *.cpp > onebigsource.cpp
10:31:40 <TrueBrain> dihedral: truelight@
10:32:07 <blathijs> Rubidium: That requires changes in the linker and the object format, so won't really work
10:32:26 <blathijs> Rubidium: Though there is some work in that area for template instantiations in the linker, might be related
10:33:25 <TrueBrain> [12:21] <mic> simply suggestion: make functions not-inline :) it is doubtful if they speed up anything ) <- just for fun run OpenTTD with ./configure, and one time with CFLAGS="-fno-inline" ./configure
10:33:27 <TrueBrain> see if it matters :)
10:33:58 <Rubidium> I'd really like an optimization at link time. That way we can put all declarations in headers and the implementations of even the easiest map accessor functions in .cpp
10:34:16 <mic> err speed? compare speed of binary?
10:34:16 <TrueBrain> Rubidium: would take for EVER! :)
10:34:38 <TrueBrain> mic: try comparing in-game speed, might be useful :)
10:35:40 <TrueBrain> but what peter1138 suggests might work best Rubidium ;)
10:36:26 *** XeryusTC has joined #openttd
10:36:42 <peter1138> use c#! no headers at all ;)
10:39:29 *** Brianetta has joined #openttd
10:39:48 <peter1138> how does gcc treat it if you specify multiple source files in one go?
10:40:19 *** TheJosh has joined #openttd
10:43:50 <Tefad> gcc foo.c bar.c bas.c -o exec ?
10:44:58 <peter1138> "compilation units"
10:45:34 <peter1138> clearly you are not the person to answer the question then :)
10:45:57 <Tefad> i'm not sure what the question is
10:46:16 <Tefad> it certainly doesn't treat the files with pesticides..
10:46:38 <Tefad> what i mean is i lack clear context
10:53:32 <mic> "<ln-> seeing some sort of graph of the include relations would be more interesting than just numbers." -- graph is about 1 Mb, still cannot make picture (several minutes already) :)
11:00:21 <peter1138> 11:25 < mic> no, compiler make small functions inline
11:00:21 <peter1138> 11:25 < mic> for -O3
11:00:21 <peter1138> 11:26 < Rubidium> not when they are in a different compilation unit (gcc isn't that smart yet AFAIK)
11:00:29 <peter1138> Tefad: that's the context
11:01:50 <Tefad> mostly relating to optimization
11:02:55 <peter1138> i was wondering if it knew how to handle it if it was told to compile all source at once
11:03:18 <Tefad> perhaps if all the files were concatenated
11:03:29 <Tefad> i think that's how some projects mangle their files
11:03:47 <peter1138> would take a while to compile :)
11:10:45 <Maedhros> kdeenablefinal is a killer... it took 1.5Gb of ram + swap to compile kmail
11:10:57 *** setrodox has joined #openttd
11:11:56 <mic> sorry i can not make graph :)
11:12:22 <mic> -dev-hda6 5779468 5485944 0 100% -
11:17:44 *** Nickman has joined #openttd
11:26:25 <mic> "_headers_dependency_graph.png: PNG image data, 96341 x 1321, 4-bit colormap, non-interlaced" --- so, i think headers dependency graphs drawing is bad idea ))
12:10:59 *** MarkSlap has joined #openttd
12:20:00 <Ailure> I should use this somewhere
12:20:05 <Ailure> 10 points for anyone who knows the joke
12:26:11 <Rubidium> long vehicles are ugly, unless they are articulated vehicles?
12:37:04 * TrueBrain makes a dance: prelimary testing shows 32bpp-anim is faster in palette animation over 8bpp-optimized :) :) :) :)
12:37:09 <CIA-1> OpenTTD: truelight * r10241 /trunk/src/ (11 files in 2 dirs):
12:37:09 <CIA-1> OpenTTD: -Codechange: CopyToBuffer now produces a buffer that is unreadable from outside the blitter, so the blitter can store anything he likes
12:37:09 <CIA-1> OpenTTD: -Codechange: added CopyImageToBuffer, which produces a readable buffer for screenshots
12:37:09 <CIA-1> OpenTTD: -Fix: 32bpp-anim now holds animation on transparent objects to avoid strange graphical effects
12:37:10 <CIA-1> OpenTTD: -Fix: 32bpp-anim now works correct on mouse-movement (it holds the palette animation correctly)
12:39:35 *** Progman has joined #openttd
12:43:14 <Ailure> [14:23] <Rubidium> long vehicles are ugly, unless they are articulated vehicles?
12:45:54 <CIA-1> OpenTTD: truelight * r10242 /trunk/src/blitter/32bpp_anim.cpp: -Fix: avoid a segfault if you move your mouse at startup with 32bpp-anim
12:54:36 *** Alanin is now known as alanin
12:55:38 *** Vikthor has joined #openttd
12:56:36 *** Chris82 has joined #openttd
12:56:50 <Chris82> just a quick question, what is this timetable thing in the latest trunk?
12:59:40 <SmatZ> hello, since r10207, I can't destroy anything ( I have over 1<<32 Euros )
13:00:19 <SmatZ> "Not enough cash - requires e288"
13:00:39 <SmatZ> probably known problem...
13:03:48 <Rubidium> SmatZ: does the patch of FS#904 solve that issue?
13:04:36 <Noldo> Chris82: check who committed it and ask him
13:08:22 <Rubidium> Chris82: check the forum first
13:09:22 <SmatZ> Rubidium: I can't make it compile...
13:10:59 <Rubidium> SmatZ: which one did you take?
13:11:25 <SmatZ> Rubidium: I used both, I will try only the first now
13:12:42 <SmatZ> Rubidium: when applied only the mo_money_r10239.diff , it works
13:13:05 <SmatZ> it seems to correct this problem
13:13:31 <Rubidium> ok, that's all I need to know
13:15:39 <dihedral> guys, check it out, OpenTTDLib with it's first release :-)
13:18:46 <Rubidium> dihedral: I think you have to document those [vehicle] arrays a little (what index refers to what vehicle type)
13:19:13 <dihedral> that's on the todo list :-)
13:19:43 <dihedral> also fetching newgrf data is still to be done
13:21:03 <Rubidium> UDP packets are not certain to arrive -> retries etc.
13:21:21 <Rubidium> on the other hand, you can do quite a lot of caching of newgrf data
13:21:22 <dihedral> its the same for all the other queries that are made
13:22:02 <Rubidium> true, but when the first query fails, you've got nothing. When the newgrf query fails you've got half of the information
13:22:58 <dihedral> i get one packet with newgrf names and one packet with the md5 sums?
13:23:26 <Rubidium> in the "normal" query packet you only get the md5 sum + grf id
13:23:39 <dihedral> that's enough is it not?
13:23:44 <Rubidium> retrieving the name of the newgrf needs to be done using another query
13:23:58 <Rubidium> dihedral: grf id + md5sum says nothing to users
13:24:42 <dihedral> unless there is a mapping somewhere (newgrf crawler?)
13:25:16 <Rubidium> grfcrawler doesn't map md5sums nor has all grf ids
13:25:49 <dihedral> well - i shall give up after trying a few times :-)
13:26:41 <dihedral> yes i know that, which is quite sad actually :-P
13:33:58 <dihedral> at least i can try with the grf stuff :-)
13:34:19 <Sacro> i'm so pissed off, i might sit and rewrite it
13:34:51 <_42_> Sacro, Hackykid? hmm... I'm trying to remember... maybe... I'm not sure... no. I don't remember Hackykid.
13:34:58 <DorpsGek> TrueBrain: I have not seen Hackykid.
13:35:01 <Sacro> looks like he ain't coming back
13:35:05 <TrueBrain> he hasn't been here for ages :)
13:35:14 <TrueBrain> not with that name anyway... you never know
13:35:30 <_42_> Sacro, TrueLight was last seen joining the partyline on DorpsGek 6 weeks 4 days 2 hours 35 minutes ago (06.05. 10:59).
13:35:38 <DorpsGek> TrueBrain: I have not seen TrueLight.
13:35:47 <Sacro> never liked him much anyway :p
13:37:26 *** Brianetta has joined #openttd
13:38:12 *** Smoovious has joined #openttd
13:38:12 *** stillunknown has joined #openttd
13:38:12 *** mikegrb has joined #openttd
13:47:01 *** Frostregen_ has joined #openttd
13:47:24 <AntB> is there any comprehensive downloadable guides on making new GRF
13:48:07 <peter1138> well you can download the specifications
13:48:13 <peter1138> but it's not really a guide
13:53:41 *** Frostregen_ is now known as Frostregen
13:56:13 <AntB> I think i got the specs. I downloaded what was in the package what was on the TTDPatch site
13:57:27 <CIA-1> OpenTTD: truelight * r10245 /trunk/src/blitter/ (7 files): -Codechange: added GetName also to all Blitters, instead of only the Factory
14:01:34 *** ChanServ sets mode: +v peter1138
14:06:03 <Ailure> Taken for long time ago too
14:06:07 <Ailure> I was messing aroudn in mini-in
14:06:13 <Ailure> exprimentating with the subsidaries patch
14:06:25 <Ailure> Diagonal tracks over road
14:06:36 <hylje> why didnt that get trunked
14:06:36 <Ailure> and the diffrent coloured aircrafts on the airport
14:06:49 <Ailure> It was fun, but miniin was too unstable for my taste
14:06:56 <Ailure> so I only used it for one game
14:07:31 <Ailure> I liked the track sharing part of subsidaries patch
14:07:41 <Ailure> I always wanted to run a multiplayer game where severeal companies shares a track
14:07:51 <dihedral> will diagonal tracks over road ever get trunked?
14:08:34 *** Chris82 has joined #openttd
14:08:35 <Ailure> well they're kinda less needed now though
14:08:41 <Ailure> since you can do bridges over diagonal rails
14:08:46 <Ailure> or hell, over any combination of rails
14:09:08 <Ailure> I remember putting insane setups below rail before
14:09:58 <Chris82> well I use the same config settings on all my servers, and the others are all shown
14:10:07 <dihedral> udp port to the game closed?
14:10:11 <Chris82> advertise and stuff is properly set
14:10:16 <Rubidium> the udp query packets couldn't reach it for several times
14:10:19 <Chris82> nope, firewall doesn't block the port
14:10:33 <Chris82> is there a console command to re-advertise?
14:10:35 <dihedral> what game ist it (address?)
14:10:46 <Chris82> 85.190.1.233 and port let me check
14:10:58 <Rubidium> Chris82: it will readvertise every 15 minutes
14:11:26 <Chris82> port 63514 (Experimental Endless Game)
14:11:37 <Chris82> the 0.5.2 servers all advertise fine
14:12:08 <Ailure> I made lots of silly setups like this one
14:12:21 <Ailure> becuse it's fun to do stuff that used to be impossible for over a decade
14:12:59 <Ailure> a paused server shouldn't make any diffrence
14:13:00 <dihedral> i dont know - just saw the game data did not change
14:13:03 <Ailure> some servs are paused all the time <<
14:13:09 <Ailure> until a player comes along
14:13:17 <Chris82> yeah the server started in paused state
14:13:30 <Chris82> Ailure: True, my 0.5.2 are configured that way
14:13:43 <Chris82> so this shouldn't be the problem
14:13:58 <dihedral> and i can reach your game on udp...
14:14:04 <dihedral> just wait another 10 - 15 mins
14:15:24 <dihedral> should running newgame not also advertise?
14:15:41 <Chris82> I tried to restart a few times, and the server is now running for like 2 hours already
14:15:53 <Chris82> just checked netstat, the port is definitely reachable
14:16:24 <dihedral> netstat does not include possible firewall settings!
14:16:31 <Chris82> is it maybe because the version of the server changed very often the last days?
14:16:52 <Ailure> wonder what I should try in my next game
14:16:59 <Ailure> I have no idea what type of game I want to do
14:17:00 <Chris82> netstat -an should show me all opened ports?
14:17:06 <Biff> no, openttd doesnt work today :(
14:17:07 <Chris82> when they're firewalled they're not open
14:17:42 <Rubidium> Chris82: it's just that some packet got lost when your server was queried by the masterserver (at least if other servers from you are shown at the server list)
14:18:14 <dihedral> btw: its written Experimental
14:19:03 <dihedral> your game aint even in the offline list :-P
14:19:16 <Chris82> Experimantal Endless Game Offline < I see it there tho?
14:20:12 <Chris82> just renamed the server and restarted, maybe it works now
14:20:43 <Rubidium> Chris82: what ports does your firewall let through?
14:20:55 <Biff> hmm, newest openttd does nothing when i start it
14:20:59 <dihedral> searched for experimEntal :-P
14:21:04 <Biff> even --help does nothing, just returns
14:21:06 <Chris82> well it's configured to allow the openttd.exe, so it allows dynamically any port that openttd wants to use
14:21:32 <dihedral> i was able to query i...
14:21:35 <TrueBrain> Chris82: use a port < 60000
14:21:35 <Biff> magne@mean:~/src/openttd/bin$ openttd -h
14:21:37 <Biff> magne@mean:~/src/openttd/bin$
14:21:44 <TrueBrain> Biff: try ./openttd -h
14:22:05 <Chris82> is it bad to use such a high port number? all my servers have a port > 60000
14:22:14 <Biff> hmm, that worked for some strange reason (it points to the same binary)
14:22:23 <Biff> but ./openttd does not work
14:22:23 <TrueBrain> it should be alright, but > 60000 is normally used for MASQUARADE
14:22:37 <TrueBrain> Biff: there is a big difference between 'openttd' and './openttd'
14:22:50 <Chris82> I'll remember that :) will be easy to change them
14:22:59 <TrueBrain> see if it works, just a guess
14:23:05 <Biff> but the one found in path is a script which starts the same binary
14:23:17 <Biff> but ./openttd doesnt work, just returns
14:23:29 <Rubidium> Biff: but if ./openttd doesn't work, the script isn't going to work either
14:23:39 <Rubidium> is there actually an executable ./openttd?
14:23:49 <Biff> yes, else it would say command not found
14:24:08 <Rubidium> how large is the binary?
14:24:16 <peter1138> -d does nothing on its own
14:24:24 <TrueBrain> peter1138: yeah, I forgot :)
14:24:36 <peter1138> TrueBrain: i thought it defaulted to max to be honest
14:25:08 <Chris82> hmmm I just noticed some weird output on the console when starting the server
14:25:25 <Biff> that created a lot of output
14:25:36 <Chris82> first it says [net] listening on x.x.x.x:port
14:25:45 <Chris82> then [udp] .... same ip and port
14:25:58 <Chris82> and then another time [udp] listening on port 0.0.0.0:0
14:26:05 <TrueBrain> Biff: so the binary works ;) Now find what fails :p :p
14:26:34 <TrueBrain> Biff: dedicated server compile?
14:26:36 <Biff> hmm, Custom .grf has invalid format
14:26:47 <peter1138> dbg: [driver] Successfully probed video driver 'null'
14:26:57 <TrueBrain> Biff: as you don't have sdl compiled
14:27:01 <TrueBrain> so what you expect OpenTTD to do?
14:27:03 <peter1138> please compile with a video driver :p
14:27:19 <TrueBrain> try ./configure --with-sdl
14:27:21 <Biff> maybe i should try configure
14:27:53 <Biff> i compiled on a machine without x earlier, but i didnt run configure first, hmm
14:28:18 <dihedral> i always compile on a machine with no x
14:28:35 <Biff> yeah, i guess you just need the sdl libraries, which is probably missing
14:29:03 <dihedral> nono - YOU need the sdl libraries... i already have them :-P
14:29:32 <Biff> yeah, but my server doesnt
14:29:47 <Biff> so it must have executed ./configure by itself or something
14:30:07 <TrueBrain> at some stage you did a ./configure
14:30:11 <TrueBrain> and it did tell you that without SDL
14:30:17 <TrueBrain> you won't have a video driver
14:30:28 <Biff> hmm, maybe, i must have been sleeping or something then :P
14:30:41 <TrueBrain> we can fix and try to avoid tons of things
14:30:47 <TrueBrain> but only till a certain level
14:30:49 <TrueBrain> we can't fix the user :)
14:31:39 <Biff> hmm, then there was the money problem
14:32:09 <Biff> even tho i have lots of money it says i cant afford things like bulldozer station
14:32:41 <CIA-1> OpenTTD: rubidium * r10246 /trunk/src/ (25 files in 4 dirs): -Fix (r10297): some forgotten money conversions and truncation issues. Thanks to benc for providing the patch.
14:33:31 <dihedral> remove the Makefile and have it written when ./configure is done :-)
14:49:50 <SmatZ> why is tunnel's price limited to 400 000 000 ?
14:51:35 <Rubidium> so it wouldn't overflow as easy in the "old" system?
14:52:33 <SmatZ> will the 400 000 000 limit be increased now?
14:52:43 <SmatZ> if there is no other reason
14:53:47 *** Vikthor has joined #openttd
14:55:04 <CIA-1> OpenTTD: rubidium * r10247 /trunk/src/ (22 files in 2 dirs): -Fix (r10210): *always* call SetDParamMoney when you want to place money in some string.
14:58:55 <CIA-1> OpenTTD: rubidium * r10248 /trunk/src/tunnelbridge_cmd.cpp: -Codechange: don't limit the cost of tunnels.
15:05:22 *** Nickman is now known as Nickman^Away
15:06:19 <SmatZ> Rubidium: thanks, I feel better now :) but there is a little problem - when I try to build a tunnel over whole 2048x2048 map, I get estimated price -2 euro (and cannot build it anyway)
15:07:18 <Rubidium> that doesn't sound right ;)
15:07:29 <dihedral> that does not sound good either :-P
15:11:25 *** Vikthor has joined #openttd
15:12:18 <peter1138> heh, locks up when leveling a 2048x2048 map
15:12:40 <SmatZ> it takes ages when I put mouse cursor at the coast to build a tunnel
15:12:55 <SmatZ> peter1138: surely lock up?
15:13:08 <peter1138> ok, not a lock up, but very slow
15:13:23 <CIA-1> OpenTTD: rubidium * r10249 /trunk/src/town_cmd.cpp: -Fix [FS#906]: town tried to gather information about the neighbourhood of a tile when it couldn't even *ever* build on that tile.
15:14:39 <SmatZ> peter1138: yes :) the code of drawing of selected sprites is probably very slow, maybe it is trying to draw tiles outside the viewport?
15:15:38 <Rubidium> SmatZ: it's determining till where it can build the tunnel
15:16:51 <dihedral> what would you expect?
15:17:52 <dihedral> on a 2048 you would expect it to be quite some itterating to do... or not?
15:18:51 <SmatZ> yes, I see now - IsTunnelInWay(end_tile, start_z) is called 2048 times, and it takes very long time to determine if there is not any tunnel
15:19:07 *** Nickman^Away is now known as Nickman
15:20:00 <Caemyr> if no - maybe some progressbar would be usefull?
15:20:28 <Caemyr> with title like "Calculating tunnel lenght"
15:20:30 <SmatZ> IsTunnelInWay tests all directions, even those you are trying to build at
15:21:15 <Caemyr> not everytime, but after a fixed number of IsTunnelInWay() iterations
15:21:43 <SmatZ> it should be sufficient to test only the orthogonal directions, and only in that direction that is more near to the edge
15:23:52 <Caemyr> it could lag the server:P
15:24:23 <SmatZ> only building the tunnel would lag the server - and you would need a lot of money to build so long tunnel :)
15:26:46 <Caemyr> to lag the server this way
15:27:06 <SmatZ> yes, but - it will lag the server for 10,20 seconds
15:27:16 <SmatZ> and you would need a lot of money
15:27:24 <SmatZ> but with a modified client
15:27:40 <SmatZ> maybe even with a normal client...
15:28:10 <dihedral> TrueBrain: how often do you get this "why is my game not being advertised"?
15:28:43 <TrueBrain> dihedral: less often nowedays then it used to be
15:30:36 <dihedral> a webform so others can check if some the masterserver gan access the game :-)
15:31:40 <SmatZ> peter1138: I just tested it - my client got disconnected, because its computations took too long :)
15:36:11 <Rubidium> SmatZ: the -2 is because it "wrapped" around when converting INT64_MAX pounds to euros
15:37:17 <Rubidium> because that's just "money" * 2
15:37:18 <CIA-1> OpenTTD: rubidium * r10250 /trunk/src/strings.cpp: -Fix: money is always 64 bits, so always parse those 64 bits.
15:37:30 <Rubidium> if you set it to pounds you'll see the correct amount
15:37:38 <SmatZ> peter1138: with a modified client, it is possible to choke the server this way
15:37:59 <SmatZ> Rubidium: even with pounds I get -1 pound as the price
15:39:02 <SmatZ> my duron 1300 as server is still computing :-D
15:40:44 <Rubidium> I see only one solution: adding the end tile of the tunnel to the parameter and first check whether it's affordable and then check whether it's buildable
15:42:31 <SmatZ> probably ... checking inside the loop if the player has enough money is probably not possible
15:42:40 *** Thomas[NL] has joined #openttd
15:43:06 <SmatZ> but on a real server, there won't be so big flat lands :) the check would take much less time
15:44:00 <Smoovious> and after seeing if it is buildable, conidering terrain only, now you have the start and endpoints, check through the list of tunnels... ignore tunnels on a different elevation, ignore tunnels with the same X on its endpoints, if the one you're building has the same X on its own endpoints (and they aren't the same X)
15:44:41 *** ChanServ sets mode: +o Bjarni
15:44:50 <Smoovious> then that leaves only having to check the other values... does your X fall in between the left over tunnel' Y's
15:44:53 <SmatZ> there is not any list of tunnels atm
15:45:05 <SmatZ> return IsTunnelInWayDir(tile, z, DIAGDIR_NE) || IsTunnelInWayDir(tile, z, DIAGDIR_SE) || IsTunnelInWayDir(tile, z, DIAGDIR_SW) || IsTunnelInWayDir(tile, z, DIAGDIR_NW);
15:45:16 *** skidd13 has joined #openttd
15:45:19 <SmatZ> ^^^ isn't checking in all 4 direction useless?
15:45:21 <Smoovious> well, there has to be some way for it to know there is a tunnell...
15:45:46 <SmatZ> yes, it checks in all directions till it finds and z < tunnel_z
15:45:51 <Rubidium> SmatZ: yes it's useless
15:46:07 <SmatZ> and then checks if it is a tunnel tile
15:47:00 <Smoovious> ok... well, if there is no index of tunnels in the code, then perhaps it should keep one... would make checking for them a lot less work
15:48:11 <Smoovious> would then make having non-standard tunnels easier to deal with too... ones that curve, or change elevation... .. .
15:48:15 <CIA-1> OpenTTD: glx * r10251 /trunk/src/video/win32_v.cpp: -Fix (r10186, FS#907): alt-tab back into openttd could leave the taskbar visible
15:49:32 <peter1138> Rubidium: even with end tile you need to check each tile
15:49:34 <Smoovious> could use the same index for bridges too
15:49:36 <SmatZ> finally, the server's computation finished :)
15:49:56 <Rubidium> peter1138: well, you can do cost calculation first, which is pretty fast
15:50:12 <SmatZ> peter1138: yes, but when you know the player cannot afford it anyway, you dont need to check for crossing tunnels
15:51:40 <dihedral> would it not be faster to itterate over existing tunnels built on the same level and check if they use that tile
15:51:45 <Smoovious> or continue to check for crossing tunnels, so he doen't have to wait around until he can afford it only to find it isn't b uildable
15:52:01 <dihedral> rather than itterating each tile your tunnel would be built through?
15:52:41 <Smoovious> not enough to catch the tunnel pieces in between the endpoints
15:54:03 <peter1138> iterate existing tunnels, eh?
15:54:15 <dihedral> was just a thought!!
15:54:19 <peter1138> requires a full map scan, but that can't be that slow, can it?
15:54:41 <dihedral> thought there was perhaps some sort of 'tunnel list'
15:55:00 <Smoovious> that's what I thought too... and am advocating. :)
15:56:04 *** Vikthor has joined #openttd
15:57:32 <CIA-1> OpenTTD: rubidium * r10252 /trunk/src/strings.cpp: -Fix: never overflow when applying exchange rates before drawing the amount of money.
15:57:45 <Rubidium> Smoovious: what kind of positive impact would such a tunnel list have?
15:58:31 <Rubidium> in worst can absolutely none
15:59:07 <Smoovious> well, it would simplify having to search the map for encroaching tunnels/bridges... instead you'd just check the index for them which has all of the linked endpoints...
15:59:24 <dihedral> in such cases of players building long tunnels it would speed up the process of finding out if a tunnel is in the way
15:59:38 <dihedral> but then - searching the endpoint will still have to be done!
16:00:24 <Smoovious> same for raising and lowering land, without the index, you gotta keep checking the map looking for tunnels... with the index, you don't waste time searching the map, you check the list...
16:00:34 <Rubidium> Smoovious: you'd have to search the WHOLE tunnel list, even for a tunnel of 5 long you need to iterate the whole list 3 tiles (either 3xlist or listx3)
16:00:43 <Smoovious> would take a lot less processor impact if you don't have to keep finding them all the time
16:00:57 <Smoovious> better than searching the whole map
16:01:05 <Rubidium> Smoovious: it doesn't search the whole map
16:01:16 <peter1138> Rubidium: if the list stores the start & end tiles you don't need a loop to test for intersection
16:01:17 <Rubidium> it only searches where there could possibly be tunnels
16:01:24 <Smoovious> how far does it check for tunnels before it determines t here isn't one
16:01:52 <Rubidium> peter1138: why not? you need to check for three intersection points in a tunnel of length 5
16:01:55 <Smoovious> which could end up being searching the whole length/width of the map, perpendicular to the proposed route
16:02:44 <dihedral> and the tunnel list could hole the level at which the tunnel is built
16:03:14 <Smoovious> that should be covered by the x/y of the endpoints already
16:03:15 <Rubidium> Smoovious: for a tunnel list you've got exactly the same problem; even worse
16:03:28 <peter1138> Rubidium: for x-axis tunnel: if (tiley == startx && tilex > startx && tilex < endx) { intersect }
16:03:38 <peter1138> plus height checking
16:03:59 <peter1138> first startx is starty ;)
16:04:26 <dihedral> on my way home... will join you later again :-)
16:04:37 <peter1138> still tons of iteration of course
16:05:14 <Rubidium> peter1138: but that is for one of the 3 x-axis that the 5-length tunnel intersects
16:05:25 <Smoovious> a line is defined by its endpoints, and it is a simple matter to find if that line will intersect another... as I currently understand it tho, right now it is searching for the existence of the lilne to b egin with by searching through the map, every time a tunnel/bridge is attempted to build, or during terrafoorming
16:06:25 <Smoovious> checking an index of x1,y1/x2,y2's of objects that already exist, is a ton less work than searching outward on the map looking for tunnel tiles
16:07:38 <Rubidium> Smoovious: only in some cases, not all
16:08:20 <Smoovious> alright... I'll bite... in what cases does it not
16:09:38 <Thomas[NL]> ehh latest trunk all the generated towns are 1 street-tile and 2 buildings
16:09:40 <Rubidium> the case where there are 4 tunnels on a map an I want to build a tunnel through a 1x1 "hill" (so 1 flat tile that is raised)
16:10:18 <Smoovious> ok, you're just messing with me now...
16:10:37 *** Sacro|Laptop has joined #openttd
16:10:56 <Rubidium> no, I'm saying: don't make the average case horribly slow to speed up the worst case
16:11:15 <Smoovious> but... say that 'hill' is in the middle of a vallley... land rises to either side of it for a long distance...
16:11:24 <Smoovious> it wouldn't be horribly slow
16:11:44 <Smoovious> the whole point of having an index to begin with is to save time having to search them out all lthe time
16:12:47 <Rubidium> latest trunk works for me ;)
16:12:55 <CIA-1> OpenTTD: rubidium * r10253 /trunk/src/town_cmd.cpp: -Fix (r10249): putting the < the wrong way around made the new towns pretty small.
16:13:07 <Rubidium> ofcourse CIA is slow, so you can take advantage of that :)
16:17:20 <skidd13> About the town roads... What about FS897?
16:18:02 <CIA-1> OpenTTD: truelight * r10254 /trunk/src/ (14 files in 2 dirs): -Feature: loading indicator, which shows in % how full a vehicle is while loading/unloading (TheJosh)
16:34:10 *** |Jeroen| has joined #openttd
16:35:11 <Sacro|Laptop> whose gonna help me code PBS?
16:35:24 <TrueBrain> you are going to help yourself :)
16:35:34 <Noldo> Sacro|Laptop: you'll need KUDr for that
16:36:16 <TrueBrain> Sacro: check the userlist.....
16:37:27 <Sacro> Bjarni: i've coded before
16:38:04 <TrueBrain> Bjarni: leave him alone...
16:38:18 <TrueBrain> if he thinks he can do it, let him!
16:38:57 <Bjarni> I'm not going to stop development of PBS
16:40:20 * Sacro puts #ifndef OSX at the top
16:40:43 <Bjarni> I just don't see any reasons to do that
16:40:50 <Sacro> stops mac users compiling it
16:41:05 <Bjarni> OSX isn't defined when compiling on mac
16:41:08 <Rubidium> it means we can let Bjarni fix PBS because it's mac specific code ;)
16:41:48 <Bjarni> it wouldn't be mac specific if the code is active for all OSes but OSX
16:41:58 <TrueBrain> I wonder when Bjarni will fix 32bpp for OSX
16:42:20 <Bjarni> I have a deadline at 14:00 tomorrow
16:42:29 <Bjarni> I give that one priority
16:51:50 * Smoovious hands peter1138 a napkin.
16:54:11 <CIA-1> OpenTTD: truelight * r10255 /trunk/src/ (5 files in 2 dirs): -Codechange: remove some old debug code nobody was using anymore
16:56:13 <hylje> hey, you just nuked those things i debugged with
16:56:19 <SmatZ> Rubidium: will it work when you try to build a tunnel over an existing tunnel?
16:57:16 <Rubidium> SmatZ: haven't tested that (yet)
16:58:40 *** Nickman is now known as Nickman^Away
17:00:00 <Rubidium> yes, it seems to work
17:00:06 <skidd13> something is wrong with the money displayed in the difficultiy settings.... LOL damned is this a lot. -> €toomuchtowritealldown
17:01:05 *** dihedral has joined #openttd
17:01:20 *** |Jeroen| has joined #openttd
17:01:23 <peter1138> i'm getting massive profits :p
17:01:30 <skidd13> And it changes it I change the value of the industry density... LOL
17:02:00 <peter1138> £70,660,801,955,244
17:03:28 <Rubidium> peter1138: probably printed wrong yes
17:03:45 <peter1138> SetDParamMoney(0, ...
17:03:49 <peter1138> SetDParamMoney(1, ...
17:03:56 <peter1138> int64 will take up 2 slots
17:04:26 <Rubidium> yes, which is the "cause" of the trouble
17:04:32 *** Vikthor has joined #openttd
17:04:48 <Rubidium> as almost everything is now 64 bits, but apparantly not everything actually is
17:04:55 <peter1138> ok, sorry i thought you'd changed it
17:05:27 <Rubidium> so there are two solutions
17:05:39 <peter1138> SetDParamMoney(2, ...
17:05:41 <Rubidium> make those DParam variables just 64 bits ;)
17:05:53 <peter1138> or make _decode_parameters 64 bit, yes
17:06:32 <Rubidium> yes, that's what I meant
17:06:32 <Biff> hmm, does openttd -g filename.sav only work for server or something?
17:06:37 <Biff> it did not open a savegame
17:07:49 <Biff> does it expect a path relative to the personal dir maybe?
17:07:51 <peter1138> if the savegame doesn't exist you'll get an (in game) error message
17:08:19 <peter1138> then maybe your "openttd" script is not passing all parameters
17:09:25 <CIA-1> OpenTTD: belugas * r10256 /trunk/src/ (newgrf_commons.cpp newgrf_commons.h newgrf_industries.cpp): -Add: Addition of IndustryTileOverrideManager
17:09:38 <peter1138> skidd13: pass TownLayout to IsRoadAllowedHere, not Town *
17:09:53 <Caemyr> another small step for him and great leap for OTTDity
17:10:26 <Belugas> thanks Caemyr, but it is really nothing :)
17:10:34 <peter1138> +SLE_CONDVAR(Town, road_layout, SLE_UINT8, 67, SL_MAX_VERSION),
17:10:38 <peter1138> ^^ dodgy with enums
17:12:08 <Wolf01> mmmh i just noticed i forgot about 2 tiles
17:13:02 <peter1138> +t->road_layout = CheckSavegameVersion(66) ? TL_ORIGINAL : _patches.town_layout;
17:13:09 <peter1138> i'd say always use the patch option
17:13:57 <peter1138> also, version 66 is wrong for town layout introduction, isn't it?
17:14:29 <skidd13> SLE_UINT8 are 256 values aren't? V66 was right at the time the patch was written (yesterday)
17:18:51 <CIA-1> OpenTTD: miham * r10257 /trunk/src/lang/ (6 files): (log message trimmed)
17:18:51 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2007-06-21 19:15:05
17:18:51 <CIA-1> OpenTTD: danish - 25 fixed, 50 changed by ThomasA (75)
17:18:51 <CIA-1> OpenTTD: finnish - 117 fixed by habazi (117)
17:18:51 <CIA-1> OpenTTD: hungarian - 6 fixed by miham (6)
17:18:52 <CIA-1> OpenTTD: romanian - 8 fixed, 9 changed by CrystyB (17)
17:18:52 <CIA-1> OpenTTD: spanish - 7 fixed by jfrank (7)
17:19:42 *** Eddi|zuHause has joined #openttd
17:20:44 <hylje> what does ottd i18n rely on?
17:22:46 <Eddi|zuHause> what kind of question is that?
17:23:00 <Eddi|zuHause> on text files compiled with strgen...
17:25:32 <CIA-1> OpenTTD: rubidium * r10258 /trunk/src/ (27 files in 2 dirs):
17:25:32 <CIA-1> OpenTTD: -Codechange: as we are now using int64 all over the place, it's better to use int64 variables in the string generating too instead of packing them into two int32s.
17:25:32 <CIA-1> OpenTTD: -Fix: some displays of money were wrong.
17:26:15 <glx> skidd13: enums are 32bits values on some platforms
17:27:35 <CIA-1> OpenTTD: rubidium * r10259 /trunk/src/tunnelbridge_cmd.cpp: -Fix (r10258): committed a little too much.. would've made pretty cheap tunnels though :)
17:27:42 <Rubidium> and 64 bits on others...
17:27:43 <skidd13> so SLE_UINT32 to be on the secure side?
17:28:45 <glx> do it like we did (search for PlayerByte or something like that)
17:30:39 <glx> PlayerByte is the wrong example :) OwnerByte is better
17:33:54 <skidd13> seen already... -> AFAICS the enum is already set to 8 bit in openttd.h (~line 225) so wher's the problem?
17:35:10 *** Wolfolo|AWAY has joined #openttd
17:35:10 *** Wolf01 is now known as Guest21
17:35:10 *** Wolfolo|AWAY is now known as Wolf01
17:35:17 <Wolf01> i need a shower, is too hot and muggy today :O
17:35:22 *** Wolf01 is now known as Wolf01|AWAY
17:35:33 <Eddi|zuHause> it was raining here all day...
17:36:13 <glx> skidd13: in town.h use TownLayoutByte instead
17:36:19 <Bjarni> it will be railing all night here
17:36:28 <CIA-1> OpenTTD: miham * r10260 /trunk/src/lang/piglatin.txt:
17:36:28 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2007-06-21 19:36:07
17:36:28 <CIA-1> OpenTTD: piglatin - 12 fixed by adammw (12)
17:36:53 <Bjarni> some rain clouds coming from Germany are going to give us like a months rain within like 6 hours or so
17:37:32 <skidd13> I thought the clouds droped all their load here. :)
17:38:09 *** tokai|ni has joined #openttd
17:38:26 <Eddi|zuHause> the rain was insane here this morning
17:38:43 <Bjarni> a funny twist is that the guys, who help removing water from basements and stuff are on strike, so the deal is to have a good house that can keep the water out or you are fucked
17:38:58 <Eddi|zuHause> i went 10m from my house door to the bus that was parking right outside on the street... i got totally wet...
17:39:27 <CIA-1> OpenTTD: rubidium * r10261 /trunk/src/ (43 files in 5 dirs): -Cleanup: we do not need CURRENCY64 and CURRCOMPACT64 anymore, because everything is already 64 bits by default.
17:39:31 <Bjarni> you didn't say how long you were waiting for the bus outside
17:40:34 <glx> I think the bus was already there
17:40:50 *** Nickman^Away is now known as Nickman
17:41:07 <Eddi|zuHause> the bus was waiting for me
17:42:26 <Eddi|zuHause> it's more like a taxi, that you order at least 2h in advance, if there is no regular bus scheduled within 1h before or after... it costs the same as the bus, which means no additional cost if you have a monthly bus ticket, or like me a semester ticket
17:43:55 <Eddi|zuHause> it's a really fine service :)
17:44:07 <Bjarni> I once used one like that and a car showed up... turned out only two people called, so it was too expensive to send a bus :)
17:44:26 <Eddi|zuHause> they introduced a lot more bus stops with the service, and one is practically in front of my house
17:44:46 <Eddi|zuHause> yes, they always send cars
17:44:55 <Eddi|zuHause> usually mini-vans
17:45:57 <Eddi|zuHause> there are regular busses at 8 and 10 in the morning, but i must be in the city at 10, so i can order a bus at 9
17:46:17 <Eddi|zuHause> which is 1h from the previous and 1h from the next regular bus
17:46:47 <Eddi|zuHause> it has so many advantages
17:46:55 <Eddi|zuHause> they wait for me if i am 2 minutes late
17:47:08 <Eddi|zuHause> i don't have to run into the village to catch the bus
17:47:49 <peter1138> which is the correct patch :o
17:51:18 <skidd13> the one with the correct code (if you ask confuzius) LOL
17:54:30 <Ailure> when I'm back I go try out the timetable thing
17:54:35 <Ailure> Nightlies are compiled soon :)
17:55:19 <Giddorah> Any devs available for a PM?
17:56:27 <Ailure> sometimes it better to say it in public so whoever is on sees it
17:57:03 <Giddorah> Aight... On strin STR_TIMETABLE_GO_TO
17:57:23 <stillunknown> Who did something to the news system recently?
17:57:56 <Giddorah> On string STR_TIMETABLE_GO_TO it's {string1} {string2} in english... That in turn translates into {string} {string} after translation... Can't this be a problem?
17:58:31 *** Sacro|Laptop has joined #openttd
17:58:41 <Eddi|zuHause> stillunknown: the last thing i remember was the split between "important" and "unimportant" economical messages
17:59:20 <peter1138> Giddorah: no, string1/2 etc are only valid for english
17:59:42 <stillunknown> Eddi|zuHause: revision?
17:59:54 <Eddi|zuHause> stillunknown: several months ago
18:00:28 <stillunknown> I'm referring to something that happened today.
18:01:06 <Eddi|zuHause> i have not checked today yet...
18:01:31 <stillunknown> news_gui.cpp:278: void AddNewsItem(StringID, uint32, uint, uint): Assertion `_total_news == 30' failed.
18:01:43 <Giddorah> peter1138: Then how do you make the correct call for the correct string if there's several strings in the same line? :P
18:02:14 *** alanin is now known as Alanin
18:02:22 *** Alanin is now known as alanin
18:02:31 <Eddi|zuHause> stillunknown: maybe related to r10258?
18:02:59 <Eddi|zuHause> sounds a little far fetched :)
18:03:36 <stillunknown> rubidium: Did you change anything today that is somewhat related to the news system?
18:05:45 <eekee> A multiplayer with current nightly just crashed with a news-related error a day or two into the game
18:06:19 <eekee> openttd: /data3/Downloads/Games/ttdx/openttd/trunk/src/news_gui.cpp:278: void AddNewsItem(StringID, uint32, uint, uint): Assertion `_total_news == 30' failed.
18:06:27 *** Brianetta has joined #openttd
18:06:31 <peter1138> Giddorah: pass, but STRINGn consumes n args, it doesn't choose the arg at position 'n'
18:06:55 <peter1138> i think there's an index parameter you can use
18:07:37 <Giddorah> Haven't seen another string containing two strings before
18:07:41 <Eddi|zuHause> Giddorah: the translation engine always takes the {STRINGn} values from the matching english string, so just use {STRING} in the translation
18:08:14 <dihedral> _network_player_info[nd->company].num_vehicle[0]
18:08:30 <dihedral> is there any place i can find the defined enum for that 0?
18:09:11 <Eddi|zuHause> Giddorah: there's a way to reverse the order of the strings, with something like {STRING:1} or so, i don't remember exactly, there are probably examples somewhere
18:09:12 <Giddorah> Eddi|zuHause: I know... But what about {STRINGx} {STRINGy}?
18:09:57 <Giddorah> It adds x and y itself without showing? Or are the strings just gonna be stripped down to {STRING} {STRING}?
18:10:11 <Eddi|zuHause> it adds the x automatically
18:10:19 <Giddorah> Aaah! That makes sense
18:10:33 <Eddi|zuHause> that's why you need english.txt as well as your_language.txt for strgen
18:11:12 <Eddi|zuHause> all the information is already in english.txt so it can take it from there
18:11:26 <Eddi|zuHause> the information in your_language.txt would be redundant
18:11:52 <Eddi|zuHause> redundant information always causes trouble on updates/changes
18:13:31 <Smoovious> I'm on a current nightly game that reset without warning... no idea why yet
18:13:59 <Eddi|zuHause> yeah, current nightly has a crashing bug
18:14:17 <Eddi|zuHause> news_gui.cpp:278: void AddNewsItem(StringID, uint32, uint, uint): Assertion `_total_news == 30' failed.
18:14:34 <Smoovious> well... it is a nightly after all...
18:14:39 <Eddi|zuHause> well, it's technically only a crash if you have assertions enabled
18:14:53 <Smoovious> no idea, I'm not serving
18:15:09 <Eddi|zuHause> but it might cause even worse trouble without :p
18:18:04 <skidd13> glx: If I set the road_layout in my patch as TownLayoutByte the random thing is f***ed up. :(
18:18:16 <Smoovious> Win32: File: /compile_farm/openttd/nightlly/compile_dir/src/town.h Line: 273 Expression: index < _Town_pool.total_items
18:21:36 <Eddi|zuHause> hm, that's a totally different place
18:22:45 <Smoovious> I'd debug i t if I knew how it worked. :P
18:24:33 <Smoovious> oh well, crashed without a dump file
18:24:49 <Bjarni> I just came to wonder... what would happen if you call a static inline function recursively?
18:25:29 <Smoovious> the static builds up until the computer explodes in a big electric-blue arc?
18:26:10 * Bjarni wonders about making such a function and commit it to see who compiles without reading what is actually committed
18:26:11 <Eddi|zuHause> the compiler will probably barf out
18:26:46 <Eddi|zuHause> or make it not inline automatically
18:27:32 *** Wolf01|AWAY is now known as Wolf01
18:30:49 <peter1138> Bjarni: nothing special happens though
18:31:22 <Ailure> I love the smell of a newly compiled nightly
18:32:05 <Smoovious> maybe you need your nose checked...
18:38:23 <stillunknown> Ailure: The current nightly is probably useless.
18:41:12 <Ailure> I thought my crash was related to something weird I was playing with
18:41:21 <SmatZ> openttd: /mnt/svn/openttd/trunk/src/town.h:273: Town* GetTown(uint): Assertion `index < _Town_pool.total_items' failed.
18:41:44 <Ailure> didn't someone switch some < > operator recently
18:42:27 <Ailure> not saying that it was wrong to do
18:42:35 <Ailure> since that bug might just hidden other bugs somehow
18:42:43 <Ailure> i'm not too sure about the inner workings of openTTD though
18:42:49 <Smoovious> <CIA-1> OpenTTD: rubidium * r10253 /trunk/src/town_cmd.cpp: -Fix (r10249): putting the < the wrong way around made the new towns pretty small.
18:43:53 <Ailure> but I have no idea if that's the cause or not :p
18:45:30 <Ailure> happens exactly after six months of runtime
18:45:40 <SmatZ> #3 0x00000000005149e1 in GetTown (index=18492) at /mnt/svn/openttd/trunk/src/town.h:273
18:46:53 <SmatZ> it happes after 13 days for me :)
18:46:54 <Ailure> it always seem to crash on july
18:47:04 <Ailure> though I managed to go 18 months this time
18:49:22 <Smoovious> tried quitting a network game before the server crashed and my end crashed
18:50:36 <Wolf01> mmmh ottd is really heavy with the 32bpp-anim, and it crashes when i press on the X to close the app (before the "do you want to quit" popup)
18:51:08 <Smoovious> I crashed before the 'want to quit' confirmation box too
18:51:32 <Eddi|zuHause> Smoovious: dump files are only on release builds, not nightlies
18:52:11 <Ailure> the little I managed to try of Timetable system is nice
18:52:19 <Eddi|zuHause> the dump files are from MSVC, but the nightlies are compiled with g++
18:53:28 <Smoovious> not familiar with g++... thnx
18:55:55 *** NukeBuster has joined #openttd
19:00:53 <stillunknown> Rubidium: Interested in the fix for the news problem?
19:02:21 <stillunknown> params must be uint64
19:02:37 <stillunknown> because in news_gui.cpp COPY_OUT_DPARAM is used
19:03:14 <Rubidium> stillunknown: that only a partial one then
19:03:24 <stillunknown> I'm not saying this is the fix, just a hint to the cause.
19:04:49 <Rubidium> yeah, I've got already several more causes :(
19:05:59 <stillunknown> I just did assert hunting and sticking fprintf's in the code, this came up eventually.
19:06:36 <stillunknown> Since the total_news was jumping from 30 to 205, which was very strange.
19:08:04 <stillunknown> Rubidium: Causes for the specific assert or just more problems?
19:08:55 <Rubidium> probably all problems you've seen tonight
19:08:58 <Rubidium> or rather, hopefully
19:09:05 <CIA-1> OpenTTD: rubidium * r10262 /trunk/src/ (7 files): -Fix (r10258): some places that needed to be changed to uint64 were hidden/forgotten, which caused memory corruptions and that in caused all kinds of assertions to trigger.
19:11:57 <stillunknown> Rubidium: have you actually compiled it?
19:12:04 <stillunknown> since it asserts during compile
19:12:31 <SmatZ> /mnt/svn/openttd/trunk/src/misc_gui.cpp:1220: error: size of array 'a' is negative
19:12:32 <Rubidium> let me guess, you've got a 64 bits compiler
19:13:15 <Rubidium> how big is that struct for a 64 bits compiler?
19:14:04 <Rubidium> does it give that assertion when you move the StringID message line one line down, i.e. below uint64 params[10] ?
19:15:57 <Eddi|zuHause> hmz... my amarok is totally acting up lately...
19:16:27 <Eddi|zuHause> like suddenly forgetting the entire music database...
19:16:31 <SmatZ> uint64 params[10]; ///< local copy of _decode_parameters
19:16:31 <SmatZ> StringID message; ///< message shown for query window
19:16:55 <Smoovious> got an assert in an industry file now... window isn't wide enuf to show the whole thing... but the expression was: index < _Industry-pool.total-items
19:17:03 <Eddi|zuHause> sounds like an alignment problem, SmatZ
19:17:14 <Rubidium> Smoovious: what version?
19:17:35 <Smoovious> is that superceded now?
19:17:42 <SmatZ> Eddi|zuHause: actually I don't know, but i works now :)
19:18:02 <Smoovious> ok... did it get redone with the nightly farm or should I compile?
19:18:41 <Eddi|zuHause> SmatZ: yeah, that "it works if i change the order" is a typical symptom for alignment stuff
19:18:54 <Eddi|zuHause> Smoovious: you need to compile manually
19:19:03 <CIA-1> OpenTTD: rubidium * r10263 /trunk/src/misc_gui.cpp: -Fix (r10262): due to 64 bits alignment a struct became a little too large.
19:19:29 <Rubidium> Smoovious: it did in about -22:41
19:19:42 <Rubidium> i.e. next nightly will be tomorrow
19:20:10 <peter1138> news at 11: you're all exceedingly lucky that trunk happens to normally be usable
19:20:11 <SmatZ> Eddi|zuHause: yes, looks so
19:20:15 <Smoovious> yeah, I know... that's how I got 10261... didn't know if it would get a bump to recompile tho or not
19:20:31 *** nihil84 has joined #openttd
19:20:39 <Smoovious> hope I can compile with the proper version # this time instead of norev000
19:20:58 <Thomas[NL]> is the x- and y-offset the distance from the top-left-image corner to the center of the tile?
19:21:09 <glx> Smoovious: what's your compiler?
19:22:13 <glx> not easy to get the rev with that
19:22:37 <glx> you can tweak the source, or use a define
19:23:14 <stillunknown> The aircraft movement code, has that been overhauled since the first RE'ing?
19:23:17 * Smoovious waits for svn to finish updating ~600 revisions...
19:24:21 *** nihil84 has joined #openttd
19:25:04 *** Nickman is now known as Nickman^Away
19:30:13 *** nihil84 has joined #openttd
19:34:01 *** Chris82 has joined #openttd
19:34:17 <Chris82> I just downloaded r10263 but there are several errors compiling it
19:34:29 <Chris82> ..\src\lang\english.txt(3373): error: Undefined command 'CURRCOMPACT64'
19:34:35 <Chris82> and 4 errors with the loading indicators patch
19:34:54 <Chris82> can anyone confirm that? (I used MSVC to compile)
19:35:21 <Rubidium> Chris82: update your whole working copy
19:35:46 <Rubidium> secondly loading indicators is likely to not apply anymore
19:36:01 *** peter1138 has joined #openttd
19:36:31 <Chris82> what I meant is that since loading indicators was added to trunk I get errors
19:36:39 <Chris82> I didn't use the .patch/.diff file from the thread
19:36:55 <Chris82> but I try to revert everything and re-compile
19:38:32 <Chris82> works, then I need to figure out which patch caused an interence with the loading indicators code
19:38:39 <Chris82> Tortoise didn't give me any conflicts
19:43:04 <stillunknown> peter1138: Do you happen to know if aircraft code was ever overhauled?
19:43:46 <peter1138> it's had changes but no rewrite, heh
19:44:01 <stillunknown> It seems so different from all the other movement code.
19:44:17 <Chris82> found the error, the loading indicators from trunk don't work with the better graphs patch :(
19:44:22 <Rubidium> aircraft are totally different
19:45:35 <Chris82> ..\src\lang\english.txt(3373): error: Undefined command 'CURRCOMPACT64' < what does this error mean?
19:45:48 <peter1138> it means the command was removed
19:45:53 <Rubidium> that you've got old language files
19:46:11 <Chris82> hmmm but I just downloaded the one from current trunk
19:46:39 <Rubidium> well, CURRCOMPACT64 isn't in trunk anymore
19:47:01 <Eddi|zuHause> Chris82: you sure it's not a line from some patch?
19:47:10 *** Thomas[NL] has joined #openttd
19:47:46 <Chris82> I am just checking that
19:48:19 <Chris82> I have a patch file which integrates about 8 patches at once, but there's no line affecting the CURRCOM... line
19:49:21 <peter1138> that's nice. line 3373 doesn't contain CURRCOMPACT64, however
19:49:23 <Chris82> ahh the better graph patch uses CURRCOMPACT64 for STR_GRAPH_Y_LABEL_CURRENCY
19:49:42 <Chris82> I misspelled it when looking for it in the patch file
19:49:48 <Chris82> what is the replacement for it?
19:50:01 <Chris82> STR_GRAPH_Y_LABEL_CURRENCY :{TINYFONT}{CURRCOMPACT64}-
19:50:04 <Chris82> that's the whole line
19:50:07 <Eddi|zuHause> without 64 probably
19:51:18 <Chris82> sorry if I ask too many stupid questions today lol :p
19:52:32 <Eddi|zuHause> Chris82: next time check the svn log, it tells you that r10261 has to do with CURRCOMPACT64, then check the diff from that revision
19:52:58 <Eddi|zuHause> it's only like 3 revisions ago
19:54:32 <Chris82> thanks for the tip, I'll check it more closely next time, I usually just rush through the log
19:58:04 <Thomas[NL]> what am I doing wrong? I'm trying to replace the flat toylandtile with wolf01's; I made a png of it placed it in data/sprites/trgtr/ saved it as 19.png and added offsets with pngcodec. started openttd with ./openttd -b 32bpp-anim but tile does not get replaced.
20:01:41 <Wolf01> did you started the toyland scenario?
20:02:38 <peter1138> did you set the offsets? heh
20:02:57 <Wolf01> if i remember right, you need to replace the 57, the 19 is the "almost cleared land"
20:03:24 <Wolf01> in toyland they are all the same
20:03:48 <Thomas[NL]> that did it indeed
20:04:36 <Thomas[NL]> can someone explain what I have to measure to get the offsets?
20:05:00 <Thomas[NL]> TrueBrain used -31, 0 (x/y)
20:07:21 <Thomas[NL]> but I can't seem to get why...
20:07:47 <peter1138> top corner of the sprite probably
20:08:42 <mic> i started crashing with ingame news, is it effect of some new changes?
20:08:58 <stillunknown> Thomas[NL]: Maybe related to viewport coordinates?
20:09:29 <stillunknown> Which go from x: [-constant. constant]
20:09:38 <stillunknown> y: [0, constant2]
20:10:18 <peter1138> you want to move the top corner of the sprite to be at 0,0 in the tile
20:10:24 <peter1138> (at least for ground tiles)
20:10:35 <peter1138> that's achieved by moving it -31,0
20:11:33 <Thomas[NL]> isn't it out by 1px then?
20:12:41 <peter1138> looking at lego1.png it's not quite perfect
20:13:31 <Thomas[NL]> I'll set some extremes and see how it ends up; hopefully I'll be able to figure out that way how it works :)
20:16:09 <Thomas[NL]> ok I get it I tink
20:17:33 <stillunknown> I don't know who came up with the idea to make special effects vehicles.
20:20:42 <stillunknown> http://paste.openttd.org/122 <-- my initial effort to bring similar movement related actions into the vehicle class (no functional changes, and trains are the only one which have been split into smaller parts and have their goto's removed)
20:21:13 <stillunknown> If anyone wants to comment ;-)
20:22:44 <Wolf01> ok, how does pngcodec work then?
20:24:41 <Thomas[NL]> pngcodec <1> xx.png x_offs=xx y_offs=xx 1 = "a" to add values, "l" to list, "r" to replace & "c" to clear them all . Very simple
20:25:53 <stillunknown> Still funny to see again.
20:26:16 <Wolf01> so... seem that i tried to write pngprops as argument
20:27:13 <Thomas[NL]> yeah, also confused me at the beginning
20:28:50 <Eddi|zuHause> Wolf01: there was a similar text about the german spelling reform... that was like 10 years ago
20:29:18 <Thomas[NL]> Wolf01, how will you cut the edges of the tiles?
20:31:24 <Thomas[NL]> the flat one uses proper edges like used on ttd-tiles, but most of the others have pieces that "stick out", I don't know if that is a problem?
20:32:57 <peter1138> Thomas[NL], in theory they'll line up
20:33:30 <Wolf01> yes, i know, i made them with collage of pieces, i found that as they look good when aligned so i kept them so
20:34:43 <Chris82> hmmm does anybody else think that on large maps the industry generator creates way too many factories and steel mills?
20:34:53 *** Thomas[NL] has joined #openttd
20:35:23 <Chris82> there's one location with like 5 producing industries and at most 2 raw material industries near it
20:35:52 <eekee> Nah, it just clusters em in maps bigger than 256
20:36:05 <eekee> is there a limit on # of windows open at once? I seem to have random windows closing
20:36:50 <Chris82> yeah but there are about as many factories as farms
20:36:54 <Chris82> that's a little much :D
20:37:07 <Belugas> talking about the windows :S
20:38:50 <Biff> i remember in the old days of ttdlx, you could only have a few windows open
20:39:02 <eekee> Biff: yeah, & only after about 8 windows too. I'm sure ottd didn't used to
20:39:37 <Chris82> woah my game just crashed with a serious fault condition with 20 windows lol
20:39:41 <Chris82> just tried to test how many I can open
20:41:28 <Wolf01> the load of scenarios fail in trunk, made with the same revision
20:42:44 <Wolf01> i always forget about towns
20:44:54 <Eddi|zuHause> starting a scenario with no towns should generate random towns...
20:45:18 <Chris82> would it be easily possible to generate a 1536x1536 map?
20:45:23 <SmatZ> it should at least give some meaningful message
20:45:24 <Chris82> or does that require a lot of code change?
20:45:30 <Eddi|zuHause> maybe with a popup confirmation
20:45:44 <peter1138> Chris82, no. Lots of stuff assumes 2^
20:45:52 <Eddi|zuHause> Chris82: i don't think that'll work
20:46:50 <Chris82> hmm :( ok I thought so already
20:47:11 <Eddi|zuHause> Chris82: might be easier to create a new type of void tiles that you can spread on a 2048x2048 map
20:47:59 <Chris82> the reason I just asked is because I want ultra huge maps and my brother wants 1024x1024 on the server so I wanted to find compromise
20:48:37 <Chris82> hmmm yeah I'll do that I think ;)
20:48:43 <peter1138> i find 512x512 massive, personally
20:49:14 <Bjarni> actually the whole tile system is based on sizes of 2^n, so changing that would be a huge task
20:49:21 <Bjarni> so the void tiles are a good idea
20:50:30 <Hendikins> 2048x2048 maps are fun :P
20:50:44 * Hendikins is playing ultra-huge at the moment
20:50:53 <Bjarni> they take a while to completely cover with tracks
20:51:33 <Hendikins> I'm taking long enough to just get my main line from one end to the other
20:52:04 <Smoovious> ugh... keep getting openttd.grf and roadstops.grf corrupted or missing... using the ones off of the svn...
20:52:56 <mic> should i add new strings to objs/lang/lang/english.txt or src/lang/english.txt?
20:52:56 <Bjarni> it might find old ones after the path patch is committed if you made a poor setup
20:53:02 <Smoovious> yeah, tried 3 times...
20:53:03 <Chris82> Hendikins: Yeah that's why I like them. Such huge maps are no problem for a modern computer
20:53:18 <dihedral> Rubidium or TrueBrain around?
20:53:19 <Chris82> and there's plenty of room to try different track layouts for effiency without clumping the map in 20 game years
20:53:24 <Hendikins> Chris82: Define modern. ottd is currently having a CPU to itself.
20:53:25 <Smoovious> I deleted them out of my svn directory, and had svn replace them from the server
20:53:28 <Bjarni> mic: src/lang/english.txt
20:53:35 <Hendikins> (I'm using dual Athlon MP 2600+ CPUs)
20:54:00 <mic> thatnk. and in what place can i add and in what not?
20:56:15 <Bjarni> mic: read the comments... some places says that the order is important, so don't mess with those. Otherwise put new strings together with strings that appears to be used in similar conditions... the compiler will figure out the rest as it uses the names of the sprites to work with
20:56:45 <Kjetil> why does it compile the blitters when ./configure is given --enable-dedicated ?
20:56:55 <dihedral> still would love to know if anybody can tell me why some values are negative...
20:57:10 <peter1138> <mic> maybe unsigned?
20:57:10 <peter1138> <peter1138> integer overflows
20:57:15 <Bjarni> dihedral: maybe you mess up with 32/64 bit
20:58:10 <dihedral> if that were the case nothing else would be at it's right place
20:58:28 <Bjarni> dihedral: instead of the huge values, you should shorten it to millions and so on.... it's not important to know every single dime if the company has 50 billions and the latter is easier to read
20:58:50 <Chris82> Hendikins: With modern I meant something like a Core 2 Duo machine
20:59:03 <Bjarni> it would be funny to get overflow in map sizes though.... negative map sizes xD
20:59:09 <Chris82> You won't see CPU usage by openttd even if you have a 2048x2048 map with 2000 trains :D
20:59:10 <peter1138> Athlon MP's are obsolete, of course...
20:59:58 <Chris82> I've heard the MPs were nice CPUs, never used AMDs except for X2 and XP though
21:00:00 <eekee> Chris82: you're joking, right??? Otherwise, what planet are you on, and can I pleeeease move there & use their computers? Pretty please?
21:00:38 <Chris82> well any Pentium 4, Core 2 Duo, Pentium D, Athlon X2, Opeteron and CPUs of this kind systems are modern
21:00:45 <Bjarni> eekee: either that or he paused the game while reading CPU load
21:00:47 <Chris82> C2D was just an example :p
21:01:02 <Hendikins> ottd isn't multithreaded anyway, is it?
21:01:05 <Kjetil> any Pentium 4 ? ( early pentium 4 sucks )
21:01:15 <Bjarni> there is the background saving
21:01:29 <Bjarni> and the GUI drawing while generating the map, but apart from that
21:01:40 <Chris82> ok I admit the CPU usage is 2 percents at peak :D
21:01:43 * Hendikins should probably be running a dedicated server on localhost and connecting a client to it to chew both his CPUs.
21:01:45 <Chris82> but still that's nothing for a game
21:01:49 <eekee> Chris82: well if those are modern, then it shouldn't be unplayable with CPUs of a generation before. It does get unplayable very quickly!
21:02:20 <Chris82> I have played the original Transport Tycoon Deluxe and the first version on a 386 CPU :D
21:02:28 <Chris82> with 8 or 16 MB Ram I think
21:02:34 <Chris82> OTTD won't run with that I think
21:02:44 <Bjarni> I like the background saving... autosave really paused the game for a while before it started compressing the game in a different thread
21:02:48 <eekee> Chris82: I KNOW! Hence my astonishment at how much ottd uses. gRANTED, TURNING NPF OFF DOES HELP A LOT
21:03:17 <mic> dihedral: can you make script to accept address of server? for example ....php?server=1.2.3.4:3979 - this will let other use it :)
21:03:23 <eekee> oops, er, only part of those caps were intended :D
21:03:36 <Chris82> I think the dedicated server with 2048x2048 uses 50 MB Ram right now (without vehicles) which I just started
21:03:55 <eekee> well maybe it's ram then
21:04:13 <eekee> eh, I should shut up, haven't slept well
21:04:28 <Chris82> uhm r10264 with lots of customized patches
21:04:52 <peter1138> The raw map is 36MB at that size.
21:04:53 <eekee> interesting. Wonder what the patches do
21:05:01 * Hendikins has no problems with RAM usage by ottd, right now the 2048x2048 map with vehicles is only chewing up 76 rss
21:05:03 <peter1138> Which for modern computers isn't a lot.
21:05:26 <Chris82> I have set towns and industries to high though
21:05:46 <mic> try 0.5.2 with 100x100 station with 400 mines in it accepting range :) and try 1 train to load from that station :)
21:06:00 <Chris82> 100x100 station? isn't 64 the limit?
21:06:17 <eekee> in does say in patch config that upping the max station size slows the game
21:06:22 * Hendikins has towns and industries on high also
21:06:33 <peter1138> hmm, each town takes ~ 1KB
21:06:54 <peter1138> each industry takes ~ 52 bytes, heh
21:07:14 <Chris82> oh that's not that much
21:07:39 <peter1138> it has a few arrays in it
21:08:06 <Chris82> I think there are like 2000 towns on such a large map, that would only be 2 MB Ram
21:08:18 <peter1138> a vehicle is less than 300 bytes
21:08:28 <mic> high spread does not slow game in trunk :) i think we can remove red message "high spread slows the game"
21:08:40 <peter1138> stations are biggish too
21:08:49 <peter1138> nearly 900 bytes (heh)
21:09:02 <eekee> Chris82: Have you run ottd multiplayer & checked the cpu usage? I'm guessing that might be interesting
21:09:03 <Chris82> well I played one game a few days ago with about 60 32x32 stations and about 200 trains on that network
21:09:07 <Chris82> that worked perfectly fine
21:09:16 <SmatZ> afair, the reason why high spread caused slowdowns, was because of AI
21:09:22 <Chris82> eekee I only play multiplayer yes
21:09:33 * eekee REALLY wants to move to Chris's planet now :D
21:09:34 <Chris82> the dedicated server has 1 to 2% at most
21:09:43 <Chris82> X2 3800+ is in the server and C2D E6600 in my desktop
21:10:17 <Chris82> the slowest CPU I tried OTTD with was a P4 3 GHz I think, I didn't know it before
21:10:28 <mic> dihedral: i dont want to install scipts, i want to allow everybody just to make 1 link :)
21:10:32 <SmatZ> I tried it at PMMX 200MHz
21:10:58 <Chris82> I would love to get back a really old working machine
21:11:04 <Chris82> my 386 was soooo silent :D
21:11:09 <peter1138> i'll swap for your C2D
21:11:12 <Chris82> no fan except a really silent PSU fan
21:11:26 <Chris82> it's really hard to build a silent PC nowadays
21:11:28 <peter1138> my 386 had a chunky PSU
21:11:31 <mic> dihedral: i think it is very easy for you to read variable from _GET
21:11:33 <SmatZ> Chris82: you may underclock your CPU and turn off the fan
21:11:37 <peter1138> with mega huge loud fan
21:11:45 <Chris82> well I cool it passively actually
21:11:50 <eekee> I use it on an iBook of a night-time. It's passable, esp with npf off, & yapf for ships is better off too in my game with 10 ships, lol
21:11:57 <Chris82> but I still have 4 120mm fans in the system + PSU
21:12:15 <peter1138> Chris82, it's easier than it was a few years ago. PSUs and CPU fans *are* quieter now
21:12:16 <Chris82> people call me insane when I say my PC is loud lol
21:12:41 <Chris82> yeah those Scythe Heatsinks are really nice for passive cooling when you have 120's in your case
21:13:07 <Hendikins> My PC *is* loud, although it has nothing on the IBM server I used to have in my room
21:13:20 <Chris82> I also modded my graphics card so it's cooled with an Accelero S1, the Accelero fan cooling solution was too loud
21:13:22 <peter1138> i'm tempted to find a passively cooled graphics card, though
21:13:40 <Chris82> X1950 Pro can be passively cooled and it's fast
21:13:43 <glx> I have a passively cooled gfx card
21:13:59 <Chris82> it's really easy to take off the original fan of a card and replace it
21:14:22 <Chris82> you just need to take care of the voltage regulators because some manufactures put very sticky heatsinks on them
21:14:33 <Chris82> so you better not rip them off when changing the fan :D
21:14:50 <Chris82> I just say it because it happened to me once :(
21:14:53 <peter1138> hmm, fanless 8600GT
21:15:09 <Eddi|zuHause> <Chris82> with 8 or 16 MB Ram I think <- TTO used around 2.5 MB ram
21:15:24 <Chris82> I actually have no idea :D
21:15:39 <Eddi|zuHause> it said that in the about box
21:15:43 <Chris82> at the time I was using Original TTD and a 386 with DOS I had no idea of what RAM is lol
21:16:11 <Eddi|zuHause> you're using either Original TT or TTD...
21:16:31 <Chris82> well I was playing both anyway
21:16:36 <glx> the funny time of tweaking autoexec.bat and config.sys to have as much memory as possible
21:16:43 <Chris82> the expansion pack for Original TT was really cool :D
21:17:19 <Bjarni> computers use way too much power
21:17:23 <Chris82> 43 is pretty good isn't it?
21:17:33 <Chris82> well look at the new ATI cards, 200+ Watts that is insane
21:17:41 <Chris82> that's more than my whole comp with C2D and X1950 Pro uses lol
21:17:44 <Kjetil> DOS is/was a horrible operating system.. a lot of limitations that isn't present on *nix
21:18:42 <peter1138> gainward do a similar one
21:18:50 <Bjarni> you can get a desktop computer that uses less than 100 W with decent performance
21:19:00 <dihedral> mic: i dont want my server to be querying other games constantly :-P
21:19:40 <SpComb> a laptop probably uses less than 100W full load
21:19:42 <dihedral> mic: + i could query the master server, get a bunch of ip addresses and do some mining :-)
21:19:56 <Chris82> of course a laptop uses 20-40 Watts I think depending on its graphics card
21:20:02 <Bjarni> the computer I used when porting OTTD used 90 W when fully loaded
21:20:07 <dihedral> which client was online where for how long, performance of the company the client was playing in etc
21:20:20 <Bjarni> and that's with two HDs and stuff
21:20:42 <dihedral> and to be honest, thats my plan - just not for all server but at least for mine
21:20:48 <Chris82> the 8600GTS requires 71 Watts tho
21:21:01 <Chris82> I think that's about the same my X1950 Pro requires
21:21:03 <dihedral> logging everything to a database and building stats
21:21:14 <Chris82> the X1950 Pro has better performance but no DX10 if you want that
21:21:27 <mic> btw, how to run openttd as master server? %)
21:21:38 <peter1138> Don't give a monkeys about DX10, but ATI suck on Linux.
21:21:58 <Chris82> Oh I don't know about that, but good to know.
21:22:23 <Phazorx> this is a strange covo for this channel
21:22:38 <Chris82> maybe you should check check a used 7800GT
21:22:44 <Chris82> it has a great performance/watt ratio
21:23:32 <peter1138> hmm, where did the C2D E2140/60s come from...
21:24:09 <peter1138> power hungry, whatever it is
21:24:19 <Bjarni> some electrical heating device that can double as computer hardware
21:24:22 <Chris82> yeah but look at the price lol
21:25:00 <Chris82> I totally don't understand how someone can through out money for SLI, Crossfire and that stuff
21:25:13 <Chris82> there's no game that can't be played with a single card
21:25:20 <Kjetil> because people are stupid
21:25:26 <Chris82> despite the noise and power consumption
21:25:38 <SmatZ> when you have money for a 50" LCD, you have money for SLI
21:25:40 <peter1138> people buy C2Qs too, heh
21:25:56 <Chris82> well a C2D E6600 is only 200 Euros
21:26:02 <Chris82> awesome performance and low power consumption
21:26:12 <Chris82> ah you mean Core 2 Quad
21:26:18 <Chris82> well that is Fake Quad anyway :D
21:26:27 <peter1138> mind you, the C2D extreme is stupid money as well
21:26:28 <stillunknown> Be sure to avoid the initial revision if your run 24/7, idle usage is a bit high.
21:26:41 <Chris82> yeah just like the P4 Extremes
21:27:11 <Chris82> idle is high on the C2Ds that's true, but I run a lot of encoding and compiling stuff all day long
21:27:34 <stillunknown> They reduced idle usage on the second revision iirc.
21:27:42 <Chris82> if you really wanna be power efficient with high performance you need a X2 EE
21:28:01 <Chris82> well mine is form August last year, one of the first C2Ds
21:28:18 <Chris82> I doubt it's a revised revision
21:28:25 <stillunknown> A (not yet released) agena 2.3 ghz low power would be great.
21:28:46 <Chris82> I think I will use a mobile CPU in my next system anyway
21:28:56 <Chris82> they are powerful enough in the meantime to serve my needs :D
21:29:13 <peter1138> problem with CPUs is you can forever be waiting for the next update before upgrading
21:29:33 <Chris82> just like with anything in your PC
21:29:35 * Phazorx is sadden recalling how his barton-m fried
21:29:39 <stillunknown> I'm looking at the time period were i'll first consider upgrading.
21:29:47 <Chris82> if I waited with my RAM until now I could have 16 GB instead of 2 GB :D haha
21:29:56 <Chris82> DDR2 prices dropped insanely
21:30:00 <stillunknown> Which is H1 2009.
21:31:38 <stillunknown> No, they don't make netburst based cpu's anymore.
21:32:00 <peter1138> Intel Core 2 Duo E2140, Socket 775, 1.6 GHz, 800MHz FSB, Conroe Core, 2x 512KB Cache, Retail
21:32:05 <Kjetil> They have returned to P6 cpus :P
21:32:42 <peter1138> maybe it's just the celeron of the C2D world, heh
21:32:49 <dihedral> Bjarni: i agree with shortening values, though before i would like to see the propper value :-)
21:32:56 <peter1138> the E4300 was supposed to be the cut down version though
21:33:15 <Chris82> what I am wondering is why the E6750 is cheaper than the E6600
21:33:51 <peter1138> there's an E6750? hmm
21:34:01 *** xBRMxJamie has joined #openttd
21:34:18 <Chris82> 2.67 GHZ as well but higher FSB
21:34:25 <stillunknown> I'd wish intel made mid range dedicated video cards.
21:34:47 <Chris82> the Q35 chipset will have a DX10 card
21:34:53 <xBRMxJamie> is there a version of 0.5.2 for PPC?
21:35:03 <stillunknown> Their linux driver support is great, and i could pair it with an amd cpu if i wanted to.
21:36:04 <xBRMxJamie> is there a version of 0.5.2 for PPC?
21:36:42 <Chris82> a great feature would be an onboard graphics card combined with a dedicated card
21:36:54 <Chris82> whenever I run 3D games the dedicated card runs and otherwise the onboard card
21:37:18 <SmatZ> something like old voodoo cards did
21:37:25 <Chris82> that should be a big potential for saving energy and reducing heat generation dramatically in the case
21:38:04 <Chris82> hehe Carmageddon time :D
21:38:15 <Chris82> I always need to think of that game in combination with Voodo Gfx
21:39:11 <peter1138> and works well using a voodoo emulator iirc
21:39:17 <Rubidium> xBRMxJamie: if you mean PPC MacOSX then yes, otherwise not officially (don't know about unofficially)
21:39:45 <xBRMxJamie> any one know if there is a newer version then 0.5.0 for pocket pc?
21:40:13 <xBRMxJamie> soz ty for awnsering
21:40:16 <SmatZ> xBRMxJamie: ottd for pocket pc is not developed here
21:40:17 <Chris82> peter1138: Yep it does, even on Vista :D
21:58:08 *** Nickman has joined #openttd
22:08:56 <Bjarni> now that looks a bit more readable
22:09:12 <Bjarni> life ain't fair, so you picked poor server names :P
22:14:09 * Hendikins runs pax end to end by train on a 2048x2048 map because he can
22:15:17 <mic> dihedral: dont you think they overflood over int32?
22:15:37 <dihedral> yeah - rubidium just said so too...
22:16:00 <dihedral> as the issue must clearly be on the php side :-) guess what i am looking into :-P
22:16:14 <Rubidium> even though it doesn't "look" like it at first hand (it has values out of the int32 range), but that's because of the exchange rate correction from pound -> euro
22:18:32 <peter1138> oh, dihedral is listening now?
22:19:28 <dihedral> peter1138: yes, well, nearly started to :-P
22:19:31 *** Progman has joined #openttd
22:20:13 <dihedral> when 64 bit handling was mentioned i at first thought of reading out of the packet... clearly my bad
22:20:44 <mic> dihedral: try to read higher part into float, multiply by 2^32 and add lower part
22:22:42 <Eddi|zuHause> wtf? float? don't you have real int64?
22:24:53 <mic> size of int in php is "impl-dep" :) likely to be 32bits on such platform ) so no 64 bit int
22:27:59 *** Vikthor has joined #openttd
22:32:41 <Phazorx> sorry was busy before
22:41:05 <mic> i configured openttd with CFLAGS=-ggdb but gdb says "(no debugging symbols found)", what may be wrong?
22:41:49 <Rubidium> ./configure --enable-debug=1 is much easier
22:42:04 <Rubidium> assuming you use trunk
22:53:08 *** Smoky555 has joined #openttd
23:11:55 *** Sacro|Laptop has joined #openttd
23:23:39 *** Chris82 has joined #openttd
23:23:46 *** NukeBuster has left #openttd
23:23:47 <Chris82> hi, anybody still awake?
23:23:56 <Chris82> I'd like to know how the game determines when a train is lost
23:24:09 <Chris82> because I get lots of train is lost messages on trains which are definitly not lost
23:24:22 <Phazorx> what PF are you using?
23:24:54 <Rubidium> IIRC if it has taken more than X days before the train reached it's destination
23:25:16 <Phazorx> Rubidium: NTP and NPF are limitted in range
23:25:31 <Phazorx> on 2048 map they can get lost easily
23:26:10 <Phazorx> last time i played 2048x128 they were getting lost with YAPF
23:26:18 <Rubidium> NPF isn't limited in range
23:26:20 <Phazorx> but that was due to overly high score most liekly
23:27:03 <Phazorx> well igf it is not limitted i do not understand why 10 times mroe trains are getting lost if i replace yapf by npf
23:33:40 <Chris82> I am using all the new pathfinding stuff
23:33:56 <Chris82> and although I am playing a 1024x2048 map right now the tracks aren't very long
23:34:56 <dihedral> Rubidium: a uint64 = uint32 + uint32 << 32 ??
23:35:26 <Phazorx> Chris82: re: which PF are you using?
23:35:37 *** bencvt is now known as benc_
23:35:42 <dihedral> when assining a high value directly to a variable i have no issues at all...
23:36:18 <Rubidium> then it probably casts it to float or something similar
23:36:44 <dihedral> i tried casting everything that i touched to a float!
23:38:26 <Phazorx> Chris82: are train that getting lost coast to coast along 2048?
23:39:41 <Chris82> they have full load, but it's not like they would wait very long to be fully loaded
23:41:07 <Chris82> is it hard coded somewhere how many days with no destination reached are considered lost?
23:41:10 <Phazorx> can you trace the lost train on full route?
23:41:28 <Phazorx> Chris82: i dont believe that applies to yapf
23:41:54 <Phazorx> yapf has 2 limitations which are determining whether train is lodt or not
23:41:54 <Rubidium> Chris82: just give us a link to the savegame, otherwise we'll keep on guessing
23:42:00 <Phazorx> overly high score and lack of route
23:42:38 <dihedral> and continue the joy tomorrow :-)
23:43:03 <dihedral> thanks for your help Rubidium , really appreciate it
23:43:08 <Chris82> I'll upload a save later shortly after a lost message occurs again
23:43:26 <Rubidium> well, rather before the lost message occurs ;)
23:43:32 <benc_> wouldnt it be better if you got a save right *before* the message? :)
23:43:37 <Phazorx> is message history pasrt of save?
23:43:56 <Rubidium> no, never has been, probably never will be
23:43:56 <benc_> hard to go backwards on the complex turing machine that is openttd;)
23:46:38 <Phazorx> Rubidium: just asking before comfirming that *after* would be completely useless
23:47:40 <Rubidium> benc_: I'd rather say impossible
23:47:42 <Chris82> hmmm I try to find a reproducable way
23:48:00 <Chris82> because it just happens randomly with different trains, I haven't found a way to reproduce it myself yet
23:48:19 <Chris82> so that makes it difficult to save before
23:49:09 <Phazorx> Chris82: can you grop the trains somehow
23:49:22 <Phazorx> and do you have one big network or many small routes?
23:51:07 <Chris82> very complicated layouts with many signals
23:51:27 <Phazorx> Chris82: combined networks or independant?
23:52:23 <Phazorx> cuz where i seen that with yapf were on 4 lanes of mainline 4000 tiles long with 1000 trains on it
23:52:27 <Chris82> you mean with different types of goods with combined?
23:52:29 <Chris82> then they are combined
23:52:36 <Phazorx> Chris82: i mean actualy connecting tracks
23:52:56 <Chris82> no there are no junctions
23:53:22 <Phazorx> so there are independant pieces of tracks, not lengthy, but trains are getting lost ?
23:54:04 <Phazorx> can you confirm that both targets of any particualr lost train are within same network (AKA connecting tracks of same type w/o interuptions)?
23:54:18 <Phazorx> replace both with all in case if your trains arent ptp
23:54:36 <Chris82> at this station I had a few lost trains before
23:55:42 <Chris82> but there's nothing wrong with the layout, the trains all go the right track
23:56:22 <Rubidium> well, I'm not so sure about that statement
23:56:50 <Rubidium> I myself have never had rogue lost train warnings
23:57:02 <Chris82> I didn't get a lost message for quite a while yet as well
23:57:09 <Phazorx> can you fit train schedule, both, all station windows and map of path in same screeny ?
23:57:11 <Chris82> I'll raise my finger if it occurs again :D
23:57:23 <Phazorx> Chris82: you can check mesage hystory
23:57:28 <Phazorx> and see lost trains therer
23:57:40 <Phazorx> it would be very good if there one reoccuring
23:57:42 <Chris82> difficult only my server, not my company
23:57:57 <Chris82> but when it reoccurs I'll ask my bro to do a screenie
23:58:06 <Phazorx> message hystory is available no matter if it is client or server
23:58:13 <Rubidium> screenies are absolutely useless.
23:58:28 <Phazorx> Rubidium: i want to see if station are on same networks actualy
23:59:00 <Rubidium> well, there are all kinds of causes for trains to go lost
23:59:09 <Chris82> well it's one big steel mill station he built there and lots of iron ore stations all connected to this steel mill station
23:59:22 <Rubidium> but it has almost always been bad network design and not an OTTD bug
23:59:35 <Chris82> and I have checked his network very closely couldn't find any ghost trains or wrong signals
23:59:45 <Rubidium> and lots of depots all over the place at less than 16 tiles from junctions...
23:59:47 <Chris82> I agree with that Rubidium
23:59:57 <Chris82> I never get the lost messages on my networks, but still his layouts look fine to me
23:59:59 <Phazorx> Chris82: in message hystora are ther reoccuring lost train message?
continue to next day ⏵
