IRC logs for #openttd on OFTC at 2024-06-08
⏴ go to previous day
02:08:59 *** tokai|noir has joined #openttd
02:08:59 *** ChanServ sets mode: +v tokai|noir
02:10:14 *** Wormnest has quit IRC (Quit: Leaving)
02:16:05 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:22:50 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:01:01 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:42:18 <DorpsGek> - Update: Translations from eints (by translators)
04:46:49 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
07:40:53 <peter1139> Hmm, 40 or 50 miles...
07:49:54 <andythenorth> My bike battery only lasts about 12 miles
08:19:45 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
08:21:25 *** SigHunter has joined #openttd
08:24:32 <pickpacket> Did I finally manage to make my PR in the right format yesterday?
08:27:44 *** Smedles has joined #openttd
08:58:54 *** salut3585 has joined #openttd
09:42:26 <FLHerne> it looks like a really neat feature :-)
09:47:09 <xarick> how does keyboard localization works in openttd
09:48:38 <xarick> doesn't look like a portuguese keyboard
10:26:25 <_glx_> It's whatever translators decided to write
12:24:26 *** asymptotically2 has quit IRC (Remote host closed the connection)
12:24:31 *** asymptotically2 has joined #openttd
12:32:43 <peter1138> Bugs me that Hebrew doesn't have a custom layout.
12:33:06 <peter1138> Makes it harder to enter RTL hebrew letters.
15:11:22 <peter1139> Hmm. `std::span<uint8_t> buf` or `uint8_t *first; uint8_t *last;`?
15:11:51 <peter1139> Latter allows `++first;`, former requires `buf = buf.subspan(1);`
15:34:02 *** Wormnest has joined #openttd
15:53:26 <peter1139> Damn, dynamo USB chargers are expensive :(
17:29:05 <andriydohniak> That is me, I need some comments/help
17:40:56 <talltyler> Organizing your commits would help the review process 🙂
17:41:26 <talltyler> Helps us see what you’re doinf
17:41:57 <andriydohniak> talltyler: I can do that, but it will take time. But for now, should I just squash everything?
17:43:06 <andriydohniak> There is no real history / intent to my commits, I tried a thing, then saw some bugs, fixed some bugs and repeat
17:43:27 <andriydohniak> but I can sqash all the commits, and then split them back up by logical chunks
17:44:00 <talltyler> That would make the most sense I think
17:44:15 <talltyler> That’s how I work, anyway
17:44:59 <andriydohniak> talltyler: You first do the work, and then organize your commit history? Or you work means you like reading organized commit history
17:45:46 <Eddi|zuHause> if you're a real wizard, you organize it by logical steps first, and then modify each commit as you fix bugs
17:46:18 <yiffgirl> why is `GB` called `GB`?
17:46:39 <truebrain> lol, I like how m9 is just instantly a 32bit value 😄
17:46:40 <andriydohniak> Eddi|zuHause: wow! That would be really magical, but in this case I had no idea what I was doing, and I learned what needs to be done as I tested and wrote code
17:47:01 <truebrain> so we go from 10 bytes per tile to 14 bytes 😄
17:47:05 <andriydohniak> truebrain: but It frees up some space in the m1, m5 (sometimes) and m7 (sometimes)
17:47:08 <truebrain> not sure that is actually needed (or wanted 😛 )
17:47:22 <truebrain> andriydohniak: sure, but it also uses 40% more memory for EVERY GAME out there 😛
17:47:27 <talltyler> Both, when I’m writing code I tend to get the first draft working and then organize into logical commits. Then as I’m fixing things I squash as I work with interactive rebases.
17:47:27 <talltyler> Reviewing code I like to go by commit so I can see which ideas go together
17:47:53 <truebrain> the most painful part of OpenTTD .. getting more information on the map, without all the people not using the new functionality to suffer 😦
17:48:59 <andriydohniak> truebrain: Is there a chance that after I fix the commit history, and all other UI / DOC issues this will get merged even with such a jump in memory ussage?
17:49:37 <truebrain> I cannot predict how other developers think about this; but for sure it is a problem that needs consideration 🙂
17:49:59 <truebrain> From experience we also know it could have a big impact on performance, for example because of cache-misses
17:50:03 <truebrain> so it needs decent benchmarking too
17:50:31 <truebrain> owh, wait, it goes from 12 to 16, so it is not 40%, a bit less 😛
17:50:40 <yiffgirl> i wonder how possible it would be to split the map up into separate feature arrays
17:51:06 <peter1138> There are 12 bits already used, to go to 250 companies you need another 12, not 32. But that requires shuffling, or splitting.
17:51:12 <truebrain> yiffgirl: so many attempts have been done over the years .. so many ... soooo mannyyyyyyyyyy
17:51:22 <talltyler> I personally don’t see a strong usecase for so many companies — performance will make the game unplayable long before you see the benefits of so many companies
17:51:23 <Eddi|zuHause> yiffgirl: the main issue with that is tiles which mis-use bits for other purpose
17:51:26 <truebrain> but it is hard to design anything that is about as fast as the current variant .. like, crazy hard 🙂
17:51:52 <talltyler> I could see the value of 32 companies, but 240 seems excessive
17:52:51 <Eddi|zuHause> we could potentially go to 30-ish companies if we "find" a bit here and there to pad the 4-bit ones to 5-bit, while keeping the existing 5-bit ones for none/town/whatever owner
17:53:08 <peter1138> that would also solve the bitmask storage issue
17:53:11 <talltyler> Of course, my argument is not against the change to the code, but the change to the memory performance of all games, even single-player and the majority of multiplayer games
17:53:12 <andriydohniak> talltyler: Currently there are a bunch of OpenTTD servers (At least 1 lol) that are split into multiple with complex communication channels because of this limit
17:53:20 <andriydohniak> peter1138: I did solve that
17:53:42 <andriydohniak> It does take up more memory, but not too much, because the map takes up most of the save space anyway
17:53:59 <andriydohniak> And I also added compatibility with old saves (As far as I know)
17:53:59 <peter1138> I mean in a much simpler way 🙂
17:54:04 <Eddi|zuHause> andriydohniak: savegame space is not the same as memory.
17:54:27 <andriydohniak> Eddi|zuHause: yea, there is a translation between, but in this case both increase
17:54:38 <talltyler> As you’re going through your commits you might see if there are any fixes/cleanups you’ve made that would benefit OpenTTD even without the rest of your changes, and make separate PRs for those 🙂
17:54:48 <truebrain> anyway, map storage issues is the reason many other ideas never came to be; it is hard to make it work for most of the games, and not just a few 😦
17:55:07 <truebrain> but michi_cc said he was going to continue his newmap branch 😛
17:55:14 <truebrain> (he said that only a few times in the last few years 😄 )
17:55:33 <Eddi|zuHause> sure. and MB is still working on DBSet :p
17:55:35 <andriydohniak> talltyler: There aren't many, I can remember 1 or 2 minor ones, but not anything actually helpfull
17:56:51 <andriydohniak> So as far as I understand the current consensus among you, devs is that adding 32 bits to every tile is too much to be merged
17:57:20 <truebrain> do you find it reasonable, to increase the memory with 33% for every game, just for more companies? 🙂
17:57:21 <Eddi|zuHause> it's not "too much" per se, but you need a better argument for it.
17:57:56 <truebrain> make us believe it is, if you believe it yourself, and we can talk 🙂
17:58:18 <andriydohniak> truebrain: Dammit! that's a good point!
17:59:04 <truebrain> I for one am not against some memory increase to gain features; just the balance has to be found 🙂
17:59:06 <Eddi|zuHause> if you want to go crazy, you could completely separate map and ownership data, then you can dynamically resize the ownership map bits by whatever company number is needed
17:59:45 <andriydohniak> Eddi|zuHause: The issue is that A LOT of code expects a fixed size company data
17:59:58 <andriydohniak> and I will need to be able to resize the bitsets too
18:00:07 <talltyler> Thus why you would have to go crazy 😛
18:00:27 <andriydohniak> talltyler: I am VERY close to saying F-it, and giving it a try!
18:00:49 <Eddi|zuHause> we did have "crazy" contributors before. that's how we got YAPF and stuff :p
18:01:05 <truebrain> the list of "crazy" shit is long 🙂
18:01:28 <truebrain> from BaNaNaS to multiplayer to scalable GUI to daylength 😛
18:01:36 <peter1138> crayz shit: `std::unordered_map<TileIndex, VirtualTileData>`
18:01:44 <talltyler> But it would be interesting to have the map only store owners NONE, TOWN, LOCAL_PLAYER, and OTHER_PLAYER. The latter would point to another lookup table only used for multiplayer games.
18:02:04 <peter1138> That sounds completely impossible.
18:02:20 <Eddi|zuHause> well, OTHER_PLAYER would also include AIs
18:02:31 <truebrain> a map per player? 😄
18:02:47 <truebrain> we should never have done NoAI ... such a terrible thing 😦
18:02:55 <Eddi|zuHause> also, LOCAL and OTHER distinction might not be useful for most stuff (like moving vehicles)
18:02:58 <talltyler> I was thinking about taking a shortcut for singleplayer games, not splitting save data per client 🙂
18:03:31 <andriydohniak> Now on a more serious note:
18:03:31 <andriydohniak> - I have moved ALL the ovnership data from m1, m5, m7 to m9, which means I know all the places that require ownership information.
18:03:31 <andriydohniak> - We don't have to resize all that crap during the game, we can save the number of players during gamesave creation, and add compat to other saves
18:03:31 <andriydohniak> - We *can* use a separate array for the ownership information, making an impact on a normal 15 company game small
18:03:43 <Eddi|zuHause> also, i believe PLAYER is a misnomer :)
18:03:59 <Eddi|zuHause> (getting into bikeshedding territory here)
18:04:01 <andriydohniak> Then people who want to have a giant server map, can just crank that lever up
18:05:01 <Eddi|zuHause> andriydohniak: first question here would be, with the "freed" bits, can you actually shrink down the older map array?
18:05:51 <andriydohniak> Eddi|zuHause: prob not, because the owner info is 5 bits, and sometimes is used for other things, so you can't just fully delete that space
18:05:55 <Eddi|zuHause> if you, like, could reduce the 12 bytes to 11 bytes.
18:06:22 <Eddi|zuHause> andriydohniak: well, you might consider moving the "misused" bits into m9 as well
18:06:26 <andriydohniak> Eddi|zuHause: that would be INCREDIBLY hard, and require a rewrite of the storage system in the map array
18:07:40 <Eddi|zuHause> also, should m9 be uint32, or would 3x uint8 be a more efficient storage?
18:07:51 <yiffgirl> Moth-ToliasviaGitHub: my hypothesis is that this change (using four bits instead of three + 8) should make the tree grouping significantly more random. my computer isn't beefy enough to compile so just pushing to preview and checking there
18:07:54 <andriydohniak> Eddi|zuHause: We are here because packing bits way to close to each other makes modifications VERY difficult, I don't want to repeat that here, I would really like for all the info to be stored +- independently, so it can be modified in the future
18:08:40 <Eddi|zuHause> andriydohniak: sure, it might modification tricky, but it is one of the key reasons why openttd is "optimized"
18:08:44 <andriydohniak> Eddi|zuHause: True, And at first I wanted to make the max player limit 1024 (- some constants), and I am searching for feedback about weather it's worth doing, or 240 is enough
18:08:59 <peter1138> They're close to each other so that they fit into the available space and don't expand it more than necessary.
18:10:12 <andriydohniak> peter1138: yea, but when the game is being developed, because of this packing, and how difficult it is to modify that layout, some values had to be split, and use different bit locations depending on tile type, etc
18:10:26 <michi_cc> truebrain: Yes ™️ Last work was just 2 months ago. So like just yesterday 🤣
18:10:31 <Eddi|zuHause> here's the thing: currently you're going from 12 to 16 bytes per tile. if you can manage to cut out the freed bits from 12 to 11, and only add 3 more, you're now going from 12 to 14, which is a MUCH EASIER argument to make to justify increased memory usage
18:10:40 <andriydohniak> My issue is not just with how close they are, it's how close they are and how difficult it is to reorder them for modifications
18:11:13 <andriydohniak> Eddi|zuHause: I can do that VERY easily by only using 3x u8s
18:11:21 <andriydohniak> This will take ~ 10 min
18:12:11 <andriydohniak> actually no, from 12 -> 15 is easy
18:12:11 <peter1138> So a separate sparse storage for owners isn't the worst idea.
18:12:20 <peter1138> Many tiles have no ownership.
18:12:22 <andriydohniak> from 12 -> 14 is hard
18:12:22 <Eddi|zuHause> well, reordering is is pretty "simple" (:p), you just have to modify the map accessor, and make the shuffling in afterload.
18:13:14 <andriydohniak> peter1138: I was thinking about making the array size dependent on the game save, and still contain all the tiles, but then only people actually using large company limits would suffer, but still have compatibility
18:13:35 <andriydohniak> Because doing something like a hash map will be way to slow for no good reasono
18:13:50 <andriydohniak> memory is cheap, cpu time is not
18:13:52 <peter1138> But then your ownership accessors need become quite complex.
18:14:11 <Eddi|zuHause> i would quite disagree
18:14:34 <Eddi|zuHause> all the simulation games i play are much more hungry for memory...
18:14:54 <andriydohniak> peter1138: Not really, just an array(vec) indexing, with a little added complexity in the save/load
18:14:57 <peter1138> That's because memory is cheap and CPU time is not 🙂
18:15:09 <michi_cc> Shuffling bits in the map around is a bit annoying, but not really difficult. Basically it just boils down to replacing the map accesors in afterload/_sl.cpp with direct accesses and adding a simple loop in AfterLoad to relocate the bits.
18:15:42 <Eddi|zuHause> my memory was almost the same price as my processor. and the processor could somewhat cope much better over time
18:16:14 <andriydohniak> michi_cc: you are talking about making the memory layout more fluid, right?
18:16:17 <peter1138> I mean, "cheap" is not talking about the price you pay for it 🙂
18:16:30 <andriydohniak> peter1138: and that too
18:17:00 <andriydohniak> if you look at the memory price / GB over time and CPU compute / $ over time, memory is kinda cheap
18:17:23 <michi_cc> andriydohniak: It was just meant as a general comment that moving existing map bits to some other place (if it makes stuff better) is not something to be scared off.
18:17:51 <michi_cc> But of course it has to have some benefit. Moving for moving's sake is bad.
18:19:00 <peter1138> Ooh ice cream van! Where is it...
18:19:35 <Eddi|zuHause> i went on a bike ride today, which ended with an ice cream.
18:19:41 <andriydohniak> michi_cc: but that would probably reduce cpu misses, and allow for some memory saves, and if the work is done once, updating in the future will be much easier
18:19:59 <andriydohniak> But this would be a LONG project
18:21:00 <Eddi|zuHause> peter1138: the issue with cheapness of cpu and memory, is it just pales in comparison with swap access.
18:21:56 <andriydohniak> the ideal would probably be a fixed size byte array, with fluid lookup table (preferably compile time) of the layout of every piece of info
18:22:34 <andriydohniak> but making a good layout that works for all types of tiles and is efficient would be difficult
18:23:14 <andriydohniak> and there are a lot of places wher tile.m<x>() is used in the game
18:23:22 <peter1138> If 60MB extra is going to put you into swap, you have more issues than a few extra bytes...
18:24:13 <andriydohniak> I was testing my update, on a 12 yo lenove thinkpad with 4 gigs of ram, and even debug profile was running fine
18:24:47 <andriydohniak> not testing for testing purposes, I was doing some work on this PR on that machine
18:27:09 <andriydohniak> Right now I have an easy path:
18:27:09 <andriydohniak> 1. Do not change the default owner memory layout
18:27:09 <andriydohniak> 2. add an array of owners, that only kicks in when the number of companies is > 15
18:27:09 <andriydohniak> 3. Add some conditions to the ownership accessors
18:27:30 <andriydohniak> the cache misses will be minimal, because during the game the result of the condition will stay the same
18:27:51 <andriydohniak> it would only change when you join a new game
18:28:19 <andriydohniak> I do not like this idea, but if memory is crucial, this might be the best option
18:28:26 <peter1138> Very few servers have 15 companies.
18:28:51 <Eddi|zuHause> peter1138: it probably doesn't but the "memory is cheap" argument leads to more than 64MB quite quickly
18:29:27 <Eddi|zuHause> also, 640kB should be enough for anyone :p
18:29:56 <andriydohniak> peter1138: That's because currently the server players can't just choose to be on their own, because of the company limitations, so they join 1 of the established companies
18:30:29 <peter1138> That's not true, most servers have less than 10 companies, so plenty of free slots.
18:30:33 <andriydohniak> I would like to be able to play a "free for all" 2b2t like games in openTTD, where you can always join
18:31:11 <locosage> Probably the only server that can legit use >15 companies sometimes is Reddit one
18:31:49 <andriydohniak> locosage: And the Master Hellish coop servers
18:32:07 <peter1138> "coop" means you need less companies not more 🙂
18:32:17 <andriydohniak> If it wold be easy to make massive multiplayer vids in open TTD, people would do it
18:32:51 <locosage> Those are quite rare in comparison
18:33:00 <andriydohniak> peter1138: but that's the only option that exists, you can't have a solo massive multiplayer competionion
18:33:17 <andriydohniak> locosage: but they would bring more popularity to the game :)
18:33:34 <andriydohniak> I think I see a marketing strat for my change now :D
18:34:01 <andriydohniak> We need this so popular youtubers host comptitions, which brings awareness to this amazing game
18:34:35 <locosage> I'm not saying it's bad to have higher limit, it's just the cost of it is a concern
18:34:53 <andriydohniak> locosage: I can make it ~0 cost for people that don't want it
18:35:26 <andriydohniak> and even so, I think the cost is low enough
18:36:25 <andriydohniak> andriydohniak: What if I make this work? would this have a better chance at being merged?
18:37:33 <andriydohniak> it would still increase the size of the bitfield from 2 bytes to 30 bytes, but this does not depend on the map size
18:39:38 <michi_cc> Depending on how many bits are expected to be usually set in a company mask, it might make sense to switch some of them to a set/list-like structure.
18:41:32 <Eddi|zuHause> <peter1138> "coop" means you need less companies not more 🙂 <-- well, imagine coop servers with infra sharing :)
18:48:23 <andriydohniak> michi_cc: but 30 bytes is not much, and it does not increase in based on the map size, not attached to tiles, and at this size normal access with cpp's bitset is VERY efficient
18:48:54 <andriydohniak> Eddi|zuHause: I didn't express myself correctly, not coop, just massive everybody by themselves multiplayer
18:49:54 <andriydohniak> I just wan't to make Spiff's patch, but more stable and upstream (ideally)
18:50:32 <talltyler> I think there are probably some moderation/trolling issues preventing more public multiplayer games, which are of course a separate problem to solve
18:51:08 <talltyler> I only play single-player or invite-only multiplayer games, for this reason
18:51:10 <andriydohniak> talltyler: but what if trolling was allowed?
18:51:25 <talltyler> It’s not the sort of game I enjoy 🙂
18:52:11 <andriydohniak> talltyler: no, but when there is only 1 player per company, how much harm can 1 player do, before others will notice and punish them
18:53:24 <andriydohniak> Or even if it wasn't allowed, it's definitelly possible to make a OpenTTD chat bot that monitors for some special ping, and then moderators solve the issue
18:53:40 <yiffgirl> i don't think trolling would be very fun for anybody involved. we all turn disasters off after all
18:54:14 <yiffgirl> which reminds me, i have a proposal to make disasters worse
18:54:45 <yiffgirl> "worse? do you mean better?" well, that too. but mainly worse
18:55:13 <Eddi|zuHause> must be this global warming, making the disasters worse.
18:57:21 <andriydohniak> as I obsrve, there is not much interest in making the company limit bigger, so I am putting this project on the back burner, and what time I put in it, I will just create yet another fork of openTTD :(
18:58:25 <yiffgirl> andriydohniak: i doubt i would personally get much use out of more companies [i never play multiplayer] but i would like the possibility
18:58:48 <Eddi|zuHause> andriydohniak: i think you're misinterpreting what people are saying
18:58:53 <talltyler> I think OpenTTD development is often a “scratch my own itch” situation. If you want it, make it happen, and as long as it doesn’t impact other things negatively, it will get fairly considered 🙂
18:59:17 <yiffgirl> yiffgirl: i also watched the spiffing brit battle royale video and crave more
18:59:19 <talltyler> Don’t take a lack of interest as opposition 🙂
19:00:18 <talltyler> I would personally like to see the limit increased to around 30, beyond that I wouldn’t use it but that doesn’t mean I’m opposed to the idea
19:01:10 <talltyler> I have seen 16-company games fill up on occasion, it often happens in this Discord server’s JGRPP games — and there are three such games running simultaneously with different themes
19:01:19 <andriydohniak> talltyler: even increasing to 30 without memory layout changes is very difficlut, so we are still where we started, and from that point changing 30 to 240 or even 1000, is not that difficult
19:02:04 <talltyler> Right, I just mean I would like to see the limit increased 🙂
19:02:38 <talltyler> How do you propose to handle the company colour issue? It’s used for a lot of things, like maps, graphs, etc.
19:02:54 <andriydohniak> talltyler: Like spiff did, just loop them
19:03:21 <andriydohniak> It's more difficult to find the correct company name, sure, but you can disable them 1 by 1 to do that
19:03:30 <andriydohniak> or we can add a hover on the graph with the name
19:03:43 <truebrain> Fa\ctorio does the same I believe?
19:04:02 <andriydohniak> My patch already loops the colors, and I haven't noticed any issues
19:04:09 <talltyler> So like the cargo payment graph in Steeltown 😛
19:05:23 <andriydohniak> we can put the [x] Experimental support for large company servers in the settings, so who wants that can turn it on, while the UI is being worked on
19:06:06 <andriydohniak> All the UI issues have solutions, and I am willing to slowly chip away at them, making ui better for < 15 company player lobbies too
19:08:47 <andriydohniak> for example, the graph menu:
19:08:47 <andriydohniak> - Add a search to the candidate list,
19:08:47 <andriydohniak> - When hovering on the candidate, highlight their graph with a thicker line or a white backdrop, so it's easy to distinguish
19:08:47 <andriydohniak> - When clicking on a line in the graph, select a company (or just show a name in a hover)
19:11:09 <andriydohniak> Graphs are not very easy to use even in < 15 company lobby
19:12:56 <yiffgirl> as someone who has also been playing steeltown, yeah
19:18:50 <peter1138> (Is a 15 company game called a "15 player lobby" now?)
19:19:32 <andriydohniak> peter1138: No, but some games are fun to play solo
19:19:42 <andriydohniak> with a lot of player
19:26:29 <talltyler> andriydohniak: These could happen as separate PRs, would be a good addition no matter what 🙂
19:28:01 <andriydohniak> talltyler: yea, but it would be especially usefull when the number of companies is large, and I would have significantly more motivation to do so if the changes to the number of companies would be accepted
19:28:57 <andriydohniak> but I think even if it doesn't get accepted, I will try to work on improving the graph. BUT I have 0 xp with the OpenTTD Ui side, so not sure how difficult that would be, or even if it is possible
19:31:51 <Eddi|zuHause> andriydohniak: just as an outsider i'd suggest not relying on the companies patch being merged anytime soon, so "i'll wait for that" is a pretty bad idea
19:35:34 <_glx_> oh and don't forget the 15 max is also because of limited available colours
19:36:56 <_glx_> each company uses 8 shades from the palette, so 120 from the 256 palette
19:38:25 <_glx_> 2CC helps in this area, but there's no 2CC in vanilla vehicles
19:43:18 <peter1139> Eddi|zuHause, sure, but you can't force enthusiasm.
19:43:28 <peter1139> There is that RGB CC patch...
19:43:45 <Eddi|zuHause> is there, really? :p
19:44:43 <andriydohniak> _glx_: the colors can loop
19:44:57 <_glx_> andriydohniak: only map accessors and AfterLoad shoud direct access
19:45:15 <_glx_> it used to be way worse
19:45:29 <andriydohniak> we discussed that above, but basically better ui will make the colors not as important, so if they loop there will be no real issue
20:01:34 <wensimehrp> alfagamma7: 39C5BB CC
20:04:29 <locosage> Tbh I'd focus on UI side of >15 companies and wait/hope for newmap to solve the storage
20:06:59 <locosage> And isn't not as much graphs as many other UI elements becoming unusable
20:19:38 <peter1138> Hopefully CodeQL will at least remove the ouf-of-date comment...
20:26:08 *** virtualrandomnumber has joined #openttd
20:26:22 *** virtualrandomnumber has quit IRC ()
20:26:49 <talltyler> andriydohniak: Knowing if the change would be accepted would absolutely help with motivation, but cleaning up tech debt with smaller PRs usually comes before the feature. Look at the PR history for my timekeeping changes — I was working on tech debt (with TrueBrain’s help) for probably 8 months before I got to the actual feature. Even then, the feature was split into many sub-features that improve
20:26:49 <talltyler> the game for everyone, not just people using my new timekeeping mode. 🙂
20:27:46 <talltyler> Seconds mode for timetables, cargo production scaling, more that I forget…
20:28:32 <andriydohniak> Damm, nothing is simple, i guess :). I guess I am starting to work on the UI improvements first
20:29:42 <talltyler> If you clean everything up first, the big scary change becomes smaller and less scary 😄
20:31:01 <andriydohniak> talltyler: but from what I saw, there isn't really much to "clean" here, all that is needed are larger data structures, and my whole PR is just adding them and fixing compatibility
20:32:18 <talltyler> I would count UI improvements among tech debt that would make more companies palatable
20:33:00 <andriydohniak> Gona start with a big cup of tea, and start exploring how the graph UI is drawn
20:34:20 <andriydohniak> btw, I am very much learning as I go. This has been my biggest patch to any project that is not mine, and even my personal projects are usually pretty small
20:34:48 <andriydohniak> And C++ is not the language I usually use, I default to rust
20:34:50 <talltyler> That’s how we all learned, I think 😄
20:35:19 <talltyler> I am not even a software developer IRL, I learned to code making NewGRFs and then contributing to OpenTTD
20:35:54 <andriydohniak> talltyler: Congrats, but I am sure it wasn't the most fun journey :)
20:36:41 <andriydohniak> but I started coding with Scratch, and I made a simple game, and a lot of iterest in programming for me also started there
20:37:02 <andriydohniak> + Linux, C, Python, C++, Rust, Java, but all that stuff came later
20:53:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:06:14 <peter1138> Oh, right, it was not CodeQL.
21:06:21 <peter1138> D:\a\OpenTTD\OpenTTD\src\network\core\packet.cpp(133): note: see reference to function template instantiation 'uint8_t &std::vector<uint8_t,std::allocator<uint8_t>>::emplace_back<uint>(uint &&)' being compiled
21:06:44 <peter1138> Warning: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\xutility(374): warning C4267: 'initializing': conversion from 'size_t' to '_Ty', possible loss of data
21:22:55 <peter1138> So yeah... why am I needing to cast this now...
21:32:21 <peter1138> Okay, simply doing the filesystem include causes it.
21:49:21 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:55:33 <andriydohniak> I hit another big rodeblock: The draw functions are const, so I can't really transfer state from them, but to check which graph did the user click, I need to get access to the already layed out lines and squares, and I don't know if there is a solution besides duplicating all the logic of laying out the graph elsewhere
22:13:43 *** bootmii has joined #openttd
22:13:43 <bootmii> There should alao be a setting for unprofitable vehicles
22:14:20 <bootmii> But making the houses fully built in the scenario editor makes a lot of sense
22:25:24 <andriydohniak> Why do everything I touch needs to be soo complex :(. I have 2 options rn, copy the whole ~100 lines of layout code from the DrawGraph function, or make the whole tree not const. Because all this use uses virtual functions, I would need to change the baseclass
22:34:42 <andriydohniak> What C++ version is supported in OpenTTD?
22:36:40 <andriydohniak> Is the compiler support there?
22:36:53 <peter1138> I hope so, because it compiles.
22:38:10 <andriydohniak> Ok, looks like 99% of c++ 20 features are supported by clang, gcc, msvc
22:38:32 <_glx_> if you have a recent enough compiler it should be fine
22:39:15 <andriydohniak> _glx_: I was just checking mb I can do something fancy with iterators, but I think normal function, and just repeating a little bit of code is simpler to understand
22:39:40 <_jgr_> andriydohniak: You can use the mutable keyword, or the big const_cast hammer, if need be
22:39:58 <_glx_> but you may approach the problem from the wrong end
22:40:46 <andriydohniak> _glx_: I want to be able to click on the lines drawn on the graph, and for this I definitelly need to know their final position, and I also need to be able to put this data somewhere
22:41:23 <andriydohniak> Or mb I can cheat, and not do highlighting, and just spawn a hover or smth
22:43:20 <andriydohniak> Actually I don't think I can do that
22:43:34 <andriydohniak> _jgr_: I am in a const function, would a mutable keyword work?
22:45:13 <_jgr_> andriydohniak: You can set individual members of your struct/class to be mutable, so that they can be changed from within const methods
22:45:40 <andriydohniak> Ok, that solves it! Not in a perfect way, but good enough
22:48:17 <_glx_> what's your idea behing clicking on graph lines ?
22:50:35 <andriydohniak> _glx_: It should highlight it, and show a tooltip with a company name, and hopefully scroll to the owner in the company list
22:51:10 <andriydohniak> I also want to add search to the list of companies in the graph menu
22:52:55 <_glx_> lines are drawn over each other, you can have exact same lines for many companies and only the latest in the list is visible
22:53:28 <_glx_> that's why the "key" button exists
22:53:52 <andriydohniak> _glx_: that is true, and I want to add the ability to hover (click) on keys and that will highlight a line
22:54:54 <_glx_> highlight when hovering key should not be too hard
22:55:15 <andriydohniak> Haven't gotten to that part, but hopefully not :)
22:55:43 <_glx_> but clicking on graph will be painful
22:56:18 <_glx_> just looking at cargo graph, everything is over everything
22:56:31 <andriydohniak> but it's super usefull, I often just want to see which company is at the top, and this will be so much easyer then remembering colors or switching on and off companies
22:58:32 <andriydohniak> _glx_: This interface is not perfect, but if I add the ability to click on any part of the line, then that would be easier to manage. And if 2 companies are riding the exact same line during the whole game, sure, you will need to deactivate one of them to figure out that there is another one behind, but just normal graphs have the same issue
22:59:51 <andriydohniak> Imagine 3 companies graph: 1 of them is at 0 for the whole duration, 2nd one is at 1 for the whole duration, how do you know where the 3rd is on the current graph if it's perfectly obscured by the other one?
23:00:11 <andriydohniak> I am not removing the buttons to show/hide graphs, I am just adding more stuff
23:00:57 <_glx_> all graph data is available anyway, you just need some kind of mapping
23:01:23 <andriydohniak> true, And I think I will figure that out, especially with the mutable keyword
23:01:36 <andriydohniak> 1 limitation I see, is a 1 frame delay
23:02:01 <_glx_> based on the graph scale for Y axis
23:02:02 <andriydohniak> I will just use the invalidate widget feature, to forse a redraw or something
23:02:37 <andriydohniak> _glx_: I don't get that
23:03:07 <_glx_> graph scale depends on which lines are actually drawn
23:04:34 <andriydohniak> _glx_: Yea, that's why I will get the info about clicks right from the draw function
23:05:42 <andriydohniak> so I will store some more state in the graph class, and as it draws all the lines / rectangles, I will just check if the previous mouse click is in bounds of 1 of the lines / rectangles, and if so set the selected line with that mutable keyword, and redraw the frame, but that time don't check for clicks
23:05:45 <_glx_> same graph, different selection
23:06:28 <andriydohniak> Yea, I know, I will use the code that draws directly to check for click colisions
23:07:07 <_glx_> maybe you can extract some code from drawing to reuse it on click handling
23:07:58 <andriydohniak> _glx_: I could, but the logic is like 100 lines of code, so it's just sooo much easyer to use the same code, and have a bit of mutablility
23:08:38 <_glx_> extract without copying, just a shared subset called by both
23:09:46 <andriydohniak> but here is the issue, then I would have to allocate a bunch of vectors, because the result of the layout code is stuff being drawn in the correct places, now I would need to store the coords in vectors, and then draw from that
23:10:10 <andriydohniak> Just seems uselessly complex and hard to use
23:14:10 <andriydohniak> Currently when I click on the small square it gets selected, and I can use that selection in other sections too
23:14:40 <andriydohniak> this is just a test, the final selection will probalby look differently
23:16:56 <peter1138> Shouldn't be too hard to extract the code that determines the rect that's being drawn in.
23:18:49 <andriydohniak> peter1138: but all this is 1 widget, so the code that determines the location of each line depends on the code that determines the legend layout and fonts there
23:18:56 <andriydohniak> I did check that
23:19:29 <andriydohniak> I don't just want a rectangle, I want all points + lines and which company do they belong to
23:23:08 <andriydohniak> peter1138: Actually, you might be right, the code that actually determines the positions of the lines/squares is pretty small and self contained, so I might just be able to use a copy of it to create a method that checks if my click hit something, and if it did, what
23:24:15 <andriydohniak> but it does depend on the rectangle size, and it's difficult to extract that, so the exact same issue here
23:25:59 <andriydohniak> peter1138: The inner rectangle size directly depends on a whole lot of code computing it inside, and the only way not to copy paste that code is with a mutable variable that determines it's size on the previous frame
23:27:13 <andriydohniak> do you by any chance know how to redraw a widget immediately?
23:50:14 <andriydohniak> Ok, I figured out how to reload the widget
continue to next day ⏵
