IRC logs for #openttd on OFTC at 2008-10-25
⏴ go to previous day
00:01:58 *** Sacro|Laptop has joined #openttd
00:33:12 *** Eddi|zuHause has joined #openttd
00:42:40 <fjb> H, x |= 2 sets the second bit of x. But how do i clear only the second bit?
00:45:04 <fjb> "x |= 2;" sets the second bit. But how do I clear it without clearing any other bit?
00:45:34 <ben_goodger> I thought H was a parameter
00:46:28 <fjb> Sorry, was lazy typing late at night.
00:46:49 <ben_goodger> er... perhaps "x |= 2;" again? can you AND only the second bit, with 0?
00:49:44 <fjb> | means or, so "x |= 2;" again does not work, 1 or 1 is still 1. I don't know if I can use & with only one bit. Maybe I should go to sleep and think about it tomorrow.
00:50:44 <ben_goodger> I shall retire also, with a book on finance
00:51:38 <ben_goodger> good morning to you
00:51:41 <fjb> Hm, x = x & ^2 cound work.
00:52:07 <Aali> fjb: x &= (binary NOT) 2
00:52:43 <Aali> yeah, my current setup can't do that character, apparently
00:52:58 <Aali> dunno if its the keyboard or synergy or whatever
00:53:28 <Aali> and x ^= 2 to toggle the bit
00:54:11 <ben_goodger> gah! I thought "NOT", then I thought there wasn't any such operation
00:54:15 <fjb> Great. Still a bit late for bit flipping with C.
00:54:17 <ben_goodger> so close to glory!
01:30:50 *** roboboy has joined #openttd
01:31:41 *** roboboy has joined #openttd
01:59:47 *** Frostregen_ has joined #openttd
01:59:57 *** Frostregen_ is now known as Frostregen
02:20:19 *** Digitalfox has joined #openttd
02:22:54 *** Digitalfox has joined #openttd
03:07:55 *** elmex_ is now known as elmex
03:25:17 *** grumbel has joined #openttd
06:17:14 *** Alberth has joined #openttd
07:38:43 *** Progman has joined #openttd
07:44:32 *** Eddi|zuHause has joined #openttd
07:48:48 *** FloSoft has joined #openttd
08:17:16 *** Vikthor has joined #openttd
08:26:16 * TrueBrain waves hello to this channel
08:26:21 <TrueBrain> and sadly enough, also goodbye :) Back tomorrow :p
08:26:45 <Rubidium> poor TrueBrain :( too much worky to do
08:27:32 <TrueBrain> almost finished .. I hope
08:59:41 *** Wezz6400 has joined #openttd
09:02:29 <Roujin> i have a somewhat stupid question: can I (and if so, how) get some kind of call trace when my patched ottd asserts somewhere? currently using gcc on linux to build
09:03:20 *** mortal` has joined #openttd
09:03:24 <FloSoft> build with debug symbols and the use gdb?
09:06:25 *** mortal` is now known as mortal
09:06:54 <Roujin> thanks FloSoft, trying to figure it out now :)
09:09:49 *** mortal` has joined #openttd
09:10:12 <Eddi|zuHause> hm... "Windows-Native GUI?" <- no game that takes itself serious in the last 15 years has used a "native gui"
09:10:22 *** mortal is now known as Guest251
09:10:22 *** mortal` is now known as mortal
09:13:39 <Alberth> Roujin: you may have to set unlimited core dump file size too. ('ulimit -a' to view current settings). After crash, program will dump core, which you can load in gdb
09:17:07 <Roujin> uhm, thanks, but already worked it out :)
09:17:54 <Roujin> gdb -> run -> [wait until assert] -> backtrace did the job
09:19:06 <Eddi|zuHause> petern: some thread in the suggestions forum demands a windows native gui
09:21:26 <Roujin> isn't it kind of a hack that the code figures out if a vehicle is on a bridge or on a tunnel depending on if its state is "hidden" or not?
09:21:43 <Roujin> there must be a better way to do this...
09:21:43 <Alberth> Roujin: with core dump you can run outside the debugger. I run OpenTTD by default in this way.
09:25:29 *** frosch123 has joined #openttd
09:28:06 *** Yeggstry has joined #openttd
09:35:43 <Eddi|zuHause> Roujin: one option that came up when discussing signals on bridges was that you could have (virtual) "wormhole tiles" (which could later be extended to real tiles that are stored in some kind of 3D-map array for above and below surface infrastructure)
09:39:47 <Eddi|zuHause> the advantage of that was that you could then give a vehicle enter tile function similar to the other tiles
09:40:15 <Eddi|zuHause> which is kind of necessary for trains to stop in front of signals
09:51:54 <Roujin> i currently changed vehicles to be transparent instead of invisible while going through tunnels - looks cool so far, but I still get an assert when reversing a train partially in the tunnel
09:54:20 <Gekz> who was the guy who wanted to buy my P3 mobo
09:56:39 <dih> whats with implementing tcl as console language :-D
10:00:07 *** stillunknown has joined #openttd
10:00:46 <Gekz> therefore no-one can use it
10:01:05 * Gekz has to stop saying "x is shit" without stating "I believe that"
10:04:14 <dih> you may hate it, but only because you are not used to it
10:04:29 <dih> also i am enjoying erlang
10:04:35 <Gekz> I don't like it because it's ugly as hell
10:04:38 <Gekz> and has nothing over any other language
10:04:43 <dih> and just because you dont like it does not mean nobody can use it
10:04:56 <Gekz> dih: your native language is not english?
10:05:08 <Gekz> English humour is hard to grasp.
10:05:52 <Gekz> that doesnt answer my question
10:05:57 <Gekz> I'm half dutch and dont speak any dutch
10:07:04 <DorpsGek> Gekz: I haven't seen anyone matching pirate*.
10:07:10 <DorpsGek> Gekz: welshpirate was last seen in #openttd 5 weeks, 1 day, 10 hours, 43 minutes, and 50 seconds ago: <welshpirate> ln-, nay
10:07:50 <dih> anyway - the nice thing with tcl over say squirrel would be that you would not need brackets to pass arguments
10:10:44 * fjb votes for perl and hides.
10:12:36 <Eddi|zuHause> you can hide, but cannot run.
10:20:14 <dih> seriously i dont think it's such a bad idea :-P
10:20:20 <dih> using tcl as console language
10:20:29 <dih> you would not even notice if you did not want to write scripts
10:22:47 <Eddi|zuHause> it makes absolutely no sense to maintain more than one scripting engine (virtual machine, API)
10:24:33 <dih> as much as it does writing your own for ai's
10:25:01 <dih> besides - who sais it has to be a must?
10:25:16 <dih> i.e. if you want tcl support, compile it yourself with --enable-tcl ?
10:26:16 <Eddi|zuHause> nobody said compiling... i said maintaining
10:26:54 <CIA-5> OpenTTD: rubidium * r14527 /trunk/src/sound.cpp: -Fix: allocate stub (empty) sound entries when loading an empty/corrupt/incorrectly sized sample.cat instead of making valid NewGRFs fail to load.
10:27:19 <Eddi|zuHause> and afaik the reason for designing an own language was that 3rd party VMs had threading problems and memory leaks all over the place
10:27:58 <Rubidium> not to mention issues with suspending
10:29:27 <dih> the great support for unsigned int
10:29:37 <dih> and afaik that is not even planed for NAIL
10:30:35 <dih> + when you hear 'needs complete rewrite' and it should replace squirrel?
10:31:06 <Eddi|zuHause> i have no idea what you are talking about
10:31:57 <Eddi|zuHause> that one i got before you were babbling incoherently
10:33:31 <Eddi|zuHause> the 4 lines before i said i don't understand you
10:34:09 <dih> squirrel nor nail support unsigned integers
10:34:22 <dih> guess what the seed is e.g.
10:34:57 <Eddi|zuHause> you should discuss that with TrueBrain, i suppose
10:35:26 <dih> happened many times before
10:35:27 <petern> they're both 32 bit values, what's the problem?
10:36:18 <dih> say you wanted to implement a scripting language into the console
10:36:36 <dih> say someone then comes along and wants to check on the money a certain company has
10:36:55 <dih> or if you want to generate the seed
10:37:10 <dih> if the scriting language does not support those data types it sucks
10:37:14 <petern> i don't particularly see the need for a scriptable console
10:37:29 <dih> you see the need for rewriting the console?
10:37:41 <dih> the way commands / arguments are handled is not really good
10:37:45 *** Doorslammer has joined #openttd
10:37:55 <petern> and money is signed anyway, so that's a useless excample
10:38:19 <petern> you were complaining about a lack of unsigned integers
10:39:22 <dih> so are you more after ditching the console all together?
10:39:31 <dih> i would doubt that to be honest
10:39:40 <petern> i see no problem with the existing console
10:39:59 <dih> it lacks a lot, a lot it could do
10:40:25 <petern> a scripting language won't help adding commands much
10:40:32 <dih> and scripting support would be useful to let admins make their servers more 'unique'
10:40:42 <dih> and you could add a bunch of handling to that
10:40:50 <dih> + it would let clients to a bunch of automated stuff too
10:41:06 <planetmaker> a toast on Rubidium for the last commit :)
10:41:07 <dih> current console is kinda frozen
10:41:25 <Alberth> petern: a scripting language tends to streamline that process
10:41:56 <dih> and afaik the console is not getting additions because it's not worth putting any effort into _that_ console
10:41:58 <petern> no further additions are necessary to do what is needed
10:42:31 <petern> about the only extra thing i can think of is allowing an admin to reset a company password
10:42:43 <petern> and a scripting language won't help that
10:42:56 <dih> i can think of a wee bit more
10:43:43 <dih> or support for getting id's of clients by their nicks
10:43:53 <dih> as every command uses the id not the nick
10:44:01 <dih> and all you get on the console when someone joins is the nick
10:44:13 <dih> callback's dont take arguments
10:44:29 <Alberth> dih: In Python they do :D
10:44:31 <dih> so when a new client joins you can only greet him in public
10:45:09 <dih> when a company goes bankrupt - console never sees a thing of that
10:45:33 <petern> scripting won't help that
10:45:35 <Alberth> dih: you see it as a kind of irc chat window?
10:45:36 <dih> move clients between companies (inc. spectator)
10:45:51 <dih> petern: scripting would help
10:46:08 <dih> say_client( get_client_id( 'foobar' ), "welcome");
10:46:35 *** NukeBuster has joined #openttd
10:47:14 <petern> i would not object to something being added
10:47:20 <petern> but i will not expend any time doing it
10:49:42 <dih> but that is the first time in about 3/4 year i have heard that
10:50:23 <dih> perhaps you devs should have a get2gether and see if you all are supporting the same idea
10:50:36 <dih> it's kinda not so helpful if 3 devs say x and 2 say y
10:58:21 *** welshdragon2 has joined #openttd
11:00:19 *** welshdragon2 is now known as welshdragon
11:00:41 *** welshdragon has joined #openttd
11:03:21 <Eddi|zuHause> <petern> and a scripting language won't help that <- it would, if the same API is used for AI scripting and console scripting, then exposing functions to the console can be standardised
11:04:01 <Eddi|zuHause> (the process of exposing a function)
11:05:25 <Eddi|zuHause> meaning a server can then script hooks in case of certain event messages
11:05:47 <dih> controlling chat, server side
11:05:53 <dih> i.e. having a list of bad words
11:06:14 <dih> trigger callbacks with chat
11:06:24 <dih> (that chat is then not distributed to other clients)
11:07:08 <dih> all that could be scripted
11:07:14 <dih> and up to the server admin to implement
11:07:18 <Eddi|zuHause> AIs reacting to chat messages would be cool ;)
11:07:35 <dih> "please give me 20000000" :-D
11:08:22 <dih> Yexo, wrote a patch i think that would add chat to the AI's
11:08:55 <dih> client side would allow notifications on x
11:09:49 <dih> send x command via rcon when i login to server x
11:17:38 *** sierra1024 has joined #openttd
11:17:59 <sierra1024> good morning gentlemen
11:18:05 <Alberth> a program is not complete until you can chat with it :P
11:19:49 <NukeBuster> it would grant the admin alot more control over his server
11:19:58 <NukeBuster> allows him to restrict massive terraforming
11:20:07 <NukeBuster> with a patch of course
11:22:20 <sierra1024> kind of strange, anyway, to forbid terraforming
11:22:45 <NukeBuster> Should make it more expansive :)
11:23:05 <petern> scriptable console would not allow control over terraforming
11:23:29 <sierra1024> NukeBuster, expansive or expensive ?
11:23:31 <NukeBuster> even if that would information would be fed to the console?
11:23:43 <dih> sierra1024, to forbid people flooding the map
11:23:57 <dih> NukeBuster, what information
11:24:17 <dih> then i'll just break my tf down to 15 x 1 tile
11:24:20 * yorick would still like client ids in CommandPackets
11:24:34 <NukeBuster> yeah, with repeated amounts you give warn warn kick warn ban
11:25:27 <NukeBuster> or avg terraforming rate
11:25:34 <dih> only if you memorize the client some way or another
11:25:45 <dih> + what he has done so far
11:25:51 <yorick> NukeBuster: that would not stop them fromm flooding the map at once
11:25:53 <dih> too expensive i would think
11:26:23 <dih> unless you sit between command packet arriving and being put on the queue
11:26:24 <NukeBuster> then price would be a better thing
11:26:30 <petern> gah, stupid setpoint still doesn't see the mouse after boot up :(
11:26:48 <dih> NukeBuster, price for tf also influences building on slopes
11:27:01 <dih> so until that is a different price, you are stuck with it
11:27:03 <NukeBuster> if your average tf average is high your costs will increase
11:27:09 <dih> if they are separated you can controll them with a grf
11:27:29 <yorick> but everyone needs to have that grf
11:28:08 <sierra1024> having grf is not lame
11:28:09 <NukeBuster> unless you can autodownload them
11:28:17 <NukeBuster> which authors don't like
11:28:20 <yorick> but it needs to be a known grf
11:28:54 <dih> NukeBuster, it's not that important
11:29:03 <dih> the openttdcoop grfpack is kinda distributed
11:29:13 <NukeBuster> yeah, ok thats true
11:29:15 <yorick> yes, but the grf needs to be in that openttdcoop grfpack
11:29:21 <yorick> and you will not target the new players
11:29:56 <NukeBuster> I still hate having to find the right grf to play on a server i find via the multiplayer window
11:30:17 <dih> they usually have a list of grf's on their website
11:30:34 <yorick> you need to have the url
11:30:38 <NukeBuster> would mean i have to find out what their website is
11:30:44 <dih> and if they dont and the grf's are not in the grf pack why play there?
11:31:01 <yorick> because that server could be fun and a challenge
11:31:02 *** welshdragon2 has joined #openttd
11:31:04 <dih> the server name holds often enough more details than you need for that
11:31:11 <yorick> and because we are CURIOUS
11:31:37 <sierra1024> mankind is curious
11:31:52 <yorick> we doesn't include you ;)
11:31:58 *** welshdragon2 is now known as welshdragon
11:32:06 <sierra1024> every single one is curious ... otherwise ... we would still sit caves and not have pc and openttd to play
11:32:12 <dih> yorick, never tell a girlfriend that :-D
11:32:18 *** welshdragon has joined #openttd
11:32:48 <yorick> last time I checked, you were not my girlfriend
11:33:30 <NukeBuster> but you want to script the console dih?
11:33:39 <dih> yorick, how many times must i tell you to forget that idea?
11:33:40 <NukeBuster> like in source games?
11:33:49 <dih> i am not gay, not into kids, and way too old for you
11:34:04 <dih> NukeBuster, i want a decent console
11:34:10 <yorick> he wanted to script the console since the console was there
11:34:21 <dih> yorick, you talk nonsense
11:36:37 <dih> also fun would be if the in-game console was displayed see-through - like the chat messages appear :-D
11:36:44 *** Dr_Jekyll has joined #openttd
11:38:23 <yorick> it would also be fun if the console would have linebreaks
11:38:41 <NukeBuster> but wasn't the openttd console the otherway around?
11:39:08 <dih> left to right? or at the bottom of the page?
11:39:43 <NukeBuster> no... in the q3 engine you can access all functions from the console...
11:39:59 <NukeBuster> they then made the gui around that
11:40:02 <dih> the openttd console is pretty limited
11:40:37 <NukeBuster> bottom of the page would be unique though
11:42:10 * dih wonders how performance would differ if tcl was the ai language :-P
11:42:14 <NukeBuster> is there a proper way to add to the console currently?
11:44:10 <dih> the way the console works is pretty ugly
11:45:30 <NukeBuster> there is no console_cmdsc.pp
11:46:28 <Eddi|zuHause> # Und immer deine Freunde
11:46:30 <Eddi|zuHause> # Ihr nehmt doch alle Drogen
11:46:33 <Eddi|zuHause> # Und ständig dieser Lärm
11:46:35 <Eddi|zuHause> # (was solln die Nachbarn sagen)
11:47:07 <NukeBuster> I'll checkout again
11:50:24 <NukeBuster> I can use the void IConsolePrint() from any where in the code or is there another way i should output to the console
11:51:22 <yorick> IConsolePrint or IConsolePrintF yes
11:51:29 <yorick> what do you like to output to it?
11:52:13 <NukeBuster> not sure... but was wondering how one would output something
11:52:45 <NukeBuster> so it isn't hard to improve console output...
11:53:46 <yorick> but it lacks special characters like \n or \t
11:53:52 <yorick> and it has no line breaks
11:54:34 <NukeBuster> even if you would call void IConsolePrint() again?
12:06:35 <NukeBuster> and /n should be handled by void IConsoleGUIPrint()?
12:07:21 <yorick> no, \n is not handled at all
12:07:55 <NukeBuster> but if one were to implement that
12:16:00 <Alberth> NukeBuster: it's not console specific, so it should be done underneath console printing imho. I remember vaguely about multi-line support in the string rendering code, maybe that can be of use.
12:16:23 <dih> the sad thing with the console is that it reads char by char
12:16:43 <dih> which is really not a nice way to handle commands and it's parameters
12:16:44 <Alberth> we don't type fast enough !
12:17:37 <Alberth> broken quoting support :)
12:17:40 <NukeBuster> it should echo foo; echo bar
12:17:41 <Rubidium> both to execute because the code can't be bothered 'bout quites?
12:18:54 <NukeBuster> so what happends if you echo "can't"?
12:20:32 <dih> Rubidium, but odly it does kinda have support for quotes
12:20:52 <dih> and the echo thingy would not do
12:24:28 <Eddi|zuHause> you really need to work on your ability to form whole sentences
12:26:00 <Doorslammer> Sometimes I words say in reverse
12:28:31 * Alberth multiple constructors are nice!
12:29:15 <Eddi|zuHause> lesson 1 in forming sentences: you need a finite verb form.
12:29:49 <Eddi|zuHause> Alberth showed us a good example how not to do it, can anyone in the class correct his mistake?
12:30:40 <Alberth> Eddi|zuHause: dih was practicing non-verbal communication
12:31:52 <Alberth> Eddi|zuHause: your class seems to lack motivation.
12:39:11 <NukeBuster> openttd codingstyle { comes on a new line with a function but not with an if?
12:39:45 <NukeBuster> ok thanks, had to be sure.
12:51:57 <NukeBuster> Belugas you around?
12:52:55 <glx> good luck to reach him ;)
12:53:57 <NukeBuster> do you know why the last diagonal level and demolish patch wasn't accepted?
13:09:20 <Roujin> uhm.. because it was full moon?
13:09:37 <Roujin> do you know why they didn't want my drag&draw patch either? :P
13:12:54 <NukeBuster> I'd like to know why they didn't like want your drag and draw patch.
13:14:21 <NukeBuster> there was something with the c++ style operator. But he also made a java style one and after that the thread went dead for the xth time.
13:15:16 <dih> NukeBuster, the devs are not obliged to include any patch at all
13:15:28 <dih> just something to be aware of
13:15:36 <dih> or to keep in the back of your head
13:17:20 <NukeBuster> I know that, but I also know that there were a few devs that liked the patch
13:18:36 <NukeBuster> At least the functionality it would give. And by that I would assume there was still an unresolved issue in the coding.
13:19:27 *** Kommer_ has joined #openttd
13:19:27 *** Kommer is now known as Guest269
13:19:27 *** Kommer_ is now known as Kommer
13:42:35 *** HerzogDeXtEr has joined #openttd
13:46:36 *** Dred_furst has joined #openttd
13:52:00 <CIA-5> OpenTTD: rubidium * r14528 /trunk/ (9 files in 2 dirs): -Codechange: cache the closest town for all road tiles instead of only roads owned by tiles. This replaces a O(n) search over all towns from the road's tileloop with a O(1) lookup (PhilSophus)
13:54:52 <planetmaker> :) I guess, iirc the thread / suggestion correctly
13:55:28 <planetmaker> town roads did know their clostest town before. Now each road does.
13:56:01 <NukeBuster> does this improve pathfinding?
13:56:13 <planetmaker> it improves performance.
13:59:27 <yorick> "roads owned by tiles" <-- what?
14:01:08 <planetmaker> towns... readt he link
14:01:22 *** Xeryus|bnc is now known as XeryusTC
14:15:27 <yorick> /src/video/dedicated_v.cpp:229: warning: unused variable "__ct_assert__"
14:18:20 <frosch123> produced by assert_compile, and not important
14:18:36 <yorick> but still gives a warning
14:19:21 <CIA-5> OpenTTD: frosch * r14529 /trunk/src/ (station.cpp station_base.h station_cmd.cpp): -Codechange: Turn FindCatchmentRadius() into Station::GetCatchmentRadius().
14:25:01 <CIA-5> OpenTTD: frosch * r14530 /trunk/src/economy.cpp: -Fix [FS#2138]: Do not deliver cargo to industries not inside station catchment area.
14:30:59 *** jez9999 has joined #openttd
14:31:40 <jez9999> Does OpenTTD NoAI tend to accept some patches that OpenTTD doesn't, or does it just sync with the OpenTTD codebase?
14:32:04 <Zuu> NoAI syncs with OpenTTD codebase from time to time.
14:32:29 <Zuu> It is done manually every now and then as far as I know.
14:33:01 <Rubidium> jez9999: only patches for the API will be considered for NoAI
14:33:40 <jez9999> i wish the openttd main binary had my map colours patch in
14:33:57 <jez9999> it makes things so much clearer on the owners map
14:34:48 <Eddi|zuHause> that does not have anything to do with AI...
14:35:17 <dih> no he was just thinking he might get it into the noai branch in hope that when it gets merged it's also in trunk
14:35:22 <Zuu> I guess the patch does not apply to current trunk, and jez9999 hoped that he could apply it to NoAI.
14:35:53 <dih> or you could see it in a semi positive way - but then it's the patchers job to keep his/her work up to date
14:37:23 <jez9999> it just sucks having to regularly recompile decent patches into my openttd, frankly
14:37:31 <jez9999> close airports, copy/paste, map colours
14:37:52 <jez9999> i guess i can understand opposition to copy/paste, but the other two seem like excellent candidates
14:38:03 <jez9999> perfectly well coded and tested too
14:39:48 <Eddi|zuHause> since when are you expert on how well anything is coded?
14:39:49 <Rubidium> jez9999: yes... I know the quality of the testing done by many of the patches
14:40:05 <frosch123> [16:39] <jez9999> it just sucks having to regularly recompile decent patches into my openttd, frankly <- if that is your only concern, use mercurial, or go to https://ammler.ch/sulai/
14:40:12 <jez9999> Eddi|zuHause: since i started programming years ago, and hacking openttd a few years ago
14:40:17 <jez9999> yeah i think i have a rough idea
14:40:25 <Rubidium> "this patch has been tested extensively in multiplayer", which then contains a huge desyncer
14:40:51 <jez9999> map colours wont break multiplayer
14:41:00 <dih> jez9999, as long as you are not a dev your rough idea just aint gonna be good enough :-)
14:56:23 <vvv444> Btw, about good coding... I'm a newbie for OpenTTD and reading the codebase more and more lately. IMHO, much of the code isn't so perfectly coded. There are lot's of very long functions, some code is quite cryptic etc. Is it only my opinion or it's something well known and resulted from the codebase historic evolution?
14:58:04 <vvv444> Ic. Well, if so, can I propose refactoring/code beautifing patches?
14:58:38 <Rubidium> proposing isn't very useful
14:59:12 <vvv444> By propose I mean written&compiled&debugged&tested diff file :)
15:00:16 <Rubidium> depends on the kind of changes
15:01:01 <vvv444> Also, there are some things I would be glad to clearify about OTTD relation to C++, it seems that the project uses C++ but on the other hand it doesn't use it much. The code is much more C like.
15:01:02 <Rubidium> because if indenting changes it becomes very hard check the changes
15:01:34 <Rubidium> that's also known... it's C compiled as C++
15:01:39 <Alberth> vvv444: project switched to c++ not long ago
15:01:59 <vvv444> Rubidium: what do you mean by indenting changes?
15:02:27 <Rubidium> a complete function where you add/remove one tab of indentation
15:04:20 <vvv444> Rubidium: Don't you have IDE tool to ignore whitespace changes?
15:04:33 <vvv444> My WinMerge on Windows does that fine
15:05:19 <Sacro> Rubidium: you using ed?
15:05:29 * Rubidium usually reads patches in his browser/using less
15:06:37 <vvv444> Rubidium: That's your choice but sofisticated dev tools born to ease our life not theopposite :)
15:06:58 <Eddi|zuHause> am i right in the assumption that i can write anything in the beginning of a diff file, and it'll be treated like a comment?
15:07:24 <Rubidium> vvv444: I got annoyed by all IDEs I've tried
15:08:35 <vvv444> I'm using Visual studio on windows. Sadly, it's the best I found :( No Opensource project compares.
15:09:02 <frosch123> Eddi|zuHause: usually yes, most patch tools trigger on "Index:" and "@@"
15:09:29 <vvv444> But TortoiseSVN & WinMerge are very comfortable indeed (these are GPLed).
15:09:34 <frosch123> except you have a @%&!!%@ Solaris with tools from 1970 or so
15:12:38 <Rubidium> MSVC doesn't work in Wine
15:13:41 <vvv444> Still try WinMerge, maybe it does ;)
15:14:36 <vvv444> Although I'm pretty sure there are plenty of cool diff tools for Linux. No way none support whitespace ignorance.
15:15:34 * vvv444 tried switching to Linux many times, every time gave up and returned to Windows with Cygwin.
15:15:35 <Eddi|zuHause> "svn diff -x -w" or something
15:15:35 <frosch123> are those tools the reason why so much patches screw up whitespaces?
15:15:55 <Rubidium> true, they support it but that means applying the patch and such which requires more work than just opening a link in your browser
15:16:04 <vvv444> frosch123: No, the stupid people who don't check are!
15:17:45 <Rubidium> and if you think the functions are huge then I'd assume you would split the large functions in several smaller functions, which moves code around (or does your diff show that nothing has been changed in that case?)
15:18:33 <Alberth> frosch123: most editors don't clearly show spurious white-space at the end of the line
15:18:40 <vvv444> Rubidium: I think you have to move it around at least once. That's the cost of getting self explanotory code at the end.
15:19:34 <vvv444> When your code is factored properly and each function name tells what exactly it does you can even do almost without comments
15:19:54 <Alberth> maybe have a patch sequence?, first a split without indent change, then a patch with only indent changes
15:20:24 <Rubidium> that's only the case in an ideal world; in the real world comments are really necessary because lots of things aren't obvious
15:20:58 <vvv444> On other hand comments tend to be mismaintaned and can become misleading.
15:21:28 <Rubidium> vvv444: what's the difference between IsRailDepot(t) vs IsRailDepotTile(t) ? That's not something that's obvious from the name
15:22:10 <vvv444> Wait a sec, I'll read both and try proposing how I would code it.
15:24:01 <vvv444> Found on the way: trunk/rail_map.h:172 unmaintaned comment ;)
15:26:08 <CIA-5> OpenTTD: frosch * r14531 /trunk/src/network/network_gui.cpp: -Fix (r12425): OSK accessed wrong widgets of password query window.
15:26:40 <frosch123> looks more like copy&paste than unmaintained
15:26:55 <Rubidium> nothing's wrong with that comment
15:27:04 *** mortal` has joined #openttd
15:27:12 <Rubidium> it's only that the precondition isn't enforced, but that's why it's a precondition
15:40:55 *** mortal`` has joined #openttd
15:46:03 <vvv444> Rubidium: Well, you are quite right about case of these two functions. Although I could propose something like: IsTileARailDepot(t) and IsRailTileADepot(t).
15:47:14 <vvv444> [The idea emphasizing in the name function that you already know that a tile is a rail time]
15:48:06 *** mortal` has joined #openttd
15:48:25 *** mortal` is now known as mortal
15:49:16 <vvv444> Rubidium: Although I can try thinking about a C++ design that will solve such kind of ambiguity.
15:50:11 * Rubidium wonders why everyone wants to make everything object oriented...
15:51:00 <vvv444> I'm talking about ways that won't hurt performance nor memory consumtion.
15:51:00 <glx> if you really want to use objects, you can try to do it for GUIs :)
15:51:08 <Alberth> vvv444: current design is opimized for speed, so you have many special cases since at various points you have slightly different information
15:51:39 <Alberth> glx: I am doing that already, see #FS1905, it just needs review comments from devs :)
15:51:49 <vvv444> I perfectly understand that.
15:51:51 <Rubidium> making objects from the map array at least doubles the size of the map array (on 64 bits)
15:52:07 <vvv444> Look you don't have to allocate the object
15:52:16 <vvv444> Just a sec, my english is slow :)
15:54:05 <Rubidium> then I'll read it a lot later tonight
15:54:34 <vvv444> Just a thought in an air, not something I've given a very serious thought: Make class heirarchy MapTile->RailTile->DepotTile etc. Use it instead of TileIndex. Non virtual objects and give each object proper functions.
15:55:34 <Alberth> vvv444: the problem as far as I can see is that you cannot have an array of differently derived objects
15:56:04 <vvv444> I didn't say it will replace map. Only said using these as indexers.
15:56:32 <vvv444> Then you can try converting MapTile to RailTile and the conversion function checkes if it's indeed RailTile. If it's not returns invalid tile.
15:56:51 <frosch123> I guess that would create quite a mess, as you would need to use multiple inheritance resp. interfaces and such
15:57:09 *** lobstar has joined #openttd
15:57:37 <frosch123> i.e. there are a lot of map accessors which can access quite different tiletypes, but not all subtypes of every tiletype
15:58:14 <vvv444> Then MapTile::IsRailDepot() would correspond to current IsRailDepotTile() and RailTile::IsDepot() corrsponds to current IsRailDepot().
15:59:02 <frosch123> IsRailDepotTile() would be more like a dynamic cast, with checking
15:59:09 *** Kommer is now known as Guest283
15:59:09 *** Kommer_ has joined #openttd
15:59:10 *** Kommer_ is now known as Kommer
15:59:11 <frosch123> don't know the c++ syntax for that
15:59:41 <vvv444> "but not all subtypes of every tiletype " <-- What do you mean?
15:59:46 <frosch123> but take a look at GetTownByTile, or GetTileOwner, or GetRailTypes
15:59:58 <glx> map accesses need to be as fast as possible as they are used for everything
16:00:05 <frosch123> GetRoadOwner is also funny
16:00:40 <Alberth> frosch123: dynamic_cast<T*>(ptr)
16:01:15 <vvv444> glx: Well, these functions will still be inline, so no performance penalty. The only idea is to save info you already have using the tile accessor object type.
16:01:28 <frosch123> Alberth: I guess I meant typeof, when that exists
16:02:05 <Alberth> vvv444: much code makes clever use of bites of different variants being at certain places. restructuring breaks that, and you have to test and code every case
16:02:19 <Alberth> frosch123: if (dynamic_cast<T*>(ptr) != NULL)
16:02:22 <frosch123> vvv444: despite of speed issues, take a look at GetRoadOwner and tell me which class to assign it to
16:02:39 <frosch123> then do the same for GetTileOwner()
16:03:29 <frosch123> Alberth: ok, I would have expected that to cause an exception :)
16:03:52 <vvv444> No, dynamic cast won't work since you don't actually have objects here. Each map accessor will be an object of 4 bytes having only one field that is the tile index. The only additional info will be the object type that isn't save anywhere except that compiler knows it in any specific place during the compile time.
16:05:25 * vvv444 coding an example peice of code
16:05:44 <frosch123> start with GetRoadOwner and GetTileOwner
16:06:11 <Alberth> vvv444: eg GetTileSlope() in tile_map.cpp uses addition to encode slope bit-fields
16:06:22 <planetmaker> frosch123: can you explain me the new station radius you submitted today?
16:07:17 <frosch123> planetmaker: cargo will be delivered to the nearest industrytile wrt. the station sign
16:07:43 <planetmaker> not to any other anymore?
16:09:02 <planetmaker> hm... reading source.
16:09:19 <planetmaker> Assuming I have two saw mills within the catchment area...
16:09:59 <planetmaker> will that have an advantage?
16:11:06 <frosch123> it will always deliver to the same first. the other will only be delivered, when the first rejects the cargo (e.g. because of stock piling)
16:12:11 <planetmaker> yeah, as before :). Read industry instead of industries :). But not to industries outside. Nice :)
16:14:13 *** sierra1024 has joined #openttd
16:14:23 <sierra1024> good evening gentlemen
16:15:00 <planetmaker> Today seems to be a day for awesome commits :)
16:15:18 <sierra1024> planetmaker, what so awesome has been commited ?
16:15:47 <yorick> it seems to be a day for awesome commits to be made ;)
16:17:45 <sierra1024> to me it looks like night
16:20:18 *** mortal` has joined #openttd
16:24:51 <vvv444> glx: Btw, what about the GUI branch you mentioned? I read at the wiki that it was started once several years ago...
16:25:14 <glx> vvv444: this branch is dead :)
16:25:35 <glx> currently windows are objects
16:25:52 <glx> but widgets still are not
16:26:29 <Zuu> I'm currently working on a patch that should make it possible to make use of more edit boxes than before, still the limit of maximum one edit box per window is there.
16:29:12 <vvv444> glx: Maybe if so the branch should be deleted to prevent misleading newbies like myself? ;)
16:29:54 <dih> newbies dont look at the svn repo
16:30:32 <Zuu> And if you do you can probably see the last modified date in it?
16:30:43 *** mortal`` has joined #openttd
16:33:53 <vvv444> dih: I'm a newbie but 1st thing I did after a played the official version downloaded from the web I checked out the trunk and compiled it :)
16:34:16 <frosch123> btw. Zuu, I am not that happy about the dynamic cast in DispatchLeftClickEvent. As I did not found a nice way to move it to QueryStringBaseWindow I guess it has to wait until it can be added to some EditBox::OnClick
16:35:49 <dih> vvv444 not every openttd newbie starts digging the repo, + not every openttd newbie is a svn newbie :-P
16:36:09 <dih> and a wannabie self-compiler
16:36:13 *** welshdragon has joined #openttd
16:37:22 <Zuu> frosch123: "Has to wait" as in dynamic_cast is okay untill widgets get object oriented or that the solution to have osk managed this way is not okay?
16:37:26 <frosch123> no, most ottd newbies are more like I-get-an-error-message-but-do-not-want-to-follow-its-directions
16:38:43 * Zuu looks on his "r14527MM" revision string and smiles
16:38:58 <frosch123> OO gui would have to redo your patch anyway, so I would leave trunk as it is currently
16:39:19 <Zuu> frosch123: Which patch are you refering to?
16:40:12 <frosch123> QueryStringBaseWindow *qs = dynamic_cast<QueryStringBaseWindow *>(w); if (qs != NULL) qs->OnOpenOSKWindow(widget);
16:41:49 <Zuu> frosch123: Yes, that line, which is included by UnifiedOpenOSK, which may not be a step forwarf for trunk but provides fundation for Window&Widget focus which is then used by filter sign list patch.
16:42:31 <Zuu> glx: Can be me, mixed something up. it is first time I'm using hg queues.
16:45:01 *** mortal` has joined #openttd
16:45:13 <CIA-5> OpenTTD: glx * r14532 /trunk/projects/determineversion.vbs: -Fix (r14522): one 'M' is enough to show modified version
16:46:45 * Zuu is excited and waits for frosch123's idea (correct placement of ' ?)
16:48:39 <Zuu> The key point of the UnifiedOpenOSK patch is that opening is initiated from DispatchLeftClickEvent function where it is relative easy to check if widget focus just changed or not, so that opening OSK can be blocked if a user just changed focus to an edit box by clicking on it.
16:49:23 <frosch123> btw. you should compare it with your patch for future coding style hints :)
16:49:40 <Zuu> Ok, a diff of diffs perhaps :)
16:50:11 <frosch123> but one that does not suppress whitespace changes :p
16:51:14 <Zuu> So you've basically moved OnOpenOSKWindow to Window base class? + other coding style stuff?
16:51:34 *** stillunknown has joined #openttd
16:59:12 <frosch123> Zuu: however, it does not really simplify stuff, it just moves handling of editbox clicks from OnClick() to OnShowOSKWindow()
16:59:41 <frosch123> there are only one or two windows which can use the inherited method of QueryStringWindow
17:00:06 <Zuu> "unified" might be a to strong word I can agree
17:04:15 <frosch123> so is the only difference that your focus patch calls OnShowOSKWindow() only when the window is focusses, while OnClick() is always called?
17:04:15 <Zuu> Well, those windows who can make use of the default values for ShowOnScreenKeyboard gets slightly shorter code wise. But the real power is that the opening of the OSK have been moved to DispatchLeftClickEvent. This power however is not much of a benefit in trunk I agree, only when Window&Widget focus patch is used.
17:04:36 *** ChanServ sets mode: +o Bjarni
17:05:11 <Zuu> frosch123: The motive behind all this is that when a user click on a edit box today the OSK opens. With focus patch I want to deley this untill the user clicks a second time.
17:05:23 <Zuu> So a user can give focus to an edit box without showing the OSK.
17:06:05 <Zuu> An alternative solution to this is to add an extra parameter to OnClick that tells if widget focus just changed.
17:06:22 <Zuu> But that means changing *many* OnClick functions which would yeild a bigger patch.
17:06:43 <frosch123> what does OnClick do for not-focussed widgets/windows?
17:07:11 <frosch123> i.e. are the windows which do not need focussing?
17:09:07 <Zuu> not focused widgets can't be clicked on, since they gain focus when they are focused on. With one exception, the title bar which I never give focus. (Reason for that is so you can move a window without deselecting the edit box)
17:09:29 <Zuu> when they are clicked on*
17:09:30 <frosch123> what about buttons, and dragging in depot and such...
17:09:46 <frosch123> and what about moving the OSK to OnDoubleClick
17:10:40 <Zuu> moving OSK to OnDoubleClick could be a possibility, though I wonder those PDAs that use the OSK, how easy/hard is it to double click on them.
17:11:14 <Zuu> I'm a tablet user and double clicking with that within the time frame is significantly harder than with a mouse/trackball.
17:11:46 <Zuu> buttons, draging etc. are not affected by focus-patch, or what are you aiming at?
17:12:34 <frosch123> you could also move the focus after calling OnClick, so you can use IsFocussed in OnClick
17:13:09 <Zuu> Hm, that's also a good idea.
17:13:52 <Zuu> Or better use IsFocused in ShowOnScreenKeyboard function to reduce amount of code duplication.
17:14:10 <frosch123> don't know though, which implications that would have though ...
17:14:15 <Burty> how can i fix "Error 1 error C2220: warning treated as error - no 'object' file generated" ?? no other erros just that
17:14:33 <frosch123> i.e. when to change focus is a very fundamental decision
17:14:38 <glx> you are not using clean trunk
17:15:10 <Burty> so i just need to get a clean checkout?
17:15:22 <Zuu> frosch123: sure, depends on what you want to achive with focus. Currently it is only used to do text-input-focus.
17:15:44 <glx> Burty: what version are you trying to compile?
17:16:36 <Burty> dont laugh but 9865 because there is a patch im seeing if i can somehow bring up to nearer the new versions
17:17:21 <glx> good luck as there are at least 2 patch breaking commits after that
17:17:47 <Burty> one of which is players.cpp
17:19:03 <glx> hmm I though it was pre c++ but it's not
17:19:16 <frosch123> Zuu: anyway, using an IsFocussed in OnClick seems to match future handling of the OSK in some EditBox::OnClick
17:20:03 <Burty> glx: well when i hit thost breakers i will root about and find out how to deal with it :D, thanks
17:20:27 *** lobstar is now known as lobster
17:20:37 <glx> usually it's: diff, update, edit diff to new filename, patch
17:21:29 <Zuu> Since a click give focus (with the exception of the titlebar, that is seldome used in OnClick anyways) it is probably not too bad for future if IsFocused() gives false when a widget is clicked.
17:25:09 <Zuu> A slight problem is that _focused_window can't change in the beginging of DispatchLeftClickEvent function, instead that has to be done after OnClick has been called. In DispatchLeftClickEvent function there are many return-statement so before each all these _focused_window need to be changed and possible also _focused_window->focused_widget which even if that is put into a fuction gives more code than setting focus in the beg
17:25:09 <Zuu> inng of the Dispatch...-function.
17:27:44 <Zuu> There is 6 return-statement between where focus is set currently and the end of function. :-)
17:30:04 <Zuu> passing an extra bool telling if widget focus changed with OnClick I think is a relativly clean solution, problem is just the length of the patch.
17:31:50 <glx> if there were "real" widgets, focus stuff would be easier
17:32:25 <frosch123> changing the focus after OnClick sounds better than an extra argument
17:33:48 *** lobster_MB has joined #openttd
17:34:05 <Zuu> Even if that means calling a change focus function before every of those 6 return-statements and one at the very end of the Dispatch...-funciton?
17:34:43 <Zuu> Also window->OnFocus() will be called after OnClick() with that approach.
17:35:22 <frosch123> I'm not sure whether each of those 6 would actually cause focussing
17:35:29 <frosch123> at least the close would not :p
17:36:01 <glx> but it's not possible to do the same in openttd
17:38:01 <frosch123> that seems to set the focus before some widget specific stuff (i.e. OnClick)
17:38:17 <Zuu> frosch123: Yea, maybe you are right, that causing focus lost on another window just bacuse you close another may be unneccesary.
17:38:39 <glx> and rev 1379 for the focus check
17:44:07 <glx> Zuu: maybe you could provide a patch for just HandleEditBoxKey() result handling (removal of "magic" values)
17:44:20 *** mortal`` has joined #openttd
17:45:24 <Zuu> glx: That is doable, if that can get merged relatively soon that would simplify for all I guess.
17:47:56 <glx> yes trunk will be easier to read, and your patch will be smaller :)
17:48:27 <glx> as some changes in it are just that
17:49:26 <Zuu> Hmm, need more diskspace hehe, have only 100 MB left on C: :D
17:49:40 <glx> windows doesn't like that
17:51:15 <Zuu> Well I have 2.5 GB of OpenTTD checkouts/compiles that could be moved to another partion.
17:54:15 <glx> 8.5GB and still counting ;)
17:54:49 <Zuu> Have 7,5 GB free on another partion, so moving there seams like a good idea. :)
17:56:59 <glx> but that includes all tags since 0.5.2 and most branches are duplicated
17:57:34 *** mortal` has joined #openttd
17:58:18 <glx> trunk is just 702MB (with debug and release builds for mingw and msvc)
18:14:29 *** mortal` has joined #openttd
18:18:22 <Eddi|zuHause> wtf? do ads in the forum now have sound?!?
18:19:20 <frosch123> oh noes - when they become common I need some sound blocker
18:19:52 <Bjarni> forums should be silent
18:20:12 <Eddi|zuHause> i could have sworn i just heard a racing car
18:20:28 <Eddi|zuHause> and it couldn't have come from anywhere else than the ad on the forum
18:26:43 <SmatZ> yorick: that's my patch! :-P
18:27:04 <yorick> SmatZ: nono, I just looked at it and recreated it
18:27:16 <yorick> and you did not commit :-p
18:27:30 <SmatZ> no, and it won't be commited
18:27:47 <SmatZ> result of devs' discussion
18:28:07 <yorick> "doing this will remove the need of it being done correctly"
18:29:15 <yorick> because its like irc...a whole new protocol needs to be created just for the bots, eh?
18:32:15 <welshdragon> SmatZ, what patch are you and yorick arguing about?
18:33:27 <yorick> welshdragon: the dev's decision not to commit anything that could be used for creating a bot for use with openttd unless it involves writing a whole new bot-protocol
18:36:49 <Ammler> devs don't like to commit something for MP anyway :P
18:50:41 *** mortal` has joined #openttd
18:51:59 *** mortal`` has joined #openttd
18:52:04 <glx> [20:20:09] <Sacro> adblock+ ftw <-- I disable it on sites I want to support
18:53:27 <frosch123> I do not care about graphics, so I would support everyone. But sound is in no way acceptable.
18:54:33 <yorick> graphics go to display:none, but if it does the CLICK ME! sound, it won't stay out of my blocklist
18:57:15 <Sacro> glx: I don't bother, I feel that sites should pay me for the right to shove adverts down my pipe
18:58:01 <Zuu> (removal of magic numbers)
18:58:36 <CIA-5> OpenTTD: frosch * r14533 /trunk/src/landscape.cpp: -Fix: ...hopefully most glitches wrt. inclined foundations.
19:00:22 <glx> Zuu: hmm yes HEBR_DEFAULT looks "weird"
19:00:38 <Zuu> good, not only me think it looks silly :)
19:01:44 <Zuu> What do you think of HEBR_OTHER_KEY?, since the function is noly called when a key is pressed. So an other key than return/enter/escape have been clicked.
19:04:49 * vvv444 encountered "highways" in the codebase, anyone who can explain about this feature plz
19:06:22 <Zuu> glx: uploaded a new version with HEBR_OTHER_KEY, but I've just made find replace in the patch-file.
19:07:38 <Zuu> hmm, the comment after HEBR_OTHER_KEY needs fixing too.
19:07:58 <frosch123> vvv444: the space in the map array can handle either three independent sets of roadbits for three types of road (which it does currently), or two independent sets of road bits for a lot more types (might be considered for future)
19:10:39 <Zuu> hmm, a comment saying that "other key" is returned when none of the below (return, escape) is quite unneccessary, so I remove the comment enterly.
19:13:20 <frosch123> how about "HEBR_EDITING", "HEBR_ENTER", "HEBR_CANCEL"?
19:15:47 <Zuu> "HEBR_EDITING", "HEBR_CONFIRM", "HEBR_CANCEL" ?
19:17:17 <Zuu> I would prefere RETURN over ENTER, as the return key is more commonly used.
19:17:51 <Zuu> but you can see both names used in trunk.
19:18:55 * frosch123 dislikes RETURN, as it refers to multiline editing, and not to enter a value
19:19:40 <frosch123> but CONFIRM is also fine
19:20:24 <Zuu> Since Escape is substitude by Cancel, confirm is more in the same kind of term as cancel.
19:21:21 <frosch123> yup, first I wanted to suggest OK, but that seemed to be too short :)
19:22:05 <Eddi|zuHause> can i have an ANY_KEY please?
19:23:12 <frosch123> Eddi|zuHause: the space bar has enough space to write anything on it as you like
19:23:27 <Zuu> In many places the old magic values have been commented for example "// ESC pressed, closes window, abandons changes". Perhaps the first part about which key have been pressed should be removed?
19:23:57 <frosch123> I guess, those comments are not needed at all :)
19:24:22 <frosch123> except they say more than CONFIRM or CANCEL :)
19:25:30 <Zuu> I think the part about what happens can be keept. But you are the devs :-)
19:26:17 <frosch123> tbh it does not really matter :)
19:35:17 <Zuu> http://bugs.openttd.org/task/2382 <-- Fourth version with Editing, Confirm, Cancel. Removed most comments. Only keept the later part of some Escape-commets where the comment says what happens. (have changed word form of these comments though)
19:36:44 <Zuu> I've commented the enums what key(s) they corespond to.
19:41:16 <Zuu> Indeed, fails here too. Probably touched a line without + or - in the patch file.
19:44:43 <vvv444> frosch123: Ok, after I thought some time about it, I see what you meant about GetTileOwner/GetRoadOwner. But is there any case when you call GetRoadOwner not for road tile? Or any case when you call GetTileOwner for house/industry tile (which is forbidden)?
19:46:00 <frosch123> GetRoadOwner applies also stations and bridges
19:46:47 <frosch123> while TileOwner is invalid for roads, except it is RailOwner for level crossings
19:47:52 <frosch123> also take at look at GetAnyRoadBits
19:48:37 <vvv444> But do you usually know if you're dealing with road, station or bridge? Or you mean it should be polymorphic?
19:49:10 <frosch123> it needs to be polymorphic
19:49:43 <frosch123> same about GetWaterClass and GetRailType
19:50:21 <frosch123> and I am sure there is more stuff which applies similiary to different tiletypes
19:51:14 <vvv444> Ok, about GetAnyRoadBits - it's not a problem since it receives explicitly the road type, so it doesn't require polymorphism.
19:52:39 <frosch123> ok, GetAnyRoadBits could be a member of the root calls
19:53:02 <vvv444> So as GetRailType, it explicitly knows the tile is rail.
19:53:03 <Zuu> glx: Now a new version is available that applies and compiles :-)
19:53:24 <frosch123> vvv444: no, GetRailType also applies to bridges and stations
19:53:42 <Zuu> * I hope * - at least it does here.
19:54:03 <frosch123> anyway I guess something is starting becoming darker in my oven :)
19:54:50 <vvv444> frosch123: Ok, actually I have to check mine too :)
19:55:39 * Zuu takes a slice dark bread :-)
19:59:23 <CIA-5> OpenTTD: glx * r14534 /trunk/src/ (5 files in 2 dirs): -Codechange [FS#2382]: Enumify magic return values of HandleEditBox function (Zuu)
20:01:53 * Bjarni notes that Zuu just moved a bit towards the dark side
20:02:21 <Bjarni> I mean you are what you eat :)
20:15:16 *** questionmark has joined #openttd
20:15:38 *** welshdragon has joined #openttd
20:15:40 <NukeBuster> is viewport.h removed a while ago?
20:16:17 <NukeBuster> and does svn give an error when a modified file is supposed to be removed+
20:16:19 <CIA-5> OpenTTD: frosch * r14535 /trunk/src/openttd.cpp: -Fix: Description of '-i' commandline option.
20:16:29 *** yorick is now known as Guest302
20:16:29 *** questionmark is now known as yorick
20:17:22 <frosch123> NukeBuster: IIRC it was split into viewport_func.h, viewport_type.h, tilehighlight_func.h and tilehighlight_type.h
20:18:08 <NukeBuster> does svn give a code like C for the file or does it remain D
20:19:30 <frosch123> IIRC svn does not delete files with local changes, but usually noone tests such behaviour without a safety copy :p
20:19:49 <NukeBuster> yeah i had the copy
20:19:57 *** Nite_Owl has joined #openttd
20:20:13 <NukeBuster> but i want to detect when such stuff happends to modified files
20:21:12 <frosch123> NukeBuster: you can also use 'svn status -v' before an update
20:21:22 <frosch123> it will show you what is going to happen
20:22:13 <frosch123> well, maybe '-u' is more useful :p
20:25:01 <NukeBuster> hmm... I'm trying to automate the updating process so I'll see what information is most useful
20:25:23 <NukeBuster> it usually should just update unless a conflict is reached
20:25:54 <NukeBuster> i would count a try to delete modified files as a conflict too
20:27:46 *** mortal`` is now known as mortal
20:28:29 *** welshdragon is now known as Guest305
20:30:23 <vvv444> frosch123: http://paste.openttd.org/138079 - Small piece of code I've written so far. Haven't decided what to do with the problematic functions yet. But I have several options to be considered.
20:31:54 <vvv444> 1. The most simple and stupid option is to put these to the basic MapTile class (as they are global today), that leaves all the responsibility of usage on the caller.
20:34:01 <vvv444> 2. For instance GetRailType function. It can be put in the RailTile class only. Then conversion from MapTile to RailTile should check (and succed) only if the tile is MP_RAILWAY/bridge with rail/or station with rail, otherwise fail.
20:36:10 <frosch123> well, I guess finally you would end up with most functions remain global, and compared with the amount of work to convert all TileIndex uses, I doubt it is worth the effort.
20:36:12 <vvv444> 3. Some kind of polymorphic mechanism that uses the map tile type for 'vtable' choice and not C++ vtable (that is initialized at object construction and doesn't suit our needs)
20:36:57 <frosch123> wrt. 3) already exists, is called TileTypeProcs or similiar
20:37:38 <frosch123> and especially the GetTileTrackStatus() is one of the most expensive functions
20:37:55 <vvv444> I know, but it can be merged here and be more usable.
20:38:06 *** Guest305 is now known as welshdragon
20:40:42 <vvv444> frosch123: I'm not sure most functions will remain global. But I'll think more about it of course. Thank you very much.
20:56:44 <dih> saving the random seed in the config should be an optional not a enforced setting
20:57:07 <dih> i.e. if someone specifies it in the file - use it, if it's not there, dont force writing it to the config file when it's saved
21:01:07 * Zuu hugs hg queues for not having to update the filter sign list patch with things that relate to widget focus.
21:02:53 <planetmaker> Zuu: I gave them a try - really nice :)
21:04:07 <Zuu> I do "hg qpop --all", and then SVN update as usual. Guess I could learn to use hg pull instead, but figured I start with queues and keep SVN for updating for now.
21:04:37 <planetmaker> is there now an easy way for me to update the version of your patch (in my personal client patch repo) with your latest?
21:04:44 <planetmaker> just replace the patch file?
21:04:52 <planetmaker> don't think so...
21:05:05 <Zuu> hmm, you should wait for v 11, though.
21:05:34 <planetmaker> :D ah, right one of todays commits...
21:05:52 <planetmaker> how does this versioning work? I didn't figure that out, so far.
21:05:52 <Zuu> Because v10 don't apply to trunk as a part of my work have been commited. (magic numbers -> enum)
21:06:09 <planetmaker> yep, congratz for that :)
21:07:04 <Zuu> Thanks. Much longer patch (167 lines) than the one-liner I got many months ago.
21:09:28 *** welshdragon is now known as Guest308
21:09:43 <Zuu> Hmm, where did English (UK) go .. :/
21:09:45 *** Guest308 is now known as welshdra-gone
21:12:35 <Zuu> planetmaker: If you have hg at my patch, can you use my old patch to un-patch the code and then apply my new patch maybe?
21:13:26 <Zuu> Either way I think hg should be able to unpatch what my patch have done.
21:13:27 <planetmaker> maybe :) I didn't try so far, but I thought you would know for sure :)
21:13:53 <planetmaker> that's feasable, yes. I could just delete it and add a new one - if worse comes to worse
21:14:46 <Aali> just pop it and replace the patch file in .hg/patches
21:14:55 <Aali> assuming its -p1, of course
21:16:19 <planetmaker> Zuu: yes, I've bookmarked that. It's pretty good :)
21:16:57 *** ChanServ sets mode: +v tokai
21:17:06 <planetmaker> it's p0, I guess, but I could convert it to p1.
21:17:36 <Zuu> Oh, a full rebuild got English (UK) back, thanks god. (No offence to the translators, but I have hard to stand OpenTTD in Swedish despite that being my native language)
21:18:44 <Aali> i haven't even tried playing it in swedish
21:19:10 <Zuu> Well I'm just so used to the english terms used in OpenTTD.
21:20:07 <Zuu> Played *TTD* since around year 2000 allways in English.
21:20:19 <Zuu> It is not that the translation is bad, it is that it is a translation.
21:21:22 <Eddi|zuHause> i have played TT in german since the first release
21:21:50 <Eddi|zuHause> the demo was in english, i think. but i didn't know english very well back then
21:22:33 *** NukeBuster has left #openttd
21:24:09 *** Nightraven has joined #openttd
21:30:41 *** NukeBuster has joined #openttd
21:47:22 <Zuu> planetmaker: I've uploaded version 11 of my filter sign list patch now, incase you want to upgrade your queues. :-)
21:49:24 <Aali> Zuu: where in sweden do you live?
21:49:44 <Aali> if you dont mind me asking
21:49:58 <planetmaker> Zuu: thanks. Indeed I want that :)
21:50:33 * planetmaker waves a hello @ TB
21:50:55 <TrueBrain> how are you all doing my friends?
21:52:08 <Rubidium> though /me feels tomorrow will be a long day ;)
21:58:00 <TrueBrain> hmmm .. we all hear gunshots outside
21:58:03 <TrueBrain> is that a good thing? :s
21:58:12 <Bjarni> TrueBrain: I'm doing ok
21:58:14 <TrueBrain> ('we' as in my roommates and I)
21:58:17 <Bjarni> but I could be better :s
21:59:22 <Bjarni> the news today talked about gunshots... somebody's house was hit by bullets (broken window and stuff) and they called the police
21:59:38 <Bjarni> the police decided to ignore it so they contacted the media o_O
21:59:55 *** scarabeus has joined #openttd
22:00:25 <TrueBrain> deep silence now ... well, if the police arrives in a few, we know for sure it was gunshots :p
22:00:35 <TrueBrain> Digitalfox: good news, I finally ordered my iPhone :) Takes 10 more days ...
22:01:05 <scarabeus> TrueBrain: exactly guy i need
22:01:10 <CIA-5> OpenTTD: frosch * r14536 /trunk/src/economy.cpp: -Fix (r14530): Do not expect uints to become negative.
22:01:13 <scarabeus> ok are you still interested in that proxy?
22:01:33 <TrueBrain> scarabeus: I worked 10 hours today, so all I can think is: huh? :p
22:01:47 <scarabeus> gentoo ebuild maintainer you
22:01:53 <scarabeus> i just upload to gentoo
22:02:05 <TrueBrain> if that makes release-ebuilds go in quicker ;)
22:02:18 <scarabeus> i need some nice mail i guess it will be truebrain@openttd.org but i want it confirmed
22:02:32 <planetmaker> Zuu: where did you upload it? I cannot find it...
22:03:10 <planetmaker> hm... and why did you rename it?
22:03:20 <glx> scarabeus: very nice to write an email address on IRC
22:03:22 <Zuu> Um, ow, uploaded wrong patch.. :)
22:03:27 <planetmaker> I was of the impression that it is only part of the patch...
22:03:45 <scarabeus> i am bit tired i should go sleep :(
22:04:01 <glx> next time use decorations for it ;)
22:04:01 <scarabeus> TrueBrain: will you be there tomorow lets say 12:00 UTC?
22:04:12 <TrueBrain> scarabeus: depends .. if I can get up that early :p
22:04:19 <Zuu> planetmaker: try again, now you should find the patch a litle bit easier :-)
22:04:29 <TrueBrain> tonight we switch to CET .. so +0100 .. hmm .. yeah :p
22:04:51 <Zuu> TrueBrain: Thanks for reminding, had forgot that.. :)
22:04:53 <TrueBrain> scarabeus: btw, why did the ebuild in portage switch to EAPI 2? (what is wrong with EAPI 1? :p)
22:05:15 <scarabeus> we just want it tested, nah kidding it allows use dependencies
22:05:45 <TrueBrain> anyway, me is going to bed .. talk to you tomorrow scarabeus :)
22:06:08 <scarabeus> i am outta here too and going to bed so see ya tomorow
22:06:10 <planetmaker> g'night from here, too
22:06:55 *** rubyruy has joined #openttd
22:08:32 <rubyruy> hey i was just going through creating a calculator for figuring out the optimal route distance given a train speed (and avg loading/wait time and maint/yr)... but it occured to me somebody PROBABLY already did this :)
22:08:41 <rubyruy> oh and also given a particular good of course
22:08:56 <rubyruy> is such thing already out there somewhere? probably a scary spreadsheet?
22:09:25 <frosch123> I saw something like that on the forums
22:09:30 * Rubidium seems to remember that the optimal distance was as far as possible
22:09:31 <frosch123> no idea whether it was correct though
22:09:42 <Zuu> frosch123: I remember it too
22:09:58 <Zuu> In General OpenTTD forum. up to one month ago.
22:10:29 <rubyruy> Rubidium: i thought that was the case as well for a while... but there is a point at which the late penalties (even for things like coal) take so much out of your income that it's worth it to use shorter routes, making more trips
22:11:01 <rubyruy> but there's so much other crap to take into account for a proper model...
22:11:26 <Zuu> and then you load a grf and you have re-do everything.
22:11:42 <rubyruy> well just have to plug in the new values
22:11:58 <rubyruy> hmm maybe somebody working on AI already went through this as well
22:12:02 <Rubidium> and then you find out the newgrf uses variable running costs...
22:12:47 <Rubidium> variable as in: when accelerating/climbing costing more than when driving at a constant speed
22:13:42 <rubyruy> i'm sure you could average it out
22:14:06 <rubyruy> i mean even without variable maint costs, slopes would affect delivery speed anyway
22:15:02 <rubyruy> do you guys remember anything about the title ? the general theme?
22:15:19 <rubyruy> i noticed there's a fair bit of mismatch between a thread's title and what it actually ends up being about ;)
22:18:19 <frosch123> there is at least another topic (using those keywords) with a weird table with magic values
22:18:33 *** welshdra-gone is now known as welshdragon2
22:25:36 <rubyruy> aww there is a patch to show this in game but it's fallen into neglect :(
22:30:29 <rubyruy> hmmm so is the consensus that if capital is a non-issue and you're optimizing income per station (or factory i guess) then longer IS always better
22:31:05 <rubyruy> but if money is actually an issue (early on) then optimizing per train is preferable, and shorter runs are better
22:33:19 *** Brianetta has joined #openttd
22:33:19 <glx> else running costs are higher than income
22:33:44 <Zuu> train length is also a parameter of importance esp. in the beginging.
22:34:38 <rubyruy> yeah i noticed that actually.... steam engine + 10 coal cars == !success :(
22:34:56 <rubyruy> optimal engine size would be another interesting thing to look at
22:35:14 * rubyruy is there a good openttd strategy site? most of the high profile resources are dev/modding
22:35:22 <rubyruy> ... are more dev/modding oriented
23:09:12 <Eddi|zuHause> i hate the time switch... it always screws up any recordings that i plan during that night...
23:12:55 *** HerzogDeXtEr has joined #openttd
23:31:24 *** ChanServ sets mode: +v tokai
23:40:38 <dih> [06:49] <dih> perhaps you devs should have a get2gether and see if you all are supporting the same idea
23:40:47 <dih> [06:49] <dih> it's kinda not so helpful if 3 devs say x and 2 say y
23:41:02 <dih> petern, and Rubidium, i had misunderstood things you guys had said separately
23:41:16 <dih> and made a pretty much out-of-place statement
23:42:04 <dih> i'll try to understand what you guys say rather than assuming things
continue to next day ⏵