Back to Home / #openttd / 2011 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2011-08-19

---Logopened Fri Aug 19 00:00:35 2011
00:13-!-mattt_ [] has joined #openttd
00:16-!-lessthanthree [] has quit [Read error: Connection reset by peer]
00:17<@planetmaker>pjpe: track speed limits are taken into account such that too low speed limits are penalized
00:19<pjpe>are there any plans to just include speed limit signals in trunk?
00:19<pjpe>it seems like a rather simple inclusion
00:19<pjpe>and people have been doing patches for it for years
00:20<@planetmaker>though interestingly I don't see a related yapf setting...
00:21<@planetmaker>I know of no such immediat plans to include speed signals
00:21<@planetmaker>I'm not sure about easy either ;-)
00:22<pjpe>it seemed like 70% of the one i was looking at was making it buildable and guis and such
00:23<pjpe>and then a short section for adding cost to the path if it encounters the signal
00:28<@planetmaker>ah... there it is, only within signal look-ahead distance: extra_cost += YAPF_TILE_LENGTH * (max_veh_speed - max_speed) * (4 + tf->m_tiles_skipped) / max_veh_speed;
00:41-!-jpx_ [] has joined #openttd
00:53-!-jpx_ [] has quit [Ping timeout: 480 seconds]
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:15-!-mattt_ [] has quit [Quit: mattt_]
01:49<KittenKoder>Houston, we have a problem.
01:52<KittenKoder>I used the 9-8 template from OGFX, though the engine doesn't fill the sprite area it hangs over a few pixels in game .... then engine is 33 pixels tip to tip, the template from OGFX is 36 pixels.
01:54<@planetmaker>and the problem is...?
01:54<KittenKoder>So it's not a problem?
01:54<@planetmaker>the only judge is how it looks ingame
01:54<KittenKoder>It's okay if the sprites hang out a couple pixels in the information screen?
01:55<KittenKoder>Everywhere else it looks great. LOL
01:55<@planetmaker>well, up to you :-)
01:55<@planetmaker>make special purchase list sprites or purchase list alignment, if you like
01:55<KittenKoder>Not on the purchase list, that's fine to, it's the information dialog with the train itself.
01:55<KittenKoder>The details.
01:59-!-ptr [] has joined #openttd
02:01-!-Biolunar [] has joined #openttd
02:05<@planetmaker>well... if you use 9/8 the train has to be longer than the game was designed for
02:06<KittenKoder>I know there are 9/8 trains in other sets .... just never noticed any such effect in that dialog.
02:06<KittenKoder>Perhaps I'm just being too critical of mine.
02:16-!-Br33z4hSlut5 [] has joined #openttd
02:17<@planetmaker>the game engine can only deal with 8/8 at most. Everything longer is... stretching the boundaries
02:17-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
02:19<KittenKoder>Well, it's only a few pixels, literally, not a few wide, just a few pixels on the pointed tip.
02:19<KittenKoder>^_^ I like pointy trains.
02:20<KittenKoder>But if it's not something that's a huge matter then I'll just ignore it for something like a few pixels.
02:21<KittenKoder>It gets cropped by the depot dialog, looks a bit odd but not horrible, I was just worried that it would be a huge deal if it happened.
02:36-!-Cybertinus [] has joined #openttd
02:40-!-Biolunar [] has quit [Ping timeout: 480 seconds]
02:51-!-DayDreamer [~DayDreame@] has joined #openttd
02:55-!-andythenorth [] has joined #openttd
02:58-!-LordAro [] has joined #openttd
03:03*andythenorth has lost eddi's algorithm for handling FIRS supplies
03:03<andythenorth>it was 80% convincing
03:09<pjpe>this p1sim looks really cool
03:09<pjpe>too bad it will never be in a form people will want to really play
03:14<@planetmaker>andythenorth: re supplies. You seem to bring it up again and again it seems to remove them or more generally to throw over the whole ecnomy concept of FIRS. I'm not sure that's a sane approach
03:15<@planetmaker>I was honestly kinda taken aback a bit when I saw that discussion (again) yesterday
03:18<andythenorth>well...the decision remains open ;)
03:19<andythenorth>it's not a 0.7 decision
03:19<@planetmaker>as well one can decide to drive with 100km/h into a tree
03:19<andythenorth>but it might need to be a change in 0.8
03:19<andythenorth>supplies are currently flawed
03:19<@planetmaker>I feer much so that without supplies I'll loose interest
03:20<andythenorth>but I think the solution is likely a change of algorithm, as per v and eddi suggestions
03:20<@planetmaker>as without supplies it's just default industries. Nothing new or different anymore
03:20<@planetmaker>no challange
03:21<andythenorth>maybe I should branch, remove them, and play a test game
03:21<@planetmaker>just tell me: what would be different to default industries then?
03:21-!-Juo [~Juo@] has joined #openttd
03:21<andythenorth>more cargos, more industries
03:21<@planetmaker>except some graphics and cargo names?
03:22<andythenorth>less code to maintain - all of the primary behaviour would be provided by openttd
03:22<@planetmaker>so... what 2ccTS is for trains FIRS would be for industries
03:22<andythenorth>removing them is not something I want to do
03:22<andythenorth>but it might be the right thing
03:22<andythenorth>like when you have your teeth drilled
03:23<@planetmaker>Well, it's not the right thing
03:23<@planetmaker>They make sense both economically and game-play wise IMHO
03:23<andythenorth>I think they deserve one more round of trying to improve the algorithm
03:23<andythenorth>before throwing the baby out with the bath water
03:23<@planetmaker>what's wrong about the current one?
03:24<andythenorth>it's unsatisfying
03:24<@planetmaker>I really fail to see it as failure
03:24<andythenorth>people find it weird
03:24<@planetmaker>do they?
03:24-!-ptr [] has quit [Quit: Zzzzzz]
03:24<@planetmaker>it's something they don't know
03:24<KittenKoder>I like the 2ccTS.
03:24<@planetmaker>so they cry for what they know which is the same scheme as default industries
03:25<KittenKoder>Default industries are boring.
03:25<andythenorth>planetmaker: we could introduce different behaviour switching via parameter :P
03:25<andythenorth>that would be fun to maintain
03:26<andythenorth>already there is part of that :P
03:26<KittenKoder>I have not seen any problems with 2ccTS and FIRS mixed, though I hate the NARS set .... after 1970.
03:27<@planetmaker>ach... I'll stop arguing. It should be obvious that supplies are THE unique selling point
03:27<KittenKoder>I like the round chains, it adds something that makes the game more fun.
03:27<andythenorth>I think there's nothing new to say that hasn't been
03:27<andythenorth>let's leave it until (a) we've tried a different algorithm
03:28<andythenorth>and (b) it's clear what's happening with YACD
03:28<@planetmaker>but I'll grumble. Because if we now cut it down to "we just provide some new graphics and do nothing else" I feel my work on conversion to NML somewhat wasted
03:28<@planetmaker>c) ignore yacd. It's not there yet
03:28<andythenorth>b == c in my brain
03:29<andythenorth>there's no point changing the FIRS behaviour against an unknown YACD target
03:29<@planetmaker>yes, thus do not judge supplies by how you use them in yacd games
03:29<andythenorth>planetmaker: FORK! :D
03:29<@planetmaker>I'd most probably not do that
03:30<@planetmaker>I'd keep playing what I have and ignore newer versions
03:30<KittenKoder>Oooh ... will there be more complexity to FIRS soon?
03:30<andythenorth>define complexity?
03:31<KittenKoder>Anything. :p
03:31<@planetmaker>similar to how on our servers seldom new versions of 2ccTS are used. The new ones just have too many pointless vehicles
03:31<KittenKoder>Speaking of which, I need to get the latest 2ccTS.
03:31*andythenorth wonders why ENSP isn't machinery already
03:32<andythenorth>there's no gameplay reason
03:32<@planetmaker>oh, there is
03:32<@planetmaker>"engineering supplies" is a clear indicator of "this helps machinery work"
03:32<andythenorth>it would come to the same if reduced analytically? Deliver "stuff" for production increase
03:32<@planetmaker>like lubricants, screws, parts, engineers
03:32<andythenorth>'machinery' or 'engineering supplies' are just labels?
03:33<@planetmaker>for different boxes
03:33<@planetmaker>I really like there being three "... supply" cargos. It's clear. Immediately.
03:33<@planetmaker>I don't have to read anything. I just know: ship it to improve
03:34<@planetmaker>and that is conceptionally a _very_ good point
03:34<andythenorth>so every time we poke at ENSP, it holds up ok
03:34<@planetmaker>it's one of the points IMHO where ECS vectors come short: it has similar cargos. But it's totally not obvious
03:34<andythenorth>more clearly defined though
03:35<@planetmaker>the ENSP? Yes, they are more clearly defined
03:35<andythenorth>no ECS is more clearly defined
03:35<@planetmaker>is it?
03:35<KittenKoder>Aha! I finally figured out the whole acceleration stuffs .... enough to make trains anyway.
03:35<andythenorth>machinery etc
03:35<@planetmaker>so? you want to make ecs2?
03:36<KittenKoder>I never liked ECS.
03:36<andythenorth>I want to not make something that confuses people
03:36<@planetmaker>ecs is great actually
03:36<@planetmaker>andythenorth: and exactly that's the strong point of ??SP cargos: they create clarity
03:36<andythenorth>although tbh my iphone confuses me, and everybody loves those
03:36<KittenKoder>1. mines closing even when supplied .... in a game where 1 year actually is 1 year would be fine but something like TTD .... blech.
03:36-!-Juo [~Juo@] has quit [Quit: Juo]
03:37<@planetmaker>they might be a bit fuzzy wrt what they constitute specifically in RL - but that's unimportant. And also an advantage
03:37<@planetmaker>one can ship many great cargo sprites
03:37<andythenorth>the iphone is a strange thing - but that's a whole other story :P
03:37<KittenKoder>2. ECS doesn't work for me anymore for some reason, I can only get one subset at a time, can't enable all the GRFs for it at once.
03:38<@planetmaker>e.g. replacing FMSP by fertilizer is the worst of the choices... and makes it boring, cuts imagination etc
03:38<andythenorth>might be worth kicking at FMSP in other ways though
03:38<andythenorth>I've yet to play a game where FMSP are really working
03:38<andythenorth>but this might be related to production code, not the cargo
03:38<@planetmaker>Well, I still like V's suggestion on how to treat primary boost via supplies
03:39<andythenorth>yeah - so changing the algorithm might be the next step in the design process
03:39<@planetmaker>Thus higher output levels require coninued and higher supply input
03:39<andythenorth>FMSP suffer a different issue
03:39<@planetmaker>with non-rigerous consideration
03:39<@planetmaker>of lower and upper boundaries
03:39<@planetmaker>what does it suffer?
03:39<andythenorth>2 issues
03:40<andythenorth>(1) it's often a PITA to build routes to farms
03:40<andythenorth>with 2 outputs and 1 input, three road stops are needed
03:40<andythenorth>and there has to be enough road to handle blocking while loading
03:40<andythenorth>so it can be boring to build those kind of routes (and looks bad)
03:41<andythenorth>a farm ends up surrounded by concrete
03:41<andythenorth>(2) farms are very low production, so the amount of cargo out is not worth the trouble
03:41<andythenorth>hu at (2)?
03:41<andythenorth>or (1)?
03:41-!-Belugas [~belugas@] has quit [Ping timeout: 480 seconds]
03:42<@planetmaker>mostly 1 - though 2 can be considered a challange, too. And 3 road stops for low output is no issue, too
03:43-!-DDR [] has quit [Quit: In democracy it's your vote that counts; In feudalism it's your count that votes. - Mogens Jallberg]
03:43-!-nicfer [~Administr@] has quit [Read error: Connection reset by peer]
03:43<andythenorth>1 is made worse because it amuses me to allow farms on very steep slopes :P
03:44-!-Muxy [~Muxy@] has joined #openttd
03:44<andythenorth>if a player uses a flat map it won't be an issue
03:44<KittenKoder>Actually, the farm system is relatively cool IMO.
03:44<Muxy>gday boys & girls (if any)
03:44<pjpe>this p1sim thread is the strangest but most enthralling thing i've ever read
03:44<KittenKoder>Sorry, coding while trying to contribute to the discussion.
03:45-!-Belugas [~belugas@] has joined #openttd
03:45-!-mode/#openttd [+o Belugas] by ChanServ
03:45<KittenKoder>But I like the complexes that FIRS makes you create, that's half the fun.
03:45<andythenorth>planetmaker: wrt supplies...sometimes a change elsewhere can fix an apparent problem. e.g. if we shipped
03:46<@planetmaker>andythenorth: that is still no issue IMHO. I never found a farm to not be within catchment area
03:46<pjpe>one of his reasons for using java is he can use some random library to render 2d sprites in opengl?
03:46<Muxy>does someone report trouble with the servers list on the web site ?
03:46<andythenorth>at the start of the game FIRS industries are very 'flat' - all industries of type x have same production
03:46<@planetmaker>again broken, Muxy?
03:47<Muxy>still broken
03:47<KittenKoder>Java doesn't play nice with OGL, pjpe ... just an FYI.
03:47<pjpe>don't look at me i'm not writing up this stuff
03:47<KittenKoder>But that's mostly because Sun-Oracle can't pick a library.
03:48<KittenKoder>Technically, it could work, but you have to install a bunch of secondary stuff and those are just .... *shudder* ... messy.
03:48<pjpe>it's just that picking a language because a random library lets you render 2d sprites with opengl does not sound like the greatest reason
03:48<KittenKoder>That's a horrible reason, I agree.
03:48<Muxy>1.1.2 servers are not displayed, and links given does not all the time display the concerned server
03:48<@planetmaker>well, andythenorth, there you have then with random initial production your first NML coding experience ;-)
03:49-!-Muxy [~Muxy@] has left #openttd [Quitte]
03:49<KittenKoder>I code Java primarily because everyone uses different OSes and the apps I make have to work on ... well ... almost anything with minimal effort.
03:49<dihedral>KittenKoder, you code java...?
03:50<KittenKoder>I like Java because of the language syntax and conventions.
03:50<KittenKoder>Yes, dihedral
03:50<dihedral>you have any running projects?
03:50<KittenKoder>Java is not nearly as bad as people think.
03:50<KittenKoder>I have one public project that I haven't ditched out of boredom.
03:50<dihedral>and at least you know what's consuming all your resources :-P
03:51<KittenKoder>The chat server is actually a Python script, but the client was the show off app, someone dared me to, so I did it in 2 weeks from scratch, no extra libraries.
03:51<pjpe>that site is straight out of 1997
03:51<dihedral>are you interested in an openttd related java project?
03:51<KittenKoder>I'm not all that creative with layouts.
03:52<KittenKoder>dihedral, the problem is that I'm not that good working on teams.
03:52<dihedral>so far, possibly not
03:52<dihedral>might change ;-)
03:53<dihedral>+ the aim is to manage everything by plugins ;-)
03:53<KittenKoder>I'm a small potato coder who just happened to get a few clients that needed a cheap alternative to Seattle's megacorp teams.
03:53<KittenKoder>Wow, did you find someone willing to do a plug-in architecture for Java?
03:53<@Terkhen>good morning
03:53<dihedral>KittenKoder, i am just making use of spi
03:54<dihedral>have a look at the projects joan, grapes, and berries on
03:54<dihedral>they are maven2 projects
03:54<KittenKoder>Plug-in architecture development for Java is a nightmare, really, it was not meant to include it when they created it and so Oracle has inherited a mess and no one wants to help them develop it.
03:56<KittenKoder>About the most help I could be is interface development though, honestly .... multimedia code is not something I'm great at, thus why all my attempts are making games fail.
03:56<dihedral>it's a bot
03:56<dihedral>it runs in a terminal
03:57<KittenKoder>Then ... not really my area of practice. ;)
03:57<dihedral>joan provides the network communication with openttd
03:57<dihedral>grapes creates the plugin handling and openttd related handling, the rest is done with plugins
03:58<KittenKoder>I'm a GUI coder, I make fancy looking web interfaces for people to connect to their databases with pretty little displays so they can tell what's going in and coming out.
03:58-!-Juo [] has joined #openttd
03:59<KittenKoder>For hobby, I design graphics ... in 3D ... not well I might add.
03:59*andythenorth biab
03:59-!-andythenorth [] has quit [Quit: andythenorth]
03:59<KittenKoder>As you can see from my website, I also tend to not bother updating unless there's a good reason.
04:00<KittenKoder>Woohoo! I got the Martian designed armored transport maglev done ... comparable to the 1980's trains ....
04:02<KittenKoder>But one question for anyone who knows: What is cargo_subtype in something like "switch(FEAT_TRAINS, SELF, sw_icm_te, cargo_subtype)", I can only find the information for defining it in the docs.
04:06-!-pugi [] has joined #openttd
04:08<@planetmaker>it is a number or what you define it to be
04:13<@planetmaker>hello peter1138
04:14<KittenKoder>Aaah, okay.
04:15<@Terkhen>hi peter1138
04:15<KittenKoder>Wait, no ... I think you misunderstood the question (likely because I suck at wording).
04:16<KittenKoder>I mean, what values does cargo_subtype itself get?
04:17<KittenKoder>I think I just figured it out though, it's like a specific refit value.
04:17<KittenKoder>Defined by each train.
04:18<KittenKoder>Okay .... why do I keep staying up so late doing this?
04:18<@peter1138>anyone played with drbd/pacemaker?
04:20<KittenKoder>Okay, one last question ... how does the 2ccTS get those cool icons to show in the purchase list?
04:20<@peter1138>they're part of the vehicle
04:21<@Terkhen>yes, you can define the buy menu sprite separately and they just add more stuff to it besides the vehicle
04:21<KittenKoder>Oooh, neat trick and easy to do.
04:22<KittenKoder>So I can use theirs to?
04:22<@planetmaker>if you release your stuff under GPL, yes
04:23<KittenKoder>Cool beans.
04:23<@planetmaker>i.e. just respect the license
04:23<KittenKoder>I may not be a conformist ... but I do like symbolic icons to look the same.
04:47<KittenKoder>Okay .... how did they get the name over far enough to make room?
04:47<@planetmaker>leading spaces most probably
04:48-!-andythenorth [] has joined #openttd
04:48<KittenKoder>Nope, not in the strings file at least.
04:50-!-pjpe [] has quit [Quit: ajax IRC Client]
04:50<KittenKoder>Though it might be in the nfo files. >.<
04:51<KittenKoder>How do you append strings to variable ones in NML?
04:52<@planetmaker>I've not tested it: push a string into a temporary storage: STORE_TEMP(string(blah), 256)
04:52-!-Brianetta [] has joined #openttd
04:52<@planetmaker>and then display a string which reads "blubber {STRING} blah bluh"
04:52<@planetmaker>not sure it works or whether it works in any way
04:52<@Terkhen>there is an example in ogfx-industries
04:53<Yexo>that should work
04:53<@planetmaker>ok :-)
04:53<Yexo>but not everywhere, not all strings allow you to have {STRING} codes
04:53<KittenKoder>Well, not talking about that case, like when defining the name of something. "Something" + VALUEFROMLNG
04:53<Yexo>KittenKoder: please provide a clearer example. When would you want to do that?
04:54<KittenKoder>Like in here: name: string(STR_ICM_NAME);
04:54<KittenKoder>Properties block of the train.
04:54<Yexo>you can't do it at all there
04:54<Yexo>you'll have to define "Something ICM" as string in the language file
04:54<Yexo>future work in nml might allow something like that, but that's for later
04:54<KittenKoder>;) That's what I was asking.
04:55<KittenKoder>I'm just not that good at asking the right questions.
04:55<@planetmaker>a skill even more important than answering questions, though ;-)
04:55<KittenKoder>Yeah, a concat function would be nice.
04:56<Yexo>I think for the purchase list that openttd will just move your strings to the right when the image gets bigger
04:56<Yexo>not completely sure, but worth a try before you start to mess with adding spaces in front
04:56<KittenKoder>It didn't.
04:57<@planetmaker>I'd have assumed it does... alas
04:57<KittenKoder>Even tried adjusting offsets, but that does nothing also.
04:59-!-staN [] has joined #openttd
05:00<staN>i have a problem using NARoads grf in multiplayer, they simply won't get upgraded from dust to tarmac
05:00<Yexo>that's expected behavior
05:01<Yexo>in multiplayer GRFs can easily cause desync if they have different information on clients and on the server
05:01<Yexo>as such some variables are not completely correct, when a grf ask for "current year" it gets "year the game started" instead
05:01<staN>i see, so there's no workaround?
05:01*andythenorth ponders playing a game that isn't YACD
05:01<Yexo>not that I know of
05:02<andythenorth>working on FIRS, but playing YACD is misleading
05:02<KittenKoder>The spaces worked .... but it's a messy method. >.< Oh well.
05:02<staN>so when starting mp game in say 1970 it would show tarmac both on client and server right?
05:03-!-Progman [] has joined #openttd
05:03<Yexo>staN: I think so
05:03<Yexo>in singleplayer you can notice the same effect: the roads won't actually change until you save and reload the game
05:03*staN ponders manipulating start date in savegame :P
05:04<@planetmaker>you don't need to manipulate the start date. IIRC the grf has a parameter.
05:06<Yexo>try "set starting_year 1970" in the console
05:06<Yexo>after that you'll have to save/reload the game to actually see the effects
05:06<staN>so manipulating the parameters in save game, well i coouuld try that, but read bad things about that :)
05:07<staN>Yexo: ah thanks, will try that
05:07<Yexo>hmm, if that works in mp (and I think it does) I just found a new way to desync games
05:08<staN>heh...mmh :/
05:08<@planetmaker>aren't server-side settings communicated to clients
05:09<Yexo>yes, but grfs aren't reloaded when you change a setting
05:09<@planetmaker>hm, yes :S
05:09<Yexo>so start server (load grfs), change starting year, client joins, sees new starting year and loads grfs with that value
05:09<@planetmaker>yeah, I just need more tea :-)
05:09<Yexo>the fix is simple: don't allow to change that value in a running mp game, like similar variables
05:11<@planetmaker>and why doesn't xchat allow to re-order the channel list? :S
05:13<KittenKoder>Ironically, I decided to make my own icons. >.<
05:17<staN>another question, is there a list of some kind of all decoupled waggons in depots a company has, and in which depots they lurk?
05:17<Yexo>unless it was added very recently: no
05:18<staN>i had to change 'allow multiple grfs' mid-game, it told me to get rid of all vehicles in game first
05:18<staN>i had to find out the hard way that waggons are vehicles too :)
05:18<staN>and search every single depot for a lost waggon
05:19<staN>maybe it should say all vehicles and waggons, don't know how much of a vehicle a wagon is lol
05:23<Rubidium>isn't the start date a 'new game' only setting? (or SE)
05:25<@planetmaker>lol. There's no 'need to allow multiple vehicle grfs mid-game' ;-)
05:28<staN>well when playing with ecs and nars after 1920 or 1930 suddenly default waggons started to appear, i tried starting a game with the same grfs but that mutiple thing turned off and they weren't i figured i would need to turn it off in my running game...
05:29<staN>and it worked...
05:29<staN>after spending quite some time searching lost waggons :D
05:35<@planetmaker>oh dear
05:36-!-jpx_ [] has joined #openttd
05:38<staN>i think a list of all depots, like there is for stations would have helped a tad :)
05:39<KittenKoder>Actually, though why you wound up doing it seems ... odd, a depot list would be a nice feature addition.
05:39<@planetmaker>staN, you've been using OpenTTD in a sort-of debug mode. It's not an end-user action which you performed by changing that setting on a running game
05:39<@planetmaker>it's not meant to be changed
05:40<@planetmaker>you basically changed the engine of a car while driving at 100km/h on the highway
05:41<Rubidium>pff... you can reboot the engine of a spaceship when it goes at warp 5+
05:41<staN>went ok :), but yeah i see your oint
05:42<KittenKoder>A depot list that also tells what type it is.
05:42<@planetmaker>Rubidium, restart != exchange hardware ;-)
05:42<KittenKoder>Though I'm past those days of mass conversion ....
05:42<@planetmaker>I can safely turn off my car's engine at 100km/h, too
05:43<Rubidium>planetmaker: restart as in reflashing the motor management ;)
05:43<KittenKoder>Pswhaw .... my dad can replace break pads going 100km/h
05:43<KittenKoder>There, beat you all!
05:46<Rubidium>ah well, I could do it while moving a a few hundred km/s!
05:46<@planetmaker>now, that'd be interesting, Rubidium :-)
05:47<@planetmaker>hm... what's your reference frame there?
05:47<staN>earth rotation around the sun?
05:47<@planetmaker>30 for Earth vs. sun
05:47<@planetmaker>about 20 of the sun vs. local standard of rest
05:48<@planetmaker>and only 200 of the sun vs. milkyway's centre
05:48<Rubidium>planetmaker: local cluster of galaxies
05:48<@planetmaker>:-) remains about the only option
05:49<Rubidium>although sun vs milkyway would work as well
05:49<@planetmaker>just so :-)
05:49<Rubidium>just didn't know whether I could simply sum all the speeds
05:49<KittenKoder>I gots icons.
05:49<Rubidium>as they arguably are vectored differently
05:49<@planetmaker>well, one can't really... but 200 vs. 20 doesn't matter anymore ;-)
05:50<Rubidium>no, but 300 + 200 or 300 - 200 makes quite a difference
05:50<@planetmaker>well. All those rotational motions are periodic ;-)
05:51<@planetmaker>thus it'll average out
05:52<Rubidium>so if I time it right I can do it at roughly 500 km/s ;)
05:53<@peter1138>yeah, i read that MW is moving at around 580 km/s
05:53-!-rellig [] has joined #openttd
05:53-!-rellig [] has quit []
05:54<@planetmaker>I always wonder whether the cosmic microwave background is not a, but the reference frame...
05:55<@planetmaker>it'd somewhat contradict the theorem that there's no special reference frame anywhere
05:55<@peter1138>and that's 0.1% of c
06:13-!-Biolunar [] has joined #openttd
06:16-!-sla_ro|master [~slaco@] has joined #openttd
06:27-!-andythenorth [] has quit [Quit: andythenorth]
06:28<KittenKoder>Is there something about the sprite_id that should be changed for multiple trains in a GRF?
06:30<KittenKoder>The first one is showing up but the second one I added is not.
06:31<@planetmaker>uhm... spriteID is not an array
06:31<@planetmaker>and for a new train most likely should have the value SPRITEID_NEW_TRAIN or how that is called
06:32<KittenKoder>Yeah, I did that, it's just SPRITE_ID_NEW_TRAIN
06:32<KittenKoder>Which means I'm back to page zero. >.<
06:34<@planetmaker>look at the example which is shipped with nml
06:35<KittenKoder>Yeah, that's how I figured it out.
06:35<KittenKoder>But as I said, it's all fine but the second train I added isn't showing up in game.
06:36<KittenKoder>No errors reported though.
06:36<KittenKoder>So I'm at a loss and grabbing at straws for possible things I did wrong.
06:36<@planetmaker>good thing that you verbosely share the code with us so that we have an easy time without guessing in the dark
06:38<KittenKoder>I know.
06:38<KittenKoder>It's just a bother doing all that most times ... just this time I am going to have to.
06:39<KittenKoder> <- Can you see what I may have completely screwed up? Keep in mind, this is a rough starting point.
06:41<KittenKoder>I'm now thinking I screwed up on the cargo classes thing.
06:42<KittenKoder>Aaah, yes, I missed part of the documentation.
06:45<KittenKoder>That didn't help.
06:46<@planetmaker>missing an essential property often is the reason
06:46<KittenKoder>They're all there though.
06:50<KittenKoder>Okay, now it's working. That was really odd.
06:50<@Terkhen>when something really strange is happening, I usually forgot to copy the grf to ~/.openttd :P
06:51<KittenKoder>It may have copied wrong .... I just don't know. >.<
06:53<KittenKoder>Erm ... messed up the tractive effort massively. >.<
06:58<KittenKoder>The Xeno LV-426
07:17<KittenKoder>Okay, two trains done ....
07:17<KittenKoder>I think I have the hang of this finally.
07:18<KittenKoder>Now time to practice the hard part.
07:18-!-pm [] has joined #openttd
07:18-!-mode/#openttd [+o pm] by ChanServ
07:18-!-tneo- [] has joined #openttd
07:19-!-Hirundo_ [] has joined #openttd
07:19-!-SmatZ is now known as Guest6374
07:19-!-SmatZ [] has joined #openttd
07:19-!-mode/#openttd [+o SmatZ] by ChanServ
07:19-!-^ekipS^ [] has joined #openttd
07:19<KittenKoder>Figured out the coding for multi-units and basic engines, worked out a decent sprite template system, and a very simple Makefile ....
07:19-!-|Terkhen| [] has joined #openttd
07:20-!-Ammller [] has joined #openttd
07:20-!-Osai^2 [] has joined #openttd
07:20-!-V4530000 [] has joined #openttd
07:21-!-avdg [] has quit [Ping timeout: 480 seconds]
07:21-!-tneo [] has quit [Ping timeout: 480 seconds]
07:21-!-XeryusTC [] has quit [Ping timeout: 480 seconds]
07:21-!-V453000 [] has quit [Ping timeout: 480 seconds]
07:21-!-Hirundo [] has quit [Ping timeout: 480 seconds]
07:21-!-V4530000 is now known as V453000
07:21-!-Hirundo_ is now known as Hirundo
07:21-!-DJNekkid [] has quit [Ping timeout: 480 seconds]
07:21-!-Yexo- [] has joined #openttd
07:21-!-XeryusTC [] has joined #openttd
07:21-!-Ammler [] has quit [Ping timeout: 480 seconds]
07:21-!-Ammller is now known as Ammler
07:21-!-avdg [] has joined #openttd
07:22-!-Yexo [] has quit [Ping timeout: 480 seconds]
07:22-!-Osai [] has quit [Ping timeout: 480 seconds]
07:22-!-^Spike^ [] has quit [Ping timeout: 480 seconds]
07:22-!-planetmaker [] has quit [Ping timeout: 480 seconds]
07:22-!-pm is now known as planetmaker
07:22-!-^ekipS^ is now known as ^Spike^
07:22-!-Terkhen [] has quit [Ping timeout: 480 seconds]
07:22-!-Guest6374 [] has quit [Ping timeout: 480 seconds]
07:22-!-|Terkhen| is now known as Terkhen
07:22-!-DJNekkid [] has joined #openttd
07:22<LordAro>why is so unreliable? :3
07:27<KittenKoder>French fries.
07:31-!-Yexo- is now known as Yexo
07:31-!-Fuco_ [] has joined #openttd
07:32-!-Fuco_ [] has quit []
07:37<@planetmaker>sorry, LordAro.... our hypervisor has some issues...
08:10-!-XeryusTC [] has quit [Ping timeout: 480 seconds]
08:10-!-XeryusTC [] has joined #openttd
08:11-!-glx [glx@2a01:e35:2f59:c7c0:511c:4bae:adaa:fd7c] has joined #openttd
08:11-!-mode/#openttd [+v glx] by ChanServ
08:18<Ammler>LordAro: not everyone likes how I abuse it to play around :-)
08:19<Ammler>anyway, please tell your issue with it, just watching parts/joins doesn't help
08:19<Eddi|zuHause>someone tell andy my post was here:
08:24<@planetmaker>thanks, Eddi|zuHause
08:25-!-sla_ro|master [~slaco@] has quit []
08:32<LordAro>Ammler: my issue with it is the part/joins ;)
08:33<@planetmaker>LordAro, the VM running the bouncer of course also goes down when the hypervisor reboots...
08:33<LordAro>how do you get a 'address' anyway? i've always wondered that... :)
08:35<Eddi|zuHause>you make a charitable donation :p
08:36<Ammler>yes, if you buy something there, I might be responsible to keep it up
08:36<Ammler>now everything is free and I don't :-P
08:36<@planetmaker>it's meant for the members of #openttdcoop and I'd say for regular DevZone users
08:37<Ammler>for users with even more unreliable connections as we have :-P
08:38-!-DayDreamer [~DayDreame@] has quit [Quit: Leaving.]
08:41<LordAro>makes sense
08:41<LordAro>(if i understood whatever you were talking about :P )
08:42-!-gggirl [] has joined #openttd
08:43<LordAro>hmmm... how to convert a 'const char*&' to 'const char*' ?
08:44<Yexo>by removing the &
08:44-!-gggirl [] has quit []
08:44<Yexo>that's really all we can say without you providing more context
08:45-!-sla_ro|master [~slaco@] has joined #openttd
08:53-!-sla_ro|master [~slaco@] has quit []
08:55-!-Lakie [~Lakie@] has joined #openttd
09:08-!-fjb [] has joined #openttd
09:09-!-andythenorth [] has joined #openttd
09:15-!-douknoukem [~KEM@] has joined #openttd
09:34-!-Prof_Frink [] has joined #openttd
09:37<LordAro>make that a 'char* const&' -> 'const char*' -- the char* const& is 'part' of a char array (char *readme_text_lines[MAX_README_LINES];)
09:40<+glx>that's a char ** ;)
09:40-!-Adambean [] has joined #openttd
09:42-!-HerzogDeXtEr [] has joined #openttd
09:45<LordAro>its not... "the char* const& is 'part' of a char array" and "(char *readme_text_lines[MAX_README_LINES]; )" are separate
09:51-!-perk11 [] has joined #openttd
09:57<Rubidium>context oh padawan ;)
09:58<LordAro>define context
09:58<Rubidium>the actual code that triggers the error +- at least 3 lines
09:58<Rubidium>and everything that it references
10:08<Eddi|zuHause>what he means is: SHOW US THE WHOLE DAMN PATCH, MAN!
10:13-!-TWerkhoven [] has joined #openttd
10:17-!-staN [] has quit [Quit: ajax IRC Client]
10:31<@Belugas>naaa... don't show us, we all do uderstand it's top secret stuff ;)
10:41-!-jpx_ [] has quit [Ping timeout: 480 seconds]
10:43-!-ladyg [] has joined #openttd
10:45-!-ladyg [] has quit []
11:13-!-ptr [] has joined #openttd
11:26-!-DOUK [~KEM@] has joined #openttd
11:28-!-sla_ro|master [~slaco@] has joined #openttd
11:29-!-andythenorth [] has quit [Quit: andythenorth]
11:32-!-douknoukem [~KEM@] has quit [Ping timeout: 480 seconds]
11:32-!-Brianetta [] has quit [Quit: Tschüß]
11:35-!-|Jeroen| [] has joined #openttd
11:41-!-DOUK [~KEM@] has quit [Read error: Connection reset by peer]
11:43-!-Juo_ [] has joined #openttd
11:45-!-Juo [] has quit [Read error: Operation timed out]
11:45-!-Juo_ is now known as Juo
11:55-!-|Jeroen| [] has quit [Quit: oO]
12:13-!-supermop_ [] has joined #openttd
12:17-!-aditsu [] has joined #openttd
12:17<aditsu>hi, what can I do against a player who is stealing my resources?
12:17<+glx>it's not your resources
12:18<+glx>you are just transporting it
12:18<aditsu>so he can just come when I grew the production to maximum, and take half of it or so, making my trains lose money?
12:19-!-Br33z4hSlut5 [] has quit [Remote host closed the connection]
12:19<@planetmaker>you can provide better service, though
12:19<aditsu>that doesn't seem fair to me
12:19<@planetmaker>what's unfair there?
12:19<@planetmaker>it's not your industry
12:20<@planetmaker>you could of course play on a server where the server rules state that such "stealing" is not allowed
12:20<aditsu>well, I take a coal mine and carefully bring it from 40 to 2295 production over a long time, then he just comes and takes the profit and damages my business
12:20<@planetmaker>and where there are actually admins around to enforce that
12:20<+glx>if you have 2 stations for this industry with good service he won't get anything
12:21<aditsu>hm.. so I should make another station?
12:21<aditsu>and have better service?
12:22<@planetmaker>yes. And build a statue, if you haven't
12:22<aditsu>I have statues, he doesn't :)
12:22<@planetmaker>then he can't get half of your cargo
12:22<@planetmaker>it's split according to "service level"
12:22<@planetmaker>station rating
12:22<@planetmaker>for that cargo
12:23<Yexo>aditsu: if you really don't like any competition play on another server that A) has an active admin and B) doesn't allow competing for cargo
12:23<aditsu>I didn't know it was generally allowed
12:23<Eddi|zuHause>why wouldn't it be?
12:24<Yexo>generally there are no rules at all
12:24<Yexo>of course there are some guidelines that most people adhere to, but even that can only be enforced when there is an active admin around
12:25<supermop_>gah ring cycle is so expensive
12:25<Eddi|zuHause>a flat cycle would be awkward
12:26<supermop_>the worst seats are $400
12:26<supermop_>thats for the whole cycle, but still
12:29<aditsu>hm.. my 2nd station doesn't seem to get anything
12:29<aditsu>or is it too late to make it?
12:29<LordAro>Rubidium: fine: :) <-- line 184/5 trigger the error
12:29<Eddi|zuHause>only the two stations with the highest rating get anything, all others get nothing
12:31<+glx>LordAro: what's the exact message ?
12:31<aditsu>Eddi|zuHause: so if there are already 2 stations, and I make another one, how can I get its rating up?
12:32<Eddi|zuHause>aditsu: you can't
12:32<aditsu>ok so it's too late then
12:32<Eddi|zuHause>(or by transferring cargo to it)
12:32<aditsu>oh? hmm
12:32<aditsu>I can try that
12:34<+glx>LordAro: *this->readme_text_lines[this->num_lines] = *src; <-- that's wrong
12:35<+glx>hmm no it's just weird :)
12:35<aditsu>oh wait, it transported something
12:35<LordAro>glx: so it is, that's just 1 character, is it not?
12:36<+glx>hmm I don't see where you allocate space for the array
12:37<+glx>oh you don't
12:38<+glx>so yes the line is wrong
12:38<LordAro>no, i do for readme_text though, but i guess that's not enough :)
12:39<+glx>anyway you could just do this->readme_text_lines[this->num_lines] = src; on newline, and replace \n and \r with \0
12:40-!-lugo [] has quit [Remote host closed the connection]
12:40<+glx>btw free(this->readme_text_lines) with no malloc is a bad idea too :)
12:44<+glx>especially for char *readme_text_lines[MAX_README_LINES];
12:47-!-Zuu [] has joined #openttd
12:47-!-andythenorth [] has joined #openttd
12:48-!-Zuu [] has quit []
12:48<aditsu>oh cool, now I have 2 stations with better rating :)
12:50-!-Zuu [] has joined #openttd
13:07*KittenKoder gasps
13:07<KittenKoder>How dare you help them, glx!
13:08-!-Juo [] has quit [Quit: Juo]
13:08<aditsu>I have another question.. there's a button to get the last message/news report, but it doesn't seem to use the message settings, it just shows the last unfiltered message, is there a way to just show the last message that was displayed to me?
13:09<KittenKoder>You can display a list of all the last messages.
13:10<KittenKoder>Use Message History, it doesn't actually show the messages, it just shows a list of their titles.
13:10<aditsu>oh yeah, but on a large map, it's pretty hard to find what I want among all the industry reports
13:10<LordAro>glx: i know, i'm not sure how to free char arrays :)
13:10<aditsu>the list is not filetered either
13:10<KittenKoder>Currently that's the only option.
13:10<@planetmaker>aditsu: I fear the answer is "we eagerly await your patch" as it has not yet a meaningful filter
13:11<aditsu>planetmaker: I'm talking about filtering based on the message settings
13:11<KittenKoder>We eagerly await your patch.
13:12<@planetmaker>aditsu: that doesn't change my answer ;-)
13:12<@planetmaker>the message settings define what is displayed where. But should not kill other messages in the overall history
13:12<@planetmaker>but the view of the overall history could get a filter like "only this" "only that" "according to news filter"
13:12<aditsu>don't be TOO eager or you might get disappointed ;)
13:14<aditsu>but if I happen to find some time, I might look at the code
13:15<KittenKoder>I think a lot of players like it as it is enough to not be that eager.
13:15<KittenKoder>But a lot of low demand options added to a product can often become high demand after the patch.
13:16<@planetmaker>aditsu: I don't expect anything. But sometimes it helps to give ideas on what / how a patch would (from my POV) fit the game
13:16<@planetmaker>there are unfortunately(?) orders of magnitude more ideas than time devoted to developing ;-)
13:19<KittenKoder>Real life can slow the progress of open source.
13:19-!-Alberth [] has joined #openttd
13:19-!-mode/#openttd [+o Alberth] by ChanServ
13:24-!-pjpe [] has joined #openttd
13:26<aditsu>heh that guy started buying exclusive rights
13:27*Alberth didn't buy such rights at all
13:27<Terkhen>urgh, I hate those
13:28<@Alberth>Terkhen thus also did not buy them :)
13:34<Terkhen>the plot thickens
13:34-!-Juo [] has joined #openttd
13:38<Zuu>When adding a new file, shall the $Id and @file comments be created or are they created by the version control system?
13:38<Terkhen>you have to add them
13:39<Zuu>Including all information that is available in other files?
13:40-!-supermop_ [] has quit [Ping timeout: 480 seconds]
13:40<Zuu>Though, I don't know who will commit the patch etc. :-)
13:42<Terkhen>IIRC those are filled automatically, but I don't know the details
13:42-!-beijingguy [] has joined #openttd
13:42<Zuu>I'll just leave them as is for now and let that be delt with later on.
13:43<Zuu>Although, I do edit the file comment.
13:44<@Alberth>Zuu: the @file is static, the $Id$ will be expanded automagically
13:44<Zuu>Alberth: So I should just have a comment: /* $Id$ */ at the top and the vcs will expand that?
13:45<CIA-2>OpenTTD: translators * r22759 /trunk/src/lang/ (dutch.txt swedish.txt unfinished/persian.txt):
13:45<CIA-2>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-2>OpenTTD: dutch - 2 changes by Bennievv
13:45<CIA-2>OpenTTD: persian - 224 changes by Peymanpn
13:45<CIA-2>OpenTTD: swedish - 13 changes by Zuu
13:45<@Alberth>subversion will, if you set 'svn:keywords' to 'Id'
13:46-!-frosch123 [] has joined #openttd
13:53-!-supermop_ [] has joined #openttd
13:55<Ammler>on hg, this is not needed
13:56<Ammler>but there is a extension keysomething
13:58-!-valhallasw [] has joined #openttd
13:59<Rubidium>Ammler: so you need to install something extra, instead of enabling something
13:59<Rubidium>Ammler: and how can you tell it to not do it?
13:59<@Alberth>Could be. I used $Id$ extensively in the past, but nowadays I don't care much for it
13:59<Ammler>Rubidium: because you do not need it, it is just a 3rd party extension
14:00-!-Wolf01 [] has joined #openttd
14:00<Rubidium>Ammler: say I want it on some files, but don't want it to happen on some other files in the same repository
14:00<Rubidium>e.g. because they contain a $Id$ style token that must not be changed
14:01<Ammler>Rubidium: well, first you should explain why you should need it on hg :-)
14:01<Ammler>what is it useful for?
14:01<@Alberth>Ammler: I don't want my .png file with $Id$ expanded
14:02<Ammler>Alberth: I meant, why do you want does key substitions at all?
14:02<Rubidium>Ammler: because if you then make a tarball you get the version in the files, so based on a source tarball you can determine the used version
14:03<Ammler>yep, that is for svn, why do you need it for hg?
14:03-!-douknoukem [~KEM@] has joined #openttd
14:03<Rubidium>e.g. to figure out the version of some OpenTTD tarball, like the 1.0.0 made by someone else
14:03<Ammler>that is the whole reason, hg does not care about
14:03<Ammler>does git?
14:04<@Alberth>Ammler: how is the vcs of relevance for determining the revision of a file?
14:04<Ammler>Alberth: on hg, you can simply run hg log <file>
14:04<@Alberth>from the tar-ball ?
14:04<Ammler>well, you don't use a tarball to work with
14:04<@Alberth>in an environment without a hg clone nearby?
14:05-!-st-15308 [foobar@] has joined #openttd
14:05<@Alberth>that's why you want it in the file itself
14:05<Ammler>as said, for those guys insist on it, can use the extension
14:06-!-st-15308 [foobar@] has quit []
14:06<andythenorth>Eddi|zuHause: last comment here:
14:06<Rubidium>Ammler: if I get the files from nml and dump them in a git repository. How can you tell me the version. Imagine for this instance that I tag it 1.0.0
14:07<Ammler>Rubidium: again, you don not use the tarball
14:07<Rubidium>in this case I'll actually be using the source files of r1625
14:07<Ammler>you convert the hg repo
14:07<Rubidium>Ammler: I don't, you don't... other morons will
14:08<Ammler>and you care about those?
14:08<Eddi|zuHause>andythenorth: what's the meaning of the strike-through?
14:08<andythenorth>silly formatting :(
14:08<andythenorth>no significance
14:09<Rubidium>Ammler: yes, I do when they start claiming that their 1.0.0 build from a particular source tarball fails. It's pretty useful to be able to tell it's the source of some trunk nightly from half a year before 1.0.0
14:09<andythenorth>Eddi|zuHause: this solution uses a stockpile but hides it from the player for various reasons
14:09<andythenorth>it's much discussed in the 'other' channel :P
14:09<Rubidium>but then I guess you have not had the pleasure of people mutilating your work and shipping it as their own
14:10<Ammler>Rubidium: but that is svn, where you have it
14:10<Ammler>where it makes sense
14:12<Rubidium>LordAro: I applied the diff and the error I get isn't quite what you were talking about
14:13<Rubidium>LordAro: is what I get
14:13<Rubidium>the important bit there being: "no known conversion for argument 6 from TextDirection to StringAlignment"
14:15<Rubidium>LordAro: easiest solution: remove the last two parameters. They have default values which are fine in your case
14:20<LordAro>Rubidium: i can't have been reading the error messages carefully :) fixed
14:20<LordAro>oh, and how would i get rid of the 'NULL in arithmatic' warning?
14:21<Rubidium>you are comparing a character to NULL
14:21<Rubidium>you want to compare it to '\0'
14:24<LordAro>compling... segfault (or similar hear i come! :)
14:25<LordAro>*(or similar) here :3
14:25<@Alberth>you crash the compiler? :p
14:26<LordAro>it has been known :)
14:26<LordAro>hai Alberth :D
14:26<@Alberth>hai LordAro :)
14:26<@Alberth>hard at work, I see :)
14:27<LordAro>yeah... i got a bit bored with minecraft multiplayer :)
14:28<LordAro>"Segmentation fault (11)" <-- told you!
14:29<LordAro> <-- how terribly broken is this? (lines 177+ and 228+)
14:33<KittenKoder>My eyez! Zee gogglez ... zey do nuthzing!
14:33<KittenKoder>J/K .... I didn't actually look. :p
14:36<Eddi|zuHause>LordAro: err... wtf? "*src"?
14:36<Yexo>LordAro: you're never allocating space for readme_text_line
14:37<Eddi|zuHause>LordAro: always do explicit comparisons in these things
14:38<@Alberth>LordAro: readme_text_lines is part of the Window struct, you should not free such data
14:38<Eddi|zuHause>LordAro: so, below "this->readme_text = MallocT<char>(filesize + 1);" you should probably do the same thing with readme_text_lines
14:39<Yexo>it makes more sense to let readme_text_lines point to lines within this->readme_text
14:39<@Alberth>Eddi|zuHause: no, in the window struct is fine, it needs conversion to a smallvector later
14:39<Yexo>no need to allocate more data
14:39<@Alberth>Yexo: that was the idea
14:39<Yexo>ah, ok
14:39-!-Kurimus [] has joined #openttd
14:39<Yexo>that does require editing the this->readme-text arrow in-place to remove unprintable characters, and not while copying it (currently to random memory)
14:40<LordAro>Alberth: then i've got completely confussled :L
14:40<Eddi|zuHause>"GetReadmeChar" is probably misnamed ;)
14:40<@Alberth>LordAro: where do you initialize readme_text_lines such that line182 becomes true?
14:40<Yexo>it is, but GrfHasReadme is too
14:40<Yexo>from that name I'd expect a bool as return value
14:41<LordAro>Yexo: it used to :)
14:41<LordAro>Alberth: is shouldn't, more of an assert really
14:41<LordAro>afk - tea
14:41<Eddi|zuHause>what i would do is just loop through readme_text, replace all \n with \0 and record their locations as beginning of next line...
14:42<@Alberth>LordAro: when the functionality of a function changes, the name should change accordingly
14:42<@Alberth>Eddi|zuHause: you got the idea :)
14:42<@Alberth>Eddi|zuHause: although it should also strip non-printable characters in the same sweep
14:42<@Alberth>but combining can be done later
14:43<Eddi|zuHause>so readme_text_lines[0] = readme_text, for (char blah) { if (blah = '\n') { blah = '\0'; readme_text_lines[index++] = blah+1;}
14:45*Alberth nods
14:45-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
14:46<Eddi|zuHause>LordAro: doing *src++ within the loop is probably evil
14:47<KittenKoder>vry sloppy
14:47-!-Wolf01 [] has quit [Read error: Connection reset by peer]
14:47<KittenKoder>Unless there
14:47-!-Wolf01 [] has joined #openttd
14:48<@Alberth>KittenKoder: be gentle, it's his first program
14:48<KittenKoder>Consider my comment as a lesson then. :p
14:48<KittenKoder>hard to type more than that though when I was nomming my burger.
14:52<KittenKoder>c++ .... you could make use of the default string library.
14:53<KittenKoder>Arrays are a challenge for beginners, in c/c++
14:54<@Alberth>but it also has to fit openttd style somewhat
14:54<KittenKoder>You mean OTTD uses c++ but no c libs?
14:54<@Alberth>very little
14:54<pjpe>builds character
14:55<@Alberth>it started in assembly, was decoded to C, and now c++ gets introduced where useful
14:55<KittenKoder>Aaah, the slow migration.
14:55<@Alberth>so there is still a lot of C-ish code
14:56<KittenKoder>>.< Are there still macros?
14:56<@Alberth>especially at the critical path it is highly optimized
14:56<@Alberth>oh sure, lots of #define s :)
14:56<@planetmaker>lots and lengthy :-)
14:56<KittenKoder>#define is used for more than just macros. :p
14:56<@Alberth>but not for constants any more, mostly
14:56<Terkhen>you don't like macros? you shouldn't look at pnml projects then :P
14:57<KittenKoder>Though technically, they are macros I guess.
14:57<KittenKoder>Terkhen, I don't like macros, mostly because of the syntax for them, also because it's being phased out of even c now.
14:57<KittenKoder>Templating is the new macro. :p
14:58*Alberth keeps his m4 program well hidden
14:59<KittenKoder>They just haven't gotten c or c++ templates able to completely replace macros, so they will likely stick around. However, I have written a LOT of programs (utility apps) that have never needed one macro. :p
14:59<KittenKoder>So it is possible to avoid, just takes a LOT of adjusment.
14:59<KittenKoder>But meh, I'm rambling.
14:59<@Alberth>using them sanely is the key, just like gotos :)
15:00<KittenKoder>... and for a beginner, his code is actually clean.
15:01*andythenorth has discovered some....issues with rivers
15:01<KittenKoder>It's readable and CamelCase is used well.
15:01<@Alberth>lots of copy/paste, and some gentle pushes from me :) but code style is by himself though
15:02<KittenKoder>Though, there's a few old school syntax in there.
15:02<KittenKoder>Then he's got a good mentor-ish.
15:03<KittenKoder>I think most of the old school naming convention is from the copy-pasta though.
15:04<KittenKoder>However a lot of new c coders these days (the leet ones) are vehemently defending it. >.<
15:04<Yexo>well, while LordAro is some ways is new, he's been writing squirrel code for at least 2 years now, so he's not exactly completely new anymore
15:04<KittenKoder>Buffering next Futurama.
15:05<KittenKoder>That's the language I was going to look up.
15:05<KittenKoder>Okay, I like it already.
15:06<KittenKoder>"squirrel's syntax is similar to C/C++/Java etc... but the language has a very dynamic nature like python/Lua etc... " <- pure epic win
15:06<@Alberth>it's a quite nice scripting language
15:06<Yexo>the implementation of the language is not so nice
15:07<KittenKoder>It's amazing that there are entire games coded in scripting languages now. LOL CPUs are uber now.
15:07<KittenKoder>It's Euphoria ....
15:07<KittenKoder>A cross-platform Euphoria ...
15:07<KittenKoder>"local array=[ 1, 2, 3, { a = 10, b = "string" } ];" <- Euphoria array.
15:09<KittenKoder>The difference is the syntax varies, but otherwise, the more I look at it, it's what Euphoria was suppose to become, at least what the author promised it was going to be but never got there.
15:09<KittenKoder>Bookmarked for later reference, now ... what was it that was coded with it that I had heard of?
15:10<Yexo>squirrel? OpenTTD uses it for AIs
15:10<KittenKoder>Oh yeah, that.
15:11<KittenKoder>I was pondering taking a try at making an AI for OTTD at some point.
15:11<KittenKoder>First I want to get a handle on this NML stuff, to me it's completely new.
15:17<@Alberth>Euphoria feels a bit like lua to me, although I have not much experience in lua
15:18<@Alberth>(and none in Euphoria :) )
15:18<KittenKoder>It was awesome back when it was young, but then it just .... stopped going anywhere.
15:20<KittenKoder>Especially because it was only Windows.
15:20<KittenKoder>Well, that wasn't why, it was because it was made specifically to work with Windows.
15:20-!-supermop_ [] has quit [Quit: supermop_]
15:22-!-KouDy [~KouDy@] has joined #openttd
15:22<andythenorth>so this rivers grf currently doesn't support snow transition
15:23<andythenorth>and I don't fancy drawing support for transition
15:23<andythenorth>and unrelated, my palette is bork-bork, but I'll figure that out :P
15:23<Ammler>not really necessary for this tiny bit of shore, is it?
15:23<Rubidium>andythenorth: I don't think that missing transition will be a huge issue ;)
15:24*Alberth tries to apply LordAro s patch, and fails
15:24<Rubidium>maybe (much) later, when the rivers are flowing it's something to look back at
15:24<andythenorth>I really don't want to draw it :)
15:24<Ammler>Alberth: from paste service?
15:24<KittenKoder>What does the rivers GRF do?
15:24<Ammler>use hg import instead patch
15:25<@Alberth>after clicking 'raw' and 'download' yes
15:25<Rubidium>andythenorth: it's not as noticable as the rail tracks ;)
15:25<Ammler>afaik, the paste service does cut the empty end lines
15:26<@Alberth> it is worse than just at the end
15:26<Rubidium>Alberth: svn up?
15:26-!-JVassie [] has joined #openttd
15:27<andythenorth>do rivers freeze up above snowline?
15:27<Rubidium>andythenorth: they don't
15:27<@planetmaker>hardly, andythenorth
15:27<Rubidium>maybe the edges a bit ;)
15:27<@planetmaker>or siberia wouldn't have rivers ;-)
15:27<@planetmaker>and boats running on ice would look very funky
15:28-!-pugi [] has quit [Ping timeout: 480 seconds]
15:28<andythenorth>vehicle-aware routes!
15:28<andythenorth>snow, sand, foliage
15:29<Ammler>LordAro: you should git diff format (might not be the issue, Alberth has)
15:30<@Alberth>interestingly, 'patch' broke on trunk, but 'hg import' did not.
15:30<Prof_Frink>Feature request: Glaciers
15:31<Prof_Frink>(New disaster: Train falls down crevasse)
15:31-!-KritiK [] has joined #openttd
15:32-!-pugi [] has joined #openttd
15:32-!-Mucht [] has joined #openttd
15:50<+glx><Yexo> the implementation of the language is not so nice <-- yeah squirrel source is horrible
15:51-!-Adambean [] has quit [Quit: Gone fishing]
15:51-!-beijingguy [] has left #openttd []
15:55*Zuu digs into the issue of why airport types are reported as available while they clearly shouldn't be that.
15:55<Zuu>Apart from that I think I have a workable implementation of AIAirportTypeList :-)
15:58<Zuu>Oh well, the AIAIrportTypeList works fine, just that it will give eg. airport type 40 which internally in OpenTTD has "IsAvailable()" reporting true which is clearly not correct.
16:02<Zuu>I guess the GUI just don't display those airports.
16:03-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
16:04<Zuu>The DoCommand-thing have some extra checks apart from IsAvailable(), so hopefully you can't cause trouble by passing an undefined airport to a server. :-)
16:04<LordAro>Alberth: so what do i need to do to the patch that i'm not understanding?
16:05<@Alberth>Eddi|zuHause had several good lines
16:06-!-Brianetta [] has joined #openttd
16:08<@Alberth>LordAro: you should initialize every piece of data before use, in this case, readme_text_lines in particular
16:08-!-Mucht [] has quit [Remote host closed the connection]
16:08<@Alberth>and since you don't malloc that data, you should also not free it
16:09<Zuu>Soo boring... building airport type 40 does not do anything more than building a small airport :-p
16:10<@Alberth>DrawString at line 184 expects a line without \n and ending in \0
16:10<@Alberth>Zuu: some safe fallback ?
16:11<Zuu>It could also be that the dumy airport is a small airport.
16:11<@Alberth>line 232 is simply wrong, you should not copy characters using the readme_text_lines pointers
16:11<Zuu>Or that the NewGRF airport type IDs are small airports by default if they are not overriden.
16:12<@Alberth>the former sounds more likely
16:12<LordAro>Alberth: ok, but how would i malloc readme_text_lines? i surely can't do "this->readme_text_lines = MallocT<char>(filesize + 1);" ?
16:12-!-Kurimus [] has quit []
16:13<@Alberth>LordAro: don't malloc it, it is fine as-is
16:13<Zuu>There is a specific concept of "overriding" an airport. That concept is not what I was refering to, which is why I substituted "overriden" to "changed".
16:13<Yexo>the dummy airport is not the small airport
16:14<LordAro>Alberth: wait, what? i thought i had to malloc it
16:14<LordAro>oh no, wait. to free it i have to malloc it, which isn't necessary :)
16:14<Zuu>As far as I can see the spec-array (which goes up to 127) is zeroed with memset and then the specs for type 0 to 9 is set used data in OpenTTD.
16:14<@Alberth>LordAro: no, I said that you should not free things you don't malloc
16:14<Zuu>After that I the NewGRF stuff kicks in.
16:15<LordAro>Alberth: that line has been deleted :3
16:15<Yexo>Zuu: and the memset should make sure "enabled" is false
16:15<Yexo>which is the first thing AirportSpec::IsAvailable checks
16:15<@Alberth>LordAro: ok :)
16:16<LordAro>[20:04:38] <Yexo> well, while LordAro is some ways is new, he's been writing squirrel code for at least 2 years now, so he's not exactly completely new anymore <-- yes :) but with squirrel you don't have to bother about silly things like pointers or type changes :)
16:16<Zuu>Yet IsAvailable() returns true for type 19 to 127 in my tests (with latest OpenGFX+ Airports loaded)
16:16<Zuu>I've had similar issues without that NewGRF loaded.
16:16<Yexo>if that's true there is a serious bug somewhere
16:17<Zuu>Somehow that NewGRF have made type 11-18 non-available.
16:17<@Alberth>The trick is that readme_text_lines points to data in readme_text (the first character of each line, in fact)
16:17<LordAro>but i'm still not sure how to do that :/
16:17<Zuu>Yexo: That's the bug I'm trying to find. :-)
16:18<Yexo>Zuu: that sounds the wrong way around
16:18<Yexo>loading OpenGFX+Airports should make types 11-18 valid
16:18<@Alberth>LordAro: do you understand what readme_text_lines[0] should contain ?
16:18<Zuu>AFAIK OpenGfx+Airports only provide one airport yet which is available as id 10.
16:18<Zuu>That one is reported as buildable.
16:19<LordAro>Alberth: i'm not so sure...
16:19<Zuu>In 1950 the following are buildable: 0, 10 and 19 to 127.
16:19<Zuu>10 is a 180 degree rotated small airport.
16:19<Yexo>Zuu: IIRC it provides snowy versions of all airports
16:20<Yexo>which version do you have?
16:20<@Alberth>LordAro: suppose I have text "abc\ndef\0" what should be in readme_text_lines[0] ? (and [1] ?)
16:20<Yexo>a rotation does not imply a separate id
16:20<Yexo>so id 10 should be the overriden small airport (both normal rotation and the rotated version)
16:21<Zuu>Oh, yes 10 is both rotations.
16:21<Yexo>also id 0 is the default small airport, as soon as it gets overriden by a newgrf id 0 should be disabled
16:21-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
16:22<Zuu>Hmm, the compatibility layer will need to have access to some function that can translate 0 to 10.
16:22<@Alberth>Yexo: <-- looks like it uses id 0
16:23<Yexo>Zuu: AirportSpec::Get(0)->GetIndex() will return 10
16:23<Yexo>Alberth: that's the grf-local id
16:23<Yexo>it mapped to the first free id openttd has, which happens to be 10
16:24<@Alberth>ah, forgot about that one
16:24<Yexo>you can have multiple newgrfs using id 0 locally and they won't conflict
16:24<Zuu>Yep, and that will have to be available to the compat nut files. Preferable without making it available to API 1.2?
16:24<Yexo>why does squirrel need it?
16:24<Zuu>Because old AIs will still rely on 0 being the small airport.
16:24<Yexo>can't you access all properties of id 10 through id 0?
16:25<LordAro>Alberth: 0 = 'abc\0' and 1 = 'def\0', i guess, but i don't know how to get the right characters into the right chars
16:25<Zuu>Not if you make 0 unavailable.
16:25<Zuu>hmm, though maybe a twist can be made where information is available for 0, but it is not buildable.
16:25<@Alberth>LordAro: correct, except "abc\ndef\0" is not moved.
16:25<Yexo>LordAro: try to find some general explanation about pointers
16:26<Zuu>Since that distinction of airport types already exist although the naming of IsValidAirport really should be IsAirportBuildable.
16:26<Yexo>Zuu: make IsAirportInformationAvailable return true but IsValidAirportType return false?
16:27<Yexo>hmm, that's not exactly how IsAirportInformationAvailable behaves now
16:27<LordAro>Alberth: so the string becomes 'abc\0def\0' ?
16:28<Zuu>hmm, no that will not do it.
16:28<Yexo>Zuu: main question: do we actually want to convert the 0 to 10 transparently?
16:28<Yexo>since id 10 might be an override of the small airport that only provides a 90 degree rotation but not the original rotation
16:28<Yexo>that will throw old AIs that make assumptions about the airports off as well
16:28<Zuu>For compat 0.7 to 1.1 we must translate 0 to 10 transparently or all existing aircraft AIs will break.
16:28<@Alberth>LordAro: thus if readme_text = "abc\ndef\0", your code needs to do the equivalent of readme_text_lines[0] = readme_text + 0; readme_text[3] = '\0'; readme_text_lines[1] = readme_text + 4;
16:29<Yexo>existing aircraft AIs will only break when an airport newgrf is loaded
16:29<Yexo>and we can't prevent breaking them in all situations
16:29<@Alberth>LordAro: and then indeed readme_text is "abc\0def\0"
16:29<Zuu>hmm, you are right
16:29<Yexo>you can write a very small newgrf that does nothing but disable the original airports
16:29<Zuu>So you are right, the best is probably to make overriden airports simply unavailable and not provide any translation.
16:29<LordAro>Alberth: that helps enormously... i think :L
16:30<LordAro>now, how to 'automate' the '+0' and '+4'...
16:31<@Alberth>it is the index in readme_text at the start of the array, or directly after a \n
16:31<Yexo>Zuu: care to share your patch so I could test the problem with the incorrect IDs being valid?
16:34-!-pugi [] has joined #openttd
16:34<andythenorth>palette issues are really boring :P
16:34<@Alberth>load in gimp, load new palette?
16:35<Zuu>Yexo: Here is a test AI that first prints all airport types and then build airport type 40 at the location where you place signs (cheat to AI company):
16:36<Zuu>It requires the patch that I will send you just in a moment.
16:40<Yexo>Zuu: that AI will keep busy-looping without any sleep as soon as the signlist is empty
16:41<Yexo>the //Keep alive lines are never reached
16:43<Zuu> <-- patch + new source files (in a directory so no lose files when untaring)
16:43<Zuu>Yexo: You are right, the keep alive is there as a base from another test AI.
16:43<Zuu>As well as the valuator function that is not used.
16:44<CIA-2>OpenTTD: alberth * r22760 /trunk/src/newgrf.cpp: -Fix (r19459): Also free allocated depot tables.
16:45<Zuu>That test AI is ment as a workbench for testing my work on the airport API.
16:46<Yexo>it's not a big problem or anything, just wanted to mention that your AIController.Sleep(1) is inside the inner loop while it should be outside
16:47<Yexo>every call to BUildAirport will make the AI sleep for the rest of the tick already
16:48-!-Mucht [] has joined #openttd
16:50<Zuu>You are right. Especially as it now slows down a debug build of OpenTTD when there are no signs.
16:51-!-andythenorth [] has quit [Quit: andythenorth]
16:51-!-valhallasw [] has quit [Ping timeout: 480 seconds]
16:53-!-Alberth [] has left #openttd []
16:54<Yexo>Zuu: IsAirportInformationAvailable contains a bug
16:54<CIA-2>OpenTTD: planetmaker * r22761 /trunk/src/viewport.cpp: -Fix (r22708): Make invisible signs un-clickable (Zuu)
16:54<Yexo>AirportSpec::Get(index) first checks if index is a valid airport, if not it assumes it was valid before and it will return the substitute type as previously indicated by the newgrf
16:54<Yexo>which due to the memset is 0
16:55<Yexo>hence it'll return the AirportSpec* of the small airport, which is enabled
16:55<Yexo>so AirportSpec::Get(type)->enabled will be true even for invalid types
16:55-!-beijingguy [] has joined #openttd
16:57<@planetmaker>thanks Zuu :-)
16:57<@planetmaker>good night
16:59<Zuu>planetmaker: thanks for commiting :-)
17:01-!-Juo [] has quit [Quit: Juo]
17:03<frosch123>oh, ai stuff...
17:03<frosch123>Yexo: have you seen fs#4702?
17:04<Yexo>yes, your patch looks good, although I'd change the wording somewhat
17:05<Yexo>something like: "If a station sign would be on this tile, the servicing quality of the station would influence the rating of the town"
17:05-!-KouDy [~KouDy@] has quit [Read error: Connection reset by peer]
17:05<Yexo>since your new sentence has the same problem as the original one, it's unclear that it's only about the station sign, not whether the tile is part of a bigger station
17:06<Zuu>Hmm, what if AirportSpec::Get(index) would only return the substitute airport if the type that index refer to is enabled? Otherwise 0 (null).
17:06-!-KouDy [~KouDy@] has joined #openttd
17:06<Yexo>but if the type the index refers to is enabled there is no reason at all to return the substitute airport
17:06<frosch123>Yexo: btw. do you have an idea why ai_company.hpp.sq gets updated?
17:07<frosch123>the functions are reordered and there is a template more
17:08<Yexo>no clue
17:08<frosch123>the reordering actually matched the hpp, so that is fine
17:08<frosch123>but the additional templates confuse me :p
17:08<Zuu>Yexo: I see now, that propose would likely disable the override NewGRF feature.
17:09<Yexo>probably the last person to update the hpp file didn't update the .hpp.sq correctly
17:09<frosch123>ah, they are added because of the additional enum
17:10<Yexo>my guess: I took the patch from Morloth for r22584 including the changes to .hpp.sq file which he probably made manually
17:14<Zuu>I guess the most clean solution to the AI airport issue is to set more sane defaluts to the >= 10 airport specs than just all-zero.
17:14<Yexo>Zuu: a fix requires thinking about what OpenTTD should do when an airport newgrf is unavailable, and I'm currently not able to think clearly enough for that :p
17:14<CIA-2>OpenTTD: frosch * r22762 /trunk/src/ai/api/ai_company.hpp.sq: -Fix (r22584): Update ai_company.hpp.sq
17:17<Zuu>I think for airports >= 10, that has not been defined by an NewGRF should not be available. I now think that setting substitute ID to AT_INVALID would be good.
17:18<Yexo>Zuu: yes, or this:
17:18<CIA-2>OpenTTD: frosch * r22763 /trunk/src/ai/api/ (ai_station.hpp ai_tile.hpp ai_town.hpp): -Fix [FS#4702]: Clarify the meaning of AIStation::IsWithinTownInfluence(), AITile::IsWithinTownInfluence() and AITown::IsWithinTownInfluence().
17:19<CIA-2>OpenTTD: frosch * r22764 /trunk/src/ai/api/ (ai_changelog.hpp ai_tile.cpp ai_tile.hpp ai_tile.hpp.sq): -Add: [NoAI] AITile::GetTownAuthority().
17:19<Zuu>Yexo: That looks good. I haven't worked enough with the internals with respect of NewGRFs yet, but your code makes sense.
17:19<Yexo>that seems to work when no newgrfs are loaded
17:20<Yexo>with opengfx+airports loaded both 0 and 10 are reported as buildable, which is not correct
17:20<Yexo>night frosch123
17:20-!-frosch123 [] has quit [Remote host closed the connection]
17:20<Zuu>I read your code after the || as: when a airport type does not refer to a NewGRF
17:21<Yexo>it's basically that: when this type has ever been defined by a newgrf (doesn't matter whether it has valid data now or not)
17:21<Zuu>Leaving it up to the NewGRF to provide sane data.
17:21<Zuu>But thats probably okay.
17:22<Zuu>After all there is lots of room for NewGRFs to provide insane data ;-)
17:22<Yexo>ok, fixed the check
17:22<Yexo>the idea was good, but the code wasn't
17:23<Yexo>it worked, but not in all cases
17:23<Yexo>still this is more a quickfix than a good solution
17:23<Yexo>need to think more about AirportSpec::Get()
17:23<Zuu>Still, I'm interested why type 11 to 18 are reported as non-available but not those 19 and above. (with OpenGFX+Airports)
17:26<Zuu>Could be that there is some code in that NewGRF that defines dummy airports for the other types. Especially since 11 to 18 is exactly the same amount as 1 to 8 (the unavailable default airports)
17:26<Yexo> types 11 to 18 are non-buildable due to their year requirements
17:27<Yexo>types 19 and above are so invalid that AirportSpec::Get() will actually return the AirportSpec from their substitute, which is the default airport due to zeroing the array
17:27<Yexo>s/default airport/small airport
17:27<Yexo>the small airport is actually buildable ;)
17:27<Zuu>Yea as we found out :-)
17:28<Yexo>opengfx+airports defines more than just the small airport
17:28<Yexo>it redefines all default airports with snowy versions
17:28<Zuu>that's what I didn't think of first.
17:28-!-KouDy [~KouDy@] has quit [Quit: Leaving.]
17:28<Yexo>for me (in 1960) airports 0, 1, 10, 12 and 19+ are buildable
17:28<Zuu>Only considered the small one as it got a rotation, but the snowy versions of course also requires to be defined.
17:30-!-JVassie [] has quit [Ping timeout: 480 seconds]
17:56-!-JVassie [~James@] has joined #openttd
17:59<LordAro>night all
18:00-!-LordAro [] has quit [Quit: "Time is an illusion. Lunchtime doubly so."]
18:05-!-beijingguy [] has left #openttd []
18:08-!-Lakie [~Lakie@] has quit [Quit: Sleep.]
18:14<Terkhen>good night
18:20*Zuu just discovered that you can insert a patch in the queue, not just adding new ones at the end
18:21<Zuu>(for hg that is)
18:23-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:27-!-Phoenix_the_II [] has joined #openttd
18:35-!-sla_ro|master [~slaco@] has quit []
18:37-!-Cybertinus [] has quit [Remote host closed the connection]
18:43-!-lugo [bnc4free@] has joined #openttd
18:53-!-aditsu [] has left #openttd []
19:07-!-Mucht [] has quit [Remote host closed the connection]
19:13-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
19:23-!-perk11 [] has quit [Ping timeout: 480 seconds]
19:31-!-perk11 [] has joined #openttd
19:38-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
19:43-!-KritiK [] has quit [Quit: Leaving]
19:43-!-Zuu [] has quit [Quit: Leaving]
19:50-!-DanMacK [] has joined #openttd
19:50<DanMacK>Hey all
19:51-!-DanMacK [] has quit []
19:52-!-ar3k [] has quit [Read error: Connection reset by peer]
19:52-!-ar3k [] has joined #openttd
19:52-!-ar3k is now known as ar3kaw
20:00-!-Progman [] has quit [Remote host closed the connection]
20:11-!-sllide [] has joined #openttd
20:21-!-ar3k [] has joined #openttd
20:22-!-mattt_ [] has joined #openttd
20:24-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
20:28-!-ar3kaw [] has quit [Ping timeout: 480 seconds]
20:29-!-sliddy [] has joined #openttd
20:29-!-sllide [] has quit [Read error: Connection reset by peer]
20:41-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
21:44-!-douknoukem [~KEM@] has quit [Ping timeout: 480 seconds]
21:50-!-sliddy [] has quit [Ping timeout: 480 seconds]
22:25-!-rhaeder [] has joined #openttd
22:31-!-rhaeder1 [] has quit [Ping timeout: 480 seconds]
22:33-!-fjb [] has quit [Ping timeout: 480 seconds]
22:56-!-bryjen [~bryjen@] has joined #openttd
23:07-!-Brianetta [] has quit [Quit: Tschüß]
23:08-!-mattt_ [] has quit [Quit: mattt_]
23:29-!-glx [glx@2a01:e35:2f59:c7c0:511c:4bae:adaa:fd7c] has quit [Quit: bye]
23:32-!-bryjen [~bryjen@] has quit [Quit: Leaving]
---Logclosed Sat Aug 20 00:00:36 2011