IRC logs for #openttd on OFTC at 2018-04-28
⏴ go to previous day
00:20:33 *** Stimrol has joined #openttd
01:38:38 <TrueBrain> ieuw, close them, quick!
01:45:39 <TrueBrain> helping people within 32 minutes; now that is a good service-rate :P
01:55:13 <Thedarkb-X40> Does the classification hard stuff in ISR actually work?
02:09:43 <Thedarkb-X40> Bleh, my ratings are plummeting because I can't keep up with the production of this iron mine.
04:04:15 *** tokai|noir has joined #openttd
04:04:15 *** ChanServ sets mode: +v tokai|noir
04:20:30 *** ChanServ sets mode: +v tokai
04:28:41 *** tokai|noir has joined #openttd
04:28:41 *** ChanServ sets mode: +v tokai|noir
04:35:37 *** ChanServ sets mode: +v tokai
04:52:40 *** muffindrake2 has joined #openttd
05:01:56 *** ToffeeYogurtPots_ has quit IRC
05:02:31 *** ToffeeYogurtPots_ has joined #openttd
05:30:08 *** tokai|noir has joined #openttd
05:30:09 *** ChanServ sets mode: +v tokai|noir
05:38:07 *** ChanServ sets mode: +v tokai
05:50:05 *** ChanServ sets mode: +v tokai
05:59:47 *** tokai|noir has joined #openttd
05:59:47 *** ChanServ sets mode: +v tokai|noir
06:02:51 *** ChanServ sets mode: +v tokai
06:13:55 *** tokai|noir has joined #openttd
06:13:55 *** ChanServ sets mode: +v tokai|noir
06:17:14 *** ChanServ sets mode: +v tokai
06:31:53 *** Thedarkb1-X40 has joined #openttd
06:31:57 *** Thedarkb1 has joined #openttd
06:33:02 *** ChanServ sets mode: +v tokai
06:34:58 *** tokai|noir has joined #openttd
06:34:58 *** ChanServ sets mode: +v tokai|noir
06:44:59 *** ChanServ sets mode: +v tokai
06:48:48 *** sla_ro|master has joined #openttd
07:01:16 *** tokai|noir has joined #openttd
07:01:16 *** ChanServ sets mode: +v tokai|noir
07:23:04 *** sim-al2 has joined #openttd
07:50:06 *** sim-al2 is now known as Guest1149
07:50:07 *** sim-al2 has joined #openttd
07:54:07 *** sim-al2 is now known as Guest1150
07:54:08 *** sim-al2 has joined #openttd
07:57:50 *** Wacko1976 has joined #openttd
07:58:08 *** sim-al2 is now known as Guest1151
07:58:09 *** sim-al2 has joined #openttd
07:59:36 *** Progman has joined #openttd
08:08:58 *** andythenorth has joined #openttd
08:47:22 *** gelignite has joined #openttd
09:00:00 <peter1138> Hmm, it appears to be raining.
09:00:11 *** sim-al2 is now known as Guest1157
09:00:12 *** sim-al2 has joined #openttd
09:05:42 <peter1138> Oh my, there's a VR model railway simulator.
09:06:53 <andythenorth> sprites complete: 61; incomplete: 122
09:06:59 <andythenorth> what does it all mean?
09:07:22 <andythenorth> 1/3 done I guess
09:26:17 *** HerzogDeXtEr has joined #openttd
09:42:34 <andythenorth> where's the new OS X binary candidate? o_O
09:46:19 *** FLHerne has joined #openttd
10:04:21 *** ipADblocker has joined #openttd
10:10:32 *** FLHerne has joined #openttd
10:28:57 *** Cybertinus has joined #openttd
10:29:16 *** ipADblocker has joined #openttd
10:29:24 <Cybertinus> good morning everybody
10:29:46 <Cybertinus> I just installed OpenTTD 1.8.0 on my Fedora laptop, but I can't get the music to play
10:30:04 <Cybertinus> I have downloaded OpenMFX and some other base sets
10:30:19 <peter1138> Yeah, music needs Timidity by default
10:30:53 <Cybertinus> that's something I need to install on my computer or is that an ingame download?
10:31:49 <Cybertinus> let me check, thanks for the point
10:32:24 <peter1138> Should be packaged by Fedora.
10:32:42 <Cybertinus> running sudo dnf install timidity++ now :)
10:33:47 <peter1138> Duke Nukum Forever!
10:35:22 <Cybertinus> ok, I got music now!
10:35:41 <Cybertinus> it only plays via the laptop speakers, not via the speakers I've got hooked up to my docking station :p
10:36:23 <peter1138> If it's all on defaults then it should be using pulseaudio.
10:37:43 <peter1138> Maybe timidity doesn't use pa by default.
10:38:10 <Cybertinus> maybe, yes. I'm diving into the timidity settings now
10:40:35 <andythenorth> ok the OS X build is pretty fucked
10:41:13 <andythenorth> I need to test it on a mac that's not also fucked though
10:41:37 <andythenorth> our 10.13 machine has an expanding battery that causes the trackpad to not accept clicks
10:41:53 <peter1138> Other people reported it works better.
10:43:01 <andythenorth> so far, GS is crashing, the cursor is locked to left of game viewport, and it's crashed (looks like fonts, again)
10:43:11 <andythenorth> these might not be specific to this new build
10:43:32 <andythenorth> cursor artefacts are gone though :)
10:44:00 <andythenorth> so I need to test with a mouse
10:44:07 <andythenorth> but...USB-C innit :P
10:45:56 <peter1138> GS is crashing how?
10:47:31 <andythenorth> specific to Busy Bee
10:47:48 <andythenorth> I will look more later, child A is busy playing right now
10:48:04 <andythenorth> it's like having a chaos monkey
10:57:05 <Cybertinus> ok, I "fixed" my issue
10:57:37 <Cybertinus> I've disabled the music in the game, and I just start VLC with all the files in the ~/.openttd/content_download/baseset/openmfx* as a playlist :p
11:06:05 *** ChanServ sets mode: +v tokai
11:09:03 *** synchris has joined #openttd
11:09:23 <peter1138> This is why we need a built-in synth :S
11:09:30 <TrueBrain> w00p, I compiled strgen! :)
11:10:46 <peter1138> Hmm, wasn't there a libtimidity driver?
11:11:30 *** Wacko1976_ has joined #openttd
11:11:55 <peter1138> Ah, but libtimidity isn't packaged it seems.
11:15:31 <peter1138> There's a configure.ac, can't remember how to bootstrap it.
11:17:36 <peter1138> Yeah, that "simple" sequence of commands.
11:18:11 <TrueBrain> so strgen doesn't use the basename of the language file .. wuth?!
11:18:17 <TrueBrain> strgen is a bit weird :D
11:18:39 <TrueBrain> I give it a -s and -d, so I expect I can do 'dutch.txt' next
11:18:49 <TrueBrain> but it has to be a valid path from your working directory
11:18:53 <TrueBrain> so I make it src/lang/dutch.txt
11:19:02 <TrueBrain> now it wants to create the file DEST_FOLDER/src/lang/dutch.lang
11:19:21 <TrueBrain> but my SOURCE_DIR is also set ... so it does find english.txt
11:21:25 <TrueBrain> so I will set the working directory :P
11:21:55 <TrueBrain> why does compiling english.lng give so many warnings? :D
11:22:55 *** D-HUND is now known as debdog
11:24:35 <TrueBrain> param STRING doesnt match STRING2
11:25:51 <TrueBrain> ah, why my folder stuff crashes and burns, is because of / in path on Windows
11:25:57 <TrueBrain> well, a mix of / and \ :)
11:26:17 <TrueBrain> guess that is also why it doesnt see it is doing english.txt
11:26:27 <TrueBrain> (as english.txt has different validation)
11:30:44 <TrueBrain> so yeah ... despite the fact that / works in paths these days, our code says: Windows? \\ it is!
11:31:47 <TrueBrain> okay, so only the last parameter has this issue; so TO_NATIVE_PATH it is :)
11:32:44 <Thedarkb1-X40> How do I turn off the vehicle is losing money thing?
11:32:55 <Thedarkb1-X40> I have some ships that only make money every two years.
11:34:35 *** tokai|noir has joined #openttd
11:34:35 *** ChanServ sets mode: +v tokai|noir
11:34:57 <peter1138> Go into settings, search for "profit"
11:35:06 <peter1138> "Warn if a vehicle's income is negative"
11:40:35 <Cybertinus> there was also some window where you could define what messages you see and which you don't? And there you could also select if you want the message to pop out of the statusbar, or if it was just a scrolling messge
11:40:57 <peter1138> Yes, that got moved to settings as well.
11:41:23 <Cybertinus> ok, didn't know that. Haven't played OpenTTD for a few years now :)
11:44:04 <TrueBrain> yippie, all languages are now compiled \o/ :D
11:46:47 *** frosch123 has joined #openttd
11:53:00 <peter1138> Oops, started too early for RVs. Doing a cargodist feeder system is out of the question then :p
12:01:30 <peter1138> Hmm, weird that the cargo flow legend lets you spy on other companies.
12:01:43 <peter1138> I suppose you can see all their orders anyway.
12:04:15 <andythenorth> you can add newgrfs to a running game, right :P
12:04:17 <Thedarkb1-X40> What's the most efficient way of joining two double tracked lines perpendicular to each other?
12:06:28 <peter1138> andythenorth, no it's illegal.
12:12:17 <Rubidium> Thedarkb1-X40: at least look for ones with split-before-merge being yes
12:12:39 <peter1138> I just use signals.
12:12:45 <peter1138> And then they join.
12:13:01 <peter1138> It's "efficient" with regards to track and signals ;)
12:14:54 <Thedarkb1-X40> Eh, slowdowns aren't a huge deal anyway.
12:18:58 *** Wormnest has joined #openttd
12:19:19 <TrueBrain> can we remove WINCE and PSP from OpenTTD? Not maintained, and I am unsure if any binaries have been produced in a long long long time for them :P
12:19:49 <peter1138> WINCE is somewhat... ancient.
12:21:51 <andythenorth> is one of them group livery? o_O
12:22:08 <peter1138> No. Nor is one NRT.
12:23:13 <andythenorth> if I move to github will people send me PRs containing sprites?
12:23:18 <andythenorth> as I am missing a few hundred
12:23:56 <Wolf01> I wonder if is possible to make the logitech quickcams to work on >=win7... my lego webcam requires win98-XP
12:23:58 <peter1138> You could send yourself PRs
12:24:18 <andythenorth> I do actually get sent sprites sometimes in devzone
12:24:31 <Thedarkb1-X40> WinCE Was replaced with windows mobile.
12:24:46 <Thedarkb1-X40> As far as I know it's still supported though.
12:25:47 <andythenorth> TrueBrain: the new OS X binary doesn't trigger the "32 bit is dead" warning from Apple :)
12:25:51 <Thedarkb1-X40> Last version of CE proper came out in 2013
12:26:11 <TrueBrain> andythenorth: good :)
12:26:11 <frosch123> andythenorth: maybe watch the factorio repo? yesterday they put the lua part of the game on github, which controls all the game balancing and stuff. while it is meant as source for modders, I also wonder whether people will submits PRs to change balancing :p
12:26:49 <peter1138> Right, I gotta make this patch bigger :p
12:27:03 *** gelignite has joined #openttd
12:30:44 <frosch123> he, i would not have expected V to have been on github for two years
12:32:45 <TrueBrain> okay .... we already have c++17 code in OpenTTD :D That took me by surprise :P
12:33:06 <frosch123> LordAro: your patch
12:33:51 <frosch123> iirc c++17 is not supported on the compilers we target
12:34:03 <frosch123> so, c++17 is optional. we want to target c++14
12:35:34 <TrueBrain> yeah .. so I just told CMake to target c++17 if available,and it will drop to c++14, c++11, etc if it cannot find it
12:35:44 <TrueBrain> going to put the low-bar on c++11 for now, but we can increase that to c++14 :)
12:35:48 <peter1138> So the CI needs to warn on it?
12:35:59 <peter1138> Or flat out just fail I guess.
12:36:30 <Wolf01> What are you revolutioning today?
12:36:31 <LordAro> there's not all that much in C++14
12:36:50 <LordAro> std::make_unique is probably the biggest
12:37:13 <frosch123> captures are the biggest :)
12:37:25 <frosch123> captures in c++11 are treacherous
12:37:55 <frosch123> but well, ottd does hardly use functors
12:38:18 <frosch123> hmm, ... actually... FOR_EACH_xxx
12:38:27 <frosch123> all the weird macros :p
12:39:03 <LordAro> would be good to get rid of those :p
12:39:26 <frosch123> well, they work, so no real benefit
12:40:15 <TrueBrain> okay, cmake starts to work .. slowly .. table/settings.h next :) What is that about ...
12:42:51 <frosch123> i was against that :p
12:46:27 <TrueBrain> okay, that was easy enough :) Pfew :)
12:46:51 <TrueBrain> now for the parsing of source.list ... lol
12:47:10 <TrueBrain> the #ifs are not the issue .. the #else are :)
12:50:05 <peter1138> Yeah, what is that .ini thing all about?
13:00:41 <peter1138> Hmm, I really can't come up with decent names for these scrolling methods...
13:00:59 <peter1138> "mouse moves the camera" "mouse moves the map"
13:01:57 <peter1138> and which one is really reversed? heh
13:02:10 <frosch123> "Move map with LMB", "Move map with RMB", "Move map with RMB, mouse locked", "Move viewport with RMB, mouse locked"
13:02:26 <TrueBrain> hmm .. how about MorphOS and BeOS support?
13:02:31 <TrueBrain> is tokai|noir still maintaining those? :)
13:02:37 <TrueBrain> or was orudge doing BeOS?
13:02:51 <frosch123> TrueBrain: you forgot os/2
13:03:04 <TrueBrain> maybe we should have a new rule, that we only support targets which we have a Docker for to compile them with :)
13:03:12 <peter1138> TrueBrain, good rule.
13:03:18 <TrueBrain> okay, parsing source.list was easier than I expected
13:03:27 <TrueBrain> simple state machines are simple
13:04:10 <TrueBrain> owh, it can be nested .. so I have to make a stack :D Okay, it is slightly more complicated :P
13:05:33 <peter1138> Oh, right, not C++ code :p
13:08:29 <TrueBrain> owh, no, not a stack, I need a depth indicator .. I wrote this before I remembered ..
13:08:45 <TrueBrain> while doing this, I was like ... I have thought about this before, haven't I? 10 years ago ...
13:09:13 <peter1138> Happens with my patches too ;p
13:09:21 <TrueBrain> just mine are in the codebase
13:09:53 *** Wacko1976 has joined #openttd
13:15:45 <peter1138> Committing patches is overrated.
13:21:32 <TrueBrain> oeh, you are not only lurking :D
13:25:26 <tokai|noir> TrueBrain: Oh... but I am lurking. :)
13:29:55 <TrueBrain> right, some time later, I finally got my source.list parser to work :)
13:30:17 *** ChanServ sets mode: +v tokai
13:32:05 <TrueBrain> and now it is missing _openttd_revision etc :)
13:47:45 <andythenorth> my offsets are all wrong eh
13:51:41 *** tycoondemon has joined #openttd
13:52:27 <_dp_> thinking on that clone PR had a idea that having some kind of a "clone this vehicle in same depot it was built in" button is probably a good idea
13:53:12 <TrueBrain> I .... just build an openttd.exe via cmake :D
13:53:26 <TrueBrain> _dp_: MORE BUTTONS IN THE UI :P
13:53:40 <_dp_> TrueBrain, more hotkeys :p
13:53:57 <TrueBrain> frosch123: yes, I was doing it on Windows with MSVC as compiler
13:54:01 <frosch123> _dp_: then you also need buttons to "assign home depot" and more
13:54:03 <TrueBrain> and it really works ....
13:54:26 <TrueBrain> starting gives some errors because I did not do everything yet to make the bin folder correct :D
13:54:35 <_dp_> frosch123, not rly but I guess makes sense for completion of interface
13:54:50 <_dp_> frosch123, It's more of a route thing actually, add a vehicle to a route
13:55:12 <_dp_> frosch123, just that OpenTTD doesn't have any concept of routes
13:55:48 <TrueBrain> okay, this is cool .. it even copied the correct dlls in the same folder :)
13:56:56 <peter1138> _dp_, you'd have to remember the depot. And then it if was removed...?
13:57:06 <TrueBrain> hmm .. failed to find a graphics set .. didnt it auto-download one?
13:57:23 <peter1138> missing networking?
13:57:26 <frosch123> yes, but only when gui
13:57:40 <_dp_> peter1138, I know, I know, too many ifs
13:57:44 <TrueBrain> it is very possible that -DENABLE_NETWORK was not set :)
13:57:46 <TrueBrain> good point peter1138 :)
13:57:48 <peter1138> Although would be nice if dedi servers can do that.
13:58:06 * andythenorth wonders how to fix the in-game sprite aligner
13:58:10 <TrueBrain> I didnt go through all the settings yet .. as it is a bit messy which exist :)D
13:58:16 <andythenorth> I never use it because the numbers bear no relation to the nfo/nml
13:58:30 <andythenorth> well...they must have some relation...but it's opaque
13:59:05 <_dp_> basically two things that annoys me in cloning that I constantly have to find depots and vehicles to clone
13:59:37 <_dp_> and sometimes I don't even care about either
13:59:41 <andythenorth> I clone in the depot
13:59:43 <andythenorth> but that's just me
13:59:53 <_dp_> like, plane crashed, fuck it, just make another one)
14:01:32 <_dp_> yeah, though it plane case I would also like auto-advertising
14:02:02 <Pikka> at that point, why not just turn plane crashes off?
14:02:36 <_dp_> Pikka, I think I did already, at least on some servers
14:03:49 <andythenorth> hmm where's the sprite aligner in src :P
14:03:54 <andythenorth> it's probably just maths
14:07:28 <TrueBrain> meh; cmake 3.5 doesn't know about c++17 yet, so it yells about it :P
14:07:42 *** tycoondemon has joined #openttd
14:09:44 <andythenorth> nah but thanks :)
14:10:16 <_dp_> it may not be a bad idea to introduce routes though. They already exist in form of shared orders so it won't change much, just a workflow a bit
14:10:33 <frosch123> merge groups and shared orders :p
14:10:54 <_dp_> frosch123, I've no idea what groups are even for :p
14:12:48 <TrueBrain> meh .. being c++11 for everything except 1 MSVC version is annoying :D
14:12:58 <Eddi|zuHause> replace groups by SQL queries :p
14:13:18 <andythenorth> you mean Squirrel?
14:13:35 * andythenorth wonders about relational table for all vehicles
14:13:54 <andythenorth> it's not even a stupid idea
14:14:42 * _dp_ already has a relational tables for all players and companies
14:16:41 <TrueBrain> frosch123 / LordAro: gnu++11 or stdc++11?
14:16:42 <Eddi|zuHause> i don't think SQLite is going to cut it here, you need some crazy object-relational thing, because you consatnly need to update all the vehicles
14:16:57 <TrueBrain> frosch123 / LordAro: gnu++11 or c++11? (oops, std is not part of that)
14:17:05 <_dp_> may be nice setup for a coding game though, relational tables, programmed signals, etc...
14:18:02 <andythenorth> Eddi|zuHause: how about noSQL? o_O
14:18:11 <frosch123> TrueBrain: if it compiles, then no gnu extensions :)
14:19:11 <Eddi|zuHause> andythenorth: i've never really understood what that is. but it sounds like the opposite of what's needed :p
14:19:34 <TrueBrain> so now how to fix MSVC2017 special c++17 case ...
14:19:34 <andythenorth> Eddi|zuHause: it's like a database, but you can't trust it
14:19:46 <andythenorth> it's not canonical
14:19:54 <andythenorth> oh and it tends to break a lot in production
14:20:02 <andythenorth> due to being engineered by people who aren't database engineers
14:20:21 * andythenorth actually has limited experience, might be spreading FUD
14:21:18 <frosch123> andythenorth: use postgres foreign data wrappers to connect your nosql junk to sql
14:21:54 <frosch123> how about an admin port foreign data wrapper? :p
14:22:21 <_dp_> frosch123, no need to connect anything, just store stuff as json in postgres :p
14:22:53 <andythenorth> does that get us routes?
14:23:11 <andythenorth> and groups that are multi-dimensional but also hierarchical?
14:23:13 <TrueBrain> LordAro: would it hurt if we remove the c++17 statement? It is a real pita to get right ..
14:23:17 <frosch123> _dp_: everything in a single bytea blob?
14:23:52 <_dp_> andythenorth, was that even supposed to?
14:23:55 <TrueBrain> LordAro: fallthrough
14:24:13 <LordAro> how is it a pain? it'd be dead code, but i'm fairly sure it's that anyway?
14:24:14 <_dp_> frosch123, put sqlite db in postgres blob so you can sql while you sql
14:24:38 <TrueBrain> LordAro: the problem is, that we are c++11, except for 1 compiler on 1 version
14:24:46 <TrueBrain> making something generic for that is .. difficult :)
14:25:05 <TrueBrain> you get something like: # Only on MSVC2017+, we are c++17. On all other, we are c++11
14:25:20 <TrueBrain> that on itself is not a real issue, but someone working on MSVC2017 won't see he did c++17
14:25:24 <TrueBrain> only when the CI starts yelling he does
14:25:36 <frosch123> i though msvc2017 barely implements c++14?
14:26:22 <TrueBrain> I really think OpenTTD should have 1 set for all its targets :) Means everyones assumption is the same, no matter which OS/Compiler you use :)
14:26:57 <TrueBrain> (as you set the standard for the whole project; not 1 file)
14:28:51 <LordAro> frosch123: last i checked msvc2017 implemented most of it
14:29:04 <andythenorth> _dp_: mumble mumble player feature requests
14:29:20 <andythenorth> and a long argument here once
14:31:26 <TrueBrain> not nearly done yet
14:31:46 <_dp_> how do I create nested groups or was that never merged?
14:33:08 <_dp_> frosch123, oh, weird, I though I tried that
14:34:27 *** ToffeeYogurtPots_ has quit IRC
14:34:53 <LordAro> TrueBrain: that source.list parsing definitely needs separating into a function
14:35:07 <LordAro> or converting to proper preproc >:)
14:35:07 <andythenorth> there were some patches that fixed group counts iirc
14:35:08 <TrueBrain> so many stuff needs fixing
14:35:16 <andythenorth> there are some oddities with grops
14:35:43 <TrueBrain> but Visual Studio 2017 runs this file fine too :D
14:35:54 <frosch123> TrueBrain: you should decide whether you want to put blanks after "foreach", "if", "else" etc :p
14:36:17 <TrueBrain> frosch123: that decision has been made years ago
14:36:29 *** Thedarkb1 has joined #openttd
14:36:44 <TrueBrain> I did; and if you spot a mistake, let me know. But this is not helping :)
14:36:48 <frosch123> anyway, i think that's the first cmake file i see, so no idea
14:37:39 <peter1138> foreach () endforeach() .hmm.
14:37:39 <frosch123> two matches for "else(", 3 matches for "foreach("
14:37:49 <TrueBrain> cmake is awesome :) I just have to learn it all the options we have ... will be a while :(
14:38:00 <TrueBrain> frosch123: so you found 5 mistakes in how many lines of code? Please :P
14:38:06 <LordAro> peter1138: it is not a pretty language
14:38:08 <peter1138> line 112 and 120 of /CMakeLists.txt
14:38:25 <TrueBrain> cmake is very nice with endNNN .. it is always NNN / endNNN
14:38:37 <TrueBrain> and what I like most about if(), you have to repeast your statement in else and endif .. this is annoying, but avoids so many mistakes
14:38:47 <TrueBrain> there is quiet some thought behind it
14:38:54 <LordAro> TrueBrain: ah, but you don't
14:38:58 <peter1138> Hmm, anyway I guess CMakeLists doesn't need to follow our C++ standard, so whatever looks nicer.
14:40:13 <peter1138> Hmm, I guess I need an enum for this scrolling stuff. 0-3 is a big vague :p
14:40:59 <frosch123> TrueBrain: to be more annoying, sometimes you indent with 4 spaces, sometimes with 8
14:41:29 <TrueBrain> frosch123: that is CMake
14:41:34 <TrueBrain> and that is pretty consistent
14:41:43 <TrueBrain> well, you dont have to do that, but every sane CMakeLists.txt does that :)
14:41:57 <TrueBrain> 8 spaces for when you are still inside parameter definitions
14:42:00 <frosch123> 4 for if, 8 for wrapped parameters?
14:42:20 <TrueBrain> makes it a lot easier to spot what is what :) As things can get a bit insane
14:42:39 <TrueBrain> and I did that consistently, I see :)
14:43:16 <TrueBrain> what I really like about CMake, I tell in strgen that if you include openttd:languages, it should add a few include directories
14:43:28 <TrueBrain> so when you include it, things are fixed for you
14:43:39 <TrueBrain> so in 1 place you define everything, and all your users are supplied with the right info
14:43:47 *** Alberth has joined #openttd
14:43:47 *** ChanServ sets mode: +o Alberth
14:43:59 <TrueBrain> (same for the find_package stuff .. it even copies the dll files for you .. as those are defined in the package)
14:44:23 <TrueBrain> I do think I can remove include_directories(${ZLIB_INCLUDE_DIR}), as that should be part of target_link_libraries .. but not sure
14:45:12 <Alberth> compiling and linking are different things
14:46:01 <TrueBrain> different linking :)
14:46:15 <TrueBrain> target_link_libaries, links a library to a target
14:46:22 <TrueBrain> including all the target definitions he said
14:46:36 <TrueBrain> (well, in CMake 2 it meant 'linking'in what you meant. In CMake 3 no longer)
14:46:46 <TrueBrain> misleading names being misleading, I guess :)
14:47:00 <Alberth> ah, how progress makes things simpler and easy :)
14:49:33 <TrueBrain> okay, you still need the include_directories :)
14:49:39 <TrueBrain> bit weird honestly .. but I guess that is what it is
14:50:30 <TrueBrain> what is annoying about cmake, that OFF, NO, FALSE, are all considered 'false'
14:50:41 <TrueBrain> so NO / ON is false / true
14:50:44 <TrueBrain> which is just WRONG
14:51:08 <LordAro> ah, you've got past the "cmake is so nice" phase :p
14:51:31 <TrueBrain> so in your opinion you either have to be 100% positive, or don't like something?
14:51:34 <TrueBrain> there is nothing in between?
14:52:21 <APTX_> there is no "cmake is so nice" phase
14:53:22 <TrueBrain> we really have to prune our OS tree .. so much weird targets
14:53:31 <TrueBrain> what is this 'OSX'?!
14:53:58 <Alberth> something proprietary
15:01:08 *** ToffeeYogurtPots has joined #openttd
15:27:14 *** ToffeeYogurtPots has quit IRC
15:30:57 <peter1138> Do we need more CPU power for the CI? :p
15:31:05 <peter1138> Ah, just completed.
15:33:26 <TrueBrain> AWS still hasnt replied to any of my communication :(
15:38:42 <TrueBrain> not sure what that smile is for ... you happy we didn't get a reply yet? :s
15:39:12 <TrueBrain> now I am just scared :(
15:41:12 <TrueBrain> it shows more problems than it fixes .. problems that were always there, just hiding
15:41:20 <TrueBrain> we were talking about it yesterday .. seems this needs a bit more work
15:41:33 <ZehMatt_> so what are the problems
15:41:40 <TrueBrain> one of the bigger things that bother me, that now 2 functions handle something to do with realtime
15:41:44 <TrueBrain> that feels very weird
15:42:04 <ZehMatt_> its typical in games to have two time variables
15:42:21 <TrueBrain> with your pathc, UpdateWindows and DrawWindows both track _real_tick
15:42:25 <TrueBrain> one at 100, one at 15
15:42:32 <TrueBrain> and I cannot see the reason why they are in 2 functions
15:42:45 <TrueBrain> feels more we have a TickWindows functions or something
15:43:03 <TrueBrain> so that made us wonder if we shouldnt have a RealTick() function in windows
15:44:06 <TrueBrain> all-in-all, I keep coming back that it feels like patching up something that is already broken
15:44:11 <TrueBrain> and I still have to look in the code myself
15:44:22 <ZehMatt_> most of the video drivers are a mess imho
15:44:23 <TrueBrain> it always has been weird btw
15:44:42 <TrueBrain> as basically with your patch you see a lot easier that many drivers dont have vsync or double buffer
15:44:45 <ZehMatt_> they do all the same more or less with minor differences
15:44:49 <TrueBrain> which is a very weir dcombination to have
15:45:16 <TrueBrain> and it is also weird that FastForward has anything to do with Window code
15:45:22 <TrueBrain> as .... FF should influence the game
15:46:20 <ZehMatt_> so what do you suggest
15:46:38 <TrueBrain> maybe frosch123 has some wisdom to share here; but I am tempted to say: lets not do this PR now, and lets go back and really look at UpdateWindows, and how it is used
15:47:11 <TrueBrain> your patch showed more issues than I have dear :)
15:47:40 <ZehMatt_> well apart from now liking how its done, from a technical point its the best viable option atm
15:47:58 <TrueBrain> what is the best viable option?
15:48:06 <ZehMatt_> unify the video drivers
15:48:10 <ZehMatt_> cleanup the whole thing
15:48:33 <LordAro> not a small amount of work
15:48:35 <TrueBrain> not sure that video drivers have to be unified to fix this messy stuff, but a good look at the Window code
15:48:52 <ZehMatt_> they all do more or less the same thing
15:48:53 <TrueBrain> and make functions responsible for one thing, and one thing only
15:49:04 <ZehMatt_> its a lot of duplicate code
15:49:10 <TrueBrain> yeah, but the problem we notices is not so much due to the video drivers; more what UpdateWindows does :D
15:49:17 <TrueBrain> but the video drivers need attention for sure too
15:49:24 <TrueBrain> as it is stupid that alt+enter keeps the resolution
15:49:31 <TrueBrain> I havent seen that in a game for ... 10+ years
15:49:39 <TrueBrain> go to the fucking native resolution, you silly
15:50:02 <TrueBrain> fullscreen borderless is defacto standard
15:50:19 <TrueBrain> so there is a lot more wrong with the video drivers :)
15:51:09 <ZehMatt_> theres also OnHundredthTick()
15:51:28 <ZehMatt_> maybe windows update should only call window->Update()
15:51:29 <TrueBrain> which ticks on the RealTime, right?
15:51:37 <ZehMatt_> so it can decide all of flashing/highlightining what not internally
15:51:41 <TrueBrain> some windows do need a tick on a game-time tick
15:52:00 <TrueBrain> so I guess there should be 2 callbacks: RealTime, and GameTime
15:52:04 <TrueBrain> both which can be configured
15:52:08 <TrueBrain> and indeed, than locally shit can be done
15:52:10 <ZehMatt_> currently UpdateWindows runs per tick
15:52:12 <TrueBrain> instead of globally :P
15:52:16 <ZehMatt_> DrawWindows every frame
15:52:31 <TrueBrain> yes, and a Window has I believe a Tick callback
15:52:39 <TrueBrain> and OneHunderthTick callback (which is RealTime)
15:52:47 <ZehMatt_> i made that real tiem
15:53:00 <ZehMatt_> which is kinda misleading too
15:53:21 <ZehMatt_> wouldnt be a Tick function enough
15:53:36 <TrueBrain> I have been told some also do stuff with the game tick
15:54:32 <TrueBrain> if I read the current (master) code right, every millisecond UpdateWindows is called, or what ever comes closest (no delta or anything)
15:54:51 <TrueBrain> he calls ProcessScheduleInvalidation and ProcesSHighlightedInvalidation on every window
15:55:14 <TrueBrain> and calls OnHunderdthTick every 100 "milliseconds" (what-ever delta it had)
15:56:15 <TrueBrain> unless you press FF .. than it goes as quickly as it can
15:56:18 <TrueBrain> here I am losing it :P
15:56:23 <TrueBrain> why the fuck does FF have influence on this ..
15:56:25 <ZehMatt_> on win32_v it calls UpdateWindows per game tick (30ms)
15:56:47 <ZehMatt_> where do you see it being called each ms
15:56:55 <TrueBrain> owh, misleading define, you are right
15:57:47 <ZehMatt_> so its internal counter wants 15 ticks
15:58:05 <TrueBrain> so UpdateWindows has 2 tasks ... invalidate parts of the screen for window updates .. and call OnHunderdthTick every 100 game ticks
15:58:19 <ZehMatt_> im curious about who calls OnTic
15:58:23 <TrueBrain> if you mean with 15, the highlight, yes
15:58:39 <TrueBrain> every 15 gameticks, the highlight cycles
15:59:37 <TrueBrain> and the 100th thing is used to force a redraw once so many game ticks
16:00:19 <TrueBrain> so that should indeed be based on game ticks
16:00:19 <ZehMatt_> so he hundred tick event should be moved into the UpdateWindow function in my PR
16:00:26 <ZehMatt_> and it shouldn't be using realtime
16:00:30 <TrueBrain> and the highlight to the Draw :P
16:00:39 <ZehMatt_> that highlight/flash whatever thing should be maybe dealt with different
16:01:17 <TrueBrain> than there is the OnTick callback
16:01:22 <TrueBrain> which is done in the StateGameLoop ..
16:01:31 <ZehMatt_> which is ran per tick
16:01:35 <ZehMatt_> from within GameLoop
16:01:46 <TrueBrain> each game tick, yes
16:01:59 <frosch123> i believe both OnTick and OnHundredthTick assume realtime
16:02:08 <TrueBrain> OnTick is used for animation
16:02:16 <frosch123> they are both called when the game is paused
16:02:23 <TrueBrain> frosch123: 100th seems to be gametick related .. is for setting itself dirty
16:02:30 <frosch123> OnHundredthTick is used to update cpu-intensive lists
16:02:32 <TrueBrain> frosch123: for example to change the Y-axis
16:02:38 <ZehMatt_> also out of curisouty
16:02:49 <ZehMatt_> fast forward is shifting the num updates correct?
16:03:00 <TrueBrain> but OnTick is now in the game loop .. but seems to be for animation .. so in DrawWindow makes more sense?
16:03:14 <TrueBrain> "shifting the num updates" <- no clue what you said there, sorry :)
16:03:21 <ZehMatt_> originally the game went like
16:03:42 <ZehMatt_> numUpdates = (timeElapsed / ticks_per_sec) << speed;
16:03:50 <ZehMatt_> i guess you guys dont have that anymore
16:04:13 <TrueBrain> FF has been ,for as long as I can remember, do everything as fast as you possibly can
16:04:20 <TrueBrain> in other words: don't sleep
16:04:29 <ZehMatt_> i see, slightly different to orct2 then
16:04:34 <TrueBrain> I do not think it ever "just made the game faster"
16:04:36 <ZehMatt_> where its basically a timescale
16:04:51 <TrueBrain> don't confuse RCT too much with TT; they are a few years apart :)
16:04:54 <ZehMatt_> so the highlight delay could be simply increased by the scale
16:05:02 <TrueBrain> lot of stuff he did for RCT he never did for TT :P
16:05:05 <ZehMatt_> but not in this case
16:05:27 <TrueBrain> highlight delay should not be influenced by FF, in my opinion
16:05:30 <TrueBrain> it is just a visual gimmick
16:05:43 <ZehMatt_> yes but if your game would run 2x the speed
16:05:45 <TrueBrain> sure, it gives a cool feeling of LOOK HOW FAST MY GAME IS GOING :D
16:05:49 <ZehMatt_> you could say the highlight time needs 2x longer
16:05:55 <ZehMatt_> and it will always look the same
16:05:59 <TrueBrain> no, you should talk about gameticks and realticks
16:06:04 <TrueBrain> not trying to map one on the other
16:06:07 <TrueBrain> that is what brought us in this mess :D
16:06:20 <ZehMatt_> using ticks is fine if you know how fast things are
16:06:32 <TrueBrain> no; ticks already have a resolution
16:06:46 <TrueBrain> GUI stuff should have nothing to do with Game stuff
16:06:52 <TrueBrain> you should be able to thread them even
16:06:58 <TrueBrain> just with a mutex to exchange data
16:07:23 <ZehMatt_> ok let me break it down
16:07:33 <ZehMatt_> you want OnTick, OnHundredthTick realtime based
16:07:44 <ZehMatt_> altho OnTick currently is bound to the game loop
16:07:51 <ZehMatt_> which is 30ms between ticks
16:08:24 <TrueBrain> I am not sure 100th tick should be realtime; we have to look how it is used for that honestly
16:08:29 <TrueBrain> there might be 2 usages
16:08:31 <ZehMatt_> so essentially UpdateWindows and DrawWindow requires to be called every frame
16:08:35 <TrueBrain> for example, updating a signlist, is realtime
16:08:42 <TrueBrain> updating the y-axis of the graph, is gametime
16:09:23 <TrueBrain> and that is why I think the approach is wrong; splitting UpdateWindows is only showing the problem
16:09:40 <TrueBrain> I think we first have to start with the Window itself, and clean those up to make more clear what we want to be influenced by FF
16:09:53 <TrueBrain> for example, animation of a news article coming up (animation from the bottom)
16:09:58 <TrueBrain> should that be influenced by FF?
16:10:02 <ZehMatt_> you still need to know when those updates are called and from where I believe
16:10:34 <ZehMatt_> i think its important for the network part that the host isnt doing anything out of order where clients do it in a different spot
16:11:01 <TrueBrain> so is animation of a Window important? If that is different in speed, does anything break?
16:11:10 <TrueBrain> (between server and client)
16:11:13 <ZehMatt_> im not sure how you check desyncs
16:11:20 <ZehMatt_> in orct2 every active sprite is hashed
16:11:21 <TrueBrain> desyncs is about randomizers getting out of sync
16:11:42 <TrueBrain> there are 2 randomizers: one that should be in sync, and is game related
16:11:45 <ZehMatt_> it checks the prng state + sprites
16:11:48 <TrueBrain> and one that is used for everything else
16:11:57 <TrueBrain> (here too you see the 2 worlds; game-world, and the rest)
16:12:16 <ZehMatt_> but i havent looked into how network events are handled
16:12:21 <TrueBrain> that is all there is to it
16:12:29 <ZehMatt_> in the current refactor I'm doing on orct2 none of the actions are executed immediately
16:12:33 <TrueBrain> the only important thing is that game-related stuff are handled in-order
16:12:50 <ZehMatt_> they are queued for the end of the update loop so clients will do the same regardless where the action is invoked from
16:12:52 <TrueBrain> (and for that to work, all network commands are always queued by 1 tick)
16:13:01 <TrueBrain> exactly; default trick
16:13:15 <TrueBrain> so that is not really relevant for our Window stuff :)
16:13:19 <TrueBrain> they do not influence the game state
16:13:34 <TrueBrain> so animation speed is irrelevant .. or at least should be :D
16:13:42 <ZehMatt_> makes things much easier
16:14:00 <TrueBrain> OpenTTD had a lot of desync issues back in 2004
16:14:00 <ZehMatt_> well it never had mp honestly in the vanilla game
16:14:07 <TrueBrain> when rewriting the network, we changed it to a lock-step method
16:14:18 <TrueBrain> so client sends to server, server sends to all clients WHEN to execute it
16:14:31 <TrueBrain> and the WHEN is always at least current + 1
16:14:39 <TrueBrain> then server says: all step to N
16:14:47 <TrueBrain> (server is in control)
16:14:48 <ZehMatt_> not too different then
16:14:55 <ZehMatt_> clients cant go beyond host ticks
16:14:59 <TrueBrain> so if you click anything on a client, it takes at least 2 ticks before you see it execute
16:15:02 <ZehMatt_> actions are executed on a specific tick
16:15:24 <ZehMatt_> it just waits for the host to do it
16:15:28 <ZehMatt_> tells the client which tick
16:15:34 <ZehMatt_> and at tick N client(s) does it
16:15:41 <TrueBrain> so back to our current problem: most games talk about an FPS and UPS these days, for good reason
16:15:51 <TrueBrain> FPS is about the client rendering .. UPS about the gamestate
16:16:04 <TrueBrain> if UPS takes 90% of my CPU time, do I care if my FPS drops to 10fps?
16:16:16 <TrueBrain> (currently they are locked; if FPS drops, UPS does, and other way around)
16:16:27 <TrueBrain> this is why you have a hard time quiting the game if you load a very big map
16:16:49 <TrueBrain> I would like to lock my FPS to .. say .. at least 10?
16:16:52 <TrueBrain> and UPS can suffer more
16:17:04 <TrueBrain> but having both UPS and FPS at 1 ... makes some shitty gameplay :P
16:17:50 <peter1138> OnTick() should be game-tick based
16:18:00 <peter1138> There should be an OnRealtimeTick() that is realtime backed.
16:18:04 <TrueBrain> OnTick mostly handles shit like animation atm
16:18:29 <TrueBrain> I havent found an OnTick yet that does anything game-state related
16:18:30 <peter1138> Ok, scrap OnTick(), add OnGameTick() and OnRealtimeTick()
16:18:30 <ZehMatt_> arent animations based on ticks?
16:18:39 <TrueBrain> peter1138: fine by me :P
16:18:48 <TrueBrain> ZehMatt_: currently everything is based on ticks
16:18:53 <TrueBrain> but lets forget what is and isnt
16:18:57 <TrueBrain> lets talk about what we want
16:19:07 <TrueBrain> do we want animation to be game tick or real tick based?
16:19:14 <TrueBrain> that is the question we should be asking :)
16:19:24 <TrueBrain> and here is a minor issue ... NewGRFs
16:19:24 <peter1138> real tick, I think.
16:19:26 <ZehMatt_> well if you fast forward the game you would expect animations to go faster?
16:19:29 <TrueBrain> they can influence game state ...
16:19:42 <peter1138> ZehMatt_, game animations yes, window animations? no!
16:19:43 <TrueBrain> so where is andy :P
16:19:56 <TrueBrain> so anything in a viewport should go quicker with FF
16:20:06 <TrueBrain> anything else should not (From a visual point of view)?
16:20:16 <ZehMatt_> well where would be such code
16:20:20 <peter1138> Quite a few OnTick()s just refresh data if needed
16:20:24 <ZehMatt_> so far theres only the highlight i can think off
16:20:24 <peter1138> That seems to be the wrong place to do it.
16:20:36 <peter1138> ZehMatt_, scrolling credits
16:20:47 <peter1138> ZehMatt_, news window pop up
16:20:49 <TrueBrain> animation in general
16:20:57 <TrueBrain> (not sprite-animation :D)
16:21:01 <TrueBrain> transitions, maybe a better word
16:21:15 <TrueBrain> news in the banner scrolling by
16:21:18 <TrueBrain> (from right to left)
16:21:42 <TrueBrain> but also window dragging?
16:21:45 <peter1138> The settings window uses the OnTick() event to handle click debouncing.
16:22:06 <TrueBrain> button down/up state
16:22:08 <peter1138> well, its buttons are not "real"
16:22:11 <TrueBrain> (the time to go from one to the other)
16:22:23 <peter1138> also, something about scrollbars uses ticks
16:22:35 <TrueBrain> so in FF my scrollbar goes a lot faster?
16:22:59 <peter1138> Something about button release times or something
16:23:03 <peter1138> Would need to look it up again.
16:23:40 <TrueBrain> so possibly a good start for this is not with splitting UpdateWindows or when it is called, but start using a delta for "realtick" updates
16:23:51 <TrueBrain> so that animation always takes, say, 1 second, for news to pop out
16:23:56 <TrueBrain> no matter what the current FPS is/was
16:24:00 <TrueBrain> no matter the FF settings?
16:24:13 <ZehMatt_> from where I understand it
16:24:18 <ZehMatt_> OnTick has to be always each 30ms
16:24:27 <ZehMatt_> otherwise things go to fast
16:24:36 <TrueBrain> we just established there is not 1 rule for OnTick
16:24:43 <peter1138> Some things within OnTick() are to do with refreshing data, that should be game ticks.
16:24:53 <ZehMatt_> it moves every tick 4 pixel
16:24:56 <peter1138> Some things are realtime. Yeah, we just discussed :p
16:24:59 <ZehMatt_> making OnTick faster moves more pixels
16:25:12 <ZehMatt_> so why cant we leave OnTick on 30
16:25:17 <peter1138> I have an idea that I should just add OnRealtimeTick() and rename OnTick() and do a PR?
16:25:20 <TrueBrain> we just, in the last 5 minutes, showed many situations with different solutions :)
16:25:30 <peter1138> And then ZehMatt_'s PR can just be about the updatewindows change.
16:25:47 <ZehMatt_> feel free to commit onto mine
16:25:53 <ZehMatt_> the topic is the same
16:25:54 <TrueBrain> ZehMatt_: read up plz :) We keep telling you: some Window uses OnTick for real time stuff, some use it for game time stuff
16:25:57 <TrueBrain> there is no 1 solution
16:26:23 <peter1138> okay guys, i'm firing up VS ;D
16:26:30 <TrueBrain> but I do not think that OnRealtimeTick() is a solution; I think OnRealtimeTick(delta) is
16:26:44 <ZehMatt_> you guys are the better judge to what needs moving
16:26:55 <peter1138> TrueBrain, so that windows don't need to reference _realtime_ticks themselves?
16:27:08 <ZehMatt_> I agree with peter1138
16:27:13 <ZehMatt_> thats how it should be done normally
16:27:16 <peter1138> TrueBrain, thing is when you want to wait 450ms... what use is delta?
16:27:17 <TrueBrain> peter1138: so that if the FPS drops, things still end in the defined time
16:27:26 <LordAro> limiting scope/usage of global vars is never a bad thing
16:27:38 <peter1138> LordAro, it would mean every window needs to keep track though.
16:27:45 <TrueBrain> if you want to wait 450ms, you have an internal time saying: 450 -= delta
16:27:55 <TrueBrain> but do we have any window that does that?
16:27:57 <ZehMatt_> cant a window request a timer
16:28:02 <ZehMatt_> to make things even simpler
16:28:12 <ZehMatt_> AddTimerFunc(&MyWindow::fn, this, delay)
16:28:13 <TrueBrain> currently we have 2 callsbacks: every gametick, and every 100 gameticks
16:28:27 <TrueBrain> but normally, in UI animation, you use deltas
16:28:30 <TrueBrain> not "amount of ticks"
16:28:36 <TrueBrain> as if you are in need of CPU, things get weird
16:29:22 <TrueBrain> for gameticks we cannot use a delta, because game state is important :P
16:29:23 <ZehMatt_> also not all windows even implement OnTick
16:29:25 <TrueBrain> but for realtime you can
16:29:31 <TrueBrain> of course they don't
16:29:35 <TrueBrain> why would every need to
16:29:41 <ZehMatt_> but you still iterate each window and call the virtual func
16:29:53 <ZehMatt_> not that you'll ever have 1000+ windows
16:29:59 <ZehMatt_> its just a waste calling empty functions :p
16:30:06 <TrueBrain> dont confuse the current discusion with pre-mature optimizations :)
16:30:15 <ZehMatt_> im not talking about optimizations
16:30:25 <TrueBrain> [16:29] <ZehMatt_> its just a waste calling empty functions :p
16:30:26 <ZehMatt_> rather a system where you can setup timers that run the requested time
16:30:32 <peter1138> TrueBrain, hmm, i'd use "expires = _realtime_ticks + 450;" to set the timer, and "if (_realtime_ticks >= expires) {}" to cause the action to happen
16:30:32 <TrueBrain> come back about that when you can profile it is an issue ;)
16:30:51 <TrueBrain> peter1138: TICKS. That will not work
16:30:55 <TrueBrain> it does work if you call it _realtime_clock
16:30:58 <peter1138> realtime-ticks in this case is ms :p
16:31:19 <TrueBrain> but yes, either you use a global msec, or a local delta_msec
16:31:23 <LordAro> std::chrono::high_resolution_clock
16:31:34 <peter1138> _realtime_ticks IS in milliseconds.
16:31:39 <TrueBrain> point is, don't depend on how often YOU are called
16:31:56 <TrueBrain> peter1138: if that is the case, the name is misleading :)
16:32:06 <TrueBrain> ticks suggests there is no predefined value between 2 ticks, just a best-effort :)
16:32:22 <TrueBrain> (which is why game-ticks is such a poor value for UI stuff :D)
16:32:33 <TrueBrain> but okay, tomato tomato :) Lets call it a realtime_clock :)
16:32:49 <TrueBrain> or, ofc, the std::chrono :)
16:33:16 <TrueBrain> and if you do both the delta and the clock, you fix both cases: those where you want to wait 450ms, and those who are doing animation
16:33:27 <peter1138> Let's do the delta.
16:33:28 <LordAro> is the argument here only to do with the name of _realtime_ticks variable?
16:33:32 <peter1138> It removes use of globals.
16:33:35 <peter1138> LordAro, looks it :p
16:33:49 <TrueBrain> LordAro: that is what we narrowed down to now, yes
16:34:06 <TrueBrain> talking the same language is for some reason important in conversations
16:34:08 <TrueBrain> dunno what that is about
16:34:23 <ZehMatt_> non relevant question: are you guys planning on changing the coding style perhaps any day
16:34:31 <peter1138> grep and vim is much easier to work with.
16:34:38 <TrueBrain> very very unlikely; you would have to make a very strong case ZehMatt_
16:34:48 <peter1138> ZehMatt_, changing what for what purpose?
16:34:51 <ZehMatt_> typing_things_like_this_is_silly_imho
16:35:04 <TrueBrain> AndTypingLikeThisIsAnyBetter?
16:35:24 <LordAro> well that's just objectively wrong :p
16:35:27 <TrueBrain> coding styles have no room for personal preference
16:35:38 <LordAro> also what TrueBrain said
16:35:43 <TrueBrain> the only important thing is that we all do the same
16:35:45 <ZehMatt_> but you guys arent C either
16:35:56 <LordAro> although my personal preferences do align quite strongly with OTTD's code style :p
16:35:58 <TrueBrain> and changing the full codebase to change from one casing to the other, is silly :)
16:36:26 <ZehMatt_> well this is an rather unconvential style
16:36:41 <ZehMatt_> im more the industrie guy so I barely see this unless I dig up 70's code
16:36:45 <TrueBrain> honestly, most project I work with use something really similar
16:36:52 <TrueBrain> so I guess it depends on your experience with other projects
16:36:57 <TrueBrain> again, personal preference :)
16:37:05 <TrueBrain> Java uses another style, sure
16:37:23 <Alberth> java itself doesn't mind, I found :p
16:37:39 <LordAro> ah least we don't have the "declare variables before use" thing from C
16:37:39 <TrueBrain> you are only heavily suggested to use a certain way :D
16:38:09 <TrueBrain> declare before use ... I think I dont understand you there :P
16:38:10 <Alberth> ZehMatt_: just become style agnostic, code in whatever is prefered
16:38:26 <peter1138> "more the industry guy" doesn't hold any sway. That assumes none of us does any professional coding, which is bullcrap.
16:38:34 <LordAro> int foo; .....; foo = bar();
16:38:40 <peter1138> Oh, unless you meant industrial systems.
16:38:40 <ZehMatt_> i didnt mean to say that
16:38:48 <TrueBrain> LordAro: in C++ you also have to do that? What am I missing?
16:38:48 <peter1138> In which case, who cares, they're all prehistoric anyway.
16:38:55 <ZehMatt_> its just what ive seen so far
16:39:02 <ZehMatt_> they all stick to more or less the same thing
16:39:03 <peter1138> Well, now you've seen OpenTTD :D
16:39:05 <LordAro> TrueBrain: int foo = bar();
16:39:11 <TrueBrain> LordAro: you can do that in C too?
16:39:17 <Alberth> TrueBrain: a few statements not involving 'foo' at the dots :p
16:39:24 <LordAro> TrueBrain: nowadays yes, but people often don't because of hysterical reasons
16:39:26 <ZehMatt_> and i didnt mean to offend anyone
16:39:33 <TrueBrain> LordAro: so your argument was void :) Okay :)
16:39:34 <peter1138> LordAro, we do have the declare first thing in a few places, left over of course.
16:39:45 <Alberth> LordAro: like Matlab, still using C89 :p
16:39:57 <TrueBrain> LordAro: I was like ... they fixed that .... LONG ago :P
16:40:18 <peter1138> ZehMatt_, you'll get on to tabs vs spaces at some point and that'll lead no where :p
16:40:30 <ZehMatt_> ive been there many times
16:40:32 <TrueBrain> but I guess the next one you say is that you are happy we can use // for comments :P
16:40:35 <ZehMatt_> something im not too worried about imho
16:40:43 <ZehMatt_> i just fix it to whats wanted
16:40:55 <ZehMatt_> because converting them is so hard in 2018 :D
16:41:18 <Alberth> most editors aren't worth their name :p
16:41:33 <TrueBrain> anywayyyyyyy ... UI ...
16:41:37 <ZehMatt_> nowadays i just use spaces
16:41:43 <peter1138> Any idea why SmallMapGui is in smallmap_gui.h?
16:41:48 <peter1138> None of the other windows are in a header file.
16:41:58 <TrueBrain> I see a commit coming up :P
16:42:24 <peter1138> TrueBrain, I can't, you took that away from us! You stole our rights! I'm gonna protest!
16:42:35 <TrueBrain> peter1138: you go girl :P
16:42:50 <TrueBrain> so to conclude a bit here ZehMatt_, I think before your PR is going to work, we should make most of the UI independant of FF
16:42:53 <TrueBrain> by what-ever means :P
16:43:07 <TrueBrain> as then your commit makes a lot of sense
16:43:26 <TrueBrain> basically the same result, but your PR started top-down
16:43:29 <peter1138> There is one line in src/linkgraph/linkgraph_gui.cpp that reaches into SmallMapWindow directly.
16:43:31 <TrueBrain> I suggest we first run a bottom-up :)
16:43:33 <peter1138> And it probably shouldn't.
16:43:52 <ZehMatt_> cant deny that the window dragging and such is much better
16:43:57 <ZehMatt_> with a few downsides on FF
16:44:05 <peter1138> It's shit for me, cos of that glitching thing :(
16:44:19 <peter1138> But if I leave Minecraft open behind the game, it's all perfect.
16:44:22 <ZehMatt_> im not even sure what the issue is about
16:44:42 <ZehMatt_> its not a true fullscreen thing
16:44:46 <TrueBrain> known_bugs.txt entry: if you have screen tearing, launch Minecraft while playing OpenTTD!
16:45:06 <TrueBrain> not sure what to think about that :D
16:45:26 <peter1138> Not even joking. Actually any game that does screen flipping in the background.
16:45:33 <peter1138> It makes me think it's a driver issue.
16:45:41 <ZehMatt_> anyway if I can somehow help changing window code just tell me what to do
16:45:48 <peter1138> I'd say "but it does it on Linux" but it's effectively the same driver there :p
16:45:54 <ZehMatt_> but first we have to establish where to put what
16:46:05 <peter1138> I might fix this smallmap window first.
16:46:14 <TrueBrain> well, I am playing Factorio Sea Block, so meh :P
16:46:19 <ZehMatt_> you'll also introduce OnRealTimeTick?
16:47:21 <peter1138> static const uint LINKGRAPH_DELAY = 0xf;
16:47:26 <peter1138> Who allowed that ;(
16:47:33 <peter1138> That 0xf... means...
16:47:53 <peter1138> 15 ticks. Aka 450ms?
16:48:05 <TrueBrain> "one moment ladies and gentlemen, we are experiencing some annoyance"
16:48:19 <TrueBrain> 450 / MILLISECONDS_PER_TICK? :)
16:48:39 <peter1138> is it signed or unsigned in the condition?
16:48:53 <TrueBrain> >= 0 would be more fun
16:49:06 <TrueBrain> I love that CLion warngs me about those stupid things while writing the code :P
16:49:47 <peter1138> Did something see "byte" ?
16:49:51 <TrueBrain> because 0xfe looks weird
16:49:57 <peter1138> 7.65 seconds seems weird
16:50:08 <APTX_> you could have written it as if (refresh --> 0)
16:50:21 <TrueBrain> APTX_: but it doesn't do the same! :P
16:50:45 <ZehMatt_> thats why I stick to my timer system :v
16:50:45 <peter1138> It looks fun though.
16:50:49 <APTX_> it should do the same thing
16:50:51 <ZehMatt_> such code wouldn't be required
16:51:03 <peter1138> APTX_, no, --refresh vs refresh-- evaluates differently
16:51:22 <TrueBrain> APTX_: you are one step later in your case :D
16:51:36 <TrueBrain> if (--1 > 0) is true
16:51:39 <TrueBrain> if (1-- > 0) is false
16:51:54 <TrueBrain> -- is such a fun operator :D
16:52:02 <TrueBrain> (--a) returns (a - 1)
16:52:18 <TrueBrain> an operator with a side-effect :D
16:52:36 <TrueBrain> a.decrease(return_origin=True) vs a.decrease(return_origin=False) :D
16:52:49 <TrueBrain> too much Python TrueBrain .. okay .. sorry ....
16:53:18 <TrueBrain> but it looks awesome, if (refresh --> 0) :D
16:53:19 <APTX_> I did see it after the first line though
16:53:23 <TrueBrain> that would fuck up so many people :D
16:53:48 <peter1138> I need my PC to compile all the time.
16:53:58 <peter1138> When it's idle, the soundcard produces a lot of noise.
16:54:10 <LordAro> peter1138: that's the reverse of normal
16:54:13 <TrueBrain> unplug your soundcard
16:54:26 <LordAro> my soundcard makes noise when i'm doing a lot of disk activity
16:54:31 <peter1138> Difficult, it's on the motherboard.
16:54:50 <TrueBrain> lol @ APTX_ .. that is horrible
16:55:07 <LordAro> hmm, do we need labels for PRs?
16:55:08 <ZehMatt_> nowadays i just go with usb sound
16:55:13 <LordAro> not-ready, and such like?
16:55:15 <TrueBrain> one thing I still want to sneak in a project is: #define true (random()>0.95?1:0)
16:55:56 <APTX_> TrueBrain: you want to do it with sizeof
16:56:04 <TrueBrain> LordAro: I was more wondering the other solution .. close PRs if they need something else to happen first, or are being split up, etc
16:56:34 <TrueBrain> as I am unsure leaving a PR open with somethinglike: this will be done after N, we won't end up with 100 PRs :P
16:57:01 <LordAro> it's a tricky balance, i agree
16:57:20 <peter1138> TrueBrain, can PRs have dependencies?
16:57:26 <TrueBrain> I think 6749 for example can be closed, as he is splitting it up in better smaller chunks
16:57:32 <Eddi|zuHause> TrueBrain: close PRs if they weren't changed in a month?
16:57:44 <LordAro> as long as the PRs are waiting on the submitter rather than the devs, i wouldn't be too worried about them
16:57:54 <TrueBrain> and PR 6750 has no resolution; so should it remain a PR? Reopening is alwayspossible
16:58:16 <LordAro> and then close them after a month of inactivity or something
16:58:41 <peter1138> virtual void OnTick()
16:58:44 <LordAro> i got the impression that 6749 was being split into other PRs, but the bulk of it was staying where it was
16:58:48 <peter1138> { /* Overrride default OnTick */
16:58:50 <TrueBrain> LordAro: but how does it help .. it just keeps pulling attention
16:58:53 <TrueBrain> having an empty PR list is nice
16:59:10 <peter1138> Ah, inherits from another window.
16:59:17 <LordAro> it is, but the reality is that people open PRs before they are ready :p
16:59:22 <TrueBrain> LordAro: sure, I guess that can be the result; b ut shouldnt we close the PR for now, and reopen when it is time it can be reviewed?
16:59:33 <TrueBrain> so there should be some wiggleroom, for sure
16:59:38 <peter1138> They *think* they are ready.
16:59:43 *** snail_UES_ has joined #openttd
16:59:56 <LordAro> i don't think things should be closed unless there's no chance they'll be reopened again
16:59:57 <TrueBrain> but if we keep PRs open for too long, we just start ignoring all PRs :P
17:00:10 <LordAro> closing/reopening looks "bad", imo
17:00:23 <TrueBrain> closing only means: this is not something we can actively help you with
17:00:34 <LordAro> idk, as if we can't make up our mind what to do with it
17:01:08 <TrueBrain> huh? only outsiders might think that (for what-ever reason), but do we care about those?
17:01:19 <TrueBrain> it is about keeping things clear and workable for us, devs
17:01:34 <LordAro> yeah, and i think labels is a better way of doing that
17:01:53 <TrueBrain> and I am doubting that .. same for issues btw
17:02:18 <TrueBrain> keeping things open where the action is not ours, is just asking for more work on our side
17:02:46 <LordAro> i agree that PRs shouldn't sit around doing nothing forever, but closing them just because the submitter is taking longer than a day or two to get back to it doesn't seem reasonable either
17:02:47 <TrueBrain> we have to keep the author responsible for his PR :)
17:03:00 <TrueBrain> how did you jump to that :P
17:03:14 <TrueBrain> there is a lot of grey; not that much black and white here :)
17:03:17 <LordAro> how did you jump to "PRs are devs responsibility" :p
17:03:38 <LordAro> 16:02:18 < TrueBrain> keeping things open where the action is not ours, is just asking for more work on our side
17:03:54 <TrueBrain> and how did you read into that: PRs are devs responsibility?!
17:04:00 <TrueBrain> really, less black/white, more grey plz :)
17:04:25 <TrueBrain> lets go back to the examples I was bringing: we now have a PR which was too big, and the author is splitting it up in smaller chunks
17:04:42 <TrueBrain> is it useful for us to keep the origin PR open? There is a chance he makes thatone smaller, or maybe he makes a new one
17:04:49 <TrueBrain> does keeping the PR contribute to anything, for us?
17:05:01 <LordAro> right, we need to ask him what he's intending to do with it
17:05:04 <TrueBrain> I was planning today to ask the author exactly that btw
17:05:18 <TrueBrain> as keeping it around for us, is just noise
17:05:23 <TrueBrain> we cannot do anything with it in its current state
17:05:36 <ZehMatt_> are we talking about my PR?
17:05:39 <TrueBrain> so, by closing it, we put the ball back to the author; he needs to tell us when we are done again
17:05:44 <TrueBrain> ZehMatt_: no, but we can now :)
17:05:54 <TrueBrain> as similar goes for yours; but it is a bit different
17:05:57 <LordAro> i see no benefit to closing it before we know what's going to be done with it
17:06:10 <LordAro> it's pointless to close it if it just gets reopened again
17:06:35 <TrueBrain> okay, LordAro, take a deep breath, step out of your current rain of thought, and lets jump on it from a different angle :)
17:06:56 <TrueBrain> lets take the MIDI PR: 1 of 2 actions I planned on doing today
17:07:13 <TrueBrain> 1) if he joins IRC, ask him if we can close his PR, and that he reopens it when he is done, or how he wanted to fix this
17:07:16 <TrueBrain> 2) ask the same in the ticket
17:07:22 <TrueBrain> we put the ball to HIM
17:07:29 <TrueBrain> that is how you deal with these things
17:07:39 <TrueBrain> you don't rudely go closing tickets and walk on :)
17:08:12 <TrueBrain> so what is the downside of doing that? we can scare off the author
17:08:19 <TrueBrain> so we have to make it very clear it is not saying no
17:08:20 <LordAro> i disagree with the "close his PR, and that he reopens it when he is done" bit
17:08:35 <TrueBrain> okay, you disagree; why?
17:08:44 <_dp_> this is getting weird... pretty much every time I decide not to pay for mobile internet and it runs out power outage happens within few days %)
17:08:45 <LordAro> it only serves to create noise in the issue
17:08:45 <ZehMatt_> what about WIP label
17:08:58 <TrueBrain> noise in the issue?
17:09:01 <TrueBrain> from whos perspective?
17:09:20 <TrueBrain> as we as dev won't look at it anymore
17:09:28 <TrueBrain> the author doesnt care, as he is working on it
17:09:29 <LordAro> "closed" from the outside looks as if it is dead
17:09:39 <TrueBrain> I think you have to recalibrate that :)
17:09:43 <TrueBrain> in GitHub that is very much not true
17:09:47 <TrueBrain> it is just a "not now"
17:09:54 <LordAro> that has not been my experience
17:09:57 <TrueBrain> it has nothing to do with dead or alive
17:10:13 <TrueBrain> but you cannot possibly keep PRs alive hoping the user picks it up
17:10:16 <TrueBrain> you say, close them after a month
17:10:23 <TrueBrain> but what if he reopens it 1 day after that with an update?
17:10:42 <peter1138> Hmm, so that status bar ticker...
17:10:50 <peter1138> Currently it's game ticks, which is wrong, right?
17:10:57 <TrueBrain> I think it is peter1138
17:10:57 <peter1138> But also, it stops when you pause the game.
17:11:45 <TrueBrain> ZehMatt_: labels are nice, but in general you should try to avoid having issues/PRs around that are not moving
17:11:57 <TrueBrain> as in the end you only end up with a lot of issues and PRs :)
17:12:08 <TrueBrain> bit like cleaning your room ... "I am going to keep this, as I mgiht need it some day"
17:12:09 <peter1138> Do we have any PRs that are not moving yet?
17:12:12 <TrueBrain> you only end up with a pile of junk :P
17:12:21 <TrueBrain> peter1138: they are all too fresh
17:12:31 <TrueBrain> 2 I doubt if they survive the day
17:12:46 <TrueBrain> one depends on your actions in the next few hours :P :P
17:12:57 <frosch123> peter1138: i have no idea how to continue with 6751 :)
17:13:09 <frosch123> an api request without usecase
17:13:36 <TrueBrain> frosch123: adding stuff for adding, is arely sensible
17:13:49 <TrueBrain> so why are you not sure how to continue? :D
17:14:12 <frosch123> i always left the closing to others :p
17:15:00 <TrueBrain> I like LordAro's suggestion there; but is Zuu willing to do that? :)
17:15:33 <TrueBrain> (btw, LordAro, talking about annoying noise in issues ... every force push stays behind in the issue it references ... that is just a bug in GitHub if you ask me :( )
17:17:21 <peter1138> frosch123, hmm, yeah, that last comment in 6751 is bizaare. Like... the submitter didn't even write the patch.
17:17:38 <peter1138> Oh it says that in the first note.
17:17:51 <frosch123> yes, zuu dug out some krimm patch
17:18:41 <TrueBrain> so would the PR be okay if it also had IsCanalTile? Or unified in a single function? Or not at all till someone asks for it again?
17:18:57 <peter1138> And yes, the problem with the use case is exactly the problem you said.
17:19:12 <frosch123> TrueBrain: i would really like to know the intention
17:19:21 <frosch123> like, should the ai avoid clearing rivers when building?
17:19:31 <frosch123> but then cleaning canals is just as bad
17:19:33 <peter1138> It's okay to clear canals?
17:19:44 <frosch123> and cleaning sea is fine or what?
17:19:47 <TrueBrain> he wrote a bit why in the originl issue
17:20:09 <TrueBrain> is krinn still alive in OpenTTD community?
17:20:31 <peter1138> The "why" seems to be "we need to detect rivers" but doesn't explain what's special about rivers.
17:21:10 <TrueBrain> because you have to destroy them before youcan build on them, it seems :)
17:21:22 <TrueBrain> and from how I read it, you currently have no way to know you could destroy it
17:22:49 <frosch123> hmm, there is ScriptMarine::IsCanalTile
17:23:29 <TrueBrain> so alias it to ScriptTile too?
17:23:41 <peter1138> Hmm, the status bar scrolling has a fixed "width"
17:23:53 <peter1138> It doesn't care about the length of the text or the width of the widget.
17:23:58 *** agentw4b has joined #openttd
17:24:05 <frosch123> i guess in that case ScriptTile only has landscape stuff
17:24:07 <TrueBrain> peter1138: stop finding work :P
17:24:17 <frosch123> while the transport stuff is in more specific classes
17:24:19 <peter1138> That's a separate issue.
17:24:39 <TrueBrain> frosch123: guess the same holds for roads etc indeed
17:24:44 <frosch123> peter1138: every modern games scrolls those short news vertically :p
17:24:47 <TrueBrain> but is river a transport thing, or a landscape thing?
17:24:56 <peter1138> Hmm, 2 pixels every 30 ms.
17:24:57 <frosch123> rivers are not company constructed
17:25:06 <frosch123> so sea/river is landscape, canal is transport
17:25:08 <TrueBrain> frosch123: neither are town roads :)
17:25:33 <frosch123> oh, there is also ScriptTile::IsStationTile...
17:25:38 <TrueBrain> peter1138: best thing is that animation can look good in 2x too ! :P
17:26:01 <peter1138> Yeah, I mean... should it be faster if the the gui is scaled up?
17:26:12 <peter1138> Same with the credits window.
17:26:16 <peter1138> Well, again, separate issue.
17:26:48 <ZehMatt_> did i just open a can of worms
17:27:02 <peter1138> ZehMatt_, you "found" some issues :)
17:27:27 <peter1138> Rabbit holes. Warren?>
17:27:42 <ZehMatt_> i wonder, has it no one ever bothered before me that the UI is somewhat sluggish
17:27:59 <TrueBrain> bothered enough to do something about it, is the question I guess :)
17:28:51 <ZehMatt_> i also should setup my other PR at some point to remove GetTickCount calls
17:29:05 <peter1138> GetTickCount... uhm...
17:30:30 *** andythenorth has joined #openttd
17:30:55 <TrueBrain> nice solution frosch123 :)
17:31:21 <_dp_> does it make sense to make a patch that allows road/bus stops to overbuild each other?
17:33:21 <andythenorth> it does to me :P
17:33:49 <frosch123> does not sound useful to me
17:33:54 <frosch123> why would you want to do that?
17:34:00 <frosch123> they share no vehicles
17:34:26 <frosch123> it's kind of the opposite of an upgrade
17:35:07 <TrueBrain> frosch123: just wondering, if you give comments on a PR which are resolved, do you mind if someone else (for example in this case: me), accepts the PR and merge it? Or do you rather want to do that validation yourself?
17:35:18 <frosch123> well, "upgrade" is the wrong word. but we only allow overbuilding for compatible stuff
17:36:14 <frosch123> TrueBrain: nah, go ahead
17:36:29 <_dp_> frosch123, makes it faster to fix when you built the wrong one
17:36:57 <_dp_> frosch123, having wrong rv station type is just something I have constant issues with)
17:38:18 <TrueBrain> frosch123: cool, tnx :D Means I can make myself useful :D
17:39:44 <frosch123> i guess i should keep on "commenting" instead of "requesting changes" :)
17:40:18 <TrueBrain> I like requesting changes; I dislike GitHub not dismissing it with a push, but only if the line you marked is touched
17:40:20 <TrueBrain> that is just annoying
17:40:27 <TrueBrain> but I have no issues dismissing your request frosch123 :P
17:40:39 <_dp_> other part would be allowing rv station removal to remove any station type, but I'm not sure how to make it reasonable for vanilla
17:40:46 <TrueBrain> I miss a bit the overview of what still needs attention .. you see badly when someone pushed a new commit
17:43:02 *** Thedarkb1 has joined #openttd
17:43:48 <peter1138> Oh textbuf isn't a window of course.
17:44:03 <peter1138> Still, that shouldn't be sped up in fast-forward either.
17:44:18 <peter1138> But it's not a window so falls outside the remit of this patch.
17:46:35 <TrueBrain> and so it spreads :P
17:48:04 *** sla_ro|master has joined #openttd
17:49:34 <_dp_> frosch123, it's similar to overbuilding rail station with different rotation. Isn't much of "upgrading" either, just convenient way of reorganizing the station
17:49:39 <Eddi|zuHause> <frosch123> like, should the ai avoid clearing rivers when building? <-- without reading the whole backlog, i'd say AI should be prevented from clearing water unless it specifically says "i definitely want to clear water"
17:50:22 <peter1138> "Dispatch WE_TICK event over all windows"
17:50:29 <peter1138> Yeah, I don't think WE_TICK exists for a long time.
17:52:06 <peter1138> Gah, I can't scroll the window properly without 6756 ;p
17:52:47 <peter1138> Hmm, also, that one should probably remove the obsolete strings.
17:52:59 * _dp_ thinking of making AI that does nothing but deliberately destroying all rivers
17:53:06 <TrueBrain> what is the difference between map and viewport?
17:53:37 <_dp_> sadly you can't easily run it in mp :(
17:53:53 <peter1138> Previous wording was "camera"... where does that fit in?
17:54:07 <TrueBrain> I honestly dont know how they differ?
17:54:47 <peter1138> The difference is moving the map under a viewport, or moving a viewport over a map.
17:55:00 <peter1138> A weird distinction that affects only the direction of movement.
17:55:07 <peter1138> And it's not intuitive.
17:55:13 <TrueBrain> ah! That is the difference
17:55:19 <TrueBrain> holy crap, that took way too long :D
17:55:22 <peter1138> "reverse scroll" was logical because it was just "opposite to normal"
17:56:01 <peter1138> Btw, should CI warn if strings have been removed from english but are still present in other langs?
17:56:31 <peter1138> (Or, I guess, warn on any language file error?)
17:56:36 <Zuu> I think in general AIs should bridge canals so that if the player want to use it for ships it is not ruined.
17:56:46 <TrueBrain> currently any language error is ignored .. good question .. frosch123?
17:57:04 <Eddi|zuHause> warning sounds like the correct level
17:57:20 <Zuu> But then, it is hard to dictate what AIs people will write.
17:57:39 <TrueBrain> CI can either error or ignore; they dont have a 'warn' level
17:58:08 <TrueBrain> I really think we will have a GitHub bot soon .. so many of thse can be solved with that :)
17:58:17 <TrueBrain> the bot can just say in a comment: CI is fine, but did you know ...... :D
17:58:17 <Eddi|zuHause> Zuu: yes, an AI building roads should probably leave canals alone. but an AI building canals might want to reroute existing canals
17:58:29 <_dp_> TrueBrain, make it error and rethink if someone complains?
17:58:32 <frosch123> TrueBrain: we used to split removal of strings into separate commits, but maybe that is just wrong :p
17:58:43 <TrueBrain> frosch123: feels off :)
17:59:30 <LordAro> seems to me like it should be an error
17:59:33 <peter1138> Hmm, right, OnGameTick() and OnRealtimeTick(int delta_ms) created.
17:59:41 <peter1138> delta_ms just to make sure we know it's in milliseconds :)
17:59:50 <peter1138> And now... I need to call it.
17:59:52 <TrueBrain> frosch123 and LordAro have the same colour on IRC .. sometimes I ahve a hard time seeing one or the other replied :P
18:00:23 <LordAro> peter1138: clearly should std::chrono::duration :p
18:00:29 <LordAro> then it is very unambiguous
18:00:48 <TrueBrain> delta of the type signed feels wrong :D
18:03:06 <peter1138> I should make it float, in case we want sub-ms accuracy ;)
18:03:46 <TrueBrain> where is my shot-gun ....
18:05:34 <peter1138> True, floats are not that accurate.
18:05:37 <Eddi|zuHause> if you're ever doing "a-b" on a variable, it should probably have a signed type
18:06:47 <TrueBrain> owh, peter1138, just so I mentioned it, remember that TickCount wraps every ~49 days :P
18:08:44 <snail_UES_> hey guys, question about RandomAction2
18:08:58 <TrueBrain> bit random question, but sure
18:09:18 <snail_UES_> the specs say that bits 0…3 are used to count from the starting vehicle
18:09:33 <snail_UES_> but this would restrict to a max of 15 vehicles...
18:09:47 <Eddi|zuHause> anything larger than that you must push to register 0x100
18:10:23 <snail_UES_> ok… I was thinking about circumventing this by setting <count> to 0 and use register 0x100
18:10:32 <snail_UES_> so it’s possible, right?
18:11:29 <Eddi|zuHause> but nml does that automatically for you
18:11:58 <snail_UES_> ok, but I’m not using nml
18:16:06 <peter1138> TrueBrain, heh, yeah I'd already considered that. If it wraps it just does an extra tick with no delta. Next tick will carry on.
18:16:20 <peter1138> TrueBrain, may be a slight hiccup but won't break.
18:19:18 <peter1138> _realtime_ticks is only updated every 30ms...
18:19:30 <TrueBrain> so it is a ticks? :P
18:19:58 <peter1138> So it jumps 30 every time.
18:19:59 <Eddi|zuHause> peter1138: i think _realtime_ticks was meant for "do this tick anyway even though the actual game is paused"
19:07:28 <peter1138> Hmm, why would you update widget lowered state in OnTick()?
19:07:49 <TrueBrain> welcome to the sticky part called Window :)
19:08:03 <TrueBrain> write all these things down, and put ZehMatt_ to work too? :D
19:08:10 <peter1138> Should be in OnInvalidateData(), and then that called...
19:11:43 <glx> TrueBrain: what changes are needed to get the right icu from vcpkg ?
19:11:44 <peter1138> Ah, cos some of the data it depends on is in the video drivers.
19:12:22 <TrueBrain> glx: change 61 to 57 in the port file, run it, you get a sha mismatch, copy/paste the right sha in
19:14:34 <glx> arg they upgraded git again
19:15:06 <TrueBrain> as vcpkg updates a lot :)
19:15:09 <TrueBrain> that is the whole idea ;) :D
19:18:49 <glx> hmm I should get icu55 to compare with useful version
19:19:09 <TrueBrain> I guess we need to check both
19:19:23 <TrueBrain> if icu57 gives a large static, icu might be to blame. If it doesnt, VS2017
19:19:27 <TrueBrain> so roll your dice :D
19:31:39 <glx> I hope the MSYS2 it's getting won't conflict with my global MSYS
19:32:28 <TrueBrain> no clue; always installed it in a Docker :D
19:34:23 <TrueBrain> you made the output, or the tool? :P
19:34:33 <LordAro> glx: you can ignore most of them
19:34:45 <LordAro> i already excluded most
19:34:48 <LordAro> TrueBrain: the output :p
19:34:53 <TrueBrain> which tool does that?
19:36:34 *** synchris has joined #openttd
19:39:35 <glx> good it uses the right tools
19:41:24 <glx> could have been fun as I have msys bash, a bash from gitshell and the bash it installed from msys2
19:42:26 <glx> I already know I can't configure and make openttd from the gitshell
19:56:39 <peter1138> Was there a magic command to strip removed strings from other langs?
19:58:17 * Rubidium wonders how long this OpenTTD compile is going to take; 15 minutes in and already at sqapi.cpp
19:58:33 <TrueBrain> you need a better CPU Rubidium!
20:00:35 <nielsm> peter1138 last I asked the answer was "no"
20:00:51 <peter1138> And you didn't make one? :p
20:01:02 <nielsm> sed -i -e /STR_WHATEVER/d src/lang/*.txt src/lang/unfinished/*.txt
20:01:38 <nielsm> is what I ended up with
20:01:59 <Eddi|zuHause> maybe translator/eints should take care of that?
20:02:26 <Eddi|zuHause> so it scans for removed strings in english.txt and removes it from the other langfiles on its daily commit?
20:05:06 <Rubidium> TrueBrain: I'm fairly certain nobody's going to give me a CPU (and all the other required hardware) to make this compile significantly faster before the build completes
20:05:57 <Eddi|zuHause> Rubidium: how sure are you that the compile is not taking 5 weeks? :p
20:06:48 <Rubidium> not that sure, but having a machine that finished this compile much faster... it's going to be an oldie
20:11:37 *** Thedarkb1 has joined #openttd
20:18:28 <Rubidium> at least the md5sum of the languages is the same, so there's some good hope my patch actually works on BE machines
20:21:14 <LordAro> Rubidium: ...what are you compiling on?
20:25:54 <LordAro> i have not heard of that
20:28:09 *** sim-al2 is now known as Guest1198
20:28:10 *** sim-al2 has joined #openttd
20:28:45 *** snail_UES_ has joined #openttd
20:29:25 <Rubidium> LordAro: replace fake with qemu and you're more likely to find it
20:31:11 <TrueBrain> wow, you started a BE for that .. nice Rubidium :D
20:31:32 <peter1138> Ah, so that's why it's so slow :p
20:33:53 <TrueBrain> we all assumed he just had a terrible machine .. but he was doing something different :D
20:37:21 *** andythenorth has joined #openttd
20:44:05 <glx> Elapsed time for package icu:x64-windows-static: 57.6 min <-- not bad
20:44:51 <TrueBrain> its terrible how long it takes ... :(
20:46:30 <Rubidium> well, for me compiling squirrel takes about as long as that ;)
20:47:29 <peter1138> Hmm, it's rebuilding table/strings.h every time. What've I broked :S
20:47:41 <LordAro> Rubidium: is there a partiular reason for this, or just for fun?
20:47:59 <TrueBrain> he is doing something that makes me REALLY happy :D
20:48:21 <TrueBrain> otherwise I missed a law ..
20:48:39 <TrueBrain> although it would explain my past relationships I guess ....
20:48:43 <TrueBrain> now you made me depressed :'(
20:49:41 <TrueBrain> he didnt ask you to remember :P
20:50:31 <frosch123> meh, my generated images are not deterministic
20:50:40 <frosch123> i guess plantuml adds some timestamp or something
20:50:42 <TrueBrain> do we want to know? :P
20:54:31 <TrueBrain> owh, btw, Rubidium, your first patch works for MSVC. I have been using that all day with CMake and MSVC :P
20:54:40 <TrueBrain> second I didnt try, as MSVC :P
20:55:44 <peter1138> Hmm, it's oaky after make clean.
20:56:04 <TrueBrain> you have to copy that yourself
20:56:38 <TrueBrain> its in vcpkg\buildtrees\icu\src\icu-57.1\icu\source\common\cmemory.h
20:56:56 <TrueBrain> (it is no longer there in ICU 58+ :D
20:57:00 <TrueBrain> sorry, totally forgot
20:59:26 <glx> anyway .lib are huge compared to useful ones
21:01:31 <TrueBrain> yeah .. so possibly it is the way ICU is compiled ..
21:01:35 <TrueBrain> at least that narrows the issue down
21:04:21 <TrueBrain> so now the quesiton, is ICU55 any different I guess
21:04:27 <TrueBrain> so happy it is not me :D
21:27:10 <frosch123> he, finished my review, already outdated :p
21:28:28 <frosch123> hmm, or is it a github bug
21:29:15 <TrueBrain> or did you have the commit older then 33 minutes open?
21:29:26 <frosch123> no, i just opened it
21:31:39 <peter1138> Oops, yes, removed one too many.
21:37:03 <glx> probably too old for vcpkg
21:41:14 <glx> or it's just a problem in ICU55 source
21:41:55 <TrueBrain> I will see if tomorrow I can understand what vcpkg does, and what openttd-useful does
21:41:56 <glx> D:/developpement/GitHub/vcpkg/buildtrees/icu/src/icu-55.1/icu/source/io/ufile.c(70): warning C4013: '__iob_func' non défini(e) ; extern retournant int pris par défaut
21:41:57 <glx> D:/developpement/GitHub/vcpkg/buildtrees/icu/src/icu-55.1/icu/source/io/ufile.c(70): error C2109: un indice requiert un type tableau ou pointeur
21:42:24 <glx> I think openttd useful is built directly in VS
21:42:46 <glx> but michi_cc knows more I think
21:42:51 <TrueBrain> lets see ... there is a lengthy description of how it is build
21:42:58 <TrueBrain> I think Rubidium build those :)
21:43:34 <TrueBrain> ah, we rolled our own 'static' variant
21:43:38 <TrueBrain> what 'version 6' you refer to glx?
21:43:58 *** bakkerl is now known as Lamp-
21:45:01 <TrueBrain> okay, so we just heavily modified the ICU project file to make a static ... who knows what is in there and what is not :D Can explain the difference I guess
21:45:09 <TrueBrain> ah, of openttd-useful
21:45:18 <TrueBrain> you just said 'version 6' :P
21:45:24 <TrueBrain> silly if there is a newer version that it never got published tbh
21:45:49 <glx> yes useful version 6 is needed for VS2015 and up I think
21:46:07 <glx> but doesn't work for prievious
21:46:17 <TrueBrain> published as 'stable'
21:46:51 <glx> not sur about the last part ;)
21:48:08 <TrueBrain> but okay .. that means that the vcpkg static is just too static :D
21:51:07 <michi_cc> Ah, looking at the 6.0 source zip I see where the size difference comes from. Out ICU is build with a different, smaller content of icudata. Full ICU data has lots of stuff we never need (like e.g. tables of country names in each language).
21:51:51 <TrueBrain> any specifics how to disable that?
21:52:28 <michi_cc> By modifying the project files, i.e. there is no build option.
21:52:47 <TrueBrain> any specific profile file or something?
21:52:51 <TrueBrain> possibly a diff? :D
21:53:08 <glx> but handcrafted icu is inconsistant with using vcpkg to simplify our task
21:53:12 <michi_cc> TrueBrain: Download openttd-useful-6.0-source.zip
21:54:13 <glx> since windows 10 creator update, ICU is included at the OS level
21:54:30 <glx> but that won't help for previous windows versions
21:54:58 <glx> and I guess it doesn't include layout stuff
21:55:09 <TrueBrain> michi_cc: I want to patch vcpkg; so far it is a bit too vague for me :)
21:55:11 <michi_cc> I never checked how much of what we need is implemented by Uniscribe (which is the native Windows API).
21:55:34 <michi_cc> TrueBrain: The zip contains said diff.
21:55:46 <TrueBrain> now that is useful information :)
21:57:11 <TrueBrain> but why does ICU have a table of country names ...
21:57:21 <TrueBrain> sounds like ICU tried to do everything
21:57:38 <glx> they stopped doing the layout ;)
21:57:59 <TrueBrain> and only because they got sick of all the bugs they coulldnt fix :P
21:58:21 <michi_cc> Because ICU " providing Unicode and Globalization support". And we only need the Unicode stuff.
21:59:38 <TrueBrain> okay, 6.0 diff is similar to 5.1 diff
21:59:41 <TrueBrain> not really helpful, that diff
22:00:42 <TrueBrain> it adds static; it doesnt really show what to remove
22:01:59 <TrueBrain> we don't need any data part of ICU?
22:02:52 <michi_cc> We need some data part, but not all data.
22:03:11 <TrueBrain> any way to make that more specific?
22:03:29 <TrueBrain> as I cannot randomly not compile data :D Do we have a list, or is there some lookup, or? Any breadcrumbs?
22:04:11 <michi_cc> You probabyl want to look at makedata.mak, makedata.vcxproj and icudata.lst
22:05:15 <TrueBrain> I noticed this in the 5.1 too .. how did those changes came to be?
22:05:21 <TrueBrain> either someone went really in depth in it
22:05:28 <TrueBrain> or it got taken from somewhere? :)
22:06:19 <michi_cc> Some of that might have already been done by Rb, the rest would be me I guess.
22:06:50 <michi_cc> There's some additional code changes in tools/ to properly build the static data lib, too.
22:07:37 <TrueBrain> via vcpkg, the statics compiled without issues .. might be 57
22:09:34 <TrueBrain> now we are getting somewhere :D
22:10:56 <TrueBrain> okay, something to fiddle a bit with tomorrow
22:11:09 <TrueBrain> basically, ICU is 15 MiB of additional binary size ......
22:11:16 <TrueBrain> stupid library is stupid
22:11:27 <TrueBrain> if only they would have put all that data in different libraries
22:11:31 <TrueBrain> so you could pick the ones you like
22:11:44 <TrueBrain> most likely they have their reasons
22:14:00 <TrueBrain> tnx michi_cc; especially the icudata.lst is a good tip :)
22:19:44 *** andythenorth has joined #openttd
22:26:14 <peter1138> curticks = GetTicks(); realtime_tick += curticks - lastcurticks;
22:26:23 <peter1138> Why is it done like that?
22:33:01 <TrueBrain> HE CAN SEE CLEARLY NOW, THE RAIN HAS GONE
22:38:01 *** agentw4b_ has joined #openttd
22:39:24 *** agentw4b__ has joined #openttd
22:46:13 *** ToBeFree has joined #openttd
22:48:22 <Eddi|zuHause> i always thought of that as "he can see clearly, now [that] the rain has gone"
22:49:15 <TrueBrain> you say tomato, I say tomato
23:07:56 <peter1138> This gets deeper...
23:11:21 <_dp_> frosch123, am I reading it right that code and chances are fine, just need to explain that in comment?
23:11:44 <frosch123> yes, code looks fine, i just wondered about the bit magic for 15 mintues :p
23:12:50 <_dp_> frosch123, I though mentioning 1-bit intersection is enough xD
23:12:59 <frosch123> esp. because i did not look at the switch after it, and wondered how that bit magic would check for a corner
23:13:15 <frosch123> _dp_: the same comment also mentions the corner :)
23:18:01 *** andythenorth has joined #openttd
23:28:28 <frosch123> thanks :) now waiting for jenkins :p
23:29:19 <peter1138> Hmm, is it possible to setup extra nodes elsewhere?
23:29:27 <peter1138> As in... if I had spare capacity...
23:29:36 <_dp_> frosch123, could also turn that switch into bit magic but comment explaining that will probably be even bigger than the switch xD
23:30:28 <frosch123> peter1138: combo breaker, there could have been 3 dp commits in a row
23:31:05 <andythenorth> jenkins on AWS spot nodes :P
23:31:15 <andythenorth> almost free for just a few nodes
23:31:39 <peter1138> Still finding gui bits that should be realtime working on game ticks...
23:34:09 *** snail_UES_ has joined #openttd
23:39:40 <peter1138> Ok, that works better.
23:39:55 <peter1138> Scrollbar buttons are usable in FFWD mode now :p
23:42:12 <peter1138> Ah yes, must not forget the animated mouse cursors that are affected by FFWD.
23:45:25 <frosch123> @calc 0.02 * 52 * 20 * 12*4
23:45:39 <frosch123> hmm, yeah, aws is too expensive for us
23:46:14 <frosch123> hmm, actually, only a 1/4 of that
23:48:21 <Eddi|zuHause> is there much difference?
23:48:51 <frosch123> Eddi|zuHause: it all depends on estimating how many minutes we actually need :p
23:49:01 <frosch123> i tried the current activity
23:49:37 <frosch123> 12 builds per day, 4 days per week, 52 weeks per year
23:50:00 <frosch123> 20 minutes per build when using 2 cores
23:50:18 <_dp_> hmm, having hard times understanding my own patch
23:50:39 <Eddi|zuHause> means you didn't document it properly!!!!
23:50:45 <peter1138> frosch123, what's it all running on at the moment? The normal OpenTTD server?
23:50:57 <frosch123> half a cent for 2 cores per minute
23:51:05 <_dp_> Eddi|zuHause, yeah, but there's like 6 lines comment I'm trying to understand xD
23:51:10 <andythenorth> it starts out cheap and gets expenisve
23:51:27 <frosch123> peter1138: i assume so, 5 years old
23:51:43 <peter1138> Is the plan to get rid of it?
23:51:46 <_dp_> Ah, got it... I guess I'll add few more lines to that comment xD
23:51:49 <andythenorth> do we need a patreon? o_O
23:52:14 <frosch123> peter1138: maybe, but it is unrealistic :p
23:52:54 <frosch123> we won't be able to run custom stuff like eints, bananas2 and masterserver on cloud stuff for free
23:53:04 <frosch123> so custom server will likely be cheaper
23:53:18 <peter1138> Yeah, cloud is not really cheaper.
23:53:50 <frosch123> but cloud may be an option for the farm, since we have a hard time to predict the usage for that :p
23:54:08 <Eddi|zuHause> "cloud" always sounds to me like the only point where it's better is if you need to scale it quickly to random loads
23:54:11 <peter1138> I think cloud is more of an option when you can predict it :p
23:55:52 <frosch123> andythenorth: i have no idea about ottd finances, but there was always enough money, there is probably some miner somewhere
23:56:35 <andythenorth> cloud is $$ more for equal performance
23:56:39 <frosch123> the last fundraiser was for 0.7 iirc
23:56:41 <andythenorth> unless you have to pay sysadmin
23:57:00 <andythenorth> if you only measure computing perf. / $ then cloud is not a good deal
23:57:07 <andythenorth> do we pay our sysadmin?
23:59:34 <andythenorth> who has the money these days? o_O
continue to next day ⏵
