IRC logs for #openttd on OFTC at 2009-09-22
⏴ go to previous day
00:02:52 <PeterT> well it's a bug causing me problems
00:02:55 <PeterT> or a problem causing bugs
00:06:34 <Yexo> PeterT: add option 3 and chose that one: only to bugs.openttd.org
00:06:58 <PeterT> <PeterT> (or just bugs.openttd.org)
00:07:08 <PeterT> I'm making the bugs page
00:15:34 <Yexo> PeterT: a certain "cameron" on that server doesn't seem to like you
00:16:03 <PeterT> i thought i banned him
00:16:28 <Yexo> he thought I was you, and asked for a ban ("go ahead, just ban me")
00:17:28 <Yexo> no, I joined as Yex0 but already left the server
00:18:23 <Yexo> anyway, I can confirm the bug on that server, but can you also repeat it on other servers?
00:18:32 <PeterT> did you see the problem?
00:19:04 <Yexo> but I can't reproduce the problem locally
00:22:53 *** KenjiE20|LT has joined #openttd
00:23:27 <Yexo> PeterT: if you find any more information, please add it to the bug report
00:23:53 <Rubidium> like how to reproduce it
00:27:06 <Eddi|zuHause> PeterT: i don't think so.
00:28:08 <PeterT> tell rubidium I found the problem
00:28:40 <PeterT> well, I knew the problem, but I fixed it now
00:32:17 <PeterT> Ah, whatever, he has to check his inbox eventually
01:03:18 *** th1ngwath has joined #openttd
01:11:30 <PeterT> Yexo: did you see my comment?
01:11:57 <Eddi|zuHause> PeterT: nobody sees anything at 3AM
01:12:16 <PeterT> on a lit computer screen, yes they do
01:14:17 * fjb has already closed his eyes and sees nothing.
01:24:40 <fjb> Yes, of course, with all 10 fingers.
01:29:02 <Eddi|zuHause> PeterT: but when someone ends a discussion with the words "good night", it usually indicates that the person is not going to have a lit computer screen
01:40:49 *** thingwath has joined #openttd
05:05:40 *** stoyanov has joined #openttd
06:07:26 *** Azrael- has joined #openttd
06:34:49 *** Terkhen has joined #openttd
06:45:49 * dihedral extends ignore list :-P
06:46:21 * Muxy likes to be in fan lists :p
07:07:31 *** DaleStan_ has joined #openttd
07:07:31 *** DaleStan is now known as Guest3275
07:07:31 *** DaleStan_ is now known as DaleStan
07:09:34 *** Cybertinus has joined #openttd
07:12:04 *** DaleStan has joined #openttd
07:17:44 *** Polygon has joined #openttd
07:33:59 *** [alt]buster has joined #openttd
07:46:47 *** Terkhen has joined #openttd
07:54:15 *** Aankhen`` has joined #openttd
08:55:00 *** DaleStan_ has joined #openttd
08:55:00 *** DaleStan is now known as Guest3282
08:55:00 *** DaleStan_ is now known as DaleStan
08:56:07 *** [com]buster has joined #openttd
09:15:18 *** Progman has joined #openttd
09:21:57 *** crakinshot has joined #openttd
09:27:31 *** FloSoft has joined #openttd
09:37:38 *** oskari89 has joined #openttd
09:50:45 <Rubidium> good (almost) afternoon :)
09:54:55 *** Chris_Booth has joined #openttd
09:57:57 *** [alt]buster has joined #openttd
10:33:26 *** Lordnokon has joined #openttd
10:35:02 <crakinshot> have a slight file problem. I need rail_map.h to link to signalex_map.h, but then signalex_map.h already includes rail_map.h. :(
10:35:33 <crakinshot> so I've made some unsafe bit access functions in a signalex_func.h and get railmap.h to use that instead
10:37:04 <crakinshot> but not safe access, as it doesn't have checks
10:39:47 *** [com]buster has joined #openttd
11:01:23 <Eddi|zuHause> you're probably doing something wrong
11:02:31 <crakinshot> the main problem is that signalex_map.h functions use rail_map.h functions to check the tile types
11:03:18 <crakinshot> I guess I could put my map altering functions in rail_map.h rather then a seperate file
11:04:38 *** KenjiE20 has joined #openttd
11:07:50 <Yexo> why does rail_map.h need to include signalex_map.h?
11:10:26 <CIA-4> OpenTTD: yexo * r17609 /trunk/src/ai/ai_info.cpp: -Fix: the dummy AI had no API version set, causing the 'API compatibility script not found' error to be printed when loading it
11:23:19 *** Lordnokon has joined #openttd
11:26:01 <crakinshot> I need to put in some new code in the tile access functions
11:26:31 <crakinshot> if the signal has been extended then all access to the m2 variable is rerouted to a pool item
11:29:50 <crakinshot> so the rail_map.h functions need the functions to check if the signal is extended.
11:30:36 <crakinshot> I'll just put the bit handlers in the rail_map.h file rather than seperate them
11:31:05 <Rubidium> have you thought at all about performance impacts?
11:31:34 *** HerzogDeXtEr1 has joined #openttd
11:36:08 <crakinshot> yeah, somewhat. So long as we're talking 1 bit from one variable it shouldn't have much impact with the normal signals
11:36:58 <crakinshot> there are two choices really, you use up all the remaining free bits of the tile (signals)
11:37:20 <crakinshot> or you move m2 out into a pool item if the signal tile has been extended
11:38:19 <crakinshot> with that option, it would cost 1 GetBit and one If condition
11:38:36 <crakinshot> for all tile accesses (RailwithSignal)
11:38:57 <crakinshot> then you'd handle the two cases on how to access the m2 data.
11:39:07 <crakinshot> the first being as before
11:39:27 <crakinshot> and second grabbing the pool item and accessing the m2 variable from there
11:40:31 <crakinshot> in theory if extended signals are not being used, then the added cost is simply that GB and if statement
11:40:58 *** Lordnokon has joined #openttd
11:52:21 *** Coco-Banana-Man has joined #openttd
11:55:01 <Eddi|zuHause> where the heck ist .za?
12:06:35 <Eddi|zuHause> oh.. so it's the crazy dutch people's fault...
12:09:41 <Rubidium> also the Saudi's fault
12:15:33 *** tux_mark_5 has joined #openttd
12:23:22 <Eddi|zuHause> Sau die arabische...
12:24:00 <Eddi|zuHause> (i don't think that translates correctly :p)
12:27:34 <FauxFaux> Sauce dies arbitarily?
12:29:05 <Eddi|zuHause> yeah, something like that :p
12:31:58 <CIA-4> OpenTTD: rubidium * r17610 /branches/0.7/src/company_cmd.cpp: [0.7] -Fix [FS#3227] (r17302): reloading an AI caused reading and later freeing of already freed memory
12:43:09 <CIA-4> OpenTTD: smatz * r17611 /trunk/src/ (company_cmd.cpp strings_type.h town_cmd.cpp): -Fix: buffers used for verifying company and president name length were too short, possibly causing false positives
13:06:39 *** Belugas has joined #openttd
13:06:39 *** ChanServ sets mode: +o Belugas
13:06:45 *** Yexo is now known as Guest3300
13:39:28 <crakinshot> well fixed the problem with 2 files needing each other start static inline functions
13:47:02 *** lewymati has joined #openttd
13:55:07 <CIA-4> OpenTTD: smatz * r17612 /trunk/ (12 files in 4 dirs): -Feature: possibility to choose (randomise or enter custom) town name before its creation (original patch by Terkhen)
14:03:31 <Terkhen> the final code is way cleaner :P
14:03:46 <Belugas> that's the work of a dev :)
14:07:25 <Belugas> keep on practicing, Terkhen
14:11:30 *** Doorslammer has joined #openttd
14:40:38 *** Grelouk has joined #openttd
14:47:48 *** Grelouk_ has joined #openttd
14:59:45 *** DaleStan has joined #openttd
15:02:52 <crakinshot> hmm, this is more difficult that I thought it would be. 2 files that need each other, but a problem because of statlic inline functions
15:03:48 <crakinshot> static inline *have* to be defined in the header, correct? If they are defined in a cpp file then the compiler won't inline them? Or something like that.
15:04:33 *** Doorslammer has joined #openttd
15:05:53 <SmatZ> compiler doesn't even know where the code originally was after preprocessor run
15:06:54 <SmatZ> (basically... it does know it because of comments in preprocessed file)
15:07:16 <SmatZ> so it can generate debug info, useful error/warning messages and things...
15:07:32 <SmatZ> lower warning level for system headers...
15:11:18 <crakinshot> hmm so I can put the declaration in a header and the definition in a cpp and it'll still be inlined?
15:11:32 <crakinshot> looked up on google, seems to suggest you can
15:13:05 *** frosch123 has joined #openttd
15:13:49 <Eddi|zuHause> but it'll only use it within that .cpp file, not any other .cpp file that includes the header
15:16:26 *** Audigex has joined #openttd
15:17:33 <crakinshot> a really ball ache
15:18:14 <crakinshot> i either still everything in railmap.h or use non-inlined functions
15:36:08 *** elmex_ is now known as elmex
16:04:26 *** Terkhen has joined #openttd
16:12:50 *** |Jeroen| has joined #openttd
16:40:31 *** Terkhen has joined #openttd
16:44:48 *** Azrael- has joined #openttd
17:05:49 <Terkhen> SmatZ: there is a bug: when you set a custom town name the town sign is not correctly updated
17:08:50 <Eddi|zuHause> hmm, when you use the cursor keys, i have the feeling that scrolling up/down is faster than scrolling left/right
17:27:09 *** Dreamxtreme has joined #openttd
17:28:36 <Eddi|zuHause> the kids start younger and younger each time...
17:31:27 <SmatZ> Terkhen: nice :) InvalidateWindowData(WC_TOWN_DIRECTORY, 0, 1); doesn't have to be called in that case? (as in CmdRenameTown)
17:35:26 *** Alberth has joined #openttd
17:35:41 <Terkhen> no, the town directory window gets updated correctly
17:36:42 <Terkhen> but looking at the code... it should be needed
17:37:31 <Terkhen> ah, InvalidateWindowData gets called at the town constructor
17:38:08 *** lewymati has joined #openttd
17:45:50 <CIA-4> OpenTTD: translators * r17613 /trunk/src/lang/ (10 files): (log message trimmed)
17:45:50 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
17:45:50 <CIA-4> OpenTTD: traditional_chinese - 107 changes by josesun
17:45:50 <CIA-4> OpenTTD: dutch - 12 changes by habell
17:45:50 <CIA-4> OpenTTD: french - 3 changes by glx
17:45:50 <CIA-4> OpenTTD: german - 1 changes by dihedral
17:45:50 <CIA-4> OpenTTD: hungarian - 6 changes by alyr
17:47:07 <Terkhen> I get the same crash in r17610, so it's not directly related to changes in r17612
17:48:06 <SmatZ> Terkhen: oh, I thought it was fixed recently... or it was Industry List actually :-x
17:49:12 <Terkhen> I remember a recent correction similar to this one, yes... but I don't know in what list
17:50:16 <Yexo> SmatZ: wasn't that about showing an empty industry list window?
17:51:56 <SmatZ> Yexo: the one I remember was about invalid industry in the list
17:52:09 <Yexo> ok, was another one then :p
17:52:32 <DorpsGek> SmatZ: Commit by rubidium :: r17472 /trunk/src (industry.h industry_cmd.cpp) (2009-09-08 12:22:28 UTC)
17:52:33 <DorpsGek> SmatZ: -Fix [FS#3182]: industry list was rebuilt too early during industry removal causing the removed industry to be still in the list after removal
17:52:47 <SmatZ> fixed by moving invalidating of list to PostDestructor iirc
17:52:48 *** Dreamxtreme has joined #openttd
17:56:07 *** Doorslammer has left #openttd
18:05:37 <Terkhen> SmatZ: InvalidateWindowData and UpdateVirtCord are called at DoCreateTown, before the town gets the custom name... I think this is the best solution: http://paste.openttd.org/216987
18:06:07 <Prof_Frink> PostDestructor? Parcelforce?
18:06:52 <SmatZ> Terkhen: DoCreateTown() is called when generating many towns for example
18:06:59 <SmatZ> also, + t->UpdateVirtCoord();
18:07:02 <SmatZ> will crash if t == NULL
18:09:39 <Eddi|zuHause> anyone ever tried to update the timetable patch?
18:10:39 <frosch123> timetabling was added to ottd in 0.6
18:12:24 *** thisismyname has joined #openttd
18:13:12 *** thisismyname has joined #openttd
18:13:35 <Eddi|zuHause> the *improved* timetable patch :p
18:14:00 <Eddi|zuHause> oh... right... simpsons...
18:15:06 *** andythenorth has joined #openttd
18:15:50 <Terkhen> I don't know what is best then: either calling these functions twice when there is a custom name or removing them from DoCreateTown and calling them at the end of CmdFoundTown and after successful CreateRandomTown calls
18:20:29 *** Audigex has joined #openttd
18:22:01 *** CraKinShOt has joined #openttd
18:25:16 *** arfonzo has joined #openttd
18:37:08 <Eddi|zuHause> hm, there are some conflicts, but the patch might not be entirely useless...
18:46:15 <Belugas> two things that are opposing themselves for the same thing
18:48:36 <Eddi|zuHause> doesn't matter, one size fits all :p
18:51:12 <CIA-4> OpenTTD: smatz * r17614 /trunk/src/town_cmd.cpp: -Fix: crash when deleting town while TownDirectory is open
18:55:28 <CIA-4> OpenTTD: smatz * r17615 /trunk/src/town_cmd.cpp: -Fix (r17612): town sign could be glitchy when creating town with custom name (Terkhen)
18:56:00 *** HerzogDeXtEr has joined #openttd
18:57:24 <Eddi|zuHause> hm... is it compile-wise a problem to have a string in $language.txt that is not in english.txt?
18:58:45 <Eddi|zuHause> because this patch removes a string from every language file, which causes lots of unnecessary conflicts
19:03:41 <SmatZ> Eddi|zuHause: what patch do you have in mind? there are currently at least two patches at FS
19:04:56 <SmatZ> if you use unix-like system, you can use perl or grep for that...
19:05:09 <SmatZ> or probably any other scripting/programming language ;)
19:05:13 <Eddi|zuHause> well, it's the least of my problems ;)
19:18:53 <Terkhen> SmatZ: thanks, I hope that I don't find anything else
19:19:21 <SmatZ> I hope you find bugs ;)
19:19:56 <Terkhen> looking at it that way... I hope that too :P
19:25:14 *** andythenorth has joined #openttd
19:26:42 <Eddi|zuHause> hm... OrderList stuff seems to have changed a bit...
19:29:09 <CIA-4> OpenTTD: frosch * r17616 /trunk/ (13 files in 3 dirs): -Codechange [FS#3222]: Enumerize properties used in callback 0x36. Based on Terkhen's work.
19:45:00 <Belugas> hum? again something based on Terkhen's work?
19:48:29 <Belugas> cannot access it SAFELY from here
19:48:44 <Belugas> for sure, it will cahnge the face of OTTD for ever
19:49:13 <Belugas> ... IRONY DETECTOR OFFLINE ... OVERLOAD
19:49:34 <Belugas> good going Terkhen, no kidding
19:51:07 <Eddi|zuHause> Belugas: surely you can access it safely, just use https:
19:53:15 <Terkhen> sorry, I was having dinner
19:53:39 <Rubidium> nah, only I do big patches... besides that one of petern
19:54:42 <CraKinShOt> I'm still having trouble with 2 headers needing one other for inline functions
19:54:58 <CraKinShOt> only way I can see of getting around it is not using inline
19:55:19 <SmatZ> CraKinShOt: why do you need signalex.h in rail_map.h?
19:55:34 <CraKinShOt> for the assertions
19:55:56 <CraKinShOt> and what I'm doing now is changing the access to the m2 variable
19:56:19 <Belugas> Alberth, it's rather the unwanted window appearing while the boss walks around...
19:56:24 <frosch123> [21:55] <Rubidium> nah, only I do big patches... besides that one of petern <- the biggest patches are done by that sed guy
19:56:27 <CraKinShOt> so rail_map needs a) to check its got the signalex bit and B) it needs access to the pool
19:57:20 <CraKinShOt> essentially in this version, if the signalex bit is being used then the m2 tile data is transfered into the ppol item
19:57:32 <CraKinShOt> while m2 is now the index to the pool item
19:58:07 <CraKinShOt> it should be relitively straight forward to alter the rail_map functions
19:58:30 <Alberth> Belugas: a Trac window looks like work :p
19:59:21 <CraKinShOt> but because the signalex files need to include rail_map.h for the assertion checks (to make sure its a RAIL_WITH_SIGNAL, I've got this problem.
19:59:45 <Rubidium> frosch123: svn diff svn://svn.openttd.org/@17009 svn://svn.openttd.org/@17010 | wc -> 470340 2089445 25733813 -> 24.5 MiB
20:02:26 *** Nite_Owl has joined #openttd
20:10:01 <Rubidium> hmm, FS#3210 *might* be related to FS#3227 if he did reload the AI and it bankrupted later on
20:14:31 <CraKinShOt> hmm, I guess I could make another pool, one just for the rail_map
20:15:05 <SmatZ> then you can make pool for tiles I reckon
20:15:35 <CraKinShOt> well its the linking of these two things thats a pain
20:16:51 <CraKinShOt> in GetRailReservationTrackBits it accesses the m2 bit. What I wanted to do it put an if condition in there, so that if a bit was set active then you access the signalex pool
20:17:33 <CraKinShOt> but that makes cross-linking a bit of a pain and not easy to seperate out the functions in rail_map.h
20:19:11 <CraKinShOt> the other alternative is you generalise the behavour for different m2 location, so again have a bit set, but this time you have a pool with just a uint16 value, which is the m2 data and the tile.m2 is now an index
20:19:22 <CraKinShOt> but meh, thats making it far too complex
20:19:38 <CraKinShOt> all for the sake of avoiding non-inline functions
20:21:07 <CraKinShOt> even if I stick all the functions into the rail_map.h that would still need the signalex_base.h for pool access
20:22:25 <CraKinShOt> the only sensible way I see at present is to have a non-inlined function in a _func.h and define it in a cpp file, which then includes rail_map.h
20:24:20 <CraKinShOt> I'll go with that, at least it will compile
20:26:07 <PeterT> what wer we talking about
20:32:04 <PeterT> the signal patch by crankinshot?
20:38:18 <Eddi|zuHause> hm... i'm not entirely sure what this line does
20:38:19 <Eddi|zuHause> + if (v->orders.list != NULL && v->IsInDepot()) v->orders.list->VehicleStoppedInDepot(v);
20:39:19 <planetmaker> I read it as: a vehicle with orders which is in a depot gets stopped.
20:41:22 <Rubidium> looks dodgy regardless
20:42:02 <Eddi|zuHause> OrderList::VehicleStoppedInDepot seems to be a new function introduced by the patch
20:44:26 <CIA-4> OpenTTD: rubidium * r17617 /trunk/src/network/ (network_internal.h network_server.cpp network_server.h):
20:44:26 <CIA-4> OpenTTD: -Codechange: make the server side packet handling be more like the client side's handling, i.e. return the connection status
20:44:26 <CIA-4> OpenTTD: -Fix: do not do invalid reads when a packet handling function closed a connection
20:44:28 <Eddi|zuHause> ah... it seems to remove the vehicle from a list of running vehicles, so the timetable spacing gets updated
20:44:57 *** Progman has joined #openttd
20:46:11 <Rubidium> so if your luck is bad and a few vehicles enter the depot (for servicing) after eachother the whole timetable spacing gets redone and when the vehicles leave again it gets undone?
20:46:49 <Rubidium> seems only useful for vehicles that are actually not participating in the time table, i.e. the ones that are actually stopped in the depot
20:47:00 <Eddi|zuHause> no... the contexts of the patch always have a "v->vehstatus |= VS_STOPPED;"
20:47:07 <Eddi|zuHause> so it does not apply on servicing
20:47:22 <Eddi|zuHause> only where vehicles get actually stopped in the depot
20:47:29 <Eddi|zuHause> but this stuff seems to have moved around
20:50:53 <Rubidium> then why call that function for *all* vehicles instead of only the stopped ones
20:53:22 <Eddi|zuHause> no, it just carries around a counter
20:53:38 <Eddi|zuHause> and does special stuff if the counter gets to 1
20:54:15 <Eddi|zuHause> anyway, searching where the vehicle stopping went...
21:04:28 *** Brianetta has joined #openttd
21:14:43 <CIA-4> OpenTTD: rubidium * r17618 /trunk/src/network/network.cpp: -Fix [FS#3226]: the 'lock' icon would erroneously be drawn for companies if the company had a password before the reset
21:24:15 <Eddi|zuHause> hm... lots of conflicts beecause of "InvalidateWindow" in context lines...
21:33:25 <Terkhen> SmatZ: you were right, I found two bugs testing some corner cases
21:35:31 <Terkhen> the first one was that, once that the OSKWindow was opened and closed, the editbox widget wouldn't update correctly if persistent tools was active... this was caused by some missing / incorrect code, the needed corrections are here: http://paste.openttd.org/216993
21:36:25 <SmatZ> Terkhen: please post that to FS, I am almost in sleeping state now :)
21:37:16 <Terkhen> I will post both of them and go to bed
21:53:49 *** andythenorth has joined #openttd
21:59:48 *** andythenorth_ has joined #openttd
22:17:34 *** andythenorth has joined #openttd
22:29:36 *** andythenorth has joined #openttd
22:42:01 *** tokai|mdlx has joined #openttd
22:50:40 <CraKinShOt> well the principle of having the m2 in the signalex pool, if the tile has one, works
22:57:30 <Eddi|zuHause> so... i think i removed all conflicts, except gui stuff...
22:58:01 <Eddi|zuHause> i'll see about that toorrow
22:59:10 <Eddi|zuHause> see, that's why :p
22:59:26 <Chris_Booth> Sleepy Eddi|zuHause
23:10:39 <CraKinShOt> well I've solved my problem
23:10:45 *** Coco-Banana-Man has quit IRC
23:10:58 <CraKinShOt> bit of rearrangement
23:14:33 <Rubidium> try running the windows version of OpenTTD through darwine
23:15:25 <Rubidium> or something like: ask the wine people for help
23:16:11 <Eddi|zuHause> ah, so he's saying "People on OSX should run the win32 binaries"?
23:16:46 <Eddi|zuHause> well, good luck ;)
23:16:51 <Rubidium> (in my interpretation of the post)
23:19:45 <tokai|mdlx> Can't a pure SDL version of OpenTTD work on Mac OS X? Just wondering...
23:20:32 <tokai|mdlx> Wine on Mac OS X (Darwine) is rather crap IMHO.
23:20:38 <Ammler> the only difference from opengfx compile with or without renum is the first sprite with the number of sprites, does that matter?
23:20:48 <tokai|mdlx> Doesn't work properly for me at least. Can't imagine someone want to play OpenTTD over it.
23:21:18 <Rubidium> but... SDL doesn't do the special iconv needed for OSX etc.
23:22:23 <tokai|mdlx> I'm a bit busy currently with other things still; but hope in next weeks find some time to bring the MorphOS port up-to-date again... people are bugging me already:)
23:23:03 <tokai|mdlx> Can't use the excuse "just play it on Mac OS X for now" anymore, I guess :D
23:24:32 <Rubidium> and based on that it looks like SDL doesn't want to be statically linked, so the compile farm won't be able to compile it anyways
23:24:46 <Rubidium> which makes the official support kinda drop dead too
23:26:28 <tokai|mdlx> Maybe SDL for Mac OS X has improved in the meantime? :)
23:26:49 <tokai|mdlx> 4 years allow some room for that I guess.
23:27:04 <Rubidium> good luck finding someone to test the CF :)
23:32:49 <CraKinShOt> update that handles the m2 shift
23:33:05 <CraKinShOt> needs cleaning up.
23:33:10 <CraKinShOt> good night all. :)
23:33:14 *** Eddi|zuHause has joined #openttd
23:35:31 <Rubidium> someone's going for a dry wine?
23:42:38 <Eddi|zuHause> if ((_settings_client.gui.advanced_vehicle_list > (uint)(company != _local_company)) != _ctrl_pressed) { <--- ok, which insane person comes up with such a check :p
23:44:34 *** KenjiE20|LT has joined #openttd
23:57:27 <Eddi|zuHause> + VLW_WIDGET_FAKED_SCROLLBAR, <-- something sounds awfully wrong with this
continue to next day ⏵