Back to Home / #openttd / 2008 / 10 / Prev Day | Next Day
#openttd IRC Logs for 2008-10-25

---Logopened Sat Oct 25 00:00:57 2008
01:44-!-Frostregen [] has quit [Quit: und weg]
02:05-!-Zorni [] has joined #openttd
02:10-!-Zorn [] has quit [Ping timeout: 480 seconds]
02:17-!-Alberth [] has joined #openttd
03:38-!-Progman [] has joined #openttd
03:41-!-Eddi|zuHause [] has quit [Read error: Connection reset by peer]
03:41-!-Wolf01 [] has joined #openttd
03:44<Alberth>good morning
03:44-!-Eddi|zuHause [] has joined #openttd
03:48-!-FloSoft [] has joined #openttd
04:12-!-TinoM [] has joined #openttd
04:17-!-Vikthor [] has joined #openttd
04:26*TrueBrain waves hello to this channel
04:26<TrueBrain>and sadly enough, also goodbye :) Back tomorrow :p
04:26<@Rubidium>poor TrueBrain :( too much worky to do
04:27<TrueBrain>almost finished .. I hope
04:27<TrueBrain>Bye :)
04:33-!-vvv444 [] has joined #openttd
04:59-!-Wezz6400 [] has joined #openttd
05:00-!-Roujin [] has joined #openttd
05:02<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
05:03<FloSoft>Roujin: use gdb?
05:03-!-mortal` [] has joined #openttd
05:03<FloSoft>build with debug symbols and the use gdb?
05:06-!-mortal` is now known as mortal
05:06<Roujin>thanks FloSoft, trying to figure it out now :)
05:09-!-mortal` [] has joined #openttd
05:10<Eddi|zuHause>hm... "Windows-Native GUI?" <- no game that takes itself serious in the last 15 years has used a "native gui"
05:10-!-mortal is now known as Guest251
05:10-!-mortal` is now known as mortal
05:13<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
05:17<Roujin>uhm, thanks, but already worked it out :)
05:17-!-Guest251 [] has quit [Ping timeout: 480 seconds]
05:17<Roujin>gdb -> run -> [wait until assert] -> backtrace did the job
05:19<Eddi|zuHause>petern: some thread in the suggestions forum demands a windows native gui
05:21<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?
05:21<Roujin>there must be a better way to do this...
05:21<Alberth>Roujin: with core dump you can run outside the debugger. I run OpenTTD by default in this way.
05:25-!-sunkan [] has joined #openttd
05:25-!-frosch123 [] has joined #openttd
05:28-!-Yeggstry [] has joined #openttd
05:35<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)
05:38-!-tokai [] has quit [Quit: icebears... take care of them!]
05:39<Eddi|zuHause>the advantage of that was that you could then give a vehicle enter tile function similar to the other tiles
05:40<Eddi|zuHause>which is kind of necessary for trains to stop in front of signals
05:51<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
05:54<Gekz>who was the guy who wanted to buy my P3 mobo
05:55*Tefad stabs Gekz
05:56<dih>whats with implementing tcl as console language :-D
05:56<Gekz>yeah I know
05:56<Gekz>it's shit
05:59<dih>tcl is great
06:00-!-stillunknown [] has joined #openttd
06:00<Gekz>I hate it
06:00<Gekz>therefore no-one can use it
06:01*Gekz has to stop saying "x is shit" without stating "I believe that"
06:04<dih>you may hate it, but only because you are not used to it
06:04<dih>i am really enjoying it
06:04<dih>also i am enjoying erlang
06:04<Gekz>I don't like it because it's ugly as hell
06:04<Gekz>and has nothing over any other language
06:04<dih>and just because you dont like it does not mean nobody can use it
06:04<dih>oh yes it has
06:04<Gekz>dih: your native language is not english?
06:05<Gekz>English humour is hard to grasp.
06:05<dih>i am half english
06:05<Gekz>that doesnt answer my question
06:05<Gekz>I'm half dutch and dont speak any dutch
06:06<Gekz>!seen pirate*
06:07<Gekz>@seen pirate*
06:07<@DorpsGek>Gekz: I haven't seen anyone matching pirate*.
06:07<Gekz>@seen *pirate*
06:07<@DorpsGek>Gekz: welshpirate was last seen in #openttd 5 weeks, 1 day, 10 hours, 43 minutes, and 50 seconds ago: <welshpirate> ln-, nay
06:07<dih>anyway - the nice thing with tcl over say squirrel would be that you would not need brackets to pass arguments
06:07<dih>i.e. newgame([<seed>);
06:08<dih>is nastier than
06:08<dih>newgame [<seed>]
06:10*fjb votes for perl and hides.
06:11<dih>yeah - hide!
06:12<Eddi|zuHause>you can hide, but cannot run.
06:12<Eddi|zuHause>... err...
06:14*fjb would prefer Lisaac.
06:20<dih>seriously i dont think it's such a bad idea :-P
06:20<dih>using tcl as console language
06:20<dih>you would not even notice if you did not want to write scripts
06:22<Eddi|zuHause>it makes absolutely no sense to maintain more than one scripting engine (virtual machine, API)
06:24<dih>as much as it does writing your own for ai's
06:25<dih>besides - who sais it has to be a must?
06:25<dih>i.e. if you want tcl support, compile it yourself with --enable-tcl ?
06:26<Eddi|zuHause>nobody said compiling... i said maintaining
06:26<CIA-5>OpenTTD: rubidium * r14527 /trunk/src/sound.cpp: -Fix: allocate stub (empty) sound entries when loading an empty/corrupt/incorrectly sized instead of making valid NewGRFs fail to load.
06:27<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
06:27<@Rubidium>not to mention issues with suspending
06:29<dih>the great support for unsigned int
06:29<dih>and afaik that is not even planed for NAIL
06:30<dih>+ when you hear 'needs complete rewrite' and it should replace squirrel?
06:30<dih>you start wondering
06:31<Eddi|zuHause>i have no idea what you are talking about
06:31<dih>NAIL + the noai branch
06:31<Eddi|zuHause>that one i got before you were babbling incoherently
06:32<dih>what was incoherently?
06:33<Eddi|zuHause>the 4 lines before i said i don't understand you
06:34<dih>squirrel nor nail support unsigned integers
06:34<dih>guess what the seed is e.g.
06:34<Eddi|zuHause>you should discuss that with TrueBrain, i suppose
06:35<dih>happened many times before
06:35<@petern>they're both 32 bit values, what's the problem?
06:36<dih>say you wanted to implement a scripting language into the console
06:36<dih>say someone then comes along and wants to check on the money a certain company has
06:36<dih>or if you want to generate the seed
06:37<dih>if the scriting language does not support those data types it sucks
06:37<@petern>i don't particularly see the need for a scriptable console
06:37<dih>you see the need for rewriting the console?
06:37<dih>the way commands / arguments are handled is not really good
06:37-!-Doorslammer [] has joined #openttd
06:37<@petern>and money is signed anyway, so that's a useless excample
06:38<dih>it's 64bit
06:38<@petern>you were complaining about a lack of unsigned integers
06:38<dih>unsupported data type
06:39<dih>so are you more after ditching the console all together?
06:39<dih>i would doubt that to be honest
06:39<@petern>i see no problem with the existing console
06:39<dih>it lacks a lot, a lot it could do
06:40<@petern>a scripting language won't help adding commands much
06:40<dih>and scripting support would be useful to let admins make their servers more 'unique'
06:40<dih>and you could add a bunch of handling to that
06:40<dih>+ it would let clients to a bunch of automated stuff too
06:41<planetmaker>a toast on Rubidium for the last commit :)
06:41<dih>current console is kinda frozen
06:41<dih>no further additions
06:41<Alberth>petern: a scripting language tends to streamline that process
06:41<dih>and afaik the console is not getting additions because it's not worth putting any effort into _that_ console
06:41<@petern>no further additions are necessary to do what is needed
06:42<@petern>about the only extra thing i can think of is allowing an admin to reset a company password
06:42<@petern>and a scripting language won't help that
06:42<dih>i can think of a wee bit more
06:43<dih>more output
06:43<dih>or support for getting id's of clients by their nicks
06:43<dih>as every command uses the id not the nick
06:44<dih>and all you get on the console when someone joins is the nick
06:44<dih>callback's dont take arguments
06:44<Alberth>dih: In Python they do :D
06:44<dih>so when a new client joins you can only greet him in public
06:45<dih>when a company goes bankrupt - console never sees a thing of that
06:45<@petern>scripting won't help that
06:45-!-ecke [~ecke@] has joined #openttd
06:45<Alberth>dih: you see it as a kind of irc chat window?
06:45<dih>move clients between companies (inc. spectator)
06:45<dih>petern: scripting would help
06:46<dih>say_client( get_client_id( 'foobar' ), "welcome");
06:46<dih>uh - odd
06:46-!-NukeBuster [~wouter@] has joined #openttd
06:46<@petern>totally frivilous
06:47<@petern>i would not object to something being added
06:47<@petern>but i will not expend any time doing it
06:49<dih>well of course not
06:49<dih>but that is the first time in about 3/4 year i have heard that
06:50<dih>perhaps you devs should have a get2gether and see if you all are supporting the same idea
06:50<dih>it's kinda not so helpful if 3 devs say x and 2 say y
06:58-!-welshdragon2 [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has joined #openttd
07:00-!-welshdragon2 is now known as welshdragon
07:00-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has quit []
07:00-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has joined #openttd
07:03<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
07:04<Eddi|zuHause>(the process of exposing a function)
07:05<Eddi|zuHause>meaning a server can then script hooks in case of certain event messages
07:05<dih>controlling chat, server side
07:05<dih>i.e. having a list of bad words
07:05<dih>muting clients
07:06<dih>trigger callbacks with chat
07:06<dih>(that chat is then not distributed to other clients)
07:06<dih>authentication system
07:06<dih>distributed banning?
07:07<dih>all that could be scripted
07:07<dih>and up to the server admin to implement
07:07<Eddi|zuHause>AIs reacting to chat messages would be cool ;)
07:07<dih>"please give me 20000000" :-D
07:08<roboboy>like in AOE?
07:08<dih>Yexo, wrote a patch i think that would add chat to the AI's
07:08<roboboy>and taunts
07:08<dih>client side would allow notifications on x
07:09<dih>play sound when
07:09<dih>show an error box
07:09<dih>send x command via rcon when i login to server x
07:14<NukeBuster>sounds interestin
07:16-!-yorick [] has joined #openttd
07:17-!-sierra1024 [] has joined #openttd
07:17<sierra1024>good morning gentlemen
07:18<Alberth>a program is not complete until you can chat with it :P
07:19<NukeBuster>it would grant the admin alot more control over his server
07:19<NukeBuster>allows him to restrict massive terraforming
07:20<NukeBuster>with a patch of course
07:21<dih>that is already possible
07:21<dih>if you patch your server
07:21<dih>you can forbid any tf
07:22<sierra1024>kind of strange, anyway, to forbid terraforming
07:22<NukeBuster>Should make it more expansive :)
07:23<@petern>scriptable console would not allow control over terraforming
07:23*petern boots to windows
07:23<dih>no it would not
07:23<sierra1024>NukeBuster, expansive or expensive ?
07:23<NukeBuster>even if that would information would be fed to the console?
07:23<dih>sierra1024, to forbid people flooding the map
07:23<sierra1024>oh i see dih
07:23<dih>NukeBuster, what information
07:24<NukeBuster>terraforming info
07:24<dih>someone tf'ed a tile?
07:24<dih>someone tf'ed 15 tiles?
07:24<dih>then i'll just break my tf down to 15 x 1 tile
07:24*yorick would still like client ids in CommandPackets
07:24<NukeBuster>yeah, with repeated amounts you give warn warn kick warn ban
07:25<NukeBuster>or avg terraforming rate
07:25<dih>only if you memorize the client some way or another
07:25<dih>+ what he has done so far
07:25<yorick>NukeBuster: that would not stop them fromm flooding the map at once
07:25<dih>too expensive i would think
07:25<dih>and that :-)
07:26<NukeBuster>thats true
07:26<dih>unless you sit between command packet arriving and being put on the queue
07:26<NukeBuster>then price would be a better thing
07:26<dih>which is silly
07:26<@petern>gah, stupid setpoint still doesn't see the mouse after boot up :(
07:26<dih>NukeBuster, price for tf also influences building on slopes
07:27<dih>so until that is a different price, you are stuck with it
07:27<NukeBuster>if your average tf average is high your costs will increase
07:27-!-Roujin [] has quit [Remote host closed the connection]
07:27<dih>if they are separated you can controll them with a grf
07:27-!-Roujin [] has joined #openttd
07:27<yorick>but everyone needs to have that grf
07:27<NukeBuster>thats lame
07:28<sierra1024>having grf is not lame
07:28<NukeBuster>unless you can autodownload them
07:28<NukeBuster>which authors don't like
07:28<yorick>but it needs to be a known grf
07:28<dih>NukeBuster, it's not that important
07:29<dih>the openttdcoop grfpack is kinda distributed
07:29<dih>for one thing
07:29<NukeBuster>yeah, ok thats true
07:29<yorick>yes, but the grf needs to be in that openttdcoop grfpack
07:29<yorick>and you will not target the new players
07:29<NukeBuster>I still hate having to find the right grf to play on a server i find via the multiplayer window
07:30<dih>they usually have a list of grf's on their website
07:30<yorick>you need to have the url
07:30<NukeBuster>would mean i have to find out what their website is
07:30<dih>and if they dont and the grf's are not in the grf pack why play there?
07:31<yorick>because that server could be fun and a challenge
07:31-!-welshdragon2 [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has joined #openttd
07:31<dih>the server name holds often enough more details than you need for that
07:31<yorick>and because we are CURIOUS
07:31<NukeBuster>still a hassle
07:31<dih>no - YOU are curious
07:31<sierra1024>mankind is curious
07:31-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has quit [Read error: Connection reset by peer]
07:31<yorick>we doesn't include you ;)
07:31-!-welshdragon2 is now known as welshdragon
07:32-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has quit []
07:32<sierra1024>every single one is curious ... otherwise ... we would still sit caves and not have pc and openttd to play
07:32<dih>yorick, never tell a girlfriend that :-D
07:32-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has joined #openttd
07:32<yorick>last time I checked, you were not my girlfriend
07:33<NukeBuster>but you want to script the console dih?
07:33<dih>yorick, how many times must i tell you to forget that idea?
07:33<NukeBuster>like in source games?
07:33<dih>i am not gay, not into kids, and way too old for you
07:34<dih>NukeBuster, i want a decent console
07:34<yorick>he wanted to script the console since the console was there
07:34<dih>yorick, you talk nonsense
07:36<dih>also fun would be if the in-game console was displayed see-through - like the chat messages appear :-D
07:36-!-Dr_Jekyll [] has joined #openttd
07:38<yorick>it would also be fun if the console would have linebreaks
07:38<NukeBuster>but wasn't the openttd console the otherway around?
07:39<dih>left to right? or at the bottom of the page?
07:39<NukeBuster>no... in the q3 engine you can access all functions from the console...
07:39<NukeBuster>they then made the gui around that
07:40<dih>the openttd console is pretty limited
07:40<NukeBuster>bottom of the page would be unique though
07:42*dih wonders how performance would differ if tcl was the ai language :-P
07:42<NukeBuster>is there a proper way to add to the console currently?
07:43<yorick>how do you mean?
07:43<NukeBuster>code wise
07:44<dih>the way the console works is pretty ugly
07:45<NukeBuster>there is no console_cmdsc.pp
07:46<Eddi|zuHause># Und immer deine Freunde
07:46<Eddi|zuHause># Ihr nehmt doch alle Drogen
07:46<Eddi|zuHause># Und ständig dieser Lärm
07:46<Eddi|zuHause># (was solln die Nachbarn sagen)
07:47<NukeBuster>I'll checkout again
07:47-!-stillunknown [] has quit [Ping timeout: 480 seconds]
07:50<NukeBuster>I can use the void IConsolePrint() from any where in the code or is there another way i should output to the console
07:51<yorick>IConsolePrint or IConsolePrintF yes
07:51<yorick>what do you like to output to it?
07:52<NukeBuster>not sure... but was wondering how one would output something
07:52<NukeBuster>so it isn't hard to improve console output...
07:53<yorick>but it lacks special characters like \n or \t
07:53<yorick>and it has no line breaks
07:54<NukeBuster>even if you would call void IConsolePrint() again?
07:55<yorick>not then
08:00-!-KritiK [] has joined #openttd
08:06<NukeBuster>and /n should be handled by void IConsoleGUIPrint()?
08:07<yorick>no, \n is not handled at all
08:07<NukeBuster>but if one were to implement that
08:08*yorick looks at NukeBuster
08:08-!-eMJay [] has joined #openttd
08:16<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.
08:16<dih>the sad thing with the console is that it reads char by char
08:16<dih>which is really not a nice way to handle commands and it's parameters
08:16<Alberth>we don't type fast enough !
08:16<dih>oh - petern
08:16<dih>try the following
08:17<dih>echo "foo ; echo bar"
08:17<dih>what would you expect?
08:17<Alberth>broken quoting support :)
08:17<NukeBuster>it should echo foo; echo bar
08:17<@Rubidium>both to execute because the code can't be bothered 'bout quites?
08:18<NukeBuster>so what happends if you echo "can't"?
08:18-!-sierra1024 [] has quit [Remote host closed the connection]
08:19-!-yorick [] has quit [Quit: Poef!]
08:20<dih>Rubidium, but odly it does kinda have support for quotes
08:20<dih>i.e. names "foo bar"
08:20<dih>name "foo bar"
08:20<dih>and the echo thingy would not do
08:20<dih>as if it were an alias
08:21<dih>alias supports ;
08:24<Eddi|zuHause>you really need to work on your ability to form whole sentences
08:25-!-glx [] has joined #openttd
08:25-!-mode/#openttd [+v glx] by ChanServ
08:26<Doorslammer>Sometimes I words say in reverse
08:26<dih>Eddi|zuHause, :-)
08:28*Alberth multiple constructors are nice!
08:29<Eddi|zuHause>lesson 1 in forming sentences: you need a finite verb form.
08:29<Eddi|zuHause>Alberth showed us a good example how not to do it, can anyone in the class correct his mistake?
08:30<Alberth>Eddi|zuHause: dih was practicing non-verbal communication
08:31<Alberth>Eddi|zuHause: your class seems to lack motivation.
08:39<NukeBuster>openttd codingstyle { comes on a new line with a function but not with an if?
08:39<NukeBuster>ok thanks, had to be sure.
08:51-!-Fuco [] has joined #openttd
08:51<NukeBuster>Belugas you around?
08:52<+glx>good luck to reach him ;)
08:53<NukeBuster>do you know why the last diagonal level and demolish patch wasn't accepted?
09:00-!-mortal [] has quit [Ping timeout: 480 seconds]
09:09<Roujin>uhm.. because it was full moon?
09:09<Roujin>do you know why they didn't want my drag&draw patch either? :P
09:10<Roujin>it's a mistery :P
09:11-!-ben_goodger [] has quit [Quit: Ex-Chat]
09:12<NukeBuster>I'd like to know why they didn't like want your drag and draw patch.
09:14<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.
09:14-!-Mortal [] has joined #openttd
09:15<dih>NukeBuster, the devs are not obliged to include any patch at all
09:15<dih>just something to be aware of
09:15<dih>or to keep in the back of your head
09:17<NukeBuster>I know that, but I also know that there were a few devs that liked the patch
09:18<NukeBuster>At least the functionality it would give. And by that I would assume there was still an unresolved issue in the coding.
09:19-!-Kommer is now known as Guest269
09:19-!-Kommer_ [] has joined #openttd
09:19-!-Kommer_ is now known as Kommer
09:21-!-Guest269 [] has quit [Ping timeout: 480 seconds]
09:31-!-Zuu [] has joined #openttd
09:42-!-HerzogDeXtEr [~Flex@] has joined #openttd
09:46-!-Sacro [~ben@adsl-87-102-39-137.karoo.KCOM.COM] has joined #openttd
09:46-!-Dred_furst [] has joined #openttd
09:49-!-HerzogDeXtEr1 [~Flex@] has quit [Ping timeout: 480 seconds]
09:52<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)
09:53<Sacro>yay for O9
09:53<Wolf01>roads owned by tiles?
09:54<Wolf01>or players?
09:54<planetmaker>:) I guess, iirc the thread / suggestion correctly
09:55<planetmaker>town roads did know their clostest town before. Now each road does.
09:56<NukeBuster>does this improve pathfinding?
09:56<planetmaker>it improves performance.
09:56<planetmaker>sometimes :)
09:58-!-yorick [] has joined #openttd
09:59<planetmaker>depending upon map, a lot:
09:59<yorick>"roads owned by tiles" <-- what?
10:01<planetmaker>towns... readt he link
10:01-!-Xeryus|bnc is now known as XeryusTC
10:15<yorick> /src/video/dedicated_v.cpp:229: warning: unused variable "__ct_assert__"
10:18<frosch123>produced by assert_compile, and not important
10:18<yorick>but still gives a warning
10:19<CIA-5>OpenTTD: frosch * r14529 /trunk/src/ (station.cpp station_base.h station_cmd.cpp): -Codechange: Turn FindCatchmentRadius() into Station::GetCatchmentRadius().
10:23-!-mikl [] has joined #openttd
10:25<CIA-5>OpenTTD: frosch * r14530 /trunk/src/economy.cpp: -Fix [FS#2138]: Do not deliver cargo to industries not inside station catchment area.
10:30-!-Gekz [] has quit [Ping timeout: 480 seconds]
10:30-!-jez9999 [] has joined #openttd
10:31-!-Zorni [] has quit [Read error: Connection reset by peer]
10:31-!-Zorn [] has joined #openttd
10:31<jez9999>Does OpenTTD NoAI tend to accept some patches that OpenTTD doesn't, or does it just sync with the OpenTTD codebase?
10:32<Zuu>NoAI syncs with OpenTTD codebase from time to time.
10:32<Zuu>It is done manually every now and then as far as I know.
10:33<@Rubidium>jez9999: only patches for the API will be considered for NoAI
10:33<jez9999>i wish the openttd main binary had my map colours patch in
10:33<jez9999>it makes things so much clearer on the owners map
10:34<dih>just the binary?
10:34<Eddi|zuHause>that does not have anything to do with AI...
10:34<jez9999>didn't say it did
10:35<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
10:35<dih>just a sneaky way round
10:35<Zuu>I guess the patch does not apply to current trunk, and jez9999 hoped that he could apply it to NoAI.
10:35<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
10:37<jez9999>it just sucks having to regularly recompile decent patches into my openttd, frankly
10:37<jez9999>close airports, copy/paste, map colours
10:37<jez9999>i guess i can understand opposition to copy/paste, but the other two seem like excellent candidates
10:38<jez9999>perfectly well coded and tested too
10:38-!-Gekz [] has joined #openttd
10:39-!-Gekz [] has left #openttd []
10:39-!-Gekz [] has joined #openttd
10:39<Eddi|zuHause>since when are you expert on how well anything is coded?
10:39<@Rubidium>jez9999: yes... I know the quality of the testing done by many of the patches
10:40<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
10:40<jez9999>Eddi|zuHause: since i started programming years ago, and hacking openttd a few years ago
10:40<jez9999>yeah i think i have a rough idea
10:40<@Rubidium>"this patch has been tested extensively in multiplayer", which then contains a huge desyncer
10:40<jez9999>map colours wont break multiplayer
10:41<dih>jez9999, as long as you are not a dev your rough idea just aint gonna be good enough :-)
10:46-!-eMJay [] has quit [Remote host closed the connection]
10:49<yorick>good afternoon
10:50-!-jez9999 [] has quit []
10:55<yorick> <-- any comments?
10:56<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?
10:57<@Rubidium>the latter
10:58<vvv444>Ic. Well, if so, can I propose refactoring/code beautifing patches?
10:58<@Rubidium>proposing isn't very useful
10:58<yorick>but you can
10:59<vvv444>By propose I mean written&compiled&debugged&tested diff file :)
11:00<@Rubidium>depends on the kind of changes
11:00<vvv444>Of course...
11: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.
11:01<@Rubidium>because if indenting changes it becomes very hard check the changes
11:01<@Rubidium>that's also known... it's C compiled as C++
11:01<Alberth>vvv444: project switched to c++ not long ago
11:01<vvv444>Rubidium: what do you mean by indenting changes?
11:02<@Rubidium>a complete function where you add/remove one tab of indentation
11:04<vvv444>Rubidium: Don't you have IDE tool to ignore whitespace changes?
11:04<vvv444>My WinMerge on Windows does that fine
11:05<Sacro>Rubidium: you using ed?
11:05*Rubidium usually reads patches in his browser/using less
11:06<Sacro>less is nice
11:06<Sacro>most is nicer
11:06<vvv444>Rubidium: That's your choice but sofisticated dev tools born to ease our life not theopposite :)
11:06<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?
11:07<@Rubidium>vvv444: I got annoyed by all IDEs I've tried
11:08<vvv444>I'm using Visual studio on windows. Sadly, it's the best I found :( No Opensource project compares.
11:09<frosch123>Eddi|zuHause: usually yes, most patch tools trigger on "Index:" and "@@"
11:09<vvv444>But TortoiseSVN & WinMerge are very comfortable indeed (these are GPLed).
11:09<frosch123>except you have a @%&!!%@ Solaris with tools from 1970 or so
11:12<@Rubidium>MSVC doesn't work in Wine
11:13<vvv444>Still try WinMerge, maybe it does ;)
11:13-!-mikl [] has quit [Quit: mikl]
11:14<vvv444>Although I'm pretty sure there are plenty of cool diff tools for Linux. No way none support whitespace ignorance.
11:14-!-Reemo [] has joined #openttd
11:15*vvv444 tried switching to Linux many times, every time gave up and returned to Windows with Cygwin.
11:15<Eddi|zuHause>"svn diff -x -w" or something
11:15<frosch123>are those tools the reason why so much patches screw up whitespaces?
11:15<@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
11:16<vvv444>frosch123: No, the stupid people who don't check are!
11:17<@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?)
11:18<Alberth>frosch123: most editors don't clearly show spurious white-space at the end of the line
11:18<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.
11:19<vvv444>When your code is factored properly and each function name tells what exactly it does you can even do almost without comments
11:19<Alberth>maybe have a patch sequence?, first a split without indent change, then a patch with only indent changes
11:20<@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
11:20<vvv444>On other hand comments tend to be mismaintaned and can become misleading.
11:21-!-Dr_Jekyll [] has quit [Ping timeout: 480 seconds]
11:21<@Rubidium>vvv444: what's the difference between IsRailDepot(t) vs IsRailDepotTile(t) ? That's not something that's obvious from the name
11:22<vvv444>Wait a sec, I'll read both and try proposing how I would code it.
11:24<vvv444>Found on the way: trunk/rail_map.h:172 unmaintaned comment ;)
11:26<CIA-5>OpenTTD: frosch * r14531 /trunk/src/network/network_gui.cpp: -Fix (r12425): OSK accessed wrong widgets of password query window.
11:26<frosch123>looks more like copy&paste than unmaintained
11:26<@Rubidium>nothing's wrong with that comment
11:27-!-mortal` [] has joined #openttd
11:27<@Rubidium>it's only that the precondition isn't enforced, but that's why it's a precondition
11:29<vvv444>oh, ic, sorry
11:33-!-Mortal [] has quit [Ping timeout: 480 seconds]
11:40-!-grumbel [] has quit [Quit: Client exiting]
11:40-!-mortal`` [] has joined #openttd
11:43-!-Burty [burty@] has joined #openttd
11:43<Burty>hey everyone
11:46<vvv444>Rubidium: Well, you are quite right about case of these two functions. Although I could propose something like: IsTileARailDepot(t) and IsRailTileADepot(t).
11:47<vvv444>[The idea emphasizing in the name function that you already know that a tile is a rail time]
11:47-!-mortal` [] has quit [Ping timeout: 480 seconds]
11:48-!-mortal` [] has joined #openttd
11:48-!-mortal` is now known as mortal
11:49<vvv444>Rubidium: Although I can try thinking about a C++ design that will solve such kind of ambiguity.
11:50*Rubidium wonders why everyone wants to make everything object oriented...
11:50<vvv444>I'm talking about ways that won't hurt performance nor memory consumtion.
11:51<+glx>if you really want to use objects, you can try to do it for GUIs :)
11:51<Alberth>vvv444: current design is opimized for speed, so you have many special cases since at various points you have slightly different information
11:51<Alberth>glx: I am doing that already, see #FS1905, it just needs review comments from devs :)
11:51<vvv444>I perfectly understand that.
11:51<@Rubidium>making objects from the map array at least doubles the size of the map array (on 64 bits)
11:52<@Rubidium>why no?
11:52<vvv444>Look you don't have to allocate the object
11:52<@Rubidium>then what?
11:52<vvv444>Just a sec, my english is slow :)
11:53-!-mortal`` [] has quit [Ping timeout: 480 seconds]
11:54<@Rubidium>then I'll read it a lot later tonight
11:54*Rubidium is gone
11:54<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.
11:55<Alberth>vvv444: the problem as far as I can see is that you cannot have an array of differently derived objects
11:56<vvv444>I didn't say it will replace map. Only said using these as indexers.
11:56<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.
11:56<frosch123>I guess that would create quite a mess, as you would need to use multiple inheritance resp. interfaces and such
11:57-!-lobstar [~michielbi@] has joined #openttd
11:57<frosch123>i.e. there are a lot of map accessors which can access quite different tiletypes, but not all subtypes of every tiletype
11:58<vvv444>Then MapTile::IsRailDepot() would correspond to current IsRailDepotTile() and RailTile::IsDepot() corrsponds to current IsRailDepot().
11:59<frosch123>IsRailDepotTile() would be more like a dynamic cast, with checking
11:59-!-Kommer is now known as Guest283
11:59-!-Kommer_ [] has joined #openttd
11:59-!-Kommer_ is now known as Kommer
11:59-!-Kommer_ is "(unknown)" on (unknown)
11:59<frosch123>don't know the c++ syntax for that
11:59<vvv444>"but not all subtypes of every tiletype " <-- What do you mean?
11:59<frosch123>but take a look at GetTownByTile, or GetTileOwner, or GetRailTypes
11:59<+glx>map accesses need to be as fast as possible as they are used for everything
12:00<frosch123>GetRoadOwner is also funny
12:00<Alberth>frosch123: dynamic_cast<T*>(ptr)
12:01-!-Guest283 [] has quit [Ping timeout: 480 seconds]
12:01<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.
12:01<frosch123>Alberth: I guess I meant typeof, when that exists
12:01-!-lobster_MB [~michielbr@] has quit [Ping timeout: 480 seconds]
12:02<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
12:02-!-lobster [~michielbi@] has quit [Ping timeout: 480 seconds]
12:02<Alberth>frosch123: if (dynamic_cast<T*>(ptr) != NULL)
12:02<frosch123>vvv444: despite of speed issues, take a look at GetRoadOwner and tell me which class to assign it to
12:02<frosch123>then do the same for GetTileOwner()
12:03<frosch123>Alberth: ok, I would have expected that to cause an exception :)
12:03<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.
12:05*vvv444 coding an example peice of code
12:05<frosch123>start with GetRoadOwner and GetTileOwner
12:06<Alberth>vvv444: eg GetTileSlope() in tile_map.cpp uses addition to encode slope bit-fields
12:06<planetmaker>frosch123: can you explain me the new station radius you submitted today?
12:07<frosch123>planetmaker: cargo will be delivered to the nearest industrytile wrt. the station sign
12:07<planetmaker>not to any other anymore?
12:09<planetmaker>hm... reading source.
12:09<planetmaker>Assuming I have two saw mills within the catchment area...
12:09<planetmaker>will that have an advantage?
12:11<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)
12:11-!-Alberth [] has left #openttd []
12:12<planetmaker>yeah, as before :). Read industry instead of industries :). But not to industries outside. Nice :)
12:14-!-sierra1024 [] has joined #openttd
12:14<sierra1024>good evening gentlemen
12:14<frosch123>yup, as before :)
12:15<planetmaker>Today seems to be a day for awesome commits :)
12:15<sierra1024>planetmaker, what so awesome has been commited ?
12:15<yorick>it seems to be a day for awesome commits to be made ;)
12:17<sierra1024>to me it looks like night
12:20-!-mortal` [] has joined #openttd
12:24<vvv444>glx: Btw, what about the GUI branch you mentioned? I read at the wiki that it was started once several years ago...
12:25<+glx>vvv444: this branch is dead :)
12:25<+glx>currently windows are objects
12:25<+glx>but widgets still are not
12:26<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.
12:27-!-mortal [] has quit [Ping timeout: 480 seconds]
12:29<vvv444>glx: Maybe if so the branch should be deleted to prevent misleading newbies like myself? ;)
12:29<dih>newbies dont look at the svn repo
12:30<Zuu>And if you do you can probably see the last modified date in it?
12:30-!-mortal`` [] has joined #openttd
12:30<yorick>Zuu: nope
12:31<+glx>yorick: on vcs it is
12:32-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has quit [Read error: Connection reset by peer]
12:33<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 :)
12:34<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
12:35-!-Doorslammer [] has quit [Quit: I'll get you next episode, Inspector Gadget! NEXT EPISODE!]
12:35<dih>vvv444 not every openttd newbie starts digging the repo, + not every openttd newbie is a svn newbie :-P
12:36<dih>and a wannabie self-compiler
12:36-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has joined #openttd
12:36-!-Burty [burty@] has quit []
12:37-!-mortal` [] has quit [Ping timeout: 480 seconds]
12:37<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?
12:37<frosch123>no, most ottd newbies are more like I-get-an-error-message-but-do-not-want-to-follow-its-directions
12:38*Zuu looks on his "r14527MM" revision string and smiles
12:38<frosch123>OO gui would have to redo your patch anyway, so I would leave trunk as it is currently
12:39<+glx>Zuu: msvc?
12:39<Zuu>frosch123: Which patch are you refering to?
12:39<Zuu>glx: Yep
12:39*glx broke something it seems
12:40<frosch123> QueryStringBaseWindow *qs = dynamic_cast<QueryStringBaseWindow *>(w); if (qs != NULL) qs->OnOpenOSKWindow(widget);
12:41<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.
12:41<+glx>hmm I get r14531M
12:42<+glx>tortoise ?
12:42<Zuu>glx: Can be me, mixed something up. it is first time I'm using hg queues.
12:42<Zuu>Yes, tortoise svn.
12:42<+glx>it's me :)
12:44*frosch123 got an idea
12:45-!-mortal` [] has joined #openttd
12:45<CIA-5>OpenTTD: glx * r14532 /trunk/projects/determineversion.vbs: -Fix (r14522): one 'M' is enough to show modified version
12:45<+glx>Zuu: fixed :)
12:45<Zuu>Nice :)
12:46*Zuu is excited and waits for frosch123's idea (correct placement of ' ?)
12:48<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.
12:49<frosch123>btw. you should compare it with your patch for future coding style hints :)
12:49<Zuu>Ok, a diff of diffs perhaps :)
12:50<frosch123>but one that does not suppress whitespace changes :p
12:51<Zuu>So you've basically moved OnOpenOSKWindow to Window base class? + other coding style stuff?
12:51-!-stillunknown [] has joined #openttd
12:51<frosch123>IIRC yes
12:51<frosch123>and some dead code
12:51-!-mortal`` [] has quit [Ping timeout: 480 seconds]
12:55-!-yorick [] has quit [Quit: Poef!]
12:55-!-ecke [~ecke@] has quit [Read error: Connection reset by peer]
12:55-!-ecke [~ecke@] has joined #openttd
12:57-!-Reemo [] has quit [Quit: - das Wiki rund um's Thema Lager und Logistik]
12:59<frosch123>Zuu: however, it does not really simplify stuff, it just moves handling of editbox clicks from OnClick() to OnShowOSKWindow()
12:59-!-Sacro [~ben@adsl-87-102-39-137.karoo.KCOM.COM] has quit [Ping timeout: 480 seconds]
12:59<frosch123>there are only one or two windows which can use the inherited method of QueryStringWindow
13:00<Zuu>"unified" might be a to strong word I can agree
13:04<frosch123>so is the only difference that your focus patch calls OnShowOSKWindow() only when the window is focusses, while OnClick() is always called?
13:04<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.
13:04-!-Bjarni [] has joined #openttd
13:04-!-mode/#openttd [+o Bjarni] by ChanServ
13:05<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.
13:05<Zuu>So a user can give focus to an edit box without showing the OSK.
13:06<Zuu>An alternative solution to this is to add an extra parameter to OnClick that tells if widget focus just changed.
13:06<Zuu>But that means changing *many* OnClick functions which would yeild a bigger patch.
13:06<frosch123>what does OnClick do for not-focussed widgets/windows?
13:07<frosch123>i.e. are the windows which do not need focussing?
13:09<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)
13:09<Zuu>when they are clicked on*
13:09<frosch123>what about buttons, and dragging in depot and such...
13:09<frosch123>and what about moving the OSK to OnDoubleClick
13:10<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.
13:11<Zuu>I'm a tablet user and double clicking with that within the time frame is significantly harder than with a mouse/trackball.
13:11<Zuu>buttons, draging etc. are not affected by focus-patch, or what are you aiming at?
13:12<frosch123>you could also move the focus after calling OnClick, so you can use IsFocussed in OnClick
13:13<Zuu>Hm, that's also a good idea.
13:13-!-Burty [burty@] has joined #openttd
13:13<Zuu>Or better use IsFocused in ShowOnScreenKeyboard function to reduce amount of code duplication.
13:14<frosch123>don't know though, which implications that would have though ...
13:14<Burty>how can i fix "Error 1 error C2220: warning treated as error - no 'object' file generated" ?? no other erros just that
13:14<frosch123>i.e. when to change focus is a very fundamental decision
13:14<+glx>you are not using clean trunk
13:15<Burty>so i just need to get a clean checkout?
13:15<Zuu>frosch123: sure, depends on what you want to achive with focus. Currently it is only used to do text-input-focus.
13:15<+glx>Burty: what version are you trying to compile?
13:16<Burty>dont laugh but 9865 because there is a patch im seeing if i can somehow bring up to nearer the new versions
13:17<+glx>good luck as there are at least 2 patch breaking commits after that
13:17<+glx>(file rename/move)
13:17<Burty>one of which is players.cpp
13:17-!-ecke [~ecke@] has quit [Read error: Connection reset by peer]
13:19<+glx>hmm I though it was pre c++ but it's not
13:19<frosch123>Zuu: anyway, using an IsFocussed in OnClick seems to match future handling of the OSK in some EditBox::OnClick
13:19-!-ecke [~ecke@] has joined #openttd
13:20<Burty>glx: well when i hit thost breakers i will root about and find out how to deal with it :D, thanks
13:20-!-lobstar is now known as lobster
13:20<+glx>usually it's: diff, update, edit diff to new filename, patch
13:20-!-ecke [~ecke@] has quit []
13:21<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.
13:25<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
13:25<Zuu>inng of the Dispatch...-function.
13:27<Zuu>There is 6 return-statement between where focus is set currently and the end of function. :-)
13:30<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.
13:31<+glx>if there were "real" widgets, focus stuff would be easier
13:32<frosch123>changing the focus after OnClick sounds better than an extra argument
13:33-!-ecke [~ecke@] has joined #openttd
13:33-!-lobster_MB [~michielbr@] has joined #openttd
13:34<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?
13:34<Zuu>Also window->OnFocus() will be called after OnClick() with that approach.
13:35<frosch123>I'm not sure whether each of those 6 would actually cause focussing
13:35<frosch123>at least the close would not :p
13:35<+glx> <-- I did it like that in another project
13:36<+glx>but it's not possible to do the same in openttd
13:38<frosch123>that seems to set the focus before some widget specific stuff (i.e. OnClick)
13:38<Zuu>frosch123: Yea, maybe you are right, that causing focus lost on another window just bacuse you close another may be unneccesary.
13:38<+glx>and rev 1379 for the focus check
13:41-!-Mortal [] has joined #openttd
13:43-!-Sacro [~ben@adsl-87-102-39-137.karoo.KCOM.COM] has joined #openttd
13:44<+glx>Zuu: maybe you could provide a patch for just HandleEditBoxKey() result handling (removal of "magic" values)
13:44-!-mortal`` [] has joined #openttd
13:44-!-mortal` [] has quit [Ping timeout: 480 seconds]
13:45<Zuu>glx: That is doable, if that can get merged relatively soon that would simplify for all I guess.
13:47<+glx>yes trunk will be easier to read, and your patch will be smaller :)
13:48<+glx>as some changes in it are just that
13:49<Zuu>Hmm, need more diskspace hehe, have only 100 MB left on C: :D
13:49<+glx>windows doesn't like that
13:49-!-Mortal [] has quit [Ping timeout: 480 seconds]
13:51<Zuu>Well I have 2.5 GB of OpenTTD checkouts/compiles that could be moved to another partion.
13:52-!-mortal`` [] has quit [Ping timeout: 480 seconds]
13:53-!-Mortal [] has joined #openttd
13:54<+glx>8.5GB and still counting ;)
13:54<Zuu>Have 7,5 GB free on another partion, so moving there seams like a good idea. :)
13:55<+glx>ok 12.2GB
13:56<+glx>but that includes all tags since 0.5.2 and most branches are duplicated
13:57-!-mortal` [] has joined #openttd
13:58<+glx>trunk is just 702MB (with debug and release builds for mingw and msvc)
14:02-!-yorick [] has joined #openttd
14:02-!-Mortal [] has quit [Ping timeout: 480 seconds]
14:05-!-Burty [burty@] has quit []
14:05-!-Mortal [] has joined #openttd
14:05-!-mortal` [] has quit [Ping timeout: 480 seconds]
14:14-!-mortal` [] has joined #openttd
14:15-!-Mortal [] has quit [Ping timeout: 480 seconds]
14:18<Eddi|zuHause>wtf? do ads in the forum now have sound?!?
14:19<frosch123>oh noes - when they become common I need some sound blocker
14:19<yorick>what ads?
14:19<@Bjarni>forums should be silent
14:20<Sacro>adblock+ ftw
14:20<Eddi|zuHause>i could have sworn i just heard a racing car
14:20<Eddi|zuHause>and it couldn't have come from anywhere else than the ad on the forum
14:22-!-mortal` [] has quit [Ping timeout: 480 seconds]
14:26<@SmatZ>yorick: that's my patch! :-P
14:27<yorick>SmatZ: nono, I just looked at it and recreated it
14:27<yorick>it just looks similar
14:27<@SmatZ>it's very same :)
14:27<yorick>and you did not commit :-p
14:27<@SmatZ>no, and it won't be commited
14:27<@SmatZ>result of devs' discussion
14:28<yorick>"doing this will remove the need of it being done correctly"
14:28<@SmatZ>yeah :)
14:29<yorick>because its like irc...a whole new protocol needs to be created just for the bots, eh?
14:32<welshdragon>SmatZ, what patch are you and yorick arguing about?
14:33<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
14:36<Ammler>devs don't like to commit something for MP anyway :P
14:39-!-Mortal [] has joined #openttd
14:50-!-mortal` [] has joined #openttd
14:51-!-sierra1024 [] has quit [Quit: Odcházím]
14:51-!-mortal`` [] has joined #openttd
14:52<+glx>[20:20:09] <Sacro> adblock+ ftw <-- I disable it on sites I want to support
14:52-!-Mortal [] has quit [Ping timeout: 480 seconds]
14:53<frosch123>I do not care about graphics, so I would support everyone. But sound is in no way acceptable.
14:54<yorick>graphics go to display:none, but if it does the CLICK ME! sound, it won't stay out of my blocklist
14:57<Sacro>glx: I don't bother, I feel that sites should pay me for the right to shove adverts down my pipe
14:58<Zuu>(removal of magic numbers)
14:58*glx checks :)
14:58<CIA-5>OpenTTD: frosch * r14533 /trunk/src/landscape.cpp: -Fix: ...hopefully most glitches wrt. inclined foundations.
14:58-!-mortal` [] has quit [Ping timeout: 480 seconds]
15:00<+glx>Zuu: hmm yes HEBR_DEFAULT looks "weird"
15:00<Zuu>good, not only me think it looks silly :)
15:01<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.
15:01<Zuu> /noly/only/
15:02<+glx>hmm yes, sounds better
15:04*vvv444 encountered "highways" in the codebase, anyone who can explain about this feature plz
15:05<+glx>non existant
15:05<vvv444>planned for feature?
15:06<Zuu>glx: uploaded a new version with HEBR_OTHER_KEY, but I've just made find replace in the patch-file.
15:07<Zuu>hmm, the comment after HEBR_OTHER_KEY needs fixing too.
15:07<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)
15:10<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.
15:13<frosch123>how about "HEBR_EDITING", "HEBR_ENTER", "HEBR_CANCEL"?
15:16<+glx>sounds good too
15:17<Zuu>I would prefere RETURN over ENTER, as the return key is more commonly used.
15:17<Zuu>but you can see both names used in trunk.
15:18*frosch123 dislikes RETURN, as it refers to multiline editing, and not to enter a value
15:19<frosch123>but CONFIRM is also fine
15:20<Zuu>Since Escape is substitude by Cancel, confirm is more in the same kind of term as cancel.
15:21<frosch123>yup, first I wanted to suggest OK, but that seemed to be too short :)
15:22<Eddi|zuHause>can i have an ANY_KEY please?
15:23<frosch123>Eddi|zuHause: the space bar has enough space to write anything on it as you like
15:23<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?
15:23<frosch123>I guess, those comments are not needed at all :)
15:24<frosch123>except they say more than CONFIRM or CANCEL :)
15:25<Zuu>I think the part about what happens can be keept. But you are the devs :-)
15:26<frosch123>tbh it does not really matter :)
15:26-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has quit [Ping timeout: 480 seconds]
15:35<Zuu> <-- 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)
15:36<Zuu>I've commented the enums what key(s) they corespond to.
15:36<+glx>it's ok for me
15:38<+glx>hmm failed to apply
15:38<Zuu>Oops, I'll check it.
15:41<Zuu>Indeed, fails here too. Probably touched a line without + or - in the patch file.
15:44<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)?
15:46<frosch123>GetRoadOwner applies also stations and bridges
15:46<frosch123>while TileOwner is invalid for roads, except it is RailOwner for level crossings
15:47<frosch123>also take at look at GetAnyRoadBits
15:48<vvv444>But do you usually know if you're dealing with road, station or bridge? Or you mean it should be polymorphic?
15:49<frosch123>it needs to be polymorphic
15:49-!-Sacro [~ben@adsl-87-102-39-137.karoo.KCOM.COM] has quit [Read error: Connection reset by peer]
15:49<frosch123>same about GetWaterClass and GetRailType
15:50<frosch123>and I am sure there is more stuff which applies similiary to different tiletypes
15:50-!-Sacro [~ben@adsl-87-102-39-137.karoo.KCOM.COM] has joined #openttd
15:51<vvv444>Ok, about GetAnyRoadBits - it's not a problem since it receives explicitly the road type, so it doesn't require polymorphism.
15:52-!-fjb_ [] has joined #openttd
15:52<frosch123>ok, GetAnyRoadBits could be a member of the root calls
15:53<vvv444>So as GetRailType, it explicitly knows the tile is rail.
15:53<Zuu>glx: Now a new version is available that applies and compiles :-)
15:53<frosch123>vvv444: no, GetRailType also applies to bridges and stations
15:53<Zuu> * I hope * - at least it does here.
15:54<frosch123>anyway I guess something is starting becoming darker in my oven :)
15:54<+glx>what are you burning?
15:54<vvv444>frosch123: Ok, actually I have to check mine too :)
15:54<vvv444>bb in 10 min
15:55*Zuu takes a slice dark bread :-)
15:56-!-fjb [] has quit [Ping timeout: 480 seconds]
15:59<CIA-5>OpenTTD: glx * r14534 /trunk/src/ (5 files in 2 dirs): -Codechange [FS#2382]: Enumify magic return values of HandleEditBox function (Zuu)
15:59<Zuu>Thanks glx
16:01*Bjarni notes that Zuu just moved a bit towards the dark side
16:02<Zuu>hehe ok
16:02<@Bjarni>I mean you are what you eat :)
16:15-!-questionmark [] has joined #openttd
16:15-!-welshdragon [~vista@adsl-83-100-138-245.karoo.KCOM.COM] has joined #openttd
16:15<NukeBuster>is viewport.h removed a while ago?
16:16<NukeBuster>and does svn give an error when a modified file is supposed to be removed+
16:16<CIA-5>OpenTTD: frosch * r14535 /trunk/src/openttd.cpp: -Fix: Description of '-i' commandline option.
16:16-!-yorick is now known as Guest302
16:16-!-questionmark is now known as yorick
16:17<frosch123>NukeBuster: IIRC it was split into viewport_func.h, viewport_type.h, tilehighlight_func.h and tilehighlight_type.h
16:18<NukeBuster>does svn give a code like C for the file or does it remain D
16:19<frosch123>IIRC svn does not delete files with local changes, but usually noone tests such behaviour without a safety copy :p
16:19<NukeBuster>yeah i had the copy
16:19-!-Nite_Owl [] has joined #openttd
16:20<NukeBuster>but i want to detect when such stuff happends to modified files
16:20<frosch123>use 'svn status'
16:20<Nite_Owl>Hello all
16:21<frosch123>NukeBuster: you can also use 'svn status -v' before an update
16:21<frosch123>it will show you what is going to happen
16:22-!-Guest302 [] has quit [Ping timeout: 480 seconds]
16:22<frosch123>well, maybe '-u' is more useful :p
16:25<NukeBuster>hmm... I'm trying to automate the updating process so I'll see what information is most useful
16:25<NukeBuster>it usually should just update unless a conflict is reached
16:25<NukeBuster>i would count a try to delete modified files as a conflict too
16:27-!-mortal`` is now known as mortal
16:28-!-welshdragon is now known as Guest305
16:28-!-yorick [] has quit [Quit: Poef!]
16:28-!-TinoM [] has quit [Quit: Verlassend]
16:30<vvv444>frosch123: - 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.
16:31<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.
16:34<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.
16:36<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.
16:36<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)
16:36<frosch123>wrt. 3) already exists, is called TileTypeProcs or similiar
16:37<frosch123>and especially the GetTileTrackStatus() is one of the most expensive functions
16:37<vvv444>I know, but it can be merged here and be more usable.
16:38-!-Guest305 is now known as welshdragon
16:40<vvv444>frosch123: I'm not sure most functions will remain global. But I'll think more about it of course. Thank you very much.
16:52-!-FloSoft [] has quit [Quit: computer has gone to sleep]
16:56<dih>saving the random seed in the config should be an optional not a enforced setting
16:57<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
17:01*Zuu hugs hg queues for not having to update the filter sign list patch with things that relate to widget focus.
17:02<planetmaker>Zuu: I gave them a try - really nice :)
17:04<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.
17:04<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?
17:04<planetmaker>just replace the patch file?
17:04<planetmaker>don't think so...
17:05<Zuu>hmm, you should wait for v 11, though.
17:05<planetmaker>:D ah, right one of todays commits...
17:05<planetmaker>how does this versioning work? I didn't figure that out, so far.
17:05<Zuu>Because v10 don't apply to trunk as a part of my work have been commited. (magic numbers -> enum)
17:06<planetmaker>yep, congratz for that :)
17:07<Zuu>Thanks. Much longer patch (167 lines) than the one-liner I got many months ago.
17:09-!-welshdragon is now known as Guest308
17:09<Zuu>Hmm, where did English (UK) go .. :/
17:09-!-Guest308 is now known as welshdra-gone
17:12<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?
17:13<Zuu>Either way I think hg should be able to unpatch what my patch have done.
17:13<planetmaker>maybe :) I didn't try so far, but I thought you would know for sure :)
17:13<planetmaker>that's feasable, yes. I could just delete it and add a new one - if worse comes to worse
17:14<Zuu>I've used this tutorial if you have not found it yet:
17:14<Aali>just pop it and replace the patch file in .hg/patches
17:14<Aali>assuming its -p1, of course
17:16<planetmaker>Zuu: yes, I've bookmarked that. It's pretty good :)
17:16-!-tokai [] has joined #openttd
17:16-!-mode/#openttd [+v tokai] by ChanServ
17:17<planetmaker>it's p0, I guess, but I could convert it to p1.
17:17<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)
17:18<Aali>i haven't even tried playing it in swedish
17:18<Aali>is it really that bad?
17:19<Zuu>Well I'm just so used to the english terms used in OpenTTD.
17:20<Zuu>Played *TTD* since around year 2000 allways in English.
17:20<Zuu>It is not that the translation is bad, it is that it is a translation.
17:21<Eddi|zuHause>i have played TT in german since the first release
17:21<Eddi|zuHause>the demo was in english, i think. but i didn't know english very well back then
17:22-!-NukeBuster [~wouter@] has left #openttd []
17:24-!-Nightraven [] has joined #openttd
17:30-!-NukeBuster [~NukeBuste@] has joined #openttd
17:47<Zuu>planetmaker: I've uploaded version 11 of my filter sign list patch now, incase you want to upgrade your queues. :-)
17:49<Aali>Zuu: where in sweden do you live?
17:49<Aali>if you dont mind me asking
17:49<Zuu>And you?
17:49<planetmaker>Zuu: thanks. Indeed I want that :)
17:50*TrueBrain waves hello
17:50*Zuu waves back on TrueBrain
17:50*planetmaker waves a hello @ TB
17:50<TrueBrain>how are you all doing my friends?
17:51<@Rubidium>pretty good ;)
17:52<@Rubidium>though /me feels tomorrow will be a long day ;)
17:52<TrueBrain>Rather tonight :)
17:57<TrueBrain>hmmm .. we all hear gunshots outside
17:58<TrueBrain>is that a good thing? :s
17:58<@Bjarni>TrueBrain: I'm doing ok
17:58<TrueBrain>('we' as in my roommates and I)
17:58<@Bjarni>but I could be better :s
17:59<@Bjarni>the news today talked about gunshots... somebody's house was hit by bullets (broken window and stuff) and they called the police
17:59<@Bjarni>the police decided to ignore it so they contacted the media o_O
17:59-!-scarabeus [~quassel@] has joined #openttd
18:00<TrueBrain>deep silence now ... well, if the police arrives in a few, we know for sure it was gunshots :p
18:00<TrueBrain>Digitalfox: good news, I finally ordered my iPhone :) Takes 10 more days ...
18:01<scarabeus>TrueBrain: exactly guy i need
18:01<CIA-5>OpenTTD: frosch * r14536 /trunk/src/economy.cpp: -Fix (r14530): Do not expect uints to become negative.
18:01<scarabeus>ok are you still interested in that proxy?
18:01<+glx>nice one frosch123
18:01<TrueBrain>scarabeus: I worked 10 hours today, so all I can think is: huh? :p
18:01<scarabeus>gentoo ebuild maintainer you
18:01<scarabeus>i just upload to gentoo
18:01<TrueBrain>yeah, please :)
18:02<TrueBrain>if that makes release-ebuilds go in quicker ;)
18:02<scarabeus>i need some nice mail i guess it will be but i want it confirmed
18:02<TrueBrain>yup :)
18:02<planetmaker>Zuu: where did you upload it? I cannot find it...
18:03<Zuu>It's not on FS.
18:03<planetmaker>hm... and why did you rename it?
18:03<+glx>scarabeus: very nice to write an email address on IRC
18:03<Zuu>Um, ow, uploaded wrong patch.. :)
18:03<planetmaker>I was of the impression that it is only part of the patch...
18:03<scarabeus>oh right sorry
18:03<scarabeus>i am bit tired i should go sleep :(
18:04<+glx>next time use decorations for it ;)
18:04<scarabeus>TrueBrain: will you be there tomorow lets say 12:00 UTC?
18:04<TrueBrain>scarabeus: depends .. if I can get up that early :p
18:04<Zuu>planetmaker: try again, now you should find the patch a litle bit easier :-)
18:04<TrueBrain>but most likely :)
18:04<TrueBrain>tonight we switch to CET .. so +0100 .. hmm .. yeah :p
18:04<planetmaker>he, thx, Zuu :)
18:04<Zuu>TrueBrain: Thanks for reminding, had forgot that.. :)
18:04<TrueBrain>scarabeus: btw, why did the ebuild in portage switch to EAPI 2? (what is wrong with EAPI 1? :p)
18:04<Zuu>We get one hour extra?
18:05<Zuu>Who :-)
18:05<scarabeus>we just want it tested, nah kidding it allows use dependencies
18:05<planetmaker>all :P
18:05<TrueBrain>anyway, me is going to bed .. talk to you tomorrow scarabeus :)
18:05<TrueBrain>night all!
18:06<+glx>night TrueBrain
18:06<Zuu>Good night TrueBrain
18:06<scarabeus>i am outta here too and going to bed so see ya tomorow
18:06<planetmaker>g'night from here, too
18:06*planetmaker waves
18:06<Nite_Owl>Later TrueBrain
18:06-!-scarabeus [~quassel@] has quit [Remote host closed the connection]
18:06-!-rubyruy [] has joined #openttd
18:08-!-Aali_ [] has joined #openttd
18:08<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 :)
18:08<rubyruy>oh and also given a particular good of course
18:08<rubyruy>is such thing already out there somewhere? probably a scary spreadsheet?
18:09<frosch123>I saw something like that on the forums
18:09*Rubidium seems to remember that the optimal distance was as far as possible
18:09<frosch123>no idea whether it was correct though
18:09<Zuu>frosch123: I remember it too
18:09<Zuu>In General OpenTTD forum. up to one month ago.
18:10-!-Aali [] has quit [Ping timeout: 480 seconds]
18:10-!-Aali_ is now known as Aali
18:10<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
18:11<rubyruy>but there's so much other crap to take into account for a proper model...
18:11<Zuu>and then you load a grf and you have re-do everything.
18:11<rubyruy>well just have to plug in the new values
18:11<rubyruy>hmm maybe somebody working on AI already went through this as well
18:12<@Rubidium>and then you find out the newgrf uses variable running costs...
18:12<@Rubidium>variable as in: when accelerating/climbing costing more than when driving at a constant speed
18:13<rubyruy>i'm sure you could average it out
18:14<rubyruy>i mean even without variable maint costs, slopes would affect delivery speed anyway
18:14-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:15<rubyruy>do you guys remember anything about the title ? the general theme?
18:15<rubyruy>i noticed there's a fair bit of mismatch between a thread's title and what it actually ends up being about ;)
18:18<frosch123>there is at least another topic (using those keywords) with a weird table with magic values
18:18-!-welshdra-gone is now known as welshdragon2
18:19-!-Nite_Owl [] has quit [Quit: Read You Soon]
18:19<rubyruy>ahh nice
18:25<rubyruy>aww there is a patch to show this in game but it's fallen into neglect :(
18:30<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
18:31<rubyruy>but if money is actually an issue (early on) then optimizing per train is preferable, and shorter runs are better
18:32<+glx>well not too short
18:33-!-frosch123 [] has quit [Remote host closed the connection]
18:33-!-Brianetta [] has joined #openttd
18:33<+glx>else running costs are higher than income
18:33<Zuu>train length is also a parameter of importance esp. in the beginging.
18:34<+glx>and engine power
18:34<rubyruy>yeah i noticed that actually.... steam engine + 10 coal cars == !success :(
18:34<rubyruy>optimal engine size would be another interesting thing to look at
18:35*rubyruy is there a good openttd strategy site? most of the high profile resources are dev/modding
18:35<rubyruy>bah - wrong key
18:35<rubyruy>... are more dev/modding oriented
18:37-!-Progman [] has quit [Remote host closed the connection]
18:47-!-Nightraven [] has quit [Quit: Verlassend]
18:50-!-Aali_ [] has joined #openttd
18:51-!-helb [~helb@] has quit [Ping timeout: 480 seconds]
18:52-!-Aali [] has quit [Ping timeout: 480 seconds]
18:53<Zuu>Night all
18:53-!-Zuu [] has quit [Quit: Leaving]
18:54-!-helb [~helb@] has joined #openttd
18:56-!-vvv444 [] has quit []
18:59-!-KritiK [] has quit [Quit: Leaving]
19:05-!-Vikthor [] has quit [Remote host closed the connection]
19:09<Eddi|zuHause>i hate the time switch... it always screws up any recordings that i plan during that night...
19:11-!-HerzogDeXtEr [~Flex@] has quit [Quit: Leaving.]
19:12-!-HerzogDeXtEr [~Flex@] has joined #openttd
19:21-!-rortom [] has joined #openttd
19:26-!-rortom [] has quit [Quit: Leaving]
19:29-!-tokai [] has quit [Ping timeout: 480 seconds]
19:31-!-tokai [] has joined #openttd
19:31-!-mode/#openttd [+v tokai] by ChanServ
19:37-!-mikl [] has joined #openttd
19:40<dih>[06:49] <dih> perhaps you devs should have a get2gether and see if you all are supporting the same idea
19:40<dih>[06:49] <dih> it's kinda not so helpful if 3 devs say x and 2 say y
19:41<dih>petern, and Rubidium, i had misunderstood things you guys had said separately
19:41-!-mortal [] has quit [Quit: [FATAL] Client error: Memory leak - More RAM needed. More! More! More!]
19:41<dih>and made a pretty much out-of-place statement
19:42<dih>i'll try to understand what you guys say rather than assuming things
19:42<dih>sorry for the annoyance
19:56-!-Roujin [] has quit [Quit: Lost terminal]
19:57-!-helb [~helb@] has quit [Ping timeout: 480 seconds]
20:19-!-welshdragon2 is now known as welshdragon
20:34-!-Eddi|zuHause [] has quit []
20:34-!-Eddi|zuHause [] has joined #openttd
20:37-!-Dred_furst [] has quit [Quit: Leaving]
20:37-!-Dred_furst [] has joined #openttd
20:39-!-ben_goodger [] has joined #openttd
20:43-!-Bjarni [] has quit [Quit: Leaving]
20:44-!-Dred_furst [] has quit [Quit: Leaving]
20:53-!-Fuco [] has quit [Quit: Quit]
20:56-!-roboboy [] has quit [Quit: ajax IRC Client]
21:07-!-DJNekkid [] has joined #openttd
21:08-!-valhalla1w [] has quit [Ping timeout: 480 seconds]
21:08-!-DJNekkid [] has left #openttd []
21:08-!-DJNekkid [] has joined #openttd
21:08-!-DJNekkid [] has quit []
21:09-!-DJNekkid [] has joined #openttd
21:12-!-Aali_ is now known as Aali
21:30-!-stillunknown [] has quit [Ping timeout: 480 seconds]
21:38-!-ecke [~ecke@] has quit [Quit: ecke]
21:57-!-Dred_furst [] has joined #openttd
22:01-!-valhallasw [] has joined #openttd
22:01-!-Gekz [] has quit [Ping timeout: 480 seconds]
22:01-!-Brianetta [] has quit [Quit: Tschüß]
22:04-!-HerzogDeXtEr [~Flex@] has quit [Read error: Connection reset by peer]
22:18-!-glx [] has quit [Quit: bye]
22:26-!-NukeBuster [~NukeBuste@] has quit [Quit:]
22:44-!-Gekz [] has joined #openttd
22:44-!-Gekz [] has left #openttd []
22:44-!-Gekz [] has joined #openttd
23:03-!-elmex_ [] has joined #openttd
23:08-!-elmex [] has quit [Ping timeout: 480 seconds]
23:08-!-elmex_ is now known as elmex
23:10-!-Wezz6400 [] has quit [Quit: Caught sigterm, terminating...]
23:42-!-Yeggstry is now known as Yeggzzz
---Logclosed Sun Oct 26 00:00:58 2008