Back to Home / #openttd / 2015 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2015-07-26

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