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