Times are UTC Toggle Colours
00:04:49 <TallTyler> I think that’s JGRPP, which has a “ships avoid collisions” feature 00:51:13 *** WormnestAndroid has quit IRC 00:52:55 *** WormnestAndroid has joined #openttd 01:40:59 *** Tirili has quit IRC 02:20:04 *** D-HUND has joined #openttd 02:23:26 *** debdog has quit IRC 02:29:09 *** Wormnest has quit IRC 03:55:49 *** _aD has quit IRC 04:37:07 *** WormnestAndroid has quit IRC 04:37:38 *** WormnestAndroid has joined #openttd 06:06:22 <pickpacket> I don't understand what I'm doing wrong, but this is still not working :( https://notabug.org/tinyrabbit/tea-tea-deluxe 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:13 <pickpacket> ty 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:03:04 *** nielsm has joined #openttd 07:09:01 <pickpacket> should "callback" (or "callbacks"?) be defined in the property block of the industry? 07:09:11 <nielsm> no 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:12:45 <nielsm> pickpacket: did you get the example I shared the other day? https://gist.github.com/nielsmh/c9e048268f5694b97b48a7060f0e6279 07:15:21 <pickpacket> nielsm: Yeah, I was just looking at it but I can't find any callbacks 07:15:50 <nielsm> line 156 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:38:43 <pickpacket> I got it working! 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:44:13 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on pull request #10071: Change: Don't strip symbols from bundles https://github.com/OpenTTD/OpenTTD/pull/10071#issuecomment-1272268520 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:31 <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:06 <andythenorth> meh 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:50:34 <andythenorth> ` if (1) {` 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:23 <andythenorth> hmm 09:55:34 <andythenorth> oh 09:55:43 <andythenorth> maybe randomised vehicles force the scope to expand 09:56:11 <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:38 *** Flygon has joined #openttd 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:54 <Eddi|zuHause> nmlc does not do any reordering 10:01:54 <glx[d]> NML does not reorder 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:29 <Eddi|zuHause> maybe in the error case, it could list all the active names to help debug it? 10:15:43 <andythenorth> might help 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:31 <andythenorth> yes 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:31 <andythenorth> probably fine 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 12:15:37 <pickpacket> Yaaaay!! Figuring out sprites now :D 12:15:48 <pickpacket> Here's a Soylent Green factory: https://lounge.warmedal.se/uploads/d8c48b589cac0373/image.png 12:16:21 *** tokai has joined #openttd 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 12:25:01 <andythenorth> hmm 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:27 <pickpacket> https://lounge.warmedal.se/uploads/5c41eedeea03d242/TTD_Palettes.png hmmm.... this wasn't the one with the explanations 🤔 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:03 <andythenorth> https://tenor.com/view/fantasia-brooms-walking-animation-gif-17666495 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:30:55 <pickpacket> Here it is! https://newgrf-specs.tt-wiki.net/wiki/PalettesAndCoordinates 12:31:53 <pickpacket> what does "Patch Company 2" mean? 12:33:10 <petern> Coffee ran out 😦 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:39:42 <pickpacket> it's a depresso 12:40:59 <EmperorJake> pickpacket: that's 2cc (2nd company colour) which can be recoloured if the NewGRF allows it 12:41:23 <pickpacket> ahhh 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:54 <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:06 <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:03 <andythenorth> GG WP 13:10:23 <andythenorth> can't call set() on lists either 🙂 13:10:25 <andythenorth> oops 13:10:29 <andythenorth> makes sense 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:37:58 <andythenorth> 1 and 2 yes 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:13 <andythenorth> lol achieved it 13:47:13 <andythenorth> pure guessing 😛 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:13:57 <andythenorth> it's a bug 🙂 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:32:17 <DorpsGek> [OpenTTD/grfcodec] SoapGentoo opened pull request #16: Gentoo patches https://github.com/OpenTTD/grfcodec/pull/16 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:40:36 <pickpacket> I copied the syntax of these: https://newgrf-specs.tt-wiki.net/wiki/NML:Default_TTD_strings 14:40:36 <glx[d]> https://translator.openttd.org/static/docs/strings.html 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:12 <andythenorth> was about 239 before 14:41:35 <glx[d]> ## goes on top of language file 14:42:27 <glx[d]> https://newgrf-specs.tt-wiki.net/wiki/NML:Language_files 14:43:14 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1028316649054548048/unknown.png 14:46:10 <petern> Mmm, random 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:38 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1028318005278560397/unknown.png 14:49:16 <petern> I like the firs 14:49:22 <petern> I like the first 14:50:13 <andythenorth> max random 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:57 <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:01 <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:56:47 <petern> https://wiki.openttd.org/en/Archive/Source/O