IRC logs for #openttd on OFTC at 2023-11-04
⏴ go to previous day
00:08:43 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:24:47 *** Smedles has joined #openttd
00:35:01 *** luk3Z[m] has joined #openttd
00:47:01 *** EmeraldSnorlax[m] has joined #openttd
01:11:27 *** yubvin[m] has joined #openttd
01:56:41 *** Wormnest has quit IRC (Quit: Leaving)
01:56:58 *** thelonelyellipsis[m] has joined #openttd
02:58:19 *** cjmonagle[m] has joined #openttd
03:00:20 *** audunm[m] has joined #openttd
03:41:54 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:59:25 *** calbasi[m]1 has joined #openttd
05:34:05 <merni> talltyler: For me, this preview build just keeps crashing before the main menu and there is a message on the console about missing
05:34:40 <merni> is there a windows build to try?
05:47:06 <merni> Also, I'm curious and trying to understand the reasons behind some features of this (without having played with it):
05:47:06 <merni> - Where "years" are used, do players see "period" now in real-time mode?
05:47:06 <merni> - Will timetables without real-time mode still work in days? If so, why? The change to second-based timetables would be a lot more intuitive to players in general even if they don't want the other stuff with real-time mode, right?
05:47:06 <merni> - Further to the above, why was "real-time mode" implemented as a separate and irreversible setting? Would it not be better to have all games in "real-time mode" by default, but equating calendar time to economic time whenever the speed of calendar time is set to 1?
05:54:26 <goddess_ishtar> I think the reason to avoid real-time mode by default was to avoid breaking expected behaviour
05:55:03 <goddess_ishtar> with the understanding that any player who enables it accepts that some grfs may not play nice
06:32:32 <jfs> If you are on day 31 of november and enable real-time mode, what should happen? If you are on 1m59s ("day 30" of "month 2") and disable real-time mode, what should happen? If you are on day 363 of a year and enable real-time mode, what should happen?
06:35:05 <jfs> I don't think there's good ways of handling any of those cases that won't break something in subtle ways. It's better to just make it a permanent setting, like the landscape type (temperate/arctic/tropical) is
06:35:13 <goddess_ishtar> yeah, the toggle being irreversible per save is *also* important because a lot of things implicitly rely on the calendar being consistent
06:37:23 <goddess_ishtar> you'd either have to skip some days or have some days twice to sync them back up again, and that would cause havoc on anything needing to know how far in the past or future something is
06:37:40 <goddess_ishtar> it's an irl problem with leap seconds
06:38:49 <goddess_ishtar> so in this case the economic calendar is like Unix time - it exists only for regularity for the system's sake and isn't for the user
06:44:36 <goddess_ishtar> the 360-day cycle of the economic calendar will always eventually drift away from the display calendar
06:45:32 <goddess_ishtar> I *am* curious how 2TT is planning on displaying timetables with real-time mode off though
07:15:06 <Rubidium> maybe just make the display calendar progress at 73 instead of 74 ticks per day, and fudge the remaining few ticks on the last day of the year
07:16:01 <Rubidium> then it won't drift much more than a day
07:39:16 *** HerzogDeXtEr has joined #openttd
08:05:38 <LordAro> Rubidium: ah, the google method :p
08:10:59 <goddess_ishtar> yeah I was gonna mention that
08:54:07 <truebrain> merni: at least it is not you; I run into the same issue. Which makes me wonder when/why this broke 😛
08:54:18 <truebrain> (no-sound should be distributed with the game, so there should always be a sound set)
08:58:43 <truebrain> it is also packed in `openttd.data` .. odd
09:04:43 <peter1138> Morning. It's raining again.
09:12:12 <goddess_ishtar> I wish it were raining
09:12:27 <goddess_ishtar> then it couldn't be snowing
09:16:39 <peter1138> Hmm, replacing lots of `new` with `std::make_unique` is kinda... ugly.
09:18:57 <truebrain> let's see what commit broke emscripten .... this will be a lot of compiling
09:19:03 <truebrain> luckily, they don't take that long anymore
09:19:52 <peter1138> Is that the reason you upgraded? :D
09:20:07 <truebrain> specially to bisect this bug
09:20:40 <truebrain> git tells me it needs 7 steps
09:23:33 <truebrain> broken since september 😛
09:25:08 <truebrain> euh, no, since october .. the september version was good .. git bisect confuses me sometimes
09:26:31 <truebrain> 2 steps left ... pam pam pam ....
09:26:46 <truebrain> I wish bisect showed a bit better between what range the problem is, so I could already peek the changelog
09:27:32 <truebrain> one commit is jumping out now ...
09:27:36 <truebrain> something about a search path list ...
09:27:53 <truebrain> and the winner is .... cda6f24fe8e2baf858dbaaf65ab2bde84ddf02d7 !
09:29:47 <peter1138> I knew it, it was me :p
09:31:13 <peter1138> fileio.cpp:972 might be it
09:32:18 <peter1138> If one of the other search paths matches the path that SP_WORKING_DIR points to that path is then ignored. Oops.
09:33:35 *** andythenorth has joined #openttd
09:34:05 <andythenorth> Why can’t discord mobile delete preview embeds? 😛
09:34:14 <peter1138> I'm not sure what the file layout looks like for empscripten.
09:35:42 <truebrain> peter1138: yeah, me neither, as in, I can see it now, but let's see why this is an actual issue ..
09:36:56 <truebrain> I guess the code goes wrong if a searchpath is changed after `FillValidSearchPaths` is called
09:37:42 <truebrain> okay, `SP_BINARY_DIR` is the issue
09:38:19 <peter1138> SP_BINARY_DIR == SP_WORKING_DIR?
09:39:07 <truebrain> but it suggests `SP_BINARY_DIR` is changed after `FillValidSearchPaths`
09:39:36 <truebrain> so why does it matter 😛
09:39:49 <peter1138> No, if SP_BINARY_DIR is the same as SP_WORKING_DIR then _valid_searchpaths no longer includes SP_BINARY_DIR
09:40:01 <peter1138> And then the later check for !SP_WORKING_DIR trips up.
09:40:27 <truebrain> so SP_WORKING_DIR is special? 😛
09:40:42 <peter1138> Yes, fileio.cpp:972 and :1205 make it so.
09:40:52 <truebrain> yeah, those line numbers are not mathcing to anything useful in my code 😛
09:41:07 <truebrain> not sure what version you are on 🙂
09:41:14 <peter1138> for (Searchpath sp : _valid_searchpaths) {
09:41:14 <peter1138> if (sp == SP_WORKING_DIR && !_do_scan_working_directory) continue;
09:41:14 <peter1138> Debug(misc, 3, "{} added as search path", _searchpaths[sp]);
09:41:23 <truebrain> that is in `DeterminePaths`
09:41:29 <truebrain> so that is before `FillValidSearchPaths`
09:41:44 <truebrain> the one in `::Scan` however
09:41:46 <peter1138> It calls FillValidSearchPaths itself.
09:42:38 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
09:43:50 <peter1138> Have two _valid_searchpaths, one always excludes SP_WORKING_DIR.
09:44:39 <peter1138> (I'm looking at master, btw)
09:45:59 <truebrain> I might be off a few revisions there; dunno 😛 But we found each other, so it is fine 🙂
09:46:34 <truebrain> I was thinking something silly like this
09:47:29 <truebrain> I will learn to proper program one day; today is not that day
09:47:43 <peter1138> Depends if the order matters.
09:47:53 <truebrain> anyway, my logic here is simple: `_do_scan_working_directory` is pointless if the working-dir isn't unique
09:48:05 <truebrain> as it is the only SP we sometimes ignore
09:48:09 <peter1138> If the order matters, it should be inserted near the beginning.
09:48:31 <truebrain> valid point .. I can't tell if that matters, but it is a valid point
09:48:36 <truebrain> so we need to insert it at the start 🙂
09:48:55 <peter1138> If the order doesn't matter, then just move SP_WORKING_DIR to the end of the enum :)
09:49:19 <truebrain> do you dare to make that call? 😄
09:49:52 <truebrain> so your solution might be more robust 😛
09:51:40 <truebrain> we have explicit code to exclude the working-dir if it is `/`
09:51:45 <truebrain> which is what triggers the emscripten issue
09:53:09 <truebrain> our filesystem code is so so weird
09:54:07 <truebrain> `_do_scan_working_directory` is purposely build to prevent unneeded `ScanPath` .. and that is the only issue here 🙂
09:54:37 <truebrain> so yeah, my PR solves the issue .. but the actual problem is much larger 😛 😛 (read: weird codebase)
09:55:00 <peter1138> It avoids scanning it because it could be ~ with lots of files.
09:55:13 <truebrain> just in this case BINARY_DIR is also set to `/` 😄
09:55:40 <truebrain> one could argue the intention of `_do_scan_working_directory` is to prevent scanning `/`, but okay ..
09:56:15 <truebrain> who in their right mind makes BINARY_DIR equal to `/` anyway 😛
09:59:57 <truebrain> so another solution might be that for emscripten we don't install in `/`, but in some subfolder
10:00:00 <truebrain> not sure if that can be done
10:05:47 <truebrain> nope, it always mounts on `/`
10:09:44 <truebrain> it is a bit silly .. they have a variable to write what the executable binary (and folder) are
10:09:53 <truebrain> but they write it just after the place you can add custom code to emscripten
10:09:56 <truebrain> so you can't actually change the value
10:10:13 <peter1138> Why do we want to scan working dir anyway?
10:10:54 *** simo333 has joined #openttd
10:10:54 <simo333> Probably should have asked here.
10:10:54 <simo333> Is it possible to make smoke effects not being a "global thing" but have it's own graphics for each vehicle?
10:10:54 <simo333> What I mean is that tiny railbus shouldn't have same effects as a 4000 HP diesel under load.
10:10:55 <truebrain> peter1138: I think we will not find answers to many of those questions 😛
10:10:56 <peter1138> Hm, dedicated servers perhaps.
10:12:02 <truebrain> okay, so I think your commit and my commit combined does not disturb any existing deployment 😛
10:13:12 <truebrain> I still think it is fucked up, but .... I touched this code enough to not touch it 😛
10:19:43 *** pemensik|home has quit IRC (Remote host closed the connection)
10:19:55 *** pemensik|home has joined #openttd
10:31:57 <peter1138> Casting of unique_ptrs is so fun.
10:32:39 <truebrain> I am happy you enjoy it
10:33:19 <peter1138> Liberal use of .get(), it works but feels wrong :)
10:39:24 <Rubidium> maybe you can use std::get instead? :D
11:01:51 <truebrain> I love comments without context 😄
11:02:16 <truebrain> it might just be GitHub messing with me btw
11:11:45 <truebrain> ah! Wwow, that is not clear in the GitHub interface at all
11:11:59 <truebrain> I was already doubting, as it is not for glx to say something untrue 😛
11:13:28 <truebrain> absolutely no idea what that comment on line 94 is trying to say 😛 I am so scared of touching this code 😄
11:13:51 <peter1138[d]> That was my thought too, which is why I didn't comment on it originally...
11:14:51 <peter1138[d]> Working dir can be overridden, but I'm not sure of the relevance.
11:35:41 <andythenorth> simo333: Can change the generation model per vehicle to one of the other builtins
11:36:11 <andythenorth> In principle the spec left open the possibility of custom generation models
11:48:47 <simo333> andythenorth: There are 3 smoke effects (steam, diesel and spark) and 3 emission types (like steam loco, diesel loco and electric).
11:48:47 <simo333> If yes, it is not what I mean.
11:50:56 <simo333> Currently it's possible to change smoke effects only with "replace sprite".
11:50:56 <simo333> You cannot have huge trail of diesel smoke above heavy diesel or small puffs behind gasoline motor railbusses.
11:51:42 <Eddi|zuHause> what do you want to vary? frequency of smoke emission? smoke development pattern over time after emission? colour?
11:58:52 *** virtualrandomnumber has joined #openttd
11:58:59 *** virtualrandomnumber has quit IRC ()
12:00:23 <andythenorth> The spec AIUI was constructed by frosch to allow in theory grf-defined effect vehicles and separately grf-defined generation model.
12:00:48 <andythenorth> There’s no action for effect vehicles currently
12:01:25 <andythenorth> The generation model might be possible in a callback, but that might be a performance issue, we never seem quite sure 🙂
12:02:21 <peter1138> Someone posted in the TTDPatch forum... and they're using TTDPatch...
12:10:07 <_zephyris> Would custom effect vehicles also have utility for industries?
12:34:31 <_zephyris> peter1138: Ddelete the archive!
12:37:03 <merni> Or at least a big notice at the top saying something like "This is the Archive section, the contents may be highly outdated and inaccurate"
12:38:11 <_zephyris> It's a wiki... there's a change history if anyone really wants to do some archaeology... delete it!
12:38:57 <peter1138> In think the problem is calling it "Archive" means nobody wants to touch it.
12:41:10 <merni> _zephyris: In this case though it was actually useful to the person using ttdpatch :p
12:41:31 <peter1138> Not really because it doesn't apply to TTDPatch.
12:42:23 <merni> > Note that this differs from TTDPatch Multihead handling in several ways: You no longer have to create the engine as a train car by holding ctrl. Instead you simply drag the second engine onto the train it is to join. Also, second engines can only ever reduce a combined train's maximum speed, never increase it.
12:42:23 <merni> This bit does though indirectly
13:31:20 <Eddi|zuHause> my first computer had 25MHz
13:35:21 <talltyler> merni: Outside real-time mode, nothing changes. Timetables still work in days. I guess I can change "timetables in seconds" to a feature that can be used in any mode, but required in Real-Time Mode. Mostly because splitting this off the Real-Time Mode PR would make both easier to review.
13:35:21 <talltyler> Real-Time Mode needs to be permanent for the reasons explained by jfs. Trying to fudge numbers to fit, or adjust dates when changing modes, sounds like an absolute nightmare which would complicate the code and introduce many possibilities for bugs. I tried for a long time to allow it to be changed and decided it's not worth it.
13:36:02 <peter1138> A 6502 at 2MHz, and that was fast :)
13:37:40 <andythenorth> peter1138: 8Mhz ARM 2
13:38:18 <peter1138> Probably not much point making that neater.
13:44:40 <peter1138> Neat. Because my cargo mapping patch is still a PR (or just a local branch...) disabling all cargo types leaves other things lying around.
13:55:21 <peter1138> I made it neater -- the zero-size matrix was the CTD cause.
13:58:27 <peter1138> Nice, that means I don't need to apply a random fix in my unit-test code which otherwise wasn't needed.
14:31:07 *** Wormnest has joined #openttd
14:39:49 <peter1138> Hmm, this window width is weird.
14:50:43 <peter1138> Hmm, not sure about the layout, maybe the resize button should be next to the hscrollbar rather than below the vscrollbar.
14:51:39 <peter1138> For station cargo filter...
14:52:19 <peter1138> Perhaps a "dropdown list" with toggle boxes. And the full cargo name.
14:52:34 <peter1138> Not toggle boxes... the tick. Like on the settings menu.
14:56:15 <peter1138> Let's check with HSCROLL elsewhere...
15:06:47 <talltyler> Oof, hidden circular dependencies will be the death of me
15:07:16 <talltyler> More silliness with header files needing to access `_settings_game`...
15:08:56 <talltyler> Actually, this one can't be conditional on a client setting or we will desync 😬
15:09:24 <peter1138> Header files should not be access settings, I think.
15:10:08 <talltyler> It does seem to make a right mess of things
15:18:24 <peter1138> ResuableBuffer itself could be update to use std::vector, if the penalty of clearing on resize is not a problem.
15:40:11 <merni> talltyler: Makes sense, thanks for the clarification
15:52:37 <peter1138> lol failed my own unit-test :D
15:53:15 <talltyler> That's what it's for, I guess 😄
15:53:16 <peter1138> I blame the clangd extension, it adds extra text to the editor view and I didn't see the widget parts were not laid out properly.
16:21:47 <peter1138[d]> So this thing... I don't immediately hate it.
16:22:38 <peter1138> What is it even showing... is it depending on cargo dist?
16:28:41 <peter1138> No, just cargo flow. And because it's a fresh start I have no cargo flow :)
16:35:40 <talltyler> I wonder if you'd want to only show cargos that have a flow
16:38:06 <peter1138> Also should the height change depending on the selected tab? The "Show vehicles on map" mode only has 6 items in the legend...
16:38:56 <talltyler> Ordinarily I'd say probably not, but this window can be so tall it might make sense to resize it
16:40:21 <merni> The window size jumping around when you click the options might not be very nice
16:46:01 <peter1138> Could be fixed height with a horizontal scrollbar.
17:39:50 <alfagamma7> I should play some Openttd tomorrow
17:45:55 <merni> peter1138: Is a scroll-bar for a map legend really necessary? If you choose to use an industry set with a crazy number of industries, maybe you should live with the smallmap window being somewhat bigger than usual :p
17:46:30 <peter1138> Nope. I'm just trying things out.
17:49:31 <merni> Also, what's "Show height"? is that a new thing for the land contours?
17:51:23 <merni> Well it must be at least more recent than 13.4 :p
17:51:54 <peter1138> Nope, it's in 13.4.
17:52:08 <merni> it only appears when the cargo flow is selected
17:52:21 <peter1138> Not just cargo flow.
17:52:49 <merni> showing height could be equally useful when using "show transport routes", why is it not enabled there?
17:53:40 <merni> is it just "nobody thought of doing it" or are there technical reasons
17:56:58 <LordAro> truebrain: have you read the cloudflare post mortem?
17:57:46 <LordAro> "the overnight shift consisted of security and an unaccompanied technician who had only been on the job for a week."
18:01:22 <alfagamma7> Something went down ?
18:02:38 <LordAro> not that most would notice
18:09:44 <talltyler> Right, that should make Real-Time Mode quite a bit simpler to review by splitting it up
18:10:19 <talltyler> I still need help refreshing the timetable panel every second though...I don't think it's the timer, but something related to invalidating data 🙂
18:16:00 *** gelignite has joined #openttd
18:23:10 <peter1138> My Britishness fails when I want to write centring...
18:34:39 <LordAro> peter1138: at least we get centred
18:35:05 <peter1138> One day I'll fix SA_CENTER...
18:35:15 <peter1138> I must have been having a moment when I made that.
18:35:34 <peter1138> (And it's not even used only for strings any more)
18:37:43 <DorpsGek> - Update: Translations from eints (by translators)
18:41:16 <andythenorth> peter1138: 20 years of css makes me think “color” would also be easier
18:41:26 <truebrain> LordAro: Yeah, a bit too much blaming the DC owners for my taste ... they should have tested full brown out of that DC earlier. Blaming it on the incompetence of someone else is kinda lame tbh
18:49:59 <peter1138> Playing Doom at 320x200 is probably not necessary...
19:14:29 <LordAro> truebrain: it is a bit "we haven't got answers yet so we're just going to speculate"
19:15:09 <LordAro> it's not that they don't blame themselves, but when 50% of the article is on the DC...
19:24:16 *** brickblock19280 has joined #openttd
19:24:16 <brickblock19280> Seems I missed that feild
19:24:39 <peter1138> Did you also miss the JGRPP repository?
19:26:28 <brickblock19280> No but it is the version I used it still happens in vanilla master tho
19:29:16 <peter1138> KST SNDTS (ScaNDinavian Train Set)
19:31:35 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:31:46 <peter1138> Well, I'm not going to start diagnosing binary NewGRFs.
19:33:49 <brickblock19280> the grf isn't doing anything with flipping and I am not the only one who has experienced it
19:33:57 <Eddi|zuHause> i don't see how those would be OpenTTD bugs
19:34:13 <peter1138> My version of grfcodec doesn't know what to make of that NewGRF file.
19:34:48 <peter1138> It's 600KB+ but I only get two 0 byte png files and a 3KB nfo file.
19:34:56 <peter1138> Unexpected id for sprite 75; expected 2 got 34
19:34:57 <brickblock19280> that is probably due to it not having any 8bpp gfx
19:35:24 <brickblock19280> locosage: wrote the compiler so you best ask him
19:35:55 <peter1138> I think that "you" there is actually you.
19:36:28 <brickblock19280> but it is simply following the spec and not providing any power for the trailing parts which means it gets the wrong 2CC
19:37:52 <Eddi|zuHause> maybe you should provide a minimal test grf
19:38:30 <brickblock19280> I did strip if from all other engines but I guess I could
19:39:48 <peter1138> Ah maybe the Debian version of grfcodec is so old it doesn't understand 32bpp at all...
19:40:28 <brickblock19280> might be I had some problem when I tried decompiling dutch stations addition set on ubuntu
19:40:42 <peter1138> GRFCodec 6.0.6 r991 - Copyright (C) 2000-2005 by Josef Drexler
19:40:57 <peter1138> 6.0.6 seems to be latest, r991 and 2005 is just weird.
19:42:21 <peter1138> Hmm, libboost needed.
19:42:49 <peter1138> Yay, building current version instead of ancient release.
19:44:42 <peter1138> (Why did the palette numbers of -p change?)
19:51:05 <peter1138> Someone sorted the list alphabetically by filename.
20:13:46 <simo333> Eddi|zuHause: Maybe picture will help me tell what I want.
20:13:46 <simo333> Here we have tiny shunter, 2-section diesel and large single one.
20:13:46 <simo333> All have same diesel effects. But I'd like to have ability to add different graphics of fumes for all of them.
20:14:40 <simo333> Smoke comming from Ko II is larger than a loco itseld
20:18:03 <jfs> "vehicle smoke effect" might be a reasonable feature that doesn't have to be too generic but can still offer lots of customization
20:19:24 <simo333> It is, and funny enough it have only 5-6 sprites for all vehicles in game.
20:19:46 <simo333> So moding it is easy, you just can't make different ones and assign them
20:23:33 <jfs> "effect spriteset", "effect frequency", and "effect frequency randomness" (+/- offset) for four situations of "idle", "running", "heavy load", and "breaking"
20:23:33 <jfs> maybe also parameters for the rise distance and rise speed of the effects
20:23:33 <jfs> then on a vehicle you can reference a specific smoke effect and give a smoke origin on the vehicle sprite
20:24:16 <peter1138> Are you defining a set of action 0 properties, or just vaguely throwing a wishlist out there? :p
20:34:44 *** Wormnest has joined #openttd
20:41:12 <_zephyris> You'd need an animation speed/frame time too.... But not a bad action0 proposition
20:44:43 <peter1138> That basically means you've implemented it now.
20:50:34 *** gelignite has quit IRC (Quit: Stay safe!)
21:10:21 <jfs> peter1138: that was mostly a sketch of an idea, closer to a wishlist since I haven't really looked at how the effects are handled right now and what would be reasonable to do
21:16:45 <goddess_ishtar> andythenorth: late but you can surround links in angle brackets to not have them embed
21:17:25 <jfs> aka. less-than greater-than signs
21:27:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:48:35 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:58:52 *** frosch123 has quit IRC (Quit: User went offline on Discord a while ago)
22:01:39 *** ChanServ sets mode: +v tokai
22:08:36 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:21:36 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:23:43 *** pemensik|home has quit IRC (Ping timeout: 480 seconds)
22:25:44 <LordAro> oh, didn't wait for the CI results :)
22:27:28 *** esselfe has quit IRC (Read error: No route to host)
22:29:42 *** esselfe has joined #openttd
22:35:52 <LordAro> seems reasonable to me, at a glance
22:37:07 <_glx_> msvc fails to compile the test
22:37:16 *** Smedles has quit IRC (Read error: No route to host)
22:37:30 *** Smedles has joined #openttd
22:37:44 <peter1138> Ah, I thought that might be an issue.
continue to next day ⏵
