IRC logs for #openttd on OFTC at 2024-01-13
⏴ go to previous day
00:03:46 <peter1138[d]> Hmm, so the ZWSP works okay in the MD5 sum.
00:04:06 <peter1138[d]> But in the string it prefers breaking between 2 and cc :/
00:10:15 <_glx_> hmm it's hard to test the PR with all the "dbg: [fontcache] Font is missing glyphs to display char 0x200B in medium font size"
00:11:46 <_glx_> at least it seems to split at the ZWSP
00:13:18 <xarick> oh, there's nothing to worry about after all
00:13:31 <xarick> 811689 fits perfectly in a int
00:14:04 <xarick> 4096x4096 map size from a corner to another
00:14:36 <xarick> still wanted to know how many closed nodes it needed
00:15:28 <xarick> i think the high level pf needs to... return the FindDepotData itself
00:15:46 <peter1138[d]> _glx_: Add an exclusion for 0x200B in FindMissingGlyphs(), line 2108
00:15:55 <xarick> cyas goodnight, take care
00:20:11 *** gelignite has quit IRC (Read error: Connection reset by peer)
00:25:53 <_glx_> hmm somehow the ZWSP has been removed before it can be useful
00:27:04 <_glx_> oh of course it's the change in gfx_layout.cpp
00:44:33 <_glx_> automatic insertion of ZWSP when font changes works (except when using sprite font)
00:47:22 <_glx_> but it looks ugly to put a new line after the colon when the rest of the string will be split again on next line
00:54:47 *** geli has quit IRC (Quit: Stay safe!)
01:11:37 <_glx_> for cases like this it would be better to not respect the suitable breaking point
01:18:10 <_glx_> left is with fully disabled suitable breaking point, so of course it's bad in many places but in some places it's less ugly than the current way (on the right)
01:19:08 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:38:41 <peter1138[d]> So you think we should be using NBSP here...
02:15:49 <_glx_> NBSP would not help for chinese
03:26:41 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
03:48:44 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:09:35 *** Wormnest has quit IRC (Quit: Leaving)
04:19:42 <limyx826> Block signal in chinese is 通过信号机 according to baidu
04:20:34 <limyx826> A block is called 闭塞分区
04:21:55 <limyx826> For the record, I knew chinese however I didn't know chinese terminologies for railway.
04:34:06 <wensimehrp> Finally, some company🙂
06:05:12 <wensimehrp> I don't quite understand the translation as well as the original string.
06:06:21 <emperorjake> It's how often the cargodist graph gets updated
06:06:45 *** HerzogDeXtEr has joined #openttd
06:09:16 <wensimehrp> The translations are... misleading
06:10:33 <wensimehrp> cargo flow overlay colours was translated to "cargo distribution graph overlay colours", and cargoflow and cargodist are two different things
06:12:08 <wensimehrp> emperorjake: So, cargoflow is related to cargodist, as cargoflow shows the flow of cargos. But cargoflow could work without cargodist.
06:20:51 <emperorjake> The cargo flow graph isn't really useful outside of cargodist
06:21:11 <emperorjake> I don't think it can even go red if cargodist is off
06:29:32 <wensimehrp> but is still works without cargodist
06:31:49 <wensimehrp> Cargo flow graph was translated into "客货流" in other strings, not "货物分配图".
06:32:04 <wensimehrp> I think I'm going to correct that
06:37:34 <wensimehrp> And for "Game Options" and "Settings", I assume that "Game Options" is referred to the OpenTTD program, and "Settings" is referred to the game you're playing.
06:39:01 <wensimehrp> Well I can't really tell the difference between the two based on the words themselves.
06:40:20 <wensimehrp> I would translate them to "程序设置", which means "Program Settings" and "游戏设置", "Game Settings".
06:52:34 <Rubidium> wensimehrp: I can't even tell the difference between them; it's historically grown this way and I think most agree that it should be one window. Yet nobody actually changed it yet...
06:53:43 <wensimehrp> wensimehrp: Nah I won't change that
06:54:57 <wensimehrp> Or actually I will, if more than half of the translators in the translator group agrees
06:59:17 <reldred> peter1138[d]: I've submitted a fixed version of NARS Addon to the master of cats to upload to bananas.
07:00:55 <reldred> should sidestep the issue entirely. not sure if any other sets are (ab)using model life 0 but that's one less big one at least.
07:11:37 <belajalilija> reldred: Whats this? So i can avoid it, i know theres 2 things that relate to vehicle life in my code but idk which does what
07:12:03 <reldred> If you want it to never expire use VEHICLE_NEVER_EXPIRES instead of lifetime of zero.
07:21:32 <belajalilija> I’m guessing 0 and 255 are functionally identical
07:22:12 <reldred> Nah, there was a weird underflow bug that allowed 0 to behave like 255, but that got fixed by peter causing the need to fix nars addon.
07:31:26 *** ChanServ sets mode: +v tokai
07:38:25 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:17:07 <andythenorth> any cheat mode that can switch time on a running game? 😛
08:26:06 <Rubidium> andythenorth: it might be a bribeable mode ;)
08:27:31 <andythenorth> considered trying to round trip it via scenario edit .sav / .scn switch 😛
08:42:58 <andythenorth> my GS is quite confused about dates 🙂
08:44:14 <andythenorth> in a non-wallclock game, looks like 🙂
08:45:31 <andythenorth> my GS main loop is broken in Wallclock, such things 😄
08:46:03 <wensimehrp> make it [eco period - minutes - seconds]
09:32:15 *** NGC3982 has joined #openttd
11:40:53 *** D-HUND is now known as debdog
11:49:23 <michi_cc[d]> For the small font in #11593, I've included OpenTTD-Small.ttf right now, but zephyris also made an all-caps version. While this would be more true to the original sprite fonts, I'm not sure it is actually better for readability. Thoughts?
12:03:06 <kuhnovic> Do you have a screenshot for comparison?
12:09:22 <kuhnovic> I find both the all caps and non-all-caps equally unreadable 😛
12:11:13 <kuhnovic> Although I guess all caps would clutter up the mini map slightly more if you have town names visibile
12:11:34 <_zephyris> The small font currently "breaks the rules" too, it's actually 7px in disguise as a 6px font.
12:11:53 <_zephyris> It's the one that would benefit most from more work
12:12:14 <_zephyris> kuhnovic: Original graphics is all caps...
12:12:28 <Rubidium> michi_cc[d]: what about just including both, but using the not-all-caps version? Then it's fairly easy for the user to change that. Then after this PR one might consider adding a "I want a more legacy experience" setting that also disables all but the TTD signals ;D
12:12:28 <michi_cc[d]> All caps looses the distinct letter shapes which is why I think normal caps is better IMHO.
12:13:34 <michi_cc[d]> Rubidium: Would need some special-casing in the platform font code though, because normally the font name from the setting is passed to the OS and that woudn't know about the font files we ship.
12:18:49 <truebrain> anyway, some in-game shots would really help understanding the difference I think
12:19:01 <truebrain> as in: sprite -> uppercase -> mixed case
12:24:28 <truebrain> and if you like, we could make it a Discord poll, asking a broader opinion 🙂
12:33:42 <xarick> if (m_veh != nullptr) {
12:44:06 <truebrain> lol, funny how different it looks 🙂
12:44:06 <michi_cc[d]> This is all on 1x zoom, as with larger font sizes it generally is better reable no matter which font.
12:44:35 <michi_cc[d]> Unfortunatly Discord likes to zoom/rescale it in the client.
12:45:18 <michi_cc[d]> The all caps version is definitely the one to go for the original look.
12:46:22 <michi_cc[d]> But especially as you start to increase the GUI/font size even slightly, regular caps is IMHO more reable than all-caps as you still have the distinct letter shapes the brain is used to.
12:46:41 <peter1138[d]> Many people are used to opengfx which is not small-caps
12:47:20 <peter1138[d]> Eh all-caps not small-caps
12:47:40 <truebrain> I would go for TTF normal, simply because that is what we are all used to in 2024
12:48:11 <michi_cc[d]> Well, luckily for me that is what is in the PR right now 🙂
13:19:34 <truebrain> another bug that would be gone if we replace fullscreen with maximized borderless 😛
13:20:45 <peter1138[d]> Well, I have an Nvidia card, and 2x 2560x1440 screens, so...
13:20:46 <reldred> or at least add that as an option 🙂
13:20:49 <truebrain> reldred: PRs are -----> that way 🙂
13:21:03 <truebrain> peter1138[d]: most of the time, in my experience, it is an X11 issue, more than anything else
13:21:08 <reldred> oh no no, you don't want me touching that part of the code :-b
13:21:17 <truebrain> that 13.3 works and 13.4 doesn't is odd, as ... well .. only dependencies were updated 😛
13:21:52 <reldred> I'll manage to stuff up something so badly your house is liable to catch fire just looking at the PR
13:30:58 <_glx_> yeah the driver does weird things with resolutions and startup display
13:39:26 <xarick> oh Im doing something much more complex 😮
13:40:27 <kuhnovic> Yes haha. My solution is quite simple. IMO it's better to go for something simple that works well enough in 99% of the situations.
13:43:34 <kuhnovic> But for example a situation like this would not be resolved correctly. The ship would choose the southmost depot, which is obviously much further away.
13:44:10 <kuhnovic> In my defense, that what it did before my changes as well 😛
13:45:23 <_glx_> ah it opts for the "local" depot
13:46:52 <kuhnovic> Yup. I tried to use BFS to search for the region with the closest depot. That works, but the closest region doesn't equal closest depot... not AT ALL
13:47:45 <_glx_> that's correct if there's a path within the region
13:49:19 <truebrain> kuhnovic: please put this, with image, in the PR as limitation. Helps in case someone in 5 years goes: THIS IS A BUG 😛
13:49:47 <peter1138[d]> Well, it is a bug 🙂
13:49:50 <michi_cc[d]> Would it be possible and practical to use the regions to find the two (or three) closests depots and then do a proper pathfind to decide between them? I do realize that you can still construct bad examples with this, but it should help for the most pathological cases.
13:49:54 <xarick> I'm working on an alternative, still wip
13:50:03 <peter1138[d]> But the PR addresses another issue, not the issue of not finding the nearest the depot 🙂
13:50:24 <_glx_> yeah at least it finds a reachable depot
13:50:42 <truebrain> peter1138[d]: that is why I would be fine with such PR 🙂 It solves the biggest problem, so ... 😄 But at least mentioning this information there helps 🙂
13:51:24 <peter1138[d]> True. Something like "This PR does not address finding the nearest depot, only that the depot found is reachable"
13:51:34 <peter1138[d]> Although in extreme cases that may actually be worse 😄
13:51:35 <truebrain> and the image; the image helps 🙂
13:52:20 <xarick> my solution takes a whole different approach
13:52:56 <xarick> for short distances, it calls the low lvl pf
13:53:02 <xarick> skips the high lvl entirely
13:54:33 <peter1138[d]> If you're skipping the high level pathfinder, you're probably taking the wrong approach then 🙂
13:55:06 <xarick> no, I added a max_cost penalty for the high lvl pf
13:56:26 <_glx_> might be possible to put the "closest" as starting nodes for a pf run to the ship
13:56:30 <xarick> im now in the process of getting the walkable cost to the nearest depot in the region to the the tile the region was entered from
13:57:02 <xarick> but aqueducts... arf, that's gonna complicate a bit
14:02:34 <kuhnovic> Aqueducts ... the bane of my existence
14:03:37 <kuhnovic> They were always the thing that broke the region pathfinder. And nobody ever uses those damn things because they are so annoying to build 😛
14:04:06 <kuhnovic> (I'm afraid TrueBrain's stats will prove me wrong here...)
14:05:50 <xarick> gotta treat the aqueduct a more than a neighbour
14:07:07 <_glx_> an aqueduct can neighbour regions very far away
14:07:24 <kuhnovic> You could also say "an aquaducts always ends in the middle of a region" or some kind of similar generalization. Again, they are not used that often. The distance calc doesn't have to be perfect, it has to be good enough.
14:07:58 <peter1138[d]> Hmm, Tahoma Bold is a weird font. At some sizes it completely loses all effort at being bold.
14:09:58 <kuhnovic> _glx_: Yup, it's almost like teleporting from one region to another. Very annoying.
14:10:20 <peter1138[d]> Not even almost 🙂
14:10:51 <_glx_> teleport but with an easy to determine cost
14:11:34 <kuhnovic> Teleport within the same universe at least
14:20:17 <xarick> how big can the hash be?
14:20:57 <xarick> 1 aqueduct per tile in the region
14:21:42 <xarick> I think 1 << 255 is unfeasible
14:41:33 <xarick> passing data around is where complexity explodes 😐
15:07:31 <xarick> i went from std::pair to std::tupple
15:07:51 <xarick> because I'm too noob to pass the node around
15:09:09 <xarick> typedef std::tuple<WaterRegionPatchDesc, DiagDirection, int> NodeInfo;
15:09:37 <xarick> NodeInfo should have another name
16:00:14 *** Wormnest has joined #openttd
16:19:43 *** gelignite has joined #openttd
16:32:52 <xarick> a callback calling back another callback
16:33:43 <xarick> feels like I'm reinventing the wheel
17:14:32 <xarick> if only I had something to show
17:53:28 <xarick> My pathological scenario
17:54:20 <xarick> it's not pathological enough
17:54:32 <xarick> it still finds the best depot to go
17:55:44 <xarick> i need a situation where the restricted path actually returns not found
17:57:43 <xarick> gonna force a low max nodes
18:06:14 <wensimehrp> How could I change this? it should be YYYY-MM-DD format
18:06:23 <wensimehrp> this is DD-MM-YYYY
18:06:53 <wensimehrp> Using zh_TW, and it is YYYY-MM-DD
18:08:23 <_jgr_> Change `STR_FORMAT_DATE_LONG`
18:24:50 <wensimehrp> `ERR_CERT_DATE_INVALID`
18:25:06 <peter1138[d]> You changed the wrong date 😄
18:38:24 <DorpsGek> - Update: Translations from eints (by translators)
18:44:22 <kuhnovic> My guess is that 3 and 1 fall in the same region. And within the region 3 is closer if you measure distance from the region on the very left. Ignoring obstacles of course, just as the crow flies.
18:45:34 <xarick> Im actually calculating the shortest manhattan distance from the edge it enters from
18:46:05 <xarick> enters the region from the SW border
18:46:24 <xarick> means DEPOT1 is closest
18:47:13 <xarick> next thing I wanna do... actually do a pf call in the final region to get the walkable closest one
18:48:50 <xarick> a PF run within a PF run, what could possibly go wrong
18:50:35 <kuhnovic> What could go wrong is that there could be a depot in a neighboring region that's closer than the one in the region you are looking at
18:56:01 <xarick> not sure how to do this... i'm gonna need a fake ship
18:57:55 <xarick> or I need another method
18:59:07 <wensimehrp> This part is too messy
19:00:49 <xarick> how do create a fake ship ppl?
19:02:00 <xarick> may have to look at trackfollower
19:08:52 <kuhnovic> Use the ship trackfollower, save yourself a lot of hassle. Don't try to build your own, there are too many edge cases
19:17:38 <kuhnovic> (I learned that the hard way)
19:40:41 <peter1138[d]> LordAro, monster!
19:50:01 <wensimehrp> why's macOS taking so long?
19:54:03 <truebrain> lol, notarizing the MacOS said: NO! With the message: "Rejected" 😄
19:54:12 <truebrain> let's hope that fixes itself tomorrow 😛
20:17:10 *** axet has quit IRC (Quit: Leaving.)
20:17:11 <Rubidium> wensimehrp: macOS builds are slow because they are actually two builds (two totally different CPU architectures) that get combined, and it doesn't help that the compiler isn't as fast as most others
20:37:48 <wensimehrp> Ah, macOS build failed
20:39:12 <peter1138[d]> Makes a change from Linux failing 😄
20:39:37 <_glx_> one fixed, another one down
20:48:11 <truebrain> orudge mentioned there was a command to dump why Apple rejected the request; maybe we should add that in the script
20:48:17 <truebrain> so we at least see why Apple rejected something
20:51:53 <Rubidium> sounds like a good plan. I doubt it's going to be solved tomorrow, as Apple says the notary service is working just fine and the retry also failed
20:52:30 <truebrain> someone with a MacOS only has to figure that out .. so I guess orudge is the person to do 😄
20:54:19 <truebrain> any commits between today and yesterday that could explain it?
21:17:51 <truebrain> that would be nasty ..
21:18:01 <truebrain> let me send orudge an email, see if he can help out
21:19:40 <truebrain> not sure how that is going to help 😄
21:19:51 <truebrain> as long as the diff in code isn't showing anything weird .. means it is not us 😄
21:22:33 <Rubidium> it might hint at other differences between runs; I only spotted a different pandoc version and the runner difference. Though here might be lurking more in there
21:22:59 <truebrain> or, Apple added some rules in the validation, and now OpenTTD violates some rule 🙂
21:23:42 <truebrain> `We're reaching out to let you know that your Apple Developer Program membership has expired as of January 12, 2024, and any content you had on the App Store is no longer available for download. `
21:23:45 <truebrain> okay, it is a different issue
21:24:33 <truebrain> `Your Apple Developer Program membership was not automatically renewed because we encountered a billing issue.`
21:30:38 <_glx_> wasn't that supposed to be already handled ?
21:30:43 <truebrain> Rubidium: try a retrigger now
21:41:17 <_glx_> oh there's still the broken WITH_ASSERT on MacOS releases
21:42:42 <_glx_> we really need someone with a mac 🙂
21:42:45 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:42:56 <truebrain> if you have an Intel, that person can be you!
21:43:01 <truebrain> VMWare + MacOS on Intel works pretty well
21:48:50 <peter1138[d]> Oh I see, £649 only gets you 8GB.
21:49:06 <peter1138[d]> Another £200 for 16GB hah
21:52:43 <truebrain> to use a tiny bit more words: orudge just fixed the Apple issue, so a retrigger should fix the nightly again 🙂
21:54:20 <Rubidium> sadly it just failed again in notarize
21:54:39 <truebrain> maybe it takes a bit of time before the administration is processed ..
21:54:43 <truebrain> so should be good tomorrow 🙂
21:55:15 <truebrain> anyway, a simple administrative oversight 🙂
21:57:26 <truebrain> `Your Apple Developer Program membership has been renewed for another year and your membership details are below.`
21:57:33 <truebrain> okay, so NOW it should work 😛
21:58:28 <truebrain> I misunderstood orudge's first message; but now I have the mail that says: should be fixed, so 🙂
22:00:20 <xarick> cannot convert argument 1 from 'Ship' to 'const Ship *'
22:01:45 <peter1138[d]> Ship is not Ship *
22:02:05 <kuhnovic> Not really, you just forgot an &
22:02:15 <xarick> if (region.GetLabel(tile) != water_region_patch.label || !callback(tile, &v)) continue;
22:02:15 <xarick> const FindDepotData depot = YapfShipFindNearestDepot(v, 0, edge_tile);`
22:02:15 <xarick> YapfShipFindNearestDepot wants a const Ship *
22:06:23 <xarick> too much horrible magic to get this to work
22:06:25 <xarick> v = Ship::Get(Yapf().GetVehicle()->index);
22:07:23 <xarick> Yapf().GetVehicle() doesn't work because it's a const...
22:08:20 <kuhnovic> You just said YapfShipFindNearestDepot wants a const Ship *, so const shouldn't be the issue
22:08:21 <Rubidium> why do you need to modify the ship during pathfinding?
22:08:57 <xarick> with const Ship v; the !callback(tile, &v) doesn't work
22:09:13 <xarick> must be a value I'm seeking
22:09:21 <kuhnovic> What does "doesn't work" mean
22:09:57 <xarick> if (region.GetLabel(tile) != water_region_patch.label || !callback(tile, &v)) continue;
22:10:24 <_jgr_> Sounds like the type signature of your "callback" needs to be adjusted
22:10:54 <_jgr_> In any case, defining a Ship on the stack like that is almost certainly wrong
22:12:38 <xarick> wow it works now... seriously?
22:23:06 <peter1138[d]> _jgr_: Never stopped him before 🙂
22:37:34 <xarick> this is bad, I don't wanna create a new ship
22:37:46 <xarick> this is calling pre destructor stuff on the ship
22:40:56 <Rubidium> still making Ships on the stack I presume
22:44:29 <_glx_> truebrain: ah yes it's fixed
22:50:21 <peter1138[d]> It's a pointer to ship, but it doesn't point to anything.
22:50:46 <xarick> the ship is retrieved from the callback
22:51:16 <xarick> or at least, that's the intented result
22:51:47 <peter1138[d]> You can just initialize it.
22:52:52 <xarick> that I tried too, doesn't work either
22:53:22 <peter1138[d]> Don't make it const then.
22:54:15 <peter1138[d]> Probably it stays nullptr because your callback is not getting called, or not changing v.
22:55:11 <xarick> using TGetTileInWaterRegionCallBack = std::function<bool(const TileIndex, Ship *)>;
22:55:50 <xarick> `using TGetTileInWaterRegionCallBack = std::function<bool(const TileIndex, const Ship *)>;`
22:57:53 <xarick> ` TGetTileInWaterRegionCallBack GetShipDepot = [&](const TileIndex tile, const Ship *v)
22:57:53 <xarick> v = Yapf().GetVehicle();
22:57:53 <xarick> return IsShipDepotTile(tile) && GetShipDepotPart(tile) == DEPOT_PART_NORTH && IsTileOwner(tile, v->owner);
23:00:32 <xarick> why does it stay nullptr?
23:01:06 <_glx_> because `region.GetLabel(tile) != water_region_patch.label` is true
23:01:57 <peter1138[d]> And your callback does not set your caller's v. It only sets its own v.
23:03:31 <xarick> oh, I think I see the problem
23:03:37 <xarick> gonna adjust code a bit
23:03:45 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:07:50 <xarick> my callback does not set my caller's v 😦 how do I make it do that?
23:11:14 <xarick> error C2100: illegal indirection
23:11:48 <Eddi|zuHause> you should possibly stick to legal indirections
23:41:25 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:44:29 <xarick> imma finding another solution
continue to next day ⏵
