Config
Log for #openttd on 19th April 2016:
Times are UTC Toggle Colours
00:02:26  *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has quit [Ping timeout: 480 seconds]
00:02:29  *** LadyHawk- is now known as LadyHawk
00:02:43  *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
00:04:22  *** HerzogDeXtEr [~farci@i59F6CBCC.versanet.de] has quit [Read error: Connection reset by peer]
00:05:34  <Samu> hmm, i guess the name "faster server autosaves" no longer apply http://www.tt-forums.net/viewtopic.php?f=33&t=74731
00:05:46  <Samu> there's nothing about speeding up autosaves anymore :(
00:06:15  <Samu> it just speeds up all saves on servers
00:07:22  <Samu> i'm sure this approach is bad
00:07:47  <Samu> don't have much time to think now, maybe tomorrow I can come up with something better about all this
00:10:21  <Samu> point a.2) is my main concern
00:10:44  <Samu> will think about it tomorrow, cyas goodnight
00:18:57  *** Samu [~oftc-webi@po-217-129-255-23.netvisao.pt] has quit [Quit: Page closed]
00:21:17  *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has quit []
00:39:54  *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
01:00:41  *** Snail [~jacopocol@cpe-98-14-130-227.nyc.res.rr.com] has joined #openttd
01:01:17  *** supermop [~supermop@pool-100-37-203-161.nycmny.fios.verizon.net] has joined #openttd
01:02:10  *** sim-al2 is now known as Guest931
01:02:11  *** sim-al2 [~sim-al2@108-221-157-231.lightspeed.mmphtn.sbcglobal.net] has joined #openttd
01:06:39  *** Guest931 [~sim-al2@108-221-157-231.lightspeed.mmphtn.sbcglobal.net] has quit [Ping timeout: 480 seconds]
01:09:01  *** Cybertinus [~Cybertinu@cybertinus.customer.cloud.nl] has quit [Ping timeout: 480 seconds]
01:27:24  *** Myhorta[1] [~Myhorta@25.103.114.89.rev.vodafone.pt] has quit [Ping timeout: 480 seconds]
02:21:53  *** liq3 [liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has joined #openttd
02:23:58  *** liq3 [liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has quit []
02:48:24  *** skrzyp [skrzyp@188.166.115.173] has quit [Remote host closed the connection]
03:30:22  *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
03:30:44  *** Flygon_ [~Flygon@ppp118-209-238-150.lns20.mel8.internode.on.net] has joined #openttd
03:31:02  *** Clockworker__ [Clockworke@177.2.175.68] has joined #openttd
03:31:04  *** guru3_ [~guru3@109.200.19.187] has joined #openttd
03:31:22  *** Kurimus_ [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has joined #openttd
03:31:38  *** txtsd_ [~txtsd@198.23.246.143] has joined #openttd
03:34:34  *** ttech2 [~ttech@dragons.have.mostlyincorrect.info] has joined #openttd
03:35:23  *** funnel_ [~funnel@81.4.123.134] has joined #openttd
03:36:16  *** Xaroth|W1rk [~XarothAtW@194.1.204.204] has joined #openttd
03:36:45  *** Sirenia_ [~sirenia@69.64.40.177] has joined #openttd
03:37:01  *** Netsplit synthon.oftc.net <-> weber.oftc.net quits: funnel, Sylf, guru3, Flygon, Xaroth|Work, murr4y, Sirenia, txtsd, Clockworker_, @Belugas,  (+4 more, use /NETSPLIT to show all of them)
03:37:01  *** txtsd_ is now known as txtsd
03:37:06  *** funnel_ is now known as funnel
03:37:10  *** Belugas [~belugas@216.191.111.230] has joined #openttd
03:37:13  *** mode/#openttd [+o Belugas] by ChanServ
03:37:42  *** Netsplit over, joins: Sylf, blathijs, murr4y, Ram-Z
03:43:44  *** _dp_ [~dP@2600:3c02::f03c:91ff:fe69:152c] has quit [Ping timeout: 480 seconds]
03:45:56  *** Sirenia_ is now known as Sirenia
03:51:28  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:4596:f7df:be02:f7ad] has quit [Quit: Leaving]
03:58:25  *** Flygon_ [~Flygon@ppp118-209-238-150.lns20.mel8.internode.on.net] has quit [Read error: Connection reset by peer]
04:02:05  *** Flygon [~Flygon@ppp118-209-238-150.lns20.mel8.internode.on.net] has joined #openttd
04:18:19  *** dP [~dP@2600:3c02::f03c:91ff:fe69:152c] has joined #openttd
04:18:20  *** dP is now known as _dp_
04:30:51  *** _dp_ [~dP@2600:3c02::f03c:91ff:fe69:152c] has quit [Ping timeout: 480 seconds]
04:37:20  *** dP [~dP@2600:3c02::f03c:91ff:fe69:152c] has joined #openttd
04:37:22  *** dP is now known as _dp_
04:39:55  *** supermop [~supermop@pool-100-37-203-161.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds]
04:44:53  *** Snail [~jacopocol@cpe-98-14-130-227.nyc.res.rr.com] has quit [Quit: Snail]
05:01:53  *** Clockworker_ [Clockworke@177.2.175.68] has joined #openttd
05:01:54  *** Clockworker__ [Clockworke@177.2.175.68] has quit [Read error: Connection reset by peer]
05:02:29  *** Clockworker__ [Clockworke@200.163.164.184] has joined #openttd
05:10:09  *** Clockworker_ [Clockworke@177.2.175.68] has quit [Ping timeout: 480 seconds]
05:22:35  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
05:22:49  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
05:33:14  *** sim-al2 [~sim-al2@108-221-157-231.lightspeed.mmphtn.sbcglobal.net] has quit [Ping timeout: 480 seconds]
06:18:16  *** Hiddenfunstuff [~Geth@y32.ip1.anvianet.fi] has joined #openttd
06:18:47  *** JGR_ [~JGR@host213-1-22-70.range213-1.btcentralplus.com] has joined #openttd
06:20:59  *** JGR [~JGR@host165-120-147-161.range165-120.btcentralplus.com] has quit [Ping timeout: 480 seconds]
06:20:59  *** JGR_ is now known as JGR
06:56:33  *** DDR [~David@S0106602ad0773a2e.vc.shawcable.net] has joined #openttd
07:05:21  *** Cybertinus [~Cybertinu@cybertinus.customer.cloud.nl] has joined #openttd
07:28:42  *** Xaroth|W1rk [~XarothAtW@194.1.204.204] has quit [Quit: Reconnecting]
07:29:11  *** Xaroth|Work [~XarothAtW@194.1.204.204] has joined #openttd
07:31:28  *** DDR [~David@S0106602ad0773a2e.vc.shawcable.net] has quit [Remote host closed the connection]
07:48:47  *** Pulec [~pulec@2a01:4f8:110:1463:67::2] has quit [Ping timeout: 480 seconds]
08:20:20  <peter1138> hmm, i suppose i should get this new star trek film
08:20:46  <peter1138> but i don't have an hddvd player
08:21:39  *** M-E [~M@ip4da0d6bd.direct-adsl.nl] has joined #openttd
08:27:03  <peter1138> ooh, a bluray drive with an aerodynamic enclosure... wha?
08:28:47  *** HerzogDeXtEr [~farci@i59F6CBCC.versanet.de] has joined #openttd
08:41:19  <joepie91> irritating discovery: the openttd protocol is actually stateful
08:41:32  <joepie91> at least for the content server...
08:45:52  <Rubidium> you mean the version number of OpenTTD?
08:52:45  <joepie91> Rubidium: nah, looking at the content server protocol atm. PACKET_CONTENT_SERVER_CONTENT responses can be either metadata or file contents
08:52:56  <joepie91> depending on whether a metadata packet was seen before and how many bytes are left to read for the file
08:53:03  <joepie91> the packet itself doesn't indicate whether it's metadata or not
08:53:09  <joepie91> that's expected to be inferred from what was seen before
08:53:11  <joepie91> hence, stateful protocol
08:53:37  *** HerzogDeXtEr [~farci@i59F6CBCC.versanet.de] has quit [Read error: Connection reset by peer]
08:54:47  <joepie91> it's a little irritating since the protocol parser I'm writing has so far been based on the assumption of it being a stateless protocol, because most of it is
08:54:56  <joepie91> and now I have to change it :P
08:58:47  <Rubidium> oh that, but then when you have to transfer more than MTU bytes you can't really circumvent that, right?
08:58:59  <Rubidium> you have some state of the file to write (or not)
09:00:13  <Rubidium> though effectively it's just data that keeps coming till an end-of-file marker (i.e. empty packet)
09:00:33  <Rubidium> unless the file could not be opened at the server side
09:00:43  <peter1138> is it not tcp?
09:01:56  *** Pulec [~pulec@78.46.49.59] has joined #openttd
09:02:16  <Rubidium> yeah, but built on top of the generic UDP/TCP packet format of OpenTTD
09:09:12  <peter1138> if it's raw tcp then there are no packets, just a stream. but i dunno what ottd does on top.
09:09:54  <Rubidium> 1 byte type, 2 bytes length, n bytes content; repeat
09:20:02  <joepie91> Rubidium: it would've been easily solved by just having a separate packet type for file contents
09:20:14  <joepie91> right now there's a "content info" and "content data" type
09:20:21  <joepie91> and "content data" will have both file metadata and file contents
09:20:44  <joepie91> if there were "content info", "content file metadata" and "content file contents" packet types, you'd be able to write a stateless parser
09:20:49  <joepie91> even if you have to reassemble the chunks
09:21:06  <joepie91> but you wouldn't need to know about previous packets to be able to parse subsequent ones, as is the case now
09:21:10  *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
09:21:24  <joepie91> each packet could be parsed independently even if you don't necessarily know what to do with the result
09:21:45  <Wolf01> o/
09:22:22  <joepie91> but right now the *format* of the "content data" packets will vary based on stream state :)
09:22:55  <joepie91> Rubidium: btw, packet length comes before packet type
09:22:59  <joepie91> not after
09:41:31  <Rubidium> you should've mentioned that when I wrote it ;)
09:41:38  *** TheMask96 [martijn@envy.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
09:46:45  *** TheMask96 [martijn@envy.vhost.ne2000.nl] has joined #openttd
09:56:41  *** Myhorta[1] [~Myhorta@25.103.114.89.rev.vodafone.pt] has joined #openttd
10:01:48  *** Samu [~oftc-webi@po-217-129-255-23.netvisao.pt] has joined #openttd
10:02:25  <Samu> woah, Nvidia is on a roll, releasing crashing drivers one after another
10:03:29  <Samu> good thing I use AMD
10:09:43  <joepie91> Rubidium: hmm? you wrote the content protocol, or? :P
10:21:11  *** andythenorth [~Andy@194.168.185.226] has joined #openttd
10:33:14  *** liq3 [~liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has joined #openttd
10:37:36  *** liq3 [~liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has quit []
10:41:49  *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd
10:52:29  *** darksecond [~darksecon@84.243.212.208] has joined #openttd
10:52:57  <darksecond> Playing openttd again, cargodist is very cool :D
11:08:26  <Rubidium> joepie91: most of it, I reckon
11:11:46  <joepie91> ahhh
11:11:51  <joepie91> Rubidium: on that note, I think there's a bug in it
11:11:55  <joepie91> you have a size check that seems off
11:12:17  <joepie91> in void ClientNetworkContentSocketHandler::RequestContentList(ContentVector *cv, bool send_md5sum)
11:12:50  <joepie91> length assert is missing the uint8 that's being written
11:13:05  <joepie91> so it's going to be one byte off for the estimated length of each item
11:13:31  <joepie91> actual length of an item is 21 or 5, not 20 or 4 :)
11:13:46  *** darksecond [~darksecon@84.243.212.208] has quit [Quit: leaving]
11:13:52  <joepie91> posted this here yesterday as well but I guess it got lost in the conversation
11:14:16  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:9436:9007:5b79:edab] has joined #openttd
11:14:42  *** Darksecond [~darksecon@a82-94-53-70.adsl.xs4all.nl] has joined #openttd
11:18:42  <joepie91> also, void ClientNetworkContentSocketHandler::RequestContentList(uint count, const ContentID *content_ids) has comments and a size check claiming that it writes a byte for the content type but I'm not seeing any such byte being written
11:20:35  <Rubidium> probably the cause of refactoring during development; could you make a patch for those issues and make a bug report with the patch attached to that (i.e. a tracker issue of type bug with a patch, not of type patch because that's generally for features and less well read)
11:20:53  <Rubidium> in any case I won't be doing anything with it as I don't have the required tools with me right now
11:21:27  <joepie91> Rubidium: I don't speak C++, so I'm not confident enough that I can write a correct patch :P
11:22:02  <joepie91> I can file a bug though
11:29:28  <Samu> question. I found a bug that only happens on 64-bit of openttd. Which category in flyspray is appropriate for this kind of bugs?
11:29:34  <Samu> build system'
11:29:36  <Samu> ?
11:30:52  <Samu> it's the lzo bug i've been talking about, i figured as much i might fill a bug report about it
11:33:13  <Rubidium> who knows?
11:33:25  <Rubidium> but are you sure it is an OpenTTD bug and not an LZO bug?
11:33:47  <Rubidium> or maybe a bug in the LZO library you are using?
11:34:06  <Samu> i tested the official trunk and 1.6.0, it happens there too
11:34:19  <Samu> only on the 64-bit
11:34:23  <Samu> 32-bit is fine
11:34:29  <Samu> win 9x also fine
11:35:45  <Samu> Unexpected end of chunk when loading LZO compressed saves
11:37:38  <Samu> i downloaded from https://www.openttd.org/en/download-stable and https://www.openttd.org/en/download-trunk
11:43:44  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:9436:9007:5b79:edab] has quit [Quit: Leaving]
11:47:51  *** Snail [~jacopocol@cpe-98-14-130-227.nyc.res.rr.com] has joined #openttd
12:00:21  <Samu> https://bugs.openttd.org/task/6450
12:11:06  *** Snail [~jacopocol@cpe-98-14-130-227.nyc.res.rr.com] has quit [Quit: Snail]
12:31:57  *** Guest904 [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Read error: Connection reset by peer]
12:32:33  *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd
12:33:30  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has quit []
12:36:28  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
12:37:24  <Samu> I found a bug in BusyBee
12:37:42  <Samu> how do i report a bug for this?
12:38:40  <ST2> http://dev.openttdcoop.org/projects/busy-bee-gs - check 1st the issues already reported there
12:38:44  <Samu> Number of years to wait to fullfill a new goal: 3, but when i click the arrow to diminish this value, it goes up to 4
12:39:03  <Samu> 4 is the minimum I can set if i change that value from default of 3
12:40:17  <ST2> by default: GSInfo.AddSetting({name="wait_years", (...) min_value=4,
12:40:23  <ST2> info.nut
12:41:00  <ST2> somewhat hard_value=3, maybe the cause of 3 appear xD
12:41:24  <Samu> im not gonna register to that website :(
12:47:15  <Darksecond> cargodist makes the game a lot more challengeing
12:48:08  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:b4a9:5f22:fd7e:3c2e] has joined #openttd
12:49:52  <andythenorth> cargodist changes my play style a bit
12:50:33  <Darksecond> how so?
12:51:24  <andythenorth> the most obvious is the automation of transfers, especially pax
12:51:29  <peter1138> cargodest?
12:51:32  <andythenorth> doing that without cargodist is blah
12:51:38  <andythenorth> peter1138: yacd :P
12:51:45  <andythenorth> destdist
12:51:46  <andythenorth> cargocargo
12:51:53  <Samu> cargo personality
12:52:42  <andythenorth> for freight, cargodist tends to perform poorly with more than two routes per pickup station
12:52:50  <planetmaker> Samu, what's wrong with registering with the openttdcoop website?
12:53:03  <andythenorth> if a third route is added, it takes a long time recalculate and rebalance the cargo
12:53:05  <Darksecond> andythenorth: you wouldn't recommend cargodist for freight?
12:53:11  <andythenorth> it’s better to add a new pickup station, and let station rating balance cargo allocation
12:54:47  <andythenorth> I use it for freight, but I have found the edge cases, and fonso has explained to me how it works
12:54:47  * andythenorth was going to update cargodist wiki page, but never did :P
12:54:47  <andythenorth> also for pax, it looks obvious to connect all routes together
12:54:47  <andythenorth> that is a very poor strategy
12:54:47  <andythenorth> better to build quite isolated networks
12:55:13  <Darksecond> really? seems more fun to build one big network
12:55:59  *** MonkeyDronez [~Monkey@77.69.236.126] has joined #openttd
12:56:11  <Darksecond> so that's what I'm doing right now, cargodist pax with one big network :)
12:57:10  <andythenorth> biggest misconception is that cargodist assigns cargo a specific destination, it doesn’t
12:57:55  <Darksecond> how so? it even says 'from ... via ... to ...' in the little window thing
12:58:44  <andythenorth> it’s based on ‘next hop’ rather than specific destination
12:59:04  <andythenorth> it works out about the same, but it’s more like flow in pipes
12:59:14  <Darksecond> so they will get on the first train that goes to the next hop? instead of a direct line?
13:01:41  <andythenorth> not sure exactly
13:01:41  <andythenorth> but it’s much easier to understand as a system of pipes, with stations as splitters
13:01:41  <andythenorth> and it uses distance and link capacity like valves to control proportions
13:01:41  <andythenorth> to people who can think algorithmically, I think that’s not a useful distinction
13:01:42  <andythenorth> but to people who think cargodist is actually simulating, e.g. preferences of individual passengers, it matters
13:02:21  <Darksecond> ah :)
13:02:24  <Darksecond> makes sense
13:02:54  <Darksecond> what I do like is how some stations slowly become 'hubs' of sorts :)
13:03:45  <andythenorth> it makes playing with airports much more satisfying
13:03:55  <andythenorth> airports can be fed from neighbouring towns
13:04:23  * joepie91 finds airports to be a capacity nightmare
13:04:40  <andythenorth> just don’t overfeed them
13:04:47  <joepie91> turns out it's quite easy to do that
13:04:49  <joepie91> :p
13:04:58  <joepie91> much more success with long-distance trains
13:05:23  <joepie91> bah, there's a bug in my parser...
13:05:27  * joepie91 vanishes again
13:06:13  <joepie91> whee, found another bug in OpenTTD source
13:10:05  *** Myhorta[1] [~Myhorta@25.103.114.89.rev.vodafone.pt] has quit [Ping timeout: 480 seconds]
13:22:09  <Wolf01> gah researched the electric furnace before plastic :|
13:22:45  <peter1138> no bugs, just features
13:23:21  <joepie91> fine, fine, misfeatures then :D
13:26:26  <joepie91> Rubidium: any chance I could pick your brain for a minute?
13:26:34  <joepie91> my parser is mis-parsing and I can't quite work out why
13:28:01  <joepie91> oh, hold on, I think I found the problem
13:28:32  <joepie91> yep, solved :D
13:28:58  <joepie91> forgot to advance my pointer after encountering a nullbyte in a string
13:35:46  *** Eddi|zuHause2 [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
13:42:31  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
13:45:10  *** OsteHovel [~OsteHovel@77.18.141.57.tmi.telenormobil.no] has quit [Ping timeout: 480 seconds]
13:46:49  *** OsteHovel [~OsteHovel@cE6A03E56.dhcp.as2116.net] has joined #openttd
13:48:44  *** DDR [~David@S0106602ad0773a2e.vc.shawcable.net] has joined #openttd
13:49:02  *** supermop [~supermop@static-71-249-209-97.nycmny.east.verizon.net] has joined #openttd
13:49:06  *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd
14:28:10  <_dp_> hi, did tropic landgen change in 1.6? doesn't seem to generate any hills whatsoever now
14:28:23  <_dp_> and there is nothing about it in changelog
14:30:16  <_dp_> I mean it does it on hilly, but there were plenty on "very flat" too previously
14:30:20  <_dp_> now it's just desert
14:31:23  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
14:31:26  *** mode/#openttd [+o Alberth] by ChanServ
14:38:13  <_dp_> oh damn, that's what "tune down" meant, everything is more flat now
14:38:25  <_dp_> how do I get back old settings then?
14:41:19  <Samu> .time to work on version 3
14:41:29  <_dp_> will it be enough if I just revert r27230?
14:42:50  <andythenorth> _dp_: desert has been flat for some time
14:42:55  <andythenorth> desert / tropic
14:42:58  <andythenorth> it’s absolutely crap :)
14:43:24  <andythenorth> you can patch it yourself trivially, just copy the temperate code in the switch, it works well
14:43:29  <Alberth> probably since MHL got added?
14:43:49  <_dp_> well, what I'm talking about changed in 1.6.0, there are plenty of trees in 1.5.3
14:44:36  <Alberth> different tree algorithm?
14:44:57  <_dp_> Alberth, nah, it's more flat now and trees only spawn on hills in tropic
14:45:14  <Alberth> ah, ok
14:45:55  <_dp_> Alberth, it seems it was your change actually ;)
14:46:10  <_dp_> https://hg.openttd.org/trunk.hg/rev/897a22994d61
14:46:37  <Alberth> chill change actually
14:47:13  <Alberth> *chillcore
14:47:49  <Alberth> he tried to fix the long slopes in MHL added openttd, which worked, a bit too well, perhaps, even :)
14:48:00  <Alberth> some parts were later reverted iirc
14:48:53  <Alberth> maybe this one should have been reverted too
14:48:59  <supermop> is it just me or is their no slide/page/board size in powerpoint
14:49:22  <supermop> like i cant set the size or ratio of these things they are just always 4
14:49:26  <supermop> :3
14:50:28  <supermop> why would anyone use this as a design tool
14:50:44  <supermop> except for the situation i'm in now where my boss told me to
14:51:04  <_dp_> ah, I dealt with mhl by setting max_heightlevel back to 15, so I guess that's why it's affecting me now xD
14:51:54  <Alberth> heights settings are not entirely correctly implemented any more, iirc
14:52:18  <Alberth> too many things are set in absolute values
14:52:19  <_dp_> well, it seemed to do the job)
14:52:41  <Alberth> which breaks if you change max height
14:53:41  <_dp_> yeah, also config settings are same as gui ones
14:54:06  <_dp_> so if you change what "very flat" means it also breaks existing configs
15:10:39  *** Gjax [~martin@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd
15:18:54  <Alberth> one could convert from number to percentage    num*100/16   :)
15:20:21  <joepie91> VICTORY!
15:20:23  <joepie91> https://clbin.com/p2JSH
15:20:27  <joepie91> my protocol parser works :D
15:20:34  <joepie91> content downloads and all!
15:24:44  *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
15:26:07  *** sim-al2 [~sim-al2@dns25-175.cbu.edu] has joined #openttd
15:29:31  *** Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has joined #openttd
15:30:14  *** frosch123 [~frosch@00013ce7.user.oftc.net] has joined #openttd
15:34:58  *** tony [~oftc-webi@host86-135-100-209.range86-135.btcentralplus.com] has joined #openttd
15:35:01  <frosch123> _dp_: try with max height levels set to 16
15:35:36  <frosch123> tropic does a height transformation, which tries to create mostly low land with a few peaks
15:35:40  <frosch123> this is broken with mhgl
15:36:00  <frosch123> vice versa, artic tries to generate high land with a few valleys
15:36:11  <frosch123> this is broken with mhl, and thus people complain about no forests in arctic :p
15:36:44  <_dp_> frosch123, already have it at 15 since mhl introduction)
15:36:57  <frosch123> ok, i expected the mapgen would work then :)
15:37:04  <tony> Hi, is anyone here familiar with Clueless plus AI, and the NoCarGoal game script?
15:37:29  <frosch123> several people here played nocargoal several times
15:37:48  *** smoke_fumus|2 [~smoke_fum@188.35.176.90] has joined #openttd
15:38:11  *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Read error: Connection reset by peer]
15:38:58  <tony> @frosch123 cool, I was looking to extending the cluesless AI that should work with it but from what I can tell, it doesn't?
15:39:55  <frosch123> are you refering to the "script communication protocol"?
15:40:22  *** ConductorCat [~Conductor@pool-108-56-8-121.washdc.east.verizon.net] has joined #openttd
15:40:24  <frosch123> https://wiki.openttd.org/Script_communication_protocol
15:41:25  <tony> Yeah, the SCP.
15:42:42  <frosch123> https://dev.openttdcoop.org/projects/ai-cluelessplus/repository/revisions <- according to that you need at least cluelessplus version 35
15:44:12  <Samu> what do you think? http://i.imgur.com/wDodzlc.png
15:45:14  <andythenorth> bloody mapgen :D
15:45:16  <Samu> the logic behind the choice of an encoding speed when a save request
15:45:31  <Samu> ... uh... is requested
15:47:05  *** ConductCat [~Conductor@pool-108-56-8-121.washdc.east.verizon.net] has quit [Ping timeout: 480 seconds]
15:47:27  <Samu> do you have other suggestions?
15:47:31  <Samu> or do you agree?
15:53:56  *** TheMask96 [martijn@envy.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
15:59:06  *** TheMask96 [martijn@wrath.vhost.ne2000.nl] has joined #openttd
16:00:37  <tony> I think it maybe because the Game Script is using 1.2 of SCP but the AI 1.3.
16:01:12  <Wolf01> bbl
16:01:15  *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
16:02:44  *** andythenorth [~Andy@194.168.185.226] has quit [Quit: andythenorth]
16:04:14  *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
16:04:40  *** MonkeyDronez [~Monkey@77.69.236.126] has quit [Quit: Leaving]
16:08:09  *** sim-al2 [~sim-al2@dns25-175.cbu.edu] has quit [Ping timeout: 480 seconds]
16:20:22  <frosch123> @calc (1460 - 2 - 1 - 1) / 5
16:20:22  <DorpsGek> frosch123: 291.2
16:20:24  <frosch123> @calc (1460 - 2 - 1 - 1) / 21
16:20:24  <DorpsGek> frosch123: 69.3333333333
16:20:35  *** aard [~aard@108.134.189.109.customer.cdi.no] has joined #openttd
16:28:43  <Samu> hmm :(
16:37:55  *** srhnsn [~srhnsn@HSI-KBW-109-192-198-135.hsi6.kabel-badenwuerttemberg.de] has joined #openttd
16:58:46  *** Progman [~progman@p57A19505.dip0.t-ipconnect.de] has joined #openttd
17:01:24  *** Arveen [~Arveen@ip-95-223-75-47.hsi16.unitymediagroup.de] has joined #openttd
17:01:56  *** Clockworker_ [Clockworke@200.163.164.184] has joined #openttd
17:01:56  *** Clockworker__ [Clockworke@200.163.164.184] has quit [Read error: Connection reset by peer]
17:03:12  *** glx [~glx@000128ec.user.oftc.net] has joined #openttd
17:03:15  *** mode/#openttd [+v glx] by ChanServ
17:09:41  <Samu> could openttd delete savegame function actually move the file to the recycle bin?
17:13:43  <Rubidium> not reliably across all platforms I guess
17:14:07  *** MonkeyDronez [~Monkey@77.69.236.126] has joined #openttd
17:17:51  <Samu> oh right
17:32:04  *** HerzogDeXtEr [~farci@i59F6B36B.versanet.de] has joined #openttd
17:32:40  <Samu> i actually like the idea of user defined variables
17:49:52  *** sim-al2 [~sim-al2@dns25-175.cbu.edu] has joined #openttd
17:50:06  *** gelignite [~gelignite@x4e30d0e3.dyn.telefonica.de] has joined #openttd
17:54:41  *** tony [~oftc-webi@host86-135-100-209.range86-135.btcentralplus.com] has quit [Quit: Page closed]
18:01:58  <Samu> Clamp(2, 0, 9) this checks if 2 is inside a range that goes from 0 to 9?
18:02:28  <Samu> but it doesn't return a true, it returns 2
18:02:40  <Samu> halp
18:02:58  <Alberth> read the documentation of the function?
18:03:20  <Samu> ok
18:07:07  *** smoke_fumus|2 [~smoke_fum@188.35.176.90] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
18:07:22  <Samu> oh, i see, makes sense, sorry
18:13:31  <Samu> this is all starting to make sense
18:13:34  <Samu> at last
18:15:47  *** sla_ro|master [slamaster@89.136.141.100] has joined #openttd
18:22:51  *** Eddi|zuHause2 is now known as Eddi|zuHause
18:26:12  <Samu> i have a dilema, need your input
18:26:39  <Samu> do you mind if i set min.compression for ZLIB to 1?
18:26:46  <Samu> because 0 doesn't even compress
18:26:55  <Samu> it stores uncompressed
18:27:19  <Samu> and there's already a "none" for that
18:32:35  <Samu> :(, i'm setting the min to 1, hope it's okay
18:35:29  *** andythenorth [~Andy@cpc87201-aztw31-2-0-cust156.18-1.cable.virginm.net] has joined #openttd
18:36:35  <Samu> as for lzma, 7, 8 and 9 are actually doing worse than lzma:6
18:36:53  <Samu> but require more memory
18:37:15  <Samu> and slightly slower
18:38:13  <Samu> lzma:9 is especially bad for 32-bits
18:38:36  <Samu> game might runs out of memory if the map is large
18:43:12  *** JacobD88 [~Thunderbi@cpc80661-stap13-2-0-cust817.12-2.cable.virginm.net] has joined #openttd
18:47:01  *** MonkeyDronez [~Monkey@77.69.236.126] has quit [Quit: Leaving]
18:49:08  *** JacobD88 [~Thunderbi@cpc80661-stap13-2-0-cust817.12-2.cable.virginm.net] has quit [Quit: JacobD88]
18:55:03  <andythenorth> o/
18:59:50  <Alberth> hi hi
19:03:55  *** sim-al2 [~sim-al2@dns25-175.cbu.edu] has quit [Ping timeout: 480 seconds]
19:03:59  *** Wolf01 [~Wolf01@host249-115-dynamic.116-80-r.retail.telecomitalia.it] has joined #openttd
19:04:24  <Wolf01> o/
19:09:26  *** sim-al2 [~sim-al2@dns25-175.cbu.edu] has joined #openttd
19:10:09  * andythenorth builds the world’s worst 4 way junction
19:12:11  <andythenorth> screenshot, or not true: http://dev.openttdcoop.org/attachments/download/7782/4-way.png
19:13:10  <Wolf01> nice one
19:18:21  <frosch123> do you have 90° turns enabled?
19:19:42  <Wolf01> I think he overbuilt
19:19:55  <andythenorth> yeah I have 90º turns enabled
19:20:05  <andythenorth> I used to disable it, but balls to that realism crap
19:20:21  <andythenorth> 90º is needed for ships to work on rivers
19:20:25  <andythenorth> and it makes it more fun also
19:20:35  <andythenorth> :)
19:24:05  <andythenorth> oops, that 4 way distracted me, forgot to do my BB goals :)
19:24:58  *** Stimrol [~Stimrol@46.239.220.130] has quit [Quit: ZNC - http://znc.in]
19:45:51  *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Quit: Valete omnes]
19:54:55  *** Arveen [~Arveen@ip-95-223-75-47.hsi16.unitymediagroup.de] has quit [Quit: Nettalk6 - www.ntalk.de]
19:55:14  <peter1138> Not realism, it just looks shit when trains do it.
19:55:29  <peter1138> Also º is still not a degrees symbol :p
19:59:10  <frosch123> apparently it is some spanish character
19:59:24  <frosch123> "masculine ordinal indicator"
19:59:28  <frosch123> no idea what that means
19:59:56  <Alberth> it counts men :p
20:00:52  <frosch123> https://en.wikipedia.org/wiki/Ordinal_indicator#.C2.BA_and_.C2.AA
20:01:19  <andythenorth> one day I’ll find the degree symbol :D
20:01:25  <andythenorth> if I try enough key combos
20:01:52  <sim-al2> It's fun to how almost all special characters fail in my IRC client
20:02:30  <frosch123> switch it to utf-8
20:03:03  <sim-al2> I can't, as far as I can tell
20:04:11  <frosch123> you are missing out on all the ö, œ and Þ
20:04:59  <andythenorth> also the magic quotes
20:05:00  <andythenorth> :P
20:05:12  <glx> « and » ?
20:05:18  <andythenorth> :P
20:05:22  <andythenorth> “no”
20:05:39  * andythenorth wonders about fixing station construction window
20:07:56  <sim-al2> Yeah, I see lot's of this: “no”
20:08:51  <sim-al2> "you are missing out on all the ö, œ and Þ"
20:09:18  <sim-al2> It works on Chatzilla of course, but I do like this interface more
20:09:31  <frosch123> andythenorth: i never understood quotes "'«»‘’‚‛“”„‟‹›⍘⍞❛❜❝❞ᅵᅵ❮❯〝〞〟
20:10:56  <andythenorth> fun aren’t they?
20:11:05  <andythenorth> sim-al2: “lots”
20:11:08  <frosch123> i mean how many rotations are positions can a ' possibly have?
20:11:24  <andythenorth> are there quote emojis?
20:11:26  *** sim-al2_2 [~chatzilla@dns25-175.cbu.edu] has joined #openttd
20:11:26  * andythenorth looks
20:11:48  <Alberth> /me wonders about emoji cargo
20:11:57  <andythenorth> oh they’re just unicode points or something I guess
20:12:07  <Alberth> or quote cargo, for that matter
20:12:35  <frosch123> andythenorth: ☹☺☻〠 <- those?
20:12:37  <andythenorth> really, there’s an emoji for the Wuppertal suspension monorail? :o
20:12:41  <andythenorth> that seems overkill
20:12:45  <Alberth> not all, I think, just the ones in the official unicode tables
20:12:54  <andythenorth> 🚟
20:17:40  <Samu> i had an idea
20:18:05  <Samu> could the minimap information run on a separate thread?
20:18:19  <frosch123> i had a dream
20:18:26  <Samu> just wondering
20:19:08  <frosch123> i discussed with eddi, what kind of synchronisation objects it woudl require to run a computer with countable infinite cores
20:19:22  <frosch123> i blame it on samu for waiting indefinitely for infinity
20:23:31  <andythenorth> there is a godwin law equivalent that applies to countable and non-countable infinity
20:24:15  <andythenorth> ho
20:24:27  <andythenorth> converting to electrified track has explosion sound effect
20:24:35  * andythenorth normally plays with sound off, because crossing bells
20:25:13  <frosch123> sounds like everyone does who uses convert-track :p
20:26:14  <andythenorth> :)
20:26:20  <frosch123> CcPlaySound10 plays SND_12_EXPLOSION
20:26:27  <frosch123> makes sense :p
20:27:19  <frosch123> all CcPlaySound are off by two
20:28:12  <Alberth> Samu: of course it can, deciding beforehand whether it will have the effect you want is the tricky part
20:29:02  <frosch123> andythenorth: https://paste.openttdcoop.org/pf3ihivsv?/pf3ihivsv <- does that sound better?
20:29:07  <Samu> it is extremely slow when i zoom out the minimap :\
20:29:20  <Wolf01> don't play large maps
20:29:39  <Samu> :\
20:29:44  <Wolf01> where large >256
20:30:13  <Samu> are these draw calls or something like that?
20:30:34  <frosch123> i still have not found a passive-agressive insult to display when someone selects a mapsize with more than 1M tiles
20:31:13  <Alberth> "Help, I am lost!"
20:31:14  <Wolf01> something like "oh noes, here we go again with this absurd map size"
20:32:07  <Samu> i had a dream that one day i'd be able to run openttd with 15 AIs + GS on a giant map
20:32:08  <Alberth> Samu: pixels blitted directly into the displayed memory
20:32:11  <Samu> from 1950 to 2050
20:32:13  * andythenorth has not found a way to educate people about the meaning of passive-aggressive :(
20:32:28  <frosch123> :)
20:33:36  <frosch123> ottd could just generate a smaller map, noone would notice
20:33:39  <Wolf01> "shit I forgot to see how much I took to get electricity in this game"
20:34:12  <Samu> i hope 16 GB of RAM is enough
20:34:44  <Samu> openttd is currently close to 5.9 GB RAM usage
20:34:47  <Samu> for this test
20:34:57  <Wolf01> meanwhile people are hosting on ras.pi
20:35:28  <Samu> only 16 game years have passed though
20:36:29  <Alberth> you can simply run each AI separately, at that map size, they won't bother each other
20:36:37  <Samu> frames are passing by so slowly
20:36:44  *** sla_ro|master [slamaster@89.136.141.100] has quit []
20:36:49  <andythenorth> frosch123: that sound effect seems better
20:36:51  <Samu> takes about half a second to update mouse cursor
20:37:14  <andythenorth> also withholding the requested map size is genuinely passive aggressive :)
20:37:25  <Alberth> :)
20:38:12  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
20:38:32  <sim-al2_2> I've turned off most of the sounds because of the subtropical climate
20:38:36  *** Hiddenfunstuff [~Geth@y32.ip1.anvianet.fi] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)]
20:38:41  <sim-al2_2> (and the damn sawmills in temperate)
20:39:16  <DorpsGek> Commit by frosch :: r27547 trunk/src/rail_gui.cpp (2016-04-19 22:39:08 +0200 )
20:39:17  <DorpsGek> -Fix: Use a more appropiate sound effect for convert-rail. (andythenorth)
20:39:18  <Wolf01> yeah, that one
20:39:35  <Wolf01> forgot a "R"
20:39:36  <andythenorth> frosch123: I didn’t write the patch :)
20:40:38  <frosch123> well, i didn't even start ottd :p
20:40:43  <andythenorth> he he
20:47:50  *** srhnsn [~srhnsn@HSI-KBW-109-192-198-135.hsi6.kabel-badenwuerttemberg.de] has quit [Quit: srhnsn]
20:54:43  <andythenorth> bed
20:54:43  *** andythenorth [~Andy@cpc87201-aztw31-2-0-cust156.18-1.cable.virginm.net] has left #openttd []
21:02:43  <Samu> yes, i finally figured this
21:02:46  <Samu> const SaveLoadFormat *fmt = GetSavegameFormat(((_savegame_format != NULL) ? _savegame_format :  _sendmap_format), &compression);
21:03:44  *** gelignite [~gelignite@x4e30d0e3.dyn.telefonica.de] has quit [Quit: http://bit.ly/1kso8Ta]
21:03:59  <Samu> i have 3 user defined settings for this
21:04:09  <Samu> the already existant _savegame_format
21:04:18  <Samu> 1 more i am creating _sendmap_format
21:04:26  <Samu> and another _autosave_format
21:04:36  <Samu> these are user defined in openttd.cfg
21:05:22  <Samu> now I got to work on bools
21:06:25  <Samu> but if there's a better approach for this, plz tell me
21:08:53  <frosch123> the fastest compression is not necessarily the most suitable one
21:09:07  <frosch123> you have to balance it with the network transmission speed
21:09:43  <frosch123> ideally you compress just as fast as you can send data
21:10:57  *** frosch123 [~frosch@00013ce7.user.oftc.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
21:13:07  <Samu> (_savegame_format != NULL) ? is to be replaced with an ugly mess of bools that will be put in there, i make the bools before passing them into GetSavegameFormat
21:13:26  <Samu> k lets see what I can do, brb
21:14:32  <Samu> ideally, the bools will follow this guidelines: http://i.imgur.com/wDodzlc.png
21:17:55  *** Gjax [~martin@93-167-84-102-static.dk.customer.tdc.net] has quit [Quit: Leaving]
21:26:47  *** liq3 [liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has joined #openttd
21:26:52  *** liq3 [liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has quit []
21:36:36  *** Progman [~progman@p57A19505.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
21:50:37  *** Supercheese [~Superchee@50-37-111-167.mscw.id.frontiernet.net] has joined #openttd
21:55:58  *** Clockworker_ [Clockworke@200.163.164.184] has quit [Read error: Connection reset by peer]
21:57:11  *** Clockworker [Clockworke@200.163.164.184] has joined #openttd
22:08:32  *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
22:13:14  <Wolf01> 'night
22:13:21  *** Wolf01 [~Wolf01@0001288e.user.oftc.net] has quit [Read error: Connection reset by peer]
22:25:10  *** _dp_ [~dP@2600:3c02::f03c:91ff:fe69:152c] has quit [Ping timeout: 480 seconds]
22:28:12  *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
22:34:15  *** dP [~dP@2600:3c02::f03c:91ff:fe69:152c] has joined #openttd
22:34:17  *** dP is now known as _dp_
22:35:46  *** Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has quit [Quit: Leaving]
22:48:57  *** HerzogDeXtEr [~farci@i59F6B36B.versanet.de] has quit [Read error: Connection reset by peer]
22:55:00  *** JacobD88 [~Thunderbi@cpc80661-stap13-2-0-cust817.12-2.cable.virginm.net] has joined #openttd
22:55:44  *** JacobD88 [~Thunderbi@cpc80661-stap13-2-0-cust817.12-2.cable.virginm.net] has quit []
23:00:30  *** sim-al2_2 [~chatzilla@dns25-175.cbu.edu] has quit [Ping timeout: 480 seconds]
23:01:29  *** sim-al2 [~sim-al2@dns25-175.cbu.edu] has quit [Ping timeout: 480 seconds]
23:19:07  *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
23:19:10  *** mode/#openttd [+v tokai|noir] by ChanServ
23:25:54  *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
23:30:39  *** tycoondemon2 [~ashnohoe@D97B8CD4.cm-3-4c.dynamic.ziggo.nl] has joined #openttd
23:35:55  *** tycoondemon [~ashnohoe@D97B8CD4.cm-3-4c.dynamic.ziggo.nl] has quit [Ping timeout: 480 seconds]
23:48:11  <Samu> hmm i have a problem... this clamping feature is annoying
23:48:57  *** aard [~aard@108.134.189.109.customer.cdi.no] has quit [Read error: Connection reset by peer]
23:52:34  <Samu> I am coding openttd in a way to use a max_compression for sending maps to clients joining a server, a min_compression for fast forward games, and a default for any other kind of savegame
23:53:34  <Samu> if openttd.cfg has nothing set in "sendmap_format = ", it will use the defaults
23:54:08  <Samu> in the case of lzma, that would be compression level 6
23:54:54  <Samu> however, if someone sets something in there, like "sendmap_format = lzma:9", the clamp function gets in the way
23:55:29  <Samu> it says an error about compression level
23:55:33  <Samu> and sets it to 6
23:56:17  <Samu> it's wrong. level 9 is possible, lzma can work with this level
23:56:49  <Samu> how can I solve this so that when nothing is set, it uses the max default of 6, but if a user sets something up to 9, it uses what the user wants?

Powered by YARRSTE version: svn-trunk