IRC logs for #openttd on OFTC at 2015-07-26
⏴ go to previous day
01:12:36 *** Hiddenfunstuff has quit IRC
02:49:34 *** Nathan1852__ has joined #openttd
03:01:12 *** kirjs_______ has joined #openttd
03:35:58 *** Nathan1852_ has joined #openttd
04:47:57 <Ade> version = sys.version_info
04:47:57 <Ade> if version[0] < 3 or (version[0] == 3 and version[1] < 2):
04:47:57 <Ade> sys.exit('ERROR: Sorry, Python 3.2 or later is required for this application.')
04:48:42 <Ade> I use linuxmint17.1,the python is 2.7,the python3 is 3.4
04:49:34 <Ade> ade@ade-desktop ~/Downloads/nml $ python setup.py install
04:49:35 <Ade> ERROR: Sorry, Python 3.2 or later is required for this application.
04:49:35 <Ade> ade@ade-desktop ~/Downloads/nml $
05:02:25 <Ade> ok ,I Have change the python to python3.4
05:02:40 <Ade> ade@ade-desktop ~/Downloads/nml $ python
05:02:40 <Ade> Python 3.4.0 (default, Apr 11 2014, 13:05:11)
05:02:40 <Ade> Type "help", "copyright", "credits" or "license" for more information.
06:56:17 *** Eddi|zuHause has joined #openttd
07:10:59 *** Alberth has joined #openttd
07:10:59 *** ChanServ sets mode: +o Alberth
07:15:17 *** pthagnar has joined #openttd
07:35:36 *** andythenorth has joined #openttd
08:11:14 *** andythenorth has joined #openttd
09:00:17 *** Progman has joined #openttd
09:05:54 *** Pensacola has joined #openttd
09:16:44 *** sla_ro|master has joined #openttd
10:06:44 *** HerzogDeXtEr has joined #openttd
10:18:07 *** Flygon_ has joined #openttd
10:26:32 *** smoke_fumus has joined #openttd
10:43:23 <Zuu> With BeeProductive, transporting coal and other things to a black hole factory become even less interesting. :-)
10:49:28 <Zuu> Or am I doing it wrong when clearing the bit?
10:50:15 <Zuu> I end up with industries having -2147483648 in their persistent store.
10:53:32 <Eddi|zuHause> that is what 0x80000000 is
10:54:15 <Zuu> hmm, so my assumption to use - to clear it out didn't work then.
10:54:42 <Eddi|zuHause> no, -2^31 = 2^31
10:55:26 <Eddi|zuHause> no, it's usually depending on the interpretation whether it's int or uint
10: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.
10:57:29 <Eddi|zuHause> anyway, use &0x7FFFFFFF to clear out bit 31
10: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
10:58:35 <Zuu> I tried ? operator first, but it didn't seem to work.
10:59:52 <Eddi|zuHause> you might want to try something like STORE_PERM(condition?new_value:old_value)
11:01:29 <Eddi|zuHause> or alternatively: switch(condition) {0: switch_that_doesn't_store; switch_that_stores;}
11:02:33 <__ln__> what's the actually working url to openttd's git repo?
11:07:52 <peter1138> Latter one is listed indirectly.
11:08:17 *** gelignite has joined #openttd
11:16:25 <Zuu> Eddi|zuHause: Thanks, that solved the problem.
11:16:54 *** andythenorth has joined #openttd
11:23:51 *** frosch123 has joined #openttd
11: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. :-)
11:35:55 <Zuu> But it is quick to disable that check.
11:43:10 *** Hiddenfunstuff has joined #openttd
11:44:00 <frosch123> i had more thoughts on json
11:44:05 <frosch123> but it's a long route :p
11:47:24 <DorpsGek> Commit by frosch :: r27340 /trunk (11 files in 4 dirs) (2015-07-26 11:47:17 +0200 )
11:47:25 <DorpsGek> -Fix [FS#6338]: Silence warning by moving _string_colourmap to a file no its own. (Cif)
11:53:46 *** zeknurn has joined #openttd
11:56:49 <DorpsGek> Commit by frosch :: r27341 trunk/src/town_gui.cpp (2015-07-26 11:56:43 +0200 )
11:56:50 <DorpsGek> -Fix [FS#6332]: Do not rerandomise the town name when only cost-estimating the founding.
12:13:22 *** openttd-user has joined #openttd
12: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?
12:14:28 <Zuu> How midi sounds depend on the sound font your sound card have.
12: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.
12:15:19 <frosch123> are you sure there is still hardware with sound fonts? :p
12:15:41 <Zuu> I guess it is done in the driver these days.
12:15:51 <Zuu> Also if you use OpenMSX, it has different songs than TTD.
12:16:07 <frosch123> openttd-user: are you sure you selected the same music set in game options?
12:16:10 <Zuu> You can copy the midi-files from TTD if you have a copy of TTD for windows.
12:18:48 <peter1138> There is still hardware with sound fonts.
12:19:11 <frosch123> external keyboards?
12:19:17 <peter1138> I haven't seen an ISA slot for a while though :p
12:19:42 <peter1138> Do emu10k-based cards still exist?
12:20:32 <peter1138> Heh, they keyboard I want costs ~£1000 and... doesn't make its own sound. Pom te pom.
12:21:57 <peter1138> Crap, didn't win the Euromillions :(
12:24:35 <openttd-user> frosch123: I can only select OpenMSX
12: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
12:25:55 <frosch123> well, neither openttd nor openmsx changed anything
12:26:08 <frosch123> so, maybe you updated your windows, got a different computer or something
12:26:22 <blathijs> Or perhaps you had the original Open
12:26:35 <blathijs> Or perhaps you had the original TTD songs before but not now?
12:26:35 <frosch123> neither openttd nor openmsx actually define the instruments, your sound drivers do that
12: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
12:27:35 <openttd-user> blathijs: No, I did not have the TTD files
12:28:23 <frosch123> ah, linux :) ok, then i actually believe that some nerd may have updated the sound fonts :p
12:28:34 <frosch123> i wouldn't expect any commercial thing to bother about that
12: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.
12:29:26 <openttd-user> frosch123: Do you mean that someone updated them in the system, or in openttd?
12:29:44 <blathijs> openttd-user: In the system
12:30:31 <openttd-user> blathijs: where in the system could that be?
12: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...
12:31:01 <Flygon> MIDI's a mess anyway :(
12:31:12 <Flygon> Shame Windows never ever encouraged decent tracker support
12:32:57 <openttd-user> Maybe the soundfonts come in with timidity?
12: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)
12:34:43 <openttd-user> blathijs: strange, I don't have it installed, would you suggest to install it?
12:38:16 <blathijs> openttd-user: Could be that timidity is using another soundfont package, then
12:46:45 *** pthagnar has joined #openttd
13:04:36 <andythenorth> can haz new features? o_O
13:05:49 <Zuu> Yeah, why cannot I place fences like in RCT?
13:07:08 * andythenorth just avoiding working on Road Hog
13:07:16 <andythenorth> no actual ponies wanted right now :P
13: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.
13:10:52 <andythenorth> compiled binaries :P
13:11:22 <andythenorth> we don’t really have pre-compiled experimental branches do we?
13:11:27 <andythenorth> just useless patch packs
13:11:50 <Zuu> That asume some set up with the compile farm that I'm clueless about how to do.
13: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.
13:12:26 <andythenorth> you’ll have to rely on some community member to compile some buggy patch pack made up of bad features :P
13:13:11 <Zuu> I could upload a Windows binary. After all I have compiled a release build for myself. :-)
13:13:23 * andythenorth has ‘views’ about patch packs apparently :)
13: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.
13:18:58 <frosch123> andythenorth: don't blame the packs :p
13:19:50 <frosch123> Zuu: i wondered whether adressing by town+type has any use :p
13:19:57 <andythenorth> I blame the people who make spurious bug reports because they’re using a pack :)
13: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. :-)
13:20:54 <TrueBrain> Zuu: you are aware the CF can compile any SVN, Git (branch) and HG (branch), right? :P
13:21:19 <TrueBrain> just a matter of asking the right persons about it :D
13: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.
13:21:34 <frosch123> TrueBrain: can we actually make the branch name a variable?
13:21:59 <frosch123> i mean we do not need automatic builds, but builds of random branches :)
13:22:53 <andythenorth> Zuu: w.r.t area command, I would guess that ‘all industries per town’ is a more common case
13: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 :-)
13:23:05 <andythenorth> going by a square map section seems odd
13:23:14 <TrueBrain> Zuu: anything that is public works
13:23:32 <TrueBrain> so if you have any public hg head with the correct code, that would work fine
13:23:42 <TrueBrain> but yes, you do need to unroll the queue; the CF cant do that for you :D
13:24:07 <TrueBrain> (and remember that if you like you can push a hg to your dev-space :P)
13:24:27 <frosch123> but #devzone may be more useful :p
13:24:39 <Zuu> I didn't knew I could, but it may be in some instruction I got.
13:25:01 <TrueBrain> if it is OpenTTD related, you can pretty much do everything on your devspace :P
13:25:19 <TrueBrain> but I agree with frosch123, it would be better to push it via openttdcoop :) They have more specified software for it :)
13:26:06 <andythenorth> frosch123: you have a wishlist for a new newgrf version?
13:26:19 * andythenorth remembers seeing one somewhere
13:26:33 <frosch123> andythenorth: yes, but it is an insane one (intentionally)
13: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?
13:27:58 <Zuu> I used branches a bit in git, but never in hg.
13:28:05 <frosch123> Zuu: it's easier to let coop pull from openttd.org first
13:28:16 <frosch123> unless you have good upload speed :p
13:28:33 <TrueBrain> Zuu: branches in hg are a ghost :P
13:29:31 <andythenorth> “seasonal acceptance/production (predictable multiple changes per year)”
13:29:33 <TrueBrain> just you have to make sure that HEAD on the branch is your code, and we are golden :)
13:29:41 <TrueBrain> Zuu: works too if you like; basically, what-ever is easiest for you
13:29:43 <andythenorth> conditional orders: “there is a y in the month"
13: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
13:30:02 <Zuu> I prefer learning more git over hg. While hg may be better, real world (=work) uses git.
13: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
13:30:53 <TrueBrain> well, depends on who can trigger it, basically :P
13:31:11 <frosch123> no automatic trigger :)
13:31:28 <TrueBrain> the CF executes a few scripts while compiling
13:31:42 <TrueBrain> it would be rather trivial to craft a code version that does nasty things :P
13:31:42 <frosch123> i just feel that we sometimes need a single build of a single patch
13:31:50 <TrueBrain> so there is trust involved :)
13:31:56 <frosch123> setting up a new farm which builds daily is of no use
13:32:24 <TrueBrain> farm entries for non-official stuff runs "on change" once a (day|week) anyway ;)
13:32:44 <frosch123> yes, but it needs a separate farm for every branch
13: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
13:33:08 *** Supercheese has joined #openttd
13:33:16 <frosch123> and i think we are talking about build-only-once stuff
13:33:18 <TrueBrain> whoho, twice as productive! Tnx peter1138 :)
13:33:30 <TrueBrain> frosch123: if there is a wish for that, it can be arranged
13:33:37 <TrueBrain> there are some issues to overcome, but nothing fancy
13:33:44 <TrueBrain> (branch-names for example)
13:34:00 <frosch123> i am thinking tags only
13:34:08 <TrueBrain> no, branch-names, like
13:34:14 <TrueBrain> openttd-custom-mybranch-r12345
13:34:31 <frosch123> openttd-custom-mytag123
13:34:44 <TrueBrain> that is not how the scripts work atm ;)
13:34:51 <TrueBrain> like I said, stuff to overcome :)
13:34:55 *** Nathan1852_ has joined #openttd
13:35:15 <Alberth> git branches ~ hg tags
13:36:01 <frosch123> well, openttd-custom-mytag-myhash would be about the same
13:37:40 <frosch123> with "tag" i just mean a fixed revision, and no moving-head like a branch
13:38:11 <andythenorth> -alpha or -experimental or -rc or whatever
13:38:22 <andythenorth> or just the hash?
13: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
13:42:21 <TrueBrain> Hardpack, last build, 1 year ago
13:42:26 <TrueBrain> TTIP, last build, 10 months ago
13:42:29 <TrueBrain> guess it is time to remove those :P
13:49:29 *** tokai|noir has joined #openttd
13:49:29 *** ChanServ sets mode: +v tokai|noir
13:57:45 <andythenorth> “when I made Thomas, it made it more like…realistic”
13:58:06 <TrueBrain> Zuu: I pressed a button; now fingers crossed it does anything :D
13:58:25 <TrueBrain> I think I configured it now that it will be pushing the files to the mirrors too .... hihi :D
13:59:31 <TrueBrain> hmm, documentation failed .. lolz
13:59:56 <Zuu> May be an error in doxygen comments from my side perhaps.
14:00:19 <TrueBrain> cannot open tag file objs/openttd.tag
14:00:23 <TrueBrain> sounds like something is just broken :P
14:01:57 <TrueBrain> ah, yes, that is indeed broken ni the CF
14:03:03 <TrueBrain> now we will have to wait for the other targets to finish, then I can retrigger it :P
14:06:01 <TrueBrain> yippie, that works; okay, this will take ~25 minutes or so
14:25:43 <DorpsGek> Commit by frosch :: r27342 /trunk/src (newgrf_railtype.cpp newgrf_railtype.h) (2015-07-26 14:25:37 +0200 )
14:25:44 <DorpsGek> -Add: Optionally return the number of sprites in the spriteset from GetCustomRailSprite.
14:25:54 <Eddi|zuHause> <__ln__> i found a bug. <-- is it about earrings not being symmetrical?
14:27:17 <__ln__> it's not as serious, only a null pointer dereference resulting in a crash.
14:28:40 <DorpsGek> Commit by frosch :: r27343 /trunk/src (rail.h rail_cmd.cpp) (2015-07-26 14:28:34 +0200 )
14:28:41 <DorpsGek> -Feature [FS#6315]: [NewGRF] Allow railtype NewGRF to define separate sprites for the fences on either track side.
14:29:11 <frosch123> V453000: ^^ may also be interesting for you, it should allow removing the gaps between fences in corners
14: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?
14:32:22 <TrueBrain> one of the perks of being a dev, I guess :P
14:33:11 <Zuu> By trigger, is that to log in to ssh and make a command there?
14:34:12 <Zuu> I guess i could do that manually.
14:34:19 <TrueBrain> I really dont mind either way
14:34:25 <TrueBrain> what ever is easiest for you
14:34:39 <Zuu> Automatic is probably easier, assuming it is like once every hour or so.
14:34:55 <TrueBrain> sadly, can only be once a day
14:35:02 <TrueBrain> because we have windows of which no other compiles can happen
14:35:13 <TrueBrain> it is easier to avoid the CF to pick up changes during those hours
14:35:20 <TrueBrain> than to make a priority thing for it :P
14:35:29 <TrueBrain> so the automatic polling would be once a day
14:35:31 *** oskari89 has joined #openttd
14:35:46 <Zuu> And it is still possible to manually triger it still?
14:36:20 <TrueBrain> prefered time you want the poll to happen?
14:44:55 <TrueBrain> well, gl/hf with it :D hihi :)
14:50:08 *** Progman has joined #openttd
15:03:10 *** Alberth has joined #openttd
15:03:10 *** ChanServ sets mode: +o Alberth
15:03:17 <Eddi|zuHause> frosch123: now, track and base sprites for the whole junction, instead of per trackbit?
15:09:22 <frosch123> no, now more interesting stuff
15:10:50 <frosch123> so, how does this tcp/ip packet-transmission work?
15:10:59 <frosch123> is there some limit on the size of a packet
15:11:19 <frosch123> do i need to care about splitting and reconcatenating bigger packets?
15:12:40 <Alberth> tcp/ip? nah, you don't care about packets at all, order is preserved, delivery is guaranteed
15:13:27 <Alberth> obviously, you may get only parts of the data at a time, at the receiving end
15: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
15: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?
15: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.
15:16:22 <Eddi|zuHause> frosch123: probably
15:16:46 <Zuu> The book says a lot more, but takes time to read.. :-)
15:17:42 *** Wormnest has joined #openttd
15:18:59 <Zuu> TCP has a maximum transmision unit, MTU and the book list 3 common values: 1460 bytes, 536 bytes and 512 bytes.
15:20:15 <frosch123> i think i found the place to lift this limit from ottd
15: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.
15:21:48 <peter1138> MTU is at the transport layer, and translates to MSS (MTU - 40bytes). Those figures are MSS.
15:22:44 <Zuu> The book says it is MTU figures, but the book could be wrong.
15:23:39 <peter1138> MTU affects more than TCP. Normal MTU is 1500 bytes.
15:24:30 <peter1138> And indeed, as long as fragmentation isn't prohibited, it doesn't particularly matter for TCP.
15:51:50 <TrueBrain> frosch123: you can change the limit, just UDP will fail :D
15:51:54 <TrueBrain> so you would have to split the two
15:52:05 <TrueBrain> UDP packets over the size of the MTU will never arrive at the destination
15:52:56 <TrueBrain> frosch123: but why do you want to change the value to start with?
15:53:12 <frosch123> because i want to send a big json as command parameter
15:53:28 <frosch123> 64kb looks more reasonable than 1460 bytes
15: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)
15:54:31 <frosch123> bananas uses tcp for the content list, right?
15:54:35 <TrueBrain> and I think we still allocate a pre-set sized buffer for the TCP :)
15:54:56 <frosch123> well, the PacketSize member is uint16 to start with :p
15:55:32 <frosch123> anyway, i am fine with 64kb, it must be hand-written by newgrf authors anyway
15:55:36 <TrueBrain> tcp_content is TCP, so yeah
15:57:00 <TrueBrain> ah, the buffer indeed is allocated SEND_MTU size
15:57:17 <frosch123> yup, already replaced that one :)
15:57:24 <TrueBrain> well, you cannot just replace it
15:57:31 <TrueBrain> you will have to split TCP and UDP somehow
15: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 :)
15:57:53 <frosch123> result will be that the map wil be streamed in chunks of 64kb, instead of 1.4
15:58:08 <frosch123> but i guess that makes no difference on the lower levels
15:58:16 <TrueBrain> would only increase the speed
15:58:41 *** andythenorth has joined #openttd
15:59:02 <TrueBrain> I guess at creating of Packet you know the estimated size .. hmm
16:00:57 <TrueBrain> hmm .. the days that we fiddled with UDP to get it stable ...
16:01:07 <TrueBrain> then NewGRFs got introduced, and servers werent pollable anymore ...
16:01:12 <TrueBrain> silly MTU on UDP :P
16: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 :(
16:03:59 <TrueBrain> owh, I so remember the days that my Linux machine refused to talk to my Windows machine
16:04:06 <TrueBrain> because Windows had an MTU of 1460, and Linux of 1500
16:04:10 <TrueBrain> hours of debugging ....
16:04:28 <TrueBrain> one machine saw the traffic going out, but not back in .. while the other saw all the traffic :D
16:04:50 <TrueBrain> the days of the "hubs" in your UTP network ..
16: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).
16: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.
16:12:24 <frosch123> or should i replace the fixed-size buffer with some growing std::vector or something?
16:12:54 <frosch123> most packets will probably be around 32 bytes or something, so allocating 64kb each time may increase the server queues
16:13:04 <frosch123> though, technically clients can still send 64kb packets
16:13:24 <frosch123> would need kicking if packets are bigger than needed
16:18:48 <TrueBrain> I don't think increasing the size of all buffers to 64k is the way to go
16:18:57 <TrueBrain> for many Packets, we already know the length (as they are predefined)
16:19:02 <TrueBrain> this feels like a huge increase in memory usage
16:19:05 <TrueBrain> (both client and server)
16:20:18 <TrueBrain> frosch123: what communication part do you require the bigger size for? (server<->client, client->server, server->client, ms->server, ms->client, ...?)
16:21:06 <frosch123> server->client for game-script triggered command packages
16:21:28 <TrueBrain> so maybe only increase the size of the packet?
16:21:35 *** Nemoder has joined #openttd
16:21:46 <frosch123> of the command packet? or add a separate big-command packet?
16:22:05 <TrueBrain> this just feels like a lot of unneeded memory being allocated all the time :D
16:22:12 <frosch123> or make the allocation incremental? first 32 bytes, then packet-size bytes
16:22:18 <frosch123> i guess the latter is easiest
16:22:28 <frosch123> after the first 32 bytes, the target size is known
16:22:41 <frosch123> so, at most one realloc per packet
16:22:49 <TrueBrain> how is it known? :)
16:23:02 <frosch123> the packet size os the first item in the packet
16:23:10 <frosch123> if that is wrong, client will be kicked anyway
16:23:19 <frosch123> since the pipe is broken then
16:23:34 <frosch123> well, reading is the tricky part :) for writing everything is known anyway
16:23:55 <TrueBrain> reading already works for > MTU ?
16:24:04 <frosch123> no, the buffer is the same in Packet
16:24:15 <frosch123> clients are kicked if they send bigger ones
16:24:26 <TrueBrain> ah; well, reading is the easiest to fix, yes
16:24:27 <frosch123> before we overrun the buffer :p
16:24:32 <TrueBrain> read 2 bytes in a static buffer, allocate rest of buffer
16:24:43 <TrueBrain> but sending is more tricky to resolve, in a clean way :)
16:25:01 <Alberth> just always allocate 64k ?
16:25:31 <TrueBrain> then we have to make separate code for ottd_content, as that would make it boom in memory :)
16:25:35 <Alberth> you don't keep packets around do you?
16:26:25 <frosch123> they are queued in some cases
16:26:31 <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? :)
16:26:36 <Alberth> fair enough, if you do, it would be a bad idea
16:26:51 <TrueBrain> Alberth: ottd_content (the server-side we run at openttd.org) uses the same code; and it keeps them around a bit longer :D
16:26:57 <frosch123> but, currently we do not check whether the client sent more than needed
16:27:02 <frosch123> so, that needs a kick as well :)
16:27:25 <TrueBrain> but yeah, why not add in every Packet(), a hint to what the max size should be (for sending)
16:27:33 <TrueBrain> and change the reading to first read the 2 bytes, then allocate the buffer?
16:27:45 <TrueBrain> sounds like a much more solid solution tbh, then just increasing the buffer :D
16:27:56 <frosch123> i would change the reading to 32 bytes first, since that should fit 99% of the packages :)
16:28: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().
16:28:40 <TrueBrain> michi_cc: yes, but that we handle already :)
16:28:57 <TrueBrain> (as you really really have to as application layer :))
16:29:02 <Nemoder> what is the best way to add a 'message of the day' for players connecting to my dedicated server?
16: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.
16:30:53 <TrueBrain> that would fail in the first real-world test tbh :P
16:31:07 <TrueBrain> but yeah .. we also use SOCK_DGRAM, where this MTU issue comes from :)
16:31:29 <michi_cc> If you only test with loop-back or LAN, it usually even holds. Over the internet OTOH...
16: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
16:33:22 <TrueBrain> owh, you can ofc, but, yes
16:33:28 <TrueBrain> let me put this in words, not in thoughts :D
16:33:36 <frosch123> there is no MTU limit in the read
16:33:56 <frosch123> it reads data up to packet_size bytes
16:33:58 <TrueBrain> our code can be such a maze of files :D
16:34:27 <frosch123> res = recv(this->sock, (char*)p->buffer + p->pos, p->size - p->pos, 0);
16:34:50 <frosch123> it does that until p->size has been received or there is no more data
16:35:22 <TrueBrain> ah, yes, udp doesn't follow the same pace as tdp there, lolz
16:35:53 <TrueBrain> so basically you could delay the Packet creating till after the first PacketSize has been read
16:36:43 <frosch123> there are already two loops for that
16:37:07 <TrueBrain> but yeah, for reading this indeed is easy enough
16:37:18 *** HerzogDeXtEr1 has joined #openttd
16:37:28 <frosch123> i would also add something to ReceivePackets
16:37:40 <frosch123> which checks whether the whole package has been consumed after HandlePackage
16:37:56 <frosch123> currently we do not care whether someone bloats the package to max size every time
16:38:18 <TrueBrain> well, your patch will be enjoỳable to test :D:D
16:38:51 <frosch123> oh, usually it does not take longer than 2 months to report a crash on start up
16: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
16:39:10 <frosch123> people will just use 1.4.0 to generate maps, if trunk mapgen is broken
16: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
17:23:13 <Nemoder> anyone know the best way for me to add a 'message of the day' for players connecting to my dedicated server?
17:24:55 <frosch123> check bin/scripts/on_server_conenct_scr.example
17:25:07 <frosch123> or use soap if you need something more advanced
17:27:03 <Nemoder> I tried with on_server_connect but it sends the message to everyone on each connection
17:27:30 <Nemoder> is there a way to send a message only to the most recent connection?
17:27:53 <frosch123> no idea, likely not with these type of basic scripts
17:27:57 <frosch123> do you know a server which does so?
17:28:58 <Nemoder> I thought I'd seen some, but I think they were likely custom builds
17:29:25 <frosch123> there are plenty of interfaces to attach external control software
17:30:15 <Zuu> Oh. sorry was not scrolled way down yet :-)
17:31:18 <frosch123> though it does way more than you asked for now
17:31:54 <frosch123> like a irc chat bridge
17:32:08 <frosch123> and admin commands via irc for moderators and such
17:32:56 <Nemoder> heh ok, looks complicated for just a motd. I just wanted to make sure I hadn't missed anything simple, thanks
17:33:48 <frosch123> but yes, soap sends the welcome message as private message
17:33:54 <frosch123> to the single client
17:34:51 *** andythenorth has joined #openttd
17:35:34 <andythenorth> slow network saves me :P
17:35:44 <andythenorth> hmm, it’s loaded now
17:35:57 <andythenorth> I guess that we can all go home now, everything that can be done has been done
17:36:20 <frosch123> we cannot send 64kb json commands yet
17:37:52 <Zuu> we cannot make tech trees yet
17:40:19 <andythenorth> nah, that movie is the end of all creative efforts
17:40:34 <andythenorth> although, it didn’t have rainbows
17:41:09 <Zuu> frosch123: Is there something in particular you had in mind for larger command payloads?
17:41:46 <frosch123> yes, i want to change the inferface from "send some uint32" to "send an query json structures"
17: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
17:42:47 <frosch123> i want to send more than one uint32
17:42:53 <Zuu> Ah that idea with key => value pairs
17:43:28 <frosch123> a whole json structure, which allows to define arbitrary interfaces between gs and newgrf, and check for their existence/compatiblity
17:45:39 <Zuu> Nice. Hopefully it get used more than SCP.
17:47:48 <Alberth> it's not secure copy :)
17:48:10 <frosch123> TrueBrain: it's an ai cheating system :p or so
17:50:10 <Zuu> Script Communication Protocl
17:50:23 <Zuu> It allows GS and AIs to talk with each other using signs.
17: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.
17:51:42 * andythenorth considers using signs for electricit
17:51:47 <andythenorth> electricity even
17:51:53 <andythenorth> ‘producing power'
17:51:56 <andythenorth> ‘consuming power'
17: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.
17:52:37 <Zuu> SCP has the side effect of signs being placed on tile 0.0 to the disslike of some players.
17:53:10 <Zuu> krinn wrote most of it by the way. I wrote some docs for it.
17:56:52 <Zuu> TrueBrain: SCP explained above
17:59:32 <peter1138> Anyone used it as a VPN yet?
17: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 ;-)
18:00:42 <TrueBrain> why are signs used for it?
18:00:57 <Zuu> Because what would you otherwise use?
18:01:05 <TrueBrain> add support for it in OpenTTD :D
18:01:12 <TrueBrain> bit of threading issues with signs if you have more than 1 active AI :D
18: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
18:02:54 *** zeknurn` has joined #openttd
18: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.
18:03:38 *** zeknurn` is now known as zeknurn
18:08:02 <peter1138> But if AI can communicate directly, that's cheating ;p
18: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. :-)
18:17:31 <TrueBrain> frosch123: don't forget network communication can be delayed with several ticks
18:17:43 <TrueBrain> so after sending a: change state, it can take up to N ticks before reading it back shows the change
18:17:58 <TrueBrain> (just in case you didn't know about that part of the network protocol yet :D)
18:18:20 <frosch123> i am well aware of that :)
18:18:37 <frosch123> gs cannot answer synchronously
18: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
18:19:08 <TrueBrain> which is not true :)
18:19:26 <frosch123> so gs are even slower?
18:19:33 <frosch123> i mean gs run on the server
18:19:41 <frosch123> i hope at least they would manage to run one command per tick
18:19:59 <TrueBrain> well, the GS wants to talk to grfs at clients, right?
18:20:04 <TrueBrain> so this has to be done via a DoCommand
18:20:09 <TrueBrain> send over the network blabla
18:20:16 <TrueBrain> the delay between sending the command, and execution
18:20:21 <TrueBrain> is N, where N is defined by the server owner
18:20:23 <frosch123> yes, but the answer is only returned on the server
18:20:32 <frosch123> the newgrf also run on the server
18:20:40 <frosch123> the server does not have to wait for a response from the clients
18:20:49 <TrueBrain> no, but the command itself is not directly executed
18:20:52 <frosch123> it does not wait for the clients when building track either
18:20:57 <TrueBrain> you can return the return value of the test-run
18:21:16 <TrueBrain> my point is this: place track with GS, query tile if track is there
18:21:24 <TrueBrain> if delay is 5, it will take 5 ticks before you see the track
18:21:39 <TrueBrain> (also on the server ;))
18: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
18:22:07 <TrueBrain> if a command is also send to clients, the "next tick" part is variable
18:22:24 <frosch123> why does the server care about the clients?
18:22:30 <TrueBrain> because we work in synced states
18:22:34 <TrueBrain> client state == server state
18:22:40 <TrueBrain> so DoCommands are delayed for N ticks
18:22:44 <TrueBrain> normally 1, but can be more
18:22:45 <frosch123> i think the server runs ahead of the clients
18:22:51 <TrueBrain> I hope not :D Would desync instantly
18:22:56 <frosch123> so for client->server->client there is a delay, but not for server->server
18:23:11 <TrueBrain> lets try this differently: say you aren an AI, and you build a station
18:23:17 <frosch123> i.e. client issues command, and the server assigns a timestamp for execution to it
18:23:18 <TrueBrain> say I put the DoCommand delay on 10 ticks
18:23:26 <TrueBrain> I build something as AI, 10 ticks later, the station is there
18:23:32 <TrueBrain> in between, both clients and server don't see the station
18:23:48 <frosch123> where is this DoCommand delay?
18:24:03 <TrueBrain> it is how the network works :) Otherwise you cannot promise synced states
18:24:09 <TrueBrain> clients and server have to do the same thing at the same time
18:24:33 <TrueBrain> so when a DoCommand happens for both server and clients, it is put to be executed on a certain frame
18:24:35 <frosch123> i think you are using a different meaning of "time"
18:24:37 <TrueBrain> which is at least 1 frame away
18:25:01 <frosch123> the server sets what the "frame time" is
18:25:15 <frosch123> when the server reaches a frame, it executed the stuff for the frame and sends it to clients
18:25:26 <TrueBrain> clients already know about it
18:25:27 <frosch123> the clients reach that frame only whatever latency they run later
18:25:50 <TrueBrain> there is no need to wait for the server to execute it
18:25:53 <frosch123> TrueBrain: well, can you speak in source code? :p
18:26:04 <TrueBrain> in the mess we call hierarcy ? :P
18:26:24 <frosch123> because in my mind, what you say makes no sense :p
18:26:47 <TrueBrain> and that is why I warn you ;) As your current documentation suggests something different than what happens :D
18:26:51 <TrueBrain> which for 99% of the servers will be fine
18:27:24 <TrueBrain> it is basically network_command.cpp
18:27:55 <TrueBrain> a DoCommandP is queued for both the server as clients to be executed on a later date
18:28:04 <TrueBrain> the command is broadcasted, and everyone puts it on its queue
18:28:10 <TrueBrain> when the frame happens, it is executed
18:28:16 <TrueBrain> (of course the server did pre-checks on it, but meh)
18:28:56 <TrueBrain> NetworkSendCommand() to be exact
18:29:00 <TrueBrain> a client sends it packet to the server
18:29:07 <TrueBrain> a server delays his packet by N
18:29:30 <TrueBrain> the delay is only there so clients can receive the packet in time
18:29:39 <TrueBrain> on high latency connections, this isn't always in the same tick
18:29:58 <TrueBrain> (and clients can walk away for M ticks since the last sync, by default .. 100 I believe)
18:30:39 <frosch123> c.frame = _frame_counter_max + 1; <- so, your N seems to be 1
18:30:48 <TrueBrain> euhmz? That is 1? Oh-oh :D
18:30:58 <TrueBrain> *creates edge case to create desyncs*
18:31:02 <frosch123> so, either 1 command per tick, or 1 command per 2 ticks
18:31:13 <frosch123> and your desync reasoning makes no sense
18:31:32 <frosch123> clients do not run in sync with the server as in atomic clocks run in sync
18:31:37 <frosch123> there is no reason for that
18:32:07 <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
18:32:39 <frosch123> _frame_counter_max = _frame_counter + _settings_client.network.frame_freq; <- ah, it is bigger than 1:)
18:32:50 <frosch123> but still, the value only affects the latency, not desyncs
18:32:53 <TrueBrain> frame_freq defaults to 1, I hope
18:33:23 <TrueBrain> 0? 0 makes little sense
18:33:27 <frosch123> so, still 1 or 2 ticks per command
18:33:32 <TrueBrain> commands cannot be excuted on the same tick
18:34:02 <frosch123> i talk about the time between server receiving a cmomand, and executing it
18:34:18 <frosch123> the time it takes for the command to travel from client to server does not matter
18:34:49 <TrueBrain> yes, and put in a local queue to be executed 1 tick later
18:34:56 <frosch123> any delay you imagine may increase the lag for clients to get their commands executed
18:34:57 <TrueBrain> (or rather, 1 frame)
18:35:07 <frosch123> but no matter what small value you assign to it, it will never desync
18:35:30 <TrueBrain> there is a lovely edge case, but we can talk about hypotheticals, or I can just find the line of code :)
18: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
18:37:51 <TrueBrain> well, to be clear, was just an awareness issue
18:37:56 <TrueBrain> so you understand it is at play
18:38:31 <frosch123> we just need a method for gs to send multiple commands at once :p
18:38:38 <frosch123> so they do not get suspended immediately :p
18:38:51 <TrueBrain> if they don't care about the answer, that is possible
18:39:38 <frosch123> TrueBrain: not sure whether you want to allow gs to spam everyone with thousands of commands per tick :p
18:39:54 <TrueBrain> there is a max amount of commands a frame can contain
18:40:04 <frosch123> so, the current limit ensured gs authors to think somewhat
18:40:42 <frosch123> TrueBrain: i think that limit only applies to clients, not for the server
18:42:14 <Zuu> A query for instant information would not use a DoCommand at all. Instead it would only use up one oopcode.
18:42:18 <TrueBrain> ah, okay, the +1 mentioned above is unrelated to the frame_freq
18:42:23 <TrueBrain> pfew, was about the so, that would be baadddd
18:42:39 <TrueBrain> (damn, globals are hard to track in our code)
18: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
18:43:52 <TrueBrain> but the +1 is completely unrelated
18:45:06 <TrueBrain> lol, that comment there is also very vague and seemly wrong in assumption :D hihi :)
18:45:20 <TrueBrain> owh, the days I thought NewGRFs didnt touch the randomizer ..
18:46:07 <Zuu> Btw, do we today have the concept of read only callbacks in NewGRF?
18: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)
18:46:21 <frosch123> all the gui callbacks :)
18:46:27 <frosch123> all the command test-runs
18:47:05 <frosch123> TrueBrain: yes, and _frame_counter_max what frame the server allowed the clients to proceed to
18:47:23 <frosch123> which may be hours after the server executed it, if the clients are happy to lag behind that long
18:47:26 <TrueBrain> so the states are always identical, and the commands they execute per tick is always the same, in the same order
18:47:42 <TrueBrain> yeah, lets not compare anything to real-time
18:47:43 <frosch123> it will only make the player on that client suffer to wait for their mouse clicks to return something :p
18:47:47 <TrueBrain> we purely talk about frame delays :)
18:48:06 <TrueBrain> so yeah, GS too are delayed, despite them being on the server
18:48:16 <TrueBrain> and indeed, frame_freq can be 0, because of the + 1 on it every time :D
18: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)
18:49:35 <TrueBrain> in fact, a client can just load an AI which does his actions for him :P (and it still works)
18: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
19:05:02 <TrueBrain> funny, this type of network protocol often is refered to as lockstep
19:05:12 <TrueBrain> but when you look that up, you find all kind of funny shit totally unrelated :D
19:08:50 <TrueBrain> frosch123: server commands also obey the commands_per_frame btw :D So we should be safe :P
19:10:03 <TrueBrain> although it is more a: command_per_frame_per_queue
19:10:18 <TrueBrain> but that makes sense I guess .. (if you have more clients, you expect more commands)
19:39:00 <andythenorth> frosch123: I just read the GS/NewGRF stuff, makes sense
19:40:43 <frosch123> but we didn't play the prototype yet, did we :p
19:41:19 <andythenorth> there’s enough possibilities + constraints to keep people busy figuring out how to use it
19:41:30 <TrueBrain> and never end up using it? :D
20:00:12 *** NGC3982 has joined #openttd
20: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.
20: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.
20:06:39 <Zuu> Though, often I found it picked towns as goals that had no primary industries :-/
20:13:07 <andythenorth> Zuu: the code I need to write, that I haven’t, is to reduce BB repeating goals :)
20:13:20 <andythenorth> but I don’t even understand what data structure I’d store that in yet :)
20:13:52 <Zuu> In general you store data in tables, but you can also use arrays.
20:14:27 <andythenorth> tables looked a bit like dicts when I read the squirrel docs
20:14:31 <Zuu> tabels is key => value pairs. arrays are lists of data with integer keys without holes.
20:14:42 <Zuu> yep they are like dicts in python
20:14:45 <andythenorth> is table order reliable?
20:16:02 <Zuu> There is also GSList, but it can only store integer values.
20:16:17 <Zuu> GSList is useful because of valuators and sort.
20:16:34 <Zuu> local list = GSTownList();
20:16:34 <andythenorth> in python, for something like this I’d just stick the goal objects in a list
20:16:47 <Zuu> list.Valuate(GSTown.GetPopulation)
20:16:52 <andythenorth> if I was really worried about performance, I’d stick just the destination-cargo pairs in a list
20:17:25 <Zuu> That would give you a list of all towns with more than 500 inhabitants.
20:18:11 <Zuu> One word of warning, GSList() and its friends give you an instance. Those cannot be saved in save games.
20:18:28 <Zuu> Only elementary data types, arrays and tables can be saved.
20: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.
20: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
20:20:43 <Zuu> Well in Producing Bee, I use the procedural approach. :-)
20:21:10 <Zuu> I keep confusing myself about the name. :-p
20:21:56 <frosch123> see bee rewards/awards :p
20:25:26 *** andythenorth has joined #openttd
20:26:08 <Zuu> Oh andythenorth I missed you dropped out. I wrote some more. :-)
20:36:29 <Alberth> you can just walk over the entries in a table
20:36:46 <Alberth> or probably better, use the goals as key
20:37:27 *** gelignite has joined #openttd
20:37:27 <Alberth> (ie the industry/town key to the list of cargoes or so
20:38:12 * andythenorth should look at this again in 2 weeks :)
20:38:33 * andythenorth needs to learn some GS basics sometime
20:38:35 <Alberth> it happens around this time of the year :)
20:40:14 <Zuu> local t = {}; t.rawset(key, value);
20:40:44 <Zuu> there is also .rawget(key) and .rawin(key). The last one check if the key exist.
20:41:11 <Zuu> If the key name is hardcoded/known, you can write it out in source code: t.town
20:42:05 <Zuu> You can also do similar magic on classes :-)
20:42:20 <Alberth> yeah, spooky small languages :p
20:43:09 <Alberth> not sure what python3 does there
21:11:40 *** andythenorth has joined #openttd
21:21:12 *** jottyfan has joined #openttd
21:36:08 *** supermop has joined #openttd
21:48:23 *** Wolf01 is now known as Guest1493
21:48:23 *** Wolf03 is now known as Wolf01
21: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
22:02:34 *** Quatroking has joined #openttd
22:02:42 <Quatroking> can you use FIRS on an existing game
22:04:22 <Taede> no, one cannot add/remove newgrfs in a running game
22:05:04 <Quatroking> so if I want to use FIRS I have to start a new map?
continue to next day ⏵