Log for #openttd on 28th June 2021:
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
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
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
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
06:47:15  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9376: Feature: Show the number of clients and companies in the online players window
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
07:35:05  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9395: Change #9188: Netsave now behaves like autosave
07:35:41  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9395: Change #9188: Netsave now behaves like autosave
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
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
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> <- 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
09:41:22  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9322: Feature: store table headers for each chunk in savegame
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
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:
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:
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
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
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 vs
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
14:34:06  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9191: Codechange: Disable pointer locking by default
14:34:25  <DorpsGek> [OpenTTD/OpenTTD] embeddedt commented on pull request #9191: Codechange: Disable pointer locking by default
14:37:11  <DorpsGek> [OpenTTD/OpenTTD] embeddedt updated pull request #9191: Codechange: Disable pointer locking by default
14:38:00  <DorpsGek> [OpenTTD/OpenTTD] embeddedt updated pull request #9191: Codechange: Disable pointer locking by default
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
14:51:04  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9298: Change: move secrets out of "openttd.cfg" into "secrets.cfg"
14:52:51  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9298: Change: move secrets out of "openttd.cfg" into "secrets.cfg"
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
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
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
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
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
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
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
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: shows the exact details
17:59:51  <andythenorth> I think I resigned my reviewer rights
18:00:30  <TrueBrain> or
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 ?
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
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>
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> 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

Powered by YARRSTE version: svn-trunk