Config
Log for #openttd on 28th September 2014:
Times are UTC Toggle Colours
00:07:29  *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.vic.bigpond.net.au] has joined #openttd
00:23:01  *** Jiinxs [~Jiinxs@ti0038a400-0515.bb.online.no] has quit []
00:23:48  *** fjb is now known as Guest1094
00:23:49  *** fjb [~frank@000158aa.user.oftc.net] has joined #openttd
00:30:48  *** Guest1094 [~frank@000158aa.user.oftc.net] has quit [Ping timeout: 480 seconds]
00:53:19  *** Djohaal [~Djohaal@177.40.5.115] has joined #openttd
01:04:48  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
01:09:25  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
01:13:11  *** Djohaal [~Djohaal@177.40.5.115] has quit [Read error: Connection reset by peer]
01:25:18  *** InvokeStatic [~Invoke@c-24-11-157-247.hsd1.mi.comcast.net] has joined #openttd
01:25:18  *** InvokeStatic_ [~Invoke@c-24-11-157-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer]
01:28:34  *** InvokeStatic_ [~Invoke@c-24-11-157-247.hsd1.mi.comcast.net] has joined #openttd
01:28:34  *** InvokeStatic [~Invoke@c-24-11-157-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer]
01:41:58  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
01:50:09  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
02:00:04  *** MJP [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds]
02:18:37  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
02:22:06  *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
02:32:22  *** abchirk_ [~abchirk@p57A0AB57.dip0.t-ipconnect.de] has joined #openttd
02:38:59  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
02:39:38  *** Jomann [~abchirk@p57A0849B.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
02:46:42  *** Celestar [~Celestar@p5DE4535C.dip0.t-ipconnect.de] has joined #openttd
03:07:29  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
03:10:49  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
03:25:17  *** Celestar [~Celestar@p5DE4535C.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
04:11:14  *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd
04:17:37  *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds]
04:45:18  <Rubidium> argoneus: somewhere in the order of 1500 bytes is the maximum packet size openttd will send
04:45:51  <Rubidium> also recv might get only a partial packet (or multiple packets)
04:46:33  <Rubidium> since the underlying network layer is free to merge the "openttd packets" (or split them up)
04:47:43  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
04:56:01  *** Eddi|zuHause [~johekr@p57BD48CB.dip0.t-ipconnect.de] has quit []
04:56:20  *** Eddi|zuHause [~johekr@p5DC66BC3.dip0.t-ipconnect.de] has joined #openttd
05:08:59  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
05:41:04  *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
06:01:36  *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
06:02:08  <andythenorth> I never knew tree growth was such a big deal
06:03:47  <Supercheese> It apparently greatly affects savegame size
06:06:48  <Rubidium> if it greatly affects your savegame size, then your map isn't finished by a long shot and you probably took a too large map size ;)
06:10:06  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
06:10:33  <Rubidium> also... how is the Latin translation going?
06:13:28  *** Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has quit [Ping timeout: 480 seconds]
06:13:39  *** Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has joined #openttd
06:16:46  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
06:18:45  <andythenorth> my trees are always transparent
06:18:55  <andythenorth> I should just start maps with trees off :P
06:18:58  *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd
06:19:26  <Rubidium> andythenorth: without trees and with the tree growth disabled ;)
06:19:35  <andythenorth> as the conclusion of the thread is that none of the current map gen settings are not good enough
06:19:44  <andythenorth> I would just remove the option from the map gen window
06:20:05  <andythenorth> the root cause of the problem is that the players don’t like the options
06:20:07  <andythenorth> so remove the options :P
06:26:06  <andythenorth> this is why andythenorth never gets commit rights
06:45:13  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
06:56:54  <Supercheese> Latin translation is nearly finished
06:57:20  <Supercheese> I'm just having issues trying to translate signals... block signals, path signals
06:57:37  <Supercheese> I wonder if some 19th century railroad texts exist in Latin
06:57:45  <Supercheese> something with sufficient terminology
07:00:04  *** Speedy` [~speedy@the.wrong.domain.name] has joined #openttd
07:00:21  *** Speedy` is now known as Speedy
07:03:22  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
07:03:26  *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
07:03:29  *** mode/#openttd [+o Alberth] by ChanServ
07:04:24  <Supercheese> the Latin wikipedia sadly is lacking in signaling terms
07:04:38  <Supercheese> as are all my school textbooks
07:06:23  <Rubidium> http://la.wikipedia.org/wiki/Semaphorum ?
07:07:38  <Supercheese> Yes, but then what is a "block signal
07:07:40  <Supercheese> "
07:07:51  <Supercheese> vs. other signals
07:08:15  <Supercheese> and then how to distinguish between semaphores (semaphora) and other signals (semaphora)...
07:08:27  <Supercheese> other/electric
07:08:44  <Rubidium> mechanical vs electrical?
07:08:44  <Supercheese> semaphora electrica, well could just be electrically-operated semaphores...
07:09:09  <Supercheese> and long-winded
07:09:41  <Supercheese> also I have been lucky enough to find prior references for translating modern terms for nearly everything except railroad signalling
07:10:04  <Supercheese> even monorail had a latin translation, surprisingly
07:10:56  <sla_ro|master> is there a latin translation for openttd?
07:10:58  <Rubidium> too bad Poland stopped using Latin in the 18th century
07:11:14  <Supercheese> sla_ro|master: There is on my hard drive, and will be available for proofreading shortly
07:11:27  <sla_ro|master> ah, well, not goin' to use it, but that's cool and weird :P
07:11:51  <sla_ro|master> well I speak a latin language who is supported by openttd
07:11:58  <sla_ro|master> so I don't need latin itself
07:16:18  *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer]
07:16:23  <Rubidium> http://en.wikipedia.org/wiki/Nuntii_Latini <- to bad I couldn't see anything about mentioning signalling failures or so (and the amount of news items per week makes it unlikely that they even exist)
07:16:43  <Supercheese> Yeah their broadcasts do not have comprehensive transcripts
07:16:55  <Supercheese> however, I could trawl their archives for some
07:16:58  <planetmaker> moin
07:17:39  <Rubidium> the question is whether they might know the wording
07:18:22  <Supercheese> I could ask my professor, I suppose, although we've no trains anywhere around here ...
07:18:43  *** KouDy [~koudy@188.75.190.58] has quit [Ping timeout: 480 seconds]
07:20:22  <Supercheese> oh also cargo distribution stuff... ugh last hurdle
07:20:30  <Rubidium> mechanical signals (on wikipedia at least) refer to the semaphores, the others are light signals
07:20:57  <Supercheese> Yeah I'll just have to tack on adjectives
07:21:27  <Supercheese> bleeeeh stupid CargoDist helptexts
07:21:34  <Supercheese> I don't even use cargodist
07:22:34  <Supercheese> they are also the longest strings in OTTD
07:23:27  <planetmaker> the short ones were already used up ;)
07:23:47  <Supercheese> STR_CONFIG_SETTING_SHORT_PATH_SATURATION_HELPTEXT weighs in at 703 characters
07:25:06  <Alberth> unless you make an in-game manual, there is no other good place, probably
07:25:50  * Supercheese debates translating them all as "Noli id uti" :P
07:26:08  <planetmaker> :P
07:28:55  <Supercheese> or I suppose "eo uti"
07:29:15  <Supercheese> dictionary is sending mixed signals
07:31:06  <Rubidium> use that for "combo signals" ;)
07:31:16  <Supercheese> oh definitely
07:31:33  <Supercheese> "Hoc adhibendum non est"
07:31:51  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
07:32:01  *** Haube [~michi@ip25048c11.dynamic.kabel-deutschland.de] has joined #openttd
07:35:33  *** Pensacola [~quassel@h220149.upc-h.chello.nl] has joined #openttd
07:37:35  <peter1138> And semaphore signals can have lights too...
07:39:01  <Supercheese> It's a bit of a sticky wicket
07:39:28  <Supercheese> some chap decided that signal and semaphore would be the same word in Latin
07:40:24  <peter1138> That's the problem with a dead language, it doesn't evolve.
07:43:51  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
07:47:13  <Supercheese> Wait did the Harry Potter railway ever mention signals?
07:47:28  <Supercheese> The first two books have official Latin translations
07:47:41  <V453000> why do you translate to latin anyway
07:47:43  <V453000> sounds useless
07:47:46  <Supercheese> and Ancient Greek too, I believe
07:47:50  <Alberth> I wondered about that too :)
07:48:03  <Alberth> maybe they missed Klingon?
07:48:09  <peter1138> There was that pig-latin translation once...
07:49:45  <__ln__> Supercheese: since it's not on webtranslator, do you have a backup copy of the translation somewhere? it would be a great pity if all work was lost due to hard disk failure.
07:49:46  <Haube> Egyptian Hieroglyphs would be nice too, but then i would want to carry stones around ;)
07:50:05  <Supercheese> __ln__: Yes it is also synched to my Google drive
07:50:22  <Supercheese> after you last mentioned I should have a backup, in fact :)
07:51:39  <__ln__> good, yes, i remember asking that earlier too :)
07:52:47  *** moffi [~moffi@dsdf-4d0a49d2.pool.mediaWays.net] has joined #openttd
07:53:58  <Supercheese> I dunno, I think it'd be a lot cooler if we called it "hamaxostichus" instead of boring old "train"
07:54:07  <Supercheese> it's a fun word
08:08:35  <Supercheese> "Loading {1:STRING} as static NewGRF with {STRING} could cause desyncs"   Oh goodness
08:11:25  <Supercheese> actually that wasn't so bad
08:11:39  <__ln__> what's NewGRF in latin?
08:11:43  <Supercheese> NewGRF  :P
08:11:57  <Supercheese> like with every other language
08:12:00  *** Yotson [~Yotson@2001:980:6ac8:1:95fa:dab6:c6ec:9f37] has joined #openttd
08:12:17  * Supercheese wonders if any of them actually change it
08:12:58  <Supercheese> even Cyrillic languages keep it
08:13:30  <Supercheese> and Japanese
08:13:46  <__ln__> even latvian
08:15:27  <Rubidium> not something like novum ludum opem tabularium ?
08:15:33  <__ln__> ha, in hebrew it's not NewGRF in all messages at least.
08:15:47  <Supercheese> well, they've even flipped text direction
08:16:12  <Supercheese> and it seems to be still NewGRF
08:16:28  <Supercheese> 159 matches to that
08:17:13  <Supercheese> wait, I had match case off
08:17:45  <Supercheese> 35, yeah it has fewer
08:18:05  <Supercheese> perhaps there are untranslated strings though
08:22:30  *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
08:22:57  <Wolf01> hi hi
08:29:55  <Wolf01> mmmh
08:30:07  <planetmaker> hi hi
08:30:10  <Wolf01> reg query finds the key, reg delete no
08:36:22  <Alberth> o/
08:41:40  <Supercheese> Hmm, can genders be passed through twice?
08:42:16  <Supercheese> e.g. STR_QUANTITY_GRAIN has "{WEIGHT_LONG} frumenti"
08:42:33  <Supercheese> and the weight string is grabbed as "{G=n}{COMMA}{NBSP}chiliogramma{P "" ta}"
08:43:00  <Supercheese> will the neutral gender be passed through to STR_QUANTITY_GRAIN, and it will inherit the gender?
08:43:15  <Rubidium> I'm not sure
08:43:49  <Rubidium> and maybe though the caller might need to do {G 0:1 ...} or something, but I guess you need to experiment with that
08:44:45  <Supercheese> Yes, although I don't know how I'll get town growth strings to cooperate
08:44:50  <Supercheese> guess I need a game script
08:45:29  <Supercheese> or bin the whole thing and use verbs instead of adjectives
08:46:48  <Rubidium> don't towns in deserts / snowy areas already use those strings?
08:47:51  <Supercheese> not the specific-quantity-of-stuff strings
08:48:03  * Supercheese will just use verbs anyway
08:48:44  <Supercheese> I'm not really sure what uses the "demands X amount of stuff" town growth strings
08:48:53  * Supercheese digs source
08:49:16  <planetmaker> game scripts
08:49:22  <Supercheese> as I thought
08:51:14  <peter1138> Bah, it's hard to diagnose the engine preview window :p
08:58:12  <Supercheese> There still is no notification for new wagons...
08:58:33  <Supercheese> although there is Ye Olde Patche for That™
08:59:41  <V453000> is there any way to make the sprite aligner work with EZ?
08:59:46  <Supercheese> and to be fair, introduction of the first monorail would cause a spam of monorail wagon notices...
08:59:48  <V453000> like move sprites by 1 pixel not 4
09:00:39  <V453000> I dont need it for code offset, just for sprite editing ... so the 1 offset value being 4 pixels isnt helping :D
09:01:55  *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
09:02:16  * Supercheese should sleep
09:02:18  <DorpsGek> Commit by peter1138 :: r26933 trunk/src/engine_gui.cpp (2014-09-28 09:02:11 UTC)
09:02:19  <DorpsGek> -Codechange: Resize engine preview window to fit vehicle sprite.
09:02:29  <Supercheese> valete amici
09:02:41  *** Supercheese [~Superchee@76.178.136.186] has quit [Quit: Valete omnes]
09:07:33  <planetmaker> V453000, no. Sprites for all zoom levels follow the same alignment. Thus you align in the 1x zoom and it must fit the others
09:08:07  <V453000> hm
09:08:43  <V453000> well yeah but the sprites can be sub-4px misaligned :P
09:09:00  <planetmaker> no, it can't. As it's just 2x or 4x zoomed-in
09:09:21  <planetmaker> thus a 1px alignment is then zoomed-in,too, and proportionally enlarged
09:09:35  <V453000> that isnt a question of coding, that is a question of how you create the sprites
09:10:23  <Eddi|zuHause> Bad_Brett certainly made his vehicles move on sub-4px-level
09:10:45  <V453000> am concerned about landscape atm
09:10:47  <V453000> (is hell)
09:11:52  <peter1138> planetmaker, well the code takes 4x zoomed in as ZOOM_LVL_NORMAL, so "1x" sprites are actually ZOOM_LVL_OUT_4X
09:11:55  <planetmaker> Eddi|zuHause, wasn't that patched source which made that possible?
09:12:33  <Alberth> yep
09:12:33  <Eddi|zuHause> planetmaker: only reading the vehicle position needed some unimplemented variable
09:12:46  <Eddi|zuHause> everything else is "stock"
09:15:18  <peter1138> Let's just increase that 16 to 64 ;)
09:15:51  <peter1138> Or more, because even 16 isn't quite enough at old-1x
09:18:02  <Eddi|zuHause> peter1138: each of these 16 steps has already 256 substeps
09:18:13  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
09:19:26  <Eddi|zuHause> (or maybe 192 on diagonals)
09:20:30  <peter1138> Eddi|zuHause, they're not visual though
09:21:58  <DorpsGek> Commit by peter1138 :: r26934 trunk/src/engine_gui.cpp (2014-09-28 09:21:51 UTC)
09:21:59  <DorpsGek> -Fix (r26933): Don't statically initialise non-static variables.
09:22:03  <Eddi|zuHause> yes. but that missing variable allowed the newgrf to offer that visualisation
09:22:23  <peter1138> yes, but that means the newgrf has to put in a lot of hard work to do it.
09:22:31  <peter1138> if the game just did it itself... much simpler
09:22:34  *** moffi2 [~moffi@dsdf-4db5eb94.pool.mediaWays.net] has joined #openttd
09:26:22  <Eddi|zuHause> but you can't just multiply existing stuff, or you potentially break things that rely on motion counter
09:26:31  *** moffi [~moffi@dsdf-4d0a49d2.pool.mediaWays.net] has quit [Ping timeout: 480 seconds]
09:26:46  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
09:27:19  <peter1138> You can divide to get the motion counter
09:29:18  <Eddi|zuHause> peter1138: but then you need two motion counters. an old and a new one
09:29:47  <peter1138> welcome to backwards compatibility
09:30:23  <Eddi|zuHause> peter1138: also, while making such a fundamental change, better fix diagonal motion and length distortion
09:30:55  *** HerzogDeXtEr [~flex@i59F6DB76.versanet.de] has joined #openttd
09:31:22  <peter1138> that's one of the reasons to change it :p
09:32:44  <Eddi|zuHause> but then you break every NewGRF that uses 32px vehicles.
09:33:25  <Eddi|zuHause> which is every NewGRF in the last 8 years...
09:34:36  <andythenorth> \o/
09:34:54  <andythenorth> no more BAD FEATURES
09:35:20  <Eddi|zuHause> andythenorth: is that like "world peace"?
09:35:29  <andythenorth> yup
09:35:33  <andythenorth> and roadtypes
09:37:14  <V453000> hm, "how to make landscape" :d
09:41:31  *** Pikkaphone [~yaaic@58.108.147.18] has joined #openttd
09:41:35  <andythenorth> oh look
09:41:47  <andythenorth> then there was trouble
09:41:48  <Pikkaphone> where?
09:42:09  <andythenorth> yes
09:42:11  <Pikkaphone> trouble is as trouble does
09:42:41  <Pikkaphone> any more hogs yet?
09:42:56  <andythenorth> loads
09:43:04  <andythenorth> if a ‘standard’ truck is 30t
09:43:13  <andythenorth> how big should a mining or logging truck be for same era?
09:43:18  <andythenorth> this is brit-ish-ish
09:43:29  <Pikkaphone> 50?
09:43:35  <andythenorth> you have the jackpot
09:43:39  <andythenorth> that was my guess too
09:43:45  <Pikkaphone> huzzah
09:43:51  <andythenorth> family fortunes
09:43:54  *** b_jonas_ is now known as b_jonas
09:43:58  <Rubidium> long, short or metric t?
09:44:01  <andythenorth> yes
09:44:36  <andythenorth> when I am looking at realisms, I pick the type of ton/tonner that suits the number I want
09:44:50  <andythenorth> usually the one that gives the highest number :P
09:44:55  <andythenorth> -r
09:46:14  <Pikkaphone> but why look at realisms?
09:48:15  <andythenorth> can’t help it
09:48:19  <andythenorth> compulsive
09:48:21  <andythenorth> low imagination
09:48:42  <Pikkaphone> nuclear powered hover hogs?
09:49:08  <andythenorth> only with cabeese
09:49:12  <Pikkaphone> horse drawn, naturally
09:50:36  <Pikkaphone> and animated rivets
09:52:14  <andythenorth> I was thinking about horse-drawn cabeese
09:53:48  <andythenorth> I think that would be mornington crescent
09:54:14  <Pikkaphone> yes
09:56:30  *** Pikkaphone2 [~yaaic@203-206-161-219.perm.iinet.net.au] has joined #openttd
09:56:40  <Pikkaphone2> whoosh
09:59:21  <Eddi|zuHause> what?
09:59:40  <Eddi|zuHause> are you two still speaking english?
10:02:00  <Pikkaphone2> http://en.m.wikipedia.org/wiki/Mornington_Crescent_(game)
10:02:07  <Pikkaphone2> if that helps
10:02:17  <Pikkaphone2> which it probably doesn't
10:02:18  *** Pikkaphone [~yaaic@58.108.147.18] has quit [Ping timeout: 480 seconds]
10:04:30  <andythenorth> Pikkaphone2: so how big is this? https://c2.staticflickr.com/4/3713/9169045063_52940483b2_z.jpg
10:04:33  <andythenorth> in tons or tonnes?
10:05:38  *** TorCoolguy_ [~ray@72.31.21.45] has joined #openttd
10:05:38  *** TorCoolguy [~ray@72.31.21.45] has quit [Read error: Connection reset by peer]
10:05:38  *** TorCoolguy_ is now known as TorCoolguy
10:06:00  <Pikkaphone2> 75? 90?
10:06:04  <andythenorth> 75
10:06:09  <andythenorth> another prize
10:06:12  <andythenorth> we’re doing well
10:06:19  <Pikkaphone2> is it slow?
10:06:24  <andythenorth> dunno
10:06:25  <Eddi|zuHause> that sounds awfully large
10:06:38  <andythenorth> awfully
10:06:44  <Eddi|zuHause> especially for the low number of axles
10:06:49  <Pikkaphone2> 3 train cars
10:06:54  <andythenorth> 4 tram cars
10:07:04  <Pikkaphone2> I measure everything in train cars now
10:07:43  <andythenorth> metric or imperial?
10:07:48  <Eddi|zuHause> a train car has four axles with 20t each, so 80t, about 20t of which are its own weight
10:07:55  <Eddi|zuHause> so 1 train car is 60t coal
10:08:18  <andythenorth> Eddi|zuHause: I think you’re confusing metric and imperial train cars
10:08:30  <Eddi|zuHause> rounding errors
10:09:00  <Pikkaphone2> also too many realisms
10:09:49  <Pikkaphone2> a TTD traincar carries 25-30t
10:10:00  <Pikkaphone2> nuff said
10:10:03  <andythenorth> do you have any cheese?
10:10:16  <Pikkaphone2> only on pizza
10:10:21  <Pikkaphone2> bbl
10:10:26  *** Pikkaphone2 [~yaaic@203-206-161-219.perm.iinet.net.au] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
10:11:06  <andythenorth> bye pikkaphone2
10:11:15  <andythenorth> although I preferred the original tbh
10:11:38  <Eddi|zuHause> and the pikkaphone6 bends?
10:11:42  <andythenorth> ha
10:11:50  *** Myhorta[1] [~Myhorta@2001:8a0:ed44:5b01:f947:9adb:1806:b97a] has joined #openttd
10:12:08  <Eddi|zuHause> http://i.imgur.com/xsf6zsj.png
10:12:13  <andythenorth> wonder if my phone bends
10:12:58  <Rubidium> don't worry, it does
10:13:02  <Rubidium> it also does blend
10:13:05  <andythenorth> it flexes
10:13:36  <Eddi|zuHause> with muscles and all?
10:13:38  <andythenorth> is inelastic deformation bending?
10:14:06  <Eddi|zuHause> no
10:14:21  <Eddi|zuHause> there is elastic bending, and there's inelastic deformation that is not bending
10:14:35  <andythenorth> pretty certain that my phone
10:14:49  <andythenorth> will flex until the inelastic deformation limit is reached
10:14:55  <andythenorth> then it will increase the component count
10:15:12  <Alberth> puzzle time!
10:16:03  *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
10:16:03  <andythenorth> I don’t see the problem tbh
10:16:19  <andythenorth> we have loads of metal-bodied mac laptops that are bent
10:16:30  <andythenorth> people put them in their pockets, forget, sit down...
10:16:49  <Alberth> they are too small :p
10:16:54  <andythenorth> bending is a feature
10:17:49  <andythenorth> also bbl
10:17:50  *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
10:20:20  <Eddi|zuHause> i don't see the problem either.
10:20:39  <Eddi|zuHause> i have no smartphone, and no mac laptop either
10:39:41  *** frosch123 [~frosch@frnk-4d01d1f1.pool.mediaWays.net] has joined #openttd
10:41:56  *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd
10:49:38  <argoneus> Rubidium: ah, thanks! is this something you know or is this documented somewhere?
10:52:42  *** arroyoc [~Thunderbi@169.pool85-57-219.dynamic.orange.es] has joined #openttd
10:53:53  *** arroyoc [~Thunderbi@169.pool85-57-219.dynamic.orange.es] has quit []
10:55:56  <Rubidium> argoneus: http://vcs.openttd.org/svn/browser/trunk/src/network/core/tcp_admin.h + http://vcs.openttd.org/svn/browser/trunk/src/network/core/packet.h#L55 + http://vcs.openttd.org/svn/browser/trunk/src/network/core/config.h#L35
10:56:23  *** MJP [~mjp@hq.z77.fr] has joined #openttd
10:59:50  <argoneus> Rubidium: ah, I see
11:00:06  <argoneus> SEND_MTU = 1460 // the maximum number of bytes we can pack in a single packet
11:00:37  <Rubidium> but as said before, assume the worst (network corruption or evil wise)
11:00:56  <argoneus> thing is I have no clue if ottd appends some sort of delimiter to each message or not
11:01:08  <argoneus> I was trying to find the code that actually sends packets and couldn't find it
11:02:33  <Rubidium> it doesn't
11:02:58  <Rubidium> it has a header though
11:04:16  <Rubidium> see packet.h and packet.cpp
11:12:09  <argoneus> Rubidium: from what I am seeing, it just asserts that the data isn't larger than 1460 bytes, no?
11:12:40  <argoneus> so it should always send no more than that, and the tcp protocol guarantees I get correct data, no?
11:12:49  <Rubidium> when sending data out, yet... but not when receiving
11:13:05  <argoneus> or does tcp only make sure you receive -something-/
11:13:58  <Rubidium> there is some error checking, but there is no guarantee
11:17:32  <argoneus> Rubidium: I still don't get it :( in packet.cpp at l179, it just kicks you off if you send too much data
11:18:39  <Eddi|zuHause> argoneus: always assume the other side didn't implement the protocol correctly
11:19:02  <Eddi|zuHause> argoneus: your program must accept any random set of data, and filter out the valid ones from that
11:19:35  <argoneus> but it just checks "is packet too big? nope, okay, read it"
11:19:42  <argoneus> and I don't understand
11:20:09  <argoneus> n = (uint32)this->buffer[this->pos++];
11:20:39  <argoneus> so this reads the value at the current buffer byte, and stores it in an uint?
11:20:47  <argoneus> but then, why does it go to the next byte, and bitshift it by 8
11:21:01  <argoneus> that hurts my head
11:21:20  <Eddi|zuHause> uint32 is 4 bytes, but may be big endian or little endian
11:21:32  <Eddi|zuHause> so the bytes in the buffer must be arranged correctly
11:22:06  <argoneus> isn't it little endian 99% of the time?
11:22:07  <Eddi|zuHause> can't just read 4 bytes and assume the correct value
11:22:14  <Eddi|zuHause> no.
11:23:44  <argoneus> I still fail to grasp this
11:23:59  <argoneus> you read a uint32 number, but then basically lose the first 2 bytes
11:24:04  <argoneus> by bitshifting
11:24:06  <argoneus> no?
11:24:45  <argoneus> or am I missing something major
11:25:33  <Eddi|zuHause> no. you read uint8
11:25:52  <Eddi|zuHause> and put that into an uint32
11:26:05  <Eddi|zuHause> then you read another uint8, and put that in a different position in the same uint32
11:26:08  <Eddi|zuHause> then you read another uint8, and put that in a different position in the same uint32
11:26:10  <Eddi|zuHause> ...
11:27:05  <Eddi|zuHause> the combination of all these uint8s makes up your uint32
11:30:57  <Alberth> you get a stream of bytes from the network, and have to assemble the bytes to 4 byte integers, in code that works both for little endian and big endian
11:32:27  <argoneus> wait, this byte assembling works for both LE and BE?
11:32:53  <Eddi|zuHause> yes, because the compiler knows what to do when casting uint8 to uint32, and bitshifting
11:33:01  <argoneus> ohh
11:34:04  <Eddi|zuHause> and LE/BE is known to the compiler
11:34:07  <argoneus> I see
11:37:32  <Eddi|zuHause> 13:37, good time as any to go out...
11:38:03  <argoneus> hm
11:38:08  <argoneus> so apparently big endian is the standard with networking
11:38:12  <argoneus> TIL
11:38:57  <Alberth> openttd may use it, that doesn't make it a standard in networking in general :)
11:39:21  <argoneus> nono
11:39:27  <argoneus> there is some RFC that defines big endian as standard
11:39:33  <Alberth> ah, ok
11:39:49  <Eddi|zuHause> big endian is the more logical one if you come from a non-hardware-design perspective
11:40:30  <argoneus> big endian is the one where if I have 1111 0000 0000 1111, it will be stored as F00F ?
11:40:44  <argoneus> aka the intuitive way
11:40:51  <Eddi|zuHause> yes
11:41:07  <argoneus> then I have to wonder
11:41:15  <argoneus> why libottdadmin2 explicitely forces little endian
11:41:24  <argoneus> and even defines its own Struct for that
11:41:47  *** KouDy [~koudy@188.75.190.58] has joined #openttd
11:41:54  <Eddi|zuHause> most common (RIFF) file formats are little endian
11:42:11  <argoneus> yes, but
11:42:41  <argoneus> if openttd sends big endian packets, and is able to read both, why would you -force- LE?
11:43:00  <Eddi|zuHause> no, you got that backwards
11:43:27  <Eddi|zuHause> the computer that the code runs on can be both LE and BE. the protocol that is transmitted is always the same
11:44:17  * argoneus has never got into networking properly
11:44:25  <Eddi|zuHause> and if the protocol says to use LE, then that is what it must be.
11:44:38  <argoneus> what "protocol"?
11:44:52  <argoneus> someone here said openttd uses big endian, and TCP uses big endian too
11:45:13  <Eddi|zuHause> the "protocol" here is the admin port protocol
11:45:20  <Eddi|zuHause> it doesn't matter what TCP uses
11:45:28  <Eddi|zuHause> TCP is completely transparent to the user
11:45:57  <Eddi|zuHause> anyway... gone
11:46:20  <argoneus> ah, ok
11:46:47  <argoneus> but thanks a lot!
11:46:49  <argoneus> you've helped
11:48:43  <Alberth> admin port and server-client traffic are two independent things
11:49:06  <Alberth> there is no reason to force both to use the same encoding
11:49:32  *** Pikka [~Octomom@d58-106-46-133.rdl801.qld.optusnet.com.au] has joined #openttd
11:49:38  <Alberth> hi hi Pikka
11:49:44  <Pikka> bonjour
11:50:40  <argoneus> Alberth: consistency? :<
11:50:50  <Alberth> ha!  :)
11:59:55  <planetmaker> consistency is only for the weak-minded :P
12:01:50  <Alberth> and for companies to have meetings about :p
12:04:34  *** sla_ro|master [slamaster@95.76.27.245] has quit []
12:04:47  <Alberth> apparently someone decided otherwise at some point in the past. It's not a big problem imho, just abstract it away to "write stuff to the network" and "read stuff from the network", and it's solved :)
12:07:59  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
12:13:57  <Rubidium> arguably the endianness of ALL OpenTTD binary network protocols is the same
12:14:43  <Rubidium> mostly because all use Packet which kinda makes it cumbersome to not use the protocol endianness of Packet
12:15:49  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
12:23:45  *** nobrain [~oftc-webi@53552595.cm-6-6a.dynamic.ziggo.nl] has joined #openttd
12:26:50  *** nobrain [~oftc-webi@53552595.cm-6-6a.dynamic.ziggo.nl] has left #openttd []
12:44:19  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
13:07:09  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
13:12:28  *** Myhorta[1] [~Myhorta@2001:8a0:ed44:5b01:f947:9adb:1806:b97a] has quit [Ping timeout: 480 seconds]
13:30:13  *** moffi2 [~moffi@dsdf-4db5eb94.pool.mediaWays.net] has quit [Ping timeout: 480 seconds]
13:30:37  *** gelignite [~gelignite@i528C3E66.versanet.de] has joined #openttd
13:39:43  *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
13:46:56  *** moffi [~moffi@dsdf-4db5eb94.pool.mediaWays.net] has joined #openttd
13:49:08  *** DabuYu [DabuYu@128.250.79.238] has joined #openttd
13:57:54  *** TomyLobo [~foo@91.65.115.103] has joined #openttd
13:58:04  <TomyLobo> hi
13:58:31  <TomyLobo> my 4096x4096 map takes about 15 seconds to autosave. is that normal?
13:58:43  <planetmaker> slow disk and computer: why not
13:58:49  <TomyLobo> nope
13:59:19  <planetmaker> it's as huge a map as you can get. And if you're watching a stream next to and and suck dry some leet torrents...
13:59:25  <TomyLobo> it's only like 1-2 years old
13:59:38  <TomyLobo> and no i dont
13:59:59  <LordAro> saving a 4kx4k map is *going* to be slow
14:00:05  <LordAro> there's not much you can do about that
14:00:14  <TomyLobo> the worst thing that's running is steam but that's not loading anything right now
14:00:27  <planetmaker> not even downloading?
14:00:42  <planetmaker> it's known to auto-update stuff
14:01:00  <TomyLobo> i would see that
14:01:13  <TomyLobo> i know computers
14:03:02  <planetmaker> maybe you're also out-of ram and it needs to swap a lot
14:03:15  <TomyLobo> 49% physical memory
14:03:17  <planetmaker> as it first needs to make a complete copy of the map and then saves the copy
14:03:41  <TomyLobo> openttd takes 387 mb right now
14:03:47  <TomyLobo> i have 8gb
14:04:05  <TomyLobo> i doubt it makes a dent :)
14:04:40  <peter1138> Yeah, 4Kx4K is quite big, and takes a while to compress.
14:09:13  <peter1138> Since when is age of the computer a good indication of its speed, anyway? :p
14:09:27  <TomyLobo> not since
14:09:36  <TomyLobo> but until netbooks came about
14:10:41  <planetmaker> so it's a 1.5 year old smartphone or tablet?
14:11:12  <TomyLobo> yes, a 1.5 year old smartphone with 8gb of ram
14:11:49  <TomyLobo> and netbooks came before smartphones and tablets, btw
14:14:06  <b_jonas> there are smartphones with 8 GB of ram?
14:14:22  <Alberth> RAM is easy and cheap
14:14:31  <b_jonas> sure, but in a smartphone too?
14:14:37  <Alberth> the question is does it have a fast CPU :p
14:14:39  <TomyLobo> b_jonas i was being sarcastic
14:14:46  <b_jonas> how's it even fit?
14:16:32  *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.vic.bigpond.net.au] has quit []
14:21:53  *** Flygon_ is now known as Flygon
14:25:00  <Flygon> Man
14:25:07  <Flygon> There's smartphones more powerful than my laptop
14:26:00  <Flygon> Now if there was x64 Smartphones
14:27:07  <FLHerne> Flygon: There are
14:27:21  <Flygon> Eksellent
14:27:32  <FLHerne> Not very many, but someone certainly made an Intel-based Android device
14:29:25  <Flygon> Man
14:29:32  <Flygon> Still waiting on looping OTTD maps
14:29:49  <Flygon> Civ II style looping  anyone?
14:29:49  <peter1138> have you got a patch for it?
14:29:52  <Flygon> World maaaaaaaaap :D
14:29:55  <Flygon> Nah
14:30:00  <peter1138> boo
14:30:00  <Flygon> I'm a lazy idiot civillian
14:30:11  <Flygon> That complains about features that are too hard to code not being in the game
14:30:28  <peter1138> yeah, sometimes i forget i was born with the ability to code
14:31:15  <Flygon> Hot dayum
14:31:17  <Flygon> Are you like
14:31:21  <Flygon> Tony Stark or something?
14:32:38  <__ln__> top
14:32:42  <__ln__> wrong window
14:33:30  <Flygon> bottom?
14:44:36  <peter1138> Generating a 4096x4096 map... reminds me of starting up Civ on my 386.
14:44:42  <peter1138> That took ages too :p
14:45:32  <Flygon> Which Civ? :D
14:45:44  <Flygon> If you want real fun
14:45:52  <Flygon> Do a