IRC logs for #openttd on OFTC at 2024-03-15
⏴ go to previous day
01:47:51 *** ChanServ sets mode: +v tokai
01:54:50 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
01:58:47 *** Leopold has quit IRC (Ping timeout: 480 seconds)
02:00:10 *** Wormnest has quit IRC (Quit: Leaving)
02:06:11 *** Leopold_ has joined #openttd
02:36:57 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:06:39 *** gnu_jj_ has joined #openttd
03:10:11 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:28:17 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
03:32:35 *** Leopold has joined #openttd
03:36:40 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:41:50 <DorpsGek> - Update: Translations from eints (by translators)
05:00:42 *** tramrider has joined #openttd
05:03:10 *** marchnex has joined #openttd
05:06:17 <tramrider> Is there anybody familiar with how x_pos and y_pos work on road vehicles relative to the tile? I am trying to check whether the vehicle is in the first half of a tile or back half of tile. And I'm doing that by 'snapping' the x (or y, depending upon the direction) of the vehicle to the nearest half tile then checking if that's divisible by the tile size. However I'm having some trouble with the x_pos and y_pos.
05:06:48 <tramrider> Should the coordinates refer to a corner of the vehicle, or the center of the vehicle? And are they the same x/y regardless of the direction of the vehicle?
05:07:37 <tramrider> I've searched for an existing helper function for this but I've not been able to find one.
05:18:26 *** Leopold__ has joined #openttd
05:20:37 *** Leopold has quit IRC (Ping timeout: 480 seconds)
05:32:53 <Rubidium> As far as I am aware it is the center of the bounding box of a part (so an articulated vehicle has multiple bounding boxes). X/Y are always in the same directions, and there are 16 positions per tile.
05:34:16 <Rubidium> the direction of x_pos/y_pos are the same as the x/y of tiles; specifically if you divide x_pos and y_pos by 16, the quotients are the tile x/y and the remainders are the location within the tile
05:37:25 <tramrider> Thanks, maybe I am over-complicating this by snapping the vehicle to the nearest half tile first. I might be able to get away with just looking at the remainders.
05:39:25 *** locosage has joined #openttd
05:39:25 <locosage> I tried visualising subtile coordinates for vehicle movement but couldn't find any interpretation of x_pos/y_pos that would make a continuous path
05:42:13 <locosage> ended up with `real_x = x + int(dx == -1) + dx * progress` formula
05:45:28 <locosage> though depending on what you're doing that may be irrelevant, as the game just draws the vehicle centered at x_pos, y_pos iirc
05:46:23 <locosage> it's more relevant if you want to do smooth vehicle movement for example
05:46:50 <tramrider> I am trying to find the location within the tile for the purpose of measuring the roadstop occupancy. Fortunately vehicles only seem able to stop at the front or half-way of a tile in road stops so I only need that level of accuracy.
05:50:45 <locosage> not sure what exactly do you count occupancy but it sounds like something that I'd do by looking at vehicle orders, not subtile coordinates
05:54:43 <tramrider> It's occupancy for the purpose of pathfinder penalties. Currently it under-penalizes road stops that are unusable if one vehicle is blocking the entrance, because of the way roadstop measures its own occupancy. Hardly a game-breaking bug but you can notice it if you have a lot of RVs.
05:56:05 <tramrider> It's PR #12290 if you want further context!
05:58:39 <locosage> oh, pf occupancy, yeah, that's tricky
06:17:39 *** marchnex has quit IRC (Remote host closed the connection)
06:17:51 *** marchnex has joined #openttd
06:25:48 <tramrider> I think I understand the logic for the fix, but tidying up the code will take me some time!
06:51:40 *** Leopold__ has quit IRC (Ping timeout: 480 seconds)
06:54:35 *** Leopold_ has joined #openttd
06:55:29 *** Leopold_ has quit IRC (Remote host closed the connection)
07:01:53 *** Leopold_ has joined #openttd
07:39:10 <truebrain> vcpkg now has 3 approvals, no merge 😛
07:41:40 <peter1138> Need to make sure they don't break anything
07:48:23 <truebrain> You would think that a change that broke linux vcpkg like fontconfig, harfbuzz, and more, would have a higher priority
07:48:32 <truebrain> but I noticed before that their care for linux is not all that high 😛
09:05:25 *** tramrider has quit IRC (Quit: Page closed)
09:11:50 <peter1138> > * Memory pool for engine renew elements. DO NOT USE outside of engine.c. Is
09:12:10 <peter1138> It's not used by `engine.cpp`, let alone `engine.c`
09:12:46 *** albertonl has joined #openttd
09:15:23 *** albertonl has quit IRC (Remote host closed the connection)
10:00:46 *** albertonl has joined #openttd
10:39:21 <andythenorth> might have a tea
10:50:06 <andythenorth> "clone individual vehicle"?
10:50:17 <andythenorth> as distinct to clone consist
10:57:05 <xarick> got conflicts to solve
10:58:26 *** PatataBrava has joined #openttd
11:01:25 <PatataBrava> priviet tovarisht
11:02:24 *** PatataBrava has left #openttd
11:14:50 <xarick> found another edge case, this one is strange
11:18:28 <xarick> ship is lost, don't know why
11:18:45 <xarick> the buoy access is unrestricted
11:19:11 <xarick> all the other ships are fine
11:19:46 <xarick> wondering if it's a me problem, let me try master
11:25:28 <xarick> also present in master
11:42:46 *** kuhnovic has joined #openttd
11:42:46 <kuhnovic> Is it also present in RC1 ?
11:43:17 <kuhnovic> Anyway, it's in master, so please report an issue 🙂
11:45:47 *** albertonl has quit IRC (Remote host closed the connection)
12:02:14 *** emperorjake has joined #openttd
12:02:14 <emperorjake> Aw, no more fighting over who gets to have Group 0?
12:03:00 <xarick> tile 33708 has a label of 0
12:03:07 <xarick> i wonder if that is the buoy
12:05:14 <xarick> nop, it's a coast, next to the buoy, this is quite interesting...
12:06:34 <xarick> this bug is deeper and has nothing to do with the pathfinder
12:06:44 <xarick> it's about station movement
12:07:33 <xarick> the buoy is removed and moved to another tile, this doesn't update the v->dest_tile of vehicles
12:07:41 *** Ox7C5 has quit IRC (Ping timeout: 480 seconds)
12:09:49 <xarick> what happened, the previous location of the buoy was valid, but then demolished, and rebuilt to a near location, reusing the same waypointid value, but with a different location. the old place was then raised terrain and became a coast
12:10:10 <xarick> pathfinder is given the old location, which is now a coast, and the high lvl pathfinder finds no water, hence the label 0
12:14:48 <xarick> low level pathfinder doesn't even get the chance, it fails right away in high level pathfinder with a size of 0
12:15:28 <xarick> would probably be given the same erroneous location, since it's also m_destTile = v->dest_tile;
12:30:35 <kuhnovic> What happens if you save and reload? I really hope you get the same error, otherwise there's desync potential
12:39:58 <LordAro> do stations get updated?
12:40:18 <LordAro> nothing stopping you from moving docks around either
13:18:09 <truebrain> michi_cc: will be happy, teaser added 😛
13:18:14 <truebrain> will change dates tomorrow for release 🙂
13:23:01 <xarick> strange, I can not reproduce the bug with those instructions
13:23:09 <xarick> there's something more to this...
13:26:44 <xarick> ah, the ship must be already going to the buoy
13:27:22 <LordAro> you should be able to construct a minimal 64x64 game to reproduce it
13:27:48 <xarick> seems to be somewhere in ProcessOrders
13:28:01 <xarick> when it checks whether the order is the same
13:28:47 <xarick> 7. Start ship must be moved to 4.
13:41:32 <_glx_> my guess is moving the station doesn't update current_order/destination
13:48:59 <peter1138> ^ This makes the screenshot wrong as it will use the same numbers as before for conversion 🙂
14:19:29 <truebrain> LordAro: lol @ your comment on #302, I was just doing a pass to remove a bunch of commas, as they were annoying me 😛
14:25:55 <truebrain> (over 150 commas in the text .. it was a bit much 😛 )
14:27:46 <xarick> from a user standpoint, "the ship is lost for no reason"
14:29:09 <xarick> forgot to upload a savegame
14:29:09 <LordAro> xarick: i was thinking "ship becomes lost after moving buoy"
14:29:22 <LordAro> as you know the reason ;)
14:29:35 <LordAro> if you don't know the reason, then yes (with a suitable savegame)
14:34:03 <truebrain> removed 50 commas .. lol
14:37:25 <xarick> my fix might be missing all the other type of orders that aren't those 3
14:39:43 <truebrain> ugh, okay, I will stop. I will rewrite complete parts if I look at it any longer 😛
14:39:53 <truebrain> the message is clear; the style could be better 🙂
14:55:25 <truebrain> `error: no type named 'source_location' in namespace 'std'`
14:55:41 <truebrain> right, time to quit OpenTTD development, I guess. 20 years. It was a good run 😛
14:55:59 <merni> xarick: I don't think so
14:57:01 <merni> I think `default: break` is unnecessary though (but it may be useful to indicate that you're not handling the other cases)
14:57:50 <xarick> the other cases can't return false
14:58:07 <xarick> they need to update the order/dest
14:59:07 <xarick> in other words, run the code that comes after
14:59:31 <peter1138> truebrain: What platform?
14:59:42 <truebrain> didn't really looked into why it complaints
14:59:51 <_glx_> not recent enough clang ?
15:00:38 <xarick> maybe it needs to return false
15:01:34 <_glx_> you can try decomposing the old check
15:02:58 <xarick> the old code says this
15:03:21 <peter1138> truebrain: I'm using clang and it's fine, so I don't think clang as "platform" is enough info 🙂
15:03:23 <xarick> if it's not a station order, return false
15:03:38 <truebrain> peter1138: I know; just didn't bother looking into it further for now 🙂
15:03:54 <truebrain> just felt like a good moment to stop development 😛 (I am kidding, to be clear)
15:04:08 <truebrain> gcc works fine btw; so just switched to that for now
15:04:18 <peter1138> Is it your system or some CI?
15:04:26 <truebrain> clang 14, ubuntu 22.04
15:04:43 <peter1138> So "platform" is your desktop. And that sounds out of date 😉
15:05:41 <peter1138> It's possible to stub out source_location, but not ideal 😄
15:06:07 <truebrain> seems clang-15 is available on the distro
15:06:13 <truebrain> something to try another day 🙂
15:09:11 <truebrain> I finally had an idea how to implement that 🙂
15:12:28 <truebrain> clang-15 works fine 🙂
15:13:29 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #12232: Fix #12228, #12231: Don't restrict path when checking ship reverse on first attempt, Pick a random trackdir if no path is found when force reversing https://github.com/OpenTTD/OpenTTD/pull/12232
15:14:04 <peter1138> truebrain: That was a quick day.
15:15:12 *** Wormnest has joined #openttd
15:15:29 <truebrain> ```Direct leak of 65536 byte(s) in 1 object(s) allocated from:
15:15:29 <truebrain> #0 0x55d11e29c522 in aligned_alloc (/home/micro/projects/OpenTTD/OpenTTD/build-clang/openttd+0x1376522) (BuildId: e25945ccd7fd6ad7dc8e66ea0f055a0ea4ada682)
15:15:29 <truebrain> #1 0x7f74215721df (<unknown module>)```
15:15:36 <truebrain> useful ... "unknown module"
15:15:40 <truebrain> peter1138: I know right!
15:16:10 <_glx_> oh we could probably remove fmt since we are c++20
15:16:12 <peter1138> valgrind or some sanitizer?
15:16:20 <truebrain> clang address sanitizer
15:16:30 <peter1138> I think I tried to enable that but nothing happened...
15:16:47 <truebrain> I run all my games with it since a few months; captured a lot of faulty code on my side 😛
15:16:50 <truebrain> and some existing bugs 🙂
15:17:25 <truebrain> `CC=clang-15 CXX=clang++-15 CXXFLAGS="-fsanitize=address" cmake ..`, in case you want to give it a go 🙂
15:17:47 <Rubidium> _glx_: maybe we could, now we deprecated some older compiler. But I do not have my hopes that far up yet
15:19:02 <truebrain> as GCC 11 compiles current OpenTTD just fine
15:19:10 <truebrain> so that 13 makes me worry a tiny bit 😄
15:19:24 <truebrain> (for the CI, that is)
15:19:49 <truebrain> but nothing stopping you from trying, ofc 🙂
15:20:19 <truebrain> not unthinkable most of our usecases are implemented on older compilers already 🙂
15:20:23 <_glx_> well release CI is on 12 for sure
15:21:13 <truebrain> so a massive `s/fmt::/std::` might just work .. or not 😄
15:21:44 <truebrain> _glx_: more the issue, GCC 13 is not available on 22.04 🙂
15:24:46 <_glx_> 415 occurence replaced 🙂
15:25:00 <Rubidium> yeah, missing support in Debian stable is going to be annoying :(
15:25:12 <truebrain> but missing support in Ubuntu stable is fine? 😛
15:26:36 <_glx_> `s/fmt::/std::/g` is not enough anyway
15:27:06 <_glx_> 148 errors on first build try
15:27:11 <truebrain> lol, `#include <format>` doesn't work on clang-15 .. I did expect that to work, tbh
15:27:46 <peter1138> ==655624==LeakSanitizer has encountered a fatal error.
15:27:46 <peter1138> ==655624==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
15:27:46 <peter1138> ==655624==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
15:27:52 <peter1138> Well, something happened.
15:28:00 <truebrain> don't run it with `gdb` 😛
15:28:13 <truebrain> I have never seen that error btw, so no clue 🙂
15:28:56 <truebrain> yeah, you need clang-17 or gcc-13, godbolt tells me 🙂
15:29:00 <truebrain> so this won't happen any time soon
15:29:04 <truebrain> (think in years, not months)
15:30:31 <peter1138> Well, I am more likely to run under lldb than not... Hmm.
15:30:35 <Rubidium> truebrain: the support in Debian missing is more annoying to me, than support in Ubuntu missing... Even then, Ubuntu's next stable will be in about a month, Debian's next stable I don't expect for at least a year
15:32:49 <truebrain> "to me" is the important part 😛 So egocentric 😛 😛
15:33:02 <truebrain> but yeah, 24.04 will have GCC-13 it seems
15:34:04 <truebrain> curious if clang-17 will be .. it seems so, but with Ubuntu you never actually know
15:34:42 <truebrain> Debian too has GCC-13 already in sid (and in testing)
15:34:57 <truebrain> clang-17 isn't in sid yet
15:36:06 <truebrain> but yeah, next Debian stable is in 2025, I guess. Add a year or what to that before people actually upgraded .. so std::format is not going to happen any time soon 😄
15:36:23 <truebrain> _jgr_: yeah, you would think; but it is Ubuntu .. they might change their mind last minute 😛
15:37:01 <_glx_> replacing FMT_STRING might be not easy
15:39:06 <xarick> seems wrong still... I'm so sad
15:39:37 <truebrain> `'initializing': conversion from 'size_t' to 'int', possible loss of data`
15:39:44 <truebrain> ofc there is one target that returns `int` from `fread`
15:40:30 <truebrain> only one compiler correctly informs when you cast `size_t` to `int` 😛
15:40:56 <_glx_> oh and fmt::print to std::print needs c++23
15:42:09 <_glx_> truebrain: looks like x64 msvc 🙂
15:43:55 <_glx_> ok just discard the idea of dropping fmt
15:44:00 <xarick> > '&&' within '||' [-Wlogical-op-parentheses]
15:44:23 <_glx_> it means you don't have the correct parantheses
15:45:26 <_glx_> you write something like (AA || BB && CC)
15:46:16 <_glx_> compiler reads it as (AA || (BB && CC)) but warns you it may not need what you expect
15:47:40 <xarick> (AA || (BB || CC) && (DD || EE))
15:47:59 <xarick> discord keeps changing my text
15:49:53 <_glx_> just edit your "problematic" line with backquotes
15:51:14 <xarick> (AA `||` (BB `||` CC) `||` (DD `||` EE))
15:51:39 <xarick> (AA || (BB || CC) ``&&`` (DD || EE))
15:51:46 <Rubidium> use IRC, looks perfectly fine here ;)
15:52:41 <_glx_> if it's all || or all && you don't need parentheses
15:52:56 <_glx_> but when mixed it's important
15:53:20 <peter1138> Backticks around the whole line, not just the part of it.
15:55:15 <LordAro> is it rendering it as a table or something daft?
15:55:29 <xarick> nothing like a print screen
15:55:30 <_glx_> no it's the spoil marker
16:01:12 <xarick> i think my code is still wrong
16:09:45 <xarick> but I'm not confident it is right
16:11:06 <_glx_> just found existence of powershell `| clip`
16:11:23 <xarick> for (Vehicle *v : Vehicle::Iterate()) { ewww that's bad
16:11:41 <_glx_> how often is a buoy relocated ?
16:11:42 <xarick> what if I have 1 million vehicles kek
16:13:23 <peter1138> There's the OrderList trick, but you can thwart that by using long non-shared orders...
16:15:02 <xarick> is that the correct approach?
16:15:46 <_glx_> it's a way to tell the buoy has moved
16:16:03 <xarick> wondering how the other cases are handled for airports, road bays, and so on
16:17:16 <xarick> I guess you're right, that may be better
16:17:37 <xarick> it updates immediately upon change instead of only when the order is processed
16:18:42 <peter1138> I don't know when it correct, and I think someone did already ask about how other cases are handled.
16:19:16 <merni> github-advanced-secu: Lol semicolon -> code
16:20:46 <_glx_> but ProcessOrder stuff might be there to explicitely handle all cases
16:22:29 <_glx_> so yeah, maybe try to find out how it's done for other movable stuff
16:25:03 *** D-HUND is now known as debdog
16:25:20 <peter1138> Might be that's also not handled 🙂
16:30:34 <_glx_> I tested with a bus, it seems it skipped to next order when I removed the station
16:31:37 <_glx_> because "(can't use station)"
16:34:17 <xarick> airports have UpdateAirplanesOnNewStation
16:37:29 <xarick> not quite the way I expected to be handled
16:39:12 <peter1138> RemoveOrderFromAllVehicles() should do the trick?
16:39:32 <peter1138> Actually that might be too much.
16:43:37 *** HerzogDeXtEr has joined #openttd
16:56:24 *** frosch123 has joined #openttd
16:56:24 <frosch123> truebrain: your blog is dated for 2024-03-15. do you want to publish today, or did you move to a weird timezone?
16:56:41 <truebrain> No, I wanted to have it in a preview
16:59:17 <truebrain> All because some merged a day too soon .. mistakes of a few .... 😛
17:05:17 <talltyler> Thanks for the fixes frosch123 🙂
17:14:45 <xarick> an alternative would be to check for order type
17:15:02 <xarick> have the pf do that, then get wp->xy
17:17:44 *** gelignite has joined #openttd
17:30:55 <peter1138> Have you determined that it's a bottleneck?
17:31:05 <xarick> yes, station list uses it
17:39:11 <peter1138> "It's used" doesn't mean "it's a bottleneck" 🙂
17:46:57 <Eddi|zuHause> well, technically, because the simulation is singlethreaded, everything is a bottleneck :p
17:51:01 <peter1138> Hmm, 47ms on Wentbourne.
17:51:54 <peter1138> 10ms by checking shared orders.
17:54:19 <peter1138> Seems to vary a lot.
17:56:06 <peter1138> I think it can be improved by not calling this function.
17:57:40 <peter1138> Got it down to < 1ms.
17:57:52 <peter1138> But, uh... it's not quite the same list 😦
17:58:41 *** __karma has joined #openttd
17:58:41 <__karma> Hey guys, regarding issue #11345 I believe it is fixed (in wallclock mode as well), but the default value text doesn't display the correct value, does this have to be fixed as well in the same PR?
18:00:44 <xarick> days/minutes are in 1 group, % is in another group
18:02:45 <__karma> Hmm mb, I didn't get what you said
18:03:14 <__karma> I meant like in wallclock mode the text should be Default Value: 5 Days/minutes/%?
18:03:26 <xarick> if service intervals are in percents, maybe it should just say 5%
18:03:34 <__karma> When in percentage it changes to 50 Days/minutes/%?
18:03:39 <peter1138> Oh yeah, Wentbourne doesn't even use shared orders. Hmm.
18:04:13 <xarick> if they're not in percentages, check the wallclock mode to display minutes
18:04:41 <xarick> at least that what I'd do
18:04:48 <xarick> but the defaults uhm... not sure
18:05:18 <peter1138> _zephyris: found a bit in the font 😄
18:05:18 <__karma> I see, I think I got it, each mode should only display its own units right?
18:05:35 <xarick> yes, that's what I'd do
18:05:38 <peter1138> Uh wait, it might be a bug in the game :S
18:05:40 <xarick> but others may disagree
18:06:30 <peter1138> Ah ha! Nope, it's a bug in OpenGFX 2.
18:06:32 <__karma> It makes sense, I'll see if I can figure out how text works
18:07:44 <peter1138> So is it acceptable for the station list to exclude unowned stations that you have no rating at, but which you do send a vehicle to?
18:11:16 <peter1138> My changed BuildStationsList drops from 47ms to 0.2ms if it doesn't matter...
18:12:53 <_zephyris> There's a bug? Or a bit? In the TTF or OpenGFX2?
18:13:44 <peter1138> That square next to Tatown Docks should be a little arrow.
18:13:58 <peter1138> It's a sprite in the baseset, not a glyph in the font.
18:14:47 <peter1138> Hmm, wish I knew which oil-rig it is.
18:15:27 <_zephyris> But getting a square because it's a private range glyph?
18:17:25 <_zephyris> I think I assumed the private range glyphs were only needed for the medium font, so that'd make sense
18:17:48 <xarick> isn't that an arrow pointing which order the vehicle is running?
18:20:28 <peter1138> Works with original TTD baseset and the TTF though.
18:20:51 <_zephyris> Must be in the base set small sprite font
18:22:53 <truebrain> at least the title game competition seems to go for a very clear winnen 😄
18:24:02 <peter1138> That's the station. This is listed in master, but excluded from my "optimized" test.
18:29:33 <salut3585> What settings in Gimp do I need to set to successfully export to a .grf file?
18:36:50 *** keikoz has quit IRC (Ping timeout: 480 seconds)
18:38:37 <peter1138> salut3585: Needs to be an 8bpp image using the palette it was saved with.
18:39:19 <peter1138> While you could potentially apply the palette again, some palette indexes are special and doing that might change them.
18:42:29 <salut3585> Do you have guide how to do it?
18:42:59 <_zephyris> peter1138: Uh oh. Well mystery solved. OpenGFX2 makes its sprite font from the fonts, which explains why it's missing there.
18:45:57 <peter1138> salut3585: Well, I think you need to start by not changing the image to be 32bpp when you open it.
18:46:51 <peter1138> JGRennisonviaGitHub: That NewGRF is doing horrible things :S
18:47:16 <peter1138> purchase-list/depot sprites are a different scale to viewport sprites o_O
18:59:03 <xarick> hopefully not a complex condition anymore
19:19:37 <peter1138> Well, now takes 5-10ms.
19:19:49 <peter1138> Better but not great 😦
19:20:34 <peter1138> Also, if filtering for trains, buses or trucks, it's now less than 1ms, because they don't have non-owned stations.
19:23:09 <peter1138> If I remove the test that includes non-owned stations with no rating but with vehicles ordered to stop there... then it's < 1ms whatever.
20:11:46 <peter1138> Ah "Amazing Xarick's Save" does not benefit as it has no oil rigs.
20:24:48 <andythenorth> sometimes there's no option
20:24:53 <andythenorth> except to play OpenTTD
20:24:58 <andythenorth> wall clock is a good thing btw
21:02:53 <xarick> ridiculous temperatures
21:32:15 <andythenorth> hmm think FIRS GS is quite broken with wallclock though 🙂
21:32:30 <andythenorth> it has a lot of elapsed time calculations
21:41:43 <kamnet> Crazy idea: support for multiple monitors so that the game play screen can occupy one and other monitors used for showing viewports, graphs, orders, menus etc?
21:42:26 <xarick> viewport on new window
21:43:06 *** Ox7C5 has quit IRC (Quit: Lost terminal)
21:45:34 <kamnet> My main gripe is that while you can stretch the game window over multiple monitors, the field of play is centered across them all This is absolute crap if you only have two monitors, it works better when you have three because it will be centered on the middle monitor.
21:46:07 <kamnet> but then they have to all be the same resolution and size otherwise it again becomes suboptimal
21:55:17 <xarick> I can't find a topic on AI dev forum
22:01:50 <xarick> I still remember AIAI being highly competitive
22:16:18 <xarick> ScriptGroupList still can't be used for GS's?
22:17:02 <xarick> nevermind, they can, I'm looking at an outdated branch
22:20:11 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:08:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:17:55 <xarick> wondering if my slow_valuate branch still works
23:19:48 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:27:37 <xarick> oops slow_valuate makes Rondje take too long to initialize
23:38:28 <xarick> oh, I see, it has valuate stuff there
23:38:48 <xarick> 13k towns might be too much
continue to next day ⏵
