IRC logs for #openttd on OFTC at 2021-07-31
⏴ go to previous day
00:13:06 *** ChanServ sets mode: +v tokai
00:19:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
00:21:12 <FLHerne> > gave me a error message that said something like "Not enough memory"? idk i have a bad attention span
00:22:00 <glx> at least crash log confirms
00:24:39 <FLHerne> It's a pity crash.log doesn't tell you how much RAM the system has?
00:25:13 <FLHerne> getting OpenTTD to OOM on its own should be pretty much impossible on most systems
00:27:41 <FLHerne> TIL that in Python, you can use square brackets in tuple unpacking, `del` and various other places where no-one uses them :p
00:28:36 <FLHerne> e.g. I often see `a, b = some_tuple` or even `(a, b) = some_tuple`, but `[a, b] = some_tuple` is just weird to me
00:28:47 <FLHerne> it's semantically identical
00:29:21 <FLHerne> The IDE I'm using doesn't know this either, so I'm in good company
00:53:45 <glx> I think we could had memory in the report
00:56:13 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:10:37 <_dp_> it doesn't have to just be openttd to oom, some chrome in the background can also help ;)
01:34:57 *** snail_UES_ has quit IRC (Quit: snail_UES_)
02:19:34 *** tokai|noir has joined #openttd
02:19:34 *** ChanServ sets mode: +v tokai|noir
02:22:00 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:26:26 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:48:18 *** WormnestAndroid has quit IRC (Read error: No route to host)
02:48:28 *** WormnestAndroid has joined #openttd
02:55:12 <Eddi|zuHause> hm... cities skylines is being naughty to me... i tried running it again after like a year, and some of the hotkeys don't work... which is a unity bug that was supposedly solved 6 years ago. and after a while it also stopped recognizing all workshop objects and mods... which people described as "well, it started working again after {restarting|relogging|whhatever}" which isn't helping
03:12:40 *** Wormnest has quit IRC (Quit: Leaving)
05:36:00 *** ChanServ sets mode: +v tokai
05:42:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
06:12:32 *** sla_ro|master has joined #openttd
06:54:24 *** sla_ro|master has quit IRC ()
06:56:32 *** andythenorth has joined #openttd
07:06:40 *** Progman has joined #openttd
08:25:29 * andythenorth automating some docs
08:26:34 *** HerzogDeXtEr has joined #openttd
08:26:49 * TrueBrain automating some other things :P
08:28:48 <andythenorth> currently I can only push to bananas via a browser?
08:29:03 <andythenorth> and doing all that scripted with curl might be blah blah
08:29:58 <TrueBrain> there is a beginning of a CLI, but no demand, so .. yeah
08:30:12 <andythenorth> I might be able to manufacture demand :P
08:30:45 <andythenorth> currently I am quite happy to just automate some local things
08:31:10 <TrueBrain> I believe the CLI does allow uploading already .. just automated authentication will be a bit difficult
08:35:56 <andythenorth> in browser it's quite simple, I assume because I have github cookie
08:36:07 <andythenorth> or however auth works
08:38:53 <TrueBrain> GitHub takes care of that, yes
08:39:03 <TrueBrain> I really don't care how they do it :D :D
08:40:24 <andythenorth> the less we have to know about implementations ....
08:41:00 <andythenorth> nobody wants to see how the sausage is made :P
08:44:19 *** frosch123 has joined #openttd
08:45:39 *** Progman has quit IRC (Remote host closed the connection)
08:45:56 * andythenorth wonders about running 4 rsyncs at once
08:45:59 <andythenorth> there are 4 dirs
08:46:04 <andythenorth> how much overhead :D
08:47:51 <frosch123> why is there "C:\Program Files (x86)\Steam\gameoverlayrenderer64.dll" in #9459 ?
08:48:03 <frosch123> does windows have something like LD_PRELOAD?
08:48:23 * andythenorth thinks if a total rysnc with a primed folder is 1s, parallelising is not likely to be a winner
08:50:06 <TrueBrain> frosch123: when you launch a game via Steam, that DLL is injected in your process
08:50:32 <TrueBrain> possibly only via the OpenGL flow, never looked into that
08:51:37 <TrueBrain> that is the technique you use on Windows for that
08:54:30 <frosch123> i like how about half of that page is about security and exploits :)
08:55:12 <TrueBrain> similar as with LD_PRELOAD :P
08:55:19 <frosch123> anyway, OOM on a 64bit system is new
08:55:32 <frosch123> on 32bit address space exhaustion was easy
08:55:49 <TrueBrain> I hit a lot of OOMs .. but Firefox with console open and emscripten is consuming a LOT of RAM :P
08:55:55 <frosch123> and allocating 3MB is not much either
08:56:07 <TrueBrain> OpenTTD starts to complain to me really quick it cannot allocate the spritecache
08:56:48 <frosch123> does windows not over-commit like linux does?
08:57:10 <frosch123> i can only trigger endless swapping, but no OOM
08:57:22 <TrueBrain> I disabled swap on Windows
08:57:39 <TrueBrain> (well, what-ever it is called on Windows)
08:58:06 <frosch123> okay, i never quite understood the point of swapping. it was always too slow to make any sense
08:58:29 <TrueBrain> that is why I disable it :P I rather have my processed being killed than my whole system crawling to a halt :P
09:38:35 <frosch123> there are android devices with 16bpp display modes?
09:39:02 <frosch123> i did not expect that 90s thing to revive
09:53:33 <TrueBrain> I am as surprised as you are :P
09:54:29 <frosch123> also, i need a better mouse
09:54:42 <frosch123> the expensive mouses have weird shapes and many useless buttons
09:54:51 <frosch123> and the cheap mouses have broken button which click mutliple times
09:55:04 <frosch123> is there no normal mouse?
09:59:43 <andythenorth> do microsoft not make theirs anymore?
10:00:01 <andythenorth> yeah, looks unchanged for last 15 years
10:00:39 <andythenorth> all other mice aren't needed
10:04:15 <frosch123> does it have a middle button?
10:04:26 <frosch123> reads like only two buttons
10:04:39 <nielsm> the wheel is a button too
10:05:06 <frosch123> ok, it doesn't say that. and i have seen both
10:05:15 <_dp_> only problem is... it's the second one xD
10:05:28 <_dp_> but I like having a lot of extra buttons xd
10:08:05 <peter1138> Second one? Do you dual-wield your mice? :D
10:08:25 <nielsm> I love my logitech MX Master
10:08:49 <nielsm> most other mice are also too small to fit my hand well
10:11:40 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
10:12:07 *** andythenorth has quit IRC (Quit: andythenorth)
10:28:55 <_dp_> great, I have a crash that only happens on release build without gdb :/
10:32:31 <LordAro> those are the best sort of crashes
10:38:33 <_dp_> well, at least it's 100% reproduceable...
10:50:54 <frosch123> TrueBrain: how do i enter constants in the editor?
11:01:57 <TrueBrain> First I need to fix that it remembers anything
11:02:13 <TrueBrain> After that adding stuff should be easy :)
11:05:57 <frosch123> i was worried you would add var1A for the lolz
11:06:40 *** virtualrandomnumber has joined #openttd
11:10:14 <TrueBrain> Haha, no, was not planning on that :p
11:18:52 *** D-HUND is now known as debdog
11:40:00 <Eddi|zuHause> the thing i worry about is that it's going into the "GRFMaker" corner, where it's not powerful enough in some special corner cases, and later nobody maintains it
11:41:02 <frosch123> thanks for taking over the worrying part
11:48:58 <DorpsGek> frosch123: OpenTTD uses TCP and UDP port 3979 for server <-> client communication, UDP port 3978 for masterserver (advertise) communication (outbound), and TCP port 3978 for content service, a.k.a. BaNaNaS (outbound)
11:55:09 *** sla_ro|master has joined #openttd
11:59:21 <frosch123> how weird, if i "add server" an ip, and connecting fails, it closes the multiplayer list
12:00:29 <TrueBrain> suits you right! :P
12:00:56 <frosch123> is the gamecoordinator stuff done?
12:01:49 <frosch123> is it enabled by default?
12:01:52 <Eddi|zuHause> well, someone's gotta worry?
12:02:00 <TrueBrain> frosch123: master-server is removed
12:02:02 <frosch123> my dedicated server says nothing about it in -d net=3
12:02:05 <TrueBrain> so you cannot even disable it :P
12:02:21 <TrueBrain> why would you run it with -dnet=3? :)
12:03:10 <frosch123> bigger number is better?
12:03:15 <TrueBrain> frosch123: is your game type set to public?
12:03:27 <TrueBrain> nah, 3 is fine, just surprised you set it :) The default is sane these days :)
12:03:38 <TrueBrain> "set server_game_type" will tell you :)
12:04:00 <TrueBrain> so there you have it :)
12:04:03 <TrueBrain> set it to invite-only or public
12:05:28 <TrueBrain> many routers don't allow STUN to their own IP
12:05:31 <TrueBrain> which is really annoying
12:05:52 <TrueBrain> it is against spec to not allow it, to be clear
12:05:56 <TrueBrain> RFC is pretty clear it should work
12:06:13 <TrueBrain> but .. yeah ... routers and implementing RFCs ... not things you see working together often :D
12:06:38 <glx> yeah even before STUN many didn't allow ip:port to extern ip from inside
12:06:54 <TrueBrain> that is the same thing ;)
12:07:19 <TrueBrain> I am happy both my routers do allow it .. but I know many that do not :(
12:07:43 <TrueBrain> frosch123: btw, please do make a bug report about the "add server" thing :) Sounds like something we should fix
12:07:57 <TrueBrain> I think an OnFailure is being too greedy ..
12:08:25 <glx> shouldn't we remove the lobby window and force join as spectator ?
12:08:40 <frosch123> now it disconencted "no resposne from server" while progressing downloading the map :p
12:09:15 <TrueBrain> didn't we address that months ago?
12:09:31 <frosch123> ah, no, it's the server kicking the client for taking too long
12:09:56 <glx> qemu-arm64 too slow to join ?
12:10:22 <frosch123> but downloading the map is slow somehow
12:10:23 <TrueBrain> ah, yeah, we fixed that the client was no longer timing out .. the server still has this "lag" thing he looks at
12:10:28 <frosch123> so the server kicks the client
12:10:43 <TrueBrain> honestly, our default values are a bit stiff there
12:11:15 <frosch123> oh, new settings folder
12:11:20 <frosch123> so many new things :)
12:11:30 <TrueBrain> you are away for a few weeks .. and boooommmm :P
12:11:41 <TrueBrain> but nothing you didn't know I was doing, so it is fine ;)
12:14:12 <frosch123> again "connection lost"
12:14:32 <frosch123> maybe my internet has a bad day
12:14:42 <frosch123> ah, it recovered after 7 seconds
12:14:48 <TrueBrain> isn't the qemu to blame here?
12:15:09 <TrueBrain> can't imagine writing out the packets will be fast
12:15:18 <frosch123> server -> qemu -> host -> turn -> host -> client
12:15:42 <TrueBrain> we stream the map while compression is running .. might be the bottleneck here
12:15:43 <frosch123> i do not see any "autosave" in the server console
12:16:00 <frosch123> also, the client does not pause the game, so really weird
12:16:12 <TrueBrain> set pause_on_join ? :)
12:16:16 <frosch123> shouldn't the client pause if there are no sync packets from the server?
12:16:34 <TrueBrain> clients do not pause, but simply do not progress, I think
12:17:32 <frosch123> yes, but trains are still moving all the time, while it displays "connection lsot for 7 seconds"
12:17:50 <TrueBrain> or at least, not what I would expect either :D
12:19:27 <frosch123> anyway, i let that _dp_ savegame run on master/main with arm64 server and amd64 client, and no "desync within 1 minute"
12:19:48 <frosch123> technically the report was with server/client roles swapped, but I blame the android port
12:19:53 <frosch123> or possibly the used compiler
12:20:02 <frosch123> i used debian/gcc8 on both after all
12:20:22 <TrueBrain> ah, that is why you were compiling for arm :D
12:26:10 <frosch123> i looked wrong. the client does stop the ticks
12:27:19 <frosch123> another funny thing i noticed. the client connects to server when entering the lobby and it reconnects when joining the game
12:27:28 <frosch123> that popups the "do you want to use turn" twice
12:27:39 <frosch123> if you use the "only this time" button
12:28:03 <TrueBrain> one of the reasons to get ride of the lobby window :)
12:28:21 <TrueBrain> but there is little we can do about it .. it creates a new TURN connection for both the lobby as joining the game
12:29:24 <TrueBrain> I considered "remembering" the "yes" for like 30 seconds, and not ask again .. but that becomes iffy real quick :D
12:30:03 <frosch123> hmm when i restart the server by loading a savegame via server console
12:30:10 <frosch123> clients try to rejoin the game
12:30:19 <frosch123> but it looks like it now uses a new server id
12:30:28 <frosch123> so client waits infinitely for server to restart
12:30:41 <TrueBrain> funny, for me it just aborted with: server not available
12:31:05 <TrueBrain> the rejoining thing is weird .. and was broken .. and is still broken :P
12:31:15 <frosch123> it does that when i close the "the server is restarting... please wait.." window
12:31:43 <TrueBrain> from what I deduced, it assumes that by the time the client gets back to reconnect, the server is online
12:31:47 <TrueBrain> otherwise .... things go weird :P
12:32:13 <TrueBrain> it is funny if we look closely into how the network behaves, we find a lot of weirdness :D
12:32:23 <TrueBrain> but we should just make tickets out of it, so we don't forget / can solve them over time
12:32:27 <TrueBrain> I was too lazy, I have to admit :D
12:43:05 <frosch123> oh right, i have a big download running on some other machine, maybe that is blocking the line
12:43:16 <frosch123> forgot about that :)
12:45:59 *** tokai|noir has joined #openttd
12:45:59 *** ChanServ sets mode: +v tokai|noir
12:48:36 *** jottyfan has joined #openttd
12:52:44 *** tokai has quit IRC (Ping timeout: 480 seconds)
13:08:33 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
13:08:48 *** Kitrana has joined #openttd
13:37:08 *** supermop_Home has joined #openttd
13:37:59 *** andythenorth has joined #openttd
13:38:33 *** roadt_ has quit IRC (Ping timeout: 480 seconds)
13:53:18 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
14:05:28 *** snail_UES_ has joined #openttd
14:17:44 <TrueBrain> right ... now time to convert the graph to Action2 chain .. lets see ..
14:25:52 <TrueBrain> at least that setting works :P
14:48:15 *** andythenorth has quit IRC (Quit: andythenorth)
14:57:30 <TrueBrain> right, debugging action2 chains .. hmm
14:57:45 <TrueBrain> how do I do that for the placement callback?
15:10:25 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
15:10:36 *** WormnestAndroid has joined #openttd
15:15:36 <TrueBrain> once I saw the debug-icon when I queried an industry ... now what-ever I try, I can't get that to work anymore :D
15:15:58 <michi_cc> I think you need to have newgrf developer tools enabled.
15:16:05 <frosch123> placement cb is hard, because there is no industry to click
15:16:07 <TrueBrain> which is the annoying part :P
15:16:14 <TrueBrain> well, the industry got placed :D
15:16:19 <frosch123> also placement cb is an exception to everything because it uses different variable numbers
15:16:35 <TrueBrain> different variable numbers?
15:17:28 <frosch123> only this cb, unique exception :)
15:18:02 <TrueBrain> but yeah, I now just returned 0x8000
15:18:10 <TrueBrain> which, if I understand it correctly, should prevent the industry from being placed
15:18:16 <TrueBrain> but it is placed .. so I need to debug what is going on :D
15:18:54 <frosch123> did you set the flag in property 21?
15:19:29 <frosch123> can you dump nfo output?
15:19:41 <TrueBrain> that is the one limitation I still have .. I cannot extract the file from the browser :D
15:19:45 <TrueBrain> was too lazy to build that :P
15:23:17 <TrueBrain> so I was kinda hoping I could see on the industry whether the cb was registered at all etc :)
15:23:21 <frosch123> i assume the mq from 2014 does not help :p
15:23:47 <TrueBrain> lol, I would guess not, no :)
15:25:15 <TrueBrain> but if I have NewGRF Dev Tools enabled, and I query an industry that clearly states it is build because of my NewGRF .. the debug icon should exist, not?
15:28:52 <TrueBrain> right, lets first fix the bug in emscripten that configuration files are not saved
15:28:56 <TrueBrain> that might help at least a bit
15:31:43 <TrueBrain> what am I doing wrong I wonder :P
15:37:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:39:51 *** WormnestAndroid has joined #openttd
15:40:12 <frosch123> did not try whether it compiles :p
15:40:16 *** Wormnest has joined #openttd
15:41:43 <frosch123> TrueBrain: eugh, did you open the industry window? instead of the landinfo window?
15:42:18 <TrueBrain> will try that when I figured out why Emscripten FS is being a bitch :D
15:42:23 <frosch123> landinfo would show the icon, if you have a newgrf industry tile
15:43:19 <TrueBrain> guess that makes sense .. means the screenshots I have been seeing were misleading me :P
15:45:22 <TrueBrain> I really do not know why, but the game no longer stores openttd.cfg with Emscripten ..ffs :P
15:46:53 <TrueBrain> right .. found the window now, tnx frosch123 :D
15:47:09 <TrueBrain> now ... should there be a "callback", I wonder .. as it is empty .. I really need to read the source :D
15:56:00 <frosch123> hmm, why does my qemu port forwarding not work...
15:56:05 <frosch123> it works for ssh, but not for openttd
15:56:36 <TrueBrain> my common mistakes: not binding the server on 0.0.0.0, having a custom port in the config I forgot about
15:57:08 <frosch123> netstat says it is listening on 0.0.0.0:3979
15:57:23 <frosch123> host says, qemu is listening on 127.0.0.1:3979
15:57:31 <frosch123> no idea where stuff gets lost inbetween
16:00:16 <TrueBrain> okay .. without changing anything, all of a sudden the config files work again .. wth
16:00:19 <TrueBrain> what-ever, time for dinner
16:02:02 *** Progman has joined #openttd
16:10:38 <frosch123> ok, now it works. i incorrectly assumed forwarding tcp would suffice
16:14:13 <frosch123> and indeed the connection-lost thing is actually the autosave
16:14:51 *** andythenorth has joined #openttd
16:16:37 <TrueBrain> and I got a callback registered, w00p
16:17:26 <TrueBrain> not that it is doing what I expect
16:17:41 <andythenorth> I write newgrf literally one line at a time :P
16:17:44 <andythenorth> even after 10 years
16:17:56 <andythenorth> line, compile, line, compile
16:23:21 <glx> <TrueBrain> but yeah, I now just returned 0x8000 <-- doesn't that also means display GRF string D000 ?
16:25:50 <glx> I think 0x8401 would be a safer choice
16:28:13 *** andythenorth has quit IRC (Quit: andythenorth)
16:40:59 <glx> anyway 0x8000 should work even if D000 string is not defined (it will be STR_UNDEFINED)
16:51:03 <Rubidium> frosch123: might #9458 be the same as #9407? No idea whether one may create new towns on that server, but it might be interesting to know. I can't find an usual suspect for endianness desyncs (i.e. a SLE_VAR_XXX that is wrong for the actual type)
16:53:17 <Rubidium> though finding desyncs for those kinds of unattended servers might be hard to reproduce if there was no desync debug logging running
16:54:08 <frosch123> founding towns is kind of rare, isn't it?
16:54:22 <frosch123> otherwise 9458 has about no info
16:57:19 <Rubidium> it is rare, but that does not mean they can't be the same issue. If the server is restart, the problem goes away
16:57:35 <Rubidium> so it's hard to reproduce it without actually rerunning the commands
16:58:10 <glx> yeah every client joining after the town creation will desync
16:59:49 <glx> but without at least command history from the server it's not possible to know if a town has been created
17:04:47 <_dp_> don't think town founding is allowed on reddit
17:05:09 <_dp_> for all I've seen it some kind of mac+reddit issue, non-macs are fine on reddit and macs are fine elsewhere
17:06:10 *** gelignite has joined #openttd
17:12:10 <Rubidium> and then only those new non-Intel macs?
17:13:44 <_dp_> irrc andythenorth even tested that at some point
17:14:12 <_dp_> got desynced or smth like that on reddit with whatever mac he was using
17:15:28 * Rubidium wonders about the phone-homey-ness of sending a DESYNC error packet with the content of CrashLog::LogOpenTTDVersion and maybe CrashLog::LogOSVersion to the server, and the server then logging that. I guess that might be going quite far, though would help in these situations. Maybe even the server sending its information to the client, so a client might be gathering basis information as well for
17:17:05 <_dp_> most don't even understand that desync is a bug
17:17:26 <frosch123> since it's not a real crash, you can show a proper "send desync report to openttd.org" window
17:17:42 <_dp_> I see a lot of desyncs on the servers but no reports whatsoever
17:18:20 <glx> clients assume it may happen and don't care about it
17:18:31 <frosch123> it would not contain info for actually reproducing an issue, but it would give some statistics to guess correlations
17:18:34 <_dp_> well, to be fair any possible desync report is kinda useless as well
17:18:47 <_dp_> you need at least saves from both sides to have a chance to figure out something
17:19:28 <glx> won't work for desync on join
17:19:33 <frosch123> _dp_: but it would help with claims like "only macs desync" or "only android desyncs"
17:20:03 <_dp_> well, yeah, but won't help fix it
17:20:07 <glx> like #9458, as the savegame is correct while the running server is not
17:20:44 <Rubidium> well... if say 95% of the cases happen with builds not made by OpenTTD (could guess that based on compiler/build time), that would potentially help dismiss reports easier as well
17:21:36 <TrueBrain> we could report desyncs to the Game Coordinator for statistics ;)
17:22:11 <_dp_> what good that's gonna do? i can give you some statistics if you want :P
17:23:16 <TrueBrain> btw, JGRPP has some very nice additional stuff for desyncs, mostly noticing a lot earlier when they happen. Would be useful to upstream those :) I keep wanting to, but I keep finding other stuff to do :D
17:24:03 <Rubidium> and also add NewGRFs to those reports, as that might give some more information as well. And maybe also information like how long the client was joined to the server?
17:24:35 <Rubidium> but alas, that would probably require consent of the user to send those reports
17:24:42 <_dp_> about 1% of sessions on citymania server ended in desyncs :p
17:24:54 <TrueBrain> Rubidium: a nice "Send Report" dialog? :D
17:25:19 <TrueBrain> ugh, on my wishlist is too to add sentry.io to OpenTTD, to collect normal crashes ..
17:25:23 <Rubidium> yes, with the information that is going to be sent
17:28:11 <_dp_> oh, it's 2% of sessions on 1.11.2...
17:47:18 <TrueBrain> okay .. after some debugging ... I forgot set-id is sometimes u16 sometimes u8 in the current specs .. after making sure I send the right type, I can deny the game from building coal mines :D
17:54:45 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
18:06:41 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:11:11 *** jottyfan has quit IRC (Quit: jottyfan)
18:21:26 <_dp_> hm, that android desyncs with some cargo packets having id's swapped
18:21:30 <_dp_> other than that it's identical
18:23:08 <frosch123> i wondered whether it's something trivial, like uploading the wrong binary to the android store
18:23:40 <frosch123> the only suspicious thing in the android diff was that frame-skipping
18:28:35 <_dp_> nah, I think I know what's going on
18:28:43 *** nielsm is now known as Guest2908
18:28:56 <frosch123> not sure how the networking works, maybe that _game_speed>100 would execute multiple ticks per network frame
18:29:11 *** Guest2908 has quit IRC (Ping timeout: 480 seconds)
18:29:14 <TrueBrain> frosch123: in network games, game_speed cannot be different from 100 without modifying other things ;)
18:29:29 <_dp_> it's different sorting order
18:30:05 <TrueBrain> either way, it should be fine to call that function multiple times .. it is just drawing that is being skipped. If splitting game-loop from GUI succeeded, ofc :)
18:30:15 <TrueBrain> the network-stuff is inside that GameLoop
18:30:41 <Rubidium> I see no reason why cargo packets would be sorted differently
18:30:43 <_dp_> here, should be stable sort
18:31:21 <Rubidium> so that might cause desyncs
18:32:14 <TrueBrain> action2 is something special .. lol. But I think I get it :) I had to read the source to understand what it actual did, as the wiki description left some possibilities :D
18:32:19 <_dp_> I'm not sure how reordered packets cause desyncs but that can reorder them afaict
18:34:35 <Rubidium> if amount - moving < used_stations.size(), then some stations won't get a packet. If the sort is unstable, on one platform station A and B get some cargo and on another B and C get the cargo
18:38:05 <frosch123> i inserted a std::reverse in front of that sort on the client
18:38:12 <frosch123> desyncs within the claimed minute :)
18:38:26 *** virtualrandomnumber has joined #openttd
18:38:38 <frosch123> _dp_: so, congratz :)
18:41:40 <TrueBrain> how does action2 deal with negative values .. hmmm
18:41:48 <Rubidium> the other std::sorts seem to be only used in/for the "UI" code
18:42:00 <frosch123> TrueBrain: it doesn't :p
18:42:06 <frosch123> results are unsigned
18:42:09 <TrueBrain> I want to know if A is bigger than B
18:42:16 <TrueBrain> so I do A - B .. but ..
18:42:25 <TrueBrain> I tried to check between 0 and 0x7fffffff
18:42:25 <frosch123> there are \cmp and \ucmp
18:42:28 <TrueBrain> that seems to be wrong :P
18:42:49 <frosch123> but 0..7fffffff shoudl also work
18:43:05 <frosch123> just 80000000..00000001 does not work
18:43:34 <TrueBrain> oof, cmp has an annoying return value
18:45:48 <TrueBrain> I absolutely adore var1a :)
18:48:47 <TrueBrain> lol, I assumed \2+ meant \x02+ ..
18:49:43 <TrueBrain> there we go .. no coalmine close to a town \o/
18:51:47 <DorpsGek> - Update: Translations from eints (by translators)
18:56:44 *** jottyfan has joined #openttd
19:06:52 <glx> <TrueBrain> oof, cmp has an annoying return value <-- the 0, 1 or 2 thing ?
19:08:18 <_dp_> how do I get that soundtrack out of my head now :/
19:12:52 <_dp_> what's the easiest way to fool network version detection on vanilla?
19:12:59 <_dp_> trying to insert std::reverse to check...
19:13:45 <frosch123> tag + modified could join tag + unmodified for me
19:14:18 *** gelignite has quit IRC (Quit: Stay safe!)
19:16:12 <TrueBrain> it makes sense from NFO point of view
19:16:20 <TrueBrain> but for me it is a tat annoying to deal with :)
19:25:25 *** andythenorth has joined #openttd
19:47:49 *** gelignite has joined #openttd
19:59:06 <DorpsGek> [OpenTTD/OpenTTD] ldpl opened pull request #9460: Fix: Use of unstable sort when distributing cargo production can caus… https://git.io/JBPMz
20:28:07 <andythenorth> so what am I supposed to be doing?
20:28:12 * andythenorth has been having a holiday
20:28:20 <andythenorth> don't we need to release nml or something?
20:29:07 <andythenorth> been some fixes since that PR :)
20:29:48 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
20:35:55 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:36:18 *** HerzogDeXtEr has joined #openttd
20:46:12 <andythenorth> hmm can we do stations in nml?
20:46:20 <andythenorth> or maybe TrueBrain's thing?
20:47:26 <glx> stations are not yet in nml
20:48:05 <andythenorth> from what I've seen of stations in nfo, it's probably a big job
20:48:10 <glx> I tried once, and gave up
20:48:17 <andythenorth> nothing seems to be shared with e.g. industries, objects
20:48:25 <andythenorth> I really don't understand nfo stations
20:52:47 *** jottyfan has quit IRC (Quit: jottyfan)
21:00:21 <TrueBrain> okay ... I have some basic stuff working, it seems ..
21:00:37 <TrueBrain> it is a bit difficult to generate code from such tree
21:00:51 <TrueBrain> especially because of the 0x20 you need to chain a 0x89
21:00:56 <TrueBrain> but I think I found a clean way ..
21:01:36 <TrueBrain> but the "customized" placement layout it now shows works. All other settings do not work yet :P
21:02:04 <glx> andythenorth: basically spritelayout is an action 2 for everything except stations, where it's in action 0
21:06:10 * andythenorth made location checks a tree
21:06:29 <andythenorth> and requires a bit of author knowledge to prevent chaining nonsense checks
21:06:48 <TrueBrain> right, lets remove settings that don't work .. silly to show stuff people cannot use yet
21:09:41 <TrueBrain> right, this actually works :D
21:10:13 <TrueBrain> do I dare to look what kind of callback chains andythenorth made for industry placement? :D
21:11:00 <andythenorth> it's just a python tree made by someone who doesn't quite understand recursive trees
21:11:06 <glx> so it can be hard to follow in nfo
21:11:50 <andythenorth> glx yeah stations, spritelayout in action 0
21:11:55 <TrueBrain> now the trick to find the source file that tells me how you did it ..
21:12:08 <andythenorth> stations just breaks any understanding of how grf works
21:13:10 <glx> then pynml, then nml, then nfo :)
21:15:00 <TrueBrain> that is not too bad andythenorth , that at least is readable enough :)
21:15:20 <TrueBrain> I will most likely add a few of those in the dropdown, just as that is easier :)
21:15:42 <andythenorth> the python is fine :)
21:15:50 <andythenorth> the nml isn't to be looked at :)
21:16:22 <glx> unluckilly I sometimes need to look at it to debug the compiler
21:17:36 <TrueBrain> the cluster thing .. that just counts all industries on the map?
21:20:05 <TrueBrain> hmm .. placement per layouts .. yeah, I will keep that as "advanced use only" :P
21:20:28 <TrueBrain> guess you should be able to store custom placements, so you can reuse them for other industries :)
21:20:54 <andythenorth> cluster checks the map size
21:21:04 <andythenorth> then says 'x clusters'
21:21:27 <andythenorth> it's one of those things where it would work better if the game had 'regions'
21:22:07 <TrueBrain> owh, I see what you did there ..
21:22:17 <TrueBrain> the first N (where N = amount of clusters) you just place the industries random
21:22:24 <TrueBrain> after that, only if they are in range of an already existing one
21:23:44 <TrueBrain> there is a check for desert tiles? Or is it doing that the stupid way? :P
21:23:55 <TrueBrain> (check for distance to desert tiles)
21:24:06 <frosch123> you can check desert tiles
21:24:28 <andythenorth> usually tile checks are done in tiles
21:24:38 <TrueBrain> yeah, I meant distance to, frosch123 :)
21:25:11 <frosch123> i think there is only distance to water
21:25:20 <TrueBrain> so it is doing it the stupid way
21:25:28 <TrueBrain> guess with procs you can make small loops
21:26:02 <TrueBrain> a proc cannot call itself?
21:26:02 <andythenorth> you can do a circular tile check
21:26:07 <andythenorth> but you can't loop
21:26:14 <frosch123> you can unroll finite loops
21:26:17 <andythenorth> do I dare show him the unroll?
21:26:32 <TrueBrain> I would expected a proc to be able to call itself :D
21:26:35 <andythenorth> actual loops would be super useful
21:26:41 <andythenorth> but I don't see how it could work
21:26:46 <frosch123> all action123 are finite :)
21:27:01 <TrueBrain> finite doesn't exclude recursion ;)
21:27:14 <TrueBrain> recursion-depth is a thing :D
21:27:28 <TrueBrain> but I can see the argument there ;)
21:27:29 <glx> if an action 2 calls itself, it won't be itself but the previous defined action 2 with the same ID
21:27:46 <andythenorth> that was the problem I saw too :)
21:30:22 <TrueBrain> anyway, happy with this result .. guess next step is .. making it a bit more dynamic .. and adding all the other options industries have
21:30:30 <TrueBrain> or shall I do industry tiles first? Hmm
21:31:13 <frosch123> do you know zephyris sprite editor?
21:33:53 <frosch123> it lacks palette animation from ttdviewer
21:36:03 <TrueBrain> for industries ofc it doesn't work, but it is a good starting point
21:36:09 <TrueBrain> well, depending on the license
21:36:13 <TrueBrain> which is not mentioned in the repo
21:36:41 <TrueBrain> no mention of a license anywhere ....
21:36:45 <TrueBrain> guess I will not be looking at the source
21:38:52 <TrueBrain> but yeah, might do industry tiles first .. think with that I have all aspects of NewGRFs for industries
21:39:11 <TrueBrain> will be fun, as in the background I can just render all tiles via action2 .. the user doesn't need to know any of that crap :D
21:41:36 <frosch123> "Add: Current version, minus Google analytics script." <- haha, first commit message
21:41:56 <frosch123> so, yeah, may be a copy&paste of other unquoted sources
21:42:39 <andythenorth> Timberwolf apropros of nothing, have you done a Bedford MJ?
21:43:14 <andythenorth> or the Foden HMLC (DROPS)
21:43:23 <andythenorth> maybe a Stalwart :P
21:43:49 * andythenorth is tempted to HEQS revival, with vehicles that are completely useless outside of miltary logistics or recovery
21:44:58 <Timberwolf> I did a Bedford, but it was a TK iirc.
21:45:46 *** Samu has quit IRC (Ping timeout: 480 seconds)
21:46:36 <Timberwolf> The Stalwart HMLC has strong Thunderbirds energy.
21:47:05 <Timberwolf> I can see that trundling straight out of a Thunderbird 2 pod.
21:51:47 <Timberwolf> You could probably extend HEQS quite far into the future by using Thunderbirds vehicles.
21:52:03 <Timberwolf> The giant crab logger thing is probably quite HEQS.
21:52:32 <andythenorth> Thunderbirds actually looks conservative compared to RL LeTourneau stuff :)
21:54:50 *** sla_ro|master has quit IRC ()
22:01:36 <andythenorth> I have a few LeTourneau books, they're 'interesting'
22:11:25 *** Progman has quit IRC (Remote host closed the connection)
22:14:17 *** andythenorth has quit IRC (Quit: andythenorth)
22:15:01 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:47:02 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:09:53 *** gelignite has quit IRC (Quit: Stay safe!)
23:18:20 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:19:23 *** WormnestAndroid has joined #openttd
23:19:35 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
