Log for #openttd on 26th July 2015:
Times are UTC Toggle Colours
00:09:19  *** DDR [] has quit [Remote host closed the connection]
00:20:29  *** HerzogDeXtEr1 [] has quit [Quit: Leaving.]
00:30:57  *** DDR [] has joined #openttd
00:49:34  *** Nathan1852__ [] has joined #openttd
00:56:56  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
01:01:10  *** kirjs_______ [] has quit []
01:01:12  *** kirjs_______ [] has joined #openttd
01:35:58  *** Nathan1852_ [] has joined #openttd
01:43:05  *** Nathan1852__ [] has quit [Ping timeout: 480 seconds]
01:44:28  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
01:48:26  *** gelignite [] has quit [Quit:]
01:50:35  *** Pereba [~UserNick@] has quit [Quit: AdiIRC - are you ready for the future? (]
01:53:38  *** Taco [~kitty@2407:500::2:981d:d5e9] has quit [Ping timeout: 480 seconds]
02:01:08  *** Quatroking [] 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 [] has joined #openttd
02:46:42  *** ade [~ade@] has joined #openttd
02:46:44  *** ade is now known as Ade
02:47:25  *** glx [] 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 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@] has quit [Quit: Leaving]
04:56:01  *** Eddi|zuHause [] has quit []
04:56:15  *** ade [~ade@] has joined #openttd
04:56:16  *** ade [~ade@] has quit [autokilled: This host may be infected. Mail with questions. BOPM (2015-07-26 04:56:16)]
04:56:17  *** Eddi|zuHause [] 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 [] has joined #openttd
05:35:36  *** andythenorth [] has joined #openttd
05:50:59  *** andythenorth [] has quit [Quit: andythenorth]
06:11:14  *** andythenorth [] has joined #openttd
06:29:50  <andythenorth> o/
06:29:54  <Alberth> moin
07:00:17  *** Progman [] has joined #openttd
07:05:54  *** Pensacola [] has joined #openttd
07:16:44  *** sla_ro|master [slamaster@] has joined #openttd
07:34:38  *** Pensacola [] has quit [Remote host closed the connection]
07:35:20  *** andythenorth [] has quit [Quit: andythenorth]
07:41:51  *** Progman [] has quit [Remote host closed the connection]
07:50:51  *** Zuu [] has joined #openttd
07:51:12  <Zuu> Hello
07:57:57  <Alberth> moin
08:06:44  *** HerzogDeXtEr [] has joined #openttd
08:18:07  *** Flygon_ [] has joined #openttd
08:21:46  *** Flygon [] has quit [Ping timeout: 480 seconds]
08:26:28  *** smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 4.2.0 Equilibrium]
08:26:32  *** smoke_fumus [~smoke_fum@] 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?
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>
09:05:39  <__ln__> thanks. question #2: why isn't that listed at
09:06:03  *** Flygon_ [] has quit [Read error: Connection reset by peer]
09:06:27  <peter1138> also works
09:06:28  <peter1138> Hmm.
09:07:52  <peter1138> Latter one is listed indirectly.
09:08:17  *** gelignite [] has joined #openttd
09:14:33  *** Wolf01 [] has joined #openttd
09:14:57  <Wolf01> o/
09:16:25  <Zuu> Eddi|zuHause: Thanks, that solved the problem.
09:16:54  *** andythenorth [] has joined #openttd
09:17:00  <Wolf01> o/
09:20:45  <Alberth> o/
09:23:51  *** frosch123 [] 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 [] 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 [] has quit [Read error: Connection reset by peer]
09:53:46  *** zeknurn [] has joined #openttd
09:54:54  *** wicope [] 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 [] 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 [] 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 [] has quit [Ping timeout: 480 seconds]
10:46:45  *** pthagnar [] has joined #openttd
10:59:27  *** pthagnar [] has quit [Remote host closed the connection]
11:00:20  *** tycoondemon [] 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:
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 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?
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 [] 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 [] 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 [] 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_ [] 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 [] 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 [] has joined #openttd
11:49:32  *** mode/#openttd [+v tokai|noir] by ChanServ
11:56:23  *** tokai [] has quit [Ping timeout: 480 seconds]
11:57:45  <andythenorth> “when I made Thomas, it made it more like
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 [] 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:
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 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 [] 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 [] has joined #openttd
12:54:30  *** openttd-user [] has quit [Quit: leaving]
12:55:27  *** andythenorth [] 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> <- about books [german] [nsfw]
13:17:42  *** Wormnest [] 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 [] has joined #openttd
13:27:38  *** mode/#openttd [+v glx] by ChanServ
13:36:42  *** gelignite [] has quit [Quit:]
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 [] 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 [] 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 [] 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> <- 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@] 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 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 [] 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 [] has quit [Ping timeout: 480 seconds]
15:06:43  *** andythenorth [] 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>
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> <- 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 [] has joined #openttd
15:35:03  <frosch123> andythenorth:
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 [] 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@] 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` [] 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 [] 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:
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 +; <- 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 [] 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 [] has quit [Ping timeout: 480 seconds]
18:00:12  *** NGC3982 [] has joined #openttd
18:01:03  *** Guest3824 [] 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 [] 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 [] 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 [] 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:
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 [] has quit [Quit: andythenorth]
18:55:14  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
19:11:40  *** andythenorth [] has joined #openttd
19:21:12  *** jottyfan [] has joined #openttd
19:28:38  * andythenorth must to bed
19:28:40  *** andythenorth [] has quit [Quit: andythenorth]
19:36:08  *** supermop [] has joined #openttd
19:48:23  *** Wolf03 [] 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 [] 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 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
20:02:34  *** Quatroking [] 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 [] has quit [Quit: Konversation terminated!]
20:55:36  *** supermop [] has quit [Ping timeout: 480 seconds]
21:06:32  *** Wormnest [] has quit [Quit: Leaving]
21:24:10  *** gelignite [] has quit [Quit:]
21:30:22  *** sla_ro|master [slamaster@] has quit []
21:52:49  *** Zuu [] has quit [Quit: Leaving]
21:59:12  *** roidal [] 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 [] 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>
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 [] has quit [Quit: WeeChat 1.2]
23:04:35  *** Nathan1852__ [] has joined #openttd
23:11:33  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
23:12:25  <Wolf01> 'night
23:12:32  *** Wolf01 [] 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 [] has joined #openttd
23:32:35  *** Nathan1852__ [] has quit [Ping timeout: 480 seconds]
23:33:39  *** oskari89 [] has quit []
23:34:51  *** Quatroking [] has quit [Quit: Leaving]
23:39:34  *** Nathan1852_ [] has joined #openttd
23:39:55  *** Nathan1852__ [] 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 [] has quit [Ping timeout: 480 seconds]
23:47:09  *** Nathan1852 [] has joined #openttd
23:47:39  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
23:53:39  *** Nathan1852__ [] has quit [Ping timeout: 480 seconds]

Powered by YARRSTE version: svn-trunk