IRC logs for #openttd on OFTC at 2021-05-29
⏴ go to previous day
00:12:13 *** Progman has quit IRC (Remote host closed the connection)
00:20:17 *** Wuzzy has quit IRC (Quit: Wuzzy)
01:37:42 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:50:50 *** Wormnest has quit IRC (Quit: Leaving)
02:54:00 *** Beer has quit IRC (Read error: Connection reset by peer)
03:46:36 *** felix is now known as Guest44
03:46:36 *** felix_ is now known as felix
03:48:03 *** Guest44 has quit IRC (Ping timeout: 480 seconds)
04:35:33 *** andythenorth has joined #openttd
05:51:16 *** andythenorth has quit IRC (Quit: andythenorth)
06:00:21 *** andythenorth has joined #openttd
06:12:45 *** snail_UES_ has quit IRC (Quit: snail_UES_)
07:08:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGGOf
07:16:05 <TrueBrain> is it just my understanding of the english language, or is it just weird that our "str_validate" doesn't validate, but more .. "ensure it is valid"? (it changes the string till it is valid, basically)
07:16:50 <TrueBrain> I keep expecting it returning me true/false, but instead it modified the string I gave it :P
07:17:36 <nielsm> yeah str_validate I'd expect to test if it's valid, one that "fixes" it should be called str_validify or str_munge or something
07:18:04 <TrueBrain> yeah, okay, so it is not just me, pfew :) Tnx :)
07:18:30 <Rubidium> it's probably ambiguous. There are no clear markers that it only checks, like a StrIsValid or StrIsEmpty
07:19:22 <TrueBrain> I don't even see how it can be ambiguous, honestly :) "validate" has a very well defined meaning, none allowing "alter it" :P
07:19:36 <TrueBrain> (as far as I understand the English language :D)
07:21:27 <TrueBrain> maybe we should just do a s/str_validate/str_validify/g over the code ..
07:21:28 <Rubidium> "to grant official sanction to by marking" // validated their passport
07:21:34 <TrueBrain> we have enough "patch killers" anyway :P
07:22:12 <Rubidium> that's where you get your stamp in your passport, or they even take away your passport if it has been deemed invalid/illegal
07:22:54 <TrueBrain> I think we are stretching the meaning of "marking" with our str_validate :P
07:22:58 <Rubidium> validify is not even in the dictionary
07:23:15 <Rubidium> or, it means "to validate"
07:24:46 <Rubidium> also, the regexp will likely fail as the std::string variant returns the valid version of the string and does not touch the given one, whereas the char* one changes the given string
07:25:10 <Rubidium> there is, by the way, a StrValid akin the StrEmpty
07:25:48 <TrueBrain> I like how you are finding "beren op de weg", but confusion developers is also not a solution :D
07:26:37 <Rubidium> so the char* str_validate -> StrMakeValidInPlace and the std::string variant to StrGetValid or something with similar meaning but better words
07:27:29 <TrueBrain> I like how parts of our code mixes my_name_is with MyNameIs, depending if we find the function "core" enough :P
07:29:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9302: Change: split check and update callbacks for settings https://git.io/JGGnV
07:30:49 <TrueBrain> I love how that triggered people :)
07:30:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGGnM
07:31:14 <TrueBrain> StrMakeValidInPlace fits the Trim functions, and at least that sounds less confusing to me
07:31:26 <TrueBrain> Rubidium: do you make a PR or shall I?
07:32:17 <Rubidium> well, StrMakeValidInPlace is only valid for the C-string variant, not for the std::string variant as the latter returns a valid std::string and leaves the given std::string untouched
07:32:40 <TrueBrain> yes, you already said that
07:37:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGGCg
07:41:06 <TrueBrain> finally figured out what _gameopt_settings is .. it is for old savegames :) OPTS chunk is no longer saves in new ones
07:42:19 <TrueBrain> and these days we use the PATS chunk to store _settings
07:46:39 *** Progman has joined #openttd
07:47:15 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9302: Change: split check and update callbacks for settings https://git.io/JGtNC
07:48:40 <Rubidium> yup... it was called _patches when it got added to the savegame
07:49:01 <TrueBrain> str_validate is used in two ways
07:49:06 <TrueBrain> one where "last" is the \0
07:49:11 <TrueBrain> one where it is the last valid character
07:51:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9302: Change: split check and update callbacks for settings https://git.io/JGG82
07:52:28 <Rubidium> the first will probably be for dynamically allocated strings, where the allocation is up to and including the '\0', and one where data is written into a buffer and we need to ensure that buffer gets '\0' terminated
07:53:00 <TrueBrain> I cannot figure out what str_validate (the templated version) expects
07:53:10 <Rubidium> though that distinction goes away when we migrate more and more to std::string
07:53:51 <TrueBrain> I would guess it is always safe to include the \0
07:54:19 <TrueBrain> it is forced nul-terminated on exit anyway
07:54:47 <Rubidium> oh, I was mixing up StrValidate, which does str_validate(str, str + strlen(str)) or something similar instead of calling it directly
07:55:02 <TrueBrain> some call StrValidate which does str+strlen+1
07:55:07 <TrueBrain> some call str_validate with str+strlen
07:55:34 <TrueBrain> it seems that str_validate reads to either \0 or "last", supporting both to work fine, from what I can understand of that function
07:55:40 <Rubidium> oh... ye olde endof vs lastof debate/change
07:56:59 <Rubidium> I think str + strlen + 1 is technically wrong, though practically not an issue
07:57:17 <TrueBrain> lastof() is including the \0 too, not?
07:58:20 <Rubidium> char[] str = ""; lastof(str) == str. str + strlen(str) + 1 != str
07:59:11 <TrueBrain> so only +1 if strlen != 0 :D
07:59:53 <Rubidium> only +1 if strlen = (size_t)-1 ;)
08:00:34 <TrueBrain> in that case the +1 is fine :P
08:00:45 <TrueBrain> as "str - 1 + 1 == str"
08:02:20 <TrueBrain> no clue why you say strlen == -1, honestly
08:02:23 <TrueBrain> can it return negative values?
08:02:38 <TrueBrain> sometimes this channel confuses me :P
08:05:10 <Rubidium> well, I assumed your +1 if strlen != 0 was a joke... Anyhow, strlen returns size_t which is signed, so if it where to be that strlen returns (size_t)-1 or maximum value of size_t, then all bytes of the memory can be accessed and all bytes except str[-1] are not 0. In that case there is little to validate, as you'd probably be messing up your stack by doing that
08:05:30 <Rubidium> size_t is *un*signed
08:06:02 *** sla_ro|master has joined #openttd
08:06:46 <TrueBrain> yeah, as I said, this channel sometimes confuses me :P
08:07:34 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9302: Change: split check and update callbacks for settings https://git.io/JGtNC
08:14:27 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9303: Cleanup: set the base in the setting templates, instead of defining the base for every setting https://git.io/JGGE4
08:14:29 <TrueBrain> okay, I was reading the code wrong, the +1 always puts it out the buffer
08:14:38 <TrueBrain> just plan weird code
08:14:47 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9304: Codechange: rename str_validate to StrMakeValid(InPlace) https://git.io/JGGEz
08:15:49 <TrueBrain> plan, yes, that is what I wanted to write, plan
08:16:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9303: Cleanup: set the base in the setting templates, instead of defining the base for every setting https://git.io/JGGEN
08:21:06 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:21:19 *** WormnestAndroid has joined #openttd
08:24:26 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
08:24:40 *** WormnestAndroid has joined #openttd
08:32:09 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9304: Codechange: rename str_validate to StrMakeValid(InPlace) https://git.io/JGG2o
08:32:35 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9303: Cleanup: set the base in the setting templates, instead of defining the base for every setting https://git.io/JGGE4
08:38:20 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9304: Codechange: rename str_validate to StrMakeValid(InPlace) https://git.io/JGGEz
08:44:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGtYy
08:47:14 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGGrv
08:47:25 <TrueBrain> almost fell in a rabbit hole!
08:48:00 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGtYy
08:48:34 <TrueBrain> the whole acquiring company is such a poor UI design, that any solution will only result in more questions :)
08:48:40 <TrueBrain> need a lot of work to become sane, honestly
08:48:54 <TrueBrain> Rubidium: aawwhhh .. at least I hope they left good breadcrumbs for you to eat? :)
08:49:30 <Rubidium> those are stale by now... it's about "nul-terminated"
08:51:26 <Rubidium> well, unicode/utf8 has no character called "nul", only "null". ASCII has had an abbreviation for a character "NUL" since 1965 (before that it was "NULL"), so "nul-terminated" sort-of implies it's ASCII when we're talking about a (supposedly) Utf8 encoded string
08:53:30 <TrueBrain> there, solved your rabbit hole :P
08:53:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9304: Codechange: rename str_validate to StrMakeValid(InPlace) https://git.io/JGGEz
09:06:28 <andythenorth> AWS bill arrived
09:06:31 <andythenorth> triggered a billing alert
09:07:15 <andythenorth> domain renewal time
09:07:37 <TrueBrain> pro-tip: get a CloudFlare account
09:07:40 <TrueBrain> migrate your domain to there
09:07:49 <TrueBrain> (and proxy your traffic to AWS via CloudFlare)
09:07:53 <TrueBrain> saves you a lot of money on the domain :)
09:08:06 <TrueBrain> CloudFlare is (near?) cost price for domains
09:10:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9305: Codechange: move all settings.ini files to table/settings and document what they are about https://git.io/JGGil
09:14:33 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9305: Codechange: move all settings.ini files to table/settings and document what they are about https://git.io/JGGil
09:18:09 <TrueBrain> lol .. okay, settings that are marked "not in save" are all also marked as "no network sync" .. makes sense
09:18:17 <TrueBrain> but .. there are a few "no network sync" that are not marked "not in save"
09:18:24 <TrueBrain> so .. when you join the server you do get those settings?
09:19:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGGPQ
09:19:32 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9304: Codechange: rename str_validate to StrMakeValid(InPlace) https://git.io/JGGXe
09:19:37 <TrueBrain> ah, no, there is special code that prevents that from happening when you are loading a multiplayer game
09:19:55 <TrueBrain> it still feels really odd :P
09:20:25 <TrueBrain> everything in "locale"
09:21:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9300: Fix #9281: acquire a company uses special bookkeeping to make you rich https://git.io/JGtYy
09:21:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9304: Codechange: rename str_validate to StrMakeValid(InPlace) https://git.io/JGGEz
09:22:51 <andythenorth> cloudflare I could save $19
09:24:44 <TrueBrain> and if you let it proxy your site, it saves a bit more, but cache invalidation is harder :P
09:25:18 *** frosch123 has joined #openttd
09:25:29 <TrueBrain> Cloudflare now also has Cloudflare pages, which generate (from GitHub for example) a website and makes it available
09:25:37 <TrueBrain> if you do less than 500 builds per month, it is completely free
09:26:11 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9305: Codechange: move all settings.ini files to table/settings and document what they are about https://git.io/JGG1n
09:27:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9305: Codechange: move all settings.ini files to table/settings and document what they are about https://git.io/JGGil
09:27:14 <andythenorth> "Just tell us your build command (e.g. npm run build) and we’ll take care of the rest," :O
09:27:18 <andythenorth> my build command is 'make'
09:27:28 * andythenorth considers subscribing to the newsletter
09:28:01 <frosch123> TrueBrain: yes, currency is really weird. some people care about playing scenarios with the "right" currency (so, store in savegame). others consider it a pure visual thing (client setting)
09:28:17 <TrueBrain> ah, okay, that somewhat makes sense :)
09:28:39 <frosch123> so, it's "store in singleplayer" and "do not bother in multiplayer" or so
09:28:44 <TrueBrain> I was looking through the history, but it is not documented :P
09:29:07 <TrueBrain> I am going to document some more parts of our settings system :P
09:29:16 <TrueBrain> as it is confusing as fuck :D
09:30:40 <TrueBrain> one of the more "annoying" issues with what our setting system has become
09:30:43 <TrueBrain> we have those nice groups
09:30:50 <TrueBrain> but that doesn't mean you can now move them to their own file
09:30:52 <TrueBrain> like locale_settings.ini
09:30:55 <TrueBrain> with a nice comment
09:31:00 <TrueBrain> because ... they are saved in the savegame
09:35:20 <frosch123> yep, we need more json-like savegames :)
09:35:49 <TrueBrain> haha, exactly what I said :P
09:35:55 <TrueBrain> (well, in private to Rb, so it doesn't count)
09:36:19 <TrueBrain> well, honestly, it doesn't have to be JSON, just a key->value chunk
09:36:28 <TrueBrain> with value a JSON encoded string :P
09:36:43 <frosch123> we probably would only have needed 1/3 of the savegame versions, if the savegame had key:value thingies
09:37:01 <TrueBrain> I am strongly wondering if I want to go down this rabbit hole today or not :P
09:37:23 <TrueBrain> it solves a lot of issues now and in the future
09:37:56 <TrueBrain> I am also kinda looking at how to add presets, which is really close to this stuff too :)
09:39:22 <Rubidium> the question though... json or ini in the savegame? The ini code already exists, just need to serialize it into the savegame
09:39:41 <TrueBrain> ideal, the key->value is str->str, in my book
09:40:00 <TrueBrain> so I am fine with the ini stuff, as long as we can (de)serialize all values to a string :)
09:41:08 <TrueBrain> we could do str->(any), but that kinda requires the key to be versionized .. so "custom_sea_level.1", "custom_sea_level.2" etc
09:41:13 <TrueBrain> not an uncommon schema
09:41:30 <TrueBrain> (otherwise you still need to do savegame bumps when-ever a type of a setting changes)
09:42:32 <frosch123> if you want a deeper rabbit hole: add string values to all enum settings :)
09:42:59 <TrueBrain> well, we do for some settings already
09:43:41 <frosch123> it's fancier with c++23, but you probably don't want to wait for that
09:44:14 <frosch123> annotations and reflections
09:44:30 <frosch123> so you can add annotations to the enum type, and use that in serialisation template magic
09:44:48 <frosch123> it won't be pretty, but powerful :p
09:45:12 <frosch123> oh, and you probably will need a compile-time debugger :p
09:46:08 <TrueBrain> but okay .. I am kinda serious about changing how we store settings
09:46:40 <TrueBrain> so any preference in what format etc, before I just do what-ever-comes-to-my-mind-in-the-next-few-hours?
09:47:11 <frosch123> want a deeper rabbit hole? store pool items as tables: list of keys first, then values for each pool item
09:47:21 <frosch123> want a deeper rabbit hole? use sqlite for the savegame
09:47:42 <TrueBrain> what are the benefits of those?
09:48:06 <frosch123> TrueBrain: i would not add a nested serialisation inside the savegame, though we do that for ai/gs settings
09:48:27 <frosch123> so, i would prefer an savegame-array with pairs of strings
09:48:34 <michi_cc_> You can do it like Audacity (which also switch to use sqlite) and try to add some "diagnostics" :P
09:48:45 *** sla_ro|master has quit IRC ()
09:48:53 <TrueBrain> only if it can be opt-out
09:49:03 *** michi_cc_ is now known as michi_cc
09:49:08 <frosch123> TrueBrain: storing pool items as key:value pairs has the same benefit as the settings. you can add/remove/reorder members
09:49:40 <frosch123> just that i consider it stupid to repeat the keys for each item (compression will save the size, but not the runtime)
09:49:46 <TrueBrain> owh, you meant it like that, sorry, it sounds liked {0 => <blobl>, 1 => <blob>} :D
09:50:10 <TrueBrain> ah, yeah, you applied optimizations in your idea :P
09:50:29 <frosch123> pretty sure you can abuse our saveload system as msgpack
09:50:55 <frosch123> so, array of string-key + type-id + union of int/bool/string
09:51:31 <frosch123> want a deeper rabbit hole? do the same with the bit-packed map array :p
09:51:31 <TrueBrain> storing the type of the value in the savegame
09:52:02 <TrueBrain> I don't really care about your rabbit hole ofc (hihi), but more the direction we would like to move this if we would do this
09:54:22 <TrueBrain> with sqlite you could use the "describe table" to read the format vehicles for example are stored in
09:54:30 <TrueBrain> and the client can figure out how to load it from there
09:54:44 <TrueBrain> or name tables like vehicle.1, vehicle.2, etc
09:54:51 <TrueBrain> would move savegame versions rather local, instead of global
09:57:01 <TrueBrain> frosch123: weren't you going to add sqlite for newgrf scan or something ?
09:57:21 <TrueBrain> s/sqlite/sqlite support/
09:57:53 <frosch123> i remembered i raised the question. not sure whether there was an answer :p
09:58:39 <TrueBrain> I remember you talking a lot about SQLite :P
09:59:30 <TrueBrain> if we want to move towards SQLite (I am not against that in the slightest), settings would need to be str->blob I guess
09:59:36 <frosch123> it's one of those generic answers: you won't need 90% of it, but it somehow contains what you need
10:00:07 <TrueBrain> or a table for each type :P
10:02:03 <TrueBrain> so either we serialize all setting values, or we prefix it with the type
10:02:58 <frosch123> i have a foss game inspired by master-of-orion (forgot it's name). it's turn based and transfers savegames between server and client in each turn.
10:03:12 <frosch123> it uses boost serialisation, and the result is terrible
10:03:37 <frosch123> the longer the game goes one, the bigger the savegame becomes, and anvancing a turn takes 10 seconds or so :p
10:03:44 <TrueBrain> we basically only have to do 3 types of serialization: bool, integer, string :)
10:03:47 <frosch123> all spend in serialisation and deserialisation
10:04:08 <TrueBrain> and even bool we can smash into integer, ofc
10:04:13 <frosch123> TrueBrain: yay, we banned floats?
10:04:53 <TrueBrain> our SaveLoad cannot store floats from what I can tell :P
10:04:57 <frosch123> TrueBrain: enums are strings, i hope :)
10:05:22 <TrueBrain> that would be optional, in my opinion
10:05:33 <frosch123> TrueBrain: json and friends hav bool, int, float, string, dict and list
10:05:44 <TrueBrain> we don't need dict/list atm
10:05:59 <TrueBrain> and enums are ints as far as I know :)
10:06:03 <frosch123> your settings are a dict
10:06:13 <frosch123> and you need list or set for some settings :)
10:06:23 <Rubidium> enums are currently ints, unless someone configured it as omany (one of many), then it's more akin a string after serialization
10:07:07 <TrueBrain> frosch123: we are talking about the savegame here, right? :)
10:07:10 <TrueBrain> not about the .ini :P
10:07:29 <TrueBrain> there are no list-types settings saved atm :)
10:07:54 <Rubidium> though there were in the past (_old_diff_custom)
10:08:06 <frosch123> hmm, display_opt is the only MMANY setting, i expected more :p
10:08:35 <TrueBrain> issue with settings is that they touch two worlds, which is annoying .. the .ini, and the savegame :)
10:08:46 <TrueBrain> mainly I wonder about serialization vs type-prefix, is the signed/unsigned, and size of integers
10:08:56 <TrueBrain> I have a hard time thinking of a reason that would be an issue
10:09:29 <Rubidium> why not use the save (de)serialize code for the ini and the savegame?
10:10:22 <Rubidium> as ini does string -> value or value -> string conversions too, or the settings layer does as ini is string key -> string value
10:10:30 <frosch123> TrueBrain: i think i would prefer storing bools as enums
10:10:50 <TrueBrain> you mean as "true" / "false" string?
10:10:53 <frosch123> when we need savegame conversion for bool settings, then because we added a third option, and it became an enum
10:11:21 <TrueBrain> so you mean storing it as 0 / 1?
10:12:14 <frosch123> something that allows changing the format to enum and adding a third option, without requiring savegame conversion code. except maybe defining the string for the old true/false values
10:12:42 <frosch123> it doesn't matter much whether you use 0/1, false/true, no/yes, disabled/enabled
10:13:09 <TrueBrain> okay, I see no reason why storing as string would be an issue for savegames
10:13:13 <frosch123> unless your crystal ball tells you what the third value will be :p
10:13:18 <TrueBrain> except indeed the increased load-times for all the "atoi"s
10:13:57 <TrueBrain> we have 200-ish entries to save
10:14:02 <TrueBrain> most of which are integers
10:14:08 <TrueBrain> would that be relevant? :)
10:14:32 <frosch123> for settings it won't be relevant. it will become relevant when doing the same for poolitems and map array :)
10:14:46 <TrueBrain> honestly, I would store poolitems differently
10:14:53 <TrueBrain> with the idea it moves to sqlite at some point
10:15:00 <TrueBrain> it needs to know the "schema"
10:15:10 <TrueBrain> so those fields can be typed
10:15:34 <TrueBrain> they don't need serialization, as the table can contain that information
10:15:41 <TrueBrain> for settings it is different, as it is a single table for all
10:15:41 <frosch123> ah, maybe add two settings sections then
10:15:53 <TrueBrain> well, that was the other suggestion I made, yes :)
10:15:56 <TrueBrain> a table per type :P
10:15:58 <frosch123> one with "string-key: int value", one with "string-key: string-value"
10:16:11 <frosch123> i kind of prefer that now :)
10:16:14 <Rubidium> practically that schema could be used for the settings as well. It's just one row with a lot of columns, so why do a special key-value here?
10:16:20 <TrueBrain> well, your enum is a bit of an issue there I would guess
10:16:31 <TrueBrain> a setting goes from 0/1 int to left/middle/right string
10:16:51 <TrueBrain> Rubidium: the idea is to NOT store all settings in a single row :P
10:17:46 <TrueBrain> hmm, setting from int to string is just some glue code, that is hardly an issue
10:18:23 <TrueBrain> Rubidium: a table should match an in-game struct, so to say
10:18:41 <TrueBrain> well, I guess you can do that for settings too
10:18:44 <Rubidium> it would. GameSettings
10:18:47 <TrueBrain> but .. that feels really inside-out
10:20:39 <Rubidium> maybe, but why make something where you define a schema and tell the key and type of everything so you can load everything efficiently. And then when you come to the settings say:... well, the schema will be (key: string, value: string) and you have to figure out the type yourself.
10:21:11 <TrueBrain> we just said not to do the latter, but instead of a table per type (given we only have 2 types)
10:21:34 <TrueBrain> which makes the settings a list
10:21:44 <TrueBrain> which makes stuff like debugging etc also a lot easier
10:22:42 <Rubidium> but how to handle enum types? Just the raw number, or the label? So enum-ints end up in the string table
10:22:46 <TrueBrain> there are most likely more fundamental reasons not to, but making a table with 200+ columns, feels wrong :P
10:23:42 <frosch123> Rubidium: enums should become strings. then those strings can also be used in the settings, and in presets, and on master server, and what not
10:23:52 <Rubidium> yeah, but implementing functionality that exists in your schema again just because a table with 200+ columns feels wrong, feels wrong too.
10:23:57 <frosch123> oh, and in rcon setting
10:24:30 <TrueBrain> for a vehicle, his struct defines a single object
10:24:36 <TrueBrain> for settings, each entry defines a single object
10:24:50 <TrueBrain> so I am not in favour of doing a single row for the settings table
10:24:56 <Rubidium> frosch123: the omany/mmanys already do that in rcon/console
10:25:17 <frosch123> yes, we need that for all enum settings :)
10:25:27 <TrueBrain> we need a method do make that easy :P
10:25:38 <frosch123> TrueBrain: if you store openttd.cfg as sqlite, each row could be a preset :p
10:25:41 <Rubidium> I am not in favour of implementing the same functionality twice without good reasons
10:25:53 <TrueBrain> frosch123: haha :) Fair :P Just JSON encode it and be done with it :P
10:27:07 <TrueBrain> Rubidium: honestly, that is a bit overreacting, and taking it very black/white. A bit of clever programming doesn't "implement it twice" :)
10:27:18 <TrueBrain> it is a simple transformation after all
10:27:22 <TrueBrain> anyway, we are stuck in a silly detail
10:27:39 <TrueBrain> so: settings are typed, so no serialization as such
10:27:49 <TrueBrain> we can consider enum -> string a serialization ofc, but that is not what I meant :)
10:28:19 <TrueBrain> how do we do versioning of settings, as in: adding a value, simple, removing one .. some glue code, easy enough too
10:28:26 <TrueBrain> but what if it actually changes of type?
10:28:30 <TrueBrain> do we just say: use a new name?
10:29:39 <TrueBrain> or if it actually changes meaning, that is possible too ofc, looking at the history :)
10:29:56 <Rubidium> just do it like the ini file, provide a convert callback when it fails to parse it
10:30:38 <Rubidium> although that ofcourse works only in one direction...
10:31:02 <TrueBrain> lets take an example: snow_line_height used to be multiplied by TILE_HEIGHT
10:31:06 <TrueBrain> this got fixed somewhere along the line
10:31:14 <TrueBrain> a savegame bump is now tracking which version you have
10:31:32 <TrueBrain> we no longer want savegame bumps, as they are annoying as fuck :P
10:31:54 <Rubidium> you need savegame bumps for that kinds of functionality
10:32:14 <TrueBrain> I see two easy solutions: either say: use a new name for that setting
10:32:15 <Rubidium> otherwise the newer games need to convert to older "types"
10:32:18 <frosch123> TrueBrain: new settings should be ignored, missing setting should use default. new setting values should refuse to load the savegame
10:32:18 <TrueBrain> or, version per setting
10:32:44 <frosch123> for everything else, you still need a global savegame version number. if you make real structural changes, with real conversion code
10:33:01 <TrueBrain> I don't see that you do, honestly :)
10:33:19 <frosch123> TrueBrain: "version per setting/struct" is on my long-time list of "failed concepts" :p
10:33:41 <TrueBrain> please do explain :)
10:33:53 <frosch123> if you move something between pool item and map array, or between different pool items. you will need global savegame conversion code
10:33:58 <frosch123> no local versions will save you
10:34:23 <TrueBrain> there are solutions there too, but sure, for sanity, these kind of changes, I can understand that
10:34:27 <frosch123> you can already see this in ottd: afterload.cpp containst most conversions, and you can insert them wherever you need them
10:34:29 <TrueBrain> but like snow_line_height is very local :)
10:34:40 <Rubidium> TrueBrain: take freeform edges as an example. You can set it, but loading it in an old version of OpenTTD that does not support it will be broken beyond repair. There is nothing you can do in saving in the new version that allows the old version to load it, except well.. not saving
10:35:02 <frosch123> some other _sl files also contain conversion code, and i think there is a long-.standing issue on GH; where some savegame crashes
10:35:27 <frosch123> because it does something inside vehicle_sl, which needs to be done in different order, somewhere inside afterload
10:35:53 <TrueBrain> so that would basically make settings only free of bumps when adding new settings
10:35:56 <Rubidium> snow_line_height is actually part of adding more height levels, so the version before that will be broken as it will only read the low 4 bits of the height. In other words, with the "new" version of the setting, that savegame cannot be read/interpreted correctly by the older vrsion of OpenTTD
10:36:19 <TrueBrain> seems you took a turn somewhere I didn't :D
10:36:24 <frosch123> TrueBrain: so essentially: AfterLoadVehicles is crap. it's almost impossible to keep savegame conversion sane, if you split it over different functions
10:37:27 <TrueBrain> frosch123: I agree, structural changes of that nature need more global control
10:37:34 <Rubidium> TrueBrain: as far as I understood you saw snow_height_line as a setting that was changed and needed a savegame bump because of that, but it was part of a much larger change that required conversions of the savegame
10:38:20 <TrueBrain> Rubidium: no, that was not the case. in this case snow_line_height had a different unit
10:38:24 <frosch123> TrueBrain: using a self-describing savegame format is less about "old versions of ottd can load newer savegames". that makes no sense in any case. it's more about "bananas can read settings, without requriing update for each ottd and patchpack version"
10:38:42 <TrueBrain> frosch123: I do not know why we took the turn about older OpenTTD loading newer savegames :P
10:39:04 <TrueBrain> I personally really do not care about forwards compatibility :D
10:39:38 <frosch123> i do not remember how it was done with the snow-line thing. but we have the same problem with openttd.cfg. in the past we sometimes renamed the setting, so old values from openttd.cfg are discarded
10:40:17 <TrueBrain> snow-line-height is a nice example of how not to do it, but not really relevant atm :)
10:40:23 <TrueBrain> we just have that settings change meaning
10:40:27 <TrueBrain> either by value or by function
10:40:38 <TrueBrain> and indeed what you say: if we rename, the old value is lost
10:40:42 <TrueBrain> so some conversion might be nice
10:41:00 <frosch123> Rubidium: truebrain means the snow-line change from 1.11, not more-heightlevels. 1.11 changed the snowline setting from "heightlevel" to "percentage of area"
10:41:09 <TrueBrain> if (IsSavegameVersionBefore(SLV_164) && _settings_game.game_creation.snow_line_height >= MIN_SNOWLINE_HEIGHT * TILE_HEIGHT) {
10:41:13 <TrueBrain> I mean that bullshit line of code
10:41:22 <TrueBrain> if we want to zoom in on this specific issue :)
10:41:40 <TrueBrain> the setting is in a quantum state :P
10:41:45 <Rubidium> oh... didn't know about that
10:41:59 <TrueBrain> but as I said: the value changed from height * TILE_HEIGHT to just height
10:42:14 <TrueBrain> do we 1) rename the variable in such case, 2) have some local versioning, 3) have some global versions
10:42:18 <TrueBrain> at least, those are the things I read so far
10:43:22 <TrueBrain> similar example: we changed our zoom-thingy to extend with "auto"
10:43:27 <frosch123> TrueBrain: imo, when integer settings change unit, rename them. adding enum items to existing settings should not require a savegame version, but rather detect it by the usage of the new value
10:43:28 <TrueBrain> which also broke stuff :P
10:43:35 <Rubidium> how would we handle removing settings from the savegame by the way? I guess that's going to use the same logic as it is now to determine whether or not to write that to the savegame, right?
10:44:12 <TrueBrain> frosch123: that works for me
10:44:33 <TrueBrain> Rubidium: the setting is simply no longer there, so it is not saved
10:44:52 <frosch123> huh? saving is not a differential thing. we always write all settings that we know on save. we do not "transfer" settings from the old savegame, if we did not know them
10:44:53 <Rubidium> but we would still accept savegames that have the removed setting, so we need to keep track of the name of the removed setting?
10:45:16 <TrueBrain> I am lost, sorry :)
10:45:30 <frosch123> Rubidium: ah, no, i would just ignore unknown settings
10:46:08 <frosch123> if a setting is so important that you cannot load the savegame without understanding it, then you need a version bump somewhere else
10:46:23 <TrueBrain> would be a really weird setting, but yes
10:46:40 <TrueBrain> (as in, I agree :P)
10:47:08 <frosch123> for sure, citymania will abuse it endlessly, to store non-settings in the settings data, like goals and company statistics, but well :p
10:47:09 <TrueBrain> it would accidentally mean OpenTTD becomes a bit more forward-compatible :P
10:47:33 <frosch123> a bit like ttdp. ttdp stored some things in the VOID tiles around the map
10:47:56 <frosch123> pretty sure citimania will abuse settings to store anything :p
10:48:32 <TrueBrain> it basically becomes a nosql storage mechanism :P
10:49:05 <frosch123> yep, servers can store data, which clients may optionally understand, or ignore
10:49:16 <TrueBrain> but you could already with chunks
10:49:18 <TrueBrain> so nothing really new
10:49:39 <frosch123> are you sure? aren't unknown chunks a hard error?
10:49:57 <TrueBrain> was that JGRPP? Hmm
10:50:12 <TrueBrain> you are right, we abort on it
10:50:27 <frosch123> if (ch == nullptr) SlErrorCorrupt("Unknown chunk type");
10:50:39 <TrueBrain> pedantic as we are :D
10:51:35 <TrueBrain> okay, with these constraints, it should be relative easy to implement within the current saveload system
10:52:32 <TrueBrain> for pools you mentioned you want something similar ..
10:52:40 <TrueBrain> so storing "x" as string
10:53:04 <TrueBrain> owh, x_pos, sorry :P
10:53:51 <frosch123> poolitems have many game internals, bitsets, references to other poolitems
10:54:13 <frosch123> so, string enums are not too useful there
10:54:34 <frosch123> but table schemas inside the savegame would still be cool
10:54:39 <TrueBrain> to be clear, I meant that we store "x_pos" -> value, over [value, ..]
10:55:13 <TrueBrain> so if we do this not only for settings, but a bit broader, we talk about a type-dicts to store in the savegame, basically
10:56:08 <TrueBrain> with the same rules? As in: if you read a key you don't know, you just ignore it. If it contains a value you don't expect, you abort. Type-change means you have to change the name?
10:56:38 <TrueBrain> and we stop worrying about signed/unsigned and 8/16/32/64 :P
10:56:53 <TrueBrain> well, the latter is not hard to keep for our saveload
10:57:15 <frosch123> yes. two ways to look at the same thing: alternating keys and values like in json. or prefixing everything with a schema: [("x_pos", "int32"), ("flags", "uint32"), ("order_list", "OrderList")], [-5, 64, 27], ...
10:57:45 <TrueBrain> yeah, "do you trust compression enough" question :)
10:59:21 <frosch123> TrueBrain: i thought the plan was now to keep storing integers in binary. so they would still have size and signedness. just that the savegame stores the typeinfo for each keys
10:59:47 <TrueBrain> frosch123: it is, but SQLite doesn't support that if we use their schema system :)
10:59:54 <TrueBrain> it only has a few primitives
11:00:02 <frosch123> so you want to store everything as int64 ?
11:00:09 <TrueBrain> for now, lets keep our types
11:00:17 <TrueBrain> but towards SQLite, we need to think about it
11:00:46 <Rubidium> SQLite is type... uhm... agnostic
11:00:48 <TrueBrain> (for example by simply not using their schema system, which is perfectly possible)
11:01:14 <Rubidium> it doesn't know NaN for real, but instead of giving an error it just writes a string
11:01:37 <TrueBrain> Rubidium: shouldn't happen with SQLite3
11:01:44 <Rubidium> and then reading that as a double gives you back 0 as it doesn't know how to convert it/it is some special value
11:01:45 <TrueBrain> if a field is marked as REAL affinity
11:01:52 <TrueBrain> it should fail to convert "NaN" :)
11:03:05 <frosch123> Note that a declared type of "FLOATING POINT" would give INTEGER affinity, not REAL affinity, due to the "INT" at the end of "POINT". <- haha, i never bothered using specific types, but that is funny
11:03:23 <TrueBrain> and that it is a note means people ran into it ..
11:04:10 <TrueBrain> so, code-wise ... we also need to keep reading the current chunks etc ..
11:04:24 <TrueBrain> so new chunk-names? :P
11:04:49 <TrueBrain> move the current loaders to a folder indicating they use an old system
11:05:51 <frosch123> TrueBrain: maybe you can read old savegames with the new reader, by giving skipping reading the schema and using a built-in schema from the savegame version
11:05:54 <Rubidium> TrueBrain: it does, or at least last year it did happen
11:06:30 <TrueBrain> frosch123: I like that approach
11:06:46 <frosch123> if you prefix all the chunks with the schema, and add the data afterwards, maybe the data could stay binary the same
11:07:11 <TrueBrain> it does look that way
11:07:39 <TrueBrain> Rubidium: no, you are right, the type of the field changes
11:07:43 <TrueBrain> which is a bit hilarious
11:09:28 <Rubidium> and extremely annoying when doing it through a library. I send it an actual float with NaN as value, and then getting the same field returns me 0. If your database does not support it, then please bomb out during the save instead of silently ignoring stuff
11:10:27 <TrueBrain> well, SQLite added types per row
11:10:50 <TrueBrain> which is not what we expect from a schema definition :)
11:11:47 <TrueBrain> frosch123: btw, I aint touching _m? :P
11:11:51 <TrueBrain> just to be clear about the scope here :D
11:12:12 <Rubidium> _m and _me need to go... according to lgtm
11:12:22 <TrueBrain> I think everyone agrees :P
11:12:53 <Rubidium> Poor global variable name '_m'. Prefer longer, descriptive names for globals (eg. kMyGlobalConstant, not foo).
11:13:29 <TrueBrain> of all the reasons to nuke it, that is not one high on the list :P
11:16:04 <frosch123> Rubidium: leading _ in identifiers is reserved. except for string-literal-postfixes, where it is the other way around :p
11:25:51 <frosch123> vehicles and stations are a problem
11:26:10 <frosch123> train/rv/ship/aircraft/disaster/smoke share the same pool and chunk
11:26:16 <frosch123> but have different structures per type
11:26:22 <frosch123> same with stations and waypoints
11:26:46 <TrueBrain> guess it has been on our wish-list for a while to split those pools anyway
11:29:23 <frosch123> no :p waypoints/stations were separate before. they were merged to have a unique id that can reference both
11:29:45 <TrueBrain> but I read several times already people want to split up vehicle pool :P
11:29:46 <TrueBrain> ; end. This isn't really the best solution, the settings the server can tell the client about should
11:29:47 <TrueBrain> ; either use a separate array or some other form of identifier.
11:29:50 <frosch123> some for vehicles. a single vehicleid is easier than a (vehicletype, vehicleid) pair everywhere
11:31:59 <TrueBrain> frosch123: I don't get that last argument, but okay :) I just have seen more than 1 developer complain that they wanted to change it :P
11:32:02 <TrueBrain> not in scope either way :)
11:32:35 <TrueBrain> loading the current savegame might require a bit of special glue
11:32:42 <TrueBrain> but in the new system, we can just store them per type, I guess
11:32:45 <TrueBrain> and load them back in a single pool
11:32:46 <frosch123> maybe you can get away with storing them in different chunks/tables. but that won't make it easier to load old savegames
11:33:05 <TrueBrain> clearly I could have used 1 sentence where I used 3 :P
11:33:51 <frosch123> btw. i do not recall anyone wanting to split vehicles into different pools :üp
11:34:03 *** peter1139 has joined #openttd
11:34:14 <frosch123> i only recall forum newbies wanting to parallize vehicle movement, thinking anything would be independent
11:34:36 <frosch123> man, my typing skill is top-notch today :p
11:34:42 <TrueBrain> I will point to this time in the IRC logs next time I see a developer suggesting it, no worries :)
11:35:17 <TrueBrain> right .. so now I have found the depth of this rabbit hole .. lets rewind and see in what order I am going to do my wishlist :)
11:35:40 <TrueBrain> first .. CmdChangeSetting needs to stop using an index in a table .. as that is annoying in so many ways :P
11:35:56 <TrueBrain> next .. I split settings into their groups, so my sanity is increased
11:36:05 *** peter1138 has quit IRC (Ping timeout: 480 seconds)
11:36:18 <TrueBrain> followed by this saveload idea
11:36:30 <TrueBrain> I want to have a "gui_settings.h"
11:36:40 <TrueBrain> and a "game_settings.h"
11:36:58 <TrueBrain> instead of 350+ entries in a single file where the order cannot be changed easily :P
11:37:14 <frosch123> ow, i would be scared of that rabbit hole, good luck :)
11:37:31 <TrueBrain> the saveload is the biggest rabbit hole there :P
11:37:39 <TrueBrain> the rest Rubidium made rather easy :P
11:37:46 <TrueBrain> well, except CmdChangeSetting
11:37:58 <TrueBrain> but I think we can just use "text" to send the string-name
11:38:06 *** HerzogDeXtEr has joined #openttd
11:38:14 <frosch123> yeah, from a coding pov, sure :p but changing the ini files has more "community interaction" :p
11:38:30 <TrueBrain> owh, the configuration file stays the same
11:38:36 <TrueBrain> I am just talking about how it looks in our code
11:38:49 <TrueBrain> and all that, because you gave the idea we wanted sticky invite codes btw
11:38:56 <TrueBrain> just to show where the rabbit hole started :D
11:39:15 <frosch123> oh, with "ini" you meant the settings-desc-ini :) i was on the openttd.cfg track
11:39:20 <andythenorth> off-topic: road vehicle chains that the player can compose? o_O
11:39:22 <TrueBrain> settings.ini, yes :)
11:39:34 <TrueBrain> no, sorry .. not going to touch openttd.cfg that much -yet-
11:39:39 <TrueBrain> I do want to move out ban-list and others
11:39:43 <TrueBrain> but for that I need all this first :D
11:40:44 <andythenorth> also noise limits for ships?
11:41:01 <frosch123> andythenorth: did you ever play with airport noise limits?
11:41:18 <andythenorth> I disable them with ogfx + airports
11:42:26 * andythenorth tries to remember what desyncs in cb 36
11:42:33 <andythenorth> doing stuff with hovercraft
11:43:06 <andythenorth> I had a PR for time travelled or something
11:44:56 <andythenorth> was there anything left to do?
11:59:20 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
12:00:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
12:01:31 <TrueBrain> that moment you find the linkgraph saveload code
12:01:35 <TrueBrain> what happened there? :D
12:04:23 <Rubidium> now you cannot unsee it
12:04:34 *** peter1139 has quit IRC (Remote host closed the connection)
12:04:55 *** peter1138 has joined #openttd
12:04:55 *** ChanServ sets mode: +o peter1138
12:05:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
12:05:36 <TrueBrain> so it stores a bit of the settings there, as the runner depends on the correct ones .. okay .. I get that ..
12:05:58 <TrueBrain> but so many questions
12:07:28 <andythenorth> one day we look at my python grf compiles on a livestream :P
12:07:35 <andythenorth> TB will run out of words
12:07:46 <TrueBrain> no, I just lower my expectations, and we are fine :P
12:08:05 <andythenorth> the basics are fine...then the graphics compositing happens
12:09:01 <andythenorth> turns out graphics compositing is nothing but...complicated
12:11:24 <TrueBrain> lol, my PR crashes and burns :P
12:12:01 <andythenorth> if I wasn't so lazy, I could write a lot less code
12:17:22 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9307: Change: artificially limit heightmap sizes to something reasonable https://git.io/JGZqm
12:18:09 *** peter1138 has quit IRC (Ping timeout: 480 seconds)
12:18:51 <Rubidium> TrueBrain: nice... making space for 64 bit settings! ;)
12:20:00 *** peter1138 has joined #openttd
12:20:01 *** ChanServ sets mode: +o peter1138
12:21:58 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on pull request #9307: Fix: artificially limit heightmap sizes to something reasonable https://git.io/JGZqb
12:27:38 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZmp
12:34:32 *** peter1138 has quit IRC (Remote host closed the connection)
12:42:19 *** andythenorth has quit IRC (Quit: andythenorth)
12:50:53 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
12:53:00 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
12:54:53 <TrueBrain> right, now it is tested :)
12:58:36 <TrueBrain> clearly not sufficiently, lol
12:59:51 <TrueBrain> haha, yes, okay .. eeuuhhh
12:59:52 *** peter1138 has joined #openttd
12:59:52 *** ChanServ sets mode: +o peter1138
13:00:14 <TrueBrain> the moment you find out that "const char *" is modified
13:00:18 <TrueBrain> stupid StrMakeValidInPlace :P
13:01:55 <Rubidium> though where's that used in your current PR?
13:03:39 <TrueBrain> basically, my earlier PR breaks scripts
13:04:43 <TrueBrain> ah, no, the only usage was ""
13:12:18 <TrueBrain> Direct leak of 16 byte(s) in 1 object(s) allocated from:
13:12:22 <TrueBrain> #1 0x5637488b17f4 in Layouter::GetFont(FontSize, TextColour)
13:12:33 <TrueBrain> #16 0x563748b986bd in ShowNewspaper
13:13:40 <glx> that's OS dependant I guess
13:14:08 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
13:14:32 <TrueBrain> lets see what that does
13:17:20 *** peter1138 has quit IRC (Read error: Connection reset by peer)
13:17:55 *** peter1138 has joined #openttd
13:17:55 *** ChanServ sets mode: +o peter1138
13:18:08 <TrueBrain> I think peter1138 's vlan work broke stuff :P
13:18:45 <glx> progress, regression passed :)
13:20:47 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
13:21:22 *** HerzogDeXtEr has joined #openttd
13:22:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:22:28 <TrueBrain> okay, a PR to solve it "nicely"
13:23:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
13:23:49 <TrueBrain> stupid str_validate() :P
13:24:06 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZl9
13:24:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:24:44 <TrueBrain> quickest fix ever? :P
13:24:49 <TrueBrain> I spotted it myself too, and was just pushing :D
13:25:16 <frosch123> must be a timezone effect
13:25:35 <TrueBrain> I like std::string .. saves me from doing stredup() :P
13:26:02 <TrueBrain> hmm .. now I am using assign()
13:27:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:27:23 <frosch123> This diff is outdated, please refresh and try again.
13:28:04 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZ4r
13:29:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:29:07 <Rubidium> that reminds me of another patchkiller in the same general area I was thinking about...
13:29:09 <TrueBrain> I still have a hard time remembering when stuff it auto-initialized :P
13:29:10 <Rubidium> -typedef CommandCost CommandProc(TileIndex tile, DoCommandFlag flags, uint32 p1, uint32 p2, const char *text);
13:29:13 <Rubidium> +typedef CommandCost CommandProc(TileIndex tile, DoCommandFlag flags, uint32 p1, uint32 p2, const std::string &text);
13:29:18 <TrueBrain> Rubidium: DO ITUHHHH
13:29:31 <glx> oh no, I have a conflict in my window PR
13:29:37 <TrueBrain> and do "std::string text" and we don't have to copy text :P
13:29:56 *** andythenorth has joined #openttd
13:30:21 <TrueBrain> well, that is only true for ScriptObject::DoCommand
13:31:32 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZB0
13:31:36 <TrueBrain> I do feel a bit bad for JGR .. I hope he can figure out an easy way to backport all these changes ..
13:31:53 <TrueBrain> frosch123: I wasn't 100% sure that empty() equals nullptr for all users
13:32:06 <TrueBrain> I can imagine something doing SetName("")
13:32:09 <TrueBrain> which means something else?
13:32:36 <TrueBrain> well, I guess we can wait for the bug report if that is the case :P
13:32:53 <frosch123> ok, maybe use "GetCommandFlags(cmd) & CMD_STR_CTRL" as condition then?
13:33:05 <frosch123> or better some "bool has_string = ..." at the top
13:35:03 <TrueBrain> fuck it, lets change "text" into std::string
13:36:18 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:36:22 <DorpsGek> [OpenTTD/BaNaNaS] frosch123 opened pull request #98: Change: migrate OpenTTD user LaDoncella to GitHub user Bluebreaker https://git.io/JGZRG
13:36:47 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain approved pull request #98: Change: migrate OpenTTD user LaDoncella to GitHub user Bluebreaker https://git.io/JGZRl
13:37:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:37:25 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain merged pull request #98: Change: migrate OpenTTD user LaDoncella to GitHub user Bluebreaker https://git.io/JGZRG
13:38:47 <TrueBrain> hmm .. what does std::string do if it is given a nullptr?
13:38:53 <TrueBrain> I expected a compile error :P
13:39:21 <frosch123> almost every std::string PR contained a crash bug of that type :p
13:39:49 <glx> default nullptr in constructors ?
13:39:54 <TrueBrain> why can't you use {} in a ternary, sad
13:40:22 <frosch123> a ternary deduces the type from the first choice
13:40:25 <glx> ternary requires same types on both sides
13:40:30 <frosch123> so {} works in the else part :)
13:40:38 <TrueBrain> yeah, it doesn't :(
13:40:46 <TrueBrain> progress != nullptr ? progress->GetEncodedText() : std::string {}
13:40:49 <TrueBrain> does seem to work :P
13:40:58 <TrueBrain> const char * vs std::string ;)
13:41:08 <glx> "" should work too in this case
13:41:14 <frosch123> did you put a space between std::string and {} :p
13:41:30 <TrueBrain> glx: wise men told me {} is faster than ""
13:42:22 <frosch123> std::string constructor is constexpr meanwhile
13:42:25 <TrueBrain> okay, I need to check CMD_RENAME_SIGN if nullptr vs "" is an issue
13:42:30 <frosch123> so pretty sure it does not save anything with a recent compiler
13:43:03 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
13:44:47 <TrueBrain> I am regretting this already :D
13:45:59 <frosch123> i am pretty sure the difference of nullptr vs "" does not make it over the network
13:46:10 <frosch123> in the command packet
13:46:26 <frosch123> so, imo keep the const char* text in ScriptObject::DoCommand
13:46:40 <frosch123> and use CMD_STR_CTRL in all conditions, instead of the emptyness
13:46:46 <TrueBrain> we need to convert some day, but yeah ... it needs other things converted first :D
13:47:37 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #9274: Fix f6d5c01: Delay deletion for self closing windows https://git.io/JsCsA
13:49:01 <TrueBrain> what does printf("%s", nullptr) do?
13:49:44 <glx> depends on OS IIRC, remember the regex in regression log parsing
13:50:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
13:50:43 <TrueBrain> frosch123: I now just always send c_str() .. should be fine
13:51:59 <frosch123> TrueBrain: depends on the version of the stdlib. 10 years ago it segfaulted, somewhen it started printing null
13:52:03 <frosch123> no idea what the standard says
13:52:27 <TrueBrain> I asked because we always print "text" when desync=1
13:52:53 <TrueBrain> so I guess all people using that use a stdlib that is supporting it :D
13:56:22 <TrueBrain> so someone in 2005 says glibc does it correct, but gcc doesn't
13:56:29 <TrueBrain> and someone in 2015 says glibc doesn't do this, but gcc does
13:56:36 <TrueBrain> call me confused :P
13:56:53 <frosch123> standard says, it must be a valid pointer
13:57:09 <frosch123> so, printing (null) is a non-standard extension :p
13:57:22 <frosch123> apparently the same exists for std::string_view
13:57:40 <frosch123> some accept nullptr, some crash on computing strlen(nullptr)
13:58:00 <TrueBrain> okay, I am sorry I asked :P
13:58:07 <TrueBrain> I wasted many human-cycles on this now :P
13:58:29 <TrueBrain> I love that these things are not just added to specs :P
13:58:30 <frosch123> you have to consider what we were doing instead before
13:58:42 <frosch123> maybe you inspired usefulness
13:58:55 <TrueBrain> well, before this I was triggering your OCD
14:00:04 <frosch123> yes, that PR is strong on the OCD level
14:00:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
14:00:37 <TrueBrain> I hope your OCD no longer triggers :) Otherwise, let me know :P
14:00:40 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZz1
14:00:53 <TrueBrain> funny, "? {} : a" is invalid syntax :)
14:00:53 <frosch123> it still triggers in one spot :)
14:01:55 <frosch123> you could remove the "text == nullptr ? std::string{} : text;", reinstall the StrEmpty in the "if", and only convert the text->std::String inside the if
14:02:09 <TrueBrain> in what variable? :)
14:02:24 <frosch123> first commit, line 312+313
14:02:27 <TrueBrain> well, that means splitting up the if too
14:02:34 <frosch123> now there is this weird, first check for nullptr, then check for empty
14:02:46 <TrueBrain> it can be non-null and empty :)
14:03:16 <frosch123> yes, but then the default constructor is good enough for command_text
14:03:29 <TrueBrain> but that does require splitting the if too :P
14:04:31 <frosch123> lol, now i noticed a real bug actually
14:04:34 <TrueBrain> is that really better? :)
14:04:58 <TrueBrain> I was about to say :D
14:06:09 <frosch123> no idea why it shows both versions no
14:06:15 <TrueBrain> yeah, but that is not doing the same
14:06:53 <TrueBrain> command_text is now empty if CMD_STR_CTRL is set
14:06:58 <TrueBrain> which is ... not what the intention is there :D
14:07:54 <frosch123> oh, i completely misremembered the meaning of CMD_STR_CTRL
14:08:04 <frosch123> i thought it meant "command has a string", but it doesn't :p
14:08:13 <TrueBrain> it is a really stupid name for a flag
14:08:17 *** Gustavo6046 has joined #openttd
14:08:24 <TrueBrain> okay, enough bikeshedding :D That was fun :)
14:08:34 <frosch123> good thing i approved already
14:08:40 <frosch123> noone remembers IRC :p
14:08:50 <TrueBrain> I could in theory remove the "!command_text.empty()" condition
14:08:56 <TrueBrain> as StrMakeValid works fine on an empty string
14:09:07 <TrueBrain> well, no, we are bikeshedding
14:10:18 <frosch123> see. the printf nullptr thing was more useful :)
14:10:37 <TrueBrain> well, I think StrMakeValid("") works .. but I want to confirm it first .. hmm
14:11:51 <TrueBrain> too bad godbolt doesn't magically have access to our code
14:12:42 <TrueBrain> I really have to look into that Layout crash .. it prevents me from running ctest locally
14:12:55 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain dismissed a review for pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZz1
14:12:55 <TrueBrain> there, that should help your OCD frosch123 :)
14:12:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
14:13:15 <TrueBrain> we are wasting some CPU cycles now
14:13:34 <frosch123> hmm, i remember gotbold could access github sources
14:13:50 <TrueBrain> I could add an empty() check in StrMakeValid
14:14:03 <TrueBrain> ugh, no, I am reverting that last change
14:14:55 <frosch123> probably fails when headers include headers with relative include paths, like we do
14:14:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
14:15:30 <TrueBrain> dismissed your review for nothing!
14:16:09 <frosch123> ahaha, i was just confused what changed, clicked the force-push link, and was even more confused :p
14:17:07 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZaX
14:17:19 <TrueBrain> talking about nullptr, I do remember that we had ALT+1 or something, that caused a (0x1) dereference :)
14:17:43 <frosch123> TrueBrain: no, it showed me the diff of readding the code, that i thought was there all the time
14:17:56 <TrueBrain> frosch123: ah, yes :D
14:18:32 <TrueBrain> does anyone ever use in 2021 alt+0 ? :P
14:18:39 <frosch123> i use alt+1 a lot. but i never used alt+0. i may have used "kill -6" somewhen
14:18:56 <glx> I used it when testing some mingw stuff
14:19:06 <TrueBrain> I didn't even use it in 2005
14:19:12 <glx> easy way to test crash log
14:19:22 <TrueBrain> "kill" does the same :)
14:19:35 <frosch123> since having two screens, i would also never think about using alt+tab :)
14:19:44 <frosch123> so no need for the shift-fast-forward
14:19:58 <TrueBrain> well, shift/alt-tab is a shitty thing to do anyway :P
14:20:01 <TrueBrain> how often I am confused
14:21:34 <TrueBrain> okay, it seems that sanitizer complains that on tear-down, not all memory is free'd
14:22:43 <glx> for the fun try setting [maintoolbar] fastforward in hotkeys.cfg, untoggle using the key is a pain ;)
14:24:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9308: Codechange: move casting a "const char *" to "char *" to the caller https://git.io/JGZlR
14:24:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
14:24:31 <glx> because autosave disables fast-forward temporarily
14:25:11 <TrueBrain> yeah, we need remappable sticky-keys :P
14:25:26 <TrueBrain> either way .. now some other fun: dinner :D
14:34:50 *** Progman has quit IRC (Remote host closed the connection)
14:35:21 *** tokai|noir has joined #openttd
14:35:21 *** ChanServ sets mode: +v tokai|noir
14:42:13 *** tokai has quit IRC (Ping timeout: 480 seconds)
14:56:07 <jez> i don't suppose anyone would feel like helping me getting the source for openttd 1.3.2 building correctly in VS 2010? i know it's old as hell but the patch i wanna apply doesn't work with newer versions of the codebase
14:56:33 <jez> i'm getting linking issues, starting with "zlibstat.lib(gzwrite.obj) : error LNK2005: _vsnprintf already defined in string.obj"
14:57:42 <glx> which patch are you applying ?
15:00:13 <glx> hmm clean 1.3.2 should build fine with VS2010
15:00:34 <Rubidium> wrong version of openttd-usefull maybe?
15:10:03 *** Wormnest has joined #openttd
15:13:37 *** Gustavo6046_ has joined #openttd
15:15:43 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
15:15:43 *** Gustavo6046_ is now known as Gustavo6046
15:20:23 <jez> ok, 5.0 fixes that error but i still get a bunch of unresolved externals
15:20:30 <jez> crashlog.obj : error LNK2019: unresolved external symbol _u_versionToString_55 referenced in function "protected: char * __thiscall CrashLog::LogLibraries(char *,char const *)const " (?LogLibraries@CrashLog@@IBEPADPADPBD@Z)
15:21:34 <glx> you may still have files built with non 5.0
15:21:56 <glx> and ICU "changes" function names at each new version
15:22:19 <glx> (happy we removed this dep in more recent openttd)
15:23:35 <glx> just checked icu 55 is from 6.0
15:25:38 <DorpsGek> [OpenTTD/OpenTTD] vituscze updated pull request #9280: Fix: Do not send vehicles towards incomplete PF nodes https://git.io/JsEBq
15:26:49 <DorpsGek> [OpenTTD/OpenTTD] vituscze commented on pull request #9280: Fix: Do not send vehicles towards incomplete PF nodes https://git.io/JGZyK
15:27:04 *** andythenorth has quit IRC (Quit: andythenorth)
15:27:48 <jez> yes, full rebuild gives me an exe :-) thanks
15:28:18 <glx> rule number one when changing libs, always full rebuild :)
15:29:15 <Rubidium> I remember spending days getting the libraries to build right, and then everything working afterwards
15:29:38 <glx> yeah it's so easy now with vcpkg
15:29:42 <jez> i did spend quite a while setting up the VM, installing DX 8.1, VS 2010, etc
15:30:20 <jez> shame clipboard never made it to trunk or i could be building latest ;-)
15:30:32 <glx> would maybe have been faster to manually apply the patch
15:32:44 <jez> once you've got the exe, how do you transfer it to a releasable format with language packs? just by hand?
15:33:09 <glx> there's a makefile for that I think
15:33:36 <Rubidium> and if you haven't set that up, then by hand might be much quicker
15:33:51 <jez> do i just need to copy the exe into an existing install?
15:34:07 <glx> you need exe and lang files
15:34:34 <jez> i have objs/langs but it doesnt have the right files
15:37:38 <glx> but compatibility scripts are
15:40:21 <jez> do i need media, man, or data folder?
15:42:25 *** sla_ro|master has joined #openttd
15:50:46 <jez> guess not, it works without them
15:51:49 <glx> to run you just need exe and matching lang files (and maybe grfs)
15:56:00 *** gelignite has joined #openttd
16:17:42 *** Mek has quit IRC (Remote host closed the connection)
16:38:39 *** ChanServ sets mode: +v tokai
16:41:20 *** Speeder has quit IRC (Ping timeout: 480 seconds)
16:45:40 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
16:47:53 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
16:58:47 *** Wormnest has quit IRC (Quit: Leaving)
17:00:38 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9280: Fix: Do not send vehicles towards incomplete PF nodes https://git.io/JGnJl
17:00:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9280: Fix: Do not send vehicles towards incomplete PF nodes https://git.io/JsEBq
17:07:23 *** Gustavo6046 has joined #openttd
17:09:32 *** andythenorth has joined #openttd
17:09:35 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9274: Fix f6d5c01: Delay deletion when closing windows https://git.io/JGnU2
17:20:20 *** andythenorth has quit IRC (Quit: andythenorth)
17:23:45 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:28:52 *** snail_UES_ has joined #openttd
17:37:43 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
17:38:36 *** andythenorth has joined #openttd
17:41:38 *** WormnestAndroid has joined #openttd
17:47:45 *** Progman has joined #openttd
17:58:23 *** J0anJosep has quit IRC (Quit: Konversation terminated!)
17:59:35 *** Gustavo6046 has joined #openttd
18:00:56 *** andythenorth has quit IRC (Quit: andythenorth)
18:07:10 *** Gustavo6046 has joined #openttd
18:16:58 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
18:18:21 *** andythenorth has joined #openttd
18:18:32 <andythenorth> goes it RV wagons?
18:30:23 <andythenorth> the harshest remedy
18:30:42 <andythenorth> it's just copy-paste from trains yes/no? :P
18:34:49 *** jottyfan has joined #openttd
18:38:14 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9273: Codechange: [Network] Use std::string for admin name and version https://git.io/Jscc1
18:43:01 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9310: Codechange: [Network] Use more std::string in server code https://git.io/JGnWP
18:47:36 *** Gustavo6046 has joined #openttd
18:54:21 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9310: Codechange: [Network] Use more std::string in server code https://git.io/JGnWP
18:58:53 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
18:58:55 <TrueBrain> stop giving me merge conflicts :P
18:59:06 <TrueBrain> my PR was first, that is not fair!! >:D
19:05:38 <TrueBrain> lol, a simple rebase now even fails
19:07:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use the setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
19:08:28 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #9274: Fix f6d5c01: Delay deletion when closing windows https://git.io/JsCsA
19:10:00 <glx> patch authors will hate us with all the recent changes
19:10:59 <TrueBrain> yeah, but at least we are all dumping it on one big pile :)
19:12:57 <TrueBrain> meh, git blame in settings.ini is annoying
19:13:03 <TrueBrain> at around 10 years you hit a brick wall :P
19:13:33 <glx> you need switch file at this time
19:13:48 <TrueBrain> and I can never figure out which file
19:13:53 <TrueBrain> as the commits around this one are not that clear about it
19:15:02 <frosch123> i think it was settings.h before that
19:15:52 <TrueBrain> and settings.cpp before that
19:15:57 <TrueBrain> but at least that is blame-wise foundable
19:17:55 <TrueBrain> finally found what I was looking for :P
19:18:52 <glx> yeah and reintroduced in noai and totally broken ;)
19:19:06 <frosch123> haha, for such things i look at old releases
19:19:19 <frosch123> the exact revision is not important there
19:28:13 <TrueBrain> so happy the intro screen is lovely old :)
19:31:27 <frosch123> TrueBrain: pretty sure the majority of savegame conversion could be deleted, if we dropped support for savegames > 10 years :p
19:31:35 <TrueBrain> frosch123: haha, yes :)
19:31:45 <TrueBrain> well, the other day someone was complaining this TTDp savegame wasn't loading correctly
19:32:08 <frosch123> that's usually because of newgrf
19:32:17 <TrueBrain> frosch123: I honestly did consider adding something like: this savegame is over N years old; please download version M to load and save it, before you can load it in this version
19:32:31 <frosch123> there was a time when newgrf were not stored in savegames, you had to activate the exact ones before loading the game
19:32:49 <TrueBrain> I was referring to the fact someone had a TTDp savegame
19:32:53 <TrueBrain> not that he could or couldn't load it :P
19:33:15 <frosch123> fair, usually they want original ttd savegames, not ttdp
19:33:38 <TrueBrain> I do wonder if we do add something like I described above .. how often that would be a problem
19:34:08 <frosch123> it would destroy all my test games, because i did not create any new ones in the past 10 years :p
19:34:17 <frosch123> players won't notice
19:34:32 <TrueBrain> it would remove a lot of technical depth from the saveload stuff
19:34:36 <frosch123> and considering the catchment area change, most interesting games are broken anyway :p
19:34:53 <andythenorth> don't we guarantee savegames forever?
19:34:57 <andythenorth> or is that a myth?
19:36:06 <frosch123> ottd could upload old savegames to a server, which pipes it through a chain of stable releases, and transfers back the upgraded version :p
19:36:13 <andythenorth> TrueBrain even with revision history :P
19:36:17 <TrueBrain> haha, nice idea frosch123 :D
19:37:15 <frosch123> would only support newgrf from bananas ofc
19:39:08 <frosch123> when the self-describing savegame format came up yesterday, i wondered whether we could upgrade all scenarios on bananas, so that bananas could extract more metadata
19:39:24 <TrueBrain> yesterday? Wait, did I miss a full day somewhere?
19:39:47 <frosch123> does "repackaging" include "load savegame and store with newer version"? :p
19:40:07 <frosch123> TrueBrain: hmm, true, yesterday i weren't on irc
19:40:19 <TrueBrain> yeah, it was a few hours ago :P
19:40:23 <TrueBrain> you are getting old my friend :)
19:40:26 <frosch123> it was before lunch :p
19:40:58 <LordAro> i wouldn't say it's a great deal of effort to support old savegames
19:40:59 <frosch123> TrueBrain: the old effect would work the other way around
19:41:09 <frosch123> i would use "yesterday" for things from 10 years ago
19:41:24 <TrueBrain> LordAro: I strongly disagree .. given I am already over an hour neckdeep in some shitty "old_diff" shit :P
19:41:47 <LordAro> that's just shitty code :p
19:42:00 <TrueBrain> imagine we can remove it!
19:42:04 <TrueBrain> just picture it ...
19:42:10 <TrueBrain> those 10 surviving savegames won't load
19:43:01 *** jottyfan has quit IRC (Quit: jottyfan)
19:43:01 <TrueBrain> any of you happen to have a savegame between 97 and 110? :)
19:43:10 *** jottyfan has joined #openttd
19:44:45 <frosch123> likely, i was playing the game at that time
19:45:59 <frosch123> revision 14xxx fits your criteria
19:46:27 <glx> I have very old saves, but probably older than version 97
19:46:44 <frosch123> and yes, noone renewed the ssl certificate
19:47:10 <frosch123> if only letsencrypt could be automated
19:47:24 <TrueBrain> frosch123: meh, all need GRFs
19:47:24 <glx> oh march 2009, could be ok, just need to check them
19:47:36 <frosch123> TrueBrain: they link where you can get them
19:47:53 <TrueBrain> yeah .. I am willing to test stuff, but this is too much effort :P :P
19:49:50 <frosch123> also mind that the collection of all pre-bananas grf is 20MB (compressed) :p
19:51:10 <TrueBrain> I am looking at this old code, somewhat realising it can never work
19:53:29 <frosch123> they were other settings chunks before the current one
19:53:51 <TrueBrain> this converts the old "diff_custom" to the new system
19:54:00 <TrueBrain> in v4 the town_council_tolerance was added
19:54:07 <TrueBrain> in v97 the new system was added
19:54:19 <TrueBrain> but ... I wonder if this code ever converts town_council_tolerance
19:54:39 <TrueBrain> (between v4 and v97)
19:55:12 <TrueBrain> I think the "from" should be 0
19:56:13 <frosch123> ah, so it was broken later
19:56:23 <TrueBrain> I think this broke it
19:56:35 <glx> checked my saves, minimal is 113
19:56:46 <TrueBrain> glx: awhh .. well, tnx anyway :D
19:58:51 <TrueBrain> how ever I look at it, that line of code makes no sense .. all of a sudden pre-v97 savegames are not being loaded correctly, I would think .. I should verify that ..
19:58:56 <TrueBrain> lets find an even older savegame :D
20:01:24 <frosch123> coop archive starts at savegame version 18
20:07:12 <TrueBrain> in newer games I still see the old_diff_custom used
20:07:19 <TrueBrain> guess it got never removed
20:08:12 <TrueBrain> sometimes I just do not understand why things work :D
20:09:06 <Rubidium> what do you mean by used? Things being written to them?
20:09:49 <Rubidium> or it still attempting to use it in configuration file loading
20:09:50 <TrueBrain> okay, abuot the link I sent earlier, SlIsObjectCurrentlyValid() does something different then I expected
20:10:03 <TrueBrain> it checks against the current version the client supports
20:10:05 <TrueBrain> not the savegame itself
20:10:08 <TrueBrain> that was a curve-ball :D
20:10:28 <TrueBrain> Rubidium: I have savegames well beyond v97 that have diff_custom set
20:10:32 <TrueBrain> (as in: non-zero values)
20:10:38 <TrueBrain> which is not what I expected
20:13:30 <TrueBrain> right, no, nevermind
20:13:46 <Rubidium> also, when there is no OPTS chunk the values of the previous load will remain in there
20:15:39 <Rubidium> well, what will set (or clear) _old_diff_custom when there is no OPTS chunk?
20:15:47 <TrueBrain> ah, I was just being piss-poor at picking savegames :D Okay, this makes a bit more sense ..
20:17:04 <Rubidium> which is called from... Load_OPTS and when loading from the configuration file I just linked
20:19:50 <TrueBrain> grr, so I downloaded the 8.0 pack, extracted it .. it finds most of the grfs, but not all :P
20:19:59 <TrueBrain> what am I doing wrong .. hmmm
20:20:49 <TrueBrain> having a zip-file in the folder
20:20:52 <TrueBrain> breaks newgrf scanner or something
20:20:56 <TrueBrain> it scanned a few files, not all :P
20:23:10 <TrueBrain> still it fails to find a few .. ugh, why does this frustrate me so often :D
20:23:51 <TrueBrain> frosch123: is it possible 8.0 pack is not compatible with 7.2 games?
20:24:59 <frosch123> i thought 8.0 is the same as 7.2, just everything removed which is also on bananas
20:25:24 <TrueBrain> still possible I am doing stuff wrong :P
20:25:31 <TrueBrain> BK Tunnel Set v0.3a
20:25:36 <TrueBrain> lets see if I have it on file or whatever ..
20:25:54 <TrueBrain> it is in my NewGRF list
20:25:59 <TrueBrain> but when I try to load the file, it says it is missing
20:26:14 <frosch123> enable newgrf dev tools in console, and load it anyway
20:26:19 <frosch123> tunnel graphics are not important
20:26:41 <TrueBrain> missing two other NewGRFs
20:26:51 <TrueBrain> stolentrees and 2ccdj
20:27:08 <TrueBrain> now I remember why I didn't want to do this :P
20:27:12 <TrueBrain> fuck my need to test :(
20:27:52 <frosch123> ok, 2ccdj is important :)
20:28:01 <TrueBrain> yeah, it crashes and burns when I just continue :P
20:28:10 <frosch123> it's probably some nightly release then, otherwise it would have been on bananas
20:28:45 <frosch123> just who knows which version :p
20:29:51 <TrueBrain> none of those md5s is what is missing :)
20:31:43 <TrueBrain> well, that is not the right version :D
20:35:58 <TrueBrain> tried a bunch of different version I could find on the web
20:38:44 <TrueBrain> still crashes, darn it :D
20:39:01 *** andythenorth_ has joined #openttd
20:39:09 <TrueBrain> might be fully unrelated, the crash, ofc
20:39:13 <frosch123> who knows, maybe it's broken savegame converison :)
20:39:21 <frosch123> try an older release
20:39:26 <TrueBrain> somewhere in the pool it breaks
20:39:40 <TrueBrain> but, 2ccdj.grf is still not the right checksum
20:39:46 <TrueBrain> so that might also be the problem
20:40:02 *** andythen_ has joined #openttd
20:40:16 <TrueBrain> its funny how much you can find on the web if you really search btw :P
20:41:08 <TrueBrain> ha, found the right one
20:41:34 <TrueBrain> now I just need to test a pre-v4 one
20:41:44 <TrueBrain> where to find that ..
20:41:50 <frosch123> now we need to get you to 2k installed newgrf, so you optimise the newgrf scanning :)
20:42:10 <TrueBrain> I already "optimized" it
20:42:15 <TrueBrain> as I was loading ProZone games for testing :P
20:42:21 <TrueBrain> I am still waiting till you add sqlite
20:42:27 <frosch123> pre-v4, try the titlegame from old releases?
20:42:49 <TrueBrain> the oldest I could find was v4 .. hmm .. lets see if I can find an older
20:42:58 <frosch123> try ottd 0.3 titlegame
20:43:47 *** andythe__ has joined #openttd
20:43:50 <frosch123> v4 is r1 of new svn :)
20:44:10 <TrueBrain> can't find a titlegame in 0.3 .. hmm
20:44:54 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
20:45:43 <frosch123> hmm, so there was none? still original ttd title?
20:46:07 <TrueBrain> dunno .. empty map?
20:46:11 <Wolf01> Aren't scenarios from original TTD compatible? Older than those ones I doubt that exists anything
20:46:32 <TrueBrain> 0.4.0.1 is already v4
20:47:04 *** andythenorth_ has quit IRC (Ping timeout: 480 seconds)
20:48:06 *** andythen_ has quit IRC (Ping timeout: 480 seconds)
20:49:00 <TrueBrain> and 0.3.2 has none, from what I can find
20:49:06 <frosch123> 0.2.1-sources.tzip has a opntitle.dat
20:49:40 <TrueBrain> okay, works as expected
20:51:43 <frosch123> pff, that titlegame is very minimal :p
20:52:00 <TrueBrain> I did not even check what it was :D
20:52:10 <frosch123> the regular rail just ends in the middle of the screen
20:52:10 <TrueBrain> busy with all kinds of stuff
20:52:17 <TrueBrain> meant for 640x480 :P
20:52:36 <frosch123> yes, but that part is within the visible area
20:53:08 <frosch123> lol, flying road vehicles
20:53:23 <frosch123> something is completely broken there
20:54:03 <frosch123> it's the train smoke
20:54:03 <TrueBrain> their type also changes :)
20:54:13 <frosch123> the sprite animation starts with smoke sprites
20:54:22 <frosch123> but it never stops and just continues looping through all sprties
20:54:35 <TrueBrain> well, enjoy your rabbit hole :P
20:54:38 <frosch123> at the start of the savegame it's still smoke
20:54:47 <frosch123> LordAro claimed that savegame conversion works :)
20:56:12 *** FLHerne has quit IRC (autokilled: Spam. Don't mail support@oftc.net with questions. (2021-05-29 20:56:12))
20:58:48 <frosch123> aw, now it reached questionmarks
20:59:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
20:59:45 <frosch123> well, it leaves the scrollable map while it shows the signal sprites from the extra grf
21:00:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9311: Codechange: use setting name instead of index for HandleOldDiffCustom() https://git.io/JGnPe
21:00:49 <TrueBrain> right .... one more "index" based setting-access to go
21:00:55 *** FLHerne has joined #openttd
21:00:59 <TrueBrain> but this one was the big one ..
21:01:08 <TrueBrain> _settings[0..18] were very important :P
21:01:50 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:02:10 *** WormnestAndroid has joined #openttd
21:02:25 <TrueBrain> in the future I plan to put those in their own _settings variable
21:02:33 <TrueBrain> so we don't need the weird string-list
21:02:36 <TrueBrain> but ... baby-steps :)
21:08:41 <TrueBrain> hmm .. so in Linux I do not have to include <array>
21:08:45 <TrueBrain> but on all other targets I do :P
21:09:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9311: Codechange: use setting name instead of index for HandleOldDiffCustom() https://git.io/JGnPe
21:11:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9312: Codechange: add a wrapper function to find all settings based on prefix https://git.io/JGnXk
21:12:13 <TrueBrain> funny .. if I ALT+F4 a window close on Windows, and Element is the next focused window, it asks me if I want to exit the application
21:12:21 <TrueBrain> that .. shouldn't really happen, I would guess :)
21:16:09 *** jottyfan has quit IRC (Quit: jottyfan)
21:16:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9306: Codechange: use setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
21:16:35 <TrueBrain> right .. that carved out settings.ini sufficiently, I hope :)
21:16:39 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:18:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:19:14 <TrueBrain> glx: the annotation fail thing is fantastic :D
21:20:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9311: Codechange: use setting name instead of index for HandleOldDiffCustom() https://git.io/JGnPe
21:20:52 *** Samu has quit IRC (Quit: Leaving)
21:21:56 *** WormnestAndroid has joined #openttd
21:23:44 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9306: Codechange: use setting name instead of index for CmdChange(Company)Setting https://git.io/JGn1A
21:24:52 <andythe__> opening the console causes different sprites to be drawn in game
21:25:03 <andythe__> that's quite funny to see
21:25:22 <TrueBrain> picture or it didn't happen :P
21:27:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9306: Codechange: use setting name instead of index for CmdChange(Company)Setting https://git.io/JGZII
21:27:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9311: Codechange: use setting name instead of index for HandleOldDiffCustom() https://git.io/JGnPe
21:27:34 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9312: Codechange: add a wrapper function to find all settings based on prefix https://git.io/JGnXk
21:27:59 <andythe__> look at the ship on the right
21:28:15 <andythe__> (there is more than 1 ship loading at that dock)
21:28:23 <andythe__> which is why the sprites change
21:33:21 <andythe__> it's quite funny toggling it
21:34:30 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:34:57 *** WormnestAndroid has joined #openttd
21:35:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9273: Codechange: [Network] Use std::string for admin name and version https://git.io/JGnyV
21:35:30 <frosch123> TrueBrain: you sent me down a weird rabbit hole
21:40:10 <TrueBrain> frosch123: where did you end up? :D
21:40:30 <Rubidium> in the green hills near Ewijk?
21:41:22 <frosch123> but ottd counts them without gaps
21:41:31 <frosch123> our ttdp savegame loader actually does the shift
21:41:38 <frosch123> so no idea where that 0.2.1 titlegame comes from
21:41:55 <frosch123> and even more confusing, ottd 0.1 does not have gaps either
21:42:10 <TrueBrain> okay, you ended up in a weird rabbit hole indeed :P
21:42:49 <frosch123> so, either (1) ludde changed the effect vehicles before ottd 0.1 (2) ttdp made them different to ttd and the ottd 0.2.1 titlegame was created with ttdp
21:42:57 <frosch123> both options appear unlikely to me :p
21:43:48 <frosch123> hmm, though ottd 0.1 also already has the ottd savegame format and lzo compression
21:44:09 <frosch123> so, i guess (1) is true. i just thought ottd 0.1 was much closer to ttd
21:44:27 <frosch123> but this means the savegame is from ttd, and the bug is older than ottd 0.1 :p
21:44:49 <frosch123> tough the savegame was resaved with ottd
21:44:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9307: Fix: artificially limit heightmap sizes to something reasonable https://git.io/JGnSu
21:45:37 <TrueBrain> now the question .. is it worth fixing? :P
21:45:54 <TrueBrain> okay, super weird .. ctest works locally, crashes on CI
21:45:57 <frosch123> ha, solved it by starting dosbox
21:46:12 <frosch123> it's actually the original ttd titlegame, but resaved with ottd
21:46:27 <frosch123> and that conversion was wrong for the effect vehicles
21:46:49 <frosch123> and the solution to the "rail ends in the middle of screen" is "that's where the intro gui is"
21:47:16 <frosch123> the track just ends behind the intro gui, and the train reverses hidden by the gui
21:47:27 <frosch123> pretty sure i read about that years ago on the forums, but forgot it again
21:48:02 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:48:59 <frosch123> because it was resaved with a version before the fix
21:49:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9310: Codechange: [Network] Use more std::string in server code https://git.io/JGn9L
21:50:28 <TrueBrain> well, clear conclusion ;)
21:51:50 <frosch123> shit.. devzone just sent me 50 mails
21:52:39 <TrueBrain> and I cannot believe you figured out what was going on with the smoke .. lol
21:52:58 <frosch123> it just send me notifications that people signed up. mails are dated from the past 48 hours
21:53:09 *** andythe__ has quit IRC (Quit: andythe__)
21:53:11 <TrueBrain> people really want to join devzone!
21:53:27 <frosch123> i would think devzone is so unmainained and broken, that spambots exploit some old known vulnerabilites of redmine
21:53:46 <frosch123> planetmaker: it may be time to shut it down, or set it readonly or something
21:56:08 <frosch123> ah, no there are more futher down. first one is from tuesday
21:56:24 <frosch123> will it now sent me a mail for every spambot who tried to sign up in the past 10 years?
21:56:37 <TrueBrain> 1: + ==26823==ERROR: ThreadSanitizer: allocator is out of memory trying to allocate 0x31223f400 bytes'
21:56:43 <TrueBrain> I broke something real good
21:58:13 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9307: Fix: artificially limit heightmap sizes to something reasonable https://git.io/JGn9Q
22:01:03 <frosch123> it will probably sent me 1000 mails till tomorrow :p
22:01:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9310: Codechange: [Network] Use more std::string in server code https://git.io/JGnHq
22:01:53 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9310: Codechange: [Network] Use more std::string in server code https://git.io/JGnWP
22:05:14 <frosch123> well, pretty sure pm gets those mails as well
22:07:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9307: Fix: artificially limit heightmap sizes to something reasonable https://git.io/JGnQe
22:12:50 *** sla_ro|master has quit IRC ()
22:16:52 <TrueBrain> of, thread issues with RandomNext
22:18:22 <frosch123> what? who calls random() in a thread?
22:25:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9307: Fix: artificially limit heightmap sizes to something reasonable https://git.io/JGn7N
22:26:26 <TrueBrain> dunno, walked away from the rabbit hole :D
22:27:39 <frosch123> 2-3 mails per minute
22:27:56 *** Wormnest has joined #openttd
22:27:57 <frosch123> so that's how many i will wake up to :p
22:28:21 <TrueBrain> that is not "too bad" :P
22:33:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9307: Fix: artificially limit heightmap sizes to something reasonable https://git.io/JGndS
22:39:02 <TrueBrain> so I spend 30 minutes looking at a bug caused by a missing & :P
22:42:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9312: Codechange: add a wrapper function to find all settings based on prefix https://git.io/JGnXk
22:42:05 <TrueBrain> NOW YOU BETTER WORK >:D
22:49:20 <TrueBrain> btw, frosch123 , why didn't you check your DHCP settings to calculate that value?
22:50:35 <frosch123> i thought about it, but i did not wanted to make that joke
22:50:52 * Rubidium wonders whether that person knows the meaning of 608400
22:50:54 <TrueBrain> it still cracks me up, that someone is gatekeeping numbers :)
22:51:28 <frosch123> Rubidium: sounds like a rotated version of 84600
22:53:02 <Rubidium> that's a coincidence
22:53:53 <frosch123> oh, my dhcp settings were wrong. it's actually 86400
22:55:33 <frosch123> i found a meaning for 604800
22:55:40 <frosch123> did you also swap digits?
22:56:37 <Rubidium> well, your variant is for the normal kind of that... mine is for the one around the last Sunday of October in most of Europe
22:57:37 <frosch123> anyway, looks like it caugtht up with history, now it only sends one mail per 30 minutes
22:58:26 <Rubidium> ... and that's why we use 1w instead of messing about with seconds manually ;)
22:59:13 <TrueBrain> or you know, just not gatekeep numbers :P
22:59:18 <TrueBrain> (not referring to you, to be clear)
23:00:04 <frosch123> hmm, i once had a microcontroller with some weird os. it's date api returned weekdays in the range 0 to 7 :p
23:01:17 <Rubidium> frosch123: what about a system that give you the date in local time and the number of seconds since last Sunday midnight UTC
23:01:47 <frosch123> oh, i explored the option of a pure week based calendar
23:02:00 <frosch123> it needed a leap week every few years
23:02:13 <frosch123> but the pattern was pretty weird
23:02:30 <frosch123> then i noticed that isoweeks are basically the same thing
23:03:04 <Rubidium> yeah, isoweek also needs isoyear
23:07:06 *** luaduck has quit IRC (Ping timeout: 480 seconds)
23:08:04 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
23:25:11 *** tokai|noir has joined #openttd
23:25:11 *** ChanServ sets mode: +v tokai|noir
23:31:56 *** tokai has quit IRC (Ping timeout: 480 seconds)
23:45:39 *** Progman has quit IRC (Remote host closed the connection)
continue to next day ⏵