IRC logs for #openttd on OFTC at 2007-07-03
⏴ go to previous day
00:13:04 *** ThePizzaKing has joined #openttd
00:18:41 *** NukeBuster has left #openttd
00:38:39 <_Ben_> hi, does anybody know where to find the sprites for the streetlamps? If not I'll trawl through the pcx files, but any hint would save me some time
00:44:27 <Eddi|zuHause> maybe table/road_land.h can give you hints?
00:51:15 <Sacro> 00266 _roadside_lamps,?
00:52:14 <_Ben_> yep, I was looking for where the sprites are found, in wich graphic file, and what number
00:52:43 <_Ben_> No worries, I'm just gunna look through and find it. I was just seeing if anyone new already, and could save me some time
01:20:19 *** Frostregen_ has joined #openttd
01:25:58 *** Frostregen_ is now known as Frostregen
01:30:52 *** Eddi|zuHause2 has joined #openttd
01:31:22 *** Digitalfox has joined #openttd
03:15:05 *** Gekkko` has joined #openttd
04:15:45 *** Osai^zZz has joined #openttd
04:53:27 *** KUDr_afk has joined #openttd
05:46:21 *** Osai^zZz is now known as Osai
05:48:24 *** Taikaponi has joined #openttd
06:13:19 *** wolfy is now known as Wolfensteijn
06:26:04 *** Taikaponi has joined #openttd
07:07:27 *** Maedhros has joined #openttd
08:15:41 *** egladil has joined #openttd
08:21:32 *** iPandaMojo has joined #openttd
08:33:23 *** tokai|ni has joined #openttd
08:40:07 *** Vikthor has joined #openttd
08:40:32 <dihedral> google is indexing my savegames :-D
08:41:53 <Smoovious> you should set up a robots.txt file in your top level directory
08:44:03 *** iPandaMojo has joined #openttd
08:47:39 <dihedral> Smoovious: about to do so!
09:05:41 *** XeryusTC has joined #openttd
09:40:54 *** setrodox has joined #openttd
10:20:57 *** raimar2 has joined #openttd
10:24:42 *** skidd13 has joined #openttd
10:25:21 *** raimar3 has joined #openttd
10:55:16 <DorpsGek> dihedral: Chris82 was last seen in #openttd 1 day, 22 hours, 2 minutes, and 39 seconds ago: <Chris82> thx
11:00:29 *** Nickman has joined #openttd
11:10:49 *** iPandaMojo_ has joined #openttd
11:24:15 *** DNazarov has joined #openttd
11:31:50 <CIA-1> OpenTTD: peter1138 * r10412 /trunk/src/ (6 files in 2 dirs): -Codechange: Remove unnecessary inclusion of hal.h in various files (and add one)
11:33:06 <stillunknown> peter1138: i have something interesting
11:33:53 <peter1138> cool, but show that to your lady
11:34:06 <stillunknown> Remember that 1000 maglev train savegame i told you about, i managed to shave off 10% cpu usage (65% to 55%).
11:35:09 <stillunknown> i did "cheat" a bit, by enlarging the map array to store some more data, so if i undo that i'll probably loose a bit again.
11:35:43 *** Frostregen_ has joined #openttd
11:35:57 <stillunknown> tile slope, min_z, max_z
11:36:06 <stillunknown> 9 bits to be precise
11:37:20 <stillunknown> But after i did that i found pretty large bottlenecks, so i can't predict the exact consequence of undoing that.
11:37:20 <peter1138> saves looking up the height of 4 tiles to find it, i guess
11:37:37 <peter1138> although that shouldn't be very slow
11:38:04 <stillunknown> GetTileSlope takes a few perfect of the cpu usage.
11:38:18 <stillunknown> But as i said, after that i found this was not the only issue.
11:39:36 <peter1138> well at some point we may store the slope in the tile, which takes 5 bits
11:40:11 <stillunknown> Are you at work?
11:42:22 *** Frostregen_ is now known as Frostregen
11:42:30 <stillunknown> peter1138: you know what
11:42:42 <stillunknown> what's embarrassing now?
11:42:59 <stillunknown> The acceleration function taking 9% cpu :-(
11:43:14 <peter1138> well there'll always be something hogging cpu :)
11:43:27 <stillunknown> But it's a lot for something like that.
11:44:23 <stillunknown> But i won't turn a mega patch into a even more large patch.
11:44:25 <peter1138> it loops the train a couple of times, iirc
11:45:05 <stillunknown> Although i'm glad that the last speed ups were gained by simplifying the code.
11:45:36 <peter1138> train_cmd.cpp:380 & 382
11:45:59 <peter1138> i wonder if removing * 60 and doing it once after the loop would help
11:48:07 <stillunknown> peter1138: Soon i will need advice how to cut up my patch, because most people do not fancy a 120 KB patch, are you the right person to ask?
11:51:37 <stillunknown> And then it's silent ;-)
11:56:28 <stillunknown> Phazorx: I have good news, i managed to reduce cpu usage on the SML_testcase.
11:56:46 <stillunknown> I do have to undo one cache(not sure if that'll have a huge effect) (in the map), but currently i got 65% ->55%
11:56:53 <peter1138> by turning off the blitter :D
11:57:17 <Phazorx> stillunknown: that's nice
11:57:29 <stillunknown> They were done with the debug blitter in a quiet place.
11:57:46 <Phazorx> that's the way to test it
11:58:06 <stillunknown> As usual the improvement was biggest with EvsL.
11:58:58 <stillunknown> But SML was a challange.
11:59:32 <Phazorx> msut say current challange are desyncs on our servers
11:59:46 <stillunknown> I don't do network stuff ;-)
12:00:25 <Phazorx> since now we got it happening everywhere, even with "assumed to be stable" releases
12:02:12 <stillunknown> Phazorx: I can't help in that area.
12:03:12 <peter1138> ps, nightlies ARE NOT RELEASES
12:03:50 <Phazorx> stillunknown: well your effort will be appreciated or sure
12:04:14 <stillunknown> Took me a lot of time to get the hang of it and produce efficient and working code.
12:04:27 <stillunknown> On functions that get called so often.
12:05:04 <Phazorx> assuming we can get to the point where these improvements will be measurable and will matter
12:05:17 <Phazorx> stillunknown: optimization is ever going process :)
12:05:25 <Eddi|zuHause2> if functions are called really often, inlining might help a great deal
12:05:42 <caladan> Not much if they are big...
12:05:42 <Phazorx> both on rail network layout and on code level...
12:06:00 <stillunknown> You get increased cache misses if you do that.
12:06:10 <dihedral> out of curiosity: what was Ev's problem (regarding his slopes patch)
12:06:16 <Eddi|zuHause2> a) you save the function call overhead
12:06:27 <Eddi|zuHause2> b) you allow the compiler to do much more optimisation
12:07:50 <Eddi|zuHause2> dihedral: his patch got rejected, and he threw a hissy fit...
12:08:31 <stillunknown> Eddi|zuHause2: i have inlined some things, even replaced some functions, like GetTileZ with more efficient version based on information i already had
12:08:51 <stillunknown> I did read up on what could be done ;-)
12:10:07 <dihedral> Eddi|zuHause2: and you want to tell me that that was all that's to it?
12:10:15 <dihedral> i was trying to read the forum thread
12:10:32 <dihedral> though him having deleted all his posts (appart of a single one)
12:10:40 <dihedral> makes it hard to follow the entire thing
12:12:19 *** Nickman is now known as Nickman^Away
12:12:36 <dihedral> Eddi|zuHause2: was there some other reason for the reject appart from the coding style?
12:12:51 <stillunknown> The coding style was the main reason i think.
12:12:56 <Eddi|zuHause2> something about massive use of macros
12:13:14 <dihedral> yeah - i recall seeing those wild discussion here
12:13:28 <dihedral> but i did not want to believe that would make anybody that upset
12:14:19 <_42_> dihedral, Ev (~chatzilla@213.141.137.47) was last seen quitting #openttd 6 days 22 minutes ago (27.06. 11:51) stating "Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007031001]" after spending 1 hour 1 minute there.
12:16:52 <dihedral> i did think that the feature looked somewhat interesting :-P
12:17:23 <stillunknown> strange, error: overloaded function with no contextual type information
12:17:34 <stillunknown> anyone ever seen that, without actually overloading a function?
12:22:15 <stillunknown> stupid error, user error that is ;-)
12:22:47 <Eddi|zuHause2> probably different declaration and definitions?
12:23:14 <stillunknown> I used an invalid variable inside the function.
12:23:36 <stillunknown> Which for some reason was not being treated normally.
12:26:40 <Eddi|zuHause2> C(++) is a bad language anyway...
12:26:45 *** Progman has joined #openttd
12:27:45 <Maedhros> C is a very good language for what it's designed for
12:28:47 <Maedhros> C++ on the other hand seems to incite wildly different opinions in people
12:29:23 <Eddi|zuHause2> the problem is that C is almost never used for what it is designed for
12:29:34 <caladan> imagine OpenTTD written in Java :P
12:29:38 <Eddi|zuHause2> or by people that do not even know what it is designed for
12:32:34 <Ailure> A TTD game like game would run fine in Java
12:33:34 <stillunknown> Ailure: You always have to pay a performance penalty with java.
12:34:14 <Ailure> Java VM have a bit of a tendancy to reserve too much memory however
12:34:38 <hylje> id rather rewrite TTD to python
12:34:40 <Ailure> But there's utilities for devolopers that can prevent that now apparently
12:34:58 <stillunknown> Either everyone writes poor java or i just haven't seen an app that works as well/fast as a C or C++ equivilant.
12:35:03 <Ailure> Not that I advocate a rewrite of openTTD
12:35:29 <Ailure> Look it up about Java perfomance on Wikipedia or something
12:35:34 <stillunknown> I personally (user perspective) hate java.
12:35:59 <caladan> i do too, it almost never works as it should...
12:36:03 <Ailure> In one case, a java program actually ran faster than it/s c++ equilant
12:36:44 <stillunknown> Then the c++ equivilant was poorly written or never optimized.
12:36:48 <Ailure> That was in some 3D game
12:36:54 <caladan> and the VM was already loaded :P
12:37:44 <Ailure> Besides Java had some quite perfomance boosts with version 1.6
12:38:27 <iPandaMojo_> Personally, I find it simpler to just hate all programming languages.
12:38:50 <iPandaMojo_> I hate C++ the most, probably mostly by virtue of knowing it the best.
12:39:00 <Ailure> or to write in plain machine code
12:39:01 <caladan> i'm against java, cause I mostly program uCs :D
12:39:35 <caladan> like 16kB RAM, 64kB program memory :D
12:39:41 <iPandaMojo_> (Well, okay, that's a lie, I hate C the most for all the things it screwed up about C++, but I like to try to pretend C doesn't even exist)
12:40:14 <stillunknown> Watch your language in here, they may be children here ;-)
12:40:39 <iPandaMojo_> Sorry, I'll stop saying C ;-)
12:41:20 <Ailure> on a system with like what
12:41:21 <caladan> hmm, its 8bit, isnt it?
12:41:45 <stillunknown> I kind of like C and C++, because it's used a lot, works well if you know what you're doing and it's the only two languages i know reasonably well.
12:41:58 <caladan> hehe, the example I gave is Atmel's ARM7, so it's even 32bit.
12:42:13 <caladan> Thou now i use MSP430 family, 8kB flash and 256B RAM
12:43:31 <caladan> it's simple, small thing
12:43:37 <Maedhros> what do you use something like that for?
12:44:15 <caladan> hmmm, like data aquisition, RTCs, timers...
12:44:32 <caladan> now it's device that will controll fish tank :D
12:44:52 <caladan> with temperature sensors, heaters, food feeder, lights, pH meter
12:45:02 <stillunknown> These things must be dirt cheap, otherwise you wouldn't use them.
12:47:12 <stillunknown> peter1138: the price for z calculation was pretty low
12:47:12 *** Brianetta has joined #openttd
13:06:20 *** peter1138 has joined #openttd
13:06:20 *** ChanServ sets mode: +o peter1138
13:14:26 *** Jezral is now known as TinoDidriksen
13:14:29 *** Chris82 has joined #openttd
13:16:22 <Chris82> I noticed some strange behaviour, I had this game running over night
13:16:42 <Chris82> it's at 23xx something now but all AI player obviously went bankrupt over night and dissapeared
13:16:51 <Brianetta> You might need to be patient for a reply
13:16:55 <Chris82> I don't understand why because their profit was fine
13:17:03 <Chris82> no problem it's not urgent :)
13:17:51 <Chris82> I just wanted to point out that there might be an overflow problem with AIs balance, I can't explain it otherwise
13:21:19 <Chris82> my own balance is a few trillion if I read the number correctly
13:25:19 <peter1138> as 9,223,372,036,854,775,808 is the max, a few trillion is quite close
13:25:27 <Maedhros> bah. there goes my one and only oil well...
13:30:11 <Phazorx> hmm... how can i use gdb to bebug stallfreeze rather thana crash?
13:31:47 * dihedral slaps Chris82 (as a way of saying 'hello')
13:45:21 <Phazorx> peter1138: ^c just quits the program
13:45:28 <Phazorx> i want the stack trace
13:46:57 <Phazorx> i get make: *** [run-gdb] Interrupt
13:48:54 *** AntB_ is now known as AntBUK
13:51:02 <peter1138> Program received signal SIGINT, Interrupt.
13:51:02 <peter1138> [Switching to Thread 1079363712 (LWP 8134)]
13:51:02 <peter1138> 0xffffe410 in __kernel_vsyscall ()
13:51:26 <peter1138> i use cgdb usually anyway
13:53:11 <Phazorx> perhaps mingw is the issue somehow
13:53:39 *** AntBUK is now known as AntB
14:01:48 *** Sacro|Laptop has joined #openttd
14:04:53 <stillunknown> peter1138: you were right, the price for z calculation was pretty low
14:06:12 <Phazorx> this suxx... i wanted to figure out that TTRS issue :(
14:10:18 <Maedhros> Phazorx: which TTRS issue was that?
14:10:41 <Phazorx> Maedhros: premade map with added ttrs freezes at certain date
14:11:50 <Maedhros> hmm, i haven't heard about that one
14:12:53 <stillunknown> Phazorx: What kind of timeframe?
14:13:03 <stillunknown> In terms on gameyears.
14:13:18 <Phazorx> scenari starts at 1939 jan 1
14:13:42 <stillunknown> Could you upload it somewere?
14:14:33 <stillunknown> Upload it somewere ;-)
14:14:37 <Maedhros> please upload it, so i can have a look too :)
14:16:31 <Phazorx> i had few revisions so i tested it wit 295, 300, 343, 401
14:16:44 <Phazorx> behavior is identical as i recall
14:16:55 <Phazorx> and problem goes away as soon as ttrs is removed
14:17:34 <Phazorx> i was thinking it is my ttrs options - but if they are changed it goes on a bit longer but still freezes within a year
14:18:40 <Phazorx> and yes, i know, coopers find most weird issues all the time... but this is a blank map for one
14:22:48 <stillunknown> Phazorx: what version of ttrs do you have?
14:23:36 <Phazorx> along with rest of GRFs it is a part of cooperd grf pack 5, need url?
14:25:43 <Phazorx> you can not reproduce the issue?
14:26:18 <Phazorx> Maedhros: few people confirmed that already
14:26:29 <Phazorx> 1st time we saw it on server when 4-5 were connected
14:26:36 <Phazorx> all froze at same time independantly
14:26:53 <Maedhros> it's happening when trying to build a newgrf house at tile 319921
14:26:54 <Phazorx> server is on linux as well as 2 users were
14:26:59 <Maedhros> but i have no idea why at the moment
14:27:20 <Phazorx> Maedhros: settings are forcing it to replace all standard houses by trrs btw
14:28:50 <stillunknown> Despite not seeing any of the familiar ttrs3 buildings, it did go into what seems to be an infinite loop.
14:29:09 <Phazorx> stillunknown: map is made w/o ttrs as i mentioned
14:29:31 <stillunknown> But i forgot to enable debug level 3, so i need to recompile.
14:30:44 <Phazorx> Maedhros: if i get the loco correctly it's water north of sicily
14:32:41 <stillunknown> House callback 23 is the problem.
14:32:48 <stillunknown> If i only knew what that was ;-)
14:33:33 <stillunknown> Phazorx: tile depends on map size
14:34:06 <Phazorx> map is 1024x1024 kinda easy to count
14:34:07 <Maedhros> callbacks are specified in hex, so this is callback 17 (whether a house can be built here)
14:34:07 *** NukeBuster has joined #openttd
14:34:51 <Sacro> OpenTTD needs to be able to load grfs from ~/.openttd/data
14:35:04 <Sacro> so i don't have to sudo and put them in /usr/share/openttd/data
14:36:05 <Phazorx> configurable path would be nice tho
14:36:07 <Maedhros> it can. if you're compiling it yourself though you may have to run ./configure manually
14:36:27 <Sacro> Phazorx: mmm, a simlink might work
14:36:30 <stillunknown> Phazorx: x=625, y=304
14:36:40 <Sacro> Maedhros: i'm the one who wrote the ArchLinux PKGBUILD :)
14:36:50 *** peter1138 has joined #openttd
14:36:50 *** ChanServ sets mode: +o peter1138
14:37:05 <Sacro> i have 2, one that works with the old makefile for stables, and another for -svn
14:37:39 <Phazorx> stillunknown: still water
14:37:44 * Sacro puts peter1138 on a train to a forest
14:38:11 <Phazorx> unless i got coordinates wrong again
14:38:23 <stillunknown> Phazorx: i hope you didn't count the tiles?
14:38:39 <Phazorx> X axis is E-W, top right to bottom left
14:38:44 <Phazorx> stillunknown: of cource i did
14:38:51 <peter1138> Sacro: it *does* read grfs from ~/.openttd/data...
14:39:19 <peter1138> well, the nightlies anyway
14:39:35 <Sacro> i'll shove em in ~/.openttd-svn/data and see what happens
14:40:44 <Phazorx> Brianetta: AP under activetcl kinda borks here
14:40:54 <Phazorx> fails to read the config for some reason
14:41:24 <Brianetta> It works on most people's setup
14:41:37 <Phazorx> is location of [autopilot] sectiopn in ini file matters?
14:41:37 <Brianetta> Is your config file called openttd.cfg?
14:41:39 <Sacro> haha, someones done a mortified icon
14:41:43 <Maedhros> Phazorx: x = 433, y = 312, but just use scrollto 319921
14:41:57 <Brianetta> but there should only be one [autopilot] section
14:42:23 <Brianetta> although I'm not sure what the consequences of more than one are. It might work, but I haven't tested it.
14:43:02 <Brianetta> The entire config file is read into a namespace, with a list named after the [section] containing pairs of keys and values
14:43:24 <Brianetta> There's a get_setting function and an is_set function to query it
14:43:40 <Brianetta> is_set returns true if get_setting returns 1, yes or on
14:44:14 <Sacro> Brianetta: a train/lawnmower... that'd be cool
14:44:24 <Brianetta> Sacro: Wouldn't it just?
14:44:39 <Brianetta> It could be fited with hedge clippers at track level
14:44:59 <Brianetta> or a set of spinning chainsaws if the saplings had really taken root
14:45:32 <Sacro> i can see health and safety having a few issues though
14:45:42 <Brianetta> Not if it's painted orange
14:45:59 <Brianetta> It'd be no more dangerous than being hit by a regular train
14:46:55 <Phazorx> perhaps i am not getting it correctly but it looks that it tries to find the sections
14:49:24 <Chris82> is there a variable for the price of a signal?
14:49:53 <Chris82> 146 is the initial price but it'll with inflation change so I can't use 146 for what I want to do
14:50:19 <Chris82> sl: change sr: with inflation
14:52:41 <Maedhros> Chris82: _price.build_signals
14:55:10 <Chris82> ok, can I post a few lines of source code here for a question?
14:56:04 <Maedhros> better to use paste.openttd.org :)
14:56:05 *** Digitalfox has joined #openttd
14:56:49 <Chris82> ok so I programmed this bit
14:57:08 <Chris82> the problem was that I was able to build infinite signals with Signal GUI/Autocomplete even with no money
14:57:20 <stillunknown> With the overhauled train controller.
14:57:28 <Chris82> this check I added there will now disallow to build signals if there is no money
14:57:51 <Chris82> but the problem is that return total_cost; only returns the current price of 1 signal and not the price of all the signals that couldn't be build
14:58:18 <Chris82> I want it to return the price of the whole action that couldn't be completed though
14:58:21 <Chris82> any idea what I need to change?
15:00:23 <Maedhros> Chris82: hmm. please could you pastebin the entire function?
15:05:21 <Belugas> Chris82, one possiblity : perform your loop twice, one for counting how many signals will be required, and another one for actually doing it, it the money is there for construction
15:06:38 <Belugas> so if not enough money, you can tell the user, then
15:06:43 <peter1138> it's already done twice
15:06:46 <peter1138> that's what commands do
15:06:54 <Maedhros> Chris82: you seem to be using ret before assigning anything to it
15:07:38 * Belugas shuts up and resumes work@work
15:07:38 <Chris82> so I should put the money check after the /* only build/remove signals with the specified density */ part?
15:08:37 <Maedhros> put it after the ret = DoCommand(...);
15:08:49 <Maedhros> and i don't think you need to check flags & DC_EXEC at all
15:09:10 <peter1138> looks to me that function totally ignores the usual way of cost checking
15:09:16 <peter1138> what's this "return total_cost" in the middle?
15:09:20 <Chris82> well that's the problem I had, if I don't do it at all, it will allow me to build 100 signals even if I only have 500 cash
15:09:39 <Maedhros> peter1138: i suspect it's based off CmdLevelLand
15:09:49 <Chris82> most of the source I posted there is current trunk code
15:10:03 <Chris82> except the money check and the if (HASBIT... part pretty much at the end
15:10:09 <Chris82> which is from Signal Auto Complete
15:10:39 <Chris82> in trunk it won't let me build too many signals, but for some reason with auto complete patched in (even if it is disabled!) it allows me to build too many signals
15:10:43 <Chris82> I don't really get it
15:11:01 <peter1138> the return total_cost stuff isn't in trunk...
15:12:10 <peter1138> what does CompleteAutoSignals() do ?
15:12:43 <Chris82> CompleteAutoSignals places signals automatically instead of dragging over the whole track
15:12:57 <peter1138> wow, that's horrible
15:13:00 <Chris82> the auto placing works perfectly except for this money bug
15:13:39 <Chris82> i.e. when I have a 200 tile long track instead of dragging 200 tiles I can just drag 2 tiles and the signals will completed automatically the way I built the first signal
15:13:52 <Chris82> it stops at junctions so tracks will never get messy
15:14:08 <peter1138> that's really the wrong way of doing it
15:14:16 <stillunknown> There's a difference between it works and pretty :-)
15:14:38 <Chris82> hehe yeah I don't know if the code is pretty, but it works :p
15:15:35 *** KUDr_afk is now known as KUDr
15:16:55 <DorpsGek> Sacro: Smoovious was last seen in #openttd 6 hours, 28 minutes, and 54 seconds ago: <Smoovious> :)
15:17:27 <peter1138> this function shouldn't need to mess around with additional cost estimation at all
15:17:46 <Chris82> I don't understand why it does either, I only modified it to work at all with current trunk
15:17:49 <Chris82> it's a pretty old patch
15:18:08 * peter1138 ponders doing a correct version
15:18:22 <Chris82> looks like rewrite instead of update :D
15:19:17 <Sacro> there appears to be a problem with tramtrkw.grf
15:19:53 <Maedhros> sounds like you overwrote it with something else
15:20:31 <Chris82> the patch is a combination of Singal GUI and Signal Autocomplete, maybe something got messed up there
15:20:44 <Chris82> I should just start from scratch I guess instead of adding stuff that shouldn't be necessary
15:21:41 <Chris82> damn I need a bigger monitor, this scrolling around in source code is really bad :D
15:22:09 *** skidd13 has joined #openttd
15:25:13 <CIA-1> OpenTTD: glx * r10413 /trunk/src/town_cmd.cpp: -Fix r10211: t->townnamegrfid was not cleared when renaming a town
15:25:30 <Phazorx> Brianetta: i found the problem, has nothing to do with AP
15:26:23 <dihedral> what res you running on Chris82
15:27:15 <Chris82> I probably get a second monitor soon that should help a lot when programming
15:27:28 <dihedral> virtual desktops :-D
15:28:45 * stillunknown mumbles something about tiling window managers, and keyboard driven wm's
15:28:53 <NukeBuster> yeah, gotta love them.... :D already have 8 now :P
15:29:53 <Chris82> well virtual desktops and stuff don't help really, the space I see at once is still the same
15:30:17 <NukeBuster> well... then you should get your res up :)
15:30:21 *** Vikthor has joined #openttd
15:30:21 <Chris82> I don't really know what I should need a VD for, I can as well switch Windows, there's no big difference imho
15:30:38 <NukeBuster> i'm now at 3200x1200
15:30:39 <Brianetta> Phazorx: That was my initial thought, but I gradually got persuaded by the stream of bug reports
15:30:51 <Chris82> yeah well but you can't view the 3200x1200 at once
15:30:57 <Chris82> but that's exactly what would help
15:31:09 <NukeBuster> well.... actually i can :D
15:31:22 <Chris82> then it's no virtual desktop
15:31:29 <Chris82> virtual implies not really that big
15:31:40 <Chris82> extended implies really that big => so extended desktop :D
15:33:13 <Phazorx> Brianetta: "players" crashes server, weas fixed recently tho
15:33:33 <Brianetta> well, that's interesting
15:33:47 <Brianetta> Unfortunately, there's no way to disable that in autopilot (:
15:33:58 <Brianetta> It's kind of a pivotal command
15:37:23 <Phazorx> i understand that... but it took a while to trace it...
15:37:37 * Phazorx wants more verbosty from AP
15:38:13 <Sacro> on a network game, we have just had both OSX players desync together
15:39:32 <Chris82> lol I just tried the Signal Auto Complete patch from r5435 and it doesn't have the bug =/
15:39:55 <Chris82> well then I guess something went bogus during the conversion to r10xxx
15:41:33 *** Hendikins has joined #openttd
15:42:50 *** Thomas[NL] has joined #openttd
15:49:18 <orudge> it seems the Mac version of the latest nightly has some nice desync errors in multiplayer
15:49:22 <orudge> the Windows version doesn't appear to have
15:49:36 <Osai> it must be something deeper
15:49:52 <Osai> because other persons have desyncs too
15:50:02 <orudge> we have two MAc players and three Windows
15:50:05 <orudge> the two Macs die at the same time
15:50:53 <Phazorx> heh this is new static grfs are loaded in dedicated mode?
15:51:37 <orudge> er, tis using a variety of grfs
15:51:42 <Rubidium> as you might've been told: dedicated mode is just a normal client without the actual GUI drawing
15:51:42 <orudge> it's the tt-forums server on servers.openttd.org
15:52:03 <peter1138> orudge: you trying getting our mac developer to debug anything :P
15:52:22 <Phazorx> Rubidium: i kinda assumed eyecandy static GRFS are not very usefull in dedicated mode with no renderer
15:53:19 <Rubidium> Phazorx: making the dedicated mode more different than the non-dedicated mode makes it easier to introduce bugs
15:53:36 <_42_> Sacro, Bjarni (~Bjarni@0x50c79adc.virnxx14.adsl-dhcp.tele.dk) was last seen quitting #openttd.wt2 16 hours 23 minutes ago (02.07. 23:29) stating "Quit: Leaving" after spending 9 hours 38 minutes there.
15:53:56 <Osai> Rubidium: strange problem, when I want to connect to Phazorx server
15:54:19 <Osai> there is a new-grf mismatch when I press the connect button (not before)
15:54:23 <Osai> dbg: [net] Connecting to 99.245.224.100 3979
15:54:23 <Osai> dbg: [grf] NewGRF 62700102 not found; checksum 0BE107D26B57B6886B5F08DFFB5A5B34
15:54:23 <Osai> dbg: [grf] NewGRF 4D656F80 not found; checksum A9A687595DC4EE204F16CA0DEAD4580E
15:54:24 <Osai> dbg: [grf] NewGRF 4E420107 not found; checksum 5A19459F9A576B151331D981A6887AAD
15:54:24 <Osai> dbg: [grf] NewGRF 2D480107 not found; checksum D12D0DF9F96AFFB4122E32D0C5D12D63
15:54:24 <Osai> dbg: [grf] NewGRF 4E440107 not found; checksum 1BB611005FFB5AB6BCEA9C0B1AF77941
15:54:24 <Osai> dbg: [grf] NewGRF 49450008 not found; checksum F7AB9FF79C9824E41F1FA073A87A70B1
15:54:26 <Osai> dbg: [net] Closed client connection 0
15:54:39 <Phazorx> these are my static grfs
15:54:49 <Osai> these are IDs of static grfs
15:54:50 <Chris82> was SET_EXPENSES_TYPE added after r5xxx ?
15:55:04 <Phazorx> osai you still have same issue?
15:55:46 <Osai> removing the static grf's helped
15:56:54 <Maedhros> Chris82: nope, it's been there for a long time
16:03:07 * dihedral is on his way home now....
16:07:55 <Maedhros> Phazorx: the reason the game is hanging is because that particular combination of parameters has given you a choice of 10 houses, none of which are 1x1 tiles (except the statues, but they're special anyway)
16:08:31 <Maedhros> i don't know if that's our bug or ttrs3's yet though
16:09:15 <Chris82> there's a potential bug in TTRS3 ? I use it all the time in MP games
16:10:10 <Phazorx> i figured it had to do with it
16:10:16 <Phazorx> but i played with params a bit as well
16:10:22 <Phazorx> howevr it only gave different timeframes
16:10:29 <Phazorx> but no stable solution
16:13:18 <peter1138> my quick & dirty autosignals works :D
16:14:43 <CIA-1> OpenTTD: rubidium * r10414 /trunk/src/network/network_server.cpp: -Fix: the network protocol check for required newgrfs sent static newgrfs too.
16:15:24 <Belugas> peter1138 is not lead dev for nothing :)
16:15:46 <Chris82> peter1138: .diff file anywhere already? :D
16:31:35 <Chris82> I don't understand this bug, when I take the r5435 version of the patch it works totally fine
16:31:54 <Chris82> when I upgrade the source to r104xx and replace the int32 with CommandCost it doesn't work anymore
16:32:05 <Chris82> the int32 to CommandCost is the only change tho
16:32:50 <Chris82> I mean the signal completion still works with CommandCost but it lets me build forever no matter how much money I have
16:32:58 <peter1138> other changes probably
16:33:43 <Chris82> hmmm well I can't find it, this patch doesn't even have a hundread lines
16:37:46 <Chris82> does total_cost += ret; and total_cost.AddCost(ret); do the same thing?
16:39:44 <NukeBuster> it works the same as in the diagonal demolish/level land patch
16:39:59 <Chris82> then the change in source causing this bug must be somewhere in the original code which is not touched by the patch
16:40:25 <Chris82> The bug here is different from the digonal patch tho, there's everything fixed already
16:40:54 <NukeBuster> is money a commandcost aswell?
16:41:42 <Chris82> but the "test" for money which we have in the diagonal patch shouldn't be necessary for the signal patch anyway as peter said before
16:42:07 <Chris82> I don't want to fix the problem by adding stuff that shouldn't be needed
16:42:37 <NukeBuster> i agree to that...
16:43:01 <NukeBuster> do you have a patch file?
16:44:36 <Chris82> there are minimal changes from the original patch code like int32 is now CommandCost and the above change in the total_cost line but except that it's the same as in r5435
16:45:27 <NukeBuster> btw.... you have the old diagonal land levelling patch...
16:46:01 <Chris82> uhm? but it's working correctly afaik
16:46:47 <NukeBuster> do you have explosions on each corner?? ;)
16:47:13 <Chris82> not for diagonal demolishing
16:48:25 <NukeBuster> yep... also there was an estimated cost problem...
16:48:54 <Chris82> yeah but I was told that the estimates are supposed to be higher than the actual costs since it can't be correctly estimated
16:48:56 *** KUDr_afk has joined #openttd
16:50:15 <Chris82> the cost variable was only available within one if clause not to the function
16:50:20 <Chris82> that's why it returned 0 all the time
16:51:11 <Chris82> so except that diagonal demolishing only causes 2 explosions instead of 4 everything should be fixed in the IN
16:51:28 <NukeBuster> still looking through your code
16:54:37 <Chris82> so at least I can be sure it's no conflict with another patch I added that's causing this bug
16:55:31 <Maedhros> Chris82: the changes in command.cpp deliberately disable the money check
16:56:17 <Chris82> oh let me check what's changed there :)
16:56:38 <Maedhros> and that appears to have been done because CompleteAutoSignals is badly written and doesn't take (flags & DC_EXEC) into account
16:57:20 *** KUDr_afk is now known as KUDr
16:59:04 <Chris82> (cmd & 0xFF) == CMD_BUILD_SIGNAL_TRACK ||
17:04:08 <Sacro> if you share orders, are timetables shared too?
17:08:12 <toresbe> So does anyone but me have problems with black areas in the graphics?
17:08:36 <Chris82> interesting, now that you say that toresbe I got this once today in a very old build
17:08:41 <toresbe> (ie. is it a problem known by someone who can better describe and debug it?
17:08:43 <Chris82> I've never seen such a black area before
17:08:59 <toresbe> This happens on the most recent build for me.
17:09:40 <Chris82> when you do a screenshot and open the picture do you see the clack areas on the screenshot?
17:09:54 *** |Jeroen| has joined #openttd
17:10:58 <Chris82> if you see it it might be the game if you don't see it on the screenshot I would guess it's your graphics card/driver
17:11:45 <toresbe> Chris82: It doesn't happen with the released one.
17:13:05 <Chris82> then maybe it was a bug in the specific "release" you have used
17:13:18 <Chris82> Maedhros you are god!!!! :D
17:13:35 <Chris82> I have no idea why these two lines were added in command.cpp but removing them fixed the bug :D:D:D:D
17:13:49 <Chris82> and auto complete still works flawlessly
17:14:09 <peter1138> 18:11 < Chris82> I have no idea why these two lines were added in command.cpp but removing them fixed the bug :D:D:D:D
17:14:25 <Sacro> we need timetables to auto-seperate trains
17:14:27 <peter1138> cos many patch authors don't know what they're doing ;)
17:15:28 <hylje> hence why we get so few patches into mainline
17:15:33 <Biff> toresbe: dont play on those old computers ;)
17:15:55 <Sacro> i like mainline actually
17:15:57 <peter1138> mainlining is some drugs thing
17:16:08 <hylje> we build mainlines over at coop :(
17:16:08 <Sacro> peter1138: it distingushes it from a branch :p
17:16:30 <hylje> well, trunk is pretty much the same as mainline in most contexts
17:16:55 <Chris82> actually mainline is even better, because it definitely is not part of a tree :D
17:17:19 <Chris82> tree with green leaves
17:17:42 <hylje> subversion is a tree structure
17:17:48 <Chris82> anyway me is happy now because this stupid bug is fixed once again due to your fabulous help guys :D
17:18:36 <Chris82> r1 = root, 0.5.2 = branch, r10414 = trunk and the tree is all together?
17:20:02 <peter1138> right, back to my signal auto complete implementation
17:20:50 <CIA-1> OpenTTD: glx * r10415 /trunk/src/ (41 files in 3 dirs): -Revert (r10403), Fix (r10323): 'message from company' test must use {STRING1}, so pass it the correct params
17:21:23 <CIA-1> OpenTTD: miham * r10416 /trunk/src/lang/ (norwegian_nynorsk.txt slovak.txt traditional_chinese.txt):
17:21:23 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2007-07-03 19:20:58
17:21:23 <CIA-1> OpenTTD: norwegian_nynorsk - 3 fixed by pollux (3)
17:21:23 <CIA-1> OpenTTD: slovak - 3 fixed by lengyel (3)
17:21:23 <CIA-1> OpenTTD: traditional_chinese - 6 fixed by xbddc (6)
17:22:04 <Chris82> NukeBuster: How did you make diagonal demolishing have 4 explosions?
17:23:08 <NukeBuster> using the fx and fy created in the patch...
17:23:29 <NukeBuster> it's just a few lines actually
17:24:46 <Chris82> do you have the .diff uploaded somewhere?
17:25:00 <Chris82> I just update my IN thread and would like to include the updated code
17:25:02 <NukeBuster> yeah its on the forum...
17:25:06 <Belugas> NukeBuster, how difficult would it be to have an explosion in the middle of the selection?
17:25:26 <NukeBuster> i wanted to copy you the spesific lines
17:25:28 <Chris82> what's the middle of 4 tiles?
17:25:47 *** Dutchtransporttycoon has joined #openttd
17:26:00 <Belugas> 4 tiles make a square/rectangle
17:26:06 <NukeBuster> @Belugas Easier than on every corner... but less fancy i gess.
17:26:13 <Belugas> at center between the four tiles
17:26:19 <Belugas> just wanted to know...
17:26:59 <Dutchtransporttycoon> who know a airport with more then 1 runway and more then 1 load/uynload area?
17:27:36 <Dutchtransporttycoon> someon????
17:27:52 <Noldo> how do you count load/unload areas?
17:28:09 <Eddi|zuHause2> Dutchtransporttycoon: you mean in reality?
17:28:29 <Dutchtransporttycoon> i have summmervakantion and i i' a little lazie so i
17:28:41 <Dutchtransporttycoon> no in the game
17:28:57 <Belugas> intercontinental has 4 runways, iirc
17:29:02 <Eddi|zuHause2> all airports have multiple gates
17:29:11 <Dutchtransporttycoon> if i want to see a real airport with more than 1 load/unload era i could go to schiphol
17:29:14 <Eddi|zuHause2> and all bigger than city airport have multiple runways
17:29:31 <Dutchtransporttycoon> i now but who knowas a grf
17:29:52 <Eddi|zuHause2> i don't think newgrf airports exist
17:29:55 <Dutchtransporttycoon> i' srry my englisch typing is not so good . i' dutch you now and i' 12 jr
17:30:34 <Belugas> newgrf airports are not available yet. Someone is working on it, form time to time
17:30:39 <Dutchtransporttycoon> but i but i have seen a screenshot of it in this forum !
17:30:39 <Eddi|zuHause2> may i express my doubts that your dutch typing would be better?
17:30:46 <NukeBuster> hope you can pick out the right lines ;)
17:30:54 <Dutchtransporttycoon> of aurse, bit
17:31:36 <Belugas> Dutchtransporttycoon, what you've seen on the forums are real airports, but they do only exists on Richk67's machine. Code is not in trunk nor release
17:31:46 <Dutchtransporttycoon> but i can type good Englisch normaly but i can' see what is typ
17:31:51 <Belugas> well... real ottd airports..
17:32:22 <Dutchtransporttycoon> In can' see here what i' typing
17:32:37 <Dutchtransporttycoon> so i make a lot mistakes
17:32:50 <NukeBuster> hmm... other irc client perhaps?
17:32:55 <Dutchtransporttycoon> but in Holland we say : BOEINEND !
17:33:00 <Dutchtransporttycoon> bOEIEND !
17:33:16 <Dutchtransporttycoon> that' what we say if we can' care
17:33:38 <Dutchtransporttycoon> Who wan's to learn al little bit Dutch?
17:34:02 <Dutchtransporttycoon> I can teach you to say goodbye and hello and stuff
17:34:19 <Dutchtransporttycoon> next time better
17:34:21 <NukeBuster> wouldn't have too ;)
17:34:26 <Dutchtransporttycoon> that' ok.
17:34:46 <Dutchtransporttycoon> dammed, antoher mistake of typing !
17:34:57 <CIA-1> OpenTTD: glx * r10417 /trunk/src/lang/ (norwegian_nynorsk.txt slovak.txt traditional_chinese.txt): -Fix: r10416 partly reverted r10415
17:35:01 <Eddi|zuHause2> ther are already too many dutch people in here anyway :p
17:35:04 <Sacro> please can you tell the game to stop putting error messages on the bottom left
17:35:15 <Sacro> its impossible to see when peopel are talking on multiplayer
17:35:31 <NukeBuster> wasn't that a patch option?
17:35:54 *** Phazorx has joined #openttd
17:36:47 <NukeBuster> i recall seeing that somewhere... or does ttdpatch have that?
17:37:04 <Eddi|zuHause2> shouldn't error messages be printed on top of the chat display?
17:37:25 <Dutchtransporttycoon> who nows a good site where i can get some insparations for Open TTD?
17:37:59 <Thomas[NL]> visit the screenshots section of tt-forums
17:40:23 <Chris82> shouldn't STRING be STRING1 @r10417 ?
17:40:42 *** Dutchtransporttycoon has quit IRC
17:41:01 *** Dutchtransporttycoon has joined #openttd
17:41:07 *** Dutchtransporttycoon has quit IRC
17:41:32 <Eddi|zuHause2> never use STRINGx in translations
17:41:52 <Eddi|zuHause2> only in english.txt
17:47:18 *** Osai is now known as Osai^Kendo
17:50:38 *** skidd13 has joined #openttd
17:51:13 <orudge> track upgrading somebody else's track in multiplayer = boom
17:51:34 <hylje> that should be beyond obvious
17:51:40 <Chris82> oh really? let me try :D
17:51:52 <orudge> maybe it's only in certain circumstances...
17:52:07 * orudge is currently listening to Tomcraft - Loneliness (1:53/3:34 @ 256 kbps) - www.owenrudge.net/playlist.php?id=736
17:53:19 <glx> orudge: should be fixed in r10415
18:03:50 <Chris82> also added Smovious Chat Patch and Bridge Dialogue Fix
18:07:49 <stillunknown> Chris82: I hope for your sake that you have a local svn server or a svk copy.
18:11:01 <Chris82> uhm I have no SVN Server sorry, I only have two copies of trunk on my HDD
18:11:15 <Chris82> one for original trunk compilation and one for IN development
18:11:27 <Chris82> I plan to install a SVN server after my exams tho
18:11:31 <Chris82> have no time for that right now :p
18:11:53 <Rubidium> svk? That's a waste of precious hdd space ;)
18:12:16 <lev400> im looking for GRF Maker?
18:12:19 <Chris82> well as long as it doesn't waste more than 2,5 TB :D
18:12:23 <stillunknown> Rubidium: how so?
18:14:14 <lev400> tram set not work in openttd?
18:14:35 <Rubidium> a clean svn checkout is already like 100 MB, the svn repository itself is 500 MB, and a git repo with all changes (to trunk) since ~ r5000 is about 90 MB
18:14:44 <lev400> or this Extended cargo schema ECS project?
18:15:15 *** mikk36[EST] has joined #openttd
18:15:31 <stillunknown> lev400: trams are not 0.5.x
18:15:41 <Rubidium> as SVK effectively clones the whole svn repository *and* you need to have a checkout of it, you'll use 600 MB, whereas the git repo would use < 100 MB
18:16:00 <stillunknown> newcargos is in trunk, but newindustries is not
18:16:06 <stillunknown> So ECS won't work.
18:16:45 <lev400> and any plans to get it to work? :X
18:17:12 <Smoovious> <Chris82> also added Smovious Chat Patch <--- \o/
18:17:21 <Smoovious> did you look at the mail subsidies one too?
18:17:25 <lev400> i first though openttd was best choice but ive been looking at some things and it seams maybe i should get ttd with ttdpatch to try some things out
18:17:36 *** setrodox has joined #openttd
18:18:13 <Chris82> yup Smoovious, but I didn't have time to test the mail subsidies yet :)
18:18:23 <Chris82> I programmed so much today already I have to do math homework now :p
18:19:33 <peter1138> woo, my signal autocomplete can now complete a circle
18:20:05 <Chris82> also added Smovious Chat Patch < was that on IRC? because in the thread I wrote it correctly :D
18:20:23 <stillunknown> Is there a specific reason why SOME_ENUMByte is used instead of a machine native int?
18:20:23 <peter1138> hmm, whoops, it doesn't change the signal direction :D
18:20:48 <Chris82> cool :) would be great if your work makes it into trunk peter, one patch less I need to maintain in the IN *g*
18:21:16 <Rubidium> stillunknown: because native enum has undefined size and native int makes the saveload stuff more complex than needed
18:21:46 <stillunknown> Rubidium: Why not make a DirectionInt for example
18:22:09 <stillunknown> I did that for one or two, and i can see the difference already.
18:22:25 <Rubidium> stillunknown: because directions are stored in the savegame
18:23:43 <stillunknown> (i switched to DirectionByte and TrackByte because i wanted to pass variables as reference, so i changed several instances in a often used function to their *Byte equivilants, which had negative effects, using int instead of byte improved performance again).
18:23:52 <lev400> so no simple way to make some new graphics without GRF Maker?
18:24:25 *** TrueBrain has joined #openttd
18:24:25 *** michi_cc has joined #openttd
18:24:25 *** unununium.oftc.net sets mode: +ov TrueBrain michi_cc
18:25:02 <stillunknown> Rubidium: Don't underestimate the effects of these things when calling functions a few billion times each hour)
18:26:14 <Rubidium> stillunknown: making stuff native int without the proper savegame knowledge is asking for trouble
18:26:59 <stillunknown> But is there no way to have these things downscaled at savetime?
18:27:48 <Thomas[NL]> lev400, you can try png codec search for it on the forums. It is different from a .grf though
18:27:54 <Rubidium> yes, but it requires a rethink of (parts of) the savegame loading/saving mechanism
18:28:08 <lev400> i have the gfx i just want to pack them into a grf?
18:28:25 *** Chicago_R_A has joined #openttd
18:28:29 <stillunknown> Rubidium: any chance this will happen soonish?
18:28:52 <Rubidium> depends on what you call soonish
18:28:57 *** iPandaMojo has joined #openttd
18:29:06 <Thomas[NL]> lev400, in what format do you have the graphics?
18:29:16 <stillunknown> Within a month or two.
18:29:56 <Thomas[NL]> are they in the ttd palette colours??
18:29:58 <peter1138> whoops, infinite loop :)
18:30:51 <stillunknown> Rubidium: Within a month or two.
18:31:02 <peter1138> crap, this detects forks but not merges :(
18:31:55 <Rubidium> stillunknown: maybe, but what are the (real) performance benefits besides the increment in memory usage?
18:32:56 <stillunknown> Data types being in the machine native format, reducing the amount of instructions needed to process it.
18:33:04 <Thomas[NL]> you don't have to convert them to the ttd-palette with pngcodec, search the forum for it?
18:34:08 <Rubidium> stillunknown: which results in... 0.0001% increase in speed?
18:34:41 <stillunknown> Rubidium: I noticed it while profiling.
18:35:10 <stillunknown> One function consumed 1% more of the total.
18:35:41 <stillunknown> But that function is called a lot.
18:36:40 <peter1138> you know, cpus do operations on bytes, words and dwords directly...
18:36:41 <Rubidium> such a deviation isn't statistical important; I've seen lots of cases where the usage was different with such a degree with several profiling runs
18:37:15 *** mikk36[EST] is now known as mikk36
18:38:40 <stillunknown> Rubidium: i will do more runs to confirm (or not).
18:40:55 <stillunknown> peter1138: Do you have reading material which will make that plausible?
18:42:08 <caladan> oh come on, optimizing too early is a bad thing
18:42:47 <caladan> int should be faster than byte, but when it comes to big arrays... byte is more efficient
18:43:53 <peter1138> as stillunknown is working purely on an optimisation patch, that can hardly be called optimising early
18:44:45 <caladan> kk, i agree, but maybe there are more important things
18:44:53 <peter1138> optimising 'better-late-than-never' some might say :)
18:45:06 <stillunknown> I think the comparison between byte's and int's is causing the difference.
18:45:09 <peter1138> sure, but if that is what he wants to do, i'm not going to stop him :)
18:45:29 <caladan> comparing int is just cmp
18:45:38 <caladan> with bytes you get addidional and probably
18:47:06 <peter1138> not that gcc is necessarily that clever, of course...
18:47:28 <peter1138> actually that should've be 0x00000011
18:48:05 <caladan> hmm, sorry, im used to CPUs where registers are whole thing and cannot be accesed by parts :D
18:48:38 <caladan> but arm has some other nice features...
18:49:09 <caladan> like all conditional ops and built in shifting
18:49:58 <peter1138> int32_t a = 0x00000011;
18:49:58 <peter1138> 8048385: c7 45 f4 11 00 00 00 movl $0x11,0xfffffff4(%ebp)
18:49:58 <peter1138> 804838c: c6 45 fb 11 movb $0x11,0xfffffffb(%ebp)
18:50:00 <peter1138> 8048390: 0f be 45 fb movsbl 0xfffffffb(%ebp),%eax
18:50:02 <peter1138> 8048394: 3b 45 f4 cmp 0xfffffff4(%ebp),%eax
18:50:17 <stillunknown> For the moment i'll leave the difference to statistical flukes, since the first try is not exactly encouraging, sorry for all the fuss.
18:51:47 <peter1138> using register is used eax & edx, but both longs
18:52:55 <caladan> so using ints will do difference in the lenght of code
18:53:14 <caladan> but now it's about accessing memory
18:53:29 <peter1138> and if i optimize it it gets compiled away ;)
18:54:37 <Eddi|zuHause2> [2007-07-03 20:46] <peter1138> mov ax, 0x11111111
18:54:37 <Eddi|zuHause2> [2007-07-03 20:46] <peter1138> mov cl, 0x11
18:54:37 <Eddi|zuHause2> [2007-07-03 20:46] <peter1138> cmp al, cl
18:54:46 <Eddi|zuHause2> i think that will fail with signed integers
18:54:57 <peter1138> it's pseudo code anyway
18:55:32 <Eddi|zuHause2> yes, but still, al might not have the same sign-bit as ax
18:55:50 <peter1138> solution: use r10417
18:55:54 <Eddi|zuHause2> Wolf01: should be fixed already
18:55:56 *** ChanServ sets mode: +o Bjarni
18:56:23 * Bjarni wonders why Sacro is always looking for him
18:56:41 <Bjarni> am I some sort of role model to him or something?
18:57:03 <Bjarni> nahh, can't be.... he would never reach my level anyway :p
18:57:10 <Eddi|zuHause2> Bjarni: there was some stuff about OSX desyncs
18:57:26 <Bjarni> Sacro: I'm not into that
18:57:45 <Bjarni> Eddi|zuHause2: OSX is perfect... it's the rest of the world that's off
18:57:55 <stillunknown> Is it right that inlining also has the effect that variables are not copied?
18:58:23 <Bjarni> anyway did anybody figure out any reason why the desyncs occurs?
18:58:26 <caladan> well, at least if they were in use
18:58:27 <Sacro> Bjarni: but you run OSX
18:58:46 <peter1138> stillunknown: depends really
18:58:49 <Eddi|zuHause2> stillunknown: it might optimise the call-by-value stuff away
18:59:22 <peter1138> if the inline function changes a value (but only internally) then it has to. i guess.
19:00:08 <Eddi|zuHause2> the compiler has to prove that it does not cause new side effects
19:02:06 <Eddi|zuHause2> but the main overhead of function calls is the saving/restoring of registers, not the parameter copying
19:02:17 <Bjarni> so about the desyncs... did you guys figure anything out last night or today?
19:02:28 <Bjarni> I went as far as "it happened"... not really useful
19:02:46 <Eddi|zuHause2> especially in RISC processors you often have an awful lot of registers
19:03:27 <peter1138> Bjarni: if you give me your mac, i'll try to diagnose it
19:03:59 <Rubidium> Bjarni: we're still busy with it
19:04:25 <stillunknown> It's just a give N variables output and return something.
19:04:25 <stillunknown> Also, what's best, if (A && B) {} if (A) { if(B) {} if (C) {}}?
19:04:25 <stillunknown> providing ofcource A is not a hugely expensive check.
19:05:23 <Rubidium> stillunknown: if A = false, then B isn't evaluated
19:05:41 <Rubidium> so it effectively becomes if (A) { if (B) {} }
19:05:48 <Rubidium> so it shouldn't matter a bit
19:06:17 <Eddi|zuHause2> you can be almost certain the compiler shuffles that stuff around anyway :)
19:07:01 <_42_> Frostregen, skidd13 (skidd13@p548A580F.dip.t-dialin.net) was last seen parting #openttdcoop 29 minutes ago (03.07. 18:37), after spending 1 hour 27 minutes there.
19:10:42 <sHELL> still working on the desync bug?
19:12:14 <caladan> compilier does resolve those A&B to two jumps, but it doesnt know which of these conditions is more probable
19:12:33 <caladan> then sometimes it matters which comes first
19:12:42 <peter1138> A will always come first
19:13:33 <caladan> that's it. and if P(A) > P(B) it's better to do if (B&A)
19:13:56 <peter1138> yes, assuming B doesn't rely on A changing stuff first, heh
19:14:00 <peter1138> but taht much was obvious
19:14:49 <Eddi|zuHause2> caladan: no, C(++) has defined to first evaluate A, if it is true then evaluate B (lazy evaluation)
19:15:07 <Eddi|zuHause2> it cannot change the order
19:15:38 <caladan> right, peter said it before. i mean that programmer can do it by hand sometimes improving code
19:16:25 <Eddi|zuHause2> yes, but that is not what the question was about
19:16:56 <CIA-1> OpenTTD: rubidium * r10418 /trunk/src/ (industry.h industry_cmd.cpp table/build_industry.h): -Codechange: implement/resurrect the industry production flags.
19:18:44 <peter1138> just finished a recompile :p
19:21:51 <caladan> have you ever seen compilier using leave on x86??
19:25:20 <CIA-1> OpenTTD: rubidium * r10419 /trunk/src/industry_cmd.cpp: -Fix (r10418): do not compare bitmasks with HASBIT. Thanks to Maedhros for spotting this.
19:33:48 *** NukeBuster has left #openttd
19:34:00 *** NukeBuster has joined #openttd
19:34:42 *** NukeBuster has left #openttd
19:38:40 *** NukeBuster has joined #openttd
19:43:33 *** NukeBuster has joined #openttd
19:44:25 *** NukeBuster has left #openttd
19:44:31 *** NukeBuster has joined #openttd
19:47:42 *** Tlustoch has joined #openttd
19:49:08 <Tlustoch> Can someone tell me how do I make japanese town names work? I have loaded grf file in the menu but then there's no selection of japanese town names in game options.
19:49:25 <Rubidium> Tlustoch: what version are you using?
19:50:12 <Rubidium> that doesn't support townnames loaded from newgrfs
19:50:53 <Rubidium> 0.6.0 will, but that isn't going to be released soon, however the "nightlies" do support them
19:51:26 <Rubidium> "nightlies" are daily snapshots of "trunk", which is (at the moment) the development branch for 0.6
19:52:03 <Tlustoch> How do I install that on gentoo?
19:53:25 <caladan> download archive with nigtly version
19:53:34 <caladan> ./configure in the dir
19:53:40 <caladan> then make and here you go
19:54:15 <Rubidium> isn't there some ebuild for trunk somewhere?
19:54:46 <caladan> haven't seen, in plain portage just openttd-0.5.2
19:55:41 <Maedhros> i wrote one at one point, but i think i abandoned i
19:57:24 <Phazorx> Maedhros that TTRS bug - any idea about it
19:58:27 <Tlustoch> I also used japan buildings but I could not find any japan style building on the map.
19:58:44 <Maedhros> Tlustoch: again, not in 0.5.2
19:59:04 <Maedhros> Phazorx: not at the moment, but i suspect you'll be fine if you get rid of the second parameter
19:59:14 <Tlustoch> But landscape and trees worked ok..
19:59:16 <caladan> Tlustoch: try that nightly build, it's cutting edge
19:59:34 <Phazorx> Maedhros: we are doing some tests for other issues and it runs on same map with ttrs enabled 25 years in future
19:59:53 <Phazorx> caladan: it's bleeding ratehr than cutting atm :)
20:01:56 <Maedhros> Phazorx: yes, it's to do with forcing the 1950-80s era buildings, so you'll be fine if the date matches the era
20:02:19 <Phazorx> same buildigns are forced
20:02:46 <Phazorx> i gues sit matters what are you forcing on top of
20:03:21 <Maedhros> but currently it seems that even if you force 1950s era buildings they're still only available from 1950
20:03:33 <Maedhros> so playing in 1930 == no available buildings == infinite loop
20:04:07 <Phazorx> in that case forcing is bad
20:04:31 <Phazorx> sad... i saw wanted to avoid having skyscrapers
20:05:51 <peter1138> hmm, ttrs3 or openttd bug? heh
20:09:57 *** Sacro_ is now known as Sacro
20:19:17 <Tlustoch> with nightly it's ok, thanks
20:19:34 <Tlustoch> What's game starting year in original game?
20:27:39 <sHELL> how come openTTD is so adictive
20:28:16 <Phazorx> if it would be bad it probably would have been even mroe addictive
20:29:57 <Phazorx> hylje join #desync plz
20:36:19 <Chicago_R_A> Still going in circles, Peter? :)
20:36:44 <Maedhros> hmmm. it seems we're wrong rather than ttrs3, but fixing it will be a bitch
20:36:52 <hylje> i recall that crashed the MiniIN signal completer
20:37:44 <peter1138> /* Prevent possible loops */
20:37:47 <peter1138> if (tile == start_tile) break;
20:38:24 <Chicago_R_A> Nice fix-- well done
20:44:33 <peter1138> hmm, better check it works for the old method :)
20:44:58 * peter1138 suspects recompiling will help, though
20:45:25 <Maedhros> Belugas: Csaboka resets all the house years in one big block, but apparently house 144 is never defined, so TownHouseChangeInfo refuses to set the house dates for any of them
20:46:44 <peter1138> you could always change the FOR_EACH_OBJECT macro
20:46:51 <peter1138> into something nicer at the same time
20:47:04 <hylje> peter1138: isnt there some redundancy? you check for tile == end_tile twice
20:47:49 <hylje> you just moved it around
20:48:32 <peter1138> but damn, ctrl is used for toggle signal type when dragging
20:48:37 <peter1138> i never knew it did that...
20:49:19 <Phazorx> peter1138: it's a perk
20:49:44 <peter1138> it costs the same as removing and rebuilding them too :o
20:50:04 <peter1138> so... how the feck should i enable autorail... i wanted to use ctrl :/
20:50:24 <Phazorx> ctrl on a tile with no signal?
20:50:31 <Chicago_R_A> I'm guessing a simple GUI is out of the question?
20:50:38 <peter1138> no, then you can't set what signal direction to use
20:51:24 <peter1138> Chicago_R_A: at this stage i want it just a simple toggle
20:52:06 <Chicago_R_A> Maybe a yes/no pop-up.... so if you highlight 10+ consecutive sections of track a pop-up simply asks if you want to continue beyond the 10 squares?
20:52:13 <Chicago_R_A> not sure if that is any easier, though
20:52:45 <Chicago_R_A> I'll be shuttin' my yapper, then :)
20:53:01 <Belugas> Maedhros : could it be a bump by overrides? Just out of nowhere...
20:53:20 <peter1138> does anyone USE ctrl-drag for replacing signal types?
20:53:45 <Chicago_R_A> Until a few min ago, I didn't even know that feature was there - so my vote goes to "no"
20:53:49 <Phazorx> not many people even know about it tho
20:54:37 <Maedhros> Belugas: unfortunately it looks like ttrs3 doesn't define house ids 144 to 148
20:55:38 <Maedhros> "If you try to modify a house ID whose property 08 isn't set, your request is ignored, but not reported as an error, either."
20:55:57 <Maedhros> i suppose it's open to interpretation whether it's our bug or the grf's :)
20:56:27 <peter1138> we ignore the house block instead of just the id. hmm.
20:57:04 <peter1138> damn this ctrl key!
20:57:12 <peter1138> damn this stupid feature!
20:57:29 <Chicago_R_A> Peter - can you tap into the whole double-click ?
20:57:33 <Belugas> their houses are contiguous in the array. why ours are not? are they too?
20:57:36 <Phazorx> and continue in both directions
20:57:40 <peter1138> double click on what? heh
20:57:49 <peter1138> hmm, ctrl-double-click
20:58:18 <peter1138> Belugas: fast forward? :o
20:58:24 <Chicago_R_A> Clearly this calls for Ctrl-Alt-Del ;)
20:58:29 <peter1138> hmm, possible temporarily until a gui...
20:58:46 <Chicago_R_A> Sorry, couldn't resist.
20:59:19 <Maedhros> Belugas: hmm? ours are too, but only after using ::SetEntitySpec on them :)
21:00:46 <MarkMc> Is there any goaround so you can remove industries? :P
21:02:55 <Belugas> i should have known that...
21:03:21 <peter1138> Belugas: lol, yes, shift is good for cost estimation ;)
21:03:42 <Phazorx> what's wrong with dblclick ?
21:03:53 <peter1138> double click is not supported there...
21:04:05 <Belugas> and it's tab for fastforward ;)
21:04:14 <peter1138> Belugas: not in a debug build
21:04:48 <Belugas> and on this joyfull note, i salute you all, going home
21:05:14 <peter1138> Maedhros: tell me how to activate this!
21:05:33 * peter1138 ponders reassigning ctrl
21:08:11 <peter1138> really, who uses it like it is?
21:09:02 <Chicago_R_A> Good ol' Alt-F4? :)
21:09:55 <Maedhros> control + drag? i don't
21:10:05 <Maedhros> or at least, i'm usually surprised when i do it accidentally
21:12:32 <MarkMc> Chicago_R_A: Hmm, is that consider as a cheat?
21:12:45 <Chicago_R_A> the bulldozer? yes
21:13:42 <NukeBuster> i tried the old signal auto complete, and tried to use it. By ctrl dragging...
21:14:12 <NukeBuster> i also never knew it was used to change signals
21:14:23 <peter1138> i thought it was a bug at first...
21:14:27 <MarkMc> Anyway, can I use it when I networkplay too? :)
21:14:27 <peter1138> hmm, maybe it is? ;)
21:14:54 <peter1138> MarkMc: also be aware that industries and towns etc can use it is
21:15:01 <peter1138> so they can build on your track
21:15:07 <peter1138> so, uh, don't leave it on
21:15:23 <MarkMc> Aha, you can turn it off to :D
21:15:58 <Chicago_R_A> Yea, good point, Peter...
21:16:14 <Chicago_R_A> I fought a town off from destroying a temperate bank over and over again until I figured that one out.
21:16:57 <Maedhros> it's probably safest to use it along with build while paused
21:17:58 <MarkMc> But it didn't help me then I always play over network then the AI:s are so stupid :>
21:18:23 <peter1138> right, auto signals should not: pass existing signals, pass junctions, pass stations. anything else?
21:19:18 <peter1138> they can go through tunnels, and over bridges
21:19:40 <peter1138> there is no trickery to get the signals to line up with the exits or whatever, though
21:19:53 <peter1138> you can sort that out manually ;)
21:19:56 <peter1138> makes it a lot simpler
21:20:05 <Chicago_R_A> jeez... you're asking a lot of us, Peter
21:20:42 <Rubidium> who knows a tool to do boundary checking on non-malloced memory?
21:21:02 <Chicago_R_A> So if I have it set to "every 8 tiles" it will count the tunnel and bridge "tiles" in the 8 and simply continue using that pattern?
21:22:36 <Chicago_R_A> Cool. That makes the most sense.
21:24:15 *** Sacro|Laptop has joined #openttd
21:24:28 <Eddi|zuHause2> i was under the impression it just did (x+y)%distance, rather than counting anything
21:24:55 <peter1138> count as in include
21:25:29 <Eddi|zuHause2> well, i mean, this would not care at all wether there were wormholes inbetween
21:26:38 <peter1138> one other possible thing... don't remove signals that are red?
21:27:24 <Eddi|zuHause2> what has that to do with autosignals?
21:27:28 <Chicago_R_A> Does this overwirite all existing signals in the segment?
21:28:00 <peter1138> you can use autosignals for removing signals too
21:28:13 <peter1138> Chicago_R_A: when placing signals, it stops at the first signal it encounters
21:28:37 <Eddi|zuHause2> oh, btw, with auto-semaphores now there is not much reason for ctrl+drag switching signal types
21:30:33 <Maedhros> (although that == 0 should be == NULL)
21:31:01 <Maedhros> housespec, stationspec, etc
21:37:20 <peter1138> Maedhros: it's definitely better. it's got parameters for a start...
21:37:42 <Chicago_R_A> Is that a roller-coaster?
21:37:56 <peter1138> it's OpenRollerCoasterTycoonDeluxe!
21:38:15 <Chicago_R_A> can you post pics of OpenRollerCoasterTycoonDeluxe highways?
21:38:19 <peter1138> just a little stress testing...
21:38:20 <Phazorx> peter1138: it would be nice to be able to make it more greedy
21:38:53 <Phazorx> in case if signal can net be placed where necessary for maintaing intervals
21:39:06 <Phazorx> it should place one in a way that signal distance will be less
21:39:17 <peter1138> 22:17 <@peter1138> there is no trickery to get the signals to line up with the exits or whatever, though
21:39:20 <peter1138> 22:17 <@peter1138> you can sort that out manually ;)
21:39:47 <Phazorx> dont have to lane them up just put on previous and nex avalibale tile
21:40:27 <Phazorx> otherwize it will loose usability aspects for any none straight network
21:41:11 <Phazorx> cuz "fire and forget" mode turns into "click and check thoroughly" :)
21:43:27 * Phazorx is goign to go cry in some corner
21:47:46 *** Digitalfox has joined #openttd
21:48:39 *** Vikthor has joined #openttd
21:52:36 *** ChanServ sets mode: +o Bjarni
21:59:15 <peter1138> woo, found a lockup
21:59:40 <Thomas[NL]> hmm, setting the production in the scen editor by clicking the number and entering a number is totally broken
22:00:43 <peter1138> Phazorx: cos you didn't draw it?
22:01:17 <Phazorx> highly unlike that it'll be worthy one if i make it
22:04:03 *** Osai^Kendo is now known as Osai
22:04:53 *** valhallasw`study is now known as valhallasw
22:32:03 *** Nickman has joined #openttd
23:07:57 <CIA-1> OpenTTD: KUDr * r10420 /trunk/projects/ (openttd_vs80.vcproj openttd_vs80.vcproj.in): -Fix [MSVC]: Disabled 'Treat Warnings As Errors' for VC8
23:09:02 <CIA-1> OpenTTD: KUDr * r10421 /trunk/src/stdafx.h: -Fix [MSVC]: suppress some code analyzer warnings for VC8
23:17:01 <DorpsGek> Sacro: Smoovious was last seen in #openttd 4 hours, 54 minutes, and 2 seconds ago: <Smoovious> yeah, was on IRC
23:22:51 *** Gekkko` has joined #openttd
23:23:49 <CIA-1> OpenTTD: KUDr * r10422 /trunk/src/airport.h: -Fix: VC8 Code Analyzer warning C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Results might not be an expected value
23:27:21 <Sacro> we have been discussing newsignals more :p
23:30:24 <KUDr> heh: warning C6326: potential comparison of a constant with another constant
23:30:51 <Sacro> might as well just nop that
23:31:19 <KUDr> it is product of tepmplates
23:31:45 <KUDr> but taken from template argument
23:31:45 <Sacro> i don't get templates :(
continue to next day ⏵
