IRC logs for #openttd on OFTC at 2025-02-11
⏴ go to previous day
01:06:28 *** keikoz has quit IRC (Ping timeout: 480 seconds)
03:27:11 *** Wormnest has quit IRC (Quit: Leaving)
03:51:19 *** Zathras has joined #openttd
03:54:34 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:54:44 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:43:13 <DorpsGek> - Update: Translations from eints (by translators)
06:08:48 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:34:30 *** barbagus has joined #openttd
06:35:54 <barbagus> Hi there, I'm trying to use the admin port (Windows, 14.1) but after setting a password in the secrets.cfg the port (3977) does not seem to open (netstat)... any idea ?
07:07:12 *** kuka_lie has joined #openttd
07:17:52 *** barbagus has quit IRC (Quit: Page closed)
09:44:16 <xarick> gonna upgrade to 14 or 15
10:08:56 *** nielsm has quit IRC (Ping timeout: 480 seconds)
10:15:17 <xarick> autoformating in visual code is dumb
10:15:27 <xarick> how do i ... customize it to my liking
10:15:57 <xarick> the language is squirrel
10:21:59 *** asymptotically2 has quit IRC (Write error: connection closed)
10:22:15 <_zephyris> Soo, what flavour of dumb am I being today?
10:22:15 <_zephyris> In file included from .../GitHub/openttd/src/debug.h:15,
10:22:15 <_zephyris> from .../GitHub/openttd/src/string.cpp:11:
10:22:15 <_zephyris> .../GitHub/openttd/src/core/format.hpp:33:13: error: redefinition of ‘struct fmt::v10::formatter<E, Char>’
10:22:15 <_zephyris> 33 | struct fmt::formatter<T, Char> : fmt::formatter<typename T::BaseType> {
10:22:16 <_zephyris> | ^~~~~~~~~~~~~~~~~~
10:22:16 <_zephyris> .../GitHub/openttd/src/core/format.hpp:17:13: note: previous definition of ‘struct fmt::v10::formatter<E, Char>’
10:22:18 <_zephyris> 17 | struct fmt::formatter<E, Char> : fmt::formatter<typename std::underlying_type_t<E>> {
10:22:18 <_zephyris> | ^~~~~~~~~~~~~~~~~~
10:22:20 <_zephyris> make[2]: *** [src/settingsgen/CMakeFiles/settingsgen.dir/build.make:146: src/settingsgen/CMakeFiles/settingsgen.dir/__/string.cpp.o] Error 1
10:22:20 <_zephyris> make[1]: *** [CMakeFiles/Makefile2:2202: src/settingsgen/CMakeFiles/settingsgen.dir/all] Error 2
10:22:22 <_zephyris> make: *** [Makefile:166: all] Error 2
10:31:34 <kuhnovic> You probably made a mistake in a call to fmt::format, and the compiler is going a tangent an freaking out
10:37:06 <kuhnovic> Just like the compiler spitting out several pages worth of perfect fowarding related templating nonsense because of a tiny mistake. Modern C++ is nice and all, but the error output can become complete gibberish then several layers of templating are involved.
10:38:34 <kuhnovic> And of course this is happening inside boost's unit test macro's, which makes it even worse. FML 😆
10:40:32 <_zephyris> Makes sense... but annoying.
10:41:02 <_zephyris> I was expecting to be chasing a syntax error from messing up a rebase conflict, this error really threw me off!
10:42:22 <_jgr_> _zephyris: You need to use a newer version of gcc, recent changes no longer work with gcc 11
10:44:25 *** enveeed has joined #openttd
10:44:25 <enveeed> Hey everyone, im looking to find the place in code where the decision is made to draw either the loading or loaded sprite set of a vehicle.
10:44:25 <enveeed> I thought I found it in `VehicleResolverObject::ResolveReal` in `newgrf_engine` but this seems to never be called for some reason
10:45:48 <peter1138> It's a virtual method, it's not called directly.
10:46:27 <enveeed> ah aight, im pretty new to cpp
10:46:48 <enveeed> is there any other place where this check is done?
10:47:41 <peter1138> There's two ways it happens, depends if you're looking at the default vehicles, or NewGRF addon vehicles.
10:47:59 <enveeed> looking for newgrf only for now
10:48:57 <peter1138> Okay, that method is the right place.
10:49:18 <enveeed> this doesnt seem to be the correct function, I changed it to always return the loading set regardless of any checks but in-game it still only shows up when in a station
10:51:10 <enveeed> if I got this right, this should only ever show the wagons with open doors, even when the train is in motion
10:51:27 <enveeed> but it just does not make any difference, seems to me like there is another place where the sprite is decided
10:52:41 <enveeed> should look like this
10:54:43 <peter1138> You should just force in_motion to false at the start, otherwise there could be an out-of-bounds read.
10:58:29 <enveeed> okay something is definitely wrong here, I just replaced the entire function with a null return for the sake of it and everything still works perfectly, seems to me that it just is not getting called in my case?
10:58:56 <enveeed> or something is wrong with my setup
10:59:11 <enveeed> inserting random print statements elsewhere works fine, I checked that
11:00:43 <peter1138> Well, add a breakpoint and see if it's triggered. (Add one somewhere you know a breakpoint will be reached first.)
11:02:23 <enveeed> yeah that was the first thing I tried and it didnt hit, blamed it on my setup and the fact that its a virtual function initially lol
11:02:35 <enveeed> hm lets see how close I can get to it
11:04:32 <_jgr_> NewGRFs aren't required to use real sprite groups to detect the loading state, you may want to try changing the value returned for vehicle variable 0x8A
11:08:52 <peter1138> Yeah, true, we 'optimised' the real stuff away if NewGRF only even returns one sprite.
11:10:01 <enveeed> ahh thank you, ill take a look at that
11:25:20 <peter1138> 8A isn't mentioned in NML, but I suppose someone could be manually accessing it.
11:30:52 <enveeed> yeah, I just checked the iron horse source and they do
11:31:39 <peter1138> ANDY WHAT HAVE YOU DONE
11:33:05 <peter1138> This is probably a case of not know that this is default behaviour of loaded/loading sprites, so finding some other way to do it.
11:33:47 <peter1138> Same with procedues_visible_cargo.pynml.
11:34:14 <peter1138> Reimplementing the amount of cargo loaded, which loaded/loading sprites have built in already.
11:35:13 <peter1138> Someone will tell me it's all better anyway and I should get over it.
11:35:17 <peter1138> And I will rage quit.
11:35:23 <peter1138> And we'll all be better off.
11:36:56 <peter1138> You used to be able to get a dongle that pretend to be a keyboard, to get around that.
11:37:07 <peter1138> These days you'd just use the dongle from a cheap wireless keyboard instead.
11:39:18 <xarick> asynchronows mode... hmm
11:40:45 <kuhnovic> Not in this case, because it's on a Dutch train 😛
11:43:33 <peter1138> If you constantly send out updates and never sleep, yes.
11:47:45 <peter1138> Great, it's working.
11:49:04 <xarick> i have some tables taking way too long to compute
11:49:26 <xarick> the infrastructure efficiency ones are bad 😦
11:54:25 <xarick> took 1 minute to prepare the data
11:54:25 <_glx_> Don't update GUI every tick it's silly
11:54:52 <xarick> table was stalled with old data
11:55:52 <_glx_> Once per economy month should be more than enough
11:57:10 <xarick> i might need to add that as a feature... decide how often tables are updated
11:57:19 <xarick> seems to be a common request from you
11:58:11 <andythenorth> peter1138: maybe I should restore loaded / loading and try to remember what the reason for not using it was
11:58:24 <andythenorth> it's been copied around between 5 versions of 3 different grfs
11:58:28 <peter1138> Layers probably involved somewhere.
11:58:41 <andythenorth> nah, it was something about wanting specifically 100% for some vehicle type
11:58:49 <andythenorth> but that might have been 10 years ago
11:58:54 <andythenorth> and not relevant
11:59:35 *** asymptotically2 has joined #openttd
12:00:18 <andythenorth> something like boats with one empty state, two loading states, and a hatch cover or something
12:00:29 <andythenorth> I'll try changing it when my big refactor is done
12:00:44 <ahyangyi> How big is a big refactor 😮
12:01:52 <peter1138> Different numbers of loading and loaded states has always been supported.
12:02:32 <andythenorth> doesn't nml require them both to be the same?
12:02:50 <peter1138> But don't refactor just because I'm moaning. Clearly the way you do it works too. Just causes confusion to the old people.
12:03:13 <andythenorth> you're not the first one to encounter this
12:04:31 <andythenorth> might need to verify in actual grf but
12:04:33 <andythenorth> `loading is used when the vehicle is loading within the station`
12:04:41 <andythenorth> `loaded is used when the vehicle is travelling`
12:04:56 <andythenorth> so to show doors or covers only at 100% would require ~100 spritesets
12:05:28 <andythenorth> if there is empty -> load sprite 1 -> load sprite 2 -> doors
12:05:52 <andythenorth> then empty shows until 25%, load sprite 1 until 50%, load sprite 2 until 75%, then the doors close
12:06:52 <andythenorth> [this is a guess]
12:08:01 <andythenorth> shows 'partial load' from 1% to 66%
12:08:08 <andythenorth> "made sense at the time"
12:08:17 <peter1138> 11:35 <@peter1138> Someone will tell me it's all better anyway and I should get over it.
12:09:03 *** Zathras is now known as debdog
12:09:06 <andythenorth> now I want to know what var loading / loaded uses again 😛
12:09:14 <andythenorth> and how it implements the boundaries
12:10:10 <andythenorth> I could just add spritesets to the spritegroup until I get the effect I want
12:10:32 <peter1138> No, it's intentionally "about here" type stuff.
12:11:35 <peter1138> `cargo_amount * number of sprites / max(1, cargo_capacity)` (division by zero, eh)
12:12:33 <andythenorth> do original sprites have part-load?
12:12:46 <peter1138> Although that will actually only show the last sprite if it's 100% loaded.
12:13:40 <peter1138> Default show cargo if it's at least half full.
12:14:25 <andythenorth> yeah so when I started drawing sprites there was a convention to add half-full sprites
12:14:38 <andythenorth> but with empty-full-loaded, they trigger at 33%
12:14:53 <ahyangyi> yes, 34% rounds to 50%
12:14:57 <andythenorth> in retrospect, empty / full would have done the job
12:16:47 <peter1138> Actually I was wrong.
12:17:32 <andythenorth> usually, we're all wrong
12:17:49 <andythenorth> or, we're all usually wrong
12:17:54 <peter1138> There's an off-by-one there :)
12:18:52 <peter1138> If you have 3 sprites, the transition points will indeed be at 33% and 66%.
12:19:17 <peter1138> 4 sprites will be 25%, 50% and 75%.
12:20:00 <peter1138> Anyway, carry on, whatever, it works anyway.
12:20:21 <andythenorth> it does, but I always feel it's wrong somehow
12:20:32 <andythenorth> like eating Frosties
12:20:59 <peter1138> A bit like choosing cargo type at the action 3 level. It was originally core to how different sets selected graphics, now you probably just have a massive switch instead.
12:29:25 <andythenorth> does nml even have a construct akin to action 3?
12:32:42 <andythenorth> `For vehicles and stations, a cargo type (identifier from the cargo table) may be used as callback name, to provide cargo-specific graphics.`
12:37:44 <andythenorth> wonder how much varact 2 time I'd save by implementing that
12:38:09 <andythenorth> currently a lot of time is spent on act2
12:44:24 <peter1138> The callback system gets in the way.
12:44:54 <peter1138> NFO allows you do have completely different callbacks on each of the graphics chains.
12:46:17 <peter1138> Not sure how NML handles it, I guess you it just tests for a callback and chains to the main callback switch.
12:52:54 <andythenorth> I won't read the nfo to find out 🙂
13:27:46 <xarick> but I have no idea what that entails
13:37:05 <kuhnovic> "I have no idea what it is but I want it"
13:37:21 <kuhnovic> The marketing department deserves a bonus
13:54:27 <xarick> the index .tobool() doesn't exist... then what does exist?
13:59:27 <xarick> integer to bool doesn't exist indeed 😦
14:02:23 <xarick> this.async_mode = GSAsyncMode(GSController.GetSetting("async_mode") != 0);
14:05:02 <xarick> what an annoying function
14:52:07 <_glx_> it's not a function, it's a scoped object
14:53:07 <_glx_> works the same as TestMode and CompanyMode
15:02:47 *** HerzogDeXtEr has joined #openttd
15:09:12 *** virtualrandomnumber has joined #openttd
15:09:39 *** virtualrandomnumber has quit IRC ()
15:12:59 <_glx_> hmm indeed `.get()` is not needed, but it actually might be better to set a comparator in the std:set itself
15:15:56 <peter1138> unordered_set might be better too.
15:47:36 <merni> except it's not maybe unused but certainly
16:06:10 <_glx_> no we can't mark, the only way is to discard CodeQL report
16:08:24 *** Wormnest has joined #openttd
17:01:18 <xarick> this doesn't work the way I'd like
17:01:52 <xarick> if the window is not open, it won't receive the update
17:02:34 <xarick> if you suddenly open the window, the update you got there is from the last time the window was open, if ever
17:28:12 *** NGC3982 has joined #openttd
17:29:21 *** urdh_ has quit IRC (Ping timeout: 480 seconds)
17:38:28 <Rubidium> _glx_: won't just removing those unused set/process_compile_flags be a much simpler solution, and that discussion isn't quite part of the fmt-internals PR, right?
17:48:43 <andythenorth> maybe it's time to alias `git comit` t o `git commit`
17:48:47 <andythenorth> GPT in the shell when?
17:50:20 <frosch123> And --amend and --ammend
17:50:45 <andythenorth> I might benefit from an 'are you sure' aliased script around `git reset --hard`
17:50:49 <_glx_> original intention of set/process_compile_flags was to allow use of set_source_files_properties in subdir cmakelists.txt, where the file is added to the list (mainly in blitter with different SSE flags), but if it's only for 1 file it's probably simpler to remove them
17:51:07 <andythenorth> it's one of my best friends, but if it's in shell history, reset --hard can be regrettable
17:51:24 <andythenorth> along with `newgame` in openttd console history 😛
18:15:03 <_glx_> oups we pressed at the same time
18:28:45 *** ChanServ sets mode: +v tokai
18:39:44 <xarick> there's something wrong with my tables in multiplayer
18:43:48 <xarick> in single player it works
18:44:03 <xarick> in multiplayer it puts the contents of 2 tables into 1
18:55:03 <xarick> this is 15.0-beta1 though
19:01:01 <_glx_> yes it's fixed in master
19:06:16 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:14:59 *** gelignite has joined #openttd
19:20:08 <truebrain> CI on Linux and Mac is faster 🙂
19:21:06 <peter1138> Game is now 500% slower, but... ;-)
19:37:03 <Rubidium> the real question is, how much faster is the slowest CI job?
19:54:13 <xarick> I think openttd is stuck
19:54:48 <truebrain> Windows? Still slow 😛
19:54:53 <truebrain> it had no effect on Windows 🙂
19:54:55 <xarick> Are you sure you want to create many random industries?
19:58:11 <xarick> it's already at 64000 industries
19:58:28 <xarick> it should like just not even attempt to run those tries
20:00:48 <xarick> having a hard time to get more towns in the map
20:02:45 <xarick> heh, there is no remove all towns button
20:04:55 <xarick> something's really wrong
20:06:17 <xarick> works fine in single player
20:11:06 <xarick> okay, I think I understand
20:11:31 <xarick> I can't use AsyncMode when creating a new table or a new element
20:11:53 <xarick> probably can't use it when removing as well, not sure
20:13:35 <peter1138> If you ever need the return value of something, you can't use async mode. Not sure if this can guarded against.
20:14:01 <xarick> I need the return value 🙂
20:14:11 <xarick> it's a TableID or whatever
20:15:15 <_glx_> there's no protection, we assume authors use async only when appropriate
20:15:52 <_glx_> would be hard to detect anyway
20:16:34 <_glx_> async mode is fire and forget, it's for commands you don't care about the return value
20:16:41 <xarick> single player works though
20:17:03 <_glx_> single player doesn't have the command loop
20:18:37 <peter1138> We could probably it not work in single player.
20:20:11 *** gelignite has quit IRC (Quit: Stay safe!)
20:21:51 <xarick> local async = GSAsyncMode(this.async_mode && !GSGame.IsMultiplayer());
20:22:30 <andythenorth> don't we run the CI on my MBP yet?
20:22:58 <peter1138> Just set up the initial elements first, then keep filling them in asyncmode.
20:23:23 <andythenorth> peter1138: "just don't do it" 🙂
20:23:27 <xarick> elements are "companies"
20:23:32 <andythenorth> can't guard against not being able to program 😛
20:23:38 <andythenorth> even I understand that
20:23:57 <xarick> if a company bankrupts or is created, elements are removed or created
20:24:28 <_glx_> but don't modify the structure in async, only updates
20:24:37 <andythenorth> async is webhooks 😛
20:24:45 <andythenorth> don't block waiting for them
20:24:50 <andythenorth> don't assume they worked
20:25:02 <andythenorth> if the result matters, inspect it later in a loop, but don't block for it
20:27:09 <_glx_> in multiplayer the commands are executed on next tick (and the result is passed to the script then), while in SP it's executed immediatly
20:27:29 <_jgr_> The primary rationale for async was so that scripts which update town growth, town text, etc aren't glacially slow
20:28:34 <_glx_> yeah updating 1 item per town per tick is super slow
20:28:46 <peter1138> _glx_, for parity we could emulate the command queue.
20:28:48 <xarick> I got it like this now:
20:29:40 <_glx_> you can keep async for the updates
20:29:59 <_glx_> but enable it before looping on elements
20:30:02 <xarick> buh muh singleplayer !
20:30:43 <peter1138> Hmm, lots of tiny async scopes.
20:31:00 <_glx_> yes they are mostly useless
20:33:04 <_glx_> you basically add a useless wrapper around the GSLeagueTable calls
20:33:36 <andythenorth> async for a single command? 😮
20:33:52 <andythenorth> two commands (mode change, command)
20:33:59 <andythenorth> where one would surely, by analysis, be faster?
20:34:04 <_glx_> double the opcode use of each call
20:35:16 <peter1138> There's calling the wrapper function then setting async mode, then calling the original function.
20:35:36 <andythenorth> xarick: "don't do this" 🙂
20:36:42 <peter1138> I actually sort of expected that leaving the AsyncMode scope would despatch and wait (if something was sent) but I guess it has uses not to.
20:37:25 <_glx_> it's destroyed when going out of scope
20:38:58 <_glx_> because you don't use it correctly, you're not supposed to store it in a variable
20:39:34 <_glx_> I mean in a long storage variable
20:41:27 <andythenorth> I don't actually understand the mode assignment
20:41:29 <andythenorth> `local asyncmode = GSAsyncMode(true);`
20:41:46 <andythenorth> then `asyncmode = null;`
20:42:05 <andythenorth> what's the implementation?
20:42:15 <andythenorth> does it create something like an environment var?
20:42:33 <andythenorth> how many mode vars can be assigned simultaneously?
20:42:48 <_glx_> local async = GSAsyncMode(true);
20:43:06 <andythenorth> that's because the scope is destroyed when exiting the braces?
20:43:09 <_glx_> only one mode is active at a given moment
20:43:57 <_glx_> the previous state is saved on GSAsyncMode() call, and restored when it's destroyed
20:44:27 <peter1138> Scoped is the best way, that's the intention as far as I'm concern.
20:44:30 <andythenorth> so is the var effectively a pointer to 'current mode'?
20:45:02 <_glx_> exactly like CompanyMode and TestMode
20:45:30 <peter1138> So all the "set everything up" commands which need the result should be done first. Then everything else can be done in one AsyncMode scope.
20:45:36 <_glx_> it's just an object setting the mode until its death
20:46:05 <andythenorth> ok so null causes the object to be destroyed
20:46:13 <andythenorth> so then we fall back to previously defined scope
20:46:27 <andythenorth> is there an array of scope vars somewhere?
20:46:39 * andythenorth roleplays actual programmer
20:47:10 <_glx_> (we don't look in the VM)
20:47:30 <andythenorth> it makes complete sense
20:48:37 <_glx_> at least squirrel doesn't defer deletion when going out of scope
20:48:53 <xarick> trying to get rid of wrappers
20:49:01 <xarick> let's see what happens
20:50:05 <andythenorth> any time GS has to touch GUI things, it becomes apparent why it's probably not THE future 🙂
20:50:35 <andythenorth> it's quite nice though
20:51:30 <andythenorth> maybe we should (1) let there be more than one GS (2) run them with their own opcodes counts (3) see what madness happens
20:51:37 <andythenorth> also (4) let them read badges on things
20:51:56 <andythenorth> "my GS got in a fight"
20:52:41 <xarick> it's like 15 players in 1 company
20:52:46 <andythenorth> offload them to another thread with unlimited read-only from the map, but make them defer anything that mutates map state to a write step
20:52:59 <andythenorth> so they have to do map:reduce type processing
20:53:09 <andythenorth> far more chaotic and interesting
20:53:32 <_glx_> hmm I wonder if we could check the return type of the function and error if it's in async
20:53:55 <andythenorth> is it too simplistic to simply drop the returns?
20:54:32 <_glx_> there's always a return, but it's 0 for most thing (same in test mode)
20:54:45 <andythenorth> when does the return matter? Is it if the author expectes an assignment?
20:55:00 <andythenorth> my async code all looks like
20:55:00 <andythenorth> local asyncmode = GSAsyncMode(true);
20:55:00 <andythenorth> foreach (page_element in this.page_elements) {
20:55:00 <andythenorth> GSStoryPage.RemoveElement(page_element.reference);
20:55:01 <andythenorth> asyncmode = null;
20:55:14 <andythenorth> unless foreach waits in a way I don't understand 😛
20:55:28 <_glx_> the return here is just a bool (command success/fail)
20:56:50 <xarick> why not asyncmode = GSAsyncMode(false); instead last line
20:57:11 <_glx_> because that would create another scope
20:57:27 <peter1138> Apparently scope/lifetime is difficult to understand.
20:57:32 <andythenorth> that's another assignment
20:57:36 <andythenorth> we need to null the object
20:58:02 <andythenorth> dunno I just see it visually, there's an array of scopes [somewhere in the VM]
20:58:11 <andythenorth> nulling it cause one to be deleted
20:58:20 <peter1138> local asyncmode = GSAsyncMode(true);
20:58:20 <peter1138> foreach (page_element in this.page_elements) {
20:58:20 <peter1138> GSStoryPage.RemoveElement(page_element.reference);
20:58:32 <_glx_> and the order of events could then be "enter new mode"->"destroy the old object"->"error because it's not the last"
21:00:18 <xarick> i fail to understand what's the point of setting it to false then
21:00:42 <_glx_> you don't have to set it to false unless temporary disabling
21:01:23 <xarick> I can only disable with null...
21:02:42 <_glx_> local a1 = GSAsyncMode(true);
21:02:42 <_glx_> local a2 = GSAsyncMode(false);
21:02:45 <_glx_> }``` is a valid workflow
21:03:58 <xarick> a2 disables the a1, what will a1 be after completing the a2 bracket
21:04:44 <_glx_> when a2 goes out of scope it returns to a1 state
21:06:16 <xarick> how would I know that's actually happen? there should be a function to tell
21:07:31 <_glx_> every GSAsyncMode() kinda push the new state on a stack, and it's poped on object destruction
21:08:24 <xarick> ah, with that perspective it's starting to make sense
21:08:44 <_glx_> "If you create an instance of this class, the mode will be switched to either Asynchronous or Non-Asynchronous mode. The original mode is stored and recovered from when ever the instance is destroyed. In Asynchronous mode all the commands you execute are queued for later execution. The system checks if it would be able to execute your requests, and returns what the cost would be. The actual cost
21:08:44 <_glx_> and whether the command succeeded when the command is eventually executed may differ from what was reported to the script. "
21:08:55 <_glx_> the documentation seems clear to me
21:09:54 <andythenorth> made sense to me
21:10:02 <andythenorth> and I am not a programmer 🙂
21:16:11 <xarick> it's just me, not obvious enough what Test
21:20:16 <Rubidium> guess you'll need some more C++ nomenclature... EnumBitSet's functions are named after the functions of std::bitset
21:28:14 *** k-man has quit IRC (Ping timeout: 480 seconds)
21:31:19 <xarick> that means the other i changed is also bad
21:32:52 <xarick> btw, on 13406, should I mention GSStation::GetOwner was removed in the changelogs?
21:33:19 <xarick> or just mention it was moved
21:33:26 <_glx_> it's still available is you moved it to BaseStation
21:33:40 <xarick> or not even add anything to the changelog
22:02:01 <xarick> i have a feeling async mode isn't active, if only there was a way to know for sure 😐
22:03:21 <yiffgirl> I updated visual studio and now cmake can't find a valid compiler at all. I am going to scream
22:05:17 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:10:20 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:11:42 <peter1138> Switch to the correct side.
22:14:16 <xarick> breakpoints not triggered at all
22:15:19 <xarick> are you sure I don't need to store this in a variable?
22:15:19 <xarick> `GSAsyncMode(this.async_mode && !GSGame.IsMultiplayer());`
22:15:52 <_zephyris> I've just been spiralling in an git eol / wsl compiler hell too...
22:16:00 <truebrain> yiffgirl: install WSL, use WSLg, and all your problems are in the past? 😄
22:16:19 <peter1138> You should not make async mode conditional on multiplayer at all.
22:18:13 <xarick> `local async = GSAsyncMode(this.async_mode);`
22:18:14 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:18:56 <peter1138> Every single example we gave earlier had a local...
22:19:11 <_zephyris> So, hours pass and I've got another (probably dumb) problem...
22:19:11 <_zephyris> /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
22:19:11 <_zephyris> collect2: error: ld returned 1 exit status
22:19:11 <_zephyris> make[2]: *** [src/settingsgen/CMakeFiles/settingsgen.dir/build.make:177: src/settingsgen/settingsgen] Error 1
22:19:11 <_zephyris> make[1]: *** [CMakeFiles/Makefile2:2208: src/settingsgen/CMakeFiles/settingsgen.dir/all] Error 2
22:19:12 <_zephyris> make: *** [Makefile:166: all] Error 2
22:19:23 <_zephyris> using gcc-12/g++-12
22:21:22 <_zephyris> [there's a lot more complaining before that, just the last few lines]
22:21:37 <_jgr_> _zephyris: What cmake command did you use?
22:21:59 <_zephyris> `cmake ..` in build dir, then `make`
22:22:27 <_jgr_> Yes, but what did you do to point cmake at gcc-12 instead of the system gcc
22:23:15 <_zephyris> Hmm, nothing I don't think
22:24:15 <_zephyris> oh, odd, yeah system gcc (ie. `gcc`) is 13.3.0
22:24:47 <_jgr_> 13.3 is fine, no need to use a different gcc then
22:25:10 <_zephyris> I've just done a release upgrade, probably had gcc-12 installed before that
22:25:41 <_jgr_> You might not to get rid of leftovers in your build dir then, usually deleting CMakeCache.txt is enough
22:35:14 <xarick> alright! now that async mode is out of the way, it's time to work on
22:36:41 <xarick> Every quarter is missing, could be useful
22:37:36 <xarick> every day is kinda pff
22:39:57 *** kuka_lie has quit IRC (Quit: Lost terminal)
22:40:55 <peter1138> Assuming it's economy time, every day is not very useful other than testing it's working.
22:42:20 <xarick> that one is every script frame
22:42:44 <andythenorth> why not 'every opcode'? 😄
22:43:22 <xarick> because i like to see the stats pronto
23:02:15 <peter1138> My gcc build goes from 496MB to 291MB. That's... so much larger than clang. Maybe it's a debug build.
23:04:06 *** Flygon has quit IRC (Read error: Connection reset by peer)
23:05:14 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:13:24 *** MarkZwei has quit IRC (Ping timeout: 480 seconds)
23:44:00 *** Wormnest has joined #openttd
continue to next day ⏵
