IRC logs for #openttd on OFTC at 2020-12-09
⏴ go to previous day
00:02:30 *** arikover` has quit IRC (Quit: ERC (IRC client for Emacs 26.3))
00:04:57 <milek7> I'm tempted to implement your idea and make emscripten url config accept a function
00:06:13 <milek7> then stick destination address into query url so server could proxy it
00:09:50 <TrueBrain> I would also use it to deny most addresses for example
00:09:56 <TrueBrain> And only allow a few
01:03:51 <milek7> >btw, regarding CSleep, shouldn't the whole CSleep do nothing, I was wondering?
01:32:59 *** TrueBrain has quit IRC (Ping timeout: 480 seconds)
01:38:15 *** Wormnest_ has joined #openttd
01:43:13 *** TrueBrain has joined #openttd
01:44:04 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:10:15 *** cHawk has quit IRC (Ping timeout: 480 seconds)
02:36:54 *** Wormnest_ has quit IRC (Quit: Leaving)
03:29:03 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
03:29:46 *** Eddi|zuHause has joined #openttd
03:45:34 *** Lejving has quit IRC (Read error: Connection reset by peer)
03:45:55 *** Lejving has joined #openttd
03:46:17 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
03:46:56 *** Eddi|zuHause has joined #openttd
03:51:38 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:27:39 *** reldred has quit IRC (Read error: Connection reset by peer)
05:28:07 *** reldred has joined #openttd
05:54:28 *** Speeder_ has joined #openttd
06:01:39 *** Speeder has quit IRC (Ping timeout: 480 seconds)
06:37:48 *** keoz has quit IRC (Ping timeout: 480 seconds)
06:39:38 *** dwfreed is now known as Guest7918
06:39:39 *** dwfreed has joined #openttd
06:43:40 *** andythenorth has joined #openttd
06:46:28 *** Guest7918 has quit IRC (Ping timeout: 604 seconds)
07:07:37 *** sla_ro|master has joined #openttd
07:29:30 <andythenorth> yair the 2nd part of a dual-headed vehicle appears to re-randomises on all triggers
07:29:57 <andythenorth> or there is an equivalent behaviour which creates a result that looks like that
07:30:31 *** tokai|noir has joined #openttd
07:30:31 *** ChanServ sets mode: +v tokai|noir
07:35:11 *** andythenorth has quit IRC (Quit: andythenorth)
07:37:42 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:47:13 *** andythenorth has joined #openttd
08:24:00 *** HerzogDeXtEr has joined #openttd
08:29:26 <TrueBrain> milek7: I meant, shouldn't we remove all cases of CSleep, instead of the one :D
08:29:32 <TrueBrain> I don't like busy-loops in code :P
08:31:16 <TrueBrain> but the answer on that is also: no, after checking out those cases :)
08:31:30 <TrueBrain> they all should do a busy-loop
08:41:01 *** cHawk has quit IRC (Read error: Connection reset by peer)
09:05:34 *** HerzogDeXtEr has quit IRC (Quit: Leaving.)
09:11:19 *** HerzogDeXtEr has joined #openttd
09:21:40 <DorpsGek> [OpenTTD/OpenTTD] orudge merged pull request #8366: Change: Don't display OS name when the user is exiting the game https://git.io/JI0Ig
09:36:52 *** andythenorth_ has joined #openttd
09:42:11 *** supermop_Home has quit IRC (Remote host closed the connection)
09:43:28 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
09:55:19 <TrueBrain> so .. I tried to disable a button ....
09:55:34 <TrueBrain> Assertion failed: widget_index < this->nested_array_size, at: src/window_gui.h,394,SetWidgetDisabledState
09:56:27 <TrueBrain> SetWidgetDisabledState vs SetWidgetsDisabledState
10:05:56 <TrueBrain> who names 2 functions THAT similar ... guess C++ could fix that now :P
10:10:54 <TrueBrain> milek7: your websocket proxy is not running?
11:22:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
11:22:07 <TrueBrain> still a bit of WIP, but with my bananas-server patch, content service is working
11:22:17 <TrueBrain> I did not apply the hostname fixes you have, as I cannot test it :D
11:22:52 <TrueBrain> for content service, basically, I am going to open content.openttd.org, and if you land on / with a WebSocket request, it will upgrade your connection and after that it is like you have a TCP connection to the content service
11:30:11 <TrueBrain> okay, knowing how -c works, and with my fix, it is really useful for development all of a sudden :D
11:32:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
11:32:31 <DorpsGek> [OpenTTD/bananas-server] TrueBrain opened pull request #39: Add: support client connections over WebSocket / HTTP https://git.io/JIzaz
11:32:40 <TrueBrain> smallest patch to add support for something like WebSocket evah ^^ :D
11:36:35 <andythenorth_> wtf is CentOS up to eh?
11:36:52 <TrueBrain> on mobile the web-version of OpenTTD doesn't work ... "�[1;31mError: No usable screen resolutions found!"
11:38:17 <andythenorth_> but we gained iOS support
11:38:27 <andythenorth_> I'll test it on ipad later
11:40:20 <TrueBrain> what is the mouse going to do .... a good question :D
11:40:25 <TrueBrain> I think it is unplayable without mouse :P
11:40:51 <andythenorth_> I think there is mouse for ipad
11:40:52 <DorpsGek> [OpenTTD/bananas-server] TrueBrain updated pull request #39: Add: support client connections over WebSocket / HTTP https://git.io/JIzaz
11:46:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
11:46:56 <TrueBrain> right, at least now it crashes on mobile
11:46:59 <TrueBrain> instead of saying it is running :D
11:48:29 <TrueBrain> I now only have to fix joining a server, but I am too lazy to write a websocket server myself
11:48:44 <TrueBrain> otherwise ... this is getting ready for review :D
12:13:12 <milek7> yes, I made changes to proxy yesterday
12:14:48 <andythenorth_> TrueBrain so have you compiled JGR with it yet? :D
12:16:22 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:16:35 *** WormnestAndroid has joined #openttd
12:28:47 <milek7> you can add any IP manually, it is proxied
12:31:50 <milek7> I wanted to make 1.10.3 build for joining other servers, but it pre-cmake :(
12:34:17 <TrueBrain> Do realise you made an open proxy now btw .. do you do any protocol filtering?
12:35:13 <milek7> 3978 and 3979 is allowed
12:35:42 <TrueBrain> So not all servers work :p :p
12:39:42 <TrueBrain> right, so let me see what is all this with hostname etc :)
12:42:24 *** JohnnyB has joined #openttd
12:42:33 <TrueBrain> milek7: you plan to upstream that emscripten patch btw? :D
12:43:26 <TrueBrain> lol ... corrupted heap memory ... I doubt the error is what really happened :P
12:43:34 <TrueBrain> emscripten can give weirdly wrong information in its crashes :D
12:56:36 <TrueBrain> lol, wtf is going on with ai_addrlen .. that is just weird :P
12:59:32 *** arikover has joined #openttd
13:02:24 <TrueBrain> so socket have 128 bytes of storage, but only 28 is used for IPv6s :P
13:06:55 <TrueBrain> okay, the addrlen seems to be a bug in their recvfrom implementation
13:07:22 <arikover> Since commit 535e18b54 (Wed Dec 9 09:21:34), I only have 1 language available (English). I made a checkout+compile with the commit before that (2864d019f, Tue Dec 8 10:24:59) and all languages are available. Have I done something wrong?
13:09:02 <TrueBrain> arikover: I think this is because all other languages are currently invalid
13:09:08 <TrueBrain> this will be fixed automatically in 5 hours or so
13:10:20 <TrueBrain> arikover: sorry for the trouble .. master does break from time to time :)
13:12:00 <TrueBrain> "The argument addrlen is a value-result argument, which the caller should initialize before the call to the size of the buffer associated with src_addr, and modified on return to indicate the actual size of the source address."
13:12:05 <TrueBrain> they do the first part, not the last part :D
13:12:19 <arikover> TrueBrain: No trouble at all!
13:13:02 <TrueBrain> this addrlen is an issue throughout the board .. none of the functions fix addrlen to be the proper length
13:16:23 *** JohnnyB has quit IRC (Remote host closed the connection)
13:26:55 <TrueBrain> hmm, in a test-case of mine it does not crash like it does in OpenTTD .. hmmmm
13:28:27 <glx> hmm when is eints supposed to reload english.txt ?
13:31:25 <TrueBrain> just before it commits
13:31:32 <TrueBrain> I can force it, if we really want to
13:32:51 <glx> maybe it could be possible to trigger it via action in openttd on merge if english.txt is modified
13:33:28 <TrueBrain> for that once a 3 years this happens? Seems like a lot of trouble :)
13:33:44 <TrueBrain> let's talk about those solutions if this happens more than once a year :D
13:34:00 <glx> anyway I'll wait to fix translation
13:34:51 <TrueBrain> so the problem happens in more places than the one you fixed :(
13:35:34 <TrueBrain> that one place just happens to be the one that crashes it :P
13:36:37 <TrueBrain> lol .. nobody noticed eints was inactive for the last 8 days, I guess :P
13:36:46 <TrueBrain> because the repo was inactive, GitHub disabled it :D
13:42:19 <DorpsGek> - Update: Translations from eints (by translators)
13:42:20 *** arikover` has joined #openttd
13:44:10 <milek7> >so the problem happens in more places than the one you fixed :(
13:44:24 <milek7> but isn't this the only place where we use address_length?
13:46:05 <TrueBrain> there was one more place, but it is an accept()
13:46:08 <TrueBrain> so currently not likely we run into that
13:46:34 <TrueBrain> glx: time to go nuts, I say ;)
13:47:38 *** arikover has quit IRC (Ping timeout: 480 seconds)
13:52:57 <TrueBrain> milek7: okay, with that fixed, I have 2 blobs of your patchset that I don't get what they do: the reset_hostname and the CompareTo()
13:53:08 <TrueBrain> can you help me out how to see what goes wrong there without that patch?
13:54:34 <milek7> afair it couldn't match received udp packet to serverlist entry, or created duplicated serverlist entry
13:55:02 <TrueBrain> ah! Yeah, I know that issue :D
13:55:13 *** arikover` has quit IRC (Quit: ERC (IRC client for Emacs 26.3))
13:55:22 <TrueBrain> I wonder what goes wrong under-the-hood there
14:01:38 <TrueBrain> the address_length was one of the reasons, lol, but that is fixed now .. so .. hmm
14:05:45 <TrueBrain> ah, that does solve it
14:05:48 <TrueBrain> just the way I add IPs is wrong :D
14:05:55 <TrueBrain> finnneeee .. let me try with Add Server :D
14:07:41 <TrueBrain> okay, that resolves to an internal IP :D Fun :)
14:14:23 <TrueBrain> yeah, DNS resolving is not really working how it should :D Lol ... or something :P
14:17:08 <TrueBrain> that explains why the websocket was using the hostname again :)
14:22:12 <TrueBrain> I love how the first IP is 172.29.1.0 .. that is not confusing at all, to use a .0 :)
14:28:27 *** Flygon has quit IRC (Read error: Connection reset by peer)
14:32:50 *** Tirili has quit IRC (Ping timeout: 480 seconds)
14:47:25 <milek7> I think that should fix it?
14:57:03 <milek7> weird macros, variable names must be quoted
15:02:11 *** gelignite has joined #openttd
15:03:02 <TrueBrain> milek7: and I wonder if the writeaddr function doesn't return the length or something
15:05:19 <milek7> / kind of lame, but let's match _read_sockaddr's interface
15:06:16 <TrueBrain> LordAro: ghehe, yeah ... magic is magic :D
15:06:43 <TrueBrain> right, what was I doing .. owh, yes, why these NetworkAddresses were not matching up
15:21:37 <TrueBrain> huh? I didn't change anything, and now it is working :P
15:21:45 <TrueBrain> wtf? Did you do anything on your backend milek7 ? :)
15:21:53 <TrueBrain> (the websocket server, that is)
15:22:13 <TrueBrain> well .... that is disturbing
15:22:29 <TrueBrain> my debugging couldn't tell me why it shouldn't be working, but memcmp kept insisting the buffers were different
15:22:35 <TrueBrain> so I printed them char by char, they are identical
15:22:37 <TrueBrain> and now .. it works
15:23:33 <TrueBrain> lets rebuild it all
15:25:44 <TrueBrain> something weird is going on :P
15:33:33 <TrueBrain> okay, it seems to be a timing issue
15:33:41 <TrueBrain> sometimes when I open the UI, it is fine
15:33:43 <TrueBrain> sometimes it is not
15:34:25 <TrueBrain> the last 4 bytes of sockaddr_in change
15:34:55 <TrueBrain> bytes that should always be zero :o
15:35:22 <TrueBrain> this is not good :D
15:38:13 <TrueBrain> okay ... so I get random garbage for the last few bytes ...
15:38:34 <TrueBrain> cool milek7 , you fixed that quickly :)
15:39:09 <TrueBrain> you stole my test and didn't credit me? I AM GOING TO SUE YOU NOW :P (I am not, I really am not :D)
15:39:50 *** jottyfan has joined #openttd
15:40:13 <TrueBrain> it seems emscripten doesn't zero ....
15:40:20 <milek7> should I append you to AUTHORS?
15:41:41 <TrueBrain> am I reading this right, that write_sockaddr doesn't zero the variable?
15:43:23 <TrueBrain> and there is the bug
15:43:31 <TrueBrain> really, they did not do an awesome job testing the network stack :P
15:43:48 <TrueBrain> they malloc, not calloc, and so they do not zero the remaining bytes
15:44:16 <TrueBrain> well, that only took 2 hours to figure out ..
15:45:04 <TrueBrain> how to fix that .. eeuuuhhhh
15:46:52 <TrueBrain> funny, in that function they do set addrlen :D
15:47:55 <milek7> though that is in addrinfo struct, not loose *addrlen
15:48:39 <TrueBrain> so ... can I wipe those zero fields .. hmmm
15:49:32 <TrueBrain> funny, IPv6 doesn't have it
15:53:37 <TrueBrain> right, that fixes the problem
15:53:46 <TrueBrain> milek7: shall I write a bug ticket, or are you already making a pull request? :P
15:53:57 <milek7> POSIX doesn't seem to require sin_zero field :P
15:54:25 <TrueBrain> given every OS does zero it, I am sure we are missing a line somewhere :)
15:56:27 <TrueBrain> it is an old old problem :P
15:58:04 <TrueBrain> so yeah ... POSIX doesn't define what should happen with those bytes, but it is common to zero them :D
15:59:07 <TrueBrain> but, milek7 , do I write a bug report, or will you just pull request it? :D
16:00:16 <milek7> I'm not very convinced that relying on sin_zero zeroed by OS is correct :D
16:00:34 <TrueBrain> it is what every OS does, so ... yeah .. there is that :)
16:00:43 <TrueBrain> and I know that, as OpenTTD makes horrible mistakes if it doesn't :P
16:00:47 <TrueBrain> and we run on many OSes :D
16:16:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
16:16:53 <TrueBrain> well, that was surprisingly more complex to track down the cause of those network issues :)
16:17:54 <TrueBrain> hopefully they accept your PRs soon milek7 :D Means we can remove those workarounds :)
16:18:12 <TrueBrain> milek7: I should now have everything your PR had, with the exception of your personal configuration
16:18:19 <TrueBrain> let me know if I missed any, as that was not by choice :D
16:19:24 <milek7> well, there was libtimidity and sdl1, but you probably don't want these for now
16:19:36 <TrueBrain> ah, yes, I almost forgot
16:19:40 <TrueBrain> sdl1 ... is there any point?
16:19:44 <TrueBrain> we could, for the fact of doing
16:20:30 <TrueBrain> libtimidity, I have nothing against you PRing that after my PR; but I would prefer to use an existing driver if possible :)
16:20:54 <milek7> afair somebody also wanted libtimidity back for different reasons
16:21:26 <TrueBrain> yeah, it was still there because people wanted it .. but as we were not testing it, it was a pita to maintain
16:21:48 <TrueBrain> but if emscripten is using it, I don't mind having it, personally
16:29:26 <TrueBrain> now lets hope LordAro / frosch123 like this enough to go through the motions of reviewing :P :D
16:30:40 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
16:30:57 <TrueBrain> oops ... were 2 commits in there that weren't needed :)
16:30:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
16:31:22 <TrueBrain> pretty happy with the result, especially the GitHub Actions :D
16:32:06 <TrueBrain> and cannot believe we found bugs in emscripten .. I really expected more people to use the network stack .. clearly they do not :P
16:33:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIn4l
16:33:56 <TrueBrain> and tnx for all the help etc milek7 , especially with upstreaming emscripten fixes :D
16:35:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIga1
16:36:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8355: Add: support for emscripten (play-OpenTTD-in-the-browser) https://git.io/JIga9
16:37:54 <TrueBrain> right, that should be it :) w00p
16:38:08 <TrueBrain> where is andy's monologue today?
16:45:25 *** Wormnest has joined #openttd
16:53:47 <andythenorth_> busy doing work
16:55:10 *** Tirili has quit IRC (Ping timeout: 480 seconds)
17:08:23 <rpifan> Im playing on mac os and the fonts are tiny
17:09:12 <rpifan> I tried to change the font size in config.txt
17:10:03 *** supermop_Home has joined #openttd
17:12:43 <supermop_Home> andythenorth_ did 43s ever operate in mixed livery front to back? I seem to recall swallow at KX end and Virgin at north at least once
17:12:54 <supermop_Home> and maybe once on GNER
17:13:09 <supermop_Home> *no virgin at kx, you know what I mean
17:13:36 <supermop_Home> regarding dual headed vehicle part re-randomizing
17:25:20 <LordAro> rpifan: font size config option only has any affect on custom fonts
17:25:33 <LordAro> you probably want the UI size options in the game options window
17:27:01 <rpifan> But the problem is its so huge it destroys the screen
17:27:12 <rpifan> The proportion is too huge
17:28:05 <LordAro> difficult to do anything between 1x & 2x for a pixel based game, really
17:28:10 <LordAro> you'll need to set a font in the config
17:28:15 <LordAro> to get anything inbetween
17:28:32 <andythenorth_> I just used double size in the UI
17:28:37 <andythenorth_> with the original base set
17:31:19 <rpifan> But the test is super blurry
17:31:48 <LordAro> i think you're going to need to provide screenshots of what you're looking at
17:34:38 <rpifan> Ill have to take a pic
17:38:58 *** andythenorth has joined #openttd
17:40:41 <rpifan> Yea but the font is super blurry
17:41:03 *** andythenorth_ has quit IRC (Ping timeout: 480 seconds)
17:42:28 *** andythenorth_ has joined #openttd
17:42:47 <andythenorth_> the font is totally sharp :)
17:43:52 <rpifan> Is there no way to fix it ?
17:44:12 <LordAro> rpifan: we do not understand what you mean by "blurry"
17:44:42 <LordAro> it isn't until i see something that suggests that it is
17:44:43 <andythenorth_> did I miss a screenshot?
17:44:50 <andythenorth_> my wifi dropped
17:44:52 <rpifan> It wasn't like that before
17:45:08 <andythenorth_> are you using opengfx?
17:45:17 <andythenorth_> if it's opengfx, it's just a bad font
17:45:56 <LordAro> rpifan: i repeat, show us what you are seeing
17:46:45 <LordAro> opengfx font hasn't changed in about 10 years
17:47:15 <andythenorth_> yeah opengfx font is just blurry
17:48:50 <andythenorth_> get the original base set files from the web
17:48:55 <andythenorth_> I can't comment on copyright
17:49:13 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
17:49:37 <LordAro> or set a specific font in your config file
17:50:32 <LordAro> andythenorth_: i'd rather you didn't link to copyright infringing content
17:50:34 <DorpsGek> - Update: Translations from eints (by translators)
17:50:59 <andythenorth_> I linked to a page about how great OpenTTD is
17:51:30 <andythenorth_> will I die before the original baseset copyright ends?
17:51:46 <andythenorth_> will I redraw opengfx to be good?
17:52:32 <rpifan> Can i send you money to fix the font
17:53:06 <andythenorth_> oh do we host the wiki?
17:56:25 <milek7> it doesn't seem blurry to me
17:56:34 <andythenorth_> also try it on the minimap etc
17:57:21 <LordAro> honestly struggling to tell the difference
17:57:34 <LordAro> rpifan: ...it's really unclear what your problem is
17:58:07 <LordAro> either show us what you're looking at, or find something else to talk about
18:02:51 *** Progman has joined #openttd
18:03:44 * andythenorth_ considers redrawing opengfx
18:04:11 <TrueBrain> please never consider that again, tnx :)
18:04:30 <andythenorth_> every time I use opengfx I consider it, brieful
18:04:43 <TrueBrain> everyone would love it if you would finish it
18:04:47 <TrueBrain> that finishing part is just unlikely
18:04:59 <TrueBrain> not because you suck or anything .. if anyone, you can
18:05:03 <TrueBrain> it is just ... an impossible job :P
18:06:31 <TrueBrain> that's what she said
18:06:41 <andythenorth_> but I have drawn 75 industries already, how many are in original (excluding toyland)?
18:07:37 <andythenorth_> about 22 or something
18:07:42 <andythenorth_> and I have drawn 3 or 4 of them already
18:07:54 <_dp_> what's wrong with opengfx?
18:08:08 <TrueBrain> not maintained, I would say :)
18:08:15 <TrueBrain> never really finished
18:08:21 <TrueBrain> it isn't even 1.0 :)
18:08:22 <andythenorth_> it's a matter of taste about style
18:08:35 <andythenorth_> but opengfx was done in a hurry by Zeph & co
18:08:39 <TrueBrain> shit, I get kicked now for saying maintained, am I not? :(
18:08:40 <andythenorth_> it was the only way to get it done TBH
18:08:50 <TrueBrain> I am happy OpenGFX exists :)
18:08:51 <andythenorth_> the kick is for saying 'maintainer'
18:08:52 <TrueBrain> I couldn't have done it
18:08:57 <TrueBrain> and OpenTTD would be far less popular without it
18:09:00 <andythenorth_> nothing is maintained :P
18:09:42 <rpifan> But how do i make the font look nicer
18:09:46 <rpifan> Is there a way to do thay
18:09:54 <rpifan> It just hurts my eyes being so jagged
18:12:13 <rpifan> Do i set that in the config.text
18:12:31 <andythenorth_> use comic sans :)
18:13:08 <TrueBrain> a very poorly written article, but it contains the info, I guess :)
18:16:49 *** frosch123 has joined #openttd
18:37:20 <Timberwolf> andythenorth_: 2x Fosterstyle base set, pls :p
18:37:40 <andythenorth_> you have the voxel magic :)
18:48:55 *** qwebirc18827 has joined #openttd
18:53:30 <frosch123> you can start with the gui spries
18:53:38 <frosch123> they need improving the most
18:54:05 <andythenorth_> they're kind of odd
18:54:36 <frosch123> just make sure to put the save/load icon to the end of the list
18:55:06 <andythenorth_> why is all the window chrome (x etc) vector?
18:56:46 <frosch123> but that is even harder to get nice :)
18:57:16 <andythenorth_> some of the ogfx icons are, strictly speaking, better than original
18:57:25 <andythenorth_> especially at 2x UI
18:57:40 <frosch123> ogfx have some gui sprites in 2x zoom
18:57:51 *** DasPoseidon has joined #openttd
19:02:30 *** DasPoseidon has quit IRC (Remote host closed the connection)
19:03:39 <frosch123> aw, github discussions is just the same as issues
19:03:49 <frosch123> just under a different tab
19:03:57 <frosch123> so, no irc replacement
19:04:27 *** qwebirc18827 has quit IRC (Remote host closed the connection)
19:11:35 *** rpifan_ has joined #openttd
19:16:13 <andythenorth_> irc will never die
19:17:02 <FLHerne> Nah, I'm not giving up my open standard with umpteen nice clients and tools for a JS blob
19:17:14 <FLHerne> And nor will most other people still using IRC
19:17:25 <FLHerne> (or they probably would have done already...)
19:17:37 <FLHerne> I have vague hopes for Matrix
19:18:58 *** rpifan has quit IRC (Ping timeout: 480 seconds)
19:21:33 <Timberwolf> I like IRC. I feel the quality of online discussion is better when there's a mild, easily surmountable technical barrier to entry.
19:26:01 <andythenorth_> yes but gif support
19:27:56 <Timberwolf> Who needs GIF support when you can wait nearly a minute for someone's carefully prepared ASCII art to make it through flood control?
19:28:37 * andythenorth_ reading a grumpy 'future of irc' thread
19:28:48 <andythenorth_> the lack of features is apparently the main feature
19:28:59 <andythenorth_> and everybody who switched to slack and discord is just wrong
19:29:04 <andythenorth_> and doesn't know how to software properly
19:29:41 <andythenorth_> so when are we adopting some JGR features then?
19:30:14 <Timberwolf> Sounds like a "future of IRC thread" reads much like a "why I still drive an early 90s car" thread.
19:36:23 <andythenorth_> JGR can build multiple railtypes on one tile
19:36:35 <andythenorth_> maybe I try compiling it again
19:42:42 *** qwebirc44879 has joined #openttd
19:44:56 *** qwebirc44879 has quit IRC (Remote host closed the connection)
20:08:18 <andythenorth_> frosch123 is it plausible that rear part of articulated vehicle doesn't handle random triggers in a way I'd understand? :)
20:09:45 <FLHerne> It's probably more likely that NML compiles it wrong :p
20:10:34 <andythenorth_> it's probably MOST likely that my code is wrong
20:10:49 <andythenorth_> but I don't want to go chasing rainbows if OpenTTD is broken
20:11:00 <andythenorth_> or if I just need to check parent instead of self
20:11:43 <andythenorth_> quite possibly nobody has randomised dual head before, although I'm surprised V hasn't
20:12:47 <glx> ideally you'd need to check if NFO is correct
20:13:01 <frosch123> andythenorth_: what trigger?
20:13:50 <andythenorth_> supposed to be TRIGGER_VEHICLE_NEW_LOAD
20:14:02 <andythenorth_> but it appears to trigger for depot visit
20:14:08 <andythenorth_> on second vehicle
20:14:23 <glx> ho randow switch and scope, seems related to a recent frosch123's PR
20:14:29 <andythenorth_> code is in a procedure, single vehicles don't have the bug
20:14:46 <andythenorth_> lead unit doesn't *appear* to have the bug, but eh, random, can't prove it :)
20:15:02 <andythenorth_> doesn't appear to be any other random switch triggering afaict
20:15:03 <frosch123> well, i can tell you. never use triggers with PARENT scope
20:15:12 <frosch123> that is broken since ttdp 2.0
20:15:36 <frosch123> anyway, NEW_LOAD is only triggered on the front vehicle
20:16:30 <andythenorth_> so what's the behaviour of the rear vehicle? :)
20:16:36 <andythenorth_> the bits happily change
20:16:42 <frosch123> ah, no, sorry. i got that wrong
20:17:07 <frosch123> so, your dual headed vehicle has capacity?
20:17:16 <andythenorth_> oh god, is this the flowchart?
20:19:50 <frosch123> i do not see anything speical for dual headed in the loading stuff
20:20:00 <frosch123> the rear part should behave like a wagon
20:20:38 <andythenorth_> bug might be me
20:23:15 <andythenorth_> oof JGR is very slow on mac
20:23:31 <andythenorth_> I don't understand how the checkout handles trunk
20:23:41 <andythenorth_> do I need to also rebase to jgr master?
20:24:06 <andythenorth_> the build is a long way behind trunk
20:24:44 <andythenorth_> nvm figured it out
20:25:11 <frosch123> are you sure "master" is the branch you want?
20:25:28 <andythenorth_> no I am in jgrpp
20:25:35 <andythenorth_> which is correct I think
20:25:47 <andythenorth_> but let's pretend I didn't mix up fetch and pull
20:28:46 <andythenorth_> ok got an up to date build of jgrp
20:28:57 <andythenorth_> runs fast the 1.10.
20:29:04 <andythenorth_> runs faster than 1.10.2
20:29:10 <andythenorth_> lack of sleep is really kicking in
20:35:05 <milek7> TrueBrain: btw why we need FD_SETSIZE at all
20:35:29 <milek7> it could be replaced by this->sock + 1?
20:49:46 *** andythenorth_ has quit IRC (Quit: andythenorth_)
21:09:36 *** andythenorth has joined #openttd
21:09:47 *** Speeder has joined #openttd
21:10:06 *** jottyfan has quit IRC (Quit: jottyfan)
21:10:12 *** Lejving has joined #openttd
21:15:36 *** Speeder_ has quit IRC (Ping timeout: 480 seconds)
21:20:18 <andythenorth> JGRPP, anyone know if there are docs?
21:21:12 <andythenorth> oh it's forum threads, found them
21:21:57 <andythenorth> thanks frosch123 that's an accurate answer :D
21:22:16 <andythenorth> I am quite seriously trying to evaluate the timetable patch
21:22:21 <andythenorth> as it's much requested
21:22:27 <andythenorth> but it's hard to judge
21:22:33 <andythenorth> * I don't know what it's supposed to do
21:22:39 <andythenorth> * nobody can really explain what it's for
21:22:43 <andythenorth> * it's not clear how to use it
21:22:51 <andythenorth> * it's not clear if it does what it's supposed to do
21:22:58 <andythenorth> but it's definitely essential
21:23:21 <frosch123> oh, dear... what are you trying to procrastinate?
21:23:24 <andythenorth> it has 'autofill', 'automate' and 'auto separate' so I've clicked all of them
21:23:26 <frosch123> do you have css work to do?
21:23:29 <andythenorth> no this is serious :)
21:23:34 <andythenorth> this is me being diligent
21:24:11 <andythenorth> ok so unclicking 'Automate' clears the timetable
21:24:29 <andythenorth> selecting 'Auto separate' does nothing without other things being clicked
21:25:01 <andythenorth> I can set a start date for something
21:25:45 <frosch123> there are two timetable patches, which are you looking at?
21:26:08 <frosch123> one is about automating vehicle distance for continuous loading
21:26:34 <frosch123> one is about coordinating multiple trains by using a global clock
21:26:50 <andythenorth> I am just using JGRPP
21:27:07 <andythenorth> by clicking 'automate' and 'auto separate' I have got ships that are spaced out
21:27:14 <andythenorth> and they seem to be equalising the spacing as I run the route
21:27:18 <andythenorth> this seems...good?
21:27:43 <frosch123> well, though i never was interested in either patch. so i am probably wrong about what they do :)
21:28:07 <andythenorth> I have added more ships, and now they're spacing
21:28:13 <andythenorth> what is all that other shit for?
21:28:23 <andythenorth> this could just be one button on orders
21:29:04 <andythenorth> start date, speed limits, late counter, expected/scheduled, scheduled dispatch, autofill
21:29:15 <andythenorth> why do I need to do all those options, when 'automate' just works?
21:29:22 <frosch123> cdist removes "transfer orders" by automating them
21:29:33 <frosch123> auto-separate removes timetables by automating them
21:29:59 <frosch123> both keep the all the gui
21:31:18 <frosch123> pretty sure all those timetable buttons are as useless as transfer orders, when enabling auto-separate or cargodist resp.
21:31:40 <andythenorth> some of them grey out
21:33:54 <andythenorth> this auto separate seems real
21:39:17 *** gelignite has quit IRC (Quit: Stay safe! Stay at home! Stop the chain reaction!)
21:39:29 <andythenorth> jgrpp draws the boundary of dirty blocks as black lines in news window
21:39:31 <frosch123> andythenorth: i had an idea. did you miss the "bitmask" around the random triggers?
21:39:42 <andythenorth> random_switch (FEAT_TRAINS, SELF, switch_spritelayer_cargos_intermodal_cars_random_default_box_DFLT_16px, bitmask(TRIGGER_VEHICLE_NEW_LOAD)) {
21:40:16 <andythenorth> I did look for other triggers in colour randomisation etc
21:40:24 <andythenorth> didn't see any, but this is complicated
21:40:40 <andythenorth> multiple spritelayers and big procedures
21:44:50 <andythenorth> can we debug a vehicle in game? :P
21:46:48 <frosch123> if we serve a newgrf debugger on localhost:6666, do you write the css for it?
21:48:48 <andythenorth> well nobody else would?
21:49:02 <andythenorth> I did the newgrf debug icon, is that proof of willing?
21:49:07 <frosch123> not sure the ottd website layout would fit :p
22:03:08 <andythenorth> times new roman, black on white
22:05:06 <FLHerne> People do need to relearn that
22:05:57 <FLHerne> Go to #web on freenode, the number of "halp! my website is too slow! what giant react framework should I add to make it fast?!" questions is absurd
22:06:04 <FLHerne> (or don't, because it's crap)
22:06:53 <andythenorth> FLHerne you have, which saves me doing it
22:07:03 <andythenorth> I have real trouble with a swathe of the industry
22:07:13 <andythenorth> and they would have real trouble with me, so it's mutual
22:07:48 <andythenorth> "If God had wanted us to play football in the clouds, he'd have put grass up there." - Brian Clough
22:07:57 <andythenorth> play with the ball on grass, and stop fucking about
22:09:08 * FLHerne was single-handedly responsible for a 5MB interactive single-page application written in Angular once
22:09:19 <FLHerne> It was terrible and the customers hated it
22:09:29 <FLHerne> I think I learned my lesson
22:09:57 <andythenorth> I was a child of Flash
22:10:22 <andythenorth> and we learnt all the lessons inside a single executable that mostly worked reliably everywhere
22:10:41 <andythenorth> and mostly we learnt 'return html to requests, with rare xhr when it's needed'
22:11:44 <andythenorth> the answer is 'slowly' and it tends towards removing crap
22:11:53 <andythenorth> I mean, I could just get cloudfront, but eh
22:18:10 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8340: Draft: Feature: Create Universal (x86_64 + Apple Silicon) build on macOS https://git.io/JkqLt
22:20:42 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8340: Draft: Feature: Create Universal (x86_64 + Apple Silicon) build on macOS https://git.io/JkqLt
22:24:08 <andythenorth> if that PR is done by Dec 25th
22:24:21 <andythenorth> there might be a 10 year old who *doesn't* get an M1 laptop
22:24:32 <orudge> Well, it's all working on my own machine
22:24:34 <andythenorth> and is persuaded that an intel mac is better
22:25:04 <andythenorth> well maybe I can persuade him to let me test it on the 25th :P
22:25:15 <andythenorth> an hour of installing toolchains and compilers :)
22:25:52 <frosch123> andythenorth: he can read a book
22:27:36 <andythenorth> orudge do you notice any performance difference on M1?
22:27:44 <andythenorth> I am hoping the UMA solves all graphical issues :P
22:28:06 <orudge> Now, how do I go about testing changes on Azure Pipelines? It looks like I can create a new pipeline to bung my test stuff into. But maybe I should simply create my own free (apparently?) organisation and test it in there.
22:28:21 <orudge> andythenorth: hmm, I haven't tested it with anything particularly heavy-duty, feel free to send over something to test if you like and I can benchmark it
22:28:45 <frosch123> orudge: doesn't it also work for non-organisations?
22:28:47 <andythenorth> maybe we have a standard test game
22:29:04 <frosch123> i think TrueBrain and glx both tested stuff on their account
22:29:38 <frosch123> oh, wait, i thought we wanted to get rid of azure
22:29:43 <orudge> Well, that's the other thing
22:30:19 <glx> I didn't test stuff on azure
22:30:52 <orudge> I think they share agent templates these days, so in theory what works on one should work on the other
22:31:46 <glx> github actions are easier to test
22:32:26 <orudge> Yeah, which is what I'm doing just now
22:36:15 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:37:44 <glx> orudge: you can't use vcpkg included in github images
22:41:25 *** keoz has quit IRC (Ping timeout: 480 seconds)
22:42:53 <orudge> glx: yeah, the intention would be to create a custom cache similar to what we do for Windows (rather than rebuilding each time, though it is an option I suppose)
22:43:04 <_dp_> btw, newgrf vehicles seem to lag a lot, 1000 trains are already slow af
22:43:53 <orudge> andythenorth: so, on my Windows desktop, I get around 12-13fps (0.33x speed factor) with that save (Core i5-6500 3.2GHz)
22:44:25 <orudge> andythenorth: on my 2019 MacBook Pro, 2.3GHz i9 8-core CPU, I get about 9-10fps (0.29x speed factor)
22:44:27 * andythenorth wonders what Iron Horse does to perf. GLX :P
22:44:44 <orudge> On my M1, running the Intel version via Rosetta, I get 20fps, 0.63x speed factor
22:44:58 <orudge> Running the ARM native version, I get 28fps, 0.82x speed factor
22:45:05 <andythenorth> so the hype is real
22:45:45 <orudge> This is not an entirely scientific comparison of course, but there was a noticeable difference
22:46:03 <andythenorth> full animation on or off? :)
22:46:18 <_dp_> andythenorth, that lagging 1000 train save I'm looking at actually uses iron horse
22:46:23 <_dp_> and some other stuff though
22:46:50 <andythenorth> if it's a recent Horse, I'm recursively checking all the vehicles in the consist from every other vehicle, for every sprite draw
22:46:55 <andythenorth> amongst other things
22:46:57 <_dp_> says 2.8.0, no idea how old is that
22:47:24 <andythenorth> it does things that gut feeling says should harm peformance
22:47:29 <andythenorth> but hard to measure
22:48:23 <andythenorth> @orudge thanks for testing :)
22:50:33 <glx> orudge: looks like you could use a matrix to reduce copy paste
22:50:33 <_dp_> didn't dig much what exactly is slowing down but it may very well be the iron horse
22:50:54 <orudge> Oh, of course, I need to use the strgen from the x86_64 version
22:51:00 <LordAro> orudge: a friend of mine has tried OTTD on an M1, says it works but it "comes up in the app report as ‘iOS’". dunno if you know anything about that, or if there's anything that can be done about it (cmake, perhaps?)
22:51:04 <orudge> glx: yeah, this is just a very rough proof of concept at the moment
22:51:11 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:51:22 <orudge> LordAro: iOS, weird. How have they tried it? Building from source?
22:51:48 *** WormnestAndroid has joined #openttd
22:53:35 <TrueBrain> milek7: TrueBrain: btw why we need FD_SETSIZE at all <- I did not check; feel free to PR that :D
22:54:28 <glx> <@orudge> Oh, of course, I need to use the strgen from the x86_64 version <-- should be easy with the recent cross compile stuff
22:54:51 <glx> but that prevents matrix usage I guess
22:55:42 <TrueBrain> orudge: Now, how do I go about testing changes on Azure Pipelines? <- in case nobody told you yet, do not make changes to the azure pipelines :P LordAro should almost be done with the GitHub Actions variant, after which we burn Azure Pipelines while dancing naked around a fire :P
22:55:49 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8340: Draft: Feature: Create Universal (x86_64 + Apple Silicon) build on macOS https://git.io/JkqLt
22:56:02 <orudge> TrueBrain: that was what I was wondering :)
22:56:09 <TrueBrain> "The job running on runner GitHub Actions 7 has exceeded the maximum execution time of 360 minutes." <- Commit checker ... lol?
22:57:02 <LordAro> looks like it got stuck in a loop?
22:57:04 <TrueBrain> orudge: you can already prototype what you want with GHA, based on LordAro's work
22:57:17 <TrueBrain> as in, building a single target won't change that much anymore :)
22:57:43 <TrueBrain> we mostly test this by either using "master" in our fork or any other branch, or make a pull request to your own fork
22:57:53 <TrueBrain> if you use "master", make sure to push to origin, not upstream like I did :P
22:58:13 <orudge> It looks like what I've got so far is more or less working, hopefully. Waiting on a couple of vcpkg pull requests to be approved, and probably the upcoming release of cmake since the current version is borked with Apple Silicon in certain circumstances
22:58:33 <TrueBrain> LordAro: well, glx wrote the recursion, so ... I can blame him? :D
22:58:40 <TrueBrain> I think this is because I pushed twice quickly, or something
22:58:55 <TrueBrain> orudge: lolz :) Broken stuff all around :P
22:59:26 <TrueBrain> and I collected 2 AWS experts so far, in response to my post .. 1 an architect, the other technical sales
23:00:02 <glx> of course it fails as it just *4 before retrying
23:00:30 <glx> I think it's supposed to start with 4
23:01:52 <orudge> andythenorth: if this is of interest, the bigcg-lag.sav (at regular zoom), in fast-forward mode, gets 37-38fps on my desktop, and around 80fps on my M1
23:02:12 <TrueBrain> STOP SELLING UIS M1, or you have to buy one for all of us
23:02:14 <glx> anyway I think I can add a max depth to bail out
23:02:20 <andythenorth> TrueBrain they're really cheap
23:02:29 <andythenorth> you just have to get an ARM Linux for it
23:02:50 <orudge> Oh, and not sure if it makes a difference, but I'm doing this via VNC, as otherwise I have to swap my keyboard and mouse over, not enough desk space for two :P
23:03:04 <andythenorth> none of this surprises me, my kids have 4 year old iPads that perform better than my i9 8 core mac
23:03:17 <andythenorth> orudge that's showboating frankly :P
23:03:41 <milek7> 'regular zoom' means fully zoomed in? or something else
23:03:44 <orudge> I am quite impressed with it, I have to say
23:04:08 <orudge> milek7: 100% zoom, as in, what you'd get by default in classic TTD (the save opens up at full zoom, 3x is it? Not really sure)
23:06:04 <andythenorth> ok so we move OpenTTD to WASM and we host it all on M1 mac minis running ARM Linux
23:06:07 <andythenorth> happy days, it's a plan
23:06:16 <andythenorth> oh wait, WASM runs on your CPU :P
23:06:27 <TrueBrain> I hope the performance on M1 is better than the browser delivers, honestly :P
23:06:31 <andythenorth> so we just need to run it remotely and stream
23:06:41 <andythenorth> isn't that what the google thing does?
23:06:48 <TrueBrain> if it wasn't for the controller support, I would have pushed it for Stadia :)
23:07:09 <TrueBrain> not sure controller support is mandatory for them .. but seems likely
23:07:14 <andythenorth> 2020 has been a very interesting year
23:07:57 <TrueBrain> Google still hasn't indexed 6k pages of the wiki, lol
23:08:12 <milek7> TrueBrain: I have wondered whether to fix this by _memsetting the allocation
23:08:32 <milek7> or by zeroying sin_zero field explictly in _write_sockaddr
23:08:40 <TrueBrain> I have been wondering the same ... either that, or setting sin_zero to 0 .. which is a lot more annoying to do
23:08:50 <TrueBrain> in both cases, memset doesn't seem to be loaded yet
23:09:13 <TrueBrain> I do not know if other OSes set sin_zero to 0 on every command
23:09:27 <TrueBrain> for example in accept()
23:09:59 <milek7> I checked getsock/getpeer in linux
23:10:08 <milek7> it does since 2002: "BSD apps want sin_zero cleared in sys_getname."
23:13:53 <milek7> liblzma port seems to be on hold waiting for some other ports system
23:14:19 <TrueBrain> hmm ... well, with your solution of not needing autoconf, I can solve that in our CMake for now, I think
23:14:31 <TrueBrain> as long as the docker image doesn't need changing, that isn't too much of an effort
23:14:41 <TrueBrain> just too bad they don't want to upstream it yet
23:14:50 <TrueBrain> by that read, it can take a while for them to fix ports properly :D
23:15:06 <TrueBrain> but I would ask to hold off too :D
23:18:08 <TrueBrain> milek7: been reading a bit how linux kernel does this .. they seem to zero it every time they also set family/port/addr
23:18:25 <TrueBrain> so I guess it might be good to do it in write_sockaddr indeed
23:18:51 <TrueBrain> milek7: btw, your ws callback now has host/port; could you also add type? (UDP / TCP)
23:20:56 <orudge> Looks like the arm64 build succeeded on GitHub Actions (of course executing the tests didn't). Can look at LordAro's work and see if I can get an actual build out of it. :) But that's for another day, for now, bedtime.
23:21:21 <TrueBrain> or turn it around: tell LordAro that your GHA works, and ask if he can adapt your work :P
23:21:28 <TrueBrain> most of the time that is a few minutes work :)
23:21:46 <LordAro> i'm expecting orudge's thing to be done first :p
23:22:04 <TrueBrain> that would be rather impossible, not? :D
23:22:29 <LordAro> last i checked orudge's PR was just for getting the CI build working
23:22:39 <LordAro> release build is in theory just a minor alteration of that
23:22:43 <TrueBrain> but he talks about getting a build out of it :P
23:22:45 <milek7> it's funny that both these memsets weren't there originally, but added later ;P
23:22:54 <TrueBrain> milek7: it is FULL of those :)
23:23:30 <TrueBrain> LordAro: the point I was making, your work is mandatory for getting builds out of GHA :)
23:24:03 <milek7> TrueBrain: I can, but does this helps with anything?
23:24:07 <milek7> you still need to special handle that first UDP packet with port information :P
23:25:48 <TrueBrain> milek7: but that is a bit dirty, honestly
23:25:57 <TrueBrain> and you have to delay connecting till you receive the first packet
23:26:05 <TrueBrain> all a bit sub-optimal
23:26:09 <TrueBrain> makes more complicated code
23:26:27 <TrueBrain> so sending the 'sock.type' too allows for more configuration :)
23:26:57 <TrueBrain> and I think that packet is not even always send .. just happens to be the case for OpenTTD :P
23:27:07 *** Tirili has quit IRC (Quit: Leaving)
23:27:14 <TrueBrain> yeah, only if you set the source port
23:28:19 <TrueBrain> LordAro: but your GHA work was nearing completion, was it not? :)
23:28:39 * andythenorth should go to bed
23:28:49 <LordAro> 80% of it done, 80% to go
23:30:21 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:30:41 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8340: Draft: Feature: Create Universal (x86_64 + Apple Silicon) build on macOS https://git.io/JI2n8
23:31:14 <TrueBrain> orudge: I like that most work is upstream :D
23:32:27 <TrueBrain> LordAro: wait, you don't build 32bit anymore?
23:32:36 <LordAro> couldn't get it working
23:32:54 <LordAro> all sorts of dependency issues
23:33:05 <TrueBrain> I am not sad; but I am surprised :D
23:33:13 <LordAro> 32bit windows is still there, which would be "more" used than 32bit linux
23:34:12 <TrueBrain> well, we could make a deal I look into the GHA a bit, and you review emscripten a bit? :P
23:34:34 <TrueBrain> (not tonight, but tomorrow or so :P)
23:34:54 <TrueBrain> from what I can tell, most what GHA now needs is a bit of restructuring like AP was
23:35:03 <TrueBrain> fetch source, build tarball with ottdrev etc
23:35:10 <LordAro> that was going to be my next thing
23:35:13 <TrueBrain> collect, generate checksums, some metadata files
23:35:32 <TrueBrain> which is mostly copy/pasting from AP .. I can give that a look tomorrow or so
23:35:40 <TrueBrain> depends how addicting a game that releases in 25 minutes is
23:36:00 <TrueBrain> as what ever you do, I have to finetune it anyway to work with AWS... I won't let you suffer that part :P
23:36:41 * andythenorth stayed up way too late
23:36:44 *** andythenorth has quit IRC (Quit: andythenorth)
23:36:48 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:36:49 <LordAro> ah yeah, cmake library detection, rather than the dependencies themselves
23:36:52 <TrueBrain> I really really do not want to look into the building of individual targets ... it was was pushed me away the most :P
23:37:01 <TrueBrain> I did that ... 5 times now in 15 years? Pretty done with it :P
23:37:29 <TrueBrain> it is such a shitty job to do, honestly ..
23:37:37 <TrueBrain> every OS has its own little thing that breaks EVERYTHING
23:37:41 <TrueBrain> you do learn a lot about OSes
23:37:45 <TrueBrain> that is the nice thing, I guess
23:38:28 *** Progman has quit IRC (Remote host closed the connection)
23:40:27 <milek7> it should be tcp/udp or dgram/stream?
23:41:23 <TrueBrain> for me that is rather tomato tomato
23:42:02 <milek7> pretty sure they don't support SCTP or something else :P
23:42:04 <TrueBrain> I mean... SPX/IPX nobody uses anymore
23:42:20 <TrueBrain> so everyone understands that DGRAM means UDP, and the other way around
23:42:36 <TrueBrain> but STRICTLY seen, it should be stream/dgram .. but the more practical way is tcp/udp :P
23:42:55 <TrueBrain> well, they only support AF_INET and AF_INET6, I now realise
23:43:03 <TrueBrain> in that case they are synonyms
23:43:17 <TrueBrain> AF_INET + DGRAM == UDP
23:43:53 <TrueBrain> so yeah, potato potato
23:44:30 <TrueBrain> I was looking into FD_SETSIZE .. in 2 out of the 3 cases we could use a form of sock+1, yes
23:44:35 <TrueBrain> the 3rd ... is a lot more tricky
23:44:54 <milek7> inet + dgram could be SCTP, but they don't support SCTP.. so yeah
23:46:02 <TrueBrain> huh? How would you identify that, I wonder ...
23:46:13 <milek7> socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP)
23:47:08 <TrueBrain> fucking weirdos ...
23:47:55 <TrueBrain> makes me wonder how many managed switches understand that :P
23:48:06 <TrueBrain> I always have so many questions with these weird things :)
23:48:17 <milek7> probably that's why nowadays everything is packed into UDP :P
23:49:02 <TrueBrain> but okay ... a review of your PR will tell you if the people of emscripten agrees with one or the other :D
23:49:32 <TrueBrain> I cannot believe emscripten only supports select() of 64
23:49:45 <TrueBrain> that is a bit weird .. I wonder how easy it is to make a problem out of that :P
23:49:58 <TrueBrain> things like .. do they recycle socket numbers?
23:50:05 <TrueBrain> or is it just a +=1 :)
23:56:11 <TrueBrain> and you are faster in finding that than I am :P
23:56:23 <TrueBrain> I just got to the createSocket function :P
23:56:33 <TrueBrain> they do allow 4096 open FDs
23:56:37 <TrueBrain> but you can only select 64
23:56:51 <TrueBrain> that O(n) function, lol
23:57:22 <TrueBrain> there is room for improvement, I would say :)
23:59:52 <TrueBrain> owh, with assertions on, creating a socket with fd >= 64 crashes already
23:59:57 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #8368: Fix: Prevent infinite recursion in commit checker https://git.io/JI2Ch
continue to next day ⏵
