IRC logs for #openttd on OFTC at 2007-11-02
⏴ go to previous day
00:05:02 *** wolfryu has joined #openttd
00:10:09 *** Smoovious has joined #openttd
00:10:27 * Smoovious touches the brim of his black hat.
00:11:14 <TrueBrain> Starting server at port 8080
00:11:14 <TrueBrain> File /www/stackless/webtt/map.py changed, reloading server..
00:11:14 <TrueBrain> Starting server at port 8080
00:12:10 *** AntB is now known as Guest137
14:06:10 *** DorpsGek has joined #openttd
14:06:10 *** ChanServ sets mode: +o DorpsGek
14:06:15 *** dihedral has joined #openttd
14:21:39 *** mikk36|w has joined #openttd
14:23:05 *** pPACO_BAN has joined #openttd
14:25:33 *** Phazorx is now known as Guest205
14:25:33 *** pPACO_BAN is now known as Phazorx
14:29:09 *** Ammlller is now known as Ammler
14:31:51 *** lolman is now known as John
14:31:59 *** John is now known as lolman
14:38:03 <Ammler> hmm, you made the grf2html tool, would it be easy possible to make a tool, which converts vehicle sets to other IDs
14:39:28 <Ammler> I saw foobar did a proposal to use for vehicle IDs, I fear now, that i.e. all tram sets will have same ID area and you can't use them together. Some like that...
14:39:58 <frosch123> Have you tried ActionD variable 99?
14:40:30 <Ammler> oh, you mean its possible with a grf?
14:40:38 <Ammler> no need to change the existing grf?
14:41:36 <Ammler> hmm, can't load the wiki page atm
14:41:48 <frosch123> I guess you have to place that ActionD at the start of the grf, or perhaps after the Action8.
14:42:34 <frosch123> But my nfo knowledge is rather passive, i.e. I can read a lot, but have written hardly any.
14:43:06 <Ammler> my idea was to have a tool which "scans" the grf and print out the used IDs and then encode it with new IDs if needed.
14:43:49 <frosch123> That won't work with callbacks. Ooops, I guess the ActionD will not work with callbacks either.
14:44:13 <Belugas> Ammler, this is not a good idea. you are modifying the work of someone else. bad bad bad. you'd better ask the author then
14:44:15 <frosch123> (I mean callbacks like the articulated one)
14:44:38 <Ammler> Belugas: of course the autor's permission is needed
14:46:05 <Ammler> frosch123: callbacks could changed too, not?
14:47:21 <frosch123> Ammler: That will require the intelligence of a human as it has to understand how the grf works.
14:48:33 <Ammler> Belugas: what do you think, technically should be possible, not?
14:50:12 *** Wolf01 is now known as Guest209
14:50:55 <Belugas> i agree with frosch123
14:51:15 *** Digitalfox has joined #openttd
14:56:05 <Belugas> that command is only valid in #openttdcoop (or somehting like that) byq
14:59:30 *** Digitalfox_ has joined #openttd
15:02:01 *** Digitalfox_ has joined #openttd
15:08:05 <Ammler> hmm, Action D variable 99 sounds very interesting, is there a Set which does use that?
15:15:51 <frosch123> Don't know, all sets that I saw using GRM, only checked if their fixed IDs are available. I have not seen one with dynammic IDs.
15:21:31 *** Unknown_Entity has quit IRC
15:25:18 *** Osai is now known as Osai^Kendo
15:48:04 *** Diabolic1Angel is now known as Diabolic-Angel
16:02:04 *** Markkisen has joined #openttd
16:06:49 <Markkisen> Where is Bjarne? :o
16:09:19 <Belugas> not connected right now, so it seems. And i'm pretty sure it is Bjarni, not Bjarne...
16:09:29 <DorpsGek> TrueBrain: Bjarni was last seen in #openttd 1 day, 14 hours, 33 minutes, and 1 second ago: <Bjarni> you guys can try to stop me, but it won't work :P
16:09:58 *** Wolf01 is now known as Guest213
16:10:55 <Ailure> do anyone else than me use silly placeholder names in their programs?
16:11:33 <Ailure> I seem to unusually often create a integer variable with the name lol too often XD
16:12:08 <ln--> bjarni must be busy with the kangaroo.
16:13:12 <hylje> Ailure: i tend to not have placeholders..
16:13:24 <Ailure> mine are mostly for testing
16:13:43 <hylje> well yes, i have single letter vars for the interactive prompt.. :>
16:13:50 <Ailure> I make them stupid so I feel forced to replace the mlater with something more proper
16:14:45 <Ailure> and sometimes I wind up with long names for references
16:14:51 <Ailure> like "signatureSigFilePathTextField"
16:15:04 <Belugas> why not make them explicit right away? easier to debug...
16:16:04 <Ailure> I don't release my code in that state
16:16:28 <Ailure> sometimes I wind up with really strange names
16:17:18 <Ailure> or at least, they did sound silly when I made them
16:26:12 *** lolman is now known as John
16:31:23 *** Wolf01 is now known as Guest214
16:39:20 *** Progman has joined #openttd
16:41:50 *** skidd13 has joined #openttd
16:44:39 *** dexterle has joined #openttd
16:45:21 <dexterle> do you know anything about the openttd console?
16:45:37 *** Wolf01 is now known as Guest220
16:45:45 <Ailure> the one that comes up when you press the tilde key on american keyboards?
16:46:04 <Ailure> what exactly do you need help about anyway
16:46:35 <dexterle> i want to know, if there is any command or way to destroy a whole company in a multiplayer game, because i cant buy it completly
16:47:29 <TrueBrain> also feel free to visit our wiki :)
16:47:29 <Ailure> You can see a list of commands by typing list_cmds btw
16:47:47 <skidd13> Can I hear some comments to FS1390 please.
16:47:49 <Ailure> and then use help on that spefic command to see what it do
16:47:50 <dexterle> ahh oki, didnt know that, thank you
16:48:11 * Belugas is looking at it right now, while eating his lunch
16:49:37 <skidd13> Belugas: "Mahlzeit!" (I don't know a fitting translation and "Have a nice meal" has a slight other meaning IMO)
16:49:49 <TrueBrain> skidd13: looks good to me
16:49:55 <dexterle> have a nice meal is a good translation
16:49:57 <TrueBrain> skidd13: and forget it to say something like that in English, there is no good way :)
16:50:21 <Belugas> "bon appetit" can be said :)
16:50:33 <TrueBrain> which is French, still no English :P
16:50:59 <Belugas> i know at least two devs who do ;)
16:51:15 <Belugas> and a few more who understand it!
16:51:26 <TrueBrain> Belugas: I think in fact most devs understand it :)
16:51:42 <Belugas> skidd13, it looks really good
16:51:58 <Belugas> TrueBrain, if you feel 100% secure, could you commit it?
16:52:06 <TrueBrain> I was about to ask you:
16:52:11 <TrueBrain> if you feel 100% secure, I will commi tit
16:52:20 <skidd13> And it seems to be a bit faster too. :)
16:52:49 <glx> <skidd13> And it seems to be a bit faster too. :) <-- don't say that without benchmarking :)
16:53:19 <Belugas> TrueBrain, i think skidd13 means it will be faster if you commit it than relying on me to do so :D
16:53:24 <TrueBrain> skidd13: but that is as useless as telling us you made a REALLY cool feature.. and then nothing :)
16:54:01 <TrueBrain> Belugas: that is why I suggested to commit it ;) I just wanted to make sure I didn't miss anything which might be wrong :p Hehe :)
16:54:15 <Belugas> another easy would be to grant skidd13 commit access, but allowed only after veto by devs
16:55:15 <Belugas> i know about that one, it is on my todo
16:55:29 <skidd13> The speedup will depend on the compiler either. So there won't be a general statement ever.
16:55:42 <Belugas> but as i told BigBB recently, i'm not available to do anything until wednesfay at least
16:56:08 <glx> skidd13: why moving template <...> ?
16:56:33 <TrueBrain> glx: all other entries in macros.h do
16:56:38 <skidd13> glx: I adapted it cause all templates are formated this way (at least in the file)
16:56:45 <TrueBrain> Belugas: I thought, while reading thisone... ;)
16:58:05 <CIA-1> OpenTTD: truelight * r11369 /trunk/src/ (macros.h road_cmd.cpp):
16:58:05 <CIA-1> OpenTTD: -Codechange [FS#1390]: changes some int to int8 in macros.h, as they describe a bit-position, which fits perfectly in an int8 (max 64) (skidd13)
16:58:05 <CIA-1> OpenTTD: -Codechange [FS#1390]: added consts in macros.h functions, so compilers can optimise better (skidd13)
16:58:05 <CIA-1> OpenTTD: -Codechange [FS#1390]: remove HAS_SINGLE_BIT, as COUNTBITS does the same (skidd13)
16:58:13 <skidd13> I like tidiness in code and uniform code flow. :) That was the most reason.
16:58:20 <Belugas> TrueBrain, i've read it a few times, seems to be fine. nothing that hurt my eyes
16:59:19 <TrueBrain> Belugas: same here :p
16:59:57 <TrueBrain> so if it compiles, let's commit it ;)
17:00:09 <TrueBrain> nice work btw, skidd13
17:01:37 <skidd13> No problem. I'm thinkin over a nice way to replace the GB/SB/etc. macros with static inline functions now.
17:01:41 <Eddi|zuHause3> where have all my GB gone...
17:02:27 <TrueBrain> skidd13: btw, about 1390, the code looks fine, but the GUI isn't really... nice..
17:02:32 <TrueBrain> it looks a bit ugly now, if you ask me..
17:02:47 <skidd13> TrueBrain: Anything in mind?
17:02:52 <TrueBrain> and in my opinion, I still think Capacities and Total Cargo should be 1 tab
17:02:58 <TrueBrain> I never understood why it isn't..
17:03:18 <skidd13> The reason is that it looks IMO overcrowded then.
17:03:20 <TrueBrain> in fact, Cargo and Capacity could be 1...
17:04:12 <TrueBrain> skidd13: possible, but with the things like Weight, Power, MaxSpeed, Max TE, it already is overcrowded ;)
17:04:24 <skidd13> Maybe a matrix with all the stuff in it could be the solution.
17:04:58 <TrueBrain> indeed sounds like a solution
17:05:02 <TrueBrain> but this adds yet an other line...
17:05:13 <TrueBrain> same as with Orders, it needs a GUI redo too :p
17:05:44 <skidd13> But ATM I don't feel like I want to recode the whole details GUI to matrix style :P
17:06:02 <TrueBrain> every time so far people said: wait for cpp_gui
17:06:07 <TrueBrain> but I dunno if that ever finishes...
17:06:32 <skidd13> Apropos order GUI There is much duplicated code with the timetable.
17:06:38 <Phazorx> TrueBrain: i have a request for shared patch enhancement :)
17:06:56 <Phazorx> could be a tricky one tho
17:08:08 <Eddi|zuHause3> gnah, i don't even have enough space to properly free some space...
17:08:14 *** Wolf01 is now known as Guest224
17:08:14 *** Wolf01|AWAY has joined #openttd
17:08:15 *** Wolf01|AWAY is now known as Wolf01
17:08:29 <Phazorx> you need space to get space?
17:08:55 <Eddi|zuHause3> yeah, it's called temporary space ;)
17:09:17 <skidd13> Eddi|zuHause3: there is a lot of space in /dev/null :P
17:10:12 <Eddi|zuHause3> yeah, but to prove wether that is "proper" might be tricky :p
17:10:43 *** Progman has joined #openttd
17:10:43 <Belugas> Coffee Flavoured Chewy Granola Bar :D
17:10:50 <fjb> Eddi|zuHause3: You can compress any file to the size of one byte. :-)
17:11:07 <Phazorx> TrueBrain: it would be nice if companies using shared drops would get a benefit from it, say a percentage increase of income (since using shared would mean exporting)
17:11:28 <skidd13> fjb: Yeah lossy zip rules :D
17:11:35 <Eddi|zuHause3> fjb: i'm not sure if "one" byte is a significant improvement over "null" bytes :p
17:11:51 <Phazorx> so perhaps when a train drops something at foreign station (which can only be shared) it gets like 2x the income
17:12:03 <fjb> Eddi|zuHause3: That are 8 bits more.
17:12:22 <Eddi|zuHause3> again: "significant" is the keyword
17:14:20 <Eddi|zuHause3> "help, i temporarily copied an important file to /dev/null like you suggested, but when i am trying to copy it back now, i cannot access it anymore" :p
17:15:24 <Belugas> hello mister commiter :)
17:15:54 <DaleStan> I'm reminded of tales of deleting this large file named "vmlinuz" that no one seems to be using.
17:16:21 <fjb> Eddi|zuHause3: Just take the backup. You know, you should have a backup of every important file.
17:16:30 <Eddi|zuHause3> DaleStan: that is fine, until you reboot your computer ;)
17:16:54 <Phazorx> DaleStan: it supposed to be <1M not that large actually
17:17:00 <fjb> DaleStan: That story is much older than Linux... :-)
17:17:31 <skidd13> Eddi|zuHause3: Why should be that a problem? boot your knoppix change the root dir to the HD and install your own compiled kernel again ;)
17:17:46 <TrueBrain> try removing /proc/mem, or /proc/kernel :p
17:17:50 *** Tlustoch has joined #openttd
17:17:56 <fjb> At the times it happened 1MB was a significant part of the hard drive.
17:18:05 <DaleStan> that is fine, until you reboot your computer <-- So I'm told. I think I'll just believe the the stories, rather than trying to booting a Linux system without it, TY*V*M.
17:18:49 <TrueBrain> skidd13: I dunno, depends on the type of 'x' I guess
17:19:16 <skidd13> TrueBrain: It shouldn't IMO.
17:19:23 <TrueBrain> skidd13: that is _very_ dangerous what you wrote there
17:19:27 <TrueBrain> you CHANGE the CONTENT of 'x'
17:19:33 <TrueBrain> so, if it is a const, it cna't work
17:19:43 <TrueBrain> but... it gives very unexpected results ;)
17:20:00 <TrueBrain> int x = 3; GB(x, 1, 1); printf("%d\n", x); <- shows 2 :p
17:20:15 <TrueBrain> so, it is wrong how ever you look at it ;)
17:20:23 <TrueBrain> skidd13: no, a constant, as, say, you want to do: GB(0xFF, 1, 1)
17:20:42 <skidd13> Ah that are you talking about. Yup agreed.
17:21:03 <TrueBrain> that really should be there ;)
17:22:46 <skidd13> return (T)(x >> s) & (T)((1U << n) - 1); // Same error :(
17:22:54 <Phazorx> TB no word on my RFC?
17:22:57 <TrueBrain> then I wouldn't know :)
17:23:17 <TrueBrain> skidd13: what is 'T' when the error happens?
17:24:12 <Eddi|zuHause3> hm, i have 1GB free swap... i should make use of that :p
17:24:18 <skidd13> TrueBrain: »int« to »DiagDirection«
17:24:47 <TrueBrain> (T)((1U << n) - 1) <- isn't that part a problem? It might not be in DiagDirection...
17:25:30 <skidd13> The cast should fix that IMO
17:25:32 <TrueBrain> skidd13: why is the return value T anyway?
17:25:48 <TrueBrain> isn't the return value bool?
17:26:05 <TrueBrain> confusing shit, those names
17:26:55 <TrueBrain> skidd13: say, 1 << n returns 0x40, -1 makes it 0x3F, maybe the compiler is clever enough to notice that isn't in DiagDirection
17:27:01 <TrueBrain> so, try not to cast back to T until the end
17:27:33 <TrueBrain> (T)((x >> s) & ((1U << n) - 1))
17:27:51 <TrueBrain> (btw, s and n should be uint8 ;))
17:28:14 *** Wezz6400 has joined #openttd
17:28:23 <glx> GB has no type, it's just an int
17:28:38 <TrueBrain> (uint64)((x >> s) & ((1U << n) - 1))
17:29:23 <skidd13> For all the stuff? GB/SB/etc.
17:29:23 <skidd13> glx: If you feed GB with an uint8 it should return an uint8
17:30:37 <glx> the problem is other types
17:30:41 <Belugas> anyway, i'm back at work... so... /me disappear
17:31:54 <glx> "incomplete" types, like DiagDirection
17:33:04 <skidd13> glx: Hmm, true. So I'd say the return is an uint, isn't?
17:34:52 <skidd13> I'm thinking over TrueBrain's statement that >> -x is invalid.
17:34:52 <skidd13> Is >> -x defined as << x?
17:35:12 <glx> or maybe use T& like other templates
17:35:44 <Eddi|zuHause3> <skidd13> Is >> -x defined as << x? <- i would not bank on this
17:36:23 <Eddi|zuHause3> i'd avoid anything outside 0..bitsize
17:37:13 <glx> yeah like TB said, n and s should be uint8
17:41:33 <Eddi|zuHause3> what i'd rather expect ">> -x" to do (assuming 32bit) is to slice out the last 5 bits of the representation of "-x", and shift by that value (unsigned)
17:42:43 <Eddi|zuHause3> which is completely not what you wish it to do ;)
17:50:21 *** Deathmaker has joined #openttd
17:51:10 <skidd13> Then many of the ints in macros.h have to be uint
17:54:25 <skidd13> glx: assuming that GB returns 32bit seems to slow down the whole stuff. This needs benchmarking. returns GB ever more than 16 bit?
17:56:43 <skidd13> Damn this macro is widely used. Not shortly to check :(
17:59:48 <skidd13> Erase my last sentence. assert(n <= 16); is short :)
18:08:26 *** liona29 has joined #openttd
18:12:13 *** Wolf01 is now known as Guest227
18:21:01 <skidd13> F*** NewGRF uses 24 bit :(
18:21:01 *** LeviathNL has joined #openttd
18:21:11 <skidd13> so no downsizing to 16 bit
18:22:12 <DaleStan> My understanding was that 16-bit is usually slower than either 8 or 32 bit.
18:23:01 <DaleStan> At least for x86 processors.
18:23:14 <skidd13> DaleStan: I'm not sure, but the inline function *seems* to be slower. Maybe different from OS to OS
18:23:57 <DaleStan> If there's a difference, it's more likely processor to processor.
18:30:47 <skidd13> do some of the internal types base on the 64 bit type?
18:31:01 *** ChanServ sets mode: +v tokai
18:32:24 *** Brianetta has joined #openttd
18:37:38 <TrueBrain> DaleStan: in fact, 32bit (or 64bit) is always faster. Next in 32bit for 64bit, then 8bit, third it 16bit. 24bit is impossible slow ;)
18:38:05 <skidd13> Hmm. Does anyone use SB with money as 4th argument?
18:38:21 <TrueBrain> skidd13: doubtful ;)
18:38:32 <TrueBrain> still, currently SB and GB can handle anything
18:38:43 <TrueBrain> if inlining means loosing that, I don't know if it is such a good idea
18:39:17 <skidd13> Is it possible to have to template values?
18:43:54 <skidd13> TrueBrain: I won't lose the anything handle stuff, but it'll secures itself for missusage ;)
18:58:57 <skidd13> should work well. But now I'm starting to like converting this stuff to templates :) More to come...
19:21:01 *** thgergo has joined #openttd
19:32:02 *** raimar2 has joined #openttd
19:40:02 *** BiA|pavel-css has joined #openttd
19:50:51 <skidd13> Thanks and good night
19:59:08 <fjb> Ups, the auto replacement window tell me that I habe 65535 locomotives of one kind...
20:00:36 <fjb> Was the code recently changed?
20:00:38 <Eddi|zuHause3> savegame, way to reproduce -> bugs
20:03:07 <fjb> I have to register first?
20:03:44 *** Tlustoch has joined #openttd
20:15:45 *** Sacro` is now known as Sacro
20:17:35 *** egladil has joined #openttd
20:31:12 *** DorpsGek` has joined #openttd
20:31:12 *** ChanServ sets mode: +o DorpsGek`
20:31:48 *** Eddi|zuHause2 has joined #openttd
20:33:05 *** MiHaMeK has joined #openttd
20:33:13 *** __karma has joined #openttd
20:33:18 *** wolfryu has joined #openttd
20:33:19 *** blathijs_ has joined #openttd
20:33:30 *** wolfryu is now known as Wolfensteijn
20:33:47 *** Diabolic-Angel has quit IRC
20:33:54 *** stillunknown has joined #openttd
20:33:57 *** Diabolic-Angel has joined #openttd
20:34:10 *** Dark_Link^ has joined #openttd
20:34:10 *** DorpsGek` is now known as DorpsGek
20:35:05 *** XeryusTC has joined #openttd
20:36:44 *** egladil has joined #openttd
20:37:01 *** ChanServ sets mode: +v tokai
20:38:53 <Jello> i was told to come here for help on openttd
20:38:53 *** Rexxars has joined #openttd
20:43:54 <fjb> Jello: What help do you need?
20:44:18 *** LeviathNL has joined #openttd
20:45:51 <Ammler> fjb: it sounds more he likes to help you :P
20:48:46 * Belugas thinks it is more than late enough to try to keep on working
20:49:08 * Belugas leaves the office and wishes you all a good weekend
20:50:23 * hylje wishes the same for Belugas in third person
20:50:41 <fjb> E52 is cool, I wish it would be a bit more reliable.
21:07:12 *** thgerg1 has joined #openttd
21:08:57 <fjb> Is there a separate switch that unhides the one way road markers?
21:09:48 <fjb> Hm, sorry, forget that question
21:51:56 *** dihedral has joined #openttd
22:28:46 *** Ammller has joined #openttd
22:33:34 *** skidd13 has joined #openttd
22:34:12 <TrueBrain> skidd13: a moment ago I did some testing on GB, inline or macro; the results don't show a clear faster or slower
22:34:25 <TrueBrain> with -O0 it likes GB macro more ;)
22:34:40 <TrueBrain> with -fno-inline, the macro wins bigtime
22:34:43 <TrueBrain> but... that is a dah ;)
22:35:08 <skidd13> And with the default -O2? Wich compiler and wich OS?
22:35:32 *** dihedral has joined #openttd
22:36:12 <TrueBrain> default -O2 was inconclusive
22:36:42 <TrueBrain> it was just a quick single-program test
22:36:48 <TrueBrain> it should be test in OpenTTD to give more details :)
22:36:55 <skidd13> But the inline should be safer to use IMO.
22:37:41 <Rubidium> it makes debugging harder/more time consuming (at least for me)
22:37:43 <skidd13> I'd like to hear some benchmarks form our redmond friends ;)
22:38:14 <TrueBrain> if you run in dbg lvl 3 (which in general I advise against), it would be dead slow
22:38:20 <TrueBrain> as that adds the -fno-inline
22:39:33 <Rubidium> TrueBrain: true... but... the backtraces are usually messed up without -fno-inline, and when getting some hard to fix/find issue fixed I'd like to have proper backtraces.
22:39:57 <TrueBrain> Rubidium: I personally only used -fno-inline just twice since the new makefile system
22:40:13 <TrueBrain> so personally, I don't see the problem with inlines over macros
22:40:41 <TrueBrain> but that is just because I have no problems addings a bunch of printfs to locate the exact problem, and because most inlines are assert protected, which give pretty clear results
22:43:58 *** Zaviori has joined #openttd
22:46:41 <Rubidium> oh... mr. Bounding Box ;)
22:47:24 *** LeviathNL has joined #openttd
22:49:08 <Markkisen> Naaw, my cat i so cute <3
22:49:19 <Markkisen> I just want to cuddle her to death
22:49:46 <TrueBrain> okay, you are scaring me
22:50:19 <Markkisen> She is having kittens in a couple of days (:
23:12:10 <Eddi|zuHause2> hm... cultrual victory, that was too easy...
23:19:19 <valhallasw> TrueBrain: webtt? map.py? :O
23:19:34 <TrueBrain> valhallasw: what? where?
23:19:34 <valhallasw> that was the result of letting irssi stay a day behind
23:20:26 <valhallasw> you posted something /www/webtt/map.py-is last night... where my irssi window stopped scrolling
23:33:47 <skidd13> Does somewhere in the code is the sqrt function is used?
23:34:27 <TrueBrain> grep is your friend :)
23:35:10 <skidd13> grep does not found anything IIRC
23:35:34 <skidd13> but maybe someone wrote someting similar like the stuff with the countbits
23:36:09 <skidd13> :%s /anything/anything code related/
23:41:01 <skidd13> I'm asking cause I strumbled over this nice piece of code:
23:44:52 <TrueBrain> anyway, we try to avoid floats in general
23:44:59 <TrueBrain> but there should be a few sqrts
23:46:17 <skidd13> The coding stuff in q_math is impressive. I'm reading through. Maybe there is some stuff that might be usefull
continue to next day ⏵