IRC logs for #openttd on OFTC at 2023-02-05
⏴ go to previous day
00:00:26 <andythenorth[d]> oops forgot to choose a random point in my circle 🙂
00:01:36 <glx[d]> but once you have some random coord in the square around a given location you can filter more precisely and exclude those outside of the circle
00:02:59 <glx[d]> like get a random point in the square enclosing circle
00:04:05 <glx[d]> it's a good approximation and you can then check the distance to see if it's in or out
00:04:35 <glx[d]> if it's out pick another point
00:07:15 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
00:07:51 <andythenorth[d]> results look correct
00:08:14 <andythenorth[d]> I haven't tried picking the random point first yet
00:08:20 <andythenorth[d]> this still picks from a list of filtered tiles
00:08:49 <andythenorth[d]> I think this needs decomposing into more area functions
00:09:01 <andythenorth[d]> 'point is in circle' being one of them
00:11:50 <andythenorth[d]> I wish I could time to ms
00:12:04 <andythenorth[d]> I'm curious how long walking these shorter tile lists takes
00:12:54 <andythenorth[d]> I'm prepared to be wrong, but walking ~4096 tiles doesn't seem like it would be particularly expensive
00:13:38 <JGR> If you increase the radius it'll get more noticable
00:13:46 <andythenorth[d]> it would get worse if I tried to scale the radius to e.g. town density and map size
00:13:54 <andythenorth[d]> square laws 😛
00:14:22 <andythenorth[d]> but I already know that this GS isn't going to work on large maps
00:14:50 <andythenorth[d]> even just updating town text monthly can't be done on a 4k x 4k map
00:15:14 <glx[d]> at least the 'pick a tile and build an industry part' is efficient (unless bad luck at picking)
00:15:46 <andythenorth[d]> I'd rather have OpenTTD make the primitive shape, and then just provide it as a constraint to prospecting
00:15:51 <andythenorth[d]> but eh, one step at a time
00:17:14 <andythenorth[d]> ok let's stop making a square then booleaning the circle out of it
00:17:24 <andythenorth[d]> we should be able to make a circle directly with trig
00:17:27 <glx[d]> yeah for AI we don't want to give too much, but maybe GS can get some useful stuff in c++ side
00:19:05 <andythenorth[d]> I don't even need trig, it's just pythagoras?
00:19:21 <glx[d]> (the issue with native calls is we can't limit the execution time)
00:20:35 <andythenorth[d]> hmm pythagoras is going to end up with floats
00:21:15 <glx[d]> but adding some area limits for prospecting on openttd side should be "fine"
00:22:19 <andythenorth[d]> c^2 + a^2 = b^2
00:22:51 <andythenorth[d]> y^2 = c^2 + x^2
00:23:14 <andythenorth[d]> should give me a circle of x, y values, using a range of x - radius, x + radius
00:23:29 <andythenorth[d]> but then I have to sqrt and squirrel is going to throw a type error?
00:23:44 <andythenorth[d]> tile x, y can't be float 😛
00:24:16 <andythenorth[d]> maybe I can force int, and check for duplicates 😛
00:25:55 <JGR> glx[d]: You can charge as many opcodes as required though
00:26:17 <glx[d]> yes, but it won't stop in the middle
00:27:02 <andythenorth[d]> might not need to
00:27:35 <andythenorth[d]> if it's just maths to get tile xy pairs
00:28:05 <andythenorth[d]> the upper limit is probably quite high, if we stick to primitive shapes, not operating on lists of tiles
00:29:06 <andythenorth[d]> given an x,y point, does it fit in a region defined by areas
00:29:37 <andythenorth[d]> dunno, better to work out in GS first, then make it faster 😛
00:30:22 <glx[d]> that's why the square is a good approximation as it limits the number of (x,y) to try
00:31:13 <andythenorth[d]> I really want to try direct pythagoras circle, but I have no way to time it
00:31:35 <andythenorth[d]> and it's a bit late for my brain to figure out 😛
00:32:19 <glx[d]> but that's because you want to determine all tiles beforehand
00:32:49 <andythenorth[d]> I'm just curious now
00:33:07 <andythenorth[d]> is it faster to do a rect and exclude non-circle points?
00:33:12 <andythenorth[d]> or faster to do pythagoras
00:33:18 <andythenorth[d]> I reckon pythagoras
00:33:34 <andythenorth[d]> 12 rects can approximate an ugly circle also though
00:33:38 <glx[d]> while you don't really need the list of tiles, just a way to pick something that may be in the list
00:34:01 <andythenorth[d]> still needs a fast way to resolve true / false for the constraint
00:34:21 <andythenorth[d]> wonder if there's a parametric function for it
00:34:35 <andythenorth[d]> but I only ever used those to draw smiley faces on a calculator
00:35:12 <glx[d]> you have center, radius, it's easy to get the square
00:35:40 <glx[d]> and in many case any random (x,y) will be inside the circle
00:37:00 <glx[d]> and I don't thing checking distance to center costs that much
00:37:08 <andythenorth[d]> reminds me of the engineering degree I nearly failed, then quit
00:37:27 *** sla_ro|master has quit IRC ()
00:38:32 <andythenorth[d]> it's 0 seconds to find circles for 28 towns, then test random points in them until 28 farms are built
00:39:39 <andythenorth[d]> that's at map gen, it's obviously slower if game is running, as it has to run 28 do commands
00:40:39 <andythenorth[d]> when we batch commands somehow, we can circumvent the 1-command-per-tick restriction anyway
00:41:14 <andythenorth[d]> how many commands can the server run per tick (not just in script)?
00:41:19 <andythenorth[d]> or is that 1?
00:42:39 <andythenorth[d]> ffwd cuts the RL time 😛
00:42:53 <andythenorth[d]> I enjoy that the random is deterministic 🙂
00:43:00 <andythenorth[d]> it really does aid testing this kind of thing
00:43:41 <andythenorth[d]> I'll try a pathological map
00:43:50 <glx[d]> it's probably possible to make an array of commands to run, and get an array of results in return
00:44:54 <andythenorth[d]> or specify a command, and a list of items to run it over
00:47:32 <andythenorth[d]> ok 3 mins so far trying to build farms on 4k x 4k
00:48:04 <andythenorth[d]> 4880 farms built so far
00:50:50 <andythenorth[d]> some of that was on FFWD
00:50:57 <andythenorth[d]> 5270 farms built
00:51:31 <andythenorth[d]> 6.2 minutes 😛
00:53:11 <andythenorth[d]> same test, 2k x 2k map
00:53:25 <andythenorth[d]> 4k maps really are catastrophic 🙂
00:54:38 <glx[d]> the bigger the map, the higher the chance for no suitable location around a town
00:54:43 <andythenorth[d]> GS stuff really scales horribly with map size 🙂
00:55:07 <andythenorth[d]> I am going to limit FIRS GS to some max map size
00:56:43 <glx[d]> hey it could be a feature of your GS, like only towns at start, then industries progressively appears
00:58:08 <andythenorth[d]> we could just give GS more execution time at map start
00:58:55 <glx[d]> or scale generating loops to the map
01:00:09 <glx[d]> for now it's always 2500
01:01:41 <glx[d]> but towns, industries, ... are scaled by map, so why not GS startup
01:02:19 <andythenorth[d]> ha ha the news history 😄
01:03:43 <glx[d]> well that can be silenced with a well placed _generating_world check
01:05:58 <andythenorth[d]> if I omit the actual BuildIndustry cmd, a 1k x 1k map is 1s to find locations
01:06:43 <andythenorth[d]> 2k x 2k map is 5 seconds
01:08:00 <andythenorth[d]> 4k x 4k 43 seconds
01:08:21 <andythenorth[d]> no town counter anywhere in the game?
01:22:57 <andythenorth[d]> GSTile.GetClosestTown doesn't seem particularly expensive
01:23:05 <andythenorth[d]> omitting it doesn't affect test times much
03:30:47 *** Wormnest has quit IRC (Quit: Leaving)
03:46:38 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:43:45 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:43:49 *** WormnestAndroid has joined #openttd
07:43:28 <andythenorth[d]> ok these tiles in the circle might be invalid
07:43:39 <andythenorth[d]> I haven't checked for
07:43:39 <andythenorth[d]> - map extents
07:44:01 <andythenorth[d]> I just do BuildIndustry in test mode, and if that fails, discard the tile
07:44:20 <andythenorth[d]> I wonder if I need to validate, or if that's equivalent to a try/except and is enough
08:08:28 <andythenorth[d]> also pythagoras works
08:16:24 <andythenorth[d]> clipping the result to integer seems to have some artefacts
08:16:36 <andythenorth[d]> circle edges are ragged in a few place
08:17:23 <andythenorth[d]> be nice if these could be timed to ms
08:22:35 <andythenorth[d]> ideal would be passing a format / resolution parameter to GSDate.GetSystemTime()
08:38:01 *** WormnestAndroid has quit IRC (Read error: No route to host)
08:38:12 *** WormnestAndroid has joined #openttd
08:38:49 <andythenorth[d]> 'ellipses are just circles scaled along 1 dimension'
08:39:25 <andythenorth[d]> don't actually need elipses for anything so far but eh
08:43:04 *** HerzogDeXtEr has joined #openttd
08:55:04 <andythenorth[d]> ok now got a region composed of 2 areas
08:56:30 <andythenorth[d]> petern: ^ this starts to look plausible, but obvs I'm doing it the hard way in GS 😛
08:56:47 <andythenorth[d]> maybe I can hole punch next
09:00:01 <andythenorth[d]> ugh FML no array.find() in squirrel 2
09:16:45 <andythenorth[d]> it's operating on arrays of xy_pairs, 'probably fine'
09:17:49 <andythenorth[d]> I wonder if there's a fast method for calculating hexagons
09:18:49 <andythenorth[d]> hexagons in boiling fat are self-managing 😛
09:19:45 <andythenorth[d]> wonder how they can be done fast
09:19:52 <andythenorth[d]> maybe tangents at fixed angles
09:21:12 <andythenorth[d]> I don't like hexagon grids, but eh
09:49:37 <andythenorth[d]> a rect of 200 x 200 seems to get stuck, the GS just loops there indefinitely (I got bored waiting for it to close)
09:51:04 <andythenorth[d]> O(n) or something?
09:54:34 <andythenorth[d]> something is wrong with my duplicate checking
10:01:13 <andythenorth[d]> hmm walking large lists is super slow in squirrel
10:02:11 <andythenorth[d]> I can't think of a fast way to combine the constraints (as filters on points)
10:02:53 <andythenorth[d]> that would seem to require checking every tile on the map against the in/out constraint
10:11:43 *** sla_ro|master has joined #openttd
10:23:22 *** D-HUND is now known as debdog
10:48:47 <TrueBrain> that moment you are trying some stuff with libcurl, and libcurl segfaults .. that is not what was suppose to happen!
10:52:37 <TrueBrain> awh, CoPilot suggested a lambda as callback function, but this doesn't work as expected 😛
10:53:02 <TrueBrain> now I wonder why not 😛
11:01:11 <andythenorth[d]> ` if (x in ::index == false) {
11:01:11 <andythenorth[d]> ::index[x] <- {};
11:01:11 <andythenorth[d]> if (y in ::index[x]) {
11:01:11 <andythenorth[d]> // xy_pair already exists, don't add it
11:01:22 <andythenorth[d]> produces index not found at the second conditional
11:01:30 <andythenorth[d]> I've literally just created it
11:07:01 <andythenorth[d]> if ((x in ::index) == false) {
11:07:04 <andythenorth[d]> seems to sort it
11:16:35 <andythenorth[d]> ok I've tried using table slots as indexes when unifying areas
11:16:42 <andythenorth[d]> I have no idea if table slots are fast or slow
11:16:59 <andythenorth[d]> this seems performant, and doesn't seem to scale as horrifically
11:17:32 <andythenorth[d]> /me now waiting for the point where someone feels the need to help 😛
11:20:07 <TrueBrain> I am finding all kinds of weird issues in the network content system that needs attention 😛
11:20:23 <TrueBrain> when it is fetching the list of download URLs, it shows a random number of "to download" 😄
11:21:49 <andythenorth[d]> crashed Squirrel again 🙂
11:26:45 <andythenorth[d]> arrays have limited length in squirrel
11:27:20 <andythenorth[d]> I mean...not surprising but eh
11:32:24 <andythenorth[d]> oh GG I have used 1 GB of RAM
11:35:28 *** Wolf01 has quit IRC (Ping timeout: 480 seconds)
11:35:46 *** sla_ro|master has quit IRC (Remote host closed the connection)
11:35:50 *** sla_ro|master has joined #openttd
11:36:06 <andythenorth[d]> hmm `foo <- null` doesn't reduce RAM use
11:36:14 <andythenorth[d]> after the objects are finished with
11:39:03 <andythenorth[d]> does declaring `static areas = array(0);` have any effect on memory use?
11:39:14 <andythenorth[d]> this is inside a squirrel class
11:42:17 <andythenorth[d]> lol out of my depth here
11:46:37 <andythenorth[d]> ok seems Squirrel has trouble garbage collecting class instances?
11:52:54 <andythenorth[d]> ok instead of lists of xy_pairs
11:53:16 <andythenorth[d]> maybe we can have some kind of generator function, yielding 'next_xy_pair'
11:53:29 <andythenorth[d]> the shapes are only rects and circles
11:54:01 <andythenorth[d]> still there might be a million valid results
11:54:20 <andythenorth[d]> each an x,y, which is what, 2 values each uint32?
11:54:22 <nielsm> squirrel has a "delete" keyword that is supposed to delete the contents of a table slot
11:55:01 <nielsm> also you'd probably need to toy with weak references if you're making any kind of structure with circular references/back references
11:56:34 <andythenorth[d]> I'm stuffing a class instance into a slot, I think the refs persist
11:56:39 <andythenorth[d]> not sure what I can do about that
11:57:50 <andythenorth[d]> delete functions to clear the slot, but the memory is persisted
11:58:29 <andythenorth[d]> I might have to rewrite all this to slots not classes
11:58:42 <nielsm> there is also a global "collectgarbage()" function you can try calling, to see if it helps any
11:59:52 <andythenorth[d]> collectgarbage() isn't available to GS I think
11:59:55 <andythenorth[d]> index not found
12:01:13 <andythenorth[d]> I suspect that the problem is the approach of keeping pairs of x,y co-ordinates in arrays
12:01:21 <andythenorth[d]> this was already pointed out to me
12:01:38 <andythenorth[d]> using 1 GB to draw 4 circles isn't idea
12:01:47 <andythenorth[d]> even if it can be garbage collected later
12:02:35 <andythenorth[d]> well it's only 13 MB, to draw 4 circles but I do it 100 times to stress test
12:05:05 *** NGC3982 has joined #openttd
12:14:26 <andythenorth[d]> I'm assuming a squirrel integer is uint32?
12:18:41 <andythenorth[d]> max tile x even in JGRP is 16384 😛
12:18:58 <andythenorth[d]> this is probably the wrong approach, but storing a more sparse x,y pair would cut RAM use
12:19:53 <andythenorth[d]> 16 bits would be enough, but 'probably not how it works'?
12:24:13 <andythenorth[d]> oh the RAM use might be because I pass very large lists as function params
12:30:07 <JGR> Storing anything in Squirrel is going to have a large overhead
12:30:28 <JGR> It's not just 8 bytes per int or whatever it might be
12:30:54 <JGR> Really you should not be storing large amounts of data at all
12:31:01 <glx[d]> Variables are kinda variants
12:34:13 <andythenorth[d]> this makes a huge difference
12:34:44 <andythenorth[d]> 1) it cuts RAM use from 1GB for 100 loops to 15 MB for 100000 loops
12:36:01 <andythenorth[d]> I still think storing these lists is the wrong approach
12:36:14 <andythenorth[d]> but I don't know how to write some kind of generator thing in Squirrel
12:36:20 <andythenorth[d]> or python for that matter 😛
12:36:58 <andythenorth[d]> instead of storing all the valid points for a region
12:37:24 <andythenorth[d]> pass a single point to a function for the region, which evaluates true / false for the point being in / out
12:38:47 <TrueBrain> do you know these moments that you are working on some code, and it keeps crashing, only for you to realise the original code you base your work on shouldn't actually work
12:39:11 <glx[d]> Always nice when it happens
12:40:46 <TrueBrain> I guess it doesn't crash as the vector is likely instantiated with a size of 4 or what-ever, and there are never more than 2 items in the list
12:42:55 <glx[d]> Modifying in a controlled manner is ok I think, like the removal handling in the loop
12:43:11 <TrueBrain> it can cause a memmove, after which all iterators are kinda invalid 😛
12:43:51 <glx[d]> But iterator is updated in this case it seems
12:44:05 <TrueBrain> no no, check the `push_back` earlier in that file
12:44:18 <TrueBrain> that can extend the vector beyond its current size, causing a memmove
12:44:22 <TrueBrain> while iterating over it
12:45:26 <TrueBrain> so iterate -> Receive -> OnReceiveData(nullptr) -> Create new HTTP connection -> push_back
12:46:09 <TrueBrain> took me a while to figure out why my new code was crashing, and the old wasn't 😛
12:49:44 <glx[d]> Yes Receive() has a "side effect" invalidating iterator, but theoricaly the caller is "fine", just assuming nothing weird happens in callee
12:50:36 <glx[d]> So broken but not directly visible without jumping around the code
12:51:01 <TrueBrain> just can't believe it doesn't crash in master 😛
12:51:29 <TrueBrain> ah, no, not luck in that sense .. well, a little bit
12:51:39 <TrueBrain> I now realise why it does work ..
12:51:46 <TrueBrain> the first call does an HTTP request to get the list of content
12:51:56 <TrueBrain> this can cause a second call, BUT, that first needs DNS resolving
12:51:59 <TrueBrain> which is done threaded
12:52:17 <TrueBrain> if that second call was not done like that, but done directly to the HTTP connector, it wouldn't work
12:52:18 *** Jericho has quit IRC (Quit: User went offline on Discord a while ago)
12:52:37 <TrueBrain> well, yeah, so luck, in the sense: the second call is never done instantly
12:53:32 <TrueBrain> in other news, with relative little code I have libcurl working with OpenTTD, so we can make outbound https connections .. which is nice 🙂
12:53:53 <TrueBrain> WinHttp for Windows is also easy
12:56:55 <Samu> I can't do something that should be so easy :(
13:04:58 <andythenorth[d]> and giving them methods, instead of returning a list
13:05:25 <andythenorth[d]> 1. given a point x, y (or alternatively, tile index), is the point in the region?
13:06:33 <andythenorth[d]> 2. a 'yield all tiles' method which generates a sequence we can step through with 'next'. The x, y ranges needed to generate the sequence can be calculated from the constraints on the areas
13:07:04 <andythenorth[d]> I'd try and do it in Squirrel, but I'm so clueless about classes and methods, and also it seems to be trivial to create memory leaks with classes
13:09:37 <Xarick> This is master, notice the pale green, indicating rainforest
13:09:55 <Xarick> this is the commit i linked, it is missing the rainforest
13:10:49 <Xarick> I wanted to add rainforest to be as close as possible as master, via your distancesquare method or some sort of algorithm
13:11:10 <Xarick> because it's much much faster at generating it that way than looking up on a table
13:11:54 <Xarick> the desert part is already quite similar, minor differences, but the rainforest is not 😦
13:36:14 <kamnet> If it's lunch for you then it means its past breakfast for me. Two day old McDonald's apple pie, or a bag of chips whose freshness expired in November?
13:37:11 <TrueBrain> still draft 😛 Need to implement winhttp now
13:38:39 <TrueBrain> I totally and utterly forgot about the coding style of OpenTTD, so curious where I fucked up more 😛
13:39:00 <andythenorth[d]> uuf definitely lunch
13:39:08 <andythenorth[d]> can't reimplement all of this GS stuff without food
13:43:28 <andythenorth[d]> this isn't viable 😄
13:44:18 <andythenorth[d]> if it was, it would be very disappointing
13:47:22 <TrueBrain> `dbg: [net] HTTP request failed: HTTP response code said error` .. that "said error" is LibCURL reporting .. I think they should have removed the `i` there 😛
13:48:09 <LordAro> that's a good zorging, even by zorg's usual standards
13:48:38 <andythenorth[d]> it only deserves a gid
13:49:58 <TrueBrain> `In doing so, you are destroying the entire history of this game` .. not only the present and the future, BUT THE ENTIRE HISTORY
13:50:12 <andythenorth[d]> and the player is no long playing
13:50:14 <andythenorth[d]> just observing
13:50:46 <andythenorth[d]> I already asked via forums if LC has some non-neurotypical thing we need to consider
13:50:54 <andythenorth[d]> and got a mod warning for my efforts
13:51:02 <andythenorth[d]> so yeah, I think just ban that
13:51:05 <andythenorth[d]> it's pointless
13:52:10 <TrueBrain> glx[d]: I think this has been suggested a few times before, also for AIs
13:52:18 <TrueBrain> the problem is that the game starts to stutter at a certain point
13:52:40 <TrueBrain> yeah, so one can argue: it already does 😛
13:53:17 <TrueBrain> does it pause for an UI refresh .. I forgot how that worked 😛
13:53:52 <glx[d]> there's a pause after each Game::GameLoop() to update
13:54:40 <TrueBrain> but yeah, I missed it is for mapgen only; the other limits are not that easily to scale up
13:54:42 <glx[d]> funny thing I noticed, a dead script is not sleeping
13:54:50 <TrueBrain> this one seems like a solid solution to me
13:58:57 <TrueBrain> stupid tabs vs spaces
14:00:24 <andythenorth[d]> meh where is all the RAM going 😛
14:00:32 <michi_cc[d]> I don't supposed someone is just burning to write some nice release announcement summarizing beta1 to now?
14:00:48 <TrueBrain> I think LordAro was just mentioning he really wants to do that
14:01:04 <andythenorth[d]> I will if no-one else does, but right now I am in grump 😛
14:02:38 <andythenorth[d]> not aided by the google results for 'squirrel subclass'
14:03:53 <andythenorth[d]> "Just in time for Christmas, it's OpenTTD 13.0!"
14:06:35 <glx[d]> andythenorth[d]: but you are already subclassing in info.nut and main.nut 😉
14:10:16 <LordAro> TrueBrain: doesn't sound like something i would say
14:16:04 <TallTyler> I can write a release announcement as an advance atonement for destroying the past, present, and future of OpenTTD
14:18:44 <michi_cc[d]> I started with something, but improvements are very welcome.
14:23:57 <TallTyler> I have almost nothing to add to that, besides the idea of claiming we're almost two months early for the old April 1st release date 😛
14:31:10 <Samu> i wanted to build upon it
14:37:34 <andythenorth[d]> I am so far down the rabbit hole 😛
14:37:41 <andythenorth[d]> pls send help
14:39:30 <Samu> the queue and the replacement of desert into normal
14:39:50 <Samu> adding to the queue while processing the queue, it's magic how it all works
14:39:56 <glx[d]> what was wrong with genland array ?
14:40:02 <Samu> and doesn't cause an infinite queu
14:40:16 <Samu> this code isn't mine, i borrowed it
14:41:09 <Samu> the genland for tropic tileset is slow
14:41:17 <Samu> and this algorithm makes it ultra fast
14:41:44 <Samu> the rainforest placement is off
14:41:50 <michi_cc[d]> TallTyler: Feel free to propose/add a commit to the PR.
14:42:01 <andythenorth[d]> crashed squirrel again 😄
14:42:28 *** WormnestAndroid has quit IRC (Remote host closed the connection)
14:42:49 <glx[d]> there's nothing magic with the queue, the loop checks for emptyness and then work on poped first element, so pushing more at the end of the queue is fine
14:43:45 <Samu> i wanted to fix the rainforest placement, but everytime i touch that queue, i fail, i either create an infinite queue
14:44:03 <Samu> or i make rainforest on the wrong tiles
14:44:51 <Samu> some of the normal tiles that are placed are supposed to be rainforest
14:44:52 <andythenorth[d]> let's crash Squirrel some more 😦
14:46:52 <andythenorth[d]> ok it's possible to try and allocate an array that's too big
14:50:48 <andythenorth[d]> but if the limit isn't tripped
14:51:04 <andythenorth[d]> allocating a huge array doesn't bloat GS memory use, not permanently anyway
14:51:43 <Samu> i want the algorithm to do as close as master
14:54:23 <Samu> what the queue magic does is create TROPICZONE_NORMAL
14:55:26 <Samu> it is initially all desert
14:56:29 <Samu> everything above water is desert initially
15:08:52 <TrueBrain> Something that contains water
15:10:12 <TrueBrain> ugh, `std::wstring` ... why do they exist? 😦
15:11:55 <andythenorth[d]> a circle doesn't have to be a list of tiles
15:12:05 <andythenorth[d]> it could be a list of rows of tiles, with start, finish
15:12:30 <andythenorth[d]> are tile indexes inherently more memory efficient than x,y pairs?
15:12:38 <andythenorth[d]> 1 uint64 vs 2?
15:21:34 <nielsm> tile indexes are actually uint32
15:22:18 <nielsm> I don't think anything supports 65536x65536 maps
15:22:39 <nielsm> (which is the max that could be indexed by 2x16 bits)
15:24:26 <TallTyler> JGR: Is your wall clock/SD implementation already independent of calendar dates? (As in, days don't align with years.) I'm trying to think about how my time PR would break your patchpack if you choose to downstream it, and Scheduled Dispatch (a feature I love) is really the only sticking point. My PR no longer shows fixed points in time for arrival/departure dates or start dates: they are displayed in seconds relative to the curre
15:24:26 <TallTyler> stored as an economy date.
15:25:28 <JGR> Most users of scheduled dispatch timetable in minutes, instead of days
15:26:04 <JGR> Minutes are independent of calendar days and the economy preogression speed
15:26:28 <andythenorth[d]> ok let's convert to tile indexes, not x,y pairs
15:26:58 <JGR> In terms of your PR, I wouldn't worry too much about how I'll deal with it
15:27:35 <TallTyler> Thanks, that's what I was hoping 🙂
15:27:44 <JGR> I am not afraid of adding more settings, so am quite happy to have traditional mode/new vanilla mode toggle if need be
15:28:19 <petern> Is it beer o'clock yet?
15:28:42 <TallTyler> Maybe I'll tell Zorg to play JGRPP to avoid my changes 😛
15:28:50 <andythenorth[d]> so GS memory bloat...due to large arrays, or that I am copying 700000 class instances into an array?
15:29:19 <JGR> TallTyler: Eh, I think he'd have a field day complaining about UI stuff in my branch
15:31:16 <andythenorth[d]> so areas in openttd, not GS? 😛
15:40:40 <andythenorth[d]> hmm unifying 12,000 areas to one tile list
15:41:03 <andythenorth[d]> 1000 of the areas are a rect of 500 x 500
15:41:42 <andythenorth[d]> memory is now
15:42:02 <andythenorth[d]> I will spend a week on this, then one of you will solve it in 30 minutes 😛
15:43:11 <andythenorth[d]> 6000 areas is
15:43:16 <andythenorth[d]> so that looks pretty linear
15:44:58 <andythenorth[d]> unifying 120 areas, a more realistic upper limit I think
15:45:27 <Samu> how do i remove a tile from a std::vector<TileIndex>
15:46:03 <Samu> i tried desert_tiles.erate(tile); doesnt work
15:49:08 <JGR> Samu: erase in this context uses an index into the array, not a stored value
15:53:04 <Samu> desert_tiles.erase(std::find(desert_tiles.begin(), desert_tiles.end(), t));
15:54:37 <Samu> looks like I did it! but it's probably slow on 4k maps
15:57:29 <andythenorth[d]> the things we could do without them
15:57:44 <Samu> the erase function itself is slow
15:57:58 <Samu> or maybe it's the finding and erasing
15:59:41 <JGR> Again, giant lists of tiles is really not the way to go, most of the time
16:00:51 <andythenorth[d]> I'm curious what the use case for giant tile lists is
16:01:01 <andythenorth[d]> other than the 'nuke a city' demolish area blast radius thing
16:01:55 <andythenorth[d]> I am 99% persuaded that 'pick a random tile within constraints' can be done without a list, accepting that random can sometimes yield unwanted results
16:02:46 <andythenorth[d]> the only case I can see for a giant list is to do a foreach over and area, running a command like GSTile.DemolishTile
16:03:44 <Samu> i failed, i turned something ultra fast as ultra slow
16:03:47 <andythenorth[d]> I am trying to work out how to write a generator
16:03:57 <andythenorth[d]> so that instead of a giant list, I can yield 'next tile'
16:04:11 <andythenorth[d]> just based on either tracking an x,y, or a tile index
16:04:28 <andythenorth[d]> but that is proper programming 😛
16:08:24 <andythenorth[d]> ok my script without instantiating any areas 😛
16:09:13 <andythenorth[d]> script with 1200 areas
16:09:24 <andythenorth[d]> JGR: ^ less concerning? 😛
16:09:49 <andythenorth[d]> it might use more than that during some ops, but it's not leaking at least
16:09:54 <JGR> Sounds better than gobbling up 1GB 😛
16:12:02 <andythenorth[d]> see if I can break it with a stupid loop
16:15:18 <andythenorth[d]> ok that's more expected result
16:15:50 <andythenorth[d]> 600 areas in 50 regions
16:25:59 <andythenorth[d]> switched from lists of x,y pairs to lists of tile indexes
16:26:07 <andythenorth[d]> hard to tell if it's more memory efficient
16:26:45 <andythenorth[d]> might also be slower, it has to do more GSMap.GetTileX() and GSMap.GetTileIndex() type lookups
16:29:43 *** WormnestAndroid has joined #openttd
16:47:57 <andythenorth[d]> "probably fine"
16:48:02 <andythenorth[d]> can be annoyingly slow to run
16:48:59 <andythenorth[d]> oh it coincides with savegame maybe that's why
16:49:49 <andythenorth[d]> no sometimes it's just slow]
16:50:13 *** Wormnest has joined #openttd
17:13:11 <michi_cc[d]> So, any more comments on 13.0 proper (or the announcement)? Otherwise it's going to be Taggy MacTagface.
17:13:46 <Pruple> if 13.0 is being released, I guess that means I need to finish my newgrfs D:
17:14:32 <andythenorth[d]> Pruple: first variants grf? o_O
17:15:15 <Pruple> I'm supposed to be finishing the notbase, got bored with airports and haven't done much these last two weeks or so.
17:15:35 <andythenorth[d]> I have been very busy with Horse, as the channel log shows
17:15:52 <petern> I've been doing nothing.
17:15:58 <andythenorth[d]> I played a lot of tanks
17:16:32 <petern> And acquired a GM MIDI synthesizer to make the music sound good.
17:16:47 <michi_cc[d]> How about an approval on the website PR?
17:19:45 <Pruple> I'll say this for #10449, it's refreshing to see someone playing a 256* map
17:20:08 <Pruple> instead of a 95% empty 4k
17:22:44 <TallTyler> Now TrueBrain promised to update Steam and GOG images 😛
17:23:14 <michi_cc[d]> Now we play the wait on actions game 🙂
17:23:58 <michi_cc[d]> orude: 13.0 proper incoming for Windows Store.
17:24:09 <michi_cc[d]> orudge: 13.0 proper incoming for Windows Store.
17:24:14 <michi_cc[d]> No edit for IRC :p
17:24:14 <TallTyler> I love it when people close their own issues once resolved 🙂
17:25:45 <TallTyler> petern: #10170 for 13.1? (you assigned yourself) 😛
17:27:22 <TrueBrain> TallTyler: Ugh. Was hoping you wouldn't notice :p something later tonight I guess ... 🙂
17:27:44 <michi_cc[d]> I did put a news image into #249 at least 🙂
17:35:57 <andythenorth[d]> ha so areas and regions might just be slow and eat memory?
17:36:14 <andythenorth[d]> even if we do a native implementation, not squirrel?
17:36:31 <andythenorth[d]> such things 🙂
17:38:00 <TallTyler> I don't understand why it's not just a range of TileIndexes, but I don't know exactly what you're trying to do 🙂
17:41:23 <glx[d]> for some reasons andy wants to get a list of tiles before doing stuff with them (like choosing one of them randomly)
17:42:08 <andythenorth[d]> squares and circles
17:42:26 <andythenorth[d]> they can't be persistent lists, that will absolutely bloat memory
17:42:34 <andythenorth[d]> regions could be large areas of the map
17:42:50 <andythenorth[d]> they have to be simple calculations for areas based on rect or circle
17:44:13 *** gelignite has joined #openttd
17:45:22 <glx[d]> hmm you could get a random (x, y) from circle
17:48:31 <andythenorth[d]> the problem with not putting lists in memory
17:48:41 <andythenorth[d]> is that doing the calculations is dog slow
17:48:50 <andythenorth[d]> as far as I can tell
17:49:20 <andythenorth[d]> random(x, y) is probably fast initially, but needs to loop until it finds a valid tile to build on
17:51:31 <JGR> You need to do those exact same calculations, in greater number, to populate the lists in the first place?
17:52:53 <andythenorth[d]> depends how out of date regions can regarding the map
17:53:05 <andythenorth[d]> I'm not proposing the caching strategy, it's not viable
17:53:12 <andythenorth[d]> but the other route is slow
17:53:18 <glx[d]> you could cache delta_y values
17:53:38 <andythenorth[d]> at least, it seems slow, using the limited seconds-resolution timing I have available
17:53:55 <andythenorth[d]> and that GS seems quite inconsistent in performance
17:54:33 <andythenorth[d]> the initial results were promising because I was gain using the free opcodes at game start
17:54:56 <andythenorth[d]> but resolving the tiles for a single simpl-ish region can take 20 seconds in normal play
17:55:04 <andythenorth[d]> not really viable eh 🙂
17:55:31 <andythenorth[d]> possibly resolving the tiles for a region shouldn't be possible
17:55:55 <glx[d]> only radius delta_y values are needed
17:56:09 <andythenorth[d]> for the circle? Yes then just look them up by x
17:56:45 <andythenorth[d]> 50% of what I am trying to do is already in GS, via GSTileList.AddRect
17:56:55 <andythenorth[d]> but I am reimplementing it as we seem to be against GSTileList
17:57:14 <andythenorth[d]> and I am not using GSTileList for the results either on the same basis
17:58:01 <andythenorth[d]> just simple array()
17:58:26 <glx[d]> your GetTiles() is already calling DeltaYFromDeltaXPythagoras() twice as much as needed
17:59:09 <andythenorth[d]> because we can just do one half and invert the sign?
17:59:56 <glx[d]> yes -delta_x and +delta_x give the same delta_y
18:00:27 <andythenorth[d]> I suspect that GetTiles() shouldn't exist at all 🙂
18:00:41 <andythenorth[d]> the main use case for this would be nuking cities, and drawing smiley faces on the map
18:01:06 <glx[d]> what you want is just GetRandomTile
18:01:26 <andythenorth[d]> for the industry locating case yes
18:01:31 <andythenorth[d]> not for the nuking cities case 😛
18:02:23 <andythenorth[d]> I suspect that my Rect2 function is also stupid
18:02:28 <glx[d]> are you nuking cities more than locating industries ?
18:02:45 <andythenorth[d]> Rect2 doesn't do any modulo on the distance
18:02:56 <andythenorth[d]> and I suspect that we can just flood-fill the list from tile indexes somehow
18:03:00 <glx[d]> yeah Rect2 is already provided by the API (somehow)
18:03:13 <andythenorth[d]> GSTileList.AddRect
18:03:34 <andythenorth[d]> for (TileIndex t : ta) this->AddItem(t);
18:04:42 <andythenorth[d]> I need to add methods like TileIsInArea() or something
18:04:47 <andythenorth[d]> that's the more interesting case
18:04:57 <andythenorth[d]> and shouldn't need lists, just calculations
18:06:35 <glx[d]> yes and it's not complex calculation `x >= origin_x - radius && x <= origin_x + radius`
18:06:45 *** smoke_fumus has joined #openttd
18:08:02 <glx[d]> and if that's valid you do the same for y (using `delta_y(abs(x - origin_x))`)
18:11:15 <glx[d]> oh `abs(x - origin_x) <= radius` should work too for the check
18:11:53 *** ChanServ sets mode: +v tokai
18:12:26 <andythenorth[d]> glx[d]: fork my GS? 😛
18:18:03 <Samu> i need to make it super fast, like the code above it
18:18:48 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
18:19:18 <Samu> need ideas to make it do what that snippet do, but without exaustively repeating the search
18:20:11 <Samu> just need to calculate the distance to the closest desert tile
18:20:19 <andythenorth[d]> I can't read C++ very well, but are you zipping two lists together there?
18:20:23 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:20:30 <andythenorth[d]> oh wait, are you looping over all tiles, then again?
18:20:41 * andythenorth[d] doesn't know the game internal API very well
18:20:44 <glx[d]> samu: normal_tiles.length() full all map loop can't be fast
18:21:11 <andythenorth[d]> thanks michi_cc[d] 🙂
18:22:21 <glx[d]> at least exchange inner and outer loops
18:24:08 <michi_cc[d]> TrueBrain: Steam/GOG left, Reddit/Twitter/Forums done.
18:24:52 <TrueBrain> Will do when I am back home. Will be a bit, so people will have to wait :p
18:33:24 <Samu> i can't exchange inner and outer loops :(
18:33:56 <Wolf01> Maybe we are stable now, focking ISP? 😒
18:36:58 <Samu> i act upon the tiles from normal_tiles list, and not the other way around
18:37:46 <andythenorth[d]> was it beer time yet?
18:38:47 <Samu> maybe kdtree? how do I use the kdtree?
18:38:58 <Samu> i want to map all desert tiles
18:39:22 <Samu> then i just want to know the distance to the closest desert tile
18:41:13 <Samu> or maybe, alternatively some kind of magic algorithm that sets rainforest for the tiles that are xx radius away from the desert
18:42:55 <andythenorth[d]> are you trying to achieve a specific result?
18:43:05 <andythenorth[d]> or figure out a new game affordance?
18:43:15 <DorpsGek> - Update: Translations from eints (by translators)
18:43:30 <Samu> yes, i'm trying to achieve a faster map gen for tropic
18:43:43 <Samu> that looks nearly equal to what it does now
18:44:07 <Samu> in relation to placing desert zones, and rainforest zones, and normal zones
18:52:45 <Samu> gonna try BitMapTileArea
19:20:24 <TrueBrain> GOG done .. now the nightmare called Steam ... as someone wanted new pictures .... 😛
19:21:42 <TrueBrain> btw TallTyler : updating GOG assets is way too much effort (I have to email them, and it is a whole thing) for the effort I want to put it right now .. so going to do Steam only for now 🙂
19:22:29 <TallTyler> Works for me, no idea how many people use GOG to play OpenTTD anyway
19:22:50 <TrueBrain> a number not worth talking about, sadly 😦
19:26:22 <michi_cc[d]> For indie games, it looks like itch.io has gained popularity. And Epic is also competing in the game distribution scene, so not many people probably have a reason to really use GOG anymore.
19:31:05 <TrueBrain> I am surprised that the Small Capsule is not replaced with your PR TallTyler 😛 I consider that one of the .. weirdest one that exist in the set 😛
19:37:06 *** MarkoMarko has quit IRC (Quit: User went offline on Discord a while ago)
19:37:31 <TrueBrain> Published everything on Steam
19:40:54 <TrueBrain> and I pressed the button to give it extra attention on the Steam platform
19:44:12 <frosch> there is a button for extra attention? do people hire interns to press it every day?
19:44:41 <TrueBrain> frosch: the description is very clear to not press that button often 😛
19:46:17 <TrueBrain> okay, I think I did my thingy too 🙂 I love the auto-upload to GOG .. so much better this way
19:49:14 <andythenorth[d]> TrueBrain: is there an intern for counting how many times it was pressed?
19:55:45 <andythenorth[d]> ok so next, restricting prospecting to an area
19:55:53 <andythenorth[d]> how will we do that? 🙂
20:05:04 <petern> Areas. Areas isn't being USED that way. Mine is.
20:10:45 <andythenorth[d]> areas for your areas
20:19:57 <TrueBrain> meh .. WinHttp it a bit tricky to work with
20:20:01 <TrueBrain> it was working in sync mode
20:20:12 <TrueBrain> but now in async .. I don't get any callback on data available
20:24:29 <TallTyler> TrueBrain: I think I made that one, actually. It could be replaced but it’s so small you can’t fit much detail without it looking busy and confusing.
20:27:02 <TrueBrain> okay, found it .... hidden in the forest of documentation, you have to call `WinHttpReceiveResponse` after the request is sent ... I don't even ... ugh 😛
20:28:45 <TrueBrain> "async", but you have to push the state machine forward ... `WinHttpQueryDataAvailable` has to be called after you receive the headers
20:28:51 <TrueBrain> this is so more complicated than it has to be
20:30:33 <frosch> meh, looks like there was no update to the networking TS since 2018, so no easier standard solution in sight. it's still all boost 🙂
20:31:26 <frosch> technical specification, i.e. the PR/discussion section of the c++ spec
20:32:50 <frosch> boost.asio exists since 2005 or something. inclusion of it has been a plan since c++17, then the gpu people joined in on the executor stuff, then coroutines, ...
20:32:52 <andythenorth[d]> goes it extend tiles to put region pointer on them? 😛
20:33:18 <frosch> maybe executors made it to c++23, not sure, so maybe after that networking it is :p
20:33:32 <TrueBrain> owh wow ... this WinHttp .. it can call a callback while in a callback
20:33:40 <TrueBrain> not sure what to think about all this 🙂
20:34:41 <frosch> isn't there some kind of "waitmultipleobjects" instead of callbacks?
20:34:53 <TrueBrain> the callback pumps the statemachine
20:34:59 <TrueBrain> it is just a bit odd, in many ways ..
20:35:08 <TrueBrain> and they kept adding stuff 😛
20:35:20 <TrueBrain> a better solution would be to do this threaded, and sync
20:35:31 <TrueBrain> but .. yeah .. that requires way too much changes throughout our code 🙂
20:36:37 <frosch> you can always do it sync in a new thread, and then add your own callback stuff between the threads
20:40:01 <TrueBrain> nah, I now almost got it .. it is just a really odd duck
20:43:59 <TrueBrain> "async" they said .. just a lie, if you ask me 😛
20:44:25 <TrueBrain> `WINHTTP_CALLBACK_STATUS_READ_COMPLETE` is triggered during `WinHttpReadData` which you call in `WINHTTP_CALLBACK_STATUS_DATA_AVAILABLE`
20:44:39 <TrueBrain> which means you need an internal bool to know inside `WINHTTP_CALLBACK_STATUS_DATA_AVAILABLE` it was the last piece of data
20:44:47 <TrueBrain> which you expect you could do in `WINHTTP_CALLBACK_STATUS_READ_COMPLETE`
20:48:20 <dP> what's the simplest way to test x86 build?
20:48:30 <dP> somehow I managed to screw it up :/
20:58:24 *** lobstarooo has joined #openttd
21:00:36 *** lobstarooo__ has quit IRC (Ping timeout: 480 seconds)
21:00:45 *** lobstarooo is now known as lobstarooo__
21:01:55 <andythenorth[d]> areas for the Samu rainforest thing? 😛
21:02:44 <andythenorth[d]> how about we restrict maps to 1048576 tiles, in arbitrary combinations 😛
21:02:57 <Samu> dP, you're the area expert!
21:02:58 <andythenorth[d]> then expand our memory use with lots of tile caches / layers / areas
21:05:15 <dP> I don't understand what you're trying to do
21:12:10 <Samu> calculate the shortest distance to the closest desert tile
21:16:38 <andythenorth[d]> you probably just have to search outwards
21:17:34 <andythenorth[d]> map stuff is always hard 😛
21:20:41 <dP> Samu: why does that even matter? afiact you're just changing TROPICZONE_NORMAL into TROPICZONE_RAINFOREST in some rare cases?
21:23:06 <dP> Samu: the obvious way to make it faster is just check the area within the 7 tile radius instead of the whole map
21:23:27 <dP> but in general you seem to do something weird
21:23:45 <dP> it would be better to just assign zones right on the first pass
21:25:11 <Samu> I guess, but how do I do it?
21:26:30 <Samu> you first assign everything that is not water to be desert, that part i understood
21:26:45 <Samu> then the queue magic is too much for my understanding
21:28:15 <andythenorth[d]> it's just hard to make a picture of what it's doing
21:28:26 <TrueBrain> oof .. the hardest part of Windows ... translating an error code to a string ... lol
21:28:39 <TrueBrain> `HTTP request failed: generic error - unknown error 12007`
21:28:39 <andythenorth[d]> what does `auto &p = queue.front();` do?
21:28:42 <TrueBrain> not all the friendly etc
21:29:46 <Samu> picks the front tile pair
21:29:55 <JGR> `auto &p = queue.front();`
21:30:37 <Samu> should it be auto p = queue.front();?
21:31:10 <glx[d]> yeah don't reference something you might delete
21:31:19 <Samu> visual studio complained about something about p
21:31:32 <Samu> and the auto fix was to put it &p
21:32:03 <TrueBrain> `HTTP request failed: The server name or address could not be resolved`
21:32:57 <Samu> VS says: 'auto' doesn't deduce references. A possible unintended copy is being made.
21:33:51 <JGR> Just ignore it, or specify the actual type you want
21:34:44 <glx[d]> you explicitely don't want a reference here, as it will be invalidated by pop()
21:35:36 <glx[d]> so a copy is fine (and mostly intended)
21:35:43 <Samu> std::pair p = queue.front();
21:36:02 <JGR> What are you actually trying to achieve with this queue?
21:37:09 <TrueBrain> now with WinHttp support ^^ 🙂
21:38:11 <Samu> i want the queue to do magic!, ask dP, he created this piece of code
21:38:38 <andythenorth[d]> or is it just stepping through all tiles, checking neighbours, and setting a terrain type bit?
21:39:01 <Samu> it seems to turn desert tiles into normal
21:39:08 <Samu> but according to a criteria
21:39:20 <Samu> then it adds more tile pairs, which is the confusing part
21:39:52 <Samu> and i say it's magic because it doesn't trigger an assert, doesn't create an infinite queue
21:40:01 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:40:08 <Samu> and the results are amazingly close to the original in master
21:40:17 <Samu> but, it is missing the rainforest
21:40:59 <Samu> and most importantly, it's super fast, in comparison
21:41:16 <TrueBrain> not sure what implementation looks better .. libcurl or winhttp .. they both have their pros and cons 😛 Funny 🙂 Right, all that is left is emscripten support, and a lot of testing 😛
21:58:42 <TrueBrain> `Passengers from Parnford to Wuham (Parnford Transport, 12 minutes left)` .. that would be so lovely ... I see this more often in games lately, where they use real time to indicate when something happens that is important to you
21:58:47 <TrueBrain> makes things so much easier to process as human
22:00:34 <andythenorth[d]> real time, or just arbitrary time since game start
22:00:48 <andythenorth[d]> the downside of real time, it reminds you how many hours you lost to OpenTTD
22:01:29 <TrueBrain> I was playing a factorio mod (a very large mod, but who is counting) that surprised me with this .. it said: in 24h, something bad happened. And I was like: 24h game-time? What makes a day?
22:01:33 <TrueBrain> but it meant 24h real time
22:01:39 <TrueBrain> which happened a lot quicker than I expected 😛
22:02:47 <TrueBrain> ended up wasting 300+h on that mod, so it happened more than once 😛
22:03:34 <TrueBrain> I hadn't read #10322 in detail yet, but it really would make things a lot easier to understand in many regards .. I think it is pretty fancy 😄
22:08:53 <TrueBrain> lol, stupid msys, complaining about the little things
22:09:07 <TrueBrain> at least it compiled the winhttp fine .. just some silly warnings
22:15:16 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:30:16 <TallTyler> andythenorth[d]: It's always relative to the current time, and changes as you look at it. Timetables have the most obvious example, since they're in multiples of two seconds.
22:30:32 <TallTyler> planetmakerviaGitHub: Now there's a name I haven't seen in a while 😄
22:33:11 <petern> Why did I decide to pick up my Beneath a Steel Sky savegame...
22:34:18 <andythenorth[d]> TallTyler: it could be patched at root - real time vs elapsed time since game start
22:34:34 <andythenorth[d]> just change the call to system clock or time now - start time 😛
22:35:30 <TallTyler> I thought about it, honestly
22:36:28 <TallTyler> But figured that would open a can of worms regarding pause, fast-forward, and OS differences
22:37:34 <JGR> That might be particularly entertaining on multiplayer
22:40:39 <TallTyler> It's all stored (and sent) in ticks and dates, so it might be fine
22:42:56 <andythenorth[d]> I didn't look where it's taking time from 😛
22:43:01 <andythenorth[d]> but generally the clock can be lied about
22:43:52 <TallTyler> Plus, real time elapsed is confusing because how long ago did you start the game? I certainly don't keep track, and probably would rather not 😛
22:45:23 <JGR> I tend to use build while paused pretty heavily
22:45:42 *** virtualrandomnumber has joined #openttd
22:46:10 *** virtualrandomnumber has quit IRC ()
22:59:04 <Samu> reduced from 125 seconds to 35 seconds, in debug mode
22:59:38 <Samu> but missing the rainforest
23:03:12 <Samu> can be faster, run tile loop doesn't need to run
23:05:42 <FLHerne> tbh I still kind of agree with Zorg
23:06:04 <FLHerne> the real-world time thing does break immersion in a way I really don't enjoy
23:06:27 <FLHerne> but the alternative thing with adaptive time units does seem crazy
23:07:16 *** gelignite has quit IRC (Quit: Stay safe!)
23:17:34 <Samu> ScriptTileList.AddRectangle... so i added the entire map, and openttd stalls
23:20:30 <Samu> well today I achieved nothing!
23:20:40 <Samu> failed to do the rainforest part
23:20:53 *** Samu has quit IRC (Quit: Leaving)
23:37:59 *** sla_ro|master has quit IRC ()
23:38:28 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
