Log for #openttd on 27th August 2017:
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
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> <-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>
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> <- 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> <- 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> 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:
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...
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:
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:
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>
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: .. 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> 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>
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> there we go
15:50:07  <TrueBrain-Bot> 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> ¯\_(ツ)_/¯
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
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, 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> 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> 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:
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,, 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> 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>
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> 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, 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> 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> 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: 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> <-- 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> <- 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> <- 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
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?
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_>
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> <- 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

Powered by YARRSTE version: svn-trunk