Times are UTC Toggle Colours
00:09:54 *** HerzogDeXtEr has quit IRC 00:39:49 <Wolf01> 'night 00:39:51 *** Wolf01 has quit IRC 00:52:49 *** ToBeFree has quit IRC 01:07:53 *** Flygon has joined #openttd 02:22:49 *** glx has quit IRC 03:38:07 *** rellig has joined #openttd 04:48:06 *** Cubey has quit IRC 05:02:11 *** Alberth has joined #openttd 05:02:11 *** ChanServ sets mode: +o Alberth 05:02:25 <Alberth> moin 06:09:32 *** chomwitt has quit IRC 06:35:47 *** adf88 has joined #openttd 06:38:11 <Alberth> o/ 06:39:22 *** KouDy_ has quit IRC 06:40:48 <adf88> hi 07:20:54 *** blocage has joined #openttd 07:41:36 *** KouDy has joined #openttd 08:16:43 *** Progman has joined #openttd 08:37:25 *** HerzogDeXtEr has joined #openttd 08:51:54 *** Wolf01 has joined #openttd 08:53:04 <Wolf01> Moin 08:53:15 <LordAro> elo 08:55:32 <blocage> hello, there is plan to switch from vehicle based GUI to track/order list based GUI ? 08:57:03 <blocage> It would be nice to setup order list independently from vehicle, then assign vehicle on them 08:58:50 <LordAro> blocage: you might be interested in https://wiki.openttd.org/Shared_orders#Shared_Orders 08:59:13 <LordAro> but i can't see such a pivotal change to the UI happening at all 09:00:13 <blocage> LordAro, I know how to share orders, but the GUI is quite dificult to handle 09:01:02 <blocage> LordAro, mm ok 09:01:32 <LordAro> it is a good idea though, i think, i just can't see it getting done any time soon 09:02:36 <blocage> ok, so no plan for this :) 09:10:34 *** Stimrol has joined #openttd 09:18:08 <Alberth> o/ 09:19:00 <Alberth> lots of plans exist, realizations of plans is the problem, as it takes time 09:19:24 <Alberth> your best chance of getting it in is to make it yourself 09:20:54 <blocage> Alberth, ^^ at less I don't start a work that is already started :) 09:21:12 <Alberth> oh, don't worry about that 09:21:40 <Alberth> plans always look similar, but there are enough details to decide to make your solution unique 09:22:05 <Alberth> and those details decide how good the solution is 09:23:00 <blocage> but I think it's better to join an effort that is already started than starting a new one from scratch 09:23:18 <Alberth> ie we have around a handful of day-length patches, and none are the same 09:23:45 <Alberth> if you can find yourself in the approach that the developers took, sure 09:24:21 <Alberth> but these things are not just "plan -> just start typing code -> done" 09:24:34 <Alberth> even if you know how to code" 09:24:59 <Alberth> the first arrow hides a shitload of thinking and deciding 09:25:19 <blocage> first I think there some sub-task to do, for exemple: visual feedback for order list 09:25:42 <Alberth> what does that mean? 09:25:56 <Alberth> "visual feedback", that is 09:26:25 <blocage> i.e. showing on map the path of a vehicle, where he should drop it's content, where he gather goods 09:26:29 <blocage> and so on 09:27:01 <blocage> so you select a vehicle, show-order-list-on-map 09:27:01 <Alberth> alright, "path" is simple if you draw straight lines 09:27:19 <blocage> and see this think on map 09:27:26 <blocage> this is a first subtask 09:27:38 <Alberth> if you mean real actual path, that's complicated, as you need to understand how the tracks/roads/bouys go 09:28:08 <blocage> that can be splitted into other sub-task, like: path of plane vs path of train vs path of other vehicle 09:28:23 <Alberth> :) 09:28:36 <Alberth> you can decompose everything several times, usually :) 09:28:53 <Alberth> but sure, have a go at it. 09:29:07 <blocage> that waht I call plan that can be share amoung developpers 09:29:31 <Alberth> how many devs are you? 09:29:46 <blocage> I'm the one :D 09:30:05 <Alberth> hmm, sharing might not work very good then :) 09:30:40 <blocage> but having a task list may provide idea to other devs 09:31:13 <blocage> but anyway I will look what I can do, maybe I will have the time, maybe not :) 09:31:17 <Alberth> it never hurts to decompose and make a list 09:31:29 <Alberth> you can post at the forum 09:31:57 <Alberth> but in general, people are happy to comment and suggest, but not in helping out 09:32:12 <blocage> I will do so if I reach something that look viable, and that I can support 09:32:18 <Alberth> but who knows, you may be lucky 09:32:32 <Alberth> ok, have fun! 09:33:28 <blocage> As everyone my time is not extensible, even after Einstein work :D 09:33:31 *** Hiddenfunstuff has joined #openttd 09:39:51 *** Celestar has joined #openttd 09:45:42 *** Celestar1 has quit IRC 10:03:17 <Wolf01> Alberth: is there some way to set the size of a nwid_vertical to like 30% of the window width? 10:04:32 <Wolf01> I'm trying with spacers with fill, but every container fills a different space based on the content 10:09:27 <Alberth> non-leaf widgets get their size from their childs 10:09:47 <Alberth> so you have to compute a good size of the childs (leafs) 10:10:12 <Wolf01> That could be difficult 10:10:17 <Alberth> or write a custom widget that handles such control (if there is room to do so, I guess) 10:10:43 <Alberth> widgets generally don't know window size 10:10:59 <Alberth> just their own size and position in the window 10:11:50 <Alberth> town window is probably the most hacky case for such a feature :p 10:12:48 <Alberth> it has 2 widgets under each other that resize iirc, but the window can't quite handle that 10:13:05 <Alberth> it got done by some custom code in the window 10:13:25 <Alberth> map window has some special code for the list at the bottom 10:14:28 <Alberth> but it's a complicated problem, if you have stuff that can move around to fill available space, as you can then exchange width for height and vice versa 10:14:51 <Wolf01> If I want to set a fixed width instead? 10:15:14 <Alberth> depends 10:15:28 <Alberth> if you have a good upper limit that would work 10:15:54 <Alberth> if you don't know, a common trick is to just pick something and enlarge when it doesn't fit 10:16:05 <Alberth> lots of windows do that 10:16:16 <Alberth> eg station picker and vehicle gui 10:16:27 <Wolf01> Yes 10:16:33 <Alberth> variable text in it, so sometimes it resizes to fit 10:16:45 <Alberth> so that's definitely an option as well 10:17:53 <Wolf01> I just want to align the buttons at the same distance between different sections, buttons now gets larger because labels have different text width in different sections 10:18:46 <Wolf01> I'm fine with labels to change size accordingly to text, but buttons should always stay the same size 10:18:48 <Alberth> just compute the size of all buttons, and return the max for all 10:20:16 <Wolf01> Which is what NC_EQUALSIZE already does 10:22:26 *** Wormnest has joined #openttd 10:22:32 <Alberth> that's inside a single container, isn't it? 10:22:39 <Wolf01> Yes 10:22:59 <Alberth> if you can put all buttons in one container, that will work 10:23:14 <Alberth> but "different sections" suggests you cannot, to me 10:24:45 <Alberth> oh, vehicle order buttons do this kind of stuff, but it's a complicated gui 10:25:03 <Alberth> with all the different rows that change between vehicle types 10:25:20 <Alberth> no idea how it works there 10:25:56 <Alberth> main menu also does it, but that might be a bad example 10:28:21 *** _3298 has joined #openttd 10:33:28 <Wolf01> Is possible to show the boxmodel of widgets? 10:34:48 <adf88> Wolf01: you can always override UpdateWidgetSize to workaround problems 10:35:09 <adf88> in your case, this would be the solution: 10:35:46 <adf88> 1. iterate all possible button texts and compute maximum 10:36:10 <adf88> 2. use the computed value as the size for all buttons (in UpdateWidgetSize) 10:36:17 <Alberth> unless someone added it, there is no grid-widget 10:36:33 <Alberth> you can port it from freerct :p 10:36:44 <Alberth> it's not simple copy/paste though 10:37:35 <Alberth> or if that's not what you mean with "boxmodel", what is the latter? 10:37:43 <_dp_> iirc openttd does some grid-like things by putting vertical lists in horizontal 10:38:07 <Alberth> or the other way around, but yes 10:38:18 <Alberth> one of the omissions we found too late :) 10:38:38 <_dp_> Alberth, usually keeping width is more problematic 10:38:41 <Wolf01> https://www.w3.org/TR/CSS2/images/boxdim.png <-boxmodel 10:39:12 <Alberth> fixed in freerct, where I discarded horizontal and vertical containers instead, as they both fit in a grid container 10:39:54 <adf88> The model is a bit different 10:40:00 <adf88> but it's something like that 10:40:14 <adf88> we have paddings, no margins etc. 10:40:28 <Wolf01> I just want to see the widget bounding box 10:40:36 <Alberth> we have margins but no border I think 10:40:43 <adf88> you just wanted a WYSIWYG designer? 10:41:01 <adf88> sorry 10:41:02 <Wolf01> I'm making that in javascript 10:41:06 <adf88> none exists 10:41:29 <adf88> :P 10:41:56 <Wolf01> But in OTTD I would like to see which widget is too large and makes all the others resize 10:42:13 <adf88> hint: sometimes i'm just using differently coloured backgrouds for debug purposes 10:43:03 <LordAro> Alberth: thought about changing OTTD to do it the FRCT way? it always did seem simpler 10:43:30 <Wolf01> adf88: a bit difficult when the widget doesn't get a colour and you need to add panels everywhere 10:44:31 <Alberth> LordAro: I haven't 10:44:59 <Alberth> freerct is version 2, which is usually simpler relative to its predecessor :) 10:47:17 <Alberth> I used to have a patch for dumping widget positions, resize settings, and sizes in an indented tree, but can't find it 10:48:56 *** Defaultti has quit IRC 10:51:11 *** Defaultti has joined #openttd 10:52:25 <adf88> Wolf01: yes, spaces don't get coloured (naturally!) 10:52:50 <adf88> if you colour widgets differently, the spaces will be visible too 10:52:56 <Wolf01> Ok, found it, it was a vertical spacer which fucked up with the width 10:55:09 <Wolf01> Doesn't a NWID_SPACER stack vertically with NWID_HORIZONTAL? Like an hamburger 10:55:36 <adf88> no 10:56:18 <Wolf01> So I have to find another way 10:56:43 <adf88> no, if I understand correctly :p 10:56:51 <adf88> what did you mean exactly? 10:56:53 <adf88> :p 10:57:44 <Wolf01> NWID_VERTICAL { 10:57:44 <Wolf01> NWID_HORIZONTAL {} 10:57:44 <Wolf01> NWID_SPACER 10:57:44 <Wolf01> NWID_HORIZONTAL {} 10:57:44 <Wolf01> } 11:00:09 <adf88> the spacer should be just between horizontal containers 11:00:15 <adf88> not sure what you are asking for 11:01:04 <adf88> height of the spacer should give a distance between horizontal containers 11:01:17 <Alberth> remove the space widget, and use a pip of (0, N, 0) on the vertical container 11:01:25 <adf88> width of the spacer should give some minimal size to the vertical container 11:01:47 <Alberth> pretty sure it works that way adf88 :) 11:03:01 <adf88> SetPIP/SetMinimalSize would work too, yes 11:04:02 <Alberth> trick that might work is to replace the space widget by a NWidgetBackground widget of some colour 11:04:11 <Alberth> BG color, that is 11:04:21 <Alberth> that allows you to see its space 11:05:13 <LordAro> would be nice to have a better way of specifying the windows, the current way isn't all that user friendly 11:07:22 <Alberth> lol, you improve python code on suggestions by pylint, and your grade decreases :p 11:11:20 <Alberth> making the windows more consistent in style and colour would be nice too 11:13:16 <Wolf01> <Alberth> remove the space widget, and use a pip of (0, N, 0) on the vertical container <- yes, that was an example, I have many horizontal containers and need the space only between 2 of them, with PIP I need to wrap the other ones into another vertical container 11:13:34 *** FLHerne has joined #openttd 11:13:58 <Wolf01> The spacer already had a setminimalsize of 0, 6 11:16:35 <Wolf01> http://imgur.com/a/n3i1I 11:18:08 <adf88> Yes, PIP is for all "internal" paddings between contained widgets 11:18:14 <Wolf01> Yes 11:18:28 <adf88> if you want a spece just in a single place, use a spacer just like you did 11:18:47 <Wolf01> The spacer was put on the side of the horizontal container 11:19:04 <Wolf01> Even if inside a vertical container 11:19:29 <adf88> on a side? 11:19:35 <Wolf01> Yes 11:19:53 <adf88> PIP is for "pre" "in" "post" 11:20:03 <Wolf01> I know 11:20:17 <Wolf01> Don't change the subject every 2 lines please 11:20:47 <adf88> I'm not 11:21:05 <adf88> i'm trying to say that you should use "pre" or "post" for a side space 11:21:18 <adf88> you don't have to put a spacer on a side 11:21:38 <Wolf01> I'm not putting the spacer on the side 11:21:59 <adf88> OK then 11:23:06 <Wolf01> http://imgur.com/a/n3i1I <- second image 11:23:07 <Alberth> looks nice, no idea what to notice in that picture though 11:24:44 <Alberth> oh, bottom text line explains 11:24:51 <Alberth> some code please? 11:25:14 <Alberth> clearly it's not under a row :p 11:26:15 <Wolf01> I put the code in the comments of the images 11:26:27 <Wolf01> Pseudocode at lease 11:26:31 <Wolf01> *least 11:27:53 *** frosch123 has joined #openttd 11:28:12 <Wolf01> Quak 11:28:50 <adf88> sorry but it's too cryptic too me 11:29:23 <Wolf01> Does it break the format? 11:30:04 <Alberth> hola 11:30:57 <frosch123> moi 11:31:31 <Wolf01> Sorry, I left a rogue PIP in the bottom one 11:31:32 <LordAro> o/ 11:32:30 *** gelignite has joined #openttd 11:34:02 <Wolf01> https://paste.openttdcoop.org/pb94wxvue <- this is the actual code (with wrong behaviour) 11:35:34 <Wolf01> Uncomment PIP on line 3 and the vertical container at L:36-62, remove the spacer at L:34 and it works, but I didn't want to use the PIP to do that (maybe I'm wrong) 11:40:38 <adf88> the spacer on line 34 11:40:44 <adf88> why do you need this? 11:40:50 <adf88> it seems problematic 11:41:09 <adf88> sorry 11:41:11 <adf88> not his one 11:41:12 <Wolf01> Yes it is, it's to separate the edge buttons 11:41:16 <adf88> not this one 11:41:28 <adf88> moment please, decrypting ;P 11:43:18 <adf88> you need this vertical container 11:43:23 <adf88> uncomment it 11:44:18 <Wolf01> Same result, weird space at the right 11:44:35 <Wolf01> Which goes away if you remove the spacer 11:44:49 <adf88> SetFill(1, 0) ? 11:45:35 <Wolf01> Nope, same result 11:46:08 <adf88> you should take care what's inside your vertical container 11:46:18 <Wolf01> Oh, if you put setfill for the spacer it works 11:47:18 <Wolf01> NWidget(NWID_SPACER), SetMinimalSize(0, 6), SetFill(1,0), <- but it looks weird 11:48:24 <Wolf01> I expected it to have the same width of the containers, not bigger 11:48:33 <Wolf01> Maybe smaller, but not bigger 11:48:44 <DorpsGek> Commit by frosch :: r27900 /trunk/src (widget_type.h window.cpp) (2017-08-27 13:48:38 +0200 ) 11:48:45 <DorpsGek> -Change [FS#6568]: Remove the gap between windows when positioning them after opening. 11:48:46 <DorpsGek> -Fix: Make automatic window-positioning RTL-aware. 11:48:47 <DorpsGek> -Fix: Automatic window-positioning now uses GUI-scale/style dependent sizes/distances instead of fixed pixel values. 11:48:52 *** _3298 has quit IRC 11:49:22 <Wolf01> I think it's because the spacer doesn't get the PIP 10,0,10 of the parent container, so it's initialized with the size of the parent container 11:49:48 <Wolf01> Alberth: could you confirm this? It's too much chinese to me 11:54:59 <Alberth> line 3 isn't doing anything, as it has only 1 column 11:56:08 <Alberth> that would then also hold for line 2 11:56:24 <Alberth> (bot for 1 row) 11:57:12 <Alberth> hmm, horizontal container has pip (10, 0, 10), so it handles spaceing at left and right thus 11:57:16 <Wolf01> I could move PIP to the parent yes, all the panels have the same PIP 11:57:46 <Wolf01> But I need to keep at least one container for every tab 11:57:55 <Wolf01> Even if it does nothing 11:58:24 <Wolf01> I could use WWT_PANEL, so tabs could have different colour 11:59:21 <Alberth> what bothers me is the vertical fill in the first column but not in the second, but that's not the problem, right? 11:59:37 <Wolf01> No, that doesn't seem to be the problem 12:00:01 <Wolf01> I copied it right away from the original code 12:00:44 *** _3298 has joined #openttd 12:02:24 <Alberth> tbh I don't understand what the problem is, currently 12:02:54 <Wolf01> The spacer creates a weird space on the right even when stacked vertically 12:03:06 <Wolf01> It seem too large 12:03:17 <Wolf01> SetFill(1,0) fixed it 12:03:35 <Wolf01> But why is too large? 12:07:18 <Alberth> what happens if you replace line 34 by NWidget(WWT_PANEL, COULOR_RED), SetMinimalSize(0, 6), EndContainer(), 12:07:29 <Alberth> ie replace it by a widget with colour 12:08:09 <Alberth> all widgets have a default fill and resize, so if you don't specify one, you get the default 12:08:51 <Wolf01> It works fine 12:08:52 <Alberth> but I don't see how it makes things move, unless you set sizes of the other widgets in some way 12:09:29 <Alberth> I'd expect SetFill(0, 0) tbh, ie no initial resizing at all 12:09:55 <Alberth> hmm, no, that would prevent other widgets from filling too 12:09:58 <Alberth> sorry 12:15:37 <Wolf01> I noticed NWID_SPACER has implicit equalsize 12:15:55 <Alberth> everything has 12:16:31 <Alberth> if you give more room than required, the remaining space gets distributed between the widgets that can fill 12:19:21 *** efess has quit IRC 12:25:12 <Alberth> although, it's not equal size, as the initial size is not taken into account 12:25:16 *** blocage has quit IRC 12:26:28 *** blocage has joined #openttd 12:28:41 <Wolf01> What I can't understand is that in the first tab the spacer works fine 12:31:02 <Wolf01> https://gist.github.com/Wolfolo/671a26d9ee339a0d72567b794950a6f0 here is the patch if you want to try it 12:53:14 <Alberth> what is exactly broken, there is no empty space at the right of "advanced" 12:53:16 *** blocage has quit IRC 12:54:50 <Wolf01> What do you mean? 12:59:30 <Alberth> windows look fine to me 12:59:53 <Wolf01> Yes, there's the SetFill 12:59:57 <Wolf01> Remove that and see 13:00:43 <Alberth> line number please? 13:00:52 <Wolf01> L:207 13:00:56 <Alberth> thank you 13:01:04 <Wolf01> L:267 sorry 13:01:22 <Wolf01> L:207 is the working one (without setfill) 13:14:39 <DorpsGek> Commit by frosch :: r27901 trunk/src/window.cpp (2017-08-27 15:14:37 +0200 ) 13:14:40 <DorpsGek> -Codechange: GetWindowZPriority only needs a WindowClass; this way it can also be used for WindowDesc before a Window instance is created. (3298) 13:15:42 <_3298> ... does that mean you intend to commit something that actually makes use of that? 13:16:00 <frosch123> no idea 13:16:07 <frosch123> still figureing out what it actually does 13:17:40 <_3298> the main point is to place windows in less-than-optimal places if there is no optimal place 13:18:07 <_3298> the best way to do that (imo) is a scoring system 13:18:44 <Alberth> Wolf01: http://devs.openttd.org/~alberth/difference_window.png 13:19:05 * _dp_ sometimes wish openttd will just place less windows 13:19:10 <frosch123> yes, but the current "put child window on top of parent" is very different to the proposed "put child window next to parent" 13:19:11 <Alberth> as you can see, the two light green areas from the top got distributed to the bottom 13:20:05 <Alberth> it's a few pixels off, but I eye-balled it, you need to get the numbers or work pixel-precise in the image editor 13:20:12 <_3298> that's actually something that comes later down the line, i just make use of the scoring system to declare positions next to the parent "optimal" 13:20:30 <Wolf01> Alberth: so what causes this? 13:20:51 <Alberth> what happens is that the default of spacer widget is not to fill, so if you leave it out, the right column cannot stretch to fill the space 13:20:58 <frosch123> _3298: you mean it's possible to split the patch and postpone the design decision onto a smaller patch? 13:21:08 <_3298> of course 13:21:19 <Alberth> so there is room around the widgets, and that gets evenly spread to other widgets in the row 13:22:15 <Alberth> or failing that, it might become lost space 13:22:51 <Alberth> filling and resizing works only if ALL widgets can do it 13:23:15 <Alberth> at least perpendicular to the direction of the container 13:23:26 <Alberth> in the direction of the container, you need only 1 widget 13:25:50 <Wolf01> Is it possible for one like me to notice this behaviour and fix the UI structure without knowing the internals? 13:32:32 <Alberth> there is no written record about default fill and resize afaik, but you can simply always specify them 13:33:22 <Alberth> Without knowledge of fill and resize, don't think you get far. However, I don't see that as "internal" 13:33:41 <Alberth> it's the core mechanism how the window is setup and resizes 13:34:57 <Wolf01> So the only alternatives are 1) try and fail; 2) post the code here and get it fixed by someone which knows exactly how it works 13:35:18 <frosch123> it works the same in other gui frameworks 13:35:21 <Alberth> I don't see how you would not need to worry about it under varying lengths of texts in the buttons and possibly varying size of the window by user-resize 13:36:22 <Alberth> just changing language already changes layout 13:38:59 <Wolf01> Ok, but taking it as a basic structure, ignoring all the possible resizing etc, do you think I should know how to fix a space which pops out from nowhere? 13:40:08 <Alberth> have you read widget.cpp lines 690 to 712? 13:40:23 <Alberth> it's described how fill and resize works 13:42:06 <Alberth> generated docs are nicer, as there are links to definitions 13:42:49 <Alberth> widget_type.h explains about the parts array line 808 and further 13:46:05 <Alberth> note that you can never ignore filling 13:46:38 <Wolf01> Fine 13:47:19 <Alberth> but yeah, it's a non-trivial system that shows unexpected behavior to new users 13:47:49 <Alberth> just like about every sub-system that does internal computations 13:48:20 <Alberth> like fios and fileio :p 13:48:42 <frosch123> i had an easier time understanding the gui :p 13:48:46 <Wolf01> The problem is: I set [label][fill][button][fill] and I get [label] void space [button][fill][fill], there is something I can't understand 13:49:20 <Alberth> labels and buttons fill too 13:49:38 <Alberth> unless you explicitly disable it, afaik 13:49:51 <Alberth> frosch123: keep it :) 13:50:04 <Alberth> makes life simpler :) 13:50:47 <Wolf01> Ok, but if I mess up the UI, I would like to know why I messed it up, without any reference, boundingbox, different colours etc I can only read the whole code and learn exactly how it works 13:51:20 <Wolf01> For example, replacing the NWID_SPACER with WWT_PANEL, the panel worked fine, right size etc, why the spacer didn't? 13:51:40 <Wolf01> Also, why the spacer worked fine in L:207 but not in L:267? 13:52:02 <Wolf01> I missed a SetFill in some other widget? Ok, which one? 13:52:30 <Alberth> maybe there is less space in line 207 13:52:42 <Alberth> ie it could be the tab that decides the window space 13:53:28 <Alberth> I can see the problem, but no idea how to fix 13:54:07 <Alberth> I had a patch that dumped the widget tree settings to stdout, which worked, but it was a mess to figure out 13:54:19 <Alberth> ie you had to study all the numbers 13:54:44 <Alberth> and it still assumed you understood how the filling and resize mechanisms work 13:55:03 <Alberth> since it's a dump after all computations are done 13:55:55 <Alberth> likely it's simpler to print the contents of the few widgets you are interested in, when you have a problem 13:55:56 <frosch123> maybe there could be a compile time switch to add a panel around every container 13:56:08 <frosch123> and then those panels get color by tree-depth or something 13:56:45 <Alberth> edges are on top of each other 13:56:47 <Wolf01> That could be a nice thing to have 13:57:01 <Alberth> unless you add 2 everywhere 13:57:39 <Wolf01> I'm fine with that, you can even explode the UI to show it better 13:58:31 <Alberth> in that case, depth isn't even needed, as edges are strictly nested inside each other than 13:58:33 <Alberth> *then 13:59:13 <Wolf01> If only... https://mdn.mozillademos.org/files/3625/3dview.png 13:59:29 <Alberth> not sure if it would help in this case 13:59:57 <_dp_> does _tick_counter overflow? 14:00:14 <Alberth> sure, just add OpenGL to OpenTTD, please :) 14:01:40 <Alberth> _dp_: date.cpp line 30: uint16 _tick_counter; ///< Ever incrementing (and sometimes wrapping) tick counter for setting off various events 14:02:12 <_dp_> Alberth, oh, right, I somehow missed () part ^^ 14:02:24 <Alberth> :) 14:02:49 <Alberth> if you look at usage, you'll see everything does & or % 14:03:16 <_dp_> anyway, it's a bit of a bug that it does 14:03:25 <frosch123> what else should it do? 14:03:32 <_dp_> coz, for example it mean towns grow ad slightly different speeds 14:03:37 <Wolf01> I started to write down a tool to preview a UI, it would be cool to be able to load the base widget list and show that, I know that resize and other changes happen when window is instanced, but it could help at least to set the initial structure with PIP, padding and see how to arrange elements 14:05:05 <Alberth> parsing a window parts array isn't that complicated, I think 14:05:34 <Wolf01> The complicate part is making it show the right way 14:05:45 <Alberth> or dump the tree after openttd constructed it 14:05:56 <Alberth> in some easy to load format 14:06:18 <Alberth> eg json or yaml 14:06:31 <_dp_> towns with index % 74 < 46 grow 0.1% faster if I done the math right 14:06:32 <Wolf01> It would be cool to use the tool to generate some basic code to copy/paste and complete 14:07:06 <Alberth> just the parts array? 14:07:10 <Wolf01> Yes 14:07:27 <Alberth> specify a tree in some format 14:07:31 <Wolf01> Already with fill, pip, colour etc 14:07:32 <frosch123> that sounds like you would end up re-impleneting the whole fill stuff 14:08:40 <Alberth> I would see it as a high-level description of the tree, which you can "compile" to the array format 14:09:01 <Wolf01> Yes frosch123, I think that is the only option to learn how things work, just looking at other UIs to copy parts doesn't seem to effective 14:09:49 <Wolf01> *to be 14:09:51 <frosch123> Alberth: sound like it would only work for entire new windows 14:10:02 <frosch123> it's even more harder to reimport an existing window 14:11:01 <Alberth> the tree is constructed, if you could get a copy before any calculation is done, you could get all data too, I think 14:11:11 <_dp_> replacing if(_current_tick % smth) with if(_current_tick == _next_smth_tick) { _next_smth_tick += smth } can fix uneven calls 14:11:15 <_dp_> also is likely faster 14:12:17 <Alberth> huh? 14:13:02 <Alberth> oh, % might not trigger, ok, that's tru 14:13:07 <Alberth> *true 14:14:25 <Alberth> Wolf01: The question is whether having the tree structure would be actually useful 14:14:48 <Alberth> ie it's a tree with a zillion numbers 14:15:22 <frosch123> adf88: change it to uint32 to reduce the effect by factor 64k? 14:15:30 <frosch123> _dp_: ^^ not adf 14:15:44 <_dp_> xD 14:15:48 <frosch123> underscores are hard 14:16:09 <_dp_> frosch123, yeah, but imo adding _next is better 14:16:36 <Alberth> but it breaks having a single counter 14:17:22 <_dp_> I'm also thinking of it in context of town growth, and it has grow_counter already which can be replaced by next thingie 14:17:58 <Wolf01> Alberth: I don't want to change the structure, I just need to show it in a format I can read, and since I'm used with xml, xaml, html, I just want a tool for fast UI prototyping 14:19:04 <Wolf01> I think I could make the same without tree structure even in html+js 14:19:30 <_dp_> only problem I see with _next is that it'll break if tick is skipped for whatever reason, but that shouldn't happen anyway 14:19:31 *** sim-al2 has quit IRC 14:24:54 <_dp_> only towns and stations seem to be affected by % problem, all other stuff works in powers of 2 14:25:18 <Alberth> NWID_MATRIX does exist, no idea what it does :) 14:25:57 <Wolf01> The depot windos 14:26:01 <Wolf01> *window 14:26:18 <Alberth> :O of course 14:39:26 <planetmaker> @op adf88 14:39:30 <planetmaker> :P 14:39:37 <planetmaker> @whoami 14:39:37 <DorpsGek> planetmaker: I don't recognize you. 14:39:41 <planetmaker> ah yes 14:39:48 <planetmaker> @cycle 14:40:43 <planetmaker> @op adf88 14:40:43 *** DorpsGek sets mode: +o adf88 14:41:44 <Alberth> :O 14:41:51 <adf88> i'm here 14:42:02 <adf88> ssh account works flwlessly 14:42:33 <Alberth> congrats ! 14:43:29 <_dp_> hmm, is it ok to drop support for town growth speeds that are slower than 1 house in 1000 days? 14:43:32 <planetmaker> wonderful :) 14:43:48 <_dp_> like I can change to bigger type but who the heck needs those anyway? 14:43:52 <planetmaker> not sure whether I can really change adf88's permissions with dorpsgek 14:44:22 <frosch123> _dp_: which towns does that affect? 14:44:42 <frosch123> iirc there is some special code to make small desert towns grow to ensure that they accept food at some point 14:45:08 <_dp_> frosch123, nah, it has nothing to do with it 14:45:22 <_dp_> frosch123, it's not even possible to achieve such slow speeds without GS 14:46:40 <_dp_> well, mb 0 houses town without stations will grow at about that speed but not any reasonable one 14:49:34 *** blocage has joined #openttd 14:49:52 <_dp_> lol, town with 1 station grows slower than town with 0 14:50:14 <_dp_> wonder if that's intended or just typo xD 14:54:04 <Alberth> Wolf01: http://devs.openttd.org/~alberth/genworld_dump.txt http://devs.openttd.org/~alberth/dump_widget_tree.patch 14:54:13 <Alberth> quick&dirty patch 14:54:50 <_3298> frosch123, i've split the window placement patch for FS#5451 into two parts; are those more understandable or should i split the first part further? 14:55:09 <Wolf01> Alberth: nice 14:55:32 <Alberth> until you find a 0 or 1 in a sea of numbers :p 14:55:39 <Alberth> *look for 14:56:31 <Alberth> which is why I am not sure this actually helps 14:57:02 <Wolf01> WWT_PANEL(fill=(1, 0), resize=(0, 0), smallest=(304, 4), current=(304, 4), pos=(10, 144)) <- did you put the panel instead of the spacer? 14:57:20 <Alberth> oh, could be an experiment 14:57:53 <_dp_> frosch123, ok, just checked, slowest growth speed without GS is about 1house/200 days, so base game won't be affected in any way 14:57:56 <Alberth> yes, just a test 14:59:04 <Wolf01> Mmmh, I could edit that to dump html 14:59:47 <Wolf01> Could it dump strings or other stuff? 14:59:47 <Alberth> any format, basically :p 15:00:06 <Wolf01> For example the label text? 15:00:16 <Wolf01> Or you just have the uint32? 15:00:20 <Alberth> sure, it's dumped while running, so everything is there 15:00:36 <Alberth> no it's all there, or you cannot compute widget size 15:00:48 <_dp_> damn, TOWN_GROW_RATE_CUSTOM takes one bit so it'll be 1 house / 500 days at slowest 15:00:57 <Alberth> but it needs code to convert number to text, of course 15:01:06 <_dp_> still twice slower than anything achievable without GS 15:01:28 <Alberth> likely fake painting the widget 15:01:44 <Alberth> might be less than trivial 15:01:58 <Alberth> setting dparam etc 15:02:40 <Alberth> _dp_: can't make it stop growing? 15:02:48 <Wolf01> I'll try to look why it changes between the 2 versions of the spacer 15:03:07 <_dp_> Alberth, there is special flag to stop growing 15:03:23 <Alberth> so just stop it temporarily in GS? :) 15:03:30 <Wolf01> I was about to ask "were it dups the stuff?" then I noticed the wall-o-text 15:03:43 <_dp_> Alberth, sure, that's what GS should be doing 15:03:51 <planetmaker> well, seems I don't have dorpsgek admin power 15:04:26 *** blocage has quit IRC 15:04:27 <Alberth> dorpsgek is a bit picky :) 15:04:53 <Alberth> doesn't always obey the regular authorities :) 15:05:22 <_dp_> Alberth, that's why I think it's fine to drop compatibility there 15:06:54 <Alberth> tbh I don't know if it's worth the trouble, 1/250 days, is pretty much once a year 15:07:27 <Alberth> at that rate you get nowhere in a competition 15:07:55 <TrueBrain> Alberth: who did give you commit permission? (Sorry, reading old thread) 15:08:04 <_dp_> Alberth, what's worth? I want to allow faster speeds but instead of switching to uint32 I think of dropping slower ones 15:08:09 <Wolf01> WTF, they removed the diff tool from NP++? 15:08:50 <Alberth> TrueBrain: there is small yet distinct difference between real authorities and regular authorities :p 15:09:27 <TrueBrain> I am afraid they overlapped in this case :P 15:09:42 <Alberth> RB asked me 15:09:44 <TrueBrain> (sorry, you made me giggle hard, with your: somebody stupid enough :D) 15:10:10 <_dp_> Alberth, so it's basically slow speeds vs 2 extra bytes per town and some more code 15:10:32 <Alberth> TrueBrain true reason was that he was fed up adding my patches :p 15:10:52 <TrueBrain> as how things go :) 15:11:27 <TrueBrain> also holds for regular work ... if you ask the same people to do your stuff over and over, sooner or later they just give you access :D 15:11:52 <frosch123> you can also forward questions to them 15:12:35 <frosch123> "no time, just ask that other guy", i always wonder whether that chains 15:12:53 <TrueBrain> at my work, that chains pretty quickly :D 15:13:01 <TrueBrain> "ask that guy" - "he told me to ask you" 15:13:02 <frosch123> does it go in circles? 15:13:05 <TrueBrain> *shit* 15:13:15 <TrueBrain> its always the hope they ask me first 15:13:17 <TrueBrain> :D 15:13:25 <Alberth> :D 15:13:57 <Wolf01> HA! Alberth: http://imgur.com/a/SyaCo 15:14:17 *** blocage has joined #openttd 15:14:45 <TrueBrain> Wolf01: wtf is wrong with you? THAT NESTING! :P 15:15:06 <Wolf01> It's a dump 15:15:07 <Alberth> Wolf01: so the text-widget grew, now what? 15:15:15 <TrueBrain> please keep those in toilets 15:15:22 <Alberth> ie it doesn't point to the cause 15:15:37 <Wolf01> The spacer enabled the fill on NWID_HORIZONTAL and NWID_VERTICAL 15:16:08 *** Flygon has quit IRC 15:16:27 <TrueBrain> omg, even Darkvater replied on the forums? I totally forgot about how (SORRY!) .. blast from the past, damn 15:16:30 <Alberth> I am surprised you get only one line change then 15:16:40 <frosch123> TrueBrain: at work we have a legacy/deprecated configuration file format named "dump" :p 15:17:05 <TrueBrain> that is why I always clal my configuration files .data 15:17:10 <TrueBrain> just so I know it will piss off the next person 15:17:52 *** jinks has quit IRC 15:17:58 <Alberth> stuff.data 15:18:50 <Wolf01> Alberth: By default they don't fill horizontally, so I should put SetFill(1,1) on the containers and not the spacer 15:19:04 <Alberth> Wolf01: oh sorry, that white line is the cursor, all yellow is change 15:19:32 <Alberth> except containers derive from child widgets, so no 15:20:09 <Alberth> ie containers have no size of themselves, it's all from their childs 15:20:26 *** jinks has joined #openttd 15:20:26 <Alberth> the panel is a bit in-between, so it can have size 15:20:36 <Wolf01> Like in html, empty div is invisible 15:22:34 <Alberth> what you see is the spacer setting made resize consistent in its container, so it gets propagated upwards 15:22:42 <Alberth> *fill 15:23:09 <Wolf01> Ok, it's right 15:23:46 <Wolf01> The problem is not shown there, widgets are just smaller in the right 15:24:35 <Wolf01> The only difference is the fill enabled on the spacer 15:26:33 <Alberth> yep, while the dump has all the numbers, it's still not quite trivial to found the problem 15:26:45 <Alberth> *find 15:26:52 <Alberth> <bleh/> 15:27:24 <TrueBrain> ugh, I am always reminded why I nowedays dislike IRC when I try to do things for OpenTTD :P (sorry :D Last project standing for me ... :D) 15:28:11 <TrueBrain-Bot> which reminded me I had a discord bridge 😄 15:28:23 <TrueBrain-Bot> one which does smilleeeyyyssssssss 15:28:54 <LordAro> oh dear 15:29:06 <TrueBrain-Bot> well, you know how much I love my smilies 😃 15:29:06 <Alberth> like :bleh: ? 15:29:17 <TrueBrain-Bot> yup! Pretty and all 😃 15:29:25 <LordAro> :slightly_smiling_face: 15:29:32 <TrueBrain-Bot> I love how my IRC client doesn't understand UTF8 😛 15:29:41 <Alberth> mine does :) 15:29:47 <LordAro> sounds like you need a better client 15:29:47 <Wolf01> Mine too 15:29:56 <Wolf01> Or just change font 15:30:11 <TrueBrain-Bot> I don't need a better client; you guys need to stop living in 1990 😛 😛 15:31:14 <LordAro> you disappoint me, TrueBrain 15:31:20 <TrueBrain-Bot> as I should! 15:31:29 <LordAro> fair point 15:31:31 <LordAro> :p 15:31:38 <TrueBrain-Bot> happy we could keep this brief 😃 15:31:39 <Wolf01> mIRC is old but still works, I don't miss smileys and images, ok, maybe images yes 15:32:02 <Wolf01> For smileys there's always (extended)ascii art 15:32:21 <Wolf01> ᕕ( ᐛ )ᕗ 15:33:21 <TrueBrain-Bot> mIRC .. lol .. 15:33:22 <LordAro> (╯°□°)╯︵ Ɩ0ɟloM 15:33:33 <TrueBrain-Bot> sorry, my grandpa called, he said he wants mIRC back 15:33:44 <Wolf01> ಥ╭╮ಥ 15:34:20 <planetmaker> honestly... I'm not sure I find other chat options really nicer than IRC 15:34:28 <TrueBrain-Bot> Discorddddddddddddd 15:34:33 <planetmaker> they don't really work better 15:34:43 <TrueBrain-Bot> no, you just need to get used to them 😃 15:34:51 <Wolf01> Also I have many (one) friend on irc 15:34:55 <TrueBrain-Bot> but having multiple devices working in sync ... its so lovely ... 15:35:06 <planetmaker> yeah... but change for the sake of it? 15:35:08 <TrueBrain-Bot> not having to be online 24/7 for your client to track everything .... 15:35:16 <TrueBrain-Bot> change is good! 15:35:19 <planetmaker> I don't ... that's a bouncer for 15:35:28 <TrueBrain-Bot> and clients rarely understand bouncers 15:35:31 <Wolf01> When discord will support whatsapp and telegram too I could try it 15:35:35 <TrueBrain-Bot> so you see the timestamp of your connect 😛 15:35:47 <planetmaker> I do 15:36:30 <TrueBrain-Bot> but, this always reminds me of XKCD: https://xkcd.com/1782/ .. I think it is true .. 15:36:33 <planetmaker> for the love and hate, there's so many chat options. And every and anyone wants and likes another. But neither talks nicely to a 2nd one 15:36:36 <planetmaker> such a pain 15:36:40 <LordAro> irssi 4 lyfe 15:36:50 <TrueBrain-Bot> hence my IRC <-> Discord bridge 😄 15:36:58 <TrueBrain-Bot> fuck you oldies 😛 (but I do love you guys) 15:37:25 <planetmaker> tehehe :) 15:37:28 <planetmaker> sure that's true 15:37:32 <LordAro> how much does matrix do these days? 15:37:37 <TrueBrain-Bot> 12 15:38:39 <Alberth> online 24/7 is grossly over-estimated :p 15:39:01 <TrueBrain-Bot> sorry, I couldn't hear youover this IRC wire 15:39:08 <TrueBrain-Bot> *trolls happily* 15:39:09 <LordAro> https://xkcd.com/1810/ is more relevant 15:39:41 <TrueBrain-Bot> why more? why being so insulting? omg! Learn manners! 😄 15:39:41 <LordAro> which doesn't even have discord on it 15:39:50 <LordAro> ^ discord user right there 15:39:51 <Alkel_U3> I tried the weechat-matrix plugin but in this particular case it's pretty difficult to get encryption. Other than that I think Matrix has what it takes to eventually replace IRC 15:40:05 <TrueBrain-Bot> I am pretty sure I am bored ... so I will annoy you guys a bit more 😃 15:40:13 <Alkel_U3> well, not counting resistance to change :P 15:40:13 <LordAro> yeah, i think matrix has potential 15:40:19 <LordAro> but it's not ready yet 15:40:27 <TrueBrain-Bot> "eventually replace IRC" .. THERE IS NO REPLACING IRC! 😦 15:40:54 <planetmaker> oh, so true @ LordAro :) 15:41:12 <planetmaker> maybe I should give pidgin a try 15:41:14 <LordAro> frosch123: didn't you say you had issues connecting to the compile farm? while TrueBrain's here and all, might be worth looking into... 15:41:30 <frosch123> oh, those were fixed 15:41:35 <LordAro> ah 15:41:38 <TrueBrain-Bot> he bugged me already 😛 15:41:41 <LordAro> ^^ 15:42:06 <TrueBrain-Bot> and I tried to finish my OSX cross-compiler in Docker 15:42:14 <TrueBrain-Bot> only to find out it still doesn't work 😦 15:42:44 <planetmaker> or again doesn't. It's not like OSX is a fixed target ;) 15:42:52 <TrueBrain-Bot> it tried to compile a system library against OpenTTD .. which for some reason was not compatible ... (a x86_64-linux library against 10.8 OSX :P) 15:42:55 <frosch123> LordAro: my plan is to make tb publish what is done and what needs doing, and then you to finish it :) 15:43:01 <LordAro> :< 15:43:15 <TrueBrain-Bot> owh, is he the victim? Gooooddddd 😛 15:43:24 <TrueBrain-Bot> planetmaker: which is a good point .. do we support OSX? 15:43:39 <frosch123> TrueBrain-Bot: he explored external compile services and setup like 5 targets 15:43:55 <TrueBrain-Bot> 10.3.9 - 10.5 15:43:58 <TrueBrain-Bot> lol 15:44:01 <frosch123> TrueBrain-Bot: it works for those who compile themself 15:44:14 <LordAro> https://github.com/LordAro/OpenTTD/commit/3d58bef57b80efe9483521cd7e5ec8f531a11058 15:44:15 <TrueBrain-Bot> yeah .. cross-compiling is really tricky 15:44:17 <TrueBrain-Bot> even more with 10.12 15:44:24 <frosch123> people who use the binaries report crashes regulary, which may be related or may not 15:44:29 <LordAro> and apparently i got rid of the actual circleci stuff, let me readd 15:44:55 <TrueBrain-Bot> ah, CI stuff 15:44:57 <TrueBrain-Bot> that is good 15:45:12 <TrueBrain-Bot> I have most stuff for releases (except OSX) ready 15:45:41 <TrueBrain-Bot> wait, I was trying to order food 15:45:42 <TrueBrain-Bot> ffs 15:46:05 <frosch123> get your priorities right :) 15:46:14 <TrueBrain-Bot> I am! Which makes me more hungry .. 15:47:44 <Alberth> order more ? 15:47:52 <TrueBrain-Bot> it is the time it takes 15:47:53 <TrueBrain-Bot> which is the issue 15:48:21 <frosch123> Alberth: interesting singularity, whenever half of the order time passed, order agani 15:48:28 <TrueBrain-Bot> and take-out is by 15 minutes, so because I missed 17:45, I can now only pick itup at 18:15, instead of 18:00 15:48:56 <Alberth> oh dear 15:49:37 <LordAro> https://circleci.com/gh/LordAro/workflows/OpenTTD there we go 15:50:07 <TrueBrain-Bot> http://devs.openttd.org/~truebrain/docker-openttd-cf/ and there I go 15:50:50 <TrueBrain-Bot> it doesnt fully work yet, because we copy our debian files outside the source directory .. and than you have permissions to fix in docker 15:50:52 <TrueBrain-Bot> which is annoying 15:51:05 <Alberth> frosch123: now if delivery time also halves each time... 15:51:17 <TrueBrain-Bot> and OSX fails to do compile-rt on 10.8, but 10.6 build-ish .. only the endianness is wrong 15:51:21 <Alberth> not sure you want to be around when you hit 0 :) 15:51:52 <TrueBrain-Bot> frosch123: that is all I have for now; if we have working Docker-files, I can fix up the CF easily 15:52:39 <TrueBrain-Bot> (but moving to git (or even github) might not be the worst idea either :D) 15:53:06 <frosch123> well, we can only run so many payed services 15:53:14 <LordAro> < Alberth> grumbly noises 15:53:16 <frosch123> the admin effort is likely exponential 15:54:05 <TrueBrain-Bot> owh, and btw, we really need someone who redoes both our website and BaNaNaS 15:54:10 <TrueBrain-Bot> it is getting really old ... 😄 15:54:21 <frosch123> so, a single server is easier to purchase every year, than 2 different compile farms (circleci does not do windows) and a main server 15:54:46 <frosch123> yeah, the bananas thing is a mistery to me 15:54:56 <TrueBrain-Bot> ah, yes; we got a bit hijacked into two conversations 15:55:01 <TrueBrain-Bot> we can run the CF ourself just fine 15:55:05 <TrueBrain-Bot> it is more the subversion which is annoying 😄 15:55:07 <frosch123> there should be so many web-cruds, why does noone volunteer? 15:55:21 * LordAro tentatively raises his hand 15:55:25 <TrueBrain-Bot> a docker-based CF is piss-easy to maintain, so 😃 15:55:36 <LordAro> TrueBrain-Bot: yeah, but cross compiling is so ew 15:55:41 <frosch123> TrueBrain-Bot: we kind of do not need subversion anymore 15:55:50 <TrueBrain-Bot> go git, go git 15:56:00 <TrueBrain-Bot> LordAro: Windows also supports docker 😃 15:56:08 <frosch123> the old argument "linear version number" is kind of deprecated, noone uses that anyway 15:56:27 <LordAro> semver for releases still holds strong, however 15:56:32 <TrueBrain-Bot> host code at github, easy PR and all that easy shit 15:56:48 <TrueBrain-Bot> or ... we can install gitlab/github enterprise/bitbucket server 15:56:55 <TrueBrain-Bot> which .. kinda works too I guess 😛 15:56:59 <LordAro> gitlab does come with its own CI stuff 15:57:02 <LordAro> ¯\_(ツ)_/¯ 15:57:03 <frosch123> i would go for host less ourself :) 15:57:08 <TrueBrain-Bot> and bug tracker, and ... 15:57:11 <LordAro> and i know i guy who works there 15:57:15 <TrueBrain-Bot> frosch123: that is wha tI am aiming for yes 😄 15:57:16 <LordAro> a guy* 15:57:25 <TrueBrain-Bot> I know a girl who worked there! HIGH FIVE! 15:57:35 <LordAro> ^^ 15:57:44 <TrueBrain-Bot> gitlab is nice, but I wonder if they support squasing by now .... 15:57:51 <TrueBrain-Bot> sometimes it are those silly things ... 15:58:11 <LordAro> tbf, github only got it a year or so ago 15:58:20 <TrueBrain-Bot> I know 😦 15:58:26 <TrueBrain-Bot> BitBucket Server still doesnt' have it 15:58:33 <TrueBrain-Bot> well, -ish 15:58:40 <TrueBrain-Bot> it is such a wonderful feature ... 15:58:49 <TrueBrain-Bot> but in BitBucket Server you cannot change how the commit message looks 15:58:51 <TrueBrain-Bot> which is stupid 15:58:55 <TrueBrain-Bot> gitlab has stupid stuff too 15:59:05 <TrueBrain-Bot> GitHub Enterprise is hilarious .. comes as an Appliance ... you need VMWare ... 15:59:10 <TrueBrain-Bot> I laughed my ass off, twice 15:59:34 <LordAro> yeah 15:59:39 <TrueBrain-Bot> let me find that vendor-lock switch 15:59:41 <TrueBrain-Bot> owh, there it is 15:59:43 <TrueBrain-Bot> *flip* 16:00:20 <planetmaker> TrueBrain, dunno whether we support it. I don't really have any working Mac hardware anymore 16:00:23 <TrueBrain-Bot> honestly, things like GitHub (or BitBucket for all I care) makes things easier .. you no longer need FS etc .. all in one place 16:00:47 <TrueBrain-Bot> lovely client-applications 16:00:47 <LordAro> https://about.gitlab.com/features/gitlab-ci-cd/ ¯\_(ツ)_/¯ 16:01:00 <TrueBrain-Bot> yes, lets put OpenTTD in a CD 16:01:06 <TrueBrain-Bot> you auto-deploy a new version to all systems 16:01:10 <TrueBrain-Bot> which have OpenTTD installed 😄 16:01:16 <TrueBrain-Bot> :D:D:D:D 16:01:26 <LordAro> :P 16:01:54 <TrueBrain-Bot> but we can indeed run GitLab ourself (I refuse to run GitHub Enterprise, sorry) 16:02:06 <TrueBrain-Bot> still better than having a FS which is disconnected from the source tbh 😃 16:02:14 <TrueBrain-Bot> integration is POWERFULLLLLL 😄 16:02:21 <LordAro> ^ amen to that 16:02:31 <TrueBrain-Bot> just my 2 cents .. 😄 16:02:35 <TrueBrain-Bot> time to get my fooddddd 16:02:39 <TrueBrain-Bot> I have annoyed you guys enough 😛 16:02:39 <TrueBrain-Bot> o/ 16:03:02 <LordAro> i'm not entirely convinced you're not hammered 16:03:07 <LordAro> but o/ 16:03:25 <TrueBrain-Bot> owh, PS: frosch123: another approach is going for AWS etc .. 😄 16:03:36 <TrueBrain-Bot> there is your proof LordAro 😄 16:03:40 <LordAro> haha 16:04:56 <frosch123> meh, i am too nooby to get jokes in that area :/ 16:05:24 <LordAro> i'm not sure OTTD has enough money for AWS 16:05:33 <TrueBrain-Bot> Who said I was joking? 16:05:47 <TrueBrain-Bot> Most likely cheaper tbh 16:05:56 *** planetmaker has left #openttd 16:05:57 <TrueBrain-Bot> I can do that math ... 16:06:35 <LordAro> really? i have to admit i've never looked into it significantly myself 16:06:44 <LordAro> i've always got the impression it was expensive though 16:07:26 <DorpsGek> Commit by adf88 :: r27902 trunk/config.lib (2017-08-27 18:07:24 +0200 ) 16:07:27 <DorpsGek> -Feature [FS#6614]: Preserve PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR environment variables in config.cache file (just like other variabes CFLAGS, LDFLAGS etc.) so they can be resused when OpenTTD re-configures itself 16:07:36 <LordAro> \o/ 16:07:48 <LordAro> grats on the promotion, adf88 16:08:04 <frosch123> LordAro: see, you have the chance to become cf admin :) 16:08:26 <LordAro> :) 16:08:37 *** planetmaker has joined #openttd 16:08:37 *** ChanServ sets mode: +o planetmaker 16:08:39 <frosch123> so many career paths without payment 16:08:47 *** planetmaker has left #openttd 16:09:03 <TrueBrain-Bot> Plenty of those :D 16:09:09 <TrueBrain-Bot> Gratz adf88 16:09:44 <TrueBrain-Bot> And only expensive is the CF 16:11:16 <TrueBrain-Bot> Still would need a new website and BaNaNaS :D 16:11:33 <LordAro> what's particularly wrong with the website & BaNaNaS? 16:11:55 <TrueBrain-Bot> Django 1.2 .. nuff said 16:12:01 <LordAro> ah 16:12:11 <TrueBrain-Bot> Python 2.5 ... 16:12:17 *** planetmaker has joined #openttd 16:12:17 *** ChanServ sets mode: +o planetmaker 16:12:19 <frosch123> LordAro: users cannot rename stuff, lots of other missing features 16:12:25 <TrueBrain-Bot> Site from 2009 ... 16:12:51 <milek7> what's wrong with site from 2009? 16:12:52 <TrueBrain-Bot> The design still stands, funny enough 16:13:40 <frosch123> @calc 365*2*10*2*0.005 16:13:40 <DorpsGek> frosch123: 73 16:14:05 <TrueBrain-Bot> I did rebuild it in Angular2 .. but we have users without Javascript :D 16:14:07 <frosch123> aws compile farm would cost us 70$/year 16:14:21 <frosch123> that's way cheaper than the other offers 16:14:28 <frosch123> but i think they do not compile for windows either 16:14:29 <TrueBrain-Bot> Sounds about right 16:14:42 <milek7> appveyor is free 16:15:00 <LordAro> yeah, need to investigate appveyor 16:15:14 <frosch123> otoh, we already have a server :p 16:18:55 <TrueBrain-Bot> let me rephrase than: if we can switch to git, other possibilities besides FlySpray open up 😄 16:19:22 *** mescalito has joined #openttd 16:20:14 <planetmaker> can't say that I'd find that terrific... but it might actually be of advantage 16:20:24 <LordAro> ultimately it's obviously up to you guys with the little '@' next to your names, but i think it'd be a good thing overall 16:20:33 <LordAro> github does even have a svn bridge :p 16:20:46 <TrueBrain-Bot> he is an hg fan 😛 16:20:56 <TrueBrain-Bot> those still exist 😄 16:20:58 <planetmaker> it would mostly require some thoughts on how to handle the versioning scheme of OpenTTD 16:21:09 <planetmaker> yes, they do ;) 16:21:19 <frosch123> all of the reasonable patchpacks use git 16:21:19 <Alberth> switch to random 40 digit hex numbers 16:21:22 <LordAro> i see no reason why stable version needs to change at all 16:21:40 <LordAro> nightly might be a bit trickier, but datestamp is feasible 16:21:43 <frosch123> so, git/github are obvious options 16:21:55 <frosch123> it's just a lot of migration work, that would break everything for a while :p 16:21:57 <Alberth> pretty close to the only options 16:22:04 <LordAro> anything else can use the 10(?) digit hex value that they do already 16:22:06 <TrueBrain-Bot> migration? 😄 16:22:09 <planetmaker> stable versions don't need much change. But the nightly builds etc need a continuous numbering 16:22:18 <TrueBrain-Bot> we already support git and hg 16:22:19 <Alberth> LordAro: 7 iirc :) 16:22:19 <frosch123> planetmaker: not really 16:22:21 <planetmaker> and for NewGRF versions for NewGRFs to decide where they run on 16:22:27 <TrueBrain-Bot> we only need to do something like: 7.0-123 16:22:29 <LordAro> YYYYMMDD 16:22:33 <TrueBrain-Bot> where 123 is the amount of commits since 7.0 😄 16:22:34 <frosch123> noone uses that, we can just drop the linear version 16:22:41 <planetmaker> LordAro: *that* doesn't work even for NewGRFs 16:22:41 <LordAro> gonna be a lot larger than the current ~27000 16:22:42 <frosch123> stable version is enough 16:22:49 <LordAro> why not? 16:23:10 <planetmaker> is there something like stable-commits-since-last-stable? 16:23:24 <TrueBrain-Bot> yes 16:23:30 <planetmaker> 1.7.3-73 16:23:38 <planetmaker> or so for the 73rd commit based on 1.7.3 16:23:49 <TrueBrain-Bot> litterly what I just said 😛 16:24:03 <planetmaker> but... it might be ambiduous when there's two branches... but name them differently. dev and stable or so 16:24:05 <LordAro> i mean, since 1.7.3 doesn't make much sense because of branch 16:24:10 <LordAro> but 1.7.0 could work 16:24:26 <LordAro> but... why? 16:24:26 <frosch123> TrueBrain-Bot: with migration i mean stuff like compilefarm, eints, hg/git bridges, ... 16:24:28 <TrueBrain-Bot> you dont branch like that 16:24:35 <TrueBrain-Bot> you branch 1.7, not 1.7.3 16:24:38 <TrueBrain-Bot> you tag 1.7.3 16:24:42 <LordAro> aye 16:24:42 <TrueBrain-Bot> so you get 1.7.3-131 16:24:42 <planetmaker> yes, of course 16:24:57 <TrueBrain-Bot> which goes fine with multiple branches 16:24:58 <planetmaker> but the current trunk won't be 1.7.3-131, but... what would it be? 16:25:03 <TrueBrain-Bot> just not multiple repos 😄 16:25:04 <LordAro> oh, i see 16:25:09 <frosch123> planetmaker: trunk is 1.8 16:25:13 <LordAro> so trunk would be 1.8.0-foobar 16:25:15 <frosch123> that's already the case today 16:25:15 <TrueBrain-Bot> trunk is 1.8-dev-123 or so 😛 16:25:15 <planetmaker> but not yet tagged 16:25:24 <frosch123> but already in rev.cpp.in 16:25:35 <planetmaker> yeah... probably like TB says 16:25:40 <frosch123> and the number would not start at branching of 1.7, but at r0 16:25:53 <TrueBrain-Bot> CF already supports git 16:25:56 <TrueBrain-Bot> we compile from GitHub 16:26:04 <LordAro> lol 16:26:04 <frosch123> we do? :o 16:26:07 <TrueBrain-Bot> hg bridge ... maybe time to say: sorry, not sorry 16:26:14 <TrueBrain-Bot> eints .. no clue 😄 16:26:29 <frosch123> eints does support git iirc 16:26:33 <LordAro> well hg-git is a thing 16:26:34 <TrueBrain-Bot> frosch123: some patchpacks compile from github 16:26:36 <TrueBrain-Bot> not trunk 😃 16:26:43 <planetmaker> hg-git works mostly 16:27:27 <planetmaker> eints... we shall see. But likely no deal breaker 16:27:53 <frosch123> eints runs with git projects on devzone 16:28:29 <TrueBrain-Bot> I hear nobody complaining, so .. we can draw up a small plan? 16:28:36 <TrueBrain-Bot> we just need to figure out what to use to host git 16:28:43 <TrueBrain-Bot> (github, gitlab, BitBucket, BitBucket Server, ..) 16:28:54 <TrueBrain-Bot> direct hosted ... *facepalm* 16:29:03 <frosch123> we are already on github and all patches are there 16:29:10 <LordAro> i would personally suggest gitlab over github 16:29:21 <TrueBrain-Bot> gitlab allows eaiser CI 16:29:23 <LordAro> purely for the builtin CI 16:29:26 <TrueBrain-Bot> ^^ 16:29:33 <frosch123> though i guess in the end it does not matter 16:29:34 <TrueBrain-Bot> but github is more mainstream 16:29:35 <Alberth> planetmaker: I tried that with github, it technically works, but don't try to do thing the hg way too much, in my experience 16:29:36 <TrueBrain-Bot> so there is a balance 16:29:48 <LordAro> aye 16:29:59 <frosch123> would we use the webinterface to commit stuff, or still push to openttd.org, which then syncs? 16:30:02 <milek7> github cannot be self-hosted 16:30:08 <LordAro> *sanely 16:30:14 <TrueBrain-Bot> frosch123: I prefer the first, not the latter 16:30:18 <frosch123> in the latter case it does not matter whether github/lab, we can just sync both 16:30:27 <TrueBrain-Bot> milek7: GitHub Enterprise is not on the table; I am not vendor-locking to VMWare 😛 16:30:42 <TrueBrain-Bot> I prefer to use PRs and accept patches like that 16:30:51 <TrueBrain-Bot> instead of pushes by "those who have the keys" 16:30:56 <LordAro> gitlab does have the ability to sync from an external source 16:31:21 <TrueBrain-Bot> (in other words, no raw access to the underlaying git repos directly) 16:31:39 <LordAro> https://gitlab.com/help/workflow/importing/migrating_from_svn oh hey 16:31:41 <milek7> gitlab problem is that its interface feels wrong 16:31:55 <TrueBrain-Bot> it only feels wrong because you are used to github 😄 16:32:00 <TrueBrain-Bot> takes a bit of time to get used to 16:32:03 <Alberth> TB gitlab/hub has the concept of protected branch, which solves that 16:32:04 <TrueBrain-Bot> same for BitBucket Server I noticed 😛 16:32:11 <TrueBrain-Bot> Alberth: exactly 16:32:29 <milek7> it looks like somebody designed it for phones, and than used that on desktop browsers 16:32:30 <Alberth> and I am +1 to that policy :) 16:32:37 <LordAro> https://docs.gitlab.com/ee/administration/custom_hooks.html hmm 16:32:38 <TrueBrain-Bot> frosch123 asked if we sync to github after a push to local git .. tha tI rather don't 😃 16:32:58 <TrueBrain-Bot> from experience, the software to use is rather up-to-taste .. they all have issues and benefits 16:32:59 <Alberth> milek7: it's github, but nobody is really designing a CSS for it 16:33:19 <TrueBrain-Bot> but wanting to switch to a frontend before git, is the main switch 😃 16:35:55 <TrueBrain-Bot> for me, gitlab vs github is more about: who is going to maintain what? 😃 16:35:59 <TrueBrain-Bot> but I am lazy 😄 16:36:21 <Alberth> LordAro: https://www.atlassian.com/git/tutorials/migrating-overview 16:36:52 <Alberth> first 3 or so pages you can safely skip :) 16:36:57 <TrueBrain-Bot> for no reason what-so-ever we are at step 3 😛 16:37:15 <TrueBrain-Bot> 4 even 😄 16:37:34 <TrueBrain-Bot> just github things I made all those commits .. it keeps giving people who follow me notificatiosn I pushed those commits 😄 16:37:38 <TrueBrain-Bot> which makes me giggle every single time 😃 16:37:53 <LordAro> ha 16:39:18 <LordAro> so, the next step is to decide between github.com, gitlab.com, or gitlab self hosted 16:39:22 <planetmaker> Alberth: yes... you cannot work too much with what makes hg actually nice. I know :( 16:39:23 <LordAro> (or bitbucket, i guess) 16:39:48 <TrueBrain-Bot> LordAro: first choice is: git, yes/no. Than: frontend before git yes/no. Only than you can talk about what software 😃 16:39:51 <TrueBrain-Bot> the software is a minor detail 16:40:17 <TrueBrain-Bot> frontend allows more restrictions, easier configuration, PR tracking, comment tracking, etc 16:41:39 <LordAro> there's no reason to switch to git without having the frontend in place, otherwise there's just no point 16:41:49 <planetmaker> kallithea :) 16:42:05 <TrueBrain-Bot> I agree LordAro. But consensus is important 😃 16:42:10 <planetmaker> or rhodecode... they changed their policy again to be (a)gpl. Not sure I can trust that, though 16:42:47 <LordAro> kallithea looks a bit dead, in terms of releases 16:42:49 <planetmaker> but tbh... having pull requests working is a big bonus. But that's likely supported by everything 16:43:24 <TrueBrain-Bot> PRs are so cool 😄 16:43:36 <TrueBrain-Bot> no more .patch files in a bug-tracker (?!?!?!?! :D) 16:43:50 <LordAro> what about .diff files? 16:43:50 <planetmaker> oh, I think one should still accept those 16:43:57 <planetmaker> however... no need for those 16:44:16 <TrueBrain-Bot> nobody should accept those 😛 Make a PR or go away 😛 16:44:32 <TrueBrain-Bot> giving feedback on a static file is so 1990 😄 16:45:07 <planetmaker> giving feedback on a dynamic file is not exactly something which works. Having the possibility to comment on the code on a per-line basis would be a big pro 16:45:10 <LordAro> i'd say that there would be the occasional person who would be opposed to git(hub/lab/w/e), but if the issues is also hosted on this frontend... 16:45:30 <planetmaker> be that the diff or the code itself... in the latter case it needs proper highlighting of what changed 16:46:22 <TrueBrain-Bot> so yeah ... BitBucket vs BitBucker Server vs Gitlab vs GtHub 😄 16:46:26 <TrueBrain-Bot> Python went to GitHub .. just saying 16:47:07 *** FLHerne has quit IRC 16:47:42 <_dp_> is there anything that didn't go to github? 16:47:48 <TrueBrain-Bot> we! 16:47:51 <TrueBrain-Bot> 😛 16:48:03 <_dp_> figured :p 16:48:07 <_dp_> anything else? 16:48:14 <TrueBrain-Bot> BitBucket has more than a few 16:48:19 <LordAro> planetmaker: have you seen github code reviews lately? they're getting rather good, and can cope with the file changing underneath it 16:49:57 <TrueBrain-Bot> I think going GitHub with the CF self-hosted is the easiest/most-robust way to go 16:50:07 <_3298> <_dp_> is there anything that didn't go to github? <- freedroidrpg seems to be on gitlab 16:50:27 <LordAro> https://github.com/SFTtech/openage/pulls openage have one of the best github integration setups i've seen 16:50:42 <LordAro> and they manage to get people to rebase their PRs too :) 16:50:51 <TrueBrain-Bot> there is a button for that 😛 16:50:56 <_dp_> _3298, never heard of that one :p 16:51:12 <LordAro> TrueBrain-Bot: yeah, but history is sometimes better than just squashing everything down 16:51:22 <TrueBrain-Bot> I know 😃 16:51:37 <TrueBrain-Bot> most of my projects work with forced fast-forward no-commit merges (read: REBASE) 16:51:43 <_3298> i found that game one day browsing my distro's games, doesn't look very active 16:51:57 <LordAro> they're also slightly insane, given they're designing their own data description language and have built their own CI server 16:52:15 <TrueBrain-Bot> we would NEVER do that 16:52:18 <TrueBrain-Bot> *looks at NewGRF* 16:52:20 <TrueBrain-Bot> *looks at CF* 16:52:22 <TrueBrain-Bot> *goes sit in a corner* 16:52:23 <LordAro> :D 16:52:35 <milek7> CF? 16:52:40 <TrueBrain-Bot> Compile Farm 16:52:44 <TrueBrain-Bot> https://farm.openttd.org/ 16:53:08 <TrueBrain-Bot> OpentTD is fully self-hosted 16:53:18 <TrueBrain-Bot> back in those days, you only had SourceForge 16:53:21 <TrueBrain-Bot> and ugh .......... 16:53:27 <planetmaker> LordAro: not so much... I still like self-hosted repo really 16:54:35 <LordAro> i get it, there's definitely a lot of appeal to self-hosting 16:54:39 <planetmaker> however, I'm not to complain if for simplicity's and less work's sake GitHub hosting is chosen... 16:54:41 <TrueBrain-Bot> what do you like about it? (more than just liking it, ofc) 16:54:53 <TrueBrain-Bot> (serious question btw; not trying to be funny etc) 16:54:58 <TrueBrain-Bot> (very bad I have to add that to my question :D) 16:55:13 *** Alberth has quit IRC 16:55:20 <LordAro> being in full control of it is my main one. there are certain aspects that github still hide away from you 16:55:33 <TrueBrain-Bot> why is it important to be in full control? 16:55:36 <TrueBrain-Bot> what is the gain? 16:55:39 <LordAro> (although now that you can rebase and suchlike, most of thsoe aspects have gone away) 16:55:54 <planetmaker> it's in our hands, we don't need to rely on 3rd-party. No vendor-lock-in. The source is our most precious asset. That's the project 16:56:10 <LordAro> ^ 16:56:20 <TrueBrain-Bot> I understand; just do realise we currently are vendor-locked, in terms of: all bug-tickets are in FS 16:56:21 <planetmaker> Yes, the whole repo is everywhere, whoever has a clone. 16:56:36 <LordAro> but ultimately, if github were to suddenly disappear from the internet, we'd have a backup somewhere 16:56:37 <TrueBrain-Bot> but if you only look at code, you are right 😃 16:56:52 <LordAro> currently there's only a couple svn repos 16:56:55 <TrueBrain-Bot> LordAro: currently we backup our source over 3 continents .. we will keep doing that 😃 16:57:05 <planetmaker> TrueBrain yes... the bug tracker is the dark duck in our barn... kinda 16:57:11 <planetmaker> we did loos Alberth :( 16:57:18 <planetmaker> *loose 16:57:36 <TrueBrain-Bot> owh no, go get him back! QUICK! 16:57:46 <milek7> when it breaks during update you can just spend few hours fixing it, instead of waiting and complianing it is broken :p 16:57:51 <TrueBrain-Bot> LordAro: OpenTTD once lost its source ... never again 😃 16:57:54 <TrueBrain-Bot> not on my watch, at least 😛 16:58:04 <planetmaker> ^^ 16:58:10 <LordAro> ^^ 16:58:16 <TrueBrain-Bot> "just spend few hours" .. if you can fix it .. and if you have the expertise .. 😉 16:58:30 <TrueBrain-Bot> fixing broken VCSes is hoping you know what the fuck you are doing 😄 16:58:31 <planetmaker> and the time, really 16:58:54 <planetmaker> it's not like anyone is paid to do that... thus work work might interfere 16:58:58 <_dp_> Am I the only one who feels that openttd has much greater chance of dying than github or anything of that caliber? 16:59:06 <TrueBrain-Bot> but we also had incidents like: our server was down .. took 24h+ to get it back online (someone pushed the power-off button in the DC) 16:59:26 <TrueBrain-Bot> _dp_: OpenTTD is alive longer than GitHub .. 16:59:39 <planetmaker> _dp_: sure, gibhub has a big audience. But that's not the reason to have our *primary* repo there, is it? 17:00:07 <TrueBrain-Bot> I think the main thing is, what-ever we pick, that we have to migrate our bugs (or don't, ofc) 17:00:18 <planetmaker> well... 17:00:20 <TrueBrain-Bot> so we want to minimize the chance of that being done again 😃 17:00:29 <LordAro> we wouldn't move to github/lab purely for git, we'd move for their frontends and whatever integrations that they bring 17:00:39 <TrueBrain-Bot> and bug tracker! 😛 17:00:42 <LordAro> ^ 17:00:54 <planetmaker> (19:00:29) LordAro: we wouldn't move to github/lab purely for git, we'd move for their frontends and whatever integrations that they bring 17:00:54 <planetmaker> ^^^ very much so 17:00:55 <LordAro> TrueBrain-Bot: good thing andy's cut the number of open bugs in half them :) 17:00:57 <TrueBrain-Bot> just one place to do it all 😛 17:01:02 <LordAro> then* 17:01:11 *** Cubey has joined #openttd 17:01:19 <TrueBrain-Bot> also easier for others to work on the project etc 17:01:59 <TrueBrain-Bot> left or right, the thing we can already do, is test our software with git 17:02:16 <TrueBrain-Bot> for example,we can switch the nightly to GitHub .. not that we have to use GitHub, but because git is already on there 17:02:25 <TrueBrain-Bot> (or our internal git, from which GitHub is pushed) 17:02:29 <TrueBrain-Bot> same for eints, etc 17:02:33 <TrueBrain-Bot> (just the read part) 17:02:57 <TrueBrain-Bot> that allows us to figure out shit like versions etc 17:03:21 <TrueBrain-Bot> and given I am moving houses, I won't have time for that the next 2 weeks from my side .. which gives you guys plenty of time to think this over a few times 😄 17:03:37 *** Alberth has joined #openttd 17:03:37 *** ChanServ sets mode: +o Alberth 17:03:46 <TrueBrain-Bot> ALBERTH IS BACK! 😄 17:03:49 <planetmaker> welcome back, Alberth :) 17:04:45 <Alberth> somewhat flakey connection 17:05:02 <planetmaker> I somewhat feared you found the git topic annoying :D 17:05:18 <Alberth> nah, I use git daily, pretty much 17:05:37 <planetmaker> oh, ok 17:05:44 <planetmaker> so much changed :P 17:06:23 <frosch123> planetmaker: according to google trends hg was most popular in 2011, which is also when ottd development was most popular 17:06:26 <Alberth> well, not sure it's a very sane tool, but it works 17:06:27 <frosch123> so it really was just us :p 17:06:39 <Alberth> :D 17:06:45 <planetmaker> :D 17:07:04 <milek7> btw. what vcs use for 10gib of assets? git? 17:07:15 <Alberth> I still use patch queues in openttd though 17:07:16 <TrueBrain-Bot> file storage 17:07:17 <TrueBrain-Bot> ext4 17:07:18 <TrueBrain-Bot> zfs 17:07:26 <TrueBrain-Bot> assets should never hit any VCS 17:07:28 <TrueBrain-Bot> they are .. assets 😃 17:07:47 <milek7> uh, but assets also have history :P 17:07:50 <LordAro> https://git-lfs.github.com/ became a thing recently 17:07:59 <LordAro> no idea how well it works 17:08:21 <TrueBrain-Bot> assets have history .. in a relational database 😛 17:08:23 <TrueBrain-Bot> ffs 😄 17:08:26 <TrueBrain-Bot> you don't diff assets 17:09:19 <Alberth> you just store the new version next to the old one, each time 17:09:55 <Alberth> disks are around 1TB minimum size nowadays 17:11:08 <_dp_> Alberth, there is never enough disk space :p 17:11:21 <milek7> but why store old assets in the same tree? 17:11:23 <TrueBrain-Bot> E_TOO_MUCH_PORN 17:11:45 <milek7> and how to pack assets for users to download then 17:12:25 <TrueBrain-Bot> look in the BaNaNaS source code! 😄 17:15:07 <Alberth> just send the users a hard disk 17:15:48 <milek7> (i'm asking because in obscure train simulator we migrated assets from svn to git https://git.eu07.pl/eu07-dev/calosciowa, but git method of packing everything into monolithic 10gib archive for download seems to be causing problems for people with poor connections) 17:16:03 <Alberth> lol 17:16:49 <TrueBrain-Bot> git, like SVN, should only be used for source code tbh .. anything binary you should prefer to keep outside a VCS; you have bette rsystems for that 17:17:01 <TrueBrain-Bot> this is mainly because VCSes are really good in diffing, and you rarely want to diff binaries (in a visual way) 17:17:20 <TrueBrain-Bot> that said, there are solutions .. never played with those 😃 17:17:29 <TrueBrain-Bot> BaNaNaS stores things based on an unique number and hash 17:17:34 <LordAro> milek7: shallow clones are a thing 17:17:52 <LordAro> and svn can cope better with binary files than git because it's a checkout, rather than a clone 17:18:04 <LordAro> but yeah, ideally you don't put binaries in VCS 17:18:11 <TrueBrain-Bot> I know companies where you need 4 (!) hours of 1 gbit/s to do a single SVN checkout 😄 17:18:14 <TrueBrain-Bot> I laughed my ass off 😄 17:18:33 <LordAro> that's... no 17:18:35 <LordAro> just don't do that 17:18:40 <TrueBrain-Bot> ^^ 😄 17:18:42 <Alberth> git-lfs is one solution, but there are others too, never needed any of those however 17:18:52 <LordAro> that's what you need a shared filesystem for 17:20:03 <Wolf01> https://www.youtube.com/watch?v=xVS9oUmr4KY cool 17:20:33 <milek7> so throw it into server with ftp, and optionally preserve history with lvm snapshots? :p 17:20:45 <TrueBrain-Bot> ftp? What is that? 17:22:24 <Alberth> milek7: do a search, "git large binary files" or so, and it will give you ways to go about this problem 17:22:32 <Wolf01> http://www.cruisetrain-sevenstars.com/ what the fuck? 17:23:06 <Alberth> TB pre-90s I think, can't be relevant with discord 17:23:30 <LordAro> ew, ftp 17:23:56 <Alberth> when security was a non-issue :p 17:24:08 <TrueBrain-Bot> its like casettes 😄 17:24:26 <Alberth> hmm, have used those too, at a 2400 baud :p 17:24:47 <Alberth> or was it 1200?, don't remember 17:27:21 <frosch123> Wolf01: what? i expected lego 17:27:54 <Wolf01> Eh, I like trains too ;) 17:34:01 * _dp_ needs a new keyboard 17:34:08 <_dp_> smashing old one no longer fixes it :( 17:34:55 <TrueBrain-Bot> and smashing the current? 17:36:05 <_dp_> currently using laptop one and I'm afraid to break something else if I smash it :p 17:36:47 <TrueBrain-Bot> I just find it weird that you smash something old in hope to fix something current, and claim that you need something new because of that 17:36:52 <TrueBrain-Bot> your logic is simply flawed 😛 17:37:43 <_dp_> if anything is flawed it's my english :p 17:37:57 <TrueBrain-Bot> 😄 17:40:29 <Wolf01> I should change back to white background, inverted colours smiles are terrible 17:41:41 <frosch123> can you ready them anyway? 17:41:45 <Wolf01> Aaaaaargh my eyes hurt... back to night mode 17:41:55 <frosch123> i always failed to distingush emoji past :) and :( 17:43:35 *** blocage has quit IRC 17:44:56 *** blocage has joined #openttd 17:50:59 <frosch123> though i like the vomit-modifier 17:58:06 <adf88> what's the default target CPU arch in VS? 17:58:29 <adf88> in OpenTTD project files 17:58:32 <adf88> ofc 18:08:25 *** FLHerne has joined #openttd 18:14:48 <V453000> sup huminz 18:32:47 <Wolf01> adf88 win32 18:36:02 <blocage> how does sprite_id map to file ? 18:36:31 <frosch123> check the sprite aligner window? 18:36:36 <frosch123> it does display the source file 18:37:23 <frosch123> anyway, it will be something in spritecache.cpp 18:39:37 <blocage> mm, let see 18:39:46 *** idl0r has joined #openttd 18:40:27 <idl0r> hey, how's the progress of those 32bpp graphics nowaydays? is there anything finished/usable yet? 18:42:23 <frosch123> thats subjective 18:42:52 <frosch123> but there is zbase baseset, yeti industry set, and various landscape sets 18:42:59 <frosch123> also pineapple trains 18:43:27 <FLHerne> And those really neat Chinese sets 18:43:34 <frosch123> i guess just go to content download and filter for 32bpp 18:43:42 <frosch123> i would expect everyone to use that tag 18:43:52 <Wolf01> And download 8GB 18:44:04 <FLHerne> idl0r: https://wiki.openttd.org/Playing_with_32_bpp_graphics is pretty much up to date afaik 18:44:34 *** glx has joined #openttd 18:44:35 *** ChanServ sets mode: +v glx 18:48:14 <idl0r> hm, are zbase and abase dead? 18:49:06 <planetmaker> well... 18:49:27 <planetmaker> they could definitely use someone taking care of. At least zBase. I can't speak for aBase 18:50:02 <LordAro> i'd imagine zeph is contactable if you need it 18:50:32 <planetmaker> probably. However zBase repo has basically everything you need to continue. And Zeph has also some nice blog postings about how he does things 18:51:06 <LordAro> true 18:51:37 <_dp_> jeez, why the heck is grow_counter exported to newgrfs? 18:52:02 <frosch123> remove it :) 18:52:19 <frosch123> many of the 80+x things are just there for completeness 18:52:49 <_dp_> gladly xD 18:52:50 <frosch123> also, i wonder how much performance we can gain for newgrf when providing better va2 operators 18:53:22 <frosch123> taking a regular firs game: the operators used most by far are "min", "xor" and "cmp" 18:53:36 <frosch123> which i believe nml generates for ? : 18:53:53 <frosch123> like, who would use "xor" other than a compiler :p 18:55:35 <V453000> BRIX ain't even mentioned on the 32bpp page :( can't say the v 0.0.1 is worth much though :) however some people actually do use it as static 18:55:59 <planetmaker> http://calculatedimages.blogspot.de/2013/01/openttd-32bpp-part-5-finished-product.html <-- there we go 18:56:40 <planetmaker> V453000: add it :) 18:56:42 <V453000> yeah, 135 hours is insanely fast 18:56:54 <V453000> yeah eventually ;P 18:57:37 <_dp_> frosch123, I use xor sometimes :p (or != if there is no xor) 19:01:53 <frosch123> https://hg.openttdcoop.org/nml/files/afad0c76c40b7eaf6d4af2a3b40961c7755f2c04/nml/actions/action2var.py#L320 <- that's where all the CMP, MIN and XOR come from 19:03:26 <idl0r> thx guys, zbase looks pretty much decent 19:04:34 <_3298> there are quite some people who call it ugly 19:05:06 <Alberth> looks like a lookup in an array? 19:17:32 <_dp_> hm, looks like next_counter thingie wasn't a great idea after all since it can't preserve progress when town isn't growing 19:17:43 <_dp_> *next_tick 19:19:18 <_dp_> does anyone know if -- is slower than % ? 19:22:42 <Alberth> for powers of 2, % becomes & 19:23:03 <Alberth> in general, division is way more expensive 19:23:57 <_dp_> Alberth, it's 74 not power of 2 19:24:08 <_dp_> Alberth, but -- is a write while % is only read 19:25:37 <Alberth> not that good in speeds at that level 19:26:11 <Alberth> but in both cases you need it in L1 cache, so the cache wait time is equal 19:26:28 <Alberth> writing out is likely done without cpu intervention 19:29:27 <_dp_> Alberth, yeah, looks like it doesn't matter much to modern processors 19:31:33 <_dp_> they don't even seem to care for anything but cache and vectorization xD 19:32:59 <frosch123> they used to care about conditional if 19:33:50 <_dp_> fonsinchen, because it's vectorization :p 19:34:18 <_dp_> frosch123, * 19:37:22 <frosch123> haha, i just applied a manual optimisation which i thought would double speed, but it halfed it :p 19:38:37 <milek7> speed of what? 19:38:59 <milek7> newgrf code execution really takes measurable time? 19:39:16 <frosch123> i replaced (a <= b) && (b <= c) with (b - a <= c - a) 19:39:47 <frosch123> which is our fancy macro to do range checks 19:40:13 <_dp_> pff, that doesn't even look as optimization :p 19:40:24 <frosch123> anyway, my measuring is probably imprecise as well 19:40:28 <frosch123> the test case is too flaky 19:40:53 <frosch123> milek7: yes 19:41:08 <frosch123> newgrf vehicles are somewhat expensive 19:41:30 <_dp_> frosch123, does it even work the same? b - a <= c - a is pretty much b <= c 19:41:49 <frosch123> and ecs industry animations can completely kill it, but i put a huge warning into the specs so that ecs is the only set which uses that part now 19:42:06 <frosch123> _dp_: everything must be unsigned 19:42:46 <frosch123> if b < a, then b-a is bigger than c-a 19:43:41 <_dp_> frosch123, what if c < a as well? 19:43:51 <frosch123> then it breaks :p 19:45:05 <frosch123> but since the intention is a range check of "b", "a <= c" is pretty safe 19:45:49 <frosch123> anyway, the -O2 is probably smarter than the old "arithmetic is better than comparision" 19:45:50 <blocage> frosch123, does not look an optimization 19:45:59 <_dp_> frosch123, ah, ok. 19:46:14 <_dp_> frosch123, still kinda shaky with values > max/2 19:46:38 <blocage> a <= b is a - b and sign bit register 19:47:18 <frosch123> http://graphics.stanford.edu/~seander/bithacks.html <- anyway, that's the standard reference for weird tricks 19:47:27 <frosch123> not sure whether this is listed there though 19:47:44 <_dp_> nice thing about && is that it doesn't always need both operands 19:47:52 <_dp_> though it's probably irrelevant in this case 19:48:00 <milek7> i think compilers are usually better at such micro-optimizations 19:48:19 <blocage> frosch123, I think you should double chack, because tricky unoptimal code, just just worth 19:48:27 <blocage> worst * 19:49:31 <frosch123> well, anyway. i did a statistical analysis about the composition of va2 chains. and it did not give a hint for useful tree optimisations 19:49:36 <blocage> and I fairly sure compiler are quite smart about boolean expresion 19:51:05 <frosch123> hmm, otoh, those weird CMP+XOR make up 20% 19:51:31 <frosch123> probably should look into the source grf where those comparisions really originate from 19:52:46 <_dp_> there is even instruction for bounds checking https://pdos.csail.mit.edu/6.828/2011/readings/i386/BOUND.htm 19:53:21 <frosch123> initially i hoped STORE_TMP and LOAD_TMP would show up big time, but they are only 7% 19:54:20 <milek7> (a <= b) && (b <= c) is cmp, ja, xor, cmp, setbe, mov, xor, jne and (b - a <= c - a) is sub, sub, cmp, setbe, mov, xor, jne 19:54:50 <milek7> but i think it is possible to do it without arithmetic and with only one branch 19:55:25 <milek7> maybe we need jit for newgrfs? :D 19:55:45 <adf88> i think that compilers are smarter 19:55:54 <adf88> ind can do this without branching 19:55:55 <_dp_> yeah, to replace nml xors with sane operations :p 19:57:24 <adf88> && doesn't have to be a jump 19:59:16 *** sim-al2 has joined #openttd 19:59:29 <adf88> imagine this pseudo-asm: 19:59:44 <adf88> 1. compute "a <= b" and "b <= c" in paralel 19:59:52 <adf88> 2. AND the results 19:59:55 <_dp_> adf88, why not? I bet it's an if condition so it has to be a jump anyway 20:00:51 <frosch123> hmm, just noticed that i never used x64 assembly 20:01:04 <adf88> the last thing would be to jump 20:01:05 <frosch123> maybe comparisons are smarter there than in i386 20:01:09 <adf88> or do something else 20:01:18 <adf88> based on the result of calcuations 20:01:28 <adf88> "if" is not always a jump 20:08:55 <blocage> frosch123, objdump -d 20:11:10 <frosch123> i always use gdb for disasembling 20:13:48 <Alberth> in C++, && in parallel is much less than trivial, due to exceptions 20:14:12 <blocage> frosch123, gdb is also fine :D 20:14:53 <frosch123> oh, also, does anyone have experience with thread_local storage class? 20:15:14 <frosch123> do the compilers use specific offset registers to reference the thread-specific memory 20:15:31 <frosch123> like for position-independent code 20:15:37 * _dp_ only used thread locals in python 20:15:43 <frosch123> or is access to them more expensive? 20:16:25 <blocage> do not know, I never did such micro optimization 20:17:09 <frosch123> ottd has many "static" variables to store temporary values and return values to avoid heap allocations 20:17:29 <frosch123> but they make the code non-reentrant 20:17:45 <frosch123> making the stuff thread_local would be enough 20:17:58 <frosch123> but i have no idea how thread_local compares to heap allocations 20:18:12 <_dp_> can we revert that already? https://www.tt-forums.net/viewtopic.php?f=31&t=76921 20:19:01 <frosch123> i think i was against it back then :p 20:19:59 <blocage> frosch123, also micro optimization are often specific to a given arch+CPU generation, the CPU do a lot of optimization himself, can manage instruction out of order, on multiple units and so on 20:21:08 <_dp_> https://www.youtube.com/watch?v=5tg1ONG18H8 20:21:31 <_dp_> openttd network lobby can as well be in that video imo :p 20:25:24 <adf88> this whole hardware/software optimizations grown into something big and crazy 20:25:49 <adf88> paradoxically, RISC processors seems to be a rescue from this situation :) 20:26:17 <frosch123> ok, x64 still uses the same flags register as i386. i do not have to learn anything new :p 20:26:33 <adf88> we need to throw x86 and other away and start again 20:26:42 <adf88> :p 20:30:12 <frosch123> the most modern microprocessor i programmed was atmel avr 20:30:28 <frosch123> and they also had flags and similar branch commands 20:30:42 *** keoz has joined #openttd 20:34:26 *** moonythedwarf has joined #openttd 20:34:29 <moonythedwarf> Boo 20:36:58 <Alberth> o/ 20:45:39 *** Alberth has left #openttd 21:08:08 *** Stimrol has quit IRC 21:10:03 <moonythedwarf> test 21:24:36 *** Hiddenfunstuff has quit IRC 21:30:10 *** gelignite has quit IRC 21:31:47 *** blocage has quit IRC 21:34:57 <frosch123> https://www.akkadia.org/drepper/tls.pdf <- this explains most about thread_local :) 21:44:46 *** keoz has quit IRC 22:05:21 *** mescalito has quit IRC 22:07:16 *** Wolf01 has quit IRC 22:07:58 *** Wolf01 has joined #openttd 22:18:20 *** Lejving has quit IRC 22:20:00 *** Wormnest has quit IRC 22:26:37 *** adf88 has quit IRC 22:27:03 *** FLHerne has quit IRC 22:30:19 *** Lejving has joined #openttd 22:35:34 *** HerzogDeXtEr has quit IRC 22:39:03 *** frosch123 has quit IRC 22:45:42 *** Progman has quit IRC 22:52:09 <Wolf01> 'night 22:52:13 *** Wolf01 has quit IRC 22:58:47 *** _3298 has quit IRC