IRC logs for #openttd on OFTC at 2023-03-06
⏴ go to previous day
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: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:44:42 *** Wormnest has quit IRC (Quit: Leaving)
03:30:59 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:17:39 *** TROILUS has quit IRC (Read error: Connection reset by peer)
04:27:47 *** bryjen has quit IRC (Quit: Leaving)
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:22:53 *** sla_ro|master has joined #openttd
06:36:57 *** nielsm has quit IRC (Ping timeout: 480 seconds)
07:40:55 <pickpacket> How high can the _settings_game.economy.town_growth_rate go?
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
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)
10:10:52 <dP> iirc "growth rate" = ticks between grow attepmpts - 1
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
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:28:08 <Xarick> `stats_all.vehicle_list.find(v->index)` doesn't work 😦
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: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: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: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: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: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: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: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:20:24 <Xarick> /* There are 14 different cases:
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:25:09 <Xarick> but there's no assert for that
12:29:02 <Xarick> I see, it fixes itself later on at line 1339
13:58:27 <glx[d]> Xarick: which is the better AI to use to easily trigger the cpu limit in valuate ?
14:00:45 <glx[d]> using a normal map size ?
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: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: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:42 <Xarick> i expected a speed up, but not this much!
15:20:00 <Xarick> creating a list of vehicles in a group
15:22:06 <Xarick> with what it's doing in c++
15:30:17 <glx[d]> let's add more print to know where each item valuation starts
15:40:57 <Xarick> with 4 valuators nested?
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: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: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: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:42 <Xarick> crashing because free on something I don't care about
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: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:33 <glx[d]> yes because it sorts on each add
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:20:13 <Xarick> can't even take a proper screnshot
17:23:31 *** tokai|noir has joined #openttd
17:23:31 *** ChanServ sets mode: +v tokai|noir
17:25:37 <Xarick> foreach (type, _ in [0, 1, 2, 3]) {
17:25:37 <Xarick> local list = AIVehicleList_DefaultGroup(type);
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: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: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: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> it's slower without vehicle_list
17:39:26 <glx[d]> so using cached data instead of iterating all vehicles is faster ?
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: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:11:14 *** gelignite has joined #openttd
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:37 <Xarick> not sure if the code is getting the correct vehicles
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> - 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: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 `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:19 <andythenorth> dP: agree, but if they want to make town names...that's fine
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: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: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> 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: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: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: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: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:12:33 <dP> diagonal roads are more of a graphical issue than a technical one imo
19:13:35 <andythenorth> I was never convinced by them
19:13:41 <TallTyler> - Control calendar time independent of economy time
19:13:41 <TallTyler> - Automatic timetable separation
19:13:46 <dP> and tile arrangements for diagonal stuff is a nightmare
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> 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: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: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:38 *** milek7_ 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:44 *** V453000 has quit IRC (Ping timeout: 480 seconds)
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:19 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
19:39:19 *** Mek has quit IRC (Read error: Connection reset by peer)
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:40:21 *** Brickblock1 has joined #openttd
19:40:45 *** Hazzard has joined #openttd
19:40:45 *** HerzogDeXtEr 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 *** 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: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
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 *** 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 *** 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: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:12:02 <dP> can it be made into a lazy cache that is only calculated when requested?
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: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: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:38:21 <dP> yeah, I guess there aren't that many vehicles to bother
21:38:33 <dP> nested groups are a bit of a problem though
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: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:28 <JGR> I'm just more penny-pinching about performance than vanilla is
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: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: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> 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:43:19 *** lobstarooo__ has quit IRC (Remote host closed the connection)
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: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:48 <Xarick> i need to add api ai game and such
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:55:32 <andythenorth> 🌲 🌲 🌲 🌲 🌲 🌲 🌲 🌲 🌳 🌲 🌲
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
23:01:26 *** Elouin has quit IRC (Quit: Ping timeout (120 seconds))
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:35:39 <Xarick> crap, not even with lzma:9 it's small enough
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...
continue to next day ⏵
