IRC logs for #openttd on OFTC at 2024-01-24
⏴ go to previous day
00:14:46 <truebrain> only 3 things left 😛
00:15:12 <truebrain> dots, filter thingy, sticky thingy, resize thingy 😛
00:15:34 <peter1138[d]> Yeah, I'm manually splitting up an svg icon sheet into separate files.
00:15:44 <truebrain> but the result is impressive
00:15:57 <truebrain> it actually feels hi-res
00:16:04 <truebrain> so after this you are doing a basegraphics right?
00:16:12 <truebrain> as those pixels also need fixing 😛
00:16:21 <truebrain> SVG a complete set!
00:16:27 <peter1138[d]> I think SVG for the whole baseset might be a performance issue 🙂
00:16:38 <truebrain> you will figure out a way
00:16:52 <peter1138[d]> Of course, Zephyris font helps massively.
00:17:22 <peter1138[d]> Not quite the same right
00:17:59 <peter1138[d]> Hmm, how big is this cursor...
00:18:38 <peter1138[d]> CursorID... that's.. just a SpriteID, surely 😮
00:19:24 <_jgr_> Sort of, there are also animated cursors
00:19:50 <truebrain> peter1138[d]: At least pixilate the rest too when you do something like that 😛
00:22:56 *** Eddi|zuHause2 has joined #openttd
00:25:41 *** Eddi|zuHause has quit IRC (Ping timeout: 480 seconds)
00:50:50 <peter1138[d]> I draw a very bad pin, I guess :p
01:24:28 <peter1138[d]> Hmm, might be a bit too thin.
01:32:44 <peter1138[d]> > Total 22 sprites, cached 0, non-cacheable 22. Optimized 4 duplicates.
01:32:57 <peter1138[d]> Surprised to see that still works for svg.
02:03:39 *** herms has quit IRC (Quit: bye)
02:07:10 <peter1138[d]> Came out a bit too large :p
02:09:26 <peter1138[d]> 256x256.. I thought it would be fine... but of course that's at 1x zoom 😄
02:12:44 <rau117> peter1138[d]: idea: double click on the logo to hide it; show it again when re-enter main screen
02:13:25 <peter1138[d]> It was just a test.
02:13:31 <peter1138[d]> The logo is pretty bad, tbh.
02:16:48 <rau117> rau117: Well, or not just the logo, but also this text.
02:16:48 <rau117> For example, to watch the titlegame without extra interface
02:28:57 <peter1138[d]> Pretty sure making it the same colour as the text is breaking some law.
02:41:39 <reldred> breakin the law breakin the law breakin the law
03:36:10 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:59:33 *** Wormnest has quit IRC (Quit: Leaving)
06:26:03 <jfs> talltyler: Either TKM needs to be used carefully in strings, so it never needs to use plural or case forms ("Subsidy duration in periods: {num}" vs "Duration of subsidies: {NUM} period{P "" s}")
06:26:03 <jfs> Or some mechanism to use nested plurals and cases has to be introduced (huge shake up of everything including the core format).
06:26:03 <jfs> Or code needs to be jiggled around so {STRING} can be used to insert variations.
06:32:40 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:04:18 *** becky_andrew has joined #openttd
07:04:18 <becky_andrew> Hello" everyone i'm sorry to disturb your privacy..."I'll help anyone interested on how to earn 100k in just 72 hours without no doubts from the crypto market. But you will have to pay me my
07:04:18 <becky_andrew> commission! Once you receive your profit! if anyone interested send me a direct message
07:15:48 *** Eddi|zuHause2 is now known as Eddi|zuHause
07:26:25 <Heiki> translator.openttd.org is giving me lots of errors like this:
07:26:30 <Heiki> String cannot be translated, its base language version is incorrect
07:32:02 <Eddi|zuHause> how is that a 404 and not a 500 error?
07:32:24 *** ChanServ sets mode: +v tokai
07:33:52 <Heiki> Eddi|zuHause: good question
07:39:05 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:55:41 <LordAro> Eddi|zuHause: i did wonder
08:14:48 <_zephyris> peter1138[d]: As long as the text acts as the button too (which it does) it's good UI practice! Looks really nice anti-aliased
08:22:37 <peter1138[d]> jfs: Or don't have a setting that changes based on another setting.
08:40:57 <peter1138[d]> "Just a quick proof-of-concept"
08:51:33 <_zephyris> peter1138[d]: Looks great! Are they separate SVGs, or an svg sprite sheet?
08:54:04 <peter1138[d]> Separate SVGs, inserted into a sprite "zoom level" slot. So the game can load them like any other sprite, on demand.
08:54:19 <peter1138[d]> My original font-based implementation used a sprite sheet.
08:54:52 <peter1138[d]> fontcache-based, rather.
08:55:06 <peter1138[d]> So yes it's a bit inefficient.
08:59:05 <peter1138[d]> Potentially it could be one blob of a svg, and then use offsets to slice & dice it. But the game would need to either render the whole thing and crop it every time, or prerender it to a large buffer and then crop that.
08:59:21 <peter1138[d]> But then if you had a spritesheet the size of trg1 that would be... nope.
09:02:25 <locosage> better add some multisprite compression so it can just shrink common svg header to nothing
09:03:24 <_zephyris> Or just crop on encode. Though I'm sure cropping SVGs is a pain, with curves extending past control nodes, groups, translations, etc.
09:03:26 <andythenorth> pixel game -> vector UI
09:03:52 <locosage> there are probably some libraries for cropping
09:03:58 <_zephyris> Well, each pixel is kinda a perfect vector square!
09:04:31 <andythenorth> "vectors are just pixels at scale"
09:04:32 <locosage> svg isn't that different from raster on a low res
09:04:59 <locosage> if you have 1px line in svg it's gonna scale like shit on anything but integer zoom
09:05:33 <_zephyris> I'm using svg to draw the 4x zoom bridge sprites(!), works really well tbh.
09:05:39 <_zephyris> But, really ideal for UI
09:12:36 <peter1138[d]> The spanner has some thin bits, but it's reasonable at 1x.
09:13:43 <peter1138[d]> Same at 1.75x. Not sure I consider that "scale like shit"
09:15:56 <locosage> you have wider lines than 1px
09:16:09 <locosage> also it's most noticeable with vertical/horizontal lines
09:16:14 <peter1138[d]> Non-SVG does scale-like-shit.
09:16:17 <locosage> they just blur between piels
09:16:22 <peter1138[d]> Of course it has wider than 1px lines, it's 1.75x scale.
09:18:22 <locosage> how does that + looks below?
09:18:41 <locosage> without the disabling
09:21:48 <locosage> this is what I'm talking about
09:22:15 <peter1138[d]> Anti-aliasing is always very visible when you zoom it in lots.
09:23:25 <locosage> yeah, but ideally there would be nothing to alias
09:23:36 <peter1138[d]> It's a 1.75 pixel wide line, so...
09:26:19 <locosage> yeah, but it would be 2 if it was hand-drawn for this zoom
09:26:50 <peter1138[d]> Yes, but who wants to hand-draw every possible fractional zoom.
09:29:17 <locosage> well, maybe someone will...
09:29:25 <peter1138[d]> Good luck to theM 🙂
09:29:41 <peter1138[d]> Btw you can press-ctrl while using the interface scale slider...
09:29:48 <locosage> also 3x=1.5x * 2 so they can be the same...
09:30:03 <locosage> but, anyway, what I'm saying is that for this + there is no difference between raster and vector
09:30:19 <locosage> raster would scale exacly like that if you use interpolation and not nn
09:32:43 <peter1138[d]> Hmm, apparently 15 AIs can run. (Maximum no. competitors: 14)
09:35:36 *** thelounge345 has joined #openttd
09:35:49 <_zephyris> Implement hinting for SVGs 😛
09:36:22 <_zephyris> But seriously, with a basic guide grid for multiple zoom levels, it's easy to draw sprites that work _well enough_ for many fractional zooms
09:38:25 <_zephyris> Hmm, hinting would be fun!
09:43:36 <peter1138[d]> There's a`shape-rendering` property in SVG2, but that's a draft somewhere and not supported.
09:45:29 <locosage> though not property of svg itself i guess.
09:48:05 <peter1138[d]> Browser compatibility charts don't tend to list my OpenTTD branches 😄
09:48:39 <_zephyris> Doesn't seem to be a well-defined spec though, as in it allows the user agent to do things, but the things the agent does aren't defined
09:52:33 <peter1138[d]> Inkscape's default keybindings are weird. No Ctrl-Z to undo...
09:55:43 <_zephyris> Is that some weird linux thing? It is on win
09:57:20 <locosage> also ctrl-z on linux for me...
10:29:36 <peter1138[d]> _zephyris: 4x sprites do scale down quite nicely to fractional sizes at least. Not as good as SVG but better than upscaling 1x or 2x sprites.
10:31:52 <_zephyris> Yeah, I can imagine they do... If drawn with downscaling in mind, eg. 4px wide lines for 4x zoom sprite.
10:33:06 *** tycoondemon has quit IRC (Ping timeout: 480 seconds)
10:33:51 <_zephyris> Well this is all looking very interesting. When I tackle 4x GUI I'll definitely try to go from SVG
10:43:05 <peter1138[d]> Well, it's possible you'll be able to use native SVG 🙂
10:54:53 <xarick> maybe I can do the search for a depot at the last region without restricting it to the area
10:55:31 <peter1138[d]> Just watch out for the blurry scales-like-shit lines :p
10:56:17 <xarick> it's a teleport search starting at the last region
10:56:49 <xarick> a 3rd attempt, perhaps?
10:57:31 <peter1138[d]> When I implemented NewStations
10:57:59 <xarick> the search is so complicated to explain, I started writing down what's happening in the PR
10:58:11 <xarick> and I found out, there's still room for improvements
10:58:12 <LordAro> peter1138[d]: will you support embedding js in svgs to implement newgrf behaviour?
10:58:56 <peter1138[d]> ini files surely.
10:59:43 <LordAro> i was just thinking about all the possible new CVEs that would be enabled by doing so
11:02:46 <xarick> <https://github.com/OpenTTD/OpenTTD/pull/10544#issue-1610243251> at the second point, *Pathfinder costs at the destination region*, where it reads "These calls are restricted to just the destination region", I could instead add another step before that which does an unrestricted search, with the starting points at the entry points of the destination region.
11:02:49 <kuhnovic> xarick: I had a quick glance at your PR, I didn't get the chance to go into full detail. But in general I think you are making it way too complicated.
11:04:01 <xarick> it would make the issue I talked about later, "One limitation I can think of is on far distant regions where a depot could be closer by navigating two regions instead of one", dissipate!
11:07:22 <xarick> it's brilliant, lol! it's complex, but well if it works as I predict, then it's great
11:08:29 <kuhnovic> It's also going to be full of problems and edge case if you keep it this complex 😛
11:09:13 <LordAro> sounds like a job for unit tests :p
11:11:17 <kuhnovic> We all know he's not going to write those
11:12:09 <LordAro> testing and finding edgecases no one else thought about is something that xarick is actually quite good at
11:12:26 <LordAro> finding the right solution to those issues... less so
11:14:14 <kuhnovic> LordAro: True, he did find that issue with aqueducts on edges
11:14:38 <kuhnovic> Still need to look into that one
11:28:58 *** thelounge345 has quit IRC (Ping timeout: 480 seconds)
11:38:11 *** thelounge345 has joined #openttd
12:28:34 <xarick> hmm 🙂 even more improvements to come
12:29:21 <xarick> GetShipDepotInWaterRegionPatch has a list of valid_tiles... the more I look into it, the more I realize, I don't need this list
12:30:19 <xarick> I only need to know if there's a depot in the region
12:32:27 <xarick> just started 14 LuDiAI Afterfixes with breakdowns enabled
12:32:37 <xarick> nearest depot will be used
12:32:58 <xarick> let's see if I get an assert or something bad out of this
12:39:38 <locosage> hm, so I made sprite encoder in rust that works slower than python 😅
12:46:29 <peter1138[d]> I just ate a load of crap for lunch, then remembered I bought salad-ingredients for that 😮
12:57:50 <xarick> that wasn't the kind of crash I expected
13:04:04 <_zephyris> peter1138[d]: Sweet, so when do I get started on ogfx2 svg gui?
13:05:03 <peter1138[d]> When I've nailed down the format maybe. Working out how to fudge colour remap support into it (without redesigning how colour remaps work.)
13:08:02 <peter1138[d]> I've already changed the format to avoid svg NewGRFs crashing vanilla OpenTTD.
13:08:28 <locosage> time to finally do LUTs ;)
13:09:14 <peter1138[d]> You mean GRF-supplied LUTs?
13:09:37 <peter1138[d]> Well, if it's not GRF-supplied then it doesn't help all that much.
13:09:45 <peter1138[d]> Unless the GRF can select from a predefined LUT.
13:10:33 <locosage> do interface sprites even use recolor?
13:11:15 <peter1138[d]> But SVG isn't limited to interface sprites either.
13:11:29 <_zephyris> Presumably you're applying recolour to the rasterised sprite?
13:11:34 <locosage> well, to get it started interface is kinda enough
13:11:59 <locosage> but interface recolors are only grf-supplied in a sense that grf can redefine default ones?
13:12:06 <peter1138[d]> _zephyris: Not yet 🙂
13:12:28 <_zephyris> locosage: Company colour and animated colours jump to mind
13:12:50 <locosage> animated colors can't even be redefined
13:13:12 <locosage> they're just hardcoded
13:13:18 <peter1138[d]> A LUT needs to map from RGBA to palette index. `GetNearestColourIndex()` already does that for normal RGBA but explicitly skips the company recolour indices.
13:13:31 <peter1138[d]> That function is designed to be generic and work with existing sprites.
13:13:45 <locosage> wait, why map into palette index?
13:13:49 <peter1138[d]> But for a new feature, it's could be possible for the NewGRF to say "these are company colour indices"
13:13:50 <locosage> unless you're talking 8bpp blitter
13:14:01 <peter1138[d]> Because colour remapping works on palette indices.
13:14:19 <locosage> LUT is color remapping
13:14:29 <peter1138[d]> ^ "without redesigning how colour remaps work"
13:15:01 <peter1138[d]> Yes I know it's not the perfect solution that you could knock up in 5 minutes with python.
13:15:02 <locosage> well, whole point of LUT is to redesign that xD
13:15:14 <locosage> otherwise it's just quantization to ttd palette
13:20:13 <locosage> ideally lut should probably be applied in a shader
13:20:26 <locosage> but I guess that's not how openttd video drivers work at all...
13:21:53 <xarick> autosave every 10 minutes?
13:22:00 <xarick> what about every month
13:22:42 <xarick> i don't want autosaving in real time
13:22:50 <peter1138[d]> Because if the calendar is paused, 1 month doesn't happen.
13:23:41 <xarick> i really have a bad faith about the new time features being introduced 😐
13:26:22 <xarick> hunting for a crash without a functional autosave... what do I do now
13:28:36 <talltyler> Also autosaving now works if the game is paused, and doesn’t make too many saves when fast-forwarding
13:33:59 <_zephyris> peter1138[d]: My gut feeling is to just treat like 32bpp sprites (rasterised anti-aliased), and require a mask svg (rasterised aliased) where exact matches to ttd palette indices are the mask pixels.
13:34:34 <_glx_> xarick: it's the game loop
13:34:57 <xarick> it's my pathfinder, took me a while to get where it was originating from
13:35:39 <_zephyris> It'd be possible to have an xml tag for palette index for recolouring, but I can't think of a tidy way of interpreting that. Perhaps just change the colour everything without a tag to 0000FF. But I can imagine a bunch of corner cases with transparency, handling stroke and path separately, etc.
13:35:43 <_glx_> somehow it throws and nothing catches it before the thread creation function safety try-catch
13:41:19 <_glx_> check the preceding call, you should see which lambda it is
13:42:09 <xarick> it's my code, I see what it is, not entirely sure, but I suspect Yapf().GetVehicle() does not yet have the vehicle set
13:42:33 <xarick> but these 10 minutes autosaves aren't too helpful
13:42:45 <xarick> needed a save the month before it happened
13:46:51 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
13:49:58 <_glx_> you can set it to lower
13:50:14 <_glx_> `set autosave_interval 1`
13:51:54 <locosage> _zephyris: could just do something like what I have in bonkygfx where magenta hue turns into cc
13:52:12 <locosage> not great solution for animated colors though
13:52:29 <_glx_> the GUI just lists the typical intervals
13:57:02 <_glx_> xarick: a pathfinder call without a vehicle seems suspicious
13:59:07 <xarick> it is only set when FindPath is fired
13:59:16 <xarick> but I need it before that
14:00:15 <xarick> need to extract the owner of the ship depot to be the same of the ship
14:00:20 <locosage> problem with indexed colors in svg is that ideally they need to be resolved before rendering
14:00:34 <locosage> otherwise it's impossible to tell if they get covered by something half-transparent
14:01:36 <xarick> maybe there's another way, but these callbacks are going back and forth, and hmm... yeah
14:02:35 <locosage> basically, it's impossible to get RGBAM out of svg without some sacrifices
14:08:48 <locosage> I don't see how to render even the simplest things like this with cc fill
14:09:38 <locosage> well, this particular thing would work with magenta-to-cc solution
14:09:44 <locosage> but not if it's animated color
14:12:19 <_glx_> a pathfinder call is supposed to have a valid vehicle
14:16:04 <_zephyris> SVGs aren't well suited to the problem, which is why I suggested a svg mask file as the solution. It would have the simple requirement is that the mask svg, rendered aliased, exactly matches a ttd palette index to be used as a mask for that pixel... Its fundamentally very similar to the problem of encoding index recolours for RGBA bitmap sprites.
14:16:28 <xarick> pf.SetVehicle(v); problem solved!
14:16:28 <_zephyris> But, I'm not the one with the skills to implement anything, so all judgement reserved 😉
14:31:40 <locosage> _zephyris: well, I guess if it's the same greyscale + mask logic as for raster sprites it'll have similar capabilities
14:32:04 <locosage> it's not like you can have non-lightness gradients with indexed colors in raster sprites
14:32:42 <locosage> not sure if combining aliased with antialiased will cause some issues though
14:33:23 <_zephyris> Yup, there would be, but only the same as 32bpp/mask...
14:38:05 <locosage> for animated colors bonkygfx uses magenta hue as a signal to use indexed color layer
14:42:54 <locosage> so basically, same thing just different condition for using mask layer
14:45:11 <nanapipirara> locosage: Btw, in this case, wouldn't it be even simpler if the yellow parts would be on a seperate layer and simply use that layers alpha as the mask?
14:46:40 <locosage> well, you still need to have some color on rgba sprite to lightness-adjust indexed colors
14:50:23 <locosage> I think I even pass rgba layers as is to openttd
14:50:37 <locosage> so only difference is that it cuts mask by magenta
14:50:54 <locosage> instead of requiring it to match exact pixels
14:51:47 <locosage> not sure how useful it actually is
14:52:21 <locosage> but it evolved from cc approach where magenta actually helps as you don't need a separate layer
14:54:03 <locosage> and cc gradients with mask are quite tricky
15:02:37 <belajalilija> Oh hey the cool thing is being talked about xd
15:18:29 <peter1138[d]> Only bad features, surely.
15:19:30 <belajalilija> It’s a very cool feature
15:19:44 <belajalilija> It will make hand drawing far easier
15:20:33 <belajalilija> Would put to bed any advantage that voxels may have for standard zoom
15:31:46 <locosage> hm, the exact same c sprite encoder algorithm in rust is 10x slower...
15:57:15 *** Wormnest has joined #openttd
15:59:16 <xarick> how do I use TicToc around returns?
16:00:09 <peter1138[d]> Just return from inside the tictoc.
16:00:57 <xarick> static TicToc::State state1("YapfShipFindNearestDepot", 1000);
16:00:57 <xarick> return YapfShipFindNearestDepot(v, max_distance);
16:07:01 <xarick> the explanation is still mildly confusing
16:08:41 <_glx_> it's just c++ magic, when you used TIC then TOC, you now only need TicToc, which is equivalent of TIC and automatic TOC
16:09:55 <LordAro> presumably it doesn't actually need to be a named variable
16:10:03 <LordAro> could just do `TicToc(state1);`
16:10:31 <_glx_> I think the variable is needed for the scope
16:17:27 <peter1138[d]> Maybe you can do that, never tried.
16:23:15 <xarick> ship service interval is 300 days... and the game just started
16:23:47 <merni> maybe reduce the interval then?
16:24:00 <xarick> I don't think AIs can do that
16:25:32 <locosage> grf-py-v2-pointer: 0.23 sec, 570092 bytes
16:25:32 <locosage> grf-py-v2: 0.29 sec, 570092 bytes
16:25:32 <locosage> truegrf: 0.39 sec, 570092 bytes
16:25:32 <locosage> grf-py-v1: 0.43 sec, 570092 bytes
16:25:34 <locosage> nml: 0.22 sec, 570092 bytes
16:25:34 <locosage> nml_py: 0.75 sec, 570092 bytes
16:34:12 <xarick> oops, didn't edit my script to deal with sending ships to depot the nearest depot way...
16:41:34 <xarick> strange, how do I append/insert a nearest depot order with AIs? apparently I can't?
16:41:44 <xarick> i need a destination tile...
16:42:07 <peter1138[d]> You need to find the nearest depot 😉
16:42:42 <xarick> OF_GOTO_NEAREST_DEPOT exists, so it might be possible
16:57:50 <_glx_> it might not be possible in current API
16:58:35 <_glx_> the flags exist, but the API probably not support orders without a valid destination
17:02:44 <peter1138[d]> Nah, it should work.
17:02:45 <_glx_> oh it does, just use INVALID_TILE
17:05:19 <_glx_> the doc could be better
17:05:29 <peter1138[d]> Hmm, who 'ordered' alpha in 8bpp mode?
17:11:22 <_glx_> const bool is_top_level_call = tile == INVALID_TILE;
17:14:02 <_glx_> then you do ```if (is_top_level_call) {
17:14:02 <_glx_> trackdirs = TrackdirToTrackdirBits(td) | TrackdirToTrackdirBits(td_rev);
17:14:42 <_glx_> but is_top_level_call will still be true
17:15:53 <_glx_> the assert is just wrong
17:16:07 <xarick> it's possibly one of those "edge cases" I was warned about
17:16:34 <_glx_> tile is now valid, but you assert on the previous state
17:17:20 <xarick> top call found a depot, secondary call is another call after the top one, now with a starting tile at another position, the "teleport search" as I call it
17:17:24 <xarick> it should have a depot
17:18:52 <xarick> it teleports to a tile closest to the area containing the depot
17:19:04 <xarick> so, it's still in the same pathway
17:20:26 <_glx_> I'm just reading FindNearestDepot(), if you pass INVALID_TILE to it, then this tile is replaced by v->tile, but the function will still continue and trigger the assert
17:21:48 <xarick> I assumed the initial value of 'tile' to be that of the overriding tile
17:22:12 <xarick> if it's not, then it's fixed to the ships current position
17:23:09 <xarick> may need some commenting describing the situation better
17:26:45 <truebrain> peter1138[d]: Fake! 😛
17:30:39 <xarick> failed to create dump file 😦
17:31:52 <xarick> I see 2 calls to YapfShipFindNearestDepot , it failed on the secondary level
17:32:43 <xarick> without dump it's hard 😦
17:33:15 <_glx_> it's weird you don't have dump
17:33:49 <_glx_> breakpad is the first thing in vcpkg.json
17:34:04 <xarick> it used to work before
17:34:08 <_glx_> it's the thing creating the dump
17:34:20 <xarick> something changed recently
17:34:37 <_glx_> we switched to breakpad some time ago
17:35:01 <xarick> i dont remember reading breakpad anywhere before
17:35:08 <xarick> that's maybe when it used to work
17:35:37 <_glx_> but cmake should install breakpad during configuration
17:36:00 <xarick> let me check cmake config, or something
17:36:32 <_glx_> cmake runs `vcpkg install`
17:37:50 <_glx_> oh your breakpad is broken
17:38:23 <_glx_> update your vcpkg sources
17:40:12 <_glx_> breakpad was broken from december 12 to december 15
17:40:16 <xarick> Im not sure what I'm supposed to do
17:41:04 <xarick> deleted cache and reconfiguring, let's see
17:41:12 <_glx_> go to D:/OpenTTD/vcpkg and git pull
17:44:38 <xarick> it generated a lot of stuff now
17:46:08 <_glx_> 1> [CMake] -- unofficial-breakpad found -- -DWITH_UNOFFICIAL_BREAKPAD -- unofficial::breakpad::libbreakpad_client
17:46:47 <xarick> ok, let's get this crashing again 🙂
17:47:00 <xarick> about 1 hour into the game
17:49:26 <xarick> oh, i had a crash save
17:49:31 <xarick> crashed right away, cool
17:50:06 <xarick> A serious fault condition occurred in the game. The game will shut down.
17:50:06 <xarick> As you loaded an emergency savegame no crash information will be generated.
17:51:44 <_glx_> yeah crash saves are usable in debugger though
17:55:36 <locosage> freaking performance, every loop is iterating less time but overall it's somehow 1.5x slower
17:55:50 <locosage> and only difference is some code that executes about never
18:02:42 <xarick> this is the place it crashed
18:02:57 <xarick> searching for a path to it failed?
18:03:44 <xarick> high level pathfinder found it
18:03:58 <xarick> low level pathfinder didn't 🙂 that's so strange
18:04:28 <frosch123> i used a 64 char long STR_ id. luckily english.txt is indented for 65 chars 🙂
18:05:01 <peter1138[d]> Hopefully no language needs to use a case with it 🙂
18:05:56 <frosch123> that's eints' problem :p
18:06:48 <xarick> do I have to move the tile to the position before the trackdirs?
18:07:06 <xarick> starting outside the edge?
18:09:16 <xarick> hmm it sure makes things slightly more complicated
18:11:43 <xarick> for aqueducts... what kind of tile do i pass as the starting tile?
18:12:39 <xarick> the tile the aqueduct is entered, or the tile it exits?
18:17:36 <peter1138[d]> Hmm, I kinda want a list of permitted palette indices.
18:21:15 <frosch123> transparent/regular/animated/pink/white?
18:24:21 <xarick> aha! there is a solution!
18:24:32 <xarick> the starting tile is the goal tile
18:24:49 <xarick> just copy pasting will fix it
18:26:28 <xarick> oh, not really copy pasting 😦
18:26:44 <xarick> I do not know the goal tile yet
18:26:57 <xarick> but the goal is the tile it starts, which is skipped by yapf
18:32:53 <kuhnovic> More special casing, just what we need
18:36:58 *** HerzogDeXtEr1 has quit IRC (Read error: Connection reset by peer)
18:39:25 <kuhnovic> Then it will look at the start of the bridge i guess
18:40:07 <xarick> I need to mimic that code, without the ship
18:41:07 <xarick> need to simulate the ship being at a future tile
18:42:38 <kuhnovic> I recommend using the TrackFollower for ships. That way you play by the same rules as the actual ship / pathfinder
18:43:12 <_glx_> Don't reinvent the wheel if not needed
18:44:41 <xarick> hmm, I see two ways to solve this edge case, i treat the start tile as a possibility to be the destination, or I move the starting tile one tile
18:45:01 <xarick> the 2nd approach is risky
18:51:52 *** gelignite has joined #openttd
18:57:10 <peter1138[d]> Of course this is for a version of OpenTTD that only I have. Exclusivity.
19:05:05 <peter1138[d]> I was going to get it finished tonight, but I'm going out on the bike instead.
19:05:30 <peter1138[d]> aka "better leave that to someone with talent"
20:07:05 <truebrain> peter1138[d]: now it is more than a prototype 😛
21:21:45 *** gelignite has quit IRC (Quit: Stay safe!)
22:01:45 <peter1138[d]> Hmm, quiet evening.
22:05:40 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:13:30 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:31:57 <xarick> > /* By default, we assume the call to this function is not the main one.
22:31:57 <xarick> > * 'tile' and 'trackdirs', if valid, contain information about where the ship
22:31:57 <xarick> > * would be located ahead of its current position in the near future.
22:31:57 <xarick> > * The ship's current position and trackdirs need to be restored if such information
22:31:57 <xarick> > * is missing, thus in turn, making this the first call. */
22:32:15 <xarick> const bool is_top_level_call = tile == INVALID_TILE;
22:33:55 <locosage> wonder if anyone is using admin port with anything but localhost connection xD
22:36:07 <peter1138[d]> xarick: You lost me at 'not the main one'
22:37:38 <xarick> or a nested call if you will it
22:38:22 <xarick> or uh... forgot the correct wording of it...
22:38:55 <xarick> yes, recursive, but only once
22:38:59 <peter1138[d]> So rather than assuming it's 'not the main one', you assume it is a nested call (not top-level?)
22:39:56 <xarick> yes, makes for easier handling of parameters
22:40:25 <peter1138[d]> Ok. You asked about the language, I'm trying to guide you here...
22:40:54 <peter1138[d]> Next, is it possible to be certain, instead of having to assume?
22:41:28 <peter1138[d]> Should it be considered a constraint for the caller?
22:43:52 <xarick> maybe the wording needs help... "assume"
22:45:15 <xarick> the main call starts from ship_cmd.cpp - YapfShipFindNearestDepot(v, max_distance);
22:46:25 <xarick> the secondary call starts from water_regions.cpp, already at the destination region - YapfShipFindNearestDepot(v, 0, tile_dist.first, trackdirs);
22:46:25 <xarick> this one with more parameters
22:49:02 <peter1138[d]> I... Assumed, heh, the wording needs help because you asked for it .
22:53:46 <xarick> my brain doesn't work. what do I write in the coment
22:57:24 <xarick> > /* If the call to this function is not the main one, 'tile' and 'trackdirs' contain
22:57:24 <xarick> > * information about where the ship would be located ahead of its current position
22:57:24 <xarick> > * in the near future.
22:57:24 <xarick> > * The ship's current position and trackdirs need to be restored if such information
22:57:24 <xarick> > * is invalid, thus in turn, it makes this the first call. */
23:00:47 <truebrain> Rubidium: really cool, #11878 🙂
23:08:27 <xarick> > /* 'tile' and 'trackdirs' contain information about where the ship would be located
23:08:27 <xarick> > * ahead of its current position in the near future when the call is not top-level.
23:08:27 <xarick> > * If such information is invalid, then that makes this the top call, so the ship's
23:08:27 <xarick> > * current position and trackdirs need to be restored. */
23:10:51 <truebrain> client-side-certificates made easy ... monocypher is pretty nice 😄
23:13:17 <truebrain> do we also want server certificate now, so the admin client knows they are talking to the right server? 😛 (answer: no)
23:14:50 <peter1138[d]> I'm not against any of it btw, I'm just wary of things related to security that look a little homebrew 🙂
23:15:00 <truebrain> you are absolutely right to ask
23:15:47 <truebrain> it is the same code I use to validate the signature of the checksum-file for plugins btw; just in reverse 😄
23:16:18 <truebrain> well, not even in reverse ..
23:19:44 <peter1138[d]> "Render windows with SVG" sounds like a bad idea...
23:19:53 <peter1138[d]> Why did I think of that?
23:24:37 <Rubidium> truebrain: such typical "my brain went faster than my fingers" of me... the actual generating of the keypair in OpenTTD isn't the problem. It's the "how do I get the public key in the server", and "how do I get the public key (of my team mates) in our company"
23:25:05 <Rubidium> but I got distracted and didn't write that down :(
23:25:10 <truebrain> as the administration is relatively easy 🙂
23:26:12 <locosage> peter1138[d]: "To a man with a hammer, everything looks like a nail" 😜
23:27:09 <Rubidium> from a server owner's perspective it's going to be quite cumbersome to have to add all the public keys of people you want to give access. Where a password is shared quite simply on a website or something
23:27:55 <Rubidium> similarly with a company, do I know the public keys of all my team mates?
23:30:04 <truebrain> Rubidium: yeah .. when I thought about this, years ago now, I kept coming back to a "lobby" system
23:30:12 <truebrain> where the server own gets: player XXX tries to join your game; allow?
23:30:16 <truebrain> after which it is whitelisted
23:30:25 <truebrain> as for companies, it is a lot easier
23:30:28 <truebrain> they join as spectator
23:30:33 <truebrain> and you can click: invite to company
23:30:50 <truebrain> what ever you do, please never bother the server-owner or client with public-keys 😛
23:32:12 <truebrain> Steam and Discord integration helps with all this btw a bit; they can allow inviting people to a server they don't have access to yet. Via the Social Integration the exchange of public keys can be done to whitelist someone
23:32:33 <truebrain> next step ofc would be an in-game "friends" list, but .... yeah ... 2030 called, they know
23:34:23 <truebrain> About X25519, it has this note peter1138[d] will like: `It is fast, simple, and relatively easy to implement securely.` 😄
23:34:55 <truebrain> "relatively easy" for who, they never say, but ... 😛
23:36:29 <locosage> grf-py-v3: 0.13 sec, 552416 bytes (CORRECT)
23:36:29 <locosage> grf-py-v2: 0.23 sec, 552416 bytes (CORRECT)
23:36:29 <locosage> truegrf: 0.38 sec, 570092 bytes
23:36:29 <locosage> grf-py-v1: 0.45 sec, 570092 bytes
23:36:29 <locosage> nml: 0.22 sec, 570092 bytes
23:36:30 <locosage> nml_py: 0.76 sec, 570092 bytes
23:36:35 <locosage> 40% faster 3% smaller and haven't even started on optimizing algorithm yet...
23:44:29 <truebrain> ah, yes, you don't do Authenticated Encryption 🙂
23:45:07 <truebrain> but the non-streaming; makes sense
23:46:54 <truebrain> I still love DH ... creating a shared secret without ever exchanging the secret on the wire
23:47:05 <truebrain> still blows my mind that is possible
23:47:48 <_jgr_> The trouble is that is that a MITM attacker can do separate DH exchanges with the two sides
23:47:59 <_jgr_> Which is why you need certificates
23:48:01 <truebrain> that is why you need to trust the server pub key 😄
23:48:13 <truebrain> we can facilitate that via the Game Coordinator btw
23:48:25 <peter1138[d]> Very gradient, such pruple.
23:48:28 <truebrain> which than acts like a CA 🙂
23:49:33 <truebrain> (which still ofc allows a MitM attack on the server-side .. but okay)
23:51:37 <peter1138[d]> Hmm, maybe I could try fiddling with the svg and use custom classes to identify bits that should be rendered with specific palette indices.
23:52:18 <truebrain> guess the server-side MitM could be mitigated by listing the pubkey on the servers.openttd.org site, so you can manually check nobody is intercepting your connection 🙂 But ... not really practical 😄
23:53:25 <_jgr_> As if people really check the key fingerpritn that SSH prints out 😛
23:53:31 <peter1138[d]> Although that would be a very custom svg renderer. Hmm.
23:53:43 <truebrain> well, I worked at places where it was checked
23:53:59 <truebrain> someone started yelling letters in an open room, for someone else to check if he was seeing the same letters
23:54:05 <truebrain> only then access was allowed
23:54:18 <truebrain> try to MitM that, someone yelling in a room 😄
23:56:19 <truebrain> btw, your trick of adding the password in the hash of the shared secret wouldn't work for Rubidium's approach of having the password optional if your client certificate is whitelisted. But it is a nice trick you use there 😄
23:57:29 <truebrain> really pleasently surprised by the simplicity of monocypher
23:58:25 <_jgr_> It's pretty convenient in that it doesn't require any more work from the user or server operator
23:59:10 <truebrain> it is nice the password is never exchanged
23:59:59 <truebrain> guess it would still be possible for the admin-port to have both; it just does require a boolean (or packet) to make the distinction
continue to next day ⏵
