IRC logs for #openttd on OFTC at 2007-06-12
⏴ go to previous day
00:00:06 <Belugas> like the power plant...
00:00:23 <Belugas> do you think tiles woth sparkles can process coal?
00:00:35 <Smoovious> yeah... dumping coal at the business office doesn't do the power station much good
00:00:51 <Belugas> that is exactly the point
00:01:03 <KristjanS> are you saying they drop oil in the desert?
00:01:17 <Smoovious> no, only along the coastlines :P
00:02:20 <KristjanS> i am not talking about building oil refinery.... :-D
00:02:59 <KristjanS> you seem like you do
00:03:14 <KristjanS> because you say that the 'tiles' need to process oil
00:03:30 <Eddi|zuHause3> the industry is distributed over several tiles
00:03:35 <Eddi|zuHause3> not all of them accept oil
00:03:44 <Eddi|zuHause3> in fact, only very few of them do
00:03:55 <Eddi|zuHause3> you have to have those tiles in the station coverage
00:04:26 <KristjanS> never seen the radius for accepting tiles to be 1 though before
00:04:43 <Belugas> a hint... only the tile with the tower and the flame do accept oil
00:04:44 <Smoovious> it is a radius around the acceting tiles
00:05:36 <Eddi|zuHause3> it made sense all the time...
00:06:56 <KristjanS> no, becuase you didn't tell me that only the tower and the flame accept oil ;-)
00:07:12 <Smoovious> he told you to use the ? tool to see which tiles accept oil
00:07:29 <Eddi|zuHause3> we told you that some tiles don't accept oil
00:07:43 <Eddi|zuHause3> and we told you to check that
00:07:49 <Smoovious> most people can handle that...
00:08:03 <Eddi|zuHause3> and you did not do that
00:08:07 <KristjanS> yes, but i didn't say that this is weird
00:08:12 <Smoovious> so now you get spanked
00:08:27 <KristjanS> i wanted to know why it is only 1 square on one side
00:08:43 <Eddi|zuHause3> it is not 1 square
00:08:54 <Eddi|zuHause3> it is 4 squares from the tile that accepts oil
00:09:02 <KristjanS> it was 1 square from the refinery building
00:09:11 <Smoovious> the building doesn't accept oil
00:09:16 <Eddi|zuHause3> but the building does not matter
00:09:45 <KristjanS> :-D yes, but i thought you meant something else
00:09:55 <Smoovious> the buildings don't matter... only the tiles that accept are what matters
00:10:26 <KristjanS> i am sorry for not understanding what you said ;^)
00:10:49 <eekee> Eddi|zuHause3: renaming did help after all, I had to free up a name the game thought appropriate (Tatminster East)
00:11:40 <Eddi|zuHause3> err... yes... freeing "west" would not make much sense when building east
00:11:49 <Eddi|zuHause3> but there are a lot of generic names
00:12:27 <Eddi|zuHause3> but remember, the number of custom names is also limited
00:13:58 <KristjanS> is there a jesus in openttd?
00:14:09 <KristjanS> my friend needs a jesus to help him
00:16:51 <Eddi|zuHause3> i have not spotted one yet
00:17:52 <Digitalfox> You may speack with me, since i have Jesus in my name...
00:18:03 <Belugas> KristjanS, you might find one, it is called wiki.openttd.org ;)
00:18:34 <KristjanS> i forwarded your messages in order to help him get enlightened
00:19:06 <Digitalfox> Belugas what have you done... I was thinking of getting rich... :(
00:25:33 <KristjanS> by the name of the purple frog
00:25:41 <KristjanS> my friend has more cash than i do
00:27:15 *** Sacro|Laptop has joined #openttd
00:27:55 <KristjanS> no wonder, one of my trains had a wrong schedule
00:27:59 <KristjanS> and i have 2 trains
00:32:32 <Belugas> Digitalfox : sorry ;)
00:32:39 <Belugas> next time, rect faster ^_^
00:40:15 *** ThePizzaKing has joined #openttd
00:43:10 <Digitalfox> Belugas: We split the money next time ;)
00:50:18 <CIA-1> OpenTTD: belugas * r10108 /trunk/src/ (newgrf_industries.cpp newgrf_industries.h):
00:50:18 <CIA-1> OpenTTD: -Codechange: implement variable 0x60 (Get industry tile ID at offset) for industries.
00:50:18 <CIA-1> OpenTTD: It is exposed for for industry tiles who will reuse it too, for variable 0x62.
00:53:39 <KristjanS> i stopped my train in a station
00:53:54 <KristjanS> it say's it's stopping and that it's going at 20 km/h
00:53:58 <KristjanS> while it's stopped already
00:55:18 *** UndernotBuilder has joined #openttd
00:55:40 <UndernotBuilder> what about making the trams topic a general announcement one?
01:30:56 *** Eddi|zuHause2 has joined #openttd
01:31:46 *** UndernotBuilder has quit IRC
01:56:52 *** tokai|ni has joined #openttd
03:17:27 <KristjanS> what key to close all windows? :p
03:37:44 *** Taikaponi has joined #openttd
03:41:01 <KristjanS> items no more bring more money the further you transport them?
03:43:00 *** welterde has joined #openttd
03:46:44 *** ChanServ sets mode: +o orudge
03:47:13 *** Rubidium has joined #openttd
03:50:30 *** MiHaMiX has joined #openttd
05:02:29 *** setrodox has joined #openttd
05:47:28 *** Frostregen_ has joined #openttd
05:48:17 *** Taikaponi has joined #openttd
05:53:37 *** Frostregen_ is now known as Frostregen
05:59:29 <stillunknown> Truebrain: How much faster is the rendering now?
06:03:44 <stillunknown> Phazorx: Is that the cpu usage?
06:04:55 <stillunknown> 5% cpu usage, that seems very low/
06:05:39 <Phazorx> it's actualy flips between 3 and 5
06:06:02 <Phazorx> but that game is weird in a sense
06:06:07 <Phazorx> lots of tracks and trains are longer
06:06:16 <peter1138> me too. i didn't get that amount of improvement
06:06:32 <Phazorx> peter1138: testing teqnique makes a lot of difference too
06:06:42 <stillunknown> peter1138: btw, i pretty much done with my own hashmap thingie, just to let you know
06:06:45 <Phazorx> that is done with no animation and sounds
06:06:58 <Phazorx> as well as viewpoint not having any action on screen
06:07:07 <Phazorx> since sprite managing takes a lot of power
06:07:31 <Phazorx> so this is pretty much only pathfining and collision cycles only
06:07:58 <stillunknown> There is much more at work, than just that.
06:08:37 <Phazorx> well... i have a feeling these two are largest consumer in terms of CPU power
06:08:46 <Phazorx> since it is per vehivle per tick
06:08:56 <stillunknown> TrainLocoHandler is a a big load as well
06:08:56 <Phazorx> rest is event based or pert game timeunit
06:09:39 <Phazorx> well my numbers are not absolute, however they are taken in same situation for all tested cases
06:09:55 <Phazorx> whcih emans they can be compared against each other and represent state of things on my platform
06:10:38 <stillunknown> Either you have a blazingly fast cpu, or something is wrong.
06:11:07 <stillunknown> Also keep in mind that rendering stuff has been improved in the last few revs.
06:11:48 <peter1138> not a great improvement
06:12:01 <peter1138> most of the reason for those changes are code separation
06:12:16 <peter1138> or something. my english went wrong there :o
06:13:58 <Phazorx> rendfering as in graphics?
06:14:12 <peter1138> which you ruled out :)
06:14:12 <Phazorx> stillunknown: CPU is clocked t-bred 2100+
06:14:34 <Phazorx> yeah for the test cases screen is pointed at water in corner of the map
06:14:49 <Phazorx> there is nothing moving on screen and animation and full details are disabled
06:15:33 <Phazorx> the aim was trully tests performance of logic part rather than anything else
06:17:33 <stillunknown> 6 bits is a bit low
06:17:58 <stillunknown> But i must go now.
06:18:22 <peter1138> i tried increasing it. didn't affect much to be honest
06:18:33 <peter1138> didn't actually benchmark it though
06:48:16 <peter1138> eek EvL uses ancient grfs
06:48:24 <peter1138> and dbsetxl with dbset??
06:50:48 *** |Gekkko| has joined #openttd
06:50:52 *** |Gekkko| is now known as Gekko
06:51:36 *** |Gekkko| has joined #openttd
06:51:41 *** |Gekkko| is now known as Gekko
06:54:05 <peter1138> hmm, yes, EvL is a lot faster
06:54:13 <peter1138> becomes smooth on my athlon 1250
07:01:00 *** |Gekkko| has joined #openttd
07:10:00 *** boekabart has joined #openttd
07:13:49 <Phazorx> peter1138: grfs are funky there sorry about that
07:14:04 <Phazorx> you see improvement w/ ur patch tho?
07:14:20 <peter1138> as my cpu is too slow
07:14:37 <peter1138> i'm doing profiling now
07:14:47 <peter1138> although maybe 10000 frames was too much
07:14:47 <Phazorx> reduce animation/details
07:14:51 <Phazorx> or run dedicated server
07:14:58 <peter1138> heh, i saved the game in the top corner
07:15:24 <Phazorx> i also disabled sound and tweaked grfx
07:15:42 <peter1138> ./openttd-6-1 -g save/speedtest.sav -v null -m null -s null
07:15:50 <peter1138> hash bits 6, hash res 1
07:21:26 *** |Gekkko| is now known as Gekko
07:26:57 <peter1138> 35.13 11.36 11.36 95542065 0.00 0.00 FindTrainCollideEnum(Vehicle*, void*)
07:27:00 <peter1138> 15.28 16.30 4.94 956793 0.00 0.00 VehicleFromPos(unsigned int, void*, void* (*)(Vehicle*, void*))
07:27:11 <peter1138> 5.63 3.78 1.09 8817163 0.00 0.00 FindTrainCollideEnum(Vehicle*, void*)
07:27:34 <peter1138> 3.25 8.21 0.63 803832 0.00 0.00 VehicleFromPosXY(int, int, void*, void* (*)(Vehicle*, void*))
07:27:44 <peter1138> 0.88 15.16 0.17 152961 0.00 0.00 VehicleFromPos(unsigned int, void*, void* (*)(Vehicle*, void*))
07:28:38 <Phazorx> it is used alarmingly often
07:29:06 <peter1138> it's the hash lookup
07:29:36 <peter1138> in trun, VFP is used for collisions, signal updates, etc...
07:29:56 <peter1138> with the patch, VFPXY is used for collisions
07:30:00 <peter1138> VFP is used for the rest
07:30:12 <peter1138> VFP only checks one hash area
07:30:26 <peter1138> VFPXY will check 1 to 4 as necessary
07:30:28 <Phazorx> can you use stillunknown caching on top of that to reduce load even further tho?
07:30:48 <peter1138> i don't think it's worth it
07:31:00 <peter1138> not least because it has invalid assumptions
07:31:31 <peter1138> 6.93 18.54 2.24 1104000 0.00 0.00 TrainLocoHandler(Vehicle*, bool)
07:31:34 <peter1138> 4.85 4.72 0.94 803964 0.00 0.00 TrainController(Vehicle*, bool)
07:31:40 <peter1138> 13.89 2.69 2.69 1104000 0.00 0.00 TrainLocoHandler(Vehicle*, bool)
07:31:44 <Phazorx> well is any part of that data is static for tick and calculated for more than one vehicle?
07:32:18 <Phazorx> does it do that much extra ?
07:33:05 <peter1138> it has to set a flag to update signals, as the signal update routine relied on the vehicle not changing hash positions
07:35:22 <Phazorx> sort of got that one :)
07:35:42 <Phazorx> back to my question - cahing state of tracks is a good idea imho
07:36:15 <peter1138> it may not be necessary though, as now the lookup is much faster
07:36:31 <peter1138> and the caching processing was quite involved
07:36:52 <peter1138> so instead of caching something that's slow, it's caching something that's faster
07:37:00 <peter1138> i will try it though :p
07:41:51 <peter1138> hmm, the larger the hash resolution the less time spent in UpdateNewVehiclePosHash()
07:42:53 <Noldo> what is it that you are tweaking?
07:43:53 <peter1138> 3.09 19.54 1.00 16985534 0.00 0.00 SignalVehicleCheckProc(Vehicle*, void*)
07:44:01 <peter1138> 0.00 19.37 0.00 33876 0.00 0.00 SignalVehicleCheckProc(Vehicle*, void*)
07:52:27 *** Desolator has joined #openttd
07:52:48 *** Maedhros has joined #openttd
07:57:35 *** Nickman has joined #openttd
08:08:57 <peter1138> bah, i wish gaim supported msn's "free text" field
08:12:43 *** XeryusTC has joined #openttd
08:14:24 <peter1138> so i can keep in contact with people?
08:14:34 <peter1138> msn messenger, of course
08:37:55 *** Vikthor has joined #openttd
08:38:11 <Kjetil> peter1138: get them to use irc :P
08:39:56 <Biff> peter1138: what is the free text field?
08:40:53 <mikegrb> Biff: it is wherey you type to not get charged
09:39:51 *** TheJosh has joined #openttd
09:40:28 <TheJosh> i am having a problem doing a 'svn update': "svn: File 'src/texteff.cpp' has inconsistent newlines"
09:41:13 <CIA-1> OpenTTD: rubidium * r10109 /trunk/src/ (spritecache.cpp spritecache.h):
09:41:13 <CIA-1> OpenTTD: -Fix [FS#838]: some NewGRFs use the same (unused in the "current" climate)
09:41:13 <CIA-1> OpenTTD: sprite IDs. Normally this gives some artefacts, but when one NewGRF expects it
09:41:13 <CIA-1> OpenTTD: to be a sprite and another NewGRF overwrites it with a non-sprite nasty things
09:41:13 <CIA-1> OpenTTD: happen (drawing a non-sprite crashes OTTD).
09:41:24 <CIA-1> OpenTTD: maedhros * r10110 /trunk/src/newgrf.cpp: -Fix: Reset NewGRF errors along with all the other NewGRF data so that errors get loaded again when pressing "Apply".
10:54:09 <TrueBrain> [07:59] <stillunknown> Truebrain: How much faster is the rendering now? <- it in fact is a bit slower, but in return we get much more freedom :)
11:04:41 *** re06011988 has joined #openttd
11:06:58 <TheJosh> i have found rendering a tad better. when i ran Pile it went a tad faster
11:07:14 <TrueBrain> zoom-outs run faster
11:07:16 <TrueBrain> much faster in fact
11:07:19 <TheJosh> althouth turning off trees is still the best way to make Pile run well in my opinion
11:07:27 <TheJosh> yeah i noticed that as well
11:22:56 <CIA-1> OpenTTD: peter1138 * r10111 /trunk/src/ (roadveh_cmd.cpp train_cmd.cpp vehicle.cpp vehicle.h):
11:22:56 <CIA-1> OpenTTD: -Codechange: Add new vehicle hash table for collision detection and finding
11:22:56 <CIA-1> OpenTTD: vehicles on a tile. The hash area scanned is far smaller than the old hash
11:22:56 <CIA-1> OpenTTD: table, which is now used for viewport updates only. This should give a
11:22:56 <CIA-1> OpenTTD: significant performance improvement for games with many vehicles. (Based on work
11:22:57 <CIA-1> OpenTTD: by 'B. N. SmatZ!' and 'madman2003')
11:24:02 <TheJosh> what is "many vehicles"? Pile Transport?
11:24:33 <TheJosh> or would even 200 trains be considered 'many'?
11:24:48 <boekabart> TheJosh: many vehicles is so many vehicles that the game starts to slow down because of it
11:24:59 <boekabart> depends on map and hardware :)
11:25:33 <peter1138> it'll be faster even with only a few vehicles
11:25:39 <peter1138> but you won't notice it
11:25:44 <boekabart> hey, peter1138, how does the collision handling know not to collide with other cars in same train
11:25:47 <TheJosh> im gonna give pile a try
11:26:14 <boekabart> go to Engine and compare?
11:26:23 <boekabart> (isn't that also kind of slow?)
11:26:51 <TheJosh> wouldint it go to engine, looking at everything along the way, and then look at everything after itself?
11:27:00 <peter1138> boekabart: not really
11:27:03 <TheJosh> isnt a train a linked list?
11:27:21 <peter1138> boekabart: the first engine is cached, so you just test if a wagon's first vehicle is yourself
11:27:38 <boekabart> peter1138: maybe is (me = other->next || other = me->next) would be enough to prevent self colliding? or is 'looping' explicitly allowed...
11:27:55 <boekabart> boekabart: only engine is collision detected anyway?
11:28:21 <peter1138> boekabart: looping is explicitly allowed
11:28:42 <peter1138> it's really not that slow though
11:28:51 <TheJosh> Pile is running very smootly
11:28:51 <peter1138> the slow bit was the hash lookup, heh
11:29:05 <boekabart> no, if only engine checks vs others and others have a direct engine*, ok. nothing to gain at all
11:29:27 <peter1138> ah, that's why it's still slow
11:29:30 <peter1138> was still a profile build
11:30:20 <TheJosh> whats the default blitter?
11:52:38 <TheJosh> is the blitter code changes to allow for a 32bpp blitter in the future?
11:52:56 <peter1138> *cough* present *cough*
11:53:08 <peter1138> although it only draws 8bpp sprites at the moment
11:53:53 <peter1138> 12:26 < TheJosh> Pile is running very smootly
11:54:02 <TheJosh> i only see 8bpp optimised, debug and simple
11:54:15 <peter1138> yes, 32bpp is not in trunk
11:54:16 <TheJosh> peter1138: more smoothly, and my other large games are too
11:54:46 <TheJosh> is it much of an improvement? i guess you need 32bpp grfs to take advantage of it
11:55:57 <boekabart> hylje: not so duh, i can think of lots of improvements as soon as the buffer is 32bpp
11:56:56 <CIA-1> OpenTTD: celestar * r10112 /branches/gamebalance/ (193 files in 10 dirs): [gamebalance] -Sync: r9520:9620 from trunk
11:57:25 <TheJosh> will the 32bpp support opacity? thus allowing for semi-transperent gui objects, or chat messages/text effects to fade out?
11:58:43 <hylje> think we want hw accel for silly effects
11:59:30 <TheJosh> doesnt the display system (sdl) use hw acceleration?
11:59:34 <Eddi|zuHause2> hw accel is supposed to be on a different level of graphics driver
11:59:56 <TheJosh> just make the silly effects a patch option for those of us with good cpus
12:00:48 <TheJosh> i can see it now: "[ x ] enable silly effects: on"
12:02:35 <peter1138> what would be nice is a (2D) opengl renderer
12:03:09 <TheJosh> another video device (instead of sdl?)
12:07:57 *** NukeBuster has joined #openttd
12:09:08 <Nickman> peter1138: you want a 2D openGL renderer? or are you gonna make one? :)
12:11:16 <Nickman> Well, some friends and I are planning on making something like that ;)
12:11:25 <peter1138> it is "possible" now
12:11:33 <Nickman> Were gonna start this summer with a project of our own
12:11:48 <Nickman> you just have to make another blitter?
12:12:50 <Nickman> To make the OpenGL renderer, do you just need to make another blitteR? or is it somewhat more complicated? :p
12:14:24 <peter1138> needs a bit more than a blitter, yeah
12:14:33 <peter1138> GL_EXT_paletted_texture
12:14:37 <peter1138> Future NVIDIA GPU designs will no longer support paletted textures.
12:14:56 <peter1138> thinking everything needs to go 32bpp
12:16:13 <Eddi|zuHause2> probably they think everything else is old enough to not need to be accelerated
12:16:38 <peter1138> it might've been handy for things like palette animation...
12:16:43 <peter1138> might still be, i suppose
12:17:16 <hylje> well with gpu acceleration you can do full-blown animation
12:18:08 <Eddi|zuHause2> the problem is converting the old animation system to the new one
12:18:18 <Eddi|zuHause2> which might not be trivial
12:19:14 <Eddi|zuHause2> i loved the palette animation in civ 1
12:19:26 <Eddi|zuHause2> shame civ 2 lost that feature
12:28:04 <CIA-1> OpenTTD: peter1138 * r10113 /trunk/src/ (10 files in 2 dirs): -Fix (r10092): Missing svn properties and some Id/@file comments
12:28:30 <Nickman> peter1138: are there any plans to start an openGL renderer?
12:29:08 <Nickman> Well, if a branch starts, i'd be happy to try and help ;)
12:39:50 <hylje> heh my gpu starts heating up when running ottd
12:42:04 <TheJosh> hey whats the proper process for a bug being fixed? i have just fixed a small bug, and added the patch to flyspray. is that all I have to do?
12:42:31 <boekabart> add it as a BUG in flyspray though, not a patch.
12:42:54 <boekabart> (so make report type Bug, and attach your Patch as suggested solution)
12:42:58 <TheJosh> no I added the patch as a comment to an existing bug
12:43:12 <TrueBrain> TheJosh: we noticed that you added the patch, and someone will look at it now :)
12:43:37 <TheJosh> do people get emails when stuff happens?
12:46:10 <TheJosh> everyone have a good night/day
12:46:13 <TrueBrain> have a good night sleep
12:46:24 <TheJosh> i hope that patch is of some use
12:47:17 <boekabart> hm, the code duplication could have been less in that patch
12:47:37 <boekabart> plus, on *nix, all of those except / are allowed, right?
12:48:11 <Eddi|zuHause2> i'd not be surprised if even / was allowed
12:48:51 <boekabart> Eddi|zuHause2: no, i just tried, not allowed
13:22:27 <CIA-1> OpenTTD: maedhros * r10114 /trunk/src/ (6 files):
13:22:27 <CIA-1> OpenTTD: -Fix: Only load newgrf error messages if the language matches the current
13:22:27 <CIA-1> OpenTTD: language. Since only one error can be loaded anyway, if the language didn't
13:22:27 <CIA-1> OpenTTD: match you'd get "Undefined string". Also since we're only loading one language
13:22:27 <CIA-1> OpenTTD: there's no need to use AddGRFString any more.
13:25:54 <Biff> unless you hack the filesystem :p
13:30:32 <TrueBrain> I like this blitter-layer: null dirver finally really doesn't draw anything to the screen
13:30:39 <TrueBrain> neither does the dedicated server (in my local working copy that is)
13:30:48 <TrueBrain> poor Briannetta, no more dedicated server screenshots :p
13:41:09 <peter1138> still wastes time doing sprite sorting
13:52:21 <TrueBrain> so there, dedicated servers can still assign a blitter if they like :p
13:55:58 <Nickman> :D, Briannetta will be pleased ;)
14:05:35 <kaan> Is there any reason that improved loading algorithm is for trains only?
14:07:27 <kaan> hmmm,. now i cant find the patch setting :P
14:07:44 <kaan> disregard me until i get control of myself please :D
14:08:56 <kaan> there, well what do you know, it *was* turned off ;)
14:09:21 <TrueBrain> then it mostly doesn't work, no
14:09:27 <TrueBrain> dunno why, but that always happens
14:09:32 <TrueBrain> when you disable something, it doesn't work!
14:09:53 <Nickman> hehe :D, it's not a bug, it's a real feature!
14:10:07 <kaan> maybe someone that isnt as stupid as i am today will make a bugreport :P
14:12:18 <kaan> "Dear dev team, the game is working as intended! Please take action immidiately."
14:18:14 <Eddi|zuHause2> what was that report? "Error: Download is much faster than upload. PS: only happens on ADSL connections"
14:22:51 <CIA-1> OpenTTD: belugas * r10115 /trunk/src/industry_map.h:
14:22:51 <CIA-1> OpenTTD: -Codechange: Create accessors to triggers and random bits for industries.
14:22:51 <CIA-1> OpenTTD: Implementation will follow soon.
14:38:42 *** Aerandir has joined #openttd
14:48:26 *** boekabart has joined #openttd
14:55:36 *** UndernotBuilder has joined #openttd
14:58:30 *** Osai^2 is now known as Osai
15:07:17 <stillunknown> peter1138: there was no performance increase in seperating the viewport and normal hashmap?
15:09:12 <stillunknown> peter1138: Please make more sense?
15:09:23 <peter1138> you said there was no performance increase
15:09:28 *** Progman has joined #openttd
15:09:41 <stillunknown> When did i say that?
15:09:49 <peter1138> 16:04 < stillunknown> peter1138: there was no performance increase in seperating the viewport and normal hashmap?
15:10:11 <stillunknown> since i looked at the diffstat
15:10:14 <peter1138> no "there was" is a statement
15:10:18 <peter1138> "was there" is a question
15:10:36 <stillunknown> Sorry for confusion.
15:10:40 <peter1138> besides, it doesn't make sense as the hashes as separated
15:11:17 <stillunknown> They are seperated. how?
15:11:54 <stillunknown> correction: How are they seperated?
15:12:05 <peter1138> there are... two of them
15:13:25 <peter1138> hmm, variable names suck though. never mind :p
15:14:36 <stillunknown> You let the old one exist for the viewport?
15:15:03 <peter1138> it's not a bottle neck for rendering, so i didn't touch it
15:15:12 <stillunknown> Maybe the names should reflect the viewport.
15:15:17 <peter1138> probably it could be optimized, but some other time
15:19:22 <stillunknown> peter1138: You should also consider looking at a replacement for "realistic" acceleration, since it's quite hungry for what it does.
15:21:55 *** RamboRonny has joined #openttd
15:22:07 <peter1138> trunk is profiling from before the patch
15:22:24 <peter1138> 7-0b is profiling with the chosen hash values (i.e. trunk now)
15:22:49 <stillunknown> You used some huge scenario for that ;-)
15:22:50 <peter1138> i really need some kind of averaging profiler, though
15:23:15 <TrueBrain> exactly the same amount of ticks, nice ;)
15:23:24 <peter1138> TrueBrain: strange that :p
15:24:14 <stillunknown> peter1138: results like nice
15:24:19 <peter1138> now TrainLocoHandler sucks ;(
15:24:54 <TrueBrain> lol, the blitter is rather fast :p Haha :)
15:25:26 <peter1138> i'd scrolled to the top of the map so there was nothing going on
15:25:37 <TrueBrain> it wasn't with -vnull?
15:25:55 <TrueBrain> ah, yes :p Then blittering already is very low :p
15:25:59 <TrueBrain> with my patch even less :p
15:26:31 <stillunknown> peter1138: I just hope that optimizations continue.
15:26:57 <stillunknown> Fortunately there will always be the next biggest cpu consumer.
15:27:08 <peter1138> well TrueBrain is doing a tremendous job with blitting and rendering
15:27:20 <TrueBrain> but not really optimizations :p
15:35:37 <stillunknown> I know just the thing to make TrainLocoHandler look good.
15:35:44 <stillunknown> Using 50-100 ships ;-)
15:36:36 <stillunknown> Ships are extremely expensive, at least for pathfinding.
15:37:17 <stillunknown> expensive == use a lot of cpu power
15:42:43 <stillunknown> Have you looked at this simplified acceleration patch on the forum?
15:45:56 <Noldo> ships just have a bit more options
15:46:49 <CIA-1> OpenTTD: rubidium * r10116 /trunk/src/ (fileio.cpp fileio.h misc_gui.cpp screenshot.cpp): -Fix [FS#850]: remove invalid characters (for the file system) from savegame names. Based on a patch by TheJosh.
15:48:17 <stillunknown> peter1138: is it any good?
15:48:28 <Noldo> We visioned with someone about making kind of rails to ships from those b-things
15:51:22 *** Progman has joined #openttd
15:51:37 <Rubidium> Noldo: problems arise when people don't use buoys, so making "rails" between buoys doesn't solve the issue
15:51:55 <UndernotBuilder> what about using the trams topic as an general announcements one?
15:52:17 <Noldo> Rubidium: too bad for them, ships won't find their way
15:52:40 <Biff> do the ship algo use A*?
15:58:26 *** Progman has joined #openttd
16:03:13 *** Prof_Frink has joined #openttd
16:17:39 <Eddi|zuHause2> hm, the bad weather arrived here...
16:45:37 <stillunknown> It's at a low resolution.
16:46:15 <stillunknown> One of the fields is bounded by stones.
16:46:33 <Eddi|zuHause2> do i win if i say "nothing"? :p
16:46:51 <Eddi|zuHause2> i'd expect something about a new (32bpp?) blitter
16:47:01 <stillunknown> It's made with the new blitting code?
16:47:40 <stillunknown> But that's not special ;-)
16:48:09 *** Hendikins has joined #openttd
16:48:14 <glx> Eddi|zuHause2 said something :)
16:49:03 *** ChanServ sets mode: +o Bjarni
16:49:32 <Eddi|zuHause2> you kinda get that idea if you follow the "art#" series :)
16:49:49 <TrueBrain> I like my art series :)
16:49:57 * TrueBrain slips Eddi|zuHause2 a cookie: www.amazon.com
16:50:02 <Eddi|zuHause2> it's definitely great :)
16:50:36 <stillunknown> Is 32bpp still moving forward?
16:50:51 <UndernotBuilder> there is a new tree
16:51:06 <Eddi|zuHause2> stillunknown does not see the forest because those trees are in the way...
16:51:56 <UndernotBuilder> oh, and what do you mean with 'blitting code'?
16:52:15 <Eddi|zuHause2> the code that does blitting?
16:53:03 <Eddi|zuHause2> i'd try the files in the "blitter" directory :)
16:53:49 <UndernotBuilder> there is no "blitter" directory in my r10067
16:54:11 <glx> UndernotBuilder: latest is r 10116
16:54:46 <Belugas> blitter is a technical term that describe the code/object responsible of painting the pixels
16:55:30 <UndernotBuilder> nope latest is r10104
16:55:43 <peter1138> nope latest is r10116
16:56:12 <Eddi|zuHause2> UndernotBuilder: the blitter directory was introduced in r10092
16:56:59 <Eddi|zuHause2> "Aktualisiert zu Revision 10116."
16:58:17 <UndernotBuilder> well, in one hour there will be r10116 in the nightlies page
16:59:07 <Eddi|zuHause2> not if there are more commits till then :)
17:01:51 <Wolf01> i tried articulated vehicles, they have some glitches but they are really cool :D
17:02:06 <Eddi|zuHause2> what kind of glitches?
17:02:35 <Phazorx> stillunknown: is thre anything you know of that would prevent a save amde in 10048M (with your patch) to load in any other version?
17:02:37 <XeryusTC> Wolf01: i got a game where an artic part ran into a house! :P
17:03:03 <Wolf01> Eddi|zuHause2 sometimes the central wagon "disappear" because it is under the tail car
17:03:50 <Wolf01> and the tail car is always not aligned with the first and the second, which seem to be perfectly aligned
17:04:22 <peter1138> sounds more like dodgy sprite offsets to me
17:08:11 <XeryusTC> Wolf01: that happens when you use the hiroshima tram set
17:08:21 <XeryusTC> i know of that set that it has some odd offsets
17:09:23 <Wolf01> is the only set which has articulated vehicles, isn't it?
17:09:33 <XeryusTC> that set has some sprite offsets that are not entirely correct
17:09:38 <XeryusTC> afaik it does indeed
17:10:56 <Wolf01> i hope for a serbian tram set update with arv
17:11:12 <CIA-1> OpenTTD: maedhros * r10117 /trunk/src/economy.cpp:
17:11:12 <CIA-1> OpenTTD: -Fix [FS#863]: When deleting the vehicles of bankrupt players, delete trains as
17:11:12 <CIA-1> OpenTTD: a whole rather than each part individually, as that leads to invalid tests on
17:11:12 <CIA-1> OpenTTD: parts that have already been deleted.
17:12:02 *** re06011988 has joined #openttd
17:14:47 <stillunknown> Phazorx: yes, probably
17:15:21 <stillunknown> It's larger and has a newer revision than openttd expects.
17:17:34 <Phazorx> stillunknown: i'm very interested in somehow fixing that
17:17:55 <Phazorx> since i have developd on that build
17:17:58 <Phazorx> something rather large
17:18:16 <Phazorx> but i want to be able to load it on other versions as well for testing purposes
17:18:45 <XeryusTC> stillunknown: you save the cache to the savegame?
17:19:14 <Bjarni> I say you should use a clean build and modify it to load the savegame in question and clear the cache and then save it as a normal savegame
17:19:18 <stillunknown> XeryusTC: no, an extra variable was added, if the train was crossing itself or not
17:19:44 <Phazorx> Bjarni: no builds i have can load any of saves made with 10048M
17:19:44 <stillunknown> the cache was stored in the map
17:20:14 <Bjarni> Phazorx: it should be made. Nobody coded anything to solve this issue
17:20:22 <stillunknown> You would need to modify to undo the changes, then somehow fake it into lowering the version number.
17:20:26 <UndernotBuilder> for when a new feature for openttd? :(
17:22:00 <Phazorx> stillunknown: modify to undo the changes?
17:23:42 <stillunknown> Phazorx: Your savegame is larger than the usual savegame, it needs to be loaded by a version which shrinks it back to the usual size.
17:24:01 <Phazorx> stillunknown: would you happen to have that version ?
17:24:20 <Phazorx> cuz i have about dozen differen bulds and most of them can not load that
17:24:39 <stillunknown> At the moment i can't help you with this, when i have time i will see if i write some code to undo this.
17:24:53 <stillunknown> (i will ask for the savegame then)
17:25:08 <Phazorx> is it possible to patch the save to make other builds to belive it is okay to load?
17:26:55 <stillunknown> Phazorx: i hope it's possible to fake the savegame into an older version, i have no experience with this however
17:27:28 <Eddi|zuHause2> the easiest solution would be to cut out all changes other the savegame changes from the patch
17:27:36 <Eddi|zuHause2> and then compare the two changed versions
17:27:59 <stillunknown> The version needs to be reduced as well.
17:28:10 <Phazorx> my idea was - pausing sometihng
17:28:18 <Phazorx> loading with vanilla 48 and 48m
17:28:39 <Phazorx> then patching 48 save with 48m differences
17:28:48 <Eddi|zuHause2> no, i mean if he wants to just compare the behaviour, he can just modify the normal build to load the newer version, not change the version back
17:28:53 <Phazorx> and if that works - apply same idea to the save i want to use
17:29:15 <Phazorx> Eddi|zuHause2: i'd like to be able to use thats ave game in general
17:29:35 <Eddi|zuHause2> that's gonna be much more problematic, Phazorx
17:30:05 <Eddi|zuHause2> as the savegame versioning is not supposed to handle that case
17:31:55 *** thgergo has joined #openttd
17:32:15 <Phazorx> so i take it code modification is necessary to be able to resave the game
17:32:40 <Phazorx> is it just the bump of save version which eneds to be dealt with of there is more?
17:32:54 <Rubidium> OpenTTD's savegames are backward compatible, not forward compatible
17:33:14 <Phazorx> i'm trying to load the save in newever version
17:33:34 <stillunknown> In a way, that version was "newer".
17:33:35 <Eddi|zuHause2> no, the modificated build is "newer" than the umodificated build
17:34:01 <Phazorx> 1M is newer than 9999 ?
17:34:15 <Rubidium> Phazorx: not necessarily
17:34:35 <Eddi|zuHause2> Phazorx: not if the change made in 1M was merged back to trunk later
17:34:55 <Phazorx> change is not in truck for sure
17:34:56 <Rubidium> for example a savegame made with trunk r10001 won't load in 0.5-r10083, even though the svn revision number is higher for 0.5
17:35:06 <Phazorx> however i dont get how tracking of that is done in code asuide of numbers
17:35:28 <Phazorx> Rubidium: different trees
17:35:42 <Phazorx> my case is same tree different branches i guess
17:35:44 <XeryusTC> Phazorx: there's a save version number in saveload.[hcpp] IIRC
17:36:02 <Rubidium> Phazorx: so, applying stillunknowns patch made you "go" on a different tree too
17:36:03 * Phazorx goes to fetch buildttd
17:36:35 <Phazorx> Rubidium: at this stage i want to be able just to fake it so i can load the game somewhere
17:37:01 <Phazorx> and btw EvsL widely used for trsing now is smade with modifed code as well
17:37:11 <Phazorx> it has copy/paste patch on top of that
17:37:18 <Phazorx> but loads just fine everywhere :/
17:37:26 <Rubidium> uhm, and in English?
17:38:01 <Phazorx> ughm... this was badly spelled english but i think it's comprehendable :)
17:38:26 <Eddi|zuHause2> Phazorx: try removing all files from stillunknown's patch except saveload.*, and apply this modified patch to a clean build
17:38:39 <Rubidium> Eddi|zuHause2: won't work
17:38:48 <glx> Phazorx: I think copy/paste doesn't touch saveload code
17:38:49 <Phazorx> Eddi|zuHause2: i tihnk i need reverse of that
17:39:10 <Rubidium> the problem is that Phazorx's vehicle savegame chunck isn't the right size for trunk
17:39:12 <Phazorx> glx but it is modded copraed to regular
17:39:24 <Phazorx> different branch just like stillunknowns
17:39:46 <Phazorx> glx, i'm trying to figure out what needs to get changed to convert save into somethingf eatable for other versions
17:40:01 <glx> remove the savegame changes
17:40:06 <Phazorx> Rubidium: is that confirmed?
17:40:16 <Rubidium> where are EvsL and trs defined?
17:40:37 <Phazorx> Rubidium: "Express vs Local"
17:41:24 <Phazorx> peter1138 used that one for testing as well as sltillunknown himself
17:41:37 <Phazorx> it's has lots of tracks and closely packed trains
17:41:57 <Phazorx> and shows benefit of both caching and hash optimization
17:42:18 <Phazorx> later in my case improves performance close to 10 times
17:42:28 <Arc> Hmmm... What's the name of the guy that's responsible for the Webtranslator?
17:42:30 *** Arc is now known as Giddorah
17:42:59 <Eddi|zuHause2> i thought we have a "contact" page for that
17:43:41 <Rubidium> Phazorx: I think you're going to have troubles because OpenTTD's savegame version isn't high enough to "easily" hack your savegame into something OTTD-trunk accepts
17:44:00 <Phazorx> Rubidium: explain please?
17:44:46 <Eddi|zuHause2> Phazorx: trunk has a savegame version of 64, stillunknown's patch has 65 (probably)
17:45:02 <Eddi|zuHause2> in order to mere back the changes, trunk must reach a savegame version of 66
17:45:10 <Phazorx> Eddi|zuHause2: that sounds liek constant soemwhere in *.h
17:45:36 <Eddi|zuHause2> yes. in saveload.cpp
17:45:39 <Rubidium> if OTTD-trunk's savegame version would've been 66 (and stillunknown's savegame 65), you could just say that it should load those bits stillunknown added for only savegame version 65 and it would load in a (slightly) modified trunk, you could save it and it would load in trunk
17:46:07 <Rubidium> but now you have to remove the bits and set the version number of OpenTTD back, which is something the saveload system isn't designed for, so I expect it to blow
17:46:12 <Phazorx> so if i mod same 48M not to bumo save - it shoudl be able to save game w/o it goign to 65
17:46:44 <Giddorah> Anyone else on the translation-staff know if there's been some kind of update to the webtranslator during the last couple of days?
17:46:46 <Eddi|zuHause2> but once a savegame got version 65, you cannot save it back to 64, as all ottd versions (modified or unmodified) always save as the newest version
17:46:46 <Rubidium> no, then you won't be able to load the savegame
17:47:23 <Eddi|zuHause2> you now need to "hack" saving to save as the older version, without affecting loading
17:47:35 <Eddi|zuHause2> which will most likely fail
17:47:37 <Phazorx> Eddi|zuHause2: hardcoding then :)
17:47:45 <Rubidium> Giddorah: what's not working/bothering you with respect to the translator?
17:49:07 <Giddorah> Rubidium: My language has fallen behind 33 lines of code... So I was about to fix these... But when I click "Next Page" it still shows the last 10 or 15 lines that was already present on the last page I was on... (Hmmm)
17:50:11 <Rubidium> so when click on "next page" it still shows the strings of the first page?
17:50:32 <Phazorx> stillunknown: hmm.. tough questio now where can i get your patch version used for 10048 ?
17:50:38 <Giddorah> That was a much easier way to put it... Hehe :)
17:51:03 <Rubidium> is there some "last page" button (don't have access to WT2 myself)
17:51:43 <stillunknown> Phazorx: ottd development forum
17:51:50 <Giddorah> Rubidium: Yes. Same there. It says I've changed page (It says for example 200 / 3000, I click next -> 201 /3000) but the lines never change.
17:51:58 <Giddorah> Rubidium: It has never acted this way before
17:52:05 <Giddorah> Rubidium: And I've been translating for months.
17:52:05 <Phazorx> stillunknown: i see 10075 there
17:52:21 <Phazorx> and you are evil: if (CheckSavegameVersion(65)) {
17:52:57 <Rubidium> Giddorah: that's something MiHaMiX has to look at then (I think he has fixed some bug this week, maybe it caused this)
17:53:22 <Giddorah> Rubidium: Okay, thanks anyways! I will have a look with him as soon as he gets back :)
17:53:49 <Giddorah> Hmmm... Weird... Now it started working
17:55:11 <Rubidium> "It's a kind of magic" :)
17:55:11 <Giddorah> "31 bad strings, 31 strings pending, 4 translators assigned" <--- Todays work is done :) Thanks for the help Rubidium :)
17:55:35 <Eddi|zuHause2> Phazorx: that's how it always was done
17:55:42 <Giddorah> There's no "anti-idling" rule in the channel is there? :S
17:56:17 <Eddi|zuHause2> Phazorx: because backwards compatibility dictates that once someone introduces that change, it is not reverted anymore
17:56:22 <hylje> you can idle just fine for years
17:56:34 <Eddi|zuHause2> so these lines are never changed again
17:56:57 <Phazorx> Eddi|zuHause2: assuming ti gets trunked that works
17:57:23 <Phazorx> but if there will be another patch, modififying save content independantly and save is made with bumop
17:57:30 *** boekabar1 has joined #openttd
17:57:37 <Eddi|zuHause2> Phazorx: backwards compatibility is only defined along the same tree branch
17:57:43 <Phazorx> version patched with this will asuume that changes there are it's own
17:57:54 <Phazorx> hmm.. actualy that makes sense
17:58:00 *** boekabar1 is now known as boekabart
17:58:10 <Eddi|zuHause2> trunk is never defined to be backwards compatible to any patch... if it is, that is pure coincidence
17:59:58 <Eddi|zuHause2> trunk is defined to be backwards compatible to all release versions, and in most cases also previous trunk versions
18:00:47 <Eddi|zuHause2> and you want to mess with this compatibility tree
18:01:02 <Phazorx> i want to be able to load save anywhere else
18:01:16 <Phazorx> and save w/o changes made by the patch
18:01:19 <Rubidium> Phazorx: that is like requesting trunk savegames to load in 0.5.2
18:01:45 *** re06011988 has left #openttd
18:01:52 *** KritiK_ has joined #openttd
18:02:14 <Phazorx> Rubidium: sort of, however what i plant o do is load it in vanilla 48
18:02:23 <Phazorx> and "uncorrupt" it that way
18:02:30 <CIA-1> OpenTTD: glx * r10118 /branches/noai/ (111 files in 12 dirs): [NoAI] -Sync with trunk r10015:r10096
18:02:44 <Phazorx> i assume after that it'll be possible to load it anywhere
18:02:54 <Phazorx> meaning in any following builds
18:03:13 <Rubidium> Phazorx: when you get it that far that it loads in (vanilla) r10048, it'll work in later trunk versions too
18:04:10 <Phazorx> Rubidium: ithat is base assumption i made
18:04:22 <Phazorx> however that aproch IMO is alos safest from sanity point of view
18:04:46 <Phazorx> however i guess what needs to be done is 3 step process
18:04:56 <Giddorah> Hmm... Since I'm here :) May I bother the dev-team for a few questions? :)
18:05:00 <Phazorx> 48M with save change to 48M with no save change
18:05:43 *** KritiK_ is now known as KritiK
18:06:13 <Bjarni> <Giddorah> Hmm... Since I'm here :) May I bother the dev-team for a few questions? :) <--- it depends on the questions
18:06:30 <Bjarni> the meaning of life is 42
18:06:32 <Giddorah> Bjarni: For a non-initiated... What is the easiest way to follow the current developement? :)
18:06:39 <Bjarni> now I answered your first question ;)
18:06:42 <Giddorah> Bjarni: Oh see... I already know that :)
18:07:26 *** Digitalfox_ has joined #openttd
18:07:35 <Giddorah> Bjarni: Oh no... Not what has been done, but where the developement is currently focusing at :)
18:07:45 <UndernotBuilder> the train collision patch is now in trunk?
18:07:51 <Belugas> exactly the same, Giddorah :)
18:08:01 <Belugas> unless you could read our mind ;)
18:08:02 <UndernotBuilder> r10111 tells so
18:08:20 <hylje> only a mere thousand to 11111
18:08:31 * Belugas can hardly read his own mind, sometimes...
18:08:33 * Giddorah do feel a craving for hotdogs coming from Belugas mind.
18:08:34 <Bjarni> developers has a nasty habit of not telling what half working patches they have and sometimes nobody are told until they are committed
18:08:59 <Eddi|zuHause2> UndernotBuilder: one of the many approaches of faster collision detecting is in trunk now
18:09:10 <Belugas> no hotdogs from my mind, believe me :D
18:09:24 <Giddorah> Is there a "controlled" developement going on... Or is it just "Pick and Fix"?
18:09:30 <Bjarni> Belugas has boobs on his mind
18:09:52 <Eddi|zuHause2> hylje: next binary revision is 11000
18:10:01 <hylje> Eddi|zuHause2: unrelated :p
18:10:15 <hylje> 11111 is just an amusing row of numbers
18:10:28 <CIA-1> OpenTTD: miham * r10119 /trunk/src/lang/ (7 files): (log message trimmed)
18:10:28 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2007-06-12 20:09:56
18:10:28 <CIA-1> OpenTTD: bulgarian - 1 fixed by thetitan (1)
18:10:28 <CIA-1> OpenTTD: estonian - 23 changed by kristjans (23)
18:10:28 <CIA-1> OpenTTD: italian - 2 fixed by lorenzodv (2)
18:10:29 <CIA-1> OpenTTD: korean - 2 fixed by darkttd (2)
18:10:29 <CIA-1> OpenTTD: romanian - 28 fixed, 59 changed by CrystyB (87)
18:10:48 <Bjarni> Giddorah: partly both... there is the big picture, but we aren't really keeping it as "the things to do"... sometimes something else shows up that's more interesting to code
18:11:09 * Bjarni throws the ball to MiHaMiX
18:11:45 <Giddorah> Awww! It trimmed my update :'(
18:12:02 <Rubidium> MiHaMiX: Giddorah had a WT2 problem that magically disappeared
18:12:08 <hylje> serves you right for having a language name far in the alphabet
18:12:09 <Giddorah> Bjarni: Interesting :) What is the "big picture" at the moment? :)
18:12:17 <Giddorah> Rubidium: I'm talking to him through PM :)
18:13:17 <Bjarni> the big picture is world domination, but that's a secret
18:13:49 <Bjarni> read the roadmap on the wiki
18:13:55 <peter1138> as usual the idiots involved in world domination tell all their secrets
18:14:35 <Giddorah> Yeah... I'm loving it how the bad guy in all the Bond movies always manage to tell all of their secrets like on a tea-party... But never manages to harm Bond
18:15:49 <Giddorah> However, back to the basics :) Is there a way to compare the Trunk to the current stables?
18:16:26 <boekabart> svn diff svn://svn.openttd.org/trunk svn://svn.openttd.org/tags/0.5.2
18:16:33 <Giddorah> I was more thinking of... What "rev" of the trunk is the current stable made out of? :P
18:16:38 <Giddorah> I can't handle svn's :P
18:16:48 <hylje> stables arent trunk snapshots
18:16:51 <boekabart> Giddorah: 7000-something i think
18:16:57 <Eddi|zuHause2> it is not based on a trunk revision
18:17:11 <Eddi|zuHause2> 0.5 branch was split from trunk a while ago
18:17:19 <Eddi|zuHause2> somewhere before christmas
18:17:20 <hylje> you have a stable branch which gets patches back from trunk
18:17:31 <Bjarni> and then we fixed bugs in it to make it really stable
18:17:35 <Eddi|zuHause2> then there were done backports
18:17:39 <Bjarni> hence the "stable" thingie
18:17:52 <Giddorah> Wait... Haha... 3 people telling the story with 3 different approaches :P
18:17:53 <Rubidium> r7535 + a big load of bugfixes and a few small features
18:18:29 <hylje> Giddorah: well at least you get a comprehensive picture
18:18:44 <Eddi|zuHause2> just get the svn log of trunk, and the svn log of branches/0.5, then cut out the doubles
18:18:46 <Rubidium> Giddorah: still doesn't tell much about what is in 0.5.2
18:18:55 <Giddorah> Yeah :) Very comprehensive, but I appreciate the effort and the patience :)
18:19:36 *** Digitalfox has joined #openttd
18:19:57 <Giddorah> So... Another question for the developer/initiated people :) What achievement would you like to reach next :)
18:20:19 <boekabart> Giddorah: see 0.6 roadmap on wiki
18:20:59 <Giddorah> boekabart: I know :) But there should be this certain something that everyone would like to just get over with a second ago :)
18:22:00 <Giddorah> Heh... I hardly ever run into any bugs :)
18:22:06 <Belugas> full newgrf compatibilty
18:22:20 <Bjarni> we already worked hard on the "no bugs" idea
18:22:22 <Giddorah> Bugfreeness/Full newGRF :)
18:22:48 <DorpsGek> TrueBrain: Open Bugs: 39; Not assigned: 25; Closed this week: 29; Opened this week: 26
18:22:52 <TrueBrain> sadly enough there are still a few :)
18:22:59 <TrueBrain> (although it has been a rather busy week)
18:23:09 <Bjarni> we closed more than we opened
18:23:20 <TrueBrain> can change any minute :p
18:23:39 <Giddorah> Bjarni: What's the most important thing you'd like to be done right now? :)
18:23:42 *** boekabart has left #openttd
18:23:43 <Bjarni> the path patch can be finished and I can close like 4 bugs assigned to me
18:24:02 * Bjarni mumbles something about a n00b shield
18:24:11 <TrueBrain> Giddorah: you are looking for something to code, or?
18:24:15 <Bjarni> err... I mean I want full newGRF support
18:24:38 <Noldo> I have always privately wanted to play openttd with dfsg-free graphics
18:24:42 <Giddorah> TrueLight: I wish I was capable of coding :( I'm just curious what's happening, where it's happening and who's doing what atm :)
18:24:57 <TrueBrain> I don't see any TrueLight here, but okay ;)
18:25:07 * Rubidium is browsing the forum ;)
18:25:12 <Bjarni> TrueBrain: you don't see the light
18:25:21 * Touqen was blinded by the light
18:25:22 <Maedhros> debian free software guidelines, i think
18:25:22 * TrueBrain is coding a blitter
18:25:23 <hylje> Bjarni: hence he's not TrueLight no more
18:25:51 <Phazorx> hmm... this is not good
18:25:55 <Giddorah> A complete standalone would own... With a completely freely distributed graphics :)
18:26:02 <Bjarni> <hylje> Bjarni: hence he's not TrueLight no more <-- he sits in the dark?
18:26:03 <Noldo> I have faith in coders doing anything they want given enough time
18:26:09 <Phazorx> 75 + patch can not load save from 48 + ptach :(
18:26:10 <Bjarni> I don't see any TrueDark either
18:26:18 <Bjarni> maybe my nightvision is borked though
18:26:27 <Wolf01> kaan, one of the members of my community had a problem with buildottd, it worked, but the ottd binary failed to work (strange error like "assert function: 0"), he resolved by reinstalling the .net 2.0
18:26:59 <TrueBrain> I love nightlies :)
18:27:22 <Bjarni> you do them on a daily basis
18:27:32 <TrueBrain> I don't do anything :p
18:27:36 <TrueBrain> but the latest just finished :)
18:27:59 <Eddi|zuHause2> i think the brain/light issue is related to "man of science, man of faith" :p
18:28:04 <TrueBrain> scripts I excidently wrote do it, yes
18:28:32 <Bjarni> TrueBrain used to be a man of faith?
18:28:49 <Eddi|zuHause2> no, but truelight maybe :)
18:28:53 <Bjarni> that's why you look into the sky for answers
18:29:25 <Bjarni> you stopped studying astronomy?
18:29:31 <Wolf01> when you want to apply invisible houses to trunk?
18:30:16 <Bjarni> too few jobs in other solar systems?
18:30:55 <Giddorah> How is work on the newGRF-support going btw?
18:31:01 <kaan> Wolf01: are you sure he had .NET 2.0 at all to begin with? maybe he had 1.1?
18:31:24 <TrueBrain> Giddorah: slowly, but growing
18:31:45 <Wolf01> he said "reinstalled", i don't have clue to know if he is a believer or not
18:32:20 <Phazorx> kaan got a question for you
18:32:45 <Giddorah> TrueBrain: Good to hear :) peter1138 working on it alone nowadays?
18:32:49 <kaan> Wolf01: oh well, even if a reinstall helped somehow then it wasnt bottd that had the problem to begin with
18:33:11 <TrueBrain> Giddorah: no, Maedhros and Belugas are doing a nice job on it too
18:33:36 <Wolf01> TrueBrain is now working on the psychostory, to foretell the future :O (he already knows how OTTD1.0 will be)
18:33:53 <TrueBrain> nah, I like being suprised
18:34:19 <Belugas> surprised, aren't you ?
18:34:44 <Bjarni> TrueBrain: do you have agoraphobia?
18:35:06 <Bjarni> because that would explain why you quitted astronomy
18:35:17 <TrueBrain> !whatis agoraphobia
18:35:41 <Bjarni> TrueBrain: "fear of open spaces"
18:35:49 <TrueBrain> I think I put Bjarni on ignore for now
18:36:27 <Bjarni> damn, that backfired :(
18:36:57 <Bjarni> backfired, but still funny :)
18:37:18 *** bubersson has joined #openttd
18:38:25 <Bjarni> well, TrueBrain claimed that he likes being surprised and I'm pretty sure he didn't expect that question from me
18:39:37 <Giddorah> Bjarni: Got that right :)
18:42:51 <Giddorah> When I'm looking at "In Development" on the NewGRF-part of the Wiki, it says only "Industries". Everything else is on "Working already".
18:43:01 <Giddorah> Does that mean that the newgrf-support is almost completed?
18:43:38 <UndernotBuilder> why there isn't dedicated server win32 packages?
18:43:59 <Belugas> Giddorah : it is still "In Development"
18:44:06 <Belugas> for once, the wiki is right :S
18:44:35 <Wolf01> we need shore corners!
18:45:03 <UndernotBuilder> Wolf01: code it :D
18:45:17 <Wolf01> i'm the last one who can do it
18:45:28 <Belugas> Wolf01, you dont NEED shore corners, you WANT shore corners ;
18:45:47 *** |Jeroen| has joined #openttd
18:45:53 <Belugas> don't underestimate your capacity, young man
18:47:10 <Belugas> sometimes, i take what's on my mind without translating, expecting it to be already rendered in english ;)
18:47:49 <Digitalfox> Wolf01: We have to get some money to bribe this guys, so then they will code shore corners ;)
18:48:15 <Giddorah> Belugas: It's interesting that you think in another language than your native one
18:48:55 <Belugas> english is not my native language
18:48:58 <Wolf01> if you apply my patches and code what i want, i'll become the official pocket pc maintainer :P
18:49:29 <Belugas> and yes, most of the time, i think in english while talking in irc
18:50:01 <Eddi|zuHause2> yeah, i try to think in english also when speaking english
18:50:10 <Eddi|zuHause2> it does not always work...
18:50:15 * Maedhros doesn't know enough of any other language to think in :/
18:50:26 <Eddi|zuHause2> sometimes i find a really fitting word in german but cannot translate it
18:50:33 <Wolf01> do you want to learn italian?
18:50:50 <Eddi|zuHause2> it's even worse the other way round
18:51:13 <Maedhros> i want to learn all sorts of languages - mandarin, japanese, french, german, welsh (for some reason...), spanish
18:51:21 <Eddi|zuHause2> if i try to speak german, but the word appears in my head in english, and i cannot find a translation
18:51:46 <Giddorah> Maedhros: Swedish? :S
18:52:06 <UndernotBuilder> I always get confused with win32 and win9x binaries
18:53:46 <Maedhros> Giddorah: not as much, but i'm open to persuasion :)
18:53:58 <Wolf01> i always get confused with 10 and 2
18:54:21 <Belugas> i get confuzed by Zeros and Ones
18:54:25 <Eddi|zuHause2> <UndernotBuilder> why there isn't dedicated server win32 packages? <- to prevent 1 million bug reports "i downloaded win32 package, but it does not start"
18:55:13 <Giddorah> Maedhros: Drink beer?
18:55:18 <Eddi|zuHause2> besides, even the normal package can run as dedicated
18:55:22 <ln-> and another good reason is that most people only have Windows XP Home or Pro, whose license limits it to serve only 10 clients.
18:55:26 <Eddi|zuHause2> just start with -D
18:56:03 <UndernotBuilder> I downloaded r10117 but there isn't any new folder
18:56:35 <Eddi|zuHause2> "i bought milk but there is no cream in the fridge"
18:57:03 <Eddi|zuHause2> that's what his sentence sounded to me...
18:57:54 <Eddi|zuHause2> UndernotBuilder: the "blitter" directory will only be in the "source" package
19:14:52 <Giddorah> Oh my god... I just saw the "birthday"-cake
19:14:56 <Giddorah> That's just awesome!
19:25:10 <Phazorx> the result of Phazorx vs 10048 + stillunknown patch is...
19:26:20 <Phazorx> it would be nice if dev's would rpovide overtride feature for things like that
19:26:48 <Phazorx> there should be a way to force laod the save, rather than refuse to do it based on auxilary checks before even trying to open the file
19:31:34 <Rubidium> Phazorx: how should it handle the fact that a chunck in the savegame isn't the expected size?
19:36:56 <Phazorx> Rubidium: it doesnt get to that point
19:37:20 <Phazorx> it stops thinking about processing as soon as it discoevers difference between versions
19:37:44 <Phazorx> if it would fail to load due to not being able to process the data - it is quite uderstandable
19:38:22 <Phazorx> but think about newgrfs - they still work even if they not fully compatible - engine is just skipping parts it doesntr know how to deal with
19:38:24 <Rubidium> Phazorx: version numbers are there because also the semantics of the savegame could change
19:38:53 <Rubidium> Phazorx: it did; it added some data
19:39:21 <Rubidium> and there is *no* way of knowing whether that data is important and how to interpret that data
19:39:49 <Phazorx> so by default it should not let average user load newever game into old build... however it is possible what the case is harmless but ther eis no easy way around
19:40:02 <Phazorx> Rubidium: agreed, but that is up to user's discretion
19:40:32 <Phazorx> if they feel like it deserve a chance - they also should exoect it to fail if they override checks
19:43:42 <Rubidium> Phazorx: the problem is that with another version number OTTD might load the savefile into all kinds of wrong memory location, so the load succeeds, but after 10 seconds of play it crashes very hard. Better to make sure that doesn't happen.
19:44:10 <Rubidium> And if people play with a patch, they are aware that they aren't playing with trunk, so they shouldn't expect trunk to load those savegames.
19:44:13 <Phazorx> hmm.. can it do something liek reparsing it on a fly ?
19:44:28 <Phazorx> liie load, adapt-as it would be saving it and reload that ?
19:44:57 <Maedhros> no, because it doesn't know what it's loading in the first place
19:45:12 <Phazorx> hmm.. that wont matter
19:45:35 <Phazorx> if it sucseed loading and ready to initilize the game - means it parsed all it could
19:46:12 <Maedhros> no, the data has no labels in the savegame. it just loads the required data into the places the game says it should load it
19:46:26 <Maedhros> but that doesn't mean it's loading data into the *right* place
19:46:51 <Phazorx> Maedhros: i'm not familar with structure of data - but i assume there are headers of some kind
19:46:56 <Phazorx> secrioning the content
19:47:05 <Phazorx> and each part is handled individually?
19:47:17 <Phazorx> these are vehicles wtc
19:47:25 <Rubidium> Phazorx: yes, these are vehicles
19:47:27 <Maedhros> yes, but all vehicles are in the same chunk
19:47:47 <Maedhros> so if you have more data in the savegame than the game expects it will load rubbish for every vehicle after the first one
19:47:52 <Rubidium> it's version 64, so each vehicle uses exactly 189 bytes
19:48:00 <Phazorx> Maedhros: somewhere in *.h data structure is outlined and format si same for every vehicle
19:48:14 <Phazorx> exactly Rubidium: so if it is 190 - ity wont load
19:48:27 <Maedhros> Phazorx: no, because it doesn't know that the savegame has 190 bytes per vehicle
19:48:28 <Rubidium> and your savegame has vehicles with size 190
19:48:28 <Phazorx> and that is defined in code, not in save
19:48:43 <Phazorx> hence the load will fail
19:49:13 <Rubidium> hence you won't be able to load your r10048M game in r10048
19:49:31 <Phazorx> Rubidium: i just did for a matter of fact but that is irrelevant atm
19:49:44 <Phazorx> my point is save might have extra data
19:49:53 <Phazorx> which engine wont know how to parse
19:50:05 <Phazorx> since it lacks structure for it and does not know it is needed
19:50:20 <Phazorx> for these cases override would be very much usefull
19:50:29 <Maedhros> Phazorx: no, what it will do is lead 189 bytes for each vehicle anyway
19:50:43 <Maedhros> the trouble is that the 190th byte will become the 1st byte in the second vehicle
19:51:01 <Rubidium> Phazorx: the problem is that you do not know where that one byte was added into those 190 bytes, it could be the 26th or the 34th or the 189th
19:51:26 <Phazorx> Maedhros: by extra data i mean it has map of underground or different planet or some other features which i can nto think of
19:51:38 <Phazorx> not more data in known structures whoch should be parsed
19:51:59 <Phazorx> but extra types of data in file which parses can not comprehend since it is not aware of them
19:52:05 <Rubidium> when you add new (types of) chuncks you don't need to increase the version number
19:52:15 <Maedhros> well if your savegame has unknown chunks, those will be ignored, yes, but that's pretty rare
19:52:19 <Rubidium> and in that case it will (most like) just load the game
19:52:46 <Phazorx> well in that case ball is stillunknown court for bumoping the version
19:52:49 <CIA-1> OpenTTD: glx * r10120 /branches/noai/ (69 files in 9 dirs): [NoAI] -Sync with trunk r10096:r10119
19:53:20 <Phazorx> cuz to best of my knowledge - save worked once i fooled code with versions
19:53:49 <Rubidium> Phazorx: he did NOT add a new chunck
19:54:13 <Phazorx> it should not have worked if there was more data in known parts
19:54:23 <Rubidium> does the savegame load in latest trunk?
19:54:44 <Phazorx> i have only tried 10075 and 10109
19:54:51 <Phazorx> and 10109 + peters patch
19:55:15 <Phazorx> i expect it to load in laters too
19:55:44 <Rubidium> don't know what stillunknown exactly did with his patch
19:55:58 <Rubidium> but he said he added some variable to Vehicle to count something
19:56:24 <Phazorx> well it is less for vehicle and mroe for tracks
19:56:43 <Rubidium> + SLE_CONDVARX(cpp_offsetof(Vehicle, u) + cpp_offsetof(VehicleRail, crossing_self), SLE_BOOL, 65, SL_MAX_VERSION),
19:56:50 <Rubidium> but that's the 10075 diff
19:57:13 <Wolf01> who does have a pocket pc with windows mobile here?
19:57:28 <Phazorx> aside of hardcoded 65
19:58:04 <glx> of course it's hardcoded, it won't change
19:58:45 <Rubidium> but apparantly stillunknown hadn't added that in his 10048 patch, which made it "easy" for you
19:59:35 <glx> it has a bump for nothing?
19:59:58 <Rubidium> the bump was so he could "initialize" those caches
20:00:35 <glx> hmm so the savegame version can be fixed by hand and it will load
20:01:07 <Rubidium> jup, that's what Phazorx did
20:01:20 <Rubidium> but normally it wouldn't be that "easy"
20:01:41 <Phazorx> i only harcoded more 65's into saveload.cpp
20:01:47 <Phazorx> and denummped save version
20:02:40 <Phazorx> thing is - i had version before i messed with it in 48M
20:03:00 <Phazorx> i used 48 and 48M to resave paused game
20:03:27 <Phazorx> and there was not much difference between saves in size
20:03:57 <Rubidium> adding one byte to a few vehicles is most likely negligable
20:04:17 <Phazorx> Rubidium: difference was 4 byte overall
20:04:31 <Phazorx> but for game with 600 vehicles there should be more
20:04:42 <Phazorx> 600 trains - 8K+ cars
20:05:02 <Rubidium> not necessarily, maybe it aligns stuff in such a way that zlib like to compress it much better
20:05:35 <Phazorx> if there waz an easy way to unlzo saves - i'd diff them
20:06:55 <Giddorah> How often are nightlies built and put on the page?
20:07:12 <Rubidium> Giddorah: make a guess
20:07:39 <stillunknown> Nightlies are made on a weekly basis ;-)
20:08:16 <Giddorah> Yeah cus... I'm from sweden... The northern parts... And during winter... Sun doesn't set :P
20:08:55 <Phazorx> that's like one interviewee i once had - how often do i get payed here? - biweekly - and how many times per year is that?
20:09:19 <Phazorx> Giddorah: it is summer there, you should look outside mroe often
20:09:56 <Giddorah> I was hoping someone would mix up sweden and australia
20:22:33 <Nickman> I'll be looking for a good laptop for next schoolyear. Any ideas of upcoming notebooks that are coming? For the moment It'l be a MacbookPro
20:22:48 <Touqen> Sounds like a winner to me.
20:24:14 <Touqen> Disclaimer: I don't actually own in apple products (Yet)
20:24:23 <CIA-1> OpenTTD: truelight * r10121 /trunk/ (32 files in 6 dirs): (log message trimmed)
20:24:23 <CIA-1> OpenTTD: -Codechange: split renderer from rest of code; no longer any code directly accesses the video-buffer
20:24:23 <CIA-1> OpenTTD: -Add: added NULL blitter and renderer, which are always used for -vnull
20:24:23 <CIA-1> OpenTTD: -Add: dedicated driver doesn't blit nor render by default. Can be overruled by user. (-D -b 8bpp-optimized)
20:24:25 <CIA-1> OpenTTD: -Remove: removed CTRL+D from win32, which is incompatible with above
20:24:25 <CIA-1> OpenTTD: -Add: extended screenshot support for PNG and BMP
20:24:27 <CIA-1> OpenTTD: -Codechange: remove all hardcoded 8bpp references and replace them with more dynamic ones
20:25:25 <Nickman> nice one treuligt... :D
20:26:01 <Giddorah> What do this open up for? :P
20:26:12 <TrueBrain> More flexible blitters and renderers
20:36:21 <Maedhros> not a clue... it takes 0.5 here
20:37:21 <ln-> i have Fedora Core 5 installed on two computers; on one it takes 0.5 as expected, but on another it takes 27 seconds and I cannot understand why.
20:48:50 <Biff> ln-: does it take any time if you remove the select?
20:50:22 <Maedhros> does it take any time if you ask it to actually poll something?
20:50:23 <Rubidium> ln-: what happens when you use one-tenth of the value for u_sec?
20:50:49 <ln-> if i set tv.tv_usec to 5000, running takes about 0.24 seconds.
20:51:09 <ln-> strace doesn't give any useful data, it just shows it's waiting in the select.
20:53:39 <Biff> usleep() works normally?
20:54:55 <ln-> now that i try the example program from select man page, which is supposed to timeout in 5 seconds, it appears to take "forever" (i waited for 50 seconds and nothing happened).
20:55:31 <ln-> usleep() produces expected result.
20:58:19 *** dihedral has joined #openttd
20:58:58 <dihedral> for some odd reason 0.5.2 is crashing all the time
20:59:02 <ln-> the only other unusual thing is that `top' shows max. 2% of CPU for processes doing heavy calculations. but still they operate at expected speed.
20:59:38 <dihedral> at least one of my games seems to go down every few days!
21:00:00 <Maedhros> dihedral: details. it's all in the details :p
21:00:10 <dihedral> last savegame pub.dihedral.de/openttd/FP1/autosave18.sav
21:00:32 <dihedral> also pub.dihedral.de/openttd/FP1/crash.sav is another one
21:01:04 <dihedral> i have no idea about the details! i only know that when i come around to checking the games, something seems wrong
21:01:35 * Maedhros realises he doesn't have a working copy of the 0.5 branch around...
21:01:51 <dihedral> autosaves are set to quater-yearly that is atm all i can offer
21:05:17 <Rubidium> dihedral: where there any users?
21:07:06 <Rubidium> dihedral: that autosave is from the moment of the crash, do you have an earlier one?
21:10:38 <dihedral> i shall check about the users
21:11:30 <dihedral> pub.dihedral.de/openttd/FP1/autosave17.sav ?
21:11:38 <dihedral> just check pub.dihedral.de/openttd/FP1
21:12:15 <dihedral> i did a few newgame's on that one today... i think it was that one at least! could have been FP2 not so sure atm
21:16:30 <dihedral> Rubidium: anything odd to be seen?
21:17:33 <Rubidium> well, getting the game in the same state takes quite a while
21:21:36 <dihedral> but do you think the data is good for finding out where the problem might lie?
21:21:36 <Rubidium> didn't crash for me; can you reproduce it yourself?
21:21:55 <dihedral> i could load the savegame
21:22:07 <dihedral> which autosave do you want me to load?
21:23:10 <Rubidium> the 17, because 18 is most likely made too close to the crash (same date)
21:23:23 <Rubidium> although, when 18 crashes immediately, that would be a result too
21:24:05 <dihedral> then i shall start 18 first :-)
21:24:21 <Rubidium> are you using autopilot?
21:25:20 <Rubidium> in the dedicated server I hope ;)
21:25:23 <dihedral> openttd.dihedral.de:3979
21:25:46 <Rubidium> it either crashes in like 10 seconds, or it's already too late
21:26:00 <dihedral> right... then it's too late
21:26:02 <Rubidium> the crash.sav is from 1946-07-01 IIRC
21:26:11 <Rubidium> so that's when the crash happened
21:26:16 <dihedral> that save game is a few days old
21:26:19 *** Brianetta has joined #openttd
21:26:29 <dihedral> as you can see when looking at the index of pub.dihedral.de/openttd/FP1
21:27:47 <dihedral> i ran a newgame between 17 and 18
21:27:52 <dihedral> as you could tell by the dates
21:28:07 <dihedral> autosave17 is from 1955-01
21:29:14 <dihedral> the game starts in 1946
21:29:20 <Rubidium> oh, so it's unreproducable... how nice
21:29:38 <dihedral> but then it looks like it's after the server restarts
21:30:22 <dihedral> loading 17 and running newgame
21:30:34 <dihedral> lets see what happens when it hits july then :-)
21:30:49 <Rubidium> just make a savegame a month of so before july
21:31:16 *** NukeBuster has joined #openttd
21:31:53 <dihedral> if quateryearly is set, i dont get why the first savegame is in july!
21:32:50 <Rubidium> because you most likely set biannually
21:34:04 <dihedral> that would also explain the 8 min interval of the creation date of those save games :-P
21:38:07 <dihedral> how do you know 18 is from the time it crashed?
21:38:56 <Rubidium> crash.sav and autosave18.sav where of about the same data IIRC
21:40:00 <dihedral> yeah - but about 6 days apart
21:40:25 <dihedral> crash.sav is from 07-Jun-2007 21:20
21:40:38 <dihedral> and autosave18.sav from 12-Jun-2007 18:49
21:41:00 <dihedral> ok - not 6 days... still days apart
21:54:32 *** Osai^2 is now known as Osai
21:57:10 <dihedral> reproduced with autosave18.sav
21:57:18 <dihedral> just let it run for some time
21:57:31 <dihedral> i shall turn of screen so i can keep the output
21:59:50 *** juancuka has joined #openttd
22:01:57 <Rubidium> dihedral: how much is some time?
22:02:28 <dihedral> must be less than 8!
22:02:47 *** boekabar1 has joined #openttd
22:03:11 *** boekabar1 is now known as boekabart
22:10:12 <dihedral> Floating point exception
22:10:34 <dihedral> have a savegame from 1946-11
22:10:57 <dihedral> pub.dihedral.de/openttd/FP1/bug.sav
22:11:36 <dihedral> just before that a dbg: [NET][UDP] Queried from 80.167.140.47 << hope it has nothing to do with client requests !!
22:11:50 <Rubidium> it shouldn't have to do with that
22:12:50 <dihedral> well - have i at least given you reproducable stuff?
22:13:32 <Rubidium> have to compile 0.5 on my (slow) server as I'm running a profile on my main computer which takes more time that I hoped
22:14:12 <CIA-1> OpenTTD: maedhros * r10122 /trunk/src/ (economy.cpp functions.h misc.cpp roadveh_cmd.cpp): -Codechange: Add a CountBitsSet function and use it to replace some less efficient loops.
22:14:52 <dihedral> you want ssh to my server?
22:15:00 <dihedral> got 0.5.2 running there already
22:15:15 <dihedral> just running the last savegame with debug level 6
22:17:13 <Rubidium> but it crashed again?
22:17:42 <dihedral> that is a savegame from 1946-11-02
22:17:52 <dihedral> crash is sometime after 1946-12-04
22:18:05 <dihedral> some time = shortley
22:18:24 <dihedral> again with Floating point exception
22:19:15 <Rubidium> that's strange as we don't use any FP except for map generation AFAIK
22:19:43 <Eddi|zuHause2> something in YAPF used to use FP
22:19:52 <dihedral> crash is in 1946-12-18
22:20:16 <Rubidium> Eddi|zuHause2: it can't be YAPF
22:20:21 <Eddi|zuHause2> might have been a debug feature...
22:20:27 <dihedral> there is nothing to be using yapf
22:21:27 <Eddi|zuHause2> errr... was the ping timeout increased?
22:21:40 <Eddi|zuHause2> i thought it used to be 480 seconds
22:22:44 <dihedral> where does the setting get set?
22:23:22 <Rubidium> oops, compiled the 0.5 binary with the wrong settings :(
22:23:42 <Eddi|zuHause2> ping timeout is a setting of the IRC server, dihedral... totally unrelated to your problem :)
22:24:09 <dihedral> if it was me causing the prob that would have been solvable a lot faster :-)
22:24:16 <Rubidium> 2 weeks of depchecking later it starts to compile
22:27:43 <Rubidium> luckily compiling with (full) debugging is faster than compiling "release" grade binaries
22:28:24 <Eddi|zuHause2> it's easy to be faster if you skip optimisations :)
22:31:07 <dihedral> anyhow - i shall hit the rack
22:31:25 *** dihedral is now known as rack
22:31:37 *** rack is now known as dihedral
22:31:58 <dihedral> hope the save game gets you somewhere with that crash
22:32:05 <dihedral> please let me know :-)
22:38:28 <Phazorx> got another save for ya to test
22:45:49 *** tokai|ni has joined #openttd
22:47:50 <Phazorx> i got ~50% load here woth 104M
22:48:07 <Phazorx> same PC that has 4% laod at EvsL
23:05:13 *** UndernotBuilder has quit IRC
23:07:07 <CIA-1> OpenTTD: bjarni * r10123 /trunk/src/video/cocoa_v.mm: -Fix r10121: the 8 bpp cocoa video driver works again
23:10:58 <CIA-1> OpenTTD: truelight * r10124 /trunk/src/video/cocoa_v.mm: -Fix r10123: fix the OSX video driver properly
23:11:22 * Eddi|zuHause2 gets popcorn and watches the commit wars
23:12:51 <Eddi|zuHause2> so what do you call it?
23:13:16 <TrueBrain> Bjarni in an overenthousiastic mood :) I send him some things to test, which he commited :p Shit happens
23:14:31 <Eddi|zuHause2> and the moral of the story? :p
23:14:44 <TrueBrain> make clear when you are sending people test-things :)
23:14:50 <TrueBrain> don't send Bjarni things at a late hour
23:14:54 <TrueBrain> don't send things at a late hour
23:15:00 <TrueBrain> tie your shoes before leaving the house
23:15:06 <TrueBrain> eat food at regular hours
23:15:14 <TrueBrain> don't type rm -rf / as root
23:15:25 <Bjarni> specially not to people, who are busy doing other stuff, but decides to look at a failure to execute problem since it's urgent
23:15:33 <Eddi|zuHause2> don't eat yellow snow?
23:15:41 <TrueBrain> Bjarni: urgent only for those who use OSX ;)
23:15:47 <TrueBrain> Eddi|zuHause2: for sure, don't eat yellow snow :)
23:16:16 <Bjarni> <TrueBrain> Bjarni: urgent only for those who use OSX ;) <-- those are the most important users ;)
23:16:24 <Eddi|zuHause2> i have never seen green snow...
23:16:27 <Bjarni> at least when it comes to stuff that I have to look at
23:16:34 <TrueBrain> nasty I can tell you
23:17:09 <Bjarni> the snow can be coloured red by sand from Sahara... the wind can take it all the way to Denmark, so I presume that it can take it to Germany and NL as well
23:17:26 <Eddi|zuHause2> i think i heard the line "don't eat yellow snow" the first time on the bundys
23:17:54 <TrueBrain> Eddi|zuHause2: most likely me too :p
23:18:05 <TrueBrain> and in the class-room of course many more times
23:21:35 <TrueBrain> so, what's next.....
23:22:29 <Eddi|zuHause2> the same thing as every night :)
23:23:32 <TrueBrain> TAKE OVER THE WORLD!
23:23:38 <TrueBrain> that makes you Pinky
23:24:01 * Bjarni feels bad for Eddi|zuHause2
23:24:09 <Eddi|zuHause2> i think we discussed that before :p
23:24:41 <Eddi|zuHause2> of course i could act like pinky, but that does not mean i would identify with him :p
23:26:09 <Eddi|zuHause2> actually, that would be a name for DorpsGek :p
23:26:34 <TrueBrain> I kind of like it :p
23:26:45 <Eddi|zuHause2> well, TruePinky of course :)
23:27:04 <Bjarni> <Eddi|zuHause2> of course i could act like pinky, but that does not mean i would identify with him :p <-- sure. It takes brainpower to identify yourself with somebody else, nomatter how similar you are :P
23:27:28 <Eddi|zuHause2> that took you long enough :)
23:28:58 <Phazorx> wow that's a weird one
23:29:30 <Phazorx> tile.h:57 tile < MapSize()
23:31:55 <Phazorx> game checking tile outside of map?
23:32:01 <Eddi|zuHause2> assertions are conditions that should always be true
23:32:12 <Phazorx> meaning this one wasnt
23:32:18 <Phazorx> and tile index probably was out of bounds
23:33:09 <Eddi|zuHause2> yes, and if you triggered that assertion, your job would be to provide us with a description how you did it
23:33:22 <Ailure> Apart from trams being implented?
23:33:40 <Eddi|zuHause2> articulated vehicles
23:33:56 <Ailure> any newGRF that uses that feature currently?
23:34:01 <Eddi|zuHause2> road vehicles to be more specific
23:34:22 <Eddi|zuHause2> some of them, at least
23:34:23 <Ailure> any spefic tramset I mean
23:34:26 <Eddi|zuHause2> and more will follow
23:35:30 <CIA-1> OpenTTD: rubidium * r10125 /trunk/src/economy.cpp: -Fix [FS#865]: under some circumstances the wagons of a train didn't get loaded properly.
23:36:38 <Ailure> I wish you could define the titlescreen in the config file
23:36:43 <Ailure> I use a custom titlescreen xD
23:36:53 <Ailure> but I have to replace it back everytime I get a new nightly
23:37:26 <TrueBrain> I still want a rotating titlescreen :)
23:37:49 <Eddi|zuHause2> wasn't wolf01 working on a patch?
23:38:25 <Ailure> I made my own titlescreen featuring some custom newGRF
23:38:36 <Ailure> but main reason is that the titlescreen OTTD uses
23:38:36 <Eddi|zuHause2> no, title screen scrolling and stuff
23:38:41 <Ailure> seems to be designed by some ADHD kid
23:39:05 <Ailure> so you hear all kind of vehicle noises when you start OTTD D:
23:39:26 <TrueBrain> start openttd -snull
23:40:10 <Eddi|zuHause2> but why do you need to replace it every time? just don't overwrite it
23:41:34 <Eddi|zuHause2> for that purpose, the read only attribute got invented :(
23:41:56 <Ailure> but my OS isn't exactly D:
23:42:04 <Ailure> if you choose overwrite all
23:42:13 <Ailure> that includes readonly files
23:42:24 <Sionide> there needs to be a competition for a new titlescreen
23:42:48 <Sionide> when the scrolling patch it done maybe
23:42:52 <Eddi|zuHause2> iirc, if i chose "overwrite all", it asked again on a read only file
23:43:06 <Sionide> basically, take a small map and *fill* it with every feature you can think of..
23:43:08 <Bjarni> I wouldn't mind more than one titlescreen
23:43:21 <Bjarni> so the game could select a random one each time
23:43:22 <Ailure> I was considering to start a such contest xD
23:43:23 <Sionide> on random, when you start?
23:43:28 <Bjarni> would use a bit more disk space though
23:43:55 <Sionide> loads of new features aren't represented in the titlescreen which is what i thought it was for..
23:44:29 <Bjarni> and if it's started by a non-developer, it's way easier for us to do nothing if nothing good turns up
23:44:35 <Ailure> mine probably would be rather boring for people with low resoultions
23:44:44 <Ailure> since you would only see the forest xD
23:44:44 <Bjarni> just remember that the titlescreen shouldn't depend on newGRF
23:45:19 <Sionide> Ailure, it's boring at your res, it needs to be busier than that... all stuff going on, all features shown (where possible obviously)
23:45:29 <Bjarni> yeah, it should work nicely with both 640x480 and 1600x1200
23:45:52 <Bjarni> testing the latter could cause issues for some people, but the first should be fairly simple to test xD
23:46:02 <Ailure> reason I made my own titlescreen
23:46:08 <Sionide> like the current one, there's always stuff going on and things moving around and that's cool
23:46:09 <Ailure> was that the orginal titlescreen was way too busy for my taste
23:46:25 <Ailure> but it get's old fast when you start OTTD often
23:46:50 <Bjarni> that's why having more than one and selection of one at random could be nice
23:46:56 <Ailure> hearing the "ding ding ding ding *boat sound*" was the same thing as "Connection lost" for me
23:47:28 <Sionide> Ailure, newgrf aside, yours doesn't show off any openttd features.. which i think the title screen should
23:48:02 <Ailure> Well I didn't make that titlescreen to show off features
23:48:09 <Ailure> mostly to please my eyes whenever I start OTTD D:
23:48:31 <Ailure> I was considering to use a competly empty landscape instead
23:48:45 <Bjarni> if it should have any chance of getting accepted as an official one, then it needs to be a showoff of features
23:49:19 <Ailure> well I didn't say I would try making this a official titlescreen though :p
23:49:44 <Ailure> and it should be possible to have more than one
23:50:23 <Ailure> and talking about offical features
23:50:31 <Ailure> it's kinda hard to showoff trams without using a newGRF
23:52:20 <Eddi|zuHause2> i think at some point we should decide to extend the default set with some features
23:52:26 <Ailure> I probably would use the generic tramset if I had to use one newGRF though
23:52:34 <Eddi|zuHause2> like generic trams, or refittable trucks
23:52:37 <Ailure> mostly becuse it's similar in style to the rest of the road vehicles and trains
23:52:48 <Ailure> generic trams set seems to be the first "finished" tramset
23:53:21 <Ailure> Though there's a few promising tram sets of course
23:53:31 *** Sacro|Laptop has joined #openttd
continue to next day ⏵
