IRC logs for #openttd on OFTC at 2022-10-08
⏴ go to previous day
00:04:49 <TallTyler> I think that’s JGRPP, which has a “ships avoid collisions” feature
00:51:13 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:52:55 *** WormnestAndroid has joined #openttd
01:40:59 *** Tirili has quit IRC (Ping timeout: 480 seconds)
02:23:26 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:29:09 *** Wormnest has quit IRC (Quit: Leaving)
03:55:49 *** _aD has quit IRC (Ping timeout: 480 seconds)
04:37:07 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:37:38 *** WormnestAndroid has joined #openttd
06:13:02 <Brickblock1> I believe your spriteset is incorrect
06:32:00 <pickpacket> Brickblock1: I wouldn't be surprised, but in what way?
06:32:34 <Brickblock1> I think it should have more numbers in it for offsets and such
06:32:50 <Brickblock1> but that's not why it isn't showing up
06:33:39 <Brickblock1> you are not using the `availability` callback and therefore it does not work
06:37:11 <pickpacket> I'll check that up
06:37:21 <andythenorth> glx[d]: I built the dock on when ships were already loading at the dock on the right, so I probably trapped it there
06:37:41 <Brickblock1> it is actually `construction_probability` I'm sorry
06:51:30 <pickpacket> There's another thing I must have missed... I don't have any connection between my industry and my industry tile
06:52:39 <Brickblock1> you need a tilelayout for that
06:55:32 <pickpacket> Yeah, that's what I was thinking. I don't understand the connection between tilelayout and industrytile though :(
06:56:14 <Brickblock1> you place the nml identifier for the industry tile in the tilelayout
06:59:08 <pickpacket> hmmm... I think I may understand it now
07:09:01 <pickpacket> should "callback" (or "callbacks"?) be defined in the property block of the industry?
07:09:48 <Brickblock1> no they are in the graphics block
07:09:53 <nielsm> you write the switch (etc) blocks on top level in the file. then reference their names in the graphics{} section of the industry block
07:15:21 <pickpacket> nielsm: Yeah, I was just looking at it but I can't find any callbacks
07:16:54 <nielsm> calls the switch at line 78-83
07:17:11 <nielsm> which ends up in the produce block at line 77
07:19:48 <pickpacket> are callbacks always defined as switch blocks?
07:21:04 <nielsm> the extra_text_industry graphic above (line 155) is technically also a callback, it just doesn't do anything dynamic
07:21:58 <nielsm> but switch blocks is the only way to do calculations and make decisions (conditionals) in callbacks
07:22:41 <nielsm> so a callback that actually checks conditions or calculates something will always be a chain of switch blocks
07:25:03 <pickpacket> but... just a construction_probability isn't very dynamic
07:25:59 <pickpacket> and your example doesn't have it defined at all 🤔
07:26:54 <nielsm> if it's just a single, constant result from the callback, you can just write it right there in the graphics block
07:27:33 <nielsm> or, you can write a switch block that switches on a constant and only has a default case
07:27:52 <pickpacket> I just want my industry to actually exist 😆
07:28:44 <nielsm> remember that most newgrf definitions are based on inheritance, any properties etc. you don't specify are the same as the industry you specified in "substitute"
07:39:24 <pickpacket> On "substitute" I had put "208", which an example said was the common factory. Changed it to INDUSTRYTYPE_TEMPERATE_FACTORY and now the thing shows up :D
07:39:36 <pickpacket> Going to try shipping people to it and see if I get goods
07:42:25 <pickpacket> I just want you to know I'm really grateful for all your help
07:44:20 <pickpacket> YES! We have Soylent Green, everyone!
08:00:37 <andythenorth> what shall we do today Brain?
08:13:58 *** D-HUND is now known as debdog
08:46:57 <Bouke> I'd like to draw attention to the download size regression for linux builds, see the comment on GH^. Not stripping binaries for linux results in a 250 MB increase in disk usage (3.65x).
08:47:58 <Bouke> The question I posted in the GH issue is whether this is still acceptable from a cost/benefit perspective, or should we keep stripping the binaries for linux bundles?
09:00:32 <FLHerne> In my (random) opinion that seems disproportionate
09:01:35 <pickpacket> I like small packages, personally. Saving bandwidth and disk space is good practice
09:02:24 <FLHerne> the Linux player (and especially player/developer) base is a lot bigger than macOS and it's easier to build stuff locally
09:03:18 <FLHerne> so I don't remember many undebuggable platform-specific bugs like the macOS ones
09:03:57 <FLHerne> (also, while the backtrace is missing info it doesn't seem to be outright misleading)
09:09:01 *** HerzogDeXtEr has joined #openttd
09:16:50 <Rubidium> AFAIR most MacOS backtraces are simply unusable, as they just refer the trace location from the closest function with got some symbols for some reason, which could be hundreds of kilobytes of code and thus a completely different function. In other words, the backtraces are basically less useful when it's stripped this "partial" way, than when it does not try to find the symbols at all
09:18:25 <Rubidium> and the better overall solution would be something like MSVC's PDB (debug information in a separate file) and dump files (so you can load stuff in the debugger). However... that does not work for self-compiled binaries, as we would not have the accompanying PDB to look at the dumps
09:32:24 <LordAro> Rubidium: #10071 was done *because* stripping macos binaries made the backtraces unusable
09:32:30 <LordAro> leaving the debug symbols in appeared to help
09:32:45 <LordAro> Bouke: perhaps strip everything except macos?
09:33:27 <LordAro> alternatively, we separate out the debug symbols for windows, why not linux-generic too?
09:41:09 <andythenorth> `nmlc ERROR: "generated/iron-horse.nml", line 181737: Unable to allocate ID for [random]switch, sprite set/layout/group or produce-block. Try reducing the number of such blocks.`
09:45:20 <andythenorth> I think Horse might be pushing at the limit
09:49:08 <andythenorth> from the nml alone, it's not clear what's triggered
09:50:31 <andythenorth> meanwhile this is an interesting piece of logic 😛
09:52:01 <andythenorth> hacks to overcome legacy issues 😛
09:53:42 <andythenorth> I wonder if it's `nmlc info: Concurrent spritegroups: 253/256 ("generated/iron-horse.nml", line 186514)`
09:54:17 <andythenorth> the change I'm making shouldn't increase the number of spritegroups, so I wouldn't expect a problem
09:54:18 <glx[d]> Maybe reorder the switches
09:54:48 <glx[d]> Or you have too many procedures in the scope while not needed at this point
09:55:14 <andythenorth> probably the procedures
09:55:43 <andythenorth> maybe randomised vehicles force the scope to expand
09:56:10 <andythenorth> the randomised vehicles are just a switch branching to the action 2 chains for the 'real' vehicles
09:56:29 <andythenorth> that would increase the number of switches in scope?
09:57:37 <glx[d]> All switches referenced in the randomiser stay in scope yes
09:58:13 <andythenorth> probably that then
09:58:40 <andythenorth> it works, until I add another vehicle to the randomisation list
10:00:29 <andythenorth> I wonder if nml tries to reorder to make the scope as small as possible
10:00:40 <andythenorth> or if I'm potentially expanding the scope horribly
10:00:56 <andythenorth> if I randomise vehicles [A, D, Q]
10:01:13 <andythenorth> and meanwhile there are B, C, E-P etc
10:01:30 <andythenorth> will the scope have to span everything declared A-Q?
10:01:53 <Eddi|zuHause> nmlc does not do any reordering
10:03:04 <glx[d]> Things stay in scope until last reference
10:05:02 <glx[d]> Would be nice if nmlc could optimise the scope, but it's a pain to do
10:05:39 <andythenorth> I wonder if I can manually optimise the scope
10:06:11 <Eddi|zuHause> you need to move these interdependent vehicles as close to each other as possible
10:06:47 <andythenorth> or make them not interdependent
10:07:12 <Eddi|zuHause> you could also duplicate them
10:07:12 <andythenorth> but that would involve even more redundant realsprite
10:07:38 <andythenorth> the existing biggest problem with Iron Horse is that half of the entire grf is just redundant realsprites
10:07:47 <andythenorth> I don't really want to inflate that further
10:07:59 <andythenorth> so I guess ordering to group related vehicles
10:09:03 <glx[d]> Would be nice if ID was an extended byte 🙂
10:09:12 <andythenorth> that's quite a big change? 😛
10:09:20 <andythenorth> did we reserve FF?
10:09:44 <glx[d]> Yeah FF is actually a valid ID
10:09:55 <andythenorth> grf version bump? 😛
10:09:59 <Eddi|zuHause> could be changed for GRFv9
10:10:50 <Eddi|zuHause> but then you could also just make it a WORD
10:11:18 <andythenorth> nmlc doesn't print the number of action 2 IDs used?
10:11:29 <andythenorth> or is spritegroups an effective proxy for that?
10:12:34 <Eddi|zuHause> that's the same thing
10:14:28 <Eddi|zuHause> maybe in the error case, it could list all the active names to help debug it?
10:16:05 <andythenorth> currently it just gives a line number, but that's quite opaque
10:16:53 <andythenorth> hmm wonder which is worse
10:17:15 <andythenorth> - avoiding scope issues entirely by duplicating action 2 chain + realsprites into these randomised vehicles (it's just templating)
10:17:32 <andythenorth> - grouping related vehicles together in the .nml
10:18:05 <andythenorth> the compile knows which ones are related, but it's possibly 1:many not 1:1
10:19:01 <andythenorth> this might pose an unmeetable constraint
10:19:05 <Eddi|zuHause> that's how we got garbage problems, people think "ah, i'll just buy a new one"
10:19:33 <Eddi|zuHause> because repairing is sometimes hard
10:19:39 <andythenorth> randomised_vehicle_1 = [A, B, D]
10:19:39 <andythenorth> randomised_vehicle_2 = [B, P, Z]
10:19:56 <andythenorth> randomised_vehicle_3 = [P, Q, R]
10:20:12 <Eddi|zuHause> that looks like a graph theory problem
10:20:17 <andythenorth> someone will tell me about O(n) or something in a minute
10:21:10 <Eddi|zuHause> those are usually NP-hard :)
10:21:48 <Eddi|zuHause> think knapsack or travelling salesman
10:21:54 <glx[d]> As long as the randomiser is inserted right after it's last referenced vehicle it should already reduce the scope
10:23:45 <glx[d]> I guess for now you are putting all randomisers at the end of the vehicle list
10:24:40 <andythenorth> everything is rendered in the buy menu order
10:24:59 <andythenorth> that's adjustable, but I would need to figure out what the order should be
10:25:26 <andythenorth> insert after last referenced vehicle
10:25:59 <glx[d]> I think you can keep A-Z as they are but insert random in this list yes
10:26:47 <Eddi|zuHause> you could also append each vehicle with a procedure: switch(randomiser_select) { case <this vehicle ID>: return <this>; else: chain to previous vehicle; }
10:27:05 <glx[d]> Some vehicles will still have a very long scope, but for many it will shorter it
10:27:13 <Eddi|zuHause> then the whole randomizer can be flattened to 1 concurrent sprite ID
10:27:23 <Eddi|zuHause> with potentially longer execution time
10:28:40 <Eddi|zuHause> has some optimisation potential, as you can put up to 255 vehicles into one switch
10:29:22 <andythenorth> counter-intuitively disabling some of the randomised vehicles increased the concurrent spritegroup count 😛
10:29:37 <andythenorth> although disabling more of them does reduce it rapidly
10:30:37 <andythenorth> ok disabling 4 randomised types reduces spritegroup count from 239 to 156
10:30:43 <andythenorth> so this is clearly causal
11:06:29 <pickpacket> a lot of industries have a bunch of different livery colours, and some have differing tile layouts. How does one do that?
11:15:21 <nielsm> different tile layouts: just define more tilelayout blocks with different names, and put all of them in the industry's layouts array
11:16:54 <nielsm> different colours can be done either by using appropriate flags and palette colours, or I think by using callbacks to select different sprites for the industry tiles (based on some property of the industry, like its on-creation assigned random value)
11:40:34 *** nielsm has quit IRC (Ping timeout: 480 seconds)
12:15:37 <pickpacket> Yaaaay!! Figuring out sprites now :D
12:16:21 *** ChanServ sets mode: +v tokai
12:19:03 <pickpacket> I understand the explanation of the palette now too. There's a few shades of blue that are all substituted for different liveries automatically
12:19:09 <pickpacket> That's pretty cool
12:20:48 <andythenorth> there are 2 ranges which are transformed to company colours
12:20:51 <andythenorth> a blue and a green
12:20:58 <andythenorth> industries don't use the second range
12:21:21 <andythenorth> did you find a palette image?
12:23:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
12:25:10 * andythenorth should have learnt set theory or something
12:25:19 <andythenorth> for this ordering of vehicles
12:27:41 <pickpacket> I found it somewhere on the wiki some time ago and apparently saved it
12:28:30 <petern> andythenorth: Line 186514 is terrifying.
12:29:29 <andythenorth> 'mostly whitespace'
12:29:52 <petern> glx[d]: NewGRF bump and NML update? 😄
12:30:23 <andythenorth> maybe gifs are over
12:30:25 <petern> I guess it's just andythenorth who runs out of IDs though.
12:31:53 <pickpacket> what does "Patch Company 2" mean?
12:35:18 <andythenorth> lol I wrote an unclosed python loop
12:35:30 <andythenorth> I don't think I achieved that more than once in the last 20 years
12:36:07 <andythenorth> extending a list while looping the same list is unwise
12:37:53 <pickpacket> petern: oh no! Have tea instead
12:38:09 <petern> Well I could just make another coffee
12:38:38 <pickpacket> andythenorth: I've done similar things where I've added and removed elements from a list while iterating over it... it's interesting to debug
12:39:14 <pickpacket> petern: do you know what it's called when you pick your coffee cup up to take a sip only to discover that it's empty?
12:40:59 <EmperorJake> pickpacket: that's 2cc (2nd company colour) which can be recoloured if the NewGRF allows it
12:44:28 <andythenorth> I need to merge these groups `[['randomised_open_car', 'randomised_piece_goods_car'], ['randomised_box_car', 'randomised_piece_goods_car'], ['randomised_piece_goods_car'], ['randomised_metal_coil_car', 'randomised_piece_goods_car', 'randomised_flat_car'], ['randomised_flat_car'], ['randomised_piece_goods_car', 'randomised_metal_coil_car', 'randomised_flat_car'], ['randomised_piece_goods_car', 'randomised_flat_car'], ['randomise
12:44:28 <andythenorth> 'randomised_flat_car'], ['randomised_metal_coil_car'], ['randomised_hopper_car', 'randomised_bulk_car'], ['randomised_dump_car', 'randomised_bulk_car'], ['randomised_chemicals_tank_car'], ['randomised_covered_hopper_car']]`
12:45:00 <andythenorth> so that a super-set is created from all the groups the item is in
12:49:11 <andythenorth> this should be easy, but I can't see how to do it without recursing into an unclosed loop 😛
12:51:53 <pickpacket> merge them into a third array?
12:53:33 <andythenorth> I see no way to do that yet 😛
12:54:01 <andythenorth> this is just some union thing, but it's not something I have an understanding of 😛
12:55:32 <pickpacket> is this something you need to do just this once, or something that needs to be done dynamically in runtime?
12:55:43 <andythenorth> if it was once, I could do it by eye 😉
12:55:51 <andythenorth> this is compile-time
12:56:19 <andythenorth> Eddi will know how to do it
13:09:09 <petern> Just put a state machine in it.
13:10:01 <andythenorth> I have written 10 lines of code that results in the same list as I started with 😛
13:10:23 <andythenorth> can't call set() on lists either 🙂
13:36:34 <pickpacket> correct me if I'm wrong: 1) I need to define a spriteset for each sprite, 2) I need to define a spritelayout for each sprite, 3) I need to define an industrytile for each tile
13:38:12 <andythenorth> 3 a different approach is used in larger sets, as tile ids are limited
13:38:31 <andythenorth> if you are not doing a lot of industries, you can just define an industrytile for each tile
13:47:20 <andythenorth> `{'randomised_flat_car', 'randomised_metal_coil_car', 'randomised_box_car', 'randomised_piece_goods_car', 'randomised_open_car'}
13:47:20 <andythenorth> {'randomised_bulk_car', 'randomised_dump_car', 'randomised_hopper_car'}
13:47:20 <andythenorth> {'randomised_chemicals_tank_car'}
13:47:20 <andythenorth> {'randomised_covered_hopper_car'}`
14:11:18 <andythenorth> ha grouping the wagons has made the ID problem worse somehow 🙂
14:17:47 <pickpacket> andythenorth: it would look better to define one industrytile per industry, really
14:18:21 <glx[d]> Works, but you need to draw based on time offset then
14:18:32 <pickpacket> what exactly is the difference between units_of_cargo and items_of_cargo when it comds to cargo?
14:18:40 <pickpacket> glx[d]: time offset?
14:18:57 <glx[d]> Tile, phone keyboard is hard to use
14:24:37 <andythenorth> if you want one industrytile per industry, you need to check relative_pos in the tile graphics chain
14:35:41 <pickpacket> I'll probably just do one industrytile per tile, as that sounds easier
14:36:51 <pickpacket> I wrote 'STR_CTNITEMS_SOYL :{COMMA} can{P "" s} of Soylent Green' in my lang file and got 'Using {P} without a ##plural pragma' 🤔
14:39:13 <glx[d]> Yes ##plural is used to tell the plural configuration
14:39:57 <pickpacket> where do I put that?
14:41:01 <andythenorth> ` nmlc info: Concurrent spritegroups: 198/256 ("generated/iron-horse.nml", line 152650)`
14:41:07 <andythenorth> after the re-ordering
14:41:11 <andythenorth> was about 239 before
14:41:35 <glx[d]> ## goes on top of language file
14:43:14 <andythenorth> too many random types, or just the right amount?
14:46:51 <petern> Random or predefined station layouts would be nice in Timberwolf's Stations. Building it piece by piece is painful.
14:48:37 <andythenorth> fewer random types
14:50:38 <andythenorth> ok we'll go with that
14:51:22 <pickpacket> "Similar to OpenTTD's language files, NML can also make use of cases, genders and plural forms. In order to utilize them, they have to be defined in the language file's header and have to match the definition as used in OpenTTD's language files:"
14:51:50 <pickpacket> "For Hungarian you'd have: ##case t ba"
14:51:56 <pickpacket> I don't understand any of this :(
14:53:01 <andythenorth> do you want Hungarian? 🙂
14:53:19 <pickpacket> no... but I don't understand what the English equivalent would look like
14:54:00 <petern> English doesn't have cases and genders, only plural forms.
14:54:20 <pickpacket> yeah, but there's no example of how the plural pragma is declared
14:55:09 <pickpacket> "##plural" isn't enough, and "##plural pragma" is invalid... but what's correct?
14:56:07 <petern> `##plural 0` for English
14:56:24 <andythenorth> I'd give you FIRS source to copy from....but that's unfair 😛
14:56:35 <andythenorth> I thought nml examples had this stuff though? 🙂
14:57:27 <petern> andythenorth: beautiful
14:58:35 <pickpacket> petern: "##plural 0" worked though, so thanks :)
14:58:35 <andythenorth> lol tab FFWD latched again
14:58:53 <andythenorth> maybe I should reduce ffwd speed
15:00:19 <petern> How is it 4pm already.
15:00:27 <petern> Oh yeah I had a quick nap, hah.
15:09:08 <pickpacket> petern: are you in the UK?
15:09:36 <pickpacket> I'm in Sweden. An hour ahead of you
15:41:42 *** Wormnest has joined #openttd
15:43:47 <pickpacket> "TTD default cargos occupy slots 0-11, so if you want to define a new cargo be sure to set this ID to 12 or higher." yet when I set it to 12 or higher it doesn't work... 0x04 works though
15:46:40 <andythenorth> have you got a cargotable?
15:47:50 *** sla_ro|master has joined #openttd
15:50:19 <andythenorth> how many cargos are in it?
15:51:17 <andythenorth> I can't remember how any of this works 🙂
15:51:25 <pickpacket> It works perfectly fine without an ID though 🤷 nml sets a sane default there too. Maybe I should just go that route?
15:51:37 <pickpacket> what do you use when you work on FIRS?
15:51:38 <andythenorth> but I believe IDs are constructed sequentially from 0 upwards, depending on the cargotable
15:51:51 *** Montana has joined #openttd
15:51:57 <andythenorth> FIRS auto-generates IDs
15:52:18 <andythenorth> I haven't touched this stuff for years though, I set it once, and never touch it again
15:52:32 <andythenorth> I try not to look at nml, FIRS barely uses it
15:52:38 <pickpacket> "For cargos, the item ID corresponds to the cargo type slot of the cargo." 🤷
15:52:58 <pickpacket> meh, I'll just go without setting an ID since that works
15:54:48 <andythenorth> usually numeric IDs are set for nml to prevent them changing between compiles, as that can break savegames needlessly
15:55:15 <andythenorth> but I suspect many people don't worry about that 🙂
16:03:42 <FLHerne> pickpacket: belatedly - each sprite must be included in a spriteset [to be used for anything], but a spriteset can contain multiple sprites and the spritelayout can use your_spriteset(n)
16:04:27 <FLHerne> and in principle the same spritelayout can be used for multiple tiles if they happen to look the same
16:07:18 <FLHerne> or your_spriteset(your_label) if the sprites are labeled
16:07:49 <petern> That's gotta be illegal
16:15:02 <petern> There's also tea in my mug
16:16:06 <pickpacket> And I thought I was being original...
16:16:19 <pickpacket> FLHerne: thanks for the clarification!
16:17:01 <Brickblock1> firs does not usually have tea I just overrode the name
16:17:06 <pickpacket> So... uhm... I gave soylent green the cargo ID 0x09 (just a random one) and all works. Except my factory for some reason accepts iron ore too 🤔
16:17:12 <pickpacket> Brickblock1: *phew*
16:17:47 <Brickblock1> is everything the industry accepts in the cargo table?
16:17:59 <pickpacket> there's something deeply disturbing about seeing a cargo tram picking up "cans of Soylent Green"...
16:18:32 <pickpacket> Brickblock1: yeah. The cargotable only has PASS and SOYL (the former is accepted, the latter is supplied)
16:19:22 <pickpacket> oh. I have to check something
16:19:53 <pickpacket> 0x0c is hex for 12, right?
16:20:26 <Brickblock1> I think so but just 12 should work
16:21:35 <pickpacket> hmm... yeah... either way it doesn't work
16:22:10 <petern> You probably need to set cargo classes so that you can have vehicles that carry the cargo. But I dunno.
16:22:26 <pickpacket> when I put 12 or above as the cargo ID it just doesn't show up in the game. But for some reason my factory still accepts iron ore
16:22:35 <pickpacket> petern: yeah I have that. That part works like a charm
16:29:17 <pickpacket> Okay so if I set a cargo ID of 10 or lower the cargo exists in the game
16:30:05 <pickpacket> I have no idea why, because it *should* be colliding with existing cargo IDs. And my factory still accepts iron ore for some unfathomable reason
16:30:13 <Brickblock1> I think I know why it isn't showing up
16:30:27 <Brickblock1> Have you set the number prop?
16:32:05 <pickpacket> no..? "This mostly affects old NewGRFs that don't have a cargo translation table. "
16:32:22 <pickpacket> (not that I know what a cargo translation table is... yet...)
16:32:40 <Brickblock1> openttd still needs it set I tested and you should always set all props
16:38:22 <Brickblock1> everything seams fine when I changed the id to 12 and number prop to 12
16:58:21 <pickpacket> Brickblock1: Cool! I'll try it :)
17:03:03 <pickpacket> Yay! It works for me too!
17:03:21 <pickpacket> now I just have to figure out why the factory accepts iron ore
17:12:07 <pickpacket> it has to do with the "substitute" value in the industrytiles
17:12:56 <pickpacket> I changed it from 0x39 to 0x79 and now it accepts coal, iron ore, and wood
17:23:28 *** esselfe has quit IRC (Remote host closed the connection)
17:25:51 * pickpacket hasn't even gotten to the actual *tea* part of it all yet..
17:27:30 *** felix_ has quit IRC (Read error: Connection reset by peer)
17:28:05 *** esselfe has joined #openttd
17:30:00 <pickpacket> How do Cargo Classes work? Now that I've set it to CC_PIECE_GOODS, what kind of vehicles can transport it?
17:32:43 <andythenorth> vehicles that set CC_PIECE_GOODS
17:37:05 <pickpacket> can you recommend any vehicle sets?
17:37:43 *** Montana has quit IRC (Quit: Leaving)
17:39:28 <pickpacket> I have a cargo tram set where the cargo trams can be refitted to carrying soylent green
17:39:53 <pickpacket> is that sort of how it would work? That vehicles need to be refittable for the cargo type
17:39:57 <andythenorth> base vehicles should refit if you have OpenTTD 12.0
17:40:12 *** esselfe has quit IRC (Remote host closed the connection)
17:40:20 <pickpacket> yeah, it's just that I run 10.3 :P
17:40:24 <andythenorth> grf vehicles can use both labels and classes
17:40:31 <andythenorth> classes give broad support
17:40:36 <andythenorth> labels give fine-grained support
17:40:48 *** esselfe has joined #openttd
17:42:32 <pickpacket> so the idea is that vehicles are refitted for the specific cargo?
17:42:47 <pickpacket> I can roll with that :D
17:43:27 <andythenorth> player refits via refit menu or station order
17:43:43 <andythenorth> grf author sets classes for general refittability of the vehicle
17:43:55 <andythenorth> then uses labels to include / exclude specific cargos from refit
17:48:42 <andythenorth> 512 x 256 is too big for FIRS Steeltown 😛
17:51:02 <pickpacket> in what way is it too big? :D
17:51:23 * pickpacket is living on the edge -- installing openttd from debian testing
17:52:15 <pickpacket> and all its dependencies 😅 I'm sure this is only going to crash my OS slightly
18:04:36 <pickpacket> I absolutely love this game
18:05:43 <pickpacket> So! Soylent green works! There's nothing that accepts soylent green, but that doesn't matter because all of this is going to be tossed overboard now because I'm going to start working on TEA instead :D :D :D :D :D
18:10:46 <andythenorth> quite satisfying when it works
18:11:12 <pickpacket> yes :D very much so
18:11:36 <pickpacket> now I'm just gonna spend... errrh... slightly less than forever drawing sprites...
18:12:14 <pickpacket> well well. Tea tree farm + tea factory + tea house. Just get to work I guess :D
18:33:53 <petern> Cargodist: 520 passengers stood on the platforms, waiting to get a 22 capacity bus that goes 7 tiles away.
18:34:19 <petern> It totally looks walkable...
18:39:11 <petern> No, I can't play without automatic transfer systems.
18:39:13 <andythenorth> I do use cdist for pax
18:39:43 <andythenorth> I too enjoy watching the bizarre side effects
18:39:55 <petern> We just transport things, we don't get to decide where to!
18:40:33 <andythenorth> not sure it can be improved 🙂
18:40:41 <andythenorth> remember YACD though? 😛
18:41:23 <andythenorth> goes it rebase YACD? 😛
18:43:13 <andythenorth> would be a short stream
18:43:20 <andythenorth> rebase -> conflicts -> fin
18:48:58 <petern> I'm currently rebasing right now
18:49:08 <petern> (I'm building in Minecraft)
18:57:46 *** Tirili has quit IRC (Quit: Leaving)
19:08:56 <andythenorth> did you have lunch?
19:10:21 <petern> I bet they still want to go via the bus stop 😄
19:11:12 <petern> This should be configurable really, especially when using NewGRFs that make towns lower density.
19:12:53 <petern> Although actually, it's only passengers that I want to effect.
19:13:13 <petern> So that's never going to work.
19:13:46 <petern> (It could work but would need more work than just changing CA_TRAIN...)
19:14:31 <petern> This is definitely not chunky bevels though
19:15:17 <andythenorth> you have cargodist in minecraft now? 😮
19:18:23 <petern> Hmm, do I have less cargo, because it doesn't need to feed into the local bus services, or do I have more cargo, because the catchment now picks up loads more...
19:18:57 <andythenorth> I see no harm in configurable catchments
19:19:10 <andythenorth> we already have a bool flag for them bigger / smaller?
19:19:48 <petern> Which makes the catchment of bus/truck stops smaller.
19:22:45 <petern> Also: it's square. Maybe radius would be better.
19:23:21 <petern> Probably not better, just different.
19:23:31 <andythenorth> different is interesting
19:23:52 <andythenorth> add a restaurant tile to increase radius
19:24:14 <petern> Garden Centre for extra pax on Sundays
19:26:38 <andythenorth> this is correct way to canal yes?
19:28:30 <petern> Glass roof? Shall I colour it?
19:29:09 <pickpacket> petern: compare to some other building with a glass roof perhaps?
19:32:41 <petern> That reminds me, does the station in NewStations with a green roof still work?
19:33:50 <petern> andythenorth: larger catchment doesn't work, I have tons of passengers waiting to get on the bus, even though the bus stop is now within the station's catchment 😄
19:34:19 <andythenorth> they will all turn into transmitters next time I update the grf 😛
19:35:00 <petern> divide cargo generation by catchment area size?
19:35:29 <petern> It's totally logical. Or something.
19:40:03 <andythenorth> did we increase the object limit?
19:40:07 <andythenorth> I think we did in theory
19:42:07 <pickpacket> hmmm.... is it possible to place a few tiles out randomly within an area around the main industry?
19:44:40 <andythenorth> you can leave gaps in the layout
19:44:54 <andythenorth> you can also generate farm fields for farms
19:45:11 <andythenorth> but you have zero control over the fields
19:45:56 <petern> Not even sprites right?
19:46:23 <pickpacket> I was actually thinking about farm fields, but they become so massive. I figure the map already has a gazillion grain fields
19:47:21 <andythenorth> petern: on or off, that's it
19:47:24 <pickpacket> gaps in the layout could work... I'll have to tinker around a bit and see what I end up liking.
19:47:43 <andythenorth> FIRS has pseudo random placement
19:47:50 <andythenorth> it just generates a *lot* of layouts
19:53:59 <pickpacket> I'm about to fall asleep at the computer... I believe that's my cue to going to bed
19:54:19 <pickpacket> see you all tomorrow :)
20:02:14 <andythenorth> such industry objects
21:02:40 <andythenorth> because it was there?
21:23:35 *** sla_ro|master has quit IRC ()
21:35:46 <andythenorth> frosch: dice varying by generation?
21:35:55 <andythenorth> not sure it's quite right yet, but eh
21:43:20 <andythenorth> bevels are too small though
21:44:36 <andythenorth> hmm should I use trucks?
21:44:40 <andythenorth> always seems like cheating
21:46:09 <reldred> But that’s why I like my patch in JGRPP that prevents trucks being able to phase through one another, it reduces/prevents vehicle spam sooooo much
21:46:40 <andythenorth> I made an RV set once
21:47:37 <petern> Quantum queueing was a 'feature'
21:51:22 <andythenorth> it's a good feature
21:54:16 <reldred> I mean, good for less experienced players to prevent total cockups,
21:55:09 <reldred> But part of what I like about JGRPP is being able to explore settings that really punish players for poor/lazy/spammy design and reward proper planning
21:55:42 <reldred> Kind of why I wish that multitile depots patch got somewhere but I suspect it’s just gonna fade into obscurity
22:11:32 <andythenorth> also daylength when?
22:13:11 <andythenorth> time is passing too fast
22:14:56 <nielsm> random thought about multitile depots: require using a railtype newgrf that adds whatever appropriate depot graphics for it. railtypes that don't have the flag set have classic "depots of holding" and railtypes that do have the flag and graphics for long depots require them.
22:16:01 <nielsm> and part of the reason for that would be that it avoids having a game setting as such, and makes it something you can't convert an existing save to using
22:16:21 <nielsm> (or at least can't convert in a supported manner)
22:17:20 <andythenorth> I should do more road stuff
22:17:38 <andythenorth> apart from not having diagonals, it's a lot less stressful than trains 😛
22:18:10 <nielsm> add a bicycle delivery guy
22:18:15 <nielsm> capacity: 1 crate of goods
22:19:02 <andythenorth> someone did I think 🙂
22:19:05 <andythenorth> velo or something
22:19:21 <andythenorth> I wouldn't mind drive-through depots at all 😛
22:19:33 <andythenorth> and a 1x2 size, like ships
22:26:20 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:27:39 <reldred> Yeah, I liked that it basically prevented the overflow depot spam entirely, and that you had to approach depot complex building with the similar sort of attention you’d approach stations with
22:30:39 <petern> But "advanced game mechanics!"
23:18:30 *** wallabra has quit IRC (Ping timeout: 480 seconds)
23:20:32 *** wallabra has joined #openttd
23:30:46 *** Flygon has quit IRC (Read error: Connection reset by peer)
23:33:42 *** Deep3D has quit IRC (Remote host closed the connection)
23:36:34 <pickpacket> brrrrrrr.... sleep? Ain't no sleep where we're going!
23:39:50 <petern> Correct, don't be silly
23:50:00 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:51:43 *** Deep3D has quit IRC (Remote host closed the connection)
continue to next day ⏵
