IRC logs for #openttd on OFTC at 2008-10-25
            
00:01:54 *** Sacro|Laptop has quit IRC
00:01:58 *** Sacro|Laptop has joined #openttd
00:03:15 *** Brianetta has quit IRC
00:05:46 *** Dred_furst has quit IRC
00:17:41 *** ecke has quit IRC
00:23:39 *** KritiK has quit IRC
00:32:50 *** Eddi|zuHause has quit IRC
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:43:07 <ben_goodger> null, x |= 2?
00:45:04 <fjb> "x |= 2;" sets the second bit. But how do I clear it without clearing any other bit?
00:45:29 <ben_goodger> oh, I see
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:34 <ben_goodger> excellent idea
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:51:49 *** stillunknown has quit IRC
00:52:07 <Aali> fjb: x &= (binary NOT) 2
00:52:14 <fjb> No, not ^2 but ~2.
00:52:38 <fjb> Yes, thank you Aali.
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:53:33 <fjb> so "x &= ~2;" should do.
00:53:44 <Aali> yep
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!
00:54:34 <ben_goodger> night
00:54:48 <fjb> Night ben_goodger
01:22:40 *** Fuco has quit IRC
01:30:20 *** Wezz6400 has quit IRC
01:30:50 *** roboboy has joined #openttd
01:31:32 *** roboboy has left #openttd
01:31:41 *** roboboy has joined #openttd
01:55:26 *** avdg[BEnl] has quit IRC
01:59:47 *** Frostregen_ has joined #openttd
01:59:47 *** Frostregen has quit IRC
01:59:57 *** Frostregen_ is now known as Frostregen
02:05:20 *** Yeggzzz has quit IRC
02:20:19 *** Digitalfox has joined #openttd
02:22:03 *** Digitalfox has quit IRC
02:22:54 *** Digitalfox has joined #openttd
02:39:41 *** glx has quit IRC
02:45:41 *** welshdragon2 has quit IRC
03:03:01 *** elmex_ has joined #openttd
03:07:51 *** elmex has quit IRC
03:07:55 *** elmex_ is now known as elmex
03:11:09 *** Sacro|Laptop has quit IRC
03:25:17 *** grumbel has joined #openttd
03:44:55 *** Sacro has quit IRC
05:44:50 *** Frostregen has quit IRC
06:05:42 *** Zorni has joined #openttd
06:10:24 *** Zorn has quit IRC
06:17:14 *** Alberth has joined #openttd
07:38:43 *** Progman has joined #openttd
07:41:32 *** Eddi|zuHause has quit IRC
07:41:42 *** Wolf01 has joined #openttd
07:42:39 <Wolf01> hello
07:44:01 <Alberth> good morning
07:44:32 *** Eddi|zuHause has joined #openttd
07:48:48 *** FloSoft has joined #openttd
08:12:55 *** TinoM 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:29 <TrueBrain> yup
08:27:32 <TrueBrain> almost finished .. I hope
08:27:38 <TrueBrain> Bye :)
08:33:08 *** vvv444 has joined #openttd
08:59:41 *** Wezz6400 has joined #openttd
09:00:30 *** Roujin has joined #openttd
09:00:41 <Roujin> cheers
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:12 <FloSoft> Roujin: use gdb?
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:16 *** Guest251 has quit IRC
09:17:54 <Roujin> gdb -> run -> [wait until assert] -> backtrace did the job
09:18:44 <petern> Eddi|zuHause?
09:19:06 <Eddi|zuHause> petern: some thread in the suggestions forum demands a windows native gui
09:19:17 <petern> hahaha
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:24 *** sunkan has joined #openttd
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:38:32 *** tokai has quit IRC
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:47:20 <Roujin> hmm
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:55:49 * Tefad stabs Gekz
09:56:39 <dih> whats with implementing tcl as console language :-D
09:56:46 <Gekz> yeah I know
09:56:47 <Gekz> it's shit
09:59:51 <dih> tcl is great
10:00:07 *** stillunknown has joined #openttd
10:00:40 <Gekz> I hate it
10:00:46 <Gekz> therefore no-one can use it
10:00:49 <Gekz> !
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:20 <dih> i am really enjoying 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:55 <dih> oh yes it has
10:04:56 <Gekz> dih: your native language is not english?
10:05:08 <Gekz> English humour is hard to grasp.
10:05:31 <dih> i am half english
10:05:52 <Gekz> that doesnt answer my question
10:05:57 <Gekz> I'm half dutch and dont speak any dutch
10:06:53 <Gekz> !seen pirate*
10:06:57 <Gekz> Hmm.
10:07:04 <Gekz> @seen pirate*
10:07:04 <DorpsGek> Gekz: I haven't seen anyone matching pirate*.
10:07:10 <Gekz> @seen *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:17 <Gekz> perhaps.
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:07:58 <dih> i.e. newgame([<seed>);
10:08:04 <dih> ])
10:08:08 <dih> is nastier than
10:08:14 <dih> newgame [<seed>]
10:10:44 * fjb votes for perl and hides.
10:11:02 <dih> yeah - hide!
10:12:36 <Eddi|zuHause> you can hide, but cannot run.
10:12:40 <Eddi|zuHause> ... err...
10:13:37 <dih> lol
10:14:48 * fjb would prefer Lisaac.
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:30:38 <dih> you start wondering
10:31:06 <Eddi|zuHause> i have no idea what you are talking about
10:31:20 <dih> NAIL + the noai branch
10:31:57 <Eddi|zuHause> that one i got before you were babbling incoherently
10:32:24 <dih> what was 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:40 <petern> no
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:05 <dih> it's 64bit
10:38:08 <petern> yes
10:38:19 <petern> you were complaining about a lack of unsigned integers
10:38:21 <dih> unsupported data type
10:39:22 <dih> so are you more after ditching the console all together?
10:39:31 <petern> ...
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:44 <dih> ah
10:39:45 <dih> hehe
10:39:59 <dih> it lacks a lot, a lot it could do
10:40:08 <dih> commands
10:40:10 <dih> output
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:12 <dih> no further additions
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:21 <dih> more output
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:13 <dih> yay
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 *** ecke has joined #openttd
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:24 <dih> uh - odd
10:46:29 <petern> well
10:46:35 *** NukeBuster has joined #openttd
10:46:52 <petern> totally frivilous
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:24 <dih> well of course not
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:52:58 <Roujin> @logs
10:53:01 <Roujin> !logs
10:53:01 <SpComb> Logs: http://zapotek.paivola.fi/~terom/logs/openttd
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:05:57 <dih> muting clients
11:06:14 <dih> trigger callbacks with chat
11:06:24 <dih> (that chat is then not distributed to other clients)
11:06:31 <dih> authentication system
11:06:35 <dih> wee
11:06:47 <dih> distributed banning?
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:22 <dih> :-)
11:07:35 <dih> "please give me 20000000" :-D
11:08:01 <roboboy> like in AOE?
11:08:22 <dih> Yexo, wrote a patch i think that would add chat to the AI's
11:08:28 <roboboy> and taunts
11:08:55 <dih> client side would allow notifications on x
11:09:03 <dih> play sound when
11:09:07 <dih> show an error box
11:09:49 <dih> send x command via rcon when i login to server x
11:14:43 <NukeBuster> sounds interestin
11:14:44 <NukeBuster> g
11:16:20 *** yorick has joined #openttd
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:18:40 <dih> lol
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:21:12 <dih> that is already possible
11:21:18 <dih> if you patch your server
11:21:23 <dih> you can forbid any tf
11:21:30 <NukeBuster> hmm
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:16 * petern boots to windows
11:23:21 <dih> no it would not
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:33 <NukeBuster> sorry
11:23:36 <NukeBuster> expensive
11:23:43 <dih> sierra1024, to forbid people flooding the map
11:23:55 <sierra1024> oh i see dih
11:23:57 <dih> NukeBuster, what information
11:24:03 <NukeBuster> terraforming info
11:24:03 <dih> someone tf'ed a tile?
11:24:08 <dih> someone tf'ed 15 tiles?
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:25:59 <dih> and that :-)
11:26:01 <NukeBuster> thats true
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:25 <dih> which is silly
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:06 *** Roujin has quit IRC
11:27:09 <dih> if they are separated you can controll them with a grf
11:27:18 *** Roujin has joined #openttd
11:27:29 <yorick> but everyone needs to have that grf
11:27:43 <dih> so?
11:27:55 <NukeBuster> thats lame
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:06 <dih> for one thing
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:35 <dih> ?
11:29:37 <dih> so?
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:22 <NukeBuster> still a hassle
11:31:29 <dih> no - YOU are curious
11:31:32 <sierra1024> lol
11:31:37 <sierra1024> mankind is curious
11:31:49 *** welshdragon has quit IRC
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:32:52 <yorick> pfew
11:33:14 <NukeBuster> lol
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:38:55 <yorick> what?
11:39:08 <dih> left to right? or at the bottom of the page?
11:39:11 <dih> :-P
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:41:26 <dih> aye
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:43:43 <yorick> how do you mean?
11:43:47 <yorick> console_cmds.cpp?
11:43:49 <NukeBuster> code wise
11:44:10 <dih> the way the console works is pretty ugly
11:45:30 <NukeBuster> there is no console_cmdsc.pp
11:45:33 <NukeBuster> .cpp
11:45:56 <yorick> src/console_cmds.cpp
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:34 <yorick> http://svn.openttd.org/trunk/src/console_cmds.cpp
11:46:35 <Eddi|zuHause> # (was solln die Nachbarn sagen)
11:47:01 <NukeBuster> strange
11:47:07 <NukeBuster> I'll checkout again
11:47:14 *** stillunknown has quit IRC
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:50:25 <NukeBuster> ?
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:05 <NukeBuster> ah
11:54:34 <NukeBuster> even if you would call void IConsolePrint() again?
11:55:00 <yorick> nope
11:55:04 <yorick> not then
12:00:49 *** KritiK has joined #openttd
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:08:14 * yorick looks at NukeBuster
12:08:39 *** eMJay has joined #openttd
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:16:49 <dih> oh - petern
12:16:58 <dih> try the following
12:17:05 <dih> echo "foo ; echo bar"
12:17:06 <dih> :-)
12:17:19 <dih> what would you expect?
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:17:55 <Rubidium> s/i/o/
12:18:54 <NukeBuster> so what happends if you echo "can't"?
12:18:59 *** sierra1024 has quit IRC
12:19:56 *** yorick has quit IRC
12:20:32 <dih> Rubidium, but odly it does kinda have support for quotes
12:20:36 <dih> i.e. names "foo bar"
12:20:39 <dih> eh
12:20:42 <dih> name "foo bar"
12:20:52 <dih> and the echo thingy would not do
12:20:53 <dih> foo
12:20:54 <dih> bar
12:20:58 <dih> as if it were an alias
12:21:04 <dih> alias supports ;
12:24:28 <Eddi|zuHause> you really need to work on your ability to form whole sentences
12:25:56 *** glx has joined #openttd
12:25:56 *** ChanServ sets mode: +v glx
12:26:00 <Doorslammer> Sometimes I words say in reverse
12:26:17 <dih> Eddi|zuHause, :-)
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:24 <glx> right
12:39:45 <NukeBuster> ok thanks, had to be sure.
12:51:50 *** Fuco has joined #openttd
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:00:09 *** mortal has quit IRC
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:10:00 <Roujin> it's a mistery :P
13:11:41 *** ben_goodger has quit IRC
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:14:52 *** Mortal has joined #openttd
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:21:14 *** Guest269 has quit IRC
13:31:10 *** Zuu has joined #openttd
13:42:35 *** HerzogDeXtEr has joined #openttd
13:46:34 *** Sacro has joined #openttd
13:46:36 *** Dred_furst has joined #openttd
13:49:23 *** HerzogDeXtEr1 has quit IRC
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:53:10 <Sacro> yay for O9
13:53:11 <Sacro> err
13:53:14 <Sacro> O(1)
13:53:39 <Wolf01> roads owned by tiles?
13:54:20 <planetmaker> towns
13:54:34 <Wolf01> or players?
13:54:37 <planetmaker> towns
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:56:18 <planetmaker> sometimes :)
13:58:35 *** yorick has joined #openttd
13:59:19 <planetmaker> depending upon map, a lot: http://www.tt-forums.net/viewtopic.php?f=33&t=40038
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:23:47 *** mikl has joined #openttd
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:47 *** Gekz has quit IRC
14:30:59 *** jez9999 has joined #openttd
14:31:28 *** Zorni has quit IRC
14:31:33 *** Zorn 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:39 <dih> just the binary?
14:34:48 <Eddi|zuHause> that does not have anything to do with AI...
14:34:59 <jez9999> didn't say it did
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:21 <dih> just a sneaky way round
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:38:59 *** Gekz has joined #openttd
14:39:25 *** Gekz has left #openttd
14:39:36 *** Gekz has joined #openttd
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:34 <dih> :-D
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:46:50 *** eMJay has quit IRC
14:49:20 <roboboy> gnight
14:49:49 <yorick> good afternoon
14:50:10 *** jez9999 has quit IRC
14:55:12 <yorick> http://paste.openttd.org/137889 <-- any comments?
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:57:12 <Rubidium> the latter
14:58:04 <vvv444> Ic. Well, if so, can I propose refactoring/code beautifing patches?
14:58:23 <yorick> yes
14:58:38 <Rubidium> proposing isn't very useful
14:58:56 <yorick> but you can
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:00:30 <vvv444> Of course...
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:02:33 <vvv444> Oh
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:10 <Rubidium> IDE?
15:05:12 <Rubidium> ;)
15:05:19 <Sacro> Rubidium: you using ed?
15:05:29 * Rubidium usually reads patches in his browser/using less
15:06:00 <Sacro> less is nice
15:06:02 <Sacro> most is nicer
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:05 <vvv444> :(
15:13:41 <vvv444> Still try WinMerge, maybe it does ;)
15:13:43 *** mikl has quit IRC
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:14:39 *** Reemo has joined #openttd
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:14 *** Dr_Jekyll has quit IRC
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:25:50 <Rubidium> huh?
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:29:55 <vvv444> oh, ic, sorry
15:33:49 *** Mortal has quit IRC
15:40:55 *** grumbel has quit IRC
15:40:55 *** mortal`` has joined #openttd
15:43:30 *** Burty has joined #openttd
15:43:42 <Burty> hey everyone
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:47:29 *** mortal` has quit IRC
15:47:31 <vvv444> *tile
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:50:19 <vvv444> :)
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:51:58 <vvv444> NO!
15:52:07 <Rubidium> why no?
15:52:07 <vvv444> Look you don't have to allocate the object
15:52:14 <Rubidium> then what?
15:52:16 <vvv444> Just a sec, my english is slow :)
15:53:49 *** mortal`` has quit IRC
15:54:05 <Rubidium> then I'll read it a lot later tonight
15:54:07 * Rubidium is gone
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:09 *** Guest283 has quit IRC
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:01:53 *** lobster_MB has quit IRC
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:08 *** lobster has quit IRC
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:11:58 *** Alberth has left #openttd
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:14:24 <frosch123> yup, as before :)
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:16:03 <sierra1024> lol
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:27:19 *** mortal has quit IRC
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:39 <dih> hehe
16:30:43 *** mortal`` has joined #openttd
16:30:52 <yorick> Zuu: nope
16:30:57 <yorick> http://svn.openttd.org/branches/cpp_gui/
16:31:24 <Zuu> okay
16:31:55 <glx> yorick: on vcs it is
16:32:52 *** welshdragon has quit IRC
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:28 *** Doorslammer has quit IRC
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:36:25 *** Burty has quit IRC
16:37:18 *** mortal` has quit IRC
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:16 <glx> Zuu: msvc?
16:39:19 <Zuu> frosch123: Which patch are you refering to?
16:39:21 <Zuu> glx: Yep
16:39:33 * glx broke something it seems
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:41:58 <glx> hmm I get r14531M
16:42:22 <glx> tortoise ?
16:42:31 <Zuu> glx: Can be me, mixed something up. it is first time I'm using hg queues.
16:42:40 <Zuu> Yes, tortoise svn.
16:42:46 <glx> it's me :)
16:44:10 * frosch123 got an idea
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:45:23 <glx> Zuu: fixed :)
16:45:27 <Zuu> Nice :)
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:00 <frosch123> Zuu: http://devs.openttd.org/~frosch/diffs/OnOpenOSKWindow.diff
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:50:25 <Zuu> hehe
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:51:38 <frosch123> IIRC yes
16:51:47 <frosch123> and some dead code
16:51:51 *** mortal`` has quit IRC
16:55:01 *** yorick has quit IRC
16:55:12 *** ecke has quit IRC
16:55:32 *** ecke has joined #openttd
16:57:42 *** Reemo has quit IRC
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:34 *** Sacro has quit IRC
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 *** Bjarni has joined #openttd
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:23 *** Burty has joined #openttd
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:34 <glx> (file rename/move)
17:17:47 <Burty> one of which is players.cpp
17:17:51 *** ecke has quit IRC
17:18:03 <Burty> ?
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:19:59 *** ecke has joined #openttd
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:20:59 *** ecke has quit IRC
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:43 *** ecke has joined #openttd
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:35:50 <glx> http://svn.libgpmi.org/svn/gpmi_extensions/trac.cgi/changeset/1365 <-- I did it like that in another project
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:41:19 *** Mortal has joined #openttd
17:43:43 *** Sacro has joined #openttd
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:44:29 *** mortal` has quit IRC
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:49:49 *** Mortal has quit IRC
17:51:15 <Zuu> Well I have 2.5 GB of OpenTTD checkouts/compiles that could be moved to another partion.
17:52:28 *** mortal`` has quit IRC
17:53:24 *** Mortal has joined #openttd
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:55:51 <glx> ok 12.2GB
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:02:09 *** yorick has joined #openttd
18:02:29 *** Mortal has quit IRC
18:05:07 *** Burty has quit IRC
18:05:20 *** Mortal has joined #openttd
18:05:49 *** mortal` has quit IRC
18:14:29 *** mortal` has joined #openttd
18:15:51 *** Mortal has quit IRC
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:34 <yorick> what ads?
18:19:43 <Bjarni> >_<
18:19:52 <Bjarni> forums should be silent
18:20:05 <Sacro> adblock+ ftw
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:22:34 *** mortal` has quit IRC
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:09 <yorick> it just looks similar
18:27:14 <SmatZ> it's very same :)
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:28:17 <SmatZ> yeah :)
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:39:43 *** Mortal has joined #openttd
18:50:41 *** mortal` has joined #openttd
18:51:18 *** sierra1024 has quit IRC
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:52:49 *** Mortal has quit IRC
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:57:52 <Zuu> glx: http://bugs.openttd.org/task/2382
18:58:01 <Zuu> (removal of magic numbers)
18:58:10 * glx checks :)
18:58:36 <CIA-5> OpenTTD: frosch * r14533 /trunk/src/landscape.cpp: -Fix: ...hopefully most glitches wrt. inclined foundations.
18:58:56 *** mortal` has quit IRC
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:01:57 <Zuu> /noly/only/
19:02:09 <glx> hmm yes, sounds better
19:04:49 * vvv444 encountered "highways" in the codebase, anyone who can explain about this feature plz
19:05:06 <glx> non existant
19:05:16 <vvv444> planned for feature?
19:05:22 <glx> maybe
19:05:30 <vvv444> tnx
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:46 <glx> right
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:11:42 <glx> ok
19:13:20 <frosch123> how about "HEBR_EDITING", "HEBR_ENTER", "HEBR_CANCEL"?
19:15:47 <Zuu> "HEBR_EDITING", "HEBR_CONFIRM", "HEBR_CANCEL" ?
19:16:49 <glx> sounds good too
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:22:17 <Zuu> :p
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:26:26 *** welshdragon has quit IRC
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:36:59 <glx> it's ok for me
19:38:02 <glx> hmm failed to apply
19:38:50 <Zuu> Oops, I'll check it.
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:40 *** Sacro has quit IRC
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:50:41 *** Sacro has joined #openttd
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:00 *** fjb_ has joined #openttd
19:52:39 <frosch123> ok, GetAnyRoadBits could be a member of the root calls
19:52:50 <frosch123> *class
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:43 <glx> hehe
19:54:49 <glx> what are you burning?
19:54:50 <vvv444> frosch123: Ok, actually I have to check mine too :)
19:54:59 <vvv444> bb in 10 min
19:55:39 * Zuu takes a slice dark bread :-)
19:56:24 *** fjb has quit IRC
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)
19:59:37 <Zuu> Cool
19:59:49 <Zuu> Thanks glx
20:01:53 * Bjarni notes that Zuu just moved a bit towards the dark side
20:02:19 <Zuu> hehe ok
20:02:21 <Bjarni> I mean you are what you eat :)
20:02:33 <Zuu> :-p
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:18 <NukeBuster> ?
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:17:50 <NukeBuster> thanks
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:20:27 <frosch123> use 'svn status'
20:20:30 <Nite_Owl> Hello all
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:04 *** Guest302 has quit IRC
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:28:44 *** yorick has quit IRC
20:28:57 *** TinoM has quit IRC
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:00 <vvv444> (3)
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:52:55 *** FloSoft has quit IRC
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:03:00 <Zuu> Yep
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:07:31 <Zuu> :-)
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:15 <Zuu> I've used this tutorial if you have not found it yet: http://hgbook.red-bean.com/hgbookch12.html
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 *** tokai has joined #openttd
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:18:52 <Aali> is it really that bad?
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:52 <Zuu> And you?
21:49:58 <planetmaker> Zuu: thanks. Indeed I want that :)
21:50:11 * TrueBrain waves hello
21:50:22 * Zuu waves back on TrueBrain
21:50:33 * planetmaker waves a hello @ TB
21:50:55 <TrueBrain> how are you all doing my friends?
21:51:54 <Rubidium> pretty good ;)
21:52:08 <Rubidium> though /me feels tomorrow will be a long day ;)
21:52:38 <TrueBrain> Rather tonight :)
21:58:00 <TrueBrain> hmmm .. we all hear gunshots outside
21:58:03 <TrueBrain> is that a good thing? :s
21:58:10 <glx> dunno
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:16 <glx> nice one frosch123
22:01:24 <frosch123> :(
22:01:28 <scarabeus> proxy-maintaining
22:01:33 <frosch123> :)
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:52 <TrueBrain> ah
22:01:53 <scarabeus> i just upload to gentoo
22:01:56 <TrueBrain> yeah, please :)
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:28 <TrueBrain> yup :)
22:02:32 <planetmaker> Zuu: where did you upload it? I cannot find it...
22:02:49 <Zuu> planetmaker: http://www.tt-forums.net/viewtopic.php?f=33&t=38715&p=739120#p739120
22:03:00 <Zuu> It's not on FS.
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:30 <scarabeus> oh right sorry
22:03:32 <planetmaker> :)
22:03:36 <scarabeus> :(
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:19 <TrueBrain> but most likely :)
22:04:29 <TrueBrain> tonight we switch to CET .. so +0100 .. hmm .. yeah :p
22:04:39 <planetmaker> he, thx, Zuu :)
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:00 <Zuu> We get one hour extra?
22:05:05 <glx> yes
22:05:11 <Zuu> Who :-)
22:05:11 <planetmaker> yep
22:05:15 <scarabeus> we just want it tested, nah kidding it allows use dependencies
22:05:17 <planetmaker> all :P
22:05:22 <Zuu> Wohoo*
22:05:25 <planetmaker> :D
22:05:45 <TrueBrain> anyway, me is going to bed .. talk to you tomorrow scarabeus :)
22:05:51 <TrueBrain> night all!
22:05:52 <scarabeus> ook
22:05:53 <scarabeus> gn
22:06:01 <glx> night TrueBrain
22:06:06 <Zuu> Good night TrueBrain
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:12 * planetmaker waves
22:06:12 <Nite_Owl> Later TrueBrain
22:06:19 *** scarabeus has quit IRC
22:06:55 *** rubyruy has joined #openttd
22:08:30 *** Aali_ 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:16 *** Aali has quit IRC
22:10:18 *** Aali_ is now known as Aali
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:01 <Wolf01> 'night
22:14:06 <rubyruy> i mean even without variable maint costs, slopes would affect delivery speed anyway
22:14:07 *** Wolf01 has quit IRC
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:17:34 <frosch123> http://www.tt-forums.net/viewtopic.php?f=29&t=39253&p=722463&hilit=optimal+travel+distance#p722463
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:19:17 *** Nite_Owl has quit IRC
22:19:28 <rubyruy> ahh nice
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:32:52 <glx> well not too short
22:33:04 <rubyruy> right
22:33:10 *** frosch123 has quit IRC
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:09 <glx> and engine power
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:19 <rubyruy> bah - wrong key
22:35:22 <rubyruy> ... are more dev/modding oriented
22:37:26 *** Progman has quit IRC
22:47:21 *** Nightraven has quit IRC
22:50:40 *** Aali_ has joined #openttd
22:51:19 *** helb has quit IRC
22:52:29 *** Aali has quit IRC
22:53:20 <Zuu> Night all
22:53:23 *** Zuu has quit IRC
22:54:08 *** helb has joined #openttd
22:56:29 *** vvv444 has quit IRC
22:59:17 *** KritiK has quit IRC
23:05:49 *** Vikthor has quit IRC
23:09:12 <Eddi|zuHause> i hate the time switch... it always screws up any recordings that i plan during that night...
23:11:37 *** HerzogDeXtEr has quit IRC
23:12:55 *** HerzogDeXtEr has joined #openttd
23:21:31 *** rortom has joined #openttd
23:26:36 *** rortom has quit IRC
23:29:41 *** tokai has quit IRC
23:31:24 *** tokai has joined #openttd
23:31:24 *** ChanServ sets mode: +v tokai
23:37:49 *** mikl has joined #openttd
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:14 *** mortal has quit IRC
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
23:42:13 <dih> sorry for the annoyance
23:56:40 *** Roujin has quit IRC
23:57:08 *** helb has quit IRC