IRC logs for #openttd on OFTC at 2024-01-22
⏴ go to previous day
00:01:38 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
03:17:18 *** Wormnest has joined #openttd
03:28:29 *** Wormnest has quit IRC (Quit: Leaving)
03:38:35 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
05:01:43 *** HerzogDeXtEr has joined #openttd
05:08:06 *** HerzogDeXtEr1 has quit IRC (Ping timeout: 480 seconds)
06:18:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:12:31 <DorpsGek> - Add: summary for week 03 of 2024 (by OpenTTD Survey)
07:31:59 *** ChanServ sets mode: +v tokai
07:38:55 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:40:01 *** pickpacket has quit IRC (Ping timeout: 480 seconds)
07:51:10 <truebrain> The difference in the amount of settings between JGRPP and vanilla is funny to observe 🙂
08:08:13 <reldred> more settings we want MORE settings
08:08:19 <peter1138[d]> Jgrpp pruned them down to sanity?
08:14:35 <truebrain> in other news, vanilla finally had a busy week with enough reports to report about it 🙂
08:15:12 <truebrain> and the JGRPP playerbase totally shifted this week to mostly Germans 😛
08:24:56 <reldred> yeah I been distracted playing other vidya games 😛
08:25:46 <reldred> and by other video games I mean "thirty minutes of starfield and then spend the rest of the day on ebay looking for minidisc players"
08:27:33 <reldred> I did snag a black Sony RH1 for an absolute steal though
08:28:34 <reldred> both the oled screens even still work!
08:48:55 <emperorjake> I don't think I've ever seen a minidisc in my life
08:49:11 <wensimehrp> survey-summary[bot]v: ```
08:49:22 <emperorjake> truebrain: what did you want me to test? 🙂
08:50:03 <reldred> emperorjake: They're super neat
08:50:09 <reldred> I've been really enjoying them.
08:50:27 <emperorjake> All I know about them I learned from the Techmoan video
08:51:09 <truebrain> emperorjake: If you can compile the latest version of my survey-branch, and then ...
08:51:35 <truebrain> contains binaries which should be signed and working. That is, they are signed so OpenTTD can load them; they are not signed that MacOS doesn't give you a nag screen 🙂
08:53:20 <truebrain> what I expect to happen is that MacOS gives you a popup, but in-game it loads fine
08:53:37 <truebrain> (as in, no "Invalid Signature" error)
08:58:16 <peter1138[d]> Bah, can't do this, early breakfasting today 😮
09:00:29 <peter1138[d]> Does NML let you define your own flag values?
09:01:26 <peter1138[d]> Oh, not even sure how the built in flags work.
09:05:12 <peter1138[d]> I mean for NewGRF properties that are bitmasks.
09:05:24 <peter1138[d]> Flags on sprites are a bit more fixed.
09:07:16 <locosage> not if you look at grf-py xD
09:12:18 <peter1138[d]> I don't think fridaemon is using grf-py.
09:13:22 <locosage> it's just custom sprite properties are the latest addition in grf-py
09:13:55 <peter1138[d]> I wonder if it can support my svg extension 😄
09:14:19 <peter1138[d]> (I've never tested it, because I couldn't make grfcodec or nmlc support it...)
09:14:23 <locosage> grf-py? I though we discussed that already, shouldn't be hard to add
09:14:34 <peter1138[d]> We did, but I didn't put any effort into it.
09:15:35 <locosage> I can try to make a simple newgrf if you tell me how it's encoded
09:21:57 <wensimehrp> 666 has a different meaning in the Mainlands
09:22:29 <truebrain> I think it is totally irrelevant; spam is spam 🙂
09:33:03 <locosage> and what branch to test it on?
09:33:25 <peter1138[d]> I have not pushed a branch yet.
09:34:34 <locosage> ok, I'll just do something I guess...
09:34:43 <locosage> is it ok if it just actiona replaces some gui sprite?
09:34:58 <locosage> also, does it need pixel alternatives?
09:34:59 <peter1138[d]> Replacement of GUI sprites is basically the intention 🙂
09:35:28 <peter1138[d]> Ah, doesn't compile. Oh dear.
09:35:52 <peter1138[d]> SpriteCollection
09:38:39 <peter1138[d]> Hmm, it does weird stuff that I don't remember writing 🙂 Basically renders all zoom levels so that it's svg-scaled instead of pixel-scaled.
09:39:50 <peter1138[d]> Fixed that, but this code is highly unlikely to work.
09:42:26 <peter1138[d]> Anyway, better get on with real $work :p
09:45:20 <locosage> so tldr I probably can't use it for testing?
09:48:02 <locosage> also, do you have any svg I can use somewhere?
09:49:14 <locosage> though I guess making my own will be a better test xD
09:57:12 <peter1138[d]> You could try, it might work 🙂
09:57:26 <peter1138[d]> But you'll be the first person trying it.
09:58:12 <peter1138[d]> I've tested svg before but it was done as a font cache instead, but then Zephyris' negated the point of that 😄
09:58:57 <emperorjake> truebrain: I am getting "invalid signature" error on both of them
09:59:13 <peter1138[d]> I think the idea of reserving zoom level is to be able to provide different svgs for different zoom levels, but not implemented.
09:59:52 <peter1138[d]> But there's probably a way of making an svg itself zoom-level aware (changing dpi or something)
09:59:56 <truebrain> emperorjake: bah. In the console it is a bit more specific why .. mind copying that?
10:00:14 <peter1138[d]> It's because Apple wants more fees.
10:01:34 <truebrain> okay, it cannot find the signature file; those files aren't in that folder?
10:01:47 <truebrain> it basically uses the location of the dylib, and next to it should be the dig
10:01:53 <emperorjake> no, I used the installer and they're not there
10:01:55 <truebrain> but that folder structure you show is unexpected
10:02:15 <truebrain> the Install script doesn't copy them
10:02:19 <truebrain> can you copy them manually for now?
10:02:28 <truebrain> I will fix that Install issue later 😄
10:02:40 <emperorjake> The folder looks like this
10:02:55 <truebrain> yeah, okay; please copy the .sig from the dmg to that folder too 😄
10:03:12 <truebrain> I forgot MacOS had an install script 😛
10:05:15 <_zephyris> peter1138[d]: SVGs come with a bunch of metadata about size and resolution. Some standard, some vendor/program specific. Wouldn't trust it an inch 😉
10:07:05 <peter1138[d]> No, that's why I pass the size and offsets outside of the svg data.
10:07:43 <peter1138[d]> But if I tell the renderer to render a specific dpi, then in theory it should be able to adjust line thickness automatically, etc...
10:07:55 <peter1138[d]> But not sure it's even necessary 😄
10:08:05 <peter1138[d]> First step: Get an svg rendered at all!
10:08:39 <peter1138[d]> locosage: this spec is likely to need changing, there's no provision here for the colour remap layer.
10:10:04 <emperorjake> truebrain: I did that, it's still not behaving. Now it says "requested to be unloaded"
10:10:14 <truebrain> yeah, that is expected
10:10:17 <_zephyris> Arguably solving the wrong problem though? Grf support of bitmaps for fractional scales would be pretty much equivalent?
10:10:25 <truebrain> but it no longer gives an invalid signature? Good!
10:10:38 <truebrain> emperorjake: Sorry, forgot to add that it can't connect to Discord, and will unload itself 😛
10:10:46 <truebrain> Steam should work if you place that magic steamdb file
10:10:54 <truebrain> but if they load, that is what I was going for 🙂
10:10:59 <truebrain> means signature validation succeeded
10:11:01 <emperorjake> The steam one says "failed to initialise" but I think that means it's messing the steam ID file
10:11:09 <truebrain> yeah; but awesome, this is what I wanted to know
10:11:16 <truebrain> 1 mistake, in the Install script, but the rest is working \o/
10:11:19 <truebrain> thank you very much!
10:11:21 <emperorjake> good enough then 🙂
10:11:25 <peter1138[d]> _zephyris: not really, different problems. This still only allows power-of-two scaling, just the image data is from svg instead of bitmap.
10:11:54 <peter1138[d]> This does make providing fractional scales simpler though, because you only need one svg.
10:12:22 <peter1138[d]> I have a separate branch for fractional scaling, and... it runs but doesn't work yet, shall we say 🙂
10:12:36 <emperorjake> truebrain: I still got the popup in MacOS though so I had to manually open the files so they would be allowed to run
10:12:44 <truebrain> yeah, I told you you would 🙂
10:12:50 <truebrain> I didn't MacOS sign the binaries 🙂
10:13:11 <emperorjake> sounds very convoluted
10:13:26 <truebrain> system on top of system on top of system on top of system on top of ....
10:13:36 <truebrain> but I got all wires connected it seems 😄
10:14:10 <truebrain> now the next challenge of the day, is figuring out why my EPSG 4326 -> 3857 is not returning values I am expecting
10:18:40 <peter1138[d]> Might just trash the sprite cache and the encoding system.
10:19:21 <peter1138[d]> 'Optimized' carefully pack all possible zoom levels into one blob of data, storing offsets between different zoom levels. Not going to work with fractional scaling.
10:29:27 <locosage> trying to free some space to build that branch atm xD
10:29:40 <locosage> openttd takes like 2gb to build
10:30:47 <locosage> and unfortunately new laptop doesn't mean larger drive nowadays
10:30:53 <peter1138[d]> 1.3G ./build + 552M ./.git, 47MB ./src.... yeah.
10:31:38 <peter1138[d]> Oh just your build is 2G... oof.
10:32:20 <locosage> oh, because debug build probably
10:32:28 <peter1138[d]> openttd and openttd_test are 164M / 172M respectively, for me.
10:32:36 <peter1138[d]> That's a big binary.
10:33:23 <peter1138[d]> Nearly 17MB for the .pch file.
10:33:55 <peter1138[d]> And then, yeah, all the unstripped object files.
10:34:21 <peter1138[d]> I should use tmpfs for this 😮
10:34:29 <peter1138[d]> Save on SSD wear & tear.
10:35:06 <peter1138[d]> I had an out-of-date docs too, that's 200MB.
10:36:40 <peter1138[d]> Frinnford (pop 3,877) has 5 theatres, 4 cinemas and 1 stadium. Nice.
10:37:34 <peter1138[d]> Starting the game in later years does make towns a bit weird.
10:48:33 <LordAro> peter1138[d]: i'd be surprised if your SSD usage was anywhere close to the maximum writes
10:49:12 <peter1138[d]> Doesn't take much for 1 misconfiguration to spew writes...
10:49:25 <LordAro> we burn out NVMe drives in about 18 months at work because our build/test process is exceptionally write heavy
10:49:40 <LordAro> i'm talking >100GB per build
10:49:48 <LordAro> which it does several times a day
10:50:14 <LordAro> OTTD is orders of magnitude less than that
10:56:53 <xarick> with the current code structure, it's difficult to know the yellow line aqueduct is also cross-region
10:57:49 <xarick> it could be cross region towards the NW side
10:58:11 <peter1138[d]> if (aqueduct length > region size)...?
11:00:37 <peter1138[d]> (if that is the right condition, then a more efficient check is "did we reach the other end in less than region size", which allows an early short cut instead of having to traverse a 100 tile bridge)
11:01:04 <peter1138[d]> ((But test logic before optimizations))
11:01:44 <peter1138[d]> So glad Christmas is over. Finally no more Christmas chocolate.
11:01:53 <peter1138[d]> Just... er... Easter chocolate now.
11:03:07 <xarick> hmm, gonna experiment something ,brb
11:04:05 <LordAro> computer definitely feels more stable when i run prime95 on half the cores
11:08:01 <xarick> think! How do I do this without using aqueduct traversability bits
11:09:06 <xarick> more checks on the edge tiles, hmm
11:12:36 <locosage> peter1138[d]: well, it loads but sprite doesn't show up
11:12:46 <locosage> idk maybe I'm doing svg "wrong"
11:12:54 <locosage> what are w/h supposed to do for svg?
11:16:06 <xarick> is that gonna be the new toyland?
11:16:29 <locosage> everything but toyland xD
11:18:15 <xarick> good looking graphs, quite simple, really, it would fit the toyland theme
11:21:04 <peter1138[d]> Hmm, your svg file is empty in that archive.
11:21:40 <locosage> oh, lol, disk space issues xD
11:22:42 <peter1138[d]> I know it's commented out but are the parameter orders meant to be different? `16, 16, 0, 0` vs `0, 0, 16, 16`
11:24:40 <locosage> it's x,y,w,h for FileSprite
11:24:59 <locosage> svgsprite has no x,y
11:25:38 <peter1138[d]> Ahhh, position within the shared sprite file.
11:26:01 <gwit> least congested melbourne tram corridor
11:29:29 <peter1138[d]> Technically an svg sprite sheet could work but would need a different data structure to share the svg contents.
11:30:53 <locosage> that's something for grf compilers to figure out I think
11:31:05 <locosage> it's not like openttd supports raster sprite sheets internally
11:31:33 <locosage> though maybe it should...
11:31:39 <locosage> at least compress it all together xD
11:33:54 <locosage> I fixed svg but that didn't seem to make any difference
11:35:51 <peter1138[d]> An A4-size svg might be the problem. Not sure.
11:36:19 <locosage> well, idk how you handle them and what's the correct size is...
11:36:47 <locosage> so I just chose the default inkscape gave me
11:39:09 <peter1138[d]> I wouldn't be surprised if it's expecting `width="16px" height="16px" viewBox="0 0 16 16"` but not sure how to make sodipod...inkscape do that.
11:39:25 <peter1138[d]> You could try drawing something in the upper left corner 🙂
11:39:34 <peter1138[d]> xarick: yes, check debug.h
11:41:58 <peter1138[d]> locosage: openttd asks for 96 dpi, so that would be ... the top-left 3.175mm I think.
11:42:21 <peter1138[d]> Okay. Well I guess it might just not work 😄
11:42:31 <peter1138[d]> Can you send the grf file over? 😄
11:44:26 <peter1138[d]> I guess an encoder could benefit from an svg linter & minimizer, but that's for a later step.
11:48:00 <locosage> some kind of gzip compresion wouldn't hurt either
11:50:01 <locosage> oh, there is even .svgz
11:50:27 <xarick> hmm Kuhnovic has the right idea, less time needed
11:50:44 <xarick> only a 100 ms increase
11:51:16 <xarick> but what about intra-aqueducts
11:55:45 <xarick> he's lucky! no aqueduct traversability bits required for intra aqueducts, but what about a cross-region aqueduct going into the opposite direction
11:58:20 <xarick> the bit is set, a connectivity exists, though neighbours might be added twice
11:58:36 <xarick> but that was already a problem, so wtv
12:07:01 <locosage> "FLIF development has stopped since FLIF is superseded by FUIF and then again by JPEG XL,"
12:07:05 <locosage> they sure change quickly xD
12:08:29 <xarick> isn't it traversibility?
12:08:35 <xarick> traversability is a typo?
12:09:46 <peter1138[d]> Main issue... I had set my blitter to 8bpp for some other testing...
12:10:54 <locosage> at least libjxl seems active, last commit 2 hours ago xD
12:11:23 <peter1138[d]> Branch is updated with bug fixes.
12:12:56 <peter1138[d]> Main issue is I mistakenly translated by w & h instead of starting at 0,0 (svg font cache version used a sprite sheet and used the translation feature) and it assumed size was 4x zoom, not 1x zoom. 1x makes more sense.
12:13:34 <peter1138[d]> Also could use the 32bpp to 8bpp conversion to make an 8bpp sprite.
12:16:50 <peter1138[d]> Not sure how to do colour remap parts at the moment either.
12:17:50 <peter1138[d]> locosage: Those flag graphics seem well suited for SVG but I know they're pixel drawn... ah well 🙂
12:18:17 <peter1138[d]> Thanks dP, you made my proof-of-concept work 😄
12:19:56 <peter1138[d]> Optimized linted version of that svg
12:20:06 <xarick> PR went a totally different approach
12:20:13 <locosage> peter1138[d]: yeah, well, maybe nanapipirara will consider doing vector version once it works
12:20:59 <peter1138[d]> (Using a tool called svgo)
12:21:33 <locosage> I did a quick googling and there seems to be an unholy amount of svg optimizers...
12:21:34 <xarick> trailing white space 🙂
12:21:49 <peter1138[d]> There are... that was one I had installed as I previously used it scripted.
12:22:02 <peter1138[d]> A lot of "svg optimizers" are "upload this to the web and we'll optimize it for you"
12:22:51 <xarick> why wouldn't the commit checker automagically remove white spaces for me
12:23:08 <peter1138[d]> Because the commit checker does not modify commits.
12:23:58 <peter1138[d]> Hmm, I wonder for colour remaps, instead of 0xFE I could use a value that lets the lower sprite colour components be used. it could be two svgs
12:24:03 <xarick> it's complaining just for thesake of complaining
12:24:15 <peter1138[d]> No, it's complaining because we have strict code style rules.
12:25:10 <xarick> fine, I'll do it myself
12:27:19 <peter1138[d]> I've viewed repos without code style or commit style rules... they're generally a shit show.
12:27:46 <peter1138[d]> Random white-space changes all over the place as different editors are set up differently...
12:31:37 <xarick> perhaps this new tic toc dude is giving me different times as before
12:32:10 <locosage> I changed size to 18x18 and it started doing this...
12:32:48 <locosage> blue rect is exactly 18x18 on outer border
12:38:14 <locosage> also, doesn't scale with fractional ui size steps, dunno if that's intended behavior
12:40:29 <peter1138[d]> It won't, the blitters are still limited to powers-of-two.
12:42:29 <peter1138[d]> 18x18 is odd, I'd possibly expect a 1-scaled pixel border with the image in the top left. Hmm.
12:42:36 <peter1138[d]> Er, 2-scaled pixel.
12:42:42 <peter1138[d]> Border bottom/right.
12:43:03 <peter1138[d]> Hmm, was that the svg set to 18x18 or the grf size set to 18x18?
12:43:24 <locosage> tried with 16x16 svg at first but same result
12:58:33 <peter1138[d]> Oh right the blue box is part of the svg.
13:09:34 <peter1138[d]> I think that's a bug in PadSprites!
13:10:02 <peter1138[d]> Normally nobody provides sprites that are zoomed out more than 1x.
13:10:16 <peter1138[d]> When you do, the padding calculation gets confused.
13:11:26 <peter1138[d]> 72 / 32 = 2.25 > 3
13:15:29 <peter1138[d]> Workaround pushed.
13:16:13 <peter1138[d]> That is something that would happen if any GRF (base or new) provided zoomed out sprites.
13:16:41 <peter1138[d]> It would be correct to render them all as SVG though, but... meh
13:17:16 <peter1138[d]> Those icons are 20x20 btw 🙂
13:21:15 <peter1138[d]> Yeah PadSprites ensures all provided sprites are multiples of each other, but probably shouldn't do that beyond 4x zoom out (1x normal zoom) as they are going to be "off" anyway.
13:21:23 <locosage> oh, I wondered what's the easiest way to see size of the sprite
13:21:33 <locosage> in the end just measured fast forward and it's 18 px
13:22:21 <merni> just trying smooth scrolling... it appears it does 2 different things: (1) scroll instead of jump when clicking on smallmap or "centre map on this" buttons and (2) adds some kind of small delay when you release an arrow key before the scrolling stops
13:22:29 <merni> why are both lumped together?
13:22:45 <peter1138[d]> It's the same thing.
13:22:50 <locosage> would be useful if sprite aligner showed width and height btw
13:22:56 <locosage> also local sprite id in grf
13:23:19 <peter1138[d]> It would, but it doesn't. You do get a bounding box shown now at least.
13:26:53 <merni> also I didn't really think about it but I have unconsciously gotten into the habit of holding shift while scrolling the map
13:27:14 <talltyler> Sorry truebrain , had to fix a conflict in saveload.h 🙂
13:28:14 <truebrain> I trust that is all you did
13:28:48 <talltyler> We're too productive and keep merging stuff that creates conflicts 😛
13:29:06 <talltyler> 200% raises for everybody when 14.0 releases?
13:29:21 <peter1138[d]> merni: There is no "separate delay". It is "move viewport to x, y and take a small bit of time to get there", it's the same in both cases, but with a larger move it takes more time of course.
13:30:42 <peter1138[d]> And if the delay between releasing the arrow key, and the scroll stopping is noticable, then... you might be using a version before the latest changes where the speed was a bit lower.
13:30:57 <merni> I am testing on 13.4 yes
13:31:13 <peter1138[d]> It's still not high, but it's less now.
13:31:17 <truebrain> in the latest you still notice it btw; but that is also why it doesn't make you want to puke 😛
13:31:35 <truebrain> I have been breaking my head over making the `/ 4` time-dependant, but I think I finally know how 😄
13:31:43 <truebrain> first day-job ... 😛
13:31:45 <merni> truebrain: does non-smooth have that effect? I never noticed but perhaps :p
13:32:00 <truebrain> merni: with non-smooth and without shift, arrow-movement is the worst
13:32:13 <truebrain> the difference is not high enough that your eyes can track, but not smooth enough that they jump around
13:32:16 <truebrain> it is a really bad experience
13:32:24 <merni> Idk I have always used that so far and not really worried about it
13:32:28 <peter1138[d]> non-smooth is isn't, but stutters.
13:32:52 <merni> that is the reason why I learned to hold shift I guess lol
13:32:55 <truebrain> with shift the distance is high enough that your eyes have less of an issue with it
13:33:08 <truebrain> but with smooth scrolling all those issues go away
13:33:20 <truebrain> it just no longer is instant
13:33:32 <peter1138[d]> I wonder how slow this svg rendering is 😄
13:34:09 <truebrain> I am sure you will cache it 😛
13:35:04 <peter1138[d]> xarick: The new TicToc time should be the same really, there's not much more to it.
13:35:23 <peter1138[d]> truebrain: It's built in to the sprite loader, so yes...
13:36:00 <peter1138[d]> It renders into a sprite, not directly into a blitter surface 🙂
13:36:41 <truebrain> why adding SVG support btw? (wondering out loud)
13:37:04 <peter1138[d]> 416µs for this sprite. That's quite high I guess.
13:37:11 <peter1138[d]> Why? Because... why not.
13:37:34 <truebrain> most people have a better reason, but sure
13:37:39 <peter1138[d]> Change for change sake 😉
13:38:00 <peter1138[d]> Everyone would like interface sprites to be non-power-of-2 scales.
13:38:17 <truebrain> but if you still convert the SVG to a sprite, you can't solve that?
13:38:39 <peter1138[d]> This is a step on that path -- instead of drawing each level specifically it does it for you.
13:38:43 <peter1138[d]> Yes. One step at a time 🙂
13:39:46 <peter1138[d]> What I could end up doing is having a separate pointer in the spritecache struct that points to single arbitrary-scaled sprite.
13:40:12 <peter1138[d]> So it doesn't affect the viewport sprites, and can be refreshed independently with interface scale.
13:40:34 <truebrain> so if you change the interface scaling, it "redraws" the SVG sprites?
13:40:43 <truebrain> clever little hack 🙂
13:40:48 <truebrain> avoids having to make changes to the blitter 🙂
13:41:08 <peter1138[d]> Well, major changes at least 🙂
13:41:37 <xarick> i fail at using the new tictoc 🙂
13:41:58 <locosage> it's not even a hack really, just caching svg rasterization
13:42:26 <peter1138[d]> truebrain: but we already found a 'bug' in PadSprites when zoomed out sprites are provided 😄
13:42:34 <xarick> TicToc::State state("YapfShipChooseTrack", 1); track = YapfShipChooseTrack(v, tile, enterdir, tracks, path_found, v->path); break;
13:42:49 <xarick> doesn't output me text
13:42:51 <truebrain> peter1138[d]: PadSprites is ...?
13:42:54 <peter1138[d]> You are missing `TicToc tt(state);`
13:43:16 <peter1138[d]> truebrain: tt can be whatever you like.
13:43:26 <peter1138[d]> That was to Xarick, sorry!
13:44:46 <peter1138[d]> truebrain: I was starting a reply to you first 😄 PadSprites ensures all the zoom levels of sprites fit in the same area, and expands sprites out if not. Normally GRFs only provide normal or zoomed in sprites, and it works then. But if you provide zoomed out sprites, it rounds them out too, so the final size is much larger than it should be.
13:45:07 <peter1138[d]> Probably it just needs to just stop at ZOOM_LVL_OUT_4X 🙂
13:45:39 <truebrain> Let me share with you what happens if you look at the world through coloured lenses
13:45:56 <peter1138[d]> I worked around it for now by not rendering svg beyond ZOOM_LVL_OUT_4X instead.
13:45:59 <peter1138[d]> Ooh, rose tinted!
13:56:45 <xarick> hmm nope, I still failing at using the new TicToc
13:59:11 <_glx_> static TicToc::State state("A name", 1);
13:59:45 <_glx_> the `static` is important
14:01:06 <_glx_> the new TicToc usage is similar to modes in AI/GS
14:02:07 <xarick> well, there's something different between now and then
14:02:19 <xarick> the whole map is not initialized
14:04:05 <peter1138[d]> Don't think that's TicToc related 😄
14:04:57 <talltyler> It's time for time 👀
14:06:10 <xarick> because now the map is not initialized, it spikes on the first attempt
14:06:44 <peter1138[d]> Oh you mean the water regions are not initialised, not the map itself 😄
14:06:52 <xarick> yes, the regions yes, that
14:09:15 <xarick> a bit all over the place
14:10:03 <xarick> need to test without my fix, i don't think it's me causing that
14:18:11 <xarick> need to check my nearest depot, it's possibly gonna be even worse
14:18:27 <talltyler> truebrain: #11603 is next, then #11341
14:18:36 <_glx_> half a second to initialise is not that bad
14:19:04 <talltyler> I tested #11603 in my test game and both AI and GS work fine in the compatibility mode using economy time. I don't have a GS to test calendar mode.
14:19:10 <_glx_> definitely fine for that size
14:19:30 <xarick> well, it used to be 3000
14:19:40 <xarick> but everything was almost ready
14:20:02 <xarick> nearest depot however... doesn't have the destination
14:20:10 <xarick> it's gonna search many more areas
14:21:28 <peter1138[d]> One issue with ship AIs now is they might use a slow pathfinder to determine what is reachable.
14:26:03 <peter1138[d]> ^ Can't change it in single player?
14:28:58 <_glx_> oh no, I can't start openttd
14:32:05 <xarick> it should be changeable anywhere
14:32:31 <xarick> doesn't have side effects
14:32:47 <peter1138[d]> Well I can understand a network client not being allowed to 🙂
14:32:58 <peter1138[d]> Though it wouldn't affect anything, of course.
14:33:00 <xarick> ah yes, the server only
14:33:09 <peter1138[d]> So even then, actually...
14:33:25 <truebrain> talltyler: Maybe you can bribe _glx_ to look at the AI PR. Pretty sure he knows more about it than I do at this point 😄
14:33:26 <xarick> the server runs the AIs, it's still synced to every client
14:33:49 <peter1138[d]> No, the client doesn't care about opcodes 🙂
14:35:33 <_jgr_> xarick: Changing it does have side effects, there's some small amount of extra code needed for changing it when scripts are running to work properly
14:36:25 <xarick> i had a variable max op codes branch, never had issues
14:36:44 <xarick> it was constantly constantly fine tunning op codes
14:36:51 <xarick> as the game progressed
14:40:35 <xarick> i was an attempt to make the scirpts combined perform under a certain ms threshold
14:41:10 <xarick> it kind of worked okay, not perfect, cus i fail at maths, but it looked promissing
14:41:27 <xarick> it achieved nearly playable framerates
14:45:21 <peter1138[d]> Thread-per-squirrel-instance yet? 😄
14:46:27 <truebrain> Let me say it for once: I do have a draft patch for that
14:46:52 <truebrain> As Squirrel can only read from the map-state, and only either queue (via async) or execute a single command
14:47:17 <truebrain> while executing commands AIs can block each other, but that was already the case
14:47:25 <truebrain> so nothing actually changes how AIs work and behave
14:47:29 <truebrain> just ... in parallel 😛
14:47:44 <truebrain> and because it is in a thread, it is also easier to deal with other stuff, like time allocation
14:48:37 <peter1138[d]> And it'll be ready for 14.0!
14:48:57 <peter1138[d]> And it'll be ready for 15.0!
14:51:53 <xarick> it's outdated but, there
14:54:30 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:01:59 <_glx_> original_dos: Original Transport Tycoon Deluxe DOS edition graphics. (unusable: 5 missing files)
15:01:59 <_glx_> original_windows: Original Transport Tycoon Deluxe Windows edition graphics. (unusable: 5 missing files)
15:02:11 <truebrain> are any of those files in a tar?
15:02:31 <_glx_> they are in subdir and also in tar
15:02:38 <truebrain> untar, and see if that fixes it?
15:03:05 <truebrain> I don't have original graphic files, so I couldn't test that part 😄
15:03:09 <peter1138[d]> Interesting, I've never considered putting the original basesets in a tar file.
15:04:06 <_glx_> I mean I have the files in data/ttddos, data/ttdwin, data/ttddos.tar and data/ttdwin.tar
15:04:43 <_glx_> oh and no subdirs in the tars
15:04:45 <xarick> pff... I disappoint myself
15:05:44 <peter1138[d]> Press your computer's turbo button.
15:05:53 <_glx_> hidden the tar (renamed them), no change
15:06:17 <truebrain> so it wasn't me then 😛
15:06:36 <truebrain> sadly, our debug-levels are a mess, so it is also not easy to see what is actually happening 🙂
15:06:51 <_glx_> it's weird because it used to work
15:06:59 <truebrain> but yeah, revert my tar-change first, to see if it isn't accidentially causing it
15:07:10 <truebrain> but if you moved the tar-files, that should have zero effect
15:07:41 <peter1138[d]> Yeah, basesets in subdirs does not work.
15:07:50 <peter1138[d]> I never tried that before with the graphics.
15:08:05 <truebrain> so the tars were the part that made it work, as they didn't have subfolders?
15:08:12 <truebrain> and now my change do make subfolders out of them
15:08:15 <truebrain> so now it stopped working?
15:09:41 <peter1138[d]> It works if the obg is inside the directory with the baseset. Hmm.
15:10:18 <_glx_> reset to before tar change, tars still hidden, same issue, so yeah the subdir part never worked
15:10:33 <peter1138[d]> Although then the extra file is "missing"
15:11:21 <_glx_> no orig_extra should be fine 🙂
15:12:17 <_glx_> 5 missing are the ones the TRG*
15:15:43 <_glx_> for now I'll just copy the files into baseset/
15:16:02 <truebrain> just the question is, how more people would have done what you did, and how many setups did we break? 🙂
15:16:12 <truebrain> so maybe we should look into why this stuff is so sensitive to folder structure
15:16:17 <truebrain> it should all use relative folders, tbh
15:16:59 <_glx_> music can't be in tar, but can be in subfolders
15:17:17 <_glx_> newgrf can be in tar and subfolder
15:17:36 <peter1138[d]> How do you limit which directories the baseset data comes from though?
15:17:42 <truebrain> music is the only one that cannot be in tar, yes. Because, external media players.
15:18:01 <truebrain> the rest should be pretty fluent in where it is located, and tar is just a directory (in a file)
15:18:12 <_glx_> my guess is something has been forgotten on baseset side 🙂
15:18:55 <peter1138[d]> If I download a baseset that contains a file name trg1r.grf, and unpack it, should it be found when searching for the real trg1tr.grf?
15:19:57 <_glx_> the issue only exists for original basesets
15:21:22 <truebrain> peter1138[d]: if it is in a folder, there is no issue, is there?
15:21:59 <truebrain> maybe I am misunderstanding it, but I understood that _glx_ had all original baseset files in a single folder
15:22:08 <truebrain> just not the "baseset" folder, but a subfolder of that
15:22:44 <truebrain> owh, the obg is not in the same folder as the rest of the files _glx_ ?
15:23:05 <peter1138[d]> The obg is in OpenTTD's build/baseset folder, normally 🙂
15:23:18 <_glx_> the obg is with the exe yes
15:23:27 <truebrain> ah, yes, so this is user-error 😄 Okay, no need to fix that 😛
15:23:43 <peter1138[d]> Not sure where they go when you install OpenTTD itself, but usually not in the same place as the grf files.
15:24:08 <truebrain> no, different searchpaths are often merged together
15:24:10 <peter1138[d]> `make[1]: CMakeFiles/Makefile2: No such file or directory`
15:24:12 <truebrain> so OpenTTD figures that out just fine
15:24:15 <_glx_> same with steam, obg is local to steam install
15:24:19 <peter1138[d]> `make install` does not 🙂
15:24:20 <truebrain> just relative paths need to be relative of each other 🙂
15:25:02 <peter1138[d]> I think this is very specific to glx.
15:25:14 <truebrain> let's hope so 😛 Otherwise we get a bunch of reports 😄
15:25:17 <peter1138[d]> Most people will have put the original graphics in the baseset folder.
15:25:22 <peter1138[d]> And not made a tarball out of them.
15:25:37 <truebrain> `If you want to play with the original Transport Tycoon Deluxe data files you have to copy the data files from the CD-ROM into the baseset/ directory.`
15:25:39 <truebrain> at least that is correct
15:26:14 <peter1138[d]> We only broke glx's spacebar, not everyone elses.
15:26:36 <_glx_> anyway my way was not fully working because both dos and windows have sample.cat 🙂
15:27:08 <_glx_> and they both were on "root" even if in a tar
15:27:22 <_glx_> so only one was ever visible
15:27:30 <peter1138[d]> I renamed one to samplew.cat and modified the obs 😄
15:27:48 <peter1138[d]> There's not much point though, the sounds are not different.
15:28:26 <_glx_> btw I still have most of my manually installed grf in data/ 🙂
15:29:00 <peter1138[d]> If we ever get rid of that... plague I tell you 🙂
15:29:15 <_glx_> 4 different ottdc subfolders in it
15:29:41 <_glx_> (yeah the start scan is long 🙂 )
15:30:08 <truebrain> you know what they say ... you do you!
15:30:20 <peter1138[d]> Hmm, I don't think I can specify palette index in an svg file 😭
15:31:19 <_glx_> anyway now openttd works again, I was just using an unsupported way that worked by luck
15:32:36 <peter1138[d]> But it might be possible to combine rgba and mask layers using svg id or class attributes
15:43:05 <truebrain> peter1138[d]: mind trying this? Now it should take a rather constant amount of time, no matter the load 🙂
15:43:12 <truebrain> took a bit of math 😛
15:49:07 <truebrain> ugh .... so many typos ... none of the pushes changed anything of the outcome ..... but the code looks better now 😄
15:51:21 <LordAro> ...why are there so many pointers?
15:51:45 <truebrain> if 4 are many, I worry 😛
15:52:06 <LordAro> why are there any at all?
15:52:30 <truebrain> because the code looks better this way? Just for a second consider what if this was all in a big if-statement, and was duplicated code 🙂
15:52:43 <peter1138[d]> It could be a reference, no?
15:53:07 <truebrain> owh, yeah, C++ .. I can make the * a nice & 🙂
15:53:08 <LordAro> i'm failing to see anything that can't just be a basic integer
15:53:25 <truebrain> LordAro: I challenge you to take that piece of code, put it in godbolt, and improve the readability 🙂
15:53:44 <truebrain> this is my answer to that puzzle 🙂
15:53:57 <peter1138[d]> Might be time for... a function?
15:54:04 <truebrain> how would that help? 🙂
15:54:20 <truebrain> it would still have 4 references going in 😄
15:54:24 <LordAro> maybe i'm massively missing something, but i would improve it by just removing all the '*'
15:54:37 <LordAro> (no, not the multiplies)
15:55:00 <truebrain> I always hate questions that put me in the defense; I always turn a bit childish when that happens, sorry 🙂
15:55:16 <truebrain> So I will reread your question: could it be done without the pointers?
15:55:27 <truebrain> basically, we have an X / Y pair, of which either of the two can be the largest
15:55:33 <truebrain> depending on the largest, we need to scale towards that
15:55:38 <truebrain> and then we need to set the value to the lowest
15:55:53 <truebrain> so what I do, I set a reference to hi/lo based on which ever that is
15:56:02 <truebrain> and do the (rather complex) calcualtion once
15:56:10 <truebrain> the other solution is to duplicate the whole calculation
15:56:21 <peter1138[d]> In a function? 😉
15:56:29 <LordAro> i'm really missing something massive here
15:56:33 <truebrain> I still need to swap x/y to that function call peter1138[d]
15:56:42 <truebrain> so it would still have 2 values going in, and 2 references coming out
15:56:48 <LordAro> there's no loops or other "state" required
15:56:55 <truebrain> but I agree, it should be in a fucntion, just because of the length of it all 😄
15:57:07 <truebrain> LordAro: really, this is the time to pick up the code and put it in godbolt, and try it 🙂
15:57:09 <peter1138[d]> That while looks like a loop.
15:57:33 <LordAro> that while loop is the only thing doing anything i'd consider "normal"
15:57:40 <truebrain> If my explanation doesn't trigger you with: ooowwwhhh ... x/y or y/x ..
15:57:41 <LordAro> i.e. actually taking an actual integer and modifying it
15:57:45 <truebrain> I don't really know what to add 🙂
15:58:19 <truebrain> and I would love for you to find me a cleaner alternative 🙂
16:00:05 <peter1138[d]> Hmm, and of course the problem with converting svg to 8bpp is you don't know which palette remap might be used 😮
16:04:30 <truebrain> I forgot how much I hated `int &` in functions .. totally unclear from the caller perspective what is going on
16:05:01 <truebrain> it removes the LordAro ick of "omg pointers!". They are still there, just hiding in the crowd now
16:05:47 <truebrain> oops, forgot to change while -> for
16:06:53 <truebrain> I first set count, then start a while to count down to zero
16:06:57 <truebrain> zounds like an if-in-hiding to me
16:08:14 <LordAro> i am not going "omg pointers"
16:08:22 <LordAro> i am going "why are you using pointers for basic arithmetic"
16:08:40 <truebrain> either I don't understand you, or you don't understand me, but .. I dunno 🙂
16:08:53 <truebrain> the pointers had nothing to do with arithmetic at least 🙂
16:09:08 <truebrain> lolz; I think we are both confused 🙂
16:09:17 <LordAro> i do not see why pointers are necessary to hold the values
16:09:32 <truebrain> because they are `[out]` values
16:09:44 <peter1138[d]> I guess that'll do 😉
16:09:55 <truebrain> owh, nice; that is a drastic improvement
16:10:01 <LordAro> out values? i haven't looked at whatever you've just done above
16:10:06 <LordAro> no functions involved here
16:11:04 <peter1138[d]> it was using pointers because it was operating on either x or y, depending on some other condition, but it needed the remaining code to still know which is x and which is y.
16:11:55 <peter1138[d]> The latest version as a function is more understandable anyway.
16:12:04 <truebrain> yeah, function was needed; too much dode
16:12:16 <truebrain> and `&` instead of `*`.... I keep forgetting that works for PODs too .. dunno why
16:12:21 <truebrain> but that is a me-problem 🙂
16:12:46 <peter1138[d]> Issue: it does not settle on the final position.
16:12:48 <truebrain> LordAro: and it could have worked without pointers, but then `w->viewport->scrollpos_x += delta_x_clamped;` would need to check once again whether X or Y was bigger, and assign the right value to it
16:13:59 <truebrain> peter1138[d]: wait, what? It does here ...
16:15:12 <truebrain> code-wise there should also be no way it doesn't settle
16:16:14 <LordAro> ok, that makes more sense
16:16:59 <truebrain> always remember I am a C-programmer 😛 But yeah, sorry LordAro, really did not understand your point; I hate chat sometimes .. walking by people resolves it in seconds 🙂
16:17:36 <truebrain> peter1138[d]: with my latest version?
16:17:54 <LordAro> today's been a "beating my head against a wall" sort of day too, which hasn't helped matters
16:18:17 <LordAro> "malloc_consolidate(): invalid chunk size" for NO REASON AT ALL
16:18:21 <truebrain> owh, and I only now see that at least 2 pointers were bullshit, the `delta_hi` and `delta_lo` ones .. those could have just been normal variables .. lolz
16:18:30 <peter1138[d]> > commit cfcfb54fd8ba361a06bbc27fe77b5b494158c97b (HEAD -> pr11865)
16:18:50 <truebrain> peter1138[d]: hmm, yes. Why can't I reproduce that, or reason why it happens ...
16:19:28 <peter1138[d]> I think it might be related to being right on the corner of the map, and at more than 1x normal zoom in.
16:20:32 <peter1138[d]> In master there is already an issue with scrolling at the corner of a map.
16:20:35 <truebrain> ha, I see what oyu mean
16:20:46 <truebrain> that is very interesting 😄
16:21:11 <peter1138[d]> Like it's permitted to go out of bounds briefly, with or without smooth scrolling.
16:21:21 <peter1138[d]> So it might be the target is somehow just out of bounds, and it's bouncing off it.
16:21:38 <truebrain> so might be an existing bug for a long time?
16:21:43 <peter1138[d]> I did open two extra viewports to switch quickly from one side to the other.
16:21:58 <peter1138[d]> Ish. In master it does not continue bouncing, only with your patch.
16:22:17 <truebrain> but yeah, it bounces alright
16:22:22 <truebrain> it tries to get to the point outside of the map
16:22:45 <truebrain> but why master doesn't keep on bouncing, that is odd
16:22:49 <peter1138[d]> And briefly succeeds.
16:24:01 <peter1138[d]> That DivAwayFromZero might be related, not sure what or how though.
16:24:12 <truebrain> it only happens on the left side, it seems
16:24:15 <truebrain> can't reproduce it on the right side
16:25:14 <peter1138[d]> I can bounce it with drag-scrolling in master on the right corner.
16:25:26 <truebrain> okay, happens on the left and top side, but only when going to away from the north corner
16:25:58 <truebrain> it bounces between 12 and 16 away
16:26:19 <truebrain> so it still thinks it has a distance to travel
16:26:26 <peter1138[d]> So... not really an issue with your patch, but your patch highlights it 😄
16:26:48 <truebrain> yeah, the destination is out of the map
16:26:55 <truebrain> so ... yeah ... no solution is good, at that point 🙂
16:26:56 <peter1138[d]> Yeah, I suspect something is telling to scroll by an offset without clamping.
16:27:12 <peter1138[d]> The solution is to make sure the destination is not out of the map, right?
16:27:16 <truebrain> `ClampViewportToMap` should correct it
16:27:43 <peter1138[d]> It does... at 1x.
16:27:57 <peter1138[d]> But at 2x or 4x zoomed in it does not work properly.
16:28:03 <truebrain> at 1x, as in, normal zoom? AsI bounce like a mofo at 1x 😛
16:28:19 <peter1138[d]> It is doing it there too. Hmm.
16:28:47 <truebrain> ``` /* Bring the coordinates near to a valid range. At the top we allow a number
16:28:47 <truebrain> * of extra tiles. This is mostly due to the tiles on the north side of
16:28:47 <truebrain> * the map possibly being drawn higher due to the extra height levels. */```
16:29:07 <truebrain> so we allow for it, but we don't allow it
16:29:44 <peter1138[d]> Wow that's a complex functioN 😮
16:30:29 <truebrain> setting the extra_tiles to zero does not fix the issue
16:30:31 <truebrain> so it is not that 😄
16:34:22 <peter1138[d]> No, that function always returns the same coordinate, even when it's bouncing.
16:34:47 <truebrain> okay ... so this is all kinds of weird ... `dest_scrollpos` is clamped in the viewport, but then we calculate a delta, add it to the position, clamp `scrollpos` to the viewport, and now it has to adjust to be inside the viewport
16:36:00 *** Wormnest has joined #openttd
16:36:37 <peter1138[d]> Hmm, but maybe it's not setting the clamped output pointer...
16:36:52 <truebrain> I see the `scrollpos_x` etc change
16:37:34 <truebrain> btw, the viewport coordinates are clamped EVERY frame
16:37:41 <truebrain> even if no change happened
16:38:07 <truebrain> as long as it doesn't show up in a flamegraph ....
16:38:25 *** gelignite has joined #openttd
16:38:29 <peter1138[d]> Make printf debugging hard to see though.
16:38:43 <truebrain> but really ... dest_scrollpos is inside the map
16:38:57 <truebrain> but when you add the delta to the values
16:39:16 <truebrain> shouldn't the line between those two point also always be inside the viewport?
16:41:16 <truebrain> owh, I see what happens
16:41:21 <truebrain> okay, that is a bit nasty ...
16:41:24 <peter1138[d]> One thing i notice is that scrollpos appears to be map-cordinates * 16, not pixel coordinates.
16:41:36 <peter1138[d]> So... looks like I was wrong the other day.
16:42:05 <truebrain> anyway, we are at a coordinate X/Y where we are right next to the map border
16:42:14 <peter1138[d]> But given that's the case, how do we scroll to sub-pixels?
16:42:16 <truebrain> we want to move to X+12/Y+6, which is also inside the border
16:42:25 <truebrain> due to timing etc, we move by (1, 0)
16:42:35 <truebrain> so now we go to X+1/Y
16:42:41 <truebrain> and this is NOT inside the map
16:42:50 <truebrain> X+1/Y+1 would be, as would X+2/Y+1
16:42:57 <peter1138[d]> ... does it bounce if we don't clamp to map? 😄
16:42:59 <truebrain> this bounces us back
16:43:17 <truebrain> so it is really the border we walk
16:43:26 <truebrain> the reason the older code bounced once, is indeed the Div away from zero bla
16:43:38 <truebrain> as that way, it would never move with (1, 0)
16:43:41 <truebrain> but always with (1, 1)
16:44:42 <truebrain> not clamping the viewport AGAIN solves the issue
16:45:02 <truebrain> so clamp the dest, and have faith
16:45:06 <peter1138[d]> Technically you are outside the map but... is that a problem.
16:45:16 <peter1138[d]> 1 or 2 pixels...
16:45:19 <truebrain> it appears not; and only for a short moment of time
16:45:46 <peter1138[d]> Oh wow, drag-bouncing is massive now 😮
16:46:27 <peter1138[d]> Something else is wrong 😄
16:46:39 <truebrain> I am telling you, rounding issues! 😛
16:46:52 <peter1138[d]> Heh, this is not 1 or 2 pixels now.
16:47:56 <truebrain> ``` int viewport_x = w->viewport->scrollpos_x;
16:47:56 <truebrain> int viewport_y = w->viewport->scrollpos_y;
16:47:56 <truebrain> ClampViewportToMap(vp, &viewport_x, &viewport_y);```
16:48:02 <truebrain> that removes the whole issue
16:48:31 <peter1138[d]> I think the issue is drag-scrolling isn't clamped at all.
16:48:44 <peter1138[d]> At least, feels like it.
16:49:13 <truebrain> basically what that does, is keep the viewport inside the map, while still allowing the scrollpos be slightly outside
16:50:09 <truebrain> should be save, as nobody is using the viewport scrollpos for anything other than this, basically
16:50:21 <truebrain> nobody seems to deduce what tile it is, based on that variable, for example
16:52:39 <peter1138[d]> I don't understand why that is different.
16:53:24 <truebrain> the `scollpos` value is not changed
16:53:33 <truebrain> so the delta between dest and actual position isn't changed
16:53:50 <truebrain> the issue seems to be that the clamp moves you to the center of the closest tile, or something weird
16:53:58 <truebrain> so it doesn't correct by a small bit to put you back in the map
16:54:01 <truebrain> it just bounces you around
16:54:10 <truebrain> so the delta between current -> dest changes a lot too
16:56:19 <peter1138[d]> Hmm, is it because it directly updated viewport->scrollpos, which 'confuses' SetViewportPosition...
16:56:46 <peter1138[d]> Also SetViewportPosition also seems to set the position of other windows viewports? Weird.
16:56:55 <truebrain> this is just very confusing
16:57:04 <peter1138[d]> DoSetViewportPosition...what.
16:57:26 <peter1138[d]> I've got an idea.
16:57:44 <peter1138[d]> Rip it out and start again :p
16:58:32 <truebrain> yeah, it really is `ClampViewportToMap` that bounces you out by A LOT
16:59:29 *** cjmonagle[m] has quit IRC (Quit: Client limit exceeded: 20000)
17:00:46 <peter1138[d]> viewport_gui.cpp:112
17:01:01 <peter1138[d]> Right click dragging... does not clamp to viewport at all.
17:01:27 <truebrain> yeah ... but that Clamp function is called every tick
17:01:30 <truebrain> whether you want to or not
17:02:47 <truebrain> okay, I can surpress the issue with a small modification
17:02:58 <truebrain> (in my smoothing algorithm)
17:03:10 <truebrain> basically restoring the old behaviour
17:04:36 <truebrain> see how this works for you
17:05:04 <truebrain> (basically, it now never moves (1, 0), which causes the problem, but always at least (1, 1) )
17:05:32 <truebrain> and how rounding works, X + 1 / Y + 1 is always fine, X + 1 / Y might not
17:15:50 <peter1138[d]> I just noticed the clamping also tracks terrain height 😮
17:16:03 <truebrain> "it is complicated"
17:16:09 <truebrain> so I don't want to touch this 😄
17:19:08 <truebrain> looks fine, doesn't it?
17:19:24 <truebrain> just don't do that 😄
17:19:31 <truebrain> (I hope that was already like this in master btw 😛 )
17:20:13 <peter1138[d]> That's without smooth scrolling, so probably
17:21:18 <peter1138[d]> I have a feeling it's jumping back because the viewport clamping is done in game-units (16 per tile).
17:24:41 <peter1138[d]> So you are jumped back to a valid coordinate based on the 16x16 tile grid... which is going to be weird for slopes anyway.
17:30:21 <truebrain> oof, trying to merge `DecodeHexText` with an actual hex decoder ... but `DecodeHexText` does so much more than just what the name suggests
17:50:34 <truebrain> ``` Start 52: ConvertHexToBytes
17:50:34 <truebrain> 52/61 Test #52: ConvertHexToBytes ............................................................................................................... Passed 0.03 sec```
17:52:07 <LordAro> actual unit tests?! :o
17:52:59 <truebrain> yeah ... actually something that is unit-testable even
17:55:35 <truebrain> right, fixed the bugs in those repos too
17:57:34 <truebrain> okay, now for realz 😛
18:08:52 <xarick> removed aqueduct traversability bits!
18:09:02 <xarick> it works without it now
18:10:25 <xarick> by now I mean... built on top of 11817
18:11:55 <xarick> There's something I wanted to do as separate PR
18:12:16 <xarick> though there's not really a big reason for it
18:15:03 <xarick> Combine VisitAdjacentWaterRegionPatchNeighbors and VisitWaterRegionPatchNeighbors into 1 single function with the objective of reducing neighbour node duplication
18:15:28 <xarick> less nodes fed into the PF
18:32:16 <peter1138[d]> Ugly bitmap font scaling :p
18:33:40 <xarick> not too bad when looking from a distance
18:34:21 <peter1138[d]> Not worth it with OpenTTD-Sans existing 😄
18:36:01 <xarick> crap, my aqueduct function is crashing on me
18:40:48 <DorpsGek> - Update: Translations from eints (by translators)
18:48:00 <truebrain> Owh .. auto merge ... that in this case resulted in an unneeded merge 😄
18:48:13 <truebrain> Sometimes it is useful, sometimes it is not 🙂
18:49:07 <truebrain> will GitHub understand it is a rebase? IT DOES! \o/
18:50:37 <truebrain> and tnx Rubidium, on all the work on reviewing that PR 🙂
19:01:40 <truebrain> this talltyler .. "12 minutes" .. no .. "period" .. no .. "12-minute periods" 😄 I think he is collecting them all 😄 (translations in wallclock PR .. depending on the string, you get a new way to indicate this time unit 😛 )
19:03:40 <xarick> I need to investigate further what yapf actually do with repeated nodes
19:27:19 <peter1138[d]> Not horrible for a quick mockup/hack/merge-into-production-already
19:27:36 <truebrain> done before 14.0? 😄
19:27:55 <peter1138[d]> If you like memory leaks... 😄
19:28:36 <peter1138[d]> I wanted a `std::unique_ptr<byte[]>` but `ReadSprite` returns `void *` so that's a bit hard.
19:29:12 <Eddi|zuHause> i see no problem in that picture :p
19:29:18 <truebrain> `FiosGetScenarioList` returns all scenarios found, where `FiosGetSavegameList` only returns it from the current folder ..
19:29:52 <Eddi|zuHause> consistency is for beginners. genius controls the chaos.
19:32:14 <truebrain> in our `-g` handler there is this line:
19:32:15 <truebrain> `bool is_scenario = _switch_mode == SM_EDITOR || _switch_mode == SM_LOAD_SCENARIO;`
19:32:27 <truebrain> isn't `_switch_mode` like ALWAYS `SM_MENU` there?
19:32:49 <truebrain> well, with `-e` you can set it to `_switch_mode = SM_EDITOR`
19:32:53 <truebrain> but ... the other condition ..
19:33:38 <truebrain> in case you do multiple `-g` it also changes behaviour
19:33:44 <truebrain> I .. well .. okay, what-ever
19:34:24 *** efessel has joined #openttd
19:35:36 <efessel> The public vanilla server we run typically lasts for 23 hours so it has to register with the coordinator fairly often.
19:35:56 <efessel> I got word people weren't seeing the server in the list today, and noticed in my logs this message:
19:35:56 <efessel> ``` Another server with the same invite-code registered itself. Switching to "local" game-type.```
19:36:20 <efessel> Not sure how this is possible? I only have one instance of this server running
19:37:22 <efessel> It's not a major issue - players just have to join via DNS/Ip for the next 23 hours 🙂
19:37:41 <truebrain> That line you see if a protection against two servers trying to claim the same invite code. One of the two (the older ones) are kicked off, as that is the most likely best resolvement. If you did a clean shutdown of the old server, and start a new, that should never happen
19:37:54 <truebrain> an easy way to solve it is to just type in the console to make the server public again
19:38:13 <truebrain> `set server_game_type public`
19:38:56 <efessel> oh yeah - that'll re-register with the coordinator 👍
19:38:56 <efessel> but curious if there's a way to "prevent" this from happening in the future?
19:39:14 <truebrain> do a clean shutdown, wait for a cycle or two, start a new server
19:39:30 <truebrain> the only moments I have seen this happen is if the server did a not-clean shutdown (kill, TCP termination, etc)
19:39:47 <efessel> The server does not shutdown - it hits `restart_game_year` and a new game is created
19:40:14 <truebrain> in that case, in rare cases, it can happen that the old server is registered to one instance of the coordinator, and the new server registers to another instance. In that case, in rare cases, race condition can occour. Still haven't been able to figure out when exactly
19:40:30 <truebrain> so maybe our `restart_game_year` is just too quick; it does a disconnect + reconnect
19:40:40 <truebrain> in that case, it should be rather rare for that to happen 🙂
19:41:28 <efessel> Yeah, it seems to re-use the same invite between games
19:41:37 <truebrain> it does; as it should
19:42:44 <efessel> Ok, I'll try to implement a workaround to execute a game type command if the bot sees that log message
19:42:59 <truebrain> it now happened, how often, in how many days? 🙂
19:43:10 <efessel> but like you said - it is rare, happens maybe every few months or so
19:43:22 <truebrain> I do plan to look into the coordinator issue at some point
19:43:29 <truebrain> but it just isn't high on my prio list due to the rarity
19:43:40 <efessel> yeah distributed systems & race conditions are fun, I know the pain 🙂
19:43:59 <truebrain> I think I just should add "time-since-registration" to the ticket, and kick the oldest ticket
19:44:01 <truebrain> instead of the latest
19:44:21 <truebrain> anyway, tnx for the report; let me know if it happens again
19:44:24 <truebrain> just so we can keep track
19:44:41 <efessel> should I open a github issue?
19:44:50 <truebrain> no, there is already one
19:57:03 <truebrain> lolz ... tar-files are only looked into when it is in the scenario map
19:57:07 <truebrain> otherwise they are completely ignored
19:57:10 <truebrain> kinda makes sense I guess
19:57:34 <truebrain> but it acts like it is in one directory
19:57:43 <truebrain> while it silently is looking in all scenario folders for tars 🙂
19:58:57 <peter1138[d]> Almost, but blue line 😮
19:59:48 <peter1138[d]> Much better than my previous attempt at fractional scaling though 🙂
20:04:06 <xarick> can you have an aqueduct over an aqueduct starting point?
20:21:19 <truebrain> Discord does need them! 😄
20:33:15 <truebrain> 1 approve is not like the others 😛
20:33:21 <truebrain> Tnx again Rubiduim 🙂 Much appreciated!
20:41:07 <peter1138[d]> Hmm, let me guess... this should be an option...
20:41:53 <_glx_> xarick: I guess it does like any sane PF, it discards the one with the highest cost
20:50:30 <belajalilija> bottom is prefereable
20:51:00 <belajalilija> i have mine like that
20:52:16 <_glx_> I can spot a missing sprite 🙂
20:52:49 <peter1138[d]> I've still got the svg newgrf loaded, but it's not the svg branch 🙂
20:53:36 <peter1138[d]> belajalilija: These are both at 2.75 scale though 🙂
20:54:11 <truebrain> not even a day old, and I found a bug 😛
20:54:59 <belajalilija> no idea what mine is
20:55:48 <peter1138[d]> Look like 2x without chunky bevels (heinous!)
20:58:00 <belajalilija> i like small bevels, make it feel cleaner
20:58:20 <belajalilija> changed my font too
20:58:42 <belajalilija> ubuntu i think it is called
20:58:48 <peter1138[d]> OpenTTD Sans is the new best 😄
20:59:18 <belajalilija> it does look good from what ive seen
20:59:46 <belajalilija> will it function like normal fonts and be able to use non latin letters?
21:00:58 <peter1138[d]> It IS a normal font.
21:01:30 <truebrain> really .. `SM_LOAD_GAME` starts a game, but `SM_LOAD_SCENARIO` starts the editor ... and `SM_START_HEIGHTMAP` starts a game
21:03:19 <peter1138[d]> Oh, I've just realised why this build keeps crashing.
21:03:36 <peter1138[d]> I added a check to make sure it's not allocating a stupid amount of memory per sprite.
21:03:45 <peter1138[d]> Because that means I mess up with scale and such like.
21:04:22 <peter1138[d]> Apparently in some sets single sprites *can* be larger than 1MB when encoded...
21:06:33 <truebrain> `Assertion 'IsInnerTile(tile) == (type != MP_VOID)' failed.` .. owh ..
21:06:52 <_glx_> 3x3 tiles sprite without split ?
21:07:07 <peter1138[d]> I'm not sure why there is a sprite that large, tbh.
21:08:07 <Rubidium> truebrain: might that be a scenario from your h2h experiment?
21:08:33 <truebrain> loading heightmaps in scenario editor is done really awkward .... and I run into that now 😛
21:09:06 <_glx_> scenario editor is really awkward 🙂
21:09:28 <truebrain> and for some reason it crashes with that error when I try to open a heightmap in the scenario editor from console
21:10:03 <truebrain> well, it also crashed from console, but it was not intentional to load a heightmap in the SE from console 😄
21:11:22 <truebrain> hmmm ... okay, something else is broken 😄
21:11:39 <truebrain> I was just opening a heightmap that didn't exist
21:12:32 <truebrain> that shouldn't crash! 😄
21:13:11 <truebrain> but yet it does .. yet it does ...
21:17:06 <truebrain> funny .. we nicely and correctly notice the heightmap is not there
21:17:16 <truebrain> and then .... owh, screw you buddy, I am just going to sit here in a corner 😛
21:18:47 <truebrain> no, bouncing is fixed 😄
21:18:53 <truebrain> you just didn't approve the PR yet:P
21:19:51 <peter1138[d]> Hmm, bilinear scaling?
21:20:07 <peter1138[d]> Nah, that'll mess up remaps.
21:20:32 <peter1138[d]> Oh, no, they're all powers-of-2 lol
21:20:48 <_zephyris> belajalilija: It has all the letters I've drawn for it, which is all Latin, Cyrillic and Greek for all European alphabet languages in OTTD 🙂
21:20:52 <peter1138[d]> I broke the sprite aligner 😦
21:21:28 <peter1138[d]> (It always draws interface-scaled sprite instead of selected zoom level)
21:23:00 <kuhnovic> Wtf, I somehow managed to add my pull request to Xarick's fork 😛
21:23:41 <xarick> my email didn't tell me anything
21:24:55 <xarick> Your master branch isn't protected
21:26:31 <_glx_> master branch is rarely protected on forks
21:27:00 <kuhnovic> I've already deleted it
21:28:55 <kuhnovic> Wow, I managed to make a screwup in a PR with changes to 2 lines of code
21:29:13 <andythenorth> peter1138[d]: pitchforks
21:29:44 <_glx_> luckily I though about checking the internal types
21:30:01 <andythenorth> flat tunnels? goes it?
21:30:15 <andythenorth> (without needing entrance slopes)
21:31:40 <xarick> uint8_t would still allow BIIIIIG areas
21:34:10 <kuhnovic> That was the mistake I mentioned
21:34:23 <kuhnovic> 2 lines of code, still managed to mess that up 😄
21:34:38 <xarick> but why one is int and the other uint
21:34:45 <xarick> that's not consistent imo
21:35:05 <kuhnovic> And that's why we have comments
21:35:32 <xarick> okay, I guess I don't read often
21:38:18 <truebrain> Rubidium: how do I edit `openttd.6`?
21:39:00 <peter1138[d]> I think that went wrong.
21:39:46 <truebrain> or do I just need to learn that format 😛
21:40:18 <peter1138[d]> groff or something? Ah troff..
21:40:26 <_glx_> maybe emacs knows it too
21:40:53 <xarick> if the pictures were high definition it wouldn't be so bad
21:40:54 <truebrain> no clue what `troff` does, but anything useful it isn't 😦
21:41:01 <peter1138[d]> There's a highligher for VS Code, so...
21:41:11 <truebrain> need a bit more than a highlighter 😄
21:41:15 <truebrain> want to know what I actually have to type 😛
21:41:29 <peter1138[d]> Isn't it obvious/ 😄
21:42:07 <peter1138[d]> Is it rather arcane.
21:42:34 <_glx_> it's better than sprite font
21:43:42 <Rubidium> truebrain: I'm just using a simple text editor, and then "man -l openttd.6" to check whether I did the right thing. Usually I can get away with copying some lines and changing them
21:44:20 <truebrain> trying to find how I can do `savegame|scenario|heightmap` 😛
21:45:43 <Rubidium> I guess you need to look at line 14
21:51:12 <truebrain> time to figure out if this actually works 😛
21:51:26 <Rubidium> maybe just generalise it, and replace savegame|scenario|heightmap with file, and in the further comments state it ought to be a savegame, scenario or heightmap
21:57:59 <xarick> should I remove the distance manhattan search for a ship depot?
21:59:01 <xarick> there may be a situation where it could be useful
21:59:36 <xarick> player is going to open up the sea to allow passage to it
22:00:39 <truebrain> _glx_: where would you like them? I already found this easy to ready, but I don't mind adding some
22:00:48 <truebrain> some people like them around the whole group, others around the comparison
22:00:51 <truebrain> so pick your poison 🙂
22:01:11 <truebrain> `case FT_SAVEGAME: _switch_mode = (_switch_mode == SM_EDITOR ? SM_LOAD_SCENARIO : SM_LOAD_GAME); break;`?
22:02:03 <truebrain> `CPack Error: CPACK_BUNDLE_ICON must be set.`
22:03:48 <truebrain> okay, so that brings the license problem back to the foreground
22:03:56 <truebrain> is now licensed under GPLv2
22:04:03 <truebrain> so I cannot add them to the MIT-licensed plugins
22:04:11 <truebrain> but I need icons for MacOS to be happy 🙂
22:04:32 <truebrain> anyone any suggestions there? 🙂
22:05:12 <LordAro> draw an approximation of it in paint
22:05:20 <jfs> do we know the authorship of the logo? can they be contacted and asked if it can be re-licensed? (otoh, a re-licensing would technically make it available for anyone to use under the least restrictive license)
22:05:45 <truebrain> not re-license, dual-license
22:05:49 <truebrain> solves that whole debacle 🙂
22:06:01 <truebrain> but I dunno how they came to be
22:06:08 <jfs> changing from a single license to dual-license is also a re-license
22:06:09 <truebrain> I once got the logo for the livestream from this Discord
22:06:18 <truebrain> although not really sure who anymore; just that I could use it for the livestream
22:06:42 <truebrain> jfs: we say the same then. As in both cases people can pick what license they want 🙂
22:06:48 <truebrain> and ofc that is the least restrictive one 🙂
22:07:38 <truebrain> okay, current icons are added by Bjarni
22:07:43 <jfs> anyway, if it's only because MacOS requires an icon in a bundle, then yeah make some kind of "dummy" icon
22:07:57 <truebrain> I do not have any clue how to make `icns` 😛
22:08:16 <truebrain> who on this Discord made the Discord logo ... hmmm
22:08:19 <truebrain> maybe talltyler knows
22:08:46 <truebrain> GIMP cannot load the `icns` ..
22:09:00 <truebrain> `openttd.icns: Mac OS X icon, 213612 bytes, "TOC " type`
22:12:02 <truebrain> can't believe how old the current icon is 😛
22:12:52 <truebrain> owh, `makeicns` on MacOS does that
22:13:12 <truebrain> so I guess I have to be very very nice to andythenorth , and see if he can help out?
22:13:52 <jfs> or possibly make it part of the build process, to assemble the icns file from input png files
22:14:13 <truebrain> I am kinda done debugging MacOS stuff via the CI; but I welcome you with open arms to make that happen 🙂
22:14:56 <xarick> ultra-wide monitor == ultra-wide horizontal code style
22:16:29 <truebrain> I also once got a version from eratonysiad .. don't know if he remembers, but do you know where you got the OpenTTD Logo from by any chance?
22:16:36 <Rubidium> that's from someone who traced the GPLv2 icons that were in OpenTTD before that
22:16:39 <jfs> truebrain: I'm already exhausted by having sorta-kinda three major features for 14.0, despite barely doing any work on them at all, other than giving a bit of advice here and there
22:16:39 <jfs> (help window written years ago, social plugins proof of concept, notdaylength concept)
22:17:33 <truebrain> jfs: just imagine writing 2 out of the 3 of those features 😛
22:17:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:17:38 <truebrain> and reviewing the 3rd
22:17:49 <andythenorth> truebrain: I can't find makeicns locally, I'll research it
22:17:55 <Rubidium> I've already spent a good while trying to find the source of the icons and couldn't find anything definitive
22:18:21 *** eratonysiad has joined #openttd
22:18:21 <eratonysiad> truebrain: The I got the older version on there, and filled in the transparent $ with white
22:18:23 <andythenorth> probably includes free malware?
22:18:42 <truebrain> eratonysiad: haha, okay, so we all recycled the same material 😄 Which is totally fine btw 🙂
22:18:49 <andythenorth> seems I have iconutil
22:19:06 <truebrain> andythenorth: would you be willing to make some MIT-licensed OpenTTD logos in icns format and 1 in png format?
22:19:17 <truebrain> (splash-screen png)
22:19:39 <truebrain> doesn't have to be pretty, etc
22:19:43 <truebrain> it just has to be MIT-licensed 😛
22:20:43 <xarick> shouldn't OpenTTD be one word in the logo?
22:20:47 <andythenorth> truebrain: totally can, but I am about to go to sleep (early start tomorrow)
22:20:48 <jfs> truebrain: I honestly wish I could put time and energy into OTTD, but other things keep taking my attention away and I hate it (too many things I want to do and too much time spent worrying about how much time I spend worrying about it instead of doing it)
22:21:25 <truebrain> andythenorth: no worries; but if you can, that would be awesome. So go sleep, enjoy the early start (ghehe, nobody ever does), and just let me know if/when you can do so 🙂
22:21:55 <andythenorth> I didn't read up for the context, but eh, can help 🙂
22:22:45 <truebrain> andythenorth: Context is simple: for the Social Plugins we need two MacOS specific icons: an App Bundle Icon (`.icns`) and a Splash (`.png`). Without it, CPack refuses to make a release 🙂
22:23:47 <truebrain> jfs: well, it also doesn't help that all three subjects are HUGE undertakings 😄 It helps to do smaller shit from time to time, like me smooth-scroll fixes .. I do those as I just don't have more time this week 🙂
22:24:07 <truebrain> that said, this social integration stuff took WAY more time than I expected. Not because of the actual work, but all the administration around it .... 😄
22:25:06 <truebrain> okay, seems only MacOS is bitching; all other OSes succeeded .. so that is promising 🙂 I guess we continue when icons arive 🙂
22:27:48 <_glx_> at least we have the artifacts 🙂
22:27:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:28:07 <truebrain> good point; I can at least test them 🙂
22:28:37 <_glx_> so where should I copy them
22:28:51 <_glx_> guess I could read the doc
22:29:01 <truebrain> that helps, as that is a check if that is clear enough 🙂
22:29:46 <truebrain> owh, should I semver these projects? So `v1.0.1` .. might be better than `1.0.1`
22:35:14 <truebrain> can't wait till you can also join each others games 😛
22:36:05 <_glx_> all my tests are done on 64x64, faster to generate
22:36:48 <_glx_> so I just extracted the zip in the folder
22:36:55 <truebrain> that is all it takes 🙂
22:37:06 <truebrain> they are both Windows signed as OpenTTD signed
22:37:20 <truebrain> (right click to see that it is signed for Windows)
22:37:35 <_glx_> the readme says to copy `lib` to a given the folder
22:37:54 <_glx_> but that's if I build myself
22:37:54 <truebrain> owh, yeah, `lib` is no more
22:38:16 <truebrain> even building yourself doesn't give a `lib` anymore I think
22:38:20 <truebrain> I removed most of that 🙂
22:39:01 <truebrain> so professional ... didn't take most of my time at all, to get all that stuff right ....... 😛
22:39:48 *** gelignite has quit IRC (Quit: Stay safe!)
22:39:55 <truebrain> the README in the repo does need a bit of an improvement in wording; will do that tomorrow
22:40:24 <truebrain> it also doesn't tell to build OpenTTD with validation disabled
22:40:27 <peter1138[d]> Aw nice, this works with the simple blitters too which don't ... technically need it because they can scale on the fly. Hmm.
22:40:37 <peter1138[d]> Oh but probably only powers-of-2 🙂
22:42:44 <truebrain> ugh, and so much more administration work to come! I kinda forgot already ... I need to update the website to correctly show all references ... add it to the nightly of Steam ... oof 😛 Don't think, just do! 🙂
22:43:03 <truebrain> _glx_: yeah, that is what I meant with "the README in the repo" 🙂
22:43:38 <truebrain> I was just afraid it also slipped in the README of OpenTTD. But it didn't. So that is good 🙂
22:45:34 <_glx_> in case someone want to link to it at build time
22:47:46 <truebrain> Yeah .. couldn't be bother to figure out how to remove it 🙂
22:48:19 <peter1138[d]> Hmm, something is not quite the same... but I think there are meant to be gaps between the letters normally...
22:49:07 <peter1138[d]> One of OpenGFX2's 'hidden' parameters 🙂
22:49:53 <talltyler> I like the Underground logo 🙂
22:51:43 <peter1138[d]> I guess it's using sprite offsets, and they're now ignored, so the normal spacing happens.
23:00:46 <reldred> They’re both gorgeous, but yeah, I dig the chrome logo.
23:09:39 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:15:46 *** ckb_ has quit IRC (Ping timeout: 480 seconds)
23:39:20 <wensimehrp> Is the web translator not working or it takes time to synchronize?
23:41:13 <_glx_> no, I also see 146 outdated strings in other languages
23:43:01 <_glx_> ah yeah they will be in next sync
continue to next day ⏵
