Times are UTC Toggle Colours
00:09:19 *** DDR [~David@S0106001f16aa47bc.vc.shawcable.net] has quit [Remote host closed the connection] 00:20:29 *** HerzogDeXtEr1 [~flex@i59F6DA5F.versanet.de] has quit [Quit: Leaving.] 00:30:57 *** DDR [~David@S0106001f16aa47bc.vc.shawcable.net] has joined #openttd 00:49:34 *** Nathan1852__ [~Nathan185@p5B216656.dip0.t-ipconnect.de] has joined #openttd 00:56:56 *** Nathan1852_ [~Nathan185@p5B216656.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:01:10 *** kirjs_______ [sid25169@id-25169.brockwell.irccloud.com] has quit [] 01:01:12 *** kirjs_______ [sid25169@id-25169.charlton.irccloud.com] has joined #openttd 01:35:58 *** Nathan1852_ [~Nathan185@p5DC1156F.dip0.t-ipconnect.de] has joined #openttd 01:43:05 *** Nathan1852__ [~Nathan185@p5B216656.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:44:28 *** Nathan1852_ [~Nathan185@p5DC1156F.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:48:26 *** gelignite [~gelignite@mue-88-130-121-114.dsl.tropolys.de] has quit [Quit: http://bit.ly/1kso8Ta] 01:50:35 *** Pereba [~UserNick@187.113.189.108] has quit [Quit: AdiIRC - are you ready for the future? (www.adiirc.com)] 01:53:38 *** Taco [~kitty@2407:500::2:981d:d5e9] has quit [Ping timeout: 480 seconds] 02:01:08 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer] 02:01:58 *** Taco [~kitty@2407:500::2:981d:d5e9] has joined #openttd 02:14:53 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 02:46:42 *** ade [~ade@182.242.140.181] has joined #openttd 02:46:44 *** ade is now known as Ade 02:47:25 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 02:47:57 <Ade> version = sys.version_info 02:47:57 <Ade> if version[0] < 3 or (version[0] == 3 and version[1] < 2): 02:47:57 <Ade> sys.exit('ERROR: Sorry, Python 3.2 or later is required for this application.') 02:48:42 <Ade> I use linuxmint17.1,the python is 2.7,the python3 is 3.4 02:49:34 <Ade> ade@ade-desktop ~/Downloads/nml $ python setup.py install 02:49:35 <Ade> ERROR: Sorry, Python 3.2 or later is required for this application. 02:49:35 <Ade> ade@ade-desktop ~/Downloads/nml $ 03:02:25 <Ade> ok ,I Have change the python to python3.4 03:02:40 <Ade> ade@ade-desktop ~/Downloads/nml $ python 03:02:40 <Ade> Python 3.4.0 (default, Apr 11 2014, 13:05:11) 03:02:40 <Ade> [GCC 4.8.2] on linux 03:02:40 <Ade> Type "help", "copyright", "credits" or "license" for more information. 03:02:40 <Ade> >>> 03:31:59 *** Ade [~ade@182.242.140.181] has quit [Quit: Leaving] 04:56:01 *** Eddi|zuHause [~johekr@p57BD5FA3.dip0.t-ipconnect.de] has quit [] 04:56:15 *** ade [~ade@222.172.141.194] has joined #openttd 04:56:16 *** ade [~ade@222.172.141.194] has quit [autokilled: This host may be infected. Mail support@oftc.net with questions. BOPM (2015-07-26 04:56:16)] 04:56:17 *** Eddi|zuHause [~johekr@p5B0DA14D.dip0.t-ipconnect.de] has joined #openttd 05:10:59 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd 05:11:02 *** mode/#openttd [+o Alberth] by ChanServ 05:15:17 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has joined #openttd 05:35:36 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 05:50:59 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 06:11:14 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 06:29:50 <andythenorth> o/ 06:29:54 <Alberth> moin 07:00:17 *** Progman [~progman@p57A182F3.dip0.t-ipconnect.de] has joined #openttd 07:05:54 *** Pensacola [~quassel@c80094.upc-c.chello.nl] has joined #openttd 07:16:44 *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd 07:34:38 *** Pensacola [~quassel@c80094.upc-c.chello.nl] has quit [Remote host closed the connection] 07:35:20 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 07:41:51 *** Progman [~progman@p57A182F3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:50:51 *** Zuu [~Zuu@h-114-162.a98.priv.bahnhof.se] has joined #openttd 07:51:12 <Zuu> Hello 07:57:57 <Alberth> moin 08:06:44 *** HerzogDeXtEr [~flex@i59F6DA5F.versanet.de] has joined #openttd 08:18:07 *** Flygon_ [~Flygon@ppp118-209-87-123.lns20.mel4.internode.on.net] has joined #openttd 08:21:46 *** Flygon [~Flygon@ppp118-209-87-123.lns20.mel4.internode.on.net] has quit [Ping timeout: 480 seconds] 08:26:28 *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 08:26:32 *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd 08:40:24 <LordAro> mrng 08:41:15 <Zuu> Good morning LordAro 08:43:23 <Zuu> With BeeProductive, transporting coal and other things to a black hole factory become even less interesting. :-) 08:47:12 <Zuu> Shouldn't this require that bit 0x80000000 (2^31) is set? And thus stop random production change from altering industry production? https://paste.openttdcoop.org/p4ighe8em 08:49:28 <Zuu> Or am I doing it wrong when clearing the bit? 08:50:15 <Zuu> I end up with industries having -2147483648 in their persistent store. 08:53:32 <Eddi|zuHause> that is what 0x80000000 is 08:54:15 <Zuu> hmm, so my assumption to use - to clear it out didn't work then. 08:54:38 <Zuu> Isn't it uint32? 08:54:42 <Eddi|zuHause> no, -2^31 = 2^31 08:55:26 <Eddi|zuHause> no, it's usually depending on the interpretation whether it's int or uint 08:56:07 <Zuu> I could use 0x20000 instead, but as 0x10000 is industry closure bit, I don't know if I hide some other useful stuff by just taking the next bit after that, so I though I go for the max bit. 08:57:29 <Eddi|zuHause> anyway, use &0x7FFFFFFF to clear out bit 31 08:58:11 <Eddi|zuHause> Zuu: btw, i think lazy evaluation doesn't work this way in NML, so the STORE_PERM is evaluated whether or not the first expression is true 08:58:35 <Zuu> I tried ? operator first, but it didn't seem to work. 08:59:52 <Eddi|zuHause> you might want to try something like STORE_PERM(condition?new_value:old_value) 09:00:05 <Zuu> Good point 09:01:29 <Eddi|zuHause> or alternatively: switch(condition) {0: switch_that_doesn't_store; switch_that_stores;} 09:02:33 <__ln__> what's the actually working url to openttd's git repo? 09:04:48 <peter1138> http://git.openttd.org/openttd/trunk.git/ 09:05:39 <__ln__> thanks. question #2: why isn't that listed at http://www.openttd.org/en/development 09:06:03 *** Flygon_ [~Flygon@ppp118-209-87-123.lns20.mel4.internode.on.net] has quit [Read error: Connection reset by peer] 09:06:27 <peter1138> http://git.openttd.org/trunk.git also works 09:06:28 <peter1138> Hmm. 09:07:52 <peter1138> Latter one is listed indirectly. 09:08:17 *** gelignite [~gelignite@mue-88-130-66-087.dsl.tropolys.de] has joined #openttd 09:14:33 *** Wolf01 [~wolf01@host146-233-dynamic.16-79-r.retail.telecomitalia.it] has joined #openttd 09:14:57 <Wolf01> o/ 09:16:25 <Zuu> Eddi|zuHause: Thanks, that solved the problem. 09:16:54 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 09:17:00 <Wolf01> o/ 09:20:45 <Alberth> o/ 09:23:51 *** frosch123 [~frosch@x5f746ab7.dyn.telefonica.de] has joined #openttd 09:28:41 <Terkhen> hello 09:32:14 <Wolf01> quak 09:33:27 <frosch123> moin 09:35:33 <Zuu> Hello. I just pushed a fix to newgrf+gs so OpenTTD random production change doesn't alter production. Though it uses bit 31 so I just realized it wil be tedios to use the sign GS now. :-) 09:35:55 <Zuu> But it is quick to disable that check. 09:43:10 *** Hiddenfunstuff [~Geth@a392.ip16.netikka.fi] has joined #openttd 09:44:00 <frosch123> i had more thoughts on json 09:44:05 <frosch123> but it's a long route :p 09:46:13 <Alberth> o/ 09:47:24 <DorpsGek> Commit by frosch :: r27340 /trunk (11 files in 4 dirs) (2015-07-26 11:47:17 +0200 ) 09:47:25 <DorpsGek> -Fix [FS#6338]: Silence warning by moving _string_colourmap to a file no its own. (Cif) 09:51:58 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Read error: Connection reset by peer] 09:53:46 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 09:54:54 *** wicope [~wicope@0001fd8a.user.oftc.net] has joined #openttd 09:56:49 <DorpsGek> Commit by frosch :: r27341 trunk/src/town_gui.cpp (2015-07-26 11:56:43 +0200 ) 09:56:50 <DorpsGek> -Fix [FS#6332]: Do not rerandomise the town name when only cost-estimating the founding. 09:58:38 <andythenorth> BusyFrog 10:13:22 *** openttd-user [~johannes@HSI-KBW-091-089-094-114.hsi2.kabelbw.de] has joined #openttd 10:13:56 <openttd-user> hey, openttd 1.5.0 has some new instruments for its songs, which is cool, but how can I get the old sounds? 10:14:28 <Zuu> How midi sounds depend on the sound font your sound card have. 10:15:02 <Zuu> If you had an old good sound card, it probably had better or at least diferent sound font to the one in your current computer. 10:15:19 <frosch123> are you sure there is still hardware with sound fonts? :p 10:15:41 <Zuu> I guess it is done in the driver these days. 10:15:51 <Zuu> Also if you use OpenMSX, it has different songs than TTD. 10:16:07 <frosch123> openttd-user: are you sure you selected the same music set in game options? 10:16:10 <Zuu> You can copy the midi-files from TTD if you have a copy of TTD for windows. 10:18:48 <peter1138> There is still hardware with sound fonts. 10:19:11 <frosch123> external keyboards? 10:19:17 <peter1138> I haven't seen an ISA slot for a while though :p 10:19:42 <peter1138> Do emu10k-based cards still exist? 10:20:32 <peter1138> Heh, they keyboard I want costs ~£1000 and... doesn't make its own sound. Pom te pom. 10:21:57 <peter1138> Crap, didn't win the Euromillions :( 10:24:22 *** Flygon [~Flygon@ppp118-209-87-123.lns20.mel4.internode.on.net] has joined #openttd 10:24:35 <openttd-user> frosch123: I can only select OpenMSX 10:25:40 <openttd-user> Zuu: I don't know, but since 1.5.0, the songs have more saxophone/trombone etc. in it, I preferred the versions where they were replaced by pianos 10:25:55 <frosch123> well, neither openttd nor openmsx changed anything 10:26:08 <frosch123> so, maybe you updated your windows, got a different computer or something 10:26:22 <blathijs> Or perhaps you had the original Open 10:26:35 <blathijs> Or perhaps you had the original TTD songs before but not now? 10:26:35 <frosch123> neither openttd nor openmsx actually define the instruments, your sound drivers do that 10:27:13 <openttd-user> frosch123: I also updated my Linux (openSuSE -> Gentoo), but I think I've heard the new sounds on an other Linux computer, too 10:27:35 <openttd-user> blathijs: No, I did not have the TTD files 10:28:23 <frosch123> ah, linux :) ok, then i actually believe that some nerd may have updated the sound fonts :p 10:28:34 <frosch123> i wouldn't expect any commercial thing to bother about that 10:28:38 <blathijs> openttd-user: I suspect that the soundfont you were using previously was missing some instruments and timidity replaced those with a generic piano instead of making them silent. Now you have a soundfont that has these instruments. 10:29:26 <openttd-user> frosch123: Do you mean that someone updated them in the system, or in openttd? 10:29:44 <blathijs> openttd-user: In the system 10:30:31 <openttd-user> blathijs: where in the system could that be? 10:30:34 <peter1138> midi just says "use a piano sound" or "use a guitar sound". it doesn't say how the sound should... er... sound... 10:31:01 <Flygon> MIDI's a mess anyway :( 10:31:08 <peter1138> no it's not 10:31:12 <Flygon> Shame Windows never ever encouraged decent tracker support 10:32:57 <openttd-user> Maybe the soundfonts come in with timidity? 10:33:36 <blathijs> openttd-user: It's likely the "freepats" package. Not sure how to approach this - you could try downgrading to some old version, or perhaps you can configure timidity/freepats to use different sounds for some instruments (you'll need to do some research about how that works ans what instrument numbers you need, though) 10:34:43 <openttd-user> blathijs: strange, I don't have it installed, would you suggest to install it? 10:38:16 <blathijs> openttd-user: Could be that timidity is using another soundfont package, then 10:38:24 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has quit [Ping timeout: 480 seconds] 10:46:45 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has joined #openttd 10:59:27 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has quit [Remote host closed the connection] 11:00:20 *** tycoondemon [~ashnohoe@D97B8CD4.cm-3-4c.dynamic.ziggo.nl] has quit [] 11:04:36 <andythenorth> can haz new features? o_O 11:05:23 <frosch123> more fences 11:05:49 <Zuu> Yeah, why cannot I place fences like in RCT? 11:07:08 * andythenorth just avoiding working on Road Hog 11:07:16 <andythenorth> no actual ponies wanted right now :P 11:09:55 <Zuu> I announced Bee Productive on the forums. Now I guess not many will use it given that hey have to patch OpenTTD first. 11:10:52 <andythenorth> compiled binaries :P 11:11:22 <andythenorth> we donât really have pre-compiled experimental branches do we? 11:11:27 <andythenorth> just useless patch packs 11:11:45 <__ln__> i found a bug. 11:11:50 <Zuu> That asume some set up with the compile farm that I'm clueless about how to do. 11:12:15 <Zuu> But some braches in the past had that. But that might assume that it is actually a branch and not just a patch file. 11:12:26 <andythenorth> youâll have to rely on some community member to compile some buggy patch pack made up of bad features :P 11:13:11 <Zuu> I could upload a Windows binary. After all I have compiled a release build for myself. :-) 11:13:23 * andythenorth has âviewsâ about patch packs apparently :) 11:13:45 <Zuu> :-) 11:18:25 <Zuu> Hmm.. I think the Area command to send a message to all industries in up to 255x255 tiles area may be not so much in use? In small areas, it is not much overhead to update industry by industry. However, a method to send messages to all industries (or all of given type) may be more useful. Eg. for BeeProductive to initialize all secondaries at 33% efficiency. 11:18:58 <frosch123> andythenorth: don't blame the packs :p 11:19:46 <andythenorth> I donât 11:19:50 <frosch123> Zuu: i wondered whether adressing by town+type has any use :p 11:19:57 <andythenorth> I blame the people who make spurious bug reports because theyâre using a pack :) 11:20:24 <Zuu> Though 255x255 is not that small as an area. If you like to divide the map in 255x255 areas and control production of each square, then it may be useful. :-) 11:20:54 <TrueBrain> Zuu: you are aware the CF can compile any SVN, Git (branch) and HG (branch), right? :P 11:21:19 <TrueBrain> just a matter of asking the right persons about it :D 11:21:26 <Zuu> town+type would be used by BeeProductive when a mail goal is completed (to upgrade all primaries), but it would be called once for each primary type. So unless the town have very many primaries, it is probably more efficient still to filter out the industries and call them one by one. 11:21:34 <frosch123> TrueBrain: can we actually make the branch name a variable? 11:21:41 <frosch123> to the farm 11:21:59 <frosch123> i mean we do not need automatic builds, but builds of random branches :) 11:22:00 <TrueBrain> frosch123: it is 11:22:53 <andythenorth> Zuu: w.r.t area command, I would guess that âall industries per townâ is a more common case 11:23:00 <Zuu> TrueBrain: Right. I kind of knew that. But would need to first set up a proper VCS branch for it and not just a hg queue :-) 11:23:05 <andythenorth> going by a square map section seems odd 11:23:14 <TrueBrain> Zuu: anything that is public works 11:23:32 <TrueBrain> so if you have any public hg head with the correct code, that would work fine 11:23:42 <TrueBrain> but yes, you do need to unroll the queue; the CF cant do that for you :D 11:24:07 <TrueBrain> (and remember that if you like you can push a hg to your dev-space :P) 11:24:27 <frosch123> but #devzone may be more useful :p 11:24:39 <Zuu> I didn't knew I could, but it may be in some instruction I got. 11:24:40 <TrueBrain> fully agree :) 11:25:01 <TrueBrain> if it is OpenTTD related, you can pretty much do everything on your devspace :P 11:25:19 <TrueBrain> but I agree with frosch123, it would be better to push it via openttdcoop :) They have more specified software for it :) 11:26:06 <andythenorth> frosch123: you have a wishlist for a new newgrf version? 11:26:19 * andythenorth remembers seeing one somewhere 11:26:33 <frosch123> andythenorth: yes, but it is an insane one (intentionally) 11:27:23 <andythenorth> any link? o_O 11:27:48 <Zuu> So I would create a devzone project, and push a clone of OpenTTD hg mirror there? And create a branch where I do my commits that also is pushed up to devzone? 11:27:54 <frosch123> andythenorth: https://wiki.openttd.org/Frosch/GRF_version_9 11:27:58 <Zuu> I used branches a bit in git, but never in hg. 11:28:05 <frosch123> Zuu: it's easier to let coop pull from openttd.org first 11:28:10 <andythenorth> ta 11:28:16 <frosch123> unless you have good upload speed :p 11:28:23 <Zuu> Right 11:28:33 <TrueBrain> Zuu: branches in hg are a ghost :P 11:29:21 <Zuu> Or I could fork this? https://github.com/OpenTTD/OpenTTD 11:29:31 <andythenorth> âseasonal acceptance/production (predictable multiple changes per year)â 11:29:33 <TrueBrain> just you have to make sure that HEAD on the branch is your code, and we are golden :) 11:29:41 <TrueBrain> Zuu: works too if you like; basically, what-ever is easiest for you 11:29:43 <andythenorth> conditional orders: âthere is a y in the month" 11:30:01 <TrueBrain> we have like 5 different ways to do this, just to make sure you have options and can do what you are most knowledged about 11:30:02 <Zuu> I prefer learning more git over hg. While hg may be better, real world (=work) uses git. 11:30:28 <frosch123> Zuu: TrueBrain: how about setting up a "sandbox" repo on coop, which everyone can push experimental stuff to, and the farm builds tags by manual trigger 11:30:38 <TrueBrain> no 11:30:40 <TrueBrain> :D 11:30:53 <TrueBrain> well, depends on who can trigger it, basically :P 11:31:11 <frosch123> no automatic trigger :) 11:31:18 <TrueBrain> no, who :D 11:31:28 <TrueBrain> the CF executes a few scripts while compiling 11:31:29 <frosch123> you, pm, me 11:31:42 <TrueBrain> it would be rather trivial to craft a code version that does nasty things :P 11:31:42 <frosch123> i just feel that we sometimes need a single build of a single patch 11:31:50 <TrueBrain> so there is trust involved :) 11:31:56 <frosch123> setting up a new farm which builds daily is of no use 11:32:24 <TrueBrain> farm entries for non-official stuff runs "on change" once a (day|week) anyway ;) 11:32:34 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Read error: Connection reset by peer] 11:32:44 <frosch123> yes, but it needs a separate farm for every branch 11:32:45 <TrueBrain> but if there is a wish for what you describe, that for sure can be done; just please validate code before you press compile :P 11:32:55 <TrueBrain> copies are cheap 11:33:05 * peter1138 copies TrueBrain 11:33:08 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 11:33:16 <frosch123> and i think we are talking about build-only-once stuff 11:33:18 <TrueBrain> whoho, twice as productive! Tnx peter1138 :) 11:33:30 <TrueBrain> frosch123: if there is a wish for that, it can be arranged 11:33:37 <TrueBrain> there are some issues to overcome, but nothing fancy 11:33:44 <TrueBrain> (branch-names for example) 11:34:00 <frosch123> i am thinking tags only 11:34:08 <TrueBrain> no, branch-names, like 11:34:14 <TrueBrain> openttd-custom-mybranch-r12345 11:34:31 <frosch123> openttd-custom-mytag123 11:34:33 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 11:34:44 <TrueBrain> that is not how the scripts work atm ;) 11:34:51 <TrueBrain> like I said, stuff to overcome :) 11:34:55 *** Nathan1852_ [~Nathan185@p5DC1156F.dip0.t-ipconnect.de] has joined #openttd 11:35:15 <Alberth> git branches ~ hg tags 11:36:01 <frosch123> well, openttd-custom-mytag-myhash would be about the same 11:36:33 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 11:37:40 <frosch123> with "tag" i just mean a fixed revision, and no moving-head like a branch 11:38:11 <andythenorth> -alpha or -experimental or -rc or whatever 11:38:22 <andythenorth> or just the hash? 11:38:38 <TrueBrain> well, from next week I have some time to fiddle with it; so if you can remind me next week, I will see what I can cook up 11:42:17 <TrueBrain> OpenTTD - 3rdparty 11:42:21 <TrueBrain> Hardpack, last build, 1 year ago 11:42:26 <TrueBrain> TTIP, last build, 10 months ago 11:42:29 <TrueBrain> guess it is time to remove those :P 11:43:24 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd [] 11:49:29 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 11:49:32 *** mode/#openttd [+v tokai|noir] by ChanServ 11:56:23 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 11:57:45 <andythenorth> âwhen I made Thomas, it made it more likeâŠrealisticâ 11:57:46 <andythenorth> :P 11:58:06 <TrueBrain> Zuu: I pressed a button; now fingers crossed it does anything :D 11:58:25 <TrueBrain> I think I configured it now that it will be pushing the files to the mirrors too .... hihi :D 11:59:21 <Zuu> Nice .-) 11:59:31 <TrueBrain> hmm, documentation failed .. lolz 11:59:56 <Zuu> May be an error in doxygen comments from my side perhaps. 12:00:19 <TrueBrain> cannot open tag file objs/openttd.tag 12:00:23 <TrueBrain> sounds like something is just broken :P 12:01:57 <TrueBrain> ah, yes, that is indeed broken ni the CF 12:01:59 <TrueBrain> pfew :D 12:02:31 <Zuu> :-) 12:03:03 <TrueBrain> now we will have to wait for the other targets to finish, then I can retrigger it :P 12:04:00 <TrueBrain> Build #2! :D 12:06:01 <TrueBrain> yippie, that works; okay, this will take ~25 minutes or so 12:06:31 <Zuu> Great 12:17:36 *** wicope [~wicope@0001fd8a.user.oftc.net] has quit [Read error: Connection reset by peer] 12:25:43 <DorpsGek> Commit by frosch :: r27342 /trunk/src (newgrf_railtype.cpp newgrf_railtype.h) (2015-07-26 14:25:37 +0200 ) 12:25:44 <DorpsGek> -Add: Optionally return the number of sprites in the spriteset from GetCustomRailSprite. 12:25:54 <Eddi|zuHause> <__ln__> i found a bug. <-- is it about earrings not being symmetrical? 12:27:17 <__ln__> it's not as serious, only a null pointer dereference resulting in a crash. 12:28:40 <DorpsGek> Commit by frosch :: r27343 /trunk/src (rail.h rail_cmd.cpp) (2015-07-26 14:28:34 +0200 ) 12:28:41 <DorpsGek> -Feature [FS#6315]: [NewGRF] Allow railtype NewGRF to define separate sprites for the fences on either track side. 12:29:11 <frosch123> V453000: ^^ may also be interesting for you, it should allow removing the gaps between fences in corners 12:31:52 <TrueBrain> Zuu: do you want to manually trigger a new build, or do you want the CF to poll automatically once in a while? 12:32:16 <TrueBrain> Zuu: https://www.openttd.org/en/download-gsnewgrf 12:32:22 <TrueBrain> one of the perks of being a dev, I guess :P 12:33:11 <Zuu> By trigger, is that to log in to ssh and make a command there? 12:33:27 <TrueBrain> by logging in to https://farm.openttd.org/ and press: Run, on the correct job 12:34:12 <Zuu> I guess i could do that manually. 12:34:19 <TrueBrain> I really dont mind either way 12:34:25 <TrueBrain> what ever is easiest for you 12:34:39 <Zuu> Automatic is probably easier, assuming it is like once every hour or so. 12:34:55 <TrueBrain> sadly, can only be once a day 12:35:02 <TrueBrain> because we have windows of which no other compiles can happen 12:35:04 <TrueBrain> (read: nightly) 12:35:13 <TrueBrain> it is easier to avoid the CF to pick up changes during those hours 12:35:20 <TrueBrain> than to make a priority thing for it :P 12:35:29 <TrueBrain> so the automatic polling would be once a day 12:35:31 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd 12:35:46 <Zuu> And it is still possible to manually triger it still? 12:35:53 <TrueBrain> yes 12:36:01 <Zuu> Best of both worlds? 12:36:20 <TrueBrain> prefered time you want the poll to happen? 12:36:29 <Zuu> So many choices :-) 12:36:36 <TrueBrain> 0100 am? 12:36:41 <TrueBrain> 0100 pm? 12:37:02 <Zuu> 0100 am 12:37:21 <TrueBrain> done :) 12:44:55 <TrueBrain> well, gl/hf with it :D hihi :) 12:45:12 <Zuu> Thanks 12:50:08 *** Progman [~progman@p57A182F3.dip0.t-ipconnect.de] has joined #openttd 12:54:30 *** openttd-user [~johannes@HSI-KBW-091-089-094-114.hsi2.kabelbw.de] has quit [Quit: leaving] 12:55:27 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 13:03:10 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd 13:03:13 *** mode/#openttd [+o Alberth] by ChanServ 13:03:17 <Eddi|zuHause> frosch123: now, track and base sprites for the whole junction, instead of per trackbit? 13:09:22 <frosch123> no, now more interesting stuff 13:10:50 <frosch123> so, how does this tcp/ip packet-transmission work? 13:10:59 <frosch123> is there some limit on the size of a packet 13:11:19 <frosch123> do i need to care about splitting and reconcatenating bigger packets? 13:12:40 <Alberth> tcp/ip? nah, you don't care about packets at all, order is preserved, delivery is guaranteed 13:13:27 <Alberth> obviously, you may get only parts of the data at a time, at the receiving end 13:13:27 <Eddi|zuHause> frosch123: the point of layers is that you don't have to worry about the lower layers at all, they just magically work 13:15:25 <frosch123> so, you say it is ottd's fault of using the same infrastructure for sending via tcp and udp, that results in command packages being limited to 1460 bytes? 13:16:13 * Zuu picked up his data com book from university. It says that the TCP layer will read from the buffer and will on the other computer write to a buffer. 13:16:22 <Eddi|zuHause> frosch123: probably 13:16:46 <Zuu> The book says a lot more, but takes time to read.. :-) 13:17:17 <Alberth> :) 13:17:33 <Eddi|zuHause> https://www.youtube.com/watch?v=iIA7LjrobiM <- about books [german] [nsfw] 13:17:42 *** Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has joined #openttd 13:18:59 <Zuu> TCP has a maximum transmision unit, MTU and the book list 3 common values: 1460 bytes, 536 bytes and 512 bytes. 13:20:15 <frosch123> i think i found the place to lift this limit from ottd 13:20:41 <Zuu> But as long as the application can define the buffer size, then you don't have to care about package splitting is my intrepretion. 13:21:48 <peter1138> MTU is at the transport layer, and translates to MSS (MTU - 40bytes). Those figures are MSS. 13:22:44 <Zuu> The book says it is MTU figures, but the book could be wrong. 13:23:39 <peter1138> MTU affects more than TCP. Normal MTU is 1500 bytes. 13:24:30 <peter1138> And indeed, as long as fragmentation isn't prohibited, it doesn't particularly matter for TCP. 13:27:35 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 13:27:38 *** mode/#openttd [+v glx] by ChanServ 13:36:42 *** gelignite [~gelignite@mue-88-130-66-087.dsl.tropolys.de] has quit [Quit: http://bit.ly/1kso8Ta] 13:51:50 <TrueBrain> frosch123: you can change the limit, just UDP will fail :D 13:51:54 <TrueBrain> so you would have to split the two 13:52:05 <TrueBrain> UDP packets over the size of the MTU will never arrive at the destination 13:52:56 <TrueBrain> frosch123: but why do you want to change the value to start with? 13:53:12 <frosch123> because i want to send a big json as command parameter 13:53:21 <TrueBrain> ieuw 13:53:22 <TrueBrain> :D 13:53:28 <frosch123> 64kb looks more reasonable than 1460 bytes 13:53:41 <TrueBrain> well, TCP has fragmentation support, so any package over the MTU will be split in multiple, reassembled by the TCP layer (in order) 13:53:45 <TrueBrain> UDP doesnt 13:54:31 <frosch123> bananas uses tcp for the content list, right? 13:54:35 <TrueBrain> and I think we still allocate a pre-set sized buffer for the TCP :) 13:54:56 <frosch123> well, the PacketSize member is uint16 to start with :p 13:55:32 <frosch123> anyway, i am fine with 64kb, it must be hand-written by newgrf authors anyway 13:55:36 <TrueBrain> tcp_content is TCP, so yeah 13:57:00 <TrueBrain> ah, the buffer indeed is allocated SEND_MTU size 13:57:17 <frosch123> yup, already replaced that one :) 13:57:24 <TrueBrain> well, you cannot just replace it 13:57:31 <TrueBrain> you will have to split TCP and UDP somehow 13:57:35 <frosch123> yes 13:57:45 <TrueBrain> and you also just don't want to increase the buffer .. you will have to find a nice slick way to resize when needed or something :) 13:57:53 <frosch123> result will be that the map wil be streamed in chunks of 64kb, instead of 1.4 13:58:08 <frosch123> but i guess that makes no difference on the lower levels 13:58:16 <TrueBrain> would only increase the speed 13:58:41 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 13:59:02 <TrueBrain> I guess at creating of Packet you know the estimated size .. hmm 14:00:57 <TrueBrain> hmm .. the days that we fiddled with UDP to get it stable ... 14:01:07 <TrueBrain> then NewGRFs got introduced, and servers werent pollable anymore ... 14:01:12 <TrueBrain> silly MTU on UDP :P 14:01:26 <TrueBrain> current MTU is totally random btw ... if you have any network with any hub with lower MTU, UDP won't work for it :( 14:03:50 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 14:03:59 <TrueBrain> owh, I so remember the days that my Linux machine refused to talk to my Windows machine 14:04:06 <TrueBrain> because Windows had an MTU of 1460, and Linux of 1500 14:04:10 <TrueBrain> hours of debugging .... 14:04:28 <TrueBrain> one machine saw the traffic going out, but not back in .. while the other saw all the traffic :D 14:04:50 <TrueBrain> the days of the "hubs" in your UTP network .. 14:05:33 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 14:07:36 <michi_cc> frosch123: Sending is no problem up to some maximum OS buffer size (which will be large enough :). For receiving though, you can not assume to get the data in the same chunks than you sent it, so you will have to reassemble (and possibly split between chunks). 14:09:28 <michi_cc> If there's a gap between receiving two consecutive packets, recv() will generally not wait and just return the data received so far. Application wise, TCP is essentially an endless stream and the protocol has to sort out the chunk borders. 14:12:07 <frosch123> https://devs.openttd.org/~frosch/diffs/tcp_packetsize.diff <- so, is this good enough? 14:12:24 <frosch123> or should i replace the fixed-size buffer with some growing std::vector or something? 14:12:54 <frosch123> most packets will probably be around 32 bytes or something, so allocating 64kb each time may increase the server queues 14:13:04 <frosch123> though, technically clients can still send 64kb packets 14:13:24 <frosch123> would need kicking if packets are bigger than needed 14:18:48 <TrueBrain> I don't think increasing the size of all buffers to 64k is the way to go 14:18:57 <TrueBrain> for many Packets, we already know the length (as they are predefined) 14:19:02 <TrueBrain> this feels like a huge increase in memory usage 14:19:05 <TrueBrain> (both client and server) 14:20:18 <TrueBrain> frosch123: what communication part do you require the bigger size for? (server<->client, client->server, server->client, ms->server, ms->client, ...?) 14:21:06 <frosch123> server->client for game-script triggered command packages 14:21:28 <TrueBrain> so maybe only increase the size of the packet? 14:21:35 *** Nemoder [~quassel@63.142.210.189] has joined #openttd 14:21:46 <frosch123> of the command packet? or add a separate big-command packet? 14:21:56 <TrueBrain> either way 14:22:05 <TrueBrain> this just feels like a lot of unneeded memory being allocated all the time :D 14:22:12 <frosch123> or make the allocation incremental? first 32 bytes, then packet-size bytes 14:22:18 <frosch123> i guess the latter is easiest 14:22:28 <frosch123> after the first 32 bytes, the target size is known 14:22:41 <frosch123> so, at most one realloc per packet 14:22:49 <TrueBrain> how is it known? :) 14:23:02 <frosch123> the packet size os the first item in the packet 14:23:10 <frosch123> if that is wrong, client will be kicked anyway 14:23:16 <TrueBrain> for reading, yes 14:23:17 <TrueBrain> for writing, no 14:23:19 <frosch123> since the pipe is broken then 14:23:34 <frosch123> well, reading is the tricky part :) for writing everything is known anyway 14:23:55 <TrueBrain> reading already works for > MTU ? 14:24:04 <frosch123> no, the buffer is the same in Packet 14:24:15 <frosch123> clients are kicked if they send bigger ones 14:24:26 <TrueBrain> ah; well, reading is the easiest to fix, yes 14:24:27 <frosch123> before we overrun the buffer :p 14:24:32 <TrueBrain> read 2 bytes in a static buffer, allocate rest of buffer 14:24:43 <TrueBrain> but sending is more tricky to resolve, in a clean way :) 14:25:01 <Alberth> just always allocate 64k ? 14:25:06 <TrueBrain> every packet? 14:25:31 <TrueBrain> then we have to make separate code for ottd_content, as that would make it boom in memory :) 14:25:35 <Alberth> you don't keep packets around do you? 14:26:25 <frosch123> they are queued in some cases 14:26:32 <TrueBrain> michi_cc: read() with SOCK_STREAM are in order; any reassembling should be done by the TCP layer (read: OS), not the application, not? :) 14:26:36 <Alberth> fair enough, if you do, it would be a bad idea 14:26:51 <TrueBrain> Alberth: ottd_content (the server-side we run at openttd.org) uses the same code; and it keeps them around a bit longer :D 14:26:57 <frosch123> but, currently we do not check whether the client sent more than needed 14:27:02 <frosch123> so, that needs a kick as well :) 14:27:25 <TrueBrain> but yeah, why not add in every Packet(), a hint to what the max size should be (for sending) 14:27:33 <TrueBrain> and change the reading to first read the 2 bytes, then allocate the buffer? 14:27:45 <TrueBrain> sounds like a much more solid solution tbh, then just increasing the buffer :D 14:27:56 <frosch123> i would change the reading to 32 bytes first, since that should fit 99% of the packages :) 14:28:29 <michi_cc> TrueBrain: In order, yes. But the application has to to know *its* packet borders (not the TCP/IP packets), i.e. two send()'s can result in one recv(). 14:28:40 <TrueBrain> michi_cc: yes, but that we handle already :) 14:28:57 <TrueBrain> (as you really really have to as application layer :)) 14:29:02 <Nemoder> what is the best way to add a 'message of the day' for players connecting to my dedicated server? 14:30:38 <michi_cc> I didn't look at the sources for this, so I guess you are right :) But I do have seen code where the author assumed that IP packet boundaries are preserved. 14:30:53 <TrueBrain> that would fail in the first real-world test tbh :P 14:31:07 <TrueBrain> but yeah .. we also use SOCK_DGRAM, where this MTU issue comes from :) 14:31:29 <michi_cc> If you only test with loop-back or LAN, it usually even holds. Over the internet OTOH... 14:32:40 <TrueBrain> frosch123: right, your suggestion to do this triggered something for me .. I doubt you can receive packet > MTU size with your patch :D 14:33:22 <TrueBrain> owh, you can ofc, but, yes 14:33:28 <TrueBrain> let me put this in words, not in thoughts :D 14:33:36 <frosch123> there is no MTU limit in the read 14:33:56 <frosch123> it reads data up to packet_size bytes 14:33:58 <TrueBrain> our code can be such a maze of files :D 14:34:27 <frosch123> res = recv(this->sock, (char*)p->buffer + p->pos, p->size - p->pos, 0); 14:34:50 <frosch123> it does that until p->size has been received or there is no more data 14:35:22 <TrueBrain> ah, yes, udp doesn't follow the same pace as tdp there, lolz 14:35:53 <TrueBrain> so basically you could delay the Packet creating till after the first PacketSize has been read 14:36:43 <frosch123> there are already two loops for that 14:36:49 <TrueBrain> exactly 14:37:07 <TrueBrain> but yeah, for reading this indeed is easy enough 14:37:14 <TrueBrain> sending .. meh 14:37:18 *** HerzogDeXtEr1 [~flex@i59F6C2FF.versanet.de] has joined #openttd 14:37:28 <frosch123> i would also add something to ReceivePackets 14:37:40 <frosch123> which checks whether the whole package has been consumed after HandlePackage 14:37:56 <frosch123> currently we do not care whether someone bloats the package to max size every time 14:38:18 <TrueBrain> well, your patch will be enjoỳable to test :D:D 14:38:51 <frosch123> oh, usually it does not take longer than 2 months to report a crash on start up 14:39:01 <TrueBrain> anyway, for readability it might be good to create a TcpPacket and UdpPacket class; adding those values on every Packet ctor is annoying to read :D 14:39:10 <frosch123> people will just use 1.4.0 to generate maps, if trunk mapgen is broken 14:39:54 <TrueBrain> for UdpPacket, set the fixed size; possibly for TcpPacket take a hint for the initial size, and make him possible to grow his buffer 14:44:00 *** HerzogDeXtEr [~flex@i59F6DA5F.versanet.de] has quit [Ping timeout: 480 seconds] 15:06:43 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 15:23:13 <Nemoder> anyone know the best way for me to add a 'message of the day' for players connecting to my dedicated server? 15:24:55 <frosch123> check bin/scripts/on_server_conenct_scr.example 15:25:07 <frosch123> or use soap if you need something more advanced 15:25:34 <frosch123> https://wiki.openttd.org/Running_Startup_Scripts 15:27:03 <Nemoder> I tried with on_server_connect but it sends the message to everyone on each connection 15:27:30 <Nemoder> is there a way to send a message only to the most recent connection? 15:27:53 <frosch123> no idea, likely not with these type of basic scripts 15:27:57 <frosch123> do you know a server which does so? 15:28:58 <Nemoder> I thought I'd seen some, but I think they were likely custom builds 15:29:12 <frosch123> unlikely 15:29:25 <frosch123> there are plenty of interfaces to attach external control software 15:29:50 <Zuu> Use a admin port client 15:30:15 <Zuu> Oh. sorry was not scrolled way down yet :-) 15:31:04 <frosch123> https://dev.openttdcoop.org/projects/soap <- soap is the standard admin tool 15:31:18 <frosch123> though it does way more than you asked for now 15:31:54 <frosch123> like a irc chat bridge 15:32:08 <frosch123> and admin commands via irc for moderators and such 15:32:56 <Nemoder> heh ok, looks complicated for just a motd. I just wanted to make sure I hadn't missed anything simple, thanks 15:33:48 <frosch123> but yes, soap sends the welcome message as private message 15:33:54 <frosch123> to the single client 15:34:51 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 15:35:03 <frosch123> andythenorth: https://www.youtube.com/watch?v=6qjPitNnCbE 15:35:21 <frosch123> sorry :p 15:35:34 <andythenorth> slow network saves me :P 15:35:44 <andythenorth> hmm, itâs loaded now 15:35:57 <andythenorth> I guess that we can all go home now, everything that can be done has been done 15:36:20 <frosch123> we cannot send 64kb json commands yet 15:37:53 <Zuu> we cannot make tech trees yet 15:40:19 <andythenorth> nah, that movie is the end of all creative efforts 15:40:34 <andythenorth> although, it didnât have rainbows 15:41:09 <Zuu> frosch123: Is there something in particular you had in mind for larger command payloads? 15:41:46 <frosch123> yes, i want to change the inferface from "send some uint32" to "send an query json structures" 15:42:10 <frosch123> i have an idea how to read/write json with newgrf, but i have to get them through the command layer :p 15:42:15 <Zuu> to reduce bit stuffing? 15:42:47 <frosch123> i want to send more than one uint32 15:42:53 <Zuu> Ah that idea with key => value pairs 15:43:28 <frosch123> a whole json structure, which allows to define arbitrary interfaces between gs and newgrf, and check for their existence/compatiblity 15:45:39 <Zuu> Nice. Hopefully it get used more than SCP. 15:46:14 <TrueBrain> SCP? 15:47:48 <Alberth> it's not secure copy :) 15:48:10 <frosch123> TrueBrain: it's an ai cheating system :p or so 15:50:06 *** DDR [~David@S0106001f16aa47bc.vc.shawcable.net] has quit [Ping timeout: 480 seconds] 15:50:10 <Zuu> Script Communication Protocl 15:50:23 <Zuu> It allows GS and AIs to talk with each other using signs. 15:51:09 <Zuu> It is built up around command sets that AIs or GSs can support. Those are abritary and up to each GS (or AI) to define and document so other authors can support them. 15:51:35 <andythenorth> hmm 15:51:42 * andythenorth considers using signs for electricit 15:51:47 <andythenorth> electricity even 15:51:53 <andythenorth> âproducing power' 15:51:56 <andythenorth> âconsuming power' 15:52:03 <Zuu> So if you play NoCarGoal (3 goal cargos), and use CluelessPlus or AIAI, they will focus on those 3 cargos until each cargo is completed and then on the remaining ones. 15:52:37 <Zuu> SCP has the side effect of signs being placed on tile 0.0 to the disslike of some players. 15:52:48 *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Ping timeout: 480 seconds] 15:53:10 <Zuu> krinn wrote most of it by the way. I wrote some docs for it. 15:56:52 <Zuu> TrueBrain: SCP explained above 15:58:08 <TrueBrain> I read, tnx :) 15:59:32 <peter1138> Anyone used it as a VPN yet? 15:59:42 <Zuu> And yes it is not secure. It is encoded in some format using the available bits in signs (they don't support all 255 byte chars, but ony the visible ones) to send messages possible split over many signs. A bit like TCP ;-) 16:00:42 <TrueBrain> why are signs used for it? 16:00:57 <Zuu> Because what would you otherwise use? 16:01:05 <TrueBrain> add support for it in OpenTTD :D 16:01:12 <TrueBrain> bit of threading issues with signs if you have more than 1 active AI :D 16:02:05 <__ln__> what would you say about: >openttd_git\src\gfx.cpp(189): warning C4146: unary minus operator applied to unsigned type, result still unsigned 16:02:54 *** zeknurn` [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 16:02:55 <Zuu> I think this was started before I joined the team and most work was done by krinn who liked to do a solution in Squirrel. Which I kind of liked to. A bit to prove that it is possible. But I agree that it would be more sensible to have a propper solution in OpenTTD. 16:03:38 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Ping timeout: 480 seconds] 16:03:38 *** zeknurn` is now known as zeknurn 16:08:02 <peter1138> But if AI can communicate directly, that's cheating ;p 16:08:21 <TrueBrain> skynet is a cheat? 16:09:32 <Zuu> AI <-> AI is only possible in SCP if the GS (server) allows it. They could still resort to planting trees at given tiles givet dates or other lower forms of communication if they wish to. :-) 16:09:52 <TrueBrain> haha :D 16:16:23 <frosch123> andythenorth: Zuu: https://wiki.openttd.org/Frosch/GS-NewGRF_Communication_via_JSON 16:17:31 <TrueBrain> frosch123: don't forget network communication can be delayed with several ticks 16:17:43 <TrueBrain> so after sending a: change state, it can take up to N ticks before reading it back shows the change 16:17:58 <TrueBrain> (just in case you didn't know about that part of the network protocol yet :D) 16:18:20 <frosch123> i am well aware of that :) 16:18:37 <frosch123> gs cannot answer synchronously 16:19:06 <TrueBrain> I mention it, because you talk about 1 command per tick; that is very true, but it suggests the command is executed the next tick 16:19:08 <TrueBrain> which is not true :) 16:19:26 <frosch123> so gs are even slower? 16:19:33 <frosch123> i mean gs run on the server 16:19:41 <frosch123> i hope at least they would manage to run one command per tick 16:19:59 <TrueBrain> well, the GS wants to talk to grfs at clients, right? 16:20:04 <TrueBrain> so this has to be done via a DoCommand 16:20:09 <TrueBrain> send over the network blabla 16:20:16 <TrueBrain> the delay between sending the command, and execution 16:20:21 <TrueBrain> is N, where N is defined by the server owner 16:20:23 <frosch123> yes, but the answer is only returned on the server 16:20:32 <frosch123> the newgrf also run on the server 16:20:40 <frosch123> the server does not have to wait for a response from the clients 16:20:49 <TrueBrain> no, but the command itself is not directly executed 16:20:52 <frosch123> it does not wait for the clients when building track either 16:20:57 <TrueBrain> you can return the return value of the test-run 16:21:16 <TrueBrain> my point is this: place track with GS, query tile if track is there 16:21:24 <TrueBrain> if delay is 5, it will take 5 ticks before you see the track 16:21:39 <TrueBrain> (also on the server ;)) 16:21:42 <frosch123> i thought it is: 1. gs sends command and is suspended, 2. server executes command on next tick, 3. gs is resumed the same tick 16:22:07 <TrueBrain> if a command is also send to clients, the "next tick" part is variable 16:22:24 <frosch123> why does the server care about the clients? 16:22:30 <TrueBrain> because we work in synced states 16:22:34 <TrueBrain> client state == server state 16:22:40 <TrueBrain> so DoCommands are delayed for N ticks 16:22:44 <TrueBrain> normally 1, but can be more 16:22:45 <frosch123> i think the server runs ahead of the clients 16:22:51 <TrueBrain> I hope not :D Would desync instantly 16:22:56 <frosch123> so for client->server->client there is a delay, but not for server->server 16:23:11 <TrueBrain> lets try this differently: say you aren an AI, and you build a station 16:23:17 <frosch123> i.e. client issues command, and the server assigns a timestamp for execution to it 16:23:18 <TrueBrain> say I put the DoCommand delay on 10 ticks 16:23:26 <TrueBrain> I build something as AI, 10 ticks later, the station is there 16:23:32 <TrueBrain> in between, both clients and server don't see the station 16:23:48 <frosch123> where is this DoCommand delay? 16:24:03 <TrueBrain> it is how the network works :) Otherwise you cannot promise synced states 16:24:09 <TrueBrain> clients and server have to do the same thing at the same time 16:24:33 <TrueBrain> so when a DoCommand happens for both server and clients, it is put to be executed on a certain frame 16:24:35 <frosch123> i think you are using a different meaning of "time" 16:24:37 <TrueBrain> which is at least 1 frame away 16:25:01 <frosch123> the server sets what the "frame time" is 16:25:15 <frosch123> when the server reaches a frame, it executed the stuff for the frame and sends it to clients 16:25:23 <TrueBrain> no 16:25:26 <TrueBrain> clients already know about it 16:25:27 <frosch123> the clients reach that frame only whatever latency they run later 16:25:50 <TrueBrain> there is no need to wait for the server to execute it 16:25:53 <frosch123> TrueBrain: well, can you speak in source code? :p 16:26:04 <TrueBrain> in the mess we call hierarcy ? :P 16:26:24 <frosch123> because in my mind, what you say makes no sense :p 16:26:47 <TrueBrain> and that is why I warn you ;) As your current documentation suggests something different than what happens :D 16:26:51 <TrueBrain> which for 99% of the servers will be fine 16:27:24 <TrueBrain> it is basically network_command.cpp 16:27:55 <TrueBrain> a DoCommandP is queued for both the server as clients to be executed on a later date 16:28:04 <TrueBrain> the command is broadcasted, and everyone puts it on its queue 16:28:10 <TrueBrain> when the frame happens, it is executed 16:28:16 <TrueBrain> (of course the server did pre-checks on it, but meh) 16:28:56 <TrueBrain> NetworkSendCommand() to be exact 16:29:00 <TrueBrain> a client sends it packet to the server 16:29:07 <TrueBrain> a server delays his packet by N 16:29:30 <TrueBrain> the delay is only there so clients can receive the packet in time 16:29:39 <TrueBrain> on high latency connections, this isn't always in the same tick 16:29:58 <TrueBrain> (and clients can walk away for M ticks since the last sync, by default .. 100 I believe) 16:30:39 <frosch123> c.frame = _frame_counter_max + 1; <- so, your N seems to be 1 16:30:48 <TrueBrain> euhmz? That is 1? Oh-oh :D 16:30:58 <TrueBrain> *creates edge case to create desyncs* 16:31:02 <frosch123> so, either 1 command per tick, or 1 command per 2 ticks 16:31:13 <frosch123> and your desync reasoning makes no sense 16:31:32 <frosch123> clients do not run in sync with the server as in atomic clocks run in sync 16:31:37 <frosch123> there is no reason for that 16:32:08 <frosch123> the server tells the clients up to what frame they are allowed to proceed, and guarantees them that there won't be any commands till then 16:32:39 <frosch123> _frame_counter_max = _frame_counter + _settings_client.network.frame_freq; <- ah, it is bigger than 1:) 16:32:50 <frosch123> but still, the value only affects the latency, not desyncs 16:32:53 <TrueBrain> frame_freq defaults to 1, I hope 16:33:11 <frosch123> 0 even 16:33:23 <TrueBrain> 0? 0 makes little sense 16:33:27 <frosch123> so, still 1 or 2 ticks per command 16:33:32 <TrueBrain> commands cannot be excuted on the same tick 16:34:02 <frosch123> i talk about the time between server receiving a cmomand, and executing it 16:34:18 <frosch123> the time it takes for the command to travel from client to server does not matter 16:34:20 <frosch123> it is zero for gs 16:34:49 <TrueBrain> yes, and put in a local queue to be executed 1 tick later 16:34:56 <frosch123> any delay you imagine may increase the lag for clients to get their commands executed 16:34:57 <TrueBrain> (or rather, 1 frame) 16:35:07 <frosch123> but no matter what small value you assign to it, it will never desync 16:35:30 <TrueBrain> there is a lovely edge case, but we can talk about hypotheticals, or I can just find the line of code :) 16:37:30 <frosch123> "This is done via a command, so at most one trigger per (1 + network.frame_freq) ticks (by default 1)." <- i changed it to that. happy? :p 16:37:51 <TrueBrain> well, to be clear, was just an awareness issue 16:37:56 <TrueBrain> so you understand it is at play 16:38:31 <frosch123> we just need a method for gs to send multiple commands at once :p 16:38:38 <frosch123> so they do not get suspended immediately :p 16:38:51 <TrueBrain> if they don't care about the answer, that is possible 16:39:38 <frosch123> TrueBrain: not sure whether you want to allow gs to spam everyone with thousands of commands per tick :p 16:39:54 <TrueBrain> there is a max amount of commands a frame can contain 16:39:59 <TrueBrain> so meh :P 16:40:04 <frosch123> so, the current limit ensured gs authors to think somewhat 16:40:42 <frosch123> TrueBrain: i think that limit only applies to clients, not for the server 16:42:14 <Zuu> A query for instant information would not use a DoCommand at all. Instead it would only use up one oopcode. 16:42:18 <TrueBrain> ah, okay, the +1 mentioned above is unrelated to the frame_freq 16:42:23 <TrueBrain> pfew, was about the so, that would be baadddd 16:42:39 <TrueBrain> (damn, globals are hard to track in our code) 16:43:40 <TrueBrain> frosch123: what I meant with desync, is that if a server executes some commands (say, from a GS) earlier than clients, random is no longer in order, and bad things happens 16:43:52 <TrueBrain> but the +1 is completely unrelated 16:45:06 <TrueBrain> lol, that comment there is also very vague and seemly wrong in assumption :D hihi :) 16:45:20 <TrueBrain> owh, the days I thought NewGRFs didnt touch the randomizer .. 16:46:07 <Zuu> Btw, do we today have the concept of read only callbacks in NewGRF? 16:46:15 <frosch123> yes 16:46:19 <TrueBrain> okay, to summarize (just for my own sanity): a command executed on the server is delayed to be executed after frame_freq + 1 (frame_counter_max) 16:46:21 <frosch123> all the gui callbacks :) 16:46:27 <frosch123> all the command test-runs 16:47:05 <frosch123> TrueBrain: yes, and _frame_counter_max what frame the server allowed the clients to proceed to 16:47:13 <TrueBrain> yes 16:47:23 <frosch123> which may be hours after the server executed it, if the clients are happy to lag behind that long 16:47:26 <TrueBrain> so the states are always identical, and the commands they execute per tick is always the same, in the same order 16:47:42 <TrueBrain> yeah, lets not compare anything to real-time 16:47:43 <frosch123> it will only make the player on that client suffer to wait for their mouse clicks to return something :p 16:47:47 <TrueBrain> we purely talk about frame delays :) 16:48:06 <TrueBrain> so yeah, GS too are delayed, despite them being on the server 16:48:16 <TrueBrain> and indeed, frame_freq can be 0, because of the + 1 on it every time :D 16:48:19 <TrueBrain> silly :P 16:49:18 <TrueBrain> (basically what I tried to do for AIs, and that extends to GS because of reasons (:P), is to keep them as much acting as a client as possible) 16:49:35 <TrueBrain> in fact, a client can just load an AI which does his actions for him :P (and it still works) 16:55:18 <TrueBrain> frosch123: btw ,double checked, but commands are send to the clients before the server executes them; so the server is just a client of to himself :D 17:05:02 <TrueBrain> funny, this type of network protocol often is refered to as lockstep 17:05:12 <TrueBrain> but when you look that up, you find all kind of funny shit totally unrelated :D 17:08:50 <TrueBrain> frosch123: server commands also obey the commands_per_frame btw :D So we should be safe :P 17:10:03 <TrueBrain> although it is more a: command_per_frame_per_queue 17:10:18 <TrueBrain> but that makes sense I guess .. (if you have more clients, you expect more commands) 17:39:00 <andythenorth> frosch123: I just read the GS/NewGRF stuff, makes sense 17:39:02 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 17:40:43 <frosch123> but we didn't play the prototype yet, did we :p 17:40:49 <andythenorth> nah 17:41:19 <andythenorth> thereâs enough possibilities + constraints to keep people busy figuring out how to use it 17:41:30 <TrueBrain> and never end up using it? :D 17:43:05 <andythenorth> eh maybe :) 17:56:21 *** NGC3982 [~kruger@h215n4-vj-d3.ias.bredband.telia.com] has quit [Ping timeout: 480 seconds] 18:00:12 *** NGC3982 [~kruger@h215n4-vj-d3.ias.bredband.telia.com] has joined #openttd 18:01:03 *** Guest3824 [urdh@bnc3.sollidi.us] has quit [Quit: boom] 18:05:14 <Zuu> The prototype is quite fun to play. It would probably be better if secondary industries started at 33% though. Now they quickly boom as Busy Bee is quite good at giving the same industry more goals. 18:06:06 <Zuu> But it is kind of reward you to build up a structure where you are flexible to send mail to new targets as you get new mail goals. 18:06:39 <Zuu> Though, often I found it picked towns as goals that had no primary industries :-/ 18:13:07 <andythenorth> Zuu: the code I need to write, that I havenât, is to reduce BB repeating goals :) 18:13:20 <andythenorth> but I donât even understand what data structure Iâd store that in yet :) 18:13:52 <Zuu> In general you store data in tables, but you can also use arrays. 18:14:27 <andythenorth> tables looked a bit like dicts when I read the squirrel docs 18:14:32 <Zuu> tabels is key => value pairs. arrays are lists of data with integer keys without holes. 18:14:42 <Zuu> yep they are like dicts in python 18:14:45 <andythenorth> is table order reliable? 18:14:58 <Zuu> I don't know 18:16:02 <Zuu> There is also GSList, but it can only store integer values. 18:16:17 <Zuu> GSList is useful because of valuators and sort. 18:16:34 <Zuu> local list = GSTownList(); 18:16:34 <andythenorth> in python, for something like this Iâd just stick the goal objects in a list 18:16:47 <Zuu> list.Valuate(GSTown.GetPopulation) 18:16:52 <andythenorth> if I was really worried about performance, Iâd stick just the destination-cargo pairs in a list 18:16:52 <Zuu> list.KeepAbove(500) 18:16:55 <Zuu> For example. 18:17:25 <Zuu> That would give you a list of all towns with more than 500 inhabitants. 18:17:39 <andythenorth> neat 18:18:03 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 18:18:11 <Zuu> One word of warning, GSList() and its friends give you an instance. Those cannot be saved in save games. 18:18:28 <Zuu> Only elementary data types, arrays and tables can be saved. 18:19:19 <Zuu> Which kind of suggests a more procedural style of programming where all data is in tables of the main class so it is quick to save (and Load) instead of asking classes to save their data as tables. 18:19:50 <Zuu> That said, many of my scripts use the class based structure with save/load. So I have not followed the better way myself :-p 18:20:17 <frosch123> how rude :p 18:20:43 <Zuu> Well in Producing Bee, I use the procedural approach. :-) 18:20:57 <Zuu> Hmm Bee Productive* 18:21:10 <Zuu> I keep confusing myself about the name. :-p 18:21:46 <frosch123> may be a curse :) 18:21:56 <frosch123> see bee rewards/awards :p 18:22:13 <Zuu> :-) 18:25:26 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 18:26:08 <Zuu> Oh andythenorth I missed you dropped out. I wrote some more. :-) 18:26:18 * andythenorth logs 18:28:05 <andythenorth> thanks 18:36:29 <Alberth> you can just walk over the entries in a table 18:36:46 <Alberth> or probably better, use the goals as key 18:37:27 *** gelignite [~gelignite@mue-88-130-66-087.dsl.tropolys.de] has joined #openttd 18:37:27 <Alberth> (ie the industry/town key to the list of cargoes or so 18:38:12 * andythenorth should look at this again in 2 weeks :) 18:38:21 <andythenorth> holidays soon 18:38:33 * andythenorth needs to learn some GS basics sometime 18:38:35 <Alberth> it happens around this time of the year :) 18:40:14 <Zuu> local t = {}; t.rawset(key, value); 18:40:44 <Zuu> there is also .rawget(key) and .rawin(key). The last one check if the key exist. 18:41:02 <Alberth> :o 18:41:08 <Alberth> new magic words :) 18:41:11 <Zuu> If the key name is hardcoded/known, you can write it out in source code: t.town 18:42:05 <Zuu> You can also do similar magic on classes :-) 18:42:20 <Alberth> yeah, spooky small languages :p 18:42:59 <Alberth> lua does that too 18:43:09 <Alberth> not sure what python3 does there 18:54:58 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 18:55:14 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd [] 19:11:40 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 19:21:12 *** jottyfan [~jottyfan@p54B7E411.dip0.t-ipconnect.de] has joined #openttd 19:28:38 * andythenorth must to bed 19:28:40 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 19:36:08 *** supermop [~supermop@cpe-67-244-121-219.nyc.res.rr.com] has joined #openttd 19:48:23 *** Wolf03 [~wolf01@host20-73-dynamic.5-87-r.retail.telecomitalia.it] has joined #openttd 19:48:23 *** Wolf01 is now known as Guest1493 19:48:23 *** Wolf03 is now known as Wolf01 19:52:41 *** Guest1493 [~wolf01@0001288e.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:54:47 <peter1138> Hmm, trying to update an intermediate CA certificate (hash algo), however the existing certificates will no validate with it... what've I done wrong? :S 20:02:16 *** frosch123 [~frosch@x5f746ab7.dyn.telefonica.de] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 20:02:34 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd 20:02:37 <Quatroking> hi 20:02:42 <Quatroking> can you use FIRS on an existing game 20:04:22 <Taede> no, one cannot add/remove newgrfs in a running game 20:05:04 <Quatroking> so if I want to use FIRS I have to start a new map? 20:05:09 <Eddi|zuHause> yes 20:05:09 <Taede> yes 20:05:13 <Quatroking> ok 20:49:45 *** jottyfan [~jottyfan@p54B7E411.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 20:55:36 *** supermop [~supermop@cpe-67-244-121-219.nyc.res.rr.com] has quit [Ping timeout: 480 seconds] 21:06:32 *** Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has quit [Quit: Leaving] 21:24:10 *** gelignite [~gelignite@mue-88-130-66-087.dsl.tropolys.de] has quit [Quit: http://bit.ly/1kso8Ta] 21:30:22 *** sla_ro|master [slamaster@95.76.27.245] has quit [] 21:52:49 *** Zuu [~Zuu@h-114-162.a98.priv.bahnhof.se] has quit [Quit: Leaving] 21:59:12 *** roidal [~roland@194-152-171-142.adsl.highway.telekom.at] has joined #openttd 22:05:24 <argoneus> I feel like playing this game again with some friends 22:05:36 <argoneus> do the nightly builds have any cool new features or is the stable fine? 22:05:42 <argoneus> I wasn't following it too much recently :< 22:06:16 <Sylf> new since when? 22:06:31 <Sylf> new since 1.5? 22:06:42 <argoneus> new since the stable release 22:06:42 <argoneus> 1.5.1 22:07:17 <Sylf> I don't know of anything cool yet 22:11:20 <argoneus> V453000: are you there friend? 22:12:43 *** Progman [~progman@p57A182F3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:13:25 <argoneus> or maybe someone else knows 22:13:29 <argoneus> is there a "recommended" starting date for NUTS? 22:13:47 <argoneus> I know it's "whatever date you want", but I'm not sure how the early trains are 22:22:38 <Sylf> NUTS start in year 0 22:23:05 <Sylf> but if you start in 1900, you get constant stream of new trains until 2100 22:23:52 <Sylf> I like starting in 1920 with NUTS. 22:31:52 <argoneus> im wondering 22:31:56 <argoneus> if you don't use a road vehicle pack 22:32:02 <argoneus> how do you handle large cities with buses? 22:32:10 <argoneus> to make them grow and to transport people 22:32:35 <argoneus> using the german road vehicle pack with trams that can transport 200 people seems like cheating 22:32:39 <Sylf> You probably don't, or ignore the pax waiting at pus stops 22:32:49 <argoneus> how do people manage in the pro games? 22:32:52 <argoneus> or do they use road vehicle packs 22:33:59 <Sylf> I've seen everything from town grf that controls pax generation, to using trams with high capacity, to trains through the town (metro trains) 22:34:23 <argoneus> I see 22:34:32 <argoneus> wait 22:34:37 <argoneus> town grf that controls pax generation? tell me more 22:36:15 <Sylf> http://pikka.users.tt-forums.net/wiki/index.php/TaI_UK_Houses 22:37:19 <argoneus> oh wow 22:38:53 <argoneus> well 22:38:59 <argoneus> considering the people I'll be playing with are new to the game 22:39:03 <argoneus> I probably shouldn't go full NUTS 22:39:17 <argoneus> or god forgive FIRS 22:39:35 <Sylf> do classic UKRS 22:39:38 <Sylf> it's a good set 22:39:51 <argoneus> aren't the UKRS trains super slow? 22:40:00 <Sylf> still one of my favorite, despite ukrs2 22:40:01 <Sylf> slow? 22:40:09 <Sylf> slow trains, or slows down the game? 22:40:13 <argoneus> slow trains 22:40:25 <Sylf> no, unless you're expecting maglev trains 22:43:02 <argoneus> Sylf: you mean UK Renewal Set? 22:43:04 <argoneus> or UK Railway Set 22:43:51 <Sylf> Renewal set 22:43:59 <argoneus> is the UKRS2 bad? 22:44:05 <Sylf> It's not bad at all. 22:44:26 <Supercheese> UKRS2 is great 22:44:30 <Supercheese> even has an addon set 22:44:33 <argoneus> I'm a bit overwhelmed with all the grfs 22:44:38 <argoneus> only played vanilla and NUTS 22:44:42 <argoneus> but NUTS is not forgiving to new players 22:44:49 <Sylf> it's not? 22:44:57 <argoneus> from what I've seen 22:45:00 <Sylf> NUTS is only overwhelming with its number of choices 22:45:01 <argoneus> even refitting is unintuitive 22:45:05 <argoneus> to new people 22:45:10 <argoneus> like people who never even heard of the game 22:45:32 <Sylf> if refitting is a game stopper, then any newgrf train is not very good 22:45:38 <argoneus> hmm 22:45:43 <argoneus> I'll just use nuts and german vehicle road set 22:45:54 <argoneus> that will give people a lot of options to do whatever 22:46:37 <argoneus> ISR, NUTS, GRV, TBRS 22:47:02 <argoneus> are there any GRFs you guys can't live without? like town graphics or road graphics or whatever 22:47:18 <argoneus> having so many options is good and bad at the same time ._. 22:47:26 <Sylf> no 22:47:33 <Sylf> vanilla openttd is great. 22:47:53 <Sylf> loading different combination of newgrf is great. 22:47:57 <argoneus> I'll just keep these four for now 22:48:01 <argoneus> should be fine 22:48:10 <argoneus> most people will ever use trains only anyway 22:50:13 <argoneus> wow, there's no GRF for european city names 22:59:28 *** roidal [~roland@194-152-171-142.adsl.highway.telekom.at] has quit [Quit: WeeChat 1.2] 23:04:35 *** Nathan1852__ [~Nathan185@p5DC1156F.dip0.t-ipconnect.de] has joined #openttd 23:11:33 *** Nathan1852_ [~Nathan185@p5DC1156F.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 23:12:25 <Wolf01> 'night 23:12:32 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 23:15:25 <argoneus> is there a way 23:15:32 <argoneus> to download all the newgrfs a savegame needs? 23:15:35 <argoneus> with a dedicated linux server 23:16:06 <glx> there are console commands 23:16:15 <argoneus> there's only content select X to do it manually 23:27:13 *** Nathan1852 [~Nathan185@p5B216E92.dip0.t-ipconnect.de] has joined #openttd 23:32:35 *** Nathan1852__ [~Nathan185@p5DC1156F.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 23:33:39 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit [] 23:34:51 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Quit: Leaving] 23:39:34 *** Nathan1852_ [~Nathan185@p5DC11BE0.dip0.t-ipconnect.de] has joined #openttd 23:39:55 *** Nathan1852__ [~Nathan185@p5B216D31.dip0.t-ipconnect.de] has joined #openttd 23:45:57 <argoneus> hmmm 23:46:04 <argoneus> I swear there was a switch to auto kill a company for inactivity 23:46:08 <argoneus> but I can't find it in the config 23:46:56 <argoneus> ah, autoclean_companies 23:47:09 *** Nathan1852 [~Nathan185@p5B216E92.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 23:47:09 *** Nathan1852 [~Nathan185@p5B216DA6.dip0.t-ipconnect.de] has joined #openttd 23:47:39 *** Nathan1852_ [~Nathan185@p5DC11BE0.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 23:53:39 *** Nathan1852__ [~Nathan185@p5B216D31.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]