IRC logs for #openttd on OFTC at 2025-06-24
⏴ go to previous day
00:02:34 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
01:03:12 *** Flygon has quit IRC (Read error: Connection reset by peer)
01:07:31 *** tokai has quit IRC (Quit: c('~' )o)
01:39:14 *** Extrems has quit IRC (Ping timeout: 480 seconds)
01:47:24 *** Wormnest has quit IRC (Quit: Leaving)
01:55:27 *** Extrems has joined #openttd
02:18:48 *** Tirili has quit IRC (Quit: Leaving)
02:22:14 *** Extrems` has joined #openttd
02:25:54 *** Extrems has quit IRC (Ping timeout: 480 seconds)
02:25:54 *** Extrems` is now known as Extrems
02:27:21 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:43:17 <DorpsGek> - Update: Translations from eints (by translators)
04:54:04 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
06:32:37 <mnhebi> LordAro: where is this screenshot, this is bugging me cause I couldn't find it scrolling up.
06:49:59 *** ChanServ sets mode: +v tokai
06:56:35 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
07:27:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:59:07 <_zephyris> Nice, face rejig is good
08:00:11 <peter1138[d]> Turned out the PR wasn't smaller than the original code though.
08:00:30 <peter1138[d]> Some of that was due to adding doxygen 🙂
08:01:37 <peter1138[d]> The removal of hard coded UI elements, logic, etc, allowed the new 'feature' to end up about the same size.
08:52:19 <locosage> first time actually seeing this in the game %)
08:58:51 <locosage> hm, how is sawmill produced != delivered?
08:59:06 <locosage> is that because it only produces on industry tick?
09:14:59 <peter1138[d]> No, each industry has a minimal cargo amount that it needs before it starts processing.
09:17:25 <peter1138[d]> If that's not reached then it won't produce anything until the next delivery.
09:18:13 <peter1138[d]> Technically it's "waiting" cargo I suppose, but in that graph, "waiting" refers to stockpiled cargo.
09:19:23 <peter1138[d]> (Both AcceptedCargo and ProducedCargo have a `waiting` field.)
09:19:39 <locosage> hm.. but on large peaks there is sometimes large difference too
09:20:21 <peter1138[d]> Shouldn't be large differences.
09:21:50 <locosage> let me see if I can repeat that..
09:22:22 <locosage> btw, cmclient has a command to run for exactly n ticks, would be quite helpful in vanilla too for testing stuff like this
09:24:03 <locosage> hm, no large difference so far but this looks kinda wrong after loading an old save
09:24:26 <locosage> It's almost like all delivered wood got counted as produced goods at first
09:25:10 <locosage> well, actually might be for the same reason xD
09:25:11 <peter1138[d]> What industry takes those cargoes?
09:28:05 <peter1138[d]> Is that a new game or an existing game?
09:28:28 <locosage> I loaded 14.1 save from the last mh event
09:28:53 <locosage> and looked at one of big factories
09:29:33 <peter1138[d]> Okay. so the initial big peak of Goods is the stats from 14.1, which stores only produced and transported for the last two months.
09:30:01 <peter1138[d]> Then you have a partial month where new the stats are also logged.
09:30:09 <peter1138[d]> Then it catches up.
09:30:14 <locosage> ok, yeah, that would do it
09:31:04 <locosage> tbh maybe it shouldn't use those two months as that just makes it confusing
09:32:12 <peter1138[d]> For anyone who's been keeping a game going in master (or a 15.0 beta) for a while, then they'll have up to 24 months of that data. Not friendly to throw that away.
09:33:26 <peter1138[d]> Technically possible to store something for "data is present" but that isn't done.
09:35:05 <peter1138[d]> If anyone thinks the partial data collection due to loading old saves is a problem that should be handled, comment on the PR please 🙂
09:35:38 <locosage> anyway, there is still quite a significant difference even on a very busy industry
09:36:01 <locosage> peter1138[d]: yeah, tough choice
09:36:10 <pickpacket> peter1138[d]: what exactly is the data used for?
09:36:57 <pickpacket> as a graph or table?
09:37:08 <pickpacket> not that that matters, just curios
09:37:25 <peter1138[d]> Can you see screenshots? 😄
09:37:27 <locosage> peter1138[d]: well, it's mostly a problem for those who are going to explain it to every confused player
09:37:49 <pickpacket> peter1138[d]: sorry 😆
09:38:28 <locosage> excel export when? 🤭
09:42:40 <Rubidium> wasn't that introduced with NewGRF profiling? Okay, not necessarily xlsx, but rather csv.
09:46:37 <pickpacket> excel can read csv
09:47:28 <peter1138[d]> locosage: Yeah, also tick delay, I guess.
09:48:57 <peter1138[d]> vehicle -> accepted waiting -> minimal amount -> produced waiting -> next game loop tick -> produced
09:51:39 <peter1138[d]> It's done on *tile* loop.
09:51:54 <peter1138[d]> That's kinda funny.
09:52:29 <peter1138[d]> The size of the industry affects how often cargo is produced.
09:52:39 <peter1138[d]> It doesn't matter which tile.
09:53:06 <locosage> and max production depends on industry size too in vanilla
09:53:14 <peter1138[d]> That explains why it basically is always delayed, not just delayed by 1 tick if a vehicle happens to be unloading at the end of a day.
09:53:48 <peter1138[d]> This is a detail that FIRS deliberately uses, I assume 😉
09:54:34 <peter1138[d]> Anyway, that means that in the graph this is "some" amount that is unaccounted for, because it's been accepted but not produced y et.
09:55:06 <locosage> dunno about firs, it vanilla it only affects primaries iirc and firs hardly has any
09:55:17 <peter1138[d]> If we assume this is just the amount of time that it takes for the industry to transmogrify accepted into produced, this is fine.
09:56:45 <locosage> it's fine, it's just that vanilla production is usually perceived as instant
09:57:14 <locosage> and now it's visibly shows as not quite xD
09:59:23 <peter1138[d]> vehicle -> accepted waiting -> minimal amount -> produced waiting -> next game loop tick -> moved to nearby station and logged as production.
10:00:16 <peter1138[d]> Yeah, the production chart only counts it when it's (possibly) moved to a station.
10:00:21 <peter1138[d]> Also if there's a recession... well.
10:02:10 <peter1138[d]> If there's a recession then accepted and produced would align. Presumably the product is stolen.
10:03:15 <peter1138[d]> Recession mechanics eh?
10:03:33 <peter1138[d]> All cargo is accepted, you get paid for it, then the industry discards some of it and produces less.
10:08:28 <locosage> the main difficulty with implementation would be storing data for future period I guess
10:08:40 <locosage> but just rotate 1 month ahead
10:10:40 <locosage> well, 1 period I guess would be more correct to say
10:12:16 <peter1138[d]> That was about primary production, all I've been talking about so far is secondary conversion.
10:15:35 <peter1138[d]> Trying to have a fixed production per month just doesn't work when then production cycles are not based on months.
10:18:17 <locosage> there was some discussion a while a go where "reddit complained" xD
10:19:24 <peter1138[d]> Yes, but Reddit is unable to work out what version numbers are.
10:24:15 <locosage> got a patch idea - procedural production charts 🤣 😜
10:32:27 <locosage> 24 years would be a bit harder to fake though 😅
10:35:07 <locosage> actually... if each industry has own "random" it won't even need to be faked
10:35:31 <locosage> whole chart for unserved industry can be restored with no saved data whatsoever
11:08:17 <Rubidium> except for NewGRF industries, changed settings, moments of recessions, etc
11:09:44 <peter1138[d]> 1491888 Jun 24 12:05 'Novapolis, 2002-01-01master.sav'
11:09:44 <peter1138[d]> 1492076 Jun 24 12:08 'Novapolis, 2002-01-01master2.sav'
11:09:44 <peter1138[d]> 1491740 Jun 24 12:08 'Novapolis, 2002-01-01master3.sav'
11:09:44 <peter1138[d]> 1491924 Jun 24 12:07 'Novapolis, 2002-01-01extended.sav'
11:09:44 <peter1138[d]> 1491976 Jun 24 12:07 'Novapolis, 2002-01-01extended2.sav'
11:09:46 <peter1138[d]> 1491880 Jun 24 12:08 'Novapolis, 2002-01-01extended3.sav'
11:10:05 <peter1138[d]> So, uh... I don't know why these file sizes are different.
11:10:23 <peter1138[d]> Loaded and saved the same savegame 3 x 2 times.
11:10:47 <peter1138[d]> Some entropy hidden somewhere.
11:10:47 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
11:17:40 <peter1138[d]> I guess this isn't a good savegame to run because everything is stopped...
11:26:49 <peter1138[d]> Heh, well the savegame is smaller...
11:33:54 <locosage> did you measure SlSaveChunks, it was the most problematic when I did tests for the first version of graphs patch
11:34:10 <locosage> also, hellish games usually have quite a low amount of industries
11:34:40 <peter1138[d]> I did not "measure SlSaveChunks", whatever that means.
11:34:48 <peter1138[d]> I just loaded a fairly busy save and ran it for a bit.
11:34:56 <locosage> it's a non-threaded part of the save
11:34:56 <peter1138[d]> 2200+ industries seems like quite a lot to me.
11:35:01 <locosage> connection lag basically
11:35:30 <locosage> I run games with 5k-10k
11:36:02 <locosage> very high density gives 5k industries on 2k map iirc
11:36:55 <peter1138[d]> It's weird isn't it, how when you ask the computer to do more things it needs to... checks notes.... do more things.
11:37:24 <locosage> I didn't ask anyone to store 5k empty charts ;p
11:38:18 <locosage> I'm actually wondering if I can just wipe them with server patch
11:53:35 <peter1138[d]> Do we do the optimisation where if two players connect at the same time it only uses one network save?
11:56:31 <_glx_> Yes we have that thing IIRC
11:59:23 <_jgr_> The code suggests otherwise?
12:00:11 <locosage> peter1138[d]: Iirc no
12:00:24 <_jgr_> If two client connections overlap the same save is not re-used
12:00:26 <locosage> I was thinking of implementing it a few years ago
12:01:57 <peter1138[d]> _jgr_: That would be a more worthwhile change than something like trying to make up history to avoid saving it.
12:02:34 *** akimoto has joined #openttd
12:03:20 <_jgr_> Is two clients connecting at the same instance something that happens frequently enough to make it worth the effort?
12:07:12 <peter1138[d]> "more worthwhile than" doesn't mean it's worthwhile 🙂
12:11:33 <Rubidium> I doubt it's unlikely that two clients connect in the same tick. A second/third client connecting in a later tick might be likely during a restart. However, next to sending the same save, you also need to retain the commands since the save. Similarly, the save it dumped almost immediately into packets and once they're sent that memory is freed. Also, would you cascade this behaviour, i.e. client 1
12:11:39 <Rubidium> joins, before that done client 2 joins and starts downloading the first savegame, client 1 is finished, client 3 joins and also starts downloading... at some point there'll be a quite long time clients need to fast-forward through and if that's not fast enough they get kicked. So, for big savegame low CPU that might be worthwhile, but savegames that use a lot of CPU it might actually be detrimental to
12:11:45 <Rubidium> the joining experience.
12:12:05 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:12:08 *** WormnestAndroid has joined #openttd
12:12:27 <peter1138[d]> Ah, saved and dumped while in progress definitely makes that unworkable.
12:16:35 <locosage> usually mass reconnections happen for an external reason, like network lag, server restart, livestream announcements, etc.
12:17:07 <locosage> so while it would be a useful improvement it won't help much on a regular basis
12:17:32 <Rubidium> though there are some cases that might be improved upon. After all, multiple people could be in the lobby waiting and in theory all of these could be sent the map at the same time (possibly an option if network bandwidth is a problem). Similarly, you could in theory do a quick cheeky network-packet check just after the memory-dump stage of the saving has completed, so even people that join in the few
12:17:39 <Rubidium> hundred ms it takes for that (on big games) could use the same save... but that might not be as worthwhile as the other one.
12:17:56 <locosage> and keeping a command queue for a short while is ok, especially if catch up times are extended
12:23:27 <locosage> hm, do other connecting clients wait until the current one finishes download?
12:24:03 <locosage> I feel like I've seen it happend but then I don't remember why it would be a limit with how it works
12:24:50 <locosage> though pause on join definitely does that
12:25:17 <locosage> so that's an easy dos for someone on slow connection xD
12:32:42 <peter1138[d]> That reminds me, I was going to investigate 86Box again.
12:32:45 <Rubidium> you'll get kicked off for downloading too slowly at some point though
12:33:12 <peter1138[d]> .AppImage, urgh.
12:33:26 <locosage> yeah, but nothing stops you from trying again ;)
12:35:36 <Rubidium> ... except the operator banning by IP or using authorized keys to join
12:36:28 <locosage> it's simpler to disable pause on join though
12:36:58 <locosage> unless it starts causing desyncs
12:37:49 <locosage> did beta2 desyncs get fixed btw?
12:38:37 <peter1138[d]> I think one that was reported may have been fixed.
12:38:58 <peter1138[d]> Usual problem, nobody really reports them, and then nobody is really testing master to test the fix.
12:42:02 <Rubidium> pause on join is merely there to be able to join savegames like Wentbourne on a computer that can just run the game fine but not catch up a game week in a few seconds
12:44:11 <locosage> it''s hard to test as it often needs a decently sized mp game for desyncs to manifest reliably
12:45:35 <locosage> and after openttdcoop there is no community crazy enough to play on master xD
12:57:27 <peter1138[d]> /me attempts to guide his contractor-colleague on data design...
12:58:15 <peter1138[d]> Which is slightly problematic, as I don't have the end-fruits of his idea, only an intermediate PR, and the other PR we already merged was removing my initial attempt from a couple of years ago that never got used... 🙂
12:58:19 <pickpacket> did someone say a few days ago that it's possible to play on any sized map as long as each side is a power of 2? If that's the case, how do I do it? :D
12:58:40 <peter1138[d]> You pick a map size.
12:58:58 <pickpacket> yes, but there is a maximum and minimum in the menu
12:59:02 <peter1138[d]> Any size between 64 and 4096 probably the missing information?
12:59:27 <pickpacket> If I wanna play on a 32x32, or an 8k
13:00:03 <pickpacket> I didn't say it's smart!
13:00:25 <peter1138[d]> Trust me, it's not worth the effort of changing the few defines that need to be changed.
13:01:00 <pickpacket> of course not. I was more hoping that I could set the values in the config file or something
13:01:20 <peter1138[d]> No, they are hard limits set in map_type.h:37-38.
13:01:51 <peter1138[d]> IIRC there are couple of other places that need to be extended due to the extra choices.
13:02:03 <peter1138[d]> (TGP stuff, and sound zoom level stuff)
13:02:34 <peter1138[d]> If you want to try 8k+ maps, try JGRPP which allows it because 4k just isn't enough of a joker size.
13:11:20 *** kuhnovic has joined #openttd
13:11:20 <kuhnovic> IIRC JGR himself even regrets adding the ability to go for larger maps
13:12:46 <peter1138[d]> No, that's just me 🙂
13:13:14 <peter1138[d]> Okay, speaking on running nightlies, does anyone have a script to download the latest nightly and restart a server...?
13:13:22 <peter1138[d]> Or should I try doing it with Steam.
13:13:52 <peter1138[d]> Manually updating betas is okay, but manually updating nightlies is not going to happen 😄
13:18:55 <pickpacket> do a cron job with a bash script
13:18:59 <pickpacket> can't be that hard
13:19:59 <peter1138[d]> My bash-yaml-fu is not up to scratch.
14:34:25 <LordAro> hardly need bash-yaml-parsing
14:34:53 <_glx_> to determine if there's a new one and where it is stored
14:48:11 <peter1138[d]> talltyler: hmm, what prevents changing `minutes_per_calendar_year` in multiplayer games? I fear I may have asked this before...
14:49:04 <talltyler> Uh, it should be fine to change. Is it locked?
14:49:19 <peter1138[d]> > This command/variable is not available during network games.
14:49:50 <talltyler> Timekeeping mode can never be changed but I change minutes per year all the time in singleplayer, don’t know why I blocked it in network games (or if I even did it on purpose)
14:50:07 <talltyler> It’s been a while since I touched that 🙂
14:50:09 <peter1138[d]> Yeah, I figured it's probably not on purpose 🙂
14:54:48 <talltyler> Are you looking at the setting .ini for that lock? (The setting flag)
15:11:54 <peter1138[d]> /me ponders automatic unbunching orders.
15:16:03 <peter1138[d]> Purchase vehicle,
15:16:09 <peter1138[d]> Unbunch order already in place 🙂
15:16:37 <peter1138[d]> I think it would interfere too much with sharing orders, and doing routes that don't need unbunching.
15:22:35 <kuhnovic> _jgr_: Must have dreamt it I guess 😛
15:23:55 <kuhnovic> I would like automatic unbunching. Just not for trains 😆
15:36:19 *** Wormnest has joined #openttd
15:42:51 *** gelignite has joined #openttd
15:47:53 * andythenorth considers a black hole unbunching tile
15:48:13 <merni> we could even have a nice roof for the trains while they are in it
15:48:33 <andythenorth> in the spirit of 'but why do trains turn around in stations, OMG this breaks all reality"
15:48:44 <andythenorth> it would be good to have more magic tiles that do gamelike things
15:49:16 <andythenorth> how about a tile that transforms the train consist against rules?
15:49:24 <andythenorth> or a tile that abstracts 50% of the cargo?
15:50:05 <andythenorth> or a tile that only releases a vehicle when it receives a signal from somewhere else
16:09:46 <squirejames> andythenorth: I can't be entirely sure but, in my current game I am *sure* I have had trains enter one depot, but appear in others. I have locos that should be physically unable to get from where they were, to the depot they are in now
16:10:00 <squirejames> Drive through depots might be responstible
17:45:11 *** gelignite has joined #openttd
18:17:04 <michi_cc> Shall we anger some folks?
18:17:39 <peter1138[d]> For the sake of it...
18:18:27 <peter1138[d]> Hmm, not quite right.
18:18:48 <peter1138[d]> Fabricating monthly data when you only have quarterly data is a bit of a faff 🙂
19:33:35 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
19:48:11 *** dh1 has quit IRC (Ping timeout: 480 seconds)
19:54:34 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
19:54:36 *** WormnestAndroid has joined #openttd
21:00:55 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:25:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:46:47 *** tokai|noir has joined #openttd
21:46:47 *** ChanServ sets mode: +v tokai|noir
21:53:55 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:14:23 <peter1138[d]> Bah, there are too many ways to handling placing things on the map.
22:49:47 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:51:23 *** WormnestAndroid has joined #openttd
22:55:13 *** reldred has joined #openttd
23:41:07 <reldred> andy what have you done
23:41:19 <reldred> that said, white vs red hilighting even on that is super handy
23:58:47 <peter1138[d]> Well, the area is not what will be used, because industries have different layouts.
continue to next day ⏵
