IRC logs for #openttd on OFTC at 2023-03-06
            
00:01:44 *** Wormnest has joined #openttd
00:54:28 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:07:12 *** Soni has quit IRC (Ping timeout: 480 seconds)
01:08:07 *** bryjen has joined #openttd
01:31:55 *** Wormnest has joined #openttd
01:39:05 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:44:14 *** WormnestAndroid has joined #openttd
02:23:55 *** Soni has joined #openttd
02:44:42 *** Wormnest has quit IRC (Quit: Leaving)
03:27:37 *** D-HUND has joined #openttd
03:30:59 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:07:44 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10529: Add precondition checks for deity/company mode https://github.com/OpenTTD/OpenTTD/pull/10529
04:07:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10536: Change: simplify/unify company mode scope checks https://github.com/OpenTTD/OpenTTD/pull/10536
04:07:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10532: Fix: deity should see all signs, AIs should not see signs of deity https://github.com/OpenTTD/OpenTTD/pull/10532
04:17:39 *** TROILUS has quit IRC (Read error: Connection reset by peer)
04:24:33 *** felix has quit IRC ()
04:24:46 *** felix has joined #openttd
04:27:47 *** bryjen has quit IRC (Quit: Leaving)
04:41:29 *** keikoz has joined #openttd
05:47:15 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:49:26 *** WormnestAndroid has joined #openttd
05:58:39 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:10:31 *** Flygon has joined #openttd
06:21:49 *** nielsm has joined #openttd
06:22:53 *** sla_ro|master has joined #openttd
06:36:57 *** nielsm has quit IRC (Ping timeout: 480 seconds)
07:38:22 <pickpacket> I can't quite follow what happens here: https://github.com/OpenTTD/OpenTTD/tree/master/src#L3465 lines 3465 to 3469. With the bitshift of the m variable. What would that typically result in?
07:40:55 <pickpacket> How high can the _settings_game.economy.town_growth_rate go?
07:45:40 <Rubidium> you missed a file name in your URL, but https://github.com/OpenTTD/OpenTTD/blob/59645c67335447e03721a67ebb3de083947dbb81/src/table/settings/economy_settings.ini#L209-L219 should be able to answer your second question
07:54:39 <pickpacket> uh... I have no idea how that filename disappeared XD https://github.com/OpenTTD/OpenTTD/blob/master/src/town_cmd.cpp#L3465
08:42:20 <pickpacket> it looks un-intuitive to me that a lower growth rate number translates to a higher growth rate in the game
08:47:35 *** Wolf01 has joined #openttd
09:37:26 <Rubidium> pickpacket: I think the documentation of that function is just plain wrong. It returns the number of game ticks before trying to grow again
09:39:29 <pickpacket> That could just be a question of semantics :) High growth rate <=> few game ticks
09:44:43 <Rubidium> That's like saying it returns the speed, but then returns the number of seconds it needs to go a distance. Yes, practically the same data. But reading the comment I expect something in meter/second, not seconds/meter (or whatever time and distance units you want to use)
09:45:00 <pickpacket> true
10:10:52 <dP> iirc "growth rate" = ticks between grow attepmpts - 1
10:14:12 <andythenorth> wonder if this applies for our fork of Squirrel 2 in our context, rather than Electric Imp's fork of Squirrel 3 😛 https://developer.electricimp.com/resources/efficientsquirrel#choose-between-classes-and-tables
10:16:43 <andythenorth> performance optimising is important, but it's possibly clown shoes to take tips from one situation and apply them to another 😛
10:17:01 <andythenorth> I guess I could try both and profile RAM use
10:38:52 <Rubidium> dP: regardless, if it's ticks between attempts then "growth rate" is just a bad name. It's like saying the top speed of two vehicles are 40 and 20. You would assume the first is the fastest, but it isn't because I used seconds per kilometer as unit. It would have been better to call it secondsPerKilometer, similarly that growth rate should be called secondsBetweenGrowAttempts where applicable
10:39:58 <Rubidium> I think self explaining function and variable names would have helped pickpacket a lot in his struggles to understand that town growth rate function
10:40:20 <dP> Rubidium: well, yeah, but I don't see a good name for `ticks - 1`. Also, considering game works with integers it's not that weird to store rate as inverse
10:51:34 <dP> speaking of vehicles... 🤣 <https://github.com/OpenTTD/OpenTTD/blob/master/src/train_cmd.cpp#L3953>
10:58:46 <Xarick> hi
11:04:40 <andythenorth> town growth rate moved to GS when? 😛
11:05:04 <andythenorth> someone had the idea of modular game logic in the default client 😛
11:05:14 <andythenorth> imagine the wiki documentation problems 😄
11:10:02 <dP> andythenorth: like a decade ago? :p
11:19:35 <Xarick> question. I have a `std::set<uint32> vehicle_list; ///< List of vehicle indexes` and i insert vehicles with `vehicle_list.insert(v->index);`. what is the code to see if a vehicle is already in vehicle_list?
11:23:02 <dP> Xarick: <https://cplusplus.com/reference/set/set/find/>
11:28:08 <Xarick> `stats_all.vehicle_list.find(v->index)` doesn't work 😦
11:31:34 <Xarick> ah, got it!
11:31:42 <Xarick> `assert(stats_all.vehicle_list.find(v->index) != stats_all.vehicle_list.end());`
11:44:19 <petern> Why uint32 instead of VehicleID?
11:46:08 <Xarick> oh, i forgot about that
11:47:55 <Xarick> I'm trying to find ways to make script lists faster
11:47:59 <Xarick> less cpu intensive
11:48:08 <glx[d]> Why checking if it's already in it ?
11:49:10 <Xarick> because if it's already in, and i'm about to insert it, I failed somewhere
11:49:18 <Xarick> same with removal
11:51:20 <glx[d]> I though about something regarding Valuate and CPU usage error, I think it may depend on when the call is done during the current tick
11:51:51 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #8480: Feature: Extended depots https://github.com/OpenTTD/OpenTTD/pull/8480
11:52:32 <glx[d]> And of course on how many Valuate calls are made during the tick
11:53:00 <Xarick> got an assert just now 😦
11:53:21 <glx[d]> Sleeping before valuating could help a lot I guess
11:55:44 <Xarick> problem I am having with Slow Valuator is that the game state changes 😦
11:55:51 <Xarick> during evaluation
11:56:48 <Xarick> got clueless clus crashing because it was iterating vehicles and a vehicle id poofs
11:57:13 <Xarick> it tried to get the name of the vehicle which was valid at the time it started valuating
12:00:18 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:00:48 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082271563241492520/image.png
12:02:05 <Xarick> caused by
12:02:51 <Xarick> <https://github.com/OpenTTD/OpenTTD/blob/master/src/train_cmd.cpp#L1287>
12:03:26 <petern> Why would its own vehicles disappear?
12:04:28 <petern> Crashed and then removed, I suppose. Not sure if autoreplace reuses the same ID, I think it does though.
12:05:14 <Xarick> it doesn't
12:09:53 <petern> Anyway, surely it's still possible for a vehicle to disappear, just less likely.
12:10:37 <petern> You could valuate and get a result, get suspended, and then your result is not valid.
12:13:27 <Xarick> a wagon is being counted as a vehicle
12:13:30 <Xarick> 😦
12:13:41 <Xarick> that's why it asserts
12:14:25 <Xarick> it tries to check if the vehicle is in the list before it removes it, and doesn't find it, because wagons aren't counted as vehicles
12:14:40 <Xarick> but it wants to remove the wagon
12:14:47 <Xarick> stoopid game
12:14:59 <Xarick> 🙂
12:20:24 <Xarick> /* There are 14 different cases:
12:20:29 <Xarick> 😐
12:23:46 <Xarick> this sounds bugged, unless it fixes itself at the end of CmdMoveRailVehicle
12:24:44 <Xarick> num_vehicles becomes 65535
12:24:51 <Xarick> 0 - 1 = 65535
12:25:09 <Xarick> but there's no assert for that
12:25:14 <Xarick> so the game just runs
12:29:02 <Xarick> I see, it fixes itself later on at line 1339
12:29:08 <Xarick> 65535 + 1 = 0
12:29:12 <Xarick> magic!
13:30:38 *** keikoz has joined #openttd
13:40:41 <DorpsGek> [OpenTTD/team] SharkyFlou opened issue #408: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/408
13:41:32 <DorpsGek> [OpenTTD/team] SharkyFlou commented on issue #408: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/408
13:55:21 <DorpsGek> [OpenTTD/team] glx22 commented on issue #408: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/408
13:58:27 <glx[d]> Xarick: which is the better AI to use to easily trigger the cpu limit in valuate ?
13:59:27 <Xarick> fastPTPAI
13:59:49 <Xarick> TracAI
13:59:56 <Xarick> AIAI with airports
14:00:03 <Xarick> MailAI
14:00:45 <glx[d]> using a normal map size ?
14:01:05 <Xarick> FastPTPAI then
14:12:28 <Xarick> i should create a topic in the forum with a list of ais with cpu evaluator issue
14:12:37 <Xarick> keep them all in one place
14:17:03 <Xarick> start the map with large towns
14:17:08 <Xarick> easier to trigger
14:34:28 <glx[d]> oh I see, it uses valuate inside valuate
14:39:19 <Xarick> just discovered that companies have a group_all for each vehicle type
14:39:47 <Xarick> if we add a list of vehicles for these groups
14:39:58 <Xarick> then we won't have to iterate over the entire vehicle pool
14:40:10 <Xarick> when creating lists
14:40:49 <Xarick> in theory it should lighten up AIs
14:40:56 <Xarick> that make use of vehicle lists
15:00:16 *** sla_ro|master has quit IRC ()
15:06:12 <petern> How do you think group_all works...
15:18:08 <Xarick> wow
15:18:16 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082321258324168794/image.png
15:18:42 <Xarick> i expected a speed up, but not this much!
15:19:46 <Xarick> this is what I'm doing <https://gist.github.com/SamuXarick/af45e73a27fc83ca32354aec05e4f884>
15:20:00 <Xarick> creating a list of vehicles in a group
15:20:08 <Xarick> i mean, in all groups
15:21:57 <Xarick> updated gist
15:22:06 <Xarick> with what it's doing in c++
15:27:02 <glx[d]> https://gist.github.com/glx22/6d91643fd631ed46c3ee75ea326c641d <-- that is a single Valuate() call
15:30:17 <glx[d]> let's add more print to know where each item valuation starts
15:32:39 *** nielsm has joined #openttd
15:37:50 <glx[d]> gist updated
15:40:46 <Xarick> 625 items
15:40:57 <Xarick> with 4 valuators nested?
15:43:31 <glx[d]> yup
15:44:52 <glx[d]> and many useless valuations as it could return earlier
15:45:32 <glx[d]> and I did all this logging in the script itself
15:49:36 <Xarick> do you mean scripts can stop valuating themselves?
15:49:43 <Xarick> if they're approaching the limit?
15:52:20 <Xarick> nearly no AI use ScriptVehicleList_DefaultGroup
15:53:11 <Xarick> only SimpleAI and derivates, ShipAI, HeliFerry
15:53:15 <Xarick> WormAi
15:55:18 <glx[d]> <https://gist.github.com/glx22/4a6562ae136f2731474463c7fa2929a2> <-- this is the valuator
15:55:54 <glx[d]> in many cases there's no items left in the list before calling the next Valuate()
15:57:11 <glx[d]> so it returns on line 17, but wasted opcodes before reaching the line
16:00:23 <Xarick> I see
16:02:21 <Xarick> the author himself could optimize his code better, but still...
16:03:19 <Xarick> valuating over 0 items shouldn't be that expensive
16:06:10 <glx[d]> funny if I add early returns, it still fails, but sooner (based on tick number)
16:08:18 <glx[d]> <https://gist.github.com/glx22/8928aa8e6fa97da23f79d19040a0d457>
16:10:54 <Rubidium> the code doesn't look like valuate over something empty costs a lot; at least valuate takes 5 ops per element, for the rest nothing besides what you would get for a normal API call
16:11:32 *** WormnestAndroid has joined #openttd
16:13:01 <glx[d]> yeah that's not the most expensive part, and my changes to log stuff also eats some ops
16:18:40 <glx[d]> 696 ops per valuation doesn't seem that big
16:19:32 <glx[d]> seems fine for about 1400 items
16:21:23 <glx[d]> but 696 is only for the original early return (with 0 items valuate)
16:23:02 <glx[d]> some cases use 3005 ops
16:23:31 <Xarick> i'm getting some error
16:23:38 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
16:24:09 <glx[d]> which lowers the number of possible items to 333 if they all use this amount
16:25:36 <glx[d]> 625 items are allowed an average of 1600 ops
16:27:14 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082338612022100088/image.png
16:27:14 <Xarick> https://gist.github.com/SamuXarick/d2f46bcf3fd6f95597d4eb0abee3f527
16:27:42 <Xarick> crashing because free on something I don't care about
16:27:48 <Xarick> what can I do?
16:32:05 <glx[d]> first use GroupStatistics::Get(), then store a reference
16:34:03 <glx[d]> the issue is `GroupStatistics stats = ...` you are creating an object, you should use `GroupStatistics &stats = ...`
16:42:33 <Rubidium> that also crashes in deity mode
16:49:54 *** sla_ro|master has joined #openttd
17:00:57 *** Wormnest has joined #openttd
17:03:28 <Xarick> ah, thanks
17:05:52 <Xarick> `if (!Company::IsValidID(ScriptCompany::GetCompany())) return;`
17:08:26 *** WormnestAndroid has joined #openttd
17:10:21 *** HerzogDeXtEr has joined #openttd
17:11:55 <Xarick> for some weird reason, this one is slow 😦
17:16:19 <Xarick> AddItem itself is slow
17:16:24 <Xarick> wow
17:16:33 <glx[d]> yes because it sorts on each add
17:17:01 <Xarick> unacceptably slow
17:17:45 <glx[d]> but old version also used AddItem
17:18:02 <Xarick> it's slow on both versions because of AddItem this time :p
17:19:08 <glx[d]> debug build ?
17:19:14 <Xarick> no, release build
17:20:13 <Xarick> can't even take a proper screnshot
17:23:18 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082352723468505098/image.png
17:23:31 *** tokai|noir has joined #openttd
17:23:31 *** ChanServ sets mode: +v tokai|noir
17:23:50 <glx[d]> weird
17:24:52 <Xarick> 250K OPcodes
17:25:37 <Xarick> while (true) {
17:25:37 <Xarick> foreach (type, _ in [0, 1, 2, 3]) {
17:25:37 <Xarick> local list = AIVehicleList_DefaultGroup(type);
17:25:37 <Xarick> }
17:25:37 <Xarick> }
17:26:08 <glx[d]> of course that's slow
17:26:38 <Xarick> there's many vehicles, about 2700 * 14
17:27:14 <glx[d]> but you are creating and destroying list cintinuously
17:27:48 <Xarick> well, I was testing speed
17:27:56 <Xarick> apparently my tests are flawed
17:29:22 <glx[d]> at least put a sleep in the while loop
17:30:29 *** tokai has quit IRC (Ping timeout: 480 seconds)
17:30:37 <Xarick> ok
17:31:03 <glx[d]> it will create/destroy 4 lists by tick
17:31:51 <glx[d]> and if you want more averaging you can add another loop to repeat more by tick
17:32:32 <TallTyler> I love how string gen has almost no documentation. Time to cargo-cult the shit out of EmitPlural to make a Real Time Setting control code 🙃
17:33:10 <glx[d]> it's ancient, and it works, nobody needs to touch it 😉
17:33:28 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082355279900967003/Unnamed_1936-09-15.png
17:33:55 <TallTyler> I figured as much, but unfortunately I need to touch it 😉
17:34:24 <Rubidium> TallTyler: I dare to argue that it's better than GetPartialPixelZ
17:34:35 <TallTyler> To implement this: https://discord.com/channels/142724111502802944/1008473233844097104/1082047309375877140
17:36:28 <TallTyler> Rubidium: I suspect my problem is a bad programmer more than bad code. Better documentation makes it easier to trial-and-error my way to success 🙂
17:36:41 <glx[d]> IIRC for plural it's plural_code, index to the arg to look at, list of strings
17:37:10 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082356213158789170/Unnamed_1936-09-13.png
17:37:10 <Xarick> it's slower without vehicle_list
17:39:26 <glx[d]> so using cached data instead of iterating all vehicles is faster ?
17:39:35 <Xarick> yes
17:39:47 <glx[d]> somehow expected I'd say
17:40:52 <glx[d]> ScriptVehicleList_Group() could also benefit from a similar change
17:41:00 <Xarick> that one has already
17:41:25 <Xarick> the ones that iterates orders are the slowest
17:41:34 <Xarick> i'm not sure what to do there
17:41:59 <Xarick> it iterates vehicles, and then check it's orders to see if there's a station in there
17:42:18 <glx[d]> IIRC all VehicleList implementation are from before GroupStatistics introduction
17:43:38 <Xarick> ScriptVehicleList_Station ScriptVehicleList_Depot
17:43:48 <Xarick> i want to do something about these 2
17:44:07 <Xarick> the station one is used by the majority of ais
17:46:59 <Rubidium> be very aware that adding a cache for them does not necessarily improve the overall performance of the game, but may reduce the performance
17:47:31 <Rubidium> *especially* when you have implicit orders that come and go, and thus require constant updating of those caches
17:48:10 <Rubidium> even when there's no AI that uses it, or the AI only uses it very occasionally
17:50:55 <glx[d]> and GenerateVehicleSortList() just do like AIs
17:52:23 <glx[d]> I think in most cases, AI don't need to call ScriptVehicleList_Station that often
17:53:05 <glx[d]> if they don't touch orders nor add/remove vehicles the list won't change
18:06:36 <TallTyler> I'm going to need some help with this one. I added a function to strgen_base and OpenTTD won't even build. I think strgen fails, but I can't see the error. OpenTTD itself just chokes because `table/strings.h` doesn't exist.
18:10:45 <TallTyler> This code is cargo-culted garbage, but it's what I've got so far: https://github.com/OpenTTD/OpenTTD/commit/a055de1ce8a99607a759607561a24f80d409be9d
18:11:14 *** gelignite has joined #openttd
18:12:30 *** Gwyd has joined #openttd
18:12:30 <Gwyd> Cargo-cult?
18:13:25 <TallTyler> Gwyd: https://en.wikipedia.org/wiki/Cargo_cult_programming
18:19:39 <Rubidium> TallTyler: how's that going to work with "{NUM} {RTS day month}"? AFAIK you can't nest things
18:21:26 <Rubidium> though I can see that bribe text being a huge PITA
18:22:21 <TallTyler> It doesn't need to, the strings with numbers use the unit conversion table. The {RTS} strings don't have numbers associated with them
18:22:40 <TallTyler> I had previously had singular and plural strings which were chosen automatically, but nielsm suggested this instead
18:24:15 <TallTyler> Not sure if you can see that conversation on IRC, but it was yesterday around 21:10 UTC
18:26:21 <Rubidium> ah, then this makes some sense ;)
18:27:07 <TallTyler> {RTS} will be used almost exclusively in setting names and helptexts
18:29:04 <andythenorth> dP: I meant the whole algorithm, in vanilla 😛
18:29:10 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082369298409988096/image.png
18:29:10 <Xarick> <https://gist.github.com/SamuXarick/27d6252d1336564e0d3cc180f6f96b7c>
18:29:37 <Xarick> not sure if the code is getting the correct vehicles
18:29:42 <Xarick> I hope it is
18:31:12 <Rubidium> TallTyler: I would actually iterate at least 3 times, just to check there are not to many parameters. So it errors on {RTS da ys seconds}
18:32:31 <Rubidium> also AllocaM doesn't seem needed; doesn't "char *words[3];" work?
18:32:48 * andythenorth reading about valuate stuff above
18:32:55 <andythenorth> if only the game could see into the future
18:33:02 <andythenorth> then it could pre-valuate ahead of time 😛
18:33:06 <andythenorth> before the call is made
18:33:17 <Rubidium> TallTyler: and instead of EmitSingleChar you should do EmitWordList, but then you need to move your function a bit down
18:33:27 <JGR> You are allowed to optimise your code before OpenTTD even sees it 😛
18:33:32 <dP> andythenorth: as much as I would like a modular game, if that is to be done with GS then, I hope, never.
18:33:51 <andythenorth> it's OpenTTD, but all gameplay is in a script
18:33:59 <andythenorth> delete quite a lot of the existing C++
18:34:02 <andythenorth> make it just an API
18:34:39 <dP> yeah, but GS sucks by design
18:35:15 <glx[d]> because GS is an evolution from AI
18:35:30 <Rubidium> TallTyler: but I would probably have refactored/rewritten the word list parsing to use C++ stuff like std::vector
18:36:05 <Xarick> i'm using a std::set for vehicle_list, is this one fast enough for what I'm doing?
18:36:08 <andythenorth> I'm kind of a fan of GS tbh
18:36:16 <TallTyler> EmitWordList() wants an input of `const char * const *words`, not sure how to create that
18:36:28 <andythenorth> the negatives of GS are listable, the positives are almost infiite
18:37:57 <Rubidium> TallTyler: const char *words[EXPECTED];
18:38:24 <Rubidium> that second const gets automagically added
18:38:35 <andythenorth> positives of GS: Freedom!
18:38:59 <JGR> Couldn't you say exactly the same about C++ and NewGRF?
18:39:27 <andythenorth> negatives:
18:39:27 <andythenorth> - slow
18:39:27 <andythenorth> - underdeveloped API
18:39:27 <andythenorth> - docs are in uncanny valley
18:39:27 <andythenorth> - squirrel 2 frigging sucks
18:39:29 <andythenorth> - pain in the arse to work with GS in game as a developer
18:40:08 <JGR> Only being able to have one GS makes it non-composable
18:40:29 <andythenorth> that could be solved by libs with a common API
18:40:35 <andythenorth> but nobody wants to do it that way 😄
18:40:49 <andythenorth> realistically it would be dependency hell
18:41:43 <andythenorth> I do wonder what happens if I write a script to just zip together the methods from main.nut for two or more GS
18:41:44 <JGR> Nearly all GSs don't handly save/load gracefully
18:41:55 <dP> it's architecturally inept
18:42:08 <dP> to control gameplay you need callbacks run on client, not events run on server
18:42:25 <TallTyler> Rubidium: Updated with your comments, thanks. Still doesn't build though. 🙂 https://github.com/OpenTTD/OpenTTD/commit/b0c5b3abacaf98a6571a55ce2279dbb5504fa8ac
18:42:40 <andythenorth> oh yeah that reminds me
18:42:40 <andythenorth> - GS handles UI button clicks etc in almost the worst possible way
18:42:49 <andythenorth> I mean that's not a long list though
18:43:12 <glx[d]> yeah events are good for AIs, because they run "independently" of the game
18:45:45 <Rubidium> TallTyler: EmitWordList(buffer, words, 2);
18:45:55 <andythenorth> when I started doing grf
18:45:55 <andythenorth> - no mac build of grfcodec
18:45:55 <andythenorth> - no mac build of renum (and renum was inconsistently maintained)
18:45:55 <andythenorth> - no nml, nfo only
18:45:55 <andythenorth> - wiki was on ttdpatch and wasn't easily changed iirc
18:45:57 <andythenorth> - no action 14
18:45:57 <andythenorth> - no `reload_newgrfs`
18:45:59 <andythenorth> - no developer tools to inspect grf in game
18:45:59 <andythenorth> - complex props, vars and callbacks due to packing multiple uses into one numbered prop/var/cb
18:46:12 <andythenorth> I could list many API features added since 2008 also, and tooling changes
18:46:43 <andythenorth> grf was baroque and only for a handful of people, and now half of discord is making grfs
18:46:54 <glx[d]> but event handling itself is not optimal, the AI will receive all events even and has to filter them (which has a cost in ops)
18:47:14 <andythenorth> pub / sub? 😛 (event subscribers)?
18:47:29 <dP> andythenorth: it still sucks though :p
18:47:36 <andythenorth> everything sucks 🙂
18:47:47 <andythenorth> all of our OSes suck, and the applications
18:47:49 <andythenorth> and the hardware
18:48:05 <JGR> The GRF bitstream format may be terrible, but in terms of what you can do, it's great
18:48:08 <TallTyler> Ah, that's probably helpful, strgen still fails though. Do I need to do anything with TranslateArgumentIdx(), like in emit plural and gender?
18:48:16 <Rubidium> TallTyler: during string compilation you do not have any settings. Here you place the two options in the (compiled) lng file, and in strings.cpp you need to "copy" the SCC_PLURAL stuff but slightly simpler
18:48:21 <dP> if you take an average mod idea from someone new that doesn't know openttd capabilities, the most likely answer it "it's impossible"
18:48:49 <Rubidium> TallTyler: no, you don't need to translate argument indices, as your code does not have/use arguments
18:49:08 <TallTyler> Oh, I see
18:49:19 <andythenorth> dP: agree, but if they want to make town names...that's fine
18:49:35 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/665a73b3c7dc07bd22c32f3a6f3c6c2db8001702
18:49:36 <DorpsGek> - Update: Translations from eints (by translators)
18:49:39 <andythenorth> TBH, any complicated mod is actually really....complicated
18:50:33 <JGR> At some point you're better off writing C++ instead
18:51:13 <JGR> In doing so you can add stuff to support more GRF features
18:52:51 <andythenorth> what's left to do for GRF?
18:52:52 <TallTyler> In strings.cpp, where do I get the two string options from? I don't have ParseWord()
18:52:59 <andythenorth> almost everything is covered now I think 🙂
18:53:09 <andythenorth> the only exception is a global view on the map
18:53:10 <nielsm> as far as I remember, a lot of the initial NewGRF work on ttdpatch was pretty much the minimum required to implement what the DBset wanted to be able to
18:53:17 <andythenorth> and newships
18:53:41 <JGR> andythenorth: I can think of plenty of things, I'm sure other GRF authors have a long shopping list as well
18:54:02 <andythenorth> I mean, the requests for new vars etc will never stop
18:54:05 <glx[d]> same for station specs, luckily industries used more tinking 🙂
18:54:08 <andythenorth> and there will *never* be enough roadtypes
18:54:19 <andythenorth> make it 64k, and someone will fill them up
18:54:36 <andythenorth> but what gameplay features are not exposed to grf at this point?
18:54:41 <andythenorth> docks?
18:54:49 <andythenorth> composable airports?
18:55:09 <glx[d]> peter has a branch for docks IIRC 🙂
18:55:16 <andythenorth> I have seen it on twitch
18:55:33 <dP> grf barely allows anything more than just changing skins
18:55:44 <TallTyler> Oh, never mind, I think I found it
18:55:58 <dP> whatever you add it hardly changes gameplay at all
18:55:59 <JGR> I've got a whole stack of GRF stuff I'd like to do, but I only have a finite amount of time for such things
18:56:16 <glx[d]> composable airports would be nice, but designing a non deadlockable state machine is hard
18:59:39 <dP> https://cdn.discordapp.com/attachments/1008473233844097104/1082376971897548872/Screenshot_from_2023-03-06_22-59-09.png
18:59:39 <dP> what I did with some newgfrs xD
18:59:58 <andythenorth> I think my list of GS negatives, was the equivalent of the old grf pony list 😛
19:00:21 <andythenorth> https://www.tt-forums.net/viewtopic.php?p=847034#p847034
19:00:43 <andythenorth> maybe I should do a blog, like the ones frosch does 🙂
19:00:48 <TallTyler> I did an Indiana Jones-themed treasure hunt with GRFs, `Rainforest Ruins`. It's mostly for decoration, the game itself isn't particularly fun
19:03:01 <TallTyler> Strgen builds! Let's see if it actually works now 🙂
19:03:15 <andythenorth> so many of those feature requests made it to grf
19:03:19 <andythenorth> really a lot
19:03:34 <andythenorth> https://www.tt-forums.net/viewtopic.php?p=1240361#p1240361
19:04:40 <TallTyler> Update time? I see at least two big ones that can get checked off as done
19:05:11 <JGR> The ships with multiple cargoes one is something that I've been thinking about doing for a while now
19:05:46 <JGR> I don't agree that this should be tied to "wake" or "shadow" vehicles though
19:06:15 <JGR> Where the extra cargo goes should be an implementation detail
19:06:48 <dP> ```- cargo arriving at a station distributed to industries in catchment area using round-robin, instead of nearest neighbour. Stops all cargo being delivered to one industry, preventing certain annoyances. Rubidium tells me it would be inefficient performance-wise (and therefore is not going to happen - seems reasonable, but I thought I'd mention it).```
19:06:48 <dP> there is literally a list of stations cached on each industry now 😆
19:07:38 <andythenorth> TallTyler: yeah 2 years on
19:07:44 <andythenorth> update time indeed
19:07:46 <andythenorth> but also new ponies 😛
19:07:50 <TallTyler> Rubidium: It works! Thank you so much for your help! 😄
19:08:14 <andythenorth> JGR: this is just the old bad habit of trying to exploit hacks, instead of providing a well-designed API 🙂
19:08:27 <andythenorth> I really learnt to stop doing it at work also, I hope 😛
19:08:49 <andythenorth> I want a t-shirt slogan for it, but I didn't find one yet
19:09:13 <andythenorth> "doing what you can think of to do, rather than what you should have done for much more benefit and not much more work really"
19:09:22 <JGR> Making the GRF interface as simple as possible makes life easier all round
19:09:39 <andythenorth> ok what new ponies?
19:09:54 <dP> grf really sucks for arbitrary logic, any feature it adds needs to be coded in the game itself
19:10:15 <andythenorth> diagonal roads are not a thing, ever, yes/no?
19:10:42 <dP> not with newgrfs around 😜
19:10:59 <andythenorth> I think that's not as strong an argument as you think 😛
19:11:05 <andythenorth> or you needed more lol emojis
19:11:26 <andythenorth> oof composable road vehicles
19:11:28 <andythenorth> that would be a thing
19:11:32 <dP> discord emojis suck :/
19:11:35 <TallTyler> I don't care about diagonal roads, honestly
19:11:46 <andythenorth> I keep putting off Road Hog 2, because having 47 different length variants for trams etc
19:11:49 <andythenorth> is silly
19:12:33 <dP> diagonal roads are more of a graphical issue than a technical one imo
19:12:55 <dP> they just look awful
19:13:35 <andythenorth> I was never convinced by them
19:13:41 <TallTyler> My list:
19:13:41 <TallTyler> - Control calendar time independent of economy time
19:13:41 <TallTyler> - Automatic timetable separation
19:13:41 <TallTyler> - Extended depots
19:13:46 <dP> and tile arrangements for diagonal stuff is a nightmare
19:13:59 <dP> foundations, etc.
19:14:07 <andythenorth> providing buildings along diagonal roads 😛
19:14:31 <dP> buildings are sortable sprites, that makes it much simpler than roads themselves
19:14:38 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1082380738437066762/image.png
19:14:38 <andythenorth> hmm maybe fine actually
19:14:43 <andythenorth> the gaps wouldn't be visible
19:14:57 <JGR> Oh yes, that's another pony, a sprite sorter which isn't awful 😛
19:15:06 <andythenorth> "just reimplement in 3D"
19:15:36 <dP> afaict, sprite sorted is already pretty much as good as it can possibly be
19:15:37 <andythenorth> oh diagonal roads, it's just inevitable we'd have to support diagonal town houses
19:15:38 <TallTyler> A better sprite sorter would enable stackable bridges, which would be lots of fun but probably a gimmick more than anything
19:15:45 <dP> anything better requires z-buffer or real 3d
19:16:19 <JGR> The reversing behaviour in the current sorter is a major anti-feature
19:16:51 <dP> is it? I haven't noticed much difference
19:17:22 <dP> I think I'm running it in cmclient without reversing for a several years now
19:17:27 <dP> don't think anyone noticed xD
19:17:46 <andythenorth> oh it's way too detailed for a pony, but it would be nice to add more steps to map gen, so grf could change behaviour if a specific GS was detected
19:18:11 <andythenorth> currently AFAIK, GS is after grf, and that's that
19:19:32 <TallTyler> Rubidium: Did I get the doxygen right on `EmitRTS()`? I don't know the right technical terms for the buffers. The cleaned-up commit: https://github.com/OpenTTD/OpenTTD/commit/fb67dbbf87c20e03bce9eafc09e8f17dba3c542b
19:19:49 <dP> TallTyler: not sure it would, sorting arbitrary 3d boxes in general is impossible as there is no ordering relation for them
19:22:11 <dP> you can't just dump sprites at the sorter and hope for it to do the work for you
19:22:22 <JGR> You could probably do stackable bridges with the current sorter
19:22:44 <JGR> You'd just have the same annoying flicker edge cases as with current single level bridges
19:25:20 <TallTyler> I guess we just need perezdidac to come back, but he's not even on this Discord anymore 😦
19:25:20 <TallTyler> https://github.com/OpenTTD/OpenTTD/pull/9043
19:25:37 <TallTyler> Or somebody to adopt his PR, I guess
19:28:01 <JGR> Is there much gameplay benfit in having that, beyond eye-candy?
19:29:05 <TallTyler> Crossing bridges would be helpful I think. Stacked, not so much, but the eye-candy would be delicious
19:35:13 *** azubieta6082266 has joined #openttd
19:35:26 *** pickpacket9 has joined #openttd
19:35:45 *** HerzogDeXtEr1 has joined #openttd
19:35:54 *** Eddi|zuHause2 has joined #openttd
19:37:00 *** geli has joined #openttd
19:37:38 *** milek7_ has joined #openttd
19:37:46 *** debdog has joined #openttd
19:37:51 *** Mek_ has joined #openttd
19:37:53 *** SoniEx2 has joined #openttd
19:38:13 *** Webster` has joined #openttd
19:38:36 *** gelignite has quit IRC (Read error: Connection reset by peer)
19:38:36 *** ckb has quit IRC (Read error: Connection reset by peer)
19:38:43 *** urdh_ has joined #openttd
19:38:44 *** V453000 has quit IRC (Ping timeout: 480 seconds)
19:38:47 *** ckb has joined #openttd
19:38:58 *** berndj has quit IRC (Read error: Connection reset by peer)
19:38:59 *** avdg has quit IRC (Ping timeout: 480 seconds)
19:38:59 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
19:39:04 *** Osai has quit IRC (Ping timeout: 480 seconds)
19:39:04 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
19:39:05 *** crem has quit IRC (Remote host closed the connection)
19:39:06 *** V453000 has joined #openttd
19:39:07 *** moll has quit IRC (Remote host closed the connection)
19:39:08 *** moll has joined #openttd
19:39:15 *** crem has joined #openttd
19:39:19 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
19:39:19 *** Mek has quit IRC (Read error: Connection reset by peer)
19:39:19 *** berndj has joined #openttd
19:39:21 *** Hazzard has joined #openttd
19:39:21 *** milek7 has quit IRC (Read error: Connection reset by peer)
19:39:21 *** Soni has quit IRC (Read error: No route to host)
19:39:26 *** Hazzard has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** urdh_ has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** HerzogDeXtEr has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** nielsm has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** D-HUND has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Kuhnovic has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Brickblock1 has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Eddi|zuHause has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** frosch has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** andythenorth has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Xarick has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Alkel_U3 has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** herms has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Hirundo has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** azubieta608226 has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Webster has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Terkhen has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** Guest5864 has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** SmatZ has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** urdh has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** pickpacket has quit IRC (reticulum.oftc.net helix.oftc.net)
19:39:26 *** pickpacket9 is now known as pickpacket
19:39:27 *** Webster` is now known as Webster
19:39:46 *** andythenorth has joined #openttd
19:39:53 *** herms has joined #openttd
19:39:55 *** Osai has joined #openttd
19:40:01 *** Xarick has joined #openttd
19:40:01 *** frosch has joined #openttd
19:40:06 *** avdg has joined #openttd
19:40:21 *** Brickblock1 has joined #openttd
19:40:45 *** Hazzard has joined #openttd
19:40:45 *** urdh_ has joined #openttd
19:40:45 *** HerzogDeXtEr has joined #openttd
19:40:45 *** nielsm has joined #openttd
19:40:45 *** D-HUND has joined #openttd
19:40:45 *** Kuhnovic has joined #openttd
19:40:45 *** Eddi|zuHause has joined #openttd
19:40:45 *** Alkel_U3 has joined #openttd
19:40:45 *** Hirundo has joined #openttd
19:40:45 *** azubieta608226 has joined #openttd
19:40:45 *** Terkhen has joined #openttd
19:40:45 *** Guest5864 has joined #openttd
19:40:45 *** SmatZ has joined #openttd
19:40:45 *** helix.oftc.net sets mode: +o Terkhen
19:40:46 <andythenorth> no other ponies? 😛
19:41:03 *** HerzogDeXtEr has quit IRC (Ping timeout: 489 seconds)
19:41:03 *** azubieta608226 has quit IRC (Ping timeout: 484 seconds)
19:41:06 *** planetmaker has joined #openttd
19:41:06 *** XeryusTC has joined #openttd
19:41:13 *** nielsm has quit IRC (Ping timeout: 484 seconds)
19:41:13 *** D-HUND has quit IRC (Ping timeout: 484 seconds)
19:41:23 *** Eddi|zuHause has quit IRC (Ping timeout: 484 seconds)
19:41:26 *** ChanServ sets mode: +v Terkhen
19:42:04 *** ChanServ sets mode: +o planetmaker
19:42:46 *** nielsm has joined #openttd
19:46:33 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082388773331013787/image.png
19:46:33 <Xarick> <https://gist.github.com/SamuXarick/1a9c2c32213ec867ab2cc935915fdc93>
19:46:40 <Xarick> there are gains!
19:46:50 <Xarick> should I post a PR of this?
19:49:13 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:53:21 <Xarick> i started this just for testing, but the gains are so impressive... I wonder if you'd accept it in master
19:59:34 <Xarick> https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:group-vehicle-list
20:07:27 *** urdh has joined #openttd
20:09:24 *** Alkel_U3 has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** Kuhnovic has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** urdh_ has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** Hirundo has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** Terkhen has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** SmatZ has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** Guest5864 has quit IRC (reticulum.oftc.net helix.oftc.net)
20:09:24 *** Hazzard has quit IRC (reticulum.oftc.net helix.oftc.net)
20:10:27 *** Hazzard has joined #openttd
20:10:27 *** urdh_ has joined #openttd
20:10:27 *** Kuhnovic has joined #openttd
20:10:27 *** Alkel_U3 has joined #openttd
20:10:27 *** Hirundo has joined #openttd
20:10:27 *** Terkhen has joined #openttd
20:10:27 *** Guest5864 has joined #openttd
20:10:27 *** SmatZ has joined #openttd
20:10:27 *** helix.oftc.net sets mode: +ov Terkhen Terkhen
20:11:20 *** urdh_ has quit IRC (Ping timeout: 482 seconds)
20:21:36 *** lobstarooo__ has joined #openttd
20:21:54 <kamnet> andythenorth: Just limit it to 3-5 cars. If anybody needs more build a dang train. 😛
20:22:54 *** lobstarooo has joined #openttd
20:27:53 <JGR> Very long road vehicles don't make much sense with how road stops work anyway
20:29:42 *** lobstarooo__ has quit IRC (Ping timeout: 480 seconds)
20:29:45 *** lobstarooo is now known as lobstarooo__
20:42:57 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:43:39 <kamnet> JGR: "load through" road stops when? 🙂
20:47:29 <andythenorth> road stop platforms? 😛
20:47:42 <andythenorth> just converge all transport types to be trains, but with different sprites?
20:47:47 <andythenorth> everything is just a railtype?
21:02:55 <andythenorth> perhaps not 😛
21:05:52 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082408733952446624/image.png
21:05:52 <Xarick> last time I post screenshots related to this
21:06:20 <andythenorth> Xarick: is there a PR?
21:06:23 <andythenorth> are there any downsides?
21:06:33 <andythenorth> not that I can approve or anything, I'm not a dev 🙂
21:06:45 <andythenorth> but I am generally interested in script profiling and performance
21:06:57 <Xarick> downsides are... requires memory to cache vehicle lists
21:07:17 <andythenorth> common trade off
21:07:25 <Xarick> which is completely useless when AI's are not even in play
21:07:28 <andythenorth> are there any issues with stale cache / cache invalidation?
21:07:47 <andythenorth> the memory used by script is same in both cases?
21:07:56 <andythenorth> are you profiling OpenTTD memory use also?
21:08:07 <andythenorth> lots of questions 😛
21:08:09 <Xarick> the memory in script itself is not touched
21:08:32 <Xarick> it's the Group itself which caches the vehicle lists
21:08:50 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened issue #10547: [Bug]: Linkgraph hover tooltip "average travel time" is incorrect https://github.com/OpenTTD/OpenTTD/issues/10547
21:09:17 <Xarick> the entity in group.h
21:12:02 <dP> can it be made into a lazy cache that is only calculated when requested?
21:12:07 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #10536: Change: simplify/unify company mode scope checks https://github.com/OpenTTD/OpenTTD/pull/10536#pullrequestreview-1327198235
21:21:06 <andythenorth> is that similar to the GS giving a hint that it wants that cache generated?
21:21:16 <andythenorth> or pre-scanning the GS for code paths that might need it?
21:21:42 <andythenorth> or is it just 'first time is slow, subsequent times are faster'?
21:25:25 <Xarick> i'll update post soon
21:27:03 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on issue #10547: [Bug]: Linkgraph hover tooltip "average travel time" is incorrect https://github.com/OpenTTD/OpenTTD/issues/10547
21:28:48 <dP> they are all valid ways to do cache on demand but the last one is way simpler yet sufficient imo
21:30:07 <andythenorth> just has a cold start time
21:30:32 <andythenorth> but that will always be incurred, even with pre-generation
21:32:35 <dP> yep
21:33:15 <JGR> Maintaining a cache of groups to child vehicles could be done cheaply enough that lazy evaluation may not be worth it
21:33:43 <JGR> std::set is is fairly heavy/expensive for that though
21:34:14 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10536: Change: simplify/unify company mode scope checks https://github.com/OpenTTD/OpenTTD/pull/10536
21:38:21 <dP> yeah, I guess there aren't that many vehicles to bother
21:38:32 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened pull request #10548: Feature: Groups cache vehicle lists https://github.com/OpenTTD/OpenTTD/pull/10548
21:38:33 <dP> nested groups are a bit of a problem though
21:38:40 <Xarick> PR posted
21:38:42 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:38:57 <dP> ideally it should probably only cache in leaf groups and iterate hierarchy when queryingg
21:40:17 <Xarick> wow, conflicts already!
21:40:26 <Xarick> such timing
21:41:21 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10529: Add precondition checks for deity/company mode https://github.com/OpenTTD/OpenTTD/pull/10529
21:49:16 * andythenorth now writing dev tools in storybook
21:49:17 <Xarick> if I don't use std::set, what do I use?
21:50:01 *** geli has quit IRC (Quit: Stay safe!)
21:50:02 <JGR> std::set is fine really
21:50:28 <JGR> I'm just more penny-pinching about performance than vanilla is
21:50:31 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1082419970253791282/image.png
21:50:43 <andythenorth> ^ using `newgame` every time got boring
21:51:08 <andythenorth> I wonder if I'll foolishly end up writing a framework so I can call every function with a button?
21:51:15 <andythenorth> that would be stupid 😛
21:51:36 <andythenorth> interactive console though....that would not 😛
21:52:02 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists https://github.com/OpenTTD/OpenTTD/pull/10548
21:52:48 <Xarick> ScriptVehicleList is not done, because... v->type == VEH_TRAIN && ::Train::From(v)->IsFreeWagon()
21:53:06 <Xarick> those aren't accounted for in groups
21:53:53 <Xarick> at least that's what I think
21:54:57 <dP> JGR: unordered_set should be more performant though
21:55:48 <JGR> Non-deterministic ordering sounds like tempting fate with desyncs
21:56:14 <JGR> set and unordered_set are both pretty bad for small values TBH
21:56:34 <dP> ai/gs run on server so can't desync
21:56:57 <Xarick> the maximum number of vehicles that can be in a list is 5000, unless someone raises that limit
21:58:04 <JGR> dP: If a cache is added to struct GroupStatistics, it will get used elsewhere because why wouldn't you
21:59:23 <dP> maybe but who cares about order? gui can desync all it wants and has own sorting anyway
22:08:55 *** lobstarooo has joined #openttd
22:10:20 <Xarick> debuglevel desync=2 is soooooo slow 😦
22:13:13 *** lobstarooo__ has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** Alkel_U3 has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** Kuhnovic has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** Hirundo has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** Terkhen has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** SmatZ has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** Guest5864 has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:13 *** Hazzard has quit IRC (reticulum.oftc.net helix.oftc.net)
22:13:16 *** lobstarooo is now known as lobstarooo__
22:14:21 *** Hirundo has joined #openttd
22:14:51 *** Hazzard has joined #openttd
22:14:55 *** SmatZ has joined #openttd
22:15:10 *** ^Spike^ has joined #openttd
22:15:36 *** Terkhen has joined #openttd
22:15:36 *** ChanServ sets mode: +o Terkhen
22:15:42 *** ^Spike^ is now known as Guest6892
22:16:05 *** Alkel_U3 has joined #openttd
22:16:41 *** Kuhnovic has joined #openttd
22:17:52 <TrueBrain> lol, netsplit .. that triggered a sentry alert for no good reason 😄
22:23:48 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1082428346601853088/image.png
22:23:48 <andythenorth> story page per industry type
22:23:59 <andythenorth> doesn't do much yet 😛
22:25:01 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:34:34 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #10547: [Bug]: Linkgraph hover tooltip "average travel time" is incorrect https://github.com/OpenTTD/OpenTTD/issues/10547
22:34:37 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler closed issue #10547: [Bug]: Linkgraph hover tooltip "average travel time" is incorrect https://github.com/OpenTTD/OpenTTD/issues/10547
22:43:19 *** lobstarooo__ has quit IRC (Remote host closed the connection)
22:43:30 <kamnet> From Reddit: https://www.reddit.com/r/openttd/comments/11k7w4u/turn_trees_off_all_together/jb6ung8/
22:43:30 <kamnet> It doesn't seem unreasonable to me to move this setting into the "Expert" category and allow players to modify it.
22:51:14 <Xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1082435248920481832/image.png
22:51:14 <Xarick> why did this fail
22:51:29 <Xarick> i created a second list
22:51:44 <Xarick> so that i could compare the result of a list with the other
22:51:56 <andythenorth> can't see if squirrel has an equivalent of python dir()
22:52:16 <andythenorth> it would be nice to dump all the attributes of a class
22:52:40 <Xarick> ah, I know why
22:52:48 <Xarick> i need to add api ai game and such
22:52:52 <Xarick> my bad
22:53:26 <andythenorth> oh
22:53:46 <andythenorth> class attributes and class properties are different in squirrel, if I understood correctly
22:54:01 <andythenorth> seems attributes have a magical syntax and special handling
22:54:16 <JGR> I find it funny how some players absolutely swear by pointlessly micromanaging trees for town ratings, and others seem to think that trees are the worst thing ever and will somehow tank game performance
22:54:33 <andythenorth> repeat for PBS
22:54:38 <andythenorth> pathfinders
22:54:43 <andythenorth> ships
22:55:32 <andythenorth> 🌲 🌲 🌲 🌲 🌲 🌲 🌲 🌲 🌳 🌲 🌲
22:56:01 <andythenorth> /me -> zzzzzzzz
22:56:05 <andythenorth> or in squirrel terms
22:56:20 <andythenorth> andythenorth.state <- "zzzzzzzz"
22:56:26 <andythenorth> oh I forgot the ;
22:56:37 <andythenorth> not that squirrel seems to care
22:56:53 <andythenorth> I don't understand these languages where `;` is line-ending convention
22:56:57 <andythenorth> but doesn't do anything
22:57:03 <andythenorth> what's it for? 😛
22:58:07 <JGR> ; ends statements, not lines
22:58:21 <andythenorth> seems squirrel does sometimes need them
22:58:26 <andythenorth> I removed them all and it crashed
22:58:36 <andythenorth> but sometimes I forget them and code still works
22:58:38 <dP> JGR: performance concerns are quite valid as they do add rendering time and savegame size
22:58:55 <dP> even tick time though probably insignificant
22:59:26 <andythenorth> ok bedtime
23:01:26 *** Elouin has quit IRC (Quit: Ping timeout (120 seconds))
23:01:32 *** Elouin has joined #openttd
23:08:27 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:12:05 <Xarick> fantastic! No asserts!
23:24:53 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:27:06 *** WormnestAndroid has joined #openttd
23:30:07 <Xarick> can't upload files larger than 25 MB 😦
23:30:09 <Xarick> great
23:35:39 <Xarick> crap, not even with lzma:9 it's small enough
23:35:58 <Xarick> 28,4 MB
23:37:09 <dwfreed> zstd
23:37:15 <dwfreed> or xz
23:37:22 <dwfreed> (lzma != xz)
23:45:31 *** Wormnest has joined #openttd
23:49:21 <dP> except neither is supported by openttd :p
23:50:00 <dP> btw, did saves become larger in 13.0?
23:50:20 <dP> feels that way for some reason...
23:52:45 <dP> at least resaving old one doesn't increase much, weird...