IRC logs for #openttd on OFTC at 2023-08-16
⏴ go to previous day
00:38:22 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:16:48 *** Flygon has quit IRC (Read error: Connection reset by peer)
01:22:20 *** Wormnest has joined #openttd
01:41:17 *** ChanServ sets mode: +v tokai
01:44:53 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:03:43 *** herms has quit IRC (Quit: bye)
02:24:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:39:18 *** D-HUND is now known as debdog
03:00:05 *** herms has quit IRC (Quit: bye)
04:18:59 <ahyangyi> andythenorth: I apologize for the confusion!
06:54:20 <truebrain> peter1138: You are right, even the default LLVM and VisualCode does that. Like I said, I am not married to it, but I really dislike the lack of visual separation .. especially on GitHub, I find it hard to read easily 🙂
06:54:39 <truebrain> but concistency is more important than personal flavour, so yeah .. let's just pick one and make sure all new follows the same 😛
06:56:06 <truebrain> we could also do the `byte status = { 0 }` syntax, not? As `std::vector<bool> test = { true, false }` is also valid?
06:56:18 <truebrain> meh .. I don't really care that much. As long as we become consistent in the choice 😛
07:05:13 <andythenorth> tomlkit or tomli_w?
07:05:24 <andythenorth> tomlkit probably
07:12:26 <andythenorth> goes it replace nml .lng files with toml? 😛
07:12:39 <andythenorth> parsing seems trivial, it's 2 lines to get a python dict
08:07:00 <pickpacket> How early am I allowed to have lunch today? I had breakfast at 5am
08:14:12 <andythenorth> `open *` is probably an anti-pattern eh
08:14:23 <andythenorth> in a python compile script
08:14:47 <LordAro> andythenorth: tomllib in py3.11 :p
08:14:57 <andythenorth> works great for read
08:15:21 <andythenorth> I want to write a script to migrate existing .lng translations, it will make people sad if I throw them away
08:15:33 <andythenorth> GPT can migrate them, but it's like pulling teeth
08:16:04 <andythenorth> GPT is like having a minimum wage offsider as an intern
08:16:42 <andythenorth> - costs about the same per hour
08:16:42 <andythenorth> - instructions have to be given very very precisely, and repeated
08:16:42 <andythenorth> - quality is highly variable
08:16:42 <andythenorth> - extreme enthusiasm
08:17:12 *** cryoshakespeare has joined #openttd
08:17:12 <cryoshakespeare> Hey there, to any of you more familiar with development, is it possible to make a grf which allows you to scale cargo capacities of different vehicle categories, like BaseCosts allows you to scale their purchase/running costs generically? Or do cargo capacities have to be defined on a per-vehicle basis?
08:18:05 <truebrain> If you don't get an answer here, make sure to try Discord channel #add-on-development too
08:18:53 <andythenorth> cryoshakespeare: per-vehicle
08:19:26 <cryoshakespeare> andythenorth: Ah, I see. Figured someone would have made it already if it were possible generically.
08:19:40 <cryoshakespeare> Thanks anyway :)
08:19:51 <andythenorth> it's a common request for grfs
08:20:01 <andythenorth> but has to be handled by each grf individually
08:20:29 <cryoshakespeare> Ah, hah. I can imagine you get a lot of repeat questions here, perhaps I should have used the search function first :P
08:20:47 <andythenorth> it's so common that ideally the game would handle it
08:21:12 <andythenorth> but that's work 🙂
08:21:58 <LordAro> feels a bit overengineeree, each string having a section with a single attribute like that
08:22:01 <cryoshakespeare> Perhaps a future feature for JGR
08:22:09 <LordAro> oh, i was scrolled up a lot
08:23:07 <andythenorth> LordAro: it would be, except this is an over-engineered grf compile 😛
08:23:12 <andythenorth> it produces 3 grfs from one
08:27:49 *** milek7 has quit IRC (Remote host closed the connection)
08:28:27 <peter1138> Reordering structs is fun.
08:29:03 <peter1138> You can save "a bit" but then you see that inheritance and sub-structs affect alignment in difficult-to-see ways.
08:30:41 <truebrain> we could just pack all structs .. but that would be horrible for performance 😄
08:32:00 <truebrain> hmm .. ubuntu doesn't distribute breakpad-dev or anything? hmmm
08:32:39 <peter1138> The rule to put the stuff with larger alignof() first normally works, but e.g. anything that inherits from Pool has a type-declared-elsewhere index, so it's beneficial to fill space there before placing pointers.
08:33:23 <peter1138> It's kind of frustrating that the there's no way to tell the compiler to efficiently rearrange it.
08:33:49 <truebrain> yeah, bit surprising even .. you would think we are not the only ones that want to optimize their memory footprint
08:41:30 <peter1138> #7261 was a mistake.
08:42:46 <peter1138> I'm thinking about reimplementing it using a fixed-size ring buffer.
08:42:50 <peter1138> > (lldb) print sizeof(RoadVehPathCache)
08:42:50 <peter1138> > (unsigned long) $1 = 160
08:43:22 <peter1138> We only ever actually keep up to 40 bytes in that cache...
08:43:41 <truebrain> why is it 160 bytes long .. are deques so memory-expensive?
08:43:56 <peter1138> Yes, each one is 80 bytes.
08:44:07 <truebrain> ah, yeah ... that kinda hurts 😛
08:44:16 <peter1138> AND they allocate memory on top for the actual data.
08:44:21 <truebrain> memory vs performance! \o/
08:45:28 <truebrain> really did not expect a deque to use so much bytes
08:45:42 <truebrain> I was thinking more like a base / head / tail / counter, so like 4*8
08:47:56 <peter1138> And it uses two of them, because either I didn't know about std::pair back then... or just thought it would use less space than wasting 3 bytes per entry...
08:48:30 <truebrain> so I see memory improvements for RV-heavy games in our future? 🙂
08:48:42 <peter1138> So a rewrite with a fixed-size buffer is reasonable I think.
08:56:11 <peter1138> truebrain: potentially, but I'm not 100% sure about the best approach. It used std::deque to avoid writing custom containers, but as 80 bytes each is excessive here...
08:56:32 <peter1138> Not sure if there's a suitable standard container.
08:57:23 <truebrain> well, if you would combine the two deques, with a std::pair, it would allow for up to 13 items in it before it uses the same amount of memory? (40 / 3)
08:57:33 <truebrain> but I am guessing the average path is a lot longer 😛
08:58:18 <peter1138> No, we deliberately cache only a short amount.
08:58:27 <truebrain> ah, well, so there is some savings, I guess
09:00:31 <peter1138> With a custom container, that we know can only ever contain, say, 16 entries, we can store the head/tail/size indices in uint8_t instead of size_t. That is 3 bytes instead of 24 bytes there alone.
09:00:56 <truebrain> well, and a base, for realloc etc
09:01:05 <truebrain> so yeah, that goes pretty quick
09:01:13 <truebrain> but .. is it worth it? In a RV heavy game, how much bytes does it save?
09:01:33 <truebrain> say, a game has 10,000 RVs. The deques would consume 800 KiB of RAM
09:01:46 <truebrain> at the very bottom, we use 50 MiB of RAM
09:01:58 <peter1138> 1.6MB as there are two.
09:01:59 <truebrain> so you would be saving, at best, 2% of RAM? (playing the devils advocate here, to be clear)
09:02:19 <truebrain> but we can combine that we noticed earlier
09:02:24 <truebrain> so back to 800, fine, 1 MiB 😛
09:02:39 <truebrain> having 10k RVs also consumes tons of other extra memory
09:03:05 <truebrain> well, an easy test: grab a game with 10k RVs or what-ever, and run with and without the cache thing compiled in 🙂
09:03:43 <truebrain> if there is a big RAM difference, I am all for a better (custom) container .. but if it is like 1% .. is that worth a custom container? (again, playing devils advocate here)
09:07:27 <peter1138> Somehow I just typed "sozeif"
09:07:46 <peter1138> Cool, towns have a cache of 1880 bytes. Good job there are not that many towns 😄
09:08:39 <locosage> stations had like 7kb or smth
09:09:15 <peter1138> No, it's 9192 bytes with #11201.
09:09:25 <peter1138> And 97xx bytes without.
09:09:58 <peter1138> Oh I stated in the commit, 9704 🙂
09:12:09 <peter1138> I have another patch that replaces the array with a std::map, so memory is only allocated for cargo actually seen, but that has issues: quite a lot of places keep a pointer to a station's GoodsEntry 😦
09:12:28 <truebrain> so much shit to fixxxxxx 😄
09:12:56 <locosage> std::map is not exactly a lightweight structure
09:13:01 <peter1138> Some of that will only be temporary so not an issue, but still needs disentangling.
09:13:01 <locosage> may have performance issues
09:13:17 <locosage> depending on how the implementation is for low element count though
09:13:25 <andythenorth> FML, why am I in a world of boot looping Steam Decks
09:13:43 <peter1138> GoodsEntry goods[64]; is not a lightweight structure either.
09:13:48 <andythenorth> my browser tabs are all crap like 'install Win11 on Steam Deck'
09:13:51 <andythenorth> I hate technology
09:14:19 <truebrain> we can just measure performance 🙂
09:15:06 <locosage> peter1138: well, yeah xD
09:15:17 <locosage> but something like list of pairs may be better than map
09:15:23 <truebrain> lol, I forgot we write all crashlogs in the root folder .. messy 😄
09:15:32 <locosage> or just shortcut map allocation for a single cargo case
09:15:50 <truebrain> `Crash dump written to /home/micro/.local/share/openttd//0829266e-6dc4-4139-4bdd7f9e-1b8f1ecf.dmp. Please add this file to any bug reports.`
09:15:54 <truebrain> linux crash.dmp files!
09:16:24 <truebrain> $ ls -lh ~/.local/share/openttd/crash202* | wc -l
09:16:53 <truebrain> no, dating back to 2022
09:17:20 <truebrain> sadly, I can't influence the name the file is given there
09:20:20 <truebrain> `Crash dump written to /home/micro/.local/share/openttd/crash20230816092014.dmp. Please add this file to any bug reports.`
09:20:24 <truebrain> nothing that can't be fixed in post 🙂
09:21:01 <peter1138> Pool of GoodsEntries...
09:23:21 <locosage> pool doesn't seem to make a difference here as every entry belongs to only one station
09:23:28 <peter1138> Although pools are not contiguous chunks any more, an array of pointers is not really worse.
09:24:32 <_glx_> Something that only store used GoodEntries and a bitmap telling which IDs are stored ?
09:25:43 <locosage> depending on what operations are done it may not even need bitmap
09:25:47 <truebrain> ` 6 openttd!HandleKeypress(unsigned int, char32_t) [window.cpp : 2675 + 0x9]` <- w00p, I can even decode the minidumps 🙂
09:26:01 <_glx_> Might need a custom object to combine both
09:26:09 <locosage> though I guess bitmap can be a way to store cargo type
09:27:05 <_glx_> We have a function iterating set bit numbers
09:27:09 <andythenorth> is `pragma` too ambiguous?
09:29:13 <locosage> btw, having a custom vector implementation with shortcuts for 0 and 1 items can be useful
09:29:23 <andythenorth> global_pragma will do then
09:36:06 <_jgr_> I'm using that sort of pattern for FlowStat
09:37:02 <_jgr_> You can end up with millions of them on a big map, so it's worthwhile to keep them trim
09:37:46 <_jgr_> struct Station might be chunky but that there aren't that many of them
09:41:24 <cryoshakespeare> I'm not sure what the etiquette for asking about GRF related questions is here, since this seems to be more about source development and patches, but does anyone know if the vanilla game vehicles exist in editable NML format anywhere?
09:42:06 <cryoshakespeare> (And I'm mostly reposting here from add-on because it's more active, but will remove if faux-pas <.<)
09:42:21 <_jgr_> No, they're built in to the game
09:42:35 <_jgr_> The OpenGFX+ GRF is probably the closest you'll get
09:42:57 <cryoshakespeare> I see, thank you!
09:43:26 <cryoshakespeare> Also, man, cool to see devs active here. Thanks for your work JGR, the patch pack is awesome :)
09:43:41 <cryoshakespeare> (and to everyone else ofc), anyway, I'll take a look into that^^
09:43:44 <_jgr_> Thanks, the vanilla devs do most of the work though
09:49:44 <peter1138> So flowstat is a std::map but...
09:50:30 <_jgr_> 90% of the time it only contains 1 value
09:52:25 <_jgr_> It doesn't actually need to be a map either
09:53:45 <peter1138> FlowStat is magic to me -- I don't know what it does, I don't know what it's for, and I don't know why 🙂
09:53:59 <peter1138> (I assume it's cargodist related)
10:04:59 <peter1138> Damn these C++ features that are "easier" to use but waste memory :p
10:05:09 <peter1138> Port back to C when?
10:06:00 <alfagamma_0007> Rewrite in Rust when?
10:06:39 <Eddi|zuHause> right after the rewrite in java
10:06:53 <peter1138> That's after we do Delphi?
10:06:57 <_jgr_> There are C++ libraries for more efficient containers
10:07:04 <peter1138> I think Belugas had a head start on that.
10:08:55 <Eddi|zuHause> locosage: was that the one where he took a decades old version?
10:13:58 <andythenorth> cryoshakespeare: it's maybe possible to modify the properties of the default vehicles via nml, without having to recreate them entirely
10:14:08 <locosage> Eddi|zuHause: yep xD
10:14:22 <peter1138> Yes of course that's possible.
10:16:18 <peter1138> You don't skip properties when defining new vehicles, because you need to be sure what the values are. Not because anything forces you to set all properties.
10:18:16 <cryoshakespeare> So, I can create a GRF which uses the names/ids of the base game vehicles, and then only include a property for their cargo capacity?^
10:18:58 <Eddi|zuHause> you can make a grf that just changes cargo capacity.
10:19:07 <Eddi|zuHause> just leave out all the rest
10:19:31 <cryoshakespeare> Thank you, wise ones :dalaipray:
10:19:45 <peter1138> It's not that simple, (in most cases) doing so will duplicate the original vehicles.
10:20:28 <peter1138> Actually maybe it won't as long as there's only 1 NewGRF doing it
10:20:34 <peter1138> I wish I knew how I wrote this 😄
10:21:51 <cryoshakespeare> I guess I can be the test monkey and find out
10:25:15 <cryoshakespeare> Come to think of it, FIRS might be editing the vanilla ships to allow them to transport fish and sand.
10:28:28 <peter1138> Shouldn't be, vehicles have cargo classes that allow approximations for cargo compatibility.
10:32:06 <cryoshakespeare> Now the only question is figuring out where to find the IDs for the vanilla vehicles
10:35:58 <andythenorth> it's in the grf wiki
10:41:35 <cryoshakespeare> It seems I'd use these for making a GRF in NFO as opposed to NML
10:44:32 <cryoshakespeare> There's definitely a funny quality here of me being completely out of my depth in doing the most basic thing, while asking advice from people who develop the source code for the whole game. I'll try to figure it out myself, but thank you all for your help^ :)
10:45:21 <cryoshakespeare> Oh? Another breadcrumb...
10:46:05 <alfagamma_0007> Pretty much difficult
10:48:10 <Eddi|zuHause> if all you want to do is change a single property, NFO isn't that bad...
10:48:45 <Eddi|zuHause> but you can also do it with NML, using the same IDs
10:49:31 <_jgr_> NFO is pretty much a write only language
10:49:49 <cryoshakespeare> I'm just unsure of where exactly I put the ID in the NML, in the item() section?
10:50:04 <_jgr_> Unless you meticulously comment everything, you'll come back two weeks later to a load of numbers which don't mean anything to you
10:51:01 <_glx_> Yes you put the ID in item section
10:51:47 <cryoshakespeare> Alright, so just "item(FEAT_SHIPS, 0)" for the oil tanker, for example
10:52:09 <_glx_> You need to name your item before the id
10:52:35 <cryoshakespeare> Right, but if I'm changing a vanilla ship, then would the name not cause it to be treated as a separate item?
10:53:04 <_glx_> It's an I internal name only used by nmlc
10:54:14 <peter1138> > The first argument is the feature of the item, the second (optional) argument is the name used to identify the object throughout the NML file and the third (optional) argument is the numerical id you want to use for this item.
10:54:23 <peter1138> `item (<expression> [, <ID> [, <expression> [, <expression>]]])`
10:54:31 <peter1138> Not entirely clear with that 🙂
10:56:04 <cryoshakespeare> So.. to change a vanilla ship's cargo capacity to some number?
10:56:04 <cryoshakespeare> `item(FEAT_SHIPS, item_mps_oil_tanker_0) {
10:56:04 <cryoshakespeare> cargo_capacity: 42069;
10:56:17 <cryoshakespeare> It feels odd that it would be so simple
10:56:51 <peter1138> You need the numeric ID in the item line, otherwise it will create new engine.
10:57:15 <peter1138> `item(FEAT_SHIPS, item_mps_oil_tanker_0, 0) {` (if it's ID 0)
10:57:38 <peter1138> At least, I think so..
10:58:14 <truebrain> _glx_: the pdb is only useful with the crash.dmp right? That is to say, if I start storing the symbols for analyze crash.dmps on a symbol-server, we don't need to publish the pdb, right?
10:58:19 <_glx_> I think it will use 0 for first item by default, but it's better to be explicit here
10:58:59 <_glx_> Nfo output can confirm it
10:59:46 <_glx_> Well in nfo it won't be 0 because first ship is not 0 😉
11:00:13 <_glx_> Nmlc does the translation
11:00:53 <_glx_> truebrain: Pdb can still be useful for manual dump analysis
11:01:02 <truebrain> can you make "manual dump"?
11:01:26 <truebrain> if you mean the crash.dmp, you can just point to the symbol server for that
11:01:33 <truebrain> means no longer finding the right pdb 😄
11:01:39 <cryoshakespeare> _glx_: So, of the options here for the oil tanker, I should be using 204 as the ID? item(FEAT_SHIPS, item_mps_oil_tanker, 204) {
11:02:20 <cryoshakespeare> Oh sorry, you were talking about NFO
11:02:23 <_glx_> And it seems nfo is smart too
11:02:28 <truebrain> _glx_: mostly wondering if there isn't any other purpose for the pdb, outside the `crash.dmp`
11:02:49 <_glx_> No it's only for crash dmp
11:03:27 <_glx_> And to attach running exe to debugger, but symbol server should be fine for that too
11:04:05 <truebrain> the main thing breakpad symbols are missing, are things like inline functions
11:04:08 <truebrain> pdb does seem to contain that
11:05:05 <andythenorth> ok now to see if I can parse existing .lng translations to my toml format
11:10:51 <andythenorth> oof I'll have to write some python split lines thing 😛
11:23:32 <truebrain> hmm .. mingw didn't create crash.dmp files .. not sure why not ..
11:24:18 <truebrain> _glx_: I need an opinion .. I can either use breakpad on Windows too, to create the crash.dmp (unifying all platforms), or I can keep the current (clearly functional) way of creating a crash.dmp .. it is a bit: unify but extra dependency, or keep custom and one less dependency ..
11:24:30 <truebrain> vcpkg supplies breakpad btw, so it is not really any issue to add the dependency
11:26:55 <peter1138> it's not in Debian.
11:27:22 <truebrain> nope; no clue why .. so that is another question we have to answer .. do we make vcpkg kinda mandatory, or do we embed breakpad in our source tree 🙂
11:33:20 <cryoshakespeare> It's a thing of beauty, thank you all for your help on this(: Now to actually make something useful :P
11:33:21 <_glx_> truebrain: Because we could not use them anyway ?
11:34:21 <truebrain> let's see what the CI is thinking here ..
11:35:11 <_jgr_> MinGW debugging symbols are DWARF, not microsoft's PDB
11:35:21 <truebrain> but a minidump is a minidump 🙂
11:35:34 <truebrain> you just need to build the executable with RelWithDebInfo
11:36:07 <_glx_> You need a tool to read them, and msvc was the only one for a long time
11:36:21 <truebrain> ah, like that, yeah, okay
11:36:30 <truebrain> so the lack of symbol-server was the reason, basically 🙂
11:38:34 <_glx_> A new dependency for windows binary is probably not an issue, but the exe size will increase I guess
11:39:30 <truebrain> I guess it depends whether we will vendor breakpad ourselves or not ...
11:39:46 <truebrain> seems to be the common thing to do for some reason
11:42:05 <truebrain> `unofficial::breakpad::libbreakpad` is also a bit weird of vcpkg .. many weird things 😛
11:42:12 <truebrain> okay, let's try vendoring ..
11:42:35 <andythenorth> I have tomlkit 0.12.1 but I can't find toml_file in it
11:42:51 <andythenorth> `dir(tomlkit)` gets me `['TOMLDocument', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '__version__', '_compat', '_types', '_utils', 'aot', 'api', 'array', 'boolean', 'comment', 'container', 'date', 'datetime', 'document', 'dump', 'dumps', 'exceptions', 'float_', 'inline_table', 'integer', 'item', 'items', 'key',
11:42:51 <andythenorth> 'key_value', 'load', 'loads', 'nl', 'parse', 'parser', 'register_encoder', 'source', 'string', 'table', 'time', 'toml_char', 'toml_document', 'unregister_encoder', 'value', 'ws']`
11:43:53 <andythenorth> ach, I'll just dump the toml to a file
11:44:18 <truebrain> ugh, an autoconf product ... I hate those 😄
11:52:41 <truebrain> it makes me a bit unsure how easy it will be to embed this
11:52:55 <truebrain> or vendor, or what-ever
11:53:57 <_glx_> Autoconf is a pain, checking so many useless things
11:54:38 <_glx_> You can have 5 minute configure for something compiling in less than 30s
11:56:30 <truebrain> I don't like these bulky libraries .. it needs shit like "logger" and more
12:07:06 <locosage> oh, looks like setting wrong data offset in grf file can crash openttd...
12:07:17 <locosage> though I guess broken newgrfs crashing the game is nothing new
12:08:55 <andythenorth> is it stupid to load and parse all the .toml files in a lang dir?
12:09:16 <andythenorth> tinfoil applies?
12:24:59 <truebrain> okay, embedding of breakpad is not going to work .. our rules are a lot stricter 😛 So vendoring seems the only sane alternative, but as they use another config system, that is non-trivial to integrate ...
12:25:40 <truebrain> why are these things always more complicated than they have to be ...
12:35:54 <truebrain> right, so vcpkg and optional it is!
12:40:19 <truebrain> it is such a weird library ... owh well. It is what it is.
12:42:42 <_glx_> did a quick check because `FILEVERSION 14,0,0,20230814` is not completely valid (though compiler doesn't complain unless using clang), and the 20230814 part is actually GB(20230814, 0, 16) but it's fine for nightlies they still get a unique combo
12:43:26 <_glx_> symbol server uses this version I think
12:43:45 <truebrain> breakpad symbol server uses a hash over the binary (which is stored in the minidump)
12:43:48 <truebrain> which is pretty nice
12:43:58 <truebrain> no clue if the pdb symbol server is all that different
12:44:46 <_glx_> looks like some kind of hash
12:44:57 <truebrain> yeah, I think they in fact share the same thing as breakpad symbols
12:45:09 <truebrain> if you look in those folders, there are .sym files .. are they plaintext?
12:45:12 <truebrain> and what is the first line?
12:47:13 <_glx_> those folders only contain advapi32.dll actually
12:48:29 <truebrain> ah, okay, Windows does it like that
12:51:07 <truebrain> right, now to figure out how `link_package` works, as it breaks 😛
12:51:10 <truebrain> I keep forgetting 😄
12:52:52 <_glx_> it uses the target if it's provided, else it adds includes and libraries
12:53:22 <truebrain> yeah, but it also expects some things to be set I remember
12:53:57 <_glx_> message(STATUS "${NAME} found -- -DWITH_${UCNAME} -- ${${NAME}_INCLUDE_DIRS} ${${NAME}_INCLUDE_DIR} -- ${${NAME}_LIBRARIES} ${${NAME}_LIBRARY}")
12:54:05 <andythenorth> how did "draw boats for Sam" turn into "learn TOML for a no-visible result" refactor of Horse?
12:54:17 <truebrain> ah, the `${NAME}_FOUND` is what I was looking for
12:54:40 <_glx_> ha yes and ${NAME} is case sensitive
12:56:01 <truebrain> more importantly, what is that name going to be, and is found set 😄 Always a challenge 😉
12:58:45 <truebrain> `-- unofficial-breakpad found -- -DWITH_UNOFFICIAL-BREAKPAD -- unofficial::breakpad::libbreakpad_client`
13:00:42 <truebrain> `#define WITH_UNOFFICIAL-BREAKPAD 1` .. our code doesn't like the `-` 😄
13:10:29 <LordAro> "our code" ? cpp, you mean :p
13:12:23 <_glx_> missing codeql.yaml update 🙂
13:13:12 <truebrain> yeah, codeql will run without breakpad
13:13:16 <truebrain> I need to remove the diff there 🙂
13:21:30 <truebrain> ugh, the Mac header is different from the Linux header
13:22:25 <truebrain> `No rule to make target '/usr/debug/lib/x86_64-linux-gnu/liblzo2.so', needed by 'openttd'. Stop.` ... eeeuuhhh?
13:23:20 <truebrain> I didn't touch that
13:23:23 <truebrain> why did that change?
13:23:26 <truebrain> that is odd that it changed 😛
13:24:37 <andythenorth> we ever going to add articulated ships?
13:24:47 <andythenorth> am about to refactor my ship grf 😛
13:25:11 <_glx_> looks like a missing lib to me
13:25:46 <_glx_> or the OS did some changes and cmake didn't notice
13:31:01 <truebrain> it is a weird error .. lzo is detected and everything
13:31:44 <_glx_> yeah `-- Found LZO: optimized;/usr/lib/x86_64-linux-gnu/liblzo2.so;debug;/usr/debug/lib/x86_64-linux-gnu/liblzo2.so (found version "2.10")`
13:31:59 <truebrain> ah, no, the `/debug` part is new
13:32:03 <truebrain> older runs doint have that
13:32:09 <truebrain> that might be that vcpkg is now added
13:32:21 <truebrain> something to toy with in a bit 🙂
13:32:54 <_glx_> oh vcpkg detected but the lib is not from vcpkg
13:34:16 <_glx_> might need fine tuning with VCPKG_ROOT checks
13:37:19 <_glx_> oh VCPKG_INSTALLED_DIR might be useful
13:39:42 <_glx_> let's check cmake cache and see how I can improve this part
13:40:44 <_glx_> ok `VCPKG_INSTALLED_DIR:PATH=C:/vcpkg/installed`
13:41:09 <_glx_> shouldn't be too hard to improve
13:41:19 <truebrain> no worries, I am working on this 🙂
13:41:43 <peter1138> andythenorth: Doesn't JGRPP have it?
13:46:19 <talltyler> Okay C++ wizards, I need some help. I am moving everything in `date_type.h` to timer files, as a separate PR to prepare for the calendar/economy date split.
13:46:19 <talltyler> In `timer_game_calendar.h`, `static constexpr Date DAYS_TILL_ORIGINAL_BASE_YEAR = DateAtStartOfYear(ORIGINAL_BASE_YEAR);` cannot find the definition for `DateAtStartOfYear()` since it's in the `timer_game_calendar.cpp`. I can't define it in the header without losing the constexpr...and anything else would be a circular reference. What do I do?
13:47:28 <_glx_> my local test with `if(VCPKG_TOOLCHAIN AND LZO_LIBRARY AND LZO_LIBRARY MATCHES "${VCPKG_INSTALLED_DIR}")` seems to work fine on windows (that is it still converts the paths)
13:47:53 <_jgr_> peter1138: Yes, it is still experimental though
13:57:34 <andythenorth> I saw the multi-hold thing
13:57:42 <andythenorth> I missed articulated
14:02:25 <_jgr_> It is implemented in much the same way as articulated road vehicles in terms of the GRF interface, but there isn't any support for something like an articulated chain of barges, if that's what you mean
14:11:22 <peter1138> What does that mean?
14:13:02 <_jgr_> To get more than cargo, you need more than one `struct Vehicle`, which means an articulated consist
14:13:11 <truebrain> talltyler: as we do with everything in C++: define `DateAtStartOfYear` in the header too 🙂
14:14:39 <talltyler> It still says it's not defined 😦
14:15:00 <talltyler> I tried that earlier as well
14:15:02 <_jgr_> These extra parts are not drawn and are not positioned independently
14:15:16 <truebrain> talltyler: bit weird, that if you define both in a header it isn't defined 😄 Sounds like something else is going on 🙂
14:15:28 <talltyler> I have it as `static constexpr Date DateAtStartOfYear(Year year)`, does it have to be `inline`?
14:15:36 <talltyler> Because then it's not constexpr and it complains about that 🙂
14:16:08 <truebrain> this is normally where I start up VSCode CodeShare 😛
14:16:18 <truebrain> as this kind of online help is .... difficult 🙂
14:18:39 <truebrain> At work atm, so I can't 😦
14:18:44 <peter1138> _jgr_: Ah okay, so it's purely for multiple cargo types.
14:19:26 <peter1138> Given the turning ability of ships, that's sensible 🙂
14:20:24 <truebrain> w00p, vscode fixed that if you press indent on a comment-block, the extra space before the `*` are preserved
14:20:27 <talltyler> Ping me later if you have time, maybe?
14:22:46 <truebrain> talltyler: if I would be to guess, you run into the issue that a class is still incomplete, and as such, `constexpr` doesn't work yet. Bit tricky to work around that, honestly.
14:23:15 <talltyler> You mean, a limitation in C++ spec?
14:23:33 <truebrain> limitation is a big word, but the function is declared at that point, not defined yet
14:23:41 <truebrain> and a non-defined function cannot be a constexpr (yet)
14:24:02 <truebrain> just the way C++ files are parsed
14:24:15 <truebrain> if you would put the DateAtStartOfYear in a parent class, it would work
14:24:19 <truebrain> but it gets a bit silly at that point 🙂
14:24:32 <talltyler> Yes, that sounds like an ugly kludge
14:24:39 <talltyler> TimerGameCommonParent 😛
14:24:45 <talltyler> TimerGameGrandparent
14:25:18 <truebrain> it was a bit of a hack to start with, calling a constexpr function from a constexpr value initializer 😄
14:26:04 <truebrain> and the more I look at the timer stuff, the more I wonder if there isn't a nicer way to make these functions work for calendar and economy .. that often happens once one does the work, you look at it, and go .. hmmmm .. what other options do we ahve
14:26:08 <truebrain> I just haven't found one 😛
14:27:38 <talltyler> So far I'm liking class inheritance where I can pick and choose what to inherit as-is and what to define separately in each subclass
14:28:12 <talltyler> I'm not using overrides so far, since there are only two subclasses -- just moving stuff out of the parent if it's not identical in each
14:29:04 <talltyler> Once I get to Real Time Mode where economy time sometimes works just like calendar time, I'll split that into a helper function that can be inherited, and then each subclass can choose whether to call the helper function or do its own thing
14:29:20 <truebrain> that is the idea yeah 😄
14:29:26 <truebrain> which works marvelous for functions
14:29:28 <talltyler> So it's really just a question of how to fix the constexpr :/
14:29:31 <truebrain> for the constants, it is a bit tricky
14:30:36 <talltyler> I mean, `DAYS_TILL_ORIGINAL_BASE_YEAR` could just be a pre-computed magic number... 🫣
14:30:56 <truebrain> well, that is what the compiler does anyway, so there is an argument to be made 😛
14:31:47 <truebrain> `static constexpr Date DAYS_TILL_ORIGINAL_BASE_YEAR{DateAtStartOfYear(ORIGINAL_BASE_YEAR)};` <- this is why I don't like the `{}` notation without spaces peter1138 😛
14:31:53 <truebrain> that becomes a mouth-full 😛 😄
14:33:19 <truebrain> sorry talltyler , I don't see a clean way to do this
14:33:39 <talltyler> Is a magic number an acceptable unclean way?
14:33:46 <andythenorth> I don't need the capabilities of the toml lang in 80% of the cases, but 20% do need it
14:34:11 <truebrain> talltyler: with the right comment, it can't hurt
14:34:24 <talltyler> Now I just need to actually compute it 😛
14:35:31 <peter1138> You could put the function outside of the classes?
14:36:11 <truebrain> this works talltyler
14:36:17 <truebrain> a delayed assignment
14:36:28 <truebrain> I am a bit surprised it is allowed, but whatever
14:37:05 <truebrain> peter1138: if you put the function outside, the variable also needs to be outside 😛
14:37:13 <peter1138> I don't think it's the end of the world if some of those constants are outside though.
14:37:30 <truebrain> owh, my gist is broken
14:37:44 <truebrain> it doesn't do what you think it does 😄
14:38:02 <peter1138> You can then declare the constant inside the class, using the value from outside the class, I think.
14:38:06 <truebrain> it just declares a global `DAYS_TILL_ORIGINAL_BASE_YEAR` .. it doesn't set the class member 😄
14:38:41 <truebrain> `DateAtStartOfYear` can't be defined before the class, as it depends on types defined in the class. So there is very little room to navigate here 🙂
14:39:20 <truebrain> but having `DAYS_TILL_ORIGINAL_BASE_YEAR` not as a class member might be the cleanest solution here
14:39:33 <truebrain> so basically my gist without the `static constexpr Date DAYS_TILL_ORIGINAL_BASE_YEAR;`
14:40:40 <talltyler> MAX_DATE would need to move too
14:41:34 <truebrain> other solution is to demote those 2 from `constexpr` to `const`
14:41:35 <talltyler> One problem with moving them outside is that they are used as both calendar and economy dates later, so they would need to be duplicated or cast
14:41:53 <truebrain> their name would have to be different for each, yes 🙂
14:42:17 <truebrain> but their name is already different .. either by prefixing the class, or by having it in their name
14:42:20 <truebrain> functional, not that much difference
14:42:25 <talltyler> Cannot be const: `a member of type "TimerGameCalendar::Date" cannot have an in-class initializer`
14:42:50 <truebrain> `static const Date DAYS_TILL_ORIGINAL_BASE_YEAR;` inside the class
14:42:56 <truebrain> `const TimerGameCalendar::Date TimerGameCalendar::DAYS_TILL_ORIGINAL_BASE_YEAR = TimerGameCalendar::DateAtStartOfYear(TimerGameCalendar::ORIGINAL_BASE_YEAR);` outside the class
14:43:17 <truebrain> but at that point you are better off just creating a `CALENDAR_DAYS_TILL_ORIGINAL_BASE_YEAR` as constexpr 🙂
14:43:41 <talltyler> I am still preferring magic numbers, personally. Besides breaking the "no magic numbers rule", I think it would be cleaner elsewhere in the code
14:44:04 <truebrain> elsewhere in the code you are debating `TimerGameCalendar::DAYS_TILL_ORIGINAL_BASE_YEAR` vs `CALENDAR_DAYS_TILL_ORIGINAL_BASE_YEAR`
14:44:26 <truebrain> I think the "no magic number" rule is going to beat you there 😛
14:44:50 <talltyler> Agreed, but everything else is in that class, I don't really like having one exception
14:44:59 <truebrain> there are two exceptions!
14:45:04 <truebrain> and that is C++ .. we can't get everything we want 🙂
14:45:34 <truebrain> if I were you, I would move them outside for now, and get everything working .. we can paint this shed in different colours when everything works 🙂
14:48:21 <truebrain> one could also argue we could make a small class called Calendar or something for all constants .. as TimerGameCalendar::.. gets so lengty 😛 But again, it is just the colour of the shed 🙂
14:50:10 <talltyler> Yeah, that would be good
14:52:52 <truebrain> waiting on mingw is like watching paint dry
14:54:47 <truebrain> `ignoring '#pragma warning ' [-Wunknown-pragmas]`
14:54:53 <truebrain> so a warning about trying to mute a warning
14:59:26 <_glx_> tried defining the function directly in the header ?
15:12:29 <talltyler> Ugh, all sorts of things are broken
15:15:39 <truebrain> w00p, MacOS also compiled!
15:21:09 <andythenorth> hmm multi-cargo ships for Sam though?
15:22:37 <truebrain> okay, that PR should now be functional. We just need to test OSX
15:22:49 <peter1138> Well, you know how it is.
15:23:10 <truebrain> building a release for that; means we can check the release pipeline, and ask someone to test a binary 😄
15:35:57 <_glx_> hmm release builds are hard to crash 🙂
15:54:42 *** Wormnest has joined #openttd
16:54:07 *** gelignite has joined #openttd
17:11:19 <truebrain> _glx_: Haha, oops .. guess I will need to start my VM in that case 🙂
17:14:28 <_glx_> oh nice we have an easy way to crash linux build 🙂
17:23:35 <truebrain> owh, mijn MacOS VM is on an old old system ... a job for this weekend 🙂
17:29:02 *** Smedles_ has joined #openttd
17:32:11 *** Smedles has quit IRC (Ping timeout: 480 seconds)
18:11:56 <truebrain> we will figure out eventually how to do this correctly 😛
18:12:06 <truebrain> _jgr_: you tested that MD5 strings in NewGRF window still looks good?
18:12:27 <_jgr_> Yes, it seems to split/layout fine as I resize the window
18:12:48 <truebrain> that was the initial issue, that segments that had no splits had to be split, and things went BOOMMMM 😛
18:38:57 <DorpsGek> - Update: Translations from eints (by translators)
18:53:11 <truebrain> trying to start MacOS in VirtualBox ... ssssslllllloooooowwwwwwwwwww
18:54:50 <truebrain> still only seeing white text about starting things, and not finding things ..
18:54:53 <truebrain> I hope it continues some day 😛
19:03:19 <truebrain> don't think it is going to boot 😛
19:11:48 *** k-man__ has joined #openttd
19:17:06 *** k-man has quit IRC (Ping timeout: 480 seconds)
19:17:06 *** k-man__ is now known as k-man
19:18:51 *** k-man_ has quit IRC (Ping timeout: 480 seconds)
19:22:21 <truebrain> this time I actually do 😛
19:33:07 <truebrain> hmm .. changed some settings .. now it doesn't want to boot at all 😛
19:46:51 *** gelignite has quit IRC (Quit: Stay safe!)
19:55:53 <truebrain> okay, Virtualbox still is a no-go for MacOS. Lets try VMWare 🙂
19:56:50 <dwfreed> Fusion is pretty good
19:57:08 <dwfreed> or you mean running MacOS in a VM
19:57:11 <truebrain> Fusion is not helping me 😄
19:58:37 <dwfreed> you will need to patch VMware Workstation in order to run MacOS; obviously MacOS still doesn't support running on anything other than Apple hardware
19:59:00 <truebrain> I am aware; not my first rodeo 😄
19:59:07 <truebrain> was juist hoping VirtualBox fixed their issues by now :()
20:11:38 <_glx_> at least you have an intel cpu
20:12:49 <peter1138> I do have an ARM desktop, but...
20:13:30 <peter1138> 48MHz ARM7500FE isn't quite the modern ARM I want 🙂
21:07:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:24:53 <truebrain> at VMWare is kinda working .. slowish, but we know that 🙂
21:43:58 <truebrain> updating to 13.5, w00p
21:53:10 <peter1138> But we're only up to 13.4.
21:55:23 <truebrain> Apple seems to disagree 😦
21:58:22 <truebrain> 12GB update ... yeah, that is going to take a while 😄
21:58:34 <truebrain> not the downloading; that finished really quickly
22:36:11 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:37:26 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
