Times are UTC Toggle Colours
00:27:36 *** Compu has joined #openttd 00:46:27 *** WormnestAndroid has quit IRC 00:46:42 *** WormnestAndroid has joined #openttd 01:15:57 *** WormnestAndroid has quit IRC 01:16:29 *** WormnestAndroid has joined #openttd 01:24:32 *** WormnestAndroid has quit IRC 01:25:12 *** WormnestAndroid has joined #openttd 02:00:50 <DorpsGek> [OpenTTD/OpenTTD] embeddedt commented on pull request #9191: Codechange: Disable pointer locking by default https://git.io/JcklC 02:42:42 *** WormnestAndroid has quit IRC 02:45:10 *** WormnestAndroid has joined #openttd 02:54:18 *** Gustavo6046 has quit IRC 02:55:25 *** debdog has joined #openttd 02:56:45 *** Gustavo6046 has joined #openttd 02:58:44 *** D-HUND has quit IRC 03:13:44 *** glx has quit IRC 03:34:34 *** Flygon has joined #openttd 04:09:35 *** snail_UES_ has joined #openttd 04:19:47 *** snail_UES_ has quit IRC 06:01:22 <DorpsGek> [OpenTTD/OpenTTD] telk5093 updated pull request #9376: Feature: Show the number of clients and companies in the online players window https://git.io/JnnOJ 06:02:03 <DorpsGek> [OpenTTD/OpenTTD] telk5093 commented on pull request #9376: Feature: Show the number of clients and companies in the online players window https://git.io/JckAZ 06:26:39 *** gelignite has joined #openttd 06:41:54 <TrueBrain> FLHerne: yeah .. I have the same issue :P I guess the best approach would be to first go over the wiki page and make sure there is some consensus about that .. even then ... lot of work with relative little benefit .. 06:46:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9191: Codechange: Disable pointer locking by default https://git.io/JcIvI 06:47:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9376: Feature: Show the number of clients and companies in the online players window https://git.io/JcIv3 06:55:39 *** sla_ro|master has joined #openttd 07:02:05 *** HerzogDeXtEr has joined #openttd 07:13:51 *** Gustavo6046 has quit IRC 07:16:40 *** Gustavo6046 has joined #openttd 07:32:23 <DorpsGek> [OpenTTD/OpenTTD] Taschi120 commented on pull request #9395: Change #9188: Netsave now behaves like autosave https://git.io/JcIt1 07:35:05 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9395: Change #9188: Netsave now behaves like autosave https://git.io/JcIqY 07:35:41 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9395: Change #9188: Netsave now behaves like autosave https://git.io/JcIql 07:56:30 <TrueBrain> wauw .. you can have invalid entries in a settings .ini, and settingsgen doesn't complain about that .. 07:56:34 <TrueBrain> it just skips the entry 07:57:10 <TrueBrain> owh, sorry, it does "warn" about it 07:57:19 <TrueBrain> in the blob of other stuff 07:57:28 <TrueBrain> but .. no, just no .. why not error? lol 08:11:24 <TrueBrain> dbg: [sl] Field 'HS?_??type??train??roadveh??ship??aircraft??effect??disaster' of type 0x56 not found, skipping 08:11:30 <TrueBrain> do you think I made a mistake in my code? :P 08:18:01 <LordAro> seems a bit likely 08:26:57 *** gelignite has quit IRC 08:26:58 *** andythenorth has joined #openttd 08:36:12 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JcIWX 08:48:46 <Xaroth> Somebody got any popcorn, I seem to have run out. 09:27:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JcI2K 09:27:45 <TrueBrain> Xaroth: stop putting wood on fire that doesn't exist please :) 09:28:05 <TrueBrain> he is asking questions, and I am answering them. Seems nothing but fair :) 09:32:19 <_dp_> yeah, it's finally getting constructive 09:32:53 <_dp_> TrueBrain, if I change the name of the field in the header of the new savegame externally, will the game still be able to parse it correctly? 09:33:31 <TrueBrain> you mean another tool than OpenTTD changes something in the savegame? 09:33:55 <_dp_> not just something, the name of field to somthing random 09:34:12 <TrueBrain> OpenTTD would read it; it won't understand the field of course 09:34:16 <TrueBrain> but it would read the chunk fine 09:34:18 <TrueBrain> even read the fields it can 09:34:22 <TrueBrain> and warn about any missing fields it now has 09:34:40 <_dp_> then that's exactly what I mean that new format uses the name for indentification 09:34:47 <_dp_> you can't change the name without breaking the format 09:35:06 <TrueBrain> okay, so when you talk about "format" you mean understanding the data 09:35:13 <TrueBrain> format usually refers to how to read the data 09:35:22 <_dp_> yeah, what I call identification you call understanding 09:35:25 <TrueBrain> interpretation of the data is always up to the reader ofc 09:35:41 <TrueBrain> like the classic: 10101001 means nothing till you assign it value 09:36:40 <_dp_> if you see it like that I'm not even talking about the format then but the internal change of the way it interprets the data 09:37:06 <TrueBrain> not sure what you mean there 09:37:13 <_dp_> like, changing it to sqlite after 9322 is not a format change in my eyes because it's just a byte structure, all the logic is already there 09:37:25 <TrueBrain> the savegame format is how things are stored on disk 09:37:29 <TrueBrain> what the ones and zeros mean 09:37:59 <TrueBrain> so there is a huge disconnect in thermology here ;) 09:38:25 <TrueBrain> https://github.com/OpenTTD/OpenTTD/blob/d93eb82ff33d47f81207a3477f6a614ca5f16045/docs/savegame_format.md <- this is our savegame format 09:38:42 <_dp_> well I don't know how would you call it then 09:38:51 <_dp_> logic or structure of the data organization 09:39:00 <_dp_> to me it's the part of the format, it's core, it's idea 09:39:08 <TrueBrain> it is different for each chunk 09:39:18 <TrueBrain> but okay, we now understand what we mean, that is more important 09:39:27 <_dp_> no, with 9322 they're pretty much all just rdbms tables 09:39:32 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JcIw0 09:41:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JcIw5 09:43:18 <_dp_> except now you don't have sufficient information in the savegame to figure out said order 09:43:26 <_dp_> unless you read the header 09:44:46 <TrueBrain> yeah, I realised that after I posted; already edited it :P 09:44:51 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JcIr2 09:45:16 <michi_cc> Eh, too slow :) 09:45:20 <TrueBrain> hihi, I indeed misread michi_cc :D My edit was quicker :P But good point michi_cc :) 09:45:25 <TrueBrain> :D 09:46:07 <_dp_> to me that is just a consequence of a format "idea" change 09:46:18 <_dp_> like, ofc, you can't skip header if it's identified by name 09:47:32 <TrueBrain> yeah, I did not consider the case where you can no longer deduce what order is used, so that is completely fair 09:47:55 <TrueBrain> it is btw a good reason to do this: it means we validate much more strict that the savegame we read has the data we assume :) 09:48:07 <TrueBrain> it is so easy in the old way to overrun records and just read garbage ... 09:49:30 <_dp_> but was that really a big issue before? 09:49:34 <_dp_> other than for broken files 09:50:05 <TrueBrain> "big issue" is a strong word, but for external tooling it was a pita 09:50:08 <michi_cc> On a related side note: While I don't have any string opinions whether we need or don't need these headers in savegames, I am somehwat sceptical of using external libraries for storage. 09:50:50 <TrueBrain> michi_cc: I think several others agree with you. I am yet of no opinion till someone shows how it looks .. could be a disaster :D 09:50:54 <TrueBrain> could be epic :P 09:51:13 <TrueBrain> but what makes you skeptical, for my curiousity? 09:51:51 <TrueBrain> _dp_: btw, as example, there was a setting added recently in the middle of the settings-blob .. took me a while to find why my tooling was doing very weird shit because of it :P 09:52:04 <michi_cc> Using the often cited SQLite as an example: They give a very, very strong guarantee about backwards compatibility, which is very good. They don't say anything about forward compatibility except that the format is "stable" though, which in theory means that the compiled library version might limit loading even if it is the same OTTD revision. 09:52:30 <TrueBrain> michi_cc: wauw, yes, that is a very valid point 09:53:12 <_dp_> it was a pita mainly because tooling had to replicate openttd code logic, and it's still a pita for anything that needs old format 09:53:34 <TrueBrain> I cannot fix the past 09:53:38 <michi_cc> Like e.g. (constructed example), Linux Distro A switches to 5.0 ahead of everybody else, which adds some stuff the the file format, making compiles still using version 4 not be able to read it. 09:53:38 <TrueBrain> I can only work towards a better tomorrow :) 09:53:59 <TrueBrain> michi_cc: so the only way would be to vendor it, basically 09:54:01 <_dp_> but if there was a way to declaratively describe the schema for all versions of the save it would be much more useful for tooling than 9322 that only has partial metadata for a single version 09:54:09 <_dp_> * imo ;) 09:54:11 <TrueBrain> but that is a very big issue indeed michi_cc , oof 09:54:13 <michi_cc> This is obviously constructed, and as far as I know, SQLite very, very rarely changes the on-disk format, but it is still something to keep in mind with any external library in general. 09:54:29 <TrueBrain> _dp_: how would you envision this? 09:55:07 <TrueBrain> michi_cc: it is funny, I am so used to version pinning my dependencies, that I did not even consider that scenario .. :D 09:55:25 <_dp_> TrueBrain, for example for settings I have this: https://pastebin.com/1Wtuc0hA 09:55:51 <_dp_> I generate this file automatically for every new game version and can use it to parse settings from any save version 09:56:02 <TrueBrain> that is a valid approach 09:56:18 <TrueBrain> one could even add an option to settingsgen to generate that JSON blob for you, if you so would like 09:56:18 <_dp_> also can use it in server config system that has nothing to do with savegames on a surface 09:58:40 <_dp_> yeah, and same approach can be extented to other chunks as well 09:58:49 <_dp_> I even have something similar, just not as readable 09:59:25 <_dp_> point is, that works much better for backwards compatibility imo, but offers no forward compatibility since you need a new schema to parse new games 09:59:43 <TrueBrain> and 9322 solves that part ;) 09:59:48 <TrueBrain> as the schema is embedded in the savegame now 09:59:56 <TrueBrain> so after that PR, you can stop creating that JSON blob 10:00:06 <TrueBrain> which would mean we could publish the JSON blob for all chunks once 10:00:08 <_dp_> yeah, but it loses a lot in the process 10:00:09 <TrueBrain> and never have to touch it again :D 10:00:33 <TrueBrain> huh? what does it lose by embedding the schema? :) 10:00:52 <_dp_> like server configuration can't use embedded schema because it has no save 10:01:08 <_dp_> serverstat needs settings defaults that embedded schema doesn't have 10:01:21 <TrueBrain> the first one I don't really get 10:01:24 <_dp_> also some way to handle renaming of settingss 10:01:26 <TrueBrain> the second one is a niche problem, isn't it? 10:02:05 <_dp_> well, that's a real world example 10:02:17 <TrueBrain> sure; but it is one tool that needs defaults 10:02:20 <TrueBrain> it can get that in various of ways 10:02:27 <TrueBrain> not sure how that stands in the way of embedding the schema in the savegame? 10:02:58 <TrueBrain> there will always be tooling that needs more information; but even in the code we don't store what the defaults were for older savegame versions 10:03:02 <_dp_> it doesn't stand in a way, it just gains nothing from it 10:03:18 <_dp_> only disadvantage of having to parse table chunk as well now 10:03:19 <TrueBrain> so 90% of the tools gain something from this, but 10% doesn't gain everything from it. That is fine, isn't it? 10:03:56 <_dp_> where did 90% come from? I have about 5 tools and only one that possibly gains something is difftool 10:04:37 <TrueBrain> your tools are not the whole universe of course :P But BaNaNaS tooling benefits (greatly even) from this, the dude on reddit that is creating maps based on savegames does, etc etc 10:04:38 <_dp_> and approach with schema offers the same advantages anyway 10:04:45 <TrueBrain> instead of having to find an alternative way to get the schema, it is now right there 10:04:50 <TrueBrain> that is always a benefit, in my view 10:06:53 <_dp_> dunno about bananas but somewhat doubt dude on reddit. He already parses a lot of what he can but a lot of what he needs isn't even in the savegame (like town names). 10:07:35 <_dp_> Probably he doesn't need to deal with old formats and just require users to convert with openttd, so that's a huge benefit for him, yes 10:08:14 <TrueBrain> also what BaNaNaS will do: load old games, save them again, read it 10:08:22 <TrueBrain> means I can remove all the "old savegame" stuff 10:08:31 <TrueBrain> which is pretty sweet :) 10:09:43 <_dp_> anyway, it all comes to forward compatibility 10:10:02 <_dp_> that's indeed a big advantage of 9322 imo, it should be its selling point 10:10:51 <_dp_> but then again, why string field ids, not integer? 10:11:11 <_dp_> integer you can just fix forever to id the field when with strings you have the whole renaming issue 10:11:11 <TrueBrain> that would require yet-another-lookup-table, and I personally do not really fancy that. 10:11:28 <_dp_> renaming "alias" table is just the same 10:11:44 <TrueBrain> most of the times, a rename also means the intention changes 10:11:59 <TrueBrain> which I already noticed with some names, as Rb asked me to rename a few 10:12:09 <TrueBrain> so I am not sure it is a bad thing 10:12:16 <_dp_> except how tooling will get renaming table is unclear and non-changeable ids are easy to guarantee 10:12:48 <TrueBrain> yeah, but this is exactly the reason not to do that. If the name changes, it is likely the assigned value to the field changed too. So tooling should be aware of this rename, and adjust according, I think 10:13:29 <_dp_> well, that basically means renaming is impossible and should be done by removing and readding the field 10:13:46 <TrueBrain> that is what a rename in general is ;) But yeah, I would be fine with that as solution to renaming 10:14:03 <_dp_> and old name is forever reserved and can't be used 10:14:10 <TrueBrain> absolutely 10:15:09 <TrueBrain> for OpenTTD it would be slightly different, as it needs to read the old field, assign it its new meaning, and store it as the new field, but that is just "how to do this in OpenTTD" 10:15:21 <TrueBrain> staying backwards compatible is always tricky .. but nothing tooling should worry about 10:18:18 *** Samu has joined #openttd 10:18:20 <_dp_> that's pretty much what I was talking about basic changes 10:18:55 <_dp_> so in openttd if field is removed it now has to be put in some dumpster and never be used again 10:19:18 <_dp_> and tooling is guaranteed that openttd does exactly that and field won't resurrect with different meaning in the future 10:19:43 <_dp_> that's a nice forward compatibility guarantee to have and would be cool if that was actually documented somewhere 10:20:17 <Samu> ship acceleration formula is just v->cur_speed + 1 every tick? 10:20:27 <_dp_> basically, there is indeed no specific advantage to integer id's if you work with string id's as if they're integer ;) 10:20:29 <TrueBrain> we have very little documented on how to deal with the content of chunks, as reality is nobody would read it ... so I wonder what an effective way is there 10:20:54 <TrueBrain> _dp_: to word it differently, you want an unique-set .. either integers or strings, but they have to be unique for ever and ever 10:21:32 <TrueBrain> removing of fields on its own rarely happens .. mostly we change the meaning of a field, causing it to be removed and a new one to be added 10:21:36 <TrueBrain> this means afterload kicks in 10:21:40 <_dp_> yeah, I guess, have id be forever bound to the field interpretation 10:21:40 <TrueBrain> and both fields are still in the code of OpenTTD 10:21:51 <TrueBrain> so in the general sense, this will work out itself just fine 10:22:00 <TrueBrain> there are of course exceptions, where a field becomes completely redundant 10:22:05 <TrueBrain> I have seen 1 or 2 during this work 10:22:20 <TrueBrain> (basically, a removed feature in one case, and something that got moved from A to D in another) 10:22:35 <TrueBrain> removing features is really unlikely, so I am not that worried about that case 10:26:40 <_dp_> also, there is a similar guarantee that can be helpful for patches (or at least cmclient for sure) - have some field naming range that is guaranteed not to be used by the game. 10:26:50 <_dp_> like, fields that start with __ or smth 10:27:17 <_dp_> it's probably going to be true anyway but if it's documented it will provide a uniform way of doing it that is guaranteed not to break with master changes 10:28:09 <_dp_> same thing with chunks, having a way to add custom chunk that's just ignored will be nice 10:28:36 <TrueBrain> that is rather difficult, as I do not look at OpenTTD as a <upstream> vs <forks> 10:28:48 <TrueBrain> as an example, say you make cmclient based on JGRPP 10:28:53 <TrueBrain> he uses __, and you use __ 10:28:57 <TrueBrain> that still clashes 10:29:28 <TrueBrain> some kind of fork-depending prefix would solve that 10:29:44 <TrueBrain> for example, it is really unlikely we would even name a field "cm_NNN" or "jgrpp_NNN" 10:29:44 <_dp_> master is way more dynamic than any of the patches so that's the main issue 10:30:04 <_dp_> and, yeah, in that range patchpacks can add their own subranges 10:30:09 <TrueBrain> so I think it is save to use names like that 10:30:17 <TrueBrain> but guarantees .. I do not think that works 10:30:25 <TrueBrain> still no clue why we guarantee "backwards compatibility" :P 10:31:00 <_dp_> why? it's not hard to dedicate __ range for patchpacks, who's going to use that anyway? 10:31:03 <TrueBrain> but that is nitpicking from my part; I think in general we can safely assume a name like "cm_NNN" is safe, or if you like, "__cm_NNN" I am 100% sure about we would never use :P 10:31:13 *** MTDL has joined #openttd 10:31:23 <_dp_> and doesn't even have to be in the code, just savegaem docs would suffice 10:31:24 <TrueBrain> that doesn't even need documentation tbh :D 10:31:37 <TrueBrain> but sure, we can write down some guidelines on that part 10:32:36 <MTDL> Hi, I'm trying to work on a custom client but am running into difficulties with compiling the project once I start including headers from other files like company_base.h 10:32:46 <_dp_> well, "cm_NNN" is generally "mmm_NNN" which I'm pretty sure can conflict with something 10:32:57 <MTDL> Specifically, clang apparently can't resolve the numeric types like uint32 and byte: https://paste.rs/fHy 10:33:32 <TrueBrain> MTDL: without seeing the diff, a bit hard to help out .. but in general: make sure stdafx.h is included before any other include 10:33:36 <TrueBrain> should be the top include in any file 10:34:25 <MTDL> My file is literally only #include "company_base.h" 10:35:14 <MTDL> Including #include<stdafx.h> does solve it 10:35:58 <TrueBrain> see any other .cpp file, it always start with stdafx.h and ends with safeguard 10:36:02 <TrueBrain> those 2 are really important :) 10:36:10 <TrueBrain> all other includes should be between those 2 lines 10:36:23 <MTDL> ah that's true, I was too focused on the header files 10:37:01 <MTDL> Whenever I open one of the other header files in clangd I get the same errors 10:37:02 <TrueBrain> OpenTTD pre-dates unified "uint32" etc, so we did it all ourselves :D 10:38:10 <MTDL> It isn't linked on the docs so I figured it was something external 10:38:15 <MTDL> *in 10:39:18 <MTDL> thanks for pointing that out 10:44:42 <MTDL> Now I can really get started 10:46:15 <Samu> are there ships that have a max speed of 128 km/h? 10:46:21 <Samu> i think i just found a bug 10:47:41 <TrueBrain> MTDL: enjoy :D 10:47:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JGlmd 10:47:51 <TrueBrain> _dp_: added words for __ stuff 10:49:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Feature: store table headers for each chunk in savegame https://git.io/JGlmd 10:49:18 <Samu> question: if ((byte)++spd == 0) 10:49:23 <Samu> if spd is 256 10:49:33 <Samu> what will the comparison be? 10:49:42 <Samu> 257 == 0? or 0 == 0? 10:50:39 <milek7> byte value is 0-255 10:50:58 <milek7> and unsigned overflow is defined to wrap around 10:51:16 <Samu> spd is a uint, bye 10:51:17 <_dp_> TrueBrain, yeah, perfect :) 10:51:19 <Samu> by the way 10:52:49 *** felix has quit IRC 10:52:54 <_dp_> TrueBrain, what do you think of adding skippable chunks as well? 10:53:02 *** felix has joined #openttd 10:53:10 <_dp_> though naming is a bit constricted for those I guess 10:53:19 <_dp_> but the reasoning is pretty much the same 10:54:46 <Samu> hmm seems the comparison is 1 == 0 10:54:59 <Samu> i thought it would be 0 == 0 10:55:57 <LordAro> Samu: prefix ++ means increment happens first 10:56:02 <LordAro> so you're comparing 257 == 0 10:56:10 <Samu> i think it's 1 == 0 10:56:14 <_dp_> though it looks like in cmclient case I can shove all the custom data to existing chunks 10:56:16 <LordAro> then the cast happens, so 256 -> 0, 257 -> 1 10:56:22 <LordAro> 1 == 0 10:56:22 <LordAro> tada 10:57:10 <Samu> regardless, if a ship has a speed of 128 km/h, the acceleration looks bugged 10:57:30 <Samu> but i need a real ship to test 11:00:11 <Samu> squid ate fish doesn't have a 128 km/h ship 11:01:13 <MTDL> Can I set up a secondary config folder for a second openttd version? 11:04:48 <Samu> wow, nobody make a ship moving at 128 km/h 11:04:59 <Samu> the newgrfs i found, have none 11:05:04 <LordAro> MTDL: 11:05:11 <LordAro> yes, use -c commandline flag 11:07:44 <MTDL> oh right thanks 11:08:14 <TrueBrain> _dp_: I have nothing against that, but the current code does :P It dates back from a time where things were different, and patchpacks were few and far apart. It protects against developers doing stupid things and giving them an early indication of that 11:08:18 <TrueBrain> I think it is out-dated 11:08:22 <TrueBrain> but .. that would be a new PR for sure :) 11:08:29 <TrueBrain> I tried my best to not touch chunks itself :P 11:09:01 <MTDL> Just noticed that if you shift click on a settings option it shows "Estimated cost: 0" 11:12:22 <TrueBrain> happens in more places, it is really funny :P 11:15:46 <MTDL> btw is there a setting to automatically unpause when a save game is loaded? 11:16:53 <Samu> enough looking for me 11:17:06 <Samu> there are no 128 km/h newgrf ships 11:20:57 <Rubidium> probably because 128 km/h is not reachable 11:34:02 <TrueBrain> MTDL: not that I know of; I use a game_start.scr script to unpause loaded games 11:34:27 <FLHerne> Samu: 127km/h-ish is the highest speed that a ship action0 can set 11:34:42 <FLHerne> 0B is a byte `Speed in mph*3.2` 11:34:58 <FLHerne> so the highest possible speed is 255/2 11:35:15 <FLHerne> This annoys people who want to make ekranoplans 11:35:48 <FLHerne> Road vehicles were the same until someone added an extra property that can set higher speeds 11:36:59 <TrueBrain> and didn't do ships while at it? Tssk :P 11:37:19 <MTDL> I guess I could just unpause manually in the code 11:37:45 <MTDL> btw where would be a good place to hook into for one time setup code whenever a game is loaded? 11:38:19 <TrueBrain> look for game_start.scr I believe 11:38:30 <TrueBrain> that is called when a game is just started 11:39:45 <MTDL> ah I see two places in openttd.cpp where it is executed 11:44:33 <MTDL> Once when a game is loaded and once when a new game is started 11:44:45 <MTDL> I guess I'll hook in afterwards to set up everything I need 11:47:15 <peter1138> Do I need to use SSIS or Microsoft Flows or what? 11:49:20 <peter1138> 11:37 < TrueBrain> OpenTTD pre-dates unified "uint32" etc, so we did it all ourselves :D 11:49:33 <peter1138> We could do a PR to fix all that ;) 11:49:42 <TrueBrain> I would say, go for it :P 11:50:08 <TrueBrain> that would mess with a lot of people's head :D 11:51:51 <peter1138> I like the inconsistency of using byte/uint8, and word/dword/short/etc/etc... 12:02:08 *** Wuzzy has joined #openttd 12:14:09 <Samu> thanks FLHerne 12:21:59 <TrueBrain> wow .. did not know we had 70 (!) settings to tune the pathfinder 12:22:05 <TrueBrain> that sounds a bit overkill :D 12:22:26 <Samu> im trying to calculate how many tiles are travelled by a ship going in axis direction at a given speed 12:23:08 <Samu> and I don't seem to get a match 12:26:28 <Samu> a ship travels 1999 tiles at 94 km/h. The timetabled says 586 days 12:26:52 <Samu> @calc 586 * 74 * 2 * 94 / 256 / 16 12:26:52 <DorpsGek> Samu: 1990.33984375 12:26:57 <Samu> 1990 tiles 12:27:02 <Samu> it's not 1999 :( 12:27:13 <Samu> why don't I get a match 12:29:35 <Samu> @calc 390 * 74 * 2 * 94 * 3 / 4 / 256 / 8 12:29:35 <DorpsGek> Samu: 1986.943359375 12:35:43 <Rubidium> missing km/h -> km-ish/h conversion? 12:39:34 <Rubidium> or what if the speed is actually 94.5 but visualised rounded down? And all other kinds of fun rounding excercises 12:41:06 <peter1138> acceleration time? 12:41:15 <TrueBrain> hammer time! 12:41:24 <Rubidium> something like not having travelled 1999 full tiles but 1998.5 tiles or not having travelled exactly 586 days but 585.8 days or 586.2 days? 12:43:55 *** glx has joined #openttd 12:43:55 *** ChanServ sets mode: +v glx 12:47:47 *** WormnestAndroid has quit IRC 12:48:00 *** WormnestAndroid has joined #openttd 12:51:33 <Samu> local days_in_transit = (distance * 256 * 16) / (2 * 74 * max_speed); 12:51:38 <Samu> how do i simplify this 12:52:23 <glx> you can move the 2 on the other side of / 12:54:15 <glx> or just do (distance * 27) / max_speed 12:57:07 <glx> <TrueBrain> wow .. did not know we had 70 (!) settings to tune the pathfinder <-- and often, everything is broken if you change one of them 12:57:25 <TrueBrain> insane :P 12:58:56 <Samu> local days_in_transit = (distance * 1024) / (37 * max_speed); 13:01:09 <glx> ah yes I was using the programmer mode of windows calc, it rounds to integers 13:16:06 <MTDL> I wonder if it's decidable whether a train can get stuck given a rail network graph 13:16:26 <MTDL> or whether there can be a gridlock 13:21:46 <Timberwolf> I ran into similar fun with AI development and setting penalty weights for all the different ways it can lay track. 13:22:26 <FLHerne> I don't think you can determine it in general; it depends on the number of trains and their orders 13:22:33 <Timberwolf> There's a fine balance between, "sensible, good-looking routes", "utter chaos" and "AI takes 9 years of game time to find a route it's happy with" 13:23:08 <glx> TrueBrain: what I was talking about intellisense http://0x0.st/-pxb.png vs http://0x0.st/-pxc.png 13:24:12 <Timberwolf> I wanted to get an AI which used more "human-like" rules, e.g. went out of its way to reuse existing track, tried to lay double track side by side, etc. 13:24:38 <glx> quite complex to do in AI 13:24:44 <FLHerne> i.e. a simple "two branches with a signal each into one platform" can't deadlock if each branch has a train, but will if there are two on one branch 13:24:55 <Timberwolf> At least, in reasonable time. 13:25:03 <TrueBrain> glx: ah, yes, never noticed that .. but indeed 13:25:11 <TrueBrain> VSCode fails to understand the function it is in too 13:25:30 <Timberwolf> It's *possible* to make an A* algorithm do it, but it will probably explore almost the entire map before it goes, "yep, that's a minimum" 13:25:42 <glx> and it was worse with FOR_ALL macros 13:25:52 *** WormnestAndroid has quit IRC 13:26:04 <TrueBrain> good thing those are almost gone :P 13:26:10 <glx> as it fails to see the function, but lists FOR_ALL in the list 13:26:25 *** WormnestAndroid has joined #openttd 13:26:58 <Timberwolf> Also I find most AI pathfinders only attempt to lay track, whereas the pathfinder should really be exploring "lay track and terraform" (which gets combinatorially worse) 13:28:13 *** Gustavo6046 has quit IRC 13:28:27 *** Gustavo6046 has joined #openttd 13:28:30 <Timberwolf> The trick I was really looking for was messing with heuristic functions so rather than trying to follow all my rules *and* find an optimal route, it was able to go, "follow the rules unless you really cannot, and take a vaguely good-enough route, but accept a few compromises so you can do it quickly" 13:54:10 <TrueBrain> hmm ... how to do string-hex -> int in C++ ... eeeuuuhhhhh 13:58:07 <TrueBrain> ha, in this same file I am working in we have code for that, sweet :D 13:58:43 *** nielsm has joined #openttd 14:00:15 <milek7> std::stoul? 14:01:49 <glx> std::from_chars 14:02:02 <TrueBrain> DecodeHexText() 14:32:31 <DorpsGek> [OpenTTD/OpenTTD] embeddedt updated pull request #9191: Codechange: Disable pointer locking by default https://git.io/J3aVd 14:34:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9191: Codechange: Disable pointer locking by default https://git.io/JcLus 14:34:25 <DorpsGek> [OpenTTD/OpenTTD] embeddedt commented on pull request #9191: Codechange: Disable pointer locking by default https://git.io/JcLuc 14:37:11 <DorpsGek> [OpenTTD/OpenTTD] embeddedt updated pull request #9191: Codechange: Disable pointer locking by default https://git.io/J3aVd 14:38:00 <DorpsGek> [OpenTTD/OpenTTD] embeddedt updated pull request #9191: Codechange: Disable pointer locking by default https://git.io/J3aVd 14:41:55 <TrueBrain> Codechange .. hihi, that is a bit of a lie :P 14:42:00 <TrueBrain> well, everything is a codechange in the end, ofc 14:50:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9191: Codechange: Disable pointer locking by default for Emscripten https://git.io/JcL2i 14:51:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9298: Change: move secrets out of "openttd.cfg" into "secrets.cfg" https://git.io/JGLne 14:52:51 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9298: Change: move secrets out of "openttd.cfg" into "secrets.cfg" https://git.io/JcLaR 14:53:16 <TrueBrain> well, it became from_chars in the end anyway :D 14:53:42 *** sla_ro|master has quit IRC 14:55:21 <TrueBrain> someone is trying to sell chairs on info@ 14:55:24 <TrueBrain> if anyone is interested .. 14:55:26 <TrueBrain> :P 14:57:52 *** snail_UES_ has joined #openttd 15:23:04 <Samu> ships keep on stacking on top of each other, no matter what i do 15:23:19 <Samu> this hurts station cargo ratings 15:24:01 <Samu> i can't know if I need to be adding ships when cargo waiting goes over 100 15:24:41 <Samu> oh well 15:25:06 <Samu> i can reduce route distances so that it never hurts rating performance 15:25:25 <Samu> 40 days in transit is the ideal number 15:31:50 *** snail_UES_ is now known as Guest801 15:31:50 *** snail_UES_ has joined #openttd 15:36:52 *** Gustavo6046 has quit IRC 15:37:35 *** Guest801 has quit IRC 16:00:42 *** Progman has joined #openttd 16:04:30 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9398: Fix: [Squirrel] Enforce comma usage in function calls https://git.io/JcL9R 16:12:49 <peter1138> Rebase from 5 months ago is... painful. 16:15:59 <blathijs> I think I still have a new map array branch somewhere from 10+ years ago, maybe I should try rebasing that one when I have some spare time? ;-) 16:17:48 *** Gustavo6046 has joined #openttd 16:18:05 <TrueBrain> Sounds a useful waste of your spare time indeed :D :D 16:18:18 <TrueBrain> Also: hi :) 16:19:57 <blathijs> I wonder how much of the OpenTTD code I would still recognize, after so long :-) 16:22:59 *** Gustavo6046 has quit IRC 16:30:18 <TrueBrain> Is A* code still there ..... :p 16:30:56 <glx> maybe, if it was NPF 16:31:15 <LordAro> NPF has a nice function called AStar iirc 16:32:53 <TrueBrain> AyStar, if I remember correctly :D 16:33:03 <LordAro> close enough 16:33:03 <glx> aystar.cpp is still here 16:33:10 <TrueBrain> Haha 16:33:51 *** Gustavo6046 has joined #openttd 16:37:07 *** Gustavo6046_ has joined #openttd 16:39:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9191: Codechange: Disable pointer locking by default for Emscripten https://git.io/J3aVd 16:41:56 *** Gustavo6046 has quit IRC 16:41:56 *** Gustavo6046_ is now known as Gustavo6046 16:42:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9376: Feature: Show the number of clients and companies in the online players window https://git.io/JnnOJ 16:46:28 *** Gustavo6046 has quit IRC 16:50:36 *** debdog has quit IRC 16:51:08 *** Gustavo6046 has joined #openttd 16:53:07 *** WormnestAndroid has quit IRC 16:56:44 *** WormnestAndroid has joined #openttd 16:58:15 *** gelignite has joined #openttd 16:59:34 *** Taschi has joined #openttd 16:59:35 <DorpsGek> [OpenTTD/OpenTTD] Taschi120 updated pull request #9395: Change #9188: Netsave now behaves like autosave https://git.io/JnQY9 17:01:12 <Taschi> i was so excited to see four new messages just moments after coming online but turns out it was just NickServ 17:01:28 <TrueBrain> poor NickServ .. his messages are not appreciated :( 17:02:05 <Taschi> poor Nicholas Serv is just too predictable 17:02:53 <Taschi> question - i've had a couple of commits in PR 3935, most of them just fixing code style issues - do you prefer to have them as individual commits or should i go and squash them? 17:03:27 <Taschi> also i'm sorry for being a big stupidhead 17:03:51 <TrueBrain> it is up to you; we can either squash it on merge, which is fine in most cases 17:03:58 <TrueBrain> or you can do it yourself .. we do not really care, honestly 17:04:07 <TrueBrain> and why would you think you are a big stupidhead? 17:04:47 *** WormnestAndroid has quit IRC 17:05:08 <Taschi> i'm just really struggling to read over codestyle documentation and follow it 17:05:18 <TrueBrain> well, just looking at my recent PRs, 90% of the time a push is followed by yet-another-push directly after ... as I fucked something up and I needed to fix it :P That is just how we roll ;) 17:05:44 <TrueBrain> it is really pretty normal to need a few times to get things just right 17:06:03 <Taschi> tbh it's probably how most software projects run 17:06:29 <Taschi> but i know how frustrating it is to have to deal with a new team member who has not figured out yet how to properly format their code 17:06:56 <TrueBrain> well, we also still have to deal with people around for 17 years who have to figure out how to properly format their code :D 17:07:00 <TrueBrain> I wouldn't worry too much about it :) 17:07:08 <Taschi> tee hee 17:07:39 <Taschi> at work we have SonarQube but it's so poorly configured for our project that it's basically useless 17:08:06 <TrueBrain> I love that in the Python world you just have "black" 17:08:10 <TrueBrain> and that is the end of it :D 17:10:12 <Taschi> there is a similar thing for Java but tbh I don't like it 17:10:56 <Taschi> for example when i chain lots of function calls (e.g. in a builder pattern or working on collections with lambdas) i like to indent them in a way that "makes sense", same for line breaks 17:11:21 <Taschi> and the code formatter then says "yoink, that line is too short, let me pull up another half-statement from the next line" 17:11:39 <TrueBrain> I think in general for bigger projects, any automated coding style is always better than having humans waste their time doing it :P 17:11:46 <TrueBrain> but "black" is one of the few I knew that is right in 99% of the time 17:11:51 <TrueBrain> so the 1% you just have to suck it up 17:11:56 <Taschi> eh 17:12:01 <TrueBrain> that said ... I do change the linelength to more than 79 17:12:03 <TrueBrain> as 79 is stupid 17:12:51 <Taschi> these tools really can go only so far... e. g. they can enforce that Javadoc comments exist or variable names follow camelCase, but they can't enforce that comments are legible or variable names make sense 17:13:09 <Taschi> which leads to gems like "@param insurance Insurance" 17:13:27 <TrueBrain> yeah .. the human is always still needed to slap lazy developers around 17:13:30 <Taschi> which we have probably 500 instances of in our codebase and YES I COULD HAVE GUESSED THAT 17:13:35 <TrueBrain> like me .. always forgetting doxygen :D 17:14:00 <Taschi> here it's mostly people who are under the illusion that their code is so compact and expressive that they do not need documentation 17:14:19 <TrueBrain> and sometimes that is true 17:14:27 <Taschi> which works GREAT in an environment where the average dev spends like two years 17:14:30 <TrueBrain> but .. you just have to suck it up for those moments :D 17:20:32 *** Flygon has quit IRC 17:24:30 *** Wolf01 has joined #openttd 17:34:04 <DorpsGek> [OpenTTD/OpenTTD] Taschi120 commented on pull request #9397: Feature: Persistant rotation of numbered autosave after restart https://git.io/JctTw 17:36:23 <glx> don't worry, I still make code style errors :) 17:36:26 <TrueBrain> glx: btw, your FiosNumberedSaveName is not thread-safe. Not sure if that is worth mentioning in the docs somewhere? 17:37:08 <glx> I guess the previous static int was not either 17:37:34 <TrueBrain> far less code, so far less chance of hitting it, but indeed 17:38:21 <TrueBrain> and I mostly mean "prefix" btw .. didn't spot the first time it is static :D 17:39:19 <TrueBrain> btw, not saying it is a problem. Was just wondering if it is worth mentioning :) 17:40:37 *** Smedles has quit IRC 17:40:41 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9397: Feature: Persistant rotation of numbered autosave after restart https://git.io/JctkK 17:40:45 <TrueBrain> here a suggestion for it :) 17:42:41 <glx> ah yes so it's more clear 17:43:52 <glx> anyway it's only used when constructing the object, so threading should not be a big issue for the particular use case 17:44:09 <TrueBrain> yeah .. it is NOW only used when .. :P :P :P 17:44:10 <TrueBrain> :D 17:44:22 *** andythenorth has joined #openttd 17:55:48 <MTDL> Which datastructure do I get the current tiles from? 17:55:51 *** Gustavo6046 has quit IRC 17:56:23 <andythenorth> yo 17:56:24 <MTDL> My goal is to iterate over every tile in the map for a frame and extract the features I need 17:57:55 <TrueBrain> _m1 .. _me 17:58:02 <TrueBrain> or one of the many wrappers that exist for it 17:58:06 <andythenorth> are we really going to wait for frosch and make him review this? :P https://github.com/OpenTTD/nml/pull/223 17:58:11 <andythenorth> frosch won't be proud of us 17:58:30 <TrueBrain> andythenorth: I think the amount of people that review NML is heavily limited anyway .. ;) 17:59:46 <TrueBrain> MTDL: https://github.com/OpenTTD/OpenTTD/blob/master/docs/landscape_grid.html shows the exact details 17:59:51 <andythenorth> I think I resigned my reviewer rights 18:00:30 <TrueBrain> or https://github.com/OpenTTD/OpenTTD/blob/master/docs/landscape.html 18:00:31 <andythenorth> it's funny, if I self-approved 7 people would show up to tell my why I am wrong, then revert it 18:00:36 <andythenorth> but eh 18:00:39 *** Smedles has joined #openttd 18:00:43 <TrueBrain> I can never remember what is what .. as GitHub doesn't render it .. ugh .. 18:02:34 *** Gustavo6046 has joined #openttd 18:02:47 <MTDL> TrueBrain, does that page exist in https://docs.openttd.org ? 18:03:05 <TrueBrain> no clue 18:03:21 <MTDL> It is an enigma 18:03:47 <MTDL> so far the hardest part for me is to find the global variables that are scattered throughout the code 18:03:53 <MTDL> Like _local_company, _m1 etc. 18:28:37 *** Gustavo6046 has quit IRC 18:35:16 *** Gustavo6046 has joined #openttd 18:50:23 *** sla_ro|master has joined #openttd 18:51:52 *** Taschi has quit IRC 18:53:54 *** Gustavo6046_ has joined #openttd 18:56:38 *** Gustavo6046 has quit IRC 18:56:40 *** Gustavo6046_ is now known as Gustavo6046 18:57:04 *** MTDL has quit IRC 19:00:32 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JctcE 19:00:33 <DorpsGek> - Update: Translations from eints (by translators) 19:03:48 <glx> <TrueBrain> _m1 .. _me <-- it's _m and _me, and should never be accessed directly :) 19:04:04 <TrueBrain> ugh, save chunks spoiled me :P 19:05:02 <glx> of course save/load is an exception 19:08:15 <peter1138> Does OpenTTD still compile on SunOS/Solaris? 19:08:39 <glx> if it has cmake and c++17 19:08:59 <TrueBrain> what prompted this question? 19:09:07 <peter1138> What about Haiku? 19:11:03 <glx> I think it was tested quite recently 19:12:58 <glx> yup last compile fixes for haiku merged a month ago 19:14:30 <peter1138> TrueBrain, *nothing* innocent whistle... 19:14:35 <peter1138> https://github.com/OpenTTD/OpenTTD/commit/7becc392818b73d278c8974332b8c4eaf55987c8 19:14:38 <peter1138> :p 19:14:40 <TrueBrain> I am slightly scared now :P 19:15:15 <TrueBrain> owh boy ... you really did that .... lol 19:15:46 <peter1138> Main issue: half the code is now my fault ;( 19:15:47 <TrueBrain> well, it would add a bit of sanity, as in, if you are used to other projects ... :P 19:15:51 <TrueBrain> hahaha 19:16:02 <TrueBrain> KHRONOS_SUPPORT_INT64 became KHRONOS_SUPPORT_int64t 19:16:07 <TrueBrain> KHRONOS_SUPPORT_int64_t 19:16:11 <TrueBrain> maybe replace case sensitive? :D 19:16:16 <peter1138> Hmm, I reverted that file. I guess not properly. 19:16:33 <TrueBrain> Showing 566 changed files with 5,639 additions and 5,718 deletions. <- lol 19:17:25 <peter1138> Anyway, more reasonable would be including cstdint to typedef uint16_t uint16; etc... I think 19:17:44 <TrueBrain> less code change for sure 19:18:37 <peter1138> As we're on C++17, cstdint should be available, so the weirdness for Haiku/Solaris should be... er... gone? I dunno... 19:25:03 *** y2kboy23_ has quit IRC 19:28:40 *** y2kboy23 has joined #openttd 19:30:45 <TrueBrain> I cannot believe you actually did this :P 19:34:20 <peter1138> Tbh, it was five minutes with VS Code's search & replace ;) 19:34:25 <peter1138> If that. 19:41:58 *** WormnestAndroid has joined #openttd 19:42:43 *** iSoSyS has joined #openttd 19:46:19 *** Gustavo6046_ has joined #openttd 19:47:04 *** Gustavo6046 has quit IRC 19:47:05 *** Gustavo6046_ is now known as Gustavo6046 19:53:25 *** gelignite has quit IRC 19:56:41 *** andythenorth_ has joined #openttd 19:57:34 *** andythen_ has joined #openttd 19:59:23 *** andythen_ has quit IRC 20:02:44 *** andythenorth has quit IRC 20:04:45 *** andythenorth_ has quit IRC 20:08:59 <nielsm> https://devblogs.microsoft.com/oldnewthing/20210628-00/?p=105374 good to know 20:14:25 <TrueBrain> nielsm: tnx for sharing .. C++ is full of these pits :P 20:21:32 *** andythenorth has joined #openttd 20:44:19 *** Gustavo6046 has quit IRC 20:51:33 *** nielsm has quit IRC 20:52:18 *** Gustavo6046 has joined #openttd 20:54:20 *** Gustavo6046 has joined #openttd 20:54:52 *** Samu has quit IRC 21:13:09 *** Gustavo6046 has quit IRC 21:15:52 *** Wolf01 has quit IRC 21:16:52 *** WormnestAndroid has quit IRC 21:21:20 *** Gustavo6046 has joined #openttd 21:29:06 *** Gustavo6046 has quit IRC 21:29:32 *** k32n13 has joined #openttd 21:31:31 *** andythenorth has quit IRC 21:31:48 *** Gustavo6046 has joined #openttd 21:34:17 *** debdog has joined #openttd 22:03:22 *** Gustavo6046_ has joined #openttd 22:04:36 *** jottyfan has joined #openttd 22:07:52 *** Gustavo6046 has quit IRC 22:07:52 *** Gustavo6046_ is now known as Gustavo6046 22:08:45 *** snail_UES_ has quit IRC 22:12:33 *** Progman has quit IRC 22:14:07 *** jottyfan has quit IRC 22:19:42 *** HerzogDeXtEr has quit IRC 22:25:53 *** Gustavo6046 has quit IRC 22:26:20 *** Gustavo6046 has joined #openttd 22:36:18 *** Gustavo6046 has quit IRC 22:36:54 *** Gustavo6046 has joined #openttd 22:56:58 *** sla_ro|master has quit IRC 22:59:04 *** tokai has joined #openttd 22:59:04 *** ChanServ sets mode: +v tokai 23:05:54 *** tokai|noir has quit IRC 23:19:24 *** Tirili has joined #openttd 23:20:04 <Tirili> Hey 23:20:17 <Tirili> For a town center, how can I select which enemy to attack? 23:24:57 *** k32n13 has left #openttd 23:26:37 <TrueBrain> If you are seeing enemies in OpenTTD, you started the wrong game I am afraid 23:27:53 <Tirili> Ha 23:27:55 <dwfreed> need a "drive-bys" mod 23:27:55 <Tirili> Oh well 23:28:14 <Tirili> No wonder there are now answers. :D 23:28:25 <Tirili> Will try again in #0ad. 23:28:32 *** tokai|noir has joined #openttd 23:28:32 *** ChanServ sets mode: +v tokai|noir 23:28:51 <glx> lol 23:29:43 <TrueBrain> And he was trying to make those trains attack those busses ... :D 23:31:52 *** Gustavo6046 has quit IRC 23:33:13 *** Gustavo6046 has joined #openttd 23:35:30 *** tokai has quit IRC 23:45:00 <Timberwolf> Not my fault if an AI decides to hurl trucks in front of my railway. 23:46:39 *** Gustavo6046 has quit IRC 23:46:40 *** Gustavo6046_ has joined #openttd 23:47:10 *** Gustavo6046_ is now known as Gustavo6046