IRC logs for #openttd on OFTC at 2023-01-03
⏴ go to previous day
00:15:01 *** michi_cc has joined #openttd
00:16:58 *** sla_ro|master has quit IRC ()
00:21:43 <TallTyler> Actually wait age needs to stay in calendar years
00:21:52 <TallTyler> Nothing wrong there 🙂
00:30:45 *** Venemo has quit IRC (Ping timeout: 480 seconds)
00:47:46 *** NotLuke has joined #openttd
00:54:28 <TallTyler> Just checked, yes it is
00:56:11 <supermop_Home__> bitmask are sounintuitive to me
01:03:22 <Pruple> alternatively, you shift 7 bits and check 1 or 0 🙂
01:06:32 <Pruple> doesn't nml give you fancy ways to work with bitmasks? bitmask(7) or something?
01:07:14 <supermop_Home__> switch (FEAT_STATIONS, 80, basic_plat_shelter, nearby_tile_same_station) {
01:07:32 <supermop_Home__> so would this check if tile 7 is part of the same station section?
01:10:02 <Pruple> is that where the "80" goes? I don't use NML
01:11:15 <supermop_Home__> if i knew i wouldn't be asking
01:11:53 <Pruple> I think that's where self/parent goes? and the expression to evaluate would be "nearby_tile_same_station && 80"
01:12:42 <Pruple> to mask it to the one bit you're wanting to check
01:12:59 <JGR> Presumably hex constants need to be prefixed with 0x as well
01:13:57 <Pruple> "nearby_tile_same_station & bitmask(7)"
01:14:53 <JGR> That would work, though the values to check inside your switch become a bit unintuitive
01:16:33 <Pruple> oh, I was looking at the diagram for rail continuation above
01:17:18 <Pruple> in that case it's not a bitmask at all?
01:17:37 <JGR> nearby_tile_same_station, rail_continuation and rail_present are all testing different things
01:18:35 <Pruple> how do you do a variable with a parameter in NML?
01:19:22 <JGR> Function syntax var(param), if I remember rightly
01:19:53 <JGR> I spend more time editing the source of nmlc than I ever do actually writing NML...
01:20:45 <Pruple> so just nearby_tile_same_station(x, y) for the expression, and it's 1 if true and 0 if not.
01:20:57 <Pruple> "The first parameter is the distance to move along the platform, the second parameter is the distance to move sideways"
01:21:47 <supermop_Home__> the parameters are a bitmask tho?
01:21:56 <JGR> "Undefined if the tile is not a station tile. " so you'll need to check nearby_tile_is_station or something like it as well
01:22:30 <JGR> One of the annoying things about NML is that requires hoop jumping that generates really inefficient code like that...
01:22:37 <supermop_Home__> if its not a station i can just return some default value in the swtich?
01:24:27 <Pruple> "nearby_tile_is_station(x, y) && nearby_tile_same_station(x, y)" should return 0 if it's not the same station or a station at all, and 1 if it is the same station, right?
01:25:06 <Pruple> if you wanted to do something different if it's not a station at all vs if it's a different station, you'd need a second switch
01:26:19 <supermop_Home__> like well i am just trying to get a simple test case for now, that works differently than the default station
01:27:18 <Pruple> JGR: did you see my nfo sprite the other day for counting vehicles with ids higher than a byte? *that* was some hoop jumping. 🤣
01:28:01 <supermop_Home__> so for a test, i want to not draw the brick-arch walls where two train sheds are next to each other, and draw columns instead
01:29:34 <supermop_Home__> so i want to check ideally if a neighboring tile is another shed or not, but barring that i'll settle with checking if it's part of this station to start
01:29:56 <supermop_Home__> if it's a different station or no station, i will draw the wall
01:30:41 <Pruple> had to store and recall the count-so-far each time, because you need to use var 7b to feed the vehicle id to var 60... what joy.
01:31:15 <JGR> That does not look too bad as varaction2 sprites go
01:31:45 <Pruple> nope. but it's vastly more complex than just a + b + c + d you could do with ids < ff
01:33:05 <Pruple> supermop_Home__: I guess when you get to that stage, it'll be checking if it's a station tile, then checking, nearby_tile_grfid, then checking nearby_tile_station_id 🙂
01:36:22 <supermop_Home__> switch (FEAT_STATIONS, nearby_tile_same_station(0,-1) switch_n_plat_samestation) {
01:37:14 <supermop_Home__> then values like 0: plat_a; 1: plat_b; plat_a
01:38:40 <Pruple> switch (FEAT_STATIONS, SELF, switch_n_plat_samestation, nearby_tile_same_station(0,-1)) { ?
01:40:52 <supermop_Home__> do stations use the self|parent thing?
01:41:09 <Pruple> yes, I think everything does
01:41:18 <Pruple> in the case of stations the parent is the town
01:41:57 <supermop_Home__> unfortunately i don't think you can do anything interesting with the town
01:42:14 <Pruple> well, you were talking about figuring out which side is closest to town before
01:42:19 <Pruple> you could compare the coordinates 🙂
01:42:36 <supermop_Home__> i wanted to make it put the little station house facing the town, but don't think that's possible
01:42:39 <Pruple> if stations know their coordinates, that is
01:43:05 <JGR> There aren't any variables for that
01:43:10 <supermop_Home__> i guess you could try to check the population or if it is a city, and only build big sheds if so
01:43:24 <glx[d]> station spec is quite old
01:45:15 <Pruple> oh well, cest la thing
01:46:25 <glx[d]> and I agree NML generated code is not the most efficient
01:47:14 <glx[d]> but bitstuffed data in the spec doesn't help
01:49:00 <supermop_Home__> this is probably dumb, but is there a fast way to just check if a platform number is even?
01:49:46 <supermop_Home__> like the default shed alternates between north and south facing roofs, but if I am not using the default tile layout, i need to manually do that
01:49:47 <JGR> The platform_number_from variables
01:50:01 <glx[d]> platform_number_from_start(PLATFORM_SAME_DIRECTION) % 2
01:50:36 <supermop_Home__> % is some kind of divisible-by-operator?
01:50:51 <glx[d]> it's the remainder of /2
01:51:13 <Pruple> % is modulo, divides and gives the remainder
01:51:48 <supermop_Home__> i'm sorry but this was not taught in architecture school in the early 00s so i have to stumble my way through this stuff
01:51:57 <Pruple> so % 2 gives you 0 1 0 1 0 1, % 4 gives you 0 1 2 3 0 1 2 3 0 1 2 3, etc... very useful for coding repeating patterns. 🙂
01:51:57 <supermop_Home__> so please be patient
01:53:07 <supermop_Home__> that is easier than doing a switch and returning different values for each number of platforms up to 16+
02:01:57 <TonyPixel> Will something like this work?
02:14:44 <supermop_Home__> hmm if i use a %2 modulo thing, the 3rd platform will also be 0, and will get half of a shed roof
02:14:55 <supermop_Home__> i'll need something else to check for that
02:18:20 <supermop_Home__> so first ill check number from start%2, then if 0 check number from end
02:26:35 <supermop_Home__> in callbacks i return this now:
02:26:38 <supermop_Home__> sprite_layouts: [layout_plat_00_X, layout_plat_01_Y, layout_plat_02_X, layout_plat_03_Y, layout_plat_04_X, layout_plat_05_Y, layout_plat_06_X, layout_plat_07_Y];
02:26:59 <supermop_Home__> can that array be somewhere else as the result of a switch?
02:27:39 <supermop_Home__> like sprite_layouts: switch_layouts… and then the results of the switch are like 0: [layout_plat_00_X, layout_plat_01_Y, layout_plat_02_X, layout_plat_03_Y, layout_plat_04_X, layout_plat_05_Y, layout_plat_06_X, layout_plat_07_Y];
02:37:44 <Pruple> beyond my knowledge of either stations or nml, sorry 🙂
02:41:36 <supermop_Home__> well im gonna try it anyway
02:48:58 <glx[d]> no, it must be sprite_layouts
02:49:49 <glx[d]> it's a limitation of the spec, layouts are actually properties under the hood
02:56:43 <glx[d]> but you can put as many spritelayouts as you want in the array and use select_sprite_layout callback to select which one to use
02:58:00 <TonyPixel> You can return array?
03:05:14 <supermop_Home__> so i put arrays in my switch results,
03:06:28 <supermop_Home__> glx[d] so the select layout callback returns arrays as well, or just a number that picks one from the array in sprite_layouts?
03:07:36 <supermop_Home__> so that callback can point to a switch that returns some number 0..8?
03:08:07 <supermop_Home__> and then it picks the 0..8th item out of the layout array?
03:09:10 <glx[d]> well 0/1 will pick 0 or 1 depending on orientation
03:09:58 <glx[d]> the array can have more than 8 values
03:10:52 <glx[d]> without the callback the spritelayout is selected from 8 first in the array based on tile type
03:12:37 <supermop_Home__> what does custom_spritesets do?
03:12:54 <glx[d]> work around another limitation of the spec 🙂
03:13:06 <supermop_Home__> can i use that instead?
03:13:35 <glx[d]> custom_spritesets is to be used inside the sprite_layout
03:13:55 *** Wormnest has quit IRC (Quit: Leaving)
03:14:26 <supermop_Home__> so istead of like 20 layouts, i can have 2 that use that to pick the sprites?
03:14:51 <glx[d]> yes, custom_spritesets accept switches as values
03:15:04 <supermop_Home__> hmm maybe that would be easier
03:16:41 *** _aD has quit IRC (Quit: leaving)
03:17:19 <supermop_Home__> iso i can just return 8, correct? not 8/9?
03:21:12 <glx[d]> if you ignore all the temp values magic it's not too hard to understand
03:21:17 <supermop_Home__> select_sprite_layout: can't point to a switch?
03:21:40 <supermop_Home__> maybe i messed something else up
03:22:04 <supermop_Home__> nmlc says unrecognized identifier
03:22:35 <supermop_Home__> select_sprite_layout: switch_shedpart;
03:22:53 <supermop_Home__> switch (FEAT_STATIONS, SELF, switch_shedpart, platform_number_from_start(PLATFORM_SAME_SECTION)%2) {
03:23:09 <supermop_Home__> doesn't look misspelled
03:23:11 <glx[d]> the switch must be defined before
03:23:38 <supermop_Home__> switch is on line 574 and the station item is line 610
03:26:58 <supermop_Home__> i had all my switches commented out while i was working on then basic station yesterday
03:27:12 <supermop_Home__> and forgot to remove my /* and */
03:27:44 <glx[d]> your editor doesn't color ?
03:27:57 <supermop_Home__> i only noticed when pasting into a gist to post the code
03:28:27 <supermop_Home__> it colors the little */ pink but it was on a line by itself
03:28:50 <glx[d]> it should color all the commented out code
03:28:56 *** wallabra has quit IRC (Ping timeout: 480 seconds)
03:32:37 *** wallabra has joined #openttd
03:32:56 <supermop_Home__> well it doesn't really do what i wanted but it does something!
03:33:43 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:34:23 <glx[d]> you can use platform_count to filter
03:37:58 <supermop_Home__> the check for nearby tile same station doesn't seem to do anything, or it always returns yes
03:40:03 *** wallabra_ has joined #openttd
03:40:45 *** wallabra has quit IRC (Ping timeout: 480 seconds)
03:40:45 *** wallabra_ is now known as wallabra
03:52:50 <supermop_Home__> in trying to fix it, i broke it more in a way that looks better?
03:57:14 <supermop_Home__> where i tell it to use layout 8, it ends up alternating 8 and 10...
03:58:18 <Pruple> supermop_Home__: looks like reading along the platform instead of across?
03:58:40 <supermop_Home__> its doing both
04:00:03 <supermop_Home__> one of my platform_number was a platform_position
04:06:53 <supermop_Home__> now maybe want some kinda wall between the shed and open platform..
04:07:13 <supermop_Home__> and maybe automatically island/side platforms
04:08:56 <supermop_Home__> maybe automatic buffers
04:15:05 *** TROILUS8 has joined #openttd
04:20:53 *** TROILUS has quit IRC (Ping timeout: 480 seconds)
04:20:54 *** TROILUS8 is now known as TROILUS
04:24:45 <glx[d]> nml stations are maybe not easy, but they can do a lot
04:36:46 <supermop_Home__> well now that i got this a lot of the path forward is clear
04:37:16 <supermop_Home__> apart from some philosophy choices
04:37:51 <supermop_Home__> like whether and how to do open ends of the platforms
04:38:54 <supermop_Home__> it annoys me when a build a 2x5 station as a terminus in a town, and it has those open stubs on the town end of it
04:39:21 <supermop_Home__> but there is no real way for the station to know which end you want the end on, if not the middle
06:16:56 *** MaverickFischer has quit IRC (Remote host closed the connection)
06:18:19 *** MaverickFischer has joined #openttd
06:25:55 <Pruple> ooh, that's interesting
06:27:47 <Pruple> I'll have to do a little more experimenting, but it appears that if you set the "(Attempt to) Synchronize reliability the primary engine" flag for a variant, the model life / withdrawal is based on the parent loco's introduction date, rather than the variants'. 🙂
06:28:17 <Pruple> which kind of makes sense, but it would be nice to know if it's intended behaviour 😉
06:29:08 <Pruple> in which case it should probably be documented as such
07:13:39 <andythenorth> if you post-hoc add it to the spec, then it's 'intended' 🙂
07:13:43 <andythenorth> that's how it works, right?
07:16:13 <Pruple> it doesn't really matter how it works, as long as it keeps working the same way 🙂
07:35:14 *** sla_ro|master has joined #openttd
08:59:23 *** ag has quit IRC (Quit: User went offline on Discord a while ago)
09:36:50 <petern> Model life is intrinsically linked to reliability, however it's not actually coded to deliberately do that.
09:38:45 <petern> Ah, the bit that does will be where it overrides the age of the model with the age of the variant.
09:40:26 <petern> At this point if things need to be changed they can.
09:41:51 <petern> Reliability sync basically needs intro date and base life to be the same as the parent to actually sync it.
09:42:08 <Pruple> it's fine how it is I think. just needs to be set in stone so that no-one tries to "fix" it down the road.
09:42:56 <petern> Basically anyone who does testing now and says it's wrong, or says it's right, gets a say.
09:43:44 <petern> It is a bit arbitrary trhough.
09:44:04 <petern> Engines are expired because their reliability says so
09:44:38 <petern> So in a way it makes sense that it affects the life of a variant when you sync reliability.
09:44:55 <Pruple> yes. withdraw early doesn't have to match up, right?
09:45:32 <Pruple> that's how I discovered the issue... later-introduced variants were being withdrawn too early
09:46:45 <petern> So the potential pitfall I see is that if the parent variant is expired then age probably won't progress, hmm.
09:47:19 <petern> Withdraw early... is that retire early.
09:49:08 <petern> So, withdraw early shouldn't affect it, but the sync-reliability concept will cause early withdrawal anyway, as the age is based on the parent variant instead of its own.
09:50:18 <petern> I guess it's a bit fragile, and the fact that a variant won't age if its parent has expired probably does need to be fixed.
09:55:14 <petern> I imagine the whole syncing thing just doesn't work right.
09:56:20 <petern> Oh well, bad features 😦
09:58:03 <Pruple> eh, it actually seems to work fine here 🙂
09:58:26 <Pruple> synced necessarily implies the variants retire at (about) the same time, right?
09:59:22 <Pruple> so I gave my later-introduced variants the same lifespan and retire early, and it looks like it works okay 🙂
10:02:25 *** supermop_Home__ has quit IRC (Ping timeout: 480 seconds)
10:35:56 <petern> Okay, I've passed the buck; "this needs to be discussed higher up"
10:37:35 <petern> I think that is suitable code for "speak to the CEO to sort out your business plans, not me who is just a developer"
10:39:14 <LordAro> alignments look a bit odd :p
10:40:03 <petern> I'm not arguing over this today though 🙂
10:40:28 <Pruple> couldn't be correcter if they tried, but that doesn't mean they can't *look* odd, that's subjective. 🙂
10:43:04 <petern> I'm tempted to align shorter vehicles properly, but that would indeed mess up a lot of existing sets.
10:43:40 <petern> Looks like it would be better for UKRS3 though.
10:44:48 <Pruple> are they not aligned properly? apart from the whole shifting on reverse thing...
10:44:59 <petern> Articulateds need special handling whatever, so... Hmm.
10:45:29 <petern> Your shorter engines are aligned properly, but OpenTTD doesn't centre them properly.
10:45:38 <LordAro> Pruple: top level brush 4 being more indented than intercity push-pull seems odd
10:46:08 <LordAro> and in general i'd expect the variants to be aligned
10:46:19 *** HerzogDeXtEr has quit IRC (Quit: Leaving.)
10:46:35 *** HerzogDeXtEr has joined #openttd
10:46:48 <Pruple> since one's a single vehicle and the other's double-headed, that would be difficult 🙂
10:47:03 <petern> Top-level is the "non-variant" one.
10:48:40 <petern> Variants get indented for each level.
10:49:14 <petern> Otherwise, OpenTTD itself is centring sprites.
10:49:53 <petern> See how MUs are drawn with respect to single engines with no NewGRFs.
10:51:32 <LordAro> Pruple: what's double-headedness got to do with it? you're already providing custom build menu sprites i think ? (i.e. the cut off carriage)
10:51:51 <LordAro> i've no idea how any of this stuff works, i'm just saying it looks a bit odd :)
10:52:22 <LordAro> and by aligned, i mean "left-aligned"
10:52:43 <petern> The point is it is intended for engines to be centred, not left-aligned, and then variants additionally get indented.
10:53:07 <LordAro> in which case, i don't think they should be centred :)
10:54:45 <reldred> I honestly think it should just be left aligned, with the widest sprite defining the standard offset for text. Indented varieties move everything by the indented amount.
10:54:54 <reldred> Ignore chris sawyer, I am right.
10:55:30 <Pruple> left aligning everything doesn't look great. but do what you want with your own newgrfs 🤷
10:55:55 <reldred> lmao, my main gripe with grf's is all the silly flags and symbols
10:56:03 <petern> Perhaps, but while changing this in OpenTTD would make things simpler, it would break every set already released.
10:56:06 <Pruple> the indenting for variants is new, so it looks odd, but we'll get used to it. Also, you don't normally leave the indents open after you've selected a vehicle
10:56:11 <reldred> if I like a .grf enough I will make my own custom version with them removed 🙂
10:56:27 <Eddi|zuHause> newgrfs can easily align vehicles themselves by providing purchase sprites that are all the same width (make sure cropping is off)
10:56:56 <petern> Yeah, I tempted to make variant groups auto-collapse.
10:57:01 <LordAro> it looks odd enough that i think it looks wrong
10:57:11 <LordAro> i.e. someone's screwed the offsets up
10:57:27 <LordAro> the vehicles just look like they're jumping around all over the place
10:57:33 <Pruple> petern: one thing that I keep finding myself wanting is a way to select a variant without actually building it 🙂
10:58:20 <Eddi|zuHause> my console autocompletion still wants to run "bin/openttd" instead of "build/openttd"
10:58:23 <Pruple> ie, make that variant the parent in the menu when I collapse the group
10:59:08 <petern> Pruple: Estimate the cost... although only works in a depot, not in the the available vehicles list.
11:00:13 <Pruple> that works, but... how would it be if just selecting a variant makes it the parent?
11:01:11 <petern> Select the parent and close the group, to reduce clutter?
11:01:25 <Pruple> something like that...
11:09:50 <petern> The variant selection happens when the command is sent, but isn't done by the command itself.
11:10:24 <petern> The only other time its changed is when a variant expires.
11:11:08 <petern> Auto-closing might conflict with how others use it though.
11:11:47 <petern> Although ensuring only one group is open is maybe a reasonable approach.
11:12:00 <Pruple> I didn't necessarily want auto-closing. just auto-changing the parent when I click on one of the variants
11:12:09 <Pruple> open the group, select the one I want, close the group
11:12:10 <petern> The screenshots of lots of open groups wouldn't be possible though, oh no!
11:12:28 <petern> Let's add an expert hidden patch setting to control it.
11:13:25 <petern> Hmm, can we push loading of savegame information to a background thread?
11:14:30 <petern> I've got someone's 4kx4k save and everything freezes for a second while getting its info.
11:17:49 <dP> I don't think auto changing parent is that good of an idea either way
11:18:31 <dP> last build variant isn't always useful and it's harder to find thing you need when it changes looks every time
11:19:37 <JGR> petern: You can do decompression in its own thread easily enough
11:29:25 <petern> I just noticed that Colour is a union with constructors. I never knew that was a thing.
12:18:54 <andythenorth> I'm fine with it 🙂
12:31:32 *** JustANortherner has quit IRC (Quit: User went offline on Discord a while ago)
12:39:08 <petern> It is perhaps a bit clearer when there are more entries.
12:40:06 <petern> Hmm, I've tried to make the original colours match but it's not quite the same 🙂
12:45:07 <LordAro> andy's alignments look fine because the variants aren't different sizes
12:47:24 <dP> still looks wrong to me to have indentation with central alignment
12:48:24 <dP> indentation implies there is something to indent there
12:48:27 <TallTyler> I would agree, but don't intend to argue about it 🙂
12:48:42 <LordAro> but someone is *wrong* on the internet!
12:49:00 <TallTyler> I also hate center-aligned text that's more than a single line (title and subtitle are fine because they're two single lines)
12:49:05 <TallTyler> Outside OpenTTD, I mean
12:53:35 <DorpsGek> LordAro: I have not seen fonso.
12:54:01 <petern> It can be reviewed to see if it makes sense though 🙂
12:54:58 <JGR> There are some similarities with the changes I've made in my branch, at a quick glance
12:55:16 <JGR> They nearly everything I've done with it has been aimed at performance, instead of simplification
12:56:22 <JGR> Not using SmallMatrix for edges in particular is a good idea
12:57:41 <petern> Small* usually means reimplemented badly.
12:59:23 <JGR> It's more that a sparse representation is much better as the graph size increases
13:00:03 <LordAro> i like that SmallMap is just a std::vector<std::pair<>>
13:02:32 <JGR> SmallMap is a bit strange, it's not sorted like boost::flat_map, yet still does all the memory moves when erasing
13:17:43 *** APTX has quit IRC (Quit: Farewell)
13:23:00 <JGR> michi_cc[d]: This looks really nice
13:33:53 <petern> My quick glance says "less is more" so this wins on that alone 🙂
13:43:04 <Rubidium> michi_cc[d]: I hope you meant simplify :D
13:44:14 <michi_cc[d]> Ru: bidium Who knows... 🙂 But yes, simplify.
13:46:07 <michi_cc[d]> JGR: No idea if you ever made any tests in this regard, but right now I sorted the edges list. Regarding performance, for the amount of edges per node I see in "typical" games, most resources online seem to indicate that a straight unsorted linear search would be faster (mainly due to cache misses and branch mispredictions).
13:46:38 <michi_cc[d]> As the old iteration order wasn't sorted either, I'm tending to just go to a unsorted, linearly searched vector.
13:47:54 <michi_cc[d]> petern: SmallMatrix is indeed not a good C++ container, due to the complete disregard for construction/destruction, which then is worked around in LG code by placement new and stuff.
13:48:21 <petern> I suspect it got left because nobody wants to touch LG 🙂
13:50:27 <JGR> At the moment I'm still using SmallMatrix for the edge annotations in LinkGraphJob, but I'm using a btree for the edges in LinkGraph
13:51:31 <petern> Hmm, do I need to test Internet Explorer in 2023...
13:51:44 <michi_cc[d]> The underlying reason for this is of course actually YACD, where I want to have multiple edges from one node to another. And a simple list seems to be to be the easiest way to do it while still not needing duplications for cargodist.
13:52:09 <JGR> SmallMatrix's resize operation is extremely slow
13:54:38 <michi_cc[d]> As each edge corresponds to an outgoing order from a station (for a specific cargo), I'm operating under the assumption that the average "fan-out" from a station is probably far below 20 or so (maybe even more like 5), where the "invisible" constant in O(....) actually matters.
13:55:29 <JGR> As in, each destination reachable directly by a vehicle leaving the station, instead of just the next hop?
13:57:38 <michi_cc[d]> JGR: Regarding which part? For cdist, an edge is basically corresponds to one or more vehicles having the destination node as the next stop. For YACD, I want to split on order list boundaries, so potentially have more than one edge from one node to the destination node.
13:58:26 <JGR> What is the benefit of doing that?
14:00:35 <michi_cc[d]> Cdist doesn't care how it routes cargo, but for fixed, cargo-packet specific destinations, A - B - C is not the same as A - B - D - E - F - C. So cdist will only store one edge A -> B, no matter how many different order lists this corresponds to. For YACD, cargo A -> C should usually not use the second connection, so I need to have two edges A -> B.
14:06:56 <JGR> So MCF from A to C would match the A -> B edges with the B -> C edge on the source order list when allocating the flow
14:08:29 <andythenorth> it's off-topic to our problem, but I am trying to find an article about the early days of Fedex (1973) by an engineer who was involved in the routing algorithm design
14:08:33 <andythenorth> mostly because it was interesting
14:09:01 <andythenorth> I think they effectively partitioned the problem to suit the hardware they had (both compute and transportation)
14:09:20 <andythenorth> so the routes for a package to and from hubs were a routed graph
14:09:29 <michi_cc[d]> Potentially yes, depending on the applied weighting. But more importantly, the actual cargo packet doesn't care about where it is actually unloaded either.
14:09:34 <andythenorth> but the hubs act as sinks / start nodes on the graph
14:09:43 <andythenorth> and all hubs are assumed to be equally connected
14:10:01 <andythenorth> then they optimised transit between the hubs to suit the availability of the airline fleet and crew
14:10:31 <andythenorth> which let them shift packages between hubs at low cost in capital (planes) and opex (flight crew)
14:10:32 <michi_cc[d]> So it just gets transported to the next station and then a "random" decision says what do with it.
14:13:03 <michi_cc[d]> Whereas the concept of YACD is cargo routing from source tile to a destination tile that is not determined by route connectivity. Other cargodEst concepts are of course possible, but not what I want to do with YACD.
14:13:50 <JGR> Wouldn't that be easier just controlling the demand layer though?
14:14:35 <michi_cc[d]> No, as this still randomly assigns the cargo packets to a next action at each unload.
14:15:01 <JGR> I don't understand why that is a problem though
14:15:45 <michi_cc[d]> When a vehicle arrives at a station/new cargo is generated, cdist looks at a flow share map and assigns the packets to whichever share is currently too small.
14:17:56 <JGR> With the end result that approximately the right proportion of cargo is delivered to each destination of the source node
14:18:35 <michi_cc[d]> JGR: One is payment because there's no guarantee that the payment distances actually correspond to what it should be from the destinations.
14:19:35 <Eddi|zuHause> i think cargodist has some weird effects when more cargo is routed through a network than transport capacity allows
14:20:13 <michi_cc[d]> The second one is that I at least intend to keep the "personalities" in YACD (if performance allows), which can cause to just be not transported (or transported differently) depending on the routes available.
14:20:24 <JGR> The cargo packet origin station and tile does not change as it is routed
14:21:03 <michi_cc[d]> The destination is indeterministic, though.
14:21:10 <petern> Yeah but (hopefully) FedEx don't decide where the packages should go 🙂
14:21:30 <JGR> Actual payment is done on delivery
14:22:37 <petern> Okay, updated JS does not work in IE.
14:22:46 <michi_cc[d]> The cdist flow mapper will happily route cargo A -> B and C -> D, but the user visible demand links in YACD might say A -> D and C -> B, which would have a different profit leve.
14:23:14 <JGR> Are you thinking of subsidies or something like it?
14:23:50 <michi_cc[d]> But like I said earlier, there are certainly many ways how to skin the cargodest cat, but for YACD I have a specific vision in mind.
14:24:52 <andythenorth> petern: no, although they did decide where to serve 😛
14:24:53 <michi_cc[d]> JGR: In YACD, towns and industries will literally show a list of destinations which the expected cargo amounts, and I want the cargo to actually travel to the shown destination.
14:25:03 <michi_cc[d]> And not just statistically arrive.
14:25:04 <andythenorth> it's not like we could copy the algorithm, but it's interesting operationally 🙂
14:26:08 <JGR> Adding a destination ID to the cargopacket and using the source/destination tuple for routing at each hop, perhaps?
14:26:59 <michi_cc[d]> Yes, like this. But to get the routing result I want I need to keep information about more than one edge between two stations.
14:28:40 <michi_cc[d]> Thus coming back to the initial thing, either the LinkGraph needs more than one edge between nodes or I would need to basically duplicate it (which I did in the old YACD as there was no cdist), but I don't want to because of all the order-related code that would be duplicated with it.
14:31:07 <Eddi|zuHause> but do you need more edges, or more information stored on one edge?
14:31:59 <michi_cc[d]> Well, I could of course put another list into each edge, but I'm not sure my CPU cache would like it.
14:33:53 <JGR> If there are multiple equivalent order lists between two nodes, is there a "get on the first arriving vehicle" to that hop mode?
14:34:27 <michi_cc[d]> Eddi|zuHause: As it is right now, the edge matrix for a graph of 100 somehow connected stations needs ~310MB per cargo.
14:34:59 <michi_cc[d]> Scratch that, mistyped, it's not MB, but KB.
14:35:29 <JGR> In my current game, the passenger link graph has about 2300 nodes
14:35:39 <JGR> So performance is something that I care about a lot 😛
14:35:44 <Eddi|zuHause> i still have my yacd1 savegame somewhere
14:36:02 <michi_cc[d]> But there where some pathological cases with matrices large enough that the savegame storage was indeed changed to only store the used elements from the matrix.
14:36:43 <michi_cc[d]> JGR: Okay, yes, that is "better". About 160 MiB per cargo.
14:37:21 <Eddi|zuHause> cargo linkgraph might need some better support of autorefit
14:38:38 <JGR> Autorefit is best avoided in general
14:39:00 <Eddi|zuHause> i really like autorefit
14:39:12 <andythenorth> ah that PDF contains the fedex partition
14:39:36 * andythenorth is an operations research geek
14:39:52 <michi_cc[d]> There might even be a bug there, because I get an assertion on one specific old savegame of mine. I haven't taken the time though to check if isn't just the save that is borked.
14:42:02 <andythenorth> 100% hub-based, we don't want hub-based, bus passengers don't work that way 😛
14:42:39 <andythenorth> and we don't have designated hubs
14:43:40 <JGR> Autorefit can cause performance issues with link refreshing and removing stale links
14:44:00 <JGR> I've got some fix for that in my branch, but can't remember exactly what
14:44:32 <Eddi|zuHause> it also has problems with establishing links in the first place
14:45:36 <andythenorth> 'refit any available' doesn't play well with cdist
14:45:55 <andythenorth> it can cause spurious links to be established, and they are then very hard to clear
14:46:05 <andythenorth> 'reload game' is usually the solution
14:46:09 <JGR> Players still use it though
14:46:38 <andythenorth> I use 'refit any available' for freight, but I don't use cdist for freight
14:47:12 <andythenorth> the friction of adding transfer orders is a lot lower than the friction of cdist
14:47:31 <andythenorth> it would be unfair to say cdist doesn't work, but the ways in which it does work are limited and faceted
14:47:56 <JGR> I use cargodist for all cargoes, but getting this to work reasonably in vanilla is very difficult
14:48:22 <andythenorth> I used cdist for pax, but it's very important to minimally connect the network
14:48:45 <andythenorth> a point-point connection between 2 cities, then local distribution within each city
14:49:00 <JGR> Eh, I'm not sure about that either
14:49:10 <andythenorth> * playstyles vary etc etc 🙂
14:49:17 <Eddi|zuHause> like i said, cargodist works poorly when all the links are overloaded
14:49:32 <andythenorth> well it works as specified 🙂
14:49:38 <andythenorth> just not maybe how some of us want 🙂
14:49:55 <JGR> Hub and spoke topology just guarantees congestion problems at the hubs
14:50:17 <JGR> I tend to go for a more mesh-like topology
14:50:52 <Eddi|zuHause> me too, but the mesh only works if you provide enough capacity, which can be... challenging
14:51:30 <JGR> Passenger generation in vanilla is too high for cargodist really
14:51:54 <andythenorth> if 'effect of distance on demand' could be tuned per linkgraph that might be....a thing 😛
14:52:04 <andythenorth> there's never a 'best' value in any game I play
14:52:14 <andythenorth> there's 'best for this city'
14:52:25 <andythenorth> then new problems emerge elsewhere
14:52:42 <JGR> You have a separate network for each city?
14:53:09 *** supermop_toil has joined #openttd
14:53:13 <Eddi|zuHause> passenger generation is too high, which needs a high distance effect, but for other cargos the effect should be low
14:53:38 <andythenorth> JGR: usually I connect cities in pairs
14:53:48 <andythenorth> then build buses or metros to distribute within the city
14:53:52 <JGR> Better to just reduce passenger generation entirely
14:54:16 <andythenorth> depending on the distance, network, population etc, changing distance effect can lead to empty metros, or overloaded metros
14:55:05 <JGR> At the moment I'm using a passenger generation of 1/6.5 of vanilla levels, in real time terms
14:55:44 <Eddi|zuHause> JGR: did the linear generation change help?
14:56:11 <JGR> Yes, but generation is too high even in linear mode
14:56:57 <JGR> In practice you need to tweak generation levels as your network size increases, that is probably something that could be automated in a YACD type system
14:57:25 <andythenorth> "increasing network connections increases ridership"
14:57:35 <andythenorth> there's probably a TedX about it or something 😛
14:57:53 <Eddi|zuHause> yeah, YACD adressed that by generating cargo for all destinations, not just the connected destinations.
14:58:11 <petern> PRs on internal projects considered harmful...
14:58:24 <andythenorth> petern: don't do it
14:58:30 <andythenorth> oh wait, no, they're good
14:58:46 <supermop_toil> although if i cannot possibly get to an office building by any means, i wont take a job there
14:59:10 <andythenorth> I know this is the shitty equivalent of 'well it works for me' but YACD was never a performance issue for me, on much older intel hardware, on a not very efficient mac build
14:59:11 <supermop_toil> so my commute destination can only be distributed to those offices i can reach
14:59:12 <petern> YACD's "all destinations" needs to be tempered a bit.
15:00:08 <petern> e.g. industries should have "contracts" with each other as to who they supply to/buy from.
15:00:29 <petern> This is gamescript land though.
15:00:55 <petern> That long coal run that spans the whole map and earns millions in your first year? Yeah no.
15:00:57 <Eddi|zuHause> that's something vaguely like subsidy
15:00:59 <JGR> I don't know, it ought to be possible to do something plausible through NewGRF
15:01:13 <andythenorth> I am probably in a 5% minority, but I would be happy with YACD for limited cargos
15:01:17 <andythenorth> basically town cargos
15:01:35 <petern> That sort of limit is needed to stop full cargodest exploding, but can't be integrated due to reasons
15:02:11 <supermop_toil> also plane flight between opposite corners of map - yes for tourism and business travel, no for commuting?
15:02:41 <Eddi|zuHause> andythenorth: town cargo is the primary target for YACD-style destinations, as it encourages adding more destinations
15:02:46 <petern> Full cargodest is terrible at the start because you get barely any passengers because you can't transport them all across the map.
15:03:04 <supermop_toil> but if the airport is all the distant town has, cdist will allocate all its passengers to air travel regardless of distance setting
15:03:27 <supermop_toil> rather than only generate a resonable number of long distance travellers
15:04:58 <petern> Ah that was the pipeline that I made deploy-on-merge rather than deploy-on-tag. Hmm.
15:05:19 <michi_cc[d]> JGR: Did you fix the memory leaks I just actually noticed in the current vanilla LinkGraphJob? Each NodeAnnotation has a `std::map` and a `std::list` constructed by placement new and I can't see any actual destructor call. The list are cleared I think, but that does not necessarily free all underlying memory.
15:09:33 <michi_cc[d]> JGR: Oh sorry, I read that wrong. NodeAnnotations are actually stored in a `std::vector`, so destructed. But the placement new is probably wrong because it will overwrite an already constructed memeber.
15:11:49 <JGR> The placement new calls are gone in my branch, they are fairly harmless as an empty container won't have allocated anything yet
15:14:58 <JGR> I think that is a leftover from SmallVector to std::vector conversion
15:15:19 <michi_cc[d]> The would be gone after #10314, too 🙂
15:16:48 <Eddi|zuHause> i've never quite understood the concept of unit tests
15:17:33 <petern> They're useful if you can easily compartmentalise things.
15:17:37 <Eddi|zuHause> like, what's supposed to be the "unit" that is being tested?
15:17:59 <Eddi|zuHause> and does the test come first, and then the unit?
15:18:23 <petern> In some case yes, you create the test and then fulfil it.
15:18:43 <petern> But that really does require a clean plan before you begin which isn't always possible. Or least, isn't how I work :p
15:19:11 <Eddi|zuHause> i almost never know how a thing works until it is finished
15:19:37 <Eddi|zuHause> and when it is finished the test is usually redundant
15:19:38 <petern> Yeah, but unit tests are what it does, not how it does it.
15:20:00 <JGR> Unit tests really become useful when you need to add something else three months later
15:20:13 <JGR> And you don't want to accidentally break anything that was already working
15:20:15 <Eddi|zuHause> but defining a unit usually implies already some knowledge about how the thing works
15:20:26 <Eddi|zuHause> which may force a design decision on you early
15:20:44 <michi_cc[d]> Software design by accident is not always the best way to design.
15:20:50 <dP> usually it's a good idea to know how thing is supposed to work before starting to write it :P
15:21:13 <JGR> "Unit" doesn't have to mean fancy design patterns
15:21:39 <JGR> It's just something that you can usefully test
15:23:42 <dP> michi_cc[d]: is #10314 supposed to work exactly the same just faster?
15:24:00 <dP> if so you can just compare random state on some big cdist game
15:24:35 <michi_cc[d]> Well, I do change the edge iteration order, so there might be tiny differences in the calculated flow values.
15:24:36 <Rubidium> tests are in any case on some spectrum from unit test to integration test and further. So what is exactly an unit is as easy to define as when something becomes a mountain from a hill
15:25:39 <michi_cc[d]> MCF is a global algorithm, so no mathematically depending on edge order, but of course with discrete numbers order still has some influence.
15:25:49 <Rubidium> so, maybe the term unit test is not the best but rather an automated test, like OpenTTD's AI regression tests
15:30:32 <glx[d]> And regression tests are far from complete
15:31:02 <LordAro> they get us about 5% test coverage, as i recall
15:31:11 <glx[d]> But they get improved sometimes
15:31:33 <michi_cc[d]> Okay, that was not what I wanted to do 😦
15:34:01 <Eddi|zuHause> clicking a wrong button on github is easy if you're not using it regularly
15:36:52 <dP> also regression tests depend on random state
15:36:55 <andythenorth> unit tests FTW, test-driven design less so
15:37:01 <andythenorth> also 100% test coverage, less so
15:37:27 <andythenorth> also...the same type of software engineers whose code is being tested for mistakes also write the unit tests
15:37:33 <andythenorth> even if it's a different person / group
15:37:44 <andythenorth> so the mistake rate in unit tests is about the same as the mistake rate in the tested code
15:38:15 <andythenorth> the main advantage of unit tests is they are usually very fast and can run on every check in, and can be parallelised
15:38:20 <andythenorth> so they are a good canary
15:40:22 <andythenorth> integration tests are in my experience much more useful, and give a lot more confidence about the real application, but require a lot more set up / tear down and can be slow
15:40:53 <andythenorth> and if it's not a monolithic application, integration tests can involve building a full environment and running all processes / workers / microservices etc
15:41:08 <andythenorth> and nerfing anything that might call to risky external services etc
15:41:38 * andythenorth stops monologue sorry, my newsletter is available, I have 0 subscribers though
15:43:16 <petern> You then write tests to ensure your mocking is correct...
15:43:29 <andythenorth> so now your mock is actually critical path software
15:44:14 <andythenorth> if the application has a UI, I've found visual diff the most powerful QA tool on effort/reward
15:45:27 <LordAro> difficult to automate though
15:45:58 <LordAro> the most common one we have is "windows decided to lock the screen"
15:47:59 <nielsm> xkcd-spacebar-heating.png
15:48:14 <TonyPixel> If I have two vehicles with some overlapping refit options, but they have different cargo subtype ids, they will not support simultaneous refit to this subtype. Is there a way to hack this?
15:49:10 <TonyPixel> Variants are for variants, not for liveries
15:50:35 <TonyPixel> Well it's not guaranteed to be a hack, so I'm fine with that
15:51:02 <petern> Use the same subtype id. Possibly it can match by string id but I'm not sure.
15:51:32 <TonyPixel> As example, I have one vehicle with liveries 1, 2 and 3
15:51:38 <TonyPixel> and another one with 2 and 3
15:51:59 <TonyPixel> If I use same ids for every livery, second vehicle will skip one id
15:52:03 <TonyPixel> Then callback will fail
15:52:13 <TonyPixel> And it won't reach liveries 2 and 3
15:52:59 <TonyPixel> what if I place something like 10: CB_RESULT_NO_TEXT
15:53:11 <TonyPixel> I think that won't work but I'll try
15:54:02 <petern> I believe as long as the string itself is the same the subtype number shouldn't matter.
15:54:15 <TonyPixel> Strings are the same
15:54:29 <TonyPixel> but it does not recognise them I think
15:54:33 <petern> The refit option list, when checking for dupes, specifically checks for cargo type and string, not subtype.
15:54:52 <petern> Whether that translates to actually refitting them is another matter though.
15:54:55 <TonyPixel> That's strange then
15:56:03 <Eddi|zuHause> IIRC cargo subtypes must be sequential, you can't skip one
15:56:03 <petern> Yeah refit command itself goes by subtype id so no.
15:56:36 <TonyPixel> Yes, Eddi, I know, it goes up until CB_..._NO_TEXT or fail
15:58:10 <TonyPixel> Is it possible to code some value you can return for subtype ids for the game to skip them?
15:59:43 <petern> It'll probably still appear as an entry, just with no name.
15:59:45 <TonyPixel> Nah, that would just leave empty variant
16:00:15 <TonyPixel> You removed ability to say "variant" and not mean "those" variants
16:00:32 <petern> Removing your freespeech rights
16:00:45 <TonyPixel> More like adding confusion
16:01:41 <petern> You could call them, hmm, I dunno... refits?
16:02:23 <TonyPixel> I meant refit variant
16:02:28 <TonyPixel> That's not the point
16:04:29 <TonyPixel> Well, it does not hurt me that much, but it would be cooler if that was possible
16:07:42 <petern> Hmm, conditional strings
16:09:14 <EmperorJake> It's janky, but most people are used to refitting engines and wagons separately by now
16:10:15 <TonyPixel> Well that would be nice if they could do it in one click
16:10:42 <TonyPixel> Add and check for another constant, can't say it's easy but that couldn't be so hard to implement
16:10:58 <petern> Reorder them so that so the common subtypes come first?
16:12:09 <TonyPixel> Firstly, they appear depending on date, secondly, that would be stupid and won't work too well, because there will be a variety of them
16:12:59 <TonyPixel> That's not really of a problem
16:15:43 <Gwyd> You could do it so the cargo refit order depends on leading engine/other vehicles in consists TonyPixel
16:15:50 <Gwyd> Complex but nice for the end user
16:16:39 <TonyPixel> That would break the order anyway
16:17:15 <TonyPixel> Because As example, F40PH loco has phases 2 to 5, and metroliner cab car only has 3 to 5
16:17:26 <TonyPixel> So it would be 3 4 5 2 on F40PH
16:17:35 <petern> The livery would change when you move wagons around.
16:17:54 <TonyPixel> I'll stick to current path
16:18:09 *** TROILUS4 has joined #openttd
16:19:38 *** TROILUS has quit IRC (Remote host closed the connection)
16:19:38 *** TROILUS4 is now known as TROILUS
16:23:16 <TonyPixel> That would be nice, but only after 16th
16:23:26 <TonyPixel> I have finals to finalise
16:23:37 <Eddi|zuHause> TonyPixel: just ditch cargo subtype and make variants
16:24:04 <TonyPixel> You don't seduce me devil
16:25:05 <Eddi|zuHause> cargo subtype is a remnant from another time, and people demand too much of it
16:32:14 <andythenorth> LordAro: it's fine for web apps, there are established frameworks 🙂
16:34:15 <Eddi|zuHause> TonyPixel: the other vari... option is to use wagon override *shudder*
16:34:55 <TonyPixel> Player should be able to choose, that's why it's not an option
16:35:17 <Eddi|zuHause> but really. choose the future... variants
16:39:19 <TonyPixel> They don't work here man
16:41:30 <andythenorth> ctrl-click to choose livery
16:41:42 <andythenorth> when is my counter byte appearing?
16:42:42 <Eddi|zuHause> what's not working with variants?
16:43:08 <Fairy> I think variants are cool and I intend to try and implement them in my UKRS2 rework
16:47:25 <supermop_toil> i had to email a scanned credit card form for a purchase order today
16:48:16 <supermop_toil> and accidentally put a typo in the email address, so lets hope no one gets that pdf with my credit card number and address
16:48:52 <andythenorth> I always enjoy ID verification where I have to email a scan of my passport
16:48:53 <supermop_toil> some old school machine shop in New Jersey that doesn't have any more sensible way to receive payment
16:49:07 <andythenorth> 'definitely email is secure, and now nobody could ever impersonate me'
16:49:28 <andythenorth> usually it's for something trivial like financial services or company regulation
16:49:49 * andythenorth wonders how email works now
16:50:02 <andythenorth> is it all split into packets going different ways?
16:50:29 <andythenorth> or is it like the old days when the complete message would be relayed via multiple mail servers operated by various ISPs
16:50:31 <Rubidium> andythenorth: I have sent a scan of a passport once, but I masked everything that was not reasonable for them to know so they only got my name... and it got accepted
16:50:37 <andythenorth> and stored to disk at each stage...
16:50:55 <supermop_toil> hoped i'd get a bounce back that the typo'd email address in undeliverable
16:51:28 <supermop_toil> Rubidium: i should have sent this guy my credit card number with the number masked out...
16:52:14 <petern> andythenorth: These days it'll either just stay within gmail, or stay within microsoft365...
16:52:37 <andythenorth> I remember learning that our company ISP could read all our email
16:52:40 <petern> But otherwise email is generally point-to-point, not bounced around all over the place.
16:52:43 <andythenorth> that was exciting
16:53:15 <petern> "We host your email so we can read it" is probably not that surprising...?
16:53:33 <petern> There was a Reddit post about that recently.
16:54:24 <andythenorth> it was a learnign
16:55:24 <andythenorth> I am trying to unsee the subtypes questions 😛
16:55:34 <andythenorth> brings back memories
16:56:15 <andythenorth> didn't it used to literally key on strings or something?
16:56:23 <andythenorth> so the subtype matched if the string matched?
16:56:55 <andythenorth> /me still uses subtypes though
16:57:19 <andythenorth> possibly should delete those
16:58:07 <petern> Something about autoreplace checks for the string, I think.
16:58:13 <petern> But simple refit, apparently not.
16:59:58 <andythenorth> wonder if the community will split over the issue
17:00:02 <andythenorth> I will register a new forum
17:00:10 <andythenorth> approved members only
17:00:41 <supermop_toil> who doesn't like variants?
17:00:46 <TonyPixel> did simuscape appear as a part of community that disagreed with some issue?
17:00:55 <supermop_toil> or what is the reasoning against them?
17:00:58 <andythenorth> but it was accompanied by drama
17:01:03 <andythenorth> supermop just taste I think
17:01:09 <petern> Simuscape disagreed with releasing anything, I think.
17:02:03 <supermop_toil> andythenorth: but like "i don't want any other liveries on my trains" or something else?
17:02:29 <supermop_toil> because in that case just dont use the variants?
17:02:36 <andythenorth> Simuscape was an attempt to create a safe space, but unfortunately it attracted the kind of people who make a safe space unsafe
17:02:52 <andythenorth> that is all I should say about
17:03:13 <supermop_toil> never went there, not interested
17:03:40 <andythenorth> supermop not going to try and rationalise taste 🙂 Some people inherently love subtype refits, and it has been presented for a long time as the official livery spec
17:03:49 <supermop_toil> andythenorth: or is the complaint "i want a separate train for each and every livery"
17:04:11 <andythenorth> copy-paste code gains an authority of its own over time 🙂
17:04:14 <supermop_toil> andythenorth: they can just use those in their own grf right?
17:04:16 <Gwyd> Nobody is against variants as a feature, but I dislike selling and rebuying a train to repaint it
17:04:44 <TonyPixel> That's why I tend to use refits over variants for that
17:04:48 <andythenorth> that is the pithy articulation
17:05:09 <Gwyd> I like the idea of organising slight variations of the same train as, well, variants
17:05:22 <TonyPixel> It would actually be nice
17:05:44 <TonyPixel> I can do them as variants
17:06:00 <TonyPixel> Or eleven thousand of F40PH rebuilds as variants
17:06:14 <supermop_toil> ^ then code your grf that way? it seems the argument as pertains to horse is odd because before, horse had no livery variations, then later it has liveries only through arcane color combinations
17:06:32 <andythenorth> nobody is really arguing against variants now
17:06:38 <supermop_toil> and now it has some liveries where before it did not, so what's the problem?
17:06:38 <andythenorth> those who were agreed to stop I think
17:06:43 <TonyPixel> nobody were then too
17:06:54 <andythenorth> nah there were definite objections to the feature, but eh
17:07:00 <supermop_toil> looking the iron horse in the mouth?
17:07:23 <andythenorth> if someone PRs 'repaint to a variant' as an 'autorepaint' GUI
17:07:28 <andythenorth> then all needs are met
17:07:46 <andythenorth> can have a basecost for the cost of that
17:08:39 <Gwyd> I mean sure I can simply not make my grfs like that but it's also my perspective as a player
17:11:17 <andythenorth> well in future, we can have more like this (and every other game I've seen do this)
17:11:23 <andythenorth> choose vehicle -> choose livery
17:11:42 <dP> hm, i have an engine with track_type RAIL but elecric engine_class and it's not showing up in the regular rail depot until I run `reloadnewgrfs`
17:11:48 <dP> is that a bug or somehow a feature?
17:13:08 <andythenorth> not actually sure that UI would be better for building a lot of trains though
17:13:12 <andythenorth> choose wagon -> choose livery
17:14:12 <supermop_toil> every train should be bare metal, and in-game paint tool to paint each one
17:14:36 <supermop_toil> no copy paste. if you want your trains to match, you have to have a steady hand
17:14:46 <supermop_toil> and if you don't paint them they rust out
17:15:26 <andythenorth> see also: Budd stainless steel cars
17:15:36 <supermop_toil> those cost extra
17:16:24 <supermop_toil> budd provided their first stainless cars to NYC on spec - didn't charge more for stainless in hopes of winning the contract
17:16:48 <supermop_toil> but nyc didn't mandate stainless for all new orders until after budd went insolvent
17:17:01 <FLHerne> TonyPixel: andy is using variants for liveries and he literally invented the feature :p
17:17:34 <petern> dP: There's magic that puts electric into the electric rail type.
17:18:18 <petern> If you include a rail type translation table, this magic will be skipped.
17:18:30 <andythenorth> FLHerne: "it wasn't me"
17:18:36 <FLHerne> similarly, petern is the guy who implemented it and he's told you to use them too
17:18:47 <andythenorth> nah let authors do what they want
17:18:50 <petern> I'm not telling anyone what to use 🙂
17:18:52 <andythenorth> it's not like a religious issue 🙂
17:18:55 <FLHerne> they're kind of the definitive authority on what variants are(n't) "for"
17:19:12 <andythenorth> the joy of variants are they are for whatever players want
17:19:18 <andythenorth> players / authors /s
17:19:34 <andythenorth> they are quite unopinionated about right or wrong usage
17:19:45 <andythenorth> it's literally just a group
17:20:00 <andythenorth> with the nice side effects that engines and wagons can be put together, which wasn't possible before
17:20:08 <andythenorth> and that expiry and intro can also be synced
17:20:24 <andythenorth> and it all works with autoreplace with zero changes to how your space bar heats up the room
17:20:33 <dP> petern: but I have translation table
17:21:34 <petern> Ah then it's something else then
17:22:53 <supermop_toil> back in office but head full of ideas for shed bits to draw
17:27:18 <pickpacket> is there a NewGRF that introduces replacements for fossil fuel industries?
17:28:25 <andythenorth> FIRS had an animated windfarm
17:28:30 <andythenorth> but it was never used in a release
17:28:43 <andythenorth> there is RUKTS nuclear add on
17:28:56 <supermop_toil> power doesn't really do anything yet, so there isn't much to replace powerplants with
17:29:29 <andythenorth> Zephryis drew that, it's good
17:29:53 <andythenorth> it can rotate to the wind angle 🙂
17:30:13 <supermop_toil> but its certainly possible to make a grf that phases them out over time
17:30:43 <andythenorth> dP: wrote a GS that places pylons between power plants
17:31:30 <supermop_toil> it would be neat to make the phase out depend on the progress of supplying non-fossil fuel generation
17:33:06 <supermop_toil> as is from the player perspective, there is little incentive - you have a vested interest in watching your cute coal trains run back and forth
17:33:27 <supermop_toil> whereas there is not much for a train to do at a windmill
17:34:07 <andythenorth> could deliver wind turbine parts
17:34:15 <andythenorth> I had a sort of plan for it
17:34:27 <andythenorth> and if the industry generates power to the grid
17:34:41 <supermop_toil> if power boosts town or industry production though then it becomes a neat puzzle to meet that demand by different means
17:35:06 <FLHerne> there's a grf with wind turbines as NewObjects so you can build them to look nice
17:35:58 <FLHerne> for "new green industries" more generally FIRS does have the Recycling Plant or whatever it's called
17:36:05 <supermop_toil> andythenorth: most powerplants only need heavy machinery parts delivered like once a year or less, which may or may not be fun?
17:36:17 <petern> Transport electricity via vehicles...
17:36:24 <andythenorth> yes but you get cool vehicles supermop 🙂
17:36:32 *** Thomas[d] has joined #openttd
17:36:32 <Thomas[d]> or even better with the wind turbines
17:36:43 <supermop_toil> yes a need for all those superheavy transformer cars
17:36:49 <FLHerne> petern: pretty sure that exists already
17:36:57 <FLHerne> there was some grf with little sparks as locomotives
17:37:12 <andythenorth> electricity can be done via GS, I just didn't write a GS
17:37:12 <supermop_toil> so i think that makes it more fun that just dumping hundreds of tons of coal every week
17:37:21 <andythenorth> because developing GS is horrorshow 🙂
17:37:31 <supermop_toil> although the coal plant also needs new turbine blades and transformers
17:38:04 <andythenorth> already possible 😛
17:38:17 <andythenorth> just write GS libraries and have an agreement on common entry point
17:38:24 <andythenorth> 'co-operative multi-tasking'
17:38:24 <supermop_toil> maybe the plant needs 1-10 years of bdmt and heavy equipment deliveries before it goes online
17:38:26 <petern> That is still just one GS.
17:38:50 <andythenorth> I never figured out whether GS is achingly slow
17:38:59 <andythenorth> drawing pixels is easier
17:39:21 <andythenorth> 2025: the year FIRS GS v0.5 is released
17:40:37 <andythenorth> needs a standardised emoji
17:44:02 <pickpacket> supermop_toil, andythenorth: I'd love something that phases out coal and oil over time, but the question is what to replace them with
17:44:35 <andythenorth> if it's IRL, wind and solar
17:45:15 <andythenorth> if it's imaginary future, add wave power and fusion
17:45:47 <andythenorth> we could do dammed hydro, but it would be very difficult to simulate
17:46:18 <pickpacket> Wind and solar would be nice, but how would you make industries of them? Hard to deliver sun or wind
17:47:10 *** gelignite has joined #openttd
17:47:20 <pickpacket> I have an idea that there could be rare earth metal mines, and the metals are transported to a battery factory, and batteries are transported to solar and wind farms
17:47:36 <andythenorth> collect livestock from the solar farms
17:47:43 <andythenorth> to keep the grass down
17:47:53 <andythenorth> and deliver cleaning agents (soap)
17:48:15 *** wallabra has quit IRC (Ping timeout: 480 seconds)
17:48:23 *** wallabra has joined #openttd
17:49:06 <MnHebi> in fact, just make a solar farm popping up launch Factorio.
17:50:37 <pickpacket> hmmm... burning livestock would be carbon neutral, right?
17:52:06 <supermop_toil> chucking the sheep down the now-empty coal mines is carbon negative
17:52:33 <pickpacket> btw I've noticed that there are some strange flags available for industries. Such as "The industry can be exploded by a military airplane"
17:52:56 <supermop_toil> probably should apply to most industries, in real life
17:54:04 <supermop_toil> really most things can be exploded by a military airplane if you bring enough actinides along
17:55:29 <FLHerne> pickpacket: for some reason, the original Microprose TTD had a disaster where oil refineries are occasionally exploded by a military airplane
17:55:56 <FLHerne> and lets NewGRF industries opt into it because yay random flags
17:56:12 <FLHerne> occasionally people suggest NewGRF or GS-driven disasters
17:56:29 <FLHerne> but no-one cares enough
18:07:21 <pickpacket> it's not an RTS game, after all
18:28:38 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:30:46 *** Wormnest has joined #openttd
18:45:53 <DorpsGek> - Update: Translations from eints (by translators)
18:54:10 <Pruple> pickpacket: this is basically reason 7 why "1900-2000" is the correct time frame for OpenTTD gameplay 😛
18:55:01 <pickpacket> Pruple: I'd love the default to at least be starting in 1900
18:55:26 <pickpacket> with ships and trains that are actually useful, and trams
18:56:07 <Pruple> with slightly-credibility-stretching zellepins, you can even have aircraft in 1900, which you can't do if you start any earlier
18:59:27 <Pruple> 1900-2000 makes oil refineries and power plants at least somewhat sensible for the whole game, gives you steam -> diesel transition mid-game, it's perfect.
19:03:42 *** greeter has quit IRC (Remote host closed the connection)
19:03:57 <EmperorJake> pickpacket: Firs3 extreme and XIS also have a biorefinery. XIS power plant accepts biomass waste too
19:05:04 <nielsm> just to compare with another game, one thing I like about Transport Fever 2 is how it has a clear change of cost-effective transport modes throughout the game. the distance where trucks are better value increases gradually, forcing you to convert shorter early routes from train to truck, and also occasionally rebuild the rail network when straighter track becomes more cost-effective
19:11:02 *** greeter has joined #openttd
19:12:18 <TrueBrain> so that is what that button does 😛
19:14:08 <TrueBrain> TallTyler: : don't you just love the energy of our translators? 😄 I really like it now became a habbit of reporting in when you did your language 🙂
19:15:48 <andythenorth> Pruple: 💯 except 1920-2020
19:19:52 <Pruple> andythenorth: this is also valid, but I like my WWI-era steam locos more than my 21st century powerhaulers. As locos become more powerful the differences between them become less significant for TTD gameplay (reason 4?)
19:20:19 <andythenorth> Pruple: class 66 for everything
19:20:28 <andythenorth> it's frosch again 🙂
19:22:49 <frosch> discord tells me moderators need to have 2FA enabled, and it thus disables mod powers. is it okay to keep that status, if i do not need mod powers?
19:22:53 <petern> frosch: Another 10 year old patch strikes again
19:23:13 <frosch> not yet, there is a month left
19:23:32 <andythenorth> can we combine 'driving backwards' and 'ctrl-click to flip articulated vehicles' 😛
19:24:14 <frosch> in that branch (which probably no longer compiles) all trains reverse driving directions when turning around
19:24:39 <frosch> there was meant to be some newgrf flag to choose between "drive backwards" or "use magic to turn the consist"
19:27:47 <Olionkey> frosch: should be fine but you shouldn't have the need to enable 2fa in the beginning for mod as you are not one
19:28:23 <frosch> ok, weird that it tells me then 🙂
19:28:29 <TrueBrain> so we now all know to target frosch to compromise his Discord to get dirty details out of us 😛
19:28:33 <Olionkey> might have gave you ugys access for something
19:28:37 <TrueBrain> (just kidding, to be clear :D)
19:28:46 <Olionkey> where discord thinks you should have it
19:29:25 <frosch> TrueBrain: i used your password, assuming it must be good
19:29:37 <TrueBrain> then all is well, it is really strong
19:29:43 <TrueBrain> like, "really strong" is my password
19:29:57 <EmperorJake> andythenorth: Transport fever style train reversing would be ideal
19:30:04 <TrueBrain> Rubidium: some CodeQL findings are impressive .. like ... "this variable is not ranged checked, and read from user space .. potentially it could overflow" .. with a 14 deep path to come to that conclusion 😄
19:30:20 <Olionkey> if anything it might just be regards of Discord channel #development-forum or Discord channel #announcements where in announcements you can do the @ everyone and development forum you can pin messages.
19:34:52 <TallTyler> frosch: Not even close to compiling 😉 `The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found.`
19:35:09 <TallTyler> Maybe I'm brave enough to try rebasing...but also maybe not
19:36:57 <frosch> most of the diffs seem to be about removing "tile" from commands, which do not need it.
19:37:13 <frosch> maybe that stuff is already done now, but it certainly would not merge well
19:38:10 <TallTyler> Eh, I'll have to rebase eventually anyway. Only four files have conflicts and none of them are saveload stuff, so maybe it won't be that painful 🙂
19:39:44 <TallTyler> I wonder if giving the players an explicit Reverse order, added using the dropdown where conditional orders are found, would be the best way to avoid pathfinding misery - unless said order is given, the train can do the magic flip if needed, and if the order is given it forcibly drives the opposite direction
19:39:53 <TallTyler> Something to try, perhaps
19:40:45 <frosch> back in the day, realism freaks would want stuff like different speeds for forward/reverse
19:41:28 <Pruple> tbh, trains driving backwards is so situational that I doubt this feature can be made sensible at all 🙂
19:41:43 <TallTyler> Reusing depot speed seems like an easy way to avoid that argument
19:41:52 <TallTyler> "You get what we give you, otherwise PRs accepted"
19:42:13 <Pruple> in the cases where it makes sense, current newgrf hacks work (well enough?)
19:42:19 <TallTyler> I actually want to use it for freight trains as much as I do push-pull trains
19:42:58 <TallTyler> But having worked on a real railroad I've spent so much time turning trains on wyes or shoving several miles to get to the right place facing the right direction that perhaps my perception is screwed
19:43:49 <TallTyler> Hmm, last time I did a big shove move it didn't end well
19:43:51 <Pruple> if you're going for "realistic operations" replacing magic flip, then you also need detaching locos 😛
19:44:18 <supermop_toil> Pruple: karn shunting patch has those
19:45:15 <TallTyler> I've played with the full shunting patch, and IMO designing a UI/workflow to give the right orders is improbable, maybe not impossible
19:45:19 <frosch> i mostly had the emu/dmu use-case in mind, while preserving/reversing wagon order
19:45:34 <supermop_toil> though you end up needing to really rethink the amount of space you give for headshunts and sidings, and the amount of time a train spends at an industrial station
19:46:04 <supermop_toil> so you often end up getting lazy and building balloon loops anyway
19:46:11 <frosch> just because newgrf hacks exist, is no reason to keep things hard for future generations :p
19:47:29 <supermop_toil> but a long time ago, Eddi|zuHause had the suggestion that emus, and double headed trains could leave immediately by reversing at a terminus, but other trains would still be able to magically flip, but with a time penalty
19:48:02 <TallTyler> A lot of the rebase seems to be `you changed something, but since then NULL became nullptr` so it's quite easy to resolve the conflict 😄
19:48:10 <Pruple> the newgrf hacks are good for specific cases, generalising the feature in a way that makes sense doesn't seem plausible (to me)
19:48:23 <Eddi|zuHause> supermop_toil: that was about the same time as frosch said "that's too complicated, take this simple solution or leave it"
19:48:34 <Pruple> but then, I'm currently writing deflipping code for train sets, so perhaps my view is skewed by not wanting this effort to be pointless 😛
19:49:12 <supermop_toil> currently a rail vehicle can lead an consist if it is an 'engine' meaning it has some HP
19:50:10 <supermop_toil> i always imagines thinking of that flag more like 'this vehicle has a driving cab'
19:50:21 <TallTyler> Can't non-engines have HP though?
19:50:39 <TallTyler> (has not done much vehicle NewGRF)
19:50:45 <supermop_toil> they aren't coded as 'engines' afaik
19:51:21 <supermop_toil> that's not really relevant to what i'm saying though
19:51:39 <supermop_toil> im saying think of the engine flag as 'has a cab' flag
19:52:09 <supermop_toil> and just as a train needs a vehicle with that flag at the front, if it has one at the rear it can also go backwards
19:52:51 <supermop_toil> ideally a cab/leading vehicle only would need that flag, and would be allowed to have 0hp
19:53:43 <TallTyler> If the leading vehicle has that flag, it can go full speed, otherwise it goes slower?
19:53:58 <TallTyler> How are DVTs coded in Horse?
19:54:04 <supermop_toil> the are engines
19:54:10 <supermop_toil> they have like 1hp
19:55:28 <supermop_toil> ideally yes, you could let trains shunt at low speed without a cab forward, but i'd settle for a simpler method of just "if cab, can go this way"
19:56:51 <supermop_toil> that would also let you have a train that is [steam engine][tender][short tank wagon][long flat car][small diesel] reverse with all the cars/lengths in the right order
19:57:27 <supermop_toil> and no arcane newgrf magic to redraw the cars as others to look right
19:58:59 <petern> Not reversing would fix all the horrible non-working reversing hacks we do at the moment 🙂
19:59:12 <TallTyler> I want low-speed reversing without a cab in front 🙂
19:59:28 <petern> I still want to experiment with new movement code though.
20:00:16 <petern> Ah... I never use that setting.
20:01:10 <dP> if it's on everything is rightfully switched to regular rail
20:01:33 <andythenorth> externalise the consist
20:01:38 <andythenorth> put the HP etc there 😛
20:01:45 <andythenorth> units are just units within it
20:01:53 <andythenorth> words are easy to say
20:02:28 <petern> Yeah, we'll need to store the original rail type instead of just assuming it. Hmm.
20:03:16 <petern> Or just remove that setting? 😄
20:03:29 <petern> (Break old savegames, sure...)
20:05:33 <dP> it's a very useful setting
20:05:41 <dP> unless you want to remove elrail xD
20:08:16 <petern> I mean, it doesn't work with newgrf railtypes so...
20:09:59 <TallTyler> Oh, the rebase goes commit by commit... I knew it was too easy, because there's five more commits to go 🙂
20:11:10 <dP> I don't think anyone significantly changed movement code in 10 years so you still may get lucky xD
20:16:45 *** gelignite has quit IRC (Quit: Stay safe!)
20:30:00 <petern> I should probably compile this before making a PR?
20:31:15 <dP> why bother, ci will compile xD
20:36:51 <glx[d]> TallTyler: there is a savegame bump 😉
20:39:47 <petern> For really old branches, I find it easier to cherry-pick commit by commit.
20:41:09 <petern> Not much difference really overall but with rebase you are forced into fixing it all at once. Cherrypick you can take your time and reset more easily without wiping out all the work you've done so far.
20:47:28 <andythenorth> ok so how would auto-repaint work then? 🙂
20:47:47 <andythenorth> is it a mode for auto-replace UI or what?
20:47:58 <andythenorth> it needs to only show vehicles that can be replaced to a variant
20:48:08 <andythenorth> and it needs to only allow replacing to their variants
20:48:13 <dP> PeterNviaGitHub: old_railtype variable seems kinda pointless
20:48:19 <andythenorth> and it needs a reduced cost and to copy vehicle age etc
20:48:34 <dP> also this comment is weird now "if it is an electric rail engine and its railtype is the wrong one "
20:49:36 <dP> imo can be just removed along with old_railtype as that will make that if pretty self-explanatory
20:51:30 <Pruple> andythenorth: The player "repaints" their locos by changing cc. Or the newgrf automatically updates the livery based on year (or date of last service + random factor, as UKRS2 did, but that doesn't work with breakdowns off). Or you use cargo subtypes.
20:52:10 <Pruple> "replace one vehicle with another vehicle in a non-standard way" is not a feature we need imo.
20:53:04 <andythenorth> no I have nothing 😛
20:53:40 <andythenorth> it seems quite an interesting exploit
20:53:59 <andythenorth> I could replace your single 91 to a dual head 91
20:54:05 <andythenorth> and it would be just a repaint
20:54:10 <andythenorth> so it would be free
20:54:29 <andythenorth> I could buy a trailer car for Horse HST
20:54:34 <andythenorth> and replace it to the power car for free
20:54:54 <Pruple> yeah, that's the problem with the idea... it assumes "variant" means "repaint". 😛
20:55:03 <andythenorth> exploits are good
20:55:49 <andythenorth> so did anyone design how liveries should work yet then?
20:56:59 <Pruple> they're either decided by newgrf logic, or by the player picking a variant, or some combination of the two. 😛
20:59:57 <andythenorth> what if there's a special depot type?
21:00:07 <andythenorth> and you have to send trains to it
21:00:15 <andythenorth> then you get free repaints
21:00:23 <andythenorth> but only to variants where the stats exactly match?
21:02:09 <Pruple> tie each livery pattern to specific company colours, that way you can change the livery just by changing CC 😉
21:02:32 <Pruple> this would be good features for amerihorse / nars3 tbh
21:03:49 <supermop_toil> rails were shipped in from germany
21:04:23 <TallTyler> Rebasing finished, I think. Let's try building 🙂
21:04:48 <andythenorth> Pruple: sounds mad, who would ever do that? 😛
21:06:43 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:08:56 <nielsm> possibly bad idea: "road vehicle manufacturers refuse selling you more vehicles due to the large number of recent accidents with brand new vehicles", "vehicle drivers are striking due to perceived danger working for your company"
21:09:08 <EmperorJake> andythenorth: Not as mad as the one time where the liveries you got depended on the company number...
21:10:06 <nielsm> (there is no defense against griefing other than human intervention)
21:10:23 <dP> nielsm: if rvs breaking trains would need to be an option either way
21:10:37 <dP> even one rv can ruin someones game if timed well
21:11:53 <dP> though I guess it can be the same breakdowns option
21:14:24 <dP> also, one can always buy a bunch of rvs in advance ;)
21:16:29 <nielsm> I don't like the idea of rv wrecks being instant ghosts, but I suppose I'd be fine with an option like, "Train-road vehicle collision behaviour": "train continues, road vehicle wreck blocks road for a while" / "train breaks down, road vehicle wreck blocks road for a while" / "train continues, road remains passable"
21:17:32 <supermop_toil> "the board of directors has removed you and filed a report with the police"
21:18:01 <supermop_toil> "local authority has had you committed for criminal insanity"
21:18:08 <dP> supermop_toil: that is kind of already happening on some servers xD
21:18:34 <Eddi|zuHause> i'd like a feature that upon despawning crashed vehicles, automatically buys a replacement in the nearest reachable depot/hangar
21:18:54 <andythenorth> along with removing disasters, breakdowns, reliability 😛
21:19:00 <supermop_toil> you cannot quite the server or game, instead you spend the next 80 in-game years staring at a screen of a cell
21:19:06 <nielsm> you could assign blame for terrorism by checking if either the train or the road vehicle was started recently or has been running for a long time (I don't think the "date player clicked start on the vehicle" is stored anywhere)
21:19:20 <dP> Eddi|zuHause: oh, yes please, also buy large advertisement at the nearest town xD
21:19:43 <dP> using short runways would be less annoying xD
21:19:50 <Eddi|zuHause> dP: i'm fine with the rating hit and stuff, that's going to fix itself over time
21:19:56 <nielsm> right, add a fourth option to the setting proposed above: "trains and road vehicles do not collide"
21:20:38 <nielsm> (meaning that level crossings still cause blockage of the road while a train is passing, but nothing happens if train and rv touch each other)
21:20:45 <Eddi|zuHause> dP: but the micromanagement if you miss the crash and 2 hours later you try to find out which route is missing a vehicle
21:21:20 <Eddi|zuHause> nielsm: imho "no crashes" should be a cheat
21:21:39 <dP> no setting should be a cheat :p
21:21:40 <nielsm> I think that's what transport fever does
21:21:52 <Eddi|zuHause> similar to no plane crashes
21:22:38 <dP> cheats should be active, making settings into cheats just makes them inconvenient
21:24:14 <Eddi|zuHause> dP: cheats and settings are functionally the same thing, except for the multiplayer and the guilt aspects
21:24:45 <Pruple> "give me $20m" is not a setting
21:24:47 <nielsm> disabling train/rv crashes tbh is the best technical workaround to griefing
21:25:16 <Pruple> magic bulldozer is something you don't normally want on, so it makes sense to go in the cheat menu
21:25:35 <Pruple> I agree, no plane crashes should be moved to settings
21:25:39 <FLHerne> nielsm/Pruple: I just wrote a patch that stops RVs entering a crossing if there's a crashed vehicle on it
21:25:43 <dP> nielsm: yeah, maybe a good solution, not all griefing though, just a bit of it
21:25:48 <FLHerne> does that make sense to you?
21:25:57 <FLHerne> it seems less cheaty than phasing through them
21:26:17 <FLHerne> (will PR it when I've ironed out the stupid glitch)
21:26:19 <dP> Pruple: I run servers with magic bulldozer on xD
21:26:24 <Pruple> I think that would go a long way to fixing the problem with multiple crossings, yes. so vehicles don't just queue up to get smashed 🙂
21:27:36 <FLHerne> Pruple: "give me $20m" is effectively a "money doesn't apply" setting
21:27:36 <Pruple> dP: I never leave it on, don't want to butterfinger the industry when rebuilding the station 😛
21:27:44 <FLHerne> and would be more convenient as such
21:28:27 <dP> Pruple: rebuild with r mode :p
21:28:31 <FLHerne> no-one clicks it once and would say "yeah, I just needed $20m to get the company going, but that's a one-off"
21:28:41 <FLHerne> if it was $100k or something it could be used that way
21:28:58 <dP> also, tbf server still denies most of the magic, it's mostly there for disabling authorities
21:29:08 <Pruple> FLHerne: people testing newgrfs use it to build a bunch of vehicles, but they don't want it on when actually playing the game for real 🙂
21:29:09 <dP> can probably even turn it off with recent changes
21:29:26 *** Wormnest has joined #openttd
21:29:30 <FLHerne> Pruple: settings profiles like NewGRF profiles? :D
21:30:03 <Pruple> or just ctrl-alt-c-click when I'm testing and need more money 🙂
21:30:53 <dP> infinite mode would make a fine "creative" mode setting
21:31:25 <nielsm> GS that resets your money once in a while
21:31:36 <nielsm> (along with eternal love)
21:31:58 <dP> gs is cumbersome considering it's often used for testing
21:32:28 <dP> actually, should probbaly increase amount of cheated money in cmclient)))
21:32:35 <dP> or even turn it into a setting
21:32:41 <dP> it's not multiplayer anyway
21:33:38 <petern> Hmm, okay. More changes.
21:34:30 <Pruple> nielsm: "eternal love" is now a setting 😛
21:40:14 <andythenorth> Pruple: what was I doing again?
21:40:18 <andythenorth> playing art of rally?
21:41:22 <Pruple> you were also suggesting that a (de-via-36)powered brakevan variant to allow composing silly freight trains is a fantastic idea and all train sets should have one
21:42:33 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:43:45 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:44:32 <andythenorth> I was going to add 10 HP to Horse brake vans
21:44:39 <andythenorth> for propelling moves
21:44:45 <andythenorth> is that a thing now?
21:45:02 <andythenorth> like a snowplough
21:45:17 <andythenorth> "brake vans add power to your train, just don't ask"
21:45:33 <andythenorth> I mean....net, the effect is the same
21:45:53 <Pruple> can't you remove the power again with cb36? that's my plan
21:45:55 <supermop_toil> andythenorth: the brakeman gets out and pushes?
21:46:12 <andythenorth> I was going to say IRL trains with brake vans can go faster
21:46:16 <andythenorth> but that's actually opposite of true
21:46:20 <andythenorth> similar to a lie
21:46:25 <Pruple> especially if the brakes are on
21:46:37 <andythenorth> well if you go up a hill and down a hill it might be net the same
21:46:54 <andythenorth> no, I can't make it work 😛
21:47:19 <andythenorth> IRL trains with brake vans are unfitted crap and travel at 30mph, at least in UK
21:47:24 <Eddi|zuHause> if you give the brake van HP it'll be an engine. you need to use the powered wagon callback
21:47:37 <andythenorth> it would be fine if it's an engine
21:47:42 <Pruple> Eddi|zuHause: that's the exact opposite of the point
21:47:49 <andythenorth> it's opposites day
21:48:05 <andythenorth> what if it's not opposites day, but I said it was?
21:48:22 <Pruple> it might have been, now it could be uncertainity day
21:48:35 <andythenorth> I am uncertain about that
21:48:38 <dP> what are you even trying to achieve by messing with brake van hp? xd
21:48:50 <andythenorth> what other goals are there?
21:51:21 <reldred> give it actual braking power? 👀
21:51:43 <reldred> I'd be fine with it appearing in engines if it did something useful
21:52:04 <dP> unlike acceleration, braking in openttd isn't very realistic
21:52:36 <andythenorth> brake type: air/vacuum/hope
21:52:42 <reldred> realisticbraking in jgrpp is bae
21:52:55 <reldred> do the kids still say bae these days?
21:53:02 <andythenorth> brake arrangement: 2 shoe, 4 shoe, disc, twin disc
21:53:03 <reldred> or is it all fr fr no cap?
21:53:17 <andythenorth> ventilated/forced ventilated disc
21:53:27 <andythenorth> speed of brake operation
21:53:30 <reldred> dP: with realistic braking and improved breakdowns one of the breakdown conditions is cooked brakes
21:53:37 <andythenorth> amount of continuous braking before brake fade
21:53:45 <reldred> doesn't result in any crashes though 😦
21:53:46 <andythenorth> risk of starting a lineside fire due to brake sparks
21:53:58 <andythenorth> amount of air in the reservoir and train line
21:54:08 <andythenorth> whether there's a separate recharge line
21:54:11 <reldred> especially with increased slope height percentage and freight weight multiplier
21:54:22 <andythenorth> time to propagate braking signals in long trains
21:54:47 <andythenorth> dual braking / triple braking, and interopability - some vehicles can act as converters
21:55:14 <andythenorth> propensity to slide on wet rail or leaf mulch etc
21:55:19 <andythenorth> fitment of sanding gear
21:55:31 <andythenorth> brake shoe / disk life, and need for servicing
21:55:43 <andythenorth> ok please make a PR
21:56:51 <dP> panic braking when someone painted rails black in the night :p
21:57:17 <andythenorth> whether brake lines freeze in winter, if moisture gets in
21:57:46 <andythenorth> we'll need a brake refit system as well
21:57:51 <andythenorth> can subtypes do it?
21:58:49 <TallTyler> andythenorth: It will be if I can bend Git to my will 😛
21:59:46 <andythenorth> EmperorJake: was it you who noticed Horse railcar trailers don't match the EMUs?
22:00:22 <EmperorJake> Oh yeah I seem to remember that
22:01:30 <andythenorth> can fix that now
22:01:34 <andythenorth> might add pantographs also
22:07:13 <EmperorJake> I can also do this now that DVTs are flippable
22:10:52 <supermop_toil> i like to put dvts on my DMUs
22:12:23 <andythenorth> dunno if it's more confusing or not, but I find it looks weird without the pans
22:19:52 <TallTyler> Definitely more confusing to me with pans
22:21:05 <FLHerne> I find it very odd without the pans
22:21:17 <FLHerne> with them it looks right
22:21:36 <FLHerne> without it looks like a DMU with weird red spots on the roof
22:21:57 <andythenorth> can always build diesel railcar trailers for those who don't like the pans 🙂
22:22:46 <andythenorth> EmperorJake: you have won
22:23:13 <EmperorJake> It's possible for a MU trailer to have pantos but no motors after all
22:23:31 <EmperorJake> andythenorth: what do I win? 😆
22:23:48 <andythenorth> pictures of motorail
22:25:46 <EmperorJake> How about SBB push pull with the loco in the middle?
22:28:16 *** Samu has quit IRC (Quit: Leaving)
22:35:54 *** wallabra_ has joined #openttd
22:37:41 *** wallabra has quit IRC (Ping timeout: 480 seconds)
22:37:41 *** wallabra_ is now known as wallabra
22:41:04 <Fairy> EmperorJake: Now we just need DMU/EMU power cars without the cab for seamless custom MUs
22:42:18 <andythenorth> nah I can't think of a quick fix 🙂
22:57:23 <andythenorth> Horse docs, 10 MB more file size to have wagon details pages
22:57:40 <andythenorth> my AWS bill this month was £0.81
23:01:23 <TallTyler> Rebased to current master and fixed to build properly. It works!
23:02:14 <andythenorth> have you tried it with any stupid newgrfs? 🙂
23:02:29 <TallTyler> Let's try that right now
23:02:36 <andythenorth> got the Variants edition?
23:03:03 <andythenorth> try snowploughs or something
23:03:28 <andythenorth> try dual head also, Blaze HST or similar
23:03:38 <andythenorth> dual head does weird things in OpenTTD sometimes
23:03:46 <andythenorth> it has weird handling of random bits and triggers
23:04:23 <TallTyler> reldred: I thought you might like that 😛
23:04:29 <reldred> TallTyler: Just merge it to trunk.
23:04:40 <andythenorth> reldred: some parameters changed, it might screw up wagon colours, dunno
23:04:42 <TallTyler> I want to make reversing an order instead of all trains doing it by default
23:04:44 <andythenorth> 'my game was fine'
23:05:01 <TallTyler> Easier to avoid screwing stuff up and having trains backing all over the place because they thought they found a faster route
23:05:11 <reldred> petern: can you collude with TallTyler to just ram that patch through plz
23:05:21 <TallTyler> Ha, let me finish it first
23:05:34 <andythenorth> patience grasshopper
23:05:36 <reldred> proper train reversing
23:05:45 <reldred> andythenorth: absolutely not
23:05:53 <andythenorth> the JFDI let's ship it route only works if the patch has been soak tested a bit
23:06:01 <andythenorth> otherwise people start putting gates and process in
23:06:19 <reldred> come on, I double dog dare ya
23:06:30 <petern> As long as it doesn't interfere with my plans 🦹
23:06:37 <reldred> okay, enough bullying, I have work to do 🙂
23:06:45 <reldred> I have a junior eng staring at me
23:07:04 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:07:24 <andythenorth> are gifs actually banned here?
23:07:28 <andythenorth> probably should be if not
23:11:20 *** wallabra_ has joined #openttd
23:12:30 <andythenorth> TallTyler: did you break it yet? 🙂
23:12:38 * andythenorth needs to go to bed
23:12:47 <TallTyler> DVTs work as intended, just building a Motorail train
23:13:03 <petern> I've got some epoxy curing, will that help?
23:13:36 <TallTyler> Vanilla HSTs work fine
23:14:21 *** wallabra has quit IRC (Ping timeout: 480 seconds)
23:14:34 <TallTyler> Not related to HSTs, just vehicles entering depots
23:14:45 <andythenorth> goes it crash? 😛
23:16:18 <petern> It means that applies if those bits are set.
23:16:50 <andythenorth> /me wonders why our docs are on my github 😛
23:16:56 <andythenorth> I guess that's my fork?
23:17:04 <TallTyler> Goes it crash indeed
23:17:19 <andythenorth> just don't confuse me with 'the maintainer' 😛
23:19:24 *** wallabra has joined #openttd
23:19:36 <andythenorth> hmm stupid railcar stuff
23:21:34 <TallTyler> Hmm, can't reproduce the crash
23:21:38 *** wallabra_ has quit IRC (Ping timeout: 480 seconds)
23:21:53 <andythenorth> "can't repro, fine to ship"
23:22:22 <TallTyler> I know exactly where it crashed, I just can't reproduce it for some reason
23:22:34 <TallTyler> `if (prev != nullptr) error("Disconnecting train");` when backing a train into a depot
23:25:13 <petern> I miss those disconnecting trains 😄
23:25:54 <TallTyler> Hmm, it still doesn't crash but going backwards it doesn't even try to enter the depot, just bounces off the end of track inside the depot
23:27:25 <TallTyler> Probably goes it fix tomorrow
23:28:12 <TallTyler> TallTyler: Here's the repo if anyone wants to fix it for me while I'm asleep 😛
23:28:26 <TallTyler> Or find other crashes, more likely
continue to next day ⏵
